Աշխարհը տեսավ օբյեկտների պահպանման առաջին նախատիպը 1996 թվականին: 10 տարի հետո Amazon Web Services-ը կգործարկի Amazon S3-ը, և աշխարհը կսկսի համակարգված կերպով խենթանալ հարթ հասցեի տարածության հետ: Մետատվյալների հետ աշխատելու և առանց ծանրաբեռնվածության տակ ընկնելու դրա ունակության շնորհիվ օբյեկտների պահպանումը արագորեն դարձավ ստանդարտ ամպային տվյալների պահպանման ծառայությունների մեծ մասի համար, և ոչ միայն դա: Մեկ այլ կարևոր առանձնահատկությունն այն է, որ այն լավ հարմար է արխիվների և նմանատիպ հազվադեպ օգտագործվող ֆայլերի պահպանման համար: Բոլորը, ովքեր ներգրավված էին տվյալների պահպանման մեջ, ուրախացան և իրենց գրկում կրեցին նոր տեխնոլոգիան:
Բայց մարդկանց խոսակցությունները լի էին ասեկոսեներով, որ օբյեկտների պահեստավորումը միայն մեծ ամպերի մասին է, և եթե ձեզ անիծյալ կապիտալիստների լուծումները պետք չեն, ապա շատ դժվար կլինի ձեր սեփականը պատրաստելը: Արդեն շատ բան է գրվել ձեր սեփական ամպի տեղակայման մասին, սակայն բավարար տեղեկատվություն չկա, այսպես կոչված, S3-ի հետ համատեղելի լուծումներ ստեղծելու մասին:
Հետևաբար, այսօր մենք կպարզենք, թե ինչ տարբերակներ կան «Որպեսզի դա լինի մեծահասակների, այլ ոչ թե CEPH և ավելի մեծ ֆայլի», մենք կտեղակայենք դրանցից մեկը և կստուգենք, որ ամեն ինչ աշխատում է Veeam Backup & Replication-ի միջոցով: Այն պնդում է, որ աջակցում է S3-ի հետ համատեղելի պահեստների հետ աշխատելուն, և մենք կփորձարկենք այս պահանջը:
Ինչ վերաբերում է մյուսներին:
Ես առաջարկում եմ սկսել շուկայի և օբյեկտների պահպանման տարբերակների փոքր ակնարկից: Ընդհանուր առմամբ ճանաչված առաջատարը և ստանդարտը Amazon S3-ն է: Երկու ամենամոտ հետապնդողներն են Microsoft Azure Blob Storage-ը և IBM Cloud Object Storage-ը:
Արդյո՞ք այս ամենը: Իսկապե՞ս այլ մրցակիցներ չկան։ Իհարկե, կան մրցակիցներ, բայց ոմանք գնում են իրենց ճանապարհով, օրինակ՝ Google Cloud-ը կամ Oracle Cloud Object Storage-ը՝ S3 API-ի թերի աջակցությամբ: Ոմանք օգտագործում են API-ի ավելի հին տարբերակները, օրինակ՝ Baidu Cloud-ը: Իսկ ոմանք, ինչպես Hitachi Cloud-ը, պահանջում են հատուկ տրամաբանություն, որն անշուշտ կառաջացնի իր սեփական դժվարությունները։ Ամեն դեպքում, բոլորին համեմատում են Amazon-ի հետ, որը կարելի է համարել ոլորտի ստանդարտը։
Բայց ներկառուցված լուծումներում շատ ավելի մեծ ընտրություն կա, ուստի եկեք նախանշենք մեզ համար կարևոր չափանիշները: Սկզբունքորեն, միայն երկուսը բավարար են՝ աջակցություն S3 API-ին և v4 ստորագրման օգտագործումը: Մենք՝ որպես ապագա հաճախորդ, շահագրգռված ենք միայն փոխազդեցության համար նախատեսված ինտերֆեյսներով, և մենք այնքան էլ հետաքրքրված չենք հենց պահեստի ներքին խոհանոցով:
Շատ լուծումներ համապատասխանում են այս պարզ պայմաններին: Օրինակ, դասական կորպորատիվ ծանր քաշայիններ.
- DellEMC ECS
- NetApp S3 StorageGrid
- Nutanix դույլեր
- Pure Storage FlashBlade և StorReduce
- Huawei FusionStorage
Գոյություն ունի զուտ ծրագրային լուծումների մի տեղ, որոնք աշխատում են առանց տուփի.
- Red Hat Ceph
- SUSE Enterprise Storage
- Ամպամած
Եվ նույնիսկ նրանք, ովքեր սիրում են հավաքից հետո զգուշորեն ներկայացնել, չվիրավորվեցին.
- CEPH-ն իր մաքուր տեսքով
- Minio (Linux տարբերակ, քանի որ Windows-ի տարբերակի վերաբերյալ շատ հարցեր կան)
Ցուցակը հեռու է ամբողջական լինելուց, այն կարելի է քննարկել մեկնաբանություններում։ Պարզապես մի մոռացեք ստուգել համակարգի կատարումը, բացի API-ի համատեղելիությունից, նախքան իրականացումը: Վերջին բանը, որ դուք ցանկանում եք, տերաբայթ տվյալների կորուստն է խրված հարցումների պատճառով: Այսպիսով, մի ամաչեք բեռի թեստերից: Ընդհանուր առմամբ, մեծահասակների համար նախատեսված բոլոր ծրագրերը, որոնք աշխատում են մեծ քանակությամբ տվյալների հետ, ունեն առնվազն համատեղելիության հաշվետվություններ: Դեպքում Վէյամ կա փոխադարձ փորձարկման վրա, ինչը մեզ թույլ է տալիս վստահորեն հայտարարել մեր արտադրանքի ամբողջական համատեղելիությունը կոնկրետ սարքավորումների հետ: Սա արդեն երկկողմանի աշխատանք է, ոչ միշտ արագ, բայց մենք անընդհատ ընդլայնվում ենք փորձարկված լուծումներ.
Մեր ստենդը հավաքելը
Կցանկանայի մի փոքր խոսել թեստային առարկայի ընտրության մասին։
Նախ, ես ուզում էի գտնել մի տարբերակ, որը կաշխատի անմիջապես տուփից դուրս: Դե, կամ գոնե առավելագույն հավանականությամբ, որ այն կաշխատի առանց ավելորդ շարժումներ անելու։ Գիշերը դափի հետ պարելը և մխիթարելը շատ հուզիչ է, բայց երբեմն ուզում ես, որ այն անմիջապես աշխատի: Եվ նման լուծումների ընդհանուր հուսալիությունը սովորաբար ավելի բարձր է: Եվ այո, մեր մեջ անհետացել է արկածախնդրության ոգին, մենք դադարել ենք բարձրանալ մեր սիրելի կանանց պատուհանների մեջ և այլն (գ):
Երկրորդ, եթե անկեղծ լինենք, օբյեկտների պահեստավորման հետ աշխատելու անհրաժեշտություն առաջանում է բավականին խոշոր ընկերություններում, ուստի սա հենց այն դեպքն է, երբ ձեռնարկության մակարդակի լուծումներ փնտրելը ոչ միայն ամոթալի չէ, այլ նույնիսկ խրախուսելի: Ամեն դեպքում, ես դեռ չգիտեմ որևէ օրինակ, որ որևէ մեկը աշխատանքից հեռացվի նման լուծումներ գնելու համար։
Ելնելով վերը նշված բոլորից՝ իմ ընտրությունն ընկավ Dell EMC ECS Համայնքային հրատարակություն. Սա շատ հետաքրքիր նախագիծ է, և ես հարկ եմ համարում պատմել դրա մասին։
Առաջին բանը, որ գալիս է ձեր մտքին, երբ տեսնում եք հավելումը Համայնքի հրատարակություն - որ սա ընդամենը լիարժեք ECS-ի պատճեն է՝ որոշ սահմանափակումներով, որոնք հանվում են լիցենզիա ձեռք բերելով: Այնպես որ, ոչ!
Հիշեք `
!!!Community Edition-ը փորձարկման համար ստեղծված առանձին նախագիծ է և առանց Dell-ի տեխնիկական աջակցության։
Եվ այն չի կարող վերածվել լիարժեք ECS, նույնիսկ եթե դուք իսկապես ցանկանում եք դա:
Հասկանում ենք
Շատերը կարծում են, որ Dell EMC ECS-ը գրեթե լավագույն լուծումն է, եթե դուք ունեք օբյեկտների պահպանման կարիք: ECS ապրանքանիշի ներքո գտնվող բոլոր նախագծերը, ներառյալ առևտրային և կորպորատիվ, հիմնված են . Մի տեսակ բարի կամքի ժեստ Dell-ից: Եվ ի լրումն ծրագրաշարի, որն աշխատում է իրենց բրենդավորված սարքաշարի վրա, կա բաց կոդով տարբերակ, որը կարող է տեղակայվել ամպի, վիրտուալ մեքենայի, կոնտեյների կամ ձեր սեփական սարքաշարի վրա: Առաջ նայելով, նույնիսկ կա OVA տարբերակ, որը մենք կօգտագործենք։
DELL ECS Community Edition-ը ինքնին լիարժեք ծրագրաշարի մինի տարբերակ է, որն աշխատում է ֆիրմային Dell EMC ECS սերվերների վրա:
Ես առանձնացրեցի չորս հիմնական տարբերություն.
- Կոդավորման աջակցություն չկա: Ամոթ է, բայց ոչ քննադատական:
- Գործվածքի շերտը բացակայում է: Այս բանը պատասխանատու է կլաստերների ստեղծման, ռեսուրսների կառավարման, թարմացումների, Docker պատկերների մոնիտորինգի և պահպանման համար: Այստեղ դա արդեն շատ վիրավորական է, բայց Dell-ին նույնպես կարելի է հասկանալ:
- Նախորդ կետի ամենազզվելի հետևանքը՝ հանգույցի չափը չի կարող ընդլայնվել տեղադրման ավարտից հետո։
- Տեխնիկական աջակցություն չկա: Սա փորձարկման համար նախատեսված արտադրանք է, որն արգելված չէ օգտագործել փոքր կայանքներում, բայց ես անձամբ չէի համարձակվի այնտեղ բեռնել petabytes կարևոր տվյալներ։ Բայց տեխնիկապես ոչ ոք չի կարող ձեզ խանգարել դա անել:
Ի՞նչ կա մեծ տարբերակում:
Եկեք շրջենք ամբողջ Եվրոպայով և անցնենք երկաթե լուծումների միջով, որպեսզի ավելի ամբողջական պատկերացում ունենանք էկոհամակարգի մասին:
Ես ինչ-որ կերպ չեմ հաստատի կամ հերքի այն հայտարարությունը, որ DELL ECS-ը լավագույն պրեմիում գտնվող օբյեկտների պահեստավորումն է, բայց եթե որևէ բան ունեք ասելու այս թեմայի վերաբերյալ, ուրախ կլինեմ կարդալ այն մեկնաբանություններում: Գոնե վարկածի համաձայն Dell EMC-ն վստահորեն OBS շուկայի առաջատարների հնգյակում է: Թեև այնտեղ ամպի վրա հիմնված լուծումները հաշվի չեն առնվում, սա առանձին խոսակցություն է։
Տեխնիկական տեսանկյունից ECS-ը օբյեկտների պահեստավորում է, որն ապահովում է տվյալների հասանելիություն՝ օգտագործելով ամպային պահպանման արձանագրությունները: Աջակցում է AWS S3-ին և OpenStack Swift-ին: Ֆայլերով միացված դույլերի համար ECS-ն աջակցում է NFSv3 ֆայլ առ ֆայլ արտահանման համար:
Տեղեկատվության գրանցման գործընթացը բավականին անսովոր է, հատկապես դասական բլոկների պահպանման համակարգերից հետո:
- Երբ նոր տվյալներ են գալիս, ստեղծվում է նոր օբյեկտ, որն ունի անուն, տվյալներ և մետատվյալներ:
- Օբյեկտները բաժանվում են 128 ՄԲ հատվածների, և յուրաքանչյուր հատվածը գրվում է միանգամից երեք հանգույցի վրա:
- Ինդեքսային ֆայլը թարմացվում է, որտեղ գրանցվում են նույնացուցիչները և պահեստավորման վայրերը:
- Մատյան ֆայլը (տեղեկամատյան մուտքագրումը) թարմացվում է և գրվում է երեք հանգույցների վրա:
- Հաճախորդին ուղարկվում է հաղորդագրություն հաջող ձայնագրման մասին
Տվյալների բոլոր երեք օրինակները գրված են զուգահեռ: Գրությունը հաջողված է համարվում միայն այն դեպքում, եթե բոլոր երեք օրինակները հաջողությամբ են գրվել:
Ընթերցանությունն ավելի հեշտ է.
- Հաճախորդը պահանջում է տվյալներ:
- Ցուցանիշը փնտրում է, թե որտեղ են պահվում տվյալները:
- Տվյալները կարդացվում են մեկ հանգույցից և ուղարկվում հաճախորդին:
Կան բավականին շատ սերվերներ, ուստի եկեք նայենք ամենափոքր Dell EMC ECS EX300-ին: Այն սկսվում է 60TB-ից, մինչև 1,5PB աճելու հնարավորությամբ։ Իսկ նրա ավագ եղբայրը՝ Dell EMC ECS EX3000-ը, թույլ է տալիս պահել մինչև 8,6 PB մեկ դարակում:
Տեղակայել
Տեխնիկապես, Dell ECS CE-ն կարող է տեղակայվել այնքան մեծ, որքան ցանկանում եք: Ամեն դեպքում, ես հստակ սահմանափակումներ չգտա։ Այնուամենայնիվ, հարմար է կատարել ամբողջ մասշտաբը` կլոնավորելով հենց առաջին հանգույցը, որի համար մեզ անհրաժեշտ է.
- 8 vCPU
- 64GB RAM- ը
- 16 ԳԲ ՕՀ-ի համար
- 1TB ուղղակի պահեստավորում
- CentOS minimal-ի վերջին թողարկումը
Սա այն տարբերակն է, երբ ցանկանում եք ամեն ինչ ինքներդ տեղադրել հենց սկզբից: Այս տարբերակը մեզ համար ակտուալ չէ, քանի որ... Ես կօգտագործեմ OVA պատկերը տեղակայման համար:
Բայց ամեն դեպքում, պահանջները շատ չար են նույնիսկ մեկ հանգույցի համար, և եթե խստորեն հետևում եք օրենքի տառին, ապա ձեզ հարկավոր է չորս այդպիսի հանգույց։
Այնուամենայնիվ, ECS CE մշակողները ապրում են իրական աշխարհում, և տեղադրումը հաջողված է նույնիսկ մեկ հանգույցով, և նվազագույն պահանջներն են.
- 4 vCPU
- 16 GB RAM
- 16 ԳԲ ՕՀ-ի համար
- Ինքնին 104 ԳԲ պահեստավորում
Սրանք այն ռեսուրսներն են, որոնք անհրաժեշտ են OVA պատկերը տեղակայելու համար: Արդեն շատ ավելի մարդասեր ու իրատեսական։
Ինքնին տեղադրման հանգույցը կարելի է ձեռք բերել պաշտոնականից . Կան նաև մանրամասն փաստաթղթեր «ամբողջը մեկում» տեղակայման վերաբերյալ, բայց կարող եք նաև կարդալ պաշտոնական կայքում . Հետևաբար, մենք մանրամասն չենք անդրադառնա OVA-ի բացման վրա, այնտեղ հնարքներ չկան: Հիմնական բանը այն է, որ նախքան այն սկսելը, մի մոռացեք կամ ընդլայնել սկավառակը պահանջվող ծավալին, կամ կցել անհրաժեշտները:
Մենք գործարկում ենք մեքենան, բացում ենք վահանակը և օգտագործում լավագույն լռելյայն հավատարմագրերը.
- մուտք: admin
- գաղտնաբառը՝ ChangeMe
Այնուհետև մենք գործարկում ենք sudo nmtui և կարգավորում ենք ցանցի միջերեսը՝ IP/mask, DNS և gate: Հաշվի առնելով, որ CentOS minimal-ը չունի ցանցային գործիքներ, մենք կարգավորումները ստուգում ենք ip addr-ի միջոցով:
Եվ քանի որ ծովերը նվաճում են միայն համարձակները, մենք կատարում ենք yum թարմացում, որից հետո վերագործարկում ենք: Դա իրականում բավականին անվտանգ է, քանի որ... բոլոր տեղակայումը կատարվում է playbooks-ի միջոցով, և բոլոր կարևոր դոկերի փաթեթները կողպված են ընթացիկ տարբերակում:
Այժմ ժամանակն է խմբագրել տեղադրման սցենարը: Ոչ մի շքեղ պատուհաններ կամ կեղծ միջերես ձեզ համար. ամեն ինչ արվում է ձեր սիրելի տեքստային խմբագրիչի միջոցով: Տեխնիկապես երկու եղանակ կա. կարող եք յուրաքանչյուր հրաման գործարկել ձեռքով կամ անմիջապես գործարկել videoploy կազմաձևիչը: Այն պարզապես կբացի կոնֆիգուրը vim-ում, և դուրս գալուց հետո կսկսի ստուգել այն: Բայց ձեր կյանքը միտումնավոր պարզեցնելը հետաքրքիր չէ, ուստի եկեք գործարկենք ևս երկու հրաման: Չնայած սա անիմաստ է, ես ձեզ զգուշացրել եմ =)
Այսպիսով, եկեք ստեղծենք vim ECS-CommunityEdition/deploy.xml և կատարենք օպտիմալ նվազագույն փոփոխություններ, որպեսզի ECS-ն գործարկվի և աշխատի: Պարամետրերի ցանկը կարելի է կրճատել, բայց ես դա արեցի այսպես.
- Licensed_accepted. true Դուք պետք չէ փոխել այն, այնուհետև տեղակայելիս ձեզանից բացահայտորեն կխնդրեն ընդունել այն և կցուցադրվի գեղեցիկ արտահայտություն: Թերևս սա նույնիսկ Զատկի ձու է:
- Ապամեկնաբանեք տողերի ինքնանունները. և մաքսային. Մուտքագրեք հանգույցի առնվազն մեկ ցանկալի անուն. տեղադրման գործընթացում հոսթի անունը կփոխարինվի դրանով:
- install_node՝ 192.168.1.1 Նշեք հանգույցի իրական IP-ն: Մեր դեպքում մենք նշում ենք նույնը, ինչ nmtui-ում
- dns_domain. մուտքագրեք ձեր տիրույթը:
- dns_servers. մուտքագրեք ձեր dns-ը:
- ntp_servers: Դուք կարող եք նշել ցանկացած մեկը: Առաջինը, որին հանդիպեցի, վերցրի լողավազանից 0.pool.ntp.org (դարձավ 91.216.168.42)
- ինքնորոշում. սովորույթ Եթե չհրապարակեք մեկնաբանությունները, ապա լուսինը կկոչվի Լունա:
- ecs_block_devices:
/ dev / sdb
Ինչ-ինչ անհայտ պատճառով, կարող է գոյություն չունենալ բլոկների պահպանման սարք /dev/vda - storage_pools:
անդամներ
192.168.1.1 Այստեղ կրկին նշում ենք հանգույցի իրական IP-ն - ecs_block_devices:
/dev/sdb Մենք կրկնում ենք գոյություն չունեցող սարքերը կտրելու գործողությունը:
Ընդհանուր առմամբ, ամբողջ ֆայլը նկարագրված է շատ մանրամասն , բայց ո՞վ կկարդա այն այդքան անհանգիստ ժամանակ։ Այն նաև ասում է, որ նվազագույնը բավարար է IP-ն և դիմակը նշելու համար, բայց իմ լաբորատորիայում նման հավաքածուն բավականին վատ գործարկվեց, և ես ստիպված էի այն ընդլայնել վերևում նշվածին:
Խմբագրիչից դուրս գալուց հետո դուք պետք է գործարկեք update_deploy /home/admin/ECS-CommunityEdition/deploy.yml, և եթե ամեն ինչ ճիշտ է արված, դրա մասին հստակ կհաղորդվի:
Այնուհետև դուք դեռ պետք է գործարկեք videoploy-ը, սպասեք, որ միջավայրը թարմացվի, և դուք կարող եք սկսել ինքնին տեղադրումը ova-step1 հրամանով, իսկ դրա հաջող ավարտից հետո՝ ova-step2 հրամանով։ Կարևոր է. մի դադարեցրեք սցենարները ձեռքով: Որոշ քայլեր կարող են զգալի ժամանակ պահանջել, չավարտվեն առաջին իսկ փորձից և կարող են թվալ, թե ամեն ինչ կոտրված է: Ամեն դեպքում, դուք պետք է սպասեք, որ սցենարը բնականաբար ավարտվի: Վերջում դուք պետք է տեսնեք նման հաղորդագրություն:
Այժմ մենք վերջապես կարող ենք բացել WebUI կառավարման վահանակը՝ օգտագործելով մեզ հայտնի IP-ն: Եթե կոնֆիգուրացիան չի փոխվել փուլում, ապա կանխադրված հաշիվը կլինի root/ChangeMe: Դուք նույնիսկ կարող եք անմիջապես օգտագործել մեր S3-ի հետ համատեղելի պահեստը: Այն հասանելի է 9020 նավահանգիստներում՝ HTTP-ի համար, և 9021՝ HTTPS-ի համար: Կրկին, եթե ոչինչ չի փոխվել, ապա access_key՝ object_admin1 և secret_key՝ ChangeMeChangeMeChangeMeChangeMeChangeMe:
Բայց եկեք շատ առաջ չընկնենք և սկսենք կարգով:
Երբ առաջին անգամ մուտք գործեք, դուք ստիպված կլինեք փոխել ձեր գաղտնաբառը համարժեքի, ինչը բացարձակապես ճիշտ է: Հիմնական վահանակը չափազանց պարզ է, ուստի եկեք ավելի հետաքրքիր բան անենք, քան պարզ չափորոշիչները բացատրելը: Օրինակ, եկեք ստեղծենք օգտվող, որը մենք կօգտագործենք պահեստ մուտք գործելու համար: Ծառայություններ մատուցողների աշխարհում սրանք կոչվում են վարձակալներ: Սա արվում է Կառավարում > Օգտագործողներ > Նոր օբյեկտ օգտագործող
Օգտատեր ստեղծելիս մեզ խնդրում են նշել անվանատարածք: Տեխնիկապես ոչինչ չի խանգարում մեզ ստեղծել դրանցից այնքան, որքան օգտատերեր կան: Եվ հակառակը։ Սա թույլ է տալիս ինքնուրույն կառավարել ռեսուրսները յուրաքանչյուր վարձակալի համար:
Համապատասխանաբար, մենք ընտրում ենք մեզ անհրաժեշտ գործառույթները և ստեղծում օգտվողի բանալիներ: S3/Atmos-ը կբավականացնի ինձ։ Եվ մի մոռացեք պահպանել բանալին 😉
Օգտագործողը ստեղծվել է, այժմ ժամանակն է նրան դույլ հատկացնել: Գնացեք Կառավարում > Դույլ և լրացրեք պահանջվող դաշտերը: Այստեղ ամեն ինչ պարզ է.
Այժմ մենք ամեն ինչ պատրաստ ենք մեր S3 պահեստի բավականին մարտական օգտագործման համար:
Veeam-ի կարգավորում
Այսպիսով, ինչպես հիշում ենք, օբյեկտների պահպանման հիմնական կիրառություններից մեկը տեղեկատվության երկարաժամկետ պահպանումն է, որը հազվադեպ է հասանելի: Իդեալական օրինակ է հեռավոր կայքում պահուստային պատճենները պահելու անհրաժեշտությունը: Veeam Backup & Replication-ում այս հատկությունը կոչվում է Capacity Tier:
Եկեք սկսենք կարգավորումը՝ ավելացնելով մեր Dell ECS CE-ը Veeam ինտերֆեյսին: Կրկնօրինակման ենթակառուցվածքի ներդիրում գործարկեք «Ավելացնել նոր պահեստ» մոգը և ընտրեք «Օբյեկտների պահեստավորում»:
Եկեք ընտրենք, թե ինչի համար է ամեն ինչ սկսվել՝ S3 Compatible:
Բացվող պատուհանում գրեք ցանկալի անունը և անցեք Հաշվի քայլին: Այստեղ դուք պետք է նշեք ծառայության կետը ձևաթղթում , տարածաշրջանը կարելի է թողնել այնպես, ինչպես կա, և ստեղծված օգտատերը կարող է ավելացվել։ Դարպասի սերվերն անհրաժեշտ է, եթե ձեր պահեստը գտնվում է հեռավոր կայքում, բայց սա արդեն ենթակառուցվածքի օպտիմալացման թեմա է և առանձին հոդված, այնպես որ կարող եք ապահով բաց թողնել այստեղ:
Եթե ամեն ինչ ճիշտ է նշված և կազմաձևված, վկայագրի մասին նախազգուշացում կհայտնվի, այնուհետև դույլով պատուհան, որտեղ կարող եք թղթապանակ ստեղծել մեր ֆայլերի համար:
Մենք անցնում ենք կախարդի միջով մինչև վերջ և վայելում ենք արդյունքը:
Հաջորդ քայլը կա՛մ ստեղծել նոր Scale-out Backup Repository, կա՛մ ավելացնել մեր S3-ը գոյություն ունեցողին. այն կօգտագործվի որպես Capacity Tier արխիվային պահպանման համար: Ընթացիկ թողարկումում S3-ի հետ համատեղելի պահեստն ուղղակիորեն օգտագործելու գործառույթ չկա, ինչպես սովորական պահոցը: Որպեսզի դա տեղի ունենա, պետք է լուծել չափազանց շատ ոչ ակնհայտ խնդիրներ, բայց ամեն ինչ հնարավոր է։
Գնացեք պահեստի կարգավորումներ և միացրեք Capacity Tier-ը: Այնտեղ ամեն ինչ թափանցիկ է, բայց կա մի հետաքրքիր նրբերանգ. եթե ցանկանում եք, որ բոլոր տվյալները հնարավորինս շուտ ուղարկվեն օբյեկտների պահպանմանը, պարզապես դրեք այն 0 օր:
Հրաշագործի միջով անցնելուց հետո, եթե չես ուզում սպասել, կարող ես սեղմել ctrl+RMB պահեստի վրա, ստիպել Tiering աշխատանքը գործարկել և դիտել գրաֆիկների սողունը:
Առայժմ այսքանը: Կարծում եմ, ինձ հաջողվեց ցույց տալ, որ բլոկի պահեստավորումն այնքան էլ սարսափելի չէ, որքան մարդիկ կարծում են: Այո, կան վագոնի և փոքր սայլի լուծումներ և տարբերակներ, բայց դուք չեք կարող ամեն ինչ ծածկել մեկ հոդվածում: Այսպիսով, եկեք կիսվենք մեր փորձով մեկնաբանություններում:
Source: www.habr.com