[0] 備忘:CloudStackを試した際のあれこれ-[Id of Radiance ver.5]





■ 備忘:CloudStackを試した際のあれこれ

 タイトル通り。久々に技術ネタ。とあるシステム一群をKVMで構築するに当たり管理性の向上を目的として導入を検討。OpenStackじゃないのかとゆー話もあるわけだが、構築後に扱う人間がCloudStackベースの商用サービスを使った経験があったので。
 バージョンは参考として購入した「CloudStack徹底入門」がベースとしている4.02を使用。またハイパーバイザは上述の通りKVMを前提。当然間違いや嘘が混じっている可能性があるので注意。


  • インストールはリポジトリを追加した上でyumのみで可。ただし各関連アプリやOS、セキュリティに対する設定変更が必要。なおyumは重いw
  • 一般的には構築に必要なサーバは「最低2台」と言われる。CloudStackそのもので言った場合、管理用の「management」とハイパーバイザに入る「agent」の2種類があるため。この2つを1台のサーバにインストール・設定できれば1台でもいけそうな気はするが未確認。
  • 構築後、「ゾーン」と呼ばれる管理領域単位で物事を進めていくことになるのだが、その中で幾つか役割の異なるネットワーク(セグメント)を設定していくことになる(パブリック、ゲスト、管理、ストレージ等)。で、最初コレを全て同一のセグメント(IPはずらした)で構築しようとしたのだが、どうもそうすると「システムVM」が正常に起動してくれない。資料的には「各ネットワークは分けたほうが良い」的な記述があるのだが、分ける以前に単一のネットワークはできないのかもしれない。
  • ただし、上記は構築を始めた初期の頃にハマってた話なのでちゃんと作れば大丈夫な可能性も。結構システムVMは他の場合でも上手く起動しないことが多かった。
  • インストール直後、まずゾーン作成ウィザードから諸々を作成するのだが、どうも「インストール直後の一発目は『ホスト』作成に失敗する確率が高い」模様。agent及びlibvirtdの初期状態から最初の設定投入が上手く反映されてないような気がする。ホスト作成のパラメータに間違いがないのにホスト作成で止まる場合は一度諦めてキャンセル。それでも管理画面的にはホストが作成されてるよーに見えるので、その状態で「agentを停止→libvirtdを再起動→agentを起動」してから管理画面のホスト情報から当該ホストの「強制再接続」もしくはホストの再作成を行うと上手くいく場合がある。その後プライマリストレージ、セカンダリストレージを手で作成する。
  • 下記に述べた設定変更とかを行う場合、管理画面から「ゾーンの無効化」を行なってからにする。こうしないとシステムVMの破棄とかが出来ない。
  • 「システムVM」。CloudStack環境を実現するために自動で生成される仮想マシン群。主だったところでは作成された仮想OS(インスタンス)の画面を擬似的にWebで表示するための「コンソールプロキシVM」と、セカンダリストレージを管理する「セカンダリストレージVM」があるわけだが、設定のバランスで、特にセカンダリストレージVMが起動に失敗し、消滅→自動再作成を繰り返す場合がある。とりあえず私の対処方法は以下の通り。
  1.  agent→libvirtdの再起動。特にagentのログに「x-xx-xxのcgroupを作成できません:そのようなファイルやディレクトリはありません」とゆーログが延々と出る場合はコレでなおる可能性がある。
  2.  プライマリストレージのマウント状態の確認。色々設定をいじったり再インストールを行なったりする中で、agentがプライマリストレージをマウントしっぱなしの場合がある。その状態でゾーンを一から再作成しようとするとagentが新たにマウントを試みる段階でエラーとなる。同じ所を同じ名前でマウントするんだからそのまま進んでくれれば良さそうなものだが、どうも「マウントできなかった」事自体をエラーと捉えるようで先に進んでくれない。ログに「ファイル '/mnt/[長ったらしいID]' を開けませんでした: そのようなファイルやディレクトリはありません」と出つつ、「df -h」でそのフォルダがマウントされている場合にこの可能性が高い。なお単純にマウント先に問題があっても同じログが出ると思われるので注意。
  • またセカンダリストレージVMが起動していても「テンプレートに標準テンプレート(CentOS5.5)が表示されない」「表示されてるんだけど利用可能状態にならない」と場合がある。こうなるとISOの登録もできない場合が多い。この場合原因はネットワーク設定にある可能性が高い。
  1.  セカンダリストレージVMが外部(インターネット)とアクセスできない場合:特に標準テンプレートは最初にインターネットからダウンロードできる必要があるため、パブリックネットワークの設定に問題があると先に進んでくれない。この場合初期データとして標準テンプレートの情報はあるため「表示されてるんだけど利用可能にならない」状態になる。セカンダリストレージVMからでもインターネットにアクセスできるIPが割り振られるようにすると解決する。(ただISOの登録はこの状態でもできるかも)
  2.  いわゆる「ストレージネットワーク」の設定が間違っている場合:KVM構成の場合、事前にハイパーバイザ側のネットワークにブリッジ(cloudbr0、cloudbr1等)を構築し、各ネットワークに割り当てることになるのだが、このブリッジを複数設定し、パブリックや管理・ストレージを分離しようとした場合に、各ネットワークに対するこのブリッジを正しく設定しないと対象ネットワークへ流すべきインターフェースが異なる事になり、通信ができない状態となる。まずは各ネットワークとブリッジの関係が正しいか確認する。また、何らかの理由で「管理画面から設定した後にホスト側で『cloud-setup-agent』コマンドをノーオプションで実行」すると、基本的にはその時のagent.propertiesの内容を元に再設定してくれるのだが、本来「guest」「private」「public」に分かれているネットワークデバイスの設定を1つにまとめてしまう。この場合一度システムVMを破棄した上でagent.propertiesの値を正しいものに変更した上でゾーンを再起動する。
  • システムVM系が正常に動かないとコンソールVMが動かない場合もあり、その場合セカンダリストレージVMとかの詳細設定も見えないのだが、とりあえず起動に成功していれば、各システムVMが稼働しているホスト上から以下のSSHでログインする事が可能。特にネットワークの不通系エラーを把握するのに有効。
 ssh -i /root/.ssh/id_rsa.cloud -p 3922 [ローカルリンクアドレス]  ※ローカルリンクアドレスは各システムVMの詳細設定から確認可能
  • 初期設定でシステムVM用のイメージをダウンロードするとゆー作業が入る。これは一度ダウンロードすれば(nfs的な置き場所さえ同じなら)何度再インストールしてもそのままで可っぽい。(再ダウンロード不要)
  • iptablesについて。インストールマニュアルに初期設定があり、また自動で色々と追加設定してくれるのだが、初期状態だとまずコンソールにつながらない。また作成したインスタンス(ゲストネットワーク)にもつながらない。ただし動作しているホストからは繋がる。ぶちゃけiptablesを停止すれば当然繋がるのだが、とりあえず以下の設定を停止させれば繋がるようになる。KVMの場合、そのブリッジを経由した通信になるので下記の設定を入れられるてはそりゃ繋がるワケがない気がするのだがどうか。どうもKVMデフォルトの「virbr0」を元に設定変更しようとしている?
 -A FORWARD -o cloudbr0 -j DROP
 -A FORWARD -i cloudbr0 -j DROP
  ※「/etc/sysconfig/iptables」内記述。なおcloudbr1以降を設定している場合それも含む。
  ※ただしセキュリティ的に正しいかは不明。一応拡張NWの設定では正しく防いでいる。
  • グローバル設定について。admin管理画面から閲覧&操作が可能な「グローバル設定」。幾つか特徴的なものを。
  1.  「host」:管理マネージャーのIPが指定されるところ、なのだが、デフォルトだと管理マネージャーサーバのデフォルトゲートウェイが指定されるI/FのIPが入ってしまう模様。管理ネットワーク及びI/Fを別にした場合に、ゾーン作成前に事前に変更する必要がある模様。
  2.  「expunge~」:Cloudstackの場合インスタンスを削除しても一定期間残して復帰ができる。デフォルトだと1日保存してくれるが、試験や仮構築の段階でこんなに残されても困るだけである。「expunge」で検索かけて引っかかる設定のうち「86400」となってるものを適宜変更すると吉。
  3.  その他「物理リソースに対してインスタンスに割り当てられる量」とかあって、これも環境によって厳しい場合があるので必要に応じて調整する。
  • よく「管理とストレージネットワークは同一でも可。でもできれば分ける」みたいな記述を見かけるのだが、上述の通りagent.propertiesを見るとネットワークI/Fの指定方法には「guest」「public」「private」の3つしかない。このうち「private」が管理・ストレージであることは明白なので、仮にネットワークを分けてもI/Fを分けることはできない?未確認。
  • 拡張ネットワーク構築時の「負荷分散」について。仮想ルータが行なってくれる仮想負荷分散。だが物理リソースがいっぱいいっぱいの場合、そもそもソレの稼働自体で結構な負荷となる模様。例えばホストが1台の環境で複数のWebインスタンスを生成し分散設定。ab等で大量のアクセスを投げ込むと、親となるホストのLoad Averageが跳ね上がり処理が遅延する。同じ条件で単一のWebにのみ負荷を集中させた方が軽い。
  • ただし上記はあくまでホスト1台をギリギリまで使うようなキツい環境の場合の話。ホストを2台にすると途端に解消され、負荷分散の効力が出る。もちろんその2台の限界値に近づけば話は別だろうが…。
  • 色々やり直す場合話。試行中は何度も再構築することになると思われる。以下が手っ取り早いと思われる。
  1.  management、agent停止
  2.  agentのマウントを解除
  3.  mysqlにログインし、データベースを消去。「drop database cloud」
  4.  DB構築スクリプトの実行。インストール途中で実行した「cloud-setup-databases」を同じオプションで実行する。
  5.  プライマリストレージ内ファイル、フォルダを削除。セカンダリ内はそのままで可。
  6.  ホストのagent.propertiesの中身をクリア(あるいはコメントアウト)。でも「host」の値は変更がなければそのままにしておいた方が良いかも。
  7.  nfsの再起動。
  8.  libvirtdの再起動。
  9.  management、agent起動
  • 上記の再作成の一環でagent.propertiesの内容を全てクリアしてagentを起動した場合、「/etc/init.d/cloud-agent status」で状態を見ると「停止してるがサブシステムがロック」とかイミフな事を言われるが、management側から再設定コマンドが投げられれば改善するのでとりあえずはシカトが吉。
  • ISOの追加について。ISOイメージの追加時に指定できる場所はURL(Web)限定っぽい。マニュアル等には「場合によってはローカルにおける」みたいな曖昧な書かれ方をしているが、「ローカルに置いたWebサーバ」を意味するのか。
  • 当たり前だがあるゾーンに登録したホストは他のゾーンに指定できない。単一のハイパーバイザサーバを異なるゾーンで共有するマネは不可能。

2013-12-09 [技術]

関連記事: