🚀 go-pugleaf

Kristoff Bonne wrote:
> Gegroet,
> 
> 
> Ik ben aan het kijken om voor het werk een cluster op te zetten (zowel
> voor "load-balancing" als voor "redundatie" toepassingen).
> (mag linux zijn maar ook ��n of andere BSD).
> 
> 
> Maar via google vind je zoveel verschillende systemen en informatie dat
> ik compleet het bos niet meer tussen de bomen terugvind.
> 
> 
> Heeft iemand dat al enige praktische ervaring mee? Welke software? Welke
> distributies?
> 
> 
> 
> Cheerio! Kr. Bonne.

Hallo,

Welke clusteroplossing zoekt u eigenlijk precies? Wat moet er 
loadbalanced/failover gemaakt worden; webserver, fileserver, databaseserver?

Glenn

Glenn,

Glenn Matthys schreef:
>> Ik ben aan het kijken om voor het werk een cluster op te zetten (zowel
>> voor "load-balancing" als voor "redundatie" toepassingen).
>> (mag linux zijn maar ook ��n of andere BSD).
>> Maar via google vind je zoveel verschillende systemen en informatie dat
>> ik compleet het bos niet meer tussen de bomen terugvind.
>> Heeft iemand dat al enige praktische ervaring mee? Welke software? Welke
>> distributies?

> Welke clusteroplossing zoekt u eigenlijk precies? Wat moet er
> loadbalanced/failover gemaakt worden; webserver, fileserver,
> databaseserver?

Eigenlijk een combinatie van de twee.

Er zijn bepaalde zaken die in "load-balancing" moeten lopen. Het zijn
vooral jobs die mooi in parallel kunnen lopen. (bv. die bepaalde
statistieken ophalen uit toestellen en die in een database steken, die
resultaten in die database ophalen en daarop berekingen doen, of die als
http-server werken om die resultaten visualiseren).


Maar aan de andere kant zijn er ook zaken die in failover moeten werken
(vooral de SQL-server en de NFS-server).


En indien mogelijk zou ik ook de "controller" (of hoe noem je dat? De
server die alle jobs scedule-d, die bepaalde welke server welke jobs
krijgt, die zorgt dat jobs niet te lang blijven hangen, ...) willen
fail-safe hebben.
Dit zou handig zijn om geen "single point of failure" te hebben, maar is
niet strikt genomen 100 % noodzakelijk.





> Glenn
Cheerio! Kr. Bonne.

Kristoff Bonne wrote:
> Glenn,
> 
> Glenn Matthys schreef:
>>> Ik ben aan het kijken om voor het werk een cluster op te zetten (zowel
>>> voor "load-balancing" als voor "redundatie" toepassingen).
>>> (mag linux zijn maar ook ��n of andere BSD).
>>> Maar via google vind je zoveel verschillende systemen en informatie dat
>>> ik compleet het bos niet meer tussen de bomen terugvind.
>>> Heeft iemand dat al enige praktische ervaring mee? Welke software? Welke
>>> distributies?
> 
>> Welke clusteroplossing zoekt u eigenlijk precies? Wat moet er
>> loadbalanced/failover gemaakt worden; webserver, fileserver,
>> databaseserver?
> 
> Eigenlijk een combinatie van de twee.
> 
> Er zijn bepaalde zaken die in "load-balancing" moeten lopen. Het zijn
> vooral jobs die mooi in parallel kunnen lopen. (bv. die bepaalde
> statistieken ophalen uit toestellen en die in een database steken, die
> resultaten in die database ophalen en daarop berekingen doen, of die als
> http-server werken om die resultaten visualiseren).
> 
> 
> Maar aan de andere kant zijn er ook zaken die in failover moeten werken
> (vooral de SQL-server en de NFS-server).
> 
> 
> En indien mogelijk zou ik ook de "controller" (of hoe noem je dat? De
> server die alle jobs scedule-d, die bepaalde welke server welke jobs
> krijgt, die zorgt dat jobs niet te lang blijven hangen, ...) willen
> fail-safe hebben.
> Dit zou handig zijn om geen "single point of failure" te hebben, maar is
> niet strikt genomen 100 % noodzakelijk.
> 
> 
> 
> 
> 
>> Glenn
> Cheerio! Kr. Bonne.

Mijn gedacht is het altijd zo simpel mogelijk houden. NFS kan eenvoudig 
failover gemaakt worden (voor loadbalancing heeft u een echte NAS 
nodig), webservers ook. Statistieken (tenzij dit echt gebruikt wordt, 
anders zie ik dat maar als een extratje, omdat het leuk is naar 
grafiekjes te kijken) zijn bijzaak en als daar dus een onderbreking in 
zit, is dat geen ramp.

Wat u blijkbaar zoekt is een All-in-one suite om uw cluster te beheren, 
maw software die de cluster abstraheert. Waarschijnlijk hebben ze bij 
IBM of HP zo'n software, maar de prijs zal ook niet mis zijn ;-). Of 
hier opensource voor bestaat, geen idee, want ik weet eigenlijk zelf 
niet goed met welke zoektermen te beginnen.

Nu ik zou eens moeten zien hoe de situatie er in de praktijk uit ziet, 
misschien valt dit zelf eenvoudig te scripten.

Glenn

Op Mon, 05 Mar 2007 21:18:59 GMT
schreef Glenn Matthys <redshift@pandora.be>:

> (voor loadbalancing heeft u een echte NAS nodig)

Er is geen enkel noodzakelijk verband tussen die twee...


-- 
JanC

"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9

Jan Claeys wrote:
> Op Mon, 05 Mar 2007 21:18:59 GMT
> schreef Glenn Matthys <redshift@pandora.be>:
> 
>> (voor loadbalancing heeft u een echte NAS nodig)
> 
> Er is geen enkel noodzakelijk verband tussen die twee...
> 
> 

Ik denk dat als je het zelf probeert met open source software dat dat 
eigenlijk niet direct de betrouwbaarste oplossing is. Je hebt dan eerst 
al zo'n clustering filesystem nodig (er zitten er wel in de kernel) en 
dan nog een distributed lock systeem. Klinkt voor mij maar zeer fragiel.

Het was waarschijnlijk een SAN dat ik bedoelde.

Glenn

On Mar 6, 8:30 am, Glenn Matthys <redsh...@pandora.be> wrote:
> >> (voor loadbalancing heeft u een echte NAS nodig)
>
> > Er is geen enkel noodzakelijk verband tussen die twee...
>
> Ik denk dat als je het zelf probeert met open source software dat dat
> eigenlijk niet direct de betrouwbaarste oplossing is. Je hebt dan eerst
> al zo'n clustering filesystem nodig (er zitten er wel in de kernel) en
> dan nog een distributed lock systeem. Klinkt voor mij maar zeer fragiel.

Hangt er vanaf wat het doel is van het clusteren. Je hebt geen shared
filesystem nodig als de applicatie dat niet vereist.

Om parallel jobs uit te voeren kan je perfect je jobs distribueren
naar verschillende systemen zonder dat die systemen toegang moeten
hebben tot eenzelfde filesystem. De resultaten van de jobs worden bv
in een databank gepompt.

Mvg,
  Sven Vermeulen

Sven,

Sven Vermeulen schreef:

>>>> (voor loadbalancing heeft u een echte NAS nodig)
>>> Er is geen enkel noodzakelijk verband tussen die twee...
>> Ik denk dat als je het zelf probeert met open source software dat dat
>> eigenlijk niet direct de betrouwbaarste oplossing is. Je hebt dan eerst
>> al zo'n clustering filesystem nodig (er zitten er wel in de kernel) en
>> dan nog een distributed lock systeem. Klinkt voor mij maar zeer fragiel.

> Hangt er vanaf wat het doel is van het clusteren. Je hebt geen shared
> filesystem nodig als de applicatie dat niet vereist.

> Om parallel jobs uit te voeren kan je perfect je jobs distribueren
> naar verschillende systemen zonder dat die systemen toegang moeten
> hebben tot eenzelfde filesystem. De resultaten van de jobs worden bv
> in een databank gepompt.

Maar dan heb je hetzelfde probleem daar. Dan moet je *die* redundant
maken anders heb je *daar* een single-point-of-failure.


Als je nu je informatie in een NFS filesystem of een SQL-server zet; dat
maakt m.i. conceptueel niet zoveel verschil uit!

Het probleem is dat bepaalde toepassingen nu eenmaal op basis van eigen
bestandsformaten werken (bv. rrdbestanden) en je dus niet altijd naar
SQL kunt gaan zonder de toepassing aan-te-passen.





>   Sven Vermeulen
Cheerio! Kr. Bonne.

Kristoff Bonne schreef:
> Maar dan heb je hetzelfde probleem daar. Dan moet je *die* redundant
> maken anders heb je *daar* een single-point-of-failure.
>
>
> Als je nu je informatie in een NFS filesystem of een SQL-server zet; dat
> maakt m.i. conceptueel niet zoveel verschil uit!

In tegendeel, ik vind juist dat een databank versus een
bestandssysteem wel een enorm conceptueel verschil uitmaken. Je hebt
ondersteuning voor transacties en de databank-software zelf levert de
high-availability ondersteuning (ipv dat je die zelf moet bricoleren).

Je hebt altijd wel ergens zwakke schakels; als je meerdere systemen
opzet met een IP sprayer ertussen is deze laatste je single-point-of-
failure en moet je ook daar weer zoeken naar een oplossing. Zo ook
voor netwerken: als je traffiek over 1 lijn gaat is dat een spof.

Een degelijke analyse van je vereisten is daarom altijd een
noodzaak ;-)

Mvg,
  Sven Vermeulen

> 
> Een degelijke analyse van je vereisten is daarom altijd een
> noodzaak ;-)


klopt, maar het is wel dikwijls moeilijk om de betrouwbaarheid van
componenten te beoordelen. Full redundancy in netwerk en systemen is wel
te doen, hoewel niet altijd makkelijk (kosten stijgen ook exponentieel).
Maar van zodra je ��n component niet redundant maakt, is het vaak
moeilijk in te schatten hoe "available" je systeem nog is.

Voorbeeld: in een omgeving met wat servers en cisco-switchen. Als je
beslist de switch niet redundant te maken, wil je weten hoe vaak zo'n
switch kan vastlopen/crashen of hoe groot de kans is dat een poort kapot
gaat. Of hoe gaan kabels kapot? Is het hoogst uitzonderlijk dat een kabel
kapot gaat of gebeurt het regelmatig? (ik heb nog nooit een UTP-kabel echt
kapot zien gaan, maar soms moet ik wel redundancy voorzien voor het geval
dat...)

Bestaan er eigenlijk benchmarks voor switchen op dat vlak ? (mean time
between failure statistieken of zo). Ik vermoed dat een switch wel meer
available zal zijn, dan een typisch linux systeem waarop een paar servers
draaien. Als daar cijfers over zijn, dan is het makkelijker te beslissen
of je je switchen nu al dan niet redundant moet maken  (lees: of het de
moeite loont om er veel meer geld en tijd aan te spenderen om je
netwerkverbindingen tussen hosts redundant te maken)

met bonding bv kunnen nic-failures overleefd worden (cable-failures ook,
als ze zich al voordoen), maar als je volledige redundancy wil, dan moet
je beide kabels naar verschillende switchen laten lopen, in sommige
topologie�n moet je dan al spanning tree gaan draaien op de switchen...
het kan snel complex (en duur) worden met redundante switchen.

slurper wrote:
>> Een degelijke analyse van je vereisten is daarom altijd een
>> noodzaak ;-)
> 
> 
> klopt, maar het is wel dikwijls moeilijk om de betrouwbaarheid van
> componenten te beoordelen. Full redundancy in netwerk en systemen is wel
> te doen, hoewel niet altijd makkelijk (kosten stijgen ook exponentieel).
> Maar van zodra je ��n component niet redundant maakt, is het vaak
> moeilijk in te schatten hoe "available" je systeem nog is.
> 
> Voorbeeld: in een omgeving met wat servers en cisco-switchen. Als je
> beslist de switch niet redundant te maken, wil je weten hoe vaak zo'n
> switch kan vastlopen/crashen of hoe groot de kans is dat een poort kapot
> gaat. Of hoe gaan kabels kapot? Is het hoogst uitzonderlijk dat een kabel
> kapot gaat of gebeurt het regelmatig? (ik heb nog nooit een UTP-kabel echt
> kapot zien gaan, maar soms moet ik wel redundancy voorzien voor het geval
> dat...)
> 
> Bestaan er eigenlijk benchmarks voor switchen op dat vlak ? (mean time
> between failure statistieken of zo). Ik vermoed dat een switch wel meer
> available zal zijn, dan een typisch linux systeem waarop een paar servers
> draaien. Als daar cijfers over zijn, dan is het makkelijker te beslissen
> of je je switchen nu al dan niet redundant moet maken  (lees: of het de
> moeite loont om er veel meer geld en tijd aan te spenderen om je
> netwerkverbindingen tussen hosts redundant te maken)
> 
> met bonding bv kunnen nic-failures overleefd worden (cable-failures ook,
> als ze zich al voordoen), maar als je volledige redundancy wil, dan moet
> je beide kabels naar verschillende switchen laten lopen, in sommige
> topologie�n moet je dan al spanning tree gaan draaien op de switchen...
> het kan snel complex (en duur) worden met redundante switchen.

Inderdaad, daarom is het meestal eenvoudiger om bepaalde zaken enkel te 
houden om het onderhoud te vereenvoudigen. Als er dan problemen zijn met 
de setup zijn deze ook gemakkelijker op te lossen want er zijn minder 
onderdelen om rekening mee te houden.

Sommige switches krijgen ook een MTBF waarde mee van de fabrikant, onder 
andere foundry networks doet dit.

Over het algemeen reken ik switches tot heel betrouwbare apparaten, 
omdat ik er zelf nog geen uitval mee gekend heb. Het gemak aan switches 
is ook, als ze kapot gaan heb je ze gewoon maar te vervangen. Servers, 
afhankelijk van welke diensten er op draaien - en nog belangerijker, of 
er andere gebruikers op inloggen of niet - vallen bij mij onder de 
categorie onbetrouwbaar tot heel onbetrouwbaar.

Overigens, databases op NFS? Brrr!

Glenn

Glenn Matthys wrote:

> Wat u blijkbaar zoekt is een All-in-one suite om uw cluster te beheren,
> maw software die de cluster abstraheert. Waarschijnlijk hebben ze bij
> IBM of HP zo'n software, maar de prijs zal ook niet mis zijn ;-). Of
> hier opensource voor bestaat, geen idee, want ik weet eigenlijk zelf
> niet goed met welke zoektermen te beginnen.
> 


komkom, EDF.fr maakte kerrighed gratis en voor niks ...
http://www.kerrighed.org/

een sys admin van het st pieters college van Jette zou het mogelijks
gebruiken, zeker ben ik niet ...

Kristoff Bonne wrote:

> Gegroet,
> 
> 
> Ik ben aan het kijken om voor het werk een cluster op te zetten (zowel
> voor "load-balancing" als voor "redundatie" toepassingen).
> (mag linux zijn maar ook één of andere BSD).
> 


http://sites.vnuexhibitions.com/sites/bezoekers_infosecurity_be/en/page.asp?module=pages&type=item&id=14175