반응형
Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
Tags
- 인프라
- os
- 네트워크
- 쿠버네티스
- 클라우드
- swift 클로저
- docker
- centOS
- ios
- NGINX
- 도커 이미지
- 데브옵스
- centOS7
- 운영체제
- linux
- 도커 컨테이너
- 도커 명령어
- 컨테이너
- 리눅스
- boj
- Python
- devops
- 프로세스
- C++
- Swift
- 도커
- k8s
- kubernetes
- 부스트코스
- AWS
Archives
- Today
- Total
귀염둥이의 메모
HA (High-Availability) 클러스터, Active-Active, Active-Stand by 본문
반응형
고가용성(High-Availability)
- 장애 극복(Fail Over)의 목적
- 서버 이중화 구성
- 서버 한 개가 죽어도 서비스가 되어야 함
Active-Active (A-A)
- L4 스위치 등의 로드밸런싱을 통해서 여러 개의 서버로 나누어서 처리한다
- 여러 개의 서버가 동시에 동작하기 때문에, 한대가 다운되어도 남은 서버가 처리 가능
- 다운 타임이 존재하지 않는다
Active-Stand by (A-S)
- Active 상태의 서버, Stand by 서버
- S가 A에게 계속해서 keep-alive를 통해 상태를 확인
- A가 장애시 서비스 장애를 즉시 인지하여 S로 서비스를 이전
- 장애 발생 시 서비스를 이전하여 운영하는 형태
- 성능적 향상은 거의 ❌
- S가 놀고 있는 상태 -> 리소스 측면에서 낭비
Stand by 유형
Hot Stand by | S를 가동 후 즉시 이용가능하게 하는 구성 |
Warm Stand by | S를 가동 후 이용 가능하게 하기 위해 준비가 필요한 구성 |
Cold Stand by | S를 정지시켜 두는 구성 |
이중화 솔루션은 장애 발생 시 Fail Over 하여 서비스 다운 타임을 최소화하고, 서비스를 자동으로 복구시키는 것이 목적이다.
HA 클러스터가 제대로 구축되지 않으면 장애 탐지를 제대로 못하거나, 자동으로 복구되지 않는 현상이 발생해 서비스 다운 타임이 발생할 수 있다. 이러한 상황에 수동 복구 조치를 하지 못하면, 단일 서버 환경보다 훨씬 긴 다운타임이 발생할 수 있다.
HA 솔루션은 비용이 비싸고, 관리 포인트가 늘어나기 때문에 정말 필요한 시스템인지 고려해봐야 한다.../
반응형
'Infra & Devops' 카테고리의 다른 글
베어메탈 서버(Bare-metal server)란? (0) | 2021.09.16 |
---|---|
호스트 가상화 vs 하이퍼바이저 가상화 vs 컨테이너 가상화 (0) | 2021.09.14 |
HPC (High Performance Computing) 클러스터 (0) | 2021.09.13 |
스케일 업(Scale up), 스케일 아웃(Scale out) (0) | 2021.08.07 |
클라우드 컴퓨팅 5가지 특성 (0) | 2021.08.07 |
Comments