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

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

Emad Younis发布了2017年7月7日

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

 

 本系列的  第一篇文章介绍了vSphere 6.5升级过程的第1阶段。第1阶段包含开始升级之前应做的所有前期工作。这包括熟悉新的vSphere 6.5功能和必要的文档。希望到现在为止，您已经完成了作业，并准备进入第二阶段，该阶段正在计划所有组件的升级步骤，安排与企业所有者的会议以收集需求，提交必要的变更控制并执行升级。

在接下来的几篇博客文章中，我们将介绍一些场景，这些场景将帮助您了解如何计划升级到vSphere 6.5。每个方案还将包括一组用于确定升级路径的要求和决策。这些示例可能与您当前的环境有关，也可能与您的当前环境无关。目的是帮助您熟悉升级过程和概念，然后将其应用于您的特定情况。

情境

这家惊人的T恤公司目前在加利福尼亚和纽约拥有两个数据中心站点。该公司最近在德克萨斯州收购了第三个站点，这将有助于他们的发行。每个站点都使用Windows上的嵌入式vCenter Server部署运行vSphere 5.5。该环境中的其他产品包括NSX，vRealize Automation（vRA），vRealize Operations（vROPS）和vRealize Log Insight（vRLI）。vRA使用的是与上述vCenter Server不同的vCenter Server端点。下面的示例图表表示每个产品的当前版本和目标（升级到）版本。每个产品随附的注释均来自其发行说明中的​​“安装或升级”部分。另外，请不要忘记添加正在使用的任何第三方产品（例如备份），以确定它们是否支持或具有升级路径，以便与vSphere 6.5兼容。

在阅读了所有新的vSphere 6.5功能之后，该公司的新的首席虚拟化架构师Adam决定现在该进行升级了。在开始升级过程之前，他已编制了一份业务需求列表，然后将列出相关的升级路径。vSphere 6.5升级项目估计需要三个月才能完成。这包括计划，协调，提交变更控制和验证。Adam的主要目标之一是在满足业务需求的同时，不要过度复杂化他的设计。这是Adam在与企业的主要利益相关者会面后制定的要求列表。

要求和决定

vSphere Single Sign-On域合并

拥有单个vSphere Single Sign-On（SSO）域将简化升级过程后的管理。从vSphere 6.0开始，许可，全局权限，自定义角色，单点登录和证书将在整个SSO域中复制，从而使跨多个vCenter Server的这些共享服务的管理更加轻松有效。

• 只能在vSphere 5.5中完成
• 这将需要从嵌入式部署到外部PSC部署的体系结构更改
• 将需要在升级过程之前完成
• 需要单独的变更控制和确认
• 中断只会影响环境的IT管理

增强链接模式

如今，每个站点都是自主运行的，这意味着每个站点都是独立管理的。这对亚当和他的团队而言效率不高。他们的目标是无论使用什么vSphere Client都对这三个站点具有可见性。

• 需要外部部署，将通过vSphere SSO域合并来完成
• 将新的vCenter Server添加到同一vSphere SSO域时自动继承；无需采取任何措施

迁移到vCenter Server Appliance

在功能和性能方面，vCenter Server Appliance 6.5超过其Windows同类产品。VCSA是VMware对vCenter Server的指导，从vSphere 6.5开始的所有新功能将仅在VCSA中：

• 本机vCenter Server高可用性
• 内置基于文件的备份还原
• vSphere Update Manager不再需要单独的Windows Server
• 支持的从Windows到VCSA的迁移工具

 高可用性

为了满足当前的10分钟RTO，Adam已决定同时利用vSphere HA和vCenter Server High Availability（VCHA）。这将确保公司免受主机和vCenter Server（应用程序）故障的影响。

• vSphere HA将再次保护主机故障
• vCenter Server VM重新启动优先级设置为最高
• vCenter Server HA需要使用负载平衡器以实现Platform Services Controller高可用性
• 支持的负载均衡器：F5，NetScaler和NSX
• VCHA提供5分钟的RTO

每个站点的集中日志记录

当前，每个站点内没有集中式日志记录。主机和vCenter Server使用默认设置，并且日志在每个单独的节点上维护。VMware免费为每个vCenter Server许可证提供25-OSI软件包。

• 每个站点的日志记录解决方案均无需额外费用（预算）
• 提供内容包
• 日志数据的仪表板和分析有助于故障排除
• 不限于vSphere产品，Windows和Linux代理可用
• 有限的功能集将需要升级到Log Insight的完整版本，以获取其他功能，例如群集，事件转发，存档等。
• Log Insight具有更多实践经验，并且可以在预算允许的情况下将来进行升级

兼容性

现在，Adam具有一组升级要求，下一步是验证每个产品的兼容性。这可以通过使用VMware产品互操作性矩阵来实现这是他在阶段1升级准备过程中现在所熟悉的文档之一。由于所有产品都与vCenter Server进行通信，因此应在第一步中选择它，标记为“选择解决方案”。有列出所有版本或指定特定版本号的选项。现在，vCenter Server将显示在表格的主要水平标题中。下一步是在“添加平台/解决方案”部分下列出还将升级的其他解决方案。下面的示例说明了vCenter Server 5.5的当前版本以及Adam将升级到6.5的版本。每个产品均显示Adam计划升级的版本，以确保它们与vSphere 6.5兼容。结果，Adam了解到NSX是唯一需要vCenter Server 6的产品。

升级顺序

执行升级之前的最后一步是列出操作顺序。此顺序在VMware vSphere升级文档中列出，并且随着时间的推移未更改。

1. vSphere SSO域整合将是第一项需要完成的任务，因为这是Adam的要求之一。请记住，这只能在vSphere 5.5上完成，一旦第一个节点更新到vSphere 6.5后，合并功能就不再可用。要注意的另一项是，这可能并不是每个人都需要的。如果这不是您的要求的一部分，请继续进行下一步，升级vCenter Server组件。以下  KB  提供了整合5.5版中的vSphere SSO域所需的详细信息。另外，请不要忘记查看vSphere 6.5的最大容量指南，以确保vSphere SSO域中受支持的Single Sign On服务器数量。
   
2. 如果您的部署是嵌入式的，则直接继续进行vCenter Server升级。在此示例中，存在跨多个站点的外部部署。要求之一是从基于Windows的vCenter Server迁移到vCenter Server Appliance。一个迁移升级类别也属于升级类别，因为它不仅将数据（默认情况下为配置/清单）从一个平台复制到另一个平台（Windows到Photon OS），而且还将版本从5.5升级到6.5。外部部署的第一步是首先升级或迁移vSphere SSO域内的所有Single Sign-On服务器。由于Single Sign-On Server 5.5版已升级到Platform Services Controllers 6.5版，而vCenter Server仍在5.5版上，这将使环境处于混合模式。由于未更改原始源计算机，因此迁移过程提供了一个简单的回滚计划。这也满足增强链接模式（ELM）的要求，因为通过步骤1中执行的域合并过程启用了ELM。

   注意：如果在vSphere 5.5中配置了链接模式，则必须先中断它，然后才能开始迁移过程。

3. 接下来是vC​​enter Server升级或迁移。现在，环境处于混合模式，因此尽快升级或迁移vSphere SSO域内的所有vCenter Server至关重要。混合模式没有强制性的时间限制，但是从故障排除角度来看，最好将两个vCenter Server组件（PSC和vCenter Server）安装在同一版本上，并在vCenter Server 6.5中获得所有新功能。

    

   注意：上面的图像与当前场景有关。vSphere 6.5中的迁移工具支持从vSphere 5.5或6.0进行迁移。

4. 现在，vCenter Server已迁移到vCenter Server Appliance 6.5，我们可以集中精力升级管理平面中的其他产品。返回上表，我们可以确定当前环境中的其他解决方案（NSX，vRA，vROPS）需要升级以支持vSphere 6.5。这也应包括任何第三方产品。
5. 应该升级所有ESXi主机，而不要为了获得最大的正常运行时间吹牛权利而将其保留。尽管vSphere 6.5环境中支持vSphere 5.5 ESXi主机，但不应将其保留。主机升级可支持最新的服务器硬件，可扩展性增加，vMotions增强和安全性提高。可以通过在群集或主机级别使用vSphere Update Manager（VUM）完成主机升级。在群集级别应用的vSphere Update Manager基准可以利用DRS自动从主机移动虚拟机，然后将主机置于维护模式，并自动启动升级过程。主机升级完成后，它将退出维护模式并移至群集中的下一个主机，直到所有主机都符合基准。
6. 虚拟机也需要爱！
   • 拥有最新的VMware Tools可确保增强虚拟机的性能和管理。尽管来宾操作系统可以在没有VMware Tools的情况下运行，但是无法安装或更新VMware Tools可能会导致操作系统性能下降和功能缺失。
   • 接下来是虚拟机硬件，它反映了受支持的虚拟机硬件功能。这包括虚拟机BIOS，支持的CPU和内存数量以及虚拟机的其他与硬件相关的功能。如果需要较新的硬件功能，则虚拟机硬件版本可以保持当前版本并进行升级。
7. 我们不能忘记存储！vSphere 6.5引入了VMFS6，它包括对先前版本的VMFS5的许多增强。VMFS6现在包括在数据存储级别以及来宾操作系统中的自动空间回收。可在此处找到有关vSphere 6.5中所有VMFS增强功能的更多信息。有多种方法可以将VMFS数据存储升级到版本6。第一个（如果有空间的话）将是创建一个新的数据存储，然后使用现有数据存储中的虚拟机进行Storage vMotion。如果空间有限，则Storage vMotion会从现有数据存储中存储所有虚拟机，然后将其从空状态从VMFS5升级到VMFS6，然后重复此过程，直到所有数据存储都已升级。
8. 将vSphere许可从vSphere 5.x升级到vSphere6.x。从myvmware门户。将新的vSphere 6.x许可证应用到vCenter Server，然后再应用到ESXi主机。升级或迁移期间将有60天的宽限期，以允许许可证升级。
   
9. Adam将部署vRLI以满足每个站点的集中日志记录要求。然后，我们将配置VCHA以满足他的vCenter Server高可用性要求。整个升级完成后，可以部署或配置任何新的VMware或3rd Party产品或功能。

Adam进行了应尽的努力，因此能够满足公司的要求，并成功地从vSphere 5.5版升级到6.5版。请记住，这只是一个示例方案，可能会也可能不会涵盖您的特定环境。同样，重要的重要收获是了解升级过程和概念并将其应用于您自己的环境。查看每个产品的发行说明，不仅知道升级过程，而且还知道一些已知问题，这很有价值。在开始升级过程之前，通过VMware支持打开SR可以确保您已对它们进行了验证，并且如果发生任何问题，这将加快支持过程。不要忘了确保在开始升级过程之前先进行备份，并确定恢复计划，以防您需要还原。在产品升级图表中制定计划不仅有助于确定何时升级产品，而且还有助于确定vCenter Server等产品的升级将如何影响其他产品。在下一篇博客文章中，我们将介绍另一种升级方案，这次涵盖了从vSphere 6.0到6.5的升级。

 

 

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.

1. 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.
2. Upgrade Horizon View server from 7.0 to 7.2. Make sure to upgrade the horizon view components in the correct order.
3. Use VUM to upgrade the ESXi hosts for the VDI environment.
4. Upgrade VM tools, then upgrade the horizon agent in the virtual desktops.
5. 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

1. Use the Nexus 1000v to VDS migration tool and complete network cleanup tasks.
2. 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.
3. 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.
4. 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.
5. 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.
6. Upgrade vSAN.
7. Upgrade SRM.
8. Upgrade ESXi hosts using VUM.
9. Upgrade VM tools / compatibility.
10.  Upgrade VMFS.
11.  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.
12.  

US Datacenters

1. Complete network cleanup tasks.
2. 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.
3. 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.
4.  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.
5. 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 
6. Upgrade vSAN
7. Upgrade SRM.
8. Upgrade ESXi hosts using VUM.
9. Upgrade VM tools / compatibility.
10. Upgrade VMFS.
11. 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!