Cloister → pengurusan kluster OTP yang mudah

Hampir setiap aplikasi perniagaan yang berjaya lambat laun memasuki fasa di mana penskalaan mendatar diperlukan. Dalam kebanyakan kes, anda hanya boleh memulakan contoh baharu dan mengurangkan purata beban. Tetapi terdapat juga kes yang kurang remeh di mana kita perlu memastikan bahawa nod yang berbeza mengetahui satu sama lain dan mengagihkan beban kerja dengan teliti.

Ternyata sangat bertuah erlang, yang kami pilih untuk sintaks yang menyenangkan dan gembar-gembur di sekelilingnya, mempunyai kelas pertama sokongan untuk sistem teragih. Secara teori, ini kelihatan remeh:

Mesej yang dihantar antara proses pada nod yang berbeza, serta antara pautan dan monitor, adalah telus […]

Dalam amalan, segala-galanya sedikit lebih rumit. Diedarkan erlang telah dibangunkan apabila "bekas" bermaksud kotak besi besar untuk penghantaran, dan "docker" hanyalah sinonim untuk longshoreman. DALAM IP4 terdapat banyak alamat yang tidak berpenghuni, gangguan rangkaian biasanya disebabkan oleh tikus yang mengunyah kabel, dan purata masa operasi sistem pengeluaran diukur dalam beberapa dekad.

Kini kita semua sangat berdikari, dibungkus dan diedarkan erlang dalam persekitaran di mana alamat IP dinamik diedarkan berdasarkan prinsip rawak yang hebat, dan nod boleh muncul dan hilang mengikut kehendak tumit kiri penjadual. Untuk mengelakkan longgokan kod boilerplate dalam setiap projek menjalankan distributed erlang, untuk memerangi persekitaran yang bermusuhan, bantuan diperlukan.

Nota: Saya sedar ada libcluster. Ia benar-benar keren, ia mempunyai lebih seribu bintang, pengarangnya terkenal dalam masyarakat, dan semua itu. Jika kaedah yang ditawarkan oleh pakej ini untuk mencipta dan mengekalkan kluster sudah mencukupi untuk anda, saya gembira untuk anda. Malangnya, saya memerlukan lebih banyak lagi. Saya mahu mengawal persediaan secara terperinci dan bukan menjadi penonton luar dalam teater penyusunan semula kelompok.

Keperluan

Apa yang saya perlukan secara peribadi ialah perpustakaan yang akan mengambil alih pengurusan kluster dan akan mempunyai sifat berikut:

• kerja telus dengan kedua-dua senarai nod berkod keras dan penemuan dinamik melalui perkhidmatan erlang;
• panggilan balik berfungsi sepenuhnya untuk setiap perubahan topologi (nod sana, nod sini, ketidakstabilan rangkaian, perpecahan);
• antara muka telus untuk melancarkan kluster dengan nama panjang dan pendek, seperti :nonode@nohost;
• Sokongan Docker di luar kotak, tanpa perlu menulis kod infrastruktur.

Yang terakhir ini bermakna selepas saya menguji aplikasi secara tempatan di :nonode@nohost, atau dalam persekitaran teragih buatan menggunakan test_cluster_task, saya baru nak lari docker-compose up --scale my_app=3 dan lihat bagaimana ia melaksanakan tiga kejadian dalam docker tanpa sebarang perubahan kod. Saya juga mahukan aplikasi bergantung seperti mnesia - apabila topologi berubah, di sebalik tabir mereka membina semula kluster secara langsung tanpa sebarang tendangan tambahan daripada aplikasi.

biara tidak bertujuan untuk menjadi perpustakaan yang mampu melakukan segala-galanya daripada menyokong kluster kepada membuat kopi. Ia bukan peluru perak yang bertujuan untuk merangkumi semua kes yang mungkin, atau menjadi penyelesaian akademik yang lengkap dalam erti kata ahli teori dari CS dimasukkan ke dalam istilah ini. Perpustakaan ini direka bentuk untuk memenuhi tujuan yang sangat jelas, tetapi melakukan tugas yang tidak terlalu besar dengan sempurna. Matlamat ini adalah untuk menyediakan ketelusan yang lengkap antara persekitaran pembangunan tempatan dan persekitaran anjal teragih yang penuh dengan bekas bermusuhan.

Pendekatan yang dipilih

biara bertujuan untuk dijalankan sebagai aplikasi, walaupun pengguna lanjutan boleh bekerja dengan pemasangan dan penyelenggaraan kluster secara manual dengan berjalan terus Cloister.Manager dalam pokok penyelia aplikasi sasaran.

Apabila dijalankan sebagai aplikasi, perpustakaan bergantung pada config, daripadanya ia membaca nilai asas berikut:

config :cloister,
  otp_app: :my_app,
  sentry: :"cloister.local", # or ~w|n1@foo n2@bar|a
  consensus: 3,              # number of nodes to consider
                             #    the cluster is up
  listener: MyApp.Listener   # listener to be called when
                             #    the ring has changed

Parameter di atas bermaksud secara literal yang berikut: biara digunakan untuk aplikasi OTP :my_app, kegunaan penemuan perkhidmatan erlang untuk menyambungkan nod, sekurang-kurangnya tiga, dan MyApp.Listener modul (melaksanakan @behaviour Cloister.Listener) dikonfigurasikan untuk menerima pemberitahuan tentang perubahan topologi. Penerangan terperinci tentang konfigurasi lengkap boleh didapati dalam dokumentasi.

Dengan konfigurasi ini, aplikasi biara akan pelancaran secara berperingkat, menangguhkan proses memulakan aplikasi utama sehingga konsensus dicapai (tiga nod disambungkan dan disambungkan, seperti dalam contoh di atas.) Ini memberi peluang kepada aplikasi utama untuk menganggap bahawa apabila ia bermula, kluster sudah tersedia. Apabila topologi berubah (akan terdapat banyak daripada mereka, kerana nod tidak bermula sepenuhnya serentak), pengendali akan dipanggil MyApp.Listener.on_state_change/2. Selalunya kami melakukan tindakan apabila kami menerima mesej status %Cloister.Monitor{status: :up}, yang bermaksud: "Helo, gugusan telah dipasang."

Dalam kebanyakan kes, pemasangan consensus: 3 adalah optimum kerana walaupun kita menjangkakan lebih banyak nod disambungkan, panggilan balik akan diteruskan status: :rehashing → status: :up pada mana-mana nod yang baru ditambah atau dialih keluar.

Apabila memulakan mod pembangunan, anda hanya perlu menetapkan consensus: 1 и biara akan dengan senang hati melangkau menunggu perhimpunan kluster apabila dia melihat :nonode@nohostAtau :node@hostAtau :[email protected] - bergantung pada cara nod dikonfigurasikan (:none | :shortnames | :longnames).

Pengurusan Aplikasi Teragih

Aplikasi yang diedarkan bukan dalam vakum biasanya termasuk kebergantungan yang diedarkan, seperti mnesia. Mudah untuk kami mengendalikan konfigurasi semula mereka daripada panggilan balik yang sama on_state_change/2. Di sini, sebagai contoh, ialah penerangan terperinci tentang cara mengkonfigurasi semula mnesia dengan cepat masuk dokumentasi biara.

Kelebihan utama menggunakan biara ialah ia melaksanakan semua operasi yang diperlukan untuk membina semula kluster selepas perubahan topologi di bawah tudung. Aplikasi ini hanya berjalan dalam persekitaran teragih yang telah disediakan, dengan semua nod disambungkan, tidak kira sama ada kita mengetahui alamat IP dan oleh itu nama nod terlebih dahulu, atau ia telah diperuntukkan/diubah secara dinamik. Ini sama sekali tidak memerlukan tetapan konfigurasi docker khas dan dari sudut pandangan pembangun aplikasi, tiada perbezaan antara berjalan dalam persekitaran teragih atau berjalan dalam persekitaran tempatan. :nonode@nohost. Anda boleh membaca lebih lanjut mengenai ini dalam dokumentasi.

Walaupun pengendalian perubahan topologi yang kompleks boleh dilakukan melalui pelaksanaan tersuai MyApp.Listener, mungkin sentiasa terdapat kes kelebihan di mana had perpustakaan dan bias konfigurasi ini terbukti menjadi asas pelaksanaan. Tak apa, ambil saja perkara di atas libcluster, yang lebih bertujuan umum, atau mengendalikan sendiri kelompok peringkat rendah. Matlamat perpustakaan kod ini bukan untuk merangkumi setiap senario yang mungkin, tetapi untuk menggunakan senario yang paling biasa tanpa rasa sakit yang tidak perlu dan salin-tampal yang menyusahkan.

Nota: pada ketika ini dalam asalnya terdapat frasa "Selamat mengelompokkan!", dan Yandex, yang saya menterjemah (saya tidak perlu membaca kamus sendiri), menawarkan saya pilihan "Selamat mengelompok!" Mungkin mustahil untuk membayangkan terjemahan yang lebih baik, terutamanya berdasarkan situasi geopolitik semasa.

Sumber: www.habr.com