vSphere 6.5 Upgrade Considerations Part-3（vSphere 6.5升级注意事项第3部分）

vSphere 6.5升级注意事项第3部分

Emad Younis发布了2017年8月20日

https://blogs.vmware.com/vsphere/2017/08/vsphere-6-5-upgrade-considerations-part-3.html

3条留言

鸣叫

更新10/3/17 –为示例场景添加了按请求需求和决定的部分，并更新了博客文章以反映这些更改。

我们首先讨论了构成成功的vSphere 6.5升级的概念和过程。然后是时候利用我们在本系列的第一篇博客文章中学到的知识，并将其应用于特定的情况。第一种情况涉及将环境从vSphere 5.5升级到6.5。现在，让我们集中讨论如何将环境从vSphere 6.0升级到6.5 Update1。我们将逐步介绍另一个示例场景，该场景可能会也可能不会覆盖您的特定环境。关键要点是了解升级过程和概念，以便您可以将其应用于自己的环境。

情境

这家Awesome Sticker公司拥有五个数据中心站点，其中三个位于美国，两个位于欧洲。每个站点都使用vCenter Server Appliance（VCSA）运行vSphere 6.0。他们使用外部部署模型来增强链接模式。有三个vSphere Single Sign-On域（SSO）：美国，欧洲和VDI。与其他部署不同，VDI环境使用嵌入式Windows vCenter Server。vSAN是该公司的主要存储。该公司还仅在美国数据中心中使用SRM进行灾难恢复。

管理层已责成其新系统工程师Kyle将环境升级到vSphere 6.5。Kyle已经从硬件兼容性列表中验证了每个站点上当前的Dell硬件是否与vSphere 6.5 兼容。他也很主动，并开始为每种产品的升级路径添加白板。

环境发现

刚接触环境Kyle想花一些时间来评估环境。当前环境正在运行vSphere 6.0 Update3。在查看发行说明时，Kyle注意到不支持从6.0 Update 3升级到vSphere 6.5。Kyle是vSphere博客的狂热读者，了解到vSphere 6.5 Update 1 现在可用，并且支持从vSphere 6.0 Update 3进行升级。他现在可以继续进行升级。他还想花一些时间对环境进行评估。凯尔还计划与每个部门的业务负责人举行会议。同时，他开始注意到他对环境的观察：

每个站点只有一个平台服务控制器（PSC）。
每个站点上的vCenter Server均未正确备份。
在欧洲的一个数据中心中运行着Nexus 1000v。
用于VDI环境的Windows vCenter Server。
SRM仅在美国数据中心中使用，在欧洲站点中没有DR解决方案。
用于主机管理和vMotion的虚拟标准交换机。
没有ISO的集中管理。
清理虚拟交换机端口名称。当前，端口组名称不一致，需要清理。

要求和决定

单个PSC的外部部署

如前所述，Kyle观察到，每个站点只有一个外部PSC，并且可能是单个故障点。凯尔（Kyle）正在考虑将每个站点更改为多个PSC。这一切都取决于公司的可用性需求，并且知道PSC在环境中扮演什么角色。PSC提供vSphere SSO域的身份验证和管理。我们也不能不谈论服务级别协议（SLA）。凯尔必须与公司中的各个业务部门进行讨论，这将有助于确定RPO和RTO要求。所有这些信息将考虑每个站点上是否实际需要辅助PSC或产生开销。让我们考虑一下PSC不在线时发生的情况及其在vSphere SSO域中的角色。

用户无法登录和管理注册到不在线的PSC的vCenter Server。一个单独的PSC在vSphere 6.5 Update 1 SSO域中最多可以注册15个vCenter Server（不推荐）。vCenter Server一次只能注册一个PSC（1：1）。
工作负载仍在运行，但是无法进行任何新的更改或部署。
只有增强型链接模式才需要外部PSC，否则，请使用嵌入式部署。
vSphere 6.5不支持跨站点重定向-仅在站点内部。这要求在每个站点上都有一个辅助PSC。
负载平衡器为使用PSC进行身份验证的vCenter Server和其他产品提供自动故障转移。权衡是增加的复杂性。
对于没有vCenter Server高可用性（VCHA）的外部部署，负载平衡器是可选的。
VCHA的外部部署需要PSC的负载平衡器，因为它不知道手动重定点。另外，如果要保护vCenter Server，则也应保护PSC。
使用PSC手动重定向vCenter Server和其他产品以通过cmsso-util进行身份验证。权衡是手动干预。
vSphere SSO域内的线性拓扑结构，易于管理，并且在PSC上没有额外的开销。建议通过使用vdcrepadmin添加复制协议以具有辅助数据路径来创建环。
在修补或升级期间，重新指向可以减少vCenter Server的停机时间。

重要资源可帮助指导vSphere拓扑规划和升级

vSphere 6.5拓扑和升级计划工具
vCenter Server和Platform Services 6.5体系结构
vCenter Server和Platform Services Controller部署类型
vCenter Server和Platform Services Controller 6.5高可用性
vSphere 6.5 Update 1最大值指南（自vSphere 6.5 GA起增加）
了解混合版本vCenter Server部署的影响

vCenter Server备份
如果vCenter Server发生故障，确保可以从中进行恢复的适当备份非常重要。Awesome Sticker公司拥有一个备份团队，该团队使用第三方备份产品来处理所有工作负载。vCenter Server和PSC从未包含在备份解决方案和计划中。

Kyle正在与他们合作，以确保它支持VADP（VMware vSphere存储API –数据保护）并可以进行映像级备份。
vCenter Server Appliance 6.5具有内置的基于文件的备份和还原。这支持嵌入式和外部PSC部署。
- 可以在VCSA或PSC运行时进行备份，而无需停止。
- 使用VCSA 6.5 ISO进行还原，该镜像用于从中进行部署，不需要任何代理。
- REST API可用于自动化。
- Windows vCenter Server VDI将在迁移之前使用第三方备份解决方案进行映像级备份。

VCSA备份的重要参考

KB 2091961 –备份和还原vCenter Server Appliance / vCenter Server 6.0 vPostgres数据库
仅Postgres DB的VCSA备份是不够的，需要备份整个设备
- 熟悉vPostgres和vCenter Server Appliance –第2部分
- 熟悉vPostgres和vCenter Server Appliance –第1部分
- 熟悉vPostgres和vCenter Server Appliance –第3部分
KB 2144536重新安装/迁移vCenter Server 6.X（仅Windows）

网络

凯尔（Kyle）注意到，其中一个欧洲数据中心正在运行Nexus 1000v。在阅读vSphere 6.5 Update 1发行说明时，他发现这将是支持第三方交换机（例如Cisco Nexus 1000）的最新版本。Kyle决定借此机会迁移到VMware虚拟分布式交换机（VDS）。他还将利用这段时间来清理他要解决的其他一些网络项目。

他将使用Nexus 1000v到VDS 迁移工具将该环境迁移到虚拟分布式交换机（VDS）。
凯尔（Kyle）编写了powercli脚本来查找环境中的任何空端口组，并计划使其退役。
端口组将被重命名为有意义的名称，因为每个端口组均被列为具有随机数的端口组。
vSphere 6.5仅允许在同一网络文件夹中的所有VDS和分布式端口组中使用唯一名称。vSphere的早期版本允许使用相同的名称KB 2147547。
由于Kyle正在迁移到VDS，因此他还计划将管理和vMotion端口组从VSS迁移到VDS。

VDS的重要参考

使用vSphere Web Client导出/导入/还原分布式交换机配置
KB 2120663与VMware vSphere 5.1.x，5.5.x和6.x的链路聚合控制协议（LACP）
常见问题解答：停止第三方vSwitch程序（2149722）

内容管理

公司的ISO遍地都是，已经成为管理的噩梦。凯尔（Kyle）注意到其中有些存储在不同的vSAN数据存储中。此外，企业所有者在其本地计算机上存储了多个存储空间，占用了大量空间。凯尔（Kyle）一直在考虑建立一个集中式图书馆，并让不同的企业主订阅。他提出了以下清单：

在订阅模型中在每个数据中心实现内容库
vSphere 6.5使用Content Library作为选项，可以使用Content Library ISO文件选项在VM上安装新的操作系统和应用程序。这将有助于确保不会将ISO复制到数据存储或本地计算机上。
企业所有者现在可以在下载ISO之前检查其内容库，以避免重复。
在ISOs之后，Kyle将研究VM模板。VM模板可以由内容库管理，但当前为OVF格式。

升级顺序

凯尔（Kyle）通过VMware全球支持服务（GSS）开创了主动式SR，这是为即将到来的升级做好准备的第一步。由于存在三个不同的vSphere SSO域，因此Kyle决定将解决最小的占用空间并逐步发展。他的攻击计划始于VDI环境，然后是欧洲数据中心，最后是美国数据中心。

VDI环境
在开始VDI环境升级之前，Kyle在开始之前进行了备份。

注意：在此处运行以下脚本，以获取估计迁移过程可能花费的时间。如果出现问题，请在估计的时间中增加缓冲区。

嵌入式vCenter Server 6.0 U3将需要迁移到6.5 U1。所有组件（PSC，VC，VUM）都驻留在一个虚拟机上，并将迁移到具有嵌入式PSC的VCSA。这将使用VCSA 6.5 Update 1 ISO中包含的迁移工具来完成。
将Horizon View服务器从7.0 升级到7.2。确保以正确的顺序升级Horizon View组件。
使用VUM升级VDI环境的ESXi主机。
升级VM工具，然后在虚拟桌面中升级Horizon Agent。
配置vCenter Server协议（FTP，FTPS，HTTP，HTTPS，SCP）进行备份。本机备份可以手动完成，也可以使用API自动执行。

欧洲数据中心

使用Nexus 1000v到VDS迁移工具并完成网络清理任务。
升级之前，请备份PSC和vCenter Server。是的，您可以拍摄快照，但无需关闭所有PSC即可。请记住，PSC是多主机的，因此所有信息都在vSphere域中复制。
首先将vSphere SSO域中的所有PSC从6.0 U3升级到6.5 U1。在这种情况下，我们只有两个，但是稍后将添加其他PSC。挂载VCSA 6.5 U1 ISO并从安装程序菜单中选择升级选项，然后通过向导升级PSC。现在，环境处于混合模式，重要的是尽快升级vSphere SSO域内的所有vCenter Server设备。混合模式没有强制性的时间限制，但是从故障排除角度来看，最好将两个vCenter Server组件（PSC和vCenter Server）安装在同一版本上，并在vCenter Server 6.5中获得所有新功能。
通过安装VCSA 6.5 U1 ISO并从安装程序菜单中选择升级选项，将vSphere SSO域内的所有vCenter Server Appliance从6.0 U3升级到6.5 U1。
因为只有两个PSC，所以每个站点一个，我们必须确保在使用vdcrepadmin完成操作后清理一些复制协议。如果PSC发生故障，这还将使Kyle能够在每个站点内手动重新指向。尽管他喜欢使用负载平衡器进行自动故障转移的想法，但他不希望它带来额外的复杂性。
- 伦敦站点中的原始PSC＃1与柏林站点中的原始PSC＃2连接。
- 在伦敦站点London中部署新的辅助PSC＃2，复制伙伴是伦敦站点中的原始PSC＃1。
- 在柏林站点中部署新的辅助PSC＃2，复制伙伴是柏林站点中的原始PSC＃1。
- 使用vdcrepadmin创建一个新的复制协议，从柏林站点中的PSC＃2到伦敦站点中的PSC＃1。
- 清理伦敦站点中原始PSC＃1与柏林站点中原始PSC＃1之间的旧复制协议。
升级vSAN。
升级SRM。
使用VUM升级ESXi主机。
升级VM工具/兼容性。
升级VMFS。
配置vCenter Server协议（FTP，FTPS，HTTP，HTTPS，SCP）进行备份。本机备份可以手动完成，也可以使用API自动执行。您只需要备份vSphere SSO域中的一个PSC，但是备份所有PSC并没有什么害处。仅当PSC都崩溃时才需要PSC的还原过程，否则只需部署新的即可。

美国数据中心

完成网络清理任务。
升级之前，请备份PSC和vCenter Server。是的，您可以拍摄快照，但无需关闭所有PSC即可。请记住，PSC是多主机的，因此所有信息都在vSphere域中复制。
首先将vSphere SSO域中的所有PSC从6.0 U3升级到6.5 U1。在这种情况下，我们只有两个，但是稍后将添加其他PSC。挂载VCSA 6.5 U1 ISO并从安装程序菜单中选择升级选项，然后通过向导升级PSC。现在，环境处于混合模式，重要的是尽快升级vSphere SSO域内的所有vCenter Server设备。混合模式没有强制性的时间限制，但是从故障排除角度来看，最好将两个vCenter Server组件（PSC和vCenter Server）安装在同一版本上，并在vCenter Server 6.5中获得所有新功能。
通过安装VCSA 6.5 U1 ISO并从安装程序菜单中选择升级选项，将vSphere SSO域内的所有vCenter Server Appliance从6.0 U3升级到6.5 U1。
在每个站点上添加一个辅助PSC，在每个站点上添加一个辅助PSC，确保在使用vdcrepadmin完成操作后必须清理一些复制协议。
- Seattle站点中的原始PSC＃1连接到Austin站点中的原始PSC＃2。
- 奥斯汀站点中的原始PSC＃2连接到坦帕站点中的原始PSC。
- 在西雅图站点中部署新的辅助PSC＃2，复制伙伴是西雅图站点中的原始PSC＃1。
- 在Austin站点中部署新的辅助PSC＃2，复制伙伴是Austin站点中的原始PSC＃1。
- 在坦帕站点中部署新的辅助PSC＃2，复制伙伴是坦帕站点中的原始PSC＃1。
- 使用vdcrepadmin创建一个新的复制协议，从Tampa站点中的PSC＃2到该环网的Seattle站点中的PSC＃1。
- 在西雅图站点中新部署的PSC＃2与奥斯汀站点中的PSC＃1之间创建新的复制协议。
- 在奥斯汀站点中新部署的PSC＃2与坦帕站点中的PSC＃1之间创建新的复制协议。
- 清理西雅图站点中原始PSC＃1与奥斯汀站点中原始PSC＃1之间的旧复制协议。
- 清理Austin站点中原始PSC＃1与Tampa站点中原始PSC＃1之间的旧复制协议。
- 使用vdcrepadmin验证您是否具有良好的线性拓扑
升级vSAN
升级SRM。
使用VUM升级ESXi主机。
升级VM工具/兼容性。
升级VMFS。
配置vCenter Server协议（FTP，FTPS，HTTP，HTTPS，SCP）进行备份。本机备份可以手动完成，也可以使用API自动执行。您只需要备份vSphere SSO域中的一个PSC，但是备份所有PSC并没有什么害处。仅当PSC都崩溃时才需要PSC的还原过程，否则只需部署新的即可。

验证方式

在整个升级过程中，Kyle使企业所有者始终处于循环中。从最初的会议开始，以解释什么是升级过程以及对他们意味着什么。这些会议还可以作为采访企业并了解其当前问题和要求的工具。Kyle还积极主动地让企业所有者在vSphere 6.5 Update 1实验室环境中测试其应用程序。提交的变更控制Kyle的详细信息中也记录了这一点。变更控制还包括回滚计划以及业务所有者将在验证测试中进行的测试。一旦企业所有者批准了他们的应用程序，Kyle就可以迁移到下一个环境。

结论

Kyle的任务是将环境从vSphere 6.0 U3升级到vSphere 6.5 Update1。在开始研究之前，他致力于快速了解vSphere 6.5 Update 1的新增功能。他还观看了新的vCenter Server灯板视频，以了解有关vCenter的信息。服务器体系结构，部署和可用性是此升级过程的一部分。由于不需要vCenter High Availability，因此Kyle能够在每个站点上添加辅助PSC，而无需使用所需的负载均衡器来降低复杂性。他在开始升级过程之前先进行了备份，并制定了恢复/退出计划，以防万一需要还原。重要的重要收获是了解升级过程和概念并将其应用于您自己的环境。祝升级愉快！

Update 10/3/17 – by request requirements and decisions section has been added for the example scenario and blog post updated to reflect these changes.

We’ve started out by discussing the concepts and processes that make up a successful vSphere 6.5 Upgrade. Then it was time to take what we’ve learned in the first blog post of this series and apply it to a particular scenario. The first scenario covered upgrading an environment from vSphere 5.5 to 6.5. Now let’s focus on how to upgrade an environment from vSphere 6.0 to 6.5 Update1. We will be walking through another example scenario which may or may not cover your particular environment. The key takeaway is understanding the upgrade process and concepts so you can apply them to your own environment.

Scenario

The Awesome Sticker company has five datacenter sites, three in the US and two in Europe. Each site is running vSphere 6.0 using the vCenter Server Appliance (VCSA). They are using an external deployment model for enhanced linked mode. There are three vSphere Single Sign-On domains (SSO) US, Europe, and VDI. Unlike the other deployments, the VDI environment is using an embedded Windows vCenter Server. vSAN is the company’s primary storage. The company also uses SRM for disaster recovery in currently only the US data centers.

Management has tasked Kyle, their new systems engineer, with upgrading the environment to vSphere 6.5. Kyle has already verified the current Dell hardware at each site is compatible with vSphere 6.5 from the hardware compatibility list. He was also proactive and started whiteboarding the upgrade path of each product.

Environment Discovery

Being new to the environment Kyle wanted to take some time and do an assessment of the environment. The current environment is running vSphere 6.0 Update 3. Reviewing the release notes, Kyle notices upgrades from 6.0 Update 3 to vSphere 6.5 are not supported. An avid reader of the vSphere blog, Kyle learned vSphere 6.5 Update 1 was now available and supports upgrades from vSphere 6.0 Update 3. He can now proceed with upgrading. He also wanted to take some time and do an assessment of the environment. Kyle is also planning to setup a meeting with the business owners of each department. In the meantime he started noting his observations about the environment:

Each site only has one Platform Services Controller (PSC).
vCenter Servers at each site are not properly backed up.
There is a Nexus 1000v running in one of the European data centers.
Windows vCenter Server used for VDI environment.
SRM is only used in the US datacenter, no DR solution in the Europe sites.
Virtual Standard Switches used for host management and vMotion.
No centralized management of ISOs.
Clean up of virtual switch port names. Currently, portgroup names are inconsistent and need to be cleaned up.

Requirements and Decisions

External Deployment with single PSC

As noted previously, Kyle observed that there is only a single external PSC at each site and could be a single point of failure. Kyle is considering changing to multiple PSCs per site. This all comes down to the availability needs of the company and knowing what role the PSC plays in the environment. The PSC provides authentication and management of the vSphere SSO domain. We also can’t talk about availability without mentioning Service Level Agreements (SLAs). The discussion Kyle is having with the different BUs in the company is a must and will help determine RPO and RTO requirements. All this information will factor in if a secondary PSC at each site is actually required or an overhead. Let’s consider what happens when a PSC is not online and its role in the vSphere SSO domain.

Users cannot login and manage the vCenter Server registered to the PSC that is not online. A single PSC can have as many as 15 vCenter Server registered in a vSphere 6.5 Update 1 SSO domain (not recommended). vCenter Server can only be registered with one PSC at a time (1:1).
Workloads are still running, but no new changes or deployments can take place.
External PSC is required only for enhanced linked mode, otherwise, use an embedded deployment.
Repointing across sites is not supported in vSphere 6.5 – only intra-site. This requires having a secondary PSC at each site.
A load balancer provides automatic failover for vCenter Server and other products using PSC for authentication. The trade-off is the added complexity.
A load balancer is optional for external deployments without vCenter Server High Availability (VCHA).
An external deployment with VCHA requires a load balancer for the PSCs as it’s not aware of the manual repoint. Also if protecting vCenter Server, PSC should be protected as well.
Manual repoint of vCenter Server and other products using PSC for authentication via cmsso-util. The trade-off is manual intervention.
Linear topology within the vSphere SSO domain, easier to manage and provides no extra overhead on the PSCs. The recommendation is to create a ring by adding a replication agreement using vdcrepadmin to have a secondary data path.
During patching or upgrades repointing can reduce downtime of vCenter Server.

Important resources to help guide with vSphere topology planning and upgrades

vSphere 6.5 Topology and Upgrade Planning Tool
vCenter Server and Platform Services 6.5 Architecture
vCenter Server and Platform Services Controller Deployment Types
vCenter Server and Platform Services Controller 6.5 High Availability
vSphere 6.5 Update 1 Maximums Guide (increased since vSphere 6.5 GA)
Understanding the Impacts of Mixed-Version vCenter Server Deployments

vCenter Server Backups
In case of a vCenter Server failure, it is important to ensure a proper backup is available to recover from. The Awesome Sticker company has a backup team that uses a 3rd party backup product for all workloads. vCenter Server and PSC were never included as part of the backup solution and schedule.

Kyle is working with them to ensure it supports VADP (VMware vSphere Storage APIs – Data Protection) and can take image level backups.
vCenter Server Appliance 6.5 has built-in file-based backup & restore. This supports both embedded and external PSC deployments.
- Backup can be taken while VCSA or PSC is running, no quiescing.
- Restore using the VCSA 6.5 ISO which was used to deploy from, no agents needed.
- REST APIs available for automation.
- Windows vCenter Server for VDI will use 3rd party backup solution for image-level backups until migrated.

Important References for VCSA backups

KB 2091961 – Backup and restore vCenter Server Appliance/vCenter Server 6.0 vPostgres database
Postgres DB only backups for VCSA are not sufficient, requires entire appliance be backed up
- Getting Comfortable with vPostgres and the vCenter Server Appliance – Part 2
- Getting Comfortable with vPostgres and the vCenter Server Appliance – Part 1
- Getting Comfortable with vPostgres and the vCenter Server Appliance – Part 3
KB 2144536 Reinstalling / Migrating vCenter Server 6.X ( Windows Only)

Network

Kyle noticed there is a Nexus 1000v running in one of the European datacenters. In reading the vSphere 6.5 Update 1 release notes he discovered this will be the last release to support a 3rd party switch such as the Cisco Nexus 1000. Kyle has decided to take the opportunity to migrate to the VMware Virtual Distributed Switch (VDS). He will also use this time to clean up a few other network items he wants to address.

He will use the Nexus 1000v to VDS migration tool to move this environment to a Virtual Distributed Switch (VDS).
Kyle wrote a powercli script to find any empty portgroups in the environment and plans to have them decommissioned.
The portgroups will be renamed to something meaningful since each is listed as portgroup with a random number.
vSphere 6.5 allows only unique names across all VDS and Distributed portgroups in the same network folder. Prior versions of vSphere allowed the same name KB 2147547.
Since Kyle is migrating to a VDS he also plans to migrate the management and vMotion portgroups from a VSS to VDS.

Important References for VDS

Exporting/importing/restoring Distributed Switch configs using vSphere Web Client
KB 2120663 Link Aggregation Control Protocol (LACP) with VMware vSphere 5.1.x, 5.5.x and 6.x
FAQ: Discontinuation of third party vSwitch program (2149722)

Content Management

The company’s ISOs are all over the place and has become a management nightmare. Kyle noticed that some are placed on different vSAN datastores. Also, the business owners have several stored on their local machines, taking up large amounts of space. Kyle has been looking at creating a centralized library and having the different business owners subscribe. He has come up with the following list :

Implementing Content Library at each datacenter in a subscription model
vSphere 6.5 uses Content Library as an option to install new operating systems and applications on VMs using Content Library ISO file option. This will help ensure that ISOs don’t get copied to a datastore or local machine.
Business owners can now check their content library before downloading an ISO to avoid duplicates.
After ISOs Kyle will look at VM templates. VM templates can be managed by content library, but currently in OVF format.

Upgrade Order

Kyle opened a proactive SR with VMware Global Support Services (GSS) as the first step in getting ready for his upcoming upgrade. Since there are three different vSphere SSO domains, Kyle has decided that he will tackle the smallest footprint and work his way up. His plan of attack starts with the VDI environment, then the European datacenters, and finally the US datacenters.

VDI Environment
Before starting the VDI environment upgrade Kyle took a backup prior to starting.

Note: Run the following script here to get an estimated time of how long the migration process will potentially take. Add buffer to the estimated time in case of issues.

The embedded vCenter Server 6.0 U3 will need to be migrated to 6.5 U1. All of the components (PSC, VC, VUM) reside on one virtual machine and will be migrated to a VCSA with embedded PSC. This will be done using the migration tool included in the VCSA 6.5 Update 1 ISO.
Upgrade Horizon View server from 7.0 to 7.2. Make sure to upgrade the horizon view components in the correct order.
Use VUM to upgrade the ESXi hosts for the VDI environment.
Upgrade VM tools, then upgrade the horizon agent in the virtual desktops.
Configure vCenter Server protocol (FTP, FTPS, HTTP, HTTPS, SCP) for backup. The native backup can be done manually or can be automated using the APIs.

European Datacenters

Use the Nexus 1000v to VDS migration tool and complete network cleanup tasks.
Backup the PSCs and vCenter Servers prior to upgrading. Yes, you can take a snapshot, but there is no need to shut down all the PSCs to do so. Remember the PSCs are multi-master so all the information is replicated across the vSphere domain.
Upgrade all the PSCs in the vSphere SSO domain from 6.0 U3 to 6.5 U1 first. In this case, we only have two, but will be adding additional PSCs later. Mount the VCSA 6.5 U1 ISO and selecting the upgrade option from the installer menu and go through the wizard to upgrade the PSCs. Now that the environment is in mixed mode and it is important to upgrade all the vCenter Servers appliances within the vSphere SSO domain as soon as possible. There is no enforced time limit on mixed mode, but it is better to get both vCenter Server Components (PSC and vCenter Server) on the same version from a troubleshooting perspective and to gain all the new functionality in vCenter Server 6.5.
Upgrade all vCenter Server Appliances within the vSphere SSO domain from 6.0 U3 to 6.5 U1 by mounting the VCSA 6.5 U1 ISO and selecting the upgrade option from the installer menu.
Since there are only two PSCs, one at each site we will have to make sure that we clean up some replication agreements once we are done using vdcrepadmin. This will also give Kyle the ability to manually repoint within each site in case of a PSC failure. Although he liked the idea of the automated failover using the load balancer, he didn’t want the added complexity it brings.
- Original PSC #1 in the London site connected to original PSC #2 in the Berlin site.
- Deploy a new secondary PSC # 2 in the London site London, replication partner is the original PSC # 1 in the London site.
- Deploy new a secondary PSC #2 in the Berlin site, replication partner is the original PSC # 1 in the Berlin site.
- Use vdcrepadmin to create a new replication agreement from PSC # 2 in the Berlin site to PSC # 1 in the London site.
- Clean up old replication agreement between original PSC #1 in the London site and original PSC #1 in the Berlin site.
Upgrade vSAN.
Upgrade SRM.
Upgrade ESXi hosts using VUM.
Upgrade VM tools / compatibility.
Upgrade VMFS.
Configure vCenter Server protocol (FTP, FTPS, HTTP, HTTPS, SCP) for backup. The native backup can be done manually or can be automated using the APIs. You only need to backup one of the PSCs in the vSphere SSO domain, but there is no harm in backing all of them up. The restore process of a PSC is only required if they all go down otherwise just deploy new.

US Datacenters

Complete network cleanup tasks.
Backup the PSCs and vCenter Servers prior to upgrading. Yes, you can take a snapshot, but there is no need to shut down all the PSCs to do so. Remember the PSCs are multi-master so all the information is replicated across the vSphere domain.
Upgrade all the PSCs in the vSphere SSO domain from 6.0 U3 to 6.5 U1 first. In this case, we only have two, but will be adding additional PSCs later. Mount the VCSA 6.5 U1 ISO and selecting the upgrade option from the installer menu and go through the wizard to upgrade the PSCs. Now that the environment is in mixed mode and it is important to upgrade all the vCenter Servers appliances within the vSphere SSO domain as soon as possible. There is no enforced time limit on mixed mode, but it is better to get both vCenter Server Components (PSC and vCenter Server) on the same version from a troubleshooting perspective and to gain all the new functionality in vCenter Server 6.5.
Upgrade all vCenter Server Appliances within the vSphere SSO domain from 6.0 U3 to 6.5 U1 by mounting the VCSA 6.5 U1 ISO and selecting the upgrade option from the installer menu.
Add a secondary PSC at each site, one at each site we will have to make sure that we clean up some replication agreements once we are done using vdcrepadmin.
- Original PSC #1 in the Seattle site connected to original PSC#2 in the Austin site.
- Original PSC#2 in the Austin site connected to the original PSC in the Tampa site.
- Deploy a new secondary PSC # 2 in the Seattle site, replication partner is the original PSC # 1 in the Seattle site.
- Deploy a new secondary PSC #2 in the Austin site, replication partner is the original PSC # 1 in the Austin site.
- Deploy a new secondary PSC #2 in the Tampa site, replication partner is the original PSC # 1 in the Tampa site.
- Use vdcrepadmin to create a new replication agreement from PSC # 2 in the Tampa site to PSC # 1 in the Seattle site for the ring.
- Create a new replication agreement between newly deployed PSC #2 in the Seattle site with PSC #1 in the Austin site.
- Create a new replication agreement between newly deployed PSC #2 in the Austin site with PSC #1 in the Tampa site.
- Clean up the old replication agreement between original PSC #1 in the Seattle site and the original PSC #1 in the Austin site.
- Clean up the old replication agreement between the original PSC #1 in the Austin site and the original PSC # 1 in the Tampa site.
- Use vdcrepadmin to validate you have nice linear topology
Upgrade vSAN
Upgrade SRM.
Upgrade ESXi hosts using VUM.
Upgrade VM tools / compatibility.
Upgrade VMFS.
Configure vCenter Server protocol (FTP, FTPS, HTTP, HTTPS, SCP) for backup. The native backup can be done manually or can be automated using the APIs. You only need to backup one of the PSCs in the vSphere SSO domain, but there is no harm in backing all of them up. The restore process of a PSC is only required if they all go down otherwise just deploy new.

Validation

Kyle kept the business owners in the loop during the entire upgrade process. This started from the initial meeting to explain what the upgrade process was and what it would mean to them. The meetings also serve as a vehicle to interview the business and get a sense of their current issues and requirements. Kyle was also proactive having the business owners test their applications in a vSphere 6.5 Update 1 lab environment. This was also documented in the details of change control Kyle submitted. The change control also included a rollback plan and what testing the business owners would do in their validation testing. Once the business owners signed off on their application, Kyle was able to move to the next environment.

Conclusion

Kyle was tasked with upgrading an environment from vSphere 6.0 U3 to vSphere 6.5 Update 1. Before starting he did his research getting up to speed on what’s new with vSphere 6.5 Update 1. He also watched the new vCenter Server light board videos to learn about vCenter Server architecture, deployment, and availability as part of this upgrade process. Since vCenter High Availability was not a requirement, Kyle was able to add a secondary PSC at each site without the required load balancer reducing complexity. He backed up prior to starting the upgrade process and had a recovery/backout plan in case he needed to revert back. The important key takeaway is understanding the upgrade process and concepts and applying them to your own environment. Happy upgrading!