この記事では、SMB Azure ファイル共有への移行の基本的な側面について説明し、移行ガイドの表を示します。 これらのガイドは、ファイルを Azure ファイル共有に移動するのに役立ちます。 ガイドは、データの場所と、移動先のデプロイメント モデル (クラウドのみまたはハイブリッド) に基づいて整理されています。
適用対象
ファイル共有の種類 | SMB | NFS |
---|---|---|
Standard ファイル共有 (GPv2)、LRS/ZRS |
![]() |
![]() |
Standard ファイル共有 (GPv2)、GRS/GZRS |
![]() |
![]() |
Premium ファイル共有 (FileStorage)、LRS/ZRS |
![]() |
![]() |
移行の基本
目標は、既存のファイル共有の場所から Azure にデータを移動することです。 Azure では、Windows Server を必要とせずに使用できるネイティブの Azure ファイル共有にデータが格納されます。 この移行は、運用データの整合性と、移行中の可用性が保証される方法で行う必要があります。 後者については、ダウンタイムを最小限に抑えて、通常のメンテナンス期間に収まるか、わずかに超えるだけで済むようにする必要があります。
Azure にはさまざまな種類のクラウド ストレージが用意されています。 Azure へのファイル移行の基本的側面の 1 つは、お使いのデータに適した Azure ストレージ オプションを見極めることです。
Azure ファイル共有は、汎用ファイル データに適しています。 このデータには、オンプレミスの SMB 共有を使用する対象となるあらゆるデータが含まれています。 Azure File Sync を使用すると、Windows サーバーが実行中のオンプレミス サーバーに複数の Azure ファイル共有のコンテンツをキャッシュできます。
オンプレミス サーバーで現在実行中のアプリケーションの場合、ファイルを Azure ファイル共有に格納することが適している場合もあります。 アプリケーションを Azure に移動し、Azure ファイル共有を共有ストレージとして使用できます。 このシナリオでは、Azure Disk を考慮することもできます。
クラウド アプリケーションによっては、SMB、マシンローカル データ アクセス、および共有アクセスに依存しないものもあります。 これらのアプリでは、Azure BLOB のようなオブジェクト ストレージが多くの場合に最適です。
ファイルの忠実性の維持
ファイル共有の移行における重要な側面は、ファイルを現在のストレージの場所から Azure に移動するときに、できるだけ多くのファイルの忠実性をキャプチャすることです。
ファイルの基本的なコンポーネントは次の 2 つです。
- データ ストリーム: ファイルのデータ ストリームにはファイル コンテンツが格納されます。
-
ファイル メタデータ: Azure BLOB のオブジェクト ストレージとは異なり、Azure ファイル共有は サポートされているファイル メタデータをネイティブに格納できます。 汎用ファイル データは従来、ファイル メタデータに依存しています。 アプリ データはそうではない場合があります。 ファイル メタデータには次のサブコンポーネントがあります。
- ファイル属性 (読み取り専用など)
- ファイルのアクセス許可。多くの場合、"NTFS アクセス許可" または "ファイルとフォルダーの ACL" と呼ばれます
- タイムスタンプ。特に作成 タイムスタンプおよび最終更新日時 タイムスタンプ
- 代替データ ストリーム。これは、より大量の非標準プロパティを格納する領域です。 この代替データ ストリームは、Azure ファイル共有内のファイルに格納できません。 これは、Azure File Sync が使用されているときはオンプレミスで保持されます。
移行におけるファイルの忠実性は、次の機能として定義できます。
- ソースについての該当するすべてのファイル情報を格納する。
- 移行ツールを使用してファイルを転送する。
- 移行先のターゲット ストレージにファイルを格納する。
この記事の移行ガイドのターゲットは、1 つ以上の Azure ファイル共有です。 こちらの SMB Azure ファイル共有ではサポートされていない機能の一覧を考慮に入れてください。
移行を円滑に進めるために、ニーズに合った最適なコピー ツールを特定し、ストレージ ターゲットをソースと一致させます。
重要
オンプレミスのファイル サーバーを Azure Files に移行する場合は、多数のファイルをコピーする前に、ファイル共有のルート ディレクトリ用の ACL を設定します。ルート ACL のアクセス許可の変更は、大きなファイルの移行後に行うと、反映されるまでに時間がかかる場合があります。
オンプレミスのドメイン コントローラーとして Active Directory Domain Services (AD DS) を利用するユーザーは、Azure ファイル共有にネイティブにアクセスできます。 Microsoft Entra Domain Services のユーザーも同様です。 それぞれのユーザーは現在の ID を使用して、共有のアクセス許可およびファイルとフォルダーの ACL に基づいてアクセスを取得します。 この動作は、オンプレミスのファイル共有に接続するユーザーに似ています。
SMB 経由の Azure Files の ID ベースの認証の詳細について学びます。
サポート対象のメタデータ
次のテーブルに、Azure Files でサポートされているメタデータを示します。
重要
LastAccessTime タイムスタンプは、ターゲット共有上のファイルまたはディレクトリでは現在サポートされていません。 ただし、Azure Files は、要求されたときにファイルの LastAccessTime 値を返します。 LastModifiedTime タイムスタンプは読み取り操作では更新されないため、常に CreationTime と同じになります。
ソース | 移行先 |
---|---|
ディレクトリの構造 | ソースの元のディレクトリ構造は、ターゲットの共有で保持できます。 |
アクセス許可 | Azure Files では Windows ACL がサポートされており、移行時に AD 統合が構成されていない場合でも、ターゲット共有に設定する必要があります。 以下の ACL を保持する必要があります: 所有者セキュリティ識別子 (SID)、グループ SID、随意アクセス リスト (DACL)、システム アクセス制御リスト (SACL)。 |
作成タイムスタンプ | ソースのファイルの元の作成タイムスタンプは、ターゲットの共有で保持できます。 |
変更タイムスタンプ | ソースのファイルの元の変更タイムスタンプは、ターゲットの共有で保持できます。 |
変更されたタイムスタンプ | ソースのファイルの元の変更されたタイムスタンプは、ターゲットの共有で保持できます。 |
ファイル属性 | 読み取り専用、非表示、アーカイブ フラグなどの一般的な属性は、ターゲット共有に保持できます。 |
検出フェーズ
移行の最初のフェーズは検出フェーズです。このフェーズでは、サイズ、数、依存関係など、移行する必要がある既存のすべての SMB ファイル共有を決定します。 これは、特に大規模な分散環境を持つ組織では、困難で時間のかかる作業になる可能性があります。 100 TiB を超えるファイル データをお持ちのお客様には、ファイル共有の検出と分析に役立つサードパーティ製ツールである Komprise を使用することをお勧めします。 詳細については、「 Komprise ファイルの移行」を参照してください。
既存の SMB ファイル共有は、オンプレミスの Windows Server に限定されない場合があることに注意してください。 Linux サーバー、クラウド、または外部 NAS デバイス上の場合があります。
評価フェーズ
検出後の評価フェーズでは、ファイル ストレージに使用できるオプションの理解、必要な Azure リソースのデプロイ、Azure ファイル共有の使用の準備が含まれます。
Azure ストレージ リソースをデプロイする
評価フェーズの一環として、Azure ストレージ アカウントとその中の SMB Azure ファイル共有をプロビジョニングします。
Azure ファイル共有は、Azure ストレージ アカウント内のクラウドにデプロイされます。 Standard ファイル共有の場合、この配置により、ストレージ アカウントが、IOPS やスループットなどのパフォーマンス数のスケール ターゲットになります。 単一のストレージ アカウントに複数のファイル共有を配置すると、これらの共有について IOPS とスループットの共有プールを作成することになります。
原則として、アーカイブ共有がある場合、またはそれらの中での日常のアクティビティが少ないことが予想される場合は、複数の Azure ファイル共有を同じストレージ アカウントにプールすることができます。 しかし、非常にアクティブな共有 (多くのユーザーやアプリケーションによって使用される共有) がある場合は、それぞれ 1 つのファイル共有があるストレージ アカウントをデプロイする必要があります。 これらの制限は、パフォーマンスが明示的にプロビジョニングされ、各共有に対して保証される FileStorage (Premium) ストレージ アカウントには適用されません。
パフォーマンスとコストの詳細については、「 パフォーマンス について」および「 課金について」を参照してください。
注
1 つの Azure リージョンにつき、1 サブスクリプションあたりのストレージ アカウント数は 250 に制限されています。 クォータの引き上げにより、リージョンごとに最大 500 個のストレージ アカウントを作成できます。 詳細については、「Azure Storage アカウントのクォータを増やす」を参照してください。
ストレージ アカウントをデプロイする際のもう 1 つの考慮事項は冗長性です。 「Azure Files の冗長性」を参照してください。
共有のリストを作成してある場合は、各共有を、それが作成されるストレージ アカウントにマップする必要があります。
ご利用のリソースの名前も重要です。 たとえば、人事部の複数の共有を Azure ストレージ アカウントにグループ化する場合は、そのストレージ アカウントに適切な名前を指定する必要があります。 同様に、使用する Azure ファイル共有に名前を付けるときは、オンプレミスの対応するものに使用したのと同じような名前を使用する必要があります。
次に、「SMB ファイル共有を作成する」の手順に従って、適切な数の Azure ファイル共有を含む適切な数の Azure ストレージ アカウントをデプロイします。 ほとんどの場合、各ストレージ アカウントのリージョンが同じであることを確認する必要があります。
Azure ファイル共有の使用を準備する
また、Azure および Azure 外のサーバーとユーザーが Azure ファイル共有を利用できるようにする方法を決定する必要があります。 最も重要な決定事項は次のとおりです。
- ネットワーク: ネットワークで SMB トラフィックをルーティングできるようにします。 詳細については、 Azure ファイル共有のネットワークの概要 を参照してください。 パブリック エンドポイント、プライベート エンドポイント、またはその両方の組み合わせを使用できます。
- 認証: ID ベースの認証用に Azure ストレージ アカウントを構成し、ストレージ アカウントを AD ドメインに参加させます。 これにより、アプリとユーザーは認証に AD ID を使用できるようになります。
- 承認: Azure ファイル共有ごとに共有レベルの ACL を使用すると、AD ユーザーとグループが特定の共有にアクセスできます。 Azure ファイル共有内で、ネイティブ NTFS ACL が引き継がれます。 ファイルとフォルダーの ACL に基づく承認は、オンプレミスの SMB 共有の場合と同様に機能します。
- ビジネス継続性: 既存の環境への Azure ファイル共有の統合には、多くの場合、既存の共有アドレスの保持が必要になります。 まだ DFS 名前空間を使用していない場合は、環境内でそれを確立することを検討してください。 ユーザーとスクリプトが使用する共有アドレスを変更せずに維持できます。 DFS-N でクライアントを Azure ファイル共有にリダイレクトすると、SMB の名前空間ルーティング サービスが提供されます。
このビデオは、簡単な 5 つのステップでインフォメーション ワーカーやアプリに直接 Azure ファイル共有を安全に公開する方法についてのガイドとデモです。
このビデオでは、次のトピックに関する専用のドキュメントが参照されています。 Azure Active Directory は Microsoft Entra ID になりましたので注意してください。 詳細については、「Azure AD の新しい名前」を参照してください。
移行ガイド
移行シナリオに適したツールを選択することが重要です。 次の表は、SMB Azure ファイル共有に移行するための推奨されるツールの組み合わせです。
この表の使用方法
ファイルが現在保存されているソースシステムの行を探します。
次のいずれかのターゲットを選択します。
- ハイブリッド展開:Azure File Sync を使用して、Azure ファイル共有のコンテンツをオンプレミスにキャッシュし、使用頻度の低いファイルをクラウドに階層化します。
- クラウドのみのデプロイ: オンプレミスのキャッシュを使用しない、クラウド内の Azure ファイル共有です。
選択した内容に一致するターゲット列を選択します。
ソースとターゲットが交差するテーブル セルに、使用可能な移行シナリオが示されています。 移行ガイドを表示するには、1 つを選択します。
シナリオにリンクがない場合は、公開されている移行ガイドがまだありません。 この表を定期的にチェックして、更新の有無をご確認ください。
ソース | ターゲット: ハイブリッド デプロイ (Azure Files と Azure File Sync) |
ターゲット: クラウドのみのデプロイ (Azure Files) |
---|---|---|
推奨されるツールの組み合わせ: | 推奨されるツールの組み合わせ: | |
Windows Server 2012 R2 以降 |
|
|
Windows Server 2012 以前 |
|
|
Linux (SMB) |
|
|
ネットワーク接続ストレージ (NAS) |
ファイル コピー ツール
移行シナリオに適したツールを選択するには、これらの基本的な質問を検討します。
ツールによって、ファイル コピーのソースとターゲットの場所がサポートされているか。
ソースとターゲットの保存場所の間のネットワーク パスまたは使用可能なプロトコル (REST や SMB など) がサポートされているか。
ツールによって、ソースとターゲットの場所でサポートされている必要なファイルの忠実性が保持されるか。
場合によっては、ターゲット ストレージで、ソースと同じ忠実性がサポートされていないことがありますが、 ターゲット ストレージが必要性を十分に満たすものである場合、ツールはターゲットのファイル忠実性の機能にのみ適合する必要があります。
ツールには、移行戦略にツールを適合させるための機能があるか。
たとえば、ツールでダウンタイムを最小化できるかどうかを検討します。
ソースをターゲットにミラーリングするオプションがツールでサポートされている場合、ソースにアクセスできる間に通常は同じソースおよびターゲットでツールを複数回実行できます。
ツールを最初に実行するときに、データの大部分がコピーされます。 この最初の実行は、しばらく時間がかかる場合があります。 多くの場合、ビジネス プロセスのためにデータ ソースをオフラインにするのに要する時間よりも長くかかります。
ソースをターゲットにミラーリングすることにより (robocopy /MIR と同様)、同じソースとターゲットでツールを再度実行できます。 転送する必要があるのは前回の実行後に発生したソースの変更のみであるため、この 2 回目の実行ははるかに速くなります。 この方法でコピー ツールを再実行すると、ダウンタイムを大幅に短縮できます。
次の表は、Microsoft ツールと、SMB Azure ファイル共有との現時点での適合性を分類したものです。
推奨 | ツール | Azure ファイル共有のサポート | ファイルの忠実性の保持 |
---|---|---|---|
![]() |
Azure Storage Mover | サポートされています。 | 完全な忠実性。* |
![]() |
Azure Data Box | サポートされています。 | 完全な忠実性。* |
![]() |
RoboCopy | サポートされています。 Azure ファイル共有は、ネットワーク ドライブとしてマウントできます。 | 完全な忠実性。* |
![]() |
Azure File Sync | Azure ファイル共有にネイティブに統合されます。 | 完全な忠実性。* |
![]() |
Azure Storage Migration Program | サポートされています。 | 完全な忠実性。* |
![]() |
記憶域移行サービス | 間接的にサポートされています。 Azure ファイル共有は、SMS ターゲット サーバーでネットワーク ドライブとしてマウントできます。 | 完全な忠実性。* |
![]() |
Data Box (デバイスにファイルを読み込むデータ コピー サービスを含む) | サポートされています。
(Data Box Disk では大きいファイルの共有はサポートされません) |
Data Box と Data Box Heavy では、メタデータが完全にサポートされます。
Data Box Disk では、ファイルのメタデータは維持されません。 |
![]() |
AzCopy 最新バージョン |
サポートされていますが、完全には推奨されません。 | 大規模な差分コピーはサポートされていないため、一部のファイルの忠実性が失われる可能性があります。
Azure ファイル共有で AzCopy を使用する方法を確認する |
![]() |
Azure Storage Explorer 最新バージョン |
サポートはされますが、推奨はされません。 | ACL など、ほとんどのファイルの忠実性が失われます。 タイムスタンプがサポートされます。 |
![]() |
Azure Data Factory | サポートされています。 | メタデータがコピーされません。 |
"* 完全な忠実性: Azure ファイル共有の機能を満たすか上回っています。''
移行ヘルパー ツール
このセクションでは、移行の計画と実行に役立つツールについて説明します。
Azure Storage Mover
Azure Storage Mover は、ファイルとフォルダーを、基になる Azure ファイル共有と同じレベルのファイル忠実度で SMB Azure ファイル共有に移行できる、比較的新しいフル マネージド移行サービスです。 フォルダー構造とメタデータ値 (ファイルとフォルダーのタイムスタンプ、ACL、ファイル属性など) が保持されます。 Azure Files で Azure Storage Mover を使用する方法については、「Azure Storage Mover を使って SMB Azure ファイル共有に移行する」を参照してください。
RoboCopy
Windows に含まれる RoboCopy は、SMB ファイルの移行に非常に役立ちます。 RoboCopy のドキュメントは、このツールの多くのオプションに役立つリソースです。
Azure Storage Migration Program
データを理解することは、適切な Azure ストレージ サービスと移行戦略を選択するための最初の手順です。 Azure Storage Migration Program には、データとストレージ インフラストラクチャを分析して貴重な分析情報を提供できるさまざまなツールが用意されています。 これらのツールは、データのサイズと型、ファイルとフォルダーの数、アクセス パターンを理解するのに役立つ場合があります。 データの統合ビューが提供され、さまざまなカスタマイズされたレポートの作成を可能にします。
この情報は次の場合に役立ちます。
- 重複および冗長データ セットを特定する
- より安価なストレージに移動できるよりコールドなデータを特定する
詳細については、「Azure Storage Migration Program の参加者向けの比較表」を参照してください。
JAM Software GmbH 製の TreeSize
Azure File Sync は、合計ストレージ容量ではなく、主に項目 (ファイルとフォルダー) の数に基づいてスケーリングされます。 TreeSize ツールを使用すると、Windows Server ボリューム上の項目数を確認できます。
このツールを使用すると、Azure File Sync のデプロイの前にパースペクティブを作成できます。 デプロイ後にクラウドの階層化が使用されている場合にも使用できます。 このシナリオでは、項目数と、サーバー キャッシュを最も使用するディレクトリが表示されます。
このツールのテスト済みのバージョンはバージョン 4.4.1 です。 クラウド階層化ファイルと互換性があります。 通常の操作中に、階層化ファイルがこのツールによって再度呼び出されることはありません。