Calamares u otros cachés HTTP con SSD Cache Store?

Estoy contemplando configurar un caché de calamar (o posiblemente barniz) en un sistema con unidades SSD.

El beneficio obvio es que estos sistemas tienen grandes velocidades de LECTURA y espero que mis índices de aciertos sean bastante altos.

Supongamos que puedo poner 7 SSD en una configuración RAID. (Hay algunos casos que me permitirán empacar mucho, mucho más)

Preguntas de implementación:

• ¿Debo usar RAID0? (Espero que una unidad falle con el tiempo, así que esto parece peligroso).

• ¿Debo usar RAID10? (Esto reduce a la mitad la huella de mi disco, lo cual es costoso).

• ¿Debo usar RAID5? (Se sabe que los SSD tienen un rendimiento de escritura "malo" y límites de escritura, y todas las escrituras de paridad adicionales pueden ralentizar esto considerablemente).

• ¿Debo tratar cada disco como su propio almacén de datos de calamar? (¿Qué tan bien maneja el calamar múltiples almacenes de datos? ¿Y qué sucede si / cuando falla uno?)

• ¿Debo ignorar los almacenes de datos y simplemente hacer los SSD en grandes particiones SWAP y dejar que la VM de Linux haga lo suyo? (parece descuidado)

Cualquier consejo de personas que usan SSD en entornos de producción sería muy apreciado. (especialmente si los estás usando para cachés HTTP)

Hemos estado usando barniz en unidades ssd durante los últimos 9 meses, ha funcionado extremadamente bien para nosotros. Anteriormente utilizamos un caché de memoria de calamar solo con una capa de carpa. Funcionó, pero la fragmentación de la memoria era un problema real que requería reinicios frecuentes. Squid 2.x también solo usará un núcleo, lo que lo hace bastante ineficiente en el hardware actual.

Para nuestro sitio, que es muy amigable con la caché, vemos aproximadamente un 10% de uso de CPU en una máquina de 8 núcleos que atiende 100Mbit / s de tráfico. En nuestras pruebas nos quedamos sin ancho de banda antes de alcanzar los límites de la CPU con 2 puertos de 1 Gb.

Tengo algunos consejos para ejecutar barniz con un caché ssd.

• El rendimiento de escritura aleatoria realmente importa. Probamos varios proveedores de unidades ssd antes de instalarnos en el intel x-25m. Hemos visto algunas publicaciones tan pequeñas como .1MB / s para 4k escrituras aleatorias, obtenemos 24MB / s 4k escrituras aleatorias con el x-25m.

• Raid0. El caché en 2.0 no es persistente, por lo que no debe preocuparse por la redundancia. Esto hace que los reinicios duelan, pero son raros. Puede hacer cosas como cargar una nueva configuración y purgar objetos sin reiniciar.

• modo mmap El caché de barniz se puede mapear en un archivo o usar espacio de intercambio. El uso de intercambio no ha funcionado bien para nosotros, tiende a usar más ancho de banda de E / S para atender la misma cantidad de tráfico. Hay un encabezado de 4 sectores en el código de intercambio de Linux, escribimos un parche para eliminar esto pero no lo hemos probado en producción.

• Programador de plazos. Con 2.6.28+ esto es consciente de SSD y funciona bien. Intentamos noop pero descubrimos que la fecha límite era más justa ya que el ancho de banda de E / S se limita.

• Desactivar lectura anticipada. Como no hay demora rotacional, no tiene sentido leer datos adicionales solo porque los necesite. El ancho de banda de E / S es valioso en estas cosas.

• Ejecute 2.6.28+. mmap de mucho espacio en linux le da al administrador de memoria un buen entrenamiento, pero los parches lru divididos ayudan mucho. El uso de la CPU kswapd disminuyó mucho cuando lo actualizamos.

Hemos publicado nuestro archivo vcl, así como varias herramientas que utilizamos con barniz en el texto del enlace . El vcl también incluye un hack limpio que implementa un servidor geoiplookup muy rápido basado en la base de datos maxmind.

No estoy usando SSD como cachés HTTP, pero puedo hacer estas observaciones:

No todos los SSD son iguales, por lo que debe tener mucho cuidado al elegir los decentes. FusionIO fabrica SSD respaldados por PCIe que son realmente de alto rendimiento (con capacidad relativamente baja), pero costosos. Las SSD X25-E SLC de Intel funcionan muy bien y son más asequibles, pero aún de baja capacidad. ¡Haz tu investigación! Definitivamente puedo recomendar las variantes X25-E SLC, ya que las estoy usando en sistemas de producción.

Existen otros SSDS que pueden brindarle una gran velocidad de lectura / escritura secuencial, pero lo importante para algo como un caché es la E / S aleatoria, y muchos SSD brindarán aproximadamente el mismo rendimiento aleatorio que los discos giratorios. Debido a los efectos de amplificación de escritura en SSD, los discos giratorios a menudo funcionarán mejor. Muchos SSD tienen controladores de baja calidad (p. Ej., Controladores JMicron más antiguos), que pueden sufrir un rendimiento significativamente degradado en algunas situaciones. Anandtech y otros sitios hacen buenas comparaciones con herramientas como iometer, verifique allí.

Y, por supuesto, los SSD son pequeños. El Intel X25-E, que diría que es el mejor SSD SATA que he visto, solo viene en variantes de 32 y 64 GB.

Para los niveles RAID, todavía se aplican las notas de rendimiento RAID estándar. Básicamente, escribir en un RAID 5 implica leer el bloque de datos que va a modificar, leer el bloque de paridad, actualizar la paridad, escribir el bloque de datos y escribir la paridad, por lo que aún tendrá un rendimiento peor que otros RAID niveles, incluso con SSD. Sin embargo, con unidades como el X25-E que tienen un rendimiento de E / S aleatorio tan alto, esto probablemente sea menos importante, ya que seguirá superando a las E / S aleatorias en discos giratorios para una matriz de tamaño similar.

Por lo que he visto, el ancho de banda del controlador RAID se satura demasiado pronto para obtener el mayor beneficio de un conjunto RAID de 7 discos, al menos en lo que respecta al rendimiento secuencial. No puede obtener más de aproximadamente 800 MB / s de los modelos actuales de controladores SATA (3ware, areca, etc.). Tener arreglos más pequeños, en múltiples controladores (por ejemplo, varios RAID1 en lugar de un solo RAID10) mejorará esto, aunque el rendimiento individual de cada arreglo se verá afectado.

Con respecto a un caché HTTP, creo que sería mejor servirlo con una buena variedad de discos giratorios y mucha memoria RAM. Los objetos a los que se accede con frecuencia permanecerán en la memoria caché, ya sea en la memoria caché interna de squid o en la memoria caché fs de su sistema operativo. Simplemente dar una máquina más ram puede reducir significativamente la carga del disco debido a esto. Si está ejecutando un caché de calamar grande, probablemente querrá mucho espacio en disco, y los SSD de alto rendimiento todavía solo tienen una capacidad relativamente baja.

No estoy muy familiarizado con las unidades SSD, pero puedo hablar sobre el tipo de arquitectura que he usado que puede ayudar a resolver algunos de sus problemas.

Hermanos

En mi caso, construí cuatro servidores con 16 GB de RAM cada uno. Configuré 9GB como el caché en memoria para que Squid lo use. Los configuré como un conjunto de hermanos para que una consulta a un servidor consultara a los demás antes de buscar los datos. En total, tenía 36 GB de memoria caché. No superaría a cuatro hermanos ya que la comunicación entre ellos comienza a empantanarse.

VIPs

Configuré un VIP para los cuatro servidores para que el cliente hable. Esto resolvió lo que sucede cuando un servidor deja de funcionar.

Niños

Configuré mi aplicación web para consultar un servidor Squid local que se ejecuta en 127.0.0.1. Luego configuró el padre de esta instancia de Squid para ser el VIP. Esto permite una conmutación por error muy rápida en caso de que todo el VIP se caiga. Si los padres no responden, el niño consulta los servicios directamente. También es útil si está utilizando un único servidor Squid y no tiene un VIP. Por supuesto, si la instancia local de Squid en su servidor web se cae, todo se detiene.

Calamar

Realmente no he mirado 3.0, pero 2.x todavía es de un solo subproceso. En algún momento te quedarás sin memoria intermedia de CPU o TCP. Extendería el caché en 2-3 cajas menos si fuera posible. También es posible que desee hacer planes para particionar sus granjas de Squid en el futuro si ve que el sistema está creciendo.

En cualquier caso, buena suerte con su construcción SSD. Me interesa saber cómo resulta, ya que probablemente seguiré esa ruta en el futuro.

¿Por qué estás considerando la incursión 10 o 5.? Quieres rendimiento aquí. No le importa si las unidades simplemente se caen, ya que es solo un caché.

Solo usa el raid 0 o mantenlos separados. Creo que por separado sería mejor, ya que un fallo de la unidad no eliminaría todo el caché.

La documentación de Squid recomienda no usar RAID sino configurar directorios de caché adicionales en discos adicionales.