Sunucu saatinin birkaç saniye kayması önemsiz görünür. Sonra bir gün sertifika doğrulaması başarısız olur, günlükler birbirini tutmaz ve yedekli iki makine hangi verinin daha yeni olduğunda anlaşamaz.
Bu yazı, sunucularda zaman senkronizasyonunu ele alıyor.
Saat Neden Kayar?
Bilgisayar saatleri mükemmel değildir:
- Donanım osilatörü kusurludur. Küçük hata birikir.
- Sıcaklık kayma hızını etkiler.
- Sanal makinelerde kayma daha büyüktür.
- Yüksek yük altında kesme gecikmeleri olur.
Üçüncü madde sanallaştırma kullananları doğrudan ilgilendirir: sanal makineler kendi saat kesmelerini her zaman zamanında alamaz ve fiziksel makinelere göre çok daha hızlı kayar.
Bu nedenle sanal makinelerde senkronizasyon daha sık ve daha dikkatli yapılmalıdır.
İkinci madde ise veri merkezi ortamında kısmen avantajdır. Sabit sıcaklık, kaymayı öngörülebilir kılar.
Kayan Saatin Yol Açtıkları
Sorunlar kademeli olarak ağırlaşır:
| Kayma | Ortaya çıkan sorun |
|---|---|
| Milisaniyeler | Dağıtık sistemlerde sıralama hatası |
| Saniyeler | Günlük karşılaştırması zorlaşır |
| Dakikalar | Kimlik doğrulama başarısız olur |
| Saatler | Sertifika geçersiz görünür |
| Günler | Zamanlanmış işler kaçar |
Üçüncü satır en sık yaşanan ve en kafa karıştırıcı olandır: iki aşamalı doğrulama kodları ve birçok kimlik doğrulama protokolü zaman tabanlıdır ve birkaç dakikalık kayma bile girişleri tamamen engeller.
Kullanıcı doğru şifreyi ve doğru kodu girdiği hâlde reddedilir. Sorunun kaynağı hiçbir yerde "saat" olarak görünmez.
Dördüncü satır ise şifreli bağlantıları etkiler. Sunucu saati ileri kaymışsa henüz geçerli olmayan bir sertifikayı geçersiz sayabilir.
Birinci satır dağıtık veritabanlarında veri tutarsızlığına yol açar. Hangi yazmanın daha yeni olduğu zaman damgasıyla belirleniyorsa, kayan saat yanlış kaydı kazandırır.
Zaman Senkronizasyonu Nasıl Çalışır?
Sunucu, güvenilir bir zaman kaynağına bağlanır:
- Zaman sunucusuna sorgu gönderilir.
- Gidiş-dönüş süresi ölçülür.
- Ağ gecikmesi hesaba katılır.
- Yerel saat kademeli düzeltilir.
Dördüncü madde protokolün en önemli davranışıdır: saat aniden zıplatılmaz, saatin akış hızı geçici olarak değiştirilerek fark kapatılır — buna kaydırma denir.
Bunun nedeni önemlidir. Saatin geriye zıplaması, süre ölçen her yazılımı bozar; negatif süreler, tekrar eden zaman damgaları ve kilitlenmiş beklemeler ortaya çıkar.
Üçüncü madde ise doğruluğu belirler. Ağ gecikmesi hesaba katılmazsa, sunucu saati sistematik olarak geride kalır.
Zaman Kaynağı Katmanları
Zaman kaynakları bir hiyerarşiye sahiptir:
| Katman | Kaynak |
|---|---|
| 0 | Atom saati, uydu alıcısı |
| 1 | Doğrudan katman 0'a bağlı sunucu |
| 2 | Katman 1'den saat alan sunucu |
| 3+ | Zincirin devamı |
Çoğu sunucu için katman 2 kaynaklar fazlasıyla yeterlidir. Milisaniye altı hassasiyet gerektiren özel durumlar dışında daha üst katmana çıkmaya gerek yoktur.
Önemli olan katman numarası değil, kaynak sayısıdır: tek bir zaman sunucusuna bağlanmak risklidir, çünkü o kaynak yanlış saat verirse sunucunuz onu sorgusuz kabul eder.
Birden fazla kaynak tanımlandığında istemci, aykırı davranan kaynağı tespit edip dışlayabilir.
Doğru Yapılandırma
Sunucularınızda dikkat edilecekler:
- En az üç zaman kaynağı tanımlayın.
- Coğrafi olarak yakın havuz kullanın.
- Zaman dilimini doğru ayarlayın.
- Sistem saatini UTC tutmayı değerlendirin.
- Güvenlik duvarında ilgili trafiğe izin verin.
Dördüncü madde çok sayıda sunucusu olanlar için önemli bir kolaylıktır: tüm sunucuları UTC'de çalıştırmak, farklı lokasyonlardaki günlükleri karşılaştırmayı basitleştirir ve yaz saati geçişlerinin yarattığı belirsizliği ortadan kaldırır.
Kullanıcıya gösterim yerel saatte yapılır; depolama ve günlük UTC kalır.
Beşinci madde sessiz bir başarısızlık nedenidir. Zaman senkronizasyonu trafiği engellenmişse hiçbir hata görünmez, saat sadece kaymaya devam eder.
İkinci madde ise doğruluğu artırır. Yakın bir kaynak, düşük ve kararlı ağ gecikmesi demektir.
Saati İzlemek
Senkronizasyonun çalıştığını varsaymayın:
- Kayma miktarını düzenli ölçün.
- Servis çalışıyor mu kontrol edin.
- Hangi kaynağın kullanıldığını görün.
- Belirli bir eşiği aşınca alarm üretin.
İkinci madde çok yaygın bir hatayı yakalar: zaman senkronizasyon servisi kurulmuş ama başlatılmamış veya çökmüş olabilir ve bu durum aylarca fark edilmez.
Sunucu normal çalışmaya devam eder, sadece saati yavaşça kayar. Sorun ancak bir kimlik doğrulama arızasıyla ortaya çıkar.
Dördüncü madde ise erken uyarı sağlar. Bir saniyelik eşik çoğu ortam için makul bir alarm seviyesidir.
Zaman senkronizasyonu yapılandırması ve izleme, sunucu devreye alma kontrol listenizin sabit bir maddesi olmalıdır; sunucu kiralama hizmeti kapsamında teslim edilen makinelerde bu yapılandırmayı ilk gün doğrulamak iyi bir alışkanlıktır.
Özel Durumlar
| Durum | Yaklaşım |
|---|---|
| Artık saniye | Yayma yöntemi kullanan kaynak seçin |
| İnternet erişimi olmayan ağ | Yerel zaman sunucusu kurun |
| Yüksek hassasiyet gereksinimi | Donanım destekli protokol |
| Uzun süre kapalı kalan makine | Açılışta tek seferlik düzeltme |
Dördüncü satır kaydırma yönteminin sınırını gösterir: saat çok fazla kaymışsa kademeli düzeltme günler sürer, bu nedenle açılışta tek seferlik sert düzeltme yapılıp sonra kaydırmaya geçilir.
Birinci satır ise nadir ama gerçek bir risktir. Artık saniye eklendiğinde bazı sistemler kilitlenmiştir; sorunu yayarak çözen kaynaklar bu riski ortadan kaldırır.
İkinci satır izole ağlarda zorunludur. İnternete çıkamayan sunucular için ağ içinde bir zaman kaynağı bulunmalıdır.
Sonuç
Sunucu saatinin kayması sessiz bir sorundur ve en sık kimlik doğrulama arızası olarak ortaya çıkar — kullanıcı doğru şifreyi girdiği hâlde reddedilir ve nedeni hiçbir yerde "saat" olarak görünmez. En az üç zaman kaynağı tanımlayın; tek kaynak yanlış saat verirse sunucunuz onu sorgusuz kabul eder. Servisin gerçekten çalıştığını izleyin — kurulmuş ama başlatılmamış bir senkronizasyon servisi aylarca fark edilmez. Çok sunuculu ortamlarda sistem saatini UTC tutmak günlük karşılaştırmasını basitleştirir.
Sıkça Sorulan Sorular (SSS)
Birkaç saniyelik kayma gerçekten sorun mu?
Duruma göre. Saniyeler seviyesinde günlük karşılaştırması zorlaşır, dakikalar seviyesinde kimlik doğrulama tamamen başarısız olur — iki aşamalı doğrulama kodları ve birçok protokol zaman tabanlıdır. Dağıtık veritabanlarında milisaniyeler bile yanlış kaydı kazandırabilir.
Kaç zaman kaynağı tanımlamalıyım?
En az üç. Tek kaynağa bağlanmak risklidir çünkü o kaynak yanlış saat verirse sunucunuz sorgusuz kabul eder. Birden fazla kaynakta istemci, aykırı davranan kaynağı tespit edip dışlayabilir. Katman 2 seviyesindeki havuzlar çoğu sunucu için fazlasıyla yeterlidir.
Saat neden aniden düzeltilmiyor?
Saatin geriye zıplaması süre ölçen her yazılımı bozar — negatif süreler, tekrar eden zaman damgaları ve kilitlenmiş beklemeler ortaya çıkar. Bu yüzden protokol saatin akış hızını geçici değiştirerek farkı kapatır. Sadece çok büyük kaymalarda açılışta tek seferlik sert düzeltme yapılır.
Sunucuyu UTC'de mi çalıştırmalıyım?
Çok sunuculu veya çok lokasyonlu ortamlarda evet. UTC, farklı yerlerdeki günlükleri karşılaştırmayı basitleştirir ve yaz saati geçişlerinin belirsizliğini ortadan kaldırır. Kullanıcıya gösterim yerel saatte yapılır; depolama ve günlük UTC kalır.
