Previous Topic: Known Issues and Important NotesNext Topic: Known Issues and Limitations


Important Notes

  1. The Relocate command is now included in the Component object. This relocates a running component to a different server in the same grid. The relocation may be performed live or using a component restart. Currently, this functionality is available only for Linux appliances. Windows appliances are not currently supported.
  2. When a new user is created on a grid, this user has limited access to the grid's objects. For example, by default the user does not have login permissions to the grid. You need to configure appropriate access rights (User and Group Administration, Overview) for your users to access the grids.
  3. CA AppLogic is OS agnostic and designed to be used with different operating systems. As part of its design, all volume operations are executed within applications named filers. These filer applications use resources on the grid like any other application. There must be enough available resources on your grid to execute any volume operations. The filer applications are not used for raw volumes or block-level volume copies.
  4. In release 3.8 Xen-based grids, the grid controller is assigned one full CPU core for its own exclusive use. CA AppLogic also reserves one CPU on every server (exclusive for dom0) with the exception of the primary server that is running the grid controller, where two CPUs are reserved (one for the grid controller and one for dom0). CA AppLogic does not assign any appliances to run on the same CPU core as used by dom0 or the grid controller.
  5. Network bandwidth resource usage is enforced on all appliances. An appliance will not be able to use more than its configured bandwidth for all of its terminals (the assigned bandwidth takes all terminals into account). Verify that the configured bandwidth for your appliances and applications is appropriate according to your bandwidth usage needs. If not, you may experience some very slow network performance in your application. The maximum bandwidth per server is 2 Gbits. If you use a 10GE backbone network, the maximum bandwidth is 20 Gbits.
  6. Appliances that forward network traffic such as load balancers and port switches share bandwidth between all terminals. For example, the same packet being forwarded by an appliance is counted on both inbound and outbound terminals.
  7. When application start fails, not all messages related to the failure may be shown in the shell. Inspect the grid log for additional information, using the list log n=20 command.
  8. Grids in which consistent scalability of performance is important should be built using servers that are as uniform as possible in CPU type and speed, memory size, and disk capacity. CA AppLogic works with grids assembled from servers with different amounts of hardware resources; however, on such grids you may experience inconsistent performance.
  9. The CA AppLogic interface is not available while the grid controller is restarting. Typically it takes one to two minutes for the grid controller to restart on its own. If the grid controller is unavailable for more than five minutes, contact CA Support.
  10. When using a SAN with your grids, we recommend 500GB of free space to accommodate catalog and user volumes for every grid that uses the configured NFS share. For example, if the NFS share is to be used for five different grids, the share should have 2.5TB of free disk space.
  11. When using a SAN with your grids, if the SAN or NFS share goes offline for any period of time, some of the volumes that were in use might get corrupted. If this corruption prevents the grid controller from running or causes applications to fail to start (or any other grid or application instability), contact CA Support immediately.
  12. We recommend that all appliances are updated with the latest APK release. To use appliances based on the latest OS distributions, such as Fedora Core, Ubuntu, Debian, RedHat and CentOS, use the latest APK versions that are distributed with CA AppLogic 3.8.

    If you do not use the latest APK version, you must configure the field engineering code of 128 on the boundary of the appliances. This field engineering code instructs CA AppLogic to use a newer device name style for the appliance volumes that are used specifically by these newer distributions. If the field engineering code of 128 is not specified, appliances based upon these newer distributions will fail to start unless the latest APK version is used.

  13. Windows 2003 Server templates are no longer distributed with CA AppLogic. The Windows 2003 server OS will be supported but the templates are no longer maintained. It is recommended to use either Windows 2008 or 2012 Server instead of Windows 2003 Server.
  14. As of CA AppLogic 3.7, the WEB5 appliance remains in the system catalog for backward compatibility. However, this appliance may be removed from the system catalog in a subsequent release.
  15. As of CA AppLogic 3.7, the LampCluster template application is no longer distributed with the release and will not be maintained.
  16. Language pack hotfixes are now integrated into CA AppLogic. There is no need to install a hotfix to get support for a specific language. All languages are installed by default.
  17. If either your primary or replica BFC database is lost or corrupted, you may be able to recover it from an automatic backup.

    Note: These backups are located in a subdirectory of the primary database so they are not a substitute for configuring a replica. These backups are also written to a subdirectory of the replica if you have one configured.

    To restore from the most recent backup:

    After the restore, there may be one or more grid in the Running, But Needs Attention state. If there is, clear the failure on those grids before proceeding.