次の方法で共有

Azure Storage Mover の信頼性

  • [アーティクル]

この記事では、Azure Storage Mover の信頼性サポートについて説明し、可用性ゾーンによるリージョン内の回復性と、リージョン間のディザスター リカバリーおよび事業継続の両方を取り上げます。 Azure における信頼性の原則の詳細については、Azure の信頼性に関するページを参照してください。

可用性ゾーンのサポート

Azure 可用性ゾーンとは、各 Azure リージョン内にある、3 つ以上に物理的に分離されたデータセンターのグループです。 各ゾーン内のデータセンターには、独立した電源、冷却手段、ネットワーク インフラストラクチャが備わっています。 ローカル ゾーンの障害が発生した場合、可用性ゾーンは、1 つのゾーンが影響を受けたときに、リージョンのサービス、容量、高可用性が残りの 2 つのゾーンによってサポートされるように設計されています。

障害の範囲は、ソフトウェアやハードウェアの障害から、地震、水害、火災などの事象に至る可能性があります。 Azure サービスの冗長と論理的な分離により、障害に対するトレランスが実現されます。 Azure の可用性ゾーンの詳細については、リージョンと可用性ゾーンに関する記事を参照してください。

Azure の可用性ゾーン対応サービスは、適切なレベルの信頼性と柔軟性を提供するように設計されています。 それらは 2 つの方法で構成できます。 それらは、ゾーン間の自動レプリケーションによるゾーン冗長、またはインスタンスを特定のゾーンにピン留めするゾーンベースのいずれかになります。 これらのアプローチを組み合わせることもできます。 ゾーン ベースとゾーン冗長のアーキテクチャを比較した詳細については、「可用性ゾーンとリージョンの使用に関する推奨事項」を参照してください。

Azure Storage Mover は、ゾーン冗長デプロイ モデルをサポートしています。

Azure Storage Mover リソースをデプロイするときは、リソースのインスタンス メタデータが保存される特定の領域を選択する必要があります。

リージョンで可用性ゾーンがサポートされている場合、インスタンス メタデータはそのリージョン内の複数の可用性ゾーンに自動的にレプリケートされます。

重要

Azure Storage Mover のインスタンス メタデータには、プロジェクト、エンドポイント、エージェント、ジョブ定義、ジョブ実行履歴が含まれますが、移行される実際のデータは含まれません。 移行ターゲットとして使用する Azure ストレージ アカウントには、独自の信頼性サポートがあります。

前提条件

ゾーン ダウン エクスペリエンス

ゾーン全体の停止中、ゾーンの復旧中に必要なアクションはありません。 Azure Storage Mover は、正常なゾーンを自動的に利用するために、自己修復と再調整を行うように設計されています。

移行ターゲット ストレージ アカウントには、独自の回復手順が必要な場合があります。 この要件は、ストレージ アカウントごとに選択された冗長性オプションによって異なります。 ストレージ アカウントのディザスター リカバリー に関するガイドを参照して、さらにステップ実行が必要かどうかを確認してください。

冗長性オプションの代わりにローカル ストレージを選択した場合は、停止中に移行に使用する新しいストレージ アカウントを作成することが必要になる場合があります。

リージョン間のディザスター リカバリーおよび事業継続

ディザスター リカバリー (DR) とは、ダウンタイムやデータ損失につながるような、影響の大きいイベント (自然災害やデプロイの失敗など) から復旧することです。 原因に関係なく、災害に対する最善の解決策は、明確に定義されテストされた DR プランと、DR を積極的にサポートするアプリケーション設計です。 ディザスター リカバリー計画の作成を検討する前に、「ディザスター リカバリー戦略の設計に関する推奨事項」を参照してください。

DR に関しては、Microsoft は共有責任モデルを使用します。 共有責任モデルでは、ベースライン インフラストラクチャとプラットフォーム サービスの可用性が Microsoft によって保証されます。 同時に、多くの Azure サービスでは、データのレプリケート、または障害が発生したリージョンから別の有効なリージョンにクロスレプリケートするフォールバックは、自動的には行われません。 それらのサービスについては、お客様がワークロードに適したディザスター リカバリー計画を設定する必要があります。 Azure PaaS (サービスとしてのプラットフォーム) オファリング上で実行されるほとんどのサービスには、DR をサポートするための機能とガイダンスが用意されており、お客様はサービス固有の機能を使って迅速な復旧をサポートでき、DR 計画の開発に役立ちます。

Storage Mover エージェントは、登録時に、Storage Mover リソースが登録されているリージョンに接続します。 エージェントの Azure リージョンで障害が発生した場合、エージェント自体は影響を受けませんが、Azure に依存する管理操作を完了できない可能性があります。 さらに、影響を受けるリージョン内にあるストレージ アカウントへのアクティブなデータ移行が失敗する可能性があります。

Storage Mover は、ディザスター リカバリーの次の 2 つのフォームをサポートしています。

重要

オンプレミスのデータ ソースのディザスター リカバリーは、お客様の責任です。

Azure によって開始されるディザスター リカバリー

Azure によって開始されるディザスター リカバリーは、リージョン ペアのあるリージョンにのみ適用されます。 リージョン間レプリケーションを利用すると、インスタンス メタデータは各リージョンにレプリケートされますが、geographyから離れることは許可されません。

Azure Storage Mover は、インスタンス メタデータの保存に Cosmos DB を使用します。 データ損失は、Azure Cosmos DB で回復不可能な障害が発生した場合にのみ、発生する可能性があります。 詳細については、「リージョンの停止」を参照してください。 Azure によって開始される復旧はアクティブ/パッシブであり、リージョンの完全復旧は最大 24 時間です。

お客様が開始したディザスター リカバリー

お客様が開始したディザスター リカバリーは、ペアになっているリージョンに制限されません。

リージョンの停止が発生する前:

  • 可用性ゾーンをサポートするリージョンに Storage Mover リソースを作成して、ゾーン冗長 Storage Mover をデプロイします。

  • 定期的に (スケジュールどおり、または大幅な変更を行った後に)、Storage Mover リソースのスナップショットを取得します。 バージョン コントロールシステムを使用してスナップショットを保存することは、スナップショットの履歴を保存および追跡するための優れた方法です。 新しいリージョンでリソースを復旧する必要がある災害時には、最後の良い状態のスナップショットを使用します。

リージョンの停止発生中:

次の 2 つのいずれかを行うことができます。

  • Azure がリージョンを復旧するまで待つことを選択します。
  • リソースを別のリージョンに再デプロイすることで、ダウンタイムを最小限に抑えます。 停止中はリソースへのアクセスに影響がある可能性があるため、リソースの直近の良い状態のスナップショットを使用することをお勧めします。

ヒント

これらの戦略のいずれも、災害の前にさらなるステップを実行する必要がある場合があるため、それに応じて確認して計画してください。

リソースを別のリージョンにデプロイする

Azure Resource Manager (ARM) テンプレートとしてリソースをエクスポートする方法の詳細については、 テンプレートのエクスポート に関するドキュメントを参照してください。

Storage Mover と関連リソースが追加のリソースのないコンテナー内に存在する場合は、 リソース グループ エクスポートを実行して、現在の状態をキャプチャする必要があります。 ただし、リソース グループに関連のないリソースが含まれている場合は、テンプレートからリソースを削除または除外する必要がある場合があります。

既存のエージェントを別のリージョンに再デプロイすることはできません。 最初に構成されたリージョンで障害が発生した場合、エージェントの完全な登録解除と再登録ができない可能性があります。 このドキュメントでは、新しいエージェントが新しいリージョン内に登録されていることを前提としています。

エクスポートされたテンプレートをディザスター リカバリーに使用するには、テンプレートにいくつかの変更が必要です。

  • 最初に、テンプレートから Microsoft.StorageMover/agents リソースと Microsoft.HybridCompute/machines リソースを削除します。 これらのリソースへの依存関係参照も必ず削除してください。
  • 次に、すべてのジョブ定義から agentResourceId プロパティを削除します。 デプロイ後に新しいエージェントに割り当てる必要があります。
  • エージェントとハイブリッド コンピューティング マシン リソースへのすべての参照を削除した後、最上位レベルの Storage Mover リソースの 保存先プロパティを更新します。 現在デプロイされているリージョンの名前を新しいリージョンの名前に置き換えます。
  • 最後に、既存のストレージ アカウント リソース ID を保持するかどうかを決定します。 必要に応じて、別のストレージ アカウントに置き換えます。

前のステップを完了し、テンプレート パラメータが正しいことを確認した後、テンプレートは新しいリージョンにデプロイする準備ができています。 テンプレート内の 保存先プロパティと同じデフォルトのリージョンを持つ新しいリソース グループにテンプレートをデプロイする必要があります。

新しいエージェントの再登録

新しい Storage Mover リソースに新しいエージェントを登録するには、 Azure Storage Mover エージェントをデプロイする方法 に関する記事のステップに従います。

ジョブ定義へのエージェントの割り当て

新しいエージェントが登録され、オンラインとして報告されたら、Azure portal または PowerShell を使用して、既存のジョブ定義を新しいエージェントに関連付けます。 便宜上、次の PowerShell の例が提供されています。

プロジェクトのジョブ定義にアクセスする方法のガイダンスについては、新しい移行ジョブを定義する を参照してください。


## Update the agent in a job definition resource
$resourceGroupName  = "[Your resource group name]"
$storageMoverName   = "[Your storage mover name]"
$projectName        = "[Your project name]"
$jobDefName         = "[Your job definition name]"
$agentName          = "[The name of an agent previously registered to the same storage mover resource]"

Update-AzStorageMoverJobDefinition `
    -ResourceGroupName $resourceGroupName `
    -StorageMoverName $storageMoverName `
    -ProjectName $projectName `
    -Name $jobDefName `
    -AgentName $agentName

ターゲット ストレージ コンテナーへのアクセス権をエージェントに許可する

移行ジョブを正常に実行するには、データ共同作成者ロールをマネージド ID に割り当てる必要があります。 ハイブリッド コンピューティング リソースのシステム マネージド ID アクセスをターゲット ストレージ アカウント リソースに割り当てます。 リソースにマネージド ID アクセスを割り当てる に関するアーティクルでは、ターゲット リソースへのアクセスを許可する方法に関するガイダンスを提供します。

これで、新しくデプロイされた Storage Mover リソースを使用して移行ジョブを開始する準備ができました。

次のステップ