Fault Tolerant, High Availability

I. 결함 발생시 시스템 정지 없이 연속적 기능을 보장하는 시스템, FTS의 개요
    가. FTS(Fault Tolerant System)의 정의

  • 하드웨어 또는 소프트웨어의 결함, 오동작, 오류 등이 발생하더라도 설계상에 명시된 기능을 지속적으로 수행할 수 있는 시스템
  • 시스템의 가용성, 신뢰성, 안전성 보장

 

    나. FTS의 필요성

  • 데이터의 무결성과 일관성 유지
  • 시스템 가동률 극대화, 데이터 안전 및 보존 유지
  • 시스템고장 등으로 인한 경제, 인명 손실을 막고 사회적혼란에 대한 대처 방안 필요
  • 트랜잭션 처리, 실시간 제어, 인간의 안전에 관련된 응용 분야에서 그 중요성이 증대

 

Ⅱ. FTS의 개념도
    가. 결함허용시스템의 개념도
 

  • PLC(Programmable Logic Controller)와 Work-stations과 같은 클라이언트 레이어 에서도 높은 고 가용성이 요구되는 경우 Standby 형태로 시스템 구성
  • 서버의 경우 Active Unix Application Server의 모든 기능을 수행할 수 있는 Standby Unix Application Server 배치. DB의 경우 Replication을 통해 복제화

 

Ⅲ. 가용성 저해 원인과 결함 해결 단계 및 주요구비 기능
    가. 가용성 저해 원인

구분

내용

해결방안

응용 시스템

-부적절한 Source code

-비 효율적 분기 logic

-잘못된 sql

-Resource 미 반환

-표준 개발프로세스 정립 및 개발자 역량 강화

-단위 테스트, 모듈 테스트

DBMS

-DB performance 튜닝 부족

-Dead Lock, Latch 경합

-주기적인 모니터링 기반 DBMS

최적화

-DB 성능진단 및 튜닝

H/W

-물리적 H/W resource 부족, Fault

-(firmware, patch)유지보수 미흡

-시스템 중요도에 따른 투자 검토

N/W

-대량트래픽에 의한 N/W Resource초과,

-DDOS, 해킹 등의 보안 침해

-물리적 Fault

-보안 솔루션

-계획적인 N/W자원 활용. QoS 도입

-이중화

 

 

    나. 결함의 해결 단계

단계

내용

결함감지

(Fault Detection)

- 하드웨어로 구성된 비교기(Compare Logic)를 통하여 수행됨

- 시스템 내에서 Fault가 발생되면 해당 모듈 또는 시스템은 Fault 상태로 들어가게 되고, OS는 각 모든 하드웨어 모듈들의 상태를 분석하여 어느 모듈이 Fault를 유발시켰는가를 분석하여 알아냄

결함진단

(Fault Diagnosis)

- Fault가 일시적(Transient)인 것인지 영구(Hard)적인 것인지 판단하여 영구적인 경우 해당 모듈을 시스템 구성에서 제거

결함통제

(Fault Isolation)

- 결함으로 인한 오류 파급 차단

결합복구

(Fault Recovery)

- Fault를 유발한 모듈을 시스템에서 제거하여 시스템을 재구성

 

 

    다. 결합허용 시스템의 주요 구비기능

기능

상세내용

중복성

- 시스템의 구성요소 백업, 이중성으로 결함 발생시 대신 동작

- 복구 작업의 지원

결함검출

- 결함 복구를 위한 결함발생 인식

결함위치확인

- 결함의 내용과 위치검출

결함격리

- 결함 발생부분의 격리

재구성

- 결함 발생시에도 정상적 작동 보장

보수

- 고장 부분을 정상 작동에 방해 없이 교체 및 보수

회복

- 교체 및 보수 후 시스템의 동작을 방해 없이 추가

데이터보존

- 정보의 손상 및 유실 방지

 
 

Ⅳ. 결함허용 기법
    가. Hardware 측면

기법

상세내용

Checkpoint 기법

한 프로세스를 주 프로세서와 보조 프로세서에 중복 할당(중복성의 원리)

Hot standby 방식

두 개의 프로세서를 동기 상태에서 프로세스 수행

Triple modular

Redundancy

3개 이상의 프로세서가 같은 입력에 대하여 동일한 연산 수행

RAID

디스크 미러링, 패리티 비트 분산 저장을 통해 결함 허용

 
 

    나. Database 측면

기법

상세내용

Rollback (Undo)

트랜잭션 작업 철회

Log File

Commit안된 작업을 로그 파일로 회복

Check Point

중간 검사시점을 두어 결함 발견시점 이후만 회복

Shadow Paging

트랜잭션 실행 동안 수행 페이지 테이블과 그림자 페이지 테이블을 지속 유지

 
 

    다. 소프트웨어 측면

기법

상세내용

Check Pointing

- S/W 수행 중에 검사시점을 설정하여 오류발생이 발견되면 발생  이전의 검사시점으로 되돌아가서 재 수행

Recovery Block

- 재 수행 (Rollback & Retry)에 근거

- 검사시점에서 오류가 발견되면 지정된 이전 검사점으로 되돌아가서 같은 기능을 가진 다른S/W모듈을 수행

Conversation

- 재 수행(Rollback & Retry)에 근거한 Recovery Block의 확장형

- 복수의 프로세서 정보를 교환하는 프로세서들 간에 적용 가능한 기법

Distributed

Recovery Block

- Recovery Block 기법을 분산환경으로 확장

- H/W 결함과 S/W 결함을 동일한 방법으로 대처

N Self-checking

Programming

- 두 개 이상의 Self-checking 컴포넌트가 수행되면서 하나는 주어진 기능을 수행하고 다른 컴포넌트는 대기상태

N version

Programming

- H/W 결함허용 기법의 Triple Modular Redundancy와 유사

- N개의 독립적인 S/W 모듈의 수행결과를 비교하여 다수의 수행  결과를 채택

 

    라. 데이터 측면

기법

내용

Parity Code

2진 정보 내의 “1’의 개수를 홀수 또는 짝수로 규정하여 결함 감지

M of N Code

N bit의 정보 길이에서 “1”의 개수가 반드시 M 개가 되게 하여 결함 감지

Checksum

한 블록의 정보내용 합을 추가

Berger Code

한 정보의 “1”의 개수를 2진 정보로 추가

Hamming Error

Correcting Code

결함 감지 및 단일 결함의 교정까지 수행하는 코드 기법

 

Ⅴ. FTS 설계 고려 사항과 활용분야 및 전망
    가. 결함허용시스템 설계 고려사항

  • 처리방식에 따라 하드웨어 구조와 적용할 기법이 달라짐
  • 결함허용 정도에 따라 적용 기법과 소요 자원이 달라짐(일반 응용분야는 단순 결함감지만으로 가능, 고신뢰도 분야는 신속한 결함값 및 복구까지 필요)
  • 분야별 결함허용 기법을 조화롭게 활용하여 FTS 구성함

    나. FTS 활용분야

구분

내용

고 신뢰도

핵반응 제어, 우주비행 제어 등

장기 안정성

무인 우주항공 제어 등

높은 가용성

전화교환망, 항공예약시스템 등

  • 하드웨어 기법 중심, Mirrored Memory, Mirrored Disk, On-line Repairing 기법 사용

    다. FTS 향후 전망

  • IT 시스템 거대화, 복잡화에 따라 적용대상 증가 전망
  • 결함 감지에서 복구/회복까지 완벽하게 만족시키는 각종 기법들 개발
  • Ubiquitous, Green IT 2.0 확대 등을 통해 자동화된 생활 환경

Ⅵ. 서비스 연속성 확보를 위한 HA의 개요
    가. HA(High Availability) 의 정의

  • 두 대 이상의 시스템을 하나의 클러스터로 묶어서 한 시스템의 장애시 클러스터내의 다른 시스템이 신속하게 서비스를 Failover해 최소한의 서비스 중단을 이루려는 메카니즘

 

    나. HA의 필요성

  • 서비스 다운타임을 최소화함으로써 가용성을 극대화
  • 고가용성으로 기업의 비즈니스 연속성(Business Continuity) 확보
  • 기업의 신뢰도 및 이미지 향상

 

    다. HA를 위한 요구사항

  • RAS(Reliability, Availability, Serviceability)
  • Dynamic Configuration and Upgrade)
  • Disaster Recovery
  • Single System Image
  • 통합운영관리, 저렴한 소유비용(TCO, Total Cost of Ownership)

 

Ⅶ. HA 구성도
    가. HA 구성도
 

  • HA 구성에 참여하는 각 시스템은 2개 이상의 네트워크 카드를 가지면서 네트워크를 통해 상호간의 장애 및 생사 여부를 감시
  • Standby Network은 서비스 네트워크 장애시 백업용으로 사용되고, Private Network 은 HA 에 참여하는 시스템들만 통신하는 전용 Network 임
  • 외장 디스크는 가동 및 개발 시스템에서 공유할 수 있어야 하며, Concurrent Access 또는 순차적인 Access 방식에 따라 HA 가 다르게 구성

 

    나. HA 구성 유형

구 분

설 명

Hot Standby

- 가장 단순하면서 많이 사용되는 유형

- 가동 시스템과 평상시 대기 상태 또는 개발 시스템으로 운영되는 백업 시스템으로 구성

- 외장 디스크는 가동 시스템에서만 접근 가능하고, 장애 시에만 백업 시스템에서 접근 가능함

Mutual Takeover

- 2개 시스템이 각각의 고유한 가동 업무 서비스를 수행하다가 한 서버에 장애가 발생하면 상대 시스템의 자원을 Failover 하여 동시에 2개의 업무를 수행하는 방식

- 장애 발생 시 Failover 에 대비해 각 시스템 2개의 업무를 동시에 서비스할 수 있는 시스템 용량을 갖추도록 고려해야 함

- 외장 디스크는 해당 시스템에서만 접근 가능함

Concurrent Access

- 여러 개의 시스템이 동시에 업무를 나누어 병렬 처리하는 방식으로 HA 에 참여하는 시스템 전체가 Active 한 상태로 업무를 수행함

- 한 시스템에 장애가 발생하여도 다른 시스템으로 Failover 하지 않고 가용성을 보장함

 

Ⅷ. HA 상세 구현방식
    가. Hot Standby

  • 평상시 백업시스템을 구성하여 대기상태를 유지하다가 장애 발생시 자원을 Take-over

 
    나. Mutual take-over

  • 각 서버가 별개의 서비스 수행중인 상태에서 특정 서비스에 문제시 해당 서비스를 타 서버로 Take-over

 
    다. Concurrent Access

  • 여러 시스템이 동일 업무를 동시에 병렬로 처리하는 방식, 한 시스템 장애 시에 타 시스템으로 서비스를 지속

Ⅸ. HA 동작 방식 및 Fault Tolerant System 과 비교
    가. HA 동작 방식

장애 상황

HA 동작 방식

시스템 전체

장애 시

- 한 시스템으로부터 keep alive packet이 오지 않는 경우 백업 시스템은 상대 시스템이 Down 되었다고 판단하고 이미 정의된 자원(Volume Group, Filesystems, IP Address,Application)을 Failover

- Failover 순서 : 미리정의된 Scripts에의해Network 자원 => Disk 자원 => Application 자원 순서로 진행 됨

Network Adapter

장애 시

- 가동시스템 내의 Service Adapter 장애 시 : 시스템에 Service adapter 와 Standby adapter를 설치 구성한 경우, Service adapter에 장애가 발생하면 Standby adapter가 Service adapter의 IP Address를 Faileover

- 가동 시스템내의전체N/W Adapter 장애 시: 백업 시스템의 Standby Adapter로가동 시스템의 Service IP Address가 Failover됨.

TCP/IP Network 장애 시

- Network 전체 장애가 발생하는 경우에는 특별한 동작을 하지 않는다

- N/W 전체 장애시에는 백업 시스템으로 Failover해도 동일한 N/W 문제가 존재함

 

 


    나. HA와 Fault Tolerant System과 비교

구분

FTS

HA

Failover Time

0초

30 ~ 300초

동시성 유지보수

필요

불필요

시스템 비용

10 ~ 20배

2배 이상

어플리케이션

제한적

대부분 범용제품

운영체제

전용 OS

범용 OS

하드웨어

전용 하드웨어

범용 하드웨어

 

Ⅹ. HA의 한계점 및 구축 시 고려사항
    가. HA 한계점

  •  External Disk 자체장애발생 시 HA Solution으로 해결 못함
  • 장애 발생으로시 스템이 Down 되지 않는 경우자동 Failover가 되지 않음
  • 시스템성능이 저하되는 경우에 자동감지가 불능
  • DB 및 Application 이 Down되는 경우에는 일반적으로 Failover하지 않음
  • DB 및 Application 자체 Bug일 경우 Failover가 의미 없음
  • HA구성에 따른 정보교환으로 시스템의 안정성, 보안성, 성능에 Overhead가 존재함


    나. HA 구축 시 고려사항

  • HA 구성 방식 및 대상 서버결정
  • 백업 서버 Capacity
  • HA 대상 시스템들에 대한 OS 자원 및 사용자 자원 동기화
  • 보호될 자원 결정 및 자원 동기화
  • External Disk의 보호방안(2중화여부)

댓글