Wikitech

¡Has cargado una revisión antigua del documento! Si la guardas, crearás una versión nueva con estos datos.

====== Charla Ceph ======
===== CEPH: Vuelve a tener control sobre tu Storage =====
==== 1-2 Años de experiencia ====
==== Flexibilidad ====

* Puede suministrar:
    * Bloque mediante RBD 
      * Clonación.
      * Replicación.
      * Snap.
      * Exportación completa o de snap.
    * FS Cephfs
    * Objetos Ceph Object Gateway S3 API
    * NFS nfs-ganesha
    * ISCSI medianteCeph iSCSI Gateway

* Puede utilizar hardware heterogéneo:
    * Discos de diferentes tecnologías y tamaños
      * Añade un peso diferente a cada disco para que cada uno se llene en función de su capacidad.
    * CPU de diferente gama y edad
      * Según la potencia de la CPU en cada osd podemos crear pools replicados o ec-code y en cualquiera de los dos casos utilizar diferentes algoritmos de compresión.
      * EL almacenamiento se basa en pools pudiendo crearlos de diferentes calidades para que se adapten mejor al cometido del pool algunos tipos de etiqueta que hemos usado: HDD,SSD,NVME,SATA,SAS,15Krpm

* Ventajas de su diseño distribuido:  
    * Permite añadir, eliminar y actualizar nodos sin detener el servicio.
    * Permite definir dominios de fallo, para cada pool y en función de los dominios colocar los datos de una forma u otra, los dominios soportados son: osd, host, chassis, rack, row, pdu, pod, room, datacenter, region, root 
    * Si falla un dominio tolerado por un pool el cluster comienza a autorepararse clonando en otros discos las replicas necesarias de los datos.
    * Si falla un dominio pero no hay suficiente hardware para sanarse el cluster en modo degradado mantiene la entrada salida.
    * Si el número de replicas es insuficiente para considerar los datos seguros, la entrada salida se detiene, hasta que se crean suficientes réplicas para proteger la integridad de los datos.
  
  
  *Nuestro piloto
    * Hard
    * Soft
    * Uso
      * Backup
      * Backend virtualización
      * Almacenamiento tareas pesadas

==== Resumen ====

Con frecuencia las soluciones de almacenamiento de fabricante actuales tienden a ser extremadamente cerradas, lo que nos supone pérdida de control sobre la configuración, operación y monitorización de un punto crítico de nuestras infraestructuras. Para muchas de estas operaciones se requiere la intervención a través de un usuario privilegiado y secreto, haciendo uso de interfaces específicos de mantenimiento y utilizando comandos que no aparecen en la documentación de usuario. Todo lo que el fabricante nos ofrece muchas veces es un interface web agradable y las opciones que nos pueda aportar el botón derecho del ratón. Creemos que CEPH puede llegar a ser una alternativa para entornos Enterprise muy atractiva y que no solo cumple, sino que supera muchas veces las
funcionalidades que nos pueden dar otras soluciones de almacenamiento

El objetivo de esta charla hacer un pequeño resumen de nuestra experiencia utilizando el sistema de almacenamiento Ceph con la intención de animar a más Universidades a unirse al proyecto y crear una comunidad saludable, hasta ahora el sistema ha superado con creces nuestras expectativas.

Los servicios suministrados por esta solución SDS son: Bloque mediante RBD, permitiendo, clonación, replicación, snap, exportación completa o de snap. Sistema de archivos tanto nativo, Cephfs soportado por el kernel de Linux, como NFS utilizando la pasarela nfs-ganesha. Soporta acceso a objetos mediante API S3 usando la pasarela Ceph Object Gateway S3. Finalmente puede integrarse con productos compatibles con ISCSI mediante Ceph iSCSI Gateway.

Una de sus principales fortalezas es su diseño distribuido que nos ofrece la posibilidad de configurar distintos dominios de fallo, permitiendo de esta forma adaptar la distribución y replicación de nuestros datos en los pool de forma que sea tolerante a fallos en diferentes niveles como osd, host, chassis, rack, row, pdu, pod, room, datacenter, región, root. Esto se traduce en una alta disponibilidad y un rendimiento bastante razonable. Esta arquitectura permite actualizaciones hardware y de software sin degradar el cluster ni dejar de dar servicio en ningún momento, para los clientes es algo totalmente transparente.

Otro gran atractivo de esta tecnología es el gran grado de heterogeneidad que permite en el hardware. Gracias a esto podemos tener discos con diferentes tecnologías y tamaños pudiendo definir cómo se debe comportar con cada disco en función de estas características. Esto se traduce en un alto grado de disponibilidad y escalado. Permitiendo configurar el algoritmo de compresión en cada pool en función de la cpu disponible, o colocar una capa de "cache tier" sobre un pool que por su naturaleza pueda beneficiarse de esta tecnología.

Hardware utilizado:

- 3 SUPERSERVER SSG-6038R-E1CR16L SUPERMICRO 2x Intel® Xeon® Processor E5-2630 v4 16GB DDR4-2400 1Rx4 LP ECC REG RoHs
    - Proporcionando 40 hilos de procesamiento siendo recomendable un hilo por cada osd
    - en cada OSD tenemos 64 Gb de ram siendo recomendable 1Gb por cada demonio osd basado en HDD y 3Gb por cada osd basado en SSD
  -  NVMe INTEL DC P3700 400GB PCIE 3.0 HET MLC SSDPE2MD400G4
    - Proporciona particiones para block.db mejorando latencias
  - 3.5" SAS3 6TB 12Gb/s 7.2K 256MB Makara BP 512E ST6000NM0095
    - Cada servidor soporta 16 discos frontales y cada servidor soporta una bandeja de expansión sas
  - 10GB 4P STANDARD LP SFP+ INTEL XL710-AM1
    - Dos puertos para servicio y dos puertos para replicación ente nodos

- Algunos datos de rendimiento sobre HDD:
     * bench  type read io_size 4096 io_threads 16 bytes 1073741824 pattern random
        * ops:   262144  ops/sec: 11714.21  bytes/sec: 47981394.30
     * bench  type read io_size 65536 io_threads 16 bytes 1073741824 pattern random
        * ops:    16384  ops/sec:  9631.85  bytes/sec: 631233181.71
     * bench  type read io_size 1048576 io_threads 16 bytes 1073741824 pattern random
        * ops:     1024  ops/sec:  3778.55  bytes/sec: 3962094626.06

===== Charla Pandora/Selenium =====

* Años de experiencia monitorizando con pandora.
  * Alarmas no implican caída de servicio.
  * Caída de servicio puede no disparar alarmas.
  * Necesidad de una monitorización más cercana al comportamiento del usuario.
  * Dificultad para crear alarmas "inteligentes" antes de Selenium.
    * Wget
    * Jmeter
    * expect
  * Separación del monitor en Fases
  * Medidas realistas de rendimiento
  * Análisis del impacto en cambios de configuración
  * Valoración objetiva del rendimiento con diferentes arquitecturas.
  * Dificultades encontradas.
    * Problemas con algunos diseños web
    * Monitorización relativamente costosa para pruebas de carga

==== Resumen ====
En infraestructuras de cierta complejidad enseguida aparece la necesidad de tener algún servicio de monitorización para detectar problemas, tras crear el sistema de alarma aparece la necesidad de analizar las caídas de servicios, para ello necesitamos almacenar gran cantidad de datos de nuestros sistemas, al realizar una gran recopilación de datos no es necesario que todos estén alarmados, simplemente guardarlos para poder analizarlos en caso de necesidad. Alarmar innecesariamente crea demasiado "ruido".

Una de las mayores dificultades en monitorización es acercarse a la experiencia de usuario. Podemos tener un servicio con varias alarmas encendidas pero que el usuario no note nada o tener un servicio con todo en verde y que los usuarios llamen porque va lento o directamente no funciona.

La solución de monitorización que adoptamos hace ya varios años es Pandora fms, partíamos de multiples mecanismos muy dispares, productos,script propios, correos automáticos y se hacía necesario unificar todo para ver la salud de nuestros servicios de un solo golpe de vista.

Durante los últimos años hemos estado trabajando utilizando solamente esta tecnología haciendo uso de los 
agentes para la medición de parámetros de las máquinas y de las alarmas para 
controlar los contratiempos que pudieran aparecer. También un factor muy
importante que nos proporciona Pandora es tener una base de datos donde se
almacena todo lo que sucede en nuestros sistemas pudiendo de esta manera 
observar qué es lo que ha llevado a cabo la incidencia y como ha reaccionado 
nuestro sistema tras ésta.

Esta solución no es mala pero no provee de datos reales de rendimiento de, por
ejemplo, los servicios web. Se puede dar el caso de que se produzca una caida
pero esta no activar ninguna alarma. Es posible solucionar esto utilizando
servicios como **Wget**, **Jmeter** o **expect** si las las pruebas a las 
páginas web son sencillas.

Optar por programas mas completos como puede ser **Selenium** puede dar buenos
resultados ya que se puedeb obtener métricas reales de la experiencia de los
usuarios en nuestras páginas no solamente rendimiento como se podría hacer con 
los anteriormente mencionados.

Resumen de la edición

Nota: Al editar esta página, estás de acuerdo en autorizar su contenido conforme a la siguiente licencia: CC Attribution-Share Alike 4.0 International