Reference Information › CA AppLogic Support Knowledge Base › Overview of Support Knowledge Base › AppLogic Best Practices

AppLogic Best Practices

AppLogic First Call / Best Practices Guidelines

Initial guidelines for supporting the Applogic cloud platform

First and foremost I would like to start by saying that almost every single ticket that comes into support will be different. Unless of course it is a known bug and there is a patch in development. Some of the most common issues however are (Commonly education or user error):

1. Application & Appliance Issues (Booting / Crashing).

   Things to ask:

   • Find out if it is Linux or Windows
   • 3t log list -To find out what applogic is reporting-or cat /var/log/messages
   • Were any changes done right before the issues started to occur? (Can they be un-done to see if the appliance can come back up properly)
   • Has the system been maintained properly? (volumes)
2. 2) Customer Education

   (System Limitations, Feature requests, appliance & application limitations, general inquiries, architectural inquiries, application & appliance provisioning (primarily windows), Applogic networking, appliance replication & clustering, and several others)

3. Physical hardware problems at the server layer (Memory, disk, CPU, I/O(Wait), ect...).
4. Corrupt, missing, degraded, stuck and orphaned volumes (Raid configurations and driver support)
5. Controller Outages & Crashes (Grid, Server, …)
6. Physical Network Misconfiguration
7. System Filer problems (Volume management)
8. Access control
9. Version Patching
10. aldo errors

Helpful commands:

3t (If issued alone this will put you in the 3t shell on the grid controllers)

You can most commonly compare the 3t shell to that of a Cisco or Extreme Networks switch. You can do tab completion just like in a bash shell and for each object and command you can tab out help information based on each command.

If you do not want to enter the 3t shell you can prepend 3t to each of the following commands at the actual bash command line and get the same results (Without tab completion though). This is a helpful feature for scripting.

Commands available in or out of the 3t Shell (From 3t Help):

valid simple commands: ?|help, exit, ca, clear, ls
valid objects:
app|application, class, cat|catalog, comp|component, grid,
ha, iface|interface, log, msg|message, srv|server,
usr|user, util|utility vol|volume
valid commands:
break, build, check, clean, continue, copy, config,
create, destroy, disable, enable, export, format, fscheck,
fsrepair, get, get_desc, identify, import, info, list,
lock, login, manage, mark, migrate, move, net_discover,
power_off, power_on, power_cycle, provision, put_desc, reboot, rename,
repair, reset, resize, restart, set, shutdown, ssh,
start, stop, unlock.
type 'help object' for info about an object and to see a list of valid commands
type 'help command' to see a list of objects to which it applies
type 'help object command' for details on a specific command

Example within the 3t shell:

(root)testgrid>app list -a This will show you a list of running apps on the grid
-------------------------------------------------------------------------------------------------------
(root)testgrid>vol list -all TEST_APP -This will show you all of the volumes associated with TEST_APP
Example at the bash prompt:
root@testgrid$3t app list -a Does the same as above
-------------------------------------------------------------------------------------------------------
root@testgrid$3t vol list --all TEST_APP 
Unknown macro: {Does the same as above} 
-------------------------------------------------------------------------------------------------------
** Quick things to do when you jump on a grid (or right before you leave) with a client is to run volume and server checks to make sure the system is being maintained properly. If not, it’s a good time to point it out to a customer.
In order check the health of volumes and servers run the following commands:
3t vol check
3t vol repair