ラボとは？
新たに取り扱うプロダクトのPoCを行ったり、さまざまな検証を行うための環境を「ラボ」と呼びます。
我々のようなSIerやプロダクト開発を行っている企業であれば、規模の大小はあれど必ず保有している設備です。
今回は、社内ラボのうちRHV（Red Hat Virtualization）を用いた検証環境をご紹介します。
RHVを用いた仮想化基盤
RHVはコミュニティベースで開発されているoVirtの商用版（ダウンストリーム）に位置づけられるプロダクトであり、ハイパーバイザにKVMを利用します。
VMware vSphereと比較されることも多く、コンピュートリソース（CPUやメモリ）とネットワーク、ストレージの集中管理と程よい抽象化が目玉の仮想化基盤と言えます。
残念ながら、Red Hat社はOpenShiftをRHVの後継として推すようになりoVirtの開発からも撤退してしまったため、oVirtコミュニティのアクティビティは低くなっています。
ハードウェアリソースを抽象化することの重要性
RHVを採用する以前のラボには10台程度のサーバが稼働しており、さらに休眠中のサーバも4〜5台ある状況でした。
それぞれのサーバに管理者がおり、VMを立てて検証を行いたいエンジニアはリソースに余裕のあるサーバを見つけて、管理者へ利用許可を乞う必要がありました。休眠中のサーバの中には 管理者不明のものもありました。
当然、管理者のポリシーによってサーバ構成は異なります。サーバAで動いていたVMをサーバBへマイグレーションしようとすると、サーバAに引き込んでいたネットワークがサーバBには引き込まれておらず、Linuxサーバを1つ動かしたいだけなのに、以下のような作業から着手する必要があることは日常茶飯事でした。
- ネットワークポートのアサインなど物理的なネットワーク設計
- ホスト環境の設定変更を行って良いのか関係者との調整
RHVによる改善
これらの問題はRHVによるハードウェアリソースの抽象化によって解決でき、RHVM（Red Hat Virtualization Manager）により抽象化されたリソースの管理や、稼働しているVMの集中管理も可能になりました。
RHV導入以前は、10台のサーバ上でどれくらいの規模のVMがいくつ動いているのか把握するために、それぞれのサーバへログインし、virsh listを実行して回る必要がありましたが、現在はRHVMのダッシュボードですべてを一目で確認できます。
現在の構成
- コンピュートノード：3台
- ストレージサーバ：1台
- 稼働VM：約80台
エンジニアはRHVM上でインスタンスの新規作成ボタンを押すだけで、空きリソースのあるサーバへVMを自動デプロイできます。また、任意のタイミングで任意のサーバへマイグレーションすることも容易になりました。
RHV上で稼働するVM間のネットワークはRHVMから簡単に接続できるため、ラボの機器へネットワークケーブルを挿すためだけに出社する必要もほぼなくなり、リモートワーク主体の当社にとっては 大きな副次効果となっています。
ハードウェア抽象化のデメリット
ハードウェアが抽象化されることで、以下のようなデメリットもあります。
- ハードウェアをパススルーでアタッチするプロダクトとの相性が悪い
- オーバーコミット運用によるハイパーバイザのオーバーヘッド
- 高負荷の検証には向かない
そのため、こういった検証を行う場合には専用の物理サーバを別途用意して実施しています。
RHVの利用例
RHV基盤へ過度な負荷をかけたり、大量のリソースを占有するといった迷惑行為をしない限り、利用制限は設けていません。
エンジニアに限らず、社員は誰でも自由に利用できます。
業務と直接関連がなくても、自分用の検証環境を構築して学習用途に使うことも可能です。
昨年（2024年11月）、当社は諸般の事情により、VDI＋シンクライアントによるリモートデスクトップ方式の業務環境を、VPN＋ファットクライアント端末によるリモートアクセス方式へ更改しました。
その結果、ラボ環境へVPN越しで接続して作業している最中に接続が切れ、作業内容が失われる事故が発生していました。
これに対し、RHV上へLinux/Windowsのデスクトップ環境をVDIとして配置し、リモートデスクトップ越しに作業することで、VPN復旧後すぐに作業の続きから再開できるようになりました。
RHVはKVMをハイパーバイザとして稼働していますが、ゲストOSとしてLinuxだけでなくWindowsも稼働可能です。
こういったOS自体の検証や、OS上で動作するアプリケーションの検証にも利用でき、物理的な検証機と比較して以下のようなメリットがあります。
- 検証終了後は RHVM上で停止・削除するだけ、物理的な検証機では検証機の返却前にストレージ初期化などの配慮が必要で手間がかかる
- 検証環境を再利用する場合はインスタンスを停止した状態で環境を保持可能、バックアップの所在が不明になるなどの事故の防止につながる
さらに、RHVの仮想ストレージにはスナップショット機能があるため、手順書作成時の環境巻き戻しが容易で、検証の精度向上に寄与しています。
もちろん、筐体が必要な検証はRHVに置き換えられませんが、相当な工数が削減され、検証そのものに多くの時間を使えるようになりました。
ネットワーク検証は物理環境で行うケースが多く、リモートワークの恩恵は得にくい傾向があります。
しかし、物理アプライアンスを購入すると非常に高額になるケースでも、仮想アプライアンスをサブスクで利用するなど工夫することで、コストを抑えることが可能です。
またネットワーク機器の検証と言っても、ネットワーク機器のみを接続して行うことは稀で、多くの場合トラフィックジェネレータ（ICMP Echoを投げるだけでも立派なジェネレータ）が必要です。そのため、トラフィックジェネレータもRHV上に配置して検証できます。
DDoS緩和を目的としたA10 Thunderの導入案件では、仮想アプライアンスのvThunderとトラフィックジェネレータをRHV上に構築し、物理アプライアンスのルータやL3SWを間に挟む構成で機能的な検証を実施しました。
AppLogic Networks社（旧Sandvine、以下ALN社）のプロダクトも仮想アプライアンスでの実装が可能です。
以下のような利用では、物理アプライアンスだと過剰性能で非効率かつレンタルも難しいため、仮想アプライアンスが適しています。
- 新機能の確認
- 問い合わせ再現
- トレーニング、デモ環境
- 案件開始前の準備
プロジェクトが複数同時進行する場合でも、仮想アプライアンスならライセンスとRHVリソースの範囲内で、必要数を自由に構築できます。
以下は、ALN社製品でPCEF（Policy and Charging Enforcement Function）を実装するユースケースの装置構成例です。
これらのALN社製品は全て仮想アプライアンスで提供されており、RHV上で稼働させることが可能です。
さらに、C-plane/U-planeが混在する複雑なネットワーク構成でも、RHV上であれば物理ネットワークを触ることなく検証環境を構築できます。
