Ceph

Secuencia de escritura

El cliente conoce los monitores que figuran en el fichero de configuración ceph.conf. Contacta con uno para conseguir una copia actualizada del «Cluster Map». Este mapa global contiene la topología del cluster Ceph, repartida en 5 mapas específicos: el mapa de los monitores, el mapa de los OSD, el mapa de los PG («Placement Groups«), el mapa CRUSH y el mapa MDS (MetaData Server).

El cliente elige en qué «pool» (grupo) va a escribir. Cada pool define el número de PGs y una regla CRUSH.

Empleando el algoritmo CRUSH («Controlled Replication Under Scalable Hashing»), el cliente sabe en que PG guardar los objetos (cada uno con su identificador) correspondientes a la información que desea almacenar. A partir del PG, puede calcular (hash del identificador del objeto, módulo el número de PGs del pool) la ubicación del objeto, POOL_ID.PG_ID. Cada ubicación es servida por un conjunto de demonios OSDs (dispositivos de almacenamiento de objetos). Al conjunto se le denomina «Acting set». Dentro del «Acting set», el demonio «primario» es al que el cliente realmente envía los datos a escribir. El primario se encarga además de coordinar el consenso («peering») con los demás demonios respecto al estado de todos los objetos del PG (con sus metadatos). También se encarga de gestionar la redundancia de los datos de los objetos (tanto réplicas como codificación con corrección)

Dentro de cada OSD, los objetos se organizan en un espacio de nombres plano (sin jerarquía). Cada objeto, además de los datos (binarios) en sí, tiene un identificador (único en todo el cluster Ceph) y metadatos (conjunto de claves-valor)

Rebalanceo

Cuando se incorpora un OSD al cluster Ceph, la mayoría de los PGs permanecen en sus OSD originales, mientras otros cambian, a fin de equilibrar el reparto de los PG entre los OSD.

Repaso

Periodicamente (una vez al día), los OSDs comparan los metadatos de sus objetos con los de otros OSDs. El repaso profundo compara el contenido de los objetos, byte a byte (típicamente, una vez a la semana)

Codificación con corrección (CC, «Erasure Coding (EC)»)

La redundancia dentro de un «pool» puede hacerse por réplica o por CC.

Con CC, cada objeto se divide en K bloques de datos («data chunks») y M bloques de codificación («coding chunks»). Los bloques de datos se reparten la información original, mientras los bloques de codificación permiten reconstruir la información original en caso de que se pierda el acceso a alguno de los bloques (como máximo, tantos bloques inaccesibles como M). El orden de los bloques se guarda en el atributo shard_t de los metadatos del objeto.

Las escrituras de cada bloque de datos son asíncronas: a medida que cada OSD completa el almacenamiento del bloque de datos que le toca, actualiza su registro de cambios (log) local y avisa al OSD primario. Si todo ha ido bien, cada OSD dispone de la última versión de los bloques que conforman el objeto, con lo cual se pueden eliminar los bloques (ficheros) que guardaban la versión anterior de cada bloque (si la había).

Si el OSD primario se cae, uno de los OSD disponibles (que no sea parte ya del «acting set») le reemplaza en el PG y se revisan los logs locales de cada OSD, a fin de que el estado del objeto sea consistente.

Para cada «pool» se puede escoger qué algoritmo utilizar para la codificación con corrección: Reed-Solomon, jerasure…

El espacio neto disponible con EC se calcula mediante la siguiente fórmula:

c = nOSD * k / (k+m) * tamaño OSD

Por ejemplo, con 64 OSD de 4 TB cada uno, 4 bloques de datos y 2 de codificación, sería 170 TB. Con 10 bloques de datos y 1 de codificación, sería 232 TB. Lo ideal es buscar un equilibrio entre el mayor espacio neto posible y el menor riesgo. Cuanto mayor sea el factor datos:codificación, mayor el aprovechamiento, pero también la probabilidad de que fallen más bloques de los que la codificación permite reconstruir.

Documentación relacionada: Erasure coding notes, Erasure coding overhead.

Estados OSD

Up/Down/Failed (activo o en fallo)
In/Out (dentro o fuera del cluster)

Estados de los PG

Peering: «poniendo de acuerdo» a todos los OSD del PG sobre el estado de los objetos (datos y metadatos) / Active (los datos están disponibles en el PG primario y sus réplicas)
/ activating / not active
Clean: los PG están replicados el número de veces esperado / Degraded: al menos 1 OSD del PG no está operativo / Down: el PG no está disponible / Recovering: uno de los OSD del PG se está sincronizando a partir de las réplicas
Undersized: el PG tiene menos copias de las requeridas
Backfilling: los OSD que se han añadido al PG están recibiendo datos del resto, para que la carga se reparta entre todos los OSD del PG
Remapped: se está cambiando de OSD primario
Stale: el OSD primario del PG no está operativo
Inconsistent: alguna de las réplicas tiene inconsistencias
Scrubbing / deep
Creating