들어가며
예전에 워드프레스 기반의 블로그를 운영하였으나, 운영 상의 이슈로 블로그를 닫은 지 벌써 6년 정도가 지났다. 그 동안에는 notion을 통해 개인적으로 작업 히스토리를 관리하고 있었으나 포트폴리오 관리 측면, 그리고 지식 공유 차원에서 다시금 퍼블릭한 공간에 문서를 작성해 보려 한다.
이 시리즈는 내가 프리랜서로 일하면서 설계한 네트워크 디자인에 대하여, Design Decision과 Lessons and Learn을 이야기하는 것을 목적으로 한다.
작업 배경
고객사는 프로그램 매매를 주력으로 하는 금융 스타트업으로, 직접 개발한 서비스가 Power Outage, Network Component Failure 상황에서도 중단 없이 동작하는 것을 원했다. 프로그램 매매가 시간 동기화에 굉장히 민감한 애플리케이션이기 때문에 PTP 기반의 시간 동기화를 위한 시스템/네트워크 아키텍처를 디자인 및 구축하였고, 장비 딜리버리 이슈 때문에 지연된 HA 구성 작업을 나중에 진행한 건이었다.
전체 아키텍처 디자인
네트워크 이중화 구성이 필요하였고, 특히 Failover 시에 애플리케이션 세션이 끊기면 안 된다는 요구사항이 있었다.
일반적인 L2 이중화를 위해 사용되는 STP는 RSTP를 적용하더라도 Failover Time이 5초 이상 소요되었기 때문에 STP-Free HA Topology가 필요했다.
이를 위해 LAG (Link Aggregation)을 적용하였고, 두 스위치 간 Loop-free 구성을 위한 MLAG와, 방화벽/클라이언트의 링크 이중화를 위한 LACP를 적용하였다.
Decision Points
-
어떤 장비를 사용할 것인가?
장비 도입 시에 MLAG 기반의 HA를 염두에 두고 있었고, PTP를 지원하는 Arista 스위치를 구매하였다.
방화벽의 경우 Fortigate를 구매하는 것이 결정되었고, Fortigate가 HA 구성을 지원하였기 때문에 문제가 되지 않았다. -
어느 수준까지 MLAG를 적용할 것인가?
Fortigate도 MC-LAG를 지원한다. 그렇기 때문에 이론적으로는 Active-Active 환경에서 MC-LAG를 통해 Fortigate 2대의 링크를 한번에 묶고, 그것을 Arista에서 받아서 구성할 수도 있을 것이다
하지만 이것은 두 가지 이유 때문에 반려되었다. 첫번째로 Fortigate HA는 두 장비 간 구성을 Sync하여 마치 하나의 장비인 것 처럼 보이게 만든다. 그러나 MC-LAG를 통해 두 대의 장비를 묶으려면 해당 장비들을 개별적으로 구성하여 Active-Active HA를 수동으로 구성해야 하고, 이것은 관리 편의성 측면에서 적절하지 않았다.
두번째는 Fortigate MC-LAG와 Arista MLAG 간의 호환성 관련 이슈 가능성이다. 표준화된 LAG 프로토콜인 LACP와 달리, MLAG는 벤더별로 서로 다른 프로토콜 구현체를 가지기 때문에 상호 운용성이 보장되지 않는다. 그래서 MLAG는 Arista에만 적용하고, 나머지 디바이스에는 LACP를 적용하였다. -
방화벽 HA 구성은 어떻게 적용할 것인가?
Fortigate HA는 Active-Active / Active-Standby 구성을 지원한다. 이번 프로젝트에서는 Bandwidth/Performance는 충분하였기 때문에, 관리 편의성이 좋고 구현 난이도가 상대적으로 낮은 Acrtive-Standby 구성을 선택하였다. -
Standby FW 전용 인터페이스를 적용할 것인가?
Fortigate HA를 적용하면 Secondary FW에는 개별적으로 접근할 수 없게 된다. 단, HA 구성 전에 Management interface를 예약해두면 해당 인터페이스를 통해 차후에 접근할 수 있으나, 방화벽의 가용 포트가 부족했기 때문에 해당 기능은 설정하지 않았다. 작업 완료 후 실제로 테스트를 진행해 보았으나, Secondary에 접근하지 못해서 불편한 점은 없었다.
구축 프로세스
다음과 같은 순서로 작업을 진행하였다.
- 디자인 리뷰
고객에게 네트워크 디자인을 도식으로 설명하고, 각각의 Design Decision 포인트들을 전달한 뒤 같이 토의하여 최종 디자인을 결정한다. - 적용 대상 시스템 선별
모든 시스템을 대상으로 HA를 적용하는 것이 아니었기 때문에, Failover 트리거 시에도 동작해야 하는 시스템들을 선별하고 LACP 구성을 위한 사전 조건을 만족하는지 확인한다. 만약 LACP를 구성할 수 없는 구성이라면 부품을 교체하여 구성 가능하게 한다. - 스위치 이중화 구성
Arista 스위치에서 MLAG를 구성하고, 클라이언트와의 LACP 구성이 정상적으로 동작하는지 검증한다. 이 때 클라이언트의 링크 절단, 스위치 장애 케이스를 모두 테스트 한다. - 방화벽 LACP 구성
HA를 적용하지 않은 상태에서 Fortigate FW - Arista 스위치 간의 LACP 구성이 정상적으로 동작하는지 검증한다. 이 때는 링크 절단 상황만을 테스트 한다. - 방화벽 HA 구성
방화벽에서 HA를 구성한 뒤, 방화벽 장애 시 정상적으로 Failover / Session sync가 이루어지는지 확인한다. MLAG 구성이 정상적으로 동작하는지 확인하기 위해 스위치 장애 상황도 한번 더 테스트한다.
Lessons and Learned
이번 일을 진행하면서 얻은 교훈들이다.
- Windows의 경우 Teaming 인터페이스는 IP 구성을 유지하지 않는다. 별도의 관리용 인터페이스를 사용하는 경우에는 문제가 없지만, Teaming 대상 인터페이스가 관리용 인터페이스라면 원격 연결이 불가능해 질 수 있기 때문에 주의가 필요하다
- FortiOS 7.x에서는 HA Failback이 기본적으로 활성화되어 있다. Failback을 끄려면 다음과 같은 명령어를 입력하여 설정을 변경해야 한다.
config system ha
set override disable마치며
일반적으로 Access layer까지 HA를 요구하는 경우가 많지 않기 때문에, 이번 작업은 상당히 도전적이고 흥미로운 일이었다. 이번 일을 통해 LAG에 대한 이해를 더 높이고, 표준 작업 프로세스를 수립할 수 있었다. 이 경험은 앞으로의 네트워크 프로젝트에도 도움이 될 것이다.
그리고 신뢰성 높은 MLAG 프로토콜을 구현해 준 Arista社 에 감사를 보낸다. 개인적으로 Arista는 정말 최고의 네트워크 장비 제조사라고 생각한다.
