2.4. 라우팅 방법
Red Hat Enterprise Linux는 Keepalived에NAT( Network Address Translation ) 또는 직접 라우팅을 사용합니다. 따라서 사용 가능한 하드웨어를 활용하고 로드 밸런서를 기존 네트워크에 통합할 때 관리자가 상당한 유연성을 확보할 수 있습니다.
2.4.1. NAT 라우팅
그림 2.3. “NAT 라우팅을 사용하여 구현됨”에서는 NAT 라우팅을 사용하여 인터넷과 사설 네트워크 간에 요청을 이동하는 로드 밸런서를 보여줍니다.
그림 2.3. NAT 라우팅을 사용하여 구현됨
[D]
이 예제에는 활성 LVS 라우터에는 두 개의 NIC가 있습니다. 인터넷의 NIC에는 eth0에 실제 IP 주소 와 유동 IP 주소가 있습니다. 사설 네트워크 인터페이스의 NIC에는 실제 IP 주소와 eth1에 유동 IP 주소가 있습니다. 페일오버가 발생하는 경우 인터넷에 직면하는 가상 인터페이스와 개인 직면의 가상 인터페이스가 백업 LVS 라우터에 의해 동시에 수행됩니다. 사설 네트워크에 있는 모든 실제 서버는 NAT 라우터의 유동 IP를 기본 경로로 사용하여 활성 LVS 라우터와 통신하여 인터넷의 요청에 응답할 수 있는 기능이 손상되지 않습니다.
이 예에서는 LVS 라우터의 공용 유동 IP 주소와 개인 NAT 유동 IP 주소가 물리적 NIC에 할당됩니다. 각 유동 IP 주소를 LVS 라우터 노드의 자체 물리적 장치에 연결할 수 있지만 NIC를 두 개 이상 보유하는 것은 필수 사항은 아닙니다.
이 토폴로지를 사용하면 활성 LVS 라우터에서 요청을 수신하고 적절한 서버로 라우팅합니다. 그런 다음 실제 서버에서 요청을 처리하고 네트워크 주소 변환을 사용하는 LVS 라우터에 패킷을 반환하여 패킷의 실제 서버 주소를 LVS 라우터의 공용 VIP 주소로 바꿉니다. 이 프로세스를 실제 서버의 실제 IP 주소가 요청 클라이언트로부터 숨겨져 있기 때문에 IP 마스커레이딩 이라고 합니다.
이 NAT 라우팅을 사용하면 실제 서버가 다양한 운영 체제를 실행하는 모든 종류의 시스템일 수 있습니다. 주요 단점은 LVS 라우터가 들어오는 요청과 들어오는 요청을 처리해야 하므로 대규모 클러스터 배포에서 병목 현상이 발생할 수 있다는 것입니다.
ipvs 모듈은 iptables 및 ip6tables NAT와 독립적인 자체 내부 NAT 루틴을 사용합니다. 그러면 /etc/keepalived/keepalived.conf 파일의 DR과 달리 실제 서버가 NAT에 대해 구성된 경우 IPv4 및 IPv6 NAT가 원활하게 수행됩니다.
2.4.2. 직접 라우팅
직접 라우팅을 사용하는 로드 밸런서 설정을 구축하면 다른 로드 밸런서 네트워킹 토폴로지에 비해 성능상의 이점이 향상됩니다. 직접 라우팅을 사용하면 실제 서버에서 LVS 라우터를 통해 나가는 모든 패킷을 전달하는 대신 요청하는 사용자에게 직접 패킷을 처리하고 라우팅할 수 있습니다. 직접 라우팅은 들어오는 패킷만 처리하기 위해 LVS 라우터의 작업을 다시 부여하여 네트워크 성능 문제가 발생할 가능성을 줄입니다.
그림 2.4. 직접 라우팅으로 구현되는 로드 밸런서
[D]
일반적인 직접 라우팅 로드 밸런서 설정에서 LVS 라우터는 VIP(가상 IP)를 통해 들어오는 서버 요청을 수신하고 스케줄링 알고리즘을 사용하여 요청을 실제 서버로 라우팅합니다. 실제 서버는 요청을 처리하고 LVS 라우터를 우회하여 응답을 클라이언트로 직접 보냅니다. 이 라우팅 방법을 사용하면 LVS 라우터의 추가 부담 없이 실제 서버의 확장성을 추가하여 실제 서버에서 클라이언트로 나가는 패킷을 라우팅할 수 있으며, 이는 네트워크 로드가 많은 병목 현상이 될 수 있습니다.
2.4.2.1. 직접 라우팅 및 ARP 제한
로드 밸런서에서 직접 라우팅을 사용하는 데는 많은 이점이 있지만 제한 사항도 있습니다. 직접 라우팅을 통한 로드 밸런서의 가장 일반적인 문제는ARP( Address Resolution Protocol )입니다.
일반적인 상황에서 인터넷의 클라이언트는 IP 주소로 요청을 보냅니다. 네트워크 라우터는 일반적으로 IP 주소와 관련하여 ARP가 있는 시스템의 MAC 주소로 요청을 대상에 보냅니다. ARP 요청은 네트워크의 모든 연결된 시스템에 브로드캐스트되며 올바른 IP/MAC 주소 조합이 있는 시스템은 패킷을 수신합니다. IP/MAC 연결은 ARP 캐시에 저장되며 주기적으로 지워지고 (일반적으로 15분마다) IP/MAC 연결로 다시 채워집니다.
직접 라우팅 로드 밸런서 설정에서 ARP 요청의 문제는 요청을 처리하기 위해 IP 주소에 대한 클라이언트 요청이 MAC 주소와 연결되어야 하므로 로드 밸런서 시스템의 가상 IP 주소도 MAC에 연결되어야 한다는 것입니다. 그러나 LVS 라우터와 실제 서버 모두 동일한 VIP를 사용하므로 ARP 요청은 VIP와 연결된 모든 머신에 브로드캐스트됩니다. 이로 인해 VIP가 실제 서버 및 처리 요청 중 하나에 직접 연결되어 LVS 라우터를 완전히 우회하고 로드 밸런서 설정의 목적을 손상시키는 것과 같은 여러 문제가 발생할 수 있습니다.
이 문제를 해결하려면 들어오는 요청이 항상 실제 서버 중 하나가 아닌 LVS 라우터로 전송되었는지 확인합니다. 이 작업은 ARP 요청을 필터링하거나 IP 패킷을 필터링하여 수행할 수 있습니다. ARP 필터링은 arptables 유틸리티 및 IP 패킷을 iptables 또는
firewalld 를 사용하여 필터링할 수 있습니다. 두 가지 접근 방식은 다음과 같습니다.
- ARP 필터링 방법은 실제 서버에 도달하는 요청을 차단합니다. 이렇게 하면 ARP가 VIP를 실제 서버와 연결하지 못하도록 활성 가상 서버가 MAC 주소에 응답합니다.
- IP 패킷 필터링 방법을 사용하면 다른 IP 주소가 있는 실제 서버로 패킷을 라우팅할 수 있습니다. 이는 먼저 실제 서버에서 VIP를 구성하지 않고 ARP 문제를 완전히 처리합니다.
