High Availability (HA, 고가용성, 高可用性)

대문 / 네트웍, 프로그래밍 / High Availability (HA, 고가용성, 高可用性)

High Availability (HA, 고가용성, 高可用性)

1.1. 개요

High Availability (HA, 고가용성, 高可用性)이란 네트워크(Network) 및 프로그램(Program) 등의 정보를 다루는데 있어서 오랜 기간 동안 지속적으로 운영을 유지할 수 있는 성질을 의미합니다.

절대 고장 나지 않는 하드웨어(Hardware), 절대 비정상 종료되지 않는 소프트웨어(Software), 새로운 기능을 넣을 때 중단시간이 발생되지 않는 등의 이상적인 환경을 달성하기 위해서는 그 만큼 충분한 요소들이 깊은 고민으로 설계 및 시험되어야 합니다.

중요한 정보를 다루는데 있어서 이러한 고가용성(高可用性)을 달성할 수 있다면 정보의 손실이나 정보접근의 기회손실을 줄일 수 있을겁니다.

여기서는 고가용성(高可用性)을 달성하는데 필요한 요소를 언급하고 어떤 방법으로 이를 고민하는지 가볍게 다루고자 합니다.

아래 내용은 어디까지나 개인적인 고민과 해석관점에서 작성되었기 때문에 틀린 부분이나 다른 이견이 있을 수 있습니다. 관련하여 의견이 있으시면 꼭! 이메일등으로 알려주시면 본문에 반영하겠습니다.

1.2. 고려해야 할 요소

  • Network 장비 고장 또는 논리 오류
    • 회선 단락
    • Noise / checksum 오류
    • 경로 설정/학습 오류
    • 악성 공격에 의한 서비스 불가 상태
    • Virtual IP 또는 Virtual MAC address 를 어떻게 관리할지
      • GARP 간격
      • Checker 의 종류 및 주기
      • Preemption delay
      • Asymetric 흐름
      • L2 / L3 네트워크 구성에 따른 특성 고려
    • IP / MAC address 충돌
    • 부하 분산 (Load balancing) / Active-Standby or Active-Active / QoS
      • 가용 장비의 리소스를 모두 최대한 활용할 수 있도록 고려
        • 백업 리소스가 최소한의 정보만 처리할 수 있는 수준인 경우 선별적 정보 분산 시나리오 필요
      • 정보의 흐름에 순서가 중요한 경우도 있을 수 있는데 이것을 만족하려면 부하 분산은 정보의 문맥단위로 고려할 필요성
        • 쪼개어진 정보 (Fragmentation) 를 나누어 분산 처리할지 고려
  • Storage 장비의 고장
    • 연결 에러
    • 잘못된 데이터 저장
    • Bad sector
  • CPU 고장
  • Memory 고장
    • ECC(Error Correcting Code) 오류
  • 재난상황에 따른 이용불능
    • 화재 / 전쟁 / 건물붕괴 / 정전 / ...
      • 백업된 정보가 동일한 위치에 함께 있는 경우 해당 재난상황이 복구되기 전까지는 서비스는 중지상태가 될 수 밖에 없음. 백업된 정보 또는 백업 장비는 위치적으로 떨어진 곳에 구성하는 것도 고려
  • Bug 에 따른 비정상 동작
    • 비정상 종료 (Segment fault, Div Zero, ...)
    • 비정상 문맥 흐름 (무한 Loop, Hangup, Panic, ...)
    • 잘못된 결과 도출
    • 중복 실행
    • 경쟁조건 미고려 오류
    • 호환성 결여
    • 리소스 부족
      • 최적화 부족에 따른 메모리 남용
      • Memory pool 부족 / 과다 사용 설계
      • 메모리 / File Descriptor / Resource handle 누수
  • 설계 변경 / 신규 기능등에 의한 중단 발생
  • 설정 오류

1.3. 장애가 발생되는 경우와 이에 따른 예상 절체 구현 시나리오

  • 복구 시나리오는 최대한의 경우의 수에 따른 메뉴얼이 작성되고 참조하기 쉽도록 제공되어야 함.
    • 정기적으로 복구 예행 연습등이 시스템적으로 마련되어 꾸준히 복구 시나리오를 숙지 필요.
  • 장애의 복구 또는 절체는 정보흐름의 연속성을 기준으로 고려될 필요가 있음.
    • 절체(FailOver)와 복구되었을 때 다시 원복되는 복원(FailBack) 등이 필요한지 검토가 필요 함.
      • 절체(FailOver) 시나리오가 잘된다고 복원(FailBack) 시나리오도 잘된다고 장담하기 어려운 경우가 존재할 수 있음.
    • 장애 현상은 일시적인 것과 장기적인 발생상황으로 나누어 생각해볼 필요가 있음.
      • 일시적인 장애상황에 절체가 이루어질 때 반복적인 절체되는 이른바 핑-퐁 현상에 대한 대처가 필요할 수 있음.
        • 빠른 절체/복원 시나리오를 수립할 수록 핑-퐁 현상의 가능성이 통상적으로 증가할 수 있음에 유의가 필요.
          • Preemption delay 가 어느 정도 고려될 필요성
      • 장기적인 장애상황은 복구가 가능한 경우와 아닌 경우로 나뉠 수 있고 복구가 불가능하다면 최대한 관리자의 조치가 이루어질 수 있도록 여러 경로로 알림이 필요할 수 있음.
  • 하드웨어 고장 또는 소프트웨어 오류가 발생한 장비의 정보는 불확실성을 가질 수 있다는 것을 염두해야 할 필요가 있음.
    • 소프트웨어 오류는 다양한 증상이 발생될 수 있으며 소프트웨어의 정상 동작 유무를 모니터링하기 위해서는 다양한 예측과 수단이 필요 함.
      • 소프트웨어가 실행 중이라고 서비스가 이루어진다고 가정할 수 없음. 소프트웨어 내부 버그로 아무것도 하지 않거나 엉뚱한 응답을 발생할 수 있다는 점.
    • 특정 하드웨어 부품이 고장인 경우 이를 Hot plug로 교체가능한지 여부에 따른 복구 메뉴얼이 달라질 수 있음.
  • 정보를 저장하는 서비스의 경우는 백업이라는 수단을 필요로 할 수 있으며 이러한 백업이 올바르게 복원이 가능한지 수시로 점검이 필요 함.
    • RAID는 정보를 저장하는데 있어서 어느정도의 백업수단으로 볼 수 있으나 복잡하고 사람의 실수로 저장된 정보도 다루기 때문에 완전한 백업으로 판단하는 오류를 조심해야 함.
    • 정보의 백업은 동일한 영역에 저장하는 것보다는 물리적 위치가 멀리 떨어진 곳에 백업 저장하는 것이 필요할 수 있음.
  • 서비스를 배포하기 전에 사전 테스트할 수 있는 환경이 고려될 필요성도 검토가 필요
  • 설계단계부터 호환성이라는 것을 충분히 검토한다면 배포오류를 줄이는데 용이할 수 있음.
    • 지금은 구현되지 않거나 쓸일이 없는 기능이어도 미래를 모를 일
    • 명확한 설계문서를 생산/관리하는 것이 없는 것보다는 좋음.
  • 로그의 기록 및 열람 구조는 원인을 찾는데 훌륭한 수단이라는 점.
    • 무엇을 수행했다는 로그보다는 무엇이 실패했다는 로그가 중요
    • 불필요한 로그인가? 필수적인 로그인가를 로그레벨등으로 관리하는 체계가 필요
    • 로그 과다로 인한 장애도 존재할 수 있다는 점.
      • 보통 실패로그는 첫 실패로그가 중요하고 그 이후의 실패로그들은 유발되는 실패이거나 반복적인 로그가 될 수 있음.
      • 치명적 오류에 대한 로그는 운영자가 빨리 인지할 수 있도록 별도의 알림수단을 마련

1.4. VRRP (Virtual Router Redundancy Protocol)

VRRP(Virtual Router Redundancy Protocol) 는 여러 장비들을 Group으로 묶어 하나의 가상 IP 주소(Virtual IP, VIP)를 Master 상태인 장비에게 부여하고 Master상태인 장비가 장애상황이 발생되는 경우 해당 Group 내의 Backup상태인 장비가 Master상태로 전환되도록 하는 프로토콜입니다.

즉, Router1, Router2, Router3, ... 은 VRRP Group으로 구성돼 Client들에게 Routing 서비스를 제공하고 VRRP 에서는 Master/Backup 개념이 사용되며 동일한 VRRP Group에 속하는 Router Group은 Priority 등의 우선권으로 각각 Master 또는 Backup 동작을 결정하게 됩니다.

VRRP 주요 특성은 다음과 같습니다.
  • 현재 VRRP 는 2가지 버젼이 있으며 서로 호환되지 않으므로 각각의 장비는 같은 버전으로 통일해서 운영해야 합니다.
    • VRRP v1 은 없습니다. (사용되지 않은 버젼)
    • VRRP v2 ([https]RFC3768 - Virtual Router Redundancy Protocol[](https://tools.ietf.org/html/rfc3768))
      • IPv4만 지원
      • 초단위 시간해상도를 사용
      • Multicast 주소로 224.0.0.18 을 사용
      • Virtual Router-ID : 00:00:5E:00:01:xx
      • Preemption criteria : Node with same priority value but higher IP would cause preemption
      • Enable VRRP : Enabled on per interface basis
    • VRRP v3 ([https]RFC5798 - Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6[](https://tools.ietf.org/html/rfc5798))
      • IPv4, IPv6 지원
      • 밀리초단위 시간해상도를 사용
      • Multicast 주소로 224.0.0.18 과 ff02::12 을 사용
      • Virtual Router-ID : IPv4의 경우 00:00:5E:00:01:xx, IPv6의 경우 multicast 주소 ff02::12를 통하여 Hello message 전송
      • Preemption criteria : Only higher priority would cause preemption
      • Enable VRRP : Need to be enabled globally
  • Priority 값은 1~255까지를 사용할 수 있으며 높은 값일수록 우선순위가 높습니다.
  • Priority 255 는 특별한 경우로 실제 물리적 Real IP 가 VRRP VIP와 같은 경우 255로 간주됩니다. (즉, 보통 설정은 1~254까지만 사용합니다.)
  • Master 상태가 되고 Priority 가 높은 우선순위인 경우 해당 회선내의 장비들의 MAC 학습 갱신을 위해서 GARP를 송신하는게 필요합니다.
  • 만약 VRRP 가 모두 동일한 Priority 로 설정된 경우 IP 주소가 큰 VRRP 쪽이 Master 상태가 됩니다.
    • 단, 양쪽사이가 단절되어 모두 Master 상태였다가 양쪽 통신이 가능해진 경우에 IP주소가 작은쪽이 Master 상태를 포기하고 Backup 상태로 전환됩니다.
  • IP 주소가 큰 경우쪽이 Fault/Backup 상태였던 경우 nopreemt(비 선점) 설정인 경우 IP주소가 큰 장비는 Master 상태로 전환되지 않고 Backup 상태를 유지됩니다.

1.5. HSRP (Hot Standby Routing Protocol)

VRRP와 유사하지만 Cisco회사에서 개발한 독자적인 프로토콜입니다.

1.6. RAID (Redundant Array of Inexpensive/Independent Disk)

1.7. Storage / Filesystem snapshot

1.8. DR (Disaster Recovery, 재해복구)

1.9. 참고자료

Retrieved from https://www.minzkn.com:443/moniwiki/wiki.php/HighAvailability
last modified 2024-05-17 23:26:16