04HA·Load Sharing 모드HA·Load Sharing 모드

ClusterXL의 고가용성은 다음 네 가지로 요약됩니다.

클러스터의 모든 멤버는 다른 멤버를 거쳐 가는 연결을 전부 알고 있습니다. 멤버들은 연결 정보와 상태 정보를 보안 전용 동기화 네트워크(synchronization network)를 통해 서로 맞춰 둡니다. 이 멤버들을 하나로 묶어 주는 접착제가 바로 Cluster Control Protocol(CCP) 로, 동기화 정보를 비롯한 멤버 간 정보를 주고받는 데 쓰입니다.

High Availability 클러스터에서는 한 멤버만 Active이고 나머지는 Standby 입니다(Active/Standby 동작). Active 멤버를 더 이상 쓸 수 없게 되면 모든 연결이 미리 지정된 Standby로 끊김 없이 다시 라우팅 됩니다. 동기화된 클러스터에서는 Standby 멤버들이 Active 멤버의 연결 상태를 늘 갱신받 으므로 페일오버 때도 연결이 그대로 살아남습니다.

멤버마다 우선순위(priority)가 매겨집니다. 평소에는 우선순위가 가장 높은 멤버가 Security Gateway 역할 을 하고, 그 멤버가 죽으면 다음 우선순위 멤버로 제어가 넘어가며, 그 멤버마저 죽으면 또 다음 멤버로 차례차례 넘어갑니다.

Security Gateway가 복구된 뒤에는 두 가지 중 하나로 동작합니다 — 현재 Active 멤버를 그대로 유지(Maintain current active = Active Up) 하거나, 우선순위가 가장 높은 멤버로 다시 전환(Switch to higher priority = Primary Up) 합니다. ClusterXL High Availability 모드는 IPv4와 IPv6를 모두 지원 합니다.

Load Sharing 은 클러스터 안에서 트래픽을 멤버들끼리 나눠, 여러 멤버의 총 처리량을 끌어올리는 방식입니다. 한 번에 한 멤버만 동작하는 High Availability와 달리, Load Sharing에서는 정상 동작하는 모든 멤버가 Active로 트래픽을 처리 합니다(Active/Active 동작).

어떤 멤버가 통신 불가 상태가 되면 남은 정상 멤버들로 투명한 페일오버가 일어나 고가용성도 함께 제공 됩니다. 모든 연결이 남은 Security Gateway들 사이에서 끊김 없이 공유됩니다. 다만 ClusterXL Load Sharing 모드는 IPv6를 지원하지 않 습니다.

ClusterXL은 멤버마다 고유한 물리 IP·MAC 주소 를 쓰고, 클러스터 자체에는 가상 IP(Virtual IP) 주소 를 씁니다. 이 클러스터 인터페이스 가상 IP는 어떤 실제 멤버 인터페이스에도 속하지 않 습니다. 아래는 두 멤버로 이루어진 ClusterXL 클러스터로, 클러스터 가상 IP와 멤버들의 물리 IP를 함께 보여 줍니다. 이 배치는 이 장의 여러 예제에서 공통으로 쓰입니다.

각 멤버는 외부·내부·동기화 세 인터페이스 를 가지며, 같은 방향을 향한 인터페이스들은 허브나 스위치로 연결합니다. 관리 서버(Management Server)는 어디에 있어도 되고, 내부 또는 외부 클러스터 IP로 연결 하면 됩니다.

멤버 IP 주소 정하기

각 멤버를 구성할 때 지켜야 할 지침은 이렇습니다. 클러스터 안의 모든 멤버는 최소 세 개의 인터페이스 를 가져야 합니다.

그리고 특정 방향을 향한 인터페이스들은 모두 같은 네트워크에 있어야 합니다. 위 그림에서 두 멤버 Member_A·Member_B는 각각 허브나 스위치를 통해 인터넷을 향한 인터페이스를 갖는데, 이것이 외부 인터페이스로 Member_A는 192.168.10.1, Member_B는 192.168.10.2 입니다.

클러스터 가상 IP 주소 정하기

위 그림에서 클러스터의 IP는 192.168.10.100 입니다. 클러스터는 외부 가상 IP 하나와 내부 가상 IP 하나 를 가지는데, 외부 IP는 192.168.10.100, 내부 IP는 10.10.0.100 입니다.

동기화 네트워크 정하기

위 그림에서 동기화 인터페이스는 멤버마다 고유한 IP를 갖습니다 — Member_A는 10.0.10.1, Member_B는 10.0.10.2 입니다.

클러스터와 멤버 IP를 다른 서브넷에 두기

ClusterXL 클러스터에 필요한 공인 IP는 인터넷을 향한 가상 클러스터 인터페이스 단 하나 뿐이고, 멤버들의 물리 IP는 모두 사설이어도 됩니다. 클러스터 IP와 멤버 IP를 서로 다른 서브넷으로 구성하면("Cluster IP Addresses on Different Subnets" 참고) 다음 두 가지에 유용합니다.

HA · Load Sharing · Active-Active 중 무엇을 고를까

어떤 모드를 고를지는 조직의 필요와 요구에 달렸습니다.

자세한 비교는 아래 모드 비교 표를 참고하세요.

Load Sharing 모드에서 따져 볼 점

Load Sharing Multicast 모드는 부하를 모든 Active 멤버에 최적으로 분산 하므로 높은 트래픽 부하를 효율적으로 다룹니다. 그러나 모든 스위치에서 쓸 수 있는 것은 아닙니다. Multicast 모드는 멀티캐스트 Cluster MAC 주소를 유니캐스트 Cluster Virtual IP에 연결 해, 클러스터로 향하는 트래픽이 모든 멤버에 도달하도록 합니다.

문제는 ARP에 있습니다. 클러스터 가상 IP에 대한 ARP Request에 대해, 멤버들은 유니캐스트 Cluster Virtual IP와 멀티캐스트 MAC 주소를 담은 ARP Reply 를 보냅니다. 그런데 일부 스위치는 이런 ARP Reply를 받아들이지 못 합니다. 어떤 스위치는 유니캐스트 가상 IP와 멀티캐스트 MAC에 대한 정적 ARP 항목(static ARP entry)을 추가 하면 해결되지만, 또 어떤 스위치는 그런 정적 ARP 항목조차 받아들이지 않습니다.

또 하나 따져 볼 것은 promiscuous 모드로 동작하는 인터페이스를 가진 네트워킹 장비 가 배치에 끼어 있는 경우입니다. 같은 네트워크 세그먼트에 그런 장비가 둘 있고 거기에 Load Sharing Multicast 모드 ClusterXL이 함께 있으면, 한 장비가 만들어 클러스터로 보낸 트래픽을 다른 장비도 처리해 버릴 수 있습니다.

이런 경우에는 Load Sharing Unicast 모드 를 쓰면 됩니다. 이 모드는 가상 IP에 멀티캐스트 MAC를 쓰지 않습니다.

IP 주소 마이그레이션

기존 Security Gateway 구성에 High Availability나 Load Sharing을 도입하려는 경우, 가능하면 Active Security Gateway의 기존 IP 주소를 가져와 그것을 클러스터 가상 IP로 삼는 것을 권장합니다. 이렇게 하면 현재의 IPsec 엔드포인트 식별자(endpoint identity)를 바꾸지 않아도 되고, 많은 경우 Hide NAT 구성도 그대로 유지 할 수 있습니다.

ClusterXL에는 여러 동작 모드가 있습니다.

High Availability 모드

ClusterXL High Availability 모드는 클러스터 환경에서 기본적인 고가용성 기능을 제공합니다. 즉 일반 Security Gateway였다면 연결이 완전히 끊어질 문제가 생겨도, 클러스터는 방화벽 서비스를 계속 제공 합니다. 여기에 Check Point State Synchronization을 결합하면 페일오버가 일어나도 사용자가 전혀 눈치채지 못하게 연결을 유지 할 수 있습니다. 그래서 High Availability는 특히 미션 크리티컬 환경(금융 거래 등)에서 예기치 못한 다운타임의 위험을 줄이는 백업 메커니즘이 됩니다.

이를 위해 HA 모드는 한 멤버를 Active로 지정하고 나머지는 Standby로 둡니다. 클러스터는 가상 IP를 Active 멤버의 물리 인터페이스 MAC 주소에 연결 합니다(가상 IP를 적절한 물리 인터페이스의 고유 MAC과 짝지음). 따라서 클러스터 가상 IP로 향하는 모든 트래픽은 실제로는 Active 멤버가 라우팅·필터링 합니다.

각 멤버의 역할은 클러스터 상태와 멤버 우선순위 에 따라 정해집니다. 우선순위는 SmartConsole의 클러스터 객체 Cluster Members 페이지에 나타나는 순서 와 같아서, 맨 위 멤버가 가장 높은 우선순위 를 가집니다. 이 순서는 언제든 바꿀 수 있는데(정책 설치가 필요하고 페일오버가 발생 합니다).

Active 멤버는 방화벽 역할 외에 자기 클러스터 상태와 커널 테이블의 변화를 Standby 멤버들에게 알리는 일도 맡아, 클러스터를 지나는 현재 트래픽 정보를 동료 멤버들이 최신으로 유지하게 합니다.

Active 멤버가 스스로 정상 동작할 수 없을 만큼 심각한 문제를 감지하면 페일오버가 발생 합니다. Standby 멤버 중 다음으로 우선순위가 높은 멤버가 Active 역할을 넘겨받 습니다. State Synchronization이 켜져 있으면 새 Active 멤버는 열려 있던 연결들을 알아보고 마지막 상태대로 이어서 처리 합니다.

장애가 났던 옛 Active 멤버(우선순위가 더 높았던)가 복구되면, Active 역할이 그 멤버로 되돌아갈 수도, 그대로 둘 수도 있습니다 — 이는 클러스터 객체 설정(Maintain current active 또는 Switch to higher priority)에 달렸습니다.

예제 — HA 모드 연결 흐름

외부 네트워크의 클라이언트가 클러스터 뒤(내부 네트워크)의 웹 서버에 접속하는 시나리오입니다. 두 멤버가 High Availability 모드로 구성되어 있습니다.

                  [외부 네트워크의 클라이언트]
                   IP 192.168.10.78/24
                   DG 192.168.10.100
                          |
                  VIP 192.168.10.100/24
                        /   \
          IP 192.168.10.1/24   IP 192.168.10.2/24
              {Active}             {Standby}
          [Member1]------sync------[Member2]
          IP 10.10.0.1/24       IP 10.10.0.2/24
                        \   /
                  VIP 10.10.0.100/24
                          |
                   DG 10.10.0.100
                   IP 10.10.0.34/24
                  [내부 네트워크의 웹 서버]

일어나는 일의 순서는 이렇습니다.

이 GARP는 클러스터 가상 IP를 새 Active 멤버의 물리 인터페이스 MAC에 다시 연결합니다. - 가상 IP 192.168.10.100 ↔ 192.168.10.2 가 설정된 외부 인터페이스의 MAC - 가상 IP 10.10.0.100 ↔ 10.10.0.2 가 설정된 내부 인터페이스의 MAC 22. 이때부터 모든 트래픽은 새 Active 멤버(Member2)를 거쳐 갑니다. 23. 옛 Active 멤버(Member1)는 이제 "down"으로 간주됩니다. 그 멤버가 복구되면 Active 역할의 복귀 여부는 클러스터 객체 설정에 따라 달라집니다.

Load Sharing 모드

Load Sharing Multicast 모드

Load Sharing은 네트워크 트래픽을 멤버들끼리 분산 합니다. 한 번에 한 멤버만 Active인 High Availability와 달리 Load Sharing에서는 모든 멤버가 Active 입니다. 어느 멤버가 어느 패킷을 처리할지는 멤버들이 결정 하는데, 이 일을 맡는 것이 결정 함수(decision function) 입니다 — 클러스터를 지나는 패킷마다 살펴 어느 멤버가 처리할지를 정 합니다. 그 결과 클러스터가 모든 멤버를 활용해 총 처리량이 늘 어납니다.

여기서 ClusterXL Load Sharing은 완전한 High Availability도 함께 제공 한다는 점이 중요합니다. 모든 멤버가 Active일 때는 트래픽이 멤버들 사이에 고르게 분산되고, 한 멤버에 문제가 생겨 페일오버가 나면 그 멤버가 처리하던 모든 연결을 나머지 멤버가 즉시 넘겨받 습니다.

ClusterXL은 두 가지 Load Sharing 방식을 제공합니다 — Multicast 와 Unicast. 둘은 멤버들이 클러스터로 보내진 패킷을 받는 방식 에서 차이가 납니다.

이더넷 네트워크 계층이 제공하는 멀티캐스트 메커니즘은 여러 인터페이스를 하나의 물리(MAC) 주소에 연결 할 수 있게 합니다. 같은 서브넷의 모든 인터페이스를 하나의 MAC에 묶는 브로드캐스트와 달리, 멀티캐스트는 네트워크 안에서 그룹을 지을 수 있습니다. 즉 한 서브넷 안에서 특정 MAC으로 보낸 패킷을 받을 인터페이스를 골라서 지정할 수 있습니다.

ClusterXL은 이 멀티캐스트로 클러스터 가상 IP를 멀티캐스트 MAC 주소에 연결 합니다. 그러면 기본 게이트웨이 역할을 하는 클러스터로 보내진 모든 패킷이 모든 멤버에 도달 하고, 각 멤버가 그 패킷을 처리할지 말지를 스스로 결정 합니다. 이 결정이 Load Sharing의 핵심으로, 적어도 한 멤버는 각 패킷을 처리하되(트래픽이 막히지 않게), 두 멤버가 같은 패킷을 처리하지는 않도록(트래픽이 중복되지 않게) 보장해야 합니다.

결정 함수에는 요구 사항이 하나 더 있습니다 — 한 연결에 속한 패킷들은 같은 멤버가 처리하도록 연결 단위로 라우팅 하는 것입니다. 다만 이 요구는 늘 강제할 수 있는 것은 아니어서, 같은 연결의 패킷이 서로 다른 멤버에서 처리되는 경우 도 있습니다. ClusterXL은 이런 상황을 모든 멤버에 연결을 복제하는 State Synchronization 으로 처리합니다.

예제 — Multicast 모드 연결 흐름

인터넷에서 클러스터 뒤의 웹 서버로 로그인하는 시나리오입니다. 클러스터는 Load Sharing Multicast 모드입니다.

Load Sharing Unicast 모드

Load Sharing Unicast 모드는 멀티캐스트 이더넷이 동작할 수 없는 환경에 맞춘 Load Sharing 해법입니다. 이 모드에서는 Pivot 이라 부르는 단일 멤버만 클러스터 가상 IP에 연결 되어, 클러스터로 보내진 모든 패킷을 받는 유일한 멤버 가 됩니다. 그런 다음 Pivot이 다른 멤버들에게 패킷을 분배 해 Load Sharing을 만들어 냅니다. 분배는 Multicast 모드와 똑같이 패킷마다 결정 함수를 적용 해 이뤄지는데, 차이는 오직 한 멤버(Pivot)만 이 선택을 한다 는 점입니다. 전달받은 패킷을 받은 non-Pivot 멤버는 결정 함수를 적용하지 않고 그냥 처리 합니다. non-Pivot 멤버도 자기 몫의 트래픽에 대해 라우팅·방화벽 작업을 하므로 여전히 Active 입니다(결정만 하지 않을 뿐).

Pivot이 결정 과정을 책임지지만 그 자신도 패킷을 처리하는 Security Gateway 입니다(예: 어떤 패킷은 자기가 직접 처리하기로 결정할 수 있음). 다만 분배라는 추가 작업이 시간을 잡아먹으므로, 보통 Pivot에는 더 적은 몫의 부하를 배정 합니다.

페일오버 동작은 누가 죽느냐에 따라 다릅니다.

예제 — Unicast 모드 연결 흐름

Load Sharing Unicast 클러스터를 최종 사용자 컴퓨터와 웹 서버 사이의 Security Gateway로 쓰는 시나리오입니다.

다음 표는 ClusterXL 모드들의 공통점과 차이점을 정리한 것입니다.

페일오버란 무엇인가

Failover(페일오버) 는 멤버가 정상 동작하지 못할 때 자동으로 일어나는 클러스터 중복(redundancy) 동작 으로, 이때 다른 멤버들이 장애 멤버를 대신합니다. 모드별로 동작이 다릅니다.

High Availability 모드에서는:

Load Sharing 모드에서는:

멤버들이 서로 살아 있음을 알리기 위해, ClusterXL의 Cluster Control Protocol(CCP) 가 멤버 간 heartbeat를 유지 합니다. 정해진 시간 동안 어떤 멤버로부터 CCP 패킷이 오지 않으면 그 멤버를 down으로 간주 하고, 페일오버가 일어날 수 있습니다.

페일오버는 언제 일어나는가

클러스터에서 다음 중 하나가 일어나면 페일오버가 발생합니다.

멤버가 복구되면 어떻게 되는가

High Availability 모드에서는 클러스터 객체 설정에 따라 갈립니다.

Load Sharing 모드에서는 장애 났던 멤버가 복구되면 모든 연결이 모든 Active 멤버 사이에 재분배 됩니다.

복구된 멤버가 보안 정책을 가져오는 방법

관리자는 보안 정책을 개별 멤버가 아니라 클러스터 객체에 설치 하고, 그러면 정책이 모든 멤버에 자동으로 설치 됩니다. 정책은 멤버 객체의 General Properties 페이지에 정의된 IP 주소로 전송됩니다.

장애 났던 멤버가 복구되면 다음 순서로 정책을 확보합니다.

이렇게 해서 모든 멤버가 언제나 같은 정책 을 쓰게 됩니다.

일반적인 페일오버 제약

일부 연결은 클러스터 페일오버를 넘기지 못할 수 있습니다.