自然の赴くままに・そのときの 気分次第で・なんとなく

興味を持ったことを、なんとなく気の向くまま書いています。

vSphere のライフサイクルの可視化をしてみた

vSphere のライフサイクル

vSphere 7 が 4/2 に登場してから早速検証をされている人も多いのではないかと思います。そして「これなら大丈夫!」と本番業務の環境に使おうと考えるようになるわけですが、新規の環境は置いておいて既存の環境をアップグレードするとなると気になるのは vSphere のライフサイクルなわけです。

既存の仮想化環境は今までのレガシーな物理環境をそのまま仮想化環境に移したシステムも少なくありません。となると、既存の業務システムの寿命とハードウエア寿命と、それに対する vSphere の寿命の関係が気になってくるわけです。

本番業務の寿命と仮想化プラットホームの寿命

今までのオンプレミスの環境の場合、ハードウエアの寿命が来てリプレースするから新しいハードウエアでサポートしている vSphere も一緒に入れるという形がほとんどです。ここで気になるところとして、仮想化プラットホームの上で既存の業務システムが動いている OS がサポートされるのか、新しい環境の vSphere を入れるときにサイロ化されてしまっている仮想化プラットホームを統合しようとしたいけれど、vSphere の互換性や統合時の課題などが気になってサイロでまたオンプレミスを更新ということが多いかと思います。また、一番ダメな例としては、ハードウエアは新しくするけれど今までの環境が vSphere X.X だから、新しいハードウエアでもしその vSphere X.X がサポートされているのであれば同じものを使いたいとか、入札の RFP でそれを書いてしまうとか、そういうのに遭遇することが結構ありますよね。これ、ハードウエアは物理的に古くなっているのはわかるんだけれど、ソフトウエアもライフサイクルがあって寿命があって、そして更新しなければならないということが発生するということを忘れていて、ずっと使えるという感覚でいる IT 担当者とそこを担当する言われたら「はい」と言ってしまう SIer があるわけです。これにより、例えば vSphere 7.0 が出たのに(またはもうすぐ出るとわかっているのに)一つ前の vSphere 6.7 を提案してしまう、または IT 担当者は RFP に書いてしまう。もちろん、事前にライフサイクルを見ていて「今は枯れた現行バージョンを使い、時期を見て安定してきた vSphere 7 に入れ替える計画をしよう。」と考えていての選択なら Good なんですが、そういうことを思わずに単に「最新は枯れていないから、不安だから、今は安定しているバージョンを使いたい」ということで SIer が提案し IT 担当者はいずれ来るアップグレードのことは Out of 眼中で仮想化プラットホームのリプレースをしてしまう。そして後になって IT 担当者は「サポート終了の連絡がきた!」と驚き環境を構築した SIer に「こんなのきいていない、責任でアップグレードしろ」と迫る。こういう恥ずかしいやり取りをよく目の当たりにしますよね。少なくとも IT をやっている者(専門家ですよね)であればそういうことにならないように事前に計画したいものです。

ライフサイクルとアップグレードのタイミングをどのように考えるか

これはとても簡単です。VMware 社が公開している製品のライフサイクル マトリックスを確認し、これから導入または更新する仮想化プラットホームにどのような影響が出るのかを知り判断・計画するだけですね。

例えば、今年の秋に仮想化プラットホームの更新がある場合、製品のライフサイクル マトリックスを確認すれば vSphere 6.7 は 2021年にジェネラルサポート終了で 2023年にはテクニカルガイダンスも終了する。でも、その後の提供終了は未定になっているのを見れば、今は安定稼働を最優先するので途中でアップグレードを考慮して vSphere 6.7 を提案するという形か、秋なのでアップデートが出て安定するだろうということを見越してその後はアップグレードはせずに vSphere 7 でいくかの判断ができます。来年度以降の話であれば、まず後者の vSphere 7 を提案または RFP に記載するべきで、今更 vSphere 6.7 にするのであれば、アップグレードは計画に織り込み済みである必要があるでしょう。

vSphere のライフサイクルを知るには

vSphere のライフサイクルを知るには先にご案内した製品のライフサイクル マトリックスを見るのが簡単ですが、細かくて読みにくいとかあるので、vSphere の ESX/ESXi と vCenter Server だけ抜粋して図にしてみました。

f:id:imaisato:20200509224451p:plain

vSphere のライフサイクル

これを見ていただければお使いの製品がいつ寿命を迎えるかがわかると思います。

PDF も用意しましたので詳細はこちらをご覧ください。古い 1.0 とかも出ていますが、こちらは正式なリリース日や終了日を失念してしまったので記載していないです。でも、そこまで古いのは使っている人はいないと思うので良いと思いますね。

drive.google.com

あと、4.0 と 4.1、5.0 と 5.1、が同じリリース日になっていますが、サポート終了から逆算してそのようにしてるみたいですね。つまり、マイナーバージョンで 0 または 5 じゃないものは、その前のバージョンのアップデート版みたいな扱いのようです。あと vSphere 6.7 U2 は限りなく vSphere 7 なのですが、これも Kubernetes 入れる前の vSphere 7 が vSphere 6.7 で、そのあたりを仕込んだのが今回の vSphere 7 なんだろうなぁと、何となく思ってしまったりしています。実際にどうなのかはわかりませんが。

ハードウエアのライフサイクルと業務システムを分離するには

結局のところ、既存のままの素組みで物理サーバとストレージを構成するオンプレミス環境、そしてそれらをまとめて管理できるのが売りの HCI にしたとしても、ハードウエア寿命による入れ替えやその際の vSphere のバージョンの心配、または vSphere 過渡期に入れ替えしなければならなくて、次の更新までに vSphere のアップグレードが必ず発生するような仮想化プラットホーム、本当にそのままでよいのかという疑問はないでしょうか。素組みのオンプレミス環境なら頑張ってサポート終了までセキュリティや不具合のリスクを負いながら塩漬けするというダメダメな選択肢でアップグレードの回数を減らすということもできるかもしれませんが、HCI を使ってしまうとハードウエアと vSphere そして HCI マネジメントソフトの関係が厳密なので、ハードウエアの寿命までの間に何度も何度もアップグレードするようなことが出てくるかもしれません。そしてそもそも HCI ハードウエア間での整合性をとるためになるべく同じハードウエアでという制限とかもあったりしますよね。こういうことも含めて業務システムとハードウエアや仮想化ソフトウエアの寿命を意識して、この先もずっとすべてのオンプレミス環境を維持管理していくその手間は結構大きい負担ではないかと思います。そして、更新時期に発生する新しいハードウエアや仮想化ソフトウエアに対してのサイジング、こういう負担はできれば少なくしたいものです。

なので、オンプレミスのハードウエア寿命のタイミングで本当にオンプレミスに残さなければならないものは何なのかなどを判断して、クラウドとのハイブリッド構成も考えてもよいのではないかと思います。その際に昨今の流れの DX や 2025年の崖とかに対応するということで業務システムも作り直すのであればクラウドネイティブ目指してコンテナ使うとかいろいろ考えられるかもしれませんが、これはこれでそれを熟知している技術者がいないとなかなか進みません。そして時間がかかって結果として「オンプレミス更新でいいやぁ」となっちゃうこともあるでしょう。なので、そこまで一気に考えるのではなく、まずは最初に負荷の低いシステムやどうしても社内に置かなければならないシステムなどだけ HCI 使ったオンプレミスの vSphere に残し、それ以外は vSphere で動いているクラウドに移してしまうということも考えるとよいかもしれません。イメージはこんな感じですね。

f:id:imaisato:20200509230758p:plain

クラウドサービスを活用してオンプレミスの負荷を下げる

このスライドは 5/6 の「vSphere 7 へのアップグレードについて」まとめてみたのところでダウンロードできる資料の 83ページにあるものですが、vSphere を使ったクラウドであればオンプレミスの環境とうまくつないで運用できることがよくわかるかと思います。そして、クラウドに移行した仮想マシンたちは実はコンテナ型で動かせるかもしれない候補ではないかと考えて構成の変更を考えてみる。それで「いけそう!」となったらコンテナに部分部分移行していく。こんな感じでクラウド上でいろいろと変えてクラウドに適した形にしていくことが「クラウドネイティブ」になるわけですね。別にコンテナだけがクラウドネイティブではなくて、今までの仮想マシン型のものも含めてクラウドをうまく活用するのが「クラウドネイティブ」で、そしてオンプレミスに残しているのと連携するようにしていくのが「ハイブリッドクラウド」、つまり今言われているいろいろな言葉はそれを「作る」のではなく変えていった結果がそれになったというほうが、IT担当者もユーザーも負担なく移行・実現できるのではないかと思います。
-----

ニフクラ アイコン&シンボル

私のブログの資料で使っているアイコンやシンボルですが、ニフクラが公開している素材を使っています。こちらからダウンロードできますので「使ってみたい」方は是非ご利用ください。(今日時点ではまだ 2018年10月3日版ですが、そのうち新しいアイコンが追加されたものに変わると思います。)

pfs.nifcloud.com