トラブルシューティング

このページでは、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 インスタンスにデータをコピーする方法は、低速となることがわかっています。緩和策はわかっていません。

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

デフォルトのマウント オプションを使用してファイル共有をマウントする場合、mount コマンドは、Filestore インスタンスでサポートされているトランスポート メソッドの検出を試みます。これにより 3 秒のレイテンシが発生します。

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

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

このマウント オプションは、autofs を使用して自動マウントする場合に特に重要です。

Filestore が応答しない

Filestore インスタンスが pingtraceroute のリクエストに応答しない

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 インスタンスは、ユーザーが制御できない内部原因による異常な状態にあり、自動的に修復されます。この間、インスタンスは使用できなくなります。また、何かを操作する必要はありません。

容量の問題

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

クライアント 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 をさらに追加する場合は、容量を追加する必要があります。

「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-id-or-number  \
        --flatten="bindings[].members" \
        --format='table(bindings.role)' \
        --filter="bindings.members:service-project-number@cloud-filer.iam.gserviceaccount.com"
    

    ここで

    • project-id-or-number は、Google Cloud プロジェクトの ID または番号です。
    • project-number は、Google Cloud プロジェクトの番号です。

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

    ROLE
    roles/file.serviceAgent
    

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

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

インスタンスの作成時にエラーコード 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 インスタンスが必要で削除できないために API を無効にできない場合は、ピアリングされたネットワークを手動でクリアするようにアカウント担当者に連絡する必要があります。

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 を無効にできません。

エラー: Failed to create subnetwork. Couldn't find free blocks in allocated IP ranges.

特定のプライベート接続では、割り当てた IP アドレス空間が枯渇すると、Google Cloud から Failed to create subnetwork. Couldn't find free blocks in allocated IP ranges. のエラーが返されます。

この問題を解決するには、IP アドレス範囲の枯渇をご覧ください。