1. Internet

iSeries
Cómo configurar un clúster
iSeries
Cómo configurar un clúster
© Copyright International Business Machines Corporation 1998, 2001. Reservados todos los derechos.
Contenido
Capítulo 1. Cómo configurar un clúster . . . . . . . . . . . . . . . . . . . . . . . . 1
Lista de comprobación de configuración de clústers . . . . . . . . . . . . . . . . . . . . 2
Descripciones de las API de clúster . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Capítulo 2. Versión actual del clúster . . . . . .
Ejemplo: configuración de clúster de dos nodos. . .
Ejemplo: configuración de clúster de cuatro nodos . .
Ejemplo: configuración de clúster de disco conmutado
.
.
.
de
. .
. .
. .
dos
. . .
. . .
. . .
nodos
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
Capítulo 3. Consejos sobre aplicaciones de clúster de alta disponibilidad . .
Cómo obtener partido del reinicio de aplicaciones de clúster de alta disponibilidad
Escritura de una aplicación de clúster de alta disponibilidad . . . . . . . . .
Llamada a un programa de salida de un grupo de recursos de clúster . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
. . . .
. . . .
. . . .
. . . .
. 7
. 7
. 8
. 10
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
11
12
12
Capítulo 4. Versión actual del clúster . . . . . . . . . . . . . . . . . . . . . . . . 15
Capítulo 5. Direcciones IP para CRG de aplicación . . . . . . . . . . . . . . . . . . . 17
Capítulo 6. Parámetros ajustables de comunicaciones de clúster . . . . . . . . . . . . . 19
Capítulo 7. Configuración de dispositivos resilientes . . . . . . . . . . . . . . . . . . 21
© Copyright IBM Corp. 1998, 2001
iii
iv
iSeries: Cómo configurar un clúster
Capítulo 1. Cómo configurar un clúster
IBM y los business partners de middleware de clúster han trabajado en equipo para proporcionar
innovadoras funciones de servicios de recursos de clúster junto con una interfaz gráfica de usuario (GUI)
para la gestión de clústers. Los servicios de recursos de clúster de OS/400 proporcionan un conjunto de
servicios integrados que mantienen la topología del clúster, realizan la función de latido y permiten la
creación y administración de la configuración del clúster y de grupos de recursos de clúster. Los servicios
de recursos de clúster también proporcionan funciones de mensajería fiables que llevan a cabo el
seguimiento de cada nodo del clúster y aseguran que todos los nodos tengan información coherente
sobre el estado de los recursos del clúster. Además, los servicios de recursos de clúster proporcionan un
conjunto de interfaces de programa de aplicación (API) y recursos que pueden utilizar los clientes y los
suministradores de aplicaciones de iSeries para mejorar la disponibilidad de sus aplicaciones. Si desea
una lista completa de las API de servicios de recursos de clúster disponibles, consulte el apartado
Descripciones de las API de clúster.
Los servicios de recursos de clúster también proporcionan un conjunto de mandatos de ejemplo en
QUSRTOOL, que se correlacionan con las API mencionadas anteriormente. Los mandatos QUSRTOOL
pueden ser de utilidad en algunos entornos. Por ejemplo, puede configurarse fácilmente un clúster para
probar las aplicaciones habilitadas para clúster. Consulte el miembro TCSTINFO del archivo
QUSRTOOL/QATTINFO para obtener más información sobre estos mandatos de ejemplo.
El apartado Ejemplos de configuración de clúster proporciona algunos ejemplos de configuraciones de 2 y
4 nodos. Lea también los consejos sobre aplicaciones para obtener información sobre cómo escribir una
aplicación o un programa de salida de alta disponibilidad para la aplicación.
Puede crear o puede comprar un programa de aplicación para crear un clúster, supervisar el estado y
llevar a cabo otras operaciones de clúster, así como su administración. Si sólo va a utilizar un clúster de
disco conmutado de 2 nodos, en lugar de ello puede utilizar la interfaz IBM Simple Cluster Management,
disponible a través de Operations Navigator y suministrada como parte de la Opción 41 de OS/400.
Al comienzo de la configuración de un clúster, debe determinar cuáles son todos los atributos del clúster
que debe especificar, como:
v Nodos del clúster (los sistemas iSeries que forman el clúster)
v Versión actual del clúster
v Recursos del clúster (objetos resilientes y aplicaciones resilientes)
v Políticas de clúster (pueden hacer referencia a conmutación por anomalía y conmutación por
administración)
v Grupos de recursos de clúster
v Direcciones IP para CRG de aplicación
v Nivel de ajuste para mensajes de clúster
Importante: Consulte la Lista de configuración de clústers para obtener detalles sobre cómo configurar el
entorno para clústers.
Para crear un clúster, debe tener acceso a, al menos, uno de los sistemas del clúster. Debe incluir al
menos un sistema en el clúster. Si sólo se especifica un sistema, debe ser el sistema al que tiene acceso
actualmente.
Consulte el apartado Business partners de middleware de clúster para averiguar qué business partners
participan y qué productos están disponibles para ayudarle con la configuración y gestión de clústers en el
servidor iSeries. Si necesita ayuda durante el proceso de configuración, consulte el apartado A quién
llamar para obtener ayuda, donde se proporciona un número al que llamar.
© Copyright IBM Corp. 1998, 2001
1
Lista de comprobación de configuración de clústers
Utilice esta lista de comprobación para asegurarse de que está preparado para configurar clústers en el
entorno.
Requisitos de TCP/IP
____
____
____
____
____
____
____
____
Requisitos de dispositivo resiliente
____
____
____
2
iSeries: Cómo configurar un clúster
TCP/IP debe estar iniciado en todos los nodos elegidos
para formar parte del clúster (STRTCP).
La dirección TCP de retorno de bucle (127.0.0.1) debe
estar configurada y debe mostrar el estado ’Activo.’
Verifíquelo utilizando NETSTAT en todos los nodos del
clúster.
Las direcciones IP utilizadas para el clúster en un nodo
determinado deben mostrar el estado ’Activo.’ Verifíquelo
utilizando NETSTAT en el nodo indicado.
Todas las direcciones IP de clúster deben estar definidas
con máscaras de subred de bits contiguos.
El estado del perfil de usuario QUSER debe ser
Habilitado.
INETD debe estar activo en todos los nodos del clúster
(STRTCPSVR *INETD). Puede verificarse mediante la
presencia de un trabajo QTOGINTD (Usuario QTCP) en la
lista de trabajos activos del nodo indicado.
El nodo local y los nodos remotos existentes deben poder
realizar una operación PING utilizando las direcciones IP
utilizadas para el clúster para asegurar que el
direccionamiento de red esté activo.
Los puertos 5550 y 5551 están reservados para clústers
IBM y no deben utilizarse para otras aplicaciones. La
utilización de puertos puede visualizarse utilizando
NETSTAT. La agrupación en clúster abrirá el puerto 5550
y lo situará en estado de ’Escucha’ una vez que se inicie
INETD.
Si los dispositivos resilientes deben conmutarse entre
particiones lógicas de un sistema, Virtual OptiConnect
debe estar habilitado para las particiones. Esto se efectúa
en el inicio de sesión de herramientas de servicio
dedicado (DST).
Si una torre de un bucle HSL se conmuta entre dos
sistemas, y uno de ellos tiene particiones lógicas, HSL
OptiConnect debe estar habilitado para las particiones.
Esto se efectúa en el inicio de sesión de herramientas de
servicio dedicado (DST).
Cuando se conmutan dispositivos resilientes entre
particiones lógicas que se encuentran en un bus de
sistema, el bus debe estar configurado como ″bus de
propiedad compartida″ por una partición, y todas las
demás particiones que van a participar en la conmutación
de dispositivo deben estar configuradas como ″bus de
uso compartido″.
____
____
____
Requisitos de seguridad
____
____
____
Consideraciones sobre trabajos
____
____
Cuando se conmuta una torre de un bucle HSL entre dos
sistemas diferentes, la torre debe estar configurada como
conmutable.
Cuando se añade una torre a un bucle HSL existente,
todos los sistemas de dicho bucle deben reiniciarse.
Debe estar instalada la opción 41 de OS/400 (Recursos
conmutables HA) y debe existir una clave de licencia
válida en todos los nodos del clúster que van a figurar en
el dominio de dispositivo. Tenga en cuenta que cualquier
utilización del programa de utilidad IBM Simple Cluster
Management requiere esta opción.
El atributo de red ALWADDCLU (Permitir añadir a clúster)
debe estar establecido adecuadamente en el nodo
destino si se intenta iniciar un nodo remoto. Debe
establecerse en *ANY o *RQSAUT dependiendo del
entorno. Si se establece en *RQSAUT, deben estar
instalados la opción 34 de OS/400 (Gestor de certificados
digitales) y Cryptographic Access Provided Product (AC2
o AC3).
El perfil de usuario que llama a las API de servicios de
recursos de clúster debe existir en todos los nodos del
clúster y debe tener la autorización *IOSYSCFG.
El perfil de usuario necesario para ejecutar el programa
de salida de un grupo de recursos de clúster (CRG) debe
existir en todos los nodos del dominio de recuperación.
Los trabajos pueden someterse mediante las API de
servicios de recursos de clúster para procesar las
peticiones. Los trabajos se ejecutarán bajo el perfil de
usuario que ejecuta el programa de salida especificado al
crear el grupo de recursos de clúster o bajo el perfil de
usuario que ha solicitado la API (para activar dispositivos
sólo en CRG de resiliencia de dispositivos). El usuario
debe asegurarse de que el subsistema que efectúa el
servicio a la cola de trabajos asociada con el perfil de
usuario está configurado como: *NOMAX para el número
de trabajos que puede ejecutar desde esa cola de
trabajos.
Los trabajos se someterán a la cola de trabajos
especificada por la descripción de trabajo obtenida del
perfil de usuario definido para un CRG. La descripción de
trabajo por omisión provocará que los trabajos se envíen
a la cola de trabajos QBATCH. Dado que esta cola de
trabajos se utiliza para muchos trabajos de usuario, puede
que el trabajo del programa de salida no se ejecute en el
tiempo esperado. Los usuarios deben considerar la
posibilidad de utilizar una descripción de trabajo exclusiva
con una cola de usuario exclusiva.
Capítulo 1. Cómo configurar un clúster
3
____
Cuando se ejecuten trabajos de programa de salida, éstos
utilizarán datos de direccionamiento de la descripción de
trabajo para elegir la agrupación de almacenamiento
principal y los atributos de tiempo de ejecución que van a
utilizar. Los valores por omisión provocarán que los
trabajos se ejecuten en una agrupación con otros trabajos
por lotes con una prioridad de ejecución 50. Ninguna de
estas condiciones producirá el rendimiento deseado para
los trabajos de programa de salida. El subsistema que
inicia los trabajos de programa de salida (el mismo
subsistema que está utilizando la cola de trabajos
exclusiva) debe asignar los trabajos de programa de
salida a una agrupación que no estén utilizando otros
trabajos iniciados por el mismo u otros subsistemas.
Además, a los trabajos de programa de salida debe
asignárseles una prioridad de ejecución 15, para que se
ejecuten antes que casi todos los demás trabajos de
usuario.
Consideraciones sobre el programa de utilidad IBM Simple Cluster Management
____
Debe estar instalada la opción 41 de OS/400 (Recursos
conmutables HA) y debe existir una clave de licencia
válida en todos los nodos del clúster que van a figurar en
el dominio de dispositivo.
____
Todos los servidores de sistema principal deben estar
iniciados: STRHOSTSVR SERVER(*ALL)
____
El servidor *MGTC debe haberse iniciado: STRTCPSVR
SERVER(*MGTC)
Descripciones de las API de clúster
Las tablas siguientes muestran el nombre y una breve descripción de las API de control de clúster y las
API de grupo de recursos de clúster que están disponibles. Para obtener más información sobre las
funciones que realizan estas API y por qué puede ser interesante utilizarlas, consulte el apartado API de
clúster.
Tabla 1. Descripciones de las API de control de clúster
Nombre de la API de control de clúster
Añadir Entrada de Nodo de Clúster
(QcstAddClusterNodeEntry)
Añadir Entrada de Dominio de Dispositivo
(QcstAddDeviceDomainEntry)
Ajustar Versión de Clúster
(QcstAdjustClusterVersion)
Cambiar Entrada de Nodo de Clúster
(QcstChangeClusterNodeEntry)
Cambiar Servicios de Recursos de Clúster
(QcstChgClusterResourceServices)
Crear Clúster (QcstCreateCluster)
4
iSeries: Cómo configurar un clúster
Descripción
Añade un nodo a la lista de miembros de un clúster ya existente.
También asigna las direcciones de interfaz IP que deben utilizar las
comunicaciones de clúster.
Añade un nodo a una lista de miembros de dominio de dispositivo
para que pueda participar en acciones de recuperación para
dispositivos resilientes. La adición del primer nodo a un dominio de
dispositivo tiene el efecto de crear dicho dominio de dispositivo.
Ajusta la versión de clúster actual al siguiente nivel, por ejemplo, para
que una función nueva pueda utilizarse dentro del clúster.
Cambia los campos de la entrada del nodo de clúster. Por ejemplo,
pueden cambiarse las direcciones de interfaz IP utilizadas para las
comunicaciones de clúster.
Ajusta el rendimiento del clúster y los parámetros de ajuste de
configuración para que coincidan con el entorno de comunicaciones
de la red utilizada para las comunicaciones de clúster.
Crea un clúster nuevo de uno o más nodos.
Nombre de la API de control de clúster
Suprimir Clúster (QcstDeleteCluster)
Descripción
Suprime un clúster existente. Los servicios de recursos de clúster
finalizan en todos los nodos de clúster activos y se eliminan del
clúster.
Finalizar Nodo de Clúster
Finaliza los servicios de recursos de clúster en un nodo o en todos
(QcstEndClusterNode)
los nodos de la lista de miembros de un clúster ya existente. Esto
hará que el nodo no esté disponible para el clúster hasta que no se
reinicie con la API Iniciar Nodo de Clúster.
Listar Información de Clúster
Recupera información sobre un clúster. Por ejemplo, puede
(QcstListClusterInfo)
devolverse la lista completa de miembros de clúster.
Listar Información de Dominio de Dispositivo
Lista información de dominio de dispositivo de un clúster. Por
(QcstListDeviceDomainInfo)
ejemplo, puede devolverse la lista de los dominios de dispositivo
definidos actualmente.
Eliminar Entrada de Nodo de Clúster
Elimina un nodo de la lista de miembros de un clúster. El nodo se
(QcstRemoveClusterNodeEntry)
elimina de todos los dominios de recuperación, las operaciones de
clúster finalizan en el nodo y todos los objetos de servicios de
recursos de clúster se suprimen del nodo.
Eliminar Entrada de Dominio de Dispositivo
Elimina un nodo de una lista de miembros de dominio de dispositivo.
(QcstRemoveDeviceDomainEntry)
Si se trata del último nodo del dominio de dispositivo, esta acción
también suprime el dominio de dispositivo del clúster.
Recuperar Información de Clúster
Recupera información sobre un clúster. Por ejemplo, se devuelven el
(QcstRetrieveClusterInfo)
nombre y la versión actual del clúster.
Recuperar Información de Servicios de
Recupera información sobre los parámetros de configuración y ajuste
Recursos de Clúster (QcstRetrieveCRSInfo)
de rendimiento de los servicios de recursos de clúster.
Iniciar Nodo de Clúster (QcstStartClusterNode) Inicia los servicios de recursos de clúster en un nodo que forma parte
de un clúster pero que en este momento no está activo. Esta API
debe llamarse en un nodo que esté activo en ese momento en el
clúster.
Tabla 2. Descripciones de las API de grupo de recursos de clúster
Nombre de la API de grupo de recursos de
clúster
Añadir Entrada de Dispositivo de Grupo de
Recursos de Clúster
(QcstAddClusterResourceGroupDevice)
Añadir Nodo a Dominio de Recuperación
(QcstAddNodeToRcvyDomain)
Cambiar Grupo de Recursos de Clúster
(QcstChangeClusterResourceGroup)
Cambiar Entrada de Dispositivo de Grupo de
Recursos de Clúster
(QcstChangeClusterResourceGroupDev)
Crear Grupo de Recursos de Clúster
(QcstCreateClusterResourceGroup)
Suprimir Grupo de Recursos de Clúster
(QcstDeleteClusterResourceGroup)
Distribuir Información
(QcstDistributeInformation)
Finalizar Grupo de Recursos de Clúster
(QcstEndClusterResourceGroup)
Descripción
Añade una entrada de dispositivo nueva a un grupo de recursos de
clúster. El dispositivo pasa a ser miembro del grupo de dispositivos
conmutables.
Añade un nuevo nodo al dominio de recuperación de un grupo de
recursos de clúster ya existente. Un nodo puede añadirse como nodo
primario (si el CRG está inactivo), como nodo de reserva o como
nodo de réplica.
Cambia los atributos de un grupo de recursos de clúster. Por ejemplo,
puede modificarse la dirección IP de toma de control para un CRG de
aplicación.
Cambia una entrada de dispositivo de un grupo de recursos de
clúster. Por ejemplo, puede modificarse la opción de activar el objeto
de configuración en la conmutación por administración o por
anomalía.
Crea un objeto de grupo de recursos de clúster. El objeto de grupo
de recursos de clúster identifica un dominio de recuperación, que es
un conjunto de nodos del clúster que jugarán un papel en la
recuperación.
Suprime un grupo de recursos del clúster. El objeto CRG se suprimirá
de todos los sistemas activos en el dominio de recuperación.
Distribuye información desde un nodo del dominio de recuperación de
un CRG a otros nodos del dominio de recuperación de dicho CRG.
Inhabilita la resiliencia del grupo de recursos de clúster especificado.
Cuando esta API finaliza satisfactoriamente, el estado del grupo de
recursos de clúster se establece en inactivo.
Capítulo 1. Cómo configurar un clúster
5
Nombre de la API de grupo de recursos de
clúster
Iniciar Conmutación por Administración
(QcstInitiateSwitchover)
Listar Grupos de Recursos de Clúster
(QcstListClusterResourceGroups)
Listar Información de Grupo de Recursos de
Clúster (QcstListClusterResourceGroupInf)
Eliminar Entrada de Dispositivo de Grupo de
Recursos de Clúster
(QcstRemoveClusterResourceGroupDev)
Eliminar Nodo de Dominio de Recuperación
(QcstRemoveNodeFromRcvyDomain)
Iniciar Grupo de Recursos de Clúster
(QcstStartClusterResourceGroup)
Descripción
Provoca la realización de una conmutación administrativa para el
grupo de recursos de clúster. El dominio de recuperación cambia de
modo que el nodo primario actual pasa a ser el último de reserva, y
el primer nodo de reserva actual pasa a ser el nuevo primario.
Genera una lista de los grupos de recursos de clúster e información
sobre el grupo de recursos de clúster del clúster.
Devuelve el contenido de un objeto de grupo de recursos de clúster.
Por ejemplo, puede devolverse el dominio de recuperación con las
funciones de nodo actuales.
Elimina una entrada de dispositivo de un grupo de recursos de
clúster. El dispositivo ya no será un recurso conmutable.
Elimina un nodo del dominio de recuperación de un grupo de
recursos de clúster ya existente. El nodo ya no participará en la
acción de recuperación de ese grupo de recursos.
Habilita la resiliencia del grupo de recursos de clúster especificado. El
grupo de recursos de clúster pasa a estar activo dentro del clúster.
Si desea utilizar una interfaz simplificada como ayuda para crear y gestionar un clúster, utilice el programa
de utilidad IBM Simple Cluster Management, utilice los mandatos de clúster de ejemplo de QUSRTOOL o
consulte el apartado Business partners de middleware de clúster para obtener información sobre a quién
debe dirigirse para adquirir productos de clúster.
6
iSeries: Cómo configurar un clúster
Capítulo 2. Versión actual del clúster
Para crear un clúster que incluya nodos de varios niveles de versión de clúster, son necesarios
determinados pasos al crear el clúster. Por omisión, la versión actual del clúster se establecerá en la
versión potencial de clúster del primer nodo añadido al clúster. Este método es adecuado si este nodo
está en el nivel de versión más bajo que puede aceptar el clúster. Sin embargo, si este nodo está en un
nivel de versión posterior, como consecuencia no podrán añadirse nodos con un nivel de versión anterior.
La alternativa es utilizar el valor de la versión de clúster destino de la creación del clúster para establecer
la versión actual del clúster en la versión potencial de clúster del primer nodo añadido al clúster, menos
uno.
Por ejemplo, considere un caso en el que debe crearse un clúster de tres nodos. Los nodos de este
clúster son:
Identificador de nodo
Release
Versión potencial de clúster
Nodo A
V4R4
1
Nodo B
V4R5
1
Nodo C
V5R1
2
Si el clúster debe crearse desde el nodo C, debe tener cuidado de indicar que va a tratarse de un clúster
de release mixto. La versión de clúster destino debe establecerse de modo que indique que los nodos del
clúster se comunicarán mediante la versión potencial del nodo solicitante menos uno.
Ejemplo: configuración de clúster de dos nodos
Este ejemplo de configuración proporciona lo siguiente:
v Conmutación por anomalía y réplica unidirecional
v Entorno de dos niveles
v Las aplicaciones y los datos se trasladan juntos
v Se utiliza un nodo de reserva para el proceso de datos fuera de línea
Este gráfico muestra el concepto de una configuración de clúster simple de dos nodos:
NODO L
NODO R
CRG A1
CRG A1
CRG D1
CRG D1
RV4C104-1
© Copyright IBM Corp. 1998, 2001
7
En este ejemplo, el nodo L opera en este momento como nodo primario para los dos grupos de recursos
de clúster denominados CRG A1 y CRG D1. CRG A1 es un grupo de recursos de clúster de aplicación y
CRG D1 es un grupo de recursos de clúster de datos. Periódicamente se ejecutarán dos programas de
salida en el nodo L para CRG A1. El motivo por el que pueden ejecutarse dos programas de salida a la
vez es que si llama a la API Iniciar CRG, se inicia un programa de salida y éste se ejecuta de forma
continuada mientras el grupo CRG A1 está activo. Si llama a la API Finalizar CRG para el grupo CRG A1,
se inicia otro programa de salida. El nodo R es el primer (y único) nodo de reserva de ambos grupos de
recursos de clúster. Los datos asociados con D1 y la información de aplicación pertinente asociada con
A1 se replican desde el nodo L al nodo R. Si falla el nodo L o tiene que desactivarse por razones
administrativas, el nodo R pasa a ser el nodo primario de los grupos de recursos de clúster A1 y D1. El
nodo R asumirá la dirección IP (Protocolo Internet) definida para el CRG A1.
Nota:
Mientras el nodo L está inactivo, la disponibilidad del
sistema está en riesgo, pues no hay ningún nodo de
reserva si el nodo R también falla. Cuando se recupera el
nodo L y vuelve a unirse al clúster, pasa a ser el nodo de
reserva de ambos grupos de recursos de clúster. A partir
de ahora, el sentido de la replicación será del nodo R al
nodo L. Si se deseara hacer del nodo L el nodo primario,
debería realizarse una conmutación de tipo administrativo.
Ejemplo: configuración de clúster de cuatro nodos
Este ejemplo de configuración proporciona lo siguiente:
v Conmutación por anomalía y réplica bidireccional
v Entorno de tres niveles
v Traslado independiente de aplicaciones y datos
v El nodo de reserva se utiliza para la producción normal de diferentes cargas de trabajo
Este gráfico muestra el concepto de una configuración de clúster de cuatro nodos:
8
iSeries: Cómo configurar un clúster
NODO L2
NODO R2
CRG A1
CRG A1
CRG A2
CRG A2
CRG D1
CRG D1
CRG D2
CRG D2
NODO L3
NODO R3
RV4C103-1
El ejemplo de cuatro nodos muestra la flexibilidad adicional posible con un clúster de iSeries. Hay dos
grupos de recursos de clúster de aplicación (A1 y A2) y dos grupos de recursos de clúster de datos (D1 y
D2). Los datos asociados con D1 son los datos críticos de la aplicación asociada con A1. Los datos
asociados con D2 son los datos críticos de la aplicación asociada con A2. Puesto que éste es un entorno
de tres niveles, las aplicaciones se encuentran en el segundo nivel (nodo L2 y nodo R2) y los datos se
encuentran separados en el tercer nivel (nodo L3 y nodo R3). Para el CRG A1, el nodo L2 es el nodo
primario y el nodo R2 es el nodo de reserva. Al mismo tiempo, el nodo R2 es el nodo primario del CRG
A2 y el nodo L2 es su nodo de reserva. Para el CRG D1, el nodo R3 es el nodo primario y el nodo L3 es
el nodo de reserva. Del mismo modo, el nodo L3 es el nodo primario del CRG de datos D2 y el nodo R3
es su nodo de reserva. De esta forma se habilita la capacidad de asumir mutuamente el control en los
niveles de aplicación y datos. Los cuatro nodos se utilizan en la producción normal. También se utilizan
para realizar las copias de reserva de otros sistemas del clúster. En el clúster, las dos aplicaciones y sus
datos asociados siempre deben estar disponibles. El corte de cualquier nodo individual no interrumpirá la
disponibilidad. Además, el corte simultáneo de un nodo en el nivel de aplicación y un nodo en el nivel de
datos no interrumpirá la disponibilidad.
Nota:
En cualquier caso, la ejecución del clúster sólo estará en
riesgo en tanto y en cuanto algunos recursos de clúster
no se replicarán cuando un nodo no esté activo. Puede
solucionar esto teniendo más de un nodo de reserva para
cualquier recurso de clúster crítico.
Capítulo 2. Versión actual del clúster
9
Ejemplo: configuración de clúster de disco conmutado de dos nodos
Un clúster que utilice tecnología de disco conmutado proporciona una alternativa a la réplica de los datos.
En un clúster de disco conmutado, los datos están contenidos realmente en agrupaciones de
almacenamiento auxiliar independientes (IASP). Este ejemplo de configuración proporciona lo siguiente:
v Una IASP conmutable con un servidor de espera desocupado (la IASP está contenida dentro de una
colección de unidades de discos que son conmutables).
v Entorno de dos niveles
v Las aplicaciones y los datos se trasladan juntos
v Se utiliza un nodo de reserva para cargas de trabajo diferentes no asociadas con los datos de esta
aplicación
v No se efectúa réplica de datos; en este clúster sólo existe una copia de los datos
Este gráfico muestra el concepto de una configuración de clúster simple de dos nodos:
Utilizando este ejemplo, el nodo L y el nodo R pertenecen al mismo dominio de dispositivo. El nodo L está
actuando actualmente como nodo primario para dos grupos de recursos de clúster denominados CRG A1
y CRG DV1. CRG A1 es un grupo de recursos de clúster de aplicación y CRG DV1 es un grupo de
recursos de clúster de dispositivo. El nodo R es el primer (y único) nodo de reserva de ambos grupos de
recursos de clúster. Los datos asociados con DV1 están contenidos en un recurso conmutable, como por
ejemplo una torre de E/S externa. La información de aplicación pertinente asociada con A1 se almacena
en la misma torre o se replica desde el nodo L al nodo R. Si el nodo L falla o necesita desactivarse por
razones administrativas, el nodo R pasa a ser el nodo primario para los grupos de recursos de clúster A1
y DV1. El nodo R tomará el control de la dirección de Protocolo Internet (IP) definida para CRG A1. El
nodo R también asumirá la propiedad del recurso conmutable definido para CRG DV1.
Nota:
10
Mientras el nodo L está inactivo, está en riesgo la
disponibilidad del sistema, ya que no hay ningún nodo de
reserva si el nodo R también falla. Cuando se recupera el
nodo L y vuelve a unirse al clúster, pasa a ser el nodo de
reserva de ambos grupos de recursos de clúster. Si se
deseara hacer del nodo L el nodo primario, debería
realizarse una conmutación por administración.
iSeries: Cómo configurar un clúster
Capítulo 3. Consejos sobre aplicaciones de clúster de alta
disponibilidad
Este tema proporciona sugerencias sobre:
v Cómo obtener partido del reinicio de aplicación“Cómo obtener partido del reinicio de aplicaciones de
clúster de alta disponibilidad”
v Diseño de una aplicación de alta disponibilidad“Escritura de una aplicación de clúster de alta
disponibilidad” en la página 12
v Utilización de la API Distribuir Información
v Llamada a un programa de salida de un grupo de recursos de clúster“Llamada a un programa de salida
de un grupo de recursos de clúster” en la página 12
Cómo obtener partido del reinicio de aplicaciones de clúster de alta
disponibilidad
Para reiniciar una aplicación, la aplicación debe conocer el estado que tenía en el momento de la
conmutación por anomalía o de la conmutación por administración. La información de estado es
específica de la aplicación; en consecuencia, la aplicación debe determinar cuál es la información
necesaria. En el caso de que no haya información de estado, la aplicación puede reiniciarse en el PC. Sin
embargo, tendrá que volver a establecer su posición dentro de la aplicación.
Hay numerosos métodos disponibles para guardar la información de estado para el sistema de reserva.
Cada aplicación necesita determinar cuál es el método que funciona mejor en su caso.
v La aplicación puede transferir toda la información de estado al sistema cliente que realiza la petición.
Cuando se produce una conmutación por anomalía o una conmutación por administración, la aplicación
se sirve del estado almacenado en el cliente para restablecer el estado en el nuevo servidor.
v La aplicación puede reproducir la información de estado (como por ejemplo la información de trabajo y
otras estructuras de control asociadas a la aplicación) en tiempo real. Cuando se produce algún cambio
en las estructuras, la aplicación comunica el cambio al sistema de reserva.
v La aplicación puede almacenar en la parte de datos del programa de salida del grupo de recursos de
clúster correspondiente a esta aplicación, información de estado oportuna que esté asociada con su
aplicación. Para este método se presupone que sólo se necesita una pequeña cantidad de información
de estado. Puede utilizar la API Cambiar Grupo de Recursos de Clúster
(QcstChangeClusterResourceGroup) para realizar esta operación.
v La aplicación puede almacenar información de estado en un objeto de datos que se replica en los
sistemas de reserva junto con los datos de la aplicación.
v La aplicación puede almacenar información de estado en un objeto de datos contenido en la IASP
conmutable que también contiene los datos de la aplicación.
v La información de estado no se guarda, por lo que deberá realizar la recuperación.
Nota:
© Copyright IBM Corp. 1998, 2001
Si la aplicación utiliza algún tipo de proceso de reinicio
desde un punto de control, la cantidad de información que
debe guardarse será menor. La información de estado
sólo se guardará en los puntos de control de la aplicación
predeterminados. El reinicio le devolverá al último punto
de control conocido, lo que equivale a la forma en que
funciona el proceso de control de compromiso de las
bases de datos.
11
Escritura de una aplicación de clúster de alta disponibilidad
Una aplicación de alta disponibilidad es aquella que puede resistir un corte del sistema en un entorno
organizado en forma de clúster. Hay numerosos niveles posibles de disponibilidad de la aplicación:
1. Si se produce un error en la aplicación, la aplicación se reinicia a sí misma en el mismo nodo y
corrige cualquier causa potencial de error (como, por ejemplo, datos de control corruptos). La
aplicación volverá a aparecer como si empezara por primera vez.
2. La aplicación realiza cierto número de procesos de reinicio desde un punto de control. La aplicación
volverá a aparecer como si estuviera próxima al punto de la anomalía.
3. Si se produce un corte del sistema, la aplicación se reinicia en un servidor de reserva. La aplicación
volverá a aparecer como si empezara por primera vez.
4. Si se produce un corte del sistema, la aplicación se reinicia en un servidor de reserva y dicha
aplicación realiza cierto número de procesos de reinicio desde un punto de control en los servidores.
La aplicación volverá a aparecer como si estuviera próxima al punto de la anomalía.
5. Si se produce un corte del sistema, se producirá una conmutación por anomalía coordinada de la
aplicación y de los datos a otro nodo o nodos del clúster. La aplicación volverá a aparecer como si
empezara por primera vez.
6. Si se produce un corte del sistema, se producirá una conmutación por anomalía coordinada de la
aplicación y de los datos a otro nodo o nodos del clúster. La aplicación realiza cierta cantidad de
procesos de reinicio desde un punto de control en los servidores. La aplicación volverá a aparecer
como si estuviera próxima al punto de la anomalía.
Nota:
En los casos anteriores que van del 1 al 4, la
responsabilidad de recuperar los datos corresponde al
usuario.
Para obtener más información sobre cómo escribir una aplicación de alta disponibilidad, consulte el
apartado Alta disponibilidad y clústers.
Para obtener información sobre cómo está configurada la estructura de trabajos para los servicios de
recursos de clúster y cómo utilizan las API de clúster las colas de usuario, consulte el apartado estructura
de trabajos de servicios de recursos de clúster y colas de usuario.
Llamada a un programa de salida de un grupo de recursos de clúster
La llamada a un programa de salida de un grupo de recursos de clúster se efectúa en diferentes fases del
entorno de un clúster. Este programa establece y gestiona el entorno necesario para que en un clúster
tenga lugar la resiliencia de aplicación y de datos. El programa de salida es opcional para un CRG de
dispositivo resiliente, pero es necesario para los demás tipos de CRG. Cuando se utiliza un programa de
salida de grupo de recursos de clúster, se le llama cuando se producen eventos a nivel de clúster,
incluyendo:
v Cuando un nodo deja el clúster de forma inesperada.
v Cuando un nodo deja el clúster como consecuencia de la acción de las API Finalizar Nodo de Clúster o
Eliminar Entrada de Nodo de Clúster.
v Cuando se suprime el clúster como consecuencia de la acción de la API Suprimir Clúster.
v Cuando la API Iniciar Nodo de Clúster activa un nodo.
v Cuando se restablece la comunicación con un nodo particionado.
Este programa de salida:
v Se ejecuta en un grupo de activación que haya recibido un nombre o en el grupo de activación del que
efectúa la llamada (*CALLER).
v Ignora el parámetro de reinicio si el programa de salida tiene una excepción sin manejar o se cancela.
12
iSeries: Cómo configurar un clúster
v Proporciona un manejador de cancelación.
Cuando se ejecuta una API del grupo de recursos de clúster, se efectúa la llamada al programa de salida
desde un trabajo aparte con el perfil de usuario especificado en la API Crear Grupo de Recursos de
Clúster. La API crea automáticamente el trabajo aparte cuando se llama al programa de salida. Si el
programa de salida de un CRG de datos no se ha ejecutado satisfactoriamente o finaliza de forma
anormal, se efectúa la llamada al programa de salida del grupo de recursos de clúster en todos los nodos
activos del dominio de recuperación con el código de acción Deshacer (15). Este código de acción
permite que se restituya cualquier actividad que no haya finalizado y que se recupere el estado original
del grupo de recursos de clúster.
Si el programa de salida de un CRG de aplicación no se ha ejecutado satisfactoriamente o finaliza de
forma anormal, los servicios de recursos de clúster intentarán reiniciar la aplicación. Se llama al programa
de salida del grupo de recursos de clúster con el código de acción Reiniciar (3). Si se intenta reiniciar la
aplicación durante el número máximo de intentos especificado y no se consigue, se llama al programa de
salida del grupo de recursos de clúster con el código de acción Conmutar por anomalía (9). La cuenta de
reinicio sólo se restablece cuando se llama al programa de salida con un código de acción de inicio, que
puede ser el resultado de un inicio de CRG, una conmutación por anomalía o una conmutación por
administración.
Cuando se inicia el grupo de recursos de clúster, el programa de salida del CRG de aplicación al que se
ha llamado en el nodo primario no debe devolver el control a los servicios de recursos de clúster hasta
que la propia aplicación finaliza o se produce un error. Una vez que el grupo de recursos de clúster
(CRG) de aplicación está activo, si los servicios de recursos de clúster deben notificar algo al programa
de salida del grupo de recursos de clúster (CRG) de aplicación, se inicia otra instancia del programa de
salida en otro trabajo diferente. Se espera el retorno de la segunda instancia del programa de salida.
Cuando se llama a un programa de salida de grupo de recursos de clúster, se pasa un conjunto de
parámetros que identifican el evento de clúster que se está procesando, el estado actual de los recursos
de clúster y el estado esperado de los recursos de clúster. Un programa de salida de grupo de recursos
de clúster puede ser llamado debido a las siguientes razones:
1 - Inicializar
Se está creando un objeto de grupo de recursos de clúster.
2 - Iniciar
Establece la resiliencia de un grupo de recursos de clúster. Además, inicia la aplicación para un
grupo de recursos de clúster de aplicación.
3 - Reiniciar
Reinicia una aplicación. Sólo se aplica a un grupo de recursos de clúster configurado para permitir
el reinicio.
4 - Finalizar
Inhabilita la resiliencia de un grupo de recursos de clúster en todos los nodos del dominio de
recuperación.
7 - Suprimir
Se suprime el objeto de grupo de recursos de clúster.
8 - Reincorporar
Se está activando un nodo inactivo o restableciendo la comunicación con un nodo particionado.
9 - Conmutar por anomalía
Se ha producido una anomalía de nodo.
10 - Conmutar por administración
Se está procesando la API Iniciar Conmutación por Administración. El papel de principal se está
asignando al nodo que tiene actualmente el papel de primero de reserva.
Capítulo 3. Consejos sobre aplicaciones de clúster de alta disponibilidad
13
11 - Añadir nodo
Se está añadiendo un nodo al dominio de recuperación.
12 - Eliminar nodo
Se está eliminando un nodo del dominio de recuperación. Cuando se elimina un nodo con la API
Eliminar Entrada de Nodo de Clúster, sólo el nodo que se elimina visualiza este código de acción.
Los otros nodos del dominio de recuperación visualizarán el código de acción Conmutar por
anomalía.
13 - Cambiar
Los nodos listados en el dominio de recuperación han cambiado su papel.
14 - Suprimir mandato
El grupo de recursos de clúster se está suprimiendo sólo en el nodo local.
15 - Deshacer
Restituir a la petición anterior. La petición anterior se encuentra en el campo Código de acción
anterior.
16 - Finalizar nodo
Un nodo de clúster está finalizando. Sólo el nodo que finaliza visualizará este código de acción.
Los otros nodos del dominio de recuperación visualizarán el código de acción Conmutar por
anomalía.
17 - Añadir entrada de dispositivo
Se está añadiendo un dispositivo a un grupo de recursos de clúster de dispositivo. Sólo se aplica
a un grupo de recursos de clúster de dispositivo.
18 - Eliminar entrada de dispositivo
Se está eliminando un dispositivo de un grupo de recursos de clúster de dispositivo. Sólo se
aplica a un grupo de recursos de clúster de dispositivo.
19 - Cambiar entrada de dispositivo
Se está cambiando información acerca de un dispositivo de un grupo de recursos de clúster de
dispositivo. Sólo se aplica a un grupo de recursos de clúster de dispositivo.
20 - Cambiar estado de nodo
El estado de un nodo se está cambiando de particionado a anómalo.
Para obtener información detallada acerca de programas de salida de grupo de recursos de clúster,
incluyendo la información que se pasa al programa de salida para cada código de acción, consulte el
apartado Programa de salida de grupo de recursos de clúster. También puede ver el ejemplo de programa
de salida de CRG de aplicación incluido en la biblioteca QUSRTOOL. El código fuente de ejemplo puede
utilizarse como base para escribir un programa de salida. Consulte el miembro TCSTAPPEXT del archivo
QATTSYSC para obtener un ejemplo escrito en ILE C.
14
iSeries: Cómo configurar un clúster
Capítulo 4. Versión actual del clúster
Para crear un clúster que incluya nodos de varios niveles de versión de clúster, son necesarios
determinados pasos al crear el clúster. Por omisión, la versión actual del clúster se establecerá en la
versión potencial de clúster del primer nodo añadido al clúster. Este método es adecuado si este nodo
está en el nivel de versión más bajo que puede aceptar el clúster. Sin embargo, si este nodo está en un
nivel de versión posterior, como consecuencia no podrán añadirse nodos con un nivel de versión anterior.
La alternativa es utilizar el valor de la versión de clúster destino de la creación del clúster para establecer
la versión actual del clúster en la versión potencial de clúster del primer nodo añadido al clúster, menos
uno.
Por ejemplo, considere un caso en el que debe crearse un clúster de tres nodos. Los nodos de este
clúster son:
Identificador de nodo
Release
Versión potencial de clúster
Nodo A
V4R4
1
Nodo B
V4R5
1
Nodo C
V5R1
2
Si el clúster debe crearse desde el nodo C, debe tener cuidado de indicar que va a tratarse de un clúster
de release mixto. La versión de clúster destino debe establecerse de modo que indique que los nodos del
clúster se comunicarán mediante la versión potencial del nodo solicitante menos uno.
© Copyright IBM Corp. 1998, 2001
15
16
iSeries: Cómo configurar un clúster
Capítulo 5. Direcciones IP para CRG de aplicación
Existen dos formas de gestionar la dirección IP asociada con un CRG de aplicación. La forma más fácil,
que es la forma por omisión, consiste en dejar que los servicios de recursos de clúster gestionen la
dirección IP. Este método conducirá los servicios de recursos de clúster a la creación de la dirección IP en
todos los nodos del dominio de recuperación, incluyendo los nodos añadidos de forma subsiguiente al
dominio de recuperación. Si se selecciona este método, la dirección IP no puede estar definida
actualmente en ningún nodo del dominio de recuperación.
El método alternativo consiste en gestionar las direcciones IP por su cuenta. Este método conduce a los
servicios de recursos de clúster a no tomar ninguna iniciativa para configurar la dirección IP; el usuario es
responsable de la configuración. Debe añadir la dirección IP de toma de control a todos los nodos del
dominio de recuperación (excepto a los nodos de réplica) antes de iniciar el grupo de recursos de clúster.
Cualquier nodo que deba añadirse al dominio de recuperación de un CRG activo debe tener configurada
la dirección IP antes de añadirse.
Es posible conseguir que la dirección IP de toma de control funcione en varias subredes, aunque el valor
por omisión es tener todos los nodos del dominio de recuperación en la misma subred. Consulte el
apartado Habilitación de la conmutación por administración de aplicación en subredes para conocer los
pasos necesarios para configurar la dirección IP de las aplicaciones en las que los nodos del dominio de
recuperación están en varias subredes.
© Copyright IBM Corp. 1998, 2001
17
18
iSeries: Cómo configurar un clúster
Capítulo 6. Parámetros ajustables de comunicaciones de
clúster
La API Cambiar Servicios de Recursos de Clúster (QcstChgClusterResourceServices) permite ajustar
algunos de los parámetros de rendimiento y configuración de servicios de topología de clúster y de
comunicaciones de clúster, para que se ajusten mejor a muchos entornos de red y de aplicación
exclusivos en los que se aplica la agrupación en clúster. Esta API está disponible para cualquier clúster
que se ejecute en la versión de clúster 2 o posterior.
QcstChgClusterResourceServices se utiliza para ajustar el rendimiento y la configuración de clústers. Esta
API proporciona un nivel básico de soporte de ajuste en el que el clúster realizará el ajuste de acuerdo
con un conjunto predefinido de valores identificados para valores de intervalo de mensajes y tiempo de
espera altos, bajos y normales. Si se desea un nivel de ajuste avanzado, generalmente anticipado con la
ayuda del personal de soporte de IBM, pueden ajustarse parámetros individuales sobre un rango de
valores predefinido. Los cambios inadecuados en los parámetros individuales pueden conducir fácilmente
a la disminución del rendimiento del clúster.
Cuándo y cómo ajustar los parámetros del clúster
La API proporciona una forma rápida de establecer los parámetros de rendimiento y configuración del
clúster sin necesidad de entrar en detalles. Este nivel básico de ajuste afecta principalmente a los valores
de sensibilidad de latido y tiempo de espera de mensajes del clúster. Los valores válidos para el nivel
básico de soporte de ajuste son:
1 (Valores de tiempo de espera altos/Latidos menos frecuentes)
Se realizan ajustes en las comunicaciones de clúster para aumentar el intervalo de latido y
los diversos valores de tiempo de espera de mensajes. Con menos latidos y valores de
tiempo de espera más largos, el clúster tardará más en responder (será menos sensible) a
las anomalías de comunicaciones.
2 (Valores por omisión)
Se utilizan los valores por omisión normales para los parámetros de rendimiento y
configuración de comunicaciones del clúster. Este valor puede utilizarse para devolver todos
los parámetros a los valores por omisión originales.
3 (Valores de tiempo de espera bajos/Latidos más frecuentes)
Se realizan ajustes en las comunicaciones de clúster para disminuir el intervalo de latido y
los diversos valores de tiempo de espera de mensajes. Con latidos más frecuentes y valores
de tiempo de espera más cortos, el clúster tardará menos en responder (será más sensible)
a las anomalías de comunicaciones.
En la tabla siguiente se muestran como ejemplo los tiempos de respuesta resultantes para una anomalía
de latido que conduce a una partición de nodo:
1 (Menos sensible)
2 (Por omisión)
Det.
Anal.
Total
Det.
Una sola subred
00:24
01:02
01:26
00:12 00:30 00:42 00:04 00:14 00:18
Varias subredes
00:24
08:30
08:54
00:12 04:14 04:26 00:04 02:02 02:06
© Copyright IBM Corp. 1998, 2001
Anal. Total
3 (Más sensible)
Det.
Anal. Total
19
Los tiempos se expresan en formato de minutos:segundos.
Dependiendo de las cargas de red habituales y de los medios físicos específicos utilizados, un
administrador de clúster puede elegir ajustar los niveles de sensibilidad de latido y tiempo de espera de
mensajes. Por ejemplo, con un transporte de alta fiabilidad y alta velocidad, como por ejemplo
Opticonnect con todos los sistemas del clúster en un bus común Opticonnect, puede desear establecer un
entorno más sensible para asegurar una rápida detección que conduzca a una conmutación por anomalía
más rápida. Se elegiría la opción 3. Si la ejecución se estuviera efectuando en un bus Ethernet de 10 Mbs
altamente cargado y los valores por omisión condujeran a particiones ocasionales debido a picos de carga
de red, podría elegirse la opción 1 para reducir la sensibilidad del clúster a los picos de carga.
La API Cambiar Servicios de Recursos de Clúster también permite el ajuste de parámetros individuales
específicos cuando los requisitos de entorno de red presentan situaciones únicas. Por ejemplo, considere
de nuevo un clúster con todos los nodos comunes en un bus Opticonnect. El rendimiento de los mensajes
de clúster puede aumentarse en gran medida estableciendo el parámetro de Tamaño de fragmento de
mensaje en el máximo de 32.500 bytes para que coincida más con el tamaño de Unidad de transmisión
máxima (MTU) de Opticonnect que el valor por omisión de 1.464 bytes. Esto reduce la actividad general
de fragmentación y reensamblaje de mensajes de gran tamaño. messages. La ventaja, obviamente,
depende de las aplicaciones de clúster y de la utilización de mensajes de clúster resultante de esas
aplicaciones. En la documentación de la API se definen otros parámetros, que pueden utilizarse para
ajustar el rendimiento de los mensajes de clúster o para modificar la sensibilidad del clúster al
particionado.
20
iSeries: Cómo configurar un clúster
Capítulo 7. Configuración de dispositivos resilientes
Para configurar un entorno de clúster que incluya dispositivos resilientes, debe ponerse atención para
evitar conflictos en el clúster. El siguiente conjunto de pasos le ayudará a realizar una configuración
satisfactoria para colecciones de recursos conmutables.
1. Complete el plan de entorno.
Planifique las configuraciones de hardware y software. Por ejemplo, determine qué torres de E/S se
conmutarán entre qué sistemas. Asimismo, identifique los sistemas que potencialmente puedan
añadirse al dominio de recuperación de un CRG de dispositivo. Si lo hace ahora, puede evitar
conflictos de asignaciones de recursos que pueden impedir que lo haga más tarde. Determine qué
recursos se incluirán en la torre conmutable; recuerde que, cuando se produce una conmutación por
anomalía o por administración, la totalidad de la torre conmutable se mueve al sistema de reserva.
Determine también otros requisitos físicos, como por ejemplo espacio de suelo y dominios de
alimentación.
2. Cree el clúster.
Si todavía no existe, cree el clúster. Añada todos los nodos al clúster. Para beneficiarse de las
posibilidades de los dispositivos resilientes, todos los nodos deben estar en la versión potencial de
clúster 2 y la versión actual de clúster debe establecerse en 2. Inicie todos los nodos del clúster o al
menos aquellos que van a estar en dominios de dispositivo.
3. Identifique qué nodos deben estar en dominios de dispositivo.
Añada nodos a sus dominios de dispositivo respectivos, incluyendo aquellos nodos que eventualmente
puedan participar en la acción de conmutación de un CRG de dispositivo. Si lo hace, los recursos
asociados con el dominio de dispositivo (como por ejemplo números de unidad de disco y rangos de
direcciones virtuales) se asignarán a través de todos los nodos del dominio de dispositivo para evitar
conflictos de recursos.
4. Cree la descripción de dispositivo IASP
En todos los nodos que deben figurar en el dominio de recuperación de una IASP, cree una
descripción de dispositivo utilizando los mismos valores de parámetro.
5. Cree los CRG de dispositivo.
6. Identifique qué nodos estarán inicialmente en el dominio de recuperación.
En la lista de dispositivos de CRG, especifique qué IASP serán conmutables bajo el CRG y si el
sistema debe activarlas cuando se produce una conmutación por anomalía o por administración.
Identifique un programa de salida para el CRG, si lo desea.
7. Configure las unidades de discos en la IASP.
El programa de utilidad de gestión de DASD proporciona una herramienta útil para hacerlo. Si realiza
este paso, es mejor tener activos todos los nodos del dominio de recuperación de CRG. Esto permite
a los nodos determinar si todos los nodos pueden acceder a todas las unidades de discos, evitando
así problemas posteriores.
8. Rellene la IASP con datos.
Cree o mueva a la IASP los sistemas de archivos definidos por usuario adecuados.
© Copyright IBM Corp. 1998, 2001
21
22
iSeries: Cómo configurar un clúster
Impreso en España