LAB 41 ‐ Subnet Migration - DevWithNehaCloud/Oracle-Cloud-Infrastructure-wiki GitHub Wiki

Comprehensive Subnet Migration Guide: Regional to AD-Specific Subnets

🏗️ 1. Architectural Foundation & Limitations

Before planning a migration, it is critical to understand the underlying architecture of Oracle Cloud Infrastructure (OCI) networking:

🚫 The "No-Conversion" Rule

In OCI, you cannot directly convert, change, or move an existing subnet from a Regional Subnet to an AD-Specific Subnet, or vice-versa. There is no toggle or button to alter a subnet's scope once it is created.

Therefore, a Subnet Migration always implies a three-step infrastructure lifecycle:

  1. Create a brand-new target subnet with the desired scope (AD-Specific).
  2. Migrate/Move the actual workloads, data, and configurations from the old subnet to the new one.
  3. Decommission (delete) the old subnet once validation is complete.

📊 Quick Comparison: Regional vs. AD-Specific Subnets

Feature Regional Subnet AD-Specific Subnet
Scope / Boundary Spans across the entire Region (all Availability Domains). Confined to one single Availability Domain (e.g., AD-1 only).
Primary Use Case Ideal for stateless layers like Load Balancers and Compute (App) Nodes that need to scale across the whole region. Critical for stateful infrastructure and PaaS Services (like OCI DB Systems) that bind deeply to specific AD hardware/storage.
The PaaS Trapped-Data Issue If a PaaS service is deployed here and that specific AD goes down, the PaaS service cannot jump or auto-failover to another AD dynamically because its underlying block storage is physically tied to the original AD. By using AD-specific subnets, you can cleanly build a Primary-Standby architecture (Primary in AD-1 Subnet, Standby/Replica in AD-2 Subnet) for true High Availability.

📌 2. Objective & Context

In Oracle Cloud Infrastructure (OCI), while Regional Subnets provide high availability across multiple Availability Domains (ADs) for standard resources, certain PaaS (Platform as a Service) components (such as OCI DB Systems or specialized data stores) are architecturally tied to a specific AD.

If a Regional Subnet experiences an isolated AD failure, these PaaS services do not automatically failover or "jump" to another AD due to storage and underlying data locking. To establish a true High Availability (HA) or Disaster Recovery (DR) topology for these services, resources must be migrated into structured AD-Specific Subnets.

This document outlines the end-to-end framework for executing a seamless subnet migration with minimal production impact.

🕒 2. Phase 1: Pre-Migration & Assessment

Before making any networking changes, thorough discovery and planning must be conducted.

  • Resource Inventory: Document every resource currently attached to the source Regional Subnet (Compute instances, Load Balancers, PaaS Databases, File Systems).
  • Dependency Mapping: Map all internal and external communication paths. Identify applications that hardcode IP addresses versus those using DNS.
  • Downtime & Maintenance Window Estimation:
    • Determine if the migration can be done live (Zero-Downtime) via replica switchovers or if it requires a maintenance window.
    • For critical PaaS and DB resources, a 2 to 4-hour maintenance window is standard.
  • Stakeholder Communication: Inform business units and application owners well in advance regarding potential brief disruptions.

🛠️ 3. Phase 2: Execution Strategy (Plan A)

Follow these sequential steps during the execution phase:

  1. Target Subnet Infrastructure Provisioning:
    • Create the new target AD-Specific Subnet.
    • Replicate the exact Security Lists, Network Security Groups (NSGs), and Route Tables from the source subnet to ensure firewall rules remain identical.
  2. Data Backup & Snapshot:
    • Immediately prior to the migration window, take full Boot/Block Volume backups of all VMs.
    • Trigger a manual, full backup/snapshot of the PaaS Database.
  3. PaaS / DB Migration Procedure:
    • Spin up a standby instance of the PaaS service inside the new target AD-Specific Subnet.
    • Sync the data from the primary instance to this new standby instance.
    • Initiate a controlled Switchover to make the instance in the new subnet the primary active database.
  4. Configuration & DNS Updates:
    • Update Application configuration files, Backend Sets of Load Balancers, and private DNS zones to point to the new IP addresses assigned in the target subnet.

🚨 4. Phase 3: Risk Management & Contingency Planning

"Hope for the best, but plan for the worst." A migration plan is incomplete without strict boundaries between reversing an incomplete setup versus handling a failure after Go-Live.

🔄 A. Rollback Strategy (In-Flight / During Maintenance)

  • Definition: Aborting the migration mid-process and returning to the exact state before the maintenance window started.
  • Trigger Condition: The target subnet creation fails, network routing configuration breaks, or the PaaS service fails to initialize in the new subnet before the application goes live.
  • Execution Steps:
    • Stop all migration activities.
    • Revert the application configurations/DNS back to the original IPs in the source Regional Subnet.
    • Data Integrity: Zero data loss, as no new live production transactions occurred on the new infrastructure.
    • Cut-off Time: A strict timer (e.g., 2 hours into a 4-hour window). If the migration is not successful by this time, the Rollback must be triggered to ensure services are restored before business hours.

📉 B. Fallback Strategy (Post Go-Live Contingency)

  • Definition: Activating a pre-planned alternative route (Plan B) because a critical failure occurred after the system went live and transactions have already processed.
  • Trigger Condition: The migration completes successfully at 3:00 AM. System goes live at 6:00 AM. By 10:00 AM, latency issues or hidden bugs crash the system. A simple "Undo (Rollback)" is impossible because hours of new live production data have been written to the new database.
  • Execution Steps:
    • Do not revert to the old subnet blindly (doing so will cause data loss).
    • Activate the Fallback Route: Route traffic to a secondary AD standby environment or a Disaster Recovery (DR) site.
    • Execute data synchronization/delta scripts to capture the new data generated between 6:00 AM and 10:00 AM and move it to the fallback environment to maintain data consistency.

🧪 5. Phase 4: Post-Migration Validation & Clean-Up

Once resources are inside the new AD-Specific Subnet, complete the following validation steps:

  • Connectivity Verification: Ensure the application tier can successfully query and write to the PaaS tier inside the new subnet.
  • Security Auditing: Validate that only authorized ports are open and no unintended public endpoints were exposed.
  • Performance Baselining: Compare application response times and query latencies against pre-migration metrics to ensure no degradation.
  • Decommissioning (Clean-up): Retain the old Regional Subnet and its dormant resources for a baking period of 24 to 48 hours. Once stability is proven, safely terminate the old resources to optimize cloud costs.

🔄 Summary: Rollback vs. Fallback (Quick Reference)

Feature Rollback Fallback
Concept "Undo" (Abort & Reverse) ↩️ "Plan B" (Alternative Route) 🔀
Timing Executed during the maintenance window (In-flight). Executed after Go-Live (In production).
Trigger Migration steps failed before completion. Migration succeeded, but production issues occurred later.
Data Impact No Data Loss: No new transactions were written. Data Preservation Needed: New live transactions exist and must be synced.
Action Revert configurations back to the original source subnet. Divert traffic to a secondary AD standby or DR environment.