En este artículo, Igor Kotenko, arquitecto jefe de Neoflex, comparte su experiencia en la implementación de una plataforma de contenedorización en una infraestructura empresarial.
Las razones por las que las empresas suelen optar por una solución local no suelen ser tecnológicas y suelen estar relacionadas con la financiación. Alguien está tratando de reducir los costos operativos (pagando por nubes externas) a favor de capitalizar la empresa (comprando sus propios servidores), alguien ya tiene recursos de hardware sólidos y quiere usarlos en una arquitectura de microservicio.
Antes de pasar a los detalles de implementación, pasemos a los términos.
El término "nubes" se considera muy congestionado. Es habitual distinguir entre diferentes tipos de soluciones en la nube:
- Infraestructura como servicio (IAAS): hardware (generalmente virtual);
- Software como servicio (SAAS), por ejemplo, DBAS - base de datos como servicio;
- Plataforma como servicio (PAAS);
- Aplicación como servicio (AAAS).
Al mismo tiempo, nada impide que las capas se basen entre sí. Obviamente, habrá infraestructura debajo de la plataforma o software.
Existe cierta confusión sobre el término "nubes privadas". A veces, esto se denomina nubes en las instalaciones, a veces se implementan en una infraestructura alquilada con aislamiento completo de su segmento de red. Incluso se mencionó máquinas virtuales con memoria y discos encriptados, mientras que un volcado de memoria no le dará al proveedor acceso a su información. En este artículo, analizaremos las soluciones implementadas internamente, en las instalaciones.
Al introducir nubes privadas, se espera que sean iguales a las nubes públicas, solo que más baratas, más seguras y más confiables. Por tanto, mucha gente piensa que las nubes privadas son a priori mejores. A menudo, los expertos simplemente implementan la versión elegida de Kubernetes u Openshift y creen que aquí es donde se completa su trabajo.
Lo que las empresas esperan obtener al implementar nubes locales:
- Bajo costo de recursos. Porque solo paga por lo que usa.
- La capacidad de agregar y devolver recursos lo más rápido posible.
- Tolerancia a fallos. El servidor se bloqueó, se dio otro automáticamente en su lugar.
- Coste de mantenimiento reducido.
¿Cómo se logra esto en las nubes públicas?
Como regla general, debido a la automatización de los procesos, las economías de escala (más baratas a granel) y el intercambio de recursos entre diferentes consumidores.
Veamos estas promesas en el contexto de las nubes privadas.
1. Bajo costo de recursos en comparación con la infraestructura convencional.
De hecho, no es así. El mismo software se implementó en las mismas máquinas, pero en contenedores. En nuestra experiencia, por el contrario, se desperdician más recursos.
2. Capacidad para aumentar y disminuir recursos extremadamente rápido.
No. Para expandirse, debe mantener inactiva la reserva de licencias de hardware y software o, primero, desechar algo innecesario. Puede dejar de utilizar recursos, pero luego estarán inactivos.
3. Tolerancia a fallos.
Sí, pero hay muchos matices. Digamos que el servidor no funciona. ¿Dónde puedo conseguir otro? ¿Cómo implementarlo rápidamente y agregarlo a un clúster? Si no eres Amazon, entonces no tienes un suministro infinito de recursos.
4. Bajo costo de soporte.
Hemos agregado al menos una capa más (plataforma de contenedorización), varios sistemas nuevos. Necesitamos especialistas con nuevas competencias. ¿De dónde vendrán los ahorros?
Examinemos estas preguntas con más detalle. Es importante recordar que las nubes privadas deben coexistir con los sistemas heredados existentes. Las organizaciones se ven obligadas a mantener la infraestructura de los sistemas existentes en paralelo, organizando un entorno de TI híbrido.
Naturalmente, el 99% del sistema no se construye desde cero. Por lo general, incluso antes de la implementación de una solución PAAS, existe un conjunto de procesos y automatización para respaldar la infraestructura anterior. Procesos de DevOps, planificación y propiedad de recursos, monitoreo, actualizaciones de software, seguridad: todos estos problemas deben coordinarse y cambiarse durante la implementación de una nube privada.
Cómo están cambiando los procesos de DevOps
Por lo general, antes de implementar su propio PAAS, el enfoque para construir DevOps se basa en el uso de sistemas de automatización de configuración como Ansible o Chef. Le permiten automatizar casi todos los procesos de TI rutinarios, a menudo utilizando bibliotecas de scripts listas para usar. Sin embargo, las plataformas de contenedorización están promoviendo un enfoque alternativo: la “infraestructura inmutable”. Su esencia no es cambiar el sistema existente, sino tomar una imagen virtual prefabricada del sistema con nuevas configuraciones y reemplazar la imagen anterior por una nueva. El nuevo enfoque no niega el anterior, sino que fuerza la automatización de la configuración a la capa de infraestructura. Por supuesto, los sistemas heredados requieren mantener el enfoque anterior.
Hablemos de la capa de infraestructura
El estándar de facto en TI es el uso de infraestructura virtual. Como muestra la práctica, la opción más común es usar vSphere. Hay muchas razones para esto, pero también hay consecuencias. En nuestra práctica, los problemas frecuentes de sobresuscripción en términos de recursos (intento de coser siete gorras de una sola piel) se vieron agravados por la casi total falta de control e influencia en este proceso por parte de los responsables del desempeño de la solución. La delimitación de áreas de responsabilidad en las divisiones de la empresa, la formalización de los procedimientos de solicitud de recursos y los diferentes objetivos de la gestión de divisiones, generaron problemas en el entorno del producto y pruebas de carga inconsistentes. En algún momento, nuestro departamento de desarrollo incluso creó una herramienta de medición de rendimiento de núcleo virtual,para diagnosticar rápidamente la falta de recursos de hardware.
Es obvio que un intento de colocar una plataforma de contenedorización en dicha infraestructura traerá nuevos colores al caos existente.
La cuestión de si una plataforma de contenedorización en las instalaciones necesita una infraestructura virtual o es mejor ponerla completa (en servidores de hierro) se ha debatido durante mucho tiempo y de manera bastante amplia. Los artículos presionados por los fabricantes de sistemas de virtualización sostienen que prácticamente no hay pérdidas de rendimiento y que los beneficios son demasiado grandes. Por otro lado, hay resultados de pruebas independientes que indican pérdidas de rendimiento de aproximadamente un 10%. No se olvide del costo de las licencias de vSphere. Por ejemplo, ¿instalar una versión gratuita de Kubernetes en hardware económico solo para ahorrar dinero y pagar vSphere? Decisión controvertida.
Vale la pena mencionar una solución de virtualización de infraestructura de código abierto, por ejemplo, Open Stack. En general, se lo veía como una solución que requería una gran inversión en el equipo. Hay estadísticas en la red según las cuales el tamaño del equipo de soporte de Open Stack es de 20 a 60 personas. ¡Y eso es independiente del soporte de la plataforma de contenedorización! Hay pocos especialistas de este tipo en el mercado, lo que aumenta su costo. Por lo general, estas inversiones solo se amortizan con grandes volúmenes de recursos.
Es importante considerar la presencia de especialistas con competencias únicas en la empresa. Desafortunadamente, las instalaciones completas de Kubernetes, a pesar de los beneficios de la transparencia y los menores costos de licencia, a menudo se ven obstaculizadas, por ejemplo, por la falta de herramientas de automatización de instalación adecuadas. Esperamos que el futuro pertenezca a este enfoque.
Otro aspecto que influye en la elección entre instalaciones virtuales y bare-metal es la organización de servidores de hierro.
Por lo general, una organización compra servidores para fines específicos. Puede alquilar servidores en el centro de datos (de lo que ofrecen), puede estandarizar y unificar la nomenclatura (simplificando la redundancia de componentes), puede ahorrar en hardware (muchos servidores económicos), puede ahorrar espacio en el rack. Diferentes enfoques en diferentes organizaciones. En general, se trata de servidores potentes con una gran cantidad de núcleos y memoria, o de volumen relativamente pequeño, o una mezcolanza prefabricada. Pero no se olvide de las necesidades de los sistemas heredados. En este punto, nuevamente nos encontramos con una contradicción de conceptos. La ideología de Kubernetes es una gran cantidad de hardware económico y está preparado para sus fallas. El servidor cayó, no importa, sus servicios se han trasladado a otro. Los datos están fragmentados (duplicados), no vinculados a un contenedor. Ideología heredada: redundancia a nivel de hardware. Matrices RAID,Racks de discos, múltiples fuentes de alimentación en el servidor, intercambio en caliente. Céntrese en la máxima fiabilidad. Puede resultar excesivamente caro apostar por dicha infraestructura de Kubernetes.
, …
Si una empresa tiene servidores de alto rendimiento con muchos núcleos a bordo, puede ser necesario dividirlos entre diferentes consumidores. Aquí no podrá prescindir de un sistema de virtualización. Al mismo tiempo, es necesario tener en cuenta la posibilidad de que el servidor falle o se detenga por mantenimiento. La aritmética es simple: si tiene dos servidores, si uno falla, necesita un 50% de reserva de energía en cada uno; si - 4 servidores, si uno falla, necesita un 25% de reserva. A primera vista, todo es simple: necesita una cantidad infinita de servidores, luego la falla de uno de ellos no afectará la capacidad total y no necesita reservar nada. Por desgracia, el tamaño de los recursos de un host no se puede reducir en gran medida. Como mínimo, debería acomodar todos los componentes relacionados, que la terminología de Kubernetes llama "pods". Y, por supuesto, cuando se procesa en servidores más pequeños,Los costos generales de los servicios de la propia plataforma están aumentando.
Para fines prácticos, es deseable unificar los parámetros de host para la plataforma. En ejemplos cercanos a la vida, hay 2 centros de datos (el soporte para el escenario DR significa al menos un 50% de reserva de recursos en términos de capacidad). A continuación, se determinan las necesidades de la organización para los recursos de la plataforma de contenedorización y la posibilidad de colocarla en hosts virtuales o bare-metal estándar. Recomendación de Kubernetes: no más de 110 pods por nodo.
Por lo tanto, para determinar el tamaño del nodo, debe considerar lo siguiente:
- Es deseable igualar los nodos;
- Los nodos deben caber en su hardware (para máquinas virtuales, múltiples, N virtual para una pieza de hardware);
- Si un nodo falla (para la versión con infraestructura virtual - un servidor de hierro), debe tener suficientes recursos en los nodos restantes para mover los pods a ellos;
- No puede haber demasiados (> 110) pods en un nodo;
- En igualdad de condiciones, es deseable agrandar los nodos.
Este tipo de características deben considerarse en todos los aspectos de la arquitectura.
Registro centralizado: ¿cómo elegir entre varias opciones?
Monitoreo: ¿tal vez su sistema de monitoreo existente no funcione, mantenga dos o migre a uno nuevo?
La plataforma se actualiza a una nueva versión, ¿con regularidad o solo cuando es absolutamente necesario?
Equilibrio tolerante a fallas entre dos centros de datos: ¿cómo?
Arquitectura de seguridad, interacción con sistemas heredados: existen diferencias con las nubes públicas. Es posible recomendar la construcción de sistemas para que exista la posibilidad de migración a nubes públicas, pero esto complicará la solución.
La planificación, asignación y propiedad de los recursos para las nubes públicas y privadas difieren poco. La principal diferencia es la cantidad limitada de recursos. Si en las nubes públicas es posible en cualquier momento tomar los recursos adicionales necesarios, por ejemplo, para las pruebas de carga, las instalaciones deben planificar cuidadosamente la secuencia de su uso. Esto significa que es posible que tenga lanzamientos nocturnos y, en consecuencia, el trabajo de los empleados de las líneas 2 y 3 aumentará en horas inoportunas. Nada nuevo para los que están solos, sino un sabor amargo de decepción por los milagros que esperan la adopción de la nube privada.
"Los cuadros lo deciden todo"
Al planificar la implementación de una plataforma de contenedorización local, en primer lugar, se necesitan especialistas con competencias únicas. Claramente, no hay suficientes de ellos en el mercado laboral actual. Además, sin tener experiencia en dicha implementación, es difícil incluso hacer una lista de todos los especialistas necesarios.
Por ejemplo, para que la plataforma funcione, debe seleccionar e instalar un sistema de almacenamiento. Cualquiera que sea el sistema que elija (CEPH o Portworx), será fundamental para la plataforma. Todo el mundo sabe que se requiere un administrador para mantener una base de datos. Asimismo, un sistema de almacenamiento de datos necesita un especialista independiente. Desafortunadamente, ¡nadie piensa en esto antes de implementar el sistema! Tenga en cuenta que la diferencia entre administradores para diferentes productos es significativa, comparable a la diferencia entre Oracle DBA y MS SQL DBA. Necesitará al menos dos personas para cada función: los empleados se van de vacaciones, se enferman e incluso, Dios no lo quiera, renuncian. Y así sucesivamente para cada competencia, y la lista de competencias necesarias para respaldar la solución es impresionante.
Me gustaría advertir de inmediato contra los intentos de cruzar todas las competencias en algunos soldados universales. Su costo, rareza y riesgos de pérdida exceden todos los límites razonables.
Nuevamente, el mantenimiento de la nube es un proceso complejo. Las empresas de la nube no se comen el pan por nada: allí, detrás de la neblina, hay mucha tecnología y mano de obra invertida.
Por supuesto, el uso de servicios de consultoría puede acelerar significativamente la implementación de la plataforma. Los socios experimentados lo ayudarán a evitar muchos errores, establecer procesos y capacitar a su equipo. Sin embargo, si aloja servicios críticos para su negocio en la plataforma, es igualmente importante brindar soporte y desarrollo de calidad. Además, en este momento, todos los sistemas existentes en el mercado se están desarrollando activamente, aparecen nuevas tecnologías, las nuevas versiones de la plataforma pueden requerir la migración de procesos complejos y pruebas serias antes de la actualización. Se requiere un fuerte equipo de soporte para garantizar el funcionamiento confiable del sistema. Y necesitará un equipo de este tipo de forma continua.
¿Cuándo debería considerar implementar una plataforma de contenedorización local?
En primer lugar, es necesario evaluar la relación entre la inversión y el rendimiento, el volumen de costos para el hardware y los empleados. Debe haber buenas razones para no poder vivir en nubes públicas o requisitos de recursos realmente serios. Es decir, si alrededor de 100 núcleos son suficientes para una organización y no está listo para expandir el equipo de soporte a decenas de personas, lo más probable es que deba concentrarse en nubes públicas o en configuraciones simples con servidores de aplicaciones. Se requiere un tamaño mínimo de equipo para respaldar la plataforma y es posible que el costo no valga la pena. Sin embargo, con el escalado de recursos y la automatización competente de todos los procesos, el beneficio de una solución privada puede ser muy significativo. Se pueden mantener muchos cientos de nodos con prácticamente el mismo comando.
Otro criterio de selección es la variabilidad de las necesidades de recursos informáticos. Si los procesos comerciales de una empresa crean una carga de recursos más o menos uniforme, es más rentable desarrollar su propia infraestructura. Si necesita utilizar grandes capacidades, pero rara vez, considere las nubes públicas o híbridas.
En cualquier caso, al elegir soluciones locales, sintonícese con un trabajo serio y sistemático, prepárese para invertir en el equipo. Pasa de lo simple a lo complejo. Esté atento al momento de la implementación y tenga especial cuidado al actualizar a nuevas versiones de la plataforma. Utilice la experiencia obtenida de los errores de otros, no la suya.
Gracias por leer este artículo, esperamos que encuentre útil la información.