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
  • Windows 11、バージョン 21H2 以降
  • Windows 10 バージョン 21H1 以降
  • Windows Server 2019 以降
  • Linux カーネル バージョン 5.3 以降
 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 アカウントと FileStorage アカウントのみをデプロイし、GPv1 とクラシック ストレージ アカウントを環境内で見つけた場合はアップグレードします。

ID

Azure ファイル共有にアクセスするには、ファイル共有のユーザーが認証され、共有へのアクセスが許可されている必要があります。 これは、ファイル共有にアクセスするユーザーの ID に基づいて行われます。 Azure Files では、次の認証方法がサポートされています。

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

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

ネットワーク

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

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

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

これは、次のネットワーク構成を考慮する必要があることを意味します。

  • 必要なプロトコルが SMB で、SMB 経由のすべてのアクセスが Azure のクライアントからのものである場合、特別なネットワーク構成は必要ありません。
  • 必要なプロトコルが SMB で、アクセスがオンプレミスのクライアントからの場合、オンプレミスから Azure ネットワークへの VPN または ExpressRoute 接続が必要であり、Azure Files はプライベート エンドポイントを使用して内部ネットワークに公開されます。
  • 必要なプロトコルが NFS の場合は、サービス エンドポイントまたはプライベート エンドポイントのいずれかを使用して、ネットワークを指定された仮想ネットワークに制限できます。 静的 IP アドレスが必要な場合や、ワークロードに高可用性が必要な場合は、プライベート エンドポイントを使用します。 サービス エンドポイントを使用した場合、ゾーン障害などのまれなイベントによって、ストレージ アカウントの基になる IP アドレスが変更される可能性があります。 データはファイル共有で引き続き使用できますが、クライアントに共有の再マウントが必要になります。

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 には、データがバックアップされて回復可能であり、セキュリティの脅威から保護されることを保証するための、多層化された方法が用意されています。 「Azure Files データ保護の概要」を参照してください。

論理的な削除

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

2021 年 1 月以降、新しいストレージ アカウントでは論理的な削除が既定で有効になっており、ほとんどの 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 では、SSD と HDD の 2 つの異なるストレージのメディア層が提供されており、お客様のシナリオのパフォーマンスと価格の要件に合わせて共有を調整できます。

  • SSD (Premium): Premium ファイル共有は、ソリッド ステート ドライブ (SSD) を使用し、IO 集中型ワークロードで一貫した優れたパフォーマンスと待機時間 (ほとんどの IO 操作で 1 桁のミリ秒以内の低待機時間) を提供します。 Premium ファイル共有は、データベース、Web サイトのホスティング、開発環境など、幅広い種類のワークロードに適しています。 Premium ファイル共有は、サーバー メッセージ ブロック (SMB) プロトコルとネットワーク ファイル システム (NFS) プロトコルの両方で使用できます。 Premium ファイル共有は、FileStorage ストレージ アカウントの種類でデプロイされ、プロビジョニング済み課金モデルでのみ利用できます。 Premium ファイル共有のプロビジョニング済み課金モデルについて詳しくは、「Premium ファイル共有のプロビジョニングについて」をご覧ください。 Premium ファイル共有は、標準のファイル共有よりも高い可用性の SLA を提供します (「Azure Files Premium レベル」を参照)。

  • HDD (Standard): Standard ファイル共有はハード ディスク ドライブ (HDD) を使用し、汎用ファイル共有のためのコスト効率の高いストレージ オプションを提供します。 Standard ファイル共有は、汎用バージョン 2 (GPv2) ストレージ アカウントの種類でデプロイされます。 SLA の詳細については、Azure のサービス レベル アグリーメントに関するページを参照してください (「ストレージ アカウント」を参照)。 Standard ファイル共有では、使用量ベースの価格を提供する従量課金制モデルが使用されます。 ファイル共有の "アクセス層" を使用すると、次のように、IOPS コストに対してストレージ コストを調整して、合計請求額を最適化できます。

    • トランザクション最適化ファイル共有は、Premium ファイル共有が提供する低待機時間を必要としないトランザクション負荷の高いワークロードに対して、最もコストが低いトランザクション価格を提供します。 Azure Files にデータを移行する際に推奨されます。
    • ホット ファイル共有は、ストレージとトランザクションのバランスの取れた価格を、その両方を効果的に利用するワークロードに対して提供します。
    • クール ファイル共有は、ストレージ集中型ワークロードに対して最もコスト効率の高いストレージ価格を提供します。

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

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

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

制限事項

現在、大きいファイルの共有 (最大容量 100 TiB) が有効な標準ファイル共有には、特定の制限があります。

  • ローカル冗長ストレージ (LRS) とゾーン冗長ストレージ (ZRS) アカウントのみがサポートされます。
  • ストレージ アカウントで大きいファイルの共有を有効にすると、geo 冗長ストレージ (GRS) または geo ゾーン冗長ストレージ (GZRS) を使用するためにストレージ アカウントを変換することはできません。
  • いったん大きいファイルの共有を有効にすると、無効にすることはできません。

標準の SMB Azure ファイル共有で GRS または GZRS を使用する場合は、「大きいファイルの共有での Azure Files geo 冗長性プレビュー」をご覧ください。

冗長性

Azure ファイル共有内のデータを損失や破損から保護するため、Azure Files では、各ファイルが書き込まれるときに複数のコピーが格納されます。 要件に応じて、さまざまなレベルの冗長性を選択できます。 現在、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) のストレージ アカウントでは、これ以外に読み取りアクセス geo 冗長ストレージ (RA-GRS) と読み取りアクセス geo ゾーン冗長ストレージ (RA-GZRS) という、Azure Files がサポートしていない 2 つの冗長性オプションが用意されています。 これらのオプション セットを使用して、ストレージ アカウントで Azure ファイル共有をプロビジョニングできますが、Azure Files ではセカンダリ リージョンからの読み取りはサポートされていません。 RA-GRS または RA-GZRS ストレージ アカウントにデプロイされた Azure ファイル共有は、それぞれ GRS または GZRS として課金されます。

冗長性の詳細については、Azure Files のデータ冗長性に関する記事を参照してください。

Standard ZRS の可用性

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

Premium ZRS の可用性

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

Standard GZRS の可用性

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

ディザスター リカバリーとフェールオーバー

計画外のリージョン サービスの停止が発生した場合に備えて、Azure ファイル共有のディザスター リカバリー (DR) 計画を立てる必要があります。 DR とストレージ アカウントのフェールオーバーに関連する概念とプロセスを理解するには、「Azure Files のディザスター リカバリーとフェールオーバー」を参照してください。

移行

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

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

次のステップ