Projets
Files
Documents


About
Fun


Login
  
Kanske lite gammal information, men om någon fortfarande använder SRM så finns denna kvar ett tag till.
.

        Lite oumbärlig samt lite ytterst umbärlig (eller självklar) 
             information om Solaris Resource Manager (SRM).
        ===========================================================

			Introduktion.
			-------------
* SRM används för att tilldela resurser på en server, i stället för att
  processerna konkurerrar om CPU och minnesresurser, vilket är det 
  traditionella i UNIX, så låter SRM användarna göra det. 
  Om man använder SRM kan man således se till att en användare som har 
  en process får lika mycket CPU som de med 10 processer.

* SRM kan användas för att styra resurser på användar-, eller gruppnivå.

* Exempel på användningsområde för SRM är serverkonsolideringar, eller om
  man vill hindra en applikation från att ta all CPU på ett system.

* Följande resurser kan kontrolleras av SRM; CPU, Virtuellt Minne, antal
  processer samt antalet inloggningar och deras längd.

Versioner.
----------
Solaris	 SRM	kräver kernel patch
2.6	 1.0	> 105181-11	
7	 1.1	> 106541-04
8	 1.2	-

			Hur SRM fungerar.
			-----------------
SRM byter ut TimeShare och InterActive klasserna i scheduleraren (även om
dessa fortfarande finns kvar i systemet), mot en klass som heter SHR, vilket
står för "SHaRe fair".

SRM aktiveras om man har applikationen installerad och "set initclass="SHR"" 
i /etc/system.

SRM använder sig sedan av PAM för att hålla reda på hur många användare som är 
inloggade och hur länge de har varit det. Detta ordnas med hjälp av några PAM 
moduler som läggs in /etc/pam.conf när man installerar SRM. SRM använder även 
PAM för att försäkra sig om att adekvata skript körs när en användare loggar 
in sig på systemet.

Det finns två demoner som SRM använder; srmgr som startas av kerneln, samt 
limdaemon, vilken startas från rc2.d/S10srm. Limdaemon notifierar användarna 
eller syslog när något händer, loggar ut användare som har varit inloggade 
längre än de får vara inloggade samt håller reda på hur många användare som 
finns inloggade på systemet.

lnoder.
-------
SRM använder sig av ett träd med "lnoder" för att hålla reda på de användare
och grupper som den kontrollerar, det finns fyra speciella lnoder som skapas 
vid installationen:

* srmidle:  All outnyttjad CPU tid hamnar i denna lnod.
* srmlost:  Processer och threads som inte har en lnod läggs in i denna grupp.
* srmother: Den grupp i vilken nya lnoder automatiskt läggs in.
* root:     Roten till alla övriga lnoder, roots processer hamnar här men dessa 
            har inga begränsningar.

Det är i lnod trädet som gränserna för olika användare/grupper finns, samt 
information om hur mycket av dessa som redan har använts.

Shared Values.
--------------
SRM använder något som kallas för "Shared Values" för att bestämma hur mycket
CPU kraft som en viss användare skall tilldelas, dessa värden är relativa.

Exempelvis; om man har ett system som har dessa två grupper:

Share Value:        1                                   1 
Gruppnamn:        Kalles                              Kajsas
                 /                                  /      
Användare:    Knatte  Fnatte                     Kicki    Titti
Share Value:    20      20                       10000    10000


I detta fall får alla användare (Knatte, Fnatte, Kicki och Titti), lika
mycket resurser, detta på grund av att samtliga användare får lika stora
delar av sin grupps resurser, och att båda grupperna får lika mycket av 
systemets.

En användare som i SRM har en låg tilldelning av resurser får CPU cykler så
länge som det inte finns en process med högre prioritet. 

Prioriteten räknas ut enligt följande:
SRM prio = SRM prio * decay_factor + usage_factor

decay_factor beror på processens "nice" värde
usage_factor beror på antal ticks som redan använts av processen och dess 
             threads, samt antal threads som tillhör lnoden och slutligen 
             även processens "share value".
		    
MyShare.
--------
"MyShare" reglerar hur mycket en "parent process" ger till sina "child 
processes", om till exempel en parent har en share på 3 och en myshare på 1 
så behåller den 33% av det den är tilldelad, förutsatt att den har behov 
av det.

			Begränsningtyper i SRM.
			-----------------------
SRM har två olika typer av begränsningar; statiska och förnyelsebara.

Statiska.
---------
Exempel på statiska begränsningar är antal processer man får ha igång 
samtidigt, hur många samtida inloggningar man får ha eller hur mycket minne 
man får allokera.

Statiska begränsningar kan frias och därefter återanvändas, till exempel
genom att man loggar ut eller att man avslutar några processer.	

Förnyelsebara.
--------------
Förnyelsebara begränsningar måste förnyas av administratören, till exempel 
kan man i SRM sätta en gräns för hur många gånger en viss användare/grupp 
får logga in på systemet, eller hur många CPU cykler denna användare får
utnyttja. När personen har nått upp till denna gräns måste man nollställa 
informationen eller utöka användarens kvot.

			SRM kommandon.
			--------------
Alla SRM kommandon installeras i /usr/srm/bin, med undantag för adminstratörs
kommandona vilka installeras under /usr/srm/sbin. Det finns två admin kommandon;
"srmadm" som har hand om själva SRM samt "limadm" vilken används för att
hantera lnoderna.

Alla kommandon i SRM vilka tar ett login som argument tar även UID som 
argument om man använder växeln "-u".

Några kommandon som kan vara bra att kunna:

* srmstat -Rac
Ger en tabell, liknande den man får från prstat, över de mest använda
SRM grupperna (-R är en odokumenterad växel).

* srmadm show -V 3
Ger en lista med SRMs variabler och dess värden.

* /usr/srm/unsupport/schedtree
Visar hur schedulerings trädet ser ut (odokumenterat kommando).

* srmkill [-l signal] 
Skickar signalen till alla processer som är associerade med användarens 
lnoder.

* liminfo -v 
Visar lnods information för användaren.

* limreport
Ger statistik om hur resurserna på systemet har används, kan till exempel
användas för att skapa underlag till fakturor. 

* limreport -a
Ger en fullständig rapport, ekvivalent med limadm -a;liminfo -v.

* limadm set -u cpu.shares=20 
Lägger till användaren i SRM's lnoder och ger den 20 CPU shares.

* limadm delete  
Tar bort användaren ur SRM.

* limadm set sgroup=root Knatte
Lägger in "Knatte" i scheduleringsgruppen "root".

* srmuser  
Kör kommandot efter att ha kopplat upp sig mot användarens lnoder.

			Backup/Restore av SRM data.
			---------------------------
1: Ta en backup på lnodes informationen:
# limreport 'flag.real' - lname preserve > /tmp/savelnodes

2: Stäng lnod databasen:
# srmadm set fileopen=n      (där n=no)

3: Trunkera densamma:
# cp /dev/null /var/srm/srmDB

4: Öppna lnod databasen:
# srmadm set -f /var/srm/srmDB fileopen=y

5: Ladda lnode databasen:
# limadm set -f - < /tmp/savelnodes

6: Starta om limdaemon:
# kill -HUP limdaemon_pid


			Variabler.
			----------
Variabler för minneshantering.
------------------------------
Alla dessa börjar med "memory.".

* MyUsage: nuvarande samt total användning av inoder och virtuellt minne.
* usage:   (egen MyUsage) + (den för childs & lnoden)
* accrue:  Hur mycket VM som lnoden har använt sedan den nollställdes.
* plimit:  VM begränsning per process i en lnode.
* limit:   VM begränsningen för lnoden.

Det finns även motsvarande variabler för terminal och cpu, till exempel
cpu.accrue eller terminal.usage.

Kernelvariabler.
----------------
Hör följer en lista över de kernel variabler som SRM använder, samt vad de 
normalt sett är satta till, samtliga dessa variabler kan ändras genom att man 
lägger in önskat värde i /etc/system, alla värden ligger i klassen srmlim.

* SRMProcsPerUID: Genomsnittligt antal processer per användare i SRM, 
                  default är 14.

* SRMLnodes: Hur många lnoder som skall cachas i kärnan.
             Standard värdet är noll, vilket innebär att kärnan kommer att
             räkna ut värdet. Algoritmen som används för att bestämma detta
             värde är ((nproc/SRMProcsPerUID)+SRMLnodesExtra)
             Defaultvärdet på SRMLnodesExtra är 20. Nproc är som alla vet
             max antal processer man får köra på systemet.

* SRMNhash: Storleken på SRM's hash tabeller.
            Standard värdet är noll, vilket innebär att kärnan tar det värde
            som SRMLnodes är satt till.
            
* SRMMemoryMax: Hur mycket av systemets minne som SRM max får utnyttja till 
                sina datastrukturer, default är 5%

* SRMMemWarnFreq: Hur ofta, i sekunder räknat, som SRM skall varna om en 
                  lnod använder för mycket minne, default är fyra sekunder.

Exempel: För att ändra SRMMemWarnFreq, lägg in följande i /etc/system:
set srmlim:SRMMemWarnFreq=10

Användarvariabler.			
------------------
Alla variabler som styr användarens rättigheter börjar med "flag.".

* uselimadm: ger samma rättigheter som root har.

* admin: ger rättigheter att administrera sin scheduleringsgrupp. 

* onelogin: en användare med denna flagga satt får enbart ha en samtida 
            inloggning

* nologin: en användare med denna flagga får inte logga in på systemet, denna
           flagga gäller om en användare har både denna och onelogin satt.

* asynckill: avsluta användarens processer om denna loggar ut ur systemet.

* asyncnice: sätt nice värdet för användarens processer till det lägsta 
             möjliga om användaren loggar ut.

För att ge någon rättigheter att administrera sin SRM grupp:
# limadm set -u flag.admin=set 

			Övrig information.
			------------------
Processer.
----------
ps -fel |grep srmgr (bör ha pid 4)
ps -fel |grep limdaemon 
ps -eo pid,class,args 

Om inte de flesta processerna ligger i klassen "SHR" så bör man verifiera
att "initclass" är satt till "SHR" i /etc/system, är inte detta fallet så
forkar inte init mot SHR, utan mot TimeShare, vilket medför att SRM inte
används.

Bootning.
---------
Om SRM inte fungerar och man vill boota utan att starta upp SRM kan man
göra en "boot -a" från OBP och därefter specificera "/etc/system.noshrload"
istället för "/etc/system". Denna fil skapas vid installation av SRM och är 
en kopia av /etc/system som den såg ut innan den blev modifierad av SRM.

Om man bootar upp ett system i single user och vill kunna använda SRM måste
limdaemon startas (/etc/rc2.d/S10srm start).

Övrigt. 
-------
Eftersom endast en SRM instans kan accessa lnod databasen (/var/srm/srmDB) 
samtidigt så krävs det att man administrerar alla SRM instanser inviduellt. 

Processer som körs som root har alltid prioritet över de andra processerna,
detta kan skapa problem om någon av de processer som körs av root löper amok.

Det går ej att starta SRM efter boot i nuvarande version, detta på grund av 
att SRM måste bli den klass som init forkar mot.

Det finns ett osupportat GUI att ladda ner från:
http://www.sun.com/software/resourcemgr/download.html

			Referenser:
			-----------
Web:
----
http://www.sun.com/solaris/ds/ds-resourcemgr/

Patchar:
--------
SRM 1.0:    108192
SRM 1.0:    109263 (backåt port av limid)
SRM 1.1:    110489
SRM 1.2:    111078

Mansidor:
---------
För mer information; installera SRM och läs mansidorna, vilka installeras
i /usr/srm/man.

_____________________________________________________________
Version 1.0 pub, senast petad på 25/Sep/2001 , Magnus Abrante


15:19 22/Nov/2013
footer image