LBaaS개요
Neutron 은 NeutronAPI 통하여 기존 Neutron 기능을 확장 가능한 플리그인 메커니즘을 가지고 있다.
대표적으로 Neutron LBaaS(Load-Balancer-as-a-Service,이하 LBaaS) 는 Load-Balancer 기능을 제공 하며, NeutronAPI 를 통하여 기능을 구현한다.
기본적으로 Load-Balancer 기능은 LBaaS agent 데몬으로 작동 되며 해당 데몬은 haproxy 기반으로 Load-Balancer 기능을 제공 하고 있다.
LBaaS v1 과 LBaaS v2 로 버전이 있으며 LBaaS v1는 openstack 릴리즈 Newton 에서 삭제 되어 지금은 기본적으로 LBaaS v2로 작동한다.
(공식적으로 LBaaS v1 에서 LBaaS v2 의 migration은 불가능)
해당 문서는 LBaaS v2 기준으로 작성 되었다.
LBaaS Concepts
LBaaS 논리적인 Concept 은 아래와 같은 형태로 구성 되어 있다.
Load balancer | load balancer 는 neutron 네트워크 포트를 사용 하여 서브넷에 아이피를 할당한다. |
Listener | Load balancers 는 1개가 아닌 다수의 listener 를 설정 하여 여러 포트에서 대한 요청을 수신 할 수 있다. |
Pool | 풀에는 로드 밸런서를 통해 콘텐츠를 제공하는 멤버 목록이 저장됩니다. |
Member | 멤버는 로드 밸런서 뒤에서 트래픽을 처리하는 서버로. 각 멤버는 트래픽을 서비스하는 데 사용하는 IP주소 및 포트로 지정된다. |
Health monitor | Member는 때때로 오프라인 상태가 될 수 있으며 상태 모니터는 올바르게 응답하지 않는 구성원의 트래픽을 우회시킵니다. 상태 모니터는 풀과 연결됩니다. |
아래 그림과 Load balancer 라는 가상의 Load-Balancer 가 있다면 해당 Load-Balancer 에는 다수의 Listener 를 지정 하여V-port 를 지정 하여
Load-Balancing을 진행 한다.
Listener 에는 특정 pool을 지정 하여 해당 pool 에 있는 member 에게 Load-Balancing을 진행 하며 Health monitor 에 의하여 상태를 체크를 진행 하다가
상태가 이상이 있을 경우 해당 상태이상있는 member로 연결 되지 않도록 한다.(해당 부분은 haproxy로 작동한다)
Create load balancer
아래 처럼 해당 프로젝트에는 web1,web2 라는 프로젝트가 각각 selfservice(private) ip 로 할당 되어 있으며 각각 웹서버 호출시 해당 인스턴스의
이름이 나오도록 설정 되어 있다.
LBaaS 에서 load-balancer 생성을 위하여 위에 설명한 것 처럼 top-down 방식으로 각 컴포넌트들을 생성 해야 한다.
load-balancer → listener → pool → member → healthmonitor 이러한 구조생성한다.
아래와 같이 테스트를 진행 한다.
how to ?
위 과정으로 lb 생성시 아래와 같이 namespace 가 생성 되어 있는 것을 확인 할 수 있다.
또한 같은 selfservice 네트워크와 연결 될 수 있도록 해당 브릿지에 인터페이스가 추가 되어 내부 selfservice 네트워크 인스턴스들과 통신 할 수 있는 것을 확인 할 수 있다.
실제로 vip 가 contoller node 에 설정 되기 때문에 해당 vip를 바인딩 하여 부하분산의 역할을 하는 haproxy를 확인 할 수 있다.
위에서 설정한 옵션이 haproxy옵션으로 추가 되는 것을 확인 할 수 있다.
위 haproxy 설정중 frontend 에 option forwardfor 가 자동으로 http mode 일 경우 추가 된다.
실제로 클라이언트에서 wireshark로 packet를 확인 하면 아래와 같이 http header에 추가 된것을 볼 수 있다.
Delete load-balancer
load-balancer 삭제 과정은 생성 과정의 반대로 진행 해야 한다
만약 해당 load-balancer에 listener 가있으면 load-balancer가 삭제가 안되며, pool 에 member 가 있을 경우 pool 이 삭제가 안된다.
그렇기 때문에 healthmonitor->member->pool->listener-> load-balancer 순서로 삭제를 모두 해야 정상적으로 삭제가 된다.
LBaaS scheduling
그렇다면 다중 controller 구조에서 lb를 어떠한 기준으로 scheduling 할까? 라는 의문점이 들었다.
아래 gitbub 공개된 neutron_lbaas 소스중 agent_scheduler.py 파일을 확인해보았다.
LoadbalancerAgentBinding 클래스를 통하여 agent가 활성 되어 있는 것을 확인 하며
LbaasAgentSchedulerDbMixin 통하여 active 상태를 랜덤 하게 할당 하는 것을 볼 수 있다.(자세한 부분은 해당 소스 직접 확인)
그렇기 때문에 neutron db에서는 해당 로드밸런서 가 특정 agent id 에 할당 되어 있는것을 확인 할 수 있다.
LBaaS rescheduling(LBaaS high-ability)
LBaaS 는 기본적으로 Neutron L3-HA와 같이 HA 구성이 불가능하다.(추후 L3-HA와 같이 구성할 예정이라는 글만 보이고 있다.)
그렇기 때문에 특정 controller node 에 스케쥴링된 load balancer 가 장애시 다른 controller node 로 복구 되지 않는다.
하지만, allow_automatic_lbaas_agent_failover 옵션을 통하여 agent 간 상태가 DOWN일 경우 rescheduling 하여 가용 할 수 있는 controller node
load balancer 를 재 할당 한다.
allow_automatic_lbaas_agent_failover | (BoolOpt) Automatically reschedule loadbalancer from offline to online lbaas agents. This is only supported for drivers who use the neutron LBaaSv2 agent |
참고: https://docs.openstack.org/ocata/config-reference/tables/conf-changes/neutron.html
설정은 neutron.conf,neutron_lbaas.conf 파일을 수정 하여 Neutron 재시작 하여 사용 한다.
Ref : https://docs.openstack.org/mitaka/networking-guide/config-lbaas.html
'Openstack' 카테고리의 다른 글
openstack helm을 이용한 kubernetes환경에서 openstack 배포 (0) | 2020.08.02 |
---|---|
DVR packet flow(FIP:North-south) (0) | 2018.12.01 |
Ansible Cloud(openstack) 모듈을 이용한 볼륨/인스턴스 생성 (0) | 2018.10.21 |
Openstack barbican install/Barbican-cinder encryption (0) | 2018.07.26 |
Openstack token provider(fernet) (0) | 2018.05.07 |