Upgrade and mixed-release considerations in the multisystem environment
As you upgrade the systems in your management domain, you should expect the following behavior during an upgrade and while your systems are at differing firmware levels.
During an upgrade
While you upgrade any
system, its management console experiences an outage. During this
time period:
- You will be unable to display the shared catalog view of this system's catalog artifacts from any other system.
- Your multisystem deployments will continue to run, but the status of virtual machines on that system as displayed on the console of another system may be temporarily out of date or unknown.
- New deployments to multi-cloud environment profiles will be unable to connect to shared services if those shared services were originally deployed from the system that is being upgraded.
Even after the management console becomes available, there are time periods during a system upgrade during which the upgrade blocks other system jobs from running. Until the upgrade is complete, you should not attempt to copy remote catalog artifacts to the upgrading system or deploy multisystem deployments to that system.
While your systems are at differing firmware levels
Recommendation: Plan to upgrade all the systems
in your multisystem domain,
and especially your multisystem subdomain,
in short succession to each other
If you have upgraded one
or more systems in your domain, but not all systems, then you should
expect the following behavior for your management domain:
- Shared catalog views of catalog artifacts such as virtual images and script packages should display as you would expect.
- Copying or synchronizing catalog artifacts from one system to another is supported, but you should note that the copy will fail if the artifact you are copying requires a level of firmware not present on the destination system.
- Some catalog artifact types may support a shared view and copying only on the newer firmware level. In this case, you cannot display these artifacts on systems at an older level or copy to those systems.
For your deployment subdomain, in this situation existing multisystem deployments
will continue to operate, and you can display their status and manage
them from any system in the deployment subdomain. New multisystem deployments
can also be issued to the deployment subdomain, but you should be
aware of the following restrictions:
- New deployment capabilities may not be able to be exercised until all systems in the deployment subdomain are upgraded to the latest firmware.
- When you deploy, your pattern's required content must be present
on the system where a given pattern part is being deployed. If you
upgrade and enable default data on the system with the new firmware,
then that same default data will not be present on the systems with
older firmware, so that you cannot deploy from the higher-level systems
to the lower-level systems. You have the following options in this
case:
- Plan your window of firmware upgrades and default data updates so that you do not need to issue multisystem deployments until all systems have been updated.
- Issue all multisystem deploys from the system with the lower firmware level. Provided this same default data is present on the system with newer firmware, the deploy should succeed.
- Before upgrading the first system, you can lock the plug-ins in your pattern. After upgrade and after updating default data, if you deploy this pattern it will still use the older default data, which means you can issue multisystem deployments even from the system with the newer firmware.
- You cannot upgrade these running deployments to newer default data until all systems on which the deployments are running have been upgraded to the new firmware and default data.