Desplegar Apache Tomcat conectado al servicio MySQL Database
MySQL Database Service es un servicio nativo Oracle Cloud Infrastructure totalmente gestionado. Está desarrollado, gestionado y soportado por el equipo de MySQL en Oracle. Tareas como copia de seguridad y recuperación, aplicación de parches de base de datos y sistema operativo, etc., se automatizan. Usted es el único responsable de gestionar sus datos, diseños de esquema y políticas de acceso.
Arquitectura
La arquitectura de referencia contiene un equilibrador de carga, un nivel de aplicación con Apache Tomcat y un nivel de base de datos con un servicio MySQL Database habilitado para alta disponibilidad.
Los componentes se encuentran en diferentes subredes. El equilibrador de carga está en una subred pública. Los servidores Tomcat comparten una subred privada y la base de datos está en su propia subred privada. Todo el acceso externo es a través del equilibrador de carga a través de un gateway de Internet.
El servicio MySQL Database habilitado para alta disponibilidad es una abstracción de un cluster. Tiene tres instancias de MySQL, pero con un único punto final. Una instancia es Primaria y las otras dos instancias son Secundarias. El Primario tiene el único punto final, lo que permite leer y escribir en la base de datos. Los Secundarios reciben datos replicados del Primario. No se permite el acceso directo a los secundarios.
En caso de fallo o conmutación manual, uno de los Secundarios se convierte en el nuevo Primario y el punto final se redirige a él. Esto significa que la dirección IP del punto final nunca cambia y no hay necesidad de actualizar la aplicación.
Se incluye una aplicación de ejemplo que muestra la gestión de sesiones de aplicación mediante la base de datos.
El siguiente diagrama ilustra esta arquitectura de referencia.
Descripción de la ilustración arquitectura- deploy-tomcat-mds-ha.png
arquitectura-despliegue-tomcat-mds-oracle.zip
Si la subred es regional, las tres instancias de MySQL se colocan en diferentes dominios de disponibilidad y dominios de fallo. En regiones con un único dominio de disponibilidad, las instancias de MySQL se colocan en diferentes dominios de fallo dentro del mismo dominio de disponibilidad.
La arquitectura tiene los siguientes componentes:
- Región
Una región de Oracle Cloud Infrastructure es un área geográfica localizada que contiene uno o más centros de datos, denominados dominios de disponibilidad. Las regiones son independientes de otras regiones, y grandes distancias pueden separarlas (entre países o incluso continentes).
- Dominios de disponibilidad
Los dominios de disponibilidad son centros de datos independientes e independientes dentro de una región. Los recursos físicos de cada dominio de disponibilidad están aislados de los recursos de los otros dominios de disponibilidad, lo que proporciona tolerancia a fallos. Los dominios de disponibilidad no comparten infraestructura, como energía o refrigeración, o la red de dominio de disponibilidad interna. Por lo tanto, es poco probable que un fallo en un dominio de disponibilidad afecte a los otros dominios de disponibilidad de la región.
- Dominios de Fallos
Un dominio de fallo es una agrupación de hardware e infraestructura dentro de un dominio de disponibilidad. Cada dominio de disponibilidad tiene tres dominios de fallos con energía y hardware independientes. Cuando distribuye recursos en varios dominios de fallos, las aplicaciones pueden tolerar fallos físicos del servidor, mantenimiento del sistema y fallos de energía dentro de un dominio de fallos.
- Red virtual en la nube (VCN) y subredes
Una VCN es una red personalizada y definida por software que se configura en una región de Oracle Cloud Infrastructure. Al igual que las redes del centro de datos tradicionales, las VCN le proporcionan un control completo sobre su entorno de red. Una VCN puede tener varios bloques CIDR no superpuestos que puede cambiar después de crear la VCN. Puede segmentar una VCN en subredes, que se pueden acotar a una región o a un dominio de disponibilidad. Cada subred está formada por un rango contiguo de direcciones que no se solapan con las demás subredes de la VCN. Puede cambiar el tamaño de una subred después de la creación. Una subred puede ser pública o privada.
- Equilibrador de carga
El servicio Oracle Cloud Infrastructure Load Balancing proporciona distribución automática del tráfico desde un único punto de entrada hasta varios servidores en el extremo posterior.
- Lista de seguridad
Para cada subred, puede crear reglas de seguridad que especifiquen el origen, destino y tipo de tráfico que se debe permitir dentro y fuera de la subred.
- Tabla de rutas
Las tablas de rutas virtuales contienen reglas para enrutar el tráfico de subredes a destinos fuera de VCN, normalmente a través de gateways.
- Gateway de Internet
El gateway de Internet permite el tráfico entre las subredes públicas en un VCN y el Internet público.
- Servidores Tomcat
Los servidores Tomcat alojan Java Servlet, JavaServer Pages, Java Expression Language y Java WebSockets. Sus aplicaciones existen en esta capa.
- Servidores de base de datos
Tomcat puede conectarse a cualquier base de datos que ofrezca Java Database Connectivity (JDBC). Esta arquitectura utiliza MySQL Database Service.
- Host de Bastion
El host bastion es una instancia informática que sirve como punto de entrada seguro y controlado a la topología desde fuera de la nube. El host bastión se aprovisiona típicamente en una zona desmilitarizada (DMZ). Permite proteger los recursos sensibles colocándolos en redes privadas a las que no se puede acceder directamente desde fuera de la nube. La topología tiene un punto de entrada único y conocido que puede supervisar y auditar regularmente. Por lo tanto, puede evitar exponer los componentes más sensibles de la topología sin comprometer el acceso a ellos.
Recomendaciones
Sus requisitos pueden diferir de la arquitectura descrita aquí. Utilice las siguientes recomendaciones como punto de partida.
- VCN
Al crear una VCN, determine el número de bloques de CIDR necesarios y el tamaño de cada bloque en función del número de recursos que planea asociar a las subredes de la VCN. Utilice bloques CIDR que se encuentren dentro del espacio de direcciones IP privadas estándar.
Seleccione bloques CIDR que no se superpongan con ninguna otra red (en Oracle Cloud Infrastructure, su centro de datos local u otro proveedor en la nube) a la que desea configurar conexiones privadas.
Después de crear una VCN, puede cambiar, agregar y eliminar sus bloques de CIDR.
Cuando diseñe las subredes, tenga en cuenta sus requisitos de flujo de tráfico y seguridad. Conecte todos los recursos dentro de un nivel o rol específico a la misma subred, que puede servir como límite de seguridad.
- Equilibrador de carga
Esta arquitectura utiliza un equilibrador de carga de 10 Mbps que se incluye en el nivel Siempre Libre. Dependiendo del número de conexiones simultáneas necesarias y del rendimiento total, puede utilizar formas más grandes. El rendimiento se puede editar en cualquier momento.
Recomendamos que utilice nombres de DNS porque la dirección IP del equilibrador de carga no se puede reservar.
- Instancias
Todos los arrendamientos obtienen dos instancias de máquina virtual (VM) siempre gratuitas, que esta arquitectura utiliza para los servidores Tomcat.
Si se requiere más potencia de procesamiento, puede seleccionar diferentes formas.
- Sistemas de base de datos
Conexión a MySQL: instale el último cliente de MySQL e instale también el shell de MySQL desde el repositorio de Yum de MySQL. Consulte la sección Más información para obtener un enlace para utilizar el repositorio de MySQL Yum.
- Almacenamiento
Las instancias de esta arquitectura utilizan almacenamiento de bloques regular; no se requiere ningún rendimiento adicional.
- Conectividad de Red
Puede gestionar el entorno conectándose a la infraestructura local existente mediante una VPN de sitio a sitio o una conexión específica con FastConnect.
Si es necesario separar el entorno de la infraestructura existente o acceder externamente, un host bastion puede proteger las conexiones de gestión. Normalmente, el host bastión se aprovisiona en una zona desmilitarizada (DMZ). Protege los recursos sensibles colocándolos en redes privadas a las que no se puede acceder directamente desde fuera de la nube. Puede evitar exponer los componentes más sensibles de la arquitectura sin comprometer el acceso a ellos.
Consideraciones
Tenga en cuenta los siguientes puntos al desplegar esta arquitectura de referencia.
- Rendimiento
Puede ajustar el rendimiento para que coincida con las necesidades específicas de la aplicación cambiando las formas de instancia (si se utiliza la serie Intel) o OCPU y memoria por separado (si se utiliza la serie AMD).
La instancia de base de datos no se puede cambiar en este momento. Elija el tamaño adecuado al crearlo.
- Seguridad
Excepto para el host de bastión (si está presente) y los equilibradores de carga, todos los componentes se deben colocar en subredes privadas.
Si se necesita una seguridad rigurosa, considere la posibilidad de aprovechar las zonas de seguridad de Oracle. Está incluido sin costo adicional.
- Disponibilidad
El equilibrador de carga viene con una instancia en espera y no requiere intervención si se produce un failover.
Los servidores Tomcat se despliegan como un par y están equilibrados por el equilibrador de carga. Cada instancia de Tomcat se encuentra en un dominio de fallos diferente.
Realice una copia de seguridad de la base de datos tan a menudo como sea necesario para que coincida con el objetivo de punto de recuperación previsto (RPO).
Aunque es poco frecuente, ajuste la ventana de mantenimiento de MySQL Database Service para que coincida con las necesidades de la organización.
- Costo
El costo de esta arquitectura cambia en función del tamaño y las formas de las instancias, la base de datos y los equilibradores de carga. No hay componentes con costos variables.
Desplegar
El código necesario para desplegar esta arquitectura de referencia está disponible en GitHub. Puede extraer el código a Oracle Cloud Infrastructure Resource Manager con un solo clic, crear la pila y desplegarlo. También puede descargar el código de GitHub en el equipo, personalizar el código y desplegar la arquitectura mediante la CLI de Terraform.
- Desplegar mediante Oracle Cloud Infrastructure Resource Manager:
- Haga clic en
Si aún no ha iniciado sesión, introduzca las credenciales de arrendamiento y usuario.
- Revise y acepte los términos y condiciones.
- Seleccione la región en la que desea desplegar la pila.
- Siga las instrucciones y peticiones de datos en pantalla para crear la pila.
- Después de crear la pila, haga clic en Acciones Terraform y seleccione Plan.
- Espere a que se complete el trabajo y revise el plan.
Para realizar cualquier cambio, vuelva a la página Detalles de pila, haga clic en Editar pila y realice los cambios necesarios. A continuación, vuelva a ejecutar la acción Plan.
- Si no son necesarios otros cambios, vuelva a la página Detalles de Pila, haga clic en Acciones de Terraform y seleccione Aplicar.
- Haga clic en
- Desplegar con el código Terraform en GitHub:
- Vaya a GitHub.
- Clone o descargue el repositorio en su computadora local.
- Siga las instrucciones del documento
README.
Más información
- Crear un cluster de Tomcat con Persistencia de Sesiones de MySQL
- Uso de JDBCStore para la persistencia de la sesión
- Introducción al Servicio MySQL Database
- Guía rápida para utilizar MySQL Yum Repository (para actualizar MySQL Client e instalar MySQL Shell)
Cambiar Log
Este log muestra solo los cambios significativos:
| 24 de febrero de 2022 |
|
| 7 de enero de 2021 | Se han agregado instrucciones para desplegar la arquitectura mediante Oracle Cloud Infrastructure Resource Manager. |