이번에 공부한 내용은 상용 고가용성 솔루션과 오픈소스 기반 고가용성 구성을 비교해보는 내용이다.
정리할 대상은 크게 두 가지다.
ftServerPacemaker + Corosync + DRBD
둘 다 서버 장애가 발생했을 때 서비스를 최대한 끊기지 않게 하기 위한 기술이다.
다만 접근 방식은 꽤 다르다.
ftServer는 고가용성을 제공하는 상용 서버 솔루션에 가깝고, Pacemaker + Corosync + DRBD는 리눅스 서버 위에 오픈소스 도구를 조합해서 직접 고가용성 클러스터를 구성하는 방식이다.
1. 먼저 HA가 뭔지 정리하기
HA(High Availability)는 고가용성을 의미한다.
쉽게 말하면 시스템에 장애가 발생하더라도 서비스가 계속 동작하도록 만드는 구조다.
서버 한 대에만 서비스를 올려두면 그 서버가 장애 났을 때 서비스도 같이 멈춘다.
그래서 중요한 서비스는 보통 서버를 두 대 이상 구성한다.
한 대에 문제가 생기면 다른 서버가 서비스를 이어받도록 만드는 것이다.
이때 핵심은 다음과 같다.
- 장애를 빠르게 감지해야 한다.
- 서비스가 다른 서버로 넘어가야 한다.
- 데이터가 유실되지 않아야 한다.
- 장애 상황에서도 중복 실행이나 데이터 충돌이 없어야 한다.
2. ftServer란?
ftServer는 Stratus에서 제공하는 상용 Fault Tolerant 서버 솔루션이다.
일반적인 HA 구성이 장애가 난 뒤 다른 서버로 서비스를 넘기는 방식이라면, ftServer는 하드웨어 자체를 이중화해서 장애를 견디는 방향에 가깝다.
즉, 서버 내부의 주요 구성 요소를 이중화해두고, 한쪽 부품에 문제가 생겨도 서비스는 계속 동작하도록 만든다.
쉽게 말하면 다음과 같다.
장애가 나도 멈추지 않도록 설계된 서버 완제품
ftServer는 CPU, 메모리, 디스크, 네트워크 같은 주요 하드웨어 구성 요소를 이중화하고, 운영체제나 애플리케이션 입장에서는 하나의 서버처럼 보이게 만든다.
그래서 사용자는 일반 서버를 쓰는 것처럼 애플리케이션을 올리면 된다.
복잡한 장애 조치 스크립트를 직접 작성하거나, 클러스터 리소스를 세밀하게 구성하는 부담이 상대적으로 적다.
3. ftServer의 장점
3.1 구성이 단순하다
ftServer는 상용 솔루션이기 때문에 하드웨어와 고가용성 기능이 통합되어 제공된다.
직접 클러스터를 설계하고 구성하는 방식보다 초기 구성 난이도가 낮다.
운영체제나 애플리케이션 입장에서는 하나의 서버처럼 보이기 때문에, 기존 애플리케이션을 크게 수정하지 않고 사용할 수 있는 경우가 많다.
3.2 장애 대응이 빠르다
ftServer는 장애가 발생했을 때 다른 서버로 서비스를 넘기는 방식보다, 장애를 견디면서 계속 동작하는 구조에 가깝다.
일반적인 Active-Standby 클러스터는 장애 감지, 리소스 정리, 서비스 이동, IP 이동 같은 절차가 필요하다.
반면 ftServer는 하드웨어 이중화 구조를 통해 서비스 중단 시간을 최소화하는 것을 목표로 한다.
3.3 벤더 지원을 받을 수 있다
상용 솔루션이기 때문에 문제가 생겼을 때 벤더의 기술 지원을 받을 수 있다.
운영 인력이 HA 클러스터를 깊게 이해하지 못하더라도, 제품 문서와 벤더 지원을 기반으로 운영할 수 있다는 점이 장점이다.
4. ftServer의 단점
4.1 비용이 높다
가장 큰 단점은 비용이다.
하드웨어와 고가용성 기능이 통합된 상용 제품이기 때문에 일반 서버를 구매하는 것보다 비용이 높을 수 있다.
초기 도입 비용뿐만 아니라 유지보수 비용도 함께 고려해야 한다.
4.2 특정 벤더에 의존하게 된다
ftServer는 특정 벤더의 하드웨어와 기술에 의존하는 구조다.
장비 확장, 부품 교체, 장애 대응, 기술 지원 등이 벤더 정책에 영향을 받을 수 있다.
그래서 자유롭게 하드웨어를 선택하거나 구성 방식을 바꾸고 싶은 환경에서는 제약이 될 수 있다.
4.3 유연성은 상대적으로 낮다
ftServer는 완성도 높은 상용 솔루션이라는 장점이 있지만, 그만큼 사용자가 내부 구조를 자유롭게 바꾸기는 어렵다.
특정 서비스에 맞춰 세밀하게 클러스터 정책을 구성하거나, 여러 오픈소스 도구를 조합해 원하는 구조를 만드는 데에는 오픈소스 방식보다 유연성이 떨어질 수 있다.
5. Pacemaker + Corosync + DRBD란?
Pacemaker + Corosync + DRBD는 오픈소스 기반으로 HA 클러스터를 구성할 때 자주 사용되는 조합이다.
각 도구의 역할은 다르다.
| 구성 요소 | 역할 |
|---|---|
| Pacemaker | 클러스터 리소스 관리 |
| Corosync | 클러스터 노드 간 통신과 멤버십 관리 |
| DRBD | 서버 간 블록 디바이스 데이터 복제 |
이 조합은 보통 두 대 이상의 리눅스 서버를 묶어 구성한다.
예를 들어 서버 A와 서버 B가 있다고 가정해보자.
평상시에는 서버 A가 서비스를 제공하고, 서버 B는 대기한다.
서버 A에 장애가 발생하면 Pacemaker가 이를 감지하고 서버 B에서 서비스를 시작한다.
이때 DRBD는 서버 A와 서버 B의 디스크 데이터를 복제해서, 장애가 발생해도 대기 서버가 같은 데이터를 사용할 수 있도록 도와준다.
6. 각 구성 요소 역할
6.1 Pacemaker
Pacemaker는 HA 클러스터의 리소스 관리자다.
서비스, 가상 IP, 파일 시스템, 데이터베이스 같은 리소스를 어느 노드에서 실행할지 결정한다.
또 장애가 발생했을 때 해당 리소스를 다른 노드로 이동시키는 역할도 한다.
예를 들어 웹 서버를 HA로 구성했다면 Pacemaker는 다음과 같은 일을 한다.
- 웹 서비스가 정상 동작하는지 확인
- 장애 발생 시 대기 노드에서 웹 서비스 실행
- 가상 IP를 장애 조치 대상 노드로 이동
- 리소스 실행 순서와 위치 제어
즉, Pacemaker는 클러스터 안에서 "무엇을 어디서 실행할지"를 판단하는 역할을 한다.
6.2 Corosync
Corosync는 클러스터 노드끼리 서로 상태를 확인할 수 있도록 해주는 통신 계층이다.
각 노드는 Corosync를 통해 다른 노드가 살아 있는지, 클러스터에 참여 중인지 확인한다.
Pacemaker는 이 정보를 바탕으로 장애 여부를 판단하고 리소스를 이동시킨다.
쉽게 말하면 Corosync는 노드 간 연락망 역할을 한다.
6.3 DRBD
DRBD(Distributed Replicated Block Device)는 서버 간 디스크 데이터를 복제하는 기술이다.
네트워크를 통해 한 서버의 블록 디바이스 데이터를 다른 서버로 복제한다.
구조만 보면 네트워크를 이용한 RAID 1처럼 이해할 수 있다.
예를 들어 서버 A에 데이터가 기록되면 DRBD가 그 데이터를 서버 B에도 복제한다.
그래서 서버 A에 장애가 발생해도 서버 B가 같은 데이터를 기반으로 서비스를 이어받을 수 있다.
7. Pacemaker + Corosync + DRBD의 장점
7.1 비용을 줄일 수 있다
이 방식은 오픈소스 도구를 조합해서 구성하기 때문에 상용 전용 장비를 도입하는 것보다 비용을 줄일 수 있다.
물론 운영 인력의 기술 역량과 구축 시간이 필요하므로 완전히 공짜라고 보기는 어렵다.
그래도 라이선스나 전용 하드웨어 비용 측면에서는 장점이 있다.
7.2 유연하게 구성할 수 있다
오픈소스 기반이기 때문에 원하는 구조에 맞게 세밀하게 구성할 수 있다.
서비스 종류, 장애 조치 방식, 리소스 순서, 노드 우선순위 등을 직접 설정할 수 있다.
환경에 따라 Active-Standby 구조나 일부 Active-Active 구조도 설계할 수 있다.
7.3 일반 서버로도 구성할 수 있다
특정 전용 장비가 아니어도 리눅스 서버를 이용해 HA 구성을 만들 수 있다.
기존에 사용하던 서버를 활용하거나, 비용에 맞는 하드웨어를 선택할 수 있다는 점도 장점이다.
8. Pacemaker + Corosync + DRBD의 단점
8.1 구축 난이도가 높다
오픈소스 조합은 자유도가 높은 만큼 직접 이해하고 설정해야 할 부분이 많다.
Pacemaker 리소스 설정, Corosync 통신 설정, DRBD 복제 설정, 파일 시스템 마운트 순서, 가상 IP 이동 등을 모두 고려해야 한다.
잘못 구성하면 장애 상황에서 서비스가 제대로 넘어가지 않거나, 더 심하면 데이터가 손상될 수도 있다.
8.2 운영 난이도가 높다
구축보다 더 어려운 것은 운영이다.
장애가 발생했을 때 로그를 보고 원인을 파악해야 하고, 클러스터 상태도 직접 확인해야 한다.
또 패키지 업데이트나 커널 업데이트를 할 때도 Pacemaker, Corosync, DRBD 간 호환성을 고려해야 한다.
운영자가 구조를 잘 모르면 장애 상황에서 복구가 늦어질 수 있다.
8.3 Split-brain 문제가 발생할 수 있다
DRBD를 사용할 때 특히 주의해야 하는 문제가 Split-brain이다.
Split-brain은 두 노드가 서로 상대방이 죽었다고 판단하고, 각자 Primary처럼 동작하는 상황을 말한다.
이렇게 되면 양쪽에서 데이터가 따로 변경되어 데이터 불일치가 발생할 수 있다.
그래서 fencing, quorum, STONITH 같은 장치가 중요하다.
장애가 난 노드를 확실히 격리하지 않으면 HA 구성이 오히려 데이터 정합성을 해칠 수 있다.
9. 두 방식 비교
| 구분 | ftServer | Pacemaker + Corosync + DRBD |
|---|---|---|
| 유형 | 상용 고가용성 서버 솔루션 | 오픈소스 HA 클러스터 구성 |
| 접근 방식 | 하드웨어 이중화 중심 | 소프트웨어 클러스터 중심 |
| 구성 난이도 | 낮은 편 | 높은 편 |
| 운영 난이도 | 비교적 낮은 편 | 높은 편 |
| 초기 비용 | 높음 | 상대적으로 낮음 |
| 유연성 | 제품 구조에 따라 제한 | 높음 |
| 장애 대응 | 장애를 견디는 구조에 가까움 | 장애 감지 후 다른 노드로 서비스 이동 |
| 데이터 복제 | 제품 구조에 따라 제공 | DRBD로 블록 디바이스 복제 |
| 벤더 지원 | 가능 | 직접 운영하거나 별도 지원 계약 필요 |
| 적합한 환경 | 높은 안정성이 필요하고 운영 부담을 줄이고 싶은 환경 | 비용을 줄이면서 직접 HA를 설계하고 운영할 수 있는 환경 |
10. 장애 처리 흐름 비교
ftServer
ftServer는 서버 내부 구성 요소가 이중화되어 있다.
장애가 발생하면 사용자가 직접 서비스를 넘기는 것이 아니라, 장비 내부 구조에서 장애를 처리한다.
운영체제와 애플리케이션은 하나의 서버에서 계속 실행되는 것처럼 동작한다.
흐름을 단순화하면 다음과 같다.
하드웨어 장애 발생
-> ftServer 내부에서 장애 감지
-> 이중화된 구성 요소로 계속 동작
-> 서비스 중단 최소화Pacemaker + Corosync + DRBD
오픈소스 HA 구성은 장애를 감지한 뒤 서비스를 다른 노드로 이동시키는 방식이다.
흐름은 다음과 같다.
Active 노드 장애 발생
-> Corosync가 노드 상태 변화 감지
-> Pacemaker가 리소스 이동 결정
-> DRBD 대기 노드가 Primary 역할 수행
-> 파일 시스템 마운트
-> 가상 IP 이동
-> 서비스 시작이 과정이 정상적으로 동작하려면 리소스 순서와 의존성이 정확히 설정되어 있어야 한다.
11. 어떤 방식을 선택해야 할까?
ftServer는 돈을 더 쓰더라도 안정성과 운영 편의성을 얻고 싶은 환경에 어울린다.
예를 들어 제조, 금융, 병원, 공공 시스템처럼 장애 시간이 곧 큰 손실로 이어지는 환경에서는 상용 솔루션이 더 적합할 수 있다.
운영 인력이 많지 않거나 HA 클러스터를 직접 운영하기 어려운 경우에도 ftServer 같은 제품이 장점이 있다.
반면 Pacemaker + Corosync + DRBD는 비용을 줄이면서 직접 고가용성 구조를 만들고 싶은 환경에 적합하다.
리눅스와 클러스터 운영 경험이 있고, 장애 테스트와 운영 절차를 충분히 준비할 수 있다면 좋은 선택이 될 수 있다.
다만 이 방식은 구축 후에도 꾸준한 관리가 필요하다.
특히 split-brain 방지, fencing 구성, 장애 조치 테스트는 반드시 챙겨야 한다.
정리
이번 내용의 핵심은 "상용 솔루션이 좋은가, 오픈소스가 좋은가"를 단순히 고르는 것이 아니다.
중요한 건 운영 환경에 맞는 방식을 선택하는 것이다.
ftServer는 비용이 높지만 구성이 단순하고 안정적인 운영을 기대할 수 있다.
Pacemaker + Corosync + DRBD는 비용과 유연성 면에서 장점이 있지만, 그만큼 구축과 운영 난이도가 높다.
따라서 중요한 서비스라면 다음 질문을 먼저 해봐야 한다.
- 서비스 중단을 어느 정도까지 허용할 수 있는가?
- 장애 발생 시 데이터 유실을 허용할 수 있는가?
- HA 클러스터를 직접 운영할 역량이 있는가?
- 초기 비용과 운영 비용 중 무엇이 더 중요한가?
- 장애 테스트를 정기적으로 수행할 수 있는가?
개인적으로는 이렇게 정리할 수 있을 것 같다.
ftServer는 안정성을 제품으로 구매하는 방식이고,
Pacemaker + Corosync + DRBD는 안정성을 직접 설계하고 운영하는 방식이다.
둘 다 고가용성을 위한 기술이지만, 책임을 어디에 둘 것인지가 다르다.
ftServer는 벤더와 제품에 더 많이 의존하고, 오픈소스 조합은 운영자의 설계와 관리 역량에 더 많이 의존한다.
그래서 실제 환경에서는 기술 자체보다 운영 역량, 예산, 장애 허용 범위까지 함께 보고 선택해야 한다.
