안녕하세요. 오픈소스컨설팅 조철진입니다.
지난 글에서는 3노드 HCI 환경에서 Masakari로 호스트 HA를 구현했습니다.이번에는 그보다 넓은 범위인 데이터센터 수준의 장애를 복구하기 위한 설계를 알아보려고 합니다.
이런 설계는 보통 Multi Region과 DR을 함께 언급하지만, 둘은 서로 다른 개념입니다.
Multi Region은 한 Region에 문제가 발생해도 다른 Region이 영향을 받지 않도록 자원을 격리하는 개념입니다. Region마다 API 엔드포인트와 컨트롤 플레인을 따로 두어, 한쪽의 장애가 다른 쪽으로 전파되지 않게 합니다.
DR은 문제가 발생한 Region의 데이터와 서비스를 정상 Region에서 동작하게 하는 일입니다. 그러려면 평상시에 데이터가 Region을 넘어 복제되어 있어야 하고, 장애 시 트래픽을 넘길 경로가 준비되어 있어야 합니다.
이번 글에서는 Multi Region에 DR을 고려한 아키텍처를 공유 드리려고 합니다.
이전 글 보러 가기 👉 OpenStack HCI 환경의 HA 구축기
Region은 독립된 API 엔드포인트와 컨트롤 플레인(DB, MQ 포함)을 갖는 OpenStack 세트입니다.
Region을 늘린다는 것은 Nova · Cinder · Neutron 등의 오픈스택 서비스들과 컨트롤 플레인을 한 세트 더 구축하여 그 엔드포인트를 Keystone 카탈로그에 새 Region 이름으로 등록한다는 뜻입니다.
공유하는 것은 Keystone과 Horizon뿐입니다.
AZ(Availability Zone)는 하나의 Region 안에서 호스트를 묶는 논리적 그룹입니다.
Nova, Neutron, Cinder에 별도 AZ를 설정할 수 있습니다. 세 서비스의 AZ를 일치 시키면 컴퓨트 · 볼륨 · 네트워크를 동일한 장애 도메인으로 묶을 수 있습니다.
완전한 격리의 대가로 운영 난이도는 올라갑니다. OpenStack에는 Region 간 리소스를 동기화 하는 기능이 없으므로 Flavor · 이미지 · 보안 그룹을 양쪽에 각각 만들어야 합니다. 이러한 부분은 IaC 도구를 통해 해결하는 것을 권장합니다.
엔드포인트 목록은 Keystone DB(service · region · endpoint 테이블)에 Region별로 저장되며, 클라이언트가 Region을 골라 해당 URL로 직접 호출합니다. 각 서비스는 받은 토큰을 Keystone에 검증하므로, Keystone을 양쪽 Region에 배포하고 Keystone DB 복제와 Fernet 키 동기화로 인증 상태를 맞춰 어느 Region에서 발급한 토큰이든 양쪽에서 동일하게 검증되도록 합니다.
Region은 장애를 격리해줄 뿐 자동으로 복구해주지는 않습니다. 퍼블릭 클라우드도 동일합니다. AWS에서 Region 하나가 죽으면 그 안의 인스턴스도 함께 죽으므로 다른 Region에 미리 준비해두어야 합니다.
Region 간에는 인스턴스를 넘겨받을 수단이 없습니다. 라이브 마이그레이션은 같은 컨트롤 플레인 안에서만 동작합니다. 따라서 Region 수준의 연속성은 애플리케이션을 양쪽 Region에 미리 배포해두는 이중화로 확보해야 합니다.
RPO (Recovery Point Objective) 허용 가능한 데이터 손실 범위
RTO (Recovery Time Objective) 장애 후 서비스 재개까지 걸리는 목표 시간
이 두 숫자가 비용을 결정합니다. RPO를 0에 가깝게 만들수록 동기 복제가 필요해져 회선과 지연 비용이 급증하고, RTO를 짧게 만들수록 반대편에 유휴 자원을 미리 세워둬야 합니다.
RPO와 RTO가 정해지면 선택지는 세 가지로 좁혀집니다.
Multi Region이 이미 구축된 상태를 가정하므로 패턴별로 달라지는 것은 RegionTwo의 인스턴스 상태와 데이터 복제 방식 두 가지입니다. 패턴을 OpenStack에 대입해보면 다음과 같은 방법들을 적용할 수 있습니다.
| 패턴 | RegionTwo | 데이터 복제 |
|---|---|---|
| Backup & Restore | 인스턴스 없음. 백업에서 복원 | cinder-backup |
| Warm Standby | 최소 대수 가동. 장애 시 스케일 업 | rbd-mirror |
| Active-Active | 동일 규모 가동. 트래픽 분산 | 애플리케이션/DB 복제 |
같은 데이터라도 어느 계층에서 복제하는지에 따라 복구 후 사용 가능한 상태가 달라집니다.
DB를 VM에 올려두고 스토리지 계층의 복제만 걸어두면 복구 시 정상 기동을 보장할 수 없습니다. 자체 복제 기능이 있는 것은 애플리케이션 계층 복제로, 없는 것만 스토리지 계층에서 처리합니다.
스토리지 계층 복제에는 Ceph의 rbd-mirror를 사용합니다. 두 Ceph 클러스터 사이에서 RBD 이미지를 비동기로 복제하므로, Cinder 백엔드가 Ceph이면 볼륨이 그대로 상대 Region으로 넘어갑니다. 비동기 방식이므로 상대 Region이 느려지거나 멈춰도 쓰기는 지연되지 않습니다.
Multi Region과 DR을 알아보았으니 이를 결합해 보겠습니다.
각 Region은 자기 컨트롤 플레인으로 독립 동작하고, Region을 통해 복제하는 것은 Ceph 볼륨 데이터와 Keystone DB, Keystone fernet 키입니다. Region 하나가 사라지면 GSLB가 트래픽을 남은 Region으로 보내고, 복제해둔 데이터로 서비스를 이어갑니다.
Region보다 작은 범위의 장애는 애플리케이션을 여러 AZ에 배치하여 완화합니다. 트래픽 진입점인 GSLB와 단일 진입점인 Horizon을 Region에 종속되지 않는 최상단에 두고, Keystone은 양쪽 Region에 배포해 인증을 이어갑니다.
| 상황 | 범위 | 대응 | 개입 |
|---|---|---|---|
| 디스크 · 노드 장애 | Region 내 | Ceph 복구 · Masakari | 자동 |
| AZ 상실 | Region 내 | 다른 AZ의 인스턴스가 처리 | 자동 |
| Region 전체 상실 | Region 간 | GSLB가 자동 제외 · 승격 | 수동 승격 |
지금까지 데이터센터 수준의 장애에 대응하기 위해 Multi Region과 DR을 OpenStack으로 구현할 수 있는 방안으로 설계해보았습니다.
물론 이 구조가 모든 환경에 맞는 정답은 아닙니다. Region을 하나 더 세우는 일 자체가 비용이고, 운영 리소스를 양쪽에서 관리해야 하는 부담도 따릅니다. 데이터센터가 하나 뿐이라면 AZ를 나누고 HA를 구성하는 것 만으로 충분한 경우도 많습니다.
다음에는 이번 글에서 다룬 구성의 구현을 더 자세히 다룰 수 있는 시간이 되었으면 좋겠습니다.
감사합니다.
