시간 동기화
chronyd 설정과 sources 및 tracking 해석, RAC 노드 시간 차이와 동기화 실패 진단
#핵심 요약
RAC는 노드끼리 하트비트와 타임스탬프로 생존을 확인하므로 노드 시계가 어긋나면 정상 노드를 장애로 오판해 퇴출(eviction)할 수 있고, Data Guard에서도 리두 시각으로 지연을 판단하기 어려워짐
OL 7은 chronyd가 시간을 맞추며, 서비스가 active인 것과 실제로 동기화된 것은 다르므로 chronyc sources, tracking까지 봄
tracking의 System time은 기준 시간과의 차이이고, 여러 노드를 차례로 조회해 보이는 몇 초 차이는 시계 오차가 아니라 조회 시각 차이임
Grid Infrastructure의 CTSS는 NTP(chrony) 설정이 있으면 Observer 모드로 지켜보기만 하고, 없으면 Active 모드로 노드 시간을 직접 맞춤
#개념과 동작 원리
#Oracle Grid Infrastructure 19c의 시간 동기화 기준
CTSS는 19c에서 deprecated이며 OS에 구성한 NTP 또는 chrony를 사용하도록 안내됨
NTP를 사용하는 경우 CTSS는 Observer로 동작하고 직접 시각을 맞추지 않으므로 chronyd와 CTSS 프로세스가 함께 있다는 이유만으로 충돌이라고 판정하지 않음
NTP가 없을 때 CTSS는 Active로 노드 간 시간을 맞추며 외부 시간 서버에는 접속하지 않음
수업 자료의 동시 실행 충돌 설명은 Observer와 Active를 구분해야 함
당시 실제 CTSS 모드, 시각 오차와 노드 퇴출의 인과, 임계값, DNS, NTP 서버 소속과 패킷 차단 위치는 확인 불가
| 확인 | 대상 |
|---|---|
date, timedatectl |
로컬, UTC, RTC 시각, 시간대, NTP 동기화 표시 |
systemctl status, is-enabled chronyd |
지금 실행 중인지, 부팅 때 자동 시작인지 |
chronyc sources -v |
기준 서버 목록, ^* 지금 맞추는 서버, ^+ 함께 쓰는 서버, ^- 제외, ? 연결 불가 |
chronyc tracking |
Reference ID, Stratum, System time(빠름, 느림), Leap status |
chrony.conf 지시어 |
없거나 틀리면 |
|---|---|
server 이름 iburst |
맞출 기준이 없어 자기 시계만 믿고 시간이 계속 벌어짐 |
makestep 1.0 3 |
큰 오차도 아주 천천히만 보정돼 그동안 클러스터가 위험한 상태에 머묾 |
minsources 2 |
서버 하나만 믿어 그 서버가 틀린 시간을 주면 그대로 따름 |
server 0.pool.ntp.org처럼 이름만 적으면 chronyd가 기동할 때 DNS로 실제 서버 IP를 받으므로, 어느 서버가 선택될지는 그때의 DNS 응답에 따라 달라짐
사내 NTP 서버가 있으면 server <NTP_IP> iburst prefer로 우선 지정함
#필수 명령어 또는 SQL
#시간과 chronyd 상태
date
timedatectl
systemctl status chronyd
systemctl is-enabled chronyd
chronyc sources -v
grep ^server /etc/chrony.conf
grep -E "makestep|minsources" /etc/chrony.conf
cat /etc/resolv.conf결과 해석:
timedatectl의 NTP synchronized: no면 시간이 어긋나 있을 가능성이 큼
실습 기록: 기준 서버 셋 중 Stratum 2 서버 하나가 ^*, 다른 하나가 ^+, 나머지가 ^-로 나오고 모두 Reach 377
Reach는 최근 8번 응답 기록(8진수)이라 377이면 모두 응답한 것이고, Last sample의 +/- 오차가 작을수록 정확함
실습 서버의 chrony.conf는 0~3.pool.ntp.org와 makestep 1.0 3이었고 minsources는 주석 처리돼 있었음
#동기화 여부 확인 (tracking)
chronyc tracking결과 해석:
동기화된 상태: Reference ID에 기준 서버, Stratum 3 같은 값, System time : 0.000012 seconds fast of NTP time
동기화되지 않은 상태: Reference ID : 00000000 (), Stratum : 0, Ref time ... 1970, Leap status : Not synchronised
이때도 System time에 아주 작은 값이 나올 수 있어 그 값 하나로 동기화됐다고 판단하지 않음
수업 자료는 System time이 수십 밀리초를 넘으면 클러스터 하트비트 판단에 영향을 줄 수 있는 수준이라고 설명하며, 정확한 허용 임계값은 확인 불가
#RAC 노드 시간을 벌린 뒤 원복 (실습 VM 전용)
systemctl stop chronyd
date -s "10 minutes"
tail -f $GRID_HOME/log/<node>/cssd/ocssd.log
systemctl start chronyd
chronyc makestep
chronyc tracking | grep "System time"결과 해석:
한 노드의 시각을 10분 앞당긴 뒤 CSS 로그에 하트비트 경고가 반복되는지 보는 실습이며, 수업 자료의 예시 로그에는 has a disk HB, but no network HB 같은 경고가 나옴
19c의 CSS 로그 실제 위치는 Grid의 ADR($ORACLE_BASE/diag/crs/<host>/crs/trace/ocssd.trc)인 경우가 많아 환경에서 확인함
끝나면 바로 chronyd를 다시 켜고, chronyc makestep으로 큰 오차를 서서히가 아니라 한 번에 맞춘 뒤 System time이 다시 작아졌는지 확인함
운영 중인 RAC 노드에서 시각을 크게 바꾸면 노드 퇴출이나 DB 시각 역행 문제를 일으킬 수 있음
#여러 노드 한꺼번에 점검
#!/bin/bash
for node in <NODE1> <NODE2>; do
echo "== $node =="
ssh $node "date '+%F %T'; chronyc tracking | grep 'System time'"
done결과 해석:
실습 기록: 두 노드의 date가 2초 차이 났지만 System time은 각각 73나노초 느림, 16마이크로초 빠름으로 둘 다 정상 동기화였음
2초는 두 서버를 차례로 조회하며 생긴 실행 시간 차이임
노드 사이 SSH 키 인증이 없으면 노드마다 비밀번호를 물어 그만큼 조회 시각 차이가 커짐
#동기화가 안 될 때
tcpdump -i enp0s3 udp port 123 -n
systemctl restart chronyd결과 해석:
NTP는 UDP 123 포트를 쓰므로, 한 터미널에서 패킷을 지켜보며 다른 터미널에서 chronyd를 재시작함
나가는 패킷도 응답도 없으면 서버가 밖으로 나가지 못하는 네트워크 구조를, 나가는 패킷만 있고 응답이 없으면 상위 방화벽, 라우터의 UDP 123 차단을 의심함
다만 이 결과만으로 어느 장비가 막는지는 확정할 수 없어 네트워크 담당자와 함께 확인함
기준 서버 이름을 DNS로 풀지 못해도 동기화가 안 되므로 /etc/resolv.conf와 getent hosts 0.pool.ntp.org도 확인함
#사용 조건과 주의사항
RAC 설치 전에 모든 노드의 chronyd가 같은 기준 서버를 쓰고 NTP synchronized: yes인지 확인함
date -s나 chronyc makestep처럼 시각을 갑자기 바꾸는 작업은 DB와 클러스터, 시각 기반 작업에 영향을 주므로 운영 중에는 피하고, 큰 오차는 원인을 먼저 찾음
작은 System time 값은 그 순간의 상태일 뿐 계속 동기화된다는 보장이 아니므로 정기 점검 항목에 넣음