マークアップ、VLM、およびシンディスクについては、後で説明します。
あるサーバーで、非常に大きくて不快なものに出会いました。 サーバーはdebian 8では分離されています。マークアップするとき、シンlvmディスクの下に仮想マシンディスクを格納するための別の大きなスペースが割り当てられますが、これまで考慮しなかった微妙な点が1つあります。
実際の構成の例：それぞれ3 TBの4つのディスクからソフトRAID-10を作成しました。
合計5.7 TBのうち、仮想ドライブディスク用に5.37タイプのLVM-Thinの別のドライブが割り当てられています。 割り当てられた合計ディスク領域が4.03 TBであるホストされた仮想マシン。 機械は自ら作動し、徐々にディスクを満たしました。 6か月間の充填は、各仮想マシンで平均20〜30％でした。
翌日（当然、待望の休暇の初日でもあった月曜日）、私たちのzabbixサーバーは、vitroalkから電報を介して熱心に通知を送信し始めました。 最初に、httpやsshなどの個々のサービスの障害について、次に完全にpingの損失について。 ssh経由でメール仮想マシンに接続すると便利です。速度が低下します。最初の数秒からは何もわかりません。ここでは、他の仮想マシンの問題に関するzabbixからの多数のメッセージが届きます。 側面を見ると、ハイパージバー自体を除いて、すべての仮想マシンにとって何が悪いのかがわかります。 私はそれに登り、最初の問題のマシンのコンソールを開きます。
そして見る
タイトルスポイラー
device-mapper: message ioctl on failed: Operation not supported
私が最初に思ったのはソフトレイドだ。 しかし、なぜハイパー自体からこのトピックに通知がなかったのか-時間、ハイパーが外向きに正しく機能する理由-2。
私はlvm -aに登りますそして、私はpve \ dataの一般的なデータを見ます
データ％-23.51％
メタ％-99.95％
チェックしてチェックメイト。
残りの仮想マシンをチェックします-それらは同じ書き込みエラーで横たわっており、サービスは猛烈に痙攣しています。 ユーザーはヒステリックです。
このテーマに関するGoogleのすべての正気な記事の中で-彼らはどこにでも同じツールを書く-追加の物理ハードドライブを追加することでスペースを拡張します。
このサーバーが置かれているローカルのFord Knoxにアクセスするのが難しいことを考えると、多くの時間を無駄にし、8GBのフラッシュドライブを備えたatishnikを送信します。 1.5時間後、彼は所定の位置に来て、USBフラッシュドライブを挿入し、lvmグループに追加し、次のコマンドでメタディスクをさらに3 GB拡大します。
タイトルスポイラー
lvresize --poolmetadatasize +3G pve/data
そして、私は最後にメタ％-1.58％を取得します
マシンを順番に再起動し、ディスクをチェックして、手で問題を修正します。 一部（メールサーバーなど）は、sfckの問題と修正なしで人間的に起動したくありませんでした。 そして最後に、問題を解決します。
カール、何だった？ 私は自問します。
Thin-LVMパーティションを作成してproxmoxに追加するとき、メタデータの容量を手動で考慮して計算機で計算し、ディスクの作成時に手動で設定する必要があるとは思いませんでした。 同じProxmox GUIなどを使用して、なぜこのような重要で重要なインジケーターが監視されないのですか？
皆さん、それが難しくなければ、コメントで、これについて、何が間違っているのか、Thinの作成について、特にメタデータについてほとんど書かれていない理由についてお話をお願いします。 そして、私以外の問題を解決するためのオプションは何ですか。 センターに行くことを許可されたフラッシュドライブを持っている認定された人がラックにアクセスできるようになり、1,000 kmの休暇中に私は2時の時間なく問題を解決することができました。
PS：もちろん、結果は私には向いていません。 フラッシュドライブはまだサーバーに突き出ています。 LVMグループに追加され、いつでも死ぬ可能性があります（この場合、メタデータが失われるため、システムが単にそれらを書き込むことができない場合よりも悪化します）。 戻ったら、他の方法でフラッシュドライブを取り除く方法を考えます（サーバーにディスクを変更したり追加したりすることはすでに不可能です）。 この機会に、仲間たち、客観的なコメントも聞きたいです。