-->
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:
Publicar un comentario