ハイブリッド ファイル サービス

この参照アーキテクチャでは、Azure File Sync と Azure Files を使用して、クラウドおよびオンプレミスのファイル共有リソース全体でファイル サービスのホスティング機能を拡張する方法について説明します。

アーキテクチャ

このアーキテクチャの Visio ファイルをダウンロードします。

ワークフロー

アーキテクチャは、次のコンポーネントで構成されています。

• Azure ストレージ アカウント。 ファイル共有をホストするために使用されるストレージ アカウント。
• Azure Files 。 Azure File Sync を使用して同期関係のクラウド エンドポイントを提供するサーバーレス クラウド ファイル共有。Azure ファイル共有内のファイルには、サーバー メッセージ ブロック (SMB) または FileREST プロトコルを使用して直接アクセスできます。
• 同期グループ。 Windows Server を実行する Azure ファイル共有とサーバーの論理グループ。 同期グループは、ストレージ同期サービスにデプロイされます。これは、Azure File Sync で使用するサーバーを登録し、同期グループのリレーションシップが含まれます。
• Azure File Sync エージェント。 これは、Windows Server マシンにインストールして、クラウド エンドポイントとの同期を有効にして構成します。
• Windows サーバー。 Azure ファイル共有と同期するファイル共有をホストするオンプレミスまたはクラウドベースの Windows Server マシン。
• Microsoft Entra ID。 Azure 環境とオンプレミス環境全体の ID 同期に使用される Microsoft Entra テナント。

コンポーネント

• Azure Storage アカウント
• Azure Files
• Microsoft Entra ID

シナリオの詳細

このアーキテクチャの一般的な用途は次のとおりです。

• クラウド環境とオンプレミス環境からアクセスできる必要があるファイル共有のホスト。
• 1 つのクラウドベースのソースと、複数のオンプレミス データ ストア間でのデータの同期。

Recommendations

ほとんどのシナリオには、次の推奨事項が適用されます。 優先すべき要件がない限り、これらの推奨事項に従ってください。

Azure Files の使用とデプロイ

ファイルはクラウドのサーバーレス Azure ファイル共有に格納します。 これらの使用方法は 2 つあり、直接マウント (SMB) するか、Azure File Sync を使用してオンプレミスにキャッシュします。デプロイの計画時に考慮する必要がある内容は、2 つの方法のどちらを選択するかによって異なります。

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

ストレージ同期サービスのデプロイ

Azure File Sync のデプロイを開始するには、選択したサブスクリプションのリソース グループにストレージ同期サービス リソースをデプロイします。 可能な限り少ない数のストレージ同期サービス オブジェクトをプロビジョニングすることが推奨されます。 サーバーとこのリソースの間に信頼関係を作成します。 サーバーは、1 つのストレージ同期サービスにのみ登録できます。 そのため、サーバーのグループを分離するために必要な数だけのストレージ同期サービスをデプロイすることが推奨されます。 異なるストレージ同期サービスを使用するサーバー間では同期できないことに注意してください。

Azure File Sync エージェントへの Windows Server マシンの登録

Windows Server で同期機能を有効にするには、Azure File Sync のダウンロード可能なエージェントをインストールする必要があります。 Azure File Sync エージェントには、2 つの主要コンポーネントがあります。

• FileSyncSvc.exe= サーバー エンドポイントの変更の監視と、同期セッションの開始を担当するバックグラウンドの Windows サービス。
• StorageSync.sys= クラウドの階層化と迅速なディザスター リカバリーを可能にするファイル システム フィルター。

エージェントは、Microsoft ダウンロード センターの Azure File Sync エージェントのダウンロード ページからダウンロードできます。

オペレーティング システムの要件

Azure File Sync は、次の表の一覧にある Windows Server バージョンでサポートされています。

詳細については、「Windows ファイル サーバーに関する考慮事項」を参照してください。

同期グループとクラウド エンドポイントの構成

同期グループは、一連のファイルの同期トポロジを定義します。 同期グループ内のエンドポイントは、相互に同期を維持されます。 同期グループには、Azure ファイル共有と 1 つ以上のサーバー エンドポイントを表す、1 つのクラウド エンドポイントが含まれている必要があります。 サーバー エンドポイントは、登録されているサーバー上のパスを表します。 1 つのサーバーが、複数の同期グループにサーバー エンドポイントを持つことができます。 目的の同期トポロジを適切に記述するために必要なだけいくつでも同期グループを作成できます。

クラウド エンドポイントは、Azure ファイル共有へのポインターです。 すべてのサーバー エンドポイントはクラウド エンドポイントと同期するので、クラウド エンドポイントはハブになります。 Azure ファイル共有のストレージ アカウントは、ストレージ同期サービスと同じリージョンに存在する必要があります。 Azure ファイル共有の全体が同期されますが、1 つ例外があり、NT ファイル システム (NTFS) ボリューム上の非表示のシステム ボリューム情報フォルダーに相当する特別なフォルダーがプロビジョニングされます。 このディレクトリは .SystemShareInformation と呼ばれ、他のエンドポイントと同期しない重要な同期メタデータが格納されています。

サーバー エンドポイントの構成

サーバー エンドポイントは、登録済みサーバー上の特定の場所を表します。たとえば、サーバー ボリュームのフォルダーなどです。 サーバー エンドポイントは (マウントされた共有ではなく) 登録されたサーバー上のパスであり、クラウドを使った階層化を使用する必要があります。 サーバー エンドポイントのパスは、システム ボリューム以外にある必要があります。 NAS はサポートされていません。

Azure ファイル共有と Windows ファイル共有の関係

可能な限り、Azure ファイル共有と Windows ファイル共有を 1 対 1 でデプロイする必要があります。 サーバー エンドポイント オブジェクトを使用すると、同期関係のサーバー側で同期トポロジを設定する方法において、高い柔軟性を発揮します。 管理を簡略化するには、サーバー エンドポイントのパスを Windows ファイル共有のパスと一致させます。

使用するストレージ同期サービスは、出来る限り最小限に抑えます。 これにより、Windows Server は一度に 1 つのストレージ同期サービスにしか登録できないため、複数のサーバー エンドポイントを含む同期グループがある場合の管理が簡単になります。

Azure ファイル共有をデプロイする際は、ストレージ アカウントでの IOPS (秒あたりの I/O 操作) 制限に注意してください。 できる限り、ファイル共有をストレージ アカウントと 1 対 1 でマップしてください。 組織と Azure でのさまざまな制限や制約により、これが可能でない場合があります。 1 つのストレージ アカウントにファイル共有を 1 つだけデプロイすることが不可能な場合は、最もアクティブなファイル共有を同じストレージ アカウントに入れないでください。

トポロジに関するレコメンデーション: ファイアウォール、エッジ ネットワーク、プロキシ接続

ソリューション トポロジに関する次のレコメンデーションを考慮してください。

ファイアウォールとトラフィックのフィルター処理

組織のポリシーまたは固有の規制要件に応じて、Azure との通信を制限することが必要になる場合があります。 そのため、Azure File Sync には、ネットワークを構成するためのメカニズムがいくつか用意されています。 要件に応じて、次のことができます。

• Azure ExpressRoute または Azure 仮想プライベート ネットワーク (VPN) 経由での同期とファイルのアップロードとダウンロードのトラフィックのトンネリング。
• Azure Files と Azure のネットワーク機能 (サービス エンドポイント、プライベート エンドポイントなど) の使用。
• お使いの環境でプロキシをサポートするよう Azure File Sync を構成。
• Azure File Sync からネットワーク アクティビティを調整。

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

プロキシ サーバーの構成

多くの組織では、オンプレミス ネットワーク内のリソースと、Azure 内などのネットワーク外部のリソース間の仲介役としてプロキシ サーバーを使用しています。 プロキシ サーバーは、ネットワークの分離とセキュリティ、監視、ログ記録などのさまざまな用途で役立ちます。 Azure File Sync はプロキシ サーバーと完全に相互運用できますが、Azure File Sync を使用する実際の環境に合わせてプロキシ エンドポイントの設定を手動で構成する必要があります。これは、Azure PowerShell で Azure File Sync のサーバー コマンドレットを使用して行います。

プロキシ サーバーを使用した Azure File Sync の構成方法の詳細については、「Azure File Sync のプロキシとファイアウォールの設定」を参照してください。

考慮事項

以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。

[信頼性]

信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 詳細については、「信頼性の重要な要素の概要」を参照してください。

• Azure ファイル共有をホストするために使用するストレージ アカウントの種類とパフォーマンスを考慮する必要があります。 ストレージ アカウントにデプロイされているすべてのストレージ リソースにより、そのストレージ アカウントに適用される制限が共有されます。 ストレージ アカウントの現在の制限の決定に関する詳細を確認するには、「Azure Files のスケーラビリティおよびパフォーマンスのターゲット」をご覧ください。
• Azure Files のデプロイには、次のように主に 2 種類のストレージ アカウントがあります。
  • 汎用バージョン 2 (GPv2) ストレージ アカウント。 GPv2 ストレージ アカウントを使うと、Standard のハード ディスク ベース (HDD ベース) のハードウェアに Azure ファイル共有をデプロイできます。 GPv2 ストレージ アカウントでは、Azure ファイル共有を格納するだけでなく、BLOB コンテナー、キュー、テーブルなどの他のストレージ リソースも格納できます。
  • FileStorage ストレージ アカウント: FileStorage ストレージ アカウントを使うと、Premium またはソリッドステート ディスク ベース (SSD ベース) のハードウェアに、Azure ファイル共有をデプロイできます。 FileStorage アカウントは、Azure ファイル共有を格納するためにのみ使用できます。 BLOB コンテナー、キュー、テーブルなどの他のストレージ リソースを FileStorage アカウントにデプロイすることはできません。
• ソリューションをデプロイするリージョンで Azure File Sync がサポートされていることを確認する必要があります。 詳細については、「Azure File Sync の利用可能なリージョン」を参照してください。
• 「アーキテクチャ」セクションで参照されているサービスが、ハイブリッド ファイル サービス アーキテクチャをデプロイするリージョンでサポートされていることを確認する必要があります。
• Azure ファイル共有内のデータを損失や破損から保護するため、すべての Azure ファイル共有では、各ファイルが書き込まれるときに複数のコピーが格納されます。 ワークロードの要件に応じて、冗長性のレベルをさらに高めることができます。
• "以前のバージョン" とは、ボリュームのサーバー側ボリューム シャドウ コピー サービス (VSS) スナップショットを使用して、ファイルの復元可能なバージョンを SMB クライアントに提供する、Windows の機能です。 VSS スナップショットと以前のバージョンは、Azure File Sync からは独立して機能します。ただし、クラウドを使った階層化を互換モードに設定する必要があります。 多くの Azure File Sync サーバー エンドポイントが、同じボリューム上に存在できます。 クラウドを使った階層化を使用しているか使用する予定のサーバー エンドポイントが 1 つでもあるボリュームでは、次の PowerShell 呼び出しを実行する必要があります。 以前のバージョンと VSS の詳細については、「以前のバージョンおよび VSS (ボリューム シャドウ コピー サービス) を使用するセルフサービス復元」を参照してください。

セキュリティ

セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの重要な要素の概要」を参照してください。

• Azure File Sync は、Azure File Sync のセットアップ以外に特別な設定を行わなくても、標準の Active Directory Domain Services (AD DS) ID で動作します。Azure File Sync を使用する場合、ファイル アクセスは一般に Azure ファイル共有経由ではなく、Azure File Sync キャッシュ サーバーを経由します。 サーバー エンドポイントは Windows Server マシン上にあるため、ID 統合の唯一の要件は、ドメインに参加している Windows ファイル サーバーを使用してストレージ同期サービスに登録することです。 Azure File Sync では、Azure ファイル共有にファイルのアクセス制御リスト (ACL) を格納し、それらをすべてのサーバー エンドポイントにレプリケートします。
• Azure ファイル共有に直接加えられた変更は、同期グループ内のサーバー エンドポイントに同期するのに時間がかかりますが、ファイル共有に対する AD DS アクセス許可をクラウドでも直接適用できることを確認する必要があります。 これを行うには、Windows ファイル サーバーがドメイン参加しているのと同じように、ストレージ アカウントをオンプレミスの AD DS にドメイン参加させる必要があります。 顧客所有の AD DS インスタンスにストレージ アカウントをドメイン参加させることの詳細については、「SMB アクセスの Azure Files ID ベース認証オプションの概要」を参照してください。
• Azure File Sync を使用する場合は、次の 3 つの異なるレイヤーの暗号化を考慮する必要があります。
  • Windows Server に格納されているデータの保存時の暗号化。 一般的に Azure File Sync で機能する Windows Server 上のデータを暗号化する方法には、ファイル システムとそれに書き込まれたすべてのデータが暗号化されるファイル システムにおける暗号化と、ファイル形式自体での暗号化という、2 つの方法があります。 これらの方法はそれぞれ目的が異なるため、必要に応じて同時に使用できます。
  • Azure File Sync エージェントと Azure 間の転送中の暗号化。 Azure File Sync エージェントは、Azure File Sync REST プロトコルと FileREST プロトコルを使用して、ストレージ同期サービスと Azure ファイル共有と通信します。どちらも、常にポート 443 経由で HTTPS を使用します。 Azure File Sync では、暗号化されていない要求が HTTP 経由で送信されることはありません。
  • Azure ファイル共有に格納されているデータの保存時の暗号化。 Azure Files に格納されるすべてのデータは、Azure Storage Service Encryption (SSE) を使用して保存時に暗号化されます。 Storage Service Encryption は Windows の BitLocker と同様に機能し、データはファイル システム レベルで暗号化されます。 データは Azure ファイル共有のファイル システムで暗号化されるため、データがディスクにエンコードされるときに、Azure ファイル共有を読み書きするために、基になるクライアント上のキーにアクセスできる必要はありません。

コスト最適化

コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。

• コスト最適化のレコメンデーションについては、Azure Well-Architected Framework の「コスト最適化の原則」ページを参照してください。
• アカウントの種類、ストレージ容量、レプリケーション、およびトランザクションに基づく詳細な料金情報については、「 Azure Storage 料金 」ページを参照してください。
• データ エグレスの価格の詳細については、データ転送の価格の詳細に関する記事を参照してください。
• コストの見積には、 計算ツール をご利用ください。

オペレーショナル エクセレンス

オペレーショナル エクセレンスは、アプリケーションをデプロイし、それを運用環境で実行し続ける運用プロセスをカバーします。 詳細については、「オペレーショナル エクセレンスの重要な要素の概要」を参照してください。

• Azure File Sync エージェントは、新機能の追加や問題の解決を目的として定期的に更新されます。 Microsoft では、取得可能になった Azure File Sync エージェントの更新プログラムが提供されるように、Microsoft Update を構成することをお勧めしています。 詳細については、「Azure ファイル同期エージェントの更新ポリシー」を参照してください。
• Azure Storage には、アプリケーションまたは他のストレージ アカウント ユーザーによって誤って削除されたデータを復旧できるように、ファイル共有での論理的な削除が用意されています。 論理的な削除の詳細については、「Azure ファイル共有で論理的な削除を有効にする」を参照してください。
• クラウドの階層化は Azure File Sync のオプション機能です。これにより、頻繁にアクセスされるファイルがサーバー上にローカルにキャッシュされ、その他はポリシー設定に基づいて Azure Files に階層化されます。 ファイルが階層化されていると、Azure File Sync ファイル システム フィルター (StorageSync.sys) によって、ファイルがローカルで、Azure Files 内のファイルへのポインターに置き換えられます。 階層化されたファイルをサード パーティ アプリケーションで安全に識別できるように、階層化されたファイルにはオフライン属性と FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS 属性の両方が NTFS 内で設定されます。 詳細については、「クラウドの階層化の概要」を参照してください。

次のステップ

• Azure File Sync とは何ですか。
• Azure File Sync はどのように課金されますか。
• Azure File Sync のデプロイはどのように計画しますか。
• Azure File Sync はどのようにデプロイしますか。
• Azure File Sync のネットワークに関する考慮事項。
• クラウドを使った階層化とは何ですか。
• Azure File Sync で使用できるディザスター リカバリー オプションは何ですか。
• Azure File Sync はどのようにバックアップしますか。

関連リソース

関連するハイブリッド ガイダンス:

• ハイブリッド アーキテクチャの設計
• Azure ハイブリッド オプション
• ハイブリッド アプリの設計上の考慮事項

関連アーキテクチャ

• Azure エンタープライズ クラウド ファイル共有
• オンプレミスでアクセスされ、AD DS によってセキュリティで保護される Azure Files
• リモートおよびローカル ブランチ ワーカー用ディザスター リカバリーを使用したハイブリッド ファイル共有
• ハイブリッド環境で Azure ファイル共有を使用する