Azure File Sync のデプロイの計画Planning for an Azure File Sync deployment

Azure File Sync を紹介するインタビューとデモ- クリックして再生Interview and demo introducing Azure File Sync - click to play!

Azure File Sync は、オンプレミスの Windows Server またはクラウド VM に多数の Azure ファイル共有をキャッシュできるサービスです。Azure File Sync is a service that allows you to cache a number of Azure file shares on an on-premises Windows Server or cloud VM.

この記事では、Azure File Sync の概念と機能を紹介します。This article introduces you to Azure File Sync concepts and features. Azure File Sync について理解したら、Azure File Sync デプロイ ガイドに従って、このサービスを試してみることを検討してください。Once you are familiar with Azure File Sync, consider following the Azure File Sync deployment guide to try out this service.

ファイルは Azure ファイル共有のクラウドに格納されます。The files will be stored in the cloud in Azure file shares. Azure ファイル共有は 2 つの方法で使用できます。これらのサーバーレスの Azure ファイル共有 (SMB) を直接マウントするか、Azure File Sync を使用してオンプレミスで Azure ファイル共有をキャッシュします。選択するデプロイ オプションによって、デプロイを計画するときに考慮する必要がある側面が変わります。Azure file shares can be used in two ways: by directly mounting these serverless Azure file shares (SMB) or by caching Azure file shares on-premises using Azure File Sync. Which deployment option you choose changes the aspects you need to consider as you plan for your deployment.

  • Azure ファイル共有を直接マウントする:Azure Files では SMB アクセスが提供されるため、Windows、macOS、および Linux で使用可能な標準的な SMB クライアントを使用して、オンプレミスまたはクラウドで Azure ファイル共有をマウントすることができます。Direct mount of an Azure file share: Since Azure Files provides SMB access, you can mount Azure file shares on-premises or in the cloud using the standard SMB client available in Windows, macOS, and Linux. Azure ファイル共有はサーバーレスであるため、運用環境でデプロイするシナリオでは、ファイル サーバーや NAS デバイスを管理する必要ありません。Because Azure file shares are serverless, deploying for production scenarios does not require managing a file server or NAS device. つまり、ソフトウェアの修正プログラムを適用したり、物理ディスクを交換したりする必要はありません。This means you don't have to apply software patches or swap out physical disks.

  • Azure File Sync を使用したオンプレミスでの Azure ファイル共有のキャッシュ:Azure File Sync を使用すると、オンプレミスのファイル サーバーの柔軟性、パフォーマンス、互換性を維持しながら、Azure Files で組織のファイル共有を一元化できます。Cache Azure file share on-premises with Azure File Sync: Azure File Sync enables you to centralize your organization's file shares in Azure Files, while keeping the flexibility, performance, and compatibility of an on-premises file server. Azure File Sync によって、オンプレミス (またはクラウド) の Windows Server が Azure ファイル共有の高速キャッシュに変換されます。Azure File Sync transforms an on-premises (or cloud) Windows Server into a quick cache of your Azure file share.

管理の概念Management concepts

Azure File Sync のデプロイには、次の 3 つの基本的な管理オブジェクトがあります。An Azure File Sync deployment has three fundamental management objects:

  • Azure ファイル共有: Azure ファイル共有はサーバーレス クラウド ファイル共有であり、Azure File Sync の同期関係のクラウド エンドポイントを提供します。Azure file share: An Azure file share is a serverless cloud file share, which provides the cloud endpoint of an Azure File Sync sync relationship. Azure ファイル共有内のファイルには、SMB または FileREST プロトコルを使用して直接アクセスできます。ただし、Azure ファイル共有が Azure File Sync で使用されている場合は、主に Windows Server キャッシュを介してファイルにアクセスすることをお勧めします。これは、現在 Azure Files には Windows Server のような効率的な変更検出メカニズムがないため、Azure ファイル共有に直接加えた変更がサーバー エンドポイントに反映されるまでに時間がかかるためです。Files in an Azure file share can be accessed directly with SMB or the FileREST protocol, although we encourage you to primarily access the files through the Windows Server cache when the Azure file share is being used with Azure File Sync. This is because Azure Files today lacks an efficient change detection mechanism like Windows Server has, so changes to the Azure file share directly will take time to propagate back to the server endpoints.
  • サーバー エンドポイント:Azure ファイル共有に同期されている Windows Server 上のパス。Server endpoint: The path on the Windows Server that is being synced to an Azure file share. これには、ボリューム上の特定のフォルダー、またはボリュームのルートを指定できます。This can be a specific folder on a volume or the root of the volume. 名前空間が重複していなければ、同じボリューム上に複数のサーバー エンドポイントが存在できます。Multiple server endpoints can exist on the same volume if their namespaces do not overlap.
  • 同期グループ:クラウド エンドポイント、Azure ファイル共有、およびサーバー エンドポイント間の同期関係を定義するオブジェクト。Sync group: The object that defines the sync relationship between a cloud endpoint, or Azure file share, and a server endpoint. 同期グループ内のエンドポイントは、相互に同期を維持されます。Endpoints within a sync group are kept in sync with each other. たとえば、Azure File Sync で管理するファイル セットが 2 組ある場合、2 つの同期グループを作成し、各同期グループに別のエンドポイントを追加します。If for example, you have two distinct sets of files that you want to manage with Azure File Sync, you would create two sync groups and add different endpoints to each sync group.

Azure ファイル共有の管理の概念Azure file share management concepts

Azure ファイル共有は、ストレージの共有プールを表す最上位オブジェクトである "ストレージ アカウント" にデプロイされます。Azure file shares are deployed into storage accounts, which are top-level objects that represent a shared pool of storage. このストレージのプールを使用すると、複数のファイル共有だけでなく、BLOB コンテナー、キュー、テーブルなどの他のストレージ リソースもデプロイできます。This pool of storage can be used to deploy multiple file shares, as well as other storage resources such as blob containers, queues, or tables. ストレージ アカウントにデプロイされているすべてのストレージ リソースにより、そのストレージ アカウントに適用される制限が共有されます。All storage resources that are deployed into a storage account share the limits that apply to that storage account. ストレージ アカウントの現在の制限を確認するには、「Azure Files のスケーラビリティおよびパフォーマンスのターゲット」をご覧ください。To see the current limits for a storage account, see Azure Files scalability and performance targets.

Azure Files のデプロイに使用するストレージ アカウントには、主に次の 2 種類があります。There are two main types of storage accounts you will use for Azure Files deployments:

  • 汎用バージョン 2 (GPv2) ストレージ アカウント: GPv2 ストレージ アカウントを使うと、Standard のハード ディスク ベース (HDD ベース) のハードウェアに、Azure ファイル共有をデプロイできます。General purpose version 2 (GPv2) storage accounts: GPv2 storage accounts allow you to deploy Azure file shares on standard/hard disk-based (HDD-based) hardware. GPv2 ストレージ アカウントでは、Azure ファイル共有を格納するだけでなく、BLOB コンテナー、キュー、テーブルなどの他のストレージ リソースを格納することもできます。In addition to storing Azure file shares, GPv2 storage accounts can store other storage resources such as blob containers, queues, or tables.
  • FileStorage ストレージ アカウント:FileStorage ストレージ アカウントを使うと、Premium のソリッドステート ディスク ベース (SSD ベース) のハードウェアに、Azure ファイル共有をデプロイできます。FileStorage storage accounts: FileStorage storage accounts allow you to deploy Azure file shares on premium/solid-state disk-based (SSD-based) hardware. FileStorage アカウントは、Azure ファイル共有を格納するためにのみ使用できます。FileStorage アカウントでその他のストレージ リソース (BLOB コンテナー、キュー、テーブルなど) をデプロイすることはできません。FileStorage accounts can only be used to store Azure file shares; no other storage resources (blob containers, queues, tables, etc.) can be deployed in a FileStorage account.

Azure portal、PowerShell、CLI では、他にもいくつかの種類のストレージ アカウントを使用できます。There are several other storage account types you may come across in the Azure portal, PowerShell, or CLI. BlockBlobStorage と BlobStorage の 2 種類のストレージ アカウントには、Azure ファイル共有を格納できません。Two storage account types, BlockBlobStorage and BlobStorage storage accounts, cannot contain Azure file shares. 他の 2 つのストレージ アカウントの種類は、汎用バージョン 1 (GPv1) ストレージ アカウントと従来のストレージ アカウントであり、どちらも Azure ファイル共有を格納できます。The other two storage account types you may see are general purpose version 1 (GPv1) and classic storage accounts, both of which can contain Azure file shares. GPv1 と従来のストレージ アカウントには Azure ファイル共有を格納できますが、Azure Files のほとんどの新機能は、GPv2 ストレージ アカウントと FileStorage ストレージ アカウントでのみ使用できます。Although GPv1 and classic storage accounts may contain Azure file shares, most new features of Azure Files are available only in GPv2 and FileStorage storage accounts. そのため、新しいデプロイには GPv2 と FileStorage ストレージ アカウントのみを使用し、GPv1 と従来のストレージ アカウントが環境に既に存在する場合はアップグレードすることをお勧めします。We therefore recommend to only use GPv2 and FileStorage storage accounts for new deployments, and to upgrade GPv1 and classic storage accounts if they already exist in your environment.

Azure File Sync の管理の概念Azure File Sync management concepts

同期グループは、ストレージ同期サービスにデプロイされます。これは、Azure File Sync で使用するサーバーを登録する最上位のオブジェクトで、同期グループのリレーションシップが含まれています。Sync groups are deployed into Storage Sync Services, which are top-level objects that register servers for use with Azure File Sync and contain the sync group relationships. ストレージ同期サービス リソースは、ストレージ アカウント リソースのピアであり、同じように Azure リソース グループにデプロイできます。The Storage Sync Service resource is a peer of the storage account resource, and can similarly be deployed to Azure resource groups. ストレージ同期サービスでは、複数のストレージ アカウントと複数の登録済み Windows サーバー間で Azure ファイル共有を含む同期グループを作成できます。A Storage Sync Service can create sync groups that contain Azure file shares across multiple storage accounts and multiple registered Windows Servers.

ストレージ同期サービスで同期グループを作成する前に、まずストレージ同期サービスで Windows Server を登録する必要があります。Before you can create a sync group in a Storage Sync Service, you must first register a Windows Server with the Storage Sync Service. これにより、登録済みサーバー オブジェクトが作成され、これはサーバー (またはクラスター) とストレージ同期サービス間の信頼関係を表します。This creates a registered server object, which represents a trust relationship between your server or cluster and the Storage Sync Service. ストレージ同期サービスを登録するには、まずサーバーに Azure File Sync エージェントをインストールする必要があります。To register a Storage Sync Service, you must first install the Azure File Sync agent on the server. 個々のサーバーまたはクラスターは、同時に 1 つのストレージ同期サービスのみに登録できます。An individual server or cluster can be registered with only one Storage Sync Service at a time.

同期グループには、1 つのクラウド エンドポイント (Azure ファイル共有) と 1 つ以上のサーバー エンドポイントが含まれます。A sync group contains one cloud endpoint, or Azure file share, and at least one server endpoint. サーバー エンドポイント オブジェクトには、クラウドを使った階層化機能を構成する設定が含まれています。これにより Azure File Sync のキャッシュ機能が提供されます。Azure ファイル共有と同期するには、Azure ファイル共有を含むストレージ アカウントが、ストレージ同期サービスと同じ Azure リージョンに存在している必要があります。The server endpoint object contains the settings that configure the cloud tiering capability, which provides the caching capability of Azure File Sync. In order to sync with an Azure file share, the storage account containing the Azure file share must be in the same Azure region as the Storage Sync Service.

管理ガイダンスManagement guidance

Azure File Sync をデプロイする場合は、次のことをお勧めします。When deploying Azure File Sync, we recommend:

  • Windows ファイル共有で Azure ファイル共有 1:1 をデプロイします。Deploying Azure file shares 1:1 with Windows file shares. サーバー エンドポイント オブジェクトを使用すると、同期関係のサーバー側で同期トポロジを設定する方法において、高い柔軟性を発揮します。The server endpoint object gives you a great degree of flexibility on how you set up the sync topology on the server-side of the sync relationship. 管理を簡略化するには、サーバー エンドポイントのパスを Windows ファイル共有のパスと一致させます。To simplify management, make the path of the server endpoint match the path of the Windows file share.

  • 使用するストレージ同期サービスは、出来る限り最小限に抑えます。Use as few Storage Sync Services as possible. これにより、Windows Server は一度に 1 つのストレージ同期サービスにしか登録できないため、複数のサーバー エンドポイントを含む同期グループがある場合の管理が簡単になります。This will simplify management when you have sync groups that contain multiple server endpoints, since a Windows Server can only be registered to one Storage Sync Service at a time.

  • Azure ファイル共有をデプロイする際には、ストレージ アカウントの IOPS 制限に注意してください。Paying attention to a storage account's IOPS limitations when deploying Azure file shares. ファイル共有をストレージ アカウントに 1:1 でマップするのが理想的ですが、これは、組織と Azure の両方からのさまざまな制限や制約により、実現できない場合もあります。Ideally, you would map file shares 1:1 with storage accounts, however this may not always be possible due to various limits and restrictions, both from your organization and from Azure. 1 つのストレージ アカウントに 1 つのファイル共有のみをデプロイすることができない場合は、使用頻度が高い共有と低い共有を考慮し、最もホットなファイル共有が同じストレージ アカウントに一緒に配置されないようにしてください。When it is not possible to have only one file share deployed in one storage account, consider which shares will be highly active and which shares will be less active to ensure that the hottest file shares don't get put in the same storage account together.

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

Windows Server で同期機能を有効にするには、Azure File Sync のダウンロード可能なエージェントをインストールする必要があります。To enable the sync capability on Windows Server, you must install the Azure File Sync downloadable agent. Azure File Sync エージェントには、2 つの主な構成要素があります。FileSyncSvc.exe は、サーバー エンドポイントの変更の監視と同期セッションの開始を担当するバックグラウンド Windows サービスであり、StorageSync.sys はクラウドの階層化と迅速なディザスター リカバリーを可能にするファイル システム フィルターです。The Azure File Sync agent provides two main components: FileSyncSvc.exe, the background Windows service that is responsible for monitoring changes on the server endpoints and initiating sync sessions, and StorageSync.sys, a file system filter that enables cloud tiering and fast disaster recovery.

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

Azure File Sync は、次のバージョンの Windows Server でサポートされています。Azure File Sync is supported with the following versions of Windows Server:

VersionVersion サポートされている SKUSupported SKUs サポートされているデプロイ オプションSupported deployment options
Windows Server 2019Windows Server 2019 Datacenter、Standard、および IoTDatacenter, Standard, and IoT 完全およびコアFull and Core
Windows Server 2016Windows Server 2016 Datacenter、Standard、および Storage ServerDatacenter, Standard, and Storage Server 完全およびコアFull and Core
Windows Server 2012 R2Windows Server 2012 R2 Datacenter、Standard、および Storage ServerDatacenter, Standard, and Storage Server 完全およびコアFull and Core

Windows Server の今後のバージョンは、それらがリリースされたときに追加されます。Future versions of Windows Server will be added as they are released.

重要

Azure File Sync で使用するすべてのサーバーは、Windows Update の最新の更新プログラムを使用して常に最新の状態を保つことをお勧めします。We recommend keeping all servers that you use with Azure File Sync up to date with the latest updates from Windows Update.

最小システム リソースMinimum system resources

Azure File Sync には、少なくとも 1 つの CPU と最低 2 GiB のメモリを備えたサーバー (物理または仮想) が必要です。Azure File Sync requires a server, either physical or virtual, with at least one CPU and a minimum of 2 GiB of memory.

重要

動的メモリを有効にした仮想マシンでサーバーが実行されている場合は、2048 MiB 以上のメモリで VM を構成する必要があります。If the server is running in a virtual machine with dynamic memory enabled, the VM should be configured with a minimum of 2048 MiB of memory.

ほとんどの運用環境のワークロードでは、最小要件のみを使用して Azure File Sync 同期サーバーを構成することはお勧めしません。For most production workloads, we do not recommend configuring an Azure File Sync sync server with only the minimum requirements. 詳細については、「推奨されるシステム リソース」を参照してください。See Recommended system resources for more information.

サーバーの機能やアプリケーションと同様に、Azure File Sync のシステム リソース要件は、デプロイの規模によって決まります。サーバー上の大規模なデプロイでは、より多くのシステム リソースが必要になります。Just like any server feature or application, the system resource requirements for Azure File Sync are determined by the scale of the deployment; larger deployments on a server require greater system resources. Azure File Sync の場合、スケールは、サーバー エンドポイント全体のオブジェクト数とデータセットのチャーンによって決まります。For Azure File Sync, scale is determined by the number of objects across the server endpoints and the churn on the dataset. 1 台のサーバーは複数の同期グループにサーバー エンドポイントを持つことができ、次の表に示すオブジェクトの数では、サーバーが接続されている完全な名前空間が考慮されています。A single server can have server endpoints in multiple sync groups and the number of objects listed in the following table accounts for the full namespace that a server is attached to.

たとえば、サーバー エンドポイント A (1000 万オブジェクト) + サーバー エンドポイント B (1000 万オブジェクト) = 2000 万オブジェクトです。For example, server endpoint A with 10 million objects + server endpoint B with 10 million objects = 20 million objects. その例のデプロイでは、8 個の CPU と、安定状態の場合は 16 GiB メモリ、初期移行の場合は (可能であれば) 48 GiB のメモリが推奨されます。For that example deployment, we would recommend 8 CPUs, 16 GiB of memory for steady state, and (if possible) 48 GiB of memory for the initial migration.

名前空間データは、パフォーマンス上の理由からメモリに格納されます。Namespace data is stored in memory for performance reasons. そのため、よいパフォーマンスを維持するには、名前空間が大きいほど多くのメモリが必要であり、チャーンが多いほど処理に必要な CPU が増えます。Because of that, bigger namespaces require more memory to maintain good performance, and more churn requires more CPU to process.

次の表では、名前空間のサイズと、一般的な汎用ファイル共有の容量への変換の両方を示してあります。ファイルの平均サイズは 512 KiB です。In the following table, we have provided both the size of the namespace as well as a conversion to capacity for typical general purpose file shares, where the average file size is 512 KiB. ファイル サイズが小さい場合は、同じ容量になるようにメモリを追加することを検討してください。If your file sizes are smaller, consider adding additional memory for the same amount of capacity. 名前空間のサイズに基づいてメモリを構成します。Base your memory configuration on the size of the namespace.

名前空間のサイズ - ファイルとディレクトリ (百万)Namespace size - files & directories (millions) 一般的な容量 (TiB)Typical capacity (TiB) CPU コアCPU Cores 推奨されるメモリ (GiB)Recommended memory (GiB)
33 1.41.4 22 8 (初期同期)/2 (通常のチャーン)8 (initial sync)/ 2 (typical churn)
55 2.32.3 22 16 (初期同期)/4 (通常のチャーン)16 (initial sync)/ 4 (typical churn)
1010 4.74.7 44 32 (初期同期)/8 (通常のチャーン)32 (initial sync)/ 8 (typical churn)
3030 14.014.0 88 48 (初期同期)/16 (通常のチャーン)48 (initial sync)/ 16 (typical churn)
5050 23.323.3 1616 64 (初期同期)/32 (通常のチャーン)64 (initial sync)/ 32 (typical churn)
100*100* 46.646.6 3232 128 (初期同期)/32 (通常のチャーン)128 (initial sync)/ 32 (typical churn)

*現時点では、1 億を超えるファイルとディレクトリを同期することは推奨されていません。*Syncing more than 100 million files & directories is not recommended at this time. これは、テストされたしきい値に基づくソフト制限です。This is a soft limit based on our tested thresholds. 詳細については、「Azure Files のスケーラビリティおよびパフォーマンスのターゲット」を参照してください。For more information, see Azure Files scalability and performance targets.

ヒント

名前空間の初期同期は集中的操作であるため、初期同期が完了するまでは、より多くのメモリを割り当てることをお勧めします。Initial synchronization of a namespace is an intensive operation and we recommend allocating more memory until initial synchronization is complete. これは必須ではありませんが、初期同期の時間が短くなる場合があります。This isn't required but, may speed up initial sync.

通常のチャーンは、1 日に変更される名前空間の 0.5% です。Typical churn is 0.5% of the namespace changing per day. チャーンのレベルがそれより高い場合は、CPU を追加することを検討してください。For higher levels of churn, consider adding more CPU.

  • NTFS ファイル システムでフォーマットされたローカルに接続されたボリューム。A locally attached volume formatted with the NTFS file system.

評価コマンドレットEvaluation cmdlet

Azure File Sync をデプロイする前に、Azure File Sync 評価コマンドレットを使用して、お使いのシステムと互換性があるかどうかを評価する必要があります。Before deploying Azure File Sync, you should evaluate whether it is compatible with your system using the Azure File Sync evaluation cmdlet. このコマンドレットでは、サポートされていない文字やサポートされていないオペレーティング システム バージョンなど、ファイル システムとデータセットに関する潜在的な問題をチェックします。This cmdlet checks for potential issues with your file system and dataset, such as unsupported characters or an unsupported operating system version. そのチェックでは、以下で説明する機能のほとんどがカバーされていますが、すべてではありません。デプロイが円滑に進むように、このセクションの残りの部分をよく読むことをお勧めします。Its checks cover most but not all of the features mentioned below; we recommend you read through the rest of this section carefully to ensure your deployment goes smoothly.

評価コマンドレットをインストールするには、Az PowerShell モジュールをインストールします。これは、次の手順に従ってインストールできます。Azure PowerShell をインストールして構成します。The evaluation cmdlet can be installed by installing the Az PowerShell module, which can be installed by following the instructions here: Install and configure Azure PowerShell.

使用法Usage

複数の方法で評価ツールを呼び出すことができます。システム チェックとデータセット チェックのどちらか一方または両方を行うことができます。You can invoke the evaluation tool in a few different ways: you can perform the system checks, the dataset checks, or both. システム チェックとデータセット チェックの両方を実行するには:To perform both the system and dataset checks:

Invoke-AzStorageSyncCompatibilityCheck -Path <path>

データセットのみをテストするには:To test only your dataset:

Invoke-AzStorageSyncCompatibilityCheck -Path <path> -SkipSystemChecks

システム要件のみをテストするには:To test system requirements only:

Invoke-AzStorageSyncCompatibilityCheck -ComputerName <computer name> -SkipNamespaceChecks

CSV で結果を表示するには:To display the results in CSV:

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

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

Azure File Sync は、直接接続された NTFS ボリュームでのみサポートされています。Azure File Sync is only supported on directly attached, NTFS volumes. Windows Server のダイレクト アタッチド ストレージ (DAS) は、Windows Server オペレーティング システムがファイル システムを所有していることを意味します。Direct attached storage, or DAS, on Windows Server means that the Windows Server operating system owns the file system. DAS は、ディスクをファイル サーバーに物理的に接続すること、仮想ディスクをファイル サーバー VM (Hyper-V によってホストされる VM など) に接続すること、または ISCSI を使用して提供されます。DAS can be provided through physically attaching disks to the file server, attaching virtual disks to a file server VM (such as a VM hosted by Hyper-V), or even through ISCSI.

NTFS ボリュームのみがサポートされます。ReFS、FAT、FAT32 およびその他のファイル システムはサポートされていません。Only NTFS volumes are supported; ReFS, FAT, FAT32, and other file systems are not supported.

次の表に、NTFS ファイル システムの機能の相互運用の状態を示します。The following table shows the interop state of NTFS file system features:

特徴量Feature サポートの状態Support status NotesNotes
アクセス制御リスト (ACL)Access control lists (ACLs) 完全にサポートされていますFully supported Windows スタイルの随意アクセス制御リストは Azure File Sync に保持され、サーバー エンドポイント上の Windows Server によって適用されます。Windows-style discretionary access control lists are preserved by Azure File Sync, and are enforced by Windows Server on server endpoints. Azure ファイル共有を直接マウントするときに ACL を適用することもできますが、これには追加の構成が必要です。ACLs can also be enforced when directly mounting the Azure file share, however this requires additional configuration. 詳細については、ID に関するセクションを参照してください。See the Identity section for more information.
ハード リンクHard links スキップSkipped
シンボリック リンクSymbolic links スキップSkipped
マウント ポイントMount points 部分的にサポートされています。Partially supported マウント ポイントがサーバー エンドポイントのルートである場合がありますが、マウント ポイントがサーバー エンドポイントの名前空間に含まれている場合、マウント ポイントはスキップされます。Mount points might be the root of a server endpoint, but they are skipped if they are contained in a server endpoint's namespace.
接合Junctions スキップSkipped たとえば、分散ファイル システムの DfrsrPrivate フォルダーや DFSRoots フォルダーなどです。For example, Distributed File System DfrsrPrivate and DFSRoots folders.
再解析ポイントReparse points スキップSkipped
NTFS 圧縮NTFS compression 完全にサポートされていますFully supported
スパース ファイルSparse files 完全にサポートされていますFully supported スパース ファイルは同期されます (ブロックされません) が、完全なファイルとしてクラウドと同期されます。Sparse files sync (are not blocked), but they sync to the cloud as a full file. クラウド内 (または他のサーバー上) のファイルの内容が変更され、変更がダウンロードされると、ファイルはスパースではなくなります。If the file contents change in the cloud (or on another server), the file is no longer sparse when the change is downloaded.
代替データ ストリーム (ADS)Alternate Data Streams (ADS) 保持されますが、同期されませんPreserved, but not synced たとえば、ファイル分類インフラストラクチャによって作成された分類タグは同期されません。For example, classification tags created by the File Classification Infrastructure are not synced. 各サーバー エンドポイント上のファイルに既存の分類タグは、変更されません。Existing classification tags on files on each of the server endpoints are left untouched.

Azure File Sync は、次のような特定の一時ファイルとシステム フォルダーもスキップします。Azure File Sync will also skip certain temporary files and system folders:

ファイル/フォルダーFile/folder NoteNote
pagefile.syspagefile.sys システムに固有のファイルFile specific to system
Desktop.iniDesktop.ini システムに固有のファイルFile specific to system
thumbs.dbthumbs.db サムネイル用の一時ファイルTemporary file for thumbnails
ehthumbs.dbehthumbs.db メディア サムネイル用の一時ファイルTemporary file for media thumbnails
~$*.*~$*.* Office の一時ファイルOffice temporary file
*.tmp*.tmp 一時ファイルTemporary file
*.laccdb*.laccdb Access データベースのロック ファイルAccess DB locking file
635D02A9D91C401B97884B82B3BCDAEA.*635D02A9D91C401B97884B82B3BCDAEA.* 内部の同期ファイルInternal Sync file
\System Volume Information\System Volume Information ボリュームに固有のフォルダーFolder specific to volume
$RECYCLE.BIN$RECYCLE.BIN FolderFolder
\SyncShareState\SyncShareState 同期用のフォルダーFolder for Sync

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

Windows Server フェールオーバー クラスタリングは、Azure ファイル同期の "汎用ファイル サーバー" デプロイ オプションでサポートされています。Windows Server Failover Clustering is supported by Azure File Sync for the "File Server for general use" deployment option. フェールオーバー クラスタリングは、"アプリケーション データ用のスケールアウト ファイル サーバー" (SOFS) またはクラスター共有ボリューム (CSV) ではサポートされていません。Failover Clustering is not supported on "Scale-Out File Server for application data" (SOFS) or on Clustered Shared Volumes (CSVs).

注意

同期が適切に機能するには、フェールオーバー クラスターのすべてのノードに Azure File Sync エージェントをインストールする必要があります。The Azure File Sync agent must be installed on every node in a Failover Cluster for sync to work correctly.

データ重複除去Data Deduplication

Windows Server 2016 および Windows Server 2019 Windows Server 2016 and Windows Server 2019
データ重複除去は、Windows Server 2016 および Windows Server 2019 でクラウドを使った階層化が有効になっているボリュームでサポートされます。Data Deduplication is supported on volumes with cloud tiering enabled on Windows Server 2016 and Windows Server 2019. クラウドを使った階層化が有効なボリュームでデータ重複除去を有効にすると、より多くのストレージをプロビジョニングしなくても、より多くのファイルをオンプレミスでキャッシュできます。Enabling Data Deduplication on a volume with cloud tiering enabled lets you cache more files on-premises without provisioning more storage.

クラウドを使った階層化が有効なボリュームでデータ重複除去が有効になっている場合、サーバー エンドポイントの場所にある重複除去最適化ファイルは、クラウドを使った階層化のポリシー設定に基づいて、通常のファイルと同様に階層化されます。When Data Deduplication is enabled on a volume with cloud tiering enabled, Dedup optimized files within the server endpoint location will be tiered similar to a normal file based on the cloud tiering policy settings. 重複除去最適化ファイルが階層化された後、データ重複除去ガベージ コレクション ジョブが自動的に実行され、ボリューム上の他のファイルから参照されなくなった不要なチャンクを削除することによって、ディスク領域が解放されます。Once the Dedup optimized files have been tiered, the Data Deduplication garbage collection job will run automatically to reclaim disk space by removing unnecessary chunks that are no longer referenced by other files on the volume.

ボリュームの節約はサーバーにのみ適用されることに注意してください。Azure ファイル共有内のデータは重複除去されません。Note the volume savings only apply to the server; your data in the Azure file share will not be deduped.

注意

Windows Server 2019 でクラウドを使った階層化が有効になっているボリュームでデータ重複除去をサポートするには、Windows 更新プログラム KB4520062 をインストールし、Azure File Sync エージェント バージョン 9.0.0.0 以降が必要です。To support Data Deduplication on volumes with cloud tiering enabled on Windows Server 2019, Windows update KB4520062 must be installed and Azure File Sync agent version 9.0.0.0 or newer is required.

Windows Server 2012 R2Windows Server 2012 R2
Azure File Sync については、データ重複除去とクラウドを使った階層化は、Windows Server 2012 R2 の同じボリューム上ではサポートされていません。Azure File Sync does not support Data Deduplication and cloud tiering on the same volume on Windows Server 2012 R2. ボリュームでデータ重複除去が有効になっている場合は、クラウドを使った階層化を無効にする必要があります。If Data Deduplication is enabled on a volume, cloud tiering must be disabled.

メモNotes

  • Azure File Sync エージェントをインストールする前にデータ重複除去がインストールされている場合、同じボリューム上でのデータ重複除去およびクラウドを使った階層化をサポートするには再起動が必要です。If Data Deduplication is installed prior to installing the Azure File Sync agent, a restart is required to support Data Deduplication and cloud tiering on the same volume.

  • クラウドを使った階層化を有効にした後にボリューム上のデータ重複除去を有効にする場合、最初の重複除去最適化ジョブで、そのボリューム上のまだ階層化されていないファイルが最適化され、クラウドを使った階層化に次のような影響を与えます。If Data Deduplication is enabled on a volume after cloud tiering is enabled, the initial Deduplication optimization job will optimize files on the volume that are not already tiered and will have the following impact on cloud tiering:

    • 空き領域ポリシーに従い、ボリューム上の空き領域に応じて、ヒートマップを使用してファイルが継続的に階層化されます。Free space policy will continue to tier files as per the free space on the volume by using the heatmap.
    • 重複除去最適化ジョブがファイルにアクセスしているために、本来ならば階層化の対象となっていたかもしれないファイルの階層化が日付ポリシーによってスキップされます。Date policy will skip tiering of files that may have been otherwise eligible for tiering due to the Deduplication optimization job accessing the files.
  • 進行中の重複除去最適化ジョブについては、ファイルがまだ階層化されていない場合は、データ ポリシーでのクラウドを使った階層化が、データ重複除去の MinimumFileAgeDays 設定により遅延します。For ongoing Deduplication optimization jobs, cloud tiering with date policy will get delayed by the Data Deduplication MinimumFileAgeDays setting, if the file is not already tiered.

    • 例:MinimumFileAgeDays 設定が 7 日、クラウドを使った階層化の日付ポリシーが 30 日の場合、日付ポリシーによって 37 日後にファイルが階層化されます。Example: If the MinimumFileAgeDays setting is seven days and cloud tiering date policy is 30 days, the date policy will tier files after 37 days.
    • 注:Azure File Sync によってファイルが階層化されると、重複除去最適化ジョブによってそのファイルはスキップされます。Note: Once a file is tiered by Azure File Sync, the Deduplication optimization job will skip the file.
  • インストールされている Azure File Sync エージェントを使用して Windows Server 2012 R2 を実行しているサーバーが、Windows Server 2016 または Windows Server 2019 にアップグレードされる場合、同じボリューム上でのデータ重複除去およびクラウドを使った階層化がサポートされるには次の手順を行う必要があります。If a server running Windows Server 2012 R2 with the Azure File Sync agent installed is upgraded to Windows Server 2016 or Windows Server 2019, the following steps must be performed to support Data Deduplication and cloud tiering on the same volume:

    • Windows Server 2012 R2 用の Azure File Sync エージェントをアンインストールして、サーバーを再起動します。Uninstall the Azure File Sync agent for Windows Server 2012 R2 and restart the server.
    • 新しいサーバーのオペレーティング システム バージョン用 (Windows Server 2016 または Windows Server 2019) の Azure File Sync エージェントをダウンロードします。Download the Azure File Sync agent for the new server operating system version (Windows Server 2016 or Windows Server 2019).
    • Azure File Sync エージェントをインストールして、サーバーを再起動します。Install the Azure File Sync agent and restart the server.

    注:サーバー上の Azure File Sync 構成設定は、エージェントがアンインストールされ再インストールされるときに保持されます。Note: The Azure File Sync configuration settings on the server are retained when the agent is uninstalled and reinstalled.

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

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

DFS 名前空間 (DFS-N) :Azure File Sync は DFS-N サーバーで完全にサポートされます。DFS Namespaces (DFS-N): Azure File Sync is fully supported on DFS-N servers. 1 つまたは複数の DFS-N メンバーに Azure File Sync をインストールして、サーバー エンドポイントとクラウド エンドポイントの間でデータを同期できます。You can install the Azure File Sync agent on one or more DFS-N members to sync data between the server endpoints and the cloud endpoint. 詳しくは、「DFS 名前空間の概要」をご覧ください。For more information, see DFS Namespaces overview.

DFS レプリケーション (DFS-R) :DFS-R と Azure File Sync はどちらもレプリケーション ソリューションなので、ほとんどの場合は、DFS-R を Azure File Sync に置き換えることをお勧めします。ただし、DFS-R と Azure File Sync を併用するのが望ましいシナリオがいくつかあります。DFS Replication (DFS-R): Since DFS-R and Azure File Sync are both replication solutions, in most cases, we recommend replacing DFS-R with Azure File Sync. There are however several scenarios where you would want to use DFS-R and Azure File Sync together:

  • DFS-R のデプロイから Azure File Sync のデプロイに移行しているとき。You are migrating from a DFS-R deployment to an Azure File Sync deployment. 詳しくは、「DFS レプリケーション (DFS-R) のデプロイを Azure File Sync に移行する」をご覧ください。For more information, see Migrate a DFS Replication (DFS-R) deployment to Azure File Sync.
  • ファイル データのコピーが必要なオンプレミスのサーバーの中に、インターネットに直接接続することができないものが含まれる場合。Not every on-premises server that needs a copy of your file data can be connected directly to the internet.
  • ブランチ サーバーが単一のハブ サーバーにデータを統合しており、それに対して Azure File Sync を使いたい場合。Branch servers consolidate data onto a single hub server, for which you would like to use Azure File Sync.

Azure File Sync と DFS-R を併用するには、次のことが必要です。For Azure File Sync and DFS-R to work side by side:

  1. DFS-R でレプリケートされるフォルダーを含むボリュームで、Azure File Sync のクラウドの階層化を無効にする必要があります。Azure File Sync cloud tiering must be disabled on volumes with DFS-R replicated folders.
  2. DFS-R の読み取り専用レプリケーション フォルダーには、サーバー エンドポイントを構成しないようにする必要があります。Server endpoints should not be configured on DFS-R read-only replication folders.

詳しくは、DFS レプリケーションの概要に関するページをご覧ください。For more information, see DFS Replication overview.

SysprepSysprep

Azure File Sync エージェントがインストールされているサーバー上で sysprep を使用することはサポートされていません。予期しない結果になる可能性があります。Using sysprep on a server that has the Azure File Sync agent installed is not supported and can lead to unexpected results. エージェントのインストールとサーバーの登録は、サーバー イメージの展開と sysprep ミニ セットアップの完了後に行われます。Agent installation and server registration should occur after deploying the server image and completing sysprep mini-setup.

クラウドの階層化がサーバー エンドポイントで有効になっている場合、階層化されたファイルはスキップされ、Windows Search によってインデックスが付けられます。If cloud tiering is enabled on a server endpoint, files that are tiered are skipped and not indexed by Windows Search. 階層化されていないファイルは適切にインデックスが付けられます。Non-tiered files are indexed properly.

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

その他の HSM ソリューションを Azure File Sync で使用することはできません。No other HSM solutions should be used with Azure File Sync.

IDIdentity

Azure File Sync は、同期のセットアップ以外に特別な設定を行わなくても、標準の AD ベースの ID で動作します。Azure File Sync を使用する場合に一般的に想定されるのは、ほとんどのアクセスが Azure ファイル共有ではなく、Azure File Sync キャッシュ サーバーを経由することです。Azure File Sync works with your standard AD-based identity without any special setup beyond setting up sync. When you are using Azure File Sync, the general expectation is that most accesses go through the Azure File Sync caching servers, rather than through the Azure file share. サーバー エンドポイントは Windows Server 上にあり、Windows Server では AD と Windows スタイルの ACL が長い間サポートされてきたため、ストレージ同期サービスに登録されている Windows ファイル サーバーがドメインに参加していることを確認する以外は何も必要ありません。Since the server endpoints are located on Windows Server, and Windows Server has supported AD and Windows-style ACLs for a long time, nothing is needed beyond ensuring the Windows file servers registered with the Storage Sync Service are domain joined. Azure File Sync では、Azure ファイル共有内のファイルに ACL が格納され、それらはすべてのサーバー エンドポイントにレプリケートされます。Azure File Sync will store ACLs on the files in the Azure file share, and will replicate them to all server endpoints.

Azure ファイル共有に直接加えられた変更は、同期グループ内のサーバー エンドポイントに同期するのに時間がかかる場合がありますが、ファイル共有に対する AD アクセス許可をクラウドで直接適用できることも確認する必要があります。Even though changes made directly to the Azure file share will take longer to sync to the server endpoints in the sync group, you may also want to ensure that you can enforce your AD permissions on your file share directly in the cloud as well. これを行うには、Windows ファイル サーバーがドメイン参加しているのと同じように、ストレージ アカウントをオンプレミスの AD にドメイン参加させる必要があります。To do this, you must domain join your storage account to your on-premises AD, just like how your Windows file servers are domain joined. お客様が所有する Active Directory へのストレージ アカウントのドメイン参加について詳しくは、Azure Files Active Directory の概要に関するページを参照してください。To learn more about domain joining your storage account to a customer-owned Active Directory, see Azure Files Active Directory overview.

重要

Azure File Sync を正常にデプロイするために、ストレージ アカウントを Active Directory にドメイン参加させる必要はありません。これは、ユーザーが Azure ファイル共有を直接マウントするときにオンプレミスの ACL を適用することを Azure ファイル共有に許可する、厳密には省略可能な手順です。Domain joining your storage account to Active Directory is not required to successfully deploy Azure File Sync. This is a strictly optional step that allows the Azure file share to enforce on-premises ACLs when users mount the Azure file share directly.

ネットワークNetworking

Azure File Sync エージェントは、Azure File Sync REST プロトコルと FileREST プロトコルを使用して、ストレージ同期サービスと Azure ファイル共有と通信します。どちらも、常にポート443 経由で HTTPS を使用します。The Azure File Sync agent communicates with your Storage Sync Service and Azure file share using the Azure File Sync REST protocol and the FileREST protocol, both of which always use HTTPS over port 443. SMB は、Windows Server と Azure ファイル共有の間でデータをアップロードまたはダウンロードするために使用されることはありません。SMB is never used to upload or download data between your Windows Server and the Azure file share. ほとんどの組織では、ほぼすべての Web サイトにアクセスするための要件として、ポート 443 経由の HTTPS トラフィックを許可しているため、通常、Azure File Sync をデプロイするために特別なネットワーク構成は必要ありません。Because most organizations allow HTTPS traffic over port 443, as a requirement for visiting most websites, special networking configuration is usually not required to deploy Azure File Sync.

組織のポリシーまたは独自の規制要件に基づいて、Azure とのより制限的な通信が必要になる可能性があります。そのため、Azure File Sync は、ネットワークを構成するためのいくつかのメカニズムを提供します。Based on your organization's policy or unique regulatory requirements, you may require more restrictive communication with Azure, and therefore Azure File Sync provides several mechanisms for you configure networking. 要件に応じて、次のことができます。Based on your requirements, you can:

  • ExpressRoute または Azure VPN 経由のトンネル同期とファイルのアップロードまたはダウンロード トラフィック。Tunnel sync and file upload/download traffic over your ExpressRoute or Azure VPN.
  • Azure Files と Azure のネットワーク機能 (サービス エンドポイント、プライベート エンドポイントなど) の使用。Make use of Azure Files and Azure Networking features such as service endpoints and private endpoints.
  • お使いの環境でプロキシをサポートするよう Azure File Sync を構成。Configure Azure File Sync to support your proxy in your environment.
  • Azure File Sync からネットワーク アクティビティを調整。Throttle network activity from Azure File Sync.

Azure File Sync とネットワークの詳細については、「Azure File Sync のネットワークに関する考慮事項」を参照してください。To learn more about Azure File Sync and networking, see Azure File Sync networking considerations.

暗号化Encryption

Azure File Sync を使用する場合、Windows Server のストレージの保存時の暗号化、Azure File Sync エージェントと Azure 間での暗号化、Azure ファイル共有のデータの暗号化という、3 つの異なるレベルの暗号化を考慮する必要があります。When using Azure File Sync, there are three different layers of encryption to consider: encryption on the at-rest storage of Windows Server, encryption in transit between the Azure File Sync agent and Azure, and encryption at rest of your data in the Azure file share.

Windows Server の保存時の 暗号化Windows Server encryption at rest

一般的に Azure File Sync で機能する Windows Server 上のデータを暗号化する方法には、ファイル システムとそれに書き込まれたすべてのデータが暗号化されるファイル システムにおける暗号化と、ファイル形式自体での暗号化という、2 つの方法があります。There are two strategies for encrypting data on Windows Server that work generally with Azure File Sync: encryption beneath the file system such that the file system and all of the data written to it is encrypted, and encryption within the file format itself. これらのメソッドは相互に排他的ではありません。暗号化の目的が異なるため、必要に応じて組み合わせて使用できます。These methods are not mutually exclusive; they can be used together if desired since the purpose of encryption is different.

そのファイル システムにおける暗号化機能を提供するために、Windows Server は BitLocker 受信トレイを提供します。To provide encryption beneath the file system, Windows Server provides BitLocker inbox. BitLocker は Azure File Sync に対して完全に透過的です。BitLocker などの暗号化メカニズムを使用する主な理由は、ディスクの盗難によるオンプレミスのデータセンターからの物理的なデータの流出を防ぎ、権限のない OS によってデータへの不正読み取り、または不正書き込みが行われるのを防ぐためです。BitLocker is fully transparent to Azure File Sync. The primary reason to use an encryption mechanism like BitLocker is to prevent physical exfiltration of data from your on-premises datacenter by someone stealing the disks and to prevent sideloading an unauthorized OS to perform unauthorized reads/writes to your data. BitLocker の詳細については、「BitLocker の概要」を参照してください。To learn more about BitLocker, see BitLocker overview.

NTFS ボリューム下に配置されるという点で BitLocker と同様に機能するサード パーティ製品は、Azure File Sync で同様に完全に透過的に機能するはずです。Third-party products that work similarly to BitLocker, in that they sit beneath the NTFS volume, should similarly work fully transparently with Azure File Sync.

データを暗号化するもう 1 つの主な方法は、アプリケーションがファイルを保存するときにファイルのデータ ストリームを暗号化することです。The other main method for encrypting data is to encrypt the file's data stream when the application saves the file. アプリケーションによっては、これがネイティブに実行されることもありますが、一般的にはそうではありません。Some applications may do this natively, however this is usually not the case. ファイルのデータ ストリームを暗号化する方法の例としては、Azure Information Protection (AIP)/Azure Rights Management Services (Azure RMS)/Active Directory RMS があります。An example of a method for encrypting the file's data stream is Azure Information Protection (AIP)/Azure Rights Management Services (Azure RMS)/Active Directory RMS. AIP/RMS などの暗号化メカニズムを使用する主な理由は、ファイル共有のデータを、誰かがフラッシュ ドライブなどの別の場所にコピーしたり、承認されていないユーザーに電子メールで送信したりすることによって、データがファイル共有から流出することを防ぐためです。The primary reason to use an encryption mechanism like AIP/RMS is to prevent data exfiltration of data from your file share by people copying it to alternate locations, like to a flash drive, or emailing it to an unauthorized person. ファイルのデータ ストリームがファイル形式の一部として暗号化されている場合、このファイルは引き続き Azure ファイル共有で暗号化されます。When a file's data stream is encrypted as part of the file format, this file will continue to be encrypted on the Azure file share.

Azure File Sync は、ファイル システムより上に位置し、ファイルのデータ ストリームの下にある NTFS 暗号化ファイル システム (NTFS EFS) やサード パーティの暗号化ソリューションと相互運用できません。Azure File Sync does not interoperate with NTFS Encrypted File System (NTFS EFS) or third-party encryption solutions that sit above the file system but below the file's data stream.

転送中の暗号化Encryption in transit

注意

2020 年 8 月 1 日より、Azure File Sync サービスでは TLS 1.0 と 1.1 のサポートが削除されます。Azure File Sync service will remove support for TLS1.0 and 1.1 on August 1st, 2020. サポートされているすべての Azure File Sync エージェントのバージョンは、既に TLS 1.2 を既定で使用しています。All supported Azure File Sync agent versions already use TLS1.2 by default. TLS 1.2 がサーバーで無効になっているか、プロキシが使用されている場合は、以前のバージョンの TLS が使用される可能性があります。Using an earlier version of TLS could occur if TLS1.2 was disabled on your server or a proxy is used. プロキシを使用している場合は、プロキシの構成を確認することをお勧めします。If you are using a proxy, we recommend you check the proxy configuration. 2020 年 5 月 1 日より後に追加された Azure File Sync サービスのリージョンでは TLS 1.2 のみがサポートされます。TLS 1.0 と 1.1 のサポートは、2020 年 8 月 1 日に既存のリージョンから削除されます。Azure File Sync service regions added after 5/1/2020 will only support TLS1.2 and support for TLS1.0 and 1.1 will be removed from existing regions on August 1st, 2020. 詳細については、トラブルシューティング ガイドを参照してください。For more information, see the troubleshooting guide.

Azure File Sync エージェントは、Azure File Sync REST プロトコルと FileREST プロトコルを使用して、ストレージ同期サービスと Azure ファイル共有と通信します。どちらも、常にポート443 経由で HTTPS を使用します。Azure File Sync agent communicates with your Storage Sync Service and Azure file share using the Azure File Sync REST protocol and the FileREST protocol, both of which always use HTTPS over port 443. Azure File Sync では、暗号化されていない要求が HTTP 経由で送信されることはありません。Azure File Sync does not send unencrypted requests over HTTP.

Azure ストレージ アカウントには、転送中の暗号化を要求するスイッチが含まれています。これは既定で有効になっています。Azure storage accounts contain a switch for requiring encryption in transit, which is enabled by default. ストレージ アカウント レベルでスイッチが無効になっており、Azure ファイル共有への暗号化されていない接続が可能な場合でも、Azure File Sync は暗号化されたチャネルのみを使用してファイル共有にアクセスします。Even if the switch at the storage account level is disabled, meaning that unencrypted connections to your Azure file shares are possible, Azure File Sync will still only used encrypted channels to access your file share.

ストレージ アカウントの転送中の暗号化を無効にする主な理由は、古いオペレーティング システム (Windows Server 2008 R2 や古い Linux ディストリビューションなど) 上で実行する必要のある、Azure ファイル共有と直接通信するレガシ アプリケーションをサポートするためです。The primary reason to disable encryption in transit for the storage account is to support a legacy application that must be run on an older operating system, such as Windows Server 2008 R2 or older Linux distribution, talking to an Azure file share directly. レガシ アプリケーションとファイル共有の Windows Server キャッシュが通信する場合、この設定を切り替えても効果はありません。If the legacy application talks to the Windows Server cache of the file share, toggling this setting will have no effect.

転送中のデータの暗号化が有効になっていることを確認することを強くお勧めします。We strongly recommend ensuring encryption of data in-transit is enabled.

転送中の暗号化の詳細については、「Azure Storage で安全な転送が必要」を参照してください。For more information about encryption in transit, see requiring secure transfer in Azure storage.

Azure ファイル共有の保存時の暗号化Azure file share encryption at rest

Azure Files に格納されるすべてのデータは、Azure Storage Service Encryption (SSE) を使用して保存時に暗号化されます。All data stored in Azure Files is encrypted at rest using Azure storage service encryption (SSE). Storage Service Encryption は Windows の BitLocker と同様に機能し、データはファイル システム レベルで暗号化されます。Storage service encryption works similarly to BitLocker on Windows: data is encrypted beneath the file system level. データは Azure ファイル共有のファイル システムで暗号化されるため、ディスクにエンコードされた場合、Azure ファイル共有を読み書きするために、基になるクライアント上のキーにアクセスできる必要はありません。Because data is encrypted beneath the Azure file share's file system, as it's encoded to disk, you don't have to have access to the underlying key on the client to read or write to the Azure file share.

規定では、Azure Files に格納されるデータは、Microsoft マネージド キーで暗号化されます。By default, data stored in Azure Files is encrypted with Microsoft-managed keys. Microsoft マネージド キーを使用すると、Microsoft によってデータの暗号化および暗号化解除のためのキーが保持され、定期的にローテーションが行われます。With Microsoft-managed keys, Microsoft holds the keys to encrypt/decrypt the data, and is responsible for rotating them on a regular basis. また、お客様が自分でキーを管理することもでき、その場合はお客様がローテーション プロセスを制御できます。You can also choose to manage your own keys, which gives you control over the rotation process. お客様が管理するキーによるファイル共有の暗号化を選択した場合、クライアントからの読み取りと書き込みの要求を処理するため、Azure Files にはキーへのアクセスが承認されます。If you choose to encrypt your file shares with customer-managed keys, Azure Files is authorized to access your keys to fulfill read and write requests from your clients. お客様管理のキーを使用すると、お客様はこの承認をいつでも取り消すことができますが、これは、SMB または FileREST API を使用して Azure ファイル共有にアクセスできなくなることを意味します。With customer-managed keys, you can revoke this authorization at any time, but this means that your Azure file share will no longer be accessible via SMB or the FileREST API.

Azure Files では、Azure Blob Storage などの他の Azure ストレージ サービスと同じ暗号化スキームが使用されます。Azure Files uses the same encryption scheme as the other Azure storage services such as Azure Blob storage. Azure Storage Service Encryption (SSE) の詳細については、「保存データに対する Azure Storage 暗号化」をご覧ください。To learn more about Azure storage service encryption (SSE), see Azure storage encryption for data at rest.

ストレージ層Storage tiers

Azure Files では、Premium と Standard の 2 つの異なるストレージのサービス レベルが提供されており、お客様のシナリオのパフォーマンスと価格の要件に合わせて共有を調整できます。Azure Files offers two different tiers of storage, premium and standard, to allow you to tailor your shares to the performance and price requirements of your scenario:

  • Premium ファイル共有: Premium ファイル共有は、ソリッドステート ドライブ (SSD) が基になっており、FileStorage ストレージ アカウントの種類にデプロイされます。Premium file shares: Premium file shares are backed by solid-state drives (SSDs) and are deployed in the FileStorage storage account type. Premium ファイル共有は、IO 集中型ワークロードの場合、ほとんどの IO 操作に対して 1 桁台のミリ秒以内で一貫したハイ パフォーマンスと低待機時間を提供しています。Premium file shares provide consistent high performance and low latency, within single-digit milliseconds for most IO operations, for IO-intensive workloads. そのため、Premium ファイル共有は、データベース、Web サイトのホスティング、開発環境など、幅広い種類のワークロードに適しています。This makes them suitable for a wide variety of workloads like databases, web site hosting, and development environments. Premium ファイル共有は、プロビジョニングされる課金モデルでのみ使用できます。Premium file shares are only available in a provisioned billing model. Premium ファイル共有のプロビジョニング済み課金モデルについて詳しくは、「Premium ファイル共有のプロビジョニングについて」をご覧ください。For more information on the provisioned billing model for premium file shares, see Understanding provisioning for premium file shares.
  • Standard ファイル共有: Standard ファイル共有は、ハード ディスク ドライブ (HDD) が基になっており、汎用バージョン 2 (GPv2) ストレージ アカウントの種類にデプロイされます。Standard file shares: Standard file shares are backed by hard disk drives (HDDs) and are deployed in the general purpose version 2 (GPv2) storage account type. Standard ファイル共有は、汎用のファイル共有や開発/テスト環境などのパフォーマンスの変動の影響を受けにくい IO ワークロードに対して信頼性の高いパフォーマンスを提供します。Standard file shares provide reliable performance for IO workloads that are less sensitive to performance variability such as general-purpose file shares and dev/test environments. Standard ファイル共有は、従量課金制の課金モデルでのみ利用できます。Standard file shares are only available in a pay-as-you-go billing model.

標準ファイル共有を最大 100 TiB にまたげるようにするEnable standard file shares to span up to 100 TiB

既定では、Standard ファイル共有に使用できるのは最大 5 TiB だけですが、共有の制限は 100 TiB に増やすことができます。By default, standard file shares can span only up to 5 TiB, although the share limit can be increased to 100 TiB. これを行うには、"大きなファイル共有" 機能をストレージ アカウント レベルで有効にする必要があります。To do this, large file share feature must be enabled at the storage account-level. Premium ストレージ アカウント (FileStorage ストレージアカウント) の場合は、すべての Premium ファイル共有が既に 100 TiB の最大容量までプロビジョニングできるようになっているため、大きなファイル共有機能のフラグはありません。Premium storage accounts (FileStorage storage accounts) don't have the large file share feature flag as all premium file shares are already enabled for provisioning up to the full 100 TiB capacity.

大きなファイル共有を有効にできるのは、ローカル冗長またはゾーン冗長の Standard ストレージ アカウントだけです。You can only enable large file shares on locally redundant or zone redundant standard storage accounts. 大きなファイル共有機能フラグを有効にした後では、冗長性レベルを geo 冗長ストレージまたは geo ゾーン冗長ストレージに変更することはできません。Once you have enabled the large file share feature flag, you can't change the redundancy level to geo-redundant or geo-zone-redundant storage.

既存のストレージ アカウントで大きなファイル共有を有効にするには、ストレージ アカウントの目次で [構成] ビューに移動し、大きなファイル共有のロッカー スイッチを有効に切り替えます。To enable large file shares on an existing storage account, navigate to the Configuration view in the storage account's table of contents, and switch the large file share rocker switch to enabled:

Azure portal での大きなファイル共有有効化ロッカー スイッチのスクリーンショット

Set-AzStorageAccount PowerShell コマンドレットおよび az storage account update Azure CLI コマンドを使用して、100 TiB のファイル共有を有効にすることもできます。You can also enable 100 TiB file shares through the Set-AzStorageAccount PowerShell cmdlet and the az storage account update Azure CLI command. 大きなファイル共有を有効にする詳しい手順については、「大きなファイル共有の有効化と作成」を参照してください。For detailed instructions on enabling large files shares, see enable and create large file shares.

新しいストレージ アカウントにファイル共有を作成にする方法の詳細については、Azure ファイル共有の作成に関する記事を参照してください。To learn more about how to create file shares on new storage accounts, see creating an Azure file share.

リージョン別の提供状況Regional availability

100 TiB の容量を持つ Standard ファイル共有には、いくつかの制限事項があります。Standard file shares with 100 TiB capacity have certain limitations.

  • 現在サポートされているのは、ローカル冗長ストレージ (LRS) アカウントとゾーン冗長ストレージ (ZRS) アカウントだけです。Currently, only locally redundant storage (LRS) and zone redundant storage (ZRS) accounts are supported.
  • 大きなファイル共有を有効にした後は、ストレージ アカウントを geo 冗長ストレージ (GRS) アカウントや geo ゾーン冗長ストレージ (GZRS) アカウントに変換することはできません。Once you enable large file shares, you cannot convert storage accounts to geo-redundant storage (GRS) or geo-zone-redundant storage (GZRS) accounts.
  • いったん大きなファイル共有を有効にすると、無効にすることはできなくなります。Once you enable large file shares, you can't disable it.

Azure File Sync の利用可能なリージョンAzure file sync region availability

Azure File Sync は、次のリージョンで利用できます。Azure File Sync is available in the following regions:

Azure cloudAzure cloud 地理的リージョンGeographic region Azure リージョンAzure region リージョン コードRegion code
パブリックPublic アジアAsia 東アジアEast Asia eastasia
パブリックPublic アジアAsia 東南アジアSoutheast Asia southeastasia
パブリックPublic オーストラリアAustralia オーストラリア東部Australia East australiaeast
パブリックPublic オーストラリアAustralia オーストラリア南東部Australia Southeast australiasoutheast
パブリックPublic ブラジルBrazil ブラジル南部Brazil South brazilsouth
パブリックPublic CanadaCanada カナダ中部Canada Central canadacentral
パブリックPublic CanadaCanada カナダ東部Canada East canadaeast
パブリックPublic ヨーロッパEurope 北ヨーロッパNorth Europe northeurope
パブリックPublic ヨーロッパEurope 西ヨーロッパWest Europe westeurope
パブリックPublic フランスFrance フランス中部France Central francecentral
パブリックPublic フランスFrance フランス南部*France South* francesouth
パブリックPublic インドIndia インド中部Central India centralindia
パブリックPublic インドIndia インド南部South India southindia
パブリックPublic 日本Japan 東日本Japan East japaneast
パブリックPublic 日本Japan 西日本Japan West japanwest
パブリックPublic 韓国Korea 韓国中部Korea Central koreacentral
パブリックPublic 韓国Korea 韓国南部Korea South koreasouth
パブリックPublic 南アフリカSouth Africa 南アフリカ北部South Africa North southafricanorth
パブリックPublic 南アフリカSouth Africa 南アフリカ西部*South Africa West* southafricawest
パブリックPublic UAEUAE アラブ首長国連邦中部*UAE Central* uaecentral
パブリックPublic UAEUAE アラブ首長国連邦北部UAE North uaenorth
パブリックPublic 英国UK 英国南部UK South uksouth
パブリックPublic 英国UK 英国西部UK West ukwest
パブリックPublic USUS 米国中部Central US centralus
パブリックPublic USUS 米国東部East US eastus
パブリックPublic USUS 米国東部 2East US 2 eastus2
パブリックPublic USUS 米国中北部North Central US northcentralus
パブリックPublic USUS 米国中南部South Central US southcentralus
パブリックPublic USUS 米国中西部West Central US westcentralus
パブリックPublic USUS 米国西部West US westus
パブリックPublic USUS 米国西部 2West US 2 westus2
US GovUS Gov USUS US Gov アリゾナUS Gov Arizona usgovarizona
US GovUS Gov USUS US Gov テキサスUS Gov Texas usgovtexas
US GovUS Gov USUS US Gov バージニア州US Gov Virginia usgovvirginia

Azure File Sync は、ストレージ同期サービスと同じリージョンの Azure ファイル共有との同期のみをサポートしています。Azure File Sync supports syncing only with an Azure file share that's in the same region as the Storage Sync Service.

アスタリスクが付いているリージョンでは、Azure サポートに連絡して、これらのリージョンの Azure Storage へのアクセス権を要求する必要があります。For the regions marked with asterisks, you must contact Azure Support to request access to Azure Storage in those regions. このプロセスについては、このドキュメントで概説されています。The process is outlined in this document.

冗長性Redundancy

Azure ファイル共有内のデータを損失や破損から保護するため、すべての Azure ファイル共有では、各ファイルが書き込まれるときに複数のコピーが格納されます。To protect the data in your Azure file shares against data loss or corruption, all Azure file shares store multiple copies of each file as they are written. ワークロードの要件に応じて、冗長性のレベルをさらに高めることができます。Depending on the requirements of your workload, you can select additional degrees of redundancy. 現在、Azure Files では次のデータ冗長性オプションがサポートされています。Azure Files currently supports the following data redundancy options:

  • ローカル冗長: ローカル冗長ストレージ (LRS と呼ばれることもあります) は、すべてのファイルが Azure ストレージ クラスター内に 3 回格納されることを意味します。Locally redundant: Locally redundant storage, often referred to as LRS, means that every file is stored three times within an Azure storage cluster. これにより、不良ディスク ドライブなどのハードウェア障害によるデータの損失を防ぐことができます。This protects against loss of data due to hardware faults, such as a bad disk drive.
  • ゾーン冗長: ゾーン冗長ストレージ (ZRS と呼ばれることもあります) は、すべてのファイルが 3 つの異なる Azure ストレージ クラスターに 3 回格納されることを意味します。Zone redundant: Zone redundant storage, often referred to as ZRS, means that every file is stored three times across three distinct Azure storage clusters. ローカル冗長ストレージと同様に、ゾーン冗長では、ファイルごとに 3 つのコピーが用意されます。ただしこれらのコピーは、異なる Azure "可用性ゾーン" の 3 つの独立したストレージ クラスターで物理的に分離されます。Just like with locally redundant storage, zone redundancy gives you three copies of each file, however these copies are physically isolated in three distinct storage clusters in different Azure availability zones. 可用性ゾーンは、Azure リージョン内の一意の物理的な場所です。Availability zones are unique physical locations within an Azure region. それぞれのゾーンは、独立した電源、冷却手段、ネットワークを備えた 1 つまたは複数のデータセンターで構成されています。Each zone is made up of one or more datacenters equipped with independent power, cooling, and networking. 3 つの可用性ゾーンすべてのストレージ クラスターに書き込まれるまで、ストレージへの書き込みは受け入れられません。A write to storage is not accepted until it is written to the storage clusters in all three availability zones.
  • geo 冗長: geo 冗長ストレージ (GRS と呼ばれることもあります) では、ローカル冗長ストレージと同じように、プライマリ リージョンの Azure ストレージ クラスター内にファイルが 3 回保存されます。Geo-redundant: Geo-redundant storage, often referred to as GRS, is like locally redundant storage, in that a file is stored three times within an Azure storage cluster in the primary region. その後、すべての書き込みが Microsoft で定義されたセカンダリ リージョンに非同期的にレプリケートされます。All writes are then asynchronously replicated to a Microsoft-defined secondary region. geo 冗長ストレージでは、データの 6 つのコピーが 2 つの Azure リージョンに分散して作成されます。Geo-redundant storage provides 6 copies of your data spread between two Azure regions. 自然災害や他の同様の出来事で Azure リージョンが完全に失われた場合など、重大な障害が発生した場合は、Microsoft によってフェールオーバーが実行され、セカンダリが実質的にプライマリになってすべての操作を提供します。In the event of a major disaster such as the permanent loss of an Azure region due to a natural disaster or other similar event, Microsoft will perform a failover so that the secondary in effect becomes the primary, serving all operations. プライマリ リージョンとセカンダリ リージョンの間のレプリケーションは非同期であるため、重大な障害が発生した場合、セカンダリ リージョンにまだレプリケートされていないデータは失われます。Since the replication between the primary and secondary regions are asynchronous, in the event of a major disaster, data not yet replicated to the secondary region will be lost. geo 冗長ストレージ アカウントのフェールオーバーは、手動で実行することもできます。You can also perform a manual failover of a geo-redundant storage account.
  • geo ゾーン冗長: geo ゾーン冗長ストレージ (GZRS と呼ばれることもあります) では、ゾーン冗長ストレージと同じように、プライマリ リージョン内の 3 つの異なるストレージ クラスターにファイルが 3 回保存されます。Geo-zone redundant: Geo-zone redundant storage, often referred to as GZRS, is like zone redundant storage, in that a file is stored three times across three distinct storage clusters in the primary region. その後、すべての書き込みが Microsoft で定義されたセカンダリ リージョンに非同期的にレプリケートされます。All writes are then asynchronously replicated to a Microsoft-defined secondary region. geo ゾーン冗長ストレージのフェールオーバー プロセスは、geo 冗長ストレージの場合と同じように動作します。The failover process for geo-zone-redundant storage works the same as it does for geo-redundant storage.

Standard Azure ファイル共有では 4 種類の冗長性がすべてサポートされていますが、Premium Azure ファイル共有では、ローカル冗長ストレージとゾーン冗長ストレージのみがサポートされています。Standard Azure file shares support all four redundancy types, while premium Azure file shares only support locally redundant and zone redundant storage.

汎用バージョン 2 (GPv2) のストレージ アカウントでは、Azure Files ではサポートされていない 2 つの追加の冗長オプションが提供されています。読み取りアクセス geo 冗長ストレージ (RA-GRS と呼ばれることもあります) と、読み取りアクセス geo ゾーン冗長ストレージ (RA-GZRS と呼ばれることもあります) です。General purpose version 2 (GPv2) storage accounts provide two additional redundancy options that are not supported by Azure Files: read accessible geo-redundant storage, often referred to as RA-GRS, and read accessible geo-zone-redundant storage, often referred to as RA-GZRS. これらのオプション セットを使用して、ストレージ アカウントで Azure ファイル共有をプロビジョニングできますが、Azure Files ではセカンダリ リージョンからの読み取りはサポートされていません。You can provision Azure file shares in storage accounts with these options set, however Azure Files does not support reading from the secondary region. 読み取りアクセス geo 冗長ストレージ アカウントまたは読み取りアクセス geo ゾーン冗長ストレージ アカウントにデプロイされた Azure ファイル共有は、それぞれ、geo 冗長ストレージまたは geo ゾーン冗長ストレージとして課金されます。Azure file shares deployed into read-accessible geo- or geo-zone redundant storage accounts will be billed as geo-redundant or geo-zone-redundant storage, respectively.

重要

Geo 冗長ストレージおよび Geo ゾーン冗長ストレージには、セカンダリ リージョンに手動でストレージをフェールオーバーする機能があります。Geo-redundant and Geo-zone redundant storage have the capability to manually failover storage to the secondary region. データ損失の可能性が高くなるため、Azure File Sync を使用している場合は、障害が発生していない場合にこの操作を行わないことをお勧めします。We recommend that you do not do this outside of a disaster when you are using Azure File Sync because of the increased likelihood of data loss. ストレージの手動フェールオーバーを開始する必要がある障害が発生した場合は、Azure File Sync でセカンダリ エンドポイントとの同期が再開されるよう、Microsoft のサポートケースを開く必要があります。In the event of a disaster where you would like to initiate a manual failover of storage, you will need to open up a support case with Microsoft to get Azure File Sync to resume sync with the secondary endpoint.

移行Migration

既存の Windows ファイル サーバーがある場合は、新しいサーバーにデータを移動しなくても、Azure File Sync を直接インストールすることができます。If you have an existing Windows file server, Azure File Sync can be directly installed in place, without the need to move data over to a new server. Azure File Sync の導入の一環として新しい Windows ファイル サーバーへの移行を計画している場合は、データを移動する方法がいくつかあります。If you are planning to migrate to a new Windows file server as a part of adopting Azure File Sync, there are several possible approaches to move data over:

  • 古いファイル共有と新しいファイル共有のサーバー エンドポイントを作成し、Azure File Sync を使用してサーバー エンドポイント間でデータを同期させます。Create server endpoints for your old file share and your new file share and let Azure File Sync synchronize the data between the server endpoints. この方法の利点は、クラウドを使った階層化に対応している Azure File Sync であるため、新しいファイル サーバーのストレージをオーバーサブスクライブすることが非常に簡単になることです。The advantage to this approach is that it makes it very easy to oversubscribe the storage on your new file server, since Azure File Sync is cloud tiering aware. 準備ができたら、エンド ユーザーを新しいサーバー上のファイル共有に切り替え、古いファイル共有のサーバー エンドポイントを削除します。When you are ready, you can cut over end users to the file share on the new server and remove the old file share's server endpoint.

  • 新しいファイル サーバーにのみサーバー エンドポイントを作成し、robocopy を使用して古いファイル共有からデータをコピーします。Create a server endpoint only on the new file server, and copy data into from the old file share using robocopy. 新しいサーバー上のファイル共有のトポロジ (各ボリュームで保持されている共有の数、各ボリュームの空き領域など) に応じて、追加のストレージを一時的にプロビジョニングする必要があります。これは、オンプレミスのデータセンター内の古いサーバーから新しいサーバーへの robocopy は、Azure File Sync がデータを Azure に移動するよりも短時間で完了するためです。Depending on the topology of file shares on your new server (how many shares you have on each volume, how free each volume is, etc.), you may need to temporarily provision additional storage as it is expected that robocopy from your old server to your new server within your on-premises datacenter will complete faster than Azure File Sync will move data into Azure.

Data Box を使用して、Azure File Sync のデプロイにデータを移行することもできます。It is also possible to use Data Box to migrate data into an Azure File Sync deployment. ほとんどの場合、お客様がデータを取り込むために Data Box を使用するのは、デプロイの速度が向上すると考えたか、または制限された帯域幅シナリオで役立つことがあると考えたためです。Most of the time, when customers want to use Data Box to ingest data, they do so because they think it will increase the speed of their deployment or because it will help with constrained bandwidth scenarios. Azure File Sync のデプロイへデータを取り込むために Data Box を使用すると、帯域幅の使用率が低下することは事実ですが、ほとんどのシナリオでは、上記の方法のいずれかを使用してオンライン データのアップロードを実行する方が短時間で済みます。While it's true that using a Data Box to ingest data into your Azure File Sync deployment will decrease bandwidth utilization, it will likely be faster for most scenarios to pursue an online data upload through one of the methods described above. Data Box を使用して Azure File Sync のデプロイにデータを取り込む方法の詳細については、「Azure Data Box を使用して Azure File Sync にデータを移行する」を参照してください。To learn more about how to use Data Box to ingest data into your Azure File Sync deployment, see Migrate data into Azure File Sync with Azure Data Box.

新しい Azure File Sync のデプロイにデータを移行する際によくある間違いは、Windows ファイル サーバーではなく Azure ファイル共有にデータを直接コピーしてしまうことです。A common mistake customers make when migrating data into their new Azure File Sync deployment is to copy data directly into the Azure file share, rather than on their Windows file servers. Azure File Sync は Azure ファイル共有上のすべての新しいファイルを識別し、それらを Windows ファイル共有に同期しますが、通常、これは Windows ファイル サーバーを使用してデータを読み込む場合よりもはるかに低速です。Although Azure File Sync will identify all of the new files on the Azure file share, and sync them back to your Windows file shares, this is generally considerably slower than loading data through the Windows file server. AzCopy などの Azure コピー ツールを使用する場合は、最新バージョンを使用することが重要です。When using Azure copy tools, such as AzCopy, it is important to use the latest version. ファイル コピー ツールの表をチェックして、Azure コピー ツールの概要を確認し、タイムスタンプや ACL など、ファイルの重要なメタデータをすべてコピーできることを確認します。Check the file copy tools table to get an overview of Azure copy tools to ensure you can copy all of the important metadata of a file such as timestamps and ACLs.

ウイルス対策Antivirus

ウイルス対策は、ファイルをスキャンして既知の悪意のあるコードを検索することで機能するので、ウイルス対策製品によって階層化されたファイルの再呼び出しが発生することがあります。Because antivirus works by scanning files for known malicious code, an antivirus product might cause the recall of tiered files. Azure File Sync エージェントのバージョン 4.0 以降では、階層化されたファイルにはセキュリティで保護された Windows 属性 FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS が設定されています。In versions 4.0 and above of the Azure File Sync agent, tiered files have the secure Windows attribute FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS set. この属性を設定してオフライン ファイルの読み取りをスキップするようにソリューションを構成する方法について、ソフトウェア ベンダーと相談することをお勧めします (多くの場合は自動実行されます)。We recommend consulting with your software vendor to learn how to configure their solution to skip reading files with this attribute set (many do it automatically).

Microsoft の社内ウイルス対策ソリューションである Windows Defender と System Center Endpoint Protection (SCEP) では、この属性が設定されたファイルの読み取りが自動的にスキップされます。Microsoft's in-house antivirus solutions, Windows Defender and System Center Endpoint Protection (SCEP), both automatically skip reading files that have this attribute set. そのテスト結果として小さな問題点がわかりました。既存の同期グループにサーバーを追加すると、新しいサーバー上で 800 バイト未満のファイルの呼び戻し (ダウンロード) が実行されるという問題です。We have tested them and identified one minor issue: when you add a server to an existing sync group, files smaller than 800 bytes are recalled (downloaded) on the new server. このようなファイルは新しいサーバー上に残り、階層化のサイズ要件 (64 KB を超えるサイズ) を満たしていないため、階層化されません。These files will remain on the new server and will not be tiered since they do not meet the tiering size requirement (>64kb).

注意

ウイルス対策ソフトウェア ベンダーは、その製品と Azure File Sync との間の互換性を、Azure File Sync Antivirus Compatibility Test Suite を使用して確認することができます。これは、Microsoft ダウンロード センターでダウンロードできます。Antivirus vendors can check compatibility between their product and Azure File Sync using the Azure File Sync Antivirus Compatibility Test Suite, which is available for download on the Microsoft Download Center.

バックアップBackup

ウイルス対策ソリューションと同様に、バックアップ ソリューションでも階層化されたファイルの再呼び出しが発生することがあります。Like antivirus solutions, backup solutions might cause the recall of tiered files. Azure ファイル共有をバックアップするには、オンプレミスのバックアップ製品ではなく、クラウド バックアップ ソリューションを使用することをお勧めします。We recommend using a cloud backup solution to back up the Azure file share instead of an on-premises backup product.

オンプレミス バックアップ ソリューションを使用している場合、クラウドの階層化が無効な同期グループ内のサーバーに対してバックアップを実行する必要があります。If you are using an on-premises backup solution, backups should be performed on a server in the sync group that has cloud tiering disabled. 復元を実行するときは、ボリューム レベルまたはファイル レベルの復元オプションを使用します。When performing a restore, use the volume-level or file-level restore options. ファイル レベルの復元オプションを使用して復元されたファイルは、同期グループ内のすべてのエンドポイントに同期され、既存のファイルはバックアップから復元されたバージョンに置き換えられます。Files restored using the file-level restore option will be synced to all endpoints in the sync group and existing files will be replaced with the version restored from backup. ボリューム レベルの復元では、Azure ファイル共有やその他のサーバー エンドポイントの新しいファイル バージョンに置き換えられません。Volume-level restores will not replace newer file versions in the Azure file share or other server endpoints.

注意

ベアメタル (BMR) 復元は予期しない結果が生じることがあるため、現在サポートされていません。Bare-metal (BMR) restore can cause unexpected results and is not currently supported.

注意

Azure File Sync エージェントのバージョン 9 では、VSS スナップショット ([以前のバージョン] タブを含む) が、クラウドの階層化が有効なボリュームでサポートされるようになりました。With Version 9 of the Azure File Sync agent, VSS snapshots (including Previous Versions tab) are now supported on volumes which have cloud tiering enabled. ただし、PowerShell を使用して以前のバージョンの互換性を有効にする必要があります。However, you must enable previous version compatibility through PowerShell. 方法については、こちらをご覧ください。Learn how.

Azure ファイル同期エージェントの更新ポリシーAzure File Sync agent update policy

Azure File Sync エージェントは、新機能の追加や問題の解決を目的として定期的に更新されます。The Azure File Sync agent is updated on a regular basis to add new functionality and to address issues. Azure File Sync エージェントの更新プログラムを公開されしだい入手できるように Microsoft Update を構成しておくことをお勧めします。We recommend you configure Microsoft Update to get updates for the Azure File Sync agent as they're available.

エージェントのメジャー バージョンとマイナー バージョンMajor vs. minor agent versions

  • エージェントのメジャー バージョンには、多くの場合、新しい機能が含まれています。メジャー バージョンでは、バージョン番号の先頭部分の数値が増えていきます。Major agent versions often contain new features and have an increasing number as the first part of the version number. 次に例を示します。*2.*.**For example: *2.*.**
  • エージェントのマイナー バージョンは "修正プログラム" とも呼ばれ、メジャー バージョンよりも頻繁にリリースされます。Minor agent versions are also called "patches" and are released more frequently than major versions. 多くの場合、バグの修正と軽微な機能強化が含まれ、新しい機能は含まれません。They often contain bug fixes and smaller improvements but no new features. 例: **.3.**For example: **.3.**

アップグレード パスUpgrade paths

Azure File Sync エージェントの更新プログラムのインストールを承認してテストする方法は 4 つあります。There are four approved and tested ways to install the Azure File Sync agent updates.

  1. (推奨) エージェントの更新プログラムを自動的にダウンロードしてインストールするように Microsoft Update を構成する。(Preferred) Configure Microsoft Update to automatically download and install agent updates.
    すべての Azure File Sync の更新プログラムを実行して、サーバー エージェントの最新の修正を確実に適用することを常にお勧めします。We always recommend taking every Azure File Sync update to ensure you have access to the latest fixes for the server agent. Microsoft Update では、更新プログラムのダウンロードとインストールを自動的に実行することで、このプロセスをシームレスにしています。Microsoft Update makes this process seamless, by automatically downloading and installing updates for you.
  2. AfsUpdater.exe を使用してエージェントの更新プログラムをダウンロードし、インストールする。Use AfsUpdater.exe to download and install agent updates.
    AfsUpdater.exe は、エージェントのインストール ディレクトリにあります。The AfsUpdater.exe is located in the agent installation directory. 実行可能ファイルをダブルクリックすると、エージェントの更新プログラムがダウンロードされてインストールされます。Double-click the executable to download and install agent updates.
  3. Microsoft Update 修正プログラム ファイル (.msp 実行可能ファイル) を使用して、既存の Azure File Sync エージェントを修正する。最新の Azure File Sync 更新プログラム パッケージは、Microsoft Update カタログからダウンロードできます。Patch an existing Azure File Sync agent by using a Microsoft Update patch file, or a .msp executable. The latest Azure File Sync update package can be downloaded from the Microsoft Update Catalog.
    .msp 実行可能ファイルを実行すると、前回の更新パスで Microsoft Update によって自動的に使用されたのと同じ方法を使用して、Azure File Sync のインストールがアップグレードされます。Running a .msp executable will upgrade your Azure File Sync installation with the same method used automatically by Microsoft Update in the previous upgrade path. Microsoft Update 修正プログラムを適用すると、Azure File Sync のインストールのインプレース アップグレードが実行されます。Applying a Microsoft Update patch will perform an in-place upgrade of an Azure File Sync installation.
  4. Microsoft ダウンロード センターから最新の Azure File Sync エージェント インストーラーをダウンロードする。Download the newest Azure File Sync agent installer from the Microsoft Download Center.
    既存の Azure File Sync エージェントのインストールをアップグレードするには、古いバージョンをアンインストールした後、ダウンロードしたインストーラーから最新バージョンをインストールします。To upgrade an existing Azure File Sync agent installation, uninstall the older version and then install the latest version from the downloaded installer. サーバーの登録、同期グループ、およびその他の設定は、Azure File Sync インストーラーによって管理されます。The server registration, sync groups, and any other settings are maintained by the Azure File Sync installer.

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

バージョン 6 のエージェントでは、ファイル同期チームによってエージェントの自動アップグレード機能が導入されました。With agent version 6, the file sync team has introduced an agent auto-upgrade feature. 2 つのモードのいずれかを選択して、サーバーでアップグレードが試行されるメンテナンス期間を指定できます。You can select either of two modes and specify a maintenance window in which the upgrade shall be attempted on the server. この機能は、エージェントの期限切れを防止する手段を提供するか、面倒な作業なしで最新状態を維持する設定を許可することで、エージェントのライフサイクル管理を支援するように設計されています。This feature is designed to help you with the agent lifecycle management by either providing a guardrail preventing your agent from expiration or allowing for a no-hassle, stay current setting.

  1. 既定の設定では、エージェントの期限切れの防止が試行されます。The default setting will attempt to prevent the agent from expiration. 示されているエージェントの有効期限の 21 日以内に、エージェントがセルフアップグレードを試行します。Within 21 days of the posted expiration date of an agent, the agent will attempt to self-upgrade. 有効期限まで 21 日以内になると週に 1 回、選択されているメンテナンス期間にアップグレードを試行します。It will start an attempt to upgrade once a week within 21 days prior to expiration and in the selected maintenance window. このオプションでは、通常の Microsoft Update 修正プログラムを適用する必要性は解消されません。This option does not eliminate the need for taking regular Microsoft Update patches.
  2. 必要に応じて、新しいエージェント バージョンが使用可能になるとすぐにエージェントが自動アップグレードされるように選択できます (現在クラスター サーバーには適用できません)。Optionally, you can select that the agent will automatically upgrade itself as soon as a new agent version becomes available (currently not applicable to clustered servers). この更新は、選択されているメンテナンス期間内に行われ、新機能と機能強化が一般提供されるとすぐに、サーバーはそれらの恩恵を受けることができます。This update will occur during the selected maintenance window and allow your server to benefit from new features and improvements as soon as they become generally available. これは安心して利用できる推奨設定であり、エージェントのメジャー バージョンだけでなく定期的な更新プログラムがサーバーに提供されます。This is the recommended, worry-free setting that will provide major agent versions as well as regular update patches to your server. リリースされるすべてのエージェントは GA 品質です。Every agent released is at GA quality. このオプションを選択すると、Microsoft はお客様に最新のエージェント バージョンをフライト化します。If you select this option, Microsoft will flight the newest agent version to you. クラスター化サーバーは除外されます。Clustered servers are excluded. フライト化が完了すると、エージェントは Microsoft ダウンロード センターでも利用可能になります (aka.ms/AFS/agent)。Once flighting is complete, the agent will also become available on Microsoft Download Center aka.ms/AFS/agent.
自動アップグレードの設定の変更Changing the auto-upgrade setting

次の手順では、インストーラーの完了後に変更を行う必要がある場合に、設定を変更する方法について説明します。The following instructions describe how to change the settings after you've completed the installer, if you need to make changes.

PowerShell コンソールを開き、同期エージェントをインストールしたディレクトリに移動してから、サーバー コマンドレットをインポートします。Open a PowerShell console and navigate to the directory where you installed the sync agent then import the server cmdlets. これは、既定ではこのようになります。By default this would look something like this:

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

Get-StorageSyncAgentAutoUpdatePolicy を実行して、現在のポリシー設定を確認し、変更するかどうかを判断できます。You can run Get-StorageSyncAgentAutoUpdatePolicy to check the current policy setting and determine if you want to change it.

現在のポリシー設定を遅延更新追跡に変更する場合は、以下を使用できます。To change the current policy setting to the delayed update track, you can use:

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode UpdateBeforeExpiration

現在のポリシー設定を即時更新追跡に変更する場合は、以下を使用できますTo change the current policy setting to the immediate update track, you can use:

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode InstallLatest

エージェントのライフサイクルと変更管理の保証Agent lifecycle and change management guarantees

Azure File Sync は、新機能および機能強化を継続的に導入するするクラウド サービスです。Azure File Sync is a cloud service, which continuously introduces new features and improvements. つまり、Azure File Sync エージェントの特定のバージョンは、一定の期間のみサポートされます。This means that a specific Azure File Sync agent version can only be supported for a limited time. デプロイを容易にするために、次のルールによって、変更管理プロセス中にエージェントの更新/アップグレードに対応するための十分な時間と通知が保証されます。To facilitate your deployment, the following rules guarantee you have enough time and notification to accommodate agent updates/upgrades in your change management process:

  • エージェントのメジャー バージョンは、最初のリリースから少なくとも 6 か月間サポートされます。Major agent versions are supported for at least six months from the date of initial release.
  • エージェントのメジャー バージョン間のサポートは、少なくとも 3 か月間重複することが保証されます。We guarantee there is an overlap of at least three months between the support of major agent versions.
  • 登録済みサーバーに対する警告は、有効期限がまもなく終了することを通知するエージェントを使用して、有効期限の少なくとも 3 か月前に発行されます。Warnings are issued for registered servers using a soon-to-be expired agent at least three months prior to expiration. Storage Sync Service の登録済みサーバー セクションで、登録済みサーバーがエージェントの古いバージョンを使用しているかどうかをチェックできます。You can check if a registered server is using an older version of the agent under the registered servers section of a Storage Sync Service.
  • マイナー エージェントの有効期間は、メジャー バージョンに関連付けられています。The lifetime of a minor agent version is bound to the associated major version. たとえば、エージェントのバージョン 3.0 がリリースされると、エージェントのバージョン 2.*は、すべてがまとめて期限切れになります。For example, when agent version 3.0 is released, agent versions 2.* will all be set to expire together.

注意

有効期間に関する警告が表示されているエージェントのバージョンをインストールしようとすると、警告が表示されますが、インストールは成功します。Installing an agent version with an expiration warning will display a warning but succeed. 期限切れのエージェントのバージョンのインストールまたはそれを使用した接続は、サポートされていないためにブロックされます。Attempting to install or connect with an expired agent version is not supported and will be blocked.

次のステップNext steps