Catatan ini melengkapi siklus tentang pencadangan. Ini akan membahas organisasi logis dari server khusus (atau VPS), nyaman untuk pencadangan, dan juga akan menawarkan opsi untuk memulihkan server dengan cepat dari cadangan tanpa banyak waktu henti jika terjadi bencana.
Data mentah
Server khusus paling sering memiliki setidaknya dua hard drive yang berfungsi untuk mengatur array RAID tingkat pertama (cermin). Hal ini diperlukan untuk dapat terus mengoperasikan server jika salah satu disk gagal. Jika ini adalah server khusus biasa, mungkin terdapat pengontrol RAID perangkat keras terpisah dengan teknologi caching aktif pada SSD, sehingga selain hard drive biasa, satu atau lebih SSD dapat dihubungkan. Kadang-kadang server khusus ditawarkan, di mana satu-satunya disk lokal adalah SATADOM (disk kecil, secara struktural merupakan flash drive yang terhubung ke port SATA), atau bahkan flash drive kecil biasa (8-16GB) yang terhubung ke port internal khusus, dan data diambil dari sistem penyimpanan, terhubung melalui jaringan penyimpanan khusus (Ethernet 10G, FC, dll.), dan ada server khusus yang dimuat langsung dari sistem penyimpanan. Saya tidak akan mempertimbangkan opsi seperti itu, karena dalam kasus seperti itu tugas mencadangkan server dengan lancar diteruskan ke spesialis yang memelihara sistem penyimpanan; biasanya ada berbagai teknologi eksklusif untuk membuat snapshot, deduplikasi bawaan, dan kesenangan lain dari administrator sistem , dibahas di bagian sebelumnya dari seri ini. Volume susunan disk server khusus dapat mencapai beberapa puluh terabyte, bergantung pada jumlah dan ukuran disk yang terhubung ke server. Dalam kasus VPS, volumenya lebih sederhana: biasanya tidak lebih dari 100GB (tetapi ada juga yang lebih besar), dan tarif untuk VPS tersebut bisa lebih mahal daripada server khusus termurah dari hoster yang sama. VPS paling sering memiliki satu disk, karena akan ada sistem penyimpanan (atau sesuatu yang hyperconverged) di bawahnya. Terkadang VPS memiliki beberapa disk dengan karakteristik berbeda, untuk tujuan berbeda:
- sistem kecil - untuk menginstal sistem operasi;
- besar - menyimpan data pengguna.
Saat Anda menginstal ulang sistem menggunakan panel kontrol, disk dengan data pengguna tidak ditimpa, tetapi disk sistem terisi penuh. Selain itu, dalam kasus VPS, penghosting mungkin menawarkan tombol yang mengambil cuplikan status VPS (atau disk), tetapi jika Anda menginstal sistem operasi Anda sendiri atau lupa mengaktifkan layanan yang diinginkan di dalam VPS, beberapa datanya mungkin masih hilang. Selain tombol, layanan penyimpanan data biasanya ditawarkan, seringkali sangat terbatas. Biasanya ini adalah akun dengan akses melalui FTP atau SFTP, terkadang bersama dengan SSH, dengan shell yang dipreteli (misalnya, rbash), atau pembatasan menjalankan perintah melalui otor_keys (melalui ForcedCommand).
Server khusus terhubung ke jaringan melalui dua port dengan kecepatan 1 Gbps, terkadang bisa berupa kartu dengan kecepatan 10 Gbps. VPS paling sering memiliki satu antarmuka jaringan. Seringkali, pusat data tidak membatasi kecepatan jaringan di dalam pusat data, namun membatasi kecepatan akses Internet.
Beban khas dari dedicated server atau VPS adalah server web, database, dan server aplikasi. Terkadang berbagai layanan tambahan tambahan dapat diinstal, termasuk untuk server web atau database: mesin pencari, sistem email, dll.
Server yang disiapkan secara khusus berfungsi sebagai ruang untuk menyimpan salinan cadangan, kami akan menulisnya lebih detail nanti.
Organisasi logis dari sistem disk
Jika Anda memiliki pengontrol RAID, atau VPS dengan satu disk, dan tidak ada preferensi khusus untuk pengoperasian subsistem disk (misalnya, disk cepat terpisah untuk database), semua ruang kosong dibagi sebagai berikut: satu partisi dibuat, dan grup volume LVM dibuat di atasnya, beberapa volume dibuat di dalamnya: 2 volume kecil dengan ukuran yang sama, digunakan sebagai sistem file root (diubah satu per satu selama pembaruan untuk kemungkinan rollback cepat, idenya diambil dari distribusi Hitung Linux), satu lagi untuk partisi swap, sisa ruang kosong dibagi menjadi volume-volume kecil, digunakan sebagai sistem file root untuk container lengkap, disk untuk mesin virtual, file sistem untuk akun di /home (setiap akun memiliki sistem file sendiri), sistem file untuk wadah aplikasi.
Catatan penting: volume harus sepenuhnya mandiri, mis. tidak boleh bergantung satu sama lain atau pada sistem file root. Dalam kasus mesin virtual atau container, momen ini diamati secara otomatis. Jika ini adalah wadah aplikasi atau direktori home, Anda harus mempertimbangkan untuk memisahkan file konfigurasi server web dan layanan lain sedemikian rupa untuk menghilangkan ketergantungan antar volume sebanyak mungkin. Misalnya, setiap situs dijalankan dari penggunanya sendiri, file konfigurasi situs ada di direktori home pengguna, dalam pengaturan server web, file konfigurasi situs tidak disertakan melalui /etc/nginx/conf.d/.conf, dan, misalnya, /home//configs/nginx/*.conf
Jika ada beberapa disk, Anda dapat membuat array RAID perangkat lunak (dan mengkonfigurasi cachingnya pada SSD, jika ada kebutuhan dan peluang), di atasnya Anda dapat membangun LVM sesuai dengan aturan yang diusulkan di atas. Juga dalam hal ini, Anda dapat menggunakan ZFS atau BtrFS, tetapi Anda harus berpikir dua kali tentang hal ini: keduanya memerlukan pendekatan sumber daya yang jauh lebih serius, dan selain itu, ZFS tidak disertakan dengan kernel Linux.
Terlepas dari skema yang digunakan, ada baiknya selalu memperkirakan terlebih dahulu perkiraan kecepatan penulisan perubahan ke disk, dan kemudian menghitung jumlah ruang kosong yang akan dicadangkan untuk membuat snapshot. Misalnya, jika server kami menulis data dengan kecepatan 10 megabyte per detik, dan ukuran seluruh array data adalah 10 terabyte - waktu sinkronisasi dapat mencapai satu hari (22 jam - ini adalah jumlah volume yang akan ditransfer melalui jaringan 1 Gbps) - perlu dicadangkan sekitar 800 GB . Pada kenyataannya, angkanya akan lebih kecil, Anda dapat membaginya dengan aman dengan jumlah volume logis.
Perangkat server penyimpanan cadangan
Perbedaan utama antara server untuk menyimpan salinan cadangan adalah disknya yang besar, murah, dan relatif lambat. Karena HDD modern telah melewati batas 10 TB dalam satu disk, maka perlu menggunakan sistem file atau RAID dengan checksum, karena selama pembangunan kembali array atau pemulihan sistem file (beberapa hari!), disk kedua mungkin gagal karena untuk meningkatkan beban. Pada disk dengan kapasitas hingga 1TB hal ini tidak terlalu sensitif. Untuk mempermudah penjelasan, saya berasumsi bahwa ruang disk dibagi menjadi dua bagian dengan ukuran yang kira-kira sama (sekali lagi, misalnya, menggunakan LVM):
- volume yang sesuai dengan server yang digunakan untuk menyimpan data pengguna (cadangan terakhir yang dibuat akan digunakan untuk verifikasi);
- volume yang digunakan sebagai repositori BorgBackup (data untuk cadangan akan langsung masuk ke sini).
Prinsip operasinya adalah volume terpisah dibuat untuk setiap server untuk repositori BorgBackup, tempat data dari server tempur akan dikirim. Repositori beroperasi dalam mode hanya tambahan, yang menghilangkan kemungkinan penghapusan data secara sengaja, dan karena deduplikasi dan pembersihan repositori secara berkala dari cadangan lama (salinan tahunan tetap ada, bulanan selama setahun terakhir, mingguan selama sebulan terakhir, setiap hari selama setahun) minggu lalu, mungkin dalam kasus khusus - setiap jam pada hari terakhir: total 24 + 7 + 4 + 12 + tahunan - sekitar 50 eksemplar untuk setiap server).
Repositori BorgBackup tidak mengaktifkan mode tambahan saja; sebagai gantinya, ForcedCommand di .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.......Jalur yang ditentukan berisi skrip pembungkus di atas borg, yang selain meluncurkan biner dengan parameter, juga memulai proses memulihkan salinan cadangan setelah data dihapus. Untuk melakukan ini, skrip wrapper membuat file tag di sebelah repositori yang sesuai. Cadangan terakhir yang dibuat secara otomatis dikembalikan ke volume logis yang sesuai setelah proses pengisian data selesai.
Desain ini memungkinkan Anda membersihkan cadangan yang tidak diperlukan secara berkala, dan juga mencegah server tempur menghapus apa pun di server penyimpanan cadangan.
Proses Pencadangan
Pemrakarsa pencadangan adalah server khusus atau VPS itu sendiri, karena skema ini memberikan kontrol lebih besar atas proses pencadangan di pihak server ini. Pertama, snapshot status sistem file root aktif diambil, yang dipasang dan diunggah menggunakan BorgBackup ke server penyimpanan cadangan. Setelah pengambilan data selesai, snapshot dilepas dan dihapus.
Jika ada database kecil (hingga 1 GB untuk setiap situs), dump database dibuat, yang disimpan dalam volume logis yang sesuai, di mana sisa data untuk situs yang sama berada, tetapi dump tersebut berada tidak dapat diakses melalui server web. Jika databasenya besar, Anda harus mengonfigurasi penghapusan data "panas", misalnya menggunakan xtrabackup untuk MySQL, atau bekerja dengan WAL dengan archive_command di PostgreSQL. Dalam hal ini, database akan dipulihkan secara terpisah dari data situs.
Jika kontainer atau mesin virtual digunakan, Anda harus mengonfigurasi qemu-guest-agent, CRIU, atau teknologi lain yang diperlukan. Dalam kasus lain, pengaturan tambahan seringkali tidak diperlukan - kami cukup membuat snapshot dari volume logis, yang kemudian diproses dengan cara yang sama seperti snapshot dari status sistem file root. Setelah data diambil, gambar dihapus.
Pekerjaan lebih lanjut dilakukan di server penyimpanan cadangan:
- cadangan terakhir yang dibuat di setiap repositori diperiksa,
- keberadaan file tanda diperiksa, menunjukkan bahwa proses pengumpulan data telah selesai,
- data diperluas ke volume lokal yang sesuai,
- file tag dihapus
Proses pemulihan server
Jika server utama mati, maka server khusus serupa diluncurkan, yang melakukan booting dari beberapa image standar. Kemungkinan besar pengunduhan akan dilakukan melalui jaringan, namun teknisi pusat data yang menyiapkan server dapat segera menyalin gambar standar ini ke salah satu disk. Pengunduhan terjadi ke dalam RAM, setelah itu proses pemulihan dimulai:
- permintaan dibuat untuk melampirkan perangkat blok melalui iscsinbd atau protokol serupa lainnya ke volume logis yang berisi sistem file root dari server yang telah meninggal; Karena sistem file root harus kecil, langkah ini akan selesai dalam beberapa menit. Bootloader juga dipulihkan;
- struktur volume logis lokal dibuat ulang, volume logis dilampirkan dari server cadangan menggunakan modul kernel dm_clone: ββpemulihan data dimulai, dan perubahan segera ditulis ke disk lokal
- sebuah wadah diluncurkan dengan semua disk fisik yang tersedia - fungsionalitas server dipulihkan sepenuhnya, tetapi dengan kinerja yang berkurang;
- setelah sinkronisasi data selesai, volume logis dari server cadangan terputus, wadah dimatikan, dan server di-boot ulang;
Setelah reboot, server akan memiliki semua data yang ada pada saat pencadangan dibuat, dan juga akan menyertakan semua perubahan yang dibuat selama proses pemulihan.
Artikel lain dalam seri ini
Cadangan Bagian 7: Kesimpulan
Saya mengundang Anda untuk mendiskusikan opsi yang diusulkan di komentar, terima kasih atas perhatian Anda!
Sumber: www.habr.com