HA 이중화 구성 - HA ijunghwa guseong

-실제 서비스를 운영하는 Active 서버가 어떠한 장애로 정상적인 작동이 불가능해진다면, 곧바로 Standby 서버가 Active 되면서 다시 서비스를 정상 작동할 수 있게 하는 구성이다.

-이해하기 쉬운만큼 구조도 단순하고 따라서 구축 비용도 저렴하다. 또한, 서버 하나만 가동되면 되므로 유지비 역시 저렴하다는 장점이 있다.

-하지만, 몇가지 문제점이 있다. 각 서버 별로 별도의 storage를 가지고 있기 때문에 수시로 동기화가 이루어져야 하고, 따라서 성능 저하를 야기할 수 있다.

또한 이런 특성 때문에 각 서버간 데이터 싱크가 맞지 않는 상황도 존재할 수 있다.

마지막으로 굉장히 큰 문제인데, Active 서버가 동작을 멈추면 Standby 서버가 활성화 될 때까지의 트랜잭션을 모두 유실하게 된다는 것이다. 이는 실시간 트랜잭션량이 많은 서비스에서는 치명적인 문제이다.

OPS(Oracle Parallel Server)

-HA구성은 Active, Standby 구성이지만 OPS구성은 인스턴스가 모두 Active 상태로 동작하기에 이론적으로는 부하를 50% 분산할 수 있고, 서비스 속도도 두배 빨라질 수 있다. 하나의 스토리지를 사용하므로 동기화에 문제가 없다.

장점 : 부하 방지, 서비스 속도 향상, 동기화 문제 없음, 하나의 서비스가 중단되는 경우 예방

단점 : RAC Ping 

* RAC Ping

 : 같은 사용자가 각각의 서버에 동시접속 하였을 경우 인스턴스1에서 변경완료된 데이터를 인스턴트2로 가져오기위해서는 디스크에 저장 후 복사하여야함. 서로 다른 인스턴스에서 참조하기위해서는 disk에 저장한 후 다시 불러와야 하는 문제가 발생.

RAC(Real Application Cluster)

-2개, 혹은 그 이상의 인스턴스가 하나의 storage를 바라보고 있는 구성이다.

-각각의 인스턴스를 서버라고 생각하고 HA와 비교한다면 Active, Standby가 아닌 모두 Active 상태라고 할 수 있다.

-그리고 모두 하나의 storage를 바라보는 상황이므로 별도의 동기화로 인한 성능 저하는 없다.

-또, 하나의 인스턴스에서 장애가 발생해도 곧바로 다음 인스턴스에서 처리해줄 수 있으므로 데이터 유실에 대한 우려도 없다.

-HA에서는 하나의 서버가 모든 처리를 해야했으므로 상대적으로 큰 부하가 발생하지만, RAC 구성에서는 균형있게 분산되어 처리할 수 있다.

-하지만, 이 역시도 단점이 존재한다. 우선 Oracle RAC가 매우 고가의 제품이라는 것이다.

또한 매우 복잡한 환경 구성으로 인해 유지보수 절차 역시도 복잡하며, 운영 인력은 RAC에 대한 충분한 이해도 필수이다.

HA구조보다 빠른 복구 시간을 보장하지만, 실제로는 RAC 구조를 다루는데 미숙해서 복구시간을 연장시킬 가능성도 있다.

-RAC Ping 문제가 개선되어 성능이 크게 향상된 것으로 oracle9i 버전부터 서로 다른 인스턴스에서 변경된 데이터를 디스크를 거치지 않고 바로 인스턴스로 가져올 수 있는 기능인 Cache Fusion이라는 기능이 사용된다.

기업은 사내 전산 시스템이나 IT 서비스를 안정적으로 운영하기 위해 많은 시간과 비용을 투자하고 있습니다. 특히 서비스가 중단되는 시간을 뜻하는 다운타임(Downtime) 을 최소화 하기위해 모든 시스템을 이중화로 구성하고 장비의 상태를 지속적으로 확인하면서 정상적인 서비스를 유지하기위해 노력합니다. 이렇게 서비스를 안정적인 상태로 오래 기간 운영하는 성질을 고가용성(HA: High Availability) 이라고 표현합니다. 고가용성은 단어 그대로 높은 가용성을 보장한다 라는 뜻을 나타내며, 99%, 99.9%와 같은 퍼센티지로 서비스 품질 수준을 표현합니다1.

이중화에 대해서

높은 가용성을 보장하기 위해서는 어떤 방법이 있을까요? 이는 앞서 언급한 이중화에 핵심이 있습니다. 이중화는 시스템에 장애가 발생할 것을 대비해서 동일한 기능을 수행하는 예비 시스템을 동시에 운용하는 행위를 뜻합니다. 따라서 이중화 환경은 단일 시스템 환경보다 더 많은 구축 비용이 발생하며, 관리할 장비가 많아진 만큼 유지보수 비용 또한 높아집니다. 하지만 높아진 비용만큼 서비스가 중단될 확률을 낮출 수 있으며, 예상치 못한 장애가 발생하더라도 빠른 시간안에 복구가 가능해집니다.

고가용성이 보장되는 서비스 환경을 구축하기 위해 이중화 구성이 필요한 부분과 그렇지 않은 부분에 대해서 판단할 수 있어야 합니다. 또한 물리적인 시스템 외에도 소프트웨어의 핵심 기능들도 이중화 대상으로 인식하고 필요할 경우 모니터링을 수행하여 관리해야 합니다. 만약 장애가 발생할 수 있는 지점을 정확하게 확인하지 못한다면 단일 장애점(SPOF : Single Point of Failure)2 이 되어 서비스 장애로 이어질 수 있는 잠재적 요인이 될 수 있습니다. 반대로 불필요한 요소까지 이중화를 한다면 서비스에 영향이 없는 부분의 결함도 장애로 인식3하여 failover4 발생 시 원인 추적에 방해를 주거나 모니터링에 어려움을 겪는 등 시스템 운영에 혼란을 줄 수 있습니다.

따라서 이중화 환경을 구성할 때에는 서비스(소프트웨어)와 서버, 네트워크, 스토리지 등 각 분야에 전문성 있는 팀을 구성하여, 운영하고자 하는 환경과 서비스 목적에 알맞은 이중화 시스템을 구축할 수 있어야 합니다.

이중화는 크게 두 가지 방법으로 구성할 수 있습니다5. 첫번째는 Active/Standby 구성으로 HA 클러스터링 된 다중 서버 환경에서 한 대의 서버는 활성 상태(이하 Active)로 동작하고 나머지 서버들은 대기 상태(이하 Standby)로 동작합니다. 클러스터로 연결된 모든 서버는 heartbeat6로 연결되어 서버와 모니터링중인 서비스들의 상태를 주고받습니다. 이때 Active 서버에서 장애가 발생한다면 HA 클러스터는 Standby 서버 중에서 점수(Score)가 가장 높은 서버에게 서비스를 이관합니다.

두 번째는 Active/Active 구성입니다. Active/Active는 HA 클러스터로 연결된 모든 서버가 Active 서버로 동작하는 환경입니다. 흔히 부하 분산 모드(Load-Balancing) 로 불리기도 합니다. Active/Active 구성의 장점은 Active/Standby 비용으로 더 높은 처리량(Throughput)을 가질 수 있지만, 장애 발생 시 제외된 Active 서버의 대수만큼 처리량이 낮아지기 때문에 서비스 장애로 확대될 수 있습니다. 따라서 장애 상황에서도 안정적인 상태를 유지하기 위해서는 Active/Standby 구성보다 더 높은 처리량을 갖는 서버나 더 많은 대수로 구성하는 것이 안전합니다.

장애 상황 및 후속 조치

이중화 구성에서 장애 상황은 크게 세 가지로 구분할 수 있습니다. 첫번째는 하드웨어 장애 상황으로 전원 공급 장치에 이상이 발생하거나 컴퓨팅 구동에 핵심인 CPU와 메모리, 디스크 장애 등을 포함합니다. 서버 급 컴퓨터의 경우 전원 이중화, 듀얼 CPU 및 메모리, RAID 구성을 통해 방지할 수 있으나, 일반적인 PC 사양의 컴퓨터는 하드웨어 장애 상황을 대비하기 어렵습니다. 만약 하드웨어 장애가 발생할 경우, 운영체제 레벨에서 처리가 되겠지만, 시스템이 멈춰버린다면(흔히 hang이라고 표현합니다) HA 클러스터 레벨에서 heartbeat를 확인하여 시스템 정지를 확인하고 이후 failover 절차를 수행합니다.

두번째는 서비스 장애 상황입니다. 서비스 장애는 서버에서 동작하는 프로그램(어플리케이션)과 서비스 데몬(Daemon)에 장애가 발생한 것을 뜻합니다. 흔히 서비스는 데이터베이스, 아파치 웹, FTP와 NFS 같은 파일 공유 프로토콜 등을 포함합니다. 만약 서비스 장애가 발생하면 HA 클러스터는 장애를 인지하고 필요 시 복구 절차를 수행하며, 복구에 실패할 경우 failover를 수행하여 Active 서버를 이전합니다.

마지막으로 네트워크 장애 상황입니다. 네트워크 장애는 서버와 서버, 또는 장치를 연결하는 서버의 네트워크 레벨에서 발생하는 장애를 뜻합니다. 예를 들어 이더넷 네트워크인 네트워크 인터페이스 카드(NIC : Network Interface Card)는 IP 주소를 통해 통신을 수행하며, NIC에서 발생한 장애나 유효하지 않은 IP 주소가 입력되어 통신이 되지 않은 상황들을 예로 들 수 있습니다. 또한 스토리지 네트워킹 장치인 파이버 채널(FC : Fibre Channel)7과 고성능 컴퓨팅 환경에서 사용되는 인피니밴드(IB : InfiniBand)8도 네트워크 장애 범위에 포함됩니다. 네트워크는 본딩(Bonding)9과 티밍(Teaming) 등을 이용하여 다수의 인터페이스를 하나로 구성하여 인터페이스 장애 상황에서도 downtime 없이 서비스를 지속할 수 있습니다.

IT 관리자는 모니터링을 통해 failover가 발생한 것을 확인했다면, 장애가 발생한 서버를 신속하게 확인해야합니다. 물론 Standby 서버가 다수일 경우 추가 장애가 발생하더라도 failover 할 수 있는 여유 노드가 존재하기 때문에 서비스 장애(Downtime이 발생하는 상황)로 확대될 가능성은 낮습니다. 하지만 잘못된 지점을 모니터링하거나 확인하지 못한 지점에서 장애가 발생한 경우 등, 예상하지 못한 상황이 발생할 때, 클러스터링 된 서버들은 모두 동일한 환경이기 때문에 동일한 이유로 failover가 발생할 수 있습니다. 따라서 위와 같은 원인일 경우에는 모니터링 설정 변경 또는 새로운 장애 지점에 대한 모니터링 수행 등 추가 조치를 신속하게 수행해야 합니다.

스토리지 이중화

스토리지는 데이터가 최종적으로 저장되는 장치이며, 스토리지 중에서도 네트워크 기반의 공유 환경을 제공하는 NAS(Network Attached Storage)는 데이터 저장뿐만 아니라 공유 서비스, 사용자 인증 서비스, 네트워크 환경까지 고려해야 합니다. 따라서 NAS 이중화는 파일 저장과 공유 기능에 영향을 줄 수 있는 장애 지점들을 모두 파악하고 관련된 자원들을 모니터링해야 합니다. 또한 SAN(Storage Area Network)과 DAS(Direct Attached Storage)와 같이 블록 스토리지가 추가로 연결된다면, 모니터링이 필요한 지점은 증가할 것입니다.

NAS 이중화 구성에서 디스크를 클러스터링 하는 방법은 크게 두 가지로 구분할 수 있습니다. 첫번째는 디스크 공유 방식으로, 별도로 구성된 SAN과 DAS와 같은 블록 스토리지의 볼륨을 NAS를 통해 공유하는 것입니다. 이 경우, NAS와 블록 스토리지는 (일반적으로)파이버 채널 네트워크로 연결됩니다. 디스크 공유 방식은 NAS와 데이터 저장 공간이 물리적으로 분리되기 때문에 NAS를 추가로 확장하거나 교체를 하더라도 원본 데이터는 블록 스토리지에 저장되어 있는 것이 특징입니다.

두번째는 데이터 동기화 방식입니다. 데이터 동기화 방식은 디스크 공유 방식과 다르게 별도의 스토리지가 존재하지 않으며, NAS에 데이터가 저장될 디스크(Disk Set)가 설치되는 일체형 환경입니다. 각각의 NAS에는 물리적으로 분리된 디스크가 할당되기 때문에 데이터 또한 분리되어 있습니다. 따라서 모든 NAS의 데이터를 동기화하기 위해서는 별도의 데이터 복제 기술이 필요합니다. 데이터 복제 기술에 따라서 다르지만 보편적인 방법으로 디스크 클러스터를 구성할 경우 10G 이더넷 또는 인피니밴드를 사용하기도 합니다.

위처럼 데이터가 저장되는 디스크의 위치에 따라서 디스크 클러스터링 방법을 선택해야 합니다. NAS는 모든 환경에서 Active/Active와 Active/Standby를 위한 서비스 이중화 구성이 가능합니다. Active/Active와 Active/Standby에 대한 자세한 구성 방법은 다음 포스트에서 실 구축 사례와 같이 설명하도록 하겠습니다.

마치며

이번 포스트에서는 이중화의 기본 개념에 대해서 설명했으며, 더 나아가 IT 관리자 시점에서 고가용성을 높이기 위한 방법은 어떤 것이 있는지 알아보았습니다. 그리고 스토리지 분야에서 NAS 이중화 구성에 필요한 배경 지식과 디스크 구성 환경에 따른 디스크 클러스터링 방법을 살펴보았습니다.

다음 포스트에서는 이중화 구성에 사용하는 오픈소스 프로젝트를 소개하고, NAS 이중화를 위한 시스템 디자인 방법과 다년간 스토리지 이중화 구축 및 유지보수를 통해 얻은 경험을 공유 하겠습니다. 감사합니다.