Cambios de configuración en un entorno en cluster

La mayor parte de la configuración del dispositivo se representa como propiedades de servicio o propiedades de recursos compartidos o LUN. Mientras que las propiedades de los recursos compartidos y los LUN se almacenan con los datos de usuario en la agrupación de almacenamiento (de manera que están siempre accesibles para el propietario actual del recurso de almacenamiento), la configuración de los servicios se almacena en cada nodo principal. Para garantizar que ambos nodos principales proporcionen un servicio coherente, es necesario sincronizar todas las propiedades de los servicios cuando se produce algún cambio o cuando uno de los nodos principales que estaba inactivo vuelve a unirse a su par. Como todos los servicios están representados por recursos de réplica, esta sincronización es realizada automáticamente por el software del dispositivo cada vez que se cambia una propiedad en alguno de los nodos principales.

Por lo tanto, no es necesario (y de hecho, es redundante) que los administradores repliquen los cambios de configuración. Los procedimientos operativos estándar deberían reflejar este atributo y requerir hacer cambios solamente en uno de los dos nodos principales del cluster una vez que se haya completado la configuración inicial. Tenga en cuenta también que el proceso de la configuración inicial del cluster replica la configuración existente en el par recientemente configurado. Por lo general, hay dos prácticas recomendadas para hacer cambios en la configuración de un cluster:

• Hacer todos los cambios de configuración relacionados con el almacenamiento y la red en el nodo principal que actualmente controla (o que controlará si se está creando un nuevo recurso) los recursos de almacenamiento o interfaz de red subyacentes.

• Hacer todos los demás cambios en uno de los nodos principales, no en los dos. La política del sitio debería especificar cuál de los nodos principales se debe considerar como el maestro en este aspecto, y, a su vez, debería depender de cuál de los nodos principales está funcionando y la cantidad de agrupaciones de almacenamiento que se han configurado. Tenga en cuenta que el software del dispositivo no hace esta distinción.

Se exagera mucho acerca de la incidencia del problema de la amnesia, que es cuando se hacen cambios de configuración separados en cada nodo y posteriormente se pierden cuando el par no está funcionando. Esto es particularmente así en Oracle ZFS Storage Appliance, que no tiene ningún mecanismo para hacer cambios independientes en la configuración del sistema de cada nodo principal. Esta simplificación alivia bastante la necesidad de tener repositorios de configuración centralizados y favorece un enfoque más simple: se supone que el nodo principal que está en funcionamiento en un momento dado tiene la configuración correcta, de manera que el par se sincroniza con ese nodo principal al iniciarse. Si bien puede haber mejoras futuras del producto que permitan la selección de una política alternativa para resolver divergencias de configuración, este enfoque básico es simple y fácil de comprender: el segundo nodo principal adopta un conjunto de parámetros de configuración que ya están en uso en el sistema de producción existente (y, por lo tanto, es muy probable que sean correctos). Para garantizar que esto sea siempre así, los administradores deben asegurarse de que el nodo principal que falle vuelva a unirse al cluster en cuanto se repare.