“Ustedes lo hacen tan intuitivo y demasiado fácil, me da confianza. ¿Por qué no puede ser todo tan fácil?
— Cliente anónimo
En mi primera post, nuestra discusión sobre actualizaciones terminó con algunas advertencias a tener en cuenta con respecto a la replicación. Esta vez profundizaremos en algunas cosas que golpean la tabla de éxito del cliente y la mejor manera de abordarlas.
Comencemos donde lo dejamos: control de versiones. A partir de la versión 5.0.1, Qumulo aplica una regla de dos trimestres en lo que respecta a la replicación (si recuerda el mes pasado, los lanzamientos trimestrales se designan con el tercer dígito como 0). Si observamos la versión 5.3.0, eso hablaría de dos trimestrales anteriores (5.1.0 y 5.2.0) y dos trimestrales posteriores (6.0.0 y 6.1.0). Es importante tener en cuenta que una liberación de puntos por encima de .0 no está dentro del rango. Usando nuestro ejemplo anterior de 5.3.0, 6.1.0 es el límite estricto ya que es trimestral. 6.1.1 es un estadio completamente nuevo en lo que respecta a la replicación y 5.3.0 se negará rotundamente a hablar con él.
Puede preguntarse, ¿cuáles son mis opciones si actualizamos inadvertidamente fuera de la ventana de dos trimestres? En este caso, deberá actualizar el lado de origen de la relación. En este sentido, a menudo se le pregunta al equipo de Éxito del Cliente de Qumulo, "¿debería pausar la replicación durante la actualización?" No señor, no debería. El motor de replicación es una cookie inteligente y se recuperará cuando finalice la actualización. Cuando se trata de actualizaciones y replicaciones, no hay nada más que hacerlo.
Otra pregunta que llega a los pasillos de Customer Success se relaciona con cambiar cosas en la fuente, como cambiar el nombre de un directorio fuente. Digamos, por ejemplo, que estamos replicando `/financials/current_fiscal' y queremos cambiarle el nombre a '/financials/FY2023'. ¿Terminaremos volviendo a replicar todos los datos? Gran negación allí. Dado que cambiamos el nombre, activará una verificación, pero en realidad no volverá a replicar nada. En cambio, en los registros de replicación, terminaría viendo que el valor 'Omitido' crece en tamaño como el "pequeño motor de replicación que podría" atravesar los datos y asegurarse de que no haya nada esperando para ser transferido.
¿Qué sucede si tiene una estructura de directorio de `/zoo/animals/mammals/capybara, pero solo desea configurar una política especial para 'mamíferos'? ¿Copiará la estructura de directorios por usted o necesito crear eso? Nuestro equipo de desarrollo lo estaba cuidando ese día: el motor de replicación de Qumulo creará los directorios anteriores para usted, recreando el árbol como '/zoo/animals/mammals/' en el destino a medida que la política entre en vigencia.
Detengámonos un momento y analicemos las políticas. ¿Necesito políticas instantáneas? De nada. Puede configurar una relación de replicación continua estándar sin necesidad de políticas. Si tiene o no sentido hacerlo sin una póliza es una decisión comercial. Sin embargo, normalmente recomendamos políticas, principalmente para propósitos de configuración extendida.
Con las políticas, puede configurar la replicación como "política+continua". Esto le dará la capacidad de tomar y transferir instantáneas en el origen en momentos específicos, así como también configurar la caducidad de la instantánea en el lado de destino. Sin una política, estará limitado a la instantánea de replicación única en el lado de destino (a menos que habilite la creación de instantáneas allí). A medida que aumenta la cantidad de replicaciones en su sitio de recuperación ante desastres, es probable que desee investigar la implementación de políticas si aún no lo ha hecho.
Finalmente, consideremos los usuarios locales y la replicación. Si tiene usuarios locales definidos en el clúster de origen, ¿necesita definir los mismos usuarios locales en el destino? Como práctica recomendada, debería hacerlo. El clúster hará referencia al UID de NFS si se establecieron permisos locales en los archivos. Al replicarlos, si el UID no está configurado en el lado de destino, el clúster no sabrá quién debe obtener los permisos, dejará de replicar y generará un error similar a
“ Último intento: /data/ no se puede replicar porque pertenece a un usuario local. Elimine todos los usuarios y grupos locales del archivo o asegúrese de que todos los usuarios y grupos locales tengan identificadores de NFS asociados y edite la relación para habilitar la asignación de identificadores locales a identificadores de NFS”.
También deberá comprobar los usuarios locales en el origen (Cluster -> Usuarios y grupos locales) y volver a crearlos en el destino. En la relación, deberá editarla en la casilla de verificación 'Asignar ID de usuario/grupo local a ID de NFS asociados'. El motor de replicación volverá a intentarlo automáticamente después de 60 segundos, por lo que siempre que haya hecho todo bien, la replicación se reanudará y seguirá funcionando.
Idealmente, esto ha disipado cierta confusión sobre la replicación y cómo se relaciona con su clúster de Qumulo. Como siempre, si tiene alguna pregunta, no dude en comunicarse con su canal de Slack, y su amable ingeniero de éxito del cliente de Qumulo estará encantado de ayudarlo. Vuelve pronto, y nos sumergiremos en el maravilloso mundo de las instantáneas.
Hasta la próxima!
