Flynn: Cara yang tepat untuk melakukan perawatan

Saya pikir poin Anda mengarah ke arah yang sama dengan komentar saya di sini #3104.

Sementara Flynn tidak secara resmi diberi label sebagai siap produksi, stabilitas dan pemulihan secara keseluruhan adalah hal yang sangat penting untuk membawanya ke lingkungan produksi. Jika keadaan menurun, itu bagus untuk memiliki platform Anda (Flynn) mendukung Anda dan mencoba yang terbaik untuk pulih secara otomatis.

Flynn memang menyertakan beberapa kemampuan untuk memperbaiki dirinya sendiri jika ada yang berbentuk buah pir atau mati total seperti yang Anda temukan setelah me-reboot cluster. Sayangnya pekerjaan ini belum selesai dan tidak agresif seperti yang diharapkan, yang paling penting tidak mengambil tindakan ketika kurang dari set awal bootstrap rekan tidak tersedia. Ini tidak ideal tetapi digabungkan dengan pembatasan ini untuk mencegahnya membuat cluster yang mengalami masalah menjadi lebih buruk. Yang mengatakan kode tersebut telah terbukti cukup andal dan kami mungkin akan segera mencabut batasan itu ketika kami dapat menemukan beberapa heuristik yang lebih baik ketika kode pemulihan/kebangkitan cluster harus mengambil tindakan.

Adapun tugas yang tidak diseimbangkan kembali setelah node diganti, ini adalah masalah yang diketahui dan sesuatu yang ingin kami atasi.

Saya tidak yakin tetapi saya tidak berpikir flynn-host benar-benar mengakhiri tugas ketika itu dimatikan/dihentikan. Saya tidak yakin apa yang akan menjadi perilaku yang diinginkan di sini karena kami menggunakan kemampuan ini untuk mendukung pembaruan dan sejenisnya. @lmars mungkin bisa menguraikan bagian depan itu.

Terima kasih telah menguji hal ini, kami serius membuat pemulihan/kebangkitan cluster yang kuat.

@bbaptist

Namun, saya tidak melihat layanan pemindahan penjadwal yang digandakan pada host lain kembali ke Host yang dipulihkan, misalnya 2 server postgres berjalan pada 1 host

Saat ini penjadwal tidak akan mematikan pekerjaan kecuali jika secara eksplisit diperintahkan untuk melakukannya. Ini murni untuk stabilitas, jika ada yang tidak beres saat memindahkan pekerjaan maka ada operator di sekitar untuk men-debug masalah yang sebenarnya (yaitu seseorang di sana secara eksplisit mencoba memindahkan pekerjaan), daripada penjadwal yang mencoba memindahkan barang pada katakanlah jam 3 pagi dan mengebor sebuah cluster.

Kami berencana untuk mengubah ini di masa depan untuk menyeimbangkan kembali (#2101), tetapi kami membutuhkan pengujian dan pemahaman yang lebih baik tentang efek samping, sehingga banyak mengutak-atik manual dan laporan seperti ini sangat membantu : smile:.

Setelah waktu yang cukup lama saya pergi ke Host yang menjalankan 2 postgres dan menghentikan layanan flynn-Host. Ini gagal menghentikan semua pekerjaan yang berjalan di host.

flynn-host _should_ menghentikan semua pekerjaan saat dimatikan (lihat di sini ), pekerjaan apa yang tersisa setelah menghentikan flynn-host ? Dan bagaimana Anda menghentikannya ( SIGTERM / SIGKILL )?

@josephglanville

yang paling penting itu tidak mengambil tindakan ketika kurang dari set awal rekan bootstrap tidak tersedia. Ini tidak ideal tetapi digabungkan dengan pembatasan ini untuk mencegahnya membuat cluster yang mengalami masalah menjadi lebih buruk.

Jadi jika saya menguji kluster 6 node, tindakan apa yang akan diambil saat melakukan pemeliharaan pada masing-masing node tersebut? Artinya ada minimal jumlah host yang bisa melakukan maintenance?

Adapun tugas yang tidak diseimbangkan kembali setelah node diganti, ini adalah masalah yang diketahui dan sesuatu yang ingin kami atasi

Ini sepertinya situasi ide untuk flynn-host fix untuk diatasi, atau saya mungkin flynn-host rebalance .

@lmars

Kami berencana untuk mengubah ini di masa depan untuk menyeimbangkan kembali (#2101), tetapi kami membutuhkan pengujian dan pemahaman yang lebih baik tentang efek sampingnya, sehingga banyak mengutak-atik manual dan laporan seperti ini sangat membantu

Flynn saat ini menangani migrasi ke status tidak seimbang, pengujian apa yang Anda perlukan untuk migrasi kembali ke status seimbang?

pekerjaan apa yang tersisa setelah menghentikan flynn-host ?

Saya cukup yakin itu controller dan discoverd tapi saya tidak yakin. Saya dapat menguji lagi hari ini dan melihat apakah saya dapat mereproduksi keadaan itu.

Dan bagaimana Anda menghentikannya ( SIGTERM / SIGKILL )?

Saya melakukan service flynn-host stop . Pemikiran saya adalah bahwa pekerjaan Pemula akan memiliki cara yang anggun untuk mematikan tugas. Ini juga akan menjadi metode yang akan digunakan oleh shutdown atau reboot yang anggun.

@bbaptist

Flynn saat ini menangani migrasi ke status tidak seimbang, pengujian apa yang Anda perlukan untuk migrasi kembali ke status seimbang?

Kami akan menginginkan beberapa tes integrasi yang ketat (misalnya menjatuhkan node, menunggu keseimbangan kembali, menambahkan node, menunggu keseimbangan kembali, memeriksa pekerjaan), tetapi saat ini kami tidak memiliki lingkungan CI yang cukup fleksibel untuk melakukan ini dengan mudah (kami memiliki rencana peningkatan #2970).

Penjadwal juga saat ini tidak memeriksa kesehatan pekerjaan, itu hanya memulai kembali pekerjaan apa pun yang diketahuinya harus dijalankan. Dengan penyeimbangan kembali, itu perlu memastikan pekerjaan baru berfungsi dengan benar di simpul baru sebelum mematikan pekerjaan yang ada sehingga tidak memperburuk keadaan. Ini akan membutuhkan beberapa restrukturisasi (logika itu saat ini tinggal di pekerja penyebaran).

pekerjaan apa yang tersisa setelah menghentikan flynn-host?

Saya cukup yakin itu pengontrol dan ditemukan tetapi saya tidak positif. Saya dapat menguji lagi hari ini dan melihat apakah saya dapat mereproduksi keadaan itu.

Oke Flynn versi berapa ini? Kami membuat beberapa perbaikan baru-baru ini untuk menghentikan pemblokiran pengontrol saat shutdown (#3014) sehingga kemungkinan Anda tidak memiliki perbaikan itu dan pengontrol bertahan lebih lama dari flynn-host diberikan untuk menunggu sampai berhenti (dan ditemukan adalah terbunuh terakhir, jadi itu akan menjelaskan mengapa itu tidak mati juga).

@lmars

Penjadwal juga saat ini tidak memeriksa kesehatan pekerjaan, itu hanya memulai kembali pekerjaan apa pun yang diketahuinya harus dijalankan. Dengan penyeimbangan kembali, itu perlu memastikan pekerjaan baru berfungsi dengan benar di simpul baru sebelum mematikan pekerjaan yang ada sehingga tidak memperburuk keadaan.

Area ini adalah titik sakit saya berikutnya dengan Flynn. Saat ini kami melihat cluster merah/hijau lebar untuk status. Idealnya, kami dapat menelusuri apa yang dilihat tuan rumah untuk setiap pekerjaan Flynn.

Oke Flynn versi berapa ini?

Versi terbaru yang dirilis: v20160624.1. Bagaimana cara saya menguji versi terbaru?

Bagaimana cara saya menguji versi terbaru?

Anda dapat menginstal dan berlangganan Flynn versi malam dengan meneruskan --channel nightly ke skrip instalasi:

sudo bash /path/to/install-flynn --channel nightly

Menguji v20160712.0

Saya melakukan service flynn-host stop pada satu node di 3 node cluster. Semua pekerjaan berhasil dihentikan. Pekerjaan dipulihkan pada host yang tersisa di cluster. Saya kemudian melakukan service flynn-host start , mensimulasikan bahwa saya me-restart Host. Itu bergabung kembali dengan cluster dan pekerjaan dimulai dengan sukses.

Saya kemudian pergi ke Host yang bukan pemimpin postgresql. Saya melakukan service flynn-host stop pada host itu. Semua pekerjaan kecuali discoverd berhasil dihentikan. Berikut adalah collect-debug-info Intisari dalam keadaan itu: https://Gist.github.com/6490b2fcd2330b831eec4755c9e19ffa. Semua pekerjaan muncul dengan sukses di 2 host lainnya. Cluster bekerja dengan benar. Saya kemudian me-reboot Host dengan pekerjaan yang macet. Segera setelah itu host turun flynn-host ps pada host yang telah up sepanjang waktu menunjukkan tidak ada pekerjaan yang berjalan di host tersebut. Setelah beberapa saat, semua pekerjaan mulai muncul untuk host itu lagi. Inilah collect-debug-info dari Host itu selama ini: https://Gist.github.com/7ba79f4140b60e32073c4294b26d450f

Mesin yang di-boot ulang tidak akan muncul kembali. Saya menginstal ulang Flynn dan menggabungkannya ke cluster. Itu bergabung dan bekerja. Saya kemudian pindah ke mematikan server Flynn yang tersisa. Saya melakukan service flynn-host stop pada host itu. Sekarang ada dua aplikasi yang masih berjalan discoverd dan flynn-controller . Saya harus mematikan dua proses sebelum saya bisa mendapatkan collect-debug-info dari status ini: https://Gist.github.com/0ed75c23d6d4327650e3a0a03d309049. Saya perhatikan juga bahwa ketika flanel berhenti, itu tidak menghapus jaringan flannel.1, atau mematikan antarmuka flynnbr0. Karena saya membunuh proses Flynn alih-alih reboot, saya baru saja melakukan service flynn-host start . Dari sini bergabung kembali.

Menjalankan sudo flynn-host fix --min-hosts 3
INFO[07-14|17:28:38] menemukan host yang diharapkan n=3
INFO[07-14|17:28:38] memastikan penemuan berjalan di semua host
INFO[07-14|17:28:38] memeriksa kain flanel
INFO[07-14|17:28:38] kain flanel terlihat bagus
INFO[07-14|17:28:38] menunggu penemuan tersedia
INFO[07-14|17:28:38] memeriksa untuk menjalankan API pengontrol
INFO[07-14|17:28:38] ditemukan menjalankan instance API pengontrol n=2
INFO[07-14|17:28:38] menemukan instance pengontrol, memeriksa formasi kritis
INFO[07-14|17:28:38] memeriksa status database sirenia
INFO[07-14|17:28:38] memeriksa status basis data db=postgres
INFO[07-14|17:28:38] memeriksa status cluster sirenia fn=FixSirenia service=postgres
INFO[07-14|17:28:38] ditemukan menjalankan pemimpin fn=FixSirenia service=postgres
INFO[07-14|17:28:38] ditemukan menjalankan instance fn=FixSirenia service=postgres count=3
INFO[07-14|17:28:38] mendapatkan status sirenia fn=FixSirenia service=postgres
INFO[07-14|17:28:38] cluster mengklaim sebagai read-write fn=FixSirenia service=postgres
INFO[07-14|17:28:38] memeriksa status basis data db=mariadb
INFO[07-14|17:28:38] memeriksa status cluster sirenia fn=FixSirenia service=mariadb
INFO[07-14|17:28:38] ditemukan menjalankan pemimpin fn=FixSirenia service=mariadb
INFO[07-14|17:28:38] menemukan instance yang sedang berjalan fn=FixSirenia service=mariadb count=3
INFO[07-14|17:28:38] mendapatkan status sirenia fn=FixSirenia service=mariadb
INFO[07-14|17:28:38] cluster mengklaim sebagai read-write fn=FixSirenia service=mariadb
INFO[07-14|17:28:38] memeriksa status basis data db=mongodb
INFO[07-14|17:28:38] memeriksa status cluster sirenia fn=FixSirenia service=mongodb
INFO[07-14|17:28:38] tidak ada pemimpin yang berjalan fn=FixSirenia service=mongodb
INFO[07-14|17:28:38] menemukan instance yang sedang berjalan fn=FixSirenia service=mongodb count=3
INFO[07-14|17:28:38] mendapatkan status sirenia fn=FixSirenia service=mongodb
INFO[07-14|17:28:38] mendapatkan layanan metadata fn=FixSirenia service=mongodb
INFO[07-14|17:28:38] mendapatkan info pekerjaan utama fn=FixSirenia service=mongodb job.id=ieflynn16071302.iexposure.com-2554aa98-0afa-4c37-8ead-5eddc8b50bd4
EROR[07-14|17:28:38] tidak dapat memperoleh info pekerjaan utama fn=FixSirenia service=mongodb
INFO[07-14|17:28:38] mendapatkan info pekerjaan sinkronisasi fn=FixSirenia service=mongodb job.id=ieflynn16071301.iexposure.com-f4ebf9e9-5f5d-41ef-ab82-c2ce47bdfd3b
INFO[07-14|17:28:38] menghentikan instance sirene yang belum ditetapkan fn=FixSirenia service=mongodb
INFO[07-14|17:28:39] memulai pekerjaan utama fn=FixSirenia service=mongodb job.id=ieflynn16071301.iexposure.com-33feef81-212a-4db3-941f-cdd84b814cb4
INFO[07-14|17:28:41] memulai pekerjaan sinkronisasi fn=FixSirenia service=mongodb job.id=ieflynn16071300.iexposure.com-00aef22e-cef9-468f-99ea-a28385cb996f
INFO[07-14|17:28:41] menunggu contoh untuk memulai fn=FixSirenia service=mongodb job.id=ieflynn16071301.iexposure.com-33feef81-212a-4db3-941f-cdd84b814cb4
INFO[07-14|17:28:41] menunggu cluster muncul baca-tulis fn=FixSirenia service=mongodb`
17:33:43.220895 host.go:153: batas waktu menunggu status yang diharapkan

Hasil yang sama dengan flynn-host fix --min-hosts 3 . Saya tidak menggunakan mongodb.

Saya mencoba untuk me-reboot Host terakhir tempat saya mematikan pekerjaan. Itu terlalu terkunci saat boot dan saya tidak bisa menyelesaikannya untuk menyelesaikan boot. Itu berhenti selama init tanpa kesalahan. Saya menggunakan kumpulan ZFS untuk flynn-default seperti yang direkomendasikan. Mungkin ada hubungannya dengan Flynn yang tidak melepas volume?

Saya tidak melihat cara untuk memiliki cluster yang konsisten setelah pemeliharaan sistem Host dengan Flynn dalam kondisi saat ini.

Oke, sepertinya ada beberapa hal yang mungkin harus saya lihat di sini.

Yang pertama adalah mengapa discoverd berhenti. Sayangnya collect-debug-info tidak mengambil log untuk pekerjaan itu jadi saya harus mencoba mereplikasi itu secara manual kecuali Anda masih memiliki host itu dan bisa mendapatkan log dari /var/log/flynn/0453517f-f905-43b6-921e-2a29856a596c.log .

Setelah Anda menginstal ulang host Anda tidak mempromosikan node pengganti ke anggota cluster konsensus sehingga toleransi kesalahan cluster kemudian terganggu. Sayangnya alasan mengapa Anda mungkin tidak melakukan ini ada pada kami, kami baru saja menggabungkan fungsi itu dan belum mengirimkan dokumen untuk itu. Saya melakukan itu sekarang namun.
Saya ingin tahu apa yang Anda maksud dengan tidak akan muncul kembali, apakah host itu sendiri tidak dapat dihidupkan kembali atau Anda tidak dapat memulai flynn-host ?

Alasan untuk pemadaman kecil flynn-host ps saat Anda menghapus simpul itu adalah karena 10.10.142.92 adalah pemimpin Raft. Menjatuhkannya menyebabkan pemilihan Raft berlangsung dengan 10.10.142.90 menjadi pemimpin baru. Blip ini diharapkan tetapi tidak akan bertahan lama.

Saya bingung tentang set log terakhir. Apakah Anda menjalankan collect-debug-info pada host yang berbeda dengan yang Anda reboot/instal ulang/reboot? IP yang dilaporkan dari ifconfig menyiratkan bahwa itu benar-benar dijalankan pada anggota stabil terakhir dari cluster 10.10.142.91 .

Apakah flynn-Host memperbaiki kesalahan karena tidak dapat memperbaiki MongoDB? Seharusnya terus berlanjut meskipun tidak dapat membuat kemajuan dengan MongoDB karena ini adalah komponen yang tidak penting untuk pemulihan.
Pemecah masalah benar-benar melaporkan bahwa cluster itu baik-baik saja (yang tampaknya seperti yang ditunjukkan oleh log, seperti

Adapun masalah reboot/hang .. kami belum pernah mengamati ini sebelumnya. Flynn tidak melakukan banyak/jika-sesuatu yang mewah pada lapisan itu selain menggunakan ZFS.

Jadi kita perlu:

• Selidiki masalah dengan penemuan/pengontrol yang tidak keluar saat menghentikan flynn-host
• Dokumen mempromosikan/menurunkan dan kekhawatiran klaster konsensus umum
• Selidiki impor kumpulan ZFS saat boot, periksa apakah kami menggunakan atribut automount ZFS

Terima kasih atas laporan terperinci Anda, saya akan mulai melihat hal ini segera.

Saya ingin tahu apa yang Anda maksud dengan tidak akan muncul kembali, apakah host itu sendiri tidak dapat dihidupkan kembali atau apakah Anda tidak dapat membuat flynn-host untuk memulai?

Ketiga host macet pada saat ini setelah saya mencoba me-reboot semuanya. Saya bahkan meninggalkan mereka semalaman dengan harapan mereka akan melakukan kesalahan pada sesuatu.

Sayangnya kumpulkan-debug-info tidak mengambil log untuk pekerjaan itu jadi saya harus mencoba mereplikasi itu secara manual kecuali Anda masih memiliki Host itu di sekitar dan bisa mendapatkan log dari /var/log/flynn/0453517f-f905 -43b6-921e-2a29856a596c.log.

Ini file lognya.
0453517f-f905-43b6-921e-2a29856a596c.log.txt

Saya bingung tentang set log terakhir. Apakah Anda menjalankan collect-debug-info pada host yang berbeda dengan yang Anda reboot/instal ulang/reboot? IP yang dilaporkan dari ifconfig menyiratkan bahwa itu benar-benar dijalankan pada anggota stabil terakhir dari cluster 10.10.142.91.

Saya menyadari setelah saya memposting ini, saya seharusnya memanggil tuan rumah dengan nama. collect-debug-info itu dijalankan setelah mematikan flynn-host pada server terakhir yang tersisa untuk dikerjakan, yaitu-flynn-16071301. Ketika saya melakukan service flynn-host stop pada Host itu, pekerjaan discoverd dan flynn-controller harus dimatikan, lalu saya menjalankan collect-debug-info pada Host itu.

Masalah yang ditemukan telah ditemukan dan diperbaiki di #3467. Apakah ada masalah yang tersisa di sini?

Saya pikir masalah lain yang saya identifikasi telah diperbaiki.
Dokumentasi tentang promosi/turunkan dapat ditemukan di sini: https://flynn.io/docs/production#replaceing -hosts