Sunucuların saatlerini GMT / UTC olarak ayarlanmış mı? [kapalı]


22

Bu, yalnızca bir veya birkaç siteye sahip küçük dükkanlar için büyük bir sorun olmayabilir, ancak daha büyük kuruluşlar için bu merak ettiğim bir şey.

UTC’de sunucunuzun tamamına / çoğuna sahip olmanın avantajları ve dezavantajları nelerdir? Bu kesinlikle raporlamada ve merkezi kayıt işlemlerinde yardımcı olacaktır. Ayrıca sorun giderme veya güvenlik denetimi için olay korelasyonuyla. Ayrıca, Günışığından yararlanma saati değiştiği için endişelenmenize gerek kalmaz.

Bir dezavantaj, yerel, coğrafi zamanda "04:00" 'de bir şey çalıştırılmasını istiyorsanız, otomatik olayların (örneğin, cron) programlanmasının biraz zaman alabilir. Unix-y makinesi için hala / etc / profile içinde "TZ" ayarlayarak kullanıcıların yerel saat diliminde bulunmasını sağlayabilirsiniz, ancak bir sunucuya RDesktop yapan Windows kullanıcıları için (ne nedenle olursa olsun) UTC'ye bakmalarına engel mi kalmışlar?

time  ntp  utc 

Adaçayı üyeler üzerinde çalışan benzer bir eski konu var: mailman.sage.org/pipermail/sage-members/2010/msg00592.html
adamo

Ve elbette, bilge üyeler hakkındaki soruyu da yayınladığınızdan beri (yeni) mailman.sage.org/pipermail/sage-members/2010/msg01194.html :)
adamo

2

Yanıtlar:


19

Çoğu şeyde olduğu gibi, "bağlıdır".

  • Tüm yöneticileriniz / kullanıcılarınız aynı saat diliminde mi? Belki de onların TZ uygun olacaktır.
  • Makineler yerel çevre ile etkileşime giriyor mu? Yerel TZ iyi olabilir.
  • Tüm kütükler analiz için merkezi bir yere mi çekildi? UTC orada yardımcı olabilir.
  • Makineler birbirleriyle zamanın önemli olduğu şekilde iletişim kurabiliyor mu? UTC aptal uyuşmazlık sorunlarını önlemeye yardımcı olabilir.
  • İşletim sistemi satıcısının (şebeke donanımı için daha muhtemel) bir önerisi var mı? Bunu bir düşün.
  • DST seni kızdıracak mı? UTC'yi kullanın.
  • Hayatınızı kolaylaştıracak ne düşünüyorsunuz? Bunu kullan.

Tüm seçenekleri yaptım (Yerel, UTC, keyfi ama tutarlı) ve makinelerin tüm dünyaya dağılmış olmasına rağmen, sistem yöneticilerinin ve kullanıcıların olduğu yerdeki "tüm makineler için ev ofisine yerel zamanı" tercih ettim. .


4
Pekala, birkaç kriter daha eklerdim. 1) Birden fazla zaman diliminde destek organizasyonlarınız varsa, her yerdeki UTC muhtemelen karışıklığı önler (bu durumda, 'ev ofisi' zaman dilimine ayarlanmış her şeyi yapmak yalnızca diğer ofislerdeki insanları tahriş etmeye hizmet eder; ortaya çıkan karışıklığı dikkate almayın) DST devreye girdiğinde. 2) Telekomünikasyon operatörleri gibi uluslararası satıcılarla uğraşmak zorundaysanız, çoğu UTC'de çalışıyor; Gönderdiğiniz zaman kayıt defterlerindeki zaman damgalarını dönüştürmek zorunda kalmamak çok zaman kazandıracaktır.
Murali Suriar

Farklı sunucularla farklı zaman dilimleri üzerinde çalıştım. Verilerin DST ve GMT olarak ayarlanan zaman dilimi sunucuları ile depolandığı bir projeyle ilgili ciddi sorunlarımız oldu. Düzeltilmesi kolay değil. Hiç kolay değil. UTC senin arkadaşın :)
John Hunt

6

Her şeyi GMT'ye ayarladık, günlük dosyalarını sistemler arasında ilişkilendirmeyi kolaylaştırıyor.

Fakat bence zaman dilimlerini düşürmeliyiz ve herkes her şey için GMT kullanmalı.


3

Diğerlerinin dediği gibi buna bağlı. Bu konuda uzun ve geniş deneyime sahip çok büyük bir grup tartıştı. Grup, dünyadaki askeri güçler ve UTC (GMT) kullanıyorlar.

Dikkate alınması gereken bir şey daha var. Bu sistemler uygulama kodunu destekliyorsa, uygulamaların saat diliminin farkında olup olmadığını bilmek için bana ulaştınız. Katıldığım bazı programlama forumlarında tarih / saatlerin her zaman UTC'de veritabanında saklanmasını ve son kullanıcıya tarih / saati nasıl gördüklerini seçmelerini öneririm.


2

Çok büyük bir hosting firması için çalışıyorum ve dünya çapında veri merkezlerimiz var. Genellikle makine saatini yerel veri merkezi saatine ayarlıyoruz ve ardından tüm destek personelimizin araçların kullanımı sırasında işlerin dönüştürüldüğü evrensel saat olarak konumlandırılan saat dilimini kullanıyoruz.

Diğerlerinin de dediği gibi, doğru bir cevap yok, ama kullandığımız yöntem :)


1

Buradaki politika, tüm makinelerin yerel saatlerine (yani fiziksel konumlarına) timzonlu olduğunu söylüyor. Zor olan tek şey, zaman nlocal verildiği için olay günlüğü girişlerini (windows machiens) ilişkilendirmektir - diğer birçok günlük dosyası da UTC'de saati yazar.

Ancak, bir sunucuya RDesktop yapan Windows kullanıcıları (ne nedenle olursa olsun) UTC'ye bakmakta mı kalmışlar?

Tamamen emin değilim, ama bence evet - saat dilimi mantıksal olarak bir makine seviyesi ayarıdır.


1

Destekledikleri uygulama nedeniyle fiziksel olarak 3 saat önceden ayarlanmış bir saat diliminde yerleşmiş makinelerimiz var.

Sunucular arasında beş saniyenin altında bir senkronizasyon bekleyen yazılımlar oluşturan, senkronizasyon için AD zamanına açıkça güvenen geliştiriciler ve senkronize olmayan durumlar için hata kontrol veya işleme rutinleri yazmaktan rahatsız olmayan geliştiricilere de sahibiz. müteakip arızaların yöneticilerin ağ zamanını hayal ettikleri standartta tutmamaları suçudur.

Yaptığımız şeyi yapma. Sadece seni acılandıracak.


1

Sadece tartışmaya ek olarak, dünyanın dört bir yanına dağılmış ofislerimiz var ve her birinin kendi web, uygulama ve veritabanı sunucusu var, her biri için farklı uygulama dalları da var, bu nedenle yerel saat dilimi iyi bir fikir ülke çapında konuşma. ABD sunucuları için, tüm konumlar için ana veri merkezimize uygun olan tüm konumlar için Central Time'a gidiyoruz, çünkü uygulama sunucuları için farklı zaman dilimlerini kullanmak ve DB'ler geliştiricilere zor anlar yaşatıyor.


0

Yeller App kısa süre önce tüm sistem yöneticilerinin UTC kullanmasını öneren bir blog yazısı yayınladı . İşte bir alıntı:

Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC.

Şakalar bir yana, temel olarak sadece UTC kullanmanın Günışığından Yararlanma Zamanı (DST) ve bunun getirdiği hataları rahatsız etmemek anlamına geliyor.

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.