vSAN OSA更改時の考慮事項
この投稿は、vExperts
Advent Calendar 2025 の 8日目です。
文字ばかりですがご容赦ください
この記事の概要
VCF9のリリースによってvSAN OSAの一部のHybrid構成がDeprecateになった。
そのため、OSA環境の更改においてはESAへのトランジションの検討が盛んになっている。
一方で、ESAへのトランジションにおいては、HCIのメリットの一つであるシームレスな更改手法（玉突き方式）がつかえない、といった
考慮事項も存在する。
本記事では、vSANクラスタの更改時によくある考慮事項を紹介する。
想定既存環境
以下のようなサンプル環境の更改を想定する
- vSAN OSA クラスタ（vSAN Ready Node、クラスタ内の全ノードが更改対象）
- ライセンスはリテール版を利用し、HWと更改時期がずれているため、更改対象ではない。
- 外部ストレージは無し
- TORスイッチのHW更改の対象に含める
※OEMライセンス利用時や、vSAN Ready Nodeより上位となる専用アプライアンスを利用している場合、
ライセンスや保守サービスにかかわる考慮事項が追加され、より複雑となることがあるが、本記事では考慮しない。
更改パターン
移行方法とストレージアーキテクチャをベースに大別すると以下の4パターンが考えられる。
- OSA玉突き更改
- OSA新規クラスタ
- ESA新規クラスタ
- 分離型新規クラスタ（vSAN MAX or 外部ストレージ）
更改パターンを選択する際の考慮事項を次項に列挙する
考慮ポイント
実績と安定性
OSAと外部ストレージ構成は実績や安定性の観点で申し分ない
ESAも2022年にリリースされて以来、大きな不具合もなく現在に至る印象があるが実績の面ではOSAや外部ストレージが勝る
トラブルシューティングに関してもOSA/外部ストレージのほうがナレッジが充実している
将来性
OSAはHybrid構成でDeprecateとされており、All Flash構成も将来的には利用できなくなる可能性が高い。
9.3までは利用できる仮定としても、その後のメジャーリリースでは非サポートになっていてもおかしくはない。
そのため、9.3の標準サポートが終了するとされる2031年を超えて利用するHWの場合はESAや外部ストレージのほうが良い。
なお外部ストレージの場合、vVOLは9.1から非サポートになることが明示されているため、
vVOLの利用は避けてVMFS/NFSで検討すべき。
vSANライセンス
現行のvSANライセンスを更改後のHWでも使いまわす場合、
vSANライセンスがAdvanced以上でないとvSAN ESAを選択することができない
ライセンスも更改（VVF or VCF）する場合は、vSAN
Enterprise相当であるためvSAN ESAも選択可能。
vSphereライセンス
HW更改時の移行方式がCross
vCenter vMotionとなる場合、既存環境のvSphereライセンスがvSphere
Ent+以上でないとオンラインでの移行ができない（Cold MigrationはvSphere Stdでも可能）
永続ライセンス利用時
旧来の永続ライセンスはVCF9で利用することができず、vSphere/vSAN 8.xが最終バージョンとなる。
VCF9以降にソフトウェアを更新するためには、新しいSubscriptionライセンスへの変更が必要となる。
vSphere/vSAN 8.xは2027年10月にEOGSとなるため、既存の永続ライセンスの更改タイミングを鑑みて、VCF9へのソフトウェア更新も計画しておく。
なお、2024/5/4以前に購入したVMwareライセンスには旧来のTechnical Guidanceが付属しているため、保守サービスの低下を許容できれば2029年10月までvSphere/vSAN 8.xで利用を継続する選択肢も生まれる。
移行方式
玉突き方式
ノード追加と削除を繰り返すことでクラスタ全体をHW更改を行う方式。既存と同じアーキテクチャ（OSA)でのみ利用可能。1ノードずつの更改が可能であるため、移行時のラックスペースやIPアドレスを最小限にできる。単一クラスタを維持したまま更改を行うため、バージョンや構成は基本的にそろえる必要がある。データ移行の時間をResync速度から見積もることが可能であり、かつAdaptive Resyncの機能によって稼働中のVMへの影響を抑えつつ移行を完了できる。
横並び方式（vMotion）
新規クラスタを構築して、vMotion/SvMotionでクラスタ間でVMを移行する方式。
一時的に並行運用となるため、IPリソースやラックスペースを多く消費する。
新旧クラスタが同じバージョンでなくてもよいため、実質的に環境のソフトウェア更新を同時に行うことが可能である。
旧クラスタとの並行運用期間もあるため、切り戻しも可能となり、通常のソフトウェア更新よりも安全に行うことができる。
移行に要する時間にかかわる制限として、同時移行数の制限が存在する。VM数が多い場合は想定よりも時間がかかるケースがある。
また、コピー速度の指標となるデータがないため、VM移行（データ移行）にかかる時間を事前に見積もるのが難しい。
またクラスタ間のVM移行（データ移行）の際に、Online Migration（vMotion）であったとしてもSnapshotなどのColdデータは管理系ネットワークを流れてしまう。
それを回避するためには、Provisioningトラフィックを有効化することが必要となる（Enable UDT Traffic）。
また、クラスタ間の移行となるため、vCenterサーバのトポロジによって、さらに2パターンに分かれる。
新旧クラスタを異なるvCenterで管理するパターン
Cross vCenter vMotionによる移行が必要。
新旧クラスタで異なるvCenterサーバで運用している場合、Cross vCenter vMotionが必要となる。そのため、オンライン移行の際にはソースとターゲットの両方でvSphere Ent+以上のライセンスが必要となる。（Cold Migrationの場合はvSphere Stdも可）
ELMを組むことでGUIを統一することで並行運用負荷低減が可能だが、バージョンの制限やトラブル時負荷などのデメリットもある。
ELMを組まずにAdvanced Cross vCenter vMotionを使うことで、それらのデメリットを回避できるが、並行運用期間に新旧クラスタでGUIが分かれるデメリットがある
新旧クラスタを単一のvCenterで管理するパターン
Cross Host vMotionによる移行が可能。
同一のvCenter配下に両クラスタが管理される場合は通常のCross Host vMotionで共有ストレージ無しでクラスタ間の移行が可能。
vMotion時のライセンス要求が低く（vSphere StdでOK）、かつ並行運用時のメリットもあるため、vCenterを別建てしなくてはならない事情がない限りこちらの方式のほうが推奨される。
横並び方式（オフライン）
小規模であれば、VMのExport/Importも検討可能になる。
アップグレード要否の考慮
玉突き方式でも横並び方式でも基本的には既存側をアップグレードする必要はない（標準サポート範囲内のバージョンを想定）。
玉突きの場合、更改後にバージョンが変わっていないため、将来的にはアップグレードが必要となる。
一方で、横並び方式の場合は新規クラスタのバージョンを既存と合わせる必要がないため、移行と同時にクラスタのアップグレードも可能となる。
将来的なアップグレード作業工数やコストのハードルも踏まえて考慮したい。
なお、VCF9はSkylake CPUは利用できないため注意が必要である。Cascade LakeであればVCF9でも利用可能だが、一部の古いIOデバイスは非対応になってしまっていることもあるため、そちらも確認が必要である。
並行運用時の注意事項
OSAクラスタとESAクラスタを並行で利用する場合、機能レベルが異なるため、OSAクラスタへの切り戻しなどが想定される環境においてはESA固有の機能は利用しないほうが良いケースがある。
vSAN ESAの圧縮やRAID5/6などは利用して問題ないが、vSAN
Data Protectionを利用する場合においては、OSA/ESA間でVMを往復させた際に想定通りの動作とならないケースがある
※SnapshotはStorage vMotion前後でも保持されるため、失われない
なお、vSANにはvSANのリモートマウント機能（旧称：vSAN HCI Mesh）があるが、vSANクラスタのESXiはOSAデータストアかESAデータストアのいずれか1種類しかマウントできない。
そのため、OSA/ESAクラスタ混在環境で相互にvSANデータストアをマウントすることはできない。
一方で、VMFS/NFSデータストアにおいては制限がないため、外部ストレージ構成の場合は新旧クラスタ間でストレージを最大限に消費できる。
3rd partyソリューションとの互換性考慮
更改に合わせてバックアップなどの3rd partyソリューションを継続利用するケースにおいても、同時に更改する場合においても、新旧アーキテクチャとの互換性確認が必要となる。
最近では主要なバックアップソリューションでESAに対応していないものは存在しない印象だが、バージョンによっては未対応ということもあるため、ESA採用時は関連ソリューションの互換性確認も必要となる。
更改に際してバージョンが変わる場合も同様である。（VCF9に未対応、部分対応のケースもありうる）
なお、Backup/Restore方式でVMを移行する場合、OSAのストレージポリシーがESA環境で適切に適用されない可能性があるため、事前にバックアップソフトウェアベンダーに確認するほうが良い。
※RAID5/6で構成されるはずがMirrorでリストアされてしまい容量が足りなくなったり、事後にvSAN
Objectの再構成が必要になるなど、余計な工数やリスクを被ることになる。
TORスイッチの更改考慮
HCI環境はTORスイッチも同時に購入・更改となるケースも多い。
vSANの場合、vSANネットワークの疎通が失われるとクラスタ全体のVMが影響を受けるため、スイッチ更改時は基本的にオフライン作業が推奨される。
横並び方式の場合は自然とTORスイッチの更改も可能となるが、玉突き方式の場合は新旧TORスイッチ間でvSANトラフィックが発生するため、新旧スイッチ間の帯域が不十分な場合に性能影響につながる可能性がある。
コスト
VVF/VCFライセンス
最新のデザインガイド（vSAN Design Guide）においても、過去バージョンから引き続き10%のオーバヘッドの考慮が必要である"Provide for a 10% CPU overhead for vSAN "
そのため、外部ストレージ構成と比べてVVF/VCFライセンスは約10%のコストアップとなる
vSANライセンス
OSAとESAを比べた場合、キャッシュ層への課金有無が異なるが、経験上はESAのRAID5/6や圧縮の恩恵によって、ESAのほうがvSANライセンスコストを抑えられる傾向にある。さらに最新バージョンではvSAN ESAでもGlobal Dedupが利用できるようになっている。vSAN OSAはEC利用時の性能影響がESAよりも大きいためRAID1想定
DIMMコスト
vSANを利用する場合、ハードウェア要件として最低限のメモリリソースが上乗せされている外部ストレージで組む場合はその分のDIMMコストを削減できる。
今後（2025/12~）はDIMM価格の上昇が予想されるため、外部ストレージによってDIMMコストが大きく抑えられる可能性もありうる。
ストレージ費用
vSANと外部ストレージを比較した場合、VVF/VCFの付属vSAN容量範囲内で賄える場合は基本的にvSANのほうが価格を抑えられる。一方で、付属vSAN容量を超えて追加のAdd-onが必要となる環境の場合は外部ストレージに価格優位性が出るケースもある。
ただし、vSAN Storage Cluster（旧称：vSAN MAX）の場合は現行のライセンス体系ではコストメリットがある環境は限定される
まとめ
本記事ではvSAN
OSAクラスタ更改時によくある考慮事項を紹介した。
vSANにフォーカスした内容となってしまったが、必ずしもvSANにこだわる必要はなく、コストや柔軟性という観点で外部ストレージ構成に十分なメリットがある。
想定しているサンプル環境はリテールライセンスを利用したvSAN Ready Node環境であるが、
VAOライセンスやアプライアンス製品等においては、追加の考慮事項があったり、今回紹介した推奨事項が当てはまらないケースもがあったりするため、
その場合についてはベンダーやSIerにもご相談ください。
コメント
コメントを投稿