In today’s market place, we typically run into two philosophies. Its either a one throat to choke philosophy that seeks advantage through leverage of one point of contact and negotiation, or it’s a choose two and play them off against each other philosophy. Sometimes we find the operationally focused organization with a multi vendor approach driven by the illusion that happiness in IT comes from highly configured fit for purpose solutions.  Even though end user needs are rarely known empirically.

Personally, I think the key here is to ensure the reference architecture does not contain any defacto or hidden lock-in. Some examples of how lock-in can occur include appliance solutions (like backup and dedup), virtualization that is not frame based, and encryption enforced over all disk based storage.

If there are no impediments to data migration, then moving to another vendor is not only doable but should actually be a defined process that is tested once a year (like disaster recovery) just to make sure no vendor has secretly captured the storage jewels.

I’d recommend closely constraining the number of suppliers as part of an official policy to minimize the technologies that need investment and training in administrative support. That’s where the real expense lies. People costs go up and up, hardware costs go down and down.

Administrative workload (cost) is calculated by the number of technologies that need managing times the number of activities occurring in provisioning and alerts, times the complexity of the environment.

The ability to minimize administrative support should always trump lower hardware prices. It should also trump the illusion of business satisfaction that comes from allegedly fit for purpose solutions where each tier has a highly engineered unique technology, albeit to meet a “business need that is more often presumed than defined with specific attributes. The strategic view has to place inordinate emphasis on automated monitoring, provisioning and management. As we progress and listen to the many stakeholders involved and try to capture their interests and needs in empirical terms, its critical to think carefully and objectively to identify the real problem that we are trying to solve, and then to make sure, through due diligence, that the solution does not cause unintended consequences – like vendor lock-in. Saving pennies in hardware can costs multiple dollars in on going administrative expense.

By Dick Benton, GlassHouse Principal Consultant

The following examples expand each step in multiplexing backups to illustrate how all tape drive devices should be used.

1. Each example shows 5 Clients, each client having 4 possible jobs streams
2. Each stream runs at 5 MB/Sec
3. Tape device can handle 80MB/Sec

Figure A
The example in Figure A shows the consecutive approach currently deployed causing a cascading slow down affect.  There is simply not enough data being presented to the tape drive for it to stream effectively.

Figure B
The example in Figure B is an improvement as each client can send a backup to the tape drive, shortening the overall backup window, and utilizing the tape drive at 20MB/Sec.

Figure C
The examples in Figure C and D show the possible configuration should the specific client not be able to handle multiple data streams or if everything could be sent to the tape drive at the same time.  The bottom right needs 100MB/Sec, but with only a slight compression ratio this scenario would keep

Figure D
the tape drive streaming at an optimized rate.  If the original example had each stream taking one hour, the backup window would need to be 20 hours to complete; where as the final example could finish all backups in only 1 hour.

Often I find myself engaged in projects where I am asked to document current storage tiers and develop future state tiers of storage. In characterizing each tier, performance and availability are among the key metrics that define each tier. There is the perception with some IT professionals that CLARiiON is a 5×9s storage platform. It seems that the justification of availability classification depends on who you talk to.

If you look through EMC’s literature, they seem to reference perceived availability based on their customer’s uptime, not as a design spec. This leaves us a subjective sampling of configurations that EMC would undoubtedly pick only the most redundant and stable.

So I can take a couple of Iomega USB drives, and with the right software and configuration, I could also meet 5×9s over a 1yr time period. This doesn’t mean that one of those USB drives meets a 5×9s design spec. Ok, maybe I’m overreaching a bit, but you get my point.

Symmetrix traditionally has been a closed architecture that requires EMC SEs and SAs to configure, update, make bin file and firmware updates. In the past there were a lot more changes on a Symm that required downtime than today. That being said, they’ve always touted the Symm as being 5×9s. Is the criterion for 5×9s a sliding metric? So I’m not even sure scheduled downtime should be considered in 5×9s.

The CLARiiON on the other hand is more open to customer configuration, reconfiguration etc… This makes it subject to hardware downtime. I know, this is a sweeping statement but I have Murphy’s Law behind me. The fact that a Symm requires EMC engineers to schedule and make critical changes kind of reminds me of the seatbelt in my Subaru. It is !!SO!! annoying that you have no choice but to put it on to stop the “fasten your seatbelt” alarm. Seatbelts are the one thing that protects passengers most in an accident, and most affects the car’s safety rating.

So there are 3 ways I hear people referring to uptime or availability

• Perceived availability - Metric driven by field performance
• Downtime for maintenance - I disagree with this one. This sound more to me like serviceability rather than availability
• Unplanned downtime - Influenced (reduced) by redundancy in architecture. I think this is the real metric that should define availability - 4×9s vs. 5×9s

So, I’m inclined to say that the CX-3 with active passive controllers would not be 5×9s but the CX-4 would. I would only consider chassis redundancy in the CX or DMX availability metric, so just up to the controller. This would not include redundant FA or host paths. As long as there are two controllers with two active/active paths to the SAN, I’d consider it 5×9s. After that it’s up to the SAN to provide redundancy to the host. I would also not include RAID configuration in this metric.

By James Brissenden, GlassHouse Senior Consultant, Storage and Data Protection

Whichever cloud deployment model route an organisation decides to take, it needs to decide whether it wants to use a private or a public cloud, or even a combination of both. For this decision, there are lots of factors to take into account. Focussing predominantly on IaaS, below I highlight some of the factors that are likely to prohibit enterprises from taking advantage of the two main cloud types and a potential solution to those challenges.

The Public Cloud
In the IaaS space, the public cloud lends itself heavily to the SMB and start-up market because of smaller user numbers, fewer SLA’s, off the shelf applications and only basic security compliance needs. However, for medium to large enterprises, apart from SaaS, the public ‘multi-tenant’ cloud is seen as too high a risk for the majority of their systems for the following reasons:

· Security and regulatory compliance
· Lack of enterprise grade features such as DR and backup
· Lack of performance based SLAs
· Complex transitions and migration paths
· Lack of standards (portability)
· Data versus server locations
· Reliability.

Although the public cloud is generally unsuitable for enterprise production systems, there is no doubt it can be an appealing proposition for test and development environments. This is where provisioning can be achieved in seconds, security compliance is often less of an issue and the ability to scale down as well as up is commercially very attractive.

The Private Cloud
So if enterprises aren’t moving their production systems into the public cloud, how can they take advantage of the commercial and operational benefits that cloud computing promises to deliver? There has been a lot of talk over the last 12 months about the ‘private cloud’ where enterprises essentially look to introduce cloud methodologies into their own IT organisation. Unfortunately more often than not, virtualisation is being confused with cloud computing when actually virtualisation should only be seen as one of enablers for cloud.

At the recent International Cloud Computing Conference And Expo in Santa Clara, US, a number of large enterprises including the CIA presented on their approach to creating a private cloud and the challenges they faced along the way. The same underlying message came from all speakers – developing a private cloud takes time, significant investment and requires high levels of automation in order to achieve the required ROI. Some of the other challenges that can be expected are listed below:

· Initial CAPEX and ongoing infrastructure refresh
· Buy in at all levels
· Extensive planning
· High levels of automation
· Significant operational investment
· Complex tool and platform selection
· Limited in-house skills and time.

In the case of the CIA, it has the size of IT infrastructure that enables them to provide the economies of scale associated with cloud computing, whilst its strict security requirements meant its only option was to develop a private cloud.

The Virtual Private Cloud……..or why not Federate!
It would seem for most enterprises the IaaS Public cloud is still too immature and the initial capital/operational expenditure and time required to develop a true Private cloud potentially outweighs the required ROI. It’s not all bad news however, many hosting providers and Telco’s are bringing enterprise grade Virtual Private Cloud offerings to market. These offerings place the burden of Capex and Opex onto the service provider but provide the end user with utility computing aligned to needs of the enterprise.

In reality there is no one solution that fits all. Over the next few years more and more organisations will adopt a federated model, taking advantage of SaaS out of the Public cloud and IaaS from virtual private clouds

-Tom Brand, GlassHouse Technologies (UK) Virtualisation Practice Lead

The understanding of ‘actual business needs’ and impact of loss can be determined through a Business Impact Analysis (BIA). This identifies how much downtime you can actually afford and therefore, what level of protection you can ‘get away with’. The amount of downtime an organisation can ‘really afford’ is directly related to the financial, legal or public relations impact an application has on the organisation in the event of its unavailability. During the BIA a pain point is established whereby the impact of the application unavailability significantly spikes. This will provide the time key which identifies the amount of downtime your organisation can afford.

These well known metrics are the Recovery Point Objective (RPO) and Recovery Time Objective (RTO), both of which have a direct impact on the amount of investment it takes to protect the application. The more aggressive these metrics are, the more expensive the infrastructure required to protect them. Getting this impact versus cost balance right is one of the biggest challenges facing organisations when implementing and maintaining DR capability.

Another challenge for businesses creating a DR strategy is that they have to decipher the tangible and intangible impacting factors and deal with emotive and unrealistic views on the impact of applications. For example, human nature dictates that ‘my’ application is the most important and so requires the highest level of protection. The consequence of that is huge expenditure required to ensure minimal downtime for applications that do not have the business impact to warrant such investment.

Until recently the complexity of determining the impacting factors has played a significant role in DR being reserved for only the most critical applications. Now, technological enhancements have meant the cost of delivering DR and recovery objectives has become cheaper and more commonplace, but effective understanding of application unavailability remains, at best, confusing.

A DR strategy is paramount for any organisation that operationally or legally relies on its applications and the information they hold. Without one the interruption of applications could spell disaster for you personally and or your organisation. Getting the balance right for downtime versus the level of protection you could get away with will result in an effective DR strategy that matches the value of the application to the cost of the infrastructure to protect it.

-Simon Johnson, GlassHouse Technologies (UK) Disaster Recovery Practice Lead

Recovery Time Objective (RTO) and Recovery Point Objective (RPO) are key measurements an IT manager needs to make the business aware of and provision for downtime accordingly. Both are recovery metrics that are calculated in time which provide quantifiable figures used to understand the tolerance levels of the business for application downtime and data loss.

RTO measures the maximum amount of time that is needed to recover from disruption and for the business to be operational again. The more aggressive your RTO, the shorter the critical time period to restore the system to normal functioning. This, inevitably means more financial investment is required in high availability infrastructure, but perhaps a small price to pay in the long run if something does go wrong. There are many technology options to consider including various clusters or complete redundant infrastructure and data replication on or offsite.

The RPO looks at the maximum amount of data loss acceptable in the event of a disruption. A business will ask itself “how much can we afford to lose”. For example, if there is a nightly backup at 21:00 and the system fails at 07:30 the following day, the system will have lost all data modifications since the backup at 21:00 the previous night. The question is – is that loss acceptable to the business?

Like RTO, the more aggressive the RPO, the greater the financial investment in infrastructure is required to meet the objective in a shorter period of time.

Some businesses - or areas within a business - may not be able to tolerate RTOs and RPOs of any longer than a few hours, while others may be able survive downtime for periods of, say a week with minimal impact. These requirements can normally be determined by the Service Level Agreements (SLAs).

For years businesses and their IT departments have struggled to understand and communicate effectively with each other, resulting in either significant under or over investment in both operational and disaster recovery application protection. Accurate RPO and RTO metrics have helped bridge this gap and, combined with business impact analysis, facilitate the alignment of applications to correct data protection levels and generate the accurate levels of investment to protect data.

SLAs are unachievable unless a business has the capabilities to deliver them. Organisations need to understand how and where data protection is delivered in order to optimise operations and meet the SLAs. Although they typically play significant roles, backups, snap shots and mirrors do not solely deliver RTOs and RPOs. Many levels of resilience throughout the IT supply chain combine to deliver recovery capabilities. These must all be accurately measured to generate the RPOs and RTOs. These quantifiable objectives translate requirements into tangible metrics which facilitate the selection of infrastructure to enable effective achievement of the SLAs, even in an unforeseen disaster situation.

-Simon Johnson, GlassHouse Technologies (UK) Disaster Recovery Practice Lead

A POC is typically a partial and often standalone solution used to establish that a concept or system satisfies some aspect of the requirements for the complete solution. The proof of concept implementation will not affect business operational data although it may integrate with existing business systems to some extent. In many environments pilots are actually more like POCs, but unfortunately the pressure to reduce cost and rapidly deliver new services has forced the POC infrastructure to become integrated with production bypassing the wider scope of planning that should be undertaken.

The purpose of a pilot project is to test, usually in a production environment, whether the system is working as it was designed while limiting business exposure. The transition from running a pilot to virtualising the wider environment shouldn’t be a leap of faith because sufficient design, development and planning should have been undertaken, and here lies another barrier. The design and planning required for the pilot should in effect be treated exactly the same as deploying the production environment. When a successful pilot has been completed, more often than not, it will simply be rebadged as production and expand accordingly.

At a high level, technology and operations are both key aspects that need to be planned and tested carefully in order to ensure the transition from pilot to production is a strategic success. Virtualisation pilots often tend to be very technology orientated when, in fact, there should be just as much focus on the operational elements associated with successfully managing the virtual infrastructure. These operational processes, such as change management, capacity planning, virtual machine (VM) lifecycle management and chargeback, have to be in place during the pilot and have the ability to scale into production. From a technology point of view, organisations must look beyond the hypervisor and address all the components of the infrastructure that virtualisation has an impact on; such as networks, backup, storage and disaster recovery. Many pilots simply test the smaller, easy to virtualise, candidates and only focus on performance at the application and operating system layer which often produces unrealistic results.

Organisations must have test strategies that include the full range of potential configurations. This will ensure the infrastructure has the capacity to scale in order to meet the demands of larger workloads as and when they are virtualised. The classic example of this being storage input/output, where cheaper storage technologies are implemented and VMs perform as expected during the pilot but performance can decline significantly once the infrastructure is loaded or VMs with heavier workloads are introduced.

With an operational strategy and ‘bigger picture’ approach to virtualisation technology planning organisations won’t need to making a leap of faith, they can just cross the bridge to a better place.

-Tom Brand, GlassHouse Technologies (UK) Practice Lead