Azure File Sync のデプロイの計画

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 ファイル共有) を直接変更した場合、その変更は、Azure File Sync の変更検出ジョブによって最初に認識される必要があります。 クラウド エンドポイントに対する変更検出ジョブは、24 時間に 1 回のみ起動されます。 詳細については、「Azure Files についてよく寄せられる質問 (FAQ)」を参照してください。

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

前のセクションでは、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 ファイル共有 (同期以外) で直接行われた変更が、より高速に検出、同期されます。

ヒント

ファイルとフォルダーの数が不明な場合は、JAM Software GmbH の TreeSize ツールをぜひご利用ください。

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

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

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

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

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

    理論的には、1 つの標準 Azure ファイル共有により、ストレージ アカウントが提供できる最大パフォーマンスが飽和状態になる可能性があります。 1 つのストレージ アカウントに複数の共有を配置することは、これらの共有について IOPS とスループットの共有プールを作成することを意味します。 これらのファイル共有への Azure File Sync のみのアタッチを計画している場合は、複数の Azure ファイル共有を同じストレージ アカウントにグループ化しても問題は発生しません。 関連メトリックの詳細については、Azure ファイル共有のパフォーマンス ターゲットを参照してください。 これらの制限は、パフォーマンスが明示的にプロビジョニングされ、各共有に対して保証される Premium Storage には適用されません。

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

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

ヒント

この情報を考慮して、ボリューム上の複数のトップレベル フォルダーを共通の新しいルート ディレクトリにグループ化することがしばしば必要になります。 次に、この新しいルート ディレクトリと、その中にグループ化したすべてのフォルダーを、1 つの Azure ファイル共有に同期します。 この手法を使用すると、サーバーあたり 30 個の Azure ファイル共有同期の制限内に抑えることができます。

共通のルートの下でのこのグループ化は、データへのアクセスにはいっさい影響しません。 ACL はそのまま維持されます。 今ここで共通のルートに変更したローカル サーバー フォルダー上に必要共有パス (SMB 共有や NFS 共有など) がある場合に限り、その調整が必要となります。 それ以外の変更はありません。

重要

Azure File Sync の最も重要なスケール ベクターは、同期が必要な項目 (ファイルとフォルダー) の数です。 詳細については、「Azure File Sync のスケール ターゲット」を確認してください。

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

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

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

マッピング テーブルの例を示す図。この画像に記されている内容を体験して使用するには、以下のファイルをダウンロードしてください。

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

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


Excel icon that sets the context for the download. 名前空間マッピング テンプレートをダウンロードします。

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

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

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

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

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

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

重要

Azure File Sync で使用するすべてのサーバーは、Windows Update の最新の更新プログラムを使用して常に最新の状態を保つことをお勧めします。

最小システム リソース

Azure File Sync には、少なくとも 1 つの CPU と最低 2 GiB のメモリを備えたサーバー (物理または仮想) が必要です。

重要

動的メモリを有効にした仮想マシンでサーバーが実行されている場合は、2048 MiB 以上のメモリで VM を構成する必要があります。

ほとんどの運用環境のワークロードでは、最小要件のみを使用して 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 のスケール ターゲット」をご覧ください。

ヒント

名前空間の初期同期は集中的操作であるため、初期同期が完了するまでは、より多くのメモリを割り当てることをお勧めします。 これは必須ではありませんが、初期同期の時間が短くなる場合があります。

通常のチャーンは、1 日に変更される名前空間の 0.5% です。 チャーンのレベルがそれより高い場合は、CPU を追加することを検討してください。

  • NTFS ファイル システムでフォーマットされたローカルに接続されたボリューム。

評価コマンドレット

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 圧縮 完全にサポートされています
スパース ファイル 完全にサポートされています スパース ファイルは同期されます (ブロックされません) が、完全なファイルとしてクラウドと同期されます。 クラウド内 (または他のサーバー上) のファイルの内容が変更され、変更がダウンロードされると、ファイルはスパースではなくなります。
代替データ ストリーム (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 同期用のフォルダー

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

Windows Server フェールオーバー クラスタリングは、Azure ファイル同期の "汎用ファイル サーバー" デプロイ オプションでサポートされています。 フェールオーバー クラスタリングは、"アプリケーション データ用のスケールアウト ファイル サーバー" (SOFS) またはクラスター共有ボリューム (CSV) ではサポートされていません。

注意

同期が適切に機能するには、フェールオーバー クラスターのすべてのノードに Azure File Sync エージェントをインストールする必要があります。

データ重複除去

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

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

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

注意

Windows Server 2019 でクラウドを使った階層化が有効になっているボリュームでデータ重複除去をサポートするには、Windows 更新プログラム KB4520062 - 2019 年 10 月またはそれ以降の月次ロールアップ更新プログラムをインストールする必要があり、Azure File Sync エージェント バージョン 12.0.0.0 以降が必要です。

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 2012 R2 用の Azure File Sync エージェントをアンインストールして、サーバーを再起動します。
    • 新しいサーバーのオペレーティング システム バージョン用 (Windows Server 2016 または Windows Server 2019) の 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 サーバーで完全にサポートされます。 1 つまたは複数の DFS-N メンバーに Azure File Sync をインストールして、サーバー エンドポイントとクラウド エンドポイントの間でデータを同期できます。 詳しくは、「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 の読み取り専用レプリケーション フォルダーには、サーバー エンドポイントを構成しないようにする必要があります。

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

Sysprep

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

クラウドの階層化がサーバー エンドポイントで有効になっている場合、階層化されたファイルはスキップされ、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 を正常にデプロイするために、ストレージ アカウントを Active Directory にドメイン参加させる必要はありません。これは、ユーザーが Azure ファイル共有を直接マウントするときにオンプレミスの ACL を適用することを Azure ファイル共有に許可する、厳密には省略可能な手順です。

ネットワーク

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) やサード パーティの暗号化ソリューションと相互運用できません。

転送中の暗号化

注意

2020 年 8 月 1 日より、Azure File Sync サービスでは TLS 1.0 と 1.1 のサポートが削除されます。 サポートされているすべての Azure File Sync エージェントのバージョンは、既に TLS 1.2 を既定で使用しています。 TLS 1.2 がサーバーで無効になっているか、プロキシが使用されている場合は、以前のバージョンの TLS が使用される可能性があります。 プロキシを使用している場合は、プロキシの構成を確認することをお勧めします。 2020 年 5 月 1 日より後に追加された Azure File Sync サービスのリージョンでは TLS 1.2 のみがサポートされます。TLS 1.0 と 1.1 のサポートは、2020 年 8 月 1 日に既存のリージョンから削除されます。 詳細については、トラブルシューティング ガイドを参照してください。

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 では、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 などのツールを使用することもできます。

GPv2 ストレージ アカウント内にデプロイされたファイル共有は、新しいストレージ アカウントを作成してデータを移行することなく、Standard 層 (トランザクション最適化、ホット、クール) 間で移動できますが、層を変更するとトランザクション コストが発生します。 共有をホットな層からクールな層に移動すると、共有内の各ファイルについてクールな層の書き込みトランザクション料金が発生します。 ファイル共有をクールな層からホットな層に移動すると、共有内の各ファイルについてクールな層の読み込みトランザクション料金が発生します。

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

標準ファイル共有を最大 100 TiB にまたげるようにする

既定では、Standard ファイル共有に使用できるのは最大 5 TiB だけですが、共有の制限は 100 TiB に増やすことができます。 共有の上限を引き上げる方法については、「大きなファイル共有の有効化と作成」を参照してください。

リージョン別の提供状況

100 TiB の容量を持つ Standard ファイル共有には、いくつかの制限事項があります。

  • 現在サポートされているのは、ローカル冗長ストレージ (LRS) アカウントとゾーン冗長ストレージ (ZRS) アカウントだけです。
  • 大きなファイル共有を有効にした後は、ストレージ アカウントを geo 冗長ストレージ (GRS) アカウントや geo ゾーン冗長ストレージ (GZRS) アカウントに変換することはできません。
  • いったん大きなファイル共有を有効にすると、無効にすることはできなくなります。

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

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

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

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

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

冗長性

Azure ファイル共有内のデータを損失や破損から保護するため、すべての Azure ファイル共有では、各ファイルが書き込まれるときに複数のコピーが格納されます。 ワークロードの要件に応じて、冗長性のレベルをさらに高めることができます。 現在、Azure Files では次のデータ冗長性オプションがサポートされています。

  • ローカル冗長: ローカル冗長ストレージ (LRS と呼ばれることもあります) は、すべてのファイルが Azure ストレージ クラスター内に 3 回格納されることを意味します。 これにより、不良ディスク ドライブなどのハードウェア障害によるデータの損失を防ぐことができます。
  • ゾーン冗長: ゾーン冗長ストレージ (ZRS と呼ばれることもあります) は、すべてのファイルが 3 つの異なる Azure ストレージ クラスターに 3 回格納されることを意味します。 ローカル冗長ストレージと同様に、ゾーン冗長では、ファイルごとに 3 つのコピーが用意されます。ただしこれらのコピーは、異なる Azure "可用性ゾーン" の 3 つの独立したストレージ クラスターで物理的に分離されます。 可用性ゾーンは、Azure リージョン内の一意の物理的な場所です。 それぞれのゾーンは、独立した電源、冷却手段、ネットワークを備えた 1 つまたは複数のデータセンターで構成されています。 3 つの可用性ゾーンすべてのストレージ クラスターに書き込まれるまで、ストレージへの書き込みは受け入れられません。
  • geo 冗長: geo 冗長ストレージ (GRS と呼ばれることもあります) では、ローカル冗長ストレージと同じように、プライマリ リージョンの Azure ストレージ クラスター内にファイルが 3 回保存されます。 その後、すべての書き込みが Microsoft で定義されたセカンダリ リージョンに非同期的にレプリケートされます。 geo 冗長ストレージでは、データの 6 つのコピーが 2 つの Azure リージョンに分散して作成されます。 自然災害や他の同様の出来事で Azure リージョンが完全に失われた場合など、重大な障害が発生した場合は、Microsoft によってフェールオーバーが実行され、セカンダリが実質的にプライマリになってすべての操作を提供します。 プライマリ リージョンとセカンダリ リージョンの間のレプリケーションは非同期であるため、重大な障害が発生した場合、セカンダリ リージョンにまだレプリケートされていないデータは失われます。 geo 冗長ストレージ アカウントのフェールオーバーは、手動で実行することもできます。
  • geo ゾーン冗長: geo ゾーン冗長ストレージ (GZRS と呼ばれることもあります) では、ゾーン冗長ストレージと同じように、プライマリ リージョン内の 3 つの異なるストレージ クラスターにファイルが 3 回保存されます。 その後、すべての書き込みが Microsoft で定義されたセカンダリ リージョンに非同期的にレプリケートされます。 geo ゾーン冗長ストレージのフェールオーバー プロセスは、geo 冗長ストレージの場合と同じように動作します。

Standard Azure ファイル共有では 4 種類の冗長性がすべてサポートされていますが、Premium Azure ファイル共有では、ローカル冗長ストレージとゾーン冗長ストレージのみがサポートされています。

汎用バージョン 2 (GPv2) のストレージ アカウントでは、Azure Files ではサポートされていない 2 つの追加の冗長オプションが提供されています。読み取りアクセス geo 冗長ストレージ (RA-GRS と呼ばれることもあります) と、読み取りアクセス geo ゾーン冗長ストレージ (RA-GZRS と呼ばれることもあります) です。 これらのオプション セットを使用して、ストレージ アカウントで Azure ファイル共有をプロビジョニングできますが、Azure Files ではセカンダリ リージョンからの読み取りはサポートされていません。 読み取りアクセス geo 冗長ストレージ アカウントまたは読み取りアクセス geo ゾーン冗長ストレージ アカウントにデプロイされた Azure ファイル共有は、それぞれ、geo 冗長ストレージまたは geo ゾーン冗長ストレージとして課金されます。

重要

Geo 冗長ストレージおよび Geo ゾーン冗長ストレージには、セカンダリ リージョンに手動でストレージをフェールオーバーする機能があります。 データ損失の可能性が高くなるため、Azure File Sync を使用している場合は、障害が発生していない場合にこの操作を行わないことをお勧めします。 ストレージの手動フェールオーバーを開始する必要がある障害が発生した場合は、Azure File Sync でセカンダリ エンドポイントとの同期が再開されるよう、Microsoft のサポートケースを開く必要があります。

移行

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

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

ウイルス対策

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

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

注意

ウイルス対策ソフトウェア ベンダーは、その製品と Azure File Sync との間の互換性を、Azure File Sync Antivirus Compatibility Test Suite を使用して確認することができます。これは、Microsoft ダウンロード センターでダウンロードできます。

バックアップ

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

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

警告

同期元またはターゲット サーバーのいずれかで実行されている Azure File Sync エージェントで Robocopy /B を使用する必要がある場合は、Azure File Sync エージェント バージョン v12.0 以上にアップグレードしてください。 v12.0 よりも前のバージョンのエージェントで Robocopy /B を使用すると、コピー中に階層化されたファイルが破損する可能性があります。

注意

ベアメタル (BMR) 復元は予期しない結果が生じることがあるため、現在サポートされていません。

注意

Azure File Sync エージェントのバージョン 9 では、VSS スナップショット ([以前のバージョン] タブを含む) が、クラウドの階層化が有効なボリュームでサポートされるようになりました。 ただし、PowerShell を使用して以前のバージョンの互換性を有効にする必要があります。 方法については、こちらをご覧ください。

データ分類

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

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

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

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

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

Azure File Sync エージェントは、新機能の追加や問題の解決を目的として定期的に更新されます。 Azure File Sync エージェントの更新プログラムを公開されしだい入手できるように Microsoft Update を構成しておくことをお勧めします。

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

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

アップグレード パス

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

  1. (推奨) エージェントの更新プログラムを自動的にダウンロードしてインストールするように Microsoft Update を構成する。
    すべての Azure File Sync の更新プログラムを実行して、サーバー エージェントの最新の修正を確実に適用することを常にお勧めします。 Microsoft Update では、更新プログラムのダウンロードとインストールを自動的に実行することで、このプロセスをシームレスにしています。
  2. AfsUpdater.exe を使用してエージェントの更新プログラムをダウンロードし、インストールする。
    AfsUpdater.exe は、エージェントのインストール ディレクトリにあります。 実行可能ファイルをダブルクリックすると、エージェントの更新プログラムがダウンロードされてインストールされます。
  3. Microsoft Update 修正プログラム ファイル (.msp 実行可能ファイル) を使用して、既存の Azure File Sync エージェントを修正する。最新の Azure File Sync 更新プログラム パッケージは、Microsoft Update カタログからダウンロードできます。
    .msp 実行可能ファイルを実行すると、前回の更新パスで Microsoft Update によって自動的に使用されたのと同じ方法を使用して、Azure File Sync のインストールがアップグレードされます。 Microsoft Update 修正プログラムを適用すると、Azure File Sync のインストールのインプレース アップグレードが実行されます。
  4. Microsoft ダウンロード センターから 最新の Azure File Sync エージェント インストーラーをダウンロードする。
    既存の Azure File Sync エージェントのインストールをアップグレードするには、古いバージョンをアンインストールした後、ダウンロードしたインストーラーから最新バージョンをインストールします。 サーバーの登録、同期グループ、およびその他の設定は、Azure File Sync インストーラーによって管理されます。

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

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

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

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

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

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

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

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

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode UpdateBeforeExpiration

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

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode InstallLatest

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

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

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

注意

有効期間に関する警告が表示されているエージェントのバージョンをインストールしようとすると、警告が表示されますが、インストールは成功します。 期限切れのエージェントのバージョンのインストールまたはそれを使用した接続は、サポートされていないためにブロックされます。

次のステップ