12月12日長野新幹線車両センターの状況

日の出が遅くなったこの時期、スマホだけで鉄道写真を撮影するのは厳しいですね。暗い中の長野新幹線車両センター訪問です。

仕業交番検査庫の状況

先週は架線表示灯は点灯していたけれど、架線には電気は来ていない状態でしたが、今週は架線に電気が通通っていました。

室内の架線死活表示器「入」表示の赤

入り口の表示器も赤字で「入」になっている

既に検修庫までの入線試験とかやっているのだと思います。12月25日の検修開始まであと2週間です。

W2の状況

手付かずが2両、解体中が 3両、本日搬出が 1両の状態です。

まずは手付かずの 2両、検修庫脇の次の解体対象の 6号車 W714-502 です。車内はそのままでした。

W714-502

次は、W2最後の解体となる W715-502は、いつもの渡り線手前にありました。屋根の白いのは雪ではなく今日は霜です。

W715-502

解体中の 3両、5号車の W725-202, 6号車の W726-302, 3号車のW725-102 は臨修庫奥の解体場所にいます。

5号車の W725-202

6号車の W726-302

3号車のW725-102

4号車 W726-202は臨修庫内、本日午前中搬出だと思います。

W7の状況

動きはありません。ただ、奥に止まっている営業車からのブロアー音や明かりが窓越しに見えるので、生きているように見えるときがあります。

W714-507 と W715-507

良いカメラで撮影すればきれいに写るでしょうがスマホではこれが限界。でも、W7の電気が入って走り出しそうに見えるかなと思います。ちなみに灯りの元は隣の11番線に入っている W7系です。

W723-102

上の写真はこんな位置関係の時に撮影してみました。

W7との並び

W2の残りの車両、来週は W725-102 と W 726-302 が解体され、21日の週に W725-202 と W714-502、最後の週に W715-502 の解体で、W2は年内で解体が終わりそうです。W7 自体は 2021年 1月からになりそうですね。

 E7系 残滓の状況

2セットの台車の状況は変わらず。

建屋横の E7系 F18 編成の台車と検修庫脇の線路上にあるW7系 W2 編成の台車

位置関係はこんな感じです。

E723-18 の運転台も変化なし。

E723-18

何か作業をするわけでもなさそうなので、現状のままどこかに持っていくのだと思います。

留置線の状況

 留置線の本格利用に向け、レールの上面も研削され光っていて、線路関連は整備が終わったようです。すべての留置線がきれいになっています。仮設の柵も見当たりません。

留置線真ん中から

あとは6番～11番の仮設の車止めを撤去するだけ。

仮設の車止めが残る6番～11番

現在の長野新幹線車両センターの状況はこのような感じです。

長野新幹線車両センター 12月12日見たまま

解体待ちと解体済みの一覧

現在の水没 E7 / W7 の状況です。解体された順番に並べています。赤字は解体済み、黄色字は解体中、緑字は残されている車両、解体待ちの編成は解体順に現在の編成状態で書いてあります。 （W2 がオリジナルの編成の状態と異なります。）

【解体】

F10：E723-10, E726-110, E725-10, E726-210, E725-110, E726-310, E725-410, E726-410, E725-210, E726-510, E715-10, E714-10
F7 : E723-7, E726-107, E725-7, E726-207, E725-107, E726-307, E725-407, E726-407, E725-207, E726-507, E715-7, E714-7

F14：E723-14, E726-114, E725-14, E726-214, E725-114, E726-314, E725-414, E726-414, E725-214, E726-514, E715-14, E714-14

F8 : E723-8, E726-108, E725-8, E726-208, E725-108, E726-308, E725-408, E726-408, E725-208, E726-508, E715-8, E714-8

F16：E723-16, E726-116, E725-16, E726-216, E725-116, E726-316, E725-416, E726-416, E725-216, E726-516, E715-16, E714-16

F1：E723-1, E726-101, E725-1, E726-201, E725-101, E726-301, E725-401, E726-401, E725-201, E726-501, E715-1, E714-1

F2：E723-2, E726-102, E725-2, E726-202, E725-102, E726-302, E725-402, E726-402, E725-202, E726-502, E715-2, E714-2

F18：E723-18, E726-118, E725-18, E726-218, E725-118, E726-318, E725-418, E726-418, E725-218, E726-518, E715-18, E714-18

W2：W715-502, W714-502, W725-202, W726-302, W725-102,W726-202, W725-402,W726-502, W726-402,W723-102,W726-102, W725-302

W7：W723-107, W726-107, W725-107, W726-207+W725-207, W726-307, W725-307, W726-407, W725-407, W726-507, W715-507, W714-507

 W2 はもう少しで解体完了。25日の検修庫利用開始前に W7 の移動があるように思います。

おまけ

写真は撮影してきませんでしたが、もしかしてと思い鉄道車両の保存やE253系の生首を置いている直冨商事の本社を見てきました。他の車両の置いていあるスペースは以前のままで変化なし。そして、その周辺も新たな展示物を置くスペースも作られていなかったので、あのE723-18の生首は、直冨商事行きではないようですね。

vSphere ESXi customize image のつくりかた（vSphere 7 が来た後の対応）

カスタムイメージが必要な理由は

vSphere Hyprvisor (ESXi) のカスタムイメージ、これはハードウエアベンダーによって実装されているハードウエア構成が異なるために、その方言ともいえる違いを吸収するために必要なのですが、VMware で認定を受けているハードウエアであればそのベンダーがカスタムイメージを用意して提供してくれますが、家ラボのように VMware 認定機種ではない場合、自分でカスタムイメージを作らないとインストールすらできない場合もあります。特に NIC, SATA, USB あたりのドライバは大切で、NIC に対応したドライバーがないとそもそもインストーラーが先に進みませんし、PC にESXi をインストールする場合は SATA が無いとディスクが見えない、そして USB が無いと USB をブートデバイスにできないなどいろいろなことがあって、新しいバージョンの vSphere が出てくるたびにカスタムイメージを作っていたかと思います。

カスタムイメージを作るのに使うツールは

カスタムイメージを作るには VMware から提供されている PowerCLI をインストールした PowerShell から、ESXi-Customizer-PS を使って作る方法を以前記事として書きました。

imaisato.hatenablog.jp

ただ、この時にはまだ vSphere 7 が登場していなかったため、この記事で紹介している ESXi-Customizer-PS も vSphere 6.7 までしか対応しておらず、vSphere 7 のイメージを作ることができなくて、以下のサイトの記事を見ながら手作業でコマンドを入力して vSphere 7.0 のイメージを作成していたかと思います。

ESXi on 10th Gen Intel NUC (Comet Lake - Frost Canyon)

ただ、やはり毎回コマンドを売ってやるのは大変ですし、ESXi-Customizer-PS のように簡単にできればよいのになぁと思っていたら、GitHub に vSphere 7 版がありましたので、そちらを使ってください。
VFrontDe/ESXi-Customizer-PS

 ESXi-Customizer-PS の使い方は、vSphere ESXi customize image のつくりかた（vSphere 7 が来る前の準備）を見てください。ここに記載してあるオプションの -v67 を -v70 にするだけで vSphere Hypervisor (ESXi) 7 のカスタムイメージができます。

カスタムイメージを作る際の留意点

カスタムイメージを作る際に取り込むネイティブドライバによっては Customizer-PS-v2.6.0-vS7.ps1 で直接 ISO イメージを作成できない場合があります。この場合は -ozip を指定して一度 ZIP に書き出し、その後同じ Customizer-PS-v2.6.0-vS7.ps1 で -izip を指定して ZIP イメージを取り込んで ISO にします。このやり方もvSphere ESXi customize image のつくりかた（vSphere 7 が来る前の準備）に書いてあります。

iso イメージを USB 媒体に書き込む

出来上がった iso イメージを イメージに書き出せない場合があります。CD に焼いて使うこともできますが、ここはスマートに USB メモリーに書き出して USB からインストールしたいですよね。それには Rufus というツールを使います。これもvSphere ESXi customize image のつくりかた（vSphere 7 が来る前の準備）に書きました。

VMKLinux が消えた後に使えなくなっているデバイスは

VMKLinux を使って開発されている Realtek のオンボード NIC が全滅します。今の所 USB NIC の Realtek デバイスは、VMware の flings で提供されている USB Network Native Driver for ESXiにあるネイティブドライバを使えば動作しますので、オンボードは諦めて、とりあえず USB NIC ｗ調達するのが速いです。
動作確認が取れているのは、
* StarTech.com USB 3.0 -2ポートギガビットイーサネットLANアダプタ USBポート付き USB32000SPT
* Anker アルミニウムユニボディハブ LANアダプター USB 3.0 RJ45 ギガビットイーサネットアダプタ 10/100/1000 Mbps
* Anker PowerExpand+ 7-in-1 USB-C PD イーサネット ハブ
* Anker PowerExpand 8-in-1 USB-C PD メディア ハブ
あたりですが、個人的には安定していて 2ポートのLANが取れるStarTech.com USB 3.0 -2ポートギガビットイーサネットLANアダプタ USBポート付き USB32000SPTがおすすめです。我が家の家ラボでは既に10個使っていますが、1台に2つ使っても安定して動いています。

我が家の家ラボでは Intel NUC 7i7 / 7i5(Intel Core i5 / i7)、ASUS ミニPC PN50-BBR026MD (AMD Ryzen R5 4500U)、謎メーカーの ACEPC CK2 (Core i5-7200U) で vSphere Hypervisor (ESXi) 7 を動かしています。NIC 増設はもちろんStarTech.com の USB32000SPT を使っています。カスタムイメージを作ればこのくらい柔軟に vSphere 7 環境を作れるのでお勧めです。

DDR4 の NUC の最大メモリー

我が家の家ラボは 第7世代の NUC で vSphere 環境を作っています。その前は DDR3L の第5世代と第6世代の NUC で環境を作っていたのですが、実際に搭載できるメモリー容量は NUC の仕様というより CPU 他の仕様で確認するのが大切です。
つまり、DDR3 / DDR3L メモリーのマシンであれば、最大 32GBのメモリーを搭載できます。そして、DDR4 メモリーのマシンであれば、仕様的には 128GB のメモリーを載せられるのですが、今市場に出回っているノート PC 用メモリーは 1枚 32GBが最大、ということで NUC は 64GB のメモリーを搭載して運用しています。もちろん Ryzen R5 のマシンも 64GB、QNAP TS-473 も 64GB メモリーを搭載して仮想環境を動かしています。メモリーが不足気味と感じているのであれば「どこまで載りそう？」を調べてチャレンジしてみるのもよいかもしれません。

12月5日長野新幹線車両センターの状況

長野市内にも積雪。でも、屋根や畑にうっすら積もるだけで、道路は溶けてしまっていました。その中の長野新幹線車両センター訪問です。

仕業交番検査庫の状況

先週は室内に電気が来ていたけれど、架線には電気は来ていない状態でしたが、今週はいよいよ架線に電気を通す準備ができたようです。架線死活表示器が生きていました。

室内の架線死活表示器「切」を表示

入り口の表示器。「切」が表示されている

いよいよ12月25日の検修開始が見えてきました。

W2の状況

手付かずが4両、解体中が 3両、本日搬出が 1両の状態です。

まずは手付かずの 4両、検修庫脇の次の解体対象の 6号車 W726-302 です。

W726-302

5号車 W725-202, 12号車 W714-502, 11号車 W715-502 はアップルブリッジ赤沼下から臨修庫よりに移動。

11号車 W715-502, 12号車 W714-502, 5号車 W725-202

W2 も半分になりました。

解体中の 3両、3号車の W725-102, 4号車の W725-202, 9号車のW725-402 は臨修庫奥の解体場所にいます。

3号車の W725-102

4号車の W725-202

9号車のW725-402

10号車 W726-502 は臨修庫内、本日午前中搬出だと思います。

W7の状況

動きはありません。そして動かないので冷たくなってしまっているため、奥の営業車とは異なり雪で真っ白でした。営業車は屋根上の中央だけの積雪です。

W714-507 と W715-507

反対側も隣の F編成に比べて雪の付着が多いのがわかります。

W723-107

W2の残りの車両、来週は W725-402 と W 726-202 が解体され、14日の週に W725-102 と W726-302、21日の週に W725-202 と W714-502、最後の週に W715-502 の解体で、W7 自体は 2021年 1月からになりそうですね。

 E7系 残滓の状況

2セットの台車の状況は変わらず。

E7 と W7 の台車

位置関係はこんな感じで、ごみ処理場の建屋横に E7系 F18 編成の台車が、右の検修庫脇の線路上に W7系 W2 編成の台車が置かれています。E7系の方は銀色のビニールシート、W7系の方は青色のビニールシートでカバーされています。

E723-18 の運転台も変化なし。

E723-18

何か作業をするわけでもなさそうなので、現状のままどこかに持っていくのだと思います。

留置線の状況

 留置線の本格利用に向けていろいろ変わっているようです。まず、廃車が置いてあった1番～5番と6番の間の柵が撤去されています。

柵が撤去された

6番から11番の車止めを撤去すれば、水害前の状態に戻ります。

1番から11番線

現在の長野新幹線車両センターの状況はこのような感じです。

長野新幹線車両センター12月5日みたまま

解体待ちと解体済みの一覧

現在の水没 E7 / W7 の状況です。解体された順番に並べています。赤字は解体済み、黄色字は解体中、緑字は残されている車両、解体待ちの編成は解体順に現在の編成状態で書いてあります。 （W2 がオリジナルの編成の状態と異なります。）

【解体】

F10：E723-10, E726-110, E725-10, E726-210, E725-110, E726-310, E725-410, E726-410, E725-210, E726-510, E715-10, E714-10
F7 : E723-7, E726-107, E725-7, E726-207, E725-107, E726-307, E725-407, E726-407, E725-207, E726-507, E715-7, E714-7

F14：E723-14, E726-114, E725-14, E726-214, E725-114, E726-314, E725-414, E726-414, E725-214, E726-514, E715-14, E714-14

F8 : E723-8, E726-108, E725-8, E726-208, E725-108, E726-308, E725-408, E726-408, E725-208, E726-508, E715-8, E714-8

F16：E723-16, E726-116, E725-16, E726-216, E725-116, E726-316, E725-416, E726-416, E725-216, E726-516, E715-16, E714-16

F1：E723-1, E726-101, E725-1, E726-201, E725-101, E726-301, E725-401, E726-401, E725-201, E726-501, E715-1, E714-1

F2：E723-2, E726-102, E725-2, E726-202, E725-102, E726-302, E725-402, E726-402, E725-202, E726-502, E715-2, E714-2

F18：E723-18, E726-118, E725-18, E726-218, E725-118, E726-318, E725-418, E726-418, E725-218, E726-518, E715-18, E714-18

W2：W715-502, W714-502, W725-202, W726-302, W725-102,W726-202, W725-402,W726-502, W726-402,W723-102,W726-102, W725-302

W7：W723-107, W726-107, W725-107, W726-207+W725-207, W726-307, W725-307, W726-407, W725-407, W726-507, W715-507, W714-507

 W2 が着々と解体されています。長野新幹線車両センターでの車両解体もあと残りわずかです。

vCenter Server Appliance 7.0 U1 をクラスタに入れると勝手にできる VCLS って？

vSphere 7 の vCenter Server Appliance をクラスタにデプロイすると、その後勝手にすべてのホストに VCS(n)という仮想マシンができます。この VCLS って何なの？と思う前にちょっと VCLS のお話を。

vCLS とは

vSphere 7.0 までは見ることのなかった仮想マシンvCLS、これは vSphere 7.0 Update 1 で追加された vSphere Cluster Services に使われる仮想マシンです。この vCLS があることにより、今までは ｖCenter Server のインスタンスに依存していた vSphere DRS や vSphere HA の機能が、vCenter Server の状態に依存せずに動作し続けることができるようになりました。これ、とても便利です。

vCLS はどういうタイミングでできるの

vCLS がデプロイされるタイミング、これは vCenter Server を vSphere 7.0 Update 1 にアップグレードするとき、それと新しいvSphere 7.0 Update1 で環境を作るときに自動的に展開されます。この画面キャプチャはリモートコンソールから各ESXi の状況を見ていますが、それぞれのホストに VCLS が展開されているのがわかるかと思います。

vCLS の展開数

vCLS はクラスタを構成しているすべてのホストにできるのではなく、最大で 3つまで展開されます。これは vSphere 7.0 以前の vCenter HA の時のアクティブノード、パッシブノードそして監視ノードの 3つの構成と同じように高可用性を維持しつつ構成情報のレプリケーションを取ることで、耐障害性を高めています。
展開される数は以下の通りになります。

クラスタ内のホスト数	vCLS の数	備考
1	1
2	2	なぜか3になる場合がある（後述）
3以上	3

vCLS はホストのメンテナンスや障害の際にはどのようになるの

各ホストにデプロイされた vCLS は、そのホスト上で vSphere DRS や vSphere HA の機能が動作するように常に起動していますが、ホストに何かあった時にどのような動作をするかを見てみます。

ホストがメンテナンスモードに入った時は

ホストがメンテナンスモードに入ったりすると実は vMotion して他のホストに移動します。先のキャプチャした環境で 2台構成のクラスタの中の 1台をメンテナンスモードにすると、このようにもう 1台のホストに vCLS が移動します。これでサービスを継続できるようにしているわけです。2ノードの場合は相手側に 2つの vCLS が集まり、3ノードの場合は残った 2ノードのどちらかに 2つの vCLS が集まります。4ノード以上のクラスタの場合は vCLS はバラバラのホスト上に移動します。

ホスト障害の場合は

HA 構成で単一のノード障害であれば、通常の vSphere HA と同様に vCLS が他のホストに移動します。何ら変わった動作はありません。そして、vCLS が生きているので当然 vCenter Server の動作するノードがダウンしても vSphere DRS や vSphere HA は機能し続けます。

vCLS が無限に増える・・・・・・・の？

ホストメンテナンスモードにした後、メンテナンス作業完了後にホストのメンテナンスモードを解除すると、メンテナンスモードで移動した vCLS は、3ノード構成以上の場合は元のホストに戻ることなくそのまま移動先に残っています。ところが、不具合なのか仕様なのかわかりませんが、2ノード構成の場合で vCneter Server が稼働しているホストをメンテナンスモードにして vCLS がもう一台のホストに移動、vCenter Server も移動させてホストのメンテナンスを実施後にメンテナンスモードを解除すると、新しい vCLS が展開されてしまうということが発生しました。3つの vCLS というのがあるので、2つの vCLS が片方のノードに集まっていてメンテナンスモードを解除したら vCLS の居ないホストが登場ということで 3つめの vCLS をデプロイしたのかもしれません。実際にその後何度もメンテナンスモードにしたり戻したりしても 3つ以上増えなかったので、これは仕様上 3つ vCLS が必要ということでこのような動作をしているのだと思います。

vCLS って作り直しできるの？

できます！！
要するに vCenter Server と一緒に vCLS も停止して、その後に vCLS を削除して vCenter Server を起動しなおせば、勝手に必要な vCLS を作り直してくれます。
正し、インベントリに「親なし」で残っていると新しい vCLS は展開されませんので、もし削除する場合には注意が必要です。（インベントリから削除すれば、自動的に新しい vCLS のデプロイが始まります。）

vCLS に必要なリソースは

vCLS は最大 3ノード分できますので、以下のリソースを考慮しておく必要があります。ただ使うリソースはとても少なくかつ負荷も低いので、あまり気にする必要はないかもしれません。

• CPU 1コア
• メモリ 128MB
• ディスク 2GB

あと、ログインすることは無いと思いますが、vCLS にログインするアカウントとパスワードです。
アカウント：root
パスワード：changeme
最初にログインするとパスワードの変更を求められます。つまり、Photon OS の初期設定パスワードのままだというのがわかります。

おまけ Raspberry Pi 4 の ESXi クラスタではどうなの？

これは単純明快です。ARM 版 ESXi では vCLS 自体がはありません。なので、ここに書いてあることは全く関係がないことになります。正し、vCenter Server 7.0 U1 を使い ARM 版 ESXi を扱おうとすると vCLS の展開失敗による「ファイルの削除」のメッセージがタスクにずっと出続けていると思います。これを抑止するためには、vCenter Server のクラスターオブジェクトの設定を一部変更してください。場所は vCenter Server -> 設定 -> 詳細設定 で以下の定義を入れます。domainについてはvCenter Server を選択すると URL に表示されるのでそれを使ってください。

• 名前 config.vcls.clusters.domain-cXXXXX:XXXXXXX
• 値 False

 

vSphere 7 Hypervisor ESXi で何故使えないデバイスが急に増えたの？

vSphere 6.7 まではいろいろなコンピューターに ESXi をどうにかインストールして使うことができましたが、vSphee 7 ではインストールすらできなくなってしまいました。これ、何故というのをちょっとお話しします。

vSphere 7 で使えないデバイスが増えたわけ

vSPhere 7 では、今までの vSphere 6.7 と色々な所に変更が加わっていますが、家ラボやっている人に大きな影響が出たのがサポートされるデバイスが大きく減ったということ。これ、vSphere 7 で VMKLinux が廃止されたことによる影響です。

VMKLinux って？

VMKLinux は Linux のデバイスを vSphere ESXi で使うためのインボックスコンポーネントです。この VMKLinux インボックスドライバを使うメリットとして Linux ネイティブドライバに vSphere のライブラリをリンクしてビルドすることにより、ESXi ネイティブドライバを作ることなく ESXi 上で Linux でサポートされているデバイスをそのまま使えるようになっていました。これ、デバイスドライバのソースが公開されていれば、CentOS 上に VMKLinux インボックスドライバのビルド環境を作ればだれでも ESXi のドライバを用意することができ、結構活用させてもらっていました。
しかし、この VMKLinux は Linux に依存する部分も多く、また 2015年にこの VMKLinux 関連が GPL 違反だと提訴されたことを記憶している人も多いと思います。結局 2018年11月にその訴えは退けられたのですが、玉虫色の判決でもあり、ESXi から Linux 色を排除するというのはある意味必要な課題として残っていたんだろうと思います。この GPL の問題は vSphere 5.5 の登場時に訴訟になっており、vSphere 5.5 で初めてネイティブドライバが登場したのですが,、ESXi 登場時から使えていたこの VMKLinux を利用しているベンダーがほとんどだったので、5.5 やその後の 6.x で ESXi の中から VMKLinux の排除はできませんでしたが、新たに作り出した vSphere 7 ESXi では既存ユーザーやベンダーは 6.x でまだ少しの間は対応可能だということもあり、vSphere 7 で VMKLinux を排除するというのは予想できた動きかと思います。
VMKLinux がどのようなことをしていたのか、簡単に図にしてみました。

そして、vSphere 7 そして vSphere 5.1 以前の構成は以下の通りです。

余計なものが介在しないのですっきりした流れになるということと、Linux 関連でこれからも出てくるかもしれない課題（ライセンスとかそういう面だけではなく、セキュリティホール他 Linux 側起因の課題）に対しても回避が可能になるわけです。メリットとして、

• パフォーマンス向上が期待できる
• トラブル時の調査や対応が楽になる
• PCIe HOt Plug などハードウエア側に実装される新機能をサポートできるようになる

などが考えられます。逆にデメリットとしては、

• ネイティブドライバーの開発が必要
• ネイティブドライバーの無いデバイスが使えなくなった

などがあり、今回の vSphere 7 で「家ラボに ESXi 7 インストールできなくなった。」というのはデメリット側の影響なわけです。

これからの vSphere では？

既に VMKLinux はサポートされていませんので、今後はネイティブドライバが用意されたデバイスだけが ESXi で利用できるデバイスになっていきます。でも、家ラボ環境でテストするのに高価なネイティブドライバを使わなければならないのは困るなぁと思いますよね。ディスクに関しては IDE や SATA が対応しているのでどうにかなりますが、問題なのは NIC、だいぶ範囲が狭まっているので Intel NUC にインストールするのに苦労した人も多いかと思います。でも、NIC に関しては VMware 社の有志が USB NIC だけですがネイティブドライバーを開発・公開してくれているので、それを使うのも一つの方法かもしれません。以下のリンクからダウンロードできますので、オンボードの NIC が使えない場合は USB NIC でどうにかするのも方法の一つです。
USB Network Native Driver for ESXi

VMKlinux 廃止に伴う使えなくなったデバイスはなに？

以下の KB にリンクされている PDF に記載がありますので、そちらを参照してください。日本語の KB にはリンクは無く、英語の KB にしかないので、日本語で本文を読んだ後に右下の「Language」を「English」にし、「Attachments」からPDFのダウンロードをしてください。
ESXi 7.0 で廃止およびサポート対象外になったデバイス (77304)

家ラボ作りに必要な情報

• まずは足りないネイティブドライバーを組み込んだカスタムイメージの作り方です。
  vSphere ESXi customize image のつくりかた（vSphere 7 が来る前の準備）](https://qiita.com/inasato/items/62396114feeaffc7b3e2)

• 次に、長く使えるライセンスを安く入手する方法です。
  vSphere 7 が出る！VMware 製品を評価したいときは・・・・評価ライセンス？それとも買っちゃう？

• 家ラボで検証開始前にちょっとプロダクトを理解したい場合
  vSphere のお勉強はー＞ハンズオンセミナーに行くより、家やオフィスでハンズオンラボを使ってみよう

• 既存環境のアップグレードの際の留意点は？
  vSphere 7.0 U1 へのアップグレード

• チャレンジャーな家ラボマニア向け

vSphere のメモリー活用の仕組みについて

vSphere を含めた仮想化環境のメモリーの話

仮想化環境のメモリー管理はいろいろな種類があるのですが、SE でもそれを理解していないでインフラの設計・運用管理をしている人を多く見かけるので、vSphere ネタとしてちょっと書いてみました。ご興味あればお読みください。

仮想化環境でメモリーを活用する技術は

物理サーバーでは、サーバー1台1台個々にメモリーを持って専有して使っていました。そして、物理サーバー全盛の時代ではハードウエアの開発速度も速く、ちょっと間を置くと性能や容量が倍とか一桁違っていたりとかが良くありました。そのような時代の中、物理ハードウエアの上でそれらの余裕あるリソースを使って仮想的にコンピューターをエミュレーションして使うという考え方が出てきて、今は仮想化の世界では主流になっている VMware 製品もこの時期に登場しています。
最初のころはメモリー空間をそのままアサインして使ったり、空いているブロックをやり取りしながら使ったりしていたので、やはりメモリー容量はそれなりに必要でしたが、ハードウエアのアシストもあって今はメモリーも効率的に使われるようになりました。私も最初に使い始めた VMware Workstation 1.0 登場が 1999年で、それから20年でここまで技術が進みつは思っていなかったのですが、こういうところが「技術」は楽しい部分です。
では、まず仮想メモリーの前に一般的なメモリー管理について簡単に説明します。メモリー管理方式にはページングとセグメントの2つの方式があって、それぞれ動きが異なります。

ページング方式

ページングは連続したメモリー空間を「ページ」という固定長の単位で扱い、そのページをOSがアプリケーションに割り当てていくという形をとっていて、OSはページテーブルを使って割り当てのマッピングを管理します。アプリがいっぱい動いてメモリーが足りなくなるとOSはメモリーページの中から最近アクセスが無くて内容の変更も行われていないページを見つけ、そのページをディスクに書き出して（ページスワップ）ページを解放します。これは Windowsで言えば「仮想メモリ」が該当します。オペレーティングシステムの基本の仕組みであってもちろん Linux でも実装されているので目にする方は多いと思います。（そして、Linux で OOM Killer で泣いた人も・・・）

ページングの発動時は実際にはアプリの処理は停止されています。要するに簡単に書くと

のような動作をします。

セグメント方式

セグメント方式は、メモリー空間の管理が可変長というところがページング方式と異なります。メモリー空間自体は全体が可変長セグメントで管理されて、そのセグメントの最初からのオフセットでメモリーを利用する形をとり、個々のセグメント同士を別々に管理ができるので相互のメモリー領域の保護という用途で使われたりしていました。（昔私も使っていた IBM System/38 ～ AS/400 の流れがそのようなメモリー管理だったと思います。）
セグメント方式は単体で使われるということより、ページング方式と組み合わされて使われるのがほとんどで、今の仮想化ではまさにセグメント方式とページング方式のハイブリッドで使われています。ざっくりと書いてみるとこんなイメージです。（実際にはもっと複雑です。）

インテルの x86 CPU はセグメントとオフセットというリニアなアドレス空間を持たない CPU のため、大規模なメモリー空間を扱うような環境には不向きな構造を持っていたため、メモリーをアクセスできる空間を仮想的なセグメント単位で扱うようにして大きなメモリー空間を扱えるようにしています。この大きなメモリー空間が 4GB として設定されたため、32bit x86 CPUは最大メモリーが 4GB しか扱えず、32bit OS はシステムが使う領域以外のアドレス空間しか使えなくなっているので、どんなにメモリーを搭載しても 3GBちょっとしか使えなかったわけです。

vSphere 仮想化環境のメモリー管理は

vSphere といえども x86（今は x86_64）の上で動く限りにはインテルのメモリー管理の制限に引っ掛かります。ただ他のOSとは異なり仮想マシンの下のHypervisor層として動くため、物理ハードウエアを効率よく使う部分は vSPhere Hypervisor (ESXi) が行ってくれます。そのため、よほどではない限り物理ハードウエア側のメモリー管理の影響で、仮想マシン側にトラブルを引き起こすということがありません。物理の時代はメモリーが足りなかったりするとすぐに業務システムに影響が出てしまうのが当たり前でしたが、vSphere などを仮想化環境を使っている場合は複数の仮想マシンが動いていて相互にメモリーを融通しながら動作するので、すべての仮想マシンで必要なメモリー容量の合計より少ないメモリーしか搭載していないハードウエア上でも、業務システムのスローダウンを引き起こすことはほとんどなくなりました。
この vSPhere Hypervisor (ESXi) が行っているメモリーを効率的に扱う仕組みには、以下の４つのものがあります。

• 透過的ページシェアリング
• バルーニング
• メモリー圧縮
• VMkernelスワップ

それぞれのメモリー活用方法は以下のようになります。

透過的ページシェアリング

仮想化環境では一つの物理サーバーの上に全く同じOSの仮想マシンが動作することが多いはずです。例えばWindows Server 2019だらけとか、Red Hat Enterprise Linux 8 だらけとか、仮想デスクトップであれば Windows 10 Enterprise ばっかりとかです。この場合、それぞれのメモリーに対して使わない領域を他に融通するような使い方をしても、全体として必要なメモリー容量はそれぞれの仮想マシンの合計になります。でも、発想の転換！！同じメモリーパターンで変更されないページを共有してしまえば、必要となるメモリー容量を削減できます。これが透過的ページシェアリングです。

現在はセキュリティの理由でデフォルトは OFF になっていますが、自社専用の環境で使う場合は有効にすると効果が見られます。特にオンプレミスで Horizon 環境を使っている場合には効果的です。

バルーニング

ページングの所ではコンピュータの上のアプリケーションはメモリーを割り当てられていてもすべてを使っているわけではなく、足りなくなったらその部分をページスワップして他に使わせるということをしていると説明しましたが、それを仮想マシンに対して行っているものがバルーニングです。
バルーニングの場合はvSphere Hypervisor（ESXi）で仮想マシンからの要求に対してメモリー割り当て不足が起きそうになった場合に、仮想マシンの中から割り当てられているメモリーで使われていないところ（inactive memory）を見つけ出し、その部分を他の仮想マシンに使わせてしまいます。そしてメモリーをはぎとられた仮想マシンはinactive memoryがページアウト（Windows ではページスワップと呼んでいたものと同じ動作です）しないようにinactive memoryメモリーの状態を固定します。これで仮想マシンの性能を落とさずに仮想マシン間でメモリーの貸し出しを実現しています。

ただ、ここで重要なこととして、inactive memoryはページアウトしないように固定はするのですが、メモリーをはぎ取られた仮想マシンで急にメモリー需要が増大してinactive memoryのエリアまで使う必要が発生した場合は急に対応ができないため、場合によっては仮想マシン自体に影響が出てしまう場合があります。具体的には Linux などの場合はメモリーを使おうとしてもその領域をバルーニングドライバが「既に使っていますよ」と通知してしまうので、場合によっては Linux のOS保護の仕組みから、プロセスの中でメモリーを多く使用しているプロセスが OOM Killer で落とされてしまうことがあります。そのため、パフォーマンスが落ちないしメモリーを効率に使えるからバルーニングは許容しようとしてしまうと、意図しないメモリー利用の増大でどれかの仮想マシンのどれかのプロセスが突然落とされてトラブルになるということも考えられますので、バルーニングはあくまでも緊急避難的な仕組みであり、物理サーバーのメモリーは必要な容量実装を実装するというのを基本にするのが賢明です。

メモリー圧縮

バルーニングでもメモリーが足りない場合は、メモリー圧縮を行います。メモリー圧縮は仮想マシンのメモリー空間が足りないためディスクにスワップさせる処理に入ることが確定的になった場合、そのメモリーページをディスクにスワップさせずに圧縮してメモリー上に置いておくという動作をします。ディスクに書き出すのではなくメモリー上に圧縮して置いてあるのでパフォーマンスに対するインパクトを最小限に抑えることができるのですが、メモリー圧縮の効果が見られない場合はメモリー圧縮を断念してディスクにスワップアウトをします。

ディスクにスワップアウトすることも場合によっては発生するので、この状態にならないようにvSphere Hypervisor (esxI) のメモリー管理をすることが重要です。

VMkernel スワップ

メモリー活用の最後の手段、VMkernel スワップは文字通り物理ディスクにメモリーページをスワップします。動作としては優先順位の低い仮想マシンのメモリーをVMkernelによりスワップアウトします。そして、仮想マシンのゲストOSはページアウトを認識しませんので（vSphere Hypervisor (ESXi) の機能でのスワップアウトなので）、ゲストOSがメモリーにアクセスするたびにディスクに書き出されたスワップファイルに対しスワップイン・アウトを繰り返すことになり、結果として物理ディスク I/O 負荷が増加してしまい、結果として仮想化環境全体の性能ダウンが発生します。

仮想化環境のメモリー管理の要点（仮想マシン視点）

ここまでは vSphere 側の視点でメモリー管理を書きましたが、仮想マシン側の視点でも注意するべき点があります。これは最初で書いたゲストOSのメモリー管理での「ページスワップ」のことで、ここを物理マシンの時代と同じように許容したサイジングで仮想マシンにしてしまうと、仮想マシンの負荷が上がってメモリーが足りなくなってページスワップが発生したりすると、これは即仮想化環境全体のディスク I/O 増加につながってしまいます。そのため、仮想マシンではメモリーを多く設定するとともに、ページングファイル無しに設定するなど「ページスワップ」させないのを基本にしてメモリーのサイジングすることが重要です。特に仮想デスクトップ環境を展開する場合は、仮想デスクトップのメモリー割り当てを 2GB とかに設定してしまうこともありますが、最近の Microsoft Office ではそれではメモリーは足りないため、多くのアプリを動かすとすぐにページスワップ発生を招いてしまいます。この時、HDDストレージを使っている場合は性能劣化が顕著になるのですぐにわかるのですが、Flashストレージを使っていると意外と気づかずに、多くの仮想デスクトップを展開・運用し始めて初めて問題に直面する場合とかも出てくるようになります。このあたり、基本は
* 仮想マシンのゲストOSではページスワップしないように設計する
* vSphere 側ではバルーニングが発生しないように必要なメモリー容量を設計する
* メモリー不足＝ディスク I/O 増大につながるので、ストレージは可能な限り性能の良いものを選択し、ストレージへのパスも帯域をしっかり確保できるようにして、イレギュラー時にも耐えられるように設計する
* パフォーマンス劣化時にゲストOSでSCSIタイムアウトが発生していたら、それはディスク I/O 増大による仮想マシンのディスクアクセス遅延が発生していることで、その原因はアプリだけではなくゲストOSのメモリー不足によるページスワップの可能性もある
ということをしっかり理解していく必要があると思います。
メモリーについてはまだまだ奥深いのですが、今回はここまでにします。

参考情報

最新の vSphere 7 でも、大きくは変わらないと思います。

• VMware vSphere 5 のメモリ管理および監視の図 (2017642)
  https://kb.vmware.com/s/article/2017642?lang=ja

• vSphere Monitoring and　 erformance
  https://docs.vmware.com/en/VMware-vSphere/7.0/vsphere-esxi-vcenter-server-70-monitoring-performance-guide.pdf

 

11月28日長野新幹線車両センターの状況

本日は平地でも雪が降る予報になっていたので、早めに訪問してきました。

W2の状況

先週解体に入った W2 ですが、既に2両の解体が完了しています。今の臨修庫の解体場所に置かれているのは、金沢寄りから 1号車の W723-102, 

W723-102

8号車の W725-402,

W725-402

そして 10号車の W726-502 です。

W726-502

解体済みなのは 7号車の W725-302 と 2号車の W726-102、先週 F18 の E725-218 搬出前に解体場所で部品取りをされていた2両です。そして、その時に一番長野寄りにあった W723-102 がいよいよ車体の解体直前に来ていました。

他の W2系は、まず検修庫脇には 9号車の W725-402が、

W725-402

臨修庫奥の建物の裏に 2両、3号車の W725-102 と 4号車の W726-202 が置かれています。

W725-102,W726-202

その奥のアップルブリッジ赤沼の下には長野側から W715-502, W714-502, 

12号車 W715-502, 11号車 W714-502

そして金沢寄りは 5号車 W725-202 と 6号車 W726-302

W725-202, W726-302

と留置されています。そして、先週確認したときは

W715-502, W714-502, W725-202, W726-302, W725-402, W726-502, W725-102,W726-202, W726-402,  W723-102,W726-102, W725-302

（11, 12, 5, 6, 9, 10, 3, 4, 8, 1, 2, 7）

の順だったのですが、今の留置の位置だと、

車輪研削庫手前

W715-502, W714-502, W725-202, W726-302　　W725-102,W726-202

（11, 12, 5, 6, 3, 4）

検修庫脇

 W725-402

（9）

解体中

  W726-502, W726-402, W723-102（搬出待ち W726-102）

（10, 8, 1, (2)）

解体・搬出済み

W725-302

（7）

になっていて、わざわざ入れ替えて9号車  W725-402と 10号車 W726-502 を引っ張り出したようです。そのため、ここまでの解体順が 7->2->1->8->10->9 になっています。 残りは多分順当に 4->3->6->5->12->11になると思いますが、実際にどうなるかは解体が始まるまでわかりません。こういう解体順番はどうやって決めているのでしょうね。

W7の状況

まずは JR西日本の W7系だらけの写真。

W2, W7, W8

写真左は W2 のグリーン車、真ん中は W7 のグランクラスとグリーン車、右は W8のグランクラスです。生きているのは W8だけですね。

W7と W8のツーショット

毎回訪問して思うのですが、この角度で見ると W7 も走り出しそうです。

遠目に見る W7と W8

 E7系 残滓の状況

ごみ処理施設の脇の台車の前にパレットが置かれ、直接台車が見えなくなりました。

見えなくなった台車

ところが、もう 1セット台車が梱包されておいてあるのを発見。これはJR西日本 W7系の W725-302 の台車のようです。線路に乗ったままブルーシートで雑に梱包されていました。

W725-302 の台車

JR西日本の台車なので白山総合車両所に持っていくのかもしれません。

E723-18 の運転台もそのまま変化なし。

E723-18

解体終盤になって運転台の生首や台車の保管など、今までにない動きが見えているのが気になるところです。

留置線の状況

 W2 が移動したことで、留置線の 1番～11番すべてが解放されました。そして営業車両が入線してくるだけになっています。

今では解体で使用する車輪転削庫線と臨修庫線、検修庫脇の線以外は車両はいなくなりました。

留置線は営業車だけ（W8が留置中）

営業車両が使用できる線も 6番線～11番線で変わらず。

留置線は営業車だけ（W8が留置中）

現在の長野新幹線車両センターの状況はこのような感じです。

長野新幹線車両センター 11月20日見たまま

解体待ちと解体済みの一覧

現在の水没 E7 / W7 の状況です。解体された順番に並べています。赤字は解体済み、黄色字は解体中、緑字は残されている車両、解体待ちの編成は解体順に現在の編成状態で書いてあります。 （W2 がオリジナルの編成の状態と異なります。）

【解体】

F10：E723-10, E726-110, E725-10, E726-210, E725-110, E726-310, E725-410, E726-410, E725-210, E726-510, E715-10, E714-10
F7 : E723-7, E726-107, E725-7, E726-207, E725-107, E726-307, E725-407, E726-407, E725-207, E726-507, E715-7, E714-7

F14：E723-14, E726-114, E725-14, E726-214, E725-114, E726-314, E725-414, E726-414, E725-214, E726-514, E715-14, E714-14

F8 : E723-8, E726-108, E725-8, E726-208, E725-108, E726-308, E725-408, E726-408, E725-208, E726-508, E715-8, E714-8

F16：E723-16, E726-116, E725-16, E726-216, E725-116, E726-316, E725-416, E726-416, E725-216, E726-516, E715-16, E714-16

F1：E723-1, E726-101, E725-1, E726-201, E725-101, E726-301, E725-401, E726-401, E725-201, E726-501, E715-1, E714-1

F2：E723-2, E726-102, E725-2, E726-202, E725-102, E726-302, E725-402, E726-402, E725-202, E726-502, E715-2, E714-2

F18：E723-18, E726-118, E725-18, E726-218, E725-118, E726-318, E725-418, E726-418, E725-218, E726-518, E715-18, E714-18

W2：W715-502, W714-502, W725-202, W726-302, W725-102,W726-202, W725-402,W726-502, W726-402,W723-102,W726-102, W725-302

W7：W723-107, W726-107, W725-107, W726-207+W725-207, W726-307, W725-307, W726-407, W725-407, W726-507, W715-507, W714-507

 W2 が着々と解体されています。長野新幹線車両センターでの車両解体もあと残りわずかです。