오늘은 DR(재해복구) 구축 사례인 OO 공제회 구성에 대해 작성해보겠습니다.
요즘 데이터센터 자체의 장애가 온프레미스나 클라우드 할 것 없이 뉴스에 보도되고 있어서
재해복구가 화두가 되고 있습니다.
OO 공제회에서도 작년에 저희 솔루션을 이용하여 DR을 구축하였는데 관련 내용을 한 번 살펴 보겠습니다.
여기도 기존 단일 서버에 Windows Server 2016 Std 환경으로 서비스를 운영 중이었는데
주센터와 백업센터에 각각 서버를 두고 재해복구 환경으로 구축하는 것이 고객의 요구사항이었습니다.
그림으로 표현하면 아래와 같습니다.
화살표가 모양이 좀 그렇네요 ^^
주센터와 백업센터 간 거리는 직선 거리로는 40km, 차량 이동 거리로는 대략 최단 거리로 45km 정도
나오는 것 같습니다.
재해복구를 구성할 때 가장 중요한 사항으로는 아무래도 센터 간의 네트워크 대역폭입니다.
원격지 복제를 사용하는 솔루션 대부분이 네트워크 기반의 TCP/IP 통신을 사용하기 때문에 일정 대역폭이
보장이 되어야 어느 정도 성능을 낼 수 있습니다.
보통 복제 소프트웨어는 최소 100Mbps의 대역폭을 요구합니다. 그 이하로 갈 경우 네트워크 지연으로 인하여
복제 성능이 나오지 않습니다.
두 번째로는 재해복구를 구성할 서버의 디스크 볼륨의 사양과 윈도우의 경우 볼륨 레터, 리눅스의 경우 파티션이
가능한 같아야 합니다.
백업센터에 신규서버로 셋팅할 경우에는 기존 주센터 서버 기준으로 맞추면 되고 간혹 OS 버전이 안 맞을 경우에는
윈도우의 경우 2016부터 2025까지는 호환이 가능하고 윈도우 2012 R2의 경우에는 동일 버전으로 맞춰야 합니다.
리눅스의 경우에는 RHEL 8~9(CentOS, OEL, Rocky, Alma)까지 호환이 가능하고 RHEL 7(CentOS, OEL)의 경우에는
동일 버전으로 맞춰야 합니다.
참고로 여기는 백업센터의 서버 OS가 Windows Server 2022 Std 입니다.
복제 성능은 100Mbps 기준으로 1시간에 35GB 정도 Sync가 가능합니다.
이 사이트의 경우에는 일시적으로 야간에 대역폭을 올릴 수 있어서 300Mbps로 작업을 하였고 Sync가 끝난 후
100Mbps로 대역폭 제한을 하였습니다.
총 Sync할 DATA는 약 500GB 정도였고 약 6시간 정도 소요되었습니다.
Sync가 끝난 후 외부 서비스 차단 후 볼륨을 수동으로 전환하여 데이터 정상 여부 확인 후 다시 원래 서버로 볼륨을 전환하였고
재해복구 구성을 마쳤습니다.
이 고객사의 구성 환경을 정리하면 아래와 같습니다.(실제 이중화 솔루션에 등록되는 리소스의 종류 및 숫자)
[DB-Group]
r0(원격 복제 리소스) – 실제 장애 시 DR 서버에서 수동으로 볼륨 전환
디스크 볼륨에 대한 재해복구 구성이다보니 솔루션 내에서는 구성 내용이 단순합니다.
볼륨 위에 올라가는 APP의 시작, 종료는 별도의 스크립트를 통해서 자체적으로 처리합니다.
bat나 sh 파일을 만들어서 트리거를 거는 방식도 있습니다.
여기까지 OO 공제회의 구축 사례를 알아보았습니다.
실제 현장의 내용을 100% 담을 수 없는 점 양해 바라며 다음 구축 사례에서 뵙겠습니다.
오늘도 저희 글을 읽어 주셔서 감사합니다.
– 코아랩 드림 –