Proxmox VE叢集cluster遇到的狀況

前陣子使用兩台PC安裝pve, 做成cluster方便管理, 但遇到其中一台只要使用zfs就會出錯, 另一台是正常的.

可是有一天遇到停電. 重開機之後, 另一台原本zfs正常,居然出現找不到zfs的錯誤訊息.
當時我登入到第一台查看, 系統出現zfs硬碟正常的, 但總是無法透過GUI介面新增回來, 最後發現, 我應該要登入第二台,才可讓zfs重新回來, 原來這兩台是合作, 又保有各自隱私呢.
哈!, 使用storage server習慣了, 遇到沒有storage server就手忙腳亂一番, 因此記錄下來.

pve maintenance mode

先前遇到一件事情, 其實說來話長, 也是因為covid-19造成的
因為無法親自到公司越南廠處理pve server, 偏偏又遇到pve不穩的狀況, 只好移除一些當時手動掛載的硬碟.

這下好了, 請當地的電腦公司人硬是移除手動掛載的硬碟 , 重開機後發現總是進入maintenance mode,
搞了好久才發現必須把/etc/fstab 的手動掛載硬碟資訊移除, 才能正常開機, 因此紀錄一下,以免重蹈覆轍.

pve 6上調整zfs快取大小

我自己在pve 6上使用zfs的經驗不是很順利;有遇到慢的、不穩的,現在可能還需要調整zfs的快取大小,才能讓zfs順利使用。
新增一個檔案 /etc/modprobe.d/zfs.conf
並修改如下:

範例為最小4G, 最大16G, 可自行依照主機實力設定,千萬不可多。 修改後重開機, 可下arcstat 查詢是否成功

options zfs zfs_arc_min=4294967296
options zfs zfs_arc_max=17179869184
options zfs zfs_flags=0x10

安裝PVE 注意事項

PVE8 注意事項(2023-8-11)

1. 修改 /etc/apt/sources.list.d/ceph.list
#若沒有訂閱,請全部加上 #
#deb https://enterprise.proxmox.com/debian/ceph-quincy bookworm enterprise
2. 修改/etc/apt/sources.list.d/pve-enterprise.list
#deb https://enterprise.proxmox.com/debian/pve bookworm pve-enterprise
#deb http://enterprise.proxmox.com/debian/pve bookworm pve-no-subscription
deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription
deb http://ftp.debian.org/debian bookworm main contrib
deb http://ftp.debian.org/debian bookworm-updates main contrib
deb http://security.debian.org/debian-security bookworm-security main contrib

接下來執行apt update;apt upgrade就可以了


PVE 6 注意事項

  1. 設定自動更新
    修改/etc/apt/sources.list.d/ 裡面的檔案

    deb https://enterprise.proxmox.com/debian/pve buster pve-enterprise
    改成
    deb http://enterprise.proxmox.com/debian/pve buster pve-no-subscription
    請注意免費版是存取http, 非訂閱版的https , buster 代表pve 6版
    修改完畢, 執行 apt update ; apt upgrade
  2. 建議安裝套件
    apt install multipath-tools lsscsi
  3. ZFS相關(2023-01-07 安裝pve 7.3時若zfs停止同步功能,會遇到當機)
    *若使用內建的zfs功能, 請考慮關掉sync功能,避免讀取過慢,造成當機
    執行
    #zfs list 取得raid pool name
    zfs list
    zfs set sync=disabled <raid pool name>
    zfs get sync <raid pool name>

    *若zfs壞了, 無法zpool import , 有時候可以清除label , 並且以readonly掛載起來
    zpool labelclear /dev/sda
    zpool import  -f -o readonly=on  <zfs pool name>
  4. 掛載硬碟到directory, 反悔解除後上面的路徑還在
    此時可以到/etc/systemd/system把該硬碟的檔案刪除, 重新刷新pve,就不會出現了
  5. 以後想到會補充在這裡

Promox VE神救援的故事, workflow GP 3.1

在這虛擬化盛行的年代, 偏偏就有很多軟體開發商, 還在抗拒虛擬化, 害怕一旦虛擬化後,將更容易被盜用,造成損失.

他們的做法主要有二,
一是綁定usb key , 讓你虛擬化後,還是得依賴usb key;
另一是軟體自行偵測是否處在虛擬環境, 若是就拒絕運行,有些則是偵測後,最後還是綁定一台實體主機, 進行授權檢查.

其實在我看來, 他們就是打著反盜版侵權的旗幟, 實際上強力控制客戶.

以台灣最有名的ERP廠商為例子 , 朋友10年前購買workflow GP 3.1 , 當時並沒有告知會鎖定實體主機, 直到朋友公司因為主機老舊,需要重新安裝, 卻出現安裝到虛擬伺服器上, 無法使用的情形, 詢問後, 才知道必須另外在一台實體主機上安裝授權程式, 並且支付ERP廠商”產生“授權序號的費用, 才能使用.

ERP廠商說得好聽就是請記得購買維護, 這些都可以免費協助, 說難聽就是要綁架,要控制這家公司的, 強力取得維護.

其實老實說, 大部分的公司都願意購買維護, 大可不需要用這種手段, 讓IT難為.

萬一實體主機壞了, 系統就停擺, 要等他們處理, 但他們卻沒有想過, 萬一產品停產, 不再維護, 或公司倒了怎麼辦?

後來我跟朋友在一個場合遇到, 才聊到他的問題, 於是我就幫忙檢視一下, 朋友公司使用ESXi 6.5 , 真的無法運行, 仿間小技巧都無法騙過ERP軟體的偵測.

我左思右想,居然橫空出現一個想法, 2010那個年代, 大部分的IT只知道vmware出的虛擬伺服器, 因此我猜測ERP廠商大概也就只會偵測vmware, 並不會偵測qemu , promox ve.

嘿嘿, 於是我立馬安裝了promox ve這個虛擬伺服器系統, 再重建workflow erp系統, 果然成功了, erp軟體一點都沒發現身處虛擬環境, 運行正常.

後話, 我還是建議朋友購買維護, 畢竟他們的ERP專業很夠, 但系統建置這方面就小鼻子小眼睛, 就讓人非常不認同.

會用到這類軟體的公司, 營收都是億來億去, 豈會虛擬化後, 還複製到別處使用, 況且這樣的軟體,一般還要經過上課, 顧問輔導, 系統開帳才有辦法使用, 會願意這樣做的公司, 還會盜用?

系統移轉在驚喜中完成,有promox ve真好!又推坑一家公司了.

用docker安裝視訊會議 jitsi-meet

jitsi 大名鼎鼎, 我們公司用了10年的openfire內部即時通訊(xmpp server), 用戶端就是用jitsi(我都簡稱神燈巨人).

多年前發現 jitsi 有meet套件可以套用在openfire裡面, 使用結果好爛幾乎不能用, 用ubuntu安裝,也一直很不穩定, 改版很頻繁.

隨著新冠病毒出現, 節神 丟出開源視訊這個議題,我才想起應該是時候,要再測試看看了, 試用結果還不錯,可以讓公司的人使用.

**經過多次測試, 建議使用 “虛擬機加單個對外ip網卡” (非docker,無nat) 才能真正穩定 – 2020/05/06

https://github.com/jitsi/docker-jitsi-meet

# 先想好要用哪個主機名稱, 先把letsencrypt搞定
certbot-auto certonly --standalone --preferred-challenges http -d <full host name>

1.
# root
# 下載最新的版本, 複製預設的設定檔案
git clone https://github.com/jitsi/docker-jitsi-meet && cd docker-jitsi-meet
cp env.example .env

1.1 安全性增加了
./gen-passwords.sh

2.修改 .env , 視自己docker狀況調整以下參數
CONFIG=~/.jitsi-meet-cfg
# Exposed HTTP port
HTTP_PORT=8000

# Exposed HTTPS port
HTTPS_PORT=8443

# System time zone
# 這我調整taipei
TZ=Asia/Taipei

# Public URL for the web service 
# 這我是沒調整,因為我是用httpd reverse proxy
#PUBLIC_URL=https://<full host name>

ENABLE_LETSENCRYPT=1
# 告訴 jitsi 說我的letsencrypt是什麼
LETSENCRYPT_DOMAIN=<full host name>

3.依照.env的 CONFIG 參數, 建立相關目錄
mkdir -p ~/.jitsi-meet-cfg/{web/letsencrypt,transcripts,prosody,jicofo,jvb}

4.視情況修改 docker-compose.yml 
        volumes:
            - ${CONFIG}/web:/config
            - /etc/letsencrypt:/etc/letsencrypt
            - ${CONFIG}/transcripts:/usr/share/jitsi-meet/transcripts

5.上線兼啟動(這部份讓人產生錯覺,很快網頁可以連線,但實際上要5分鐘才正常,畢竟用了4個container)
docker-compose up -d

6.修改解析度(這我沒怎麼測試,預設是720,為了頻寬著想,所以改480)
# ~/.jitsi-meet-cfg 這個目錄依剛開始安裝的.env設定而不同
cd ~/.jitsi-meet-cfg/web
vi config.js
##
     constraints: {
         video: {
             aspectRatio: 16 / 9,
             height: {
                 ideal: 480,
                 max: 480,
                 min: 240
             }
         }

     },

Optional

1. 啟用認證
# 修改 .env 啟用登入認證(我使用最基本的內部認證, ldap怎麼都不成功...XD)
# Enable authentication
ENABLE_AUTH=1
# Enable guest access
ENABLE_GUESTS=0
# Select authentication type: internal, jwt or ldap
AUTH_TYPE=internal

1.1 啟用內部認證後,如何新增使用者
# 進入container
docker exec -it docker-jitsi-meet_prosody_1 bash
# 建立使用者,後面那串meet.jitsi不需要修改哦
prosodyctl --config /config/prosody.cfg.lua register <使用者名稱> meet.jitsi 

2. 增加google日曆功能

1 先想好使用哪個google 帳號讓大家能自由存取,可個人帳號也可使用g suite帳號
建議該帳號的calendar只用來預約會議室使用

2 登入進入 https://console.cloud.google.com/apis/dashboard 
新增project,進入Credentials新增 OAuth 2.0 client IDs , 新增後會給你一個client id,記下來
xxxx.apps.googleusercontent.com

3 進入 AAuth consent screen , 設定該 auth 的使用範圍
4 修改 vi ~/.jitsi-meet-cfg/web/config.js
啟用google calendar , 加上先前的client id,
enableCalendarIntegration: true,
googleApiApplicationClientID:”xxx.apps.googleusercontent.com”,
5.重啟
cd ~/docker-jitsi-meet/ ; docker-compose restart
6 登入jitsi meet 進行相關授權, 若出現未經允許存取calendar,就不管了,允許吧.

https://github.com/jitsi/jitsi-meet/blob/master/doc/integrations.md

1 2 3 4