jueves, 31 de diciembre de 2015

Cross vCenter NSX : Use case customized part 1

-->
Hi there,


In this post I will try to put all my thoughts about a cross VC NSX use case used in conjunction with SRM, has been a time since I don't blog may be because I get lost in many things including work and fighting with reality, anyway I will died doing NSX!!!

So lets do like the business case:

This is a big client that has a need to migrate all the virtual infrastructure vSphere based from site A, site B and site C to site D, D has the capacity to support all workloads, the players on the field are vSphere and Site Recovery Manager at that time, everything was ok and then due to applications are hardcoded with ip address the big client has decided to maintain Ip addressing at any cost during this migration.


So simple ah? not it is not, here are the challenges to be beaten:

Application in every site are like a mystery to deal with, this means even applications sponsors don't know how they are mapped between them, i.e. application X has 300 VM's but it is uncertain who they are and how critical is the relationship, se we are fucked.

In every site is like a "do it yourself" vSphere deployment, this means not all the hardware is the same, and the installer guy of vSphere was thinking in porno when he did the deployment, so in consequence is not homogenous vSphere installation

Networking is a pain in the ass, for say less, so in every single site they have routed networks in same segment presented in all sites, for instance let's say we have a site A and the vSphere admin was required a VM or a bunch, to map the networks it is requires to have in an specific dvPortgroup since it is presented (the required VLAN) at physical segment and with and specific ip address sub-network, then this is just the beginning the administrator has to ask network flows and depending on physical networks a NAT (there is like 6K NAT's by the way) and then security for apps and NLB.


The proposal:

So the main driver is to keep ip address of VM's, right? so in a beautiful world the perfect elegant and awesome solution could be Cross VC NSX + SRM, but lets take a break to check why this will be the use case of years to come in DR and DA.

First lest check what we use to have as a solution for DR from VMware perspective, Site Recovery Manager is a tool that can be used for orchestration of Disaster Recovery, this sounds like fancy but is more easy that it sounds, so here are the features in high level about SRM:

  • In vSphere environments SRM will allow to "be the man in the middle" for Replication mechanisms at disk level, so whatever replication  (already certificated by VMware) SRM will mask instructions to disk arrays to break, copy or clone and reverse replication (please don't hate me I know is more detail but I want to give an Idea).
  • Array replication can be in one direction only, or both.
  • Can be used with vSphere Replication which is the network replication of datastore files for VM's been protected.
  • You can map vSphere objects from protected site to recovery site
  • Can be used as a tool for planned migrations maybe renewal of hardware.
  • Networks can be mapped from source and destination but need to wait till vmtools to "wake up" in order to change ip address or apply a script to change VM behavior or cosmetic changes.


So per se SRM can help IT to have a solid DR schema at low cost due to all the pieces involved are taken in governance by this orchestrator (not VCO don get confuse).



On the other hand what we can do to deal with networking mapping and preserver ip addressing the same during migration of VM's?

Lets see a little bit of NSX Cross VC solution has to offer, so at this point I guess everybody know WTF is SDN and VMware NSX right? Well assuming that, we start to describe this use case of VMware NSX with these capabilities:


  • With Cross VC NSX we are able to extend the Logical Switches (VXLAN based logical L2 switches) in geographical separated sites, for that we need to have 150 ms RTT, and WAN link of at least 1600 MTU.
  • We can have a natural mapping of logical wires with SRM
  • For been a L2 logical switch projected in two sites you can have the same ip address for VM's hanged in this, so if you migrate from site A to site B the VM will preserve ip address!!!
  •  It is possible to have 8 sites in extension


I guess you wonder how in the world L3 is taken in account? So check this and be amazed, VMware NSX installed in both sites (controllers just in one of them) so the same concept of extension of Logical switches applies to the Distributed Logical Router, this means that we have a projection of same DLR in both sites been the same logical router, so wen a packet comes from physical world looking for a VM inside virtual infrastructure (vSphere) this packet is router by Edge Service gateway and passed to U-DLR (U stands for Universal so Universal DLR and Universal LS, Universal Objects in cross VC NSX) this logical router know exactly where is the VM even if this is already migrated to other site and deliver the packed to the VM!!!

I need to check how performance is hammer in this case since there is not a VPN or such doing the extension, we are just doing an ip connectivity communication between sites and MTU over 1550 that's all, so according to me this is for WAN links with high BW and low latency since we required to have 150 ms RTT and vXLAN will have like a 1.5 Gbps of throughput.






That's for now I need to do some work so let me continue this horror story in next post....and please forgive my lack of diagrams but hope to solve that soon...


cya hogs!!





No hay comentarios: