Mengekalkan alat sandaran sumber terbuka: cerapan dan banyak lagi

Strategi sandaran mungkin kelihatan seperti masalah yang telah diselesaikan, namun pentadbir sistem sering bergelut dengan soalan tentang cara membuat sandaran data dengan betul, tempat menyimpannya dan cara menyeragamkan proses sandaran merentas persekitaran perisian yang berbeza. Pada tahun 2011, kami membangunkan skrip sandaran tersuai yang mengendalikan sandaran untuk projek web pelanggan kami dengan cekap. Skrip ini memberi manfaat kepada kami selama bertahun-tahun, menyimpan sandaran dalam storan dan repositori luaran kami mengikut keperluan. Walau bagaimanapun, apabila ekosistem perisian kami berkembang dan mempelbagaikan, skrip kami menjadi pendek, kekurangan sokongan untuk teknologi baharu seperti Redis dan MySQL/PostgreSQL. Skrip juga menjadi rumit, tanpa sistem pemantauan selain makluman e-mel.

Skrip kami yang dahulunya padat berkembang menjadi sistem yang kompleks dan tidak terurus. Mengemas kini skrip ini untuk pelanggan yang berbeza menjadi mencabar, terutamanya apabila mereka menggunakan versi tersuai. Menjelang awal tahun lepas, kami menyedari bahawa kami memerlukan penyelesaian yang lebih moden.

Dalam artikel ini, kami akan menerangkan semua kesukaran yang kami hadapi semasa membangunkan nxs-backup dan berkongsi pengalaman dan cabaran kami. Anda juga boleh menguji alat pada projek anda dan berkongsi pengalaman anda, kami amat berminat untuk mendengar daripada anda. Sekarang, mari kita mulakan!

Kami menyenaraikan keperluan kami untuk sistem baharu:

• Data sandaran perisian yang paling biasa digunakan: (Fail: diskret dan tambahan; MySQL; PostgreSQL; MongoDB; Redis);
• Simpan sandaran dalam repositori popular: (FTP; SSH; SMB; NFS; WebDAV; S3);
• Terima makluman sekiranya berlaku masalah semasa proses sandaran;
• Mempunyai fail konfigurasi bersatu untuk mengurus sandaran secara berpusat;
• Tambah sokongan untuk perisian baharu dengan menyambungkan modul luaran;
• Nyatakan pilihan tambahan untuk mengumpul tempat pembuangan;
• Dapat memulihkan sandaran dengan alatan standard;
• Kemudahan konfigurasi awal. Semua keperluan ini disenaraikan berdasarkan keperluan kami kira-kira 5 tahun yang lalu. Malangnya, tidak semua daripada mereka dibebaskan.

Kami melihat penyelesaian sumber terbuka yang telah wujud sebelum mencipta versi pertama nxs-backup kami. Tetapi mereka semua mempunyai kelemahan mereka. Sebagai contoh, Bacula terlalu sarat dengan fungsi yang tidak diperlukan untuk kami, konfigurasi awal adalah — agak pekerjaan yang melelahkan kerana banyak kerja manual (contohnya, untuk menulis/mencari skrip sandaran pangkalan data), dan untuk memulihkan salinan perlu menggunakan utiliti khas , dsb.

Tidak mengejutkan bahawa kami menghadapi masalah yang sama semasa mempunyai idea untuk menulis semula alat kami. Kemungkinan fakta bahawa dalam empat tahun sesuatu telah berubah dan alat baharu telah muncul dalam talian tidak begitu tinggi, tetapi masih.

Kami mengkaji beberapa alatan baharu yang tidak dipertimbangkan sebelum ini. Tetapi, seperti yang dibincangkan sebelum ini, ini juga tidak sesuai dengan kami. Kerana mereka tidak memenuhi keperluan kami sepenuhnya.

Kami akhirnya mencapai dua kesimpulan penting:

1. Tiada penyelesaian sedia ada yang sesuai sepenuhnya untuk kami;
2. Nampaknya kami sudah cukup pengalaman dan kegilaan untuk menulis penyelesaian kami buat kali pertama. Dan pada dasarnya kita boleh melakukannya sekali lagi. Jadi itulah yang kami lakukan.

Sebelum meneroka versi baharu, mari lihat apa yang kami ada sebelum ini dan mengapa ia tidak mencukupi untuk kami.

Versi lama menyokong DB seperti MySQL, PostgreSQL, Redis, MongoDB, penyalinan fail diskret dan tambahan, berbilang storan jauh (S3; SMB; NFS; FTP; SSH; WebDAV) dan mempunyai ciri seperti penggiliran sandaran, pengelogan , pemberitahuan e-mel dan modul luaran.

Sekarang, lebih lanjut tentang perkara yang kami bimbang.

Jalankan fail binari tanpa memulakan semula fail sumber pada mana-mana Linux

Dari masa ke masa, senarai sistem yang kami bekerjasama telah berkembang dengan ketara. Kini kami menyediakan projek yang menggunakan selain daripada pengedaran serasi deb dan rpm standard seperti Arch, Suse, Alt, dll.

Sistem terkini mengalami kesukaran menjalankan nxs-backup kerana kami hanya mengumpul pakej deb dan rpm serta menyokong senarai terhad versi sistem. Di suatu tempat kami memetik semula keseluruhan pakej, di suatu tempat hanya binari, di suatu tempat kami hanya perlu menjalankan kod sumber.

Bekerja dengan versi lama sangat menyusahkan jurutera, kerana keperluan untuk bekerja dengan sumbernya. Apatah lagi pemasangan dan pengemaskinian dalam mod sedemikian mengambil lebih banyak masa. Daripada menyediakan 10 pelayan sejam, anda hanya perlu menghabiskan satu jam pada satu pelayan.

Kami telah lama mengetahui bahawa adalah lebih baik apabila anda mempunyai binari tanpa kebergantungan sistem yang boleh anda jalankan pada sebarang pengedaran dan tidak mengalami masalah dengan versi perpustakaan yang berbeza dan perbezaan seni bina dalam sistem. Kami mahu alat ini sama.

Minikan imej docker dengan nxs-backup dan sokong ENV dalam fail konfigurasi

Kebelakangan ini, begitu banyak projek sedang berjalan dalam persekitaran kontena. Projek ini juga memerlukan sandaran, dan kami menjalankan nxs-backup dalam bekas. Untuk persekitaran dalam bekas, adalah sangat penting untuk meminimumkan saiz imej dan dapat berfungsi dengan pembolehubah persekitaran.

Versi lama tidak memberi peluang untuk bekerja dengan pembolehubah persekitaran. Masalah utama ialah kata laluan perlu disimpan terus dalam konfigurasi. Oleh sebab itu, bukannya satu set pembolehubah yang mengandungi hanya kata laluan, anda perlu meletakkan keseluruhan konfigurasi ke dalam pembolehubah. Mengedit pembolehubah persekitaran yang besar memerlukan lebih tumpuan daripada jurutera dan menjadikan penyelesaian masalah menjadi lebih sukar.

Selain itu, apabila bekerja dengan versi lama, kami terpaksa menggunakan imej Debian yang sudah besar, di mana kami perlu menambah beberapa perpustakaan dan aplikasi untuk sandaran yang betul.

Walaupun menggunakan versi imej yang tipis, kami mendapat saiz minimum ~250Mb, yang cukup banyak untuk satu utiliti kecil. Dalam sesetengah kes, ini menjejaskan proses permulaan pengumpulan kerana tempoh imej ditarik ke nod. Kami ingin mendapatkan imej yang tidak lebih besar daripada 50 MB.

Kerja dengan storan jauh tanpa fius

Satu lagi masalah untuk persekitaran kontena ialah menggunakan fius untuk memasang storan jauh.

Semasa anda menjalankan sandaran pada hos, ini masih boleh diterima: anda telah memasang pakej yang betul dan mendayakan fius dalam kernel, dan kini ia berfungsi.

Perkara menjadi menarik apabila anda memerlukan fius dalam bekas. Tanpa peningkatan keistimewaan dengan akses terus ke teras sistem hos, masalah tidak dapat diselesaikan dan ini merupakan penurunan ketara dalam tahap keselamatan.

Ini perlu diselaraskan, tidak semua pelanggan bersetuju untuk melemahkan dasar keselamatan. Itulah sebabnya kami terpaksa membuat sejumlah besar penyelesaian yang kami tidak mahu ingat. Tambahan pula, lapisan tambahan meningkatkan kebarangkalian kegagalan dan memerlukan pemantauan tambahan terhadap keadaan sumber yang dipasang. Ia adalah lebih selamat dan lebih stabil untuk bekerja dengan storan jauh menggunakan API mereka secara langsung.

Status pemantauan dan menghantar pemberitahuan bukan sahaja kepada e-mel

Hari ini, pasukan semakin kurang menggunakan e-mel dalam kerja harian mereka. Ia boleh difahami kerana lebih pantas untuk membincangkan isu itu dalam sembang kumpulan atau dalam panggilan kumpulan. Telegram, Slack, Mattermost, MS Teams dan produk lain yang serupa diedarkan secara meluas oleh itu.

Kami juga mempunyai bot, yang menghantar pelbagai makluman dan memberitahu kami tentangnya. Dan sudah tentu, kami ingin melihat laporan sandaran ranap di ruang kerja seperti Telegram, bukan e-mel, antara ratusan e-mel lain. By the way, sesetengah pelanggan juga ingin melihat maklumat tentang kegagalan dalam Slack mereka atau messenger lain.

Selain itu, anda sudah lama ingin dapat menjejaki status dan melihat butiran kerja dalam masa nyata. Untuk melakukan ini, anda perlu menukar format aplikasi, mengubahnya menjadi syaitan.

Prestasi tidak mencukupi

Satu lagi kesakitan akut ialah prestasi yang tidak mencukupi dalam senario tertentu.

Salah seorang pelanggan mempunyai longgokan fail yang besar hampir satu terabait dan semuanya adalah fail kecil — teks, gambar, dsb. Kami sedang mengumpul salinan tambahan bahan ini dan menghadapi masalah berikut — salinan tahunan mengambil masa TIGA hari. Ya, versi lama tidak dapat mencerna volum itu dalam masa kurang dari sehari.

Memandangkan keadaan, kami, sebenarnya, tidak dapat memulihkan data pada tarikh tertentu, yang kami tidak suka sama sekali.

Pada mulanya, kami melaksanakan penyelesaian sandaran kami dalam Python kerana kesederhanaan dan fleksibilitinya. Walau bagaimanapun, apabila permintaan semakin meningkat, penyelesaian berasaskan Python menjadi tidak mencukupi. Selepas perbincangan menyeluruh, kami memutuskan untuk menulis semula sistem dalam Go atas beberapa sebab:

1. Kompilasi dan Ketergantungan: Pengkompil AOT Go menghasilkan binari universal, bebas pergantungan, memudahkan penggunaan merentas sistem yang berbeza;
2. Prestasi: Keupayaan multithreading yang wujud dalam Go menjanjikan prestasi yang lebih baik;
3. Kepakaran Pasukan: Kami mempunyai lebih ramai pembangun berpengalaman dalam Go berbanding Python.

Mencari penyelesaian

Semua masalah di atas, pada tahap yang lebih besar atau lebih kecil, menyebabkan kesakitan yang ketara kepada jabatan IT, menyebabkan mereka menghabiskan masa yang berharga untuk perkara yang penting, tetapi kos ini boleh dielakkan. Selain itu, dalam situasi tertentu risiko tertentu dicipta untuk pemilik perniagaan — kebarangkalian tanpa data untuk hari tertentu, walaupun sangat rendah, tetapi bukan sifar. Kami enggan menerima keadaan.

Nxs-backup 3.0

Hasil kerja kami ialah versi baharu nxs-backup v 3.0 yang baru-baru ini mempunyai kemas kini kepada v3.8.0
Ciri utama versi baharu:

• Laksanakan antara muka yang sepadan untuk semua kemudahan storan dan semua jenis sandaran. Kerja dan storan dimulakan pada permulaan, dan bukan semasa kerja sedang berjalan;
• Kerja dengan storan jauh melalui API. Untuk ini, kami menggunakan pelbagai perpustakaan;
• Gunakan pembolehubah persekitaran dalam konfigurasi, terima kasih kepada rangka kerja aplikasi mini go-nxs-appctx yang kami gunakan dalam projek kami;
• Hantar acara log melalui cangkuk. Anda boleh mengkonfigurasi tahap yang berbeza dan menerima hanya ralat atau peristiwa pada tahap yang dikehendaki;
• Nyatakan bukan sahaja tempoh masa untuk sandaran, tetapi juga bilangan sandaran tertentu;
• Sandaran kini hanya dijalankan pada Linux anda bermula dengan kernel 2.6. Ini menjadikannya lebih mudah untuk bekerja dengan sistem bukan standard dan lebih pantas untuk membina imej Docker. Imej itu sendiri telah dikurangkan kepada 23 MB (dengan tambahan pelanggan MySQL dan SQL disertakan);
• Keupayaan untuk mengumpul, mengeksport dan menyimpan metrik yang berbeza dalam format yang serasi dengan Prometheus.
• Menghadkan penggunaan sumber untuk kadar cakera tempatan dan storan jauh.

Kami telah cuba mengekalkan kebanyakan konfigurasi dan logik aplikasi, tetapi terdapat beberapa perubahan. Kesemuanya berkaitan dengan pengoptimuman dan pembetulan kecacatan dalam versi sebelumnya.

Sebagai contoh, kami meletakkan parameter sambungan ke repositori jauh ke dalam konfigurasi asas supaya kami tidak menetapkannya untuk jenis sandaran yang berbeza setiap kali.

Di bawah ialah contoh konfigurasi asas untuk sandaran. Ia mengandungi tetapan umum seperti saluran pemberitahuan, storan jauh, pengelogan dan senarai kerja. Ini ialah konfigurasi utama asas dengan pemberitahuan mel, kami amat mengesyorkan menggunakan pemberitahuan e-mel sebagai kaedah lalai. Jika anda memerlukan lebih banyak ciri, anda boleh melihat rujukan dalam dokumentasi.

server_name: wp-server
project_name: My Best Project

loglevel: info

notifications:
  mail:
    enabled: true
    smtp_server: smtp.gmail.com
    smtp_port: 465
    smtp_user: j.doe@gmail.com
    smtp_password: some5Tr0n9P@s5worD
    recipients:
      - j.doe@gmail.com
      - a.smith@mail.io
  webhooks: []
storage_connects: []
jobs: []
include_jobs_configs: [ "conf.d/*.conf" ]

Beberapa perkataan tentang perangkap

Kami dijangka akan menghadapi cabaran tertentu. Ia akan menjadi bodoh untuk berfikir sebaliknya. Tetapi dua masalah menyebabkan butthurt yang paling kuat.

Kebocoran memori atau algoritma tidak optimum

Malah dalam versi nxs-backup sebelumnya, kami menggunakan pelaksanaan pengarkiban fail kami sendiri. Logik penyelesaian ini adalah untuk cuba mengelak daripada menggunakan alat luaran untuk membuat sandaran, dan bekerja dengan fail adalah langkah paling mudah yang mungkin.

Dalam amalan, penyelesaian itu terbukti boleh dilaksanakan, walaupun tidak begitu berkesan pada sejumlah besar fail, seperti yang dapat dilihat daripada ujian. Pada masa itu, kami menghapuskannya kepada spesifikasi Python dan berharap dapat melihat perbezaan yang ketara apabila kami beralih kepada Go.

Apabila kami akhirnya sampai ke ujian beban versi baharu, kami mendapat keputusan yang mengecewakan. Tiada peningkatan prestasi dan penggunaan memori lebih tinggi daripada sebelumnya. Kami sedang mencari penyelesaian. Baca banyak artikel dan penyelidikan mengenai topik ini, tetapi mereka semua berkata bahawa penggunaan «filepath.Walk» dan «filepath.WalkDir» adalah pilihan terbaik. Prestasi kaedah ini hanya meningkat dengan keluaran versi baharu bahasa.

Dalam percubaan untuk mengoptimumkan penggunaan memori, kami juga telah melakukan kesilapan dalam mencipta salinan tambahan. By the way, pilihan yang rosak sebenarnya lebih berkesan. Atas sebab yang jelas, kami tidak menggunakannya.

Akhirnya, semuanya melekat pada bilangan fail yang akan diproses. Kami menguji 10 juta. Pemungut Sampah nampaknya tidak dapat mengosongkan jumlah pembolehubah yang dijana ini.

Akhirnya, menyedari bahawa kami boleh menghabiskan terlalu banyak masa di sini, kami memutuskan untuk meninggalkan pelaksanaan kami demi penyelesaian yang diuji masa dan benar-benar berkesan — GNU tar.

Kami mungkin kembali kepada idea pelaksanaan kendiri kemudian apabila kami menghasilkan penyelesaian yang lebih cekap untuk mengendalikan berpuluh juta fail.

ftp yang berbeza

Satu lagi masalah timbul apabila bekerja dengan ftp. Ternyata pelayan yang berbeza berkelakuan berbeza untuk permintaan yang sama.

Dan ini adalah masalah yang sangat serius apabila untuk permintaan yang sama anda mendapat sama ada jawapan biasa, atau ralat yang nampaknya tidak ada kaitan dengan permintaan anda, atau anda tidak mendapat pepijat apabila anda menjangkakannya .

Jadi, kami terpaksa berputus asa menggunakan perpustakaan "prasad83/goftp" untuk memilih "jlaffaye/ftp" yang lebih mudah, kerana yang pertama tidak dapat berfungsi dengan betul dengan pelayan Selectel. Ralatnya ialah apabila menyambung, yang pertama cuba mendapatkan senarai fail dalam direktori kerja dan mendapat ralat hak akses kepada direktori yang lebih tinggi. Dengan “jlaffaye/ftp” masalah seperti itu tidak wujud, kerana ia lebih mudah dan tidak menghantar sebarang permintaan kepada pelayan.

Masalah seterusnya ialah terputus sambungan apabila tiada permintaan. Tidak semua pelayan berkelakuan seperti ini, tetapi ada yang melakukannya. Oleh itu, kami perlu menyemak sebelum setiap permintaan sama ada penyambung telah tertanggal dan disambungkan semula.

Ceri di atas ialah masalah mendapatkan fail daripada pelayan, atau lebih jelasnya, percubaan untuk mendapatkan fail yang tidak wujud. Sesetengah pelayan memberikan ralat semasa cuba mengakses fail sedemikian, yang lain mengembalikan objek antara muka io.Reader yang sah malah boleh dibaca, hanya anda mendapat potongan bait kosong.

Semua situasi ini telah ditemui secara empirikal dan perlu ditangani sendiri.

Kesimpulan

Paling penting, kami membetulkan masalah versi lama, perkara yang menjejaskan kerja jurutera dan mewujudkan risiko tertentu untuk perniagaan.

Kami masih mempunyai "kehendak" yang belum direalisasikan daripada versi terakhir, seperti:

• Penyulitan sandaran;
• Pulihkan daripada sandaran menggunakan alat nxs-backup;
• Antara muka web untuk mengurus senarai kerja dan tetapannya.

Senarai ini kini dipanjangkan dengan yang baharu:

• Penjadual kerja sendiri. Gunakan tetapan tersuai dan bukannya crone sistem;
• Jenis sandaran baharu (Clickhouse, Elastic, lvm, dll).

Dan, sudah tentu, kami akan gembira mengetahui pendapat masyarakat. Apakah peluang pembangunan lain yang anda lihat? Apakah pilihan yang akan anda tambahkan?

Anda boleh membaca dokumentasi dan mengetahui lebih lanjut tentang nxs-backup di tapak webnya, terdapat juga bahagian penyelesaian masalah di tapak web kami jika anda ingin meninggalkan sebarang isu.

Kami telah membuat tinjauan pendapat dalam saluran Telegram kami tentang ciri yang akan datang. Ikuti kami untuk menyertai aktiviti sedemikian dan menyumbang kepada pembangunan alat!

Jumpa lagi nanti!

Atas ialah kandungan terperinci Mengekalkan alat sandaran sumber terbuka: cerapan dan banyak lagi. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!