Cloister → manajemen cluster OTP sederhana

Hampir setiap aplikasi bisnis yang sukses cepat atau lambat akan memasuki fase di mana penskalaan horizontal diperlukan. Dalam banyak kasus, Anda cukup memulai instance baru dan mengurangi rata-rata beban. Namun ada juga kasus yang tidak terlalu sepele di mana kita perlu memastikan bahwa node yang berbeda mengetahui satu sama lain dan mendistribusikan beban kerja dengan hati-hati.

Ternyata sangat beruntung diperoleh, yang kami pilih karena sintaksisnya yang menyenangkan dan sensasi di sekitarnya, memiliki kualitas terbaik dukungan untuk sistem terdistribusi. Secara teori, ini kedengarannya sepele:

Pengiriman pesan antar proses pada node yang berbeda, serta antara link dan monitor, bersifat transparan […]

Dalam praktiknya, semuanya menjadi sedikit lebih rumit. Didistribusikan diperoleh dikembangkan ketika "kontainer" berarti kotak besi besar untuk pengiriman, dan "buruh pelabuhan" hanyalah sinonim untuk pekerja pelabuhan. DI DALAM IP4 ada banyak alamat yang kosong, kerusakan jaringan biasanya disebabkan oleh tikus yang mengunyah kabel, dan waktu aktif rata-rata sistem produksi diukur dalam beberapa dekade.

Sekarang kita semua sudah sangat mandiri, terpaket, dan berjalan terdistribusi diperoleh dalam lingkungan di mana alamat IP dinamis dibagikan berdasarkan prinsip keacakan besar, dan node dapat muncul dan menghilang sesuai keinginan penjadwal. Untuk menghindari tumpukan kode boilerplate di setiap proyek yang berjalan secara terdistribusi diperoleh, untuk memerangi lingkungan yang tidak bersahabat, diperlukan bantuan.

Catatan: Saya sadar bahwa ada libcluster. Keren banget, bintangnya seribu lebih, penulisnya terkenal di masyarakat, dan sebagainya. Jika metode yang ditawarkan oleh paket ini untuk membuat dan memelihara cluster sudah cukup untuk Anda, saya senang untuk Anda. Sayangnya, saya membutuhkan lebih banyak lagi. Saya ingin mengontrol pengaturan secara detail dan tidak menjadi penonton luar dalam teater reorganisasi klaster.

Persyaratan

Yang saya butuhkan secara pribadi adalah perpustakaan yang akan mengambil alih pengelolaan cluster dan memiliki properti berikut:

• pekerjaan transparan dengan daftar node yang dikodekan secara keras dan penemuan dinamis melalui layanan diperoleh;
• panggilan balik yang berfungsi penuh untuk setiap perubahan topologi (simpul di sana, simpul di sini, ketidakstabilan jaringan, perpecahan);
• antarmuka transparan untuk meluncurkan cluster dengan nama panjang dan pendek, seperti :nonode@nohost;
• Dukungan Docker langsung, tanpa harus menulis kode infrastruktur.

Yang terakhir berarti setelah saya menguji aplikasi secara lokal di :nonode@nohost, atau dalam lingkungan yang didistribusikan secara artifisial menggunakan test_cluster_task, saya hanya ingin lari docker-compose up --scale my_app=3 dan lihat bagaimana ia mengeksekusi tiga instance di buruh pelabuhan tanpa perubahan kode apa pun. Saya juga ingin aplikasi dependen seperti mnesia - ketika topologi berubah, di balik layar mereka membangun kembali cluster secara langsung tanpa adanya tindakan tambahan apa pun dari aplikasi.

Biara tidak dimaksudkan untuk menjadi perpustakaan yang mampu melakukan segalanya mulai dari mendukung cluster hingga membuat kopi. Ini bukanlah solusi jitu yang bertujuan untuk mencakup semua kasus yang mungkin terjadi, atau menjadi solusi akademis yang lengkap dalam artian yang dikemukakan oleh para ahli teori dari CS dimasukkan ke dalam istilah ini. Perpustakaan ini dirancang untuk melayani tujuan yang sangat jelas, namun melakukan tugasnya yang tidak terlalu besar dengan sempurna. Tujuannya adalah untuk memberikan transparansi penuh antara lingkungan pembangunan lokal dan lingkungan elastis terdistribusi yang penuh dengan kontainer yang tidak bersahabat.

Pendekatan yang dipilih

Biara dimaksudkan untuk dijalankan sebagai sebuah aplikasi, meskipun pengguna tingkat lanjut dapat bekerja dengan perakitan dan pemeliharaan cluster secara manual dengan menjalankannya secara langsung Cloister.Manager di pohon pengawas aplikasi target.

Saat dijalankan sebagai aplikasi, perpustakaan bergantung pada config, yang darinya terbaca nilai-nilai dasar 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 secara harafiah berarti sebagai berikut: Biara digunakan untuk aplikasi OTP :my_app, menggunakan penemuan layanan erlang untuk menghubungkan node, setidaknya tiga, dan MyApp.Listener modul (implementasi @behaviour Cloister.Listener) dikonfigurasi untuk menerima pemberitahuan tentang perubahan topologi. Penjelasan rinci tentang konfigurasi lengkap dapat ditemukan di dokumentasi.

Dengan konfigurasi ini, aplikasi Biara akan peluncuran secara bertahap, menunda proses memulai aplikasi utama hingga konsensus tercapai (tiga node terhubung dan terhubung, seperti pada contoh di atas.) Hal ini memberikan kesempatan kepada aplikasi utama untuk berasumsi bahwa ketika dimulai, cluster sudah tersedia. Setiap kali topologi berubah (akan ada banyak, karena node tidak dimulai sepenuhnya secara sinkron), handler akan dipanggil MyApp.Listener.on_state_change/2. Seringkali kita melakukan suatu tindakan ketika kita menerima pesan status %Cloister.Monitor{status: :up}, yang artinya: “Halo, cluster sudah terpasang.”

Dalam kebanyakan kasus, instalasi consensus: 3 optimal karena meskipun kita mengharapkan lebih banyak node yang terhubung, callback akan tetap berjalan status: :rehashing → status: :up pada node yang baru ditambahkan atau dihapus.

Saat memulai dalam mode pengembangan, Anda hanya perlu mengaturnya consensus: 1 и Biara akan dengan senang hati melewatkan penantian perakitan cluster ketika dia melihatnya :nonode@nohostAtau :node@hostAtau :[email protected] - tergantung pada bagaimana node dikonfigurasi (:none | :shortnames | :longnames).

Manajemen Aplikasi Terdistribusi

Aplikasi terdistribusi yang tidak berada dalam ruang hampa biasanya menyertakan dependensi terdistribusi, seperti mnesia. Mudah bagi kami untuk menangani konfigurasi ulangnya dari callback yang sama on_state_change/2. Di sini, misalnya, adalah penjelasan rinci tentang cara mengkonfigurasi ulang mnesia dengan cepat masuk dokumentasi Biara.

Keuntungan utama menggunakan Biara adalah ia melakukan semua operasi yang diperlukan untuk membangun kembali cluster setelah perubahan topologi Dibawah tenda. Aplikasi hanya berjalan di lingkungan terdistribusi yang sudah disiapkan, dengan semua node terhubung, terlepas dari apakah kita mengetahui alamat IP dan nama node sebelumnya, atau mereka telah ditetapkan/diubah secara dinamis. Ini sama sekali tidak memerlukan pengaturan konfigurasi buruh pelabuhan khusus dan dari sudut pandang pengembang aplikasi, tidak ada perbedaan antara berjalan di lingkungan terdistribusi atau berjalan di lingkungan lokal. :nonode@nohost. Anda dapat membaca lebih lanjut tentang ini di dokumentasi.

Meskipun penanganan perubahan topologi yang rumit dimungkinkan melalui implementasi khusus MyApp.Listener, mungkin selalu ada kasus-kasus ekstrem di mana keterbatasan perpustakaan dan bias konfigurasi terbukti menjadi landasan implementasi. Tidak apa-apa, ambil saja yang di atas libcluster, yang lebih bertujuan umum, atau bahkan menangani sendiri cluster tingkat rendah. Tujuan dari pustaka kode ini bukan untuk mencakup setiap skenario yang mungkin terjadi, namun untuk menggunakan skenario yang paling umum tanpa kerumitan yang tidak perlu dan proses salin-tempel yang rumit.

Catatan: pada titik ini dalam bahasa aslinya ada frasa “Selamat pengelompokan!”, dan Yandex, yang saya gunakan untuk menerjemahkan (saya sendiri tidak harus membuka kamus), menawari saya opsi “Selamat pengelompokan!” Mungkin mustahil untuk membayangkan terjemahan yang lebih baik, terutama mengingat situasi geopolitik saat ini.

Sumber: www.habr.com