コミックマーケット99、参加します。
TL;DR
新刊が出ます！あと、キャッシュレスが使えます！
おかえりコミケ、ただいまコミケ
COVID-19の流行から2年。やっとコミックマーケットが（完全な形ではないにしろ）帰ってきました。
実は、私は別で創作系のアカウントとサークルを持っていて、そっちはオンリーイベントが主だったこともあり、COVID-19下でも細々と即売会が続けられていたんですが、やはりコミケが戻ってくるのは格別な思いがあります。
そんなわけで、hinananohaが主宰する「Ureshino Network Service」でも新刊を出さねば！と、今月に入ってから死にながらやっておりました。無事出せそうで安心しています。
今回の新刊「会報URESHINO 2021冬特別号」について
まず最初に謝罪致します。Funnel Advisor、停止中です。
これは、2年間の間にメンテしないといけないものが増えてしまったことと、なによりDVD-ROMカタログが発行されないことによるものです。FAはカタロムに強く依存しておりましたので、再開には諸々改造が必要で、さてどうしたものか……となっております。
というわけで、今年は趣向を変えて「特別号」ということで、キャッシュレス特集をすることとしました。
前述の創作系のサークル「雛菊書房」で、このCOVID-19下での非接触な決済を云々という建前で面白そうだから諸々導入しまして、その経験を一冊の本にしました。
この手の話は技術系評論同人でもちょいちょい出てる話ではあるんですが、やはり「数奇者のおもちゃ」という側面が大きいので、今回は「普通のサークルが導入出来ること」を主眼に置いて、色々書きました。
是非お手にとっていただけますと幸いです。
既刊の頒布について
また、遥か昔、2年前のC97で頒布した「会報URESHINO Vol.2」は、予想外に爆速でなくなるという事故があったため、今回電子版という形で再版することとしました。
「電子版なら別にBOOTHでよくね？」と思うと思いますが、まあこう、キャッシュレスの体験をしつつ電子版を買えたら楽しいですよね、という気持ちです。形式は今考えているところですが、おそらくC94の「会報URESHINO 準備号」と同じように、ダウンロードカードをお渡しすることになると思います。
キャッシュレス決済について
そこそこに対応していますって感じです。現金でも大丈夫です。今回はSquare Terminalを使いますので、レシートも出せます。
久々のコミケ！
めちゃくちゃ楽しみすぎて夜しか眠れねぇ！
仕事めちゃくちゃ忙しい中どうにか本をひねり出せたので、是非買ってくれると嬉しいなと思っています。よろしくお願いします。
Windows 11とCPU要件について（人柱してみた記事）
注意：この記事は「要件外のPCにWindows 11をインストールして、さらにはそれを常用すること」をオススメすることを目的とはしていません。悪いことは言わないので新しいPCを買いましょう。
（非対応な環境だと対応環境と比較してBSoDの発生率が52%以上高い*1とされており、推奨されない事には変わりありません。また、この記事では継続運用可能性については一切検証しておらず、今後Microsoftにより非対応環境へのWindows Updateの提供が停止される可能性があります。）
TL; DR
Windows 11 インストールバトルの結果、
- 既存のWindows 10環境からのアップグレードは、アップグレードアシスタント/Windows 11 インストーラのどちらを使っても要件非該当としてブロックされる。
- クリーンインストールについては、
※2021/10/07 追記：上記の挙動について、Microsoft公式に記載があったためこちらに掲載します。
support.microsoft.com
2.メディアから起動してセットアップを起動します。 このパスはクリーン インストールで、以前のファイルや設定は保持されません。 詳細については、「PC をクリーンにして新たに開始する」を参照してください。
重要: TPM 1.2 (最小システム要件の TPM 2.0 ではなく) 以上の場合は、Windows 11 をインストールできるので、メディアから起動する前にデバイスで最小システム要件を満たしていることを確認する必要があります。また、TPM 1.2 ではプロセッサがファミリとモデルで承認されている CPU の一覧にあることは確認されません。
また、アップグレードの際に適用される厳格な要件チェックの回避方法も同様に記載がありますが、この記事では要件外の環境へのインストールは推奨しておらず、むしろ「要件外の環境（ノートＰＣ）へインストールを試みたら失敗した」事を記載しています。
失敗しても元に戻せるバックアップや、トラブル発生時に対応出来るだけど技術的専門性を持たない場合、上記の記事に書かれた手順は実施しないことを強く推奨します。
祝・Windows 11 リリース
めでたい。
というわけで、前回の記事の振り返り
kokura.hatenadiary.jp
前回の記事は、Windows 11の要件確認ツールの最初のバージョンが出た時に執筆しました。
ここで問題になったのは、「仮想環境でWindows 11を利用する方法」。高性能なPCで仮想マシンをいっぱい立ててる人や、逸般の誤家庭で誤自宅にサーバラックをお持ちの方など、そういった方向けに、「果たして仮想環境下でどうやってWin11の要件を満たすべきか」を検証しました。
というわけで、無事Windows 11がリリースになったので、実際にインストールが可能かどうか、検証しました。
検証
検証環境
今回の検証環境は以下の通り。なお、今回の検証では、何らかの「回避ツール」や「回避手段を搭載したISO」などは使わず、Microsoft公式Webサイト*2から取得したインストールイメージをそのまま使います。
比較用の要件を満たした環境
要件非該当環境 - VMware vSphere
- VMware vSphere 7.0.2 + vCenter Server 7.0 Enterprise Plus (Native Key Provider 有効)
検証結果
比較用要件該当環境 : Ryzen9 3900X + VMware Workstation Pro
特に問題が起こることなくインストールは完了。この仮想マシンは今後、メインマシンのWin11移行に備え、各種ソフトの動作確認用に供用します。
要件非該当環境：VMware vSphere(クリーンインストール)
まず、CPUのみ要件非該当にした場合。仮想マシン構築時に以下の設定を入れます。
- ストレージ選択時に「仮想マシンの暗号化」を選択
- OS選択画面で「 Windows 仮想化ベースのセキュリティの有効化 」をチェック
- ハードウェア構成画面でTPMを追加。また、ビデオメモリを256MB(上限)に設定。
この状態でインストールを行った結果、特に問題なくインストールが完了しました。
インストール時に何らかの警告なども表示されませんでした。また、一部で噂になっていた「Windows Updateを提供しない」問題についても以下の通り、特に問題なく動きました。
また、TPM有効/セキュアブート無効の場合も、特に問題ないことが確認できました。
というわけで、次にTPMを無効にしてインストールを行おうとしたのですが。
こちらは、インストーラの画面で、エディションを選択した後の画面（通常であればライセンス条項が表示される）ですが、この通り、「このPCは、このバージョンのWindowsをインストールするための最小システム要件を満たしていません」と表示され、インストールの継続ができませんでした。
どうやら、TPM無効でのインストールはできないようで、これすなわちUEFI無効（レガシーBIOS）でのインストールも出来ないことを示しています。
要件非該当環境：VMware vSphere(アップグレード)
次に、当該環境に既に構築済みのWindows 10を用いて、Windows 11へのアップグレードインストールが動作するか確認しました。
この環境はもちろんですが、「PC正常性チェック」ツールでは要件を満たしていない、と言われています。
さて、アップグレードの方法は主に2つあり、
があるのですが、それぞれ両方で試しました。
まず、インストールアシスタントについては、実行するや否や、
「このPCは、Windows11をインストールするための最小システム要件を満たしていません」と表示され、期待する間もなく終わりました。
続いて、インストールメディアから。
こちらは、門前払いではなく、とりあえずツールは起動しましたが、すぐに
「プロセッサがサポートされていない」と言われ、こちらもインストールを進めることが出来ませんでした。
要件非該当環境：Microsoft Hyper-V
次に、Hyper-V + Core i7-4770Kの場合。自作PCでM/BはASUSのZ87-PRO(V EDITION)。
Hyper-Vでの構築時は、
- 世代を「第2世代」にすること
- 構築後、TPMを有効化すること
この状態で仮想マシンを構築します。
こちらも特に問題なく構築完了。少なくとも、仮想環境においてはCPUの型番が要件非該当であることを理由に新規インストールがブロックされることはない事を確認しました。
なお、余談ですが、この構築時にCPUのコア数を標準（1コア）のまま構築してしまい、TPMを無効にしたときと同じ「このPCは、このバージョンのWindowsをインストールするための最小システム要件を満たしていません」というエラーでインストーラが止まり、だいぶヒヤヒヤしました。ただ、ここから、CPUのコア数要件はどうやらブロック対象になるようです。
検証結果からわかりそうなこと
とりあえず、仮想環境においては、TPMさえどうにか前回の記事で書いた方法で実装・設定できれば、例えCPUが古くても（少なくともIvy Lake世代くらいまでは）Windows 11の「クリーンインストールは」できることが確認できたと考えております。また、現時点ではWindows Updateも提供されており、「とりあえずの検証環境」などを目的としたWindows 11の仮想マシンはとりあえずは問題無さそうという結論に至れそうです。大枚叩いてProLiant Gen10とかを取得する必要がない、という事実は本当に胸をなで下ろしました。よかった、本当によかった……。
但し、既存のWindows 10からのアップグレードはけんもほろろ、と言わんばかりで、おそらくこの挙動は物理マシンでも変わらずでしょう。要件を厳格化することはあり得ても、緩和することはおそらくあり得ないでしょうから、CPU要件を満たしていないWindows 10物理マシンからのWindows 11へのアップグレードは諦めましょう。
問題は、物理マシンで、CPUの要件を満たさないマシンへのWindows 11へのクリーンインストールですが、……引き続き情報が欲しい、という気持ちです。おそらく色々な要素があると思います。ただ、インストールが上手くいかない可能性がある、ということは証明できたかと思います。しかも、一応ディスクへの書き込みはされているので、OSを吹き飛ばした、という最悪の結果と一緒に……*3。
こんなところで、今回の検証は終わりにしたいと思います。少しでも何かの参考になれば、幸いです。
おまけ
MSアカウント回避方法
ユーザアカウント作成時に相変わらずMicrosoftアカウントを要求してくるWindowsですが、
今回のMSアカウント回避ポイントは、この画面の「サインイン オプション」のリンクです。これをクリックすると、
このような画面が表示され、「オフライン アカウント」をクリックすれば、MSアカウントを回避できます。検証用環境を建てる時とかの参考になれば。
個人的「ここすき」ポイント
今回は、インストールの最初の方で、PC名の入力を求められます。これ、すごくありがたいです。ここで入力すると、すぐに再起動し、そのままセットアップが継続（アカウントの設定などになる）されます。今まではセットアップが終わった後、「システム」を開いて、名前を変更して、再起動して……という手間があったので、それが不要になったこと、嬉しいですね。
*1:https://blogs.windows.com/windows-insider/2021/08/27/update-on-windows-11-minimum-system-requirements-and-the-pc-health-check-app/
*2:https://www.microsoft.com/ja-jp/software-download/windows11
*3:今回の検証では、空いているSSDを使ったため、実害はありませんが、今使っているPCへのインストールを行った場合、「何もない箱」が生まれることになります
Windows 11に備えて仮想マシンでもTPMを使いたい！ ~ESXi(vSphere)/Hyper-V/VMware Workstationなどでの実現方法~
TL;DR
Windows 11 では最低要件にTPM2.0が追加されました。
www.microsoft.com
物理マシンの話はさておき、普通に仮想マシンを構築すると、多くの場合、TPMは使えません。
「え、じゃあWindows 11は仮想マシンでは動かせないのか！？」となったので色々調べたり実験したりしました。
結果は、少なくとも2021年6月25日現在、仮想WindowsマシンでTPMをどうにかする方法は
- Windowsホスト上で仮想マシンを動かす場合、
- Hyper-Vでやるのが一番簡単
- 少し設定が分かりづらいけどVMware Workstation Proでも可能
- VMware Workstation Playerでは標準では非対応*1
- VirtualBoxは非対応
- ESXiを使う場合、ESXi単体で使う場合はどうひっくり返っても不可
- vCenter Serverを運用している場合は、以下のどちらかを満たすこと
という結論に達しました。この中では特にESXiの場合について、そして無料でKMSを用意する方法としてPyKMIPを使う方法を述べていきます。
なお、先にオチを言っておくと、ESXi環境の場合、どちらにせよ現状（別でグラボが用意されてない場合）WDDMが1.3なのでWindows 11の最低要件を満たしません。
（将来的にどうにかなるのか、ホスト側のハード依存なのか、引き続き精査したいところだけど情報が無い……。誰か教えてください）
※2021年6月26日追記：WDDMのバージョンではWindows 11実行可能かどうかの判定をしていないようで、シンプルにプロセッサがサポートリスト（下記）に載っているかどうか + TPMとかの要件で見ているようです。
ただこの要件表、Windows 10の時点で載ってないマシンに普通にインストールして稼働できているので、現状確実にインストールできるものにだけ「OK」を出している説が出てきました。
なので、「○が出る」ことには意味があっても「×が出る」ことにはあまり意味がないかもです。
docs.microsoft.com
※2021年10月7日追記：CPUの要件については、別途検証記事を書きました。よろしくお願いします。
kokura.hatenadiary.jp
注意事項：
今回紹介する内容は、あくまで「自宅サーバ」や、「検証/開発用環境」などの仮の環境をベースにしたものです。
PyKMIPは安定して稼働する保証はないため、業務の、本番環境として利用する場合は、適切なKMSを購入/契約するか、vSphere Enterprise Plusライセンスを用意してください。
ESXiを使う場合のvTPM事情
ESXiでvTPM(仮想TPM)を使う場合の要件はVMwareの以下のページに記載があります。
docs.vmware.com
vTPM の要件
vTPM を使用するには、vSphere 環境が以下の要件を満たす必要があります。
この要件のうち、厄介なのが「vCenter Server に構成されたキー プロバイダ」というものです。これについて説明していきます。
vSphereのキープロバイダ
vCenter Serverに構築されたキープロバイダ、について『vSphere セキュリティ』ドキュメントには以下のように記載されています。
docs.vmware.com
vSphereで使える「キープロバイダ」には大きく3つあります。
- 標準のキープロバイダ
- 信頼済みキープロバイダ
- VMware vSphere Native Key Provider
このうち、「信頼済みキープロバイダ」については今回割愛します（どうひっくり返っても自宅に入れられるものではないため）。
残りの二つが、今回検討するものになります。
まず、標準のキープロバイダとは。
docs.vmware.com
これはシンプルに「KMIPに対応した外部のKMSサーバを使う」というものです。KMIP1.1に対応していれば何でも良いです。
こちらは他に要件はありません。ライセンスも一番安いEssential Kitとかでもおそらく大丈夫なはずです*3。
次にVMware vSphere Native Key Provider
docs.vmware.com
これは、ESXiホストのライセンスをvSphere Enterprise Plus(最上位ライセンス)にする必要がある代わりに、vCenter Serverの機能としてKMSを提供するというものです。
要件は、以下の3つです。
- vSphere 7.0 Update 2 以降
- ESXi ホストがクラスタに含まれていること（※単一ホストであっても）
- vSphere Enterprise Plus エディションであること
こちらは、ESXiホストにTPMが搭載されていることが推奨はされているようですが、必須要件ではありません。
以上の2つから、自宅や開発環境のような環境でキープロバイダを用意する場合、
- ホストがvSphere Enterprise PlusライセンスかつvSphere 7.0u2以上であるか
- PyKMIPを使って外部KMSを構築する
の2択となります。
vSphere Native Key Providerの設定
まずは簡単な方、vSphere Native Key Providerの設定方法を簡単に紹介します。
なお、この方法はvCenter Server 7.0.2現在のものです。
docs.vmware.com
- 予めクラスタを作成し、ホストをクラスタに所属させます。
- インベントリでvCenter Serverを選択し、「設定」タブを開き、「セキュリティ」内の「キープロバイダ」をクリック
- 左上の「追加」をクリックし、「ネイティブ キー プロバイダの追加」をクリック
- 任意のvSphere Native Key Provider名を入力します（ex: Default）。
- ESXiホストに物理TPMが載っているのを前提にする場合は、「TPM で保護された ESXi ホストでのみキー プロバイダを使用する」のチェックボックスをオンにします。そうでない場合は、ここをオフにしてください。
- 「キープロバイダの追加」をクリックします。
- 「キープロバイダ」の画面に戻ってくるので、追加したキープロバイダをクリックします。
- 下に表示される「詳細」タブ内の「キープロバイダのバックアップ」をクリックします。これは、万が一キープロバイダの設定が壊れてしまったとき、元のキープロバイダを復元して仮想マシンが起動できない状態になるのを防ぐためのものです。
- バックアップファイルをパスワードで保護する場合（推奨）、「ネイティブ キー プロバイダ データをパスワードで保護」をチェックし、パスワードを入力、「パスワードを安全な場所に保存しました」をチェックして下さい。
- 「キープロバイダのバックアップ」をクリック。すると.p12ファイルがダウンロードされます。これがキープロバイダのバックアップです。大切に保管してください。
- 準備完了です。
PyKMIPを使った標準のキープロバイダの設定
次に、「Enterprise Plusなんか買えるわけないだろハゲ！」という人の為に、標準キープロバイダを使う場合について説明します。
標準キープロバイダを使う場合、KMSを建てる必要があります。無料で使えるKMSは、今の所PyKMIPくらいのようなので、導入方法と適用方法を解説します。
なお、検証環境は以下の通りです。
- PyKMIPインストール先環境
- 前提要件
- 証明書が必要です。オレオレでもいいので適当にCAを建てて証明書を作成して下さい。(作成方法は調べればいっぱい転がっていると思うので今回は割愛します。
KMS構築(PyKMIPのインストール)
- 対象のシステムがvCenter Serverから到達可能であることを確認して下さい。
- 必要なパッケージをインストールします。
# apt install python3-dev libffi-dev libssl-dev libsqlite3-dev
- PyKMIP用のディレクトリを作成します。
# mkdir /usr/local/PyKMIP # mkdir /etc/pykmip # mkdir /var/log/pykmip
- PyKMIPをGithubから持って来て、インストールします。
# cd /usr/local # git clone https://github.com/OpenKMIP/PyKMIP # python3 /usr/local/PyKMIP/setup.py install
- 設定ファイルを作成します。
# vi /etc/pykmip/server.conf
[server] database_path=/etc/pykmip/pykmip.database hostname=[vCenter ServerからアクセスするときのこのホストのIPアドレス] port=5696 certificate_path=[証明書ファイル] key_path=[秘密鍵ファイル] ca_path=[証明書のCAファイル] auth_suite=TLS1.2 policy_path=/usr/local/PyKMIP/examples/ enable_tls_client_auth=False logging_level=DEBUG
- 自動起動するためのSystemdのユニットファイルを作成します。
# vi /etc/systemd/system/pykmip.service
[Unit] Description=Python implementation of the Key Management Interoperability Protocol Server Wants=network.target [Service] Type=simple ExecStart=/usr/bin/python3 /usr/local/PyKMIP/bin/run_server.py Restart=no [Install] WantedBy=default.target
- Systemdに登録して起動します。
# systemctl enable pykmip.service # systemctl start pykmip.service
以上でサーバの構築が完了です。PyKMIPのログは /var/log/pykmip/server.log に出力されます。
Logrotateとかはおそらく自分で設定する必要がありそう*4なので、必要に応じて設定して下さい。
KMSのvCenterへの追加
追加方法はNative Key Providerより少し複雑です。
docs.vmware.com
- インベントリでvCenter Serverを選択し、「設定」タブを開き、「セキュリティ」内の「キープロバイダ」をクリック
- 左上の「追加」をクリックし、「標準のキー プロバイダの追加」をクリック
- 名前に任意のキープロバイダ名を入力します。
- KMSには「PyKMIP」、アドレスにPyKMIPを入れたサーバのIPアドレス、ポート番号は「5696」を入力し、「キープロバイダの追加」をクリックします。
- 接続に成功すると「vCenter Server にキー プロバイダを信頼させる」というウィンドウが表示され、先程作成した証明書が表示されます。間違いないことを確認して右下の「信頼」をクリックします。
- キープロバイダの画面に戻って来たら、追加したキープロバイダをクリックします。
- 下に表示される詳細画面の「PyKMIP」の左の「>」をクリックしてウィザードを表示させます。
- 「KMS が vCenter Server を信頼するようにします」の下の「VCENTER SERVERを信頼する」をクリック
- 「方法の選択」が表示されるので、「KMS証明書及びプライベートキー」を選択し、「次へ」をクリックします。
- PyKMIPに設定した証明書と秘密鍵のファイルをアップロードするか、証明書ファイルをエディタで開き、証明書であれば「-----BEGIN CERTIFICATE-----」から「-----END CERTIFICATE-----」まで、秘密鍵であれば「-----BEGIN RSA PRIVATE KEY-----」から「-----END RSA PRIVATE KEY-----」まで（それ自身も含む）をコピーして貼り付けます。
- 「信頼の確立」ボタンをクリックします。
- 正常に完了すれば、上のキープロバイダのリストで、当該項目のステータスが「健全」、証明書が「有効」と表示されます。
KMSを使ったTPMが有効な仮想マシンの作成方法
前述の方法でNative Key ProviderかPyKMIPでKMSを構築完了すると、仮想マシンの作成ができます。
仮想マシンの作成時もいくつかのステップを踏む必要があるので、以下解説します。
- 通常通り、「仮想マシンの作成」を実行
- ストレージの選択の時に「この仮想マシンを暗号化」のチェックボックスにチェックを入れます。なお、その際、チェック後にストレージに「互換性無し」と表示された場合、前述のチェックボックスの下の「仮想マシン ストレージ ポリシー」を「VM Encryption Policy」に変更すると利用できるようになります。
- ゲストOSの選択の際に「Windows 仮想化ベースのセキュリティの有効化」にチェックを入れて下さい。
- ハードウェアのカスタマイズ画面が表示されたら、「新規デバイスの追加」から「Trusted Platform Module (TPM)」を選択して下さい。
以上で完了です。これで仮想マシンにTPMを適用することが出来るようになりました。
ここまででESXiでTPMを使う方法の話は終わりです。ここから先は余談（Windows上の仮想マシンでどうにかする方法と、ESXi仮想マシンでは結局Windows11は動きそうにないという話）です。
Windows上でTPM有効なWindows仮想マシンを建てる方法考察
Windows上で仮想マシンを建てるハイパーバイザソフトウェアには大きく3種類あります。
- Hyper-V：Microsoft謹製のWindowsの機能。昔は使いづらいはトラブルだらけだで苦しめられた
- VMware Workstation系（Player/Pro）：VMwareの製品。Playerは個人使用目的であれば無料、Proは有償。
- VirtualBox：みんな大好き[要出典]Oracleのソフト。
vTPMを使った仮想マシンを建てる難易度は、
Hyper-V（超簡単） > VMware Workstation Pro（やり方さえわかれば） >> VMware Workstation Player（少し面倒くさい） >>>>>>>>>>>>>>> VirtualBox（無理）
という感じです。一応それぞれについて軽く。
Hyper-VでvTPMを有効にする
超簡単です。第二世代仮想マシンの設定で仮想マシンを作った後、「設定」→「セキュリティ」で「トラステッド プラットフォーム モジュールを有効にする」にチェックを入れるだけです。
ハードウェア要件はたしかありません。OSもWindows 10 Proの最新バージョンを使ってれば特に問題ないはずです*5
これでインストール、起動すると無事使えます。そして、Windows11にはもちろん、対応しています。
VMware Workstation ProでvTPMを有効にする
こちらはちょっと面倒くさいです。VMware製品はTPMを有効にする場合は仮想マシンの暗号化が必須となります。そのため、以下の操作が必要です。
この操作をした上で、ハードウェアの追加から「Trusted Platform Module」を選択すると、TPMを追加することが出来るようになります。
ちなみに、Workstation Pro 15の環境で上記の設定を踏まえて建てた仮想マシンは、Windows 11に対応しているようです。
VMware Workstation PlayerでvTPMを有効にする
Workstation Player(無償製品)の場合、vTPMや仮想マシンの暗号化にかかる設定項目がGUI上は表示されないそうです。
こちらは、フォーラムを見ると、VMの設定ファイルを直接いじることでできる、らしいですが、未確認です。（どなたか是非試して見て下さい）
communities.vmware.com
VirtualBoxでvTPMを使う
できない、というのが結論のようです。
forums.virtualbox.org
古い議論ではありますが、下の方を見ると割と最近の投稿もあり、依然TPMの実装はないようです。今までのVirtualBoxの開発の様子も見ていると、まあ、おそらく（少なくともすぐには）実装はされないだろう、というのが私の感想です。
ESXiではWindows 11の仮想マシンが建てられるか
さて、こんな感じで長々と色々検証し、TPMまで用意した、のですが。
（VMware Workstation Proをリモートクライアント画面として使っているので混乱しますが、ESXi上の仮想マシンです）
この通り、ダメでした。原因はVMware ToolsのディスプレイドライバがWDDM 2.xに対応していないためです。
これが、ESXi(vSphere)に起因するモノなのか、ESXiが載っているハードに起因するモノなのかが残念ながら分からず……。もし前者なら、今後VMwareが対応してくれることを祈りましょう。
後者だった場合は……。（目を伏せる）
CPUがサポートリストからはずれているだけっぽいので、引き続き様子を見たいと思います。頼む動いてくれ……！
拡張MIB(Private MIB)からZabbixテンプレートを作る話
TL;DR
1. SNMP関連の環境を整えます
2. 監視したい機器の拡張MIB (もし標準MIBをつかう場合はそれも）を取得します。
3. mib2zabbixをつかいます
github.com
4. あとは気合いで実機で試しながら必要な項目を調整します
以上
経緯とか
これをすることに至った経緯はこちらをご覧下さい。
kokura.hatenadiary.jp
というわけで、mib2zabbixをつかって、存在しないZabbix Templateをつくっていい感じにする話について説明します。
SNMPとかMIBについて
MIBに関する話を理解できる方は次の「やり方」まで飛ばして下さい。
ネットワーク機器やサーバなどの監視には、多くの場合SNMP(Simple Network Management Protocol)をつかって行われます。
SNMPとは何か、MIBの基本についてはざっくりこちらをご参照下さい。
さて、このMIBについて、ネットワーク機器の監視においては主に「標準MIB」と「拡張MIB」を用いて行われます。
標準MIBは 1.3.6.1.2.1 (MIB-II) で定められているもの、拡張MIBは 1.3.6.1.4.1 (enterprise) 以下にベンダ毎に独自で定めているものとなります。
標準MIBは「標準」であるが故に取れる情報も限られており、多くの場合欲しい情報、例えば筐体の稼働状況や温度などは拡張MIBで取得することとなります。
拡張MIBは各ベンダで公開されています。
例として、YAMAHAは以下で公開しています。
YAMAHA private MIB
ですが、この中身ですが、例えばYAMAHAのMIBのうち、YAMAHA-RT-INTERFACEでは、
-- $Id: yamaha-rt-interfaces.mib.txt,v 1.31 2019/06/27 11:54:59 y-nishihara Exp $
YAMAHA-RT-INTERFACES DEFINITIONS ::= BEGIN
IMPORTS
mgmt, NetworkAddress, IpAddress, Counter, Gauge, TimeTicks
FROM RFC1155-SMI
OBJECT-TYPE
FROM RFC-1212
DisplayString, PhysAddress
FROM RFC1213-MIB
TRAP-TYPE
FROM RFC-1215
IANAifType
FROM IANAifType-MIB
yamahaRTInterfaces
FROM YAMAHA-RT;
-- Information of interfaces
yrIfNumber OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of physical and logical network interfaces
(regardless of their current state) present on this
system."
::= { yamahaRTInterfaces 1 }
yrIfTable OBJECT-TYPE
SYNTAX SEQUENCE OF YrIfEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"A list of physical and logical interface entries.
The number of entries is given by the value of
yrIfNumber."
::= { yamahaRTInterfaces 2 }
yrIfBindTable OBJECT-TYPE
SYNTAX SEQUENCE OF YrIfBindEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"A list of binding information entries between
a lower and a higher interfaces. Typical lower
interface is a physical one, and typical higher
interfae is a PP."
::= { yamahaRTInterfaces 3 }こんな感じのものが延々2600行近く、これが数十ファイルあり、これを全部自力で見て必要なものを探し当てるのは至難の業です。
もうちょっと見やすくするMIB Viewer的なツールも無いわけではないですが、多くは有料、無料のものも今では珍しいJavaアプリケーション。大変厳しいものがあります。
というわけで、これをどうしようか、と言うのが今回の話です。
やり方(環境構築~テンプレート完成まで)
やり方は一番最初で説明した通りなのですが、具体的に説明していきます。
なお、ここでは対象の環境として以下の環境を用いています。特にRHEL系などをご利用の場合は適宜読み替えて下さい。(多分素のDebianならこれと同じ方法で出来ると思います）
注意事項
重要：以下の作業を実働中の業務環境/顧客環境/その他停止・障害が基本的に許されない本番環境で実施しないで下さい。
この作業では、実際の監視対象機器に対して試験的に大量のSNMP要求を送ったり、それによって大量のDiscoveryリクエスト/pollリクエストをZabbixが抱える作業を実施します。
そのため、最悪の場合、
- 監視対象機器の停止、遅延、他の監視項目の監視不可
- Zabbix Serverの停止、遅延、負荷の上昇
- これらに起因する様々な問題
が発生する場合があります。必ず別途テスト環境を用意して実施して下さい。
自宅鯖だったり、少人数で運用していてかつミッションクリティカルで無い場合は、問題ないことを確認した上でご自身の判断で実施して下さい。
SNMP環境の整備
テンプレートを作成するためにはMIBをOID形式ではなくアイテム名で認識できる必要があるため、また必要な拡張MIBを認識させるため、以下作業を実施します。
1. パッケージのインストール
# apt install snmp snmp-mibs-downloader
2. 標準のMIBファイルの修正/拡張MIBの読み込み設定
snmp-mibs-downloaderで投入したMIBファイルには一部不具合があるため*1修正します。
MIBファイルは /usr/share/snmp/mibs/ にダウンロードされています。
# wget http://www.iana.org/assignments/ianaippmmetricsregistry-mib/ianaippmmetricsregistry-mib -O /usr/share/snmp/mibs/iana/IANA-IPPM-METRICS-REGISTRY-MIB # wget http://pastebin.com/raw.php?i=p3QyuXzZ -O /usr/share/snmp/mibs/ietf/SNMPv2-PDU # wget http://pastebin.com/raw.php?i=gG7j8nyk -O /usr/share/snmp/mibs/ietf/IPATM-IPMC-MIB
完了後、今後追加される新しいMIBを読み込めるよう、設定を変更します。
--- /etc/snmp/snmp.conf.orig 2021-05-09 12:53:06.458047027 +0000 +++ /etc/snmp/snmp.conf 2021-05-07 05:50:17.757122586 +0000 @@ -1,7 +1,7 @@ # As the snmp packages come without MIB files due to license reasons, loading # of MIBs is disabled by default. If you added the MIBs you can reenable # loading them by commenting out the following line. -mibs: +mibs all # If you want to globally change where snmp libraries, commands and daemons # look for MIBS, change the line below. Note you can set this for individual
3. 拡張MIBの投入
監視したいベンダ/端末の拡張MIBを投入します。ベンダによっては機種毎にMIBが違うこともあるので注意。
保存場所は /usr/share/snmp/mibs/ ですが、もし大量にある場合(依存関係にあるMIBファイルがなく)一回で動かない場合もあるので ~/.snmp/mibs に置くと、万が一の時に標準のMIBを消さずに済みます*2（n敗）。
投入後は、試しにその拡張MIBを含むOIDで snmptranslate コマンドを実行して、動作を確認します。
ここでは試しに、1.3.6.1.4.1.1182.2.3.9.1 を確認します。
$ snmptranslate .1.3.6.1.4.1.1182.2.3.9.1 YAMAHA-RT-INTERFACES::yrIfPpEntry
もしYAMAHAのMIBを適用した場合、このように出てきたら準備完了です。なお、以下のように表示された場合はMIBが読み込まれていません。
$ snmptranslate .1.3.6.1.4.1.1182.2.3.9.1 iso.3.6.1.4.1.1182.2.3.9.1
また、表示される前に何らかのエラーが出ている場合、必要なMIBファイルが揃っていない可能性があります。その場合、何のMIBがないか表示されますので、そのMIBで検索するとMIBファイルが見つかります。
ここまで完了したら、使用するMIBファイルを /usr/share/snmp/mibs/ に移動しましょう。
これで準備完了です。
mib2zabbixの使い方
では、mib2zabbixを使ってZabbix Templateのたたき台を作っていきます。
ホームディレクトリに戻りましたら、mib2zabbixをダウンロードします。
# apt install perl libxml-simple-perl libsnmp-perl $ git clone https://github.com/cavaliercoder/mib2zabbix $ cd mib2zabbix
ダウンロード完了したら、あとはmib2zabbixを実行するのみです。今回必要とするZabbix Templateの範囲のMIBのOIDを確認します。
例えば、YAMAHAのMIBは 1.3.6.1.4.1.1182(YAMAHA-SMI::yamaha) ですが、ルータのMIBだけで良ければ .1.3.6.1.4.1.1182.2(YAMAHA-SMI::yamahaRT) があれば充分です。
さて、今回の例では .1.3.6.1.4.1.1182.2 のZabbix Templateを作るとすると、以下の通りになります。
$ snmptranslate -Tz | mib2zabbix -o .1.3.6.1.4.1.1182.2 -f template-yamaha-RT-mibs.xml -N Yamaha-Router-MIB -e
それぞれ
- -o: 対象のOIDのルート（一番上）を指定
- -f: 出力ファイル名
- -N: テンプレートの(Zabbix上での)表示名（※Zabbix上で変えれるので仮のもので良い）
- -e: 全ての監視項目を有効化
となります。 -e については、付けないと大量の項目を一個一個クリックして有効化する羽目になるので、最初は全部有効にすることをおすすめします。
監視項目の選別
無事Zabbixテンプレートが出力されたら、実際にZabbixにTemplateとして登録し（テンプレート名も修正し）、ホストに適用します。
この際、注意事項として bulkリクエスト は基本的に無効にした方が良いです。
大量のbulkリクエストは監視対象機器のCPU負荷を上昇したり、そもそもSNMP要求が溜まって拒否されることがあります。
実際に適用すると、
- 不要な監視項目（802.1Xを使っていないのにそれ関連の監視項目がある、など）
- 取得不能な監視項目（オブジェクトが存在しない、と言われるもの）
- これに関しては一時的な不具合である可能性もあるため、一旦ホストを無効にし要求を落ち着けた後、Zabbix Serverからsnmpwalkを使って要求を飛ばしてみると良いです。これでも取得出来ない場合は多分その項目は存在しません。
- 例：RTX810は yrhInboxTemperature (.1.3.6.1.4.1.1182.2.1.15.0) は取得出来ません。 RTX1210では取得出来ます。
- これに関しては一時的な不具合である可能性もあるため、一旦ホストを無効にし要求を落ち着けた後、Zabbix Serverからsnmpwalkを使って要求を飛ばしてみると良いです。これでも取得出来ない場合は多分その項目は存在しません。
- 不要ではないものの取得するとZabbix Server/監視機器の負荷が高くなるため取得をしない方が良い項目
等が見つかります。これらを /var/log/zabbix/zabbix_server.log や各監視機器のコンソール/Web GUI などを見ながら調整していきます。
正直これが一番面倒でした。
ここまで出来れば晴れてZabbix テンプレートの完成です。
成果物
上記のアレコレの結果出来たのがこの話です。
kokura.hatenadiary.jp
但し、まだまだやることは残っていて、
- 完全に不要な監視項目を排除出来たわけではない
- 監視項目の名前がMIBのアイテム名のままで可読性が低い
等々、今後も修正していきますのでよろしくお願いします。
おまけ
実際に監視項目の選別の際、何度もRTX1210のCPU使用率を100%に張り付かせたり、Zabbix Serverの負荷が大惨事になったりしました。
実はそれまでZabbix Server は「監視鯖だからそんなにスペックいらないよね」とCore2 Duoとかいう化石を使ってたのですが流石に厳しくなり、NECのExpress5800を導入するに至りました。
石も1個しか置いてないしメモリも4GBだけですが、クロックも高くコア数も倍、何よりバスの速度が速い（あとディスクもSASなのでレイテンシが低い）のでだいぶ楽になりました。
また、監視対象が増えるとZabbixやMySQLも標準の設定でやっていくのがだいぶ厳しくなってきます。
私は以下のように設定して今の所どうにかしています。
- MySQL: innodb_buffer_pool_size=2048M を設定に追加(innodbのバッファを2GBに増やした）
- Zabbix Server: 色々な監視プロセスを標準より増やしたり、キャッシュサイズを増やしたりした
- StartPollers=10
- StartIPMIPollers=3
- StartDiscoverers=4
- CacheSize=512M
- Timeout=10
Zabbixのプロセス数の調整は、実際に自分のサーバでは何のリソースが足りないかを見て調整することになります。Zabbix Serverの監視項目や発生した障害を見ながら調整すると少し幸せになれるかもしれません。
それはそうと、Zabbixサーバを立ててからだいぶ経つのにやっと今更NW機器類の監視が出来るようになったってそれZabbixサーバ持ってる意味ある？（宝の持ち腐れ）
実はpatliteもあるんですが活用できて無くて……この辺も活用できるようになったら記事を書きたいですね。
*1:http://ooltcloud.sakura.ne.jp/blog/201712/article_17222239.html
*2:特にCiscoの場合、かなり沢山のMIBが混ざっており、必ずと言って良いほどエラーが起きますので最初は分離した方がいいです。
IPMI搭載サーバのセンサーデータをHTTP API経由でZabbix監視する仕組みを作った話
経緯とか
昨日は我が家のラックのうちネットワークの部分を見ましたが、サーバの部分はこんな感じになってます。
このうち、下にあるHPE ProLiant DL380p Gen8はESXiなのですが、上にあるNEC Express5800(ここでZabbix Serverが動いている)と更に上の A.T.Works QuadBeagle ZG+は物理Ubuntu Serverとして稼働しています。
さて、我が家ではZabbixにて諸々監視をしようと試みているのは先日お話ししましたが、我が家で動いている物理Ubuntu ServerをZabbixで監視するにあたり、以前より以下の問題がありました。
- lm_sensorsをつかって監視したいのに、
- 温度しか拾ってこない
- 拾ってきてる温度の値もおかしい
- ではIPMIで、とやろうとすると、
- 要求が多すぎるせいか、BMCが落ちる(NEC Express5800)
この状況でどうにか温度/ファン速度を監視できないかと模索したところ、以下の結論にたどり着きました。
1. ローカルでIPMIを取得するコマンドを叩く
2. その結果を何らかの方法でZabbixに送る
3. みんなHappy
今回は、Zabbixからサーバにデータを取得しに行くこととし、取得方法はHTTPエージェント、そのため監視されるサーバ側にセンサのデータをJSONでいい感じに返すHTTP APIを構築することにしました。*1
構成
構成は下図の通りです。
やってることは、
1. 監視対象のサーバ上で ipmitools sensor list コマンドを実行し、その結果をファイルに書き出すのを1分毎に行うcronを挿入する
2. Apache + wsgiなWebサーバを構築し、APIはflask-restfulをつかって受け付ける
3. メインのPythonスクリプトでは、要求があったら1. のファイルを読み込んでparseしてjsonファイルとして応答する
4. HTTPエージェントを使ってjsonを受取り、そのデータをベースにLLDでアイテムを作るZabbix Templateを適用し、1分に1回このAPIにデータを取得しに行く
という感じです。
Githubで公開したコードにはこのうち、
が格納されています。
具体的な構築方法はGithubの方を参照して下さい。
補足
本件、補足としては以下の通りです。
最後に
NEC Express5800でIPMI経由でデータを取得するとBMCが死ぬのはどうやら私だけでは無かったようなので、そう言う方にとって有用に使えることを祈っております。
あと、今回はHTTP Agentを使ったので大変面倒なことになりましたが、普通に監視対象からpy-zabbixとかを使ってアイテムの作成までやってしまった方が（テンプレートも不要で）楽だと思うのでそのうちそっちも作ります。そのうちね。
YAMAHAルータとAlaxalAスイッチ(AX2400S系)のZabbixテンプレートを作った話
TL;DR
- YAMAHAルータとAlaxalAのAX2400S系用のZabbix 5.x用テンプレートを作りました
- YAMAHAの方は、理論上全てのSNMP監視が出来るYAMAHAルータで、AlaxalAの方はAX2400S系で動作します。
- 作るのにはmib2zabbixをつかって、出来たやつを実機で試しながら調整しました。
- 動作確認環境は以下の通り
- 以下で公開しています。
- 追記: Zabbix Shareにも公開しました*1。
share.zabbix.com
share.zabbix.com
以上
経緯とか
ずっと前からおうちサーバはやってたし、Zabbixサーバも置いてたのですが、ろくに監視をしてなかったのでいい加減どうにかしようとおもった（感想）
ここから真面目な話ですが、我が家のラックのネットワーク部分は現在こんな感じです。
利用している機器が、
と、もしこれが会社のNWだったら頭の血管が切れそうなマルチベンダっぷりです。なおこのうち、Cisco 891FJは落ちても困らないルータなので監視から除外するとして、残りの機器をどうにか監視したい気持ちがあります。
このうち、Cisco SG300は既に割と新しめなテンプレートがあります。
share.zabbix.com
バージョンも4.x以降と、いい感じです。
ところが、YAMAHAのルータについては、探して出てくるのは
https://blog.yuu26.com/zabbix-rtx1210/
Zabbix2向けのもので、こちらは試したところエラーでインポートが出来ませんでした。
AlaxalAに至っては全く情報なし。と言うわけでYAMAHAとAlaxalAについては自分で作る事にしました。
その他
これを作る際に mib2zabbix ってやつをつかいました。
github.com
ただもちろんこれつかって入れてほいおわり、……ではなく、実機で実際に要求を送りながらアイテムを最低限整えました。
この辺の話はまた近く別の記事で話そうと思います（多分需要はあると信じてる）
頑張って作りはしましたが、まだアイテム名がMIBのアイテム名のままだったり、「えっこれいる？」みたいなアイテムが残ってたり、他の人の環境でやったら動かねぇ！とか多々あるかと思いますので、よろしければつかっていただいて、何かありましたらTwitterでもGithubでissue立てていただくでも、なんだったら「直したぜ」って言ってプルリクとか立てて戴けたらもう泣いて喜んで三千里という感じでございます。
最後に
世の中にどのくらいいるか分からないけど、RTX1210,RTX810とかのYAMAHAルータや（こっちは結構いそう）AlaxalAのAX2400S系のスイッチ（いる？）のZabbix監視をしたいけどテンプレート作るとか無理だがと思ってる各位に届いてくれ
*1:投稿方法を教えて下さりありがとうございました https://twitter.com/qryuu/status/1391049245428314113
コミックマーケット97 のお知らせ
やっと入稿しました！
遅いぞと言う声はもう耳で蛸が養殖出来るくらいには……。
大変お待たせしました。今回は、「会報 URESHINO Vol.2」です！
「Funnel Advisor公開したはいいけど、それについて書いた本がない」とかいう間抜けを晒した前回の反省を生かし、今回、創刊号の内容も入れつつ、追加要素の説明や、あれからどうなったか、そして何より、「お前技術系ジャンルなのに技術の話してねぇじゃん」という（私の中の勝手な）声にお答えいたしまして、少しではありますが技術的な話も追加させていただきました。
なんだかんだでB5 42Pと読み応えのある量になったのでは無いかと思っておりますので、是非皆様お手にとって頂けますと幸いです。
また、前回頒布しました、「入門 コンピュータリテラシー」も持ち込みますので、こちらもよろしくお願い致します。
お前内容被ってね？
よく見てますね……ありがとうございます。最近両方に投稿するようにしました。ちょっとだけ内容が異なるのは、読むユーザ層の違いを考えてです。多分。おそらく。maybe。
