Data centers

02:14 PM
Joe Onisick
Joe Onisick
Commentary
50%
50%
Repost This

Better Data Center Standardization Through Pod Architecture Design

The Frankenstein method of disparate systems in the data center can impede expansion and the march toward the private cloud. Pod architecture design can offer better standardization and tighter integration. Learn more about the method.

The traditional piecemeal method of data center hardware acquisition is inefficient, error-prone and costly to maintain. Moving the data center forward toward private cloud architectures requires new thinking, planning and standardization. One proven method for this is pod architecture design.

In this sense, a pod is a set of define compute, network and storage resources. Pods can be designed with expandability options for compute and storage, or can be fixed based on a set compute capacity. Overall, pod designs provide tighter integration and better standardization across the infrastructure board.

One of the key advantages of pod architecture is the tight integration among components. Historically, IT infrastructure has been purchased in disparate refresh cycles and chosen by separate teams. This leads to compatibility complications and, potentially, sub-optimal designs used as workarounds. Designing these solutions with a holistic approach allows feature sets to be tightly coupled, enabling maximum value from the infrastructure as a whole.

Another major benefit is the operational cost savings gained from the standardization. Using a pod infrastructure as your building block for the data center allows your IT staff to focus on one set of hardware/software components. This focus will increase the depth of understanding possible, as well as reduce the learning curve.

The core components of a pod architecture are compute, network and storage. Additionally, security appliances (virtual or physical) may be included. Another component typically factored in is automation/orchestration software. While this won't be repeated with each pod, the underlying pod hardware may effect automation/orchestration decisions.

The pod should be designed in repeatable chunks for growth purposes. This means you'll need to properly assess your resource consumption model. Let's take a look at two examples:

A smaller organization may be able to fit into a single pod architecture for the foreseeable future. In these cases you'll want to design compute and storage expansion options that will maintain standardization. Blades will typically be a good fit here because the networking is expanded by default with each chassis. For rack-mount servers, your compute expansion option may include top-of-rack switching or additional blades for a director-class switch.

In a larger organization, the pod itself should typically be the expansion unit, although half-pod options aren't unheard of. You may also design expansion options for compute and storage for the event that one is maxed out while the other has resource availability. Overall, the idea should be to get as close to purchasing a new uniform pod each time you hit set utilization levels.

This consumption model helps with not only deployability ans operability, but also with maintaining the books from a finance perspective. The cost becomes very predictable for adding IT resources, and with steady growth it will be simple to plan for. Even with unpredictable growth, it's beneficial to know the complete cost well in advance.

In both scenarios, you'll want to factor in things like racks and cable management. These should be standardized as well, and often make a great pod boundary (as in one pod per rack). Another factor you'll want to consider when designing your pod is power and cooling--especially with enclosed or in-row systems. You'll want to tailor your pod design to a logical expansion point for your HVAC design.

Building a data center based on a pod design alleviates the commonly found Frankenstein method of piecing together disparate systems. This provides a more robust and stable platform through tighter integration and testing. With each expansion, the IT team will know the hang-ups in advance. Additionally, pods offer financial and operational benefits.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Joe Onisick
50%
50%
Joe Onisick,
User Rank: Apprentice
8/13/2012 | 10:46:03 PM
re: Better Data Center Standardization Through Pod Architecture Design
Mark,

I totally agree with all of your points. A pod architecture should not be a point of vendor lock-due to proprietary protocols. Additionally each pod should be able to lug into an upper layer manager of choice so you don't end up with automation/orchestration silos. Standards are key, and proprietary should be avoided unless it has inherant understood value.

Joe
Mark Berly
50%
50%
Mark Berly,
User Rank: Apprentice
8/12/2012 | 1:32:52 PM
re: Better Data Center Standardization Through Pod Architecture Design
The concept of repeatable pod architectures has been around a long time, the biggest issue with these designs are vendors use the concept of a pod to push proprietary extensions/protocols. Conceptually a pod should be plug-n-play with a larger architecture of other pods that all inter-operate via standard protocols. Leveraging best of breed pod architecture by decoupling proprietary vendor extensions/protocols make sense. I advocate building a vendor agnostic data center network which allows all the components to be interconnected with high speed, non-oversubscribed platforms all of which provide proper buffering and tooling to allow effective transport and management of the traffic running over it...
More Blogs from Commentary
Infrastructure Challenge: Build Your Community
Network Computing provides the platform; help us make it your community.
Edge Devices Are The Brains Of The Network
In any type of network, the edge is where all the action takes place. Think of the edge as the brains of the network, while the core is just the dumb muscle.
SDN: Waiting For The Trickle-Down Effect
Like server virtualization and 10 Gigabit Ethernet, SDN will eventually become a technology that small and midsized enterprises can use. But it's going to require some new packaging.
IT Certification Exam Success In 4 Steps
There are no shortcuts to obtaining passing scores, but focusing on key fundamentals of proper study and preparation will help you master the art of certification.
VMware's VSAN Benchmarks: Under The Hood
VMware touted flashy numbers in recently published performance benchmarks, but a closer examination of its VSAN testing shows why customers shouldn't expect the same results with their real-world applications.
Hot Topics
1
SDN Strategies Part 3: Juniper, Dell, Brocade, Alcatel-Lucent
Kurt Marko, Contributing Editor,  4/17/2014
1
SDN Strategies Part 4: Big Switch, Avaya, IBM,VMware
Kurt Marko, Contributing Editor,  4/18/2014
1
IT Certification Exam Success In 4 Steps
Amy Arnold, CCNP/DP/Voice,  4/22/2014
White Papers
Register for Network Computing Newsletters
Cartoon
Current Issue
Video
Slideshows
Twitter Feed