Harm Paas wrote:
> On Tue, 2006-10-10 at 01:30 +0200, Stefan Suurmeijer wrote:
>
>>> 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.
>
>
Graag. Van de overige faculteiten hoor ik ook graag wie benaderd kan
worden. Ik zal in elk geval gebruikerswensen gaan inventariseren en op
basis daarvan een concept ontwerp maken. Maar ik voorzie nog wel steeds
dat de lezers van deze lijst uiteindelijk moeten kiezen voor een
distributie. Zowel SuSE als Red Hat zullen ongetwijfeld kunnen voldoen
aan de wensen.
Misschien dat het uiteindelijk toch een gevoelskwestie wordt, als de
verschillen heel klein zijn.

>> 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 :-)
>
>
Ik geloof je meteen. Dat is wel erg snel ;-)

>> -   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.
>
Oeps. Typo, ik bedoelde natuurlijk een unattended install ;-)

> 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.
>
>
Ok. Bovenstaande punt was dus: is er iets op tegen om zowel een image
als een unattended installatie te maken en op iedere plek de meest
logische variant te gebruiken? Betekent iets meer werk, maar dat kunnen
we mogelijk terugverdienen in flexibiliteit van installatie

>> -   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.
>
>
Een probleem momenteel is de verwevenheid van werkplekken en ldap
authenticatie. We zitten elkaar kort gezegd in de weg. Dus wordt een
nieuw LDAP cluster en tree opgebouwd waarop straks alleen maar ldap
authenticatie plaatsvindt en dat geen (directe) relatie met
werkplek-login meer heeft.
Het is waar dat er het afgelopen jaar wat problemen zijn geweest, met
name hardware gerelateerd (vanochtend nog zal sommigen opgevallen zijn).
Maar met dat al is de uptime ruim boven 99,9 %, en zoals gezegd, ik
verwacht dat na verplaatsing van authenticatie naar het nieuwe cluster
het aantal problemen vrijwel tot nul gereduceerd zal worden.
Een voorbeeld: om problemen met het SAN te ondervangen wordt aan *beide*
SANs gekoppeld. Zelfs als een SAN helemaal down gaat zal dat dan geen
effect meer hebben op het authenticatie cluster (afgezien van wat
foutmeldingen in logs). Door het weghalen van de login connecties van
duizenden windows pc's zal de load op de machines fors teruglopen,
worden ze dus minder warm, dus minder kans op hardware fouten. Plus, we
hebben een vijftal nieuwe machines aangeschaft die ruim gedimensioneerd
zijn.

> 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).
>
>
Remco heeft ook veel getest met ncpmount, en in zijn woorden, het
"zuigt." Dat kunnen we dus afschrijven lijkt me. Alternatieven zijn
toegang via Novell's proprietary oplossing (waarschijnlijk wat ze jou
hebben laten zien Jurjen) of via NFS.
Beide moeten getest worden, waarbij de voorkeur m.i. moet uitgaan naar
niet gebruiken van proprietary oplossingen waar vergelijkbare (of
hopelijk betere) oplossingen voorhanden zijn.

>> 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.
>
Ok, maar dan begrijp ik dat het je meer om I/O performance gaat dan om
authenticatie?

>
>> 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.
>
Staat genoteerd.

vrgr
Stefan