ストレージ アカウントがレプリケートされる方法を変更する

Azure Storage では、計画的および計画外の両方のイベントでデータを保護するために、その複数のコピーを常に保存します。 このようなイベントには、一時的なハードウェア障害、ネットワークの停止や停電、大規模な自然災害が含まれます。 データ冗長により、障害が発生しても、ストレージ アカウントが Azure Storage のサービス レベル アグリーメント (SLA) を満たすことが保証されます。

この記事では、既存のストレージ アカウントのレプリケーション設定を変更するプロセスについて説明します。

レプリケーションの種類を変更するためのオプション

ご自身のシナリオに最適な冗長構成を決定する際には、低コストと高可用性のトレードオフを検討してください。 どの冗長構成を選択するかの判断に役立つ要因は次のとおりです。

• プライマリ リージョンでのデータのレプリケート方法。 プライマリ リージョンのデータは、ローカル冗長ストレージ (LRS) を使用してローカルにレプリケートすることも、ゾーン冗長ストレージ (ZRS) を使用して Azure 可用性ゾーン全体にレプリケートすることもできます。
• データが geo レプリケートされているかどうか。 geo レプリケーションは、プライマリ リージョンから地理的に離れている 2 番目のリージョンにデータをレプリケートすることで、地域災害から保護します。 geo レプリケートされた構成には、geo 冗長ストレージ (GRS) と geo ゾーン冗長ストレージ (GZRS) があります。
• アプリケーションがセカンダリ リージョンのレプリケートされたデータへの読み取りアクセスを必要とするかどうか。 プライマリ リージョンが何らかの理由で使用できなくなった場合に、セカンダリ リージョンにレプリケートされたデータへの読み取りアクセスを許可するようにストレージ アカウントを構成できます。 セカンダリ リージョンのデータへの読み取りアクセスを提供する構成には、読み取りアクセス geo 冗長ストレージ (RA-GRS) と読み取りアクセス geo ゾーン冗長ストレージ (RA-GZRS) があります。

すべての冗長オプションの詳細な概要については、「Azure Storage の冗長性」を参照してください。

必要に応じてストレージ アカウントの冗長構成を変更できますが、一部の構成には制限とダウンタイムの要件が適用されます。 環境に変更を加える前にこれらの制限と要件を確認することで、お客様自身の時間枠やアップタイム要件との競合を回避することができます。

レプリケーション設定を変更するには、次の 3 つの方法があります。

• セカンダリ リージョンへの geo レプリケーションまたは読み取りアクセスを追加または削除します。
• 変換を実行して、ゾーン冗長を追加または削除します。
• 最初の 2 つのオプションがサポートされていないシナリオで手動移行を実行するか、特定の期間内で変更が完了するようにします。

geo 冗長と読み取りアクセスは同時に変更できます。 ただし、ゾーン冗長も伴う変更には変換が必要であり、2 段階のプロセスを使用して個別に実行する必要があります。 これらの 2 つの手順は、任意の順序で実行できます。

冗長構成の変更

次の表に、レプリケーションの種類を切り替える方法の概要を示します。

¹ geo 冗長を追加すると、1 回限りのエグレス料金が発生します。
² ご自分のストレージ アカウントにアーカイブ層の BLOB が含まれている場合は、アクセス層の制限事項 を確認してから、冗長の種類を geo 冗長またはゾーン冗長に変更してください。
³ サポートされる変換の種類は、ストレージ アカウントの種類によって異なります。 詳しくは、ストレージ アカウントの表をご覧ください。
⁴ フェールオーバーによる LRS アカウントの ZRS または GZRS への変換はサポートされていません。 詳細については、フェールオーバーとフェールバックに関するセクションを参照してください。
⁵ LRS から ZRS への変換は、Azure Blob Storage で NFSv3 プロトコルのサポートが有効になっている場合、またはストレージ アカウントに Azure Files NFSv4.1 共有が含まれている場合には、サポートされません。
⁶ geo 冗長の有効化は即時に行われるように見えますが、2 つのリージョン間のデータ同期が完了するまでは、セカンダリ リージョンへのフェールオーバーを開始することはできません。

レプリケーション設定を変更する

冗長構成の変更のシナリオに応じて、以下のいずれかの方法を使用してレプリケーション設定を変更します。

Azure portal、PowerShell、または Azure CLI を使用して冗長構成を変更する

ほとんどの場合、Azure portal、PowerShell、または Azure CLI を使用して、ストレージ アカウントの geo 冗長または読み取りアクセス (RA) レプリケーション設定を変更できます。

Azure portal でストレージ アカウントがレプリケートされる方法を変更しても、変換が必要な変更を含め、アプリケーションのダウンタイムは発生しません。

Set-AzStorageAccount -ResourceGroupName <resource_group> `
    -Name <storage_account> `
    -SkuName <sku>

az storage account update \
    --name <storage-account> \
    --resource-group <resource_group> \
    --sku <sku>

変換を実行する

冗長の "変換" とは、ストレージ アカウントのゾーン冗長の側面を変更するプロセスです。

変換中、データの損失は発生せず、アプリケーションのダウンタイムは必要ありません。

変換を開始するには、次の 2 つの方法があります。

• 顧客が開始
• サポート側で開始

顧客が開始した変換

サポート リクエストを開く代わりに、ほとんどのリージョンの顧客は、変換を開始してその進捗状況を監視できます。 このオプションは、サポート リクエストの作成と管理に関連する潜在的な遅延を排除します。 顧客が開始した変換がサポートされているリージョンを決定する方法については、リージョンの制限に関する記事を参照してください。

顧客が開始した変換は、Azure portal、PowerShell、または Azure CLI を使用して、サポートされているリージョンで完了できます。 開始されても、変換が開始されるまで最大 72 時間かかることがあります。

Start-AzStorageAccountMigration
    -AccountName <String>
    -ResourceGroupName <String>
    -TargetSku <String>
    -AsJob

az storage account migration start  \
    -- account-name <string> \
    -- g <string> \
    --sku <string> \
    --no-wait

顧客が開始した変換の進行状況の監視

変換要求が評価されて処理されると、状態は次の表に示すリストに進みます。

¹ 開始後、通常であれば変換は 72 時間以内に始まりますが、場合によってはそれより長くかかることがあります。 顧客が開始した変換のタイミングの詳細については、「タイミングと頻度」を参照してください。
² 変換が失敗した場合は、Microsoft にサポート リクエストを送信して、失敗の理由を特定します。

Get-AzStorageAccountMigration
   -AccountName <String>
   -ResourceGroupName <String>

az storage account migration show \
    --account-name <string> \
    - g <sting> \
    -n "default"

サポート側で開始した変換

お客様は、Microsoft でサポート リクエストをオープンすることで、変換を依頼できます。

Microsoft からの変換を依頼するには、次の手順に従います。

1. Azure portal で、変換するストレージ アカウントに移動します。

2. [サポートとトラブルシューティング] で、 [新しいサポート リクエスト] を選択します。

3. アカウント情報に基づき [問題の説明] タブに入力します。

   • 概要: (説明テキスト)
   • 問題の種類: [Technical](テクニカル) を選択します。
   • サブスクリプション:ドロップダウン リストからサブスクリプションを選択します。
   • サービス: [使用中のサービス] を選択し、[サービスの種類] の [ストレージ アカウントの管理] を選択します。
   • リソース: 変換するストレージ アカウントを選択します。 複数のストレージ アカウントを指定する必要がある場合は、[追加情報] タブで行うことができます。
   • 問題の種類: [データ移行] を選択します。
   • 問題のサブタイプ: [Migrate to ZRS, GZRS, or RA-GZRS](ZRS、GZRS、または RA-GZRS に移行) を選択します。

   

4. [次へ] を選択します。 [ソリューション] ページに切り替わる前に、[推奨される解決策] タブが一瞬表示される場合があります。 [ソリューション] ページで、変換に関するストレージ アカウントの適格性を確認できます。

   • ターゲット レプリケーションの種類: (ドロップダウンから目的のオプションを選択)
   • 移行元のストレージ アカウント: (1 つのストレージ アカウント名またはセミコロンで区切ったアカウントのリストを入力)
   • [Submit](送信) をクリックします。

   

5. ストレージ アカウントが変換に適格でないことが結果に示されている場合は、適切なアクションを実行します。 それ以外の場合は、[サポート リクエストに戻る] を選択します。

6. [次へ] を選択します。 移行するストレージ アカウントが複数ある場合は、[詳細] タブで、各アカウントの名前をセミコロンで区切って指定します。

   

7. [その他の詳細] タブで必要な情報を指定し、[確認および作成] を選択して、サポート チケットを確認し、送信します。 Azure サポート エージェントがケースを確認し、サポートを提供するために連絡します。

手動移行

手動の移行は、変換よりも高い柔軟性を備えています。 特定の日付までにデータを移動する必要がある場合、または変換がシナリオでサポートされていない場合は、このオプションを使用できます。 手動移行は、ストレージ アカウントを別のリージョンに移動する場合にも役立ちます。 詳細については、「Azure ストレージ アカウントを別のリージョンに移動する」をご覧ください。

以下の場合には手動の移行を実行する必要があります。

• ストレージ アカウントを別のリージョンに移行する必要があります。
• ストレージ アカウントは、BLOB またはブロック BLOB アカウントです。
• ストレージ アカウントのアーカイブ ストレージ層にデータが含まれており、データのリハイドレートは望ましくありません。

手動の移行では、既存のストレージ アカウントから、新しいストレージ アカウントに、データをコピーします。 手動の移行を実行する場合、次のいずれかのオプションを使用できます。

• AzCopy のような既存のツール、Azure Storage クライアント ライブラリのいずれか、または信頼できる Microsoft 以外のツールを使用して、データをコピーします。
• Hadoop や HDInsight を使い慣れている場合は、ソース ストレージ アカウントとターゲット ストレージの両方をクラスターにアタッチできます。 次に、DistCp などのツールを使用してデータ コピー処理を並列化します。

手動移行を実行する方法の詳細なガイダンスについては、「Azure ストレージ アカウントを別のリージョンに移動する」を参照してください。

レプリケーションの種類の変更に関する制限事項

以下の条件に応じて、一部のレプリケーション変更シナリオに制限が適用されます。

• リージョン
• 機能の競合
• ストレージ アカウントの種類
• アクセス層
• プロトコルのサポート
• フェールオーバーとフェールバック

リージョン

ストレージ アカウントが配置されているリージョンで、必要なすべてのレプリケーション設定がサポートされていることを確認します。 たとえば、アカウントをゾーン冗長 (ZRS、GZRS、または RA-GZRS) に変換する場合は、ストレージ アカウントが、これをサポートするリージョンにあることを確認します。 ゾーン冗長ストレージと geo ゾーン冗長ストレージでサポートされているリージョンの一覧を参照してください。

機能の競合

一部のストレージ アカウント機能は、他の機能や操作と互換性がありません。 たとえば、セカンダリ リージョンにフェールオーバーする機能は geo 冗長の重要な機能ですが、その他の機能はフェールオーバーと互換性がありません。 フェールオーバーでサポートされていない機能とサービスの詳細については、「サポートされていない機能とサービス」を参照してください。 競合する機能が有効になっている場合、アカウントの GRS、GZRS、または RA-GZRS への変換はブロックされる可能性があります。または、フェールオーバーを開始する前に、後で機能を無効にする必要がある場合があります。

ストレージ アカウントの種類

レプリケーション設定を変更する場合は、ストレージ アカウントの種類に関連する次の制限事項を考慮してください。

一部のストレージ アカウントの種類では、変換と移行のどちらが可能かと、可能な場合はその方法に影響する、特定の冗長構成のみがサポートされます。 Azure ストレージ アカウントの種類とサポートされている冗長オプションの詳細については、ストレージ アカウントの概要に関する記事を参照してください。

次の表は、ストレージ アカウントの種類で使用できる冗長性オプションの概要と、変換と手動移行がサポートされるかどうかを示しています。

¹ Premium ファイル共有の変換は、サポート リクエストを開いて利用できます。お客様が開始する変換は、PowerShell または Azure CLI を使って行うことができます。
² マネージド ディスクは LRS と ZRS で使用できますが、ZRS ディスクにはいくつか制限があります。 LRS ディスクがリージョンである (ゾーンが指定されていない) 場合、SKU を変更すると変換できます。 LRS ディスクがゾーンである場合、「マネージド ディスクを移行する」のプロセスに従って、手動でのみ移行することができます。 Standard SSD マネージド ディスクのスナップショットとイメージを、Standard HDD ストレージに格納できます。また、LRS オプションと ZRS オプションから選択できます。 可用性セットとの統合については、「Azure マネージド ディスクの概要」を参照してください。
³ ストレージ アカウントが v1 の場合は、変換を実行する前に v2 にアップグレードする必要があります。 v1 アカウントをアップグレードする方法については、「汎用 v2 ストレージ アカウントにアップグレードする」を参照してください。
⁴ ZRS クラシック ストレージ アカウントは非推奨になりました。 ZRS クラシック アカウントの変換については、「ZRS クラシック アカウントの変換」を参照してください。

ZRS クラシック アカウントの変換

ZRS クラシックを利用できるのは、汎用 V1 (GPv1) ストレージ アカウントのブロック BLOB に限られました。 ストレージ アカウントについて詳しくは、「Azure ストレージ アカウントの概要」をご覧ください。

ZRS クラシック アカウントでは、1 つから 2 つのリージョン内の複数のデータセンターに、データが非同期的にレプリケートされます。 Microsoft がセカンダリへのフェールオーバーを開始していないと、レプリケートされたデータは利用できませんでした。 ZRS クラシック アカウントと LRS、GRS、または RA-GRS を相互に変換することはできません。 また、ZRS クラシック アカウントは、メトリックまたはログをサポートしていません。

ZRS クラシックを別のレプリケーションの種類に変更するには、次のいずれかの方法を使用します。

• まず ZRS にアップグレードする
• データを別のレプリケーションの種類に直接手動で移行する

ZRS クラシック ストレージ アカウントを ZRS にアップグレードするには、Azure portal、PowerShell、Azure CLI を ZRS が使用できるリージョン内で使用します。

Set-AzStorageAccount -ResourceGroupName <resource_group> -AccountName <storage_account> -UpgradeToStorageV2

az storage account update -g <resource_group> -n <storage_account> --set kind=StorageV2

ZRS クラシック アカウント データを別の種類のレプリケーションに手動で移行するには、手動移行を実行する手順に従います。

ソース アカウントとは異なるリージョンにあるゾーン冗長ストレージ アカウントにデータを移行する場合は、手動で移行する必要があります。 詳細については、「Azure ストレージ アカウントを別のリージョンに移動する」をご覧ください。

アクセス層

目的の冗長オプションが、ストレージ アカウントで現在使用されているアクセス層をサポートしていることを確認します。 たとえば、ZRS、GZRS、RA-GZRS のストレージ アカウントでは、アーカイブ ストレージ層はサポートされていません。 詳細については、BLOB データのホット、クール、アーカイブ アクセス層に関するページを参照してください。 LRS、GRS、RA-GRS のいずれかのアカウントを、ゾーン冗長をサポートするアカウントに変換するには、最初にアーカイブされた BLOB をアーカイブ層の BLOB をサポートするストレージ アカウントに移動します。 次に、ソース アカウントを ZRS、GZRS、RA-GZRS に変換します。

アーカイブ ストレージ層の BLOB を含む LRS ストレージ アカウントは、アーカイブされたすべての BLOB をホット ストレージ層またはクール ストレージ層にリハイドレートした後、GRS または RA-GRS に切り替えることができます。 手動の移行を実行することもできます。

プロトコルのサポート

次のいずれかのケースに該当する場合、ストレージ アカウントをゾーン冗長 (ZRS、GZRS、RA-GZRS) に変換することはできません。

• Azure Blob Storage で NFSv3 プロトコルのサポートが有効になっている
• ストレージ アカウントに Azure Files NFSv4.1 共有が含まれている

フェールオーバーとフェールバック

アカウントをセカンダリ リージョンにフェールオーバーした後、PowerShell または Azure CLI (バージョン 2.30.0 以降) を使用して新しいプライマリから新しいセカンダリへのフェールバックを開始することができます。 フェールオーバーを開始します。

GRS または RA-GRS アカウントの障害から復旧するために、カスタマー マネージド アカウントのフェールオーバーを実行した場合、そのアカウントはフェールオーバー後に新しいプライマリ リージョンでローカル冗長 (LRS) になります。 フェールオーバーによって行われる LRS アカウントの ZRS または GZRS への変換はサポートされていません。 代わりに、手動移行を実行してゾーン冗長を追加します。

ダウンタイムの要件

変換中にはストレージ アカウント内のデータにアクセスでき、持続性や可用性が失われることはありません。 この移行プロセスの間も Azure Storage SLA は維持され、変換中にデータは失われません。 サービス エンドポイント、アクセス キー、Shared Access Signature、およびその他のアカウント オプションは、移行後も変更されません。

手動移行の実行を選択した場合、ダウンタイムは発生しますが、移行プロセスのタイミングをより詳細に制御できます。

タイミングと頻度

Azure portal からゾーン冗長の変換を開始した場合、変換プロセスが開始されるまで最大 72 時間かかる可能性があります。 サポート リクエストを開いて変換を要求した場合は、開始するまでにさらに時間がかかる可能性があります。 顧客が開始した変換の進行状況を監視するには、「顧客が開始した変換の進行状況の監視」を参照してください。

ゾーン冗長の変換後、ストレージ アカウントの冗長設定を再度変更するには、少なくとも 72 時間待つ必要があります。 一時的な保留を使用すると、別の変更を行う前にバックグラウンド プロセスを完了することができ、アカウントの一貫性と整合性が確保されます。 たとえば、LRS から GZRS への移動は 2 段階のプロセスです。 1 回の操作でゾーン冗長を追加し、2 回目の操作で geo 冗長を追加する必要があります。 LRS から ZRS への移動後、ZRS から GZRS に移動するには、少なくとも 72 時間待つ必要があります。

データがレプリケートされる方法の変更に関連するコスト

Azure Storage には、レプリケーションの構成用にいくつかのオプションが用意されています。 これらのオプションは、次のように価格の安いものから順に並んでいます。

• LRS
• ZRS
• GRS
• RA-GRS
• GZRS
• RA-GZRS

ストレージ アカウントでのデータのレプリケート方法の変更に関連するコストは、変更する冗長構成の側面によって異なります。 データ ストレージとエグレス帯域幅の価格の組み合わせによって、変更のコストが決まります。 価格の詳細については、Azure Storage の価格に関するページをご覧ください。

プライマリ リージョンにゾーン冗長を追加する場合、その変換に関連する初期コストは発生しませんが、必要なレプリケーションとストレージ スペースが増加するため、継続的なデータ ストレージ コストが高くなります。

geo 冗長によって、ストレージ アカウント全体がセカンダリ リージョンにレプリケートされるため、変更時にエグレス帯域幅の料金が発生します。 それ以降のプライマリ リージョンへの書き込みでも、セカンダリ リージョンへの書き込みをレプリケートするためのエグレス帯域幅の料金が発生します。

geo 冗長を削除する (GRS から LRS に変更する) 場合、変更のコストは発生しませんが、レプリケートされたデータはセカンダリの場所から削除されます。

関連項目

• Azure Storage の冗長性
• geo 冗長性を使用する高可用性アプリケーションの設計
• Azure ストレージ アカウントを別のリージョンに移動する
• ストレージ アカウントの最終同期時刻プロパティを確認する