2.5 고속 , 경량의 스토리지 서버 선택

CHAPTER 02.

한 단계 높은 서버 / 인프라 구축다중화 , 부하분산 , 고성능 추구

스토리지 서버가 왜 필요해졌을까 ?

모든 웹 서버로 배치 (deploy) 시키는 데에는 시간이 걸린다 .

모든 웹 서버에 대용량의 하드디스크를 탑재해야 한다 .

모든 웹 서버의 파일이 정합성을 갖는지 검증하기가 곤란하다 .

웹 서버를 신규로 도입하기가 곤란하다 ( 파일 복사에 시간이 걸린다 .)

스토리지 서버 도입을 망설였던 이유

스토리지 서버에 장애가 발생하면 피해가 광범위하게 미친다 .

만일 데이터가 소실되면 복구하는 데 엄청난 시간과 노력이 소요된다 .

스토리지 서버는 병목이 되기 쉽다 .

상용 제품은 비싸다 .

스토리지 서버는 단일장애점이 되기 쉽다

스토리지 서버는 병목이 되기 쉽다

이상적인 스토리지 서버

대량으로 접속되어 오더라도 병목이 되지 않을 정도로 빨라야 함

여러 대의 서버에 파일을 동기화하는 것을 피해야 함

단일장애점이 되지 않아야 함

가능하면 오픈소스로 실현하고자 함

HTTP 를 스토리지 프로토콜로 이용하기

3.1 DNS 서버의 다중화

•CHAPTER 03.

•무중단 인프라를 향한 새로운 연구

• DNS 서버 , 스토리지 서버 , 네트워크

DNS 서버 다중화의 중요성

주소변환 (resolve) 라이브러리를 이용한 다중화와 성능저하의 위험성

서버팜 (server farm) 에서의 DNS 다중화

-> VRRP 를 이용한 구성

-> DNS 서버의 부하분산

주소변환 라이브러리를 이용한 다중화

/usr/include/resolv.h

/etc/resolv.conf

주소변환 라이브러리의 문제점

최초에 지정되어 있는 DNS 서버가 다운

-> 타임아웃 ( 디폴트 5 초 )

-> 다음 서버로 질의

성능저하의 위험성 ..... 메일서버의 예

1. 목적지 주소의 도메인 파트에 대해 MX 레코드 질의를 한다 .

2. MX 의 결과로부터 A 레코드를 질의해서 송신 서버의 IP 주소를 얻는다 .

1 시간에 1000 통의 메일을 전송

1 시간 = 3600 초

DNS 질의 2 회하면서 총 10 초의 타임아웃 발생

3600 초 /10 초 = 360 통

영향력이 큰 DNS 장애

성능은 저하되지만 에러는 발생하지 않는 상황은장애의 발견을 늦추는 요인이 된다 .

DNS 서버 장애는 영향을 미치는 범위가 크지만 장애가 발생한 장소를 찾아내려면 시간이 오래 걸릴 경우가 많다는 데 주의

서버팜에서의 DNS 다중화

VRRP 를 이용한 구성

로드밸런서를 이용한 구성

VRRP 를 이용한 구성

health check

로드밸런서를 이용한 구성