Changes to VMware NSX Licensing

So yesterday VMware announced a new licensing model for NSX – VMware’s Software-Defined Network product.

Up until now, VMware have only had a single version of NSX available to buy – which customers were not too fond off – it was an ‘all-or-nothing’ approach to SDN which customers found too restricting. I’m glad to see that VMware have taken on board all the feedback from customers and partners and amended their licensing model.

NSX is now available in three editions: Standard, Advanced and Enterprise – all licensed per socket (although there is a per-user license model for the Advanced edition to align with VDI deployments).

Existing NSX for vSphere customers automatically get allocated with Enterprise edition licenses. Existing NSX for Horizon customers automatically get allocated NSX Advanced edition licenses. The existing NSX for vSphere and Horizon offerings reached End of Availability on 3rd May 2016.

NSX licenses

VMware have positioned the three new editions according to the three main use cases:

  • Automation (virtual networking, automatically deploy network services via vRealize Automation)
  • Security (Micro-segmentation, 3rd party integration, securing VDI)
  • Application Continuity (Multi-site NSX deployments, DR, Hybrid Cloud networking)

So if all you want are the benefits of virtual networks – collapsing the switching and routing into the kernel, shortening network provisioning times, automating network configuration – then you will only require the Standard edition (and at roughly £1500 per cpu license, it’s around a third of the original NSX price).

In reality, a lot of customers will probably purchase the Advanced edition (at roughly £3400 per cpu license) as they will want the security features (distributed firewall) to allow them to implement micro-segmentation, as well as the ability for 3rd party integration with the likes of Trend Micro, Palo Alto Networks, Checkpoint, etc.

So whilst the Advanced edition will work out nearly £1000 less per CPU, it’s interesting that the Enterprise edition is going to be almost £1000 more expensive than the original price for NSX – and for pretty much the same product feature set! The only new feature that I can see in the Enterprise edition is possibly the increased support of Hardware VTEPs (from Arista, Dell, Juniper, maybe Cisco) – pretty much every other feature is currently available in the NSX for vSphere product…. so I’m not sure how VMware can justify the price hike for exactly the same product?!?

In fact this was raised by a number of partners today during a NSX Partner Round-table that I attended. I can only assume that the price hike is to cover any new features that might be in future roadmaps??

One thing worth noting is that NSX licensing applies to any active workload in a DR
site. This means there is no requirement for NSX licenses at the DR site as long as there are no active workloads running there!

For more information visit http://www.vmware.com/go/nsx.
Additional details on NSX licensing edition features can be found at: http://www.vmware.com/products/nsx/licensing.html

Advertisements

Improvements to vCloud Air Disaster Recovery as a Service (DRaaS)

When DRaaS was launched by VMware the backend of last year, everyone was pretty excited about the ability to ‘get rid’ off their secondary/DR site and offload it all into the cloud – A subscription based DR solution which would allow customers to decrease their Capex and offset it with an Opex model.

It kind of boils down to the old accounting argument regarding whether Capex or Opex is a better spending model for IT Infrastructure. Now I’m not an accountant, nor am I pretending to understand the ins-and-outs of tax-deductible benefits, but from my understanding an Opex model is more tax efficient – especially on the P&L balance sheet. (Obviously correct me if I’m wrong!)

Usually a Capex model means:

  1. You require a large amount of cash outlay to purchase all the goods
  2. You have to make an ‘educated’ guess to estimate future capacity needs
  3. Once you’ve purchased the goods, you’re pretty much stuck with it, despite advancements in technology of company growth

However, some CFOs still think that Opex is more expensive as they only consider the cost of the physical server required for the applications.
Whenever you have to do any sort of capex/opex comparison, you have to take the direct costs such as power, cooling, floor space, storage and IT resources to manage the physical hardware.
Plus then there’s all the indirect costs – network and storage, procurement and accounting costs, transportation/logistics, etc. Once all these other costs that accompany the physical tin are considered, it becomes a different argument!

Anyways, I digress…..

So When VMware launched vCloud Air DR, I thought it would become a viable solution for customers looking to get rid of their DR site….. but upon closer inspection there were some flaws in the solution – namely trying to automate your DR (like SRM) and the process of failback once your primary site comes back online (the vCloud Connector process was clunky and required VMs to be powered off before a full data copy occurs back to the primary site – not a viable solution as who would switch off their VMs in order to copy them back over? And we’re talking hours offline if you’re copying a 100GB VM over a 100Mb link!!).

Quick overview of the benefits:

  • RPO configured on individual VMs from 15mins to 24hrs.
  • DR protection is per VM (allowing individual VMs to be failed over)
  • Secure asynchronous replication of VMs (using vSphere replication)
  • Self-service DR testing of VMs (up to 2 tests per 12mth period with a 7 day testing period)
  • Guaranteed resource availability (especially during DR failover)
  • Monitoring and management via Web Client
  • Integrates seamlessly with vSphere environments
  • VMs can run for up to 30 days in a failover scenario without incurring additional costs
  • Ability to transition out of the DRaaS into vCloud Air Private or Dedicated Cloud
  • SLA of 4hrs or less

DRaaS

I’m happy to say that the current release now offers Native Failback using vSphere Replication to reverse the replication from vCloud Air DR into your on-premise environment. Unlike vCloud Connector, this does not require the VMs to be powered off during the reverse replication. It can also be managed from your Web Client – similar to how you originally setup the replication process to vCloud Air.

In addition to this, VMware are now offering Multiple Point-in-Time Recovery using the ability of vSphere replication to retain multiple recovery points, up to a total of 24! Great if you need to recover to an earlier point in time if the latest replication set is corrupt or the VM experiences errors.

Finally, Automation is now possible with full integration with vRealize Orchestrator via a plug-in. This will allow you to create multiple VM recovery plans and automate the failover process – similar to what SRM can do.

For more information about the new version of vCloud Air DR, head along to VMware’s blog announcement: What’s new with vCloud Air DR?

For more information about the vCloud Air offerings, point your browsers here: vCloud Air

vCloud Air Tutorials

Want to know more about the VMware vCloud Air services? Well pop along to the tutorial page in the vCloud portal! =)

http://vcloud.vmware.com/uk/using-vcloud-air/tutorials

Excellent material for how to use the vCloud Air services, how to setup and deploy VMs if you purchase a Dedicated or Virtual Private Cloud….. and most importantly how the vCloud Air Disaster Recovery works (which was what I was after).

We’ve had a huge number of customers interested in DRaaS and vCloud Air DR seems a very viable solution!

vCenter Site Recovery Manager – Shared Recovery Site

So a lot of customers use Site Recovery Manager as the tool to automate their Disaster Recovery Policy, usually it’s deployed on an one-to-one relationship – i.e. a single protected site and a single recovery site where the SRM/vCenter server on the protected site is paired to a SRM/vCenter server on the recovery site.

Not many people are aware that since SRM 4.0 you could actually set up a Shared Recovery Site which allows you to ‘fan-in’ your recovery from several protected sites (ie N-to-1 relationship).
This could be very useful if an organization has several remote/branch offices and requires them to be protected by a single shared site. Another example is where a service provider offers business continuity services to multiple customers – DR-as-a-Service.

In a shared recovery site configuration, you install one SRM Server instance on each protected site. On the recovery site, you install multiple SRM Server instances to pair with each SRM Server instance on the protected sites (so if you had two protected sites, in the recovery site you need to deploy two SRM servers).
All of the SRM Server instances on the shared recovery site connect to the same vCenter Server instance.

Similar to how standard SRM is deployed, you can use either array-based replication or vSphere replication.

Image
In the diagram above, you can see that there are two field offices protected by the their Head office.

SRM Server A (Field Office 1) is paired to SRM Server C (HO)
SRM Server B (Field Office 2) is paired to SRM Server D (HO)

So what are the limitations of a Shared Recovery Site?

  • You can’t reconfigure an existing standard SRM deployment to use a shared recovery site, this is because a custom installer is used when deploying SRM which allows you to set the SRM Identifier (which must be identical for the SRM pair).
  • Each instance of the SRM Server at the shared recovery site must be deployed on its own host machine, ie you can’t deploy multiple SRM servers on the same VM.
  • Each instance of the SRM server requires its own database.
  • You’re limited to a maximum of 10 protected sites per shared recovery site.
  • When accessing SRM through vCenter Server on the shared recovery site, you can view all the SRM extensions (and pairs) and hence see all the VMs, protection groups, recovery plans, etc.

One thing you need to be very careful with is how your solution is licensed if you’re thinking about using the Reprotect functionality of SRM (or bi-directional protection).
As with standard 1:1 SRM deployments, you can re-use your protected site SRM licenses at the recovery site (assuming they are no longer in use at the protected site) and invoke reprotect/failback.
However, if you use a new set of keys at the recovery site, then you need to ensure you have enough licenses to cover the VMs that need to be reprotected.

For example:
Site A – licensed to protect 20 VMs.
Site B – licensed to protect 10 VMs.
Shared Recovery Site – licensed to protect 25 VMs.

If you don’t transfer the licenses from the protected site to the shared recovery site, then you can only perform reprotect on 25 VMs. If you recover all of the VMs from sites A and B to the shared recovery site and attempt to perform reprotect, you have sufficient licenses to reprotect only 25 of the 30 VMs that you recovered!

The Operational Limits for SRM in a shared recovery site can be found here:
http://kb.vmware.com/kb/2008061

At some point before Christmas I’m hoping to get this all up and running in MTI’s demo centre…… =)

Protecting your Cloud (vCloud & SRM)

So one of the BIG problems at the moment is that SRM does not fully support protecting your vCloud environment.
http://www.vmware.com/support/srm/srm-releasenotes-5-1-1.html#caveats

It supports protecting your management cluster (so the vCenter servers, vCD cells, vCNS manager, vCM, DBs, etc), but it doesn’t yet protect your resource cluster….. so all those VMs you’ve deployed in your organisations under vCD – well they’re not protected by SRM!

Definitely NOT COOL if your primary site goes tits up!!

From what I can gather, this is mainly due to the way SRM work….. When you setup SRM for DR, you have to ‘pre-create’ resources at the recovery site in order to map the resources from the protected site to them (stuff like resource pools, folders, network, placeholder VMs). Unfortunately vCD likes to have full control of a resource cluster and manages all the resource itself – this basically means that the vCD cells are not aware of the objects that have been created in the recovery site for SRM. It doesn’t matter if the names are the same, what matters is the Management object Reference IDs (MoRef ID) have changed and this is what vCD uses to construct its environment…..

MoRef IDs are used to correlate objects between vCD and the underlying vSphere/vCenter layer. Any changes to these identifiers will result in the loss of functionality because vCD will not be able to manage these objects as it will not be aware of them (ie the MoRef IDs will not exist inside the vCD DB).
The use of SRM would result in a change of the MoRef ID on the vCenter Server layer, resulting in an incorrect reference in the vCD database – and so leaving the object (eg. a VM) unmanageable from a vCD perspective. I believe SRM also re-signatures the storage volumes which will also confuse vCD.

About a year ago Chris Colotti and Duncan Epping wrote an article on how vCloud DR could be achieved, this involved the clever idea of putting the resource ESXi hosts at the recovery site into the same resource cluster as the resource ESXi hosts at the protected site (but in maintenance mode as obviously it won’t see the storage located at the protected site so can’t be used by vCD). Then using vSphere HA to take the ESXi hosts out of maintenance mode to handle the recovered workloads…. However, this solution did involved manual intervention to fail over the vCD resources correctly:
http://www.yellow-bricks.com/2012/02/13/vcloud-director-infrastructure-resiliency-solution/
http://www.vmware.com/files/pdf/techpaper/vcloud-director-infrastructure-resiliency.pdf

Earlier this year, another white paper was released which described how the majority of this manual process (ie the VMware bits) could be automated using PowerCLI:
http://www.vmware.com/files/pdf/techpaper/VMware-vCloud-Directore-Infrastructure-resiliency-whitepaper.pdf

However, what’s missing is the automation of the whole storage piece – breaking the replication and making the volumes read/write….. but then I guess this is really more storage-vendor dependent! =)
I guess if the storage vendor has exposed the array to VMware using VASA then it could be possible to script the storage steps as well….! =)

Anyways, it’s been an interesting read…… and definitely a problem I see VMware sorting out for the next release of SRM!

Given how powerful PowerCLI is, I really need to find some time to learn how to use it!!