Archive for May, 2013

OpenStack havana에 기대하는 몇가지…

요즘 grizzly 버전가지고 열심히 놀구 있습니다. 써보니깐.. private cloud까지는 훌륭히 만들 수 있을 것 같아요..

그러다 havana 릴리스에 어떤 blue print가 있는가 대충 훑어봤는데, 그중에 몇 개 이야기 해봅니다.

Support for Quantum L3 plugin in Devstack

l3 agent는 linux box에서 돌아가도록 되어있습니다. plugin 형태로 구축하면 hardware 장비를 조절하여 l3의 기능을 처리할 수 있겠죠. 이렇게 하면 l3 agent host에 부하가 줄어들어 보다 안정적인 서비스를 할 수 있습니다.

게다가 인프라 쪽은 s/w 보다는 h/w를 믿는 경향(?)이 있어서, 이게 더 심리적인 안정감을 줄 것 같습니다.

Enable loadbalancing vendors to implement their drivers - step0

이것도 위와 마찬가지로, haproxy로 되어있는 구성을 l4 장비를 이용해서 처리하는 기능이죠.

Dynamic DNS support for instances

aws ec2처럼 dns로 연결하고 싶습니다.

IPSec VPNaaS Python APIs / CRUD Operations

VPN은 public cloud를 한다면 필요한 기능입니다. havana까지는 api가 정리가 될 것 같고, 다음 릴리스에서는 뭔가 사용할 만한 결과물이 나오겠지요. OpenVPN을 이용한 client vpn, site-to-site vpn이면 훌륭합니다.

nova-network에서는 CloudPipe에서 지원했었지만, 아직 Quantum에는 없네요.

QoS API implementation: OpenVSwitch w/ DSCP

네트워크 서비스에 QoS는 기본이겠죠? 옆에 누군가가 엄청나게 네트워크를 써 버린다면.. ㅎㅎ

Ceilometer

metering입니다. 즉 어느 사용자가 얼마나 사용했는지를 나타냅니다. 효율을 측정하기 위해서는 반드시 필요하겠죠?

grizzly에 들어가긴 했지만, havana에 제대로 들어갈 예정입니다.

Heat

Heat는 CloudFormation 처럼 web site stack을 정의하고, 그에 따라서 API를 이용하여 OpenStack을 설정하는 콤포넌트 입니다. 이 기능보다 제가 주목하고 있는 것은 여기에 AutoScaling 기능이 들어간다는 점이죠.

역시 주 관심사가 Quantum이라 네트워크가 대부분이군요. ^^


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) 이를 자동화한 스크립트


kvm 인스턴스 생성 스크립트

  • kvm, virsh로 인스턴스 생성
  • 메모리, 디스크 크기, 연결 bridge 설정 가능
  • qcow2 이미지 포멧


moinmoin에 지속적으로 계정 생성을 시도하는 ip 차단: 가난한 자의 ddos 방어..

본 서버에 같이 돌아가는 서비스 중에 하나가 moinmoin 입니다. 그냥 혼자 이것저것 정리한 내용들을 두서없이 적는데...

어떤 녀석들이 여기에다가 지속적으로 새로운 계정 생성을 시도하면서 스팸 짓을 합니다. 녜.. 여기 서버는 가상서버에다가 메모리도 1기가로 아주 작아서 이런 요청이 계속 들어오면 apache 프로세스그 많아서서 서버가 엄청 느려집니다.

그래서 해당 ip를 그냥 .htaccess에서 접근차단 하기로 했습니다. 아주 간단하게.~~

이 스크립트를 그냥 crontab에서 돌려 놓으세요~

물론 다른 나이스한 방법이 있겠지만.. 우선 귀찮아서... ^^;


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 이상으로 조절하는 것이 좋겠습니다.


setup NAT on Mac OS X

$ sudo sysctl -w net.inet.ip.forwarding=1
$ sudo natd -interface en0
$ sudo ipfw add divert natd ip from any to any via en0

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