VMwareからProxmoxへ。現場エンジニアに聞く「今、本当に必要な仮想化基盤」とは

VMwareをはじめとする仮想化基盤は、企業や大学のシステムを支える重要なインフラとして長年利用されてきました。

一方で近年、仮想化ソフトウェアのライセンス体系の変化に加え、サーバー、メモリ、SSDなどのハードウェア価格も上昇しています。

これまでなら、

「仮想化基盤なら3ノード構成」
「共有ストレージを用意する」
「障害が発生しても止まらない構成にする」

といった考え方が、ある意味では“当たり前”でした。

しかし、その当たり前は今も最適なのでしょうか。

Proxmox VEについて語る三好永那士氏と山本守氏
左:三好 永那士 氏/右:山本 守 氏

今回は、当社でProxmox VEの設計・構築を担当するインフラエンジニアの山本と、技術営業を担当する三好に、実際の案件でどのようにProxmoxの構成を考えているのかを聞きました。

インフラエンジニア(スペシャリスト):山本 守 氏
営業担当(技術営業 課長代理):三好 永那士 氏

仮想マシン30台なら、まず何から考えるのか

――例えば仮想マシンが30台程度ある環境をProxmoxへ移行するとしたら、まずどのようにサーバースペックを考えますか?

既存環境からの移行であれば、まず現在の基盤を調査します。CPU、メモリ、ストレージがどの程度割り当てられていて、実際にはどの程度使用されているのか。

新規構築であれば、各システムの要件やシステム担当者へのヒアリングから必要なリソースを算出していきます。

CPUについては、理想を言えば物理コアと仮想CPUは1対1です。ただし、すべての仮想マシンについて1対1にする必要があるとは考えていません。

例えば、

  • 負荷が高いシステム、重要なシステム:1対1
  • 一般的な業務システム、AD、ファイルサーバーなど:1対2〜4程度
  • 検証環境など普段の負荷が小さいもの:さらに大きなオーバーコミット

といったように、システムの性質によって考え方を変えます。

CPUは常にすべての仮想マシンが最大負荷になるわけではないので、ある程度平均化できます。そのため、必要に応じてオーバーコミットすることは可能です。

ただ、何でもオーバーコミットすればよいわけではありません。

CPUはオーバーコミットできても、メモリは慎重に

――メモリについても同じように考えられますか?

メモリはCPUとは少し違います。基本的には、オーバーコミットさせない前提で設計した方が安全だと思っています。

CPUは瞬間的に負荷が高くなっても平均化できますが、メモリは仮想マシンが確保すると、その分を実際に使用します。

メモリが不足してスワップを使い始めると、パフォーマンスが大きく低下します。「サーバー自体は動いているけれど、遅くて実用にならない」という状態は避けたいところです。

既存環境で100GB割り当てられていて、実際には30GB程度しか使用していないのであれば、30GBを基準にしながら将来の増加分を考えます。

例えば現在30GBなら、1.2倍程度の余裕を見たり、今後仮想マシンが増える予定があればその分も加えます。

さらに、3ノード構成であれば、1ノードが停止したときに残りの2ノードで仮想マシンを動かせる容量を確保する必要があります。

3ノードなら「1台止まっても動く」ことを前提にする

――3ノード構成の場合、どのくらいの余裕を見ておくのでしょうか?

インフラエンジニアの山本守氏
インフラエンジニア(スペシャリスト):山本 守 氏

基本的には、各ノードのリソース使用率を66%未満に抑えるように考えます。1台が停止した場合、そのノードで動いていた仮想マシンを残り2台で分担することになるからです。

4ノードであれば考え方は少し変わり、75%未満でも計算上は成り立ちます。

ただ、実際には障害対応だけではありません。メンテナンスで仮想マシンを退避することもありますし、新しいサーバーを一時的に構築することもあります。既存サーバーをすぐに削除できず、一時的に新旧2台が存在することもあります。

そのため、実運用では60〜70%程度に抑えておく方が安全だと思います。

ストレージは「今割り当てている容量」をそのまま持ってこない

――ストレージ容量はどのように見積もっていますか?

既存環境であれば、まず現在の使用量を確認します。その上で今後5年間の増加や、仮想マシンが追加される可能性を考えます。

目安としては、現在必要な容量に対して1.3〜1.5倍程度を見ることが多いです。

ただし、ここで重要なのは、既存の仮想ディスク容量をそのまま新環境へ持ってくる必要があるのか、という点です。

例えば3TBの仮想ディスクを割り当てているけれど、実際には1TBしか使用していない。しかも今後も3TBを使う予定がない。そうであれば、本当に3TB必要なのかは、お客様と相談した方がよいと思います。

仮想基盤の更新は「無駄なリソースを整理する機会」

仮想基盤は長年運用していると、不要な容量がそのまま残っていることがあります。10TB割り当てたサーバーが、実際には1TBしか利用していない。

それを何も考えずに新しい基盤へ移行すると、さらに余裕を見て12TB、13TBと確保してしまうことになります。

しかし、それではSSDやストレージ価格が高騰している現在、無駄なコストがそのまま次の基盤にも引き継がれてしまいます。

仮想化基盤の更新は、「今までこうだったから同じ容量を用意する」のではなく、「本当に必要なリソースはどれだけなのか」を一度整理する良いタイミングでもあります。

ネットワークは今なら25GbEを基本に

――Proxmoxのネットワークは10GbE、25GbE、100GbEなど、どの程度必要でしょうか?

大型モニターに表示したProxmox VEの管理画面

今構築するのであれば、基本的には25GbEで考えることが多いです。

現在のサーバーNICは10GbEと25GbEの両方に対応している製品も多いですし、Cephを利用するのであれば25GbE以上を前提に考えた方が良いと思います。

一方で100GbEについては、大規模環境でなければコストパフォーマンスがまだ良くありません。仮想マシンの台数やストレージ性能によって、どこがボトルネックになるのかを見ながら選択します。

単に速いNICを付けるだけでなく、どこにどれだけ帯域を使うのかまで含めて設計することが重要です。

Proxmox Backup Serverは「純正だから使う」以上のメリットがある

――バックアップについては、どのような構成を推奨していますか?

基本的にはProxmox Backup Server(PBS)を利用します。Proxmox VEと同じハードウェアに置くのではなく、別のサーバーとして構築します。仮想基盤そのものが故障したときに、バックアップまで一緒に失ってしまっては意味がないからです。

容量については、バックアップ対象となる仮想マシン容量の1.5〜2倍程度を一つの目安にしています。

PBSはチャンク単位でデータを管理していて、変更された部分だけを転送します。そのため、例えば100GBの仮想マシンでも、毎回100GBを転送するわけではありません。

日々の変更量が少なければ、転送されるデータも小さくなり、バックアップ時間もかなり短くなります。実際の環境では、仮想マシン1台のバックアップが数分程度で終わるケースもあります。

「数秒前に戻す必要があるシステム」ばかりではない

バックアップや可用性を考えるとき、重要なのは、「どの時点まで戻れればよいのか」というRPO(目標復旧時点)です。

ECサイトや金融系システムのように、数秒、数分前までのデータを守る必要があるシステムもあります。一方、大学などのシステムでは、数十分前まで戻れれば業務上問題がないケースも少なくありません。

すべてのシステムに最高レベルの冗長性を求めるのではなく、そのシステムに必要なレベルを見極めることが重要です。

2台目のPBSでランサムウェア対策も

――PBSはランサムウェア対策にも利用できますか?

できます。例えば2台目のPBSを別に用意し、1台目から2台目へPull型で同期させる方法があります。

認証情報も別にしておけば、仮に仮想基盤やメインのバックアップ環境がランサムウェアの被害を受けた場合でも、2台目まで被害が及ぶ可能性を下げることができます。

2台目は高性能なサーバーである必要はありません。大容量のSATAディスクを搭載した比較的安価なサーバーでも構成できます。できれば別の建物など、物理的にも離れた場所に置くとより効果的です。

クラウドストレージを利用する方法もありますが、オンプレミス環境でコストを抑えながらランサムウェア対策を行う方法としても有効です。

Ceph、3Tier、それとも2ノード。何を選ぶべきか

――ProxmoxではCephを使ったHCI構成、共有ストレージを使う3Tier構成、ZFSを使った2ノード構成などがあります。どのように使い分けていますか?

ホワイトボードでProxmox 3-Tierアーキテクチャを説明する三好永那士氏
Proxmox 3-Tier構成を説明する三好 永那士 氏

拡張性を重視するのであれば、Cephは非常に良い選択肢です。今後ノードを増やしていく予定がある環境なら、Cephのメリットは大きいと思います。

3Tier構成は、これまで長く使われてきた構成ですし、共有ストレージを利用する安心感もあります。

一方で最近、非常に面白いと考えているのが、2ノード+ZFSレプリケーションです。

2ノード構成ではQDeviceをどうするか

――2ノード構成の場合、クラスタの成立には何か注意点がありますか?

2ノードでProxmoxクラスタを構成する場合、考えておく必要があるのがQDeviceです。

クラスタでは、どのノードが正常に稼働しているのかを判断するために「Quorum(クォーラム)」という考え方を使います。

3ノード構成であれば、2台以上が正常であれば多数決が成立します。一方、2ノードだけでは1台が停止したときに「どちらが正しい状態なのか」を多数決で判断できません。

そこで、クラスタの判断に参加する第三の投票役としてQDeviceを用意します。

QDevice用に大きなサーバーを追加する必要はありません。今回のようにProxmox Backup Server(PBS)を別サーバーとして用意しているのであれば、PBSにQDeviceの役割を持たせるという構成も考えられます。

QDevice自体はProxmox専用の特殊なハードウェアではなく、Linux上で利用できるパッケージとして導入できます。Proxmox側とQDevice側の双方で、

「このサーバーをクラスタの調停役として利用する」

という設定を行うイメージです。

専用に小型PCなどを置く方法もありますが、本番環境で長期間運用することを考えると、既にバックアップ用として稼働するPBSへ役割を持たせる方が、構成としてもシンプルです。

また、QDeviceのためだけにProxmoxノードと同じような専用ネットワーク構成を用意する必要がない点も、2ノード構成では扱いやすいポイントです。

「364日の性能」を優先するという考え方

2ノード構成では、基本的に仮想マシンは各ノードのローカルストレージ上で動作します。そしてZFSレプリケーションを利用して、もう一方のノードへ定期的にデータを同期します。

共有ストレージを必要とせず、通常時はローカルNVMeなどの性能をそのまま利用できます。

一方で、大きな障害が起きた場合には、最後にレプリケーションした時点までデータが戻る可能性があります。

つまり、「絶対に止めない」構成ではなく、「止まった場合にどう戻すか」を重視した構成です。

インタビューでは、こんな議論になりました。

「365日のうち、実際に障害対応が必要になるのはごく一部。その1日のために、3台目のサーバーや共有ストレージへ大きなコストをかけるべきなのか」

ハードウェアが安かった時代であれば、余裕を持った冗長構成を作ることに大きな問題はありませんでした。しかし、現在はサーバーもメモリもSSDも高価になっています。

であれば、364日は高性能なローカルストレージで快適に利用し、万一の1日は多少性能を落として復旧する。

そうした割り切りも、一つの合理的な設計ではないでしょうか。

Proxmoxだからこそ「高価な構成をそのまま再現しない」

Proxmoxを検討するお客様の多くは、仮想化基盤のコストを見直したいと考えています。それにもかかわらず、

3台の高性能サーバー。
高価な共有ストレージ。
大容量のバックアップ製品。
さらに高価なネットワーク。

と積み上げてしまえば、結局かなり高額な仮想化基盤になります。

もちろん、高可用性が必要なのであれば、それが正しい設計です。しかし、本当にそこまでの可用性が必要なのか。

障害が起きたとき、

「数十分前まで戻ることを許容できる」
「数時間以内に復旧できればよい」

というシステムなのであれば、もっとシンプルな構成も選択できます。

まず2ノードで考え、必要ならCephや3Tierへ

今回のインタビューを通して見えてきた考え方は、とてもシンプルです。

最初から、

「仮想基盤だから3ノード」
「共有ストレージが必要」
「HCIでなければならない」

と決めるのではありません。まず、

  • どの程度止められるのか
  • どの時点までデータが戻ってもよいのか
  • 将来ノードを増やす予定があるのか
  • どこまでの性能が必要なのか
  • 障害時にどの程度人手をかけられるのか

を整理する。その結果、

2ノード+ZFSレプリケーションで十分なら、そこから始める。
拡張性や高可用性が必要ならCephを選ぶ。
共有ストレージを利用した従来型の運用が適しているなら3Tierを選ぶ。

Proxmoxの大きなメリットは、特定の構成に縛られず、要件に合わせて仮想化基盤を設計できることなのかもしれません。

ハードウェアも「Proxmox専用品」である必要はない

Proxmoxはハードウェアの自由度が高いことも特徴です。VMwareやNutanixのように、特定の認定ハードウェア構成だけを前提とするものではありません。

一方で、安価であれば何でもよいわけではありません。障害時に数か月サーバーが戻ってこないセンドバック保守では、仮想基盤としては使いにくいケースがあります。

ディスクなど故障しやすい部品を現地交換できることや、先出し交換に対応していることなど、ハードウェア価格だけでなく保守条件まで含めて選ぶ必要があります。

Proxmox VE 9.2の管理画面(仮想マシンのコンソール)
Proxmox VE 9.2の管理画面

「最も高機能な構成」ではなく「最も合理的な構成」を

仮想化基盤では、可用性を高めようと思えばいくらでも高めることができます。しかし、可用性を上げるほどコストも複雑性も増えていきます。

重要なのは、最高の構成を作ることではなく、そのシステムに必要十分な構成を作ること。

Proxmox VEは、その選択肢を大きく広げてくれる仮想化プラットフォームです。

3ノードCeph。
共有ストレージを利用した3Tier。
そして2ノード+ZFSレプリケーション。

当社では、特定の構成を最初から決めるのではなく、お客様のシステム要件、予算、運用体制、許容できる停止時間やデータ損失量を確認した上で、構成を検討しています。

VMwareなど既存の仮想化基盤の更新費用に悩んでいる方や、次期仮想化基盤をどのように構成すべきか迷っている方は、ぜひ一度ご相談ください。

コメント

この記事へのトラックバックはありません。

関連記事

目次