Azure Files のデプロイの計画
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 |
|
Linux カーネル バージョン 4.3 以降 |
使用できるレベル | Premium、トランザクション最適化、ホット、クール | Premium |
課金モデル | プロビジョニング容量 | |
Azure DNS ゾーン エンドポイント (プレビュー) | サポートされています | サポートされています |
冗長性 | LRS、ZRS、GRS、GZRS | LRS、ZRS |
ファイル システム セマンティクス | Win32 | POSIX |
認証 | ID ベースの認証 (Kerberos)、共有キー認証 (NTLMv2) | ホストベースの認証 |
承認 | Win32 スタイルのアクセス制御リスト (ACL) | UNIX 形式のアクセス許可 |
大文字小文字の区別 | 大文字小文字は区別されないが、保持される | 大文字小文字は区別される |
開いているファイルの削除または変更 | ロックのみを使用する | はい |
ファイル共有 | Windows 共有モード | バイト範囲アドバイザリ ネットワーク ロック マネージャー |
ハード リンクのサポート | サポートされていません | サポートされています |
シンボリック リンクのサポート | サポートされていません | サポートされています |
必要に応じてインターネットからアクセス可能 | はい (SMB 3.0 以降のみ) | いいえ |
FileREST のサポート | はい | サブセット: |
必須のバイト範囲ロック | サポートされています | サポートされていません |
アドバイザリ バイト範囲ロック | サポートされていません | サポートされています |
拡張/名前付き属性 | サポートされていません | サポートされていません |
代替データ ストリーム | サポートされていません | 該当なし |
オブジェクト 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 に移行します。 移行を成功させるには、シナリオに適した移行戦略とツールを選択することが重要です。
移行の概要に関する記事に、基本についての説明と、シナリオに適した移行ガイドを紹介する表が含まれています。