Dimensionamiento típico de Onesait Platform

Owned by Onesait Platform
Last updated: 08/09/22
4 min read

 

Introducción

El objetivo de esta entrada es mostrar unos dimensionamientos tipos de plataforma en función de diversos escenarios.

Estas recomendaciones deben validarse con el equipo de Producto sobre el escenario concreto de un proyecto.

 

Un objetivo fundacional de la plataforma es tener una estrategia “Zero Lock-in” con los proveedores, de modo que la plataforma pueda desplegarse en todas las Clouds y también On Premise.

Para cumplir con la estrategia la plataforma propone un despliegue basado en contenedores Docker y orquestada por Kubernetes, de modo que estos puedan desplegarse de forma independiente al proveedor, e integrar una plataforma CaaS que permite la gestión visual y sencilla de estos contenedores de forma independiente al proveedor (como CaaS usamos Rancher u OpenShift).

Adicionalmente la plataforma puede usar servicios SaaS concretos de algunos proveedores y desplegarse sobre un cluster Kubernetes existente (AKS pj), siempre gestionados desde el CaaS de plataforma ara conseguir la independencia de los proveedores.

Despliegue para Entornos de Desarrollo basado en VMS

Cuando desplegamos la plataforma sobre VMS en Entornos de desarrollo la propuesta de despliegue de plataforma es como esta: 

 

  • Entorno CaaS (Rancher):

    • Despliegue en Single-Instance (1 VM) ya que una indisponibilidad del CaaS no afecta a la operación.

    • Características de la VM:

      • 4 cores y 16 Gb RAM.

      • 512 GB HDD montado en /datadrive

      • ​Sistema de ficheros XFS.

      • SO Linux 64 bits: CentOS 7.X (now 7.8) / Rocky Linux 8.X (now 8.4) / RHEL >8.2 / Ubuntu 20.X (now 20.02)

    • Accesos:

      • Acceso por SSH con usuario con permiso sudo

      • Conectividad con VMs Plataforma: 8080/tcp, 500/udp, 4500/udp

  • Plataforma:

    • Despliegue contenerizado de todos los módulos incluida persistencia y balanceador.

    • Despliegue en 1 VM según necesidades del proyecto y módulos a desplegar:

      • Entorno básico: 1 VM con 4 cores y 16 Gb RAM y 256 Gb disco XFS.

      • Entorno típico: 1 VM con 8 cores y 32 Gb RAM y 512 Gb disco XFS.

      • Entorno alta carga: 1 VM con 16 cores y 64 Gbs RAM y 1 TB disco XFS.

    • Necesidades adicionales:

      • Acceso por SSH con usuario con permiso sudo

      • Conectividad con VMs CaaS: 8080/tcp, 500/udp, 4500/udp

      • Puerto accesible a la vnet: 443 (consola web de la Plataforma).

 

Despliegue para Entornos Productivos basado en VMs

En Entornos Productivos, la propuesta de despliegue de plataforma contempla:

 

  • Load-Balancer:          

    • Se puede usar Load-Balancer de Cloud elegida, Plataforma (NGINX) o balanceador HW.

  • Entorno CaaS (Rancher):

    • En función de la HA requerida, se puede montar en Single-Instance o en cluster (3 VMS).

    • VMs:

      • 4 cores y 16 Gb RAM.

      • 512 GB HDD montado en /datadrive

      • Sistema de ficheros XFS.

      • SO Linux 64 bits: CentOS 7.X (now 7.8) / Rocky Linux 8.X (now 8.4) / RHEL >8.2 / Ubuntu 20.X (now 20.02).

    • Necesidades adicionales:

      • Acceso por SSH con usuario con permiso sudo

      • Conectividad con VMS Plataforma: 8080/tcp, 500/udp, 4500/udp

  • Plataforma:

    • Despliegue contenerizado de los módulos de plataforma sin incluir persistencia.

    • Despliegue en al menos 3 VM según necesidades del proyecto y módulos a desplegar:

      • Entorno básico: 2 VM con 4 cores y 16 Gb RAM y 256 Gb RAM.

      • Entorno típico: 2/3 VM con 8 cores y 32 Gb RAM y 512 Gb disco.

      • Entorno alta carga: 3 VM con 16 cores y 64 Gbs RAM y 1 TB disco.

    • Necesidades especiales:

      • Acceso por SSH con usuario con permiso sudo

      • Conectividad con VMS CaaS: 8080/tcp, 500/udp, 4500/udp

      • Puerto accesible a la vnet: 443 (consola web de la Plataforma).

¿Cuándo montar el CaaS Rancher en Single-Instance?

Cuando se monta Rancher sin HA, o lo que es lo mismo el cluster de Kubernetes sin HA, el funcionamiento es el siguiente:

  • Los servicios desplegados en los Workers siguen funcionando aunque el Master de Kubernetes esté parado.

  • Los balanceadores web (ingress in nomenclatura kubernetes) que se crean en Kubernetes también siguen funcionando.

  • Lo que se pierde si se cae el Master de Kubernetes:

    • No se pueden hacer despliegues o cambios de configuración de los módulos desplegados.

    • Además, si se cae uno de los Workers no se levantarían los servicios automáticamente en otro de los workers, esto último, sólo afectaría a servicios no replicados y los servicios críticos van replicados.

    • Todo esto vuelve a estar operativo al levantarse de nuevo el Master Kubernetes.

Despliegue sobre Cluster Kubernetes (como Azure AKS o AWS EKS)

Cuando desplegamos sobre un Cluster Kubernetes como AKS o EKS, los módulos de Plataforma se despliegan como PODs por lo que puedes darles a cada uno su factor de replicación.

Fuentes