-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Lim
committed
Feb 29, 2024
1 parent
a44870e
commit 38e6103
Showing
1 changed file
with
55 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,55 @@ | ||
# 11. 이중화 기술 | ||
|
||
- 끊김없는 안정적인 서비스를 제공하기 위해서는 네트워크, 서버, 스토리지와 같은 인프라뿐만 아니라 애플리케이션도 이중화(다중화) 기술을 적용해야 함 | ||
- 이중화를 위해 동일한 역할을 하는 인프라를 두 대 이상 구성하거나 하나의 장비 내에 네트워크 인터페이스 카드와 같은 내부 구성요소를 다중으로 구성하기도 하고 동일한 역할을 하는 애플리케이션을 동시에 여러 개 띄워 서비스를 제공하기도 함 | ||
- 이런 이중화 기술은 서비스 가용성을 높여주고 가용량을 확장해주기 때문에 안정적인 서비스 제공을 위해 이중화는 필수 요소 | ||
|
||
## 11.1 이중화 기술 개요 | ||
|
||
- 서비스를 제공하기 위한 인프라의 주요 목표 중 하나는 적시에 서비스를 출시하기 위해 인프라를 신속히 제공하는 것 | ||
- 소위 타임 투 마켓을 위한 인프라의 민첩성 | ||
- 하지만 인프라의 더 본질적인 목표는 더 가용성 높은 서비스에 필요한 인프라를 안정적으로 제공하는 것 | ||
- 인프라를 설계할 때 가용성, 연속성, 안정성 등의 항목을 보는 것도 인프라를 안정적으로 제공하는 데 필요한 주요 지표 | ||
- 따라서 인프라를 설계할 때, 단일 접점의 장애가 전체 서비스에 영향을 미치지 않도록 SPoF(단일 장애점)를 만들지 않아야 함 | ||
|
||
### 11.1.2 이중화의 목적 | ||
|
||
- 인프라를 구성하는 각 요소가 복수 개 이상으로 인프라를 구성해 특정 인프라에 문제가 발생하더라도 이중화된 다른 인프라를 통해 서비스가 지속되도록 해줌 | ||
- 서비스에 필요한 출발 지점부터 끝 지점까지(End-to-End) 속하는 모든 인프라에 이중화 구성을 고려해야 함 | ||
- 서비스를 위한 물리적 또는 가상 머신 서버, 서버와 네트워크 장비를 구성해주는 인터페이스, 서버에 연결된 스위치, 다수 서버의 부하 분산을 위한 L4/L7 스위치, 방화벽, 인터넷 게이트웨이, 인터넷 회선 등 모든 요소가 이중화 구성이 필요한 항목 | ||
- 심지어 이 모든 요소가 속한 데이터 센터 자체도 이중화가 필요해 DR 센터나 액티브-액티브 데이터 센터를 구축 | ||
- 인프라가 이중화되어 있다면 특정 지점에 문제가 발생하더라도 이중화된 인프라를 이용해 서비스 할 수 있음 | ||
- 특정 인프라의 장애 상황에서도 서비스는 가능하므로 서비스의 연속성이 보장되고 이것을 폴트 톨로런스(장애 허용, 결함 감내)가 보장된다고 말하기도 함 | ||
|
||
## 11.2 LACP | ||
|
||
- 1990년대 중반까지는 각 벤더별로 장비 간 대역폭을 늘리기 위해 독자적인 방법으로 구현했지만 벤더 독자적인 방법으로는 다른 장비끼리 연결할 때 호환성 문제가 발생해 이 문제를 해결하기 위해 상호호환 가능한 연결 계층(Link Layer) 표준화를 시작 | ||
- 이 표준화가 LACP (Link Aggregation Control Protocol) | ||
- 링크 애그리게이션의 목적은 대역폭 확장을 통한 두가지를 제공하는 것 | ||
- 링크 사용률 향상(Improved Utilization of Available Link) | ||
- 향상된 장애 회복(Improved Resilience) | ||
- LACP를 사용하면 두 개 이상의 물리 인터페이스로 구성된 논리 인터페이스를 이용해 모든 물리 인터페이스를 액티브 상태로 사용 | ||
- 이것을 통해 스위치와 스위치 또는 스위치와 서버 간 네트워크 대역폭이 물리 인터페이스 수량만큼 확장 | ||
- 또한, 논리 인터페이스를 구성하는 물리 인터페이스 중 일부에서 문제가 발생하더라도 나머지 물리 인터페이스로 서비스를 유지 | ||
- 액티브-스탠바이가 아니라 액티브-액티브 상태이므로 인터페이스 절체로 인한 지연 없이 서비스를 제공 | ||
|
||
## 11.3 서버의 네트워크 이중화 설정 | ||
|
||
- 인터페이스 이중화에 사용되는 기술 명칭은 윈도우와 리눅스에 따라 다음과 같이 다르게 부름 | ||
- 윈도우: 팀/team/티밍/teaming | ||
- 리눅스: 본드/bond/본딩/bonding | ||
|
||
### 11.3.1 리눅스 본딩 모드 | ||
|
||
- 리눅스 본딩 모드는 모드 0~4까지 있음 | ||
- 실무에서는 이중화를 구성할 때, 액티브-스탠바이로는 모드 1을 사용하고 액티브-액티브로는 모드 4를 사용하며 나머지 모드는 보통 잘 사용하지 않음 | ||
|
||
#### 11.3.1.1 모드1: 액티브- 스탠바이 | ||
|
||
- 인터페이스를 액티브-스탠바이로 구성할 때는 모드 1을 사용 | ||
- 평소 액티브 인터페이스로만 패킷이 전달되지만 액티브가 죽으면 스탠바이 인터페이스가 자동으로 활성화되어 패킷을 전송함 | ||
- 원래의 액티브 인터페이스가 다시 살아나면 설정에 따라 액티브 인터페이스가 자동으로 다시 활성화(Auto Fail Back)되거나 수동으로 넘기기 전까지 스탠바이 인터페이스가 활성화 상태를 유지 | ||
|
||
#### 11.3.1.2 모드4: LACP | ||
|
||
- 표준 프로토콜인 LACP를 이용해서 인터페이스를 액티브-액티브 방식으로 사용하고 싶을 때는 모드 4로 설정 |