martes, 28 de enero de 2014
ERROR: Multicast communication with node using mping failed [solved]
Hola,
hoy hemos migrado un PowerHA 6.1 a 7.1.2 mediante un mksysb de una máquina con AIX 7.1 y PowerHA 7.1.2_SP02.
Hemos configurado el cluster con sus redes y un resource group en el nodo 1, pero cuando hemos is a sincronizar el script que verifica la comunicación multicast arrojaba un error y el estado quedaba con "Failed":
"
[...]
lscluster: Cluster services are not active.
lscluster: Cluster services are not active.
Saving existing /var/hacmp/clverify/ver_mping/ver_mping.log to /var/hacmp/clverify/ver_mping/ver_mping.log.bak
Verifying clcomd communication, please be patient.
Verifying multicast communication with mping.
ERROR: Multicast communication with node node01 using mping failed.
Errors encountered verifying communications between nodes.ERROR: Unable to communicate using multicast messages
"
Este es otro ejemplo más de lo poco limpios que han sido los desarrolladores a la hora de hacer estos scripts de verificación, al igual que pasa con clmigcheck tal y como puse en el post anterior (http://jorgelopezaragoneses.blogspot.com.es/2014/01/powerha61-71-upgrade-tips-errors.html).
Veréis que en el fichero /var/hacmp/clverify/ver_mping/ver_mping.log se está utilizando la IP 228.168.101.43 y, probablemente, el grupo de redes no tiene enrutada la MAC Multicast asociada entre sus switches.
La solución es sencilla, hay que editar el script que ejecuta esta comprobación y ponerle la IP multicast que vayamos a utilizar y que ya habremos probado con anterioridad que funciona.
# vi /usr/es/sbin/cluster/diag/ver_mping
Cambiamos la IP 228.168.101.43 por la nuestra:
# if we got no multicast line from lscluster, we will use the default multicast addr.
MCAST_ADDR4="228.168.101.43"
Un saludo.
viernes, 24 de enero de 2014
PowerHA6.1 to 7.1 Upgrade. Tips, errors & clmigcheck problems [solved]
Hola,
he estado cacharreando en un entorno de pruebas con el PowerHa7.1 y dónde he encontrado "más trampas" ha sido en su actualización porque la administración, salvo que el menú de smit cambia y que tenemos el repository disk y la IP multicast, el resto es muy similar a la hora de administrar.
Problemas que he encontrado en el propio script clmigcheck:
1) ERROR: PowerHA System Mirror requires a shared disk connected to all nodes in the cluster. None could be found.
Problema: el script clmigcheck no detecta los discos compartidos por ambos nodos, aunque sí los hay.
Solución: Hay que hacer varios cambios en /usr/sbin/clmigcheck o bien crear el fichero /var/clmigcheck/clmigcheck.txt a mano.
El comando cllspvids ha debido cambiar y ahora no debería recibir opciones, aunque en el script clmigcheck si la tiene.
Ejemplo: he comentado las líneas que están mal y he incluido otras con el comando sin opciones.
# Get space separated list of shared disks connected to
# every node in the cluster
#log "prompt_disks: Output from cl_lspvids -n ${node_list}:\n"
log "prompt_disks: Output from cl_lspvids :\n"
#${CSPOCDIR}/cllspvids -n ${node_list} >>${LOGFILE} 2>&1
${CSPOCDIR}/cllspvids >>${LOGFILE} 2>&1
log "\n"
2) ERROR: Multicast communication with node srvnimprasce01 failed.
Problema: El script clmigcheck hace un test de mping utilizando una IP Multicast fija definida en el script.
Solución: modificar el script clmigcheck poniendo la IP Multicast que vaya a utilizar el cluster.
NOTA: aunque el tráfico multicast esté habilitado entre dos máquinas, es posible que la MAC Multicast por la que hablan no esté enrutada en los switches.
Para sacar la MAC Multicast que van a utilizar para pasársela al grupo de networking, los tres primeros campos son fijos 01:00:5e: y los tres siguientes corresponden al valor hexadecimal de cada uno de los tres últimos octetos de la IP Multicast del cluster.
Ej: IP Multicast=228.23.14.101 --> MAC Multicast=01:00:5e:17:0e:65
Solución a algunos de los errores reportados por clmigcheck.
1) ERROR: Communications Path for node srvnimprasce02 must be set to hostname
Problema: en /etc/hosts hay una entrada con una IP errónea para uno de los nodos.
Solución: editar /etc/hosts para corregirlo.
2) ERROR: You must first ensure the ODM configuration has no errors, then you can enter additional configuration information.
Note that you must enter the configuration information before you can install PowerHA System Mirror 7.1 on a system that contains an ODM configuration. You must rerun the tool and first check the ODM configuration, then enter the configuration data.
Problema: se ha ejecutado clmigcheck e inmediatamente se ha seleccionado la opción 3.
Solución: siempre que se necesite ejecutar la opción 3 de clmigcheck, hay que ejecutar primero la opción 1.
3) CONFIG-ERROR: The configuration contains unsupported options: Heartbeat via IP Alias Address.
The PowerHA network name is. This will have to be removed from the configuration before migration to PowerHA System Mirror
Problema: hay heartbeat configurados a través de IP alias.
Solución: eliminar la configuración “IP Address Offset” en cada red. Requiere parada de los servicios de cluster.
NOTA: hacerlo en ambos nodos o hacerlo en uno y sincronizar.
# smitty hacmp > Extended Configuration > Extended Topology Configuration > Configure HACMP Networks > Change/Show a Network in the HACMP Cluster
Change/Show an IP-Based Network in the HACMP Cluster
[Entry Fields]
* Network Name Red_Adm
New Network Name []
* Network Type [ether] +
* Netmask(IPv4)/Prefix Length(IPv6) [255.255.255.0]
* Enable IP Address Takeover via IP Aliases [Yes] +
IP Address Offset for Heartbeating over IP Aliases [10.1.1.1] ? --> Vaciar []
* Network attribute public +
Sincronizar
Smitty hacmp > Extended > HACMP Verification and Synchronization
Errores durante la administración de un cluster PowerHA7.1
1) clmgr errors with repository disk operations
Problema: ejemplo
# clmgr replace repository 0004d86a94efa267
ERROR: "0004d86a94ef9202" cannot be found on "machineX"
Available Physical Volumes:
[…]
Solución: modificar la Object Class HACMPsircol poniendo el pvid correcto (lspv)
- Hacer backup del objeto
# odmget HACMPsircol
HACMPsircol:
name = "SCFE_pro_sircol"
id = 0
uuid = "0"
ip_address = "228.23.14.101"
repository = "0002329ab3e778dd"
backup_repository = "0004d86a94efa267"
# odmget HACMPsircol > HACMPsircol.tmp
- Modificar el backup con el PVID bueno
# vi HACMPsircol.tmp
- Eliminar el objeto antiguo
# odmdelete HACMPsircol
- Insertar el objeto nuevo
# odmadd HACMPsircol.tmp
2) Error: RSCT cluster services (cthags) are not active on this node
Problema: Los servicios de cluster no levantan reportando el siguiente error:
rc.cluster: Error: RSCT cluster services (cthags) are not active on this node.
rc.cluster: Try bringing up CAA and RSCT with the following command:
startsrc -g caa.
cl_rsh had exit code = 1, see cspoc.log and/or clcomd.log for more information
En PowerHa 7.1, cthags sustituye a grpsvcs como gestor del Group Service por lo que, en este caso, el problema es que cthags no se ha iniciado correctamente. Para ello es necesario rebotar la máquina con los servicios de cluster activos.
NOTA: es posible que sea necesario levantar los servicios de cluster antes de rebotar o no se pueda rebotar ahora mismo. Será grpsvcs quién esté gestionando el Group Services en ese momento.
Arrancamos el cthags aunque no vaya a hacer nada, pero el chequeo del cluster mira a ver si el subsistema está "active"
# startstc –s cthags
# smitty clstart
he estado cacharreando en un entorno de pruebas con el PowerHa7.1 y dónde he encontrado "más trampas" ha sido en su actualización porque la administración, salvo que el menú de smit cambia y que tenemos el repository disk y la IP multicast, el resto es muy similar a la hora de administrar.
Problemas que he encontrado en el propio script clmigcheck:
1) ERROR: PowerHA System Mirror requires a shared disk connected to all nodes in the cluster. None could be found.
Problema: el script clmigcheck no detecta los discos compartidos por ambos nodos, aunque sí los hay.
Solución: Hay que hacer varios cambios en /usr/sbin/clmigcheck o bien crear el fichero /var/clmigcheck/clmigcheck.txt a mano.
El comando cllspvids ha debido cambiar y ahora no debería recibir opciones, aunque en el script clmigcheck si la tiene.
Ejemplo: he comentado las líneas que están mal y he incluido otras con el comando sin opciones.
# Get space separated list of shared disks connected to
# every node in the cluster
#log "prompt_disks: Output from cl_lspvids -n ${node_list}:\n"
log "prompt_disks: Output from cl_lspvids :\n"
#${CSPOCDIR}/cllspvids -n ${node_list} >>${LOGFILE} 2>&1
${CSPOCDIR}/cllspvids >>${LOGFILE} 2>&1
log "\n"
2) ERROR: Multicast communication with node srvnimprasce01 failed.
Problema: El script clmigcheck hace un test de mping utilizando una IP Multicast fija definida en el script.
Solución: modificar el script clmigcheck poniendo la IP Multicast que vaya a utilizar el cluster.
NOTA: aunque el tráfico multicast esté habilitado entre dos máquinas, es posible que la MAC Multicast por la que hablan no esté enrutada en los switches.
Para sacar la MAC Multicast que van a utilizar para pasársela al grupo de networking, los tres primeros campos son fijos 01:00:5e: y los tres siguientes corresponden al valor hexadecimal de cada uno de los tres últimos octetos de la IP Multicast del cluster.
Ej: IP Multicast=228.23.14.101 --> MAC Multicast=01:00:5e:17:0e:65
Solución a algunos de los errores reportados por clmigcheck.
1) ERROR: Communications Path for node srvnimprasce02 must be set to hostname
Problema: en /etc/hosts hay una entrada con una IP errónea para uno de los nodos.
Solución: editar /etc/hosts para corregirlo.
2) ERROR: You must first ensure the ODM configuration has no errors, then you can enter additional configuration information.
Note that you must enter the configuration information before you can install PowerHA System Mirror 7.1 on a system that contains an ODM configuration. You must rerun the tool and first check the ODM configuration, then enter the configuration data.
Problema: se ha ejecutado clmigcheck e inmediatamente se ha seleccionado la opción 3.
Solución: siempre que se necesite ejecutar la opción 3 de clmigcheck, hay que ejecutar primero la opción 1.
3) CONFIG-ERROR: The configuration contains unsupported options: Heartbeat via IP Alias Address.
The PowerHA network name is
Problema: hay heartbeat configurados a través de IP alias.
Solución: eliminar la configuración “IP Address Offset” en cada red. Requiere parada de los servicios de cluster.
NOTA: hacerlo en ambos nodos o hacerlo en uno y sincronizar.
# smitty hacmp > Extended Configuration > Extended Topology Configuration > Configure HACMP Networks > Change/Show a Network in the HACMP Cluster
Change/Show an IP-Based Network in the HACMP Cluster
[Entry Fields]
* Network Name Red_Adm
New Network Name []
* Network Type [ether] +
* Netmask(IPv4)/Prefix Length(IPv6) [255.255.255.0]
* Enable IP Address Takeover via IP Aliases [Yes] +
IP Address Offset for Heartbeating over IP Aliases [10.1.1.1] ? --> Vaciar []
* Network attribute public +
Sincronizar
Smitty hacmp > Extended > HACMP Verification and Synchronization
Errores durante la administración de un cluster PowerHA7.1
1) clmgr errors with repository disk operations
Problema: ejemplo
# clmgr replace repository 0004d86a94efa267
ERROR: "0004d86a94ef9202" cannot be found on "machineX"
Available Physical Volumes:
[…]
Solución: modificar la Object Class HACMPsircol poniendo el pvid correcto (lspv)
- Hacer backup del objeto
# odmget HACMPsircol
HACMPsircol:
name = "SCFE_pro_sircol"
id = 0
uuid = "0"
ip_address = "228.23.14.101"
repository = "0002329ab3e778dd"
backup_repository = "0004d86a94efa267"
# odmget HACMPsircol > HACMPsircol.tmp
- Modificar el backup con el PVID bueno
# vi HACMPsircol.tmp
- Eliminar el objeto antiguo
# odmdelete HACMPsircol
- Insertar el objeto nuevo
# odmadd HACMPsircol.tmp
2) Error: RSCT cluster services (cthags) are not active on this node
Problema: Los servicios de cluster no levantan reportando el siguiente error:
rc.cluster: Error: RSCT cluster services (cthags) are not active on this node.
rc.cluster: Try bringing up CAA and RSCT with the following command:
startsrc -g caa.
cl_rsh had exit code = 1, see cspoc.log and/or clcomd.log for more information
En PowerHa 7.1, cthags sustituye a grpsvcs como gestor del Group Service por lo que, en este caso, el problema es que cthags no se ha iniciado correctamente. Para ello es necesario rebotar la máquina con los servicios de cluster activos.
NOTA: es posible que sea necesario levantar los servicios de cluster antes de rebotar o no se pueda rebotar ahora mismo. Será grpsvcs quién esté gestionando el Group Services en ese momento.
Arrancamos el cthags aunque no vaya a hacer nada, pero el chequeo del cluster mira a ver si el subsistema está "active"
# startstc –s cthags
# smitty clstart
Aix Migration: sissas64_dd error [Solved]
Hola,
aunque no he encontrado un documento de IBM en el que diga esto, la experiencia me dice que es así. Para realizar una migración de AIX 5.3 a 6.1 o de AIX 6.1 a 7.1, hay que escoger un software que no tenga un SP muy bajo, pues en ellos es probable que falte el fichero /usr/lib/drivers/pci/sissas64_dd contenido en el fileset devices.common.IBM.sissas.rte.
0301-154 bosboot: missing proto file: /usr/lib/drivers/pci/sissas64_dd
Ejemplo de entornos en los que he encontrado este error y lo he solucionado utilizando otro software: Migración de AIX5.3 TL7 SP4 a AIX6.1 TL6 SP1 --> corregido con AIX6.1 TL7 SP7
Migración de AIX6.1 TL7 SP5 a AIX7.1 TL0 SP1 --> corregido con AIX7.1 TL2 SP2
He visto un par de soluciones que a mí me han funcionado a medias y que seguramente ya hayáis encontrado en otras páginas.
1) Copiar el /usr/lib/drivers/pci/sissas_dd a /usr/lib/drivers/pci/sissas64_dd y recrear la bootimage (bosboot -ad /dev/hdiskX)
2) Traer el /usr/lib/drivers/pci/sissas64_dd de otra máquina con la misma versión y recrear la bootimage.
El problema de esto es que luego te encuentras inconsistencias en el sistema reportadas por lppchk que, por otro lado, es posible que corrijas con instalaciones de software. Yo preferí buscar una instalación limpia.
Un saludo.
aunque no he encontrado un documento de IBM en el que diga esto, la experiencia me dice que es así. Para realizar una migración de AIX 5.3 a 6.1 o de AIX 6.1 a 7.1, hay que escoger un software que no tenga un SP muy bajo, pues en ellos es probable que falte el fichero /usr/lib/drivers/pci/sissas64_dd contenido en el fileset devices.common.IBM.sissas.rte.
0301-154 bosboot: missing proto file: /usr/lib/drivers/pci/sissas64_dd
Ejemplo de entornos en los que he encontrado este error y lo he solucionado utilizando otro software: Migración de AIX5.3 TL7 SP4 a AIX6.1 TL6 SP1 --> corregido con AIX6.1 TL7 SP7
Migración de AIX6.1 TL7 SP5 a AIX7.1 TL0 SP1 --> corregido con AIX7.1 TL2 SP2
He visto un par de soluciones que a mí me han funcionado a medias y que seguramente ya hayáis encontrado en otras páginas.
1) Copiar el /usr/lib/drivers/pci/sissas_dd a /usr/lib/drivers/pci/sissas64_dd y recrear la bootimage (bosboot -ad /dev/hdiskX)
2) Traer el /usr/lib/drivers/pci/sissas64_dd de otra máquina con la misma versión y recrear la bootimage.
El problema de esto es que luego te encuentras inconsistencias en el sistema reportadas por lppchk que, por otro lado, es posible que corrijas con instalaciones de software. Yo preferí buscar una instalación limpia.
Un saludo.
Build date error in a AIX TL update [solved]
Hola,
ayer conseguimos corregir un problema que, en principio, tenía muy mala pinta.
Para realizar una actualización con multibos desde AIX6.1_Tl4_SP3 a AIX6.1_TL8_SP2 hay que actualizar el fileset bos.rte.bosinst ya que si no la actualización da un fallo de bosboot.
http://www-01.ibm.com/support/docview.wss?uid=isg1fixinfo137662
En este caso, en vez de actualizar sólo el fileset bos.rte.bosinst, se hizo una actualización intermedia completa a versión TL7 SP07 para luego pasar a TL8 SP02. Problema, la actualización en el último paso fallaba por las build dates.
BUILDDATE Verification ...
+-----------------------------------------------------------------------------+
Verifying build dates...
installp: The build date requisite check failed for fileset devices.pciex.df1020e214103c04.rte.
Installed fileset build date of 1245 is more recent than the selected fileset build date of 1241.
installp: The build date requisite check failed for fileset devices.pciex.df1020e214100f04.rte.
Installed fileset build date of 1245 is more recent than the selected fileset build date of 1241.
installp: The build date requisite check failed for fileset devices.pciex.df1020e214103c04.diag.
Installed fileset build date of 1245 is more recent than the selected fileset build date of 1241.
installp: The build date requisite check failed for fileset devices.pciex.df1020e214100f04.diag.
Installed fileset build date of 1245 is more recent than the selected fileset build date of 1241.
installp: Installation failed due to BUILDDATE requisite failure.
El mayor problema es que no se disponía de ningún tipo de backup de la máquina, ni alternate rootvg, ni multibos, ni siquiera mksysb y tampoco podíamos subir a un TL intermedio, por lo que intentamos solucionar el problema con las herramientas de que disponíamos.
NOTA: si hubiera partido de un estado con todos los filesets en COMMITTED y se hubiera actualizado en APPLIED, podríamos haber empezado por hacer reject
y buscar una versión de AIX inicial cuyos filesets tuvieran un builddate inferior.
Aunque el proceso fue más tedioso de lo que parece, los pasos son bastante simples:
1) Eliminar errores reportados por lppchk
# lppchk -v
csm.server 1.6.0.0 (not installed; requisite fileset)
Para eliminarlo, lo buscamos en nuestro repositorio de software y lo instalamos.
2) Eliminar paquetes con BUILDDATE mayor (al no ser bos.rte se podían borrar)
# installp -u
3) Realizar una instalación del software seleccionando la opción overwrite para dejar el sistema en una versión estable desde la que podamos actualizar después.
# smitty install --> “OVERWRITE same or newer versions? yes”
(En lugar de 452 paquetes ha instalado 76)
4) Realizar la actualización:
# smitty update_all
Éste es un caso particular en el que el estado de la paquetería había quedado algo inestable pero, en general, si tenemos un problema con las BUILD DATES y los paquetes se pueden eliminar, sólo será necesario quietarlos de enmedio y volver a lanzar la actualización.
# installp -u
o
# smit install --> Software Maintenance and Utilities --> Remove Installed Software
Una vez eliminados,
# smitty update_all
Un saludo.
Suscribirse a:
Entradas (Atom)