TrueTime dan konsistensi eksternal

Pratinjau

Produk atau fitur ini adalah penawaran pratinjau yang tunduk pada "Persyaratan Penawaran Pra-GA" di bagian Persyaratan Layanan Umum di Persyaratan Khusus Layanan, dan hanya dapat digunakan untuk tujuan pengembangan, pengujian, pembuatan prototipe, dan demonstrasi program software. Produk atau fitur ini tidak dapat digunakan untuk tujuan pemrosesan data atau komersial apa pun. Produk dan fitur pra-GA tersedia "sebagaimana adanya" dan mungkin memiliki dukungan terbatas. Untuk mengetahui informasi selengkapnya, lihat deskripsi tahap peluncuran.

Spanner Omni mencapai konsistensi eksternal di lingkungan yang dikelola sendiri dengan menerapkan TrueTime API berbasis software. Sistem ini mengandalkan arsitektur berbasis cluster untuk menyediakan stempel waktu otoritatif, sehingga memastikan transaksi mencerminkan urutan serial yang ketat di seluruh infrastruktur Anda.

Untuk mempertahankan stempel waktu dan serialisasi yang akurat dan konsisten, konfigurasikan server waktu utama dan klien berbasis host yang menghitung interval waktu berdasarkan latensi jaringan dan clock drift. Pantau performa deployment Anda melalui metrik tertentu dan pastikan hardware yang mendasarinya memenuhi spesifikasi yang diperlukan untuk error kecepatan clock dan sinkronisasi stempel waktu.

Spanner Omni dan TrueTime

Untuk memberikan konsistensi eksternal yang sama dengan Spanner versi terkelola, Spanner Omni menggunakan implementasi TrueTime API Google berbasis software. Di lingkungan Spanner terkelola, TrueTime mencapai interval ketidakpastian yang sempit dengan menggunakan beberapa server waktu yang disinkronkan dengan penerima GPS fisik dan jam atom. Karena Spanner Omni berjalan di infrastruktur yang dikelola sendiri dan tidak dapat mengandalkan hardware fisik ini, Spanner Omni mencapai konsistensi menggunakan arsitektur berbasis cluster.

Dengan implementasi ini, semua transaksi dieksekusi dalam urutan serial. Jika satu transaksi selesai sebelum transaksi lain dimulai, transaksi kedua akan mencerminkan efek dari transaksi pertama. Spanner Omni mengandalkan pengurutan kausal berikut: jika panggilan ke t1 = TrueTime::Now() selesai sebelum panggilan ke t2 = TrueTime::Now() dimulai (bahkan di mesin yang berbeda), maka t2.latest akan lebih baru dari t1.earliest. Dengan menetapkan stempel waktu commit dari interval ini, Spanner Omni memastikan bahwa jika transaksi t1 di-commit sebelum transaksi t2 dimulai, stempel waktu utama akan mencerminkan bahwa t1 terjadi sebelum t2.

Untuk mengetahui informasi selengkapnya tentang cara Spanner versi terkelola menggunakan TrueTime, lihat TrueTime dan konsistensi eksternal dalam dokumentasi Spanner.

Arsitektur TrueTime

Arsitektur berbasis cluster menggunakan dua komponen inti untuk menyediakan TrueTime di seluruh deployment Anda:

• Server waktu: Cluster menetapkan satu server database sebagai server waktu utama. Server ini adalah sumber kebenaran tunggal otoritatif untuk seluruh deployment Spanner Omni, yang menyediakan waktu dari clock lokal presisi tinggi. Untuk memastikan ketersediaan tinggi, jika server utama berhenti merespons, cluster akan secara dinamis mempromosikan server database lain untuk mengambil peran ini. Server waktu dipaketkan dalam biner Spanner Omni, sehingga tidak memerlukan infrastruktur terpisah atau dependensi eksternal.

• Klien waktu: Daemon latar belakang berjalan di setiap mesin host dalam deployment. Daemon ini secara berkala membuat kueri server waktu utama untuk mengambil parameter waktu saat ini dan memublikasikannya ke proses yang berjalan di mesin.

TrueTime menghitung interval waktu berdasarkan clock drift terbatas dan waktu round-trip (RTT) jaringan antara server database Spanner Omni dan server waktu utama. Semua mesin host dalam deployment harus memiliki clock lokal yang beroperasi dalam batas yang diketahui pada error kecepatan.

Dampak ketidakpastian (epsilon) dan latensi

TrueTime merepresentasikan waktu sebagai interval, [earliest, latest], bukan nilai tunggal. TrueTime menghitung ukuran interval ketidakpastian ini berdasarkan dua faktor:

• Waktu round-trip (RTT) jaringan: Latensi selama sinkronisasi antara klien waktu dan server waktu utama. Klien waktu yang berada di pusat data yang sama dengan server waktu utama mengalami ketidakpastian yang jauh lebih rendah daripada klien di pusat data jarak jauh.

• Clock drift: Drift alami clock fisik pada mesin klien dan server antara sinkronisasi.

Ketidakpastian yang tinggi dapat meningkatkan waktu tunggu commit transaksi. Namun, karena replikasi Paxos juga memerlukan komunikasi jaringan, ketidakpastian TrueTime tidak meningkatkan latensi commit transaksi selama ketidakpastiannya lebih kecil daripada latensi round-trip Paxos.

Untuk mengetahui detail selengkapnya, lihat Spanner di balik layar: Memahami serialisasi ketat dan konsistensi eksternal.

Persyaratan hardware

Agar TrueTime berbasis software berfungsi dengan benar, hardware yang mendasarinya harus memenuhi persyaratan berikut:

• Penghitung stempel waktu: Anda harus menggunakan penghitung stempel waktu hardware. Pada arsitektur Linux x86, penghitung ini adalah Time Stamp Counter (TSC).
• Error kecepatan clock terbatas: Clock lokal harus beroperasi dalam error kecepatan yang diketahui dan terbatas dari frekuensi nominalnya. Anda dapat memantau pelanggaran error kecepatan clock menggunakan metrik sla_tester_violation_count. Untuk mengetahui informasi selengkapnya, lihat Kemampuan observasi TrueTime.

Batasan

TrueTime tidak didukung selama migrasi langsung mesin virtual (VM) atau container yang menjalankan Spanner Omni. Pengecualian ada untuk jenis mesin dan Amazon Machine Image (AMI) tertentu yang memenuhi syarat di platform seperti Amazon Web Services (AWS). Untuk mengetahui informasi selengkapnya, lihat Persyaratan sistem Spanner Omni.

Kemampuan observasi

Anda dapat menggunakan dasbor TrueTime di Grafana untuk memantau metrik berikut. Gunakan metrik ini untuk memastikan TrueTime berbasis software beroperasi dalam parameter yang diharapkan:

Metrik	Deskripsi	Tindakan yang disarankan
true_time_is_available	Memeriksa apakah TrueTime API tersedia.	Konfigurasikan pemberitahuan untuk setiap ketidaktersediaan. Jika TrueTime tidak tersedia, Spanner Omni juga kemungkinan tidak tersedia. Ketidaktersediaan dapat bersifat sementara atau persisten, dan memerlukan penyelidikan.
sla_tester_violation_count	Menunjukkan potensi masalah perilaku clock atau hardware pelanggaran persyaratan.	Selidiki untuk mengidentifikasi penyebab pelanggaran. Kemungkinan penyebabnya adalah migrasi langsung, penangguhan VM, atau TSC yang beroperasi di luar kecepatan clock batas yang diharapkan.
true_time_interval_uncertainty	Melacak epsilon dari TrueTime interval.	Pantau metrik ini untuk meminimalkan latensi transaksi. Ketidakpastian yang tinggi meningkatkan waktu tunggu commit, yang dapat meningkatkan latensi transaksi secara keseluruhan.