목차/03. 요구사항·호환성

03요구사항·호환성요구사항·호환성

ClusterXL을 세우기 전에 무엇을 어떤 형태로 설치할 수 있고, 멤버는 몇 대까지 묶을 수 있으며, 멤버끼리 무엇이 똑같아야 하는지 를 먼저 알아야 합니다. 이 장은 어플라이언스·Open Server 설치 형태, 지원 멤버 수, 하드웨어·소프트웨어 요구사항, VMAC 모드, 동기화 네트워크 토폴로지, 클록 동기화, IPv6 지원, 그리고 동기화 클러스터의 제약까지 빠짐없이 정리합니다.

Check Point 어플라이언스와 Open Server

ClusterXL은 Check Point 어플라이언스에 다음 두 가지 형태 중 하나로 설치할 수 있습니다.

  • Distributed(분산) 구성 — Cluster Member와 Security Management Server를 서로 다른 컴퓨터에 설치하는 방식입니다.
  • Full High Availability 구성 — Cluster Member와 Security Management Server를 같은 컴퓨터에 설치하는 방식입니다. 이때 각 컴퓨터는 Standalone 구성으로 동작합니다.

단, Open Server에는 Distributed 구성으로만 ClusterXL을 설치할 수 있습니다(즉, 멤버와 관리 서버를 다른 컴퓨터에 두어야 합니다).

ClusterXL이 지원하는 플랫폼 목록은 R82 Release Notes 를, 설치 방법은 R82 Installation and Upgrade Guide 를 참고하세요.

지원하는 클러스터 멤버 수

묶을 수 있는 멤버 수는 모드마다 다릅니다.

모드지원 멤버 수
High Availability최대 5대
Load Sharing최대 5대
VRRP Cluster(Gaia OS)2대 (sk105170 참고)
VSLS(Virtual System Load Sharing)최대 13대

멤버의 하드웨어 요구사항

ClusterXL의 동작은 전적으로 내부 타이머와 내부 타임아웃 계산에 의존 하는데, 이 계산은 하드웨어 클록 틱(hardware clock ticks)을 기준 으로 합니다. 그래서 예기치 않은 동작을 피하려면, ClusterXL은 CPU 특성이 동일한 장비끼리만 지원됩니다.

멤버의 소프트웨어 요구사항

소프트웨어 쪽도 멤버들이 동일해야 한다 는 원칙은 똑같습니다.

  • ClusterXL은 동일한 운영체제끼리만 지원됩니다 — 모든 Cluster Member가 같은 OS에 설치되어 있어야 합니다.
  • ClusterXL은 동일한 Check Point 소프트웨어 버전끼리만 지원됩니다 — OS 빌드와 핫픽스(hotfix)까지 포함해 모든 멤버가 동일한 Check Point 소프트웨어를 설치하고 있어야 합니다.
  • 모든 Check Point 소프트웨어 구성 요소가 모든 멤버에서 같아야 합니다. 즉, 켜진 Software Blade와 기능이 모든 멤버에서 동일 해야 합니다. 구체적으로 다음 항목들이 일치해야 합니다.
    • SecureXL 상태 가 모든 멤버에서 같아야 합니다(전부 켜져 있거나, 전부 꺼져 있거나).
    • CoreXL Firewall 인스턴스 수 가 모든 멤버에서 같아야 합니다.
    • Advanced Dynamic Routing 상태와 설정이 모든 멤버에서 같아야 합니다.

CoreXL 인스턴스 수가 어긋날 때의 동작은 다음과 같습니다.

상황결과
CoreXL Firewall 인스턴스가 더 많은 멤버자신의 상태를 DOWN으로 변경 합니다.
인스턴스 수가 더 많은 상대 멤버로 페일오버모든 연결이 유지 됩니다.
인스턴스 수가 더 적은 상대 멤버로 페일오버일부 연결이 끊깁니다. 끊기는 연결은, 상대 멤버에 존재하지 않는 CoreXL Firewall 인스턴스를 지나던 연결들입니다.

이런 조건이 어긋나면 트래픽이 예상대로 처리되지 않거나 멤버 상태가 예기치 않게 바뀔 수 있고, 무엇보다 Full Sync가 실패 합니다.

VMAC 모드 — 페일오버를 매끄럽게

ClusterXL을 High Availability 모드나 Load Sharing Unicast 모드(Multicast 아님) 로 구성하면, 클러스터 Virtual IP 주소에는 단 한 멤버만 연결 됩니다. High Availability 환경에서는 그 한 멤버가 Active 멤버이고, Load Sharing 환경에서는 Pivot 멤버입니다.

페일오버가 일어나면, 새 Active(또는 새 Pivot) 멤버가 Gratuitous ARP Request(GARP)를 연달아 브로드캐스트 합니다. 이 GARP는 클러스터의 Virtual IP 주소를 새 Active(또는 Pivot) 멤버의 물리 MAC 주소에 다시 연결 하는 역할을 합니다. 그런데 이 과정에서 다음과 같은 문제가 생길 수 있습니다.

  • Static NAT 항목이 많은 멤버는 GARP를 너무 많이 보냅니다. 그러면 스위치가 이 GARP 갱신을 ARP 테이블에 제때 반영하지 못해, 이미 죽은 멤버의 물리 MAC 주소로 계속 트래픽을 보냅니다. 스위치가 ARP 캐시를 완전히 갱신할 때까지 트래픽이 끊깁니다.
  • VoIP 전화 같은 일부 네트워크 장비는 GARP를 아예 무시합니다. 이런 장비들은 죽은 멤버의 MAC 주소로 계속 트래픽을 보냅니다.

이런 페일오버 중 트래픽 단절을 최소화하려고 쓰는 것이 Virtual MAC(VMAC) 입니다. ClusterXL High Availability 모드나 Load Sharing Unicast 모드에서 Virtual MAC을 켜면, 모든 멤버가 동일한 Virtual MAC 주소를 모든 클러스터 Virtual 인터페이스와 Virtual IP에 연결 합니다. Virtual MAC 모드에서 멤버들이 (GARP Request로) 광고하는 VMAC은, 각 멤버의 실제 MAC 주소는 그대로 둔 채 그 위에 Virtual MAC 주소를 덧붙이는 방식입니다.

로컬 연결과 Sync 연결에 대해서는, 각 멤버의 실제 물리 MAC 주소가 여전히 자신의 실제 IP 주소에 연결 되어 있습니다.

VMAC 모드를 켠 클러스터의 페일오버 시간은, 물리 MAC 주소를 쓰는 클러스터의 페일오버보다 짧 습니다. VMAC 설정 방법은 고급 기능의 Virtual MAC(VMAC) 구성 항목을 참고하세요.

동기화 네트워크가 지원하는 토폴로지

동기화 네트워크는 여러 토폴로지로 구성할 수 있습니다. 아래에서는 네 가지를 차례로 다룹니다.

Topology 1

Topology 1
Topology 1
  1. Sync 인터페이스를 여러 물리 subordinate 인터페이스의 Bond 로 구성합니다. 이 토폴로지에서는 Bond 인터페이스를 High Availability 또는 Load Sharing 모드 로 설정할 수 있습니다.
  2. 모든 멤버의 모든 물리 subordinate 인터페이스가 같은 스위치 하나에 연결 됩니다.
  3. 이 토폴로지에서 멤버들은 subordinate 인터페이스의 링크 상태(link state)만 감시 합니다.

Topology 2

Topology 2
Topology 2
  1. Sync 인터페이스를 여러 물리 subordinate 인터페이스의 Bond 로 구성합니다. 이 토폴로지에서도 Bond 인터페이스를 High Availability 또는 Load Sharing 모드 로 설정할 수 있습니다.
  2. 각 멤버에서 같은 Bond에 속한 물리 subordinate 인터페이스들이 서로 다른 스위치에 연결됩니다.
  3. 두 스위치는 케이블로 서로 연결 되어 있어야 합니다.
  4. 이 토폴로지에서도 멤버들은 subordinate 인터페이스의 링크 상태만 감시 합니다.

Topology 3 (Enhanced Active/Backup Bond)

Topology 3
Topology 3
  1. Sync 인터페이스를 여러 물리 subordinate 인터페이스의 Bond 로 구성합니다. 이 토폴로지에서는 다음 조건을 지켜야 합니다.
    • Bond 인터페이스를 반드시 Active-Backup 모드 로 설정해야 합니다.
    • primary subordinate 인터페이스를 명시적으로 지정하면 안 됩니다.
  2. 각 멤버에서 같은 Bond에 속한 물리 subordinate 인터페이스들이 서로 다른 스위치에 연결됩니다.
  3. 스위치끼리 케이블로 연결할 필요는 없 습니다.
  4. 이 토폴로지에서 멤버들은 다음을 수행합니다.
    • subordinate 인터페이스의 링크 상태를 감시합니다.
    • 멤버 사이의 경로(path)를 감시하고, 서로의 연결성에 관해 통신하며, 어느 Bond subordinate 인터페이스를 쓸지 합의 합니다.
    • CCP 패킷을 활성(active) subordinate 인터페이스로만 전송 합니다(모든 subordinate 인터페이스로 CCP를 브로드캐스트하지 않습니다).
    • 모든 subordinate 인터페이스가 다 죽어야만 페일오버 합니다.

추가 정보 — 어떤 멤버가 다른 멤버로부터 CCP 패킷을 받지 못하면(예: 스위치 사이의 케이블이 빠진 경우), 그 멤버는 다른 모든 멤버에게 전용(dedicated) CCP 패킷 을 보냅니다. 이 전용 CCP 패킷에는 그 멤버가 쓸 수 있는 모든 Bond subordinate 인터페이스의 맵(map) 이 담겨 있습니다. 다른 멤버들은 이 전용 CCP 패킷을 받으면 다음을 수행합니다.

  • 받은 "사용 가능한 Bond subordinate 인터페이스 맵"을 자신의 Bond subordinate 인터페이스 상태와 비교합니다.
  • 그 결과에 따라 Bond 내부 페일오버(bond internal failover) 를 수행합니다.
  • 사용 가능한 모든 subordinate 인터페이스를 순회하는 대신, 특정하게 선택된 subordinate 인터페이스로 곧장 페일오버 합니다.

Topology 4 (Enhanced Active/Backup Bond)

Topology 4
Topology 4
  1. Sync 인터페이스를 여러 물리 subordinate 인터페이스의 Bond 로 구성합니다. 이 토폴로지에서도 다음 조건을 지켜야 합니다.
    • Bond 인터페이스를 반드시 Active-Backup 모드 로 설정해야 합니다.
    • primary subordinate 인터페이스를 명시적으로 지정하면 안 됩니다.
  2. 각 멤버에서 같은 Bond에 속한 물리 subordinate 인터페이스들이 서로 다른 스위치 쌍(pair)에 연결됩니다.
  3. 이 스위치 쌍들이 서로 연결(체인처럼 연결, chained together) 됩니다.
  4. 이 토폴로지에서 멤버들은 다음을 수행합니다.
    • subordinate 인터페이스의 링크 상태를 감시합니다.
    • 멤버 사이의 경로를 감시하고, 서로의 연결성에 관해 통신하며, 어느 Bond subordinate 인터페이스를 쓸지 합의 합니다.
    • CCP 패킷을 활성 subordinate 인터페이스로만 전송 합니다(모든 subordinate 인터페이스로 CCP를 브로드캐스트하지 않습니다).
    • 모든 subordinate 인터페이스가 다 죽어야만 페일오버 합니다.

추가 정보 — Topology 3과 마찬가지로, 어떤 멤버가 다른 멤버로부터 CCP 패킷을 받지 못하면(예: 스위치 사이의 케이블이 빠진 경우) 다른 모든 멤버에게 전용 CCP 패킷 을 보냅니다. 이 패킷에는 그 멤버가 쓸 수 있는 모든 Bond subordinate 인터페이스의 맵이 담깁니다. 다른 멤버들은 이 패킷을 받으면 자신의 Bond subordinate 인터페이스 상태와 비교하여 Bond 내부 페일오버를 수행하고, 모든 subordinate 인터페이스를 순회하는 대신 선택된 특정 subordinate 인터페이스로 곧장 페일오버 합니다.

ClusterXL의 클록 동기화

ClusterXL을 쓸 때는 모든 Cluster Member의 클록(시계)을 반드시 동기화 해야 합니다. 클록은 수동으로 맞추거나, NTP 같은 프로토콜 로 동기화할 수 있습니다. VPN 같은 기능은 모든 멤버의 클록이 동기화되어 있어야만 제대로 동작 합니다.

ClusterXL의 IPv6 지원

R82 ClusterXL은 IPv6에 대해 High Availability 클러스터를 지원 합니다. IPv6 상태 정보도 동기화되며, 페일오버가 일어날 때 IPv6 클러스터링 메커니즘이 활성화됩니다.

IPv6 주소는 다음에 지정할 수 있습니다.

  • 클러스터 Virtual 인터페이스
  • 멤버의 물리 인터페이스

다만 다음과 같은 제한이 있습니다.

  • Load Sharing 클러스터에서는 IPv6를 지원하지 않 습니다.
  • 동기화 인터페이스(synchronization interface)에는 IPv6 주소를 지정할 수 없 습니다.

ClusterXL High Availability에서의 IPv6 동작 — 페일오버 동안 클러스터는 Gratuitous ARP Request 패킷을 보내 클러스터 인터페이스에 연결된 호스트·라우터를 갱신합니다. 이는 가상 클러스터 IPv4 주소에 대한 새 MAC 주소를 광고하는 방식입니다. ClusterXL은 페일오버 동안 IPv6 네트워크도 갱신합니다 — Neighbor Advertisement 메시지를 보내 neighbor cache(IPv4의 ARP 캐시에 해당)를 갱신 하며, 가상 클러스터 IPv6 주소에 대한 새 MAC 주소를 광고합니다. 또한 target 주소가 가상 클러스터 IPv6 주소와 같은 Neighbor Solicitation에는 모두 응답 합니다.

동기화 클러스터의 제약

Cluster Member를 동기화할 때는 다음과 같은 제약이 적용됩니다.

  • 동기화 이중화(synchronization redundancy)를 위해 전용 물리 인터페이스를 둘 이상 쓰는 것은 지원되지 않 습니다. 대신 동기화 인터페이스 이중화에는 Bonding 을 쓰면 됩니다(Sync Redundancy 항목 참고). 또한 VRRP 클러스터에서는 동기화 인터페이스 이중화가 지원되지 않 습니다(sk92804 참고).
  • 모든 Cluster Member는 동일하게 구성된 하드웨어 플랫폼에서 동작 해야 합니다.
  • 한 멤버가 죽으면, 그 멤버를 지나던 user-authenticated 연결은 유실 됩니다. 다른 멤버들은 그 연결을 복구할 수 없습니다. 다만 client-authenticated·session-authenticated 연결은 유지 됩니다. 이렇게 차이가 나는 이유는, 멤버의 user space 프로세스가 사용자 인증 상태를 보관 하기 때문입니다. 멤버들은 kernel space 정보를 동기화하는 방식으로는 user space 정보를 동기화할 수 없습니다. 반면 Session Authentication과 Client Authentication 상태는 kernel 테이블에 저장되어 동기화 되므로 유지됩니다.
  • 시스템 리소스(system resources)를 쓰는 연결 상태는 동기화할 수 없 습니다. 이유는 user-authenticated 연결과 같습니다.
  • 연결에 대한 어카운팅(accounting) 정보는 각 멤버에 누적되었다가 관리 서버로 보내져 집계 됩니다. 페일오버가 일어나면, 아직 관리 서버로 보내지지 않은 어카운팅 정보는 유실 됩니다. 이 위험을 줄이려면 어카운팅 정보를 보내는 시간 간격을 줄이면 됩니다. 클러스터 객체 > Logs > Additional Logging 창에서 Update Account Log every 값을 더 낮게 설정하면 됩니다.