Differences

This shows you the differences between two versions of the page.

--- wiki:customization_tips [2020/03/25 15:12] – neyron
+++ wiki:customization_tips [2020/03/25 15:19] – neyron
@@ Line 337: / Line 337: @@
  */10 * * * *       root /usr/sbin/oar_phoenix
 </code>
-====== Useful commands and administration tasks ======
-//Here, you'll find useful commands, sometimes a bit tricky, to put into your scripts or administration tasks//
-===== List suspected nodes without running jobs =====
-You may need this list of nodes if you want to automatically reboot them because you don't know why they have been suspected and you think that it is a simple way to clean things:
-<code>
- oarnodes  --sql "state = 'Suspected' and network_address NOT IN (SELECT distinct(network_address) FROM resources where resource_id IN \\
- (SELECT resource_id  FROM assigned_resources WHERE assigned_resource_index = 'CURRENT'))" | grep '^network_address' | sort -u
-</code>
-===== List alive nodes without running jobs =====
-<code>
- oarnodes  --sql "state = 'Alive' and network_address NOT IN (SELECT distinct(network_address) FROM resources where resource_id IN \\
- (SELECT resource_id  FROM assigned_resources WHERE assigned_resource_index = 'CURRENT'))" | grep '^network_address' | sort -u
-</code>
-===== Oarstat display without best-effort jobs =====
-<code>
- oarstat --sql "job_id NOT IN  (SELECT job_id FROM job_types where types_index = 'CURRENT' AND type = 'besteffort') AND state != 'Error' AND state != 'Terminated'"
-</code>
-===== Setting some nodes in maintenance mode only when they are free =====
-You may need to plan some maintenance operations on some particular nodes (for example add somme memory, upgrade bios,...) but you don't want to interrupt currently running or planned users jobs. To do so, you can simply run a "sleep" job into the admin queue and wait for it to become running, and then set the node into maintenance mode. But you also can use this trick to set automatically the node into maintenance mode when the admin job starts:
-<code bash>
- oarsub -q admin -t cosystem -l /nodes=2 'uniq $OAR_NODE_FILE|awk "{print \\"sudo oarnodesetting -m on -h \\" \\$1}"|bash'
-</code>
-This uses the "cosystem" job type that does nothing but start your command on a given host. This host has to be configured into the //COSYSTEM_HOSTNAME// variable of the //oar.conf// file, and for the current purpose, you can simply put //127.0.0.1//. You also need to install the oar-node package on this host.
-The example above will disable 2 free nodes, but you may want to add a //-p// option to specify the nodes you want to disable, for example: ''-p "network_address in ('node-1','node-2')"''
-**Note:** you can't simply do that within a "normal" job as oar will kill your job before all the resources of the node are set into the maintenance mode
-===== Optimizing and re-initializing the database with Postgres =====
-Sometimes, the database contains so much jobs that you need to optimize it. Normally, you should have a **vacuumdb** running daily fron cron. You can do manually a **vacuumdb -a -f -z ; reindexdb oar** but don't forget to stop OAR before, and be aware that it may take some time. But the DB still may be very big and it may be a problem for backups or the nightly vaccum takes too much time. A more radical solution is to start again with a new database, but keep the old one so that you can still connect to it for jobs history. You can do this once a year for example, and you only have to backup the current database. Here is a way to do this:
-  *  First of all, make a backup of your database! With postgres, it is as easy as:
-<code>
- create database oar_backup_2012 with template oar
-</code>
-It will create an exact copy of the "oar" database named "oar_backup_2012". Be sure that you have enough space left on the device hosting your postgres data directory. Doing so will allow you to make queries on the backup database if you need to find the history of old jobs.
-  *  You should plan a maintenance and be sure there's no more jobs into the system.
-  *  Make a dump of your "queues", "resources" and "admission_rules" tables.
-  *  Stop the oar server, drop the oar database and re-create it.
-  *  Finally, restore the "queues", "resources" and "admission_rules" tables into the new database.
-  *  And restart the server.
-====== Green computing ======
-//In this section, you'll find tips for optimizing the fluids consumptions of your clusters//
-===== Activating the dynamic on/off of nodes but keeping a few nodes always ready =====
-**Warning:** this tip is now partly obsoleted by the new **hulot** module that comes with the latest oar release. this energy saving module has got a keepalive feature. take a look at the comments above all the energy* variables into the oar.conf file.
-First of all, you have to set up the ecological feature as told into the FAQ: [[http://oar.imag.fr/admins/faq_admin.html#how-to-configure-a-more-ecological-cluster-or-how-to-make-some-power-consumption-economies|How to configure a more ecological cluster]].
-**Note:** if you have an ordinary cluster with nodes that are always available, you may set the cm_availability property to 2147483646 (infinite minus 1)
-**Note: ** once this feature has been activated, the **absent** status may not always really mean absent, but **standby** as oar may want to automatically power on the node. to put a node into a real absent status, you have to set the cm_availability property to **0**
-This tip supposes that you have set up your nodes to automatically set them to the Alive state when they boot and to the Absent state when they shutdown. You may refer to the FAQ for this: [[http://oar.imag.fr/admins/faq_admin.html#how-to-manage-start-stop-of-the-nodes|How to manage start/stop of the nodes?]] or to this section of the [[#Start.2Fstop_of_nodes_using_ssh_keys|Customization tips]].
-Here, we provide 3 scripts that you may customize and that make your ecological configuration a bit smarter than the default as it will be aware of keeping powered on a few nodes (4 in this example) that will be ready for incoming jobs:
-==wake_up_nodes.sh==
-<code bash>
-#!/bin/bash
-IPMI_HOST="admin"
-POWER_ON_CMD="cpower --up --quiet"
-NODES=`cat`
-for NODE in $NODES
-do
-  ssh $IPMI_HOST $POWER_ON_CMD $NODE
-done
-</code>
-Very simple script containing the command that powers on your nodes. In this example, suitable for an SGI Altix Ice, we do a **cpower** from an **admin** host. You'll probably have to customize this. This script is to be put in front of the SCHEDULER_NODE_MANAGER_WAKE_UP_CMD option of the oar.conf file, like this:
-<code>
- SCHEDULER_NODE_MANAGER_WAKE_UP_CMD="/usr/lib/oar/oardodo/oardodo /usr/local/sbin/wake_up_nodes.sh"
-</code>
-== set_standby_nodes.sh ==
-<code bash>
-#!/bin/bash
-set -e
-# This script is intended to be used from the SCHEDULER_NODE_MANAGER_SLEEP_CMD
-# variable of the oar.conf file.
-# It halts the nodes given in the stdin, but refuses to stop nodes if this
-# results in less than #NODES_KEEP_ALIVE alive nodes, because we generally
-# want to have some nodes ready for treating immediately some jobs.
-NODES_KEEP_ALIVE=4
-NODES=`cat`
-ALIVE_NODES=`oarnodes  --sql "state = 'Alive' and network_address NOT IN (SELECT distinct(network_address) FROM resources where resource_id IN (SELECT resource_id  FROM assigned_resources WHERE assigned_resource_index = 'CURRENT'))" | grep '^network_address' | sort -u`
-NODES_TO_SHUTDOWN=""
-for NODE in $NODES
-do
-  if [ $ALIVE_NODES -gt $NODES_KEEP_ALIVE ]
-  then
-    NODES_TO_SHUTDOWN="$NODE\n$NODES_TO_SHUTDOWN"
-    let ALIVE_NODES=ALIVE_NODES-1
-  else
-    echo "Not halting $NODE because I need to keep $NODES_KEEP_ALIVE alive nodes"
-  fi
-done
-if [ "$NODES_TO_SHUTDOWN" != "" ]
-then
-  echo -e "$NODES_TO_SHUTDOWN" |/usr/lib/oar/sentinelle.pl -f - -t 3 -p '/sbin/halt -p'
-fi
-</code>
-This is the script for shutting down nodes. It uses **sentinelle** to send the **halt** command to the nodes, as suggested by the default configuration, but it refuses to shutdown some nodes if this results in less than 4 ready nodes. This script is to be put into the SCHEDULER_NODE_MANAGER_SLEEP_CMD by this way:
-<code>
- SCHEDULER_NODE_MANAGER_SLEEP_CMD="/usr/lib/oar/oardodo/oardodo /usr/local/sbin/set_standby_nodes.sh"
-</code>
-==nodes_keepalive.sh==
-<code bash>
-#!/bin/bash
-set -e
-# This script is intended to be ran every 5 minutes from the crontab
-# It ensures that #NODES_KEEP_ALIVE nodes with at least 1 free resource
-# are always alive and not shut down. It wakes up the nodes by submiting
-# a dummy job. It does not submit jobs if all the resources are used or
-# not available (cm_availability set to a low value)
-NODES_KEEP_ALIVE=4
-ADMIN_USER=bzeznik
-# Locking
-LOCK=/var/lock/`basename $0`
-### Locking for Debian (using lockfile-progs):
-#lockfile-create $LOCK || exit 1
-#lockfile-touch $LOCK &
-#BADGER="$!"
-### Locking for others (using sendmail lockfile)
-lockfile -r3 -l 43200 $LOCK
-if [ "`oarstat |grep \"wake_up_.*node\"`" = "" ]
-then
- # Get the number of Alive nodes with at least 1 free resource
- ALIVE_NODES=`oarnodes  --sql "state = 'Alive' and network_address NOT IN (SELECT distinct(network_address) FROM resources where resource_id IN (SELECT resource_id  FROM assigned_resources WHERE assigned_resource_index = 'CURRENT'))" | grep '^network_address' | sort -u`
- # Get the number of nodes in standby
- let AVAIL_DATE=`date +%s`+3600
- WAKEABLE_NODES=`oarnodes  --sql "state = 'Absent' and cm_availability > $AVAIL_DATE" |grep "^network_address" |sort -u|wc -l`
- if [ $ALIVE_NODES -lt $NODES_KEEP_ALIVE ]
- then
-   if [ $WAKEABLE_NODES -gt 0 ]
-   then
-     if [ $NODES_KEEP_ALIVE -gt $WAKEABLE_NODES ]
-     then
-       NODES_KEEP_ALIVE=$WAKEABLE_NODES
-     fi
-     su - $ADMIN_USER -c "oarsub -n wake_up_${NODES_KEEP_ALIVE}nodes -l /nodes=${NODES_KEEP_ALIVE}/core=1,walltime=00:00:10 'sleep 1'"
-   fi
- fi
-fi
-### Unlocking for Debian:
-#kill "${BADGER}"
-#lockfile-remove $LOCK
-### Unlocking for others:
-rm -f $LOCK
-</code>
-This script is responsible of waking up (power on) some nodes if there's not enough free alive nodes. The trick used by this script is to submit a dummy job to force OAR to wake up some nodes. It's intended to be ran periodically from the crontab, for example with such a /etc/cron.d/nodes_keepalive file:
-<code>
- */5 * * * *     root    /usr/local/sbin/nodes_keepalive.sh
-</code>
 ====== Use cases ======