トラブルシューティング

このページでは、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 の間でデータをコピーする

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

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

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 コマンドの df、ls、その他の読み取り/書き込みオペレーションが応答を停止した場合に、Filestore インスタンスはクライアントへのマウント中に削除された可能性があります。

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

    gcloud filestore instances list

インスタンスがリストから削除された場合は、削除されたインスタンスと同じ IP アドレスとファイル共有名で新しいインスタンスを作成することで、再び操作できるようになります。インスタンスが作成されると、レスポンスのないオペレーションはエラーで終了します。Filestore インスタンスが必要ない場合は、ファイル共有のマウントを解除して、Filestore インスタンスを削除できます。

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

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

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

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

Cloud KMS 鍵の状態の変化が検出されると、インスタンスはデータの配信を自動的に停止します。以下はその一例です。

  • 鍵または鍵バージョンの無効化。
  • 鍵または鍵バージョンの破棄。
  • 鍵の権限の変更。

詳細については、CMEK でデータを暗号化するをご覧ください。

容量の問題

「デバイスに空き領域がありません」

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

エンタープライズおよび高スケール SSD 階層のインスタンスには、プロビジョニングされた容量の最大容量使用量の約 89% があります。残りの容量は内部オペレーションとリソース用に予約されています。詳細については、既知の問題をご覧ください。

「df」コマンドと「du」コマンドが異なるディスクの空き領域を報告する

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

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

lsof | grep deleted

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

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

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

    gcloud services enable file.googleapis.com

  2. Filestore インスタンスのそれぞれに、使用中の別の範囲と重複しない IP アドレス範囲が関連付けられている必要があります。制限事項の詳細については、予約済み IP アドレス範囲の構成をご覧ください。

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

  4. 引き続きエラーが発生する場合は、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

インスタンス作成時の System limit for internal resources has been reached エラー

このエラーは、Filestore が内部ネットワークの割り当ての上限に達した場合に発生します。Filestore インスタンスを作成する VPC ネットワークごとに、Filestore では、そのネットワークとピアリングする内部ネットワークを作成する必要があります。これらの内部ネットワークは、Filestore インスタンスと、それらに関連付けられた VPC ネットワークが削除されても保持されます。

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

System limit for internal resources has been reached. Please request to adjust limit here: https://forms.gle/PFPJ2QD4KnCHzYEx9

Filestore API を無効にしてから再度有効にすると、内部ネットワークをクリアできます。

gcloud services disable file.googleapis.com

gcloud services enable file.googleapis.com

削除できない Filestore インスタンスがある場合、または割り当て増加リクエストで付与された割り当てを失わないために API を無効にできない場合は、次のフォームを入力して、ネットワークの上限を調整できます。

https://forms.gle/PFPJ2QD4KnCHzYEx9

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

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

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

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

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

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

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.path と spec.nfs.server の値が、ファイル共有名と Filestore インスタンスの IP アドレスとそれぞれ一致していることを確認します。

例:

ファイル共有が vol1 という名前で、Filestore インスタンスの IP アドレスが 10.0.0.2 の場合、PV spec.nfs.path と spec.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 アドレス範囲の枯渇をご覧ください。