SIOS SANless clusters – 페이지 31

11월 23, 2022	Azure 고가용성 모범 사례의 SAP Azure 고가용성 모범 사례의 SAP 다음 비디오에서는 SAP에서 20년의 경험을 가진 Microsoft의 수석 SAP 설계자 Bala Anbalagan이 Azure에서 SAP 솔루션을 보호하기 위해 고가용성을 구성하는 모범 사례를 설명합니다. 또한 클라우드에서 HA 솔루션을 구현할 때 자주 저지르는 실수와 사용자가 SIOS LifeKeeper를 구성할 때 알아야 할 주요 요소를 검토합니다. 클라우드에서 SAP 고가용성 솔루션 구성 Bala는 모든 SAP 사용자가 고가용성 솔루션은 특히 클라우드에서 없어서는 안 될 필수 요소입니다. 모든 클라우드 공급자는 환경을 변경해야 합니다. 하드웨어 인프라에 대한 서비스 수준이 높더라도 SAP 시스템이 완전히 다운될 수 있는 짧은 기간의 가동 중지 시간이 있습니다. 사용자가 SAP HA를 적절하게 구성하는 것도 중요합니다. HA 솔루션을 설치하는 주된 목적은 가동 중지 시간으로부터 보호하는 것이지만 제대로 수행하지 않으면 실행 중인 클라우드에 관계없이 시간과 비용을 낭비할 뿐입니다. 클라우드 공급자의 구성 규칙을 따르는 것이 중요합니다. HA를 잘못 구성하거나 장애 조치 및 장애 복구 테스트에 실패하면 예상치 못한 상황, 특히 활용도가 높은 기간에 비즈니스 중단이 발생할 수 있습니다. SIOS 라이프키퍼 구성 프로세스 중에 오류를 감지할 수 있습니다. 예를 들어 HA 클러스터의 노드 간에 항상 중복 통신 채널 또는 보조 네트워크 연결을 원하므로 단일 통신 채널만 구성하는 경우 경고를 보냅니다. 당신이 사용하는 경우 SIOS 데이터키퍼 , 복제 프로세스 중에 구성에 문제가 있으면 경고도 표시됩니다. SIOS를 간단하게 구성하는 이유는 무엇입니까? SIOS에는 매우 간단한 구성 프로세스가 있습니다. 기본적으로 각 클러스터 노드에 LifeKeeper를 설치하고 복구하려는 애플리케이션에 따라 다양한 유형의 SIOS 애플리케이션별 복구 키트(ARK) 모듈(LifeKeeper와 함께 제공)을 사용하기만 하면 됩니다. 또한 간단한 GUI로 프로세스를 따라가기가 매우 쉽습니다. 인텔리전스가 내장되어 있어 GUI의 세부 정보를 변경할 필요가 없습니다. 대부분의 정보를 자동으로 감지하여 설정 프로세스를 더욱 단순화합니다. 사용할 ARK와 사용 방법을 아는 것은 구성 프로세스에서 중요합니다. ARK는 LifeKeeper 소프트웨어에 애플리케이션별 인텔리전스를 제공하는 소프트웨어 모듈입니다. SIOS는 다양한 애플리케이션에 대해 별도의 ARK를 제공합니다. 예를 들어 SAP HANA의 경우 SIOS를 설치합니다. SAP HANA 아크 SAP의 모범 사례를 유지하면서 LIfeKeeper가 구성 단계를 자동화하고, 장애를 감지하고, SAP HANA에 대한 안정적인 장애 조치를 관리할 수 있도록 합니다. Azure에서 SAP용 HA 구현 시 가장 큰 실수 사용자가 일반적으로 구현 Azure의 SAP 솔루션용 HA 온프레미스 환경에서와 동일한 프로세스를 사용합니다. 그들은 사고 방식을 바꿀 필요가 있습니다. 항상 클라우드 공급자가 제공한 권장 사항을 따르십시오. 즉, 클라우드 공급자가 권장하는 대로 문서를 읽고 매개변수를 유지하십시오. 또 다른 일반적인 실수는 너무 많은 복잡성을 추가하는 것입니다. 일부 고객은 단일 클러스터에 모든 것을 넣지만 서버마다 클러스터를 분리해야 합니다. 클러스터를 너무 크게 만들면 불필요한 복잡성과 잠재적 위험이 추가됩니다. HA 클러스터링과 관련하여 모든 측면에서 철저한 테스트가 중요합니다. 가동되기 전에 주기적으로(그리고 자주) HA 구성을 테스트하는 것이 예상치 못한 다운타임을 방지하기 위해 할 수 있는 최선의 방법입니다. 자세히 알아보기 SAP 고가용성 아래 비디오의 모범 사례 또는 문의하기 클라우드에서 필수 애플리케이션에 대한 고가용성 및 재해 복구 구현에 대한 자세한 내용을 보려면 여기를 클릭하세요. 의 허가를 받아 복제됨 시오스
11월 20, 2022	단순한 HA 및 DR 시대는 지났습니다. 단순한 HA 및 DR 시대는 지났습니다. TV 채널을 넘기다가 Drew Barrymore와 함께한 영화 "He's Just Not That Into You"의 한 장면을 우연히 발견했습니다. 하나의 전화번호와 하나의 자동응답기가 있었고 그 자동응답기 하나에는 카세트테이프 하나가 있었고 그 카세트테이프 하나에는 남자가 보낸 메시지가 있거나 없었습니다. 이제 7가지 다른 기술에 의해 거부당하기 위해 이 모든 다른 포털을 확인하기만 하면 됩니다. 지쳤어.” 때로는 클라우드가 하나만 있거나 클라우드 플랫폼이 없기를 바라지 마십시오. 하나의 OS에서 실행되는 하나의 DB; 걱정할 프런트 엔드 애플리케이션만 있으면 됩니다. 그러나 세상은 변했고 더 빠르게 움직이고 있으며 더 복잡해지고 있습니다.기술의 발전, 인수합병의 결과, 수십억 명의 소비자가 최신 거래와 최고의 경험을 찾는 연중무휴 24시간 사회의 증가하는 욕구와 속도는 단순한 날이 사라 졌다는 것을 의미합니다. 가용성에 대한 4가지 어려운 진실 귀하의 솔루션은 생각만큼 간단하지 않습니다 물론 기업 환경은 단순하지 않습니다.펀치 카드 이후로 거의 존재해 온 레거시 시스템과 애플리케이션이 있습니다.차세대 애플리케이션 및 데이터베이스용으로 만들어진 새로운 시스템이 있습니다.또한 한 플랫폼에서 다른 플랫폼으로 마이그레이션하는 사이의 간격을 메우거나 시간을 맞추기 위해 10년 전에 만든 솔루션이 있지만 최선의 노력에도 불구하고 이러한 시스템은 남아 있습니다. 이러한 문제에 U 회사의 인수 합병으로 인해 증가하는 시스템 및 IT 리소스 세트가 추가되었습니다. 새로운 시대에 HA를 제공하는 것은 생각만큼 간단하지 않습니다. 잘못된 아키텍처는 생각보다 더 큰 문제입니다. 고객 경험 부사장으로서 잘못된 아키텍처로 인한 피해를 목격했습니다.HA 소프트웨어를 배포하면 응용 프로그램과 데이터베이스의 가용성을 개선하는 데 확실히 도움이 될 수 있지만 HA 소프트웨어는 불완전한 요구 사항, 빈약한 네트워킹, 중복 하드웨어 부족 또는 기타 누락된 아키텍처 구성 요소를 완전히 극복할 수 없습니다.우리 팀은 피크 운영 시간 동안 시스템을 불안정하게 만드는 작은 규모의 환경을 수정하기 위해 고객과 협력한 적이 있습니다.네트워킹 및 하드웨어 불안정성을 포함하는 잘못된 아키텍처로 인해 팀은 종종 피할 수 있는 다운타임 문제를 복구하기 위해 허둥지둥하는 자신을 발견했습니다.완전하고 건전하며 가용성이 높고 탄력적인 솔루션을 갖추려면 건전한 아키텍처의 일부로 훌륭한 소프트웨어를 배포해야 합니다. 관리자는 인정하는 것보다 더 많은 도움이 필요합니다. 성장 가능성이 있는 견고한 아키텍처를 기반으로 구축된 엔터프라이즈급 고가용성 탄력적 HA 솔루션을 개발하는 것은 간단한 프로세스가 아닙니다.복원력, 애플리케이션 및 데이터 가용성을 위한 설계 및 설계는 선반에서 케이크 믹스 상자를 집는 것만큼 쉽지 않습니다.다양한 도구, 여러 팀의 프로세스, SLA 혼합, 다양한 OS, 애플리케이션, 데이터베이스 및 플랫폼을 투입하면 도움이 필요한 레시피를 갖게 됩니다. 최근에 저는 엔터프라이즈 지원 환경에서 일하는 20년 베테랑을 인터뷰했습니다.그는 얼마나 많은 동료들, 심지어는 자신도 중요한 엔터프라이즈 가용성 유지의 무게를 감당할 수 없었는지 설명했습니다.관리자는 치명적인 다중 시스템, 다중 애플리케이션, 거의 완전한 데이터 센터 붕괴를 처리하기 위해 새벽 2시 이후로 깨어 있을 때 도움이 필요할 뿐만 아니라, 기술적으로 복잡한 시대. 귀하의 솔루션은 귀하가 생각하는 것만큼 가용성이 높지 않을 수 있습니다. "퍼블릭 클라우드 공급자는 일반적으로 서비스 수준 계약에서 일정 수준의 가용성을 보장하지만 이러한 SLA는 클라우드 하드웨어에만 적용됩니다." 다음을 포함하여 클라우드 공급자 SLA가 적용되지 않는 애플리케이션 가동 중지에 대한 다른 많은 이유가 있습니다. 소프트웨어 문제 및 버그 인적 오류 소프트웨어 오류 시스템 또는 애플리케이션 중단 고객 경험 부사장으로서 재귀 루틴의 종료 실패로 인한 서비스 거부 공격, 시스템 고갈, 건전하고 중요한 애플리케이션의 보안 소프트웨어 격리, 커널 패닉, 임의로 재부팅합니다.HA 전략이 하이퍼바이저의 SLA에만 의존하는 경우 솔루션의 가용성이 생각만큼 높지 않을 수 있습니다. 중요한 애플리케이션을 다음과 같이 보호해야 합니다. 클러스터링 소프트웨어 문제를 모니터링 및 감지하고 문제에 안정적으로 대응하며 필요한 경우 작업을 대기 서버로 이동하여 제품과 서비스가 필요할 때 언제 어디서나 안정적이고 사용할 수 있도록 합니다. 우리의 단일 데이터 센터는 수십 개의 데이터 센터에 걸쳐 있는 일련의 클라우드 플랫폼이 되었습니다.우리의 스컹크 작업 애플리케이션은 Windows, Linux 및 몇 가지 다른 *Nix 변종에서 관리해야 하는 중요한 프런트 엔드, 미들웨어 및 백엔드 솔루션의 일부가 되었습니다.기술의 행진은 우리의 고가용성 더 복잡해지고 더 나은 아키텍처가 필요합니다.이는 또한 우리 팀이 모든 것을 관리하는 데 더 많은 도움이 필요하다는 것을 의미하며, 주의하지 않으면 우리가 취약하고 노출된 상태로 남아 있음을 의미할 수 있습니다.네 가지 진실 중 팀이 가장 직면하고 있는 것은 무엇입니까? Cassius Rhue, VP 고객 경험 시오스
11월 15, 2022	Windows용 SIOS LifeKeeper의 새로운 드라이버는 무엇을 합니까? Windows용 SIOS LifeKeeper의 새로운 드라이버는 무엇을 합니까? 공유 환경과 SAN이 없는 환경에서 향후 몇 년 동안 더 강력한 데이터 보호를 제공합니다. Coca-Cola, KitKat, SalesForce 및 Windows용 SIOS LifeKeeper 공통점?다음은 몇 가지 힌트입니다. 코카콜라는 특히 사회적 주제에 초점을 맞춰 미래에 적응하기 위해 상징적인 브랜드의 제품 재설계를 사용하는 캠페인을 다시 시작했습니다. Kit-Kat은 소셜 미디어, YouTube 및 일반적인 기술 물결의 호황을 기념하고 기념하고 Android(KitKat) OS의 브랜드 강점을 활용하기 위해 영국에서 캔디바를 리브랜딩했습니다. Salesforce는 기본 제품을 개편하여 고객의 요구 사항을 충족할 수 있도록 보다 세련되고 현대적이며 빠른 인터페이스를 만들었습니다. 이들 기업은 고객에게 더 나은 서비스를 제공하고 미래에 적응 및 준비하며 강점을 활용하기 위해 상징적인 제품, 서비스 및 솔루션을 크게 개선했습니다.유사한 방식으로 SIOS는 Windows용 SIOS LifeKeeper 제품을 크게 개선했습니다. LifeKeeper for Windows 버전 8.9.0 이전에는 I/O 펜싱, 드라이브 식별 및 관리를 포함한 공유 스토리지 기능이 NCR_LKF 드라이버에서 처리되었습니다.SIOS LifeKeeper for Windows 릴리스 버전 8.9.0부터 SIOS Technology Corp.는 공유 스토리지 드라이버 아키텍처를 재설계했습니다. 현재 릴리스부터 NCR_LKF 드라이버가 제거되고 SIOS DataKeeper / SIOS DataKeeper Cluster Edition의 SANless 스토리지 복제 뒤에 있는 엔진인 SIOS ExtMirr 드라이버로 대체되었습니다. Windows용 SIOS LifeKeeper의 NCR_LKF 아키텍처 변경의 5가지 중요한 이점: 더 현대적인 드라이버 ExtMirr 드라이버는 공유 스토리지 기능을 관리하기 위한 최신 필터 드라이버를 제공합니다.NCR_LKF 드라이버는 "표시등 켜기" 및 "데이터 안전"에 중점을 두었지만 드라이버의 아키텍처는 최신 드라이버보다 뒤처졌습니다.ExtMirr 드라이버는 이러한 데이터 보호를 유지하는 동시에 최신 버전의 Windows OS에서 더 호환되고 현대적이며 더 쉽게 지원됩니다. 보다 강력한 I/O 펜싱 SIOS DataKeeper 및 SIOS DataKeeper Cluster Edition 모두에서 사용되는 드라이버에는 강력한 펜싱 아키텍처가 포함되어 있습니다. NCR_LKF 드라이버는 I/O 펜싱이 가능했지만 새 드라이버는 더 강력하며 SAN 및 SANless 환경에서 테스트되었습니다. 향상된 I/O 펜싱은 보호된 볼륨 내에서 볼륨 잠금 및 노드 소유권 정보를 활용합니다. 더 긴밀한 통합 및 호환성. DataKeeper 제품에 사용되는 ExtMirr 드라이버용 I/O 펜싱을 활용한다는 것은 DataKeeper 제품 라인과의 통합에서 Windows용 LifeKeeper 솔루션이 증가한다는 것을 의미합니다.ExtMirr 드라이버에는 최신 버전도 포함되어 있습니다. Microsoft 드라이버 서명 드라이버 서명 및 보안 부팅을 시행하는 운영 체제와 원활하게 작동합니다. 더 쉬운 관리 ExtMirr 드라이버는 고객과 관리자에게 볼륨 상태를 얻고 관리하기 위한 대규모 명령줄 유틸리티 세트를 제공합니다.emcmd 명령은 SIOS DataKeeper 제품 모두에 고유합니다. 이제 SIOS LifeKeeper 공유 볼륨 구성을 통해 더 쉽게 관리할 수 있습니다. Windows용 LifeKeeper 제품과 함께 공유 스토리지 및 복제된 구성을 모두 활용하는 고객 및 파트너는 이제 알고 사용할 수 있는 단일 명령줄 도구 세트를 갖게 되었습니다. emcmd 도구는 관리(잠금, 잠금 해제 등)를 위한 이전의 volume.exe, volsvc 및 유사한 NCR_LKF 필터 드라이버 도구를 대체합니다. 더 자주 업데이트 및 수정 Windows용 SIOS LifeKeeper에 ExtMirr 드라이버를 추가하면 공유 스토리지 구성과 복제 구성이 이제 업데이트, 새로운 기능 및 수정 사항에서 향상됩니다. NCR_LKF 드라이버는 I/O 펜싱을 위한 견고한 토대와 안정적인 기반을 제공했지만 ExtMirr 드라이버로 전환하면 새로운 제품 지원을 위해 더 빠른 업데이트를 통해 고객이 동일한 강도와 안정성을 볼 수 있습니다. Lightning 업데이트에 대한 SalesForce Classic만큼 화려하지만 중요한 기능을 추가하고 SIOS DataKeeper 및 SIOS LifeKeeper 솔루션 모두의 강도와 수명을 늘리며 앞으로 몇 년 동안 공유 및 SAN 없는 환경에서 데이터 보호를 강화할 것입니다. Cassius Rhue, VP 고객 경험 시오스
11월 11, 2022	크기 정보가 올바른지 확인하기 위해 파일 시스템 및 미러 리소스를 다시 만드는 방법 크기 정보가 올바른지 확인하기 위해 파일 시스템 및 미러 리소스를 다시 만드는 방법 고가용성(HA) 클러스터링으로 작업할 때 클러스터의 모든 노드 구성이 서로 병렬인지 확인하는 것이 중요합니다. 이러한 '미러링된' 구성은 클러스터의 장애 지점을 최소화하여 더 높은 수준의 HA 보호를 제공합니다. 예를 들어 소스 노드에서 미러 크기가 업데이트되었지만 대상 노드에서 동일한 정보가 업데이트되지 않은 상황을 보았습니다. 미러 크기 불일치로 인해 장애 조치 시 대상 노드에서 LifeKeeper가 시작되지 않았습니다. 다음은 소스와 동일한 크기 정보를 사용하여 대상 노드에서 미러 리소스를 재생성하기 위한 권장 단계입니다. 단계: 애플리케이션의 관점에서 소스 노드의 데이터가 유효하고 일관성이 있는지 확인합니다. 소스(미러의 소스)에서 파일 시스템 백업 /opt/LifeKeeper/bin/lkbackup -c를 실행하여 두 노드에서 LifeKeeper 구성을 백업합니다. 모든 자원을 서비스에서 제외하십시오.이 예에서 리소스는 노드 sc05에서 서비스 중이고 sc05는 미러의 소스입니다(그리고 sc06은 미러의 대상 시스템/대상입니다). LifeKeeper GUI의 오른쪽 창에서 DataKeeper 리소스 서비스 중입니다. 딸깍 하는 소리 서비스 중단 자원 팝업 메뉴에서. 선택한 리소스를 서비스에서 제외할 것인지 확인하는 대화 상자가 나타납니다. 작업과 관련된 모든 리소스 종속성은 대화 상자에 기록됩니다. 딸깍 하는 소리 다음. 서비스에서 제외되는 리소스의 결과를 보여주는 정보 상자가 나타납니다. 딸깍 하는 소리 완료. 모든 자원이 서비스에서 제외되고 파일 시스템이 마운트 해제되었는지 확인하십시오. 미러가 구성되지 않았는지 확인하려면 소스에서 cat /proc/mdstat 명령을 사용하십시오. 소스에서 mount 명령을 사용하여 파일 시스템이 더 이상 마운트되지 않도록 합니다. 소스에서 /opt/LifeKeeper/bin/lcdstatus -q를 사용하여 리소스가 모두 OSU인지 확인합니다. LifeKeeper GUI에서 IP 리소스(VIP)와 파일 시스템 리소스(/mnt/sps) 간의 종속성을 끊습니다.VIP 리소스를 마우스 오른쪽 버튼으로 클릭하고 종속성 삭제를 선택합니다. 그런 다음 하위 리소스 태그에 대해 파일 시스템 리소스(/mnt/sps)를 선택합니다. 이렇게 하면 IP 리소스(VIP)가 있는 계층과 파일 시스템 리소스(/mnt/fs) 및 미러 리소스(datarep-sps)가 있는 계층이 있습니다. 파일 시스템 및 미러 리소스가 있는 계층 구조를 삭제합니다. /mnt/sps를 마우스 오른쪽 버튼으로 클릭하고 리소스 계층 삭제를 선택합니다. 소스에서 파일 시스템에 대해 'mount <device> <directory>'를 수행합니다. 예: 마운트 /dev/sdb1 /mnt/sps GUI를 통해 다음을 통해 미러 및 파일 시스템을 다시 만듭니다. 복구 키트: 데이터 복제 스위치백 유형: 지능형 서버: 소스 노드 계층 유형: 기존 파일 시스템 복제 기존 마운트 지점: <마운트 지점 선택>. 이 예에서는 /mnt/sps입니다. 데이터 복제 리소스 태그: <기본값 사용> 파일 시스템 리소스 태그: <기본값 사용> 비트맵 파일: <기본값 사용> 비동기식 복제 활성화: 예 일단 생성되면 미러 및 파일 시스템 계층 구조를 확장할 수 있습니다. 대상 서버: 대상 노드 스위치백 유형: 지능형 템플릿 우선순위: 1 대상 우선 순위: 10 사전 확장 검사가 완료되면 다음을 선택하고 다음 값을 선택합니다. 대상 디스크: <미러 대상 디스크 선택>.이 예에서는 /dev/sdb1입니다. 데이터 복제 리소스 태그: <기본값 사용> 비트맵 파일: <기본값 사용> 복제 경로: <사용자 환경의 복제 경로 선택> 탑재 지점: <환경에서 탑재 지점 선택>.이 예에서는 /mnt/sps입니다. 루트 태그: <기본값 사용> 리소스 "확장"이 완료되면 "마침"을 선택한 다음 "완료"를 선택합니다. LifeKeeper GUI에서 IP 리소스(VIP)와 파일 시스템 리소스(/mnt/sps) 간의 종속성을 다시 만듭니다. VIP 리소스를 마우스 오른쪽 버튼으로 클릭하고 종속성 만들기를 선택합니다.하위 리소스 태그에 대해 /mnt/sps를 선택합니다. 이 시점에서 미러는 파일 시스템 크기의 전체 재동기화를 수행해야 합니다. LifeKeeper GUI의 오른쪽 창에 있는 LifeKeeper GUI에서 VIP 리소스를 마우스 오른쪽 버튼으로 클릭합니다. "In Service"를 선택하여 IP 리소스(VIP)를 복원하고 미러가 서비스 중인 소스 시스템(이 예에서는 sc05)을 선택한 다음 애플리케이션이 다시 시작되고 IP에 액세스할 수 있는지 확인합니다. 의 허가를 받아 복제됨 시오스
11월 9, 2022	전환, 장애 조치 및 복구 간의 미묘하지만 중요한 차이점 설명 전환, 장애 조치 및 복구 간의 미묘하지만 중요한 차이점 설명 고가용성은 전문 분야이며 대부분의 전문 분야와 마찬가지로 고유한 어휘와 용어가 있습니다. 우리 고객은 일반적으로 IT에 대해 매우 잘 알고 있지만 HA 환경에서 일한 적이 없다면 일반적인 HA 용어 중 일부가 그들과 우리 모두에게 상당한 혼란을 야기할 수 있습니다. 그것들은 단순해 보이지만 HA의 맥락에서 매우 구체적인 의미가 있습니다. 여기에서는 전환, 장애 조치 및 복구라는 세 가지 용어에 대해 설명합니다. 전환이란 무엇입니까 ? 전환은 *사용자 시작* 를 통한 조치 고가용성 (HA) 클러스터링 솔루션 사용자 인터페이스 또는 CLI. 전환 시 사용자는 *수동으로* 보호된 응용 프로그램의 소스 또는 기본 서버를 변경하는 작업을 시작합니다. 일반적인 전환 시나리오에서 실행 중인 모든 응용 프로그램 및 종속성은 상위 응용 프로그램에서 시작하여 모든 하위/종속성이 중지될 때 끝나는 순서대로 중지됩니다. 애플리케이션과 해당 종속성이 중지되면 새로 지정된 기본 또는 소스 서버에서 순서대로 다시 시작됩니다. 예를 들어 알파, 베타 및 감마 리소스가 있는 경우. 리소스 알파는 리소스 베타 및 감마에 따라 다릅니다. 리소스 베타는 리소스 감마에 따라 다릅니다.전환 이벤트에서 알파 리소스가 먼저 중지되고 베타가 중지되고 마지막으로 감마가 중지됩니다.세 가지가 모두 중지되면 전환은 계속해서 리소스를 의도한 서버의 작동 상태로 만듭니다.프로세스는 자원 Gamma에서 시작하여 Beta가 이어지며 마지막으로 Alpha 자원에 대한 시작 작업이 완료됩니다.전통적으로 전환 작업에는 리소스가 적절하고 질서 있는 방식으로 중지되어야 하므로 더 많은 시간이 필요합니다. 전환은 가동 시간을 유지하면서 소프트웨어 버전을 업데이트해야 하거나 기본 프로덕션 노드에서 유지 관리 작업(롤링 업그레이드를 통해)을 수행하거나 DR 테스트를 수행해야 할 때 수행되는 경우가 많습니다. 주요 요점 : 조치를 취하는 데 실패가 없다면 전환이었습니다. 장애 조치란 무엇입니까? 장애 조치 작업은 일반적으로 서버 충돌 또는 예기치 않은/계획되지 않은 재부팅에 대한 응답으로 사용자가 시작하지 않은 작업입니다. 노드 A와 노드 B의 두 노드가 있는 HA 클러스터의 시나리오를 고려하십시오.이 시나리오에서는 모든 중요 응용 프로그램 Alpha, Beta 및 Gamma가 노드 A에서 시작되고 작동합니다. 이 시나리오에서 장애 조치는 노드 A에 예기치 않은/계획되지 않은 재부팅, 전원 끄기, 중지 또는 패닉이 발생할 때 발생합니다. HA 소프트웨어가 노드 A가 더 이상 작동하지 않고 클러스터 내에서 작동 가능하지 않음을 감지하면(솔루션에서 정의한 대로), 장애 조치 작업을 트리거하여 사용 가능한 클러스터 노드에 대한 중요한 애플리케이션, 리소스, 서비스 및 종속성에 대한 액세스를 복원합니다. , 이 경우 노드 B.장애 조치 시나리오에서 노드 A에 충돌(또는 기타 시뮬레이션된 즉각적인 오류)이 발생했기 때문에 노드 A에서 중지할 프로세스가 없으며 결과적으로 적절한 감지 및 차단 작업이 처리되면 노드 B는 즉시 복원 프로세스를 시작합니다. 자원. 전환의 경우와 같이 프로세스는 자원 Gamma에서 시작하여 Beta가 이어지며 마지막으로 Alpha 자원에 대한 시작 작업이 완료됩니다. 일반적으로 장애 조치 작업은 전환보다 시간이 덜 걸립니다. 의 처리 때문이다. 장애 조치 이전 기본(서비스 중 또는 활성) 노드에서 리소스를 중지(또는 정지)할 필요가 없습니다. 핵심 사항: 시스템 장애에 대한 응답으로 장애 조치가 발생합니다. 무엇인가요 회복 ? 복구 이벤트는 장애 조치와 혼동하기 쉽습니다. 복구 이벤트는 프로세스, 서버, 통신 경로, 디스크 또는 클러스터 리소스에 장애가 발생하고 식별된 장애에 대한 응답으로 고가용성 소프트웨어가 작동할 때 발생합니다. 대부분의 HA 소프트웨어 솔루션은 여러 가지 방법으로 복구 이벤트를 처리할 수 있습니다. 가장 눈에 띄는 방법은 다음과 같습니다. 로컬에서 단계적 재시작 후 원격에서 단계적 재시작 다시 시작은 항상 로컬에서 시도되며 복구에 성공하면 추가 작업이 발생하지 않습니다. 로컬 재시작에 실패하면 다음 작업이 발생합니다. 로컬 다시 시작이 실패하면 리소스가 원격 노드로 정상적으로 이동됩니다. 로컬에서 단계적 재시작 후 원격에서 강제 재시작 다시 시작은 항상 로컬에서 시도되며 복구에 성공하면 추가 작업이 발생하지 않습니다.로컬 다시 시작이 실패하면 다음 작업이 발생합니다. 리소스는 기본 노드를 차단하여 원격 노드로 이동합니다. 원격에서 강제 재시작 다시 시작은 로컬에서 시도되지 않습니다. 리소스는 방법 2b에 설명된 대로 항상 다음 사용 가능한 클러스터 노드로 강제 설정됩니다. 강제 서버 재시작, 원격 장애 조치 없음 다시 시작은 항상 로컬에서 시도됩니다. 로컬 다시 시작이 실패하면 기본 노드가 다시 시작되어 서비스 복구를 시도합니다. 리소스는 원격 시스템에 실패하지 않습니다. 정책 기반 로컬 재시작 후 원격 정책은 복구를 원격으로 시도하기 전에 재시도 횟수를 제어할 수 있습니다. 복구 정책의 다양한 변형으로 인해 전환 동작과 유사한 복구 이벤트를 쉽게 볼 수 있습니다. 이것은 종종 방법 1과 5의 경우입니다. 이러한 시나리오에서 응용 프로그램과 서비스는 원격 노드에서 시작되기 전에 순서대로 정상적으로 중지됩니다. 방법 2와 3, 고객은 종종 장애 조치와 유사한 동작을 보게 됩니다. 방법 2와 3에서 기본 서버는 장애 조치와 유사한 관찰 가능한 동작을 생성하는 HA 소프트웨어에 의해 다시 시작되거나 차단됩니다.방법 4는 일반적으로 거의 사용되지 않는 옵션이지만 전환과 장애 조치가 혼합된 것입니다.방법 4는 응용 프로그램 및 서비스를 정상적으로 중지한 다음 응용 프로그램 및 서비스를 다시 시작하는 것으로 시작합니다(전환과 유사). 그러나 응용 프로그램 및 서비스의 로컬 다시 시작이 실패하면 시스템이 다시 시작되지만(페일오버와 유사) 실제로 원격 클러스터 노드에 실패하지 않습니다. 드물기는 하지만 방법 4는 불균형 클러스터가 있거나 정책 기반 방법론과 함께 사용되는 경우에 자주 호출됩니다. 주요 요점 : 복구 이벤트는 선택한 방법에 따라 다릅니다. 벤더 간의 HA 용어는 공통 용어가 다른 의미를 가질 수 있는 영역입니다. 엔터프라이즈 응용 프로그램과 함께 클러스터 솔루션을 배포하고 유지 관리할 때 장애 조치, 전환 및 복구에 대한 솔루션 공급자 용어를 이해해야 합니다.그리고 그 자리에 있는 동안 레스토랑에서 소스를 옆(접시)에 놓을지 아니면 옆(으깬 감자)에 소스를 놓을지 확인하십시오. 시오스