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
Filed under: efficiency, solutions, technologies Tagged: availability, block, brocade, building block, cisco, cloud, emc, esx, fabric, hyper-v, integration, isolation, pod, private, sizing, symmetrix, unisphere, vblock, vce, vmax, vmware, vnx, vsphere
