728x90
반응형

HA (High Availability): 무중단 서비스를 위한 고가용성 아키텍처

개요

디지털 경제 시대에 서비스 중단은 막대한 경제적 손실과 고객 이탈을 초래합니다. Amazon, Google, 금융 기관 등은 1분의 다운타임도 허용하지 않는 무중단 서비스를 제공하기 위해 HA(High Availability, 고가용성) 아키텍처를 구축합니다. HA는 단순한 백업을 넘어, 클러스터링 기술을 통해 시스템 구성 요소의 장애가 발생해도 서비스 연속성을 보장하는 종합적인 설계 철학입니다. 본 포스트에서는 HA의 핵심 개념인 클러스터링, 다양한 HA 구성 유형, Failover 메커니즘, 그리고 현실적인 한계와 극복 방안을 체계적으로 살펴보겠습니다.

HA (High Availability) 개념

고가용성이란?

  • 정의: 시스템 또는 서비스가 지속적으로 운영 가능한 능력을 보장하는 아키텍처
  • 목표: 장애 발생 시에도 최소한의 다운타임으로 서비스 연속성 유지
  • 핵심 원리:
    • 중복성(Redundancy): 모든 단일 장애점(SPOF) 제거
    • 자동 장애 조치(Automatic Failover): 수동 개입 없이 자동 전환
    • 상태 동기화(State Synchronization): Active-Standby 간 데이터 일관성

가용성 계산

가용성(%) = (총 운영 시간 - 다운타임) / 총 운영 시간 × 100
가용성 연간 다운타임 월간 다운타임 주간 다운타임 일간 다운타임
99% 3.65일 7.31시간 1.68시간 14.40분
99.9% 8.77시간 43.83분 10.08분 1.44분
99.99% 52.60분 4.38분 1.01분 8.64초
99.999% 5.26분 26.30초 6.05초 864밀리초
99.9999% 31.56초 2.63초 604밀리초 86.4밀리초

HA vs DR (Disaster Recovery)

graph TD
    A["서비스 연속성"] --> B["HA<br/>(High Availability)"]
    A --> C["DR<br/>(Disaster Recovery)"]

    B --> D["목적:<br/>단일 장애 대응"]
    B --> E["복구 시간:<br/>초~분"]
    B --> F["범위:<br/>동일 데이터센터"]

    C --> G["목적:<br/>재난 대응"]
    C --> H["복구 시간:<br/>시간~일"]
    C --> I["범위:<br/>지리적 분산"]

클러스터링 (Clustering)

클러스터링 정의

  • 개념: 두 대 이상의 시스템을 논리적으로 묶어 하나의 시스템처럼 운영
  • 목적: 장애 발생 시 Failover를 통한 서비스 지속성 확보
  • 구성 요소:
    • 노드(Node): 클러스터를 구성하는 개별 서버
    • 클러스터 소프트웨어: 노드 간 통신 및 Failover 관리
    • 공유 스토리지: 노드 간 데이터 공유 (일부 구성)
    • 전용 네트워크: Heartbeat 통신용 Private Network

클러스터링 아키텍처

graph TB
    subgraph "HA 클러스터"
    A["Primary<br/>Node"] <-->|"Heartbeat<br/>(Private Network)"| B["Standby<br/>Node"]
    A <-->|"데이터 동기화"| C["Shared Storage<br/>or<br/>Replicated Storage"]
    B <-.->|"데이터 접근"| C
    end

    D["Client"] -->|"Public Network"| E["Virtual IP<br/>(VIP)"]
    E --> A

    A -->|"장애 발생"| F["Failover 시작"]
    F --> G["Standby가<br/>VIP 인수"]
    G --> H["서비스 계속"]

Heartbeat (Keep Alive) 메커니즘

Heartbeat 개념

  • 정의: 노드 간 주기적으로 전송하는 생존 확인 신호
  • 목적: 상대방 노드의 정상 동작 여부 실시간 모니터링
  • 메시지: "I'm alive" 신호, 일반적으로 1-5초 간격

Heartbeat 동작 원리

sequenceDiagram
    participant P as Primary Node
    participant S as Standby Node

    loop 정상 상태
        P->>S: Heartbeat (1초마다)
        S->>P: Heartbeat ACK
        Note over S: Primary 정상 확인
    end

    Note over P: 장애 발생<br/>(네트워크/시스템)

    S->>P: Heartbeat 전송
    Note over S: ACK 없음 (1회)

    S->>P: Heartbeat 재전송
    Note over S: ACK 없음 (2회)

    S->>P: Heartbeat 재전송
    Note over S: ACK 없음 (3회)

    Note over S: 장애 판정!<br/>(Timeout)

    S->>S: Failover 시작
    S->>S: VIP 인수
    S->>S: 서비스 활성화

Heartbeat 구현 예시

# Python Heartbeat 예시
import socket
import threading
import time

class HeartbeatMonitor:
    def __init__(self, peer_ip, port=5000, interval=1, timeout=3):
        self.peer_ip = peer_ip
        self.port = port
        self.interval = interval  # Heartbeat 간격 (초)
        self.timeout = timeout    # 장애 판정 임계값 (실패 횟수)
        self.failure_count = 0
        self.is_peer_alive = True

    def send_heartbeat(self):
        """주기적으로 Heartbeat 전송"""
        while True:
            try:
                sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
                sock.settimeout(0.5)

                # Heartbeat 메시지 전송
                message = "HEARTBEAT"
                sock.sendto(message.encode(), (self.peer_ip, self.port))

                # ACK 대기
                data, addr = sock.recvfrom(1024)
                if data.decode() == "ACK":
                    self.failure_count = 0
                    self.is_peer_alive = True
                    print(f"[OK] Peer {self.peer_ip} is alive")

            except socket.timeout:
                self.failure_count += 1
                print(f"[WARNING] Heartbeat timeout ({self.failure_count}/{self.timeout})")

                if self.failure_count >= self.timeout:
                    self.is_peer_alive = False
                    print(f"[CRITICAL] Peer {self.peer_ip} is DOWN!")
                    self.trigger_failover()

            except Exception as e:
                print(f"[ERROR] Heartbeat failed: {e}")

            finally:
                sock.close()

            time.sleep(self.interval)

    def trigger_failover(self):
        """Failover 수행"""
        print("[ACTION] Starting Failover...")
        # VIP 인수
        self.acquire_vip()
        # 서비스 활성화
        self.start_services()

    def acquire_vip(self):
        """Virtual IP 인수"""
        # Linux 예시
        import os
        vip = "192.168.1.100"
        interface = "eth0"
        os.system(f"ip addr add {vip}/24 dev {interface}")
        print(f"[VIP] Acquired {vip}")

    def start_services(self):
        """서비스 시작"""
        # 애플리케이션 서비스 시작
        import os
        os.system("systemctl start myapp")
        print("[SERVICE] Application started")

# 사용 예시
monitor = HeartbeatMonitor(peer_ip="192.168.1.2")
threading.Thread(target=monitor.send_heartbeat, daemon=True).start()

Heartbeat 네트워크

graph LR
    A["Primary Node"] <-->|"Heartbeat 1<br/>(Ethernet)"| B["Standby Node"]
    A <-.->|"Heartbeat 2<br/>(Serial/RS-232)"| B

    A --> C["Public Network"]
    B -.-> C
  • 이중화(Redundant Heartbeat): 네트워크 장애와 노드 장애 구분
    • Ethernet Heartbeat 실패 + Serial Heartbeat 성공 → 네트워크 장애 (Split-Brain 방지)
    • 모든 Heartbeat 실패 → 노드 장애

HA 유형

1. Hot Standby (열대기)

개념

  • 정의: Primary와 Standby가 모두 가동 상태, Standby는 대기만 수행
  • 특징:
    • Standby가 전원이 켜진 상태로 대기
    • 데이터는 실시간 동기화
    • Failover 시간: 초 단위
    • 가장 일반적인 HA 구성

아키텍처

graph TB
    subgraph "Hot Standby 구성"
    A["Primary Node<br/>(Active)"]
    B["Standby Node<br/>(Hot Standby)"]

    A -->|"데이터 복제<br/>(실시간)"| C["Shared Disk<br/>or<br/>Replicated Disk"]
    B -.->|"대기<br/>(Read-Only)"| C

    A <-->|"Heartbeat"| B
    end

    D["Client"] --> E["VIP:<br/>192.168.1.100"]
    E -->|"바인딩"| A

    F["장애 발생"] --> G["Standby가<br/>VIP 인수"]
    G --> H["Standby가<br/>Primary 승격"]

동작 시나리오

1. 정상 상태:
   - Primary: 서비스 제공, 데이터 Write
   - Standby: Heartbeat 모니터링, 데이터 동기화 수신

2. Primary 장애 발생:
   - Standby: Heartbeat Timeout 감지 (예: 3초)

3. Failover 시작:
   - Standby: VIP(192.168.1.100) 인수
   - Standby: 공유 디스크 또는 복제 디스크 Mount
   - Standby: 애플리케이션 서비스 시작

4. 서비스 재개:
   - Client: VIP로 접속 시 Standby로 자동 연결
   - 서비스 중단 시간: 3-10초

구현 예시 (Keepalived)

# /etc/keepalived/keepalived.conf (Primary)
vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100          # Primary 우선순위 높음
    advert_int 1          # Heartbeat 간격 (1초)

    authentication {
        auth_type PASS
        auth_pass secret123
    }

    virtual_ipaddress {
        192.168.1.100/24  # VIP
    }
}

# /etc/keepalived/keepalived.conf (Standby)
vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 90           # Standby 우선순위 낮음
    advert_int 1

    authentication {
        auth_type PASS
        auth_pass secret123
    }

    virtual_ipaddress {
        192.168.1.100/24
    }
}

2. Mutual Takeover (상호 인수)

개념

  • 정의: 두 노드가 각각 다른 서비스를 Primary로 운영하면서 서로의 Standby 역할 수행
  • 목적: 하드웨어 자원 활용률 극대화
  • 특징:
    • 양쪽 노드 모두 Active 상태
    • 각 노드가 서로 다른 서비스 담당
    • 장애 시 한쪽이 양쪽 서비스 모두 처리

아키텍처

graph TB
    subgraph "Mutual Takeover 구성"
    A["Node A"]
    B["Node B"]

    A -->|"Primary"| C["Service 1<br/>(Web Server)"]
    A -.->|"Standby"| D["Service 2<br/>(DB Server)"]

    B -.->|"Standby"| C
    B -->|"Primary"| D

    A <-->|"Heartbeat"| B
    end

    E["Client 1"] --> F["VIP1: 192.168.1.101"]
    G["Client 2"] --> H["VIP2: 192.168.1.102"]

    F --> C
    H --> D

    I["Node A 장애"] --> J["Node B가<br/>Service 1+2<br/>모두 처리"]

장단점

장점

  • 하드웨어 활용률 높음 (Standby가 유휴 상태 아님)
  • 비용 효율적
  • 두 서비스 모두 이중화 달성

단점

  • 장애 시 한 노드에 부하 집중 (성능 저하 가능)
  • 리소스 여유 필요 (각 노드가 양쪽 서비스 처리 가능해야 함)

구현 예시

# Pacemaker + Corosync 구성
# Node A
crm configure primitive WebService ocf:heartbeat:apache \
    params configfile="/etc/apache2/apache2.conf" \
    op monitor interval="10s"

crm configure primitive DBService ocf:heartbeat:mysql \
    params datadir="/var/lib/mysql" \
    op monitor interval="10s"

# Node A는 WebService를 Primary로
crm configure location WebService-on-NodeA WebService 100: node-a

# Node B는 DBService를 Primary로
crm configure location DBService-on-NodeB DBService 100: node-b

3. Concurrent Access (동시 접근)

개념

  • 정의: 여러 노드가 동시에 같은 데이터에 접근하여 Active-Active로 서비스 제공
  • 특징:
    • 모든 노드가 Active 상태
    • 부하 분산(Load Balancing) 효과
    • 공유 디스크에 동시 접근 (DLM, Distributed Lock Manager 필요)

아키텍처

graph TB
    A["Load Balancer<br/>VIP: 192.168.1.100"]
    B["Node 1<br/>(Active)"]
    C["Node 2<br/>(Active)"]
    D["Node 3<br/>(Active)"]

    A -->|"분산"| B
    A -->|"분산"| C
    A -->|"분산"| D

    B <-->|"DLM<br/>(분산 락)"| E["Shared Storage"]
    C <-->|"DLM"| E
    D <-->|"DLM"| E

    F["Client 1"] --> A
    G["Client 2"] --> A
    H["Client 3"] --> A

    I["Node 2 장애"] --> J["Load Balancer가<br/>Node 1, 3으로<br/>트래픽 재분배"]

DLM (Distributed Lock Manager)

// DLM 개념적 예시
void update_shared_data(int node_id, Data* data) {
    // 분산 락 획득
    lock_handle = dlm_lock("shared_data", EXCLUSIVE);

    if(lock_handle != NULL) {
        // 공유 데이터 수정
        modify_data(data);
        write_to_shared_storage(data);

        // 락 해제
        dlm_unlock(lock_handle);
    } else {
        // 락 획득 실패 - 재시도 또는 대기
        handle_lock_failure();
    }
}

적용 사례

  • Oracle RAC (Real Application Clusters)

    • 여러 Oracle 인스턴스가 하나의 데이터베이스에 동시 접근
    • Cache Fusion으로 노드 간 데이터 블록 공유

  • VMware vSphere HA

    • 여러 ESXi 호스트가 공유 데이터스토어 접근

  • GFS2 (Global File System 2)

    • 클러스터 파일 시스템, 동시 읽기/쓰기 지원

Failover 프로세스

Failover 단계

graph TD
    A["1.장애 감지<br/>(Fault Detection)"] --> B["2.장애 확인<br/>(Fault Confirmation)"]
    B --> C["3.리소스 인수<br/>(Resource Takeover)"]
    C --> D["4.서비스 시작<br/>(Service Startup)"]
    D --> E["5.클라이언트 재연결<br/>(Client Reconnection)"]
    E --> F["서비스 정상화"]

    B -.->|"False Alarm"| G["계속 모니터링"]

1. 장애 감지 (Fault Detection)

def detect_failure(heartbeat_monitor):
    """Heartbeat 타임아웃으로 장애 감지"""
    if heartbeat_monitor.failure_count >= THRESHOLD:
        return True
    return False
  • Heartbeat Timeout: 연속 N회 실패 시 장애 판정
  • Health Check: 서비스 포트, 프로세스 상태 확인
  • STONITH (Shoot The Other Node In The Head): 확실한 격리를 위한 강제 전원 차단

2. 장애 확인 (Fault Confirmation)

def confirm_failure(primary_ip):
    """다중 경로로 장애 재확인"""
    # Ethernet Heartbeat
    eth_alive = check_heartbeat_ethernet(primary_ip)

    # Serial Heartbeat (대체 경로)
    serial_alive = check_heartbeat_serial()

    # ICMP Ping
    ping_alive = os.system(f"ping -c 1 {primary_ip}") == 0

    if not eth_alive and not serial_alive and not ping_alive:
        return True  # 확실한 장애
    else:
        return False  # 네트워크 문제일 가능성
  • Split-Brain 방지: 네트워크 단절과 노드 장애 구분
  • 다중 경로 확인: 여러 채널로 재확인

3. 리소스 인수 (Resource Takeover)

#!/bin/bash
# Failover 스크립트 예시

# 1. VIP 인수
ip addr add 192.168.1.100/24 dev eth0
echo "VIP acquired"

# 2. 공유 디스크 마운트
mount /dev/sdb1 /mnt/shared
echo "Shared disk mounted"

# 3. 이전 Primary 격리 (STONITH)
fence_node primary-node
echo "Primary node fenced"

4. 서비스 시작 (Service Startup)

# 4. 애플리케이션 서비스 시작
systemctl start postgresql
systemctl start apache2
echo "Services started"

# 5. 상태 확인
systemctl status postgresql
systemctl status apache2

5. 클라이언트 재연결

# 클라이언트 측 재연결 로직
import time

def connect_with_retry(vip, port, max_retries=5):
    for attempt in range(max_retries):
        try:
            conn = socket.create_connection((vip, port), timeout=5)
            print("Connected successfully")
            return conn
        except Exception as e:
            print(f"Connection failed (attempt {attempt+1}): {e}")
            time.sleep(2)  # Failover 대기

    raise Exception("Connection failed after all retries")

# VIP로 연결 (Failover 시 자동으로 Standby로 연결됨)
conn = connect_with_retry("192.168.1.100", 5432)

HA의 한계

1. External Disk 장애

graph TB
    A["Primary Node"] --> C["Shared Disk<br/>(외부 스토리지)"]
    B["Standby Node"] -.-> C

    C -->|"디스크 장애"| D["데이터 손실"]

    A -->|"Failover"| B
    B -.->|"접근 불가"| C

    D --> E["서비스 불가"]
  • 문제: 공유 디스크 자체가 고장나면 Failover해도 데이터 접근 불가
  • 영향: 단일 장애점(SPOF) 여전히 존재

2. Hang 및 성능 저하 미해결

# 애플리케이션이 Hang 상태
while True:
    # 무한 루프에 빠진 상태
    # 프로세스는 살아있지만 응답 없음
    pass

# Heartbeat는 정상 전송 (프로세스 살아있음)
# → Failover 미발동
# → 서비스 응답 없음 지속
  • 문제: 프로세스는 살아있지만 응답하지 않는 Hang 상태
  • Heartbeat 한계: OS 레벨 Heartbeat는 프로세스 존재만 확인, 애플리케이션 로직 정상 여부 미확인

3. Split-Brain (뇌분할)

graph LR
    A["Primary Node<br/>(VIP: 192.168.1.100)"]
    B["Standby Node"]

    A <-.->|"Heartbeat<br/>네트워크 단절"| B

    B --> C["Standby가<br/>Primary 장애로 오인"]
    C --> D["Standby가<br/>VIP 인수<br/>(VIP: 192.168.1.100)"]

    E["두 노드 모두<br/>같은 VIP 보유"] --> F["데이터 불일치<br/>충돌"]
  • 문제: 네트워크 단절로 양쪽이 모두 Primary로 동작
  • 결과: 데이터 충돌, 서비스 오동작

HA 한계 해결 방안

1. 스토리지 이중화

graph TB
    A["Primary Node"] --> B["Storage 1<br/>(Primary)"]
    A -.-> C["Storage 2<br/>(Replica)"]

    D["Standby Node"] -.-> B
    D --> C

    B <-->|"동기 복제<br/>(DRBD, Sync)"| C

    E["Storage 1 장애"] --> F["Node가<br/>Storage 2로<br/>자동 전환"]

DRBD (Distributed Replicated Block Device)

# DRBD 설정 예시
# /etc/drbd.d/r0.res
resource r0 {
    protocol C;  # 동기식 복제

    on primary-node {
        device /dev/drbd0;
        disk /dev/sdb1;
        address 192.168.1.1:7789;
        meta-disk internal;
    }

    on standby-node {
        device /dev/drbd0;
        disk /dev/sdb1;
        address 192.168.1.2:7789;
        meta-disk internal;
    }
}

# Primary에서 스토리지 장애 시 자동 전환
drbdadm primary r0
mount /dev/drbd0 /mnt/data

2. Application-Level Health Check

# 애플리케이션 레벨 Health Check
class ApplicationHealthCheck:
    def __init__(self):
        self.last_success = time.time()

    def check_health(self):
        """실제 애플리케이션 기능 테스트"""
        try:
            # DB 쿼리 테스트
            db.execute("SELECT 1")

            # API 엔드포인트 테스트
            response = requests.get("http://localhost/health", timeout=5)
            if response.status_code != 200:
                raise Exception("Health check failed")

            # 비즈니스 로직 테스트
            result = process_sample_request()
            if not result:
                raise Exception("Business logic failed")

            self.last_success = time.time()
            return True

        except Exception as e:
            print(f"Health check failed: {e}")
            return False

# Heartbeat 전송 전에 Health Check
if health_checker.check_health():
    send_heartbeat()
else:
    # Health Check 실패 → Heartbeat 전송 중단 → Failover 유도
    pass

3. Split-Brain 방지

Quorum (정족수)

graph TD
    A["3-Node 클러스터"]
    B["Node 1"]
    C["Node 2"]
    D["Node 3"]

    A --> B
    A --> C
    A --> D

    E["네트워크 분할"] --> F["Group A: Node 1, 2<br/>(2/3 = Quorum 확보)"]
    E --> G["Group B: Node 3<br/>(1/3 = Quorum 없음)"]

    F --> H["Group A가<br/>서비스 계속"]
    G --> I["Group B는<br/>자동 Shutdown"]
# Pacemaker Quorum 설정
crm configure property no-quorum-policy=stop

# 3노드 중 과반(2개) 이상만 Active
# 분리된 소수 노드는 자동 중지

Fencing (STONITH)

# STONITH 설정 (전원 차단)
crm configure primitive fence_primary stonith:fence_ipmilan \
    params ipaddr=192.168.1.1 login=admin passwd=secret \
    op monitor interval=60s

# Primary 응답 없으면 강제 전원 차단
# → Standby만 유일한 Active 노드 보장

Tiebreaker (중재자)

graph LR
    A["Primary Node"] <-.->|"Heartbeat 단절"| B["Standby Node"]

    A -->|"Ping"| C["Tiebreaker<br/>(Quorum Device)"]
    B -->|"Ping"| C

    C -->|"Primary 응답 없음"| D["Standby에게<br/>승인"]
    D --> E["Standby가<br/>Primary 승격"]
# Corosync Quorum Device
# 제3의 노드 또는 네트워크 장비가 중재자 역할
pvecm qdevice setup 192.168.1.254

4. H/W + S/W HA 솔루션 병행

통합 HA 아키텍처

graph TB
    subgraph "애플리케이션 계층"
    A1["App Instance 1"] <--> A2["App Instance 2"]
    end

    subgraph "데이터베이스 계층"
    D1["DB Primary"] -->|"Replication"| D2["DB Standby"]
    end

    subgraph "스토리지 계층"
    S1["Storage 1"] <-->|"DRBD"| S2["Storage 2"]
    end

    subgraph "네트워크 계층"
    N1["Switch 1"] <--> N2["Switch 2"]
    end

    subgraph "전원 계층"
    P1["UPS 1"] -.-> P2["UPS 2"]
    end

    A1 --> D1
    A2 --> D2
    D1 --> S1
    D2 --> S2

다층 방어 전략

  1. 하드웨어 HA

    • 이중 전원(Dual Power Supply)
    • RAID 디스크
    • 네트워크 본딩(Bonding)

  2. 소프트웨어 HA

    • 클러스터링 (Pacemaker, Keepalived)
    • 애플리케이션 모니터링
    • 자동 재시작 (systemd, supervisord)

  3. 데이터 HA

    • DB 복제(Replication)
    • 스토리지 미러링(DRBD)
    • 백업 및 복구

  4. 네트워크 HA

    • 이중 네트워크 경로
    • 로드 밸런서 이중화
    • DNS Failover

실전 HA 구축 사례

사례 1: 웹 서비스 HA (Nginx + Keepalived)

# Primary 노드 (192.168.1.1)
# /etc/keepalived/keepalived.conf
vrrp_script check_nginx {
    script "/usr/local/bin/check_nginx.sh"
    interval 2
    weight -20
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100

    track_script {
        check_nginx
    }

    virtual_ipaddress {
        192.168.1.100/24
    }
}

# /usr/local/bin/check_nginx.sh
#!/bin/bash
if systemctl is-active nginx > /dev/null; then
    exit 0
else
    exit 1
fi

사례 2: PostgreSQL HA (Patroni + etcd)

# Patroni 설정
scope: postgres-cluster
name: node1

restapi:
  listen: 192.168.1.1:8008
  connect_address: 192.168.1.1:8008

etcd:
  hosts: 192.168.1.3:2379

bootstrap:
  dcs:
    ttl: 30
    loop_wait: 10
    retry_timeout: 10
    maximum_lag_on_failover: 1048576
    postgresql:
      use_pg_rewind: true

postgresql:
  listen: 0.0.0.0:5432
  connect_address: 192.168.1.1:5432
  data_dir: /var/lib/postgresql/13/main
  pgpass: /tmp/pgpass
  authentication:
    replication:
      username: replicator
      password: secret
    superuser:
      username: postgres
      password: secret
  • 자동 Failover: Leader 노드 장애 시 자동으로 Replica 승격
  • 자동 복구: 이전 Leader 복구 시 자동으로 Replica로 재진입

마무리

HA(High Availability)는 단순한 백업을 넘어 클러스터링, 실시간 동기화, 자동 Failover를 통합한 무중단 서비스 아키텍처입니다. Hot Standby, Mutual Takeover, Concurrent Access 등 다양한 구성 방식을 통해 99.99% 이상의 가용성을 달성할 수 있으며, Heartbeat 메커니즘을 통해 장애를 신속히 감지하고 VIP 인수와 서비스 전환을 자동화합니다. 그러나 공유 스토리지 장애, 애플리케이션 Hang, Split-Brain 같은 한계가 존재하므로, 스토리지 이중화(DRBD), 애플리케이션 레벨 Health Check, Quorum/STONITH를 통한 Split-Brain 방지, 그리고 하드웨어와 소프트웨어 HA 솔루션의 병행 구축이 필수적입니다. 전원, 네트워크, 스토리지, 데이터베이스, 애플리케이션 등 모든 계층에서 중복성을 확보하고 자동 장애 조치 메커니즘을 구축함으로써 진정한 무중단 서비스를 실현할 수 있습니다.

Keywords

HA, High Availability, 고가용성, Clustering, 클러스터링, Failover, 장애 조치, Hot Standby, Keep Alive, 무중단

728x90
반응형

'IT Professional Engineering > CA.OS' 카테고리의 다른 글

CPU 스케줄링: 한정된 자원을 공정하게 나누는 스케줄링 기법  (0) 2025.12.30
RAID (Redundant Array of Inexpensive Disks): 데이터 안정성과 성능을 동시에 높이는 디스크 어레이 기술  (0) 2025.12.30
WDT (WatchDog Timer): 시스템 자동 복구의 핵심 메커니즘  (0) 2025.12.28
FTS (Fault Tolerant System): 무중단 시스템을 위한 결함 허용 기술  (0) 2025.12.28
OpenMP: 공유 메모리 병렬 프로그래밍의 표준  (0) 2025.12.28

+ Recent posts

티스토리툴바