고 가용성 솔루션을 선택하기위한 12 가지 검사 목록 항목

고 가용성 솔루션을 선택할 때 몇 가지 기준을 고려해야합니다. 이는 솔루션의 총 비용에서 클러스터 구성 및 관리의 용이성, 하드웨어 및 소프트웨어에 대한 특정 제한 사항까지 다양합니다. 이 게시물은 가장 중요한 체크리스트 항목 중 12 개에 간단히 적용됩니다.

1. 표준 OS 및 응용 프로그램 버전 지원

OS, 데이터베이스 또는 응용 프로그램 소프트웨어의 엔터프라이즈 또는 고급 버전이 필요한 솔루션은 범용 서버 환경으로 전환 할 경우의 비용 이점을 크게 줄일 수 있습니다. 적절한 HA 미들웨어를 배포하십시오. 이 방법을 사용하면 표준 버전의 응용 프로그램과 OS를 고 가용성으로 사용할 수 있습니다. 동시에 비즈니스 환경의 가동 시간 요구 사항을 충족하십시오.

2. 다양한 데이터 저장 장치 구성 지원

HA 클러스터를 전개 할 때, 보호 된 응용 프로그램이 필요로하는 데이터는 응용 프로그램을 서비스해야하는 모든 시스템에서 사용 가능해야합니다. 이 데이터는 데이터 복제를 통해 공유 SCSI 또는 파이버 채널 저장소를 사용하거나 NAS 장치를 사용하여 공유 할 수 있습니다. 어떤 방법으로 배포하든, 사용하는 HA 제품은 비즈니스 요구 사항에 따라 변경할 수 있도록 모든 데이터 구성을 지원할 수 있어야합니다.

삼. 이기종 솔루션 구성 요소 사용 기능

일부 HA 클러스터링 솔루션은 클러스터 내의 모든 시스템이 동일한 구성을 요구합니다. 이 요구 사항은 클러스터링 기술이 서버 또는 스토리지를 차별화하고 OS 벤더 사이에서 지원해야하는 구성을 제한하려는 하드웨어 관련 솔루션에 공통적으로 적용됩니다. 이 제한 사항은 확장 된 서버를 임시 백업 노드로 배포하고 클러스터 배포에서 기존 하드웨어를 다시 사용할 수있는 능력을 제한합니다. 동일하게 구성된 서버를 배포하는 것이 귀하의 필요에 맞는 올바른 선택 일 수 있지만 결정은 귀하의 HA 솔루션 제공 업체에 의해 결정되어서는 안됩니다.

4. 클러스터 내 3 개 이상의 노드 지원

클러스터에서 지원할 수있는 노드 수는 확장 성의 중요한 척도입니다. 엔트리 레벨 HA 솔루션은 대개 액티브 / 패시브 모드에서 하나의 2 노드 클러스터로 제한합니다. 이 구성은 대기 서버 추가를 통한 가용성 향상을 제공하지만 여전히 응용 프로그램 중단 시간에 노출 될 수 있습니다. 2 노드 클러스터 구성에서 어떤 이유로 서버 하나가 작동 중지 된 경우 나머지 서버는 단일 실패 지점이됩니다. 3 개 이상의 노드를 클러스터링하면 더 높은 수준의 보호 기능을 제공 할 수 있습니다. 동시에 확장 성이 뛰어난 구성을 구축 할 수도 있습니다.

5. 액티브 / 액티브 및 액티브 / 스탠바이 구성 지원

프로젝트에 적합한 고 가용성 솔루션을 선택하는 것이 중요합니다. 활성 / 대기 구성에서 한 서버는 유휴 상태이며 클러스터 구성원의 작업 부하를 인계받습니다. 이 설정에는 컴퓨팅 리소스 투자를 제대로 활용하지 못하는 단점이 있습니다. IT 지출에서 최대 이익을 얻으려면 클러스터 노드가 활성 / 활성 구성에서 실행될 수 있는지 확인하십시오.

6. 노드 및 개별 서비스 수준에서의 문제 탐지

모든 HA 소프트웨어 제품은 클러스터 서버 기능의 문제점을 감지 할 수 있습니다. 이 작업은 클러스터 구성원이 신호 전달을 중지하면 클러스터 내의 서버간에 하트 비트 신호를 보내고 복구를 시작하여 수행됩니다. 그러나 고급 HA 솔루션은 또 다른 문제를 감지 할 수 있습니다. 개별 프로세스 나 서비스가 사용할 수 없게 만들지 만 서버가 하트 비트 신호를 보내거나 응답하지 않게하는 문제가 발생할 때 발생합니다. HA 소프트웨어의 주요 기능은 최종 사용자가 응용 프로그램을 사용할 수 있는지 확인하는 것이므로 이러한 서비스 수준의 중단을 감지하고 복구하는 것이 중요한 기능입니다. HA 솔루션이 노드 및 서비스 레벨 문제를 모두 감지 할 수 있는지 확인하십시오.

7. 노드 내 및 노드 간 복구 지원

클러스터 노드와 노드 내에서 복구 작업을 수행하는 기능 또한 중요합니다. 노드 간 복구에서 한 노드가 다른 노드에 대한 책임의 전 영역을 담당합니다. 시스템 레벨 하트 비트가 누락되면 하트 비트를 보내야하는 서버는 작동 불능으로 간주되고 다른 클러스터 구성원은 복구 조작을 시작합니다. 노드 내 또는 로컬 복구의 경우 실패한 시스템 서비스는 먼저 실행중인 서버 내에서 복원을 시도합니다. 이 작업은 일반적으로 서비스 및 종속 시스템 리소스를 중지하고 다시 시작하여 수행합니다. 이 복구 방법은 훨씬 빠르며 다운 타임을 최소화합니다.

8. 서버 측 복구의 클라이언트 연결에 대한 투명성

애플리케이션 또는 전체 노드의 서버 측 복구는 클라이언트 측 사용자에게 투명해야합니다. 가상화 된 IP 주소 또는 서버 이름의 사용, 복구 중 실제 컴퓨팅 엔티티로의 가상 컴퓨팅 리소스 매핑 및 네트워크 라우팅 테이블 자동 업데이트를 통해 시스템이 복구 된 응용 프로그램과 데이터에 액세스하는 데 클라이언트 시스템을 변경하지 않아도됩니다. 복구 된 응용 프로그램에 액세스하기 위해 수동으로 클라이언트 측 구성을 변경해야하는 솔루션은 복구 시간을 크게 늘립니다. 필요한 상호 작용으로 인해 추가 오류가 발생할 수 있습니다. 복구는 서버와 클라이언트 모두에서 자동화되어야합니다.

9. 계획되고 계획되지 않은 다운 타임에 대한 보호

계획되지 않은 서비스 중단에 대한 보호 기능 외에도 배포하는 HA 솔루션은 유지 관리 활동으로 인한 중단 시간을 줄이기위한 관리 도구로 사용할 수 있어야합니다. 클러스터 구성원간에 응용 프로그램을 주문형으로 이동할 수있는 기능을 제공함으로써 응용 프로그램과 사용자를 첫 번째 유지 관리를 수행하는 동안 두 번째 서버로 마이그레이션 할 수 있습니다. 따라서 최종 사용자가 IT 리소스를 사용할 수없는 유지 관리 기간이 필요하지 않습니다. HA 솔루션이 클러스터 노드간에 응용 프로그램과 필요한 리소스를 수동 (요청시)으로 이동하는 간단하고 안전한 방법을 제공하는지 확인하십시오.

10. 일반적인 비즈니스 기능을위한 선반 보호

평가할 모든 HA 솔루션에는 파일 시스템, IP 주소, 데이터베이스, 응용 프로그램 등 특정 시스템 자원의 상태를 모니터하도록 설계된 테스트 및 지원되는 에이전트 또는 모듈이 포함되어야합니다. 이러한 모듈을 복구 모듈이라고도합니다. 공급 업체가 제공 한 모듈을 배포하면 공급 업체와 다른 고객이 이미 수행 한 런타임 모두에서 이익을 얻을 수 있습니다. 또한 이러한 솔루션 구성 요소를 지속적으로 지원하고 유지 관리 할 수 ​​있습니다.

11. 맞춤형 비즈니스 애플리케이션을위한 보호 기능을 쉽게 통합 할 수있는 기능

기업에 보호 조치를 원하지만 공급 업체에서 제공 한 복구 모듈이없는 응용 프로그램이있을 수 있습니다. 따라서 HA 솔루션의 보호 스키마에 비즈니스 애플리케이션을 쉽게 통합 할 수있는 방법이 필요합니다. 응용 프로그램을 수정하지 않고 특히 공급 업체 특정 API를 포함하지 않고이 작업을 수행 할 수 있어야합니다. 애플리케이션을 보호하기위한 예제와 단계별 프로세스를 제공하는 소프트웨어 개발자 키트가 있어야합니다. 또한 필요한 경우 제공 업체가 제공하는 지원 서비스도 함께 제공됩니다.

12. 클러스터 구축 및 관리의 용이성

HA 클러스터를 둘러싼 공통된 신화는 배포 및 관리에 비용이 많이 들고 복잡하다는 것입니다. 이것은 반드시 사실 일 필요는 없습니다. 초기 클러스터 구성을 지원하려면 클러스터 관리 인터페이스를 마법사 기반으로 사용해야합니다. 새 요소가 클러스터에 추가 될 때 자동 요소 발견이 포함되어야합니다. 마찬가지로 전체 클러스터의 상태를 한 눈에 모니터링 할 수 있어야합니다. 마지막으로 모든 클러스터 메타 데이터는 HA 방식으로 저장해야합니다. 손상 또는 중단으로 인해 전체 클러스터가 분리 될 수있는 클러스터 내의 단일 쿼럼 디스크가 아닙니다. 이 체크리스트의 기능을 살펴봄으로써 특정 HA 요구에 가장 적합한 결정을 내릴 수 있습니다. 고 가용성 솔루션을 선택하는 것은 로켓 과학이 아닙니다. Linuxclustering의 허가를 받아 복제했습니다.