[VMware] vSphere 5.5のサポート終了について

 

おそらくまだまだ本番環境で現役として運用中であろうvSphere 5.5のサポート期間が今年(2018年) 9月19日で終了します。

vSphere 5.5 and vSAN 5.5 End of General Support Reminder

正式には”ジェネラルサポートの終了-End of General Support (EOGS) “になりまして、その後2年間の”テクニカル ガイダンス-Technical Guidance”期間に入るため、まあ~最悪2020年9月19日までは引き続き利用可能とも言えます。ただし”ジェネラルサポート”で提供するメンテナンス アップデートやアップグレード、不具合とセキュリティの修正がなくなるため、EOGS以降発生するバグや脆弱性に対する対応が難しくなります。

 

もちろんEOGSの前にvSphere 6.xにバージョンアップすることがベストですが、予算なども含め検討が必要かと思います。

 

Lifecycle MatrixによるとvSphere(ESXiとvCenter) 5.5に合わせ、以下のプロダクトも同じく2018年9月18日でEOGSを迎える予定となってます。

  • Cisco Nexus 1000V
  • Integrated OpenStack 3.1
  • Site Recovery Manager 5.5、 5.8
  • vCenter Server Heartbeat 6.6
  • vCenter Update Manager 5.5
  • vRealize Automation 6.2.5 Advanced/Enterprise Edition
  • vSAN 5.5 🙂

  • vSphere Data Protection 5.5、 5.8
  • vSphere Storage Appliance 5.5

 

広告

[VMware] vRealize Automationの導入 (17)

 

(0) vRAの概要
(1) vRAのコンポーネント
(2) vRAのインストール
(3) テナント作成
(4) Active Directoryの追加
(5) エンドポイントの作成
(6) ファブリックグループの作成
(7) マシンプリフィックス/ネットワークプロファイルの作成
(8) ビジネスグループの作成
(9) 予約/予約ポリシーの作成
(10)ブループリント作成
(11)サービスカタログの作成
(12)ブループリントのリクエスト
(13)承認ポリシーの作成
(14)カスタムプロパティの作成
(15)vROエンドポイントの作成
(16)イベントブローカーの設定
(17)NSXとの統合

 

お久しぶりです。;)

今回はNSX for vSphereを統合する手順を紹介します。vRA 7.0以降NSX関連情報が増えてきています。理由はもちろんNSXの導入が増加しているためでしょう。多くの企業がNSXの検証を終え、本番環境への導入も増えてきています。少々古い情報ですが2016年だけで約2,400社がNSXのライセンスを購入しているとの発表がその根拠かなと…

で、NSXを統合する理由は?というともちろんvRAのブループリントでNSXの機能が利用できるからです。:)

 

(17)NSXとの統合

 

① [インフラストラクチャ] → [エンドポイント]順位クリックします。

 

② [エンドポイント]を選択し、[新規] → [ネットワークおよびセキュリティ]の[NSX]をクリックします。

※ちなみにvRA 7.2までは、下図のようにvCenterエンドポイントの一部して設定する形でした。

 

 

③ [全般]タブより、必要情報を入力し、[接続をテスト]をクリックします。

  • 名前 : NSXエンドポイント名
  • Address :  NSX ManagerのURL
  • User name : NSX Managerの管理者アカウント
  • パスワード :NSX Managerの管理者アカウントのパスワード

 

④ 自己証明書の警告を確認後、[OK]をクリックします。

 

⑤ 接続テストが成功したことが確認できたら、[関連付け]タブをクリックします。

 

⑥ [新規]をクリックし、名前のプルダウンメニューからvCenterのエンドポイントを選択し、[OK]をクリックします。

※ これは、既存のvCenterエンドポイントと作成したNSXのエンドポイントを紐付けるためです。vRA 7.2ではそもそもvCenterエンドポイントの一部としてNSXを統合したのでこの手順は不要でした。

 

⑦ [OK]をクリックし、エンドポイント作成を完了します。

 

⑧ では、きちんとNSXエンドポイントが作成されたか確認してみます。[コンピュートリソース] → [コンピュートリソース]順にクリックし、作成したコンピュートリソースから[Data Collection]を実行します。

 

⑨ NSXのエンドポイントが作成されるとData Collectionに”Network and Security Inventory”項目が追加れます。Statusが”成功”することを確認します。

 

⑩ 今度は[予約]の[Network]タブを見てみます。ちゃんと利用可能なネットワークとしてNSXの論理ネットワークが表示されることが確認できます。

 

これでNSXの統合手順は終わりです。次は仮想マシンをvRA管理下にできる仮想マシンのインポート方法について紹介したいと思います。

 

[VMware] Web Client接続時[400] Single Sign-Onエラーが発生する

 

先日、検証環境のvCenterに接続できなくなりました。外部PSCとVCSAの構成ですがWeb Clientで接続すると以下のようなエラーが表示され、もちろんHTML5 Clientでもダメでした。

[400] Single Sign-On サーバへの認証要求の送信中にエラーが発生しました – null

 

エラーコードとメッセージからSSOに問題があるようで少々調べましたが中々解決できませんでした。このようなSSO関連エラーはVCSAとPSC間の時刻ズレが原因の場合が少なくないのでそれぞれ時刻を確認してみましたが同じでした。色々試しましたが埒が明かず、バックアップデータもありませんでしたので’もうインストールし直しか’と諦めかけてましたが以下の方法で何とか復旧できました。

 

まず新たにPSCをデプロイしました。デプロイ時のSSO構成は、問題(があるように思われる)のPSCのSSOに参加するオプションで。

新PSCデプロイ後、VCSAから以下のコマンドでre-pointを実施。

root@k-vc02 [ ~ ]# cmsso-util repoint –repoint-psc k-psc04.kiiro.local
Validating Provided Configuration …
Validation Completed Successfully.
Executing repointing steps. This will take few minutes to complete.
Please wait …
Stopping all the services …
All services stopped.
Starting all the services …
Started all the services.
The vCenter Server has been successfully repointed to the external Platform Services Controller k-psc04.kiiro.local.

 

再度Web Clientにアクセスしたところ、復活!

VCSA上でPSC情報を確認したところ、表示されるのは新しくデプロイしたPSCのみでした。

root@k-vc02 [ ~ ]# /usr/lib/vmware-vmafd/bin/vmafd-cli get-ls-location –server-name localhost
https://k-psc04.kiiro.local:443/lookupservice/sdk

 

インベントリ情報など問題ないことを確認し、問題(?)のPSCを停止して一件落着みたいな…

色々とイジりまくってた時におかしくなったんですかね。 汗

 

ちなみに以前から同僚からもお客さんからも”組み込みPCS”と”外部PSC”の使い分けは?って聞かれますがこちらの「Platform Services Controller (PSC) FAQ」に明記されています。

If you want/need Enhanced Linked Mode (e.g. multiple vCenter Servers in the same vSphere SSO Domain) you have to use an external PSC.

要は”拡張リンク モード”を使う場合は”外部PSC”ということです。さらに…

There could be a product that recommends and external PSC for some reason. But outside of that there is really no benefit to running an External PSC without Enhanced Linked Mode.

“拡張リンク モード”を使わないと”外部PSC”はあまりメリットがないとのことです。 🙂

 

 

[VMware] vSAN 6.6 環境でovfテンプレートのデプロイが失敗する

 

先日同僚から共有してもらった内容です。

vSAN 6.6の環境においてovfテンプレートをデプロイしようとすると失敗する場合があります。

The operation is not allowed in the current state

 

■ 原因

vSAN 6.6の既知のバグのようです。リリースノートを確認すると既知の問題として挙げられています。

vSAN クラスタに OVF テンプレートをデプロイする場合、vSAN クラスタ上で DRS が無効になっていると操作は失敗します。次のようなメッセージが表示されます:The operation is not allowed in the current state。

 

この問題は6.6.1でも解消されておらず、リリースノートにも載っています。

 

■ 解決方法

リリースノートではDRSを有効にしろって書いてあります。恐らくovfデプロイ時DRSの推奨値を適用しようとする動きをしているためかと思われますが問題はDRSはEnterprise Plusエディションでの機能のため、Standard以下のエディションの場合はそもそもこのワークアラウンドは使えないことです。

 

もちろん初期構築時は評価ライセンスのため問題ありませんが、一旦正規ライセンスを適用してからだとややこしくなります。 :) その場合はESXi Host Clientからデプロイすることで回避できますのでご参照ください。

 

 

[ETC] Intel CPUバグによる脆弱性について

 

年明け早々、厄介な脆弱性で盛り上がってます。:)

共通脆弱性識別子(CVE – Common Vulnerabilities and Exposures)として以下の脆弱性が公開されました。脆弱性の内容はCPUアーキテクチャ関連バグに関するものです。

 

CVE-2017-5753とCVE-2017-5715は別名”Spectre“、CVE-2017-5754は”Meltdown“という別名となっていて両方共に非常に深刻なバグのようです。

“Meltdown”は1995年以降リリースされたIntel CPUのすべての世代がバグの影響を受け、このバグによりカーメルメモリ情報が読み取れてしまうリスクがあるとのことです。カーネルメモリ情報に関連するため、アンチウィルスソフトアや暗号化でも防げないとのことです。(“Meltdown”はAMD社のCPUでは影響を受けないようです)

“Spectre”は任意のプログラムによりユーザプログラムのメモリ情報が読み取られてしまうバグとのことです。どっちも深刻ですが”Meltdown”の方がよりヤバそうです。

 

しかも上記2つのバグを修正するためのパッチが適用するとCPUのパフォーマンスが最大30%低下してしまう検証結果が報告され益々炎上しているようで、Intel社から本バグについて言及し’うちだけの問題じゃない、他社CPUでも起こりうる。修正パッチの影響もそんな大げさなことではない’としていますが事態は収まりそうもないようです。

 

リスクの対象が過去10年間リリースされたIntel CPUなため、その影響範囲は膨大でGoogle社やMicrosoft社、Amazon社、RedHat社などでは早速対応を公開しています。

 

VMware社も関連内容を公開し”Spectre”に対するパッチも公開しましたが”Meltdown”については以下のようなコメントのみ、パッチはありませんでした。

A third issue due to speculative execution, Rogue Data Cache Load (CVE-2017-5754), was disclosed along the other two issues. It does not affect ESXi, Workstation, and Fusion because ESXi does not run untrusted user mode code, and Workstation and Fusion rely on the protection that the underlying operating system provides.

ESXiは未信頼ユーザモードのコードを実行しないし、WorkstationとFusionはOSが提供する保護機能に依存しているため”Meltdown”の影響を受けないとのことみたいです。

 

一部では2014年OpenSSL関連バグで業界を騒がせた”Heartbleed“を凌ぐインパクトがあると言ってますので、しばらく注意深く各ベンダーの対応状況をチェックした方が良いかもしれません。

 

[VMware] vSAN 6.2 Essentials 無料公開

vSAN界では有名な人物が2人います。Cormac HoganさんとDuncan Eppingさんがその2人です。

お2人ともにVMware社のSABU(Storage & Availability Business Unit)のCTOでありながらvSphere Clustering関連やストレージ、vSAN関連の有益な情報を数多く紹介しています。いつもお世話になっております! 🙂

 

この2人が執筆したEssential Virtual SAN (VSAN): Administrator’s Guide to VMware Virtual SANのvSAN 6.2対応版であるこの本を無料で公開してくれました。

Holiday gift: vSAN Essentials book available for free

vSAN Essentials e-book is now free

 

300ページに渡りアーキテクチャーをはじめインストール、ストレージポリシー、管理・運用、そしてトラブルシューティングまでvSANのすべてをカバーしています。vSAN 6.2版ではありますが、殆どの部分は現在でも十分活用できる内容ですのでvSANの管理者やこれからvSANを導入しようとする方には必読かもしれません。:)

 

改めてCormac HoganさんとDuncan Eppingさんに感謝の気持ちを伝えたいですね。:)

 

[VMware] vExpert 2018 応募開始

 

vExpert 2018の応募が開始されました。

vExpert 2018 Applications are Now Open

 

今年からはvExpert専用のポータルも用意され、応募もこのvExpert専用ポータルから行います。

 

vExpertになるとvExpert専用Slackチャネル参加やvExpert認定書、1年間の評価ライセンスなどのVMware社提供をはじめ、様々な3rdパーティが提供するメリットがあります。

Andrea Mauroさんのまとめ : vExpert 2017 Benefits

 

応募期間は2017年12月19日から1ヶ月間で、受賞者発表は2018年2月16日となっています。

 

2017年、VMware製品やテクノロジーに普及に貢献した方、VMware Loveな方は是非応募してみてください。:)