Gestión de recursos de clusters
El gestor de recursos es responsable de garantizar que se haya conectado el juego correcto de interfaces de red, que estén activas las agrupaciones de almacenamiento correctas y que los numerosos parámetros de configuración permanezcan sincronizados entre dos controladores en clusters. La mayoría de las actividades de este subsistema son invisibles para los administradores. Sin embargo, se expone un aspecto importante. Los recursos se clasifican en varios tipos que dictan si el recurso se importa (se hace activo) y, de ser así, cuándo se hace. Tenga en cuenta que la definición de ''activo'' varía según la clase de recurso. Por ejemplo, una interfaz de red pertenece a la clase neta y se activa cuando se abre la interfaz.
Los tres tipos de recursos más importantes son réplica, único y privado:
-
Recursos de réplica: las réplicas son el tipo de recurso más simple; no se exponen nunca a los administradores y no aparecen en la pantalla de configuración del cluster. Las réplicas existen siempre y están siempre activas en ambos controladores. Normalmente, estos recursos simplemente actúan como contenedores de propiedades de servicio que se deben sincronizar entre los dos controladores.
-
Recursos únicos: al igual que las réplicas, los recursos únicos se utilizan para sincronizar el estado. Sin embargo, se encuentran siempre activos en exactamente uno de los controladores. Los administradores pueden elegir el controlador en el que cada recurso único debe estar activo. Si se produce un fallo en ese controlador, su par importa el recurso único. Los recursos únicos son clave para las características de disponibilidad de la agrupación en clusters. Los únicos son los recursos que los usuarios suelen imaginar que pasan de un controlador con fallos al par superviviente. Estos incluyen las interfaces de red y las agrupaciones de almacenamiento. Como una interfaz de red es una recopilación de direcciones IP utilizadas por los clientes para encontrar un juego conocido de servicios de almacenamiento, es fundamental que se asigne a cada interfaz el mismo controlador que los clientes de la agrupación de almacenamiento esperan ver al acceder a las direcciones de esa interfaz.
-
Recursos privados: los recursos privados son conocidos solo por el controlador al que se asignan, y nunca se toma el control de ellos al producirse un fallo. Normalmente, esto es útil solamente para las interfaces de red. Consulte el siguiente análisis de casos de uso específicos.
Otro tipo de dato es el simbionte. Un simbionte permite que un recurso siga a otro cuando se importa y se exporta. Por ejemplo, se utiliza un simbionte para representar los discos y los dispositivos flash de la agrupación de almacenamiento.
En la siguiente figura, se muestra un ejemplo de una configuración en cluster con recursos compartidos.
Figura 4 Ejemplo de configuración en cluster de ZS3-2
En la tabla siguiente, se describen las características de los diferentes tipos de recursos de cluster.
|
Cuando se crea un nuevo recurso, inicialmente se lo asigna al controlador en el que se está creando. No se puede cambiar el propietario, a menos que ese controlador se encuentre en el estado AKCS_OWNER. Por lo tanto, es necesario crear recursos en el controlador que debería ser su propietario o tomar el control antes de cambiar la propiedad del recurso. En general, es posible destruir los recursos de cualquier controlador, pero no se pueden destruir las agrupaciones de almacenamiento que se exportan. Normalmente, los mejores resultados se obtienen cuando se destruyen los recursos en el controlador que los controla en ese momento, sin importar qué controlador es el propietario asignado.
La mayoría de los parámetros de configuración, incluidas las propiedades de los servicios, los usuarios, los roles, las reglas de asignación de identidad, las reglas de directorio raíz automático de SMB y las definiciones de iniciador iSCSI se replican automáticamente en ambos controladores. Nunca es necesario configurar estos parámetros en ambos controladores, independientemente del estado del cluster. Si un dispositivo no funciona cuando se realiza el cambio de configuración, el cambio se replicará en el otro dispositivo cuando este se vuelva a unir al cluster en el siguiente inicio, antes de proporcionar servicio. Existen algunas excepciones:
-
Las definiciones y las opciones de recursos compartidos y LUN se pueden configurar únicamente en el controlador que tiene el control de la agrupación subyacente, sin importar cuál sea el controlador al que se suele asignar la agrupación.
-
La configuración del servicio de identidad (el nombre y la ubicación del dispositivo) no se replica.
-
Los nombres proporcionados al chasis son visibles solo en el controlador al que fueron asignados.
-
Cada ruta de red está vinculada a una interfaz específica. Si cada controlador tiene asignada una interfaz cuya dirección está en una subred en particular, y esa subred contiene un enrutador al que los dispositivos deben dirigir el tráfico, se debe crear una ruta para cada interfaz, aun cuando se utilice la misma dirección de puerta de enlace. Esto permite que cada ruta pueda estar activa individualmente cuando el control de los recursos de red subyacentes cambie entre los dos controladores. Para obtener más información, consulte Consideraciones de la agrupación en clusters para redes.
-
Las claves de host SSH no se replican y nunca se comparten. Por lo tanto, si no se configuró ninguna interfaz administrativa privada, se pueden esperar discrepancias en las claves al intentar iniciar sesión en la CLI con una dirección asignada a un nodo que falló. Las mismas limitaciones se aplican a los certificados SSL utilizados para acceder a la BUI.
El modelo básico implica que la configuración común se replica de manera transparente y los administradores asignan una recopilación de recursos a cada controlador del dispositivo. Esas asignaciones de recursos forman el enlace de las direcciones de red para los recursos de almacenamiento que los clientes esperan ver. Independientemente de cuál sea el dispositivo que controla la recopilación de recursos, los clientes pueden acceder al almacenamiento que necesitan en las ubicaciones de red que esperan.
Temas relacionados