En antaŭaj afiŝoj, ni dividis instrukciojn por agordo и surbaze de Veeam. Hodiaŭ ni volas paroli pri sekurkopio uzante Commvault. Ne estos instrukcioj, sed ni diros al vi, kion kaj kiel niaj klientoj jam subtenas.
Stoksistemo de rezerva sistemo bazita sur Commvault en la datumcentro OST-2.
Kiel ĝi funkcias?
Commvault estas rezerva platformo por aplikoj, datumbazoj, dosiersistemoj, virtualaj maŝinoj kaj fizikaj serviloj. En ĉi tiu kazo, la komencaj datumoj povas esti en iu ajn retejo: ĉe ni - ĉe la kliento, en alia komerca datumcentro aŭ en la nubo.
La kliento instalas agenton sur rezervaj objektoj - iData Agento - kaj agordas ĝin laŭ la postulataj rezervaj politikoj. iData Agent kolektas la necesajn datumojn, kunpremas, malduplicas, ĉifras kaj transdonas ilin al la rezerva sistemo DataLine.
Prokuraj serviloj certigi la konekteblecon de la klienta reto kaj nia reto, la izolado de la kanaloj tra kiuj datumoj estas transdonitaj.
Sur la DataLine-flanko, datumoj de la iData Agento ricevas Media Agent Server kaj sendas ĝin al stokado en stoksistemoj, bendbibliotekoj, ktp. Ĉio ĉi estas administrita de Commserve. En nia agordo, la ĉefa kontrolservilo situas sur la OST-ejo, kaj la rezerva servilo situas sur la NORD-ejo.
Defaŭlte, klientdatenoj estas konservitaj en unu retejo, sed vi povas organizi sekurkopiojn al du lokoj samtempe aŭ agordi horaron por translokigi sekurkopiojn al dua retejo. Ĉi tiu opcio nomiĝas "helpa kopio". Ekzemple, ĉiuj plenaj sekurkopioj fine de la monato estos aŭtomate duobligitaj aŭ translokitaj al dua retejo.
Skemo de operacio de la Commvault rezerva sistemo.
La rezerva sistemo funkcias ĉefe pri VMware-virtualigo: CommServe, Media Agent kaj Proxy-serviloj estas deplojitaj sur virtualaj maŝinoj. Se la kliento uzas nian ekipaĵon, tiam la sekurkopioj estas metitaj sur la stoksistemon Huawei OceanStor 5500 V3. Por sekurkopii klientajn stoksistemojn, stoki sekurkopiojn sur bendbibliotekoj, apartaj Media Agents sur fizikaj serviloj estas uzataj.
Kio estas grava por klientoj?
Laŭ nia sperto, klientoj, kiuj elektas Commvault por sekurkopio, atentas la sekvajn punktojn.
Konzolo. Klientoj volas administri sekurkopiojn mem. Ĉiuj bazaj operacioj estas haveblaj en la Commvault-konzolo:
- aldoni kaj forigi servilojn por sekurkopio;
- starigi iData Agent;
- kreado kaj manlibro de taskoj;
- mem-restarigo de sekurkopioj;
- agordi sciigojn pri la stato de rezervaj taskoj;
- diferencigo de aliro al la konzolo depende de la rolo kaj grupo de uzantoj.
Dedupliko. Deduplikado permesas vin trovi kaj forigi duplikatajn blokojn de datumoj dum la rezerva procezo. Tiel, ĝi helpas ŝpari spacon en la stokadsistemo kaj reduktas la kvanton de datumoj transdonitaj, reduktante la postulojn por larĝa de bando. Sen dedupliko, sekurkopioj prenus ĝis du ĝis tri fojojn la grandecon de la originaj datumoj.
En la kazo de Commvault, deduplikado povas esti agordita ĉe la klientflanko aŭ sur la Media Agent-flanko. En la unua kazo, ne-unikaj datumblokoj eĉ ne estos translokigitaj al la Media Agent Server. En la dua, la ripeta bloko estas forĵetita kaj ne skribita al la stokadsistemo.
Tia bloka deduplikado baziĝas sur haŝfunkcioj. Al ĉiu bloko estas asignita hash, kiu estas stokita en hash-tabelo, speco de datumbazo (Deduplication Database, DDB). Dum transdonado de datumoj, la haŝiŝo estas "truita" tra ĉi tiu bazo. Se tia hash jam estas en la datumbazo, tiam la bloko estas markita kiel ne-unika kaj ne estas transdonita al la Media Agent Server (en la unua kazo) aŭ ne estas skribita al la datumstokado (en la dua).
Danke al maldupliko ni povas ŝpari ĝis 78% de stokado. Nun 166,4 TB estas stokitaj en stokado. Sen deduplikado, ni devus stoki 744 TB.
Eblo diferencigi rajtojn. Commvault havas la kapablon agordi malsamajn nivelojn de aliro al rezerva administrado. La tiel nomataj "roloj" determinas, kiaj agoj estos uzanto rilate al rezervaj objektoj. Ekzemple, programistoj nur povos restarigi servilon kun datumbazo al specifa loko, dum administranto povos fari neordigan sekurkopion por la sama servilo kaj aldoni novajn uzantojn.
Ĉifrado. Vi povas ĉifri datumojn dum sekurkopio per Commvault laŭ la jenaj manieroj:
- flanke de la klienta agento: en ĉi tiu kazo, la datumoj estos transdonitaj al la rezerva sistemo jam en ĉifrita formo;
- sur la Media Agent-flanko;
- ĉe la kanalnivelo: datumoj estas ĉifritaj flanke de la klientagento kaj deĉifritaj sur la Media Agent Server.
Disponeblaj ĉifradaj algoritmoj: Blowfish, GOST, Serpent, Twofish, 3-DES, AES (rekomendita de Commvault).
Iuj statistikoj
Meze de decembro, kun la helpo de Commvault, ni havas 27 klientojn sekurkopiantaj. Plej multaj el ili estas komercistoj kaj financaj institucioj. La totala kvanto de originalaj kopiaj datumoj estas 65 TB.
Ĉirkaŭ 4400 taskoj estas plenumitaj ĉiutage. Malsupre estas statistikoj pri plenumitaj taskoj dum la lastaj 16 tagoj.
Plejparte, Vindoza Dosiersistemo, SQL-Servilo kaj Interŝanĝaj datumbazoj estas sekurkopiitaj per Commvault.
Kaj nun la promesitaj kazoj. Kvankam nepersonaj (NDA salutas :)), ili donas ideon pri kio kaj kiel klientoj uzas sekurkopion bazitan sur Commvault. Malsupre estas kazesploroj por klientoj, kiuj uzas ununuran rezervan sistemon, t.e. komunan programaron, Media Agent-Servilojn kaj stokadsistemojn.
Kazo 1
Kliento. Rusa komerca kaj fabrikada kompanio de la sukeraĵa merkato kun distribuata reto de branĉoj tra Rusio.
Tasko.Organizo de sekurkopioj por Microsoft SQL-datumbazoj, dosierserviloj, aplikaĵserviloj, Exchange Online leterkestoj.
La komencaj datumoj troviĝas en oficejoj tra Rusio (pli ol 10 urboj). Vi devas sekurkopii al la retejo de DataLine kun posta reakiro de datumoj en iu ajn el la oficejoj de la kompanio.
Samtempe, la kliento volis plenan memadministradon kun alirkontrolo.
Profundo de stokado - jaro. Por Exchange Online, 3 monatoj por interretaj kopioj kaj jaro por arkivoj.
La decido. Plia kopio estis starigita por la datumbazoj en la dua retejo: la lasta plena sekurkopio de la monato estas translokigita al alia retejo kaj konservita tie dum jaro.
La kvalito de la kanaloj de la foraj oficejoj de la kliento ne ĉiam permesis sekurkopion kaj restarigon en la optimuma tempokadro. Por redukti la kvanton de transdonita trafiko, dedupliko estis agordita ĉe la klientflanko. Danke al ŝi, la tempo de plena sekurkopio iĝis akceptebla, konsiderante la malproksimecon de la oficejoj. Ekzemple, plena datumbaza sekurkopio de 131 GB de Sankt-Peterburgo estas farita en 16 minutoj. De Jekaterinburg, 340 GB-datumbazo estas konservita dum 1 horo 45 minutoj.
Per roloj, la kliento agordis malsamajn permesojn por siaj programistoj: nur sekurkopion aŭ restarigi.
Kazo 2
Kliento. Rusa ĉeno de vendejoj por infanoj.
Tasko. Organizo de sekurkopio por:
tre ŝarĝita MS SQL-areto bazita sur 4 fizikaj serviloj;
virtualaj maŝinoj kun retejo, aplikaĵserviloj, 1C, Exchange kaj dosierserviloj.
La tuta specifita infrastrukturo de la kliento estas interspacigita inter la OST kaj NORD-ejoj.
RPO por SQL-serviloj - 30 minutoj, por la resto - 1 tago.
Profundo de stokado - de 2 semajnoj ĝis 30 tagoj, depende de la tipo de datumoj.
La decido. Ni elektis kombinaĵon de solvoj bazitaj sur Veeam kaj Commvault. Veeam estas uzata por sekurkopioj de dosieroj de nia nubo. Datumbazaj serviloj, Aktiva Adresaro, poŝto kaj fizikaj serviloj estas sekurkopiitaj per Commvault.
Por atingi altan rezervan rapidecon, la kliento asignis apartan retadaptilon sur fizikaj serviloj kun MS SQL por rezervaj taskoj. Plena sekurkopio de 3,4 TB datumbazo daŭras 2 horojn 20 minutojn, kaj plena restarigo daŭras 5 horojn 5 minutojn.
La kliento havis grandan kvanton da komencaj datumoj (preskaŭ 18 TB). Se la datenoj estus stakigitaj sur bendbibliotekon, kiel la kliento faris antaŭe, tiam pluraj dekduoj da kartoĉoj estus postulataj. Ĉi tio malfaciligus la administradon de la tuta rezerva sistemo de la kliento. Tial, en la fina efektivigo, la glubendbiblioteko estis anstataŭigita per stokadsistemo.
Kazo 3
Kliento. Superbazara ĉeno en la CIS
Tasko. La kliento volis subteni kaj restarigi SAP-sistemojn gastigitajn en nia nubo. Por SAP HANA datumbazoj RPO=15 minutoj, por virtualaj maŝinoj kun aplikaĵserviloj RPO=24 horoj. Profundo de stokado - 30 tagoj. En kazo de akcidento RTO=1 horo, restarigi kopion laŭpeto RTO=4 horoj.
La decido. Por la HANA-datumbazo, sekurkopioj de DATA-dosieroj kaj Log-dosieroj estis agorditaj je specifaj intervaloj. Registrodosieroj estis arkivitaj ĉiujn 15 minutojn aŭ kiam ili atingis certan grandecon.
Por redukti la reakirotempon de la datumbazo, ni starigis dunivelan stokadon de sekurkopioj bazitaj sur la stokadosistemo kaj la bendobiblioteko. Enretaj kopioj estas aldonitaj al la diskoj kun la ebleco de reakiro en ajna momento dum la semajno. Kiam la sekurkopio fariĝas pli malnova ol 1 semajno, ĝi estas movita al la arkivo, al la bendobiblioteko, kie ĝi estas konservita dum pliaj 30 tagoj.
Plena sekurkopio de unu el la 181 GB-datumbazoj estas farita en 1 horo 54 minutoj.
Kiam oni agordas sekurkopion, oni uzis la SAP-backint-interfacon, kiu ebligas integri triajn sekurkopiajn sistemojn kun SAP HANA Studio. Tial sekurkopioj povas esti administritaj rekte de la SAP-konzolo. Ĉi tio faciligas la vivon al administrantoj de SAP, kiuj ne devas alkutimiĝi al la nova interfaco.
Rezervadministrado ankaŭ estas havebla al la kliento per la norma klientkonzolo Commvault.
Tio estas ĉio por hodiaŭ. Demandu en la komentoj.
fonto: www.habr.com