زمان در Ubuntu Production: Chrony، پایش Offset و رفع اختلال NTP

مقدمه

Clock skew می‌تواند Kerberos، TLS، ترتیب log و replication را مختل کند. تنظیم timezone مشکل ساعت واقعی را حل نمی‌کند؛ source، offset و وضعیت sync باید مستقل بررسی شوند.

مثال عملی

دو NTP داخلی از منابع متفاوت تغذیه می‌شوند؛ سرورهای برنامه و DBA از آن‌ها استفاده می‌کنند و timestamp لاگ مرکزی UTC است.

پیش‌نیازها

Ubuntu Server 24.04 LTS، Bash 5، systemd؛ package patch را پیش از تغییر با dpkg-query ثبت کنید.

سخت‌افزار و ظرفیت: برای مثال یک VM با ۲ vCPU، ۲ GiB RAM و ۲۰ GiB دیسک؛ این ظرفیت پیشنهادی آزمایشگاه است و sizing سرویس به بار واقعی وابسته است.

نرم‌افزار و دسترسی: sudo، chrony و دسترسی UDP/123 به NTP سازمان؛ آدرس‌های 10.20.30.53 و .54 نمونه‌اند.

Architecture / Design

Authoritative time → NTP داخلی → chronyd client → kernel clock → برنامه. timezone فقط نمایش زمان را تغییر می‌دهد؛ تغییر clock واقعی روی workload اثر دارد.

Installation / Configuration

ابتدا وضعیت موجود را ثبت کنید. فقط یک daemon مالک همگام‌سازی باشد؛ نصب chrony معمولاً timesyncd را جایگزین می‌کند اما وضعیت را verify کنید.

timedatectl status
date -u --iso-8601=seconds
sudo apt-get update
sudo apt-get install -y chrony
systemctl is-active chrony systemd-timesyncd
sudo cp -a /etc/chrony /root/chrony-before-change

در فایل /etc/chrony/chrony.conf خطوط pool/server فعلی و sourcedirهای تولیدشده را بازبینی کنید؛ sourceهای متداخل را فقط پس از تعیین مالکیت حذف کنید. دو خط زیر نمونه source سازمان‌اند و باید جایگزین sourceهای public شوند.

server 10.20.30.53 iburst
server 10.20.30.54 iburst

sudo chronyd -p -f /etc/chrony/chrony.conf
sudo systemctl restart chrony
chronyc sources -v
chronyc tracking
sudo timedatectl set-timezone Asia/Tehran
date -u --iso-8601=seconds

انتظار: یک source با ^*، Reach پس از چند poll رو به 377 و Leap status: Normal. hostname source ممکن است reverse DNS نمایش داده شود. اگر offset بزرگ است روی Production makestep اجرا نکنید؛ ابتدا اثر آن بر database و scheduling را ارزیابی کنید.

Security Hardening

کلاینت NTP نباید بی‌دلیل سرور عمومی شود. sourceهای مجاز را در egress firewall محدود کنید؛ در محیط نیازمند صحت رمزنگاری‌شده NTS را با سرور پشتیبان طراحی کنید. دو سرور هم‌وابسته تنوع منبع ندارند.

Monitoring

Offset، stratum، Reach و تغییر source را پایش کنید. نمونه هشدار: offset بالاتر از ۱۰۰ ms برای ۵ دقیقه؛ برای workload حساس آستانه دقیق‌تر تعریف شود. Zabbix/Prometheus exporter نباید صرف active بودن سرویس را sync تلقی کند.

Troubleshooting

^? یعنی source هنوز قابل استفاده نیست؛ UDP، DNS و clock منبع را بررسی کنید. ^x می‌تواند source ناسازگار نشان دهد.

chronyc sources -v
chronyc sourcestats -v
chronyc tracking
sudo journalctl -u chrony -n 80 --no-pager

Reach صفر با daemon فعال یعنی polling موفق نیست. ساعت VM که مرتب جهش می‌کند نیاز به بررسی time sync hypervisor و یک مالک مشخص دارد. تغییر timezone برای TLS expired راه‌حل نیست.

Backup / Recovery

state داده کاربردی در این مقاله ندارد؛ config chrony، policy timezone و source inventory را version کنید. در rollback source قبلی را بازگردانید و tracking را کنترل کنید. پس از خاموشی طولانی قبل از شروع workload حساس، sync تأیید شود؛ جهش دستی زمان بخشی از recovery database نیست.

Best Practices

UTC در log و timezone محلی در نمایش استفاده شود. تغییر دستی ساعت و تغییر NTP یک ticket مستقل با تحلیل workload نیاز دارند.

نسخه‌های قدیمی و Compatibility

timesyncd برای کلاینت ساده قابل استفاده است؛ این baseline با chrony اجرا می‌شود. دستورهای timedatectl timesync-status به timesyncd مربوط‌اند و سلامت chrony را نشان نمی‌دهند.

پرسش‌های متداول

آیا timezone اشتباه باعث TLS failure است؟

TLS بر زمان واقعی تکیه دارد؛ timezone فقط نمایش را تغییر می‌دهد.

آیا active بودن chrony یعنی sync برقرار است؟

خیر؛ source selection، offset و Leap status باید بررسی شوند.