Tag: Quantum

quantum lbaas

create pool

$ NET_ID=e5768970-4e96-467d-9be1-e0e0b789f025
$ quantum lb-pool-create --name test --lb-method \
  ROUND_ROBIN --protocol TCP --subnet-id=$NET_ID

quantum lb-pool-list
+--------------------------------------+------+-------------+----------+----------------+----------------+
| id                                   | name | lb_method   | protocol | admin_state_up | status         |
+--------------------------------------+------+-------------+----------+----------------+----------------+
| 044208a8-9e29-4fee-b41b-9b58567f3874 | test | ROUND_ROBIN | TCP      | True           | PENDING_CREATE |
+--------------------------------------+------+-------------+----------+----------------+----------------+

create vip

$ quantum lb-vip-create --name test-vip1 --protocol-port 80 --protocol TCP --subnet-id=$NET_ID test
$ quantum lb-vip-list
+--------------------------------------+-----------+-------------+----------+----------------+--------+
| id                                   | name      | address     | protocol | admin_state_up | status |
+--------------------------------------+-----------+-------------+----------+----------------+--------+
| 515fa2c5-a135-4b59-b247-803e844383f1 | test-vip1 | 10.10.100.5 | TCP      | True           | ACTIVE |
+--------------------------------------+-----------+-------------+----------+----------------+--------+

여기서 pool도 status가 ACTIVE로 바뀌고.. lbaas가 동작하는 노드에 qlbaas- 로 ip namespace가 생긴다.

생성된 vip에... 다른 port로 만들면 오류가 발생

$ quantum lb-vip-create --name test-vip-https --protocol-port 443 --protocol TCP --subnet-id=$NET_ID test --address=10.10.100.5
Another Vip already exists for pool 044208a8-9e29-4fee-b41b-9b58567f3874

fixed ip에서 vip 찾아내기…

Quantum으로 인스턴스의 fixed ip를 기준으로 해당 인스턴스의 load balancer에 연결된 vip 얻어오기

  • overlapping ip 환경에서는 안됨... network을 구분하지 못해서...

Quantum Provider network

Provider Network은 문서상에 나와있는 내용을 그대로 빌리자면, OpenStack 네트워킹 네트워크를 데이터 센터의 physical network와 직접적으로  mapping하는 네트워크 입니다. 즉, 데이터 센터에서 제공하는 네트워크를 바로 tenant network에 사용하는 것입니다.

일반적으로 데이터센터에서 제공하는 네트워크는 vlan으로 구분하여 제공하게 됩니다. 이런 상황에서 하나의 vlan을 하나의 tenant에 전용으로 할당하는 것은 효율적이지 않습니다. 이는 vlan이라는 성격상 4096개의 제한도 있겠지만, 데이터 센터의 네트워크 계획에 따라서 vlan을 할당하므로 사용자가 직접 네트워크를 만드는 모델은 적합지 안습니다. provider network 생성 자체를 admin 권한으로 생성하는 것이 아마 이것과 관련있을지 모르겠습니다.

물론 보안 요구사항등의상황에 따라서 특정 provider network을 특정 tenant에 할당하여 사용할 수 있지만, 이 경우는 ip address 낭비를 위하여 subnet mask를 적절히 조절해야 되겠습니다.

provider network으로 네트워크를 디자인한다면...

  • vlan 4개를 24비트로 데이터 센터에서 할당 받음
    • vlan 100: 10.10.100.0/24
    • vlan 101: 10.10.101.0/24
    • vlan 200: 10.10.200.0/24
    • vlan 201: 10.10.201.0/24
  • 각 vlan의 gateway는 각 주소의 1번(e.g. 10.10.100.1)으로 설정됨
  • admin 계정으로 각 vlan에 해당되는 네트워크를 provider network으로 생성
  • tenant들이 해당 네트워크에 인스턴스를 만들 수 있다록 shared network으로 생성

이를 하기 위한 physical node의 네트워크 연결은 network, compute 노드 모두

  • eth0: management
  • eth1: vlan tagging 100, 101, 200, 201, 물론 해당 gateway까지 연결 가능해야함.

그리고 shard network을 사용하고, private network을 사용하지 않기 때문에 l3-agent는 사용하지 않습니다. 그렇기 때문에 private network을 사용했을 때와 같이 external network용 NIC가 필요없습니다.

OpenStack Settings

/etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini

tenant_network_type = vlan
network_vlan_ranges = default:100:101,default:200:201
bridge_mappings=default:br-eth1

tenant_network_type = vlan

provider network으 vlan으로 제공되기 때문에 vlan으로 설정합니다.

network_vlan_ranges = default:100:101,default:200:201

데이터 센터의 상황에 따라서는 연속적인 vlan을 사용할 수 없을 수 있습니다. 그런 경우를 테스트하기 위해서 위처럼 따로 떨어진 범위의 vlan을 설정해봤으며, 이 두 개를 설정하는 것은 위의 예제처럼 컴마(,)로 분리하면 됩니다.

bridge_mappings=default:br-eth1

network_vlan_range에서 설정한 네트워크가 어떤 ovs bridge와 mapping이 될 지 설정합니다. 이 bridge는 openvswitch-agent에서 자동으로 만들어지므로, 별도의 작업은 필요 없습니다.

Create Network

provider network은 admin 권한으로만 생성이 가능합니다. 따라서 admin user에서 생성합니다. 그리고 provider network은 horizon에서 만드는 기능이 없습니다. quantum cli로 아래처럼 만듭니다.

vlan tag 번호와, --shared 옵션을 확인하기 바랍니다.

$ quantum net-create pub100 --provider:network_type vlan \
    --provider:segmentation_id=100 --shared
$ quantum net-create pub101 --provider:network_type vlan \
    --provider:segmentation_id=101 --shared
$ quantum net-create pub200 --provider:network_type vlan \
    --provider:segmentation_id=200 --shared
$ quantum net-create pub201 --provider:network_type vlan \
    --provider:segmentation_id=201 --shared

그리고 만들어진 네트워크에 아래처럼 subnet을 할당합니다.

$ quantum subnet-create pub100 10.10.100.0/24
$ quantum subnet-create pub101 10.10.101.0/24
$ quantum subnet-create pub200 10.10.200.0/24
$ quantum subnet-create pub201 10.10.201.0/24

subnet을 생성할 때는, 반드시 데이터 센터에서 할당핟은 network cidr을 잘 맞춰서 생성해야 합니다.

일반 사용자에서 quantum net-list 명령으로 보면 shared network이기 때문에 방금 생성한 네트워크의 정보를 확인할 수 있습니다.

$ quantum net-list
+--------------------------------------+--------+-----------------------------------------------------+
| id                                   | name   | subnets                                             |
+--------------------------------------+--------+-----------------------------------------------------+
| 546f14c5-b837-41ef-964a-0eba46aa23f9 | pub101 | 34b28d6f-5398-46ed-ba9e-f848ef6269b0 10.10.101.0/24 |
| 7b455fae-a2a5-4204-b04a-4859f335580d | pub100 | 238340a8-7d9c-4a5b-ac34-d8047e1c3f5a 10.10.100.0/24 |
| ce24e1ec-f256-4d81-b99d-668847d7a472 | pub200 | 48df6481-b952-4c92-a8f3-6293ecb4186c 10.10.200.0/24 |
| fc427218-8244-4284-b68c-d3429c8cccec | pub201 | 82274a91-95fb-42cf-895e-e70efff4b062 10.10.201.0/24 |
+--------------------------------------+--------+-----------------------------------------------------+

물론 shared network이므로 network의 subnet 정보도 확인 할 수 있습니다.

Create Instance

Instance를 생성하는 것은 동일합니다.

다만, 여기서는 생성할 수 있는 네트워크가 4가지가 되는데, 사용가자 생성할 때 4가지 중에 하나의 네트워크를 선택해야합니다. 개인적인 의견으로는 아무 네트워크나 자동으로 골라서 만들어주는 옵션이 있으면 좋겠는데, 아직 그런 기능이 없군요.

뭐, 간단한 스크립팅으로 가능은 하겠지만요..

Metadata problem...

인스턴스는 잘 생성이 됩니다. dhcp에서도 ip를 잘 받아옵니다. 그런데 ssh로 연결이 안됩니다. 인스턴스 로그에서 보면 바로 확인할 수 있는데, metadata를 받아오지 못하기 때문입니다.

private network을 사용했던 경우에는 l3-agent가 동작하는 tenant의 default gateway에서 169.254.169.254/32로 가는 요청을 잡아서 quantum-metadata-agent로 보내고, 여기서 다시 nova-api에서 서비스되는 메타데이터 서버로 proxy를 하는 작업을 거칩니다.

그런데 여기서 생성했던 provider network은 l3-agent가 없습니다. 즉, 169.254.169.254로 가는 트래픽은, 데이터 센터에서 제공해주는 physical 라우터로 향하게 됩니다. OpenStack이 관할하는 곳을 벗어나서, metadata를 얻어오지 못하는 것이죠.

그런데, 이 경우에도 대비해서 quantum을 잘 살펴보면 dhcp-agent에서 metadata-ns-metadata-proxy를 띄울 수 있는 옵션이 있습니다.

dhcp_agent에서 quantum-ns-metadata-proxy 띄우기

설정은 간단합니다. 아래처럼 설정해주고,

/etc/qantum/dhcp_agent.ini:

enable_isolated_metadata = True

설정하고, dhcp-agent를 재시작한 후, dhcp-agent가 동작하는 namespace를 보면 아래처럼 169.254.169.254/16 이라는 ip address가 설정된 것을 확인할 수 있습니다.

$ ip netns exec qdhcp-7b455fae-a2a5-4204-b04a-4859f335580d ip a
50: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
51: ns-61eaed6f-d0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether fa:16:3e:ad:73:bb brd ff:ff:ff:ff:ff:ff
    inet 10.10.100.3/24 brd 10.10.100.255 scope global ns-61eaed6f-d0
    inet 169.254.169.254/16 brd 169.254.255.255 scope global ns-61eaed6f-d0
    inet6 fe80::f816:3eff:fead:73bb/64 scope link
       valid_lft forever preferred_lft forever

이제 instance에서 아래처럼 확인하면 meta-data를 가져오는 것을 확인할 수 있습니다.

$ curl http://10.10.100.3/latest/meta-data/

근데... 헐.. 169.254.169.25로 호출하지 않고, 10.10.100.3으로 요청을 했네요. 혹시나 하고 169.254.169.25로 요청하면 여전히 안됩니다. 여전히 metadata 요청 패킷은 저 멀리 안드로메다로 가고 있습니다.

host routing...

안드로메다로 가는 메타데이터 트래픽을 10.10.100.3으로 보내기 위해서는, l3-agent에서 하는 방법으로는 gateway에서 다른 호스트로 redirect하는 방법이 있습니다. 근데 provider router는 phisycal router를 사용하므로, 거기의 routing table을 OpenStack이 수정할 수 없습니다. 만일 수정할 수 있다고 해도, provider network이 만들어 질 때마다, routing table 추가 작업을 요청해야하기 때문에 그리 좋은 방법은 아닙니다. 물론 OpenStack Agent가 하는 기능을 뚝딱 만들면 되겠지만요.

OpenStack way로 해결하는 방법은 subnet을 생성할 때 host-route 옵션을 주는 것입니다.

$ quantum subnet-create --host-route \
    destination=169.254.0.0/16,nexthop=10.10.100.3 pub100 10.10.100/24

또는 기존의 subnet을 업데이트 하려면... 쬐끔 복잡하게..

$ quantum subnet-update  \
    --host-routes type=dict list=true destination=169.254.0.0/16,nexthop=10.10.100.3

이렇게하면, 인스턴스가 dhcp에서 정보를 가져올 때 routing table까지 가져오므로 instance의 routing table에 의해서 meta-data에 접근이 가능합니다.

cirros bug

그런데 cirros에서 routing table을 dhcp에서 요청하지 않기 때문에 동작하지 않습니다.

cirros의 경우는 부팅 후 routing table을 직접 수정하여 확인하세요.

$ route add -net 169.254.0.0 netmask 255.255.0.0 gw 10.10.100.3 dev eth0

ubuntu cloud 이미지는 아주 잘 동작합니다. 다만 꺼림직하게 인스턴스 routing table이 하나 추가된다는 것 빼구요. 이거 없애려면, 위에서 언급했던, physical router에서 routing table을 추가하면 됩니다.

CentOS 5.x의 문제

CentOS 5.8에서도 dhclient가 static routing을 요청하지 않아서 문제가 발생합니다. 이 경우는 http://jcape.name/2009/07/17/distributing-static-routes-with-dhcp/ 를 참고하세요.

dhcp-agent의 ip address고정...

이렇게 해서 pub100 네트워크는 잘 되었고, pub101에서 하다보면 뭔가 다른 것을 발견하게 됩니다.

pub100에서의 dhcp-agent가 동작하는 port의 ip address는 10.10.100.3인 반면에 pub101에서는 10.10.101.2으로 할당됩니다. 당연히 인스턴스의 ip address도 10.10.100.2, 10.10.101.3으로 서로 다릅니다. 아마도 인스턴스를 생성하고, dhcp-agent의 포트를 생성하는 순서의 문제인 것 같은데, subnet 생성 후에 dhcp-agent의 포트를 강제로 만들어 주면 되겠습니다.

$ quantum dhcp-agent-network-add <agent_id> <network_id>

결론

  • provider network은 SPoF인 l3-agent을 사용하기 않습니다.
  • 모든 네트워크가 physical network으로 구현되어, 기존의 네트워크 인프라에서 운영될 수 있습니다.
  • private network을 사용하기 않기 때문에, 기존 데이터 센터의 인프라와 자연스럽게 통합됩니다.

이를 종합하면, 기존 데이터센터와 통합해야할 필요가 있는 환경에서는 Provider Network이 가장 맞는 선택인 것 같습니다.


auth.log가 quantum agent가 수행하는 sudo 로그로 꽉 찼어요..

어제 시스템 팀에서 연락이 왔습니다. /var/log/auth.log에 아래처럼 지속적으로 quantum-agent가 남기는 로그가 남는다구요.

Jun 23 06:33:26 network sudo: pam_unix(sudo:session): session opened for user root by (uid=106)
Jun 23 06:33:26 network sudo: pam_unix(sudo:session): session closed for user root
Jun 23 06:33:26 network sudo: pam_unix(sudo:session): session closed for user root
Jun 23 06:33:26 network sudo: quantum : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/bin/quantum-rootwrap /etc/quantum/rootwrap.conf ovs-vsctl --timeout=2 get Interface tapae222d3c-61 external_ids
Jun 23 06:33:26 network sudo: pam_unix(sudo:session): session opened for user root by (uid=106)
Jun 23 06:33:26 network sudo: quantum : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/bin/quantum-rootwrap /etc/quantum/rootwrap.conf ovs-vsctl --timeout=2 get Interface tapae222d3c-61 external_ids

음.. 그렇군 하면서 보니까 /var/log/auth.log에는 로그가 정신없이 쌓이고 있군요. 한 호스트에 일주일에 쌓인 로그가 약 500M 정도입니다. 한 호스트에 이정도이니 다른 quantum-agent가 동작중인 network, compute 노드를 합치면.. 헐... 이 녀석을 처리하기로 했습니다. 당연히 모든 sudo의 로그를 날릴 수 없고, quantum agent가 날리는 sudo 명령만 없에기로 했습니다.

/var/log/auth.log는 어디서 생기느냐.. 당연히 아시겠지만 syslog가가 auth,authpriv.*인 내용만 골라서 분리한 내용입니다. Ubuntu의 경우는 rsyslog를 사용하기 때문에 /etc/rsyslog.d/50-default.conf에 정의되어 있지요.

auth,authpriv.*                 /var/log/auth.log

즉... 어디선가 syslog로 날리는 저 내용을 없애면 되는 것이죠.

로그 내용을 보면

  1. sudo에서 이용하는 pam의 세션이 열리고 닫혔다.
  2. sudo로 수행하는 명령은 어떤 것이다.

입니다. 첫번째 로그와 두번째 로그를 날리는 주체는 다릅니다. 첫번째는 pam.d, 두번째는 sudo...

두번째는 간단합니다. /etc/sudoers.d/quantum_sudoers에서 아래 라인을 추가하면 됩니다.

Defaults        logfile=/var/log/sudo.log
Defaults        !syslog

내용 보면 간단하죠? syslog로 로그를 남기지 않고 /var/log/sudo.log로 남깁니다. 그래서 /var/log/authl.log에 로그가 가지 않습니다.

여기까지 하고 /var/log/auth.log를 보면 여전히 세션이 열리고 닫힌 기록이 계속 남습니다. 이는 pam.d에서 해 줘야하는 것이죠. 그래서 /etc/pam.d/sudo를 보면

@include common-auth
@include common-account
@include common-session-noninteractive

이렇게 나와있습니다. 세션에 관련딘 내용은 세번째 줄 같죠? 맞습니다. 조금 긴 내용이 나옵니다. 여기서 잠깐 위의 로그 파일을 자세히 보면 ...

Jun 23 06:33:26 lion034 sudo: pam_unix(sudo:session): session closed for user root

뭔가 보이나요? 그렇죠.. pam_unix라는 곳에서 로그를 남기고 있다고 친절하게 알려주고 있습니다. 다시 pam_unix 관련된 라인이 있는지 찾아보면

session required        pam_unix.so

라고 친절히 있습니다. 그렇습니다.. 여기서 뭔가 해줘야 하겠는데.. 어떤게 있을까 하고 뒤져보니깐... 방법이 아주 간단히  있더군요.

session [success=1 default=ignore] pam_succeed_if.so service in sudo quiet use_uid
session required        pam_unix.so

자세한 내용은 모르겠고, sudo service에서 성공한 인증은 로그를 무시하라는 이야기 이군요.

자... 여기까지 하면... 그렇게 많이 쌓이던 로그가 갑자기 없어지는 신기한 경험을 합니다~~ ㅎ~

그리고 마지막으로 quantum sudo log를 /var/log/sudo.log로 보낸 것 기억하시죠? 이것까지 마무리 하면 되겠습니다.

/etc/logrotate.d/sudo:

/var/log/sudo.log {
    daily
    missingok                                                                           
    compress
    delaycompress
    notifempty
}

추가) 이런 방법 말고 rsyslog에서 필터링 하는 방법도 있군요. /etc/rsyslog.d/50-default.conf의 시작 부분에 다음을 추가합니다.

:msg, contains, "uid=106"
& ~

:msg, contains, "ovs-vsctl"
& ~

참고:


Quantum: multiple l3-agent

grizzly에는 multiple quantum agent가 된다는 정보가 있습니다.

l3-agent가 돌아가는 곳은 모든 네트워크 트래픽이 통과하기에 SPoF의 문제를 해결해야하는데, multiple quantum agent가 된다면 하나의 agent가 문제가 생겼을 경우 다른 agent로 traffic을 전달하여 failover를 수행할 수 있기에 테스트 해 봤습니다.

단순하게 기존의 network 노드와 똑같이 하나 더 network 노드를 추가한 후에 상황은 다음과 같습니다.

root@control:~# quantum agent-list
+--------------------------------------+--------------------+-----------------+-------+----------------+
| id                                   | agent_type         | host            | alive | admin_state_up |
+--------------------------------------+--------------------+-----------------+-------+----------------+
| 0665ee95-55b4-4f7a-a647-e1cf75c019b3 | Open vSwitch agent | network02.stack | :-)   | True           |
| 3d324ac7-a900-4ee9-b97a-df43a30a14e2 | Open vSwitch agent | network.stack   | :-)   | True           |
| 405275c2-48e2-43e4-9853-ce314976dc61 | DHCP agent         | network02.stack | :-)   | True           |
| 6d47b5ce-9d07-4fdb-ad2d-239123ad4087 | L3 agent           | network02.stack | :-)   | True           |
| 91b431b0-ece9-4fbb-a0b9-757c22034ffc | Open vSwitch agent | compute01.stack | :-)   | True           |
| a4887a55-6baf-43ad-a0fa-fd67a07181f2 | DHCP agent         | network.stack   | :-)   | True           |
| da17342b-d2cb-494a-9cf9-5a264b814dde | L3 agent           | network.stack   | :-)   | True           |
| f6d3146a-7a9e-4483-8cbd-c76ef1c76081 | Open vSwitch agent | compute02.stack | :-)   | True           |
+--------------------------------------+--------------------+-----------------+-------+----------------+

여기서 보면 network.stack과 network02.stack에 같은 쌍의 quantum agent가 동작하고 있습니다.

root@control:~# quantum l3-agent-list-hosting-router router_admin_ext
+--------------------------------------+---------------+----------------+-------+
| id                                   | host          | admin_state_up | alive |
+--------------------------------------+---------------+----------------+-------+
| da17342b-d2cb-494a-9cf9-5a264b814dde | network.stack | True           | :-)   |
+--------------------------------------+---------------+----------------+-------+

다시 확인하면 admin tenant의 router인 router_admin_ext 라우터는 network.stack에서 동작하는 것을 확인할 수 있습니다. 물론 network.stack 노드에서도 아래처럼 l3 agent가 정상적으로 설정되어 있는 것을 확인할 수 있습니다.

root@network:~# ip netns
qrouter-f3fe0c48-3248-4b2d-9f5b-c4a9c5fc01ed
qdhcp-85e58593-f869-4233-9e5f-26e7b63df016
root@network:~# ip netns exec qrouter-f3fe0c48-3248-4b2d-9f5b-c4a9c5fc01ed ip addr
15: qr-8acb1ecd-d0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
    link/ether fa:16:3e:74:31:5d brd ff:ff:ff:ff:ff:ff
    inet 10.250.0.1/24 brd 10.250.0.255 scope global qr-8acb1ecd-d0
    inet6 fe80::f816:3eff:fe74:315d/64 scope link 
       valid_lft forever preferred_lft forever
16: qg-a364f00b-f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
    link/ether fa:16:3e:5e:80:f9 brd ff:ff:ff:ff:ff:ff
    inet 10.200.0.2/16 brd 10.200.255.255 scope global qg-a364f00b-f1
    inet6 fe80::f816:3eff:fe5e:80f9/64 scope link 
       valid_lft forever preferred_lft forever
17: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever

이제 이 router를 network02.stack으로 옮겨보죠. 옮기는 것도 자동으로 되면 좋겠는데, 아직 그러한 기능은 없는 것으로 보이며 l3-agent-router-remove, l3-agent-router-add 명령을 이용해서 옮기면 됩니다.

root@control:~# quantum l3-agent-router-remove da17342b-d2cb-494a-9cf9-5a264b814dde router_admin_ext
Removed Router router_admin_ext to L3 agent

이렇게 하면 network.stack에서 동작하는 l3-agent에서 router_admin_ext를 제외합니다. 이 명령을 내린 후에 network.stack 노드에서 해당 namespace를 확인하면 ip address 설정들이 모두 삭제되어 있습니다.

이제 network02.stack l3-agent에 router_admin_ext를 할당하면 됩니다.

root@control:~# quantum l3-agent-router-add 6d47b5ce-9d07-4fdb-ad2d-239123ad4087 router_admin_ext
Added router router_admin_ext to L3 agent
root@control:~# quantum l3-agent-list-hosting-router router_admin_ext
+--------------------------------------+-----------------+----------------+-------+
| id                                   | host            | admin_state_up | alive |
+--------------------------------------+-----------------+----------------+-------+
| 6d47b5ce-9d07-4fdb-ad2d-239123ad4087 | network02.stack | True           | :-)   |
+--------------------------------------+-----------------+----------------+-------+

이렇게 하면 옮겨지는 네트워크 노드인 network02.stack에 router에 해당하는 network namespace가 생기고, 그리고 여기에 l3-agent가 동작할 수 있는 설정이 생깁니다.

root@network02:~# ip netns
qrouter-f3fe0c48-3248-4b2d-9f5b-c4a9c5fc01ed
root@network02:~# ip netns exec qrouter-f3fe0c48-3248-4b2d-9f5b-c4a9c5fc01ed ip addr
12: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
13: qr-8acb1ecd-d0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
    link/ether fa:16:3e:74:31:5d brd ff:ff:ff:ff:ff:ff
    inet 10.250.0.1/24 brd 10.250.0.255 scope global qr-8acb1ecd-d0
    inet6 fe80::f816:3eff:fe74:315d/64 scope link 
       valid_lft forever preferred_lft forever
14: qg-a364f00b-f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
    link/ether fa:16:3e:5e:80:f9 brd ff:ff:ff:ff:ff:ff
    inet 10.200.0.2/16 brd 10.200.255.255 scope global qg-a364f00b-f1
    inet6 fe80::f816:3eff:fe5e:80f9/64 scope link 
       valid_lft forever preferred_lft forever

이상으로 multiple quantum agent의 간단한 기능을 확인해 봤습니다. 이 기능을 보면서 자동 failover/ load balancing 등의 기능이 있으면 좋겠구나 했지만 그런 기능은 아쉽지만 없네요. 하지만 간단한 작업으로 손쉽게 추가할 수 있을 것으로 보입니다.

update) 이를 자동화한 스크립트


Quantum: ping은 되는데 인터넷이 안된다.

OpenStack 네트워크를 OpenVSwitch, GRE tunneling으로 구성하였을 경우에, 인스턴스에서 외부로 ping은 나가나 인터넷이 원할하지 않는 현상을 보일 때가 있습니다. 아주 일반적이지 않는 경우죠.

ping이 아주 잘 되고, dns lookup까지 아주 잘되면 일반적으로 인터넷이 잘된다고 할 수 있으나,

$ curl google.com      # ---- [1]
$ curl www.google.com  # ---- [2]

[1] 번의 경우에는 잘 되고, [2]번은 안되는 경우가 발생합니다.

이 것은 gre tunneling의 특성때문에 발생하는 것으로 CISCO의  Why Can't I Browse the Internet when Using a GRE Tunnel?에 아주 자세히 설명이 나와있습니다.

간단히 요약하면 gre tunneling을 하려면 packet을 gre header를 포함하여 encapsuling하게 되는데, 이 때문에 tcp/ip 패킷에 한번에 담을 수 있는 사이즈는 1500(기본 MTU) - 24(GRE Header) = 1476이 됩니다. 그런데 gre tunneling 외부(L3 agent)에서 부터는 mtu가 1500이므로 상대방 웹 서버에서는 mtu인 1500으로 보내주는데, gre tunneling 안에서는 이를 분리하여 보낼 수 없으므로 최대 패킷 크기 mtu(SMSS)를 조정하는 ICMP를 호출합니다. 여기서 ICMP로 mtu 조절하는 명령이 막히면 서로 mtu 조절에 실패하여 통신이 막히는 것으로 보이는 것이죠..

위의 경우를 보면 [1]은 전송되는 데이터가 작아서 packet 한번에 전송됩니다. 그래서 SMSS를 조절할 필요가  없는데, [2]의 경우는 패킷이 커서 SMSS를 조절할 필요가 있는데, 여기서 막히는 것입니다.

이를 해결하는 간단한 방법은 인스턴스 인터페이스의 mtu를 적당히 조절하면 됩니다. 저의 경우는 1454로 조절하면 되더군요. 그리고 이를 모든 인스턴스에 적용하게 하려면 quantum-dhcp-agent의 옵션으로 두면 되겠습니다.

그리고 production에 간다면, 당연히 인스턴스의 mtu를 조절하는 방법은 이상하고, gre tunneling이 사용하는 switch, interface의 mtu를 1524 이상으로 조절하는 것이 좋겠습니다.


도데체 내 floatingip-list는 뭔고? + field_specs 사용법

quantum은 nova와는 다르게 사용자를 구별하지 않습니다. 아직 keystone의 인증 기능이 완전하게 통합되지 않는 것이죠. 아마도 grizzly에서 해결할 것 같습니다.

그런데 지금 너무 불편합니다. quantum floatingip-list하면 내가 할당받은 floatingip-list만 나와도 정신없는데, 다른 tenant의 것까지 나온다면 더욱 더 정신없습니다. nova처럼 내것만 나오면 좋을텐데 말입니다.

목마른 사람이 우물판다고 간단하게 스크립트 만들어 봤습니다.

#!/bin/bash
TENANT_ID=$(keystone tenant-list | grep " $OS_TENANT_NAME " | awk '{print $2}')
ARG=$@

if [ ! -z "$TENANT_ID" ]; then
        EXTARG=--tenant_id=${TENANT_ID}

        if [[ ! "$ARG" =~ ' -- ' ]]; then
                EXTARG="-- $EXTARG"
        fi
fi

quantum $ARG $EXTARG

사용법은 q.sh로 저장하시고 quantum 명령과 동일하게 쓰면 됩니다. 이제 q.sh로 실행하면 quantum의 대부분의 query 명령이 내가 속한 tenant의 것만 나옵니다. 이제 눈이 좀 정갈해 지는군요.

quantum의 help를 아무리 뒤져봐도 특정 tenant의 목록을 가져오는 것은 없습니다. 유일하게 힌트가 보이는 것 이라고는 filter_specs가 있는데, 여기 키와 값에 뭘 넣어야할지 막막하기도 합니다. 녜 quantum은 이제 folsom 버전에 들어가서 아직 부족한 부분이 많아서 그렇습니다. 당연 문서도 부족합니다(cinder도 아마 그렇지요).

filter_specs에 넣을 수 있는 값들은 리스트된 객체를 show 했을때 보이는 값입니다.

root@:~# quantum net-list
+--------------------------------------+---------+--------------------------------------+
| id                                   | name    | subnets                              |
+--------------------------------------+---------+--------------------------------------+
| 0ded8d5c-9820-4e90-8ca8-97e4a072b2e1 | demo2   | 5d21c90d-7640-4de4-bed7-ce27421851d3 |
| 791d5c88-c437-4f82-97f0-ce435acb2172 | ext_net | c9f2a3cf-2013-4452-b3f5-c778143cc87f |
| d4950d6e-d796-4e30-9fba-d33599ba3644 | admin   | 304f2b2b-6e8f-403c-96b6-0b292007685d |
| e8d18114-540d-4c5e-b2a9-32e4a2e29625 | demo1   | 67b07eb0-235b-4dc4-843c-81e41247e737 |
+--------------------------------------+---------+--------------------------------------+
root@:~# quantum net-show ext_net
+---------------------------+--------------------------------------+
| Field                     | Value                                |
+---------------------------+--------------------------------------+
| admin_state_up            | True                                 |
| id                        | 791d5c88-c437-4f82-97f0-ce435acb2172 |
| name                      | ext_net                              |
| provider:network_type     | gre                                  |
| provider:physical_network |                                      |
| provider:segmentation_id  | 1                                    |
| router:external           | True                                 |
| shared                    | False                                |
| status                    | ACTIVE                               |
| subnets                   | c9f2a3cf-2013-4452-b3f5-c778143cc87f |
| tenant_id                 | e949c418d49649c39005d6dfa7d3ade2     |
+---------------------------+--------------------------------------+

이라고 했을때 여기서 ext_net을 찾는 방법은 아래와 같습니다.

root@:~# quantum net-list -- --name=ext_net
+--------------------------------------+---------+--------------------------------------+
| id                                   | name    | subnets                              |
+--------------------------------------+---------+--------------------------------------+
| 791d5c88-c437-4f82-97f0-ce435acb2172 | ext_net | c9f2a3cf-2013-4452-b3f5-c778143cc87f |
+--------------------------------------+---------+--------------------------------------+
root@:~# quantum net-list -- --router:external=True
+--------------------------------------+---------+--------------------------------------+
| id                                   | name    | subnets                              |
+--------------------------------------+---------+--------------------------------------+
| 791d5c88-c437-4f82-97f0-ce435acb2172 | ext_net | c9f2a3cf-2013-4452-b3f5-c778143cc87f |
+--------------------------------------+---------+--------------------------------------+

하지만.. 이게 절대적인 것은 아니고 대부분 이렇다는 것이네요.. ^^;


quantum: metadata overlapping patch 적용기

quantum의 문제중에 하나인 overlapping_ip을 사용할 때 metadata service가 작동하지 않는 문제에 대해서 이전에 언급했었고, 이에 대한 패치가 저번주에 올라왔습니다.

오늘 이를 테스트 해봤는데 대략 잘 동작합니다.

간단한 구조는 다음과 같습니다.

  1. metadata request는 http://169.254.169.254/latest/metadata 형태로 router namespace로 들어온다.
  2. router namespace의 NAT rule에 의해서 localhost의 port 9697로 redirect 된다.
  3. 9696에서 listen하는 process(quantum-ns-metadata-proxy)는 l3_agent에서 network 생성에 맞춰 관리되며, namespace당 하나씩 생성된다.
  4. quantum-ns-metadata-proxy는 파라미터로 router_id를 가지므로 자신이 담당하는 network을 알 수 있다.
  5. quantum-ns-metadata-proxy는 nova-metadata-agent가 필요한 정보를 모아서(instance-id, router-id, network-id) http header에 포함하여 quantum-metadata-agent로 proxy request를 보낸다.
  6. quantum-metadata-agent는 ns-metadata-proxy에서 넘어온 전보를 바탕으로 instance-id를 확인하고 이를 http header에 포함하여 nova-metadata-api에 보낸다.
  7. nova-metadata-api는 X-Instace-ID가 있으면 이 아이디를 기준으로 메타데이터를 넘긴다.

대략 순서를 정리하면 이렇습니다. 마지막으로 quantum-metadata-agent를 upstart service로 등록하여 작업하는 것 까지하면 대략 쓸만할 것 같습니다.

지금은 우선 테스트라 quantum-metadata-agent가 같은 서버로 들어갔지만, metadata_ip를 줄 수 있으므로 별도의 서버에 운영할 수 있겠습니다.

삽질기

위 패치는 nova/ quantum 2개로 구성이 되어있으며, 당연히도 master 소스를 기준으로 작성이 되어있습니다. 그런데 저는 테스트 환경을 ubuntu folsom cloud archive를 사용하기 때문에 folsom 용으로 만들어야 했지요.. git에서 작업하기 위해 몇 가지 삽질을..

  1. master에 patch 적용하고 patch
  2. stable/folsom 기준으로 branch를 하나 만들고...
  3. master의 commit를 cherry picking...
  4. 다시 folsom에 맞게 소스 수정하고 commit...
  5. folsom과 변경된 부분으로 patch 생성...
물론 nova/ quantum도 같이요...
  • upstart-job service 등록

Side effect?

이전에 metadata 접속 방식은 l3 router namespace에서 metadata api로 요청하는 것이었습니다. 이 경우 l3 router namespace 부터는 public ip address이므로 결국 metadata api server의 주소도 public ip address를 가지게 됩니다.

그런데 이 metadata api server는 굳이 외부에서 접속할 필요가 없으므로 public ip를 가질 필요가 없습니다. 따라서 뭔가 꺼림직 했었는데, 이번 패치를 적용하면, quantum-metadata-agent를 내부망에서 운영할 수 있으므로 metadata api server가 내부망에서 운영이 가능합니다.


OpenStack: 가상머신의 네트워크가 안될 때 quantum의 체크 사항들

[toc]openstack에서 가상머신을 생성하기는 했는데, nova에서는 생성이 되었다고 리포트되지만 Quantum 네트워크 문제로 가상머신이 연결되지 않은 경우가 있다. 이러한 경우 몇가지 체크할 포인트를 정리해본다. 물론 여기는 모두 folsom에서 OpenVSwitch + GRE Tunneling을 사용할 경우를 가정한다.

증상들

quantum의 설정 문제라면 보통 아래의 증상이 나타난다.

  • nova list를 보면 가상머신에 ip는 할당이 되어 있지만, ping이 가지 않는다.
  • ping은 가는데 ssh 접속이 안된다.
  • vnc로 접속하면 접속은 된다.
nova list에서 가상머신의 ip address가 할당이 되지 않고 생성되는 문제가 있는데, 이는 대부분 quantum의 문제가 아니고 다른 문제였다. 이 경우는 nova-compute의 로그를 확인하면 된다.

physical network 확인

integration bridge가 설정 되어 있는지 확인

모든 l3-agent, dhcp-agent, ovs-plugin-agent가 동작하는 곳에 br-int bridge가 있는지 확인한다. quantum ovs plugin이 동작하기 위해서는 반드시 br-int bridge가 필요하다. agent가 자동으로 만들어 줄 만 한데 안만들어 주고 있다.(반면에 gre tunnel이 사용하는 br-tun은 알아서 만든다.)

이 경우는 quantum 로그 파일에 br-int bridge가 없다는 에러를 내기 때문에 찾아내기 아주 쉽다.

external bridge 확인

l3-agent가 동작하고 있는 곳에 br-ex bridge가 있는지 확인한다. 그리고 br-ex bridge에는 외부와 연결된 interface가 추가되어 있는지 확인한다.

테스트 환경에서의 bridge를 확인하면 아래와 같다. (qg-*는 tenant network의 gateway port다.)

    Bridge br-ex
        Port "qg-5376a58a-a7"
            Interface "qg-5376a58a-a7"
                type: internal
        Port "qg-8be78718-4b"
            Interface "qg-8be78718-4b"
                type: internal
        Port "eth2"
            Interface "eth2"
        Port br-ex
            Interface br-ex
                type: internal

그리고 여기에 연결된 eth2(external nic)에는 ip address가 설정하지 않는다.(물리적 연결을 확인하기 위해서 ip를 추가하고 테스트하기는 한다.)

datapath-dkms

openvswitch는 dynamic kernel module support를 사용한다. openvswitch-switch user space daemon과 커널 모듈이 동시에 사용되는 것이다. 의존성에 의해서 자동으로 설치되기는 하지만, 어떠한 경우에는 커널 모듈을 설치하지 않는 경우도 있기 때문에 한 번 쯤은 확인하는 것이 좋다.

root@net-l3:~# dpkg -l | grep datapath-dkms
ii  openvswitch-datapath-dkms        1.4.0-1ubuntu1.3             Open vSwitch datapath module source - DKMS version
root@net-l3:~# dkms status
openvswitch, 1.4.0, 3.2.0-33-generic, x86_64: installed

quantum-plugin-openvswitch-agent 동작 확인

nova-compute, quantum-l3-agent, quantum-dhcp-agent가 동작하는 노드에서는 quantum-plugin-openvswitch-agent가 동작하면서 지속적으로 quantum 서비스를 polling하면서 openvswitch의 설정들을 잡는다. database/ rabbitmq connection이나 keystone 설정들의 문제는 로그파일을 보면 바로 나오니 문제를 파악하기 쉽다. 하지만 gre tunneling을 맺는 것을 명시적으로 오류가 나지 않으므로 이 부분을 확인해야한다.

아래는 테스트 환경에서 gre tunneling 확인한 모습이다. remote_ip="10.130.1.101" 처럼 보이는 부분이 있어야하며, 기타 여러 다른 문제로 인해서 여기에 상대방의 ip가 정상적으로 나오지 않는 경우를 많이 경험했다.

root@net-dhcp:~# ovs-vsctl show
40a579fe-a5ae-4f63-b6ca-6967280a9893
    Bridge br-tun
        Port "gre-1"
            Interface "gre-1"
                type: gre
                options: {in_key=flow, out_key=flow, remote_ip="10.130.1.101"}
        Port patch-int
            Interface patch-int
                type: patch
                options: {peer=patch-tun}
        Port br-tun
            Interface br-tun
                type: internal
        Port "gre-4"
            Interface "gre-4"
                type: gre
                options: {in_key=flow, out_key=flow, remote_ip="10.130.1.11"}
        Port "gre-3"
            Interface "gre-3"
                type: gre
                options: {in_key=flow, out_key=flow, remote_ip="10.130.1.10"}
    Bridge br-int
        Port patch-tun
            Interface patch-tun
                type: patch
                options: {peer=patch-int}
        Port br-int
            Interface br-int
                type: internal
        Port "tap9dd6bf73-9a"
            tag: 2
            Interface "tap9dd6bf73-9a"
                type: internal
        Port "tap063f59a8-7b"
            tag: 1
            Interface "tap063f59a8-7b"
                type: internal
    ovs_version: "1.4.0+build0"

이런 문제가 있는 경우는 remote_ip가 나오지 않는 호스트의 ovs_quantum_plugin.ini의 local_ip 설정이 있는지 확인하고, 정확하게 gre tunneling으로 사용할 ip가 명시되어 있다면 단순히 quantum-plugin-openvswitch-agent 서비스를 재시작하면 대부분 해결 된다.

dhcp namespace에서 ping이 되는지

dhcp agent가 동작하는 곳에는 dhcp namespace가 생기고 여기에는 해당 네트워크에 동작하는 dhcp 서버가 동작하게 된다. 일만적으로 172.16.1.2처럼 2번의 ip를 가지게 되고 가상머신은 3번 아이피부터 시작한다. 여기는 외부 네트워크 연결과는 상관없이 내부 네트워크만 동작하면 되므로 우선 여기부터 확인한다.

root@net-dhcp:~# ip netns
qdhcp-9cbd5dd0-928a-4808-ae34-4cc2563fa619
qdhcp-55db86bf-7eee-4fac-a928-844218e88a11
root@net-dhcp:~# ip netns exec qdhcp-9cbd5dd0-928a-4808-ae34-4cc2563fa619 ip addr
8: tap9dd6bf73-9a: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether fa:16:3e:eb:c1:b3 brd ff:ff:ff:ff:ff:ff
    inet 172.16.2.2/24 brd 172.16.2.255 scope global tap9dd6bf73-9a
    inet6 fe80::f816:3eff:feeb:c1b3/64 scope link
       valid_lft forever preferred_lft forever
9: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
root@net-dhcp:~# ip netns exec qdhcp-9cbd5dd0-928a-4808-ae34-4cc2563fa619 ping -c 3 172.16.2.5
PING 172.16.2.5 (172.16.2.5) 56(84) bytes of data.
64 bytes from 172.16.2.5: icmp_req=1 ttl=64 time=8.82 ms
64 bytes from 172.16.2.5: icmp_req=2 ttl=64 time=3.98 ms
64 bytes from 172.16.2.5: icmp_req=3 ttl=64 time=2.17 ms

--- 172.16.2.5 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 2.179/4.996/8.823/2.804 ms

가상 머신의 ip로 ping이 간다면 우선 내부 네트워크는 정상적으로 작동한다는 말이다. 더불어 gre tunnel도 정상적으로 잘 된다는 이야기이다.

l3 namespace에서 네트워크 확인

l3 namespace는 해당 네트워크의 gateway가 위치(172.16.1.1)하는 곳이다. 당연히 여기서 네트워크가 문제없이 잘 되어야 외부로 나가는 길이 열리는 것이다.

l3 namespace에서 다음 사항을 확인해본다.

  • instance로의 ping
  • default gateway
root@net-l3:~# ip netns
qrouter-2c901c4d-eeb3-43b0-a84a-30da10fa74d7
qrouter-5fce397a-4e9d-4a42-8139-f7748a0f69b6
root@net-l3:~# ip netns exec qrouter-5fce397a-4e9d-4a42-8139-f7748a0f69b6 ip addr
8: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
9: qr-7b757ca9-3f: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether fa:16:3e:23:36:5b brd ff:ff:ff:ff:ff:ff
    inet 172.16.1.1/24 brd 172.16.1.255 scope global qr-7b757ca9-3f
    inet6 fe80::f816:3eff:fe23:365b/64 scope link
       valid_lft forever preferred_lft forever
10: qg-8be78718-4b: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether fa:16:3e:b7:bc:06 brd ff:ff:ff:ff:ff:ff
    inet 10.100.1.130/25 brd 10.100.1.255 scope global qg-8be78718-4b
    inet 10.100.1.131/32 brd 10.100.1.131 scope global qg-8be78718-4b
    inet6 fe80::f816:3eff:feb7:bc06/64 scope link
       valid_lft forever preferred_lft forever
root@net-l3:~# ip netns exec qrouter-5fce397a-4e9d-4a42-8139-f7748a0f69b6 ping -c 3 172.16.1.3
PING 172.16.1.3 (172.16.1.3) 56(84) bytes of data.
64 bytes from 172.16.1.3: icmp_req=1 ttl=64 time=10.4 ms
64 bytes from 172.16.1.3: icmp_req=2 ttl=64 time=0.563 ms
64 bytes from 172.16.1.3: icmp_req=3 ttl=64 time=0.541 ms

--- 172.16.1.3 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.541/3.851/10.450/4.666 ms
root@net-l3:~# ip netns exec qrouter-5fce397a-4e9d-4a42-8139-f7748a0f69b6 route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         10.100.1.129    0.0.0.0         UG    0      0        0 qg-8be78718-4b
10.100.1.128    *               255.255.255.128 U     0      0        0 qg-8be78718-4b
172.16.1.0      *               255.255.255.0   U     0      0        0 qr-7b757ca9-3f
root@net-l3:~# ip netns exec qrouter-5fce397a-4e9d-4a42-8139-f7748a0f69b6 ping -c 3 10.100.1.129
PING 10.100.1.129 (10.100.1.129) 56(84) bytes of data.
64 bytes from 10.100.1.129: icmp_req=1 ttl=64 time=22.1 ms
64 bytes from 10.100.1.129: icmp_req=2 ttl=64 time=0.423 ms
64 bytes from 10.100.1.129: icmp_req=3 ttl=64 time=0.339 ms

--- 10.100.1.129 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.339/7.622/22.105/10.241 ms

여기서 namespace의 gateway는 quantum을 이용해서 네트워크를 생성할때 만들어준 네트워크에서 알아서 잡는 것이다. 따라서 해당 주소는 미리 있어야한다. 위에서는 external network의 subnet을 10.100.1.128/25로 주었기 때문에 해당 네트워크의 첫번째 아이피인 10.100.1.129로 gateway가 자동으로 잡혔다.

또한 10.100.1.130은 해당 네트워크의 nat로 외부 접속할 대표 아이피이고 10.100.1.131은 floatingip로 설정된 것이다.

metadata

어쨌든 가상 머신으로 ping까지 잘 가지만 ssh로 로그인할 수 없는 경우가 있다. 이런 경우는 대부분 가상머신이 metadata를 가져오지 못해서 생기는 문제로 가상머신의 로그나 vnc로 접근해서 확인하면 확인할 수 있다.

ubuntu 가상 머신의 경우는 아래와 같은 메시지가 남는다.

root@c-01-01:~# tail /var/lib/nova/instances/instance-00000003/console.log
cloud-init start-local running: Thu, 22 Nov 2012 15:07:50 +0000. up 3.37 seconds
no instance data found in start-local
ci-info: lo    : 1 127.0.0.1       255.0.0.0       .
ci-info: eth0  : 1 172.16.2.4      255.255.255.0   fa:16:3e:78:fa:03^M
ci-info: route-0: 0.0.0.0         172.16.2.1      0.0.0.0         eth0   UG
ci-info: route-1: 172.16.2.0      0.0.0.0         255.255.255.0   eth0   U
cloud-init start running: Thu, 22 Nov 2012 15:07:54 +0000. up 7.01 seconds
2012-11-22 15:08:48,306 - util.py[WARNING]: 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [51/120s]: url error [timed out]
2012-11-22 15:09:39,360 - util.py[WARNING]: 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [102/120s]: url error [timed out]
2012-11-22 15:09:56,379 - util.py[WARNING]: 'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [119/120s]: url error [timed out]

로그를 보면 dhcp를 통해서 ip를 받아왔지만 cloud-init에서 metadata server롤 접속하지 못해서 ssh key를 받아오지 못해 ssh 인증키를 가상머신에 설치하지 못해서 이다. 이 문제에 관해서는 이전에 적었으니 참고하시면 되고, 간단하게 말한다면 l3 agent namespace에서도 metadata server에 접속할 수 있어야되고, 반대로 metadata server에서도 가상 머신에 접속할 수 있어야 합니다. management / data / external / tenant network을 모두 같은 네트워크에서 구성했다면 문제가 안생기겠지만, 별도의 분리된 네트워크나 private network을 사용했다면 직접 연결되는 경로가 없기 때문에 만들어 줘야 합니다.

간단하게 한다면 metadata api server에서 아래처럼 하면 됩니다.

root@api $ route add -net <tenant subnet> gw <tenant default public ip>;
root@api $ route add -net 172.16.1.0/24 gw 10.100.1.130

참고로 metadata_ip는 external network에서 접근 가능한 ip여야 합니다. metadata server를 접근하는 곳이 l3 namespace인데 여기는 이미 external network 영역이기 때문입니다. 여기서 management나 기타 다른 영역으로 들어가는 것은 구성상 바람직 하지 않습니다.

기타 다른 이유들...

  • keystone
    • 설정 오류
    • quantum user의 권한 문제: quantum user는 admin role이 있어야 한다.
  • glance 이미지 설정 오류
    • glance의 설정이 잘못되어 있으면 가상 머신의 상태가 build에서 멈춰있습니다. nova-compute 쪽 로그를 보면 이미지를 찾을 수 없다고 나옵니다.
    • glace 이미지 오류: glance에서 이미지를 추가할 때 뭔가 잘못하여 active가 아닌 queued 상태인 이미지가 만들어 질 수 있는데, 이 이미지로 가상머신을 만들면 역시 build 상태에서 멈춰 있습니다.
  • quantum-service startup error
  • 가끔 nova-network을 설치해놓고선 quantum service가 왜 안뜨냐고 투덜인 분이 있습니다. 녜.... quantum은 nova-network을 완전해 대체할 목적으로 만들어 졌기에 같이 공존할 수 없습니다. nova-volume과 cinder와의 관계와 같습니다.  /etc/nova/nova.conf에 enabled_apis=ec2,osapi_compute,metadata 처럼 몇몇 서비스를 내리세욧

.....

quantum은 openstack의 마지막에 있습니다. 무슨 말이냐 keystone, glance, nova-* 등 여러 openstack 요소들이 동작을 제대로 한 이후에 quantum의 동작을 확인할 수 있습니다. 네트워크가 안된다는 것은 단순 네트워크 문제로 보이지만 다른 여러 요인들이 겹쳐서 생기는 문제가 더 많습니다. 경험상 정작 quantum 자체의 문제보다는 다른쪽의 문제가 더 많았습니다.

감이 오시나요? quantum을 하려면 다른 것도 어느 정도 대충 알아야한다는 이야기입니다. 그러지 않고서는 quantum은 문제 없어!! 라고 끝내버리는 경우가 생길 수 있는데, 이건 팀워크에서는 하면 안되는 것이죠.. 음.. 이상한..

어쨌든 끝~


metadata_overlapping_networks에 대한 패치가 올라와 벼렸군

일전에 지금의 Quantum 구현에 overlapping networks에서 metadata를 가져오는 문제가 있고, 이에 대한 해결책에 대해서 이야기한 적이 있었죠. 시간내서 이 것을 제대로 정리해서 패치를 보낼 생각이었는데... 허걱 오늘 Dream Host에서 이 문제에 대한 패치를 보냈군요.

기본 구현을 보면 기본적인 아이디어는 제 아이디어와 비슷합니다. 역시나 namespace에서 agent를 router_id, network_id를 가지고 있는 agent를 띄우고, 다시 agent가 proxy 역할을 해서 실제 metadata로 proxy 형태로 request를 보내는 겁니다.

소스를 보니 깔끔하군요. 지금 적용해도 큰 무리는 없겠습니다. 다음주에 시도해봐야 겠습니다.

역시.. 빨리 했어야 하는건데. ㅡㅡ;


  • Copyright © 1996-2010 Your wish is my command. All rights reserved.
    iDream theme by Templates Next | Powered by WordPress