May 2008 - Posts

• XS23 Cloud Server

  Tue. May. 13, 2008
  by Todd Brannon, Dell Data Center Solutions

  There has been some recent press around some of the equipment we’ve developed in our cloud computing group. The core of our business is essentially a consulting and design service and developing new products for customers is a big part of the fun. Because these aren’t mainstream PowerEdge systems, we don’t get the chance to show them off as much as we’d like. Our group has been talking for some time about “optimized designs” for cloud and hyperscale computing without showing what that can really mean, so it’s time to unveil something that’s come out of the lab.  Pictured here is one of our favorites: the XS23.

  

  XS23 front – twelve 3.5” SAS or SATA drives; 3 per server

  This product was designed for a customer that needed maximum compute density, a healthy amount of local disk and, of course, lowest power draw possible. Our architecture team threw all that in the blender and out came a 2U standard rack mount chassis that houses four dual-socket servers and twelve 3.5” hot plug drives.

  

  XS23 exploded view: two dual-socket servers mounted in chassis bottom; two in a mezzanine above. Industry standard rack-mount chassis.

  Density of this type is certainly not unheard of (half depth or twin 1U’s), but by going to a 2U chassis we were able to fit it with larger, more efficient fans and stack 3 rows of full 3.5” drives across the front. So, even with a 25% higher density than general purpose blades, it provides three local spindles of 3.5” SAS/SATA disk to each server. Of course there are tradeoffs. This was expressly designed for an environment with high node failure tolerance - a cloud application. By designing out a lot of the capabilities that weren’t required (like redundant power) we were able to deliver the performance and power profile required. Efficiencies are gained by shared resources - as seen in a lot of general purpose designs available today. We think the key to designing the perfect cloud server is knowing where to stop and also what not to build in. This is a function of each customer’s unique design goals. Applications truly capable of foregoing high availability in hardware are somewhat rare, but customers in this space have it – as well as a laser focus on their business levers. So in this case we took the problem statement and made the tradeoffs to yield highest efficiency and density within the performance parameters of the application.

  It’s important for me to emphasize that the XS23 is not generally available. This system is qualified and supported for only a handful of specific customer applications and locations; it’s not completely productized to bear a PowerEdge badge. I hope you’ll watch this space for more unique designs and the discussion on cloud taxonomy and architecture that Jimmy's leading.

  4 comment(s) del.icio.us email this digg

• Layer 1....

  Mon. May. 05, 2008
  by Jimmy Pike, Director—System Architecture

  I’d like to continue on our journey and build out the model that we have described starting at the bottom of my model and moving towards the top. The first thing we should do is change the name of layer 1. Some have pointed out to me that while the facilities is an important element, this block is going to cover a lot more than just the facilities and we should change its name. I’d like to propose physical plant (which is a very familiar term to facilities folks) and see if this encompasses what lies ahead.

  

  Figure 1 – Cloud Computing Layered Model

  The first aspect to consider as part of this layer is what I am going to call ”macroscopic containment” or MC for short. Most folks would simply refer to this as the building, but I want to make a distinction here as there are many functions we can get from the MC.

  · The simplest form of MC is of course NONE. This is the case for equipment where the cabinetry is designed to sit out in the open. We see this in the telecom and perhaps the military industries, but not in this space. (although there are some interesting discussions ahead and a debate where “container” based solutions should go.)

  · Next we find a very simple MC or what I am going to refer to as temporary devices. The best example of this is a tent. Not very practical in most cases (in fact it almost sounds like a joke), but I know there are people considering them for areas where all they need is a bit of protection from the elements and some light physical security.

  · The next level is a fairly major transition to an actual building. This is probably where we are going to see most cloud installations and is what I think will ultimately prove to be most cost effective. I will refer to this as a utility building which is best described as a simple shell with a concrete floor (no raised floor). It provides controlled separation from the IT environment and outside environment. (I’ve seen these for about $38/sq ft. depending on the way you want the building finished-out.)

  · The final MC type is more along the lines of conventional data centers with raised floors and the works. This provides a very clean and well controlled solution and is probably overkill for most cloud environments. A reasonable rule of thumbs for this type of MC is about $500 per sq ft.

  We may want to add something describing this as owned, leased, or co-located space, but I have omitted this for now. I have also added MC to the schematic model we are going to build, but it isn’t much to look at. We’ll have to get a bit further in the definition for it to start having meaning.

  As always, your comments are welcomed. Next up, Utilities!

  1 comment(s) del.icio.us email this digg