The following section describes Grid records.
The following table lists the possible state values for a grid. The API State Name column lists the state as it appears in the grid_record of the API. The UI State Text column lists the descriptive text displayed in the user interface for the state value. The Description column includes more information about what is happening for the specific state.
|
API State Name |
UI State Text |
Description |
|
resource_allocated_state |
Stopped |
The BFC representation of the grid is created, but no servers are assigned to it yet. |
|
resource_getting_ready_state |
Preparing to start |
Grid is searching and reserving servers for its use. |
|
resource_getting_ready_failed_state |
Start failed |
The grid failed to acquire the number of servers specified by its minimum server hardware configuration and is finishing processing before moving to a failed state. |
|
resource_ready_state |
Stopped |
The grid has servers assigned, but is not currently running due to user choice. This state is usually reached because a user used the BFC to stop the grid. |
|
resource_wait_to_run_state |
Preparing to start |
In the case of a grid, it passes through this state very quickly and no processing was done. |
|
resource_booting_state |
Starting |
This state applies to grid creation processes and grid restart. |
|
resource_cancel_boot_state |
Canceling start, waiting for operations to complete. |
A user issued a stop or delete to the grid during start. The grid is attempting to cleanly stop this operation. |
|
resource_running_state |
Running |
The grid is up and running and the BFC has not detected any issues with how it is running. |
|
resource_waiting4_uctl_status_state |
Grid operation in progress |
This can occur for any of the following reasons: Upgrade - The BFC is in the process of upgrading the grid. Update grid - The BFC is in the process of updating the grid. Add server - In the process of reimaging a new server and adding it in to the running grid. Update power credentials - The user updated the credentials for one or more power controller. The BFC is in the process of configuring CA AppLogic with this additional data. Apply hotfix - One or more hotfixes are being applied to the grid. Apply SSH keys - The user has performed the "Manage SSH Keys" operation and the BFC is updating the grid controller and the grid servers with the new key information. |
|
resource_uctl_breached_state |
Grid requires user action |
An attempt to perform one of the operations in resource_waiting4_uctl_status_state has failed or has reached a stopping point where the BFC needs user input. For example: Upgrade staged - Normal processing: expected when a user does a grid upgrade and selects 'Reboot Later'. Too many servers in grid - Normal processing: The number of servers in the grid exceeds the target. Waiting for a user to intervene. Not enough servers - Normal processing: The grid has fewer running servers than target. Upgrade failed - Failure: an attempt to upgrade the grid failed. Grid controller offline - CA AppLogic not running correctly: The BFC has started the servers and handed control of the servers to CA AppLogic. After doing so, the BFC has lost contact with the grid controller. Grid server offline - CA AppLogic not running correctly: The grid controller is online, but one or more of the servers in the grid are not currently participating in the grid. Grid update failed - One of the various update operations has failed. Apply hotfix failed- The BFC failed in applying a hotfix to the grid. This can only happen when a grid server fails in the process of applying a hotfix or if an invalid hotfix was imported. |
|
resource_waiting4_ucth_status_state |
Remove server in progress |
The user has selected a server for removal from the grid and the grid is working on removing it. |
|
resource_ucth_breached_state |
Remove server failed |
The BFC failed to remove a specific server from the grid, or the grid currently has more servers than its Target and is waiting for a user to select which server to remove. |
|
resource_wait_to_stop_state |
Preparing to shut down |
A user has issued a "Stop" command to the grid using the BFC. The BFC is running a shutdown of the grid servers. |
|
resource_failed_running_state |
Failed, running |
The grid failed during the start process. The BFC has left the grid servers in whatever state they reached so that a person can debug the problem. |
|
resource_failed_wait_to_stop_state |
Failed - waiting to shut down |
After a stop in the resource_failed_running_state, the grid is in the process of shutting down the servers. |
|
resource_failed_ready_state |
Failed, stopped |
Grid servers are stopped. Only reached after a stop in the resource_failed_running_state. |
|
resource_failed_state |
Boot failed |
Grid failed to acquire the SLA configured minimum number of servers. |
|
resource_quarantining_wait_to_stop_state |
Quarantining - preparing to shut down |
A grid delete operation was performed on a running (or partially running) grid. The grid has gone in to the resource_quarantining_wait_for_reset_state. |
|
resource_quarantining_wait_for_reset_state |
Quarantining - preparing to clean up |
Each grid server is sanitized. The first part of each partition on the disks are zeroed out so that the partition is not accessible and the server will not boot into the grid operating system until it is reimaged. |
|
resource_quarantined_state |
Quarantined |
Grid will land here for a very short time during the delete process. The BFC infrastructure is cleaning up the last remnants of the grid in its internal data structures. |
The grid record is used for both simple grid create where minimum information is specified and for complex grid create where the user has explicit control and fully specifies all attributes for the grid rather than allowing the system to implicitly specify some of the information. The grid record passed as the payload to the grid creation API contains the following fields:
|
Field |
Type |
Description |
|
comp_id |
integer |
Read-only field that contains the resource component ID for the grid resource. |
|
id |
integer |
The CA AppLogic grid ID. Valid values are 1-31, but may be further constrained by the grid IDs that were specifically configured for use by the BFC being operated upon. |
|
name |
string |
The name associated with the grid. |
|
description |
string |
A description of the grid. |
|
state |
string |
Read-only field that contains the resource state of the grid, for example, resource_allocated_state, resource_running_state, resource_stopped_state. |
|
applogic_version |
string |
The CA AppLogic version associated with this grid, for example, 3.1.9. This field appears as the name field in the version record returned via a BFC API GET operation to the versions URI. |
|
applogic_hotfixes |
list of string |
A list of hotfixes and/or language packs that have been applied to the grid. On create, it specifies the set of hotfixes and/or language packs that should be applied to the grid. On read, it returns the hotfixes and/or language packs that have been applied to the grid. |
|
oem_kit |
string |
The name of an OEM Kit uploaded to the BFC for branding the CA AppLogic Grid Web Access. |
|
xen_config |
grid_server_configuration record |
A record with fields: min, target, max and selection_criteria which are the xen SLA minimum, target, and maximum number of servers for this grid, plus an expression for the server selection criteria. |
|
esx_config |
grid_server_configuration record |
A record with fields: min, target, max and selection_criteria which are the ESX SLA minimum, target, and maximum number of servers for this grid plus an expression for the server selection criteria. |
|
servers |
list of server boot MAC addresses |
A read-only list of boot NIC MAC addresses associated with the servers currently allocated to the grid. In a future release, you can use these MAC addresses to retrieve more detailed information about each server in the grid. |
|
external_network |
string |
The base address and CIDR of the network from which application IP addresses are allocated, for example, 127.10.10.0/24. |
|
ext_dns_1 |
string |
Primary DNS server for the grid. |
|
ext_dns_2 |
string |
Secondary DNS server for the grid. |
|
app_ips |
list of grid_ip_range records |
The application IP addresses reserved for use by this grid's set of applications. Each range identifies the subnet (a read-only field that is the subnet component ID), the VLAN ID for the range (if any), whether the range is public or private, and the range low and high IP address. When specified on input to either a grid create or a grid update operation, the application IP ranges specified are the exact ranges that will be set on the grid and will replace the ranges currently set. Also, on create, this field and the numAppIPs query string parameter are mutually exclusive, only one or the other may be specified. The numAppIPs query string is not supported on update. |
|
app_ip_count |
integer |
This is a read-only field that contains the number of application IP addresses reserved for use by the grid's applications. It reflects the actual number of IPs allocated to the grid, whether they were specified explicitly by the user or selected by the system due to the user specifying the numAppIPs query string parameter to the grid creation operation. |
|
controller_ip |
string |
The IP address that should be or is assigned to the AppLogic grid controller. |
|
default_vlan |
integer |
The default VLAN used by applications on the grid. Valid range is 1-4094. |
|
account_id |
string |
The CA AppLogic account ID for the customer responsible for the grid. |
|
account_key |
string |
The CA AppLogic ssh key assigned to the customer responsible for the grid. |
|
vmware_license_key |
string |
The VMware license key that allows the grid to image servers as ESX servers. |
|
global_user_dir |
A grid_global_directory_config record |
The user directory service to use for role-based access control (RBAC). Currently, none, LDAP, and Active Directory are the types of directory services supported. |
|
grid_controller_name |
string |
The hostname for the CA AppLogic grid controller. |
|
grid_controller_user |
string |
Input-only field that specifies the username for the initial user configured for the CA AppLogic grid controller. |
|
grid_controller_password |
string |
Input-only field that specifies the password for the initial user configured for the CA AppLogic grid controller. |
|
recovery_password |
string |
Input-only field that contains the recovery password for the CA AppLogic grid controller. |
|
stripe_size |
integer |
The disk stripe size in kbytes when disk striping is being used for this grid. |
|
additional_config |
list of string |
Input-only field containing any additional grid configuration parameters in the form ["key=val",...]. |
|
external_storage |
external_storage_nfs record |
Specification of NFS server/path on which AppLogic volumes will be stored. |
You use grid server selection criteria to qualify and rank available servers. After you create the selection criteria clauses using tags, you can control grid server population. Two types of tags are provided: Tags and Smart Tags. You use a Tag to designate basic server allocation. You use a Smart Tag to identify more granular characteristics for a group of servers. Characteristics you can designate include CPU cores, CPU speed, discovery date, memory, power type, and total disk capacity.
When tags are present, they are applied in addition to the minimum server requirements imposed by the CA AppLogic version you select for the grid.
Tags are combined in Conjunctive Normal Form (CNF) clauses to define a set of tests used as the server selection criteria for the grid. The syntax for specifying selection criteria requires translating CNF-specified tests into a (JSON) array of disjointed literals (ORed in priority order) within a list representing the conjunction. Literals within the CNF clauses represent constraints for requirements (that is, Tag names) or disallowed conditions (negated Tag names).
The following examples use hypothetical sets that represent tag selection criteria. You then use CNF statements to yield selection criteria values.
Example 1
In this example you have server tags defined for the members of the following three sets:
Next, assume that you want to designate server criteria for you grid so that the Platinum server is selected before a Gold or Silver server, irrespective of color. In this example, the grid cannot accept a Bronze or Triangle server.
In CNF this is written as:
((Platinum or Gold or Silver) and (not Triangle))
This yields the following selection criteria value:
[["Platinum","Gold","Silver"],["~Triangle"]]
Note that the terms "and" and "or" are absent from the syntax. A conjunction of disjunctions is assumed by using CNF and thus they are implied by the syntax..
This is interpreted as the following, in which each line is tried until enough servers are found to satisfy the grid deficit:
Example 2:
In this example, you decide that a Red server is better than a Blue or Green server. Also, a Yellow tag has been added, but you want to designate that Yellow servers will not work for the grid.
The selection value now becomes:
[["Platinum","Gold","Silver"],["Red","~Yellow"],["~Triangle"]]
This is interpreted as follows:
Example 3:
You could modify the grid selection illustrated in example 2 to add the criteria that the grid exclude not only Yellow servers, but also prefer Blue over Green servers. The selection value can be changed to the following:
[["Platinum","Gold","Silver"],["Red","Blue","Green"],["~Triangle"]]
This will cause the BFC to find servers in the following order until enough servers are found:
Example 4
In this example, the shape criteria include Circles instead of disqualifying Triangles:
[["Platinum","Gold","Silver"],["Red","Blue","Green"],["Circle"]]
This has the following effect on the selection:
Example 5
When you choose to use negation in server criteria, consider the behavior if and when members of a Tag category change. For example, think of what servers would be selected by the above queries if a Square was added as a shape. Also, consider how unknowns are handled. It is quite a bit different to request a server not be a Triangle when there are only Circles and Triangles. Once there are Squares they will be added to Grid1 with the same likelihood as a Circle unless the above refinement to call out Circles explicitly is used.
In the following example, the grid only requires that its servers are not Gold and that they are not Circles.
In CNF this is written as:
((not Gold) and (not Circle))
This is translated to the following selection string:
[["~Gold"],["~Circle"]]
If Gold servers were mistakenly excluded the criteria is modified to:
[["~Circle"]]
The grid record includes an external_storage field which you can use to specify an external location for CA AppLogic volumes. At present, NFS is the only supported external storage type.
Accessibility of external storage is not validated as part of the creation operation by default. This is consistent with the behavior of the BFC UI, where storage can be validated with a separate operation. The API create will validate storage accessibility (and fail the create operation if the storage can't be accessed) when the checkExternalStorage flag is present in the querystring of the POST operation URI.
Note: If you want to change from one NFS share to another share, you can use the stopGrid query parameter to stop the grid as part of the update. After the grid stops, you can copy volumes from the old NFS share to the new NFS share manually.
A grid_server_configuration record contains the server hardware values for the minimum, target, and maximum number of servers to allocate for a grid plus an expression indicating the server selection criteria. There is one instance of the record for the Xen Config and another for the ESX Config.
|
Field |
Type |
Description |
|
min |
integer |
Minimum number of servers of this type required by the grid. |
|
target |
integer |
Target number of servers of this type for the grid. |
|
max |
integer |
The maximum number of servers of this type allowed in the grid. |
|
selection_criteria |
list of lists |
An expression in Conjunctive Normal Form (CNF) used to select servers for the grid based on tags that are associated with the servers. These tags are either simple tags (assigned directly to a server or servers) or smart tags (associated with servers by specifying a set of hardware requirements for the servers to be selected and assigning to the tag). In both cases, the tags specified in the selection criteria are themselves simple string tag names which are included in the CNF expression. The simplest CNF (representing a selection criteria of servers that are associated with a single tag) would be [["TagName"]]. Server selection criteria need not be specified (that is, set to null). Any server that meets the minimum requirements that are specified by the CA AppLogic version suffices. |
An external_storage_nfs record identifies an NFS server and export path used to store CA AppLogic volumes.
|
Field |
Type |
Description |
|
host |
string |
The NFS server host (hostname or IP address). |
|
path |
string |
The path exported by the NFS server. |
A grid_ip_range record identifies the subnet including the range, a public/private designator, and integer low and high address range values. Each range of application IP values represents addresses configured for use by applications running on a grid.
|
Field |
Type |
Description |
|
subnet_id |
integer |
Read-only field containing the component ID of the including subnet. |
|
vlan |
integer |
The VLAN number of the VLAN to which this IP range belongs. If this range does not belong to a VLAN, this field displays "JSON null". |
|
public_private |
string |
Indicator of public or private use. Valid values are "public" and "private". |
|
ip_low |
string |
The lowest address in an application IP range. |
|
ip_high |
string |
The highest address in an application IP range. |
|
display_subnet |
string |
A display name for the subnet, such as 10.10.10.0. |
|
display_vlan |
string |
A display name for the VLAN which is the VLAN number in the 0-4096 range. |
|
range_size |
integer |
The number of IP addresses that this range contains. |
A grid_global_directory_config record specifies the access parameters for the global directory service used for RBAC authentication of CA AppLogic grid users.
|
Field |
Type |
Description |
|
type |
string |
Current types are none, LDAP, and active_directory. |
|
host |
string |
The IP address of the server hosting the directory service. |
|
port |
integer |
The TCP port number on which the directory service listens. |
|
use_tls |
boolean |
A boolean value to indicate if the directory service uses transport layer security. |
|
user_base_dn |
string |
The base distinguished name (DN) that holds the user entries. |
|
group_base_dn |
string |
The base distinguished name (DN) that holds the group entries. |
|
user_id_attr |
string |
The name of the attribute that holds the user id. |
|
group_id_attr |
string |
The name of the attribute that holds the group id. |
|
login_cache_period |
integer |
The length of time (in seconds) for which a login remains valid before needing to re-authenticate. |
|
Copyright © 2013 CA Technologies.
All rights reserved.
|
|