Distribuisci Apache Tomcat connesso al servizio MySQL Database
MySQL Database Service è un servizio nativo Oracle Cloud Infrastructure completamente gestito. È stato sviluppato, gestito e supportato dal team MySQL in Oracle. Task quali backup e recupero, applicazione di patch al database e al sistema operativo e così via vengono automatizzati. L'utente è responsabile esclusivamente della gestione dei dati, della progettazione dello schema e dei criteri di accesso.
Architettura
L'architettura di riferimento contiene un load balancer, un livello di applicazione con Apache Tomcat e un livello di database con un servizio MySQL Database abilitato per HA.
I componenti si trovano in subnet diverse. Il load balancer si trova in una subnet pubblica. I server Tomcat condividono una subnet privata e il database si trova nella propria subnet privata. Tutto l'accesso esterno avviene tramite il load balancer tramite un gateway Internet.
Il servizio MySQL Database abilitato per HA è un'astrazione di un cluster. Dispone di tre istanze di MySQL ma con un singolo endpoint. Un'istanza è Primaria e le altre due istanze sono Secondarie. Il primario ha il singolo endpoint, consentendo letture e scritture nel database. I secondari ricevono dati replicati dal primario. Non è consentito l'accesso diretto ai secondari.
In caso di guasto o switchover manuale, uno dei Secondari diventa il nuovo Primario e l'endpoint viene reindirizzato ad esso. Ciò significa che l'indirizzo IP dell'endpoint non cambia mai e che non è necessario aggiornare l'applicazione.
È inclusa un'applicazione di esempio che mostra la gestione delle sessioni dell'applicazione utilizzando il database.
Il seguente diagramma illustra questa architettura di riferimento.
Descrizione dell'immagine architecture-deploy-tomcat-mds-ha.png
Architecture-deploy-tomcat-mds-oracle.zip
Se la subnet è regionale, le tre istanze di MySQL vengono posizionate in domini di disponibilità e domini di errore diversi. Nelle aree con un singolo dominio di disponibilità, le istanze di MySQL vengono posizionate in domini di errore diversi all'interno dello stesso dominio di disponibilità.
L'architettura ha i seguenti componenti:
- Area
Un'area Oracle Cloud Infrastructure è un'area geografica localizzata che contiene uno o più data center, denominati domini di disponibilità. Le regioni sono indipendenti da altre regioni, e vaste distanze possono separarle (tra paesi o addirittura continenti).
- Domini di disponibilità
I domini di disponibilità sono data center indipendenti e autonomi all'interno di un'area. Le risorse fisiche in ogni dominio di disponibilità vengono isolate dalle risorse negli altri domini di disponibilità, il che fornisce tolleranza agli errori. I domini di disponibilità non condividono infrastrutture quali l'alimentazione o il raffreddamento o la rete di dominio di disponibilità interna. È quindi improbabile che un errore a un dominio di disponibilità influenzi gli altri domini di disponibilità nell'area.
- Domini di errore
Un dominio di errore è un raggruppamento di hardware e infrastruttura all'interno di un dominio di disponibilità. Ogni dominio di disponibilità ha tre domini di guasto con alimentazione e hardware indipendenti. Quando si distribuiscono risorse su più domini di errore, le applicazioni possono tollerare errori fisici del server, la manutenzione del sistema e gli errori di alimentazione all'interno di un dominio di errore.
- Rete cloud virtuale (VCN) e subnet
Una VCN è una rete personalizzabile e definita dal software impostata dall'utente in un'area Oracle Cloud Infrastructure. Come le reti di data center tradizionali, le VCN offrono il controllo completo sull'ambiente di rete. Una VCN può avere più blocchi CIDR non sovrapposti che è possibile modificare dopo aver creato la VCN. È possibile segmentare una VCN in subnet, che può essere definita in un'area o in un dominio di disponibilità. Ogni subnet è costituita da un intervallo contiguo di indirizzi che non si sovrappongono con le altre subnet nella VCN. Puoi modificare la dimensione di una subnet dopo la creazione. Una subnet può essere pubblica o privata.
- Load balancer
Il servizio Oracle Cloud Infrastructure Load Balancing fornisce la distribuzione automatica del traffico da un singolo punto di accesso a più server nel backend.
- Lista di sicurezza
Per ogni subnet è possibile creare regole di sicurezza che specifichino l'origine, la destinazione e il tipo di traffico che devono essere consentiti all'interno e all'esterno della subnet.
- Tabella instradamento
Le tabelle di instradamento virtuale contengono regole per instradare il traffico dalle subnet alle destinazioni al di fuori di un VCN, in genere tramite gateway.
- Gateway Internet
Il gateway Internet consente il traffico tra le subnet pubbliche in un VCN e Internet pubblico.
- Server Tomcat
I server Tomcat ospitano Java Servlet, JavaServer Pages, Java Expression Language e Java WebSockets. Le applicazioni esistono in questo layer.
- Database server
Tomcat può connettersi a qualsiasi database che offre JDBC (Java Database Connectivity). Questa architettura utilizza MySQL Database Service.
- Host di base
L'host bastion è un'istanza di calcolo che funge da punto di accesso sicuro e controllato alla topologia dall'esterno del cloud. L'host bastione viene eseguito in genere in una zona demilitarizzata (DMZ). Consente di proteggere le risorse sensibili inserendole in reti private a cui non è possibile accedere direttamente dall'esterno del cloud. La topologia dispone di un singolo punto di accesso noto che è possibile monitorare e controllare regolarmente. Così, è possibile evitare di esporre i componenti più sensibili della topologia senza compromettere l'accesso a loro.
Suggerimenti
Le vostre esigenze potrebbero differire dall'architettura descritta qui. Utilizzare i suggerimenti riportati di seguito come punto di partenza.
- VCN
Quando crei una VCN, determina il numero di blocchi CIDR necessari e la dimensione di ogni blocco in base al numero di risorse che intendi collegare alle subnet nella VCN. Utilizzare i blocchi CIDR che si trovano all'interno dello spazio di indirizzi IP privati standard.
Selezionare i blocchi CIDR che non si sovrappongono a qualsiasi altra rete (in Oracle Cloud Infrastructure, il data center on premise o un altro provider cloud) a cui si intende impostare connessioni private.
Dopo aver creato una VCN, è possibile modificare, aggiungere e rimuovere i relativi blocchi CIDR.
Quando si progettano le subnet, prendere in considerazione il flusso di traffico e i requisiti di sicurezza. Allegare tutte le risorse all'interno di uno specifico livello o ruolo alla stessa subnet, che può fungere da limite di sicurezza.
- Load balancer
Questa architettura utilizza un load balancer da 10 Mbps incluso nel livello Sempre libero. A seconda del numero di connessioni simultanee necessarie e del throughput totale, è possibile utilizzare forme più grandi. Il throughput può essere modificato in qualsiasi momento.
Si consiglia di utilizzare i nomi DNS perché l'indirizzo IP del load balancer non può essere riservato.
- Istanze
Tutte le tenancie ottengono due istanze di Virtual Machine (VM) sempre gratuite, utilizzate da questa architettura per i server Tomcat.
Se è richiesta più potenza di elaborazione, è possibile selezionare forme diverse.
- Sistemi di database
Connessione a MySQL: installare il client MySQL più recente e installare anche MySQL Shell dal repository di MySQL Yum. Vedere la sezione Ulteriori informazioni per un collegamento all'utilizzo del repository di MySQL Yum.
- Memoria
Le istanze di questa architettura utilizzano una normale memorizzazione a blocchi; non sono necessarie prestazioni aggiuntive.
- Connettività di rete
È possibile gestire l'ambiente connettendosi all'infrastruttura locale esistente utilizzando una VPN site-to-site o una connessione dedicata a FastConnect.
Se è necessario separare l'ambiente dall'infrastruttura esistente o accedervi esternamente, un host bastione può proteggere le connessioni di gestione. L'host bastione viene in genere eseguito il provisioning in una zona demilitarizzata (DMZ). Protegge le risorse sensibili inserendole in reti private a cui non è possibile accedere direttamente dall'esterno del cloud. È possibile evitare di esporre i componenti più sensibili dell'architettura senza comprometterne l'accesso.
Considerazioni
Durante la distribuzione di questa architettura di riferimento, prendere in considerazione i seguenti punti.
- Prestazioni
È possibile regolare le prestazioni in base alle esigenze specifiche dell'applicazione modificando le forme dell'istanza (se si utilizza la serie Intel) oppure OCPU e memoria separatamente (se si utilizza la serie AMD).
Impossibile modificare l'istanza di database al momento. Scegli la dimensione adeguata quando la crei.
- Sicurezza
Ad eccezione dell'host bastione (se presente) e dei load balancer, tutti i componenti devono essere posizionati in subnet private.
Se è richiesta una sicurezza rigorosa, prendere in considerazione l'opportunità di usufruire delle zone di sicurezza di Oracle. È incluso senza costi aggiuntivi.
- Disponibilità
Il load balancer viene fornito con un'istanza in standby e non richiede alcun intervento in caso di failover.
I server Tomcat vengono distribuiti come coppia e bilanciati dal load balancer. Ogni istanza Tomcat si trova in un dominio di errore diverso.
Eseguire il backup del database il più spesso necessario per soddisfare l'obiettivo del punto di recupero (RPO) previsto.
Sebbene non frequente, adeguare la finestra di manutenzione per MySQL Database Service in modo che corrisponda alle esigenze dell'organizzazione.
- Costo
Il costo di questa architettura cambia in base alle dimensioni e alle forme delle istanze, del database e dei load balancer. Nessun componente con costi variabili.
Distribuisci
Il codice richiesto per distribuire questa architettura di riferimento è disponibile in GitHub. È possibile estrarre il codice in Oracle Cloud Infrastructure Resource Manager con un solo clic, creare lo stack e distribuirlo. In alternativa, scaricare il codice da GitHub nel computer, personalizzare il codice e distribuire l'architettura utilizzando Terraform CLI.
- Distribuisci utilizzando Oracle Cloud Infrastructure Resource Manager:
- Fare clic su
Se non si è già connessi, immettere la tenancy e le credenziali utente.
- Rivedere e accettare i termini e le condizioni.
- Selezionare l'area in cui distribuire lo stack.
- Seguire i prompt e le istruzioni visualizzate sullo schermo per creare lo stack.
- Dopo aver creato lo stack, fare clic su Azioni Terraform e selezionare Piano.
- Attendere il completamento del job e rivedere il piano.
Per apportare eventuali modifiche, tornare alla pagina Dettagli stack, fare clic su Modifica stack e apportare le modifiche necessarie. Eseguire nuovamente l'azione Piano.
- Se non sono necessarie ulteriori modifiche, tornare alla pagina Dettagli stack, fare clic su Azioni Terraform e selezionare Applica.
- Fare clic su
- Distribuzione con il codice Terraform in GitHub:
- Andare a GitHub.
- Duplicare o scaricare il repository nel computer locale.
- Seguire le istruzioni contenute nel documento
README.
Ulteriori informazioni
- Creazione di un cluster Tomcat con persistenza sessione MySQL
- Utilizzo della persistenza di JDBCStore for Session
- Introduzione a MySQL Database Service
- Guida rapida all'utilizzo del repository MySQL Yum (per l'aggiornamento del client MySQL e per l'installazione della shell MySQL)
Log modifiche
Questo log elenca solo le modifiche significative:
| 24 febbraio 2022 |
|
| 7 gennaio 2021 | Aggiunte istruzioni per distribuire l'architettura utilizzando Oracle Cloud Infrastructure Resource Manager. |