The separate tools used to manage the LAN, SAN, blade server connectivity, NICs and HBAs also contribute to data center management complexities. Often administrators can see only what is in their direct line of responsibility and don’t have the overall view of the entire network environment. Now, imagine if they could:

• Logically eliminate the management of multiple switching layers
• Apply policies and manage traffic across many physical switches as if they were one switch
• Scale network bandwidth without manual reconfiguration of switch ports and network policies
• Provide a single, customized view of network status available to server, network, and storage administrators

Ethernet data center bridging and its new Ethernet fabric allows organizations to broaden the sphere of application mobility, provide VM awareness, and optimize server resources for applications just as it improves networking for storage.

Using this new data center bridging Ethernet fabric, organizations can simplify network architecture, more rapidly scale their networks, and significantly reduce data center management overhead. This is still a work in progress, but here at ASG at least, we see converged enterprise DCB Ethernet networks as the future, and we’re focused on helping companies get there as easily as possible.

Reliability

Despite trends in NAS virtualization and other appliance-based virtualization, nothing beats the rock solid reliability of Hitachi’s VSP—probably its top feature. Any growing enterprise with mission critical data should take a close look at the VSP for this reason. The VSP’s unique controller architecture can handle multiple cascading controller failures without going down, with very limited performance degradation. Software upgrades can be done without server reboots, which makes it the least disruptive to applications during SW upgrades.

One of our clients recently implemented the Hitachi VSP for this very feature. You can read about the full project in the CRN article, Denali Deploys Virtual Desktops To Give Doctors More Time With Patients. ASG handled the Hitachi VSP portion of this project. Here’s a quick summary from our own Pacific Northwest Regional Architect, Grant Loveridge:

“Seattle Children’s Hospital was having issues with their virtual desktop infrastructure (VDI) system going down intermittently, and VDI plays a very important role at Seattle Children’s Hospital.  Doctors and nurses rely on certain information to make critical decisions about patient care, etc.  In short, the system just can’t go down! In the process of rolling out their VDI deployment, the customer quickly realized their infrastructure was not robust enough. There were some concerns about the backend storage not being able to handle the demands and patient information not being available to the hospital staff.  Plus, the hospital operates 24 x 7, which means maintenance windows are very difficult to schedule.”

“The customer purchased the VSP to provide the reliability and scalability they needed—with just enough capacity to support the VDI pilot. The customer was able to get started with the VSP at an affordable level, using emergency funding.  All upgrades were accomplished with no downtime to users or applications. They have since scaled the system to support many more users and applications.  They also purchased a second VSP for disaster recovery and are using Hitachi Universal Replicator between sites—a project that is now underway. All in all, the customer is very happy with the VSP solution.”

With these benefits, I imagine the popularity of the Hitachi VSP can only continue to grow. I’ll be sure to keep you updated on its progress. If you have any questions about the VSP or our other Hitachi solutions, feel free to contact us.

About the Author
Anthony Sayre is an Advanced Product Specialist at ASG and our resident expert for Hitachi Data Systems solutions. You can contact him at asayre (at) virtual.com.

A quiet storm has been brewing at Advanced Systems Group. The Hitachi Data Systems Virtual Storage Platform (VSP), Hitachi’s flagship enterprise storage solution, has been quietly taking the data center world by storm. The Hitachi VSP can only be described as a smash hit since its introduction a year ago. With a full sales pipeline and 24 units sold or in process of implementation (that’s a lot—trust me), the VSP is fulfilling mid-range to enterprise needs for mission critical primary storage, disaster recovery, virtual desktop infrastructure, public and private cloud, archival and more.

We can’t sell VSP solutions fast enough, for two reasons: the scale/consolidation abilities of the VSP and its unmatched reliability. Today, I’ll just discuss the first of these features—scale/consolidation.

Scale/consolidation

The VSP can be a diskless storage virtualization engine, and/or it can scale up to over 2000 2.5” disk drives. Plus, it can virtualize up to 255 petabytes (!) of external storage, which is key to Hitachi’s ability to scale and consolidate older legacy systems under one management tool. Here at ASG, we’re witnessing first-hand just how powerful the scale/consolidation story can be. Here’s an example:

One of our clients, a Colorado based e-marketing company, provides many cloud services to fortune 500 companies around the world. As new projects for their clients come up, they often need to move data on the fly from lower to higher storage tiers, run the project, and then move the data back. Without Hitachi’s storage virtualization features like tiered storage management, this wouldn’t be possible without hiring many more IT storage administrators, taking systems down, migrating data, and booting them back up again—a nightmarish task for any data center manager, but especially in this company’s multiple petabyte data center.

ASG engineers architected a VSP solution that’s in the implementation process now, and will consolidate the customer’s 1.3PB of storage spread across 111 devices to 1.6PB across just 11(!) devices in a streamlined virtualized storage environment with automated tiering and DR. This wouldn’t have been possible without the VSP’s consolidation and massive scaling abilities.

In my next post, I’ll discuss the second of the VSP’s most desired features—its outstanding reliability. In the mean time, feel free to share your own Hitachi success story in the comments below. Feel free to contact me if you’d like to learn more about the VSP or our other Hitachi solutions.

About the Author
Anthony Sayre is an Advanced Product Specialist at ASG and our resident expert for Hitachi Data Systems solutions. You can contact him at asayre (at) virtual.com.

Over the course of our 30 years in business, we’ve helped many companies with their data center relocations and migrations, and we’ve developed a four step methodology that can help reduce your stress (Although, notice we didn’t say ‘eliminate’).

1. Discovery and Data Collection:

• Startup servers and apply new system information (e.g., IP addresses, name etc).
• Assist in verification of properly working systems and applications.
• Track, document, and scale data to be replicated.
• Track and document changes to replicated data.

2. Analysis and Design:

• Recommend an appropriate amount of bandwidth to maintain replication of applications.
• Ensure equivalent amount of storage is available at new site.
• Establish IP connection between the two sites.
• Document the external facing IP addresses at old and new sites.

3. Planning and Risk Management:

• Install and implement replication (VVR, SNDR, HORC).
• Begin replication and continue asynchronous replication until fully replicated.
• Prepare DNS propagation within the WWW / internal.
• Switch to synchronous replication to ensure transaction integrity.

4. Complete Implementation:

• Complete the switch over:
  • Shutdown applications at old site.
  • Suspend Replication.
  • Propagate DNS entries to WWW / internal.
  • Startup applications at new site.
  • Test applications using external and internal connection.
  • Fail-back to old site, if required.
  • Restore hardware/data if applicable.
• Manage the entire project, including the formal project plan and coordination of all parties.

Data center relocations and migrations always pose a serious threat of disruptions or data loss that can jeopardize your crucial business operations. If you’re serious about your business, then disruptions and data loss are unacceptable risks. While these four steps can certainly help you plan your data center relocation, you still may want to seriously consider the help of a data center relocation specialist skilled in industry best practices and proven methodologies to ensure a successful move.

Here’s a link to a more detailed overview of our data center relocation and migration methodology.

In general, server‐to‐storage applications are intolerant of extended delays, technically referred to as nondeterministic I/O latencies. Many server workloads expect a response to data requests from the networked storage devices in the 1‐10 millisecond range, and many servers are configured to assume that I/O operations have been lost in the case of lengthy delays, such as sixty seconds without a response. That will often cause the application to cease execution. Similarly, these same applications are simply intolerant of dropped packets that trigger resends and cause I/O queue backups that result in the same delayed response times and subsequent application termination as described.

For this reason, Fiber Channel (FC) is the prevailing networking protocol for server‐to‐storage connectivity today. While FC can be deployed in point‐to‐point mode, as in direct attached storage (DAS), the majority of FC deployments support storage area networks (SANs) that enable resource sharing across a larger and more disparate set of server and storage assets than the direct connect model  typically allows.

FC deployments today run over a dedicated network using dedicated single‐use networking equipment components; typically Host Bus Adapters (HBAs) that provide server‐to‐storage connectivity, specialized FC switches and directors, and special cabling. These require specialized training, experience, and tools to set up and manage. FC today offers speeds up to 8 Gigabits per second (Gbs), enabling it to deliver low‐latency response at relatively high‐performance levels. This is sufficient for now to meet the needs of most of the I/O intensive workloads found in today’s data center.

Looking ahead, FC may have trouble matching Ethernet performance going forward. While 16Gbs FC is coming, Ethernet currently provides 10Gbs performance and will be moving to 40Gbs shortly.

Maybe more significant is the economics of FC today. FC components are more expensive, and the lack of QoS capability forces over‐provisioning of FC network resources to address peak consumption period, a wasteful and inefficient practice, as is the case with Ethernet.

By comparison, a converged network reduces cost by eliminating the number of host adapters by combining NIC and HBA functions into one adapter and eliminating redundant infrastructure cost by using one cable infrastructure to support both storage and IP traffic.

Ethernet also supports storage, mainly through iSCSI, the server‐to‐storage protocol designed to transport SCSI block storage commands over Ethernet using TCP/IP. iSCSI was designed to take advantage of all the manageability, ease‐of‐use, high availability, and guaranteed delivery mechanisms provided by TCP/IP while providing a seamless path from 1Gbs Ethernet to 10Gbs Ethernet and beyond. Here at Advanced Systems Group, we’ve seen an uptick in 10Gbs iSCSI deployment over the past 18 months.

By using Ethernet as its underlying transport layer, iSCSI addresses two key data center manager issues—1) reducing the cost and 2) reducing the complexity of deploying FC networks. The first issue—cost—is addressed by the fact that iSCSI can run over existing Ethernet networks and can use software initiators that consume server cycles and memory atop existing Ethernet NICs or LOM (LAN on Motherboard) chips instead of requiring dedicated and relatively expensive Host Bus Adaptors to provide connectivity.

The second issue—complexity—is addressed by the sheer ubiquity of Ethernet network management competency and toolsets that exist today. Most organizations have no trouble finding sufficiently skilled people to handle their basic Ethernet needs.

iSCSI adoption is growing and has found considerable acceptance in small and midsize enterprises, as well as finding adoption for cost-sensitive applications within larger enterprises. Data center managers with time‐sensitive applications, such as OLTP, or Monte Carlo Portfolio Analysis, have not jumped on the iSCSI bandwagon due to uncertainty about the latency resulting from iSCSI’s dependency on an Ethernet layer that can result in dropped packets and extended I/O latencies in lossy environments. However, as 10Gbs Ethernet makes the possibility of converged networking more feasible, all recognize a new need for finer‐grained QoS mechanisms that can address I/O latency and lossy-ness.

Those hopes ride mainly on Data Center Bridging. iSCSI leverages TCP/IP to mitigate the lossy uncertainty of Ethernet by providing better delivery mechanisms. While this currently is addressed through network simplification (appropriate provisioning, minimal router hops, VLANs, etc.), the introduction of Data Center Bridging will enable iSCSI to take full advantage of the lossless nature and deterministic latency of Data Center Bridging-enabled Ethernet networks. In addition, the finer grained QoS capabilities provided by Data Center Bridging will better enable iSCSI, as well as other Ethernet-based storage protocols, in the movement toward converged networking environments.

Data Center Bridging enhancements to Ethernet networks also enable Fibre Channel over Ethernet (FCoE), a new protocol specification developed in the INCITS T11 committee. FCoE will allow FC commands to be transmitted natively over Data Center Bridging-enabled 10Gbs Ethernet networks. FCoE specifies the mechanism for encapsulating FC frames within Ethernet frames and is targeted at data center SANs. As a result, it preserves the capital investment and operational expertise of existing deployments of Fibre Channel SANs while allowing them to coexist with a converged infrastructure. The FCoE specification was ratified in June 2009.

The intrinsic improvements in Data Center Bridging Ethernet for storage deployments (lossless, QoS, low‐latency) enables data center managers to finally plan for a singular converged Ethernet-based network for all data center communications including user‐to-server, server–to‐server and server‐to‐storage networks. By deploying a converged network, data center managers will gain the broad benefits previously described:

• Cost reduction through the use of common components between endpoints (servers, storage, etc.) and switches
• Ability to leverage a common management platform, personnel, knowledge and training across the data center
• Platform with a future that today looks to provide a performance upgrade path to 100Gbs
• Reduction in costs resulting from less need for dedicated single‐use components such as FC-only HBAs and switches.

We’ll next discuss scaling virtual server environments and application mobility, so check back soon, and let us know what you think!

Ethernet utilizes upper level layer protocols (TCP) to manage end‐to‐end data delivery and integrity. When the amount of data entering the network exceeds network capacity, Ethernet networks become over‐subscribed and will drop data packets in certain circumstances, which results in lost data.

Fibre Channel (FC), by comparison, provides a buffer‐to‐buffer credit that ensures packets will not be dropped due to congestion in the network, making it lossless. Ethernet can be made lossless only by adopting higher level protocols such as TCP/IP, which have adapted to the intent of IEEE 802-based networks by incorporating end‐to‐end congestion avoidance and flow control algorithms. Ethernet is an 802-based network.

To deliver traffic differentiation and QoS with Ethernet, the existing IEEE Ethernet 802.1p/Q standards provide classification of traffic flows with 3-bit tagging. Network equipment devices (like bridges and routers) use this classification to put different classes of traffic into different queues, while the standard specifies strict priority scheduling of these queues. This allows higher priority traffic to be serviced before the lower priority queues, thus achieving lower latency and also lower drop probability for priority traffic. However, this also creates unfairness issues for other queues because higher priority queues use more bandwidth, effectively starving the lower priority queues. Although the standard does permit the use of other scheduling algorithms, the behavior isn’t specified—which means no single implementation exists, producing interoperability issues.

Enter Data Center Bridging, an architectural extension designed to improve and expand the role of Ethernet in the data center. Data center bridging allows organizations to logically manage networks end-to-end with QoS through four capabilities:

1. Congestion Notification (CN)—provides end-to-end congestion management
2. Priority‐based Flow Control (PFC)—provides a link-level, flow-control mechanism
3. Enhanced Transmission Selection (ETS)—provides a common management framework
4. Discovery and capability exchange protocol—conveys the capabilities and configuration of the above features to ensure a consistent configuration across the network

Data Center Bridging networks can be characterized by limited bandwidth‐delay and limited hop‐count. When multiple traffic types are transmitted over a single link, there needs to be assurance that each traffic type obtains the bandwidth that has been allocated for it, while at the same time, conditionally restraining any traffic types from exceeding their allocated bandwidth.

When multiple traffic types—LAN, SAN, IPC—are consolidated onto a single converged link, there is no inherent prioritization of traffic between these types; however, each traffic type needs to maintain its current usage model of a single interface with multiple traffic classes supported. Each type also needs to maintain its bandwidth allocations for a given virtual interface (VI), independent of traffic on other VIs. Data Center Bridging physical links provide multiple virtual interfaces for different traffic types.

The new features and capabilities of Data Center Bridging will need to operate within and across multiple network domains with varying configurations. Achieving interoperability across these environments requires that link partners exchange information about their capabilities and configuration and then select and accept feature configurations with their link partners. This is accomplished through the four capabilities (CN, PFC, ETS, Discovery and Exchange) noted above.

These capabilities, in conjunction with other Data Center Bridging technologies, enable support for higher layer protocols that are loss-sensitive while not affecting the operation of traditional LAN protocols utilizing other priorities. Converged enterprise data center networks, however, must do more than provide QoS for mixed traffic. Data center networks must address the needs of networked storage and the scaling of virtual server networks.

That’s what we’ll discuss in our next blog, so be sure to come back!

Flexible as it is, however, Ethernet does not do all things for all purposes. As a result, organizations have turned to other networking protocols for other tasks, especially where the loss of data in the form of dropped packets can pose a serious problem. A related problem resulting from this is the need of organizations to maintain and support multiple networking protocols. This is costly and inefficient.

Ethernet also presents challenges when organizations are faced with managing multi-tier networks. In addition, it does not handle server virtualization particularly well or the mobility of the resulting virtual machines. In short, Ethernet is starting to show its age as networking equipment evolves into the highly virtualized enterprise data centers of the future.

Probably the biggest complaint with Ethernet comes from its lack of support for quality of service (QoS). QoS refers to the ability to create and manage networks to deliver different levels of service for different types of traffic. It is possible with Ethernet to achieve some level of QoS, but native Ethernet gives all classes and/or types of traffic equal access to bandwidth.

Not all types of traffic, however, are of equal importance to the organization. Ethernet QoS does not go far enough in distinguishing between types or classes of traffic. A telephony application or customer support agent might have the same priority as a mission critical application or as a high priority file transfer. Lacking this level of QoS, data center managers must over-provision network bandwidth for peak loads, endure user complaints during these periods, or manage traffic prioritization at the source side by limiting the amount of non-priority traffic entering the network (and nobody likes finding network access blocked).

QoS also refers to the need for loss-less data transmission, particularly in regard to storage networking. Networks lose data when they get over-saturated with traffic, which forces buffers to overflow and data packets to be dropped. Ethernet tries to compensate by resending the dropped data packets but that often only exacerbates the problem. Although these ‘resends’ happen quickly (25 milliseconds) they contribute to the lack of consistent response times. This characteristic limits Ethernet’s ability to service applications that are either response time sensitive, such as customer facing online transaction processing systems (OLTP) or applications that are dependent on isochronous or near isochronous communications, such as video streaming over distance.

Ethernet also needs more and better management tools to give administrators a way to see what is happening over the network and make adjustments to improve QoS. Ethernet tools today tend to be the basic tools that come with the networking devices.

So, the question arises: How can Ethernet be made ready for today’s increasingly virtualized data centers? Our next blog post on the subject will start answering this question by introducing Data Center Bridging.

I’ve read a lot recently about Cisco’s single-vendor network strategy and also the subsequent report issued by Gartner that slams this concept– Gartner Slams Cisco’s Single-Vendor Network Vision.

Here’s an excerpt (emphasis is mine):

One surprising benefit from our investigation was that for most organizations interviewed, the

1.  Streamline storage and data management with deduplication and consolidation

2.  Search out and prepare with disaster recover planning

3.  Reduce your data center hardware, power and IT footprint costs with virtualization technology

4.  Choose with applications or data should be moved to cloud computing solutions

In this blog, we thought it’d be good to complete the loop and share our experience with a relocation and consolidation effort we did for Hydro Gulf of Mexico and StatOil.

Hydro Gulf of Mexico approached Advanced Systems Group to relocate their legacy data center to a new facility in downtown Houston. Mid-way through the development of the move plan however, Hydro GOM merged with another company, StatOil.

As a result of the merger, Hydro GOM and our team reconfigured the partially-completed relocation plans to include the data center assets from StatOil. These combined assets were to be located the StatOil City West facility in Houston, TX—in a location built especially for the new data center.

In the weeks prior to the move, our Consulting Services team fully documented the new environment. Throughout the design and implementation of the new facility, ASG compiled and provided a comprehensive source of data center information including layouts and floor plans, server and storage documentation, as well as network, legacy, power and HVAC information.

Once the new facility was finished, our Consulting Services team successfully completed the data center relocation project on-schedule, with no unexpected downtime and no major hardware failures or equipment damage. Our team and the newly-established StatOil-Hydro IT team collaborated successfully to handle all issues that arose as they moved the Hydro GOM IT assets over the course of just three weekends.

While we can take credit for the data center move, the real hero of the story is the proven, structured methodology that guided our relocation.

In case you missed the first three entries in this Data Center Relocation series:

Part 1:  A Proven Methodology is Critical for Success

Part 2:  Discovery & Data Collection, Analysis & Design

Part 3:  Planning & Risk Management, Complete Implementation