Microsoft StorSimple - automatic disaster recovery
Today our IT expert, Henrik Mockus, on the blog will present a series of detailed reviews of the main features of Microsoft StorSimple. We will focus on several separate aspects. One of the most important is disaster recovery. After the basic installation of Microsoft StorSimple, you must select settings that meet the requirements of reliability. Using the example of a file server, Henrik will talk about the technical intricacies of this scenario.
StorSimple is Microsoft's hybrid storage solution designed to provide simple, fast, cost-effective storage of data from the Microsoft Azure data center to local users. To familiarize yourself with the basics and to acquire basic knowledge of the operation of this software, we recommend reading the article “Microsoft Azure StorSimple: Easy Entry to a Hybrid Cloud” .
What does the architecture of this scenario look like? The file server runs on a virtual machine (VM) with Windows Server 2012 R2. It may have a failover cluster configuration. For data storage, the server uses StorSimple as Cluster Shared Volumes (CSC), which come as iSCSI volumes . StorSimple mirrors volumes in Azure (CloudSnapshots), after which domain users get access to them. This architecture provides excellent accessibility. All components are duplicated. The scope of work and operating costs are limited to a minimum.
')
Source: Microsoft
What do I need to know to create the appropriate Enterprise Disaster Recovery environment? This section describes the following individual components required to configure an AV:
In previous blog posts, I described the Microsoft StorSimple features. In this context, Cloud Snapshots should also be noted. They are used to securely copy an entire set of data, as well as to encrypted copy from iSCSI volumes to blob storage. This is where the cloud device for Microsoft StorSimple comes in handy. The Microsoft StorSimple cloud device is a virtual device running on a Microsoft Azure VM. This cloud device provides the same functionality in a hardware device, and makes iSCSI volumes available to servers. However, the following condition is essential: a cloud device can process no more than 64 TB of data. Therefore, if the memory of the hardware device is more than 64 TB, the iSCI volumes must be divided between several cloud devices. This restriction is set because the cloud device is a standard VM in Azure. And, as we know, the VM supports no more than 64 hard drives with a memory capacity of 1023 GB each.
Now you need to find a way to authenticate users. The following options are presented, depending on the complexity of the environment:
Then you need to make sure that the file servers through which users access shared resources (via DFS, FailoverCluster, etc.) are also available at the time of the crash. In this case, Microsoft Azure Site Recovery is used to duplicate the corresponding VMs in the Azure Data Center as exact copies up to the last bit. The following diagram shows the basic principles for the operation of Microsoft Azure Site Recovery for a specific scenario.
How Microsoft Azure Site Recovery works (source: Microsoft)
This requires an Azure Site Recovery provider who will be responsible for coordinating operations on the Hyper-V host. It uses port 443 to communicate with the Microsoft Azure data center. It also needs a recovery services agent for each VM. If necessary, it runs scripts on the current VM to perform the corresponding operations during an accident.
Last but not least, the possibility of automatic execution of the process of transition to another resource is provided for. Microsoft Azure Automation Service is designed for this purpose. Users can set up an Azure Automation account or select a ready-made list of tasks (runbook) from the pool. After adding a runbook to your personal account, you will need just one click to launch multiple operations.
Test transition to another resource in no way affects the servers. VMs are simply loaded into Azure, and volumes are mapped to VMs. But before this, the StorSimple volumes are copied and attached to the virtual device, thus forming the perfect playing field.
The planned transition to another resource uses a “friendly approach” to stop the VM from working in local data centers for later loading into Azure. To do this, the existing Cloud Snapshot is mapped to a virtual device. Voila!
Then, when an unplanned transition to another resource, VMs are simply loaded into Azure and the StorSimple volume container is transferred to another resource. After that, the volumes are in the VM, and the file server access to the data is restored.
source: Microsoft
In particular, a ready runbook makes the whole process very simple. Template scripts have already been written, they can be modified to fit individual scenarios.
The hybrid solution described here promises to provide excellent availability for the file services provided, simplified administration and good potential for cost reduction. In the end, the Microsoft Azure Data Center is used as the location of the crash. In addition, the dedicated location of the hardware and software transition being carried out is thus out of date.
In the future, Microsoft will focus on developing a solution for a hybrid data center. In Azure Site Recovery, Azure StorSimple or Azure Active Directory, ready-made solutions are already presented for the perfect connection between the on-premises infrastructure and Azure.
StorSimple is Microsoft's hybrid storage solution designed to provide simple, fast, cost-effective storage of data from the Microsoft Azure data center to local users. To familiarize yourself with the basics and to acquire basic knowledge of the operation of this software, we recommend reading the article “Microsoft Azure StorSimple: Easy Entry to a Hybrid Cloud” .
1. Automated Disaster Recovery Architecture
What does the architecture of this scenario look like? The file server runs on a virtual machine (VM) with Windows Server 2012 R2. It may have a failover cluster configuration. For data storage, the server uses StorSimple as Cluster Shared Volumes (CSC), which come as iSCSI volumes . StorSimple mirrors volumes in Azure (CloudSnapshots), after which domain users get access to them. This architecture provides excellent accessibility. All components are duplicated. The scope of work and operating costs are limited to a minimum.
')
Source: Microsoft
2. What is needed for automatic disaster recovery?
What do I need to know to create the appropriate Enterprise Disaster Recovery environment? This section describes the following individual components required to configure an AV:
- cloud device for iSCSI volumes in Microsoft Azure;
- ActiveDirectory in Azure or on the local network;
- Azure SiteRecovery storage
- Azure Automation.
In previous blog posts, I described the Microsoft StorSimple features. In this context, Cloud Snapshots should also be noted. They are used to securely copy an entire set of data, as well as to encrypted copy from iSCSI volumes to blob storage. This is where the cloud device for Microsoft StorSimple comes in handy. The Microsoft StorSimple cloud device is a virtual device running on a Microsoft Azure VM. This cloud device provides the same functionality in a hardware device, and makes iSCSI volumes available to servers. However, the following condition is essential: a cloud device can process no more than 64 TB of data. Therefore, if the memory of the hardware device is more than 64 TB, the iSCI volumes must be divided between several cloud devices. This restriction is set because the cloud device is a standard VM in Azure. And, as we know, the VM supports no more than 64 hard drives with a memory capacity of 1023 GB each.
3. Automated Disaster Recovery Step-by-Step Guide
Now you need to find a way to authenticate users. The following options are presented, depending on the complexity of the environment:
- A domain controller can use Azure Site Recovery to display an entire VM for less complex environments, in which only one domain controller is running and a small number of users are present. In the event of an accident, the reflection simply reboots. Then all changes in structure of Azure need to be repeated in the data processing center of the company. I am not a supporter of this method, and in some cases it will not even work.
- It is recommended to configure another data center in Azure to configure large environments with a large number of data centers, users and a large rate of change in blood pressure. After that, the data center becomes part of the overall structure, automatically displaying all changes in the structure before Microsoft Azure, as part of the replication topology.
4. Microsoft Azure Site Recovery
Then you need to make sure that the file servers through which users access shared resources (via DFS, FailoverCluster, etc.) are also available at the time of the crash. In this case, Microsoft Azure Site Recovery is used to duplicate the corresponding VMs in the Azure Data Center as exact copies up to the last bit. The following diagram shows the basic principles for the operation of Microsoft Azure Site Recovery for a specific scenario.
How Microsoft Azure Site Recovery works (source: Microsoft)
This requires an Azure Site Recovery provider who will be responsible for coordinating operations on the Hyper-V host. It uses port 443 to communicate with the Microsoft Azure data center. It also needs a recovery services agent for each VM. If necessary, it runs scripts on the current VM to perform the corresponding operations during an accident.
5. Microsoft Azure Automation Service
Last but not least, the possibility of automatic execution of the process of transition to another resource is provided for. Microsoft Azure Automation Service is designed for this purpose. Users can set up an Azure Automation account or select a ready-made list of tasks (runbook) from the pool. After adding a runbook to your personal account, you will need just one click to launch multiple operations.
Test transition to another resource in no way affects the servers. VMs are simply loaded into Azure, and volumes are mapped to VMs. But before this, the StorSimple volumes are copied and attached to the virtual device, thus forming the perfect playing field.
The planned transition to another resource uses a “friendly approach” to stop the VM from working in local data centers for later loading into Azure. To do this, the existing Cloud Snapshot is mapped to a virtual device. Voila!
Then, when an unplanned transition to another resource, VMs are simply loaded into Azure and the StorSimple volume container is transferred to another resource. After that, the volumes are in the VM, and the file server access to the data is restored.
source: Microsoft
In particular, a ready runbook makes the whole process very simple. Template scripts have already been written, they can be modified to fit individual scenarios.
6. Conclusions and perspectives
The hybrid solution described here promises to provide excellent availability for the file services provided, simplified administration and good potential for cost reduction. In the end, the Microsoft Azure Data Center is used as the location of the crash. In addition, the dedicated location of the hardware and software transition being carried out is thus out of date.
In the future, Microsoft will focus on developing a solution for a hybrid data center. In Azure Site Recovery, Azure StorSimple or Azure Active Directory, ready-made solutions are already presented for the perfect connection between the on-premises infrastructure and Azure.
Source: https://habr.com/ru/post/312064/
All Articles