|
|
|
Esta sección describe los problemas conocidos y las limitaciones actuales.
Esto significa que un dispositivo puede hablar únicamente con dispositivos conectados a él (además de su propio servidor y el controlador de grid). Sin embargo, los protocolos en los dispositivos nuevos deberían estar correctamente especificados para garantizar la integridad del diseño de la aplicación y la compatibilidad con versiones futuras de CA AppLogic.
El espacio en disco disponible total que registra el comando de información del grid es una estimación sin formato y no tiene en cuenta la duplicación del volumen. El espacio en disco disponible real es la cantidad disponible registrada dividida entre el número de duplicaciones (2 duplicaciones de forma predeterminada). Por ejemplo, si hay 1.000 GB de espacio en disco disponible y el grid se ha configurado para tener 2 duplicaciones, el espacio en disco disponible será de 500 GB. También, con objeto de duplicar correctamente los volúmenes, debe haber suficiente espacio en disco en, al menos, X servidores, donde X es el número de duplicaciones (CA AppLogic no fallará al crear un volumen si una de las duplicaciones no se puede crear, sino que mostrará una advertencia indicando que el volumen no se puede duplicar).
Si se inicia una aplicación y falla uno de los servidores del grid, el inicio de la aplicación producirá un error si uno o varios de los dispositivos de la aplicación estaban planificados para ejecutarse en el servidor que ha fallado. Si se produce esta situación, lo único que debe hacer es reiniciar la aplicación.
Para cargar archivos de mayor tamaño en el volumen, utilice el comando vol manage de shell. No olvide especificar los valores de configuración de la IP externa para este comando, a fin de activar el acceso remoto desde dentro del gestor de volumen. Para obtener más información, consulte la referencia del comando vol manage.
CA AppLogic es compatible con el arranque de dispositivos OpenSolaris desde un volumen de arranque basado en zfs. Tenga en cuenta que CA no ha verificado este extremo y puede que no funcione correctamente. Solaris 10 no es compatible con zfs.
Actualmente esto se limita a agrupaciones de zfs de dispositivos individuales. Para beneficiarse por completo de todas las funciones de zfs en CA AppLogic, los usuarios pueden montar sus propias agrupaciones de zfs dentro de sus propios dispositivos. Si se va a utilizar una agrupación de zfs para la duplicación, los volúmenes de CA AppLogic que se utilicen en la agrupación se deberían crear con la duplicación de CA AppLogic desactivada (utilizando la opción mirrored=0 al crear los volúmenes). Además, una agrupación de zfs creada mediante el archivador Solaris de CA AppLogic no funcionará en Solaris 10. Consulte la referencia sobre las limitaciones de los SO para conocer todas las limitaciones de CA AppLogic con respecto a los sistemas operativos.
Si necesita un almacenamiento mayor, utilice un sistema de archivos diferente.
El nuevo modo de configuración dhcp no es compatible con el marcado de propiedad para la configuración del dispositivo. Al trasladar los dispositivos del modo de configuración volfix a dhcp, la documentación de APK describe cómo tratar con dispositivos que dependen del marcado de propiedades para configurar el dispositivo. Para obtener más información, consulte la sección sobre los kit para dispositivos (APK).
Para ver los indicadores de validación de una aplicación, abra la aplicación en el modo de edición. Los indicadores de validación se utilizan para señalar dispositivos en los que las propiedades, los terminales o los volúmenes obligatorios no se han configurado correctamente.
Se puede utilizar iso2class para instalar un dispositivo Solaris 10 usando la consola gráfica para el proceso de instalación. Sin embargo, cuando finalice la instalación y el dispositivo se reinicie, la consola gráfica se puede seguir usando, aunque se debe usar en el modo de texto (sin acceso al escritorio de Solaris 10; acceso estrictamente basado en texto). Esto se debe a un problema con la GUI de Solaris 10 (no es un error de CA AppLogic).
Por lo tanto, la consola gráfica no se puede usar con estos dispositivos. Esto se hace a propósito para lograr que los dispositivos sean lo más compactos posible. Mediante la nueva utilidad iso2class, los usuarios pueden crear sus propios dispositivos con un soporte de escritorio completo.
Este error se debe al hecho de que CA AppLogic define el nombre del equipo de un dispositivo igual que su nombre de instancia. Por lo tanto, si tiene más de 1 dispositivo ejecutándose en un grid y todos tienen los mismos nombres de instancia, el error de nombre duplicado se mostrará en Windows en la consola gráfica. Este error es sólo una advertencia y no afecta al grid ni a su funcionamiento. Sin embargo, si necesita utilizar Windows como un controlador de dominio, será necesario establecer los nombres de equipo como nombres únicos para cada dispositivo. Puede servirse de la utilidad wincfg para establecer el nombre del equipo en su dispositivo.
Se han realizado pruebas con la versión 6 de Java, actualización 7, en los exploradores Internet Explorer, Firefox, Chrome y Safari. Si no se utiliza la última versión de Java, la consola gráfica puede no funcionar correctamente (se quedará colgada mientras se intenta cargar). Antes de informar a CA sobre errores en la consola gráfica, compruebe que está utilizando la última versión de Java (si necesita actualizar Java en el explorador, deberá volver a abrir el explorador después para que la consola gráfica funcione correctamente).
Cuando un servidor secundario toma el control como nuevo servidor primario, si no hay suficientes recursos disponibles en el servidor para iniciar el controlador de grid, CA AppLogic reinicia los dispositivos que se están ejecutando en el nuevo servidor primario en otros servidores dentro del grid, de forma que el controlador de grid se pueda iniciar en el nuevo servidor primario. Tenga en cuenta que esto puede perjudicar a los grupos de conmutación por error del dispositivo. Si CA AppLogic detiene uno de estos dispositivos, es posible que no pueda reiniciar el dispositivo en otro servidor porque puede que no haya recursos suficientes para satisfacer el grupo de conmutación por error.
Todos los dispositivos basados en HVM (Solaris 10, Windows, etc.) utilizan una cantidad de memoria superior a la cantidad configurada en el servidor. Normalmente, dependiendo de la cantidad de memoria asignada a un dispositivo basado en HVM, el dispositivo utiliza memoria adicional en el servidor en el que se está ejecutando (esta memoria adicional la requiere el hipervisor de virtualización que se ejecuta en los servidores y se conoce como "memoria fantasma"). Por lo tanto es posible que, aunque un servidor pueda tener bastante memoria disponible en comparación con lo que se asigna para el dispositivo, el dispositivo no pueda ejecutarse en ese servidor debido a la memoria fantasma adicional que necesitan los dispositivos basados en HVM, que no está disponible en el servidor. El planificador de CA AppLogic tiene en cuenta esta memoria fantasma extra al planificar dispositivos durante el inicio de la aplicación.
Al utilizar una red troncal de 10 G, el rendimiento máximo que se puede lograr entre dispositivos que se ejecutan en servidores diferentes es de 2 Gbps (posiblemente debido a algún tipo de limitación dentro del hipervisor que usa CA AppLogic).
En su lugar, puede utilizarse cualquier tipo de explorador.
Las interfaces compartidas deberían funcionar con todos los otros sistemas operativos.
A continuación se detallan los problemas conocidos de esta versión:
Cuando se usa el controlador RAID HP Smart Array sin activar el caché de escritura, el rendimiento de reducirá en un 50%. Esta incidencia se ha verificado en un servidor HP DL 580 G7 con Smart Array P410/i 256 MB. Estas tarjetas requieren la instalación de una pila o condensador para permitir el caché de escritura.
Al utilizar ServerEngines Corp. NIC con CA AppLogic de NIC de Emulex OneConnect 10Gb (be3) (rev 01). Estos NIC amplifican incorrectamente los paquetes si se activa la opción SR-IOV de BIOS. Estos paquetes amplificados alteran la memoria caché de transferencia del puente, de modo que el puente descarta los paquetes en lugar de enviarlos al destino correcto. Esto provoca cierta inestabilidad en CA AppLogic, lo que da lugar a errores intermitentes en el inicio de la aplicación. Por lo tanto, asegúrese de que la configuración de SR-IOV de BIOS esté desactivada para todos los controladores de NIC de Emulex 10G en todos los servidores del grid.
Cuando se utiliza una red troncal de 10G, el rendimiento máximo que se puede alcanzar entre los dispositivos que se ejecutan en distintos servidores es de aproximadamente 2,5 Gbps (se pueden observar los distintos resultados en función del tipo de hardware de 10G que se utiliza). CA investiga actualmente varias optimizaciones de red (como, por ejemplo, la activación de marcos Jumbo) que se pueden activar en futuras versiones de CA AppLogic para mejorar el rendimiento de la red de 10G.
Muy raramente una aplicación fallará al iniciarse debido a un montaje de volumen atascado en uno de los servidores. CA AppLogic detecta montajes de volúmenes atascados e informa de ellos al usuario mediante el cuadro de mandos del grid. Si se encuentra con este problema en su grid, notifíqueselo a CA Support. Si lo desea, también puede desactivar el servidor que tiene los montajes de volúmenes atascados o bien reiniciarlo para tratar de resolver este problema.
Si esta situación ocurre, el reinicio del servidor primario restaurará el grid en un estado operacional.
VDS: vulnerabilidad de seguridad: configuración inicial de usuario/contraseña
Si se accede a la GUI de CA AppLogic mediante Microsoft Internet Explorer 6 o 7, la GUI pierde memoria a medida que se abren aplicaciones para editar o cuando se abre el shell Web (entre 5 y 20 MB de memoria del sistema se pierden por cada una de estas operaciones). Se recomienda cerrar y volver a abrir el explorador cada pocas horas para recuperar la memoria perdida. Se pueden utilizar también otros exploradores como Firefox, Chrome o Safari en lugar de Internet Explorer.
La GUI ya no cierra automáticamente la sesión del usuario cuando hay una gran carga en el controlador de grid. En cambio, el usuario recibirá un mensaje que afirma que había un error de red. En este caso, sin embargo, la GUI es completamente funcional. El mensaje de error de red se recibirá solamente cuando haya una gran carga en el controlador, por ejemplo, cuando se inicien 4 aplicaciones al mismo tiempo y, a la vez, se esté copiando un volumen grande de muchos GB. En grids grandes, pruebe a asignar hasta un núcleo de CPU completo y 1 GB de RAM al controlador.
Si un grid se reinicia mediante el comando de reinicio del grid, al hacer una copia de seguridad después de reiniciar, uno o varios de los volúmenes del sistema pueden verse degradados. CA AppLogic repara automáticamente estos volúmenes como principal prioridad.
Al migrar un volumen, asegúrese de que, por lo menos, uno de los flujos esté en un servidor activado; de lo contrario, el comando de migración fallará. El volumen se puede migrar completamente fuera de su conjunto original de servidores migrando el volumen dos veces.
Algunos servidores físicos pueden tardar mucho tiempo en reiniciarse. Esto puede hacer que falle la recuperación automática del grid de CA AppLogic. El resultado de final es que puede que las aplicaciones no se reinicien por completo automáticamente después de que el grid se recupere de un error. Esto se debe a que el controlador de grid espera un máximo de 10 minutos para que se reinicien todos los servidores y vuelvan a conectarse al controlador de grid (puede que esta cantidad de tiempo no sea suficiente para que todos los servidores se reinicien). La solución alternativa es reiniciar manualmente las aplicaciones después de que todos los servidores se hayan reconectado al controlador de grid. Ejecute "list srv" para asegurarse de que todos los servidores se conecten al controlador de grid: todos ellos deberían estar en estado activo. En CA AppLogic 2.1, con un tiempo de espera de arranque del servidor de 10 minutos, esto puede ocurrir sobre todo si un servidor no consigue arrancar debido a un funcionamiento incorrecto del hardware o del BIOS.
Cuando el operador reinicia el grid, el estado de error del grid se supone que se restablece y se debería mostrar un mensaje en el cuadro de mandos donde se indique que el operador ha reiniciado el grid intencionadamente ("El operador ha reiniciado el grid el..."). A veces, al reiniciar el grid, el archivo de grid no se restablece ni se muestra el mensaje del cuadro de mandos. El único problema que esto puede causar es cuando se produzca el siguiente error del grid, que puede que las aplicaciones no se reinicien automáticamente (dependiendo de cuántas veces haya fallado el grid cuando se produzca este error). Para obtener una solución alternativa para este problema, en caso de que se haya reiniciado intencionadamente el grid y no se muestre ningún mensaje en el cuadro de mandos, póngase en contacto con CA Support a fin de restablecer el estado de error del grid.
El motivo de esta leve reducción de recursos está relacionado con la adjudicación para zonas de servicio. En cuanto a la memoria, se debe probablemente a la relación de XEN con la tabla de asignación de memoria para una máquina virtual. En cuanto al disco, se debe a zonas de servicio de sistema de archivos normales (esto es lo mismo que en los servidores Linux normales).
En este caso, la aplicación no la tiene abierta ningún otro usuario para realizar ediciones, pero el editor de CA AppLogic considera erróneamente que alguien más la tiene abierta para este propósito. Si ocurre esto, sencillamente anule el bloqueo de la aplicación cuando lo solicite el editor al abrir la aplicación.
La principal ralentización se produce al abrir una aplicación en el editor de aplicaciones de CA AppLogic.
Si el cliente tiene abierta la consola gráfica y se pierde la conexión con Internet (error de tarjeta de la red cliente, bloqueo del equipo cliente, el acceso a Internet no se encuentra disponible, etc.), la consola gráfica tardará 15 minutos en volver a abrirse.
El ratón es difícil de utilizar en Ubuntu cuando la consola gráfica de CA AppLogic está en uso. Esto se debe a una limitación del soporte de XEN VNC (no se admite la aceleración del ratón). Algunos usuarios indican que ajustando los valores de configuración del ratón en Ubuntu se resuelve el problema. Además, raramente se repetirán pulsaciones varias veces al escribir texto desde el teclado (si se da el caso, simplemente borre los caracteres de sobra que aparezcan).
Esto incluye las contraseñas al iniciar sesión en un dispositivo. La consola de arranque de texto se debería usar solamente para finalidades de depuración. La consola de SSH se puede usar en su lugar para todas las demás funciones.
Si un usuario vuelve a abrir la consola de arranque de texto para un dispositivo después de haberla abierto previamente, deberá pulsar la tecla Intro para ver el indicador de inicio de sesión o el símbolo del sistema. Esto se debe a que la consola de arranque está esperando a que el usuario especifique algún dato (ya sea la información de inicio de sesión o un comando para que se ejecute).
Si un grid tiene un dispositivo que forma parte de un grupo de conmutación por error que se ejecuta en un servidor secundario en el que hay que reiniciar el controlador de grid, CA AppLogic puede detener ese dispositivo que podría perjudicar al grupo de conmutación por error.
Después de haber actualizado un grid a la última versión, se muestra un mensaje en el cuadro de mandos que indica que el grid ha fallado a causa de un problema de hardware. Este mensaje se puede ignorar con total seguridad y eliminarlo del cuadro de mandos.
El kit para dispositivos (APK) no funciona actualmente con Ubuntu 9.10 ni 10.x debido a varias incompatibilidades con el último SO. Sin embargo, existen diversas publicaciones en los foros de CA AppLogic que describen cómo utilizar algunas de las distribuciones de SO posteriores con CA AppLogic.
Si usa una configuración de HA de red con CA AppLogic y se produce un error de red externa, las aplicaciones o los dispositivos que utilicen interfaces externas pueden quedarse inaccesibles hasta durante 5 minutos. Parece que esto lo provocan las direcciones MAC de la memoria caché del enrutador. Si se espera a que el enrutador vacíe su memoria caché de ARP o si se envía una respuesta de ARP con un arping desde la aplicación, se restaura el funcionamiento. Esto solamente afecta a la red externa (la red troncal no se ve afectada).
Solaris 10 no funciona en CA AppLogic 3.x ni con servidores Xen ni ESX.
OpenSolaris solamente funciona en servidores basados en XEN.
La GUI de recuperación solamente funciona en servidores basados en XEN.
Las interfaces compartidas no son compatibles con los contadores de dispositivos.
Si un usuario apaga y vuelve a encender un grid, el tiempo de actividad del sistema no se restablece. Si el grid se reinicia, el tiempo de actividad del sistema se debería restablecer.
Si un usuario enciende un grid mediante el comando power_cycle para el grid, es posible que se produzca un error en el servidor primario al reiniciar. Esto solamente ocurrirá en el caso de que el comando se ejecute después de una nueva instalación de grid y si el grid no se ha reiniciado antes de ejecutar el comando de apagar y volver a encender. El reinicio de grid en algún momento después de una nueva instalación de grid puede ayudar a evitar este problema.
Si el tamaño del recurso compartido de NFS se cambia mientras se ejecuta un grid, CA AppLogic no lo detectará hasta que se reinicie el grid. Este problema se corregirá en una futura versión.
Cuando se destruye un grid que utilizaba un SAN, CA AppLogic suprime el contenido de la carpeta del grid en la SAN, pero abandona la carpeta vacía. Este problema se corregirá en una futura versión.
No se pueden usar servidores basados en Dell que utilicen tarjetas RAID H200 con CA AppLogic. Este problema se corregirá en una futura versión.
La solución alternativa para este problema es activar el hardware RAID en el servidor de Dell antes de utilizarlo para crear el grid.
Los dispositivos basados en RedHat 5.3 no se pueden instalar con iso2class. Este problema se corregirá en una futura versión.
Con muy poca frecuencia, una actualización a 3.5 de las versiones 3.0 o 3.1 puede producir un error. En este caso de error de actualización en concreto, los siguientes mensajes están presentes en el registro de estado del grid al que se accede mediante BFC (haga clic en el estado del grid para abrir el registro).
installing the controller image ioctl: LOOP_SET_FD: Device or resource busy installing new controller FAILED, aborting
Si estos mensajes están presentes en el registro, vuelva a ejecutar la actualización; debería realizarse correctamente.
Nota: Este problema es en realidad un error de las versiones 3.0 y 3.1 de CA AppLogic, y se resuelve en CA AppLogic 3.5.
El comando de reversión de la versión 3.5 a la 3.1 no funciona en un grid basado en ESX. Sin embargo, como solución alternativa, puede utilizarse el comando de degradación (tenga en cuenta que la degradación lleva más tiempo que la reversión). Este problema se corregirá en una futura versión.
Los volúmenes basados en ext3-snapshot no funcionan con grids basados en ESX. Sin embargo, estos volúmenes funcionan con grids basados en XEN. Si se utiliza un grid basado en ESX y se necesita utilizar un volumen de ext3-snapshot, se puede agregar un nodo basado en XEN al grid y utilizar dicho nodo para crear o gestionar los volúmenes de ext3-snapshot (cuando se ejecuten los comandos del volumen, deben desactivarse todos los servidores ESX para que el archivador de CA AppLogic se ejecute en el nodo basado en XEN). Este problema se corregirá en una futura versión.
Podría producirse un error al intentar migrar flujos del volumen del SAN local a grids que están configurados para utilizar un SAN externo. En vez de migrar el flujo del volumen al SAN local, CA AppLogic intenta migrar erróneamente el flujo al SAN externo. Si se encuentra este error, utilice la opción store=local con el comando vol migrate. Este problema se corregirá en una futura versión.
Cuando se actualiza CA AppLogic de 3.0.30 a 3.5.x, el controlador del grid se cuelga intermitentemente y cualquier comando de 3tshell que se ejecute devuelve un mensaje de error de memoria baja.
Para solucionar la incidencia, reinicie el controlador del grid. Este problema se corregirá en una futura versión.
En algunos NIC de Broadcom, y concretamente en NetXterme II BCM5709/5716, la velocidad de vínculo detectada por el controlador del NIC es de 100 Mb/s o 10 Mb/s. Como resultado, CA AppLogic no puede instalarse.
Para solucionar la incidencia, intente reinstalarlo. Este problema se corregirá en una futura versión.
La versión de OpenSSH instalada en el controlador del grid limita el número de sesiones de ssh multiplexadas simultáneas a 10. Como resultado, si se ejecutan más de 10 solicitudes asincrónicas, la API no las recoge.
Para solucionar la incidencia, envíe menos de 10 solicitudes asincrónicas simultáneas a la API. Este problema se corregirá en una versión futura.
Si renombra la interfaz de Montaje o Componentes, el editor de la aplicación no se carga completamente. Este problema se corregirá en una versión futura.
En servidores con estos NIC, después de haber creado un grid, el resultado de la información de srv srvX -extended muestra al estado de los NIC como inactivo. Esto se ha identificado como una incidencia específica de hardware. Para solucionar la incidencia, inicie sesión en el conmutador correspondiente, cierre el puerto del NIC en el srvX y actívelo de nuevo. El estado ahora debería ser activo. Este problema se corregirá en una futura versión.
Se ha observado que en servidores PE R710 de Dell con NIC Broadcom NetXtreme II 57711 (bnx2x) de 10Gbe, BFC no es capaz de detectar los servidores en los que se producirá un error de instalación. Esto es una incidencia específica de hardware y se corregirá en una futura versión.
A continuación, figuran los problemas conocidos clave que incluye esta versión con respecto a los dispositivos de Windows. Si lo desea, consulte la referencia de instalación de dispositivos de Windows para obtener información sobre procedimientos adicionales y notas.
Al utilizar el nuevo APK de Windows que se incluye con CA AppLogic 3.5, la edición de centro de datos de 64 bits de Windows Server 2003 puede producir un error intermitentemente al iniciarse en un grid basado en Xen. Si se produce este problema, el reinicio del dispositivo puede solucionarlo. Este problema se corregirá en una futura versión.
El archivador de Windows puede hacer que falle una operación de cambio de tamaño de volumen si el volumen fuente contiene una entrada de directorio o un archivo que estén dañados. La causa principal de este problema deriva del hecho de que algunas de las instalaciones de software de Microsoft contienen a propósito entradas de directorio no válidas (no estamos seguros del motivo; esto se ha observado cuando el usuario instala una versión de Microsoft SQL Server en su dispositivo). Además, el volumen de origen puede estar dañado debido al uso y desgaste habituales. Este problema se puede solucionar ejecutando una reparación del sistema de archivos en el volumen (vol fsrepair) antes de cambiar de tamaño el volumen.
CA ha observado que la operación de cambio de tamaño de los volúmenes NTFS falla 2 de cada 100 veces. Estos 2 errores se producen porque el archivador de Windows no consigue iniciarse correctamente en el grid. Si se produce este problema, al repetir el cambio de tamaño una segunda vez, debería solucionarse. Este problema, sin embargo, debería estar resuelto en esta versión; si observa este problema, informe al respecto al Soporte técnico de CA.
El archivador de Windows emplea una utilidad de Microsoft llamada diskpart para gestionar los volúmenes NTFS de Windows. Ocasionalmente diskpart falla al obtener información sobre el volumen o al montarlo. Esto es un error muy poco frecuente y puede hacer que las operaciones 'vol create' o 'vol resize' fallen en los volúmenes NTFS.
Si el usuario tiene una aplicación que contiene un dispositivo de Windows y se agregan uno o más dispositivos de Windows a la aplicación o bien se agregan o eliminan terminales en los dispositivos de Windows, durante el primer inicio de aplicaciones, algunos los dispositivos de Windows pueden detectar IP duplicadas en su red interna (esto puede suceder solamente durante el primer inicio de la aplicación después de que ésta se haya modificado). Esto no debería causar ningún error operacional en la aplicación ni requerir la intervención del usuario; las direcciones IP duplicadas son estrictamente temporales. En el peor de los casos, parte de la comunicación de red relacionada con cualquiera de los dispositivos de Windows se puede retrasar entre 30 y 60 segundos.
Al intentar detener una aplicación Windows, el proceso se quedaba bloqueado al 99% de su realización. La operación agotaba el tiempo de espera una vez transcurridos 15 minutos. La aplicación contenía 2 instancias de un dispositivo de Windows 2003 Server DataCenter Edition (WIN03DC). Uno de los dispositivos de Windows se detenía y el otro se quedaba bloqueado durante la operación 'comp stop'. Esto se producía solamente una vez y no se podía reproducir.
De vez en cuando se registran ceros para los siguientes contadores de E/S de disco para los dispositivos de Windows (aunque se esté generando un flujo sostenido de E/S): bytes totales de lectura y escritura, núm. de lecturas y escrituras del volumen y el tiempo consumido en las lecturas y escrituras. Esto se debe a un error en la API perfmon de Windows: los valores cero los registra la API perfmon de Windows.
Aparte de los MSI del archivador, las versiones de Windows traducidas al japonés deberían funcionar con CA AppLogic.
Los dispositivo de Windows producen un error al iniciarse si está instalado un dispositivo de DVD-ROM virtual de MagicISO. Los dispositivos de DVD-ROM virtuales no son compatibles actualmente con CA AppLogic para dispositivos basados en Windows.
En algunas ocasiones, se requieren varios minutos para que Windows detecte nuevos NIC en un dispositivo. Esto ocurre cuando el usuario agrega o elimina terminales para un singleton de dispositivo de Windows. El tiempo adicional necesario para detectar estos NIC nuevos puede causar el agotamiento de los tiempos de espera de arranque del dispositivo. Una solución alternativa para esto es aumentar el tiempo de espera de arranque en su dispositivo de Windows.
Si un usuario tiene un dispositivo de Windows en su grid y migra el dispositivo a otro grid que tiene hardware diferente, el dispositivo de Windows puede requerir una reactivación (reactivación de Windows de Microsoft). La reactivación se produce cuando ha cambiado una cantidad específica de hardware (CA desconoce exactamente qué cambios de hardware motivan esta reactivación). Tenga en cuenta que una reactivación puede requerir que el dispositivo de Windows acceda a Internet. Este problema particular se ha observado después de cambiar de tamaño del volumen de arranque de dispositivo de Windows y migrar el dispositivo a un grid diferente.
Este problema solamente afecta a Windows 2008 Server de 32 o 64 bits (Windows 2003 Server funciona perfectamente). Al acceder a un volumen de Windows 2008 mediante el archivador o SSH a un dispositivo, puede que el usuario no pueda acceder o modificar archivos por problemas con los permisos. Para acceder o modificar archivos mediante el shell del comando, conéctese a través de la consola gráfica al escritorio de Windows y abra un shell de comandos. El shell de comando se puede usar para acceder a los archivos o modificarlos.
Windows 2003 Server agota el tiempo de espera durante el primer arranque en la instalación. Asegúrese de seguir las instrucciones de generación de Windows para encontrar una solución alternativa a esta incidencia.
Al instalar los controladores Turbogate PV, cuando se inicia el dispositivo y se ejecuta en un servidor de grid de Xen, el usuario deberá hacer clic manualmente en el asistente de instalación de hardware para la instalación de los controladores Turbogate PV en todos los terminales que se han configurado en el dispositivo. De lo contrario, se producirá un error al iniciar el dispositivo.
Al crear un nuevo dispositivo de servidor de Windows 2003 de 32/64 bits, el dispositivo funcionará solamente con un servidor de grid que utilice el mismo hipervisor en el cual se creó el dispositivo en un principio. De lo contrario, el dispositivo se bloqueará durante el arranque. Por ejemplo, si el dispositivo se ha creado inicialmente en un servidor de grid de ESX, sólo podrá utilizarse en un servidor de grid de ESX. (Si intenta utilizar el dispositivo en un servidor de grid de XEN no funcionará, el dispositivo se bloqueará durante el arranque).
Éste es un problema conocido con el servidor de Microsoft Windows 2003. Microsoft tiene una solución para resolver este problema con su dispositivo de Windows 2003.
Los problemas de la lista siguiente se han observado en versiones de CA AppLogic 2.4-3.x pero son sumamente difíciles de reproducir (o es imposible hacerlo) y se han producido solamente una vez o dos veces. Si se produce en su grid cualquiera de estos problemas, envíe un informe de error a CA para describir qué problema se ha producido y qué comandos de CA AppLogic ejecutados han conducido al error.
Un servidor del grid se reiniciaba solo debido a un bloqueo en el kernel de Linux en dom0 del servidor. Es probable que esto no provoque el fallo del grid entero, como en versiones anteriores de CA AppLogic, pero podría causar tiempo de inactividad en la aplicación. En este caso, CA AppLogic reinicia en otros servidores del grid los dispositivos que se estaban ejecutando en el servidor que ha fallado. Si observa este problema en su grid, póngase en contacto con CA Support.
En CA AppLogic 2.4, ha habido varios casos en los que un servidor pierde la conexión con el controlador de grid y se reinicia. Esto hace que todos los dispositivos que se estaban ejecutando en el servidor se replanifiquen en otros servidores del grid y también puede causar tiempo de inactividad en la aplicación. Se desconoce por qué los servidores pierden sus conexiones con el controlador de grid. En CA AppLogic 2.7-3.x, si la conexión del servidor con el controlador de grid se disuelve, el servidor intenta reconectarse con el controlador de grid y, si lo consigue, el servidor permanece operacional y no hay tiempo de inactividad en la aplicación. Si el servidor no se puede reconectar al controlador de grid durante 1 minuto, el servidor se reinicia y se produce tiempo de inactividad en la aplicación. Cuando un servidor pierde su conexión con el controlador de grid, se registra un mensaje en el cuadro de mandos. Si observa este problema, póngase en contacto con CA Support de inmediato.
En CA AppLogic 2.7 y 2.8, al intentar cambiar el tamaño de 4 volúmenes NTFS al mismo tiempo, se produce un error en la operación de cambio de tamaño de los 4 volúmenes. Este problema se ha observado sólo una vez.
Mientras NASR estaba replicando un archivo de 800 MB en un volumen de 1 GB, el dispositivo de NASR dejó de responder. CA es incapaz de reproducir este problema. Si observa este problema en su grid, comuníqueselo al servicio de Soporte de CA.
El usuario abrió más de 6 consolas gráficas para distintos dispositivos de Windows que se ejecutaban en el grid (abiertas al mismo tiempo). Al abrir la 7.ª consola gráfica, uno de los servidores se reinició y se volvió a unir al grid. Los dispositivos que se estaban ejecutando en el servidor que falló se reiniciaron en otros servidores del grid. Este problema se ha observado solamente una vez.
Hemos identificado los siguientes problemas conocidos con Backbone Fabric Controller (BFC) en esta versión:
su - bfcadmin
Importante: Después de interrumpir esta dependencia, el sistema se ejecutará sin la réplica, de manera que se deberá volver a la IU y establecer otra réplica en la misma ubicación, o en otra distinta.
No utilice el comando "3t grid shutdown" en un grid.
Cuando esto ocurre, el problema se soluciona si se reinicia el servicio de NFS en BFC.
Si se recibe este mensaje, tan sólo es necesario hacer clic en la tecla "Esc" para continuar con la instalación.
En CA AppLogic 3.5, se detecta que algunos NIC NetXtreme II de Broadcom Corporation son demasiado lentos. Si produce este error, intente volver a detectar el servidor.
Si el BFC se queda sin espacio antes de que pueda apagarse, deberá reiniciar el BFC cuando haya liberado espacio para que vuelva a funcionar correctamente.
Si está realizando una instalación no atendida con esta versión del producto, su contraseña no puede contener “=”.
Si utilizaba una red VLAN 0 en el BFC con AppLogic 3.1, podrá seguir usando ese ID de VLAN, pero no podrá asignar ese VLAN en la IU a partir de 3.5.
Este error podría permitir que los servidores accedieran accidentalmente a los grids que deberían estar bloqueados. Si los puertos están correctamente configurados, este problema no se producirá.
Si necesita emplear más de 256 caracteres, basta con eliminar esos parámetros en más de una actualización del grid.
Si está instalando Bare Metal e intentando definir una réplica sobre un sistema de archivos basado en NFS, se producirán problemas si bfcadmin no posee el directorio. Una opción simple es agregar la réplica después de realizar la instalación mediante la IU. Otra es realizar los siguientes pasos:
groupadd -g 64869 bfc useradd -u 64870 -g 64869 bfcadmin
chown bfcadmin /mnt/replica chgrp bfc /mnt/replica
(donde /mnt/replica es la ruta al directorio de réplica)
En algunos servidores, el número de CPU detectado por el sistema es el mismo indistintamente de si Hyper Threading está activado o desactivado. Esto se ha observado en algunos procesadores Dell R610.
Este problema tiene que ver con cómo se escriben los parámetros en el archivo de configuración transferido al conjunto. Si en la IU el usuario introduce sus datos con un coma entre las entradas, se produce el mismo error. La solución para el API de BFC es transferir solamente una única cadena con entradas separadas por un salto de línea.
Por ejemplo:
\"additional_config\":[\"ext_dns1=155.35.34.108\next_dns2=141.202.1.108\"]
En lugar de:
\"additional_config\":[\"ext_dns1=155.35.34.108\",\"ext_dns2=141.202.1.108\"]
La incidencia se produce cuando el protocolo de árbol de expansión (STP) está activado en los conmutadores externos y la red VLAN sin etiquetar en el puerto del conmutador que se conecta a la interfaz externa del servidor no es la misma que la red VLAN sin etiquetar del puerto del conmutador que se conecta a la interfaz externa de los servidores de BFC. El parámetro stp_port de la interfaz externa del servidor se detecta como desconocido y el servidor se pone en cuarentena. Para solucionar la incidencia, puede desactivar completamente el protocolo STP en los conmutadores externos o configurar la red VLAN sin etiquetar del puerto del conmutador que se conecta a la interfaz externa de los servidores para que sea la misma que la red VLAN sin etiquetar del puerto que se conecta a la interfaz externa de los servidores de BFC. A continuación, desactive la cuarentena del servidor para reiniciar el proceso de detección.
Esta incidencia se produce porque al suprimir incorrectamente una subred en 3.1 se produce un error si se tienen grids con intervalos de direcciones IP de aplicación que están en esa subred. El proceso de actualización busca la subred que falta en la actualización y a continuación se produce un error porque no la encuentra. Para solucionar la incidencia, utilice las instrucciones de la actualización errónea para restaurar la instalación previa de BFC 3.1. A continuación, diríjase a cada uno de los grids y suprima los intervalos de direcciones IP de aplicación del grid que no pertenece a una subred actualmente configurada. En algunos casos, como cuando posteriormente se vuelve a agregar la misma subred con un nuevo parámetro de longitud de prefijo de CIDR, el intervalo puede estar dentro de los límites de la subred actual, pero el componente de subred subyacente será incorrecto y seguirá provocando un error en la actualización. Debería comprobar en la IU del controlador del grid que la subred del BFC coincide con los parámetros del intervalo de direcciones IP de aplicación para cerciorarse de ello.
El parámetro -o de isotool no muestra correctamente los dispositivos USB adjuntados al equipo (cuadro de CentOS 5.5). Éste es un problema conocido de CentOS 5.5. Para resolver esto, se debe emitir el siguiente comando de shell como raíz de usuario:
service haldaemon restart
| Copyright © 2012 CA. Todos los derechos reservados. |
|