Applicazione aziendale con Oracle Database su Compute Engine

Last reviewed 2024-09-02 UTC

Questo documento fornisce un'architettura di riferimento per aiutarti a sviluppare per ospitare un'applicazione aziendale ad alta disponibilità che utilizza Database Oracle con deployment dell'intero stack nelle VM di Compute Engine. Puoi utilizzare questa architettura di riferimento per eseguire il rehosting (lift and shift) in modo efficiente delle applicazioni on-premise che utilizzano database Oracle su Google Cloud. Questo include anche indicazioni per creare una topologia di database Oracle in Google Cloud che soddisfa Architettura di disponibilità massima (MAA) Oracle i tuoi requisiti. I destinatari di questo documento sono cloud architect e Amministratori di database Oracle Nel documento si presuppone che tu abbia familiarità con in Compute Engine e Oracle Database.

Se utilizzi Oracle Exadata o Oracle Real Application Clusters (Oracle RAC) eseguire database Oracle on-premise, puoi eseguire la migrazione delle tue applicazioni in modo efficiente su Google Cloud ed eseguire i tuoi database su Oracle Database@Google Cloud. Per maggiori informazioni le informazioni, vedi Applicazione aziendale su VM di Compute Engine con Oracle Exadata in Google Cloud.

Architettura

Il seguente diagramma mostra l'infrastruttura per un'applicazione aziendale a più livelli che utilizza Oracle Database. Il livello web, il livello di applicazione Le istanze del database Oracle sono ospitate sulle VM di Compute Engine. Il livello web e a livello di applicazione vengono eseguiti in modalità attiva-attiva su VM distribuite in due zone all'interno di una regione Google Cloud. La piattaforma principale e quella di standby il deployment delle istanze del database viene eseguito in zone separate. Questa architettura è allineata con archetipo di deployment regionale, per garantire che la topologia Google Cloud sia affidabile a una singola zona.

Un'applicazione aziendale multi-livello utilizza il database Oracle sulle VM di Compute Engine.

L'architettura mostrata nel diagramma precedente include i seguenti componenti:

Componente Finalità
Bilanciatore del carico delle applicazioni esterno regionale Il bilanciatore del carico delle applicazioni esterno regionale riceve e distribuisce le richieste degli utenti alle VM del livello web.
Sicurezza di Google Cloud Armor norme Il criterio di sicurezza di Google Cloud Armor contribuisce a proteggere il tuo app stack da minacce come attacchi DDoS (Distributed Denial of Service) e cross-site scripting (XSS).
Gruppo di istanze gestite a livello di regione per il livello web Il livello web dell'applicazione viene di cui è stato eseguito il deployment su VM Compute Engine che fanno parte di un gruppo di istanze gestite regionale. Questo gruppo di istanze gestite è il backend per il bilanciatore del carico delle applicazioni esterno. Il gruppo di istanze gestite contiene di Compute Engine in due zone. Ciascuna di queste VM ospita un'istanza indipendente del livello web dell'applicazione.
Bilanciatore del carico delle applicazioni interno regionale Il bilanciatore del carico delle applicazioni interno regionale distribuisce il traffico dalle VM di livello web alle VM di livello applicazione.
Gruppo di istanze gestite a livello di regione per il livello di applicazione Il livello dell'applicazione, ad esempio un cluster Oracle WebLogic Server, viene disegnato su VM Compute Engine che fanno parte di un MIG regionale. Questo gruppo di istanze gestite è il backend per il bilanciatore del carico delle applicazioni interno. Il gruppo di istanze gestite contiene di Compute Engine in due zone. Ogni VM ospita un'istanza indipendente del server delle applicazioni.
Istanze Oracle Database di cui è stato eseguito il deployment sulle VM di Compute Engine L'applicazione in questa architettura utilizza una coppia principale/di riserva di istanze Oracle Database di cui viene eseguito il deployment su VM Compute Engine in zone distinte. Occupati della tua (BYOL) per queste istanze di database Oracle e potrai gestire le VM e le istanze del database.
Pool di archiviazione Hyperdisk Le VM in ogni zona (in tutti i livelli dell'applicazione , usano volumi bilanciati Hyperdisk da un pool di archiviazione Hyperdisk. Creando e gestendo tutti i dischi in un unico pool di archiviazione, puoi migliorare l'utilizzo della capacità e ridurre la complessità operativa, mantenendo al contempo la capacità di archiviazione e le prestazioni di cui le VM hanno bisogno.
Dati Oracle Osservatore Guard FSFO L'osservatore FSFO (Fast-Start Failover) Oracle Data Guard è un programma leggero che avvia il failover automatico in standby Istanza del database Oracle quando l'istanza principale non è disponibile. L'osservatore viene eseguito su una VM di Compute Engine in una zona diverso dalle zone in cui il database principale e quello in standby viene eseguito il deployment delle istanze.
Bucket Cloud Storage Per archiviare i backup delle istanze Oracle Database, questa l'architettura utilizza un bucket Cloud Storage. Per semplificare il recupero del database durante un'interruzione del servizio in una regione, puoi archiviare i backup con ridondanza geografica in un bucket a due o più regioni.
Rete Virtual Private Cloud (VPC) e sottorete Tutte le risorse Google Cloud nell'architettura utilizzano una singola rete e una singola subnet VPC. In base ai tuoi requisiti, può scegliere di creare un'architettura che utilizza più reti VPC o più subnet. Per saperne di più, consulta Decidere se creare più reti VPC.
Gateway Cloud NAT pubblico L'architettura include un gateway Cloud NAT pubblico per attivare connessioni in uscita sicure dalle VM Compute Engine che hanno solo indirizzi IP interni.
Cloud Interconnect e Cloud VPN Per connettere la tua rete on-premise alla rete VPC in Google Cloud, puoi utilizzare Cloud Interconnect o Cloud VPN. Per informazioni sui vantaggi relativi di ciascun approccio, consulta Scegliere un prodotto per la connettività di rete.
Cloud Monitoring e Cloud Logging Cloud Monitoring ti aiuta a osservare il comportamento, l'integrità e le prestazioni della tua applicazione e delle risorse Google Cloud. Ops Agent raccoglie le metriche e i log dalle VM Compute Engine, incluse le VM che ospitano le istanze Oracle Database. L'agente invia i log a Cloud Logging e le metriche a Cloud Monitoring.

Prodotti utilizzati

Questa architettura di riferimento utilizza i seguenti prodotti Google Cloud:

  • Compute Engine: un servizio di calcolo sicuro e personalizzabile che ti consente di creare ed eseguire VM sull'infrastruttura di Google.
  • Google Cloud Hyperdisk: un servizio di archiviazione di rete che puoi utilizzare per eseguire il provisioning e scalare dinamicamente i volumi di archiviazione a blocchi con prestazioni configurabili e prevedibili.
  • Cloud Load Balancing: un portafoglio di bilanciatori del carico scalabili, globali e regionali ad alte prestazioni.
  • Cloud Storage: uno spazio di archiviazione di oggetti a basso costo e senza limiti per diversi tipi di dati. I dati sono accessibili dall'interno e dall'esterno di Google Cloud replicati in più località per la ridondanza.
  • Virtual Private Cloud (VPC): un sistema virtuale che fornisce un ambiente globale e scalabile di networking per i carichi di lavoro di Google Cloud.
  • Google Cloud Armor: un servizio di sicurezza della rete che offre regole WAF (web application firewall) e contribuisce a proteggere da attacchi DDoS e alle applicazioni.
  • Cloud NAT: un servizio che fornisce Google Cloud gestiti Network Address Translation ad alte prestazioni.
  • Cloud Monitoring: un servizio che offre visibilità su prestazioni, disponibilità e integrità delle tue applicazioni e dell'infrastruttura.
  • Cloud Logging: un sistema di gestione dei log in tempo reale con archiviazione, ricerca, analisi e generazione di avvisi.
  • Cloud Interconnect: un servizio che estende la tua rete esterna al sulla rete Google tramite una connessione ad alta disponibilità e a bassa latenza.
  • Cloud VPN: un servizio che estende in modo sicuro la tua rete peer al servizio attraverso un tunnel VPN IPsec.

Questa architettura di riferimento utilizza i seguenti prodotti Oracle:

  • Oracle Database: un sistema di gestione di database relazionali (RDBMS) che estende il modello relazionale a un modello relazionale a oggetti.
  • Oracle Data Guard: un insieme di servizi per creare, mantenere, gestire per monitorare uno o più database in standby.

Sei responsabile dell'acquisto delle licenze per i prodotti Oracle di cui esegui il deployment in Google Cloud e della conformità ai termini e alle condizioni delle licenze Oracle.

Note sul layout

Questa sezione descrive fattori di progettazione, best practice e consigli di progettazione che devi prendere in considerazione quando utilizzi questa architettura di riferimento per sviluppare una topologia che soddisfi i tuoi requisiti specifici per sicurezza, affidabilità, efficienza operativa, costi e prestazioni.

Le indicazioni fornite in questa sezione non sono esaustive. A seconda dei requisiti specifici della tua applicazione e dei prodotti e delle funzionalità di Google Cloud e di terze parti che utilizzi, potresti dover prendere in considerazione fattori di progettazione e compromessi aggiuntivi.

Progettazione del sistema

Questa sezione fornisce indicazioni per aiutarti a scegliere le regioni Google Cloud per il deployment e selezionare i servizi Google Cloud appropriati.

Selezione delle regioni

Quando scegli la regione Google Cloud per il tuo deployment, considera le i seguenti fattori e requisiti:

  • Disponibilità dei servizi Google Cloud in ogni regione. Per maggiori informazioni le informazioni, vedi Prodotti disponibili in base alla località.
  • Disponibilità dei tipi di macchine Compute Engine in ogni regione. Per ulteriori informazioni, vedi Regioni e zone.
  • Requisiti relativi alla latenza per gli utenti finali.
  • Costo delle risorse Google Cloud.
  • Requisiti normativi.

Alcuni di questi fattori e requisiti potrebbero comportare dei compromessi. Ad esempio, la regione più conveniente potrebbe non avere l'impronta di carbonio più bassa. Per maggiori informazioni, consulta Best practice per la scelta delle regioni Compute Engine.

Infrastruttura di calcolo

L'architettura di riferimento in questo documento utilizza le VM di Compute Engine per ospitare tutti i livelli dell'applicazione. A seconda dei requisiti della tua applicazione, puoi scegliere i seguenti altri servizi di calcolo Google Cloud:

  • Contenitori: puoi eseguire applicazioni containerizzate in cluster Google Kubernetes Engine (GKE). GKE è un motore di orchestrazione dei container automatizza il deployment, la scalabilità e la gestione delle applicazioni containerizzate.
  • Serverless: se preferisci concentrare le risorse IT sui dati e sulle applicazioni anziché sulla configurazione e sul funzionamento delle risorse di infrastruttura, puoi utilizzare i servizi serverless come Cloud Run.

La decisione di utilizzare VM, container o servizi serverless comporta un compromesso tra flessibilità di configurazione e impegno di gestione. Le VM e i contenitori offrono maggiore flessibilità e controllo della configurazione, ma sei responsabile della gestione delle risorse. In un'architettura serverless, carichi di lavoro in una piattaforma preconfigurata che richiede il minimo sforzo di gestione. Le indicazioni di progettazione per questi servizi non rientrano nell'ambito di questo documento. Per ulteriori informazioni sulle opzioni di servizio, consulta Opzioni di hosting delle applicazioni.

Opzioni di archiviazione

L'architettura mostrata in questo documento utilizza un pool di archiviazione Hyperdisk in ogni zona, con volumi Hyperdisk Balanced per le VM in tutti i livelli. I volumi Hyperdisk forniscono prestazioni, flessibilità ed efficienza migliori rispetto ai dischi permanenti. Per informazioni sui tipi e sulle funzionalità di Hyperdisk, consulta Informazioni su Hyperdisk.

Per archiviare i dati condivisi tra più VM in una regione, come i file di configurazione per tutte le VM nel livello web, puoi utilizzare un'istanza Filestore regionale. I dati archiviati in un'istanza a livello di regione Filestore sono replicati in modo sincrono tra le tre zone all'interno della regione. Questa replica garantisce alta disponibilità e robustezza contro le interruzioni di zona. Puoi archiviare file di configurazione condivisi, gli strumenti e le utilità comuni e i log centralizzati e montare l'istanza su più VM.

Quando progetti l'archiviazione per i carichi di lavoro, considerane il funzionamento caratteristiche dei carichi di lavoro, requisiti di resilienza, prestazioni aspettative e obiettivi di costo. Per ulteriori informazioni, vedi Progetta una strategia di archiviazione ottimale per il tuo carico di lavoro cloud.

Progettazione della rete

Quando crei l'infrastruttura per uno stack di applicazioni multilivello, devi scegliere un design di rete che soddisfi i tuoi requisiti aziendali e tecnici. L'architettura mostrata in questo documento utilizza una topologia di rete semplice con una singola rete e subnet VPC. A seconda dei tuoi requisiti, puoi scegliere di utilizzare più reti VPC o più subnet. Per ulteriori informazioni, consulta la seguente documentazione:

Sicurezza, privacy e conformità

Questa sezione descrive i fattori da considerare quando utilizzi questo riferimento per progettare una topologia in Google Cloud che soddisfi i requisiti e conformità dei tuoi carichi di lavoro.

Protezione contro minacce esterne

Per proteggere la tua applicazione da minacce esterne come attacchi DDoS e XSS, definisci criteri di sicurezza di Google Cloud Armor appropriati in base ai tuoi requisiti. Ogni criterio è un insieme di regole che specifica le condizioni valutate e le azioni da intraprendere quando le condizioni sono soddisfatte. Ad esempio, una regola puoi specificare che se l'indirizzo IP di origine del traffico in entrata corrisponde a per un indirizzo IP o un intervallo CIDR specifico, il traffico deve essere negato. Puoi anche applicare regole del web application firewall (WAF) preconfigurate. Per ulteriori informazioni, vedi Panoramica dei criteri di sicurezza.

Accesso esterno per le VM

Nell'architettura di riferimento descritta in questo documento, le VM che ospitano il livello web, l'applicazione e le istanze del database Oracle non hanno bisogno per impedire l'accesso in entrata da internet. Non assegnare indirizzi IP esterni a questi delle VM in esecuzione. Le risorse Google Cloud che hanno solo indirizzi IP interni privati possono comunque accedere ad alcune API e servizi Google utilizzando Private Service Connect o l'accesso privato Google. Per maggiori informazioni le informazioni, vedi Opzioni di accesso privato per i servizi.

Per abilitare connessioni in uscita sicure dalle risorse Google Cloud che hanno solo indirizzi IP privati, come le VM Compute Engine in questa architettura di riferimento, puoi utilizzare Secure Web Proxy o Cloud NAT.

Sicurezza delle immagini VM

Le immagini approvate sono immagini con software conforme ai tuoi criteri o alla tua sicurezza i tuoi requisiti. Per assicurarti che le VM utilizzino solo immagini approvate, puoi definire un criterio dell'organizzazione che limiti l'utilizzo delle immagini in progetti di immagini pubbliche specifici. Per ulteriori informazioni, consulta Configurare i criteri per l'utilizzo di immagini attendibili.

Privilegi dell'account di servizio

Nei progetti Google Cloud in cui è abilitata l'API Compute Engine, account di servizio predefinito viene creata automaticamente. Per le organizzazioni Google Cloud create prima del 3 maggio 2024, a questo account di servizio predefinito viene concesso l'accesso Ruolo IAM (roles/editor), a meno che questo comportamento non sia disabilitato.

Per impostazione predefinita, l'account di servizio predefinito è associato a tutte le VM create utilizzando Google Cloud CLI o la console Google Cloud. Il ruolo Editor include una vasta gamma di autorizzazioni, pertanto l'associazione dell'account di servizio predefinito alle VM rappresenta un rischio per la sicurezza. Per evitare questo rischio, puoi creare e utilizzare account di servizio dedicati per ogni livello dello stack dell'applicazione. Per specificare alle risorse a cui l'account di servizio può accedere, usano criteri granulari. Per ulteriori informazioni, consulta Limitare i privilegi degli account di servizio.

Crittografia del disco

Per impostazione predefinita, i dati archiviati nei volumi Hyperdisk vengono criptati utilizzando Chiavi di proprietà di Google e gestite da Google. Come ulteriore livello di protezione, può scegliere di criptare le chiavi di crittografia dei dati di proprietà di Google utilizzando chiavi che possiedi e gestisci in Cloud Key Management Service (Cloud KMS). Per ulteriori informazioni, consulta Informazioni sulla crittografia dei dischi.

Sicurezza della rete

Per controllare il traffico di rete tra le risorse nell'architettura, devi configurare le funzionalità appropriate Criteri per il firewall di nuova generazione (NGFW).

Ulteriori considerazioni sulla sicurezza

Quando crei l'architettura per il tuo carico di lavoro, tieni presenti le best practice e i consigli per la sicurezza a livello di piattaforma forniti nel blueprint Enterprise Foundations.

Affidabilità

Questa sezione descrive i fattori di progettazione da considerare quando si utilizza questo riferimento per creare e gestire un'infrastruttura affidabile per il deployment in Google Cloud.

Resistenza ai guasti delle VM

Nell'architettura mostrata in questo documento, se una VM Compute Engine in uno dei livelli non funziona, l'applicazione può continuare a elaborare le richieste.

  • Se una VM nel livello web o nel livello dell'applicazione si arresta in modo anomalo, il gruppo di istanze gestite pertinente la ricrea automaticamente. I bilanciatori del carico inoltrano le richieste solo al web attualmente disponibile di Compute Engine e istanze di server delle applicazioni.
  • Se la VM che ospita l'istanza del database Oracle principale ha esito negativo, il L'osservatore FSFO di Oracle Data Guard avvia un failover automatico in standby dell'istanza del database Oracle.

Riparazione automatica delle VM

A volte le VM che ospitano il livello web e il livello di applicazione potrebbero essere in esecuzione e disponibili, ma potrebbero esserci problemi con l'applicazione stessa. La l'applicazione potrebbe bloccarsi, arrestarsi in modo anomalo o avere memoria insufficiente. In questo scenario, le VM non risponderanno ai controlli di integrità del bilanciatore del carico e il bilanciatore del carico non indirizzerà il traffico alle VM non attive. Per contribuire ad assicurare che le applicazioni rispondano come previsto, puoi configurare i controlli di integrità basati su applicazioni nell'ambito del criterio di riparazione automatica dei tuoi gruppi di istanze gestite. Se l'applicazione su una determinata VM non risponde, il gruppo di istanze gestite corregge automaticamente la VM. Per ulteriori informazioni configurare la riparazione automatica, consulta Informazioni sulla riparazione delle VM per l'alta disponibilità.

Resistenza alle interruzioni delle zone

Se si verifica un'interruzione in una zona, l'applicazione rimane disponibile.

  • Il livello web e il livello di applicazione sono disponibili (e reattivi) perché le VM si trovano in MIG regionali. I gruppi di istanze gestite a livello di regione assicurano che le nuove VM vengano create automaticamente nell'altra zona per mantenere il numero minimo di VM configurato. I bilanciatori del carico inoltrano le richieste alle VM del server web e del server delle applicazioni disponibili.
  • Se un'interruzione interessa la zona che ha il database Oracle principale allora l'osservatore FSFO di Oracle Data Guard avvia un'istanza il failover all'istanza Oracle Database in standby. L'osservatore FSFO funziona su una VM in una zona diversa da quelle che hanno delle istanze di database in standby.
  • Per garantire l'alta disponibilità dei dati nei volumi Hyperdisk durante un a una singola zona, puoi usare Disponibilità elevata con Hyperdisk Balanced. Quando i dati vengono scritti in un volume, vengono replicati in modo sincrono tra due zone nella stessa regione.

Solidità alle interruzioni della regione

Se si verifica un'interruzione per entrambe le zone dell'architettura o per una regione significa che l'applicazione non è disponibile. Per ridurre i tempi di inattività causati in caso di interruzioni in più zone o regioni, puoi implementare il seguente approccio:

  • Mantieni una replica passiva (failover) dello stack di infrastruttura in un'altra regione Google Cloud.

  • Utilizza un bucket Cloud Storage a due o più regioni per archiviare i backup del database Oracle. I backup vengono replicati in modo asincrono in almeno due località geografiche. Con replica backup del database, la tua architettura è mappata Livello Silver di Oracle MAA (Massima disponibilità massima).

    Per una replica più rapida dei backup archiviati in bucket in due regioni, puoi utilizzare la replica turbo. Per ulteriori informazioni, consulta la sezione Disponibilità e durabilità dei dati.

  • Se si verifica un'interruzione nella regione principale, utilizza il backup del database ripristinare il database e attivare l'applicazione nella regione di failover. Utilizza le funzionalità di Criteri di routing DNS per instradare il traffico al bilanciatore del carico nella regione di failover.

Per le applicazioni business-critical che devono continuare a essere disponibili anche in caso di interruzione del servizio in una regione, ti consigliamo di utilizzare l'archetipo di implementazione multiregionale. Per il livello del database, puoi utilizzare Oracle Active Data Guard FSFO per eseguire il failover automatico a un'istanza Oracle Database di standby nella regione di failover. Questo approccio si mappa Livello MAA Gold di Oracle.

Scalabilità automatica MIG

Quando esegui l'applicazione su VM in un gruppo di istanze gestite regionale, l'applicazione rimane disponibile durante le interruzioni isolate delle zone. La funzionalità di scalabilità automatica dei gruppi di istanze gestite stateless consente di mantenere la disponibilità e le prestazioni delle applicazioni a livelli prevedibili. I gruppi di istanze gestite stateful non possono essere sottoposti a ridimensionamento automatico.

Per controllare il comportamento della scalabilità automatica dei gruppi di istanze gestite, puoi specificare come l'utilizzo medio della CPU. Puoi anche configurare la scalabilità automatica in base alla pianificazione. Per ulteriori informazioni, vedi Gruppi di istanze con scalabilità automatica.

Posizionamento VM

Nell'architettura descritta in questo documento, il livello di applicazione e di livello base, vengono eseguite su VM di Compute Engine distribuite su più zone. Questa distribuzione garantisce la robustezza dell'applicazione in caso di interruzioni in una singola zona. Per migliorare ulteriormente questa robustezza, puoi creare un criterio di posizionamento distribuito e applicarlo al modello MIG. Con crema di posizionamento, quando il gruppo di istanze gestite crea le VM, le posiziona all'interno di ciascuna zona diversi server fisici (chiamati host), in modo che le tue VM siano robuste degli errori dei singoli host. Tuttavia, un compromesso con questo approccio è che potrebbe aumentare la latenza per il traffico di rete tra VM. Per ulteriori informazioni, consulta la Panoramica delle norme relative al posizionamento.

Pianificazione della capacità delle VM

per assicurarti che la capacità per le VM di Compute Engine sia disponibile necessaria per la scalabilità automatica MIG, puoi creare prenotazioni. Una prenotazione fornisce una capacità garantita in una zona specifica per un numero specificato di VM di un tipo di macchina scelto. Una prenotazione può essere specifica per un progetto possono essere condivisi tra più progetti. Gli addebiti per le risorse prenotate vengono applicati anche se non viene eseguito il provisioning delle risorse o se non vengono utilizzate. Per ulteriori informazioni per le prenotazioni, incluse le considerazioni sulla fatturazione, Prenotazioni delle risorse di zona Compute Engine.

Disponibilità dello spazio di archiviazione a blocchi

L'architettura in questo documento utilizza un pool di archiviazione Hyperdisk in ogni zona per fornire archiviazione a blocchi per le VM Compute Engine. Creerai un pool di capacità di archiviazione a blocchi per una zona. Quindi creerai volumi Hyperdisk pool di archiviazione e collegare i volumi alle VM nella zona. Il pool di archiviazione tenta di aggiungere automaticamente capacità per assicurare che il tasso di utilizzo non superi l'80% della capacità di provisioning del pool. Questo approccio garantisce che lo spazio di archiviazione a blocchi sia disponibile quando necessario. Per ulteriori informazioni, consulta Come funzionano i pool di archiviazione Hyperdisk.

Archiviazione stateful

Una best practice nella progettazione delle applicazioni è evitare la necessità di un client stateful i dischi permanenti. Tuttavia, se il requisito esiste, puoi configurare i dischi in modo che siano stateful per assicurarti che i dati vengano conservati quando le VM vengono riparate o ricreate. Tuttavia, ti consigliamo di mantenere i dischi di avvio stateless, in modo da poterli aggiornare facilmente alle immagini più recenti con nuove versioni e patch di sicurezza. Per ulteriori informazioni, consulta la pagina Configurazione dei dischi permanenti stateful nei gruppi di istanze gestite.

Backup e ripristino

L'architettura in questo documento utilizza Cloud Storage per archiviare i database backup. Se scegli il tipo di località con due regioni o più regioni per il bucket Cloud Storage, i backup vengono replicati in modo asincrono in almeno due località geografiche. Se si verifica un'interruzione del servizio a livello di regione, puoi utilizzare i backup per ripristinare il database in un'altra regione. Con un secchio con due regioni, puoi ottenere una replica più rapida attivando l'opzione di replica turbo. Per ulteriori informazioni, consulta la sezione Disponibilità e durabilità dei dati.

Puoi utilizzare il servizio di backup e RE per creare, archiviare e gestire i backup dei di Compute Engine. Il servizio di backup e RE archivia i dati di backup nel formato originale leggibile dall'applicazione. Se necessario, puoi ripristinare i carichi di lavoro in produzione utilizzando direttamente i dati dello spazio di archiviazione di backup a lungo termine senza attività di spostamento o preparazione dei dati che richiedono molto tempo. Per ulteriori informazioni, consulta la seguente documentazione:

Ulteriori considerazioni sull'affidabilità

Quando crei l'architettura cloud per il tuo carico di lavoro, consulta le best practice e i consigli relativi all'affidabilità forniti nella seguente documentazione:

Ottimizzazione dei costi

Questa sezione fornisce indicazioni per ottimizzare il costo della configurazione e del funzionamento di una topologia Google Cloud creata utilizzando questa architettura di riferimento.

Tipi di VM

Per aiutarti a ottimizzare l'utilizzo delle risorse VM, Compute Engine fornisce suggerimenti sul tipo di macchina. Utilizza i consigli per scegliere i tipi di macchine adatti ai requisiti di calcolo del tuo carico di lavoro. Per i carichi di lavoro con requisiti prevedibili in termini di risorse, puoi personalizzare il tipo di macchina in base alle tue esigenze e risparmiare denaro utilizzando tipi di macchine personalizzate.

Modello di provisioning delle VM

Se la tua applicazione è a tolleranza di errore, VM spot può aiutarti a ridurre i costi di Compute Engine per le tue VM nel livello web e dal livello di applicazione. Il costo delle VM spot è notevolmente inferiore rispetto alle VM normali. Tuttavia, Compute Engine potrebbe arrestarsi o eliminare Trova le VM per recuperare capacità.

Le VM spot sono adatte per job batch in grado di tollerare il prerilascio che non prevedono requisiti di alta disponibilità. Le VM spot offrono lo stesso tipi di macchine, opzioni e prestazioni delle VM normali. Tuttavia, quando la capacità delle risorse in una zona è limitata, i gruppi di istanze gestite con VM spot potrebbero non essere in grado di eseguire lo scale out (ovvero creare VM) automaticamente per raggiungere le dimensioni target specificate finché la capacità richiesta non diventa di nuovo disponibile. Non utilizzare VM Spot per le VM che ospitano le istanze di Oracle Database.

Utilizzo delle risorse VM

La funzionalità di scalabilità automatica dei gruppi di istanze gestite stateless consente alla tua applicazione di gestire in modo graduale gli aumenti del traffico verso il livello web e il livello di applicazione. Anche la scalabilità automatica consente di ridurre i costi quando il fabbisogno di risorse è ridotto. MIG stateful non possono essere scalati automaticamente.

Licenze Oracle Database

Sei responsabile dell'approvvigionamento delle licenze per i prodotti Oracle che su Compute Engine, ed è tua responsabilità rispettare le termini e condizioni delle licenze Oracle. Quando calcoli il valore Il costo delle licenze per i database, considera il numero di licenze per i processori Oracle in base al tipo di macchina scelto per l'applicazione VM di Compute Engine che ospitano le istanze del database Oracle. Per ulteriori informazioni, consulta Licenze del software Oracle nell'ambiente di cloud computing.

Utilizzo delle risorse di archiviazione a blocchi

L'architettura in questo documento utilizza un pool di archiviazione Hyperdisk in ciascuna zona per l'archiviazione a blocchi per le VM di Compute Engine. Puoi migliorare l'utilizzo complessivo della capacità di archiviazione a blocchi e ridurre i costi utilizzando i pool di archiviazione con capacità avanzata, che utilizzano il thin provisioning e le tecnologie di riduzione dei dati per migliorare l'efficienza dello spazio di archiviazione.

Ulteriori considerazioni sui costi

Quando crei l'architettura per il carico di lavoro, considera anche le regole generali best practice e consigli forniti in Framework dell'architettura Google Cloud: ottimizzazione dei costi.

Efficienza operativa

Questa sezione descrive i fattori da considerare quando si utilizza questo riferimento per progettare una topologia Google Cloud che puoi utilizzare in modo efficiente.

Aggiornamenti della configurazione delle VM

ad aggiornare la configurazione delle VM in un gruppo di istanze gestite (ad esempio il tipo di macchina o immagine disco di avvio), crei un nuovo modello di istanza con configurazione e quindi applicare il nuovo modello al gruppo di istanze gestite. Il gruppo di istanze gestite aggiorna le VM utilizzando un metodo di aggiornamento specificato da te: automatico o selettivo. Scegli un metodo appropriato in base ai tuoi requisiti di disponibilità ed efficienza operativa. Per ulteriori informazioni su questi metodi di aggiornamento del gruppo di istanze gestite, consulta Applica nuove configurazioni di VM in un gruppo di istanze gestite.

Immagini VM

Per i modelli di istanze MIG, anziché utilizzare le immagini pubbliche fornite da Google, ti consigliamo di creare e utilizzare immagini del sistema operativo personalizzate che includono le configurazioni e il software richiesti dalle tue applicazioni. Puoi raggruppare le immagini personalizzate in una famiglia di immagini personalizzate. Una famiglia di immagini punta all'immagine più recente della famiglia, in modo che i modelli di istanza e gli script possono utilizzare l'immagine senza che tu debba aggiornare i riferimenti a una specifica dell'immagine. Devi aggiornare regolarmente le immagini personalizzate in modo da includere gli aggiornamenti e le patch di sicurezza forniti dal fornitore del sistema operativo.

Modelli di istanza deterministici

Se i modelli di istanze che utilizzi per i tuoi MIG includono script di avvio (ad esempio per installare software di terze parti), assicurati che gli script specifichino esplicitamente i parametri di installazione del software, come la versione del software. In caso contrario, quando il gruppo di istanze gestite crea le VM, il software installato sulle VM potrebbe non essere coerente. Ad esempio, se il modello di istanza include uno script di avvio per installare Apache HTTP Server 2.0 (il pacchetto apache2), assicurati che lo script specifichi la versione esatta di apache2 da installare, ad esempio la versione 2.4.53. Per ulteriori informazioni, vedi Modelli di istanza deterministici.

Gestione dello spazio di archiviazione a blocchi

L'architettura in questo documento utilizza un pool di archiviazione Hyperdisk in ogni zona per fornire archiviazione a blocchi per le VM Compute Engine. I pool di archiviazione Hyperdisk semplificano la gestione dello spazio di archiviazione. Invece di allocare e gestire la capacità singolarmente per numerosi dischi, definisci un pool di capacità che può essere condiviso tra più carichi di lavoro in una zona. Poi crei i volumi Hyperdisk nel pool di archiviazione e li colleghi alle VM nella zona. Lo spazio di archiviazione il pool tenta di aggiungere automaticamente capacità per garantire che il tasso di utilizzo non superi l'80% della capacità di provisioning del pool.

Connettività del server di applicazioni al database

Per le connessioni dalla tua applicazione a Oracle Database, ti consigliamo di utilizzare il nome DNS interno di zona della VM del database anziché il relativo indirizzo IP. Google Cloud risolve automaticamente il DNS all'indirizzo IP interno principale della VM. Un ulteriore vantaggio di questo approccio è che non è necessario prenotare e assegnare indirizzi IP interni statici per le VM di database.

Amministrazione e assistenza di Oracle Database

Quando esegui un'istanza Oracle Database autogestita su una VM Compute Engine, si verificano problemi operativi simili a quelli che si verificano quando esegui Oracle Database on-premise. Tuttavia, con una VM Compute Engine non devi più gestire l'infrastruttura di calcolo, networking e archiviazione sottostante.

Ulteriori considerazioni operative

Quando crei l'architettura per il carico di lavoro, considera la soluzione migliore in generale pratiche e raccomandazioni per l'efficienza operativa descritte in Framework dell'architettura Google Cloud: eccellenza operativa.

Ottimizzazione delle prestazioni

Questa sezione descrive i fattori da considerare quando utilizzi questa architettura di riferimento per progettare una topologia in Google Cloud che soddisfi i requisiti di prestazioni dei tuoi carichi di lavoro.

Prestazioni di calcolo

Compute Engine offre un'ampia gamma di tipi di macchine predefinite e personalizzabili tra cui scegliere in base ai requisiti di prestazioni dei tuoi carichi di lavoro.

  • Per le VM che ospitano il livello web e il livello di applicazione, scegli un'opzione il tipo di macchina appropriato in base ai requisiti di prestazioni diversi livelli. per ottenere un elenco dei tipi di macchina disponibili che supportano Hyperdisk. volumi e che soddisfano le tue prestazioni e altri requisiti, utilizza Confronto di serie di macchine tabella.
  • Per le VM che ospitano le istanze di Oracle Database, ti consigliamo di utilizzare un tipo di macchina della serie di macchine C4 della famiglia di macchine per uso generico. I tipi di macchine C4 offrono con prestazioni costantemente elevate per i carichi di lavoro dei database.

Rendimento della rete

Per i carichi di lavoro che richiedono una bassa latenza di rete inter-VM, puoi creare un criterio di posizionamento compatto e applicarlo al modello di gruppo di istanze gestite utilizzato per il livello di applicazione. Quando il gruppo di istanze gestite crea le VM, le posiziona in posizioni fisiche a server vicini tra loro. Un criterio di posizionamento compatto consente migliorare le prestazioni della rete tra VM, un criterio di posizionamento distribuito può contribuire a migliorare Disponibilità delle VM come descritto in precedenza. Per raggiungere un equilibrio ottimale tra e disponibilità della rete, quando si crea un posizionamento compatto puoi specificare la distanza tra le VM. Per maggiori informazioni le informazioni, vedi Panoramica dei criteri di posizionamento.

Compute Engine prevede un limite per il traffico in uscita per VM larghezza di banda della rete. Questo limite dipende dal tipo di macchina della VM e dal fatto che il traffico venga indirizzato tramite la stessa rete VPC della VM di origine. Per le VM con determinati tipi di macchine, per migliorare le prestazioni di rete puoi ottenere una larghezza di banda in uscita massima più elevata attivando le prestazioni di rete Tier_1. Per ulteriori informazioni, consulta Configurare le prestazioni di rete Tier_1 per VM.

Prestazioni dello spazio di archiviazione Hyperdisk

L'architettura descritta in questo documento utilizza volumi Hyperdisk per le VM in tutti i livelli. Hyperdisk consente di scalare prestazioni e capacità in modo dinamico. Puoi modificare le IOPS, la velocità effettiva e le dimensioni di ciascun volume sottoposte a provisioning in base alle esigenze di prestazioni e capacità dello spazio di archiviazione del tuo carico di lavoro. La delle prestazioni dei volumi Hyperdisk dipendono dal tipo di Hyperdisk e dalla macchina delle VM a cui sono collegati i volumi. Per ulteriori informazioni Limiti delle prestazioni e ottimizzazione Hyperdisk, consulta la documentazione seguente:

Altre considerazioni sul rendimento

Quando crei l'architettura per il tuo carico di lavoro, tieni conto delle best practice e dei consigli generali forniti nel framework dell'architettura di Google Cloud: ottimizzazione delle prestazioni.

Passaggi successivi

Collaboratori

Autore: Kumar Dhanagopal | Sviluppatore di soluzioni cross-product

Altri collaboratori: