Difference between revisions of "Procedure Infrastructure upgrade"
Andrea.manzi (Talk | contribs) (→gCF based) |
Andrea.manzi (Talk | contribs) (→gCF based) |
||
Line 74: | Line 74: | ||
The different service packaging is required because it reflects the different nature of the gCube services and their deployment model: | The different service packaging is required because it reflects the different nature of the gCube services and their deployment model: | ||
− | * Core services ( also named Enabling layer services https://gcube.wiki.gcube-system.org/gcube/index.php/Core_Services_Installation) : The Core Services are the minimal set of gCube Services needed to setup and manage a gCube infrastructure. Due to their nature and deployment scenario they should be installed /upgraded manually. Given that a manual installation is requested the Full gar archive is preferable cause it install together with a service the needed dependencies. Please note that not all the Core Services have a Full Gar cause this has been introduced when moving to Maven, and not all of them have been ported yet. In case the where the Full Gar is not available the service dependencies are listed on the Admin guide. In the case of manual upgrade the following actions should be performed | + | * '''Core services''' ( also named Enabling layer services https://gcube.wiki.gcube-system.org/gcube/index.php/Core_Services_Installation) : The Core Services are the minimal set of gCube Services needed to setup and manage a gCube infrastructure. Due to their nature and deployment scenario they should be installed /upgraded manually. Given that a manual installation is requested the Full gar archive is preferable cause it install together with a service the needed dependencies. Please note that not all the Core Services have a Full Gar cause this has been introduced when moving to Maven, and not all of them have been ported yet. In case the where the Full Gar is not available the service dependencies are listed on the Admin guide. In the case of manual upgrade the following actions should be performed |
Container stop: | Container stop: | ||
$GLOBUS_LOCATION/bin/gcore-stop-container | $GLOBUS_LOCATION/bin/gcore-stop-container | ||
Line 82: | Line 82: | ||
$GLOBUS_LOCATION/bin/gcore-deploy-service ServiceName-full.gar | $GLOBUS_LOCATION/bin/gcore-deploy-service ServiceName-full.gar | ||
Please note that this operation removes together with the service implementation and dependencies also the configuration files ( among them the important jndi-config.xml). So in case of upgrades they should be recollected from the backup ( a GHN backup is always performed by the upgrade script) | Please note that this operation removes together with the service implementation and dependencies also the configuration files ( among them the important jndi-config.xml). So in case of upgrades they should be recollected from the backup ( a GHN backup is always performed by the upgrade script) | ||
− | * Application services : the services that implements the Application logic and they are not fundamental in a gCube infrastructure deployment. They are installed using the Dynamic Deployment facilities implement by gCube part of the Resoruce and VRE Management area https://gcube.wiki.gcube-system.org/gcube/index.php/VRE_Management. In details each gHN is equipped with a gCube service ( Deployer) which is responsible for the installation of packages on the node. The deployer is invoked by another gCube service | + | * '''Application services''' : the services that implements the Application logic and they are not fundamental in a gCube infrastructure deployment. They are installed using the Dynamic Deployment facilities implement by gCube part of the Resoruce and VRE Management area https://gcube.wiki.gcube-system.org/gcube/index.php/VRE_Management. In details each gHN is equipped with a gCube service ( Deployer) which is responsible for the installation of packages on the node. The deployer is invoked by another gCube service |
Revision as of 16:42, 8 April 2014
Preparation of the upgrade plan
This page http://wiki.i-marine.eu/index.php/Resources_Upgrade#gCube_Upgrade contains the list of gCube upgrades perfomed in iMarine so far.
When dealing with the preparation of a deployment plan we should deal with different categories of components:
- Containers
- gHN
- Smartgears
- gCube Services
- gCF based
- Smargears based
- Portal and Portlets
Containers upgrade
The infrastructure is equipped with 2 types of containers :
- gHN : customisation of a Globus WS core 4.0.4 container
- SmartGears : a set of extension to any Servlet based container to enable registration and activation on the infra of webapps ( at the moment only tomcat is installed)
The main documentation regarding the containers is the gCube Admin guide:
- gHN : https://gcore.wiki.gcube-system.org/gCube/index.php/Administrator_Guide
- Smartgears: https://gcube.wiki.gcube-system.org/gcube/index.php/SmartGears_gHN_Installation
gHN
The gHN unfortunately implements an old flat classloader schema, which means that common and application libs are all shared and stored in the same folder. When a new version of the gHN is available we should understand which changes have been applied. The typical changes are:
- a new version of the libraries part of the gHN
- a new version of the web services part of the gHN
- a change on the configuration of the GHNgCube Hosting Node.
At this level of maturity the gHN upgrades difficultly introduce not backward compatibilities, which should make life easier..
In order to upgrade an existing installation we have been always using 2 type of scripts:
- upgrade script: The script downloads the new version of the gHN from Maven, removes the old libraries and copies the new ones by keeping the existing gCube Services installed. He modifies also the existing configuration if needed. In case one of the existing base gCube services ( Deployer, GHNgCube Hosting Node. Manager, ResultSet) needs to be updated it takes care also of undeploy the old version and deploy the new one
- clean script: The script runs a reinstallation of the gHN by keeping only the gCube service state. it can be needed in case of changes of java version ( e.g. move from java 6 built artifacts to java 7) as well
The latest versions of the scripts are available on svn at:
https://svn.research-infrastructures.eu/d4science/gcube/trunk/ghn-distribution/upgrade-scripts/
The rules behind the execution of the upgrade or the clean script in a running installation are :
- if the gHN is empty ( the gHN is not running any other web service other than the basic gCube ones) it's always better to run a clean script
- if most of the libraries part of the gHN, the gCube services installed and their deps have changes better to run a clean script
- if only part of the the libraries or the conf of the gHN has changed, better to always run an upgrade script.
Of course the main difference between the 2 scripts is the result. The upgrade script does not require any other action from the site manager, while the clean script requires that the gCube services previously installed on the node have to be reinstalled. ( see section on service upgrade)
SmartGears
In the case of SmartGears containers we are in front of the latest generation servlet containers, which implement separate classloaders for common and each applications and in most of the cases the upgrade is a really simple procedure.
The upgrade is a combination of 2 scripts:
- Download scripts : https://gcube.wiki.gcube-system.org/gcube/index.php/SmartGears_gHN_Installation#Upgrade, which downloads the version to install from Nexus
- Install script : https://gcube.wiki.gcube-system.org/gcube/index.php/SmartGears_gHN_Installation#Installation, which first removes the previous installed components if present.
gCube service upgrade
The upgrade of gCube Services depends on the nature of the services and the technology used for their development
gCF based
gCube Services gCF based are the oldest categories of Web ServiceSelf-contained, self-describing, modular application that can be published, located, and invoked across the Web. Web services perform functions that can be anything from simple requests to complicated business processes. Once a Web service is deployed, other applications (and other Web services) can discover and invoke the deployed service. developed in gCube: they are developed using the gCF ( gCore Framework) , they run in a gHN and they are packaged in a bundle called gar archive (i.e. deployer-service.gar). Also in this case we have 2 possible gar archives:
- Normal gar archive : which contains the service implementation, the config and the wsdl
- Full gar archive: which in addition contains all the service runtime dependencies.
The different service packaging is required because it reflects the different nature of the gCube services and their deployment model:
- Core services ( also named Enabling layer services https://gcube.wiki.gcube-system.org/gcube/index.php/Core_Services_Installation) : The Core Services are the minimal set of gCube Services needed to setup and manage a gCube infrastructure. Due to their nature and deployment scenario they should be installed /upgraded manually. Given that a manual installation is requested the Full gar archive is preferable cause it install together with a service the needed dependencies. Please note that not all the Core Services have a Full Gar cause this has been introduced when moving to Maven, and not all of them have been ported yet. In case the where the Full Gar is not available the service dependencies are listed on the Admin guide. In the case of manual upgrade the following actions should be performed
Container stop: $GLOBUS_LOCATION/bin/gcore-stop-container Old service undeployment : $GLOBUS_LOCATION/bin/gcore-undeploy-service ServiceName New Service deployment $GLOBUS_LOCATION/bin/gcore-deploy-service ServiceName-full.gar
Please note that this operation removes together with the service implementation and dependencies also the configuration files ( among them the important jndi-config.xml). So in case of upgrades they should be recollected from the backup ( a GHNgCube Hosting Node. backup is always performed by the upgrade script)
- Application services : the services that implements the Application logic and they are not fundamental in a gCube infrastructure deployment. They are installed using the Dynamic Deployment facilities implement by gCube part of the Resoruce and VREVirtual Research Environment. Management area https://gcube.wiki.gcube-system.org/gcube/index.php/VRE_Management. In details each gHN is equipped with a gCube service ( Deployer) which is responsible for the installation of packages on the node. The deployer is invoked by another gCube service