I’ve been getting some questions about the correct SRM and vSphere upgrade order from our customers lately. The default order of any vSphere environment is to begin with the vCenter Server of course but the more products and thus complexity you add to your environment, the upgrade order may change. In a multisite environment with external PSCs and vCenter Server Appliances you would normally upgrade all PSCs first and then the vCenter Servers. When SRM/vSphere Replication comes into play, the upgrade path is a bit different.
Before you begin the upgrade of the SRM/vSphere infrastructure, it is recommended that you check and verify the following:
SRM and vSphere upgrade order
The recommended SRM and vSphere upgrade with 2 sites looks as follow:
- Upgrade the PSCs and vCenter Server on the protected site.
- If you use vSphere Replication, upgrade the vSphere Replication deployment on the protected site.
- Upgrade Site Recovery Manager Server on the protected site.
- If you use array-based replication, upgrade the storage replication adapters (SRA) on the protected site.
- Upgrade the PSC and vCenter Server on the recovery site.
- If you use vSphere Replication, upgrade the vSphere Replication deployment on the recovery site.
- Upgrade Site Recovery Manager Server on the recovery site.
- If you use array-based replication, upgrade the storage replication adapters (SRA) on the recovery site.
- Verify the connection between the Site Recovery Manager sites.
- Verify that your protection groups and recovery plans are still valid.
- Upgrade ESXi Server on the recovery site.
- Next, upgrade ESXi Server on the protected site.
- And finaly, upgrade the virtual hardware and VMware Tools on the virtual machines on the ESXi hosts.
So, the rule of thumb in the SRM and vSphere upgrade order is to upgrade the components on the protected site before you upgrade the components on the recovery site. Upgrading the protected site first allows you to perform a disaster recovery on the recovery site if you encounter problems during the upgrade that render the protected site unusable. The exception are the ESXi hosts, which you can upgrade after you finish upgrading the other components on the protected and recovery sites.
It is important to note that If you configured SRM bidirectional protection, in which each site acts as the recovery site for the virtual machines on the other site, upgrade the most critical of the sites first.
The obvious question that pops up is that this upgrade order contradicts the conventional vSphere upgrade where you must upgrade all PSCs in sequence first. If you have 2 different SSO sites within the SRM infrastructure then, of course, this isn’t an issue. You will upgrade both sites as described in the steps above. But if you want to upgrade within one SSO domain, the procedure above is recommended and should be seen as an exception in the standard vSphere upgrade process.
Hope this clears up the upgrade order a bit and gives you an idea why it needs to be done this way.