Jak zmienić nazwę klastra Proxmox

Wstęp

Zakładałeś klaster pewnie w pośpiechu - dwa, trzy node’y, trzeba było wybrać jakąś nazwę, więc powstało coś w stylu test, pve-cluster albo, co gorsza, nazwa firmy, z której się w międzyczasie wyprowadziłeś. Miesiące później nazwa razi w oczy przy każdym pvecm status, a Ty otwierasz dokumentację w nadziei na proste pvecm rename. Nie znajdziesz takiej komendy. Oficjalna dokumentacja Proxmox wprost mówi o nazwie klastra: “Use a unique name for your cluster. This name cannot be changed later.” Krótko: nie da się. A jednak - da się, tylko nie przyciskiem w GUI, tylko ręczną edycją configu i zrozumieniem, co się dzieje pod maską. W tym wpisie pokażę jak to zrobić w miarę bezpiecznie, dlaczego Proxmox tego nie ułatwia i na co uważać, zanim wydasz pierwsze systemctl restart corosync.

Dlaczego to nie jest proste

Nazwa klastra w Proxmoksie nie jest osobnym ustawieniem gdzieś w bazie - to parametr cluster_name w sekcji totem pliku /etc/pve/corosync.conf. Ten plik żyje w pmxcfs - specjalnym systemie plików opartym o bazę SQLite, który w czasie rzeczywistym replikuje konfigurację klastra do wszystkich node’ów. Corosync odpowiada za komunikację między node’ami i ustalanie kworum, a cluster_name jest jego identyfikatorem klastra używanym w tym protokole.

Problem w tym, że każda zmiana w corosync.conf musi być zsynchronizowana wszędzie naraz, a config_version w pliku to jedyny mechanizm, który mówi node’om “to jest nowsza wersja configu, zaakceptuj ją”. Jeśli zmienisz nazwę i zrestartujesz corosync tylko na części node’ów, przez chwilę będziesz mieć dwie grupy demonów corosync, które nie chcą się ze sobą dogadać, bo każda widzi inną tożsamość klastra w pamięci procesu, dopóki nie przeładuje configu. W praktyce trwa to sekundy, ale przy klastrze z HA i uruchomionymi maszynami lepiej to zrobić świadomie niż na hura.

Stąd ostrożność w oficjalnej dokumentacji - to nie jest funkcja, której ktoś w Proxmoksie testował na wszystkich możliwych topologiach (QDevice, wiele linków corosync, HA), więc zamiast ją wspierać połowicznie, wolą napisać “nie da się”.

Zanim zaczniesz

Kilka rzeczy do sprawdzenia przed edycją:

• Masz dostęp SSH do każdego node’a w klastrze - zmianę trzeba wprowadzić wszędzie, nie tylko tam, gdzie akurat jesteś zalogowany.
• Klaster ma kworum (pvecm status pokazuje Quorate: Yes). Nie baw się w to w trakcie awarii sieciowej czy przy martwym node’zie.
• Masz kopię /etc/pve/corosync.conf na wszelki wypadek, np. cp /etc/pve/corosync.conf ~/corosync.conf.bak.
• Używasz QDevice? Po zmianie nazwy będziesz musiał go usunąć i dodać ponownie - certyfikat QDevice jest powiązany ze starą nazwą klastra i po zmianie zacznie zgłaszać błędy o nieprawidłowym certyfikacie.

Krok po kroku: zmiana nazwy klastra

1. Sprawdź obecny stan

Na dowolnym node’zie:

pvecm status
cat /etc/pve/corosync.conf

Zwróć uwagę na sekcję totem i aktualny config_version w sekcji cluster. Będziesz go za chwilę potrzebować.

totem {
  cluster_name: stary-klaster
  config_version: 4
  ...
}

cluster {
  config_version: 4
  ...
}

W nowszych wersjach Proxmoksa config_version bywa też osobno w bloku cluster na końcu pliku - podbij obie wartości, jeśli obie występują.

2. Edytuj corosync.conf

Plik /etc/pve/corosync.conf wystarczy edytować na jednym node’zie - to katalog /etc/pve/ jest tym magicznym, replikowanym przez pmxcfs, więc zmiana rozejdzie się sama, o ile jest poprawna składniowo i ma wyższy config_version.

nano /etc/pve/corosync.conf

Zmieniasz cluster_name i podbijasz config_version o dokładnie 1:

 totem {
-  cluster_name: stary-klaster
+  cluster_name: homelab-xl
   config_version: 4
+  config_version: 5
   ...
 }

Zapisujesz plik. Jeśli składnia jest błędna albo config_version się nie zgadza, pmxcfs po prostu zignoruje zmianę - sprawdź to od razu:

cat /etc/pve/corosync.conf

Jeśli widzisz nową nazwę - zmiana przeszła walidację i pmxcfs zaczął ją replikować do pozostałych node’ów. Możesz to potwierdzić, odpytując inny node w klastrze - zawartość /etc/pve/corosync.conf powinna się tam zgadzać w ciągu kilku sekund.

3. Zrestartuj corosync na każdym node’zie

Corosync trzyma nazwę klastra w pamięci od momentu startu procesu, więc sam zapis pliku jej nie zmieni w działającym demonie. Trzeba go zrestartować - na każdym node’zie z osobna, jeden po drugim, nie równolegle:

systemctl restart corosync

Po restarcie na pierwszym node’zie sprawdź pvecm status - node powinien nadal widzieć klaster (bo pozostałe wciąż działają na starym configu w pamięci, ale to ten sam config_version z tożsamej bazy, więc się dogadają). Dopiero jak przejdziesz przez wszystkie node’y, cały klaster jednomyślnie operuje na nowej nazwie.

4. Zrestartuj pve-cluster i pveproxy

Sama nazwa w GUI (i część wewnętrznych mechanizmów PVE, np. pvestatd) czyta ją z pmxcfs, więc żeby zobaczyć efekt w interfejsie webowym, restartujesz jeszcze:

systemctl restart pve-cluster
systemctl restart pveproxy

Zrób to na każdym node’zie. Odśwież przeglądarkę (najlepiej z czyszczeniem cache) - w lewym górnym rogu GUI powinieneś zobaczyć nową nazwę klastra.

5. QDevice, jeśli go używasz

Jeśli masz skonfigurowany QDevice do głosowania w klastrach o parzystej liczbie node’ów, po zmianie nazwy zobaczysz błędy o nieprawidłowym certyfikacie - certyfikat QDevice jest generowany dla konkretnej nazwy klastra. Usuwasz go i dodajesz ponownie:

pvecm qdevice remove
pvecm qdevice setup <adres_IP_QDevice>

Weryfikacja

Na koniec, na wszystkich node’ach:

pvecm status
corosync-cfgtool -s

pvecm status powinien pokazywać nową nazwę w polu Name, a corosync-cfgtool -s - że wszystkie linki (link: 0) są connected na każdym node’zie. Jeśli klaster ma HA, sprawdź jeszcze ha-manager status, żeby upewnić się, że menedżer HA nie zgubił się w międzyczasie.

Alternatywa bez restartu corosync

W sieci krąży też wariant bez restartu corosync na wszystkich node’ach naraz - edycja bezpośrednio w bazie pmxcfs przez sqlite3 na pliku /var/lib/pve-cluster/config.db, a potem restart usług pvestatd, pvedaemon, pve-cluster i corosync w jednej sekwencji. Wspominam o tym tylko dla kompletności - to jeszcze bardziej “za kulisami” niż edycja corosync.conf, bo omija normalną walidację configu przez pmxcfs, a przy błędzie w zapytaniu UPDATE łatwo o uszkodzenie bazy konfiguracyjnej całego klastra. Jeśli i tak wolisz iść tą drogą, zrób to najpierw na klastrze testowym.

Jeśli wolisz nie ryzykować

Jest jeszcze trzecia droga, najbezpieczniejsza: zamiast zmieniać nazwę istniejącego klastra, załóż nowy klaster pod docelową nazwą i przenieś do niego node’y i maszyny wirtualne jeden po drugim. Więcej roboty, zero ryzyka związanego z ręczną edycją corosync.conf na żywym organizmie. Warta rozważenia, jeśli klaster jest mały albo migrujesz sprzęt i tak planujesz reinstalację node’ów.

Podsumowanie

Proxmox nie daje przycisku do zmiany nazwy klastra, bo to funkcja, której oficjalnie nie testują i nie wspierają - ale mechanizm jest prosty do zrozumienia: cluster_name w /etc/pve/corosync.conf, podbity config_version, restart corosync na każdym node’zie po kolei, a na końcu pve-cluster i pveproxy po nową nazwę w GUI. Cała trudność bierze się nie z samej edycji pliku, a z tego, że robisz to na żywym klastrze, gdzie kolejność i cierpliwość między krokami mają znaczenie. Rób to w oknie serwisowym, miej backup corosync.conf pod ręką i przechodź przez node’y po kolei, a nie zaskoczy Cię nic więcej niż odświeżenie przeglądarki na końcu.