vSphere 7について調べてみよう その６（HAProxyを利用したvSphere Tanzuについて）

 今回は、vSphere 7 Update1で可能となったHAProxyを使用したvSphere Tanzu

についてのお話となります。

いままでは、vSphere Tanzuを利用するにはNSX-Tが必要となっておりその分の

リソースとライセンス費用を別途用意しなくてはなりませんでした。

しかし、HAProxyを使用する場合はvCenterとESXiのみで構築が可能となります。

詳細はマニュアルをどうぞ

 https://docs.vmware.com/jp/VMware-vSphere/7.0/vmware-vsphere-with-tanzu/GUID-152BE7D2-E227-4DAA-B527-557B564D9718.html

  →vSphere with Tanzu のネットワーク

   →vSphere ネットワークと HAProxy ロード バランシングを使用して スーパーバイザー クラスタ を設定するためのシステム要件およびトポロジ

   ※なぜか、マニュアルの中のリンクをたどると表示してくれないので、pdfをダウンロードした方が良いと思います。

マニュアルの内容を簡単にですが説明すると以下のような流れになります。

１ 分散仮想スイッチを作成し以下のポートグループを用意する

   ・管理用ポートグループ

   ・1つ目のワークロード用ポートグループ（スーパーバイザークラスター(SCP)で使うネットワーク）

   ・2つ目のワークロード用ポートグループ（Tanzu kubernetes Cluster(TKC)のノードで使うネットワーク）

   検証等するのであれば、管理用とワークロード用のネットワークを/24で2つ用意し、ワークロード用のネットワークは分割して使うのがいいと思います。

   ポートグループとして用意するわけではありませんが、SCPやTKCのVIPなどとなるロードバランサー用IPレンジも必要となります。

   VC1台、ESXi4台の例としては以下の様な割り振りです。

   

   管理用(192.168.1.0/24)

    VC 192.168.1.10

    ESXi1～ESXi4 192.168.1.11～192.168.1.14

    HAProxy 192.168.1.20

   ワークロード用(192.168.10.0/24)

    ロードバランサー用IPレンジ  192.168.10.144/28

    1つ目のワークロード用ポートグループ 192.168.10.160/28

    2つ目のワークロード用ポートグループ 192.168.10.192/28

    ※/28としていますが、あくまで範囲を指定するだけの用途となりサブネットが/28で設定する必要があるわけであありません。

２ コンテンツライブラリの作成を行い、TKCのノードとして使用するOVAのダウンロードをしておく

３ OVAでHAProxyをデプロイする

４ ワークロードの有効化をする

５ 名前空間を作成する

   →作成時に名前空間で使用するネットワークはnetwork-2(2つ目のワークロード用ポートグループ)を指定する。

６ yamlからTKCの展開を行う

これで成功すれば構築完了です。

ですが、そのままだとPodの作成はできるものの、deploymentで展開をしようとするとエラーとなります。

実は、構築した状態ではPod Security Policy(PSP)によって作成できないようになっています(権限がない状態)。

そのため、権限の変更を行ってあげる必要がありますが、この辺の操作もすべてkubernetesの知識を元に行うことになります。

また、NSX利用時と異なる点もあります。

ワークロードの有効化をして名前空間を作成することはできますが、名前空間にyamlからPodの作成はできません。

ユーザーが利用するPodが展開できるようになるには、TKCの名前空間を利用する必要があります。

作るのも設定するのも現状はvSphere＋kubernetesの知識と経験が十二分に必要な状態です。

あと、HAProxyに何か問題があったときどこの誰が対応してくれるのかについてはわからない(VMがサポートしてくれるのか不明)

という部分もあり、なかなか難しいなと思いました。

vSphere 7に関して調べてみよう その5 vSphere Lifecycle Manager(vLCM)

 今回は、vCenter Update Manager(VUM)の後継に当たる機能「vSphere Lifecycle Manager(vLCM)」について調べてみました。

VUM自体はESXiのパッチを管理する機能として登場し、機能拡張でゲストOSのパッチも管理する機能が追加された

ことがあったと思いますが、一瞬でその機能がなくなったのは不評だったんでしょうねぇ。

個人的には、使う人は使うけど使わない人は使わない(esxcliとかコマンドを使う)という印象。

勝手にパッチをダウンロードしてきたり、勝手に当てられたりしたら困るという印象が強いんじゃないかと思います。

設定次第なんですけどね。

では、いつもどおりVMwareのブログを読んでいきたいと思います。

https://blogs.vmware.com/vsphere/2020/04/vsphere-7-patching-lifecycle-management.html

VUMと機能違いとしては以下のようです。

 ・ホストベンダーのアドオン(OEMで追加されているパッケージ)にも対応した

 ・対応しているベンダーのファームウェアやドライバにも対応した

 ・適用単位がクラスター単位となった。

機能が追加され、クラスタ単位で統一性を保ちましょうという考え方になったようです。

今のところNSXの管理には対応していないようですね。

以前あったゲストOSのパッチ管理は、既に他の製品(WSUS等)で行うことが浸透していたこともありましたが、

ハードウェア方面は構築時のままということもあるでしょうし、この機能で確認や管理、修正が簡単に

行えるようになれば良いなとは思います。

ただ、出たての機能(安定して使えるかどうか不明)であることと、ダウンロードする場合インターネットに

つながっていないといけないのがセキュリティ的に容認されない場合が多いんじゃないかというのがネック

になってくるんじゃないでしょうか。

今月は以上になります。

vSphere 7に関して調べてみよう その４Assignable Hardware

 今回は「Assignable Hardware」について調べてみました。

ハードウェアとあるので、ハードウェアの機能を何かしら補助したり使用したり

す機能なのでしょう。

ということで、以下のVMwareブログを読んでみます。

      Assignable Hardware

       https://blogs.vmware.com/vsphere/2020/03/vsphere-7-assignable-hardware.html

chromeの翻訳機能を使うと冒頭から以下のような、具体的に何のことかよくわからないよくある感じの文章・・・

----

多種多様な最新のワークロードは、ハードウェアアクセラレータを使用して特定の機能をオフロードし、CPUサイクルを節約し、一般に多くのパフォーマンスを得ることができます。たとえば、通信業界について考えてみましょう。NICとFPGAを利用したネットワーク機能仮想化（NFV）プラットフォーム。または、仮想デスクトップインフラストラクチャ（VDI）の展開でグラフィックアクセラレーションにGPUを使用しているお客様。AI / ML空間は、アプリケーションが使用するようにイネーブルされるワークロードの他の例であるオフロードの計算にGPUをします。vSphereでハードウェアアクセラレータ（通常はPCIeデバイス）を利用するには、デバイスを仮想マシン内で実行されているゲストOSに公開する必要があります。

----

くじけそうになりますが、この下にある文章も読んでみるとこの機能が何をもたらそうとしているのかがなんとなくわかります。

何が書いてあるかというと、『今までもハードに紐ついた機能を仮想マシン等に提供することはできました。

しかし、そのようなハードに歩もついた機能を仮想マシンに利用させた場合、vMotion等が行えません。

これは、DRSでのロードバランスや、仮想マシンが動作しているESXiに何かがあって停止してしまった場合の

HAなどが使えず、同様のことを行おうと思ったときに、人の手によって作業をしなければなりません。』という感じの内容です。

今回の「Assignable Hardware」はそこにメスを入れるための機能であるようです。

今までvmxに直接書き込まれていたPCIeデバイスのハードウェアアドレスが書き込まれなくなり、代わりに仮想マシンがどのような機能を利用しているかが公開され、必要なハードウェア機能を持っているESXi同士であれば仮想マシンの移行が可能となるようです。

また、この機能を使用してNVIDIA vGPUを仮想マシンに提供できるようです。

使うためにはホストのグラフィック設定を有効にしたり、VIBの導入をしたり、NVIDIAのドライバーを設定したりと現状ではなかなか骨が折れそうな作業のようですね。

今回は以上になります。

vSphere 7に関して調べてみよう その３改良されたDRS

vSphere 7で改良されたDRSについて調べたことを記事にしたいと思います。

この記事は以下の情報を参考にしています。

       https://blogs.vmware.com/vsphere/2020/03/vsphere-7-improved-drs.html

       https://blogs.vmware.com/vsphere/2020/05/vsphere-7-a-closer-look-at-the-vm-drs-score.html

DRSはクラスタ内のホスト上で動作する仮想マシンの負荷の偏りを計算して、閾値を上回った場合に仮想マシンの移行

を自動で行う、または移行の推奨を表示する機能です。

仮想マシン起動時にどのESXiで起動するのが良いかについても計算し、バランスよく仮想マシンを自動もしくは手動で

配置することもやってくれます。

以前のDRSは、各ESXiの負荷が偏っていないかどうかという観点で5分に1回計算を行い、移行するかどうかの判断を

行っていました。

また、DRSの計算が行われる際、負荷の要素としてはCPUとメモリが利用されていました。

何処が変わったかについてですが、以下があげられます。

  １．クラスタ内の各ESXiで消費リソースの偏りを見ていた点

      → 各ESXiでDRSスコアの計算を行い、そのスコアが最も高い(余裕がある)ESXiに仮想マシンを移動させる。

      

  ２．DRSの計算が5分に1回 → 1分に1回に頻度がアップ

  ３．DRSの計算に使われる要素はCPUとメモリ → CPUとメモリに加えてネットワークの使用量が追加

それぞれ調べたことや思ったことについて以下に書いておきます。

  １．DRSの仕組みが変わった点について

      新しくなったDRSの考え方についてですが、以下の式となっているようです。

      

      Goodness (actual throughput) = Demand (ideal throughput) ? Cost (loss of throughput)

      Efficiency = Goodness (actual throughput) / Demand (ideal throughput)

      Total efficiency = EfficiencyCPU * EfficiencyMemory * EfficiencyNetwork

      Total efficiency on host = VM DRS score

      Demand(理想のスループット状態)からCost(失ったスループット)を引いた値が「Goodness」

      「Goodness」を「Demand(理想のスループット状態)」で割ったのが「Efficiency」

      

      Efficiencyは効率という意味ですので、どのくらい効率の良いスループット状態なのかを表す数字だと思います。

      そしてメモリ、CPU、ネットワークのEfficiencyをそれぞれ掛け算したもを、トータルのEfficiencyとみている

      ようです。

      これで仮想マシン単体での効率が計算しているということなのでしょう。

      

      稼働するESXiホスト上でこの計算を行った結果がDRSスコアということなのですが、この計算の正確な意味を考え

      てもしょうがないのでそういう考え方かというくらいでいいと思います。

      人間の考える理想の負荷状況とは異なるでしょうし、このスコアを使うのはDRSであって人間ではないですから。

      このスコアが低く(閾値に引っかかる状態)、別のESXi上に移したほうがよいスコアになるとDRSが結論を出したと

      きにvMotionを行うわけですが、vMotionの実施にもコストがかかり移行した際の効率上昇よりvMotionで消費され

      るリソース消費の方が高いという場合も起こりえるでしょう。

      

      DRSはこの辺も考えて、移行にかかるリソース消費の方が高くなる場合vMotionは行わないようです。

      スコアが低いのに動いてない仮想マシンは、そのように判断されたということですね。

  ２．DRSの計算頻度が変更されたことについて

      DRSの計算頻度が5倍になったということは、完全自動にしている場合は5倍vMotionがされる可能性もあるので

      そういう動きやすい仮想マシンは、DRSのルールでESXiから移動しないようにするなど配慮が必要になるかもしれ

      ませんね。

      ここは、使う側の好みが分かれそうです。

  ３．DRSの計算に使用される要素としてネットワークが追加された点について

      具体的にはどういうことかというと、ネットワーク帯域の使用量がDRSの計算に組み込まれています。

      ネットワーク帯域の使用量が高く他のESXiに移したほうがいい場合は結構あると思いますし、良いかなと思います。

      メモリ、CPU、ネットワークときましたので、いつかはストレージのI/Oも見て計算するようになるのかなぁと思い

      ますが、その場合は各計算要素について優先順位を付けれるといいですね。

      メモリとCPUだけ見てほしかったり、ネットワークだけ気にしたかったりとそういう状況に合わせられると更にいい

      と思います。

今回は改良されたDRSについてでした。

vSphere 7に関して調べてみよう その２改良されたvMotion/Storage vMotion

 vSphere 7で改良されたvMotion/Storage vMotionについて調べたことを記事にしたいと思います。

この記事は以下のVMwareのブログを参考にしています。

  https://blogs.vmware.com/vsphere/2020/03/vsphere-7-vmotion-enhancements.html

  https://blogs.vmware.com/vsphere/2020/06/vsphere-7-storage-vmotion-improvements.html

vMotion

vMotionは私がVMware製品と関わり始めた新人のペーペーだった頃(まだVCがVirtual Centerと呼ばれていた時代)から

存在するもはや皆さんご存じの代表的な機能だと思います。

動いてる仮想マシンを、ESXiから別のESXiに移動させるすごーい機能ですね。はい。

そもそも、どうやってそんなこと実現してるのかというと、移行元ESXiのメモリ上にある仮想マシンのデータを

vMotionを有効にしたvmkernel経由で移行先ESXiに渡しています。

と、この辺まではみなさんご存じではないでしょうか。

今回、先にご紹介したブログにvSphere 6.7までのvMotionの仕組みも解説されていまして、

それを読んでみますと、準備段階として、仮想マシンのvCPUにメモリ状態をトレースするツールをインストール

します。

これは、vMotion中に行われた変更を移行先ESXiにも送らないといけないからです。

もうちょっと詳細に書くと、メモリのどの部分が変更されたのかを追いかけてその情報を送信しないといけないからです。

vMotionが開始されると、そのツールのを使ってメモリ情報の更新を追いかけていくわけですが・・・

このときに従来のやり方では、仮想マシンのvCPUを一瞬(マイクロ秒らしい)停止させるという動きをしていたようです。

新しいvMotionは、全部のvCPUではなくvCPUを一つだけにして他のvCPUは処理を継続できるように改良したそうです。

これは、モンスターVM(ものすごいスペックの仮想マシン)をvMotionする場合を想定し、処理が中断しないように

するためのようです。

Storage vMotion

仮想マシンの各種ファイルは通常データストア内に存在します。

vmx、vmdk等々ですね、これらのファイルを元のデータストアから別のデータストアに移すのがStorage vMotionですね。

こちらにも、vMotion同様モンスターVMへの対応で改良がくわえられたようです。

改良がくわえられたのはFast Suspend and Resume（FSR）という機能です。

Storage vMotionは仮想マシンがホストを移動しませんが、実は同じホスト上で宛先となる仮想マシンを作成しそちらの

マシンに切り替えを行うのですが、その際にデバイスの状態とメモリデータの転送を同じホスト上で行う機能です。

FSRが処理を行うために要求されるvCPUは1つとなりますが、一時的にすべてのvCPUがスリープ状態になっていたようです。

小さい仮想マシンであれば影響は少ない(1秒以内？)ようですが、モンスターVMになれば・・・お察しですね。

どう改良されたのかについてブログの内容を確認しますと、面白いことにvMotionとは逆で1つのvCPUから全部のvCPUを

使って処理を行うことで処理の効率化を行い、ブログにもありますが、メモリ1TBとvCPU48個の仮想マシンで

かかる時間が7.7秒→500ミリ秒に短縮されたようです。

今回はvMotionとStorage vMotionの改良についての内容でした。

次回はRDSの改良について調べたいと思います。

vSphere7に関して調べてみよう その１構成の上限

vSphere7がリリースされ最近早くもUpdate1もリリースされたようです。

この世界のスピードには相変わらずついていくことができませぬ。

そんなSEが私一人ではないと思いたい・・・

とはいえ、なんだかんだと、そんな私でもSEを10年以上続けられたという事実がございます。

それは、ひとえに、どこの誰かは存じませぬが私が知らない情報をまとめてネットで見られるように

してくださった同じSEの方々がいらっしゃったから。

そんな私ですが、vSphereに関しては長いことついあってきた製品であり、少しばかり知見があります。

しかしながら、元となっている知識が3系、4系、5系と古くここらで改めて最新の知識を得ておくべきと

思い、vSphere7 についてあれこれ調べていくシリーズをブログでやっていこうと思いました。

今月のこの記事を第一回として毎月1本のペースで3月までブログを書いていきたいと思います。

まず、vSphere7でどんな新機能が追加されたのかですが以下のサイトを確認しました。

  Introducing vSphere 7: Features & Technology for the Hybrid Cloud

   https://blogs.vmware.com/vsphere/2020/03/vsphere-7-features.html

  

  大きくアピールされているのは以下の機能のようですね。

   ・vSphere with Kubernetes

   ・Improved Distributed Resource Scheduler (DRS)

   ・Assignable Hardware

   ・vSphere Lifecycle Manager

   ・Refactored vMotion

   ・Intrinsic Security

  

  このほかにも、仮想ウォッチドックなどの新しい機能があるようです。

  vSphere with Kubernetesについては、少し前に記事にしたのでこのシリーズでは取り扱いません。

  上記の残りの5を来月から記事にしていきたいと思います。

では、今月は何かといいますと。。。

私が個人的に気になる、新しいOSのサポートとVC/ESXi/仮想マシンの上限の値について調べておきたいと思います。

いつの間にか『構成の上限』がPDFから検索サイトになっていたで見つけるのに苦労しました。

サイトの構成も結構変更するのでこの辺の目当ての物を見つける作業は結構慣れが必要かと個人的に思います。

  「VMware Configuration Maximums」

    https://configmax.vmware.com/home

    Select Productで「vSphere」を選択し、「Select Version」で見たいバージョンを選択。

    最後に、「All Categories」から見たい項目(複数選択可)を選ぶと見れます。

    

    仮想マシンのCPU(256→768)やメモリ(6128GB→24TB)がvSphere7 U1からすごく強化されていますが・・・

    これを必要とするマシンっていったい何を動かすんだろうとそっちが気になるｗ

一方、ゲストOSサポートは新しく追加されたものはほとんどないようですが、Tech PreviewやLegacyの

状態になっていたものが取り払われているように見えます。

しかし、実際は状況は変わってない(表記漏れ)かもしれないので、LegacyやDepricatedの物については

要注意が必要かと思います。

話はそれますが、最近は仮想マシンにandroidのOSを入れられるようで、開発もこっちでやってたり

するんですかねぇしみじみと時間の流れを感じます。

 「VMware Compatibility Guide」

   https://www.vmware.com/resources/compatibility/search.php

来月は、vMotionの改良について調べたいと思います。 

vSphere7 with kubernetesってなにさ?

 今回は、vSphere7からの新機能となる、vSphere with kubernetesについての情報となります。

 vSphere with kubernetesとは？

  kubernetesをvCenter配下のESXi上に組み立ててネットワーク部分をNSX-Tでやりましょうという製品になります。

  kubernetesって？ という方もいるかと思いますが、端的にいますとDockerホストをクラスタリングして耐障害性等を備えたものになります。

 vSphere側からkubernetesの操作ができるようになる？

  kubernetesをESXi上でというと、vSphere Clientからkubernetesの操作ができるかと思いがちですが、vSphere Clientからは基本的に表示された情報を見ることしかできません。

  kubernetesに対してPod(仮想マシンに相当するもの)を作成したり、Sevice(仮想スイッチに相当するもの)を作ったりするのは、yamlという設計書のようなファイルを用意してコマンドで実行する必要があります。  

vSphereの知識と経験で行えるのは環境の構築までとなります。

  つまり、もともともkubernetesを使っていた人がESXi上でもkubernetesを使えるようになりますよというお話のようです。

  この辺は、VMware Integrated OpenStackと似たような立ち位置ですね。

  ESXi上にkubernetes環境を移すことで何が良くなるかについて考えてみましたが、kubernetes管理者が物理の管理をしなくていいということでしょうかね。

  それも、kubernetes管理者とvSphere管理者が異なる場合になりますが・・・

 vSphere with kubernetesに必要なものは？

  マニュアルの要件を見てみましょう。

   https://docs.vmware.com/jp/VMware-vSphere/7.0/vmware-vsphere-with-kubernetes/GUID-B1388E77-2EEC-41E2-8681-5AE549D50C77.html

  

  最初に見たときは、驚きましたね・・・

  仮想環境に用意して確認しようかなと思ったんですが、とてもじゃないですが用意できませんｗ

  このレベルで環境持ってない場合は考える必要がないんだなと、ある意味潔い気持ちになります。

  実際の環境ではVCFという構成であることが大前提のようで、なかなかハードルが高い・・・

  

  さらに、ライセンスも通常と異なるようで、注意が必要です。

  そして別途NSX-Tも必要と考えると・・・

    

 でもでも、VMware製品にかかわるSEとしては、ちょっとくらいは触れておきたいと思ったあなた。

 今回も、、、ありましたよ、ハンズオンラボ。(https://labs.hol.vmware.com/HOL/)

        

   HOL-2013-01-ISM - vSphere 7 with Kubernetes - Lightning Lab

   →物理の構築、NSX-Tでの設定等は確認できませんが、それらの準備が終わった状態から

     ワークロードの有効化→名前空間の作成→Podの展開といった作業の内容を確認できます。

   

 実機ではなくあくまでシミュレーションなので疑似的な体験となりますが、そのかわり失敗することはないので気楽にやってみて「あ～こういう感じなのか」というのはわかるかと思います。

結局ハンズオンラボの紹介となってしまいましたが、今回は以上となります。

VxRailについて調べてみた。

HCI（ハイパーコンバジードインフラストラクチャ）の一種である、VxRailについて

機会があったので調べてみました。

その内容をまとめ、個人的な見解を入れたものが当記事となります。

あまり技術的な内容ではないですので、予めご了承ください。

HCIとは、従来のサーバーと外部ストレージ、それを接続するストレージネットワーク

という3層の構造を1つにまとめたものです。

現在、市場をリードしているのはAHV(Nutanix)とVxRail(DELL_EMC)といった製品です。

今回はVxRailについての内容となりますが、VxRailはVMware製品(vSphere ESXi、vSAN)

を使用してHCIを構成しています。

複数の物理サーバーにESXiを導入し、各物理サーバーのローカルディスクをvSANで

共有ストレージとして利用する構成です。

VxRailを含むHCIですが、何がメリットとなるかというと以下の点がよく挙げられています。

  1．導入が簡単

  2．管理が簡単

  3．拡張も簡単

1．については実際に実機を導入してみないことには何とも言えないので、

正直なところ不明です。

ただ、セミナー等を視聴するとセッティングをDELL_EMCで行ってから配送

してくれるようなのでそういうことであれば簡単といえると思います。

2．および 3．についてですが、こちらも実際にVxRailを使ってみない事には

何とも言えないとなりますが・・・

こちらはVMware社のハンズオンラボで誰でも操作してみることができるので、

そちらで実際に体験をしてみました。

  ※こちらからメールアドレスとパスワードでログイン可能です。

    https://labs.hol.vmware.com/HOL

今回私がやってみたのは「HOL-0301-01-HCI」というラボになります。

実際に作業してみたところ、ストレージ機器のシリアルなどの情報をvSphere Clientから

確認でき、ディスクの交換やノードの拡張に、システムのアップデートも行うことができました。

・シリアルナンバー(赤枠)等、ハードウェアの情報が見れるGUIの画面

・ディスクリプレースの作業も手順の中でやってみることができました。

　以下のように、基本的にはボタンを押していくだけで処理が進みます。

　この後にも処理が続きますが、どのような画面になるかは実際に試していただければと思います。

・vCenterに管理されていてVxRail に組み込まれていないESXiホストを自動で検索し、

　追加可能なESXiホストがあれば追加かを行うことができます。

　クラスターの「configure」から「Add VxRail Host」を選択し、右上の「ADD」

　ボタンから追加可能です。

   

・VxRailのシステムアップデートもGUIから実施可能です。

1時間～2時間くらいでラボを完了できるため、少し時間の空いた時にできますし、

何度もやり直せるのでおかしなエラーが出たとしても、もう一回ラボを展開すればいい

ので気楽に作業できます。

手順等はマニュアルなどでも知ることはできますが、実行した際に実際にどんな動き方をするのか、どのようなメッセージが表示されるのかなど、やはり動かしてみないとわからないこともありますので、このようなHOLを見つけたら活用していきたいですね。

今回は以上となります。

【こんなところでVDI】ここからVDI接続してみた・その８ 上空10,000ｍの機内より

久々にJALの国内線に乗り移動中です。無料でインターネットが利用できるので、機内からVDI接続を試してみました。まずは、速度を測定してみます。豊橋上空で測定開始。

なんと、自宅よりも上空10,000ｍのほうがダウンロードスループット良いかも、、、。

VDIにアクセス。デスクトップのロードには少し時間がかかりました。

接続できました。

操作もできました。飛行機の上でも通信状況が良ければ利用できますね。

2回目の速度測定は、高知沖上空。

陸地から離れたせいなのか、それともたまたまなのか、スループットはだいぶ落ちました。

余談
コンソメスープ、おいしい！！

それでは。

VCSA(仮想マシンポートグループ)とESXi(管理用vmkernelポート)を分散仮想スイッチ上に移動するちょっとしたお作法

こんにちは。
私です。

自分で検証する際、普段は管理系のネットワークはメンテナンス性を重視して標準仮想スイッチを使う
のですが、要件としてVCSAやESXiの管理ネットワークも分散仮想スイッチ上に移動して検証しないと
いけないものがありました。

実際に環境を作る際、少し考慮しないといけないことがあったり、元の標準仮想スイッチに戻すのも
面倒だったりとあったので書いとこうと思います。

＜＜何が問題だったか＞＞

    ・分散仮想スイッチににvmnicが追加されてない状態で、元の仮想スイッチからVCとESXiの
      管理ネットワークを移行する際、vmnicも一緒に移動するとエラーになる。

    ・一度分散仮想スイッチ上に移動したスイッチを元の標準仮想スイッチに移行するGUI操作はない。

この2点ですね。

管理ネットワークを元の標準仮想スイッチに戻すというのは、GUI上ではないというだけでDUCIで以下の
項目から、元に戻すか初期化するかを選べます。
(分散仮想スイッチ上に移動していない場合はグレーアウトしています。)

GUIでは一方通行で一度分散仮想スイッチ上に移動したら戻させないというVMwareの熱い意志があるのでしょう。

では、私が行った管理ネットワークの移行時ににどのようなメッセージが出てしまったのか、手順と一緒に
ご覧ください。
まず、移行前の状態がこちら。

標準仮想スイッチに、管理用vmkernelポートとVCSAの仮想マシンが接続しています。

では、分散仮想スイッチに移行してみましょう。
移行するホストを選びます。

 利用しているvmnicと一緒に各ポートグループを移動します。

移行を開始すると最初はうまく処理が進んでるように見えるのですが・・・
エラーとなってしまいます。

推測ですが、VCSAが仮想マシンなので、仮想マシンのネットワークを切り替える際に仮想NICが一度切り離されます。
そのタイミングで通信ができなくなるため、ESXiとも通信ができなくなりエラーが発生してしまうのでしょう。
(うまいことやってくれないもんですかねぇ・・・)

解決策としては、未使用のvmnicを利用して移行を実施し、移行完了したら仮想スイッチに残ったvmnicを
分散仮想スイッチに付け替えて、分散仮想スイッチのNICチーミングで利用するvmnicを整理するという
方法になります。

他にも、ESXiと通信可能な別の仮想スイッチにVCSAを移動させESXiだけ先に分散仮想スイッチに移行する
などが考えられれますが、おそらくこれが一番楽でしょう。

というわけで、改めて移行をやってみます。
今度はvmnic0ではなく、vmnic1をアップリンクとして追加しました。

 ここから先は先ほどと同じになります。

処理を実施してみましょう。

今度はエラーにならず、処理が完了しました。

ESXiのディスクが壊れたとき、はたしてVSANは本当に動くのか？

検証でVSAN+SRMの環境を作ったのですが、無事に確認が終わったので削除することになりました。
そのときに、ふと「あ、せっかくだから1台VSANで使ってるディスク削除して復活できるか確認してみよ」
と思ったので興味本位でやってみました。

  ※物理ではなくNested環境のため、実機でやった場合に同様のことになるのかは定かではありません。

＜環境＞
  ESXi3台(仮想マシン)
  VCSA1台(Nested上の仮想マシン)
  vSphere Replication(Nested上の仮想マシン)
  SRMサーバー(Nested上の仮想マシン)
  テスト用仮想マシン1台(Nested上の)

＜やったこと＞
  VSANを構成しているESXi3台の内1台で、仮想マシンの設定と編集からVSANで使用しているディスク(キャッシュ用1本、キャパシティ用2本)を削除。
  この状態でしばらく放置してもNested上の仮想マシンはちゃんと動いているかどうかの確認。
  削除したディスクを追加しなおして、VSANが再度正常な状態に戻るかどうかの確認。

作業前のVSAN構成
各ESXiでVSANに利用しているディスクが確認できます。

作業前の仮想マシン状況
pingで通信状況を確認しています。

ディスク削除後
当然ですが、ディスクが見えなくなりアラートが起動しました。

仮想マシンのほうは、相変わらず元気で問題なさそうです。
なかなかやりますね。


































ディスク再度追加
ディスク追加後は、アダプターの再スキャンとストレージの再スキャンを行いました。
その後、VSANのディスクグループを作成しています。

ディスクグループ作成の処理が実行され無事元の状態に戻りました。

ESXiを停止せずに復旧できたのはありがたいですね。
ただし、ディスク追加後は必ずアダプターの再スキャン→ストレージの再スキャンを行ってください。
経験上、ストレージの情報に不整合が出たり、きちんと認識できていなかったりして良からぬトラブルが発生してしまうかもしれません。

以上。

【こんなところでVDI】ここからVDI接続してみた・その７ タイ・バンコク市内

先日LCCを利用してバンコクへ行ってきました。LCCで往復4万円弱。国内旅行行けるくらいの金額で海外旅行に行けますね。また滞在したホテルからVDI接続してみました。まず、ホテルの部屋のWiFiの速度を測定。こんな感じでした。17Mbps。私の自宅より速いですね。私の自宅は下り12.8Mbps、上り1.1Mbpsでした。

もちろん、問題なく利用できます。

余談。
ナイトマーケット、タラート・ロットファイ・ラチャダーを上からみた景色が絶景でした。

【VMware】Photon OSについて調べてみた

すでに何回かPhoton OSについて操作してみた内容のブログを書きましたが、改めてPhotonOSについて調べてみたのでその内容を書きます。

PhotonOSって何だ？

• Photon OSとは

Project Photon OS™は、クラウドネイティブアプリケーション、クラウドプラットフォーム、およびVMwareインフラストラクチャ向けに最適化されたオープンソースの最小限のLinuxコンテナホストです。

• Photon OSの特徴
• VMwarevSphere®最適化
• Linuxカーネルは、Photon OSがvSphere上で実行されているときのパフォーマンスに合わせてチューニングされる。
• セキュリティ強化
• カーネルやその他のオペレーティングシステムは、セキュリティを重視して構築されている。
• カーネルはKernel Self-Protection Project (KSPP)の推奨に基づいて構築されている。
• 整理されたパッケージとリポジトリ
• パッケージには強化されたセキュリティフラグが組み込まれている。
• セキュア　EFIブート
• セキュアなリモート管理
• Photon管理デーモンは、コマンドラインユーティリティ、Python、またはRESTによるAPIコールを使用して、リモートのPhoton OSマシン上のファイアウォール、ネットワーク、パッケージ、およびユーザーを安全に管理する。
• 永続ボリュームのサポート
• コンテナのサポート
• Photon OSにはDockerデーモンが含まれる。
• MesosやKubernetesなども動く。
• Project Lightwave 統合
• 効率的なライフサイクル管理
• Photon OSは、管理、パッチ、および更新が容易。
• コンテナパッケージのセキュリティパッチやアップデートはタイムリーに更新される。
• 現在提供中のOSバージョン
• 2.0
• 3.0（ベータ）

• Photon OSを動かせる場所
• VMware製品
• VMware vSphere、Workstation Pro、VMware Fusion
• パブリッククラウド
• Microsoft Azure
• Google Compute Engine（GCE）
• Amazon Elastic Computeクラウド（EC2）
• ARM64（バージョン3.0より対応：現在ベータ版）
• Raspberry pi 3
• PhotonOSの提供方法
• ISO
• OVA
• Amazon Machine Image　(AMI)
• Google Compute Engine image
• Azure VHD
• 必要要件
• RAM　2GB（推奨）
• ディスク　512MB（最小）
• ISOのフルバージョンの場合
• 8GB　  Fusion、Workstation
• 16GB　vSphere
• ２つの提供バージョン
• minimal version
• パフォーマンス重視。実行コンテナに合わせて調整された軽量ホスト。
• full version
• アプリケーション開発、テスト、および展開のパッケージが含まれる。
• ライセンス
• オープンソースライセンス
• 提供場所

GitHub　Project Photon OS™ by VMware

https://vmware.github.io/photon/

• Photon OS Wiki

https://github.com/vmware/photon/wiki

• Photon OS Wiki FAQ

https://github.com/vmware/photon/wiki/Frequently-Asked-Questions 

       FAQにいろいろと細かい情報が書いてあるのでみると面白いかも。

• Photon OS Administration Guide

https://github.com/vmware/photon/blob/master/docs/photon-admin-guide.md

• Photon OS が利用されているもの
• vCenter Server Appliance (vSphere6.5)
• vCenter Server Appliance (vSphere6.5)のPhoton OSパッチを以下から確認できる
• VMware vCenter Server Appliance Photon OS Security Patches
• vSphere Replication Appliance　参照
• Site Recovery Manager 参照

• VMware Photon Platform
• マルチテナントプラットフォーム
• VMware Photon Controller
• VMware Photon Platform記事
• VMware、コンテナ専用プラットフォームにKubernetesやVMware NSX、Virtual SANを統合した新版「Photon Platform」発表。VMworld 2016 Europe
• にほんごVMwareで紹介されているPhoton OSの記事
• PhotonOSを簡単に試せるインターネット上のハンズオンラボ
• HOL-1930-01-CNA - Project Photon OS and Container Basics - Getting Started
• ハンズオンラボ　HOL-1930-01-CNA　ドキュメント

【こんなところでVDI】ここからVDI接続してみた・その６ タイ・バンコク・スワンナプーム国際空港

バンコク・スワンナプーム国際空港。綺麗な空港でした。乗り継ぎ待ちの間、空港の無料WiFiサービスを利用して、スマートフォンからVDI接続してみました。

若干、重いかな、、、と思いましたが使えます。

ファイルサーバー見てみたり、、、

Gmail見てみたり

速度はこれくらいでした。

【こんなところでVDI】ここからVDI接続してみた・その５ モルディブ・アリ環礁

こんなところでVDI。今回はモルディブのアリ環礁です。

今回は荷物を減らしたかったのでPCは持っていきまっせんでした。スマートフォンからVDIに接続。普通にログインできました。スマホからの操作と考えれば、操作感も問題なし。

時刻は接続端末の時間を使ってますね。

接続に利用したのは現地の観光客向けのSIMです。

何気に速い。。。私の自宅よりも速かったです。

余談：行った時期が雨季だったので初日、その次の日と雨に降られ、晴れたのは帰国日前日と帰国日のみでした。滞在期間が短かったのでダイビングができるのは1日だけ。ダイビングなら雨季の方が大物多いと聞いてたのですが、大物見るツアーは毎日やっているわけではなく、なら、シュノーケルツアー！と思ったらすでに予約でいっぱい、、、。今回の滞在期間中には見られませんでした。ジンベエザメ見たかった。。。