Sunucuların aynı saatte olması neden önemlidir?


35

Veri merkezlerinin tüm sunucunun aynı saatte olduğundan emin olmak için çok çaba harcadığını (şu anda bulamıyorum, ancak her ne kadar bulamıyorum) okudum. Sıçrama saniyeleriyle ilgili endişeleri de içeren, ancak bunlarla sınırlı olmayan.

Sunucuların aynı zamanda olması neden bu kadar önemli? Ve gerçek toleranslar nelerdir?

Yanıtlar:


53

Güvenlik

Genel olarak, zaman damgaları, bir saldırganın çalabildiği bir kimlik doğrulama kodunu tekrar kullanabileceği (ör. Ağı koklayarak) tekrar saldırı saldırılarını önlemeye yardımcı olmak için çeşitli kimlik doğrulama protokollerinde kullanılır .

Kerberos kimlik doğrulaması tam olarak bunu yapar. Windows'ta kullanılan Kerberos sürümünde, varsayılan tolerans 5 dakikadır.

Bu, Google Kimlik Doğrulayıcı, RSA SecurID, vb. Gibi iki faktörlü kimlik doğrulama için kullanılan çeşitli bir kerelik parola protokolleri tarafından da kullanılır. Bu durumlarda tolerans genellikle yaklaşık 30-60 saniyedir.

İstemci ve sunucu arasında senkronizasyon yapıldığında, kimlik doğrulamanın tamamlanması mümkün olmazdı. (Bu kısıtlama, MIT Kerberos'un en yeni sürümlerinde, istekte bulunan ve KDC'nin kimlik doğrulama sırasında saatler arasındaki farkı belirlemesini sağlayarak kaldırılmıştır, ancak bu değişiklikler Windows Server 2012 R2'den sonra gerçekleşmiştir ve Windows'ta bir süre önce görmeden önce olacaktır. Ancak, 2FA'nın bazı uygulamalarının muhtemelen her zaman senkronize edilmiş saatlere ihtiyacı olacaktır.)

yönetim

Saatlerin senkronize olması farklı sistemlerle çalışmayı kolaylaştırır. Örneğin, tüm sistemler aynı zamana sahipse, günlük girişlerini birden çok sunucudan ilişkilendirmek çok daha kolaydır. Bu durumlarda, genellikle NTP'nin sağlayacağı 1 saniyelik bir toleransla çalışabilirsiniz, ancak ideal olarak zamanın karşılayabileceğiniz kadar yakın bir şekilde senkronize edilmesini istiyorsunuz. Çok daha sıkı toleranslar sağlayan PTP'nin uygulanması çok daha pahalı olabilir.


16
+1 Günlüğü zaman damgası senkronize olmayan zaman aşımına uğramış dağıtılmış öğelerdeki hata durumlarında sorun giderme: bir daha asla
Mathias R. Jessen

3
NTP arka plan programı çalıştıran sunucular genellikle 0,01 saniye (birkaç milisaniye) ile senkronize edilir. Yerel Windows NTP eşitlemesi yalnızca günde birkaç kez denetlenir ve doğru değildir. Windows için kullanılabilen ve iyi bir eşitleme sağlayan NTP istemcileri vardır.
BillThor

Bu yanıt için +1, çünkü sadece sistem saatimi kontrol ediyorum ve 5 saniye geç kaldım, ancak şimdi senkronize etmek için ntp kullanıyorum, soruyu ntp.org'a bir link ekleyerek insanların kontrol edebilir sistem
Freedo

2
makeayrıca, istemci / sunucu NFS'si arasındaki saat sapması ile karışır.
Sobrique

@BillThorlar, Windows hizmeti hakkında bilgilerinizi on yıl geride bırakıyor. 2003R2'nin piyasaya sürülmesinden bu yana tam bir NTP istemcisi olmuştur ve uyarlanabilir bir şekilde AD etki alanının aracı bölümünü senkronize etmektedir. 2008R2'de 64Hz sistem zamanlayıcı kene sınırlarının <16 ms'lik tipik ofsetlerini görüyoruz. Daha küçük kene aralıkları kullanabilen 2012+ kutularında daha iyi zaman işleyişi görüyoruz.
rmalayter

17

Temel olarak, farklı cihazlardaki kayıtlardan gelen olayları ilişkilendirebilmeniz için. Birinin web sunucunuz aracılığıyla veritabanınıza eriştiği bir güvenlik olayınız olduğunu varsayalım; güvenlik duvarınızdaki, yük dengeleyiciniz, web sunucunuz ve veritabanı sunucusundaki zaman damgalarının eşleşmesini, böylece her bir cihazdaki günlükleri bulabilmenizi istersiniz. Bu olayla ilgili. İdeal olarak, her şeyin birkaç milisaniye içinde olmasını istersiniz. Ve bunun gerçek dış zamanla senkronize olması gerekir, böylece gerekli olması durumunda günlüklerinizi üçüncü taraf günlükleriyle de ilişkilendirebilirsiniz.


2
Ayrıca, zaman senkronize edilmezse, ldap ve / veya kerberos gibi bazı güvenlik çözümleri başarısız olacaktır. Bazı HA çözümleri gibi.
Jenny D, Reinstate Monica’nın

7

Sadece yönetim açısından değil, aynı zamanda saatlerin senkronize olması uygulama seviyesi korelasyonunda da önemlidir. Bu, çözümün nasıl tasarlandığına, çalışan uygulamaların birlikte çalışabilecekleri işlemler için zaman damgasını nasıl aldıklarına bağlıdır. Çok fazla ofset olan (gelecekte yaklaşık 20 saniye idi) bir sunucuda çalışan ve etkileşimde olduğu diğerlerine kıyasla işlem doğrulamasının başarısız olduğunu gördüm.

Ayrıca, örneğin VMWare ESXi sunucusunda sanallaştırma ve VM'nin süresi sanallaştırma hipervizörü ile senkronize değilse, o zaman vmotion gibi bir eylem VM saatini hipervizörlerle senkronize edebilir ve bu da beklenmeyen sonuçlara yol açabilir. zaman farkı yeterince büyükse.

Gerçek toleransların ne olduğunu bilmiyorum, çünkü bunun ne tür sistemler olduğuna çok bağlı olduğunu düşünüyorum, ancak genel olarak, veri merkezindeki sunucuları birbirlerinin arasında bir saniyeden daha az bir süre uzakta tutmanın mümkün olduğunu düşünüyorum.


6

Artık saniyeden bahsettiğinizden beri, özellikle zor kullanım gerektirdiklerini belirtmek gerekir.

Genellikle 23:59:60 gibi bir saniye enjekte edilerek eklenirler, bu dakika ve saniye alanları için zaman damgalarını 0-59 olarak doğrularsanız sorunludur. İki saniye sürecek 23:59:59 yinelemenin alternatifi, zamanlaması saniyede bir duyarlılığa sahip herhangi bir şeyle uğraşacağından daha iyi değil.

Google aslında bir süre önce iyi bir çözüm bulmuştu, ancak henüz geniş çapta kabul görmemiş gibi görünüyor. Çözüm önerileri, bir "leke" uygulamak ve değişikliği tüm süreçler bir NTP sunucusu tarafından yönetiliyordu. Onlar bir blog yayınlanan 2011 yılında geri hakkında ilginç okuma yapar ve bu soruya alakalı görünmektedir.


Gibi bir çok geliyor bazı NTP müşterilerin dönüş davranış sonsuza gibi uygulamaya konmuştur.
CVn

@ MichaelKjörling tür. Fark, saatin zaman içinde bir düzeltme yapılarak yanlış olduğu tespit edildikten sonra dönüşün büyük sıçramalardan kaçınması gerektiğidir. Google’ın yaptığı, kasıtlı olarak ntp sunucularına bir mahsup eklemek, önceden çevirmek ve böylece artık hiçbir zaman atlamak olmadı.
Kaithar

5

Zaman damgaları ne zaman dahil olursa, senkronize olmayan cihazlar aşağıdaki gibi mantıksal tutarsızlıklar yaratabilir: A, B'ye bir sorgu gönderir ve B'nin yanıtı, sorgununkinden daha erken bir zaman damgasıyla gelir ve muhtemelen A'nın bunu görmezden gelmesine neden olur.


4

Yukarıdakilerin tümüne katılıyorum. Daha fazla düşünce yapmak istiyorum Cassendra
gibi bazı veritabanları zaman damgasını çok zorluyor . Eşzamanlılıkla başa çıkma şekli budur.

Farklı zaman damgası, veritabanını tamamen bozar.


2
Bu daha iyi bir yorum olarak gönderildi
Dave M

Bu yüzden, bir grup CentOS 5.2 makinesinde glibc'yi yükselttim ve güncelleme yanlışlıkla MST zaman diliminin yarısını oluşturdu - hemen rastgele çıkmış olan kullanıcıların “hareketsizlik” yapmasıyla ilgili sorunlar yaşadık. Her türlü küçük alet ve kodlama zamanın az ya da çok doğru olmasını bekliyor. Ayrıca, zamanınız yanlışsa ve otomatik olarak düzeltilmiş bir yol alırsa, kafa karıştırıcı ve gelecekten gelen dosyalar ve günlük zaman damgalarını
kapatırsınız

Bunun bir sürü dağıtık veritabanı için geçerli olmasını beklerdim. İki işlem sırasını tersine çevirmek için sadece birkaç saniyelik zaman damgalarındaki fark yeterli olabilir.
Kaithar
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.