Mengapa penting bahwa server memiliki waktu yang sama persis?


35

Saya telah membaca berkali-kali (walaupun saya tidak dapat menemukannya sekarang) bahwa pusat data berusaha keras untuk memastikan bahwa semua server memiliki waktu yang sama persis. Termasuk, tetapi tidak terbatas untuk mengkhawatirkan lompatan detik.

Mengapa sangat penting bahwa server memiliki waktu yang sama? Dan apa toleransi sebenarnya?

Jawaban:


53

Keamanan

Secara umum, cap waktu digunakan dalam berbagai protokol otentikasi untuk membantu mencegah serangan replay , di mana penyerang dapat menggunakan kembali token otentikasi yang dapat dicurinya (misalnya dengan mengendus jaringan).

Otentikasi Kerberos melakukan hal ini, misalnya. Dalam versi Kerberos yang digunakan di Windows, toleransi default adalah 5 menit.

Ini juga digunakan oleh berbagai protokol kata sandi satu kali yang digunakan untuk otentikasi dua faktor seperti Google Authenticator, RSA SecurID, dll. Dalam kasus ini toleransi biasanya sekitar 30-60 detik.

Tanpa waktu yang disinkronkan antara klien dan server, tidak mungkin menyelesaikan otentikasi. (Pembatasan ini dihapus dalam versi terbaru dari MIT Kerberos, dengan meminta pemohon dan KDC menentukan offset antara jam mereka selama otentikasi, tetapi perubahan ini terjadi setelah Windows Server 2012 R2 dan itu akan memakan waktu sebelum Anda melihatnya di Windows versi. Tetapi beberapa implementasi 2FA mungkin akan selalu membutuhkan jam yang disinkronkan.)

Administrasi

Memiliki jam dalam sinkronisasi membuatnya lebih mudah untuk bekerja dengan sistem yang berbeda. Misalnya, mengkorelasikan entri log dari beberapa server jauh lebih mudah jika semua sistem memiliki waktu yang sama. Dalam kasus ini, Anda biasanya dapat bekerja dengan toleransi 1 detik, yang NTP akan berikan, tetapi idealnya Anda ingin waktu disinkronkan semampu Anda. PTP, yang memberikan toleransi lebih ketat, bisa jauh lebih mahal untuk diterapkan.


16
+1 Mengatasi masalah kesalahan kondisi pada ystems yang didistribusikan dengan stempel waktu pencatatan yang tidak sinkron: tidak pernah lagi
Mathias R. Jessen

3
Server yang menjalankan daemon NTP biasanya disinkronkan dalam 0,01 detik (beberapa milidetik). Sinkronisasi Windows NTP asli hanya memeriksa beberapa kali sehari, dan tidak seakurat. Ada klien NTP yang tersedia untuk Windows, yang menyediakan sinkronisasi yang baik.
BillThor

+1 untuk jawaban ini, karena saya hanya memeriksa waktu sistem saya dan saya terlambat 5 detik, tetapi sekarang saya menggunakan ntp untuk menyinkronkan, akan lebih baik untuk menambahkan pertanyaan ke tautan ke ntp.org sehingga orang dapat memeriksa mereka system
Freedo

2
makejuga menjadi bingung oleh skew jam antara klien / server NFS.
Sobrique

@BillThor informasi Anda tentang layanan Windows adalah sekitar satu dekade di belakang. Ini telah menjadi klien NTP penuh sejak rilis 2003R2, dan menyinkronkan secara adaptif bagian dari domain AD. Kita melihat <16 ms tipikal offset pada 2008R2 batas dari tick timer sistem 64Hz. Kami melihat ketepatan waktu yang lebih baik pada kotak 2012+ yang dapat menggunakan interval centang yang lebih kecil.
rmalayter

17

Terutama, sehingga Anda dapat menghubungkan insiden dari log pada perangkat yang berbeda. Misalkan Anda memiliki insiden keamanan di mana seseorang mengakses database Anda melalui server web Anda - Anda ingin cap waktu pada firewall Anda, penyeimbang beban Anda, server web Anda dan server database Anda semua cocok sehingga Anda dapat menemukan log pada setiap perangkat yang berhubungan dengan kejadian itu. Idealnya, Anda ingin semuanya berada dalam beberapa milidetik. Dan itu harus disinkronkan dengan waktu eksternal yang sebenarnya, sehingga Anda juga dapat mengkorelasikan log Anda dengan log pihak ketiga jika itu menjadi perlu.


2
Juga, beberapa solusi keamanan seperti ldap dan / atau kerberos akan gagal jika waktu tidak disinkronkan. Seperti beberapa solusi HA.
Jenny D berkata Reinstate Monica

7

Bukan hanya itu penting dari perspektif administrasi, tetapi memiliki jam di sinkronisasi saya menjadi penting dari korelasi tingkat aplikasi juga. Ini tergantung pada bagaimana solusi dirancang, bagaimana aplikasi yang berjalan mendapatkan stempel waktu mereka untuk setiap transaksi yang mereka kerjakan. Saya telah melihat validasi transaksi gagal karena aplikasi berjalan di server dengan terlalu banyak offset (sekitar 20 detik di masa depan) dibandingkan dengan yang lain yang berinteraksi dengannya.

Juga jika virtualisasi misalnya server VMWare ESXi, dan waktu VM tidak sinkron dengan hypervisor, maka tindakan seperti vmotion dapat menyinkronkan kembali jam VM dengan hypervisor dan ini pada gilirannya dapat menyebabkan hasil yang tidak terduga. jika perbedaan waktunya cukup besar.

Saya tidak tahu apa toleransi yang sebenarnya, karena saya pikir itu sangat tergantung pada jenis sistem yang ada, tapi saya pikir secara umum dapat dicapai untuk menjaga server di pusat data memiliki kurang dari satu detik saling mengimbangi satu sama lain.


6

Karena Anda menyebutkan detik kabisat, harus dicatat bahwa mereka memerlukan penanganan yang sangat sulit.

Biasanya ditambahkan dengan menyuntikkan sedetik 23:59:60, ini bermasalah jika Anda memvalidasi stempel waktu sebagai 0-59 untuk bidang menit dan detik. Alternatif pengulangan 23:59:59 untuk membuatnya 2 detik tidak jauh lebih baik karena itu akan mengacaukan apa pun yang waktu sensitif ke tingkat per detik.

Google sebenarnya datang dengan solusi yang baik beberapa waktu lalu yang tampaknya belum banyak diadopsi. Solusi mereka adalah menerapkan lompatan "smear" dan membagi perubahan selama periode waktu tertentu, seluruh proses dikelola oleh server NTP. Mereka menerbitkan sebuah blog tentang hal itu pada tahun 2011, membuat bacaan yang menarik dan tampaknya relevan dengan pertanyaan ini.


Kedengarannya seperti perilaku membunuh beberapa klien NTP , yang telah diimplementasikan seperti selamanya.
CVn

@ MichaelKjörling agak. Perbedaannya adalah bahwa perubahan tegangan dimaksudkan untuk menghindari lompatan besar setelah jam dinyatakan salah dengan membuat koreksi dari waktu ke waktu. Apa yang dilakukan Google adalah dengan sengaja menambahkan offset ke server ntp mereka, membanting di muka dan dengan demikian tidak pernah memiliki lompatan kedua.
Kaithar

5

Kapan pun cap waktu terlibat, perangkat yang tidak disinkronkan dapat membuat inkoherensi logis, seperti: A mengirimkan kueri ke B, dan balasan B datang dengan stempel waktu lebih awal dari kueri, mungkin menyebabkan A mengabaikannya.


4

Saya setuju dengan semua poin di atas. Saya ingin memberikan lebih banyak pemikiran.
Beberapa basis data seperti Cassendra sangat bergantung pada cap waktu . Itulah cara berurusan dengan konkurensi.

Stempel waktu yang berbeda akan mengacaukan basis data.


2
Ini lebih baik diposting sebagai komentar
Dave M

Jadi saya memutakhirkan glibc pada sekelompok mesin CentOS 5.2, dan pembaruan itu secara tidak sengaja menetapkan setengah dari zona waktu MST - kami segera memiliki masalah dengan pengguna yang secara acak dikeluarkan untuk melakukan "ketidakaktifan." Segala macam widget kecil dan doding mengharapkan waktu menjadi lebih atau kurang benar. Juga jika waktu Anda salah dan mendapat koreksi otomatis kembali, Anda berakhir dengan file dan mencatat waktu yang benar-benar membingungkan dan datang dari masa depan ...
Beberapa Nerd Linux

Saya berharap ini benar dari banyak basis data terdistribusi. Perbedaan cap waktu hanya beberapa detik mungkin cukup untuk membalik urutan dua operasi.
Kaithar
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.