Modelos de Servicios Compartidos de Fujitsu K5
2016-12-01
Machine-translated — the English original is authoritative.
En la plataforma IaaS de Fujitsu K5 existen muchas formas diferentes de implementar una arquitectura de servicios compartidos de tecnología, dependiendo de sus requisitos.
[Actualización: 09/03/2017]: Sin embargo, antes de continuar, permítame explicar rápidamente a qué me refiero con los siguientes dos términos: Plano de Control y Plano de Datos en el contexto de OpenStack y la plataforma IaaS K5 de Fujitsu. Imaginemos que le han pedido construir un nuevo servicio de Exchange para una empresa en K5. Este servicio requerirá los siguientes componentes de infraestructura: una red, un enrutador, un cortafuegos y un servidor para alojar la aplicación.
Plano de Control, utilizado por los Administradores de Infraestructura de K5: Para construir esta infraestructura necesitará acceso a los servicios del plano de control de K5: los puntos finales de la API que pueden comunicarse con los servicios Keystone, Neutron y Nova. No es necesario que los usuarios regulares del servicio final de Exchange accedan a este plano de control.
Plano de Datos, utilizado por los usuarios finales del servicio: Una vez que se ha construido la infraestructura, el administrador de Exchange y los usuarios finales accederán al nuevo servidor/servicios a través del plano de datos; efectivamente, se comunicarán directamente con el nuevo servidor a través de su interfaz virtualizada.
Modelo de Servicios Compartidos K5 – Sin Aislamiento de Usuarios del Plano de Control
El diseño más sencillo sería colocar todas sus instancias en un único proyecto y utilizar grupos de seguridad y, opcionalmente, múltiples subredes, para proporcionar aislamiento en el plano de datos o, más correctamente, segmentación de tráfico. Obviamente, también puede seguir utilizando los mecanismos estándar de autenticación del Sistema Operativo para controlar el acceso a las propias instancias virtuales.
Grupos de Seguridad
Uno de los componentes clave de la solución anterior son los Grupos de Seguridad. Un grupo de seguridad en OpenStack es un mecanismo para controlar todos los flujos de tráfico de entrada y salida en una interfaz (puerto) por interfaz (puerto). Un grupo de seguridad puede contener múltiples reglas, cada una definiendo el rango de direcciones IP, los Protocolos y la Dirección del tráfico de red permitido. En un modelo de servicios compartidos donde el servidor A y el servidor B deben estar aislados pero ambos pueden comunicarse con un tercer servidor C, los grupos de seguridad proporcionan este aislamiento. También se pueden adjuntar múltiples grupos de seguridad a una única interfaz para construir el conjunto de reglas.
Sin embargo, la desventaja de este modelo es que el administrador del proyecto del plano de control tiene acceso a todos los recursos.
Modelo de Servicios Compartidos K5 – Con Aislamiento de Usuarios tanto del Plano de Datos como del Plano de Control
Si desea garantizar el aislamiento tanto en las capas del plano de control como del plano de datos para sus recursos, esto se puede lograr utilizando la arquitectura anterior combinada con control de acceso basado en roles, múltiples proyectos y otra capacidad de Fujitsu K5: Enrutamiento Inter-Proyecto.
Control de Acceso Basado en Roles (RBAC)
La plataforma Fujitsu K5 aprovecha el proyecto Keystone de OpenStack para proporcionar Control de Acceso Basado en Roles para los usuarios dentro de un Contrato (o Dominio en términos nativos de OpenStack). Puede tener administradores del plano de control definidos de proyecto en proyecto. Esto le da la capacidad de distribuir sus recursos (máquinas virtuales, redes, etc.) entre múltiples Proyectos y definir qué usuarios tienen acceso administrativo a estos recursos en el plano de control.
Enrutamiento Inter-Proyecto
La pista está en el título: esta característica de K5 le permite enrutar entre redes en diferentes proyectos dentro del mismo Contrato.
Combinando todas estas capacidades de K5, podemos proporcionar a los Administradores de Dominio de K5 la capacidad de controlar el aislamiento de los recursos tanto en la capa del plano de control como en la capa del plano de datos.
Por ejemplo, con el siguiente modelo podemos definir un usuario que pueda administrar los recursos IaaS en el Proyecto A y un usuario diferente que pueda administrar recursos en el Proyecto B. Ninguno de estos administradores requiere acceso directo a los recursos en los Proyectos del otro ni al Proyecto de Servicios Compartidos. Sin embargo, ambos podrán enrutar hacia los servicios disponibles en el Proyecto de Servicios Compartidos, siempre que se hayan aplicado las Reglas Correctas de Grupos de Seguridad.
Los dos modelos anteriores están contenidos dentro de una única zona de disponibilidad de K5, pero estos modelos también se pueden distribuir fácilmente entre las dos zonas de disponibilidad utilizando otro componente de K5 llamado Conector de Red.
Conector de Red K5
El Conector de Red tiene dos casos de uso fundamentales:
- Enrutar el tráfico de red desde redes externas de clientes directamente hacia un proyecto de K5.
- Enrutar el tráfico de red entre redes en diferentes Zonas de Disponibilidad dentro del mismo proyecto.
Este conector evita la necesidad de que el tráfico de la red del cliente atraviese la conexión a Internet al cruzar Zonas de Disponibilidad.
El siguiente ejemplo de Pila LAMP ilustra el uso de un Conector de Red con dos Zonas de Disponibilidad.
¡Feliz Apilamiento!
Originally published on allthingscloud.eu (2016-12-01).