大量の空き RAM、NVMe Intel P4500、その他すべてが非常に遅い - スワップ パーティションの追加が失敗した話

この記事では、VPS クラウド内のサーバーの 15 つで最近発生した、私が数時間困惑した状況について説明します。 私は約 XNUMX 年間、Linux サーバーの構成とトラブルシューティングを行ってきましたが、このケースは私の実践にはまったく当てはまりませんでした。問題の原因を正しく特定して解決するまでに、いくつかの誤った仮定を立て、少し絶望的になりました。 。

プリアンブル

当社は中規模のクラウドを運用しており、32 コア、256 GB RAM、4500TB PCI-E Intel P4 NVMe ドライブという構成の標準サーバー上に構築しています。 この構成は、VM インスタンス タイプ レベルで適切な制限を提供することで IO オーバーヘッドを心配する必要がなくなるため、非常に気に入っています。 NVMeインテルだから P4500 優れたパフォーマンスを備えているため、マシンへの完全な IOPS プロビジョニングと、ゼロ IOWAIT でバックアップ サーバーへのバックアップ ストレージの両方を同時に提供できます。

私たちは、VM ボリュームの保存にハイパーコンバージド SDN やその他のスタイリッシュでファッショナブルな若者向けのものを使用しない古くからの信者の 2 人であり、システムがシンプルであればあるほど、「主任がいなくなった」状況でもトラブルシューティングが容易になると信じています。山へ。" その結果、LVM4 上にデプロイされる XFS または EXT2 に VM ボリュームを QCOWXNUMX 形式で保存します。

オーケストレーションに使用する製品である Apache CloudStack によっても、QCOW2 を使用する必要があります。

バックアップを実行するには、ボリュームの完全なイメージを LVM2 スナップショットとして取得します (はい、LVM2 スナップショットが遅いことはわかっていますが、ここでも Intel P4500 が役に立ちます)。 私たちはそうします lvmcreate -s .. そして助けを借りて dd バックアップ コピーを ZFS ストレージを備えたリモート サーバーに送信します。 ここではまだ少し進歩しています。結局のところ、ZFS はデータを圧縮形式で保存でき、次を使用して迅速に復元できます。 DD または、次を使用して個々の VM ボリュームを取得します mount -o loop ....

もちろん、LVM2 ボリュームの完全なイメージを削除するのではなく、ファイル システムを RO しかし、これによって XFS がすぐにではなく、予測できない形で悪くなるという事実に直面しました。 いつ発生するか不明なエラーにより、ハイパーバイザー ホストが週末、夜間、または休日に突然「停止」するのは非常に好ましくありません。 したがって、XFS ではスナップショット マウントを使用しません。 RO ボリュームを抽出するには、LVM2 ボリューム全体をコピーするだけです。

この場合、バックアップ サーバーへのバックアップ速度はバックアップ サーバーのパフォーマンスによって決まり、非圧縮データの場合は約 600 ～ 800 MB/秒になります。さらに制限となるのは、バックアップ サーバーが接続されている 10Gbit/秒のチャネルです。クラスターに。

この場合、8 台のハイパーバイザ サーバーのバックアップ コピーが 8 台のバックアップ サーバーに同時にアップロードされます。 したがって、バックアップ サーバーのディスク サブシステムとネットワーク サブシステムは低速であるため、ハイパーバイザー ホストのディスク サブシステムが過負荷になることはありません。これは、ハイパーバイザー ホストが簡単に処理できる、たとえば XNUMX GB/秒を処理できないためです。生産する。

上記のコピー プロセスは、高速 Intel P4500 ドライブの使用、NFS の使用、そしておそらく ZFS の使用などの詳細を含む、さらなるストーリーにとって非常に重要です。

バックアップストーリー

各ハイパーバイザー ノードには、サイズが 8 GB の小さな SWAP パーティションがあり、次を使用してハイパーバイザー ノード自体を「ロールアウト」します。 DD 参考画像より。 サーバーのシステム ボリュームには、LSI または HP ハードウェア コントローラーで 2xSATA SSD RAID1 または 2xSAS HDD RAID1 を使用します。 一般に、システム ボリュームは SWAP を除いて「ほぼ読み取り専用」モードで動作するため、内部に何が入っているかはまったく気にしません。 また、サーバーには大量の RAM があり、30 ～ 40% が空いているため、SWAP については考えていません。

バックアッププロセス。 このタスクは次のようになります。

#!/bin/bash

mkdir -p /mnt/backups/volumes

DIR=/mnt/images-snap
VOL=images/volume
DATE=$(date "+%d")
HOSTNAME=$(hostname)

lvcreate -s -n $VOL-snap -l100%FREE $VOL
ionice -c3 dd iflag=direct if=/dev/$VOL-snap bs=1M of=/mnt/backups/volumes/$HOSTNAME-$DATE.raw
lvremove -f $VOL-snap

に注意を払う ionice -c3実際、NVMe デバイスの IO スケジューラは次のように設定されているため、これは NVMe デバイスにはまったく役に立ちません。

cat /sys/block/nvme0n1/queue/scheduler
[none] 

ただし、従来の SSD RAID を備えたレガシー ノードが多数あり、それらにとってこれは関連性があるため、移行されています。 れているように。 全体として、これは無益さを説明する興味深いコードにすぎません。 ionice このような構成の場合。

旗に注目してください iflag=direct のために DD。 読み取り時の IO バッファの不必要な置換を避けるために、バッファ キャッシュをバイパスするダイレクト IO を使用します。 しかし、 oflag=direct ZFS の使用時にパフォーマンスの問題が発生したため、そうしません。

私たちはこのスキームを数年間問題なく使用してきました。

そしてそれが始まりました... ノードの 50 つがもうバックアップされておらず、前のノードが XNUMX% という驚異的な IOWAIT で実行されていることがわかりました。 コピーが行われない理由を理解しようとすると、次の現象が発生しました。

Volume group "images" not found

「インテル P4500 も終わりだ」と考え始めましたが、ドライブを交換するためにサーバーの電源を切る前に、やはりバックアップを実行する必要がありました。 LVM2 バックアップからメタデータを復元することで、LVM2 を修正しました。

vgcfgrestore images

バックアップを起動すると、次の油絵が表示されました。

またしても私たちはとても悲しかったです。すべての VPS が苦しむことになり、私たちも苦しむことになるので、このままでは生きていけないことは明らかでした。 何が起こったのかはまったく不明です - iostat 残念な IOPS と最高の IOWAIT を示しました。 「NVMeを置き換えよう」以外のアイデアはありませんでしたが、ちょうど良いタイミングで洞察が得られました。

状況を段階的に分析する

歴史雑誌。 数日前、このサーバー上に 128 GB RAM を備えた大規模な VPS を作成する必要がありました。 メモリは十分にあるように見えましたが、念のため、スワップ パーティションにさらに 32 GB を割り当てました。 VPS が作成され、タスクが正常に完了し、インシデントは忘れられましたが、SWAP パーティションは残りました。

構成機能。 すべてのクラウドサーバーのパラメータ vm.swappiness デフォルトに設定されました 60。 そしてSWAPはSAS HDD RAID1上に作成されました。

何が起こったのか（編集者による）。 バックアップするとき DD 大量の書き込みデータが生成され、NFS に書き込む前に RAM バッファに置かれました。 ポリシーに基づいたシステムコア swappinessは、VPS メモリの多くのページを、低速の HDD RAID1 ボリューム上にあるスワップ領域に移動していました。 これにより、IOWAIT が非常に大幅に増加しましたが、IO NVMe によるものではなく、IO HDD RAID1 によるものでした。

問題はどのように解決されたか。 32GBのスワップパーティションが無効になりました。 これには 16 時間かかりました。SWAP がオフになる方法とその理由については、別途お読みください。 設定が変更されました swappiness 次の値に等しい 5 雲全体に。

どうしてこんなことが起こらないのでしょうか？。 第一に、SWAP が SSD RAID または NVMe デバイス上にある場合、第二に、NVMe デバイスはなく、それほど大量のデータを生成しない低速デバイスがあった場合です。皮肉なことに、NVMe が速すぎるために問題が発生しました。

その後、すべてが以前と同じように機能し始め、IOWAIT はゼロになりました。

出所： habr.com