On Tue, 2006-10-10 at 01:30 +0200, Stefan Suurmeijer wrote:

> Ik geloof dat mijn naamgeving een beetje ongelukkig gekozen is. Ik had
> misschien beter "inventarisatie technische randvoorwaarden" kunnen ...

Klopt, geeft niet. Belangrijker is dat we gestructureerd het project
verder afwikkelen.

> Tweede insteek was dan ook om een eerste beeld van de functionele wensen
> te krijgen. Jullie kennen je gebruikers natuurlijk goed en kunnen
> ongetwijfeld daar wat zinnigs over zeggen.
Inderdaad, uitgangspunt moet zijn een programma van eisen vanuit de
gebruikersgeledingen.
Voor de FWN pilot heb ik destijds getracht aan te geven op welke
gebruikersdisciplines we voor de FWN gebruikersgroep zouden moeten
mikken : een onderzoeker/ontwerper die een "rijke" en gemakkelijk
(her)configureerbaar en betrouwbaar systeem verlangt waar hij ook zijn
overige ("kantoor") automatiseringstaken op kwijt kan. In het geval van
een "RuG brede" werkplek is dat een hele opgave. Differentieren naar
onderzoeksgroepen via server based software is misschien nodig,maar we
moeten daarbinnen nog steeds uitgaan van een en dezelfde client
distributie.
Wijzelf (IWI) kent twee hoofdgroepen Linux gebruikers: onze studenten en
onze onderzoekers,verder niet. Ze hebben op dit moment exact dezelfde
client installatie. Voorzover er verschillen zijn leggen we die aan op
de servers van het domein: nauwelijks verschillend, hier en daar wat
extra software.

> Met die randvooraarden en gegevens wil ik een eerste schets maken van
> een functioneel en een technisch ontwerp. Die eerste schets moet dan
> worden voorgelegd aan een aantal kerngebruikers om hun mening te polsen.
> aan de hand daarvan worden de schetsen dan uitgewerkt tot een definitief
> ontwerp. Dat ontwerp zal deel gaan uitmaken van een projectplan voor
> realisatie van de LWP.
>
> > Het lijkt me zinvol dit stuk ter hand te nemen en verder uit
> > te werken
> >
> Een mooi stuk, dat kan zeker dienen als basis voor een projectplan.

Ok, we hebben wel een paar van deze gebruikers. We vragen ze wel even en
maken een lijstje.

> Een paar vragen/opmerkingen daarover:
> -   Begrijp ik goed dat de installatie van een werkplek, groot 5.7GB bij
> IWI momenteel in 6 minuten gebeurd?

Ja, dat begrijp je goed. 6 (zes) minuten realtime vanaf een kale disk,
je mag wel eens langskomen om te klokken :-)

> -   Is het handig zowel een uninstall als een image uitrol mogelijk te
> maken? Afhankelijk van werkplek en specifieke noden kan dan gekozen
> worden voor een uninstall installatie dan wel het plaatsen van een image
Uninstall begrijp ik even niet. We installeren alleen maar.
Een rollback zoals in MS-Windows kennen we niet.
We testen natuurlijk wel eerst gedegen op een testsysteem.
Ons deployment systeem is voornamelijk gebaseerd op imaging. Daarnaast
voert het een configuratie uit na het laden van de bundles en de
gebruiker kan aan de slag.

> -   Het is duidelijk dat er aanpassingen nodig zijn in de
> authenticatieomgeving om een LWP te faciliteren (bijv. de Posix
> attributen, groepen om toegang fijnmaziger te kunnen reguleren). Alle
> noodzakelijke aanpassingen zullen zoals vermeld uitgevoerd worden
>
Prima !

> -   Zie ook een eerdere mail van Arjan: ik ben eerlijk gezegd ook nog
> niet overtuigd van het nut van jouw data-servers.
> Het
> authenticatiecluster (LDAP servers) is zeer redundant uitgevoerd en zal
> op afzienbare termijn losgekoppeld worden van de RUG-tree, hetgeen de
> stabiliteit (nu al >99,9% beschikbaar) nog zal verhogen.
Dit is een afweging. Natuurlijk, elke server vergt extra beheer. Maar
gebruikersgroepen kunnen allerlei redenen hebben om locale dataservers
op te houden. Ze kunnen nuttige functies vervullen, ook qua stabiliteit
en quality of service.
LDAP replicatie bijvoorbeeld. Mijn perceptie van de QOS van de L:DAP
server is trouwens anders. Ik kijk nu een jaar mee in een maillinglist
( itteam ) en ik heb heel veel ellende gezien die geweten werd aan de
slechte QOS van de LDAP authenticatie server. Centrale SAN storage bleek
een ander probleem het afgelopen jaar.

We (vooral Jurjen) hebben ook metingen gedaan aan de performance van SAN
en Novell storage t.o.v. NFS.
Mijn voorlopige conclusies :
- Er is een probleem met de data r/w performance op de centrale
  storage.
- Het probleem is tevoorschijn gekomen tijdens vergelijkende
  performance metingen tussen een Novell en een NFS cient-server
  datamodel.
- Er dient een nader onderzoek gestart te worden naar de oorzaak
  van deze performance verschillen.
- De metingen geven een vertekend beeld ten nadele van de NFS
  oplossing, daar aan de server zijde daarvan ook nog eens een ten
  opzichte van het centrale SAN een simpele ( IDE ! ) RAID als
  schijvenpakket staat (onze RAID haalt 40 MB/s r/w throughput
  op het device, niet slecht, maar harder wil ook domweg niet vanwege
  de IDE schijven).

> Plaatsen van
> lokale servers zal in mijn optiek eerder leiden tot meer downtime
> (grotere kans op storingen door hardware etc). Los daarvan: mijn
> "knooppunt servers" waren exact wat jij beschrijft, namelijk een eigen
> LDAP kopie (replica) van de centrale user accounts. Wat je wilt is dus
> zeker mogelijk, maar je moet me nog wel overtuigen van de wenselijkheid.
> Hoe denken de anderen hierover? Arjen, jij ziet geen meerwaarde begrijp ik?
> -   Je stukje over centrale storage snap ik niet helemaal geloof ik.
> Afhankelijk van de manier waarop we toegang bieden tot centrale storage
> is er een aantal beveiligingszaken waar rekening mee moet worden
> gehouden, maar dit hoeft niet noodzakelijkerwijze te leiden tot
> verminderde user data security.

Storingen valt nogal mee. We moeten onze servers bijna uit slaan om ze
te stoppen nadat ze eenmaal zijn gestart: meestal draaien ze jaren, tot
we ze vervangen moeten omdat ze uit het servicecontract lopen.
Maar ze kosten geld, inderdaad.
Die servers kunnen straks vrij simpele machines zijn: Het enige
wezenlijke wat ze moeten doen is wat administratie regelen, o.a. t.a.v.
LDAP replicatie en wat file i/o handling. Er zijn hier nogal wat
twijfels over de performance van datatransporten van grote groepen Linux
clients over het netwerk naar een centrale storage. Afzonderlijke
datalijnen via f.o. kanalen naar de SAN kan dat m.i. ondervangen.

> distributies: we moeten natuurlijk op zeker moment een keuze maken:
> meerdere distributies aanbieden is wat mij betreft geen optie. Nogmaals:
> ik ben er van overtuigd dat met alle distributies aan (vrijwel alle)
> functionele wensen van gebruikers valt te voldoen. Op grond van
> randvoorwaarden die uit ons overleg naar voren zijn gekomen hebben we
> vooralsnog de keuze beperkt tot SuSE of Red Hat, ik hoop dan ook dat we
> een keuze tussen die twee kunnen maken.
> Ik zou dan ook iedereen willen vragen om over beide distributies na te
> denken en met een eigen lijstje plussen en minnen te komen (en hopelijk
> op grond daarvan een keuze). Van Jurjen heb ik begrepen dat hij een
> lichte voorkeur voor SuSE heeft, voornamelijk vanwege bekendheid ermee.
> Voor mij geldt hetzelfde en daarnaast is het feit dat SuSE al in
> licentie is een plus wat mij betreft.
>
Ik sluit me daarbij aan.

--
Met vriendelijke groet,

 ---Harm


---------------------------------------------------------------------------
 Harm Paas,  Sys. Admin.            Email     : [log in to unmask]
 Dept. of Computing Science,        Phone     : +31 50-3633944
 IWI - Instituut voor Wiskunde & Informatica
 Rijksuniversiteit Groningen        FAX       : +31 50-3633800
 PO Box 800, 9700 AV Groningen,     Country   : The Netherlands

---------------------------------------------------------------------------