선택한 단어 수는 입니다.
최소 단어 이상 선택하여야 합니다.
최소 단어 이상 선택하여야 합니다.
선택한 단어 수는 30입니다.
최대 10 단어까지만 선택 가능합니다.
최대 10 단어까지만 선택 가능합니다.
문제 정의
- SCMS는 클러스터 시스템을 위한 관리기로서 오류 발생 상황에 대한 DBMS 의 장애 극복 절차를 지원하지 않으며, OCMS는 Oracle이라는 특정 DBMS 를 위한 클러스터 관리기로서 iBASE/ Chis坨了의 장애 극복 절차를 지원하지 않아, 이들과의 직접적인 성능 비교가 불가능하다. 따라서 본 논문에서는 구현된 클러스터 관리기의 관리노드, 백업관리노드, 데이타베이스 서버노드의 고장을 감지하고, 각각의 고장 에 따른 복구 절차를 수행하는데 소요되는 시간을 측정하여 성능고찰을 수행한다. 표 8은 각각의 고장 감지와 이에 따른 복구절차 수행에 소요되는 시간을 나타낸다.
- 본 절에서는 클러스터 기반 DBMS를 위한 고가용성 클러스터 관리기를 설계하기 위해 기존의 관리도구를 살펴본다. 이를 위해 DBMS를 위한 관리도구로 가장 널리 알려진 오라클 8i 의 OCMS(Ora 이 e Cluster Management Software) 및 리눅스 Beowulf 클러스터 시스템을 위한 관리 소프트웨어인 SCMS (SMILE Cluster Management System)를 살펴본다.
- 본 절에서는 클러스터 기반 DBMS인 iBASE/ Cluster 를 이용한 클러스터 관리기의 구현 및 성능고찰을 수행 한다. 이롤 위한 클러스터 관리기의 구현환경은 Int시 Pentium-Ill 450 CPU, 128 MByte의 메모리의 4대의 PC로 구성하며, Redhat 7.
- 또한 클러스터 관리기의 각 컴포넌트 상태에서 관리노드의 NM, Sys, LB, iBase가 INACTIVE 상태임을 알 수 있고, 첫 번째 서버노드에서 실행되던 리눅스 가상 서버와 iBASE/Clustei■의 GLM이 현재 관리노드인 두 번째 서 버노드에서 정상적으로 동작한다. 이번에는 백업관리노 드의 오류발생시 백업관리노드가 다른 서버노드로 역할 이 바뀌는 지를 검사한다. 이를 위해 백업관리노드의 클 러스터 네트워크 케이블의 연결을 차단하여 백업관리노 드를 노드격리 상태로 만든다.
제안 방법
- CMe 네트워크의 고장여부와 서비스 상태 테이블, 그리고 전달받은 이벤트를 바탕으로 클러스터 시스템내의 모든 자원과 서비스를 통합 관리하여 이벤트를 발생 시키며, 전달받은 이벤트를 해석하여 적절한 서비스 handler에게 이벤트를 전달하여 그에 따른 절차를 수행 하게 한다. 한편 CM이 실행되는 관리노드에 오류가 발 생하면, 전체 클러스터 기반 DBMS의 오류로 나타나기 때문에, 이를 방지하기 위하여 백업관리노드를 둔다.
- 둘째, 노드의 종류에 따른 단일 노드의 오류 발생 시 클러스터 시스템의 도작 여부를 검사한다. 먼저 관리노 드의 오류를 검사하기 위해, 관리노드의 클러스터 네트워크 케이블의 연결을 차단하여 관리노드를 노드 격리 상태로 만든다.
- 클러스터 시스템 환경에서 클러스터 기반 DBMS는 디스크를 공유하기 때문에 한 서버노드의 잘못된 동작은 전체 클러스터 기반 DBMS에 영향을 미칠 수 있다. 따라서 서버노드가 잘못된 동작을 하여 전체 클러스터 기반 DBMS의 데이타 무결성에 영향을 미치지 않도록 네트워크 고장 종류에 따른 복구 절차를 수행한다. 첫 째, 서비스 네트워크가 단절될 때 사용자의 서비스 요청 에 대한 처리결과를 사용자에게 전송할 수 없으므로, 해당 노드는 현재 수행중인 트랜잭션을 중단하고 완료가 안된 트랙잭션의 복구절차를 수행한다.
- 따라서 전체 클러스터 기반 DBMS가 오류에 상관없이 계속적으로 정상적인 서비스를 수행할 수 있도록 클러스터 시스템을 관리한다. 또한 클러스터 관리기를 통해 사용자가 클러스터 시스템을 구성하는 각 노드들의 자원 활 용 상태를 보다 쉽게 파악하고 클러스터 시스템을 관리 할 수 있도록 하였다. 아울러 클러스터 관리기를 클러스 터 기반 DBMS 인 iBASE/Clustei■를 이용하여 구현하였 고, 관리노드, 백업관리노드, 데이타베이스 서버노드 그리고 다중노드의 오류 상황에 대해 테스팅하였다.
- 마지막으로, CMe 관리노드에 위치하며 NM으로부터 각 서버노드의 정보와 이벤트를 전달받고, 이를 바탕으로 서버노드의 각 서비스별 프로세스, probe, 그리고 NM의 상태를 나타내는 서비스 상태 테이블을 유지 관 리한다. 또한, 각 서버노드의 클러스터 네트워크와 서비스 네트워크를 통해 ping 메시지를 전송하여, 네트워크 의 고장여부를 판단한다. 서비스 상태 테이블은 시스템을 모니터하는 시스템 probe와 DB, 리눅스 가상 서버, 노드의 네트워크 상태와 NM의 상태를 활성과 비활성으 로 나타낸다 표 2는 CM이 발생시키는 이벤트와 그에 따른 수행절차를 나타낸다.
- 마지막으로, CMe 관리노드에 위치하며 NM으로부터 각 서버노드의 정보와 이벤트를 전달받고, 이를 바탕으로 서버노드의 각 서비스별 프로세스, probe, 그리고 NM의 상태를 나타내는 서비스 상태 테이블을 유지 관 리한다. 또한, 각 서버노드의 클러스터 네트워크와 서비스 네트워크를 통해 ping 메시지를 전송하여, 네트워크 의 고장여부를 판단한다.
- 마지막으로, 관리노드, 백업관리노드, 데이타베이스 서 버노드에서 오류가 발생한 뒤에 또 다른 종류의 노드 오류가 연속되는 다중 오류 경우를 테스팅한다. 이를 위해 먼저 관리노드, 백업관리노드, 데이타베이스 서버노 드에서 오류가 발생한 뒤의 클러스터 시스템 내의 상태를 표 7에 요약한다.
- 둘째, 클러스터 네 트워크가 단절될 때, 해당 서버노드는 관리노드로부터 사용자의 서비스 요청을 전달받을 수 없으며, 다른 서버 노드에 데이타를 전달할 수 없으므로 실행중인 트랜잭 션의 복구절차를 수행하고 종료한다. 마지막으로, 노드 의 완전 고장 상태가 발생하면 해당 서버노드를 부하분 산 대상에서 제거하고, 다른 서버노드가 이를 알 수 있도록 하고 아울러 복구 절차를 수행한다.
- 마지막으로, 데이타베이스 서버노드의 고장이 발생하 면 관리노드가 이를 감지하고 이에 따른 복구절차를 수 행한다. 데이타베이스 서버노드의 고장을 감지하는데 소 요되는 시간은 0.
- 둘째, 노드의 종류에 따른 단일 노드의 오류 발생 시 클러스터 시스템의 도작 여부를 검사한다. 먼저 관리노 드의 오류를 검사하기 위해, 관리노드의 클러스터 네트워크 케이블의 연결을 차단하여 관리노드를 노드 격리 상태로 만든다. 그림 7은 관리노드에 오류가 발생 시 클 러스터 관리기의 사용자 인터페이스를 나타낸다.
- 본 논문에서 구현된 클러스터 관리기를 iBASE/ Cluster를 이용하여 정상동작여부를 검사한다. 구현 및 테스팅에 사용된 클러스터 시스템은 4대의 서버로 구성 되며, 각 서버에 iBASE/Chister DBMS가 설치되어 동작한다.
- 본 절에서는 iBASE/Chister를 이용한 클러스터 관리 기의 성능을 분석한다. SCMS는 클러스터 시스템을 위한 관리기로서 오류 발생 상황에 대한 DBMS 의 장애 극복 절차를 지원하지 않으며, OCMS는 Oracle이라는 특정 DBMS 를 위한 클러스터 관리기로서 iBASE/ Chis坨了의 장애 극복 절차를 지원하지 않아, 이들과의 직접적인 성능 비교가 불가능하다.
- 또한 클러스터 관리기를 통해 사용자가 클러스터 시스템을 구성하는 각 노드들의 자원 활 용 상태를 보다 쉽게 파악하고 클러스터 시스템을 관리 할 수 있도록 하였다. 아울러 클러스터 관리기를 클러스 터 기반 DBMS 인 iBASE/Clustei■를 이용하여 구현하였 고, 관리노드, 백업관리노드, 데이타베이스 서버노드 그리고 다중노드의 오류 상황에 대해 테스팅하였다. 한편 오류 발생시 그에 따른 복구 절차를 수행함으로써 오류 발생 후에도, 전체 클러스터 기반 DBMS가 정상적인 서비스를 수행할 수 있도록 하였다.
- 본 절에서는 클러스터 기반 DBMS를 위한 고가용성 클러스터 관리기를 설계하기 위해 기존의 관리도구를 살펴본다. 이를 위해 DBMS를 위한 관리도구로 가장 널리 알려진 오라클 8i 의 OCMS(Ora 이 e Cluster Management Software) 및 리눅스 Beowulf 클러스터 시스템을 위한 관리 소프트웨어인 SCMS (SMILE Cluster Management System)를 살펴본다.
- 이때, 관리노드에 오류가 발생 하면 사용자의 서비스 요청이 서버노드로 전달될 수 없 기 때문에, 전체 클러스터 기반 DBMS가 서비스를 수 행할 수 없다. 이를 위해 본 논문에서는 관리노드 이외 의 서버노드 가운데 한 노드를 데이타베이스 서버의 역 할과 백업관리노드의 역할을 동시에 수행하도록 지정한다. 마찬가지로 백업관리노드에서 오류가 발생하면, 관 리노드를 제외한 서비스 가능한 서버노드중의 하나가 백업관리노드의 역할을 수행한다, 따라서 전체 클러스터 기반 DBMS는 모든 서버노드가 데이타베이스 서버의 역할을 수행하며, 서버중의한 노드는 관리노드의 역할 을, 다른 하나의 노드는 백업관리노드의 역할을 동시에 수행한다.
- 이를 위해 본 논문에서는 클러스터 기반 DBMS를 위한 고가용성 클러스터 관리기를 설계 및 구현한다. 이는 각 노드들에 대해서 IP(In坨met Protocol) 레벨의 단일 시스템 이미지를 제공함으로써, 사용자의 트랜잭션이 어느 노드에서 수행되는 지에 구애를 받지 않는 투명성 (transparency)를 제공한다.
- RMI는 SMA가 가진 노드들 의 정보를 바탕으로 동작하는 상위 애플리케이션을 위한 APKApplication Program Interface)들의 집합이다. 이를 통해 각 노드 및 클러스터의 환경을 설정하는 프 로그램, 각 노드의 상태를 확인할 수 있는 모니터링 소 프트웨어 및 스케줄러, 클러스터 환경에서 하나의 노드 에서처럼 동작할 수 있는 유닉스 명령어들을 제공한다. 그러나, SCMS는 클러스터 시스템을 위한 관리기로 클 러스터 기반 DBMS의 오류 감지 및 회복 절차를 지원 하지 못하는 단점이 있다.
- 따라서 서버노드가 잘못된 동작을 하여 전체 클러스터 기반 DBMS의 데이타 무결성에 영향을 미치지 않도록 네트워크 고장 종류에 따른 복구 절차를 수행한다. 첫 째, 서비스 네트워크가 단절될 때 사용자의 서비스 요청 에 대한 처리결과를 사용자에게 전송할 수 없으므로, 해당 노드는 현재 수행중인 트랜잭션을 중단하고 완료가 안된 트랙잭션의 복구절차를 수행한다. 또한 DBMS가 사용자의 서비스 처리 요구를 받지 않도록, 리눅스 가상 서버의 부하분산대상에서 제거한다.
- 여기서 probe와 handlere 각각 시스템, DB, LB(Load Banlancer) probe와 handler로 분류된다. 첫째, 시스데 DB, LB probe는 각 서버에서 CPU, 메 모리, 네트워크의 시스템 상태, DBMS 인스턴스 상태, 그리고 부하분산기를 각각 모니터한다. 부하분산기로는 리눅스 가상 서버를 사용한다[10].
- 그림 1은 OCMS의 시스템 구조를 나타낸다. 첫째, 오라클에서 개발한 watchdog 데몬은 데이타베이스의 오류를 방지하기 위해, 시스템 자원을 모니터하는 리눅스의 watchdog 타이머 (timer)를 사용한다. watchdog 데몬은 노드 모니터와 클러스터 관리자를 모니터하며, 정해진 시간간격으로 watchdog 타이머에게 메시지를 전달한다.
- 본 논문에서는.클러스터 기반 DBMS의 효율적인 관리를 위해 고가용성 클러스터 관 리기를 설계하고 구현하였다. 이는 클러스터 시스템을 이루는 각 서버노드에서 시스템의 주요 자원을 모니터 하고, 이를 통해 시스템, 네트워크, 데이타베이스의 오류 를 감지하고, 오류 발생 시 복구절차를 수행한다.
- 구현 및 테스팅에 사용된 클러스터 시스템은 4대의 서버로 구성 되며, 각 서버에 iBASE/Chister DBMS가 설치되어 동작한다. 테스팅은 정상동작상태, 관리노드에 오류가 발생 했을 때, 백업관리노드에 오류가 발생했을 때, iBASE/ Cluster 서버 노드에 오류가 발생했을 때, 그리고 두 노 드가 연속적으로 오류가 발생하는 다중 오류 상황으로 구분하여 각각의 오류상황에 다른 복구절차가 정상적으 로 실행되는 지를 검사한다.
이론/모형
- 부하분산기로는 리눅스 가상 서버를 사용한다[10]. 리눅스 가상 서버가 지원하는 시스템의 구조 중 direct routing 방식을 사용 하며, 스케줄링(scheduling) 알고리즘으로는 round robin 방법을 사용한다. 각각의 probe는 모니터되는 대상 서비 스의 상태에 따라 이벤트를 발생시킨다.
성능/효과
- 즉, 2개 이상의 서버노드가 동시에 오류가 발생할 수 없다는 가정하에 2개이상의 노드가 동시에 오류가 발생하여 네트워크 통 신이 불가능할 경우, 현재의 상태 정보와 과거의 상태정보 비교를 통해 현재 노드에 오류가 발생한 것을 감지 한다. 논 논문에서 제안하는 과거 상태 정보를 통해 오 류를 감지하는 방법은 서버 노드의 수에 영향을 받지 않아서 확장성 측면에서 OCMS 보다 효율적이다. 마지 막으로, OCMS 는 공유 디스크의 오류를 감지하여 DBMS 인스턴스들이 공유디스크에 접근하지 못하도록 복구절차를 수행한다.
- 둘째, 백업관리노드의 고장이 발생하면 이를 관리노드 가 감지하고 서비스 가능한 다른 노드를 백업관리노드 로 선택한다. 백업관리노드의 고장을 감지하는데 소요되는 시간은 089초이며, 백업관리노드의 역할 수행을 위한 복구절차는 0.
- 즉, 시스템 내의 어떠한 노드에서도 클러스터 내의 모든 시스템 자원과 행위를 제공받을 수 있어야 한다. 둘째, 전체 시스템 구성과 각 노드의 부하 및 CPU, 메 모리, 디스크 등 자원의 활용상태의 파악이 용이하여야 한다. 셋째, 모든 노드의 성능을 최대한 발휘하기 위해 사용자의 요구를 적절히 분산시키는 스케줄링 방법이 필요하다.
- 또한 DBMS가 사용자의 서비스 처리 요구를 받지 않도록, 리눅스 가상 서버의 부하분산대상에서 제거한다. 둘째, 클러스터 네 트워크가 단절될 때, 해당 서버노드는 관리노드로부터 사용자의 서비스 요청을 전달받을 수 없으며, 다른 서버 노드에 데이타를 전달할 수 없으므로 실행중인 트랜잭 션의 복구절차를 수행하고 종료한다. 마지막으로, 노드 의 완전 고장 상태가 발생하면 해당 서버노드를 부하분 산 대상에서 제거하고, 다른 서버노드가 이를 알 수 있도록 하고 아울러 복구 절차를 수행한다.
- 첫째, 서비스 네트워크 단절은 각 노드들 간의 통신은 가능하지만 사용자로부터 서비스 요청을 받아들일 수 없거나, 처리된 결과를 사용자에게 전달할 수 없는 상태 이다. 둘째, 클러스터 네트워크 단절은 사용자의 서비스 요청을 각 노드로 재분배 할 수 없는 상태이거나, 노드 간의 통신이 이루어질 수 없는 상태이다. 마지막으로, 노드 완전고장은 클러스터 네트워크 및 서비스 네트워 크가 단절되어 해당 노드가 아무런 기능을 할 수 없는 상태이다.
- 하지만 제안하는 클러스터 관리기는 단지 2N 개의 메시 지의 교환을 필요로 한다. 따라서, 제안하는 클러스터 관리기가 OCMS 보다 네트워크 자원을 효율적으로 사용할 수 있음을 알 수 있다. 둘째, OCMS는 다른 서버 노드의 오류감지를 위해 공유 디스크상의 quorum 파티 션을 사용한다.
- 즉, 관 리노드의 역할이 백업관리노드로 동작하던 두번째 관리 노드로 바뀌었으며, 서비스 가능한 다른 서버노드중의한 서버노드가 새로이 백업관리노드로 동작한다. 또한 클러스터 관리기의 각 컴포넌트 상태에서 관리노드의 NM, Sys, LB, iBase가 INACTIVE 상태임을 알 수 있고, 첫 번째 서버노드에서 실행되던 리눅스 가상 서버와 iBASE/Clustei■의 GLM이 현재 관리노드인 두 번째 서 버노드에서 정상적으로 동작한다. 이번에는 백업관리노 드의 오류발생시 백업관리노드가 다른 서버노드로 역할 이 바뀌는 지를 검사한다.
- 현재 클러스터 시스템을 구성하는 4개의 서버노드가 정상동작중이며, 그 중 첫 번째 서버노드는 관리노드의 역할을 수행하며, 두 번째 서버노드는 백업 관리노드의 역할을 수행한다. 또한 클러스터 관리기의 각 컴포넌트 상태에서 현재 모든 서버노드의 데몬프로 그램(sys로 표시) 및 iBASE/Cluster가(iBase로 표시) 정상동작중이며, CM과의 통신을 관리하는 NM이 정상 동작하며 모든 서버노드가 서비스중임을 알 수 있다. 현재 리눅스 가상서버는 관리노드인 첫 번째 서버노드에서 정상동작중이며, 클러스터 기반 DBMS의 전역잠금 관리기 인 GLM(Global Lock Manager) 마스터 노드 인 첫 번째 노드에서 실행중이다.
- 둘째, 클러스터 네트워크 단절은 사용자의 서비스 요청을 각 노드로 재분배 할 수 없는 상태이거나, 노드 간의 통신이 이루어질 수 없는 상태이다. 마지막으로, 노드 완전고장은 클러스터 네트워크 및 서비스 네트워 크가 단절되어 해당 노드가 아무런 기능을 할 수 없는 상태이다.
- 아울러 본 논문에서 구현한 클러스터 관리기의 오류 감지 및 복구수행시간의 효율성을 제시하기 위해 OCMS를 포함하는 Oracle 9i RAC 버전의 매뉴얼을 검토하였으며, 그 결과 Ora이e 9i OCMS 의 경우 Ora이e DBMS 서버 노드의 고장을 감지하고 복구하는데 최소 20초 이상의 시간이 소요되에 12], 본 논문에서 구현한 클러스터 관리기가 오류감지 및 복구수행시간 측면에서 (2초 이내) 매우 성능이 뛰어남을 알 수 있다. 또한 본 논문에서 구현한 클러스터 관리기와 OCMS 를 비교하 면 표 9와 같다.
- 87초이며, 복구절차를 수행하는데 소요 되는 시간은 0’71초이다. 이를 통해 고장 감지부터 복구 절차 수행까지 평균 L52초가 소요되어 최소주기인 2초 내로 수행하므로 효율적이라 할 수 있다. 한편 복구절차 수행 시간이 0.
- 또한 본 논문에서 구현한 클러스터 관리기와 OCMS 를 비교하 면 표 9와 같다. 첫째, OMCS의 경우 cluster manager 는 각 서버노드에 존재하며 다른 서버노드의 cluster manager와 통신을 통해 전체 시스템을 관리한다’ 만약 N 개의 서버노드가 존재한다면, OCMS는 시스템을 관 리하기 위해 (N-1)*N 개의 메시지를 교환해야 한다. 하지만 제안하는 클러스터 관리기는 단지 2N 개의 메시 지의 교환을 필요로 한다.
- 첫째, 관리노드의 고장이 발생하면 이를 모니터하는 백업관리노드가 네트워크 상태와 관리노드로 ping 메시 '지를 보내고 이에 대한 응답을 통해 관리노드의 고장을 감지하고, 자신이 관리노드의 역할을 수행한다. 여기서 ping 메시지에 대한 응답은 최소주기를 2초로 설정하였다.
- 이러한 클러스터 기반 DBMS를 효율적으로 관리하기 위해서는 다음과 같은 기능을 지니는 관리 도구가 필요하다. 첫째, 다수의 노드로 구성된 클러스터 시스템을 단일 시스템처럼 인식할 수 있는 환경이 제공되어야 한다. 즉, 시스템 내의 어떠한 노드에서도 클러스터 내의 모든 시스템 자원과 행위를 제공받을 수 있어야 한다.
- 이러한 클러스터 관리기를 설계함에 있어 고려해야 할 사항 은 다음과 같다. 첫째, 모니터 대상을 최소화하여 노드 의 부하를 가중시키는 것을 방지한다. 둘째, 모니터 주 기(frequency)를 동적으로 변화시켜, 노드의 상태정보를 관리노드로 전송할 때 발생하는 네트워크 전송(traffic) 량을 적절히 조절한다[11].
- 첫째, 서비스 네트워크 단절은 각 노드들 간의 통신은 가능하지만 사용자로부터 서비스 요청을 받아들일 수 없거나, 처리된 결과를 사용자에게 전달할 수 없는 상태 이다. 둘째, 클러스터 네트워크 단절은 사용자의 서비스 요청을 각 노드로 재분배 할 수 없는 상태이거나, 노드 간의 통신이 이루어질 수 없는 상태이다.
- 첫째, 정상동작상태를 테스팅하기 위하여 첫 번째 서 버노드는 관리노드의 역할을, 두 번째 서버노드는 백업 관리노드의 역할을 수행하도록 한다. 사용자의 서비스 요청은 관리노드인 첫 번째 서버로 전송되며 관리노드 의 리눅스 가상 서버는 현재 서비스 가능한 4개의 서버 노드 가운데 한 서버노드로 round-robin 알고리즘에 의해 순서대로 서비스 요청을 재분배한다.
- 아울러 클러스터 관리기를 클러스 터 기반 DBMS 인 iBASE/Clustei■를 이용하여 구현하였 고, 관리노드, 백업관리노드, 데이타베이스 서버노드 그리고 다중노드의 오류 상황에 대해 테스팅하였다. 한편 오류 발생시 그에 따른 복구 절차를 수행함으로써 오류 발생 후에도, 전체 클러스터 기반 DBMS가 정상적인 서비스를 수행할 수 있도록 하였다.
후속연구
- 향후 연구로는 첫째, 공유 디스크에 대한 오류감지 및 오류 발생 시 복구 절차를 수행할 수 있도록 개선하고, 둘째, 각 노드에서 모니터한 부하 및 자원활용 상태에 기반한 효율적인 부하분산 알고리즘을 설계하여, 사용자의 서비스 요청을 보다 효율적으로 분산시켜 클러스터 기반 DBMS의 전체적인 성능 향상을 도모하는 것이다.
※ AI-Helper는 부적절한 답변을 할 수 있습니다.