La mayor parte de la configuración del dispositivo se representa como propiedades de servicio o propiedades de recursos compartidos o LUN. Las propiedades de recursos compartidos y LUN se almacenan con los datos de usuario en la agrupación de almacenamiento para que el propietario actual de ese recurso de almacenamiento pueda acceder a ellas siempre, mientras que la configuración de los servicios se almacena en cada controlador. Para garantizar que ambos controladores proporcionen un servicio coherente, es necesario sincronizar todas las propiedades de los servicios cuando se produce algún cambio o cuando uno de los controladores 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 controladores.
Por lo tanto, es redundante e innecesario 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 controladores del cluster una vez que se haya completado la configuración inicial. El proceso de configuración inicial del cluster replica toda la configuración existente en el par recientemente configurado.
A continuación, se detallan las mejores prácticas para realizar cambios en la configuración en cluster:
Realizar todos los cambios de configuración de almacenamiento y red en el controlador que actualmente controla (o 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 controladores, no en los dos. El controlador que especifique como el controlador maestro debe depender de cuál de los controladores está funcionando y cuántas agrupaciones de almacenamiento se configuraron.
Oracle ZFS Storage Appliance no tiene ningún mecanismo para realizar cambios independientes en la configuración del sistema de cada controlador. Esta simplificación alivia la necesidad de tener repositorios de configuración centralizados. Se supone que el controlador en funcionamiento en un momento dado tiene la configuración correcta y su par se sincroniza con este al iniciarse. El par adopta un juego de parámetros de configuración que ya están en uso en el sistema de producción existente y, por lo tanto, es altamente probable que sean los parámetros correctos. La mejor práctica es comprobar que el controlador con el fallo vuelva a unirse al cluster tan pronto como se repare.
Temas relacionados