6월 3, 2022 |
Linux용 SIOS Protection Suite/LifeKeeper의 이점Linux용 SIOS Protection Suite/LifeKeeper의 이점
의 허가를 받아 재생산 시오스 |
|||||||||||||||||||||
5월 29, 2022 |
Linux용 SIOS 보호 제품군/LifeKeeper – 통합 구성 요소Linux용 SIOS 보호 제품군/LifeKeeper – 통합 구성 요소시오스 Protection Suite에는 조직의 미션 크리티컬 시스템을 보호하기 위한 다음과 같은 소프트웨어 구성 요소가 포함되어 있습니다. 시오스 라이프키퍼시오스 LifeKeeper는 완벽한 내결함성 소프트웨어 솔루션 서버, 파일 시스템, 애플리케이션 및 프로세스에 대한 고가용성을 가능하게 합니다. LifeKeeper에는 사용자 정의된 내결함성 하드웨어가 필요하지 않습니다. LifeKeeper는 두 개 이상의 시스템을 네트워크로 그룹화하기만 하면 사이트별 구성 데이터를 생성하여 다음을 제공합니다. 자동 오류 감지 및 복구 . 장애가 발생한 경우 LifeKeeper는 장애가 발생한 서버에서 지정된 대기 서버로 보호된 리소스를 마이그레이션합니다. 사용자는 실제 전환 중에 잠시 중단됩니다. 그러나 LifeKeeper는 운영자 개입 없이 대기 서버에서 작업을 복원합니다. 시오스 데이터키퍼시오스 DataKeeper는 LifeKeeper 환경을 위한 통합 데이터 복제 기능을 제공합니다. 이 기능을 사용하면 LifeKeeper 리소스가 다음에서 작동할 수 있습니다. 공유 및 비공유 스토리지 환경 . 애플리케이션 복구 키트( 방주 에스)애플리케이션 복구 키트( 방주 s) LifeKeeper가 특정 애플리케이션 또는 서비스를 관리하고 제어할 수 있도록 하는 도구 및 유틸리티를 포함합니다. 언제 방주 특정 애플리케이션용으로 설치된 경우 LifeKeeper는 애플리케이션의 상태를 모니터링하고 실패할 경우 애플리케이션을 자동으로 복구할 수 있습니다. 이 복구 키트는 방해가 되지 않으며 LifeKeeper가 보호하기 위해 애플리케이션 내에서 변경할 필요가 없습니다. 의 일부로 사용할 수 있는 '기성품' 애플리케이션 복구 키트의 포괄적인 라이브러리가 있습니다. 시오스 보호 제품군 포트폴리오. 종류와 수량 방주 제공되는 s는 에디션에 따라 다릅니다. 시오스 보호 제품군을 구입했습니다. 의 허가를 받아 재생산 시오스 |
|||||||||||||||||||||
5월 25, 2022 |
고가용성, RTO 및 RPO고가용성, RTO 및 RPO고가용성(HA)은 99.99% 이상 작동하고 사용할 수 있는 컴퓨터 소프트웨어 또는 구성 요소를 나타내는 정보 기술 용어입니다. 애플리케이션 또는 시스템의 최종 사용자가 경험하는 서비스 중단 시간은 연간 52.5분 미만입니다. 이 수준의 가용성은 일반적으로 중복 서버, 네트워크, 저장소 및 소프트웨어를 사용하여 단일 장애 지점을 제거하여 응용 프로그램 가동 중지 시간을 줄이는 구성인 고가용성 클러스터링을 사용하여 달성됩니다. 복구 시간 목표( RTO ) 및 복구 지점 목표( RPO )?99.99%의 가용성 시간 외에도 고가용성 환경 또한 엄격한 복구 시간 및 복구 시점 목표를 충족합니다. 복구 시간 목표 ( RTO )은 애플리케이션 장애부터 애플리케이션 운영 및 가용성 복구까지의 경과 시간을 측정한 것입니다. 회사가 해당 애플리케이션을 중단할 수 있는 기간을 측정한 것입니다. 복구 시점 목표 ( RPO )는 다운타임 문제 이후 애플리케이션 가용성이 복원되었을 때 데이터가 얼마나 최신 상태인지 측정합니다. 장애 발생 시 허용할 수 있는 최대 데이터 손실량으로 종종 설명됩니다.시오스 고가용성 클러스터는 RPO 0과 RTO 분. 고가용성 클러스터란 무엇입니까?고가용성 클러스터에서 중요한 애플리케이션은 이중화를 위해 하나 이상의 보조 노드에 연결된 기본 서버 노드에서 실행됩니다. 다음과 같은 클러스터링 소프트웨어 시오스 LifeKeeper는 클러스터된 애플리케이션 및 종속 리소스를 모니터링하여 활성 노드에서 작동하는지 확인합니다. 시스템 수준 모니터링은 클러스터 노드 간의 간격 하트비트를 통해 수행됩니다. 주 서버에 장애가 발생하면 하트비트 시간 초과 간격이 초과된 후 보조 서버가 복구를 시작합니다. 응용 프로그램 수준 오류의 경우 클러스터링 소프트웨어는 활성 노드에서 응용 프로그램을 사용할 수 없음을 감지합니다. 그런 다음 장애 조치(failover)라고 하는 프로세스에서 애플리케이션과 종속 리소스를 보조 노드로 이동합니다. RTO 에스. 기존 장애 조치 클러스터에서 클러스터의 모든 노드는 동일한 공유 스토리지, 일반적으로 SAN(Storage Area Network)에 연결됩니다. SAN ). 장애 조치 후 보조 노드에 공유 스토리지에 대한 액세스 권한이 부여되어 엄격한 요구 사항을 충족할 수 있습니다. RPO 에스. 의 허가를 받아 재생산 시오스
|
|||||||||||||||||||||
5월 21, 2022 |
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에서 장애 조치 클러스터링 프로젝트를 시작하기 전에 필요한 주요 개념을 이해하려면 이 링크를 검토하십시오.
네트워크 구성 요소 구성이 섹션에서는 각 노드에 필요한 컴퓨팅 리소스, 네트워크 구조 및 이러한 구성 요소를 구성하는 데 필요한 프로세스에 대해 간략히 설명합니다. 인스턴스 생성 AWS 처음부터 EC2
Linux용 SIOS Protection Suite를 실행하도록 Linux 노드 구성Linux용 SIOS 보호 제품군 설치로그인 및 기본 구성중요 자원 보호IP 리소스가 보호되면 전환("대기" 노드가 "활성" 노드가 됨)을 시작하여 기능을 테스트합니다. |
|||||||||||||||||||||
5월 16, 2022 |
ZRS(영역 중복 저장소)가 있는 Azure 공유 디스크의 성능ZRS(영역 중복 저장소)가 있는 Azure 공유 디스크의 성능2021년 9월 9일 마이크로소프트 발표 일반 가용성 Azure Disk Storage용 ZRS(영역 중복 저장소) , Azure 공유 디스크 포함. 흥미로운 점은 이제 가용 영역(AZ)에 걸쳐 공유 스토리지 기반 장애 조치 클러스터 인스턴스를 구축할 수 있다는 것입니다.클러스터 노드가 서로 다른 AZ에 있으므로 사용자는 이제 99.99% 가용성 SLA에 대한 자격을 얻을 수 있습니다. 영역 중복 저장소를 지원하기 전에 Azure 공유 디스크는 LRS(로컬 중복 저장소)만 지원하여 클러스터 배포를 단일 AZ로 제한하여 사용자가 AZ가 오프라인이 될 경우 중단될 수 있었습니다. 그러나 ZRS를 사용하여 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에서 실행되도록 하려는 사람들을 볼 수 있었습니다. |