2.5 고속, 경량의 스토리지 서버 선택 3.1 DNS서버의 다중화

1. 2.5 고속 , 경량의 스토리지 서버 선택
CHAPTER 02.
한 단계 높은 서버 / 인프라 구축
다중화 , 부하분산 , 고성능 추구

2. 스토리지 서버가 왜 필요해졌을까 ?
모든 웹 서버로 배치 (deploy) 시키는 데에는 시간이 걸린다
.
모든 웹 서버에 대용량의 하드디스크를 탑재해야 한다 .
모든 웹 서버의 파일이 정합성을 갖는지 검증하기가 곤란하
다 .
웹 서버를 신규로 도입하기가 곤란하다 ( 파일 복사에 시간이 걸린
다 .)

3. 스토리지 서버 도입을 망설였던 이유
스토리지 서버에 장애가 발생하면 피해가 광범위하게 미친다 .
만일 데이터가 소실되면 복구하는 데 엄청난 시간과 노력이 소요된
다 .
스토리지 서버는 병목이 되기 쉽다 .
상용 제품은 비싸다 .

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

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

8. 이상적인 스토리지 서버
대량으로 접속되어 오더라도 병목이 되지 않을 정도로 빨라야 함
여러 대의 서버에 파일을 동기화하는 것을 피해야 함
단일장애점이 되지 않아야 함
가능하면 오픈소스로 실현하고자 함

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

11. 3.1 DNS 서버의 다중화
• CHAPTER 03.
• 무중단 인프라를 향한 새로운 연구
• DNS 서버 , 스토리지 서버 , 네트워크

12. DNS 서버 다중화의 중요성
주소변환 (resolve) 라이브러리를 이용한 다중화와
성능저하의 위험성
서버팜 (server farm) 에서의 DNS 다중화
-> VRRP 를 이용한 구성
-> DNS 서버의 부하분산

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

14. /usr/include/resolv.h

15. /etc/resolv.conf

16. 주소변환 라이브러리의 문제점
최초에 지정되어 있는 DNS 서버가 다운
-> 타임아웃 ( 디폴트 5 초 )
-> 다음 서버로 질의

17. 성능저하의 위험성 ..... 메일서버의 예
1. 목적지 주소의 도메인 파트에 대해 MX 레코드 질의를 한
다 .
2. MX 의 결과로부터 A 레코드를 질의해서
송신 서버의 IP 주소를 얻는다 .

18. 1 시간에 1000 통의 메일을 전송
1 시간 = 3600 초
DNS 질의 2 회하면서 총 10 초의 타임아웃 발생
3600 초 /10 초 = 360 통

19. 영향력이 큰 DNS 장애
성능은 저하되지만 에러는 발생하지 않는 상황은
장애의 발견을 늦추는 요인이 된다 .
DNS 서버 장애는 영향을 미치는 범위가 크지만 장애가 발생
한 장소를 찾아내려면 시간이 오래 걸릴 경우가 많다는 데 주
의

20. 서버팜에서의 DNS 다중화
VRRP 를 이용한 구성
로드밸런서를 이용한 구성

21. VRRP 를 이용한 구성

22. health check

23. 로드밸런서를 이용한 구성