Configura un criterio di alta disponibilità per le VM

Questo documento mostra come configurare il criterio di alta disponibilità per le macchine virtuali (VM) che vengono eseguite utilizzando il runtime VM su GDC.

Quando abiliti il runtime VM su GDC, il cluster crea un oggetto VMHighavailabilityPolicy denominato default. Questo oggetto specifica la strategia di recupero predefinita in caso di errore di un nodo cluster su cui è in esecuzione una VM. Le possibili strategie di recupero predefinite sono:

  • Ripianifica: riprogramma la VM su un altro nodo cluster.
  • Ignora: non consente di eseguire alcuna operazione.

Inizialmente, la strategia di recupero predefinita è impostata su Reschedule.

Una strategia di recupero predefinita di Reschedule è appropriata nella seguente situazione:

  • Il cluster ha almeno due nodi worker.

  • Il provisioning dei dischi della VM viene eseguito utilizzando una classe di archiviazione basata su file di rete. In altre parole, la classe di archiviazione si basa su un file system di rete che coordina i blocchi dei file POSIX su diversi client. Network File System (NFS) è un esempio di classe di archiviazione basata su file di rete.

Se le tue VM utilizzano l'archiviazione locale o un sistema di archiviazione basato su blocchi, ti consigliamo di impostare la strategia di ripristino predefinita su Ignore. Questo consiglio è per i seguenti motivi:

  • Se le VM utilizzano l'archiviazione locale e si verifica un errore di un nodo, non è possibile recuperare i dati archiviati e spostarli in un nuovo nodo.

  • Se le tue VM utilizzano un sistema di archiviazione basato su blocchi, lo spazio di archiviazione potrebbe non avere garanzie di scollegamento sufficienti. Ciò potrebbe causare l'accesso simultaneo al disco e il danneggiamento dei dati durante la pianificazione delle VM.

Ispeziona l'oggetto VMHighavailabilityPolicy

Verifica che sia presente un oggetto VMHighavailabilityPolicy:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get VMHighAvailabilityPolicy --namespace vm-system

Sostituisci USER_CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster utente.

L'output mostra che è presente un oggetto VMHighavailabilityPolicy denominato default. Nell'output puoi anche vedere il valore corrente di defaultRecoveryStrategy. Ad esempio, il seguente output mostra che il valore attuale di defaultRecoveryStrategy è Reschedule:

vm-system   default   5m55s   Reschedule   15s   1m30s

Ottieni una visualizzazione dettagliata dell'oggetto VMHighavailabilityPolicy:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get VMHighAvailabilityPolicy \
    --namespace vm-system --output yaml

Output di esempio:

apiVersion: vm.cluster.gke.io/v1alpha1
kind: VMHighAvailabilityPolicy
metadata:
  ...
  labels:
    app.kubernetes.io/component: kubevirt
    app.kubernetes.io/managed-by: virt-operator
    kubevirt.io: virt-api
  name: default
  namespace: vm-system
  ..
spec:
  defaultRecoveryStrategy: Reschedule
  nodeHeartbeatInterval: 15s
  nodeMonitorGracePeriod: 1m30s

Cambiare la strategia di recupero predefinita

In determinate situazioni, ti consigliamo di cambiare la strategia di recupero predefinita. Ad esempio, se le VM utilizzano l'archiviazione locale o un file system non basato su file di rete, ti consigliamo di modificare il valore di defaultRecoveryStrategy in Ignore.

Per modificare il valore di defaultRecoveryStrategy, apri l'oggetto VMHighavailabilityPolicy per la modifica:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG edit VMHighAvailabilityPolicy \
    default --namespace vm-system

Nell'editor di testo, modifica il valore di defaultRecoveryStrategy scegliendo un valore a tua scelta: Reschedule o Ignore. Chiudi l'editor di testo.

Esegui l'override della strategia di recupero predefinita per una VM

La strategia di ripristino predefinita si applica a tutte le VM in esecuzione nel cluster. Tuttavia, potresti dover eseguire l'override della strategia di ripristino predefinita per singole VM.

Ad esempio, supponiamo che per la maggior parte delle VM venga eseguito il provisioning di una classe di archiviazione basata su file di rete, mentre per alcune VM viene eseguito il provisioning di una classe di archiviazione basata su blocchi. Per ogni VM che utilizza l'archiviazione basata su blocchi, ti consigliamo di eseguire l'override della strategia di recupero predefinita impostando la strategia di ripristino per la singola VM su Ignore.

Per eseguire l'override della strategia di recupero predefinita per una VM, aggiungi un'annotazione vm.cluster.gke.io/vm-ha-recovery-strategy sia all'oggetto VirtualMachineInstance (VMI) sia all'oggetto GVM.

Ad esempio, questi comandi impostano la strategia di recupero su Ignore per una VM denominata my-vm:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  annotate vmi my-vm \
  vm.cluster.gke.io/vm-ha-recovery-strategy=Ignore --overwrite

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  annotate gvm my-vm \
  vm.cluster.gke.io/vm-ha-recovery-strategy=Ignore --overwrite

Se vuoi rimuovere le annotazioni in un secondo momento, utilizza un trattino alla fine del nome dell'annotazione. Ad esempio:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  annotate vmi my-vm \
  vm.cluster.gke.io/vm-ha-recovery-strategy-

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  annotate gvm my-vm \
  vm.cluster.gke.io/vm-ha-recovery-strategy-

Configurazione avanzata

Oltre a configurare la strategia di ripristino predefinita, puoi configurare quanto segue:

  • Intervallo heartbeat del nodo: il tempo tra gli heartbeat inviati da ciascun nodo del cluster

  • Periodo di tolleranza per il monitoraggio dei nodi: il periodo di tempo massimo durante il quale un nodo può non inviare un heartbeat prima che sia considerato in stato non integro

Nella maggior parte dei casi, i valori predefiniti per l'intervallo heartbeat e il periodo di tolleranza sono appropriati. Tuttavia, puoi scegliere di regolare questi valori per ottimizzare il compromesso tra velocità di recupero e overhead. Un intervallo del battito cardiaco più breve abbrevia il tempo di recupero, ma aumenta anche l'overhead. In un cluster di grandi dimensioni, potresti scegliere di allungare l'intervallo di heartbeat, poiché gli heartbeat frequenti di molti nodi potrebbero creare un carico non accettabile sul server API Kubernetes.

Mantieni l'intervallo di heartbeat inferiore al periodo di tolleranza per evitare casi in cui un singolo battito cardiaco mancato comporta la valutazione di un nodo in stato non integro.

Esegui kubectl edit per aprire l'oggetto VMHighavailabilityPolicy per la modifica. Imposta nodeHeartbeatInterval e nodeMonitorGracePeriod su valori di tua scelta.

spec:
  defaultRecoveryStrategy: Reschedule
  nodeHeartbeatInterval: 15s
  nodeMonitorGracePeriod: 1m30s