DNS Cluster Loadbalancing Failover

DNS Server
DNS(Domain Name System)는 컴퓨터 이름을 IP 주소로 변환하거나 해석해 주는데 사용되어지는 분산된 데이터베이스를 유지하는 서버이다.
과거 윈도우NT와는 달리 액티브 디렉터리로 윈도우2000 네트워크를 구성할 때 DNS는 반드시 요구되는 네트워크 서비스이다.

서버동작 원리
도메인 이름 시스템은 계층적 클라이언트/서버 기반의 분산 데이터베이스 관리시스템으로 DNS는 TCP/IP계층의 응용프로그램 계층의 서비스이고, 그 하위의 프로토콜인 UDP와 TCP를 둘 다 사용합니다.
DNS 데이터베이스의 목적은 컴퓨터 이름을 IP 주소로 분해하는 것으로, 클라이언트는 분해자(Resolver)로, 서버는 이름 서버(Name Server)로 부릅니다.
분해자는 성능을 높이기 위하여 UDP 질의를 서버에 보내고 반환된 데이터의 절단현상(truncation)이 발생했을 때만 TCP로 분류합니다.
포트 번호는 53번을 사용합니다.


TCP/IP 네트워크에서 사용되는 네임 서비스의 구조이다. TCP/IP 네트워크에서는 도메인이라고 하는 논리적 그룹을 계층적으로 설정할 수 있고, 그 논리적 그룹 명칭인 도메인명을 컴퓨터의 명칭(호스트명)의 일부에 포함시켜 이용하는 방법을 찾고 있다. 도메인 혹은 호스트 이름을 숫자로 된 IP 주소로 해석해 주는 TCP/IP 네트워크 서비스로서, 계층적 이름 구조를 갖는 분산형 데이터 베이스로 구성되고 클라이언트·서버 모델을 사용한다.

각 컴퓨터의 이름은 마침표에 의해 구분되고 알파벳과 숫자로 구성된 세그먼트의 문자열로 구성되어 있다. 예를 들어 기관별로는 com이면 기업체, edu인 경우는 교육기관, gov인 경우는 정부기관 등으로 나누어져 있다. 국가도메인은 au는 호주, ca는 캐나다, jp는 일본, kr는 한국, tw는 대만, uk는 영국 등이다.

Load balancing

로드밸런싱이라고도 한다. 병열로 운용되고 있는 기기 사이에서의 부하가 가능한 한 균등하게 되도록 작업 처리를 분산하여 할당하는 것을 말한다.

컴퓨터 내에서 여러 개의 마이크로프로세서에 작업의 처리를 균등하게 배정하거나 네트워크 상에서의 접속요구를 여력이 있는 서버로 돌리거나 하는 등 여러 분야에서 광범위하게 사용되고 있는 개념이다.

부하분산을 효율적으로 하기 위해서는 각 기기의 부하를 계속적으로 측정할 필요가 있다. 그러나 부하의 측정을 지나치게 엄밀하게 운용하게 되면 부하분산제어 자체가 오히려 큰 부하가 된다.

이 때문에 부하분산은 정밀도와 부하의 균형을 유지하는 형태로 실용화되고 있으며, 더욱 더 효율이 좋은 방법을 찾기 위한 연구가 계속되고 있다.

---
기존 Server Load Balancing 방법
- DNS Round-Robin을 이용한 Server Load Balancing


L4를 통한 Server Load Balancing
- TCP session관리가 Layer 4 장비를 통하여 가능하게 됨에 따라 다양하고 확실한 Load Balancing 구현
- Client가 웹 브라우저 상에서 URL을 입력하여 DNS로 하여금 얻어지는 Ip address값 (L4에서는 Virtual IP :VIP 이라고 말한다.) 을 통하여 L4의 Virtual Server로 접속.
- Virtual Serve의r로 접속하게된 http request는 Vip로 mapping되어있는 실제 서버(real server) Group matching.
- Server group으로 Matching 시키는 기법은 L4가 가지고 있는 여러 가지 분산 알고리즘에 의해 작동하게 되는데 사이트의 성격에 따라 알맞게 선택.

Cluster
①유사성(類似性)과 같은 어떤 개념을 바탕으로 몇 개의 집단으로 분류한 데이터 집합.
②서로 근접한 위치에 있으며 하나의 제어 장치에 의해 제어되는 입출력 장치나 단말 장치 등의 장치 집단.
③플로피 디스크나 하드 디스크에 정보를 기록하고 기록된 정보를 읽어 내기 위해 운영 체계(OS)가 사용하는 디스크 저장 공간의 단위. 디스크의 물리적 최소 저장 공간 단위는 섹터인데, 섹터는 프로그램이나 데이터를 관리하는 단위로서는 너무 작기 때문에 일정한 수의 섹터로 구성되는 다발을 한 단위로 사용한다. 다발은 디스크의 종류에 따라 보통 2의 제곱수의 섹터로 구성되며, OS가 디스크 저장 공간을 할당하고 해제하거나, 사용·미사용 공간을 관리하는 최소 단위이다. 아무리 작은 정보를 저장하더라도 1다발이 할당된다. 다발의 크기는 다발을 구성하는 섹터의 수에 섹터의 크기를 곱한 것이 된다. 이와 같이 다발을 사용하면 기억 장소가 낭비되는 단점도 있지만, 디스크에 접근하는 횟수가 줄어들기 때문에 전반적으로 처리 속도가 빨라지는 장점이 있다.
클러스터링의 용도는 크게 3가지가 있습니다.
로드벨런싱(Load Balancing) 용도, 빠른처리능력 용도, 장애 허용성(fault tolerance)용도....
LVM
LVM 은 Logical Volume Manager 의 약자로서, 저장장치들을 좀더 효율적이고 유연하게 관리할 수 있는 커널의 부분과 프로그램을 말합니다. 처음에는 IBM에서 개발되었는데, 그후에 OSF(현재는 OpenGroup http://www.opengroup.org)에서 차용을 하여 OSF/1 operating system 에서 쓰였습니다. 지금은 HP-UX, Digital Unix operating system, AIX 등의 상용 유닉스에서 쓰고 있습니다. 리눅스 버전은 현재 HP-UX의 것을 모델로 하여 Sistina Software 사(http://www.sistina.com)에서 open source로 개발하고 있습니다.

LVM 을 이해하려면 먼저 Software RAID (Redundant Array of Inexpensive Drives)를 언급해야 하는데, 이 둘은 비슷하면서도 큰 차이가 있습니다.
비슷한 점은 여러 물리적인 디스크들을 하나의 논리적인 디스크처럼 다룰 수 있게 함으로서 조합방법에 따라 고용량, 고속, 데이터의 무결성을 실현하는 점입니다.
하지만 분명하게 다른 점이 있는데. lvm은 raid보다 관리 및 확장이 비교적 쉬운 반면, raid에는 lvm에는 없는 disk mirroring(RAID level 1), Parity Stripe (RAID level 4,5) 등의 방식이 있어서 속도 또는 데이터의 무결성을 보장 받을 수 있다.

LVM 특징
·쉬운 관리.
·서로 다른 많은 디바이스 조합 지원.
·직관적인 저장 장치로의 접근.
·뛰어난 확장성.
·믿을만한 안전성과 효율.
·스냅샷 기능 지원.

우선, pc 급 시스템 사용자들의 가장 큰 고민 중의 하나가 시스템을 처음 설치할 때에 파티션의 구성을 어떻게 할 것인가 일 것입니다. 파티션은 한번 구성해 놓으면 바꾸기가 쉽지 않기 때문입니다. 또 파티션이 가득 차기라도 하면 어렵게 백업을 하거나 눈물을 머금고(?) 자료를 지워야 할 경우도 심심치 않게 생기기 마련입니다. 하지만 LVM를 쓰면 간단하게 저장공간을 확장, 축소 할 수 있기 때문에 그런 고민을 덜 수 있습니다.

다른 예로, 중소형 서버에서는 비교적 적은 비용으로 대용량 저장 장치를 구현하는 것이 가능해집니다. 그리고, 백업 없이 기존의 환경을 유지한 채 확장이 가능하기 때문에 (물론 백업은 *언제나* 중요하다.) 유지보수 면에서 상당한 이득이 있을 있다.

출처:http://www.linuxlab.co.kr/docs/01-05-4.htm


시스템 Raid

출처: http://blog.naver.com/mybrainz.do?Redirect=Log&logNo=140018561879

#RAID 구성


1. 리눅스에서 지원하는 소프트웨어 raid 레벨

1)raid-Linear : 간단히 여러개의 파티션을 하나로 묶는 역활
2)raid-0 : 여러개의 파티션을 하나로 묶어 스트라이핑기술을 이용하여 처리속도가 빨라진다.
디스크 오류에 대한 안전성은 없다는 단점
3)raid-1 : 미러링 기술을 이용하여 여러개의 디스크에 정확하게 복사본을 만들어 준다.
오류가 발생하면 복사해둔 이미지로 복구하게된다.
4)raid-3 : 패리티정보를 모아 별도의 디스크에 저장한다.이 패리티정보를 이용하여 오류가
발생한 디스크의 데이터를 복구한다. 안정성은 있으나 디스크성능이 감소한다.
5)raid-5 : raid -3 와 비슷하게 패리티정보를 이용하나 디스크에 저장하지는 않는다.
안전성도 제공하고 raid-3 에 비해 디스크의 성능저하가 일어나지 않는다.

2.RAID 관련 예제파일

1)레드햇 9.0 이후로는 /usr/share/doc/raidtools-1.00.3 디렉토리 밑에 예제가있다.
없을경우 rpm -ql raidtools 로 검색한다.
2)cp /usr/share/doc/raidtools-1.00.3/raidtab.sample /etc/raidtab
-> 해당 샘플파일을 /etc/raidtab 이란 화일로 복사한다.

3.raid - 0 구성하기

raid - 0 으로 구성해서 속도를 높이고 /raidtest 로 마운트 시키려고 한다.
여유 하드가 없으므로 자체하드의 남은 공간을 1GB * 2 로 설정해본다.

1) FDISK 로 1GB 를 두개 추가로 나눈다. (FDISK 는 현 블로그 FDISK 참조)
2) 나눠진 파티션은 /dev/hda8 과 /dev/hda9 라고 예를 든다.
3) /etc/raidtab 열어 설정한다.

#vi /etc/raidtab
raiddev /dev/md0 //raid 디바이스명 지정
raid-level 0 //raid 레벨 지정
nr-raid-disks 2 //raid 갯수 지정
persistent-superblock 1 //기본셋팅지정
chunk-size 4

device /dev/hda8 //디바이스명
raid-disk 0 //raid 디스크 넘버로 0부터 설정
device /dev/hda9
raid-disk 1

4)raid device 를 생성

#mkraid /dev/md0
handling MD device /dev/md0
analyzing super-block
disk 0 : /dev/hda8, 875511KB, raid superblock at 875392KB
disk 1 : /dev/hda9, 875511KB, raid superblock at 875392KB

5)raid를 작동 시킨다.

#raidstart /dev/md0
->최근에는 mkraid 하면 자동으로 start가 이루어진다.또한 재부팅시에도 자동으로시작된다

6)파일시스템을 생성한다

#mkfs -t ext3 /dev/md0

7)마운트할 디렉토리 생성

#mkdir /raidtest

8)마운트

#mount -t ext3 /dev/md0 /raidtest

9)raid 상태 확인

#lsraid -p

Cron 데몬
Cron 데몬은 작업을 주기 적으로 반복할 수 있도록 해주는 것이다.
- Cron 재시작
root]# /etc/init.d/crond restart

- 사용자의 crontab 내용을 본다.
root]# crontab -l

시스템 지정 crontab을 이용하는 방법
/etc/cron.hourly(시간별)
/etc/cron.daily(일별)
/etc/cron.weekly(주별)
/etc/monthly(월별)

■ CRON



→ 같은 작업을 주기적으로 반복할수 있도록 해준다.

보통 /etc/rc.d/init.d/crond 데몬에 의해 실행된다.

설정은 /usr/bin/crontab 명령어를 사용한다.



♠ 관련명령어 및 파일



1.crontab

▶ cron작업을 설정하는 명령이다. 실행시키면 기본vi편집기가 실행된다.

▶ option

-l : 현재 crontab 에 의해 설정된 내용을 출력한다.

-e : crontab 의 내용을 작성하거나 수정한다.

-r : crontab 의 내용을 삭제한다.

-u : root권한자가 해당사용자의 crontab 파일을 다룰때 사용한다.

▶ 예제

[root@linux root]#crontab -l

→ 작업목록을 보여준다.

[root@linux root]#crontab -e -u bluetree

→ bluetree 사용자의 crontab 을 작성하거나 수정한다.

[root@linux root]#crontab aaa

→ aaa 란 파일을 crontab 으로 사용한다.

aaa 에는 이미 crontab 형식에 맞에 입력되어 있어야한다.

▶ crontab 의 작업형식

→ 5개의 날짜필드와 1개의 명령필드로 구성되어있다.



MM HH DD mm d command

MM : 분을 의미한다 ( 0 ~ 59까지 사용)

HH : 시를 의미한다. ( 0 ~ 23 까지 사용)

DD : 날짜를 의미한다 ( 1 ~ 31까지 사용)

mm : 달을 의미한다.( 1 ~ 12까지 사용)

d : 요일을 의미한다.( 0 ~ 7 까지 사용, 0 과 7은 일요일을 나타낸다)

command : 실행할 명령을 입력한다.

※ 참고

위 형식에서 시간을 나타내는 각 필드에서 와일드 카드 '*'를 사용할수 있고

각각의 요일을 구분할 때 ',' 를 사용하고 연일을 나타낼때는 '-'를 사용한다.

즉 월요일과 수요일은 '1,3' 월요일부터 금요일까지는 '1-5' 로 표시할수있다



2./etc/crontab

→ 시스템이 정기적인 작업이 수행될수 있도록 기본적으로 설정되어있는 파일이다.



3./var/spool/cron 디렉토리

→ 각각의 사용자가 등록한 crontab은 이 디렉토리아래에 각 사용자이름으로 저장된다.



♠ crontab 내용 설정예



0 12 * * 1-5 /home/bluetree/start

→ 월요일부터 금요일까지 /home/bluetree/start 란 스크립트를 실행시킨다.



0 12 1 1-12/2 * /home/bluetree/babo

→ 1월부터 12월까지 2개월마다 /home/blutree/babo 란 화일을 실행시킨다.



0 4 * * 1,3,5 cat /root/notice | mail -s "notice" bluetree75@naver.com

→ 월,수,금 오전 4시에 notice 라는 문서의 내용을 메일로 발송한다.



♠ cron 사용자 제한



※ /etc/cron.allow (허가목록) 과 /etc/cron.deny(거부목록) 을 참조하게된다.

1./etc/cron.deny 만 존재하는경우

→ 기본적으로 모든사용자가 사용가능하고 cron.deny 에 등록된 사용자만

사용불가능하다.

2./etc/cron.allow 만 존재하는 경우

→ cron.allow 파일에 등록된 사용자만 사용가능하다.

3. 두 파일 모두 없을경우

→ 모든 사용자가가능하다

4. 두 파일 모두 있을경우

→ cron.deny 내용을 무시하고 cron.allow 명기된 사용자만 사용가능하다






장애 극복 : Failover

Failover는 1차 시스템이 고장 또는 정기 유지보수 등의 이유로 이용할 수 없는 상태가 되었을 때, 2차 시스템이 즉시 그 임무를 넘겨받아 프로세서, 서버, 네트웍 또는 데이터베이스 등과 같은 시스템 구성요소의 기능들이 중단 없이 유지될 수 있는 백업 운전 모드를 말한다. 한 차원 더 높은 수준의 무정지형 시스템을 만드는데 주로 사용되었던 failover 개념은, 가동상태를 항상 유지해야 하는 극히 중요한 시스템의 핵심 부분이다. 여기에는 대기 중이던 시스템 구성요소로 작업들이 자동으로 옮겨짐으로써, 최종 사용자들에 한 순간의 중단도 없이 서비스를 제공할 수 있도록 하는 절차가 수반되어 있다. Failover는 어떠한 형태의 시스템에도 적용될 수 있는데, 예를 들어 PC에서의 failover란 고장난 프로세서로부터 보호하는 장치가 될 수 있으며, 네트웍에서의 failover는 접속 경로, 저장장치 또는 웹서버 등과 같은 네트웍 구성요소나 시스템 구성요소에 두루 적용될 수 있다.

저장된 데이터를 이용하기 위해서는 원래 점대점 또는 한 쌍이 상호 교차된 형태 등과 같이 매우 기본적인 구성 형태를 통해 서버에 접속해야만 했다. 이러한 환경에서는, 서버 한 대의 고장으로 인해 많은 사용자들이 서버가 복구되어 온라인에 연결되기 전까지는 원하는 데이터에 접근할 수 없게 된다. 그러나, 최근에는 SAN 등과 같은 여러 대의 서버와 데이터 저장 시스템 사이에서 다대다 접속을 가능케 하고 있다. 일반적으로 데이터 저장관련 네트웍은 많은 경로를 사용하는데, 각각의 경로는 서버와 해당 시스템간에 모든 구성요소가 연관되는 완전한 세트로 구성된다. 고장난 경로는 대개 그 경로의 어떤 개별 구성요소의 고장으로부터 유발될 수 있다. 구성요소들을 각각 이중으로 갖추고 있는 다양한 접속 경로는 하나 이상의 경로에 고장이 발생하더라도 서비스 존속이 가능하도록 보장하는데 사용된다. 자동으로 failover 되는 역량이 있다는 것은, 장비의 고장으로 인해 서비스가 중단되는 사태를 피할 수 없는 심각한 경우에서도 기능이 정상적으로 동작할 수 있도록 하는 것을 의미한다.


부하분산 : Load balancing
요약
병렬로 운영되는 기기 사이에서 부하가 균등하게 되도록 하는 일.

본문
로드밸런싱이라고도 한다. 병열로 운용되고 있는 기기 사이에서의 부하가 가능한 한 균등하게 되도록 작업 처리를 분산하여 할당하는 것을 말한다.
컴퓨터 내에서 여러 개의 마이크로프로세서에 작업의 처리를 균등하게 배정하거나 네트워크 상에서의 접속요구를 여력이 있는 서버로 돌리거나 하는 등 여러 분야에서 광범위하게 사용되고 있는 개념이다.
부하분산을 효율적으로 하기 위해서는 각 기기의 부하를 계속적으로 측정할 필요가 있다. 그러나 부하의 측정을 지나치게 엄밀하게 운용하게 되면 부하분산제어 자체가 오히려 큰 부하가 된다.
이 때문에 부하분산은 정밀도와 부하의 균형을 유지하는 형태로 실용화되고 있으며, 더욱 더 효율이 좋은 방법을 찾기 위한 연구가 계속되고 있다.


HA(High Availability)

HA, 중단 없는 서비스를 위한 필수 전략

인터넷의 급속한 발전으로 세계 어느 곳에 있든지 웹브라우저만 있으면 다양한 업무들을 처리할 수 있게 됐다. 전 세계가 인터넷이라는 거대한 하나의 고리로 연결됐을 뿐 아니라 인터넷 뱅킹, 전자결제, 전자상거래, 홈쇼핑, 증권 거래, 민원 업무 등 우리의 일상도 인터넷을 이용해 처리할 수 있게 된 것이다. 이처럼 인터넷이 생활 속으로 깊숙이 침투하고 이러한 서비스를 이용하는 사용자들이 빠르게 증가함에 따라 중단 없는 서비스에 대한 요구도 점점 높아지고 있다. 따라서 24×7×365일 항상 서비스를 제공할 수 있는 시스템이 절실하게 필요해졌다. ‘해가 져도 비즈니스는 계속된다’는 광고 카피처럼, HA(High Availability)는 이제 비즈니스의 연속성과 가용성을 극대화해주는 필수 전략이 되고 있다.

서비스 다운타임을 초래하는 요소들
서비스의 연속성을 저해하는 요인은 크게 두 가지로 나눌 수 있다. 계획된 다운타임(Planned Downtime)과 계획되지 않은 다운타임(Unplanned Downtime)이 바로 그것.
계획된 다운타임에는 △시스템 변경 △신규 시스템 도입 △데이터 백업 △소프트웨어 추가 △애플리케이션 마이그레이션 같은 것들이 있다.
시스템을 운영하는 데 이와 같은 작업은 필수이다. 비록 작업 전에 계획된 다운타임을 공고한다 할지라도 고객들은 서비스를 받지 못하는 불편함을 감수해야만 한다.
한편 계획되지 않은 다운타임에는 △정전 및 UPS 장애 △하드웨어 장애 △소프트웨어 장애 △네트워크 장애 같은 것들이 있다.
서비스 시스템은 항상 장애가 발생할 수 있는 소지를 갖고 있다.
계획되지 않은 다운타임은 서비스 시스템에 갑자기 발생하는 장애로 인한 것이다. 장애의 종류와 정도에 따라 다운타임 시간은 며칠이 될 수도 있다. 예고 없이 발생하는 장애로 인해 야기된 서비스 다운은 기업이나 조직에게 치명적인 위협을 가할 수도 있다.

서비스 장애 시 발생할 수 있는 일들
요즘 시스템을 이용해 처리되는 많은 업무들은 우리가 매일 이용하는 서비스들이다. 따라서, 서비스 장애 시 우리는 서비스의 중단에서 오는 불편함을 직접 느낄 수밖에 없다. 몇 가지 예를 살펴보자.
백화점에 가서 멋진 겨울 외투를 카드로 구매하려고 하는데, 신용카드 회사의 결제 서버에 장애가 발생한다면 어떻게 될까? 설상가상으로 백화점의 메인 서버에 장애가 발생하면 어떻게 될까? 우리는 물건을 사고 싶어도 살 수 없을 것이다.
홈쇼핑의 메인 서버에 장애가 발생하면 고객들은 큰 불편을 겪게 될 것이고, 홈쇼핑 업체에서는 엄청난 매출 손실을 보게 될 것이다. 또, 인터넷 상거래 서버가 다운되면 거래를 할 수 없게 된 수많은 회사들이 아우성을 칠 것이다. 자동화가 된 제조 업체에서 공장 제조 라인을 제어하는 서버에 장애가 발생하면, 공장 라인은 멈출 수밖에 없다.
필자는 동사무소에서 증명서를 발급받을 때, 한 시간 이상을 기다린 경험이 있다. 당시 증명서를 발행하는 서버에 문제가 있었기 때문이다.
물론, 예로 든 이러한 몇 가지 상황들은 극히 일부에 불과하다. 그러나 예고 없는 서비스의 중단은 우리의 일상 생활에 큰 불편을 초래한다는 점은 분명하다. 서비스가 중단됐을 때 우리가 할 수 있는 일이라곤 서비스가 복구되기를 기다리는 일뿐이다.



서비스 다운타임=손실
그림 2에서 보는 바와 같이 서비스의 다운타임은 곧 직접 손실로 이어진다. 서비스의 종류와 중요도에 따라 손실액은 더 증가할 수 있다. 서비스의 다운타임이 너무 오래 지속되면 그 기업은 회생하기 어려울 수도 있다.
피해액을 계산하기조차 어려운 간접 손실은 더 큰 문제다. 다운타임이 늘어날수록 직접 손실뿐만 아니라 추가적인 간접 손실도 늘어나고, 이는 비즈니스에 치명타가 된다. 브랜드 가치, 시장 점유율, 주가, 평판, 고객 만족 등이 추락하며, 고객들은 등을 돌리고 다른 기업을 찾아 떠난다. 한번 신뢰를 잃고 떠나간 고객은 되돌아오지 않는다.
‘소 잃고 외양간 고친다’는 속담이 있다. 서비스가 다운되는 장애를 겪은 후에야 시스템에 대한 투자를 서두르는 기업들이 바로 이에 해당하는 경우일 것이다. 미리 조금만 투자했더라면 훨씬 손실을 줄일 수 있었을 것이다. 서비스 다운 시 발생하는 간접 손실까지 고려하면, 가용성에 대한 투자는 필수라고 할 수 있다. 특히 요즘처럼 경쟁이 치열한 환경에서는, 서비스의 가용성을 높여야만 유사시에도 회사가 살아남을 수 있다는 절박한 인식이 필요하다.

HA 구성(클러스터 구성)
단일 시스템

시스템 가용성
언제나 보장(서비스 레벨의 HA 구성은 99.999%의 가용성 보장).
한 번 시스템에 장애가 발생하면 복구 시간이 오래 걸림(보통 97% 내외의 가용성을 보장).

애플리케이션
시스템이 다운돼도 대기 상태에 있는 서버에서 항상 서비스 가능.
시스템을 재구성한 후 다시 서비스 재개.

비용 및 효율성
초기 설치 비용에 대해서 부담이 있긴 하지만 훨씬 안정적이고 믿을 만한 서비스를 보장받을 수 있음.
설치 비용은 저렴하나 시스템 장애가 일어나게 되면 가용성이 보장 안됨.

평가
긴 안목에서 중단 없는 서비스를 제공해 더 효율적임.
장애는 곧 막대한 매출 손실뿐 아니라 항상 시스템 운영자를 불안하게 함.

(그림 3) HA 구성과 단일 시스템 비교

HA의 필요성
HA(High Availability)는 고가용성을 의미한다. HA와 클러스터(Cluster)라는 용어는 엄밀히 말하면 다르지만, 고가용성이라는 의미로 혼용해 사용하고 있다. 아마도 몇몇 HA 제품들의 명칭에 클러스터라는 단어가 사용되고 있기 때문일 것이다.
HA의 목적은 서비스의 다운타임을 최소화함으로써 가용성을 극대화하자는 것이다. 운영 서버에 장애가 발생하더라도, 대기 서버가 즉시 서비스를 대신 처리해 준다면 서비스의 다운타임은 최소화될 수 있다. 운영 서버에 언제 장애가 발생할 지는 아무도 예측할 수 없다. 관리자가 아무도 없는 새벽 시간에 장애가 발생할 수도 있다. HA는 관리자가 없을지라도, 운영 서버의 장애를 모니터링해 대기 서버가 처리할 수 있도록 함으로써 중단 없이 서비스를 제공하는 역할을 한다.
HA는 이와 같이 계획되지 않은 다운타임을 위해 구성하는 것이지만, 더불어 계획된 다운타임에 대해서도 이용할 수 있다. 운영 서버 작업 시, HA를 이용해 대기 서버로 쉽고 빠르게 서비스를 이관할 수 있다. 이렇듯 HA는 서비스 이관의 편리함을 제공한다.
과거에는 HA에 투자하는 것을 과잉 투자라고 생각했다. 그러나 HA는 이제 선택 사항이 아니다. e비즈니스 환경에서 기업이 살아남기 위한 필수 사항이 된 것이다.

가용성의 수준
가용성 100%는 이상적인 수치이다. 아무리 견고한 시스템이라도 장애가 발생할 수 있는 소지가 분명히 있다. 그림 2에 보면 99.99%인 경우, 1년 중 발생하는 다운타임은 총 52분임을 알 수 있다.
그러나 HA 솔루션에도 많은 진보가 있었다. HA 솔루션의 기술 진보 과정을 살펴보면 다음과 같이 나눌 수 있다.

1세대: 시스템 장애만을 감지하는 수준
시스템의 하드웨어 장애가 발생할 경우에만 장애를 감지해 대기 서버로 서비스를 이관한다. 그러나 애플리케이션의 장애는 감지하지 못하는 단점이 있었으며 99.5% 정도의 가용성을 제공한다.

2세대: 시스템 장애뿐만 아니라 서비스 레벨까지 감지
하드웨어 장애뿐 아니라 애플리케이션의 장애까지 감지해 서비스를 이관한다. 현재 상용 제품들이 대부분 2세대에 속한다. 대표 제품으로는 레가토, 베리타스 클러스터를 들 수 있으며 99.99% 정도의 가용성을 보장한다.

3세대: 커넥션 손실이 없는 차세대 HA
2세대 HA는 운영 서버 장애 시 커넥션 손실이 발생한다. 그리고 대기 서버가 서비스를 시작하면 새로운 커넥션을 형성해야 한다. 차세대 HA는 커넥션 손실이 없는 100% 가용성에 가장 근접한 HA가 될 것이다.

현재 대부분의 HA 제품은 2세대로서, 가용성 수준은 99.99%에 달한다. 2세대 제품에 대해서는 다음 회에서 고가용성의 다양한 구현 방법을 논하면서 설명할 계획이며, 100%를 지향하는 차세대 HA는 마지막 회에서 더욱 자세히 다룰 예정이다.

HA 구현 효과
HA 구현의 가장 큰 효과는 무엇보다 중단 없는 서비스를 가능하게 해준다는 것이다. 이와 더불어 HA는 시스템 관리자들의 부담을 가볍게 해준다. 시스템 관리자들의 어깨를 짓누르고 있는 것은 장애에 대한 부담이다. 장애 발생 시 서비스 중단에 대한 책임을 져야 하고, 시스템을 복구하는 것 또한 관리자들의 몫이다.
HA를 구현하면 관리자들의 짐이 줄어든다. 장애가 발생하더라도 대기 서버가 즉시 서비스를 수행하게 될 것이며, 본래 운영 서버를 수리할 시간 여유가 생기기 때문이다.

다양한 HA 제품들
현재 상용되고 있는 HA 제품들은 크게 하드웨어 업체에서 제공하는 것과 서드파티 제품으로 구분할 수 있다.
각 하드웨어 업체들은 자체 HA를 가지고 있다. 하드웨어 업체의 HA는 해당 하드웨어와 해당 OS에 종속적이다. 반면에, 서드파티 제품은 하드웨어 업체나 OS 플랫폼에 독립적이며 애플리케이션 레벨에서 동작하기 때문에 제품이 가볍다. 또한 이기종 OS 환경 하에서도 단일 콘솔로 관리할 수 있다는 장점이 있다.

HA가 관리하는 장애 포인트
HA는 어떠한 상황을 장애로 판단하고 대기 서버를 구동해 서비스를 하도록 하는 것일까?
HA가 관리하는 포인트는 크게 세 가지로 나누어 볼 수 있다.
- 하드웨어 장애: 전원 공급, CPU, 메모리, HDD 장애
- 네트워크 장애: 네트워크 카드, LAN 케이블 장애
- 프로세스 장애: DB 및 각종 애플리케이션 장애
HA는 계속해서 상대방 시스템의 상태를 모니터링하고 있다가 이와 같은 장애가 발생할 경우 자동으로 조치하게 된다. 이를 통해 서비스를 지속적으로 제공할 수 있도록 해준다.
HA는 양쪽 서버에 각각 설치하게 된다(그림 7).
각 시스템을 보면 맨 하단에 OS가 있고, 그 위에 애플리케이션이 있다. HA는 맨 상단에서 시스템과 애플리케이션을 모니터링한다. Heartbeat는 두 서버 간의 HA 통신 라인이다. 서로의 상태를 모니터링하는 중요한 연결 라인이다.
그림 8에 HA 절체(Failover) 원리에 대해 도시했다.
활성(Active)-대기(Standby) 상태의 두 시스템이 있다. 활성 서버에 장애가 발생했을 때, 모든 서비스가 대기 서버에서 구동돼 서비스가 이루어진다. 물론 HA가 활성 서버의 장애를 자동으로 감지해 대기 서버로 넘기는 것이다. 이런 현상을 절체, 페일오버(Failover), 스위치오버(Switchover)라고 말한다.
HA는 첫째, 서비스 IP인 10.10.10.3을 넘겨준다. 클라이언트에서는 10.10.10.3 IP만 찾으므로 대기 시스템으로 연결된다.
둘째, 스토리지의 파일 시스템인 /data를 마운트한다. 이 안에 모든 데이터가 들어있다.
셋째, DB 및 각종 애플리케이션을 구동한다. 애플리케이션까지 구동돼야만 온전한 서비스를 할 수 있게 된다.

지금까지 HA의 정의와 필요성, 구축 효과 등에 대해 알아보았다. HA의 도입으로 서비스의 가용성을 극대화할 수 있다. 언제 장애가 발생하더라도 HA가 자동으로 대처해 주기 때문에, 기업들은 업무의 지속성을 유지할 수 있으며, 관리자들은 장애에 대한 공포를 덜 수 있게 된다.