Difference: SystemAdministratorGuideForEMI1 (41 vs. 42)

Revision 422011-10-31 - EricFrizziero

Line: 1 to 1
 
META TOPICPARENT name="SystemAdministratorDocumentation"

System Administrator Guide for CREAM for EMI-1 release

Line: 32 to 32
  glite-CLUSTER is a node type that can publish information about clusters and subclusters in a site, referenced by any number of compute elements. In particular it allows to deal with sites having multiple CREAM CE nodes and/or multiple subclusters (i.e. disjoint sets of worker nodes, each set having sufficiently homogeneous properties).
Changed:
<
<
In Glue1, batch system queues are represented through GlueCE objectclasses. Each GlueCE refers to a Cluster, which can be composed by one or more SubClusters. However the gLite WMS requires the publication of exactly one SubCluster per Cluster (and hence per batch queue).
>
>
In Glue1, batch system queues are represented through GlueCE objectclasses. Each GlueCE refers to a Cluster, which can be composed by one or more SubClusters. However the gLite WMS requires the publication of exactly one SubCluster per Cluster (and hence per batch queue).
  Thus sites with heterogeneous hardware have two possible choices:
  • publish a SubCluster with a representative/minimum hardware description (e.g. the minimum memory on any node)
Line: 38 to 37
 Thus sites with heterogeneous hardware have two possible choices:
  • publish a SubCluster with a representative/minimum hardware description (e.g. the minimum memory on any node)
  • define separate batch queues for each hardware configuration, e.g. low/high memory queues, and attach the corresponding GlueCE objects to separate Cluster/SubCluster pairs. For attributes with discrete values, e.g. SL4 vs SL5, this second option is the only one which makes sense.
Deleted:
<
<
 However, without the use of the gLite-cluster, YAIM allows configuring a single Cluster per CREAM head node.
Changed:
<
<
A second problem, addressed by gLite-cluster arises for larger sites which install multiple CE headnodes submitting to the same batch queues for redundancy or load-balancing. Without the use of gLite-cluster, YAIM generates a separate Cluster/SubCluster pair for each head node even though they all describe the same hardware. This causes no problems for job submission, but by default would overcount the installed capacity at the site by a multiple of the number of SubClusters. The workaround, before introducing the gLite-cluster, was to publish zero values for the installed capacity from all but one of the nodes (but this is clearly far from being an ideal solution).
>
>
A second problem, addressed by gLite-cluster arises for larger sites which install multiple CE headnodes submitting to the same batch queues for redundancy or load-balancing. Without the use of gLite-cluster, YAIM generates a separate Cluster/SubCluster pair for each head node even though they all describe the same hardware. This causes no problems for job submission, but by default would overcount the installed capacity at the site by a multiple of the number of SubClusters. The workaround, before introducing the gLite-cluster, was to publish zero values for the installed capacity from all but one of the nodes (but this is clearly far from being an ideal solution).
  The glite-CLUSTER node addresses this issue. It contains a subset of the functionality incorporated in the CREAM node types: the publication of the Glue1 GlueCluster and its dependent objects, the publication of the Glue1 GlueService object for the GridFTP endpoint, and the directories which store the RunTimeEnvironment tags, together with the YAIM functions which configure them.
Line: 80 to 68
  http://savannah.cern.ch/bugs/?87691
Changed:
<
<
in the current implementation when configuring via yaim, all queues of a given CE head node gets mapped to a single cluster (i.e. it not possible to map different queues to different clusters). Waiting for the fixes for these bugs, the ldif files produced by yaim must be then manually edited.
>
>
in the current implementation when configuring via yaim, all queues of a given CE head node gets mapped to a single cluster (i.e. it not possible to map different queues to different clusters). Waiting for the fixes for these bugs, the ldif files produced by yaim must be then manually edited.
 

0.0.1 Choose the authorization model

Line: 241 to 227
 

0.0.0.1 Installation of the CREAM CE software

Changed:
<
<
The CREAM software itself can work with both Sun jdk and openjdk. However, the apel-core package, deployed in the CREAM CE node, requires mm-mysql, which explicitly requires Sun jdk. So to install the middleware software needed for the CREAM CE, install first of all Sun JDK ( jdk). This is actually not needed in a standard SL5 box, since in this case the Sun JDK rpm is available in the OS repo. Please note that this dependency on mm-mysql is being fixed by APEL developers.
>
>
The CREAM software itself can work with both Sun jdk and openjdk. However, the apel-core package, deployed in the CREAM CE node, requires mm-mysql, which explicitly requires Sun jdk. So to install the middleware software needed for the CREAM CE, install first of all Sun JDK ( jdk). This is actually not needed in a standard SL5 box, since in this case the Sun JDK rpm is available in the OS repo. Please note that this dependency on mm-mysql is being fixed by APEL developers.
  Then install xml-commons-apis:
Line: 301 to 286
 

0.0.0.1 Installation of the CREAM CE software

Changed:
<
<
The CREAM software itself can work with both Sun jdk and openjdk. However, the apel-core package, deployed in the CREAM CE node, requires mm-mysql, which explicitly requires Sun jdk. So to install the middleware software needed for the CREAM CE, install first of all Sun JDK ( jdk). This is actually not needed in a standard SL5 box, since in this case the Sun JDK rpm is available in the OS repo. Please note that this dependency on mm-mysql is being fixed by APEL developers.
>
>
The CREAM software itself can work with both Sun jdk and openjdk. However, the apel-core package, deployed in the CREAM CE node, requires mm-mysql, which explicitly requires Sun jdk. So to install the middleware software needed for the CREAM CE, install first of all Sun JDK ( jdk). This is actually not needed in a standard SL5 box, since in this case the Sun JDK rpm is available in the OS repo. Please note that this dependency on mm-mysql is being fixed by APEL developers.
  Then install xml-commons-apis:
Line: 669 to 651
  If the new BLAH Blparser is used (click here for instructions to check if you are using the old or the new blparser) the parameter bupdater_loop_interval attribute in /etc/blah.config defines how often the batch system is queried to check the status of the jobs. If a low value is used, job status changes are detected promptly, but this also means that several batch system queries are done, and this can cause a high load.
Changed:
<
<
With yaim-cream-ce v >= 4.2.2-1, this parameter is configurable via yaim: the relevant yaim variable is BUPDATER_LOOP_INTERVAL which has 30 (secs) as default value.
>
>
With yaim-cream-ce v >= 4.2.2-1, this parameter is configurable via yaim: the relevant yaim variable is BUPDATER_LOOP_INTERVAL which has 30 (secs) as default value.
 
Changed:
<
<
With yaim-cream-ce v. < 4.2.2-1, this parameter is not configurable via yaim, and therefore it is needed to manually edit the blah configuration file, otherwise the default value (5 s.) is used. After having set this value in the blah configuration file it is necessary:
>
>
With yaim-cream-ce v. < 4.2.2-1, this parameter is not configurable via yaim, and therefore it is needed to manually edit the blah configuration file, otherwise the default value (5 s.) is used. After having set this value in the blah configuration file it is necessary:
 
  • to stop tomcat: service tomcat5 stop
  • to restart the blparser: /etc/init.d/glite-ce-blahparser restart
Line: 732 to 709
 SHOW VARIABLES like 'innodb_buffer_pool_size';
Added:
>
>

0.1 MySQL database: How to resize Innodb log files?

If the following error occurs


InnoDB: ERROR: the age of the last checkpoint is ,

InnoDB: which exceeds the log group capacity .

InnoDB: If you are using big BLOB or TEXT rows,you must set the

InnoDB: combined size of log files at least 10 times bigger than the

InnoDB: largest such row.


then you must resize innodb log files.

Follow these steps:

  • check for the value of the innodb_log_file_size.
SHOW VARIABLES  like "innodb_log_file_size"; 

  • Stop the MySQL server and make sure it shuts down without any errors. You can have a look at the error log to see if there are no errors.
service mysqld stop

  • Once the server has stopped, edit the configuration file ( /etc/my.cnf) and insert or change the value of innodb_log_file_size to your desired value. Example:
[mysqld]
innodb_log_file_size=64M

  • Move the log file sizes ib_log* to some place out of the the directory where the log files reside. Example:
mv /var/lib/mysql/ib_logfile* /tmp

  • Now restart the server.
service mysqld start

  • Check for errors in /var/log/mysqld.log file

  • Verify the correct size of the log files
ls -lrth /var/lib/mysql/ib_logfile*
 

0.1 How to start the CREAM service

A site admin can start the CREAM service just starting the CREAM container:

 
This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback