事象について

仮想マシンバックアップアプライアンス製品として VMware が無償で提供している vSphere Data Protection (以下、VDP) を使っていますが、バックアップタスク実行中に仮想マシンが 10秒~20秒以上停止する現象がありました。

本番環境の仮想マシンで、中で動いている Heartbeat が夜中に何故か待機系仮想マシンへ切り替わってしまったので、調べてくれと依頼がありました。

サーバ側は特に問題なさそうだったので、色々調べていくうちにもしかすると VDP が悪さしているのでは?。。と思い、切り分けすることに。

以下は、仮想マシン 15台をバックアップした時の Ping 結果です。(ExPing 100ms 間隔)

VDP のバックアップ対象となっている本番環境の仮想マシンで以下の事象が発生していると思うとぞっとしますね。。

vsphere-data-protection-virtual-machine-ping-failed

ping がめちゃくちゃ落ちてる。。

この問題は、バックアップタスクの最後の段階である スナップショット削除 タスクが実行される時に発生します。

VDP のバックアップ時に実行されるタスクの大きな流れは、以下の通りです。

  • スナップショット取得
  • バックアップ (フルバックアップ、または 差分バックアップ)
  • スナップショット削除

※ 初回バックアップはフルバックアップが取得され、次回からは、差分バックアップが実行されます。

ちなみに、同時バックアップ可能な仮想マシン数は、VDP 仕様上、8台までです。

事象についてですが、最初は、複数の仮想マシンバックアップが同時に実行されたため、もしかすると高負荷によるトラブルかもしれないと思ったので、試しに仮想マシン 1台だけを手動でバックアップを実行してみた結果、やはり スナップショット削除 のタイミングで仮想マシンが 10秒以上停止する事象が発生しました。

仮想マシンが止まっている間には、以下の現象が起きます。

  • 仮想マシンへ Ping が通らない
  • 仮想マシンの中でコマンドを実行しても反応しない (仮想マシン無応答)

仮想マシンを Ping 監視している場合には、その閾値によっては、夜中にアラーとがあがるかもしれませんし、Heartbeat のようなアプリケーションで冗長を組んでいる仮想マシンの場合には、Failover が発生し、スタンドバイ機へ切り替わってしまう可能性もあります。

対策方法

保険として万が一のためにバックアップを取っているのに、逆にバックアップアプライアンスによって障害が発生すると怖いので、早く対応したいと思い、調べてみたところ、VMware KB にも同事象が記載されていました。

KB には、VDP がインストールされたホストと同じホスト上に存在する仮想マシンをバックアップすれば良いと書いてありますが、実際に仮想マシンは、複数台の ESXi ホスト上で稼動しているので、全てのバックアップ対象仮想マシンを VDP が存在する特定のホストに配置することはありえないと思います。

リソース分散のために、vMotion するかもしれないし、負荷状況によっては、DRS によって自動配置されるかもしれないので、根本的な対策にはならない気がします。

なので、VDP のデータ転送方式である SCSI hot-add の代わりに NBD 方式を使うように設定します。

  1. 該当 DATA PROTECTION へ SSH 接続する
  2. avvcbimageAll.cmd の一番最後の行に転送方式として LAN(NBD) Transport を設定する
/usr/local/avamarclient/var/avvcbimageAll.cmdRaw Code(S)Raw Code(T)
・・・
--transport=nbd

※ サービス再起動、アプライアンスの再起動は不要です。

以下は、nbd 設定後、仮想マシン 15台をバックアップした時の Ping 結果です。(ExPing 100ms 間隔)

vsphere-data-protection-nbd-transport-virtual-machine-ping-ok

最後に

これで スナップショット削除 タイミングでバックアップ対象仮想マシンが無応答になる問題は解決できますが、デメリットとして、バックアップに相当時間がかかります。

本当に遅いです。 が、遅くても Ping 落ちることなくサービスを守ることができるのであれば、遅くても我慢という感じです。

バックアップ対象となる仮想マシンの数が少なければ別に問題になりませんが、台数が多くなるとバックアップスケジュール時間内に全てのバックアップジョブが終わらない可能性があるため、ジョブごとにバックアップ実行曜日を分けて設定するなどの工夫が必要です。

私が運用している環境では、複数の VDP アプライアンスを使ってかなりの数の仮想マシンをバックアップしているため、実際に、バックアップに失敗したときの確認作業にすごく稼動をとられています。

バックアップは、なるべくアプリケーションにお任せしたいですが、逆に対応に稼動取られるくらいだったら有料でもいいからもっといい製品を使ってみたい気持ちにもなりますが。

でも、バックアップが頻繁に失敗するしないは、バックアップ先のストレージの性能とネットワークが 1G か 10G かによってかなり差が出るので、VDP が悪いとは言い切れません。

vCenter 当たり、バックアップアプライアンス VDP を 10台までしか建てられない仕様も気になりますし(5.5 基準で 10台、6.0 は、20台まで可能です)、無料だからっていう理由で使っているだけなので、良いバックアップ製品ご存知の方いらっしゃいましたらご紹介頂けますと幸いです。(無料でこれだけのバックアップができることもメリットと言えばメリットですね)

もし、バックアップストレージとして NFS を使っていて、そのストレージが iSCSI 接続をサポートしているのであれば、データストアを NFS マウントではなく、iSCSI として接続させると転送方式を LAN(NBD) Transport に変えなくても症状が改善される可能性がありますので、試してみてはいかがでしょうか。

因みに、私は今までバックアップ用ストレージとして、安くて容量の大きいストレージ (Q ほげほげ) に Enterprise SATA を使っていましたが、新規クラウド環境を構築する際に、余っている ESX ホストに CentOS を入れ、600GB HDD (SAS) × 8本10G NIC (Bonding) 構成でバックアップ用の NFS サーバを構築し、その上で VDP を動かしてバックアップを取得してみたら、hot-add モード でも全然問題ありませんでした。(スナップショット削除タスクが走ったときに、ExPing 100ms 間隔で、2発落ちるくらいでした)

と言いながらも ESXi ホストを NFS サーバとして使うのは、値段的にもスペック的にも勿体無い気がします。

バックアップ用だからといって、容量だけ稼げる安いストレージよりは、ある程度の性能・パフォーマンスが出るストレージ・ネットワークを使った方が結果的には良いと思います。

以上、vSphere Data Protection 仮想マシンが10秒以上停止する問題と対策について でした。