Azure의 Red Hat Enterprise Linux에 대한 비즈니스 연속성 및 재해 복구 고려 사항
이 문서에서는 Azure에서 RHEL(Red Hat Enterprise Linux) 기반 환경에 대한 BCDR(비즈니스 연속성 및 재해 복구) 준비 상태를 개선하는 방법을 설명합니다. RHEL 워크로드를 지원하고 RHEL 플랫폼 관리 구성 요소를 배포하는 데 사용할 수 있는 권장 사항을 제공합니다. Red Hat Management 구독에는 하나 이상의 RHEL 랜딩 존에서 워크로드를 관리하는 데 도움이 되는 플랫폼 구성 요소가 포함되어 있습니다. 이러한 구성 요소는 자체 BCDR 구성을 제공합니다.
디자인 고려 사항
RHEL 워크로드의 복원력을 향상시키기 위해 다음 고려 사항을 구현합니다.
복구 시간 목표
RTO(복구 시간 목표)는 재해 발생 후 시스템이 원래 상태로 복구하는 데 걸리는 시간입니다. RTO에는 다음이 걸리는 시간이 포함됩니다.
- VM(가상 머신) 및 애플리케이션에 최소한의 기능을 복원합니다.
- 애플리케이션에 필요한 데이터를 복원합니다.
비즈니스 측면에서 RTO는 비즈니스 프로세스가 서비스되지 않는 시간을 나타냅니다. 낮은 RTO는 중요 업무용 워크로드에 적합하므로 비즈니스 프로세스를 신속하게 다시 시작할 수 있습니다. 우선 순위가 낮은 워크로드의 경우 RTO가 높을수록 회사 성능에 눈에 띄는 영향을 미치지 않을 수 있습니다.
복구 지점 목표
클라우드 환경을 성공적으로 운영하려면 백업, 복제 또는 둘 다 구현하여 오류로부터 데이터를 보호해야 합니다. RPO(복구 지점 목표)는 데이터가 마지막으로 캡처된 시간을 나타냅니다. 시스템이 실패하면 최신 복구 지점으로만 복원할 수 있습니다.
가장 최근의 복구 지점에서 중단이 발생한 시간까지 RPO를 측정합니다. RPO를 시간 단위로 측정하면 시스템 오류로 인해 마지막 복구 지점과 중단 사이의 시간 동안 데이터가 손실됩니다. 며칠 동안 RPO를 측정하면 시스템 오류로 인해 마지막 복구 지점과 중단 사이의 일 동안 데이터가 손실됩니다. 이론적으로 1일 RPO는 오류로 이어지는 일의 모든 트랜잭션이 손실됩니다.
중요 업무용 시스템의 경우 RPO를 몇 분 또는 몇 초 단위로 측정하여 수익 또는 수익 손실을 방지합니다. 일반적으로 RPO가 짧을 경우 관리 비용이 증가합니다. 이러한 비용을 줄이려면 허용되는 가장 긴 RPO에 중점을 둔 관리 기준을 만들어야 합니다. 그런 다음, 더 많은 투자를 보증하는 특정 플랫폼 또는 워크로드의 RPO를 줄일 수 있습니다.
워크로드 BCDR 고려 사항
RHEL 기반 워크로드에 대한 고가용성 및 재해 복구 디자인 고려 사항은 해당 워크로드를 지원하는 기술에 따라 달라집니다. 대부분의 최신 워크로드는 네이티브 Azure 서비스를 활용하여 가용성 영역 및 지역 간에 중복성을 제공할 수 있습니다. Azure 서비스를 사용하여 데이터 복제를 관리하고, 가용성 집합의 크기를 자동으로 조정하고, 업데이트 및 장애 도메인을 제어합니다. 이러한 사례를 통해 RHEL 배포의 가용성을 보다 쉽게 보장할 수 있습니다.
데이터베이스 솔루션 및 기타 상태 저장 애플리케이션은 고가용성 및 재해 복구를 제공하기 위해 운영 체제 중심 솔루션이 필요할 수 있습니다. 애플리케이션 개발자 또는 공급업체에 문의하여 애플리케이션이 지원하는 솔루션을 확인합니다. 자세한 내용은 IaaS 앱에 대한 고가용성 및 재해 복구를 참조 하세요.
| Azure 기능 또는 서비스 | 정의 | 고려 사항 |
|---|---|---|
| 지역 | 네트워크 지연 시간을 낮추기 위해 서로 가까이 있는 데이터 센터 그룹입니다. 빠른 데이터 전송을 보장하기 위해 특정 지역 네트워크는 데이터 센터를 연결합니다. | Azure 지역을 선택할 때 데이터 센터, 사용자 및 백 엔드 데이터의 위치를 고려합니다. 선택한 지역에서 필요한 서비스의 가용성을 확인합니다. RHEL 배포의 경우 시작할 지역이 하나 있을 수 있으며 나중에 BCDR을 위해 더 많은 지역을 추가할 수 있습니다. |
| Azure ExpressRoute | Microsoft 데이터 센터에서 사용자 고유의 인프라 또는 공동 배치 시설로 프라이빗 연결을 설정하는 데 사용할 수 있는 Azure 서비스입니다. | ExpressRoute는 공용 인터넷을 우회하고 전용 프라이빗 연결을 제공합니다. 이 구성은 대규모 RHEL 배포에 대한 일반적인 요구 사항입니다. ExpressRoute는 공유 서비스이므로 기업의 전체 대역폭 요구 사항에 맞게 대역폭 용량을 신중하게 계획해야 합니다. 대역폭이 부족한 경우 데이터 센터의 중요한 서비스에 대한 액세스 또는 사용자 환경을 손상시킬 수 있습니다. 지역 및 피어링 위치에서 복원력 있는 방식으로 ExpressRoute를 배포해야 합니다. |
| 가용성 영역 | Azure 지역 내에서 자체 전원, 냉각 및 네트워킹 시스템을 포함하는 데이터 센터 그룹을 분리합니다. 가용성 영역은 데이터 센터 오류에 대한 고가용성 및 복원력을 제공합니다. | 높은 SLA(서비스 수준 계약)를 보장하려면 가능한 경우 RHEL 인프라와 함께 가용성 영역을 사용합니다. 가용성 영역은 지역 내에서 데이터 센터 중복성을 제공합니다. 그러나 모든 지역에 가용성 영역이 있는 것은 아니므로 신중하게 계획해야 합니다. Azure Red Hat OpenShift 및 랜딩 존 관리 서비스와 같은 RHEL 서비스는 가용성 영역을 지원합니다. |
| 가용성 집합 | VM의 논리적 그룹화입니다. 계획되거나 계획되지 않은 유지 관리 이벤트 중에 하나 이상의 VM이 항상 작동 및 실행됩니다. 장애 도메인은 전원 또는 네트워크와 같은 일반적인 물리적 인프라를 공유하는 가용성 집합의 하위 집합입니다. 여러 장애 도메인에 VM을 배포하는 경우 가용성 집합은 하드웨어 오류가 VM 가용성에 미치는 영향을 줄입니다. | 가용성 집합은 높은 SLA를 제공합니다. 가용성 집합은 지역에 가용성 영역이 없는 경우 RHEL 인프라에 적합합니다. 가용성 집합에는 하이퍼바이저 선호도 방지 규칙과 유사한 하드웨어 중복성만 있습니다. 따라서 지역에 가용성 영역이 없는 경우 데이터 센터 및 지리적 중복성을 위한 다중Region 전략이 필요합니다. |
| Azure Load Balancer | 네트워크 부하 분산 서비스입니다. 여러 Red Hat Enterprise 서버에서 대용량 네트워크 트래픽을 효율적으로 제공하도록 Load Balancer를 구성할 수 있습니다. 이 서비스는 짧은 대기 시간과 높은 처리량으로 작동하여 애플리케이션의 성능과 가용성을 향상시킵니다. Load Balancer는 수요에 따라 자동으로 크기를 조정할 수 있습니다. 애플리케이션의 하이브리드 배포를 촉진하기 위해 Load Balancer는 Azure의 여러 지역과 온-프레미스 환경과 Azure 간에 네트워크 트래픽을 분산할 수 있습니다. |
Load Balancer는 네트워크 트래픽을 여러 서버에 분산하여 중단 없는 애플리케이션 가용성을 제공하고 단일 지점 오류를 방지합니다. 재해가 발생하면 Load Balancer는 트래픽을 운영 서버로 리디렉션하여 신속한 장애 조치(failover) 및 복구를 제공합니다. 이 작업은 가동 중지 시간을 최소화하고 비즈니스 작업을 유지 관리합니다. Load Balancer는 온-프레미스 서버에서 Azure 클라우드 또는 여러 Azure 지역의 서버로 트래픽을 분산할 수 있습니다. 자세한 내용은 부하 분산 옵션을 참조 하세요. |
| 관리 디스크 | Azure에서 관리하는 가상화된 디스크입니다. 디스크 크기 및 유형을 선택합니다. Azure는 다양한 스토리지 단위에 디스크를 분산하여 하드웨어 오류로부터 데이터를 보호합니다. | 관리 디스크는 모든 RHEL 인프라에 가장 적합합니다. 관리되지 않는 디스크를 사용하지 마세요. 자세한 내용은 VM에 대한 SLA를 참조 하세요. 디스크 유형이 다르면 성능과 비용이 다릅니다. RHEL 인프라 머신의 경우 Azure Premium SSD를 사용하는 것이 좋습니다. 디스크 유형을 선택할 때 비용, 성능 및 가용성을 고려합니다. 시스템을 할당 취소하면 로컬 SSD 및 임시 디스크가 제거됩니다. 이러한 디스크의 데이터를 적절하게 백업합니다. |
| Azure Backup | 데이터를 백업하고 Azure 클라우드에서 복구하는 비용 효율적인 솔루션을 제공하는 서비스입니다. | 백업은 VM 오류 또는 손상으로부터 RHEL 인프라를 보호하는 안정적이고 비용 효율적인 솔루션입니다. Backup을 사용하여 VM을 다시 만들거나 데이터를 손실하지 않고도 클라우드에서 전체 VM 또는 특정 파일 및 폴더를 쉽게 복원할 수 있습니다. 지원되는 다른 파트너 솔루션을 사용할 수도 있습니다. |
| Azure Arc | 데이터 센터, 에지 디바이스 및 다중 클라우드 아키텍처를 비롯한 다양한 환경에서 실행되도록 Azure 서비스를 확장하는 플랫폼입니다. Azure Arc를 사용하여 애플리케이션 및 서비스에 대한 일관된 개발, 운영 및 보안 관리를 제공합니다. | Azure Arc를 사용하여 중앙 집중식 자동화된 백업 및 모니터링을 구현하여 BCDR 관점에서 복원력을 높입니다. |
| Azure Site Recovery | 비즈니스 연속성을 보장하기 위한 재해 복구 기능을 제공하는 서비스입니다. 여러 지역에서 Azure VM 및 온-프레미스 VM을 포함한 워크로드를 복제하고 관리할 수 있습니다. Site Recovery를 사용하면 복제, 장애 조치(failover) 및 복구 프로세스를 설정하여 계획된 중단 및 계획되지 않은 중단 중에 애플리케이션을 보호할 수 있습니다. | Site Recovery를 사용하여 복구 문제를 최소화하고 인프라 비용을 절감하며 Azure 지역 간 또는 온-프레미스 위치에서 Azure로의 안전하고 신뢰할 수 있는 복구를 보장합니다. |
| 리소스 잠금 | 조직의 사용자 및 역할을 제한하는 데 사용할 수 있는 Azure 기능입니다. 우발적이거나 악의적인 변경으로부터 중요한 리소스를 보호합니다. 구독, 리소스 그룹 또는 개별 리소스 수준과 같은 다양한 범위 수준에서 리소스를 잠글 수 있습니다. 잠금 유형에 따라 사용자가 리소스를 삭제하거나 수정하는 것을 방지할 수 있지만 여전히 해당 구성을 읽을 수 있습니다. | 모든 RHEL 인프라 및 골든 이미지 VM을 보호하려면 리소스 잠금을 사용합니다. 실수로 중요한 컴퓨터가 손실되지 않도록 하려면 삭제 잠금을 최소한으로 적용합니다. 자주 변경되지 않으므로 RHEL 인프라 머신에 ReadOnly 잠금을 적용합니다. 적절한 변경 제어 기간 동안에만 변경합니다. |
RHEL 플랫폼 BCDR 고려 사항
RHEL 플랫폼 인프라의 BCDR 기능에 대한 자세한 내용은 다음을 참조하세요.
디자인 권장 사항
Linux 컨테이너의 클라우드 네이티브 애플리케이션의 경우 Kubernetes 기반 플랫폼을 사용하여 확장성, 고가용성 및 중복성을 보장합니다. Azure Red Hat OpenShift 플랫폼 또는 복제된 스토리지 또는 지역 복제 스토리지와 함께 자체 관리형 OpenShift 배포를 사용하는 것이 좋습니다.
네이티브 웹 애플리케이션 프런트 엔드 및 상태 비지방 애플리케이션의 경우 애플리케이션 가용성을 제공하는 많은 Azure 네이티브 서비스를 사용할 수 있습니다. 이러한 서비스를 사용하는 아키텍처는 다음을 참조하세요.
- 고가용성 영역 중복 웹 애플리케이션을 기준으로 합니다.
- 고가용성 다중Region 웹 애플리케이션.
이전 아키텍처는 가용성 영역에 다양한 Azure 서비스를 사용합니다. 다중Region 아키텍처는 콘텐츠에 지역 복제 기능을 사용하고 Azure Front Door를 부하 분산 서비스로 사용합니다.
고가용성이 필요한 기존의 많은 상태 저장 애플리케이션의 경우 RHEL은 Pacemaker 고가용성 추가 기능을 제공합니다. Azure Marketplace에서 이 기능이 있는 시스템을 얻거나 필요한 소프트웨어 구성 요소가 포함된 사용자 지정 이미지를 배포할 수 있습니다. 자세한 내용은 Microsoft Azure에서 Red Hat 고가용성 클러스터 구성을 참조하세요.
가용성 문제는 서비스 중단 및 서비스 응답 시간에 영향을 줍니다. 서비스 성능이 저하되어 고객의 서비스 환경이 저하될 수 있습니다. 필요한 지역 내에서 성능 수준과 충분한 용량을 유지하려면 Azure 주문형 용량 예약 기능을 사용합니다.
안정성
서비스 VM 인프라로서의 인프라에 적용되는 많은 개념은 RHEL 아키텍처에도 적용됩니다. 자세한 내용은 안정성 디자인 원칙을 참조 하세요.
클러스터
Azure는 단일 RHEL Pacemaker 클러스터 내에서 Application Server Central Services 및 데이터베이스 고가용성 결합을 지원하지 않습니다. 이 제한을 해결하려면 개별 클러스터로 구분합니다. VM 쌍으로 최대 5개의 중앙 서비스 클러스터를 결합할 수 있습니다.
SAP의 BCDR의 경우 SAP 중앙 서비스 클러스터를 실행하려면 다음 서비스를 고려하세요.
- RHEL Pacemaker 클러스터: STONITH 블록 디바이스는 지원되지 않지만 Azure 펜스 에이전트를 사용할 수 있습니다.
- SAP 인증 비 Microsoft 클러스터 소프트웨어: 요구 사항에 맞는 경우 이 옵션을 탐색합니다.
특정 요구 사항 및 운영 체제에 따라 적절한 서비스를 선택합니다.
자세한 내용은 다음을 참조하세요.
- RHEL 9용 Microsoft Azure에서 Red Hat 고가용성 클러스터를 구성합니다.
- RHEL 9에 대한 고가용성 클러스터를 구성하고 관리합니다.
- RHEL 8 설명서.
Azure Compute 갤러리 복제본
컴퓨팅 갤러리를 사용하여 배포를 위한 골든 이미지를 저장할 수 있습니다. 애플리케이션 및 도구의 재해 복구를 위해 이러한 이미지를 사용합니다. 컴퓨팅 갤러리는 가용성 영역을 지원하는 지역의 ZRS(영역 중복 스토리지) 계정과 함께 고가용성 리소스를 사용할 수 있습니다. ZRS는 영역 오류에 대한 복원력을 제공합니다. 갤러리 이미지를 다른 지역이나 지역에 복제할 수도 있습니다.
참고 항목
서로 다른 지역에 갤러리가 두 개 이상 있는 것이 좋습니다.
Site Recovery
Site Recovery 는 일부 RHEL 구성 요소의 복원력을 향상시킬 수 있습니다. 지원되는 RHEL 사이트 복구 서버 목록은 Site Recovery를 사용한 Azure VM 재해 복구에 대한 지원 매트릭스를 참조 하세요. 또한 Site Recovery를 온-프레미스 환경에서 클라우드로 장애 조치(failover)로 설정할 수도 있습니다. Site Recovery 비용을 예측하려면 Site Recovery 배포 플래너를 사용합니다.
복구 클러스터 노드
RTO를 줄이고 복원력을 높이기 위해 활성 또는 대기 원격 복구 클러스터 노드를 사용할 수 있습니다. 재해 복구 클러스터 항목을 수동으로 구성해야 합니다. 예를 들어 구성을 적용하여 리소스를 설정하고 데이터를 복사해야 합니다.