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

Getting Ready › Release Notes › Known Issues and Important Notes › Important Notes

Important Notes

  1. ALD is no longer used to install/upgrade grids and to import catalogs and applications. Taking the place of ALD is the Backbone Fabric Controller (BFC). BFC is a simple-to-use web-based GUI application that is used to create and manage all of your CA AppLogic® grids within a single backbone. See the BFC documentation for how to download/install BFC and how to use it to manage your CA AppLogic® grids. To import catalogs and applications into your grid (i.e., system_ms that is shipped with CA AppLogic®), copy the catalog/application to your grid's impex volume and use the cat import and app import CA AppLogic® commands.
  2. CA AppLogic® 3.x now supports the VMware ESX hypervisor, in addition to Xen. While CA AppLogic® 3.x maintains all of the features and functionality for both hypervisors, there are some important usage aspects that are specific to VMware ESX when using it with CA AppLogic®:
  3. CA AppLogic® 3.x introduces role-based access controls (RBAC). RBAC provides for the ability to grant permissions (control over) to an object (application template, application instance, catalog or grid). By default, 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 for your users to access the grids.
  4. When using the Web API to access your CA AppLogic® 3.x grid, the Web API application must be configured with a user who has full access rights to the grid (administrator-type access).
  5. In CA AppLogic® 3.x, the operating system support for appliances is not as vast as it is for prior CA AppLogic® releases. In 3.x, Solaris 10 is not supported at all, and OpenSolaris is only supported for Xen. Note that OpenSolaris and Solaris 10 are being discontinued by Oracle and are being replaced by Solaris Express and Solaris 11.

    Note: All of the Solaris-based appliances have been removed starting from CA AppLogic® 3.5, excluding the Solaris filer. Contact CA Support if you need these appliances.

  6. CA AppLogic® is OS agnostic and designed to be used with different operating systems. As part of its design, all volume operations (create/format, copy, resize, file-system check/repair and manage) are executed within CA AppLogic® applications named filers; they are no longer executed by the CA AppLogic® grid controller as with previous versions of CA AppLogic®. As such, these new filer applications use resources on the grid just like any other regular CA AppLogic® application. Therefore, there must be enough available resources on your grid to execute any of the CA AppLogic® volume operations. Note that the filer applications are not used for raw volumes or block-level volume copies.
  7. The grid controller uses 10% of a core (for both ESX and Xen-based servers).
  8. Because all volume operations are now executed using filer applications, all volume operations are slower as compared to previous CA AppLogic® releases since the filer applications have to be started/stopped as part of the volume operation. Typically, there is about 20 seconds of overhead for Linux-based volume operations and about 130 seconds for Solaris-based volume operations.
  9. 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 (or else you may experience some very slow network performance in your application). The maximum bandwidth per CA AppLogic® server is 2 Gbits.
  10. Appliances that pass through network traffic such as gateways, load balancers and port switches, the bandwidth is actually cut in half. For example, a load balancer that is assigned 100M of bandwidth is actually limited to 50M (due to the fact that the network traffic passes in and out of the appliance).
  11. Before accessing the CA AppLogic® GUI on a newly installed or upgraded CA AppLogic® grid, the user should clear out the browser's cache. If the browser's cache is not cleared out, the CA AppLogic® GUI may not behave properly.
  12. The grid shell can be accessed either through a web browser or using an ssh client. For increased security, password-based ssh logins are not supported except during grid installation.

    Important! We strongly recommend that you use the web shell provided with the CA AppLogic® GUI.

  13. When accessing the grid over ssh, the login user name is always root, regardless of the CA AppLogic® user name. For the purpose of ssh logins, users and their roles are uniquely identified by their public ssh keys.
  14. Web browser's Javascript and pop-ups must be enabled to use the web-based graphical user interface (dashboard, editor, documentation)
  15. Users are responsible for allocating, assigning and use of externally visible IP addresses for applications; CA AppLogic® takes care of all internal network assignments
  16. While the Backbone Fabric Controller sets up all grid servers and controllers with carefully pre-configured firewalls and disables unnecessary network services, users and maintainers are encouraged to verify the security settings of their systems.
  17. Network performance between servers on the private network used for volume and inter-appliance communication is measured to approximately 900 Mbps. The TCP network performance measured between appliances residing on different servers is measured as 720-900 Mbps. When running Windows, the TCP network performance is about 940 Mbps and UDP is about 500-700 Mbps.
  18. Resource limits on appliance hardware resources are enforced differently for different types of resources (CPU, memory, bandwidth). CPU is "no less than" , memory is "exactly that much" (includes VM overhead), bandwidth is "exactly that much". CPU resources may be enforced to "exactly that much", using the new --cap_cpu option when starting the application.
  19. When starting an application with a specified amount of minimum CPU, it is not guaranteed that the application will get exactly the amount of specified CPU. For example, if an application is started with cpu=2, it is possible that the application will receive 1.97 CPU as observed by adding up all of the assigned CPU to all components of the application. This is due to rounding errors that may occur while trying to assign CPU to each individual component.
  20. 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.
  21. Grids in which linear scalability of performance is important should be built using servers that are as uniform as possible in CPU type/speed, memory size and disk capacity. CA AppLogic® will work correctly in grids assembled from servers with different amounts of hardware resources; however, on such grids you may experience sub-linear performance.
  22. There is no user visibility during a grid controller restart due to a grid controller VM failure. If the grid controller VM fails and CA AppLogic® restarts the grid controller VM, there is no user visibility while the controller is restarting. Typically it takes 1-2 minutes for the grid controller to restart on its own. If the grid controller is unavailable for more than 5 minutes, contact CA Support.
  23. Creation of an NTFS03 volume always results in an NTFS08 volume. NTFS08 volumes may be used with Windows 2003 Server.
  24. The net_discover command for grid and server is not supported on ESX-based grids/servers.
  25. When using a SAN with your CA AppLogic® grids, ensure that there is at least 500GB of free space 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.
  26. When using a SAN with your CA AppLogic® 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.
  27. To use CA AppLogic® appliances based on the latest OS distributions (such as Fedora Core, Ubuntu, Debian, and CentOS), configure the new field engineering code of 128 on the boundary of the appliances. This new 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.
  28. If either your primary or replica BFC database is lost or corrupted, you may be able to recover it from an automatic backup that is always being run from the 3.1 version of the BFC. These backups actually live 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: