Cluster Nexus dell'operatore di Azure

Azure Operator Nexus è basato su costrutti di base come server di calcolo, appliance di archiviazione e dispositivi di infrastruttura di rete. Il cluster Nexus dell'operatore di Azure rappresenta una distribuzione locale della piattaforma. Il ciclo di vita delle risorse specifiche della piattaforma dipende dallo stato del cluster.

Panoramica della distribuzione del cluster

Durante la distribuzione del cluster, il cluster viene sottoposto a varie fasi del ciclo di vita, che hanno ruoli specifici designati per garantire che lo stato di destinazione venga raggiunto.

Fase di convalida hardware:

La convalida hardware (HWV) viene avviata durante il processo di distribuzione del cluster. Durante questa fase, ogni computer definito nella configurazione rack del cluster viene sottoposto a un controllo hardware completo prima della distribuzione. HWV valuta l'integrità e lo stato di tutti i componenti hardware in questi computer. HWV tenta di correggere le impostazioni di avvio del BIOS configurate in modo errato e i componenti del firmware in base alle esigenze.

In base ai risultati di questi controlli HWV e a qualsiasi macchine ignorate dall'utente, si stabilisce se siano stati superati nodi sufficienti e/o siano disponibili per soddisfare le soglie necessarie per continuare il deployment. I risultati di HWV per ogni server vengono registrati nell'area di lavoro Log Analytics (LAW), creata come parte della configurazione del cluster.

Questo articolo offre una panoramica dettagliata della panoramica della convalida hardware del processo HWV

Questo articolo fornisce istruzioni su come controllare e risolvere i problemi relativi ai risultati HWV Risolvere i problemi di convalida hardware

Fase di convalida dei prerequisiti di Azure

Prima che la distribuzione del cluster proceda, Operator Nexus verifica che le risorse di Azure fornite dall'utente siano accessibili usando l'identità gestita configurata. Questa convalida garantisce che il cluster possa usare correttamente le risorse seguenti durante e dopo la distribuzione:

• Area di lavoro Log Analytics (LAW): obbligatorio per l'installazione dell'estensione software e la raccolta di metriche
• Account di archiviazione: utilizzato per archiviare l'output dei comandi di esecuzione
• Key Vault: usato per la rotazione delle credenziali e l'archiviazione dei segreti

La fase di convalida viene eseguita come il passaggio "Convalida dei prerequisiti di Azure" nell'azione di distribuzione. Ogni risorsa viene sottoposta a un controllo della connettività e delle autorizzazioni:

Se una convalida ha esito negativo, l'azione di distribuzione segnala l'errore con un messaggio di errore che indica la risorsa non riuscita e il motivo. Cause comuni includono:

• Assegnazioni di ruolo mancanti nella risorsa di destinazione
• Identificatori di risorsa non corretti (ID area di lavoro, URL del contenitore o URI del vault)
• Regole del firewall che bloccano l'accesso dai servizi di Azure attendibili

La distribuzione non procede finché tutti i prerequisiti di Azure non superano la convalida. Dopo aver corretto eventuali problemi, la verifica riprova automaticamente.

Per istruzioni dettagliate sulla configurazione e sulla risoluzione dei problemi, vedere Identità gestita del cluster e risorse fornite dall'utente.

Fase iniziale bootstrap

Quando la convalida hardware ha esito positivo e vengono soddisfatte le soglie di distribuzione, viene generata un'immagine bootstrap nella gestione cluster per avviare la distribuzione del cluster. Questa immagine iso URL viene usata per eseguire il bootstrap del nodo temporaneo, che distribuirà i componenti del cluster di destinazione, che effettuano il provisioning del piano di controllo kubernetes (KCP), del piano di gestione Nexus (NMP) e dell'appliance di archiviazione. Questi diversi stati si riflettono nello stato del cluster, in cui queste fasi vengono eseguite come parte del flusso di lavoro temporaneo di bootstrap.

Il nodo di bootstrap temporaneo esegue il provisioning in sequenza di ciascun nodo KCP e, se un nodo KCP non riesce nel provisioning, l'azione di distribuzione del cluster fallisce, segnalando lo stato del cluster come fallito. L'operatore Bootstrap gestisce il processo di provisioning per i nodi bare metal usando l'approccio di avvio PXE (Preboot Execution Environment).

Dopo il provisioning dei nodi KCP, l'azione di distribuzione procede con il provisioning dei nodi NMP in parallelo. Ogni gruppo di gestione deve ottenere una percentuale di successo nel provisioning di almeno 50%. Se questo requisito non è soddisfatto, l'azione di distribuzione del cluster ha esito negativo, con conseguente contrassegno dello stato del cluster come non riuscito.

Una volta completato correttamente il provisioning dei nodi NMP, vengono create fino a due appliance di archiviazione prima che l'azione di distribuzione proceda col provisioning dei nodi di calcolo. Il provisioning dei nodi di calcolo viene effettuato in parallelo e, dopo aver raggiunto la soglia definita del nodo di calcolo, lo stato del cluster passa da Distribuzione a In esecuzione. Tuttavia, i nodi rimanenti continuano a eseguire il processo di provisioning finché anch'essi non vengono correttamente provisionati.

Operazioni del cluster

• Elenco cluster: elencare le informazioni del cluster nel gruppo di risorse o nella sottoscrizione fornita.
• Mostra cluster: ottenere le proprietà del cluster fornito.
• Aggiornare il cluster: aggiornare le proprietà o i tag del cluster fornito.