Building Blocks – Part VI: But my #PrivateCloud is too small (or too big) for building blocks!

Does your Building Block need a Fabric? <- Part 6

Okay, so this is all well and good, but you have been reading these posts and thinking that your environment is nowhere near the size of my example so Building Blocks are not for you. The fact is you can make individual Building Blocks quite a bit smaller or larger than the example I used in these posts and I’ll use a couple more quick examples to illustrate.

Small Environment: In this example, we’ll break down a 150 VM environment into three Building Blocks to provide the availability benefit of multiple isolated blocks. Additional Building Blocks can be deployed as the environment grows.

150 Total VMs deployed over 12 months
(2 vCPUs/32GB Disk/1GB RAM/25 IOPS per VM)

    • 300 vCPUs
    • 150GB RAM
    • 4800 GB Disk Space
    • 3750 Host IOPS

Assuming 3 Building Blocks, each Building Block would look something like this:

    • 50 VMs per Building Block
    • 2 x Dual CPU – 6 Core Servers (Maintains the 4:1 vCPU to Physical thread ratio)
    • 24-32GB RAM per server
    • 19 x 300GB 10K disks in RAID10 (including spares) — any VNXe or VNX model will be fine for this
      • >1600GB Usable disk space (this disk config provides more disk space and performance than required)
      • >1250 Host IOPS

Very Large Environment: In this example, we’ll scale up to 45,000 VMs using sixteen Building Blocks to provide the availability benefit of multiple isolated blocks. Additional Building Blocks can be deployed as the environment grows.

45000 Total VMs deployed over 48 months
(2 vCPUs/32GB Disk/4GB RAM/50 IOPS per VM)

    • 90000 vCPUs
    • 180,000 GB RAM
    • 1,440,000 GB Disk Space
    • 2,250,000 Host IOPS

Assuming 4 Building blocks per year, each Building Block would look something like this:

    • 2812 VMs per Building Block
    • 18 x Quad CPU – 10 Core Servera plus Hyperthreading (Maintains the 4:1 vCPU to Physical thread ratio)
    • 640GB Ram per server
    • 1216 x 300GB 15K disks in RAID10 (including spares) — one EMC Symmetrix VMAX for each Building Block
      • >90000GB Usable disk space (the 300GB disks are the smallest available but still too big and will provide quite a bit more space than the 90TB required. This would be a good candidate for EMC FASTVP sub-LUN tiering along with a few SSD disks, which would likely reduce the overall cost)
      • >140,000 Host IOPS

Hopefully this series of posts have shown that the Building Block approach is very flexible and can be adapted to fit a variety of different environments. Customers with environments ranging from very small to very large can tune individual Building Block designs for their needs to gain the advantages of isolated, repeatable deployments, and better long term use of capital.

Finally, if you find the benefits of the Building Block approach appealing, but would rather not deal with the integration of each Building Block, talk with a VCE representative about VBlock which provides all of the benefits I’ve discussed but in a pre-integrated, plug-and-play product with a single support organization supporting the entire solution.

Does your Building Block need a Fabric? <- Part 6

4 thoughts on “Building Blocks – Part VI: But my #PrivateCloud is too small (or too big) for building blocks!

  1. Chuck

    Thanks for the interesting series.

    I’m curious how you would handle small environments if there’s a desire to use blade servers.

    Take your 150 VM example, you’d have to get to 4+ blocks before you’d fill most vendors’ blade chassis:

    If you were using a blade solution would you:
    – Spread hosts in each block across all available chassis, ignoring the physical boundary of the chassis and basically treating them as a fabric connection.
    – Isolate a given building block to a single chassis, spreading full blocks across available chassis. In this case, would you consider it acceptable for two blocks to share a chassis (assuming there were additional blocks in other chassis), i.e. two 4-host blocks sharing a single UCS chassis?

    1. storagesavvy

      Regardless of manufacturer, Blade servers present a unique challenge from a cost perspective. Since you pay for the chassis no matter how many blades you install, the most cost effective use of a chassis is to fill all of the slots. Each empty slot in a chassis increases the overall cost per blade.

      I discussed this briefly with one of my local VCE peeps, and he informed me that for vBlocks, the rule is to make a single vBlock fully redundanct, so they use a minimum of two chassis per block. Cost no object, put two chassis in each block and only install the blades you need to meet the compute/memory requirements.

      Of course, cost is usually a big issue in most environments, so throwing two mostly empty chassis into each block is probably a non-starter. In the 150VM example, I had a total of 6 servers across the 3 blocks. You *could* install just one chassis, add 6 blades, then connect each pair to a different storage array through a fabric, or directly from the fabric interconnects in the blade chassis. The problem here is that you lose the benefits of fault isolation since a chassis problem (rare I know) would affect all 3 blocks.

      The least cost option that maintains fault isolation would be to use two chassis, install 3 servers in each, and treat each chassis like a fabric. Connect one server from each chassis to each array. Loss of a chassis affects 50% of the environment, loss of a storage array affects two servers (33% in this example). Over time you can grow by adding arrays and inserting additional blades. Cost effectiveness probably dictates a slighty different approach though. I’d probably play with the calculations to get the number of arrays down and increase the number of servers per building block.

      Cisco UCS blades add a further wrinkle since UCS is designed for multiple chassis to share the same fabric interconnects. Further, UCS doesn’t really have good support for Direct Attached storage so you end up needing a fabric. Two Chassis and Two fabric interconnects would create a fully redundant environment. Then you need a fabric between the interconnects and the storage. Depending on long term growth projections, deploying two or more blade environments up front and growing into the chassis later may be just fine.

      HP and Cisco offer chassis with only 8 slots which could help make small building blocks more cost effective. Last I checked, Dell and IBM still only have the 15/16 slot chassis but I’ll admit that I haven’t paid much attention.

      Unfortunately, as much as I love blades, they may not be the most cost effective solution at small scale.

      Hope that helps.

  2. Dude

    I notice you are using IOPs as a storage metric, IOPs without a normalized and agreed upon Read Write Ratio is risk business, no? How else do you apply the RAID Write penalty?

    1. storagesavvy

      Quite true! For the sake of my blog posts, since they are an example, the read/write ratio doesn’t really matter so much. But in Part 4, I did specify that I was using a 50:50 read/write ratio, and I calculated disk IOPS at that point to account for the parity write penalty.

      When sizing any system that handles disk IO’s, the read/write ratio needs to be calculated based on the particular IO characteristics seen in that environment. Some customers and applications are very write heavy, others are more read heavy. Once the predominant read/write ratio is determined for a particular environment, then you can apply the math for parity writes and figure out the disk IOPS needed to handle the workload.

      The read/write ratio will mostly have a bearing on the RAID type that makes the most sense. If capacity requires more disks than RAID6 would require to meet performance, RAID6 is probably a good choice. But in some cases we find that performance requirements can require more spindles than the capacity, so RAID10 is less expensive.

Comments are closed.