After the sharing rights codeword and the grouping
rules have been applied to the Group Manager, a GiCAP group can be
created by issuing the icapmanage command using
the -a and -g options. Members are
added by issuing the icapmanage command using the -a option, the -g option to select the
group name, and the -m option to specify a name for
the new member along with a list of hosts running on the system. The
list of hosts must include at least one host per nPartition on the
system.
Note that a single partition of a complex cannot
join a GiCAP group; all partitions of a complex must be specified
when adding a group member. An iCAP server can join a group if the
Group Manager has at least as many GiCAP Sharing Rights as the total
number of cores without usage rights on that server. Members can be
added to a GiCAP group as long as there are sufficient GiCAP Sharing
Rights available and it is permitted by the grouping rules. Each member
that joins the group decreases the available GiCAP Sharing Rights
by the number of cores without usage rights contributed by that member
complex.
While the size of GiCAP groups is not specifically
restricted, performance of group-related functions is affected by
the number of group members and the number of partitions for each
member server, as well as the types of hardware involved. A larger
number of group members can cause an increase in startup time for
the Group Manager and may also affect the performance of icapmodify commands when a transfer of usage rights occurs.
If temporary capacity is being used, then the size of the group may
also increase the amount of communication time needed for tracking
of temporary capacity.
When adding groups to a Group Manager system,
the icapmanage -T command can be used to test
hardware compatibility for one or more host systems in order to determine
which groups the systems can join. When used in combination with the -g option to specify a group name, it tests whether the
specified host systems have hardware which is compatible with the
group. Without the -g option, it reports which groups
of all the groups managed by this Group Manager have hardware which
is compatible with the host systems. The host names do not have to
be from the same complex, but in order to best predict the possibility
of being able to join a group, the list of hosts should include all
the nPartitions for a particular complex. If the hosts are not compatible
with each other, no groups will be reported as having compatible hardware.
You can create multiple GiCAP groups and they
can be managed by the same Group Manager or by different Group Manager
systems. Systems which do not have any Instant Capacity components
can be part of a GiCAP group. Deactivating resources on these systems
allows them to loan usage rights to other members in the group.
The following example shows how to create a group
and show group status:
Example 7-3 Creating a Group
> icapmanage -a -g one
Group one added.
> icapmanage -s
Software version: B.08.02
32 GiCAP Sharing Rights: 0 in use, 32 available
Group ID: one
Group Members:
No members found |
The following example updates the grouping rules
for all groups managed by the Group Manager, tests if a server complex
has hardware which is compatible with group “one”, and
adds a member called “IT” to that group. Note that when
you first add new members to a group, you will be prompted for the
root password for each specified host. The password is used only to
establish an SSH authorization for secure communication and is not
saved or stored.
Example 7-4 Adding a Member to a Group
> icapmanage -i -U /tmp/GiCAP.rules
> icapmanage -T node.corp.com -g one
root@mypar.node.corp.com’s password:
The server(s) are compatible with GiCAP group one
> icapmanage -a -m IT:node.corp.com -g one
Member IT added to group one. |
Following is an example of the output of icapstatus on a group member system:
Example 7-5 Example Output of icapstatus on a group member system
 |
> /usr/sbin/icapstatus
Software version: B.11.23.08.03
System ID: node
Serial number: USR4020003
Product number: A6093A
Unique ID: Z3e0ec8e078cd3c7b
System contact e-mail: mjones@corp.com
From e-mail: Set to the default ('adm')
Asset reporting: on
Temporary capacity warning period: 15 days
Exception status: No exception
Member zoo6 in GiCAP group MyGroup, managed by node.corp.com
Borrowed core usage rights: 0
Borrowed cell usage rights: 0
Borrowed memory usage rights: 0.0 GB
Local nPartition Status (Wed, Dec 19, 2007 12:34:56 PM)
-------------------------------------------------------
Total number of configured cores: 8
Number of Intended Active cores: 2
Number of active cores: 2
Number of inactive cores: 6
Additional cores that can be activated with current usage rights: 0
Number of cores that could be activated with additional usage rights: 6
Number of cores that can be activated with temporary capacity: 6
Number of cores currently unavailable for assignment: 0
Instant Capacity Resource Summary
---------------------------------
Number of cells without usage rights: 0
Number of inactive cells: 0
Amount of memory without usage rights: 0.0 GB
Amount of inactive memory: 0.0 GB
Number of cores without usage rights: 6
Number of inactive cores: 6
Number of cores using temporary capacity: 0
Temporary capacity available: 60 days, 0 hours, 0 minutes
Projected temporary capacity expiration: N/A
Allocation of Instant Capacity Resources among the nPartitions
--------------------------------------------------------------
Intended Actual
nPar Total Active Active =======Inactive======= Runs
ID Cores Cores Cores Cores Memory Cells iCAP nPar Name
==== ===== ======== ====== ====================== ==== ==================
0 8 # 2 2 6 0.0 GB 0 Yes zoo0 (local)
1 8 8 8 0 0.0 GB 0 Yes zoo1
N/A 0 N/A N/A N/A 0.0 GB 0 N/A Unassigned Cells
# Value for Intended Active not specifically set and defaults to the
number of configured cores in active cells.
|
|
Printable version
