ساعت دقیق، بخشی از صحت سرویس است
وقتی دو سرور درباره ترتیب رویدادها اختلاف دارند، مسئله همیشه از صف پیام یا پایگاه داده آغاز نمی‌شود. ممکن است ساعت یکی از میزبان‌ها جلو باشد و گزارش‌های آن آینده را نشان دهند. سامانه احراز هویت، اعتبار گواهی، زمان انقضای نشست و تحلیل رخداد همگی به برداشت قابل اتکا از زمان وابسته‌اند. chrony پیاده‌سازی همگام‌سازی ساعت است که ابزارهای chronyd و chronyc را در اختیار مدیر سیستم می‌گذارد. chronyd کار اصلی اندازه‌گیری و اصلاح را انجام می‌دهد و chronyc رابط مشاهده و کنترل آن است. هدف این مقاله توضیح مدل عملیاتی این مجموعه است، نه ارائه یک نسخه تنظیمات که بدون شناخت شبکه روی همه ماشین‌ها کپی شود.
ساعت سیستم از نگاه برنامه معمولاً یک عدد پیوسته و دقیق به نظر می‌رسد، اما سخت‌افزار محلی نوسان دارد. حتی اگر امروز زمان درست تنظیم شود، نرخ حرکت ساعت ممکن است با مرجع تفاوت داشته باشد. دما، محیط مجازی و وضعیت اجرای ماشین روی کیفیت اندازه‌گیری اثر می‌گذارند. به همین دلیل همگام‌سازی شامل دو مسئله است: اختلاف فعلی ساعت و خطای نرخ حرکت آن. اصلاح صرف تاریخ، مسئله دوم را حل نمی‌کند. chrony با نمونه‌برداری از منابع و برآورد رفتار ساعت می‌کوشد هر دو را مدیریت کند؛ بنابراین سلامت سرویس را باید در یک بازه زمانی بررسی کرد، نه فقط با دیدن یک خروجی تاریخ.
درخواست زمان، اندازه‌گیری همراه با عدم قطعیت است
در NTP تبادل پیام به برآورد فاصله زمانی میان ساعت محلی و منبع کمک می‌کند. تأخیر رفت و برگشت شبکه بخشی از این اندازه‌گیری است. مشکل زمانی پدید می‌آید که مسیر رفت و برگشت متقارن نباشد یا صف شبکه در یک جهت بیشتر از جهت دیگر باشد. در این وضعیت حتی یک منبع درست هم ممکن است برای کلاینت برآورد کم‌دقتی ایجاد کند. پس نزدیک بودن منبع از نظر جغرافیا به تنهایی کافی نیست؛ پایداری مسیر و میزان تغییر تأخیر نیز اهمیت دارد. از اینجا می‌توان فهمید چرا نتیجه یک نمونه منفرد مبنای مناسبی برای نتیجه‌گیری درباره انحراف دائمی ساعت نیست.
انتخاب چند منبع مستقل به تشخیص وضعیت‌های ناسازگار کمک می‌کند. استقلال یعنی منابع صرفاً نام‌های متفاوتی برای یک زیرساخت مشترک نباشند. اگر همه منابع از یک ساعت اشتباه تغذیه شوند، توافق آن‌ها تضمین‌کننده صحت نیست. در محیط سازمانی معمولاً کلاینت‌ها از سرورهای زمان داخلی استفاده می‌کنند و آن سرورها با منابع بالادستی مناسب ارتباط دارند. این طرح نیازمند پایش خود سرورهای داخلی است. پنهان‌کردن همه کلاینت‌ها پشت یک منبع واحد بدون افزونگی، مسئله را از شبکه بیرونی به یک نقطه شکست داخلی منتقل می‌کند. تعداد و ترکیب منابع باید با دسترس‌پذیری شبکه و سیاست سازمان تعیین شود.
تفاوت server و pool در پیکربندی
در فایل chrony.conf دستور server یک منبع مشخص را معرفی می‌کند. دستور pool برای مجموعه‌ای از سرورها طراحی شده که از طریق نام دامنه معرفی می‌شوند. این تفاوت فقط ظاهری نیست؛ نام یک مجموعه عمومی ممکن است به چند نشانی پاسخ دهد و چرخه انتخاب و جایگزینی منابع با یک میزبان ثابت یکسان نباشد. پیش از انتخاب باید دانست چه کسی آن نام را اداره می‌کند، کلاینت به چه شبکه‌ای دسترسی دارد و آیا استفاده از سرویس عمومی با سیاست سازمان سازگار است. در محیط جدا از اینترنت، افزودن نام‌های عمومی بدون امکان دسترسی تنها خطای قابل پیش‌بینی تولید می‌کند.
گزینه iburst برای گرفتن نمونه‌های اولیه سریع‌تر در شرایط تعریف‌شده به کار می‌رود و می‌تواند زمان رسیدن به برآورد اولیه را کاهش دهد. این گزینه به معنی ارسال دائمی و بی‌وقفه درخواست نیست. فاصله نمونه‌برداری و رفتار انتخاب منبع موضوع‌های جداگانه هستند. همچنین فایل driftfile محلی برای نگه‌داری برآورد خطای نرخ ساعت است تا اجرای بعدی از اطلاعات قبلی استفاده کند. این فایل را نباید با نسخه پشتیبان تنظیمات یا تاریخچه کامل اندازه‌گیری‌ها اشتباه گرفت. اگر ماشین از یک الگوی آماده تکثیر شده باشد، باید رفتار ساعت و شرایط مجازی‌سازی آن ماشین جدید جداگانه ارزیابی شود.
اصلاح تدریجی در برابر جهش ساعت
اصلاح ساعت می‌تواند با تغییر تدریجی نرخ انجام شود تا زمان به مقدار درست نزدیک شود. در مقابل، جهش ساعت مقدار زمان را ناگهان تغییر می‌دهد. این تفاوت برای برنامه‌هایی که مدت را با ساعت دیواری حساب می‌کنند مهم است. جهش رو به عقب ممکن است ترتیب ظاهری رویدادها را برهم بزند؛ جهش رو به جلو نیز می‌تواند انقضاها را زودتر فعال کند. برنامه‌ای که مدت سپری‌شده را اندازه می‌گیرد بهتر است از ساعت یکنواخت مناسب استفاده کند، اما مدیر زیرساخت نمی‌تواند فرض کند همه نرم‌افزارهای موجود چنین رفتاری دارند. سیاست اصلاح باید با نیاز برنامه‌ها سازگار باشد.
دستور makestep اجازه می‌دهد وقتی اختلاف از آستانهٔ تعیین‌شده بزرگ‌تر باشد و محدودیت شمار به‌روزرسانی‌ها اجازه دهد، اختلاف بزرگ با جهش اصلاح شود. محدود کردن این رفتار به ابتدای کار یک الگوی رایج است، ولی مقدار مناسب به سرویس وابسته است. نباید یک نمونه مستندات را بدون فهم آستانه و شمار به‌روزرسانی مجاز وارد تولید کرد. هنگام راه‌اندازی مجدد ماشین، تفاوت زیادی میان اصلاح ساعت پیش از شروع برنامه‌ها و اصلاح آن در میانه پردازش تراکنش‌ها وجود دارد. وابستگی سرویس به آماده‌شدن زمان نیز باید با سازوکار راه‌اندازی توزیع بررسی شود؛ فعال بودن پردازش chronyd به خودی خود اثبات نمی‌کند ساعت در محدوده مطلوب قرار گرفته است.
خروجی tracking چه چیزی می‌گوید؟
فرمان tracking در chronyc نمایی از وضعیت برآورد ساعت می‌دهد. شناسه مرجع، سطح منبع، زمان مرجع و اطلاعات خطای ساعت برای تشخیص وضعیت استفاده می‌شوند. Stratum فاصله سلسله‌مراتبی از مرجع را نشان می‌دهد و رتبه‌بندی ساده کیفیت نیست. یک منبع با عدد کوچک‌تر لزوماً مسیر شبکه بهتر یا اندازه‌گیری دقیق‌تری برای کلاینت شما ندارد. خواندن خروجی باید همراه با شناخت وضعیت همگام‌سازی باشد. اگر مرجع معتبر انتخاب نشده، مشاهده چند عدد کوچک در خروجی نباید به عنوان سلامت قطعی گزارش شود. تغییرات در طول زمان معمولاً از یک تصویر لحظه‌ای ارزشمندترند.
در گزارش عملیاتی بهتر است میان اختلاف برآوردشده، تأخیر مسیر و پراکندگی اندازه‌گیری تفاوت گذاشته شود. هر کدام علت و اقدام متفاوتی دارند. اختلافی که پس از راه‌اندازی در حال کاهش است با اختلافی که هر ساعت افزایش پیدا می‌کند یکسان نیست. اولی ممکن است بخشی از رسیدن به وضعیت پایدار باشد؛ دومی نیازمند بررسی منبع، نرخ ساعت یا محدودیت محیط است. یک هشدار خوب فقط به وجود پردازش اکتفا نمی‌کند؛ وضعیت انتخاب منبع، مدت از آخرین به‌روزرسانی معتبر و تناسب خطای زمان با نیاز واقعی برنامه را نیز در نظر می‌گیرد.
sources و sourcestats را با هم بخوانیم
فرمان sources فهرست منابع و وضعیت انتخاب آن‌ها را نشان می‌دهد. نمادهای خروجی اهمیت دارند و باید با راهنمای نسخه نصب‌شده خوانده شوند. منبع انتخاب‌شده، منبع قابل ترکیب و منبع نامناسب موقعیت‌های متفاوتی دارند. نمایش یک منبع در فهرست به معنی استفاده از آن نیست. همچنین ستون reach تاریخچه‌ای محدود از موفقیت پاسخ‌ها را بازتاب می‌دهد و به شکل خاصی نمایش داده می‌شود؛ تفسیر آن به عنوان درصد ساده اشتباه است. برای تشخیص قطع ارتباط، باید روند تغییر این ستون و زمان آخرین پاسخ همراه با تنظیمات فاصله نمونه‌برداری بررسی شود.
فرمان sourcestats اطلاعات آماری بیشتری درباره اندازه‌گیری منابع می‌دهد. اختلاف میان منابع، پراکندگی نمونه‌ها و کیفیت برآورد به مشخص‌شدن مسیر مسئله کمک می‌کند. اگر تنها یک منبع ناپایدار است، تغییر تنظیمات کل میزبان معمولاً نخستین اقدام مناسبی نیست. اگر همه منابع همزمان افت کیفیت دارند، مسیر مشترک شبکه، بار میزبان یا تغییرات مجازی‌سازی ارزش بررسی دارند. ثبت خروجی‌ها پیش و پس از تغییر اهمیت دارد؛ در غیر این صورت ممکن است یک بهبود موقت را به اصلاحی نسبت بدهیم که علت اصلی را هدف نگرفته است. تغییر همزمان چند پارامتر نیز مقایسه را دشوار می‌کند.
امنیت منبع و دسترسی به سرویس
قابل دسترس بودن پاسخ NTP به تنهایی هویت منبع را اثبات نمی‌کند. در سناریوهای مناسب، NTS برای محافظت رمزنگاری‌شده از ارتباط زمان مطرح می‌شود. پشتیبانی کلاینت، سرور، کتابخانه‌ها و دسترسی شبکه باید بررسی شود. NTS با یک سرور دلخواه که چنین قابلیتی ندارد فعال نمی‌شود و مشکلات مسیر یا دقت فیزیکی ساعت را نیز جادویی برطرف نمی‌کند. امنیت زمان مجموعه‌ای از کنترل‌هاست: انتخاب منبع معتبر، محدودکردن تغییر تنظیمات، پایش انحراف و حفاظت از مسیر مدیریت. صرف اضافه کردن یک گزینه بدون بررسی نتیجه عملی، شاهد اجرای موفق این کنترل‌ها نیست.
میزبانی که فقط کلاینت زمان است نباید ناخواسته به سرور عمومی تبدیل شود. دستورهای allow و deny در زمینه خدمت‌رسانی به کلاینت‌های NTP معنا دارند و باید دقیق بررسی شوند. دسترسی به فرمان‌های مدیریتی نیز موضوع جداگانه‌ای است. در شبکه سازمانی می‌توان فقط محدوده‌های لازم را مجاز کرد و همزمان با دیواره آتش مسیرهای شبکه را محدود ساخت. اگر سرور زمان داخلی برای چند شعبه خدمت می‌دهد، قواعد باید همان شعبه‌ها را پوشش دهند و تغییرات آدرس‌دهی ثبت شود. آزمایش از یک کلاینت مجاز و یک مسیر غیرمجاز کمک می‌کند سیاست واقعی با انتظار تطبیق داده شود.
یک مسیر عیب‌یابی قابل تکرار
فرض کنیم بعد از انتقال ماشین مجازی، هشدار اختلاف زمان فعال شده است. ابتدا وضعیت پردازش و گزارش خطا بررسی می‌شود، سپس tracking و sources ثبت می‌شوند. در مرحله بعد دسترسی DNS و مسیر UDP مورد نیاز منابع بررسی می‌شود. اگر نام‌ها حل می‌شوند اما پاسخ نداریم، بررسی فایروال، مسیر خروجی و محدودیت ارائه‌دهنده منطقی است. اگر پاسخ وجود دارد ولی هیچ منبعی انتخاب نمی‌شود، باید ناسازگاری منابع و کیفیت نمونه‌ها را دید. این ترتیب، احتمال تغییر بی‌دلیل تنظیمات حساس ساعت را کم می‌کند و برای تیم بعدی نیز شواهد قابل استفاده باقی می‌گذارد.
در پایان تغییر، تنها خاموش‌شدن هشدار کافی نیست. باید چند چرخه نمونه‌برداری سپری شود، روند خطا پایدار بماند و برنامه وابسته نیز رفتار درست داشته باشد. زمان بررسی، منابع فعال و تغییر انجام‌شده در گزارش ثبت می‌شوند. برای میزبان‌های جدا از شبکه، حالت نگه‌داری زمان بدون مرجع باید صریحاً از همگام‌سازی معتبر تفکیک شود. هیچ ابزار نرم‌افزاری نمی‌تواند در غیاب مرجع قابل اعتماد، صحت مطلق ساعت را تضمین کند. مزیت chrony زمانی روشن می‌شود که اندازه‌گیری، انتخاب منبع و مشاهده وضعیت را به یک فرایند عملیاتی منظم تبدیل کنیم و کیفیت زمان را با نیاز سرویس بسنجیم.
