|
 |
Linuxskolen del 8 (LINUXmagasinet 2/2003)
Effektiv bruk av Linux
Linuxskolen får denne gang sin virkelige ilddåp! Vi skal se hvordan man effektivt lar flere Linuxmaskiner dele CPU-er, og utnyttelse av denne kraftpakken sammen med terminalserver.
Dermed kan enkeltmaskinene i Linuxklyngen faktisk være diskløse og hente den openMosix-modifiserte kjernen fra serveren. Hva er vel vitsen med en masse prosessorkraft dersom den ikke blir brukt til noe? Siden vi også skal benytte K12 Linux fra K12 Linux Terminal Server Project, K12LTSP i dette oppsettet, må vi installere dette først.
k12 linux, terminalserver
Basert på Red Hat Linux og Linux Terminal Server Project (http://www.ltsp.org/) har K12 Linux utviklet seg til en stabil og fleksibel nettverksløsning for tynne klienter, og den FUNGERER! Konseptet oppsto blant tekniske koordinatorer i Portland, Oregon i USA for noen år siden, som et helt uforpliktende samarbeide. Dette har utviklet seg i forskjellige retninger. K12 Linux for skolebruk er den vi skal se nærmere på her, siden den passer ypperlig inn i mange sammenhenger hvor diskløse PC-er er ønskelig.
Du finner K12 Linux på http://k12ltsp.org/contents.html, og siste versjon er i skrivende stund 3.0.1 basert på Red Hat 8.0 med KDE og Gnome. Den enkleste måten å installere på er ved å laste ned de 3 imagene systemet består av fra ftp://k12linux.mesd. k12.or.us/pub/K12LTSP/3.0.1/iso/, brenne dem over på CD og installere som vanlig. Denne artikkelen benytter som eksempel K12 Linux-nettet fra ALOMAR Observatory hvor jeg arbeider (versjon 2.1.2). De som ikke har brent slike CD-er tidligere bør sjekke denne linken først; http://www.e-smith.org/docs/howto/CD_burning_howto.php3.
Maskinvaren du behøver for å sette opp en K12-server avhenger i stor grad av hvilken løsning du ser for deg. Ved inntil rundt 10 klienter holder en «vanlig» arbeidsstasjon med 1 GHz CPU, 512 MB RAM (50 MB/klient), 10 GB HD. Med flere klienter bør man over på en dual CPU maskin, 2 GB RAM, større disk osv. Jo mer RAM, dess raskere oppleves bruken av serveren. Raske nettverkskort og en stor HUB, eller helst en switch, er nødvendig for å skille terminalnettet fra hovednettet. Det er absolutt ikke ønskelig å belaste hovednettet med trafikken i terminalnettet.
Installasjonen er forholdsvis enkel og starter straks første CD er bootet. Klikk «Yes» og «Next» etter å ha valgt «LTSP Server». Du ender opp med en fullt fungerende LTSP server. Er du godt bevandret i Linux’ (Red Hats) applikasjonsjungel og administrasjon av arbeidsstasjoner og servere, velger du «Custom» og foretar dine egne valg.
nettverksoppsett
Du må ha to nettverkskort i serveren. Eth0 mot klientmaskinene og switch/hub, samt eth1 mot hovednettet eller internet. Eth0 settes opp med et privat
IP adresseområde ála 192.168.30.1 og ingen hostname. Eth1 gis en adresse fra hovednettet eller internett, hostname, DNS, gateway på vanlig måte. Du kan jo også la eth1 bruke DHCP dersom du har en slik server i nettet ditt. Dersom du benytter kun ETT nettverkskort eller ønsker et annet adresseområde enn den LTSP benytter som default, 192.168.0.x må du redigere følgende filer etter installasjonen:
/etc/exports
/etc/hosts.allow
/etc/rc.d/init.d/nat
/etc/hosts
/etc/dhcpd.conf
/opt/ltsp/i386/etc/lts.conf
/opt/ltsp/templates/k12linux/hosts-update.sh
/opt/ltsp/templates/k12linux/setup-update.sh
konfigurasjon av server
På ALOMAR booter de diskløse klientene via nett-verkskortene, 3Com Corporation 3c905C-TXM vha PXE. Dette skjer ved at kortet først kontakter DHCP på serveren, som starter bootingen ved å forsyne nettverkskortet med en PXE bootkjerne fra /tftpboot/lts/pxe/. Deretter forteller den hvilken Linuxkjerne som skal bootes og deler ut en IP-adresse iht oppsettet i /etc/dhcpd.conf. Dette må være satt opp slik:
# Sample configuration file for ISCD dhcpd at ALOMAR
#
# Don’t forget to set run_dhcpd=1 in /etc/init.d/dhcpd
# once you adjusted this file and copied it to /etc/dhcpd.conf.
#
default-lease-time 21600;
max-lease-time 21600;
#allow booting;
#allow bootp;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.30.255;
option routers 192.168.30.1;
option domain-name-servers 128.39.135.1;
option domain-name “alomar.no”;
option root-path “192.168.30.1:/opt/ltsp/i386”;
ddns-update-style ad-hoc;
option option-128 code 128 = string;
option option-129 code 129 = text;
shared-network WORKSTATIONS
subnet 192.168.30.0 netmask 255.255.255.0
# range dynamic-bootp 192.168.30.10 192.168.30.19;
use-host-decl-names on;
option log-servers 192.168.30.1;
group
use-host-decl-names on;
option log-servers 192.168.30.1;
host term-c01
hardware ethernet 00:02:1E:F1:F0:52;
fixed-address 192.168.30.10;
if substring (option vendor-class-identifier, 0, 9) = “PXEClient”
filename “/lts/3c905c-tpo.pxe”;
else if substring (option vendor-class-identifier, 0, 9) = “Etherboot”
filename “/lts/vmlinuz-2.4.18-4-om-client”;
option vendor-encapsulated-options 3c:09:45:74:68:65:72:62:6f:6f:74:ff;
option host-name “term-c01”;
option option-128 e4:45:74:68:00:00;
option option-129 „NIC=3c59x“;
host term-c02
hardware ethernet 00:02:1E:F1:EF:DA;
fixed-address 192.168.30.11;
if substring (option vendor-class-identifier, 0, 9) = “PXEClient”
filename “/lts/3c905c-tpo.pxe”;
else if substring (option vendor-class-identifier, 0, 9) = “Etherboot”
filename “/lts/vmlinuz-2.4.18-4-om-client”;
option vendor-encapsulated-options 3c:09:45:74:68:65:72:62:6f:6f:74:ff;
option host-name “term-c02”;
option option-128 e4:45:74:68:00:00;
option option-129 „NIC=3c59x“;
osv......
Serveren deler ut kjerner til klientene under boot-prosessen ved hjelp av et tftpboot. Kjernene ligger i
/tftpboot/lts/. Hos oss ser dette slik ut:
[kolbjorn@alo-term kolbjorn]$ ls -l /tftpboot/lts/
total 5628
-rw-r—r— 1 root root 18296 Oct 29 15:20 3c905c-tpo.pxe
drwxr-xr-x 3 root root 4096 Oct 29 11:45 boot
drwxr-xr-x 3 root root 4096 Oct 29 11:45 pxe
lrwxrwxrwx 1 root root 26 Nov 5 09:21 vmlinuz -> vmlinuz-2.4.18-4-om-client
-rw-r—r— 1 root root 1223680 Nov 5 09:20 vmlinuz-2.4.18-4-om-client
-rw-r—r— 1 root root 1404416 Jul 3 2002 vmlinuz-2.4.18-ltsp-1
-rw-r—r— 1 root root 1863168 Jan 20 2002 vmlinuz-2.4.9-1-kitchen-sink.img
Normalt booter klientene ut fra informasjonen i /etc/dhcpd.conf, men dersom de ikke står oppført her, vil default konfigurasjon i /opt/ltsp/i386/etc/lts.conf benyttes. Dersom noen av maskinene i nettet har spesielle kjernebehov, eller trenger ekstra settinger i forbindelse med drivere for mus, lyd- eller skjermkort, må /etc/dhcpd.conf brukes. Annen konfigurasjon av klientene gjøres i /opt/ltsp/i386/etc/lts.conf og vårt eksempel ser slik ut:
#
# Config file for the Linux Terminal Server Project at ALOMAR
#
[Default]
LTSP_BASEDIR = «/opt/ltsp/i386»
SERVER = 192.168.30.1
DEFAULT_SERVER = 192.168.30.1
LOCAL_APPS = Y
NIS_SERVER = 128.39.135.10
NIS_DOMAIN = alomar
# XSERVER = auto
# X_MOUSE_PROTOCOL = “PS/2”
# X_MOUSE_DEVICE = “/dev/psaux”
X_MOUSE_RESOLUTION = 400
X_MOUSE_BUTTONS = 3
USE_XFS = N
[term-c01]
XSERVER = auto
X_MOUSE_PROTOCOL = “PS/2”
X_MOUSE_DEVICE = “/dev/psaux”
XkbLayout = no
USE_NFS_SWAP = N
RUNLEVEL = 5
[term-c02]
XSERVER = auto
X_MOUSE_PROTOCOL = “PS/2”
X_MOUSE_DEVICE = “/dev/psaux”
XkbLayout = no
USE_NFS_SWAP = N
RUNLEVEL = 5
osv....
For at brukerne på ALOMAR skal kunne benytte alle sine filer i /home på hovedserveren er denne katalog-en NFS-mountet til K12 Linux-serveren. Sikre deg at /home på terminalserveren virkelig er tom! Oppsett av NFS gjøres slik i dette tilfellet:
- Hovedserver /etc/exports:
/home 192.168.30.0/255.255.255.0 (rw)
Restart NFS etter dette.
- LTSP server /etc/fstab:
alomar:/home/ /home nfs defaults,rsize=8192,wsize=8192 0 0
Vær sikker på at NFS-servers hostname og ip-adr. ligger i /etc/hosts
For å slippe problemer med brukerrettigheter og synkronisering av passord- og gruppefiler har vi satt opp hovedserveren som NIS-server. NIS benyttes først av LTSP serveren slik at den har en oppdatert bruker/gruppe-database og ikke får rettighetsproblemer med sin NFS-mountede /home. Klientene er satt opp med ypbind mot hovedserveren slik at heller ikke disse blir plaget med rettighetstull når de kobler seg opp mot /home på LTSP serveren under booting. Dermed ivaretar vi alle bruker/eier rettigheter, og slipper unna med vedlikehold av alle brukerne på én maskin. Det eneste som MÅ gjøres i forbindelse med innlegging av en ny bruker på hovedserver, for at denne skal kunne logge seg på terminalnettet, er følgende:
* Legge brukeren til som normalt på hovedserver
* Hopp inn i /usr/lib/yp
* Kjør “./ypinit -m” for å gjenoppbygge yp database
* Restart ypserver med “/etc/rc.d/init.d/ypserv restart”
* Logg inn på terminalserver og su root
* Restart ypbind med “/etc/rc.d/init.d/ypbind restart”
* For å sjekke at alt gikk bra: “ypmatch <username> passwd”
* Dette skulle returnere noe slikt som:
[root@alo-term kolbjorn]# ypmatch demobruker passwd
demobruker:$uLRJ4jNH$Xq9yUxo2XhpCq7YrzdbtZ1:
5020:5030::/home/demobruker:/bin/bash
Nå er hovedserver og terminalserver synkroniserte med hensyn til /home og brukere. Printere kan også enkelt legges til systemet. For mer info, sjekk dokumenta-sjonen til LTSP her: http://www.ltsp.org/documentation/ltsp-3.0.0/ltsp-3.0.html#AEN456
klientene
På de diskløse klientene skal du bare montere den maskinvaren du ønsker at de skal inneholde. Det skal, med mindre du har meget spesielle maskiner, være mulig å plugge dem i nettet og boote opp. Ferdige kjerner ligger i /tftpboot/lts/ som skulle passe for de fleste. Får du imidlertid slike problemer kan du forandre innføringen i /etc/dhcpd.conf for den spesielle maskinen og heller la den boote vmlinuz-2.4.9-1-kitchen-sink.img. Denne kjernen inneholder drivere for mye mer hardware enn den som er default – vmlinuz-2.4.18-4-om-client. Ønsker du «fine tuning» av enkelte maskiner må du gjøre dette via settinger i /etc/dhcpd.conf for hver maskin. Dersom du ikke har tilgang til nettverkskort med PXE, kan du boote klientene med en floppy som emulerer bootprom på nettverkskortet. (Se http://www.Rom-O-Matic.net). Imidlertid har K12-gutta gjort mye av jobben for deg, og du finner mange slike floppy boot images på K12-serveren etter installasjon. Finn det som passer og bruk enten «rawrite» under DOS, eller «dd» under Linux for å skrive imaget til floppyen, som du setter i den diskløse klienten og starter opp. Valg av default Window Manager gjør du som vanlig i Linux ved å velge enten bruk av kdm (KDE login manager) eller gdm (Gnome login manager). K12LTSP er default satt opp til å boote direkte inn i XFree86 (runlevel 5). Dette kan du forandre for hver klient i /opt/ltsp/i386/etc/lts.conf på serveren.
Vi har nå et fungerende terminalnett, og vi kan gjøre dette om til en kraftpakke i form av en openMosix-basert Linuxklynge (cluster). Dette er kronen på verket i denne artikkelen.
openmosix
openMosix er en utvidelse av Linuxkjernen som tillater single-CPU-systemer å jobbe sammen som en klynge, og forvandler disse maskinene til en supercomputer. Straks du har installert openMosix vil de forskjellige nodene (enkeltmaskinene) snakke sammen, og klyngen vil tilpasse seg den belastningen den til enhver tid utsettes for. Dersom en node opplever økt belastning i forhold til de andre, vil den automatisk overføre noe av databehandlingen til resten av klyngen. På denne måten vil openMosix prøve å holde alle maskinene like opptatt.
Hvordan oppnås så denne ytelsesforbedringen i praksis? En patch til Linuxkjernen gjør den om til en rask, sikker og kosteffektiv SSI- (Single System Image) plattform for klynger. Du ender med andre ord opp med en gruppe Linuxmaskiner som sammen oppfører seg som om den var bare en enkelt maskin. Med openMosix’ Auto Discovery kan nye noder tilføres klyngen mens den kjører, og disse nye vil automatisk oppdages og starte deling av de prosessene som pågår. Siden alle utvidelsene for openMosix er utført i Linuxkjernen, er det ikke nødvendig å programmere applikasjoner spesielt beregnet for klyngen. Alle programmene høster fordelene av openMosix’ distribuerte prosessering. Man kan sammenlikne med det som skjer i en SMP-maskin (fler-prosessor), med den forskjellen at openMosix utmerket skalerer til over 1000 noder som hver kan være flerprosessor-maskiner.
systemkrav
Minimum to Linuxmaskiner med raske nettverskort. Bedre nettverk gir bedre ytelse. I eksemplet benyttes samme kort i alle maskiner – 3Com 3c905C-TX [Fast Etherlink], da disse tillater booting via nett. Maskinene kan være av ymse slag hva gjelder CPU-kraft og minne. I eksemplet brukes en Pentium 166 MHz med 32 MB RAM. Om du bruker Red Hat, Mandrake, JBL, Debian eller SuSE spiller ingen rolle. Det som er viktig er at du minimum benytter en 2.4 kjerne, og at nettverkskortene er bra. Godt med diskplass til swap er også nødvendig.
klyngetyper
Det finnes 3 hovedtyper av openMosix-klynger:
- Single-pool lar alle servere og arbeidsstasjoner fremstå som en samlet klynge som deler likt på alle prosesser uten intervensjon utenfra
- Server-pool består av en gruppe servere koblet opp som en klynge. For å benytte klyngen må du logge deg på. Din egen arbeidsstasjon blir ikke belastet med oppgaver fra klyngen.
- Adaptive-pool betyr at serverne deler oppgavene mens arbeidsstasjonene kobler seg på/av og bidrar til klyngen når det er ønskelig. Du kan f.eks. bruke maskinen din alene på dagen, men om kvelden kobler maskinen seg til klyngen og er tilgjengelig for andre prosesser. Smart?
installasjon
Dette kan gjøres fort og smertefritt ved hjelp av ferdige RPM-er for utvalgte distribusjoner som Red Hat, eller ved å kompilere opp fra kildekode eller direkte fra CVS. Her er kommandoene for å hente fra CVS:
cvs -d:pserver:anonymous@cvs.openmosix.sourceforge.net:/cvsroot/openmosix login
cvs -z3 -d:pserver:anonymous@cvs.openmosix.sourceforge.net:/cvsroot/openmosix co linux-openmosix
cvs -z3 -d:pserver:anonymous@cvs.openmosix.sourceforge.net:/cvsroot/openmosix co userspace-tools
I dette eksemplet forutsetter jeg at du benytter Red Hat og at vi kompilerer fra stabil kildekode. Hvorfor ikke fra RPM? Vel, jeg tviler på at alle som kunne tenke seg å tukle med openMosix ikke allerede har tuklet med sin Red Hat, og dermed ikke lengre har et «jomfruelig» system hvor en RPM passer rett inn! Jobben må gjøres både for K12LTSP server og for de kjernene som klientene skal boote, siden de bruker en annen kjerne enn selve serveren. Vi starter med serveren. Vi henter openMosix kjerne-patch fra http://www.mosix.org/txt_distribution.html, og etter å ha akseptert lisensvilkårene finner du «Userland Tools» på http://www.mosix.org/txt_download.html.
Du trenger også en såkalt «vanilla kernel», en kjerne urørt av Red Hat eller andre, for å kunne tilføre patchen uten problemer. Pakk ut ny kjerne og link denne til /usr/src/linux før du patcher den med “patch -Np1 < openMosix1.5.2moshe” i en terminal. Deretter konfigurerer du den nye kjernen din på vanlig måte, men med spesielt henblikk på openMosix slik:
CONFIG_MOSIX=y
# CONFIG_MOSIX_TOPOLOGY is not set
CONFIG_MOSIX_UDB=y
# CONFIG_MOSIX_DEBUG is not set
# CONFIG_MOSIX_CHEAT_MIGSELF is not set
CONFIG_MOSIX_WEEEEEEEEE=y
CONFIG_MOSIX_DIAG=y
CONFIG_MOSIX_SECUREPORTS=y
CONFIG_MOSIX_DISCLOSURE=3
CONFIG_QKERNEL_EXT=y
CONFIG_MOSIX_DFSA=y
CONFIG_MOSIX_FS=y
CONFIG_MOSIX_PIPE_EXCEPTIONS=y
CONFIG_QOS_JID=y
Deretter kompilerer du den nye kjernen med ‘make dep bzImage modules modules_install ’.
Kopier den nye kjernen til /boot/ og husk å gjøre de nødvendige forandringer i /etc/lilo.conf (og kjøre /sbin/lilo etterpå) eller /etc/grub.conf for de som foretrekker Grub som boot manager. Kommandoen ‘make install ’ vil normalt gjøre hele jobben for deg automatisk, også rekonfig-urasjon av lilo.conf/grub.conf, men ikke alle liker denne løsningen. Reboot og din nye openMosix K12LTSP server er et faktum!
mosix filesystem
En ting i kjernen det er verdt å nevne her er CONFIG_MOSIX_FS=y. Dette er Mosix’ eget filsystem MOSIX Filesystem (MFS). Mosix bruker MFS til gjøre alle foldere og filer fra hver node tilgjengelig gjennom hele klyngen som om de er ett filsystem. En fordel med MFS er at det sørger for en enhetlig cache for filer sett fra forskjellige noder ved å vedlikeholde EN felles cache på servernoden. MFS tilfredsstiller den såkalte Direct File System Access- (DFSA) standarden, som utvider mulighetene for en migrert prosess til å utføre enkelte I/O-operasjoner lokalt på den noden den migrerte prosessen befinner seg på. Utvidelsen reduserer behovet for kommunikasjon med hjemme-noden (der prosessen startet) i I/O-operasjoner. Dermed kan slike prosesser, og også blandede I/O- og CPU-prosesser fritt migrere mellom de forskjellige nodene. Resul-tatet blir en mer dynamisk og «avslappet» klynge.
Tiden er inne for å patche kjernene for klientene. De diskløse maskinene inngår i Mosix-nettet, så kjernene de laster ned under boot patches og rekompileres for å gi tilgang til kjerneegenskapene i openMosix. Dette er en omstendelig prosess som jeg ikke vil ta for meg her, siden Ragnar Wisløff (ragnar@wisloff.no) har oversatt en utmerket HowTo om Linux Terminal Server som er skrevet av James McQuillan. Sjekk http://www.ltsp.org/documentation/ltsp-3.0-4-no.html og følg fremgangsmåten der. Etter at klientkjernene er ferdige og plassert i /tftpboot/lts/ gjenstår det litt konfigurasjon før alt er oppe og kjører. I /etc/mosix.map må du legge inn referanser mellom ip-adresser og mosix node-numre:
# MOSIX CONFIGURATION at ALOMAR
#
#
# Each line should contain 3 fields, mapping IP addresses to MOSIX node-numbers:
# 1) first MOSIX node-number in range.
# 2) IP address of the above node (or node-name from /etc/hosts).
# 3) number of nodes in this range.
#
#
# MOSIX-# IP number-of-nodes
#
1 192.168.30.1 1
2 192.168.30.10 6
Vi forutsetter nå at du har patchet og kompilert nye kjerner både for server og klienter, og at du nå er klar til å starte openMosix med /etc/rc.d/init.d/openmosix start. Nå kan du sjekke forholdene med /etc/rc.d/init.d/openmosix status, og det burde se noe slikt ut:
[root@alo-term kolbjorn]# /etc/rc.d/init.d/openmosix status
This is OpenMosix node #1
Network protocol: 2 (AF_INET)
OpenMosix range 1-1 begins at term-gw.alomar.no
OpenMosix range 2-7 begins at term-c01.alomar.no
Total configured: 7
Nå må du justere hvordan hver enkelt openMosix-klient skal se ut når det gjelder skjermkort, lydkort, ekstra applikasjoner osv. Dette lærer du mer om her: http://k12ltsp.org/faq.html#software.
Ved å koble openMosix og K12LTSP har vi på ALOMAR et eget nettverk hvor gjester og ansatte kan bruke arbeidsstasjoner plassert rundt om i bygget, fritt og uten behov for ekstra administrasjon av meg eller IT-avdelingen på Andøya Rakettskytefelt. Vi kan også benytte treg maskinvare som med openMosix og terminalserveren får økt ytelse. Vi kan enkelt legge til og trekke fra maskiner i nettet, og ved bruk av en egen swith/hub er terminalnettet adskilt fra hovednettet. At man enkelt administrerer all software på EN maskin, som så brukes av flere, er jo helt ypperlig. Det som gjenstår er å implementere en Windows 2000 terminalserver, slik at brukerne av klientmaskinene kan aksessere sine applikasjoner for Windows via rdesktop direkte i Linux. Det finnes neppe et system som kan kalles en administrators drøm, men dette er noe i nærheten!
|
 |
|
