File:  [LON-CAPA] / loncom / html / adm / help / tex / Domain_Configuration_User_Sessions.tex
Revision 1.3: download - view: text, annotated - select for diffs
Tue Apr 7 21:16:20 2015 UTC (9 years, 7 months ago) by raeburn
Branches: MAIN
CVS tags: version_2_12_X, version_2_11_X, version_2_11_5_msu, version_2_11_5, version_2_11_4_uiuc, version_2_11_4_msu, version_2_11_4, version_2_11_3_uiuc, version_2_11_3_msu, version_2_11_3, version_2_11_2_uiuc, version_2_11_2_msu, version_2_11_2_educog, version_2_11_2, version_2_11_1, HEAD
- Update Domain Coordinator documentation for session hosting/offloading.

\label{Domain_Configuration_User_Sessions}
Default domain configurations can be assigned for:

\begin{itemize}

\item Offloading sessions when busy, or prior to maintenance

Starting with LON-CAPA 2.11, as Domain Coordinator you can use the web GUI to
configure where your servers will offload user sessions (for new log-ins)
when they are busy, if your server is a member of a cluster of servers. 

If you have not yet configured offloading then the least busy of the servers
listed in /home/httpd/lonTabs/spare.tab on each server will be used, if your server
is found to be at over 100\% user load or 100\% server load.

The default spare.tab file included with a LON-CAPA release includes four access  
servers in the msu domain, and one access server in the csm domain.
If your LON-CAPA domain is part of the LON-CAPA network then one of the five servers
will host offloaded sessions from busy servers in your domain. 
Once offloading has been configured using the GUI, the spare.tab files on your servers 
will no longer be consulted, since offload settings for your domain will now be 
stored centrally in the configuration.db file for your domain.  Changes
made via the web GUI are propagated immediately to all servers in your domain. 

The load limits which are used to compute percentage load are currently set on each 
server when you run UPDATE to install LON-CAPA (or update to a new release).
The defaults are: Server Load: 2.00; User Load: 0.

These values can also be set by editing the /etc/httpd/conf/loncapa.conf file 
(CentOS, Scientific Linux, RHEL, Fedora) or the /etc/apache2/loncapa.conf file
(SuSE, SLES, Ubuntu), and setting values for lonLoadLim and/or lonUserLoadLim.
(Web server reload required after making changes to loncapa.conf).

The percent server load is computed from: 100 * loadavg/lonLoadLim, and 
percent user load is computed from 100 * activeusers/lonUserLoadLim.

If you do not wish to restrict the number of active user sessions on your server
set the User Load (i.e., lonUserLoadLim) to 0.

The loadavg comes from the one minute average for CPU utiization, i.e., the 
first number in the output from cat /proc/loadavg.

The activeusers total is the number of user session files in
/home/httpd/lonIDs which have modification times within the last 30 minutes.

The ``User session hosting/offloading'' option in the domain configuration GUI
allows you to set where user sessions will be offloaded, separately for each 
server in your domain.  You can designate offload servers as either primary or default.
Primary servers are considered first when seeking to offload a user session.

Ordinarily, session offloading only occurs when a user first logs in.  However,
you can also choose to offload all active users from a particular server by
checking the ``Switch active users on next access'' checkbox for that server.
You might use this feature if you wanted to take an access server out of the 
pool of servers in your domain for maintenance (all sessions are switched
regardless of current load values, with the exception of Domain Coordinators).

Notes: 
\begin{enumerate}

\item
As this type of offload happens on page load, it requires the user to be 
actively interacting with the system (i.e., the web browser needs to request 
a page). 

\item
Any transactions resulting from the original page request (e.g.,  
grading of a homework submission) will be completed on the server  
before the output containing the server switch function is returned to  
the client. 

\end{enumerate}
 
\item Session Hosting

Starting with LON-CAPA 2.10, as Domain Coordinator you can configure a domain 
to include constraints on where sessions for users from your domain may be 
hosted, and also which other domains may have their users hosted on your  
servers.

If a LON-CAPA server is part of a cluster in which there is a only a 
single domain, or multiple domains but only a single library server,
then options to control user session hosting are unavailable, as they
do not make sense in this context.

\begin{itemize}
\item Hosting of users from other domains. 

There are two types of setting: ``Allow all, but exclude specific domains'' or ``Deny all, but include specific domains''.  In both cases the options are (a) for the setting to be in use, or (b) not be in use (the default).  If in use, then checkboxes can be checked for any ``internet domains'' for which the constraint is to apply. Internet domains encompass all servers at a particular institution, and also any aliases used on a multiple domain server.  For example, there is a single internet domain for educog.com.  Constraints for that internet domain will apply to all *.educog.com servers, as well as all domains on the multi-domain educog server.  On a multiple domain server, session hosting constraints are defined in a single domain - the default domain included in the loncapa.conf file (e.g., the ``author'' domain for ``educog.com'').
\item Hosting domain's own users elsewhere. 

Again the same two types of setting are available: (a) ``Allow all, but exclude specific domains'' or (b) ``Deny all, but include specific domains''.  There is a third type of setting: ``LON-CAPA version requirement'', which, in common with the other two can be set to be:  ``in use'', or ``not in use'' (the default).  This setting can be used to require that sessions for users in your domain are not hosted on LON-CAPA versions which predate a particular selected version.  
\end{itemize}

\end{itemize}

FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>