네트워크 인프라 (5) 네트워크 인프라의 가용성 및 이중화

 

 

1. 가용성

 

 

가용성은 서버와 네트워크 프로그램 등의 정보 시스템이 정상적으로 사용 가능한 정도를 말한다.

서비스를 끊임 없이 오래 서비스할 수 있을 경우 가용성이 높은 시스템이라고 하며, 이를 고가용성이라 표현한다.

 

고가용성을 만족시키기위한 방법들은 다음과 같다.

 

1. 컴포넌트 이중화

 

(1) 이유

- 컴포넌트에 고장, 장애가 발생해도 복구할 수 있어야 한다.

- 애초에 고장, 장애에 의한 정지가 최소한으로 발생해야 한다.(MTBF, Mean Time Between Failur, 평균 무고장 시간)

(2) H/W계층의 경우

: 전원, 네트워크, 디스크를 이중화할 수 있다. 

(3) 시스템 계층

: 특정 서버의 처리가 중단 되어도 다른 서버에서 지속적으로 처리하게 할 수 있다.

(4) 물리적 위치 계층

: 시스템을 서로 다른 위치(데이터 센터 및 클라우드)에서 운영하는 이중화로 대규모 장애 및 재해에도 시스템을 유지할 수 있다.

(5) 결론

: H/W보다 시스템 이중화가 효과적이며 시스템 이중화보다 물리적 이중화가 효과적이다. (비용과 가용성은 비례한다.)

 

2. 컴포넌트 감시

- 장애가 발생한 것을 빠르게 검출할 수 있어야 한다.

 

3. 데이터 백업

- 고장, 장애가 발생해도 데이터가 보호되어야 한다.

 

 

 

 

 

 

2. 이중화

 

 

기능을 병렬로 나열해 하나의 기능에 장애가 발생해도 다른 것을 이용해서 서비스를 계속할 수 있어야 한다.

이중화의 핵심 역할은 다음과 같다.

 

(1) 부하 분산 : 적절하게 부하를 분산시켜야 한다.

(2) 내부적 생존 감시 : 정기적으로 감시하여 빠르게 장애를 검출해야 한다.

(3) 마스터 결정

(4) 페일오버 : 마스터에 장애 발생 시 신속하게 역할을 위임해야 한다.

 

 

 

2-1. 서버 내 이중화의 경우

 

 

(1) 전원, 장치 등의 이중화

: 전원, 팬 등의 장치가 이중화되어 하나가 망가져도 정상적으로 가동할 수 있다.

서버 랙에 전원 포트가 이중화되어 각각 따로 접속한다.

 

(2) 네트워크 인터페이스 이중화

: PCI 슬롯에 장착하는 네트워크 카드도 이중화하여 여러개의 복수 포트로 네트워크 카드 장애에 대비한다.

(평상 시에는 N개만 사용하고 나머지 N개는 스탠바이  상태로 대기한다.)

 

(3) 장애 발생 시

- 기본적으로는 액티브 - 스탠바이로 구성되어 액티브에 문제가 발생하면 스탠바이로 FailOver한다.

- Lnux의 경우

> MII 감시 : 인터페이스의 동작만 감시한다. 직접 접속된 스위치만 확인 가능하다는 단점이 있으나 불필요한 패킷 발송으로 인한 트래픽이 발생하지 않기 때문에 주로 이용된다.

> ARP 감시 : 특정 IP로 요청을 지속적으로 보내서 응답 유무로 판단한다.

 

 

2-2. 저장소 이중화의 경우

 

 

(1) HDD 이중화

: HDD는 내구성이 떨어지기 때문에 저장소 이중화의 대상은 대개 HDD이다.

Storage Area Network라는 네트워크를 구축할 수 있으나 비용 문제로 거의 사용되지 않는다.

현재 주로 사용되는 방법은 TCP/IP 프로토콜상에 네트워크를 구축하는 것이다.

 

(2) 저장소 내부의 구조와 RAID

-  저장소의 컨트롤러가 저장소의 입출력을 제어한다.

-  HDD는 엔클로져를 이용하여 확장성이 높으며, 엔클로저에 접근하는 엑세스를 이중화한다.

-  여러 HDD를 gruping하여 논리적인 HDD로 인식시키는 것을 RAID라고 한다.

> 논리적 HDD : Logical Unit(LU) OS는 LU를 인식한다.

> 물리적 HDD

 

(3) RAID를 사용하는 이유

- 안정성 확보

: HDD에 장애가 발생해도 데이터가 손실되지 않도록 데이터 기록을 이중화할 수 있다.

- 성능 향상

: 컨트롤러가 미리 정해놓은 크기로 I/O를 분할하여 복수 HDD를 병렬 I/O처리할 수 있다. (Stripe)

- 용량 확장

: 논리 HDD는 하드웨어의 물리 한계를 넘어 자유롭게 용량을 결정할 수 있다.

 

(4) RAID의 종류

- RAID1 

: 주 디스크 용량의 두 배 이상을 준비하여 백업용 디스크를 운용한다.

속도 저하가 없으나 용량이 2배 이상 필요하다.

- RAID5

: 모든 디스크에 균등하게 데이터를 striping하여 저장하고, 패리티 정보를 함께 저장해 드라이버 중 일부 손상 시 복구한다.

추가적인 용량이 필요하지 않으나(최소한의 조건은 존재한다.) 패리티 체크로 인해 속도가 느리다.

- RAID10

: 데이터를 Mirroring하고 Striping까지 한다.

가장 안정적이지만 비용이 가장 증가한다. 

 

(5) 장애 발생 시

- RAID10의 경우

: RAID 구성에 포함된 데이터는 망가지지 않으나 이중화 구조가 망가진다.

따라서 핫 스페어 디스크를 준비해놓고, 장애 발생 시 핫 스페어 디스크가 RAID에 포함된다.

-> 미러링이 I/O를 기록한다.

-> 이중화 회복을 위해 핫 스페어 디스크에 데이터를 복사한다.(Rebuild)

> HDD를 교환한 후에 핫 스페어로부터 데이터를 복구하는 경우도 있다.(Copy-back)

- 단, 핫 스페어 디스크도 고갈되고 HDD 파손 시 데이터 손실이 발생한다.

 

(6) 버스 이중화의 경우

> 서버와 저장소 사이의 버스를 이중화할 수 있다.

-> 사용자가 파일을 기록한다.

-> 파일 시스템에서 고정 길이 블록으로 처리된다.

-> 파일 시스템 캐시를 디스크에 푸시할 때 장치 관리자의 multipath기능이 블록I/O를 현재 디스크 I/O버스에 할당한다.(2중화)

-> I/O스케줄러에 의해 요청 큐에 저장된다.

-> HBA 드라이버가 큐 순서에 따라 HBA를 사용하여 드라이버에 기록한다.

-> 장애 검출 시 DM-Multipath를 통해 버스를 Fail-over한다.

(HBA : 서버와 다른 장비의 통신을 위한 카드)

 

 

 

2-3. 웹 서버 이중화의 경우

 

 

(1) Process/ Thread 이중화

: 가장 보편적인 아파치 웹 서버의 경우 프로세스(httpd)를 여러개 준비하여 대응한다.

대응 프로세스의 최소/최대값을 같게 하여 스레드 가동/정지의 오버헤드를 줄이는 것이 좋다.

 

(2) 장애 발생 시

: 503 Service Unvailable와 함께 요청을 큐에 보관하지 않고 바로 반환한다.

 

(3) 이중화 방법 : Round Robin

- DNS에 하나의 호스트 이름에 여러 IP주소를 등록한다. (DNS Round Robin)

- 단 DNS가 서버 상태를 감시하는 것은 아니기 때문에 서버가 정지되어도 원래 반환하던 Ip 주소를 반환하므로 가용성은 좋지 않다.

- 세션 상태도 파악하지 않으므로 동일 서버에 지속적으로 접속해야하는 경우에도 부족합하다.

 

(4) 이중화 방법 : Road Balancer (부하 분산 장치)

: 라운드 로빈보다 고도화된 이중화 방식으로, 쿠키에 웹 서버를 저장하면 로드 밸런서가 쿠키를 읽어 해당 웹 서버에 지속적으로 연결해준다.

또한 Persistence 기능으로 세션 테이블을 만들어 동일 세션을 유지하도록 한다.

 

(5) 로드 밸런서의 작동 로직

> 클라이언트가 ip주소로 request를 전송한다.

-> DNS가 여러 ip 주소를 반환한다.

-> 클라이언트가 해당 Ip 주소로 서버에 요청한다.

-> 로드 밸런서가 쿠키를 식별하여 특정 웹 서버에 연결해준다.

 

(6) 주의사항

- 프록시 서버를 경유할 경우 로드 밸런서 입장에서는 프록시 서버의 IP 주소 자체가 클라이언트 IP 주소로 인식할 수 있다. 이 경우 특정 웹 서버로만 요청이 몰린다.

- 쿠키 사용하는 경우 AP 서버에서 해당 쿠키를 덮어쓰지 않도록 주의해야 한다.

- URL 구조의 Persistence를 사용할 경우 부정 접속에 대한 대책이 필요하다.

 

(7) 로드 밸런서의 할당 알고리즘

- 라운드 로빈(Roind Robin) : 서버 Ip 주소의 순서대로 요청을 할당한다.

- 최소 연결(Least Connection) : 현재 활성 세션 수보다 세션 수가 가장 적은 서버 IP 주소에 요청을 할당한다.

- 응답 시간 : 서버 CPU 사용률 및 응답 시간을 고려하여 부하가 적은 서버의 IP 주소에 요청을 할당한다.

*알고리즘이 복잡할 수록 부하가 증가한다.

 

(8) 장애 발생 시 (로드 배런서의 경우)

> 로드 밸런서가 웹 서버 가동 상태를 감지한다.

-> 클라이언트 요청을 동적으로 달느 서버에 할당한다.(Fail-Over)

 

 

 

 

 

 

 

 

2-4. AP 서버 이중화의 경우

 

 

(1) AP 서버의 이중화

- 로드 밸런서를 이용한다.

- 세션 정보 및 웹 서버 요청을 이중화한다.

 

(2) 장애 극복 로직

> 장애로 인해 응답이 없을 시 쿠키 정보로 판단하여 해당 AP 서버로 리다이렉션 시킨다. (웹서버)

-> 보조 세션이 승격하여 기본 세션이 되어 리다이렉션 요청을 받는다. (AP서버)

-> 장애가 발생한 서버에서 세션 정보를 복사한다. (웹서버)

-> 클라이언트에게 리다이렉션 반환 시 정보가 저장되어있는 서버 정보를 쿠키에 추가해서 반환한다. (웹서버)

* 세션 정보 복사 과정에서 부하가 발생한다.

 

(3) DB서버와의 연결 이중화 경우

: DB 서버 연결 시 사용할 Connection을 여러개 생성해놓는다. (Connection Pooling)

 

(4) DB서버와의 연결 장애 시

: 연결이 모두 사용 중이라면 큐잉 상태가 되어 대기하고, 지정 시간이 초과하면 에러를 반환환다.

이 또한 웹서버 이중화와 마찬가지로 최소값과 최대값을 동일하게 설정하여 오버헤드를 줄이는 것이 좋다.

 

 

 

 

 

 

2-5. DB 서버 이중화의 경우

 

 

(1) Active - Standby 이중화

- 액티브 - 스탠바이형의 Cluster로 구성한다.

- DB의 고가용성 (HA, High Availability)을 위해 필수적

- 하트비트 혹은 투표장치로 서로를 감시한다.

 

(2) 장애 발생 : 투표 장치의 경우

> 액티브가 장애를 감지하고 서비스 정지 혹은 OS를 재시작한다.

-> 공유 디스크 내부의 투표 장치를 통해 스탠바이가 상태를 감지한다.

-> 스탠바이가 감지하고 액티브로 변홚나다.

 

(3) 장애 발생 : 하트비트의 경우

> 하트비트로 상호 상태를 확인하다가 인식할 수 없게 되면 클러스터 소프트웨어가 페일오버 실시 여부를판단할 수 없다.(Split Brain)

-> 이 경우 투표 장치에 먼저 기록한 쪽이 정상 작동으로판단하고 액티브로 전환한다.

-> 기록에 실패한 쪽은 즉시 재시동 혹은 정지한다.

* 단, 클러스터 소프트웨어가 오작동할 수 있기 때문에 중요한 데이터는 여전히 백업해야 한다.

 

(5) Active-StandBy를 사용하는 경우

- 병렬로 서비스 실행이 불가능하고 데이터 일관성이 중요할 경우

 

(6) Active - Active 이중화

- Shared Noting (Oracle, Mysql Cluster) : 각 노드별로 따로 디스크를 가지고 있어서 데이터가 분산된다.

> 노드만 추가함으로써 확장이 가능하다.

> 그러나 데이터 베이스 자체를 재배치해야해서 확장성이 좋지 않다.

> 갱신 시 분산 위치를 검토해야해서 갱신 처리가 느리다.

 

- Shared Everything (Orcal Real Application Cluster) : 디스크 데이터를 모든 노드가 공유한다. 장애 발생 시 다른 노드가 처리.

> 다른 노드에 있는 데이터와 일치성을 확장해야해서 확장이 쉽지는 않다.

> 모든 노드에서 같은 데이터에 엑세스할 경우 배타적 제어 혹은 데이터 경합을 하기 때문에 속도가 저하된다.

 

- 결론 : 가용성은 Shared Everything이 높으며 안전성은 Shared Noting이 더 뛰어나다.

 

 

 

 

 

 

 

2-6. 네트워크 장비 이중화의 경우

 

 

(1) L2 스위치 이중화

- 서버간 연결 스위치를 두 곳에 연결하여 하나는 스탠바이 상태로 대기한다.

- 스위치를 서로 Cascade하여 서로 다른 스위치간 통신을 시키고, 신호가 없으면 즉시 대체한다.

 

(2) 포트 이중화

- 여러 포트를 합쳐서 본딩하여 양 쪽 포트를 모두 이용하다가 장애 발생 시 나머지로만 해결한다.

- 부수적인 효과로 대역폭이 증가한다.

단, 네트워크 출입 회선도 대역폭을 맞춰주지 않으면 의미는 없다.

 

(3) L3 스위치 이중화

- Active-StandBy 구조로 평상시에는 한 쪽만 사용하고 폴링 체크한다.(하트비트)

- VRRP(Virtual Router Redundancy Protocol)의 경우 각 라우터에 우선도를 지정하여 장애 발생 시 해당 우선도에 맞춰 액티브 지정.

- VRRP는 모든 포트를 감시하므로 전용 링크가 필요하지 않다.

 

(4) 논리적 토폴로지

- L2, L3 스위치를 조합할 경우 경로를 두 개 만들어 논리적인 포트는 하나만 사용한다.

- 장애 시에는 절단한 경로(Blocking Port)로 이동한다.

- RSTP(Rapid-STP)로 빠르게 페일오버 할 수 있다.

 

 

 

 

 

 

 

 

2-7. 기타

 

(1) GLSB(글로벌 서버 부하 분산)

 

 

평상시에는 유저와 물리적으로 가까운 서버를 이용해 접속시켜 레이턴시를 줄인다.

장애 발생 시 복제 기능으로 페일오버.

성능을 위해서는 비동기 구성을 사용하나 이 경우 데이터를 완전히 보호할 수 없다.

 

 

 

(2) 감시의 종류

 

- 생존 감시

: 감시 대상인 서버의 프로세스에 지속적으로 핑을 보내 작동 여부를 확인한다.(Polling)

- 로그 감시

: 기존에 확인하지 못한 로그가 발생할 경우 확인해서 상태를 감시한다.

- 성능 감시 (SNMP)

: 디스크 사용률, 메모리 사용현황, 디스크 고갈 등 리소스 상태와 네트워크 액세스 지연 시간, 디스크 액세스 지연 시간 등으로 파악. 서브 및 네트워크 장비까지 모두 감시한다.

- 콘텐츠 감시

: 로드밸런서가 주로 담당하며, 감시 대상의 URL에 지속적으로 Get 요청을 보내서 가동 여부를 판단하고 응답이 오지 않는 서버에는 클라이언트 요청을 전달하지 않는다.