프로덕션 준비가 되지 않은 플랜 계획 및 설계

DR 인프라 용량은 계획에 달리 명시되어 있지 않는 한 프로덕션 워크로드를 관리할 수 있어야 합니다. 프로덕션 환경과 맞지 않는 리소스로 DR을 구현하는 것은 비용 측면에서는 매력적으로 보일 수 있지만 재해의 영향을 훨씬 더 심각하게 만들 수 있습니다.

재해 복구 환경을 계획하고 구현할 때 자체 복원력 요구 사항을 고려하세요. DR 구현의 고가용성 요구 사항을 줄여서 비용을 절감하려고 하지 마세요. 재해가 발생하면 프로덕션 워크로드에 복원력이 있는 환경이 필요합니다. 클라우드의 서비스는 확장 가능하므로 나중에 용량을 추가할 수 있지만 재해로 인한 지역적 수요 증가로 인해 단기적으로 용량이 부족할 수 있습니다.

비기술적인 단일 장애 지점 잊기

단일 장애 지점(SPOF)은 기술뿐만 아니라 솔루션의 어느 곳에나 있을 수 있습니다. 솔루션은 사용자, 공급업체, 제공자 및 기타 외부 종속성에 따라 달라질 수 있습니다. SPOF를 명확하게 파악하고 종속성을 완화하세요. 재해 복구 테스트의 첫 번째 세션 동안 SPOF를 발견할 준비를 하십시오.

SPOF 중에서 제공자 위험은 DR 플랜에서 고려해야 할 조건입니다. 동일한 제공자에 대한 프로덕션 및 DR이 모두 있는 경우 위험 조건이 증가하므로 신중하게 고려해야 합니다.

플랜 A만 있음

재난은 다양한 형태로 발생할 수 있으므로 특정 재난 시나리오 하나만 대비하면 다른 재난에 취약해질 수 있습니다. DR 계획을 구상할 때 여러 가지 재해 시나리오를 고려하고 계획이 얼마나 유연한지 입증하세요.

계획이 제대로 테스트되지 않음

검증되지 않은 DR 솔루션은 성공이 가장 중요한 순간에 장애가 발생할 가능성을 높입니다. 테스트는 제대로 작동하는 솔루션이 있는지 검증하는 데 필수적입니다. 테스트하는 조건도 중요하므로 여러 테스트 시나리오를 만들어야 합니다.

한 곳에서는 계획적으로 운영을 종료하고 다른 곳에서는 체계적으로 재시작하는 방식으로 DR 테스트를 수행하면 DR 테스트가 제대로 작동하는지 확인하는 데 도움이 됩니다. 하지만 실제 긴급 상황에서는 단순한 전체 종료가 항상 발생하는 것은 아닙니다.

비상 상황으로 인해 워크로드가 점진적으로 영향을 받는 '롤링 재난 상황'을 시뮬레이션하여 잠재적인 비상 상황을 최대한 가깝게 모방하도록 테스트를 설계하세요. 프로그레시브 임팩트는 솔루션의 복원력을 테스트하고 스트레스 조건에 견딜 수 있는 능력에 대한 인사이트를 제공합니다.

고가용성

고가용성은 재해 복구와 동일하지 않습니다. { IBM Cloud 고객이 IBM Cloud 멀티존 리전(MZR)을 활용하여 배포의 가용성이 높은지 확인할 것을 권장합니다. 각 MZR에는 최소 3개의 영역이 있으며, 이 영역들은 서로 밀접하게 연결되어 있지만 운영상으로는 분리된 데이터 센터입니다. 종종 문제와 서비스 중단은 전체 지역이 아닌 단일 영역에만 영향을 미칩니다. 기본적으로 MZR의 모든 영역에 워크로드를 배포하면 다운타임과 재해 요청의 필요성을 줄일 수 있습니다. 두 번째 리전으로의 장애 복구는 장애 복구와 마찬가지로 중요한 프로세스가 될 수 있으므로 가능한 한 많은 조치를 취하여 장애 복구가 필요하지 않도록 하세요. 그러나 MZR은 데이터 손상이나 악의적인 손상과 같은 재난을 예방하지는 못합니다.

규정 및 규정 준수

일부 워크로드와 데이터는 엄격한 업계 규정 및 규정 준수 표준의 적용을 받으며, 이는 실행 또는 저장할 수 있는 물리적 위치에 영향을 미칠 수 있습니다. 재해 복구 사이트의 위치를 선택할 때는 선택한 지역이 필요한 규정 및 컴플라이언스를 충족하는지 확인하세요. 데이터를 복제할 위치도 확인해야 합니다.

지역 간 Object Storage 버킷은 데이터를 다른 지역으로 복제하는 방법을 제공하지만, 데이터가 지역 제한이 적용되는 경우 주의해서 사용하세요. 데이터가 조직 또는 업계 규정 준수 규칙을 위반하는 국가 또는 지역의 지역으로 전송되지 않았는지 확인합니다.

재해 복구 지역의 용량

재해가 발생하면 많은 고객이 재해 복구 계획을 수립할 수 있습니다. 추가 수요로 인해 장애가 발생한 지역과 가장 가까운 하나 이상의 지역의 용량에 심각한 부담을 줄 수 있습니다. 이로 인해 사용 가능한 리소스가 부족할 수 있습니다. 예를 들어 us-south 에 장애가 발생하면 많은 고객이 us-east 지역에서 먼저 복구하는 것을 선택할 가능성이 높습니다. eu-gb 에 실패하면 eu-de 에 더 많은 수요가 몰릴 것으로 예상됩니다.

재해로 인해 수요가 많은 경우 복구 지역에서 우선적으로 선택한 인프라를 프로비저닝할 수 없을 수도 있습니다. 여기에는 인기 있는 VPC VSI 프로필이 포함됩니다. 대체 VSI 프로필이 필요한 상황을 고려할 수 있는 애플리케이션의 다양한 아키텍처를 고려해야 합니다. 애플리케이션에서 대체 인프라 사용을 허용할 수 없는 경우, 재해 발생에 대비하여 선택한 재해 복구 지역에 필요한 만큼의 용량을 구축하거나 예약하거나 용량 문제를 피하기 위해 더 멀리 떨어진 다른 위치를 고려하는 것이 좋습니다.

선택한 지역에서 백업을 복원할 수 있는지 확인합니다. 예를 들어 규정 준수 경계를 넘어서는 지역에서는 데이터베이스를 복원할 수 없습니다. 모범 사례로, 데이터 복원 시기를 테스트하고 전체 지역에 영향을 미치는 대규모 재해가 발생하면 많은 고객이 한꺼번에 데이터 복원을 시도하므로 시간이 연장될 수 있다는 점을 고려해야 합니다.

연결

네트워킹 서비스는 타사의 작업이나 물리적 인프라의 추가 설치가 필요할 수 있으므로 프로비저닝 및 구성에 다소 시간이 걸릴 수 있습니다. DR 계획을 만들 때 이러한 서비스의 리드 타임을 고려하세요. 이러한 서비스는 미리 프로비저닝하는 것이 가장 좋습니다:

• Direct Link, Transit Gateway 로컬 및 Transit Gateway 글로벌
• VPC Edge
• VPN 게이트웨이 및 연결
• DNS 허브 및 스포크의 VPC 설정이 있는 사설 DNS
• 공유 서비스용 VPE
• 컨텍스트 기반 제한 규칙
• 사설 DNS의 글로벌 로드밸런서
• CIS 공개 LBaaS, VPE 개인 경로 및 PPNLB 사용

배포 가능한 아키텍처와 VPC landing zone 배포 가능한 아키텍처와 FS 클라우드 참조 아키텍처를 활용하여 사전 또는 재해 복구 중에 연결성을 준비하세요.

부분 또는 전체 장애 조치

클라우드는 다양한 서비스로 구성되어 있으며 애플리케이션은 함께 작동하는 여러 구성 요소에 의존할 수 있습니다. 재해 복구 계획은 일반적으로 지역 수준에서 치명적인 장애에 대비하며 해당 지역의 모든 서비스가 손실되는 경우를 가정합니다. 그러나 고립된 서비스 중단은 해당 지역의 다른 서비스에 영향을 미치지 않고 발생할 수 있습니다.

이러한 경우 다른 리전으로 전체 장애 조치가 필요한지 아니면 장애가 발생한 구성 요소만 해결하면 되는지 평가하는 것이 중요합니다.

예를 들어 데이터베이스 서비스에 치명적인 장애가 발생하는 경우 웹 서비스를 포함한 전체 워크로드에 장애 조치를 취해야 하나요? 아니면 다른 구성 요소가 다른 지역의 대기 읽기 복제본 데이터베이스로 쉽게 전환할 수 있나요?

이러한 시나리오의 처리 용이성은 워크로드를 설계하고 구성하는 방식에 따라 달라집니다. 서비스 이름을 하드코딩하지 말고 부분 중단 시 원활한 전환을 위해 네트워크 지연 시간 등의 요소를 고려한 아키텍처를 구축하세요.

장애 복구

또 다른 고려 사항은 재해가 진정된 후의 장애 복구 위치입니다. 장애 복구 절차는 DR 계획에 문서화되어 있습니다. 페일백 고려 사항은 다음과 같습니다:

• 복구 위치에서 장애 복구하거나 정상적으로 계속 실행하나요?
• 페일백이 필수인 경우 언제 시도하나요?
• 장애 복구는 어떻게 작동하여 더 이상의 중단을 최소화할 수 있을까요?

장애 복구는 재해만큼이나 복잡하고 혼란스러울 수 있으므로 장애 복구가 필요한지 여부를 고려하세요. 대신 두 번째 위치에서 서비스를 계속 실행할 수 있나요? 장애 복구의 타이밍도 중요합니다. 장애를 일으킨 상황이 해결되고 장애 복구로 인해 중단이 장기화되지 않도록 해야 합니다.

장애 조치 시행 여부와 관계없이 DR 프로비저닝을 다시 만들거나 재설정해야 합니다.