Sunucu Saatlerinin Doğruluğu ve NTP

Sunucular 7×24 çalışan ve sürekli hizmet veren bilgisayarlar. Hiç kapanmayan bilgisayarların da saatlerinin bir kez düzgün ayarlandıktan sonra hiç bozulmamasını bekleyebilirsiniz.

Ama yanılırsınız :).

Sunucuların saatleri milisaniyeler düzeyinden başlayarak kayabilirler, hatta bu kayma zaman içerisinde dakikaları bile bulabilir. Artık bir donanımda tek sunucu da çalıştırmıyoruz, sanal sunucularda bu kayma miktarı daha da fazla artıyor (donanımın saati paylaşıldığı için).

Ne Önemi Var?

Eeee… bir sunucunun saati birkaç dakika ileride ya da geride olsa ne farkeder diyebilirsiniz. Sorun şu ki, sunucularda yapılan işlemlerin çoğunluğu saniye (hatta milisaniye) biriminde sürelerde gerçekleşiyor.

Birçok sunucuyu ilgilendiren bir işlem yaptığınızı farzedelim, aynı anda birinin saati 16:54:22, ötekinin saati 16:54:17, bir başkasınınkinin 16:55:22 olsun. O işlemin tam olarak hangi sunucuda hangi saatte yapıldığını nereden bileceksiniz? İşlemin yapılmasının ne kadar sürdüğünü ve akışını göremeyeceksiniz.

Sistemde gezinen birini takip ettiğinizi düşünelim, hangi sunucudan sunucuya atladığını, tam ne işlem yaptığını, vs çözmeye çalışırken aradaki zaman farkları kafanızı iyice karıştıracaktır.

Keza aynısı sistem kayıtlarını inceleyerek, geçmişe dönük inceleme yapmanız gereken herhangi bir çalışmada geçerli olacaktır.

NTP ile Saatlerimizi Ayarlayalım

Sunucuların zamanlarını ayarlamak için bir “kuzey yıldızı”na gereksinim duyacaklarını, yıllaar yıllar önce düşünmüş başkaları da. NTP (Network Time Protocol = Ağ Zaman Protokolü) adı verilen bir İnternet standardı ve sunucular arasında haberleşme yöntemi ortaya koymuşlar.

Tek işi zaman servisi vermek (yani saatin kaç olduğunu söylemek) olan NTP sunucularına bağlanan diğer sunucu bilgisayarları, saatin tam olarak kaç olduğunu öğrenip kendilerini ona göre gerekiyorsa düzeltme yöntemine gidiyorlar.

ntp.org isimli bir alan adı var, pool.ntp.org adresine bağlanan sunucular, “havuz”dan kendileri için en uygun/yakın zaman sunucusunu bularak oradan zaman bilgisini alıyorlar.

ntpdate ile Zamanda Atlamak

Normalde bir saati ayarlamak için, doğrudan saati değiştirir ve o zamana “atlama” yaparız. Saat bir an 16:54:22 iken birden 16:54:17 olabilir örneğin. Linux’ta date komutu aynen bunu yapıyor. ntpdate komutu da bu zamanı NTP sunucusundan çekerek yapan uzak akrabası.

Ancak sunucu kayıtları ve uygulamalarında tutarlılık yine önplanda olduğu noktada bunun sağlıklı olamayacağı birkaç senaryo düşününce ortaya çıkıyor. Zamanı geri aldığınızı farzedelim: 16:54:22 iken saat, zamanı ayarladınız ve (sunucu açısından zamanda geriye gidip) saati 16:54:17 yaptınız. Bu durumda sunucu 16:54:17′yi ve sonraki 5 saliseyi ikinci bir kere daha yaşayacak demektir. Sunucu kayıtlarında önce 16:54:18′de yapılmış bir işlem, sonra 16:54:22′de yapılmış bir işlem, sonra tekrar 16:54:18′de yapılmış ikinci bir işlem kaydedilebilecek demektir.

Aynı zaman damgalı ama aslında farklı iki zamana ait işlem tutarsızlık yaratacaktır. Ayrıca zamanın tekil/biricik/unique olduğu ve doğrusal ilerlediğine güvenerek çeşitli işlemler yapan sunucu servislerinin de güvendiği dağlara kar yağacaktır. Zaman ayarlarken servisleri durdurup, zamanı ayarlayıp, servisi başlatmak da bir çözüm ama çoğu zaman sunucu servisler için o kadarlık bir zaman kaybı da uygun olmuyor.

Üstelik ntpdate kullanılarak yapılabilecek olan, sadece belirli aralıklarla (cron’dan) ntpdate komutunu çalıştırmak.

ntpd ile Zamanın Akışını Değiştirmek

İşte o noktada NTPd adı verilen bir nadide uygulama devreye giriyor. Sunucunuzda sürekli çalışan bir uygulama olan ntpd, sadece anlık olarak değil, sürekli zamanı kontrolü altına alıyor. Belirli aralıklarla gidip uzaktaki NTP sunucusuna bakıp doğru zamanı alıyor.

Kendi yerelindeki zaman ile NTP’den gelen zaman farklı olduğunda ise zamanı doğrudan değiştirmek yerine, sunucudaki zamanı yavaşlatıyor ya da hızlandırıyor.

Örneğin gerçek saatin 16:54:22, sunucu saatimizin 16:57:22 olduğunu düşünelim. ntpd zamanın akışını yavaşlatıyor, bir dakika sürmesi gereken 60 saniyenin yavaaş yavaaaş 65 saniyede ilerlediğini görebiliyorsunuz. Daha uzun süren saniyeler sonucunda, her dakika 5 saniye daha gerçeğe yaklaşıyoruz ve 12 dakika sonunda saatler birbirine eş hale geliyor ve ntpd zamanı normal akışına çeviriyor.

Ya da zamanda geride olduğumuzu farzedelim. Gerçek saat yine 16:54:22 olsun ama bizim yerel saatimiz 16:53:22. Bu kez, zamanı hızlandırıyor. Bizim saatimizle saniyeler hızla akmaya başlıyor ve zaman içinde saatler eşitlendiğinde artık zaman akışı normale dönüyor.

Bilimkurgu filmlerinde gördüğümüz, evrende zamanın belli bir yerde daha hızlı/yavaş akması hayaldi gerçek oldu :).

Bu yöntem sayesinde, sunucu sistemimiz açısından zaman hiçbir zaman tekrar etmezken, zamanda hiç atlama da gerçekleşmiyor. Tüm saniyeler mutlaka yaşanıyor, hiçbir saniye iki kere yaşanmıyor.

ntpd aynı zamanda zaman değişimleri ile ilgili istatistik tutuyor ve sunucunun saati belirli bir zamanda ortalama ne kadar kayıyor bilgisine sahip oluyor. Daha sonra uzaktaki NTP sunucusu ile bağlantısı herhangi bir nedenle belirli bir süre koparsa, elindeki istatistiklere göre tahmin yürüterek zamanı ayarlamaya devam ediyor: “En son 2 gün önce doğru saati almıştım, 2 gündür haber yok. Elimdeki istatistiklere göre, bu sunucunun saati 2 gün içinde ortalama 5 ms kayıyor, o zaman ben de saati ona göre düzenleyeyim” diyerek çalışmasını sürdürüyor.

ntpd / ntpdate Seçimi

Peki ne zaman ntpd, ne zaman ntpdate kullanacağız?

Bir kereliğine zamanı ayarlayıp (aradaki fark günler düzeyinde örneğin), daha sonra tüm servisleri tekrar başlatıp logları da temizleyeceksek ntpdate kullanımı istediğimiz sonuca hızlıca varmamızı sağlıyor. Sonrasında ntpd ile ince kaymaları tutabiliriz.

Çalışan canlı bir sunucu sisteminde ise, bu işlemi ntpd’ye bırakmak ve zamanın daha nazikçe düzenlenmesini sağlamak gerekiyor.

Alternatif olarak görülen cron’dan sık sık ntpdate çalıştırarak sunucudaki saat kaymasını önlemeye çalışmak ise yazının başından beri belirttiğim nedenlerle pek önerilmeyen bir yöntem. Sürekli bir zaman için ntpd var zaten.

ntpdate, yine servislerin önemsenmediği, sık kapatılıp-açılan bir masaüstü sisteminde rahatlıkla tercih edilebilir.