Kurulum · Linux ve Sistem Yönetimi
Chrony ile Sunucu Zaman Senkronizasyonu Kurulumu
Doğru saat Kerberos, TLS geçerliliği ve olay ilişkilendirme için temel bağımlılıktır. Chrony kaynaklardan ölçüm alır ve sistem saatini düzeltir. Saat dilimi görüntüleme tercihidir; NTP…
Teknik gözden geçirme:
Mimari ve çalışma modeli
Doğru saat Kerberos, TLS geçerliliği ve olay ilişkilendirme için temel bağımlılıktır. Chrony kaynaklardan ölçüm alır ve sistem saatini düzeltir. Saat dilimi görüntüleme tercihidir; NTP senkronizasyonunun yerine geçmez.
Önce kurumun onaylı NTP kaynaklarını, erişim yolunu ve VM host/konuk saat mekanizmasını belirleyin. Aynı saati bağımsız iki daemon’un yönetmesini engelleyin. Dağıtımın chronyd/chrony servis adı ve yapılandırma yolunu doğrulayın; kaynakları iburst ile tanımlayıp servis durumunu kontrol edin.
Üretimde saati aniden ileri/geri atlatmak veritabanı, sertifika ve zamanlayıcıları etkileyebilir. Makestep koşullarını açılış penceresiyle sınırlayın; çalışma sırasında step gerekiyorsa bakım değerlendirmesi yapın. Kaynak erişimi ile güvenilen senkronizasyon durumunu ayrı kontrol edin.
- 1Onaylı saat kaynağı
- 2Chrony ölçümü
- 3Saat düzeltmesi
- 4Offset ve kaynak alarmı
Tasarım parametreleri
- Kaynak çeşitliliği
- Birden çok adresin aynı fiziksel saate bağlı olup olmadığını değerlendirin.
- Offset/skew
- Tek sayı yerine zaman içindeki offset, jitter ve frequency göstergelerini izleyin.
- VM saat yolu
- Hypervisor guest araçları ve NTP’nin desteklenen birlikte çalışma koşulunu kontrol edin.
Hesap ve uygulama örneği
Üç onaylı kaynağı olan pilotta chronyc sources -v ile seçilen kaynağı, tracking ile sistem düzeltmesini okuyun. Bir kaynağı keserek alternatif seçimi gözleyin. Kurum hedefi örneğin 50 ms ise bunu yalnız ilk örnekte değil 24 saatlik ölçümde doğrulayın.
Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.
chronyc tracking
chronyc sources -v
chronyc sourcestats -v
# Configuration fragment, replace with approved reachable sources:
# server ntp1.example.test iburst
# server ntp2.example.test iburst
# makestep 1.0 3
Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Reach sıfır | UDP 123, resolver veya kaynak erişimi. | Kaynak adı çözümleme ve ağ kuralını kontrol edin. |
| Saat doğru görünüyor ama sync yok | Manuel saat veya local mode. | Tracking reference ve leap status alanlarını inceleyin. |
Kabul ve doğrulama kontrolleri
- Tek saat yöneticisini doğrulayın.
- Onaylı kaynakları yapılandırın.
- Tracking/sources çıktısını kaydedin.
- Kaynak kesintisini sınayın.
- Step etkisini değerlendirin.
- Offset için alarm tanımlayın.
İlgili kavramlar
Telemetri ve zaman eşleştirmesi
Telemetri, sistemin ne yaptığını açıklayan log, metrik ve olay kayıtlarının bütünüdür. Log bir olayın ayrıntısını, metrik zaman içindeki davranışı, dağıtık iz ise isteğin bileşenler arasındaki yolunu gösterir. Saat farkları aynı olayı farklı zamanlarda olmuş gibi gösterebilir. Merkezi zaman senkronizasyonu, kaynak kimliği ve tutarlı saat dilimi kullanın. Alarm tasarımında yalnız eşik değil, ne kadar sürdüğü ve kullanıcıya etkisi de değerlendirilmelidir. Kayıtların kesildiği durum ayrıca izlenmeli; log yokluğu, olay yokluğu şeklinde yorumlanmamalıdır.
Kimlik doğrulama ve oturum
Kimlik doğrulama kullanıcının veya iş yükünün kim olduğunu kanıtlar; yetkilendirme ise bu kimliğin ne yapabileceğini belirler. Başarılı oturum açma, bütün kaynaklara erişim izni anlamına gelmez. Kullanıcı oturumları, servis kimlikleri, API belirteçleri ve cihaz sertifikaları farklı yaşam döngülerine sahiptir. İlk giriş kadar oturum süresi, belirteç yenileme, işten ayrılma, kayıp cihaz ve acil erişim senaryolarını da tasarlayın. Kimlik sağlayıcı erişilemez olduğunda hangi oturumların süreceğini ve hangi yeni erişimlerin engelleneceğini ölçün.
TLS ve sertifika doğrulaması
TLS iletişimin gizliliğini ve bütünlüğünü sağlar; sertifika doğrulaması karşı taraf kimliğinin kontrolüne yardımcı olur. Sertifika adı, zincir, geçerlilik süresi ve güvenilen kökler birlikte değerlendirilmelidir. Bir bağlantının şifreli olması uygulamanın yetkilendirmesinin doğru olduğu anlamına gelmez. Reverse proxy veya inspection kullanılıyorsa TLS oturumunun hangi noktada sonlandırıldığını çizimde açıkça gösterin. Hata teşhisinde sertifika kontrolünü kapatmak kalıcı çözüm değildir; yanlış hostname, eksik ara sertifika ve cihaz saatini ayrı inceleyin.
Uygulama tutarlılığı
Bir kopyanın açılabilir olması, uygulama verisinin tutarlı olduğunu kanıtlamaz. İşletim sistemi önbelleği, veritabanı günlükleri ve birden fazla disk veya servis arasındaki işlem sırası sonucu etkiler. Crash-consistent kopya beklenmedik kapanma sonrasındaki duruma benzer; application-consistent kopya uygulamanın desteklediği hazırlık ve yazma düzenini dikkate alır. Geri dönüşte yalnız dosya sayısını değil, işlem bütünlüğünü, kayıt ilişkilerini ve uygulama testini kontrol edin. Yedek ürününün desteklediği entegrasyonu, uygulama sürümünü ve hata çıktısını doğrulamadan tutarlılık varsaymayın.
Yüksek erişilebilirlik ile kurtarma ayrımı
Yüksek erişilebilirlik, belirli arızalarda hizmetin kısa kesintiyle sürmesini hedefler; yedekleme, kaybolan veya bozulan veriyi önceki bir noktadan geri getirir. Bir küme yanlış silinen kaydı diğer düğüme de aktarabilir. Bu nedenle HA ve backup birbirinin yerine geçmez. Hizmetin DNS, kimlik, ağ, depolama ve enerji bağımlılıklarını birlikte düşünün. Başarılı düğüm geçişi tek başına yeterli değildir: kullanıcı oturumunun, uygulama yazmasının ve dış entegrasyonların geçiş sonrası davranışı da ölçülmelidir.
Bağımlılık ve geri açılış sırası
Bir hizmet çoğu zaman kimlik, DNS, zaman, ağ, veritabanı ve lisans servislerine bağlıdır. Bağımlılıkları yalnız cihaz listesi olarak değil, hangi hizmetin hangi koşulla çalışabildiğini gösteren bir grafik olarak kaydedin. Geri açılış sırası buna göre belirlenir; bazı döngüsel bağımlılıklar özel acil erişim gerektirir. Çalışan altyapı bileşenleri ile işin yeniden başlayabildiği anı ayırın. Her bağımlılığa sorumlu, doğrulama yöntemi ve alternatif erişim yolu atayın. Uçtan uca testte bir bileşeni bilerek erişilemez hale getirerek varsayımları sınayın.
Birincil teknik dokümantasyon
Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.