Azure Files のデプロイの計画

[アーティクル]
03/10/2023

Azure Files は、主に、サーバーレスの Azure ファイル共有を直接マウントするか、Azure File Sync を使用してオンプレミスの Azure ファイル共有をキャッシュするかの 2 つの方法でデプロイできます。デプロイに関する考慮事項は、選択したオプションによって異なります。

Azure ファイル共有の直接マウント: Azure Files からは Server Message Block (SMB) または Network File System (NFS) アクセスが提供されるため、Azure ファイル共有を、お使いの OS で利用できる標準の SMB または NFS クライアントを利用し、オンプレミスまたはクラウドでマウントできます。 Azure ファイル共有はサーバーレスであるため、運用環境でデプロイするシナリオでは、ファイルサーバーや NAS デバイスを管理する必要ありません。つまり、ソフトウェアの修正プログラムを適用したり、物理ディスクを交換したりする必要はありません。
Azure File Sync を使用したオンプレミスでの Azure ファイル共有のキャッシュ: Azure File Sync を使用すると、オンプレミスのファイルサーバーの柔軟性、パフォーマンス、互換性を維持しながら、Azure Files で組織のファイル共有を一元化できます。 Azure File Sync によって、オンプレミス (またはクラウド) の Windows Server が SMB Azure ファイル共有の高速キャッシュに変換されます。

この記事では主に、オンプレミスまたはクラウドクライアントによって直接マウントされる Azure ファイル共有をデプロイする場合の、デプロイに関する考慮事項について説明します。 Azure File Sync のデプロイを計画する場合は、「Azure File Sync のデプロイの計画」を参照してください。

使用可能なプロトコル

Azure Files には、Azure ファイル共有をマウントするための業界標準のファイルシステムプロトコルとして、サーバーメッセージブロック (SMB) プロトコルとネットワークファイルシステム (NFS) プロトコルの 2 つが用意されており、ワークロードに最適なプロトコルを選択できます。 Azure ファイル共有では、SMB と NFS の両方のプロトコルを同じファイル共有で使用することはできません。ただし、同じストレージアカウントに SMB と NFS の Azure ファイル共有を作成することはできます。現在、NFS 4.1 のみが、新しい FileStorage ストレージアカウントタイプ内でサポートされます (Premium ファイル共有のみ)。

SMB と NFS の両方のファイル共有に対し、Azure Files により、ストレージのニーズに合わせたスケールアップが可能で、数千ものクライアントによって同時にアクセスできる、エンタープライズレベルのファイル共有が提供されます。

機能	SMB	NFS
サポートされるプロトコルのバージョン	SMB 3.1.1、SMB 3.0、SMB 2.1	NFS 4.1
推奨される OS	Windows 10 バージョン 21H1 以降 Windows Server 2019 以降 Linux カーネルバージョン 5.3 以降	Linux カーネルバージョン 4.3 以降
使用できるレベル	Premium、トランザクション最適化、ホット、クール	Premium
課金モデル	プロビジョニング容量 (Premium ファイル共有) 従量課金制 (Standard ファイル共有)	プロビジョニング容量
Azure DNS ゾーンエンドポイント (プレビュー)	サポートされています	サポートされています
冗長性	LRS、ZRS、GRS、GZRS	LRS、ZRS
ファイルシステムセマンティクス	Win32	POSIX
認証	ID ベースの認証 (Kerberos)、共有キー認証 (NTLMv2)	ホストベースの認証
承認	Win32 スタイルのアクセス制御リスト (ACL)	UNIX 形式のアクセス許可
大文字小文字の区別	大文字小文字は区別されないが、保持される	大文字小文字は区別される
開いているファイルの削除または変更	ロックのみを使用する	はい
ファイル共有	Windows 共有モード	バイト範囲アドバイザリネットワークロックマネージャー
ハードリンクのサポート	サポートされていません	サポートされています
シンボリックリンクのサポート	サポートされていません	サポートされています
必要に応じてインターネットからアクセス可能	はい (SMB 3.0 以降のみ)	いいえ
FileREST のサポート	はい	サブセット: `FileService` に対する操作 `FileShares` に対する操作 `Directories` に対する操作 `Files` に対する操作
必須のバイト範囲ロック	サポートされています	サポートされていません
アドバイザリバイト範囲ロック	サポートされていません	サポートされています
拡張/名前付き属性	サポートされていません	サポートされていません
代替データストリーム	サポートされていません	該当なし
オブジェクト ID	サポートされていません	該当なし
再解析ポイント	サポートされていません	該当なし
スパースファイル	サポートされていません	該当なし
圧縮	サポートされていません	該当なし
名前付きパイプ	サポートされていません	該当なし
SMB ダイレクト	サポートされていません	該当なし
SMB ディレクトリリース	サポートされていません	該当なし
ボリュームシャドウコピー	サポートされていません	該当なし
短いファイル名 (8.3 の別名)	サポートされていません	該当なし
サーバーサービス	サポートされていません	該当なし
ファイルシステムトランザクション (TxF)	サポートされていません	該当なし

管理の概念

Azure ファイル共有は、ストレージの共有プールを表す最上位オブジェクトである "ストレージアカウント" にデプロイされます。このストレージのプールを使用すると、複数のファイル共有だけでなく、BLOB コンテナー、キュー、テーブルなどの他のストレージリソースもデプロイできます。ストレージアカウントにデプロイされているすべてのストレージリソースにより、そのストレージアカウントに適用される制限が共有されます。ストレージアカウントの現在の制限については、「Azure Files のスケーラビリティおよびパフォーマンスのターゲット」をご覧ください。

Azure Files のデプロイに使用するストレージアカウントには、主に次の 2 種類があります。

汎用バージョン 2 (GPv2) ストレージアカウント: GPv2 ストレージアカウントを使うと、Standard のハードディスクベース (HDD ベース) のハードウェアに、Azure ファイル共有をデプロイできます。 GPv2 ストレージアカウントでは、Azure ファイル共有を格納するだけでなく、BLOB コンテナー、キュー、テーブルなどの他のストレージリソースを格納することもできます。
FileStorage ストレージアカウント:FileStorage ストレージアカウントを使うと、Premium のソリッドステートディスクベース (SSD ベース) のハードウェアに、Azure ファイル共有をデプロイできます。 FileStorage アカウントは、Azure ファイル共有を格納するためにのみ使用できます。FileStorage アカウントでその他のストレージリソース (BLOB コンテナー、キュー、テーブルなど) をデプロイすることはできません。 SMB と NFS の両方のファイル共有をデプロイできるのは FileStorage アカウントだけです。

Azure portal、PowerShell、CLI では、他にもいくつかの種類のストレージアカウントを使用できます。 BlockBlobStorage と BlobStorage の 2 種類のストレージアカウントには、Azure ファイル共有を格納できません。他の 2 つのストレージアカウントの種類は、汎用バージョン 1 (GPv1) ストレージアカウントと従来のストレージアカウントであり、どちらも Azure ファイル共有を格納できます。 GPv1 と従来のストレージアカウントには Azure ファイル共有を格納できますが、Azure Files のほとんどの新機能は、GPv2 ストレージアカウントと FileStorage ストレージアカウントでのみ使用できます。そのため、新しいデプロイには GPv2 と FileStorage ストレージアカウントのみを使用し、GPv1 と従来のストレージアカウントが環境に既に存在する場合はアップグレードすることをお勧めします。

Azure ファイル共有をストレージアカウントにデプロイする場合は、次のことをお勧めします。

他の Azure ファイル共有を使用したストレージアカウントへの Azure ファイル共有のデプロイのみ。 GPv2 ストレージアカウントでは混在する目的のストレージアカウントを使用できますが、Azure ファイル共有や BLOB コンテナーなどのストレージリソースではストレージアカウントの制限が共有されるため、リソースを混在させると、後でパフォーマンスの問題のトラブルシューティングがより困難になる可能性があります。
Azure ファイル共有をデプロイする際には、ストレージアカウントの IOPS 制限に注意してください。理想的には、ファイル共有をストレージアカウントに 1:1 でマップします。ただし、組織と Azure の両方からのさまざまな制限と制限により、これが常に可能とは限りません。 1 つのストレージアカウントに 1 つのファイル共有のみをデプロイすることができない場合は、使用頻度が高い共有と低い共有を考慮し、最もアクティブなファイル共有が同じストレージアカウントに一緒にデプロイされないようにしてください。
GPv2 アカウントとファイルストレージアカウントを展開し、GPv1 とクラシックストレージアカウントを環境内で見つけた場合にのみアップグレードします。

ID

Azure ファイル共有にアクセスするには、ファイル共有のユーザーが認証され、共有へのアクセスが許可されている必要があります。これは、ファイル共有にアクセスするユーザーの ID に基づいて行われます。 Azure Files は、次の 4 つの主な ID プロバイダーと統合されています。

オンプレミス Active Directory Domain Services (AD DS、またはオンプレミス AD DS): Azure ストレージアカウントは、Windows Server ファイルサーバーや NAS デバイスと同様に、顧客所有の Active Directory Domain Services ドメインに参加させることができます。ドメインコントローラーは、Azure VM や、別のクラウドプロバイダーの VM としてもオンプレミスにデプロイできます。Azure Files は、ドメインコントローラーがホストされている場所に依存しません。ストレージアカウントがドメインに参加すると、エンドユーザーは、PC にサインインしたユーザーアカウントを使用してファイル共有をマウントできます。 AD ベースの認証では、Kerberos 認証プロトコルが使用されます。
Azure Active Directory Domain Services (Azure AD DS) :Azure AD DS では、Azure リソースに使用できる Microsoft が管理するドメインコントローラーが提供されます。ストレージアカウントを Azure AD DS にドメイン参加させることで、顧客所有の AD DS に参加させる場合と同様の利点が得られます。このデプロイオプションは、AD ベースのアクセス許可を必要とするアプリケーションのリフトアンドシフトシナリオに最も役立ちます。 Azure AD DS では AD ベースの認証が提供されるため、このオプションでも Kerberos 認証プロトコルが使用されます。
ハイブリッド ID 用の Azure Active Directory (Azure AD) Kerberos: Azure AD Kerberos を使用すると、Azure AD を使用して、クラウドに同期されるオンプレミス AD ID であるハイブリッドユーザー ID を認証できます。この構成では Azure AD を使用して、SMB プロトコルでファイル共有にアクセスするための Kerberos チケットを発行します。つまり、エンドユーザーは、ハイブリッド Azure AD 参加済みおよび Azure AD 参加済み VM からドメインコントローラーへの通信を必要とせずに、インターネット経由で Azure ファイル共有にアクセスできます。
Azure ストレージアカウントキー:Azure ファイル共有は、Azure ストレージアカウントキーを使用してマウントすることもできます。この方法でファイル共有をマウントするために、ストレージアカウント名がユーザー名として使用され、ストレージアカウントキーがパスワードとして使用されます。ストレージアカウントキーを使用して Azure ファイル共有をマウントすることは、マウントされたファイル共有に ACL があっても、共有上のすべてのファイルとフォルダーに対する完全なアクセス許可を持つため、事実上管理者の操作です。ストレージアカウントキーを使用して SMB 経由でマウントする場合は、NTLMv2 認証プロトコルが使用されます。

オンプレミスのファイルサーバーから移行するか、あるいは Windows ファイルサーバーや NAS アプライアンスと同様に動作させることが目的の Azure Files で新しいファイル共有を作成するお客様の場合は、ストレージアカウントを顧客所有の AD DS にドメイン参加させることをお勧めします。ストレージアカウントの顧客所有 AD DS へのドメイン参加の詳細については、「概要 - SMB を使用した Azure ファイル共有へのオンプレミスの Active Directory Domain Services 認証」を参照してください。

ストレージアカウントキーを使って Azure ファイル共有にアクセスする場合は、「ネットワーク」セクションの説明に従って、プライベートエンドポイントまたはサービスエンドポイントを使用することをお勧めします。

ネットワーク

Azure ファイル共有を直接マウントするには、多くの場合、次の理由から、ネットワーク構成についていくつかの検討が必要です。

SMB ファイル共有が通信に使用するポート 445 は、多くの組織やインターネットサービスプロバイダー (ISP) によって送信 (インターネット) トラフィックに対して頻繁にブロックされます。
NFS ファイル共有はネットワークレベルの認証に依存するため、制限されたネットワーク経由でのみアクセスできます。 NFS ファイル共有を使用するには、常に何らかのレベルのネットワーク構成が必要です。

ネットワークを構成するために、Azure Files はインターネットにアクセスできるパブリックエンドポイントを提供し、サービスエンドポイントなどの Azure ネットワーク機能との統合を提供します。これは、パブリックエンドポイントを指定された仮想ネットワークに制限し、プライベートエンドポイントを使用して、仮想ネットワーク IP アドレス空間内からストレージアカウントにプライベート IP アドレスを提供します。

実際的な観点からは、次のネットワーク構成を考慮する必要があります。

必要なプロトコルが SMB で、SMB 経由のすべてのアクセスが Azure のクライアントからのものである場合、特別なネットワーク構成は必要ありません。
必要なプロトコルが SMB で、アクセスがオンプレミスのクライアントからの場合、オンプレミスから Azure ネットワークへの VPN または ExpressRoute 接続が必要であり、Azure Files はプライベートエンドポイントを使用して内部ネットワークに公開されます。
必要なプロトコルが NFS の場合は、サービスエンドポイントまたはプライベートエンドポイントのいずれかを使用して、ネットワークを指定された仮想ネットワークに制限できます。

Azure Files のネットワークを構成する方法の詳細については、「Azure Files のネットワークに関する考慮事項」を参照してください。

パブリックエンドポイントまたはプライベートエンドポイントとの VPN/ExpressRoute 接続を使用してファイル共有に直接接続することに加えて、SMB には追加のクライアントアクセス戦略 (SMB over QUIC) が用意されています。 SMB over QUIC は、QUIC トランスポートプロトコルを介した SMB アクセス用にゼロ構成の「SMB VPN」を提供します。 Azure Files は SMB over QUIC を直接サポートしていませんが、Azure File Sync を使用して、Windows Server 2022 Azure Edition VM 上に Azure ファイル共有の軽量キャッシュを作成できます。このオプションの詳細については、「Azure File Syncを使用した SMB over QUIC」に関するページを参照してください。

暗号化

Azure Files では、2 種類の暗号化がサポートされています。転送中の暗号化は、Azure ファイル共有のマウントとアクセス時に使用される暗号化に関連しており、保存時の暗号化は、データがディスクに格納されるときの暗号化の方法に関連します。

転送中の暗号化

重要

このセクションでは、SMB 共有の転送中の暗号化について詳しく取り上げます。 NFS 共有による転送中の暗号化の詳細については、「セキュリティとネットワーク」を参照してください。

既定では、すべての Azure ストレージアカウントで転送中の暗号化が有効になっています。つまり、SMB 経由でファイル共有をマウントするか、または FileREST プロトコル (Azure portal、PowerShell/CLI、Azure SDK など) 経由でファイル共有にアクセスすると、Azure Files では、暗号化または HTTPS が設定されている SMB 3.x 以上で作成された接続のみが許可されます。 SMB 3.x をサポートしていないクライアント、または SMB 3.x をサポートしているが、SMB 暗号化をサポートしていないクライアントは、転送中の暗号化が有効になっている場合は Azure ファイル共有をマウントできません。暗号化付き SMB 3.x がサポートされているオペレーティングシステムの詳細については、Windows、macOS、および Linux に関する詳細なドキュメントを参照してください。 PowerShell、CLI、および SDK の現在のバージョンはすべて HTTPS をサポートしています。

Azure ストレージアカウントでの転送中の暗号化を無効にすることができます。暗号化が無効になっている場合、Azure Files では、SMB 2.1、暗号化なしの SMB 3.x、および HTTP 経由の暗号化されていない FileREST API 呼び出しも許可されます。転送中の暗号化を無効にする主な理由は、古いオペレーティングシステム (Windows Server 2008 R2 や古い Linux ディストリビューションなど) 上で実行する必要のあるレガシアプリケーションをサポートするためです。 Azure Files では、Azure ファイル共有と同じ Azure リージョン内の SMB 2.1 接続のみが許可されます。Azure ファイル共有の Azure リージョンの外部 (オンプレミスまたは異なる Azure リージョン内など) の SMB 2.1 クライアントは、ファイル共有にアクセスできません。

転送中のデータの暗号化が有効になっていることを確認することを強くお勧めします。

転送中の暗号化の詳細については、「Azure Storage で安全な転送が必要」を参照してください。

保存時の暗号化

Azure Files に格納されるすべてのデータは、Azure Storage Service Encryption (SSE) を使用して保存時に暗号化されます。 Storage Service Encryption は Windows の BitLocker と同様に機能し、データはファイルシステムレベルで暗号化されます。データは Azure ファイル共有のファイルシステムで暗号化されるため、ディスクにエンコードされた場合、Azure ファイル共有を読み書きするために、基になるクライアント上のキーにアクセスできる必要はありません。保存時の暗号化は、SMB と NFS の両方のプロトコルに適用されます。

規定では、Azure Files に格納されるデータは、Microsoft マネージドキーで暗号化されます。 Microsoft マネージドキーを使用すると、Microsoft によってデータの暗号化および暗号化解除のためのキーが保持され、定期的にローテーションが行われます。また、お客様が自分でキーを管理することもでき、その場合はお客様がローテーションプロセスを制御できます。お客様が管理するキーによるファイル共有の暗号化を選択した場合、クライアントからの読み取りと書き込みの要求を処理するため、Azure Files にはキーへのアクセスが承認されます。お客様管理のキーを使用すると、お客様はこの承認をいつでも取り消すことができますが、これは、SMB または FileREST API を使用して Azure ファイル共有にアクセスできなくなることを意味します。

Azure Files では、Azure Blob Storage などの他の Azure ストレージサービスと同じ暗号化スキームが使用されます。 Azure Storage Service Encryption (SSE) の詳細については、「保存データに対する Azure Storage 暗号化」をご覧ください。

データ保護

Azure Files には、データがバックアップされて回復可能であり、セキュリティの脅威から保護されることを保証するための、多層化された方法が用意されています。

論理的な削除

論理的な削除は、ファイル共有が誤って削除された場合に回復できるようにする、SMB ファイル共有のストレージアカウントレベルの設定です。ファイル共有が削除された場合、完全に消去されるのではなく、論理的に削除された状態に移行します。論理的に削除されたデータが完全に削除され、復旧できなくなるまでの時間を構成することができます。この保有期間中はいつでも共有の削除を取り消すことができます。

ほとんどの SMB ファイル共有では、論理的な削除を有効にすることをお勧めします。共有の削除が一般的かつ望まれているワークフローでは、保持期間を短く設定するか、または論理的な削除をまったく有効にしないように決定できます。論理的な削除は、ストレージアカウントで有効になっている場合であっても、NFS 共有では機能しません。

論理的な削除の詳細については、データの誤削除の防止に関する記事を参照してください。

バックアップ

共有スナップショットを利用して、Azure ファイル共有をバックアップすることができます。これは、特定の時点の共有の読み取り専用のコピーです。スナップショットは増分であり、以前のスナップショット以降に変更されたデータだけが含まれます。ファイル共有ごとに最大 200 のスナップショットを保持し、最大 10 年間保存できます。これらのスナップショットを取得するには、Azure portal、PowerShell、またはコマンドラインインターフェイス (CLI) を使用して手動で行うか、または Azure Backup を使用することができます。スナップショットはファイル共有内に格納されます。つまり、ファイル共有を削除すると、スナップショットも削除されます。スナップショットバックアップを誤削除から保護するために、共有に対して論理的な削除が有効になっていることを確認します。

Azure ファイル共有の Azure Backup によって、スナップショットのスケジュール設定と保持期間が処理されます。三世代 (GFS: grandfather-father-son) 機能は、日次、週次、月次、年次のスナップショットを取得できることを意味し、それぞれに個別の保持期間が設けられています。また、Azure Backup によって論理的な削除の有効化が調整され、その中のいずれかのファイル共有がバックアップに構成されると、すぐにストレージアカウント上で削除のロックが行われます。最後に、顧客が自身のバックアップ資産の統合されたビューを利用できるように、Azure Backup には、特定の主な監視機能およびアラート機能が用意されています。

Azure portal 上で、Azure Backup を使用して、項目レベルおよび共有レベルの両方の復元を実行できます。必要な作業は、復元ポイント (特定のスナップショット)、特定のファイルまたはディレクトリ (該当する場合)、復元先の場所 (元の場所または別の場所) を選択することだけです。バックアップサービスによって、スナップショットデータのコピーが処理され、ポータル上に復元の進行状況が表示されます。

Microsoft Defender for Storage を使用して Azure Files を保護する

Microsoft Defender for Storage は、お使いのストレージアカウントに対する潜在的な脅威を検出する、Azure ネイティブのセキュリティインテリジェンスレイヤーです。これは、Azure Files によって生成されたデータプレーンとコントロールプレーンテレメトリを分析することで、包括的なセキュリティを提供します。 Microsoft 脅威インテリジェンスを利用した高度な脅威検出機能を使用し、検出された脅威を軽減し、将来の攻撃を防ぐ手順など、コンテキストに応じたセキュリティアラートを提供します。

Defender for Storage は、Azure Files によって生成されるテレメトリストリームを継続的に分析します。悪意のある可能性のあるアクティビティが検出されると、セキュリティアラートが生成されます。これらのアラートは、Microsoft Defender for Cloud に、疑わしいアクティビティの詳細と、調査手順、修復アクション、セキュリティに関する推奨事項と共に表示されます。

Defender for Storage は、完全なファイルハッシュ (REST API でのみサポート) に基づいて、ランサムウェア、ウイルス、スパイウェア、ストレージアカウントにアップロードされたその他のマルウェアなどの既知のマルウェアを検出します。これは、マルウェアが組織に入り、さらにユーザーやリソースに拡散されるのを防ぐのに役立ちます。「ハッシュ評価分析の制限事項」も参照してください。

Defender for Storage はストレージアカウントのデータにはアクセスしないので、そのパフォーマンスには影響しません。 Microsoft Defender for Storage は、サブスクリプションレベル (推奨) またはリソースレベルで有効にできます。

ストレージ層

Azure Files では、Premium、トランザクション最適化、ホット、クールの 4 つの異なるストレージのサービスレベルが提供されており、お客様のシナリオのパフォーマンスと価格の要件に合わせて共有を調整できます。

Premium:Premium ファイル共有は、ソリッドステートドライブ (SSD) によってサポートされており、IO 集中型ワークロードで一貫した優れたパフォーマンスと待機時間 (ほとんどの IO 操作で 1 桁のミリ秒以内の低待機時間) を提供します。 Premium ファイル共有は、データベース、Web サイトのホスティング、開発環境など、幅広い種類のワークロードに適しています。 Premium ファイル共有は、サーバーメッセージブロック (SMB) プロトコルとネットワークファイルシステム (NFS) プロトコルの両方で使用できます。
トランザクション最適化:トランザクション最適化ファイル共有は、Premium ファイル共有が提供する待機時間を必要としない、トランザクション負荷の高いワークロードを可能にします。トランザクション最適化ファイル共有は、ハードディスクドライブ (HDD) によってサポートされている標準ストレージハードウェアで提供されます。トランザクション最適化は、従来は "Standard" と呼ばれていましたが、これはサービスレベル自体ではなく、ストレージメディアの種類を指しています (ホットおよびクールも、標準ストレージハードウェア上にあるため、"Standard" サービスレベルです)。
Hot:ホットファイル共有は、チーム共有などの汎用ファイル共有シナリオに最適化されたストレージを提供します。ホットファイル共有は、HDD によってサポートされている標準ストレージハードウェアで提供されます。
Cool:クールファイル共有は、オンラインアーカイブストレージのシナリオ向けに最適化された、コスト効率に優れたストレージを提供します。クールファイル共有は、HDD によってサポートされている標準ストレージハードウェアで提供されます。

Premium ファイル共有は、FileStorage ストレージアカウントの種類でデプロイされ、プロビジョニング済み課金モデルでのみ利用できます。 Premium ファイル共有のプロビジョニング済み課金モデルについて詳しくは、「Premium ファイル共有のプロビジョニングについて」をご覧ください。トランザクション最適化、ホット、クールファイル共有などの Standard ファイル共有は、汎用バージョン 2 (GPv2) ストレージアカウントの種類でデプロイされ、従量課金制で利用できます。

ワークロードのストレージ層を選択する場合は、パフォーマンスと使用量の要件を考慮してください。ワークロードに 1 桁の待機時間が必要な場合、またはオンプレミスの SSD ストレージメディアを使用している場合は、おそらく Premium 層が最適です。チーム共有が Azure からオンプレミスにマウントされている場合または Azure File Sync を使用してオンプレミスにキャッシュされている場合など、低待機時間が特に問題ではない場合は、コストの観点から、標準ストレージの方が適している可能性があります。

ファイル共有をストレージアカウントで作成すると、異なるストレージアカウントの種類に固有の層に移動させることはできません。たとえば、トランザクション最適化ファイル共有を Premium 層に移動する場合、FileStorage ストレージアカウントで新しいファイル共有を作成し、データを元の共有から FileStorage アカウント内の新しいファイル共有にコピーする必要があります。 AzCopy を使用して Azure ファイル共有間でデータをコピーすることをお勧めしますが、Windows の robocopy または macOS と Linux 用の rsync などのツールを使用することもできます。

詳細については、「Azure Files の課金について」をご覧ください。

制限事項

100 TiB の容量を持つ Standard ファイル共有には、いくつかの制限事項があります。

現在サポートされているのは、ローカル冗長ストレージ (LRS) アカウントとゾーン冗長ストレージ (ZRS) アカウントだけです。
大きなファイル共有を有効にした後は、ストレージアカウントを geo 冗長ストレージ (GRS) アカウントや geo ゾーン冗長ストレージ (GZRS) アカウントに変換することはできません。
いったん大きなファイル共有を有効にすると、無効にすることはできなくなります。

冗長性

Azure ファイル共有内のデータを損失や破損から保護するため、すべての Azure ファイル共有では、各ファイルが書き込まれるときに複数のコピーが格納されます。ワークロードの要件に応じて、冗長性のレベルをさらに高めることができます。現在、Azure Files では次のデータ冗長性オプションがサポートされています。

ローカル冗長ストレージ (LRS) : LRS では、すべてのファイルが Azure ストレージクラスター内に 3 回保存されます。これにより、不良ディスクドライブなどのハードウェア障害によるデータの損失を防ぐことができます。ただし、データセンター内で火災や洪水などの災害が発生した場合、LRS を使用しているストレージアカウントのすべてのレプリカが失われたり、回復不能になる可能性があります。
ゾーン冗長ストレージ (ZRS): ZRS を使用すると、各ファイルのコピーが 3 つ保存されますが、これらのコピーは物理的に異なる Azure "可用性ゾーン" にある 3 つの異なるストレージクラスターに分離されます。可用性ゾーンは、Azure リージョン内の一意の物理的な場所です。それぞれのゾーンは、独立した電源、冷却手段、ネットワークを備えた 1 つまたは複数のデータセンターで構成されています。 3 つの可用性ゾーンすべてのストレージクラスターに書き込まれるまで、ストレージへの書き込みは受け入れられません。
Geo 冗長ストレージ (GRS): GRS の場合、プライマリリージョンとセカンダリリージョンの 2 つのリージョンがあります。ファイルは、プライマリリージョンの Azure ストレージクラスター内に 3 回保存されます。書き込みは、Microsoft によって定義されたセカンダリリージョンに非同期的にレプリケートされます。 GRS では、データの 6 つのコピーが 2 つの Azure リージョン間で分散して作成されます。自然災害や他の同様の事象で Azure リージョンが完全に失われた場合など、重大な障害が発生した場合は、Microsoft によってフェールオーバーが実行され、セカンダリが実質的にプライマリとなってすべての操作を提供します。プライマリリージョンとセカンダリリージョンの間のレプリケーションは非同期であるため、重大な障害が発生した場合、セカンダリリージョンにまだレプリケートされていないデータは失われます。 geo 冗長ストレージアカウントのフェールオーバーは、手動で実行することもできます。
Geo ゾーン冗長ストレージ (GZRS) : GZRSは、あたかもZRSのように、geo 冗長を持っていると考えることができます。 GZRS を使用すると、ファイルはプライマリリージョンの 3 つの異なるストレージクラスターに 3 回保存されます。その後、すべての書き込みが Microsoft で定義されたセカンダリリージョンに非同期的にレプリケートされます。 GZRS のフェールオーバープロセスは、GRS と同じように動作します。

最大 5 TiB の Standard Azure ファイル共有では、4 種類の冗長性すべてがサポートされます。 5 TiB を超える Standard ファイル共有では、LRS と ZRS のみがサポートされます。 Premium Azure ファイル共有は、LRS と ZRS のみをサポートしています。

汎用バージョン 2 (GPv2) のストレージアカウントでは、Azure Files ではサポートされていない 2 つの追加の冗長オプションが提供されています。読み取りアクセス geo 冗長ストレージ (RA-GRS と呼ばれることもあります) と、読み取りアクセス geo ゾーン冗長ストレージ (RA-GZRS と呼ばれることもあります) です。これらのオプションセットを使用して、ストレージアカウントで Azure ファイル共有をプロビジョニングできますが、Azure Files ではセカンダリリージョンからの読み取りはサポートされていません。読み取りアクセス geo 冗長ストレージアカウントまたは読み取りアクセス geo ゾーン冗長ストレージアカウントにデプロイされた Azure ファイル共有は、それぞれ、geo 冗長ストレージまたは geo ゾーン冗長ストレージとして課金されます。

Standard ZRS の可用性

標準の汎用 v2 ストレージアカウントの ZRS は、Azure リージョンのサブセットで使用できます。

(アフリカ) 南アフリカ北部
(アジア太平洋) オーストラリア東部
(アジア太平洋) インド中部
(アジア太平洋) 東アジア
(アジア太平洋) 東日本
(アジア太平洋) 韓国中部
(アジア太平洋) 東南アジア
(ヨーロッパ) フランス中部
(ヨーロッパ) ドイツ中西部
(ヨーロッパ) 北ヨーロッパ
(ヨーロッパ) ノルウェー東部
(ヨーロッパ) スウェーデン中部
(ヨーロッパ) スイス北部
(ヨーロッパ) 英国南部
(ヨーロッパ) 西ヨーロッパ
(中東) カタール中部
(中東) アラブ首長国連邦北部
(北米) カナダ中部
(北米) 米国中部
(北米) 米国東部
(北米)米国東部 2
(北米) 米国中南部
(北米) US Gov バージニア
(北米)米国西部 2
(北米) 米国西部 3
(南アメリカ) ブラジル南部

Premium ZRS の可用性

Premium ファイル共有の ZRS は、Azure リージョンのサブセットで使用できます。

(アジア太平洋) オーストラリア東部
(アジア太平洋) 東日本
(アジア太平洋) 東南アジア
(アジア太平洋) 韓国中部
(ヨーロッパ) フランス中部
(ヨーロッパ) 北ヨーロッパ
(ヨーロッパ) 西ヨーロッパ
(ヨーロッパ) 英国南部
(中東) カタール中部
(北米) 米国東部
(北米)米国東部 2
(北米)米国西部 2
(北米) 米国中南部
(南アメリカ) ブラジル南部

Standard GZRS の可用性

GZRS は、Azure リージョンのサブセットで使用できます。

(アフリカ) 南アフリカ北部
(アジア太平洋) オーストラリア東部
(アジア太平洋) 東アジア
(アジア太平洋) 東日本
(アジア太平洋) 韓国中部
(アジア太平洋) 東南アジア
(アジア太平洋) インド中部
(ヨーロッパ) フランス中部
(ヨーロッパ) ドイツ中西部
(ヨーロッパ) 北ヨーロッパ
(ヨーロッパ) ノルウェー東部
(ヨーロッパ) スウェーデン中部
(ヨーロッパ) スイス北部
(ヨーロッパ) 英国南部
(ヨーロッパ) 西ヨーロッパ
(北米) カナダ中部
(北米) 米国中部
(北米) 米国東部
(北米)米国東部 2
(北米) 米国中南部
(北米)米国西部 2
(北米) 米国西部 3
(北米) US Gov バージニア
(南アメリカ) ブラジル南部

移行

多くの場合、組織に対して新しいファイル共有を確立するのではなく、既存のファイル共有をオンプレミスのファイルサーバーまたは NAS デバイスから Azure Files に移行します。移行を成功させるには、シナリオに適した移行戦略とツールを選択することが重要です。

移行の概要に関する記事に、基本についての説明と、シナリオに適した移行ガイドを紹介する表が含まれています。