トラブルシューティング

このページでは、Filestore の使用中に問題が発生した場合に役立つトラブルシューティング手順を示します。

パフォーマンスの低下

  1. クライアント VM に推奨マシンタイプを使用していることを確認します。
  2. クライアント VM が Linux を実行している場合は、デフォルトのマウント オプションを使用していることを確認します。

  3. クライアント VM が Filestore インスタンスと同じリージョンに配置されていることを確認します。リージョン間でマウントすると、パフォーマンスが低下するだけでなく、ネットワーク コストも発生します。

  4. Filestore インスタンスが最大容量に達していないか、ほぼ達していないことを確認します。容量がほぼいっぱいになると、残りの領域がかなり断片化されるため、読み取りと書き込みのオペレーションの速度が低下します。このような状況を回避するために必要な空き領域の量は、状況に応じて異なります。ディスク容量不足のアラートを設定することをおすすめします。

  5. fio ツールを使用して Filestore インスタンスのパフォーマンスをテストします

    テストの結果、パフォーマンスの異常な低下が見られる場合は、アカウント担当者にお問い合わせください。テスト結果が想定どおり、またはそれよりも高いことが判明した場合は、次のセクションに進みます。

パフォーマンスの低下につながるユースケース

パフォーマンスの低下につながるユースケースとシナリオを以下に示します。

サイズの小さいファイルを多数含むワークロード

Filestore のファイル共有は、データの安全性と NFS プロトコル準拠のために sync エクスポート オプションを使用します。つまり、ほとんどのデータ修正オペレーションでは、Filestore インスタンスはそのデータがストレージに commit されるまで待ってから、クライアント VM からのリクエストに応答します。オペレーションに多くのファイルが含まれていると、クライアントが長い一連の同期オペレーションを行い、累積レイテンシが加算されます。

この例として、TAR ファイルなどのファイル共有上のアーカイブを抽出する場合が挙げられます。TAR は、多数のファイルを含むアーカイブを抽出する際に、一連の多数の同期オペレーションを実行します。その結果、パフォーマンスは大幅に低下します。

多数のサイズの小さいファイルをファイル共有にコピーする場合は、gsutil などのツールでファイルの作成を並列化してみてください。

mkdir -p /mnt/nfs/many_files_rsync/
time gsutil -m -q rsync -rp many_files /mnt/nfs/many_files_rsync/

Cloud Storage と Filestore の間でデータをコピーする

gsutil を使用して Cloud Storage から Filestore インスタンスにデータをコピーする方法は現在、低速となることがわかっています。緩和策はわかっていません。

ファイル共有のマウント時とマウント解除時のレイテンシ

デフォルトのマウント オプションを使用してファイル共有をマウントすると、3 秒のレイテンシが発生します。これは、Filestore インスタンスのサポートされた転送方法の検出時にマウント コマンドの試行が行われたためです。

mountd デーモンは最初に、UDP を使用しようとしますが、Filestore ではサポートされていません。最初の試行がタイムアウトすると、TCP にフォールバックします。この検出プロセスをバイパスし、レイテンシが増加するのを防ぐには、tcp マウント オプションを指定します。次に例を示します。

sudo mount -o tcp 10.0.0.2:/vol1 /mnt/nfs

これは、autofs で自動マウントする場合に特に重要です。

Filestore が応答しない

Filestore インスタンスが ping または traceroute リクエストに応答しない

Filestore インスタンスは ICMP を許可していないため、ping リクエストまたは traceroute リクエストには応答しません。

Filestore インスタンスへの接続をテストするには、クライアントから showmount を実行します。

sudo showmount -e filestore-ip

Filestore インスタンスは、エクスポートされたファイルシステムで応答します。次に例を示します。

Export list for 10.139.19.98:
/vol1 192.168.0.0/16,172.16.0.0/12,10.0.0.0/8

次のコマンドを実行して、クライアントが Filestore の RPC 情報にアクセスできるかどうかを確認することもできます。

sudo rpcinfo -p <filestore-ip>

レスポンスは次のようになります。

program vers proto   port  service
 100000    4   tcp    111  portmapper
 100000    3   tcp    111  portmapper
 100000    2   tcp    111  portmapper
 100000    4   udp    111  portmapper
 100000    3   udp    111  portmapper
 100000    2   udp    111  portmapper
 100024    1   udp   2046  status
 100024    1   tcp   2046  status
 100003    3   tcp   2049  nfs
 100227    3   tcp   2049
 100021    1   udp   4045  nlockmgr
 100021    3   udp   4045  nlockmgr
 100021    4   udp   4045  nlockmgr
 100021    1   tcp   4045  nlockmgr
 100021    3   tcp   4045  nlockmgr
 100021    4   tcp   4045  nlockmgr
 100005    3   udp   2050  mountd
 100005    3   tcp   2050  mountd

定期メンテナンス

Filestore が数分間応答しなくなり、その後再び応答した場合、応答しない期間は、おそらく定期メンテナンス イベントが原因です。Filestore の SLA については、SLA ページをご覧ください。

Filestore は、カスタム定義のメンテナンスの時間枠をサポートしていません。お客様は、Filestore のメンテナンス時間枠のスケジュールも利用できません。

クライアントにマウントされている間にインスタンスが削除された

ファイル操作または UNIX コマンドの dfls、その他の読み取り/書き込みオペレーションが応答を停止した場合に、Filestore インスタンスはクライアントへのマウント中に削除された可能性があります。

インスタンスがまだ存在するかどうかを確認します。

    gcloud filestore instances list

インスタンスがもうリストにない場合、削除されたインスタンスと同じ IP アドレスとファイル共有名で新しいインスタンスを作成して、制御を復元できます。インスタンスが作成されると、応答のないオペレーションはエラーで終了します。ファイル共有のマウントの解除に進み、不要な場合は Filestore インスタンスを削除できます。

今後このような問題が発生しないよう、Filestore インスタンスを削除する前にマウントを必ず解除してください。

インスタンスがステータス REPAIRING を表示する

Filestore インスタンスは、ユーザーが制御できない内部原因の異常な状態であり、自動的に自己修復されます。この間、インスタンスは使用不能であり、これ以上のアクションは必要ありません。

容量の問題

「デバイスに空き容量がありません」

  1. クライアント VM で次のコマンドを実行して、Filestore インスタンスに十分な i ノードがあるかどうかを確認します。

    df -i
    

    コマンドから次のような結果が返されます。

    Filesystem           Inodes        IUsed      IFree         IUse%  Mounted on
    10.0.0.2:/vol1    134217728        13         134217715     1%     /mnt/test
    

    ファイル共有に保存されるファイルごとに 1 つの i ノードが消費されます。IUse% が 100% の場合、無料の inode がなく、割り当ての上限に達していなくてもファイル共有でこれ以上ファイルを保存できないことを意味します。inode の数は容量に応じて増減します。inode をさらに追加する場合は、容量を追加する必要があります。

  2. inode が残っている場合は、ディレクトリの最大エントリ数(ファイルまたはサブディレクトリ)に達した可能性があります。ディレクトリ内に存在できるエントリの最大数は、エントリの名前の長さによって異なります。ただし、この上限に達することは、確固とした上限というよりは確率的なものです。この問題を解決するには、エントリをサブディレクトリに分散して深いファイル階層を作成する必要があります。

「df」と「du」のコマンドで報告される空きディスク容量が異なる

実行中のプロセスによってオープンされているファイルが削除された場合、ファイルが消費するディスク容量は、ファイルが閉じられるまで解放されません。df コマンドは、削除されたオープン ファイルによって消費される容量を考慮しますが、du コマンドはそうしません。このため、du コマンドでは df よりも空き容量がしばしば多く表示されます。

実行中のプロセスによってまだオープンされているファイルを表示するには、次を実行します。

lsof | grep deleted

インスタンスを作成できない

Filestore インスタンスの作成時に PERMISSION DENIED

  1. Filestore API が有効になっているかどうかを確認します。

    gcloud services enable file.googleapis.com
    
  2. roles/file.editor ロールがあるかどうかを確認します。詳細については、IAM のロールと権限をご覧ください。

  3. 依然としてエラーが発生する場合は、Filestore サービス アカウントfile.serviceAgent ロールを削除された可能性があります。これを確認するには、次を実行します。

    gcloud projects get-iam-policy project-name  \
        --flatten="bindings[].members" \
        --format='table(bindings.role)' \
        --filter="bindings.members:service-project-id@cloud-filer.iam.gserviceaccount.com"
    

    ここで

    • project-name は Google Cloud プロジェクトの名前です。
    • project-id は、Google Cloud プロジェクトの ID です。

    このコマンドは、次のような出力を返します。

    ROLE
    roles/file.serviceAgent
    

    roles/file.serviceAgent がリストにない場合は、次を実行して復元できます。

    gcloud projects add-iam-policy-binding project-id --member serviceAccount:service-project-id@cloud-filer.iam.gserviceaccount.com --role roles/file.serviceAgent
    

    ここの project-id は Google Cloud プロジェクトの ID 番号です。

インスタンスの作成時にエラーコード 13 が表示される

インスタンスの作成中にエラーコード 13 エラーが生じる原因はいくつかありますが、最も一般的な原因は、Filestore が内部ネットワークの割り当ての上限に達したことです。

Filestore インスタンスを作成するすべての VPC ネットワークについて、Filestore ではそのネットワークとピアリングする内部ネットワークを作成する必要があります。これらの内部ネットワークは、Filestore インスタンスと、それらに関連付けられた VPC ネットワークが削除されても保持されます。

プロジェクトの内部ネットワーク数が 49 に達すると、Filestore は新しい内部ネットワークを作成できなくなります。このため、新しい VPC ネットワーク上に Filestore インスタンスを作成できなくなります。このような操作を行うと、エラーになります。

Error code 13, message: an internal error has occurred

内部ネットワークをクリアするための唯一の方法は、Filestore API を無効にしてから再度有効にすることです。API を無効にする前に、Filestore インスタンスやバックアップなど、Filestore 関連のすべてのリソースを削除する必要があります。

gcloud services disable file.googleapis.com

gcloud services enable file.googleapis.com

Filestore インスタンスが必要なために削除できない場合は、アカウント担当者に連絡して、ピアリングされるネットワークを手動でクリアする必要があります。

VPC ネットワークと Filestore インスタンスを定期的に削除して作成する必要がある場合、ネットワーク割り当ての不足を回避するには2つの方法があります。

  • VPC ネットワークを作成するときは、Filestore インスタンスの作成に使用された以前のネットワークと同じ名前を使用します。

  • 削除して再作成するのではなく、49 以下の VPC ネットワークのプールを循環します。

ファイル共有をマウントできない

VM または GKE Pod が Filestore にアクセスできない

次を実行して、Filestore インスタンスにアクセスできることを確認します(pingtraceroute はサポートされていません)。

sudo showmount -e <filestore-ip>

このコマンドは、エクスポートされたファイルシステムのリストを返すはずです。次を実行して、クライアントが Filestore の RPC 情報にアクセスできるかどうかを確認します。

sudo rpcinfo -p <filestore-ip>

Filestore インスタンスにアクセスできない場合、一般的な原因としては、ネットワーク設定や ACL の設定が正しくないことや、間違ったインスタンスをマウントしようとしていることが考えられます。

  1. IP ベースのアクセス制御が有効になっているかどうかを確認し、クライアントの IP アドレスが制限されているかどうかを確認します。詳細については、こちらをご覧ください。
  2. ファイアウォールの設定で、必要なポートが確実に開いていることを確認してください。詳細については、ファイアウォール ルールの構成をご覧ください。
  3. GKE クラスタから Filestore にアクセスしようとした場合に mount.nfs: access denied by server while mounting ... というエラーが発生している場合は、GKE クラスタからファイル共有にアクセスできないをご覧ください。

ファイル共有をマウントしようとしたときに権限が拒否されました

インスタンスに NFS エクスポート オプションがリスティングされているかどうかを確認します。

gcloud filestore instances describe instance-id \
    --zone=zone

ここで

  • instance-id は、Filestore のインスタンス ID です。
  • zone は、Filestore インスタンスが存在するゾーンです。

このコマンドは次のような出力を返します。

createTime: '2019-10-11T17:28:23.340943077Z'
fileShares:
- capacityGb: '1024'
  name: vol1
  nfsExportOptions:
  - accessMode: READ_WRITE
    ipRanges:
    - 128.0.0.0/29
    squashMode: NO_ROOT_SQUASH
name: projects/yourproject/locations/us-central1-c/instances/nfs-server
networks:
- ipAddresses:
  - 10.0.0.2
  modes:
  - MODE_IPV4
  network: default
  reservedIpRange: 10.0.0.0/29
state: READY
tier: BASIC_HDD

nfsExportOptions が一覧表示された場合は、クライアントの IP アドレスが想定される accessMode として ipRanges の下で一覧表示されているいずれかの範囲内にあるかどうかを確認してください。範囲内にない場合は、NFS エクスポート オプションを編集してください。これを行う手順については、インスタンスの編集をご覧ください。

App Engine にファイル共有をマウントできない

Filestore は App Engine をサポートしていません。

GKE クラスタからファイル共有をマウントできない

Filestore ファイル共有を GKE クラスタに直接マウントすることはできません。代わりに、PV と PVC を構成する必要があります。

GKE クラスタからファイル共有にアクセスできない

Kubernetes や Google Kubernetes Engine に関連するトラブルシューティングの詳細については、公式の Kubernetes トラブルシューティング ガイドおよび GKE トラブルシューティング ガイドもご覧ください。

エラー: 出力: mount.nfs: xxxx:/file-share-name のマウント中にサーバーによってアクセスが拒否された

PV spec.nfs.pathspec.nfs.server の値が、ファイル共有名と Filestore インスタンスの IP アドレスとそれぞれ一致していることを確認します。

例:

ファイル共有が vol1 という名前で、Filestore インスタンスの IP アドレスが 10.0.0.2 の場合、PV spec.nfs.pathspec.nfs.server は次の値と一致する必要があります。

apiVersion: v1
kind: PersistentVolume
metadata:
 name: fileserver
spec:
 capacity:
   storage: 2T
 accessModes:
 - ReadWriteMany
 nfs:
   path: /vol1
   server: 10.0.0.2

Filestore API を無効にできない

Filestore インスタンスやバックアップなどの Filestore 関連のリソースがすべて削除されていることを確認します。Filestore インスタンスがデプロイされている間は、Filestore API を無効にできません。