前の記事で書いた環境で
単一PC上にCloudStack4.1をインストールして、
いざインスタンスを立ち上げ
コンソール画面を開こうとしたら
 |
| 前回の記事の環境 |
「接続がタイムアウトしました
192-168-XXX-XXX.realhostip.com のサーバからの応答が
一定時間以内に返ってきませんでした。」
とでてきて接続できない問題が発生した。
グローバル設定の consoleproxy.url.domain に
かかれているドメイン名を使ったFQDNなのだけど、
クライアントPC上でlookupするとDHCPで割り当てられた
ルータへいってしまい誰もどこにあるかわからない。
でしらべてみると、
How to Replace realhostip.com with Your Own Domain Name
という記事に、
ゾーン内にbind9(DNS)きってローカルネット側に
192-168-XXX-YYY.realhostip.comが192.168.XXX.YYYであると
正引きできるようにすれば良いみたいなことが書かれている。
ドメイン名は上記のグローバル設定変更でかえることができる。
bind9を入れる気力がなかったので.
クライアントPCのhostsに直接書き込んで対処した。
Windows7ならC:\Windows\System32\drivers\etc\hostsを
ノートパッド（管理者権限起動）で
192.168.11.141 192-168-11-141.realhostip.com
192.168.11.142 192-168-11-141.realhostip.com
～
と男らしく書いていく。
本格的にCloudStack運用する場合はDNSサーバは必要だな..
でもそれだけじゃないな..結局のところ192.168.11.xセグメントに
192.168.11.1と192.168.11.100という２つのルータがつながっているようなもの
なので、これをなんとかするにはきちんとrouteコマンドで処理しとかないと..
routeコマンドで「192.168.11.141～160」へ通信する場合は
192.168.11.100をゲートウェイにしてねという設定を実行し無くてはならない。
ルーティング変更目的でrouteコマンドをWindowsで使用する場合は、
コマンドプロンプトを管理者権限であげること。
（route PRINTでテーブルの状態見るくらいなら通常起動でもOK）
で、ここではたと気づいたのだけど、
CloudStack管理下のセグメントを着る場合はCIDR表記ができるようにしとけばよかった..
そうすればrouteコマンドでプライベートアドレス範囲はこのゲートウェイというように
綺麗に１発で指定できる。
そうしないと192.168.11.141/32から192.168.11.160/32まで2回routeコマンド打たないと
いけなくなるんじゃ..
サブネット計算苦手な人はこちらの計算サイト(IPv4)があります。
IPの範囲指定する場合はできるだけCIDRで切れる範囲を
選ぶようにしよう..
で次にクライアントPC上で以下のrouteコマンドを1つづつ発行した。
route add 192.168.XXX.YYY mask 255.255.255.255 192.168.11.100 metric 1
そして再度管理コンソールからコンソール画面開こうとしたのだけど..
あれ？ひらかない..
CloudStack All in One サーバ(192.168.11.100)からプライベートセグメントへの
ルーティングがない..
管理サーバからは、いくつかネットワーク設定があるが
cloud0: オートナンバ用
cloudbr0: サーバのNICへつながるブリッジ
eth0: 物理的なNICをさす
virbr0: 192.168.122.1(KVMインストールするとできる)
だろうからvnet0～9があやしいのだけど..
どのネットワークがインスタンスが使用しているのかがわからないので
ルーティングしようがない..
うーん、All in Oneサーバはクライアントも兼ねないと駄目かな..
taskselしてUbuntu Desktopインストール
して管理サーバ上でブラウザあげて
そこで管理コンソールを開けるか..
0 件のコメント:
コメントを投稿