C贸mo migramos m谩s de 700 servidores a Salt
Durante mucho tiempo estuvimos satisfechos con una configuraci贸n compleja y engorrosa con 2 repositorios Git, donde parte de los datos se almacena en MySQL y la otra parte es Puppet 3.8. Pero nuestras necesidades crecieron gradualmente, la cantidad de servicios aument贸 y el rendimiento de la configuraci贸n disminuy贸. Luego nos propusimos la tarea de mejorar la configuraci贸n, optimizando todos los datos y herramientas disponibles.
Nuestro equipo ha seleccionado una configuraci贸n adecuada para ellos en 3 etapas. Compartimos nuestra experiencia de optimizaci贸n de Salt, c贸mo aplicar y personalizar sin esfuerzo extra.
Nota: En Habr茅 encontramos excelentes art铆culos de nuestros colegas, por lo que no nos detendremos en los temas ya cubiertos. Recomendamos encarecidamente leer:
Qu茅 tiene de bueno SaltStack y qu茅 tareas se pueden resolver con 茅l : un art铆culo deptsecurity, Tecnolog铆as Positivas.
Instalaci贸n, lanzamiento, primeros comandos y familiaridad con las funciones : art铆culo del autorzerghack007...
Salt es un sistema de gesti贸n de configuraci贸n y ejecuci贸n remota. Un marco de infraestructura de c贸digo abierto escrito en Python.
驴Por qu茅 Salt?
Salt, Ansible, Puppet y Chef son opciones decentes para elegir una herramienta de administraci贸n de configuraci贸n. Elegimos Salt porque priorizamos los siguientes beneficios:
- Modularidad, disponibilidad de API en la versi贸n gratuita, a diferencia de Ansible.
- Python, lo que significa que puede comprender f谩cilmente cualquier componente y escribir usted mismo la funcionalidad que falta.
- Alto rendimiento y escalabilidad. El asistente establece una conexi贸n permanente con los minions utilizando ZeroMQ para obtener el m谩ximo rendimiento.
- Los reactores son una especie de disparadores que se ejecutan cuando aparece un determinado mensaje en el bus de mensajes.
- La orquestaci贸n es la capacidad de construir relaciones complejas y realizar acciones en una secuencia espec铆fica, por ejemplo, configurar el equilibrador de carga primero y luego el cl煤ster del servidor web.
- Puppet y Chef est谩n escritos en Ruby. Nuestro equipo no tiene un especialista competente para trabajar con este lenguaje de programaci贸n, pero Python es bien conocido y lo usamos con frecuencia.
- Para aquellos equipos que anteriormente usaron Ansible, la capacidad de usar los libros de jugadas de Ansible ser谩 relevante. Esto le permitir谩 migrar a Salt sin dolor.
Tenga en cuenta:
Hemos estado usando Salt durante casi dos a帽os y le recomendamos que preste atenci贸n a los siguientes puntos:
- Salt, , . , . , SaltStack .
- SaltStack . , . : , . , cmd.run file.managed, .
, , , .
. .
Dado:
Entonces, nuestra configuraci贸n inicial es:
- 2 repositorios de Git (uno es para ingenieros y administradores; el segundo es para servidores muy cr铆ticos, disponible solo para administradores);
- un dato en MySQL;
- la otra parte, en Puppet 3.8 (exagerada con la herencia, pr谩cticamente sin usar Hiera , almacenamiento de valores clave).
Objetivo: migrar el sistema de gesti贸n de la configuraci贸n a Salt, aumentar su rendimiento, hacer que la gesti贸n del servidor sea m谩s c贸moda y comprensible.
Soluci贸n: En
primer lugar, comenzamos a migrar la configuraci贸n original a Salt desde servidores de servicios no cr铆ticos separados, al mismo tiempo que nos deshacemos del c贸digo obsoleto.
Luego preparamos la configuraci贸n para servidores VDS. En nuestro caso, se trata de perfiles para servidores de servicio, servidores de desarrollo y servidores cliente.
El principal problema con la transici贸n de Puppet a Salt fue el sistema operativo desactualizado (en 2018, estaban Ubuntu 12.04 y 14.04). Antes de la migraci贸n, era necesario actualizar el sistema operativo y no afectar el funcionamiento del servicio / servidor. De lo contrario, todo fue bastante f谩cil: los colegas se involucraron gradualmente en el proceso.
Entre las principales ventajas, el equipo se帽al贸, por ejemplo, una sintaxis m谩s comprensible. Mis colegas y yo acordamos usar los consejos de las mejores pr谩cticas de Salt , pero los complementamos con nuestras propias recomendaciones que reflejan nuestras particularidades.
El equipo tambi茅n evalu贸 los m茅todos de entrega de la configuraci贸n: empujar (el maestro "empuja") y tirar (el minion "tira"). El modo sin maestro ayuda si necesita probar algo simple y al mismo tiempo no meterse con el repositorio de Git. Ejecutar un minion en modo sin maestro le permite usar la administraci贸n de configuraci贸n de Salt en una m谩quina sin tener que ir al maestro de Salt en otra m谩quina. La configuraci贸n es completamente local.
Hasta 300 minions con tal soluci贸n, no tuvimos problemas serios. La configuraci贸n maestra en ese momento es un VDS con 6 n煤cleos y 4 GB de memoria.
Sin embargo, tan pronto como el n煤mero de minions alcanz贸 los 300, el promedio de carga (carga promedio del sistema) aument贸 a 3.5-4, y el sistema se ralentiz贸 mucho. Anteriormente, el comando state.apply tardaba entre 30 y 40 segundos, 隆pero ahora tarda 18 minutos!
Ese resultado, por supuesto, fue inaceptable para nosotros. Adem谩s, expertos de otras empresas han escrito sobre historias de 茅xito con 10.000 minions. Empezamos a averiguar cu谩l era el problema.
Las observaciones del maestro no dieron una respuesta inequ铆voca a la pregunta. Hab铆a suficiente memoria, la red no estaba cargada, el disco se utiliz贸 en un 10%. Pensamos que la culpa era de GitLab, pero tampoco la ten铆a.
Parece que no hab铆a suficiente potencia del procesador: al agregar n煤cleos, el promedio de carga disminuy贸 naturalmente y se ejecut贸 el comando state.apply, aunque m谩s r谩pido, unos 5-7 minutos, pero no tan r谩pido como quer铆amos.
Agregar trabajadores resolvi贸 parcialmente el problema, pero aument贸 significativamente el consumo de memoria.
Entonces decidimos optimizar la configuraci贸n en s铆.
Nivel 1
Dado que los pilares son un almacenamiento protegido, el acceso al almacenamiento est谩 asociado con las operaciones de cifrado, y debe pagar el acceso a 茅l con el tiempo de la CPU. Por lo tanto, redujimos el n煤mero de llamadas a los pilares: los mismos datos se tomaron una sola vez; si se necesitaban en otro lugar, el acceso a ellos se realizaba mediante la importaci贸n ({% - from 'defaults / pillar.sls' import profile%}).
La configuraci贸n se aplica una vez por hora, el tiempo de ejecuci贸n se elige al azar. Despu茅s de analizar cu谩ntas tareas se realizan por minuto y cu谩n uniformemente se distribuyen en el transcurso de una hora, descubrimos: al comienzo de la hora, del 1 al 8, pasa la mayor cantidad de tareas, y al minuto 34, 隆ninguna! Escribimos un corredor que pasaba por todos los minions una vez a la semana y distribu铆a las tareas de manera uniforme. Gracias a este enfoque, la carga se volvi贸 uniforme, sin saltos.
Hubo sugerencias para pasar a un servidor de hierro, pero en ese momento no estaba all铆 y ... resolvimos el problema de una manera diferente. Agregamos algo de memoria y colocamos toda la cach茅 en ella. Al observar el tablero de Grafana, primero pensamos que el salt-master no estaba funcionando, ya que el promedio de carga cay贸 a 0.5. Verificamos el tiempo de ejecuci贸n de state.apply y tambi茅n nos sorprendi贸: 20-30 segundos. 隆Fue una victoria!
Etapa 2
Seis meses despu茅s, el n煤mero de minions aument贸 a 650 y ... el rendimiento volvi贸 a degradarse. El gr谩fico de carga promedio crece con el n煤mero de minions.
Lo primero que hicimos: habilitamos la cach茅 de pilar, establecimos la vida 煤til en 1 hora (pillar_cache_ttl: 3600). Nos dimos cuenta de que ahora nuestras confirmaciones no ser谩n instant谩neas y tendremos que esperar a que el maestro actualice la cach茅.
Como no quer铆amos esperar en absoluto, hicimos ganchos en GitLab. Esto permiti贸 en la confirmaci贸n para indicar para qu茅 minion necesitas actualizar la cach茅. La cach茅 de Pillars redujo significativamente la carga y redujo el tiempo para aplicar la configuraci贸n.
Etapa 3
Meditamos un poco sobre los registros de depuraci贸n y presentamos una hip贸tesis: 驴qu茅 pasa si aumentamos el intervalo de actualizaci贸n para el backend del archivo y el cach茅 de la lista de archivos (gitfs_update_interval, fileserver_list_cache_time)? La actualizaci贸n se realizaba una vez por minuto y, a veces, tardaba hasta 15 segundos. Al aumentar el intervalo de actualizaci贸n de 1 minuto a 10 minutos, 隆volvimos a ganar en velocidad! El indicador LA disminuy贸 de 1,5 a 0,5. El tiempo para aplicar la configuraci贸n se redujo a los 20 segundos deseados. A pesar de que LA volvi贸 a crecer despu茅s de alg煤n tiempo, la velocidad de ejecuci贸n de la aplicaci贸n estatal no cambi贸 significativamente. Se agreg贸 una actualizaci贸n forzada de estos cach茅s a los ganchos en git push.
Agregamos an谩lisis a Elasticsearch: reescribimos el elasticsearch_return incorporado y ahora podemos monitorear los resultados de state.apply (tiempo de ejecuci贸n promedio, estado m谩s largo y n煤mero de errores).
resultados
Ahora estamos completamente satisfechos con el desempe帽o de Salt. Hay planes para duplicar el n煤mero de minions. Todav铆a es dif铆cil decir c贸mo nuestro maestro har谩 frente a tal carga. Quiz谩s recurramos a la escala horizontal o encontremos un par谩metro m谩gico. 隆El tiempo dir谩!
Si est谩s usando gitfs como tu backend, 隆dale un cinco! Lo m谩s probable es que est茅s pasando por los mismos problemas que nosotros. As铆 que estaremos encantados de discutir este tema en los comentarios.