Esta es la segunda parte de un artículo en dos partes que se adentra en los detalles de la tecnología de reequilibrio de Couchbase. La página primera parte trata la mecánica básica y los antecedentes del proceso de reequilibrio. En esta segunda parte, veremos más detenidamente cómo supervisar el proceso de reequilibrio y cómo detener y solucionar los problemas de reequilibrio.
Seguimiento de un reequilibrio
Aparte de la supervisión general de un Membase/Couchbase, hay algunas áreas específicas en las que centrarse durante un reequilibrio. La mayoría de ellos pueden ser monitoreados a través de la interfaz web, y más específicamente capturados mirando las estadísticas subyacentes disponibles en cada nodo.
- Puede controlar de cuántos (y cuáles) vbuckets es responsable un nodo determinado y utilizarlo para hacerse una idea del progreso de un reequilibrio.
- Ya sea debido a un "relleno" masivo o a lecturas puntuales para materializar los datos en la RAM antes de enviarlos al nodo de destino.
- Combinado con la carga de tráfico normal, un reequilibrio puede resultar en un gran aumento de la cola de escritura en disco, ya que los datos se transfieren a la RAM más rápido de lo que pueden ser drenados al disco. (*ver más abajo un bug/defecto de diseño que se está solucionando actualmente).
- Deberías ver bastante actividad aquí, y puede ser 'explosiva' cuando un vbucket se mueve de un lugar a otro.
- Es fundamental para entender por qué un reequilibrio puede estar tardando más de lo esperado. Verás estas compensaciones asociadas con el nodo de destino (porque está registrando cuántas ha enviado... a diferencia del nodo de origen al que se le está diciendo que haga una compensación).
¿Por qué tarda tanto mi reequilibrio?
Los clientes me preguntan a menudo cuánto tiempo debería llevar un reequilibrio, y tengo que decirles constantemente que en realidad no lo sé. Depende mucho de la cantidad de datos (número y tamaño de los objetos individuales), de la velocidad del disco (tanto de lectura como de escritura) y de la carga de la red... por no hablar de la posibilidad de que se produzcan fallos en los nodos y otras ralentizaciones inesperadas a lo largo del proceso.
En lugar de intentar cuantificar de forma fiable cuánto tardaría un reequilibrio en condiciones cada vez más variables, me parece mucho más importante poder caracterizar y controlar su estado. Como ya se ha dicho, lo ideal es que un reequilibrio no tenga un impacto material en la aplicación, por lo que no importa cuánto tarde. Si se percibe un impacto, será más importante entender por qué (y posiblemente resolverlo) que intentar acelerar el proceso de reequilibrio en sí.
La causa más común de la lentitud general es un disco lento en el nodo de destino que provoca retrocesos de TAP.
*Bicho actual/defecto de diseño: En las versiones 1.7.1.1 e inferiores, un nodo puede empezar a borrar datos antiguos del disco mientras aún está en proceso de recibir datos nuevos. En nuestras pruebas iniciales, se demostró que este borrado no lleva mucho tiempo. En realidad, hemos descubierto que bajo ciertas condiciones (especialmente EC2 de Amazon) puede tardar mucho más de lo esperado. Desafortunadamente, un nodo no puede realizar estos borrados (en masa) y escribir al mismo tiempo y eso puede acabar 'matando de hambre' al proceso de escritura. Esto conduce a una cola de escritura en disco muy grande y, finalmente, a un período prolongado de retrocesos de TAP. Aunque no es catastrófico, puede ser desconcertante para el usuario en términos de un tiempo de reequilibrio muy extendido y posible temor por la seguridad de los datos. El comportamiento está siendo (o ha sido) corregido con la versión 1.7.2 para evitar que se produzca esta situación.
Rendimiento durante un reequilibrio
Por diseño, un reequilibrio no debería tener un impacto material en el rendimiento de la aplicación. En realidad, sin embargo, una operación de reequilibrio aumenta la carga global y la utilización de recursos de un sistema, por lo que ciertos entornos pueden notar una degradación. Nuestra mejor práctica es realizar un reequilibrio durante los niveles de tráfico más bajos de una aplicación, si es posible.
Las dos causas principales de un golpe de rendimiento durante el reequilibrio son la saturación de la red y la contención del disco. Aunque la utilización de la CPU es otra causa posible, es muy poco frecuente que sea la única causa, salvo en los casos de mayor tráfico (varios cientos de miles de operaciones por segundo), y suele estar relacionada con alguna causa subyacente (como la espera de E/S de disco).
La saturación de la red debería ser bastante obvia. Si su aplicación ya está empujando el clúster cerca de su ancho de banda de red, un reequilibrio es probable que cause más saturación que puede conducir a tiempos de espera y errores. Actualmente no permitimos (pero puede que lo hagamos en el futuro) limitar la actividad de red de un reequilibrio.
La contención de disco es un poco más difícil de ver y caracterizar. Esto se remonta a uno de los principales beneficios de Membase/Couchbase Server, la separación de RAM de IO de disco. Al servir tanto como sea posible desde la RAM, el software enmascara cualquier ralentización a nivel de IO de disco. El disco es normalmente mucho más lento que la RAM, pero cuando se le pide una mayor carga a un disco, se vuelve aún más lento. El reequilibrio es una de esas cargas incrementadas. Si tu aplicación está leyendo todos sus datos de la RAM, no deberías ver ningún impacto aquí. Sin embargo, si muchas peticiones (y "muchas" es subjetivo) están siendo atendidas desde el disco porque no están almacenadas en caché en la RAM, el rendimiento puede y va a sufrir. Puedes mitigar esto teniendo más RAM, pero eso no siempre es práctico y a veces es sólo cuestión de ser consciente de lo que está pasando.
Detener un reequilibrio
Como cada vbucket se mueve individualmente, un reequilibrio puede detenerse (ya sea manualmente o por algún fallo) sin tener que rehacer todo el proceso. Basta con reiniciar el reequilibrio y se retomará desde donde se dejó.
Hay dos advertencias al respecto, dado el estado actual del software:
- Si está eliminando nodos con un reequilibrio, y ese reequilibrio se detiene, necesita volver a eliminar los nodos antes de iniciar de nuevo el reequilibrio. El clúster no "recuerda" lo que hiciste la última vez, así que es importante recordárselo.
- Es una buena práctica esperar al menos 5 minutos antes de reiniciar un reequilibrio (independientemente de por qué se detuvo). Esto es para permitir que las distintas conexiones entre nodos se limpien correctamente. Las versiones posteriores del software impondrán este límite (a través de la interfaz de usuario web, se puede anular mediante el uso de la CLI / REST API si se desea ... pero no lo hagas a menos que te lo digamos ;-)
Si un reequilibrio se detiene en medio del movimiento de un vbucket en particular (como es probable), no hay nada de qué preocuparse. Ese movimiento en particular se "cancela" simplemente dejando activo el vbucket original. No se necesita nada más.
Fallos de reequilibrio
¿Qué debe hacer cuando falla un reequilibrio? Lo ideal es reanudar el reequilibrio en poco tiempo si tiene sentido (de nuevo, espere al menos 5 minutos). Esto depende mucho de la naturaleza del fallo. Cuando se produce un fallo de reequilibrio, debe intentar averiguar la causa y también el estado actual del clúster.
Aunque, por supuesto, nos esforzamos por corregir todos los errores del software, inevitablemente habrá situaciones en las que un reequilibrio falle. Los dos motivos más comunes son los tiempos de espera o los fallos.
Un tiempo de espera se genera cuando un nodo en particular tarda en responder (o no responde en absoluto después de un periodo de tiempo) y normalmente se debe a la lentitud de la red o del disco. También verás un timeout si un nodo falla, pero sólo si lo hace de forma que la otra parte no pueda averiguar qué ha pasado. En este último caso, un tiempo de espera puede enmascarar algún otro problema más grave.
Un fallo (ya sea de un proceso interno como memcached o de algún componente externo del sistema como el kernel) también provocará un fallo en el reequilibrio.
Los registros tendrán algo de información (con suerte una cantidad sustancial) sobre el fallo en sí. Dirán algo como "timeout" (lo mismo que "wait for memcached failed") o "some process exited unexpectedly". Aunque se trata de información útil, especialmente para que el soporte la investigue, la causa es mucho menos importante que el estado actual del clúster.
Antes de reanudar el reequilibrio, debe evaluar inmediatamente si es necesario tomar medidas adicionales. El diagnóstico principal consiste en determinar si todos los nodos del clúster siguen en buen estado y pueden servir datos. Si es así, perfecto. Si no, primero hay que remediar esa situación. No voy a abordar esta actividad más general de solución de problemas aquí, pero se entiende la idea. Puedes estar seguro de que los datos están a salvo (y de que es posible una conmutación por error si es necesario).
Resumen
Si has seguido este artículo, y el primer mensaje sobre el reequilibrio entonces sabes casi todo lo que hay que saber sobre el proceso de reequilibrio. Más importante aún, ahora deberías estar en posición de hacer una conjetura educada sobre los efectos y necesidades de hacer un rebalanceo y cómo esto afectará tus despliegues y operaciones de tus clusters de Couchbase y Membase.
