Estimación y reducción del impacto de la toma de control

Hay un intervalo durante la toma de control y el failback durante el cual no se puede proporcionar acceso al almacenamiento para los clientes. La duración de este intervalo varía según la configuración, y los efectos exactos para los clientes dependen de los protocolos que utilizan para obtener acceso a los datos. La comprensión y la mitigación de estos efectos pueden marcar la diferencia entre una implementación de cluster exitosa y un fallo costoso en el peor momento posible.

Los clientes NFS (todas las versiones) normalmente no dejan que el software de la aplicación vea las interrupciones, lo que hace que las operaciones de E/S se demoren mientras el servidor no está disponible. NFSv2 y NFSv3 son protocolos sin estado que se recuperan casi de inmediato cuando se restaura el servicio. NFSv4 incorpora un período de gracia de cliente en el inicio durante el cual, generalmente, no se puede realizar E/S. La duración de este período de gracia se puede ajustar en Oracle ZFS Storage Appliance (consulte la ilustración); si se la reduce, se reduce el impacto evidente de la toma de control y el failback. Para interrupciones planificadas, Oracle ZFS Storage Appliance ofrece una recuperación sin período de gracia para clientes de NFSv4, lo cual evita la demora del período de gracia. Para obtener más información acerca de la recuperación sin período de gracia, consulte la propiedad de período de gracia en Propiedades de NFS.

Figura 10-10  Período de gracia en un cluster

El comportamiento de iSCSI durante las interrupciones de servicio depende del iniciador, pero los iniciadores normalmente se recuperan si el servicio se restaura dentro de un período de espera específico del cliente. Consulte la documentación de su iniciador para obtener información detallada adicional. El destino iSCSI normalmente puede proporcionar servicio tan pronto como se completa la toma de control, sin demoras adicionales.

SMB, FTP y HTTP/WebDAV son protocolos orientados a la conexión. Como los estados de sesión asociados con estos servicios no se pueden transferir junto con el almacenamiento y la conectividad de red subyacentes, todos los clientes que usan uno de estos protocolos se desconectan durante la toma de control o el failback y se deben volver a conectar después de que se completa la operación.

Si bien hay varios factores que afectan la duración de la toma de control (y su pariente cercano, la duración del failback), en la mayoría de las configuraciones, estos tiempos están dominados por el tiempo requerido para importar los recursos del conjunto de discos. Los tiempos de importación típicos para cada conjunto de discos varían entre 15 y 20 segundos y de manera lineal con respecto a la cantidad de conjuntos de discos. Tenga en cuenta que un conjunto de discos está formado por una mitad de un JBOD, siempre que los alojamientos de discos de ese medio JBOD se hayan completado y hayan sido asignadas a una agrupación de almacenamiento. Los discos no asignados y los alojamientos de discos vacíos no afectan la duración de la toma de control. El tiempo necesario para importar los recursos de un conjunto de discos no se ve afectado por los parámetros que pueden ser ajustados o alterados por los administradores, de manera que los administradores que están planificando implementaciones en clusters deben:

• limitar el almacenamiento instalado de manera que los clientes puedan tolerar los tiempos de toma de control asociados con ellos o bien;

• ajustar los valores de tiempo de espera en el cliente por encima del tiempo de toma de control máximo esperado.

Tenga en cuenta que, si bien la importación de los conjuntos de discos normalmente cubre el grueso del tiempo necesario para llevar a cabo la toma de control, no es el único factor en juego. Durante el proceso de importación de la agrupación, se deben volver a reproducir todos los registros del log de intención y se debe compartir cada recurso compartido y cada LUN mediante los servicios apropiados. La cantidad de tiempo requerida para realizar estas actividades para un único recurso compartido o LUN es muy pequeña (del orden de las decenas de milisegundos), pero si la cantidad de recursos compartidos es muy grande, puede representar una contribución importante para el tiempo total de la toma de control. Dado que se mantiene una cantidad relativamente pequeña de recursos compartidos (unos pocos miles o menos), se puede reducir considerablemente la duración del proceso.

La duración del failback suele ser mayor que la de la toma de control para cualquier configuración dada. Esto es así porque el failback es una operación de dos pasos: primero, el dispositivo de origen exporta todos los recursos de los que no es el propietario asignado y, a continuación, el dispositivo de destino realiza el procedimiento de toma de control estándar sobre los recursos que le fueron asignados solamente. Por lo tanto, siempre se necesitará más tiempo para hacer el failback del nodo A al nodo B para que el nodo A tome el control sobre el nodo B en caso de fallo. Este tiempo adicional necesario para failback depende mucho menos de la cantidad de conjuntos de discos que se exporta que el tiempo de la toma de control, de manera que una cantidad pequeña de recursos compartidos y LUN puede afectar más la duración del failback que la de la toma de control. También es importante tener presente que el failback es un proceso que siempre debe iniciar un administrador, de manera que se puede programar que la interrupción más prolongada que acarrea ocurra en un horario en el que el nivel de interrupción de las actividades de la empresa sea el menor posible.

Nota: Los tiempos estimados indicados en esta sección corresponden a la versión 2009.04.10,1-0 del software/firmware. Otras versiones pueden tener un rendimiento diferente; asimismo, el rendimiento real puede variar. Es importante hacer una prueba del proceso de toma de control para evaluar el impacto exacto que tiene en las aplicaciones de los clientes antes de implementar un dispositivo en clusters en un entorno de producción.