Despliegue Estratégico de Infraestructura Cloud Híbrida y Servicios de Red

Modelo de Despliegue: Nube Híbrida

Tras la virtualización de los equipos, el siguiente paso es migrar el centro de cálculo a un centro de datos en el edificio de Walqa. Este centro de datos se conectará a cada una de las sedes a través de una red MPLS, creando un modelo de nube que ofrezca servicios de TI de manera flexible y escalable. El modelo de despliegue propuesto, basado en la localización y administración de la infraestructura, es el de una Nube Híbrida.

Esta infraestructura en nube combina dos tipos de nubes (privada y pública) que, aunque permanecen como entidades independientes, se unen mediante tecnologías (estándares o propietarias) que facilitan la portabilidad de datos y aplicaciones.

Componentes de la Nube Híbrida

Nube Privada: De uso exclusivo para nuestra empresa, con múltiples consumidores (unidades de negocio). Será propiedad, administrada y operada por nuestro departamento de TI. Aquí se alojarán todos los sistemas existentes (p. ej., el/los servidor/es del ERP), excepto la herramienta de colaboración (servidor FTP). La evolución estratégica se plantea en tres fases:

Nuestro departamento de TI actuará como proveedor interno de servicios de TI para toda la organización.
Subcontratación de la administración y operación de la infraestructura a un tercero, permitiendo que nuestros recursos humanos se enfoquen en tareas más estratégicas y relacionadas con el negocio.
Migración de servicios a un proveedor de servicios cloud, combinando nube privada (IBM, Telefónica, etc.) con nube pública (AWS, Azure, Google Cloud, Alibaba Cloud, etc.).

Nube Pública: Infraestructura destinada al uso público general.

Se utilizarán los servicios de Nube Pública de Microsoft para consumir, en modalidad de servicio y pago por uso, la herramienta de colaboración O365. Esta incluye OneDrive para compartir archivos, además de numerosas aplicaciones de productividad y colaboración para los empleados.

Modelo de Entrega de Servicios

Para la Fase I, se identifican las siguientes demandas diferenciales:

IaaS (Infraestructura como Servicio): Nuestro departamento de TI se autoabastecerá de máquinas virtuales según sus necesidades para implementar nuevos servicios. Utilizarán la consola de VMware ESXi para crear VMs, configurando vCPU, vRAM, vHD y vNIC. Ellos se encargarán de la instalación del SO, Middleware, Runtime, datos y aplicaciones.
PaaS (Plataforma como Servicio): Este modelo se utilizará para proporcionar la plataforma del ERP como servicio al departamento financiero (propietario del ERP interno) y al resto de la organización. Incluye la administración y gestión del SO, Middleware y Runtime. El departamento financiero se encargará de la aplicación servidora y su parametrización. En la Fase 3, se migrará a un PaaS proporcionado por un proveedor de servicios cloud externo. Se realizará una migración a SAP para adoptar un modelo PaaS: SAPaaS, eliminando el pago de licencias y adoptando un modelo de consumo como servicio (pago por uso).
SaaS (Software como Servicio): Se contratará la herramienta de colaboración O365 como SaaS a Microsoft, con un modelo de coste por usuario/mes. Esto proporciona a la organización un modelo de costes flexible y predecible (p. ej., para una empresa de 1000 empleados con un coste de 6€/persona/mes por O365 y un crecimiento previsto del 5% en personal, el coste adicional anual sería de 50 x 12 x 6 = 3.600€).

Virtualización y Contenedores

Las máquinas virtuales (IaaS) se utilizarán para los servidores del centro de datos.
Se migrará de Windows XP a un sistema operativo más moderno, como Windows 10. Para garantizar la compatibilidad de la aplicación cliente del ERP, se virtualizará (“contenerizará”) la aplicación utilizando Dockers. Un Docker es una imagen de un sistema de ficheros que empaqueta una aplicación o sus componentes para ejecutarse en un sistema operativo compartido como un proceso.

El contenedor incluye no solo la aplicación, sino también los binarios y librerías del SO necesarios (en este caso, DLLs antiguas de Windows XP). Al estar aislado en el contenedor, no habrá incompatibilidades con las DLLs modernas de Windows 10.

Se ha optado por contenedores en lugar de máquinas virtuales porque:

El proceso de arranque de la aplicación es transparente para los usuarios.
Es una virtualización ligera, lo que permite un arranque más rápido de la aplicación (no es necesario levantar toda la VM con su SO).
No requiere hipervisor.
Las restricciones y el aislamiento de recursos son suficientes para las necesidades (portátiles de los empleados), ya que no está expuesto al exterior.

Cada proceso/grupo de procesos de la aplicación cliente ERP se asociará a un namespace, limitando su acceso a los recursos asociados a ese namespace. Las características clave son:

Abstrae la aplicación del SO subyacente mediante el Container Daemon, que contiene el motor para la ejecución de contenedores. Esto permite que múltiples aplicaciones compartan el SO y los recursos de cómputo.

Hipervisor

Se utilizará un hipervisor de tipo I (nativo, unhosted o bare metal) en los servidores que alojarán las máquinas virtuales. El hipervisor gestionará la distribución de recursos físicos (CPU, RAM, disco duro y red) entre las VMs. Este hipervisor, también conocido como Virtual Machine Manager (VMM), es la capa de software que controla el acceso al hardware, crea y ejecuta las VMs.

Se elige un hipervisor de tipo I (p. ej., VMware ESXi) porque:

Se ejecuta directamente sobre el hardware físico, sin necesidad de cargar un SO subyacente.
Ofrece el mejor rendimiento y eficiencia para servicios empresariales debido a su acceso directo al hardware.

Los hipervisores de tipo 2, al depender del SO subyacente, introducen latencia, ya que todas las actividades de las VMs deben pasar por el SO del host.

Ubicación de las VNFs (Funciones de Red Virtualizadas)

vLoadBalancer y vFirewalls: En los routers EDC (Edge Data Center) del cliente. Se implementa balanceo de carga para baja latencia y se refuerza la seguridad en el punto de entrada del cliente.
vAntiDOS: En los Ingress Routers de la red MPLS. Se evita redirigir tráfico malicioso a la nube, actuando antes de que llegue al router del cliente.
vAntiSpam y vAntiMalware: En la nube del proveedor de servicios de conectividad. Esto garantiza que todo el tráfico que circula por la red sea tráfico limpio.

Evolución de la Red: De RDSI a SDN y NFV

Migración desde RDSI: Se inicia la migración de la red desde líneas dedicadas con tecnología RDSI (costosa, lenta y con frecuentes fallos físicos) a una solución más moderna.
Contratación de Servicios de Conectividad: Se contratan servicios de conectividad a un proveedor. Cada router de salida de nuestra sede se conecta al router más cercano del proveedor, lo que nos conecta a la red MPLS, aprovechando sus ventajas en ingeniería de tráfico y enrutamiento dinámico. El proveedor es responsable del mantenimiento y operación de la conectividad entre nuestro router y el suyo.
Migración a SDN (Modelo Overlay): El proveedor de servicios migrará su red MPLS a tecnología SDN, comenzando por los routers frontera (los que se conectan con nuestros routers). Este es el modelo Overlay. Aprovechamos para migrar nuestros routers tradicionales a routers SDN, beneficiándonos de la flexibilidad que ofrece esta tecnología. El controlador SDN del proveedor solo controlará los routers de borde.
Migración Completa a SDN (Modelo Underlay) y NFV: Se migrarán todos los routers internos de la red MPLS a SDN. La capa de datos (data plane) residirá en estos dispositivos, mientras que la capa de control (control plane) estará en el controlador en la nube. Todos los dispositivos de la red serán SDN y estarán gestionados por el controlador. Este es el modelo Underlay. El operador de servicios de conectividad incorpora una arquitectura NFV a través de un MANO (Manager Orchestrator) conectado al controlador. Esto permite desplegar VNFs en la nube o en cualquier dispositivo de la red, incluyendo los routers de salida en cada una de nuestras sedes.