OpenStack仮想マシンネットワークに問題があることがわかったら、まずは以下の16の手順を試してください。

1. すべてのセキュリティ グループを開きます。これは最も基本的なことですが、多くの人が忘れがちです。

[[231785]]

実際、私はそのようなシナリオに数え切れないほど遭遇してきました。長い間ネットワークの問題をデバッグし、さまざまな方法を使用しましたが、最終的にセキュリティ グループが開かれていないことがわかりました。

2. インターフェイスを介して VM ログを確認するか、コンピューティング ノードの console.log ファイルをチェックして、DHCP IP 取得の成功のログがあるかどうかを確認します。

インターフェース上でコンソールログを見ることができます

計算ノードで表示できます

/var/lib/nova/instances/6323a941-de10-4ed3-9e2f-1b2b25e79b66/console.log

ログがない場合は、画像に問題があることを意味します。

グラブで

linux /boot/vmlinuz-3.2.0-49-仮想ルート=UUID=6d2231e4-0975-4f35-a94f-56738c1a8150 ro コンソール=ttyS0

GRUB_CMDLINE_LINUX_DEFAULT="コンソール=ttyS0"

アップデート-grub

3. 仮想マシンがDHCPサーバーに接続できない場合は、メタデータサーバーを使用せず、ユーザー名とパスワードでログインできるイメージを準備する必要があります。

このような画像は簡単に作れます。自分で作ることもできます。イメージを起動した後、cloud-init 関連の構成を削除し、デフォルトのユーザー名とパスワードを設定します。

4. VNC経由でログイン

5. VNC 経由でログインできない場合は、VNC 設定に問題があることを意味します。方法1: VNCを再設定する

VNC プロキシの機能:

• パブリックネットワークをプライベートネットワークから分離する
• VNC クライアントはパブリック ネットワーク上で実行され、VNC サーバーはプライベート ネットワーク上で実行され、VNC プロキシはこれら 2 つを接続するブリッジとして機能します。
• VNCプロキシはトークンを介してVNCクライアントを認証します
• VNC プロキシは、プライベート ネットワーク アクセスをより安全にするだけでなく、特定の VNC サーバー実装を分離し、ユーザー エクスペリエンスに影響を与えることなく、異なるハイパーバイザーの VNC サーバーをサポートできます。

VNCプロキシの展開

• トークン検証のためにコントローラーノードに nova-consoleauth プロセスをデプロイする
• コントローラーノードに nova-novncproxy サービスをデプロイします。ユーザーの VNC クライアントはこのサービスに直接接続します。
• コントローラー ノードには通常、2 つのネットワークに接続された 2 つのネットワーク カードがあります。 1 つは外部アクセス用で、パブリック ネットワークまたは API ネットワークと呼ばれます。このネットワーク カードの IP アドレスは、図の 172.24.1.1 などの外部ネットワーク IP です。もう 1 つのネットワーク カードは、OpenStack のさまざまなモジュール間の通信に使用され、管理ネットワークと呼ばれます。これは通常、図の 10.10.10.2 などの内部ネットワーク IP です。
• コンピュートノードにnova-computeをデプロイし、nova.confファイルに次の設定を記述します。
• vnc_enabled=True
• vncserver_listen=0.0.0.0 //VNCサーバーのリスニングアドレス
• vncserver_proxyclient_address=10.10.10.2 //nova vnc proxy はイントラネット IP 経由で vnc サーバーにアクセスするため、nova-compute は vnc proxy にこの IP を使用して接続するように指示します。
• novncproxy_base_url=http://172.24.1.1:6080/vnc_auto.html //この URL はクライアントに返される URL なので、その中の IP は外部ネットワーク IP です。

VNC プロキシの操作プロセス:

1. ユーザーは、ブラウザから VNC クライアントを開いて仮想マシンに接続しようとします。
2. ブラウザはnova-apiにリクエストを送信し、vncにアクセスするためのURLを返すように要求します。
3. nova-apiはnova-computeのget vncコンソールメソッドを呼び出し、VNC接続情報の返却を要求します。
4. nova-compute は libvirt の get vnc console 関数を呼び出します。
5. libvirt は、仮想マシンを実行している /etc/libvirt/qemu/instance-0000000c.xml ファイルを解析して VNC サーバー情報を取得します。
6. libvirt はホスト、ポート、その他の情報を JSON 形式で nova-compute に返します。
7. nova-computeはトークンとしてUUIDをランダムに生成します
8. nova-computeはlibvirtから返された情報と設定ファイルの情報をconnect_infoに結合し、nova-apiに返します。
9. nova-apiはnova-consoleauthのauthorize_console関数を呼び出します。
10. nova-consoleauth はインスタンス -> トークン、トークン -> connect_info の情報をキャッシュします。
11. nova-api は connect_info 内のアクセス URL 情報をブラウザに返します: http://172.24.1.1:6080/vnc_auto.html?token=7efaee3f-eada-4731-a87c-e173cbd25e98&title=helloworld%289169fdb2-5b74-46b1-9803-60d2926bd97c%29
12. ブラウザはリンクを開こうとします
13. このリンクはnova-novncproxyにリクエストを送信します
14. nova-novncproxy は nova-consoleauth の check_token 関数を呼び出します。
15. nova-consoleauthはトークンを検証し、インスタンスに対応するconnect_infoをnova-novncproxyに返します。
16. nova-novncproxyは、connect_infoのホスト、ポート、その他の情報を介してコンピュートノード上のVNCサーバーに接続し、プロキシ作業を開始します。

6. VNCログインが失敗した場合は、別の方法があります。独自のVNCクライアントを使用して、コンピューティング物理ノードのIPアドレスを介してログインします。

qemu-system-x86_64 にはパラメータ -vnc 0.0.0.0:5 があります

コンピューティングノードのIPアドレスを通じてアクセスできます

7. ovs-vsctl show と brctl を使用して、各ネットワーク カードとブリッジの関係が正しいかどうか、トンネルが接続されているかどうか、ネットワーク カードがアップ状態であるかどうかを確認します。

8. 仮想マシンの仮想ネットワーク カードから DHCP サーバーのネットワーク カードへの構成が正しい場合は、br-tun 上の ovs-ofctl dumpflows をチェックして、パケットのフロー ルールが正しく書き換えられているかどうか、および正しいルールがあるかどうかを確認する必要があります。

9. VNC 経由でログインした後、コマンド ラインから dhclient を実行して DHCP サーバーへの接続を再開できます。コンピューティング ノード上のネットワーク カードとブリッジに対して tcpdump を 1 つずつ実行して、どのネットワーク カードまたはブリッジがパケットを受信しなかったか、および受信したパケット内の VLAN ID が正しいかどうかを確認します。

10. VM が DHCP サーバーから IP を取得できる場合、作業の半分は完了です。次に、cloud-initを使用してイメージに変更し、メタデータサーバーが正常に接続してキーを挿入できるかどうかを確認します。これもconsole.logで確認できます。

11. メタデータ サーバーに正常に接続できない場合は、メタデータ サーバーのプロセス全体を 1 つのモジュールずつ実行し、各モジュールのログをチェックして、ポートが正しいかどうか、要求が受信されているかどうかをチェックするか、VM で curl を使用してメタデータ サーバーの要求をシミュレートする必要があります。

OpenStack のメタデータは、ユーザーが各インスタンスのパラメータを設定するためのメカニズムを提供します。たとえば、ホスト名など、インスタンスの特定の属性を設定するとします。

インスタンス アクセス メタデータ サーバー http://169.254.169.254

メタデータの重要な用途は、各インスタンスの SSH 公開キーを設定することです。

メタデータを取得するための API インターフェースは次のとおりです。

http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key

この IP アドレスは Openstack に存在しません。なぜメタデータを取得できるのですか?

これはAmazonのせいです。メタデータはAmazonによって最初に提案されました。参照: http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/AESDG-chapter-instancedata.html

その後、多くの人が Ubuntu、Fedora、CentOS などの一部のオペレーティング システム イメージを Amazon 用にカスタマイズし、Metadta を取得するための API アドレスもハードコードしました。したがって、互換性のために、OpenTack はアドレス 169.254.169.254 を予約しています。

次に、iptables NAT を介して実際の API にマップします。

iptables -A nova-network-PREROUTING -d 169.254.169.254/32 -p tcp -m tcp --dport 80 -j DNAT --to-destination 16.158.166.197:8775

Nova はどの仮想マシンがメタデータを要求しているかをどのように区別しますか?採用されるアプローチは、HTTP ヘッダーでどの仮想マシンであるかを識別することです。

仮想マシンが 169.254.169.254 にアクセスするプロセスは次のとおりです。

（１）仮想マシンがリクエストを送信する

• 仮想マシンが起動すると、169.254.169.254にアクセスします。
• データパケットは仮想マシンのデフォルトゲートウェイ172.71.71.1に直接送信されます。
• デフォルトゲートウェイはネットワークノードqr-XXXXXにあります

（２）名前空間内のiptables

• 名前空間が使用されるため、ネットワーク ノード上の各名前空間には、対応する iptables ルールとネットワーク デバイスが存在します。
• iptablesルールでは、宛先アドレス169.254.169.254のデータパケットはローカルポート9697にリダイレクトされます。

ip netns exec qrouter-5a74908c-712c-485c-aa9f-6c1e8b57e3e1 iptables -t nat -nvL

(3) 名前空間メタデータプロキシ

名前空間が有効になっている場合、このようなプロセスがルータごとに作成されます。このプロセスはポート 9697 をリッスンし、主な機能は次のとおりです。

1. リクエスト ヘッダーに X-Forwarded-For と X-Neutron-Router-ID を追加し、それぞれ仮想マシンの固定 IP アドレスとルーターの ID を示します。

2. リクエストをUnixドメインソケット（/var/lib/neutron/metadata_proxy）にプロキシする

(4) 中性子メタデータエージェント

ネットワーク ノード上のメタデータ エージェントは、/var/lib/neutron/metadata_proxy をリッスンします。

このプロセスの機能は、リクエスト ヘッダーの X-Forwarded-For および X-Neutron-Router-ID パラメータに従って Neutron サービスから仮想マシン ID を照会し、Nova メタデータ サービス (デフォルト ポート 8775) にリクエストを送信することです。メッセージ ヘッダー: X-Forwarded-For、X-Instance-ID、X-Instance-ID-Signature は、それぞれ仮想マシンの固定 IP、仮想マシン ID、仮想マシン ID の署名を表します。

12. メタデータ サーバーに正常に接続でき、キーが正常に挿入された場合、次のステップでは、名前空間から ping および ssh を実行できるかどうかを確認します。

13. 名前空間が成功した場合は、フローティング IP に ping を実行し、ネットワーク ノードで SSH を実行して、成功したかどうかを確認します。そうでない場合は、br-ex ネットワーク カードが正しく追加されているかどうか、IP が設定されているかどうか、ルーティング テーブルが正しいかどうか、および名前空間内のフローティング IP の iptables ルールが正しく追加されているかどうかを確認します。

14. ネットワーク ノード上のフローティング IP に ssh できる場合は、他のノードからも ssh する必要があります。失敗した場合は、br-ex URL 構成に問題がある可能性があります。 br-ex によって追加された物理ネットワーク カードが混在状態ではない可能性があります。ルーティング構成に問題がある可能性もあります。フローティング IP が配置されているネットワーク セグメントの場合、ネットワーク ノードを指しません。

15. フローティング IP が成功した場合は、VM で apt-get update を実行する必要があります。そうでない場合は、OpenStack でゲートウェイ (10.0.0.1) に ping できるかどうかを確認し、次に物理ネットワーク環境でゲートウェイ (16.158.XXX.1) に ping できるかどうかを確認します。

16. DNS サーバーが正しく構成され、ping できるかどうかを確認します。可能であれば、apt-get update は正常に実行されます。