HA(High Availability)

HA(High Availability)는 고가용성을 의미한다. HA와 클러스터(Cluster)라는 용어는 엄밀히 말하면 다르지만, 고가용성이라는 의미로 혼용해 사용하고 있다. 아마도 몇몇 HA 제품들의 명칭에 클러스터라는 단어가 사용되고 있기 때문일 것이다. HA의 목적은 서비스의 다운타임을 최소화함으로써 가용성을 극대화하자는 것이다. 운영 서버에 장애가 발생하더라도, 대기 서버가 즉시 서비스를 대신 처리해 준다면 서비스의 다운타임은 최소화될 수 있다. 운영 서버에 언제 장애가 발생할 지는 아무도 예측할 수 없다. 관리자가 아무도 없는 새벽 시간에 장애가 발생할 수도 있다. HA는 관리자가 없을지라도, 운영 서버의 장애를 모니터링해 대기 서버가 처리할 수 있도록 함으로써 중단 없이 서비스를 제공하는 역할을 한다. 고가용성 솔루션(HACMP)은 각 시스템 간에 공유 디스크를 중심으로 집단화(clustering)로 엮어지며 다수의 시스템을 동시에 연결할 수 있다.또한 HACMP 구성에 따라 여러 가지 방식으로 구현할 수 있지만 실제 널리 쓰이는 방식은 2개의 서버를 연결하는 것으로, 2개의 시스템이 각각의 업무를 수행한다. 즉, 1개의 서버에서 장애가 발생하면 다른 하나의 서버가 그 서버의 업무를 대신 수행하여 시스템 장애를 불과 몇 초 만에 복구할 수 있다.

서비스 다운타임을 초래하는 요소들

계획된 다운타임(Planned Downtime)

• 시스템 변경

• 신규 시스템 도입

• 데이터 백업

• 소프트웨어 추가

• 애플리케이션 마이그레이션

계획되지 않은 다운타임(Unplanned Downtime)

• 정전 및 UPS 장애

• 하드웨어 장애

• 소프트웨어 장애

• 네트워크 장애

	HA 구성 시스템	단일 시스템
시스템 가용성	언제나 보장	한번 시스템에 장애가 발생하면 복구 시간이 오래 걸림
어플리케이션	시스템이 다운돼도 대기 상태에 있는 서버에서 항상 서비스 가능	시스템을 재구성한 후 다시 서비스 재개
비용 및 효율성	초기 설치 비용에 대해서 부담이 있긴 하지만 훨씬 안정적이고 믿을 만한 서비스를 보장 받을수 있다.	설치 비용은 저렴하나 시스템 장애가 일어나게 되면 가용성이 보장 안됨
평가	긴 안목에서 중단 없는 서비스를 제공해 더 효율적임	장애는 곧 막대한 매출 손실뿐 아니라 항상 시스템 운영자를 불안하게 함

HA 솔루션의 기술 진보

1세대: 시스템 장애만을 감지하는 수준

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

2세대: 시스템 장애뿐만 아니라 서비스 레벨까지 감지

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

3세대: 커넥션 손실이 없는 차세대 HA

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

HA가 관리하는 장애 포인트

HA가 관리하는 포인트는 크게 세 가지로 나누어 볼 수 있다.

• 하드웨어 장애: 전원 공급, CPU, 메모리, HDD 장애

• 네트워크 장애: 네트워크 카드, LAN 케이블 장애

• 프로세스 장애: DB 및 각종 애플리케이션 장애

HA는 계속해서 상대방 시스템의 상태를 모니터링하고 있다가 이와 같은 장애가 발생할 경우 자동으로 조치하게 된다. 이를 통해 서비스를 지속적으로 제공할 수 있도록 해준다.

HA 클러스터링 구축 방법

활성-대기 구성

가장 기본적인 구성은 활성(Active)-대기(Standby) 구조이다.

한 서버가 활성 상태로 서비스하고 있을 때, 대기 서버는 전원은 켜 있고 OS까지만 올라와 있는 상태이다. 활성 서버에 하드웨어 장애나 네트워크 장애, 혹은 프로세스 장애 등이 발생해 서비스를 못하게 되면, 대기 서버에 있는 HA가 운영 서버의 장애 발생을 감지한다. 그리고HA가 자동으로 대기 서버에 모든 서비스를 올려준다. 즉, 단방향 페일오버를 구현하는 구성이다.

기존 활성 서버에 접속했던 클라이언트는 접속이 끊어지겠지만, 재접속 시 바로 서비스를 받을 수 있다. 왜냐하면 대기 서버가 모든 서비스를 대신하기 때문이다. 클라이언트 입장에서 보면 두 대의 서버 중에 어떤 서버가 서비스를 하는지는 관심 밖의 일이다. 서비스를 받을 수 있는가가 주관심이다. HA를 구현하는 가장 큰 이유는 중단 없는 서비스를 공급하는 데 있다.

활성-대기 구성의 가장 큰 장점은 단순함이라 할 수 있다. 구성하기도 쉽고, 관리자 입장에서도 운영하기 쉽다. 그래서 지금도 많은 기업의 시스템들이 이러한 구성으로 구현되고 있다.

활성과 대기 시스템의 사양을 동일하게 구성하는 경우도 있지만, 때에 따라서는 대기 시스템의 사양을 약간 낮게 구성하는 경우도 있다. 활성 서버의 장애 발생 시, 대기 서버가 서비스를 하면서 몇 시간 정도만 버텨 준다면, 이 시간에 원래의 활성 서버를 수리할 수 있다. 그리고 서비스를 원래의 활성 서버로 돌려놓을 수 있기 때문이다.

활성-활성 구성

기업의 운영자 입장에서 봤을 때, 대기 서버는 보통 때 아무 일도 안 하니 투자한 비용이 아깝다는 생각을 하게 된다. 어떠한 방식으로든지 대기 서버도 보통 때 다른 업무를 서비스하기를 원한다. 래서 나온 방식이 활성(Active)-활성(Active) 구성이다.

활성-활성 구성에서는 한 서버가 DB 서비스를 하고, 다른 서버는 웹 서비스를 제공하게 된다.두 대의 서버가 각기 다른 서비스를 제공하는 것이다. 그러다가 DB 서버에 장애가 발생할 경우, HA는 웹 서버에서 DB 서비스를 할 수 있도록 한다.

즉, 웹 서버는 원래 자신이 하던 웹 서비스뿐만 아니라 DB 서비스까지 두 가지 일을 수행하게 된다. 반대로 웹 서비스에 장애가 발생했을 경우, DB 서버에서 DB 서비스뿐만 아니라 웹 서비스까지 같이 수행하게 된다. 상호 대기 서버가 되는 구성이다.

그런데 이런 구성을 하고자 한다면 몇 가지 고려해야 할 사항이 있다.

우선 하나의 서버에서 DB와 웹 서비스 두 가지를 할 수 있도록 시스템 사양을 설계해야만 한다. 이렇게 설계하지 않고 하나의 서버에서 두 가지 서비스가 실행될 경우 서버가 부하를 견디지 못해 다운될 수도 있다. 그러면 두 가지 서비스 모두 장애가 발생해, HA 클러스터를 구축한 효과를 볼 수가 없다. 또, 하나의 서버에서 두 가지 서비스가 모두 실행될 수 있도록 환경 설정도 해줘야 한다.

활성-대기보다는 구성상 약간 복잡해지지만, 이 구성은 한 직장에서 근무하는 의좋은 동료 같은 느낌을 준다. 회사에서도 동료가 아플 경우, 다른 동료가 자신의 일뿐만 아니라 아픈 동료의 일까지 대신 수행하는 것과 같은 것이다.

전용 대기 서버를 구축할 경우

두 대의 활성 서버는 각기 다른 서비스를 하고 있다. 전용 대기 서버는 한 대이다. 장애가 발생하면, 전용 대기 서버가 장애가 발생한 서버 대신 서비스를 하게 된다. 물론 전용 대기 서버는 두 서비스를 할 수 있는 충분한 사양이 되도록 설계해야 한다.

상호 대기로 구축할 경우

세 대의 서버가 모두 각기 다른 서비스를 한다. 이들은 또 상호 대기 서버가 되기도 하는데, 일례로 DB 서버가 다운됐을 경우에는 웹 서버가 웹 서비스와 DB 서비스까지 하게 된다. 역시 파일 서버가 다운되면, DB 서버가 DB 서비스와 파일 서비스를 모두 제공할 수 있도록 구성하게 된다.

HA 활용 방안

서비스 복구 방법

활성 서버에 장애가 발생하면, 대기 서버에서 서비스를 하게 된다. 그럼, 장애가 발생한 서버의 문제점을 수정한 후 서비스를 원래의 활성 서버로 돌려놓기 위해서는 어떻게 해야 할까?

HA가 구현된 시스템에서는 마우스 버튼 클릭 하나로 서비스를 원래 메인 서버로 아주 쉽게 옮길 수 있다. 단, 서비스의 다운타임이 몇 초라도 발생하므로 이 작업은 서비스 사용자가 없는 야간 시간대나 특정 시간대를 이용하는 것이 좋다.

운영 서버 업그레이드 작업 시 HA 활용법

시스템을 운영하다 보면, 업그레이드나 구성을 변경해야 할 때가 있다. 단일 시스템만으로 운영하는 경우에는 이 같은 작업을 하기 위해서 어쩔 수 없이 서비스 다운을 사용자들에게 공지하고, 사용자가 적은 야간 시간대에 작업을 해야만 했다. 하지만, HA를 구성해 놓은 환경이라면 마우스 버튼 클릭 하나만으로 대기 서버에서 서비스를 하도록 변경할 수 있다. 작업 중에도 서비스는 차질 없이 지속되기 때문에, 고객들은 하등의 불편을 겪지 않아도 되며, 관리자들 역시 마음의 여유를 가질 수 있는 것이다. 원래의 HA 구현 목적은 운영 서버의 장애 발생 시, 대기 서버에서 자동으로 서비스를 재개해 서비스가 지속적으로 제공되도록 하는 것이지만, 이와 같이 계획된 시스템 다운 시에도 HA는 매우 유용하게 활용될 수 있다.