Disaster Recovery (part 3 of 4)

By Ashwin Venugopal -

 



To read part 1, please click here
To read part 2, please click here
To read part 4, please click here



Set up disaster recovery for SQL Server

SQL Server can be easily deployed in a number of ways:
  • Standalone SQL Server- In this one, the SQL Server as well as all the other databases are hosted on a single machine. While host clustering is required for the local high availability when virtualized, the guest-level high availability isn't implemented.

  • SQL Server Failover Clustering Instances (Always On FCI)- Here, two or more nodes running SQL Server instanced with shared disks are configured in a Windows Failover Cluster and if a node is down, the cluster can fail SQL Server over to another instance. This kind of approach is specifically used to implement high availability at a primary site but cannot protect against failure or outage in the shared storage layer.

  • SQL Always On Availability Groups- Two or more nodes are set up in a shared nothing cluster, with SQL Server databases configured in an availability group, with synchronous replicationand automatic failover.     

Site Recovery Support

Supported Scenarios

Site Recovery can protect SQL Server as given in the table:

Scenario

To a secondary site

To Azure

Hyper-V

Yes

Yes

VMware

Yes

Yes

Physical server

Yes

Yes

Azure

NA

Yes

 Deployment prerequisites

  • An on-premises SQL Server deployment, running a supported SQL Server version along with an Active Directory for your SQL server.
  • The requirements for the scenario you want to deploy.  

Set up Active Directory

You can set up Active Directory in the secondary recovery site, to properly run SQL Server.

  • Small enterprise- You should use Site Recovery replication if you want to fail over the entire site to replicate the domain controller to the secondary datacenter, or to Azure as you have a small number of applications.

  • Medium to large enterprise- If you have large number of applications, and want to fail over by application or workload, you should set up an additional domain controller in the secondary datacenter, or in Azure; but for Always On availability group, it is recommended to set up another additional domain controller on the secondary site or in Azure, to use for the recovered SQL Server instance.       

Preparation of the disaster recovery scenario

SAP HANA on Azure Service Management can attach with the extra set of volumes as a target for the production replica to the HANA Large Instance unit on which the TST HANA instance is running while also providing the SID of your production HANA instance. After it confirms the attachment of those volumes, you can easily mount them on to the HANA Large Instance unit.

Next, you have to install the second SAP HANA instance on the HANA Large Instance unit in the DR Azure region, where you can run the TST HANA instance. The users must have same the same UID and Group ID as the production instance and if the installation is successful then, you should:

  • Implement the HLI storage snapshot preparation process.
  • Use the HANABackupCustomerDetails.txt with teh new HANA instance and verify if the connectivity into the storage is working correctly or not.
  • Stop the newly installed SAP HANA instance on the HANA Large Instance unit in the DR Azure region.
  • Unmount these PRD volumes and contact SAP HANA on Azure Service Management. The volumes can't stay mounted to the unit because they can't be accessible while functioning as storage replication target.  

Note- The /hana/log volume is not replicated because it is not necessary to restore the replicated SAP HANA database to a consistent state in the disaster recovery site.

After that, you have to set up the storage snapshot backup schedule to go to your RTO as well as RPO in the disaster case and for better RPO, you can easily copy the HANA transaction log backups from SAP HANA on Azure (Large Instances) to the other Azure region. 

After the confirmation of the replication relationship setup by HANA Large Instance operations as well as starting up the execution storage sanpshot backups, the data replication begins. As the replication progresses, the snapshots on the PRD volumes in the DR Azure regions are not restored and if there is a failover, restore to an older storage snapshot can also be selected in place of the latest storage snapshot.

Monitor disaster recovery replication

To achieve this, you have to run the script azure_hana_replication_status which must be run for a unit that runs in the disaster recovery location to function accordingly. This command can also be run for every HANA Large Instance unit of your tenant in the disaster recovery location but cannot be used to acquire details about the boot volume.


      


To read part 1, please click here
To read part 2, please click here
To read part 4, please click here


Comments

Post a Comment

Popular posts from this blog

Deployment (Part 3)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 2, please click  here Microsoft Monitoring Agent (MMA) MMA is used across multiple Microsoft solutions and has undergone a few name changes as its features and functionality have evolved. If it is being considered to be used, then following areas should be covered during a Microsoft Sentinel deployment project: Consider the timelines and the strategy for a migration to AMA (Azure Monitor Agent) before the MMA end-of-life.  Consider the central deployment and management methodology for MMA. Determine which endpoints are in scope for deployment as these affect the log ingestion volume significantly.  Azure Monitor Agent (AMA) Organizations with MMA as the main Microsoft Sentinel agent should start planning the migration to AMA as soon as possible to avoid a rushed migration. One of the main advantages of AMA is the ability to control the log collection policy centrally and apply different policies against different groups of computers, re
Read more

Project Resourcing (Part 2)

By Ashwin Venugopal -
Image
  To read part 1, please click  here Engineering - SIEM The SIEM engineers configures Microsoft Sentinel, including Log Analytics, Logic Apps, workbooks, and playbooks. They are also responsible for the following high-level tasks: Initial configuration of Azure tenant, including provisioning required resources, assigning access roles, and configuring workspace parameters like log retention, resource tagging, and blueprints.  Deployment and configuration of syslog/CEF log collection agents in appropriate locations to collect logs from on-premises devices. Generally, it will be joint effort of both system engineer and SIEM engineer, involving configuration and potential troubleshooting.  Working with system owners to enable log forwarding and configuring any required parsing of log data in Log Analytics.  Working with security operations to create and deploy KQL analytic rules to offer detections for SOC/Computer Security Incident Response Team (CSRIT) use. Tuning of alert rule parameter
Read more

Design Planning (Part 3)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 2, please click  here Complex Organizational Structures SIEM can be an expensive security control, hence, it is common multiple businesses to contribute to the overall expense. Various organizational units may require a level of access to specific dashboards or sets of data. Microsoft Sentinel offers the ability to assign table-level permissions and limit the level of access to the minimum required to perform requisite job functions.  Role-based Access Control (RBAC) Requirements Microsoft Sentinel offers an extensive list of Azure built-in roles that can be used to provide granular access according to the job requirements and permitted level of access. Some of them are various Microsoft Sentinel dedicated roles: Microsoft Sentinel Contributor- Can perform all engineering-related configuration, such as creating alert rules, configuring data connectors, and additional similar tasks.  Microsoft Sentinel Reader- Can query the log data stor
Read more