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 のドキュメントを参照してください。

    Note

    Invoke-AzStorageSyncChangeDetection PowerShell コマンドレットは、最大 10,000 個の項目のみを検出できます。 その他の制限事項については、「Invoke-AzStorageSyncChangeDetection」 のドキュメントを参照してください。

    Note

    REST を使用して Azure ファイル共有に加えられた変更は、SMB の最終更新時間を更新するものではなく、同期による変更とは見なされません。

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

  • 同じファイルが 2 つのサーバー上でほぼ同時に変更されると、どうなりますか?
    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 エンジニアから明示的に指示された場合を除き、サーバー エンドポイントを削除しないことをお勧めします。 サーバー エンドポイントの削除の詳細については、「サーバー エンドポイントを削除する」を参照してください。

  • ストレージ同期サービスやストレージ アカウントを、別のリソース グループ、サブスクリプション、または Azure AD テナントへ移動できますか?
    はい。ストレージ同期サービスやストレージ アカウントは、別のリソース グループ、サブスクリプション、または Azure AD テナントに移動できます。 ストレージ同期サービスまたはストレージ アカウントを移動した後、Microsoft.StorageSync アプリケーションにストレージ アカウントへのアクセス権を付与する必要があります (「Azure File Sync がストレージ アカウントへのアクセス権を持っていることを確認します」を参照してください)。

    Note

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

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

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

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

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

  • Azure File Sync ではディレクトリの LastWriteTime が同期されますか?
    いいえ。Azure File Sync ではディレクトリの 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 を使用するための回避策として DFS 名前空間 (DFS-N) を使用することはできますか?

    Azure Files で ABE を使用するシナリオは現在サポートされていませんが、SMB Azure ファイル共有で DFS-N を使用することはできます。 ABE は DFS-N の機能であるため、ID ベースの認証を構成し、ABE 機能を有効にすることはできます。 ただし、それが適用されるのは DFS-N フォルダー ターゲットのみで、対象のファイル共有自体にさかのぼって適用されることはありません。 DFS-N は、フォルダー ターゲットの手前にあるプロキシとしてではなく、参照によって機能するためです。

    たとえば、「\mydfsnserver\share」というパスをユーザーが入力した場合、SMB クライアントは \mydfsnserver\share => \server123\share の参照を受け取り、後者に対してマウントします。

    そのため ABE が機能するのは、DFS-N サーバーがリダイレクトの前にユーザー名のリストをホストしている場合に限られます。

    \DFSServer\users\contosouser1 => \SA.file.core.windows.net\contosouser1 \DFSServer\users\contosouser1 => \SA.file.core.windows.net\users\contosouser1

    (contosouser1users 共有のサブフォルダー)

    各ユーザーがリダイレクト "後" のサブフォルダーである場合、ABE は機能しません。

    \DFSServer\SomePath\users --> \SA.file.core.windows.net\users

AD DS および Azure AD DS 認証

  • Azure Active Directory Domain Services (Azure AD DS) では、Azure AD に参加している、または登録されたデバイスからの Azure AD 資格認証を利用する SMB アクセスをサポートしますか?

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

  • 別のサブスクリプションの VM からの Azure AD 資格認証によって、Azure ファイル共有にアクセスすることはできますか?

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

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

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

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

    Azure Files オンプレミス AD DS 認証は、ストレージ アカウントが登録されているドメイン サービスのフォレストにのみ統合されます。 別のフォレストからの認証をサポートするには、環境でフォレストの信頼が正しく構成されている必要があります。 Azure Files を AD DS に登録する方法は、通常のファイル サーバーとほとんど同じです。このサーバーでは、認証のために AD で ID (コンピューターまたはサービスのログオン アカウント) が作成されます。 唯一の違いは、ストレージ アカウントの登録済み SPN が、ドメイン サフィックスと一致しない "file.core.windows.net" で終了することです。 ドメインの管理者に問い合わせて、ドメイン サフィックスが異なることで、複数のフォレスト認証を有効にするためにサフィックス ルーティング ポリシーの更新が必要かどうかを確認してください。 サフィックス ルーティング ポリシーを構成する例を次に示します。

    例: フォレスト A ドメインのユーザーが、フォレスト B のドメインに対して登録されたストレージ アカウントを使用してファイル共有にアクセスしたい場合、そのストレージ アカウントのサービス プリンシパルにはフォレスト A 内のどのドメインのサフィックスとも一致するサフィックスがないため、自動的には機能しません。この問題に対処するには、"file.core.windows.net" のカスタム サフィックスに対して、フォレスト A からフォレスト B へのサフィックス ルーティング規則を手動で構成します。

    まず、フォレスト B に新しいカスタム サフィックスを追加する必要があります。構成を変更するための適切な管理者アクセス許可があることを確認してから、次の手順を行います。

    1. フォレスト B のドメインに参加しているマシンにログオンします
    2. [Active Directory ドメインと信頼関係] コンソールを開きます。
    3. [Active Directory ドメインと信頼関係] を右クリックします
    4. [プロパティ] を選択します。
    5. [追加] を選択します。
    6. UPN サフィックスとして "file.core.windows.net" を追加します
    7. [適用][OK] の順に選択してウィザードを閉じます。

    次に、フォレスト A にサフィックスのルーティング規則を追加し、フォレスト B にリダイレクトされるようにします。

    1. フォレスト A のドメインに参加しているマシンにログオンします。
    2. [Active Directory ドメインと信頼関係] コンソールを開きます。
    3. ファイル共有にアクセスするドメインを右クリックし、[信頼] タブをクリックし、出力方向の信頼からフォレスト B のドメインを選択します。 2 つのフォレスト間に信頼を構成していない場合は、最初に信頼を設定する必要があります。
    4. [プロパティ][サフィックスのルーティングに名前を付けます] の順に選択します。
    5. "*.file.core.windows.net" サフィックスが表示されるかどうかを確認します。 されない場合は、[更新] をクリックします。
    6. "*.file.core.windows.net" を選択し、[有効][適用] をクリックします。
  • コンピューター アカウントの作成と、AD でストレージ アカウントを表すサーバー ログオン アカウントの作成に違いはありますか?

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

  • ストレージ アカウント キーを利用してキャッシュされた資格認証を削除し、既存の SMB 接続を削除してから、Azure AD または AD 認証を持つ新しい接続を初期化するにはどうしますか?

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

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

      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

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

    Windows エクスプローラーでは、Azure Files でホストされているファイルとディレクトリの UPN の代わりに、ファイル/ディレクトリ所有者の SID が表示されます。 ただし、次の PowerShell コマンドを使用して、ディレクトリ内のすべての項目とその所有者 (UPN を含む) を表示できます。

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

Network File System (NFS v4.1)

  • Azure Files NFS はいつ使用すべきですか?

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

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

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

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

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

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

共有スナップショット

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

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

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

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

課金と価格

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

関連項目