클러스터 복원력, 성능 및 결과를 개선하기 위한 4가지 회피 전략

고가용성에서 회피 전략을 사용하는 4가지 이유

1. 더 나은 성능 (서버 과부하 최소화)

HA에서 회피 전략을 사용하는 한 가지 이유는 응용 프로그램 및 서버 성능을 높이는 것입니다.프로덕션 워크로드를 실행하는 세 대의 서버의 경우를 생각해 보십시오. 이를 Server Alpha, Server Beta, Server Gamma라고 부르겠습니다.서버 알파 및 베타는 데이터베이스로 지원되는 중요한 애플리케이션을 실행하는 반면 서버 감마는 보고서 및 데이터 변환 작업을 실행합니다.서버 알파에 장애가 발생하면 서버 베타로의 장애 조치가 일반적으로 발생합니다.그러나 베타 서버는 이미 큰 작업 부하를 실행하고 있기 때문에 추가 응용 프로그램 로드로 인해 바람직하지 않은 서버 과부하가 발생하고 두 응용 프로그램의 성능이 저하될 수 있습니다.따라서 서버 감마가 장애 조치 대상으로 선택되었는지 확인하기 위해 회피 전략을 배포하는 것이 현명할 수 있습니다.

2. 성능 최적화

Alpha, Beta 및 Gamma의 세 서버 시나리오를 다시 고려하십시오.서버 알파 및 베타는 최대 워크로드를 처리하도록 확장되는 반면 Server Gamma는 비용 최적화된 서버입니다.서버 알파 및 서버 베타에 장애가 발생하면 비용 최적화 서버인 Gamma로 장애 조치가 발생합니다.그러나 이 서버는 최대 작업 부하나 서버 알파와 서버 베타의 작업 부하를 동시에 처리하도록 확장되지 않습니다.이 경우 회피 전략을 사용하여 다른 호스트를 사용할 수 있게 되는 즉시 Server Gamma에서 워크로드 중 하나 또는 둘 다를 자동으로 이동하여 성능을 최적화할 수 있습니다.

3. 고가용성 최적화

HA 최적화는 회피 전략을 배포하기 위한 또 다른 시나리오입니다. 성능 최적화 전략과 마찬가지로 HA 최적화는 환경이 대부분의 실패 시나리오에서 살아남을 수 있도록 하고 애플리케이션이 어느 시점에서든 가능한 최고 수준의 가용성을 제공하도록 최적화되어 있는지 확인하는 데 사용됩니다.HA 최적화는 인큐 프로세스가 복제된 SAP와 같은 애플리케이션에 중요합니다.모든 SAP 환경에서 잠금 손실 및 취소된 작업의 위험 때문에 ASCS(ABAP SAP Central Service) 및 ERS(복제 대기열 삽입) 인스턴스가 동일한 서버에 장기간 상주하는 것을 원하지 않습니다. 이를 방지하기 위해 ERS 및 ASCS 인스턴스가 항상 반대 클러스터 노드에서 실행되도록 하는 회피 전략을 사용할 수 있습니다.프로덕션 워크로드를 실행하는 세 대의 서버의 경우를 고려하여 서버 알파, 베타, 감마라고 합시다.서버 알파는 ASCS 인스턴스를 실행하고 서버 베타는 ERS 인스턴스를 실행합니다.Server Gamma는 ERS(Server Beta)와 ASCS(Server Alpha)의 장애 조치를 위한 세 번째 노드 역할을 합니다.베타가 충돌하는 경우 ASCS 인스턴스와 동일한 노드에서 실행되는 ERS 리소스를 원하지 않을 것입니다.이 작업을 보장하기 위해 먼저 자동으로 확인하고 두 애플리케이션이 별도의 서버에 있는지 확인하고 잠금 장애 조치를 위한 SAP ASCS/ERS 모범 사례를 유지 관리하는 회피 전략을 배포할 수 있습니다.

4. DR 회피

약 70마일 떨어진 City Alpha와 City Beta의 두 데이터 센터가 있고 대부분의 클라이언트가 그 사이에 있다고 가정합니다. 그러나 최근 내부 조직, 합병/폐쇄 및 인수, 거버넌스 요구 사항의 변경으로 인해 IT 팀은 Alpha 및 Beta에서 약 350마일 떨어진 City Gamma에 위치한 세 번째 데이터 센터를 추가해야 합니다.이제 알파 및 베타에서 주로 보호되었던 리소스도 감마 위치로 확장됩니다.대부분의 사용자와 팀이 알파 및 베타 위치 근처에 있고 가장 극단적인 사용자도 이웃 도시에 있다는 점을 감안할 때 팀은 감마 위치로의 장애 조치를 피해야 합니다. 다른 전략과 마찬가지로 DR 회피는 한 지역 내에서 하나의 노드만 실패할 경우 DR 노드를 방지하여 성능, 내부/외 지역 데이터 비용, 대기 시간 및 클라이언트 액세스를 최적화하려고 합니다.또한 두 노드가 서로 다른 시간 후에 실패하더라도 DR로 이동하기 전에 항상 클러스터 또는 데이터 센터의 다른 노드로 장애 조치가 발생하도록 합니다. 그렇다면 회피 전략을 어떻게 전개할 것인가?많은 공급자가 구성할 수 있는 선호도 규칙을 가지고 있는 반면 다른 공급자는 서버 우선 순위 또는 수동 단계의 조합을 사용합니다.Linux용 SIOS Protection Suite의 경우 다음을 포함한 여러 기본 제공 방법을 사용할 수 있습니다.

1. 리소스 우선 순위 지정

장애가 발생하면 리소스는 남아 있는 우선 순위가 가장 낮은 서버로 장애 조치되고 추가 서버(알파, 베타 및 감마)로 캐스케이드됩니다.Server Alpha는 Resource.HR의 기본 서버이고, Server Beta는 Resource.MFG의 기본 서버이며, Server Gamma는 모든 리소스/서버의 백업 서버입니다.리소스 우선 순위 지정을 사용하면 Resource.HR은 Server Alpha에서 1의 우선 순위를 가지며 Server Gamma에서 2의 우선 순위를 갖습니다.Resource.MFG는 Server Beta에서 1의 우선순위를 가질 수 있고 Server Gamma에서 2의 우선순위를 가질 수 있습니다.고객이 환경 사용을 최적화하려는 경우 Resource.HR은 Server Beta에서 3의 우선 순위를 가질 수 있고 Resource.MFG는 Server Alpha에서 3의 우선 순위를 가질 수 있습니다.Server Alpha에 오류가 발생하는 경우 Resource.HR 리소스는 Server Alpha에서 서비스 시작(복원)을 시도하기 전에 먼저 Server Gamma에 실패합니다.

Linux용 SIOS Protection Suite(UI 및 CLI)를 사용하면 사용자가 각 서버 및 리소스 조합에 대한 우선 순위를 지정할 수 있습니다.

2. 정책 또는 선호도 규칙

또한 정책 규칙을 사용하여 지정된 서버에서 리소스 복구가 발생하지 않도록 함으로써 리소스가 더 중요하거나 리소스 집약적인 작업 부하를 실행할 수 있는 지정된 서버를 피할 수 있습니다.일반적인 정책은 다음과 같습니다.

• • • • • • 기본적으로 특정 서버의 애플리케이션을 차단하는 제약 조건 정책입니다.
          • 리소스가 충분하지 않은 서버에서 애플리케이션을 차단하는 리소스 정책
          • 리소스가 시스템에서 허용되거나 허용되지 않는 기간을 정의하는 임시 정책
          • 클러스터 내에서 선호하는 서버 또는 가능한 애플리케이션 소유권 기능을 정의하는 사용자 정의 정책.

SIOS Protection for Linux CLI를 사용하면 지정된 서버의 특정 리소스에 대한 장애 조치를 비활성화하고, 오류를 보호하는 임시 정책을 제공하고, 특정 애플리케이션 유형, 제약 조건 정책 및 사용자 지정 정책의 오류를 비활성화할 수 있는 정책 규칙을 지정할 수 있습니다.

• 특정 회피 리소스

자원 회피 전략을 수립하는 가장 세부적인 방법은 각 계층 내에 특정 회피 스크립트를 배포하는 것입니다.이 방법을 사용하면 사용자가 특정 응용 프로그램(예: app1 및 app2)을 구성하여 가능한 한 서로를 피하면서 다른 응용 프로그램이 제한 없이 실행되도록 할 수 있습니다.Alpha, Beta 및 Gamma의 세 서버와 app1, app2 및 app3의 세 리소스의 경우 이 방법이 가장 큰 유연성을 제공합니다.이 예에서 app1과 app2는 서버가 실패할 때 배열을 피하려고 하지만 app3은 배열 제한 없이 우선 순위에 따라 사용 가능한 다음 노드로 실패합니다.

회피 전략 및 리소스의 추가 예를 보려면 Linux용 SIOS Protection Suite를 고려하십시오. 선적 서류 비치 .고객이 가능하면 다른 노드에서 실행해야 하는 두 개의 애플리케이션(app1 및 app2)이 있는 경우 고객은 Linux gen/app 리소스용 SIOS Protection Suite와 '/opt/LifeKeeper'를 사용하여 두 개의 회피 터미널 리프 노드 리소스를 생성할 수 있습니다. /lkadm/bin/avoid_restore' 스크립트.

– Cassius Rhue, VP, 고객 경험