🚀 go-pugleaf

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