|
|
España-Español | |
|
|
 |
|
Notas de la revisión del software de administración VSE versión A.03.00.00 > Capítulo 5 Notas de la revisión específicas de aplicaciones
Notas de la revisión de Global Workload Manager |
|
|
Se espera que Global Workload Manager tenga un control completo de las CPU disponibles en un sistema mientras un dominio de recursos compartidos está desplegado. No obstante, hay ocasiones en las que deben efectuarse ajustes manuales, por ejemplo:
Global Workload Manager A.03.00.00 no es compatible con las versiones de HP Integrity VM anteriores a la versión A.02.00. Si desea administrar equipos virtuales mediante gWLM A.03.00.00, HP recomienda mejorar a HP Integrity VM versión A.03.00 o posterior. Si no realiza la mejora, puede obtener mensajes como: Unable to deploy SRD nombre: A VM encountered with no size o Unable to deploy SRD 'nombre':guestCpuSetEntitlement (): hpvm_nonvm_cpu_set_entitlement (HPVM_NONVM, (100.000000,100.000000),FALSE) failed: (0,90) Mejore a HP Integrity VM versión A.03.00 o posterior, si es posible. Si no puede mejorar a partir de HP Integrity Virtual Machines versión A.01.20, deberá instalar el agente gWLM versión A.02.00.00 en el sistema VM Host. Si no puede mejorar a partir de HP Integrity Virtual Machines versión A.02.00, instale el agente gWLM versión A.02.50.00 o utilice gWLM A.03.00.00 para administrar sólo equipos virtuales con concesiones especificadas en porcentajes. (Es decir, no administre equipos virtuales con concensiones especificadas en ciclos de CPU.) Para obtener versiones anteriores del agente gWLM, y ayuda con esta configuración, póngase en contacto con HP en la siguiente dirección electrónica: <gwlmfeedback@rsn.hp.com>. gWLM no se puede utilizar con Resource Manager (PRM) ni Workload Manager (WLM) para administrar el mismo sistema al mismo tiempo. Si se intenta hacerlo, se obtendrá un mensaje que indica que la aplicación que en realidad administra el sistema mantiene un bloqueo. Para utilizar gWLM en esta situación, antes apague la aplicación que mantiene el bloqueo. Para el administrador PRM, escriba los siguientes comandos:
Para el administrador WLM, escriba el siguiente comando:
Para obtener información sobre las restricciones existentes cuando se utiliza gWLM con Global Instant Capacity, visite la dirección http://docs.hp.com/en/vse.html y localice el libro blanco «Using Global Workload Manager 3.0 with Global Instant Capacity». Según las características de las cargas de trabajo, gWLM puede migrar recursos de CPU con rapidez. Esta migración frecuente puede generar en potencia, aunque de modo muy poco común, una condición de carrera (race condition), haciendo que la partición virtual se bloquee. También puede generar una emergencia, dando lugar a uno o varios de los siguientes mensajes: No Chosen CPU on the cell-cannot proceed with NB PDC. o PDC_PAT_EVENT_SET_MODE(2) call returned error Mejorar a vPars A.03.04 soluciona este problema. Con las versiones anteriores de vPars, este problema se puede solucionar del modo siguiente: Asigne (mediante la asignación de rutas) al menos una CPU por célula como una CPU vinculada a al menos una partición virtual. (Puede ser cualquier partición virtual.) Esto garantiza que no se produzca una nueva designación en las migraciones de CPU. Por ejemplo, si tiene cuatro células (0, 1, 2, 3), cada una de ellas con cuatro CPU (10, 11, 12, 13) y cuatro particiones virtuales (vpar1, vpar2, vpar3, vpar4), puede asignar 0/1x a vpar1, 1/1x a vpar2, 2/1x a vpar3 y 3/1x a vpar4, donde x is 0,1,2,3. Si migra un equipo virtual desde un sistema VM Host que forma parte de un dominio de recursos compartidos, deberá eliminar el equipo virtual del dominio de recursos compartidos antes de agregarlo en un dominio de recursos compartidos del nuevo sistema VM Host. Elimine el equipo virtual en el dominio de recursos compartidos antes de migrarlo. Migrar el equipo virtual antes de eliminarlo del dominio de recursos compartidos puede dar lugar a las siguientes condiciones, según la interface utilizada.
Global Workload Manager versión A.03.00.00 incluye las siguientes soluciones a anomalías: Comportamiento anterior: El archivo /etc/opt/gwlm/conf/gwlmcms.properties se sobrescribe cuando se ejecuta vseinitconfig. Comportamiento actual: El archivo /etc/opt/gwlm/conf/gwlmcms.properties ya no se sobrescribe. Comportamiento anterior: Global Workload Manager utiliza iCAP para administrar nParticiones. Con iCAP B.08.00, los intentos de gWLM por modificar recursos iCAP son infructuosos a menos que el sistema tenga un saldo positivo de TiCAP. Comportamiento actual: No se necesita un saldo positivo de TiCAP. Comportamiento anterior: En un dominio de recursos compartidos que administre particiones virtuales anidadas en una nPartición, es posible que vea información de estado que indica un mensaje de advertencia Major en la vista de dominios de recursos compartidos. Este mensaje de advertencia indica que la asignación de CPU es mayor que el tamaño del dominio de recursos compartidos. Comportamiento actual: Actualmente, se puede administrar un subconjunto de las particiones virtuales de una nPartición sin generar mensajes de advertencia. Al modificar una directiva personalizada, la selección del botón OK define el valor Metric Response en Inverse. Puede modificar la directiva mediante la interface de línea de comandos de gWLM según se describe a continuación.
Si utiliza gWLM y tiene cualquiera de los dos siguientes tipos de dominios de recursos compartidos basados en particiones, y ha mejorado los agentes gWLM de las particiones desde gWLM A.01.x a gWLM A.03.00.00, no puede agregar otras particiones en el mismo complejo del dominio de recursos compartidos:
Utilice el siguiente procedimiento en el servidor CMS para restablecer el dominio de recursos compartidos:
Global Workload Manager puede activar TiCAP si es necesario para cumplir con las directivas de dominios de recursos compartidos. Para evitar el consumo innecesario de TiCAP, deberá tener una cantidad suficiente de CPU con licencias permanentes disponibles. Si el dominio de recursos compartidos rebasa dicha cantidad, se consume TiCAP para satisfacer las necesidades del dominio de recursos compartidos. gWLM puede administrar una carga de trabajo sólo en un dominio de recursos compartidos desplegado a la vez. Por consiguiente, si una carga de trabajo se asocia directamente a un paquete Serviceguard (mediante el selector del cuadro de diálogo Workload Definition), gWLM puede administrarla sólo en uno de los sistemas host donde pueda ejecutarse en potencia. Si un equipo virtual se asocia a un paquete Serviceguard, el equipo virtual se representa con una carga de trabajo distinta en cada sistema VM Host. En cualquiera de los dos casos, actualmente no se puede administar una sola carga de trabajo mientras sigue a un paquete Serviceguard asociado. Para una carga de trabajo asociada a un paquete Serviceguard, puede aplicar una directiva mediante compartimentos fss o de conjunto de procesadores en sólo uno de los dominios de recursos compartidos a los que la carga de trabajo podría conmutar por error. Para los demás dominios de recursos compartidos a los que la carga de trabajo podría conmutar por error, deberá aplicar una directiva en una instancia que incluya un sistema operativo (partición virtual o nPartición). Puede utilizar una directiva condicional gWLM para cambiar la asignación de recursos según qué paquetes haya presentes. Para un equipo virtual asociado a un paquete Serviceguard, puesto que el equipo virtual se representa con una carga de trabajo distinta en cada sistema host, basta con administrar independientemente cada carga de trabajo en el dominio de recursos compartidos para cada sistema VM Host. El uso de procesadores locales en célula con particiones virtuales en el marco de una nPartición que utilice iCAP da lugar a un error del comando icod_modify. No asigne CPU utilizando especificaciones de célula. Considere la asignación de CPU a las particiones virtuales utilizando una ruta de hardware. También, para utilizar procesadores locales en célula, actualice a vPars A.04.04 en HP-UX 11i v2 (B.11.23) o a vPars A.05.01 en HP-UX 11i v3 (B.11.31). Global Workload Manager permite que varios dominios de recursos compartidos de un complejo utilicen TiCAP: debe impedirse que se dé esta situación. Los cambios efectuados en la configuración de un dominio de recursos compartidos grande que está desplegado pueden tardar mucho (varios minutos) en surtir efecto. Los productos de HP System Fault Management (SFM) y Event Monitoring Service (EMS Hardware Monitors en concreto) generan sucesos, o indicaciones, cuando se migran las CPU. Según las características de las cargas de trabajo, gWLM puede migrar CPU con rapidez. Con el tiempo, esta migración frecuente puede conllevar una cantidad lo bastante grande de sucesos como para que el rendimiento del servidor CMS HP SIM se vea afectado negativamente. Se dispone de las siguientes opciones como soluciones:
Para obtener información sobre cualquiera de estas soluciones, consulte la documentación de HP SIM (disponible en http://www.hp.com/go/hpsim). El servidor CMS tarda en contestar. Mida el tiempo de un comando gwlm list en el servidor CMS. Si dura más de 10 segundos, dé los siguientes pasos:
Se puede instalar un agente gWLM más nuevo en un servidor CMS mediante una versión anterior de gWLM. Por ejemplo, puede instalar el agente A.03.00.00 en un sistema con CMS versión A.02.00.00.x. Esta configuración no es válida y hace que el sistema quede inservible. Actualice la versión de CMS. Esta actualización también instala el agente correspondiente. (Puesto que gWLM necesita que todos los nodos administrados de un dominio de recursos compartidos tengan la misma versión de agente, deberá actualizar los agentes de cualquier otro nodo administrado que pueda estar en un dominio de recursos compartidos que incluya el servidor CSM. Para obtener información sobre la realización de esta actualización, consulte la Guía de instalación y actualización del software de administración VSE. Después de emitir una solicitud para eliminar una carga de trabajo, completar la eliminación puede llevar mucho tiempo (varios minutos). Elimine los datos históricos de supervisión y configuración de la base de datos de gWLM escribiendo el siguiente comando:
Si prefiere no ajustar la base de datos, puede eliminar simultáneamente varias cargas de trabajo con ayuda del comando gwlm delete. Para obtener más información, consulte la página de manual de gwlm(1M). Cuando se instala el agente gWLM en un sistema que tiene instalado Integrity VM, las operaciones de detección sólo notifican los compartimentos de Integrity VM, aun cuando haya conjuntos de procesadores y grupos fss. Con la interface de línea de comandos de gWLM no se puede agregar una carga de trabajo en un dominio de recursos compartidos que tenga particiones anidadas, a no ser que ya se administre un igual de dicha carga de trabajo en dicho dominio de recursos compartidos.
Esto no constituye un problema cuando se utiliza la interface de gWLM en el administrador HP SIM. Basta con seguir las instrucciones del paso 1 del asistente Manage Systems and Workloads (al que se obtiene acceso seleccionando Create Al intentar eliminar el último grupo fss (valor por defecto) de un dominio de recursos compartidos con particiones anidadas, se puede obtener un mensaje que incluye el siguiente texto: Unable to remove workload nombre_carga_de_trabajo: Attempting to remove a compartment with an unachievably low Fixed policy size. Increase the Fixed policy resource amount and try again. Cuando se supervisa un dominio de recursos compartidos con particiones virtuales dentro de una nPartición en un sistema HP-UX 11i v1, el tamaño supervisado de la nPartición puede no haberse actualizado. Si instala gWLM A.03.00.00 en un sistema con Integrity VM A.02.00 instalado, obtendrá mensajes con la siguiente forma en syslog: vm_fssagt[2461]: dangerous REALTIME job 2686 gwlmagent En lugar de gwlmagent, puede ver parstatus, HPUXChildWrap o wbemexec. Puede obtener un mensaje parecido al siguiente: Information Error during shutdown. The unbinding of objects in the registry may have failed, and the workload management lock has not been released. Associated Exception com.hp.gwlm.common.JniPlatformException: prm_ctrl_rel_cfg_lock failed because vm_fssagt:8343 is the lock owner Cuando un sistema tiene conjuntos de procesadores, gWLM utiliza sólo el conjunto de procesadores 0 para los grupos fss. gWLM puede administrar CPU que estén asignadas sólo al conjunto de procesadores 0. No hay ninguna solución: simplemente así es como se implementan los grupos fss en un sistema con conjuntos de procesadores. Puede seguir teniendo los grupos fss en el conjunto de procesadores 0 (dejando sin administrar el resto de los conjuntos de procesadores), administrar utilizando en su lugar conjuntos de procesadores (haciendo caso omiso de los grupos fss) o quitar todos los conjuntos de procesadores (que no sean el conjunto de procesadores 0) mediante el siguiente comando:
La detección realizada por Global Workload Manager no siempre notifica información actual para los equipos virtuales detenidos. Específicamente, cuando un equipo virtual se detiene y el número de CPU virtuales se modifica, la detección realizada por gWLM no muestra el número modificado de CPU virtuales. En su lugar, muestra el número de CPU virtuales correspondiente al inicio más reciente del equipo virtual. gWLM, como aplicación de cliente/servidor que es, es más sensible que otros tipos de aplicaciones a la configuración de red del sistema host. gWLM admite la administración sólo en el marco de un dominio de red individual. Por ejemplo, si el sistema host del servidor CMS tiene varias tarjetas de interface de red que están conectadas a varias redes distintas, gWLM necesita que el nombre de host completo resuelva la dirección IP que será accesible por los agentes gWLM que hayan de administrarse. Este problema constituye una preocupación sobre todo cuando un sistema host está conectado a los dos elementos siguientes:
Global Workload Manager intenta detectar y notificar problemas de configuración con la red que puedan acarrear un comportamiento no deseable, pero en algunos casos dicha detección se produce en un contexto del que sólo puede informarse en un archivo de registro. gWLM no admite alias de nombres de host. Sólo se admiten nombres de host DNS canónicos (nombres de dominio completos). Los nombres de host no pueden tener una longitud superior a 64 caracteres. El siguiente mensaje puede mostrarse en la interface de HP SIM con gWLM: Unable to build a single shared resource domain from the set of specified hosts: mihostA.midominio.com mihostB.midominio.com Este mensaje indica que no hay disponible ningún mecanismo de uso compartido de recursos admitido entre los sistemas host especificados. El mensaje puede obtenerse si:
Si obtiene este mensaje:
El siguiente mensaje puede mostrarse cuando se utiliza el asistente Manage New Systems o el comando gwlm discover: Error during discovery of compartments. Asimismo, el archivo /var/opt/gwlm/gwlmagent.log.0 contiene el siguiente mensaje: com.hp.gwlm.common.PlatformException: /usr/sbin/parstatus -w exited with a non-zero exit status. Captured stderr is: Error: Unable to get the local partition number. La causa más probable es que haya una versión anticuada del software nPartition Provider. Global Workload Manager utiliza un comando que aporta nPartition Provider, que normalmente está en todas las versiones de HP-UX, para determinar las capacidades del sistema. También puede utilizar el comando /opt/vse/bin/vseassist para diagnosticar el problema. Instale el software de nParticiones más reciente, aun cuando no utilice nParticiones. Para HP-UX 11i v1, utilice la versión B.11.11.01.03.01.01 o posterior. Para HP-UX 11i v2 en los servidores HP 9000, utilice la versión B.11.23.01.03.01.01 o posterior. Para HP-UX 11i v2 en los servidores HP Integrity, utilice la versión B.11.23.01.04 o posterior. nPartition Provider se facilita en las siguientes ubicaciones:
De vez en cuando, un agente gWLM y el servidor gWLM CMS discrepan sobre si un dominio de recursos compartidos está realmente desplegado o no. Esto puede suceder cuando se utiliza Ctrl-C para interrumpir un comando gwlm deploy o undeploy. También puede suceder si se producen errores al guardar una configuración gWLM: La configuración se despliega y, a continuación, se guarda en el depósito de configuración de gWLM. Si el despliegue se produce pero el almacenamiento no se lleva a cabo, el agente gWLM percibe el dominio de recursos compartidos como desplegado mientras que el servidor CMS lo percibe como plegado. Utilice la opción --force con gwlm deploy o gwlm undeploy para sincronizar el agente y el servidor CMS. Por ejemplo, ejecute el siguiente comando para obligar tanto al agente como al servidor CMS a considerar el dominio de recursos compartidos como desplegado, sustituyendo el dominio de recursos compartidos por el nombre de su dominio de recursos compartidos:
Para obtener más información sobre el comando gwlm, consulte la página de manual de gwlm(1M). Es posible que se muestre de forma reiterada un mensaje parecido a cualquiera de los dos siguientes:
Esta situación es normal excepto cuando el bloqueo del sistema (usuario y hora) se mantiene durante más de 10 minutos. Dado el caso, puede levantar el bloqueo deteniendo y reiniciando gwlmcmsd, aunque tal vez tenga que esperar hasta 1 minuto antes de poder utilizar gWLM. Utilice los siguientes comandos:
Es posible que no disponga de datos históricos a efectos de representación gráfica, aunque tenga la certeza de que se ha desplegado un determinado dominio de recursos compartidos durante el intervalo de tiempo en cuestión. Se produce un problema afín al seleccionar un intervalo de tiempo en que se espera una actividad elevada del sistema, pero el gráfico muestra una actividad limitada. Asimismo, se podría esperar una actividad muy escasa durante un intervalo de tiempo, pero el gráfico muestra mucha actividad. Compruebe que los relojes de sistema del servidor CMS y de todos los sistemas del dominio de recursos compartidos están sincronizados. Si los relojes difieren de forma significativa, es posible que gWLM no pueda hacer coincidir los datos procedentes de los nodos administrados con el intervalo que se trate de representar gráficamente. Se puede obtener el siguiente mensaje al intentar ver informes en tiempo real: Real-time data is currently loading, please wait... You might also verify that the remote node is running and SRDs have been deployed. Global Workload Manager podría no mostrar las actualizaciones de supervisión para un dominio de recursos compartidos ni en la línea de comandos ni a través de la interface gráfica del administrador HP SIM. Esto puede deberse a los intentos de reformar el tiempo de espera del dominio de recursos compartidos que han dejado a éste en un estado en que el agente de cada uno de sus nodos administrados debe reiniciarse. También puede deberse a que un nodo administrado está apagado, no ejecuta gwlmagent, o se ha bloqueado. Si el nodo administrado está apagado o gwlmagent no se ejecuta, obtendrá el siguiente mensaje: The gWLM agent process on the host is not running -- start the agent and retry. Si el nodo administrado se ha bloqueado, o el dominio de recursos compartidos necesita que se reinicien todos sus agentes, los síntomas pueder ser:
Si un dominio de recursos compartidos no proporciona supervisión en tiempo real a lo largo de un periodo de tiempo sostenido, reinicie el agente gWLM en cada nodo administrado del dominio de recursos compartidos. En el caso de un miembro de dominio de recursos compartidos bloqueado, mientras la supervisión en tiempo real de dicho dominio de recursos compartidos está bloqueada, los demás dominios de recursos compartidos siguen administrando recursos. No obstante, la supervisión en tiempo real de los demás dominios de recursos compartidos se puede bloquear debido al miembro del dominio de recursos compartidos bloqueado. Para restaurar la supervisión de los demás dominios de recursos compartidos:
Parece que el comando gwlm monitor no funciona correctamente. Un informe de gwlmreport se basa en un intervalo de informe que empieza a medianoche del día en que comienza el informe y termina a medianoche del día en que concluye el informe. Las muestras que solapan la medianoche al principio o al final del intervalo de informe se excluyen del informe. Este problema sólo afecta a los agentes gWLM A.02.00.00.x. Los pesos de directiva ayudan a gWLM a determinar las asignaciones de recursos cuando hay un excedente de recursos. Con los pesos de todas las directivas utilizadas en un dominio de recursos compartidos definidos en el mismo valor, los recursos deberían asignarse equitativamente a las cargas de trabajo asociadas. No obstante, definir los pesos en cero para todas las directivas de un dominio de recursos compartidos hace que se asigne a una sola carga de trabajo todo el excedente de recursos. En un dominio de recursos compartidos con particiones anidadas, la asignación de directivas Fixed (fijas) en las que la suma de los valores fijos sea menor que el mínimo del compartimento primario puede dar lugar a que las cargas de trabajo obtengan más recursos de los especificados en las directivas Fixed. Este problema afecta tanto a los agentes gWLM A.01.01.x como a los agentes gWLM A.02.00.00.x. El valor de índice de convergencia que se especifica (opcionalmente) al definir una directiva sólo afecta a las directivas Custom (personalizadas). Las directivas OwnBorrow (PropiedadPréstamo) y Utilization (Utilización) no se ven afectadas. Las directivas Custom (personalizadas) utilizan valores de medición que el usuario proporciona a través del comando gwlmsend. Si se redespliega un dominio de recursos compartidos que tenga una directiva Custom, se pierde el valor más reciente de la medición de la directiva. En esta situación, gWLM fundamenta las asignaciones en la solicitud mínima especificada en la directiva de la carga de trabajo. La carga de trabajo también puede obtener los recursos de CPU que queden después de satisfacer todas las directivas. Los intentos de ejecución de gwlm dan lugar a volcados de núcleos cuando /var está lleno. La solución a corto plazo consiste en liberar espacio en /var. La solución a largo plazo consiste en actualizar la versión de Java. Si utiliza una variante de Java 1.4.2, compruebe que tiene al menos Java 1.4.2.10. Si utiliza una variante de Java 1.5, no se dispone actualmente de una corrección publicada. Se puede mostrar un mensaje con el siguiente texto: ... unable to create new native thread Este problema se produce porque los siguientes parámetros del kernel se definen en valores demasiado bajos:
Normalmente, gWLM no permite crear al mismo tiempo varios dominios de recursos compartidos basados en particiones virtuales en una sola nPartición o sistema. No obstante, cuando hay varios usuarios de gWLM desplegando dominios de recursos compartidos casi al mismo tiempo, gWLM podría permitir por error que existan los diversos dominios de recursos compartidos mencionados. Puede obtener un mensaje parecido al siguiente: Error trying to deploy SRD, mysystem.vpar.000 to mysystem2.mydomain.com. SRD, mysystem2.fss.000 is already deployed. Only one SRD is allowed to be deployed. En HP-UX 11i v2 (B.11.23), una aplicación ubicada en un grupo fss podría bloquearse al ejecutarse en una partición virtual, nPartición o sistema de un solo procesador. Al definir una directiva condicional en un archivo de configuración XML utilizando el elemento compositePolicyDefinition, se especifican las condiciones con ayuda de los elementos conditionItem. Para cada elemento conditionItem, se especifica un valor de orden que gWLM utiliza para determinar el orden de evaluación. gWLM acepta actualmente el mismo valor de orden para elementos conditionItem diferentes en el mismo elemento compositePolicyDefinition, pero da error al evaluarlos sin notificarlo. gWLM debe generar un mensaje de error en este caso. Con los compartimentos basados en conjuntos de procesadores o grupos fss, gWLM permite colocar secuencias de comandos en los compartimentos utilizando los registros de las aplicaciones con nombres alternativos. Esto sólo funciona si el shell o intérprete utilizado está listado en el archivo /etc/shells. Normalmente, perl no se incluye en dicho archivo. Por lo tanto, las secuencias de comandos de perl (y cualquier otra secuencia de comandos basada en shells o intérpretes que no estén listados en /etc/shells) no se colocan correctamente. Este problema no afecta a los archivos ejecutables. Agregue /opt/perl/bin/perl, y cualquier otro shell o intérprete necesario, en el archivo /etc/shells. Global Workload Manager reconocerá los shells o intérpretes agregados en 30 segundos.
La colocación de todos los procesos con el comando gwlmplace en un nodo administrado se pierde si:
En estos casos, los procesos se colocan según los registros de aplicaciones o los registros de usuarios que correspondan. Si no existe ningún registro, los procesos que no sean raíz se colocan en el conjunto de procesadores por defecto o el grupo fss por defecto; los procesos raíz se dejan donde están. Cuando gWLM administra los conjuntos de procesadores en un sistema, todos los procesos del sistema tienen que ubicarse en una carga de trabajo. gWLM coloca los procesos según los registros de aplicaciones o los registros de usuarios especificados al crear o modificar la definición de una carga de trabajo. Si no existe ningún registro, los procesos están sujetos a las reglas de colocación, que se explican en el tema de la ayuda en línea «pset / fss group tips», en la sección titulada «Precedence of placement techniques». Si utiliza psrset para colocar los procesos en conjuntos de procesadores, es probable que gWLM traslade los procesos al conjunto de procesadores por defecto. Para mantener la colocación de un proceso, utilice los registros de aplicaciones o los registros de usuarios de gWLM al crear o modificar las definiciones de cargas de trabajo en gWLM. Si el uso de registros no resulta práctico, utilice el comando gwlmplace. No obstante, tendrá que utilizar gwlmplace después de cada redespliegue de un dominio de recursos compartidos para volver a ubicar los procesos en las cargas de trabajo deseadas. Los grupos fss creados por gWLM se pueden abandonar y su eliminación no resulta fácil. Esta situación se produce por diversos motivos. Por ejemplo, al administrar un dominio de recursos compartidos basado en grupos fss, se utiliza un segundo servidor CMS (quizá porque el servidor CMS original se ha desactivado). Esto puede dejar al dominio de recursos compartidos con grupos fss que no se pueden quitar. Mediante la interface HP SIM, puede crear un dominio de recursos compartidos nuevo que integre automáticamente los grupos fss existentes. También puede eliminar los grupos fss, en cuyo caso tiene varias opciones. Si tiene instalado el administrador PRM, escriba el siguiente comando:
Si no tiene instalado el administrador PRM, utilice el siguiente procedimiento:
Los grupos fss ya deberían haber desaparecido del sistema. No obstante, las definiciones de las cargas de trabajo correspondientes aún están en el depósito de configuración de gWLM. Dichas definiciones y la definición de dominio de recursos compartidos se pueden eliminar utilizando la interface de gWLM en el administrador HP SIM. Seleccione Tools Los tamaños o asignaciones para los equipos virtuales de un dominio de recursos compartidos desplegado pueden aparentar ser inferiores a los mínimos de directiva correspondientes. Si las CPU de un sistema VM Host se suscriben por exceso al desplegar un dominio de recursos compartidos en dicho host, gWLM muestra el tamaño actual de NONVM como un valor negativo. Al intentar dejar de administrar un equipo virtual que se haya iniciado, el dominio de recursos compartidos se puede plegar, aun cuando se muestre el siguiente mensaje: The virtual machine nombre_equipo_virtual on host nombre_host is on but does not have an associated gWLM policy. Please turn the virtual machine off, or apply a gWLM policy to provide the necessary resources. Global Workload Manager se ha diseñado para utilizar las extensiones de archivos .log.0, .log.1 y .log.2 para los archivos de registro. Se utiliza el bloqueo de archivos Java para asegurar que hay sólo un proceso gWLM actualizando un archivo de registro en cualquier momento dado. A partir de Java 1.4.2.06, el bloqueo de archivos permite crear archivos con extensiones que presentan la forma .log.0.n, donde n es algún entero. Si utiliza Java versión 1.4.2.06 o posterior y desea consultar los archivos de registro en busca de mensajes de error, utilice el siguiente comando para ver qué archivos contienen mensajes de error recientes:
A continuación, puede utilizar /usr/bin/tail para ver mensajes en los archivos de registro actualizados recientemente. Si envía los archivos de registro al servicio de soporte técnico de HP, cree un archivo con formato tar mediante los siguientes comandos:
A continuación, envíe el archivo /tmp/gwlmlogs4support.tar al servicio de soporte técnico de HP. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 Versión para imprimir |
|
|
|
|
|
|||||||||||||||
|
|||||||||||||||
Remove Associated gWLM Policy.
