Veeamでのイメージング中にVMwareがクライアントを驚かせないようにする方法
最近、MySQLサーバーが「機能しなくなった」（つまり、クライアント接続が切断された）。さまざまなこと（パケットサイズの調整など）を数週間試した後、VMWareAPIを使用してvmdkなどのスナップショットとコピーを行うのはVeeamイメージングバックアップであることがわかりました。
私たちはCentos6.4ゲストでESXi5を使用しており、MySQL 5.1.69-logのみを（ほぼ）実行しています。
この問題を引き起こしたと思われる変更は、物理ディスクサイズを約100から300GBに増やし、新しい容量のほとんどを使用するようにゲストファイルシステムのサイズを変更することでした。ディスクが増加して以来、バックアップ中にこれらの問題が発生しています。おそらく、スナップショット関連の機能の実行にかかる時間が増加したためです。
新しいディスクは2x300GBGen8 15k SAS RAID1です。古いディスクは同じくらい小さいだけでした。Veeamプロセスのターゲットは1Gb専用イーサネット上のReadyNASです（つまり、一般的なオフィスから分離されています）。トラフィック）。
ホストはHPDL380Pタワーです。
==server spec (BASE CHASSIS)==
SERIES DL380P GEN8
PROCESSOR TYPE Intel Xeon E5-2609 v2 (2.5GHz/4-core/10MB/6.4GT-s QPI/80W)
NUMBER OF PROCESSORS 2
MEMORY 80GB
INTERNAL DRIVE BAYS 8 SFF HDD Bays
COMPATIBLE HDD SFF SAS/SATA
HARD DISK CONTROLLER SMART ARRAY P420I/ZERO MEMORY CONTROLLER (RAID 0/1/1+0)
私の「IT担当者」は、空のブロックをスキップする（新しいディスクの大部分が空である）など、Veeam構成にいくつかの調整を加えましたが、これはまったく役に立たなかったようです。
Veeamは、「ターゲットを再起動する」または「VMWare APIを使用するだけ」と言っても、あまり役に立ちませんでした。
「気絶」とは、仮想マシンが一時的に（約30秒）フリーズした後、通常どおり継続することを意味すると思います。
VMWare.logの例：
Line 7411: 2016-06-08T17:11:44.910Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 21068381 us
Line 7556: 2016-06-08T17:22:24.608Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 19819322 us
Line 7700: 2016-06-08T17:22:30.140Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 1130044 us
Line 7929: 2016-06-08T17:23:08.616Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 30197618 us
したがって、私の問題には2つの解決策があります。
イメージング中のVMWareゲストの「見事な」ことを防止または軽減する方法はありますか。
MySQLまたは仮想ネットワークまたはCentosへのスタンの影響を減らす方法はありますか？.
これは、フラッシュバックアップキャッシュモジュールなしでSmart ArrayRAIDコントローラーを実行するHPProLiantサーバーです。
その結果、書き込みキャッシュ（または読み取りキャッシュ）がなくなり、仮想マシンのスナップショットなどの操作が低下します。あなたはこれの効果を経験しました。現在の構成は、ほとんどのワークロード、特に仮想化には適していません。
最善のオプションは、キャッシュモジュールとバッテリー/ FBWCを購入することです。 HPパーツ631681-B21、631679-B21、または631069-B21。
これにより、パフォーマンスが向上し、発生している問題が解消されます。
参照：
HP DL360p上のFBWCおよびゼロメモリ（ZM）RAIDコントローラー
研究からの私自身の質問に答える。 （これらのアプローチのいずれかが実際に機能し、他の誰かの提案の前にある場合にのみ、私は自分の答えを受け入れます。）
この（古い）記事 スナップショットの危険性と回避方法は何ですか？ いくつかの考えられる原因と3つの予防策について説明しています。興味深いことに、この問題がMS SQLServerやその他のサーバー製品にどのように影響するかについて言及しています。
仮想マシンをスタン/一時停止したくない場合は、snapshot.maxIterationsを20（またはそれ以上）に設定できます。これは、vSphereがスナップショットファイルをコミットするためにより多くの試行（反復）を行うことを意味します。このKB記事の詳細。
次に、このアプローチのリスクとデメリットについて説明します。
第二に、それは示唆しています：
または、snapshot.maxConsolidateTimeを60秒に設定することもできます。これは、仮想マシンの一時停止を60秒間受け入れて、同期統合を実行できることを意味します。多くの場合、これはスナップショットファイルが大きくなるのを待つよりも優れたオプションであり、仮想マシンをはるかに長い時間スタンさせる必要があります。
しかし、「気絶」と「一時停止」の違いはわかりません。
そして最後に：
ESXi 4.1には、VMXファイルに追加する必要のあるパラメータsnapshot.asyncConsolidate.forceSync =“ FALSE”を追加したアップデートがあります。この設定により、同期統合が無効になり、仮想マシンが気絶することはありません。このKBの詳細情報。
これらのソリューションの潜在的な欠点については説明していませんが、いくつかあると思います。そうでない場合はデフォルトになります。
これらのパラメータまたはソリューションがv5でまだ関連しているかどうかはまだ確認していません。
更新：Veeamは、ESXiのv4およびv5に関連するこのKBにリストされている上記の変更を行うことを推奨しています。 スナップショットを削除すると、仮想マシンが30分以上応答しなくなります（2039754）
UPDATE2：キャッシュを待つよりも安価で迅速なため、今夜これらの構成変更を行い、ホストを再起動します。その後、数日間監視して、これだけで解決するかどうかを確認します。