AWS 클라우드 환경을 위한 Linux용 SIOS Protection Suite 평가 안내서

AWS에서 Linux용 SIOS Protection Suite 평가 시작하기

이 단계별 가이드를 사용하여 AWS에서 2노드 클러스터를 구성하고 테스트하여 Oracle, SQL Server, PostgreSQL, NFS, SAP 및 SAP HANA와 같은 리소스를 보호하십시오.

평가를 시작하기 전에

AWS에서 장애 조치 클러스터링 프로젝트를 시작하기 전에 필요한 주요 개념을 이해하려면 이 링크를 검토하십시오.

• 고가용성, RTO , 그리고 RPO – HA의 기본 개념을 명확하게 이해합니다.

• 시오스 Linux용 Protection Suite – 통합 구성 요소 – SIOS Protection Suite에 포함된 구성 요소 이해: SIOS LifeKeeper, DataKeeper 및 애플리케이션 복구 키트/

• 장점 시오스 Linux용 보호 제품군 – Linux용 SIOS Protection Suite가 어떻게 우수한 데이터 보호 기능을 제공하는지 알아보십시오.

• 클라우드 환경으로 마이그레이션할 때 워크로드를 분산하는 방법 – 온프레미스 환경과 달리 퍼블릭 클라우드 오퍼링은 워크로드를 배포할 때 선택할 수 있는 광범위한 지리적 지역 가용성 영역을 제공합니다. 클라우드에 대한 워크로드 분산 전략을 선택하기 위한 모범 사례를 알아보세요.

• 퍼블릭 클라우드 플랫폼과 네트워크 구조의 차이점 – 퍼블릭 클라우드 제공업체는 자체 네트워킹 구조를 가지고 있습니다. 이러한 구조가 클러스터 구성에 미치는 영향에 대한 기본 사항을 알아보세요.

• 클라이언트가 활성 노드에 연결하는 방법 – 애플리케이션 장애에 대한 대응을 감지하고 관리하는 주요 클러스터링 메커니즘을 학습합니다.

• 노드 간 데이터 복제는 어떻게 작동합니까?– 스토리지의 중복성을 보장하는 것이 필수적입니다. SIOS DataKeeper가 노드 간에 데이터를 효율적으로 복제하는 방법을 알아보세요.

• 스플릿 브레인(Split Brain)이란 무엇이며 이를 피하는 방법 네트워크 연결이 실패한 경우에도 하나의 활성 노드와 하나 이상의 대기 노드를 유지 관리하는 방법을 알아봅니다.

네트워크 구성 요소 구성

이 섹션에서는 각 노드에 필요한 컴퓨팅 리소스, 네트워크 구조 및 이러한 구성 요소를 구성하는 데 필요한 프로세스에 대해 간략히 설명합니다.

• 장애 조치 클러스터링을 위해 네트워크 구성 요소를 구성하는 방법 알아보기
• 이 튜토리얼에서 사용된 네트워크 구조
• 이 자습서에 사용된 컴퓨팅 리소스

인스턴스 생성 AWS 처음부터 EC2

• 처음부터 AWS에 인스턴스 생성
• 전환 AWS 서비스
• 결정 AWS 지역
• 만들기 VPC
• 서브넷 생성
• 인터넷 게이트웨이 생성 및 할당 VPC
• 라우팅 테이블 생성
• 보안 그룹 생성
• 첫 번째 EC2 인스턴스 생성
• 두 번째 및 세 번째 인스턴스 생성

Linux용 SIOS Protection Suite를 실행하도록 Linux 노드 구성

• Linux용 SIOS Protection Suite를 실행하도록 Linux 노드 구성

Linux용 SIOS 보호 제품군 설치

• Linux용 SIOS 보호 제품군 설치

로그인 및 기본 구성

• 로그인 및 기본 구성

중요 자원 보호

• 에서 IP 리소스 생성 온프레미스 환경
• 노드 간 전환 클라우드 환경

IP 리소스가 보호되면 전환("대기" 노드가 "활성" 노드가 됨)을 시작하여 기능을 테스트합니다.

• 전환이 작동하는지 확인하기 위해 대기 노드로 전환하는 방법
• Oracle 리소스 보호
• 보호 MSSQL 빠른 서비스 보호 사용
• PostgreSQL 리소스 보호
• 보호 NFS 자원
• 보호 수액 자원
• 보호 수액 하나 자원

의 허가를 받아 재생산 시오스

ZRS(영역 중복 저장소)가 있는 Azure 공유 디스크의 성능

2021년 9월 9일 마이크로소프트 발표 일반 가용성 Azure Disk Storage용 ZRS(영역 중복 저장소) , Azure 공유 디스크 포함.

흥미로운 점은 이제 가용 영역(AZ)에 걸쳐 공유 스토리지 기반 장애 조치 클러스터 인스턴스를 구축할 수 있다는 것입니다.클러스터 노드가 서로 다른 AZ에 있으므로 사용자는 이제 99.99% 가용성 SLA에 대한 자격을 얻을 수 있습니다. 영역 중복 저장소를 지원하기 전에 Azure 공유 디스크는 LRS(로컬 중복 저장소)만 지원하여 클러스터 배포를 단일 AZ로 제한하여 사용자가 AZ가 오프라인이 될 경우 중단될 수 있었습니다.

그러나 ZRS를 사용하여 Azure 공유 디스크를 배포할 때 알아야 할 몇 가지 제한 사항이 있습니다.

• 프리미엄 SSD(반도체 드라이브) 및 표준 SSD에서만 지원됩니다. Azure 울트라 디스크는 지원되지 않습니다.
• ZRS가 포함된 Azure 공유 디스크는 현재 미국 서부 2, 서부 유럽, 북유럽 및 프랑스 중부 지역에서만 사용할 수 있습니다.
• 읽기 및 쓰기의 디스크 캐싱은 프리미엄 SSD Azure 공유 디스크에서 지원되지 않습니다.
• 프리미엄 SSD에는 디스크 버스팅을 사용할 수 없습니다.
• Azure Site Recovery 지원은 아직 사용할 수 없습니다.
• Azure Backup은 Azure Disk Backup을 통해서만 사용할 수 있습니다.
• 서버 쪽 암호화만 지원되며 Azure 디스크 암호화는 현재 지원되지 않습니다.

나는 또한 흥미로운 메모를 발견했습니다. 선적 서류 비치 .

"더 많은 쓰기 지연 시간을 제외하고 ZRS를 사용하는 디스크는 LRS를 사용하는 디스크와 동일하며 확장 목표가 동일합니다. 디스크를 벤치마킹하여 애플리케이션의 워크로드를 시뮬레이션하고 LRS와 ZRS 디스크 간의 대기 시간을 비교하십시오.” 문서에 ZRS가 추가 쓰기 대기 시간을 발생시키는 것으로 나와 있지만 예상할 수 있는 추가 대기 시간을 결정하는 것은 사용자의 몫입니다. 에 대한 링크 디스크 벤치마크 성능 테스트에 도움이 되도록 문서가 제공됩니다.

문서의 지침에 따라 DiskSpd를 사용하여 발생할 수 있는 추가 쓰기 대기 시간을 측정했습니다. 물론 결과는 작업 부하, 디스크 유형, 인스턴스 크기 등에 따라 다르지만 여기 내 결과가 있습니다.

	LRS(로컬 중복 스토리지)	영역 중복 저장소(ZRS)
쓰기 IOPS	5099.82	4994.63
평균 지연 시간	7.830	7.998

내가 실행한 DiskSpd 테스트는 다음 매개변수를 사용했습니다.

diskspd -c200G -w100 -b8K -F8 -r -o5 -W30 -d10 -Sh -L testfile.dat ZRS가 있는 P30 디스크와 표준 DS3 v2(4개의 vcpus, 14GiB 메모리)에 연결된 LRS가 있는 P30에 썼습니다. ) 인스턴스 유형. 공유 ZRS P30도 다른 AZ의 동일한 인스턴스에 연결되었고 빈 클러스터 애플리케이션에 공유 스토리지로 추가되었습니다.

2%의 오버헤드는 데이터를 2개의 AZ에 동기적으로 배포하기 위해 지불해야 하는 합리적인 가격처럼 보입니다. 하지만 클러스터링된 애플리케이션을 원격 노드로 이동하여 디스크를 하나의 AZ에, 인스턴스를 다른 AZ에 배치하면 어떻게 될지 궁금했습니다.

결과는 다음과 같습니다.

	LRS(로컬 중복 스토리지)	영역 중복 저장소(ZRS)	원격 AZ에서 쓸 때 ZRS
쓰기 IOPS	5099.82	4994.63	4079.72
평균 지연 시간	7.830	7.998	9.800

이 시나리오에서 나는 25%의 쓰기 지연 증가를 측정했습니다. AZ에 완전한 장애가 발생하면 스토리지와 인스턴스가 모두 보조 AZ로 장애 조치되며 이러한 지연 시간 증가는 전혀 발생하지 않습니다. 그러나 AZ 전체가 아닌 다른 오류 시나리오에서는 클러스터된 애플리케이션이 한 AZ에서 실행되고 Azure 공유 디스크가 다른 AZ에서 실행될 수 있습니다. 이러한 시나리오에서는 추가 오버헤드를 피하기 위해 가능한 한 빨리 클러스터링된 워크로드를 스토리지와 동일한 AZ에 있는 노드로 다시 이동하려고 할 것입니다.

Microsoft는 방법을 문서화합니다. 스토리지 계정 장애 조치 시작 GRS를 사용할 때 다른 지역으로 이동하지만 영역 중복 저장소를 사용할 때 다른 AZ로 저장소 계정의 장애 조치를 수동으로 시작할 수 있는 방법이 없습니다. 장애 조치(failover) 클러스터 인스턴스를 모니터링하여 클러스터 워크로드가 다른 서버로 이동할 때마다 경고를 받고 안전하게 이동하는 즉시 다시 이동할 계획을 세워야 합니다.

예기치 않게 이러한 상황에 처할 수 있지만 롤링 업데이트를 수행할 때 클러스터된 응용 프로그램 서버의 계획된 유지 관리 중에도 확실히 발생합니다. 인식은 스토리지가 저하된 상태에서 수행되는 시간을 최소화하는 데 도움이 되는 핵심입니다.

앞으로 Microsoft에서 사용자가 GRS와 마찬가지로 ZRS 디스크의 수동 장애 조치를 시작할 수 있기를 바랍니다. GRS에 기능을 추가한 이유는 자동 장애 조치가 예상대로 발생하지 않을 경우에 대비하여 사용자의 손에 권한을 주기 위함이었습니다. Zone Redundant Storage의 경우 SIOS DataKeeper와 같은 호스트 기반 복제 솔루션이 수행하는 방식과 유사하게 스토리지와 애플리케이션을 함께 연결하여 항상 동일한 AZ에서 실행되도록 하려는 사람들을 볼 수 있었습니다.

가용성 SLA: FT, 고가용성 및 재해 복구 – 시작 위치

우리 삶의 많은 부분이 기술 중심인 현대 시대에 우리는 매우 순간적인 세계에 살고 있다고 말할 수 있습니다.예를 들어, 버튼을 클릭하면 주간 식료품 주문이 문앞에 도착합니다.이벤트나 여행을 위한 티켓을 즉시 구매할 수 있습니다.아니면 요즘에도 전시장 근처에 가지 않고 깐깐한 영업사원을 만나지 않고도 새 차를 주문할 수 있습니다. 우리는 이 편리한 세상에서 버릇이 없습니다.

그러나 이러한 수준의 서비스를 뒷받침해야 하는 모든 공급업체와 서비스 제공업체에 대해서는 잠시 생각해 보겠습니다.그들은 기본 인프라(특히 IT 인프라)가 이러한 "상시 가동" 기대치를 지원할 수 있는 방식으로 구축 및 운영되도록 보장하기 위해 높은 수준의 투자를 유지해야 합니다.애플리케이션과 데이터베이스는 항상 실행되어 고객 요구를 충족하고 회사 생산성과 수익을 극대화해야 합니다.IT 비즈니스 연속성의 중요성은 그 어느 때보다도 중요합니다.

많은 IT 가용성 개념이 다음과 같이 떠돌고 있습니다. 내결함성(FT) , 고가용성 (하아) 그리고 재해 복구 (DR) .그러나 이것은 추가 질문을 제기할 수 있습니다.이러한 가용성 개념의 차이점은 무엇입니까?내 인프라에 적합한 것은 무엇입니까?결합하거나 교환할 수 있습니까? 가용성 이니셔티브의 첫 번째이자 가장 중요한 단계는 명확한 애플리케이션/데이터베이스 가용성 서비스 수준 계약(SLA)을 설정하는 것입니다.그런 다음 가장 적합한 가용성 접근 방식을 정의합니다.

SLA란 무엇입니까?

어느 정도까지는 SLA가 무엇인지 모두 알고 있지만 이 논의를 위해 우리 모두가 동일한 파장에 있는지 확인합시다. 가용성 SLA는 애플리케이션/데이터베이스 가동 시간 및 액세스 가능성의 예상 수준을 정의하는 서비스 공급자와 최종 사용자 간의 계약으로, 합의된 서비스 수준이 그렇지 않은 경우 공급업체가 관련 처벌(일반적으로 재정적)을 보장하고 개략적으로 설명합니다. 만났다.IT 세계에서 SLA는 RTO(복구 시간 목표) 및 RPO(복구 시점 목표)라는 두 가지 비즈니스 중요도 측정에서 위조됩니다.아주 간단하게, RTO는 장애 발생 시 애플리케이션 작업을 얼마나 빨리 복원해야 하는지 정의합니다. RPO는 복구 시나리오의 경우 데이터가 얼마나 최신 상태여야 하는지 정의합니다. 애플리케이션 및 데이터베이스에 대한 이러한 메트릭을 식별할 수 있으면 SLA가 정의됩니다.SLA는 백분율로 측정되므로 예를 들어 99.9% 또는 99.99%와 같은 용어를 사용할 수 있습니다.이는 IT 부서가 해당 연도에 애플리케이션에 대해 몇 분의 가동 시간 및 가용성을 보장하는지 측정한 것입니다. 일반적으로 더 많은 보호는 더 많은 비용을 의미합니다. 따라서 응용 프로그램 또는 데이터베이스의 가동 중지 시간 비용을 추정하고 이 SLA를 비즈니스에 적합한 솔루션을 선택하는 도구로 사용하는 것이 중요합니다.

SLA가 확보되면 FT, HA, DR 또는 이들의 조합 중 어떤 유형의 솔루션이 가용성 요구 사항에 가장 적합한 접근 방식인지에 대한 비즈니스 결정을 내릴 수 있습니다.

내결함성(FT)이란 무엇입니까?

FT는 99.999%로 매우 인상적인 가용성 SLA를 제공합니다.실제 환경에서 FT 솔루션은 1년에 5.25분 이하의 다운타임을 보장합니다.기본적으로 두 개의 동일한 서버가 서로 병렬로 실행되어 "록스텝" 프로세스라고 하는 활성-활성 구성에서 두 서버의 트랜잭션을 동시에 처리합니다. 1차 서버가 실패하면 2차 서버는 애플리케이션 중단이나 데이터 손실 없이 처리를 계속합니다.최종 사용자는 서버 오류가 발생했음을 다행스럽게도 인식하지 못할 것입니다.

이것은 환상적인 소리입니다!이것은 훌륭하게 들립니다!왜 다른 것이 필요할까요?그러나 잠시만요… FT가 종이에 들리는 것처럼 굉장하지만 고려해야 할 몇 가지 주의 사항이 있습니다.

"록스텝" 프로세스는 이상한 짐승입니다.특히 프로세서 측면에서 실행할 수 있는 서버 하드웨어 유형에 대해 매우 까다롭습니다.이 제한된 하드웨어 호환성 목록으로 인해 FT 솔루션은 관련 지원 및 서비스가 포함된 둘 이상의 FT 클러스터를 고려할 때 수십만 달러가 될 수 있는 가장 높은 비용 브래킷에 위치하게 됩니다.

소프트웨어 오류 취약성

FT 솔루션은 또한 하드웨어 내결함성을 염두에 두고 설계되었으며 잠재적인 애플리케이션 오류에 많은 관심을 기울이지 않습니다.FT 솔루션은 동일한 트랜잭션과 프로세스를 동시에 실행하므로 기본 서버에 애플리케이션 오류가 있는 경우 보조 서버에도 복제됩니다.

고가용성(HA)이란 무엇입니까?

대부분의 SLA에서 FT는 평균 사용 사례를 구매하고 관리하기에는 너무 비쌉니다.대부분의 경우 HA 솔루션이 더 나은 옵션입니다. 적은 비용으로 거의 동일한 수준의 보호 기능을 제공합니다.HA 솔루션은 Active-Standby 방식으로 배포하여 1년에 약 52분의 다운타임에 해당하는 99.99% SLA를 제공합니다.작업이 재개되기 전에 활성 서버가 대기 서버로 전환되어야 하는 짧은 기간의 가동 중지 시간이 있기 때문에 감소된 SLA가 도입되었습니다.좋습니다. 이것은 FT 솔루션만큼 인상적이지는 않지만 대부분의 IT 요구 사항에 대해 HA는 CRM 및 ERP 시스템과 같은 매우 중요한 응용 프로그램의 경우에도 SLA를 충족합니다.

마찬가지로 중요한 고가용성 솔루션은 애플리케이션에 구애받지 않으며 애플리케이션 장애 및 하드웨어 또는 OS 장애 발생 시 서버 장애 조치를 관리할 수도 있습니다. 또한 훨씬 더 많은 구성 유연성을 허용합니다.대부분의 경우 기본 OS가 지원되는 모든 플랫폼에서 실행되기 때문에 처리할 FT와 같은 하드웨어 호환성 목록이 없습니다.

재해 복구(DR)가 그림에 어떻게 들어맞습니까?

FT 및 HA와 마찬가지로 DR도 중요한 비즈니스 기능을 지원하는 데 사용할 수 있습니다. 그러나 DR은 FT 및 HA와 함께 사용할 수 있습니다.내결함성 및 고가용성은 데이터 센터(또는 클라우드 가용성 영역) 내와 같은 로컬 수준에서 가동 시간을 유지하는 데 중점을 둡니다.DR은 재해가 기본 데이터 센터에 충돌하는 경우 장애 조치할 중복 사이트 또는 데이터 센터를 제공합니다.

이 모든 것은 무엇을 의미합니까?

하루가 끝나면 취해야 할 잘못된 접근 방식이나 올바른 가용성 접근 방식이 없습니다.이는 보호하려는 비즈니스 프로세스의 중요성과 솔루션의 기본 경제성으로 귀결됩니다.일부 시나리오에서는 간단합니다.예를 들어, 원자력 발전소를 운영하고 있다면 중요한 작업이 FT 시스템으로 보호된다는 것이 더 편안할 것입니다. 그것을 직시하자, 당신은 아마 거기에서 서비스가 중단되는 것을 원하지 않을 것입니다.그러나 대부분의 IT 환경에서 중요한 가동 시간은 훨씬 더 소화 가능한 가격대로 HA와 함께 제공될 수도 있습니다.

선택 방법: FT, HA 및 DR?

• 무엇보다도 비즈니스 운영을 자세히 이해하고 다운타임 비용을 파악하십시오.
• SLA가 설정되면 잠재적인 다운타임 비용과 선택한 가용성 솔루션의 비용을 비교해 보십시오.
• 가용성 솔루션을 선택할 때는 배포 용이성과 사용 용이성을 고려하십시오. 이는 가용성 솔루션의 전체 TCO에도 영향을 미치기 때문입니다.

IT 시스템은 강력하지만 가장 불편한 시간에 잘못될 수 있습니다. FT, HA 및 DR은 이 즉각적이고 편리하게 주도되는 세상에서 고객에게 SLA를 제공할 때 귀하를 보호하는 보험 정책입니다.

의 허가를 받아 재생산 시오스

IO 병목 현상을 방지하는 방법: Windows 클라우드 배포를 위한 DataKeeper 인텐트 로그 배치 지침

최적의 애플리케이션 성능을 보장하기 위해 배포 시 SIOS 데이터 키퍼 배치하는 것이 중요합니다 의도 로그 (비트맵 파일)을 사용 가능한 가장 낮은 대기 시간 디스크에 저장하여 IO 병목 현상을 방지합니다. AWS, GCP 및 Azure에서 사용 가능한 가장 짧은 지연 시간 디스크는 임시 드라이브입니다. 그러나 Azure에서는 임시 드라이브를 사용하는 것과 Premium SSD를 사용하는 것의 차이가 최소화되므로 Azure에서 DataKeeper를 실행할 때 임시 드라이브를 사용할 필요가 없습니다. 그러나 AWS 및 GCP에서는 의도 로그를 임시 드라이브로 재배치하는 것이 필수적입니다. 그렇지 않으면 쓰기 처리량이 크게 영향을 받습니다.

비트맵 파일에 임시 디스크를 활용할 때 절충점이 있습니다. 임시 드라이브의 특성은 이 드라이브에 저장된 데이터의 지속성이 보장되지 않는다는 것입니다. 실제로 클라우드 인스턴스가 콘솔에서 중지되면 인스턴스에 연결된 임시 드라이브는 폐기되고 새 드라이브가 인스턴스에 연결됩니다. 이 프로세스에서 비트맵 파일은 삭제되고 비어 있는 새 비트맵 파일이 그 자리에 놓입니다.

비트맵 파일이 손실되면 완전한 재동기화가 발생하는 특정 시나리오가 있습니다. 예를 들어 주 서버가 SANless 클러스터 r이 콘솔에서 종료되면 장애 조치가 발생하지만 서버가 다시 온라인 상태가 되면 미러의 새 소스에서 이전 소스로 완전한 재동기화가 발생합니다. 이것은 자동으로 발생하므로 사용자는 어떤 조치도 취할 필요가 없으며 활성 노드는 이 재동기화 기간 동안 온라인 상태를 유지합니다.

비트맵 파일 배치가 성능에 영향을 줄 수 있는 다른 시나리오도 있습니다. 예를 들어 NVMe 드라이브를 복제하는 경우 NVMe 드라이브에 비트맵 파일을 보관할 작은 파티션을 만들고 싶을 것입니다. 일반적으로 비트맵 파일은 인스턴스에서 사용 가능한 가장 빠르고 대기 시간이 짧은 디스크에 있어야 합니다. 또한 다른 IO 작업으로 과도하게 부담되지 않는 디스크에 있어야 합니다.

의도 로그를 재배치하는 방법에 대한 정보는 다음에서 찾을 수 있습니다. DataKeeper 문서 . 의도 로그가 사용되는 방법에 대한 추가 정보는 DataKeeper 문서 .

의 허가를 받아 재생산 시오스

AWS EC2 클라우드에서 중요한 SAP S/4 HANA를 보호하는 선도적인 미디어 플랫폼

SAP, Amazon Web Services 및 Red Hat Linux에 대한 인증 및 검증을 기반으로 SIOS 선택

이 선도적인 미디어 조직은 매주 싱가포르의 거의 모든 성인에게 다가갑니다. 디지털, 텔레비전, 라디오, 인쇄 및 가정 외 미디어에 걸쳐 미국에서 가장 광범위한 미디어 플랫폼을 통해 4개 언어(영어, 북경어, 말레이어 및 타밀어)로 50개 이상의 제품 및 브랜드를 제공합니다.

환경

회사는 사용 SAP S/4 HANA 애플리케이션 그리고 HANA 데이터베이스 조직 전체의 운영을 강화하여 여러 부서의 운영을 통합합니다. 그들은 온프레미스 데이터 센터의 Red Hat Linux 환경에서 이러한 중요한 애플리케이션과 데이터베이스를 실행하고 있었습니다. 이러한 필수 시스템을 가동 중지 및 재해로부터 보호하는 것은 이 조직의 IT 팀의 최우선 과제입니다.

도전

미디어 조직의 IT 팀은 SAP 애플리케이션과 HANA 데이터베이스를 AWS EC2 클라우드로 이전함으로써 상당한 비용 절감을 실현할 수 있음을 인식했습니다. 그러나 마이그레이션이 성공하려면 기존 SAP 환경을 중단 없이 AWS로 "리프트 앤 시프트"하는 고가용성(HA) 및 재해 복구(DR) 솔루션이 필요했습니다.

평가

회사의 IT 팀은 클라우드에서 99.99% 가용성 SLA를 충족하기 위해 신뢰할 수 있는 HA/DR 솔루션을 원했습니다. 솔루션은 SAP와 AWS 모두의 인증을 받아야 했으며 Red Hat Linux 운영 체제를 지원해야 했습니다. 마지막으로, 이러한 중요한 워크로드에 대해 완전한 DR 보호를 제공할 수 있도록 하려면 여러 AWS 가용 영역(AZ)에서 장애 조치할 클러스터링 솔루션이 필요했습니다. AWS 솔루션 설계자는 조직에서 Linux 클러스터링 소프트웨어용 SIOS LifeKeeper를 사용할 것을 권장했습니다. 회사의 IT 팀은 프로젝트를 완료하기 위한 짧은 일정이 있었고 진행을 방해하지 않으면서 요구 사항을 충족할 수 있는 HA 공급업체를 선택해야 했습니다.

해결책

그들은 SIOS LifeKeeper가 우리의 모든 기준을 충족했을 뿐만 아니라 SIOS 팀이 매우 빠르게 조직되어 클라우드 마이그레이션 프로젝트를 일정에 맞게 유지할 수 있었기 때문에 SIOS LifeKeeper를 선택했습니다. SIOS Lifekeeper는 Red Hat 및 AWS EC2 클라우드 환경의 고가용성에 대해 AWS와 SAP 모두에서 인증을 받았습니다. SIOS 솔루션은 AWS 가용 영역 전반에 걸쳐 중복성을 복제하고 제공할 수 있기 때문에 또 다른 주요 기준을 충족했습니다. 조직의 IT 팀은 하루 24시간 연중무휴로 질문에 답변하고 지원을 제공할 수 있는 SIOS의 전담 현지 지원 팀에 깊은 인상을 받았습니다. 일주일. 조직에는 현재 AWS EC2의 여러 가용 영역에서 실행되는 S/4 HANA 및 SAP HANA 애플리케이션을 보호하기 위해 Linux용 SIOS LifeKeeper를 사용하는 5쌍의 장애 조치 클러스터가 있습니다.

결과

소프트웨어를 사용한 이후로 가동 중지 시간이 연장되지 않아 가용성이 안정적이었습니다. 이 고객이 HA/DR 또는 애플리케이션 성능을 희생하지 않고 이러한 중요한 워크로드를 클라우드로 마이그레이션할 수 있게 함으로써 SIOS를 통해 상당한 비용 절감을 달성할 수 있었습니다."라고 그는 말했습니다. SIOS LifeKeeper의 Mediacorp의 용이성은 IT 관리 시간을 최소화하여 훨씬 더 많은 비용을 절약했습니다.

의 허가를 받아 재생산 시오스