Questa nota conclude il ciclo sul backup. Qui si discuterà dell'organizzazione logica di un server dedicato (o VPS), ideale per il backup, e verrà proposta una soluzione per il ripristino rapido del server da un backup senza significativi tempi di inattività in caso di guasto.
Dati di origine
Un server dedicato ha solitamente almeno due dischi rigidi, utilizzati per organizzare un array RAID di primo livello (mirror). Questo è necessario per garantire la continuità operativa del server anche se un disco si guasta. Se si tratta di un server dedicato normale, può esserci un controller RAID hardware separato, con tecnologia di caching attiva su SSD, per cui oltre ai normali dischi rigidi può essere collegato uno o più SSD. A volte sono disponibili server dedicati che presentano solo dischi SATADOM (piccoli dischi, strutturalmente simili a chiavette USB, collegati a una porta SATA), o addirittura una piccola chiavetta USB (8-16 GB) collegata a una porta interna speciale, e i dati vengono prelevati da un sistema di archiviazione connesso tramite una rete dedicata (Ethernet 10G, FC, ecc.), e ci sono server dedicati che si avviano direttamente dal sistema di archiviazione. Non tratterò queste opzioni, poiché in tali casi il compito del backup del server passa al tecnico che gestisce il sistema di archiviazione, dove solitamente ci sono varie tecnologie proprietarie per la creazione di snapshot, deduplicazione integrata e altre comodità per gli amministratori di sistema, già esaminate 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 dimensione dei dischi collegati al server. Nel caso di VPS, le dimensioni sono più contenute: solitamente non oltre 100 GB (ma ci sono anche più grandi), e le tariffe per tali VPS possono facilmente essere superiori a quelle dei server dedicati più economici dallo stesso fornitore. Di solito, un VPS ha un solo disco, poiché ci sarà un sistema di archiviazione (o qualcosa di ipercostruito). A volte, un VPS ha più dischi con diverse caratteristiche, per scopi diversi:
- piccolo sistema — per l'installazione del sistema operativo;
- grande — per la memorizzazione dei dati degli utenti.
Durante la reinstallazione del sistema tramite il pannello di controllo, il disco con i dati dell'utente non viene sovrascritto, mentre quello di sistema viene completamente rimpiazzato. Inoltre, nel caso di un VPS, il provider può offrire un pulsante che crea uno snapshot dello stato del VPS (o del disco), tuttavia, se si installa un proprio sistema operativo o si dimentica di attivare il servizio necessario all'interno del VPS, parte dei dati potrebbe comunque andare persa. In aggiunta al pulsante, di solito viene offerto un servizio di archiviazione dei dati, spesso molto limitato. Di solito, si tratta di un account con accesso tramite protocollo FTP o SFTP, a volte insieme a SSH, con una shell limitata (ad esempio rbash), oppure con restrizioni nell'esecuzione di comandi tramite authorized_keys (attraverso ForcedCommand).
Un server dedicato è collegato alla rete tramite due porte con una velocità di 1 Gbps; a volte possono essere presenti schede con una velocità di 10 Gbps. In un VPS, l'interfaccia di rete è di solito una sola. Generalmente, i data center non limitano la velocità di 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 comprende un server web, un database e un server applicazioni. Possono essere installati anche vari servizi ausiliari, tra cui per il server web o il database: motore di ricerca, sistema di posta elettronica, ecc.
Come spazio per il backup viene utilizzato un server appositamente preparato, di cui si parlerà più dettagliatamente in seguito.
Organizzazione logica del sistema di file
Se c'è un controller RAID, o è un VPS con un solo disco, e non ci sono particolari preferenze sul 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'unica partizione, su di essa viene creata un gruppo di volumi LVM, in cui vengono creati diversi volumi: 2 piccoli volumi della stessa dimensione, utilizzati come filesystem radice (cambiati a turno durante gli aggiornamenti per consentire un rapido ripristino, idea presa dalla distribuzione Calculate Linux), un altro — per la partizione di swap, il resto dello spazio libero viene suddiviso in piccoli volumi, utilizzati come filesystem radice per contenitori completi, dischi per macchine virtuali, filesystem per gli account in /home (ogni account ha il proprio filesystem), filesystem per contenitori di 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 contenitori, questo aspetto è rispettato automaticamente. Se invece si tratta di contenitori di applicazioni o di directory home, è consigliabile considerare la separazione dei file di configurazione del server Web e di 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 directory home dell'utente, nelle impostazioni del server Web i file di configurazione dei siti non vengono inclusi tramite /etc/nginx/conf.d/.conf, ma, ad esempio, /home//configs/nginx/*.conf
Se invece ci sono più dischi — è possibile creare un array RAID software (e configurare la sua cache su SSD, se necessario e possibile), su cui costruire LVM secondo le regole sopra indicate. In questo caso è possibile usare anche ZFS o BtrFS, ma è necessario riflettere due volte: entrambi richiedono un approccio molto più serio alle risorse, inoltre ZFS non è incluso nel kernel di Linux.
Indipendentemente dallo schema utilizzato, è sempre opportuno stimare in anticipo la velocità di scrittura dei cambiamenti sui dischi, dopodiché calcolare la dimensione dello spazio libero che sarà riservato per la creazione delle istantanee. Ad esempio, se il nostro server scrive dati a una velocità di 10 megabyte al secondo e la dimensione totale dell'array di dati è di 10 terabyte, il tempo di sincronizzazione può arrivare fino a un giorno (22 ore, è il tempo necessario per trasmettere tale quantità tramite una rete da 1 Gbit/s) — è consigliabile riservare circa 800 GB. In realtà, il numero sarà minore; può essere tranquillamente diviso per il numero di volumi logici.
Dispositivo server per lo storage dei backup
La principale differenza di un server per lo storage dei backup è rappresentata da dischi grandi, economici e relativamente lenti. Poiché i moderni HDD hanno già superato la soglia di 10 TB per disco, è indispensabile applicare file system o RAID con checksum, perché durante la riconfigurazione dell'array o il ripristino del file system (che può richiedere diversi giorni!) potrebbe guastarsi un secondo disco a causa del carico elevato. Con dischi di capacità fino a 1 TB non era così sensibile. Per semplicità, suppongo che lo spazio disco sia suddiviso in due parti di dimensioni approssimativamente uguali (ancora una volta, ad esempio, usando LVM):
- volumi, corrispondenti ai server utilizzati per lo storage dei dati utente (su di essi verrà distribuita l'ultima copia di backup effettuata per il controllo);
- volumi, utilizzati come repository di BorgBackup (qui verranno direttamente immessi i dati per i backup).
Il principio di funzionamento consiste nel creare volumi separati per ciascun server sotto i repository di BorgBackup, dove verranno trasferiti i dati dai server di produzione. I repository funzionano in modalità solo append, escludendo la possibilità di cancellazione intenzionale dei dati, e grazie alla deduplicazione e alla pulizia periodica dei repository dai vecchi backup (rimangono copie annuali, mensili dell'ultimo anno, settimanali dell'ultimo mese, quotidiane dell'ultima settimana; in particolari casi, anche orarie dell'ultimo giorno: in totale circa 50 copie per ogni server).
Nei repository di BorgBackup non si attiva la modalità solo aggiunta, bensì si utilizza ForcedCommand in .ssh/authorized_keys in questo modo:
from="indirizzo del 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 al termine del recupero dei dati. A tale scopo, lo script wrapper crea un file segnale vicino al relativo repository. L'ultima copia di backup eseguita viene automaticamente ripristinata sul volume logico corrispondente al termine del processo di upload dei dati.
Questa struttura consente di pulire periodicamente i backup non necessari e impedisce ai server di produzione di eliminare qualsiasi cosa sul server di archiviazione dei backup.
Il processo di backup
Il nodo che inizia il backup è direttamente il server dedicato o VPS, poiché questo schema offre un maggiore controllo sul processo di backup da parte di questo server. In primo luogo, viene creato uno snapshot dello stato del filesystem radice attivo, che viene montato e caricato utilizzando BorgBackup sul server di archiviazione dei backup. Al termine del recupero dei dati, lo snapshot viene smontato e rimosso.
Nel caso di una piccola base di dati (fino a 1 GB per ogni sito), viene realizzato un dump della base di dati, che viene salvato nel volume logico corrispondente, dove si trovano i restanti dati dello stesso sito, ma in modo che il dump non sia accessibile tramite il server web. Se invece le basi sono grandi, è necessario configurare il recupero dati 'a caldo', ad esempio utilizzando xtrabackup per MySQL, o lavorando con WAL con archive_command in PostgreSQL. In questo caso, la base di dati verrà ripristinata separatamente dai dati dei siti.
Se vengono utilizzati container o macchine virtuali, è necessario configurare qemu-guest-agent, CRIU o altre tecnologie necessarie. In altri casi, di solito non saranno necessarie impostazioni aggiuntive: basta creare snapshot dei volumi logici, che vengono poi elaborati analogamente allo snapshot dello stato del filesystem radice. Dopo il recupero dei dati, gli snapshot vengono rimossi.
Il lavoro successivo avviene sul server di archiviazione dei backup:
- Viene controllato l'ultimo backup eseguito in ogni repository,
- Viene controllata la presenza di un file di marcatura che indica che il processo di estrazione dei dati è completato,
- Viene eseguito il ripristino dei dati sul volume locale corrispondente,
- Il file di marcatura viene rimosso
Processo di ripristino della funzionalità del server
Se il server principale si guasta, viene avviato un server dedicato equivalente, che si avvia da un'immagine standard. Molto probabilmente, il caricamento avverrà tramite rete, tuttavia il tecnico del Data Center che imposta il server può copiare immediatamente quest'immagine standard su uno dei dischi. Il caricamento avviene nella memoria RAM, dopo di che inizia il processo di ripristino:
- Viene effettuata la richiesta per collegare il dispositivo a blocchi tramite iscsinbd o un altro protocollo simile del volume logico, contenente il file system radice del server guasto; poiché il file system radice deve essere di piccole dimensioni, questa fase dovrebbe essere completata in pochi minuti. Viene inoltre eseguito il ripristino del bootloader;
- Viene ricreata la struttura dei volumi logici locali, si collegano i volumi logici dal server di backup utilizzando il modulo del kernel dm_clone: inizia il ripristino dei dati e le modifiche vengono registrate immediatamente sui dischi locali
- Viene avviato un contenitore con tutti i dischi fisici disponibili - la funzionalità del server viene completamente ripristinata, ma con prestazioni ridotte;
- Al termine della sincronizzazione dei dati, i volumi logici dal server di backup vengono disconnessi, il contenitore viene spento e il server viene riavviato;
Dopo il riavvio, il server avrà tutti i dati presenti al momento della creazione del backup, oltre a includere tutte le modifiche apportate durante il processo di ripristino.
Altri articoli del ciclo
Backup, parte 7: Conclusioni
Invito a discutere la proposta nei commenti, grazie per l'attenzione!
Fonte: habr.com
