\section{Installation and Configuration}
\subsection{Complete list of packages}
-%\subsection{Daemons description}
-%\subsection{CLI tools description: purge/dump/load}
\LB is currently distributed mainly in RPMs packages. It is available also in
binary form packed as .tar.gz. Recent attempts to multiplatform porting and
For temporary files, approximately 10\,GB is sufficient for LB server setups
working normally, more can be needed when backlog forms in data export
to any external service. For example, typical setup processing 40\,000 jobs per
-day where all jobs are purged after 10 days needs about 58
-($10 \cdot 40000 \cdot 0.000000120 + 10$) gigabytes (not accounting for operating
-system and system logs).
-
-\TODO{salvet: vylepsit citelnost formulky}
+day where all jobs are purged after 10 days needs about 58 gigabytes
+($10 \cdot 40000 \cdot 120 \mbox{KB (per job)} + 10$) not accounting for operating
+system and system logs.
For smooth handling of 40\,000 jobs/day, this or better machine configuration
is necessary:
\subsubsection{Migration from previous versions}
-\TODO{salvet}
+Although new LB server versions are backwards compatible with already
+stored data (without need for conversion) usually, it is necessary to recreate
+LB database from scratch or to change its database schema at some points.
+Database schema changes are not (currently) performed automatically
+during YAIM configuration since they take a lot time and temporary disk
+space.
-updaty databaze, kdy jak, migrace na 3.1 i na HEAD
+There were two such notable upgrades:
+\begin{itemize}
+\item Version 1.4.3 of \textt{glite-lb-server} package. This \LB server version introduced optional use of database transactions for \LB database updates in order to improve their performace. This feature is switched on by default when underlaying MySQL database uses transactional InnoDB tables. For new installations, YAIM configuration process will create transactional database automatically. Existing databases can be converted using provided SQL command script:
+\begin{quote}
+\verb'mysql -u lbserver lbserver20 </opt/glite/etc/glite-lb-dbsetup-migrate2transactions.sql'
+\end{quote}
-transakce
+\item \LB version 2.0. This version features merged \LB server and proxy services using single database, pointers to purged jobs (``zombies'') and other improvements requiring database schema changes. Existing databases must be converted using provided shell script \verb'/opt/glite/etc/glite-lb-migrate_db2version20'. Use \verb'-s' parameter to convert database used by \LB server previously and \verb'-p' to convert database used by \LB proxy before. Optionally, unnecesary index can be dropped (this operation is likely to take a lot of time when applied to large database):
+\begin{quote}
+\verb'mysql -u lbserver lbserver20 -e "alter table events drop index host"
+\end{quote}
+\end{itemize}
+%\TODO{automated conversion through YAIM ?}
\subsubsection{Index configuration}
-\TODO{Initial YAIM way only, rest in Sect.~\ref{maintain:index}}
+Initial YAIM configuration does not create any \LB indexes, see Section~\ref{maintain:index}} for instructions
+on changing \LB server index configuration.
+
\subsubsection{Server superusers}
\label{inst:superusers}
\TODO{policy format}
-\subsubsection{Notification delivery}
+% \subsubsection{Notification delivery}\TODO{co tu ma byt?}
\subsubsection{Export to R-GMA}
+\LB server can export information on job state changes to R-GMA infrastructure through \verb'lcgmon'
+in real time. This export is enabled by YAIM by default and uses \verb'GLITE_WMS_LCGMON_FILE'
+environmental variable to retrieve name of log file which is to be consumed by \verb'lcgmon' (usually
+\verb'/var/glite/logging/status.log'). The log file has to be rotated regularly.
+
\subsubsection{Data backup}
\label{inst:backup}
+Data stored \LB server can be backed up using backups of underlaying database or using \verb'glite-lb-dump' utility.
+The latter has some advantages, see Section~\ref{run:dump} for details.
+
\subsubsection{Purging old data}
\label{inst:purge}
-\TODO{Setup cron job, refer to Sect.~\ref{maintain:purge}}
-
-\subsubsection{Export to Job Provenance}
+Initial YAIM configuration creates a cron job which runs once a day and purges old
+data (jobs in Cleared state after two days, Aborted and Cancelled after 15 days, and other jobs
+after 60 days of inactivity). It is recommended to run the cron jobs more often (in order to purge less jobs
+during single run) if event queue backlogs form in client WMS machines when the purging cron jobs is running.
+For details on setting job purge timeouts, see Sect.~\ref{run:purge}.
\subsubsection{Exploiting parallelism}
+\LB server uses 10 worker processes (threads) to handle active client accesses (inactive connections are killed
+when necessary). Each worker process uses separate connection to database server. Number of worker processes
+can be changed by adding \verb'--slaves' parameter with desired number to servers command line
+using \verb'GLITE_LB_SERVER_OTHER_OPTIONS' variable.
+
\subsubsection{Tuning database engine}
\label{inst:db_tuning}
\subsection{\LB proxy}
-Namergovat do serveru
+All necessary configuration of standalone \LB proxy is done by YAIM,
+previous \LB server section applies to merged server+proxy setups (\LBnew only).
\subsection{\LB logger}
+All necessary configuration of normal \LB logger is done by YAIM.
\subsection{Smoke tests}
git://scientific.zcu.cz / jra1mw.git / commitdiff