Migrating Azure API Management from STV01 to STV02 Platform: Migration Guide
Microsoft has officially Announced that Azure API Management
instances hosted on the stv1 platform will be retired by 31 August 2024.
If you have instances hosted on the stv1 platform, migrate them to the stv2
platform before that date to avoid service disruptions.
This blog post will help you in how to migrate the Azure API Management service from STV01 to STV02, covering both VNet injected and non-VNet injected scenarios. Options are featured that explain how to use new or existing subnets. Furthermore, it describes the process of deleting old STV01 compute resources.
Azure API Management enables an organization to publish, secure, transform, and monitor APIs with efficiency. In the ever-evolving tiers of service in Azure, STV01 to STV02 tier migration offers much-improved performance and scalability in various areas. However, this kind of migration will call for careful planning, where the decision has to be made between a new subnet or an existing one for the VNet-integrated migration process.
Before you migrate Azure API Management from the STV01 to STV02, you
need to understand the difference between these two tiers:
• STV01: An older version with certain limitations in
scalability, performance, and availability of various features.
• STV02: This new version has better performance as well as
scalability, with better security features as well. There is the implementation
of zone redundancy, better throughput, and lower latency.
Migrating to STV02 allows organizations to leverage such
upgrades and facilitates a superior API management solution.
Pre-Migration Activities
a. Assessment of Existing Configuration
1. API
Inventory: Document all APIs, with the products, policies, and subscriptions,
that are listed in the APIM.
2.Check VNet
Integration: If the APIM is VNet-integrated, the stipulation shall impact the
approach towards migration.
3.Backup
Data as a Precaution: The backup should be taken for API definitions, products,
policies, and all other custom settings.
b. Downtime Scheduling (if necessary)
• VNet-Injected
Instances: It might require downtime because of the reconfiguration of the
network, especially for changes at the subnet level.
• Non-VNet-Injected
Instances: Generally, this will be migrated with minimal downtime, though plan
for a Change Window always.
c Update DNS Records
If your APIM is using custom DNS names, then update the DNS records to point to the new STV02 endpoint readied after migration.
Migration Activities: New Subnet or Existing Subnet
Prerequisites
- A
network security group must be attached to each subnet, and NSG
rules for API Management on the stv2 platform must be
configured. The following are minimum connectivity settings:
- Outbound
to Azure Storage over port 443
- Outbound
to Azure SQL over port 1433
- Outbound
to Azure Key Vault over port 443
- Inbound
from Azure Load Balancer over port 6390
- Inbound
from Api Management service tag over port 3443
- Inbound
over port 80/443 for clients calling API Management service
- The
subnet must have service endpoints enabled for Azure Storage, Azure SQL,
and Azure Key Vault
- The
address space of each existing subnet must be large enough to host a copy
of your existing service side-by side with your existing service during
migration.
- Other
network considerations:
- Turn
off any auto scale rules configured for API Management instances deployed
in the subnet. Auto scale rules can interfere with the migration process.
- If
you have multiple API Management instances in the same subnet, migrate
each instance in sequence. We recommend that you promptly migrate all
instances in the subnet to avoid any potential issues with instances
hosted on different platforms in the same subnet.
VNET Injected Migration: New Subnet or Existing Subnet
For APIM instances that are configured with Virtual Network, there are two major options for migrating from STV10 to STV02: either new subnet or existing subnet. A. New Subnet Advantages: Isolation: The new APIM instance is totally isolated from the old instance, and isolation helps in minimizing the disruption during migration. Clean Slate: It's a fresh opportunity to reconfigure network security settings and further polish the subnet for new workload.
Migration Steps:
1. Create a new subnet
b. Do the following step on Azure Portal: Create a new
subnet inside the existing VNet for your existing APIM instance.
2. New STV02 Instance
Provisioning: a. Need to create a new instance of APIM with the required tier
STV02 and ensure to use the latest subnet.
3. APIs and Configurations Migration:
a. Export the APIs and Policies: APIs, Policies, and
Configurations from STV01 should be exported using the Azure portal or some
PowerShell scripts.
4.Network Security Group Update: Network Security Groups and
firewall rules enable access between the new STV02 instance and your backend
services.
5.Test and Validate: Ensure that all API's are working as
expected and similarly network integration established correctly.
6.Switch Over: Update DNS records to point to the new STV02 endpoint and ensure the old STV01 instance is left unused
Existing Subnet
Easier Configuration: There is no need to provision a new
subnet and configure NSGs in the subnets
Migration is Faster: Migration time is minimal as all your
existing settings and policies with respect to your network are retained.
Create New STV02 Instance:
1. Add a new instance of APIM with the appropriate tier,
STV02, under the same subnet.
2. Switch APIs and configurations:
3.Export APIs and Policies: Export all APIs, policies, and
configurations from the old STV01 or instance with Azure Portal or with the use
of PowerShell scripts.
o Import to STV02: Import all the exported settings to the
new instance.
o Ensure
NSGs and firewall rules are properly configured for the new instance on the old
subnet.
4.Verification
and Validation:
o Ensure all
APIs are working fine, and the network is configured as expected.
5.Switch
Over:
o Update DNS
entries to point to the new STV02 endpoint and ensure that the old STV01
instance is not reachable anymore.
Automatic Deletion Options:
1. 15-Minute
Deletion Option:
o Quick
Cleanup: This retains the STV01 instance for just 15 minutes after the
switch-over. This best works for a user who wants to dispose of the old
instance as fast as possible to save costs that could be unnecessary.
o Immediate
Impact: This option should work well only when you are convinced that the new
STV02 instance has been fully tested. This is because you are allocated very
little time in case you want to reverse.
2. 48-Hour Deletion Option:
o Grace
Period: This option would make sure that STV01 instance would get automatically
deleted after 48 hours of switch-over. This option gives grace period in which
the new STV02 instance can be tested and verified for any misconfigurations.
o Safety
Net: This option provides window to check that new STV02 instance does not face
any critical issues during initial usage, at which time the old instance could
be reverted.
Auto-delete option can be configured as given below:
• As we are
following through the migration steps in the Azure portal, select the preferred
time of deletion when you are performing risk and confident in your
testing—either 15 minutes or 48 hours.
(Optional) Migrate back to original subnet
If you migrated and changed to a new subnet, optionally migrate back to the original subnet you used in each region. To do so, update the VNet configuration again, this time specifying the original VNet and subnet in each region. As in the preceding migration, expect a long-running operation, and expect the VIP address to change.
Non-VNet Injected Migration
For such APIM instances that are not directly injected with
a Virtual Network, migration is less critical:
1. Create a
New STV02 Instance:
o From Azure
portal, create a new API Management instance with STV02 tier.
2. Migrate
APIs and Configurations:
o Export
APIs and Policies: Export all APIs, policies, and configurations from STV01.
o Import to
STV02: Import the exported configurations into the new STV02 instance.
3.Test and
Validate:
o Ensure
that all APIs are working fine without any connectivity problem from backend
services.
4. Switch
Over:
o Update DNS
records to point to the new endpoint, STV02, and ensure that the old endpoint,
STV01, is eventually not accessed.
5. Automatically Remove the Old STV01 Compute Resources
Post Migration Activities
- Steps after Migration check on the status of the APIM should be Online and Platform Version should be stv02 or stv02.1
- Test on the API are communicating with the backends as expected after the network dependencies are reverted.
Additional Checks
a. Monitor Performance
• Monitor
the performance of new APIM using Azure Monitor and Insights.
b. Update Documentation
• Ensure
all team members and other stakeholders are aware of the changes and update
documentation
c. Review Security settings
• Review
security set up and policies and ensure they are aligned with the policies of
the organization
Comments
Post a Comment