neutron openstack networking 정리

# "Neutron 오픈스택 네트워킹" 책에서 중요한 내용을 발췌.

# 책이 발간된지 오래되었지만 동작 매커니즘은 유효함.

루트헬퍼 설정

• 루트헬퍼는 호스트에서 루트 권한을 악용하여 오픈스택 관련 커맨드를 잘못 실행하지 않도록 오픈스택에서 제공하는 보안 매커니즘.
• 오픈스택에서는 뉴트론 관련 커맨드 실행시 root로 직접 실행하지 않고 sudo neutron-rootwrap /etc/neutron/rootwrap.conf <커맨드>를 호출한다
• 호스트에 sudoers 항목으로 추가해두면 오픈스택에서 neutron-rootwrap을 루트로 실행시킬수 있다
• neutron-rootwrap에서는 설정파일에서 필터 정의를 찾아서 커맨드 필터를 로드한다
  요청한 커맨드가 필터에 정의된 커맨드 중에 있다면 이 커맨드를 루트로 실행하고, 매칭되는게 없다면 요청을 거부한다
• 클라우드 규모가 커져가면 neutron-api을 호출하는 커맨드에 대한 처리 속도가 점점 느려질수있다. neutron-rootwrap 커맨드 대신 sudo를 사용하면 보안에 대한 안전성은 떨어지지만 커맨드 실행 속도는 높일 수 있다

neutron dhcp-agent 설정

• use_namespaces : DHCP에 대해 네트워크 네임스페이스의 적용 여부 지정
  • 설정시 qdhcp-로 네임스페이스 생성됨
  • 미설정시 테넌트 간의 네트워크를 중첩시킬 수 없으므로 테넌트 네트워크 구성에 제약이 발생
• enable_isolated_metedata : 방화벽이나 라우터와 같은 물리 디바이스에서 인스턴스에 대한 디폴트 게이트웨이 역할을 수행하면서 뉴트론에서 별도로 인스턴스에 대한 메타데이터 서비스를 제공할 때 유용
  • L3 에이전트를 사용할 경우 인스턴스에서는 디폴트 게이트웨이 역할을 하는 뉴트론 라우터를 통해 메타데이터 서비스를 찾게 된다.
  • isolated 네트워크란 뉴트론 라우터가 게이트웨이 역할을 하지 않고 뉴트론에서 인스턴스의 DHCP 요청을 처리하는 네트워크를 말한다
  • 인스턴스에서 플랫 네트워크나 VLAN을 사용하지만 L3 에이전트는 사용하지 않는 경우가 해당
• enable_metadata_network : L3 에이언트를 사용할 수도 있는 상황에서 메타데이터 에이전트가 라우터와 다른 호스트에 있을 때 설정
  • 서브넷 CIDR 169.254.0.0/16을 포함하는 네트워크를 메타데이터 네트워크로 인식한다
  • 뉴트론 라우터에 연결할때 라우터가 설치된 노드에 메타데이터 프록시도 띄워서 이 라우터에 연결된 모든 네트워크에서 메타 데이터 정보를 얻을 수 있게 한다

neutron metadata-agent 설정

• nova에서는 메타데이터 서비스를 이용해 가상 머신 인스턴스에서 자신의 호스트네임, 공개 키 등과 같은 정보를 가져온다
• 인스턴스는 부팅 과정에서 http://169.254.169.254로 메타데이터 서비스에 접속해 정보를 얻는다
• neutron-metadata-agent는 DHCP나 라우터네임스페이스를 통해 컨트롤러 노드에 있는 openstack-nova-metadata-api(또는 openstack-nova-api) 서비스에게 프록시를 제공한다
• 메타데이터 에이전트는 모든 네트워크마다 neutron-ns-metadata-proxy 프로세스를 띄운다
• 뉴트론에서는 다양한 방식으로 인스턴스에게 메타데이터를 제공하며 뉴트론 라우터를 기반으로 동작한다
• 메타데이터에 대한 동작이 제대로 수행되려면 뉴트론과 노바가 공유 비밀 패스워드로 통신 할수 있도록 설정해야 한다.

neutron의 subnet

• host-route 속성은 DHCP를 통해 주입될 static route 경로를 지정한다
• 서브넷마다 최대로 가질 수 있는 경로의 개수는 디폴트로 20이며 /etc/neutron/neutron.conf에서 다른 값으로 변경할수 있다

# Maximum number of host routes per subnet (integer value)
#max_subnet_host_routes = 20

• DHCP를 미사용으로 변경하면 DHCP를 사용하는 인스턴스는 IP 연결이 끊어짐

인스턴스에서 주소를 얻는 과정

1) DHCP 클라이언트에서 브로드캐스트로 DHCPDISCOVERY 패킷을 보낸다

2) DHCP 서버는 요청에 대한 응답으로 DHCPOFFER 패킷을 보낸다
→요청을 보낸 인스턴스의 MAC, IP, subnet mask, 임대기간, DHCP 서버의 IP가 담겨있다

3) 응답을 받은 DHCP 클라이언트는 다시 DHCPREQUEST 패킷을 DHCP 서버로 보내서 서버에서 제공할 주소를 요청한다. 여러개의 오퍼를 받을수 있지만 단 한개만 수락한다

4) DHCP 서버는 DHCPACK 패킷을 인스턴스에게 보내서 IP 설정이 완료된다

→ nameserver나 route와 같은 다른 DHCP 옵션도 인스턴스에게 보낸다

인스턴스에서 메타데이터 가져오기

1) 라우터 네임스페이스를 통하는것

• 게이트웨이 IP가 뉴트론 라우터에 속한다
• 라우터는 메타데이터 서비스를 포함한 서브넷에서 발행하는 모든 트래픽의 라우팅을 처리한다
• 인스턴스에서 http://169.254.169.254에 있는 메타데이터서비스로 HTTP 요청을 보내면 뉴트론 라우터에서 iptables 체인과 룰을 검사해 라우팅 결정을 한다
• qrouter 네임스페이스에는 HTTP 요청을 9697 포트에 있는 로컬 리스너에게 리다이렉션 하는 PREROUTING 규칙이 지정되어 있다

2) DHCP 네임스페이스를 통하는것

• 인스턴스가 뉴트론 라우터에 연결되지 않은 네트워크에 있다면 인스턴스에서 메타데이터 서비스에 도달하려면 인스턴스에 경로를 직접설정하거나 DHCP를 통해 경로를 제공해야 한다
  • dhcp_agent.ini에서 enable_isolated_metadata가 true 설정되어 있다면 DHCP 네임스페이스마다 메타데이터 서비스에 대한 프록시를 하나씩 제공한다
• 169.254.169.254에 대한 경로를 직접 추가
  • 인스턴스가 169.254.169.254에 있는 DHCP 네임스페이스의 메타데이터 서비스에 접근하려면 next hop에 대한 경로를 인스턴스의 디폴트게이트웨이가 아닌 DHCP 네임스페이스 인터페이스로 설정해야 한다.
  • 예시) ip route add 169.254.169.254/32 via 192.168.204.2
  • 인스턴스마다 매번 경로를 하나씩 추가하는 과정은 번거롭다

---

로드밸런싱

• 풀멤버 : IP + Port
• 풀 : 풀 멤버의 그룹
• 가상IP

로드 밸런싱 알고리즘

• 라운드로빈 (round robin) : 모든 머신에 균등배분하므로 리소스를 가장 적게 사용. 어느 머신이 연결을 처리하기에 버거운지 알아내는 매커니즘은 없으므로 모든 멤버가 동일한 처리 속도와 연결속도, 메모리 용량을 가지도록 구성
• 최소 연결 (least connection) : 현재 처리하는 연결의 수가 가장 적은 서버로 새연결을 전달. 각 서버의 연결 수를 계속 기록하고 있다가 트래픽을 적절히 분산하므로 일종의 동적 알고리즘이다. 처리량이 높은 풀 멤버에서 트래픽을 더 받을 수 있으므로 연결을 좀 빨리 처리할수 있다
• 출발지 (source IP) : 특정한 출발지 IP에서 발생하는 트래픽을 지정된 풀멤버로 전달. 초기에는 라운드로빈으로 동작하면서 할당된 연결 정보를 테이블에 기록해두고 나중에 동일한 IP에 대해 추가로 연결 요청이 들어올때 이 테이블에 기록된 정보를 활용한다. 세션 정보를 로컬 웹서버에 저장하는 온라인 쇼팅 카트와 같이 클라이언트의 모든 요청에 대해 특정한 서버를 사용하게 하려는 애플리케이션에 주로 사용.

세션 지속성

• SOURCE_IP 
  • 클라이언트의 IP를 기반으로 스티키 테이블에 한 항목을 생성하고 그 뒤에 같은 IP에서 들어오는 연결을 동일한 백엔드 풀 멤버로 전달
  • 설정 값에 따라 10,000개의 항목을 스티키 테이블에 담을수 있다
  • 이 방식을 사용하면 여러 클라이언트가 프록시를 통해 서버에 연결을 요청할 경우 로드밸런서가 하나의 클라이언트에서 온것으로 오판해 로드를 제대로 분산하지 못하는 경우가 발생할 수 있다
• stick-table type ip size 10k stick on src
• HTTP_COOKIE 

  cookie SRV insert indirect nocache

• 클라이언트에서 처음 가상 IP로 연결할 때 다음 차례에 있는 풀멤버로 전달
• 클라이언트의 IP 주소에 영향을 받지 않으므로 출발지 IP의 지속성을 보장할 수 있다.
• 이 멤버가 요청에 대한 응답을 보낼때 haproxy에서 SRV라는 쿠키를 응답에 넣어 클라이언트로 보낸다. 이때 집어 넣는 SRV 쿠키 값은 서버의 고유 식별자이다. 나중에 클라이언트에서 동일한 가상 IP에 대한 요청을 보낼때 haproxy에서 요청 헤더에서 쿠키를 꺼내본 다음 여기서 지정하는 풀멤버로 트래픽을 보낸다

• APP_COOKIE

appsession <CookieName> len 56 timeout 3h

• 애플리케이션 쿠키를 백엔드에서 정의하면 haproxy는 서버에서 쿠키를 설정한 시점을 확인하고 이를 테이블에 저장한 다음 서버 식별자와 연결한다
• 이 값으로 사용한 문자중 최대 56자까지 저장된다-쿠키는 세시간이상 사용되지 않으면 자동으로 삭제된다
• 같은 요청이 나중에 또 들어오면 haproxy에서 쿠키를 검색해 발견될 경우에는 이값에 지정된 풀 멤버로 전달하고 그렇지 않으면 로드밸런싱 알고리즘을 적용한다
• 쿠키는 세시간 이상 사용되지 않으면 자동으로 삭제된다

 

네트워트에 로드 밸런싱 적용

• haproxy를 사용하면 로드밸런서는 one-arm 모드로 동작한다
• 로드 밸런서는 하나의 인터페이스로 클라이언트와 풀 멤버 사이에서 오고가는 트래픽을 처리

• 로드밸런서를 통과할때 SNAT 처리를 해줘야 한다
• 뉴트론에서는 haproxy가 풀멤버에게 HTTP X-Forwarded-For 헤더로 보내도록 설정한다
  따라서 풀멤버는 클라이언트의 원래 주소를 볼수 있다
• one-arm 모드대신 routed 모드나 transparent 모드를 사용할 수도 있다
• routed 모드를 사용하면 로드밸런서가 클라이언트와 풀멤버사이에서 게이트웨이이 역할을 한다
  • 이 모드에서는 로드밸런서가 풀멤버의 게이트웨이가 되기에 패킷의 출발지 주소를 변경하지 X
• transparent 모드를 사용하면 로드밸런서가 동일한 서브넷에 설정된 두개의 VLAN 사이의 네트워크 브릿지 역할을 한다
  • 이 모드에서는 풀 멤버에서 게이트웨이를 변결할 필요가 없기 때문에 로드 밸런서를 설치하는 과정에서 네트워크 설정에 영향을 거의 주지 않는다

*원서 집필시 haproxy는 다른 방식 지원 불가능.

헬스모니터 설정

• --deply 상태를 검사하는 주기를 (초) 단위로 지정. 디폴트: 5초
• --max-retries 풀 멤버를 DOWN으로 표시하기 위한 기준이 되는 연속으로 실패하는 회수의 최대값. 디폴트 :3
• --timeout 모니터에서 응답을 기다릴 시간(초). 디폴트 : 16

→ 이값은 풀 멤버가 응답하는데 충분한 시간을 주도록 보통 (delay * max-retries) + 1 로 설정

• --type 속성중 PING은 haproxy에서 제대로 지원하지 않으므로 TCP타입과 똑같이 동작함

---

iptables 소개

#테이블

• Raw : 다른 테이블 보다 먼저 적용되는 디폴트 테이블. 주로 connection 트래킹에 제외될 부분을 설정할때 사용하며
• Filter : 패킷을 필터링 할때 사용하는 디폴트 테이블
• NAT : 네트워크 주소 변환(NAT)에 사용되는 디폴트 테이블
• Mangle : 특수한 패킷 변경에 사용되는 디폴트 테이블로서, 시큐리티 그룹이나 FWaaS에서는 사용하지 않음

#체인

• PREROUTING : 패킷에 대한 라우팅 결정을 내리기 전에 이 체인이 적용된다. 라우터 네임스페이스에서 FloatingIP 처리할때 사용한다
• INPUT : 패킷이 호스트머신에 전달될때 사용
• FORWARD : 라우팅 경로는 결정됐지만 로컬에 전달되지 않는 패킷에 이 체인이 적용
• OUTPUT : 호스트 머신에서 보낸 패킷이 이 체인에 적용
• POSTROUTING : 라우팅 결정이 끝난 패킷이 이 체인에 들어온다. 라우터 네임스페이스에서 Floating IP처리할떄 사용

#동작

• ACCEPT : 해당 패킷을 허용하고 애플리케이션으로 전달
• DROP : 별다른 동작 없이 패킷을 무시
• REJECT : 패킷을 무시하면서 패킷을 보낸 쪽으로 에러 메시지를 보낸다
• LOG : 패킷에 대한 세부 사항을 로그에 남긴다
• DNAT : 패킷의 목적지 IP를 수정한다
• SNAT : 패킷의 출발지 IP를 수정한다
• RETURN : 체인을 호출한 곳으로 리턴한다