Tema anterior: Problemas conocidos

Tema siguiente: Limitaciones y problemas conocidos

Introducción › Notas de la versión › Problemas conocidos › Notas importantes

Notas importantes

  1. ALD ya no se utiliza para instalar/actualizar grids ni para importar catálogos y aplicaciones. En lugar de ALD, se utiliza Backbone Fabric Controller (BFC). BFC es una aplicación de GUI basada en Web de fácil uso que se utiliza para crear y gestionar todos los grids de CA AppLogic dentro de una sola red troncal. Consulte la documentación de BFC para saber cómo descargar o instalar BFC y cómo utilizarlo para gestionar los grids de CA AppLogic. Para importar catálogos y aplicaciones a un grid (esto es, a system_ms, tal y como viene de forma predeterminada en CA AppLogic), se debe copiar el catálogo o aplicación al volumen impex del grid y utilizar los comandos cat import y app import de CA AppLogic.
  2. CA AppLogic 3.x ahora es compatible con el hipervisor de ESX de VMWare, además de Xen. Mientras CA AppLogic 3.x mantiene todas las características y funciones para ambos hipervisores, hay algunos aspectos de uso importantes que son específicos de VMWare ESX cuando se usa con CA AppLogic:
  3. CA AppLogic 3.x incluye controles de acceso basados en roles (RBAC). RBAC permite conceder permisos (control) a un objeto (plantilla de aplicación, instancia de aplicación, catálogo o grid). De forma predeterminada, cuando se crea un usuario nuevo en un grid, este usuario tiene acceso limitado a los objetos del grid. Por ejemplo, de forma predeterminada el usuario no tiene permisos de inicio de sesión en el grid. Es necesario configurar derechos de acceso adecuados (Administración de usuarios y grupos, Descripción general de RBAC) para sus usuarios para acceder a los grids.
  4. Al utilizar la API de la Web para acceder al grid de CA AppLogic 3.x, la aplicación de la API de la Web se deberá configurar con un usuario que tenga derechos de acceso completo al grid (acceso de administrador).
  5. En CA AppLogic 3.x, la compatibilidad del sistema operativo con dispositivos no es tan amplia como lo es con versiones previas de CA AppLogic. En 3.x, Solaris 10 no se admite en absoluto, y OpenSolaris se admite solamente con Xen. Tenga en cuenta que Oracle está dejando de trabajar con OpenSolaris y Solaris 10, los cuales se están reemplazando por Solaris Express y Solaris 11.

    Nota: Todos los dispositivos basados en Solaris se han eliminado, empezando por la versión 3.5. de CA AppLogic y excepto el archivador de Solaris. Póngase en contacto con CA Support si necesita estos dispositivos.

  6. CA AppLogic no se ha diseñado para ningún sistema operativo en concreto, sino que se puede utilizar con sistemas operativos diferentes. Como parte de su diseño, todas las operaciones de volumen (create/format, copy, resize, file-system check/repair y manage) se ejecutan dentro de aplicaciones de CA AppLogic llamadas "archivadores"; el controlador de grid de CA AppLogic ya no las ejecuta como en las versiones anteriores de CA AppLogic. Como tal, estas nuevas aplicaciones de archivador utilizan los recursos del grid al igual que cualquier otra aplicación normal de CA AppLogic. Por lo tanto, debe haber bastantes recursos disponibles en el grid para ejecutar cualquiera de las operaciones de volumen de CA AppLogic. Tenga en cuenta que las aplicaciones de archivador no se utilizan para volúmenes sin formato ni copias del volumen de nivel de bloque.
  7. El controlador de grid utiliza un 10% de un núcleo (tanto para los servidores de ESX como para servidores de Xen).
  8. Como todas las operaciones de volumen se ejecutan ahora mediante aplicaciones de archivador, todas las operaciones de volumen son más lentas en comparación con las versiones anteriores de CA AppLogic, ya que las aplicaciones de archivador se tienen que iniciar o detener como parte de la operación de volumen. Normalmente, hay unos 20 segundos de sobrecarga para operaciones de volumen basadas en Linux y aproximadamente 130 segundos para operaciones de volumen basadas en Solaris.
  9. El uso de los recursos de ancho de banda se impone en todos los dispositivos. Un dispositivo no podrá utilizar más que el ancho de banda configurado para todos los terminales (el ancho de banda asignado tiene todos los terminales en cuenta). Asegúrese de que el ancho de banda configurado para sus dispositivos y las aplicaciones sea apropiado según sus necesidades de uso del ancho de banda (de lo contrario, se puede obtener un rendimiento de red muy lento en la aplicación). El ancho de banda máximo por servidor de CA AppLogic es de 2 Gbits.
  10. En los dispositivos por los que pasa el tráfico de red (por ejemplo, las puertas de enlace, los equilibradores de carga y los conmutadores de puertos), el ancho de banda se reduce realmente a la mitad. Por ejemplo, en un equilibrador de carga que tenga asignados 100 M de ancho de banda, éste se ve limitado realmente a 50 M (ya que el tráfico de red entra y sale del dispositivo).
  11. Antes de acceder la GUI de CA AppLogic en un grid de CA AppLogic recién instalado o actualizado, el usuario debería borrar la memoria caché del explorador. Si la memoria caché del explorador no se borra, es posible que la GUI de CA AppLogic no responda correctamente.
  12. Se puede acceder al shell del grid a través de un explorador Web o mediante un cliente ssh. Para mejorar la seguridad, no se admiten los inicios de sesión ssh basados en contraseña, excepto durante la instalación del grid.

    Importante: Se recomienda encarecidamente que use el shell Web que se proporciona con la GUI de CA AppLogic.

  13. Al acceder al grid a través de ssh, el nombre de usuario de inicio de sesión es siempre root (raíz), con independencia del nombre de usuario de CA AppLogic. Para los inicios de sesión de ssh, los usuarios y sus roles están identificados de forma exclusiva mediante sus claves ssh públicas.
  14. Las ventanas emergentes y el Javascript del explorador Web se deberán activar para utilizar la interfaz de usuario gráfica basada en Web (cuadro de mandos, editor y documentación).
  15. Los usuarios son responsables de adjudicar, asignar y usar direcciones IP visibles externamente para las aplicaciones. CA AppLogic se ocupa de todas las asignaciones de red internas.
  16. Aunque Backbone Fabric Controller configura todos los servidores de grid y los controladores con cortafuegos cuidadosamente preconfigurados y desactiva los servicios de red innecesarios, se recomienda que los usuarios y mantenedores verifiquen las configuraciones de seguridad de sus sistemas.
  17. El rendimiento de red entre servidores de la red privada que se usa para la comunicación entre dispositivos y el volumen es de unos 900 Mbps. El rendimiento de red TCP medido entre dispositivos que residen en servidores diferentes es de 720-900 Mbps. Al ejecutar Windows, el rendimiento de red TCP es de unos 940 Mbps y el de UDP oscila entre 500 y 700 Mbps.
  18. Las limitaciones de recursos relacionadas con los recursos de hardware de los dispositivos se aplican de forma diferente para los diversos tipos de recursos (CPU, memoria o ancho de banda). El valor para la CPU es "no inferior a", para la memoria es "exactamente esa cantidad" (incluye la sobrecarga de la VM) y el ancho de banda es "exactamente esa cantidad". Se puede establecer la obligación de que los recursos de CPU sean "exactamente esa cantidad", mediante la nueva opción --cap_cpu al iniciar la aplicación.
  19. Al iniciar una aplicación con una cantidad mínima especificada de CPU, no se garantiza que la aplicación vaya a obtener exactamente la cantidad de CPU especificada. Por ejemplo, si una aplicación se inicia con cpu=2, es posible que la aplicación reciba 1,97 de CPU, tal y como se observa agregando toda la cantidad de CPU asignada a todos los componentes de la aplicación. Esto se debe a errores de redondeo que pueden ocurrir al intentar asignar CPU a cada componente individual.
  20. Cuando falla el inicio de la aplicación, es posible que no todos los mensajes relacionados con el error se muestren en el shell. Consulte el registro del grid para obtener información adicional, mediante el comando list long n=20.
  21. Los grids en los que la escalabilidad lineal de rendimiento sea importante se deben crear mediante servidores que sean lo más uniformes posible en cuanto a tipo y velocidad de CPU, tamaño de memoria y capacidad de disco. CA AppLogic funcionará correctamente en grids creados a partir de servidores con cantidades diferentes de recursos de hardware; sin embargo, en tales grids se puede experimentar rendimiento sublineal.
  22. No hay visibilidad de usuario al reiniciar el controlador de grid debido a un error de la VM del controlador de grid. Si la VM del controlador de grid falla y CA AppLogic reinicia la VM de dicho controlador, el usuario no tendrá visibilidad mientras el controlador se esté reiniciando. Normalmente se necesitan entre 1 y 2 minutos para que el controlador de grid se reinicie. Si transcurren más de 5 minutos y el controlador del grid sigue sin estar disponible, póngase en contacto con CA Support.
  23. La creación de un volumen NTFS03 siempre da lugar a un volumen NTFS08. Se pueden utilizar volúmenes NTFS08 con Windows 2003 Server.
  24. El comando "net_discover" para el grid y los servidores no es compatible en los servidores o grids basados en ESX.
  25. Cuando se use una SAN con sus grids de CA AppLogic, se debe garantizar que se dispone de al menos 500 GB de espacio libre para todos los grids que utilizan el recurso compartido de NFS configurado. Por ejemplo, si el recurso compartido de NFS se utilizara para cinco grids diferentes, el recurso compartido debería tener 2,5 TB de espacio libre en disco.
  26. Cuando se use una SAN con sus grids de CA AppLogic, si el recurso compartido de SAN o NFS se desconecta durante un período de tiempo, algunos de los volúmenes que se estaban utilizando podrían corromperse. Si esta corrupción impide que el controlador del grid se ejecute o provoca un error de inicio de las aplicaciones (o cualquier otra inestabilidad del grid o la aplicación), póngase en contacto con CA Support de inmediato.
  27. Para usar dispositivos de CA AppLogic basados en las últimas distribuciones de SO (como Fedora Core, Ubuntu, Debian y CentOS), configure el nuevo código de ingeniería de campo de 128 como límite de los dispositivos. Este nuevo código de ingeniería de campo ordena a CA AppLogic que utilice un estilo de nombre de dispositivo más nuevo para los volúmenes del dispositivo que se utilizan específicamente por estas distribuciones más nuevas. Si el código de ingeniería de campo de 128 no se especifica, los dispositivos basados en estas distribuciones más nuevas no podrían iniciarse.
  28. Si su base de datos de BFC de réplica o primaria se pierde o se daña, se podrá recuperar a partir de una copia de seguridad automática que se ejecuta siempre desde la versión 3.1 del BFC. Estas copias de seguridad viven realmente en un subdirectorio de la base de datos primaria así que no son un sustituto para configurar una réplica. (Estas copias de seguridad se escriben también en un subdirectorio de la réplica si lo tiene configurado.) Para restaurar a partir de la copia de seguridad más reciente: