Ներմուծման փոխարինումը գործնականում. Մաս 2. Սկիզբ. Հիպերվիզոր

Նախորդում Հոդված Դիտարկվել են տարբերակներ, թե ինչով կարող են փոխարինվել գոյություն ունեցող համակարգերը ներմուծման փոխարինման կարգի իրականացման շրջանակներում: Հետևյալ հոդվածները կկենտրոնանան կոնկրետ ապրանքների ընտրության վրա, որոնք փոխարինում են ներկայումս տեղակայվածներին: Սկսենք ելակետից՝ վիրտուալացման համակարգից:

1. Ընտրության տանջանք

Այսպիսով, ինչից կարող եք ընտրել: IN Հեռահաղորդակցության և զանգվածային հաղորդակցության նախարարության ռեգիստր կա ընտրություն:

• Սերվերի վիրտուալացման համակարգ»R-վիրտուալացում» (libvirt, KVM, QEMU)
• Ծրագրային փաթեթ»Brest վիրտուալացման գործիքներ» (libvirt, KVM, QEMU)
• Վիրտուալացման միջավայրի կառավարման և մոնիտորինգի հարթակ «Շարքս հոսք» (ամպային լուծում, որը 95% դեպքերում հարմար չէ պետական ​​գրասենյակների համար (գաղտնիություն և այլն)
• Ծրագրային փաթեթ սերվերների, աշխատասեղանների և հավելվածների վիրտուալացման համար»Հյուրընկալող(KVM x86)
• Վիրտուալացման միջավայրի անվտանգ կառավարման համակարգ»Զ|վիրտ«(aka oVirt+KVM)
• Վիրտուալիզացիայի միջավայրի կառավարման համակարգ»ROSA վիրտուալացում«(aka oVirt+KVM)
• Հիպերվիզոր QP VMM (չափազանց նման է Oracle Virtual Box-ին, որպեսզի որևէ այլ բան լինի)

Կարող եք նաև հաշվի առնել OS-ի բաշխման մեջ ներառված կամ դրանց պահեստներում գտնվող հիպերվիզորները: Օրինակ, Astra Linux-ն ունի KVM աջակցություն: Եվ քանի որ այն ներառված է ՕՀ-ի պահոցներում, այն կարելի է «լեգիտիմ» համարել տեղադրման և օգտագործման համար: «Ի՞նչը կարող է օգտագործվել որպես ներմուծման փոխարինման մաս, և ինչը չի կարելի» քննարկվել է նախորդ հոդվածում Հոդված, ուստի ես չեմ անդրադառնա այս խնդրին:

Փաստորեն, այստեղ Astra Linux վիրտուալացման գործիքների ցանկ:

• VirtualBox- ը
• Virt-մենեջեր (KVM) Արծվի հոսանք
• գրադարան KVM-ի վրա

ROSA Linux-ը նման ցուցակ չունի, բայց այն կարող եք գտնել վիքիում հետևյալ փաթեթները:

• ROSA վիրտուալացում oVirt-ի միջոցով KVM-ի միջոցով
• QEMU KVM-ի վրա
• oVirt 3.5 KVM-ի վրա

Հաշվելն ունի սա QEMU KVM-ի վրա

Alt Linux-ն ունի նույնը KVM

1.2. Կա մեկ ԲԱՅՑ

Ավելի մանրամասն ուսումնասիրելուց հետո մենք եզրակացնում ենք, որ մենք ստիպված կլինենք գործ ունենալ միայն մի քանի հայտնի հիպերվիզորների հետ, մասնավորապես.

1. KVM
2. VirtualBox- ը
3. QEMU

QEMU Սա անվճար և բաց կոդով ծրագիր է՝ տարբեր հարթակների ապարատների նմանակման համար, որը կարող է աշխատել առանց KVM-ի օգտագործման, սակայն ապարատային վիրտուալիզացիայի օգտագործումը զգալիորեն արագացնում է հյուր համակարգերի աշխատանքը, ուստի KVM-ի օգտագործումը QEMU-ում (-enable-kvm) նախընտրելի տարբերակն է: (գ) Այսինքն, QEMU-ն 2-րդ տիպի հիպերվիզոր է, որն անընդունելի է արտադրանքի միջավայրում: KVM-ով այն կարող է օգտագործվել, բայց այս դեպքում QEMU-ն կօգտագործվի որպես KVM կառավարման գործիք...

Օգտագործելով բնօրինակը VirtualBox- ը առևտրի մեջ իրականում կա լիցենզիայի խախտում«Սկսած 4-րդ տարբերակից, որը թողարկվել է 2010 թվականի դեկտեմբերին, արտադրանքի հիմնական մասը անվճար բաշխվում է GPL v2 լիցենզիայի ներքո: Դրա վերևում տեղադրված լրացուցիչ փաթեթը, որն ապահովում է USB 2.0 և 3.0 սարքերի աջակցություն, Remote Desktop Protocol (RDP), սկավառակի կոդավորումը, բեռնումը NVMe-ից և PXE-ից, բաշխվում է հատուկ PUEL լիցենզիայի ներքո («անձնական օգտագործման և գնահատման համար»): , որի համաձայն համակարգը անվճար է անձնական օգտագործման, ուսուցման նպատակներով կամ գնահատման համար՝ նախքան կոմերցիոն տարբերակը գնելու որոշումը»։ (գ) Plus VirtualBox-ը նույնպես 2-րդ տիպի հիպերվիզոր է, ուստի այն նույնպես անհետանում է:

Ընդամենը: իր մաքուր տեսքով մենք ունենք միայն KVM.

2. Մնացածը՝ KVM, թե KVM.

Եթե ​​դուք դեռ պետք է անցնեք «տնային» հիպերվիզորին, ձեր ընտրությունը, անկեղծ ասած, փոքր է: Դա կլինի KVM այս կամ այն ​​փաթաթում, որոշակի փոփոխություններով, բայց դա դեռ կլինի KVM: Սա լավ է, թե վատ, այլ հարց է, դեռ այլընտրանք չկա:

Եթե ​​պայմաններն այնքան էլ խիստ չեն, ապա, ինչպես քննարկվել է նախորդում Հոդված«Մենք պետք է ցուցանիշները հասցնենք սահմանված սահմաններին։ Փաստորեն, սա նշանակում է, որ մենք պետք է փոխարինենք գործող ՕՀ-ն Հեռահաղորդակցության և Զանգվածային կապի նախարարության ռեգիստրի արտադրանքով և փոխարինված օպերացիոն համակարգերի թիվը հասցնենք 80%-ի... Այսպիսով, մենք կարող ենք ապահով կերպով թողնել կլաստերը Hyper-V-ում: , քանի որ մենք ունենք այն և մեզ դուր է գալիս այն...» (գ) Այսպիսով, մենք կանգնած ենք ընտրության առաջ. Microsoft Hyper-v կամ KVM. KVM միգուցե դրա վրա «պտուտակված» հսկիչները, բայց այն դեռ նույնը կմնա KVM.

Այս ապրանքները հեռու են համեմատելի լինելուց մեկ անգամՈչ երկու անգամՈչ երեք անգամ...Դե հասկանում ես...

Տեղակայման և կազմաձևման մասին KVM նույն կերպ չէր գրված մեկ անգամՈչ երկու անգամՈչ երեք անգամ իսկ չորս անգամ...Մի խոսքով. խամրեց.

Նույնը վերաբերում է Microsoft Hyper-V- ը..

Ես իմաստ չեմ տեսնում կրկնվելու և այս համակարգերը նկարագրելու, համեմատելու և այլն: Դուք, իհարկե, կարող եք հոդվածներից հանել հիմնական կետերը, բայց դա անհարգալից կլինի հեղինակների նկատմամբ, կարծում եմ: Ով պետք է ընտրի, կկարդա ոչ միայն սա, այլ նաև մի սար տեղեկատվություն, որպեսզի որոշում կայացնի։

Միակ տարբերությունը, որի վրա ես ուզում եմ կենտրոնանալ, failover clustering-ն է: Եթե ​​Microsoft-ը սա ներկառուցված է ՕՀ-ի և հիպերվիզորի ֆունկցիոնալության մեջ, ապա KVM-ի դեպքում դուք ստիպված կլինեք օգտագործել երրորդ կողմի ծրագրակազմ, որը պետք է ներառվի ՕՀ-ի պահոցներում: Corosync+Pacemaker-ի նույն համադրությունը, օրինակ. (Գրեթե բոլոր կենցաղային օպերացիոն համակարգերն ունեն այս համադրությունը... գուցե բոլորը, բայց ես չեմ ստուգել դրանց 100%-ը:) Կլաստերի տեղադրման ձեռնարկները նույնպես առատորեն հասանելի են:

3. Եզրակացություն

Դե, ինչպես միշտ, մեր Կուլիբինները չանհանգստացան, վերցրեցին այն, ինչ ունեին, մի փոքր ավելացրեցին իրենցը և արտադրեցին «ապրանք», որը, ըստ փաստաթղթերի, ներքին է, բայց իրականում OpenSource է: Արդյո՞ք իմաստ ունի բյուջեից գումար ծախսել «առանձին» վիրտուալացման համակարգերի վրա (կարդացեք՝ ներառված չէ ՕՀ-ում): Մի մտածիր. Քանի որ դուք դեռ կստանաք նույն KVM-ն, դուք միայն պետք է վճարեք դրա համար:

Այսպիսով, հիպերվիզորի համար փոխարինող ընտրելը կախված է նրանից, թե որ սերվերի ՕՀ-ն եք պատրաստվում գնել ձեռնարկության համար և աշխատել: Կամ, ինչպես իմ դեպքում, դուք կմնաք այն, ինչ արդեն ունեք (Hyper-VESXi insert_needed):

Source: www.habr.com