I de tidligere indlæg har vi delt instruktioner til opsætning af og baseret på Veeam. I dag vil vi fortælle om backup ved hjælp af Commvault. Der vil ikke være instruktioner, men vi vil fortælle, hvad og hvordan vores kunder allerede sikkerhedskopierer.
SAN-systemer til backup baseret på Commvault i datacenteret OST-2.
Hvordan fungerer det?
Commvault er en platform til backup af applikationer, databaser, filsystemer, virtuelle maskiner og fysiske servere. Kilde-data kan være placeret på hvilken som helst platform: hos os – hos kunden, i et andet kommercielt datacenter eller i skyen.
Kunden installerer en agent på backup objekterne – iData Agent – og konfigurerer den i overensstemmelse med de ønskede backuppolitikker. iData Agent indsamler de nødvendige data, komprimerer, deduperer, krypterer og sender dem til backup-systemet DataLine.
Proxy-servere sikrer forbindelsen mellem klientnetværket og vores netværk, isolerer de kanaler, hvorigennem data sendes.
På DataLine modtager Media Agent Server og sender dem til opbevaring på SAN, båndbiblioteker osv. Alt dette styres af CommServe. I vores konfiguration ligger den primære kontrolserver i OST, den sekundære i NORD.
Som standard placeres kundedata på én placering, men det er muligt at organisere backup med det samme på to lokationer eller planlægge en tidsplan for overførsel af backups til den anden placering. Denne mulighed kaldes "yderligere datakopiering" (auxiliary copy). For eksempel vil alle fulde backups i slutningen af måneden automatisk blive duplikeret eller flyttet til den anden placering.
Funktionsdiagram for Commvault backup-systemet.
Backup-systemet fungerer primært ved virtualisering af VMware: på virtuelle maskiner er serverne CommServe, Media Agent og Proxy-servere installeret. Hvis kunden bruger vores udstyr, placeres backups på SAN Huawei OceanStor 5500 V3. For backup af kundens SAN, og opbevaring af backups på båndbiblioteker anvendes separate Media Agent på fysiske servere.
Hvad er vigtigt for kunderne?
Fra vores erfaring bemærker kunder, der vælger Commvault til backup, følgende punkter.
Konsol. Kunder ønsker at administrere backup selv. I Commvault-konsollen er alle de vigtigste operationer tilgængelige:
- tilføjelse og fjernelse af servere til backup;
- konfiguration af iData Agent;
- oprettelse og manuel kørsel af jobs;
- selvstændig gendannelse af backups;
- opsætning af alarmer om status for backupopgaver;
- afgrænsning af adgang til konsollen afhængigt af rolle og brugergruppe.
Deduplicering. Deduplicering gør det muligt at finde og fjerne gentagne datablokke under backup-processen. Dermed hjælper det med at spare plads på lagringssystemet og reducerer mængden af data, der overføres, hvilket sænker kravene til hastigheden af forbindelsen. Uden deduplicering ville backups optage to til tre gange så meget plads som de oprindelige data.
I tilfælde af Commvault kan dedupliceringen konfigureres på klientsiden eller på Medieagenten. I det første tilfælde sendes ikke-unikke datablokke ikke engang til Medieagent-serveren. I det andet tilfælde bliver den gentagne blok forkastet og bliver ikke gemt på lagringssystemet.
Denne blokdeduplicering er baseret på hash-funktioner. Hver blok tildeles en hash, som gemmes i en hashtabel, en slags database (Deduplication Database, DDB). Under dataoverførsel 'slås' hashen op i denne database. Hvis en sådan hash allerede findes i databasen, bliver blokken markeret som ikke-unik og bliver ikke sendt til Medieagent-serveren (i første tilfælde) eller ikke gemmes på lagringssystemet (i det andet).
Takket være dedupliceringen formår vi at spare op til 78% plads i lagringssystemet. I øjeblikket opbevares 166,4 TB på lagringssystemet. Uden deduplicering ville vi skulle opbevare 744 TB.
Mulighed for at afgrænse rettigheder. I Commvault er der mulighed for at fastsætte forskellige adgangsniveauer til administration af backup. De såkaldte 'roller' definerer, hvilke handlinger der vil for brugeren i forhold til backup-objekterne. For eksempel vil udviklere kun kunne gendanne servere med databaser til et bestemt sted, mens administratoren kan starte en manuel backup for den samme server og tilføje nye brugere.
Kryptering. Data kan krypteres under backup via Commvault på følgende måder:
- på klientsiden: data vil på dette tidspunkt blive sendt til backup-systemet i krypteret form;
- på Media Agent-siden;
- på kanalniveau: data krypteres på klientsiden og dekrypteres på Media Agent-serveren.
Tilgængelige krypteringsalgoritmer: Blowfish, GOST, Serpent, Twofish, 3-DES, AES (anbefales af Commvault).
Lidt statistik
I midten af december har vi med Commvault backup af 27 kunder. Størstedelen heraf er detailhandlere og finansielle institutioner. Den samlede mængde af de originale backup-data fylder 65 TB.
Der udføres cirka 4400 opgaver dagligt. Nedenfor er statistikken for udførte opgaver de sidste 16 dage.
Mest af alt backup'er man Windows File System, SQL Server og Exchange-databaser via Commvault.
Og nu de lovede cases. Selvom de er anonymiserede (NDA sender hilsner :)), giver de et indblik i, hvad og hvordan kunderne bruger Commvault-baseret backup. Herunder præsenteres cases fra kunder, der bruger et samlet backup-system, dvs. shared software, Media Agent Servers og lagringssystemer.
Case 1
Kunde. En russisk handels- og produktionsvirksomhed inden for slikmarkedet med et distribueret netværk af filialer i Rusland.
Opgaven.Organisering af backup for Microsoft SQL-databaser, filservere, applikationsservere og Exchange Online-postkasser.
De originale data er placeret på kontorer over hele Rusland (mere end 10 byer). Backup skal tages til DataLine-anlægget med efterfølgende gendannelse af data i hvilket som helst af virksomhedens kontorer.
Klienten ønskede dog fuld selvstændig kontrol med adgangsbegrænsning.
Opbevaringsdybde – et år. For Exchange Online – 3 måneder for operationelle kopier og et år for arkiver.
Løsningen. Der blev indstillet en ekstra kopi af databaserne til det anden anlæg: den seneste fulde backup fra måneden overføres til det andet anlæg og opbevares der i et år.
Kvaliteten af forbindelserne fra kundens fjernkontorer tillod ikke altid at udføre backup og gendannelse inden for optimale tidsrammer. For at reducere den overførte trafik blev der opsat deduplikation på kundens side. Dette gjorde, at tiden for en fuld backup af data blev acceptabelt taget i betragtning af afstanden mellem kontorerne. For eksempel tager en fuld backup af en database på 131 GB fra Sankt Petersborg 16 minutter. Fra Jekaterinburg tager backup af en database på 340 GB 1 time og 45 minutter.
Ved hjælp af roller indstillede kunden forskellige rettigheder for sine udviklere: kun til backup eller gendannelse.
Case 2
Kunde. Russisk kæde af butikker for børneartikler.
Opgaven. Organisering af backup for:
højtydende MS SQL-klynger baseret på 4 fysiske servere;
virtuelle maskiner med websteder, applikationsservere, 1C, Exchange og filservere.
Hele den nævnte infrastruktur er fordelt mellem OST og NORD-lokationerne.
RPO for SQL-servere er 30 minutter, for de andre er det 1 døgn.
Lagringsdybde – fra 2 uger til 30 dage afhængigt af datatypen.
Løsningen. Valgt kombination af løsninger baseret på Veeam og Commvault. Veeam bruges til filbackup fra vores cloud. Databaser, Active Directory, e-mail- og fysiske servere backs up via Commvault.
For at opnå høj hastighed i backupen tilknyttede kunden en separat netværksadapter på fysiske servere med MS SQL til backupopgaver. En fuld backup af en database på 3,4 TB tager 2 timer og 20 minutter, mens en fuld gendannelse tager 5 timer og 5 minutter.
Kunden havde et stort volumen af kilde data (næsten 18 TB). Hvis datamængden skulle lagres på et båndbibliotek, som kunden gjorde tidligere, ville det kræve flere dusin patroner. Dette ville komplicere styringen af hele kundens backup-system. Derfor blev båndbiblioteket i den endelige implementering erstattet med en SAN.
Case 3
Kunde. Kæde af supermarkeder i CIS
Opgaven. Kunden ønskede at organisere backup og gendannelse af SAP-systemer, der var placeret i vores cloud. For SAP HANA-databaser er RPO=15 minutter, for virtuelle maskiner med applikationsservere er RPO=24 timer. Lagringsdybden er 30 dage. I tilfælde af en ulykke er RTO=1 time, for gendannelse af en kopi efter anmodning er RTO=4 timer.
Løsningen. For the HANA database, backup of DATA files and log files was configured at a specified frequency. Log files were archived every 15 minutes or when a certain size was reached.
To reduce the database recovery time, we set up a two-tier backup storage based on a storage system and tape library. Active copies are stored on disks with the ability to restore at any point within a week. When a backup is older than 1 week, it is moved to the archive on the tape library, where it is kept for an additional 30 days.
A full backup of one of the databases with a size of 181 GB takes 1 hour and 54 minutes.
When setting up the backup, the SAP backint interface was used, allowing integration of third-party backup systems with SAP HANA Studio. Therefore, backups can be managed directly from the SAP console. This simplifies life for SAP administrators, who do not need to get accustomed to a new interface.
Backup management is also available to the client through the standard Commvault client console.
That's all for today. Feel free to ask questions in the comments.
Kilde: habr.com
