Swine Flu? What It Means For IT Professionals

The US Center for Disease Control (CDC) has confirmed 64 cases of swine flu in the United States and as other countries including Canada (6), New Zealand (3), the United Kingdom (2), Israel (2), Spain (2), and now Germany have confirmed cases, the World Health Organization has raised the worldwide pandemic threat level to Phase 4. This means health officials have confirmed that the disease can spread person-to-person and has the potential to cause "community-level" outbreaks. The CDC recommends avoiding travel to Mexico and if you get sick, to stay home from work. Large numbers of employees out sick will impact the business (revenue) and cost your company a lot of money in productivity loss (you still pay employees their salary when they're out).

Stopping the spread of the disease and treating those infected is obviously a health issue, but the swine flu outbreak does have implications for IT professionals in both the short term and the long term. First, if you haven't done so already, you need find a copy of the bird flu business continuity plan (BCP) that your company developed in 2006 and call a walk through exercise immediately. And if your responsibility is IT disaster recovery and not necessarily business continuity, don't wait around for someone else to dust of the plan and call the exercise - this is too important to wait. Call your CIO, CISO, COO, and CEO and tell them it needs to be done now. There's a good chance that the plan is out of date and that it hasn't been exercised in a long time.

A plan walk through is no substitute for a more thorough exercise but its a good place to start. This will help you:

• Validate the currency of the plan and the procedures.
• Validate team member roles and responsibilities.
• Understand what technology and services you currently have in place.

After the plan walk through, you will need to conduct a more thorough exercise that will validate team member competence, confirm the time it takes to execute each activity, and validate the technology you have in place to support the plan including:

• Automated communication and notification solutions for crisis and emergency communication.
• Remote access procedures to ensure that the greatest number of employees can effectively work from if there is a "community-level" outbreak and more travel restrictions.

As you dust off the plan, update it, and exercise it, you've also got to make sure that you roll out a training and awareness program so that employees know what to expect in terms of communication from senior management, where to go for information, and what to do when and if you invoke your pandemic BCP. As IT, this might not be your responsibility, but you need to raise the issue during exercises.

What swine flu has done is reminded us all of the necessity to plan for threat scenarios that affect people more than they do data centers and other physical corporate facilities. Alternate work area facilities, mobile recovery units, and other workforce recovery strategies aren't effective when people are home sick or there are travel bans in place. In these scenarios your workforce recovery strategy must rely on remote access solutions or virtual workforce solutions.

In a recent joint Forrester and Disaster Recovery Journal survey, we asked 285 BC/DR decision makers if their company had strategies for workforce recovery in their BCPs, 68% said yes. This means that 32% of you out there have a lot of work to do. Of the 68% that have strategies in place, 86% use remote access procedures as part of their strategy;

Remote access or virtual workforce solutions can be as simple as VPN procedures for employees with laptops or remote desktop solutions like Citrix GoToMyPC or LogMeIn or more advanced solutions like desktop virtualization or application virtualization. Bottom line, you want employees to be able to access their data and applications so long as they can get to a computer with Internet access.

You also have to think about your own employees: how will you run IT operations if key employees are out sick or can't get to work? There's a lot you can do remotely, but not everything. You have to ask yourself: how many employees have we cross-trained for other job functions? Can your storage administrators run backups? Could your server admins allocate storage or debug a storage network problem? Cross-training in critical functions is another part of workforce recovery or, I should say, workforce continuity.

I have an upcoming report that looks at the human side of business continuity and disaster recovery planning. I'm interested to hear how the swine flu has changed your priorities and how senior management has asked IT to help in the response.

By Stephanie Balaouras

Check out Stephanie's research

Deduplication Will Exist Everywhere

Most customers were just starting to get their arms around all the different deduplication approaches available in disk appliances and VTLs from vendors when backup software vendors and even non-storage related vendors began announcing deduplication capabilities.

We all know the appliance and VTL vendors offering dedupe, including COPAN Systems, Data Domain, EMC, Exagrid, FalconStor, HP, IBM (Diligent), NEC, NetApp, Quantum, Sepaton, Sun StorageTek, and others.

And there were existing backup software vendors, including EMC Avamar, Symantec NetBackup PureDisk, and many online backup software vendors, like Asigra. Now add CommVault Simpana 8.0 and IBM Tivoli Storage Manager (TSM) V6.

But just because the deduplication is performed in software doesn't automatically make it source deduplication. With source deduplication, the deduplication is performed on the client (the server or desktop/laptop that you want to backup) before its transmitted over the LAN. Even though it's performed in software, IBM TSM and CommVault Simpana provide target deduplication. The deduplication is not performed on the client — it's performed on the media server and stores the data in deduplicated form on whatever disk target you have. So source vs. target is not what does the deduplication but rather where deduplication is performed. You can expect other backup software vendors to add deduplication capabilities in the future.

Any software vendor that manages content will build in dedupe: Ocarina is a good example of this. So will software vendors that manage storage capacity, particularly those vendors whose offerings have a built in volume manager and filesystem. VMware is a good example here. The company introduced deduplication capabilities in vSphere (v4 of of Virtual Infrastructure).

Plus, vendors such as NetApp offer deduplication in their production storage systems. NetApp customers have seen good dedupe ratios in virtual environments (server and desktop) and file shares. EMC has introduced file level deduplication capabilities in its Celerra offering. Neither vendor charges for dedupe. You can bet more storage vendors will add file and eventally block-level deduplication functionality.

AND there are completely new entrants like Riverbed. Surprised? It makes sense when you realize that WAN optimization vendors like Riverbed have been deduplicating data all along - that's partly how they're able to reduce bandwidth requirements for workloads like remote backup and replication. They simply "rehydrate" the data before its written to disk. Now imagine a WAN optimization appliance as a gateway to a NAS system deduplicating data inline and storing the data in deduplicated form, not rehydrating it.

IT professionals need to know that deduplication will be available everywhere in the environment, in software and hardware, and in production environments, not just backup and archiving. There will be pros and cons to each approach and it's likely that you will leverage multiple approaches in your environment.

I also expect that since deduplication exists everywhere and is quickly becoming a standard feature of software and disk systems, vendors soon won't be able to charge a significant premium for it, if any premium at all.

I'm in the process of finishing up a report on the state of deduplication and I'd welcome any comments on the subject. Are you still struggling to decide between approaches? If you've already dedplyed dedupe, is it living up to the hype? Are you using dedupe to reduce bandwidth requirements between data centers and remote offices?

By Stephanie Balaouras

Check out Stephanie's research

VMware Wants To Be Your Network Operating System Of Choice

Whenever a company changes the name of their major product you often have to wonder what level of change they are trying to signal. In the case of VMware which changed ESX to vSphere yesterday, the signal is one of intent. They could have called it vWorldDomination but that might have been a bit too caustic. So instead they chose a global metaphor. Despite the subtlety, make no mistake, this version is a direct affront to how we have traditionally run our data centers with traditional operating systems and element-centric system management tools.

They made their case initially at VMWorld EMEA when they declared that a new “operating system” is needed in the virtualized data center and that the old model no longer applies. They called it Cloud OS but didn’t deliver on this vision. vSphere is the first step towards this new model in that it significantly shifts the focus from simply virtualizing workloads to managing and automating pools of VMs and shows how management at the virtual infrastructure layer can address data center efficiency in ways other layers can’t. It also moves the VM world closer to being able to manage business services that span VMs (although other tools like HP Operations Orchestrator and BMC BladeLogic still do this better) and track and diagnose their performance with AppSpeed, previously BeeHive, (although not as well as Hyperic).

Probably the biggest improvement in vSphere is its performance and scalability. There are a number of improvements to the maximum supported RAM and CPU configurations, as well as far better I/O throughput, and overall efficiency. In short, VMware can now claim that they can virtualize any application, no matter how performance hungry it is. Plus, VMware partners like Intel and Cisco have announced complimentary enhancements to address a variety of performance and ease of configuration issues.

Some of the key capabilities that enterprise customers should strongly consider include:

• vCenter Host Profiles -- Capture all the configuration details of a deployed virtual machine or collection of VMs and create a golden master that will enforce these configuration parameters when a service is reinstantiated, moved or duplicated.
• Thin provisioning with vStore -- Quick, what’s your storage to VM ratio today? What if you could cut this down by 90%? How many of your VMs share the same OS and middleware stack (or same applications). And your storing how many copies of that exact same software? 'Nuff said. While many enterprises take advantage of array-based thin provisioning to get some of these same benefits, vStore provides these vendors with an API to optimize thin provisioning for a vSphere environment.
• vShield Zones -- Distributed Resource Scheduling is a key technology for creating pools of resources and allowing VMs to automatically optimize their use of these resources. But managing a big homogeneous pool lets you set policies per app but not across groups of apps. Zones lets you create sub-pools for implementing these types of policies.
• vCloud -- while this is still mostly a future, VMware now has named a collection of hosting companies who plan to deploy VMware-based cloud computing in their data centers which will allow you to more easily take advantage of Infrastructure as a Service cloud computing. The big gain they bring: Your vSphere and theirs are compatible and your existing vCenter-centric tools allow aggregation of your virtual pool and their clouds.
• Fault tolerance -- for applications that require zero downtime, VMware now offers a fault tolerant capability that can eliminate the need for specialized hardware or additional clustering technologies. The fault tolerance feature replicates your VM’s state to a shadow VM on separate hardware in the same data center. If the primary machine should fail, the shadow VM picks up with no disruption to users.

But before you can really take advantage of these enhancements, enterprise infrastructure and operations professionals need to adopt more general best practices with their VMware environments such as booting VMs from network storage, activating DRS and getting comfortable with basic policies, taking greater advantage of VM templates and virtual appliances, leveraging VMware HA for recovery, and backing up with tools that leverage VMware’s backup APIs. You can’t move to a more efficiency future without preparing your environment for it.

By James Staten and Galen Schreck

Check out James' research and Galen's research.

Covetus The Sun Installed Base

The value of Sun’s Solaris installed base proved its worth once again this week as Oracle found it too tempting to pass up and pulled the trigger trumping IBM. A large percent of Oracle’s most profitable customers run their Oracle wares on Solaris and for them to fall further into the hands of the mortal enemy alone justifies the purchase. Sure, Oracle gains complimentary IP in Java, MySQL, and a very competent services organization but most of the rest is likely to end up off Oracle’s books.

It’s not every day that we read about a software maker buying a hardware company and that in itself is perhaps the biggest sign of things to come from this acquisition. Oracle, like Microsoft, enjoys healthy profit margins from a software-only business model. While Oracle is far more consulting-heavy than its Redmond rival, it profits rise above IBM, HP, Cisco and others because of its low cost of goods. Sun’s server and storage businesses don’t fit with this model and certainly don’t justify the further investment in the SPARC microprocessor that will be needed to keep this business healthy. So despite Oracle’s statement that, “Oracle plans to engineer and deliver an integrated system -- applications to disk -- where all the pieces fit and work together, so customers do not have to do it themselves,” expect Oracle to shop these units tout suite. Dell and HP are likely to bid for these businesses and do a strategic alignment on product collaboration like HP’s last year on the Oracle Data Warehouse.

Sun’s tape products, picked up in the StorageTek acquisition will be especially appealing, but tape has become a far less important part of the storage ecosystem than it was when Sun made its initial purchase. EMC, NetApp, and Cisco could potentially bid but are less likely suitors.

Expect Oracle to continue to invest in Unbreakable Linux, too. While this strategy was Oracle’s move to gain an OS agenda, and Solaris gives it much stronger IP position, the migration from UNIX to Linux will continue unabated. Unbreakable Linux will become more about taking from RedHat.

On the virtualization front, Oracle becomes a bit more formidable player but still with a lot of ground to gain. Both OracleVM and Sun xVM are based on the Xen open source hypervisor but are different implementations. Expect these to come together and for Sun’s virtual machine management (and enterprise management technology for that matter) to be sucked into Oracle Enterprise Manager. Oracle has taken a tough stance against any hypervisor other than their own and this will simply make them more stubborn in this regard.

What strategy should enterprise Infrastructure & operations leaders take? If you haven’t started shifting your Solaris workloads from SPARC to Intel, what are you waiting for? We recommend staying the course on your virtualization strategy. It shouldn’t take that much work for Oracle to unify xVM and OracleVM but both need lots of business development help to gain traction with the greater ecosystem surrounding VMware and Microsoft Hyper-V to justify your investment.

By James Staten

Check out James' research

Is a CMDB even possible?

This is one of the most frequently asked questions I get in my many interactions with people on the topic of CMDB. The short answer is, “A CMS is possible, but the common model of CMDB is not.” I have even been challenged on Twitter that CMDB is nothing more than an endless time sink (follow glennodonnell to see the threads). Sadly, this is a common perception that is fueled by the many failures resulting from an unrealistic view of CMDB as a monolithic database.

Herein lie the real gremlins of the CMDB and the primary reason Carlos Casanova and I set out to write The CMDB Imperative in late 2007. Yes, the book is now available from your favorite book retailer <wink!> (including Kindle <another wink!>)! The main problem with CMDB is the term itself. The right way to think about the configuration management database (CMDB) is not to think of it as a database at all. It is an organized collection of databases and other data sources that are very likely to be in multiple formats in multiple places in multiple tools from multiple vendors. Some may be in a home-grown Oracle database, some in an HP network management tool, some in an EMC storage tool, some in your HR database, etc.

A monolithic CMDB has several problems, most of them around the challenges of maintaining accurate contents. It might be good to highlight this issue with a little story.

My team and I built our first CMDB in 1986, although we didn’t call it a CMDB. We were too young and naïve and none of this had yet evolved to a reasonable point. It was more an asset database than a CMDB. It was a decent model of our newly complex environment of distributed Sun workstations and servers, but it was a grand failure. We didn’t capture the many relationships needed in a real CMDB, although that was not our fatal mistake. Our youthful naiveté led us to believe we could maintain its accuracy. It was all manual. We had no automated means to populate our CMDB to reconcile it with reality. We quickly abandoned it, but we did learn from that debacle.

Our “CMDB” failed because it was what many beleaguered CMDBs are today – what I like to call unified ambiguity. These CMDBs are consolidated repositories, but the contents are of dubious quality. If you can’t trust your CMDB, you are in trouble. Your decisions are driven by the CMDB. Good data yields good decisions. Bad data results in flawed decisions and sloppy execution. When you make the wrong decision, you need to go back and do it all over again, usually more slowly because you now also have to gather and verify the state of your relevant environment. In The CMDB Imperative, we point out other flaws of the monolithic model, but unified ambiguity is the greatest curse against the CMDB.

So, if the CMDB is no good, what is a CMS and how is it so much better? ITIL v3 introduced the concept of a configuration management system (CMS) that finally abandons the notion of a consolidated data repository. Instead, the CMS incorporates many CMDBs – what we should really call management data repositories (MDRs).

An MDR is a tightly focused information repository. It is not an attempt to build a model of the entire world. It maintains a view specific to its focused domain. You will have one for your network, one for your servers, maybe another for your virtual servers, one for your mainframe(s), one for your distributed applications, and so on. An MDR has two distinct benefits: it is fine-tuned for that domain and it is far easier to keep it accurate.

A network router has different attributes than a virtual server and a J2EE application is very different than a SAN, so it is best to have MDRs dedicated to each and tailored to reflect the precise model of each. A “one size fits all” model is a compromise, the proverbial jack of all trades and master of none. An MDR must be a master of one.

By restricting an MDR to a specific domain, we can keep it more accurate. Most notably, we can implement discovery technology to “learn the truth” about the domain. This has quickly become a key focal point of the CMS, especially with regard to practical solutions you can buy and implement today. With discovery, you can ensure a high degree of accuracy in this particular domain. Each MDR can be its own pocket of the truth. Pockets of the truth are far superior to unified ambiguity!

Here we get to the meat of the “What’s real?” element of the CMS versus what is yet to come. The whole vision of federating the MDRs into a cohesive CMS is still at least a year away, probably more for most of us. There are indeed actions we can take now and technologies we can buy now that will help us in our journey. My June 30, 2008 Forrester report A Federated CMDB Remains Distant, But Start Now, addressed this very issue. At the top of the realistic steps we can take is automated discovery. Other steps of course, are involved with planning. If you try to embark on a CMDB/CMS without the right planning, executive support, and staffing, I guarantee doom to your entire mission. Do not attempt this as a “lone wolf” or “skunk works” within your organization. Both are politically dangerous tactics, especially in economic times like these!

At nearly the same time ITIL v3 was published, a group of leading CMDB vendors collaborated on the release of the CMDBf specification. Its name, CMDB Federation Working Group, may not have been very original, but the work that came out of the CMDBf is profound. Some of the language is a bit different between CMDBf and ITIL v3, but the philosophies are perfectly aligned. CMDBf puts more meat on the bones of what ITIL v3 espouses, as it clearly defines the technical details of how tools will share their data.

ITIL v3 tells us that the data will exist in pockets. CMDB tells us how to link these pockets. In the ultimate view of federation, we don’t try to copy data from one MDR to another. Instead, we “point” to the data using metadata and web services. This is well defined in the CMDBf specification. As we navigate the data for the intended purpose, we jump from MDR to MDR and back as defined by abstraction models that represent the higher-level use case we are executing.

For example, an application will likely be an abstraction model that tells us how the various servers and other elements constitute that application. I show a highly simplified n-tier application example here. The application model contains several infrastructure elements and their relationships. We need not pull all of the data about each of these into a single point. The application model will link to the appropriate MDR(s) for the network devices, which hold the truth about those network devices. It will also link to the relevant server MDR(s), which contain the server truth. Others MDRs are included, but the abstraction that represents the application is relatively simple and concise. The means by which they are assembled gives us the full picture and therefore, the full value of what we need to do.

Is this really all possible? Absolutely! We need to wait for a few of the technologies to mature, however. Vendors are moving swiftly, but we will be well into 2010 by the time the various parts of the CMS will fit together. Even then, legacy tools will be a challenge, probably needing some custom federation adapters. Throughout this period, we will experience small steps forward, many of them already in progress. CMDBf support is already emerging from the major vendors. Others will follow.

We must also view these tools as merely enabling the processes we execute. Good process is still the number one missing link in the IT profession. The tools accelerate the process execution. You can do good things faster or do bad things faster. The choice is yours, but the answers are there if you play your cards right.

By Glenn O'Donnell

Check out Glenn's research.

The Open Cloud Manifesto

The Open Cloud Manifesto, backed by its thirty-six firms that signed on with its debut, outlines core value propositions, points out challenges, sets goals, and then lists several principles of what an open cloud should accomplish. Until now, there has been no real attempt to define or restrict the term or use of the term "cloud", but it’s hard to view this effort as highly credible when many of the early cloud leaders did not sign onto it. Most glaringly absent are Amazon, Google, Microsoft, and salesforce.com. Why aren’t all vendors signing onto this manifesto?

Well, one such reason given by Microsoft was their discomfort of being asked to sign the document "as is" without any chance for input. Forrester analyst Frank Gillett interviewed Microsoft and IBM shortly afterward and found out a more detailed story behind this disagreement:

• The "cloud" term is limiting, especially for meaningful mass communication since it currently encompasses so many services.
• The Manifesto’s idealism is worthy, but not a useful guide for strategy.
• The value of some cloud service offerings will come directly from being closed, not open.

For IT ops professionals the goal of the manifesto is a good one as no enterprise wants their applications or their data to be locked into any more proprietary platforms than we already have and clearly a set of extensions beyond the existing web services clouds leveraged today are warranted. But the timing of this may be a bit premature. The cloud market is very early in its development and vendors are innovating in both technology offerings and business models and until these settle into relatively consistent practices, standards simply cannot be set. However, this manifesto marks the first step towards the future of the cloud and defining what exactly the term would include or exclude.

IT Ops professionals should not sit idly by and let the vendor community define the standards and the offerings and determine where openness is warranted. Get involved by letting cloud vendors know where interoperability is most important to you and where you want better openness and APIs and where standardized interfaces make the most sense.

By James Staten

Check out James' research