서버인프라를지탱하는기술3_2_3

서버/인프라를 지탱하는 기술Ch. 3 무중단 인프라를 향한 새로운 연구

아꿈사chois79

13년 4월 23일 화요일

3.2 스토리지 서버의 다중화

(DRBD로 미러링 구성)


스토리지 서버는 대량의 파일을 저장한다


주요 이슈

고장에 의해 데이터가 손실되면 복구가 어려움

모든 파일을 복구하는데에는 많은 시간이 소요됨


스토리지 서버는 RAID로 구성하여장애를 예방하는 것이 일반적이다


RAID-0

A

C

E

G

B

D

F

H

Controller

I/O 성능 개선을 위한 구조


RAID-1

A

B

C

D

A

B

C

D

Controller

I/O 안정성과 성능이 개선But, 디스크 용량 낭비


RAID-5

A

C

P3

G

B

P2

E

H

Controller

P1

D

F

P4

RAID-1을 개선Parity를 사용


RAID-10

A

B

C

D

A

B

C

D

RAID-1

E

F

G

H

E

F

G

H

RAID-1

RAID-0일반적으로 많이 사용안전성과 성능 모두

뛰어남


RAID 컨트롤러가 고장난다면?...


스토리지 서버의 다중화를 고려해 보자

파일 업로드시 양쪽 서버에 저장


정합성 체크를 어떻게 하지?

장애로 인해 한쪽만 파일이 업로드 된다면?

파일 갯수가 많을 경우 정합성 체크가쉽지 않다


DRBD(Distributed Replicated Block Device)

HA 클러스터를 구성할때 유용한블록 디바이스를 제공

네트워크를 이용한 RAID-1


DBRD의 구성Active/Backup 구조

블록 디바이스에 대한 변경사항을실시간으로 전송


DBRD의 설정

/etc/drbd.conf

resource r0 {protocol A;on ws1 { # 호스트 명

device /dev/drbd0;disk /dev/sdb1;address 192.168.0.201:7789;meta-disk internal;

}on ws2 {

device /dev/drbd0;disk /dev/sdb1;address 192.168.0.202:7789;meta-disk internal;

}

사용가능 프로토콜 A: 로컬 디스크에 쓰기가 끝나고 TCP 버퍼에 쓰기가 완료된 시점에서 쓰기 작업이 완료

B: 로컬 디스크에 쓰기가 끝나고 원격 호스트로 데이터가 도달한 시점에서 쓰기 작업이 완료

C: 원격 호스트의 디스크에도 쓰기가 완료된 시점에서 쓰기 작업이 완료


DBRD의 실행

Master

1. DRBD실행

2. primary 상태로 변경

3. /dev/drbd0 에 파일 시스템 생성

4. /dev/drbd0 을 마운트

Secondary

실행시 기본적으로 Secondary 상태임


수동으로 장애 극복

백업 전환 스크립트

#!/bin/sh

/etc/init.d/nfs-kernel-server stop

umount /mnt/drbd0

drbdadm secondary all

마스터 전환 스크립트

#!/bin/sh

drbdadm primary all

mount /dev/drbd0 /mnt/drbd0

/etc/init.d/nfs-kernel-server start

1. 마스터 서버의 DRBD를 secondary 상태로 변경 - 블록 디바이스가 마운트 되어 있으면 실패 함2. 백업 서버를 master 상태로 변경하고 마운트


자동으로 장애 극복keepalived의 VRRP 기능을 사용

마스터 장애시 마스터에서 백업 전환 스크립트가 꼭 실행이 되도록 해야 함


NFS 서버를 장애 극복시 주의할 점

새롭게 마스터가 된 NFS 서버는 어떠한 클라이언트에서도 마운트 되지 않은 상태임

- NFS 클라이언트는 서버 전환 유무를 알지 못함 - 서버는 클라이언트가 마운트되지 않았다고 판단

해결책1. /var/lib/nfs/ 를 동기화 - 접속 정보를 미러링2. nfsd 파일 시스템을 이용 - 마운트되지 않은 요청도 마운트 된 것 처럼 처리


이게 끝이 아니다.

DRBD는 블록 디바이스를 미러링.누군가 실수로 지운 파일을 복구가 안됨.

매일은 아니더라도 최악의 사태를대비한 백업이 필요


3.3 네트워크의 다중화


지금까지의 다중화는 OSI 7Layer중 L3 ~ L7에 해당


L1, L2에 레벨에 장애가 발생한다면?랜 카드, 케이블 등..


네트워크 장애 포인트

1. LAN 케이블2. 네트워크 카드3. 네트워크 스위치의 포트4. 네트워크 스위치

1~3 장애: 링크 장애4 장애: 스위치 장애스위치간 접속시 1, 3 장애: 스위치간 접속 장애


링크 다중화

서버와 스위치 사이의 접속을 다중화서버에서 NIC을 여러개 사용하고,

LAN 케이블도 같은 수 만큼 연결


NIC 마다 IP가 틀린데, 그럼 장애시다른 IP로 접속을 해야 하나?


여러 물리 네트워크 카드를 모아서 하나의 논리적인 네트워크 카드로 다룰 수 있게 함

Bonding 드라이버


Bonding 드라이버의 동작모드 동작

balance-rr 라운드 로빈

active-backup 고장났을 경우 다음 NIC을 사용

balance-xor 송신처와 목적지 MAC 주소를 XOR하여 사용할 NIC을 결정

broadcast 송신 패킷을 복사해서 모든 물리 NIC에 동일한 패킷을 전송

802.3adIEEE 802.3ad 프로토콜을 사용해서 스위치와의 사이에서 동적으로 Aggregation을 작성

balance-tlb가장 부하가 낮은 물리 NIC을 선택해서 송신, 수신은 특정 물리 NIC을 사용

balance-alb 송수신 모두 부하가 낮은 NIC을 사용


MII 감시(Media Independent Interface)- 링크 다운되면 고장난 것으로 간주

ARP 감시(Address Resolution Protocol)- ARP 요청을 보내고 응답이 오는지 감지하여 판단

Bonding 드라이버의장애 탐지


스위치의 다중화

물리 NIC을 묶어서 다중해 해도 동일한스위치에 연결되어 있다면 스위치 장애에

대응할 수 없다


스위치의 다중화

LS1-2가 없을 경우 L1-1 장애 시 문제가 발생- Svr2에서 L2-1을 통해 Svr로 패킷 전송 시 유실 발생


링크를 이중화할 경우 스위치의 포트 개수는실질적으로 스위치 한 대분

서버 대수가 늘어나면 포트 수가 부족할 것


스위치의 증설

문제점: sw3과 sw4 사이에 연결이 없기 때문에 sw1이나 sw2 장애시 sw3과 sw4가 고립됨


그럼 이렇게 하면?

브로드 캐스트 스톰 발생브로드 캐스트 패킷이 루프가 생긴 네트워크 내부를 무한히 계속 돌아 다니는 상태

LS3-4


RSTP(Rapid Spanning Tree Protocol)

각 스위치가 협조해서 네트워크 상에서생긴 루프를 검출하고, 다중화된 연결을 자동적으로차단하기 위한 데이터 링크 계층의 프로토콜


RSTP의 동작

루프가 형성된 네트워크에서 그 일부를 논리적으로절단함으로써 루프를 해소

우선 순위를 기반으로 루트 브리지를 뿌리로한 “트리 구조”를 생성상위 노드로의 연결은 반드시 하나로 한정

장애시 하위 브리지와 BPDU를 교환해서 역할을 교대


Bonding 드라이버를 사용하면 서버와 스위치 간의 접속을 다중화할 수 있음

이에 따라 포트 증설이 필요할 경우RSTP를 지원하는 스위치를 사용하여

스위치 확장이 가능함.


서버인프라를지탱하는기술3_2_3

Technology

Transcript of 서버인프라를지탱하는기술3_2_3