Global Site
Displaying present location in the site.
June 29th, 2021
Introduction
We tried backing up and restoring mirror disks by using an Amazon EBS snapshot (hereinafter called "EBS snapshot") in Amazon Web Services (hereinafter called "AWS").
For Linux environment, please refer to 
here.
In AWS, taking EBS snapshots allows easily backing up Amazon EBS volumes (hereinafter called "EBS volumes"). What we tested this time is using an EBS snapshot to back up and restore EBS volumes used for mirror disks.
Contents
1. What are EBS Snapshots?
EBS snapshots are taken for backing up data in EBS volumes to Amazon S3.
EBS snapshots are taken asynchronously. During or after that, therefore, the EBS volumes can be used continuously. In taking an EBS snapshot, however, it is recommended to secure a rest point for ensuring the data consistency. Since EBS snapshots are taken as incremental backups, the time for that is minimized and the storage cost can be saved.
In addition, EBS volumes with data can be restored from an EBS snapshot stored in Amazon S3: by replacing existing EBS volumes (attached to the EC2 instance) with new ones (created from the snapshot). This restoration re-creates the state for a particular past point of time, with all the data remaining intact.
Note that, by accessing an EBS volume being created from an EBS snapshot, the performance may be dropped. When an EBS volume is created from an EBS snapshot, the data in the replicated volume is read over time in the background to make the volume available soon. However, if the data is not yet read but accessed, the requested data immediately starts to be downloaded and read in the background from Amazon S3 to the volume.
[Reference]
Amazon EBS snapshots
Amazon EBS snapshots 2. HA Cluster Configuration
The following describes how a HA cluster based on VIP control for Windows is configured in a VPC (Amazon Virtual Private Cloud) environment of the N. Virginia region. In each of the EBS volumes, a cluster partition and a data partition are created.
- VPC-1 (VPC ID：vpc-1234abcd)
- －CIDR：10.0.0.0/16
- －Subnets
- ■Subnet-A1 (Subnet ID：sub-1111aaaa)：10.0.10.0/24
- ■Subnet-A2 (Subnet ID：sub-2222aaaa)：10.0.110.0/24
- ■Subnet-B1 (Subnet ID：sub-1111bbbb)：10.0.20.0/24
- ■Subnet-B2 (Subnet ID：sub-2222bbbb)：10.0.120.0/24
- －RouteTables
- ■Main (Route table ID：rtb-00000001)
- >10.0.0.0/16 → local
- >0.0.0.0/0 → igw-1234abcd (Internet Gateway)
- >20.0.0.100/32 → eni-1234abcd (ENI ID of active server1)
- ■Route-A (Route table ID：rtb-0000000a)
- >10.0.0.0/16 → local
- >0.0.0.0/0 → eni-1234efgh(ENI ID of NAT1)
- >20.0.0.100/32 → eni-1234abcd (ENI ID of active server1)
- ■Route-B (Route table ID：rtb-0000000b)
- >10.0.0.0/16 → local
- >0.0.0.0/0 → eni-1234ijkl(ENI ID of NAT2)
- >20.0.0.100/32 → eni-1234abcd (ENI ID of active server1)
- －EC2 instance
- ■Instance-1 (Instance ID：i-1XXXXXXXXXXXXXX)：server1
- ・Root device：/dev/sda1
- ・Block devices：/dev/sda1
- ・Block devices：xvdb
- ■Instance-2 (Instance ID：i-2XXXXXXXXXXXXXX)：server2
- ・Root device：/dev/sda1
- ・Block devices：/dev/sda1
- ・Block devices：xvdb
- Disk configuration
- ■Disk0
- ・System：C:\
- ■Disk01
- ・Cluster partition：R:\
- ・Data partition：M:\
- EXPRESSCLUSTER
- －Failover group (failover)
- ■Mirror disk resource
- ・Cluster partition：R:\
- ・Data partition：M:\
For the configuration procedure, see "EXPRESSCLUSTER X for Windows HA Cluster Configuration Guide for Amazon Web Services".
The procedure requires AWS CLI for taking an EBS snapshot, creating EBS volumes from the snapshot, and detaching and attaching the volumes. Therefore, define access permission policies for these actions and give the permission to the EC2 (Client for operation) in advance, by adding the following:
- ec2:CreateSnapshot
- ec2:CreateVolume
- ec2:DetachVolume
- ec2:AttachVolume
3. Backup Procedure
Back up the EBS volume used for a mirror disk by taking an EBS snapshot as follows:
- 1.Stop the mirror disk resource of the active server:
Stop the mirror disk resource for securing a rest point of the mirror disk.
Other group resources may also be stopped due to their dependence on the mirror disk resource. - 2.Shut down the standby server:
In Cluster WebUI, shut down the standby server. - 3.Restart the mirror disk resource of the active server:
Restart the mirror disk resource to resume the operation. Also restart the other group resources stopped together with the mirror disk resource. - 4.Take an EBS snapshot of the EBS volume for the mirror disk of the standby server.
- 5.Restart the standby server to make it return to the cluster.
4. Restoration Procedure
For this mirror-disk restoration, the following case is assumed: All data was deleted from both the active server and the standby server due to, for example, an operational error on the active server.
If an operational error on the active server causes all its data to be lost, the data is mirrored in that of the standby server, whose data is completely deleted as well.
To restore the mirror disk of each of the servers from the EBS snapshot, go through the following steps, which eliminates the need for full copying from the mirror disk of the active server to that of the standby server*:
- *The full copying is necessary if only the active server's mirror disk was restored.
- 1.Delete the configuration of the mirror disk resource from that of EXPRESSCLUSTER.
If there are other resources that depend on the mirror disk resource, change their dependence on it. - 2.From the EBS snapshot taken in backing up the mirror disk of the standby server, create EBS volumes.
- 3.From each of the active and standby servers, detach the existing EBS volumes for the mirror disk:
Before that, unmount the mirror disk on the OS of each of the servers to make the disk offline. - 4.To each of the servers, attach the new EBS volumes created in step 2:
Mount the mirror disk on the OS of each of the servers to make the disk online.
Set the same drive letter as before detaching the old EBS volumes. - 5.Reconfigure the mirror disk resource.
This involves some configuration change.
For the other resources that depended on the mirror disk resource, make them depend on it again. - 6.Start the mirror disk resource.
5. Operation Check
5.1 Backup
The following fully describes how to take an EBS snapshot of the standby server's mirror disk.
5.1.1 Stopping the Mirror Disk Resource of the Active Server
In Cluster WebUI, stop the mirror disk resource. Note that other group resources may also be stopped due to their dependence on the mirror disk resource.
5.1.2 Shutting Down the Standby Server
In Cluster WebUI, shut down the standby server.
5.1.3 Restarting the Mirror Disk Resource of the Active Server
In Cluster WebUI, restart the mirror disk resource. Also restart the other group resources stopped in "5.1.1 Stopping the Mirror Disk Resource of the Active Server".
5.1.4 Taking an EBS Snapshot
Take an EBS snapshot, indicated as (1) below, for the mirror disk of the standby server:
> aws ec2 create-snapshot --volume-id vol-11111111bbbbbbb(Volume ID of the standby server's mirror disk) --description "Mirror Volume Snapshot" (1)
Use the AWS Management Console or another tool to check that the snapshot has been taken.
Make a note of Snapshot ID(SnapshotId) of the EBS snapshot for later use.
5.1.5 Restarting the Standby Server to Make it Return to the Cluster
Use the AWS Management Console or another tool to restart the standby server. Check that the server has successfully returned to the HA cluster.
5.2 Restoration
The following fully describes how to restore the mirror disks of each of the servers from the EBS snapshot.
Begin on the assumption that all data was deleted from the mirror disks of both the active server and the standby server.
5.2.1 Deleting the Configuration of the Mirror Disk Resource
Delete the configuration of the mirror disk resource from that of EXPRESSCLUSTER.
If there are other resources that depend on the mirror disk resource, change the setting of Startup Attribute to Manual Startup to prevent the resources from being started by mistake.
After this change, apply it in Cluster WebUI.
5.2.2 Creating EBS Volumes
From the EBS snapshot taken in "5.1.4 Taking an EBS Snapshot", create an EBS volume for each Availability Zone of the active and standby servers, indicated as (2) and (3) respectively below:
> aws ec2 create-volume --region us-east-1 --availability-zone us-east-1a --snapshot-id snap-11111111bbbbbbb(Snapshot ID of (1)) --volume-type gp2 (2)
> aws ec2 create-volume --region us-east-1 --availability-zone us-east-1b --snapshot-id snap-11111111bbbbbbb(Snapshot ID of (1)) --volume-type gp2 (3)
> aws ec2 create-volume --region us-east-1 --availability-zone us-east-1b --snapshot-id snap-11111111bbbbbbb(Snapshot ID of (1)) --volume-type gp2 (3)
Use the AWS Management Console or another tool to check that the EBS volumes have been created.
Make a note of Volume ID(VolumeId) of each of the EBS volumes for later use.
5.2.3 Detaching the Existing EBS Volumes
First, from the Disk Management window, right-click the desired disk (mirror disk) and select Offline.
Then, from each of the active and standby servers, detach the EBS volume for the mirror disk.
Make a note of Device name (Device: for example, /dev/sdx, xvdb) with this detachment for later use: specifying the value for --device in attaching the EBS volumes (2) and (3) above.
> aws ec2 detach-volume --volume-id vol-11111111aaaaaaa(Volume ID of the active server's mirror disk)
> aws ec2 detach-volume --volume-id vol-11111111bbbbbbb(Volume ID of the standby server's mirror disk)
> aws ec2 detach-volume --volume-id vol-11111111bbbbbbb(Volume ID of the standby server's mirror disk)
5.2.4 Attaching the New EBS Volumes
To each of the servers, attach the EBS volume created in "5.2.2 Creating EBS Volumes".
> aws ec2 attach-volume --volume-id vol-22222222aaaaaaa --instance-id i-11111111aaaaaaa --device /dev/sdx
> aws ec2 attach-volume --volume-id vol-22222222bbbbbbb --instance-id i-11111111bbbbbbb --device /dev/sdx
- ■vol-22222222aaaaaaa ：Volume ID of the EBS volume created as (2)
- ■i-11111111aaaaaaa ：Instance ID of the active server
- ■/dev/sdx ：Device name of which a note was made during the detachment
> aws ec2 attach-volume --volume-id vol-22222222bbbbbbb --instance-id i-11111111bbbbbbb --device /dev/sdx
- ■vol-22222222bbbbbbb ：Volume ID of the EBS volume created as (3)
- ■i-1111111bbbbbbb ：Instance ID of the standby server
- ■/dev/sdx ：Device name of which a note was made during the detachment
From the Disk Management window, right-click the desired disk (mirror disk) and select Online.
If the drive letter is not the same as before detaching the old EBS volume, change the drive letter to the original letter.
In our verification, the drive letters on the active server were changed from (R:) to (D:) and from (M:) to (E:), as shown below. So we modified the drive letters into the original letters.
From the Disk Management window, confirm that the disk is recognized as before the detachment, and that the data is restored.
5.2.5 Reconfiguring the Mirror Disk Resource
Add the configuration of the mirror disk resource, deleted in "5.2.1 Deleting the Configuration of the Mirror Disk Resource", again. During this reconfiguration, do the following:
- －In [md] Resource Definition of Group, click Tuning.
Then, in Mirror Disk Resource Tuning Properties, uncheck Execute the initial mirror construction. - －For the other resources that depended on the mirror disk resource, make them depend on it again by returning Startup Attribute from Manual Startup to Automatic startup.
Then apply the above changes in Cluster WebUI.
5.2.6 Starting the Mirror Disk Resource
On the active server, start the failover group to check if the cluster is normally started. Also on the standby server, do it in the same way.
Conclusion
Through the above test, we have found taking an EBS snapshot very useful in terms of easily backing up and restoring mirror disks. In addition, restoring the mirror disk of each server as above will shorten the entire restoration time, which eliminates the need for full copying from the mirror disk of the active server to that of the standby server.
If you consider introducing the configuration described in this article, you can perform a validation with the trial module of EXPRESSCLUSTER. Please do not hesitate to contact us if you have any questions.