Bagaimana kami memigrasi 700+ server ke Salt
Untuk waktu yang lama, kami puas dengan konfigurasi yang rumit dan tidak praktis dengan 2 repositori Git, di mana sebagian datanya disimpan di MySQL, dan bagian lainnya adalah Puppet 3.8. Tetapi kebutuhan kami tumbuh secara bertahap, jumlah layanan meningkat, dan kinerja konfigurasi menurun. Kemudian kami menetapkan sendiri tugas untuk meningkatkan konfigurasi, mengoptimalkan semua data dan alat yang tersedia.
Tim kami telah memilih konfigurasi yang sesuai untuk mereka sendiri dalam 3 tahap. Kami berbagi pengalaman kami tentang pengoptimalan Salt, cara menerapkan dan menyesuaikan tanpa usaha ekstra.
Catatan: Di Habré kami menemukan artikel bagus dari kolega kami, jadi kami tidak akan memikirkan masalah yang sudah dibahas. Kami sangat merekomendasikan membaca:
Apa yang baik tentang SaltStack, dan tugas apa yang dapat diselesaikan dengannya - artikel darikeamanan, Teknologi Positif.
Instalasi, peluncuran, perintah pertama dan keakraban dengan fungsi - artikel penuliszerghack007...
Salt adalah manajemen konfigurasi dan sistem eksekusi jarak jauh. Kerangka infrastruktur sumber terbuka yang ditulis dengan Python.
Mengapa Salt?
Salt, Ansible, Puppet, dan Chef adalah opsi yang layak untuk memilih alat manajemen konfigurasi. Kami memilih Salt karena kami memprioritaskan manfaat berikut:
- Modularitas, ketersediaan API dalam versi gratis, tidak seperti Ansible.
- Python, yang berarti Anda dapat dengan mudah memahami komponen apa pun dan menulis sendiri fungsionalitas yang hilang.
- Performa dan skalabilitas tinggi. Wizard membuat koneksi permanen dengan minion menggunakan ZeroMQ untuk performa maksimal.
- Reaktor adalah sejenis pemicu yang dijalankan ketika pesan tertentu muncul di bus pesan.
- Orkestrasi adalah kemampuan untuk membangun hubungan yang kompleks dan melakukan tindakan dalam urutan tertentu, misalnya, mengonfigurasi load balancer terlebih dahulu, kemudian cluster server web.
- Wayang dan Koki ditulis dengan bahasa Ruby. Tim kami tidak memiliki spesialis yang kompeten untuk bekerja dengan bahasa pemrograman ini, tetapi Python sangat terkenal dan sering digunakan oleh kami.
- Untuk tim yang telah menggunakan Ansible sebelumnya, kemampuan untuk menggunakan Ansible playbooks akan relevan. Ini akan memungkinkan Anda untuk bermigrasi ke Salt tanpa rasa sakit.
Harap Dicatat:
Kami telah menggunakan Salt selama hampir dua tahun sekarang dan kami menyarankan Anda untuk memperhatikan poin-poin berikut:
- Salt, , . , . , SaltStack .
- SaltStack . , . : , . , cmd.run file.managed, .
, , , .
. .
Diberikan:
Jadi, konfigurasi awal kami adalah:
- 2 repositori Git (satu untuk insinyur dan admin; yang kedua untuk server yang sangat kritis, tersedia hanya untuk admin);
- sepotong data di MySQL;
- bagian lain - di Puppet 3.8 (kelebihan warisan, praktis tidak menggunakan Hiera - penyimpanan nilai kunci).
Tujuan: untuk memigrasi sistem manajemen konfigurasi ke Salt, meningkatkan kinerjanya, membuat manajemen server lebih nyaman dan mudah dipahami.
Solusi:
Pertama-tama, kami mulai memigrasikan konfigurasi asli ke Salt dari server layanan non-kritis yang terpisah, pada saat yang sama menghapus kode yang tidak terpakai.
Kemudian kami menyiapkan konfigurasi untuk server VDS. Dalam kasus kami, ini adalah profil untuk server layanan, server pengembangan, dan server klien.
Masalah utama saat beralih dari Puppet ke Salt adalah sistem operasi yang sudah ketinggalan zaman (pada 2018, ada Ubuntu 12.04 dan 14.04). Sebelum migrasi, OS perlu diperbarui dan tidak memengaruhi pengoperasian layanan / server. Jika tidak, semuanya cukup mudah: rekan kerja secara bertahap terlibat dalam proses tersebut.
Di antara keuntungan utama, tim mencatat, misalnya, sintaks yang lebih bisa dimengerti. Kolega saya dan saya setuju untuk menggunakan tip Praktik Terbaik Garam , tetapi melengkapinya dengan rekomendasi kami sendiri yang mencerminkan kekhasan kami.
Tim juga mengevaluasi metode pengiriman konfigurasi: push (master "push") dan pull (minion "pulls"). Mode tanpa master membantu jika Anda perlu menguji sesuatu yang sederhana dan tidak mengacaukan repositori Git. Menjalankan minion dalam mode tanpa master memungkinkan Anda menggunakan manajemen konfigurasi Salt di satu mesin tanpa harus pergi ke master Salt di komputer lain. Konfigurasi ini sepenuhnya lokal.
Hingga 300 antek dengan solusi seperti itu, kami tidak memiliki masalah serius. Konfigurasi master saat itu adalah VDS dengan 6 core dan memori 4 GB.
Namun, begitu jumlah minion mencapai 300, Load Average (beban sistem rata-rata) meningkat menjadi 3,5-4, dan sistem sangat melambat. Sebelumnya, perintah state.apply membutuhkan waktu 30-40 detik, tetapi sekarang membutuhkan waktu 18 menit!
Hasil seperti itu, tentu saja, tidak dapat kami terima. Selain itu, para ahli dari perusahaan lain telah menulis tentang kisah sukses dengan 10.000 antek. Kami mulai mencari tahu apa masalahnya.
Pengamatan master tidak memberikan jawaban yang jelas untuk pertanyaan itu. Ada cukup memori, jaringan tidak dimuat, disk digunakan sebesar 10%. Kami pikir GitLab yang harus disalahkan, tetapi itu juga tidak bisa disalahkan.
Tampaknya tidak ada cukup daya prosesor: ketika menambahkan inti, Rata-rata Beban secara alami turun, dan perintah state.apply dijalankan, meskipun lebih cepat, sekitar 5-7 menit, tetapi tidak secepat yang kami inginkan.
Menambahkan pekerja sebagian memecahkan masalah, tetapi secara signifikan meningkatkan konsumsi memori.
Kemudian kami memutuskan untuk mengoptimalkan konfigurasi itu sendiri.
Tahap 1
Karena pilar adalah penyimpanan yang dilindungi, akses ke penyimpanan dikaitkan dengan operasi enkripsi, dan Anda harus membayar untuk mengaksesnya dengan waktu CPU. Oleh karena itu, kami mengurangi jumlah panggilan ke pilar: data yang sama diambil hanya sekali; jika diperlukan di tempat lain, maka diakses melalui impor ({% - dari 'defaults / pillar.sls' import profile%}).
Konfigurasi diterapkan sekali dalam satu jam, waktu eksekusi dipilih secara acak. Setelah menganalisis berapa banyak tugas yang dilakukan per menit dan seberapa merata tugas tersebut didistribusikan selama satu jam, kami menemukan: pada awal jam, dari menit ke-1 hingga ke-8, sebagian besar tugas berlalu, dan pada menit ke-34, tidak ada! Kami menulis pelari yang melewati semua antek sekali seminggu dan tugas yang didistribusikan secara merata. Berkat pendekatan ini, beban menjadi seragam, tanpa lompatan.
Ada saran untuk pindah ke server besi, tetapi pada saat itu tidak ada dan ... kami memecahkan masalah dengan cara yang berbeda. Kami menambahkan beberapa memori dan menempatkan seluruh cache di dalamnya. Melihat dasbor Grafana, pertama-tama kami mengira bahwa salt-master tidak berfungsi, karena Load Average turun menjadi 0,5. Kami memeriksa waktu eksekusi state.apply dan juga terkejut - 20-30 detik. Itu adalah kemenangan!
Tahap 2
Enam bulan kemudian, jumlah minion meningkat menjadi 650, dan ... penurunan performa datang lagi. Grafik Load Average tumbuh dengan jumlah antek.
Hal pertama yang kami lakukan: aktifkan cache pilar, setel masa hidup menjadi 1 jam (pillar_cache_ttl: 3600). Kami menyadari bahwa sekarang komitmen kami tidak akan instan dan harus menunggu master memperbarui cache.
Karena kami tidak ingin menunggu sama sekali, kami membuat pengait di GitLab. Ini diperbolehkan dalam komit untuk menunjukkan minion mana yang Anda perlukan untuk memperbarui cache. Cache pilar secara signifikan mengurangi beban dan mengurangi waktu untuk menerapkan konfigurasi.
Tahap 3
Kami merenungkan sedikit log debug dan mengajukan hipotesis: bagaimana jika kami meningkatkan interval pembaruan untuk backend file dan cache daftar file (gitfs_update_interval, fileserver_list_cache_time)? Pembaruan yang berlangsung satu menit sekali dan terkadang membutuhkan waktu hingga 15 detik. Dengan meningkatkan interval pembaruan dari 1 menit menjadi 10 menit, kami menang lagi dalam kecepatan! Indikator LA menurun dari 1,5 menjadi 0,5. Waktu untuk menerapkan konfigurasi dikurangi menjadi 20 detik yang diinginkan. Terlepas dari kenyataan bahwa LA tumbuh lagi setelah beberapa waktu, kecepatan eksekusi state.apply tidak berubah secara signifikan. Pembaruan paksa dari cache ini telah ditambahkan ke hook di git push.
Kami menambahkan analitik ke Elasticsearch: menulis ulang elasticsearch_return bawaan dan sekarang kami dapat memantau hasil state.apply (waktu eksekusi rata-rata, status terlama, dan jumlah kesalahan).
hasil
Sekarang kami benar-benar puas dengan kinerja Salt. Ada rencana untuk menggandakan jumlah antek. Bagaimana tuan kita akan mengatasi beban seperti itu masih sulit untuk dikatakan. Mungkin kita akan beralih ke penskalaan horizontal atau menemukan parameter ajaib. Waktu akan berbicara!
Jika Anda menggunakan gitfs sebagai backend, berikan lima! Kemungkinannya adalah, Anda mengalami masalah yang sama seperti kami. Jadi kami akan dengan senang hati membahas topik ini di komentar.