Deze notitie sluit de cyclus over back-upoplossingen af. Dit keer bespreken we de logische organisatie van een dedicated server (of VPS) die handig is voor back-updoeleinden, en we bieden een snelle manier aan om een server te herstellen vanuit een back-up zonder veel uitvaltijd in geval van een storing.
Brongegevens
Een dedicated server heeft meestal minimaal twee harde schijven, die dienen voor het opzetten van een RAID-array van het eerste niveau (mirror). Dit is nodig om de server operationeel te houden als ƩƩn schijf uitvalt. Bij een standaard dedicated server kan er een aparte hardware RAID-controller aanwezig zijn, met actieve cachingtechnologie op SSD's, zodat naast de normale harde schijven ƩƩn of meerdere SSD's kunnen worden aangesloten. Soms worden dedicated servers aangeboden waarvoor alleen lokale schijven zoals SATADOM aanwezig zijn (kleine schijven die qua constructie lijken op een USB-stick, aangesloten op een SATA-poort), of zelfs een gewone kleine (8-16 GB) USB-stick die op een speciale interne poort is aangesloten, terwijl de gegevens afkomstig zijn van een SAN die via een dedicated storage-netwerk is aangesloten (Ethernet 10G, FC, enz.), en er zijn zelfs dedicated servers die volledig vanaf de SAN opstarten. Dit soort opties zal ik niet bespreken, aangezien in deze gevallen de back-upverantwoordelijkheid soepel overgaat naar de specialist die de SAN beheert; meestal zijn daar verschillende proprietary technologieƫn voor het maken van snapshots, ingebouwde deduplicatie en andere voordelen voor systeembeheerders besproken in eerdere delen van deze cyclus. De totale capaciteit van de schijfruimte van een dedicated server kan oplopen tot enkele tientallen terabytes, afhankelijk van het aantal en de capaciteit van de schijven die op de server zijn aangesloten. In het geval van een VPS zijn de volumes bescheidener: meestal niet meer dan 100 GB (maar soms meer), en de tarieven voor dergelijke VPS'en kunnen gemakkelijk duurder zijn dan de goedkoopste dedicated servers van dezelfde provider. Een VPS heeft meestal ƩƩn schijf, omdat daar een SAN (of iets hypergeconvergeerds) achter zit. Soms heeft een VPS meerdere schijven met verschillende kenmerken voor verschillende doeleinden:
- klein systeem ā voor de installatie van het besturingssysteem;
- groot ā voor het opslaan van gebruikersgegevens.
Bij het herinstalleren van het systeem via het controlepaneel wordt de schijf met gebruikersdata niet gewist, terwijl de systeemschijf volledig wordt overschreven. Ook kan de VPS-provider een knop aanbieden die een snapshot van de VPS (of schijf) maakt, maar als je je eigen besturingssysteem installeert of vergeet de benodigde service binnen de VPS te activeren, kan een deel van de data alsnog verloren gaan. Vaak wordt er naast de knop een opslagsysteem aangeboden, dat meestal sterk beperkt is. Dit is vaak een account met toegang via FTP of SFTP, soms samen met SSH, met een beperkte shell (bijvoorbeeld rbash), of een beperking op het uitvoeren van commando's via authorized_keys (door middel van ForcedCommand).
Een dedicated server is verbonden met het netwerk via twee poorten met een snelheid van 1 Gbps, soms zijn dit kaarten met een snelheid van 10 Gbps. Bij VPS is de netwerkinterface meestal Ć©Ć©n. Datacenters beperken vaak de snelheid binnen het datacenter niet, maar wel de snelheid van toegang tot het internet.
De typische belasting van een dergelijke dedicated server of VPS bestaat uit een webserver, een database en een applicatieserver. Soms kunnen er verschillende extra ondersteunende services worden geĆÆnstalleerd, inclusief voor de webserver of database: een zoekmachine, mailsysteem, enzovoorts.
Als opslagruimte voor back-ups fungeert een speciaal voorbereide server, hierover zal later meer worden beschreven.
Logische organisatie van het bestandssysteem
Als er een RAID-controller is, of dit een VPS met Ć©Ć©n schijf is, en er zijn ook geen specifieke voorkeuren voor de werking van het schijfsubsystem (bijvoorbeeld een aparte snelle schijf voor de database) ā dan wordt de vrije ruimte als volgt verdeeld: er wordt Ć©Ć©n partitie aangemaakt, waarop een LVM-volume groep wordt gemaakt, waarin verschillende volumes worden aangemaakt: 2 kleine volumes van gelijke grootte, die worden gebruikt als het root-bestandssysteem (wisselend bij updates voor de mogelijkheid van snelle terugrol, dit idee is overgenomen van de Calculate Linux-distributie), een andere voor de swap-partitie, de overige vrije ruimte wordt verdeeld over kleine volumes die dienen als root-bestandssystemen voor volledige containers, schijven voor virtuele machines, bestandssystemen voor gebruikersaccounts in /home (elk account heeft zijn eigen bestandssysteem), en bestandssystemen voor applicatie-containers.
Belangrijke opmerking: de volumes moeten volledig autonoom zijn, dat wil zeggen dat ze niet van elkaar of van het root-bestandssysteem afhankelijk mogen zijn. In het geval van virtuele machines of containers wordt dit punt automatisch gerespecteerd. Als het echter gaat om applicatie-containers of thuismappen, is het belangrijk om na te denken over het scheiden van configuratiebestanden van de webserver en andere services zodat de afhankelijkheden tussen volumes maximaal worden weggenomen. Bijvoorbeeld, elke site draait onder zijn eigen gebruiker, de configuratiebestanden van de site bevinden zich in de thuismap van de gebruiker, in de instellingen van de webserver worden de configuratiebestanden van de sites niet ingeschakeld via /etc/nginx/conf.d/.conf, maar bijvoorbeeld /home//configs/nginx/*.conf
Als er meerdere schijven zijn ā kan er een softwarematige RAID-array worden aangemaakt (en deze configureren met SSD-caching, als er behoefte aan is en de mogelijkheden dit toelaten), waarboven LVM wordt samengesteld volgens de regels zoals hierboven voorgesteld. In dit geval kunnen ook ZFS of BtrFS worden gebruikt, maar het is belangrijk om hier goed over na te denken: beide vereisen een veel serieuzere benadering van de middelen, bovendien is ZFS niet inbegrepen in de Linux-kernel.
Ongeacht het gebruikte schema is het altijd goed om vooraf een schatting te maken van de snelheid waarmee wijzigingen naar de schijven worden geschreven, en vervolgens de grootte van de vrije ruimte te berekenen die gereserveerd zal worden voor het maken van snapshots. Bijvoorbeeld, als onze server gegevens schrijft met een snelheid van 10 megabyte per seconde, en de totale gegevensopslag 10 terabyte bedraagt ā kan de synchronisatietijd wel een dag bedragen (22 uur ā dat is hoe lang het duurt om dit volume over een netwerk van 1 Gbit/s te verzenden) ā het is aan te raden om ongeveer 800 GB te reserveren. In de praktijk zal dit getal lager zijn; je kunt het zonder problemen delen door het aantal logische volumes.
Backup opslagserver
Het belangrijkste verschil met een backup opslagserver is de grote, goedkope en relatief trage schijven. Aangezien moderne HDD's al de 10TB-grens in Ć©Ć©n schijf hebben overschreden, is het noodzakelijk om bestandssystemen of RAID met checksums te gebruiken, omdat tijdens het herschikken van de array of het herstellen van het bestandssysteem (meerdere dagen!) de tweede schijf kan falen door de verhoogde belasting. Bij schijven tot 1TB was dit minder kritisch. Voor de eenvoud van de beschrijving neem ik aan dat de schijfruimte in twee ongeveer gelijke delen is verdeeld (bijvoorbeeld met behulp van LVM):
- volumes, overeenkomend met de servers, die worden gebruikt voor het opslaan van gebruikersgegevens (hierop zal de laatst gemaakte back-up worden uitgerold ter controle);
- volumes, gebruikt als BorgBackup-repositories (hierin zullen de gegevens voor back-ups terechtkomen).
Het principe van werking bestaat eruit dat afzonderlijke volumes worden gecreĆ«erd voor elke server onder de BorgBackup-repositories, waar de gegevens van de operationele servers naartoe zullen gaan. De repositories werken in een alleen-toevoegen modus, wat de mogelijkheid van opzettelijk verwijderen van gegevens uitsluit; door deduplicatie en periodiek reinigen van de repositories van oude back-ups (blijven jaarlijkse kopieĆ«n, maandelijkse van het afgelopen jaar, wekelijkse van de afgelopen maand, dagelijkse van de afgelopen week, mogelijk ā in speciale gevallen ā uurlijkse van de afgelopen dag: totaal 24 + 7 + 4 + 12 + jaarlijkse ā ongeveer 50 kopieĆ«n voor elke server).
In de BorgBackup-repositories wordt de alleen-toevoegen modus niet geactiveerd, in plaats daarvan wordt ForcedCommand gebruikt in .ssh/authorized_keys, ongeveer als volgt:
from="serveradres",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.......Op het opgegeven pad bevindt zich een wrapper-script bovenop borg, dat naast het starten van de binaire uitvoer met parameters, ook het herstelproces van de back-up start na het gegevensopslag. Hiervoor maakt het wrapper-script een indicatiebestand aan naast het desbetreffende repository. De laatste gemaakte back-up wordt automatisch hersteld op de desbetreffende logische schijf na de gegevensopslag.
Deze constructie maakt het mogelijk om periodiek onnodige back-ups te verwijderen, en voorkomt daarnaast dat productie-servers iets op de back-upserver verwijderen.
Het back-upproces
De initiator van de back-up is de dedicated server of VPS zelf, omdat dit schema meer controle biedt over het back-upproces vanuit deze server. Allereerst wordt er een snapshot gemaakt van de actieve root-bestandssysteem, die wordt gemonteerd en geĆ¼pload met BorgBackup naar de back-upserver. Na het voltooien van de gegevensopslag wordt het snapshot ontkoppeld en verwijderd.
In het geval van een kleine database (tot 1 GB voor elke site) wordt er een database-dump gemaakt, die wordt opgeslagen in de overeenkomstige logische schijf, daar waar ook de andere gegevens van dezelfde site zijn opgeslagen, maar zodat de dump niet toegankelijk is via de webserver. Als de databases groter zijn, moet er een "hot" gegevensopslag worden geconfigureerd, bijvoorbeeld met behulp van xtrabackup voor MySQL, of het gebruik van WAL met archive_command in PostgreSQL. In dit geval wordt de database apart hersteld van de gegevens van de websites.
Als er containers of virtuele machines worden gebruikt, moet de qemu-guest-agent, CRIU of andere benodigde technologieĆ«n worden ingesteld. In andere gevallen zijn er meestal geen extra configuraties nodig ā we maken gewoon snapshots van de logische schijven die vervolgens op dezelfde manier worden verwerkt als het snapshot van het root-bestandssysteem. Na de gegevensopslag worden de snapshots verwijderd.
Het verdere werk vindt plaats op de back-upserver:
- de laatste gemaakte back-up wordt in elke repository gecontroleerd,
- er wordt gecontroleerd of er een labelbestand aanwezig is dat aangeeft dat het gegevensherstelproces is voltooid,
- de gegevens worden uitgepakt naar de bijbehorende lokale schijf,
- het labelbestand wordt verwijderd,
Het herstelproces van de server,
Als de primaire server uitvalt, wordt er een vergelijkbare dedicated server opgestart die wordt geladen vanuit een standaardimage. Waarschijnlijk zal de opstart via het netwerk plaatsvinden, maar de datacentertechnicus die de server configureert, kan deze standaardimage ook direct op een van de schijven kopiƫren. De opstart gebeurt in het RAM, waarna het herstelproces begint:
- er wordt een verzoek gedaan voor het aansluiten van het blokapparaat via iscsinbd of een ander vergelijkbaar logisch volumprotocol dat het rootbestandssysteem van de uitgevallen server bevat; aangezien het rootbestandssysteem klein moet zijn, zou deze stap binnen enkele minuten moeten zijn voltooid. Ook wordt de bootloader hersteld;
- de structuur van de lokale logische volumes wordt opnieuw opgebouwd, de logische volumes van de back-upserver worden opgenomen met behulp van de kernelmodule dm_clone: het herstel van gegevens begint, en de wijzigingen worden direct op de lokale schijven geschreven,
- er wordt een container opgestart met alle beschikbare fysieke schijven ā de functionaliteit van de server wordt volledig hersteld, maar met verminderde prestaties;
- na de synchronisatie van gegevens worden de logische volumes van de back-upserver losgekoppeld, de container wordt uitgeschakeld, de server wordt opnieuw opgestart;
Na de herstart heeft de server alle gegevens die aanwezig waren op het moment van het maken van de back-up, en zijn ook alle wijzigingen die tijdens het herstelproces zijn aangebracht, inbegrepen.
Andere artikelen in de serie
Back-up, deel 7: Conclusies
Ik nodig u uit om de voorgestelde optie in de reacties te bespreken, dank u voor uw aandacht!
Bron: habr.com
