Linux용 SIOS Protection Suite/LifeKeeper의 이점

Linux용 SIOS Protection Suite/LifeKeeper의 이점

• 시오스 소프트웨어는 여러 운영 체제 버전 및 버전(Linux 및 Windows 모두)을 지원합니다.
  • 운영 체제에 관계없이 미션 크리티컬 리소스를 보호하기 위한 일관된 사용자 경험.
• 시오스 온프레미스, 가상화(VMware) 및 클라우드 환경(공개 플랫폼 포함)을 포함한 여러 환경을 위한 고가용성 솔루션을 제공합니다. AWS , Azure, Google Cloud 및 비공개 호스팅 클라우드 환경. 다른 환경에서 동일한 도구를 사용할 수 있습니다.
  • 하이브리드 환경도 지원됩니다. 프라이빗 클라우드에서 호스팅되는 보조 노드와 추가 DR(재해 복구) 옵션을 제공하는 퍼블릭 클라우드 플랫폼에 위치한 세 번째 노드를 사용하여 온프레미스 노드를 기본 위치로 구성할 수 있습니다.

• 시오스 애플리케이션 복구 키트( 방주 s), 엔터프라이즈 애플리케이션 및 데이터베이스의 세계 최고의 제공업체에서 사용할 수 있습니다.
  • 우리의 포괄적인 라이브러리 방주 s는 '기성품' 애플리케이션의 가장 광범위한 범위를 보호합니다.
  • 기타 '비표준' 또는 레거시 애플리케이션은 내장된 'GenApp'으로 보호할 수 있습니다. 방주 또는 관습을 개발함으로써 방주 사내에서 또는 협력하여 시오스 엔지니어.

• 오픈 소스 도구(사용자가 사전에 환경 매개변수를 수동으로 설정한 다음 복잡한 명령줄 매개변수 세트를 입력해야 함)와 달리 일련의 마법사 기반 설치 및 구성 화면을 통해 보호가 필요한 리소스를 직관적으로 선택할 수 있으며 선택에 도움이 됩니다. 제공될 보호의 유형 및 범위.
  • 마법사는 시스템과 환경을 검색하여 보호할 리소스를 식별합니다. 대부분의 경우 운영자는 기본 선택을 확인하고 고유한 환경별 호스트 ID 등을 입력하기만 하면 설치가 완료됩니다.
  • 이렇게 하면 HA 솔루션이 잘못 구성될 가능성과 시스템 또는 애플리케이션 오류로 인한 불가피한 예기치 않은 가동 중지 시간이 줄어듭니다.
• 시오스 24×7 중요 지원을 포함한 포괄적인 범위의 기술 지원 옵션을 제공하며, 가용 예산, 시스템 복잡성 또는 고가용성을 요구하는 애플리케이션의 중요도에 맞춘 지원 옵션을 제공합니다.

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

Linux용 SIOS 보호 제품군/LifeKeeper – 통합 구성 요소

Linux용 SIOS 보호 제품군/LifeKeeper – 통합 구성 요소

시오스 Protection Suite에는 조직의 미션 크리티컬 시스템을 보호하기 위한 다음과 같은 소프트웨어 구성 요소가 포함되어 있습니다.

시오스 라이프키퍼

시오스 LifeKeeper는 완벽한 내결함성 소프트웨어 솔루션 서버, 파일 시스템, 애플리케이션 및 프로세스에 대한 고가용성을 가능하게 합니다. LifeKeeper에는 사용자 정의된 내결함성 하드웨어가 필요하지 않습니다. LifeKeeper는 두 개 이상의 시스템을 네트워크로 그룹화하기만 하면 사이트별 구성 데이터를 생성하여 다음을 제공합니다. 자동 오류 감지 및 복구 .

장애가 발생한 경우 LifeKeeper는 장애가 발생한 서버에서 지정된 대기 서버로 보호된 리소스를 마이그레이션합니다. 사용자는 실제 전환 중에 잠시 중단됩니다. 그러나 LifeKeeper는 운영자 개입 없이 대기 서버에서 작업을 복원합니다.

시오스 데이터키퍼

시오스 DataKeeper는 LifeKeeper 환경을 위한 통합 데이터 복제 기능을 제공합니다. 이 기능을 사용하면 LifeKeeper 리소스가 다음에서 작동할 수 있습니다. 공유 및 비공유 스토리지 환경 .

애플리케이션 복구 키트( 방주 에스)

애플리케이션 복구 키트( 방주 s) LifeKeeper가 특정 애플리케이션 또는 서비스를 관리하고 제어할 수 있도록 하는 도구 및 유틸리티를 포함합니다. 언제 방주 특정 애플리케이션용으로 설치된 경우 LifeKeeper는 애플리케이션의 상태를 모니터링하고 실패할 경우 애플리케이션을 자동으로 복구할 수 있습니다. 이 복구 키트는 방해가 되지 않으며 LifeKeeper가 보호하기 위해 애플리케이션 내에서 변경할 필요가 없습니다.

의 일부로 사용할 수 있는 '기성품' 애플리케이션 복구 키트의 포괄적인 라이브러리가 있습니다. 시오스 보호 제품군 포트폴리오. 종류와 수량 방주 제공되는 s는 에디션에 따라 다릅니다. 시오스 보호 제품군을 구입했습니다.

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

고가용성, RTO 및 RPO

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

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 공유 디스크의 성능

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를 사용하여 발생할 수 있는 추가 쓰기 대기 시간을 측정했습니다. 물론 결과는 작업 부하, 디스크 유형, 인스턴스 크기 등에 따라 다르지만 여기 내 결과가 있습니다.

내가 실행한 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에 배치하면 어떻게 될지 궁금했습니다.

결과는 다음과 같습니다.

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

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

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

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