Come costruire un cluster Proxmox

01

Congela ambito e prerequisiti

Seleziona una release Proxmox VE attualmente supportata dalla guida di amministrazione ufficiale e leggi i suoi requisiti specifici prima dell'installazione. Prepara hostname univoci, indirizzi di gestione stabili, sincronizzazione dell'ora, accesso amministrativo, backup verificati e un percorso di ripristino indipendente. Registra i budget delle risorse di nodo e guest in modo che servizi di gestione, storage e ripristino non vengano allocati altrove.

Preferisci nodi che possano comunicare su un percorso stabile di classe LAN. Proxmox documenta un cluster basato su quorum e richiede una consegna Corosync affidabile con latenza inferiore a 5 millisecondi per un funzionamento stabile. Ciò rende un cluster esteso su regioni pubbliche distanti un progetto diverso e generalmente inadatto a meno che tu non possa dimostrare che la sua rete soddisfa i requisiti ufficiali. Nessun tessuto inter-regione privato è implicito da un elenco di server pubblici.

• Proxmox VE Guida all'amministrazione ↗

02

Progetta il quorum prima di unire i nodi

Annota i voti e ogni partizione che intendi far sopravvivere. Un cluster a tre nodi è il punto di partenza diretto perché la maggioranza può rimanere dopo la perdita di un nodo votante. Un progetto a due nodi non diventa sicuro tramite failover desiderato; Proxmox documenta QDevice come modo per fornire un voto aggiuntivo, e quel votante esterno introduce i propri requisiti di raggiungibilità e posizionamento.

Il quorum protegge lo stato coerente del cluster, non la disponibilità dell'applicazione da sola. Decidi come vengono riavviate le guest, quale storage richiedono i loro dischi e cosa succede quando un nodo è isolato ma ancora in esecuzione. Evita di modificare i voti attesi per forzare una partizione scrivibile come risposta di routine.

03

Pianifica onestamente il traffico di Corosync e del carico di lavoro

Elenca separatamente gestione delle liste, Corosync, migrazione, storage, backup e traffico pubblico degli ospiti, quindi mappa ciascuno sulle interfacce fornite e sugli indirizzi instradati. Percorsi fisici dedicati o separazione VLAN possono ridurre le interferenze, ma un ordine Tungsto non garantisce una VLAN privata o un collegamento cluster aggiuntivo. Conferma qualsiasi funzionalità di rete richiesta prima di ordinare; altrimenti progetta entro le interfacce e l'instradamento pubblico effettivamente forniti.

Corosync valorizza la latenza stabile e la consegna ordinata affidabile più della larghezza di banda di punta. Migrazione, replica e backup possono creare flussi molto più grandi, quindi pianificali e misurali senza far morire di fame la comunicazione del cluster. Applica i firewall host dai requisiti di porta ufficiali e limita l'esposizione della gestione; non copiare un set di regole da una versione non correlata.

04

Scegli lo storage in base all'esito di recupero promesso

Lo storage locale mantiene semplici i domini di guasto ma non rende un disco guest disponibile su un altro nodo. La replica locale ZFS può ridurre il punto di ripristino, ma è asincrona e può perdere modifiche tra le repliche. Lo storage condiviso può rendere gli stessi volumi guest visibili a più nodi, mentre lo storage distribuito aggiunge requisiti di capacità, rete e operativi. Nessuno di questi elimina la necessità di un backup separato.

Definisci dove risiedono le immagini ISO, i dischi guest e i backup, come viene monitorato lo spazio libero e cosa succede quando lo storage si riempie. Proxmox avverte che i guest che utilizzano uno storage thin-provisioned pieno possono ricevere errori di I/O. Conserva i supporti di ripristino e le credenziali al di fuori del cluster che potresti dover ricostruire.

05

Usa un piano di accettazione e fallimento a fasi

Applica patch e verifica ogni nodo autonomo prima di creare il primo cluster, quindi unisci un nodo alla volta usando la guida della versione selezionata. Dopo ogni modifica, registra appartenenza, quorum, stato temporale, visibilità dello storage e stato del backup. Aggiungi un guest non di produzione solo dopo che il piano di controllo è sano.

Pianifica esercitazioni controllate per un nodo non disponibile, un percorso Corosync non disponibile, storage non disponibile e ripristino dal backup. Definisci il risultato atteso e le condizioni di interruzione prima di ogni esercitazione; non eseguire test distruttivi contro l'unica copia di un carico di lavoro. Le richieste di alimentazione hardware e reinstallazione Tungsto possono essere messe in coda per l'elaborazione dell'operatore, quindi non sono un controller HA gestito o un timer di ripristino garantito. Il risultato finale è un runbook di proprietà con risultati osservati dalla tua distribuzione, non una promessa di disponibilità non qualificata.