PowerScale: Isilon: OneFS: Después de la actualización, es posible que se vean impactos en el rendimiento de un trabajo posterior a la actualización.

Como parte de las actualizaciones de OneFS, se debe realizar una migración necesaria y obligatoria de nuestra versión anterior del diseño de inodos a una nueva versión; no hay manera de aplazar o evitar esta migración.  Esto afectará a todos los archivos de su clúster OneFS, incluidos el espacio de usuario (/ifs) y todos los archivos de tipo de sistema.

Este procedimiento comienza después de que se "confirma" la actualización del clúster de OneFS en el proceso de actualización.

La gran escala de este trabajo en algunos escenarios e implementaciones puede causar problemas transitorios de rendimiento.
 

Después de confirmar una actualización de OneFS, un trabajo del sistema de tipo actualización que actualiza el sistema de archivos después de una actualización de versión de software se iniciará automáticamente y se debe permitir su ejecución hasta su finalización.  Si hay cambios en la estructura de inodos entre las versiones de OneFS de la actualización, el trabajo de actualización realizará cambios en la estructura de inodos en cada archivo.  Cuando esto ocurre, el trabajo de actualización en ejecución puede causar problemas de rendimiento temporales debido al aumento de IOPS necesarios para realizar cambios en la estructura de inodos.  Esto se puede mitigar cambiando la política para el trabajo de actualización a Baja desde el valor predeterminado actual de Medio.

¿Qué sistemas pueden verse afectados?

Durante esto, literalmente todos los archivos de la plataforma de almacenamiento se migrarán rápidamente a la nueva versión de inodo. El ritmo general de las actualizaciones observadas en el laboratorio en todas las plataformas de hardware y el uso de la política de trabajo predeterminada pueden llegar hasta decenas de millones de objetos de archivos generales por hora. Tenga en cuenta que los "archivos" en este contexto no se refieren solo a los archivos "cargados por el usuario", como verá, por ejemplo, en sus cuotas e informes. Esto también incluye todos los archivos y objetos en el nivel del sistema. 

Una vez que la migración está en curso, como se ve como un trabajo en la CLI denominada "Actualización" que se ejecuta bajo la política media predeterminada, existe la posibilidad de que un clúster isilon vea problemas de rendimiento temporales y transitorios mientras se produce esta actualización. A partir de la cantidad limitada de informes que hemos observado, parece que la migración de inodos de actualización puede tomar en una escala de horas a días en función de una política media.

Esto se puede mitigar cambiando la política para el trabajo de actualización del valor predeterminado actual de Medio a Bajo.

Si se observan impactos en el rendimiento, para mitigarlos, cambie la política del trabajo de actualización de Medio a Bajo. Cambiar la política a Baja reduce el impacto general que tiene el trabajo mientras se ejecuta, pero aumenta el tiempo que tarda en completarse.
 

Para cambiar la política de un trabajo de actualización actualmente en ejecución a Bajo, ejecute el siguiente comando:

Para cambiar la política de futuros trabajos de actualización a Baja, ejecute el siguiente comando:

Nota: Este trabajo es una parte clave de este tipo de actualización en particular. Si bien cosas como la prioridad del trabajo se pueden modificar, el requisito absoluto de que se ejecuta este trabajo no se puede modificar. Si el "trabajo" de alguna manera se cancela o falla, se reanuda nuevamente. Los cambios de inodo deben completarse.