1. NTP 서버는 무엇이며 왜 필요할까?
인트라넷에 여러 서버를 구성하다보면, 서버 사이 동기화를 진행해야 하는 순간이 온다. 이 서버 사이 동기화에서 가장 중요한 물리적인 요인은 시간인데, 각 서버의 운영체제 시간(또는 하드웨어 시간)이 조금이라도 틀어지게 되면 연동이 되지 않거나, 연동이 되더라도 나중에 시스템에 문제가 생겼을 때, 로그를 확인하는 과정에서 시간 간극으로 인해 정확한 원인을 파악하지 못하는 경우가 발생하게 된다.
예를 들어 A라는 서버가 B라는 서버보다 시간이 10분 정도 빠르게 설정되어 있고, 두 서버가 동기화되어 있는 상태라고 하자. 그리고 이 시스템에 이슈가 발생하여 기록된 로그를 확인하는데, 두 서버 사이 시간 차이가 존재한다면, A서버 고장이 기록된 시점보다 10분 늦은 시점에 B 서버 로그에도 이와 관련된 로그가 찍히게 된다. 별 것 아닌 것이라고 생각하는 분들도 있을 수 있겠지만, 로그의 양이 매우 많아 1초에 수백 줄이 찍히는 경우라면 이슈의 원인을 분석하기에 매우 큰 어려움이 있을 수 밖에 없다.
각 서버의 시간이 틀어지는 원인은 매우 다양하다. 우선 모든 서버가 동일한 시간부터 설치되지 않는다는 점이 있다. A 서버는 3년 전에 설치하여 구동하고 있고, B 서버는 2년 전에 설치하여 구동하고 있다면 설치 시점에 서버 하드웨어 시간이 조금 틀어져 있는 경우 시간 간극이 발생할 수 있겠다. 운영체제 시간이야 하드웨어 시간을 따라가니 논외로 치고...
두 번째 원인은 서버가 설치된 위치가 상이한 경우이다. 필자가 업무 상으로 다루는 서버에서도 이러한 케이스를 목격했는데, 동일한 장비를 동일한 시간에, 하드웨어 시간까지 완전하게 일치하여 부팅시키더라도, 각 서버가 위치한 서버룸이 매우 멀리 떨어져 있는 경우, 5년 정도 지나니 5분 이상의 시간 차이가 발생하는 경우도 있다. 이는 지구의 미세 중력에 따라 흐르는 시간의 속도가 달라지기 때문인데, 중력의 영향이 강한 곳일수록, 중력의 영향이 약한 곳에 비해 시간이 빠르게 흘러가기 때문이다(따라서 저층의 서버룸이 고층의 서버룸보다, 극지방에 위치한 서버들이 적도에 위치한 서버보다 시간이 빠르게 흐른다. 더 자세한 내용은 아인슈타인의 상대성 이론을 찾아보도록 하자).
하여간 이러한 원인들에 의해 서버의 시간이 틀어지면 서버 사이 연동이 어려워지기 때문에, 시간을 동기화 할 수 있는 서버가 필요해졌다. 이 때문에 나온 것이 NTP 서버다.
NTP 서버는 Network Time Protocol의 약자다. 이름에서도 알 수 있듯이 망 내의 시간을 동기화하기 위한 프로토콜이다. 이 프로토콜을 사용하기 위해서 특정 서버 시간을 기준으로 잡아야 할텐데, 이 서버가 시간 정확성이 낮은 장비라면 연동을 해봐야 의미가 없을 것이다. 따라서 이 기준서버는 매우 정교하게 작동하는 원자시계 또는 GPS와 연동된 시계가 장착된 서버를 지정한다.
그런데, 생각해보자. 이들 시계를 장착한 서버는 매우 가격이 비쌀 것이다. 만약 전 세계의 모든 서버가 시간을 동기화하기 위해 수량이 많지 않은 이들 기준 서버에 NTP로 시간 동기화를 시도한다면, 저 기준 서버들은 얼마 지나지 않아 과부하로 운명을 달리할 것이다. 따라서, 기준 서버의 부하를 덜어주기 위해, 이들 서버의 하부 구조에 이를 중계할 수 있는 NTP 서버를 다시 구성하게 된다. 하부 구조의 이들 서버 역시 그 아래 하부 구조 서버와만 시간 동기화를 진행하고, 그 다음 계층도 동일한 방식을 거치게 된다(다단계 구조 같다고 보면 된다).
위의 그림은 설명하기 쉽게 그린 대략적인 NTP 시스템의 구조다. 구조가 피라미드 형식인데 NTP 구성 시스템 내에서는 이러한 계층 구조를 Stratum이라고 부른다. 즉, 일반 서버에서 시간 동기화를 위해 연동을 진행할 때는 상위의 Stratum0, 1로 직접 동기화를 시도하는 것이 아니라, 그 아래의 계층부터 동기화를 진행하게 된다.
국내에서 시간 동기화에 사용하는 NTP 서버, 즉 Stratum 2의 서버 중 많이 사용하는 서버 목록은 아래와 같다.
- time.bora.net
- time.kornet.net (지원 종료)
- time.nist.gov
- kr.pool.ntp.org
그럼 본격적으로 NTP 서버를 구성하고 클라이언트에서 구성한 NTP 서버에 시간 동기화를 진행해보자.
2. NTP 패키지 설치
필자는 필자가 구성한 내부 네트워크 망에 사용하기 위한 NTP 서버를 구성하고 내부망 내의 가상 서버를 NTP 서버와 연동하여 시간 동기화를 진행하려 한다. 구조는 다음과 같다.
NTP 서비스를 실행하기 위해서는 ntp 패키지를 설치해야 한다. yum 명령어(Ubuntu 계열은 apt-get을 사용하자)를 사용하거나, rpm 파일을 직접 다운받아 수동으로 설치하면 된다.
< ntp 설치 명령어 >
# yum install ntp 또는
# rpm -Uvh {ntp rpm 파일} -> rpm 파일을 사용한 패키지 설치는 여기를 참고하자.
< ntp 패키지 설치 확인 명령어 >
# rpm -qa ntp
NTP 서비스는, 서버와 클라이언트 모두 ntp 패키지가 설치되어 있어야 한다. 따라서, 필자는 실제 사용 중인 Linux는 물론이고, 가상 서버에 올려놓은 Linux에도 동일하게 ntp 패키지 설치를 진행했다.
패키지 설치가 완료되면, 이와 관련된 설정 파일을 수정해야 한다.
3. NTP 서버 설정파일
늘상 말하는 것이지만, 모든 Linux 서비스의 설정파일은 /etc 폴더 내에 위치한다. ntp 서비스 역시 예외가 아니라 rpm -qc ntp 명령어로 설정 파일의 위치를 확인하면 다음과 같이 /etc 폴더 아래 경로가 출력이 된다.
세 설정 파일 중, 가장 위의 /etc/ntp.conf가 기본 설정 파일이며, vi 편집기로 열어보자.
기본적인 NTP를 구성하는 상황이라면, 설정 파일 내용 중, 위의 그림의 빨간 박스 내부만 확인하면 된다. 위쪽의 restrict는 NTP 서버에 접근할 수 있는 접근 제어 설정을 진행하는 곳이고, 아래의 server 부분은 Stratum 3인 내부 NTP 서버가 참조할 Stratum 2 서버를 지정하는 곳이라고 보면 된다.
(1) NTP Access Control 설정
restrict 부분으로 작성된 내용은, 현재 구성한 NTP 서버에 접근하여 시간 동기화를 진행할 수 있는 IP 대역대를 설정하는 것이라고 보면 된다. 기본적으로 서버 자신의 IP(127.0.0.1, ::1)는 모든 권한이 허용되어 있다.
필자의 경우, 아무나 필자의 NTP 서버를 사용하지 않기를 원하기 때문에, 기본값을 권한 없음으로 설정해 첫 줄에 박아두었다.
# restrict default nomodify notrap noquery
설정된 내용 외의 모든 IP에서는, NTP 서버에 설정된 내용을 수정할 수 없고, NTP 서버에 쿼리를 날릴 수도 없으며, ntpq라고 불리는 제어 명령어 사용도 불허한다는 의미다(ntpq는 다음 포스팅에서 알아볼 예정이다). 만약 이들 옵션이 누락된 채 restrict default만 존재한다면, 기본 값으로 모든 권한이 허용된다는 의미가 된다. 물론 모든 서버에 이러한 기본 권한이 허용되면 NTP 서버 부하가 증가하기 때문에 일반적으로 잘 사용하는 문구는 아니다.
조금 아래쪽에 restrict 내용이 다시 보이는데, 이 부분은 필자가 접속을 허용하는 IP 대역대를 명시하고, NTP 서버의 시간 동기화만 가능하도록 권한을 준 부분이다.
# restrict {IP 대역} mask {netmask} {옵션1} {옵션2}
필자는 내부망 대역대에서 쿼리를 제외한 나머지 권한은 부여하지 않았다. 이렇게 설정한 경우, 내부망의 모든 서버는 지금 설정하는 NTP 서버에 연동하여 시간 동기화를 하는 것이 가능해진다.
내부망 서버에서 우리가 구축한 NTP 서버로 접근할 수 있도록 설정하는 부분은 끝났다. 이제 NTP 서버가 Stratum 2의 NTP 서버와 시간 동기화를 할 수 있도록 설정할 차례이다.
(2) Stratum 2 NTP 서버 동기화
restrict 내용에서 얼마 떨어지지 않은 곳에 server라고 작성된 부분이 있다. 이 부분이 바로 NTP 서버가 시간 동기화를 진행할 Stratum 2의 NTP 서버를 명시하는 곳이다. 일반적으로 Stratum 2 계층의 NTP 서버를 동기화 할 때, 2개 이상의 NTP 서버를 명시하는데, 하나의 Stratum 2계층NTP 서버가 고장나더라도 다른 Stratum 2 계층의 NTP 서버를 사용할 수 있도록 하기 위함이다.
필자는 time.bora.net과 time.kornet.net을 추가했다.
Stratum 2계층 NTP 도메인 뒤에 iburst라는 옵션이 추가되어 있는데, 이 옵션은 연동하려는 Stratum 2계층 NTP와 현재 구성하는 NTP 서버의 시간 차이가 5분 이상 벌어져 있는 경우, 동기화를 할 수 있도록 만들어주는 옵션이라고 보면 된다. 만약, 현재 구성하는 NTP 서버의 시간이 10월 25일 오전 10시이고, Stratum 2계층의 NTP 서버 시간이 10월 25일 오전 11시라면, 아무리 NTP 구성을 잘 한다고 해도 시간 동기화는 진행되지 않는다. 따라서 iburst는 기본값으로 설정 파일 내용에 추가하는 것이 좋다.
이렇게 설정이 마무리되면 설정 파일을 저장하고 나온 뒤, ntpd 서비스를 재시작하자. 재시작하고 얼마 지나지 않으면 Stratum 2계층 NTP와 우리가 구성한 NTP 서버의 시간이 동기화된다.
ntpq 명령어에 -p 옵션을 사용하여 NTP 서버의 동기화 여부를 확인할 수 있다. 위의 사진을 보면 time.bora.net 앞에 *표시가 되어 있는데, 이는 현재의 서버가 time.bora.net에 NTP 연동이 잘 되어 있음을 의미하는 것이다.
내부망의 NTP 서버 구성이 끝났다면, 다음으로 가상 Linux 서버에서 생성한 NTP 서버에 시간 동기화를 진행해보자.
4. NTP 클라이언트 서버의 NTP 서버 동기화
사실, 클라이언트에서는 설정 파일을 크게 건드릴 것이 없다. server 부분에 해당하는 내용만 우리가 설치한 NTP 서버 IP를 넣어주면 끝이기 떄문이다. 따라서 필자는 실제 시간이 동기화되는 것을 확인하기 위해 설정 파일을 적용하기 전, date 명령어로 운영체제 시간을 바꾼 뒤, 설정 후 시간 동기화가 제대로 진행되는지 확인해보려 한다.
우선, date 명령어로 가상 Linux 서버의 시간을 변경했다. 1월 1일 00시 01분으로.
다음으로, /etc/ntp.conf 파일을 vi 편집기로 열어 server 부분에 우리가 구축한 NTP 서버의 IP를 입력해준다.
설정이 완료되면 저장하고 나와 ntpd 서비스를 실행하자. 그러면 아래와 같이 시간이 동기화 되는 것을 확인할 수 있다. 다만, 필자처럼 너무 시간 간격이 큰 경우, 처음 동기화되는데 시간이 조금 소요될 수 있다.
참고로 클라이언트 서버에서 NTP 서버로 시간을 질의하는 프로토콜은 UDP/123번 포트를 사용한다. 따라서, NTP서버나 클라이언트의 방화벽에서 이 포트와 연관된 통신을 막는 정책이 존재한다면 당연히 동기화는 진행되지 않는다. 10분 이상 기다렸음에도 동기화가 진행되지 않는다면 방화벽 문제일 가능성이 높으니 방화벽을 확인하도록 하자.
클라이언트 역시 ntpq 명령어에 -p 옵션을 붙여 결과를 검색하면, 우리가 설정한 NTP 서버와 잘 연동되고 있는 것을 확인할 수 있다.
이번 포스팅에서는 NTP 서버의 구성, 구축 방법 그리고 클라이언트와의 연동에 대해 알아보았다. 구축내용이 어렵거나 그렇지는 않지만, 이번 포스팅을 작성하면서 ntpq나 기타 설정 내용의 옵션에 대해 많이 설명하지 못했다. 따라서, 다음 포스팅에서 설정 옵션 및 시간 연동과 관련된 명령어를 추가로 작성하고 NTP 부분은 마무리하려 한다.
FIN.
'IT Security > LINUX Basic' 카테고리의 다른 글
35. Linux - 메일서버 구축 및 메일 전송 1, 개요 (0) | 2021.01.23 |
---|---|
34. Linux - NTP 서버 설치 및 시간 동기화2 (0) | 2020.12.09 |
32. Linux - rpm 명령어 기본 사용법3(의존성 외) (0) | 2020.10.25 |
31. Linux - rpm 명령어 기본 사용법2(설치/삭제) (0) | 2020.10.24 |
30. Linux - rpm 명령어 기본 사용법1(질의) (0) | 2020.08.23 |
댓글