Redundantie switches of SLA.

[Verwijderd]

Ik ben momenteel aan het uitzoeken of het verstandig is de huidige afgesloten SLA's op de netwerkapparatuur op te zeggen of in plaats daarvan 100% redundantie realiseren.

De huidige SLA's dekken een reparatietijd van 8 uur. (binnen kantooruren). Jaarlijks zijn we rond de €9000 euro kwijt aan de SLA's (hierbij worden in totaal 12 switches gedekt, Cisco catalyst 2950 2*GBIC 48/24prts).

Voor een volledige redundantie zou een investering van €8000 voldoen.

Belangrijke noot hierbij is dat de netwerkapparatuur een economische levensduur heeft van 5 jaar en dus zeker voor die periode een SLA behoeft.

Simpele reken som leidt tot:
SLA: 5 x €9000 : 45.000
Redundantie: 1 x € 8000

Mogelijk kort door de bocht lijkt het mij verstandig om voor de redundantie te gaan.... Hebben jullie hier andere meningen over laat het me graag weten.

[ Voor 5% gewijzigd door Verwijderd op 05-01-2004 13:26 ]

[[ash]]

Je moet natuurlijk niet de kosten meerekenen in geval er wel een switch uitvalt, je zal de redundantie toch moeten herstellen. Hoe zit het met garantie/reparatie tijden als je dus geen nieuwe SLA's afsluit.

[Verwijderd]

[ash] schreef op 05 januari 2004 @ 13:31:
Je moet natuurlijk niet de kosten meerekenen in geval er wel een switch uitvalt, je zal de redundantie toch moeten herstellen. Hoe zit het met garantie/reparatie tijden als je dus geen nieuwe SLA's afsluit.

In principe geeft Cisco een ongelimiteerde garantie mits het apparaat zich in de juiste omgeving bevindt. Daarbij geven zij een MTBF van 18 jaar, wat de economische levensduur zéér ruim overtreft. Onder garantie valt tevens de reparatie een reparatietijd wordt hier echter niet genoemd.

[[ash]]

Dan klinkt het naar mij als een goed idee, hou alleen wel rekening mee dat de netwerk omgeving hierdoor complexer wordt en dat er dus betere en duurder netwerk beheerders nodig zijn.

[kell.nl]

Nog een voordeel van redundantie is, indien goed geimplemteerd, dat de down-time behoorlijk korter is, in het geval van een storing. (SLA=8 uur, redundantie=ca. 10 minuten om de getroffen kabeltjes om te prikken).
Dat zou je dus ook in je kostenberekening mee kunnen.

Daar staat wel tegenover dat bij een calamiteit de down-time weer veel langer kan zijn. (bijv. brand, waarbij alle switches uitbranden). Maar als de switches ook bij de servers staan, kan dat misschien wel te verwaarlozen zijn, als de levertijd van nieuwe servers langer duurt, dan de levertijd van de switches. (De mensen kunnen dan sowieso niet werken)

[raymonvdm]

Als je toch zorgt dat je switches via glas in een ring lopen dan. Schakelt toch een deel van de ring uit door z`n spanning tree totdat 1 van de switchen uitvalt. Omdat het spanningtree protocol dan een andere route zoekt. (de spanningtree down gebrachte interface zal up gebracht worden. om zo weer een link te krijgen)

In hoeverre wil je redundant zijn ? en wat mag het allemaal kosten.

Wij hebben trouwens een 4 uurs contract op onze catalyst 4006`en. Wil alleen niet weten wat het kost.

[Verwijderd]

Ik snap niet helemaal waarom je dit onder een noemer gooit?

Naar mijn idee zijn redundancy en sla's twee totaal verschillende dingen.
Een sla van 8 uur is leuk maar zeker niet te gebruiken als redundancy:

Bellen tijdens kantooruren is vaak het credo en dat betekent dat je om 19:00 s'avonds dus gewoon het "haasje" bent.

Mijn advies:

Bouw redundancy in om er zeker van te zijn dat je organisatie ten alle tijden up is.
Denk vervolgens na of de desbtreffende sla's wel hun geld waard zijn, mijn persoonlijke mening is hier vrij negatief over.
Sla's zijn vaak duur en na jaren braaf betalen kun je 9/10 keren zelf de shit opruimen.

[Routed]

Een SLA op 2950's vind ik zowieso redelijk overdreven.
De prijs hiervan weegt zoals je zelf al had berekend niet op tegen de prijs van de switches zelf.
En om nou gelijk redundant te gaan in een netwerk van 12 switches en het netwerk gelijk maar te verdubbellen is ook weer zo rigo maatregel.

Tussen stap zou kunnen zijn om de grootste patchkast als spare op de plank te zetten (4 stukes ofzow).
Mocht er dan een switch dood gaan dan is het een kwestie van een nieuwe pakken, config erop fietsen en inbouwen, dit neemt incl omzetten van de patches zeker niet meer dan 10min in beslag (en ja dit hebben we getimed ).

Bij ons hebben we dus een continue spare vooraad van minimaal 11 3550's en 10 2950's.

De enige switches waar wij een sla op hebben zijn de 6500's, die ga je nml niet echt op spare nemen

[Verwijderd]

/me agrees met deff.

Die switches kan je voor de prijs van 2 jaar van je SLA al vervangen...Paar op standby houden en de SLA's opzeggen. Ik neem aan dat er overspanningsbeveiligingen voor die switches hangen, dus ik verwacht niet dat er opeens 8 switches tegelijk eruit knallen. Paar op de plank zetten en die inzetten in geval van moeilijkheden.

[SED]

Verwijderd schreef op 06 januari 2004 @ 11:50:
/me agrees met deff.

Die switches kan je voor de prijs van 2 jaar van je SLA al vervangen...Paar op standby houden en de SLA's opzeggen. Ik neem aan dat er overspanningsbeveiligingen voor die switches hangen, dus ik verwacht niet dat er opeens 8 switches tegelijk eruit knallen. Paar op de plank zetten en die inzetten in geval van moeilijkheden.

Me too...
Paar op de plank is ruim voldoende.
Volledige redundantie kost overigens meer dan alleen de prijis van de switches!!
Dus gewoon paar ( 2) op plnak zetten en dan ook daadwerkelijk niet gebruiken want die verleiding is nogal groot blijkt in de praktijk

[Verwijderd]

SED schreef op 06 januari 2004 @ 17:59:
[...]


Me too...
Paar op de plank is ruim voldoende.
Volledige redundantie kost overigens meer dan alleen de prijis van de switches!!
Dus gewoon paar ( 2) op plnak zetten en dan ook daadwerkelijk niet gebruiken want die verleiding is nogal groot blijkt in de praktijk

Ik heb hier nog wat oude meuk liggen voor het geval 1 van de Cisco's het begeeft. Hoeven het maar vol te houden, totdat de boosdoener terug is van reparatie. Performance is hier niet zo heel erg belangrijk, dus tijdelijk een aantal werkplekken op 10 of 100 Mbit hubs is niet zo'n ramp.