第21回 CloudStack ユーザ会, ”4. VMware Support for DRS”

1. 第21回CloudStack ユーザ会
4. VMware Support for DRS
2014/9/12
KDDI 北条

2. What’s New in 4.4
• Load Balancing
DRS（Distributed Resource Scheduler）のサポート
物理サーバの負荷のばらつきを分散して平均化
• Power Management
DPM（Distributed Power Management）のサポート
消費電力削減を目的として、物理サーバの負荷を集中化
• Affinity Rules
DRSアフィニティルールを使って、
クラスタ内のホストへのインスタンスの配置を制御

3. VMware DRS
• パワーオン時および起動中のインスタンスを物理サーバのCPUと
メモリ負荷に応じて、自動的にvMotionする機能
• DRSのアルゴリズムとCloudStackのインスタンス探索
VMware
300秒毎にクラスタ内の移行しきい値を計算
しきい値超えの場合はロードバランスが改善する移行パスを探索してvMotionを実行
CloudStack
300秒300秒
60秒60秒
・・・
60秒毎にManagement ServerからvCenterへインスタンス探索（DirectAgent）
時間
時間
・・・

4. DRSのメリット(1)
クラスタ内でサイロ化された物理サーバリソースをプール化し、
動的分散することでインスタンスの統合率を向上
⇒ CloudStackとの親和性大
Cluster 1
Primary
Storage
Cluster 2
Primary
Storage
VMware CloudStack
Cluster N
Primary
Storage
Cluster ゾーン内でプール化
Cluster
DRSなし
サイロ化
DRSあり
クラスタ内
でプール化

5. DRSのメリット(2)
• クラスタ内でプール化されたリソース（ CPU,メモリ）を
用途毎に分割
• 「リソースプール」と「シェア、予約、制限」で実現
⇒CloudStack未サポート
Cluster
営業部
クラスタリソース
100GHz, 50GB
開発部営業部開発部
40GHz, 20GB 60GHz, 30GB

6. 検証環境
• ApacheCloudStack4.4のDRS機能を実装している
CloudPlatform4.3.0.1
• VMware vCenter5.5
• ESXi5.5 ×5台（12core/48GB,同一のCPU種別）
2台DRSクラスタ、3台HAクラスタ
• Primary Storage： iSCSI
• Secondary Storage： NFS
• 1ゾーン, 1Pod, 2クラスタ
• 移行の自動化レベル：完全自動化
• 移行のしきい値：5.0（積極的）
L2 switch
Cluster 1
Primary
Storage
Cluster 2
Pod 1
Secondary
Storage
L3 switch
Primary
Storage
Zone１
DRSを
構成

7. 検証(1)
• DRSなし
• vCenterで2vCPU/4GBのインスタンスを手動vMotion
17:25:39 vMotion開始
17:25:57 vMotion完了
17:26:34,313 (DirectAgent) Detecting a new state but couldn't find a old state so adding it to the
changes
17:26:36,708 (DirectAgent) VM is now missing from host report but we detected that it might be
migrated to other host by vCenter
17:26:36,708 (DirectAgent) VM is now missing from host report and VM is not at
starting/migrating state, remove it from host VM-sync map, oldState: Running
17:27:17,526 (DirectAgent:”物理サーバ名”) find VM on host
（management-server.log一部抜粋）
vMotion完了から約2分未満でCloudStackがインスタンスを検知

8. 検証(2)
• DRSあり（完全自動化、閾値5.0）
• 5台のインスタンス（ 2vCPU/4GB ）にI/O,CPU負荷を発生
• その後、コマンドを停止して負荷のバラつきを発生させる
dd if=/dev/urandom of=/tmp/’date +%Y%m%d%H%M%S’ bs=‘expr $RANDOM % 900’K
yes >> /dev/null
“mackerel”, https://mackerel.io/

9. 検証(2 cont,)
18:54 5号機のインスタンスのI/O,CPU負荷を停止
19:01 2号機がDRSで他方のホストへvMotion
19:01:34,311 (DirectAgent) Detecting a new state but couldn't find a old state so adding it to the
changes
19:01:37,192 (DirectAgent) VM is now missing from host report but we detected that it might be
migrated to other host by vCenter
19:01:37,192 (DirectAgent) VM is now missing from host report and VM is not at
starting/migrating state, remove it from host VM-sync map, oldState: Running
19:02:03,481 (DirectAgent:”物理サーバ名”) find VM on host
19:02:03,481 (DirectAgent:”物理サーバ名”) VM found in host cache
（management-server.log一部抜粋）
vMotion完了から約2分未満でCloudStackがインスタンスを検知
“mackerel”, https://mackerel.io/

10. 検証(3)
• DRSあり（完全自動化、閾値5.0）
• 5台のインスタンス（ 2vCPU/4GB ）にI/O,CPU負荷を発生
• 任意のインスタンスでVMスナップショットとボリュームスナッ
プショットを取得
19:36:34,347 (DirectAgent) Detecting a new state but couldn't find a old state so adding it to the
changes
19:36:34,347 (DirectAgent) VM is now missing from host report but we detected that it might be
migrated to other host by vCenter
19:01:37,192 (DirectAgent) VM is now missing from host report and VM is not at
starting/migrating state, remove it from host VM-sync map, oldState: Running
19:36:42,870 (DirectAgent:”物理サーバ名”) find VM on host
19:36:42,870 (DirectAgent:”物理サーバ名”) VM found in host cache
（management-server.log一部抜粋）
VMスナップショットを取得したインスタンス、ボリュー
ムスナップショット取得中のインスンタンスがDRSの移行対象
となりvMotionが実行される。

11. 検証(4)
• インスタンスの移行時のログでストップコマンドの実行が出力
される場合がある。
• ログ出力時にインスタンスの停止は未発生。
17:34:34,343 (DirectAgent) VM is now missing from host report but we detected that it might be
migrated to other host by vCenter
17:34:34,343 (DirectAgent) VM is now missing from host report and VM is not at
starting/migrating state, remove it from host VM-sync map, oldState: Running
17:34:34,439 INFO (DirectAgent) VM is at Running and we received a power-off report while
there is no pending jobs on it
17:34:34,441 Sending "com.cloud.agent.api.StopCommand“
17:34:34,441 Executing "com.cloud.agent.api.StopCommand"
17:34:34,441 Executing resource StopCommand:
17:34:34,458 find VM on host
17:34:34,458 VM not found in host cache
（management-server.log一部抜粋）

12. 検証(5)
• DRSアフィニティルールの設定
インスタンス
仮想マシン～ホスト間の
アフィニティ
仮想マシン間の
非アフィニティ
01 物理サーバ#1 AntiAffinity_Group
02 物理サーバ#1
03
04
05 AntiAffinity_Group
インスタンス01と02は同じサーバで稼働し、01と05は異なるサー
バで稼働する。
アフィニティルールの設定時にこの条件を満たしていない場合は、
DRSによりインスタンスの移行が実行される。

13. VMware DPM
• クラスタの負荷変動に応じて自動的にサーバの電源をON/OFF
• 低負荷のサーバ上のインスタンスを自動的にvMotionして、空に
なったサーバの電源をStandby Modeへ遷移する。
• クラスタが高負荷になった場合に、自動的に電源ONする。
• BMC、IPMI等によってサーバの電源を制御
＜未検証＞

14. DRS利用時の設計のベストプラクティス
• DRSにより統合率は40-60%上昇すると言われている。
• CPUはオーバコミットする。ただし割り当て待ち状態に注意。
• メモリはオーバコミットしない。メモリ回収によるインスタン
スのパフォーマンスダウンを考慮。
• CloudStackではリソース割り当ての閾値をクラスタ毎で設定。
閾値= “allocated.capacity.diablethreshold” × “overprovisiong.factor”
閾値はCPU150%として使用率を監視して統合率を徐々に上げる。
メモリ閾値は既定値として、物理メモリはDRS利用しない場合の
サイジングの1.5～3倍を搭載する。
cluster.cpu.allocated.capacity.diablethreshold 0.85(default)
cpu.overprovisiong.factor 1.8
cluster.memory.allocated.capacity.diablethreshold 0.85(defalut)
cpu.overprovisiong.factor 1(defatult)
1.53
0.85

15. ご清聴ありがとうございました