SRM Windows upgrade to SRM Appliance with SRDF SRA

Now that VMware has a number of SRM releases that support the Appliance model (8.3-8.5), more and more customers are taking the leap to move off their Windows implementation. VMware provides a procedure to make the transition which applies to any SRM environment whether it is using an SRA or not. I’ve been reticent, therefore, to comment on this upgrade because it is owned by VMware and they would be the point of contact if a customer had any issues following said procedure. However, I have spoken to a number of customers who were simply confused about how our SRDF SRA figures into the upgrade so I’ll try to clear a few things up.

Procedure

Just so we’re on the same page, here is the current process for upgrading to the SRM Appliance. I’ve only included the high-level steps. Refer to the VMware documentation for all the detail.

I am only discussing the upgrade of SRM to the appliance here, not upgrading the SRDF SRA. But let me make clear, that while you could run Windows SRM on one site and Dockers SRM on the other site, you cannot run two different versions of the SRDF SRA. In other words we do not support rolling upgrades. Each site must have the same SRDF SRA and same Solutions Enabler versions.

Prerequisites

  • Windows SRM must be at 8.3
  • The SRM service on Windows should be shutdown (do both sites)
  • Deploy two SRM Appliances (protection and recovery sites). Note they could be the same IP and hostname as your current one but don’t need to be.
  • <this one is mine> Make sure your SRM environment is clean – no recovery plans in test mode, etc.

Procedure

  1. Log in to the Site Recovery Manager for Windows host machine (protection site).
  2. Open a command prompt and navigate to the bin folder in the Site Recovery Manager installation directory %SRM_INSTALL_DIR%\bin.
  3. Run the following script: export-srm-data.bat <export_dir>
  4. Log in to the SRM Appliance Management Interface as admin and enable SSH so that you can copy the migration files and connect to the appliance to complete the migration (protection site).
  5. Transfer the exported directory to the SRM Appliance host machine.
  6. Shut down the Windows host machine.
  7. Log in to the SRM Appliance host machine as root (first admin then change user).
  8. Run the following script: /opt/vmware/srm/bin/import-srm-data.sh <export_dir>
  9. (Optional) Import the Storage Replication Adapters (SRAs) through the SRM Appliance Management Interface.
  10. On the Site Recovery home tab, select the site pair, and click Actions > Reconnect.

OK now that you’ve run through the high-level let’s go over the areas that customers ask about and add some nuance.

SRA tied to platform

Our SRDF SRA comes in two distributions: Windows and Appliance (or Docker). The SRA is tied to the platform. If you currently run Windows, you installed the SRA on the SRM Windows box. We even do some checking to make sure the software is there before installing. When you upgrade to the SRM Appliance you will install the Docker version of the SRA. You cannot use the SRM Appliance and “point to” the SRA on the Windows box. No such thing. The SRA is just a piece of software like SRM. But we will talk below about XML files.

Solutions Enabler

I would say in a good amount of Windows SRM environments I’ve seen, customers use what I call a collapsed tier. They install vCenter, SRM, and Solutions Enabler (SE) all on the same box. This makes it really easy because your SE client and server is the same thing. This requires presenting Gatekeepers (those pesky small RDMs) to that Windows box. Other customers choose to use a client/server model where they install SE on some other Windows or Linux box. And a small number of customers use the embedded SE environment on the array itself. We generally don’t recommend that since it makes scaling difficult, but for simple environments it isn’t an issue and it avoids having to deal with RDMs.

When you run VMware’s migration, all those settings you export and import represent all parts of SRM, including the array managers (SE). Therefore after following the procedure you should end up with an operational environment, including SE seeing the arrays and array pairs. One difference to understand about the SRDF SRA on the SRM Appliance is that it is a client/server model. Because the SRA runs in Docker and we don’t support SE on Docker, there must be an external SE. With Windows SRM you can do that collapsed tier I mentioned where SE lives on the same box. Let’s look at two scenarios of how this plays out for the migration.

SE on non-SRM host

If you are running a client/server model currently with Windows SRM, you’re basically good. VMware will bring in the array managers (IPs or hostnames) that already point to an external SE server be that a host or embedded on the array. You’ll have to do a rediscovery of pairs to be sure the handshake is made (certificates), but that should happen in the course of the migration.

SE on Windows box

Now if you run your SE server (client is always required) on the same box as SRM and you plan on keeping it with the SRM Appliance, you do not want to follow step 6 from the migration of shutting down the Windows box, since that would result in losing SE access. Instead just stop all SRM services on the Windows box. But this also limits your ability to keep the same hostname and IP when you deploy the SRM Appliance. VMware does not require that, however.

SRDF SRA XML files

This is probably the biggest pain point of migration. If you have made any changes to the Windows XML files that are part of the SRDF SRA you’ll need to bring those changes over manually to the appliance. Changing the XML files on Windows is easy, on the SRM Appliance not so much. On the appliance you’ll have to download the config files and make changes and then upload them. The process is covered in the TechBook and various blog posts. Do NOT copy the files from Windows directly to the appliance ones. You’ll get errors uploading the config file. Most customers use the default settings and adjust for AutoTargetDevice so typically you’d only have to make a change to the global options file.

Recommendations

  • If you currently run SE on your Windows SRM server I suggest you keep it for the migration if you don’t mind changing the hostname and IP of your new SRM Appliance. It will just make life that much easier initially. You can always rename your SRM Appliance later (not hard) and then create a new SE server.
  • I know it’s a pain, but do a test migration. I’ve had problems with VMware’s export/import process and you want a clean migration.

References

  • Be sure you use the hot fix version of the SRDF SRA for Dockers. I have two posts which will be useful. This was the first one before the hot fix. It covers the install. This second one is for the hot fix. The big difference between the builds is when you run the enableAutoSSLCertGen.sh script. Before the hot fix you ran the script before the install, now you run it after.
  • TechBook
  • VMware documentation
Advertisement

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Website Powered by WordPress.com.

Up ↑

%d bloggers like this: