Այս նշումը ավարտում է կրկնօրինակման ցիկլը: Այն կքննարկի հատուկ սերվերի (կամ VPS) տրամաբանական կազմակերպումը, որը հարմար է պահուստավորման համար, ինչպես նաև կառաջարկի տարբերակ՝ արագ վերականգնելու սերվերը կրկնօրինակից՝ առանց մեծ խափանումների աղետի դեպքում:
Նախնական տվյալներ
Նվիրված սերվերն ամենից հաճախ ունի առնվազն երկու կոշտ սկավառակ, որոնք ծառայում են առաջին մակարդակի RAID զանգված (հայելին) կազմակերպելու համար: Սա անհրաժեշտ է, որպեսզի կարողանաք շարունակել աշխատել սերվերը, եթե մեկ սկավառակը ձախողվի: Եթե սա սովորական հատուկ սերվեր է, ապա SSD-ի վրա կարող է լինել առանձին ապարատային RAID կարգավորիչ՝ ակտիվ քեշավորման տեխնոլոգիայով, որպեսզի բացի սովորական կոշտ սկավառակներից, հնարավոր լինի միացնել մեկ կամ մի քանի SSD: Երբեմն առաջարկվում են հատուկ սերվերներ, որոնցում միակ տեղական սկավառակներն են SATADOM-ը (փոքր սկավառակներ, կառուցվածքայինորեն՝ SATA պորտին միացված ֆլեշ կրիչ), կամ նույնիսկ սովորական փոքր (8-16 ԳԲ) ֆլեշ կրիչը՝ միացված հատուկ ներքին պորտին, և տվյալները վերցված են պահեստավորման համակարգից, որը միացված է հատուկ պահպանման ցանցի միջոցով (Ethernet 10G, FC և այլն), և կան հատուկ սերվերներ, որոնք բեռնվում են անմիջապես պահեստավորման համակարգից: Ես նման տարբերակներ չեմ դիտարկի, քանի որ նման դեպքերում սերվերի կրկնօրինակման խնդիրը սահուն անցնում է պահեստավորման համակարգը սպասարկող մասնագետին. սովորաբար կան տարբեր սեփական տեխնոլոգիաներ՝ նկարներ ստեղծելու, ներկառուցված կրկնօրինակման և համակարգի ադմինիստրատորի այլ ուրախությունների համար: , քննարկվել է այս շարքի նախորդ մասերում։ Նվիրված սերվերի սկավառակների զանգվածի ծավալը կարող է հասնել մի քանի տասնյակ տերաբայթի՝ կախված սերվերին միացված սկավառակների քանակից և չափից: VPS-ի դեպքում ծավալներն ավելի համեստ են՝ սովորաբար ոչ ավելի, քան 100 ԳԲ (բայց կան նաև ավելին), և նման VPS-ի սակագները հեշտությամբ կարող են ավելի թանկ լինել, քան նույն հոսթերի ամենաէժան նվիրված սերվերները: VPS-ն ամենից հաճախ ունի մեկ սկավառակ, քանի որ դրա տակ կլինի պահեստավորման համակարգ (կամ հիպերկոնվերգացված ինչ-որ բան): Երբեմն VPS-ն ունի տարբեր բնութագրերով մի քանի սկավառակ՝ տարբեր նպատակների համար.
- փոքր համակարգ - օպերացիոն համակարգը տեղադրելու համար;
- մեծ - օգտագործողի տվյալների պահպանում:
Երբ համակարգը նորից տեղադրում եք կառավարման վահանակի միջոցով, օգտվողի տվյալների հետ սկավառակը չի վերագրվում, բայց համակարգի սկավառակն ամբողջությամբ լիցքավորվում է: Բացի այդ, VPS-ի դեպքում, հոսթերը կարող է առաջարկել կոճակ, որը նկարում է VPS-ի (կամ սկավառակի) վիճակի պատկերը, բայց եթե տեղադրեք ձեր սեփական օպերացիոն համակարգը կամ մոռանաք ակտիվացնել ցանկալի ծառայությունը VPS-ի ներսում, որոշ տվյալները դեռ կարող են կորել: Կոճակից բացի, սովորաբար առաջարկվում է տվյալների պահպանման ծառայություն, առավել հաճախ՝ շատ սահմանափակ: Սա սովորաբար հաշիվ է, որը հասանելի է FTP-ի կամ SFTP-ի միջոցով, երբեմն՝ SSH-ի հետ միասին, հանված կեղևով (օրինակ՝ rbash) կամ լիազորված_ստեղների միջոցով հրամաններ գործարկելու սահմանափակում (ForcedCommand-ի միջոցով):
Նվիրված սերվերը ցանցին միացված է երկու պորտով՝ 1 Գբիտ/վ արագությամբ, երբեմն դրանք կարող են լինել 10 Գբիտ/վ արագությամբ քարտեր։ VPS-ն ամենից հաճախ ունի մեկ ցանցային ինտերֆեյս: Ամենից հաճախ տվյալների կենտրոնները չեն սահմանափակում ցանցի արագությունը տվյալների կենտրոնի ներսում, բայց սահմանափակում են ինտերնետ հասանելիության արագությունը:
Նման նվիրված սերվերի կամ VPS-ի բնորոշ բեռնվածությունը վեբ սերվերն է, տվյալների բազան և հավելվածի սերվերը: Երբեմն կարող են տեղադրվել տարբեր լրացուցիչ օժանդակ ծառայություններ, այդ թվում՝ վեբ սերվերի կամ տվյալների բազայի համար՝ որոնման համակարգ, փոստային համակարգ և այլն:
Հատուկ պատրաստված սերվերը գործում է որպես պահեստային պատճեններ պահելու տարածք, որի մասին ավելի մանրամասն կգրենք ավելի ուշ:
Սկավառակի համակարգի տրամաբանական կազմակերպում
Եթե ունեք RAID վերահսկիչ կամ մեկ սկավառակով VPS, և չկան հատուկ նախապատվություններ սկավառակի ենթահամակարգի աշխատանքի համար (օրինակ՝ տվյալների բազայի համար առանձին արագ սկավառակ), ամբողջ ազատ տարածքը բաժանվում է հետևյալ կերպ. ստեղծվում է, և դրա վերևում ստեղծվում է LVM ծավալային խումբ, դրանում ստեղծվում են մի քանի հատորներ՝ նույն չափի 2 փոքր հատորներ, որոնք օգտագործվում են որպես արմատային ֆայլային համակարգ (փոփոխվում են մեկ առ մեկ թարմացումների ժամանակ՝ արագ վերադարձի հնարավորության համար, Գաղափարը վերցվել է «Calculate Linux» բաշխումից), ևս մեկը՝ swap բաժանման համար, մնացած ազատ տարածքը բաժանված է փոքր ծավալների, որն օգտագործվում է որպես արմատային ֆայլային համակարգ՝ լիարժեք կոնտեյներների, սկավառակներ վիրտուալ մեքենաների, ֆայլերի համար։ համակարգեր /home-ում հաշիվների համար (յուրաքանչյուր հաշիվ ունի իր ֆայլային համակարգը), ֆայլային համակարգեր հավելվածների կոնտեյներների համար:
Կարևոր նշում. հատորները պետք է լինեն ամբողջովին ինքնամփոփ, այսինքն. չպետք է կախված լինեն միմյանցից կամ արմատային ֆայլային համակարգից: Վիրտուալ մեքենաների կամ կոնտեյներների դեպքում այս կետը դիտվում է ավտոմատ կերպով։ Եթե դրանք հավելվածների կոնտեյներներ են կամ տնային դիրեկտորիաներ, ապա դուք պետք է մտածեք վեբ սերվերի և այլ ծառայությունների կազմաձևման ֆայլերը բաժանելու մասին այնպես, որ հնարավորինս վերացնի կախվածությունը ծավալների միջև: Օրինակ, յուրաքանչյուր կայք աշխատում է իր սեփական օգտագործողից, կայքի կազմաձևման ֆայլերը գտնվում են օգտագործողի գլխավոր գրացուցակում, վեբ սերվերի կարգավորումներում, կայքի կազմաձևման ֆայլերը ներառված չեն /etc/nginx/conf.d/-ի միջոցով:.conf և, օրինակ, /home//configs/nginx/*.conf
Եթե կան մի քանի սկավառակներ, կարող եք ստեղծել ծրագրային RAID զանգված (և կարգավորել դրա քեշը SSD-ի վրա, եթե կա անհրաժեշտություն և հնարավորություն), որի վերևում կարող եք կառուցել LVM՝ համաձայն վերը նշված կանոնների: Նաև այս դեպքում, դուք կարող եք օգտագործել ZFS կամ BtrFS, բայց դուք պետք է երկու անգամ մտածեք այս մասին. երկուսն էլ պահանջում են շատ ավելի լուրջ մոտեցում ռեսուրսների նկատմամբ, և բացի այդ, ZFS-ը ներառված չէ Linux միջուկում:
Անկախ օգտագործված սխեմայից, միշտ արժե նախօրոք գնահատել սկավառակների վրա փոփոխություններ գրելու մոտավոր արագությունը, այնուհետև հաշվարկել ազատ տարածության քանակը, որը կվերապահվի նկարներ ստեղծելու համար: Օրինակ, եթե մեր սերվերը տվյալներ է գրում վայրկյանում 10 մեգաբայթ արագությամբ, իսկ տվյալների ամբողջ զանգվածի չափը 10 տերաբայթ է, համաժամացման ժամանակը կարող է հասնել մեկ օրվա (22 ժամ. ահա թե որքան կփոխանցվի այդպիսի ծավալը: ցանցի միջոցով 1 Գբիտ/վ) - արժե վերապահել մոտ 800 ԳԲ: Իրականում ցուցանիշը ավելի փոքր կլինի, դուք կարող եք ապահով կերպով բաժանել այն տրամաբանական ծավալների քանակով:
Պահուստային պահեստավորման սերվերի սարք
Պահուստային պատճենները պահելու սերվերի հիմնական տարբերությունը նրա մեծ, էժան և համեմատաբար դանդաղ սկավառակներն են: Քանի որ ժամանակակից HDD-ները մեկ սկավառակի վրա արդեն հատել են 10 ՏԲ բարը, անհրաժեշտ է օգտագործել ֆայլային համակարգեր կամ RAID ստուգիչ գումարներով, քանի որ զանգվածի վերակառուցման կամ ֆայլային համակարգի վերականգնման ժամանակ (մի քանի օր!) երկրորդ սկավառակը կարող է ձախողվել: բեռի ավելացման համար. Մինչև 1 ՏԲ տարողությամբ սկավառակների վրա սա այնքան էլ զգայուն չէր: Նկարագրության պարզության համար ես ենթադրում եմ, որ սկավառակի տարածությունը բաժանված է մոտավորապես հավասար չափի երկու մասի (կրկին, օրինակ, օգտագործելով LVM).
- Օգտագործողի տվյալները պահելու համար օգտագործվող սերվերներին համապատասխան ծավալներ (վերջին արված կրկնօրինակը կտեղակայվի դրանց վրա՝ ստուգման համար);
- որպես BorgBackup պահոցներ օգտագործվող հատորներ (կրկնօրինակների տվյալները ուղղակիորեն կգտնվեն այստեղ):
Գործողության սկզբունքն այն է, որ յուրաքանչյուր սերվերի համար ստեղծվում են առանձին հատորներ BorgBackup պահեստների համար, որտեղ կգնան մարտական սերվերների տվյալները։ Պահեստները գործում են միայն հավելվածի ռեժիմով, ինչը բացառում է տվյալների միտումնավոր ջնջման հնարավորությունը, ինչպես նաև հին պահուստներից պահեստների կրկնօրինակման և պարբերական մաքրման պատճառով (տարեկան պատճենները մնում են՝ ամսական վերջին տարվա համար, շաբաթական վերջին ամսվա համար, օրական՝ Անցյալ շաբաթ, հնարավոր է հատուկ դեպքերում - վերջին օրվա ժամային ժամ. ընդհանուր 24 + 7 + 4 + 12 + տարեկան - մոտավորապես 50 օրինակ յուրաքանչյուր սերվերի համար):
BorgBackup-ի պահոցները չեն միացնում միայն հավելվածի ռեժիմը, փոխարենը .ssh/authorized_keys-ում ForcedCommand-ն օգտագործվում է այսպես.
from="адрес сервера",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.......Նշված ուղին պարունակում է borg-ի վերևում գտնվող փաթաթման սցենար, որը, բացի պարամետրերով երկուականը գործարկելուց, լրացուցիչ սկսում է տվյալների հեռացումից հետո կրկնօրինակի վերականգնման գործընթացը: Դա անելու համար wrapper script-ը ստեղծում է պիտակի ֆայլ՝ համապատասխան պահեստի կողքին: Վերջին արված կրկնօրինակը ավտոմատ կերպով վերականգնվում է համապատասխան տրամաբանական ծավալին՝ տվյալների լրացման գործընթացի ավարտից հետո:
Այս դիզայնը թույլ է տալիս պարբերաբար մաքրել անհարկի կրկնօրինակները, ինչպես նաև թույլ չի տալիս մարտական սերվերներին որևէ բան ջնջել պահեստային պահեստային սերվերի վրա:
Կրկնօրինակման գործընթաց
Կրկնօրինակման նախաձեռնողը հատուկ սերվերն է կամ ինքը՝ VPS-ը, քանի որ այս սխեման ավելի շատ վերահսկողություն է տալիս այս սերվերի կողմից կրկնօրինակման գործընթացի վրա: Նախ, վերցվում է ակտիվ արմատային ֆայլային համակարգի վիճակի պատկերը, որը տեղադրվում և վերբեռնվում է BorgBackup-ի միջոցով պահեստային պահեստավորման սերվերում: Տվյալների հավաքագրման ավարտից հետո պատկերն ապամոնտաժվում և ջնջվում է:
Եթե կա փոքր տվյալների բազա (մինչև 1 ԳԲ յուրաքանչյուր կայքի համար), ապա կազմվում է տվյալների բազայի աղբանոց, որը պահպանվում է համապատասխան տրամաբանական ծավալով, որտեղ գտնվում են նույն կայքի մնացած տվյալները, բայց այնպես, որ աղբանոցը լինի. հասանելի չէ վեբ սերվերի միջոցով: Եթե տվյալների բազաները մեծ են, դուք պետք է կարգավորեք «տաք» տվյալների հեռացումը, օրինակ՝ օգտագործելով xtrabackup MySQL-ի համար, կամ աշխատեք WAL-ի հետ archive_command-ով PostgreSQL-ում: Այս դեպքում տվյալների բազան կվերականգնվի կայքի տվյալներից առանձին:
Եթե օգտագործվում են կոնտեյներներ կամ վիրտուալ մեքենաներ, դուք պետք է կարգավորեք qemu-guest-agent, CRIU կամ այլ անհրաժեշտ տեխնոլոգիաներ: Այլ դեպքերում լրացուցիչ կարգավորումներ ամենից հաճախ անհրաժեշտ չեն. մենք պարզապես ստեղծում ենք տրամաբանական ծավալների նկարներ, որոնք այնուհետև մշակվում են այնպես, ինչպես արմատային ֆայլային համակարգի վիճակի պատկերը: Տվյալները վերցնելուց հետո նկարները ջնջվում են։
Հետագա աշխատանքն իրականացվում է պահեստային պահպանման սերվերի վրա.
- յուրաքանչյուր պահոցում կատարված վերջին կրկնօրինակը ստուգվում է,
- ստուգվում է նշանի ֆայլի առկայությունը՝ նշելով, որ տվյալների հավաքագրման գործընթացը ավարտված է,
- տվյալները ընդլայնվում են համապատասխան տեղական ծավալով,
- պիտակի ֆայլը ջնջված է
Սերվերի վերականգնման գործընթաց
Եթե հիմնական սերվերը մեռնում է, ապա գործարկվում է նմանատիպ նվիրված սերվեր, որը բացվում է ինչ-որ ստանդարտ պատկերից: Ամենայն հավանականությամբ, ներբեռնումը կկատարվի ցանցի միջոցով, սակայն տվյալների կենտրոնի տեխնիկը, որը տեղադրում է սերվերը, կարող է անմիջապես պատճենել այս ստանդարտ պատկերը սկավառակներից մեկում: Ներբեռնումը տեղի է ունենում RAM-ում, որից հետո սկսվում է վերականգնման գործընթացը.
- հարցում է արվում բլոկ սարքը iscsinbd-ի կամ նմանատիպ այլ արձանագրության միջոցով կցել տրամաբանական ծավալին, որը պարունակում է մահացած սերվերի արմատային ֆայլային համակարգը. Քանի որ արմատային ֆայլային համակարգը պետք է փոքր լինի, այս քայլը պետք է ավարտվի մի քանի րոպեում: Բեռնախցիկը նույնպես վերականգնված է.
- տեղական տրամաբանական ծավալների կառուցվածքը վերստեղծվում է, տրամաբանական ծավալները կցվում են պահուստային սերվերից՝ օգտագործելով dm_clone միջուկի մոդուլը. տվյալների վերականգնումը սկսվում է, և փոփոխություններն անմիջապես գրվում են տեղական սկավառակների վրա։
- բեռնարկղը գործարկվում է բոլոր հասանելի ֆիզիկական սկավառակներով - սերվերի ֆունկցիոնալությունը լիովին վերականգնված է, բայց նվազեցված կատարողականությամբ.
- տվյալների համաժամացման ավարտից հետո պահեստային սերվերից տրամաբանական ծավալներն անջատված են, կոնտեյները անջատված է, և սերվերը վերագործարկվում է.
Վերագործարկումից հետո սերվերը կունենա բոլոր տվյալները, որոնք եղել են պահուստավորման ստեղծման պահին, ինչպես նաև կներառի բոլոր փոփոխությունները, որոնք կատարվել են վերականգնման գործընթացում:
Շարքի այլ հոդվածներ
Կրկնօրինակ Մաս 7. Եզրակացություններ
Հրավիրում եմ ձեզ մեկնաբանություններում քննարկել առաջարկվող տարբերակը, շնորհակալություն ուշադրության համար:
Source: www.habr.com