oVirt 2 ժամում. Մաս 1. Բաց սխալ հանդուրժող վիրտուալացման հարթակ

Ներածություն

բաց կոդով նախագիծ o Վիրտուալ ձեռնարկության մակարդակի վիրտուալացման անվճար հարթակ է: Շրջելով habr-ի միջով՝ ես դա գտա o Վիրտուալ չի լուսաբանվում այնքան լայնորեն, որքան արժանի է:
oVirt-ը իրականում վերին հոսանքն է Red Hat Virtualization (RHV, նախկինում RHEV) համակարգի համար, որն աճում է Red Hat-ի թևի տակ: Շփոթմունքից խուսափելու համար սա ոչ նույնը, ինչ CentOS vs RHEL, մոդելը ավելի մոտ է Fedora vs RHEL:
Կափարիչի տակ - KVM, կառավարման համար օգտագործվում է վեբ ինտերֆեյսը։ Հիմնված է RHEL/CentOS 7 OS-ի վրա:
oVirt-ը կարող է օգտագործվել ինչպես «ավանդական» սերվերի, այնպես էլ աշխատասեղանի վիրտուալացման (VDI) համար, ի տարբերություն VMware լուծման, երկու համակարգերը կարող են գոյակցել մեկ համալիրում:
Լավ նախագիծ փաստագրված, վաղուց հասունացել է արդյունավետ օգտագործման համար և պատրաստ է բարձր բեռների։
Այս հոդվածն առաջինն է շարքից, թե ինչպես կարելի է ստեղծել աշխատանքային ձախողման կլաստեր: Դրանց միջով անցնելուց հետո կարճ ժամանակում (մոտ 2 ժամ) մենք կստանանք լիարժեք գործող համակարգ, չնայած մի շարք հարցեր, իհարկե, հնարավոր չէ բացահայտել, կփորձեմ անդրադառնալ դրանց հաջորդ հոդվածներում։
Մենք այն օգտագործում ենք արդեն մի քանի տարի, սկսել ենք 4.1 տարբերակից։ Մեր արդյունաբերական համակարգն այժմ աշխատում է 480-րդ սերնդի HPE Synergy 460-ի և ProLiant BL10c-ի վրա Xeon Gold պրոցեսորներով:
Գրելու պահին ներկայիս տարբերակը 4.3 է:

Հոդվածներ

1. Ներածություն (Մենք այստեղ ենք)
2. Մենեջերի (ovirt-շարժիչ) և հիպերվիզորների (հոսթների) տեղադրում
3. Ընդլայնված կարգավորումներ

Ֆունկցիոնալ հատկանիշներ

oVirt-ում կա 2 հիմնական միավոր՝ ovirt-engine և ovirt-host(ներ): Նրանց համար, ովքեր ծանոթ են VMware արտադրանքներին, oVirt-ն ամբողջությամբ որպես հարթակ vSphere-ն է, ovirt-engine-ը` կառավարման շերտը, կատարում է նույն գործառույթները, ինչ vCenter-ը, իսկ ovirt-host-ը հիպերվիզոր է, ինչպես ESX (i): Որովհետեւ vSphere-ը շատ տարածված լուծում է, երբեմն ես այն կհամեմատեմ դրա հետ։

Բրինձ. 1 - oVirt կառավարման վահանակ:

Linux-ի բաշխումների և Windows տարբերակների մեծ մասը աջակցվում են որպես հյուր մեքենաներ: Հյուր մեքենաների համար կան գործակալներ և օպտիմիզացված վիրտուալ սարքեր և virtio դրայվերներ, հիմնականում սկավառակի վերահսկիչ և ցանցային ինտերֆեյս:
Սխալ հանդուրժող լուծում և բոլոր հետաքրքիր առանձնահատկությունները կիրառելու համար ձեզ անհրաժեշտ կլինի ընդհանուր պահեստավորում: Աջակցվում են և՛ բլոկի FC, FCoE, iSCSI, և՛ ֆայլերի NFS պահեստները և այլն: Խափանման հանդուրժող լուծում իրականացնելու համար պահեստավորման համակարգը պետք է լինի նաև սխալ հանդուրժող (առնվազն 2 կարգավորիչ, բազմանցում):
Տեղական պահեստների օգտագործումը հնարավոր է, բայց լռելյայնորեն միայն ընդհանուր պահեստները հարմար են իրական կլաստերի համար: Տեղական պահեստները համակարգը դարձնում են հիպերվիզորների անհամաչափ հավաքածու, և նույնիսկ ընդհանուր պահեստավորման դեպքում կլաստերը չի կարող հավաքվել: Ամենաճիշտ ճանապարհը առանց սկավառակի մեքենաներն են, որոնք բեռնված են SAN-ից կամ նվազագույն չափի սկավառակներ: Հավանաբար, vdsm hook-ի միջոցով կարելի է Software Defined Storage-ի լոկալ սկավառակներից (օրինակ՝ Ceph) կառուցել ու ներկայացնել իր VM-ը, բայց ես դա լուրջ չեմ մտածել։

ճարտարապետություն

Բրինձ. 2 - oVirt ճարտարապետություն.
Ճարտարապետության մասին լրացուցիչ տեղեկություններ կարելի է գտնել այստեղ փաստաթղթավորում մշակող.

Բրինձ. 3 - oVirt օբյեկտներ.

Հիերարխիայի վերին տարրը − data Center. Այն որոշում է, թե արդյոք օգտագործվում է ընդհանուր կամ տեղային հիշողություն, ինչպես նաև օգտագործվող գործառույթների հավաքածուն (համատեղելիություն, 4.1-ից 4.3): Կարող է լինել մեկ կամ ավելի: Շատ տարբերակների համար կանխադրված տվյալների կենտրոնի օգտագործումը կանխադրված է:
Տվյալների կենտրոնը բաղկացած է մեկից կամ մի քանիսից Կլաստերներ. Կլաստերը որոշում է պրոցեսորի տեսակը, միգրացիոն քաղաքականությունը և այլն: Փոքր տեղադրումների դեպքում դուք կարող եք նաև սահմանափակվել ձեր Default կլաստերով:
Կլաստերն իր հերթին բաղկացած է HostՆրանք, ովքեր կատարում են հիմնական աշխատանքը՝ կրում են վիրտուալ մեքենաներ, դրանց հետ միացված են պահեստներ։ Կլաստերը ենթադրում է 2 կամ ավելի հյուրընկալողներ: Թեև տեխնիկապես հնարավոր է կլաստեր պատրաստել 1 հոսթինգով, սա գործնական կիրառություն չունի։

oVirt-ն աջակցում է բազմաթիվ հնարավորությունների, ներառյալ. Վիրտուալ մեքենաների ուղիղ միգրացիա հիպերվիզորների միջև (կենդանի միգրացիա) և պահեստների միջև (պահեստի միգրացիա), աշխատասեղանի վիրտուալացում (վիրտուալ աշխատասեղանի ենթակառուցվածք) VM լողավազաններով, պետական ​​և քաղաքացիություն չունեցող VM-ներ, աջակցություն NVidia Grid vGPU, ներմուծում vSphere-ից, KVM, կա հզոր API և շատ ավելին: Այս բոլոր հնարավորությունները հասանելի են առանց հոնորարների, և անհրաժեշտության դեպքում աջակցություն կարելի է ձեռք բերել Red Hat-ից՝ տարածաշրջանային գործընկերների միջոցով:

RHV գների մասին

Արժեքը բարձր չէ VMware-ի համեմատ, միայն աջակցություն է ձեռք բերվում՝ առանց լիցենզիան գնելու պահանջի: Աջակցությունը գնվում է միայն հիպերվիզորների համար, ovirt-engine-ը, ի տարբերություն vCenter Server-ի, ծախսեր չի պահանջում։

Հաշվարկի օրինակ սեփականության 1-ին տարվա համար

Դիտարկենք 4 2 վարդակից մեքենաների կլաստեր և մանրածախ գներ (նախագծային զեղչեր չկան):
RHV ստանդարտ բաժանորդագրություն արժե 999 դոլար մեկ վարդակից/տարեկան (պրեմիում 365/24/7 - $1499), ընդհանուր 4*2*$999=$7992.
vSphere գինը:

• VMware vCenter Server Standard $10,837.13 մեկ օրինակի համար գումարած Basic բաժանորդագրությունը $2,625.41 (Արտադրական $3,125.39);
• VMware vSphere Standard $1,164.15 + Հիմնական բաժանորդագրություն $552.61 (Արտադրական $653.82);
• VMware vSphere Enterprise Plus $6,309.23 + Հիմնական բաժանորդագրություն $1,261.09 (Արտադրական $1,499.94):

Ընդհանուր՝ 10 + 837,13 + 2 * 625,41 * (4 + 2) = $ 27 196,62 ամենափոքր տարբերակի համար. Տարբերությունը մոտ 3,5 անգամ է։
oVirt-ում բոլոր գործառույթները հասանելի են առանց սահմանափակումների:

Համառոտ բնութագրեր և առավելագույններ

Համակարգի պահանջները

Հիպերվիզորը պահանջում է պրոցեսոր, որը միացված է ապարատային վիրտուալացմանը, մեկնարկելու համար RAM-ի նվազագույն քանակը 2 ԳԲ է, ՕՀ-ի համար առաջարկվող պահեստը 55 ԳԲ է (հիմնականում տեղեկամատյանների համար և այլն, ՕՀ-ն ինքնին քիչ է պահանջում):
Լրացուցիչ մանրամասներ - այստեղ.
Համար Շարժիչ նվազագույն պահանջներ 2 միջուկ/4 ԳԲ RAM/25 ԳԲ պահեստ: Առաջարկվում է - 4 միջուկից / 16 ԳԲ RAM / 50 ԳԲ պահեստից:
Ինչպես ցանկացած համակարգում, կան ծավալների և քանակների սահմանափակումներ, որոնց մեծ մասը գերազանցում է հասանելի զանգվածային առևտրային սերվերների հնարավորությունները: Այո, զույգ: Intel Xeon Gold 6230- ը կարող է հասցեագրել 2 TiB RAM և տալիս է 40 միջուկ (80 thread), ինչը նույնիսկ ավելի քիչ է մեկ VM-ի սահմաններից:

Վիրտուալ մեքենայի առավելագույն քանակը.

• Միաժամանակ աշխատող վիրտուալ մեքենաների առավելագույն քանակը՝ անսահմանափակ;
• Առավելագույն վիրտուալ պրոցեսորներ մեկ վիրտուալ մեքենայի համար՝ 384;
• Առավելագույն հիշողություն մեկ վիրտուալ մեքենայի համար՝ 4 TiB;
• Մեկ սկավառակի առավելագույն չափը մեկ վիրտուալ մեքենայի համար՝ 8 TiB:

Հյուրընկալողի առավելագույն քանակը.

• Տրամաբանական պրոցեսորի միջուկներ կամ թելեր՝ 768;
• RAM՝ 12 TiB
• Հոսթավորված վիրտուալ մեքենաների քանակը՝ 250;
• Միաժամանակյա կենդանի միգրացիաներ՝ 2 մուտքային, 2 ելքային;
• Կենդանի միգրացիայի թողունակություն. լռելյայն մինչև 52 ՄԲ (~436 Մբ) մեկ միգրացիայի համար, երբ օգտագործվում է ժառանգական միգրացիոն քաղաքականությունը: Այլ քաղաքականություններ օգտագործում են հարմարվողական թողունակության արժեքներ՝ հիմնված ֆիզիկական սարքի արագության վրա: QoS քաղաքականությունը կարող է սահմանափակել միգրացիայի թողունակությունը:

Մենեջերի տրամաբանական սուբյեկտի առավելագույն չափերը.

4.3-ում կան հետևյալ սահմանները.

• Data Center
  • Տվյալների կենտրոնի առավելագույն քանակը՝ 400;
  • Հյուրընկալողների առավելագույն քանակը՝ 400 աջակցվող, 500 փորձարկված;
  • VM-ի առավելագույն քանակը՝ 4000 աջակցվող, 5000 փորձարկված;
• Բույլ
  • Կլաստերների առավելագույն քանակը՝ 400;
  • Հյուրընկալողների առավելագույն քանակը՝ 400 աջակցվող, 500 փորձարկված;
  • VM-ի առավելագույն քանակը՝ 4000 աջակցվող, 5000 փորձարկված;
• Ցանց
  • Տրամաբանական ցանցեր/կլաստեր՝ 300
  • SDN/արտաքին ցանցեր՝ 2600 փորձարկված, առանց պարտադրված սահմանափակումների;
• Պահեստ
  • Առավելագույն տիրույթներ՝ 50 աջակցվող, 70 փորձարկված;
  • Հոսթներ մեկ տիրույթի համար. սահմանափակում չկա;
  • Տրամաբանական ծավալներ մեկ բլոկային տիրույթի համար (ավելի շատ)՝ 1500;
  • LUN-ների առավելագույն քանակը (ավելին)՝ 300;
  • Սկավառակի առավելագույն չափը՝ 500 TiB (լռելյայն սահմանափակված է մինչև 8 TiB):

Իրականացման տարբերակներ

Ինչպես արդեն նշվեց, oVirt-ը կառուցված է 2 հիմնական տարրերից՝ ovirt-engine (կառավարում) և ovirt-host (hypervisor):
Շարժիչը կարող է տեղակայվել ինչպես պլատֆորմից դուրս (ինքնուրույն կառավարիչ. դա կարող է լինել մեկ այլ հարթակում աշխատող վիրտուալ մեքենա կամ առանձին հիպերվիզոր, և նույնիսկ ֆիզիկական մեքենա), այնպես էլ հենց հարթակում (ինքնակառավարվող շարժիչ, որը նման է VMware-ի VCSA-ին: մոտեցում):
Հիպերվիզորը կարող է տեղադրվել սովորական OS RHEL/CentOS 7 (EL Host) և մասնագիտացված նվազագույն ՕՀ (oVirt-Node, հիմնված el7-ի վրա):
Բոլոր տարբերակների ապարատային պահանջները մոտավորապես նույնն են:

Բրինձ. 4 - ստանդարտ ճարտարապետություն.

Բրինձ. 5 - Ինքնահոսթինգ Շարժիչի ճարտարապետություն:

Ինքս ինձ համար ընտրեցի ինքնուրույն Manager և EL Hosts տարբերակը.

• Անկախ մենեջերը մի փոքր ավելի հեշտ է գործարկման հետ կապված խնդիրներով, չկա հավի և ձվի երկընտրանք (ինչ վերաբերում է VCSA-ին, դուք չեք սկսի մինչև գոնե մեկ հյուրընկալողն ամբողջությամբ չաշխատի), բայց կա կախվածություն մեկ այլ համակարգից *;
• EL Host-ն ապահովում է ՕՀ-ի ամբողջ հզորությունը, որն օգտակար է արտաքին մոնիտորինգի, վրիպազերծման, անսարքությունների վերացման և այլնի համար:

* Այնուամենայնիվ, դա չի պահանջվել շահագործման ողջ ժամանակահատվածում, նույնիսկ հոսանքի լուրջ խափանումից հետո:
Բայց ավելին է կետի!
Փորձարկման համար հնարավոր է թողարկել ProLiant BL460c G7 զույգ սայրեր Xeon® պրոցեսորով: Մենք կվերարտադրենք դրանց վրա տեղադրման գործընթացը:
Անվանենք ovirt.lab.example.com, kvm01.lab.example.com և kvm02.lab.example.com հանգույցները։
Եկեք անմիջապես գնանք տեղադրում.

Source: www.habr.com