Techniques for creating system pattern Scaling Manager mode types

This article describes how to build a virtual application pattern that implements the automatic extension of the http://www.aliyun.com/zixun/aggregation/12423.html "> virtual system Pattern Instance nodes." This technology utilizes virtual application mode policies, monitoring frameworks, and virtual system patterns to clone APIs. The virtual system mode (VSP) model defines the cloud workload as a middleware mirroring topology. The VSP middleware workload topology can have one or more virtual mirrors, or parts. Each part of the workload model can be configured for static expansion. At deployment time, IBM Pure Creator System (hereinafter referred to as Pureapplication) creates a VSP instance of many virtual machines (VSP instance VM nodes) based on the extension settings on the part. The VSP model does not support automatic extensions based on extended policies.

This article describes how to build a schema type for virtual application Mode (VAP) that you can use as an extension manager to dynamically add and remove VSP instance VM nodes based on user-defined policies. This article assumes that you have learned how to use the VAP Plug-in Development Kit (VAP PDK) to build a VAP pattern type and plug-in, and to familiarize yourself with the VAP extension framework.

Create a VAP pattern type auto-Extend VSP instance

The following subsections describe how to create a "VSP scaling Manager" VAP mode type. The VAP mode type can act as a manager to facilitate automatic expansion of the VSP instance VM nodes. The technology leverages the VAP monitoring, policy framework, and VSP Clone APIs. Building this pattern type involves the following steps:

creates the VAP application model meta data and captures the details of the VSP instance. Create a policy object that defines an extension policy. Create a topology template that transforms the application model into a topology document. Create a monitoring meta model and a monitoring script to monitor the VSP instance. Creates a VSP instance of the VM node extension script.

Case

In this article, we will use the WebSphere cluster VSP as the target VSP for automatic scaling. As shown in Figure 1, the WebSphere cluster VSP consists of a Deployment manager part, a custom node part, and an IBM HTTP server part. In the following sections, you will learn how to automatically extend custom node parts based on the usage of your system's CPUs. You can use this technique to extend any VSP part based on any user-defined extension criteria.

Figure 1. WebSphere Cluster VSP

Step 1: Create the VAP application Model meta data

To extend the VM node of the VSP instance, you need to perform the following user input:

VSP Instance Name the VSP node part name accesses the user credentials required by the running instance to perform the user credentials required by the VSP command-line API (Deployment personnel command line API)

The VSP instance name and the VSP node part name are used to uniquely identify the extended resource. In our WebSphere cluster VSP use case, the value of the VSP node part name is the custom node, and the value of the VSP instance name is the instance name of the deployed WebSphere cluster VSP instance. The instance user credentials are required to perform a monitoring script (using SSH) on the VM to be extended. The Deployer user credentials are required to run the API to add or remove VMS based on the monitored values.

Using the VAP Component Object properties, you can get the input you need from the user. You can use the VAP application model metadata to model the Component object properties. Listing 1 shows the metadata for the application model. Figure 2 shows how these properties are displayed in the virtual Application Builder.

Listing 1. VSP Scaling Manager Property meta model (Metadata.json)

{"id": "vsyscloning", "type": "Component", "label": "Vsys Scaling Manager", "description": "Example for cloning a virtual System "," image ":" Appmodel\/images\/demoapp.png "," thumbnail ":" Appmodel\/images\/thumbnail\/demoappl.png "," Attributes ': [{' id ': ' CLONENODE ', ' type ': ' String ', ' required ': true, ' label ': ' Virtual System Node ',}, {' id ': ' clonevsys ' , ' type ': ' String ', ' required ': true, ' label ': ' Virtual System Instance Name ',}, {' id ': ' vsyspass ', ' type ': ' String ', ' Required ': True, ' label ': ' Virtual System password ', ' displayType ': ' Password '}, {' id ': ' dephost ', ' type ': ' String ', ' Required ': True, ' label ': ' Deployer Host Name ',}, {' id ': ' depuser ', ' type ': ' String ', ' required ': true, ' label ': ' Deployer User id ",}, {" id ":" Deppass "," Type ":" string "," required ": True," label ":" Deployer password "," DisplayType ":" Password "} ] }

Figure 2. VSP Scaling Manager Properties

Step 2: Create a Policy object to define the extension policy

You can use the VAP policy framework to create a VSP automatic extension policy. The VAP policy framework allows you to define a policy object using the VAP Application model metadata. See the scalability and flexibility in the IBM pureapplication System virtual Application Model for more information on how to define policies using the VAP Application model metadata.

Listing 2 shows the policy object definition for the CPU based extension. Figure 3 shows how the policy is displayed in the virtual Application Builder. Using the policy interface shown in Figure 3, users can create an extension policy that extends the VSP instance VM node based on the usage of the VM's CPU. As shown in Figure 3, the default policy definition can command the system to perform an extension, if the CPU usage exceeds 80%, and if it is less than 10%, it is scaled down.

In our WebSphere cluster VSP use case, if all custom node VMS have a CPU utilization of more than 80%, this extension strategy expands the custom node VM and shrinks less than 10%.

Listing 2. VSP scaling Manager's CPU extension policy Object Meta model (Metadata.json)

{"id": "Scalingpolicyofvsys", "label": "Vsys scaling Policy", "type": "Policy", "Applicableto": ["vsyscloning"], " Thumbnail ":" Appmodel/images/thumbnail/clusterpolicy.png "," image ":" Appmodel/images/clusterpolicy.png "," Description ": Vsys Scaling Policy", "groups": [{"category": "Scaling Type", "id": "Cpuvsys", "label": "CPU Based", " DefaultValue ": True," Attributes ": [" Cpuvsys "," ScaleInstanceRange1 "," triggerTime1 ", ...]," attributes ": [{" id ":"] TriggerTime1 "," label ":" Minimum Time (SEC) to trigger Add/remove "," type ":" Number "," Max ": 1800," min ":" Required ": True, "Samplevalue": ", ...}, {" id ":" scaleInstanceRange1 "," label ":" Instance number range of scaling in/out "," type ":" Range ", Min": 1, "Max": "Required": true, "Samplevalue": [1, ten], ...}, {"id": "Cpuvsys", "label": "Scaling in/out when Average CPU usage of clustered members are out of Threshold range (#), ' type ': ' Range ', ' displayType ': ' percentage ', ' required ": True," Max ":" Min ": 1," Samplevalue ": [10, 80], ...} ]}

Figure 3. VSP scaling Manager CPU extension policy

Step 3: Create a Topology template that transforms the application model into a topology document

The pureapplication System IaaS layer uses the topology document to create the VAP instance. Topology documents are generated from the application model. When you use the virtual Application Builder to create VAP, the model is created behind the scenes by the pureapplication system. You can use the rate template in Listing 3 to transform the VSP scaling Manager VAP application model into a topology document. The template in Listing 3 creates a role named "Clone" and the following parameter values: VSP instance details (obtained by step 1) and policy definitions (obtained by step 2). These parameter values are used in the VSP Auto Extension Manager VAP lifecycle script to drive the expansion of the VSP instance.

Listing 3. VSP Scaling Manager topology Template (VSYSCLONING.VM)

{#set ($spattrs = $provider. Getpolicyattributes ($component, "Scalingpolicyofvsys")) "Vm-templates": [{persistent]: False, ' name ': ' ${prefix}-clone ', ' roles ': [{' parms ': {' dephost ': ' $attributes. Dephost "," Depuser ":" $attributes. Depuser "," Deppass ":" $attributes. Deppass "," CLONENODE ":" $attributes. CLONENODE "," Clonevsys ":" $attributes. Clonevsys "," Vsyspass ":" $attributes. Vsyspass ", #if_value ($spattrs," ScaleInstanceRange1 "," Mininst ": $spattrs. Scaleinstancerange1.get (0), ') #if_value ( $spattrs, "ScaleInstanceRange1", "Maxinst": $spattrs. Scaleinstancerange1.get (1), ') #if_value ($spattrs, "Cpuvsys", ' "Mincpu": $spattrs. Cpuvsys.get (0), ') #if_value ($spattrs, "Cpuvsys", "maxcpu": $spattrs. Cpuvsys.get (1), ') #if_value ( $spattrs, "triggerTime1", "Triggertime": $spattrs. TriggerTime1, ') "iscloned": "FALSE"}, "type": "Sclone", "Name": " Clone '}], ' Packages ': [' Sclone ']}]}

Step 4: Create the monitoring meta model and scripts

In this step, you will create the required resources to monitor the VSP instance VM nodes. You can trigger an extension of the VSP instance VM node based on the monitored values, as defined in the extension policy. You can use the VAP monitoring framework to monitor the VSP instance VM nodes. The VAP monitoring framework will trigger the collection of monitored metrics and then display these monitored indicators in the VAP console. To complete this step, the VAP monitoring framework expects the VAP plug-in to provide the following information:

metric metadata that defines the metric data (listing 4 shows the metric metadata used to measure CPU usage). A script (see the cpuutil.sh in the code sample provided) to collect metrics from the VSP instance VM node. The registration code for the metric metadata and the collection script. Listing 5 shows the Maestro API call to register assets with the framework. Indicators display metadata that graphically displays the collected metrics. Listing 6 shows the metadata used to display the CPU metrics for the VSP instance VM node.

Listing 4. Metric metadata for VSP CPU metrics (Cpuvsyscollector.json)

{"Version": 1, "Update_interval": "Category": ["Cpuvsys"], "metadata": [{"Cpuvsys": {"Update_interval": 60, " Metrics ": [{" Attribute_name ":" Cpuvsys "," Metric_name ":" Cpuvsys "," Metric_type ":" COUNTER "}}}]}

Listing 5. Registration indicator collector (configure.py)

#Register CPU Vsys collectormaestro.monitorAgent.register (' {\ ' node ': '%s ', \ ' role ': '%s ', \ ' collector ': " Com.ibm.maestro.monitor.collector.script ", \" config ": {\" metafile ":"/home/virtuser/collectors/ Cpuvsyscollector.json ", \" executable ":"/home/virtuser/collectors/cpuutil.sh "," Arguments ":"%s ", \" VALIDRC ":" 0 ", \ "Workdir": "/tmp", \ "Timeout": "The" (nodename,rolename,arguments);

Listing 6. Monitor indicators display metadata (Monitoring_ui.json)

[{"Version": 2, "category": "Cpuvsys", "label": "CPU Usage", "Displayroles": ["Sclone"], "displays": [{"label": "CPU Usage of Virtual System Instance Node, MonitorType: "Historicalnumber", "ChartType": "Lines", "metrics": [{] AttributeName ":" Cpuvsys "," label ":" Used Percentage "}]}]

Extending and monitoring scripts

In this section, we'll delve into the monitoring and extension scripts. The script performs the following tasks:

The script retrieves the CPU usage of the VSP instance VM node. In our use case, the script will get the CPU utilization of the WebSphere VSP custom node instance. If the value retrieved is greater than the value specified in the policy, a new VSP instance VM node is created once the maximum value defined by the policy is reached. In our use cases, if a custom node instance's CPU usage exceeds 80, a WebSphere VSP custom node is created until there are 10 such nodes. If the retrieved value is less than the value defined in the policy, all nodes (except the minimum number of nodes defined in the policy) will be deleted. In our use cases, if a custom node instance has a CPU utilization of less than 10, all but two WebSphere VSP custom nodes will be deleted. Finally, the script returns the metric data to the VAP monitoring framework for display in the deployment console.

The script is periodically triggered by the monitoring framework. The trigger cycle is based on the Update_interval parameters defined in the monitoring metadata. In this script, we typically connect the VAP monitoring framework for a short time to trigger an extension of the VSP instance VM node. In the following sections, you will learn how to add or remove VSP instance VM nodes using the VSP Clone and delete APIs.

Step 5: Create a VSP instance VM node extension script

You can use Python scripts to add or remove VSP instance VM nodes. The Python script is triggered by the monitoring script cpuutil.sh using the pureapplication System deployer command line tool. Listing 7 and Listing 8 show the Python script used to add and remove a VSP instance VM node. These scripts use VSP virtual system objects, virtual machine objects, and their clones. They also remove methods to enlarge and reduce the VSP instance VM node.

Listing 7. Script to add a new VSP part VM

#This python script is used to clone one new node (the type CloneNode) #belonging to Vsys instance Clonevsys. #No new node would be CRE ated if Max is Reached.import osimport sysclonenode=sys.argv[1]clonevsys=sys.argv[2]max=sys.argv[3] #function to check If the maximum clone limit is Reacheddef Ismax (max, System, CloneNode): current=0 vms=system.virtualmachines to VM in VMS: Vmpartname= vm.patternpart.partCaption vmstatus = Vm.currentstatus if (vmpartname = cloneNode and Vmstatus = "RM01006"): Current+=1 if (current < max): Return "False" Else:return "True" #Get the input virtual system instance. Allsystems=deployer.virtualsystems.list ({' Name ': Clonevsys}) found= ' False ' for system in Allsystems:vsysname= System.Name vsysstatus = system.currentstatus print "SysName:" + vsysname + "Sysstatus:" + vsysstatus if (vsysstatus = = " RM01006 "or Vsysstatus = =" RM01070 "): #Get all the running virtual rogue to VM in VMS: Vmpartname= vm.patternpart.partCaption vmstatus = VM. Currentstatus print "Vmname:" + vmpartname + "Vmstatus:" + vmstatus if (Vmpartname = cloneNode and Vmstatus = "RM01006"): Found= ' True ' #If max limit not reached then clone. Ismaximum = Ismax (int (max), System, CloneNode) if (ismaximum = = ' False '): print "Clone started" vm.clone () Break if (found== ' True '): Break

Listing 8. Delete the VSP part VM script

#This python script is used to release the nodes (of type CloneNode) #belonging to Vsys instance Clonevsys. #No nodes are Released if min specified is Reached.import osimport sysclonenode=sys.argv[1]clonevsys=sys.argv[2]min=int (sys.argv[3) #Check if minimum number of nodes Reached.def ismin (min, System, CloneNode): current=0 vms=system.virtualmachines for VMs in Vms:vmpartname= vm.patternpart.partCaption vmstatus = Vm.currentstatus if (vmpartname = cloneNode and Vmstatus = = " RM01006 "): Current+=1 if (> Min): Return" False "Else:return" True "#Get the input virtual system Instance.allsystems=deployer.virtualsystems.list ({' Name ': Clonevsys}) found= ' False ' for system in Allsystems: Vsysname=system.name vsysstatus = system.currentstatus print "SysName:" + vsysname + "Sysstatus:" + vsysstatus if ( Vsysstatus = = "RM01006" or vsysstatus = "RM01070"): #Get all running virtual rogue to VM In vms:vmpartname= vm.patternpart.partCaption vmstatus = vm.cuRrentstatus print "Vmname:" + vmpartname + "Vmstatus:" + vmstatus if (Vmpartname = cloneNode and Vmstatus = "RM01006"): Found = ' True ' #Delete till minimum specified is reached. Isminimum = ismin (int (min), System, CloneNode) if (isminimum = = ' True '): Break Else:print "Delete started" Vm.delete () if ( found== ' True ': Break

In these five steps, you have actually completed the following tasks:

defines a user-defined extension policy using the VAP policy object. The VAP monitoring framework is used to trigger the VSP instance VM monitoring and to trigger the dynamic automatic expansion of the VSP instance VM according to the monitored metrics. Creates a new VSP instance VM node using the cloning and deletion method provided by the VSP command API, or deletes an existing VSP instance VM node.

Test Cases

In this section, you will learn how to test the WebSphere Cluster custom node extension use case. To test the use case, you first need to create a WebSphere Cluster VSP instance. Figure 4 shows a WebSphere Cluster VSP instance. You must also create a VAP pattern type to drive the VSP extension. The sample code provided in this article has a VAP pattern type (vsysscalingmgr) that you can import into your pureapplication system environment to drive the VSP extension. Once you have imported the model type, you can use the virtual application Builder to create a new VAP and deploy the newly created VAP.

Figure 4. WebSphere Cluster VSP Instance

Figure 5 shows the WebSphere Cluster scaling Manager VAP in the virtual application Builder.

Figure 5. WebSphere Cluster Scaling Manager mode

After you complete the schema deployment, you can use the following steps to simulate an extension:

Log on to the deployment Manager console. Create a new server on an existing node, perform a full resynchronization, or perform other operations on this node to increase CPU usage on the custom node. In the monitoring script cpuutil.sh, you can unit test the custom node extensions for the VSP instance by canceling the comment on the line of code shown in Listing 9. This gives you a dummy value of 85 as the CPU usage for subsequent tasks in the script. If you want to reduce this usage, you can annotate the lines that you uncomment.

Listing 9. To test the VSP scaling Manager mode with a uncomment line

cpuval=$ (ssh-i $DIR _name/key-o stricthostkeychecking=no $ADMIN _name@ $i "Top-b-d1-n2| Grep-i \ Cpu (s) \ | Cut-d ', ' responsefilename | awk ' {print \$2} ' | cut-d '% ' responsefilename | Sed-n 2p ") #To Unit Test clone un-comment the following line. After cloning to Unit-test delete#comment the this line. #cpuval =85#end Unit Test un-comment echo "CPU value is" $cpuval >>/ Home/virtuser/collectors/scaling.log

Figure 6 shows the monitoring user interface in the VAP console. This interface shows the CPU usage of the VSP instance node custom node. Note that when you unit test a pattern type using the method described in Listing 9, the graph surges to 85% and then down to 2%.

Figure 6. CPU utilization of virtual system instance nodes

Figure 7 shows the addition of the custom node instance. If all custom node instances have more than 80% CPU usage, a new WebSphere VSP custom node will be created until the maximum value of 10 nodes is reached. When the CPU usage of all custom node instances falls below 10%, the other nodes are deleted except for the two custom node instances.

Figure 7. WebSphere VSP Custom Node extension

Concluding

In this article, you learned how to create a VAP pattern type to drive the user-defined automatic extension of the VAP instance VM node. With this technique, you can automatically extend a VSP instance VM node with user-defined extension policies, as well as minimum or VSP values. You can also use the VAP dashboard to further monitor the VSP instance metrics. The disadvantage of this technique is that users are required to enter the user credentials of the VSP instance VM, and only pureapplication System users who have access to the VSP instance can deploy the VAP scaling Manager instance. Otherwise, the Deployer CLI does not have permission to add or remove nodes.