記憶域スペースダイレクトを使用したディザスターリカバリーDisaster recovery with Storage Spaces Direct

適用対象:Windows Server 2019、Windows Server 2016Applies to: Windows Server 2019, Windows Server 2016

このトピックでは、ディザスターリカバリー用にハイパー集約インフラストラクチャ (HCI) を構成するシナリオについて説明します。This topic provides scenarios on how hyper-converged infrastructure (HCI) can be configured for disaster recovery.

多くの企業では、ハイパー集約型ソリューションを実行しています。災害を計画している場合は、障害が発生した場合でも、運用環境にとどまることができます。Numerous companies are running hyper-converged solutions and planning for a disaster gives the ability to remain in or get back to production quickly if a disaster were to occur. ディザスターリカバリー用に HCI を構成するには、いくつかの方法があります。このドキュメントでは、今日で利用できるオプションについて説明しています。There are several ways to configure HCI for disaster recovery and this document explains the options that are available to you today.

障害が発生した場合の可用性の復元に関するディスカッションは、目標復旧時間 (RTO) と呼ばれています。When discussions of restoring availability if disaster occurs revolve around what's known as Recovery Time Objective (RTO). これは、ビジネスに対する許容できない結果を回避するためにサービスを復元する必要がある期間です。This is the duration of time targeted where services must be restored to avoid unacceptable consequences to the business. 場合によっては、運用環境がほぼ即座に復元されると、このプロセスが自動的に実行されることがあります。In some cases, this process can occur automatically with production restored nearly immediately. それ以外の場合は、サービスを復元するために、管理者の手動操作が必要になります。In other cases, manual administrator intervention must occur to restore services.

現時点では、次のようなディザスターリカバリーオプションが使用されています。The disaster recovery options with a hyper-converged today are:

  1. 記憶域レプリカを利用する複数のクラスターMultiple clusters utilizing Storage Replica
  2. クラスター間での hyper-v レプリカHyper-V Replica between clusters
  3. バックアップと復元Backup and Restore

記憶域レプリカを利用する複数のクラスターMultiple clusters utilizing Storage Replica

記憶域レプリカは、ボリュームのレプリケーションを有効にし、同期レプリケーションと非同期レプリケーションの両方をサポートします。Storage Replica enables the replication of volumes and supports both synchronous and asynchronous replication. 同期レプリケーションと非同期レプリケーションのどちらを使用するかを選択する場合は、目標復旧時点 (RPO) を考慮する必要があります。When choosing between using either synchronous or asynchronous replication, you should consider your Recovery Point Objective (RPO). 回復ポイントの目標は、大きな損失と見なされる前に発生する可能性があるデータ損失の可能性を示します。Recovery Point Objective is the amount of possible data loss you are willing to incur before it is considered major loss. 同期レプリケーションを使用する場合は、同時に両方のエンドに順次書き込みが行われます。If you go with synchronous replication, it will sequentially write to both ends at the same time. 非同期にすると、書き込みは非常に高速にレプリケートされますが、失われる可能性があります。If you go with asynchronous, writes will replicate very fast but could still be lost. アプリケーションまたはファイルの使用状況を考慮して、最適な動作を確認する必要があります。You should consider the application or file usage to see which best works for you.

記憶域レプリカは、ブロックレベルのコピーメカニズムであり、ファイルレベルです。つまり、どのような種類のデータがレプリケートされるかは関係ありません。Storage Replica is a block level copy mechanism versus file level; meaning, it does not matter what types of data being replicated. これにより、ハイパー集約型インフラストラクチャのための一般的なオプションになります。This makes it a popular option for hyper-converged infrastructure. また、記憶域レプリカはレプリケーションパートナー間でさまざまな種類のドライブを利用できるので、1つの HCI 上のすべての種類の記憶域ともう一方の種類の記憶域を完全に問題なく使用できます。Storage Replica also can utilize different types of drives between the replication partners, so having all of one type storage on one HCI and another type storage on the other is perfectly fine.

記憶域レプリカの重要な機能の1つとして、Azure とオンプレミスの両方で実行できることが挙げられます。One important capability of Storage Replica is that it can be run in Azure as well as on-premises. オンプレミスからオンプレミスへのセットアップ、Azure から Azure への設定、またはオンプレミスから Azure への設定 (またはその逆) を行うことができます。You can set up on-premises to on-premises, Azure to Azure, or even on-premises to Azure (or vice versa).

このシナリオでは、独立したクラスターが2つあります。In this scenario, there are two separate independent clusters. HCI 間での記憶域レプリカの構成については、「クラスター間のストレージレプリケーション」の手順に従ってください。For configuring Storage Replica between HCI, you can follow the steps in Cluster-to-cluster storage replication.

ストレージレプリケーションの図

記憶域レプリカを展開する場合は、次の考慮事項が適用されます。The following considerations apply when deploying Storage Replica.

  1. レプリケーションの構成は、フェールオーバークラスタリングの外部で行われます。Configuring replication is done outside of Failover Clustering.
  2. レプリケーション方法の選択は、ネットワークの待機時間と RPO の要件によって異なります。Choosing the method of replication will be dependent upon your network latency and RPO requirements. 同期は、障害発生時にデータが失われないようにするために、クラッシュ整合性がある低待機時間のネットワーク上のデータをレプリケートします。Synchronous replicates the data on low-latency networks with crash consistency to ensure no data loss at a time of failure. 非同期は待機時間の長いネットワーク経由でデータをレプリケートしますが、障害が発生したときに各サイトに同一のコピーが含まれていない可能性があります。Asynchronous replicates the data over networks with higher latencies, but each site may not have identical copies at a time of failure.
  3. 障害が発生した場合、クラスター間のフェールオーバーは自動的には行われず、記憶域レプリカの PowerShell コマンドレットを使用して手動で調整する必要があります。In the case of a disaster, failovers between the clusters are not automatic and need to be orchestrated manually through the Storage Replica PowerShell cmdlets. 上の図では、Clustera.contoso.com 内はプライマリで、ClusterB はセカンダリです。In the diagram above, ClusterA is the primary and ClusterB is the secondary. Clustera.contoso.com 内がダウンした場合は、リソースをアップする前に ClusterB をプライマリとして手動で設定する必要があります。If ClusterA goes down, you would need to manually set ClusterB as Primary before you can bring the resources up. Clustera.contoso.com 内がバックアップされたら、セカンダリにする必要があります。Once ClusterA is back up, you would need to make it Secondary. すべてのデータが同期されたら、変更を行い、ロールを最初に設定した方法に戻します。Once all data has been synced up, make the change and swap the roles back to the way they were originally set.
  4. 記憶域レプリカはデータをレプリケートするだけであるため、このデータを使用している新しい仮想マシンまたは Scale Out ファイルサーバー (SOFS) は、レプリカパートナーのフェールオーバークラスターマネージャー内に作成する必要があります。Since Storage Replica is only replicating the data, a new virtual machine or Scale Out File Server (SOFS) utilizing this data would need to be created inside Failover Cluster Manager on the replica partner.

記憶域レプリカは、クラスターで仮想マシンまたは SOFS が実行されている場合に使用できます。Storage Replica can be used if you have virtual machines or an SOFS running on your cluster. PowerShell スクリプトを使用すると、レプリカ HCI のリソースをオンラインにすることができます。Bringing resources online in the replica HCI can be manual or automated through the use of PowerShell scripting.

Hyper-V レプリカHyper-V Replica

Hyper-vレプリカは、ハイパー集約型インフラストラクチャでのディザスターリカバリーのための仮想マシンレベルのレプリケーションを提供します。Hyper-V Replica provides virtual machine level replication for disaster recovery on hyper-converged infrastructures. Hyper-v レプリカでは、仮想マシンを取得して、セカンダリサイトまたは Azure (レプリカ) にレプリケートすることができます。What Hyper-V Replica can do is to take a virtual machine and replicate it to a secondary site or Azure (replica). 次に、セカンダリサイトから、Hyper-v レプリカが3番目の (拡張レプリカ) に仮想マシンをレプリケートできるようになります。Then from the secondary site, Hyper-V Replica can replicate the virtual machine to a third (extended replica).

Hyper-v レプリケーションの図

Hyper-v レプリカを使用すると、レプリケーションは Hyper-v によって処理されます。With Hyper-V Replica, the replication is taken care of by Hyper-V. レプリケーションのために仮想マシンを初めて有効にする場合、最初のコピーを対応するレプリカクラスターに送信する方法には、3つの選択肢があります。When you first enable a virtual machine for replication, there are three choices for how you wish the initial copy to be sent to the corresponding replica cluster(s).

  1. ネットワーク経由での初期コピーの送信Send the initial copy over the network
  2. 初期コピーを外部メディアに送信して、サーバーに手動でコピーできるようにするSend the initial copy to external media so that it can be copied onto your server manually
  3. レプリカホストで既に作成されている既存の仮想マシンを使用するUse an existing virtual machine already created on the replica hosts

もう1つのオプションは、この初期レプリケーションを実行するタイミングです。The other option is for when you wish this initial replication should take place.

  1. レプリケーションをすぐに開始するStart the replication immediately
  2. 初期レプリケーションが行われる時刻をスケジュールします。Schedule a time for when the initial replication takes place.

その他に必要な考慮事項は次のとおりです。Other considerations you will need are:

  • レプリケートする VHD/VHDX を選んでください。What VHD/VHDX's you wish to replicate. これらのすべてをレプリケートするか、そのうちの1つだけをレプリケートするかを選択できます。You can choose to replicate all of them or only one of them.
  • 保存する回復ポイントの数。Number of recovery points you wish to save. 復元する特定の時点についていくつかのオプションが必要な場合は、必要な数を指定します。If you wish to have several options about what point in time you wish to restore, then you would want to specify how many you want. 復元ポイントが1つだけ必要な場合は、それも選択できます。If you only want one restore point, you can choose that as well.
  • ボリュームシャドウコピーサービス (VSS) で増分シャドウコピーをレプリケートする頻度を設定します。How often you wish to have the Volume Shadow Copy Service (VSS) replicate an incremental shadow copy.
  • 変更がレプリケートされる頻度 (30 秒、5分、15分)。How often changes get replicated (30 seconds, 5 minutes, 15 minutes).

HCI が Hyper-v レプリカに参加する場合、各クラスターにHyper-v Replica Brokerリソースが作成されている必要があります。When HCI participate in Hyper-V Replica, you must have the Hyper-V Replica Broker resource created in each cluster. このリソースにはいくつかの処理があります。This resource does several things:

  1. は、Hyper-v レプリカを接続するクラスターごとに1つの名前空間を提供します。Gives you a single namespace for each cluster for Hyper-V Replica to connect to.
  2. レプリカ (または拡張レプリカ) が最初にコピーを受信したときにそのクラスター内のどのノードが配置されるかを決定します。Determines which node within that cluster the replica (or extended replica) will reside on when it first receives the copy.
  3. 仮想マシンが別のノードに移動した場合に、レプリカ (または拡張レプリカ) を所有しているノードを追跡します。Keeps track of which node owns the replica (or extended replica) in case the virtual machine moves to another node. レプリケーションが行われると、情報を適切なノードに送信できるように、これを追跡する必要があります。It needs to track this so that when replication takes place, it can send the information to the proper node.

バックアップと復元Backup and restore

あまり重要ではない従来のディザスターリカバリーオプションの1つは、クラスター全体またはクラスター内のノードで障害が発生した場合です。One traditional disaster recovery option that isn't talked about very much but is just as important is the failure of the entire cluster or a node in the cluster. このシナリオのいずれのオプションでも、Windows NT バックアップを使用します。Either option with this scenario makes use of Windows NT Backup.

常に、ハイパー集約型インフラストラクチャの定期的なバックアップを作成することをお勧めします。It is always a recommendation to have periodic backups of the hyper-converged infrastructure. クラスターサービスが実行されている間、システム状態のバックアップを作成すると、クラスターレジストリデータベースがそのバックアップの一部になります。While the Cluster Service is running, if you take a System State Backup, the cluster registry database would be a part of that backup. クラスターまたはデータベースの復元には、2つの異なる方法があります (権限のないと権限があります)。Restoring the cluster or the database has two different methods (Non-Authoritative and Authoritative).

権限のないNon-authoritative

権限のない復元は、Windows NT バックアップを使用して行うことができ、クラスターノード自体の完全な復元に相当します。A Non-Authoritative restore can be accomplished using Windows NT Backup and equates to a full restore of just the cluster node itself. クラスターノード (およびクラスターレジストリデータベース) と現在のすべてのクラスター情報を復元するだけでよい場合は、権限のないを使用して復元します。If you only need to restore a cluster node (and the cluster registry database) and all current cluster information good, you would restore using non-authoritative. 権限のない復元は、Windows NT バックアップインターフェイスまたはコマンドライン WBADMIN を使用して実行できます。EXCEL.EXE.Non-Authoritative restores can be done through the Windows NT Backup interface or the command line WBADMIN.EXE.

ノードを復元したら、クラスターに参加させます。Once you restore the node, let it join the cluster. 実行されるのは、既存の実行中のクラスターに対して行われ、すべての情報が現在のもので更新されるからです。What will happen is that it will go out to the existing running cluster and update all of its information with what is currently there.

関しAuthoritative

一方、クラスター構成の権限のある復元では、クラスター構成が時間内に戻されます。An Authoritative restore of the cluster configuration, on the other hand, takes the cluster configuration back in time. この種類の復元は、クラスター情報が失われ、復元が必要な場合にのみ実行してください。This type of restore should only be accomplished when the cluster information itself has been lost and needs restored. たとえば、1000の共有に含まれているファイルサーバーを誤って削除した場合、それらのファイルが必要になります。For example, someone accidentally deleted a File Server that contained over 1000 shares and you need them back. クラスターの権限のある復元を完了するには、コマンドラインからバックアップを実行する必要があります。Completing an Authoritative restore of the cluster requires that Backup be run from the command line.

クラスターノードで権限のある復元が開始されると、クラスタービュー内の他のすべてのノードでクラスターサービスが停止し、クラスター構成が固定されます。When an Authoritative restore is initiated on a cluster node, the cluster service is stopped on all other nodes in the cluster view and the cluster configuration is frozen. このため、復元が実行されたノードのクラスターサービスを最初に開始することが重要であるため、クラスターはクラスター構成の新しいコピーを使用して形成されます。This is why it is critical that the cluster service on the node on which the restore was executed be started first so the cluster is formed using the new copy of the cluster configuration.

権限のある復元を実行するには、次の手順を実行します。To run through an authoritative restore, the following steps can be accomplished.

  1. WBADMIN を実行します。管理コマンドプロンプトから EXE を実行して、インストールするバックアップの最新バージョンを取得し、システム状態が復元可能なコンポーネントの1つであることを確認します。Run WBADMIN.EXE from an administrative command prompt to get the latest version of backups that you want to install and ensure that System State is one of the components you can restore.

    Wbadmin get versions
    
  2. 使用しているバージョンのバックアップに、クラスターレジストリ情報がコンポーネントとして含まれているかどうかを確認します。Determine if the version backup you have has the cluster registry information in it as a component. このコマンドには、手順3で使用するために必要な、バージョンとアプリケーション/コンポーネントの2つの項目があります。There are a couple items you will need from this command, the version and the application/component for use in Step 3. たとえば、バージョンでは、バックアップが2018年1月3日に実行され、これが復元する必要があるとします。For the version, for example, say the backup was done January 3, 2018 at 2:04am and this is the one you need restored.

    wbadmin get items -backuptarget:\\backupserver\location
    
  3. 権限のある復元を開始して、必要なクラスターレジストリのバージョンのみを回復します。Start the authoritative restore to recover only the cluster registry version you need.

    wbadmin start recovery -version:01/03/2018-02:04 -itemtype:app -items:cluster
    

復元が完了したら、このノードが最初にクラスターサービスを開始し、クラスターを形成する必要があります。Once the restore has taken place, this node must be the one to start the Cluster Service first and form the cluster. その他のすべてのノードを起動し、クラスターに参加させる必要があります。All other nodes would then need to be started and join the cluster.

まとめSummary

これを合計するために、ハイパー集約されたディザスターリカバリーは、慎重に計画する必要があるものです。To sum this all up, hyper-converged disaster recovery is something that should be planned out carefully. ニーズに最適なシナリオがいくつかあり、十分にテストする必要があります。There are several scenarios that can best suits your needs and should be thoroughly tested. 注意すべき1つの項目は、過去にフェールオーバークラスターを使い慣れている場合、ストレッチクラスターは長年にわたって非常に人気のあるオプションでした。One item to note is that if you are familiar with Failover Clusters in the past, stretch clusters have been a very popular option over the years. ハイパー集約型ソリューションでは、設計に多少の変更があり、回復性に基づいています。There was a bit of a design change with the hyper-converged solution and it is based on resiliency. ハイパー収束クラスター内の2つのノードが失われた場合、クラスター全体が停止します。If you lose two nodes in a hyper-converged cluster, the entire cluster will go down. この場合、ハイパー収束環境では、ストレッチシナリオはサポートされていません。With this being the case, in a hyper-converged environment, the stretch scenario is not supported.