고가용성 아키텍처

Red Hat OpenShift on IBM Cloud 아키텍처는 지역, 구역, 클러스터 수준에서 높은 가용성을 제공합니다.

사용 가능한 지역

모든 지역은 지역별 API 엔드포인트에서 액세스할 수 있는 고가용성 로드 밸런서로 설정됩니다. 로드 밸런서는 수신 및 발신 요청을 지역의 구역에 있는 클러스터로 라우팅합니다. 전체 지역 실패의 가능성은 낮습니다. 그러나 이 실패에 대해 설명하려는 경우 여러 지역에 다중 클러스터를 설정하고 외부 로드 밸런서를 사용하여 이를 연결할 수 있습니다. 전체 리전에 장애가 발생하면 다른 리전에 있는 클러스터가 워크로드를 이어받을 수 있습니다.

클러스터 및 존 가용성

구역 실패는 모든 실제 컴퓨팅 호스트 및 NFS 스토리지에 영향을 줍니다. 실패에는 전원, 냉각, 네트워킹 또는 가동 중단 및 자연 재해(예: 홍수, 지진 및 허리케인)가 포함됩니다. 구역 실패로부터 보호하려면 외부 로드 밸런서에 의해 로드 밸런싱된 2개의 서로 다른 구역에서 클러스터를 보유해야 합니다. 다중 영역 위치에서 클러스터를 만들어 마스터를 여러 영역에 분산시킵니다. 또는 다른 구역에 두 번째 클러스터를 설정하는 것을 고려해 보십시오.

다중 구역 사용 가능 여부

멀티존 클러스터는 여러 작업자 노드와 존에 걸쳐 작업량을 분산함으로써 존 장애에 대한 추가적인 보호 기능을 제공합니다. 작업자 노드는 여러 구역에 걸쳐 세 개의 복제본과 함께 자동으로 배치됩니다. 전체 구역에서 중단이 발생하면, 작업 부하가 다른 구역의 작업자 노드로 배정되어 중단으로부터 앱을 보호합니다.

글로벌 로드 밸런싱

마스터 장애로부터 앱을 보호하거나 지원되는 다중 영역 중 하나에 있어야 하는 클래식 클러스터의 경우, 지역 내 여러 영역에 여러 클러스터를 생성하고 글로벌 로드 밸런서와 연결할 수 있습니다.

고가용성을 위한 자원 분배.

다중 작업자 노드, 구역 및 클러스터 간에 앱을 분배하면 사용자에게 작동 중지 시간이 발생할 가능성이 낮아질 수 있습니다. 로드 밸런싱 및 격리 등의 기본 제공 기능을 사용하면 호스트, 네트워크 또는 앱에서 잠재적 장애가 발생할 때 복원성이 높아집니다. 가용도의 증가 순으로 정렬된 다음의 잠재적 클러스터 설정을 검토하십시오. IBM Cloud 의 자원이 지리적 구역과 지역에 어떻게 분배되는지에 대한 자세한 정보는 위치 문서를 참고하시기 바랍니다.

단일 구역 클러스터

클래식 전용

단일 영역 클러스터에는 동일한 영역 내의 개별 물리적 호스트에 분산된 작업자 노드가 있습니다. 이 옵션은 마스터 업데이트와 같은 특정 중단 사태를 방지하고 관리가 더 간단합니다. 그러나 전체 구역에서 중단이 발생하면 앱을 보호하지 못합니다.

다중 구역 클러스터

클래식 VPC

다중 영역 클러스터는 여러 영역에 걸쳐 세 개의 복제본이 자동으로 배포된 작업자 노드를 포함합니다. 전체 구역에서 중단이 발생하면, 작업 부하가 다른 구역의 작업자 노드로 배정되어 중단으로부터 앱을 보호합니다.

로드 밸런서와 연결된 여러 클러스터

클래식 VPC

동일한 영역 또는 다른 영역에 여러 클러스터를 설정하고 글로벌 로드 밸런서를 통해 연결할 수 있습니다. 이 옵션은 단일 존 지역에 클러스터를 프로비저닝해야 하지만, 다중 존 가용성의 이점을 누리고 싶은 경우에 유용합니다.

높은 가용성 기능

앱과 서비스의 가용성을 높이기 위해 사용할 수 있는 기능을 검토하십시오.

재해 복구 기능

재해 복구를 위한 일반적인 전략은 Portworx 와 같은 솔루션을 사용하여 데이터의 저장 및 백업을 구성하는 것입니다.

Red Hat OpenShift on IBM Cloud 는 다음과 같은 재해 복구 기능을 지원합니다:

rclone 또는 OADP 과 같은 데이터 내보내기를 위한 추가 옵션을 검토합니다.

복구 시간 목표(RTO)와 복구 지점 목표(RPO)

IBM® 가 재해 복구를 어떻게 지원하는가

IBM® 재해 발생 시 특정 복구 조치( Red Hat OpenShift on IBM Cloud )를 취합니다.

IBM 가 서비스를 유지하는 방법

모든 업그레이드는 복구 계획과 롤백 과정을 포함한 IBM 서비스의 모범 사례를 따릅니다. 정기적인 유지보수는 짧은 중단 시간을 유발할 수 있지만, 클라이언트 가용성 재시도 로직 으로 완화할 수 있습니다. 변경 사항은 지역별로, 지역 내의 구역별로 순차적으로 적용됩니다. IBM 는 결함이 발견되는 즉시 업데이트를 되돌립니다.

복잡한 변경 사항은 노출을 제어하는 기능 플래그를 통해 활성화 및 비활성화됩니다.

고객의 업무량에 영향을 미치는 변경 사항은 IBM Cloud 알림에 자세히 설명되어 있습니다. 이 서비스에 영향을 미치는 계획된 유지보수, 공지사항, 릴리스 노트에 대한 자세한 정보는 모니터링 알림 및 상태를 참조하십시오.

고가용성 및 재해 복구에 대한 사용자의 책임

HA와 DR에 대한 계획을 지속적으로 테스트하는 것은 여러분의 책임입니다.

네트워크 연결이 중단되거나 서비스가 잠시 중단될 수 있습니다. 애플리케이션의 고가용성을 유지하기 위해 애플리케이션 소스 코드에 클라이언트 가용성 재시도 로직이 포함되어 있는지 확인하는 것은 사용자의 책임입니다.

사용자는 앱과 서비스에 적합한 수준의 가용성을 달성할 수 있도록 클러스터를 구성할 책임이 있습니다. 클러스터에 대해 설정하는 가용성 레벨은 IBM Cloud HA SLA(Service Level Agreement) 이용 약관에 따른 적용 범위에 영향을 줍니다. 예를 들어, SLA 이용 약관에 따라 전체 HA 적용을 받으려면 최소 총 여섯 개의 작업자 노드, 즉 세 개의 구역에 고르게 분산된 구역당 두 개의 작업자 노드로 다중 구역 클러스터를 설정해야 합니다.

사용자는 클러스터에서 실행되는 워크로드와 애플리케이션 데이터의 복구에 대한 책임이 있습니다. 재해 복구에 대한 회원님의 책임에 대한 자세한 내용은 Red Hat OpenShift on IBM Cloud 사용 시 회원님의 책임 을 참조하세요.

변경 관리

변경 관리에는 업그레이드, 구성 변경 및 삭제와 같은 작업이 포함됩니다. 작업의 중단 시간이나 데이터 손실을 줄이기 위해 다음 사항을 염두에 두십시오.

• 사용자와 프로세스에 IAM 역할과 권한을 부여할 때는 업무 수행에 필요한 최소한의 권한만 부여하는 것이 좋습니다. 예를 들어, 생산 자원을 삭제하는 기능을 제한합니다.

• API, CLI 또는 콘솔 도구를 사용하여 운영 체제 패치가 포함된 제공된 워커 노드 업데이트를 적용하거나 워커 노드를 재부팅, 다시 로드 또는 교체하도록 요청할 수 있습니다.

• API, CLI 또는 콘솔 도구를 사용하여 제공된 메이저 및 마이너 Kubernetes 마스터 업데이트와 메이저, 마이너 및 패치 워커 노드 업데이트를 적용합니다. 문제나 다운타임을 방지하기 위해 각 버전 업데이트에 대한 정보와 요구 사항을 검토해야 합니다.

• 클러스터 워커 노드가 최신 버전으로 실행되는지 확인하세요 Ubuntu 버전이 실행되는지 확인하세요.

• 클러스터에서 실행하는 모든 애드온의 출시 일정을 확인하십시오.

앱과 서비스 배포를 위한 고려 사항

클러스터를 구성하는 방식은 앱과 서비스의 가용성 수준에 영향을 미칩니다. 다중 작업자 노드 및 클러스터에 보다 광범위하게 설정을 분배할수록 사용자가 앱에서 작동 중단을 겪을 가능성이 보다 줄어듭니다.

가용성의 정도가 증가하는 순서로 정렬된 다음의 잠재적 앱 설정을 검토하십시오.

1. 단일 노드에 설정된 복제본으로 관리되는 n+2 파드를 사용한 배포입니다.
2. 복제본 세트에 의해 관리되며 단일 구역 클러스터의 다중 노드 간에 전개된(반친화성) n+2 팟(Pod)의 배치.
3. 복제본 세트에 의해 관리되며 구역 간의 다중 구역 클러스터의 다중 노드 간에 전개된(반친화성) n+2 팟(Pod)의 배치.

고가용성 워크로드를 만드는 방법에 대한 자세한 내용은 다음 문서를 참조하세요.

• 고가용성 배치 계획
• 클러스터 고가용성 전략
• Red Hat OpenShift on IBM Cloud 사용에 대한 책임