このページでは、Filestore の使用中に問題が発生した場合に役立つトラブルシューティング手順を示します。
パフォーマンスの低下
- クライアント VM に推奨マシンタイプを使用していることを確認します。
クライアント VM が Linux を実行している場合は、デフォルトのマウント オプションを使用していることを確認します。
クライアント VM が Filestore インスタンスと同じリージョンに配置されていることを確認します。リージョン間でマウントすると、パフォーマンスが低下するだけでなく、ネットワーク コストも発生します。
Filestore インスタンスが最大容量を超えるか、超えようとしていないことを確認します。残り容量が僅かになると、残りのスペースが断片化することが多く、読み取り / 書き込みオペレーションが遅くなります。このような状況を回避するために必要な空き領域は、状況によって異なります。ディスク容量不足のアラートを設定することをおすすめします。
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 インスタンスにデータをコピーする方法は、低速となることがわかっています。パフォーマンスを向上させる方法の詳細については、Google Cloud リソース全体でパフォーマンスを向上させるをご覧ください。
ファイル共有のマウント時とマウント解除時のレイテンシ
デフォルトのマウント オプションを使用してファイル共有をマウントすると、マウント コマンドは 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
Filestore API が有効になっているかどうかを確認します。
gcloud services enable file.googleapis.com
Filestore インスタンスのそれぞれに、使用中の別の範囲と重複しない IP アドレス範囲が関連付けられている必要があります。制限事項の詳細については、予約済み IP アドレス範囲の構成をご覧ください。
roles/file.editor
ロールがあるかどうかを確認します。詳細については、IAM のロールと権限をご覧ください。引き続きエラーが発生する場合は、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 の設定が正しくないことや、間違ったインスタンスをマウントしようとしていることが考えられます。
- IP ベースのアクセス制御が有効になっているか、クライアントの IP アドレスが制限されているかどうかを確認します。詳細については、こちらをご覧ください。
- ファイアウォールの設定を調べて、必要なポートが開いていることを確認してください。詳細については、ファイアウォール ルールの構成をご覧ください。
- 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 アドレス範囲の枯渇をご覧ください。