次の方法で共有


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

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

  • サーバー エンドポイントは (マウントされた共有ではなく) 登録済みサーバー上のパスである必要があります。 ネットワーク接続ストレージ (NAS) はサポートされていません。
  • サーバー エンドポイントがシステム ボリューム上に存在してもかまいませんが、システム ボリューム上のサーバー エンドポイントではクラウドを使った階層化を使用できません。
  • ボリューム上でサーバー エンドポイントを確立した後でパスまたはドライブ文字を変更することはサポートされていません。 サーバー エンドポイントの作成前に、適切なパスを使用していることを確認してください。
  • 登録済みサーバーは複数のサーバー エンドポイントをサポートできますが、同期グループには、常に登録済みサーバーあたり 1 つのサーバー エンドポイントしか含めることができません。 同期グループ内のその他のサーバー エンドポイントは、異なる登録済みサーバー上に存在する必要があります。
  • 名前空間が重複していない場合、各エンドポイントは一意の同期グループに同期していれば、同じボリューム上に複数のサーバー エンドポイントが存在する可能性があります (たとえば、F:\sync1 と F:\sync2 など)。

この記事では、新しいサーバー エンドポイントを作成し、同期を開始するうえで必要となるオプションおよび判断事項について説明します。これらを実際に行うには、Azure File Sync のデプロイの計画を完了し、サーバー エンドポイントの作成のために必要なリソースを前の手順でデプロイ済みである必要があります。

前提条件

サーバー エンドポイントを作成するには、まず次の条件を満たしていることを確認する必要があります。

  • サーバーに Azure ファイル同期エージェントがインストールされ、登録されていること。 Azure File Sync エージェントのインストールの詳細については、Azure File Sync でのサーバーの登録と登録解除に関するページを参照してください。
  • ストレージ同期サービスがデプロイされていること。 ストレージ同期サービスをデプロイする方法の詳細については、Azure File Sync をデプロイする方法に関するページを参照してください。
  • 同期グループがデプロイされていること。 同期グループの作成方法に関するセクションをご覧ください。
  • サーバーがインターネットに接続され、Azure にアクセスできること。 Azure File Sync では、サーバーとクラウド サービスの間の全通信にポート 443 を使用します。
  • エンドポイントの作成で許可された制限内であること。 スケーラビリティとパフォーマンスのターゲットの詳細については、「Azure File Sync のスケール ターゲット」を参照してください。

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

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

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

  • 登録済みサーバー: サーバー エンドポイントを作成するサーバーまたはクラスターの名前。
  • パス: 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 でファイルの同期が維持されます。

Note

Azure Files Sync は、サーバー エンドポイントを作成する前に、Azure ファイル共有のスナップショットをバックアップとして取得します。 このスナップショットを使用して、サーバー エンドポイントが作成される前の状態に共有を復元できます。 スナップショットは、サーバー エンドポイント作成後に自動的に削除されることはないため、不要な場合は手動で削除できます。 Azure File Sync によって作成されたスナップショットを見つけるには、Azure ファイル共有のスナップショットを確認し、[イニシエーター] 列で AzureFileSync を確認します。

[クラウドを使った階層化] セクション

新しいサーバー エンドポイントの作成時には、Azure File Sync のクラウドを使った階層化機能を使用するかどうかを選択できます。[クラウドを使った階層化] セクションのオプションは後で変更可能です。 ただし、以下のセクションで述べる各種オプションを使用できるかどうかは、新しいサーバー ポイントに対してクラウドを使った階層化を有効にするかどうかで決まります。

詳しくは、基本事項、ポリシー、ベスト プラクティスについて解説したこちらのクラウドを使った階層化に関するページを参照してください。

[初期同期] セクション

[初期同期] セクションは、同期グループの最初のサーバー エンドポイントでのみ使用できます。 サーバー エンドポイントを追加する場合は、「[初期ダウンロード] セクション」を参照してください。

初期同期動作には、根本的に異なる 2 つの動作があります。

[マージ]

[Authoritative upload]\(権限のあるアップロード\)

[マージ] は標準オプションであり、既定で選択されています。 特定の移行シナリオの場合を除いて、[マージ] を選択したままにしてください。

  • サーバーの場所に参加する場合、ほとんどのシナリオでは、サーバーの場所またはクラウド共有が空白になっています。 このような場合、[マージ] の動作は適切であり、期待どおりの結果が得られます。
  • 両方の場所にファイルとフォルダーが含まれている場合、名前空間はマージされます。 サーバー上のファイルまたはフォルダ名がクラウド共有上にも存在する場合、同期の競合が発生します。 競合は自動的に解決されます

    [マージ] オプション内で、Azure ファイル共有のコンテンツがサーバーに最初に到達する方法を選択できます。 Azure ファイル共有が空の場合、この選択内容は影響を及ぼしません。 詳細については、「 初期ダウンロード」セクションを参照してください

[Authoritative upload]\(権限のあるアップロード\) は、特定の移行シナリオ専用の初期同期オプションです。 これは、クラウド共有のシード処理にも使用されたのと同じサーバー パスを Azure Data Box と同期します。 この場合、クラウドとサーバーの場所はほとんど同じデータですが、サーバーは少し新しいのですが。 ユーザーは、Data Box の転送中にも変更を行い続けます。 この移行シナリオでは、その後、競合が生じないように、サーバー上の変更内容 (新しい方) に合わせてクラウドをシームレスに更新する必要があります。 そのため、サーバーは名前空間の形状についての権限を持ち、サーバーからの大規模な初期アップロードを避けるために Data Box が使用されます。 クラウド ストレージのシードにオフライン データ転送メカニズムを使用する場合であっても、サーバーの権限のあるアップロードにより、クラウドをダウンタイムなしで導入できます。

[Authoritative upload]\(権限のあるアップロード\) オプションを選択してサーバー エンドポイントをプロビジョニングできるケースは、サーバーの場所にデータが存在する場合のみに限られています。 これは、意図せず誤った構成が行われる事態を防ぐためです。 権限のあるアップロードの動作は、RoboCopy /MIR と同様です。 このモードでは、ソースをターゲットにミラーリングします。 ソースは AFS サーバーで、ターゲットはクラウド共有です。 権限のあるアップロードでは、ターゲットの形状はソースのイメージに合わせて形成されます。

  • 新規作成または更新されたファイルおよびフォルダーはサーバーからアップロードされます。
  • サーバーに存在しない (しなくなった) ファイルとフォルダーは、クラウド共有から削除されます。
  • サーバー上のファイルおよびフォルダーに対するメタデータのみの変更は、メタデータのみの更新として効率的にクラウド共有に反映されます。
  • ファイルとフォルダーは、サーバー上とクラウド共有に存在することがあります。 ただし、Azure ファイル共有のシード以降に、サーバー上で一部のファイルやフォルダーの親ディレクトリが変更されている可能性があります。 これらのファイルやフォルダーは、クラウド共有から削除され、再アップロードされます。 そのため、移行中は、名前空間を大規模に再構築しないようにすることをお勧めします。

[初期ダウンロード] セクション

[初期ダウンロード] セクションは、同期グループの 2 つ目以降のサーバー エンドポイントで使用できます。 同期グループの最初のサーバー エンドポイントには、Azure Data Box を使用した移行に関係する特別なオプションがあります。 これらのオプションは、同期グループ内の最初のサーバー エンドポイントでなければ適用されません。

Note

Azure ファイル共有が空の場合、[初期ダウンロード] オプションを選択しても影響はありません。

このセクションの一環として、Azure ファイル共有のコンテンツがサーバーに最初に到達する方法を選択します。

Azure portal の [サーバー エンドポイントを作成します] ウィザードに含まれるオプションの説明画像。

最初に名前空間をダウンロードする 名前空間のみをダウンロードする 階層化されたファイルを回避する
説明 最初に名前空間全体をダウンロードします。 ファイル コンテンツは、ヒート マップに基づいてサーバーへのバックグラウンド アクティビティとしてクラウドから呼び出されます。これにより、最近アクセスされたデータが早く再呼び出されます。 サーバー ボリュームの空き領域が 10% 未満の場合、残りのファイルは階層化されたファイルのままになります。 名前空間 (ファイルとフォルダーの構造) のみがダウンロードされます。 ファイルコンテンツはサーバーに送信されません。 サーバー上のフォルダーにファイルが表示される前に、各ファイル全体をダウンロードします。 このオプションを使用すると、サーバー上に階層化されたファイルが存在しなくなります。 名前空間の項目とファイル コンテンツは、常に同時に存在します。 
既定の設定 このサーバー エンドポイントに対してクラウドの階層化が有効になっていない場合の既定値。 このサーバー エンドポイントに対してクラウドの階層化が有効になっている場合の既定値。 既定のオプションとして選択されていません。 このオプションは、クラウドの階層化が有効になっていない場合にのみ使用できます。
階層化が有効な場合の動作 クラウドの階層化が有効になっている場合、階層化されたファイルのバックグラウンド呼び出しは、指定されたクラウド階層化ポリシーの条件を満たすとすぐに停止します (存在する場合は、ボリュームフリー ポリシーと日付ポリシーも考慮されます)。 名前空間 (ファイルとフォルダーの構造) のみがダウンロードされます。 ファイルコンテンツはサーバーに送信されません。 オプションは使用できません。
階層化が有効になっていない場合の動作 クラウドの階層化が有効になっていない場合、バックグラウンド呼び戻しを使用してサーバー エンドポイントにすべてのデータを取り消すことが目的です。 すべてのデータに対応できる十分な大きさのボリュームをプロビジョニングする必要があります。 ボリュームに十分な空き領域がない場合、クラウドの階層化が無効になっている場合でも、一部のファイルは階層化された状態で残ります。 名前空間 (ファイルとフォルダーの構造) のみがダウンロードされます。 ファイルコンテンツはサーバーに送信されません。 サーバー上のフォルダーにファイルが表示される前に、各ファイル全体をダウンロードします。
いつ使用するか
  • ユーザーが名前空間のダウンロード後すぐに最近のファイルにすばやくアクセスする必要があり、ほとんどのデータがプロビジョニング時に Azure ファイル共有に存在する場合。 帯域幅が低いお客様は、初期プロビジョニング後のバックグラウンド リコールの恩恵を受ける場合もあります。  階層化されたファイルの再呼び出しの詳細については、「 Azure File Sync 階層化ファイルを管理する方法」を参照してください。
  • ブランチ オフィスの新しいサーバー エンドポイントなど、サーバー パスが空のフォルダーとして開始される Azure File Sync サーバー側のディザスター リカバリー シナリオに最適です。
データの呼び戻し頻度が低い、または少量のデータのみをオンデマンドで呼び出す必要があるアプリケーションに最適です。
  • 階層化に依存せずに、すべてのデータを常にローカルで使用できる必要がある場合。
  • 常にすべてのファイルへのアクセスを必要とするアプリケーションに最適です。
  • データ アクセスのパフォーマンスの問題に階層化されたファイルが必要ない低帯域幅サーバーで便利です。
影響 CPU/メモリは名前空間のスケールに基づいてサイズ変更する必要があり、リソースは I/O パフォーマンスの問題を回避する必要があります。 詳細については、「Azure File Sync の推奨されるシステム リソース」を参照してください。 -
  • ボリュームには、すべてのデータを格納するための十分な領域が必要です。 すべてのファイル コンテンツをダウンロードする必要があるため、最初のダウンロードには時間がかかる可能性があります。
  • 最初の 2 つのオプションよりも低速であるため、高速ディザスター リカバリーには適していません。

初期ダウンロード オプションを選択した後は、サーバー エンドポイントの作成を確認した後で変更することはできません。

Note

サーバー エンドポイントを追加するときに、ファイルが Azure ファイル共有に存在する場合、最初に名前空間をダウンロードすることを選択すると、ファイルはローカルにダウンロードされるまで階層化されて表示されます。 既定では、ネットワーク帯域幅の使用を制限するために、1 つのスレッドを使用してファイルがダウンロードされます。 ファイルのダウンロード パフォーマンスを向上させるには、スレッド数を 1 より大きくして Invoke-StorageSyncFileRecall コマンドレットを使用します。

初期ダウンロード完了後のファイル ダウンロードの動作

初期ダウンロードの完了後のサーバー上でのファイルの表示方法は、クラウドを使った階層化機能を使用しているかどうかと、クラウドの変更の事前リコールを選択しているかどうかで決まります。 後者は、同期グループに地理的な場所の異なるサーバー エンドポイントが複数含まれている場合に有用な機能です。

  • クラウドを使った階層化が有効
    このサーバー エンドポイントでは、他のサーバー エンドポイントの新規ファイルおよび変更済みファイルが階層化されたファイルとして表示されます。 これらの変更は、他のサーバー エンドポイントによる Azure ファイル共有の変更の事前呼び戻しを有効にしている場合のみ、完全なファイルになります。
  • クラウドを使った階層化が無効
    このサーバー エンドポイントでは、他のサーバー エンドポイントの新規ファイルおよび変更済みファイルが完全なファイルとして表示されます。 これらは、最初に階層化されたファイルとして表示されたりその後でリコールされたりすることはありません。 クラウドを使った階層化により階層化されたファイルは、ディザスター リカバリーを高速化するための機能であり、初期プロビジョニング中のみ表示されます。

プロビジョニングの手順

ポータルまたは PowerShell を使用して新しいサーバー エンドポイントが作成されている場合、サーバー エンドポイントをすぐに使用する準備ができていません。 クラウド内の対応するファイル共有に存在するデータの量によっては、サーバー エンドポイントが機能し、使用できる状態になるまでに数分から数時間かかる場合があります。

以前は、サーバー エンドポイントのプロビジョニングの状態と、サーバーが、ユーザーがデータにアクセスする準備ができているかどうかを確認する場合、サーバー エンドポイントにログインして、すべてのデータがダウンロードされたかどうかを確認する必要がありました。 プロビジョニング手順では、サーバー エンドポイントを使用する準備ができているかどうか、および同期が Azure portal から直接完全に機能するかどうかを、サーバー エンドポイントの概要ブレードで把握できます。

サポートされているシナリオでは、[プロビジョニング手順] タブに、サーバー エンドポイントがユーザー アクセスの準備ができている場合など、サーバー エンドポイントで何が起こっているかについての情報が示されます。

サポートされるシナリオ

現在、プロビジョニング手順は、追加される新しいサーバー エンドポイントに、サーバー エンドポイント用に選択されたサーバー パスにデータがない場合にのみ表示されます。 その他のシナリオでは、[プロビジョニング手順] タブは使用できません。

プロビジョニング状態

サーバー エンドポイントのプロビジョニングが進行中の場合に表示されるさまざまな状態とその意味を以下に示します。

  • 進行中: サーバー エンドポイントがユーザー アクセスの準備ができていません。
  • 準備完了 (同期は機能しない): ユーザーはデータにアクセスできますが、変更はクラウド ファイル共有に同期されません。
  • 準備完了 (同期機能): ユーザーはデータにアクセスでき、変更はクラウド共有に同期され、エンドポイントは完全に機能します。
  • 失敗: エラーのため、プロビジョニングに失敗しました。

[プロビジョニング手順] タブは、サポートされているシナリオでのみ Azure portal に表示されます。 サポートされていないシナリオでは使用できないか、表示されません。

次のステップ

Azure ファイル共有と Azure File Sync についてさらに詳しく知る必要があります。次の記事は、高度なオプション、ベスト プラクティス、トラブルシューティングを理解するのに役立ちます。