Another brilliant UCS use case

Another brilliant UCS use case

The best part of my job is working directly with customers, sharing what I know and learning new applications of UCS from them.

This week I explored a brilliant use case for UCS with a customer – overcommitting blade resources for multi-tenant DR with Cisco UCS.

If you provide DR for multiple customers, and you don’t use UCS, then you currently need to replicate the same infrastructure for each customer.  If you are using HP Virtual Connect then that means replicating a lot of infrastructure, especially the networking.  If you like to maintain hundreds of redundant network components and have confidence that you can do this for business critical applications with zero configuration drift, then you are a Special Breed, and possibly Not Human.

Why not fix this problem, save money, give yourself an easier time and look smart by using a smaller infrastructure and over-committing it as follows:

  • Converge your network: Instead of HP Virtual Connect and its distributed, hard to maintain network-per-chassis configuration, use Cisco UCS centralized, highly-available and, quite frankly, simple network control point and just scale your compute, not your network points.
  • Converge your compute: Instead of replicating HP blades for every customer (nice for the vendor, bad for the customer), use Cisco UCS service profiles to over-commit a smaller number of blades.  Only one customer is in DR at one time, so it is possible to use as few as eight blades for around twenty customers.

As an illustration, imagine you have three customers you provide DR facilities for.  Each customer needs eight blades for their DR purposes.  Some for desktop, some for web, some for infra, some for DB.  Every customer has the same requirements, but this is not mandatory (just easy for this illustration).

With HP’s system, you would need three times eight blades – effectively, two or three chassis.  That means you need two or three redundant networks to manage, duplicated to cover ethernet and fibre-channel.

With UCS’s system, you only need eight blades, one chassis, one network control point, and instead you create twenty-four service profiles – eight for each customer.

When DR time happens, you associate the customer’s service profiles to the available blades and VOILA!  Your DR site is up.

By my simple maths, that means the HP solution will cost you AT LEAST three times as much as UCS, not counting the additional OpEx cost and grey hairs that the HP solution will give you.

Use boot from SAN, leverage UCS policies and pools, and you only have to configure it once – wire once and walk away.  You never have to reconfigure the network again, all you do is associate and disassociate service profiles to blades.  Simple.

As time goes by, the use cases that are unique to UCS are starting to emerge as customers adapt the solution to fit their business needs.  The Cisco Unified Computing practice is an exciting place to be right now.

FAQ

Some questions I’ve been asked already…

But what if I do DR differently?

Hey, this is a brief illustration, not a complete guide to DR: your mileage will vary :-)

But how do I migrate service profiles to DR?

You don’t migrate stuff in DR – how can you migrate from a “dead” data center?  That’s like using vMotion for DR – doesn’t make sense.

This is a “standby DR” architecture, leaving redundant architecture in place for DR.  This simple illustration shows how you can over-commit this redundant, standby architecture for multiple customers.

But what if my customers don’t want to share “their” DR blades?

They aren’t sharing their blades – only one customer uses the blades at one time.  If you want to be more elaborate and carve out dedicated redundant standby infrastructure then you can do that, but you (the provider) and your customer loses the $benefits of over-commitment.  It’s up to you!

But why don’t I just use ESX to provide the over-commitment?

You can use ESX AND you can use UCS.  You don’t have to pick one OR the other, you ideally use both.  But imagine if you need different sizes of blades for different workloads, like a “Big ESX” and a “Small ESX” – how will you do that without Service Profiles providing variable size blades on demand?  What about if your workload isn’t running on ESX today?  What about if you have different networking (VLANs?) and storage (VSANs?) requirements for different customers?  You should use ESX and UCS: it’s the most powerful combination.

Related posts:

  1. Tradeoffs between scalability and performance in UCS
  2. Cisco UCS: different workload, different configuration, same blade. Simple.
  3. With UCS you buy one set of switches every 112 blades
  4. VMware + Ubuntu + Ruby + REST + XML + Cisco UCS API
  5. Get Spidey Powers with UCS; but with Great Power comes Great Responsibility