solución de problemas de ceph rgw

Aquí, me gustaría resumir las fallas relacionadas con ceph rgw que normalmente encuentro y los métodos de manejo correspondientes. Esto le ayudará a encontrar una solución rápida y eficiente la próxima vez que se encuentre con un problema similar. Recopilaré las fuentes de los casos de fallas de varios canales, como: mi propio entorno, sitio web oficial, comentarios de amigos del grupo, etc.

También publicaré algunos casos de fallas en el grupo para que todos puedan discutir y comunicarse juntos en el grupo.

A veces, también publico algunos casos de falla en el grupo para que todos puedan discutir y comunicarse juntos en el grupo.

Ocasionalmente, los clientes de radosgw (como s3cmd) experimentan retrasos al interactuar con radosgw y radosgw responde a las solicitudes muy lentamente.

Primero, verifiquemos si hay algún problema con el cliente y la red del clúster. Podemos obtener la información interna de radosgw a través del socket de gestión del demonio radosgw. Vaya al nodo donde se encuentra la instancia de radosgw y ejecute el siguiente comando:

En el campo Ups generado por el comando anterior, puede ver que hay dos solicitudes, una es la solicitud con tid 1858, y la otra es la solicitud con solicitud tid 1873. Tomemos como ejemplo la solicitud con tid 1858. La información de la solicitud es la siguiente:

El campo last_sent indica la hora en que se envió la solicitud a rados. Si la diferencia entre esta hora y la hora actual es grande, significa que rados no responde a la solicitud enviada a rados, lo que hace que radosgw no pueda responder a la solicitud del cliente (s3cmd), por lo que el s3cmd del cliente se retrasará.

Bien, sabemos el motivo y luego continuamos mirando el campo osd, que indica a qué osd radosgw enviará esta solicitud. Como puede ver arriba, se envía al osd.1. , pg Es 2.d2041a48, y luego ejecutamos

Puedes ver que la copia principal de esta página es osd.1, luego ingresamos al nodo donde se encuentra osd.1 y ejecutamos el comando

Arriba en la información, podemos encontrar la información de la solicitud con tid 1858, y luego podemos ver el campo flag_point. Esperar suboperaciones significa que estamos esperando una respuesta de otra réplica de osd.0.

Ahora sabemos que es porque osd.0 no respondió al mensaje principal de osd.1, lo que provocó que todo io se atascara. Porque existe la posibilidad de que osd.0 no responda al mensaje. muy alto, por lo que debería basarse en la situación real. Investiguemos por qué osd.0 no respondió al mensaje principal de osd.1.