みなさま、こんにちは、VMware の知久です。
この連載では、VMware のマルチクラウド戦略の中心アーキテクチャである VMware Cloud Foundation がどの様な製品で、どの様な価値をお客様に提供するのかを改めてお伝えしています。
前回の連載では、VMware Cloud Foundation の特徴を特定のトピックに絞ってお伝えしておりましたが、先日にVMware Cloud Foundation のメジャーバージョンアップである、VMware Cloud Foundation 5.0がリリースされましたので、今回は本編は一旦休止し、番外編 ということで VMware Cloud Foundation 5.0の中身についてお伝えさせて頂きます。
1. サポートライフサイクルポリシーの変更
VMware Cloud Foundation 5.0の機能のお話の前に、当バージョンから VMware Cloud Foundation の製品のサポートライフサイクルポリシーが大きく変更になっていますので、そちらからお伝えしていきます。
・従来のサポートライフサイクルポリシーである N-2ポリシー
VMware Cloud Foundation 4.xでは VMware のサポートライフサイクルポリシーの一つである、N-2 ポリシーが適用されています。
N-2ポリシーでは、最新のメジャー、もしくはマイナーバージョンがリリースされてから12ヶ月、もしくは三世代先の最新リリースが提供されたタイミングのどちらか長い方がGeneral Support 期間として定義されています。つまり、General Support終了日が最新バージョンのリリースに依存するため、事前に明確なサポート終了日が不透明なため、大規模環境ではバージョンアップ計画を建てにくいという課題も存在していました。
・新しく採用された Enterprise HCI Policy (EHP)
上記の課題もあり、VMware Cloud Foundation 5.0 から採用されたのが、Enterprise HCI Policy です。
EHP では vSphere や NSX 等の製品と同様に、メジャーバージョンのリリースから一定期間の General Support 期間に加え、それが終了したあとに Technical Guidance の期間が準備されており、VMware Cloud Foundation 5.0 の場合には、リリース日から4年間のGeneral Support期間とその後1年間の Technical Guidance の期間が設けられているため、極端なお話をするとリリースから5年間は VMware Cloud Foundation を5.0のまま運用してもサポートされます。
ただし、上記でもお伝えしているとおり、VMware Cloud Foundation ではライフサイクル管理に伴う作業を極限まで簡素化し、常に最新のインフラを運用することで、セキュリティ面での堅牢性や、極力不具合を排除する健全性を確保する趣旨ですので、一度導入したら最後までバージョンアップしない塩漬け運用をするのではなく、定期的なアップデートを行う事を引き続き推奨しています。
図1： VMware Cloud Foundation 4.x と 5.0のサポートライフサイクルポリシーとサポート期間の違い
2. VMware Cloud Foundation 5.0の BOMリスト
VMware Cloud Foundation 4.x では中のコンポーネントに関しては、vSphere、vSAN に関しては7.0ベース、NSX は3.xで構成されていますが、VMware Cloud Foundation 5.0 のリリース前にそれぞれの製品はメジャーバージョンアップされており、VMware Cloud Foundation 5.0 では各コンポーネントもメジャーバージョンアップ後のバージョンで構成されており、vSphere、vSAN に関しては8.0 u1a、NSX は4.1.0.2が採用されています。
図2： VMware Cloud Foundation 5.0 に含まれている製品一覧 ( BOM リスト)
3. VMware Cloud Foundation 5.0 新機能
上記のとおり、VMware Cloud Foundation 5.0では中のコンポーネントもメジャーバージョンアップしているため、製品毎の新しい機能は当然追加されていますが、VMware Cloud Foundation 自体の機能も新しく追加されています。
図3： VMware Cloud Foundation 5.0 新機能ハイライト
その中からいくつか厳選して、機能の特徴をお伝えしたいと思います。
・SDDC Manager Context Aware プリチェック
VMware Cloud Foundation のライフサイクル管理機能には、運用している環境に新しいアップデートを問題なく適用出来るかを事前に確認するプリチェック機能が実装されているのは以前にもお伝えしましたが、従来のプリチェック機能は適用するアップデートには依存しておらず、現在の環境が健全な状態で、アップデート作業を実施しても問題ないかを確認する意味合いが強いものでした。
それに対して VCF5.0から実装された SDDC Manager Context Aware プリチェックでは、アップデートするターゲットバージョンを指定することが出来、そのアップデートバージョンの要件に基づいたプリチェックを実施することが可能になっています。
さらに、従来のプリチェックでは実行するとワークロードドメイン内の全コンポーネントに強制的なチェックが実施されましたが、こちらのプリチェックではチェックするコンポーネントを選択して、チェック範囲を限定することが出来、例えばアップデート計画として、この日は NSX、別の日は vCenter など細かくスケジューリングしている場合、アップデート前に実行するプリチェックも個別に行えるため、時間の短縮や作業効率が向上します。
SDDC Manager Context Aware プリチェックの実装に伴い、従来に比べてより厳密な確認や作業効率化が可能になります。
図4： VMware Cloud Foundation 5.0 プリチェック時のターゲットバージョンと対象範囲選択画面
図5： VMware Cloud Foundation 5.0 プリチェック実行結果の表示画面
・Configuration Drift Awareness
つづいてご紹介するのが Configuration Drift Awareness の機能です。
そもそも Configuration Drift とは？と言うことですが、従来から VCF ではバージョンリリース毎に新機能に伴う構成変更の要素が Configuration Drift として、アップデートバンドルに含まれています。従来の VCF ではその Configuration Drift はどのような変更内容か中身もよくわからず、またアップデートすると問答無用で適用されてしまったのですが、VCF5.0では使用可能な構成の更新という項目が追加され、そこに適用可能な Configuration Drift の内容が表示され、アップデート後に必要に応じて適用するかを選択することが出来るようになっています。
この機能によって構成変更内容の可視化であったり、環境に合わせた構成の柔軟性が向上します。
図6： VMware Cloud Foundation 5.0で実装された Configuration Drift 確認画面
・SSO が分離されたワークロードドメイン機能とワークロードドメイン数の上限の向上
続いてご紹介するのが SSO が分離されたワークロードドメインの機能です。
前回お伝えしたように、VMware Cloud Foundation では、vCenter や NSX Manager などの管理系ワークロードを稼働させるためのマネジメントドメインとユーザー用ワークロードを稼働させるワークロードドメインの二種類のドメインを用いて管理します。
従来の VMware Cloud Foundation ではユーザー用のワークロードドメインは作成時にワークロードドメイン毎に vCenter が展開され、マネジメントドメイン構成時に作成された SSO に全て拡張リンクモードでぶら下がるため、拡張リンクモードの制限により1個のマネジメントドメイン + 14個のワークロードドメインが最大ドメイン数となっていました。
VMware Cloud Foundation 5.0 から実装された SSO が分離されたワークロードドメイン機能では、マネジメントドメインで構成された SSO とは別の SSO を構成し、そこに任意のワークロードドメインをぶら下げる事が可能になっています。
これにより、SSO を分離した構成が必須にはなりますが、VMware Cloud Foundation で構成可能なワークロードドメイン数の上限が最大で25個まで引き上げられるのと、従来ではサポートされていなかった Perpetual / Term ライセンスとサブスクリプションライセンスの混在がサポートされるようになります。
さらに SSO が分離されることによってアカウント管理も明確に分離出来るため、マルチテナント利用を想定した構成をとりやすくなります。
図7： SSO が分離されたワークロードドメイン機能を活用したワークロードドメイン構成例
・4.x から 5.0 へのインプレースアップグレードのサポート
最後は新機能とは少し異なりますが、既存環境から VMware Cloud Foundation 5.0 へのインプレースアップグレードについてお伝えします。
2020年に VMware Cloud Foundation 4.0 がリリースされた当時、実はインプレースアップグレードには対応しておらず、既存の VMware Cloud Foundation 3.xの 環境を 4.0にするには、別のハードウェアに4.0の新環境を構成し、既存環境から仮想マシンを移行する必要性がありました。
その後、4.3.1のリリースでようやくインプレースアップグレードに対応しましたが、それを実行するには VMware の技術アセスメントを事前に受ける必要があるなど、中々敷居も高く、3.x から 4.x へのインプレースアップグレードは大きな課題でした。
その様な反省点も踏まえ、VMware Cloud Foundation 5.0 では最初から 4.xからのインプレースアップグレードをサポートしています。
さらにアップグレード元のバージョンに関しても幅広く、4.3以上であれば、直接5.0にアップグレードする事が可能になっていますので、現在4.3を運用されている方で、EOGSに伴うアップデートを検討されている方は、4.5.xでなく、一足飛びで5.0へアップグレードするのも視野に入れて頂いても良いかと思います。
図8： VMware Cloud Foundation 4.x から 5.0へのインプレースアップグレードパス
まとめ
さて、今回は番外編ということで、VMware Cloud Foundation 5.0の変更点や新機能についてお伝えしましたが、サポートライフサイクルポリシーの変更やプリチェックの大幅な強化によって、VMware Cloud Foundation 5.0では、従来に比べて運用の柔軟性や効率性が大きく向上しています。
さらにインプレースアップグレードの対応によって、既存の環境のアップデートもかなり敷居が低くなっていますので、VMware Cloud Foundation 4.x をお使いで次回のアップデートをご検討されている方は、5.0へのアップデートを検討されてはいかがでしょうか？
次回は引き続き番外編２として、今回お伝えした4.xから5.0へのインプレースアップグレードを実際に試し、注意点や考慮点などをお伝え出来ればと思っています。
