태그 보관물: neutron

juno의 새기능 : L3-HA

juno가 나온지 꽤 되었다.

juno에 여러가지 기능이 추가되었지만, 우리(나?)에게 제일 필요한 기능이 바로 L3-agent의 HA였기 때문에,

L3-HA와 DVR에 대해 소개하려고 한다.

업무적인 여러가지 이유로 L3-HA와 DVR을 한달여 가까이 공부하였는데, 각각의 장단점을 가지고 있었다.

그중 L3-agent HA에 대해 설명해보고자 한다.

 

L3-HA

기존의 네트워크 구조에서는 L3-agent로 모든 패킷이 흐르기 때문에 SPOF가 될 수 밖에 없었다.

또한 L3-agent가 사망시에 별다른 복구 방법이 존재 하지 않았다..

고작 할 수 있는 것은 fail난 노드의 router를 remove를 한 뒤, 정상적인 노드에 router-add를 하는 거 정도?

이 경우에 모든 라우터에 처리가 동시에 되지 않는다고 가정했을 때,

라우터별로 시간차이가 존재할 수 있고, 또한 특별한 스크립트를 만들어 놓지 않는 이상 실시간적으로 대응하기도 힘들었다.

따라서 재수가 없으면 30분이상 장애가 날수도 있는 슬픈… 암튼 그렇다..

그래서 나온것이 L3-agent HA가 되시겄다.

L3-agent HA는 애초에 neutron에서 router를 만들데 스케쥴러에서 여러노드에 동시에 띄워 놓게 한다.

1개의 라우터에 대해 여러개의 백업을 만들어 놓는 다는 의미다.

아래의 그림에서 L3 agent1이 마스터라고 했을때 agent2는 백업이 될 것이다.

L3-ha

이 각각의 라우터 중에서 오직 1개만 active상태로 사용중이 되고  나머지 라우터는 standby 상태가 된다.

위와 같이 모든 라우터의 네임스페이스는 위와 같은 구조로 만들어지게 되는데,

HA라는 장치가 추가로 생성되며,

이 생성된 HA장치들이 서로 keepalived 패킷을 보내어 죽었는지 살았는지 체크한다.

그리고 master(?) 라우터가 응답이 없을 경우, 다음 우선순위 장치가 마스터를 꿰차게 된다.

L3-agent HA는 VRRP를 통해 구현되며,

구현을 하기 위해서는 neutron.conf에 다음과 같은 옵션을 넣어줘야 한다고 한다.

allow_automatic_l3agent_failover = True

이 L3-HA를 사용할 경우 다음과 같은 장단점이 있다.

장점 1. VRRP를 이용해 라우터들이 3-4초 내에 다른 노드로 넘어가게 되어서 장애 시간의 초단축이 예상된다.

장점2. 현재로써는 세션 유지가 되지 않지만 다음 버전인 kilo?에서는 contrackd를 이용해서 세션까지 트랙킹하여 세션까지 유지 가능하게 될 가능성이 높다.

단점1. HA는 가능하지만, 애초에 네트워크 노드에 부하가 집중되는 것은 막을 수 없다.

단점2. 어떤 네트워크에 라우터가 master로 띄워져 있는지 확인이 불가능하다. 물론 방법이야 있겠지만, openstack 내에서 명령어로 확인하는 것은 불가능해보인다.

이 자료는 아래의 내용을 참고하여 만들어 졌으며, 내용중 일부(그림)를 발췌하여 사용하였다.

겁나 자세하게 잘나와 있는 듯~

https://assafmuller.files.wordpress.com/2014/11/l3-ha.pdf

토막상식 : quantum-dhcp-agent 관련

최근 네트워크 이슈가 계속 발생되면서 각 데몬들에 대해 연구하고 있는데…

 

최근 네트워크와 라우터를 새로 만들었는데 , 라우터는 L3-agent와 연결 되었지만 네트워크는 dhcp-agent와 연결이 되지 않는 현상을 발견했다.

 

그래서 장애니 뭐니 반나절을 고생했는데.. 나중에되서 알게된 사실은  “원래 안생긴다.”

 

VM을 만들게되면 그 때 dhcp-agent와 network가 연결되는 것이었다.

 

아휴 멍충이..

 

openstack-lbaas-agent 의 haproxy “maxconn” tuning 방법

hatop으로 haproxy의 상태를 확인해 봤더니 아래처럼 2000개 세션밖에 처리를 못하게 되어 있다.

before

conf파일을 수정해봤자 lbaas-agent가 재시작되면 말짱 도루묵 -_-;;

결론은 lbass가 재시작될 때 적용되는 template을 변경해야 한다는 소리인데…

구글을 통해 알아본 결과, 소스코드를 수정해야 한다고 한다.

https://ask.openstack.org/en/question/37821/is-it-possible-to-increase-maxconn-value-on-haproxy/

그렇다면 낼롬 해보는 것이 인지상정!!!

시도해보겠다.

 

1. 우선 패키지를 찾아낸다.

 

위에 “python-neutron”이 범인이다!

 

2. 저 패키지를 까본다.

 

이번에도 “/usr/lib/python2.7/dist-packages/neutron/services/loadbalancer/drivers/haproxy/cfg.py”이 범인이닷!

 

3. 이제 저 파일을 수정한다. 나는 추가적으로 모니터링을 위해 stats를 enable했다. edit

 

4. 이후 lbaas-agent를 재시작하면 “maxconn 15000″이 똬악!  stat페이지도 똬악!, 끝!

after