Unidad 8.3: Laboratorio de piedra angular - Construir el núcleo empresarial de extremo a extremo

Introducción

Cada módulo anterior construyó una pieza del entorno de FinCorp en aislamiento y mantuvo esa construcción deliberadamente ligera. Esta unidad es donde las piezas se convierten en un sistema. Usted configurará el núcleo de producción en un solo centro de datos virtual: la topología de tres niveles del Módulo 3, los equilibradores de carga de capa 7 pública y capa 4 privada, el PostgreSQL Cluster y el In-Memory DB caché en el nivel de datos privado del Módulo 5, un Managed Kubernetes Cluster del Módulo 6, y las puertas de enlace híbridas VPN y NAT que llevan el corte.

La piedra angular no vuelve a enseñar cada construcción; hace referencia a la unidad que lo hizo. Lo que agrega es lo que ninguna unidad individual podía mostrar: el orden de ensamblaje y las dependencias entre recursos. El error recurrente cuando estas construcciones se encuentran no es un valor de campo incorrecto, es una secuencia incorrecta, un equilibrador de carga creado antes de que existan sus objetivos, una puerta de enlace creada antes de que se reserve su IP público, una base de datos a la que se le asigna una dirección que colisiona con DHCP. Obtenga el orden correcto y la arquitectura de la Unidad 8.2 se vuelve real.

1. El orden de compilación es un grafo de dependencias, no una lista de tareas

La decisión más importante en una compilación integrada es la secuencia. Varios recursos de IONOS no pueden crearse o no pueden funcionar hasta que algo más exista primero, y la plataforma no siempre reordena el trabajo para usted. Trate la compilación como un grafo de dependencias y resuélvalo de abajo hacia arriba.

Cuatro reglas de ordenación conllevan la mayoría del riesgo, y cada una se estableció en una unidad anterior:

• Reserve las direcciones IP públicas primero. Un ALB público necesita al menos un listener IP, el VPN Gateway y el NAT Gateway cada uno selecciona desde direcciones reservadas, y un Kubernetes LoadBalancer ingreso IP debe reservarse para que la eliminación de un Servicio no la libere. La dirección IPv4 reservada está vinculada a la región, así que réservela en la región del VDC. Esta es la regla detrás de los errores comunes en las Unidades 3.1, 3.3 y 3.6.
• El VDC y sus LANs preceden a todo. La topología de tres LAN de la Unidad 3.1 es el sustrato. Los servidores, bases de datos, balancers y gateways se conectan a LANs que deben existir ya, con direcciones reservadas para que los servicios gestionados y los gateways tengan espacio (el rango .2 a .9 se mantiene claro, el nivel de datos en una dirección estática estable).
• Un balancer necesita sus objetivos primero. El NLB de capa 4 privado de la Unidad 3.4 se distribuye a servidores de nivel de datos que deben estar provisionados ya en su LAN privado; un NLB apuntando a objetivos que no existen no tiene nada que enrutrar. Lo mismo se aplica a los objetivos de la aplicación detrás del ALB de capa 7.
• La red híbrida precede a las cargas de trabajo que dependen de ella. El NAT Gateway debe existir y la ruta predeterminada LAN debe apuntar a él antes de que las cargas de trabajo privadas puedan llegar a Internet para la instalación de paquetes o llamadas de salida API; el cambio de enrutamiento es el paso que los equipos olvidan.

Estas reglas producen un orden natural: sustrato de red, luego cómputo, luego el nivel de datos, luego los balancers que lo anteceden, luego la plataforma de contenedores, luego el borde híbrido. El recorrido a continuación sigue exactamente ese orden.

2. La Arquitectura Integrada que FinCorp Está Construyendo

El objetivo es la forma canónica en capas de la Unidad 1.2, ahora poblada con los productos específicos elegidos a lo largo del curso. La siguiente tabla asigna cada nivel a su producto, la unidad que lo construyó y la decisión de diseño detrás de la elección, para que el recorrido pueda hacer referencia en lugar de repetir.

Todo esto se encuentra en un VDC, en una región elegida en la Unidad 1.4 para satisfacer GDPR y la residencia de BSI. El nivel de datos nunca toca un LAN público; las únicas superficies que se enfrentan a Internet son el ALB público y las IPs reservadas de las dos puertas de enlace.

DCD Implementación paso a paso

Usted ensamblará el núcleo completo de FinCorp en el VDC creado en la Unidad 2.1, combinando las compilaciones de los Módulos 3, 5 y 6 en orden de dependencia. En lugar de repetir cada campo, cada paso nombra la unidad que documenta la compilación detallada y establece solo lo que la integración agrega: lo que ya debe existir, dónde se conecta y la decisión que lo vincula a sus vecinos. Trate las guías de paso por unidad como la referencia de nivel de campo y esta como la secuencia de ensamblaje.

Objetivo de compilación: Compilar el núcleo de empresa de FinCorp de extremo a extremo en el Data Center Designer, uniendo las guías de paso de los módulos.

Requisitos previos: El VDC de FinCorp de la Unidad 2.1 con su región fija; los privilegios Reserve IP Blocks y Create Kubernetes Clusters; un certificado PEM importado (una sola hoja RSA y clave coincidente) en el Certificate Manager para el listener HTTPS del ALB; y los detalles de conexión del centro de datos corporativo para el par IKEv2.

Pasos (en el Data Center Designer):

1. Reservar las direcciones IP públicas (hágalo primero). En Menú > Servicios de red > Administración de IP, reserve direcciones IPv4 públicas en la región del VDC para: el listener del ALB público, el VPN Gateway, el NAT Gateway y el punto de entrada de ingreso Kubernetes. Usted recibe direcciones del grupo en lugar de elegirlas, y cada una está vinculada a la región. Este solo paso inicial elimina el fallo de orden más común en las Unidades 3.1, 3.3 y 3.6.

2. Compilar la topología de tres LAN (como se construyó en la Unidad 3.1). En el VDC de FinCorp, cree el LAN de borde público (el único LAN conectado al acceso a Internet), el LAN de aplicación privada y el LAN de datos privados. Mantenga cada uno con el valor predeterminado /24, deje .2 a .9 claro para servicios y pasarelas administrados, y no conecte ninguno de los LAN privados a Internet. Esta segmentación es lo que permite que los equilibradores administrados y la base de datos permanezcan seguros sin un NSG.

3. Proporcionar los servidores de nivel de aplicación (como se construyó en la Unidad 4.1). Coloque los servidores de aplicación sin estado en el LAN de aplicación privada como servidores Dedicated Core. Dedicated Core es la elección deliberada para una garantía de rendimiento predecible bajo carga; el nivel se mantiene sin estado para que los datos de sesión vivan en la caché, no en el servidor, y para que VM Auto Scaling pueda agregar y eliminar réplicas libremente (Unidad 4.3).

4. Proporcionar los servidores o puntos de conexión de nivel de datos en el LAN de datos privados. El equilibrador de capa 4 en el paso 7 necesita objetivos que ya existan, por lo que los objetivos de nivel de datos deben estar presentes antes de que se cree el NLB. Asigne a las NIC de nivel de datos direcciones estáticas estables fuera del rango DHCP.

5. Compilar el PostgreSQL Cluster (como se construyó en la Unidad 5.3). En Menú > Bases de datos > PostgreSQL, cree una base de datos Cluster de varios Node en el LAN de datos privados. Para el libro mayor de FinCorp, seleccione la replicación Estrictamente Sincrónica con tres o más instancias, establezca una ventana de mantenimiento real fuera de horas pico y asigne una IP privada que termine entre .3 y .10 para que nunca colisione con DHCP. No hay un punto de conexión público y no hay réplica de lectura; esa brecha se llena en el siguiente paso.

6. Compilar la caché In-Memory DB (como se construyó en la Unidad 5.5). En Menú > Bases de datos > In-Memory DB, cree la caché en el mismo LAN de datos privados con una conexión privada única. Esta es la mitad de escalado de lectura del patrón sin réplica de lectura y el almacenamiento de estado externalizado que hace que el nivel de aplicación sea seguro para autoescalar. Tamaño por RAM al conjunto de trabajo; capture las credenciales en la creación porque no se pueden cambiar más tarde.

7. Compilar el NLB de capa 4 privado frente al nivel de datos (como se construyó en la Unidad 3.4). Coloque un Network Load Balancer con ambas interfaces en LAN privadas: el listener en el LAN de aplicación, el backend en el LAN de datos. Agregue los servidores de nivel de datos existentes como objetivos con una regla de reenvío TCP y una comprobación de salud TCP. El NLB no termina TLS, por lo que el certificado permanece en el backend; esta es la parte privada de la ruta en capas.

8. Compilar el ALB de capa 7 público en el borde (como se construyó en la Unidad 3.3). Cree el grupo de objetivos de servidores de aplicación primero, luego coloque un Application Load Balancer con su interfaz norte en Acceso a Internet y su interfaz sur en el LAN de aplicación. Configure el listener HTTPS en la IP pública reservada del paso 1 con el certificado PEM importado, agregue una regla de reenvío basada en ruta que apunta al grupo de objetivos y ordene reglas específicas por encima de la predeterminada. El ALB termina TLS y da la sustitución de API-gateway su mitad de borde; no tiene lista de permitidos ni NSG, por lo que el filtrado permanece en las NIC de destino.

9. Compilar el Managed Kubernetes Cluster (como se construyó en la Unidad 6.2). En Menú > Contenedores > Managed Kubernetes, cree un Cluster público con un plano de control respaldado por Frankfurt para mantener los datos del plano de control en Alemania, luego agregue un grupo de Node Dedicated Core. Conecte la LAN del grupo de Node del Cluster dentro del mismo VDC. Reserve la IP de ingreso del paso 1, implemente un controlador de ingreso en el Cluster expuesto como un servicio LoadBalancer único anclado a esa IP, y recuerde que un servicio LoadBalancer es una IP estática de un solo Node, no un equilibrador administrado; la entrada real de capa 7 frente al Cluster es el ALB separadamente aprovisionado, con el controlador de ingreso en el Cluster detrás de él.

10. Compilar el NAT Gateway para la salida privada (como se construyó en la Unidad 3.6). Agregue un NAT Gateway, conéctelo al LAN de aplicación privada, asigne una IP pública reservada del paso 1 y cree una regla SNAT para la subred de aplicación. Luego, establezca la ruta predeterminada del LAN privado (0.0.0.0/0) en el gateway; sin este cambio de enrutamiento, la salida nunca sucede en silencio. NAT es SNAT-only, por lo que no proporciona camino de entrada. Agregue una regla SNAT UDP para que DNS aún resuelva para las VM que utilizan la ruta predeterminada NAT.

11. Compilar el VPN Gateway y el túnel al centro de datos corporativo (como se construyó en la Unidad 3.6). Cree un VPN Gateway IKEv2 en su IP pública reservada, conéctelo al LAN privado con una dirección de puerta de enlace en el rango .2 a .9, luego cree un túnel al par corporativo con un PSK fuerte y parámetros de fase 1 y fase 2 coincidentes. Enumere los CIDR de red de nube y par como el contrato de enrutamiento estático; no hay BGP. Seleccione la variante de nivel de alta disponibilidad para que el par activo-pasivo comparta la IP única de la puerta de enlace.

12. Proporcionar y validar todo el VDC. Proporcione los cambios acumulados. Valide la ruta en capas de extremo a extremo: un cliente alcanza el ALB en su IP pública sobre HTTPS, el nivel de aplicación lee a través de la caché y cae en falta a PostgreSQL en un error, el NLB distribuye conexiones cifradas al nivel de datos, las cargas de trabajo privadas alcanzan Internet solo a través del NAT Gateway, y el centro de datos corporativo alcanza las LAN privadas solo a través del túnel VPN. El nivel de datos es accesible desde ningún lugar público.

Errores comunes:

• Construir un consumidor antes de que exista su IP reservada. El listener del ALB, ambas pasarelas y el punto de entrada Kubernetes esperan una dirección reservada; reserve todas ellas en el paso 1, en la región correcta, antes de que algo consuma una.
• Crear el NLB antes de que existan los objetivos de nivel de datos. Un equilibrador apuntando a objetivos ausentes se enruta a nada; proporcione el nivel de datos (paso 4) antes del NLB (paso 7).
• Apuntar el NAT Gateway a la cosa incorrecta, o olvidar la ruta predeterminada. NAT es SNAT-only con ningún camino de entrada, y la puerta de enlace no hace nada hasta que la ruta predeterminada del LAN privado se reorienta hacia él. Agregue la regla SNAT UDP también, o DNS se rompe para esas VM.
• Tratar el servicio LoadBalancer del Kubernetes como la puerta de entrada real del Cluster. Es una IP estática de un solo Node limitada a ese Node de rendimiento; la entrada de capa 7 de producción es el ALB separadamente aprovisionado, con el controlador de ingreso en el Cluster detrás de él.
• Colocar el plano de control Kubernetes en un centro de datos de EE. UU. para este Workload regulado. Elija el plano de control de Frankfurt para que los datos del plano de control permanezcan en Alemania; los datos del grupo de Node permanecen en la región elegida independientemente.
• Conectar un LAN privado a Internet "para probar", o intentar envolver un ALB o NLB administrado en un Grupo de Seguridad de Red. Los equilibradores administrados no tienen NSG; la seguridad del nivel de datos proviene enteramente de vivir en un LAN privado, por lo que una sola conexión a Internet en el LAN de datos desmantela el argumento de cumplimiento.
• Dar al PostgreSQL Cluster o a la caché una dirección dentro del rango DHCP. Reutilice los primeros tres octetos del LAN y elija una dirección que DHCP nunca asigne (que termine .3 a .10); una colisión produce fallos de conexión intermitentes y difíciles de diagnosticar.
• No coincidir los parámetros de fase 1 o fase 2 de VPN entre la puerta de enlace de IONOS y el par corporativo, o buscar una opción IKEv1. No hay IKEv1; los parámetros deben coincidir exactamente en ambos extremos o el túnel nunca se establece, y el par HA presenta una IP compartida al par.

Resumen

El núcleo de FinCorp es ahora un VDC que realiza la arquitectura en capas desde la Unidad 1.2: un ALB de capa 7 público que termina TLS en el borde, un nivel de aplicación de Dedicated Core sin estado, un NLB de capa 4 privado y un nivel de datos privado de un PostgreSQL Cluster estrictamente sincrónico frontado por una caché In-Memory DB, con un Managed Kubernetes Cluster y las puertas de enlace híbridas VPN y NAT conectadas. La lección de la piedra angular no es ningún valor de campo individual; esos se establecieron en las construcciones por módulo. Es que un entorno integrado es un grafo de dependencias, y que construir de abajo hacia arriba (IPs, luego LANs, luego cómputo, luego datos, luego equilibradores de carga, luego contenedores, luego el borde híbrido) es lo que convierte un conjunto de construcciones individuales correctas en una arquitectura de producción coherente y conforme.

Puntos clave:

• El orden de construcción es un grafo de dependencias: reserve las IPs públicas primero, cree LANs antes de que algo se conecte, proporcione objetivos antes del equilibrador de carga que los sirve, y redirija la ruta predeterminada antes de esperar la salida de NAT.
• El nivel de datos nunca toca una LAN pública; la segmentación, no un NSG, es lo que protege los equilibradores de carga gestionados y la base de datos, porque los equilibradores de carga gestionados no tienen NSG.
• El PostgreSQL Cluster no tiene réplica de lectura; la caché In-Memory DB es la sustitución de escalado de lectura y el estado externalizado que permite que el nivel de aplicación se escale y falle de manera segura.
• El servicio LoadBalancer de Kubernetes Cluster es un Node estático único, no el punto de entrada de producción; el ALB público más un controlador de entrada en Cluster es la verdadera puerta de entrada de capa 7, y un plano de control de Frankfurt mantiene los datos del plano de control en Alemania.
• La piedra angular hace referencia a cada unidad por módulo en lugar de repetirla: los laboratorios delgados por módulo existen para que este laboratorio de integración pueda llevar a cabo la síntesis.

Lectura adicional

• Unidad 8.2: La Arquitectura Empresarial de Referencia (el diseño que se implementa en este laboratorio)
• Unidad 3.1, 3.3, 3.4, 3.6: las construcciones de redes y equilibrio de carga que se combinan aquí
• Unidad 5.3, 5.5: la base de datos relacional Cluster y la caché en el nivel de datos privado
• Unidad 6.2: la construcción de Managed Kubernetes Cluster en el nivel público
• Unidad 7.1: cableado de resistencia y conmutación por error en este núcleo