2023年07月21日(金) - 22:27 | カテゴリ:
Linux
“ns-lab BB”のサーバ管理にAnsibleを多用しているのは言うまでもないが、
サーバをメンテナンスするタイミングを逃して実行環境を放置していた。
昨日、メンテナンスの時間を確保出来たので、
KVMホストのメンテと一緒にAnsible実行環境のアップグレードしたのだが、
Ansible 2.14.2へ変わったのがマズかった。
一部のプレイブックでは以前作成した管理用スクリプトをshellモジュール経由で叩く様にしており、
その中で警告メッセージを減らす為にshell:warnの設定を入れていた。
しかし、Ansible 2.14でshell:warnが削除されたのでエラーで失敗する様になった。
Starting in 2.14, shell and command modules will no longer have the option
to warn and suggest modules in lieu of commands.
The warn parameter to these modules is now deprecated and defaults to False.
Similarly, the COMMAND_WARNINGS configuration option is also deprecated and defaults to False.
These will be removed and their presence will become an error in 2.14.
|
コレに気づかず、アップデート後初のAnsible実行でエラーの嵐が発生。
普段動いていた物が動かなくなったので焦ったが、独自に組んでいたログ取得からデバッグを開始。
表題の通り、shell:warnの所で処理が軒並み停止する事がわかった。
Ansibleの更新履歴を追いかけた所、v2.11のDeprecatedリストにそのまま載っていた。
実行時もwarnオプションが存在しないから削除する様にエラーが出ていたので予想はついていたが、
更新履歴はちゃんと読まないとハマる事があると改めて実感した出来事だった。
………
自宅鯖だからこそ読まずにぶっつけ本番をした結果ハマった原因だが、
流石に自宅鯖で全部追いかけるのは大変なのと、
趣味の範疇だからこそぶっつけ本番チャレンジ出来るのがメリットなので、
敢えてやり方は変えず今回の事も備忘録にしておこうと思う。
2023年03月27日(月) - 21:30 | カテゴリ:
Linux
zabbixの追いかけを放置してProxmoxに浮気している間に6.4がリリースされていた。
最新版が出たとなるとアップグレードして動作を見ておきたいのと、
ついでにバックエンドのMariaDBも同時にメンテを行ってみた。
データベースの方は、MariaDB 10.7からMariaDB 10.11へアップグレードをした。
zabbix 6.4はMaria DB 10.11に対応していないが、
次期マイナーバージョンでは対応予定にもなっているのでLTS適用を優先した。
DBのフルダンプを事前に取得してデータが壊れても復旧出来る様にしてから着手したが、
“mariadb-upgrade”も全てPASSして作業が完了した。
下記の公式マニュアルを事前確認しておいたのも効いた。
………
zabbixの方はZabbix ServerとZabbix Proxyを停止してからバイナリを入れ替えつつ再起動。
コンフィグは一文字も変更せず流用したが無事に起動した。
が、データベースの文字コードと照合順序が古いままだったのと、
主キーが古いままだった事に気づいたので修正も実施。
zabbixを長年動かし続けると遭遇する事が多いデータベース絡みのエラー。
毎回手動で直すのも面倒なので、今回はデータベース自体の照合順序も変更した。
主キー更新はオンラインドキュメントの手順に従い実施したら終わったので割愛。
そんなこんなで文字コード照合順序打ち込んだコマンドは次の通り。
厳密には、もっと丁寧に実施した方が良いが自宅サーバなので手抜きした。
データベース名は”zabbix”に置換しているが大体のコマンドは合っている。
SELECT SCHEMA_NAME,DEFAULT_CHARACTER_SET_NAME,DEFAULT_COLLATION_NAME \
FROM information_schema.schemata \
WHERE SCHEMA_NAME = 'zabbix';
+--------------------+----------------------------+------------------------+
| SCHEMA_NAME | DEFAULT_CHARACTER_SET_NAME | DEFAULT_COLLATION_NAME |
+--------------------+----------------------------+------------------------+
| zabbix | utf8mb3 | utf8mb3_general_ci |
+--------------------+----------------------------+------------------------+
SELECT TABLE_SCHEMA,TABLE_NAME,TABLE_COLLATION \
FROM information_schema.tables \
WHERE TABLE_SCHEMA = 'zabbix' AND TABLE_COLLATION = 'utf8mb3_general_ci';
+--------------+------------------------+--------------------+
| TABLE_SCHEMA | TABLE_NAME | TABLE_COLLATION |
+--------------+------------------------+--------------------+
| zabbix | scim_group | utf8mb3_general_ci |
| zabbix | connector | utf8mb3_general_ci |
| zabbix | userdirectory_saml | utf8mb3_general_ci |
| zabbix | userdirectory_ldap | utf8mb3_general_ci |
| zabbix | userdirectory_media | utf8mb3_general_ci |
| zabbix | userdirectory_idpgroup | utf8mb3_general_ci |
| zabbix | connector_tag | utf8mb3_general_ci |
+--------------+------------------------+--------------------+
ALTER TABLE zabbix.scim_group CONVERT TO CHARACTER SET utf8mb3 COLLATE utf8mb3_bin;
ALTER TABLE zabbix.connector CONVERT TO CHARACTER SET utf8mb3 COLLATE utf8mb3_bin;
ALTER TABLE zabbix.userdirectory_saml CONVERT TO CHARACTER SET utf8mb3 COLLATE utf8mb3_bin;
ALTER TABLE zabbix.userdirectory_ldap CONVERT TO CHARACTER SET utf8mb3 COLLATE utf8mb3_bin;
ALTER TABLE zabbix.userdirectory_media CONVERT TO CHARACTER SET utf8mb3 COLLATE utf8mb3_bin;
ALTER TABLE zabbix.userdirectory_idpgroup CONVERT TO CHARACTER SET utf8mb3 COLLATE utf8mb3_bin;
ALTER TABLE zabbix.connector_tag CONVERT TO CHARACTER SET utf8mb3 COLLATE utf8mb3_bin;
ALTER DATABASE zabbix CHARACTER SET utf8mb3 COLLATE utf8mb3_bin;
|
データベースを弄った後にZabbix ServerとZabbix Proxyを再起動して10分程度動かすと反映される。
………
実際にzabbix 6.4を弄ってみたが目に見えて大きな変更点が無くすんなり弄れた。
公式サイトに書いてある、テンプレートをバージョン管理出来るっぽいのが便利に見えたが、
手動で管理する物では無さそうだった。
zabbix 5.0の時にあったUI変更の様に目に見えた大きな変更点は無かったので、
エンタープライズ用途でも学習コストが少ないのは嬉しい。
その割には内部処理は高速化されているみたいなので暫く動かしてみる。
今回の6.4へのアップグレードはすんなり出来た。
二の足踏んでいる自宅サーバ民ならサクッと実施しても大丈夫だろう。
« 続きを隠す
2023年02月16日(木) - 23:55 | カテゴリ:
Linux
SDNと聞くと、ネットワークをソフトウェア制御する事を浮かべる人が多いはず。
2014～2015年頃にバズワードになって爆誕した後、巷で持て囃された後に衰退期を迎え、
EVPN・VXLANを引っ提げる事で、やっとネットワーク屋に迎えられた気がする。
そんなSDNだが、リソース集約とネットワークの仮想化と言われるだけあり、
高密度にリソースを集約する仮想サーバと相性が良かったりする。
AWSっぽいIaaSを構築出来るOpenStackも一種のネットワーク仮想化技術を用いているし、
VMwareも専用のSDNソリューションを抱えていたりする。
………
VMwareに年貢を払いたくな人向けのソリューションとして、
OSSのProxmoxという仮想サーバアプリケーションがある。
筆者も最近はProxmoxにハマっており、サーバを作ってはぶっ壊すを繰り返して遊んでいる。
Proxmoxでネットワークを組む場合、Linux SwitchかOpen vSwitchの何れかを使う事になるが、
ふと『Open vSwitchが使えるなら、EVPN・VXLANを喋れるのでは？』という疑問が生じた。
アプリケーションがあるならSDNコントローラも準備されていそうな気がしたので調査したら、
まさにVMwareっぽい仮想スイッチも搭載できる事がわかった。
やり方は公式ドキュメントにSDNオーバーレイを構築する設定方法がそのまま載っていた。
標準ではインストールされていないので表示もされないが、
“apt install”すると追加パッケージがインストールされてSDNが使える様になる。
# apt install libpve-network-perl ifupdown2
|
libpve-network-perlをインストールすると、Proxmoxのデータセンター画面にSDN項目が追加され、
EVPN・VXLANを直接設定出来る様になる模様。
設定箇所でオーバーレイネットワークを設定すると、ノード間でトンネルを直接張る様になる。
実際の処理速度やCPU負荷などは未知数だが、Proxmoxで手軽にSDNを組む場合には候補に挙がるはず。
テスト目的でSDNを作る場合、Cisco CSR 1000vやArista vEOSを用いてEVPNとVXLANを組む例が多いが、
Proxmoxで使おうとすると仮想スイッチの制御が煩雑になる。
煩雑な部分を排除しつつ簡単に組めるならメリットもあるので、採用例が今後増えるかもしれない。
とは言っても、ns-lab BBのサーバは仮想ホストはゲストサーバを動かす事に専念させて、
ネットワーク構築はゲストサーバ層で仮想ルータを動かすポリシーなので、実践投入は見送りになりそう。
