Azure File Sync を使用したディザスター リカバリーのベスト プラクティス
Azure File Sync の場合、ディザスター リカバリーについて考慮すべき 3 つの主要な領域があります。高可用性、データ保護とバックアップ、データ冗長性です。 この記事は各領域について説明しており、独自のディザスター リカバリー ソリューションに使用する構成を決定するのに役立ちます。
Azure File Sync デプロイにおいては、クラウド エンドポイントには常にデータの完全なコピーが含まれますが、オンプレミス サーバーはデータの破棄可能なキャッシュと見なすことができます。 サーバー側に障害が発生した場合は、新しいサーバーをプロビジョニングし、そのサーバーに Azure File Sync エージェントをインストールして、それを新しいサーバー エンドポイントとして設定することで復旧できます。
ハイブリッドという性質上、従来のサーバー バックアップとディザスター リカバリーの戦略の中には、Azure File Sync に対応していないものもあります。登録済みサーバーについて、以下のことは Azure File Sync でサポートされていません。
警告
これらのアクションを実行すると、同期の問題または階層化されたファイルの破損が発生し、最終的なデータ損失につながるおそれがあります。 これらのアクションのいずれかを実行した場合は、Azure サポートに問い合わせ、ご使用のデプロイが正常であることをご確認ください。
- サーバー エンドポイントがまだアクティブな間に、あるサーバーから別のサーバーにディスク ドライブ (ボリューム) を転送または複製する
- オペレーティング システム バックアップから復元する
- サーバーのオペレーティング システムを別のサーバーに複製する
- 以前の仮想マシン チェックポイントに戻す
- オンプレミス (サード パーティ) のバックアップからサーバー エンドポイントへ階層化されたファイルを復元する
高可用性
オンプレミス サーバーの高可用性を実現するためには、異なる 2 種類の戦略を使用できます。 フェールオーバー クラスターを構成するか、スタンバイ サーバーを構成できます。 どちらの構成にするかの決定要因は、システムにどれだけ投資する用意があるか、また、障害発生時のシステム ダウン時間の長さを最小限に抑えることに、その追加コストに見合う価値があるかどうかです。
フェールオーバー クラスターの場合、Azure File Sync を使用するために特別な手順を実行する必要はありません。スタンバイ サーバーの場合は、次の構成を行う必要があります。
異なるサーバー エンドポイントを持ち、同期先がプライマリ サーバーと同じ同期グループであるセカンダリ サーバーを作成しますが、サーバーへのエンドユーザー アクセスは有効にしません。 これにより、すべてのファイルをプライマリ サーバーからスタンバイ サーバーに同期できます。 名前空間だけが最初にダウンロードされるように、名前空間のみの階層化を有効にすることを検討できます。 プライマリ サーバーで障害が発生した場合は、DFS-N を使用して、スタンバイ サーバーへのエンドユーザー アクセスをすばやく再構成できます。
データ保護とバックアップ
実際のデータの保護は、ディザスター リカバリー ソリューションの重要なコンポーネントです。 Azure ファイル共有でこれを行うには、主に 2 つの方法があります。データのバックアップをクラウドにするかオンプレミスにするかです。 クラウドにデータをバックアップすることを強くお勧めします。なぜなら、クラウド エンドポイントにはデータの完全なコピーが含まれるのに対し、サーバー エンドポイントにはデータのサブセットのみが含まれる可能性があるからです。
クラウド内のデータのバックアップ
クラウド バックアップ ソリューションとして Azure Backup を使用する必要があります。 Azure Backup によって、バックアップのスケジュール設定、保持、復元などの処理が行われます。 必要であれば、手動で共有スナップショットを取得し、独自のスケジュール設定と保持のソリューションを構成できますが、これは理想的ではありません。 または、サードパーティのソリューションを使用して、Azure ファイル共有を直接バックアップすることもできます。
障害が発生した場合は、ファイル共有の特定の時点の読み取り専用コピーである共有スナップショットから復元できます。 これらのスナップショットは読み取り専用であるため、ランサムウェアの影響を受けません。 共有の完全復元の操作に時間がかかる大規模なデータセットの場合は、スナップショットへの直接ユーザー アクセスを可能にできます。そうすることによって、ユーザーは、復元が完了するまでの間に各自の必要なデータをローカル ドライブにコピーできます。
スナップショットは、手動で取得するか、Azure Backup によって代わりに取得するかに関係なく、Azure ファイル共有に直接保存されます。 このため、スナップショットを保護するには、ファイル共有が誤って削除されないように論理的な削除を有効にする必要があります。
詳細については、「Azure ファイル共有のバックアップについて」を参照するか、バックアップ プロバイダーにお問い合わせいただき、Azure ファイル共有のバックアップがサポートされているかどうかをご確認ください。
オンプレミスのデータをバックアップする
クラウドを使った階層化を有効にする場合は、オンプレミスのバックアップ ソリューションを実装しないでください。 クラウドを使った階層化を有効にすると、データのサブセットのみがサーバーにローカルに保存され、残りのデータはクラウド エンドポイントに保存されます。 ローカル バックアップに使用するバックアップ ソリューションに応じて、階層化されたファイルは次のいずれかになります。
- スキップされ、バックアップされない (
FILE_ATTRIBUTE_RECALL_ONDATA_ACCESS属性のため)。 - 階層化されたファイルとしてのみバックアップされる。ライブ共有での変更が原因で復元時にアクセスできない恐れがあります。
- ディスクに呼び戻される。この結果、エグレス料金が高くなります。
オンプレミス バックアップ ソリューションを使用することに決定した場合、バックアップは、クラウドを使った階層化が無効な同期グループ内のサーバーで行う必要があります。 復元を実行するときは、ボリューム レベルまたはファイル レベルの復元オプションを使用します。 ファイル レベルの復元オプションを使用して復元されたファイルは、同期グループ内のすべてのエンドポイントに同期され、既存のファイルはバックアップから復元されたバージョンに置き換えられます。 ボリューム レベルの復元では、クラウド エンドポイントまたは他のサーバー エンドポイントの新しいファイル バージョンは置き換えられません。
ボリューム シャドウ コピー サービス (VSS) スナップショット ([以前のバージョン] タブを含む) が、クラウドを使った階層化が有効なボリュームでサポートされています。 これにより、自分に代わって管理者に復元を実行してもらうのではなく、セルフサービス復元を実行できます。 ただし、PowerShell を使用して以前のバージョンの互換性を有効にする必要があり、それによってスナップショット ストレージのコストが増加します。 VSS スナップショットはサーバー エンドポイント自体の障害から保護されません。そのため、必ずクラウド側のバックアップと共に使用する必要があります。 詳細については、「以前のバージョンおよび VSS (ボリューム シャドウ コピー サービス) を使用するセルフサービス復元」を参照してください。
データの冗長性
堅牢なディザスター リカバリー ソリューションを確保するには、何らかの形式のデータ冗長性をインフラストラクチャに追加します。 Azure Files 用に 4 つの冗長性オファリングがあります。ローカル冗長ストレージ (LRS)、ゾーン冗長ストレージ (ZRS)、geo 冗長ストレージ (GRS)、および geo ゾーン冗長ストレージ (GZRS) です。
- ローカル冗長ストレージ (LRS) : LRS では、すべてのファイルが Azure ストレージ クラスター内に 3 回保存されます。 これにより、不良ディスク ドライブなどのハードウェア障害によるデータの損失を防ぐことができます。 ただし、データセンター内で火災や洪水などの災害が発生した場合、LRS を使用しているストレージ アカウントのすべてのレプリカが失われたり、回復不能になる可能性があります。
- ゾーン冗長ストレージ (ZRS): ZRS を使用すると、各ファイルのコピーが 3 つ保存されますが、これらのコピーは物理的に異なる Azure "可用性ゾーン" にある 3 つの異なるストレージ クラスターに分離されます。 可用性ゾーンは、Azure リージョン内の一意の物理的な場所です。 それぞれのゾーンは、独立した電源、冷却手段、ネットワークを備えた 1 つまたは複数のデータ センターで構成されています。 3 つの可用性ゾーンすべてのストレージ クラスターに書き込まれるまで、ストレージへの書き込みは受け入れられません。
- Geo 冗長ストレージ (GRS): GRS の場合、プライマリ リージョンとセカンダリ リージョンの 2 つのリージョンがあります。 ファイルは、プライマリ リージョンの Azure ストレージ クラスター内に 3 回保存されます。 書き込みは、Microsoft によって定義されたセカンダリ リージョンに非同期的にレプリケートされます。 GRS を使用すると、データの 6 つのコピーが 2 つの Azure リージョンに分散して作成されます。
- Geo ゾーン冗長ストレージ (GZRS): GZRS は、ZRS のようなものと考えることができますが、geo 冗長を備えています。 GZRS を使用すると、ファイルはプライマリ リージョンの 3 つの異なるストレージ クラスターに 3 回保存されます。 その後、すべての書き込みが Microsoft で定義されたセカンダリ リージョンに非同期的にレプリケートされます。
堅牢なディザスター リカバリー ソリューションにするためには、ほとんどのお客様は ZRS を検討する必要があります。 ZRS は、追加されるデータ冗長性の利点の割に追加コストが最小限で済み、障害が発生した場合に最もシームレスです。 組織のポリシーまたは規制要件によってデータに対する geo 冗長性が必要とされる場合は、GRS または GZRS を検討してください。
geo 冗長
ストレージ アカウントが GRS または GZRS レプリケーションのいずれかが構成されている場合、プライマリ リージョンが永続的に回復不可能または長時間使用できないと判断されると、Microsoft によってストレージ同期サービスのフェールオーバーが開始されます。 障害が発生した場合に、自分で行う必要のある操作はありません。
GRS または GZRS のペア リージョンへのストレージ同期サービスのフェールオーバーを手動で要求することもできますが、そのプロセスはシームレスではなく、追加コストが発生する場合があるため、大規模なリージョン停止以外の場合にこれを行うことはお勧めしません。 プロセスを開始するには、サポート チケットを開き、Azure ファイル共有を含む Azure ストレージ アカウントとストレージ同期サービスの両方がフェールオーバーするように要求してください。
警告
このプロセスを手動で開始する場合、ご使用のストレージ同期サービスのフェールオーバーを要求するには、サポートにお問い合わせください。 同じサーバー エンドポイントを使用してセカンダリ リージョンに新しいストレージ同期サービスを作成しようとすると、Azure File Sync の以前のインストールはクリーンアップされないため、ストレージ アカウントに余分なデータが残ることがあります。
フェールオーバーが発生すると、サーバー エンドポイントは、セカンダリ リージョンのクラウド エンドポイントと自動的に同期するために切り替えられます。 ただし、サーバー エンドポイントはクラウド エンドポイントと調整する必要があります。 この場合、セカンダリ リージョンのデータがプライマリと同じにならない可能性があるため、ファイルの競合が発生する場合があります。