2014.09.16

CloudStackで実現するDedicated Servers(専有サーバ)

KDDI クラウドプラットフォームサービス(以下、KCPSと略します)の開発を担当している北条です。KCPSは、Apache CloudStackをベースにしたCitrix社のCloudPlatform 3.0.7を使ってクラウド基盤を構築しています。KCPSは2012年7月にサービスリリースし、当時最新のバージョンであった3.0.5を採用しました。また、2013年2月に仮想化基盤としてKVMに加えてVMwareをリリースしています。当時CloudPlatformではあまり例のないマルチハイパーバイザでのサービス提供であったため、バグフィックスやスクリプト等による個別の対策を強いられてきました。最終的にCitrix社のサポートによりKDDIの改善要求を全て満たした3.0.7へアップグレードすることで、より安定性の高いクラウドプラットフォームを提供しています。CloudPlatform 4.xがリリースされていますが、Quality Cloudを提供するキャリアクラウドは、安定性第一なので、最新だから即採用とはいきません。
サービスの特徴の一つとして、Premiumメニューと呼ばれる専有サーバサービスがあります。ポータル画面から特定の物理サーバ上に仮想マシンを作成することができるので、オンプレミスと同等の専有サーバ環境をクラウド上で利用することができます。

図1

今回は、この専有サーバをCloudPlatformの機能を使ってどのように実現しているかをCloudStackDay2014セッション資料をもとに紹介いたします。

CloudPlatformのアプローチ 「Affinity Groups」

affinity
CloudPlatformは本来、共有リソースのオーケストレーションソフトです。CloudPlatform4.2以降では、”Affinity Groups”を仮想マシンに対して設定して、専有サーバを実現する方法と、ROOT管理者がリソース(zone、pod、cluster、host)を特定のアカウントに紐付ける方法が取られています。Affinity Groupsではアンチ・アフィニティルール(別のホストに収容したい仮想マシンをグループ化するルール)が使われています。Domain毎(契約毎)に異なるAffinity Group IDを仮想マシンに割り当てることで、異なるDomainの仮想マシンが同じ物理ホストで起動しないルールを実現することができます。

KDDIのアプローチ1 「Host Tags」

図3

KCPSで採用しているCloudPlatform 3.xではAffinity Groupsの機能がまだ具備されていなかったこともあり、”Host Tags”を物理サーバへ割り当てることで専有サーバ化を実現しています。Host Tagsは一般的にはHA Tagとして仮想マシンが作成されないホストを指定するために使われます。KCPSでは、HA Tagとしての利用だけでなく、専有型の物理サーバに対してDomain毎に固有の文字列をHost Tagとして指定します。また、共有型(KCPSではValueメニューと呼びます)の物理サーバに対しては、共通のHost Tagを割り当てています。

KDDIのアプローチ2 「物理サーバを指定して仮想マシンを作成する」

図4

専有型を実現する要素はもう一つあります。上記左側は、Apache CloudStackで皆さんが見慣れている仮想マシン作成画面です。右側は、KCPSの画面です。CloudPlatformもApache CloudStackと同じUIを具備します。このUIから作成すると仮想マシンはCloudPlatformがランダムに指定する物理サーバに作成されてしまいます。そのため、KCPSではカスタムのUIを提供し、仮想マシンが該当のHost Tagの物理サーバ上でしか作成、起動しない仕組みを提供しています。CloudStack UIと比べると派手なUIでないですが、とても重要です。しかも1画面で全部設定できるので結構便利ですよ。

専有サーバの追加

図5

専有サーバが追加されるまでの動作は以下のとおりです。

  1. 専有サーバの追加(ハイパーバイザ、ゾーン、サーバ数を指定)
  2. listHostsのAPIを呼び出し、割り当て可能な物理サーバの検索
  3. updateHostのAPIを呼び出し、ホストタグ“CustomerA”を割り当て
  4. 物理サーバの割り当て完了画面をユーザへ返却
  5. 物理サーバの割り当て履歴を保存

次に、専有サーバ上に仮想マシンを作成します。

専有サーバでの仮想マシンの作成

図6

仮想マシンを作成するまでの動作は以下のとおりです。

  1. ホストタグ“CustomerA”の物理サーバに割り当てられている仮想マシン一覧を表示
  2. hostidを指定してdeployVirtualMachineのAPIを呼び出して、仮想マシンを作成
  3. 仮想マシン作成完了画面をユーザへ返却
  4. 仮想マシン作成の履歴を保存

仮想マシンの起動

図7

仮想マシンを起動する場合も、カスタムのUIを使って、hostidを指定してstartVirtualMachineのAPIを呼び出します。

専有サーバの削除

図8

専有サーバが削除されるまでの動作は以下のとおりです。物理サーバ上に仮想マシンが存在する場合に削除できないようにlistVirtualMachineを呼び出して仮想マシンの存在確認を実施します。

  1. 物理サーバをhostidで指定し、専有サーバ削除を実行
  2. listVirtualMachineのAPIを呼び出して、インスタンスの存在確認 ※存在する場合はエラー出力
  3. updateHostのAPIを呼び出してホストタグをCustomerAからPREMIUMへ更新
  4. 物理サーバ削除完了の画面をユーザへ返却
  5. 物理サーバの割り当て履歴を保存

お客様のユースケース

図9

このお客様は、WEB/アプリケーションサーバのようにスケールアウト可能なサーバを共有型で比較的低価格な仮想マシンで構築し、DBサーバのようにスケールアップが必要なサーバを占有型で8vCPU以上を仮想マシンへ割り当てています。また、専有型では、お客様が冗長化したい仮想マシンを明示的に異なる物理サーバへ配置することができます。これにより、物理サーバダウン(※)によるアプリケーションの可用性を担保することができます。(※KCPSでは物理サーバのダウン時に仮想マシンはHAホストへフェイルオーバします。)

まとめ

KCPSの専有サーバサービスは、CloudPlatformの「Host Tag」と「APIによる物理サーバを指定した仮想マシンの制御」で実現していることを紹介しました。今後は、Quality Cloud の観点からKCPSの専有サーバの割り当てアルゴリズムを改修する予定です。クラウド基盤の物理トポロジーを考慮する手法となるので、CloudPlatformのAffinity Groupsでは実現が難しく、KCPSの品質面での特徴になると思います。また、セキュリティコンプライアンス要件の高いお客様に対しては、ストレージやネットワーク(※)の物理的な専有化を提供する必要があるかも知れません。この点も継続して検討していきたいと思います。(※ここでのネットワークとはクラウド設備内のスイッチやケーブルを表しています。KCPSでは“KDDI Wide Area Virtual Switch”と呼ばれる閉域網によるイントラ接続をご利用いただくことができます。)
次回は、KCPSで提供しているKVMとVMwareのマルチハイパーバイザの構成から、CloudPlatformの機能の違いを紹介したいと思います。最後までお読みいただきまして有難うございました。

カテゴリ
タグ

KDDI株式会社 商品企画本部
プロダクト企画部

北条 裕樹

新着記事
タグ
アーカイブ
カテゴリー
Contact
TOP