Questa nota conclude il ciclo di backup. Si discuterà dell'organizzazione logica di un server dedicato (o VPS), adatta per il backup, e sarà proposta una soluzione per il ripristino rapido del server da un backup senza significativi tempi di inattività in caso di guasti.
Dati di origine
Un server dedicato ha di solito almeno due dischi rigidi, utilizzati per costituire un array RAID di primo livello (mirror). Questo è necessario per garantire la continuità operativa del server nel caso in cui un disco fallisca. Se si tratta di un server dedicato standard, può esserci un controller RAID hardware dedicato, con tecnologia di caching attiva su SSD, in modo che, oltre ai dischi rigidi normali, possa essere collegato uno o più SSD. A volte vengono offerti server dedicati che hanno come dischi locali solo SATADOM (piccoli dischi, strutturalmente — chiavette, collegate a una porta SATA), o addirittura una piccola chiavetta (8-16 GB), collegata a una porta interna speciale, mentre i dati vengono prelevati da uno storage SAN, connesso tramite una rete dedicata (Ethernet 10G, FC, ecc.), o ci sono server dedicati che si avviano direttamente dallo storage SAN. Non tratterò queste opzioni, poiché in tali casi la responsabilità del backup del server passa agli specialisti che gestiscono lo storage SAN, che di solito hanno diverse tecnologie proprietarie per creare snapshot, deduplicazione integrata e altri vantaggi per il system administrator, discussi nelle parti precedenti di questo ciclo. La capacità dell'array disco di un server dedicato può raggiungere diverse decine di terabyte, a seconda del numero e della capacità dei dischi connessi al server. Nel caso dei VPS, le dimensioni sono più modeste: di solito non oltre i 100 GB (anche se ci sono eccezioni), e le tariffe per tali VPS possono facilmente essere più elevate rispetto ai server dedicati più economici offerti dallo stesso host. Nel caso dei VPS, di solito c'è un solo disco, poiché sotto di esso ci sarà uno storage SAN (o qualcosa di iperconvergente). A volte i VPS hanno più dischi con diverse caratteristiche, per scopi diversi:
- piccolo sistema — per l'installazione del sistema operativo;
- grande — per lo storage di dati utente.
Durante la reinstallazione del sistema tramite il pannello di controllo, il disco contenente i dati utente non viene sovrascritto, mentre il sistema viene completamente ripristinato. Inoltre, nel caso di un VPS, l'host può offrire un pulsante per creare uno snapshot dello stato del VPS (o del disco), ma se viene installato un sistema operativo personalizzato o si dimentica di attivare il servizio necessario all'interno del VPS, alcuni dati potrebbero comunque andare persi. Oltre al pulsante, di solito viene offerta una soluzione di storage, spesso molto limitata. Di solito, si tratta di un account con accesso tramite protocollo FTP o SFTP, a volte insieme a SSH, con shell limitata (ad esempio rbash), o con limitazioni nell'esecuzione di comandi tramite authorized_keys (tramite ForcedCommand).
Il server dedicato è connesso alla rete tramite due porte con velocità di 1 Gbit/s, a volte possono essere schede con velocità di 10 Gbit/s. Nel caso dei VPS, l'interfaccia di rete è di solito una sola. Di solito, i data center non limitano la velocità della rete all'interno del data center, ma limitano la velocità di accesso a Internet.
Il carico tipico di un server dedicato o di un VPS consiste in un server web, un database e un server applicazioni. Possono essere installati anche vari servizi ausiliari, inclusi per il server web o il database: motori di ricerca, sistemi di posta, ecc.
Come spazio di archiviazione per i backup viene utilizzato un server appositamente preparato, di cui si parlerà in dettaglio più avanti.
Organizzazione logica del sistema disco
Se c'è un controller RAID, o si tratta di un VPS con un disco solo, e non ci sono preferenze specifiche per il funzionamento del sottosistema disco (ad esempio, un disco veloce separato per il database), tutto lo spazio libero viene suddiviso in questo modo: viene creato un unico volume, su di esso viene creato un gruppo di volumi LVM, in cui vengono creati diversi volumi: 2 piccoli di dimensioni uguali, utilizzati come file system root (che vengono alternati durante gli aggiornamenti per consentire un rapido rollback, idea ispirata dalla distribuzione Calculate Linux), un altro — per la partizione di swap, il resto dello spazio libero viene suddiviso in volumi più piccoli, utilizzati come file system root per container completi, dischi per macchine virtuali, file system per account in /home (ogni account ha il proprio file system), file system per container-applicazioni.
Nota importante: i volumi devono essere completamente autonomi, cioè non devono dipendere l'uno dall'altro né dal filesystem radice. Nel caso di macchine virtuali o container, questo aspetto viene rispettato automaticamente. Tuttavia, se si tratta di container per applicazioni o directory home, è opportuno considerare di separare i file di configurazione del server web e altri servizi in modo da ridurre al minimo le dipendenze tra i volumi. Ad esempio, ogni sito funziona con il proprio utente, i file di configurazione del sito sono nella home dell'utente, nelle impostazioni del server web i file di configurazione dei siti non sono inclusi tramite /etc/nginx/conf.d/.conf, ma, ad esempio, /home//configs/nginx/*.conf
Se ci sono più dischi, è possibile creare un array RAID software (e configurarne la cache su SSD, se necessario e possibile), sopra il quale costruire LVM secondo le regole suggerite in precedenza. Anche in questo caso è possibile utilizzare ZFS o BtrFS, ma vale la pena riflettere: entrambi richiedono un approccio molto più serio alle risorse, inoltre ZFS non è incluso nel kernel Linux.
Indipendentemente dallo schema utilizzato, è sempre utile stimare in anticipo la velocità di scrittura delle modifiche sui dischi e calcolare lo spazio libero che sarà riservato per la creazione di snapshot. Ad esempio, se il nostro server scrive dati a una velocità di 10 megabyte al secondo e la dimensione dell'intero array di dati è di 10 terabyte, il tempo di sincronizzazione potrebbe raggiungere un giorno (22 ore - tanto tempo impiegherebbe a trasferire tale volume su una rete 1 Gbit/s) - sarebbe opportuno riservare circa 800 GB. In realtà, il numero sarà inferiore, si può tranquillamente dividerlo per il numero di volumi logici.
Dispositivo server per il backup
La principale differenza di un server per il backup è costituita da dischi grandi, economici e relativamente lenti. Poiché i moderni HDD hanno già superato il limite di 10 TB in un singolo disco, è imprescindibile l'uso di filesystem o RAID con checksum, poiché durante la ristrutturazione dell'array o il ripristino del filesystem (che può durare diversi giorni!) potrebbe guastarsi il secondo disco a causa dell'aumento del carico. Con dischi da 1 TB non si avvertiva così tanto. Per semplificare la descrizione, presumo che lo spazio su disco sia diviso in due parti di dimensioni simili (ancora, ad esempio, utilizzando LVM):
- volumi corrispondenti sui server, utilizzati per memorizzare i dati degli utenti (su di essi sarà distribuita l'ultima copia di backup effettuata per il controllo);
- volumi utilizzati come repository BorgBackup (qui verranno memorizzati direttamente i dati per i backup).
Il principio di funzionamento consiste nel creare volumi separati per ciascun server destinati ai repository BorgBackup, dove giungeranno i dati dai server in produzione. I repository funzionano in modalità append-only, escludendo la possibilità di eliminare intenzionalmente i dati, e grazie alla deduplicazione e alla pulizia periodica dei repository dai vecchi backup (rimangono le copie annuali, quelle mensili per l'ultimo anno, settimanali per l'ultimo mese, giornaliere per l'ultima settimana, possibilmente - in casi speciali - orarie per l'ultimo giorno: in totale 24 + 7 + 4 + 12 + annuali - circa 50 copie per ogni server).
Nei repository BorgBackup non è attivata la modalità append-only, ma viene utilizzato ForcedCommand in .ssh/authorized_keys in un formato del tipo:
from="indirizzo server",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.......Nel percorso specificato è presente uno script wrapper sopra Borg, che oltre a eseguire il binario con i parametri, avvia anche il processo di ripristino del backup dopo il completamento del recupero dei dati. A tal fine, lo script wrapper crea un file di segnalazione accanto al relativo repository. L'ultima copia di backup effettuata viene automaticamente ripristinata sul corrispondente volume logico al termine del processo di upload dei dati.
Questa struttura consente di pulire periodicamente i backup non necessari e non permette ai server di produzione di eliminare nulla sul server di storage per i backup.
Il processo di backup
Il server dedicato o VPS funge da iniziatore del backup, poiché questo schema offre un maggiore controllo sul processo di backup da parte di questo server. Si inizia creando uno snapshot dello stato attivo del file system radice, che viene montato e caricato sul server di archiviazione dei backup utilizzando BorgBackup. Una volta conclusa l'acquisizione dei dati, lo snapshot viene smontato e rimosso.
Se si dispone di un piccolo database (fino a 1 GB per ciascun sito), si crea un dump del database, che viene salvato nel volume logico corrispondente, in modo che non sia accessibile tramite il server web. Se i database sono di grandi dimensioni, è opportuno configurare l'acquisizione dei dati 'a caldo', ad esempio tramite xtrabackup per MySQL, o utilizzare WAL con archive_command in PostgreSQL. In questo caso, il database verrà ripristinato separatamente dai dati dei siti.
Se vengono utilizzati contenitori o macchine virtuali, è necessario configurare qemu-guest-agent, CRIU o altre tecnologie necessarie. Negli altri casi, generalmente non è necessaria una configurazione aggiuntiva: si creano semplicemente snapshot dei volumi logici, che vengono poi elaborati analogamente allo snapshot dello stato del file system radice. Dopo l'acquisizione dei dati, gli snapshot vengono rimossi.
Il lavoro successivo avviene sul server di archiviazione dei backup:
- si verifica l'ultimo backup eseguito in ciascun repository,
- si controlla l'esistenza di un file di etichetta che indica che il processo di acquisizione dei dati è completato,
- si esegue il ripristino dei dati sul volume locale corrispondente,
- si rimuove il file di etichetta
Il processo di ripristino della funzionalità del server
Se il server principale fallisce, viene avviato un server dedicato analogo, che si avvia da una certa immagine standard. Probabilmente il caricamento avverrà attraverso la rete, ma il tecnico del Data Center, responsabile della configurazione del server, può subito copiare quest'immagine standard su uno dei dischi. Il caricamento avviene nella memoria RAM, dopo di che inizia il processo di ripristino:
- viene inviata una richiesta per collegare un dispositivo di blocco tramite iscsinbd o un altro protocollo simile per il volume logico che contiene il file system radice del server guasto; poiché il file system radice deve essere di dimensioni contenute, questa fase dovrebbe completarsi entro pochi minuti. Viene inoltre eseguito il ripristino del bootloader;
- viene ricreata la struttura dei volumi logici locali e si collegano i volumi logici dal server di backup tramite il modulo del kernel dm_clone: inizia il ripristino dei dati, e le modifiche vengono registrate immediatamente sui dischi locali
- si avvia un contenitore con tutti i dischi fisici disponibili: si ripristina completamente la funzionalità del server, ma con prestazioni ridotte;
- al termine della sincronizzazione dei dati, i volumi logici dal server di backup vengono scollegati, il contenitore viene spento e il server viene riavviato;
Dopo il riavvio, il server avrà tutti i dati che erano presenti al momento della creazione del backup e includerà tutte le modifiche effettuate durante il processo di ripristino.
Altri articoli del ciclo
Backup, parte 7: Conclusioni
Vi invitiamo a discutere la proposta nei commenti, grazie per l'attenzione!
Fonte: habr.com
