Archive for September, 2010

Rack Solutions for Cisco UCS and Cisco Nexus 7000 Series Switches

September 27, 2010

One thing many people don’t give much thought to when implementing or upgrading a solution in their datacenter is the racks.  In a lot of cases customers may be consolidating using virtualization and have more racks than they can use.  In many cases this approach works just fine if you are housing some basic servers and networking equipment but for some newer technologies older racks just don’t cut it.  If you are considering spending hundreds of thousands of dollars on new cutting edge technology why not spend a few extra thousand dollars and get the proper infrastructure to house it.  If you spent $300,000 on a new Ferrari you probably wouldn’t leave it parked on the street under a tarp would you?

As rack manufactures go there are more than a few.  We’ve been a reseller of APC for a while now and I continue to be impressed with their products.  Recently APC has released some very nice rack solutions for Cisco UCS and the Cisco Nexus 7000 series switch.  Now these are not “special” product specifically built for either one of these solutions but simple solution created from existing products to house hardware that has special rack requirements.  These solutions include the racks, pdu’s and cable management.  For any of you who have had the pleasure of racking/wresting a Nexus 7000 switch into a standard older rack know that it is not exactly what you’d call a perfect fit.  Both of the APC solutions have options for a more standard sized rack and their 750mm wide x 1200mm deep racks which really give you some room to work and run cables.

From a pricing standpoint these solutions are really pretty reasonable.  $3000 – $4000 street price per rack with all the PDU’s, cable management and assorted goodies.  For a UCS or Nexus solution that costs more than most houses that is really a heck of a deal.

For more details on APC UCS solutions download the pdf here:

Details on the Nexus 7000 are below.

More Details on Per VM Pricing for Site Recovery Manager

September 19, 2010

VMware’s recent change to a per VM pricing model for some products, particularly SRM, has certainly stirred up questions among end users.  That being the case I thought I’d take this opportunity to share some of the details I’ve gathered over the past week or so.  Hopefully this will help reduce some of the confusion.

  1. “You will benefit from the new pricing model…”  – that’s straight off the VMware website but I’ll let you decide if you think its true for your particular use case.
  2. If you’ve purchased per processor license and want to continue doing this you have until December 15, 2010 to do so.
  3. After December 15, 2010 you will only be able to purchase SRM using the Per VM model.
  4. Under the Per VM licensing model, licenses with be sold in 25 VM increments.  If you only want to protect 5 VM’s you’ll still be buying a 25 pack.
  5. License usage is based on a rolling average of the highest number of VMs in the past 12 months
  6. With SRM, any VM that is part of a protection group is counted.  This is regardless of whether the VM is turned on or not.
  7. Per VM is only supported in SRM 4.1 and newer.
  8. Per VM license keys can not be combined with per processor keys.
  9. VMware will be moving everyone to the per VM model over time.
  10. You will be able to trade-in your per processor licenses for per VM licenses.  The trade-in allocation will be 5 per VM licenses per processor license.  If you have 6 processors of SRM licensing you would receive 30 per VM licenses.  I have no idea how that plays in with the 25 packs of per VM licensing yet.

So those are some of the high points but lets take a look at a hypothetical situation from the cost perspective.  I’ll use retail pricing and assume 15 VM’s will run on a server with 2 processors.

Per Processor Model:

License Per Proc          $1,750

Production Support   $438

Total                               $2,188 x 2 procs = $4,376

Per VM Model

License for 25 VMs     $11,250

Production Support    $2,813

Total                                $14,063

Lets take a vSphere farm now with 3 Hosts, each with 2 processors.  Under my previous assumption that would be 6 processors with the capability to run 45 VMs (15 per host x 3 hosts).  Now lets look at the pricing comparisons:

Per Processor Model:

Licensing/Support Cost    $4,376 x 3 = $13,128

Max Number of VMs protected   45

Cost per Protected VM  $291 per VM

Cost per Protected VM assuming only 25 VM’s are protected = $525 per VM

Per VM Model:

Licensing/Support Cost   $14,063

Max Number of VMs protected  25

Cost per Protected VM   $562 per VM

Total Cost to protect 45 VM’s   $28,126

So is there a breakeven point?  Maybe, it just depends on the consolidation numbers you can achieve.  I suspect however that most people will not “benefit from the new pricing model”.  At the end of the day, unfortunately, all the calculations in the world won’t change the fact that you eventually will end up with per VM pricing for SRM whether you like it or not.

If you want more details you can view the official VMware details here:

Replication, Backup and Crackhead Mary

September 12, 2010

Last week I had a casual conversation with a guy about some basic concepts around replicated SANs and backups.  Dealing with virtualization and storage on a day to day basis it’s sometimes easy to forget that some people are not very familiar with the details of replicated SAN’s and disk based backup technologies.  So the question was posed, “if I have replicated SAN’s do I really need to spend money on backup?”.   The idea that “hey I’ve got two copies of the data at different sites. I should be good to go short of a nuclear bomb hitting the east coast.” is how many people look at backup/DR.

The idea that with replicated SAN’s, if one site becomes a smoking hole you still have the exact same data at another site (assuming sync replication) is certainly a true statement.  In a true “smoking hole” scenario this is probably what you want right?  All your data is there and, provided you have a solid failover process in place, you should be back up and running soon.  Let’s face it though, the smoking hole scenario, while horrible, is not as common as say the ID10T type of scenario that you probably deal with on a weekly or even daily basis.  When Mary from HR deletes the entire department directory one morning because she was out smokin’ crack and doing Jello shooters til 2 am that same morning – replicated SAN’s are simply going to replicate Mary’s stupidity to both sites.  Perhaps an even a worse senario is when your CEO asks you to recover a file he thinks he deleted 2 weeks ago – replicated SAN’s aren’t going to help you much here either, although there should be replicated copies of your termination papers at both sites real soon!

You can see where I’m going with this.  Now obviously with Snapshot technology and things like CDP and CRR technologies like RecoverPoint some of these ID10T error can be mitigated but there is still no real replacement for a good backup strategy.  Replication is great for DR where recovery times have to be very fast and data loss has to be kept to a minimum but unless it is used in conjuction with a solid backup strategy you are really only protecting yourself from the smoking hole scenario which, if we’re lucky, will never happen.  Crackhead Mary and delete-key happy executives are going to be problems you will deal with with much more regularity.