Cloud Metrics se cambia a OnMetal: aumenta su confiabilidad, reduce costos

por Alexander Scammon

Hace algunos meses, Rackspace Cloud Metrics cambió nuestro sistema de producción de la ejecución en máquinas virtuales en la nube a la ejecución en Rackspace OnMetal. El resultado es un sistema más confiable que es, sorprendentemente, más barato.

Cloud Metrics es un software como servicio (SaaS) de múltiples inquilinos que ofrece una plataforma flexible y asequible para almacenar y encargarse de métricas de series de tiempo. Brinda un REST API para asimilación y recuperación de métricas. Además, permite una innovadora integración con populares herramientas de código abierto como statsd, collectd y  Grafana. El software que impulsa este servicio es un proyecto de código abierto denominado ‘Blueflood’, desarrollado en Apache Cassandra.

Para nuestras necesidades operacionales, Rackspace Cloud Metrics requiere un clúster grande y estable de máquinas con mucho espacio de almacenamiento. Nos ocupamos de la flexibilidad y de la estabilidad para que los usuarios no tengan que hacerlo. Nuestro enfoque en la flexibilidad y la estabilidad es precisamente nuestra motivación para cambiar a OnMetal.

Dedicábamos mucho tiempo a atender las necesidades de nuestro clúster anterior. Para nuestros clientes, el servicio era relativamente estable, pero a costa de mucha mano de obra. A su vez, esto afectaba a nuestros esfuerzos de ingeniería para mejorar nuestro sistema. Por las dos razones que explicaré a continuación, esperábamos que los servidores OnMetal mejoraran la confiabilidad de nuestro servicio y liberaran parte del muy necesario tiempo de ingeniería.

Llevamos mucho tiempo codiciando la capacidad de computación disponible de OnMetal, pero esperábamos que aumentara nuestros costos. No obstante, cuando hicimos los cálculos, descubrimos que era mucho más barato (sí, ¡más barato!) que nuestra configuración existente. En ese momento nos dimos cuenta de que teníamos que cambiar a OnMetal.

Nuestro espacio original

Antes de cambiar a OnMetal, operábamos con servidores Rackspace 60G ‘Performance 2’ a los que ahora se denomina ‘I/O Virtual Servers’: máquinas virtuales que se ejecutan en la nube OpenStack de Rackspace. También disponemos de una gran cantidad de Cloud Block Storage (CBS) conectada a cada servidor.

El desempeño de nuestros servidores virtuales era más que suficiente para nuestras necesidades. De hecho, Cassandra pocas veces presentaba mucha carga para estas máquinas y los servidores en general estaban bastante ocupados. La razón del sobreaprovisionamiento del CPU y la memoria era conseguir los 600 GB de espacio de almacenamiento que proporcionaban estas máquinas.

No obstante, ni siquiera estas máquinas proporcionaban suficiente espacio para nuestras necesidades. En lugar de acelerar una interminable lista de servidores, aumentamos el almacenamiento incorporado en estas máquinas con 800 GB adicionales por servidor de Cloud Block Storage SATA de Rackspace. Conectamos todo con Rackspace Cloud Networks y conseguimos un enorme clúster para nuestras métricas.

Problemas con el clúster anterior

Manejamos el clúster en este estado de división por bastante tiempo: algunos datos localmente, otros en Cloud Block Storage. Pero esta configuración hacía que el clúster fuera muy sensible. Cualquier alteración en nuestras Cloud Networks podría provocar una desconexión de Cloud Block Storage, lo que colocaría a Cassandra en una situación complicada. Siempre podíamos recuperarnos de estos inconvenientes (esa es la razón por la que Cassandra es excelente), pero causaba que el equipo tuviera que trabajar innecesariamente.

También nos dimos cuenta de que con todo nuestro Cloud Block Storage, nuestro espacio era en realidad más costoso que un clúster de tamaño similar de nodos OnMetal I/O. A precios de mercado, el costo de nuestros servidores de 60 GB + 800 GB de Cloud Block Storage es aproximadamente de $2,050 al mes. Mientras tanto, el costo de un único nodo de OnMetal I/O sin Cloud Block Storage es aproximadamente de $1,780 al mes. Para nuestro clúster de 32 nodos, resulta que los ahorros ascienden a más de $100,000 al año.

El cambio a OnMetal

Esencialmente, realizamos un intercambio de los servidores Perfomance 2 a los nuevos OnMetal, uno por uno. Como OnMetal todavía no es compatible con Cloud Network, tuvimos que rehacer parcialmente el cableado en la configuración e iptables de Cassandra, pero esa fue la parte más complicada del cambio.

Al cambiar a Cassandra, nuestro desempeño mejoró drásticamente. Los gráficos mostrados a continuación se obtuvieron durante el periodo en el que cambiamos todo a OnMetal: compruebe las mejoras. La latencia de lectura y escritura de ClientRequest mejoró muchas veces. Los gráficos mostrados a continuación muestran la media y los percentiles de 95 y 99 para todas las lecturas y escrituras:

Como puede ver, es una mejora bastante drástica. La media y el percentil 99 para las lecturas mejora tres veces, mientras que el percentil 95 es prácticamente indistinguible de la media. Para las escrituras, pasamos de medir todo en milisegundos a medirlo todo en microsegundos.

Las mejoras no fueron realmente tan sorprendentes. En primer lugar, OnMetal tiene mejores características de desempeño que las máquinas virtuales que utilizábamos. En segundo lugar, nuestra antigua configuración Cassandra no era compatible con que Cloud Block Storage aumentara nuestro almacenamiento local. Con OnMetal, todo el almacenamiento se realiza en local en la caja y, prepárese, ¡el almacenamiento local es más rápido! Aun así, era positivo ver la confirmación de que estas máquinas, sin capa de virtualización y cuyo desempeño no se veía afectado por  vecinos ruidosos, nos ayuda a operar de forma mucho más eficiente.

Desafíos

El principal desafío que encontramos fue que un par de nodos de OnMetal se reiniciaban en momentos inesperados. Esto solo afectaba a un puñado de servidores, la mayoría de ellos en nuestro ambiente de pruebas. En esas ocasiones, le pedimos al equipo de OnMetal que pusiera a la máquina en modo de mantenimiento, de modo que no se reaprovisionara cuando la borráramos. Hasta el momento, eliminando un nodo incorrecto y acelerando uno nuevo ha solucionado nuestros problemas.

Como se trataba de un asunto bastante serio, trabajamos directamente con el equipo de OnMetal para aislar el problema. Afortunadamente, como Cassandra es maravillosamente resistente, una caja desconectada por 30 o 45 segundos mientras se reinicia no es grave, por lo tanto, dejamos un nodo de reinicio para poder investigar el problema. Al final, el equipo de OnMetal descubrió que una actualización del firmware del ventilador de mesa resolvía el problema. El último de nuestros servidores de reinicio lleva funcionando ininterrumpidamente durante las últimas semanas. El equipo de OnMetal ha implementado desde entonces el ajuste en todo el conjunto de servidores de OnMetal.

Lo único que echamos de menos de nuestra época de Performance Cloud es el acceso directo al control. Con nuestros antiguos servidores de nube pública, si había algún problema afectando a una máquina, siempre podíamos acceder a mycloud.rackspace.com y utilizar la aplicación de consola java para ese servidor. Como nuestro clúster de OnMetal ha sido muy estable, no lo hemos necesitado. Aun así, la falta de un plan B sigue preocupando a los miembros más precavidos del equipo.

¿Qué obtuvimos?

  1. Más confiabilidad: al eliminar nuestra dependencia del Cloud Block Storage y de Cloud Networks, redujimos la cantidad de servicios que podrían influir en nuestra operación. Además, nuestras máquinas de OnMetal tienen muchas menos posibilidades de verse afectadas por vecinos ruidosos, de modo que estas máquinas tienen más probabilidades de permanecer estables.
  2. Configuración más sencilla: en línea con lo anterior, sin Cloud Block Storage y Cloud Networks, toda nuestra infraestructura es más sencilla de configurar y mantener.
  3. Menores costos: en pocas palabras, es más barato. Ya lo sé, ¡es una locura! Obtiene hardware real y en vivo acelerado como si fuera un servidor en la nube, pero por menos dinero que el servidor en la nube correspondiente además de almacenamiento de bloques en la nube.
  4. Más desempeño: disponemos de más del doble de RAM actualmente e, incluso, aunque nuestros antiguos servidores tenían 16 núcleos virtuales para los 10 núcleos de los nodos OnMetal I/O, el desempeño de estas nuevas cajas rápidamente superó las antiguas.
  5. Más almacenamiento: incluso con Cloud Block Storage, solo aprovisionábamos 1.4 TB de almacenamiento por servidor. Los nodos OnMetal I/O tienen 1.6 TB, de modo que aumentamos nuestra capacidad 14%, sin siquiera intentarlo.

Por último, obtuvimos máquinas reales. No solo se trata de que sintamos nostalgia al recordar aquellos buena época anterior a la nube: la idea de que nuestros servidores son independientes es reconfortante, el hecho de que servidores enteros no estén supeditados al capricho y a la consideración de algún cruel hipervisor.

Hasta ahora, el impacto para el equipo de utilizar máquinas reales, en lugar de servidores virtuales es la misma diferencia que hay entre la noche y el día. Dedicamos menos tiempo a trabajar en nuestra infraestructura y más tiempo a trabajar en hacer avanzar nuestro producto. Tomaríamos esa decisión en cualquier momento, especialmente si ahorramos dinero en el proceso.

 

1 COMMENT

LEAVE A REPLY

Please enter your comment!
Please enter your name here