Azure DR Architecture Overview

Hello Penumarthi Dora Krishna, it looks like you’re planning to use Azure Site Recovery (ASR) to replicate your ICMVA app servers, Indexer and LDAP VMs, and DB2 HDR for database log shipping. To make sure we cover all the bases and tailor the advice correctly, could you clarify a few things?

1. Operating systems and versions
   • What OS (Windows/Linux) and versions are your ICMVA app servers, Indexers and LDAP VMs running?
   • What version of DB2 are you using?
2. Azure regions and networking
   • Which Azure regions have you chosen for primary and DR?
   • Have you set up network connectivity (VNets, VPN/ExpressRoute) between on-prem (if any) and Azure?
3. Recovery requirements
   • What RPO (recovery point objective) and RTO (recovery time objective) are you targeting for each component?
   • Do you need app-consistent snapshots for ICMVA and LDAP?
4. ASR configuration
   • Have you already added the ASR Mobility agent to your VMs?
   • What replication policy settings (frequency of recovery points, retention) are you considering?
5. DB2 HDR details
   • How frequently are you shipping transaction logs for HDR?
   • Where is the HDR standby instance located (on-prem vs. Azure VM)?
   • During a failover, do you plan to orchestrate a role swap of the HDR pair manually or via automation?
6. Indexer & LDAP replication
   • How do you plan to keep your Indexer data in sync? (folder-level replication, built-in index replication, etc.)
   • For LDAP, are you using multi-master replication or another mechanism?

With those details we can give you targeted guidance on setting up ASR replication, configuring HDR failover, and ensuring everything comes up cleanly in your DR location. In the meantime, here are a few docs you’ll find useful:

Reference list

• ASR overview & Azure-to-Azure architecture: https://learn.microsoft.com/azure/site-recovery/azure-to-azure-architecture
• ASR pricing & cost estimation: https://learn.microsoft.com/azure/site-recovery/site-recovery-cost
• ASR availability zone DR: https://learn.microsoft.com/azure/site-recovery/azure-to-azure-how-to-enable-zone-to-zone-disaster-recovery
• Managed Disk DR options: https://learn.microsoft.com/en-us/azure/site-recovery/

The described Azure DR architecture aligns with documented patterns, with some clarifications and recommendations:

1. Use of Azure Site Recovery (ASR) for core ISIM components

• ASR is appropriate for VM-level DR of application and infrastructure components such as:
  • ICMVA application server
  • Indexer
  • LDAP server
• ASR replicates the managed disks of these VMs to the DR region and orchestrates failover/failback.
• Ensure that any attached storage types are supported by ASR. For SAP workloads, for example, managed disks are protected by ASR, while other storage types may require different DR strategies. The same principle applies to ISIM components: validate storage type support in the ASR support matrix.
• For shared or file-based components (config shares, logs, etc.), follow the storage-specific DR strategy (for example, Azure Files, Azure NetApp Files, or shared disks each have different DR approaches).

2. DB2 database DR with DB2 HDR / log shipping

• For database workloads, the recommended DR approach is to use the database’s native replication/DR technology rather than ASR, because ASR does not guarantee database consistency and has data change rate limitations.
• For DB2 specifically, the guidance for SAP workloads is to use IBM DB2 HADR (High Availability Disaster Recovery). In the ISIM scenario, DB2 HDR/log shipping plays the same role: database-native DR.
• This pattern—VM-level DR with ASR for app tiers plus DB-native replication for the database tier—is consistent with recommended architectures.

3. Combined pattern and key considerations

• Architecture pattern:
  • Application/utility tiers (ICMVA, Indexer, LDAP): protected with ASR between regions.
  • Database tier (DB2): protected with DB2 HDR/log shipping between primary and DR regions.
• Ensure:
  • Network connectivity and name resolution are designed so that, after failover, application components can reach the DB2 DR instance and any replicated services.
  • Recovery plans in ASR include boot order and any post-failover scripts needed to point applications to the DB2 DR endpoint.
  • RPO/RTO objectives are validated against DB2 HDR configuration (log shipping frequency, mode) and ASR replication settings.

This combination of ASR for servers and DB2 HDR/log shipping for the database is a valid and recommended pattern, provided storage support and database consistency requirements are carefully verified.

References:

• Disaster recovery overview and infrastructure guidelines for SAP workload
• Disaster recovery guidelines for SAP application
• Disaster recovery architecture for an Azure data platform