Patrón de diseño de servicio compartido de tecnología Fujitsu K5 – Alta disponibilidad
2017-01-13
Machine-translated — the English original is authoritative.
El siguiente patrón de diseño es un ejemplo de cómo se podría implementar una plataforma de servicios compartidos de tecnología en K5. La diferencia entre esta arquitectura y el blog anterior sobre servicios compartidos es que he incluido nuestros conectores de Inter-Zona de Disponibilidad para proporcionar un enlace interno de alta velocidad entre las subredes en las diferentes Zonas de Disponibilidad (AZ). Ahora es posible garantizar que sus aplicaciones tradicionales o aplicaciones nativas de la nube se puedan distribuir fácilmente entre las dos AZ. El tráfico de red no atraviesa Internet. Toda la arquitectura que se muestra a continuación se puede implementar automáticamente con un esfuerzo mínimo gracias a las pilas HEAT, el proyecto de Orquestación de Infraestructura de K5/OpenStack.
Nota para usuarios nativos de OpenStack : Tanto los enlaces InterProject como los enlaces InterAvailability Zone discutidos aquí son mejoras que Fujitsu ha realizado en la API de OpenStack Neutron para su uso en la nube pública.
DMZ
El proyecto DMZ se utiliza para enrutar el tráfico hacia y desde la solución. Se podría utilizar un servidor proxy para proporcionar/controlar el acceso a Internet a los otros proyectos. Se podría instalar un servidor terminal https como Guacamole en cada DMZ para proporcionar acceso redundante a las consolas de los servidores.
Se instalan dos enrutadores virtuales en cada AZ. Uno gestiona todo el enrutamiento interproyecto y el segundo se utiliza junto con FWaaS para controlar el acceso en el límite de Internet. Podría utilizarse aquí una instancia LBaaS opcional orientada al público para proporcionar HA para el servicio Guacamole.
Servicios compartidos
Este proyecto se utilizaría para alojar todos los servicios compartidos que desee proporcionar a sus otros proyectos, como correo electrónico (aunque no olvide que K5 también ofrece esto como una oferta PaaS), intercambio de archivos, repositorios git, etc. Se utiliza un conector de red para enlazar las subredes de servicios compartidos entre las zonas de disponibilidad, lo que facilita la sincronización rápida de datos entre servicios críticos. También se podría utilizar aquí un LBaaS orientado al interior si es necesario. Por diseño, estas subredes no tienen capacidad de DNAT ni de SNAT. Sería necesario aprovechar un servicio proxy en el DMZ (no parte de K5) para lograr esto. La alternativa sería enlazar esta subred directamente a Internet a través de otro enrutador virtual, rompiendo el modelo requerido 🙂
Departamento A/B/C…etc
Estos son los proyectos que consumirían los usuarios finales. Pueden tener las mismas características de HA expuestas a ellos que están en el proyecto de Servicios Compartidos. Este modelo permite un despliegue rápido y fácil, destrucción y reimplantación para satisfacer las demandas, manteniendo intactos los servicios centrales.
Los Grupos de Seguridad se utilizan a lo largo de todo el sistema para proporcionar también una capa adicional de seguridad de red para todos los hosts.
Resumen
El modelo completo de Servicios Compartidos se puede implementar rápida y consistentemente una y otra vez utilizando las Plantillas HEAT de Infraestructura como Código (IaC) de K5. Cada vez más clientes están aprovechando modelos como este para ayudarles en sus viajes de Integración Continua y Despliegue Continuo (CI/CD). Si esto le interesa, le recomiendo que también eche un vistazo a Cloud Foundry para el desarrollo rápido de aplicaciones: K5 también ofrece una plataforma Cloud Foundry.
Apilamiento feliz.
withk5youcan
Originally published on allthingscloud.eu (2017-01-13).