Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Jcsug21 20140912

1,781 views

Published on

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

Published in: Technology
  • Be the first to comment

Jcsug21 20140912

  1. 1. 第21回CloudStack ユーザ会 4. VMware Support for DRS 2014/9/12 KDDI 北条
  2. 2. What’s New in 4.4 • Load Balancing DRS(Distributed Resource Scheduler)のサポート 物理サーバの負荷のばらつきを分散して平均化 • Power Management DPM(Distributed Power Management)のサポート 消費電力削減を目的として、物理サーバの負荷を集中化 • Affinity Rules DRSアフィニティルールを使って、 クラスタ内のホストへのインスタンスの配置を制御
  3. 3. VMware DRS • パワーオン時および起動中のインスタンスを物理サーバのCPUと メモリ負荷に応じて、自動的にvMotionする機能 • DRSのアルゴリズムとCloudStackのインスタンス探索 VMware 300秒毎にクラスタ内の移行しきい値を計算 しきい値超えの場合はロードバランスが改善する移行パスを探索してvMotionを実行 CloudStack 300秒300秒 60秒60秒 ・・・ 60秒毎にManagement ServerからvCenterへインスタンス探索(DirectAgent) 時間 時間 ・・・
  4. 4. DRSのメリット(1) クラスタ内でサイロ化された物理サーバリソースをプール化し、 動的分散することでインスタンスの統合率を向上 ⇒ CloudStackとの親和性大 Cluster 1 Primary Storage Cluster 2 Primary Storage VMware CloudStack Cluster N Primary Storage Cluster ゾーン内でプール化 Cluster DRSなし サイロ化 DRSあり クラスタ内 でプール化
  5. 5. DRSのメリット(2) • クラスタ内でプール化されたリソース( CPU,メモリ)を 用途毎に分割 • 「リソースプール」と「シェア、予約、制限」で実現 ⇒CloudStack未サポート Cluster 営業部 クラスタリソース 100GHz, 50GB 開発部営業部開発部 40GHz, 20GB 60GHz, 30GB
  6. 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 Zone1 DRSを 構成
  7. 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. 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. 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. 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. 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. 12. 検証(5) • DRSアフィニティルールの設定 インスタンス 仮想マシン~ホスト間の アフィニティ 仮想マシン間の 非アフィニティ 01 物理サーバ#1 AntiAffinity_Group 02 物理サーバ#1 03 04 05 AntiAffinity_Group インスタンス01と02は同じサーバで稼働し、01と05は異なるサー バで稼働する。 アフィニティルールの設定時にこの条件を満たしていない場合は、 DRSによりインスタンスの移行が実行される。
  13. 13. VMware DPM • クラスタの負荷変動に応じて自動的にサーバの電源をON/OFF • 低負荷のサーバ上のインスタンスを自動的にvMotionして、空に なったサーバの電源をStandby Modeへ遷移する。 • クラスタが高負荷になった場合に、自動的に電源ONする。 • BMC、IPMI等によってサーバの電源を制御 <未検証>
  14. 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. 15. ご清聴ありがとうございました

×