Is CLARiiON a 5×9s Box?

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

Wireless Mobility Security by Robbie Higgins

Moving the bottleneck by John Merryman

So the cloud hype train rolls on and we’re all constantly being told how the cloud can help cut costs, increase agility and reduce time to market. The cloud certainly has its advantages and for SMB’s and start ups with little or no ‘IT baggage’ the cloud is an attractive proposition. However, for most enterprises a transition to cloud computing is not something that should be undertaken lightly. Today, a large number of cloud solutions exist in the market place, providing great choice; but this leads to a complex decision making process. Broadly, three core deployment models exist – Infrastructure as a Service (IaaS), Platform as a Service (Paas) and Software as a Service SaaS. These models are typically provided from an internal (private) cloud, external (public) cloud or both. For more on cloud definitions and deployment models, I recommend reading this article by the National Institute of Standards and Technology (NIST).

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