Administrace komentářů

Všechno popsané vím a mám to tak uděláno, ale né úplně vše. To je důvod, proč řeším otázky typu:
Vyplatí se toto předělávat a mít to robustně i na síťové vrstvě, nebo výpadek jednou za x let na 20min nevadí?
Musím to hned na všech úrovních řešit robustně, nebo půjde nějak minimalizovat popsané riziko na straně napájení?

Osobně jsem podobný incident zažil poprvé, většinou totiž když mi něco odešlo z těch kvalitnějších věcí, tak to bylo tak, že to prostě umřelo :-/

Každopádně někteří místní by ti řekli, že řešit failover pomocí RSTP je out of date, protože dnes existují řešení, které splní jak failover, tak mají oproti RSTP možnost využívat všechny trasy (LACP, IRF apod.) U routerů se dost často pro ten základ používá VRRP.
U L3 switche ale na VRRP lze zapomenout. Takže u něj se musí řešit failover pomocí stacku, tj. mít stackovatelný L3 switch a všechno do něj mít zapojeno do aspoň dvou node pomocí trunku nebo lacpu.

Pokud jde o výměnu switche, tak to nebývá moc jednoduchá akce, resp. záleží na několika faktorech. Téměř vždy to obnáší nějaký druh přednastavení (v případě stacku definování čísla stacku + portů pro cluster komuniaci, v případě normálního switche obnovu nastavení ze zálohy). Pokud jsou na switchích vlany, tak jsou tři možnosti výměny:
1) když není místo v racku, tak popsat si všechny zapojené kabely (třeba 48ks), vyměnit switch a znovu zapojit na porty, kde byly
2) když je místo v racku, tak nainstalovat switch pod současný a přepíchat kabely
3) pokud máme rozjetý 802.1x s automatickou konfigurací portů, tak opět easy a nic se neřeší, protože je vesměs jedno, co kam píchnu.
4) pokud chvátáme, máme vlany, nemáme místo v racku ani automatickou konfiguraci portů, tak to risknout, zapojit podobně a pak řešit nefunkční věci

Já osobně mám 10Gbit switche ve stacku, všechny servery připojený přes 4x10Gbit (2x10Gbit pro storage a 2x10Gbit pro app/hypervisory/zálohování/user access).
Zdar Max