Gestión de recursos de clusters

El gestor de recursos es responsable de garantizar que se haya conectado el conjunto 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 nodos principales en clusters. La mayoría de las actividades de este subsistema son invisibles para los administradores. Sin embargo, hay un aspecto importante que queda expuesto. 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 por clase de recurso; por ejemplo, una interfaz de red pertenece a la clase neta y está activa cuando se levanta la interfaz. Los tres tipos más importantes de recursos son único, privado y réplica.

Las réplicas son el tipo más simple: no se exponen nunca a los administradores y no aparecen en la pantalla de configuración del cluster (ilustración 4). Las réplicas existen siempre y están siempre activas en ambos nodos principales. Normalmente, estos recursos simplemente actúan como contenedores de propiedades de servicio que se deben sincronizar entre los dos nodos principales.

Al igual que las réplicas, los recursos únicos se utilizan para sincronizar el estado, pero están siempre activos en exactamente uno de los nodos principales. Los administradores pueden elegir el nodo principal en el que cada recurso único normalmente debe estar activo; si ese nodo principal presenta un fallo, el par importa el recurso único. Los recursos únicos son la clave para las características de disponibilidad de la agrupación en clusters: son los recursos que los usuarios se suelen imaginar como que pasan de un nodo principal que falló al par superviviente e 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 conjunto de servicios de almacenamiento, es fundamental que se asigne a cada interfaz el mismo nodo principal que los clientes de la agrupación de almacenamiento esperan ver al acceder a las direcciones de esa interfaz. En la ilustración 4, todas las direcciones asociadas con la interfaz PrimaryA siempre serán provistas por el nodo principal que importó pool-0, mientras que las direcciones asociadas con PrimaryB siempre serán provistas por el mismo nodo principal que pool-1.

Los recursos privados son conocidos solo por el nodo principal al que se asignan y nunca se toma el control de ellos al producirse un fallo. Esto suele resultar útil solo para las interfaces de red. Consulte el siguiente análisis de casos de uso específicos.

Figura 2-22  Ejemplo de agrupación en clusters ZS3-2

Hay otros tipos de recursos, pero son detalles de implementación que no se muestran a los administradores. Uno de estos tipos es el simbionte, que permite a un recurso seguir a otro cuando se importa y exporta. El uso más importante de este tipo de recursos es para la representación de los discos y los dispositivos flash de la agrupación de almacenamiento. Estos recursos se conocen como conjuntos de discos y se deben importar siempre antes de la agrupación ZFS que contienen. Cada conjunto de discos está formado por la mitad de los discos de un contenedor de almacenamiento externo. Un sistema de almacenamiento en cluster puede tener conectada la cantidad de conjuntos de discos que se desee (según lo que admita el hardware), y cada agrupación ZFS se forma a partir de los dispositivos de almacenamiento de uno o varios conjuntos de discos. Como los conjuntos de discos pueden contener dispositivos ATA, se deben importar y exportar explícitamente para evitar ciertos comportamientos relacionados con la afiliación específicos de los dispositivos ATA que se utilizan en entornos de rutas múltiples. La representación de los discos como recursos proporciona una manera simple de realizar estas actividades en el momento correcto. Cuando un administrador configura o cambia el propietario de una agrupación de almacenamiento, la asignación del propietario de los conjuntos de discos asociados con la agrupación se cambia de manera transparente al mismo tiempo. Como todos los simbiontes, los recursos de los conjuntos de discos no aparecen en la interfaz de usuario de la configuración del cluster.

Tabla 2-36  Gestión de recursos de clusters

Recurso ícono Omnipresente Toma de control cuando hay un fallo ÚNICO No Sí RÉPLICA Ninguno Sí N/D PRIVADO No No SIMBIONTE Ninguno Mismo tipo que el principal Mismo tipo que el principal

Cuando se crea un nuevo recurso, inicialmente se lo asigna al nodo principal en el que se está creando. El propietario no se puede cambiar a menos que el nodo principal se encuentre en el estado AKCS_OWNER. Por lo tanto, es necesario crear recursos en el nodo principal que debería ser su propietario o tomar el control antes de cambiar la propiedad del recurso. Por lo general, es posible destruir los recursos de cualquier nodo principal, pero no se pueden destruir las agrupaciones de almacenamiento que se exportan. Los mejores resultados normalmente se obtienen destruyendo recursos en el nodo principal que los controla en ese momento, sin importar qué nodo principal 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 nodos principales. Por lo tanto, nunca es necesario configurar estos parámetros en ambos nodos principales, independientemente del estado del cluster. Si un dispositivo no está funcionando cuando se hace el cambio de configuración, se replicará en el otro cuando se vuelva a unir al cluster en el siguiente inicio, antes de proporcionar servicios. Existen algunas excepciones:

• Las definiciones y las opciones de recursos compartidos y LUN se pueden configurar solo en el nodo principal que tiene el control de la agrupación subyacente, sin importar cuál sea el nodo principal al que se suele asignar la agrupación.

• La configuración del servicio "Identity" (Identidad) (es decir, el nombre y la ubicación del dispositivo) no se replica.

• Los nombres proporcionados al chasis son visibles solo en el nodo principal al que fueron asignados.

• Cada ruta de red está vinculada a una interfaz específica. Si cada nodo principal 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 nodos principales. Consulte la sección sobre consideraciones para redes si desea obtener información más detallada.

• Las claves de host SSH no se replican y nunca se comparten. Por lo tanto, si no se ha configurado ninguna interfaz administrativa privada, se puede esperar que haya discrepancias en las claves al intentar iniciar sesión en la CLI con una dirección asignada a un nodo que ha fallado. Las mismas limitaciones se aplican a los certificados SSL utilizados para acceder a la BUI.

Así, el modelo básico es que la configuración común se replica de manera transparente, y los administradores asignan una recopilación de recursos a cada nodo principal del dispositivo. Esas asignaciones de recursos a su vez forman la vinculación 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.