Este es el segundo blog de una serie de 2-blog sobre la escalabilidad de la plataforma DCHQ usando la armadura como la capa de red subyacente. El primer blog cubre el despliegue de 10.000 contenedores en 10 Armadura de clústeres, cada uno con 3 Servidores Cloud en Rackspace con 4 GB de memoria y 2 CPU.
En este blog, vamos a cubrir el despliegue de 2.000 contenedores -, pero en lugar de utilizar 10 grupos con 3 servidores de la nube cada uno, vamos a utilizar un solo grupo de la armadura con 30 servidores de la nube . DCHQ no sólo automatiza el despliegue y gestión de aplicaciones, sino que también automatiza el aprovisionamiento de la infraestructura y se auto-escala en 13 diferentes nubes y las plataformas de virtualización. Lea más sobre esta prueba de escalabilidad en este blog.
Fondo
Mientras portabilidad de la aplicación (es decir, ser capaz de ejecutar la misma aplicación en cualquier sistema Linux) sigue siendo la principal fuerza motriz para la adopción de Contenedores de Linux, otras ventajas clave es ser capaz de optimizar la utilización de los servidores para que pueda utilizar todos los bits de cómputo. Por supuesto, para los entornos de aguas arriba, como PROD, es posible que quiera dedicar más que suficiente CPU y memoria para su carga de trabajo - pero en entornos / PRUEBA DEV, que generalmente representan la mayor parte del consumo de recursos de cómputo en una organización, optimizando la utilización del servidor CAN conducir a importantes ahorros de costes.
Todo esto suena bien en papel - pero DevOps ingenieros y operadores de infraestructuras siguen luchando con las siguientes preguntas:
- ¿Cómo puedo servidores de grupos a través de diferentes nubes en conglomerados que se asignan a los grupos empresariales, los equipos de desarrollo, o proyectos de aplicación?
- ¿Cómo se supervisan estos grupos y conseguir la penetración en el consumo de recursos por diferentes grupos o usuarios?
- ¿Cómo puedo configurar la red a través de servidores de un clúster de modo que los contenedores a través de múltiples hosts pueden comunicarse entre sí?
- ¿Cómo defino mi propia política de colocación basadas en la capacidad para que pueda utilizar todos los bits de cómputo en un clúster?
- ¿Cómo se puede escalar automáticamente el clúster para satisfacer las demandas de los desarrolladores para nuevas implementaciones de aplicaciones basadas en contenedor?
DCHQ, disponible en alojada y en las instalaciones de versiones, se dirige a todos estos retos y proporciona las políticas más avanzadas de suministro de infraestructuras, se auto-escala, de agrupamiento y colocación de los operadores de infraestructuras o ingenieros DevOps.
- Un usuario puede registrar cualquier host Linux corriendo en cualquier lugar mediante la ejecución de un script generado automáticamente para instalar el agente DCHQ, junto con acoplable y la capa de red definida por software (opcional). Esta tarea puede ser automatizado mediante programación utilizando nuestro descanso de la API para la creación de "Servidores" Docker ( https://dchq.readme.io/docs/dockerservers )
- Alternativamente, DCHQ se integra con 13 proveedores de la nube, permitiendo a los usuarios ponen en funcionamiento automáticamente la infraestructura virtual en vSphere, OpenStack, CloudStack, Amazon Elastic Cloud Computing, Google Compute Engine, Rackspace, digitalocean, SoftLayer, Microsoft Azure, y muchos otros.
La construcción de la plantilla de aplicación para el clúster Nginx
Después de registrarse en DCHQ (ya sea el DCHQ.io instalado o la versión on-premise), un usuario puede navegar a App & Machine y luego haga clic en el + botón para crear un nuevo acoplable Componer plantilla.
Hemos creado un clúster Nginx sencilla por el bien de esta prueba escalabilidad. Usted notará que el CLUSTER_SIZE parámetro le permite especificar el número de contenedores para poner en marcha (con las mismas dependencias de la aplicación).
El mem_min parámetro le permite specifcy la cantidad mínima de memoria que desea asignar al contenedor.
El anfitrión parámetro le permite especificar el host que desea utilizar para las implementaciones de contenedores. De esta manera se puede garantizar una alta disponibilidad para sus clústeres de servidores de aplicaciones a través de los diferentes huéspedes (o regiones) y se puede cumplir con las reglas de afinidad para asegurar que la base de datos se ejecuta en un equipo diferente, por ejemplo. Éstos son los valores admitidos para el parámetro host:
- host1, host2, host3 , etc. - selecciona un host al azar dentro de un centro de datos (o clúster) para implementaciones de contenedores
- <Dirección IP 1, dirección IP 2, etc.> - permite a un usuario especificar el actual direcciones IP a usar para implementaciones de contenedores
- <Nombre de host 1, 2 Nombre de host, etc.> - permite a un usuario especificar los nombres de host reales de usar para los despliegues de contenedores
- Los comodines (por ejemplo, "db- *", o "app-SRV-*") - para especificar los caracteres comodín para utilizar dentro de un nombre de host
El aprovisionamiento de la infraestructura subyacente En Cualquier Nube
Una vez que se guarda una aplicación, un usuario puede registrar un proveedor de nube para automatizar el aprovisionamiento y la auto-escala de los racimos en 13 diferentes nube de puntos finales, incluyendo vSphere, OpenStack, CloudStack, Servicios Web de Amazon, Rackspace, Microsoft Azure, digitalocean, HP Pública nube, IBM SoftLayer, Google Compute Engine, y muchos otros.
En primer lugar, un usuario puede registrar un proveedor de nube de Rackspace (por ejemplo) navegando a proveedores de la nube y luego hacer clic en el botón + para seleccionar Rackspace. La clave de API de Rackspace debe ser proporcionada - que puede ser recuperada de la sección Configuración de la cuenta.
Un usuario puede crear un clúster con una política de auto-escala para girar automáticamente los nuevos servidores de la nube. Esto puede hacerse navegando a Clusters página y luego hacer clic en el + botón. Puede seleccionar una política de colocación basadas en la capacidad y luego Tejer como la capa de red con el fin de facilitar la comunicación-contenedor cruz protegido por contraseña segura a través de múltiples hosts dentro de un grupo. En este caso, también definimos una política de auto-escala que hará girar hasta servidores de la nube en este grupo hasta el límite máximo definido (en este caso 30 servidores de la nube). Derechos granulares están disponibles para asegurarse de que este grupo sólo puede ser utilizado por los 10 usuarios que estamos utilizando en esta prueba (user1@dchq.io, user2@dchq.io, ..., user10@dchq.io). Por último, los derechos pueden ser definidos a nivel de anteproyecto (o plantilla de aplicación) - para garantizar que sólo las aplicaciones se pueden implementar con derecho a este clúster compartido. En este caso, el grupo estaba abierto a "Todos los Planos".
Un usuario puede ahora suministrar un número de Servidores Cloud en el clúster recién creado ya sea a través del flujo de trabajo basado en la interfaz de usuario o mediante la definición de una plantilla de máquina de composición basada en YAML simple que puede ser solicitada a la Biblioteca de autoservicio.
Flujo de trabajo basado en la interfaz de usuario - Un usuario puede solicitar servidores de la nube de Rackspace navegando a Máquinas y luego hacer clic en el + botón para seleccionar Rackspace . Una vez seleccionado el proveedor de la nube, un usuario puede seleccionar la región, el tamaño y la imagen sea necesario. Los puertos se abren de forma predeterminada en los servidores de la nube de Rackspace para dar cabida a algunos de los requisitos de puerto (por ejemplo, 32000-59000 para Docker, 6783 para la armadura, y 5672 para RabbitMQ). Un racimo Luego se activa y el número de Servidores Cloud se puede especificar.
Plantilla Componer máquina basada en YAML - Un primer usuario puede crear una plantilla de máquina de componer para Rackspace navegando a Máquinas y luego seleccionar la máquina de composición .
Los parámetros admitidos para la plantilla de la máquina de composición se resumen a continuación:
- Descripción : Descripción del modelo / plantilla
- instanceType : Nube proveedor de valor específico (por ejemplo general1-4)
- región : Nube proveedor de valor específico (por ejemplo IAD)
- Imagen : Obligatorio - completo la imagen ID / nombre (por ejemplo IAD / 5ed162cc-b4eb-4371-b24a-a0ae73376c73 o vSphere VM Template nombre)
- nombre de usuario : Opcional - sólo para vSphere VM Template nombre de usuario
- contraseña : Opcional - sólo para vSphere VM Template contraseña cifrada. Puede cifrar la contraseña utilizando el punto final https://www.dchq.io/#/encrypt
- la red : Opcional - Nube proveedor de valor específico (por ejemplo, por defecto)
- SecurityGroup : Nube proveedor de valor específico (por ejemplo DCHQ-seguridad-grupo)
- KEYPAIR : Nube proveedor de valor específico (por ejemplo, clave privada)
- OpenPorts : Opcional - valores de los puertos separados por comas
- cuentan : Nº total de VM, por defecto es 1.
Una vez que se guarda la plantilla de la máquina de composición, un usuario puede solicitar esta máquina desde el autoservicio Biblioteca . Un usuario puede hacer clic en Personalizar y, a continuación, seleccione el proveedor de la nube y el clúster de usar para el aprovisionamiento de estos servidores de Rackspace Cloud.
El Cluster despliegue de Nginx programación utilizando la API REST de la DCHQ
Una vez que los Servidores Cloud se aprovisionan, un usuario puede desplegar el clúster mediante programación con Nginx de DCHQ REST API. Para simplificar el uso de las API, un usuario tendrá que seleccionar el clúster creado anteriormente como el clúster predeterminado. Esto puede hacerse navegando a mi perfil , y luego seleccionando el clúster predeterminado sea necesario.
Una vez seleccionado el clúster predeterminado, a continuación, el usuario sólo puede ejecutar la siguiente secuencia de comandos rizo que invoca la API "desplegar" ( https://dchq.readme.io/docs/deployid ).
En este sencillo script de rizo, tenemos los siguientes:
- Un bucle, 1-20
- Con cada iteración estamos despliegue de la aplicación Nginx agrupado utilizando el clúster predeterminado asignado a user1@dchq.io~~V
- usuario1% 40dchq.io se utiliza para user1@dchq.io donde símbolo @ se sustituye por hexadecimal% 40
- @ Entre la contraseña y de acogida no se sustituye por hex
- <id> se refiere al ID de aplicación de clúster Nginx. Esto puede ser recuperada mediante la navegación a la Biblioteca > Personalizar para el clúster Nginx. El número de identificación debe estar en el URL
- sueño 22 se utiliza entre cada iteración
- Después de ejecutar esta secuencia de comandos, 200 contenedores Nginx se habrían desplegado por user1@dchq.io - 20 iteraciones el despliegue de un clúster de Nginx de 10 contenedores cada uno.
a continuación, se repitió el mismo proceso para los otros usuarios (user2@dchq.io, user3@dchq.io, ..., user10@dchq.io~~number=plural) - todos los que despliegan en el mismo clúster compartido.
Usted puede probar este script rizo mismo. Puede instalar DCHQ On-Premise ( http://dchq.co/dchq-on-premise.html ) o inscribirse en DCHQ.io Alojado PaaS ( http://dchq.io ).
El monitoreo de la CPU, memoria e I O Utilización / de la agrupación, servidores y contenedores Operando
DCHQ permite a los usuarios monitorear la CPU, memoria, disco y E / S de los clusters, anfitriones y contenedores.
- Para supervisar los clústeres, sólo puede desplazarse a Clusters
- Para supervisar los ejércitos, sólo puede desplazarse a las máquinas
- Para supervisar los contenedores, sólo puede desplazarse a vivir Aplicaciones
Tenemos un seguimiento de la actuación de los anfitriones y el grupo antes y después lanzamos los 2.000 contenedores.
Después de girar hasta 2.000 contenedores, hemos capturado imágenes de las cartas de funcionamiento de la agrupación. Se puede ver que la utilización de la memoria con agregación en los 30 servidores de la nube en el cluster estaba en 81% .
Se puede ver que la utilización de la memoria más alta en los 30 servidores de la nube en el cluster estaba en 84% .
Cuando hemos perforado hacia abajo en uno de los 30 hosts del clúster y vimos más detalles como el # de los contenedores que se ejecutan en ese servidor en particular, el número de imágenes sacó y, por supuesto, la CPU / memoria de Utilización / disco. En este caso, la utilización de la memoria de ese ordenador particular fue del 83% .
Aquí está una vista de todos los grupos que ejecutan 200 Nginx (donde cada grupo tenía 10 contenedores).
Conclusión
Al compás de la implementación de aplicaciones basadas en acoplable sigue siendo un desafío para muchos DevOps ingenieros y operadores de infraestructuras, ya que a menudo tienen dificultades para gestionar grupos de servidores a través de múltiples equipos de desarrollo, donde los controles de acceso, monitoreo de redes, de colocación basadas en la capacidad, auto-escalan a cabo políticas y cuotas son aspectos clave que deben ser configurados.
DCHQ, disponible en alojada y en las instalaciones de versiones, se dirige a todos estos retos y proporciona las políticas más avanzadas de suministro de infraestructuras, se auto-escala, de agrupamiento y colocación de los operadores de infraestructuras o ingenieros DevOps.
Además de las capacidades de aprovisionamiento y agrupamiento de infraestructura avanzada, DCHQ simplifica la contenerización de las aplicaciones empresariales a través de un marco de composición solicitud previa que se extiende acoplable Componer con fijaciones variable de entorno en imágenes cruz, extensibles escritura del golpe plug-ins que se pueden invocar en el momento de la solicitud o después de la prestación, y la agrupación de aplicaciones de alta disponibilidad a través de múltiples hosts o regiones con soporte para escalado automático.
para obtener acceso a las plantillas de aplicaciones Java de varias filas fuera de la caja junto con la funcionalidad de gestión del ciclo de vida de aplicaciones como monitoreo, actualizaciones de contenedores, en escala / entrega y continua.
No comments:
Post a Comment