Se definisci un’applicazione con un’etichetta k8s inesistente, Astra Control Center creerà, gestirà e rimuoverà immediatamente l’applicazione. Per evitare questo problema, Aggiungi l’etichetta k8s ai pod e alle risorse dopo che l’applicazione è stata gestita da Astra Control Center.

Non esiste alcun modo per interrompere un backup in esecuzione. Se è necessario eliminare il backup, attendere che sia stato completato, quindi seguire le istruzioni riportate in "Eliminare i backup". Per eliminare un backup non riuscito, utilizzare "API di controllo Astra".

Se si ridimensiona un volume persistente dopo la creazione di un backup e poi si ripristina da tale backup, le dimensioni del volume persistente corrispondono alle nuove dimensioni del PV invece di utilizzare le dimensioni del backup.

I cloni di volumi persistenti molto grandi e consumati potrebbero essere lenti a intermittenza, a seconda dell’accesso del cluster all’archivio di oggetti. Se il clone viene bloccato e non sono stati copiati dati per più di 30 minuti, Astra Control termina l’azione del clone.

I cloni delle applicazioni all’interno dello stesso cluster si guastano costantemente con il grafico BitNami PostgreSQL 11.5.0. Per clonare correttamente, utilizzare una versione precedente o successiva del grafico.

Un clone dell’applicazione potrebbe non riuscire se i vincoli del contesto di protezione originale sono configurati a livello di account di servizio all’interno dello spazio dei nomi nel cluster OCP. Quando il clone dell’applicazione non funziona, viene visualizzato nell’area delle applicazioni gestite di Astra Control Center con lo stato Removed. Vedere "articolo della knowledge base" per ulteriori informazioni.

Dopo che un’applicazione è stata distribuita con una classe di storage esplicitamente impostata (ad esempio, helm install …​-set global.storageClass=netapp-cvs-perf-extreme), i successivi tentativi di clonare l’applicazione richiedono che il cluster di destinazione abbia la classe di storage specificata in origine. La clonazione di un’applicazione con una classe di storage esplicitamente impostata su un cluster che non ha la stessa classe di storage non avrà esito positivo. In questo scenario non sono disponibili procedure di ripristino.

Se si tenta di riutilizzare un bucket utilizzato da un’altra installazione o da una precedente installazione di Astra Control Center, le operazioni di backup e ripristino non avranno esito positivo. È necessario utilizzare una benna diversa o pulire completamente la benna utilizzata in precedenza. Non è possibile condividere i bucket tra istanze di Astra Control Center.

Quando si aggiunge un bucket, selezionare il bucket provider corretto e immettere le credenziali corrette per tale provider. Ad esempio, l’interfaccia utente accetta come tipo NetApp ONTAP S3 e accetta le credenziali StorageGRID; tuttavia, questo causerà l’errore di tutti i backup e ripristini futuri dell’applicazione che utilizzano questo bucket.

Se si dispone di una licenza di valutazione, assicurarsi di memorizzare l’ID account per evitare la perdita di dati in caso di guasto di Astra Control Center se non si inviano ASUP.

Durante il backup di un’applicazione o il ripristino di un’applicazione, è possibile specificare un ID bucket. Un’operazione di cloni dell’applicazione, tuttavia, utilizza sempre il bucket predefinito definito. Non esiste alcuna opzione per modificare i bucket per un clone. Se si desidera controllare quale bucket viene utilizzato, è possibile farlo "modificare l’impostazione predefinita del bucket" oppure fare una "backup" seguito da un "ripristinare" separatamente.

Non è possibile utilizzare un kubeconfig con più di un cluster e un contesto. Vedere "articolo della knowledge base" per ulteriori informazioni.

Se Trident su un cluster di applicazioni diventa offline (e viene riportato online) e si verificano errori di servizio interni 500 quando si tenta di gestire i dati delle applicazioni, riavviare tutti i nodi Kubernetes nel cluster di applicazioni per ripristinare la funzionalità.

Se l’esecuzione di un gancio di esecuzione richiede più di 25 minuti, l’hook non riesce, creando una voce del registro eventi con un codice di ritorno "N/A". Qualsiasi snapshot interessata verrà contrassegnata come non riuscita e una voce del registro eventi risultante ne annoterà il timeout.

Poiché gli hook di esecuzione spesso riducono o disattivano completamente le funzionalità dell’applicazione con cui vengono eseguiti, si consiglia di ridurre al minimo il tempo necessario per l’esecuzione degli hook di esecuzione personalizzati.

Durante la raccolta ASUP, lo stato del bundle nell’interfaccia utente viene riportato come uno dei due collecting oppure done. La raccolta può richiedere fino a un’ora per ambienti di grandi dimensioni. Durante il download di ASUP, la velocità di trasferimento dei file di rete per il bundle potrebbe essere insufficiente e il download potrebbe scadere dopo 15 minuti senza alcuna indicazione nell’interfaccia utente. I problemi di download dipendono dalle dimensioni dell’ASUP, dalle dimensioni del cluster scalate e se il tempo di raccolta supera il limite di sette giorni.

Quando si utilizza Kubernetes snapshot-controller (noto anche come external-snapshotter) versione 4.2.0 con Kubernetes 1.20 o 1.21, le snapshot possono iniziare a fallire. Per evitare questo problema, utilizzare un altro "versione supportata" Di external-snapshotter, come la versione 4.2.1, con Kubernetes versioni 1.20 o 1.21.

Se si tenta di ripristinare contemporaneamente una o più applicazioni gestite singolarmente all’interno di uno spazio dei nomi, le operazioni di ripristino possono fallire dopo un lungo periodo di tempo. Come soluzione alternativa, ripristinare ciascuna applicazione una alla volta.

Se si aggiorna un sistema Astra Control Center che utilizza un registro che non richiede l’autenticazione a una versione più recente che utilizza un registro che richiede l’autenticazione, l’aggiornamento non riesce. Per risolvere il problema, attenersi alla seguente procedura:

Se i cluster non sono stati disgestiti prima della disinstallazione di Astra Control Center, è possibile eliminare manualmente i pod nello spazio dei nomi di monitoraggio netapp e nello spazio dei nomi con i seguenti comandi:

È possibile eliminare manualmente i CRD Traefik. Le CRDS sono risorse globali e l’eliminazione di queste risorse potrebbe avere un impatto sulle altre applicazioni del cluster.