👶🏾 ☔️ 🌼 etcd 3.4.3: penelitian keandalan dan penyimpanan penyimpanan 🖨️ 🕴🏿 🍊

Catatan perev. : Konten artikel ini tidak sepenuhnya khas blog kami. Namun, seperti yang diketahui banyak orang, etcd terletak di jantung Kubernetes, oleh karena itu penelitian ini, yang dilakukan oleh konsultan independen di bidang keandalan, ternyata menarik di antara para insinyur yang mengoperasikan sistem ini. Selain itu, menarik dalam konteks bagaimana proyek-proyek Open Source yang telah membuktikan diri dalam produksi ditingkatkan bahkan pada tingkat yang sangat "rendah". Vault

kunci-nilai (KV) dll adalah database terdistribusi berdasarkan algoritma konsensus Raft. Dalam analisis yang dilakukan pada tahun 2014 , kami menemukan bahwa etcd 0.4.1 dipengaruhi oleh apa yang disebut basi dibaca secara default(baca operasi yang mengembalikan nilai lama dan tidak relevan karena keterlambatan sinkronisasi - kira-kira terjemahan.) . Kami memutuskan untuk kembali ke etcd (kali ini - ke versi 3.4.3) untuk mengevaluasi kembali secara terperinci potensinya di bidang keandalan dan keamanan.

Kami telah menemukan bahwa operasi dengan pasangan "kunci-nilai" benar-benar serializable dan bahwa proses pengamat (jam tangan) dikirimkan ke setiap perubahan dalam kunci pesanan. Namun, kunci di etcd pada dasarnya tidak aman, dan risiko yang terkait dengannya diperburuk oleh bug, akibatnya relevansi sewa tidak diperiksa setelah menunggu kunci. Anda dapat membaca komentar pengembang dll pada laporan kami di blog proyek .

Penelitian ini disponsori oleh Cloud Native Computing Foundation (CNCF), bagian dari The Linux Foundation. Itu dilakukan sepenuhnya sesuai dengan kebijakan etis Jepsen .

1. Latar Belakang

Repositori KV dll adalah sistem terdistribusi yang dirancang untuk digunakan sebagai dasar untuk koordinasi. Seperti Zookeeper dan Konsul , etcd menyimpan sejumlah kecil negara yang jarang diperbarui ( secara default hingga 8 GB ) dalam bentuk peta nilai-kunci dan menyediakan transaksi baca, tulis, dan mikrotik yang sangat serializable di seluruh gudang data, serta primitif koordinasi seperti kunci , pelacakan (jam tangan) dan pemilihan pemimpin. Banyak sistem terdistribusi, seperti Kubernetes dan OpenStack , menggunakan etcd untuk menyimpan metadata cluster, mengoordinasikan tampilan data yang terkoordinasi, memilih pemimpin, dll.

Pada tahun 2014, kami sudah melakukan evaluasi dll 0.4 0.4 . Kemudian kami menemukan bahwa secara default cenderung membaca basi karena optimasi. Sementara pekerjaan pada prinsip-prinsip Raft membahas perlunya membagi operasi baca menjadi utas dan meneruskannya melalui sistem konsensus untuk memastikan viabilitas, dll membaca pada pemimpin mana pun secara lokal tanpa memeriksa keadaan terkini tentang pemimpin yang lebih baru. Tim pengembangan etcd menerapkan kuorum bendera opsional , dan di etcd versi 3.0 API , linearizability untuk semua operasi kecuali operasi pelacakan muncul secara default . API etcd 3.0 berkonsentrasi pada peta datar KV di mana kunci dan nilainya buram

array ( buram ) byte. Menggunakan rentang kueri, Anda dapat mensimulasikan kunci hierarkis. Pengguna dapat membaca, menulis, dan menghapus kunci, serta memantau aliran pembaruan untuk satu kunci atau rentang kunci. Toolkit etcd dilengkapi dengan sewa (objek variabel dengan masa hidup terbatas, yang dikelola dalam keadaan aktif oleh permintaan detak jantung klien), kunci (objek bernama khusus terikat pada sewa) dan pilihan pemimpin.

Dalam versi 3.0, etcd menawarkan API transaksional terbatasuntuk operasi atom dengan banyak tombol. Dalam model ini, transaksi adalah ekspresi kondisional dengan predikat, cabang benar, dan cabang palsu. Predikat dapat merupakan gabungan dari beberapa perbandingan utama: kesetaraan atau berbagai ketidaksetaraan, menurut versi satu kunci, revisi global, dll, atau nilai kunci saat ini. Cabang benar dan salah dapat mencakup beberapa operasi baca dan tulis; semuanya diterapkan secara atom tergantung pada hasil estimasi predikat.

1.1 Jaminan konsistensi dalam dokumentasi

Pada Oktober 2019, dokumentasi dlld untuk API menyatakan bahwa "semua panggilan API menunjukkan konsistensi yang konsisten - bentuk terkuat dari jaminan konsistensi yang tersedia pada sistem terdistribusi." Ini tidak begitu: konsistensi yang konsisten benar - benar lebih lemah daripada linierabilitas, dan linierabilitas jelas dapat dicapai dalam sistem terdistribusi. Lebih lanjut, dokumentasi menyatakan bahwa "selama operasi membaca, etcd tidak menjamin transfer nilai [yang terbaru (diukur oleh jam eksternal setelah selesainya kueri)] tersedia di setiap anggota cluster". Ini juga pernyataan yang terlalu konservatif: jika etcd menyediakan linearitas, operasi baca selalu dikaitkan dengan status komitmen terbaru dalam urutan linierisasi.

Dokumentasi juga mengklaim bahwa etcd menjamin isolasi serializable: semua operasi (bahkan yang mempengaruhi beberapa tombol) dilakukan dalam urutan umum. Para penulis menggambarkan isolasi serializable sebagai "tingkat isolasi terkuat yang tersedia dalam sistem terdistribusi." Ini (tergantung pada apa yang Anda maksud dengan "tingkat isolasi") juga tidak benar; serializability ketat lebih kuat dari serializability sederhana, sementara yang sebelumnya juga dapat dicapai dalam sistem terdistribusi.

Dokumentasi mengatakan bahwa semua operasi (kecuali pelacakan) di etcd secara linearizable secara default. Dalam hal ini, linearitas didefinisikan sebagai konsistensi dengan jam global yang disinkronkan dengan lemah. Perlu dicatat bahwa definisi seperti itu tidak hanya tidak sesuai dengan definisi linearitasHerlihy & Wing, tetapi juga menyiratkan pelanggaran kausalitas: node dengan jam buka akan mencoba membaca hasil operasi yang bahkan belum dimulai. Kami berasumsi bahwa etcd masih bukan mesin waktu, dan karena didasarkan pada algoritma Raft, definisi yang dapat diterima secara linier harus diterapkan.

Karena operasi KV di etcd adalah serializable dan linearizable, kami berpikir bahwa sebenarnya etcd menyediakan serialisasi yang ketat secara default . Ini masuk akal, karena semua kunci etcd berada dalam satu mesin negara, dan Raft menyediakan pemesanan lengkap semua operasi pada mesin negara ini. Bahkan, seluruh dataset etcd adalah objek linearizable tunggal.

Bendera opsional lebih serializable rendahTingkat operasi baca dari konsistensi ketat hingga seri yang teratur, memungkinkan pembacaan kondisi komitmen yang ketinggalan zaman. Perhatikan bahwa bendera serializabletidak memengaruhi serialisasi cerita; Operasi KV, dll, dapat diserialkan dalam semua kasus.

2. Tes pengembangan

Untuk membuat test suite, kami menggunakan perpustakaan Jepsen yang sesuai. Versi etcd 3.4.3 (terbaru pada Oktober'19) dianalisis, bekerja pada kelompok Debian Stretch yang terdiri dari 5 node. Kami telah mengimplementasikan sejumlah kesalahan dalam klaster ini, termasuk partisi jaringan, mengisolasi node individu, mempartisi cluster menjadi mayoritas dan minoritas, serta partisi non-transitif dengan mayoritas yang tumpang tindih. Mereka “menjatuhkan” dan menangguhkan subset node acak, dan juga para pemimpin yang sengaja dinonaktifkan. Distorsi temporal hingga beberapa ratus detik diperkenalkan, baik pada interval multisecond maupun pada milidetik (fast flicker). Karena etcd mendukung secara dinamis mengubah jumlah komponen, kami menambahkan dan menghapus secara acak node selama pengujian.

Beban uji termasuk register, set, dan tes transaksional untuk memeriksa operasi pada KV, serta beban khusus untuk kunci dan jam tangan.

2.1 Daftar

Untuk mengevaluasi keandalan etcd selama operasi KV, tes register dikembangkan selama operasi baca, tulis, perbandingan , dan set dilakukan secara acak pada kunci unit. Hasilnya dievaluasi menggunakan alat linearizability Knossos menggunakan model register perbandingan / instalasi dan informasi versi.

2.2 Kumpulan

Untuk mengukur bacaan basi, tes dikembangkan yang menggunakan transaksi perbandingan dan set untuk membaca satu set bilangan bulat dari kunci tunggal dan kemudian menambahkan nilai ke set ini. Selama pengujian, kami juga melakukan pembacaan paralel seluruh set. Setelah selesai ujian, hasilnya dianalisis untuk terjadinya kasus ketika elemen, yang dikenal menjadi hadir di set, tidak hadir dalam hasil membaca. Kasus-kasus ini digunakan untuk mengukur bacaan basi dan kehilangan pembaruan.

2.3 Tambahkan Uji

Untuk memverifikasi serializability ketat, uji append dikembangkan selama transaksi dibaca secara paralel dan nilai tambah ke daftar yang terdiri dari set unik bilangan bulat. Setiap daftar disimpan dalam satu kunci etcd, dan penambahan dibuat dalam setiap transaksi, membaca setiap kunci yang perlu diubah dalam satu transaksi, dan kemudian kunci-kunci ini ditulis dan pembacaan dilakukan dalam transaksi kedua, yang dilindungiuntuk memastikan bahwa tidak ada kunci yang direkam telah berubah sejak pembacaan pertama. Di akhir pengujian, kami merencanakan hubungan antara transaksi berdasarkan prioritas waktu nyata dan hubungan operasi baca dan tambah. Memeriksa grafik ini untuk loop memungkinkan untuk menentukan apakah operasi itu serializable.

Sementara etcd mencegah transaksi dari penulisan kunci yang sama beberapa kali, Anda dapat membuat transaksi hingga satu catatan per kunci. Kami juga memastikan bahwa operasi baca dalam transaksi yang sama mencerminkan operasi penulisan sebelumnya dari transaksi yang sama.

2.4 Kunci

Sebagai layanan koordinasi, etcd menjanjikan dukungan bawaan untuk penguncian yang didistribusikan . Kami menyelidiki kunci ini dengan dua cara. Pada awalnya, permintaan penguncian dan pembukaan kunci secara acak dihasilkan , menerima sewa untuk setiap kunci dan membiarkannya terbuka menggunakan klien dll bawaan di klien Java keepalivehingga dirilis . Kami menguji hasilnya dengan Knossos untuk melihat apakah mereka membentuk implementasi linear dari layanan kunci.

Untuk pengujian yang lebih praktis (dan untuk menghitung frekuensi kegagalan kunci), kami menggunakan kunci dan lain-lain untuk mengatur pengecualian bersama saat melakukan pembaruan pada set di memori.dan mencari pembaruan yang hilang di set ini. Tes ini memungkinkan kami untuk secara langsung mengkonfirmasi apakah sistem yang menggunakan dll sebagai mutex dapat dengan aman memperbarui keadaan internal.

Versi ketiga dari uji penguncian melibatkan penjaga pada kunci sewaan untuk memodifikasi set yang disimpan di etcd.

2.5 Pelacakan

Untuk memverifikasi bahwa arloji memberikan informasi tentang setiap pembaruan kunci, satu kunci dibuat sebagai bagian dari pengujian dan nilai integer unik yang ditetapkan secara buta . Sementara itu, pelanggan membagikan kunci ini selama beberapa detik setiap kalinya. Setiap kali setelah inisiasi arloji, klien mulai dengan revisi yang telah dihentikannya terakhir kali.

Di akhir proses ini, kami memastikan bahwa setiap klien mengamati urutan perubahan kunci yang sama.

3. Hasil

3.1 Pelacakan dari revisi ke-0

Saat melacak kunci, klien dapat menentukan revisi awal , yang merupakan "revisi opsional yang memulai pelacakan (secara inklusif)". Jika pengguna ingin melihat setiap operasi dengan kunci tertentu, ia dapat menentukan revisi pertama dlld. Apa audit ini? Model data dan glosarium tidak memberikan jawaban untuk pertanyaan ini; revisi digambarkan sebagai penghitung 64-bit yang monoton, tetapi tidak jelas apakah etcd dimulai pada 0 atau 1. Adalah masuk akal untuk mengasumsikan bahwa penghitungan mundur dari awal (untuk berjaga-jaga).

Sayangnya, ini salah. Meminta revisi ke-0 menyebabkan etcd untuk memulai pembaruan penyiaran, dimulai dengan revisi saat ini di server plus satu, tetapi tidak dengan yang pertama. Permintaan untuk revisi pertama memberikan semua perubahan. Perilaku ini tidak didokumentasikan di mana pun .

Kami percaya bahwa dalam praktiknya, kehalusan ini tidak akan mengarah pada masalah dalam produksi, karena sebagian besar kelompok tidak bertahan pada revisi pertama. Selain itu, etcd memampatkan cerita dari waktu ke waktu, jadi dalam aplikasi dunia nyata, kemungkinan besar, dalam hal apa pun, itu tidak memerlukan membaca semua versi, dimulai dengan revisi pertama. Perilaku seperti itu dibenarkan, tetapi tidak ada salahnya deskripsi yang sesuai dalam dokumentasi.

3.2 Kunci mitis

Dokumentasi API untuk kunci menyatakan bahwa kunci yang dikunci "dapat digunakan bersama dengan transaksi untuk memastikan bahwa pembaruan di etcd hanya terjadi ketika kunci dimiliki." Aneh, tetapi tidak memberikan jaminan apa pun untuk kunci itu sendiri dan tujuannya tidak dijelaskan.

Namun, dalam bahan lain, pengelola dll masih berbagi informasi tentang penggunaan kunci. Misalnya, pengumuman rilis etcd 3.2 menjelaskan aplikasi etcdctluntuk memblokir perubahan berbagi file pada disk. Selain itu, dalam masalah pada GitHub dengan pertanyaan tentang tujuan khusus kunci, salah satu pengembang etcd menjawab yang berikut:

etcd , ( ) , ( etcd), - :

etcd;
- ( , etcd);
.

Contoh seperti itu diberikan etcdctl: kunci digunakan untuk melindungi tim put, tetapi tidak mengikat kunci untuk pembaruan.

Sayangnya, ini tidak aman karena memungkinkan banyak klien untuk secara bersamaan memegang kunci yang sama. Masalahnya diperburuk oleh penangguhan proses, crash jaringan atau partisi, namun, hal itu juga dapat terjadi pada cluster yang benar-benar sehat tanpa kegagalan eksternal. Misalnya, dalam uji coba ini , proses nomor 3 berhasil mengatur kunci, dan proses 1 mendapatkan kunci yang sama secara paralel bahkan sebelum proses 3 memiliki kesempatan untuk menghapusnya:

Pelanggaran mutex paling terlihat pada sewa dengan TTL pendek: TTL 1, 2, dan 3 detik tidak dapat memberikan pengecualian bersama setelah hanya beberapa menit pengujian (bahkan dalam kelompok sehat). Penangguhan proses dan partisi jaringan menyebabkan masalah lebih cepat.

Dalam salah satu varian kunci-tes kami, mutex dlld digunakan untuk melindungi pembaruan bersama dari satu set integer (seperti yang ditunjukkan oleh dokumentasi, dlld). Setiap pembaruan membaca nilai sampel dalam memori saat ini, dan, setelah sekitar satu detik, menulis koleksi ini kembali dengan penambahan elemen unik. Dengan sewa dengan TTL dua detik, lima proses paralel, dan proses berhenti setiap lima detik, kami dapat menyebabkan hilangnya sekitar 18% dari pembaruan yang dikonfirmasi.

Masalah ini diperburuk oleh mekanisme penguncian internal di etcd. Jika klien menunggu klien lain untuk membukanya, kehilangan sewa, dan setelah itu kunci dilepaskan, server tidak memeriksa ulang sewa untuk memastikan bahwa itu masih berlaku sebelum memberi tahu klien bahwa kunci sekarang ada di belakangnya.

Dimasukkannya cek sewa tambahan, serta pemilihan TTL yang lebih lama dan pengaturan waktu tunggu pemilihan yang cermat , akan mengurangi frekuensi masalah ini. Namun, pelanggaran mutex tidak dapat sepenuhnya dihilangkan, karena kunci yang didistribusikan pada dasarnya tidak aman dalam sistem asinkron. Martin Kleppmann dengan meyakinkan menggambarkan hal ini dalam artikelnyaTentang kunci yang didistribusikan. Menurutnya, layanan pemblokiran harus mengorbankan kebenaran untuk menjaga kelangsungan dalam sistem asinkron: jika proses macet saat mengontrol pemblokiran, layanan pemblokiran perlu beberapa cara untuk memaksa pemblokiran dibuka. Namun, jika proses sebenarnya tidak jatuh, tetapi hanya berjalan lambat atau tidak tersedia untuk sementara waktu, membuka kunci itu dapat menyebabkannya ditahan di beberapa tempat pada saat yang sama.

Tetapi bahkan jika layanan pemblokiran terdistribusi menggunakan, katakanlah, semacam detektor kegagalan sihir dan benar-benar dapat menjamin pengecualian bersama, dalam kasus beberapa sumber daya non-lokal, penggunaannya masih akan tidak aman. Misalkan proses A mengirim pesan ke database D sambil memegang kunci. Setelah itu, proses A macet, dan proses B menerima kunci dan juga mengirim pesan ke pangkalan D. Masalahnya adalah bahwa pesan dari proses A (karena asinkron) dapat muncul setelah pesan dari proses B, melanggar saling pengecualian bahwa kunci itu seharusnya menyediakan. .

Untuk mencegah masalah ini, perlu bergantung pada fakta bahwa sistem penyimpanan itu sendiri akan mendukung kebenaran transaksi atau, jika layanan penguncian menyediakan mekanisme seperti itu, gunakan“ Anggar” tanda yang akan dimasukkan dalam semua operasi yang dilakukan oleh pemegang kunci. Ini akan memastikan bahwa tidak ada operasi dari pemegang kunci sebelumnya yang terjadi secara tiba-tiba di antara operasi pemilik kunci saat ini. Misalnya, dalam layanan pemblokiran Chubby Google , token ini disebut sequencer . Di etcd, Anda dapat menggunakan revisi kunci kunci sebagai token pemblokiran yang dipesan secara global.

Selain itu, kunci kunci di etcd dapat digunakan untuk melindungi pembaruan transaksional di etcd itu sendiri. Memeriksa versi kunci kunci sebagai bagian dari transaksi, pengguna dapat mencegah transaksi jika kunci tidak lagi ditahan (mis. versi kunci kunci lebih besar dari nol). Dalam pengujian kami, pendekatan ini memungkinkan kami untuk berhasil mengisolasi operasi baca-modifikasi-tulis di mana penulisan adalah satu-satunya transaksi yang dilindungi oleh penguncian. Pendekatan ini menyediakan isolasi yang mirip dengan token rentetan, tetapi (seperti token rentetan) tidak menjamin keaslian: suatu proses dapat crash atau kehilangan mutex selama pembaruan yang terdiri dari banyak operasi, meninggalkan dll dalam keadaan tidak konsisten secara logis.

Hasil pekerjaan dalam masalah proyek:

Jam tangan dimulai pada revisi 0 mulai nanti - tidak diputuskan;
Kunci kembali setelah memblokir tanpa memeriksa kepemilikan - master;
Kunci tidak didokumentasikan sebagai tidak aman - tidak terpecahkan.

4. Diskusi

Dalam pengujian kami, dll. 3.4.3 memenuhi ekspektasi mengenai operasi KV: kami mengamati konsistensi yang sangat serializable dari transaksi baca, tulis, dan bahkan multi-key, terlepas dari penangguhan proses, kerusakan, manipulasi jam dan jaringan, serta perubahan dalam jumlah anggota cluster . Perilaku serializable ketat diimplementasikan secara default dalam operasi KV; kinerja pembacaan dengan serializableset bendera menyebabkan tampilan basi basi (seperti yang dijelaskan dalam dokumentasi).

Monitor (jam tangan) berfungsi dengan benar - setidaknya pada masing-masing tombol. Sampai kompresi sejarah menghancurkan data lama, arloji berhasil mengeluarkan setiap pembaruan kunci.

Namun, ternyata kunci di etcd (seperti semua kunci yang didistribusikan) tidak memberikan pengecualian bersama. Proses yang berbeda dapat menahan kunci pada saat yang sama - bahkan dalam kelompok sehat dengan jam yang disinkronkan dengan sempurna. Dokumentasi dengan API penguncian tidak mengatakan apa-apa tentang ini, dan contoh-contoh kunci yang disajikan tidak aman. Namun, beberapa masalah dengan kunci harus dilakukan setelah rilis patch ini .

Sebagai hasil dari kolaborasi kami, tim etcd membuat sejumlah amandemen pada dokumentasi (mereka telah muncul di GitHub dan akan diterbitkan dalam versi masa depan situs web proyek). Halaman GitHub Warranties API sekarang menyatakan bahwa secara default etcd benar - benar serializabledan klaim bahwa serial dan serializable adalah tingkat konsistensi terkuat yang tersedia dalam sistem terdistribusi telah dihapus. Berkenaan dengan revisi, sekarang ditunjukkan bahwa awal harus dari unit (1) , meskipun dokumentasi API masih tidak mengatakan bahwa upaya untuk memulai dari revisi ke-0 akan menghasilkan "keluaran peristiwa yang terjadi setelah revisi saat ini ditambah 1" alih-alih "pengiriman semua acara" yang diharapkan. Dokumentasi masalah keamanan kunci sedang dikembangkan .

Beberapa perubahan dokumentasi, seperti menggambarkan perilaku khusus etcd ketika mencoba membaca, dimulai dengan revisi nol, masih memerlukan perhatian.

Seperti biasa, kami menekankan bahwa Jepsen lebih memilih pendekatan eksperimental untuk verifikasi keamanan: kami dapat mengkonfirmasi keberadaan bug, tetapi tidak adanya mereka. Berbagai upaya sedang dilakukan untuk menemukan masalah, tetapi kami tidak dapat membuktikan kebenaran umum dari dll.

4.1 Rekomendasi

Jika Anda menggunakan kunci di etcd, pikirkan apakah Anda memerlukannya untuk keamanan atau hanya untuk meningkatkan kinerja dengan secara probabilistik membatasi konkurensi. Kunci etcd dapat digunakan untuk meningkatkan kinerja, tetapi menggunakannya untuk tujuan keamanan bisa berisiko.

Secara khusus, jika Anda menggunakan kunci etcd untuk melindungi sumber daya bersama seperti file, database atau layanan, sumber daya ini harus menjamin keamanan tanpa memblokir. Salah satu cara untuk mencapai ini adalah dengan menggunakan token rentetan monoton . Mungkin, misalnya, revisi dlld terkait dengan kunci kunci yang dimiliki saat ini. Sumber daya bersama harus memastikan bahwa setelah klien menggunakan tokenyuntuk melakukan beberapa operasi, operasi apa pun dengan token x < yakan ditolak. Pendekatan ini tidak memastikan atomicity, tetapi tidak menjamin bahwa operasi dalam kerangka penguncian dilakukan secara berurutan, dan tidak sebentar-sebentar.

Kami menduga bahwa pengguna biasa tidak mungkin mengalami masalah ini. Tetapi jika Anda tetap mengandalkan membaca semua perubahan dari etcd, dimulai dengan revisi pertama, ingat bahwa Anda harus melewati 1, bukan 0 sebagai parameter. Eksperimen kami menunjukkan bahwa revisi nol dalam hal ini berarti "revisi saat ini", dan tidak "Paling awal."

Akhirnya, kunci dan lain-lain (seperti semua kunci yang didistribusikan) menyesatkan pengguna: mereka mungkin ingin menggunakannya sebagai kunci biasa, tetapi mereka akan sangat terkejut ketika mereka menyadari bahwa kunci ini tidak memberikan saling pengecualian. Dokumentasi API, posting blog, masalah di GitHub tidak mengatakan apa-apa tentang risiko ini. Kami menyarankan Anda memasukkan informasi dalam dokumentasi dlld yang mengunci tidak memberikan pengecualian bersama dan memberikan contoh penggunaan token rentetan untuk memperbarui status sumber daya bersama, bukan contoh yang dapat menyebabkan hilangnya pembaruan.

4.2 Rencana selanjutnya

Proyek etcd telah dianggap stabil selama beberapa tahun: algoritma Raft berdasarkan itu telah bekerja dengan baik, API untuk operasi KV sederhana dan mudah. Meskipun beberapa fitur tambahan baru-baru ini menerima API baru, semantiknya relatif sederhana. Kami percaya bahwa kami telah mempelajari cukup perintah dasar seperti getdan put, transaksi, pemblokiran, dan pelacakan. Namun, ada tes lain yang harus dilakukan.

Saat ini, kami belum melakukan penilaian penghapusan yang cukup terperinci .: Mungkin ada kasus batas yang terkait dengan versi dan revisi, ketika objek terus-menerus dibuat dan dihapus. Dalam pengujian di masa mendatang, kami bermaksud melakukan operasi pemindahan dengan studi yang lebih hati-hati. Kami juga tidak menguji kueri rentang atau melacak operasi dengan beberapa kunci, meskipun kami menduga semantik mereka mirip dengan operasi dengan kunci tunggal.

Dalam tes, kami menggunakan suspensi proses, crash, manipulasi dengan jam, jaringan dibagi dan komposisi cluster berubah; di belakang layar ada masalah seperti kerusakan disk dan kegagalan Bizantium lainnya di tingkat satu node. Peluang ini dapat dieksplorasi dalam penelitian masa depan.

Pekerjaan itu didukung oleh Cloud Native Computing Foundation., bagian dari The Linux Foundation , dan mematuhi kebijakan etika Jepsen . Kami ingin mengucapkan terima kasih kepada tim etcd atas bantuan mereka, dan perwakilan berikut khususnya: Chris Aniszczyk, Gyuho Lee, Xiang Li, Hitoshi Mitake, Jingyi Hu dan Brandon Philips.

etcd 3.4.3: penelitian keandalan dan penyimpanan penyimpanan