Den hÀr anteckningen avslutar serien om sÀkerhetskopiering. Den handlar om den logiska organisationen av en dedikerad server (eller VPS) som Àr lÀmplig för sÀkerhetskopiering, samt ett förslag pÄ snabb ÄterstÀllning av servern frÄn en sÀkerhetskopiering utan större driftstopp vid en krasch.
Ursprungliga data
En dedikerad server har oftast minst tvĂ„ hĂ„rddiskar som anvĂ€nds för att organisera ett RAID-array av första graden (spegel). Detta Ă€r nödvĂ€ndigt för att kunna fortsĂ€tta driften av servern om en disk gĂ„r sönder. Om det Ă€r en vanlig dedikerad server kan det finnas en separat hĂ„rdvaru-RAID-kontroller med aktiv SSD-cache, sĂ„ att en eller flera SSD-enheter kan kopplas till de vanliga hĂ„rddiskarna. Ibland erbjuds dedikerade servrar dĂ€r endast SATADOM-enheter (smĂ„ diskar, konstruktionellt â en USB-enhet som kopplas in i en SATA-port) finns, eller till och med en vanlig liten (8-16 GB) USB-enhet som kopplas in i en speciell intern port, och data hĂ€mtas frĂ„n lagringssystemet som Ă€r anslutet via ett dedikerat lagringsnĂ€tverk (10G Ethernet, FC, etc.), och det finns Ă€ven dedikerade servrar som startar direkt frĂ„n lagringssystemet. Jag kommer inte att diskutera sĂ„dana alternativ, eftersom uppgiften för serverns sĂ€kerhetskopiering ofta övergĂ„r till den specialist som underhĂ„ller lagringssystemet, dĂ€r det vanligtvis finns olika proprietĂ€ra teknologier för att skapa statusavbilder, inbyggd deduplicering och andra fördelar för systemadministratören som diskuterades i tidigare delar av denna serie. Volymen av lagringsarrayen för en dedikerad server kan nĂ„ flera tiotals terabyte, beroende pĂ„ antal och volym av diskar som Ă€r anslutna till servern. För VPS Ă€r volymerna mer blygsamma: vanligtvis högst 100 GB (men det kan ocksĂ„ finnas större), och priserna för sĂ„dana VPS kan lĂ€tt vara dyrare Ă€n de billigaste dedikerade servrarna frĂ„n samma hostingleverantör. VPS har oftast en disk, eftersom den kommer att vara kopplad till lagringssystemet (eller nĂ„got hyperkonvergerat). Ibland har VPS flera diskar med olika egenskaper för olika Ă€ndamĂ„l:
- liten systemdisk â för installation av operativsystemet;
- stor disk â för lagring av anvĂ€ndardata.
Vid ominstallation av systemet via kontrollpanelen skrivs inte disken med anvÀndardata över, medan det systemet skrivs över fullstÀndigt. I fallet med VPS kan vÀrdena erbjuda en knapp som tar en snapshot av VPS:ens (eller diskens) tillstÄnd, men om du installerar ditt eget operativsystem eller glömmer att aktivera den nödvÀndiga tjÀnsten inom VPS kan vissa data ÀndÄ gÄ förlorade. Utöver knappen erbjuds vanligtvis en datalagringstjÀnst, ofta kraftigt begrÀnsad. Normalt sett Àr detta ett konto med Ätkomst via FTP- eller SFTP-protokollet, ibland tillsammans med SSH, med en begrÀnsad shell (till exempel rbash), eller en begrÀnsning pÄ kommandon som kan köras via authorized_keys (via ForcedCommand).
Den dedikerade servern Àr ansluten till nÀtverket med tvÄ portar med en hastighet pÄ 1 Gbit/s, ibland kan det vara kort som har en hastighet pÄ 10 Gbit/s. VPS har oftast bara en nÀtverksgrÀnssnitt. Oftast begrÀnsar datacentren inte internethastigheten inom datacentret, men begrÀnsar hastigheten för internetÄtkomst.
Den typiska belastningen pÄ en sÄdan dedikerad server eller VPS bestÄr av en webbserver, en databas och en applikationsserver. Ibland kan olika extra hjÀlptjÀnster installeras, inklusive för webbservern eller databasen: sökmotor, postsystem, osv.
Som lagringsutrymme för sÀkerhetskopior anvÀnds en sÀrskilt förberedd server, om den kommer att beskrivas mer detaljerat senare.
Logisk organisation av filsystemet
Om det finns en RAID-kontroller, eller om det Ă€r en VPS med en enda disk, och inga speciella preferenser för hur diskunderlaget ska fungera (till exempel en separat snabb disk för databasen) â delas allt ledigt utrymme pĂ„ följande sĂ€tt: En partition skapas, ovanpĂ„ denna skapas en LVM-volymgrupp, i vilken flera volymer skapas: 2 smĂ„ volymer av samma storlek, som anvĂ€nds som rotfilsystem (de byts ut mot varandra vid uppdateringar för att möjliggöra snabb Ă„terstĂ€llning, idĂ©n hĂ€rstammar frĂ„n distributionen Calculate Linux), ytterligare en â för swap-partitionen, det resterande lediga utrymmet delas upp i smĂ„ volymer som anvĂ€nds som rotfilsystem för fullstĂ€ndiga containrar, diskar för virtuella maskiner, filsystem för konton i /home (varje konto har sitt eget filsystem), filsystem för applikationscontainrar.
Viktig observation: volymerna mÄste vara helt sjÀlvförsörjande, det vill sÀga de fÄr inte vara beroende av varandra eller av rotfilsystemet. NÀr det gÀller virtuella maskiner eller containrar följs detta automatiskt. Om det dÀremot handlar om applikationscontainrar eller hemkataloger Àr det vÀrt att övervÀga att separera konfigurationsfiler för webbservern och andra tjÀnster pÄ ett sÀtt som minimerar beroenden mellan volymer. Till exempel, varje webbplats körs av sin egen anvÀndare, konfigurationsfilerna för webbplatsen ligger i anvÀndarens hemkatalog, i webbserverns instÀllningar inkluderas konfigurationsfiler för webbplatser inte via /etc/nginx/conf.d/.conf, utan till exempel via /home//configs/nginx/*.conf
Om det finns flera diskar â kan man skapa en mjukvaruraid-array (och konfigurera dess caching pĂ„ SSD om det Ă€r nödvĂ€ndigt och möjligt), ovanpĂ„ vilken man bygger LVM enligt reglerna som föreslagits ovan. I detta fall kan man ocksĂ„ anvĂ€nda ZFS eller BtrFS, men hĂ€r bör man tĂ€nka efter en extra gĂ„ng: bĂ„da krĂ€ver ett betydligt mer seriöst tillvĂ€gagĂ„ngssĂ€tt till resurser, och dessutom gĂ„r inte ZFS med i Linux-kĂ€rnan.
Oavsett vilken strategi som anvÀnds Àr det alltid bra att först uppskatta den ungefÀrliga skrivhastigheten för Àndringar pÄ diskarna, och dÀrefter berÀkna hur mycket ledigt utrymme som kommer att reserveras för att skapa snapshots. Till exempel, om vÄr server skriver data med en hastighet av 10 megabyte per sekund och storleken pÄ hela datamÀngden Àr 10 terabyte - kan synkroniseringstiden nÄ upp till ett dygn (22 timmar - sÄ mycket tid kommer det att ta att överföra sÄdan volym över ett 1 Gbit/s nÀtverk) - bör cirka 800 GB reserveras. I verkligheten kommer siffran att vara lÀgre, och man kan tryggt dela den med antalet logiska volymer.
Backup-serverlagring
Den största skillnaden med en backup-lagringsserver Àr de stora, billiga och relativt lÄngsamma diskarna. Eftersom moderna HDD:er redan har överstigit grÀnsen pÄ 10 TB pÄ en disk - mÄste filsystem eller RAID med kontrolsummor tillÀmpas, eftersom under tiden för omstrukturering av arrayen eller ÄterstÀllning av filsystemet (nÄgra dagar!) kan den andra disken gÄ sönder pÄ grund av den ökade belastningen. PÄ diskar med kapacitet upp till 1 TB var detta inte lika kÀnsligt. För enkelhetens skull antar jag att utrymmet pÄ diskarna Àr uppdelat i tvÄ ungefÀr lika stora delar (till exempel med hjÀlp av LVM):
- volymer som motsvarar servrarna, anvÀnda för lagring av anvÀndardata (dÀr den senaste skapade backupen kommer att distribueras för kontroll);
- volymer, anvÀnda som BorgBackup-repositorier (dit kommer data för backup att gÄ).
Arbetsprincipen Àr att separata volymer skapas för varje server under BorgBackup-repositorier, dÀr data frÄn produktionsservrarna kommer att hamna. Repositorierna arbetar i ett endast tillÀggslÀge, vilket utesluter möjligheten för avsiktlig radering av data, och tack vare deduplicering och periodisk rensning av repositorierna frÄn gamla backuper (det finns kvar Ärliga kopior, mÄnatliga under det senaste Äret, veckovisa under den senaste mÄnaden, dagliga under den senaste veckan, och eventuellt - i speciella fall - varje timme under den senaste dagen: summa summarum 24 + 7 + 4 + 12 + Ärliga - cirka 50 kopior för varje server).
I BorgBackup-repositorier aktiveras inte tillÀggslÀget, istÀllet anvÀnds ForcedCommand i .ssh/authorized_keys ungefÀr enligt följande:
from="server address",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.......Vid den angivna sökvÀgen finns ett wrapper-skript ovanpÄ borg, som förutom att köra den binÀra filen med parametrar Àven startar en ÄterstÀllningsprocess för sÀkerhetskopior efter att data har överförts. För detta ÀndamÄl skapar wrapper-skriptet en flaggfil intill det relevanta arkivet. Den senaste sÀkerhetskopian ÄterstÀlls automatiskt pÄ den relevanta logiska volymen efter att dataöverföringen Àr klar.
Denna konstruktion möjliggör periodisk rensning av onödiga sÀkerhetskopior och förhindrar Àven produktionsservrar frÄn att ta bort nÄgot pÄ sÀkerhetskopieringsservern.
SĂ€kerhetskopieringsprocessen
Initiativtagaren till sÀkerhetskopieringen Àr sjÀlva den dedikerade servern eller VPS, eftersom denna ordning ger mer kontroll över sÀkerhetskopieringsprocessen frÄn denna server. Först görs en snapshot av det aktiva rotfilsystemets tillstÄnd, som monteras och laddas upp med BorgBackup till sÀkerhetskopieringsservern. Efter att dataöverföringen Àr klar avmonteras och raderas snapshoten.
Vid en liten databas (upp till 1 GB för varje webbplats) görs en databasdump som sparas i motsvarande logiska volym, dit ocksÄ resten av datan för denna webbplats finns, men sÄ att dumpen inte Àr tillgÀnglig via webbservern. Om databaserna Àr stora bör "varma" datainsamlingar konfigureras, till exempel med hjÀlp av xtrabackup för MySQL, eller arbetet med WAL med archive_command i PostgreSQL. I detta fall kommer databasen att ÄterstÀllas separat frÄn webbplatsdata.
Om containrar eller virtuella maskiner anvĂ€nds bör qemu-guest-agent, CRIU eller andra nödvĂ€ndiga teknologier konfigureras. I andra fall behövs oftast inga ytterligare instĂ€llningar â vi skapar bara snapshots av de logiska volymerna, som sedan bearbetas pĂ„ samma sĂ€tt som snapshoten av rotfilsystemets tillstĂ„nd. Efter datainsamlingen raderas snapshoten.
DÀrefter fortsÀtter arbetet pÄ sÀkerhetskopieringsservern:
- senaste sÀkerhetskopiering kontrolleras i varje repository,
- kontrollen av en mÀrkfil som indikerar att datautvinningsprocessen har slutförts pÄgÄr,
- data ÄterstÀlls till motsvarande lokala volym,
- mÀrkfilen tas bort
Process för att ÄterstÀlla servern
Om huvudservern kraschar startar en liknande dedikerad server som laddas frÄn en standardbild. Troligen kommer laddningen att ske över nÀtverket, men teknikern i datacentret som stÀller in servern kan omedelbart kopiera denna standardbild till en av diskarna. Laddningen sker i RAM-minnet, varefter ÄterstÀllningsprocessen pÄbörjas:
- en begĂ€ran om att koppla blockenheten via iscsinbd eller ett annat liknande logiskt volymprotokoll, som innehĂ„ller den döda serverns rotfilsystem, görs; eftersom rotfilsystemet ska vara litet â bör detta steg slutföras inom nĂ„gra minuter. Ă terstĂ€llning av bootloadern utförs ocksĂ„;
- strukturen för lokala logiska volymer Äterskapas, logiska volymer frÄn backupservern kopplas samman med hjÀlp av dm_clone-kÀrnmodulen: datan ÄterstÀlls, och Àndringar skrivs omedelbart till de lokala diskarna
- en container startas med alla tillgĂ€ngliga fysiska diskar â serverns funktionalitet Ă„terstĂ€lls helt, men med nedsatt prestanda;
- efter att datasykronisering Àr klar kopplas volymerna frÄn backupservern bort, containern stÀngs av, servern startas om;
Efter omstarten kommer servern att ha all data som fanns vid tidpunkten för sÀkerhetskopian, samt inkludera alla Àndringar som gjordes under ÄterstÀllningsprocessen.
Andra artiklar i serien
Backup, del 7: Slutsatser
Jag inbjuder till diskussioner om det föreslagna alternativet i kommentarerna, tack för att du uppmÀrksammade detta!
KĂ€lla: habr.com
