Maintainance of WebSphere Extended deployment server

When applying maintenance to upgrade the level of WebSphere Application Server Extended Deployment and WebSphere Network Deployment it is important that the deployment manager remain inactive until both upgrades are complete because if the deployment manager is active before both upgrades are complete it may detect an incompatible version of WebSphere Application Server Extended Deployment and remove some required resources from the dynamic cluster. Keeping the deployment manager inactive until both Network Deployment and WebSphere Application Server Extended Deployment updates have been completed will insure that this potential problem does not occur.

How to set up dynamic cluster

Follow the Creating a new dynamic cluster on Windows using WebSphere Virtual Enterprise document to setup a dynamic cluster.


The basic steps for creating dynamic cluster can be divided into three basic parts

Preparing DM and portal nodes

• Install and configure Deployment Manager


• Install WAS XD and augment the deployment manager profile


• On all the WebSphere portal servers install WAS XD and augment wp_profile

Adding Primary Node to dynamic cluster

• Prepare the node for dynamic cluster
  
  
  
  • cluster-node-config-pre-federation
  
  
  • Optional tasks if your using look aside repository or database backed user registry
  
  
  • cluster-node-config-post-federation
  
  
  • wp-change-portal-admin-user
  
  
  
  


• Login into WAS Admin consol and Create a node group


• Add primary portal server as node to the node group


• Create Dynamic cluster, in the WAS Admin Console


• Create the primary portal node as cluster member using the existing server as a template


• Create dynamic cluster by executing cluster-node-config-dynamic-cluster-setup config task


• Access the web content management content:Set the WCM_HOST and WCM_POST websphere variables at the primary portal server level to point to the web server host name and port name through which the WCM content would be accessed.


• Propogate the changes
  
  
  
  • Stop DM
  
  
  • Stop Node Agent
  
  
  • Stop Server 1
  
  
  • Stop portal server
  
  
  • start DM
  
  
  • Start Node
  
  
  • Start Server1
  
  
  • Start WebSPhere POrtal
  
  
  • 
    
  
  

Adding additional nodes to the cluster

• Setup the wkplc_dbtype.properties and wkplc_comp.properties files to point to correct database


• Validate database settings by executing
  
  
  
  • validate-database-driver
  
  
  • validate-database-connections
  
  
  
  


• Prepare the node for dynamic cluster
  
  
  
  • cluster-node-config-pre-federation
  
  
  • Optional tasks if your using look aside repository or database backed user registry
  
  
  • cluster-node-config-post-federation
  
  
  • wp-change-portal-admin-user
  
  
  
  


• Login into the WAS Admin Console and add the new node as new member to the node group


• Run the ConfigEngine.bat/sh cluster-node-config-dynamic-cluster-setup task to add the new member to the existing dynamic cluster


• Apply changes by restarting the server


• Access the Web Content Management Content by changing value of WCM_HOST and WCM_PORT websphere variables at the nodename scope to indicate the name of the fully qualified host and port

What is a dynamic Cluster

You can create IBM WebSphere Application Server Extended Deployment dynamic cluster to run IBM WebSphere Portal server. The Dynamic cluster is one of the features provided by WAS - Extended Deployment, to support dynamic operations.

The WebSphere XD has a concept of service policy that lets you define performance goals for application or actually application URL and decide the priority of application compaired to other applications.

Once an administrator has classified an application's URLs and connected them to service policies, then the ODR will begin examining incoming URLs and compare their performance characteristics to the goals defined in the corresponding service policies. The ODR can accomplish this through several mechanisms:

• The ODR can use its knowledge of the relative priorities of different service policies to determine how long requests will wait in its own internal queues; higher-priority requests will receive service before lower-priority requests when resources are constrained.


• The ODR can use its knowledge of response time goals and the relative availability of resources (CPU and memory) in different cluster members to perform dynamic workload management.


• The ODR can work with other parts of the system to achieve dynamic placement within a dynamic cluster. Dynamic placement is a facility in which the XD autonomic managers determine how many copies of an application server are appropriate within a cluster. For example, if one application is performing well above its performance goals, while another higher- or equal-priority application is underperforming because the machines running clustered copies of that application are overtaxed, then the autonomic manager can decide to adjust the number of application servers running each application, decreasing the former and increasing the latter to improve the performance of the overwhelmed application.

Some of these facilities (such as the classification and queuing of work) are entirely the function of the ODR, and will work well with many different types of workloads. Others (such as dynamic placement) are more specialized and work in concert with other parts of the XD system. All require require the use of the ODR, which is the fundamental architectural linchpin of XD, and possesses still more features.