Best practice per il calcolo

Questa pagina presenta le best practice per l'utilizzo di Google Cloud VMware Engine.

Seleziona la regione migliore per la tua applicazione

Per scegliere la regione migliore per le tue applicazioni, prendi in considerazione i seguenti fattori:

  • Per ridurre al minimo la latenza della rete e migliorare l'esperienza dei clienti, seleziona una località più vicina ai tuoi utenti. La console Google Cloud fornisce una dashboard sul rendimento in tempo reale che può aiutarti a visualizzare la latenza sia tra le regioni sia tra gli utenti di internet e una regione Google Cloud.
  • Per mantenere le prestazioni dell'applicazione, ottimizza la connettività alle strutture on-premise selezionando la regione Google Cloud più vicina. Per i deployment multicloud, valuta la vicinanza alle regioni di altri fornitori di cloud.
  • Per garantire che le tue applicazioni rimangano conformi alle normative, come le norme di conformità del settore delle carte di pagamento (PCI) o il Regolamento generale sulla protezione dei dati (GDPR) dell'Unione Europea, seleziona una regione che supporti questi requisiti.
  • I costi e i prezzi variano in base alla regione. Assicurati di tenere conto di queste differenze regionali quando pianifichi il deployment.
  • Quando selezioni una località, alcuni SKU potrebbero essere disponibili solo in alcune regioni e non in altre.

Decidere quando scegliere un design multi-regione

Nelle seguenti situazioni, ti consigliamo di eseguire il deployment in più cloud privati VMware Engine in più regioni per lo stesso ambito del progetto o del carico di lavoro:

  • Implementazioni del ripristino di emergenza che utilizzano Site Recovery Manager (SRM) o Zerto.
  • Applicazioni che richiedono disponibilità globale o latenza ridotta per la loro base di utenti.
  • Requisiti di pianificazione della capacità specifici per regione.

Progettare per la resilienza delle zone

VMware Engine fornisce ridondanza di zona in regioni specifiche. In queste regioni, per una maggiore tolleranza agli errori, puoi anche eseguire il deployment di cloud privati come cluster esteso. Per informazioni su queste regioni, consulta le note di rilascio di VMware Engine.

Se viene eseguito il deployment come cluster esteso, il cloud privato ha nodi in due zone indipendenti. Per supportare questo design, devi avere un numero uguale di nodi in ogni zona. Questo tipo di progettazione garantisce la disponibilità delle applicazioni tramite la resilienza di zona e VMware vSphere High Availability.

Durante il provisioning di un cloud privato ampliato, le VM potrebbero essere eseguite su entrambi i lati di un cloud privato ampliato. Utilizza regole di affinità per controllare il posizionamento delle VM di workload sugli host all'interno di un cluster raggruppandole e fissandole a un sito. Questo tipo di progettazione garantisce la resilienza delle zone tramite l'alta disponibilità (HA) delle applicazioni.

Separare gli ambienti in più cloud privati

Un cloud privato è uno stack VMware Cloud Foundation indipendente gestito da un vCenter Server.

Puoi separare l'impronta di VMware Engine su più cloud privati. Ad esempio, utilizza un vCenter Server dedicato nei seguenti casi:

  • Per un tipo di carico di lavoro specifico, ad esempio l'Infrastruttura desktop virtuale (VDI)
  • Quando i limiti di un cloud privato non sono adeguati
  • Per la gestione delle licenze e del software
  • Per trasparenza e semplicità dei costi
  • Per il monitoraggio
  • Per la conformità ai requisiti normativi
  • Per il multitenancy a tutti i livelli, inclusi i componenti di gestione e l'infrastruttura

Per evitare la proliferazione non necessaria di endpoint di gestione, utilizza solo il numero richiesto di cloud privati.

Ottimizza il numero di core

VMware Engine ti consente di ridurre il numero di core CPU efficaci esposti all'hypervisor ESXi. Ciò potrebbe essere auspicabile o obbligatorio ai sensi di alcuni contratti di licenza del software.

Non è consigliabile ridurre il numero di core del primo cluster perché ospita componenti chiave, come vCenter e NSX Manager.

La riduzione del numero di core effettivi in un cluster non influisce sul costo di esecuzione del cluster, in particolare per i workload Oracle. Per saperne di più, consulta le indicazioni su assistenza e licenze.

Per ulteriori informazioni, consulta Limitazioni del numero di core personalizzati.

Aggiungi nodi di riserva per la resilienza

I cluster VMware Engine devono essere dimensionati in modo da avere almeno un nodo di riserva per la resilienza. Questo nodo di riserva è disponibile per il cluster e può fornire capacità e risorse aggiuntive in caso di carico elevato o competizione. Questi nodi di riserva vengono fatturati come parte del cloud privato esistente.

Se è richiesta una maggiore affidabilità, valuta la possibilità di aggiungere altri nodi di riserva al cluster in modo che siano disponibili durante le finestre di manutenzione. La pianificazione dell'esecuzione dei carichi di lavoro su questi nodi di riserva consente di ottimizzare l'utilizzo dei cluster nei cloud privati.

Definisci il numero di errori da tollerare

Per VMware vSAN, utilizza l'attributo Failures to Tolerate (FTT) (Errori da tollerare) nei criteri di archiviazione vSAN per definire il numero di errori che un cluster può tollerare senza influire sulla sua integrità dei dati o sulla disponibilità delle VM.

Più alto è il valore FTT, maggiore è la capacità degli host richiesta.

Passaggi successivi