Nota ini melengkapkan kitaran tentang sandaran. Ia akan membincangkan organisasi logik pelayan khusus (atau VPS), mudah untuk sandaran, dan juga akan menawarkan pilihan untuk memulihkan pelayan dengan cepat daripada sandaran tanpa banyak masa henti sekiranya berlaku bencana.
Data mentah
Pelayan khusus paling kerap mempunyai sekurang-kurangnya dua cakera keras yang berfungsi untuk mengatur tatasusunan RAID peringkat pertama (cermin). Ini adalah perlu untuk dapat meneruskan operasi pelayan jika satu cakera gagal. Jika ini adalah pelayan khusus biasa, mungkin terdapat pengawal RAID perkakasan yang berasingan dengan teknologi caching aktif pada SSD, supaya sebagai tambahan kepada pemacu keras biasa, satu atau lebih SSD boleh disambungkan. Kadangkala pelayan khusus ditawarkan, di mana satu-satunya cakera tempatan ialah SATADOM (cakera kecil, secara struktur pemacu kilat disambungkan ke port SATA), atau pemacu kilat kecil biasa (8-16GB) yang disambungkan ke port dalaman khas, dan data diambil daripada sistem storan , disambungkan melalui rangkaian storan khusus (Ethernet 10G, FC, dll.), dan terdapat pelayan khusus yang dimuatkan terus daripada sistem storan. Saya tidak akan mempertimbangkan pilihan sedemikian, kerana dalam kes sedemikian, tugas untuk membuat sandaran pelayan dengan lancar diserahkan kepada pakar yang menyelenggara sistem storan; biasanya terdapat pelbagai teknologi proprietari untuk membuat syot kilat, penyahduplikasi terbina dalam dan kegembiraan lain pentadbir sistem , dibincangkan dalam bahagian sebelumnya dalam siri ini. Jumlah tatasusunan cakera pelayan khusus boleh mencapai beberapa puluh terabait, bergantung pada bilangan dan saiz cakera yang disambungkan ke pelayan. Dalam kes VPS, volumnya lebih sederhana: biasanya tidak lebih daripada 100GB (tetapi terdapat juga lebih banyak), dan tarif untuk VPS tersebut dengan mudah boleh menjadi lebih mahal daripada pelayan khusus termurah dari hoster yang sama. VPS selalunya mempunyai satu cakera, kerana akan terdapat sistem storan (atau sesuatu yang hiperkonvergen) di bawahnya. Kadangkala VPS mempunyai beberapa cakera dengan ciri yang berbeza, untuk tujuan yang berbeza:
- sistem kecil - untuk memasang sistem pengendalian;
- besar - menyimpan data pengguna.
Apabila anda memasang semula sistem menggunakan panel kawalan, cakera dengan data pengguna tidak ditimpa, tetapi cakera sistem diisi semula sepenuhnya. Juga, dalam kes VPS, hoster mungkin menawarkan butang yang mengambil gambar keadaan VPS (atau cakera), tetapi jika anda memasang sistem pengendalian anda sendiri atau terlupa untuk mengaktifkan perkhidmatan yang dikehendaki di dalam VPS, beberapa data mungkin masih hilang. Sebagai tambahan kepada butang, perkhidmatan penyimpanan data biasanya ditawarkan, selalunya sangat terhad. Biasanya ini ialah akaun dengan akses melalui FTP atau SFTP, kadangkala bersama-sama dengan SSH, dengan cangkerang yang dilucutkan (contohnya, rbash), atau sekatan untuk menjalankan arahan melalui authorized_keys (melalui ForcedCommand).
Pelayan khusus disambungkan ke rangkaian melalui dua port dengan kelajuan 1 Gbps, kadangkala ini boleh menjadi kad dengan kelajuan 10 Gbps. VPS selalunya mempunyai satu antara muka rangkaian. Selalunya, pusat data tidak mengehadkan kelajuan rangkaian dalam pusat data, tetapi mereka mengehadkan kelajuan akses Internet.
Muatan biasa pelayan khusus atau VPS adalah pelayan web, pangkalan data dan pelayan aplikasi. Kadangkala pelbagai perkhidmatan tambahan tambahan boleh dipasang, termasuk untuk pelayan web atau pangkalan data: enjin carian, sistem mel, dsb.
Pelayan yang disediakan khas bertindak sebagai ruang untuk menyimpan salinan sandaran; kami akan menulis mengenainya dengan lebih terperinci kemudian.
Organisasi logik sistem cakera
Jika anda mempunyai pengawal RAID, atau VPS dengan satu cakera, dan tiada keutamaan khas untuk pengendalian subsistem cakera (contohnya, cakera pantas yang berasingan untuk pangkalan data), semua ruang kosong dibahagikan seperti berikut: satu partition dicipta, dan kumpulan volum LVM dibuat di atasnya, beberapa jilid dicipta di dalamnya: 2 jilid kecil dengan saiz yang sama, digunakan sebagai sistem fail akar (diubah satu demi satu semasa kemas kini untuk kemungkinan rollback cepat, idea itu diambil daripada pengedaran Kira Linux), satu lagi adalah untuk partition swap, ruang kosong yang selebihnya dibahagikan kepada jilid kecil , digunakan sebagai sistem fail akar untuk bekas penuh, cakera untuk mesin maya, fail sistem untuk akaun di /home (setiap akaun mempunyai sistem fail sendiri), sistem fail untuk bekas aplikasi.
Nota penting: jilid mestilah serba lengkap, i.e. tidak harus bergantung antara satu sama lain atau pada sistem fail akar. Dalam kes mesin atau bekas maya, titik ini diperhatikan secara automatik. Jika ini adalah bekas aplikasi atau direktori rumah, anda harus berfikir tentang mengasingkan fail konfigurasi pelayan web dan perkhidmatan lain dengan cara untuk menghapuskan kebergantungan antara volum sebanyak mungkin. Sebagai contoh, setiap tapak dijalankan daripada penggunanya sendiri, fail konfigurasi tapak berada dalam direktori rumah pengguna, dalam tetapan pelayan web, fail konfigurasi tapak tidak disertakan melalui /etc/nginx/conf.d/.conf, dan, sebagai contoh, /home//configs/nginx/*.conf
Jika terdapat beberapa cakera, anda boleh mencipta tatasusunan RAID perisian (dan mengkonfigurasi cachingnya pada SSD, jika ada keperluan dan peluang), di atasnya anda boleh membina LVM mengikut peraturan yang dicadangkan di atas. Juga dalam kes ini, anda boleh menggunakan ZFS atau BtrFS, tetapi anda harus berfikir dua kali tentang perkara ini: kedua-duanya memerlukan pendekatan yang lebih serius terhadap sumber, dan selain itu, ZFS tidak disertakan dengan kernel Linux.
Terlepas dari skema yang digunakan, ia sentiasa bernilai menganggarkan lebih awal anggaran kelajuan menulis perubahan pada cakera, dan kemudian mengira jumlah ruang kosong yang akan dikhaskan untuk membuat syot kilat. Contohnya, jika pelayan kami menulis data pada kelajuan 10 megabait sesaat, dan saiz keseluruhan tatasusunan data ialah 10 terabait - masa penyegerakan boleh mencecah sehari (22 jam - ini ialah jumlah volum sedemikian yang akan dipindahkan melalui rangkaian 1 Gbps) - ia patut ditempah kira-kira 800 GB . Pada hakikatnya, angka itu akan menjadi lebih kecil; anda boleh membahagikannya dengan selamat dengan bilangan volum logik.
Peranti pelayan storan sandaran
Perbezaan utama antara pelayan untuk menyimpan salinan sandaran ialah cakeranya yang besar, murah dan agak perlahan. Oleh kerana HDD moden telah melintasi bar 10TB dalam satu cakera, adalah perlu untuk menggunakan sistem fail atau RAID dengan jumlah semak, kerana semasa pembinaan semula tatasusunan atau pemulihan sistem fail (beberapa hari!) cakera kedua mungkin gagal disebabkan oleh kepada peningkatan beban. Pada cakera dengan kapasiti sehingga 1TB ini tidak begitu sensitif. Untuk kesederhanaan penerangan, saya menganggap bahawa ruang cakera dibahagikan kepada dua bahagian yang lebih kurang saiznya (sekali lagi, sebagai contoh, menggunakan LVM):
- volum sepadan dengan pelayan yang digunakan untuk menyimpan data pengguna (sandaran terakhir yang dibuat akan digunakan pada mereka untuk pengesahan);
- jilid yang digunakan sebagai repositori BorgBackup (data untuk sandaran akan pergi terus ke sini).
Prinsip operasi ialah volum berasingan dicipta untuk setiap pelayan untuk repositori BorgBackup, di mana data daripada pelayan pertempuran akan pergi. Repositori beroperasi dalam mod tambahan sahaja, yang menghapuskan kemungkinan memadam data secara sengaja, dan disebabkan penyahduplikasian dan pembersihan berkala repositori daripada sandaran lama (salinan tahunan kekal, bulanan untuk tahun lepas, mingguan untuk bulan lepas, setiap hari untuk minggu lepas, mungkin dalam kes khas - setiap jam untuk hari terakhir: jumlah 24 + 7 + 4 + 12 + tahunan - kira-kira 50 salinan untuk setiap pelayan).
Repositori BorgBackup tidak mendayakan mod tambahan sahaja; sebaliknya, ForcedCommand dalam .ssh/authorized_keys digunakan seperti ini:
from="Π°Π΄ΡΠ΅Ρ ΡΠ΅ΡΠ²Π΅ΡΠ°",command="/usr/local/bin/borg serve --append-only --restrict-to-path /home/servername/borgbackup/",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-user-rc AAAAA.......Laluan yang ditentukan mengandungi skrip pembalut di atas borg, yang, selain melancarkan binari dengan parameter, juga memulakan proses memulihkan salinan sandaran selepas data dialih keluar. Untuk melakukan ini, skrip pembalut mencipta fail tag di sebelah repositori yang sepadan. Sandaran terakhir yang dibuat secara automatik dipulihkan kepada volum logik yang sepadan selepas proses pengisian data selesai.
Reka bentuk ini membolehkan anda membersihkan sandaran yang tidak perlu secara berkala, dan juga menghalang pelayan pertempuran daripada memadamkan apa-apa pada pelayan storan sandaran.
Proses Sandaran
Pemula sandaran ialah pelayan khusus atau VPS itu sendiri, kerana skim ini memberikan lebih kawalan ke atas proses sandaran di pihak pelayan ini. Pertama, petikan keadaan sistem fail akar aktif diambil, yang dipasang dan dimuat naik menggunakan BorgBackup ke pelayan storan sandaran. Selepas tangkapan data selesai, syot kilat dinyahlekap dan dipadamkan.
Jika terdapat pangkalan data kecil (sehingga 1 GB untuk setiap tapak), longgokan pangkalan data dibuat, yang disimpan dalam volum logik yang sesuai, di mana seluruh data untuk tapak yang sama terletak, tetapi supaya longgokan itu tidak boleh diakses melalui pelayan web. Jika pangkalan data adalah besar, anda harus mengkonfigurasi penyingkiran data "panas", contohnya, menggunakan xtrabackup untuk MySQL, atau bekerjasama dengan WAL dengan archive_command dalam PostgreSQL. Dalam kes ini, pangkalan data akan dipulihkan secara berasingan daripada data tapak.
Jika bekas atau mesin maya digunakan, anda harus mengkonfigurasi qemu-guest-agent, CRIU atau teknologi lain yang diperlukan. Dalam kes lain, tetapan tambahan selalunya tidak diperlukan - kami hanya mencipta syot kilat volum logik, yang kemudiannya diproses dengan cara yang sama seperti syot kilat keadaan sistem fail akar. Selepas data diambil, gambar dipadamkan.
Kerja lanjut dijalankan pada pelayan storan sandaran:
- sandaran terakhir yang dibuat dalam setiap repositori disemak,
- kehadiran fail tanda disemak, menunjukkan bahawa proses pengumpulan data telah selesai,
- data dikembangkan kepada volum tempatan yang sepadan,
- fail tag dipadamkan
Proses pemulihan pelayan
Jika pelayan utama mati, maka pelayan khusus yang serupa dilancarkan, yang but daripada beberapa imej standard. Kemungkinan besar muat turun akan berlaku melalui rangkaian, tetapi juruteknik pusat data yang menyediakan pelayan boleh segera menyalin imej standard ini ke salah satu cakera. Muat turun berlaku ke dalam RAM, selepas itu proses pemulihan bermula:
- permintaan dibuat untuk melampirkan peranti blok melalui iscsinbd atau protokol lain yang serupa kepada volum logik yang mengandungi sistem fail akar pelayan yang telah mati; Memandangkan sistem fail akar mestilah kecil, langkah ini perlu diselesaikan dalam beberapa minit. Pemuat but juga dipulihkan;
- struktur volum logik tempatan dicipta semula, volum logik dilampirkan daripada pelayan sandaran menggunakan modul kernel dm_clone: ββpemulihan data bermula, dan perubahan ditulis serta-merta ke cakera tempatan
- bekas dilancarkan dengan semua cakera fizikal yang tersedia - kefungsian pelayan dipulihkan sepenuhnya, tetapi dengan prestasi yang berkurangan;
- selepas penyegerakan data selesai, volum logik dari pelayan sandaran diputuskan sambungan, bekas dimatikan, dan pelayan dibut semula;
Selepas but semula, pelayan akan mempunyai semua data yang ada pada masa sandaran dibuat, dan juga akan memasukkan semua perubahan yang dibuat semasa proses pemulihan.
Artikel lain dalam siri ini
Sandaran Bahagian 7: Kesimpulan
Saya menjemput anda untuk membincangkan pilihan yang dicadangkan dalam ulasan, terima kasih atas perhatian anda!
Sumber: www.habr.com