Best practice per il calcolo

Questa pagina presenta le best practice di computing per Google Cloud VMware Engine.

Seleziona la regione migliore per la tua applicazione

Per scegliere l'area migliore per le tue applicazioni, considera i seguenti fattori:

  • Per ridurre al minimo la latenza di rete e migliorare la customer experience, seleziona la località più vicina ai tuoi utenti. La console Google Cloud fornisce una dashboard delle prestazioni in tempo reale che può aiutarti a visualizzare la latenza tra regioni e tra utenti di internet e una regione Google Cloud.
  • Per mantenere le prestazioni delle applicazioni, ottimizza la connettività alle strutture on-premise selezionando la regione Google Cloud più vicina. Per i deployment multi-cloud, considera la vicinanza alle regioni di altri fornitori di servizi cloud.
  • Per assicurarti che le tue applicazioni mantengano la conformità alle normative, ad esempio le norme di conformità del settore delle carte di pagamento (PCI) o il Regolamento generale sulla protezione dei dati (GDPR) europeo, seleziona una regione che supporti questi requisiti.
  • Costi e prezzi variano in base alla regione. Tieni 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.

Decidi quando scegliere una progettazione multiregionale

Nelle situazioni seguenti, potresti voler eseguire il deployment su più cloud privati di VMware Engine in regioni diverse per lo stesso ambito di carichi di lavoro o di progetto:

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

Progettazione per la resilienza di zona

VMware Engine fornisce la ridondanza delle zone in regioni specifiche. In queste regioni, per una maggiore tolleranza di errore, puoi anche eseguire il deployment di cloud privati come cluster ampliato. Per informazioni su queste regioni, consulta le note di rilascio di VMware Engine.

Quando viene eseguito il deployment come cluster ampliato, il cloud privato ha nodi in due zone indipendenti. Per supportare questa progettazione, devi avere un numero uguale di nodi in ciascuna zona. Questo design garantisce la disponibilità delle applicazioni attraverso la resilienza di zona e VMware vSphere High Accessibility.

Durante il provisioning di un cloud privato esteso, le VM potrebbero essere eseguite su entrambi i lati di un cloud privato ampliato. Utilizza le regole di affinità per controllare il posizionamento delle VM dei carichi di lavoro sugli host all'interno di un cluster raggruppandole e fissandole a un sito. Questo design garantisce la resilienza della zona attraverso l'alta disponibilità (HA).

Separa gli ambienti tra diversi cloud privati

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

Puoi separare la tua impronta di VMware Engine su più cloud privati. Ad esempio, utilizza un server vCenter dedicato nei seguenti casi:

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

Per evitare l'inutile proliferazione degli endpoint di gestione, utilizza solo il numero richiesto di cloud privati.

Ottimizza il conteggio dei core

VMware Engine consente di ridurre il numero di core CPU effettivi esposti all'hypervisor ESXi. Ciò potrebbe essere desiderabile, o richiesto, in base ad alcuni contratti di licenza software.

La riduzione del numero di core del primo cluster non è consigliata perché ospita componenti chiave come vCenter e NSX Manager.

La riduzione del numero di core effettivi in un cluster non cambia il costo di esecuzione del cluster, in particolare per i carichi di lavoro Oracle. Per ulteriori informazioni, consulta le indicazioni relative ad assistenza e licenze.

Per maggiori informazioni, consulta Limiti 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 carichi o conflitti elevati. Questi nodi di riserva vengono fatturati come parte del cloud privato esistente.

Se è necessaria un'affidabilità maggiore, valuta la possibilità di aggiungere altri nodi di riserva al cluster in modo che siano disponibili durante i periodi di manutenzione. La pianificazione dei carichi di lavoro per l'esecuzione su questi nodi di riserva consente di ottimizzare l'uso dei cluster nei cloud privati.

Definisci il numero di errori da tollerare

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

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

Passaggi successivi