diff --git a/cloudhub/modules/ROOT/assets/image-source-files/upgrade-ch2-review-conf.graffle b/cloudhub/modules/ROOT/assets/image-source-files/upgrade-ch2-review-conf.graffle new file mode 100644 index 000000000..460fadc93 Binary files /dev/null and b/cloudhub/modules/ROOT/assets/image-source-files/upgrade-ch2-review-conf.graffle differ diff --git a/cloudhub/modules/ROOT/assets/images/upgrade-ch2-review-conf.png b/cloudhub/modules/ROOT/assets/images/upgrade-ch2-review-conf.png new file mode 100644 index 000000000..defd1f4b8 Binary files /dev/null and b/cloudhub/modules/ROOT/assets/images/upgrade-ch2-review-conf.png differ diff --git a/cloudhub/modules/ROOT/nav.adoc b/cloudhub/modules/ROOT/nav.adoc index fea14f7e6..366a5a607 100644 --- a/cloudhub/modules/ROOT/nav.adoc +++ b/cloudhub/modules/ROOT/nav.adoc @@ -12,6 +12,7 @@ ** xref:maintenance-and-upgrade-policy.adoc[CloudHub Maintenance and Upgrade Policy] ** xref:penetration-testing-policies.adoc[Run Vulnerability Assessment and Penetration Tests] * xref:cloudhub-release-notes.adoc[Release Notes] + * xref:vpc-upgrade.adoc[] * xref:cloudhub-use.adoc[Using CloudHub] ** xref:developing-applications-for-cloudhub.adoc[Develop Applications for CloudHub] ** xref:deploying-to-cloudhub.adoc[Deploy to CloudHub] diff --git a/cloudhub/modules/ROOT/pages/vpc-upgrade.adoc b/cloudhub/modules/ROOT/pages/vpc-upgrade.adoc new file mode 100644 index 000000000..a8332a54d --- /dev/null +++ b/cloudhub/modules/ROOT/pages/vpc-upgrade.adoc @@ -0,0 +1,128 @@ += CloudHub VPC to CloudHub 2.0 Private Space Upgrade + +//Overview +To migrate your workloads from CloudHub to CloudHub 2.0, you need to set up your CloudHub 2.0 infrastructure and network connections. One approach is to create new CloudHub 2.0 private spaces with configurations that differ from your existing CloudHub setup. + +To retain your infrastructure configuration, use the in-product VPC upgrade tool to easily migrate your CloudHub dedicated Virtual Private Cloud (VPC) to a CloudHub 2.0 private space. + +When your new private space is ready, you can gradually migrate your applications from the CloudHub VPC to the CloudHub 2.0 private space. After moving all your applications, you can decommission your old VPC. + + +// Benefits +Using the in-product VPC upgrade tool saves you time because you don't need to acquire new CIDR blocks, set up new network connections, and configure the private space from the ground up. + +The tool provisions the infrastructure for a CloudHub 2.0 private space by cloning the existing configurations of your eligible CloudHub dedicated VPC, using the same CIDR block. + +If your VPC has existing Transit Gateways (TGW) or Virtual Private Networks (VPN) connections, they transfer seamlessly to the new CloudHub 2.0 private space. This migration ensures that any new applications deployed to the new private space can communicate effectively. + +The default CloudHub certificates are configured as part of the private space's default certificates. The DLB custom domains of the migrated VPC are created as part of the private space's custom TLS certificates. + +[NOTE] +During the VPC upgrade process, you use doubled entitlements for your VPC and network connections. Work with your account representative to remain compliant with entitlements and finish the upgrade on time. + +== Understand Eligibility +//Which VPCs are eligible for upgrade + +Due to their architectural differences and distinct interfaces, CloudHub 2.0 supports some features differently than CloudHub. Follow this eligibility checklist to confirm which VPCs are eligible for the upgrade: + +Availability of IPs:: ++ +Your VPC must have at least 25% free space, and 100 or more available IP addresses per subnet to be eligible for the upgrade. + +Deprecated Availability Zones (AZs):: ++ +VPCs using any of these deprecated AZs aren't eligible for the upgrade: ++ +* use1-az3 +* usw1-az2 +* cac1-az3 +* apne1-az3 +* sae1-az2 +* usw2-az4 + +Legacy VPNs:: ++ +VPCs with legacy VPNs configured aren't eligible for the upgrade. + +Direct Connect or VPC Peering:: +If your VPC has Direct Connect or VPC Peering configured, migrate to Transit Gateway or VPN before upgrading. + +TLS 1.1 ciphers:: ++ +These ciphers can't be carried over from CloudHub to CloudHub 2.0: ++ +* ECDHE-ECDSA-AES128-SHA1 +* ECDHE-ECDSA-AES256-SHA1 +* ECDHE-RSA-AES128-SHA1 +* ECDHE-RSA-AES256-SHA1 + +Multiple Internal DNS Special Domains:: +VPCs with more than one internal DNS special domain configured aren’t eligible for the upgrade. + +Absent Internal DNS Special Domains:: +If you do not have internal DNS configured for your VPC and your VPC has network connections or DLBs, it will not yet be eligible for an upgrade. + +Limitation for Restricting Outbound Egress Traffic:: +CloudHub VPC doesn't restrict outbound egress traffic, so removing the default firewall rule that allows this traffic can cause failures in your migrated private space. + +== Upgrade your VPC via Anypoint Platform + +. From *Anypoint Platform*, select *Runtime Manager* > *Upgrade*. ++ +Alternatively, select *Runtime Manager* > *What's New* to read more about the VPC upgrade, and click *Continue to Upgrade* to start upgrading your VPCs. +. Click *Upgrade Now* in the *Upgrade Status* column for the VPC to upgrade. ++ +The *Upgrade to CloudHub 2.0* review page displays the configurations currently available in your VPC, as well as the configurations that are created during the upgrade. ++ +image::upgrade-ch2-review-conf.png[VPC upgrade review page showing available configurations.] ++ +. Click *Next* to continue. +. Provide a name for the new private space. ++ +Optionally, you can specify xref:ps-gather-setup-info.adoc#cidr-block[reserved CIDRs] to connect to your new private space. +. Click *Create* to create the new private space. ++ +The *Upgrade to CloudHub 2.0* review page shows the progress of the VPC upgrade process, which takes about 15 to 30 minutes. + +[NOTE] +If you create a VPN to provision your CloudHub VPC, wait until the newly created VPN status shows as available before migrating your VPC to a CloudHub 2.0 private space. + +As soon as the upgrade process starts, the upgraded VPC is locked for any further updates. + +You can cancel the upgrade process to revert to your VPC at any time by clicking *Cancel Upgrade*. In that case, the newly created private space is deleted, and your VPC is unlocked. + +After you provision the private space, the *Cancel Upgrade* button no longer shows. However, you can still roll back the upgrade by deleting the private space. + + +== Next Steps After VPC Upgrade + +After you complete the upgrade, the private space is fully provisioned and you can start deploying applications to it. + +[NOTE] +When deploying new CloudHub 2.0 application, don't use CloudHub default domain as using CloudHub default domains can lead to issues such as potential traffic outages. + +You can start migrating your applications individually by creating new versions in the CloudHub 2.0 private space and then deleting the corresponding application in the CloudHub VPC. After migrating all your applications, delete your old VPC and any attached dedicated load balancers on CloudHub. + +During the migration, you can continue to deploy and manage applications in your VPC to maintain business continuity. After the upgrade, your CloudHub dedicated VPC is locked for any changes to the infrastructure, including environment or business group associations, network connections, and internal DNS, to prevent configuration drift. Make all changes in the newly created private space instead. Any configuration changes carried over to the CloudHub 2.0 private space are applied to the CloudHub VPC during the upgrade. + +If your CloudHub VPC doesn't have any network connections and you create new ones in your new CloudHub 2.0 private space after the upgrade, these new connections aren’t reflected back in your CloudHub VPC. + +The firewall rules configured in your VPC are copied to the private space. After that, you can make additional changes to the firewall rules in the VPC and the private space. To avoid configuration drift, apply any firewall rule changes in both places throughout the migration. + +[WARNING] +VPC firewall rules that have ports other than `80`, `443`, and `30500` to `32500` are dropped during migration. + +== Entitlements for VPCs, Private Spaces, and Network Connections (VPNs/TGW) + +After you complete the VPC upgrade and bring over any existing TGW and VPN network connections, your old and new infrastructure count separately against your usage. Therefore, if your organization uses all purchased quota, your usage can exceed the allowed quota until you move all your applications to CloudHub 2.0 and decommission your old VPC. + +Work with your account representative to plan for additional entitlements, and decommission your CloudHub infrastructure (VPCs and associated DLBs) within six months after the upgrade to avoid interruptions when trying to create or edit VPCs, private spaces, or network connections. + + +== See Also + +* xref:cloudhub-2::index.adoc[] +* xref:cloudhub-2::ch2-features.adoc[] +* xref:cloudhub-2::ch2-comparison.adoc[] +* xref:cloudhub-2::ch2-private-space-about.adoc[] +* xref:cloudhub-2::ch2-deploy-private-space.adoc[]