W poprzednim rozważono opcje dotyczące tego, czym można by zastąpić istniejące systemy w ramach realizacji nakazu zastąpienia importu. Poniższe artykuły skupią się na wyborze konkretnych produktów, które zastąpią obecnie wdrożone. Zacznijmy od punktu wyjścia – systemu wirtualizacji.
1. Agonia wyboru
Zatem z czego możesz wybierać? W :
- System wirtualizacji serwerów”R-wirtualizacja» (libvirt, KVM, QEMU)
- Pakiet oprogramowania "Narzędzia do wirtualizacji Brest» (libvirt, KVM, QEMU)
- Platforma do zarządzania i monitorowania środowiska wirtualizacji „Strumień Sharxa” (rozwiązanie chmurowe, które w 95% przypadków nie nadaje się dla urzędów (tajemnica itp.)
- Pakiet oprogramowania do wirtualizacji serwerów, komputerów stacjonarnych i aplikacji”GOSPODARZ" (KVM x86)
- System bezpiecznego zarządzania środowiskiem wirtualizacyjnym”Z|virt"(alias oVirt+KVM)
- System zarządzania środowiskiem wirtualizacyjnym”Wirtualizacja ROSA"(alias oVirt+KVM)
- Hiperwizor QP VMM (zbyt podobny do Oracle Virtual Box, aby był czymkolwiek innym)
Można także wziąć pod uwagę hypervisory znajdujące się w dystrybucji systemu operacyjnego lub znajdujące się w ich repozytoriach. Na przykład Astra Linux obsługuje KVM. A ponieważ znajduje się w repozytoriach systemu operacyjnego, można go uznać za „legalny” do instalacji i używania. O tym, co można zastosować w ramach substytucji importu, a czego nie, pisaliśmy już w poprzednim artykule , więc nie będę się rozwodzić nad tym problemem.
Właściwie tutaj :
- VirtualBox
- Virt-menedżer (KVM) Prąd orła
- libvirt przez KVM
ROSA Linux nie ma takiej listy, ale można ją znaleźć na wiki :
- Wirtualizacja ROSA przez oVirt przez KVM
- QEMU przez KVM
- oVirt 3.5 przez KVM
Oblicz ma to
Alt Linux ma to samo
1.2. Jest jedno ALE
Po bliższym przyjrzeniu się dochodzimy do wniosku, że będziemy mieli do czynienia tylko z kilkoma dobrze znanymi hypervisorami, a mianowicie:
QEMU to darmowy program typu open source do emulacji sprzętu różnych platform, który może działać bez użycia KVM, ale zastosowanie wirtualizacji sprzętu znacznie przyspiesza wydajność systemów-gości, dlatego preferowaną opcją jest użycie KVM w QEMU (-enable-kvm). (c) Oznacza to, że QEMU jest hiperwizorem typu 2, co jest niedopuszczalne w środowisku produktu. Można go używać z KVM, ale w tym przypadku QEMU będzie używane jako narzędzie do zarządzania KVM...
Korzystanie z oryginału VirtualBox w handlu jest rzeczywiście : „Począwszy od wersji 4, wydanej w grudniu 2010, główna część produktu jest dystrybuowana bezpłatnie na licencji GPL v2. Zainstalowany na nim dodatkowy pakiet, zapewniający obsługę urządzeń USB 2.0 i 3.0, Remote Desktop Protocol (RDP), szyfrowanie dysków, bootowanie z NVMe i PXE, dystrybuowany jest na specjalnej licencji PUEL („do użytku osobistego i ewaluacji”) , w ramach którego system jest bezpłatny do użytku osobistego, do celów szkoleniowych lub do oceny przed podjęciem decyzji o zakupie wersji komercyjnej.” (c) Plus VirtualBox jest także hiperwizorem typu 2, więc również znika.
Razem: tylko w czystej postaci KVM.
2. Reszta: KVM czy KVM?
Jeśli nadal musisz przejść na „domowego” hypervisora, twój wybór, szczerze mówiąc, jest niewielki. To będzie KVM w tym czy innym opakowaniu, z pewnymi modyfikacjami, ale nadal będzie to KVM. Czy to dobrze, czy źle, to już inna kwestia; nadal nie ma alternatywy.
Jeśli warunki nie są tak rygorystyczne, to jak omówiono w poprzednim : „Musimy doprowadzić wskaźniki do ustalonych limitów. De facto oznacza to, że musimy wymienić istniejący system operacyjny na produkty z rejestru Ministerstwa Telekomunikacji i Komunikacji Masowej oraz zwiększyć liczbę wymienianych systemów operacyjnych do 80%.... Możemy więc bezpiecznie opuścić klaster na Hyper-V , skoro to mamy i lubimy...” (c) Stoimy więc przed wyborem: Microsoft Hyper-v lub KVM. KVM może z „przykręconym” do niego sterowaniem, ale nadal pozostanie takie samo KVM.
Produkty te nie są porównywalne Nie Nie ...No cóż, rozumiesz...
Informacje o wdrażaniu i konfiguracji KVM nie było napisane w ten sam sposób Nie Nie i nie ... Jednym słowem, .
To samo dotyczy
Nie widzę sensu się powtarzać i opisywać tych systemów, porównywać itp. Można oczywiście wyciągać kluczowe punkty z artykułów, ale moim zdaniem byłoby to brakiem szacunku dla autorów. Ktokolwiek będzie musiał dokonać wyboru, przeczyta nie tylko to, ale także całą masę informacji, dzięki którym podejmie decyzję.
Jedyną różnicą, na której chcę się skupić, jest klaster pracy awaryjnej. Jeśli Microsoft ma to wbudowane w system operacyjny i funkcjonalność hypervisora, w przypadku KVM będziesz musiał użyć oprogramowania innej firmy, które powinno znajdować się w repozytoriach systemu operacyjnego. Na przykład ta sama kombinacja Corosync+Pacemaker. (Prawie wszystkie krajowe systemy operacyjne mają tę kombinację... może wszystkie, ale nie sprawdziłem 100% z nich.) Podręczniki dotyczące konfigurowania klastrowania są również dostępne w obfitości.
3. Wniosek
No cóż, jak zwykle nasi Kulibini nie zawracali sobie głowy, wzięli, co mieli, dodali trochę od siebie i wyprodukowali „produkt”, który według dokumentów jest krajowy, ale w rzeczywistości jest to OpenSource. Czy ma sens wydawanie pieniędzy z budżetu na „oddzielne” systemy wirtualizacji (czytaj: nieuwzględnione w systemie operacyjnym)? Nie myśl. Ponieważ nadal będziesz otrzymywać ten sam KVM, będziesz musiał jedynie za niego zapłacić.
Zatem wybór zamiennika hypervisora sprowadza się do tego, jaki system operacyjny serwera zamierzasz kupić dla przedsiębiorstwa i z którego będziesz korzystać. Lub, jak w moim przypadku, pozostaniesz przy tym, co już masz (Hyper-VESXi Insert_needed).
Źródło: www.habr.com