Example Temporary Instant Capacity Scenario
| The Temporary Instant Capacity example scenario picks up from where the example from Chapter 10, "Instant Capacity," left off. The rex02 nPartition has two unlicensed CPUs that have been deactivated. This scenario describes how to activate these two CPUs using Temporary Instant Capacity in a situation where the rex02 testing nPartition is serving as a Serviceguard failover node for a production workload. Only when the Serviceguard package is active on the rex02 nPartition should Temporary Instant Capacity CPUs be activated. This scenario will not cover the process of setting up the Serviceguard cluster, nor will it discuss the steps required to automatically activate Temporary Instant Capacity CPUs based on activation of a Serviceguard package. Those two processes are covered in Chapter 16, "Serviceguard," and Chapter 15, "Workload Manager," respectively. The software used to activate, deactivate, and monitor Temporary Instant Capacity is the same software used to manage Instant Capacity. All deactivated CPUs within nPartitions running HP-UX can be activated using Temporary Instant Capacity. Most of the commands shown in this example are identical to those shown in Chapter 10, "Instant Capacity." There are three primary differences between managing Temporary Instant Capacity and Instant Capacity.
Configuring E-mail ConnectivityThe version of Temporary Instant Capacity used in this chapter requires e-mail connectivity to HP for asset reporting. Configuring and sending asset reports by e-mail consists of the following steps.
Viewing the Initial StatusOnce e-mail asset reports are being sent to HP, the next step is to view the configuration of the complex. Listing 11-1 shows the initial Temporary Instant Capacity status of the complex. Initially, there is zero temporary capacity available on the system. However, two unlicensed CPUs in the rex02 nPartition are inactive. These two unlicensed CPUs will be used as Temporary Instant Capacity when a Serviceguard failover occurs to the nPartition. Listing 11-1. Initial Instant Capacity and Temporary Instant Capacity Configuration# icod_stat Software version: B.06.01 System ID: rex02 Serial number: USE4416CNL Product number: AB240A Unique ID: ad2b3532-abd9-11d8-a988-7877a7f45c12 System contact e-mail: bryanj@rex01 From e-mail: bryanj@rex01.fc.hp.com Asset reporting: on Exception status: No exception Local Hard Partition Information -------------------------------- Total processors: 4 Intended Active processors: 4 Active processors: 2 Licensed processors that can be activated: 0 Processors that can be activated if licensed: 2 Processors that cannot immediately be activated: 0 Global iCOD Information ----------------------- iCOD cells: 0 Actual inactive cells: 0 iCOD processors: 2 Actual inactive processors: 2 iCOD Memory: 0.0 GB Actual inactive Memory: 0.0 GB Temporary capacity available: 0 days, 0 hours, 0 minutes Processors using temporary capacity: 0 Projected temporary capacity expiration: N/A Allocation of iCOD Resources Among Partitions ------------------------------------------------------------- nPar Inactive Inactive Inactive ID Cells Memory CPUs nPar Name ==== ======== =========== ======== ====================== 0 0 0.0 GB 0 rex01 1 0 0.0 GB 2 rex02 (local) N/A 0 0.0 GB 0 Unassigned Cells iCOD Partition Configuration Information --------------------------------------------------------------- Intended Actual Compatible nPar Active Active Total Software ID CPUs CPUs CPUs Installed nPar Name ==== ======== ====== ===== ========== ==================== 0 12 12 12 Yes rex01 1 4 2 4 No rex02 (local) Acquiring a Temporary Instant Capacity CodewordTemporary Instant Capacity can be purchased in increments of 30 CPU days. After you have purchased Temporary Instant Capacity, go to the Instant Capacity portal to acquire a codeword. The Instant Capacity portal at http://www.hp.com/go/icod/portal requires the following information for a Temporary Instant Capacity codeword:
Like Instant Capacity, the amount of temporary capacity is tracked at the complex level. As a result, Temporary Instant Capacity can be used in any nPartition running HP-UX in the complex, even simultaneously in multiple nPartitions. The product number, serial number, and audit snapshot are available from the icod_stat command. Listing 11-2 shows the command displaying the system snapshot that is required when you acquire a Temporary Instant Capacity codeword. Listing 11-2. Instant Capacity System Snapshot # icod_stat -s Product number: AB240A Serial number: USE4416CNL Audit snapshot: mFXkeaT.txEdPkq.P2VKsFM.dD5ztet.fVfBXt7.8VTqT5g.ALWjhdm. KMHQ1TF.J3AXaMg.qhP2 Once you have the icod_stat system snapshot, you can use the Instant Capacity portal to acquire the Temporary Instant Capacity codeword. Figure 11-2 shows an example screen from the Instant Capacity portal on the Create codewords page. Notice that the screen is different from the Instant Capacity right-to-use codeword page shown in Chapter 10, "Instant Capacity," as the number of CPUs, cells, and memory is not required for Temporary Instant Capacity. Instead, the number of CPU days is required. Figure 11-2. Temporary Instant Capacity Codeword Portal Applying the Temporary Instant Capacity CodewordAfter you have received a Temporary Instant Capacity codeword from the portal, the next step is to apply the codeword to the system. The icod_modify command applies the Temporary Instant Capacity codeword with the C argument. The Temporary Instant Capacity codeword applied in this example contains 90 CPU days of CPU time. This can be consumed by one CPU that is active for 90 days, two CPUs active for 45 days, or any other combination of CPUs and time. Temporary Instant Capacity does not need to be consumed in a continuous block of time and is debited only while unlicensed CPUs are active. When the unlicensed CPUs are deactivated, the Temporary Instant Capacity balance does not change. # icod_modify \ > -C XJ64Fa4.nsAFEiG.hJE9603.Nz3L0Xg-FH5G5eu.YB1wiL3.LFQDjWT.p5efEz7 The following valid codeword has been applied to the complex: Temporary Capacity Codeword 90 days, 0 hours, 0 minutes Execute the icod_stat(1M) command to see the results of the application of this codeword. Listing 11-3 shows the status of the system after you have applied the codeword. There are now 90 days of temporary capacity on the system. At this point, unlicensed CPUs in any nPartition in the complex running HP-UX may be activated as temporary capacity. Listing 11-3. Temporary Instant Capacity Status after Applying Codeword# icod_stat [...] Global iCOD Information ----------------------- iCOD cells: 0 Actual inactive cells: 0 iCOD processors: 2 Actual inactive processors: 2 iCOD Memory: 0.0 GB Actual inactive Memory: 0.0 GB Temporary capacity available: 90 days, 0 hours, 0 minutes Processors using temporary capacity: 0 Projected temporary capacity expiration: N/A [...] Activating Temporary Instant CapacityTo activate unlicensed CPUs you will need to specify a special argument in the icod_modify command. As shown in the following command, the t option is required when you activate unlicensed CPUs that are intended to consume Temporary Instant Capacity. If you intend to defer activation of the CPUs until the next reboot, the D argument should be added to the command. important Always specify the t option when activating temporary capacity. Failure to specify the option will cause the command to fail and zero CPUs will be activated. Only when the t option is specified will the Temporary Instant Capacity software allow the unlicensed processors to be activated and begin debiting Temporary Instant Capacity. The following command also shows a description of the activation of unlicensed CPUs. This field is logged in the Instant Capacity log file and is sent via e-mail to the system contact when the CPUs are activated. The final field in the command is the full name of the administrator activating the command. The icod_modify command must be executed by root, so this field allows an administrator to provide clarity about exactly who activated the processors. # icod_modify -t -a 2 \ > "Activating two Temporary Capacity \ > CPUs for failover testing":\ > "Bryan Jacquot" 4 processors are intended to be active and are currently active. Processors using temporary capacity: 2 Projected temporary capacity expiration: 10/09/04 19:00:00 After the unlicensed CPUs have been activated, an e-mail is sent to the system contact for the nPartition. Remember, this field is configured using the icod_modify command. Listing 11-4 shows the e-mail that is sent to the system contact when the temporary capacity is activated. Listing 11-4. Email Notification for Temporary Instant Capacity Processor ActivationDate: Wed, 25 Aug 2004 19:00:20 -0600 (MDT) To: bryanj@rex01 Subject: iCOD Configuration Change Notification A configuration change has been made to the following system: rex02 One or more processors were activated. Details of the change include: Time of change: 08/25/04 19:00:20 Previous number of active processors: 2 Current number of active processors: 4 Number of processors to be active after reboot: 4 Description of change: Activating two Temporary Capacity CPUs for failover testing Person making change: Bryan Jacquot System contact e-mail: bryanj@rex01 If you are the system contact and do not want to receive this type of notification in the future, it can be disabled by executing the following command on the system in question: /usr/sbin/icod_notify -n off To turn notification on, execute: /usr/sbin/icod_notify -n on The status of the complex after activating the unlicensed CPUs is shown in Listing 11-5. This command was executed approximately 30 minutes after the temporary capacity was activated. Temporary Instant Capacity software does not continuously monitor temporary capacity. Instead, Temporary Instant Capacity is debited every 30 minutes. If the icod_stat command had been executed immediately after the activation of the CPUs, the output would have most likely stated that the full 90 days of temporary capacity was available. Since there are two active CPUs consuming temporary capacity, after approximately 30 minutes of clock time, a total of one CPU hour of temporary capacity has been consumed. Therefore, the Temporary Instant Capacity software reports that 89 days and 23 hours remain. note Temporary Instant Capacity accounting is not performed continuously. Instead, the Temporary Instant Capacity software periodically wakes up and takes a snapshot of the system and then goes back to sleep. Executing the icod_stat command every minute will not result in immediate updating of the temporary capacity available. Listing 11-5. Temporary Instant Capacity Status after Activating Processors# icod_stat [...] Local Hard Partition Information -------------------------------- Total processors: 4 Intended Active processors: 4 Active processors: 4 Licensed processors that can be activated: 0 Processors that can be activated if licensed: 0 Processors that cannot immediately be activated: 0 Global iCOD Information ----------------------- iCOD cells: 0 Actual inactive cells: 0 iCOD processors: 2 Actual inactive processors: 0 iCOD Memory: 0.0 GB Actual inactive Memory: 0.0 GB Temporary capacity available: 89 days, 23 hours, 0 minutes Processors using temporary capacity: 2 Projected temporary capacity expiration: 10/09/04 19:00:00 [...] Deactivating Temporary Instant CapacityTemporary capacity is deactivated in much the same way it is activated. The icod_modify command is used along with options to deactivate processors. In this example, testing of Temporary Instant Capacity with the Serviceguard failover has been completed, so both unlicensed processors will be deactivated. Notice that no special option is required when deactivating CPUs. Instead, as soon as the number of active CPUs is less than or equal to the number of licensed CPUs, the Temporary Instant Capacity software stops debiting the Temporary Instant Capacity balance. The D option can be provided in the command to deactivate processors if the change should be deferred until the next reboot. This feature is especially useful when applications running in an nPartition have not been designed to accommodate a dynamic environment in which CPUs are instantly deactivated. Using the D option causes Temporary Instant Capacity to be debited until the reboot is performed. Therefore, the reboot should be performed in a timely fashion to avoid unnecessary use of Temporary Instant Capacity. In the following command, the d (lower case) command line option causes the specified number of CPUs to be instantly deactivated. Since the D (upper case) command line option was not appended to the command, the CPUs are instantly deactivated instead of the deactivation being deferred until the next reboot. # icod_modify -d 2 \ > "Testing deactivation of Temporary \ > Capacity CPUs after failover \ > is restored":\ > "Bryan Jacquot" 2 processors are intended to be active and are currently active. Processors using temporary capacity: 0 Projected temporary capacity expiration: N/A Viewing the Temporary Instant Capacity Log FileBoth Instant Capacity and Temporary Instant Capacity share the same log file. Listing 11-6 shows the log file with the application of the Temporary Instant Capacity codeword, followed by the debit to the temporary capacity. Finally, the log file shows the deactivation of the unlicensed CPUs. In this scenario, the Temporary Instant Capacity codeword was applied on the rex02 nPartition and the unlicensed CPUs were activated in the rex02 nPartition. However, the Temporary Instant Capacity codeword does not need be applied to the same nPartition where temporary capacity will be used. Temporary Instant Capacity codewords apply to the entire complex, so unlicensed CPUs could have been activated in any nPartition running HP-UX in the complex. Listing 11-6. Temporary Instant Capacity Log File< /var/adm/icod.log > Date: 08/25/04 18:58:20 Log Type: Temporary capacity codeword applied Temporary capacity added: 90 days, 0 hours, 0 minutes Date: 08/25/04 19:00:20 Log Type: Configuration Change Total processors: 4 Active processors: 4 Intended Active CPUs: 4 Description: Activating two Temporary Capacity CPUs for failover testing Changed by: Bryan Jacquot Date: 08/25/04 19:30:34 Log Type: Temporary capacity debit Temporary capacity CPUs: 2 CPU minutes debited: 60 Temporary capacity available: 89 days, 23 hours, 0 minutes Date: 08/25/04 19:35:43 Log Type: Configuration Change Total processors: 4 Active processors: 2 Intended Active CPUs: 2 Description: Testing deactivation of Temporary Capacity CPUs after failover is restored Changed by: Bryan Jacquot |
EAN: 2147483647
Pages: 197