2023年02月04日(土) - 21:29 | カテゴリ:
Linux
Proxmoxでゲストサーバを作った場合、
サーバイメージをそのまま保存するのと、ブロックストレージに格納する方法の二つがある。
イメージがファイルとして保存されている場合はイメージを複製バックアップ出来るが、
ブロックストレージの場合はエクスポートが必要だったり手順が面倒になる。
しかも、イメージを複製したとしてもProxmoxでのゲストサーバ設定は複製できないので、
リストアする時にゲストサーバのハードウェア設定もする必要が出てくる。
ProxmoxはWeb画面でゲストサーバのバックアップをする事も出来るが、
リストアはそのままでは出来ない筈なので、コマンドを使って直接リストアが必要となる。
コマンドでゲストサーバのリストアが出来るなら、
コマンドでバックアップも出来ると考え手順を調べてみた所、
Web画面と同様にバックアップを取得する方法が分かったのでメモしておく。
Proxmoxにはqmコマンドというゲストサーバを管理するコマンドが用意されており、
コレを使う事でイメージファイルとコンフィグをエクスポート出来る。
ProxmoxはWeb画面での操作が売りだが、自動化する時には使いやすいコマンドセットとなる。
このコマンドは強力で、非圧縮モードでゲストサーバをエクスポートした後、
“vma extract <file>.vma”を実行すればイメージとコンフィグを分離する事も可能だったりする。
$ qm list
$ qm config <vmid>
$ qm stop <vmid>
$ vzdump <vmid> --compress zstd
$ scp vzdump-qemu-<vmid>.vma.zst remote:~/
$ qmrestore vzdump-qemu-<vmid>.vma.zst <vmid>
$ qm list
|
バックアップ・リストアをコマンドで実行する手順は上記の通り。
コマンドを上手く使えば、クラスタを組んでいないサーバへのマイグレートも可能な筈。
今回の参考サイトは次の通り。というよりも、ドキュメント通りに実行すれば普通に使えた。
数回試してみたが、普通に動いておりゲストサーバも正常稼働している。
ProxmoxにはAPIも用意されているので、同様の事はAPI経由でも実行出来ると思うが、
対話型のshellだからこそ、状況を見ながらチェック出来るのがメリットとなる。
Web画面、shellコマンド、APIを使って上手く操作できる様に環境整備をしていきたい。
« 続きを隠す
2023年01月22日(日) - 22:54 | カテゴリ:
Linux
録画鯖と不要なサーバの統廃合をする為にProxmoxクラスタを作っていた時、それは起きた。
“ns-lab BB”で構築するサーバの基本設計は2台1組のデュアルアクティブ方式なのだが、
Proxmoxも同様に2台1組のスタンドアロン構成で組んでいた。
統廃合によって管理するゲストサーバ台数が増えたので、
管理画面から全台を見れる様にすべく4台クラスタに構成変更したのだが、
メンテナンスで2台停止する時にQuorum判定で過半数を超えられず、
ホストサーバがクラスタに復帰出来ない場合がある事にぶち当たった。
クラスタで良くあるQuorum判定はProxmoxでも有効で、
偶数ノードでクラスタを構築すると過半数を超えられずメンテ時に嵌る
実際に2台のホストを停止した状態が次の画像だが確実にNO判定になってしまい、
無理やりホストを起動してもゲストがエラーを吐いて起動出来なかった。
そもそも、後から起動したProxmoxノードがクラスタに参加出来なかったりする。

ググると“pvecm expected 1”でQuorum判定をYESに変更して復帰させる手法が出てくるが、
試した限り確実に復帰できるわけでは無く、正常に復帰出来なかった事も半分位あった。
この問題は最終的にクラスタノードを何回か再起動すると直る事が多いのだが、
クラスタ構成のイロハの通り、Proxmoxノードも奇数にしておく必要があると身をもって実感した。
4台でクラスタを組んだ状態のProxmoxクラスタステータスは次の通り。
Quorumが過半数を超える様にする必要があるので、自動的に”3″が入力される事となる。
# pvecm status
Cluster information
-------------------
Name: cluster
Config Version: 4
Transport: knet
Secure auth: on
Quorum information
------------------
Date: Sun Jan 22 hh:mm:ss 2023
Quorum provider: corosync_votequorum
Nodes: 4
Node ID: 0x00000001
Ring ID: 1.11
Quorate: Yes
Votequorum information
----------------------
Expected votes: 4
Highest expected: 4
Total votes: 4
Quorum: 3
Flags: Quorate
Membership information
----------------------
Nodeid Votes Name
0x00000001 1 192.168.x.1 (local)
0x00000002 1 192.168.x.2
0x00000003 1 192.168.x.3
0x00000004 1 192.168.x.4
|
この状態で2台落とす、前述の通りともれなく面倒な事になる。
どうやってコレを解決するか考え中だが有力候補はラズパイでモニタ用Proxmoxを構築する事。
Pimoxというラズパイ用Proxmoxがあるので、構築してモニタ機に仕立てれば過半数を超えられる。
他にはProxmoxをゲストサーバとしてProxmox上に構築してモニター専用機にする方法も検討中。
Nested Virtualizationになるので動作は重くなるが、
クラスタ参加して過半数を超えられれば良いので動けばOK理論でやるかもしれない。
しかし、万が一クラスタが壊れてもゲストサーバは稼働し続けてくれる事が分かっているので、
一旦はこのまま構築を進めて自鯖弄りの糧にしようと思う。
進めている統廃合を先に完了させないと検証環境を維持できないので、時間を見つけて進めねば。
« 続きを隠す
2023年01月14日(土) - 19:10 | カテゴリ:
Linux
自鯖の本番KVMホストサーバはkimchiを使ってゲストサーバをGUI管理しており、
このアプリの必須コンポーネントにnovncが含まれている。
最近、CentOS7の更新で降って来たnovnc 1.3.0-5へアップグレードしようとしたら、
次の依存エラーが表示されてアップグレード出来なかった。
Resolving Dependencies
--> Running transaction check
---> Package novnc.noarch 0:0.5.1-2.el7 will be updated
---> Package novnc.noarch 0:1.3.0-5.el7 will be an update
--> Processing Dependency: python3-websockify for package: novnc-1.3.0-5.el7.noarch
--> Finished Dependency Resolution
Error: Package: novnc-1.3.0-5.el7.noarch (epel)
Requires: python3-websockify
|
エラー内容そのままだが、novnc 1.3.0-5を動かす為にはpython3-websockifyが必要になった模様。
CentOS7はpython2.7系なので、そのままではpython3-websockifyがインストール出来ず、
依存関係を解決出来なくてアップグレードに失敗した。
CentOS7でpython3を使うにはIUSのサードパーティリポジトリを追加する事が多いが、
IUSでpython3-websockifyを配っていないので、最終的に手動インストールが必要になる。
どうするか迷ったが、筆者は今回のnovncアップグレードを見送る事に。
頑張れば依存関係を解決出来そうだが手動インストールするとカオスになるので、
安定重視の本番KVMホストで試すのは諦めた。
CentOS7のEOLが2024年06月な事もあり、来年には刷新が必要なのでその時に直そうと思う。
それまでは、アップグレード時にexclude指定して乗り切る予定。