Ploop では、コンテナ内でファイルが追加/削除されるとディスク領域が失われ、コンテナを手動で圧縮する必要があることは知っていますが、再起動したりクラッシュしたりするとコンテナが回復不能になることもあると読んだことがあります。
コンテナの破損を避けるために OpenVZ サーバーを適切に再起動する方法はありますか?
答え1
ploop コンテナの不正シャットダウンの場合でも、通常は fsck を実行するだけで十分です。書き込み操作中に実際のハードウェアをシャットダウンするのとあまり変わりません。これらの ploop ではトランザクション ログを含むファイル システムを使用すると思われるため、これ以上の問題は発生しないはずです。
Brian が述べたように、ホスト ノードを適切にシャットダウンすると、コンテナーはクリーンな状態になり、ploop はマウント解除されます。
ホスト ノードと同じファイル システムを使用するディレクトリ ベースのコンテナーを使用している場合、この時点ですでに破損の可能性がわずかにあります。実際には大きな違いはなく、回復時間を考慮する必要があるだけだと思います。多くの ploop では、1 つのホスト ノードのファイル システムよりも fsck に時間がかかる可能性があり、多くの手動操作が必要になる可能性があります。
一方、ホスト ノードに非常に大きなファイル システムがある場合、その fsck には非常に長い時間がかかり、fsck 中はすべてのコンテナーがダウンしたままになります。ploop を使用するコンテナーは、ホスト ノード自体に fsck するものがない場合は、ホスト ノードが復旧した後に段階的に起動できます。
ホストノードがコンテナデータを中央ストレージから読み込み、障害発生時に相互にオン/オフを切り替えるような高可用性設定を行うことで、この問題を軽減できますが、それはやりすぎだと思います。
ploop を検討する理由は何ですか? コンテナー内の多数の小さなファイルによって処理速度が大幅に低下する NFS 経由でのパフォーマンス向上のために ploop を検討しました。ただし、ファイルシステムの破損について言及されているので、おそらくそれはシナリオではありません。
答え2
いいえ、各プループが適切に停止するまで待つ必要があります。
ploop コンテナは、そのルート ディレクトリを介してファイルにアクセスするために起動する必要があります。
simpfs コンテナは chroot に似たディレクトリ構造なので、オン/オフに関係なくアクセスできます。
私は何千ものコンテナを管理していますが、待ち時間を無駄にすることはできません。アクセスまたは移行を行う必要があるときはいつでも、ploop コンテナが起動するのを待ったり、ploop コンテナを持つホストを管理するために、ploop がオフになるまで待ったりする必要があります。また、ploop が破損した場合、最初からやり直さなければならず、失われます。私はこのような損傷を一度や二度ではなく経験しているので、どれほど優れているかに関係なく、これを信頼できないシステムと呼んでいます。