Azure File Sync のデプロイの計画

Azure File Sync は、オンプレミスの Windows Server またはクラウド VM に多数の Azure ファイル共有をキャッシュできるサービスです。

この記事では、Azure File Sync の概念と機能を紹介します。 Azure File Sync について理解したら、Azure File Sync デプロイ ガイドに従って、このサービスを試してみることを検討してください。

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

• 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 のデプロイには、次の 3 つの基本的な管理オブジェクトがあります。

• Azure ファイル共有: Azure ファイル共有はサーバーレス クラウド ファイル共有であり、Azure File Sync の同期関係のクラウド エンドポイントを提供します。 Azure ファイル共有内のファイルには、SMB または FileREST プロトコルを使用して直接アクセスできます。ただし、Azure ファイル共有が Azure File Sync で使用されている場合は、主に Windows Server キャッシュを介してファイルにアクセスすることをお勧めします。これは、現在 Azure Files には Windows Server のような効率的な変更検出メカニズムがないため、Azure ファイル共有に直接加えた変更がサーバー エンドポイントに反映されるまでに時間がかかるためです。
• サーバー エンドポイント:Azure ファイル共有に同期されている Windows Server 上のパス。 これには、ボリューム上の特定のフォルダー、またはボリュームのルートを指定できます。 名前空間が重複していなければ、同じボリューム上に複数のサーバー エンドポイントが存在できます。
• 同期グループ:クラウド エンドポイント、Azure ファイル共有、およびサーバー エンドポイント間の同期関係を定義するオブジェクト。 同期グループ内のエンドポイントは、相互に同期を維持されます。 たとえば、Azure File Sync で管理するファイル セットが 2 組ある場合、2 つの同期グループを作成し、各同期グループに別のエンドポイントを追加します。

Azure ファイル共有の管理の概念

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 File Sync の管理の概念

同期グループは、ストレージ同期サービスにデプロイされます。これは、Azure File Sync で使用するサーバーを登録する最上位のオブジェクトで、同期グループのリレーションシップが含まれています。 ストレージ同期サービス リソースは、ストレージ アカウント リソースのピアであり、同じように Azure リソース グループにデプロイできます。 ストレージ同期サービスでは、複数のストレージ アカウントと複数の登録済み Windows サーバー間で Azure ファイル共有を含む同期グループを作成できます。

ストレージ同期サービスで同期グループを作成する前に、まずストレージ同期サービスで Windows Server を登録する必要があります。 これにより、登録済みサーバー オブジェクトが作成され、これはサーバー (またはクラスター) とストレージ同期サービス間の信頼関係を表します。 ストレージ同期サービスを登録するには、まずサーバーに Azure File Sync エージェントをインストールする必要があります。 個々のサーバーまたはクラスターは、同時に 1 つのストレージ同期サービスのみに登録できます。

同期グループには、1 つのクラウド エンドポイント (Azure ファイル共有) と 1 つ以上のサーバー エンドポイントが含まれます。 サーバー エンドポイント オブジェクトには、クラウドを使った階層化機能を構成する設定が含まれています。これにより Azure File Sync のキャッシュ機能が提供されます。Azure ファイル共有と同期するには、Azure ファイル共有を含むストレージ アカウントが、ストレージ同期サービスと同じ Azure リージョンに存在している必要があります。

必要なストレージ同期サービスの数を検討する

前のセクションでは、Azure File Sync に対して構成するコア リソース ("ストレージ同期サービス") について説明されています。 Windows Server は、1 つのストレージ同期サービスにのみ登録できます。 そのため、多くの場合、単一のストレージ同期サービスをデプロイし、そこですべてのサーバーを登録することをお勧めします。

以下の場合に限り、複数のストレージ同期サービスを作成します。

• データを交換する必要のない個別のサーバー セットがある場合。 この場合は、異なるストレージ同期サービスの同期グループ内でクラウド エンドポイントとして既に使用されている Azure ファイル共有と同期するために、特定のサーバー セットを除外するようにシステムを設計する必要があります。 これは見方を変えると、別々のストレージ同期サービスに登録されている Windows Server は、同一の Azure ファイル共有と同期できないということになります。
• 1 つのストレージ同期サービスでサポートできるよりも多くの登録済みサーバーまたは同期グループを用意する必要がある場合。 詳細については、「Azure File Sync のスケール ターゲット」を確認してください。

バランスの取れた同期トポロジの計画

リソースをデプロイする前に、ローカル サーバー上で何をどの Azure ファイル共有と同期するかを計画することが重要です。 計画を作成すると、必要なストレージ アカウント、Azure ファイル共有、および同期リソースの数を決定するのに役立ちます。 これらの考慮事項は、データが現在 Windows Server または長期的に使用するサーバー上に存在しない場合でも、やはり関係があります。 状況に応じて適切な移行パスを決定する際は、移行セクションが役立ちます。

この手順では、必要な Azure ファイル共有の数を決定します。 1 つの Windows Server インスタンス (またはクラスター) では、最大 30 個の Azure ファイル共有を同期できます。

現在、SMB 共有としてユーザーとアプリに対してローカルに共有しているボリュームには、さらに多くのフォルダーが存在する場合があります。 このシナリオを理解する最も簡単な方法は、1:1 で Azure ファイル共有にマップするオンプレミスの共有を想像することです。 1 つの Windows Server インスタンスの共有数が 30 以下と十分に少ない場合は、1 対 1 のマッピングをお勧めします。

共有の数が 30 を超える場合、通常オンプレミスの共有を 1 対 1 で Azure ファイル共有にマッピングする必要はありません。 次のオプションを検討してください。

共有のグループ化

たとえば、人事 (HR) 部門に 15 個の共有がある場合、すべての HR データを 1 つの Azure ファイル共有に格納することを検討できます。 1 つの Azure ファイル共有にオンプレミスの共有を複数格納しても、ローカルの Windows Server インスタンスに通常の 15 個の SMB 共有を作成できます。 これは、単にこれらの 15 個の共有のルート フォルダーを共通フォルダーの下のサブフォルダーとして整理することを意味します。 その後、この共通フォルダーを Azure ファイル共有に同期します。 そうすることで、このオンプレミスの共有グループに必要なのは、クラウド内の 1 つの Azure ファイル共有のみとなります。

ボリュームの同期

Azure File Sync では、ボリュームのルートを Azure ファイル共有に同期することをサポートしています。 ボリューム ルートを同期した場合、すべてのサブフォルダーとファイルは同じ Azure ファイル共有に格納されます。

ボリュームのルートを同期することが常に最適なオプションであるとは限りません。 複数の場所に同期することには利点があります。 たとえば、そうすることで、同期スコープあたりの項目数を少なく抑えることができます。 Azure ファイル共有と Azure File Sync は、共有ごとに 1 億個の項目 (ファイルとフォルダ) を保持できるようテストされています。 ただし、ベスト プラクティスとしては、1 つの共有に保持する項目数は、2000 万から 3000 万個未満にすることをお勧めします。 Azure File Sync に含める項目数を少数に設定することは、ファイルの同期にとって有益というだけではありません。項目の数が少ないと、次のようなシナリオでも利点があります。

• クラウド コンテンツの初期スキャンの完了までの時間が短くなり、その結果、Azure File Sync 対応のサーバーに名前空間が表示されるまでの待機時間が短縮されます。
• Azure ファイル共有スナップショットからのクラウド側の復元が高速になります。
• オンプレミスサーバーのディザスター リカバリーが大幅にスピードアップされます。
• Azure ファイル共有 (同期以外) で直接行われた変更が、より高速に検出、同期されます。

デプロイ マップへの構造化アプローチ

後の手順でクラウド ストレージをデプロイする前に、オンプレミス フォルダーと Azure ファイル共有の間にマップを作成することが重要です。 このマッピングを行うと、プロビジョニングする Azure File Sync の "同期グループ" リソースの数と名称が通知されます。 同期グループは、Azure ファイル共有とサーバー上のフォルダーを連携させ、同期接続を確立します。

必要な Azure ファイル共有の数を決めるには、次の制限事項とベストプラクティスをレビューしてください。 そのことが、マップの最適化に役立ちます。

• Azure File Sync エージェントがインストールされているサーバーは、最大 30 個の Azure ファイル共有と同期できます。

• Azure ファイル共有は、ストレージ アカウント内にデプロイされます。 この配置により、このストレージ アカウントが、IOPS やスループットなどのパフォーマンス数のスケール ターゲットになります。

  Azure ファイル共有をデプロイする際には、ストレージ アカウントの IOPS 制限に注意してください。 理想的には、ファイル共有をストレージ アカウントに 1:1 でマップする必要があります。 ただし、組織と Azure の両方からのさまざまな制限と制約により、これが常に可能とは限りません。 1 つのストレージ アカウントに 1 つのファイル共有のみをデプロイすることができない場合は、使用頻度が高い共有と低い共有を考慮し、最もアクティブなファイル共有が同じストレージ アカウントに一緒にデプロイされないようにしてください。

  Azure ファイル共有をネイティブで使用する Azure にアプリをリフトする場合は、Azure ファイル共有のパフォーマンスをさらに上げる必要があります。 将来的にでもこのように使用することが考えられる場合は、1 つの標準の Azure ファイル共有を独自のストレージ アカウントに作成するのが最善です。

• 1 つの Azure リージョンにつき、1 サブスクリプションあたりのストレージ アカウント数は 250 に制限されています。

ここでのベストプラクティスは、同期スコープあたりの項目数を少なくしておくことです。 これは、フォルダーを Azure ファイル共有にマッピングする際に考慮する必要がある重要な要素です。 Azure File Sync は、共有ごとに 1 億個の項目 (ファイルとフォルダー) を使用して検証済みです。 ただし、多くの場合、1 つの共有に保持する項目数は、2000 万から 3000 万個未満にすることをお勧めします。 これらの数値を超え始めた場合は、名前空間を複数の共有に分割します。 これらの数値をほぼ下回っている場合、複数のオンプレミスの共有を同じ Azure ファイル共有にグループ化することを続行できます。 この方法により、拡大する余地が得られます。

状況によっては、一連のフォルダーが同じ Azure ファイル共有に論理的に同期される可能性があります (前述の新しい共通のルート フォルダーのアプローチを使用します)。 ただし、1 つの Azure ファイル共有ではなく 2 つに同期されるように、フォルダーを再グループ化することをお勧めします。 このアプローチを使用すると、ファイル共有あたりのファイルとフォルダーの数をサーバー間に分散させることができます。 オンプレミスの共有を分割し、より多くのオンプレミス サーバー間で同期させることもできます。これにより、追加のサーバーごとに 30 を超える Azure ファイル共有と同期することができます。

ファイル同期の一般的なシナリオと考慮事項

#	同期シナリオ	サポートされています	考慮事項 (または制限事項)	解決策 (または対処法)
1	複数のディスク/ボリュームと複数の共有があるファイル サーバーと、同じターゲット Azure ファイル共有 (統合)	いいえ	ターゲットの Azure ファイル共有 (クラウド エンドポイント) は、1 つの同期グループとの同期のみをサポートします。 同期グループは、登録済みサーバーごとに 1 つのサーバー エンドポイントのみをサポートします。	1) 最初に、1 つのディスク (そのルート ボリューム) を、ターゲットの Azure ファイル共有と同期させます。 最大のディスク/ボリュームから始めると、オンプレミスのストレージ要件に対応できます。 クラウドの階層化を構成して、すべてのデータをクラウドに階層化します。これにより、ファイル サーバーのディスク領域を解放します。 他のボリューム/共有から、同期中の現在のボリュームにデータを移動します。 すべてのデータがクラウドに階層化/移行されるまで、手順を 1 つずつ続行します。 2) 一度に 1 つのルート ボリューム (ディスク) をターゲットにします。 クラウドの階層化を使用して、すべてのデータをターゲットの Azure ファイル共有に階層化します。 同期グループからサーバー エンドポイントを削除し、次のルート ボリューム/ディスクを含むエンドポイントを再作成し、同期させます。このプロセスを繰り返します。 注: エージェントの再インストールが必要になる場合があります。 3) 複数のターゲット Azure ファイル共有を使用することをお勧めします (パフォーマンス要件に基づいて同じまたは異なるストレージ アカウント)
2	1 つのボリュームと複数の共有があるファイル サーバーと、同じターゲット Azure ファイル共有 (統合)	はい	登録済みサーバーごとの複数のサーバー エンドポイントを、同じターゲット Azure ファイル共有と同期させることはできません (上記と同じ)	複数の共有または最上位フォルダーを保持しているボリュームのルートを同期させます。 詳しくは、共有のグループ化の概念に関するページと「ボリュームの同期」を参照してください。
3	複数の共有、ボリューム、またはこれらの両方があるファイル サーバーと、1 つのストレージ アカウントの複数の Azure ファイル共有 (1 対 1 の共有マッピング)	はい	1 つの Windows Server インスタンス (またはクラスター) では、最大 30 個の Azure ファイル共有を同期できます。 ストレージ アカウントは、パフォーマンスのためのスケール ターゲットです。 IOPS とスループットは、ファイル共有間で共有されます。 同期グループあたりのアイテム (ファイルとフォルダー) の数は、1 つの共有あたり 1 億個以内にします。 理想的には、1 つの共有あたり 2 千万または 3 千万個未満にするのが最適です。	1) 複数の同期グループを使用します (同期グループの数 = 同期させる先の Azure ファイル共有の数)。 2) このシナリオでは、一度に 30 個の共有のみを同期させることができます。 そのファイル サーバーに 30 を超える共有がある場合は、共有のグループ化の概念に関するページと「ボリュームの同期」を使用して、ソースのルート フォルダーまたは最上位フォルダーの数を減らします。 3) オンプレミスで追加の File Sync サーバーを使用し、それらのサーバーにデータを分割/移動して、ソース Windows サーバーの制限事項に対処します。
4	複数の共有、ボリューム、またはこれらの両方があるファイル サーバーと、異なるストレージ アカウントの複数の Azure ファイル共有 (1 対 1 の共有マッピング)	はい	1 つの Windows Server インスタンス (またはクラスター) を、最大 30 個の Azure ファイル共有と同期させることができます (同じまたは異なるストレージ アカウント)。 同期グループあたりのアイテム (ファイルとフォルダー) の数は、1 つの共有あたり 1 億個以内にします。 理想的には、1 つの共有あたり 2 千万または 3 千万個未満にするのが最適です。	上記と同じ方法
5	1 つのルート ボリュームまたは共有がある複数のファイル サーバーと、同じターゲット Azure ファイル共有 (統合)	いいえ	同期グループでは、別の同期グループで既に構成されているクラウド エンドポイント (Azure ファイル共有) を使用できません。 同期グループでは、異なるファイル サーバーでサーバー エンドポイントを使用できますが、ファイルは区別できません。	"上記のシナリオ # 1 のガイダンスと、一度に 1 つのファイル サーバーをターゲットにする場合の追加の考慮事項に従ってください。"

マッピング テーブルを作成する

前述の情報を使用して、必要な Azure ファイル共有の数を決定し、既存のデータのどの部分がどの Azure ファイル共有に格納されるかを判断します。

必要に応じて参照できるように、自分の考えを記録しておく表を作成します。 一度に多数の Azure リソースをプロビジョニングするときは、マッピング計画の詳細がおろそかになりがちなので、情報が整理された状態を維持することが重要です。 次の Excel ファイルをダウンロードして、マッピングの作成に役立つテンプレートとして使用します。

名前空間マッピング テンプレートをダウンロードします。

Windows ファイル サーバーに関する考慮事項

Windows Server で同期機能を有効にするには、Azure File Sync のダウンロード可能なエージェントをインストールする必要があります。 Azure File Sync エージェントには、2 つの主な構成要素があります。FileSyncSvc.exe は、サーバー エンドポイントの変更の監視と同期セッションの開始を担うバックグラウンド Windows サービスであり、StorageSync.sys はクラウドを使った階層化と迅速なディザスター リカバリーを可能にするファイル システム フィルターです。

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

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

Version	サポートされている SKU	サポートされているデプロイ オプション
Windows Server 2025	Azure、データセンター、Essentials、Standard、IoT	完全およびコア
Windows Server 2022	Azure、データセンター、Essentials、Standard、IoT	完全およびコア
Windows Server 2019	データセンター、Essentials、Standard、IoT	完全およびコア
Windows Server 2016	データセンター、Essentials、Standard、Storage Server	完全およびコア
Windows Server 2012 R2*	データセンター、Essentials、Standard、Storage Server	完全およびコア

* Windows Management Framework (WMF) 5.1 をダウンロードしてインストールする必要があります。 Windows Server 2012 R2 でダウンロードしてインストールする適切なパッケージは、Win8.1AndW2K12R2-KB*******-x64.msu です。

Windows Server の今後のバージョンは、それらがリリースされたときに追加されます。

最小システム リソース

Azure File Sync には、少なくとも 1 つの CPU、少なくとも 2 GiB のメモリ、NTFS ファイル システムでフォーマットされたローカル接続ボリュームを備えたサーバー (物理または仮想) が必要です。

ほとんどの運用ワークロードでは、最小要件のみを使用して Azure File Sync 同期サーバーを構成することはお勧めしません。 詳細については、「推奨されるシステム リソース」を参照してください。

推奨されるシステム リソース

サーバーの機能やアプリケーションと同様に、Azure File Sync のシステム リソース要件は、デプロイの規模によって決まります。サーバー上の大規模なデプロイでは、より多くのシステム リソースが必要になります。 Azure File Sync の場合、スケールは、サーバー エンドポイント全体のオブジェクト数とデータセットのチャーンによって決まります。 1 台のサーバーは複数の同期グループにサーバー エンドポイントを持つことができ、次の表に示すオブジェクトの数では、サーバーが接続されている完全な名前空間が考慮されています。

たとえば、サーバー エンドポイント A (1000 万オブジェクト) + サーバー エンドポイント B (1000 万オブジェクト) = 2000 万オブジェクトです。 その例のデプロイでは、8 個の CPU と、安定状態の場合は 16 GiB メモリ、初期移行の場合は (可能であれば) 48 GiB のメモリが推奨されます。

名前空間データは、パフォーマンス上の理由からメモリに格納されます。 そのため、よいパフォーマンスを維持するには、名前空間が大きいほど多くのメモリが必要であり、チャーンが多いほど処理に必要な CPU が増えます。

次の表では、名前空間のサイズと、一般的な汎用ファイル共有の容量への変換の両方を示してあります。ファイルの平均サイズは 512 KiB です。 ファイル サイズが小さい場合は、同じ容量になるようにメモリを追加することを検討してください。 名前空間のサイズに基づいてメモリを構成します。

名前空間のサイズ - ファイルとディレクトリ (百万)	一般的な容量 (TiB)	CPU コア	推奨されるメモリ (GiB)
3	1.4	2	8 (初期同期)/2 (通常のチャーン)
5	2.3	2	16 (初期同期)/4 (通常のチャーン)
10	4.7	4	32 (初期同期)/8 (通常のチャーン)
30	14.0	8	48 (初期同期)/16 (通常のチャーン)
50	23.3	16	64 (初期同期)/32 (通常のチャーン)
100*	46.6	32	128 (初期同期)/32 (通常のチャーン)

*現時点では、1 億個を超えるファイルとディレクトリを同期することは推奨されていません。 これは、テストされたしきい値に基づくソフト制限です。 詳細については、「Azure File Sync のスケール ターゲット」をご覧ください。

評価コマンドレット

Azure File Sync をデプロイする前に、Azure File Sync 評価コマンドレットを使用して、お使いのシステムと互換性があるかどうかを評価する必要があります。 このコマンドレットでは、サポートされていない文字やサポートされていないオペレーティング システム バージョンなど、ファイル システムとデータセットに関する潜在的な問題をチェックします。 これらのチェックでは、以下で説明する機能のほとんどがカバーされていますが、すべてではありません。デプロイが円滑に進むように、このセクションの残りの部分をよく読むことをお勧めします。

評価コマンドレットをインストールするには、Az PowerShell モジュールをインストールします。これは、次の手順に従ってインストールできます。Azure PowerShell をインストールして構成します。

使用法

複数の方法で評価ツールを呼び出すことができます。システム チェックとデータセット チェックのどちらか一方または両方を行うことができます。 システム チェックとデータセット チェックの両方を実行するには:

Invoke-AzStorageSyncCompatibilityCheck -Path <path>

データセットのみをテストするには:

Invoke-AzStorageSyncCompatibilityCheck -Path <path> -SkipSystemChecks

システム要件のみをテストするには:

Invoke-AzStorageSyncCompatibilityCheck -ComputerName <computer name> -SkipNamespaceChecks

CSV で結果を表示するには:

$validation = Invoke-AzStorageSyncCompatibilityCheck C:\DATA
$validation.Results | Select-Object -Property Type, Path, Level, Description, Result | Export-Csv -Path C:\results.csv -Encoding utf8

ファイル システムの互換性

Azure File Sync は、直接接続された NTFS ボリュームでのみサポートされています。 Windows Server のダイレクト アタッチド ストレージ (DAS) は、Windows Server オペレーティング システムがファイル システムを所有していることを意味します。 DAS は、ディスクをファイル サーバーに物理的に接続すること、仮想ディスクをファイル サーバー VM (Hyper-V によってホストされる VM など) に接続すること、または iSCSI を使用することによって提供されます。

NTFS ボリュームのみがサポートされます。ReFS、FAT、FAT32 およびその他のファイル システムはサポートされていません。

次の表に、NTFS ファイル システムの機能の相互運用の状態を示します。

機能	サポートの状態	Notes
アクセス制御リスト (ACL)	完全にサポートされています	Windows スタイルの随意アクセス制御リストは Azure File Sync に保持され、サーバー エンドポイント上の Windows Server によって適用されます。 Azure ファイル共有を直接マウントするときに ACL を適用することもできますが、これには追加の構成が必要です。 詳細については、ID に関するセクションを参照してください。
ハード リンク	スキップ
シンボリック リンク	スキップ
マウント ポイント	部分的にサポートされています。	マウント ポイントがサーバー エンドポイントのルートである場合がありますが、マウント ポイントがサーバー エンドポイントの名前空間に含まれている場合、マウント ポイントはスキップされます。
接合	スキップ	たとえば、分散ファイル システムの DfrsrPrivate フォルダーや DFSRoots フォルダーなどです。
再解析ポイント	スキップ
NTFS 圧縮	部分的にサポート	システム ボリューム情報 (SVI) ディレクトリが圧縮されているボリュームに配置されたサーバーのエンドポイントは、Azure File Sync でサポートされていません。
スパース ファイル	完全にサポートされています	スパース ファイルは同期されます (ブロックされません) が、完全なファイルとしてクラウドと同期されます。 クラウド内 (または他のサーバー上) のファイルの内容が変更され、変更がダウンロードされると、ファイルはスパースではなくなります。
代替データ ストリーム (ADS)	保持されますが、同期されません	たとえば、ファイル分類インフラストラクチャによって作成された分類タグは同期されません。 各サーバー エンドポイント上のファイルに既存の分類タグは、変更されません。

Azure File Sync は、次のような特定の一時ファイルとシステム フォルダーもスキップします。

ファイル/フォルダー	Note
pagefile.sys	システムに固有のファイル
Desktop.ini	システムに固有のファイル
thumbs.db	サムネイル用の一時ファイル
ehthumbs.db	メディア サムネイル用の一時ファイル
~$*.*	Office の一時ファイル
*.tmp	一時ファイル
*.laccdb	Access データベースのロック ファイル
635D02A9D91C401B97884B82B3BCDAEA.*	内部同期ファイル
\System Volume Information	ボリュームに固有のフォルダー
$RECYCLE.BIN	Folder
\SyncShareState	同期用のフォルダー
.SystemShareInformation	Azure ファイル共有での共有用フォルダー

ローカルディスクで必要な空き領域を検討する

Azure File Sync の使用を計画するときは、サーバー エンドポイントを作成する予定のローカル ディスクでどれだけの空き領域が必要かを考慮してください。

Azure File Sync では、以下のものがローカル ディスク上のスペースを使用することを考慮する必要があります。

• クラウドを使った階層化が有効な場合:

  • 階層化されたファイルの再解析ポイント
  • Azure File Sync メタデータ データベース
  • Azure File Sync heatstore
  • ホットキャッシュに完全にダウンロードされたファイル (存在する場合)
  • ボリュームの空き領域ポリシーの要件

• クラウドを使った階層化が無効な場合:

  • 完全にダウンロードされたファイル
  • Azure File Sync heatstore
  • Azure File Sync メタデータ データベース

ここでは、ローカル ディスクで必要な空き容量を見積もる方法を、例を使って説明します。 たとえば、Azure Windows VM に Azure File Sync エージェントをインストールし、ディスク F にサーバー エンドポイントを作成する予定だとします。ファイル数は 100 万で、そのすべてを階層化します。ディレクトリ数が 10 万、ディスク クラスター サイズは 4 KiB になります。 ディスク サイズは 1000 GiB です クラウドを使った階層化を有効にし、ボリュームの空き領域ポリシーを 20% に設定する必要があります。

1. NTFS は、階層化されたファイルごとにクラスター サイズを割り当てます。 100 万ファイル * 4 KiB クラスター サイズ = 4,000,000 KiB (4 GiB)

   Note

   クラウドを使った階層化を最大限に活用するには、階層化された各ファイルがクラスターを占有するため、より小さい NTFS クラスター サイズ (64 KiB) を使うことをお勧めします。 また、階層化されたファイルによって占有される領域は、NTFS によって割り当てられます。 したがって、UI には表示されません。

2. 同期メタデータは、項目ごとにクラスター サイズを占有します。 (100 万ファイル + 100,000 ディレクトリ) * 4 KiB クラスター サイズ = 4,400,000 KiB (4.4 GiB)
3. Azure File Sync heatstore は、ファイルあたり 1.1 KiB を占有します。 100 万ファイル * 1.1 KiB = 1,100,000 KiB (1.1 GiB)
4. ボリュームの空き領域ポリシーは 20% です。 1000 GiB * 0.2 = 200 GiB

この場合、Azure File Sync には約 209,500,000 KiB (209.5 GiB) の領域が必要になります。 このディスクに必要な空き領域を計算するために望ましい追加の空き領域に、この量を追加します。

フェールオーバー クラスタリング

1. Windows Server フェールオーバー クラスタリングは、Azure ファイル同期の "汎用ファイル サーバー" デプロイ オプションでサポートされています。 フェールオーバー クラスターで "汎用ファイル サーバー" ロールを構成する方法の詳細については、 「2 ノードクラスター化ファイル サーバーのデプロイ」に関する記事を参照してください。
2. Azure File Sync によってサポートされる唯一のシナリオは、クラスター化されたディスクを使用する Windows Server フェールオーバー クラスターです
3. フェールオーバー クラスタリングは、"アプリケーション データ用のスケールアウト ファイル サーバー" (SOFS)、クラスター共有ボリューム (CSV)、またはローカル ディスクではサポートされていません。

データ重複除去

Windows Server 2025、Windows Server 2022、Windows Server 2019、Windows Server 2016
データ重複除去は、Windows Server 2016、 Windows Server 2019、Windows Server 2022 および Windows Server 2025 のボリューム上の 1 つまたは複数のサーバー エンドポイントでクラウドを使った階層化が有効になっているか無効になっているかに関わらず、サポートされています。 クラウドを使った階層化が有効なボリュームでデータ重複除去を有効にすると、より多くのストレージをプロビジョニングしなくても、より多くのファイルをオンプレミスでキャッシュできます。

クラウドを使った階層化が有効なボリュームでデータ重複除去が有効になっている場合、サーバー エンドポイントの場所にある重複除去最適化ファイルは、クラウドを使った階層化のポリシー設定に基づいて、通常のファイルと同様に階層化されます。 重複除去最適化ファイルが階層化された後、データ重複除去ガベージ コレクション ジョブが自動的に実行され、ボリューム上の他のファイルから参照されなくなった不要なチャンクを削除することによって、ディスク領域が解放されます。

ボリュームの節約はサーバーにのみ適用されることに注意してください。Azure ファイル共有内のデータは重複除去されません。

Windows Server 2012 R2
Azure File Sync については、データ重複除去とクラウドを使った階層化は、Windows Server 2012 R2 の同じボリューム上ではサポートされていません。 ボリュームでデータ重複除去が有効になっている場合は、クラウドを使った階層化を無効にする必要があります。

メモ

• Azure File Sync エージェントをインストールする前にデータ重複除去がインストールされている場合、同じボリューム上でのデータ重複除去およびクラウドを使った階層化をサポートするには再起動が必要です。

• クラウドを使った階層化を有効にした後にボリューム上のデータ重複除去を有効にする場合、最初の重複除去最適化ジョブで、そのボリューム上のまだ階層化されていないファイルが最適化され、クラウドを使った階層化に次のような影響を与えます。

  • 空き領域ポリシーに従い、ボリューム上の空き領域に応じて、ヒートマップを使用してファイルが継続的に階層化されます。
  • 重複除去最適化ジョブがファイルにアクセスしているために、本来ならば階層化の対象となっていたかもしれないファイルの階層化が日付ポリシーによってスキップされます。

• 進行中の重複除去最適化ジョブについては、ファイルがまだ階層化されていない場合は、データ ポリシーでのクラウドを使った階層化が、データ重複除去の MinimumFileAgeDays 設定により遅延します。

  • 例:MinimumFileAgeDays 設定が 7 日、クラウドを使った階層化の日付ポリシーが 30 日の場合、日付ポリシーによって 37 日後にファイルが階層化されます。
  • 注:Azure File Sync によってファイルが階層化されると、重複除去最適化ジョブによってそのファイルはスキップされます。

• インストールされている Azure File Sync エージェントを使用して Windows Server 2012 R2 を実行しているサーバーが、Windows Server 2016、Windows Server 2019、Windows Server 2022 または Windows Server 2025 にアップグレードされる場合、同じボリューム上でのデータ重複除去およびクラウドを使った階層化がサポートされるには次の手順を行う必要があります。

  • Windows Server 2012 R2 用の Azure File Sync エージェントをアンインストールして、サーバーを再起動します。
  • 新しいサーバーのオペレーティング システム バージョン用 (Windows Server 2016、Windows Server 2019、Windows Server 2022 または Windows Server 2025) の Azure File Sync エージェントをダウンロードします。
  • Azure File Sync エージェントをインストールして、サーバーを再起動します。

  注:サーバー上の Azure File Sync 構成設定は、エージェントがアンインストールされ再インストールされるときに保持されます。

分散ファイル システム (DFS)

Azure File Sync は、DFS 名前空間 (DFS-N) および DFS レプリケーション (DFS-R) との相互運用をサポートします。

DFS 名前空間 (DFS-N): Azure File Sync は DFS-N 実装で完全にサポートされます。 Azure File Sync エージェントを 1 つ以上のファイル サーバーにインストールして、サーバー エンドポイントとクラウド エンドポイントの間でデータを同期させることができます。その後、DFS-N を使用して名前空間サービスを提供できます。 詳しくは、DFS 名前空間の概要に関するページと、Azure Files での DFS 名前空間に関するページを参照してください。

DFS レプリケーション (DFS-R) :DFS-R と Azure File Sync はどちらもレプリケーション ソリューションなので、ほとんどの場合は、DFS-R を Azure File Sync に置き換えることをお勧めします。ただし、DFS-R と Azure File Sync を併用するのが望ましいシナリオがいくつかあります。

• DFS-R のデプロイから Azure File Sync のデプロイに移行しているとき。 詳しくは、「DFS レプリケーション (DFS-R) のデプロイを Azure File Sync に移行する」をご覧ください。
• ファイル データのコピーが必要なオンプレミスのサーバーの中に、インターネットに直接接続することができないものが含まれる場合。
• ブランチ サーバーが単一のハブ サーバーにデータを統合しており、それに対して Azure File Sync を使いたい場合。

Azure File Sync と DFS-R を併用するには、次のことが必要です。

1. DFS-R でレプリケートされるフォルダーを含むボリュームで、Azure File Sync のクラウドの階層化を無効にする必要があります。
2. DFS-R の読み取り専用レプリケーション フォルダーには、サーバー エンドポイントを構成しないようにする必要があります。
3. DFS-R の場所との重複が可能なサーバー エンドポイントは 1 つだけです。 複数のサーバー エンドポイントが、他のアクティブな DFS-R の場所と重複すると、競合が発生する可能性があります。

詳しくは、DFS レプリケーションの概要に関するページをご覧ください。

Sysprep

Azure File Sync エージェントがインストールされているサーバーでの sysprep の使用はサポートされておらず、予期しない結果になる可能性があります。 エージェントのインストールとサーバーの登録は、サーバー イメージの展開と sysprep ミニ セットアップの完了後に行われます。

Windows Search

クラウドを使った階層化がサーバー エンドポイントで有効になっている場合、階層化されたファイルはスキップされ、Windows Search でインデックス付けされません。 階層化されていないファイルは適切にインデックスが付けられます。

その他の階層型ストレージ管理 (HSM) ソリューション

その他の HSM ソリューションを Azure File Sync で使用することはできません。

パフォーマンスとスケーラビリティ

Azure File Sync エージェントは Azure ファイル共有に接続している Windows Server マシンで実行されているため、実質的な同期パフォーマンスは、Windows Server と基になるディスクの構成、サーバーと Azure Storage の間のネットワーク帯域幅、ファイルのサイズ、データセット全体のサイズ、データセットでのアクティビティなど、お使いのインフラストラクチャの要因によって異なります。 Azure File Sync はファイル レベルで動作するため、Azure File Sync ベースのソリューションのパフォーマンス特性の測定には、1 秒間に処理されたオブジェクト (ファイルとディレクトリ) の数が適しています。

Azure portal または SMB を使用して Azure ファイル共有に加えられた変更は、サーバー エンドポイントに対する変更とは異なり、検出とレプリケーションが即座に行われることはありません。 Azure Files にはまだ変更通知またはジャーナルがないため、ファイルが変更されたときに自動的に同期セッションを開始する方法はありません。 Windows Server では、Azure File Sync は Windows USN ジャーナルを使用して、ファイルが変更されたときに同期セッションを自動的に開始します。

Azure ファイル共有に対する変更を検出するために、Azure File Sync には、変更検出ジョブと呼ばれるスケジュールされたジョブがあります。 変更検出ジョブは、ファイル共有内のすべてのファイルを列挙した後、ファイルの同期バージョンと比較します。 変更検出ジョブによってファイルが変更されていると判断された場合に、Azure File Sync は同期セッションを開始します。 変更検出ジョブは 24 時間ごとに実行されます。 変更検出ジョブは Azure ファイル共有内のすべてのファイルを列挙することで機能するため、変更の検出は、大きな名前空間のほうが小さな名前空間よりも時間がかかります。 大規模な名前空間の場合、変更されたファイルを判断するのに 24 時間ごとに 1 回より長くなる場合があります。

詳細については、「Azure File Sync のパフォーマンス メトリック」と「Azure File Sync のスケール ターゲット」を参照してください。

ID

Azure File Sync は、同期のセットアップ以外に特別な設定を行わなくても、標準の AD ベースの ID で動作します。Azure File Sync を使用する場合に一般的に想定されるのは、ほとんどのアクセスが Azure ファイル共有ではなく、Azure File Sync キャッシュ サーバーを経由することです。 サーバー エンドポイントは Windows Server 上にあり、Windows Server では AD と Windows スタイルの ACL が長い間サポートされてきたため、ストレージ同期サービスに登録されている Windows ファイル サーバーがドメインに参加していることを確認する以外は何も必要ありません。 Azure File Sync では、Azure ファイル共有内のファイルに ACL が格納され、それらはすべてのサーバー エンドポイントにレプリケートされます。

Azure ファイル共有に直接加えられた変更は、同期グループ内のサーバー エンドポイントに同期するのに時間がかかる場合がありますが、ファイル共有に対する AD アクセス許可をクラウドで直接適用できることも確認する必要があります。 これを行うには、Windows ファイル サーバーがドメイン参加しているのと同じように、ストレージ アカウントをオンプレミスの AD にドメイン参加させる必要があります。 お客様が所有する Active Directory へのストレージ アカウントのドメイン参加について詳しくは、Azure Files Active Directory の概要に関するページを参照してください。

ネットワーク

Azure File Sync エージェントは、Azure File Sync REST プロトコルと FileREST プロトコルを使用して、ストレージ同期サービスと Azure ファイル共有と通信します。どちらも、常にポート443 経由で HTTPS を使用します。 SMB は、Windows Server と Azure ファイル共有の間でデータをアップロードまたはダウンロードするために使用されることはありません。 ほとんどの組織では、ほぼすべての Web サイトにアクセスするための要件として、ポート 443 経由の HTTPS トラフィックを許可しているため、通常、Azure File Sync をデプロイするために特別なネットワーク構成は必要ありません。

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

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

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

暗号化

Azure File Sync を使用する場合、Windows Server のストレージの保存時の暗号化、Azure File Sync エージェントと Azure 間での暗号化、Azure ファイル共有のデータの暗号化という、3 つの異なるレベルの暗号化を考慮する必要があります。

Windows Server の保存時の 暗号化

一般的に Azure File Sync で機能する Windows Server 上のデータを暗号化する方法には、ファイル システムとそれに書き込まれたすべてのデータが暗号化されるファイル システムにおける暗号化と、ファイル形式自体での暗号化という、2 つの方法があります。 これらの方法は相互に排他的ではありません。暗号化の目的が異なるため、必要に応じて組み合わせて使用できます。

そのファイル システムにおける暗号化機能を提供するために、Windows Server は BitLocker 受信トレイを提供します。 BitLocker は Azure File Sync に対して完全に透過的です。BitLocker などの暗号化メカニズムを使用する主な理由は、ディスクの盗難によるオンプレミスのデータセンターからの物理的なデータの流出を防ぐことであり、データに無許可の読み書きを行う権限のない OS のサイドローディングを防ぐことです。 BitLocker の詳細については、「BitLocker の概要」を参照してください。

NTFS ボリューム下に配置されるという点で BitLocker と同様に機能するサード パーティ製品は、Azure File Sync で同様に完全に透過的に機能するはずです。

データを暗号化するもう 1 つの主な方法は、アプリケーションがファイルを保存するときにファイルのデータ ストリームを暗号化することです。 アプリケーションによっては、これがネイティブに実行されることもありますが、一般的にはそうではありません。 ファイルのデータ ストリームを暗号化する方法の例としては、Azure Information Protection (AIP)/Azure Rights Management Services (Azure RMS)/Active Directory RMS があります。 AIP/RMS などの暗号化メカニズムを使用する主な理由は、ファイル共有のデータを、誰かがフラッシュ ドライブなどの別の場所にコピーしたり、承認されていないユーザーに電子メールで送信したりすることによって、データがファイル共有から流出することを防ぐためです。 ファイルのデータ ストリームがファイル形式の一部として暗号化されている場合、このファイルは引き続き Azure ファイル共有で暗号化されます。

Azure File Sync は、ファイル システムより上に位置し、ファイルのデータ ストリームの下にある NTFS 暗号化ファイル システム (NTFS EFS) やサード パーティの暗号化ソリューションと相互運用できません。

転送中の暗号化

Azure File Sync エージェントは、Azure File Sync REST プロトコルと FileREST プロトコルを使用して、ストレージ同期サービスと Azure ファイル共有と通信します。どちらも、常にポート443 経由で HTTPS を使用します。 Azure File Sync では、暗号化されていない要求が HTTP 経由で送信されることはありません。

Azure ストレージ アカウントには、転送中の暗号化を要求するスイッチが含まれています。これは既定で有効になっています。 ストレージ アカウント レベルでスイッチが無効になっており、Azure ファイル共有への暗号化されていない接続が可能な場合でも、Azure File Sync は暗号化されたチャネルのみを使用してファイル共有にアクセスします。

ストレージ アカウントの転送中の暗号化を無効にする主な理由は、古いオペレーティング システム (Windows Server 2008 R2 や古い Linux ディストリビューションなど) 上で実行する必要のある、Azure ファイル共有と直接通信するレガシ アプリケーションをサポートするためです。 レガシ アプリケーションとファイル共有の Windows Server キャッシュが通信する場合、この設定を切り替えても効果はありません。

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

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

Azure ファイル共有の保存時の暗号化

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 では、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 の課金について」をご覧ください。

Azure File Sync の利用可能なリージョン

リージョン別の提供状況については、「リージョン別の利用可能な製品」を参照してください。

次のリージョンでは、Azure File Sync を使用する前に、Azure Storage へのアクセス権を要求する必要があります。

• フランス南部
• 南アフリカ西部
• アラブ首長国連邦中部

これらのリージョンへのアクセス権を要求するには、このドキュメントの手順に従ってください。

冗長性

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 として課金されます。

移行

既存の Windows ファイル サーバー 2012R2 以降がある場合は、新しいサーバーにデータを移動しなくても、Azure File Sync を直接インストールすることができます。 Azure File Sync の導入の一環として新しい Windows ファイル サーバーに移行することを計画している場合、または現在データがネットワーク接続ストレージ (NAS) に配置されている場合は、このデータに関して Azure File Sync を使用するいくつかの移行方法が可能です。 どの移行方法を選択するかは、現在データが存在する場所によって異なります。

詳細なガイダンスについては、Azure File Sync と Azure ファイル共有の移行の概要に関する記事を参照してください。

ウイルス対策

ウイルス対策は、ファイルをスキャンして既知の悪意のあるコードを検索することで機能するため、ウイルス対策製品によって階層化されたファイルの再呼び出しが発生することがあります。この結果、エグレス料金が高額になる可能性があります。 階層化されたファイルには、セキュリティ保護された Windows 属性 FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS が設定されています。この属性が設定されたファイルの読み取りをスキップするようにソリューションを構成する方法については、ソフトウェア ベンダーに相談することをお勧めします (多くは自動的に実行されます)。

Microsoft の社内ウイルス対策ソリューションである Windows Defender と System Center Endpoint Protection (SCEP) では、この属性が設定されたファイルの読み取りが自動的にスキップされます。 そのテスト結果として小さな問題点がわかりました。既存の同期グループにサーバーを追加すると、新しいサーバー上で 800 バイト未満のファイルの呼び戻し (ダウンロード) が実行されるという問題です。 このようなファイルは新しいサーバー上に残り、階層化のサイズ要件 (64 KB を超えるサイズ) を満たしていないため、階層化されません。

バックアップ

クラウドを使った階層化が有効になっている場合、サーバー エンドポイント、またはサーバー エンドポイントが配置されている VM を直接バックアップするソリューションは使用しないでください。 クラウドを使った階層化では、データのサブセットのみがサーバー エンドポイントに格納され、完全なデータセットは Azure ファイル共有に保存されます。 使用されるバックアップ ソリューションによっては、階層化されたファイルはスキップされ、バックアップされないか (FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS 属性が設定されているため)、ディスクに再呼び出しされるため、エグレス料金が高額になります。 Azure ファイル共有を直接バックアップするには、クラウド バックアップ ソリューションを使用することをお勧めします。 詳細については、「Azure ファイル共有のバックアップについて」を参照するか、バックアップ プロバイダーに問い合わせて、Azure ファイル共有のバックアップがサポートされているかどうかを確認してください。

オンプレミス バックアップ ソリューションを使用する場合、クラウドを使った階層化が無効な同期グループ内のサーバーに対してバックアップを実行し、階層化されたファイルがないことを確認する必要があります。 復元を実行するときは、ボリューム レベルまたはファイル レベルの復元オプションを使用します。 ファイル レベルの復元オプションを使用して復元されたファイルは、同期グループ内のすべてのエンドポイントに同期され、既存のファイルはバックアップから復元されたバージョンに置き換えられます。 ボリューム レベルの復元では、Azure ファイル共有やその他のサーバー エンドポイントの新しいファイル バージョンは置き換えられません。

データ分類

データ分類ソフトウェアがインストールされている場合、クラウドを使った階層化を有効にすると、次の 2 つの理由によりコストが増加する可能性があります。

1. クラウドを使った階層化を有効にすると、アクセス頻度の高いファイルがローカルにキャッシュされ、アクセス頻度の低いファイルがクラウド内の Azure ファイル共有に階層化されます。 データ分類によってファイル共有内のすべてのファイルが定期的にスキャンされる場合、クラウドに階層化されたファイルは、スキャンされるたびにリコールされる必要があります。

2. データ分類ソフトウェアでファイルのデータ ストリームのメタデータを使用する場合は、ソフトウェアが分類を確認するために、ファイルを完全にリコールする必要があります。

リコールの回数と、リコールされるデータ量の両方の増加のために、コストが増加する可能性があります。

Azure ファイル同期エージェントの更新ポリシー

Azure File Sync エージェントは、新機能の追加や問題の解決を目的として定期的に更新されます。 新しいバージョンが利用可能な場合は、Azure File Sync エージェントの更新をお勧めします。

エージェントのメジャー バージョンとマイナー バージョン

• エージェントのメジャー バージョンには、多くの場合、新しい機能が含まれています。メジャー バージョンでは、バージョン番号の先頭部分の数値が増えていきます。 例: 17.0.0.0
• エージェントのマイナー バージョンは "修正プログラム" とも呼ばれ、メジャー バージョンよりも頻繁にリリースされます。 多くの場合、バグの修正と軽微な機能強化が含まれ、新しい機能は含まれません。 例: 17.2.0.0

アップグレード パス

Azure File Sync エージェントの更新プログラムのインストールを承認してテストする方法は 5 つあります。

1. Azure File Sync エージェント自動アップグレード機能を使用して、エージェントの更新プログラムをインストールします。 Azure File Sync エージェントは自動アップグレードします。 利用可能な場合は最新のエージェント バージョンをインストールするか、現在インストールされているエージェントの有効期限が近づいた時に更新するかを選択できます。 詳細については、「エージェントのライフサイクルの自動管理」を参照してください。
2. エージェントの更新プログラムを自動的にダウンロードしてインストールするように Microsoft Update を構成する。 すべての Azure File Sync の更新プログラムをインストールして、サーバー エージェントの最新の修正を確実に適用することをお勧めします。 Microsoft Update では、更新プログラムのダウンロードとインストールを自動的に実行することで、このプロセスをシームレスにしています。
3. AfsUpdater.exe を使用してエージェントの更新プログラムをダウンロードし、インストールする。 AfsUpdater.exe は、エージェントのインストール ディレクトリにあります。 実行可能ファイルをダブルクリックすると、エージェントの更新プログラムがダウンロードされてインストールされます。 リリース バージョンによっては、サーバーの再起動が必要な場合があります。
4. Microsoft Update 修正プログラム ファイル (.msp 実行可能ファイル) を使用して、既存の Azure File Sync エージェントを修正する。 最新の Azure File Sync 更新プログラム パッケージは、Microsoft Update カタログからダウンロードできます。 .msp 実行可能ファイルを実行すると、Microsoft Update が自動的に使用されたのと同じ方法を使用して、Azure File Sync のインストールがアップグレードされます。 Microsoft Update 修正プログラムを適用すると、Azure File Sync のインストールのインプレース アップグレードが実行されます。
5. Microsoft ダウンロード センターから最新の Azure File Sync エージェント インストーラーをダウンロードします。 既存の Azure File Sync エージェントのインストールをアップグレードするには、古いバージョンをアンインストールした後、ダウンロードしたインストーラーから最新バージョンをインストールします。 サーバーの登録、同期グループ、およびその他の設定は、Azure File Sync インストーラーによって管理されます。

自動エージェントのライフサイクル管理

Azure File Sync エージェントは自動アップグレードします。 2 つのモードのいずれかを選択して、サーバーでアップグレードが試行されるメンテナンス期間を指定できます。 この機能は、エージェントの期限切れを防止する手段を提供するか、面倒な作業なしで最新状態を維持する設定を許可することで、エージェントのライフサイクル管理を支援するように設計されています。

1. 既定の設定では、エージェントの期限切れの防止が試行されます。 示されているエージェントの有効期限の 21 日以内に、エージェントがセルフアップグレードを試行します。 有効期限まで 21 日以内になると週に 1 回、選択されているメンテナンス期間にアップグレードを試行します。 このオプションでは、通常の Microsoft Update 修正プログラムを適用する必要性は解消されません。
2. 必要に応じて、新しいエージェント バージョンが使用可能になるとすぐにエージェントが自動アップグレードされるように選択できます (現在クラスター サーバーには適用できません)。 この更新は、選択されているメンテナンス期間内に行われ、新機能と機能強化が一般提供されるとすぐに、サーバーはそれらの恩恵を受けることができます。 これは安心して利用できる推奨設定であり、エージェントのメジャー バージョンだけでなく定期的な更新プログラムがサーバーに提供されます。 リリースされるすべてのエージェントは GA 品質です。 このオプションを選択すると、Microsoft はお客様に最新のエージェント バージョンをフライト化します。 クラスター化サーバーは除外されます。 フライト化が完了すると、エージェントは Microsoft Update および Microsoft ダウンロード センターでも利用可能になります。

自動アップグレードの設定の変更

次の手順では、インストーラーの完了後に変更を行う必要がある場合に、設定を変更する方法について説明します。

PowerShell コンソールを開き、同期エージェントをインストールしたディレクトリに移動してから、サーバー コマンドレットをインポートします。 これは、既定ではこのようになります。

cd 'C:\Program Files\Azure\StorageSyncAgent'
Import-Module -Name .\StorageSync.Management.ServerCmdlets.dll

Get-StorageSyncAgentAutoUpdatePolicy を実行して、現在のポリシー設定を確認し、変更するかどうかを判断できます。

現在のポリシー設定を遅延更新追跡に変更する場合は、以下を使用できます。

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode UpdateBeforeExpiration

現在のポリシー設定を即時更新追跡に変更する場合は、以下を使用できます

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode InstallLatest -Day <day> -Hour <hour>

エージェントのライフサイクルと変更管理の保証

Azure File Sync は、新機能および機能強化を継続的に導入するするクラウド サービスです。 つまり、Azure File Sync エージェントの特定のバージョンは、一定の期間のみサポートされます。 デプロイを容易にするために、次のルールによって、変更管理プロセス中にエージェントの更新/アップグレードに対応するための十分な時間と通知が保証されます。

• エージェントのメジャー バージョンは、最初のリリースから少なくとも 6 か月間サポートされます。
• エージェントのメジャー バージョン間のサポートは、少なくとも 3 か月間重複することが保証されます。
• 登録済みサーバーに対する警告は、有効期限がまもなく終了することを通知するエージェントを使用して、有効期限の少なくとも 3 か月前に発行されます。 Storage Sync Service の登録済みサーバー セクションで、登録済みサーバーがエージェントの古いバージョンを使用しているかどうかをチェックできます。
• マイナー エージェントの有効期間は、メジャー バージョンに関連付けられています。 たとえば、エージェント バージョン 17.0.0.0 が期限切れに設定されると、エージェント バージョン 17.*.*.* がすべて一緒に期限切れに設定されます。

次のステップ

• ファイアウォールとプロキシの設定の考慮事項
• Azure Files をデプロイする
• Azure File Sync をデプロイする
• Azure File Sync の監視