This chapter is from the book
This chapter is from the book
This chapter is from the book
Assigning Placeholder Datastores
As we will see later in this chapter, an important part of the wizard for creating Protection Groups is selecting a destination for placeholders for the Recovery Site. This is a VMFS or NFS volume at the recovery location. When you create a Protection Group at the production site, SRM creates a VMX file and the other smaller files that make up the virtual machine from the Protected Site to the Recovery Site using the placeholder datastore selected in the wizard. It then preregisters these placeholder VMX files to the ESX host at the Recovery Site. This registration process also allocates the virtual machine to the default resource pool, network, and folder as set in the inventory mappings section. Remember, your real virtual machines are really being replicated to a LUN/volume on the storage array at the Recovery Site. You can treat these placeholders as an ancillary VM used just to complete the registration process required to get the virtual machine listed in the Recovery Site's vCenter inventory. Without the placeholder VMs, there would be no object to select when you create Recovery Plans.
If you think about it, although we are replicating our virtual machines from the Protected Site to the Recovery Site, the VMX file does contain site-specific information, especially in terms of networking. The VLAN and IP address used at the recovery location could differ markedly from the protected location. If we just used the VMX as it was in the replicated volume, some of its settings would be invalid (port group name and VLAN, for example), but others would not change (amount of memory and CPUs).
The main purpose of placeholder VMX files is that they help you see visually in the vCenter inventory where your virtual machines will reside prior to executing the Recovery Plan. This allows you to confirm up front whether your inventory mappings are correct. If a virtual machine does not appear at the Recovery Site, it's a clear indication that it is not protected. It would have been possible for VMware to create the virtual machine at the Recovery Site at the point of testing the Recovery Plan, but doing it this way gives the operator an opportunity to fix problems before even testing a Recovery Plan.
So, before you begin configuring the array manager of Protection Groups, you should create a small, 5–10GB volume on the storage array of your choice and present that to all the ESX hosts that will perform DR functions. For example, on my EMC NS-120 array I created a 5GB LUN visible to my Recovery Site ESX hosts (esx3/4), called using EMC's Virtual Storage Console formatted with VMFS, and giving it a friendly volume name of SRM_Placeholders. It's a good practice to keep the placeholder datastores relatively small, distinct, and well named to stop people from storing real VMs on them. If you wish, you could use datastore folders together with permissions to stop this from happening.
It's worth stating that if you ever want to run your Recovery Plan (failover) for real, either for planned migration or for disaster recovery, you would need a placeholder datastore at the Protected Site as well for returning to the production location as part of any reprotect and automated failback procedure. This has important consequences if you want to easily use the new automatic failback process or reprotect features. I'd go so far as to say that you might as well create a placeholder volume at both locations at the very beginning.
This placeholder datastore needs to be presented to every ESX host in the cluster that would act as a recovery host in the event of DR. The datastore could be used across clusters if you so wished, so long as it was presented to all the hosts that need to have access to it in the site. For me, each cluster represents an allocation of memory, CPU, network, and storage. In my case, I created placeholder datastores at New Jersey used in the process of protecting VMs in New York, and similarly I created placeholder datastores at New York used in the process of protecting VMs in New Jersey. In most cases you will really need only one placeholder datastore per cluster. As I knew at some stage I would need to do a failover and failback process in SRM it made sense to set these placeholder datastores at this stage, as shown in Figure 9.15.
Figure 9.15 Placeholder datastores should be on nonreplicated datastores available to all hosts in the datacenter or clusters where SRM is in use.
Remember, the smallest VMFS volume you can create is 1.2GB. If the volume is any smaller than this you will not be able to format it. The placeholder files do not consume much space, so small volumes should be sufficient, although you may wish to leverage your storage vendor's thin-provisioning features so that you don't unnecessarily waste space—but hey, what's a couple of gigabytes in the grand scheme of things compared to the storage footprint of the VMs themselves? On NFS you may be able to have a smaller size for your placeholder datastore; much depends on the array—for example, the smallest volume size on my NetApp FAS2040 is 20GB.
It really doesn't matter what type of datastore you select for the placeholder VMX file. You can even use local storage; remember, only temporary files are used in the SRM process. However, local storage is perhaps not a very wise choice. If that ESX host goes down, is in maintenance mode, or is in a disconnected state, SRM would not be able to access the placeholder files while executing a Recovery Plan. It would be much better to use storage that is shared among the ESX hosts in the Recovery Site. If one of your ESX hosts was unable to access the shared storage location for placeholder files, it would merely be skipped, and no placeholder VMs would be registered on it. The size of the datastore does not have to be large; the placeholder files are the smaller files that make up a virtual machine, they do not contain virtual disks.
But you might find it useful to either remember where they are located, or set up a dedicated place to store them, rather than mixing them up with real virtual machine files. It is a good practice to use folder and resource pool names that reflect that these placeholder virtual machines are not "real." In my case, the parent folder and resource pool are called "NYC_DR" at the New Jersey Recovery Site. Once the placeholder datastore has been created, you can configure SRM at the Protected Site and use it to create the "shadow" VMs in the inventory.
- In SRM, select the Protected Site; in my case, this is the New York site.
Select the Placeholder Datastores tab (see Figure 9.16).
Figure 9.16 The Placeholder Datastores tab
- Click the Configure Placeholder Datastore link.
- In the subsequent dialog box, select the datastore(s) you created.
)
){kind=link}
){kind=link}
The dialog box in Figure 9.16 does allow you to add multiple placeholder datastores for each cluster that you have. The choice is yours: one placeholder datastore for all your clusters, or one placeholder datastore for each cluster in vCenter. Your choice will very much depend on your storage layer and policies within your organization. For example, if you are using IP-based storage it will be very easy to present an iSCSI or NFS volume across many VMware clusters. If you're using Fibre Channel, this could involve some serious work with zoning and masking at the switch and storage management layer. It may be your storage team's policy that each ESX host in a VMware cluster represents a block of storage or a "pod" that cannot be presented to other hosts outside the cluster.
If you look closely at the screen grab you can see that from New York Site (Local), I am browsing the datastores in the New Jersey vCenter. From there I can locate the datastore I called "NYC_SRM_Placeholders" as the location for the placeholder files. I configured a similar setup at the New Jersey location to facilitate the new automatic failback and reprotect features in SRM.