Estamos haciendo el mejor sistema de detección de préstamos en Rusia y países vecinos. En un mundo ideal, solo nos ocuparíamos del diseño y desarrollo del sistema. Pero, por desgracia, el antiplagio no funciona en el vacío, y para que nuestros usuarios utilicen nuestros desarrollos de manera conveniente y cómoda, también necesitamos desarrollar el entorno que rodea nuestro servicio. Nuestro software aún no funciona sin hierro, los usuarios deben proporcionar asistencia técnica, es necesario recibir el pago de los usuarios sin violar la ley, etc. En resumen, la rutina es suficiente.

Este artículo es el primero de una serie de dramas de producción sobre cómo mejoramos nuestro servicio con la subcontratación. Compartimos problemas reales y conclusiones.

Nubes, caballos de pelo rubio ...

^{(Desde algún lugar de Internet, lo vi por primera vez aquí ).}

La carga en nuestro sistema es muy desigual: en primer lugar, durante el día la carga cambia 5 veces. En segundo lugar, hay una estacionalidad pronunciada. ¡El máximo diario de controles después del final de la sesión de verano se reduce en 10 veces! La sesión de invierno no es tan brillante, pero tampoco es un regalo. Además, cada sesión de verano posterior es más pesada (en términos del número de controles) y más difícil (nuevas tecnologías de búsqueda y funcionalidad) de la anterior. Por lo tanto, por un lado, quiero tener un buen suministro de recursos, por otro lado, no pagar demasiado durante una disminución de la actividad. En una sesión, puede implementar más servidores y, en verano, reducir la cantidad de recursos consumidos. Obviamente, este es solo el caso con los proveedores de la nube. En este artículo, hablaré sobre varios aspectos de la interacción con varios proveedores de la nube (AWS, IT Grad, MCS, YC). Si a alguien le parece que esto es un grito del alma, no se equivocará mucho. ¡Entonces vamos!

Aws

Comenzamos a usar recursos en la nube en febrero de 2013 cuando alquilamos nuestro primer servidor en AWS. De hecho, Amazon es la primera y más antigua experiencia de lucha contra el plagio con las nubes. Luego comenzamos con una máquina, y ahora nuestro presupuesto en AWS es un orden de magnitud más alto que el presupuesto para todas las nubes rusas. El primer amor, como sabes, nunca se olvida. Todos los problemas y oportunidades con otras nubes en este artículo lo consideré en función de la experiencia con AWS.

Es cierto que también hubo una mosca en el ungüento en las relaciones con Amazon. Las siguientes son las características o inconvenientes que tenemos con Amazon:

1. No puede acceder a la consola de una máquina virtual a través de un navegador. ¡Y a veces es justo aquí realmente necesario! Una vez que eliminamos por error la interfaz de red, se perdió el acceso en una de las máquinas. Fue una suerte que alguien ya se hubiera encontrado con ese problema, en media hora encontramos y aplicamos con éxito la solución. A través de la consola, tal operación podría hacerse en un minuto.
2. Los costos están en dólares y nosotros ganamos en rublos. En consecuencia, la rentabilidad depende del dólar.
3. No hay un centro de datos en Rusia, el más cercano cuando comenzamos fue en Irlanda. Esto significa un gran ping y algunas restricciones en el almacenamiento de datos que surgen debido a los requisitos de la ley rusa.
4. Roskomnadzor bloquea regularmente las direcciones de AWS. Actualmente, hay diferentes servidores disponibles en AWS de diferentes sitios. Por razones desconocidas, la conexión a la máquina puede caerse. Por lo general, cambiar la dirección IP, VPN y proxy ayuda.
5. Amazon es significativamente más caro que las nubes rusas. Es cierto que puede reducir el costo a través de un programa de respaldo flexible y el uso de instancias puntuales . Y estamos usando activamente ambos. Por desgracia, aún no hemos visto dicha funcionalidad en las nubes domésticas (upd: YC anunció "VM interrumpidas" en el boletín del 18 de febrero, estamos esperando detalles).
6. El problema con mensajes insuficientemente informativos. Durante la transición de la 3ra generación de máquinas a la 4ta o 5ta, el hardware virtual cambió seriamente, en particular, el método de conexión de unidades, y las máquinas simplemente no comenzaron después del cambio de tipo. La interfaz de administración de instancias devolvió un mensaje conciso: capacidad insuficiente. Había suficientes límites para crear los tipos necesarios de máquinas con un margen, y durante aproximadamente seis meses probamos sin éxito el soporte técnico gratuito para cambiar los límites. No sirvió de nada. Como resultado, buscaron en Google la solución: una recreación banal de las máquinas ayuda.
7. Un par de veces borramos los SSD en los agujeros: los discos simplemente desaparecieron del sistema junto con todos los datos. Dado que estos eran discos efímeros , es decir los datos se pierden cuando la máquina se detiene, no almacenamos algo irremplazable en ellos.

En principio, era posible vivir con estas deficiencias. Sin embargo, exactamente en el momento en que Amazon finalmente notó el mercado ruso, nuestra cuenta se volvió poco conveniente para el pago con tarjeta. Afortunadamente, Amazon corrigió rápidamente la situación y nos proporcionó un administrador de cuentas que nos ayudó a pasar de pagar con una tarjeta a un contrato directo y pagar una factura y elaborar varios tipos de acuerdos. En general, él viene regularmente a Rusia, y cuando viene a nosotros, habla sobre oportunidades para optimizar la infraestructura y el pago. Algunas veces trae consigo un Arquitecto de Soluciones, con quien puede discutir la arquitectura actual de nuestra solución, hablar sobre "Lista de Deseos" y problemas, y obtener varias soluciones, no solo a través de los servicios de AWS. Los empleados de Amazon declaran que su objetivo no es proporcionar más servicios, sino garantizar que los servicios adquiridos beneficien a la empresa. Parece que esto es realmente cierto. La cantidad de servicios, la velocidad de su desarrollo y la profundidad de la integración mutua son impresionantes. AWS tiene todo para organizar tanto el proceso de desarrollo como la operación de sistemas altamente cargados de cualquier escala. Hasta ahora, ¡solo un problema global es caro!

IT Grad 2016

En 2015, decidimos que era hora de abandonar completamente nuestro propio hierro. Quería poner los problemas en la confiabilidad del equipo específicamente en otros y concentrarme más en mejorar los procesos de nuestro propio desarrollo. Según nuestras previsiones, en 2016 habríamos tenido suficiente del equipo que teníamos ahora, y nos gustaría tener una reserva para cada evento de incendio. Nos acercamos a la elección del proveedor a fondo: preparamos una prueba de carga y un cuestionario con preguntas importantes para nosotros y elegimos meticulosamente entre cinco proveedores: ActiveCloud, Cloud4Y, CloudOne, IT Grad, Softline.

Como resultado, optamos por las nubes IT Grad. Sus ventajas:

1. Posición de vida activa, las respuestas a nuestras preguntas se dieron rápidamente, fue fácil comunicarse.
2. La presencia de unidades SSD rápidas, hasta 30 IOPS por GB. El número de operaciones de lectura aleatorias es un indicador muy importante para nosotros, ya que los valores altos nos permiten colocar nuestros módulos de escaneo en la nube.
3. Plataforma VCloud con la capacidad de controlar máquinas y la presencia de una consola para cada máquina.
4. La capacidad de aumentar los recursos de una máquina virtual sin reiniciar.
5. Facturación flexible : el pago se realiza por los recursos que estaban en uso el día en el medio del período del informe (del 14 al 15 de cada mes). Además, existe una opción de "Pago por uso", sin embargo, es más costosa y el cálculo de la cantidad de recursos consumidos se realiza por la carga promedio de CPU y RAM cada 2 horas.

En 2016, nos mudamos a IT Grad. Esto es lo que sucedió en los tres años incompletos de nuestra vida juntos:

1. Una vez tuvimos un problema. Exactamente a las 21:00 comenzó un extraño descenso en el rendimiento. La cantidad de verificaciones que el sistema podía hacer disminuyó de 150 a 20-30 por minuto, mientras que después de un par de horas todo se restableció y resolvió a una velocidad de 600 verificaciones por minuto. Buscamos durante una semana en casa, verificamos usuarios, atrapamos bots y DDoS, pero no encontramos nada. Nos dirigimos al soporte de IT-Grad, descubrimos que "oh, y estamos haciendo copias de seguridad aquí". Como resultado, nos aplastaron con una fuente de problemas para diferentes sistemas de discos y configuraron el trabajo.
2. Por lo general (características del uso del producto), durante una sesión, nuestro tráfico supera los 100 megabits por segundo. Este valor, por cierto, a menudo se establece de manera predeterminada para el canal no reservado en muchos proveedores de la nube. Cuando cruzamos esta frontera por primera vez, surgieron una serie de problemas: el Edge integrado no podía hacer frente a la VPN entre el punto de entrada ubicado en nuestro equipo y la máquina virtual del servidor web ubicado en la nube. Como se esperaba, recurrieron al soporte, donde se nos ofreció aumentar los recursos en Edge. Ok, no hay duda, reemplazamos su configuración de pequeña a grande, y también expandimos el canal al tamaño de nuestro tráfico pico con un margen. No sirvió de nada. En general, no pudimos encontrar la solución óptima, tuve que reducir el volumen de tráfico trasladando parte de la producción a otros sitios.
3. La conexión VPN al sitio IT Grad a veces se rompe durante 1-2 minutos. A la pregunta de por qué sucede esto, ni nosotros ni el soporte técnico podemos encontrar la respuesta. Hasta ahora tengo que vivir con este problema.
4. El mecanismo para cambiar el tamaño de los recursos funciona mal, tanto sobre la marcha como en estado apagado. Sin embargo, me parece que esto es más bien un problema con el proveedor de la plataforma (VMware). Sin embargo, ya nos hemos encontrado con el hecho de que para aplicar de manera confiable todas las extensiones, era necesario reiniciar la máquina invitada (Windows Server 2012 R2). Después de cambiar el tamaño, la máquina en sí no arrancó varias veces. Una vez que el soporte solucionó este problema de 2 a 4 de la mañana durante la sesión, nuestra propia temporada. ¡Hacía calor incluso de noche!
5. En 2016, tuvimos un gran monolito, como el Everest, que requirió muchos recursos. Tantos que a veces necesitábamos superar el tamaño máximo de máquinas invitadas recomendadas para un host determinado. El soporte técnico nos solicitó persistentemente reducir el tamaño de las máquinas virtuales a al menos la mitad del tamaño del host. Debemos rendir homenaje a IT Grad: se nos ofreció usar un hardware separado con la capacidad de usarlo por completo, sin embargo, por unos pocos grandes sumas de dinero, y se perdió la flexibilidad de la nube.
6. Facturar una vez al mes para medir la cantidad de recursos consumidos nos ha engañado dos veces. Al principio, preguntamos directamente sobre la oportunidad de reducir los recursos del 14 al 15 de un mes para pagar menos. Nos respondieron directamente que así es como funciona. La primera vez nos golpeó dolorosamente durante la transferencia de una parte de la venta a nuestra nube. El factor humano funcionó: trataron de terminar rápidamente todo antes del 14, luego lo rastrearon notablemente. La segunda vez aprovechamos esta oportunidad después de casi 3 años de cooperación, después de lo cual se nos facturó en promedio los días 5, 15 y 20. Luego, el factor humano funcionó para ellos: después de la llamada resultó que cometieron un error a su favor (el recálculo se realizó manualmente), se disculpó y dio un descuento.
7. El rendimiento de los discos y las máquinas en su conjunto cumplió con las características declaradas. Sin embargo, varias veces no pudimos entender por qué todo funcionaba tan lentamente, incluso la interfaz se desaceleró sin piedad. El soporte aseguró que todo estaba en orden y que no tenían problemas con el equipo. Lo que sucedió allí (nuestro servidor en ese momento migró a un host vecino o alguien hizo una copia de seguridad del subsistema de disco) sigue siendo un misterio para nosotros.
8. Los discos se pueden cambiar entre máquinas de forma independiente solo a través del soporte. Al comienzo del uso, era imposible tener discos de diferentes tipos en la máquina, tenía que salir (iSCSI, Samba y NFS). Después de algún tiempo, el uso de diferentes tipos de discos en una máquina se hizo posible primero a través del soporte y luego por su cuenta (aparentemente hecho en vCloudDirector). Por cierto, la actualización del sistema de administración de virtualización ocurre regularmente. Recibimos una carta 1-2 veces al mes que indica que durante una o dos horas el sistema de control de la máquina virtual toma trabajo técnico y no estará disponible por algún tiempo, las máquinas mismas continúan funcionando en este momento.
9. El 16 de febrero de 2018, una parte de nuestras ventas ubicadas en IT Grad se debió a problemas de suministro de energía del centro de datos en el que se encontraba el equipo. Nos enteramos del incidente de facto; no pudimos contactar al soporte técnico. Tuve que llamar a nuestro gerente de cuenta, él dijo inmediatamente en un minuto qué y cómo, y se desconectó, aparentemente contándole el resto. Desde lo agradable, estábamos acostados al lado de VKontakte.

Después de pasar un tiempo en una casa alquilada y enfrentar todo lo anterior, en 2017 decidimos que era bueno visitarlo, pero mejor en casa, y comenzamos a hacer una nube con discos NVMe rápidos y la capacidad de controlar completamente todo. Tan pronto como lo dijo: trasladó las ventas a su nube de clientes corporativos y módulos de búsqueda (en total más del 90% de la carga), dejando monitoreo, estadísticas y clientes privados en IT Grad. En 2018, todos calcularon nuevamente y resultó que era más rentable dividir la producción: mantener parte en la nube arrendada y parte en la suya. Lo que vino de esto, lo contamos más.

Soluciones de nube de correo

Honestamente, quería hacerlo, como en AWS, pero en Rusia. Por lo tanto, comenzamos a mirar hacia las nubes con conjuntos de servicios similares (a quienes estoy engañando, al menos con el análogo de EC2 y S3). La búsqueda fue de corta duración: encontramos la "Amazonía rusa" en la persona de MCS . ¡Una gran empresa con una amplia gama de servicios diversos, según todas las indicaciones, deberían ser capaces de preparar las nubes!

El comienzo del conocido fue maravilloso. Un gerente de cuentas vino a nuestra oficina, contó todo en detalle, describió las oportunidades actuales y los planes para el futuro cercano. El resultado fue una imagen maravillosa: precios bajos para los recursos informáticos, hay un almacenamiento de objetos y una salida temprana a la producción de la base de datos (similar a RDS). También nos dieron un límite de efectivo sólido para las pruebas (incluso más de lo que ofrece Azure).

Para ese momento, ya teníamos la parte de IaC lista para desplegar todas las máquinas a través de terraform. MCS tenía OpenStack y fue bien soportado! Por cierto, el soporte técnico se lleva a cabo a través de un canal de telegramas: comunicación "en vivo" y está claro que quieren ayudar. Hay un sistema de tickets, pero aún no lo hemos usado. Soporte técnico SLA se refiere a las solicitudes creadas en el sistema de tickets.

Para diciembre de 2018, teníamos escritos scripts de implementación de infraestructura a través de terraform. Es hora de moverse. Para empezar, decidimos transferir el sistema con clientes privados, que durante todo este tiempo vivieron con equipos en IT Grad. Entonces todo es como en una película:

7 (), 18:00 . , .
10 (), 10:00 – .
12 () – .
10:00 terraform. , , .
12:00 ansible'. . !
15:30 . 30 , 16:30.
15:45 . .
15:55 . : , .
16:20 , . , . , - .
17:30 , , .
18:00 . 1,5 .


El problema identificado con diferentes formatos con un nuevo intento no debería haber aparecido, pero lo encontramos y por si acaso lo solucionamos.

17 (), .
15:30 . , .
16:00 . .
16:30 , 100%. -? !
17:00 , , , , iotop, top, ProcessExplorer, PerformanceMonitor. .
21:45 , , , 2000 .
22:00 , .


El viejo producto de IT Grad satisfizo fácilmente la demanda diferida de cheques de usuarios, no hay problema.

Al día siguiente (18 de diciembre), nos dimos cuenta de lo siguiente:

1. No sabíamos qué ralentizaba específicamente el sistema. Antes del friso, prácticamente no había carga en ninguna parte. Sí, todavía tenemos llamadas de bloqueo profundo dentro del sistema y lo más probable es que haya un bloqueo en alguna parte, pero donde exactamente, no pudimos encontrarlo, fue necesario investigar más a fondo.
2. Nuestra prueba de carga actual no coincidía con el perfil de carga del producto. Fue asombroso porque Gracias a esta prueba, nos preparamos para la última sesión, identificamos y eliminamos una gran cantidad de cuellos de botella. Pero tal es la realidad: es necesario rehacer la prueba teniendo en cuenta la experiencia adquirida.
3. Producido en IT Grade con recursos comparables de CPU y RAM, puede hacer frente fácilmente al doble de la carga.

Entonces, creamos rápidamente una prueba que logra el mismo resultado que vimos de primera mano. Acudimos al soporte de MCS para averiguar si estamos consumiendo algún límite de CPU, pero en general es completamente nuestro o no, y todo está bien con la red. Todavía no han respondido a la segunda pregunta, encontraron algo en la tercera y nos recomendaron que hiciéramos cambios en los sistemas de múltiples núcleos. En general, hemos desarrollado una actividad vibrante, el fin de año está cerca y todos quieren irse de vacaciones con una sensación de logro.

Esto es lo que terminamos trabajando con MCS:

1. Incluso en la etapa de selección, nos enviaron una tabla con las características de hardware virtual y SLA por disco. Una de las ventajas fue que prometieron 50 IOPS / GB (IT Grad: 30 IOPS / GB) para el SSD. El contrato resultó ser diferente: "lectura: 5000 IOPS, escritura: 2000 IOPS", y nos perdimos esto, no esperábamos esto. Las tablas son idénticas, ¡la diferencia es solo en un lugar! Por cierto, no vimos las dependencias de rendimiento en el tamaño del disco. Cuando probamos, incluso resultó que con un disco más grande, la velocidad disminuye. El secreto de estos pequeños indicadores es que MCS tiene ceph geo-distribuido, lo que significa que hasta que el nodo remoto diga que los datos han sido escritos, no se le dirá al cliente que la grabación está completa. Por cierto, nadie parece tener esa fiabilidad "fuera de la caja" entre los proveedores con los que hablamos. ¡Pero para nosotros tal confiabilidad solo pone palos en las ruedas! Si sucede algo, debemos movernos rápidamente a otro DC cuando surgen problemas y, por lo tanto, tenemos nuestra propia replicación asincrónica. Tenemos DRP y estamos preparados para la pérdida de una pequeña cantidad de datos en caso de accidente. Debemos rendir homenaje a MCS, que aceleraron la puesta en marcha de una matriz SSD local, cuyo rendimiento fue mucho mayor.
2. En cuanto a los parámetros de las máquinas, no son arbitrarios. Hay un cierto conjunto de CPU-RAM- {SSD / HDD} (casi como en AWS), y otros tipos de máquinas solo se pueden crear a través del soporte. Todo el proceso dura aproximadamente 2 horas, no hay límite en el número de tipos, lo principal es que el número de núcleos no debe ser más de la mitad del hipervisor ~ 40-48 procesadores. Durante la creación de la máquina, puede agregar discos usted mismo y cambiarlos entre máquinas.
3. Después de encender el SSD local, cambiar los parámetros de la máquina hizo imposible iniciarlo. Solo podían lanzarse a través del soporte. En algún lugar en un mes resolvieron el problema.
4. Por primera vez ante el soporte técnico por telegrama. En general, es conveniente, especialmente al comienzo, cuando hay muchas preguntas y el servicio se está complicando. Pero cuanto más lejos, más difíciles resultaron las preguntas y la velocidad de respuesta y el contenido de la información disminuyeron lentamente. A finales de año, cuando, por supuesto, los plazos de todos estaban en marcha, la baja velocidad de las respuestas me enfureció terriblemente. En algún momento, incluso preguntaron sobre los SLA. ¡Aquí es donde se entendió que el SLA está en el sistema de tickets, y no en el telegrama! En el momento del 19 de febrero, varias de nuestras preguntas sin respuesta formuladas el 24 de diciembre cuelgan en este canal ...
5. El soporte técnico a través del sistema de tickets no tiene en cuenta que hemos iniciado sesión y requiere una notificación adicional del número de contrato. En respuesta, envía una carta "nos pondremos en contacto con usted", pero no indica el número de boleto o el estado.

Mientras trabajaba con MCS, otra nube comenzó a verse en paralelo.

Sin embargo, otra nube (Yandex Cloud)

El primero de los otros fue Yandex. A finales de 2018, solo tenían máquinas virtuales y almacenamiento de objetos, su propio sistema de virtualización, API abierta. El complemento de terraform estaba en alfa y fue aceptado por HashiCorp. El soporte, como de costumbre, es a través de telegrama, pero es menos activo que en MCS. El límite de dinero de la prueba es lo suficientemente pequeño y no nos permitió realizar pruebas normales. Tuve que concluir rápidamente un acuerdo (3 días hábiles) y pagar las pruebas. Según los resultados de la prueba, obtuvimos lo mismo que en el MCS. Comenzó a parecernos que había dos problemas: todos tenemos unidades demasiado lentas y tenemos una prueba demasiado severa.

IT Grad 2019

En general, fijamos una fecha límite para mudarse ya el 22 de diciembre, para que haya otra semana para identificar y resolver los problemas ocultos de una nueva residencia. Habiendo perdido la esperanza de pasar a la fecha límite y un poco cansado de la abundancia de nueva información en la persona de MCS e YC, decidimos que IT Grad no es tan malo en su contexto. Incluso nos sentimos un poco nostálgicos y pensamos que todo lo nuevo está bien establecido. Ya en IT Grad definitivamente trabajaremos bien, hay un precedente. Además, IT-Grad aumentó: había un centro de datos de Moscú, Tier III, tiempo de actividad en el momento en que todavía tiene el 100% (nunca falló), y el equipo en el interior: 4 zócalos Intel Xeon escalables (hasta 42 núcleos x 3 GHz Xeon Gold 6154). ¡Qué diablos no es broma, daremos una segunda oportunidad!

28 (), 18:10 - vDC , , .
29 ( ), 17:04 , . .iso , . , . , . , .
30 (), 22:00 , .iso, . , - .
31 (), 3:15 Edge vDC vDC. , . .

, .

2 (), 15:30 .
2 (), 21:50 , Guest OS Customization .
3 (), 18:05 !

1. Ahora, en la preparación del artículo, descubrieron que el tiempo exacto de las solicitudes y respuestas no se refleja en el sistema de tickets. En cambio, dice "hace aproximadamente 2 meses", el tiempo exacto se muestra solo en una información sobre herramientas. Por correo, también es difícil restaurar la secuencia de eventos. Los mensajes al correo vienen en una lógica no obvia y no contienen una descripción de la acción. Los tickets se crean en el sistema después de un tiempo en nombre de un empleado de soporte técnico de IT Grad.
2. Después de mirar más de cerca el equipo después de las vacaciones, vimos Xeon v2 allí. Eso no es lo que acordamos. Bien, decidimos esta pregunta con el administrador de la cuenta. Hubo algunas dificultades debido al hecho de que en el nuevo año 2019 IT Grad se incluyó en el MTS , y justo después de las vacaciones hubo un pequeño desastre. Desde vDC en adelante, el nuevo equipo en Moscú DC no era visible vDC creado antes del año nuevo. Solo a través de Internet abierto, el soporte técnico nos "complació" de que la velocidad de movimiento no exceda 1TB / día. ¡Y ya hemos subido 7 TB de datos! Como resultado, crearon una aplicación para mudarse el jueves por la noche. Un día después, el viernes por la noche, pregunté cómo estás y cuándo planean comenzar (¡espera casi una semana!)? Un día después, el sábado por la noche, nos dijeron que todos los autos se habían movido. No me gustó que 2.5 días no hubo información sobre el progreso del trabajo y que las estimaciones sobre la mudanza eran demasiado pesimistas.
3. En septiembre de 2018, cuando comenzamos a implementar IaC, nos dimos cuenta de que Terraform funciona muy mal con vCloudDirector (upd: al momento de escribir esto, nos enteramos de que VMware vCloud Director Provider 2.0 apareció , pero aún no lo he probado). Al principio, ni siquiera podíamos crear una máquina debido a que vCloud nos informó de un error en el espíritu de "algo salió mal, tienes un error de 512 caracteres 136 líneas (¡la línea era más corta!) Xml de la configuración de la máquina". Pedimos apoyo. La pregunta fue redirigida a los ingenieros, al final nos dijeron que Terraform no es compatible, resuélvelo tú mismo. De todos modos, descubrimos que el culpable era el empaquetador, con el que recopilamos la imagen de la máquina, no podía hacer frente al formato de configuración de VMware patentado. Terraform es muy malo con vCloudDirector, todo se enhebra lentamente y el conector ha estado abandonado durante mucho tiempo y no se desarrolla. Nadie nos daría acceso a vSphere. Si permanece en VMware, entonces necesita ver su automatización a través de su API.

Organizamos un banco de pruebas en una nueva ubicación. El resultado fue sorprendente: la prueba falló, los síntomas son los mismos que en el MCS. Probablemente, en la producción actual en el fragor de la batalla por la sesión, se cambiaron algunas configuraciones del sistema operativo que evitan que el sistema se congele, pero que ahora no se puede restaurar. Para evitar que esto vuelva a suceder, presentamos IaC. Llevamos a cabo 2 pruebas más: creamos máquinas nuevas a partir de imágenes limpias de los sistemas operativos de la venta actual: falla; en máquinas de producción existentes: éxito. Por lo tanto, se confirmó que hicimos algunos ajustes en el sistema operativo o la base de datos, pero no recordamos cuál. En este punto, la solución de nuestro desarrollo llegó a tiempo: los frisos se detienen cuando las sesiones confiables están deshabilitadas en WCF.

Realizamos una prueba de carga con la configuración recomendada por los desarrolladores en paralelo en MCS (2 GHz, Xeon v4) e IT Grad (3 GHz, Xeon v2): la cantidad de núcleos y memoria es la misma. En MCS, la prueba pasó más rápido (por un cuarto) y más suave (en IT Grad, la prueba se volvió irregular, luego más rápida y luego más lenta).

Comparación de rendimiento de disco

Estábamos más preocupados por el rendimiento de los discos para bases de datos e índices, razón por la cual probamos principalmente SSD. No juzgue estrictamente las pruebas, cuando necesitábamos comprender el rendimiento de las nubes, en habr.com todavía no había varias pruebas de discos, procesadores, proveedores de nube de memoria ( una vez , dos ). Teníamos un tiempo limitado y necesitábamos comparar rápidamente el rendimiento para tener una idea de la diferencia en el rendimiento. Por lo tanto, el requisito para la prueba era uno: puede repetirse rápidamente en cualquier sitio. Utilizamos las máquinas lo más cerca posible de los parámetros que ya habíamos implementado, fio, para probar el rendimiento de los discos, y pgbench, para evaluar el rendimiento de la base de datos en este disco. Como estándar, tomamos medidas de la producción actual: MARS (porque nuestro equipo lleva el nombre de los héroes de la serie animada sobre ratones rockeros de Marte ).

Por lo general, el rendimiento del disco depende de su tamaño. Observamos este comportamiento en IT City y en AWS, pero en MCS no vimos tal dependencia, tampoco existe en SLA, y las pruebas dieron un resultado paradójico (y posiblemente inexacto): el rendimiento disminuye al aumentar el disco.

Contamos iops para discos HDD y SSD, así como tps (transacciones por segundo) para la base de datos postgres en discos SSD. Hay dos tipos de discos en MCS: SSD y HDD ceph geo-distribuidos regulares y SSD locales (solo en un DC) (su rendimiento se muestra entre paréntesis). También en enero de 2019, en el envío de correos de MCS, leemos que aumentaron el rendimiento del disco en un 20%, el resultado de la prueba también está en la tabla (MCS 2019). En febrero, se informó otra aceleración, pero no realizamos pruebas aquí.

Resultados:

Metodología de prueba

iops se calculó como el promedio de 4 ejecuciones de fio:
/root/fio-2.0.9/fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75

tps , como un promedio de 3 ejecuciones de pgbench:
pgbench -c 10 -j 2 -t 10000 example

Descripción de stands

Marte

Xeon v4, 2 GHz ; HDD: ceph, 3 nodos de 9x 2Tb ST2000NX0253, réplica 2; SSD: ceph, 3 nodos en 2Tb NVMe Intel DC P4600, réplica 2

CPU : 4, RAM : 8 GB, HDD : 32 GB, SSD : 150 GB; La producción paralela está girando.

Graduado de TI

Xeon v4 / v2, 2 GHz ; HDD : 0.1 IOPS / GB ; SSD: 30 IOPS / GB

CPU : 4, RAM : 4 GB, HDD : 250 GB, SSD : 200 GB

Mcs

Xeon v4; HDD: r / w: 1500/1000 IOPS; SSD: r / w: 5000/2000 IOPS

Para probar HDD: CPU : 2, RAM : 4GB, HDD : 50GB

Para probar SSD, TPS : CPU : 8, RAM : 16 GB, SSD : 600 GB

Y

Xeon v4, 2GHz

CPU : 8, RAM : 8GB, HDD : 20GB, SSD : 50GB

Comparación de las estimaciones de TCO para el año

Contamos TCO para cuatro opciones. Los valores relativos se muestran en la tabla a continuación. Debo decir que este es un cálculo para nuestro caso específico y que todo puede resultar diferente para usted.

Hicimos el cálculo de la siguiente manera. El año se dividió en dos partes: sesiones (con mayor carga de trabajo) y el resto del tiempo. Para cada parte, se calculó la cantidad requerida de recursos de CPU y RAM. El volumen de disco requerido, debido al crecimiento constante del servicio, solo crece con el tiempo, por lo tanto, tomamos el promedio entre el comienzo y el final del año para la evaluación.

Hubo poca dificultad para evaluar con AWS, ya que no hay costo directo para el kernel y los gigabytes de memoria. Tomamos 3 máquinas mínimas c5.large, r5.large y m5.large y calculamos su costo a precios MCS (cambiando proporcionalmente el costo del núcleo de la CPU, ya que MCS tiene una frecuencia de 2 GHz). Resultó así: en promedio, el costo de las instancias simples de AWS es 2.5-2.8 veces mayor que el costo de MCS. AWS publica precios sin IVA. Por lo tanto, para el costo de AWS agregamos 20%, la tasa anual promedio en dólares es de 70 rublos. Los discos se consideran simplemente a precios de EBS (utilizamos diferentes tipos de gp2, sc1, st1). En algunos lugares necesitamos unidades NVMe de instancias de la familia i3. Su precio por gigabyte se calcula de manera muy simple: la diferencia de costo entre i3 y un procesador análogo y una instancia de memoria de la familia r4, dividido por la cantidad de NVMe. Resulta 3.1 rublos por gigabyte en 30 días.

Incluso en la conversación sobre presupuestos, me gustaría notar la diferencia en el costo de una licencia de Windows por un núcleo por mes para todos los proveedores de la nube. En AWS, la diferencia entre el costo de las instancias de Linux OnDemand y Windows OnDemand dividido por el número de núcleos es una constante de aproximadamente 2.800 rublos por mes. En YC, la licencia de Windows para el núcleo es 3 veces más barata, alrededor de 900 rublos al mes, y en MCS, casi 9 (!) Veces más barata, alrededor de 300 rublos al mes. Todavía dependemos mucho de Windows: ahora, gracias a .net core, estamos comenzando a hacer una plataforma multiplataforma contra el plagio, incluso para reducir el costo de mantenimiento.

El costo agregado de YC también incluye el costo del tráfico.

Conclusiones

A través de las nubes

AWS Dicen que en Rusia hay 4 buenos proveedores de nube: AWS, GCP, Azure y DO, y todos ellos no están en Rusia.
Pros: gran servicio, equipos modernos de alta calidad, buenas configuraciones en EC2, una gran cantidad de servicios.
Contras: caro (más riesgos de tipo de cambio) y no en Rusia (ILV, el gran firewall ruso en el horizonte). Realmente quiero que nuestras nubes sigan este ejemplo a seguir.
Características: El soporte técnico gratuito puede resolver un mínimo de problemas, pero, para ser sincero, lo contactamos solo para ampliar los límites de uso. Pagado, por cierto, cuesta alrededor del 10% de la cuenta.

IT Grad . Buen servicio para la nube corporativa. Hay análogos de EC2 y S3 basados ​​en Swift.
Pros: buen rendimiento (CPU de 1-2-3 GHz, SSD, HDD), equipo nuevo (en uno de los DC) entre nubes domésticas, configuraciones arbitrarias de la máquina.
Contras: facturación incomprensible, VMware (pobremente automatizado, interfaz flash), un poco de caos y gran cantidad de soporte técnico.
Características: se agudiza más bajo uso corporativo (una vez configurado, luego cambios raros) que bajo un sistema público altamente cargado (actualizaciones frecuentes, cambios constantes). Desde 2019, el negocio de IaaS se ha vendido junto con personas y equipos en MTS, ahora todo puede cambiar en cualquier dirección. Comunicación a través del sistema de tickets y teléfono, me gustaría una reacción más rápida y un mensaje de los plazos previstos.

MCS Hay análogos de los servicios EC2 (hay GPU), S3, ECS, RDS, EMR, sus propios servicios: aprendizaje automático, recuperación ante desastres en la nube, copia de seguridad en la nube
Pros: económico, en desarrollo activo, hay GPU (Tesla V100 y Grid K2).
Contras: unidades lentas, humedad, mal karma de la empresa matriz.
Características: el soporte técnico al principio es útil, se activa una gran cantidad de empleados, se siente ayuda, pero luego hay una disminución notable en la actividad (no respondieron nada desde el 24 de diciembre, incluso estoy preocupado por los muchachos).

YC . Tenemos muy poca experiencia trabajando con este proveedor, es difícil decir algo específico. Hay análogos de EC2, S3, RDS, DS, SQS (alfa), ELB (alfa), sus servicios únicos: SpeechKit, Translate.
Pros: las unidades son más rápidas que MCS.
Contras: el proveedor de terraformación está húmedo; El software del shell de virtualización con API abierta no es muy grande para la comunidad, lo que significa que hasta ahora solo puede confiar en las fortalezas del equipo de YC en el desarrollo del proveedor de Terraform.
Características: pagar por el tráfico.

Lecciones aprendidas

1. Nos dimos cuenta de que las pruebas de estrés son moralmente obsoletas. Actualizaron la prueba, encontraron nuevos cuellos de botella, los arreglaron y mejoraron el producto. Recordamos que la prueba de carga debe ser adecuada y debe haber configuraciones en las que definitivamente no pase para que pueda ver el límite de su aplicabilidad.
2. A pesar de la creencia generalizada de que el software no se está optimizando en este momento y de que todos los cuellos de botella se están inundando de recursos, tuvimos que descubrir y optimizar nuestro sistema. Resultó mejor de lo que era, la nueva versión de Anti-Plagiarism requiere menos recursos y funciona más rápido. Ya describí varios lugares más donde puede reducir el consumo de recursos.
3. Hicimos IaC, implementamos y actualizamos a través de ansible, aprendimos cómo pasar de una nube a otra (con replicación de datos preliminar) en casi 10-15 minutos. Si los datos se copian y se configura la replicación regular, aquí está el Plan de recuperación ante desastres: moverse en media hora con pérdida de datos en los últimos 15 minutos.

Lo que queremos de las nubes

1. Respuestas rápidas del soporte técnico. Desafortunadamente, hasta ahora no podemos usarlo como en AWS: hay muy poca información disponible.
2. Soporte para la automatización del despliegue de infraestructura mediante fondos gratuitos (terraform).
3. Previsibilidad en el rendimiento. Esto se aplica a la facturación, rendimiento de la CPU, RAM, discos.
4. La presencia de análogos funcionales EC2, S3, RDS ahora. En el futuro cercano, necesitamos soporte para k8s y cálculos de GPU (ya lo usamos en AWS).

Además de pasar a las nubes, en los últimos meses hemos logrado tocar el rastrillo en otras áreas. Cómo fue, lo contaremos un poco más tarde.