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

And a few parting thoughts when considering a new backup solution, in general:

We strongly encourage customers to explore reference architecture design alternatives before choosing a specific product for deduplication. In most cases, backup architecture redesign is the best way to maximize re-use of existing backup assets and take full advantage of next generation backup technologies, such as VTL and deduplication. In addition, performing a vendor-neutral performance and sizing analysis for core and remote sites is the only way to properly plan for deduplication both from a technical and budgetary perspective.

-John Merryman, GlassHouse Service Director

a

Tape Elimination (VTL and encryption)

Many of our customers are modernizing backup architecture, with the goal of minimizing or even eliminating tape. Mitigating media loss risk, simplifying operations, and improving disaster recovery are key drivers for tape reduction in core and remote backup environments. Many customers are embracing VTL and deduplication/replication as an outright alternative to tape encryption. The typical reference architecture we develop in the field with mid-large enterprise customers still includes tape, yet repositions tape to store data of certain type and value, and for many customers significantly restricts the physical movement of offsite tape. Tape is being eliminated from remote site backups all together, given appropriate WAN bandwidth for replication of deduplicated data.

-John Merryman, GlassHouse Service Director

Archiving

Should backup and archive be the same service? The GlassHouse general position is ‘no’, however every environment faces need for long term retention of data, and in lieu of a true enterprise archiving platform, backup data retention is the only option for many enterprises. In general, we see tape playing a valuable role for long term retention of data, and most vtl/deduplication vendors tend to agree with this position. Operationally, backup and archiving should be logically segregated, with archives treated clearly as the exception than the rule with a clear distinction made between server archives (to backup environments) and true archives, such as those found in email or database archiving systems.

-John Merryman, GlassHouse Service Director

Data replication and DR solutions

The impact of disk based replication of deduplicated data has a profound impact on backup architectures and their role in disaster recovery. The traditional backup environment today uses offsite vaulting for tape, and disk or host based replication for more aggressive disaster recovery capabilities. The role of backup in disaster recovery can be significantly enhanced through any combination of backup software or hardware deduplication and replication schemes.

-John Merryman, GlassHouse Service Director

When I discuss storage with senior IT managers and executives, invariably topping the list of concerns – not surprisingly in this economic environment – is “cost”. There seems to be a sense that ever more precious budget dollars/pounds/euros/or shekels are not being invested as wisely or effectively as they should be. Surprisingly, there is often a lack of hard evidence of this inefficiency and this, in fact, only adds to their discomfort: executives who are called on to approve large storage purchases lack solid information on where the storage that they approve is going and how it’s being consumed. Call it fear of the unknown or perhaps an educated hunch based on experience, I would say that their concerns are well founded.

At its core, the problem with storage stems from the continuing high rates of data growth exacerbated by the fact that our traditionally accepted methods of storing and protecting this data are no longer as effective as they once were.

Picture and iceberg: every byte or GB of data that is created (above the surface) has a multiplier effect in terms of the storage on which it resides (lurking below the surface). If you want to think of this as overhead, you may do so, but to a large extent, much of the overhead is necessary. We have RAID protection that, depending on the method applied, increases storage requirements by 20-100%. We also may make snapshots, additional mirrors, or replicated copies of data that, again, depending on policies and requirements, may increase storage capacity needs several fold.

However, there is also increased consumption based on how we manage storage throughout its lifecycle. This is impacted significantly by not only policies and process, but also by the types of technology deployed in the infrastructure and the tools available to monitor and manage the environment – lack of visibility is a common complaint.

But wait – there’s more! Unlike other aspects of IT, storage is unique in that it is PERSISTANT. Once a byte of data is written, it is highly likely that it will be there forever, carrying all of the overhead just discussed and also multiplying in other ways, such as being backed up and archived.

This all adds up to lots of inefficiency and an underlying cost structure that for most isn’t sustainable. Unfortunately, often the knee-jerk reaction is to focus on technology. Yes, certainly newer technologies like thin provisioning and data deduplication can contribute to improved efficiency. But addressing the problem goes well beyond this: it requires seriously evaluating “business as usual” and applying a multi-pronged approach that includes accurate metrics to improve visibility and form the basis for a plan, a rethinking of allocation and demand management that encourages changed behavior regarding consumption, in combination with the intelligent application of technology. A more piecemeal approach will result in piecemeal results, and won’t ensure successful navigation around the iceberg.

-Jim Damoulakis, GlassHouse CTO

Continued from part 2 - click here to view

Now each consumer in this supply chain must be able to clearly and concisely articulate their requirements (demand) in service terms, not in technology requirements or technology specifications. This is one of the key differences between “techno centric” and “service centric” approach. The service catalog will provide service offerings expressed in service terms not in technology specifications.

This is because the service supplier is now solely responsible for designing technology solutions to supply the specified service offerings.

The service provider model talks about responding to and aligning with Business Needs. The Business Needs are very simply defined as “what the customer or consumer wants”. What we really mean by “business needs” for the Storage SP are the service needs required by the storage consumer.

How is demand placed on the various layers of the supply chain? The Business Unit will typically complete an SLRQ (Service Level Request Questionnaire) that has been carefully designed to capture all the information needed for each SP who may be involved in supplying the demand. It is important to note that each SP may also initiate a demand for services from the next lowest level in the supply chain.

Consumers at each level of the supply chain place demand on the next lower level. The Business Units use the SLRQ to place demand on the Application and DBA SPs, who then place demand on the Server SP, who in turn places a demand on the Storage SP.

The Business Units and the Application SP are the only customer/supplier relationship in the supply chain where an actual ITIL SLA rather than an OLA is used to govern the delivery of services to the “end user”, the Business Unit.

-Dick Benton, GlassHouse Principal Consultant

Continued from part 1 - click here to view

Now each consumer in this supply chain must be able to clearly and concisely articulate their requirements (demand) in service terms, not in technology requirements or technology specifications. This is one of the key differences between “techno centric” and “service centric” approach. The service catalog will provide service offerings expressed in service terms not in technology specifications.

This is because the service supplier is now solely responsible for designing technology solutions to supply the specified service offerings.

The service provider model talks about responding to and aligning with Business Needs. The Business Needs are very simply defined as “what the customer or consumer wants”. What we really mean by “business needs” for the Storage SP are the service needs required by the storage consumer.

How is demand placed on the various layers of the supply chain? The Business Unit will typically complete an SLRQ (Service Level Request Questionnaire) that has been carefully designed to capture all the information needed for each SP who may be involved in supplying the demand. It is important to note that each SP may also initiate a demand for services from the next lowest level in the supply chain.

Consumers at each level of the supply chain place demand on the next lower level. The Business Units use the SLRQ to place demand on the Application and DBA SPs, who then place demand on the Server SP, who in turn places a demand on the Storage SP.

The Business Units and the Application SP are the only customer/supplier relationship in the supply chain where an actual ITIL SLA rather than an OLA is used to govern the delivery of services to the “end user”, the Business Unit.

to be continued…

-Dick Benton, GlassHouse Principal Consultant

In a service provider model, we typically find a multi layered supply chain delivering services under ITIL OLAs to support a final deliverable to the end consumer under an ITIL SLA. The end consumer (or customer) is invariably the Business Unit but there are many internal consumers who also participate in the order and consumption of services within the IT supply chain. It is invariably these internal consumers who are the direct Storage Customer.

A customer is typically defined as the entity that places an order for consumption of goods or services in return for a payment of some kind. In the service provider model (SPM), this payment concept may exist only if the organization has adopted a charge back policy or has some other process to make the service selection subject to economic rationale. Thus it is more appropriate to use the term consumer rather than customer when identifying the entity that orders and consumes the services provided under the SPM

To satisfy the end consumer, typically the business unit, the service provider model calls for the supply of IT services from a supply chain of internal Service Providers (SPs) as illustrated in the following diagram

Each layer in the supply chain can place demand on the next lowest level in the supply chain. This demand is expressed in service terms and placed by way of an Order Fulfillment procedure that is supported by a Service Catalog of offerings. The selection process is often supported by some form of service level request questionnaire or dialog (SLRQ) to assist logical selection of the most appropriate service

The supply chain layer (Service Provider) that actually provides the services, is solely responsible for designing the technology architecture needed to deliver the selected services.

to be continued…

- Dick Benton, GlassHouse Principal Consultant

Continued from Fibre Channel over Ethernet (FCoE) part 1

New standards are being developed, which will achieve line-rate bandwidth with zero packet loss. This is being referred to a ‘lossless’ network which supports standards like:

• Priority Flow Control (IEEE 802.1Qbb)

• Congestion notification (IEEE 802.1Qau)

• Shortest path bridging (802.1aq)

• Link layer routing protocol (IETF – TRILL)

• Enhanced Transmission Selection (802.1Qaz)

These standards are referred to as Converged Enhanced Ethernet (CEE) or Fibre Channel over Convergence Enhanced Ethernet (FCoCEE).[T1]

In order to support converged Fibre Channel and IP on the same NIC, it requires a CNA card with either copper SFP+ cables or optical fiber cables. This will reduce costs by decreasing the number of NICs, as well as reducing management overhead. It allows management of a single network unit instead of two separate network infrastructures (IP and Fibre Channel); it will also decrease the power and cooling consumption. This will be handy in virtualization environments, and will allow leveraging advanced Ethernet networking capabilities such as QoS inside the Fibre Channel space.

Conclusion

FCoE is a compelling new technology that allows unified I/O in the data center. But before adopting the technology, make sure you understand it beyond the slogans and brochures. Evaluate the current state of your storage networking infrastructure and make the decision based on business requirements and not based on trends.

External Link:

http://video.computerworld.com/services/player/bcpid1351827287?bctid=1410385428

-Ronny Front, GlassHouse Senior Consultant