Basic Server Management and beyond

The term server management conjures up different connotations in the mind of the listener.  Depending on the type of server — software application server, virtual server or physical server, the issues they care about are different. Two tasks that instantly come to the fore are server configuration and server monitoring.

A software application server manager may visualize configuration of production middleware servers and the parameters may include database connections, memory size etc.  A manager responsible for the virtual infrastructure in a data center may picture server configuration tasks as storing and accessing virtual images, operating system types etc. for the virtual machines.  An infrastructure manager responsible for physical servers will take into consideration power, firmware and network configurations for the server.

Once the servers have been deployed, they need to be monitored.  Servers can be monitored for basic availability, feedback, threshold crosses or outright failures.  A software development manager could look for faults in the server logs with regard to database connections or code exceptions.  A virtual machine manager may be looking for the noisy virtual machine (VM) that affects neighboring VMs.  A physical server manager may monitor any hardware, power or network connection failures.  After detecting any faults, server managers need to analyze the cause of the problem, determine corrective course of action and make necessary configuration changes to fix the problem.

Typically, initial server management is done through a GUI interface. This is very useful during development and for visual operational monitoring.  Next, development and operations staff would need a command line interface and scripting capability to speed up server starts/stops and configuration parameter changes. This allows for rapid and scripted deployment of servers.  The ultimate capability is when the server exposes an API and a software program can automatically configure and monitor the server based on predetermined policies. This allows closed loop management of servers.  Imagine an ideal scenario where a server goes down and the management software detects the fault, determines the cause, alerts the operations center and automatically restarts the server with a safe configuration. Cisco UCS provides all the underlying capabilities needed to make this a reality in the physical server realm.

Cisco UCS Manager is the embedded device manager that runs in the Fabric Interconnect and provides the necessary management capabilities.  The Cisco UCS Fabric interconnect switch provides low-latency, lossless 10 Gigabit Ethernet and Fibre Channel over Ethernet (FCoE).  The UCS Manager provides configuration and monitoring capabilities for managing the physical servers and the UCS devices which provide network access. For an in-depth overview of the UCS Manager check out the UCS Manager Architecture document.

To simplify server management the UCS Manager provides a GUI, a command line interface (CLI) and an XML application-programming interface (API).  Users can write their own custom applications to manage servers. I would argue that users can create a “Hardware as a Service” offer in quick order.  And to top that, with the UCS Platform Emulator IT practitioners can even take the UCS Manager for a spin without procuring a single piece of UCS hardware – all at no cost.  No wonder several independent software vendors have used the API to create value-added IT solutions such as service assurance for the UCS.

In this recent interview given by Cisco Cloud CTO, Lew Tucker, you will see how an API such as the UCS Manager XML API , is a critical component of Cisco Unified Management and data centers of the future.

Tags: , ,


What does a 4 year old have in common with Cisco?

“Ow mommy, my leg huuuuuuuuuuurts,” complained my 4 year old.  After a quick examination and check-in with the doctor (read: I opened a book written by Dr. Sears and consider that a check- in with “the doctor”), I determined the problem was simply growing pains.

Growing pains don’t apply only to small children and adolescents. They apply to small companies and large enterprises alike. And like the growing pains you experienced when you were 4, 12, and 18 years old, they can cause physical (in the form of operational costs) and emotional (in the form of stress) pain for your business.

For my 4 year old the solution to growing pains is a kiss, hug, and maybe some chocolate ice cream. Most businesses (all businesses? There is always an exception) need more than a band-aid; businesses want a long-term solution to business challenges with measurable results. One of the most common “growing pains” for businesses is controlling operating expenditures.

Recent research shows that up to 75 percent of enterprise IT costs are operating expenditures (Gartner ITKMD, January 2011). Let’s explore how Cisco has significantly grown its infrastructure while reducing operating costs.

Here are some highlights of what we’ve achieved:

  • Virtualization strategy lowered TCO by over 30%; when turned into a cloud environment, TCO  dropped another 30%
  • Freed up the equivalent of a full-time employee for 1.5 weeks
  • Reduced IT service delivery times from weeks down to less than an hour
  • Achieved six-fold decrease in support hours spent each quarter
  • Decreased the number of critical issues related to the network by 30%
  • Provisioning time reduced from 8 weeks to 15 minutes for infrastructure services

How did we achieve these results? By deploying a private cloud solution built on a secure data center, enabling Cisco to deliver IT-as-a-Service. Every single capability and service –application, data, communication, infrastructure — is delivered as a service to the business

How can you learn more?

Watch the video testimonial with Cisco CIO, Rebecca Jacoby

Read the Total Cost of Ownership Case Study

Tags: , , , ,


Router Security: Ready for Primetime

I have a confession: I’m a technology late-adopter. On Rogers’ Innovation Adoption bell curve, I probably fall somewhere in the ‘late majority’ —  I like the tried and true.

But with a few years and many advances, I’m back on Facebook (my short experience with it left me with privacy paranoia),  and if you can believe it, I’m now an iPhone user. I appreciate not lugging around my iPod, and having a camera ready whenever I need it, but it’s not only the extra bells on the integrated device that has impressed me — it’s the realization that I don’t have to compromise functionality to have it all.

Another technology that has made a lot of strides since its entry into the market is integrated router security. In the past,  adding security could severely impact the performance on your routers, or the security functionality was so trimmed down that it was hardly worth it. But innovations in routing have made integrated security a viable option, with significant opex benefits. So even you’re a technology late adopter, it may be time to think about integrated router security. Here are three reasons why:

1. Cisco routers can be used for firewalling and DDoS attack protection, without compromising router performance. There are multiple ways to use the IOS Firewall on the Next-Gen Integrated Services Routers (ISR G2s) and Cisco Aggregation Services Routers (ASR 1000s). Here are just a few typical scenarios:

  • Use the ISR G2 IOS Firewall for hybrid direct Internet access from the branch, with the non-Internet traffic backhauled to headquarters
  • Use the ASR 1000 IOS Firewall to protect all traffic backhauled to the head end
  • Use the ASR 1000 IOS Firewall to protect all campus internet traffic at the enterprise edge

At the enterprise edge, speeds are critical, and layering firewall technology on the router could raise eyebrows as it would be the first line of defense. The ASR 1000 was built to accommodate multiple simultaneous services running on a single platform; a built-in zone-based firewall and capabilities to protect against mass traffic (traffic flooding). If a DDoS attack was directed at an ASR 1000, the router doesn’t exhibit high CPU consumption because the packet forwarding engine (or data plane) has extremely high capacity, and the route processor (or control plane) runs on a separate, independent CPU which can instruct the data plane to open or close pinholes for traffic. Even under attack or overload with oversubscribed interfaces, the ASR 1000 will always give priority to high priority packets, to maintain QoS. The ISR G2 IOS Firewall also provides stateful firewall capabilities to meet compliance mandates such as PCI or HIPAA, and it works with other Cisco IOS security features, including Cisco IOS Intrusion Prevention System (IPS), and IOS Network Address Translation (NAT), Cisco ScanSafe Cloud Web Security, or Cisco TrustSec (below) to create an integrated branch-office perimeter security solution.

2. Cisco routers can provide all of your VPN functionality at high scale. The ASR 1000 Series and ISR G2s offer both remote-access and site-to-site VPN connectivity. End users can connect securely to the network, and you can increase the integrity confidentiality of your sensitive traffic between branch offices and across your WAN. For remote access, users can connect using the Cisco AnyConnect VPN client on laptops to handhelds to the FlexVPN Server on the ISR G2 or ASR 1000.  Businesses with remote offices can use Group Encrypted Transport VPN (GET VPN) for encrypting IPv4 and IPv6 traffic over the WAN, and Dynamic Multipoint VPN (DMVPN) for encrypting IPv4 and IPv6 traffic over the internet.  In addition, the encryption on Cisco routers offers next-generation encryption, including AES 128-bit encryption or higher. And both the ASR 1000 and ISR G2 have built-in hardware encryption capabilities that are enabled without impact on router performance – the ASR 1000 can encrypt up to 11 Gbps, and the ISR G2 up to 1.2 Gbps.

3. Cisco routers can enforce access control policies typical firewalls and access control lists (ACLs) cannot. There are several reasons to have security policies that are based on the user or group and the data that is being accessed – whether it be compliance, internal governance, or best practices to protect confidential or sensitive data. Even your senior executives may not be allowed to access sensitive financial data when on a mobile device on an unsecured public Wi-Fi network. Cisco TrustSec is a contextual, data-centric security solution uses Cisco infrastructure, including the ISR G2 and ASR 1000, to enforce access control throughout the network. Based on the policy set in the centralized policy engine (Cisco Identity Services Engine (ISE)), you can restrict user access using the ASR 1000 or ISR G2 IOS Firewall (blocking based on the Secure Group Tag (SGT)). TrustSec enables you to leverage your Cisco infrastructure for more granular access control, down to the device being used, the location from which users are connecting, or what data they’re trying to access.

In a nutshell, it sums up to: you can have the security functionality you need, without compromising your routing infrastructure. And this goes without saying, but by combining your security functionality on your routers, you have less to buy, install, maintain, and manage. If you’re in the market for a new router, you might want to think about integrated security sooner than later, as you can often get a discount when you buy security bundles up front. Visit the Cisco router security page or contact your channel partner or account manager for more information on security bundle offers. As with my iPhone, the integrated technology approach may just be your life-changer.

Tags: , , , , , , , ,


Toyota Tsusho Deploys Cisco Virtual WAAS to Enhance Performance

vWAAS Bandwidth Reduction Chart

A key WAN optimization benefit is the mitigation on bandwidth consumption during the huge traffic burst on Mondays, when employees arrive at work and email attachments come to their mailboxes. This chart shows actual bandwidth consumption well below what applications would have required.

A few weeks back I highlighted a report from VCE about our virtual WAAS (vWAAS) WAN optimization solution running on the Vblock platform. Now comes a new case study of a vWAAS deployment at Georgetown, Kentucky-based Toyota Tsusho America, Inc. (TAI). For the Georgetown data center, TAI decided on vWAAS rather than WAAS appliances. The detailed case study is a compelling argument for virtualizing WAN optimization for improved high-availability and more streamlined operations.

“We were an early adopter of vWAAS,” says Chris Jones, TAI Manager of Infrastructure and Operations, “and we perceived value in placing WAN optimization close to the data rather than near the WAN edge. In particular, we felt we could have lower-cost high availability (HA) for WAN optimization by leveraging the Vblock HA. And we perceived operational simplicity in the event of failure, compared with replacing a physical appliance and rebuilding the cache.”

The Vblock platforms include SAN storage for fast I/O, along with extensive redundancy features for high availability. vWAAS can leverage the SAN for Data Redundancy Elimination (DRE), the mechanism that delivers much of application acceleration and bandwidth reduction. DRE builds application-aware caches of data, and small tokens replace redundant data on the WAN. At TAI, WAN optimization performance becomes fault-tolerant: Upon any failure, a new vWAAS instance can utilize the existing cache stored on the SAN.

TAI then focused on the 18 of 36 sites in North America that were approaching the limitations of the T-1 circuits that connected them to the private MPLS network serving TAI and its subsidiaries. TAI’s deployment right-sizes WAAS appliances for each site. The largest branch site, New York City, utilizes a Wide Area Engine (WAE) 674 appliance. Other branch sites use Wide Area Virtualization Engine (WAVE) 274 appliances. Most branch appliances are deployed in line for simplicity. “It’s pretty easy, just a matter of getting them out there and walking an end user through a very quick wiring change. The simplicity saved us a significant amount of costs associated with sending an IT resource onsite,” says Jones.

TAI expects to see the return on investment (ROI) within a year. With WAAS, TAI avoided the US$8000 per year per site additional recurring costs, reduced email traffic to its largest location by more than 65 percent, and deferred for the foreseeable future expensive bandwidth upgrades at many of its locations. And TAI generally prefers capital investments in solutions rather than increasing operational expenditures, in particular if the ROI is so fast. “ROI in a year is a pretty strong business proposition,” says Jones.

HTTP response times improved consistently in the 35-40% range, further enhancing user productivity. You can read more about the TAI deployment, their application environment and other business benefits they expect from the vWAAS deployment here.

Tags: , ,


How a Customer Crisis Ten Years Ago Helped Me Understand the Challenges of Cloud Service Creation Today (Part 1)

If you are already offering cloud services from your data center, or are starting your planning to do so, there are some key initial questions I’d advise you consider.  And they’re not about the technical aspects of data center architecture!  You find yourself asking “what cloud services should we offer?” and “How do we evolve what we offer today”.  You may, post launch, also find yourself asking “Why is the take up to our cloud services not as big as we initially forecast?”.  Before you say “aha –  these are questions for service providers offering cloud services” .. I would argue that these questions are fundamental to enterprise and public sector organizations too — assuming that you intend to provide cloud services to your user community that help them do their jobs.  Following one of my colleagues who blogged earlier that, with cloud services, “you need to think like a product manager”, I will assert here that there are some key lessons from product management that can help you in creating cloud services that are actually useful to your customer and/or your internal clients and stakeholders.

As you may have noticed from my previous blogs, I’ve worked in product management of both products and services for a while (since 1997 in fact, when I moved from software engineering into the “dark side” :-) ) …. so what lessons have I learned that may help you address the challenges of creating and defining new cloud services?

If you are starting a journey to cloud, offering services from your data center – either to internal stakeholders as in the case of an enterprise business, or to external customers as a service provider would do – you should find yourself asking “what cloud services should we offer?” … and if you are already offering cloud services, you may find yourself asking “why isn’t the take up to our cloud services not as big as we’d hoped?”

My story around this is very clearly etched in my mind: it really was a “light-bulb” moment in my product management education. I was at a meeting with a customer at their R&D labs.

Cisco Scotland Office at Night – Where I Work

It was the 4th or 5th such meeting around the product (which so happened to be an Element Management System (EMS) – a type of network management software application.  I wasn’t directly responsible for this EMS, however I had been involved in one of the early requirements meetings.   I remember watching as a senior product manager from Cisco, and a representative from the customer (who I will now call “the customer”, although later I recognized that he was only one), reviewed the Product Requirements Document (PRD) – the document that specifies exactly what the product should and should not do — and, page by page, signed off the document as being exactly what the customer wanted.  I was relatively new to product management then, and wow, this guy was a senior product manager, this was an impressive process, we need to start doing this in my team, and this must be the way to do things .. and so on.  I was impressed!

And so my lessons began ….

Anyway, time went on, and the product was developed and delivered, and since I was based close to the customer, I was called on to help when the product clearly wasn’t meeting the customer expectations.  Sure, there were a few quality issues after the first release or two, but these were eventually ironed out.  Yet the customer came back and reported that his operations team still weren’t using this EMS.  We went through 3 or 4 meetings, where spreadsheet after spreadsheet of feature requests was brought back to us by the customer, with the consistent message — “if you could implement some of these features, we would use this”.  And so it went on.  And still they didn’t use the EMS.

Time passed and we were back at the customer labs, for another meeting.  The primary customer contact had organised for us to meet the operations manager, whose team were the target users.  The ops manager rushed in late, and what he said next really concisely communicated what he really needed: “Sorry” he said, “we’ve just lost an Internet PoP [Point of Presence, or Central Office] and our network is at risk of collapse from the sudden increase in web traffic.  I’ve only got 10 minutes to spend with you, sorry for dragging you here.  I really don’t like you guys”, he continued, “I can’t upgrade our network because of you”.

In one sentence, he described his problem.  And the EMS, while it satisfied many of his “requirements”, didn’t solve his main operational headache sufficiently.  The EMS did have some software download features to help with network upgrades, but they didn’t support the large scale operational procedures this customer used to upgrade their network in a robust and cost effective manner.

This was a key moment in my product management learning and experience – think customer problems first, requirements second — and indeed helped my team and I re-think our approach to the market completely (and subsequently devised a multi-award winning product for troubleshooting MPLS networks).

An additional aspect was the organisational divide between our main contact in the customer and the operations team. Basically these two individuals were in different groups within the customer, and to be honest, didn’t communicate very often.  So we also missed the organisational silos that can – unfortunately — happen in large organisations.

This brings me to one of the fundamental lessons of product management – the “tyre swing” analogy below – which is as relevant to cloud service creation as it was to my example above.   And I’ll discuss this more in part 2 of this blog!

In the meantime, if you want to find out more on Cisco Data Center Services and how we can help you develop and implement your cloud computing strategy, please check out our Cisco Cloud Enablement Services – and (of course! :-) ) have a read through some of my previous blogs.

The Tyre Swing Analogy: How Different Users Perceive Differently the Customer Needs

Tags: , , , ,


Cisco, NetApp & Microsoft – FlexPod validated with Microsoft Private Cloud

NetApp and Cisco continue to innovate and deliver new popular FlexPod solutions.  These pre-designed and pre-tested Data Center infrastructure offerings are built on a unified architecture comprised of Cisco UCS servers, Cisco Nexus switches, and NetApp storage with Data ONTAP.

We’re pleased to announce FlexPod validated with Microsoft private cloud, a new offering which brings the benefits of the FlexPod architecture to Microsoft Windows Server and Hyper-V environments with System Center integration.

Microsoft Windows Server and Microsoft applications such as Exchange, SharePoint, SQL Server, and VDI are key workloads we often find in our customer’s UCS installations. UCS provides an optimum compute solution for these Microsoft applications delivering an agile, simple, and efficient Data Center platform. Please visit the FlexPod validated with Microsoft Private Cloud site here to learn more on how Cisco and NetApp are enabling your journey to the Microsoft Private Cloud.

Tags: , , , ,


Intelligent Automation + UCS = The Right Choice for your SAP Business Warehouse Accelerator

In-memory computing has been cited as one of the top technologies for 2012, SAP has introduced exciting new solutions based on this technology, and it is clearly part of the future of Business Intelligence (BI). But if you’re evaluating SAP BI solutions, what hardware systems are right for you today and in the future?

Maybe you recently acquired a license for SAP’s BusinessObjects Explorer and Business Warehouse Accelerator software. Maybe you want to prepare your data center for next generation in-memory computing databases like SAP HANA, but you’re not quite ready to invest in it yet.   Maybe you know that you need an appliance to run it in your data center and are evaluating options.

The BI landscape is complex, and many organizations aren’t quite sure how to integrate new BI technologies into their enterprise roadmap while reducing risk. In response, Cisco’s Intelligent Automation software team partnered with our UCS team to offer an SAP-certified appliance for BW Accelerator and other BI solutions.

Cisco’s appliance for SAP BW Accelerator is unique in that it uses our Intelligent Automation software specifically engineered to execute technical operations for BI solutions like SAP NetWeaver Business Warehouse and Business Objects as well as in-memory computing solutions like HANA. This powerful automation extends to the appliance’s compute and storage level as well.

The Cisco Appliance for SAP BW Accelerator is also built on Cisco UCS. Carrying up to 40 blades in the largest configuration, Cisco’s appliance harnesses the power of the highly acclaimed Unified Computing System to the fullest potential. It accomplishes this by leveraging our automation and orchestration software to integrate directly with Cisco UCS Manager.

The storage component is also integrated into the appliance. We have a version of the appliance that leverages NetApp FAS 3240 storage and it plays a critical role in operations. As such, the Cisco appliance for SAP BW Accelerator integrates directly with NetApp APIs to ensure that both SAP’s software and the underlying infrastructure are running smoothly.

We’re hosting a webinar with SAPinsider on Tuesday February 28th so you can learn about our SAP-certified BW Accelerator (BWA) solution and learn how you too can build on-demand reports, mitigate risk, and reduce costs.

You’ll learn whether our 3-blade appliance will do the job or whether you need the 40 blade version – and you’ll discover the powerful differentiation and value we provide with UCS and our Intelligent Automation software.

Sign up here to join us for this technical introduction and business discussion on why leading organizations are selecting Cisco as the go-to partner for their critical SAP Business Intelligence applications. The agenda for the webinar includes:

  • Introduction to Cisco’s BWA Appliance solution
  • Important benefits of Cisco Intelligent Automation
  • Managing service levels to ensure SAP BWA performance
  • Lowering TCO for your SAP BWA Appliance
  • Scalability, reliability and performance for BWA

Find out more about Cisco’s appliance for SAP BWA at http://cisco.com/go/sapbwa. And if you have any questions, you can reach us at sapbw@cisco.com.

Tags: , , , ,


Three Pitfalls to Avoid While “Hitching your Wagon to the Cloud” (Pitfall 1: WAN Does Not Matter)

Last week at the Cloud Connect 2012 conference in Santa Clara, I was sharing a panel with industry colleagues representing the most prominent vendors in the application optimization, cloud infrastructure and network acceleration space . The topic was “hitching your wagon to the cloud”, discussing the importance of the network, particularly WAN, to make your cloud deployments successful. Folks talked about interesting concepts like “stateless branch office”, and “nirvana of Internet as WAN” before someone in the audience retorted, “I need solutions that help me deal with reality!”

The reality is that as enterprises adopt the cloud, IT teams, particularly networking, are expected to make everything work magically and deliver the best user experience without sacrificing security. In my last post, “Why hybrid clouds look like my grandma’s network”, I highlighted networking requirements on the cloud side to make deployments successful. Today, let’s focus on what’s needed on the branch or user side of the equation.  It is indeed possible to deliver a stellar cloud experience to even the most far flung branches and users on the move if IT teams consider WAN obstacles  and avoid the following pitfalls :

  1. Cloud is about the Internet, so WAN does not matter
  2. I can secure Cloud in the same way as I secure other enterprise applications
  3. Cloud is about centralization so can “survive” with dumb infrastructure at the branch

 In this blog, let’s talk about the fallacy of “WAN does not matter.” In future blogs, I’ll cover the other pitfalls. A common misperception is that Cloud, especially SaaS applications like Salesforce.com, are accessible via the Internet and don’t need rethinking of WAN strategy. Adding bandwidth to remote sites should be good enough to provide a good user experience, right? Not necessarily. The reality is that the majority of enterprises still backhaul Internet traffic over private WAN,  T1/T3 or MPLS, to central sites for Internet handoff. Just adding bandwidth is not only expensive, but also has the counter effect of adding more latency as traffic from the branch user to SaaS application causes hair-pinning via the central site.

 What you need is to re-architect your WAN into a “hybrid WAN” with direct Internet access from the branch that intelligently uses your private WAN for intra-enterprise traffic. To do this, your network at the branch needs to be smart enough to:

  • Split traffic between private and public networks based on policies
  • Have a unified QoS framework to make sure critical Internet traffic does not get clobbered by someone watching a casual YouTube video
  • Build failover capabilities to 3G/4G wireless networks for cases where the Internet connection goes down

Seems a tall order? There are solutions available to all of this with ease. For more specific design information look here.

Thoughts? Other pitfalls, you may have experienced?

Tags: , , , , , , ,


Cisco SANs: Where do you begin?

I spent two weeks over at the Ask the Expert forums, and I came to the realization that often our customers are bombarded with facts, figures, speeds, feeds, features, buzzwords, comparisons and functionalities for which they’re not sure which ones they must have while others they can live without or are a convenience.  So I figured I’d toss out what I think are the top features for building an MDS Storage Area Network.   Some may be obvious and others you might shake your head or light up the torches.  They’re not in any particular order as your mileage varies from mine.  I’ll probably skip those that are obvious like “hot swap power supplies” and other oh so exciting abilities…

The first set I usually refer to as the holy trinity of features as they constitute the foundation of the connectivity… VSANs, Port-Channels and TE Ports.  They’ve been around literally forever on the platform and for good reason, they’ve been part of the hardware’s DNA since it’s inception.  Additionally, if you walk down the hall to the folks that manage your LAN, you’ll find out that they’re using pretty much the same concepts and features as you (VLANs, Port/Ether-Channels and Trunking or 802.1q).  So, if those guys are managing hundreds or thousands of switches and routers, there’s probably something worthwhile here.   It’s also a pretty good chance that they are using them for the very same reasons that you are:

  • VSANs: Isolation of fault domains.
  • Port-Channels: High Availability and load-balancing of InterSwitch Links (ISL)
  • TE_Ports: The ability to run multiple VSANs over the same ISL leveraging frames tagged with the VSAN ID and enforced in hardware.

Next on my list is NPV Mode aka N_Port Virtualization.  I grew up in the era of 16 port SAN switches and like rabbits, they multiplied, and so did their domains, and don’t get me started on the upgrades…  You had top of rack designs that involved dozens of small switches and this tsunami of small switches was slowed down by the emergence of the high density directors with hundreds of ports, first 128 then 256 now over 500.  Lots of small switches met their demise..

However, this architecture came roaring back today, especially as we see companies deploy FCoE on with the Nexus 5000 at the edge/access.  However, Cisco got smart and implemented NPV mode, which solved quite a few problems that were killing us back in the day.  The NPV switch didn’t take up a domainID, thereby it didn’t maintain a copy of the zoneset, it didn’t process FSPF, nameserver or maintain E_Ports.  It became for all intents and purposes, a pretty dumb device.  Thereby solving the last headache: the upgrades.  If the switch itself doesn’t require all the intelligence, there’s fewer reasons for you to upgrade it.  Fewer features means fewer bugs.  Fewer bugs means fewer upgrades.  Fewer upgrades means fewer maintenance windows at 2am on a Saturday night.  And I don’t think there’s anybody out there that relishes in the thought of doing an upgrade when compared with anything else you could be doing at 2am on a Saturday night.

Next on my list, I’d say Remote AAA, or Authentication, Authorization and Accounting.  Though you might classify it as “store my user-account information somewhere else”.  There was a time when you set up a switch and then had every user set their own password, or more commonly you just set some common admin account up on it and the SAN team used the same one everywhere. Leveraging the existing AAA infrastructure (TACACS+, Radius, LDAP or Active Directory) means one less thing that the SAN admin has to maintain and it enables you to easily grant access and determine what they can do from a central location

Since we’re on management, I’m going to add, Event Notification and Management. I’ve seen environments where one guy’s sole responsibility is to watch a screen of SAN switches and wait for “something to happen.”  Always wondered, what happens if he’s at lunch and something happens…? Better be a short lunch.  We’re really looking for the switch to detect a problem and then notify us or the maintainer to resolve the problem.  My favorite example of this comes from the disk array companies.  A drive fails in your disk array at 2am, the array phones home, opens up a case saying “disk drive has failed.”  An engineer is dispatched within a few hours, they show up at your datacenter, replace the failed disk and business continues on as normal.  You’ve enjoyed your full 8 hours of sleep and when you come in in the morning, you’ve got a nice email from the storage company telling you that they replaced a failed drive for you.    So what features contribute to this?  You can start with syslog, call-home emails (which can go to you or your service maintainer) or SNMP based notifications.  Any of these messages can be processed automatically and then with a bit of intelligence in the receiving software take the appropriate action.  The key part being that the switch informed you of a problem. Could be a failed fan or it could be that an ISL is running at 90% utilization.

Looking at my stack of cards here, next up at bat is Enhanced Zoning.  This standards (FC-GS-4 and FC-SW-3) based zoning method solved two key problems with the most common activity in SAN management, both which can be considered career limiting moves.  The first being, the ability for the switch (not your GUI) to provide you with a preview of what zones and zonesets you are about to put into production and then either go forward or abort the changes.  The second being the elimination of the practice of having a “master zoning switch”.  This was an arbitrary switch in which you performed all of your zoning related work on.  Why? Because it supposedly held the only complete copy of your zoneset database, and if this switch went down, you were in a world of hurt.  Enhanced zoning fixed this by guaranteeing that all switches in the fabric (or VSAN on the MDS) had an identical copy of the full zone database (this is the one you edit and then activate).  Third, it also ensured that you never had both you and the SAN admin down the hall editing the zoneset at the same time.  I know I mentioned two career limiting moves, but this ones a doozy.  The ability to aquire a lock on the zoneset ensures that nobody is editing a stale zoneset database.

Since I’m on zoning, I think I’ll segue into Device-Aliases.  The easiest way to explain these is to use a simple example from the LAN world.  Imagine for a second, if you implemented DNS on a per subnet basis?  So www.cisco.com could resolve to a different IP address if you were on subnet 192.168.0.0 than if you were on 172.22.0.0.  So the networking folks decided to make DNS independent from the underlying infrastructure.  This is where Device-Aliases improved upon the age old method of providing SAN pWWN to plaintext mapping over fcAliases.  The problem with fcAliases is that they are tied to zoning.  That’s like tying DNS to ftp applications only.  What if you want to use something that crosses VSAN boundaries like IVR? Fcaliases don’t guarantee that pwwn1 has the same fcAlias defined in both or all VSANs.  Or you could have host1 defined two different ways in two or more VSANs.  Device-Aliases, working independent of zoning guarantees a 1:1 mapping of pwwn to “plain text name”.  Thereby eliminating the shortcomings with fcAliases.

So here we are, not sure how to end this, but my editor is probably looking for me to write some flowing prose in the style of some 18th century Norwegian poet, I’ll just leave with this nugget.  While your SAN fabric may have many requirements due to business drivers, there is a set of features for which every Cisco SAN Fabric should have.  These are those foundation features for which we build our SANs upon.  Sure there others such as performance monitoring or SAN Extension for which get built upon these features, but if you start with these and wrap them with solid processes, you’ll be much better off than most.

So which of these features do you use or can’t live without and which do you abhor? I’m always interested in what people are actually deploying. Until next time, watch out for the open floor tile…

Tags: , , , , ,


Get Your Network Fit for Video – the Easy Way! AutoQos



Video to Video Communication is the Future

Marthin De Beer | 15 Feb 2012



14,470


68








UCS: Over 10,000 Served

Todd Brannon | 18 Jan 2012



9,029


9








Cisco: Helping Our Customers Innovate

John Earnhardt | 03 Feb 2012



3,384


9








Cisco Has 100K Twitter Followers. Now What?

Autumn Truong | 24 Jan 2012



8,264


8








My BFF Router

Ido Glazer | 31 Jan 2012



6,655


8