【OpenStack】metadataのOpenStackでの使用(一)

宣言:
このブログは転送を歓迎しますが、原作者の情報を残してください.
新浪微博:@孔令賢HW;
ブログアドレス:http://blog.csdn.net/lynn_kong
内容は本人の学习、研究と総括で、もし同じであれば、本当に光栄です!
バージョン:Grizzly masterブランチ2013.6.17配備:3ノード(controller+network+compute)ネットワークタイプ:vlanの前のblogで仮想マシンアクセス169.254.169.254の問題に遭遇し、F版ではネットワークノード上でNAT変換を行い、novaのmetadataサービスに直接アクセスするが、この方法はnamespaceを使用する際には有効ではない.namespaceはIPアドレスのオーバーラップをサポートするため、novaはどの仮想マシンがmetadataを要求しているのか区別できません.この問題はG版で解決され、blueprintはここにある.採用する方法は,HTTPヘッダでどの仮想マシンであるかを識別することである.同時に、G版はQuantumに2つのサービスを追加しました:namespace metadata proxyとmetadata agent.1つの仮想マシンが169.254.169.254にアクセスするプロセスは、次の図のようになります:
流れを詳しく話す前に、metadataの役割と由来を知らない人が多いと思います.分からない子供靴はここを見てください.
1、仮想マシンが仮想マシンの起動を要求すると、169.254.169.254にアクセスしていくつかのコンテンツを取得します.これは私が前に間違っていたログから見ることができます.
'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [0/120s]: http error [404]
仮想マシンの内部アクセス169.254.169.254、何があるか見てみましょう.

ubuntu@ubuntu-test:~$ curl http://169.254.169.254/2009-04-04/meta-data
ami-id
ami-launch-index
ami-manifest-path
block-device-mapping/
hostname
instance-action
instance-id
instance-type
kernel-id
local-hostname
local-ipv4
placement/
public-hostname
public-ipv4
public-keys/
ramdisk-id

では、これらのコンテンツはどのように取得されますか?仮想マシン内部には特別なルーティングがないため、パケットは仮想マシンのデフォルトゲートウェイに直接送信され、デフォルトゲートウェイはnetwork nodeにあります.仮想マシンのNIC情報は次のとおりです.

ubuntu@ubuntu-test:~$ ip -4 address show dev eth0
2: eth0:  mtu 1500 qdisc pfifo_fast state UP qlen 1000
inet 10.1.1.2/24 brd 10.1.1.255 scope global eth0

仮想マシンのルーティング情報:

ubuntu@ubuntu-test:~$  ip route
default via 10.1.1.1 dev eth0  metric 100 
10.1.1.0/24 dev eth0  proto kernel  scope link  src 10.1.1.2

2、namespace-metadata-proxy namespaceを使用しているため、network node上の各namespaceには対応するiptablesルールとネットワークデバイスがあります.
まず、対応するiptablesルールを見てみましょう.

-A quantum-l3-agent-PREROUTING -d 169.254.169.254/32 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 9697
-A quantum-l3-agent-INPUT -d 127.0.0.1/32 -p tcp -m tcp --dport 9697 -j ACCEPT

仮想マシンのデフォルトゲートウェイ装置情報のアドレス情報は、仮想マシンゲートウェイのIP(10.1.1.1)を見ることができる.

root@network232:~# ip netns exec qrouter-b147a74b-39bb-4c7a-aed5-19cac4c2df13 ip addr show qr-f7ec0f5c-2e
12: qr-f7ec0f5c-2e:  mtu 1500 qdisc noqueue state UNKNOWN 
    link/ether fa:16:3e:81:9c:69 brd ff:ff:ff:ff:ff:ff
    inet 10.1.1.1/24 brd 10.1.1.255 scope global qr-f7ec0f5c-2e
    inet6 fe80::f816:3eff:fe81:9c69/64 scope link 
       valid_lft forever preferred_lft forever

iptablesルールでは、宛先アドレス169.254.169.254のパケットをローカルポート9697にリダイレクトします.では、network nodeのポートのリスニングプロセスを見てみましょう.

root@network232:~# ip netns exec qrouter-b147a74b-39bb-4c7a-aed5-19cac4c2df13 netstat -nlpt | grep 9697
tcp        0      0 0.0.0.0:9697            0.0.0.0:*               LISTEN      13249/python

プロセス番号13249、このプロセスを見てください.

root@network232:~# ps -f --pid 13249 | fold -s -w 85 
UID        PID  PPID  C STIME TTY          TIME CMD
root     13249     1  0 16:30 ?        00:00:00 python 
/usr/bin/quantum-ns-metadata-proxy 
--pid_file=/var/lib/quantum/external/pids/b147a74b-39bb-4c7a-aed5-19cac4c2df13.pid 
--router_id=b147a74b-39bb-4c7a-aed5-19cac4c2df13 --state_path=/var/lib/quantum 
--metadata_port=9697 --debug --verbose 
--log-file=quantum-ns-metadata-proxyb147a74b-39bb-4c7a-aed5-19cac4c2df13.log 
--log-dir=/var/log/quantum

このプロセスがどこから来たのか、この問題を説明し、コードを貼る必要があるかもしれません.

    def _spawn_metadata_proxy(self, router_info):
        def callback(pid_file):
            proxy_cmd = ['quantum-ns-metadata-proxy',
                         '--pid_file=%s' % pid_file,
                         '--router_id=%s' % router_info.router_id,
                         '--state_path=%s' % self.conf.state_path,
                         '--metadata_port=%s' % self.conf.metadata_port]
            proxy_cmd.extend(config.get_log_args(
                cfg.CONF, 'quantum-ns-metadata-proxy-%s.log' %
                router_info.router_id))
            return proxy_cmd

        pm = external_process.ProcessManager(
            self.conf,
            router_info.router_id,
            self.root_helper,
            router_info.ns_name())
        pm.enable(callback)

が表示されます.namespaceシーンを有効にすると、routerごとにこのようなプロセスが作成されます.プロセスは9697ポートをリスニングします.主な機能は次のとおりです.
1、要求ヘッダにX-Forwarded-ForとX-Quantum-Router-IDを追加し、それぞれ仮想マシンのfixedIPとrouterのIDを表す
2、要求をUnix domain socket(/var/lib/quantum/metadata_proxy)に代理する
3、Quantum Metadata Agent network node上のmetadata agent傍受/var/lib/quantum/metadata_proxy:

root@network232:~# netstat -lxp | grep metadata
unix  2      [ ACC ]     STREAM     LISTENING     46859    21025/python        /var/lib/quantum/metadata_proxy
root@network232:~# ps -f --pid 21025 | fold -s 
UID        PID  PPID  C STIME TTY          TIME CMD
quantum  21025     1  0 16:31 ?        00:00:00 python 
/usr/bin/quantum-metadata-agent --config-file=/etc/quantum/quantum.conf 
--config-file=/etc/quantum/metadata_agent.ini 
--log-file=/var/log/quantum/metadata-agent.log

このプロセスの機能は、要求ヘッダのX-Forwarded-ForおよびX-Quantum-Router-IDパラメータに従ってQuantum serviceに仮想マシンIDを問合せ、次にNova Metadataサービスに要求(デフォルトポート8775)を送信し、メッセージヘッダ:X-Forwarded-For、X-Instance-ID、X-Instance-ID-IDはそれぞれ仮想マシンのfixedIP、仮想マシンIDおよび仮想マシンIDの署名を表す.
4、Nova Metadata Services Novaのmetadata Servicesはnova-apiとともに起動し、ec 2,osapi_の3つのサービスを同時に起動するcompute, metadata.仮想マシンは169.254.169.254の戻り内容にアクセスします.実はmetadataサービスがnova-conductorにクエリーした後、network nodeのmetadata agentに戻り、metadata agentからmetadata proxyに戻り、仮想マシンに戻ります.

root@controller231:~# netstat -nlpt | grep 8775
tcp        0      0 0.0.0.0:8775            0.0.0.0:*               LISTEN      1714/python     
root@controller231:~# ps -f --pid 1714
UID        PID  PPID  C STIME TTY          TIME CMD
nova      1714     1  0 16:40 ?        00:00:01 /usr/bin/python /usr/bin/nova-api --config-file=/etc/nova/nova.conf