Baremetal Advanced Networkingをひもといてみた。

皆さん、こんにちは。
シトリックスでCloudPlatform(CloudStackの商用製品版)のリードシステムエンジニアをしています山村です。シトリックスで2年以上CloudPlatformをしておきながら、初めてAdvent Calendarに投稿します。失礼しました。

今回、皆さんいろいろご興味のあるCloudStackでのアドバンスドゾーンでのベアメタルサポートについてお話したいと思います。最近はIBM SOFTLAYERがベアメタルをマーケットに訴求していますので、我々のお客様からも時々CloudStack/CloudPlatformでのベアメタルに関してご質問をいただくことがあります。今回はそのロジックや、何ができるのか?何ができないのか?含めてお話をしたいと思います。

まずCloudStack/CloudPlatformでのベアメタルサポートの現状ですが

・Baremetal with Basic Zone
CloudStack4.2(CloudPlatformでは4.2から)からサポート https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Baremetal

・Baremetal with Advanced Zone
CloudStack4.4(CloudPlatformでは4.5からExperimental Support)からサポートhttps://cwiki.apache.org/confluence/display/CLOUDSTACK/Baremetal+Advanced+Networking+Support

です。 両方とも基本的に行っていることは、管理サーバがIPMIを使ってベアメタルホストをパワーオンし、PXEブートで立ち上げてネットワーク経由でOS自動インストールをするということです。 これはCloudStackなどのクラウドOSには関係ない世界の話です。

しかしCloudStackのようなクラウドOSを一枚上にかますことで、仮想インスタンスと同じように、GUIからセルフでプロビジョニングができるようにするための特殊な実装が必要です。その実装がこれらでなされており、Basic ZoneとAdvanced Zoneの場合で、前提としているネットワークトポロジーが違うため、それぞれ別な発想での実装がされているわけです。

Basic ZoneではそもそもVLANハンドリングとかできません。そのためネットワークのプロビジョニングに複雑な実装は不要です。GUIからPXEブートの基本動作をキックできればいいわけです。 しかしAdvanced Zoneでは、ゲストネットワークのVLANハンドリングが必要です。またそのゲストネットワークには、仮想スイッチではなく物理スイッチが存在するので、その自動プロビジョニングが必要になります。また仮想ルータがゲストネットワークとパブリックネットワークとの間に存在するので、DHCP/PXEサーバはどこに配置する?とかややこしいことを考えなくてはいけません。その辺りをCloudStackの中で上手に自動化しています。
では本題です。

以下前提となるネットワークトポロジーです。Advanced Zone(Isolated)のネットワークイメージをもてる方であれば大枠想像がつくかと思いますが、この絵のベアメタルホストのところが従来の仮想インスタンス、レイヤ2スイッチのところがOpenvSwitchのような仮想スイッチにあたるところです。

では実際にベアメタルホストがプロビジョニングされるまでのフローを追いかけてみましょう。

管理者(Admin)が事前に行っておく作業:
1.httpサーバにベアメタルプロビジョニングに必要なファイル群(kickstartファイル / kernel / initrd / Baremetal Rack Configurationファイル)をアップしておきます。 ※Baremetal Rack Configurationファイルに関しては、後述しています。
2.管理サーバのホストOSでIPMIの設定をします(ipmitool)
3.グローバル設定にbaremetal.internal.storage.server.ipというパラメータにhttpサーバのアドレスを入力します(もちろんcloudstack-managementのリスタートは必要です)。
4.グローバル設定に新しくBaremetal Rack ConfigurationというViewが追加されています。ここでBaremetal Rack Configurationを追加します。 ※Baremetal Rack Configurationに関しては、後述しています。
5.VMWareクラスターを作成してゾーンに登録します。
6. ベアメタル用のクラスターを作成します。
7.ベアメタル用のホストを登録します。
8.ベアメタル用のテンプレートを作成します。
9.ベアメタル用のネットワークオファリングを作成します。
(新しくBaremetalPxeServerというネットワークサービスオプションが追加されています)
10.ベアメタル用のコンピュートオファリングを作成します。

テナント(アカウント)が行う作業:
1.ベアメタル用のネットワークオファリングでネットワークを作成します。
2.ベアメタル用のコンピュートオファリングでベアメタルインスタンスを作成します。

テナント(アカウント)がベアメタルインスタンス作成後に裏でCloudStackがやっていること:
1.管理サーバがSSHでVRにログインし、DHCP/PXEサーバ関連の設定をします。
2.管理サーバがSSHでVRにログインし、ゲストネットワークからbaremetal.internal.http.server.ipで指定したIP(ここでは外部HTTPサーバ)へのトラフィックは、VRの管理インターフェースのIPでSource NATして出ていくように設定します。
3.L2スイッチにREST API経由でポートVLANの設定をします(このゲストネットワークに割り振られたVLANID)。
4.管理サーバがベアメタルホストに対してIPMIを使ってパワーオンし、PXEブートでホストがブートアップしようとします。
5.ベアメタルホストがブートアップし、VRからIPアドレスやPXEの情報などを取得します。
6.Linux Kernel(init.rd)をダウンロードします。
7.KickStartファイルをダウンロードします。
8.KickStartファイルに記述されている情報に基づきOSパッケージをダウンロードし、自動OSインストールをします。
9.ベアメタルホストのプロビジョニングが終了したら、KickStartファイルに記載されているPost-Provisionスクリプトが実行されます。そのスクリプトが実行されると、VRで稼働しているエージェントに対して起動したことを伝えるためのhttpリクエストが送信されます。エージェントはそれを受けると、先に設定していたSource NATのルールを削除して、管理サーバに対して、ベアメタルホストが起動したことを伝えます。そうすることでベアメタルインスタンスのステータスがStartingからRunningへと切り替わります。 また管理サーバはSource NATのルールのTTL(Time-To-Live)も同じく設定をします。TTLがきれる前にVRからNotificationが届かなければ、何か問題が発生したと考え、VRに対してSource NATルールの削除の指令を行い、プロビジョニングが失敗したというエラー処理を行います。

いかがでしょうか? 結構複雑なフローをCloudStackが自動化していることが見て取れると思います。でもきっといくつかの疑問/質問が頭に浮かぶことかと思います。そこで次に、QA形式でそれらのご質問にお答えする形でお話を進めていきたいと思います。

Q1:Advanced Isolatedのネットワークトポロジー前提だけど、Advanced Sharedでは利用できないの?
A1:Advanced Isolatedでのみ対応です。

Q2:ベアメタルホストが欲しいだけなのだけど、VMWare環境も必要なの?XenServer/KVMじゃだめなの?
A2:Advanced Isolated環境ではVRがNAT/LBなどのネットワークサービスを提供するのが前提です。仮想ルータやシステムVMなどはベアメタル上では動作しないので、ベアメタルとは別にこれらVMが動作するための環境がゾーンの中に必要です。 その仮想環境はVMWareだけになります。これは技術的な理由からきています。上記ロジックのから、管理サーバはVRに対して様々な設定を事前にプログラムしています。これは管理サーバが直接VRの管理インターフェースに対してSSHで入って行っています。そのため、直接管理サーバからVRの管理インターフェースに対してアクセスできる通信経路が必要です。 一方、XenServerとKVMの場合には、管理インターフェースはもっていなく、そのかわりにリンクローカルインターフェースという、ハイパーバイザとつながっているネットワークを持っています。そのため、直接管理インターフェースに対してSSHアクセスすることができないため、このベアメタル環境ではXenServer/KVM環境は使えないのです。

Q3:Layer2スイッチを管理サーバからポートVLANの設定をするみたいだけど、どこのベンダー製品でもいいの?
A3:現状確認がとられているのはForce10のS4810のみです。

Q4:他ベンダーのL2スイッチを使う手段はないの?
A4:他ベンダー独自のプラグインを開発し、それを利用すれば使えるようなフレームワークにはなっていますが、その実装はベンダー依存となります。以下はそのフレームワークの概念図になります。

Q5:Basic Zoneのベアメタルの場合だと、Adminが外部にDHCP/PXEサーバなどを用意していたけど、Advanced Zoneの場合は不要なの?
A5:Advanced Zoneの場合には、VRがDHCP/PXEサーバの仕事を請け負います。その設定も管理サーバから自動的にされます。しかし外部にHttpサーバは必要です。HttpサーバにはPXEブートに必要なKickStartファイルやパッケージなどのファイル群を格納しておきます。

Q6:ベアメタルホストにインストールできるOSに制限はあるの?
A6:以下のOSでQAされ動作確認がされています(CloudPlatformとして)。他OSの動作に関しては未確認です。
CentOS 5.5, CentOS 6.2, CentOS 6.3, Fedora 17, and Ubuntu 12.04.

Q7:CloudStackで通常の仮想インスタンスでサポートされているコンソール/スナップショット/プライマリストレージ/セカンダリストレージ/HAなどの機能は、ベアメタルでも同じくサポートされるの?
A7:仮想環境と物理環境のアーキテクチャ的な違いでサポートされていません。

Q8:複数のベアメタルホストが同時にPXEブートしたらVRの負荷が大きくなりそうだけど大丈夫?
A8:実装上は同時実行の上限値はありませんが、同時ブートアップしたらVRの負荷はどうしても高くなります。CloudStackのデザインドキュメント上では、経験上10台以上の同時PXEブートは推奨しないとの記載がされています。

Q9:IPv6はサポートされているの?
A9:IPv6はサポートされていません。

Q10:Post-ProvisionスクリプトがKickStartファイルの中で設定されていなかったらどうなるの?
A10:管理サーバが、ベアメタルホストが立ち上がったということを知ることができないため、プロビジョニングは最終的に失敗します。そのため忘れずこの設定が必要です。
以下KickStartファイル(CentOS6.x用)とPost-Provisionスクリプト例:
KickStartファイル(CentOS6.X用)

Post-Provisionスクリプト(このスクリプトをKickStartファイルの末尾に追加)

Q11:Baremetal Rack Configurationって何ですか?
A11:CloudStackからLayer2スイッチに対してVLAN設定を行うので、スイッチへのアクセス情報(IPアドレス/ログインID/パスワードなど)や、どのポートにどのMACアドレスのベアメタルホストが接続されているか(トポロジー情報)を管理サーバは知っておく必要があります。その設定ファイルはJSON形式のファイルになっています。 このファイルを外部HTTPサーバに格納し、そのファイルへのhttpパスを上記でお話したグローバル設定>Baremetal Rack Configurationに設定をすることで、管理サーバはスイッチ情報を知ることができます。
以下コンフィグファイル例。
Fig6

いかがでしたでしょうか?理解がすすみましたか?

CloudStackの商用ライセンス版のCloudPlatformでは、2015年1月にリリースされる予定のCloudPlatform4.5で、このBaremetal Advanced NetworkingをExperimental Release(ケースオープンは受けることはできますが、バグ修正などは不可の場合もありという位置づけで)としてサポートする予定です。

ここまでお話しましたように、利用できるL2スイッチがForce10だけと限定されていたり、一緒に利用できる仮想環境もVMWareに限定されていたりと、まだまだ利用シーンは限られていますが、この辺りが今後エンハンスされていけばいいですね。

Tweet about this on TwitterShare on Facebook41