Hallo, ik kwam onlangs een interessant probleem tegen: het instellen van opslag voor het maken van back-ups van een groot aantal blokapparaten.
Elke week maken we een back-up van alle virtuele machines in onze cloud, dus we moeten duizenden back-ups kunnen onderhouden en dit zo snel en efficiënt mogelijk doen.
Helaas standaardconfiguraties RAID5, RAID6 in dit geval zullen we dat niet mogen doen, omdat het herstelproces op zulke grote schijven als de onze pijnlijk lang zal duren en hoogstwaarschijnlijk nooit zal eindigen.
Laten we eens kijken welke alternatieven er zijn:
— Vergelijkbaar met RAID5, RAID6, maar met configureerbaar pariteitsniveau. In dit geval wordt de reservering niet blok voor blok uitgevoerd, maar voor elk object afzonderlijk. De eenvoudigste manier om wiscodering uit te proberen, is door uit te breiden .
is een momenteel nog niet uitgebrachte ZFS-functie. In tegenstelling tot RAIDZ heeft DRAID een gedistribueerd pariteitsblok en gebruikt het tijdens herstel alle schijven van de array tegelijk, waardoor het beter in staat is schijfstoringen te overleven en sneller te herstellen na een storing.
Server beschikbaar Fujitsu Primergy RX300 S7 met processor Intel Xeon CPU E5-2650L 0 @ 1.80 GHz, negen RAM-sticks Samsung DDR3-1333 8Gb PC3L-10600R ECC-geregistreerd (M393B1K70DH0-YH9), schijfplank Supermicro Superchassis 847E26-RJBOD1, aangesloten via Dubbele LSI SAS2X36-expander en 45 schijven Seagage ST6000NM0115-1YZ110 op 6TB per stuk.
Voordat we iets beslissen, moeten we eerst alles goed testen.
Hiervoor heb ik verschillende configuraties voorbereid en getest. Om dit te doen, heb ik minio gebruikt, dat fungeerde als een S3-backend en het in verschillende modi met verschillende aantallen doelen lanceerde.
Kortom, de minio-behuizing werd getest in wiscodering versus software-raid met hetzelfde aantal schijven en pariteit van schijven, en dit zijn: RAID6, RAIDZ2 en DRAID2.
Ter referentie: wanneer u minio met slechts één doel start, werkt minio in de S3-gatewaymodus en levert uw lokale bestandssysteem in de vorm van S3-opslag. Als u Minio start en meerdere doelen opgeeft, wordt de Erasure Coding-modus automatisch ingeschakeld, waardoor de gegevens tussen uw doelen worden verspreid en tegelijkertijd fouttolerantie wordt geboden.
Standaard verdeelt minio doelen in groepen van 16 schijven, met 2 pariteiten per groep. Die. Twee schijven kunnen tegelijkertijd uitvallen zonder gegevensverlies.
Om de prestaties te testen, heb ik 16 schijven van elk 6 TB gebruikt en er kleine objecten van 1 MB op geschreven, dit beschreef onze toekomstige belasting het meest nauwkeurig, aangezien alle moderne back-uptools gegevens in blokken van verschillende megabytes verdelen en ze op deze manier schrijven.
Om de benchmark uit te voeren, hebben we het hulpprogramma s3bench gebruikt, gelanceerd op een externe server en tienduizenden van dergelijke objecten in honderden threads naar minio gestuurd. Daarna probeerde ik ze op dezelfde manier terug te vragen.
De benchmarkresultaten worden weergegeven in de volgende tabel:
Zoals we kunnen zien, presteert minio in zijn eigen wiscoderingsmodus aanzienlijk slechter bij het schrijven dan minio die bovenop de software RAID6, RAIDZ2 en DRAID2 in dezelfde configuratie draait.
Apart ik test minio op ext4 versus XFS. Verrassend genoeg bleek XFS voor mijn type werklast aanzienlijk langzamer te zijn dan ext4.
In de eerste reeks tests toonde Mdadm superioriteit ten opzichte van ZFS, maar later dat u de ZFS-prestaties kunt verbeteren door de volgende opties in te stellen:
xattr=sa atime=off recordsize=1Men daarna werden de tests met ZFS veel beter.
Je kunt ook constateren dat DRAID niet veel prestatiewinst oplevert ten opzichte van RAIDZ, maar in theorie zou het veel veiliger moeten zijn.
In de laatste twee tests heb ik ook geprobeerd om metadata (speciaal) en ZIL (log) vanaf de SSD naar de spiegel over te zetten. Maar het verwijderen van metadata leverde niet veel winst op in de opnamesnelheid, en bij het verwijderen van ZIL, my bereikte het plafond met een benutting van 100%, dus ik beschouw deze test als een mislukking. Ik sluit niet uit dat als ik snellere SSD-schijven had, dit mijn resultaten misschien enorm zou kunnen verbeteren, maar helaas had ik ze niet.
Uiteindelijk heb ik besloten om DRAID te gebruiken en ondanks de bètastatus is het in ons geval de snelste en meest efficiënte opslagoplossing.
Ik heb een eenvoudige DRAID2 gemaakt in een configuratie met drie groepen en twee gedistribueerde reserveonderdelen:
# zpool status data
pool: data
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM
data ONLINE 0 0 0
draid2:3g:2s-0 ONLINE 0 0 0
sdy ONLINE 0 0 0
sdam ONLINE 0 0 0
sdf ONLINE 0 0 0
sdau ONLINE 0 0 0
sdab ONLINE 0 0 0
sdo ONLINE 0 0 0
sdw ONLINE 0 0 0
sdak ONLINE 0 0 0
sdd ONLINE 0 0 0
sdas ONLINE 0 0 0
sdm ONLINE 0 0 0
sdu ONLINE 0 0 0
sdai ONLINE 0 0 0
sdaq ONLINE 0 0 0
sdk ONLINE 0 0 0
sds ONLINE 0 0 0
sdag ONLINE 0 0 0
sdi ONLINE 0 0 0
sdq ONLINE 0 0 0
sdae ONLINE 0 0 0
sdz ONLINE 0 0 0
sdan ONLINE 0 0 0
sdg ONLINE 0 0 0
sdac ONLINE 0 0 0
sdx ONLINE 0 0 0
sdal ONLINE 0 0 0
sde ONLINE 0 0 0
sdat ONLINE 0 0 0
sdaa ONLINE 0 0 0
sdn ONLINE 0 0 0
sdv ONLINE 0 0 0
sdaj ONLINE 0 0 0
sdc ONLINE 0 0 0
sdar ONLINE 0 0 0
sdl ONLINE 0 0 0
sdt ONLINE 0 0 0
sdah ONLINE 0 0 0
sdap ONLINE 0 0 0
sdj ONLINE 0 0 0
sdr ONLINE 0 0 0
sdaf ONLINE 0 0 0
sdao ONLINE 0 0 0
sdh ONLINE 0 0 0
sdp ONLINE 0 0 0
sdad ONLINE 0 0 0
spares
s0-draid2:3g:2s-0 AVAIL
s1-draid2:3g:2s-0 AVAIL
errors: No known data errorsOké, we hebben de opslag geregeld, laten we het nu hebben over waar we een back-up van gaan maken. Hier zou ik het meteen willen hebben over drie oplossingen die ik heb kunnen proberen, en deze zijn:
- vork , een gespecialiseerde oplossing voor het back-uppen van blokapparaten, heeft een nauwe integratie met Ceph. Kan verschillen tussen snapshots maken en er een incrementele back-up van maken. Ondersteunt een groot aantal opslag-backends, inclusief zowel lokaal als S3. Vereist een aparte database om de deduplicatie-hashtabel op te slaan. Nadelen: geschreven in Python, heeft een enigszins niet-reagerende cli.
- vork , een al lang bekende en beproefde back-uptool, kan een back-up van gegevens maken en deze goed ontdubbelen. In staat om back-ups zowel lokaal als op een externe server via scp op te slaan. Kan een back-up maken van blokkeerapparaten als deze met de vlag worden gestart --special, een van de minpunten: bij het maken van een back-up wordt de repository volledig geblokkeerd, dus het is aan te raden om voor elke virtuele machine een aparte repository te maken, in principe is dit geen probleem, gelukkig zijn ze heel gemakkelijk te maken.
is een actief ontwikkelend project, in go geschreven, vrij snel en ondersteunt een groot aantal opslag-backends, waaronder lokale opslag, scp, S3 en nog veel meer. Afzonderlijk zou ik willen opmerken dat er een speciaal gemaakt is voor restic, waarmee u snel opslag kunt exporteren voor gebruik op afstand. Van al het bovenstaande vond ik dit het leukste. Kan een back-up maken van stdin. Het heeft bijna geen merkbare nadelen, maar er zijn verschillende kenmerken:
-
Ten eerste probeerde ik het te gebruiken in de algemene repositorymodus voor alle virtuele machines (zoals Benji) en het werkte zelfs redelijk goed, maar de herstelbewerkingen duurden erg lang, omdat... Elke keer vóór het herstellen probeert restic de metadata van alle back-ups te lezen. Dit probleem kon, net als bij borg, eenvoudig worden opgelost door voor elke virtuele machine een aparte repository te maken. Deze aanpak is ook zeer effectief gebleken voor het beheren van back-ups. Afzonderlijke opslagplaatsen kunnen een afzonderlijk wachtwoord hebben voor toegang tot gegevens, en we hoeven ook niet bang te zijn dat de mondiale opslagplaats op de een of andere manier kapot gaat. Je kunt net zo gemakkelijk nieuwe repository's spawnen als bij een borgback-up.
In ieder geval wordt deduplicatie alleen uitgevoerd ten opzichte van de vorige versie van de back-up; de vorige back-up wordt bepaald door het pad voor de opgegeven back-up. Als u dus een back-up maakt van verschillende objecten van stdin naar een gemeenschappelijke repository, vergeet dan niet om de locatie op te geven. keuze
--stdin-filenameof geef de optie elke keer expliciet op--parent.
-
Ten tweede duurt herstel naar stdout veel langer dan herstel naar het bestandssysteem vanwege het parallelle karakter ervan. In de toekomst zijn we van plan om betere ondersteuning toe te voegen voor back-ups voor blokapparaten.
-
Ten derde wordt het momenteel aanbevolen om te gebruiken , omdat versie 0.9.6 heeft een bug met langdurig herstel van grote bestanden.
Om de effectiviteit van de back-up en de snelheid van schrijven / herstellen vanaf een back-up te testen, heb ik een aparte repository gemaakt en geprobeerd een back-up te maken van een kleine afbeelding van een virtuele machine (21 GB). Er zijn twee back-ups gemaakt zonder het origineel te wijzigen, waarbij elk van de genoemde oplossingen werd gebruikt om te controleren hoe sneller/langzamer de gededupliceerde gegevens werden gekopieerd.
Zoals we kunnen zien, heeft Borg Backup de beste efficiëntieratio voor initiële back-ups, maar is deze inferieur in termen van zowel schrijf- als herstelsnelheid.
Restic bleek sneller te zijn dan Benji Backup, maar het duurt langer om te herstellen naar stdout, en helaas weet het nog niet hoe het rechtstreeks naar een blokapparaat moet schrijven.
Nadat ik alle voor- en nadelen had afgewogen, besloot ik om voor mezelf te kiezen rustiek с rest-server als de handigste en meest veelbelovende back-upoplossing.
In deze screencast ziet u hoe een 10 gigabit-kanaal volledig wordt benut tijdens meerdere back-upbewerkingen die tegelijkertijd worden uitgevoerd. Het is vermeldenswaard dat schijfrecycling niet boven de 30% uitkomt.
Ik was meer dan tevreden met de oplossing die ik kreeg!
Bron: www.habr.com