次の方法で共有

Azure Files と Azure File Sync についてのよくあるご質問 (FAQ)

Azure Files は、業界標準のサーバー メッセージ ブロック (SMB) プロトコルおよびネットワーク ファイル システム (NFS) プロトコル経由でアクセスできる、クラウド内のフル マネージドのファイル共有を提供します。 Azure ファイル共有は、クラウドまたはオンプレミスにデプロイされた Windows、Linux、macOS で同時にマウントできます。 また、データが使用される場所に近接した Windows Server マシンに、Azure File Sync で 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 ファイル共有への初回アップロードが完了したとき、Azure File Sync によって同期グループ内のファイルが上書きされることはありません。 代わりに、シンプルな競合解決方法が採用されています。ファイルに対して 2 つのエンドポイントで同時に変更を加えた場合、その両方の変更が保持されます。 最後に書き込まれた変更では、元のファイル名が維持されます。 (LastWriteTime によって決定される) 古いファイルには、エンドポイント名と競合番号がファイル名に追加されます。 サーバー エンドポイントの場合、エンドポイント名はサーバーの名前です。 クラウド エンドポイントの場合、エンドポイント名は Cloud です。 名前は、次の命名規則に従います。

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

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

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

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

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

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

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

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

  • 階層化されたファイルのオフライン属性をスキップするオプションはありますか?

    階層化されたファイルのサムネイルとプレビューを表示する場合は、オフライン属性の設定をスキップするように Azure File Sync を構成できます。

    1. サーバーに次のレジストリ キーを追加します。

      reg ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Azure\StorageSync" /v SkipOfflineAttributeOnTieredFile /t RE

    2. FileSyncSvc サービスを再起動します。

    構成が完了したら、次の手順を実行します

    • 新しい階層化されたファイルには、オフライン属性がなくなりました。
    • 既存の階層化されたファイルは、次のメンテナンス実行で更新されます (24 時間ごとに発生します)。

    Note

    この設定は、特定の拡張機能ではなく、すべてのファイルにグローバルに適用されます。 オフライン属性がない場合、Windows エクスプローラーに別のアイコンが表示されます。 エクスプローラーで [属性] 列を追加して、階層化されたファイル (属性 ALM) を識別できます。 使用パターンに基づいて、オフライン属性をスキップするとファイルの呼び戻しが増加する可能性があるため、取り消しアクティビティを監視し、エグレス コストが許容範囲内に収まるようにする必要があります。 階層化されたファイルを管理する方法を参照してください。

  • 階層化されたファイルがサーバー エンドポイント名前空間の外部に存在するのはなぜですか。
    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 では、Azure Files の格納データと共にディレクトリ レベルまたはファイル レベルの NTFS ACL が保持されますか。

    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) を更新しません。 これは正しい動作です。

  • Dedup との相互運用の一部としてのクラウド階層化のボリューム領域のしくみ
    重複除去機能がインストールされている場合、重複除去の GC がトリガーされると、使用可能なボリューム領域が予想以上に増えることがあります。 たとえば、クラウド階層化の空き領域ポリシーが 20%に設定されているとします。 空き領域が少ないと、Azure File Sync に通知されます (空き領域が 19%の場合など)。 階層化では、1% より多くの領域を解放する必要があると判断されますが、バッファーとして 5% 余分に追加されるため、最大 25% (30 GiB など) を階層化します。 ファイルは、30 GiB に達するまで階層化されます。 Dedupとの相互運用の一環として、Azure File Syncは階層化セッション終了時にゴミ収集を開始します。

  • AFS サーバー上のウイルス対策ソフトウェアが階層化ファイルを再呼び出しするのはなぜですか?
    階層化ファイルにユーザーがアクセスすると、一部のウイルス対策 (AV) ソフトウェアによって、意図しないファイルの再呼び出しが発生する可能性があります。 これは、階層化ファイル (RECALL_ON_DATA_ACCESS 属性が指定されたもの) を AV ソフトウェアが無視するように構成されていない場合に発生します。 これは次のように動作します。

    1. ユーザーが階層化ファイルにアクセスしようとします。
    2. AV ソフトウェアは読み取りハンドルをブロックします。
    3. 次に、AV アプリケーションは独自の読み取りを実行して、ファイルのウイルスをスキャンします。

    このプロセスは、AV ソフトウェアが階層化ファイルを呼び出しているように見えるかもしれませんが、実際にはユーザーのアクセス試行によってトリガーされます。 この問題を防ぐには、RECALL_ON_DATA_ACCESS 属性が指定された階層化ファイルのスキャンを無視するように AV ベンダーがソフトウェアを構成していることを確認します。

  • SSL 検査ソフトウェアは AFS サーバーへのアクセスをブロックできますか? SSL 検査ソフトウェア (Zscaler や FortiGate など) が、Azure へのアクセスを Azure File Sync (AFS) サーバー エンドポイントに許可していることを確認します。 これらの SSL 検査ツールを使用して、ファイアウォール設定をオーバーライドし、トラフィックを選択的に許可することができます。 この問題を解決するには、ネットワーク管理者に問い合わせてください。 AFS サーバーでこの問題が発生しているかどうかを確認するには、"testnet" コマンドを使用します。

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

  • 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 を使用することはできます。

  • プリンターまたはスキャナーを使用して Azure ファイル共有に保存できますか?

    Azure Files では、Windows、Linux、macOS のみがサポートされます。 プリンターまたはスキャナーから Azure ファイル共有に直接アクセスすることはサポートされていません。 ただし、既に Azure File Sync を使用している場合は、Windows ファイル サーバーに印刷またはスキャンしてから、ファイルを Azure ファイル共有に同期できます。

  • Azure Files は代替データ ストリームをサポートしていますか?

Azure Files では、 代替データ ストリームはサポートされていません。 SMB 経由でデータを転送すると、代替データ ストリームが見つかった場合、 ファイルが既に存在 するメッセージがスローされます。 次の PowerShell コマンドを使用して、代替ストリームを確認できます。

get-item <file path+name> -Stream *

複数のストリームが表示されている場合は、次の PowerShell コマンドを使用して削除できます。

remove-Item <file path+name> -Stream *

Azure File Sync を使用すると、代替データ ストリームはオンプレミスに保持されます。

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 を使用する」を参照してください。

    Note

    マルチフォレストのセットアップでは、ルート、ディレクトリ、またはファイル レベルで 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

ネットワーク ファイル システム (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 冗長ストレージを選択した場合、共有スナップショットもペアになっているリージョンに冗長的に保存されます。

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

  • 共有スナップショットは削除せずに、共有を削除することはできますか。
    いいえ。 ファイル共有を削除するワークフローでは、共有を削除するとスナップショットが自動的に削除されます。

課金と価格

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

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

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

関連項目

  • Last updated on