前に 輸入代替命令の実施の一環として、既存のシステムを何に置き換えることができるかについてのオプションが検討されました。 次の記事では、現在導入されている製品を置き換える特定の製品の選択に焦点を当てます。 出発点である仮想化システムから始めましょう。
1. 選択の苦しみ
それで、何を選ぶことができますか？ で :
- サーバー仮想化システム」R-仮想化» (libvirt、KVM、QEMU)
- ソフトウェアパッケージ "Brest 仮想化ツール» (libvirt、KVM、QEMU)
- 仮想化環境を管理および監視するためのプラットフォーム 「シャークスストリーム」 (95% のケースで政府機関には適さないクラウド ソリューション (機密性など)
- サーバー、デスクトップ、アプリケーションを仮想化するためのソフトウェア パッケージホスト" (KVM x86)
- 仮想化環境を安全に管理するためのシステム」Z|virt「(別名 oVirt+KVM)」
- 仮想化環境管理システム」ROSA仮想化「(別名 oVirt+KVM)」
- ハイパーバイザー QP VMM (Oracle Virtual Box に似すぎて他のものとは言えません)
OS ディストリビューションに含まれているハイパーバイザー、またはそのリポジトリにあるハイパーバイザーを考慮することもできます。 たとえば、Astra Linux は KVM をサポートしています。 また、OS リポジトリに含まれているため、インストールおよび使用が「正規」であると見なされます。 「輸入代替の一部として使用できるものと使用できないもの」については、前回説明しました。 なので、この問題については触れません。
実はここで :
- VirtualBox
- 仮想マネージャ (KVM) イーグル電流
- libvirt KVM経由
ROSA Linux にはそのようなリストはありませんが、Wiki で見つけることができます。 :
- ROSA仮想化 KVM 経由 oVirt 経由
- QEMU KVM経由
- oVirt 3.5 KVM経由
計算にはこれがあります
Alt Linuxにも同じものがあります
1.2. XNUMXつありますが、
詳しく調べたところ、次のようないくつかのよく知られたハイパーバイザーのみを扱う必要があるという結論に達しました。
QEMU は、さまざまなプラットフォームのハードウェアをエミュレートするための無料のオープン ソース プログラムであり、KVM を使用しなくても動作しますが、ハードウェア仮想化を使用するとゲスト システムのパフォーマンスが大幅に向上するため、QEMU で KVM (-enable-kvm) を使用することをお勧めします。 (c) つまり、QEMU はタイプ 2 のハイパーバイザーであり、製品環境では受け入れられません。 KVMでも使えますが、この場合はKVM管理ツールとしてQEMUを使うことになります…。
オリジナルを使用する VirtualBox 商業においては実際には : 「4 年 2010 月にリリースされたバージョン 2 以降、製品の主要部分は GPL v2.0 ライセンスに基づいて無料で配布されます。 その上にインストールされる追加パッケージは、USB 3.0 および 2 デバイス、リモート デスクトップ プロトコル (RDP)、ドライブ暗号化、NVMe および PXE からのブートのサポートを提供し、特別な PUEL ライセンス (「個人使用および評価用」) の下で配布されます。このシステムは、個人使用、トレーニング目的、または製品版の購入を決定する前の評価のために無料で使用できます。」 (c) さらに、VirtualBox もタイプ XNUMX ハイパーバイザーであるため、これも消えます。
合計： 純粋な形で私たちが持っているのは KVM.
2. 残り: KVM それとも KVM?
それでも「国内」ハイパーバイザーに切り替える必要がある場合、率直に言って、選択肢は狭いです。 そうなる KVM 特定の変更を加えたラッパーまたは別のラッパーでも、KVM のままです。 これが良いか悪いかは別問題ですが、他に選択肢はまだありません。
条件がそれほど厳しくない場合は、前回説明したように、 : 「指標を確立された限界値に近づける必要があります。 実際、これは、既存の OS を電気通信・マスコミュニケーション省レジストリの製品に置き換え、置き換えられるオペレーティング システムの数を 80% に増やす必要があることを意味します。そのため、クラスターを Hyper-V 上に安全に残すことができます。 、私たちはそれを持っていて、それが気に入っているので...」(c) したがって、私たちは選択に直面しています。 Microsoft Hyper-v または KVM. KVM おそらくコントロールが「ねじ込まれている」かもしれませんが、それでも同じままです KVM.
これらの製品は比較には程遠い しない しない …まあ、わかります…
導入と構成について KVM 同じように書かれていませんでした しない しない と ... 一言で、 .
同じことが当てはまります
繰り返し説明したり、これらのシステムを説明したり、比較したりすることには意味がありません。 もちろん、記事から重要なポイントを引き出すことはできますが、それは著者に対して失礼になると思います。 選択する人は、これだけでなく、決断を下すために山ほどの情報も読むことになります。
私が注目したい唯一の違いは、フェールオーバー クラスタリングです。 Microsoft がこれを OS およびハイパーバイザー機能に組み込んでいる場合、KVM の場合は、OS リポジトリに含まれているサードパーティ ソフトウェアを使用する必要があります。 たとえば、Corosync + Pacemaker の同じ組み合わせ。 （国内のほぼすべてのOSがこの組み合わせになっています…もしかしたら全部かも知れませんが、100％確認したわけではありません。） クラスタリングの設定マニュアルも豊富に用意されています。
3.まとめ
さて、いつものように、私たちのクリビンたちは気にせず、持っているものを取り入れ、独自のものを少し追加して、文書によれば国産ですが、実際にはオープンソースである「製品」を作成しました。 「別の」仮想化システム (つまり、OS には含まれていない) に予算からお金を費やすのは理にかなっていますか? 考えないでください。 同じ KVM を引き続き受け取るため、料金を支払うだけで済みます。
したがって、ハイパーバイザーの代替品を選択することは、エンタープライズ用にどのサーバー OS を購入して運用するかによって決まります。 または、私の場合のように、すでに持っているもの (Hyper-VESXi insert_needed) をそのまま使用します。
出所： habr.com