Azure Files データのレプリケート方法を変更する

✔️ 対象: Microsoft.Storage リソースプロバイダーで作成され、Provisioned v1、Provisioned v2、または従量課金の課金モデルを使用するクラシックファイル共有

✖️ 次には適用されません: Microsoft.FileShares リソースプロバイダーで作成されたファイル共有

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

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

重要

ゾーンストレージアカウントを使用している場合は、冗長性構成をローカル冗長ストレージ (LRS) から LRS 以外の構成に変更する前に、まずストレージアカウントをゾーンから固定解除する必要があります。

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

ご自身のシナリオに最適な冗長構成を決定する際には、低コストと高可用性のトレードオフを検討してください。冗長性構成を選ぶ際の要因には以下が含まれます:

プライマリリージョンでのデータのレプリケート方法。 プライマリリージョンのデータは、ローカル冗長ストレージ (LRS) を使用してローカルにレプリケートすることも、ゾーン冗長ストレージ (ZRS) を使用して Azure 可用性ゾーン全体にレプリケートすることもできます。
データに geo 冗長が必要かどうか。 ジオ冗長性は、データを主要な地域から地理的に離れた第二の地域に複製することで、地域災害からの保護を提供します。 Azure Files では、geo 冗長ストレージ (GRS) と geo ゾーン冗長ストレージ (GZRS)の両方がサポートされています。

重要

Azure Files では、読み取りアクセス geo 冗長ストレージ (RA-GRS) または読み取りアクセス geo ゾーン冗長ストレージ (RA-GZRS) はサポートされていません。ストレージアカウントが RA-GRS または RA-GZRS を使用するように構成されている場合、ファイル共有は GRS または GZRS として構成され、またそのように課金されます。

すべての冗長オプションの詳細な概要については、Azure Files の冗長性に関するページを参照してください。

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

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

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

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

冗長構成の変更

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

Note

手動移行は、レプリケーションの種類の変更に関する制限内でレプリケーション設定を変更するすべてのシナリオで選択できるオプションです。簡略化のため、手動移行オプションは次の表から除外されています。

切り替え	LRS へ	GRS へ ⁶	先: ZRS	GZRS へ ^2、6
元: LRS	N/A	Azure portal、PowerShell、または CLI^1、2 を使用する	変換を実行する^{2、3、4、5}	まず、Portal、PowerShell、または CLI を使用して GRS ¹ に切り替え、その後 GZRS 3、4、5 への^{変換を実行}
GRS から	Azure portal、PowerShell、または CLI を使用する	N/A	まず、Portal、PowerShell、または CLI を使用して LRS に切り替え、次に ZRS 3、5 への^{変換を実行する}	変換を実行する^3、5
元: ZRS	変換を実行する³	まず、Portal、PowerShell、または CLI を使用して GZRS に切り替え、その後 GRS 3 への^{変換を実行}	N/A	Azure portal、PowerShell、または CLI¹ を使用する
GZRS から	まず、Portal、PowerShell、または CLI を使用して ZRS に切り替え、その後 LRS 3 への^{変換を実行する}	変換を実行する³	Azure portal、PowerShell、または CLI を使用する	N/A

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

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

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

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

リージョン

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

重要

LRSからZRSへの顧客主導の変換は、ZRSをサポートするすべての公開地域で利用可能ですが、以下の地域を除きます。

(北米) メキシコ中部

既存の ZRS アカウントから LRS への顧客が開始した変換は、すべてのパブリックリージョンで利用できます。

機能の競合

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

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

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

一部のストレージアカウントタイプは特定の冗長性設定のみをサポートしており、それが変換や移行の方法に影響を与えます。 Azure ストレージアカウントの種類とサポートされている冗長オプションの詳細については、ストレージアカウントの概要に関する記事を参照してください。

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

ストレージアカウントの種類	LRS のサポート	ZRS のサポート	変換のサポート (Azure portal から)	変換のサポート (サポートリクエストによる)	手動移行のサポート
SSD プロビジョニング済み v1	✅	✅	✅	✅ ¹	✅
HDD 従量課金制	✅	✅	✅	✅	✅

¹ 客戶發起轉換(client-initiated conversion)時,Azure portal、PowerShell、またはAzure CLIを使用。サポートリクエストを出すこともできます。

プロトコルのサポート

ストレージアカウントにNFSファイル共有があり、パブリックエンドポイントアクセスが有効であれば、ストレージアカウントをゾーン冗長(ZRSまたはGZRS)に変換することはできません。

パブリックエンドポイントが有効になっている NFSv4.1 共有の変換はサポートされていません。公開エンドポイントを持つNFS共有の冗長性を変更するには、以下の手順に従ってください:

ストレージアカウントのパブリックエンドポイントへのアクセスを無効にします。
特定のストレージアカウントの冗長を変更する変換要求を送信します。
ストレージアカウントが移行された後、必要に応じてプライベートまたはパブリックエンドポイントを設定してください。

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

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

GRSアカウントの障害から回復するためにカスタマー管理のアカウントフェイルオーバーを行うと、フェイルオーバー後、アカウントは新しいプライマリリージョンでローカル冗長(LRS)になります。フェイルオーバーによるLRSアカウントでは、いわゆるフェイルバック操作であっても、ZRSやGZRSへの変換はサポートされていません。たとえば、セカンダリリージョンで GRS から LRS へのアカウントフェールオーバーを実行してから、それを再度 GRS として構成すると、新しいセカンダリリージョン (元のプライマリ) では LRS のままになります。その後、別のアカウントフェールオーバーを実行して元のプライマリリージョンにフェールバックすると、元のプライマリでもう一度 LRS のままになります。この場合、プライマリリージョンで ZRS または GZRS への変換を実行することはできません。代わりに、手動移行を実行してゾーン冗長を追加します。

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

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

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

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

ストレージアカウントのAzureポータルでのレプリケート方法を変更しても、変換が必要な変更を含めてアプリケーションのダウンタイムにはつながりません。

Azure portal でストレージアカウントの冗長オプションを変更するには、以下の手順に従います。

Azure portal のストレージアカウントに移動します。
[データ管理] で [冗長性] を選択します。
冗長性設定を更新します。
[保存] を選択します。

Azure PowerShell を使用して、ストレージアカウントの冗長オプションを変更できます。

ローカル冗長と geo 冗長ストレージを切り替えるには、Set-AzStorageAccount コマンドレットを呼び出し、-SkuName パラメーターを指定します。

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

Azure CLI を使用して、ストレージアカウントの冗長オプションを変更できます。

ローカル冗長と geo 冗長ストレージを切り替えるには、az storage account update コマンドを呼び出し、--sku パラメーターを指定します。

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

変換を実行する

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

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

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

顧客が開始
サポート開始

ヒント

可能な限り、サポート主導の変換ではなく、顧客主導の変換を活用しましょう。顧客主導のコンバージョンでは、Azureポータルから直接コンバージョンを開始し、進行状況を監視できます。サポートリクエストを作成したり管理したりする必要はありません。

顧客が開始した変換

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

HDD(標準)ファイル共有の場合、Azureポータル、PowerShell、またはAzure CLIを使って、サポート地域で顧客主導の変換を完了できます。

SSD(プレミアム)ファイル共有の場合、顧客主導の変換はAzureポータル、PowerShell、Azure CLIを通じて可能です。または、サポート側で開始した変換を要求することもできます。

開始されても、変換が開始されるまで最大 72 時間かかることがあります。

重要

変換を完了するための SLA はありません。

変換の開始と終了をより細かく制御する必要がある場合は、手動移行を検討してください。一般に、アカウント内のデータが多いほど、そのデータを他のゾーンやリージョンにレプリケートするのにかかる時間は長くなります。

顧客が開始した変換のタイミングの詳細については、「タイミングと頻度」を参照してください。

ストレージアカウントのゾーン冗長性をAzureポータル内で追加または変更するには、以下の手順を行ってください:

Azure portal のストレージアカウントに移動します。
[データ管理] で [冗長性] を選択します。
冗長性設定を更新します。
[保存] を選択します。

PowerShellを使ってローカル冗長ストレージとゾーン冗長ストレージを切り替えるには、 Start-AzStorageAccountMigration コマンドレットを使用し、 -TargetSku パラメータを指定します。

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

Azure CLIを使ってローカル冗長ストレージとゾーン冗長ストレージを切り替えるには、az storage account migration startコマンドを使用し、--skuパラメータを指定します。

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

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

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

Status	説明
変換用に送信済み	変換要求が処理のために正常に送信されました。
進行中¹	変換が進行中です。
完了 - または - 失敗²	変換が正常に完了しました。 - または - 変換に失敗しました。

¹ 開始後、改宗開始までに最大72時間かかることがあります。リクエスト開始から96時間以内にコンバージョンが進行中の状態に入らない場合は、理由を把握するためにMicrosoftにサポートリクエストを提出してください。顧客が開始した変換のタイミングの詳細については、「タイミングと頻度」を参照してください。
² 変換が失敗した場合は、Microsoft にサポートリクエストを送信して、失敗の理由を特定します。

Note

Microsoftは変換の要請を迅速に処理しますが、いつ完成するかは保証できません。もし特定の日付までにデータを変換する必要がある場合は、手動の移行を行うのが良いでしょう。

一般に、アカウント内のデータが多いほど、そのデータをリージョン内の他のゾーンにレプリケートするのにかかる時間は長くなります。

顧客が開始した変換の状態は、ストレージアカウントの [冗長] ページに表示されます。

ストレージアカウントで開始した移行の現在の移行状況を追跡するには、 Get-AzStorageAccountMigration コマンドレットを使用してください:

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

ストレージアカウント上で開始された変換の現在の移行状態を追跡するには、以下のように az storage account migration show コマンドを使用します。

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

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

お客様は、Microsoft でサポートリクエストを開いて、変換を要求できます。

ヒント

複数のストレージアカウントを変換する必要がある場合は、1 つのサポートチケットを作成し、[追加情報] タブで変換するアカウントの名前を指定します。

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

Azure portal で、変換するストレージアカウントに移動します。
[サポートとトラブルシューティング] で、[新しいサポートリクエスト] を選択します。
アカウント情報に基づき [問題の説明] タブに入力します。
- 概要:リクエストを説明し、ソースとターゲットの冗長性の種類を含めてください。
- [問題の種類]: [技術] を選択します。
- サブスクリプション: ドロップダウンからサブスクリプションを選択します。
- サービス: [使用中のサービス] を選択し、[サービスの種類] の [ストレージアカウントの管理] を選択します。
- リソース: 変換するストレージアカウントを選択します。複数のストレージアカウントを指定する必要がある場合は、[追加情報] タブで行うことができます。
- 問題の種類: [データ移行] を選択します。
- 問題のサブタイプ: [ZRS、GZRS、または RA-GZRS に移行] を選択します。
[次へ] を選択します。 [推奨される解決策] タブが、[ソリューション] ページに切り替わる前に一時的に表示される場合があります。 [ソリューション] ページで、変換に関するストレージアカウントの適格性を確認できます。
- ターゲットレプリケーションの種類: (ドロップダウンから目的のオプションを選択)
- 移行元のストレージアカウント: (単一のストレージアカウント名またはセミコロンで区切られたアカウントの一覧を入力)
- [Submit]\(送信\) をクリックします。
ストレージアカウントが変換に適格でないことが結果に示されている場合は、適切なアクションを実行します。それ以外の場合は、[サポートリクエストに戻る] を選択します。
[次へ] を選択します。移行するストレージアカウントが複数ある場合は、[詳細] タブで、各アカウントの名前をセミコロンで区切って指定します。
[その他の詳細] タブで必要な情報を指定し、[確認と作成] を選択して、サポートチケットを確認し、送信します。 Azure サポートエージェントがケースを確認し、サポートを提供するために連絡します。

手動移行

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

ストレージアカウントを別のリージョンに移行する場合は、手動で移行を実行する必要があります。

重要

手動の移行ではアプリケーションのダウンタイムが発生することがあります。申請が高可用性を必要とする場合は、コンバージョンオプションも利用可能です。変換は、ダウンタイムが発生しないインプレース移行です。

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

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

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

Azure Files の冗長性を変更する際のダウンタイム要件

ゾーン冗長化の際には、ストレージアカウントのデータに耐久性や可用性の損失なしにアクセスできます。この移行プロセスの間も Azure Storage SLA は維持され、変換中にデータは失われません。サービスエンドポイント、アクセスキー、Shared Access Signature、その他のアカウントオプションは、移行後も変更されません。

手動移行を選択する場合はダウンタイムが必要ですが、移行のタイミングをよりコントロールできます。

タイミングと頻度

顧客主導のゾーン冗長変換プロセスは開始から最大72時間かかることがありますが、リソースの可用性、データ量、その他の要因が遅延の原因となることがあります。サポートリクエストを開いてコンバージョンを依頼すると、開始に時間がかかることがあります。顧客が開始した変換の進行状況を監視するには、「顧客が開始した変換の進行状況の監視」を参照してください。

重要

変換を完了するための SLA はありません。変換の開始と終了のタイミングをよりコントロールしたいなら、手動移行を検討してください。一般に、アカウント内のデータが多いほど、そのデータを他のゾーンやリージョンにレプリケートするのにかかる時間は長くなります。

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

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

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

LRS
ZRS
GRS
GZRS

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

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

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

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

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-08-03