Poverty Among the Current Elderly

Ceph está diseñado para no tener un único punto de fallo, lo que significa que ante algún fallo de software o hardware debe ser capaz de recuperarse automáticamente sin interrumpir sus servicios, siempre que este no exceda el dominio de fallo. En Ceph esto se logra con la redundancia de servicios para el caso de los Ceph Monitors, los Ceph Managers y los servidores de metadatos Ceph, y con el factor de replicación para el caso de las pools en los OSDs. Tal y como se especificó en el capítulo anterior, en el presente trabajo, por el hecho de tener solo tres servidores disponibles para la implementación del clúster Ceph, el dominio de fallo está restringido a solo un servidor a la vez. O sea, que el clúster Ceph debe ser capaz de recuperarse como máximo a la caída de todos los servicios de un servidor a la vez. Si por alguna razón dejan de estar disponibles dos o más servicios del mismo tipo en diferentes servidores, el clúster Ceph dejará de estar operativo y por consecuencia el sistema de archivos Ceph no será accesible para lectura ni para escritura.

Para comprobar la estabilidad del clúster Ceph, se llevaron a cabo algunos experimentos que implican la caída de uno o varios servicios de Ceph, teniendo cuidado siempre de no superar el dominio de fallo. Esto se realizó con el objetivo de observar el comportamiento del sistema ante esta situación, comprobar si este era capaz de recuperarse completamente de forma automática mientras continuaba prestando servicios al clúster HPC y de mantener una calidad aceptable de los servicios. Todas las pruebas fueron realizadas sobre los servidores ceph1 y ceph2 porque son los que corren los cuatro servicios de Ceph (MON, MDS, MGR, OSD), para así simular las situaciones más críticas que el clúster Ceph implementado debe soportar.

El primer experimento fue apagar uno de estos dos servidores. En el momento de llevarlo a cabo se encontraba el servidor ceph1 activo como MDS y MGR, y el servidor ceph2 en espera para estos servicios. Entonces, se decidió apagar el servidor ceph1. Para comprobar que el clúster Ceph continúa prestando servicios, se inició un proceso de escritura y otro de lectura en uno de los nodos clientes. Automáticamente luego de apagar el servidor ceph1, Ceph mostró el estado HEALT_WARN como se esperaba (ver Anexo IV), con los mensajes:

 MDSs en espera insuficientes  2 OSDs inactivos (down)  1 servidor inactivo

 1 de 3 MONs inactivo

 Redundancia de datos degradada

Todos los grupos de ubicación fueron marcados como active+undersized+degraded, active+undersized o incomplete lo cual indica que están activos y disponibles, pero están degradados o incompletos porque no existe el número de réplicas adecuado para cada objeto. Unos segundos más tardes, comenzó el proceso de rebalanceo (como se puede observar en el anexo V), mostrándose progresivamente los grupos de ubicación con problema con el estado active+undersized+degraded+remapped+backfill, lo cual indica que los objetos degradados están siendo reubicados y replicados hasta alcanzar nuevamente el factor de replicación. Esto solo pasó con los objetos pertenecientes a la pool de metadatos (aproximadamente el 6% de los objetos), los cuales luego de aproximadamente 5 minutos pasaron al estado active+clean+remapped (ver Anexo VI). Debido a que la pool de datos es de tipo con códigos de borrado, con factor de replicación 3 y que en su perfil se especificó como dominio de fallo el servidor, no es posible reubicar los objetos pertenecientes a ella porque solo quedan dos servidores disponibles y no pueden existir dos réplicas del mismo objeto en el mismo servidor para este tipo de perfil. Por esto, los objetos pertenecientes a la pool de datos permanecieron en el estado active+undersized+degraded o active+undersized. Además, es preciso aclarar que luego de culminar el rebalanceo, Ceph indicó en su estado que aproximadamente el 6% de los objetos estaban fuera de lugar. Esto se debe a que los objetos reubicados de la pool de metadatos están replicados pero no están distribuidos correctamente de acuerdo al dominio de fallo.

Al observar los procesos de lectura y escritura (observable en el anexo V y VI en la sección client) se puedo verificar que el clúster Ceph permaneció dando servicio en todo momento, aún en estado degradado. Aunque en el momento del rebalanceo las razones de transferencia disminuyeron en un 40% aproximadamente y luego se mantuvieron disminuidas en un 20% aproximadamente con respecto al estado inicial.

Cuando el servidor ceph1 fue reiniciado, se observó que sus servicios Ceph se incorporaron al clúster nuevamente y que comenzó el proceso de recuperación (ver Anexo VII). Todos los grupos de ubicación con problemas pasaron al estado active+recovering+degraded y progresivamente fueron pasando al estado active+clean. Unos 5 minutos más tarde, el clúster

Ceph cambió su estado a HEALT_OK y todos los grupos de ubicación fueron marcados como active+clean, mostrando que se había recuperado completamente. Durante la recuperación los procesos de lectura y escritura también permanecieron con afectaciones mínimas en cuanto a las razones de transferencia, hasta que una vez recuperado el clúster tomaron sus valores iniciales.

El segundo experimento fue desconectar las interfaces de red del servidor ceph2 una a la vez, que en el momento de la prueba tenía los servicios de MDS y MGR como activos. Esta prueba tiene el objetivo de simular un corte en la red. Cuando se desconectó la interfaz de red perteneciente a la red de acceso, ocurrió exactamente lo mismo que en el experimento anterior. Para el caso de la interfaz de red perteneciente a la red del clúster, solo fueron marcados los 2 OSDs pertenecientes a ese servidor como inactivos y sus correspondientes grupos de ubicación como active+undersized+degraded semejante al caso anterior. Antes de que los OSDs fueran marcados como fuera del clúster y comenzara el rebalanceo, se reconectó la interfaz de red. En este caso no se obtuvo el resultado esperado, ya que luego de varios minutos se observaba que los 2 OSDs permanecían inactivos. Una minuciosa revisión mostró que el problema radicaba en que los servicios correspondientes a los OSDs se habían detenido y fue necesario reiniciarlos manualmente. Esto se debió a que el proceso de desconexión de la interfaz de red se realizó por software, inhabilitando la interfaz de red en el sistema operativo. Por el contrario, una desconexión física del cable de red no causó que los servicios relativos a los OSDs se detuvieran. Luego de reiniciarlos, los OSDs se incorporaron al clúster Ceph y comenzó el proceso de recuperación automática. Unos minutos más tardes el clúster había vuelto a la normalidad.

El tercer experimento fue detener selectivamente los servicios del clúster, teniendo en cuenta no sobrepasar el dominio de fallo, y reiniciarlos nuevamente. Esto se hizo para simular una caída inesperada de algún servicio de Ceph. Para detener e iniciar los servicios se usaron los comandos siguientes respectivamente:

$ systemctl stop {servicio} $ systemctl start {servicio}

Donde {servicio} se sustituye por el servicio en cuestión. En esta prueba, la recuperación del clúster ocurrió de forma automática en todos los casos como se esperaba y Ceph mostró

los mensajes de error correspondientes a cada servicio en cada caso. Cuando se detenía un servicio, su homólogo en espera pasaba a activo y cuando el servicio se reiniciaba se incorporaba al clúster sin problemas. Es necesario aclarar que Ceph no reinicia los servicios detectados con problema automáticamente, cuando el administrador del sistema detecta este tipo de errores el servicio debe ser reiniciado manualmente.