CloudStackで提供されるインスタンス向けの各IPに「VPN有効化」のボタンが付いているが、ひょっとしてVPNを有効にできるIPって各ネットワークの代表アドレス(※[送信元 NAT]となっているもの)だけなんだろうか。唯一成功したのがコレだけなんだが。

2014-11-19 [技術・作業]

 CloudStack4.2環境の運用を開始し、徐々にインスタンスへのアクセスが増えてきたある日のこと。
 とあるWebアプリに「アクセスできない」というトラブルが発生。拡張ネットワーク構成の、仮想ルータでロードバランスも行なっている構成。ロードバランサ経由の他、各サーバ単体の静的IPでもアクセスできない。ついでに管理用のSSHもつながらないことからおそらくTCP周りは全滅している模様。
 ただCloudStackのコンソール経由で見てみるとサーバ自体は動作しておりアクセスも操作もできる。またロードバランサ環境=複数サーバ構成なわけだが、その複数のサーバ間の通信は行える。どうも仮想ルータと内部ネットワーク間のアクセスができなくなっている模様。
 ところで仮想ルータは、ネットワーク構成によってはかなりのアクセスが集中する構成にも関わらず、初期状態ではTCPのコネクション数やら何やらのチューニングが行われていない。いや/etc/sysctl.confには一部設定されてるっぽいのだがなぜだか起動直後は反映されていない。また、ソフトウェアロードバランサであるところのhaproxy。これの初期設定もワリと抑えめにされており拡張の余地が残されている。
 その辺のパラメータを超えちゃったのかなーとか思いつつ設定を調整し仮想ルータ再起動。通信復旧。やれやれこれで様子見。

 ………その約一週間後。ほぼ同様の通信障害が発生orz とりあえず仮想ルータ再起動で復旧するところまで同じ。
 しかしTCPパラメータ等の調整をした後の二度目となると別の原因の可能性が高くなる。というか最初の段階でTCPの限界系のログが一切出ておらず、というかその他の通信系の不具合もまったく予兆すらない。雰囲気wとしては「あるタイミングでふっとTCPパケットが消失しはじめる」かのような感じと言えばよいか。弾いたり拒否したりするのではなく、消失。あるいは行方不明。しかも仮想ルータ全体にではなくいずれかの仮想NICに依存する形で。

 それでもまあTCP周りの原因を推定して詰めていくしかなかったので、CloudStack以前にハイパーバイザ側で何か対応すべき点はないか、今回の場合「KVM」で何かしらTCPをチューニングする余地がないかとあれやこれや調べてたところ、某tHatの仮想化チューニング話・「ネットワーク調整のヒント」というページで

  arp_filter を使用して ARP 変動を防ぎます。 ARP 変動はホスト、 ゲストいずれでも発生する可能性のある望ましくない状況で、 マシンが ARP 要求に対して複数のネットワークインターフェースから応答してしまう原因となります。 この設定を永続的にするため、 echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter を行なうか、 /etc/sysctl.conf の編集をしてください。

 なる記述を目にする。
 ARP変動?初めて聞く言葉。調べると世間的には「ARP Flux」と呼ばれる現象であるらしい。1台のマシンに同一セグメントのIPが振られている複数のNICがあると、ARP取得用のブロードキャストの応答が変になってARPテーブルのMACアドレスがおかしくなる現象、らしい。仮想マシンを構成する場合1物理サーバ内に同一セグメントの仮想NICが(仮想ブリッジ含めて)複数生成されることもあるため、表面化する可能性が高まるっぽい。

 …怪しい。
 ARPテーブルがおかしくなるとゆーことは、すなわち通信対象となるMACアドレスが変な方に向いているとゆーこと。仮に発生すればそりゃTCPパケットが行方不明ぽくなっても不思議ではない。ARPテーブルはNIC毎に保持されるので障害発生時に特定のNIC側に発生するのも説明できる。こんな現象であればより頻発してても不思議ではないが、ARPテーブルならば定期的にクリアされるだろうしおかしければ再要求もされるだろうから状況によっては自動復旧されてたのだろうと推察。

 対処としては「arp_filter」を有効にすること。ARP要求に対してより厳密に確認するためのパラメータぽい。一度検証機で試した後、仮想ルータ並びにその配下のインスタンス、更にCloudStack管理外の各物理サーバに設定(デフォルトに対して設定する「net.ipv4.conf.default.arp_filter =1」を/etc/sysctl.confに記述)。更に念の為にcronで1分毎にARPテーブルをログ保存するよう仕掛ける。

 …設定した約十分後、早速障害が発生orz
 しかしこれはむしろ「設定が生きたから」ではないかと推察。むしろこれまでが変な状態だったのだろうと。それがARPテーブルの更新のタイミングでより厳密に処理されるようになった結果、エラーとして顕在化したのではないかと。
 とりあえず三度仮想ルータを再起動→通信復旧した後、前述のARPログを見てみると、ちょうど障害が発生したタイミングでいくつかの通信対象が「Incomplete」となっており、復旧していない事を確認。「Incomplete」はarpコマンドで強制的にテーブルから削除した場合に瞬間的に発生しうる状態だが、普通はその後(接続時に)再要求が行われてすぐ復旧する。数分に渡ってIncompleteの状態になるのはさすがに異常。元々の障害時も似たような状態だったのだろうと推察。

 その後数十日間上記の状態で稼働を続けたが、通信周りの障害発生なし。念のためARPテーブルも確認し続けているがIncompleteは発生していない。
 これで多分収束したものと思われる。

 まー仮想ルータやら仮想ブリッジやら半自動でゴテゴテ作るCloudStackなので、いずれこーゆー「1物理サーバ(というか物理NIC)に割り当てられた複数の仮想NIC」的なところで問題が発生しても不思議じゃないかなぁとぼんやりと推察していたところもある。が、今回はまだしも「ARP Flux」という特定問題のヒントがあったのである程度絞れたが、ホントに1物理サーバ内で論理ネットワークを無視した変な通信し始められたら正直お手上げだよなぁ、とか漠然とオモタ。もちろんCloudStack、KVMに限らずあらゆる仮想基盤で言えることだと思うが。

追記:
 残念ながらその後もarp消失に伴う事例が発生中。ただし頻度は落ちてる。また上記arp_filterを設定しきれてない物理NICもあるので(※でも運用中なのでヘタに設定できない)とりあえずarp_filterの設定に一定の効果はあるものと思う。
 また最近CloudStackのシステムVMのバージョンが2014.06頃に上がった事を確認。取り急ぎ検証環境でシステムVMの入れ替え→仮想ルータの初期化を実行。数日経過したけどとりあえず目に見えた異常はなし。見たとこサービスのアップデートはそれほど顕著ではないが、ベースとなるOSが32bitの他64bitも選択できるようになった。前回までは32bit一択だった気がするので例えばメモリ的な処理限界に起因するものだとしたらこれでだいぶ改善される可能性もある。

関連タグ:CloudStackTCP/IP
2014-04-16 [技術]

 タイトル通り。紆余曲折の上よーやくちゃんと稼働を開始して、たくさんインスタンスやら拡張NWやら作ってそれぞれにちゃんとサービスやらF/Wやら設定して冗長化も確認してetcetcで正式稼働を開始したと思ったしばらく後に、何気にインスタンスの生成、あるいは再起動をしたら「インスタンスの生成に失敗しました」系が発生する場合に何度か遭遇。

 まあその間プライマリorセカンダリに使ってるストレージに何らかの変更を加えたor障害があった、セキュリティ設定でポートをより強く縛ったとかフツーの要因もあるでしょうが、今回遭遇したのはそう言うパターンではない話。

 事の発端は拡張NW形式の仮想ルータ。けっこーたくさんの通信を行うせいかconntrackdログが多くなり、/var領域を簡単に100%占めてしまってるのを確認。一応表面上の動作はちゃんとしてそうなんだけども、/varが100%で問題になったケースも今まで何度も味わってきてる。ローテート頻度を1日に落としたりもしたけれども間に合わず、こりゃログを外部に逃した方がよいなと、複数ある拡張NW全部にまたがるsyslogインスタンスを作ろう、と設定したところ、「インスタンスの作成に失敗しました」発生。

 ログ的には「Failed to deploy Vm with Id:XXX   on Host with Id: null」と、なんかそれっぽい事言ってるけどきっとこれではない。最初自分で登録したISOが悪いのかと思って標準テンプレで作成したらこちらは成功してしまった。じゃあISOが悪いのかと色々試したが結果変わらず。そのうち再度試した標準テンプレでもダメになってしまった。この時点でISOやらテンプレやら、及びセカンダリストレージの原因の可能性を除外。
 次にインスタンスの生成条件を色々変更。サイズやらオファリングやらネットワークやら…したところ、「複数ネットワークに属してる場合に発生」することを確認。さらに、生成に成功したインスタンスに対し後から別NWのNICを付加したところ、特定のいくつかのネットワークを付加した場合に発生することを確認。

 そいや前似たような事態になった際に、所謂「ネットワークの再起動。初期化込」をやったら治ったことがあった。でも今は正式運用後。へたげにネットワーク再起動なんかするわけにもいかない。
 ネットワーク毎に問題があるってことは、きっと仮想ルータに何か問題があるんだろうな、しかもNIC割り当てるとダメになるってことはIPアドレスの割当、DHCP周りの問題のよーな気がする。じゃあ仮想ルータにどんな問題が起きてるとゆーんだ?

 ………………あ。

 話はここで「事の発端」に舞い戻るわけです。つまり「/varが100%使い切ってる事が問題なんじゃないか」と。
 早速問題のconntrackdログを退避して消去、conntrackdを再起動、/varに空きができたことを確認。その仮想ルータに紐づくネットワークをインスタンスに追加割当、インスタンス起動…無事起動!

 いやはや正直わかりづらい。ログだけだとそれっぽい所にたどり着かないし、インスタンスの起動に関する問題だから仮想ルータのディスク領域なんかフツーは気にしないだろう。それに今回「拡張ネットワーク」だったから「複数の拡張ネットワーク間で比較ができた」けれども、これが基本ネットワーク構成だったらどうだったろう。まあネットワークの初期化再起動でクリアされる問題ではあるが…。
 そもそも拡張NWで作られる仮想ルータのconntrackdログのローテート間隔はデフォルトで週単位。トラフィックの状態によってはあっとゆー間に埋まってしまう。仮想ルータに領域追加しやすくするとか、あるいはシステムVMとして「ログVM」とか用意してシステムVM系のログはそっちに逃すとかの対策を標準でした方が良いんじゃないだろうか。

 まあそんなわけで私はこれからsyslog専用インスタンスを構築する予定です。


追記: conntrackdで外部syslogに飛ばす手法がわからなかったのでテキトーなNFSマウントを作成、そちらに保存するように変更しました。
関連タグ:CloudStack
2014-03-17 [技術・作業]

 インスタンスの起動、停止とかとボリュームからのテンプレート生成とかを同時にやるとAPI?がロックでもしあうのか片方の処理が終わるまで片方が終わらなかったり、せっかく作ったテンプレートが最後DBに登録されないとかの現象が起きる模様。
関連タグ:CloudStack
2014-02-24 [技術・作業]

 題名通り。
 とあるCloudStack4.2.1環境で、テストに使ってた標準テンプレート(CentOS5.5)ベースのインスタンスよりも正式環境用のRedHat6のインスタンスの方がHDDのアクセス速度が遅いとゆー事象が発覚。まあ題名にもある通りvirtioで動いておらずにIDEモードだったことが原因なのはすぐに判明したのですが、あれ、じゃあそもそもvirtioの利用可否とかどこで決定してるんだろう、そしてどうすれば変更されるんだろう、とゆー疑問が発生。あ、KVMね。フツーにKVMをインストールするならGUIツールからドライブをvirtioに変更すればいいのだろうけれど、その辺きっとCloudStackが管理してるだろーからへたげにいじる気にはなれない。

 色々調べてたところ、ISOの登録時の「OS Type」。これに依存してることが判明。Adminガイドを読むと「特定のPV(※準仮想化)モードに対応してるOSの場合は自動でvirtioになるよ」とのことで、RHEL6もそれに入ってはいるのだが、バグなのかなんなのかどうも反応してない様子。

 で、同じくvirtioに対応してるハズなのにハブられてる最新CentOS6.5のISOイメージを元に幾つか試したところ、標準テンプレと同様の「CentOS5.5」だとvirtioが有効になる、「Other 2.6 Linux」だとダメ。「Other PV」だとOK。同じISOでもOS Typeの選択次第でどーとでもなるらしい。ただし同じくAdminガイドでは「低レベルのOSを指定するのはお薦めしない」との事。となると「Other PV」が一番無難だろうか。

 さて上記はあくまでISOを登録するタイミングでの話。すでにインストしてしまったものはどうにもならないのだろうか。とりあえずインスタンスをテンプレ化してから操作でも試してみるかなとインスタンス停止。ついでに名前を変えてみるか…とふとインスタンスの編集モードに移行してみたところ、あらまあ「OSの種類」が再選択できるようになってるじゃないですかw 早速「Other PV」を選択。起動。特に問題なく起動。dfかけてみたところそれまで「/dev/sda」だったドライブが「/dev/vda」とvirtioモードに移行したことを確認。更にddで1GBくらい強制書き込みしたときの速度が向上してることを確認。やれやれ。

 で、なんでそもそもなんでこんな話になったかとゆーと、virtio環境とIDE環境下で上記ddの結果が5倍くらいの差が出た事がそもそもの発端。今回とあるSANを共有エリアとしたCLVM環境で構築したのだけれどもなんかえらくダイレクトに数値が出た感じ。

関連タグ:CloudStack
2014-02-05 [技術・作業]

 試用していたCloudStack4.0.2がある程度落ち着いたので、最新版での運用が可能か今度は4.2の検証をしてみた。というかしている。まだやり切れてるわけではないけど取り敢えず現状で把握したことなど。なお例によって間違いや嘘が交じる可能性があるのでご注意。
 なお環境としては引き続きCentOS6.4のKVMベース。NICが2枚あるPCサーバ3台(管理x1 ホストx2)で構築。ホストは2枚のNICのそれぞれにIP持ちのブリッジcloudbr0、cloudbr1を設定(つまりインストールマニュアルとはNIC構成が異なる)。

  • 基本的な雰囲気は4.0系列と同じような感じ。それほど違和感なく進められる。
  • 名称、コマンド等が「cloud~」から「cloudstack~」に変更。初期DB投入スクリプトが「cloudstack-setup-databases」になったのとか。
  • システムVMイメージのダウンロードURLが4.0系列からは変更されてる。まあマニュアルに従ってインストール進めてれば問題なし。
  • 4.0系列では「yum install cloud-agent」でKVM関係までインストールされた(ような気がする)が4.2だと入らない模様。別途「yum install kvm」で追加する。
  • 4.2に限ったことではないが、自動で入るiptablesの状況(ブリッジに対するFORWARDのDROP等)次第ではシステムVMが外部にアクセス出来ない事がある。しかもそのiptable設定が入るタイミングがよくわからない。(投入直後は大丈夫だったのに翌日になったらダメになってたとか)
→投入タイミングは色々ある模様。例えばマイグレーションを行なった時に受けた側のホストはiptablesの設定が書き換わる。
→iptable設定を書き換えるスクリプトは「/usr/share/cloudstack-common/scripts/vm/network/security_group.py」である模様。
 上記ファイルの下記をコメントアウトすればブリッジに対するFORWARDのDROP処理は停止する。
→もちろんこれがセキュリティ的に、且つどの環境でも正しいかは不明。無条件許可が正しいとは思えない一方で、ブリッジはいわばスイッチだから無条件で止められても困るよなぁと。
  • 手動で入れる主なiptables設定は管理・ホスト側とも4.0系列と同じ。
  • ホスト投入直後だとシステムVMを含むインスタンスの作成にコケるのも一緒。もうクラスタにホストを追加したらagent、libvirtdは再起動するのはデフォにした方が良い気がしてきた。
  • ひと通りゾーンの基本設定を終えた後にじゃあホストを追加しようとしたところ「Guid is not updated for cluster with specified cluster id; need to wait for hosts in this cluster to come up」とゆーエラーが出て追加が出来なかった。
→とりあえず原因を突き詰めると、当該クラスタの情報テーブル「cluster」の「guid」が「NULL」なっていることが原因の様子。
→このguidはクラスタ生成直後はNULLで、その後ホストを追加するとよくあるランダムげなidが投入される。どこか別のテーブルとリンクしてるかは不明。とりあえず「host」テーブルとリンクしてる箇所はない模様。
→どうもこのguid、初期のホストの作成に失敗→その後手動で再設定や強制接続を行なってホストを有効にした場合は入ってくれないらしい。
→初期ホスト投入時のみNULL値を無視すると思われる。その後は「ホスト投入が完了してない」と判断して上記エラーが出る、のか。
→とりあえず暫定的な手法として、当該クラスタのguiidになんでもよいので適当な値を代入しとけばこのエラーは出なくなりホストの追加が可能になる。ぶちゃけ以下の状態でも可。
   update cluster set guid='a' where id=[当該クラスタのID]
→もちろんこんなのが良いとはとても思えない。なんかリンクしてるところがあるならそこから引っ張ってきたいし、そうでないにしても従来のフォーマットに基づいた値を投入したいところ。
→あるいは 「初期状態」と判定させられれば良いのだろうが、それを判定しているフラグはテーブル内にはなさそう。詳細はプログラムを追わなければわからないか。
→なおこのguidは特にその後の操作(更なるホスト追加等)で上書きされることはない。
→ただし、クラスタ内から全てのホストを削除するとまたNULL値が入る。こうなるとまた同じエラーが出てホストの追加が出来なくなる。こうなったらクラスタも消して再作成した方が多分速い。
2013-12-10 [技術]

 タイトル通り。久々に技術ネタ。とあるシステム一群を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 [技術]