Edellisessä Vaihtoehtoja olemassa olevien järjestelmien korvaamiseksi harkittiin osana tuontikorvausmääräyksen täytäntöönpanoa. Myöhemmin artikkeleissa keskustelemme tiettyjen tuotteiden valinnasta, jotka korvaavat tällä hetkellä käytössä olevat tuotteet. Aloitetaan referenssipisteestä - virtualisointijärjestelmät.
1. Valinnan tuska
Joten mistä voit valita? SISÄÄN :
- Palvelimen virtualisointijärjestelmäR-virtualisointi» (libvirt, KVM, QEMU)
- Ohjelmistopaketti "Brestin virtualisointityökalut» (libvirt, KVM, QEMU)
- Virtualisointiympäristön hallinta- ja seurantaalusta "Sharx Stream" (pilviratkaisu, joka ei sovellu valtion virastoille 95 %:ssa tapauksista (salaisuus jne.)
- Ohjelmistopaketti palvelimien, työasemien ja sovellusten virtualisointiinHOST" (KVM x86)
- Suojattu virtualisointiympäristön hallintajärjestelmä «Z|virt» (alias oVirt+KVM)
- Virtualisointiympäristön hallintajärjestelmä «ROSA-virtualisointi» (alias oVirt+KVM)
- hypervisor QP VMM (liian samanlainen kuin Oracle Virtual Box ollakseen mitään muuta)
Voit myös ottaa huomioon käyttöjärjestelmän toimitukseen sisältyvät tai niiden arkistossa sijaitsevat hypervisorit. Esimerkiksi samassa Astra Linuxissa on KVM-tuki. Ja koska se sisältyy käyttöjärjestelmän arkistoihin, sitä voidaan pitää "laillisena" asennusta ja käyttöä varten. "Mitä voidaan käyttää osana tuontikorvaamista ja mitä ei" käsiteltiin edellisessä , joten en viivyttele tätä asiaa.
Itse asiassa täällä :
- VirtualBox
- Virt-johtaja (KVM) Eagle-virta
- Libvirt KVM:n kautta
ROSA Linuxilla ei ole tällaista luetteloa, mutta löydät sen wikistä :
- ROSA-virtualisointi oVirt yli KVM:n
- QEMU KVM:n kautta
- oVirt3.5 KVM:n kautta
Laske se
Alt Linuxilla on sama
1.2. On yksi MUTTA
Tarkemmin tarkasteltuna päättelemme, että meidän on käsiteltävä vain muutamia tunnettuja hypervisoreita, nimittäin:
QEMU on ilmainen ja avoimen lähdekoodin ohjelma eri alustojen laitteistojen emulointiin, jotka voivat toimia ilman KVM:ää, mutta laitteiston virtualisointi nopeuttaa huomattavasti vierasjärjestelmiä, joten KVM:n käyttö QEMU:ssa (-enable-kvm) on suositeltava vaihtoehto. (c) Eli QEMU on tyypin 2 hypervisor, jota ei voida hyväksyä tuotantoympäristössä. KVM:n kanssa sitä voidaan käyttää, mutta tässä tapauksessa QEMU:a käytetään KVM-hallintatyökaluna…
Käyttämällä alkuperäistä VirtualBox kaupassa itse asiassa on : "Versiosta 4 alkaen, joka julkaistiin joulukuussa 2010, suurin osa tuotteesta jaetaan ilmaiseksi GPL v2 -lisenssillä. Sen päälle asennettu lisäosapaketti, joka tukee USB 2.0- ja 3.0 -laitteita, Remote Desktop Protocol (RDP), asemasalausta, NVMe-käynnistystä ja PXE-käynnistystä, jaetaan erityisen PUEL:n ("Personal Use and Evaluation") alla. ) lisenssi, jolla järjestelmä on ilmainen henkilökohtaiseen käyttöön, koulutustarkoituksiin tai arviointiin ennen kaupallisen version ostopäätöstä." (c) Lisäksi VirtualBox on myös tyypin 2 hypervisori, joten se myös katoaa.
Yhteensä: meillä on vain puhtaassa muodossa KVM.
2. Loput: KVM vai KVM?
Siinä tapauksessa, että sinun on silti vaihdettava "kotimaiseen" hypervisoriin, sinulla on suoraan sanottuna vähän valinnanvaraa. Se tulee olemaan KVM yhdessä tai toisessa kääreessä, tietyin muutoksin, mutta silti se on KVM. Onko tämä hyvä vai huono asia, on toinen kysymys, vaihtoehtoa ei edelleenkään ole.
Jos ehdot eivät ole niin tiukat, niin, kuten edellisessä mainittiin : ”Meidän on saatava indikaattorit asetettuihin rajoihin. Itse asiassa tämä tarkoittaa, että meidän on korvattava olemassa olevat käyttöjärjestelmät Telecom- ja joukkoviestintäministeriön rekisterin tuotteilla ja saatava korvattujen käyttöjärjestelmien määrä 80 prosenttiin… Joten voimme turvallisesti jättää klusterin Hyper-V: hen, koska meillä on se jo ja pidämme siitä… "(c) Meillä on siis vaihtoehto: Microsoft Hyper-V tai KVM. KVM ehkä ohjaimet "kierrettynä" siihen, mutta se pysyy silti samana KVM.
Näitä tuotteita ei ole verrattu pitkälle Ei Ei … No, ymmärrät idean…
Tietoja käyttöönotosta ja määrityksestä KVM ei myöskään kirjoitettu Ei Ei eikä … Sanassa, .
Sama juttu aiheesta
En näe mitään syytä toistaa ja kuvata näitä järjestelmiä, vertailla jne. Voit tietysti poimia artikkeleista tärkeimpiä kohtia, mutta tämä on mielestäni epäkunnioittavaa tekijöitä kohtaan. Se, kenen on valittava, lukee tämän lisäksi myös valtavan määrän tietoa päättääkseen.
Ainoa ero, johon haluan keskittyä, on vikasietoklusterointi. Jos Microsoftilla on tämä sisäänrakennettu käyttöjärjestelmään ja hypervisorin toimintoihin, KVM:n tapauksessa sinun on käytettävä kolmannen osapuolen ohjelmistoja, jotka tulisi sisällyttää käyttöjärjestelmän arkistoihin. Sama Corosync + Pacemaker -paketti esimerkiksi. (Lähes kaikissa kotimaisissa käyttöjärjestelmissä on tämä paketti ... ehkä kaikilla on, mutta en tarkistanut kaikkia 100%.) Myös klusteroinnin määritysoppaita on runsaasti.
3. Päätelmä
No, kuten tavallista, meidän Kulibinit eivät vaivautuneet, he ottivat mitä heillä oli, ruuvasivat vähän omaa ja julkaisivat "tuotteen", joka asiakirjojen mukaan on kotimainen, mutta todellisuudessa se on OpenSource. Onko järkevää käyttää budjetista rahaa "erillisiin" virtualisointijärjestelmiin (lue, ei sisälly käyttöjärjestelmään)? Älä ajattele. Koska saat edelleen saman KVM:n, vain sinun on silti maksettava siitä.
Hypervisorin korvaajan valitseminen riippuu siis siitä, mitä palvelinkäyttöjärjestelmiä aiot ostaa Enterpriselle ja käyttää sitä. Tai, kuten minun tapauksessani, pysy siinä, mitä sinulla jo on (Hyper-VESXi fill in_required).
Lähde: will.com