| 5월 16, 2022 |
ZRS(영역 중복 저장소)가 있는 Azure 공유 디스크의 성능 |
| 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, 고가용성 및 재해 복구 – 시작 위치
가용성 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 인텐트 로그 배치 지침
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를 보호하는 선도적인 미디어 플랫폼
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 관리 시간을 최소화하여 훨씬 더 많은 비용을 절약했습니다.
의 허가를 받아 재생산 시오스
다운타임으로부터 시스템 보호
다운타임으로부터 시스템 보호
오늘날의 비즈니스 환경에서 조직은 SAP, SQL Server, Oracle 등과 같은 애플리케이션, 데이터베이스 및 ERP 시스템에 의존합니다. 이러한 애플리케이션은 가장 중요한 비즈니스 운영을 통합하고 간소화합니다. 실패하면 돈보다 더 많은 비용이 듭니다. 이러한 복잡한 시스템을 다운타임으로부터 보호하는 것이 중요합니다.
입증된 고가용성 및 재해 복구
SIOS는 20년 이상의 경험을 가지고 있습니다. 고가용성 그리고 재해 복구 .SIOS는 모든 솔루션에 딱 맞는 사이즈가 없다는 것을 알고 있습니다. 오늘날의 데이터 시스템은 온프레미스, 퍼블릭 클라우드, 하이브리드 클라우드 및 멀티 클라우드 환경의 조합입니다. 애플리케이션 자체로 인해 훨씬 더 복잡해질 수 있습니다. 그러나 오픈 소스 클러스터 소프트웨어를 구성하는 것은 힘들고 시간이 많이 걸리며 인적 오류가 발생하기 쉽습니다.
SIOS는 중요한 애플리케이션을 위한 고가용성 및 재해 복구를 제공하는 솔루션을 보유하고 있습니다. 이러한 솔루션은 다양한 산업 및 사용 사례 전반에 걸쳐 당사의 실제 경험을 기반으로 개발되었습니다. 우리의 제품은 다음을 포함합니다 Windows용 SIOS DataKeeper 클러스터 에디션 그리고 Linux용 SIOS LifeKeeper 또는 Windows. 이러한 강력한 애플리케이션은 장애 조치 보호를 제공합니다. LifeKeeper에 포함된 애플리케이션 복구 키트는 구성을 자동화하고 입력을 검증하여 애플리케이션 구성 시간을 단축합니다.
온프레미스, 클라우드 또는 하이브리드 환경에서 시스템 보호
SIOS는 온프레미스, 클라우드 또는 하이브리드 클라우드 환경에서 비즈니스 크리티컬 애플리케이션에 필요한 보호 기능을 제공하고 관리 복잡성을 줄입니다. 아래 비디오에서 당사에 대해 자세히 알아보거나 문의하기 비즈니스 크리티컬 애플리케이션을 위한 고가용성 및 재해 복구에 대해 자세히 알아보십시오.
의 허가를 받아 재생산 시오스