오늘은 공유디스크 환경에서 서버 이중화를 구성한 사례인 OO 손해보험의 구축 사례를 작성해보겠습니다.
기존 로컬 디스크 복제 구성과 형태는 비슷한데 복제가 아닌 외장 디스크를 붙여서 구성한 사례입니다.
시스템 사전 요구사항이나 그 외 APP의 요구사항은 복제 구성과 동일합니다.
다만 디스크의 구조가 다르기 때문에 APP의 설치 시 주의해야 합니다.
고객의 요구사항은 그림으로 표현하면 아래와 같습니다.
공유 디스크는 OS에서 바라볼 때 보통 아래의 구조로 보입니다.
APP의 설치 시 주의할 점은 공유해야 할 DATA가 동시에 쓰여지지 않도록 주의해가면서 설치하는 것입니다.
이 것은 저희 솔루션 뿐만 아니라 모든 서버 이중화 솔루션에 해당하는 공통된 내용입니다.
설치 절차는 아래와 같습니다.
1) Active 서버에서 공유디스크 볼륨 마운트 진행
2) DB의 엔진은 OS영역에 DATA는 공유디스크 영역에 반드시 분리하여 설치 진행
3) 설치 후 정상 동작 확인(기본 접속 정보로 접속 유무 확인)
4) Active 서버에서 DB 종료
5) Active 서버에서 공유디스크 볼륨 마운트 해제
6) Standby 서버에서 공유디스크 볼륨 마운트
7) 공유디스크 볼륨에 DATA 폴더 이름을 변경(뒤에 _old 붙임)
8) Active 서버와 동일하게 설치
9) 설치 후 정상 동작 확인
10) Standby 서버에서 DB 종료
11)APP이 설치 시 경로, 버전, 환경변수 등은 반드시 양 서버에 동일하게 셋팅
12) 복제 및 공유해야 할 DATA가 있을 경우 DB HA 구성과 동일하게 구성
13) APP은 반드시 서버 이중화 솔루션을 통해 제어가 이뤄져야 하며, 시작 유형은 반드시 수동이거나
재부팅 시 자동시작(시작 프로그램 혹은 자체 재시작 제어 모듈)이 중지 되어야 함
14) WatchDog APP의 경우(부모 – 자식 프로세스로 동작하는 APP) 자체 모니터링 중지
사전 작업이 완료되면 서버 이중화 솔루션을 설치 및 구성합니다.
윈도의 경우 양쪽 공유 디스크의 Lock을 걸고 부팅 시 자동 잠금을 진행하도록 레지스트리에 등록합니다.
리눅스의 경우에는 자체 마운트 기능을 사용하며 대기서버는 디스크가 항상 논리적으로
연결이 해제되어 있기 때문에 별도의 Lock을 걸지 않습니다.
그리고 이중화 구성이 정상적으로 완료되면 운영서버에서만
코아랩 클러스터가 공유디스크 볼륨의 마운트를 해제하고 서비스를 기동합니다.
공유 디스크 환경의 경우에는 데이터 Sync가 없기 때문에 페일오버 테스트를 바로 진행할 수 있습니다.
이 고객사의 구성 환경을 정리하면 아래와 같습니다.(실제 이중화 솔루션에 등록되는 리소스의 종류 및 숫자)
[DB-Group – Failover]
VIP(가상아이피)
r0(로컬 복제 리소스)
MSSQLSERVER
SQLSERVERAGENT
Tomcat
[APP-Group – Parallel]
Application A
Application B
Application C
여기까지 OO 손해보험의 구축 사례를 알아보았습니다.
실제 현장의 내용을 100% 담을 수 없는 점 양해 바라며 다음 구축 사례에서 뵙겠습니다.
오늘도 저희 글을 읽어 주셔서 감사합니다.
– 코아랩 드림 –