Below is my scenario.
Data Center : 1 (Primary)
vCenter 6.0
ESXi 6.0
NSX Manager 6.2.2
Data Center : 2 (DR)
vCenter 6.0
ESXi 6.0
NSX Manager 6.2.2
I have all my primary VMs in the my primary DC.
I will be using Storage replication to replicate my VMs in Primary to the DR Site ( I am not using VMware replication, but i am using other storage replication)
So when there is any issue with the Primary VM`s I will bring up the VM`s in the DR site . Will be using SRM to change the hostname & the IP Address to bring up the VMs in DR.
I will be using NSX distributed firewall to protect my VMs. Below are the question I need to have answers.
1. When the VM is being migrated from the Primary site to DR site how will the firewall rules will be mapped. Since the IP Address will be changed to the new IP how should i manage the firewall rules.
2. Since i am not using Cross vCenter functionality how will the new VMs which are bought up in the DR will be able to map to the vCenter & also how NSX will identify and manage these VMs.
Yes, that is perfect
1. When the VM is being migrated from the Primary site to DR site how will the firewall rules will be mapped. Since the IP Address will be changed to the new IP how should i manage the firewall rules.
Since this is not a cross VC NSX - i would simply create secruity Group and security policy against protected VM's in DR site. That way when the VM's are failed-over . They will remain protected.
2. Since i am not using Cross vCenter functionality how will the new VMs which are bought up in the DR will be able to map to the vCenter & also how NSX will identify and manage these VMs.
NSX is not aware of protected or recovered VM . Any VM that is populated in the inventory,as long VC is in sync with NSX it will have visibility.
Thanks.
Regarding the 2nd point I have the query.
2. Since i am not using Cross vCenter functionality how will the new VMs which are bought up in the DR will be able to map to the vCenter & also how NSX will identify and manage these VMs.
NSX is not aware of protected or recovered VM . Any VM that is populated in the inventory,as long VC is in sync with NSX it will have visibility.
In the DR site when the VM is bought up how the vCenter in the secondary Site recognize the VM.
Because the VM is not created by the vCenter in the DR site.
Some options that I can think.
1. Create DFW using SRM placeholder VMs as DFW objects
On the DR vCenter, you should see SRM placeholder VM, but I haven't try if creating DFW against SRM placeholder VM works after failover or not.
2. Create DFW rules using IP Sets
Create DFW rules on DR vCenter using IP Sets of VMs for DR site
3. Create DFW rules using infrastructure objects (logical switches, dvPortGroup)
Depends on your DFW rules / security policy scenario, you can create DFW rules using vCenter infrastructure objects such as logical switches or dvPortGroup so it will match against any VM attached to that logical switch/dvPortGroup
In the DR site when the VM is bought up how the vCenter in the secondary Site recognize the VM.
Because the VM is not created by the vCenter in the DR site.
Not really true. VM's are still managed by DR site VC and Host- Only from a SRM perspective VC in primary and secondary takes care of protection and reprotection which has no relation with NSX .
But i agree with placeholder VM point which bayu mentioned. I will not recommend creating rules against Placeholder VM's, i have never tested it as well. Because these status keep changing during DR events. Other than that creating security groups and leveraging vc objects should work flawlessly .One more point is ,just ensure that you don''t place NSX components on DR replicated volumes.
Thanks bayuwibowo & Sreec
I have one basic question regarding the option of using place holder VM option.
For ex in primary site i have VM with the name abc123 & with IP 1.1.1.1
My understanding is that in the DR site there will be placeholder VM with the same IP address & hostname. Let me know if my understanding is right.
If this is the case, when the DR is invoked the SRM will change the hostname & IP address as efg123 & 2.2.2.2
In this case how exactly will the firewall rules can be placed.
The other option which i am looking is that of creating dynamic membership using service composer & create the firewall rules.
The dynamic membership will be based on the host name when the VM comes up in the DR.
So whenever the VM comes up it will be part of the dynamic group & the firewall rules will be applied dynamically to that group.
Let me know if this will work.
I have one basic question regarding the option of using place holder VM option.
For ex in primary site i have VM with the name abc123 & with IP 1.1.1.1
My understanding is that in the DR site there will be placeholder VM with the same IP address & hostname. Let me know if my understanding is right.
If this is the case, when the DR is invoked the SRM will change the hostname & IP address as efg123 & 2.2.2.2
In this case how exactly will the firewall rules can be placed.
Placeholder is just a dummy VM with just config files. Yes you are right, when fail-over is invoked vm should get customized only if you have configured your recovery plan in that way . Behind the scene it is guest customization . OR ensure that the DR network is visible for DHCP discovery so that VM will get the IP based on the scope. Hope it is clear now ?
So if we know our VM name in DR is ABC - We can simply create a Security Group and Policies with Static/Dynamic and filter criteria OS/vm name etc ...and create a firewall policy .
You can test it with Test recovery option in SRM without impacting production workloads and confirm rules are getting applied and is working as expected and perform a actual failover once all prerequisites are met and confirmed from storage side.
The other option which i am looking is that of creating dynamic membership using service composer & create the firewall rules.
The dynamic membership will be based on the host name when the VM comes up in the DR.
So whenever the VM comes up it will be part of the dynamic group & the firewall rules will be applied dynamically to that group.
Yes, this is what exactly i mentioned in my first post .
Thanks.
Placeholder is just a dummy VM with just config files. Yes you are right, when fail-over is invoked vm should get customized only if you have configured your recovery plan in that way . Behind the scene it is guest customization . OR ensure that the DR network is visible for DHCP discovery so that VM will get the IP based on the scope. Hope it is clear now ?
In my environment I don't have the DHCP discovery enabled. But all VM`s do have VM tools. I believe this should suffix the requirement.
Yes, that is perfect
Thanks