Azure Filesは、サーバーレス Azure ファイル共有を直接マウントするか、Azure File Syncを使用してオンプレミスでファイル共有をキャッシュする方法の 2 つの方法で展開できます。デプロイに関する考慮事項は、選択したオプションによって異なります。
Azure ファイル共有の直接マウント: Azure Filesはサーバー メッセージ ブロック (SMB) アクセスまたはネットワーク ファイル システム (NFS) アクセスを提供するため、OS で使用可能な標準の SMB または NFS クライアントを使用して、オンプレミスまたはクラウドAzureファイル共有をマウントできます。 Azureファイル共有はサーバーレスであるため、運用環境のシナリオに展開する場合、ファイル サーバーまたは NAS デバイスを管理する必要はありません。 このアーキテクチャは、ソフトウェアパッチを適用したり、物理ディスクをスワップアウトしたりする必要がないことを意味します。 クラシック ファイル共有 (SMB と NFS) またはMicrosoft Azureを選択できます。管理モデルとしての FileShares (NFS のみ)。
オンプレミスにAzureファイル共有をキャッシュするAzure File Sync (SMB のみ): Azure File Sync を使用すると、オンプレミス ファイル サーバーの柔軟性、パフォーマンス、互換性を維持しつつ、Azure Filesで組織のファイル共有を一元化できます。 Azure File Syncは、オンプレミス (またはクラウド) Windows Serverを SMB Azure ファイル共有のクイック キャッシュに変換します。
この記事では、主に、オンプレミスまたはクラウド クライアントによって直接マウントされるAzureファイル共有をデプロイする場合のデプロイに関する考慮事項について説明します。 Azure File Syncを使用する予定がある場合は、「Azure File Syncデプロイメント計画」をご覧ください。
管理の概念
Azureでは、resource は、Azureサブスクリプションとリソース グループ内で作成および構成する管理可能な項目です。 リソース プロバイダーは、特定の 種類のリソースを提供する管理サービスです。 多くのリソースを使用してワークロードをAzureにデプロイすることもできますが、Azure Filesは次の 2 つの重要なリソースを中心にしています。
Storage アカウント。
Microsoft.Storageリソース プロバイダーによって提供されます。 ストレージ アカウントは最上位のリソースであり、ストレージ、IOPS、スループットの共有プールを表し、ストレージ アカウントの種類に応じて、クラシック ファイル共有やその他のストレージ リソースをデプロイできます。 ストレージ アカウントにデプロイするすべてのストレージ リソースは、そのストレージ アカウントに適用される制限を共有します。 クラシック ファイル共有では、SMB と NFS の両方のファイル共有プロトコルがサポートされます。File shares。
Microsoft.FileSharesリソース プロバイダーによって提供されます。 ファイル共有は、ストレージ アカウントの必要性を排除することで、Azure Filesのデプロイを簡略化する新しい最上位レベルのリソースです。 従来のファイル共有はストレージアカウントにデプロイする必要がありますが、ファイルシェアはストレージアカウント自体や仮想マシン、ディスク、仮想ネットワークなどの他のAzureリソースに直接デプロイします。 現在、Microsoft.FileSharesでは NFS ファイル共有プロトコルのみがサポートされています。 SMB が必要な場合は、クラシック ファイル共有を選択します。
このビデオでは、ストレージ アカウントとファイル共有管理モデルの違いの包括的な概要について説明します。
クラシック ファイル共有 (Microsoft。ストレージ)
従来のファイル共有(ストレージ アカウントにデプロイされたファイル共有)は、Azure Filesのファイル共有をデプロイする従来の方法です。 SMB と NFS、SSD と HDD のメディア層、すべての冗長性の種類、すべてのリージョンでの可用性など、Azure Filesがサポートするすべての主要な機能をサポートします。 クラシック ファイル共有では、さまざまなAzure Files機能がサポートされますが、重要な制限事項があります。
容量計画: クラシック ファイル共有と、同じストレージ アカウント内に存在する BLOB コンテナーなどの子オブジェクトは、ストレージ、IOPS、スループットの共通プールを共有します。 このアーキテクチャは、ストレージ アカウントに複数のクラシック ファイル共有を配置するときに、容量のボトルネックを回避するために慎重に計画する必要があります。 1 つのクラシック ファイル共有の増加によって他のファイル共有が混雑する可能性があるため、ストレージ アカウントに配置された各クラシック ファイル共有の現在と将来の両方のニーズを考慮してください。
共有設定: ストレージ アカウント レベルで、ネットワークやセキュリティ規則など、多くの重要な設定を適用します。 そのため、クラシック ファイル共有を同じストレージ アカウントに配置する方法を慎重に検討する必要があります。 ストレージ アカウントを信頼境界と見なし、同じセキュリティ設定で問題ない場合は、クラシック ファイル共有のみを同じストレージ アカウントに配置します。
スケーリングの複雑さ: 大規模なAzure Filesデプロイでは、
Microsoft.Storageリソース プロバイダーからのストレージ アカウントの制約により、多くのAzure サブスクリプションを管理する必要があります。 詳細については、「ストレージ アカウントの制限」を参照してください。
クラシック ファイル共有のデプロイでは、次の 2 種類のストレージ アカウントが使用されます。
プロビジョニングされたストレージ アカウント:
FileStorageストレージ アカウントの種類は、プロビジョニングされたストレージ アカウントを識別します。 プロビジョニングされたストレージ アカウントを使用して、プロビジョニングされたクラシック ファイル共有を SSD または HDD ベースのハードウェアにデプロイできます。 プロビジョニングされたストレージ アカウントのみを使用して、クラシック ファイル共有を格納できます。 BLOB コンテナー、キュー、テーブルなどの他のストレージ リソースには使用できません。 すべての新しいクラシック ファイル共有のデプロイには、プロビジョニングされたストレージ アカウントを使用します。従量課金制ストレージ アカウント:
StorageV2ストレージ アカウントの種類は、従量課金制ストレージ アカウントを識別します。 従量課金制ストレージ アカウントを使用して、HDD ベースのハードウェアに従量課金制のファイル共有をデプロイできます。 従量課金制ストレージ アカウントを使用して、クラシック ファイル共有や、BLOB コンテナー、キュー、テーブルなどの他のストレージ リソースを格納できます。
詳細については、「クラシック ファイル共有を作成する」を参照してください。
ファイル共有 (Microsoft。FileShares)
Microsoft.FileShares リソース プロバイダーは、ファイル共有を新しい最上位レベルのAzure リソースとして提供します。 これらのファイル共有は、クラシック ファイル共有よりも次の利点を提供します。
管理の簡素化: Azure ポータルまたは管理 API を使用して、ファイル共有を最上位レベルのリソースとして直接作成します。 この方法では、ストレージ アカウントを管理するための要件が削除され、デプロイ エクスペリエンスが合理化されます。
独立した容量とパフォーマンス: 各ファイル共有には、専用のストレージ、IOPS、スループットがあります。 この設計により、ストレージ アカウントの限られたリソースに対して容量を計画する必要がなくなります。また、ワークロードの需要の増加に合わせてファイル共有を自由に拡張できます。
詳細な構成: ファイル共有レベルでネットワークとセキュリティの設定を適用し、アクセス境界と分離を正確に制御できるようにします。 この構成により、特定のアプリ、チーム、または環境にセキュリティ ポリシーを簡単に適用できます。
予測可能で柔軟な課金: ファイル共有では、プロビジョニングされた v2 課金モデルが使用されます。これにより、共有ごとにストレージ、IOPS、スループットを個別にプロビジョニングできます。 Azure では最上位レベルの Azure リソースごとに課金されるため、ファイル共有を使用しているプロジェクト、チーム、または顧客にコストを配賦する目的で、各ファイル共有のコストを簡単に追跡できます。
スケールとパフォーマンスの向上: ファイル共有では、クラシック ファイル共有よりも制限は高く、デプロイ時間は低くなるようサポートされます。 詳細については、「Azure Filesスケーラビリティとパフォーマンスのターゲットを参照してください。
リージョン別の提供状況
現在、Microsoft.FileShares を使用して、次のリージョンでファイル共有を作成できます。 Microsoftを使用したファイル共有に対するプライベート エンドポイントのサポート。FileShares は、すべてのAzureパブリック クラウド リージョンで使用できます。
- オーストラリア中部
- オーストラリア東部
- オーストラリア南東部
- ブラジル南部
- ブラジル南東部
- カナダ中部
- カナダ東部
- インド中部
- 東アジア
- 米国東部
- フランス中部
- フランス南部
- ドイツ北部
- ドイツ中西部
- イスラエル中部
- イタリア北部
- 東日本
- 西日本
- JIOインディアセントラル
- JIO インド西部
- 韓国中部
- 韓国南部
- 米国中北部
- 北ヨーロッパ
- ノルウェー東部
- ノルウェー西部
- ポーランド中部
- 南アフリカ北部
- 南アフリカ西部
- 米国中南部
- インド南部
- 東南アジア
- スウェーデン中部
- アラブ首長国連邦中部
- アラブ首長国連邦北部
- 英国南部
- 英国西部
- 西ヨーロッパ
- 米国西部
リソース プロバイダーの比較: Microsoft。ストレージとMicrosoft。FileShares
今後のすべての Azure Files NFS プロトコルの新規デプロイにおいて、Microsoft.FileShares を使用した新しいファイル共有エクスペリエンスを評価することをお勧めします。
新しいファイル共有エクスペリエンスで特定の機能要件がまだ利用できない場合、またはワークロードで SMB プロトコルのサポートが必要な場合は、クラシック ファイル共有エクスペリエンスを使用します。
| 機能 | クラシック ファイル共有  |
ファイル共有 (Microsoft。FileShares)  |
|---|---|---|
| サポート保証 | 一般公開 | 一般公開 |
| サービスの最上位リソース | ストレージ アカウント  |
ファイル共有 |
| SMB プロトコル |
|
|
| NFS プロトコル |
|
|
| Azure File Syncサポート |
|
|
| ストレージ アカウントが必要 |
|
|
| 従量課金制の課金モデル |
|
|
| プロビジョニング済み v1 の課金モデル |
|
|
| プロビジョニング済み v2 の課金モデル |
|
|
| HDD のサポート性 |
|
|
| SSD のサポート性 |
|
|
| LRS |
|
|
| ZRS |
|
|
| GRS |
|
|
| GZRS |
|
|
| 共有レベルごとの課金、ネットワーク、セキュリティ構成 |
|
|
| 1 つのファイル共有に対する単一の vnet 構成 |
|
|
| 複数のファイル共有に対する単一の vnet 構成 |
|
|
| AKS CSI ドライバー |
|
|
| データ プレーン REST API |
|
|
| 論理削除のサポート |
|
|
| スナップショットのサポート |
|
|
| 転送中の暗号化 |
|
|
| カスタマー マネージド キー |
|
|
| ゾーン固定 |
|
|
使用可能なプロトコル
Azure Filesには、サーバー メッセージ ブロック (SMB) プロトコルとネットワーク ファイル システム (NFS) プロトコルという、Azureファイル共有をマウントするための業界標準の 2 つのファイル システム プロトコルが用意されています。 ワークロードに最適なプロトコルを選択します。 Azureファイル共有では、同じファイル共有上の SMB プロトコルと NFS プロトコルの両方がサポートされていませんが、同じストレージ アカウント内に SMB と NFS Azureファイル共有を作成できます。
SMB ファイル共有と NFS ファイル共有の両方で、Azure Filesはストレージのニーズに合わせてスケールアップできるエンタープライズ レベルのファイル共有を提供し、何千ものクライアントが同時にアクセスできます。
| 機能 | SMB | NFS |
|---|---|---|
| サポートされるプロトコルのバージョン | SMB 3.1.1、SMB 3.0、SMB 2.1 | NFS 4.1 |
| 推奨される OS |
|
Linux カーネル バージョン 4.3 以降 |
| 使用可能なメディア層 | SSD と HDD | SSD のみ |
| 冗長性 |
|
|
| ファイル システム セマンティクス | Win32 | POSIX |
| 認証 | ID ベースの認証 (Kerberos)、共有キー認証 (NTLMv2) | ホストベースの認証 |
| 承認 | Win32 スタイルのアクセス制御リスト (ACL) | UNIX 形式のアクセス許可 |
| 大文字小文字の区別 | 大文字小文字は区別されないが、保持される | 大文字小文字を区別 |
| 開いているファイルの削除または変更 | ロックのみを使用する | はい |
| ファイル共有 | Windows共有モード | バイト範囲アドバイザリ ネットワーク ロック マネージャー |
| ハード リンクのサポート | サポートされていません | サポートされています |
| シンボリック リンクのサポート | サポートされていません | サポートされています |
| 必要に応じてインターネットからアクセス可能 | はい (SMB 3.0 以降のみ) | いいえ |
| FileREST のサポート | はい | はい (Microsoft。ストレージのみ) |
| 必須のバイト範囲ロック | サポートされています | サポートされていません |
| アドバイザリのバイト範囲ロック | サポートされていません | サポートされています |
| 拡張/名前付き属性 | サポートされていません | サポートされていません |
| 代替データ ストリーム | サポートされていません | 該当なし |
| オブジェクト識別子 | サポートされていません | 該当なし |
| 再解析ポイント | サポートされていません | 該当なし |
| スパース ファイル | サポートされていません | 該当なし |
| 圧縮 | サポートされていません | 該当なし |
| 名前付きパイプ | サポートされていません | 該当なし |
| SMB ダイレクト | サポートされていません | 該当なし |
| SMB ディレクトリのリース | サポートされていません | 該当なし |
| ボリュームのシャドウ コピー | サポートされていません | 該当なし |
| 短いファイル名 (8.3 の別名) | サポートされていません | 該当なし |
| ファイル システム トランザクション (TxF) | サポートされていません | 該当なし |
アイデンティティ
Azureファイル共有にアクセスするには、共有へのアクセスが認証され、承認されている必要があります。 ほとんどの場合、ストレージ アカウント キーの代わりに ID ベースの認証を使用して、SMB Azure ファイル共有にアクセスします。
Azure Filesでは、SMB 共有に対して次の認証方法がサポートされています。
- オンプレミス Active Directory Domain Services (AD DS):Windows Server ファイル サーバーや NAS デバイスと同様に、Azureストレージ アカウントを顧客所有の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 ベースのアクセス許可を必要とするアプリケーションのリフトアンドシフト シナリオに最も役立ちます。 Domain Services は AD ベースの認証を提供するため、このオプションでは Kerberos 認証プロトコルも使用されます。
- Microsoft Entra Kerberos: Microsoft Entra Kerberos を使用すると、Microsoft Entra IDを使用して hybrid またはクラウド専用 ID を認証できます。 この構成では、Microsoft Entra IDを使用して Kerberos チケットを発行し、SMB プロトコルを使用してファイル共有にアクセスします。 つまり、エンド ユーザーは、ハイブリッド参加済み VM とMicrosoft Entra参加済み VM からインターネット経由Microsoft Entra Azureファイル共有にアクセスできます。
- linux クライアントの SMB 経由のActive Directory認証: Azure Filesは、AD DS または Microsoft Entra Domain Services を介した Kerberos 認証プロトコルを使用して、Linux クライアント用の SMB 経由の ID ベースの認証をサポートします。
- Azureストレージ アカウント キー: セキュリティ上の理由から推奨されませんが、ID を使用する代わりにAzureストレージ アカウント キーを使用してAzureファイル共有をマウントすることもできます。 ストレージ アカウント キーを使用してファイル共有をマウントするには、ストレージ アカウント名をユーザー名として使用し、ストレージ アカウント キーをパスワードとして使用します。 マウントされたファイル共有には、ACL がある場合でも、共有上のすべてのファイルとフォルダーに対する完全なアクセス許可があるため、ストレージ アカウント キーを使用して Azure ファイル共有をマウントすることは、実質的に管理者の操作です。 ストレージ アカウント キーを使用して SMB 経由でマウントする場合は、NTLMv2 認証プロトコルが使用されます。 ストレージ アカウント キーを使用する必要がある場合は、「 ネットワーク」 セクションの説明に従って、プライベート エンドポイントまたはサービス エンドポイントを使用します。
オンプレミスのファイル サーバーから移行したり、Azure Filesで新しいファイル共有を作成Windows Serverファイル サーバーや NAS アプライアンスなどの動作を意図した場合は、ストレージ アカウントを顧客所有の AD DS にドメイン参加させます。 詳細については、「Overview - Azure ファイル共有に対する SMB 経由のオンプレミス AD DS 認証を参照してください。
ネットワーク
Azure ファイル共有を直接マウントするには、多くの場合、次の理由から、ネットワーク構成について少し考える必要があります。
- 多くの組織およびインターネット サービス プロバイダー (ISP) は、送信 (インターネット) トラフィックのために SMB ファイル共有が通信に使用するポート 445 をブロックします。
- NFS ファイル共有はネットワーク レベルの認証に依存するため、制限されたネットワーク経由でのみアクセスできます。 NFS ファイル共有を使用するには、常に何らかのレベルのネットワーク構成が必要です。
ネットワークを構成するために、Azure Filesは、インターネットにアクセス可能なパブリック エンドポイントを提供し、サービス エンドポイントなどのAzureネットワーク機能との統合を提供します。これは、パブリック エンドポイントを指定された仮想ネットワークに制限するのに役立ちます。プライベート エンドポイントは、ストレージ アカウントに仮想ネットワーク IP アドレス空間内からのプライベート IP アドレスを提供します。 パブリック エンドポイントまたはサービス エンドポイントの使用に追加料金はかかりませんが、プライベート エンドポイントには標準のデータ処理料金が適用されます。
次のネットワーク構成について考えてみましょう。
- 必要なプロトコルが SMB であり、SMB 経由のすべてのアクセスがAzureのクライアントからのアクセスである場合、特別なネットワーク構成は必要ありません。
- 必要なプロトコルが SMB であり、オンプレミスのクライアントからのアクセスである場合は、オンプレミスから Azure ネットワークへの VPN またはAzure ExpressRoute接続が必要であり、Azure Filesプライベート エンドポイントを使用して内部ネットワークに公開されます。
- 必要なプロトコルが NFS の場合は、サービス エンドポイントまたはプライベート エンドポイントのいずれかを使用して、ネットワークを指定された仮想ネットワークに制限できます。 静的 IP アドレスが必要な場合や、ワークロードに高可用性が必要な場合は、プライベート エンドポイントを使用します。 サービス エンドポイントでは、ゾーンの停止などのまれなイベントによって、ストレージ アカウントの基になる IP アドレスが変更される可能性があります。 ファイル共有でデータを引き続き使用できる間、クライアントは共有の再マウントを必要とします。
詳細については、「Azure Files ネットワークに関する考慮事項を参照してください。
パブリック エンドポイントまたはプライベート エンドポイントとの VPN/ExpressRoute 接続を使用してファイル共有に直接接続することに加えて、SMB には追加のクライアント アクセス戦略 (SMB over QUIC) が用意されています。 SMB over QUIC は、QUIC トランスポート プロトコルを介した SMB アクセス用にゼロ構成の 「SMB VPN」 を提供します。 Azure Files SMBを直接QUICでサポートしているわけではありませんが、Azure File Syncを使うことでWindows Server 2022 AzureエディションのVM上でAzureファイル共有の軽量キャッシュを作成できます。このオプションについて詳しく知りたい方は、Azure File Sync を使ったSMB over QUICをご覧ください。
Azure Filesの暗号化
Azure Filesでは、次の 2 種類の暗号化がサポートされています。
- 転送中の暗号化。Azure ファイル共有のマウントまたはアクセス時に使用される暗号化に関連します
- データがディスクに格納されるときにどのように暗号化されるかに関連する、保存時の暗号化
転送中の暗号化
既定では、すべてのAzureストレージ アカウントで転送中の暗号化が有効になっています。 この機能は、SMB 経由でファイル共有をマウントする場合、または FileREST プロトコル (Azure ポータル、PowerShell/CLI、Azure SDKなど) を使用してファイル共有にアクセスする場合Azure Files、暗号化または HTTPS を使用して SMB 3.x で作成された場合にのみ接続が許可されることを意味します。 SMB 3.x をサポートしていないクライアント、または SMB 3.x をサポートしているが SMB 暗号化をサポートしていないクライアントは、転送中の暗号化が有効になっている場合、Azureファイル共有をマウントできません。 暗号化で SMB 3.x をサポートするオペレーティング システムの詳細については、
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 Filesでは、Azure Blob Storageなどの他のAzure ストレージ サービスと同じ暗号化スキームが使用されます。 Azure Filesに格納されているすべてのデータは、サービス側暗号化 (SSE) によって保存時に暗号化されます。これは、Windowsの BitLocker と同様に機能します。
データはAzure ファイル共有のファイル システムの下で暗号化されるため、ディスクにエンコードされるため、Azure ファイル共有の読み取りまたは書き込みにクライアントの基になるキーにアクセスする必要はありません。 保存時の暗号化は、SMB と NFS の両方のプロトコルに適用されます。
既定では、Azure Filesに格納されているデータは、Microsoftマネージド キーを使用して暗号化されます。 Microsoftマネージド キーでは、Microsoftはデータの暗号化と暗号化解除を行うキーを保持します。 Microsoftは、これらのキーを定期的にローテーションする役割を担います。
クラシック ファイル共有Azure場合は、customer マネージド キーを使用してデータを暗号化できます。 カスタマー マネージド キーを選択した場合、Azure Filesは、クライアントからの読み取りと書き込みの要求を満たすためにキーにアクセスする権限を持ちます。 カスタマー マネージド キーを使用すると、いつでもこの認可を取り消すことができます。 ただし、この承認がないと、Azureファイル共有は SMB または FileREST API 経由でアクセスできなくなります。
Microsoft.FileShares リソース プロバイダーを使用して作成された Azure ファイル共有では、保存時暗号化にカスタマー マネージド キーを使用できません。 Microsoft マネージド キーを使用する必要があります。
データ保護
Azure Filesでは、多層アプローチを使用して、データがバックアップされ、回復可能であり、セキュリティ上の脅威から保護されていることを確認します。 Azure Filesデータ保護の概要を参照してください。
論理的な削除
ソフト削除は、誤って削除したファイル共有を復元するために使用できる、ストレージ アカウント レベルの設定です。 ファイル共有を削除すると、完全に削除されるのではなく、ソフト削除状態に移行します。 論理的に削除された共有が完全に削除され、復旧できなくなるまでの時間を構成することができます。この保有期間中はいつでも共有の削除を取り消すことができます。
新しいストレージ アカウントについては、ソフトデリートが既定で有効になります。 共有の削除が一般的で想定されるワークフローがある場合は、短い保持期間を設定するか、論理的な削除を有効にしないことを決定できます。
論理的な削除の詳細については、データの誤削除の防止に関する記事を参照してください。
Backup
Azure ファイル共有のバックアップには、共有の読み取り専用かつ特定の時点のコピーである共有スナップショットを使用してください。 スナップショットは増分的であるため、前のスナップショット以降に変更されたデータのみが含まれます。 各ファイル共有は最大 200 個のスナップショットをサポートしており、最大 10 年間保持できます。 Azure ポータルでスナップショットを手動で作成することも、PowerShell またはコマンド ライン インターフェイス (CLI) を使用することもできます。 Azure Backupを使用することもできます。
SMB Azure ファイル共有のAzure Backupはスナップショットのスケジュール設定と保持を処理します。 三世代 (GFS: grandfather-father-son) 機能は、日次、週次、月次、年次のスナップショットを取得できることを意味し、それぞれに個別の保持期間が設けられています。 Azure Backupまた、論理的な削除の有効化を調整し、その中のファイル共有がバックアップ用に構成されるとすぐに、ストレージ アカウントに対して削除ロックを行います。 Azure Backupには、お客様がバックアップ資産を統合して表示できる、特定の主要な監視機能とアラート機能が用意されています。
Azure Backupを使用して、Azure ポータルでアイテム レベルと共有レベルの両方の復元を実行できます。 復元ポイント(特定のスナップショット)、該当する場合は特定のファイルやディレクトリ、そして復元したい場所(元の場所または代替場所)を選びます。 バックアップ サービスによって、スナップショット データのコピーが処理され、ポータル上に復元の進行状況が表示されます。
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は、ストレージ アカウント のデータにアクセスせず、パフォーマンスに影響を与えません。 サブスクリプション レベル (推奨) またはリソース レベルでMicrosoft Defender for Storageを有効にできます。
ストレージ層
Azure Filesには、ソリッド ステート ディスク (SSD) とハード ディスク ドライブ (HDD) の 2 つのメディア層が用意されています。 これらのレベルを使用すると、シナリオのパフォーマンスと価格の要件に合わせて共有を調整できます。
SSD (premium): SSD ファイル共有は、IO 集中型ワークロードの場合、ほとんどの IO 操作に対して 1 桁台のミリ秒以内で安定したハイ パフォーマンスと低待機時間を提供しています。 SSD ファイル共有は、データベース、Web サイトのホスティング、開発環境など、幅広い種類のワークロードに適しています。
SMB プロトコルと NFS プロトコルの両方で SSD ファイル共有を使用できます。 SSD ファイル共有は、プロビジョニング済み v2 課金モデルとプロビジョニング済み v1 課金モデルで使用できます。 SSD ファイル共有では、HDD ファイル共有よりも高い可用性 SLA が提供されます。
HDD (standard): HDD ファイル共有は、汎用ファイル共有のためのコスト効率の高いストレージ オプションを提供します。 HDD ファイル共有は、プロビジョニング済み v2 および従量課金モデルで使用できますが、新しいファイル共有のデプロイには、プロビジョニング済み v2 モデルをお勧めします。 SLA の詳細については、オンライン サービス向け Azure SLA ページ を参照してください。
ワークロードのメディア レベルを選択する場合は、パフォーマンスと使用量の要件を考慮してください。 ワークロードで 1 桁の待機時間が必要な場合、またはオンプレミスで SSD ストレージ メディアを使用している場合は、おそらく SSD ファイル共有が最適です。 低待ち時間がさほど重要でない場合は、コストの観点から HDD ファイル共有の方が適している可能性があります。 たとえば、Azureからオンプレミスにマウントされたチーム共有や、Azure File Syncを介してオンプレミスにキャッシュされたチーム共有に関して、待機時間が短くなる可能性があります。
ストレージ アカウントにファイル共有を作成した後は、別のメディア レベルに直接移動することはできません。 たとえば、HDD ファイル共有を SSD メディア レベルに移動する場合、新しい SSD ファイル共有を作成し、データを元の共有から FileStorage アカウント内の新しいファイル共有にコピーする必要があります。
SSD と HDD のメディア層の詳細については、Azure Files の課金モデルを理解する と Azure ファイル共有のパフォーマンスを理解して最適化する をご覧ください。
冗長性
Azure ファイル共有内のデータをデータの損失や破損から保護するために、Azure Filesは、書き込まれた各ファイルの複数のコピーを格納します。 要件に応じて、冗長性のレベルを選択できます。 Azure Filesでは、現在、データの冗長性に関する次のオプションがサポートされています。
ローカル冗長ストレージ (LRS): ローカル冗長性により、すべてのファイルが Azure ストレージ クラスターに 3 回格納されます。 この方法は、ディスク ドライブの不良などのハードウェア障害によるデータ損失からの保護に役立ちます。 ただし、データ センター内で火災や洪水などの災害が発生した場合は、LRS を使用しているストレージ アカウントのすべてのレプリカが失われたり、回復不能になったりする可能性があります。
ゾーン冗長ストレージ (ZRS):ゾーン冗長では、各ファイルの 3 つのコピーが格納されます。 ただし、これらのコピーは、Azure 可用性ゾーン内の 3 つの異なるストレージ クラスターで物理的に分離されます。 可用性ゾーンは、Azure リージョン内の一意の物理的な場所です。 それぞれのゾーンは、独立した電源、冷却手段、ネットワークを備えた 1 つまたは複数のデータセンターで構成されています。 3つの可用性ゾーンすべてのストレージクラスターに書き込まれるまで、ストレージへの書き込みは承認されません。
Geo 冗長ストレージ (GRS): geo 冗長性では、プライマリ リージョンとセカンダリ リージョンがあります。 ファイルは、プライマリ リージョンの Azure ストレージ クラスターに 3 回格納されます。 書き込みは、Microsoft定義されたセカンダリ リージョンに非同期的にレプリケートされます。
geo 冗長性により、2 つの Azure リージョン間に分散されたデータの 6 つのコピーが提供されます。 自然災害やその他の同様のイベントによってAzureリージョンが永続的に失われるなど、大規模な災害が発生した場合、Microsoftはフェールオーバーを実行します。 この場合は、セカンダリがプライマリになり、すべての操作が行われます。
プライマリ リージョンとセカンダリ リージョンの間のレプリケーションは非同期であるため、重大な災害が発生した場合、セカンダリ リージョンにまだレプリケートされていないデータは失われます。 geo 冗長ストレージ アカウントのフェールオーバーは、手動で実行することもできます。
geo ゾーン冗長ストレージ (GZRS): geo ゾーン冗長性では、ファイルはプライマリ リージョンの 3 つの別個のストレージ クラスターに 3 回格納されます。 その後、すべての書き込みが、Microsoft定義されたセカンダリ リージョンに非同期的にレプリケートされます。 geo ゾーン冗長性のフェールオーバー プロセスは、geo 冗長性の場合と同じように動作します。
HDD ファイル共有では、4 種類の冗長性がすべてサポートされます。 SSD ファイル共有では、LRS と ZRS のみがサポートされます。
従量課金制ストレージ アカウントには、読み取りアクセス geo 冗長ストレージ (RA-GRS) と読み取りアクセス geo ゾーン冗長ストレージ (RA-GZRS) という、Azure Filesがサポートしていない他の 2 つの冗長性オプションが用意されています。 これらのオプションを設定Azureストレージ アカウント内のファイル共有をプロビジョニングできますが、Azure Filesではセカンダリ リージョンからの読み取りはサポートされません。 RA-GRS または RA-GZRS ストレージ アカウントにデプロイされたAzureファイル共有は、それぞれ geo 冗長または geo ゾーン冗長として課金されます。
冗長性の詳細については、「Azure Files データ冗長性」を参照してください。
ゾーン冗長 SSD ファイル共有の可用性
ゾーン冗長 SSD ファイル共有は、Azure リージョンのsubset で使用できます。
ディザスター リカバリーとフェールオーバー
計画外のリージョン サービスの停止が発生した場合は、Azure ファイル共有のディザスター リカバリー (DR) 計画を立てる必要があります。 DR とストレージ アカウントのフェールオーバーに関連する概念とプロセスを理解するには、Azure Files の
移行
多くの場合、組織の新しい新しいファイル共有を確立するのではなく、既存のファイル共有をオンプレミスのファイル サーバーまたは NAS デバイスからAzure Filesに移行します。 移行の成功には、適切な移行戦略とツールを選択することが重要です。
SMB 移行については、「 SMB 移行の概要 」を参照してください。この概要には、シナリオに対応している可能性の高い移行ガイドが記載されています。
NFS の移行については、「 NFS Azure ファイル共有への移行を参照してください。
