Hej, jag stötte nyligen på ett intressant problem: att ställa in lagring för säkerhetskopiering av ett stort antal blockenheter.
Varje vecka säkerhetskopierar vi alla virtuella maskiner i vårt moln, så vi måste kunna underhålla tusentals säkerhetskopior och göra det så snabbt och effektivt som möjligt.
Tyvärr standardkonfigurationer RAID5, RAID6 i det här fallet kommer vi inte att tillåtas göra det, eftersom återställningsprocessen på så stora diskar som vår kommer att vara smärtsamt lång och troligen aldrig tar slut.
Låt oss titta på vilka alternativ som finns:
— Liknar RAID5, RAID6, men med konfigurerbar paritetsnivå. I detta fall utförs reservationen inte block för block, utan för varje objekt separat. Det enklaste sättet att prova raderingskodning är att expandera .
är en för närvarande outgiven ZFS-funktion. Till skillnad från RAIDZ har DRAID ett distribuerat paritetsblock och använder, under återställning, alla diskar i arrayen samtidigt, vilket gör det bättre att överleva diskfel och återhämta sig snabbare efter ett fel.
Server tillgänglig Fujitsu Primergy RX300 S7 med processor Intel Xeon CPU E5-2650L 0 @ 1.80 GHz, nio stickor RAM Samsung DDR3-1333 8Gb PC3L-10600R ECC-registrerad (M393B1K70DH0-YH9), diskhylla Supermicro SuperChassis 847E26-RJBOD1, ansluten via Dubbel LSI SAS2X36 Expander och 45 skivor Seagage ST6000NM0115-1YZ110 på 6TB vardera.
Innan vi bestämmer oss för något måste vi först testa allt ordentligt.
För att göra detta förberedde och testade jag olika konfigurationer. För att göra detta använde jag minio, som fungerade som en S3-backend och lanserade den i olika lägen med olika antal mål.
I grund och botten testades minio-fodralet i raderingskodning vs mjukvaru-raid med samma antal diskar och paritet av diskar, och dessa är: RAID6, RAIDZ2 och DRAID2.
Som referens: när du startar minio med bara ett mål, fungerar minio i S3-gatewayläge och levererar ditt lokala filsystem i form av S3-lagring. Om du startar minio som anger flera mål, kommer raderingskodningsläget att aktiveras automatiskt, vilket sprider data mellan dina mål samtidigt som feltoleransen tillhandahålls.
Som standard delar minio in mål i grupper om 16 diskar, med 2 pariteter per grupp. De där. Två diskar kan misslyckas samtidigt utan att förlora data.
För att testa prestanda använde jag 16 diskar på 6TB vardera och skrev små objekt på 1MB i storlek på dem, detta beskrev vår framtida belastning mest exakt, eftersom alla moderna säkerhetskopieringsverktyg delar upp data i block på flera megabyte och skriver dem på detta sätt.
För att genomföra riktmärket använde vi verktyget s3bench, som lanserades på en fjärrserver och skickade tiotusentals sådana objekt till minio i hundratals trådar. Därefter försökte jag begära tillbaka dem på samma sätt.
Benchmarkresultaten visas i följande tabell:
Som vi kan se presterar minio i sitt eget raderingskodningsläge betydligt sämre att skriva än minio som körs ovanpå mjukvaran RAID6, RAIDZ2 och DRAID2 i samma konfiguration.
Separat mig testa minio på ext4 vs XFS. Överraskande nog, för min typ av arbetsbelastning visade sig XFS vara betydligt långsammare än ext4.
I den första omgången av tester visade Mdadm överlägsenhet över ZFS, men senare att du kan förbättra ZFS-prestanda genom att ställa in följande alternativ:
xattr=sa atime=off recordsize=1Moch efter det blev testerna med ZFS mycket bättre.
Du kan också notera att DRAID inte ger mycket prestandavinst jämfört med RAIDZ, men i teorin borde det vara mycket säkrare.
I de två senaste testerna försökte jag även överföra metadata (special) och ZIL (logg) till spegeln från SSD:n. Men att ta bort metadata gav inte mycket vinst i inspelningshastighet, och när man tog bort ZIL, min slog i taket med 100 % utnyttjande, så jag anser att detta test är ett misslyckande. Jag utesluter inte att om jag hade snabbare SSD-enheter så kanske detta skulle kunna förbättra mina resultat avsevärt, men tyvärr hade jag dem inte.
Till slut bestämde jag mig för att använda DRAID och trots dess betastatus är det den snabbaste och mest effektiva lagringslösningen i vårt fall.
Jag skapade en enkel DRAID2 i en konfiguration med tre grupper och två distribuerade reservdelar:
# 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 errorsOkej, vi har ordnat lagringen, nu ska vi prata om vad vi ska säkerhetskopiera. Här skulle jag omedelbart vilja prata om tre lösningar som jag lyckades testa, och dessa är:
- gaffel , en specialiserad lösning för säkerhetskopiering av blockenheter, har tät integration med Ceph. Det kan ta skillnader mellan ögonblicksbilder och bilda en inkrementell backup från dem. Stöder ett stort antal backends för lagring, inklusive både lokala och S3. Kräver en separat databas för att lagra hashtabellen för deduplicering. Nackdelar: skrivet i python, har en lite svarslös cli.
- gaffel , ett sedan länge känt och beprövat verktyg för säkerhetskopiering, kan säkerhetskopiera data och deduplicera det väl. Kan spara säkerhetskopior både lokalt och till en fjärrserver via scp. Kan säkerhetskopiera blockera enheter om de lanseras med flaggan --special, ett av nackdelarna: när du skapar en säkerhetskopia är förvaret helt blockerat, så det rekommenderas att skapa ett separat förråd för varje virtuell maskin, i princip är detta inte ett problem, lyckligtvis skapas de väldigt enkelt.
är ett aktivt utvecklande projekt, skrivet i go, ganska snabbt och stöder ett stort antal lagringsbackends, inklusive lokal lagring, scp, S3 och mycket mer. Separat skulle jag vilja notera att det finns en speciellt skapad för restic, vilket gör att du snabbt kan exportera lagring för fjärranvändning. Av alla ovanstående gillade jag den mest. Kan säkerhetskopiera från stdin. Det har nästan inga märkbara nackdelar, men det finns flera funktioner:
-
För det första försökte jag använda det i det allmänna lagringsläget för alla virtuella maskiner (som Benji) och det fungerade till och med ganska bra, men återställningsoperationerna tog väldigt lång tid, eftersom... Varje gång innan återställning försöker restic läsa metadata för alla säkerhetskopior. Detta problem löstes enkelt, som med borg, genom att skapa ett separat arkiv för varje virtuell maskin. Detta tillvägagångssätt har visat sig vara mycket effektivt för att hantera säkerhetskopior också. Separata arkiv kan ha ett separat lösenord för att komma åt data, och vi behöver inte heller vara rädda för att det globala arkivet på något sätt kan gå sönder. Du kan skapa nya arkiv lika enkelt som i borg backup.
I alla fall utförs deduplicering endast i förhållande till den tidigare versionen av säkerhetskopian; den tidigare säkerhetskopieringen bestäms av sökvägen för den angivna säkerhetskopian, så om du säkerhetskopierar olika objekt från stdin till ett gemensamt arkiv, glöm inte att ange alternativ
--stdin-filename, eller ange uttryckligen alternativet varje gång--parent.
-
För det andra tar återställning till stdout mycket längre tid än återställning till filsystemet på grund av dess parallella karaktär. I framtiden planerar vi att lägga till närmare stöd för säkerhetskopiering av blockenheter.
-
För det tredje rekommenderas det för närvarande att använda , därför att version 0.9.6 har en bugg med lång återställning av stora filer.
För att testa effektiviteten av säkerhetskopieringen och hastigheten för att skriva/återställa från en säkerhetskopia skapade jag ett separat arkiv och försökte säkerhetskopiera en liten bild av en virtuell maskin (21 GB). Två säkerhetskopieringar gjordes utan att ändra originalet, med var och en av de listade lösningarna för att kontrollera hur snabbare/långsammare den deduplicerade datan kopierades.
Som vi kan se har Borg Backup det bästa initiala säkerhetskopieringseffektivitetsförhållandet, men är sämre när det gäller både skriv- och återställningshastighet.
Restic visade sig vara snabbare än Benji Backup, men det tar längre tid att återställa till stdout, och tyvärr vet den ännu inte hur man skriver direkt till en blockenhet.
Efter att ha vägt alla för- och nackdelar bestämde jag mig för att nöja mig restisk с rest-server som den mest bekväma och lovande backuplösningen.
I den här screencasten kan du se hur en 10-gigabit-kanal utnyttjas helt under flera säkerhetskopieringar som körs samtidigt. Det är värt att notera att diskåtervinning inte överstiger 30%.
Jag var mer än nöjd med lösningen jag fick!
Källa: will.com