Esta sección contiene los siguientes temas:
Limitaciones y problemas conocidos
Nota: Todos los dispositivos basados en Solaris se han eliminado, empezando por la versión 3.7 de CA AppLogic®.
Importante: Se recomienda encarecidamente que use el shell Web que se proporciona con la GUI de CA AppLogic®.
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.
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.
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.
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 (como Windows) 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.
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:
Mientras el grid y el propio controlador del grid soportan una gran carga, es posible que varios comandos del controlador del grid (por ejemplo, app provision o vol resize) fallen y produzcan errores de red en la GUI. Si se produce esta incidencia, aumente la CPU del controlador del grid a 1 y la memoria hasta un mínimo de 2 GB; esto debería suponer una solución alternativa para la incidencia.
Esta incidencia se arreglará en una versión futura.
Para solucionar esta incidencia, anule el anclado del dispositivo y reinicie la aplicación. Esta incidencia se arreglará en una versión futura.
Actualmente, el archivador no es compatible con la gestión de dos volúmenes ext3-snapshot al mismo tiempo. Este problema se corregirá en una versión futura.
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.
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 Soporte de CA. 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. Tenga en cuenta que esta incidencia no se ha observado en CA AppLogic® 3.5 o 3.7.
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 Soporte de CA 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, es probable que se deba 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 infraestructura 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.
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).
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.
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.
Con muy poca frecuencia, una actualización a 3.7 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.7.
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.
Nota: Esto podría afectar también a la versión de 3.7.
Mientras se cambia el tamaño de volúmenes basados en NTFS muy grandes (muchos GB de tamaño), la operación de cambio de tamaño puede dejar de informar el progreso y parecerá bloquearse. Sin embargo, la operación de cambio de tamaño sigue en curso y se completará correctamente. Este problema de notificación se corregirá en una versión futura.
Como la versión de CA AppLogic® es la 3.1+, el rendimiento del controlador de SAS MegaRAID se degrada y funciona un 75 % aprox. más lento en comparación con un servidor físico. CA está trabajando actualmente en resolver esta incidencia y publicará una revisión en cuanto la incidencia se identifique y se corrija. Hasta que esta incidencia no se resuelva, se recomienda encarecidamente utilizar un tipo diferente de controlador de disco.
Actualmente los dispositivos Windows 2008 DataCenter Edition producirán un error al iniciarse si están configurados para utilizar más de 8 CPU (solamente en grids basados en Xen). Este problema se corregirá en una versión futura.
Hay una incidencia con la actualización de Cygwin al intentar actualizar al último APK de Windows que se distribuye con CA AppLogic® 3.7. Se recomienda generar un nuevo dispositivo para Windows en lugar de actualizar hasta que se corrija esta incidencia. Este problema se corregirá en una versión futura.
Al ejecutar comandos de 3t mediante SSH, los parámetros se dividen con espacios o con acentos graves (`), en función de la forma en que se invoque el comando. Si un comando de 3t tiene un valor de la propiedad con un espacio, los caracteres después del espacio se tratarán incorrectamente como un argumento separado. Este problema se corregirá en una versión futura.
La propiedad http_port se ignora; el puerto será siempre 8080. Este problema se corregirá en una versión futura.
Los intentos de iniciar más de 90 dispositivos basados en HVM en grids basados en Xen pueden producir un error durante el montaje o errores de inicio de dispositivo. Esto es una incidencia conocida y se corregirá en una futura versión.
Utilice una versión anterior de Safari o consulte el vínculo siguiente para obtener una posible solución alternativa para esta incidencia.
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.
Actualmente, los controladores Halsign Turbogate no son compatibles con Windows 8 de 32 bits; sin embargo, sí lo son con la versión de 64 bits de Windows 8. Esta incidencia se arreglará en una versión futura.
En estos momentos, el APK de Windows no detecta correctamente las asignaciones de direcciones IP duplicadas. Por lo tanto, depende del usuario determinar si se han asignado accidentalmente direcciones IP duplicadas. Esta incidencia se arreglará en una versión futura.
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, solo podrá utilizarse en un servidor de grid de ESX (intentar 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.
La siguiente lista incluye problemas que se han observado en versiones de CA AppLogic®, 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 Soporte de CA.
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®, si la conexión del servidor con el controlador de grid se disuelve, el servidor intenta volver a conectarse con el controlador del grid y, si lo consigue, el servidor permanece operacional y no se produce 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 Soporte de CA de inmediato.
En CA AppLogic®, 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.
Si está realizando una instalación no atendida con esta versión del producto, su contraseña no puede contener “=”.
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 la opción de procesamiento de gráficos no se establece correctamente en Internet Explorer 9, los gráficos en BFC no se muestran correctamente. Los gráficos afectados aparecen en las páginas de los servidores, los grids y el cuadro de mandos de BFC.
Para corregir este problema, en Internet Explorer 9, haga clic en Opciones de Internet en el menú Herramientas. Haga clic en la ficha Opciones avanzadas y encuentre la sección Gráficos acelerados. Active la casilla de verificación Usar procesamiento por software. Guarde los cambios y reinicie Internet Explorer.
Si es necesario establecer todas estas MAC en el modo de detección automática (lista de no permitidos), lo mejor sería utilizar el modo de configuración manual (lista de permitidos) con 3.5.
Asegúrese de que tiene disponibles las direcciones IP externas cuando se agreguen servidores a BFC.
Debido a este error, no se pueden intercambiar directamente el controlador y las IP de aplicación el uno con las otras en un solo paso. Si debe llevarse a cabo esta acción, primero, deben configurarse con otros valores; a continuación, se pueden volver a establecer como los valores deseados.
Si intenta agregar una red etiquetada a un grid sin etiquetar mediante la API, la llamada se realizará correctamente, en lugar de devolver el mensaje 400 que indica que la solicitud no es correcta.
Cuando no existe ningún servidor de descarga configurado (directorio de descarga local), se muestran versiones como descargadas y se aceptan operaciones de supresión, pero estas últimas no se producen. En futuras versiones, se generará un mensaje de error que describa por qué no tiene lugar esta acción.
Esto no es realmente un error, sino únicamente un mensaje confuso.
Se puede utilizar la API para agregar el mismo intervalo varias veces, pero se puede utilizar la IU para eliminar los intervalos duplicados (sin embargo, dejar los intervalos duplicados en su lugar no produce ningún problema).
Dado que no se ha localizado 3.7.0, las partes nuevas de la aplicación solo mostrarán cadenas en inglés. Las partes previamente localizadas de la aplicación (las que existían en la versión 3.5) seguirán mostrando cadenas en el idioma correspondiente, tal y como hacía antes.
En determinados hardware de Dell se puede activar una opción de BIOS de medio virtual de DRAC. Esta función permite iniciar un dispositivo de medios virtuales mediante la red. Sin embargo, el kernel de CA AppLogic® puede identificar el dispositivo de medio virtual como dispositivo de SCSI y confundir el nombre de dispositivo de arranque (lo que era "sda" se convierte en "sdb").
Para evitar este problema, desactive la opción de medio virtual de DRAC en la BIOS de DRAC del hardware de Dell.
Cuando agrega o elimina direcciones a la lista de direcciones MAC en BFC, limite el número máximo a 500. La lista de direcciones MAC se utiliza en el modo de detección para incluir servidores (cuando se establece en Configuración manual) o excluir servidores (cuando se establece en el modo de detección automática).
Se puede trabajar con la lista de direcciones MAC en la ficha Detección de la página Administración de BFC. Se puede editar la lista de servidores, o bien se puede importar un archivo con una lista de servidores. Se puede establecer también la lista de direcciones MAC mediante la API de BFC.
Aunque los servidores del grid de AppLogic Xen son compatibles con los discos de 3 TB, los servidores del grid de AppLogic ESX son compatibles con un máximo de discos de 2 TB. No se deben elegir servidores con discos de 3 TB para ejecutar el hipervisor de ESX, de lo contrario se producirá un error al crear el grid.
Si se ha participado en el programa beta de CA AppLogic® 3.7, a continuación, se debe asegurar de que la versión beta de CA AppLogic® esté presente en el directorio de descargas de BFC si se tiene que ejecutar el procedimiento de reserva debido a una error de actualización.
|
Copyright © 2013 CA.
Todos los derechos reservados.
|
|