시스템 업데이트, 복사 및 클론 복제 사용 사례
변경 제안
PDF
테스트 또는 교육 목적으로 대상 시스템에서 소스 시스템의 데이터를 사용할 수 있도록 여러 가지 시나리오가 있습니다. 이러한 테스트 및 교육 시스템은 정기적으로 소스 시스템의 데이터를 업데이트하여 테스트 및 교육이 현재 데이터 세트와 함께 수행되도록 해야 합니다.
이러한 시스템 업데이트 작업은 인프라, 데이터베이스 및 애플리케이션 계층에 있는 여러 작업으로 구성되며 자동화 수준에 따라 몇 일이 걸릴 수 있습니다.
SAP LaMa와 NetApp 클론 복제 워크플로우를 사용하면 인프라 및 데이터베이스 계층에서 필요한 작업을 더 빠르게 처리하고 자동화할 수 있습니다. SAP LaMa는 소스 시스템에서 타겟 시스템으로 백업을 복원하는 대신 NetApp Snapshot 복사본과 NetApp FlexClone 기술을 사용하여 다음 그림과 같이 몇 시간이 아닌 몇 분 이내에 HANA 데이터베이스를 시작하는 데 필요한 작업을 수행할 수 있습니다. 클론 생성 프로세스에 필요한 시간은 데이터베이스의 크기와 무관합니다. 따라서 몇 분 안에 초대형 시스템도 만들 수 있습니다. 운영 체제 및 데이터베이스 계층뿐만 아니라 SAP 사후 처리 측면에서도 작업을 자동화하여 런타임을 더욱 줄일 수 있습니다.
논리적 손상을 처리합니다
논리적 손상은 소프트웨어 오류, 인적 오류 또는 태업 때문에 발생할 수 있습니다. 하지만 논리적 손상은 표준 고가용성 및 재해 복구 솔루션을 통해 해결할 수 없는 경우가 많습니다. 따라서 논리적 손상이 발생한 계층, 애플리케이션, 파일 시스템 또는 스토리지에 따라 가동 중지 시간을 최소화하고 허용되는 데이터 손실 요구 사항을 충족하지 못하는 경우가 있습니다.
최악의 경우는 SAP 애플리케이션의 논리적 손상입니다. SAP 애플리케이션은 서로 다른 애플리케이션이 서로 통신하고 데이터를 교환하는 환경에서 작동하는 경우가 많습니다. 따라서 논리적 손상이 발생한 SAP 시스템을 복원 및 복구하는 것은 권장되는 방법이 아닙니다. 손상이 발생하기 전의 시점으로 시스템을 복원하면 데이터가 손실됩니다. 또한 SAP 환경은 더 이상 동기화되지 않으며 추가 후처리 작업이 필요합니다.
SAP 시스템을 복원하는 대신 별도의 복구 시스템에서 문제를 분석하여 시스템 내의 논리적 오류를 해결하는 것이 더 좋습니다. 근본 원인 분석에는 비즈니스 프로세스 및 애플리케이션 소유자의 참여가 필요합니다. 이 시나리오에서는 논리적 손상이 발생하기 전에 저장된 데이터를 기반으로 복구 시스템(운영 시스템의 클론)을 생성합니다. 복구 시스템 내에서 필요한 데이터를 내보낸 후 운영 시스템으로 가져올 수 있습니다. 이 방법을 사용하면 운영 시스템을 중단할 필요가 없으며, 최상의 시나리오에서는 데이터가 없거나 극히 일부의 데이터만 손실됩니다.
수리 시스템을 설정할 때는 유연성과 속도가 매우 중요합니다. NetApp 스토리지 기반 Snapshot 백업을 사용하면 일관된 여러 데이터베이스 이미지를 사용하여 NetApp FlexClone 기술을 사용하여 운영 시스템의 클론을 생성할 수 있습니다. 파일 기반 백업에서 리디렉션된 복원을 사용하여 복구 시스템을 설정하는 경우 몇 시간이 아니라 몇 초 이내에 FlexClone 볼륨을 생성할 수 있습니다.
재해 복구 테스트
효과적인 재해 복구 전략을 위해서는 필요한 워크플로우를 테스트해야 합니다. 테스트는 전략이 제대로 작동하는지 여부와 내부 문서화가 충분한지 여부를 보여 줍니다. 또한 관리자가 필요한 절차를 교육할 수 있습니다.
SnapMirror를 통한 스토리지 복제를 사용하면 RTO 및 RPO를 위험에 빠뜨리지 않고 재해 복구 테스트를 실행할 수 있습니다. 데이터 복제를 중단하지 않고 재해 복구 테스트를 수행할 수 있습니다. 비동기식 및 동기식 SnapMirror의 재해 복구 테스트에서는 재해 복구 대상에 있는 Snapshot 백업과 FlexClone 볼륨을 사용합니다.
SAP LaMa는 전체 테스트 절차를 조율하는 데 사용할 수 있으며 네트워크 펜싱, 대상 호스트 유지 관리 등을 수행합니다.
