本記事では、vSphere ESXiのインストール先として、複数のデバイスを取り上げながら、それぞれの特性、利点、考慮事項を比較を行います。ここで取り扱うデバイス＝ハードドライブ、SDカード、USBメモリスティックのような、ESXiをインストールするストレージ デバイスを指します。
読者様のインフラストラクチャの環境、監視体制、予算によって最適なデバイス選びができるよう支援をすることを目的とした記事です。
vSphere ESXi インストール先の選び方
vSphere ESXiのインストール要件
まずはVMware公式ドキュメント内にてインストール要件を確認しましょう。
以下記事内のポイントの抜粋
- 最低限必要な容量は6.7までは1GB、7.0以降は8GBである
- 上記の違いは、vSphere 7からのパーティションレイアウト変更に伴うものである。
引用元：ESXiのシステム ストレージの概要
- 上記の違いは、vSphere 7からのパーティションレイアウト変更に伴うものである。
- vSphere 7.xの場合
- vSphere 7からは上記の通り、インストールデバイスのパーティションレイアウトが変更となり、スクラッチパーティションに代表されるような特定の領域を想定した際のデザインの考え方が変わりました。主に次のような3つの推奨があります。
引用元：ESXiのハードウェア要件
- vSphere 7からは上記の通り、インストールデバイスのパーティションレイアウトが変更となり、スクラッチパーティションに代表されるような特定の領域を想定した際のデザインの考え方が変わりました。主に次のような3つの推奨があります。
- vSphere 6.xの場合
- ログ保存領域であるスクラッチ パーティションを、ESXiインストール先と同じデバイス上に設定したい場合は最低でも5.2GB以上の領域が必要である
- SDカード及びUSBメモリスティックをESXiのインストール先に利用する場合、上記の5.2GB以上の容量のものを準備したとしてもこれらのデバイスはESXiのインストーラーによってログ保存先としてはセットされません（これはデバイスの耐久面からこのような動きになっています）
- M.2 デバイスをESXiのインストール先として選択する場合は、ESXiのインストーラーはこのデバイス上にVMFSを構成します。しかしながらこの領域上で仮想マシンを動作させることは、M.2 デバイスそのものの耐久性を劣化させる可能性があるため仮想マシンの動作をさせることをおすすめしません。
M.2 デバイスに関する記述が登場したのはvSphere 6.7のドキュメントからが初めてです。
これもまた時代の流れによりインストールデバイスのトレンドが変化してきていることを感じさせますね。
また、以下の記事でも紹介していますが、Dell EMCではPowerEdgeサーバーに搭載するM.2デバイスとして”Boot Optimize Storage Solution”という拡張カードを提供しています。
vSphere ESXiのスクラッチ パーティションについて
Dell EMC | BOSSってなんだろう？～PartnerSEつぶやきブログ～
ここまでの内容も踏まえ、一般的にESXiのインストール先として登場するデバイスを列挙してみましょう。
- USBメモリスティック
- SDカード
- ハードドライブまたはソリッドステートドライブ
- M.2 デバイス(Dell EMCの場合はBOSS)
- SANブート
これらのインストール先について以下の視点から評価していこうと思います。
- 導入難易度
- コスト面
- 耐久性と障害検知
USBメモリスティック
- 導入難易度：★(簡単)
- コスト面：★（低価格）
- 耐久性と障害検知：★（低い）
USBメモリスティックは、安い、簡単が魅力です。また基本的にUSBポートはサーバーには標準搭載されているため、導入についてもUSBマウスやキーボードを接続するくらい簡単です。
このデバイスに対する考慮事項は、”障害検知が出来ない点”と”ログ保存領域の設置箇所検討”の2つです。
職業柄、テクニカルサポートのエンジニアと会話をした際に”サーバーを再起動したらESXiの起動デバイスが認識しなくなって、ESXiが起動しなくなった”というというシナリオを聞くことがあります。
一般的なサーバーには概ねハードウェア障害検知ツールが標準搭載されていることが多いですが、
監視対象としてUSBメモリスティックについては障害検知対象になっていないことが殆どです。
流れとしてはこのようなイメージです。
- ESXiがインストールされたUSBメモリスティックを搭載したサーバーを起動
- USBメモリスティックからメモリ上にvmkernelがロード、起動される
- 運用開始
- 運用期間中にUSBメモリスティックが破損する
- USBメモリスティックは破損するもESXi自体はメモリ上で動作をし続ける
- サーバーを再起動
- USBメモリスティックは既に動いていないため、ESXiのブートに失敗
管理者からすれば”サーバーを再起動しただけで、ESXiが動かなくなった”と感じてしまいますが、実態は上記のような流れです。
SDカード
- 導入難易度：★(簡単)
- コスト面：★★（中～低価格）
- 耐久性と障害検知：★★（やや低い）
サーバーにSDカードを搭載する場合、SDカードスロットを備えたサーバーであることが前提となります。
Dell EMC PowerEdgeサーバーの場合は、第11世代のPowerEdgeサーバーからは、”Internal Dual SD Card Module”という名称でSDカード搭載オプションを用意しています。
Internal Dual SD Card Module – Dell
このカードリーダー自体はDell EMC PowerEdgeにおいてはオプションですので、必要な場合は購入時に注文するかあとで増設キット購入が必要となります。
USBメモリ スティックとの共通点としては、入手のしやすさ、記憶媒体自体の価格が低い事、カード自体は専用スロットに挿すだけ、という手軽さです。やはりこのデバイスもスクラッチ パーティション設定先としてはNGです。
一方でUSBメモリ スティックとの違いとしては、次の2つがあります。
- 障害検知手法が存在する
- 搭載箇所がシャーシの内部である場合、交換のためには筐体のカバーを開ける必要がある
Dell EMCではPowerEdgeに備えている監視機能に”integrated Dell EMC Remote Access Controller”という機能がありますが、この機能を利用すると下図のようにエラー検知が可能であり、上記で紹介したUSBメモリ スティックのように障害を見落とすことはありません。
また保守交換の場合では、同社の場合はSDカード スロットは筐体内部に配置している兼ね合いから、
SDカード1枚の交換には筐体カバーを開閉が発生します。
ラッキングしている筐体の場合、ラックから引き出す必要があるため、USBメモリ スティックと違い交換に対してはお手軽とは言い難いです。
ハードドライブまたはソリッドステートドライブ
- 導入難易度：★★(簡単)
- コスト面：★★★（中価格）
- 耐久性と障害検知：★★★（標準的）
エンタープライズのインフラにおいて、これらのドライブに対してOSを入れるという手法は非常に伝統的な手法でした。vSphere ESXiについて言えば、インストールに必要な容量はWindows Server等の他OSと比べると十分すぎるほどの容量だとも言えます。
またRAIDを利用することでドライブ内のデータ保護及び障害検知も出来ます。ログ配置についてもこれらのデバイス上にESXiとログ保存先(スクラッチ パーティション)を共存させることも可能です。
そのため設計についてシンプル化できるという利点があると言えます。
一方で考慮事項ですが、2つあります。
- vSAN環境においては次のKBの内容を考慮する必要があります。
vSAN と 非 vSAN ディスクを同じストレージ コントローラで使用する場合のベスト プラクティス(2129050) - Software Defined Storage環境において、最大限にストレージ容量を活かしきれない
まずはじめに1の方から図も利用しながら解説をしていきます。
例えばDell EMC PowerEdge R640という機種をvSAN用ノードとして利用する場合、前面ディスクスロットのスタイルが以下のように複数あります。
Dell EMC Virtual Rack – PowerEdge R640
例えば、以下のような構成は非サポート構成です。
キーポイントは単一のハードウェア ストレージコントローラーにて、ハードウェアRAIDを構成しているドライブと、ハードウェアRAIDを構成していないドライブの混在は、vSANのIO動作に問題を起こす要因に成りかねない、というものです。
もしハードウェアRAIDによりESXiの領域を保護したい場合は、ESXi用とvSAN用にストレージ アダプターをそれぞれ準備しましょう。
こちらはサポートされる構成です。2つのストレージ アダプターを搭載すれば問題ありません。
続いて2の、”Software Defined Storage環境において、最大限にストレージ容量を活かしきれない”についてですが、OSの領域のために前面のディスク スロットを2つも消費してしまっています。
ESXiのインストールサイズはたったの数GBであることを考えれば、それだけのために大容量ドライブを使うのは少々もったいないようにも思えます。（もちろん、ハードウェアRAIDを構成してESXiをインストールすることの利点は、ログ管理領域の設置ができるというメリットがありますので、こうした目的を理解してデプロイされるのは全く問題ないと言えます）
少なくともストレージ容量をできるだけ増やしたいというユーザーには、この方法は向かないと言えます。
また、この方法では、前面ドライブ スロットがESXiに使われてしまうのに加えて、PCI スロットも1スロット余分に利用してしまっているため、1Uサーバーのように拡張性が限定的な製品では導入の敷居が高いと言えます。
M.2 デバイス
- 導入難易度：★★(簡単)
- コスト面：★★★（中価格）
- 耐久性と障害検知：★★★（標準的）
何度も登場するBOSSです。社内でも”ボス”と呼ばれています。これまで紹介してきたデバイス達にはそれぞれ弱点がありました。
- USBメモリスティックやSDカードは耐久性面が不安且つログ保存先の設計が必要
- 物理ドライブの場合にはドライブスロットがvSANでは活用出来なくなる
これらをカバーするソリューションとしてM.2デバイスが登場したと言えるでしょう。
BOSSもPCIカードベースでのソリューションではありますが、前項の物理ドライブと違い、筐体のドライブスロットを利用しませんので、vSANのためにそれらを活用することが可能です。
BOSS上には最大2枚のM.2 SSDが搭載可能であり、RAID1によるミラー保護も可能です。
これに加えSDカードと同じく、iDRACを始め複数の管理ソリューションが利用可能です。
BOSS-S1 コントローラ用の管理アプリケーション
加えて、スクラッチ パーティションの作成をBOSS上に行うことも可能です。外部公開している資料ページでは、BOSS上へのVMFS作成は行わないようにとの記述がありますが、これは仮想マシンを動作させないように、という意味合いのものになります。
考慮事項としては次のような点が挙げられると言えます。
- 汎用的というよりはベンダー固有のソリューション寄りである
- 比較的新しいデバイスであるため、枯れた技術による安定性を求めるユーザーよりは先進的な技術を追い求めるユーザー向けである
- 拡張カードスロットを1つ利用する
参考資料
Dell EMC Boot Optimized Server Storage-S1 User’s guide
SANブート
- 導入難易度：★★★★(難しい)
- コスト面：★★★★★（高額）
- 耐久性と障害検知：★★★★★（高い）
SANブートでは、ESXiをSANストレージ上から起動します。
つまりSANストレージ環境が存在することが前提となるため、
SANストレージを保有していないユーザーの場合はまず本選択肢は外れると言ってもいいでしょう。
また、SANストレージを保有していたとしても、製品そのものがSANブートをサポートしているかどうかの確認が必要です。
例えばDell EMC PowerVault MD3 ストレージでは、SAN Bootをサポートしていません。Link (Page 11参照)
SANブートの利点は次の通りです。SANブートのメリット – vSphere 6.7
これまでの起動デバイス選びでは、耐久性や価格、障害検知などを比較しながらだったのに対し、SANブートの選定理由の一つは、管理性の向上にあると言えます。
vSANにおける起動デバイスの考慮事項
vSAN環境においては、ESXiホストに搭載されているメモリ搭載容量は、起動デバイスの選定基準の1つとなります。ホストの搭載メモリ量が512GB未満であればUSBメモリやSDカードといったデバイスが利用可能であり、これを超える場合についてはSATADOMやディスクなどのデバイスである必要がありますのでご注意ください。
まとめ
本記事では、ESXiのインストール先として複数の選択肢があることを学びました。
どれが最も良い、ということはありません。コストの面で見るのか、管理性でみるのか、視点によって評価が異なるためです。
最も重要なのはそれぞれの特性を理解し、考慮事項に対し適切な対処を行い正しい運用を行う事にあります。
これまで私がサポート/サービス系部門に所属してきた経験からは、ログ保存領域についての設定不足により必要な調査ができなかった、というケースが散見されていましたので、一言アドバイスをさせて頂くとすれば、ログ保存先については特にご配慮いただければ幸いです。（スクラッチパーティション以外にもSyslogサービスの利用という方法もあります）
コメント