Azure Files に関してよく寄せられる質問 (FAQ)

  • [アーティクル]

Azure Files は、業界標準のサーバー メッセージ ブロック (SMB) プロトコルおよびネットワーク ファイル システム (NFS) プロトコル経由でアクセスできる、クラウド内のフル マネージドのファイル共有を提供します。 Azure ファイル共有は、クラウドまたはオンプレミスにデプロイされた Windows、Linux、macOS で同時にマウントできます。 また、Azure File Sync を使用すると、Windows Server マシンに Azure ファイル共有をキャッシュし、データが使用される場所に近接する高速アクセスを実現できます。

Azure File Sync

  • ドメイン参加のサーバーおよびドメイン非参加のサーバーを、同じ同期グループに含めることはできますか?
    はい。 異なる Active Directory に属しているサーバー エンドポイントを 1 つの同期グループに含めることは可能です。ドメインに参加していない場合でも同様です。 この構成は技術的には機能するものの、通常の構成としては、お勧めしません。あるサーバー上のファイルやフォルダー用に定義されたアクセス制御リスト (ACL) が、同期グループ内の他のサーバーでは適用できない可能性があるためです。 最良の結果を得るには、同じ Active Directory フォレスト内にあるサーバー間、別の Active Directory フォレスト内にあるものの信頼関係が確立されているサーバー間、またはドメインに属していないサーバー間で同期することをお勧めします。 これらの構成を混在させることは避けるようにしてください。

  • SMB またはポータルを使用して Azure ファイル共有上でファイルを直接作成しました。このファイルを同期グループのサーバーで同期するには、どのくらいの時間がかかりますか?

    Azure Portal または SMB を使用して Azure ファイル共有に加えられた変更は、サーバー エンドポイントに対する変更とは異なり、検出とレプリケーションが即座に行われることはありません。 Azure Files にはまだ変更通知/ジャーナルがないため、ファイルが変更されたときに自動的に同期セッションを開始する方法はありません。 Windows Server では、Azure File Sync は Windows USN ジャーナルを使用して、ファイルが変更されたときに同期セッションを自動的に開始します。

    Azure ファイル共有に対する変更を検出するために、Azure File Sync には、変更検出ジョブと呼ばれるスケジュールされたジョブがあります。 変更検出ジョブは、ファイル共有内のすべてのファイルを列挙した後、ファイルの同期バージョンと比較します。 変更検出ジョブによってファイルが変更されていると判断された場合に、Azure File Sync は同期セッションを開始します。 変更検出ジョブは 24 時間ごとに実行されます。 変更検出ジョブは Azure ファイル共有内のすべてのファイルを列挙することで機能するため、変更の検出は、大きな名前空間のほうが小さな名前空間よりも時間がかかります。 大規模な名前空間の場合、変更されたファイルを判断するのに 24 時間ごとに 1 回より長くなる場合があります。

    Azure ファイル共有で変更されたファイルを直ちに同期したければ、Invoke-AzStorageSyncChangeDetection PowerShell コマンドレットを使用すると、Azure ファイル共有における変更の検出を手動で開始できます。 このコマンドレットは、一部の自動プロセスによって Azure ファイル共有に変更が加えられたり、管理者によって変更が行われるシナリオ (ファイルやディレクトリを共有に移動するなどの) を意図したものです。 エンド ユーザーの変更に関しては、Azure File Sync エージェントを IaaS VM にインストールし、エンド ユーザーに IaaS VM 経由でファイル共有にアクセスしてもらうことをお勧めします。 このように、すべての変更が迅速に他のエージェントと同期され、Invoke-AzStorageSyncChangeDetection コマンドレットを使う必要はありません。 詳細については、Invoke-AzStorageSyncChangeDetection のドキュメントを参照してください。

    Windows Server 上のボリュームに対する更新シーケンス番号 USN のように、Azure ファイル共有への変更検出について調査を行っています。 今後この機能の開発を優先的に進めるために、Azure コミュニティ フィードバックで投票をお願いします。

  • 同じファイルが 2 つのサーバー上でほぼ同時に変更されると、どうなりますか?
    ファイルの競合は、Azure ファイル共有内のファイルがサーバー エンドポイントの場所にあるファイルと一致しない (サイズや最終変更時刻が異なる) 場合に発生します。

    次のシナリオでは、ファイルの競合が発生する可能性があります。

    • エンドポイント (例: サーバー A) でファイルが作成または変更されます。 サーバー A での変更がそのエンドポイントに同期される前に、別のエンドポイントで同じファイルが変更された場合、競合ファイルが作成されます。
    • サーバー エンドポイントの作成前に、Azure ファイル共有とサーバー エンドポイントの場所にファイルが存在していました。 サーバー エンドポイントの作成時に、サーバーと Azure ファイル共有とでファイルのファイル サイズや最終変更時刻が異なる場合、競合ファイルが作成されます。
    • 破損が発生したかナレッジの制限に達したため、同期データベースが再作成されました。 データベースが再作成されると、同期は調整というモードになります。 調整が発生したときに、サーバーと Azure ファイル共有とでファイルのファイル サイズや最終変更時刻が異なる場合、競合ファイルが作成されます。

    Azure File Sync では、シンプルな競合解決方法が採用されています。ファイルに対して 2 つのエンドポイントで同時に変更を加えた場合、その両方の変更が保持されます。 最後に書き込まれた変更では、元のファイル名が維持されます。 (LastWriteTime によって決定される) 古いファイルには、エンドポイント名と競合番号がファイル名に追加されます。 サーバー エンドポイントの場合、エンドポイント名はサーバーの名前です。 クラウド エンドポイントの場合、エンドポイント名は Cloud です。 名前は、次の命名規則に従います。

    <FileNameWithoutExtension>-<endpointName>[-#].<ext>

    たとえば、CompanyReport.docx で競合が生じたとします。以前の書き込みが CentralServer で発生した場合、最初の競合ではファイル名 CompanyReport.docx が、CompanyReport-CentralServer.docx となります。 2 回目の競合では、CompanyReport-CentralServer-1.docx という名前になります。 Azure File Sync は、1 つのファイルにつき 100 個の競合ファイルをサポートします。 競合ファイルの最大数に達すると、競合ファイルの数が 100 個未満になるまで、ファイルの同期は失敗します。

  • クラウドの階層化を無効にしていても、サーバー エンドポイントの場所に階層化されたファイルが存在するのはなぜですか?
    階層化されたファイルがサーバー エンドポイントの場所に存在する理由には、次の 2 つがあります。

    • 新しいサーバー エンドポイントを既存の同期グループに追加すると、最初に名前空間を呼び戻すオプションか、初期ダウンロード モードで名前空間のみを呼び戻すオプションのいずれかを選択します。この場合、ファイルはローカルにダウンロードされるまで、階層化された状態で表示されます。 これを回避するには、初期ダウンロード モードで、階層化されたファイルを除くオプションを選択します。 手動でファイルを呼び戻すには、Invoke-StorageSyncFileRecall コマンドレットを使用します。

    • サーバー エンドポイントでクラウドの階層化が有効になっていて、その後無効になった場合、ファイルはアクセスされるまで階層化されたままになります。

  • Windows エクスプローラーで階層化されたファイルのサムネイルやプレビューが表示されないのはなぜですか?
    階層化されたファイルの場合、サムネイルとプレビューはサーバー エンドポイントでは表示されません。 Windows のサムネイル キャッシュ機能は、オフライン属性が設定されたファイルの読み取りを意図的にスキップするため、これは予期されている動作です。 クラウドを使った階層化が有効になっている場合、階層化されたファイルを読み取ると、それらがダウンロード (呼び戻し) されます。

    この動作は Azure File Sync 固有ではありません。Windows エクスプローラーでは、オフライン属性が設定されているすべてのファイルに対して "グレーの X" が表示されます。 この X のアイコンは、SMB 経由でファイルにアクセスすると表示されます。 この動作の詳細については、「オフラインとマークされているファイルのサムネイルを取得しない理由」に関する記事を参照してください

    階層化されたファイルの管理方法については、「階層化ファイルの管理方法」を参照してください。

  • 階層化されたファイルが、サーバー エンドポイントの名前空間の外部に存在するのはなぜですか?
    Azure File Sync エージェント バージョン 3 以前の Azure File Sync は、サーバー エンドポイントと同じボリューム上であっても、サーバー エンドポイントの外部に存在する階層化されたファイルが移動することをブロックしていました。 他のボリュームに対する、コピー操作、階層化されていないファイルの移動、および階層化されたファイルの移動は、影響を受けませんでした。 このような動作の理由は、ファイル エクスプローラーおよび他の Windows の API による同じボリューム上での移動操作は、(ほとんど) 瞬時の名前変更操作であるという、暗黙の仮定によるものでした。 これは、Azure File Sync がクラウドからデータを呼び戻している間、エクスプローラーや他の移動方法 (コマンド ラインや PowerShell など) が応答しないように見えることを意味します。 Azure File Sync エージェント バージョン 3.0.12.0 以降の Azure File Sync では、サーバー エンドポイントの外部にある階層化されたファイルを移動できます。 階層化されたファイルがサーバー エンドポイントの外部で階層化されたファイルとして存在できるようにし、バックグラウンドでファイルを呼び戻すことにより、上で説明したような悪影響を防ぎます。 つまり、同じボリューム上での移動は瞬時であり、移動が完了した後で、ファイルをディスクに呼び戻すためのすべての処理を行います。

  • サーバー上の Azure File Sync で同期、クラウド、階層化などに問題があります。サーバー エンドポイントを削除し、再度作成すべきですか?

    いいえ。サーバー エンドポイントの削除は、サーバーの再起動とは異なります。 サーバー エンドポイントを削除して再作成する操作が、同期、クラウドの階層化などの Azure File Sync の側面に関する問題を解決するために適した解決策になることはほぼありません。サーバー エンドポイントの削除は、破壊的な操作です。 階層化されたファイルがサーバー エンドポイントの名前空間の外部に存在する場合、データが失われる可能性があります。 詳細については、「階層化されたファイルがサーバー エンドポイント名前空間の外部に存在するのはなぜですか」を参照してください。 または、サーバーエンド ポイント名前空間内に存在する階層化されたファイルのファイルにアクセスできなくなる可能性があります。 このような問題は、サーバー エンドポイントを再作成しても解決しません。 クラウドの階層化を有効にしていない場合でも、階層化されたファイルがサーバー エンドポイントの名前空間内に存在する可能性があります。 そのため、特定のフォルダーで Azure File Sync の使用を停止したい場合や、Microsoft エンジニアから明示的に指示された場合を除き、サーバー エンドポイントを削除しないことをお勧めします。 サーバー エンドポイントの削除の詳細については、「サーバー エンドポイントを削除する」を参照してください。

  • ストレージ同期サービスやストレージ アカウントを、別のリソース グループ、サブスクリプション、または Microsoft Entra テナントに移動できますか?
    はい。ストレージ同期サービスやストレージ アカウントを、別のリソース グループ、サブスクリプション、または Microsoft Entra テナントに移動できます。 ストレージ同期サービスまたはストレージ アカウントを移動した後、Microsoft.StorageSync アプリケーションにストレージ アカウントへのアクセス権を付与する必要があります。 次の手順のようにします。

    1. Azure portal にサインインし、左側のナビゲーションから [アクセス制御 (IAM)] を選択します。

    2. [ロールの割り当て] タブを選択して、ストレージ アカウントにアクセスできるユーザーとアプリケーション (サービス プリンシパル) を一覧表示します。

    3. Microsoft.StorageSync またはハイブリッド ファイル同期サービス (古いアプリケーション名) が一覧に閲覧者とデータ アクセス ロールで表示されるか確認します。

      Microsoft.StorageSync またはハイブリッド ファイル同期サービスが一覧表示されない場合は、次の手順を行います。

      • [追加] を選択します。
      • [ロール] フィールドで、 [閲覧者とデータ アクセス] を選択します。
      • [選択] フィールドに「Microsoft.StorageSync」と入力し、ロールを選択し、[保存] を選択します。

      Note

      クラウド エンドポイントを作成するときは、ストレージ同期サービスとストレージ アカウントが同じ Microsoft Entra テナントに存在する必要があります。 クラウド エンドポイントが作成されたら、ストレージ同期サービスとストレージ アカウントを別の Microsoft Entra テナントに移動できます。

  • Azure File Sync は、ディレクトリ/ファイルのレベルの NTFS ACL を Azure Files に格納されたデータと共に保持しますか?

    2020 年 2 月 24 日の時点で、Azure File Sync によって階層化された新規および既存の ACL は NTFS 形式で保存され、Azure ファイル共有に直接加えられた ACL の変更は、同期グループ内のすべてのサーバーに同期されます。 Azure ファイル共有に対する ACL の変更は、Azure File Sync によって同期されます。Azure Files にデータをコピーするときは、必要な "忠実性" をサポートするコピー ツールを使用して、属性、タイムスタンプ、ACL を SMB または REST 経由で Azure ファイル共有に必ずコピーしてください。 AzCopy などの Azure コピー ツールを使用する場合は、最新バージョンを使用することが重要です。 ファイル コピー ツールの表をチェックして、Azure コピー ツールの概要を確認し、ファイルの重要なメタデータをすべてコピーできることを確認します。

    Azure File Sync で管理されているファイル共有に対して Azure Backup を有効にした場合、ファイル ACL をバックアップ復元ワークフローの一部として引き続き復元できます。 これは、共有全体または個々のファイル/ディレクトリに対して機能します。

    Azure File Sync によって管理されるファイル共有の自己管理型バックアップ ソリューションの一部としてスナップショットを使用している場合、スナップショットが 2020 年 2 月 24 日より前に作成されていると、ACL が NTFS ACL に正しく復元されないことがあります。 この問題が発生した場合は、Azure サポートに連絡することを検討してください。

  • Azure File Sync はディレクトリの LastWriteTime を同期しますか? ディレクトリ内のファイルが変更されたときに、"変更日" の timestamp が更新されないのはなぜですか?
    いいえ。Azure File Sync ではディレクトリの LastWriteTime が同期されません。 さらに、ディレクトリ内のファイルが変更された場合、Azure Files はディレクトリの変更日の timestamp (LastWriteTime) を更新しません。 これは正しい動作です。

セキュリティ、認証、およびアクセス制御

  • Azure Files では、ファイルのアクセスと変更をどのように監査できますか?

    次の 2 つのオプションによって、Azure Files の監査機能を使用できます。

    • ユーザーが Azure ファイル共有に直接アクセスしている場合は、トラブルシューティングのために、Azure Storage ログを使用して、ファイルの変更とユーザー アクセスを追跡できます。 要求は、ベスト エフォートでログに記録されます。
    • Azure File Sync エージェントがインストールされている Windows Server 経由でユーザーが Azure ファイル共有にアクセスしている場合は、監査ポリシー またはサードパーティ製品を使用して、Windows Server 上のファイルの変更とユーザー アクセスを追跡します。

  • Azure Files では、アクセスベースの列挙 (ABE) を使用して SMB Azure ファイル共有内のファイルとフォルダーの可視性を制御できますか?

    Azure Files での ABE の使用は現在サポートされていませんが、SMB Azure ファイル共有で DFS-N を使用することはできます。

ID ベースの認証

  • Microsoft Entra Domain Services では、Microsoft Entra ID に参加しているか登録されているデバイスからの Microsoft Entra 資格情報を使用した SMB アクセスはサポートされていますか?

    いいえ、このシナリオはサポートされていません。

  • ID ベースの認証を使用しているときに、正規名 (CNAME) を使用して Azure ファイル共有をマウントできますか?

    はい。このシナリオは、SMB Azure ファイル共有の単一フォレスト環境とマルチフォレスト環境の両方でサポートされるようになりました。 ただし、Azure Files では、ドメイン プレフィックスとしてストレージ アカウント名を使用する CNAME の構成のみがサポートされています。 プレフィックスとしてストレージ アカウント名を使いたくない場合は、DFS 名前空間の使用を検討してください。

  • 異なるサブスクリプションの VM から Microsoft Entra 資格情報を使用して Azure ファイル共有にアクセスすることはできますか?

    ファイル共有のデプロイ元であるサブスクリプションが、VM のドメイン参加先である Microsoft Entra Domain Services デプロイと同じ Microsoft Entra テナントに関連付けられている場合は、同じ Microsoft Entra 資格情報を使用して Azure ファイル共有にアクセスできます。 制限は、サブスクリプションにではなく、関連付けられている Microsoft Entra テナントに課せられます。

  • Azure ファイル共有のプライマリ テナントとは異なる Microsoft Entra テナントを使用し、Azure ファイル共有のために Microsoft Entra Domain Services またはオンプレミス AD DS 認証を有効にすることはできますか?

    不正解です。 Azure Files では、ファイル共有と同じサブスクリプションに存在する Microsoft Entra テナントとの Microsoft Entra Domain Services またはオンプレミス AD DS 統合のみがサポートされます。 サブスクリプションは、1 つの Microsoft Entra テナントにのみ関連付けることができます。 認証にオンプレミス AD DS を使用する場合は、ストレージ アカウントが関連付けられている Microsoft Entra ID に AD DS 資格情報を同期する必要があります。

  • Azure ファイル共有のオンプレミス AD DS 認証は、複数のフォレストを使用する AD DS 環境との統合をサポートしますか?

    Azure Files オンプレミス AD DS 認証は、ストレージ アカウントが登録されているドメイン サービスのフォレストにのみ統合されます。 別のフォレストからの認証をサポートするには、環境でフォレストの信頼が正しく構成されている必要があります。 詳細な手順については、「複数の Active Directory フォレストで Azure Files を使用する」を参照してください。

    注意

    マルチフォレストのセットアップでは、ルート、ディレクトリ、またはファイル レベルで Windows ACL および NTFS アクセス許可を構成するためにエクスプローラーを使用しないでください。 代わりに icacls を使用してください。

  • コンピューター アカウントの作成と、AD でストレージ アカウントを表すサーバー ログオン アカウントの作成に違いはありますか?

    コンピューター アカウント (既定) または サービスのログオン アカウントのいずれを作成しても、認証が Azure Files でどのように機能するかに違いはありません。 ストレージ アカウントをご利用の AD 環境内の ID として表す方法については、自分自身で選択することができます。 Join-AzStorageAccountForAuth コマンドレットに設定されている既定の DomainAccountType がコンピューター アカウントです。 ただし、ご利用の AD 環境で構成されているパスワードの有効期限は、コンピューター アカウントまたはサービス ログオン アカウントによって異なる可能性があります。また、AD でストレージ アカウント ID のパスワードを更新することを考慮する必要があります。

  • Microsoft Entra ID または AD 資格情報を使用して新しい接続を初期化する前に、ストレージ アカウント キーを使ってキャッシュされた資格情報を削除し、既存の SMB 接続を削除するにはどうすればよいですか?

    次の 2 段階のプロセスに従って、ストレージ アカウント キーに関連付けられている保存済みの資格情報を削除し、SMB 接続を削除します。

    1. Windows コマンド プロンプトから次のコマンドを実行して、資格情報を削除します。 資格情報が見つからない場合は、保存されていないという意味なので、この手順は省略できます。

      cmdkey /delete:Domain:target=storage-account-name.file.core.windows.net

    2. ファイル共有への既存の接続を削除します。 マウント パスは、マウントされたドライブ文字または storage-account-name.file.core.windows.net パスのいずれかとして指定できます。

      net use <drive-letter/share-path> /delete

  • エクスプローラーで、セキュリティ識別子 (SID) の代わりに、ファイルまたはディレクトリの所有者の userPrincipalName (UPN) を表示できますか?

    エクスプローラーを使用すると、サーバーに対して RPC API が直接呼び出され、SID が UPN に移動します。 Azure Files はこの API をサポートしていないため、エクスプローラーでは、Azure Files でホストされているファイルとディレクトリの UPN の代わりに、ファイルまたはディレクトリ所有者の SID が表示されます。 ただし、ドメイン参加クライアントから、次の PowerShell コマンドを使用して、ディレクトリ内のすべての項目とその所有者 (UPN を含む) を表示できます。

    Get-ChildItem <Path> | Get-ACL | Select Path, Owner

Network File System (NFS v4.1)

  • NFS Azure ファイル共有はどのような場合に使用すべきですか?

    NFS 共有に関するページを参照してください。

  • NFS 共有では保存されたデータをどのようにバックアップしますか?

    NFS 共有上のデータのバックアップは、rsync などの使い慣れたツールや、サードパーティのバックアップ パートナーの製品などを使用するように計画できます。 Commvault、Veeam、Veritas を含む複数のバックアップ パートナーが、自社のソリューションを Azure Files の SMB 3.x と NFS 4.1 の両方で動作するように拡張しています。 NFS Azure ファイル共有スナップショット を使うこともできます。

  • 既存データを NFS 共有に移行できますか?

    同じリージョン内であれば、scp、rsync、SSHFS などの標準ツールを使用してデータを移動できます。 NFS Azure ファイル共有は複数のコンピューティング インスタンスから同時にアクセスできるため、並列アップロードによってコピー速度を向上させることができます。 詳細については、「Azure の NFS ファイル共有に移行する」を参照してください。 リージョンの外部からデータを取り込む場合は、VPN または ExpressRoute を使用して、オンプレミスのデータ センターからファイル システムにマウントします。

  • NFS Azure ファイル共有で IBM MQ (マルチインスタンスを含む) を実行できますか?

共有スナップショット

共有スナップショットを作成する

  • 利用している共有スナップショットは geo 冗長ですか?
    共有スナップショットには、そのスナップショットが取得された Azure ファイル共有と同じ冗長性があります。 お使いのアカウントに geo 冗長ストレージを選択した場合、共有スナップショットもペアになっているリージョンに冗長的に保存されます。

共有スナップショットをクリーンアップする

  • 共有スナップショットを削除せずに、共有を削除できますか?
    共有にアクティブな共有スナップショットがある場合、共有を削除することはできません。 API を使用して共有と一緒に共有スナップショットを削除することはできます。 共有スナップショットと共有の両方を削除するのであれば、Azure Portal で行うこともできます。

課金と価格

  • Azure Files のトランザクションとはどういうもので、どのように課金されますか? プロトコル トランザクションは、ユーザー、アプリケーション、スクリプト、またはサービスによる Azure ファイル共有の操作 (ファイルの書き込み、読み取り、一覧表示、削除など) のたびに発生します。 1 つの操作として認識する可能性がある一部のアクションには、実際には複数のトランザクションが関係する場合があることに注意してください。 従量課金制モデルで課金される標準の Azure ファイル共有の場合、種類が異なるトランザクションは、ファイル共有へのそれらの影響に基づいて異なる価格になります。 トランザクションは、プロビジョニングされたモデルを使用して課金される Premium ファイル共有の課金には影響しません。 詳細については、課金の概要に関する記事をご覧ください。

  • 共有スナップショットはどのように課金されますか?
    共有スナップショットは、本質的に増分です。 基本の共有スナップショットは、共有そのものです。 それ以降の共有スナップショットはすべて増分であり、先行する共有スナップショットとの差分のみが格納されます。 変更されたコンテンツに対してのみ、請求されます。 共有に 100 GiB のデータがあり、最新の共有スナップショットの後に 5 GiB だけが変更された場合、共有スナップショットは追加の 5 GiB のみを消費し、請求は 105 GiB に対して行われます。 トランザクションおよび標準エグレスの課金の詳細については、「Azure Files の価格」ページをご覧ください。

その他のサービスとの相互運用

  • Azure ファイル共有を Windows Server フェールオーバー クラスターの "監視用ファイル共有" として使用できますか。
    この構成は現在、Azure Files ではサポートされていません。 Azure Blob ストレージを使用してこれを設定する方法については、「フェールオーバー クラスターのクラウド監視を展開する」をご覧ください。

関連項目