2024年7月15日月曜日

AOS6.8/Prism Central 2024.1以降のPC登録解除時の注意点

AOS6.8に対応したPrism Centralは、2024.1以降のバージョンとなります。

これらのバージョンの組み合わせにおいて、Prism Elementから1度Prism Central登録を行った後、登録を解除すると以前に登録したPrism Centralであっても、別で展開したPrism Centralであっても登録ができなくなる仕様となっているようです。

(参考)In pc.2024.1, Prism Element is blacklisted and cannot be registered to either the same PC or a different PC
https://portal.nutanix.com/kb/15679

これは、Prism Centralとの登録を解除するクラスターは、今後破棄予定のクラスターという認識だからのようです。(そんな極端な認識にいきなり変わっても困るのですが...)

CVMのncliコマンドから、以下のようにPrism Centralの解除コマンドを実行すると以下のようなメッセージが追加されてます。

<ncli>  multicluster remove-from-multicluster cluster-id=aac92028-1b14-4688-a891-c1e4acf842ec username=admin password=PrismCentlraのパスワード external-ip-address-or-svm-ips=192.168.XX.XXX

▼Unregist前に確認されるメッセージ

Unregistering the PE from PC is not a supported workflow. Are you sure you want to proceed(YES/NO) ?(Refer to KB-15679 for details): 

ここで「Y」を入力するとPrism Centralの登録が解除されます。

ちなみに、先程まで登録されていたPrism Centralに再度Nutanixクラスターを登録してみたところ、以下のようなブラックリスト入りされているというエラーメッセージがタスクに表示され登録する事ができません。

別でPrism Centralを再展開しましたが、同じメッセージが表示され、やはりPrism Centralに登録する事は、できませんでした。


今まで、Prism Centralのバージョンアップをせずに再展開して、Nutanixクラスターを再登録などして運用されていた場合、AOS6.8以降での運用時には、注意が必要です。





2024年7月6日土曜日

Nutanix CEにおけるinode問題の対応

2024年7月現在、Nutanix CEのインストーラーに含まれているAOSは、6.5.2となります。

このバージョンでは、inodeの枯渇によるクラスターサービスの稼動に影響を与える恐れがあります。

この事象、稼動させてすぐは起きず、しばらく経って(私の環境では、稼動させて1年程度経った後に事象が発生)から起きるため、すぐに事象が発生しませんが、しばらく経ってから起きる可能性があるため、注意が必要です。

3ノード以上でクラスターを作っている場合、1ノード障害に耐えることが出来ますが、検証用で1ノードクラスターを作成している場合、クラスターサービスが起動できなくなる事象が出る可能性もあります。

本事象は、NCCの「inode_usage_check」にて検出されますので、このチェック項目がWarningもしくはFailとして検出された場合は、速やかに対応が必要となります。

(参考)NCC Health Check: inode_usage_check
https://portal.nutanix.com/kb/1532


本事象は、AOS6.5.3以上にアップグレードすれば解決しますので、この事象を回避するため、これからCEを展開する方は、展開後に速やかにアップグレードをしていただくことをお勧めします。

既存でNutanix CEを利用していて、1ノードクラスターで構成している場合、アップグレードする前にこの事象が出てしまうと、AOS自体のアップグレードができない可能性もあります。

この事象が発生した場合、「/var/spool/postfix/maildrop」がinodeを消費している可能性があります。

まず、「/home/nutanix」の使用量が100%近くになっている可能性がありますので以下のコマンドで、空き容量も確認しておきます。

allssh 'df -i /'


さて、この事象を取り急ぎ対処するためには、以下のコマンドを実行します。

allssh 'sudo postsuper -d ALL maildrop'

これで、「/home/nutanix」ディレクトリの空き容量も増えるかと思いますし、クラスターサービスも「cluster start」で正常起動するはずです。


いずれにしてもAOSアップグレードを定期的に行っておけば特に心配する問題でもありませんので、定期的なアップグレードを行う事が大切かと思います。

また、Nutanixのアップグレードは、非常に簡単に行えるための機能が用意されていますので、難しいコマンドを利用することなくアップグレードが可能ですから、積極的なアップグレードを勧めします。




2024年6月8日土曜日

Prism上に残ったタスクのステータスを中断に変更する方法

Prismで様々なタスクを実行していると、まれにですがタスクが進まず残ってしまうことがあります。

 ▼タスクが進まず残ってしまったところ


この残ってしまったタスクは、大半が裏で動作しているタスクが、Prismに対してステータスが渡されていない状態になっていることが考えられます。タスク自体が裏で実行中の物であれば、そのまま待てば良いですが、タスク自体が異常終了するなどしている場合、ステータスだけがの進行中のまま残ってしまいますので、こういった場合は、表示上のステータスを変更を行い、タスクとしては中断した状態のステータスにすることで、タスク表示に残り続ける状態を改善します。

※この方法は、本番環境でむやみに使う物ではありませんので、本番環境でのタスク表示が残った場合は、必要に応じてサポートに問い合わせを行ってください。


タスクステータスを変更する方法

まず、SSHで、CVMにログインを行います。

次に以下のコマンドを実行します。

ecli task.list include_completed=false

すると、以下のようなタスクの結果が表示されます。
(横スクロールで確認してください)

Task UUID                             Parent Task UUID                      Component     Sequence-id  Type                                                       Status
6971450b-a9b5-4b13-6083-a747aeda976f  a66b9851-2318-4a56-6023-8f5781583ea6  cluster_sync  14           Password sync on 192.168.38.174                            kRunning
a66b9851-2318-4a56-6023-8f5781583ea6                                        cluster_sync  10           Password sync: Password changed for admin or nutanix user  kRunning


ここでは、親タスクと子タスクがあります。

この場合、いきなり親タスクを中断できませんので、先に子タスクを中断します。

ergon_update_task --task_uuid='6971450b-a9b5-4b13-6083-a747aeda976f' --task_status=aborted

すると、以下のような確認が来ますので、「y」を入力し、タスクを中断します。

WARNING: Using this command can cause database corruption and complete system failure, if used improperly.
Are you sure you want to continue? (y/n)
y


これで、タスクは「abort」つまり、中断扱いになります。


どうしてもタスクの表示が変わらず表示に残り続けるなどがある場合、このコマンドでタスクステータスを中断に変更することで、終了タスクとして表の表示に残り続けることが無くなるようになると思います。





2024年5月4日土曜日

Prism Centralのトライアル機能を無効化する方法

Prism Centralは、デフォルトで180日間のトライアル機能があります。
Prism Ultimate機能を利用すると、クラスターのリソースの無駄を洗い出したり、リソースの枯渇状況を今までの利用から推測する機能など様々な機能が提供されます。

トライアル期間が有効な間は、以下のようにPrism Central上部に緑のバーが表示されますが、90日のトライアル期間がが終了すると、ライセンス切れのバーがずっと表示されたままになります。


トライアル期間が終了後、Prism Centrralの無償版の機能で継続利用することが可能なのですが、画面上Ultimateトライアル機能を無効化するトルグボタンが、Prism Central 2022.6以降表示されなくなっています。

トライアルのUltimate機能を無効化するためには、以下のコマンドをPrism CentralにSSHでログインし、実行します。

curl --location --request POST 'http://localhost:9080/PrismGateway/services/rest/v1/license/Starter?enable=false' --header 'X-Nutanix-Preauth-User: admin' --header 'Content-type: application/json' --header 'Accept: application/json'

#続いてnccで再度ライセンスチェックを行います
ncc health_checks system_checks check_license_compliance

実行完了後、Prism Centralの画面をログアウトし、再度ログインします。

これで、Prism Ultimateのトライアル機能が無効化されます。


コマンドの内容を見る限り、APIを直接コールしているので、おそらく以前はこのAPIをPOSTするトグルボタンがあったのが、それがなくなった(というか間違って消した?)のでは無いかと思います。

元々GUIで出来た機能なので、これは新しいPrism Centralで戻してほしいところではありますが...。


(参考)Disable Prism Ultimate Trial License in Prism Central
https://portal.nutanix.com/kb/11101






2023年12月19日火曜日

AHVでアップリンクNICにLACPを利用する場合

AHV環境でアップリンクNICにLACPを利用したチーミングを行うケースがあります。

AHVは、もちろんLACPに対応しています。今回は、以前にも紹介しましたが改めてLACPを含めアップリンクのチーミング方法とLACPの設定方法についてお伝えします。

AHVのチーミング方法

AHVは、3つのアップリンクにおけるチーミング方法をサポートしています。

チーミングモード使用事例
active-backupデフォルト構成では、単一のアクティブなアダプターを介してすべてのトラフィックが送信されます。
balance-slbマルチキャストトラフィックに関する注意事項があります。ホスト帯域幅の使用率が単一の 10 GbE アダプターを超えて増加します。各 VM NIC を一度に 1 つのアダプターに配置します。 
LACP and balance-tcpLACPとリンクアグリゲーションが必要です。アダプター間で VM NIC の TCP および UDP セッションのバランスをとることにより、ホストと VM の帯域幅使用率が単一の 10 GbE アダプターを超えて増加します。物理ネットワーク スイッチでLACP ネゴシエーションを必要とします。

AHVのデフォルトは、「active-backup」構成であり、こちらがメーカー推奨の構成となります。複数NICでアップリンクを構成した場合、アクティブとして利用するNICがⅠ本になるため、4本アップリンク構成などの場合はNICが無駄になってしまいますので、Nutanixの構成の推奨としては、2本のNICでチーミング構成を作成し、「active-backup」構成を利用することです。こちらの構成が推奨な理由は、Nutanixは、10Gのネットワーク帯域をフルで利用しない仕組みであることと、LAGにおけるスイッチとの相性およびスイッチの設定ミスによる通信不能状態を引き起こすことをなくすというメリットがあるためです。
当然ながらActive-Backup構成であれば、接続するスイッチ側は、LAGなど設定の必要なく、通常のAccessもしくはTrunkポートで設定すればOKです。

▼Acrive-Backupのアップリンク利用イメージ


balance-slbは、複数のアップリンクNICに対して、仮想マシン毎に特定の物理NICを利用するという構成です。こちらもスイッチ側には、LAGなどのポートを束ねる設定は必要ありません。仮想マシンに搭載された仮想NIC毎に利用する物理NICが割り当てられるため、仮想マシントラフィックによっては、物理NICのトラフィック量が不均等になる可能性はあります。

balance-slbのアップリンク利用イメージ


最後にLACP and balance-tcpですが、こちらはLACPを利用した構成です。スイッチ側でLAGの設定をする際のバランシングモードは「balance-tcp」を設定する必要があります。
物理NICが分散されて利用するため、負荷分散ができかつチーミングされた物理NICの性能を最大限利用することができます。

▼LACPを利用した場合のアップリンク利用イメージ


ここまで、アップリンクモードについて確認してみました。
重要なことは、LAG構成は、LACPのみサポートされており、静的LAGは非サポートであることに注意してください。


<LACPの設定方法>

では、LACPを利用する場合について考えてみましょう。

現在、Nutanixでは、Prism上でアップリンクNICのチーミングモードを変更することができ、Prismでのオペレーションが強く推奨されています。GUIで簡単に変更できることは大変便利です。しかし、Prismを利用して設定を変更するということは、Nutanixクラスターサービスが起動していることが前提です。
ノード追加を行う場合も、追加ノードのチーミングモードを設定できる項目がExpand Clusterの画面に追加されています。

▼Expand Cluster時に拡張ノードに対してチーミングの個別設定が可能


Nutanixの初期設定は、Active-Backupですのでこの状態でクラスターを起動させるために、Nutanixに接続される物理スイッチは、LACPモードではなく、通常のポートで設定する必要があります。一方、Prismからチーミングモードを変更すると1ノードずつチーミングモードがLACPに変更されます。(従来はここでノードの再起動が発生していましたが、AOS6.7においては、再起動は、発生しなくなっています)

しかし、1ノードのチーミングモードがLACPに変わると物理スイッチ側は、まだ通常のポートモードであることから、チーミングモードが変更されたノードは、疎通ができなくなってしまいます。

これを防ぐために、スイッチ側は、LACPの設定を行いつつもfallbackモードを有効化しておくことが必要となります。このfallbackモードは、物理スイッチでLACPを設定されたポートで、LACPのネゴシエーションができなかった場合、標準ポートとしてネゴシエーションするという機能です。この機能を利用することで、予め物理スイッチはLACPに設定しつつも、Nutanix側は、Active-Backupで起動時は、fallback機能が働き、通常ポートとして稼動し、PrismからLACPモードに変更すると、Nutanix側でLACPが有効化されるため、物理スイッチもLACPモードが有効化されるため、疎通が出来なくなるという事故をなくすことができます。

しかし、物理スイッチのメーカーにおいては、fallbackモードが実装されていない場合があります。この場合は、予めNutanixクラスターにLACPモードを有効化した上で、物理スイッチもLACPモードにしておけば、問題なくネゴシエーションができるかと思います。では、NutanixのノードをクラスタースタートせずにLACPモードにする方法としては、CVMから以下のコマンドを入力することでチーミングモードを変更します。

この手順は、クラスターメンバーに入る前のノードでもサ行が可能です。既にクラスターメンバーには行っているノードにおいて設定変更する場合は、クラスターサービスを「cluster stop」コマンドをCVMで実行し、予めクラスターサービスを停止しておきます。

まず、ノードの物理NICを確認します。

nutanix@NTNX-23SM6C-CVM:10.38.51.173:~$ manage_ovs show_uplinks
Bridge: br0
  Bond: br0-up
    bond_mode: active-backup
    interfaces: eth5 eth4 eth3 eth2 eth1 eth0
    lacp: off
    lacp-fallback: false
    lacp_speed: slow
    lacp_status: off

ここでは、eth0からeth5全てが1つの仮想スイッチのアップリンクNICとして構成されており、現行はLACPモードではないことがわかります。

では、LACPモードを有効化します。

nutanix@NTNX-23SM6C-CVM:10.38.51.173:~$ manage_ovs --bridge_name br0 --interfaces eth0,eth1,eth2,eth3,eth4,eth5  --bond_mode balance-tcp --lacp_mode fast --lacp_fallback true  update_uplinks
2023-12-16 05:09:49,505Z WARNING manage_ovs:1361 Failed to fetch gflags. Acropolis service might be down: HTTPConnectionPool(host='127.0.0.1', port=2030): Max retries exceeded with url: /h/gflags?show=hypervisor_username (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0x7f5e411bc350>: Failed to establish a new connection: [Errno 111] Connection refused',)).
2023-12-16 05:10:02,734Z INFO cpdb.py:141 Failed to send RPC request. Retrying.
2023-12-16 05:10:02,856Z INFO cpdb.py:141 Failed to send RPC request. Retrying.
2023-12-16 05:10:03,265Z INFO cpdb.py:141 Failed to send RPC request. Retrying.
2023-12-16 05:10:03,267Z INFO cpdb.py:141 Failed to send RPC request. Retrying.
2023-12-16 05:10:03,280Z INFO cpdb.py:141 Failed to send RPC request. Retrying.
2023-12-16 05:10:03,661Z INFO cpdb.py:141 Failed to send RPC request. Retrying.
2023-12-16 05:10:13,008Z INFO manage_ovs:700 Node: 10.38.51.173 failed to connect to IDF while validating virtual switch configuration. Continuing further may result in inconsistency with the existing virtual switch configuration and require manual remediation once IDF is available.
Do you want to proceed? (Y/[N]):

クラスターサービスが上がっていないので色々コンソールに出力されますが、気にせず、Y/Nの質問が来るまで待った上で、Yを入力設定を完了します。


設定が完了したら、再度アップリンクのステータスを確認します。

nutanix@NTNX-17SM6C100126-C-CVM:10.38.51.173:~$ manage_ovs show_uplinks
2023-12-16 05:19:26,915Z WARNING manage_ovs:1361 Failed to fetch gflags. Acropolis service might be down: HTTPConnectionPool(host='127.0.0.1', port=2030): Max retries exceeded with url: /h/gflags?show=hypervisor_username (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0x7f687cc8b350>: Failed to establish a new connection: [Errno 111] Connection refused',)).
Bridge: br0
  Bond: br0-up
    bond_mode: balance-tcp
    interfaces: eth5 eth4 eth3 eth2 eth1 eth0
    lacp: active
    lacp-fallback: true
    lacp_speed: fast
    lacp_status: configured ★

ここで確認すべき情報は、「lacp_status」です。

こちらの例では、LACP設定は完了していますが、スイッチとLACPでネゴシエーションで来てない状態になります。この項目が「negotiated」であれば、スイッチとのLACPネゴシエーションが確立されています。

なお、AOS6.7「el8.nutanix.20230302.207」のAHVバージョンにおいては、従来AHVがら設定をしていた「ovs-vsctl」や「ovs-appctl」コマンドが利用できなくなっているようです。

AHV上で、ovsコマンドの一覧を確認した際の結果

[nutanix@NX-AHV3 bin]$ ls -alg | grep ovs
-??????????  ? ?            ?            ? ovs-appctl
-rwxr-xr-x.  1 root    234440 May  1  2023 ovsdb-client
-rwxr-xr-x.  1 root    185560 May  1  2023 ovsdb-tool
-rwxr-xr-x.  1 root      8064 Feb 24  2023 ovs-docker
-rwxr-xr-x.  1 root     47168 May  1  2023 ovs-dpctl
-rwxr-xr-x.  1 root     61740 May  1  2023 ovs-dpctl-top
-rwxr-xr-x.  1 root    453544 May  1  2023 ovs-ofctl
-rwxr-xr-x.  1 root      2862 May  1  2023 ovs-parse-backtrace
-rwxr-xr-x.  1 root      3418 May  1  2023 ovs-pcap
-rwxr-xr-x.  1 root     15121 May  1  2023 ovs-pki
-rwxr-xr-x.  1 root     17347 May  1  2023 ovs-tcpdump
-rwxr-xr-x.  1 root      2195 May  1  2023 ovs-tcpundump
-rwxr-xr-x.  1 root     12104 May  1  2023 ovs-vlan-test
-??????????  ? ?            ?            ? ovs-vsctl


今後は、CVMから「manage_ovs」を利用することが前提となっている流れでは無いかと思います。








2023年12月12日火曜日

仮想マシンにのNICにVLANトランクを設定する方法

ネットワーク関連の仮想アプライアンスなど、複数のネットワークを持たせた仮想マシンを構成することがあるかと思います。AHVの場合、「AHV-20230302.207」バージョンの場合、1つの仮想マシンに対して、仮想NICの搭載は15個が最大とされています。

なお、15を超えるNICを仮想マシンに追加することは、Prismの画面上可能なのですが、仮想マシンのパワーオンに時間がかかります(NICの数に応じて30秒を超える)。

コンパチビリティを考えてもNICの数は15個以内に収めておきたいところですが、Firewall的な動作をする仮想マシンなどNICを15個以上必要とする場合があるかと思います。

このような場合、仮想マシンの仮想NICに対して、TAGVLANをそのまま仮想NICに流す、トランクモードの設定を行うことが出来ます。

今回は、AHV環境において仮想マシンにVLAN Trunkを渡すNICの作成方法をご紹介します。

まずは、Prism画面から普通通り仮想マシンを作成します。この際、NICは搭載せずNICなしの仮想マシンとして作成してください。


次に、acliで、仮想NICの割当を行います。

acli vm.nic_create [仮想マシン名] vlan_mode=kTrunked trunked_networks=[通信させたいVLAN-IDをカンマ区切りで記入] network=[UNTAGで割り当てるNIC]

仮想マシンに対して、UNTAGのネットワーク(いわゆるNativeVLAN)を割り当てたくない場合であっても、「network」の定義は必須となります。
(UNTAG側で通信をさせたくない場合は利用しないVLANを作成し、そのVLANを割り当ててください)

では、仮想マシン側ではどのように設定をするかもご紹介します。

まずは、Windows Serverの場合です。

サーバーマネージャーのNICチーミング機能を有効化します。


まずは、チームから「チームの新規作成」をクリックします。


チーミング設定を行います。とはいえ、NICは1本しかありませんの、1本のNICを選択します。1本のNICですからバランシングもできません。仮想マシンの場合は、チーミングモードを「スイッチに依存しない」、負荷分散モードを「アドレスのハッシュ」を選択します。(それ以外のオプションを選択した場合、チーミングNICは作成できません)

プライマリ チームインターフェースは、このNICに対して割り当てるVLANをNativeVLAN以外にする場合は、こちらのオプションで「特定のVLAN」で、指定したいVLAN-IDを入力します。


作成が完了すると、アダプターとインターフェースの部分に、作成したNICが表示されます。

ここからさらに違うVLAN用にNICを作成する必要がありますが、「アダプターとインターフェース」の「タスク」メニューから「新しいチームに追加」がクリックできません。
わかりにくいのですが、「チームインターフェース」を選択し、再度「タスク」をクリックすることで、「新しいチームを追加する」がクリックできるようになります。


▼チームインターフェースを選択


こちらのインターフェースの追加をクリックすることで、別のVLANを割り当てたNICを作成することができます。


ネットワーク接続の画面から見ると、物理のNIC(こちらは、IPアドレスなどの設定をしないでください)と、チーミングされた2つのNICが見えています。IPアドレスの付与や各種設定は、このチーミングされたNICに設定を行います。



LinuxOSの場合もご紹介します。

Rocky Linux 9.3での設定方法を見てみましょう。(他のRHEL互換OSである、Alma Linuxなども同様の設定となります)

最初に、「ip addr」で、既存NICの情報を確認します。

[root@rocky93master admin]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever

2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 50:6b:8d:86:5c:7d brd ff:ff:ff:ff:ff:ff
    altname enp0s3
    inet 10.168.1.70/24 brd 10.168.1.255 scope global dynamic noprefixroute ens3

       valid_lft 28434sec preferred_lft 28434sec
    inet6 fe80::526b:8dff:fe86:5c7d/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

この場合、VLAN用にNICを作成する元NICが、「ens3」であることがわかります。このNICをもとにVLAN401のNICを作成してみます。

シェル画面で「nmtui」を実行し、「接続の編集」をクリックします。

新規NICを作成するので、「追加」を選択します。

作成したNICは「VLAN」を選択します。


プロファイル名はわかりやすい名称にします。デバイス名も管理しやすいデバイス名にしておきます。
親は、VLAN通信をする元NICになります。先ほど事前に調査したNIC「ens3」を入力します。VLAN idには、通信させたいVLAN IDを入力します。IPv4設定等は、状況に応じてIPアドレス付与を行います。

作成されたVLAN NICができたことを確認し、「戻る」を選択します。


nmtuiを終了します。


シェル画面から、「ip addr」コマンドで再度、NICの状態を確認します。

[root@rocky93master admin]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 50:6b:8d:86:5c:7d brd ff:ff:ff:ff:ff:ff
    altname enp0s3
    inet 10.168.1.70/24 brd 10.168.1.255 scope global dynamic noprefixroute ens3
       valid_lft 27267sec preferred_lft 27267sec
    inet6 fe80::526b:8dff:fe86:5c7d/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
5: ens401@ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 50:6b:8d:86:5c:7d brd ff:ff:ff:ff:ff:ff
    inet 10.14.254.75/16 brd 10.14.255.255 scope global dynamic noprefixroute ens401
       valid_lft 5878sec preferred_lft 5878sec
    inet6 fe80::442a:a590:abec:e8a0/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

追加したNICである、「ens401」が追加され、この場合、DHCPを使ってIPアドレスが取得できていることがわかります。

その他仮想アプライアンスの場合は、そのアプライアンスの指示に従いVLANインターフェースの作成が可能かと思いますので、利用したい製品でのVLANインターフェース作成方法をご参照ください。






2023年12月5日火曜日

Nutanix Filesのコマンド操作一覧

日本においてもNutanix Filesを実際に利用するケースが増えてきております。Nutanix Filesは、従来のWindows Serverを使ったファイルサーバーでは実現の難しい、大規模なスケールアウト型のファイルサーバーを構築することが可能です。一方Nutanix Filesは、一部の設定をコマンドでしか設定できない設定があります。本日は、コマンドでしか設定できない内容を中心に紹介します。ご紹介する作業は、一部のコマンドを除いてFSVMにSSHでログインし、設定をおこなうことを前提としています。また、今回のコマンドは、Files 4.4.1をベースに記載しています。


タイムゾーン設定

FilesのタイムゾーンはデフォルトUTCになっています。この場合、SSR等の一部の機能がUTCをベースにして稼動してしまうため、稼動している地域のタイムゾーンで稼動するように設定が必要です。(この作業は、導入後最初に行う事をお勧めします)

afs fs.set_timezone "Asia/Tokyo"


FilesのSSR開始時間を指定する

SSRの開始時間は、UTCタイムゾーンを基準に動作します。そのため、GUI画面で指定したSSRの時間は、日本の場合9時間ずれて実行されます。SSRの時間基準を日本時間に合わせるためには、オフセットを9時間ずらす必要があります。

afs snapshot.set_ssr_hourly_offset 9


Filesの起動及びシャットダウン方法

Filesは、FSVMををシェルに入ってシャットダウンすることは、正しいシャットダウン方法として認められていません。Filesクラスターをシャットダウン後FSVMをシャットダウンする必要があります。起動時も個別でFSVMを起動してもFilesクラスターは起動しません。それらの手順を一元化して行うコマンドがあります。こちらの手順は、CVMから行います。

起動方法

afs infra.start *

シャットダウン方法

afs infra.stop *

ここでは、登録されているFilesクラスターを全て起動するため「*」を入れていますが、1つのNutanixクラスターに複数のFilesクラスターがあり、その1つを起動及びシャットダウンするためには、「*」部分にFilesクラスター名称を入れることで、任意のFilesクラスターの起動及びシャットダウンが可能です。


サブマウント

Nutanix Filesは、作成された共有フォルダ毎にその共有フォルダーを処理するFSVMが決定されます。そのため、1つの共有フォルダの配下に大量のフォルダを作成した運用の場合、1つのFSVMのみに負荷がよってしまいNutanix Filesの本来のメリットである分散処理ができなくなってしまいます。しかし、従来からの共有フォルダ運用を行っていた場合、いきなり運用方法を変更することも難しいかと思います。
そのような場合、既に作成した共有フォルダに、別の共有フォルダをサブフォルダとして割り当てることができます。この場合、DFSの機能のような形で実際に共有フォルダの配下にあるサブマウントされた共有フォルダは、別の共有フォルダにアクセスするため別のFSVMに負荷が分散するため、共有フォルダの構造をなるべく変えずにFSVMの負荷分散を行うことが出来ます。

afs share.edit child-share-name submount_path=submount-path
child-share-nameは、Filesで作成した共有フォルダ(サブフォルダに当てたいフォルダ)を入力します。
submount_pathは、実際にサブフォルダに割り当てたいフォルダパス(/親共有フォルダ/サブフォルダ名)という形の記載をします。
この際に注意をしてほしいことは、割り当てたいサブフォルダ名のフォルダを予めWindowsのエクスプローラ等で作成しておく必要があります。そのフォルダがオーバーライドされたサブマウントしたい共有フォルダにオーバーライドされます。

サブフォルダのマウント状態は、以下のコマンドで一覧表示させることができます。

afs share.list_all_submounted_shares
実行結果例
afs share.list_all_submounted_shares
+--------------+--------------+-----------------------+
| Parent Share | Child Share  | Submount Path         |
+--------------+--------------+-----------------------+
| 親フォルダ   | サブフォルダ | /親フォルダ/サブサブ/ |
+--------------+--------------+-----------------------+

WORMフォルダの作成

ファイルを誤って削除したり変更できないようにする共有フォルダを作成できます。既に作成された共有フォルダには、後から設定できません。フォルダ作成時に設定を行う必要があります。

afs share.add 共有フォルダ名 worm_enabled=true worm_retention_period=time in seconds worm_cooloff_interval=time in seconds worm_type=ShareLevel

パラメーター説明
legal_holdすべてのユーザーによる期限切れファイルの削除を禁止します。
description共有の説明を入力します。
hard_quota_size_gbハード クォータ サイズを GB 単位で入力します。
protocolNFS または SMB として指定します。
share_type共有タイプを default(標準共有)または、distributed(分散共有)を指定します。
size_gb共有のサイズを GB 単位で入力します。
timeoutタイムアウトを秒単位で入力します。
worm_cooloff_intervalWORM のクールオフ間隔を秒単位で指定します。Cooloff_interval のデフォルト値は 600 秒 (10 分) です。
worm_enabledtrue(有効)またはfalse(無効)を指定します。
worm_typeShareLevelを指定します
worm_retention_period保持期間の値を秒単位で指定します。保持期間のデフォルト値は 31449600 秒 (52 週間) です。


シンボリックの有効化

Files上で作成されたシンボリックを利用できる用にする機能です。この機能を利用する為には、予めWindowsクライアントで
「fsutil behavior set SymlinkEvaluation  R2R:1  R2L:1」
コマンドを実行し、シンボリックリンクが利用できる状態にしておく必要があります。

afs smb.set_conf "enable smb symlinks" "False" section=global

通常GUIで設定できる項目もコマンド設定できますが、今回はコマンドでしか設定できない項目をご紹介しました。



 


2023年8月7日月曜日

AHVにおけるメモリーオーバーコミットの利用方法(その1)

AHV環境においては、長らく仮想マシンのメモリー割り当ては、ハードウェアからの予約となり、他の仮想マシンとのメモリーの空き容量を相互に使うメモリーオーバーコミット機能が利用できませんでした。AHV 20201105.30007 以降を備えたハイパーバイザーとAOS 6.0.2以降であれば、メモリーオーバーコミットが利用可能となります。

今回は、このメモリーオーバーコミットの紹介をします。

そもそもメモリーオーバーコミットとは、なにかをおさらいしておきましょう。

メモリーオーバーコミットは、仮想マシンに割り当てられたメモリーのうち、仮想マシンのOSレイヤー以上で利用されていないメモリーを、Balloonドライバーで回収し、ハイパーバイザーに戻すことで、本来のホストの持つ物理メモリーサイズを超えて、仮想マシンにメモリーを割り与えることです。即ち、空いている容量を他の仮想マシンに転用するだけであって、物理的に利用できるメモリー容量が増えるわけでは、ありません。また、メモリーは、1台のホスト内でメモリーのやりくりを行うので、ホストを超えてのメモリーのオーバーコミットはできません。

単純にわかりやすく考えると、月極駐車場で、100台の駐車スペースを法人契約していた場合、平日の10時から16時までは、平均80台の車が営業車として利用されており駐車スペースが空いているため、10時から16時までの間に別の利用者に貸し出すような考え方です。(オーバーブッキングビジネスの考え方)

要は、枠としては、既に押えられているが、実質使われていない空いているキャパシティーを、さらに利用するような考え方となります。


では、メモリーオーバーコミットの利用方法を具体的にご紹介します。

メモリーオーバーコミットは、仮想マシン単位で設定します。

Prism Centralで仮想マシンを作成する際、もしくは作成済みの仮想マシンに対して、Enable Memory Overcommitメニューで、メモリーオーバーコミット機能を有効化します。


Prism Centralでの有効/無効以外に、acliを利用して、メモリーオーバーコミットの有効/無効の設定が可能です。

acli vm.update 仮想マシン名 memory_overcommit=true/false


環境としては、以上で設定は終わりです。仮想マシンには、VirtIO Driverの最新版(Ver 1.2.1)を利用して、バルーンドライバーのインストールが必須となります。

Windowsの場合は、Nutanixが提供する、VirtIO Driverからインストールを行います。


Linuxの場合は、カーネルにバルーンドライバーが入っているかを確認します。

lsmod | grep baloon

で、以下のように結果が表示されれば、バルーンドライバー(カーネルモジュール)が入っています。

virtio_balloon         24576  0

もし入っていない場合は、カーネルモジュールの設定変更する必要があります。

Ballon Driverは、カーネルビルド時に利用する"make menuconfig"の「Device Drivers -> Virtio Drivers」の中にあります。


メモリーオーバーコミットの仕様も確認しておきましょう。

  • AOS6.0.2以降/AHV 20201105.30007以降でサポート
  • 最新のVirtIO Driverを仮想マシンインストールします
  • メモリーオーバーコミットの有効/無効は、仮想マシン単位で、仮想マシンがパワーオフの状態で設定します。
  • PrismCentral 2022.4以降であれば、GUIで仮想マシン単位でメモリーオーバーコミットの設定が可能です。
  • ホストを超えたメモリーオーバーコミットはできませんん。
  • GPUパススルーやvGPUを設定した仮想マシン、vNMUA設定をした仮想マシンは、メモリーオーバーコミットできません。
  • メモリーオーバーコミットを有効にした仮想マシンは、仮想マシンのメモリーホットアドは、できません。
  • ライブマイグレーションを行う場合、通常に比べ移動の速度が遅くなる可能性があります。
  • 物理メモリーの枯渇に備え、スワップファイルが内部的にNutanixManagementShareストレージコンテナ内に作成されます。
  • デフォルトで、各仮想マシンは、割り当て容量の25%が物理メモリーに割り当てが保証(予約)されます。残りの75%は、他の仮想マシンのメモリーオーバーコミット領域として利用されることがあります。(すなわち、4倍までオーバーコミット可能)


仮想マシン側も準備ができれば、あとは、動きを見てみましょう。

メモリーオーバーコミットは、ホストを超えてメモリーをオーバーコミットすることができませんので、今回は、わかりやすいように1台のNutanixホストで試してみたいと思います。

物理搭載メモリー192GBから、CVMが消費するメモリー32GBとハイパーバイザーが利用するメモリーが4GB程度ありますから、実際には、160GB程度しか仮想マシンは利用できないと思います。

この環境で、メモリーを160GB割り当てた仮想マシンを作成します。

この場合、160GBのメモリーをこの仮想マシン専用に確保することができないため、仮想マシンを起動することができません。


しかし、メモリーオーバーコミット機能をONにすると仮想マシンを起動することができます。実際に利用されているメモリー容量は、この場合、160GBのメモリー割り当てに対して、20.67%しか利用していないことがわかります。メモリーオーバーコミットが有効化された仮想マシンは、割り当てられたメモリーサイズの75%がメモリーのオーバーコミットとして他の仮想マシンで起動する際に利用される領域となります。


しかし、CVMは、オーバーコミットができないはずですが、なぜかハイパーバイザーの容量を考えても物理メモリーとして利用できる範囲を超えていると思われます。

では、物理メモリーを超えた容量を割り当てた場合はどうなるのでしょうか?最初に256GBで割り当てたところ、仮想マシンは起動しませんでした。200GBでも起動しませんでしたが、199GBにすると仮想マシンは起動します。はっきりした仕様がわかりませんが、おそらく物理メモリー容量に、8GB未満までであれば仮想マシンに物理容量を超えるメモリーサイズが利用できる可能性があります。


ここからさらに、28GBのメモリーを割り当てた仮想マシンを起動すると、きちんと起動します。最大4倍までがオーバーコミットできるので、トータルで物理メモリー容量を超えた形で仮想マシンを起動することができます。

次回は、より詳細にメモリーオーバーコミットの動きを見ていきたいと思います。




2023年7月26日水曜日

NDBで対応するデータベースと必要な用語について

NDBでデータベースを管理する前に、どのようデータベースやどのような構成のデータベースに対応出来るのかや、NDBで出てくる用語についておさえておきましょう。


プロビジョニングと登録

まず、NDBには、既存のデータベースを登録してNDBで管理する方法と、NDBからデータベースサーバーを展開・管理するという2つの方法があります。それぞれのデータベースによって、登録できるデータベースサーバーの種類、新規展開時のデータベースサーバーの対応している種類に違いがあります。この違いを認識しておく必要があります。こちらは、NDBのバージョンによって対応出来るデータベースの種類や構成によって異なるため、詳細はNDBのリリースノートを参照してください。

(参考)Nutanix Database Service Release Notes 2.5.2.1


対応しているデータベース

NDBは、全てのデータベースをサポートしているわけではありません。残念ながら、SynfowareやHiRDB、Btrieve、InformixやDB2などは対応していません。

NDB 2.5.2.1では、以下のデータベースをサポートしています。

  • Oracle DataBase 11.2.0.4 ~ 21.3.0.0.x(OSは、OEL/RHEL/SUSEのみ、RAC対応)
  • SQL Server 2012 ~ 2019(OSは、Windowsのみ)
    ※1 登録は、2008 R2にも対応
    ※2 Always On 高可用性グループ及びフェールオーバークラスタリングインスタンス(FCI)に対応
  • PostgreSQL 10.x ~ 14.x(OSは、CentOS/RHEL/Ubuntu/Debianのみ)
    ※1 EDB PostgreSQL Enterprise Editionのも対応
    ※2 クラスター構成の場合、Patroni/Etcd/HAProxy/Keepalivedが必要
  • MySQL 5.6 ~ 8.0 (OSは、CentOS/Ubuntu/Debian/RHELのみ)
  • MariaDB 5.5 ~ 10.3 (OSは、CentOS/RHELのみ)
  • MongoDB 5.x (OSは、CentOS/RHEL/Ubuntu/Debianのみ)


グリーンフィールドとブラウンフィールド

NDBのリリースノートを見ているとこの用語が至る所に出てきます。

グリーンフィールド
NDBを介して展開されたデータベースサーバーのこと。

ブラウンフィールド
NDBを介さず手動等で展開したデータベースサーバーのこと。この場合は、NDBへの登録で、NDB管理配下にすることができます。

注意点としては、まずWindows版のOracleは、管理不可であることをご認識下さい。
SQLServerは、Windows版のみサポートでLinux版は、対応していません。
各データベースソフトウェアが最も得意としているOSをNDBは、対応していることに注意してください。

また、対応しているデータべーソフトのOS対応情報とデータべーソフトのバージョンは必ず遵守してください。例えば、CentOSの代わりにRockyLinuxを用いてPostgreSQLを利用したり、PostgreSQLのバージョン15をCentOSに入れたりした場合、Compatibilityの範囲外となり、NDBへの登録・展開ができない場合があります。

また、グリーンフィールドの場合とブラウンフィールドの場合で、NDBの中で利用できる機能が一部異なる点も注意が必要です。

その他にもNDB専門の用語がありますが、順次作業を進める中で出てくるタイミングでお伝えします。NDBの用語は、Nutanixのドキュメントに記載がありますのでそちらを参考にして下さい。

(参考)NDB Terminology Reference


次回は、実際にNDBでデータベースの管理ができる手順を順を追って説明していきます。




2023年7月25日火曜日

NDBの展開(その2)

前回までに、NDBの管理コンソール画面にアクセスできるところまで設定しました。

今回から、NDB管理仮想アプライアンスの初期設定を行っていきます。

NDBクラスターの名称(任意の名称)と、NDBで管理するDB仮想マシンを展開するPrismElementの管理者情報を入力します。


続いてネットワークセグメンテーションの設定画面になります。Nutanixクラスター側でネットワークセグメンテーションが有効になっている場合は、iSCSIデーターサービスのVLAN選択を行う必要があります。(Nutanixクラスター側でネットワークセグメンテーションが有効でない場合、この設定はスキップできます)


続いて、DNSやNTPサーバー、タイムゾーンの設定を確認します。この情報は、Nutanixクラスター側から取得してきますのでほとんどのパラメーターが自動入力されています。
必要に応じて(特にSMTPサーバー)の設定を入力し、次に進みます。


続いて、NDBで展開するデータベースサーバーが利用するストレージコンテナを選択します。

最後に、展開するデータベースサーバーが利用するVLANの設定を行います。
IPAMの設定が行われている場合は、プールの設定をせずIPAMからのIP払い出しが可能です。IPAMを利用しない場合は、IPアドレスプールを設定します。このIPアドレスは、NDBから展開したDBサーバーに付与されるIPアドレスに利用されます。

次に進むと、設定情報が反映されます。しばらく時間がかかりますのでそのまま待ちます。


しばらく待つと、タスクが完了します。

「開始します」をクリックすると、初期の画面が表示されます。


次回は具体的なNDBの利用方法について1つずつ見ていきます。






2023年7月24日月曜日

NDBの展開(その1)

では早速NDBの展開を行っていきます。

NDBは、Nutanixプラットフォーム(NC2を含む)で、ハイパーバイザーが、AHVもしくはvSphereの環境に対応しています。

2023年7月現在、最新のNDBは、「2.5.2.1」となります。今回は、AHVバージョンを利用して作業を行います。

AHV用のqcow2を、Nutanixサポートポータルから取得します。


AHVのイメージサービスにダウンロードしたqcow2を登録します。


展開したqcow2を元に仮想マシンとして展開します。

NDBの仮想マシンは、以下のスペックをベースとして展開してください。

TimeZone : UTC
vCPU Core : 4
vCPU Socket : 1
RAM : 16GB
モード : Legacy BIOS
NIC : 任意のVLAN(マルチNICも対応)

※参考
Installing NDB on AHV

なお、IPアドレスの設定は、cloud-initを使って設定可能ですが、vSphereの場合は、設定方法が異なる事から、今回は、AHVでもvSphere寛容でもどちらでも適用可能な、仮想マシン起動後にコマンドでIPアドレスを設定する方法をご紹介します。

仮想マシンが構成できたらパワーオンを行います。コンソール画面を開き、以下のユーザー名とパスワードでシェルにログインします。

ユーザー名 : era
パスワード : Nutanix.1

IPアドレスを設定するため以下のコマンドを入力します。

era-server
era-server > era_server set ip=付与したいIP netmask=付与したいネットマスク gateway=付与したいデフォルトゲートウェイ nameserver=DNSサーバー ntp_server=NTPサーバー

注意すべき点は、era-serverコマンドで、NDBプロンプトに入ります。その次にIPアドレスを付与する際にコマンドは、era_servereraのあとがアンダースコア)であることに注意してください。また、NDBの仮想マシンはキーボードが101キーボード設定になっています。106/109キーボードの場合、アンダースコアー(_)は、「Shift+-(ハイフン)」、イコール(=)は、「^(ハット)」になりますのでこちらも注意してください。

NTPサーバーとDNSサーバーは、任意入力となりますが、NTPは特に設定しておくことを強くお勧めします。(タイムマシン機能時の時間ずれを防止するため)


このコマンドが実行完了するまで、しばらく時間がかかります。

設定が完了したら、ブラウザで指定したIPアドレスにアクセスします。
EULAが表示されたら、同意し、adminユーザーの新しいパスワードを設定します。もし、EULAが表示されない場合、以下のデフォルトユーザーでログインを行います。


デフォルトのadminユーザーのログイン情報
ユーザー名 : admin
パスワード : Nutanix/4u

ログインに成功すると、以下のような設定画面が表示されます。


次回は、ウィザードの内容に従って、初期設定を行います。




2023年7月23日日曜日

NDBで管理するデーターベースのメリット

NDBは、Nutanix Database Serviceの略称です。
NDBは、その昔Nutanix ERAと呼ばれていた、データーベースの管理ソフトウェアになります。

世の中で稼動するアプリケーションにおいて、データベースの存在は欠かせません。一方データベースはどんどん肥大化しかつミッションクリティカルになってきています。データベースの管理を怠るとデータベース障害の発生リスクを呼び、アプリケーションの稼動に影響を及ぼす可能性があります。

一方、データベースの管理は、データベーソフトウェアに応じた独特の管理方法が必要で、その習得には時間を要する課題があります。

NDBは、そんなデータベースの管理を楽にするツールです。

NDBは、以下の特徴を持った機能を有しています。


1.数クリックでデータベースサーバーを展開

シングルインスタンスのSQLServer データーベースや、SQL Server AllwaysOn 高可用性グループやOracle RACなど、構築が難しいデータベースサーバーもマウスの数クリックだけでデータベースサーバーを構築可能です。


2.データベースサーバーへのパッチの一括適用

データベースサーバーは塩漬け運用という形で、1度稼動すると基本パッチを適用しない運用が多く続けられてきました。昨今では、脆弱性を突いた攻撃なども増えていることから、高いった塩漬け運用は古の悪しき運用となり、昨今では、積極的なパッチ適用が運用の現場でも求められています。しかし、OracleのOPatchのように、パッチ適用にはそれなりのスキルナレッジがないと作業が難しいケースが多くあります。
NDBは、稼動しているデータベースサーバーに対して、パッチ適用のオペレーションをマウスクリック数回の作業だけで適用できる機能を持っています。
沢山のデータベースサーバーを管理している場合においては、パッチ適用の時間を大幅に短縮することもできますし、データベースの高度なスキルを持った人月度対応する事も無くなります。


3.タイムマシンによるデーターベースのロールバック

データベース運用においてノウハウを必要とする機能の1つがアーカイブログ(トランザクションログ)の運用ではないかと思います。アプリケーションのバグや何らかの形でデータベースのデーターに不具合が生じたり、データベースの障害が発生した場合、なるべく最新の状態までデーターを復旧させる必要があります。レガシーな運用では、毎日夜間にDMPファイルの出力でバックアップ対応しているケースが多く見受けられますが、DMP出力後に変更されたデーターはリカバリの対象とはならないので、より新しいデーターのバックアップという観点に置いて、DMPでのバックアップ運用は限界があります。また、DMPは差分出力ができないので、データベースのサイズが大きくなればなるほど時間がかかることから本番運用のデータベースに置いてDMPでのバックアップは限界があります。
NDBは、アーカイブログを管理を行う機能を持っています。定期的なログファイルの取得は、もちろんデータベースサーバーの障害発生時には、面倒なコマンドを使うことなく、マウス操作だけで任意の時間(1秒単位)でデータベースの内容を戻すことができます。


4.データベースのクローン

パッケージソフトウェアの開発など、開発の現場では、運用中のデータベースを元にカスタマイズプログラムを作成したり、運用中で障害が発生すると、そのデータベースのデーターを元にバグの調査をするなど、1つのデータベースから派生するデータベースは、開発の現場で多く存在しているケースがあります。
従来は、元となるデータベースのデーターをエクスポートして取得したDMPを、別のスキーマーや別のインスタンスにインポートするなどを行っていたため、エクスポートとインポートに大幅な時間を要することと、データベースを稼働させるストレージも大量に消費するため、無駄なことが多い運用でした。
NDBを利用すると、Nutanixの持っているストレージの機能を利用し、ストレージベースのポインターとアーカイブログ管理機能を用いて、クローン元のデータベースの任意の時間をベースに、高速なクローンが可能です。



NDBは、今までのデータベースの運用に置いて、DBの構築やアーカイブ運用といったスキルを必要とする部分をデータベースに詳しい一部のエンジニアに負荷が集中するを避け、より可視化された形で、チーム全体で運用ができるように支援するツールです。

次回からは、NDBの展開方法と使い方をご紹介します。


2023年6月3日土曜日

AHV環境におけるWindows仮想マシンのシャットダウンについて

AHV環境では、仮想マシンの電源管理に、物理的なPCなどでも利用されているACPIの命令を利用しています。このACPIの命令は、業界標準の規格であるためどのようなOSに対しても統一的に電源制御できるのが特徴です。

しかし、Windows OSについては、ACPI命令に対応しているものの初期設定の場合、条件によっては、ACPIによるシャットダウン命令を受けてくれないことがあります。

そのため、NGTを経由してシャットダウンする方法が提供されていますが、環境によってはNGTを稼動できない状況下があるかと思います。

本日は、ACPIコールによるシャットダンをWindows仮想マシンで行うポイントをご紹介します。

1.一定時間無操作によるディスプレイの電源OFF

サーバーOSであっても一定時間無操作であると、ディスプレイの電源をOFF(信号出力を止める)のがデフォルトでオンになっています。ディスプレイ電源がOFFになった状態で、ACPI経由でシャットダウン命令がコールされると、ディスプレイの電源が表示(画面出力の信号が行われる)だけで、シャットダウンは行われません。さらにもう一度シャットダウンのACPI命令を投げることでシャットダウンが行われます。
UPS連携などでシャットダウンを行う場合、このままでは正常にシャットダウン出来ない可能性があります。従ってディスプレイの電源を切るは、「なし」に設定しておくことが大事です。

▼設定画面からの変更方法

▼コントロールパネルからの設定変更


2.画面ロック時のシャットダウン

ディスプレイの信号停止によるシャットダウンの影響は比較的簡単に対策をすることができます。一方で、画面ロック時のシャットダウンについては、少々厄介です。
これは、Windowsの画面で操作を行い一定時間無操作の場合や、意図的に離席するなどので「Ctrl + Alt + Delete」でロック、もしくは、「Windowsキー + L」で画面を見えないようにして、第三者の不正な操作や機密情報を盗み見るショルダーハックを防止する機能です。
これはこれで、重要な意味を持つのですが、Windows OSのデフォルト設定では、画面ロックが行われている場合、ACPIによるシャットダウン命令を無視する仕様となっています。

▼画面ロックの状態


これは、ロック時は、作業途中という扱いになりシャットダウンが行われないように設計されているWindows OSのデフォルトの動作となります。
しかし、VDI環境や停電時は、安全なシャットダウンが優先されますので、OSの正常シャットダウンを優先すべきなケースがあります。

ロック時におけるシャットダウンの設定について、ご説明していきます。

Windowsには、ロック時でもシャットダウンを強制するオプションがあるのですが、こちらがデフォルトでは非表示になっています。

▼電源ボタンに対する設定が表示されない


そこで、まずは強制シャットダウンのメニューを表示させる必要があります。
該当のWindowsマシンから、以下のコマンドを管理者で実行します。

powercfg -attributes SUB_BUTTONS 833a6b62-dfa4-46d1-82f8-e09e34d029d6 -ATTRIB_HIDE

このコマンドを実行後、「コントロールパネル」→「電源オプション」→現在設定されているプランの「プラン設定の変更」を開きます。

「電源ボタンとカバー」→「強制ボタン/カバーシャットダウンを有効にする」→「設定」を「オン」に変更します。


この設定を行うことで、画面ロック時にもシャットダウンを行うことが出来るようになります。

なお、間違えやすいのですが、電源ボタンとカバーの配下にある「電源ボタンの操作」をシャットダウンにしてもロック状態でのシャットダウンはできません。「強制ボタン/カバー シャットダウンを有効にする」の項目を「オン」にするので、間違えないようにして下さい。


詳細は、こちらもご参考下さい。
Power actions initiated from Prism or API may fail for Windows VMs