| Section | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Include Page
MCCS에서 관리하는 리소스
네트워크카드
MCCS 는 TCP/IP 기반 네트워크 연결을 모니터 합니다. 일시적인 연결 장애나 네트워크 어댑터, 케이블의 네트워크에 장애를 감지합니다.
네트워크주소
MCCS 는 전환가능한 노드안의 네트워크 장치 위에서 가상 IP 주소와 서브넷 마스크를 구성하고 가상 IP 주소를 감시하며 노드의 실제 IP 주소와 같은 방식으로 동작합니다.
가상 IP 주소를 할당할 네트워크 카드의 실제 IP 주소는 정적이어야 합니다.
기본 응용
단일 실행 파일 형태의 프로세스를 등록할 때 사용하며, MCCS는 운영 체제의 프로세스 테이블에 등록된 프로세스 이름의 존재 여부를 체크해서 장애를 감지합니다.
복합 응용
기본 응용과 달리 여러 개의 프로세스로 이루어진 응용 프로그램 또는 톰캣과 같이 스크립트로 실행해야 하는 응용 프로그램 등을 등록할 때에 사용합니다.
단순히 실행 파일만을 감지하지 않고, 프로세스에 대한 시작/종료/감지 기능을 수행하는 스크립트 명령을 이용하여 사용자가 원하는 방법으로 정상적인 동작을 감시하고자 할 경우에도 복합 응용으로 등록하여 사용합니다.
공유 디스크
MCCS 는 외부 공유 스토리지에 연결된 노드의 I/O 경로의 상태를 감시합니다.
미러 디스크
클러스터에 공유디스크가 없을 경우, 데이터는 로컬 혹은 직접 연결된 스토리지에 저장됩니다. 이런 환경에서 TCP/IP 를 통한 미러 구성요소는 변경된 데이터를 복제할 때 사용됩니다.
서비스
서비스는 윈도우의 SCM(Service Control Management)에 의해 관리되는 프로세스를 관리합니다.
가상이름
윈도우 기반 NetBIOS 이름을 관리합니다.
스카시예약
스카시예약 에이전트는 SCSI3-PR(Persistent Reservation) 이라는 스토리지가 지원하는 SAN 프로토콜을 사용하여 LUN 단위의 Lock 을 관리합니다.
이 기능은 클러스터의 모든 노드가 다른 노드의 상태를 알 수 없을 때 데이터 손상을 방지합니다.
MCCS 특징 및 장점
MCCS는 다음과 같은 특징 및 장점을 가지고 있습니다.
서비스 레벨의 장애 감지와 자동화된 페일오버 제공
MCCS는 하드웨어의 장애뿐만 아니라 서비스 제공에 필요한 자원들(예를 들면 네트워크 접속, 응용프로그램 구동, 플랫폼 상태, 디스크 접속 등)에 대해서 정상적인 상태인지를 항상 감시하고 관리합니다. 따라서 해당 자원들에 대해 장애 상태가 감지되어 정상적인 서비스 제공이 불가능한 경우에는 유연한 복구 정책에 따라 자동적으로 서비스를 재구동 시키거나 다른 가용 서버로 페일오버 시키게 됩니다.
로컬 디스크 복제(Mirroring) 및 공유(Shared) 디스크 환경 지원
MCCS는 로컬 디스크 복제 환경과 공유 디스크 환경 모두를 지원합니다. 그러므로 사용자에게 디스크 시스템 환경 구성에 보다 나은 유연성을 제공합니다.
페일오버 그룹(Failover Group) 구성 지원
한번에 한 노드에서만 실행될 수 있는 리소스를 포함한 그룹을 페일오버 그룹이라고 합니다.
페일오버 그룹은 중요 자원 장애시 대기 노드로 서비스가 전환됩니다. 이 그룹에 포함된 자원은 운영 노드에서만 동작합니다.
예를 들면 가상 IP 주소의 경우 운영 노드와 대기 노드로 동시에 사용될 수 없습니다. 또한 가상 IP 주소가 장애인 경우 대기 노드로 서비스가 전환됩니다.
병렬 그룹(Parallel Group) 구성 지원
두 개 이상의 노드에서 동시에 실행될 수 있는 리소스로 구성된 그룹을 병렬 그룹이라고 합니다. 병렬 그룹은 페일오버 하지 않습니다.
일반적으로 클러스터로 구성된 응용프로그램을 포함한 리소스들은 운영 노드에서 실행(Online)중일 때는 대기 노드에서는 정지(Offline)된 상태로 있습니다. 그러나 병렬 그룹으로 구성하는 경우에는 지정한 응용프로그램을 양 쪽 노드에서 동시에 시작, 감시, 종료 등을 행할 수 있습니다.
예를 들면 양 쪽 노드에서 백업 소프트웨어를 운영하고 있고 이를 클러스터에서 관리하는 리소스로서 등록하는 경우, 필요하다면 백업 소프트웨어를 양 쪽 노드에서 항상 동시에 실행하는 상태로 운영할 수 있습니다. (단, 해당 프로그램이 복수의 노드에서 병렬로 실행될 수 있어야 합니다.)
다중 그룹(Multi-Group) 환경 구성 지원
그룹은 MCCS에서 장애 감시, 복구, 페일오버 등을 위해 관리하는 자원들(예를 들면 네트워크 카드, IP 주소, 디스크, 응용프로그램 등)을 의존성에 따라 묶어 놓은 집합체이며, 페일오버가 되는 리소스들의 집합 단위입니다.
하나의 클러스터 안에는 여러 개의 그룹 구성이 가능합니다. 이 때문에 운영/대기(Active/Standby), 운영/운영(Active/Active) 구성이 가능합니다. (Active/Active는 각각의 서버에서 다른 서비스를 운영하는 것을 의미합니다.)
MCCS는 페일오버 그룹과 병렬 그룹을 동시에 지원합니다. 다중 그룹 환경에서 각각의 그룹은 독립적으로 운영됩니다.
하드웨어 호환성
MCCS는 특정 하드웨어의 제조사 또는 모델에 영향을 받지 않는 범용의 솔루션입니다. 따라서 클러스터 노드간의 동일한 하드웨어를 사용할 필요가 없습니다.
원격 재해 복구 시스템 구성
MCCS는 시스템의 위치에 관계 없이 고가용성 구성을 행합니다. 따라서 대기 시스템을 원격지에 위치함으로써 추가 비용 없이 재해 복구 시스템을 쉽게 구성할 수 있습니다.
원격 관리 콘솔(Remote Management Console) 제공
MCCS는 콘솔을 통하여 로컬 서버 혹은 원격 서버에서 MCCS를 제어 및 관리할 수 있습니다. 원격 서버에서는 TCP/IP와 포트 정보를 통해 MCCS가 구성된 서버로 연결할 수 있으며, 별도의 환경 파일을 구성할 필요가 없습니다.
(Windows MCCS 콘솔은 Windows 서버에만 접근이 가능하고, Linux MCCS 콘솔은 Linux 서버에서만 접근이 가능합니다.)
두 노드 환경 지원
MCCS는 2대의 서버 환경을 지원 합니다. (3대 이상의 클러스터링 환경은 ㈜맨텍으로 문의해 주시기 바랍니다.)
MCCS 동작 원리
MCCS는 핫빗 통신을 통해 노드들을 하나의 클러스터로 연결해서 구성합니다. 클러스터 동작은 노드 상태와 역할에 따라 결정되며, 노드 상태는 시스템뿐만 아니라 MCCS의 동작과 핫빗 통신 상태에 따라 결정됩니다.
다음은 클러스터 모드와 독립실행 모드에서 가능한 노드 상태입니다.
클러스터 모드의 노드 상태
- EXITED(엔진 종료) - MCCS 엔진이 종료된 상태입니다.
- INITING(초기화) - 엔진이 시작되고 구성 정보 분석과 핫빗 통신이 이루어지기 전의 기본 노드 상태입니다. MCCS 엔진이 시작된 후 두 노드가 핫빗으로 통신을 하며 상호 상태를 수집하는 초기 상태입니다. 정상적인 경우는 이 상태에서 LOCAL_BUILD 또는 REMOTE_BUILD 상태로 변경되지만, 구성 또는 물리적 환경에 문제가 있는 경우는 INITING 상태에 머물거나 자동 종료되어 EXITED 상태가 됩니다.
- LOCAL_BUILD(로컬구성) - 클러스터의 모든 노드들이 INITING 상태일 때, 핫빗 설정에서 우선 순위가 가장 높은 노드가 LOCAL_BUILD 상태로 변경되며, 이 상태의 노드는 로컬 구성 파일 (%MCCS_HOME%\config\main.json)에서 구성 정보를 분석합니다. 클러스터의 노드 중에서 오직 한 노드만이 이 상태를 거쳐 RUNNING 상태가 되며, 다른 노드들은 이 노드로부터 데이터를 동기화하는 REMOTE_BUILD 상태를 거치게 됩니다.
- REMOTE_BUILD(원격구성) - INITING 상태의 노드가 핫빗 통신을 통해 RUNNING 상태인 노드를 발견하면, 자신을 REMOTE_BUILD 상태로 설정한 후, RUNNING 상태인 노드로부터 구성 정보를 동기화합니다.
- RUNNING(정상) - LOCAL_BUILD 또는 REMOTE_BUILD를 통해 구성 데이터베이스 설정을 완료한 상태이며, 이 상태에서 정의된 모든 리소스에 대한 에이전트와 그룹 관리자를 시작합니다.
- FAULTED(시스템장애) - RUNNING 상태에 있던 노드와의 모든 핫빗이 끊어졌을 때, RUNNING 상태의 노드를 FAULTED로 설정합니다.
노드 상태의 변화 과정
다음은 MCCS의 동작 단계에 따른 노드 상태의 변화 과정을 보여줍니다.
[그림] MCCS 동작 단계에 따른 노드 상태
핫빗 이중화
핫빗은 노드 상호간의 상태를 동기화하고 장애 상태를 결정하는 중요한 역할을 합니다. 따라서 시스템이 운영중인 상황에서는 언제나 통신이 가능한 상태임을 보장하기 위해 반드시 이중화되어야 합니다.
또한 네트워크 고립 여부를 판단하기 위해서 핫빗 네트워크 중에서 하나는 서비스 네트워크 또는 클러스터 노드 외의 노드와 통신이 가능한 네트워크로 반드시 설정해야 합니다.
노드 장애(Node Fault)
모든 핫빗 통신이 일정 시간 단절될 경우는 해당 노드를 장애 상태로 판정합니다. (상세한 내용은 "챕터 9. 노드 속성값"편을 참조해 주십시오.)
핫빗 통신 단절에 대한 최종 판정은 ICMP(Internet Control Message Protocol) 테스트에 의해 이루어집니다. 각각의 핫빗 네트워크가 단절된 시간이 지정 시간을 초과할 경우는 원격 노드의 장애, 분열, 고립으로 판정합니다.
핫빗 단절
모든 핫빗 통신이 단절되면 상호간에 상태 정보를 교환할 수 있는 방법을 잃게 됩니다. 이 경우에 MCCS가 상대 노드를 장애로 판단할 것인지 아니면 단지 상호간의 네트워크 통신만 단절된 상태로 판단할 것인지에 따라 서비스 복구 여부가 결정됩니다.
분열(Split)
핫빗 네트워크의 단절이 클러스터 속성에 정의되어 있는 일정 시간 간격 이상의 시간차로 발생할 경우는 노드 장애 보다는 핫빗 네트워크 전체에 대한 불안정을 의심할 수 있습니다. 따라서 핫빗에 의한 노드 상태를 신뢰할 수 없는 상황으로 판단하여 클러스터내의 모든 노드에 대한 MCCS 서비스를 재시작합니다.
핫빗 통신이 다시 정상적으로 이루어지면 RUNNING 상태로 복귀합니다. 그렇지 않으면 INITING 상태에서 핫빗 통신이 정상화될 때까지 대기하게 됩니다.
고립(Isolation)
일정 시간 내에 모든 핫빗이 단절된 경우라도 상대 노드를 장애로 판단하기 전에 먼저 로컬 노드 자신이 모든 네트워크로부터 단절된 상황인지를 확인할 필요가 있습니다.
만일 게이트웨이 혹는 DNS 서버와 같이 공인된 네트워크 지점과의 통신이 가능한 상태라면 로컬 노드 자신은 단절된 상황은 아니며, 상대 노드가 장애 상태인 것으로 판단하여 상대 노드에서 운영중인 서비스의 복구를 시도할 수 있습니다. 그러나 그렇지 않은 경우에는 상대 노드가 로컬 노드의 상황을 고립으로 판단합니다.
상대 노드는 로컬 노드를 장애 상태로 결정하고, 로컬에서 운영중인 서비스에 대한 복구를 시도하기 때문에, 로컬 노드는 가능한 빨리 운영중인 서비스를 종료해야 합니다.
(상세한 내용은 "챕터 9. 노드 속성값" 편을 참조해 주십시오. )
원격 노드 장애(Remote Node Fault)
일정 시간 내에 모든 핫빗이 단절된 경우이며 자신이 고립상태가 아니라는 판정이 난 경우에 해당합니다. 로컬 노드가 서비스를 운영중인 경우에는 자신의 상태를 유지하며, 원격 노드에서 구성된 서비스 중에서 운영되지 않는(OFFLINE) 서비스를 기동(ONLINE)시킵니다.