[수제] Ha 솔루션을 활용한 이중화 구축 후기 + 잡설

[수제] Ha 솔루션을 활용한 이중화 구축 후기 + 잡설
Photo by Paul Hanaoka / Unsplash

작성 동기

회사의 클라우드 기반 SAAS 제품을 온프레미스로도 제공하고자 하는 수요가 있어서, 어쩔수없이 해당 작업을 진행하게 되었다. 어쩔 수 없이라고는 했지만 Cloud 기반에서 온프레미스 기반으로 전환하면 여러가지로 이점이 많다.

보안적인 측면에서도 강화되는 부분이 있고(밖으로 안 나가니까), 기업/기관의 민감한 정보를 직접 그들의 내부망에서 나가지 않아도 되는 장점도 있다. 또한 온프레미스로 계약할 경우 보통 월간 비용이 아니라 몇년치 금액을 처음 한번에 받기 때문에 금전적 이득도 있다. 물론 그것에 대한 반대급부로 이런저런 힘든 점이 있는데, 여기서는 굳이 언급하지 않을 것이다.

Cloud 기반을 온프레미스로 옮기는 부분도 작성할 게 많지만, 이번에는 이미 1대의 베어메탈 서버에서 완전히 서비스 운영이 가능한 상태가 되어 있다고 가정하고 작성할 것이다.

그동안 1번도 해본적이 없는 작업이었기 때문에 굉장히 시행착오가 많았는데, 이 글을 보는 비슷한 작업 담당자들과 미래의 나를 위해 기록을 남긴다. 그동안 클라우드 상에서 편하게 개발해왔는데 이번에 이 작업을 하며 꽤나 여러 가지를 배울 수 있었던 거 같다.

사실 요즘 AI한테 물어보면 정말 거의 다 나와서 이걸 작성하는 게 의미가 있나 싶지만 (나도 작업을 하면서 AI의 도움을 많이 받았다) 그래도 다른 점은 나는 직접 이걸 해봤다는 것이다. Certified라는 것이다.

대상 독자

  • 이중화 솔루션을 통해 onPremise 서버의 안정성을 높여야 하는 개발자
  • SaaS를 OnPremise 기반으로 이전해야 하는 개발자

결과물 구성도

아래는 현재 구축되어 있는 이중화 서버의 구성도이다.

할 때는 엄청 고생했는데 하고 보니 왜 이렇게 없어보이지? 나중에 생각나는 요소 있으면 추가해야되겠다.

구성도의 내용을 설명하자면 아래와 같다.

  • PC1과 2는 랜선으로 직접 연결되어 있으며, 이 선으로 heartbeat 확인 및 데이터 복제가 이루어진다. (혹은 분산을 위해 하트비트용 랜선과 데이터복제용 랜선을 분리할 수 있다.)
    • 하트비트용은 상관없지만 데이터복제용 랜선의 경우 SSD 복제 & 데이터 변경량이 많을 경우 이를 따라가려면 1Gbps로는 부족할 수 있어 10Gbps를 권장한다.
  • 액티브 - 스탠바이 구성이다. 쉽게 말해 평소에는 액티브 pc가 외부의 요청을 전부 처리해주고, 스탠바이 pc는 대기 상태로 있다가 액티브 pc에 장애가 발생하면 즉시 서비스를 이어받는다. 스탠바이에서의 프로그램이 꺼져있다가 켜지는 시간이 걸려가지고 다운타임이 한 2-3분정도 걸리긴 한다.. 이건 내가 이중화를 도커 컴포즈로 하고 순서를 지키다 보니 시간이 좀 더 걸린거고 개별 프로세스별로 이중화한다면 병렬 시작이 되니까 훨씬 빠르게 전환될 것이다. 어쨌든 일반 사용자는 1대의 pc가 고장나더라도 문제없이 서비스를 계속 이용할 수 있는 것이다. 이것이 이중화의 핵심 목적이다. 그리고 이런 최소한의 안정성 보장 없이는 b2b 기업/기관에 납품하기란 거의 불가능하다. 그러니까 pc 1대로는 안된단 이야기이다.
  • pc1,2 모두 내부망 안의 private ip를 가지고 있으며, 외부에서는 VIP(Virtual ip)로만 접근한다. VIP 할당 맟 전환은 HA 솔루션이 알아서 해준다.
  • 두 PC는 동일한 디스크 내용을 공유한다. (즉, 둘 다 같은 데이터를 가지고 있음) : ssd, hdd
  • 두 PC 모두 켜져 있으며, 액티브 pc는 서비스를 제공하고, 스탠바이 pc는 대기 상태이다. (즉 서버 애플리케이션이 꺼져있음)

주요 기술 스택

  • docker compose, nginx, mysql, python (app server)

일반적으로 이중화를 구축할 경우 보통 프로그램별로 이중화를 한다. ex) mysql 프로세스 이중화, nginx 이중화를 각각 하는 개념. 그치만 나는 도커 컴포즈로 전체 서비스를 묶어서 이중화를 시도해보았다. (즉, 도커 컴포즈 단위로 이중화) 그 이유는 다음과 같다.

  1. 여러 서비스들의 개별 설정을 포함해서 1개의 문서에 정의할 수 있고, 커맨드 한줄로 전체 앱을 시작/종료할 수 있기 때문에 관리가 편하다. 이 관리가 편한 점은 구축 이후에 고객사의 담당자들 입장에서도 매우 편할 것이다. ㅎㅎ
  2. 각 프로세스별로 실행 순서가 있다. 예를 들어 Mysql이 켜지기 전에 그 mysql에 의존하는 앱 애플리케이션이 켜지면 오류가 난다. 물론 이중화 솔루션에서도 순서를 지정할 수 있다. 근데 도커 컴포즈 단위로 이중화를 하면 도커 컴포즈가 알아서 실행 순서를 맞춰주기 때문에 훨씬 편하다. + 서비스별 하트비트 개별설정도 덤
  3. 로컬 개발과의 연동성 : 나는 온프렘 작업 하기 전에도 클라우드용 서버 개발을 도커 컴포즈로 진행해왔기 때문에, 온프렘 환경에서도 동일한 도커 컴포즈 파일을 사용할 수 있었다. 즉, 로컬 개발 환경과 온프렘 환경에서 동일한 도커 컴포즈 파일을 사용함으로써 개발과 배포의 일관성을 유지할 수 있었다. 재사용할 수 있는 부분도 굉장히 많았다. 난 뭐든지 내가 쉽게 이해할 수 있는 수준의 최대한 심플하게 하는 것이 좋다 ...

다만 연동해보니 이중화 솔루션 업체 (HA) 직원도 도커 컴포즈로 하는 건 경험이 없어 보였다. 그래서 내가 마무리를 해야 했다.


연동 작업 과정

2대의 PC 준비

HA 솔루션은 아무것도 준비가 안된 상태에서 직원이 온다고 자동으로 되는 것이 아니다. 단일 서버에서 모든 기능이 정상 상태로 구동되도록 구현이 완료되어야 그제야 이중화 구축 시작이 가능하다. 여기서는 이미 1대를 완벽히 구현했다고 가정하고 진행한다. 일단 1대의 pc에서 서비스 정상동작이 확인되면, 그 pc와 똑같은 세팅의 2번째 노드를 구성해야 한다. 이 때는 클론질라라는 툴을 추천한다. 나중에 클론질라 사용법에 대해서도 작성할 것이다. 간단하게 말하면 클론질라는 첫번째 pc의 모든 것을 복사해오며, 이후 구분을 위해 2번째 pc의 이런저런 정보만 바꿔주면 정말 거의 똑같은 2번째 pc를 얻을 수 있다. 서버 간의 사양 차이는 나도 된다. 다만 디스크 파티션은 완전히 동일해야 한다. 만약 물리 디스크의 차이가 날 경우 파티션을 만들 때 디스크가 작은 쪽에 큰 쪽이 맞춰야 하는 것이다. 사실 2대의 pc와 ha 업체에서 미리 요청하는 사항만 잘 세팅해두면, 나머지는 ha 업체 직원이 방문 혹은 원격으로 거의 대부분 해주기 때문에, 이 문서에서는 이중화 작업을 하면서 겪었던 여러 트러블 슈팅에 대해서 이야기해 보겠다.

VIP, 데이터 싱크

그리고 미리 지정을 해둬야 하는 게 있었는데, 이중화의 핵심인 vip에 쓸 ip를 선정해야 했고, 이는 내부망에서 안쓰는 ip 하나를 찾아서 ping으로 확인 후 배정했다. 또한 2대의 pc를 물리적으로 랜선으로 연결해야 했다. 서버용이 아닌 일반 pc 2대로 테스트하는 거였어서 랜포트가 1개씩밖에 없었고, 그래서 usb 랜카드를 2개 구매해 2대의 pc를 랜선으로 연결했다. 이 선을 통해서 두대의 pc는 ha 의 heartbeat와 데이터 싱크를 진행하게 될 것이다. (실제 고객사 배포 시에는 안정성을 위해 2개의 선을 각각 사용하는 것을 추천한다) 그리고 2대의 pc가 한대처럼 움직이려면 핵심은 데이터를 싱크하는 것이다. 데이터 싱크 방식은 나는 복제 방식을 선택했다. san 방식은 따로 장비가 또 있어야되니까 귀찮..

테스트용 논리 디스크 : 루프백

이중화의 핵심 중 하나는 디스크 동기화이니, 각 PC에 동일한 디스크 파티션을 만들어야 한다. 이 때 굳이 새로운 하드디스크 같은 걸 살 필요 없고, 테스트용이라면 리눅스 루프백을 만들어서 그걸 논리 디스크로 사용해도 테스트용으로는 아무 문제가 없다. 다만 리눅스 루프백은 일반 디스크와 달리 파티션 구축 후 작업해줘야 하는 게 있다. (재부팅 시 연결이 끊기는 것을 방지하기 위함)

+@ (260120)

보니까 HA 업체에서 루프백은 LV 대비 문제가 있을수도 있다고 한다. 그럴 경우 LV에서 떼서 사용하면 된다. (아직 파티션 할당이 되지 않은 공간이 있는 경우. 없다면 파티션 크기를 조정 후에 해야 함)

sudo lvcreate -n newdata1 -L 10G ubuntu-vg
sudo lvcreate -n newdata2 -L 10G ubuntu-vg
sudo mkfs.ext4 /dev/ubuntu-vg/newdata1
sudo mkfs.ext4 /dev/ubuntu-vg/newdata2

HA 솔루션에서 프로세스별 실행 순서에 대해

컴포즈로 구동되는 서비스들의 실행순서는 컴포즈 파일에서 제어할 수 있기에 여기서는 제외한다. 여기서는 전체적인 실행순서에 대해 이야기할 것이다. 사실 그렇게 얘기할 게 많지는 않다. 아래처럼 하면 된다.

  • 시작 시 : 1) VIP 설정 -> 2) DRBD 연결 -> 3) 도커 컴포즈 실행
  • 중지 시 : 1) 도커 컴포즈 중지 -> 2) DRBD 해제 -> 3) VIP 해제

예를 들어 drbd 연결 전에 도커 컴포즈를 실행해 버리면 컨테이너의 디스크가 마운트되기 전에 컨테이너가 실행되어 빈 폴더에서 구동되는 상황 등 문제가 발생할 수 있다. 따라서 반드시 위 순서를 지켜야 한다. 위 순서는 ha 솔루션의 관리페이지에서 순서를 지정할 수 있다.

IP에 대해

이중화 솔루션 구축 시 필요한 최소 ip는 5개이다. 괄호는 예시.
1. VIP (192.168.0.3)
2. 노드 A의 private IP (192.168.0.1)
3. 노드 B의 private IP (192.168.0.2)
4. 노드 A의 직접연결선의 IP (10.10.10.1)
5. 노드 B의 직접연결선의 IP (10.10.10.2)

만약 핫빗과 안정성을 분리하기 위해 직접연결을 2개의 랜선으로 한다면, 각각의 랜선에 대해 별도의 IP가 필요하다. 즉 직접연결선이 2개라면 총 7개의 IP가 필요하다.

작업하면서 궁금했던 점들의 셀프 QnA

  1. 이중화 솔루션으로 이중화를 하면 100% 장애가 없을까? : 그렇지 않다. 액티브 노드가 문제가 발생할 경우 스탠바이 노드가 이를 감지하고 액티브로 승격하는데, 이 과정에서 약간의 다운타임이 발생할 수 있다. 길면 한 2-3분 정도?
  2. 동기화 대상 폴더에 대해 미리 마운트를 해야 할까? : 아니다. DRBD가 알아서 해준다. DRBD 연결 전에 마운트가 되어 있으면 안된다. 그러니까 직접마운트 하지말란 말이다.
  3. RAID 구성은 어떻게 할까? 이중화를 하더라도 RaID 구성은 하는 것이 좋다. 서버 업체에서 우리가 요청하면 하드웨어 RAID 디스크를 구성해서 준다.

설치 후 솔루션 테스트

HA 솔루션은 구동 후에 아래의 테스트를 거치면 된다.

  1. 액티브 노드에서 스탠바이로의 운영서버 전환 테스트 : 잘꺼지고, 잘 켜지는가? vip로 접속 시 문제 없는가?
  2. 액티브 노드를 poweroff : 스탠바이 노드가 잘 액티브로 전환되는가?
  3. 스탠바이 노드를 poweroff : 액티브 노드가 문제 없이 계속 서비스하는가?
  4. 액티브노드 상태일때 작성한 데이터가 스탠바이 노드로 넘어간 후에도 잘 싱크가 되는가?
참고사항 : 두 pc 간의 데이터 싱크는 실시간으로 이루어지지만, 액티브 PC의 동기화 폴더에서 파일을 만든다고 해서 스탠바이 PC에서 그 파일이 바로 생기지 않는다. 스탠바이 PC에 생기려면 스탠바이 PC가 액티브 PC가 되어야 한다. 즉 마운트가 되어야 한다. 나는 그걸 몰라서 파일 만들어보고 왜 싱크 안되지 해서 다시 직원분을 불렀다는…

기타 잡설

HA 솔루션 업체는 어디로?

국내에서 유지보수 편하게 받고 하려면 국내업체가 좋다. 일단 맨텍사 제품이 국내에선 가장 유명하고, SM인포메이션 등의 업체도 HA 솔루션을 판매하고 있다. 이외에도 해외 업체의 HA 솔루션을 국내에서 총판 개념으로 팔고 있는 업체도 여럿 있다. 얘기를 들어보니까 국내의 HA 업체들도 해외 업체 제품을 팔다가 직접 만들어보자 해서 지금까지 하고 있다고 한다. 뭐 국내에서 해외 제품보다는 국내 제품의 파이가 커지는 것이 좋으니 긍정적으로 보고 있다.

일하면서 좀 더 생각나는 내용 있으면 또 추가할 예정.

Read more

[잡설] DNS에 대해 ,, 이런저런 ,,

DNS는 Domain Name System. 도메인 주소 (parkchisu.com) 을 넣으면 거기에 맞는 IP(32.132.12.123)를 리턴하는 시스템이다. 당연히 이런 기초정보를 공부하기 위해 쓰는 건 아니고.. 이번에 작업하면서 약간 헷갈렸던 부분이 있어 관련 내용을 공유한다. 회사의 내부망에서도 자체 DNS 서버를 운영할 일이 생긴다. 예를 들어 사내망에서만 접속할 수

By Park Chisu
k8s pod 자원 배분에 대해 ..

k8s pod 자원 배분에 대해 ..

k8s는 안다고 생각했는데 알고보니 몰랐던 것들이 계속 나온다 .. 이번엔 가장 기본적인 파드 자원 분배에 관한 이런 저런 얘기를 써놓을 예정 .. 계속 추가 예정 ,, 일단 기본적인 개념은 Request, Limit 일 것이다. * Request : 파드가 노드 안에서 "나는 이만큼 노드의 자원을 쓸 것이다" 라고 선언해두는 값. CPU의 경우 100m 이런식으로 정의할

By Park Chisu
[문제 해결] Docker compose 환경에서 keycloak 연결 이슈

[문제 해결] Docker compose 환경에서 keycloak 연결 이슈

문제 상황 도커 컴포즈로 keycloak 컨테이너와 그 컨테이너에 연결할 내 앱 서버를 작성했는데, 이상하게 처음 startup할 때 keycloak 연결 에러가 났다. 사실 연결 오류로 실패할 경우 자동으로 재시작하면 문제없이 동작하기에 그냥 넘어가도 됐지만… 계속 신경이 쓰여서 해당 에러를 제거하고자 했다. 서버 시작할 때마다 에러 메시지 뜨면 괜히 신경쓰이니 … keycloak.exceptions.

By Park Chisu
[리눅스] 외부인용 임시 계정 발급하기

[리눅스] 외부인용 임시 계정 발급하기

업무를 하다보면 리눅스 서버에 외부인의 연결을 허용해야 할 때가 있다. 특정 프로그램 설치라던지.. 그 때는 그 담당 직원 전용 계정을 만들어서 전달해야 한다. 여기서는 Ubuntu 24.04를 기준으로 작성한다. 계정 발급 타사 직원용 계정(예: external_vendor)을 생성합니다. # 계정 생성 (홈 디렉토리 포함) sudo useradd -m -s /bin/bash

By Park Chisu