Azure File Sync のデプロイ

Azure File Sync を使用すると、オンプレミスのファイル サーバーの柔軟性、パフォーマンス、互換性を維持したまま Azure Files で組織のファイル共有を一元化できます。 Azure File Sync により、ご利用の Windows Server が Azure ファイル共有の高速キャッシュに変わります。 SMB、NFS、FTPS など、Windows Server 上で利用できるあらゆるプロトコルを使用して、データにローカルにアクセスできます。 キャッシュは、世界中にいくつでも必要に応じて設置することができます。

この記事に記載されている手順を完了する前に、「Azure Files のデプロイの計画」と「Azure File Sync のデプロイの計画」を読むことを強くお勧めします。

前提条件

  1. Azure File Sync をデプロイするのと同じリージョンに Azure ファイル共有が存在すること。詳細については、以下を参照してください。

  2. ストレージアカウントへの Azure File Sync アクセスを許可するには、次のストレージ アカウント設定を有効にする必要があります:

    • SMB セキュリティ設定 では、 SMB 3.1.1 プロトコル バージョン、 NTLM v2 認証と、 AES-128-GCM 暗号化を許可する必要があります。 ストレージ アカウントの SMB セキュリティ設定を確認するには、「SMB セキュリティ設定」を参照してください。
    • ストレージ アカウント キーのアクセスを許可 するには 有効にする必要があります。 この設定を確認するには、ストレージ アカウントに移動し、設定 セクションで 構成 を選択します。
  3. Azure File Sync と同期する、サポートされている Windows Server の少なくとも 1 つのインスタンス。サポートされる Windows Server のバージョンと推奨されるシステム リソースの詳細については、「Windows ファイル サーバーに関する考慮事項」を参照してください。

  4. 省略可能: Windows Server フェールオーバー クラスターで Azure File Sync を使用する場合は、クラスター内の各ノードに Azure File Sync エージェントをインストールする前に、汎用のファイル サーバー ロールを構成する必要があります。 フェールオーバー クラスターで汎用のファイル サーバー ロールを構成する方法の詳細については、「クラスター化された 2 ノード ファイル サーバーの展開」を参照してください。

    注意

    Azure File Sync によってサポートされる唯一のシナリオは、クラスター化されたディスクを使用する Windows Server フェールオーバー クラスターです。 Azure File Sync については「フェールオーバー クラスタリング」セクションをご覧ください。

  5. クラウド管理は Azure portal で行うことができますが、PowerShell 5.1 または PowerShell 6 以降でローカルで実行することを意図した PowerShell コマンドレットを介して、高度な登録済みサーバー機能が提供されます。 PowerShell 5.1 は、既定で Windows Server 2016 以降に付属しています。 Windows Server 2012 R2 では、$PSVersionTable オブジェクトの PSVersion プロパティの値を調べることによって、少なくとも PowerShell 5.1. を実行していることを確認できます。

    $PSVersionTable.PSVersion
    

    Windows Server 2012 R2 の最新のインストールのように、PSVersion の値が 5.1.* 未満の場合は、Windows Management Framework (WMF) 5.1 をダウンロードしてインストールすることでアップグレードする必要があります。 Windows Server 2012 R2 でダウンロードしてインストールする適切なパッケージは、Win8.1AndW2K12R2-KB*******-x64.msu です。

    PowerShell 6+ は、サポートされているすべてのシステムで使用でき、その GitHub ページ経由でダウンロードできます。

Azure File Sync で使用する Windows Server の準備

フェールオーバー クラスターの各サーバー ノードなど、Azure File Sync で使用する各サーバーで、Internet Explorer セキュリティ強化の構成を無効にします。 これは、初回のサーバー登録でのみ必要です。 サーバーの登録後に再び有効にできます。

Note

Windows Server Core で Azure File Sync をデプロイする場合は、この手順を省略できます。

  1. サーバー マネージャーを開きます。
  2. [ローカル サーバー] をクリックします。
    サーバー マネージャー UI の左側にある [ローカル サーバー]
  3. [プロパティ] サブウィンドウで、 [IE セキュリティ強化の構成] リンクを選択します。
    サーバー マネージャー UI の [IE セキュリティ強化の構成] ペイン
  4. [Internet Explorer セキュリティ強化の構成] ダイアログ ボックスで、 [管理者][ユーザー] の両方で [オフ] を選択します。
    [オフ] が選択された [Internet Explorer セキュリティ強化の構成] ポップアップ ウィンドウ

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

Azure File Sync のデプロイでは最初に、選択したサブスクリプションのリソース グループにストレージ同期サービス リソースを配置します。 必要に応じて、これらをプロビジョニングすることをお勧めします。 後でサーバーとこのリソースの間に信頼関係を作成し、サーバーは 1 つのストレージ同期サービスにのみ登録できます。 そのため、必要な数のストレージ同期サービスをデプロイし、サーバーのグループを分離することをお勧めします。 異なるストレージ同期サービスを使用するサーバー間では同期できないことに注意してください。

Note

ストレージ同期サービスは、デプロイされたサブスクリプションとリソース グループからアクセス許可を継承します。 アクセス権を持つユーザーを慎重に確認することをお勧めします。 書き込みアクセス権を持つエンティティは、このストレージ同期サービスに登録されたサーバーからファイルの新しいセットの同期を開始することができ、それらにアクセスできる Azure Storage にデータが送られます。

ストレージ同期サービスをデプロイするには、Azure portal に移動し、 [リソースの作成] をクリックして、Azure File Sync を検索します。検索結果から [Azure File Sync] を選択した後、 [作成] を選択して [ストレージ同期のデプロイ] タブを開きます。

開いたウィンドウに、次の情報を入力します。

  • Name:ストレージ同期サービスの (リージョンごとに) 一意の名前。
  • サブスクリプション:ストレージ同期サービスを作成するサブスクリプション。 組織の構成方針によっては、1 つ以上のサブスクリプションにアクセスできることがあります。 Azure サブスクリプションは、各クラウド サービス (Azure Files など) に対する課金の最も基本的なコンテナーです。
  • [リソース グループ] :リソース グループは、ストレージ アカウントやストレージ同期サービスなどの Azure リソースの論理グループです。 Azure File Sync 用の新しいリソース グループを作成するか、既存のリソース グループを選択できます (リソース グループをコンテナーとして使用して、組織のリソースを論理的に分離することをお勧めします。たとえば、HR リソースや特定のプロジェクトのリソースをグループ化します)。
  • [場所] :Azure File Sync をデプロイするリージョン。この一覧ではサポートされているリージョンのみを使用できます。

完了したら、 [作成] を選択して、ストレージ同期サービスをデプロイします。

Azure File Sync エージェントをインストールする

Azure File Sync エージェントは、Windows Server を Azure ファイル共有と同期できるようにするダウンロード可能なパッケージです。

このエージェントは、Microsoft ダウンロード センター からダウンロードできます。 ダウンロードが完了したら、MSI パッケージをダブルクリックして Azure File Sync エージェントのインストールを開始します。

重要

フェールオーバー クラスターで Azure File Sync を使用する場合は、クラスターのすべてのノードに Azure File Sync エージェントをインストールする必要があります。 Azure File Sync で動作するようにクラスター内の各ノードを登録する必要があります。

次を実行することをお勧めします。

  • トラブルシューティングとサーバーのメンテナンスを簡素化するために、既定のインストール パス (C:\Program Files\Azure\StorageSyncAgent) をそのまま使用します。
  • Microsoft Update を有効にして、Azure File Sync を最新の状態に保ちます。 機能の更新プログラムと修正プログラムを含め、Azure File Sync エージェントに対するすべての更新が Microsoft Update から実行されます。 最新の更新プログラムを Azure File Sync に適用することをお勧めします。詳細については、Azure File Sync の更新ポリシーに関する記事をご覧ください。

Azure File Sync エージェントのインストールが完了すると、サーバー登録 UI が自動的に開きます。 登録の前にストレージ同期サービスが必要です。ストレージ同期サービスを作成する方法については、次のセクションをご覧ください。

Windows Server をストレージ同期サービスに登録する

Windows Server をストレージ同期サービスに登録すると、サーバー (またはクラスター) とストレージ同期サービスの間に信頼関係が確立されます。 1 つのサーバーは、1 つのストレージ同期サービスにのみ登録でき、同じストレージ同期サービスに関連付けられている他のサーバーおよび Azure ファイル共有と同期できます。

Note

サーバーの登録時には、Azure 資格情報を使ってストレージ同期サービスと Windows Server の間に信頼関係が作成されますが、その後、サーバーは独自の ID を作成して使用します。この ID は、サーバーが登録されていて、現在の Shared Access Signature トークン (ストレージ SAS) が有効な間だけ有効です。 サーバーの登録が解除されるとサーバーに新しい SAS トークンを発行できなくなるので、サーバーは Azure ファイル共有にアクセスできず、すべての同期を停止します。

サーバーを登録する管理者は、特定のストレージ同期サービスに対する所有者または共同作成者の管理ロールのメンバーである必要があります。 これは、Azure portal においてストレージ同期サービスに対する [アクセス制御 (IAM)] で構成できます。

また、サーバーを登録できる管理者と、ストレージ同期サービスで同期を構成することも許可されている管理者を、区別することもできます。 その場合、サーバーの登録のみが許可される管理者の一覧を取得するカスタム ロールを作成し、そのカスタム ロールに次のアクセス許可を付与する必要があります。

  • "Microsoft.StorageSync/storageSyncServices/registeredServers/write"
  • "Microsoft.StorageSync/storageSyncServices/read"
  • "Microsoft.StorageSync/storageSyncServices/workflows/read"
  • "Microsoft.StorageSync/storageSyncServices/workflows/operations/read"

Azure File Sync エージェントがインストールされると、サーバー登録 UI が自動的に開きます。 開かない場合、これを次に示すファイルの場所から手動で開くことができます: C:\Program Files\Azure\StorageSyncAgent\ServerRegistration.exe。 サーバー登録 UI が開いたら、 [サインイン] を選択して開始します。

サインインすると、次の情報の入力を求められます。

サーバー登録 UI のスクリーンショット

  • Azure サブスクリプション: ストレージ同期サービスを含むサブスクリプション (「ストレージ同期サービスのデプロイ」をご覧ください)。
  • リソース グループ:ストレージ同期サービスを含むリソース グループ。
  • ストレージ同期サービス: 登録するストレージ同期サービスの名前。

適切な情報を選択したら、 [登録] を選択してサーバー登録を完了します。 登録プロセスの一環として、追加のサインインを求められます。

同期グループとクラウド エンドポイントを作成する

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

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

重要

同期グループ内の任意のクラウド エンドポイントまたはサーバー エンドポイントで変更を行うことにより、ファイルを同期グループ内の他のエンドポイントに同期できます。 クラウド エンドポイント (Azure ファイル共有) を直接変更した場合、その変更は、Azure File Sync の変更検出ジョブによって最初に認識される必要があります。 クラウド エンドポイントに対する変更検出ジョブは、24 時間に 1 回のみ起動されます。 詳細については、「Azure Files についてよく寄せられる質問 (FAQ)」を参照してください。

クラウド エンドポイントを作成する管理者は、クラウドエンド ポイントで参照されている Azure ファイル共有が含まれるストレージ アカウントの所有者管理ロールのメンバーである必要があります。 これは、Azure portal においてストレージ アカウントに対する [アクセス制御 (IAM)] で構成できます。

同期グループを作成するには、Azure Portal でストレージ同期サービスに移動し、 [+ 同期グループ] を選びます。

Azure Portal で新しい同期グループを作成する

表示されるウィンドウで次の情報を入力して、同期グループとクラウド エンドポイントを作成します。

  • 同期グループ名: 作成する同期グループの名前。 この名前は、ストレージ同期サービス内で一意である必要がありますが、理にかなった任意の名前を指定できます。
  • サブスクリプション:「ストレージ同期サービスのデプロイ」でストレージ同期サービスをデプロイしたサブスクリプション。
  • ストレージ アカウント: [ストレージ アカウントの選択] を選んだ場合は、同期する Azure ファイル共有を持っているストレージ アカウントを選択できる別のウィンドウが表示されます。
  • Azure ファイル共有: 同期する Azure ファイル共有の名前。

サーバー エンドポイントを作成する

サーバー エンドポイントは、登録済みサーバー上の特定の場所を表します。たとえば、サーバー ボリュームのフォルダーなどです。 サーバー エンドポイントは、次の条件に従います。

  • サーバー エンドポイントは (マウントされた共有ではなく) 登録済みサーバー上のパスである必要があります。 ネットワーク接続ストレージ (NAS) はサポートされていません。
  • サーバー エンドポイントがシステム ボリューム上に存在してもかまいませんが、システム ボリューム上のサーバー エンドポイントではクラウド階層化を使用できません。
  • ボリューム上でサーバー エンドポイントを確立した後もパスまたはドライブ文字を変更することはサポートされていません。 登録済みサーバーで最終的なパスを使用していることを確認します。
  • 登録済みサーバーは複数のサーバー エンドポイントをサポートできますが、同期グループには、常に登録済みサーバーあたり 1 つのサーバー エンドポイントしか含めることができません。 同期グループ内のその他のサーバー エンドポイントは、異なる登録済みサーバー上に存在する必要があります。

サーバー エンドポイントを追加するには、新しく作成した同期グループに移動します。 [サーバー エンドポイント] で、[+ サーバー エンドポイントの追加] を選びます。 [サーバー エンドポイントの追加] ブレードが開きます。 次の情報を入力してサーバー エンドポイントを作成します。

[サーバー エンドポイントの追加] ブレードを示すスクリーンショット。

  • 登録済みサーバー: サーバー エンドポイントを作成するサーバーまたはクラスターの名前。
  • パス: Azure ファイル共有に同期する Windows Server 上のパス。 パスには、フォルダー (D:\Data など)、ボリューム ルート (D:\ など)、またはボリューム マウント ポイント (D:\Mount など) を指定できます。
  • クラウドの階層化: クラウドの階層化を有効または無効にするスイッチ。 クラウドの階層化によって、使用頻度やアクセス頻度が低いファイルを Azure Files に階層化できます。 クラウドを使った階層化を有効にする場合は、クール ファイルを階層化するタイミングを Azure File Sync に知らせるために設定するポリシーとして、ボリュームの空き領域ポリシーおよび日付ポリシー の 2 つのポリシーがあります。
    • ボリュームの空き領域: サーバー エンドポイントが配置されているボリュームに確保する空き領域のサイズ。 たとえば、1 つだけのサーバー エンドポイントがあるボリュームでボリュームの空き領域を 50% に設定すると、データの約半量が Azure Files に階層化されます。 クラウドの階層化が有効かどうかにかかわらず、Azure ファイル共有は、データの完全なコピーを常に同期グループ内に保持します。
    • 日付ポリシー: 指定した日数アクセスされていない (これは読み書きされて) ファイルがクラウドに階層化されます。 たとえば、アクセスされずに 15 日以上経過したファイルが通常はアーカイブ ファイルであることがわかった場合は、日付ポリシーを 15 日に設定します。
  • [初期同期]: 同期グループの最初のサーバー エンドポイントでのみ使用できます (1 つの同期グループに複数のサーバー エンドポイントを作成すると、セクションが [初期ダウンロード] に変化します)。 [初期同期] セクション内で、初期アップロード初期ダウンロードのビヘイビアーを選択できます。
    • 初回アップロード: Azure ファイル共有にサーバーが初めてデータをアップロードする方法を選べます。

      • 方法 1: このサーバー パスのコンテンツを Azure ファイル共有内のコンテンツとマージします。 同じ名前とパスのファイルは、コンテンツが異なると競合が生じます。 そのようなファイルは、両方のバージョンが互いに隣り合うように保存されます。 サーバー パスまたは Azure ファイル共有が空の場合は、常にこのオプションを選択してください。
      • 方法 2: Azure ファイル共有内のファイルとフォルダーを、このサーバーのパスにあるコンテンツで強制的に上書きします。 この方法では、ファイルの競合が回避されます。

      詳しくは、初期同期をご覧ください。

    • 初回ダウンロード: Azure ファイル共有からサーバーに初めてデータをダウンロードする方法を選べます。 この設定は、ファイルを含む Azure ファイル共有にサーバーが接続する場合に重要です。 "名前空間" は、ファイルとフォルダーの構造を表します (ファイル コンテンツは含みません)。 "階層化されたファイル" のファイル コンテンツは、ローカル アクセスまたはポリシーによってクラウドからサーバーに回収されます。

      • 方法 1: 最初に名前空間をダウンロードしておき、ローカル ディスクの容量を上限としてファイルのコンテンツをリコールします。
      • 方法 2: 名前空間のみダウンロードします。 ファイルのコンテンツは、実際にアクセスされた時点でリコールされます。
      • 方法 3: 階層化されたファイルを避けます。 ファイルは、完全にダウンロードされてからサーバーに表示されます。

      詳しくは、初期ダウンロードをご覧ください。

サーバー エンドポイントを追加するには、 [作成] を選びます。 Azure ファイル共有と Windows Server でファイルの同期が維持されます。

オプション:ファイアウォールと仮想ネットワークの設定を構成する

ポータル

ファイアウォールと仮想ネットワークの設定で動作するように Azure File Sync を構成したい場合、次の手順を実行します:

  1. Azure portal から、セキュリティを確保するストレージ アカウントに移動します。

  2. 左側のメニューで [ネットワーク] を選択します。

  3. [許可するアクセス元] の下で [選択されたネットワーク] を選択します。

  4. ご利用のサーバーの IP または仮想ネットワークが、 [アドレスの範囲] セクションに一覧表示されていることを確認します。

  5. [信頼された Microsoft サービスによるこのストレージ アカウントに対するアクセスを許可します] チェック ボックスがオンになっていることを確認します。

  6. [Save](保存) を選択して設定を保存します。

    Azure File Sync が動作するようにファイアウォールと仮想ネットワークの設定を構成する

オプション:以前のバージョンおよび VSS (ボリューム シャドウ コピー サービス) を使用するセルフサービス復元

以前のバージョンとは、ボリュームのサーバー側 VSS スナップショットを利用してファイルの復元可能なバージョンを SMB クライアントに提供する、Windows の機能です。 これにより、IT 管理者に復元を依頼しなくても、インフォメーション ワーカーが直接利用できる強力なシナリオが実現します。これは一般に、セルフサービス復元と呼ばれます。

VSS スナップショットと以前のバージョンは、Azure File Sync からは独立して機能します。ただし、クラウドを使った階層化を互換モードに設定する必要があります。 多くの Azure File Sync サーバー エンドポイントが、同じボリューム上に存在できます。 クラウドを使った階層化を使用しているか使用する予定のサーバー エンドポイントが 1 つでもあるボリュームでは、次の PowerShell 呼び出しを実行する必要があります。

Import-Module '<SyncAgentInstallPath>\StorageSync.Management.ServerCmdlets.dll'
Enable-StorageSyncSelfServiceRestore [-DriveLetter] <string> [[-Force]] 

ボリューム全体の VSS スナップショットが作成されます。 既定では、スナップショットを保存する十分なスペースがある場合、特定のボリュームに対して最大で 64 のスナップショットを保持することができます。 VSS はこれを自動的に処理します。 既定のスナップショット スケジュールでは、月曜日から金曜日まで、1 日に 2 つのスナップショットを作成します。 このスケジュールは、Windows のスケジュールされたタスクを使用して構成できます。 上記の PowerShell コマンドレットは、以下の 2 つのことを行います。

  1. 指定されたボリューム上の Azure File Sync のクラウドを使った階層化を以前のバージョンと互換性を持つように構成し、ファイルがサーバー上でクラウドに対して階層化されている場合でも、確実に以前のバージョンから復元できるようにします。
  2. 既定の VSS スケジュールを有効にします。 後で変更することもできます。

Note

注意すべき重要な点が 2 つあります。

  • -Force パラメーターを使用し、かつ VSS が現在有効になっている場合、現在の VSS スナップショット スケジュールは上書きされ、既定のスケジュールで置き換えられます。 コマンドレットを実行する前に、必ずカスタム構成を保存してください。
  • クラスター ノード上でこのコマンドレットを使用している場合、クラスター内の他のすべてのノードでも実行する必要があります。

セルフサービス復元の互換性が有効かどうかを確認するには、次のコマンドレットを実行する必要があります。

Get-StorageSyncSelfServiceRestore [[-Driveletter] <string>]

これにより、サーバー上のすべてのボリュームと、そのそれぞれの、クラウドを使った階層化との互換性が維持される日数の一覧が表示されます。 この日数は、ボリュームごとに可能な最大のスナップショット数と、既定のスナップショット スケジュールに基づいて自動的に計算されます。 そのため既定では、インフォメーション ワーカーに提示されている以前のバージョンはすべて、復元のために使用することができます。 既定のスケジュールを、より多くのスナップショットを作成するように変更する場合も同様です。 ただし、ボリュームで利用可能なスナップショットの中で、互換性が維持される日数の値よりも古いものが生じるようにスケジュールを変更した場合、ユーザーはその古いスナップショット (以前のバージョン) を使用して復元を行うことはできなくなります。

Note

セルフサービス復元を有効にすると、Azure ストレージの使用量と請求に影響があります。 この影響は、現時点でサーバー上で階層化されているファイルだけに限定されます。 この機能を有効にすると、以前のバージョン (VSS スナップショット) のエントリによって参照できる、クラウドで利用可能なファイル バージョンが必ず存在するようになります。

この機能を無効にすると、互換性が維持される日数が経過するまで、Azure ストレージの使用量は徐々に低下していきます。 これを速める方法はありません。

ボリュームごとの既定の VSS スナップショット最大数 (64) とそれを作成する既定のスケジュールでは、インフォメーション ワーカーが以前のバージョンから復元できる最大日数は 45 日間になります (ボリューム上でどれほどの VSS スナップショットを保存できるかによって異なります)。

ボリュームごとの VSS スナップショット最大数として 64 が適切な設定ではない場合、レジストリ キーでその値を変更することができます。 新しい制限値を有効にするには、既に有効にされている、以前のバージョンの互換性を有効にするためのコマンドレットを各ボリュームで再実行する必要があります。ボリュームごとの新しい VSS スナップショット最大数を反映するために、-Force フラグを使用します。 これにより、互換性が維持される日数が新しく計算されます。 この変更は、新しく階層化されたファイルでのみ有効になり、既に実行した VSS スケジュールへのカスタマイズはすべて上書きされることにご注意ください。

VSS スナップショットは、既定ではボリューム領域の最大 10% を消費できます。 VSS スナップショットに使用できるストレージの量を調整するには、vssadmin resize shadowstorage コマンドを使用します。

オプション:新規および変更されたファイルを Azure ファイル共有から事前にリコールする

Azure File Syncは世界各地に分散している企業向けに、ローカル ユーザーがファイルにアクセスする前に、リモート リージョンのサーバー キャッシュを事前に設定しておくことができます。 このモードがサーバーエンド ポイントで有効になっている場合、Azure ファイル共有で作成または変更されたファイルがこのサーバーによって呼び戻されます。

シナリオ

世界各地に分散しているある企業は、米国およびインドにブランチ オフィスを構えています。 朝 (米国時間)、インフォメーション ワーカーが新しいプロジェクト用の新しいフォルダーと新しいファイルを作成し、それらを使用して一日作業しました。 Azure File Sync によって、フォルダーとファイルが Azure ファイル共有 (クラウド エンドポイント) に同期されます。 インドにいるインフォメーション ワーカーは、インドのタイムゾーンでプロジェクトの作業を続行します。 彼らが朝に作業に取り掛かる際、インドにあるローカルの Azure File Sync 対応サーバーでは、インド チームが効率的にローカル キャッシュで作業できるように、これらの新しいファイルがローカルで利用できるようになっている必要があります。 このモードを有効にすることで、オンデマンドの呼び戻しによる最初のファイル アクセスが遅くなることを回避し、Azure ファイル共有でファイルが変更または作成されるとすぐにサーバーによって事前にファイルが呼び戻されるようになります。

重要

ここまで詳細に Azure ファイル共有の変更をサーバー上で追跡すると、エグレス トラフィックとAzure からの請求額が増加する可能性があることを認識することが重要です。 サーバーに呼び戻されたファイルが実際にはローカルで必要でない場合、サーバーへの不要な呼び戻しによって、悪影響を及ぼす可能性があります。 このモードは、クラウドの最近の変更をサーバー上のキャッシュに事前に保存しておくことで、そのサーバー上のファイルを使用しているユーザーやアプリケーションに良い影響を与えることがわかっている場合に使用します。

サーバー エンドポイントで Azure ファイル共有の変更内容を事前に呼び戻すよう有効にする

  1. Azure portal で、ストレージ同期サービスにアクセスし、適切な同期グループを選択して、Azure ファイル共有 (クラウド エンドポイント) で変更を詳細に追跡するサーバー エンドポイントを特定します。
  2. [クラウドを使った階層化] セクションで、"Azure ファイル共有のダウンロード" トピックを探します。 現在選択されているモードが表示され、それを変更して Azure ファイル共有の変更をより詳細に追跡し、サーバーに事前に呼び戻すことができます。

現在有効になっているサーバー エンドポイントにおける Azure ファイル共有のダウンロード動作と、それを変更するためのメニューを開くボタンを示す画像。

オプション:サーバー エンドポイント上の QUIC 経由の SMB

Azure ファイル共有 (クラウド エンドポイント) は、クラウドまたはオンプレミスからの直接アクセスが可能な完全な SMB エンドポイントですが、クラウド側でファイル共有データへのアクセスを希望するお客様は、多くの場合、Azure VM でホストされている Windows Server インスタンスに Azure File Sync サーバー エンドポイントをデプロイします。 Azure ファイル共有に直接アクセスするのではなく、サーバー エンドポイントを追加する最も一般的な理由は、Azure ファイル共有で直接行われた変更が Azure File Sync によって検出されるまでに最大で 24 時間以上かかる場合があるのに対し、サーバー エンドポイントで行われた変更はほぼ直ちに検出され、他のすべてのサーバーとクラウド エンドポイントに同期されることです。

この構成は、ユーザーが自宅や道路から作業している場合など、ユーザーのかなりの割合がオンプレミスでない環境で非常によく見られます。 従来、パブリック インターネットを介して SMB を使用してファイル共有にアクセスすることは、Windows ファイル サーバーまたは Azure Files に直接ホストされているファイル共有の両方を含め、ほとんどの組織と ISP がポート 445 をブロックするため、非常に困難でした。 この制限はプライベート エンドポイントと VPN で回避できますが、Windows Server 2022 Azure Edition には追加のアクセス戦略 (QUIC トランスポート プロトコル経由の SMB) が用意されています。

QUIC 経由の SMB は、ほとんどの組織と ISP が HTTPS トラフィックをサポートするために開いている、ポート 443 経由で通信されます。 QUIC 経由で SMB を使用すると、Windows 11 以上を使用するクライアントが Azure File Sync サーバー エンドポイントでホストされているファイル共有にアクセスするために必要なネットワークが大幅に簡素化されます。 Windows Server Azure Edition で QUIC 経由の SMB をセットアップして構成する方法の詳細については、Windows ファイル サーバーでの QUIC 経由の SMB に関するページを参照してください。

Azure File Sync でのオンボード

Azure File Sync での最初のオンボードで完全なファイル忠実性とアクセス制御リスト (ACL) を維持しながらダウンタイムをゼロにするための推奨手順を以下に示します。

  1. ストレージ同期サービスをデプロイします。
  2. 同期グループを作成します。
  3. 完全なデータ セットがあるサーバーに Azure File Sync エージェントをインストールします。
  4. そのサーバーを登録し、共有にサーバー エンドポイントを作成します。
  5. 同期で、Azure ファイル共有 (クラウド エンドポイント) への完全アップロードを行います。
  6. 初期アップロードが完了したら、残りの各サーバーに Azure File Sync エージェントをインストールします。
  7. 残りの各サーバーに新しいファイル共有を作成します。
  8. 必要に応じて、クラウドの階層化ポリシーを使用して新しいファイル共有にサーバー エンドポイントを作成します。 (この手順では、初期セットアップに使用できる追加のストレージが必要です。)
  9. Azure File Sync エージェントで、実際にデータ転送を行わずに完全な名前空間の迅速な復元を行います。 完全な名前空間の同期後、同期エンジンは、サーバー エンドポイントのクラウドの階層化ポリシーに基づいてローカル ディスク領域を満たします。
  10. 同期の完了を確認した後、必要に応じてトポロジをテストします。
  11. ユーザーとアプリケーションをこの新しい共有にリダイレクトします。
  12. 必要に応じて、サーバー上の重複する共有を削除できます。

別途初期オンボーディング用のストレージがなく、既存の共有にアタッチしたい場合は、ストレージ同期サービスを使用してデータをアップロードする代わりに別のデータ転送ツールを使用して、Azure ファイル共有内のデータを事前シードすることができます。 事前シードのアプローチが推奨されるのは、ダウンタイムを受け入れることができ、初期のオンボード プロセス中にサーバー共有上のデータが変更されないことを確実に保証できる場合のみです。

  1. オンボード プロセス中にいずれのサーバー上のデータも変更されないようにします。
  2. REST 経由での AzCopy または SMB (Robocopy など) で任意のデータ転送ツールを使用してサーバー データを Azure ファイル共有に事前シードします。 Robocopy を使用する場合は、ドメイン ID は使用せず、ストレージ アカウントのアクセス キーを使用して Azure ファイル共有をマウントする必要があります。 AzCopy を使用する場合は、必ず適切なスイッチを設定して、ACL タイムスタンプと属性を保持してください。
  3. 既存の共有を指している目的のサーバー エンドポイントで Azure File Sync トポロジを作成します。
  4. 同期によるすべてのエンドポイントでの調整プロセスを完了します。
  5. 調整が完了したら、変更のために共有を開くことができます。

現時点では、事前シード処理のアプローチにはいくつかの制限があります。

  • 同期トポロジが完全に稼働する前にサーバー上のデータを変更すると、サーバー エンドポイントで競合が発生することがあります。
  • クラウド エンドポイントを作成した後、Azure File Sync は、最初の同期を開始する前にクラウド内のファイルを検出するプロセスを実行します。このプロセスの完了にかかる時間は、ネットワークの速度、使用可能な帯域幅、ファイルとフォルダーの数など、さまざまな要因によって異なります。 プレビュー リリースでの大まかな見積もりでは、検出プロセスは約 10 ファイル/秒で実行されます。そのため、データがクラウドに事前シードされる場合は、事前シード処理の実行が高速であっても、システムが完全に稼働するまでの全体的な時間が大幅に長くなることがあります。

DFS レプリケーション (DFS-R) のデプロイを Azure File Sync に移行する

DFS-R のデプロイを Azure File Sync に移行するには:

  1. 置き換える DFS-R トポロジを表すための同期グループを作成します。
  2. 移行する DFS-R トポロジの完全なデータ セットがあるサーバーで開始します。 そのサーバーに Azure File Sync をインストールします。
  3. そのサーバーを登録し、移行する最初のサーバーのサーバー エンドポイントを作成します。 クラウドの階層化を有効にしないでください。
  4. すべてのデータが Azure ファイル共有 (クラウド エンドポイント) に同期されるようにします。
  5. 残りの各 DFS-R サーバーに、Azure File Sync エージェントをインストールします。
  6. DFS-R を無効にします。
  7. 各 DFS-R サーバーにサーバー エンドポイントを作成します。 クラウドの階層化を有効にしないでください。
  8. 同期の完了を確認した後、必要に応じてトポロジをテストします。
  9. DFS-R の使用を終了します。
  10. 必要に応じて、任意のサーバー エンドポイントでクラウドの階層化を有効にできるようになります。

詳しくは、Azure File Sync と分散ファイル システム (DFS) の相互運用に関するページをご覧ください。

次のステップ