The following issues have been observed in CA AppLogic® releases but are extremely difficult to reproduce (if at all) and have only been observed once or twice. If any of these issues appear on your grid, please send a bug report to CA describing which problem occurred and which CA AppLogic® commands were executed that led to the failure.
A server in the grid rebooted on its own due to a crash in the Linux kernel in dom0 of the server. This would not cause the entire grid to fail like in previous CA AppLogic® releases; but could cause application downtime. In such a case CA AppLogic® restarts the appliances that were running on the failed server on other servers in the grid. If this issue is observed on your grid, contact CA Support.
In CA AppLogic® 2.4, there have been several cases where a server loses connection to the grid controller and reboots. This causes all of the appliances that were running on the server to be rescheduled on other servers in the grid and can also cause application downtime. It is unknown why the servers are losing their connections to the grid controller.
If the server's connection to the grid controller is dissolved, the server tries to reconnect to the grid controller and if successful, the server remains operational and there is no application downtime. If the server cannot reconnect to the grid controller for one minute, the server is rebooted and application downtime occurs. When a server loses its connection to the grid controller, a message is logged to the dashboard. If this problem is observed, contact CA Support.
On CA AppLogic®, resizing 4 NTFS volumes at the same time caused all four volume resize operations to fail. This issue has been observed only once.
While NASR was replicating an 800MB file on a 1GB volume, the NASR appliance became unresponsive. CA is unable to reproduce this issue. If this issue is encountered on your grid, contact CA support.
User opened six graphical consoles to different windows appliances running on the grid (opened at the same time). Upon opening the seventh graphical console, one of the servers rebooted and rejoined the grid. The appliances that were running on the failed server were restarted on other servers within the grid. This issue has only been observed once.
We have identified the following known problems with the Backbone Fabric Controller (BFC) in this release:
su - bfcadmin
Important! After breaking this dependence, your system will be running without replica, so go back into the UI and establish another replica at the same or a different location.
Please do not use the “3t grid shutdown” command on a grid.
When this occurs, doing a “service nfs restart” on the BFC should resolve the problem.
If you get this message, simply hit the “Esc” key to continue the install.
In CA AppLogic® 3.5, some Broadcom Corporation NetXtreme II NICs misreport as being too slow. If you get this error, you can try rediscovering the server.
If the BFC runs out of space before it is able to shutdown, you will need to restart the BFC once you free-up space for it to function properly again.
If you are performing an unattended install with this version of the product, your password cannot contain a “=”
This bug could occasionally allow servers into grids that should be blocked. If the ports are properly configured, this problem will not be encountered.
If you need to use more than 256 characters, simply break those parameters into more than one update of the grid.
On some servers, the CPU count reported by the system is the same when Hyper-Threading is disabled as when it is enabled. This has been observed on some Dell R610s.
This is an issue with how parameters are written to the configuration file passed to aldo set. If in the UI the user enters their data with a comma between entries, the same failure is seen. The work-around for the BFC API is to only pass a single string with a newline separator between the entries.
For example:
\"additional_config\":[\"ext_dns1=155.35.34.108\next_dns2=141.202.1.108\"]
Instead of:
\"additional_config\":[\"ext_dns1=155.35.34.108\",\"ext_dns2=141.202.1.108\"]
This issue occurs because deleting a subnet in 3.1 does not properly fail if you have grids with application IP address ranges that are in that subnet. The upgrade process looks for the missing subnet on upgrade and then fails because it is missing. For the workaround, use the instructions from the failed upgrade to restore your previous 3.1 BFC installation. Then, go to each of the grids and remove any application IP address ranges from the grid that does not belong to a currently configured subnet. In some cases, such as when you subsequently re-added the same subnet with a new CIDR prefix length parameter, the range may be within the bounds of a current subnet, but the underlying subnet component will be incorrect and still cause an upgrade failure. You should validate that the subnet in the BFC matches the parameters of the application IP address range in the grid controller UI to be sure.
The isotool -o parameter does not correctly show the USB devices attached to the machine (CentOS 5.5 box). This is a known issue with CentOS 5.5. To resolve this, you must issue the following shell command as user root:
service haldaemon restart
If the graphics rendering option is not set correctly in Internet Explorer 9, graphs in the BFC do not display correctly. Affected graphs appear in the BFC Dashboard, Grids, and Servers pages.
To fix this problem, in Internet Explorer 9 click Internet Options on the Tools menu. Click the Advanced tab and locate the Accelerated graphics section. Select the Use Software Rendering check box. Save your changes and restart IE.
This problem can be encountered if you have many VLAN/subnet sets and by-pass the warning during the upgrade that this might be a problem. If you get this warning during the upgrade, please contact Support before proceeding.
If you need to set these many MACs to AutoDiscovery (blacklist) mode, it would be best to use Manual Configuration (whitelist) mode with 3.5.
Please ensure you have external IP addresses available when added servers to a BFC.
As part of the process defined for single bare metal ISO creation using the Bare Metal ISO tool, the user needs to place bfcbaremetai.iso and bfcinstall.iso in the directory declared through the ‘rawiso’ parameter in Bare Metal ISO tool project file. The user then needs to assign ‘644’ permission to these ISOs using following commands:
chmod 644 bfcbaremetal.iso
chmod 644 bfcinstall.iso
Due to this bug you cannot directly swap the controller and application IPs with each other in one step. If you must do this, first set them to some other values, then you may set them again to the intended values.
The IP ranges get mapped to the correct VLANs during an upgrade from pre-3.5.1 to 3.5.1 or later except for one case. If you create a grid and later add a network with a VLAN to that grid, the IPs reserved for that VLAN will remain reserved on the default (untagged) network after the upgrade. If you need to recover those specific IPs, please contact Support.
If you attempt to add a tagged network to an untagged grid via the API, the call will succeed, instead of returning 400 Bad Request.
Some of the bug fixes and modifications in BFC 3.5.2 changed a small number of strings used in the BFC in 3.5.2. Those modified strings are few in number and mostly in the area of VLAN management, but they will appear in English regardless of your language of choice.
|
Copyright © 2012 CA.
All rights reserved.
|
|