Filestore インスタンスを維持する

このページでは、Filestore インスタンスのメンテナンスの概要について説明します。メンテナンスのカテゴリ、階層への影響、ネットワークの永続性、ベスト プラクティスについて説明します。

概要

Filestore はインスタンスを定期的に更新し、ファイル共有サービスの信頼性、セキュリティ、最新性を確保します。メンテナンス アップデートは通常、1 ～ 2 週間ごとに実施されます。

Filestore のメンテナンスは Google によって完全に管理されます。カスタム メンテナンスの時間枠を構成したり、メンテナンスを手動で延期または再スケジュールしたりすることはできません。

メンテナンス アップデートは、次のカテゴリに分類されます。

  • Filestore ソフトウェアの更新: システムの最適化、パフォーマンスの向上、新機能。
  • オペレーティング システムのパッチ: 基盤となる仮想マシン（VM）オペレーティング システムの継続的なモニタリングとパッチ適用により、セキュリティの脆弱性から保護します。
  • インフラストラクチャのアップグレード: 基盤となる仮想マシンの移行、ハードウェアのメンテナンス、ネットワークの更新。

サービスティア別のメンテナンスの影響

メンテナンス更新の影響は、インスタンスのサービス階層によって異なります。

基本階層インスタンスではメンテナンス中に短時間のダウンタイムが発生するため、基本階層は主に開発、テスト、重要度の低いワークロードに使用することをおすすめします。高可用性と中断のないファイル アクセスを必要とする本番環境ワークロードには、Regional、Enterprise、または Zonal ティアを使用します。

ゾーンティア、リージョン ティア、エンタープライズ ティア

Zonal、Regional、Enterprise のサービスティアでは、中断のないアップグレード（NDU）が使用されます。

メンテナンス中、これらの階層のインスタンスは完全に利用可能であり、ダウンタイムがほぼゼロの状態でファイル リクエストの処理を継続します。メンテナンス アップデートはバックグラウンドで適用されるため、アップグレード プロセスは接続された Network File System（NFS）クライアントに対して透過的になります。

ベーシック ティア

ベーシック ティアのインスタンスは、自動フェイルオーバーのない単一ノード ストレージによってバックアップされます。基盤となるホストの移行、システム パッチ、ソフトウェアの更新が発生すると、更新が完了するまでファイル オペレーションは一時的に一時停止します。

メンテナンス イベント中、基本 HDD ティアと基本 SSD ティアのインスタンスは、通常 2 ～ 5 分間の短い期間使用できなくなります。

このメンテナンスの時間枠中は、次のようになります。

  • 読み取り、書き込み、ディレクトリ リストなどのファイル オペレーションが一時的に一時停止またはフリーズします。
  • デフォルトの再試行メカニズムを使用する接続クライアントは、インスタンスがレスポンスを再開するまで待機します。

ネットワークとインスタンスの永続性

Filestore インスタンスに割り当てられた内部 IP アドレスは、メンテナンス中も永続的に維持され、変更されません。接続されている NFS クライアントは、更新後にマウント構成を更新したり、ファイル共有を再マウントしたりする必要はありません。

サービスレベル契約（SLA）

Filestore サービスレベル契約（SLA）に従い、定期メンテナンスによるダウンタイムはダウンタイムの計算から除外されます。

メンテナンス処理のベスト プラクティス

Filestore のメンテナンスをスケジュール設定したり遅延させたりすることはできないため、一時的な停止を適切に処理するように NFS クライアントとインフラストラクチャを構成します。

  • ハード マウントを使用する: クライアントに Filestore ファイル共有をマウントする場合は、soft ではなく hard マウント オプションを指定します。ハードマウントでは、ファイル サーバーが一時的に使用できなくなると、NFS クライアントはサーバーが応答するまでリクエストを無期限に再試行します。これにより、データの完全性が維持され、アプリケーションの I/O エラーを防ぐことができます。
  • NFS クライアントのタイムアウトと再試行を構成する: メンテナンス中の一時的な遅延によってクライアントのタイムアウトが発生しないように、NFS クライアントでタイムアウトと再送信のマウント オプションを構成します。
  • アプリケーションの再試行を実装する: 指数バックオフを使用して再試行ロジックをクライアント アプリケーションに組み込み、一時的なストレージ遅延をスムーズに処理します。
  • インスタンスの健全性とメンテナンスをモニタリングする: Google Cloud コンソールで、または Cloud Monitoring を使用して、インスタンスのパフォーマンスとステータスをモニタリングします。Basic 階層のインスタンスでは、更新期間中にレイテンシが一時的に急増したり、ファイル オペレーションが一時的に一時停止したりすることがあります。

次のステップ