【趣味】太刀魚釣り

今日の記事は全くの趣味です(笑)
本日、今年の釣り初めにして釣り納に行ってきました。

もはや趣味と言っていいのかわからないくらい、このご時世と仕事やら育児のバタバタで釣りに行けてません('◇')ゞ

釣果は87匹と大爆釣！！

お刺身、みりん干し、から揚げ、天ぷら、骨せんべいにして美味しく頂きました。

来年はもう少しいけるといいなぁ…

フルクローンとリンククローンの違い（おさらいパート１）

私がリンククローンを導入した8年前、vSANのバージョンで言うと1.0でしたが（めちゃくちゃアーリーアダプターです（笑））

当時、サーバの仮想化は一般化してきましたが、電子カルテに代表される病院情報システムに関しては、まだ、仮想環境導入を見送る病院が多くある時代でした。vSAN×リンククローンで電子カルテを運用させてたのはおそらく当時はうちだけだったはず…

仮想デスクトップの仕組みはすべてのI/O実行環境がサーバ側にアクセスが集中するため、ストレージI/Oが高くなり、その負荷を吸収する大規模な共有ストレージが導入時の大きな課題となっていたのが大きな問題かと思います。

当院では、ローミングプロファイルを活用することでリンククローン方式での導入を実現し、VDIに必要なストレージの絶対容量を低減すると共に、ストレージの仮想化技術を取り入れることで、ホストサーバに内蔵した高速なSSDを効果的に活用することができ、ログオンストームや電子カルテ使用におけるピーク時のI/O負荷にも十分に対応可能なストレージパフォーマンスを低コストで確保することを目指しました。方式の違い、手法についての当時の概要をおさらいとして説明させていただきます。

VDI基盤を構成するホストサーバの台数は3台で、マスターイメージとなる1つの仮想マシンを読み取り専用で共有利用するリンククローン方式での運用を採用することで、仮想デスクトップの高効率な実装と素早い展開を可能にすることを目指しました。仮想ストレージは、各ホストサーバに内蔵されているSSDやHDDなどのローカルディスクを仮想的に束ね、単一の統合データストアとして利用するものです。自動的に仮想ストレージデータストアとして各ホストから認識でき、単純にホストサーバを増設するだけで、共有ストレージの容量やI/O性能をスケールアウトすることが可能になります。

まず、マスターテンプレートを1台ずつクローニングしていくのがフルクローン方式となります。

フルクローン方式は、マスターイメージとなる親仮想マシンの複製であるクローンを展開する方法です。台数分だけのディスク容量が必要となるので物理PCと同様の考え方となります。

次に、リンククローン方式の場合は、複数の仮想デスクトップを用意すると利用前のOSの状態は同一のイメージを利用します。その後、利用状況に応じてユーザーごとにデータが作成されマスターテンプレートとの差分が発生することになります。

そこで、OSイメージはマスターとして1つにまとめてしてしまい、差分だけをユーザーごとにデータを保持するのがリンククローン方式となり同機能を用いることで、ストレージの容量を大きく削減することが可能になり、コストメリットが得られるように構成しました。

リンククローン方式でのVDI基盤では、更新(Refresh)、再構成 (Recompose)、再調整 (Rebalance)というタスクが発生するので、どのタイミングでどのアクションを選ぶのかの調整が重要になります。更新(Refresh)は仮想デスクトップ環境を初期状態に戻す処理を指していますが、当院では、病棟部門へのヒアリング調査によりセッションが切断されてから、5分使わなければ更新(Refresh)しても運用に問題ないというデータが得られたのでそのように設定を行いました。

　これにより、未使用のデスクトップは定常的にクリーンな状態となり、余剰な差分ディスクによるストレージ消費を防止するとともに、次の利用者がすぐに接続できる状態を維持できています。

また、プリンタドライバの追加や電子カルテのクライアント側のパッチ、プラグインなどの追加の場合は、マスターのみに追加のコンポーネントをインストールし、再構成 (Recompose)することで、すべての仮想デスクトップに差分を展開することが可能となります。

それでは、今回はこのあたりで。

次回、パート２はディスク容量やIOについておさらいしていきたいと思います。
今回もお付き合いいただきありがとうございました。

停電後などに仮想マシンが立ち上がらないときの対処法

 当院では、ESXi3台構成のVDI環境を2組運用させているが、これからの台風シーズンなど突然の停電や雷などのサージによって、分散しているUPSの一部だけがダメになってしまったがために、ESXiが2台での運転になり、DRSによって停止した1台分に乗っていた仮想マシンが他のホストに移行した後に全停電などが起きた場合に起こりやすい（自分も2度ほど経験した）トラブルの対処法のご紹介です。

まず、DRS(vSphere Distributed Resource Scheduler)のおさらいですが、 ハードウェアの使用率を自動的に最適化し、状況の変化にリアルタイムで対応することで、データ センターの運用効率を向上させるものです。また、ホスト1台に障害が発生して物理的に修理が必要になっても、残りのホストにダウンタイムなしで仮想マシンを移動させ、サーバ メンテナンスを実行することが可能です。

とても便利ですね。

vSphere HA では、アドミッション コントロールを使用して、ホストで障害が発生した場合に仮想マシンをリカバリするのに十分なリソースが確保されるようにします。

アドミッション コントロールは、リソース使用量に制約を適用します。これらの制約に違反する可能性のあるアクションは許可されません。許可されない可能性のあるアクションには、次のものが挙げられます。

仮想マシンのパワーオン

仮想マシンの移行

仮想マシンの CPU またはメモリ予約の増加

vSphere HA アドミッション コントロールの基本は、クラスタでどれだけの数のホスト障害を許容しながら、フェイルオーバーを行うかにあります。

ここで、一番最初に記載させていただいたトラブルでESXiが落ちている場合、最後に残ったESXiにDRS機能が頑張って仮想マシンを移動させたがために、復電時にアドミッション コントロールがリソース使用量で制限をかけて、仮想マシンが起動してこないことがあります。私も最初はなぜだか全くわからなかったです(笑)

このように理由がわかっている場合は、アドミッション コントロールのチェックを外して無効化して、CPUとメモリには負荷はかかりますが、それで強引に起動して下さい。ある程度、起動したら手動で積極的にDRSをかけて（もしくは手動で稼働ホストを移行する）リソースの空いているESXiに仮想マシンを分散させてください。そうすれば無事立ち上がるかと思います。

もちろん、普段はアドミッション コントロールは有効が推奨です。あくまで、イレギュラーの話です。

台風シーズンに突入しますが、皆様にこのようなトラブルが出ないことを切に願います。もしもの時に、こういうこともあり得ることを頭の片隅に置いていただければ幸いです。

インスタントクローンでの仮想マシンの展開時間

 2022年3月に事務系（インターネット接続あり）のVDIのリプレイスはVMware horizon7からhorizon8にバージョンアップしたこともあり、これまで使用していたリンククローンがなくなり、代わりにインスタントクローンに変わりました。

今回、インスタントクローンで仮想マシンを更新するのに要した時間は、うちの環境でたったの14秒でした('◇')ゞ

めちゃくちゃ高速になっています。

当院での過去のインフラとの比較ですので、CPUの性能も変わっていますし、メモリの搭載量も違うので参考程度ですが、新規デスクトップ作成にかかる時間をそれぞれの方式で5回ずつ計測し、平均値を算出した結果を示しています。

2012年に最初にVDIを導入したときは新規で仮想デスクトップを作成するのに5回の平均値で1時間2分52秒だったのに対し、2015年の電子カルテ導入時に採用したリンククローン方式では5回の平均値が7分49秒となりました。そして、今回のインスタントクローンでは5回の平均値がなんと14秒です。

ちなみに、一気に行くとマルチタスクで複数台同時に進行していくので、現在リンククローンを採用している電子カルテのインフラは病院内全部の端末を再構成するのに35分かかります。インスタントクローン方式を採用した事務系の端末70台を一気に再展開したときに要した時間は3分59秒でした。今年度、電子カルテのインフラもこの方式でリプレイスする予定になっています。

次回は、インスタントクローンにするとなぜここまで高速展開が可能なのか、説明したいと思います。それでは。

お礼【VDI環境でのセキュリティ対策について】

 7月30日の第12回岡山県医療情報技師会では、300人を超える方々が視聴してくださり誠にありがとうございました。私の演題の【VDI環境でのセキュリティ対策について】への質問も多くいただきまして感謝申し上げます。時間の都合で2つくらいしか回答できなかったのですが、またこのような機会がありましたら、もう少し深く掘り下げてお話させていただきたいと思っています。