自宅ラボの仮想化基盤を VMware ESXi から Proxmox VE に移行した。 動機 自宅ラボでは2台の物理マシンに VMware ESXi をインストールして仮想化基盤を構築しているが、VMUG Advantage 会員になることをケチっていたため vMotion を使えない状態だった。 仮想ホストのメンテナンスをしようと思っても VM の停止を許容するしかなかった。 そんな折、オープンソースの Proxmox VE という仮想化プラットフォームの存在を知った。 Proxmox VE であれば無償で仮想化基盤の HA クラスタを組むことができるとのことで、ESXi から Proxmox VE に切り替えることにした。 AWS SAA の勉強をしないといけない現実から目を逸しているだけ。 Proxmox VE とは Proxmox VE (Virtual Environment) は、Debian ベースの仮想化プラットフォームで、KVM による仮想マシン環境と LXC によるコンテナ環境が提供されるらしい。 KVM も LXC も使ったことがないので実際どんなものかは分からない。 複数の物理マシンを用意すれば無償でクラスタを組むことができる（大事になことなので2度言う）点が VMware 製品とは異なり、個人的に大きなメリットと感じた。 また、試せてはないけど Proxmox VE のストレージとして Ceph を構築できるらしい。 物理マシンがもう1台欲しくなっちゃうけど時期が悪すぎる。 Proxmox VE 導入 ESXi から Proxmox VE に VM を移行する。 手順は Proxmox 公式 Wiki の Migration of servers to Proxmox VE を参考にした。 ...

Ceph クラスタ用のラズパイ 4 に PoE+ HAT を導入しました。 PoE+ HAT にはファンも内蔵されているのですが、このファンが煩いです。 ラズパイ本体の温度によってファンの回転数が変わるようなのですが、頻繁に回転数が変わります。 温度をみたところ 50℃ 前後を行き来していて、どうやら 50℃ を境に回転数が上がるようです。 書斎にラズパイを置いているのですが、これでは全く集中できません。 ファン回転数の閾値を変更して、騒音レベルを下げます。 どうやって PoE+ HAT のファンを制御するかググったところ、Raspberry Pi OS ではシステム設定用のファイル /boot/config.txt に下記のような設定を追加すればよいようです。 dtoverlay=rpi-poe-plus dtparam=poe_fan_temp0=40000,poe_fan_temp0_hyst=2000 dtparam=poe_fan_temp1=45000,poe_fan_temp1_hyst=2000 dtparam=poe_fan_temp2=50000,poe_fan_temp2_hyst=2000 dtparam=poe_fan_temp3=55000,poe_fan_temp3_hyst=5000 dtparam に設定するパラメータは意味はラズパイ Firmware の README に書いてありました。 パラメータ 内容 デフォルト値 poe_fan_temp0 ファンがオンになる温度 40000 poe_fan_temp0_hyst ファンがオフになるまでの温度差 2000 poe_fan_temp1 ファンが速度を上げる温度 45000 poe_fan_temp1_hyst ファンが減速する温度差 2000 poe_fan_temp2 ファンが速度を上げる温度 50000 poe_fan_temp2_hyst ファンが減速する温度差 2000 poe_fan_temp3 ファンが速度を上げる温度 55000 poe_fan_temp3_hyst ファンが減速する温度差 5000 Ceph クラスタ用ラズパイの OS には Fedora を使っているのですが、Raspberry Pi OS とは config.txt の場所が異なっており /boot/efi/config.txt にありました。 ...

RHEL 9 がリリースされたので自宅ラボの RHEL 8 をアップグレードしようとしたところ、CPU がサポート対象外となっておりアップグレードできませんでした。 【結論】AMD Zen/Zen+/Zen 2 のマシンは RHEL 9 にアップグレードできない 先に結論から言うと、AMD Ryzen 5 3400G を使っている自宅ラボの仮想化基盤上のマシンが RHEL 9 にアップグレードできませんでした。 どうやら AMD Zen/Zen+/Zen 2 のマシンは RHEL 9 にアップグレードできないようです。 以下、アップグレードの流れとともに上記結論を判断した理由を説明します。 アップグレードの事前チェック RHEL 9 の公式ドキュメントに RHEL 8 からのアップグレード手順が載っていました。 RHEL 8 から RHEL 9 へのアップグレード Red Hat Enterprise Linux 9 | Red Hat Customer Portal この手順に則って、leapp コマンドを使ってアップグレードの事前チェックをしました。 $ leapp preupgrade --target 9.0 ==> Processing phase `configuration_phase` ====> * ipu_workflow_config IPU workflow config actor (snip) ============================================================ UPGRADE INHIBITED ============================================================ Upgrade has been inhibited due to the following problems: 1. Inhibitor: Firewalld Configuration AllowZoneDrifting Is Unsupported 2. Inhibitor: Leapp detected a processor which is no longer supported in RHEL 9. Upgrade cannot proceed. Consult the pre-upgrade report for details and possible remediation. ============================================================ UPGRADE INHIBITED ============================================================ (snip) すると、赤く UPGRADE INHIBITED という文字が表示されて終了しました。 どうやら RHEL 9 へのアップグレードができない状態のようです。 ...

Red Hat Developer Subscription for Individuals を再登録した記録です。 RHEL 9 へのアップグレードを試す RHEL 9 がリリースされました！ 自宅ラボに Red Hat Developer Subscription for Individuals (以下、Developer Subscription) というサブスクリプションを使って RHEL 8 サーバを構築しています。 Developer Subscription とは、Red Hat が提供してくれる個人向けの無料プログラムで、Red Hat Enterprise Linux (RHEL) を 16 台まで利用することができます。 詳しくは以下の FAQ を参照してください。 No-cost Red Hat Enterprise Linux Individual Developer Subscription: FAQs | Red Hat Developer 早速、公式ドキュメントの手順を参照してアップグレードを試みました。 第3章 アップグレードの準備 Red Hat Enterprise Linux 9 | Red Hat Customer Portal 手順通り、RHEL 8 サーバにサブスクリプションが割り当てられているか確認しました。 ...

Cephadm で構築した Ceph クラスタのホストをメンテナンスする手順です。 今回は 3 台構成 (ceph1/ceph2/ceph3)の Ceph クラスタのうち、ceph1 をメンテナンス対象としています。 バージョン 本記事で利用している Ceph のバージョンです。 $ ceph version ceph version 16.2.7 (dd0603118f56ab514f133c8d2e3adfc983942503) pacific (stable) 事前確認 はじめに、メンテナンス対象ホストを停止してもクラスタに影響が出ないかチェックします。 ceph orch host ok-to-stop コマンドを使うことでチェックしてくれます。 $ ceph orch host ok-to-stop ceph1 ALERT: Cannot stop active Mgr daemon, Please switch active Mgrs with 'ceph mgr fail ceph1.eqphaf' 今回はアラートが出力されてしまいました。 ceph1 の MGR がアクティブ状態となっているためホストの停止ができないようです。 次のコマンドでスタンバイ状態の MGR へフェイルオーバーします。 $ ceph mgr fail ceph1.eqphaf フェイルオーバーが成功したか Ceph クラスタの状態を確認します。 ceph -s cluster: id: dc32e976-d0ea-11ec-bac3-dca6329a21a7 health: HEALTH_ERR (snip) services: mon: 3 daemons, quorum ceph1,ceph2,ceph3 (age 4m) mgr: ceph3.mlmhqd(active, since 9s), standbys: ceph1.eqphaf, ceph2.rlgifo osd: 6 osds: 5 up (since 68m), 5 in (since 12h) 今回は ceph1 の OSD が落ちている状態なのでエラーが出ていますが無視してください。 ...

Ceph OSD が落ちるなどして PG (Placement Group) でエラーが出た場合の修復手順です。 我が家のラズパイ Ceph は頻繁に OSD が落ちます。 そのせいで PG のエラーも多発しており、都度対応しています。 PG のエラー状況に応じた修復手順をこの記事に掲載していきます。 免責 本記事では個人利用の Ceph クラスタに対して実施した手順を掲載しています。 PG の修復はデータ損失を伴う可能性があります。 掲載内容によって生じた損害等の一切の責任を負いかねますのでご了承ください。 （大事なことなので） バージョン 本記事で利用している Ceph のバージョンです。 $ ceph version ceph version 16.2.7 (dd0603118f56ab514f133c8d2e3adfc983942503) pacific (stable) 状況確認 OSD が落ちた Ceph クラスタの状況を確認します。 ceph health detail コマンドで Ceph クラスタの状況を確認すると、PG_DAMAGED や PG_DEGRADED といったアラートが上がっていて、PG に active+clean+inconsistent などがマークされています。 $ ceph health detail (snip) [WRN] OBJECT_UNFOUND: 4/1615 objects unfound (0.248%) pg 2.1f has 1 unfound objects pg 2.3 has 1 unfound objects pg 2.7 has 1 unfound objects pg 2.e has 1 unfound objects [ERR] OSD_SCRUB_ERRORS: 6 scrub errors [ERR] PG_DAMAGED: Possible data damage: 4 pgs recovery_unfound, 4 pgs inconsistent pg 2.3 is active+recovery_unfound+degraded, acting [7,5,0], 1 unfound pg 2.7 is active+recovery_unfound+degraded, acting [1,0,6], 1 unfound pg 2.9 is active+clean+inconsistent, acting [7,1,0] pg 2.d is active+clean+inconsistent, acting [0,1,7] pg 2.e is active+recovery_unfound+degraded, acting [6,5,4], 1 unfound pg 2.15 is active+clean+inconsistent, acting [4,6,5] pg 2.1b is active+clean+inconsistent, acting [0,1,7] pg 2.1f is active+recovery_unfound+degraded, acting [6,4,1], 1 unfound [WRN] PG_DEGRADED: Degraded data redundancy: 12/4845 objects degraded (0.248%), 4 pgs degraded pg 2.3 is active+recovery_unfound+degraded, acting [7,5,0], 1 unfound pg 2.7 is active+recovery_unfound+degraded, acting [1,0,6], 1 unfound pg 2.e is active+recovery_unfound+degraded, acting [6,5,4], 1 unfound pg 2.1f is active+recovery_unfound+degraded, acting [6,4,1], 1 unfound PG の状態に応じて対処していきます。 ...

Cephadm のアラート CEPHADM_FAILED_DAEMON を消す方法です。 ...

自宅ラボでは Cephadm を使ってラズパイに Ceph クラスタを構築して遊んでます。 今回は Ceph の Zabbix モジュールを使って Zabbix からラズパイ Ceph クラスタを監視できるようにします。 ただモジュールを有効化するだけでは Zabbix から監視できなかったので、手順を残します。 ちなみにラズパイ Ceph クラスタは CentOS/RockyLinux/AlmaLinux 各種 OS を使った混合環境です。 本当はクラスタ構築の話から投稿したかったのですが、モチベの関係で先にこのネタから投稿します。 Zabbix モジュール有効化 Ceph Manager Daemon (MGR) は、モジュールという形でダッシュボード機能や他製品との連携機能を提供しています。 Cephadm 自体も「Orchestrator モジュール」を使って Ceph を管理しているようです。 公式のモジュール一覧は ここ （でいいんですかねぇ…？） MGR のモジュールの中に「Zabbix モジュール」があるので、このモジュールを有効化して使います。 ceph mgr module enable zabbix Zabbix モジュールのパラメータのうち、以下の 2 つを設定します。 zabbix_host: Zabbix サーバのホスト名 identifier: Zabbix に登録する Ceph クラスタ名 ceph zabbix config-set zabbix_host zabbix.example.com ceph zabbix config-set identifier raspi-ceph 今回はその他のパラメータはデフォルト値のまま使いました。 以下のコマンドでパラメータを確認します。 ...

2021 年も残すところ数日ということで、少し早いですが今年 1 年間の振り返りと来年の抱負を掲げます。 ...

Red Hat が提供するエンタープライズなコンテナ・プラットフォーム「OpenShift」がシングルノードに対応したようです。 Meet single node OpenShift: Our newest small OpenShift footprint for edge architectures The cloud native approach to developing and deploying applications is increasingly being adopted in the context of edge computing. However, edge workloads and use cases span a myriad of locations, technical requirements, and physical footprints. www.redhat.com そうとなれば試してみたい欲求が抑えられませんよね？ というわけで要件を満たす機器を選定するところから SNO (Single Node OpenShift) を導入してみました。 ハードウェア要件 SNO をインストールするには以下のスペックが必要です。 プロファイル CPU メモリ ストレージ 最低限 8 vCPU コア 32 GB 120 GB 普通(?) の OpenShift だとコントロールプレーンで 4 コア/16 GB、コンピュートノードで 2 コア/8 GB が最小要件となっているので、一台辺りのスペックは高くなってしまいます。 一台でコントロールプレーンとコンピュートノードの役割を担うのでそこら辺は仕方ないですね。 ...