Valid Cisco based FC / FCoE combinations as of 7/2/2010

A coworker sent me this in PDF form, and I thought it was useful / important enough to make a quick post regarding it. This would have been very nice to have in the early stages on FCoE / Cisco / UCS designs, but nonetheless a handy quick reference.

Enjoy!

Comparing storage virtualization technologies: EMC VPLEX, Netapp VSeries, HDS USP-V

The release of VPLEX has spawned some interesting conversations with customers. When exploring the concept of storage federation, which is enabled by storage virtualization, the question that often comes up is, how do the main storage virtualization technologies differ?

The three mainstream storage virtualization technologies in the market today are Netapp’s V-Series, HDS USP-V, and now EMC VPLEX. They all have some commonalities and differences in their architecture, function and use cases……

Interesting use cases for VPLEX

As I’m sure most are aware, EMC released its VPLEX product for federated storage access (a virtual storage engine). The idea being able to share storage across sites using distributed caching algorithms making active/active data centers a reality. Currently available across synchronous distances (100km) and for local site use cases. This product does all the things Invista does, plus cache coherency, plus across distance, plus a scale out cluster model, plus simplified setup and management and not performing the virtualization at the SAN switch level (thus not requiring stretched fabrics between sites), plus doing it with an appliance model, plus….. well you get the point.

The main reason for this technology is to further enable cloud based IT architectures. The ability to dynamically move storage work loads across data centers (or even within different arrays in the same data center) seamlessly without any application downtime or interaction. Once can also make a case for easy tech refreshes since virtualizing the storage volume decouples it from the physical array, allowing you to play the “storage vmotion” game with which back-end array the data actually resides on. Very similar to how VMware decouples the application/OS workload from the physical server.

Those are all pretty standard use cases for storage virtualization, but how about some others?

A quick look at server vs traditional blade vs UCS wiring

This is just a quick post illustrating the wiring simplicity of the UCS when compared to traditional rack / blade servers…

First up is your traditional rack with Dell 1RU servers. Note the separate LAN/SAN connections per “compute unit.” Not all of servers are wired up here, but you can imagine the mess if they were.

Next up, a Dell Blade chassis. Things get a little better, but still, quite a bit of wiring as the LAN / SAN connections from each chassis require separate physical cabling. In this picture there are only 2 SAN connections (really 1 if you consider redundancy). Imagine this with 2-4 more SAN connections to give the type of connectivity you would need in a production environment and potentially more LAN connections to meet throughput needs. Also keep in mind, each chassis deployed in this manner will require all of these connections. It can get hairy when there are multi-chassis configurations. If you needed more SAN bandwidth you would need to write up more FC connections. If you need more LAN bandwidth, you would need more ethernet connections. You would need to know these requirements up front, or take some educated guesses. Calculating wrong here could create a real cabling nightmare in the future if FC ports vs LAN ports are not available in the network. Also worth noting are the separate management interface cables.

Finally, we have the UCS. Note the cabling simplicity. The 4 black connections from each FEX carries unified I/O to the top of rack for distribution into the core. 8 connections per chassis = 80Gb throughput per chassis for you to divvy up as you desire. Need 50Gb of LAN and 30Gb of SAN? No problem, utilize the the UCS manager and configure via service profiles. Need 40Gb LAN and 40Gb SAN? Again, no cabling changes or adding connections, simply do it in software via the UCS manager. Utilizing the Palo CNAs in the blades gives you even more flexibility which is unparalleled with other systems. This is truly wire once, use/change as you see fit technology. Would you rather balance your LAN / SAN bandwidth requirements via physical cabling, or using QoS in protocols? Much more flexibility in this design. And do you notice cabling missing for “management”? That’s right, no dedicated management cables needed per chassis, all handled via the 4 black connections per FEX to an internal management network. Another area of simplicity.

I get a lot of questions as to what the wiring simplicity actually looks like on a real kit, so I thought I would make this quick post to see it in the wild.

A look at solving the VDI IOPS problem

One of the great things about working for a VAR is that I get to evaluate best of breed solutions in a vendor agnostic manner. Lately, I’ve been spending more and more time speaking with and doing VDI designs for both our EMC and Netapp customers.

I thought I’d take some time to discuss how each of these companies are helping to solve the “VDI IOPS problem.” For those not familiar with this particular problem space, to put it very simply: with physical desktop deployments, each desktop/user has their own hard drive. When moving to a virtual desktop, the storage is consolidated on a SAN/NAS array, and thus there is no longer a 1:1 dekstop to disk drive relationship. This is not to say that you *cannot* have a 1:1 desktop to disk relationship, but doing so would be extremely cost prohibitive and ruin any practical method for justifying VDI regardless of any opex savings. The issue is not one of disk space, but one of performance, namely IOPS. Each disk drive can only support so many IOPS, so the question becomes, how do we design cost effective storage solutions for VDI, while providing the correct amount of performance to not impact user experience.

EMC and Netapp both have different solutions to this problem. To illustrate, lets look at a simple use case:

• 5000 users
• average desktop user IOPS requirement of 10IOPS per user

Simple math gives us 5000 * 10 = 50,000 IOPS required from the storage array. Assuming a standard deployment of 15K fiber channel disks (at 200 random IOPS per disk with decent latency), NOT counting RAID overhead, we would need ~250 spindles to support this workload. This (relatively) massive spindle count will completely skew any TCO when building a business case for VDI, so we must find a way to lower this spindle count, and do it in a cost effective manner WITHOUT sacrificing the performance of the overall system. This is not a $/GB problem, this is s $/IOPS problem. Applying deduplication techniques, and reducing the overall spindle requirement from a CAPACITY perspective will do nothing for solving the $/IOPS problem. Or will it? The storage cost is one of the biggest costs of any VDI deployment. So this is a very important place to look for efficient designs.

UCS connectivity into Ethernet and FC networks

There has been some talk lately about how the Cisco UCS connects into various networks and some of the “limitations”. I put “limitations” in quotes as I hope to explain why these are actually design considerations and not “limitations.”

This is an issue that hits home for me, as I am discussing UCS with customers on an almost daily basis and this is absolutely part of the conversation. The main question is, why can we not direct connect storage devices and other hosts into the 6100 since they have ethernet and FC ports? There are two aspects to this: a) why technically it is not feasible given the current rev of the HW/SW and b) why you would or would not want to do this when designing a solution in the first place.

For those not familiar, the UCS is the unified compute platform by Cisco. However, this post is not meant to describe the UCS system, rather to focus on connecting it to an existing or new customer network. That being said, some background on the UCS and the I/O flow is necessary…

whitebox vsphere lab

Despite having a full lab in our Tampa office consisting of two UCS chassis, Nexus 5k switches, various EMC, and Netapp storage devices, Avamar, DataDomain, etc, etc ( you get the point ), I still felt the need to have an ESX environment at home for tinkering purposes. Some of our equipment is reserved for demo purposes, and some for engineering (aka “playground”) purposes, but there is something to be said for having unadulterated access to your own equipment, and lets face it, having ESXi running at home is just cool.

It is still a work in progress, but I wanted something with a small foot print, quiet, and most importantly it needed to have all the proper CPU support to function with FT for testing purposes. For those not familiar with vSphere FT, it essentially allows a primary VM to run on one ESX host and a secondary VM to run in lock-step on another ESX to provide near-zero recovery in the case of physical ESX host (or other infrastructure) failure….

Obligatory first post…

Well, I have finally succumbed to the blogosphere. A quick background: I work for a large national systems integrator in the US. Officially by title I am the Technology Manager for the Data Center Practice in my district. In my role I wear multiple hats with a healthy mix of operating in a business strategy role, leading a virtual data center engineering team, and providing pre-sales engineering support to the field in sales campaigns. The best part of my job is interacting with customers, listening to their business problems, translating those into technical requirements and providing solutions to those problems. It is a fun and challenging job which forces creative thinking on a day to day basis which keeps me on my toes. No day is like the day before, and that’s something I enjoy. This blog will serve to primarily discuss the technology and more importantly the application of said technology that is driving the revolution in the data center space today — namely the push towards virtualizing everything! Hence the name of the blog.

I look forward to sharing technical info, sparking conversation around these technologies/market trends as well as any comments you may have.