Podcast: letöltés (Hossz: 18:45 — 18,1 MB)
- mi az a VSS?
- mit csinál a VSS?
- VSL (Virtual Switch Link)
- a VSL redundanciája
- mi történik, ha az aktív felügyelő meghibásodik?
- mi történik, ha egy VSL link meghibásodik?
- mi történik, ha egy nem VSL port meghibásodik?
- mi történik, ha az összes nem VSL Port meghibásodik?
- mi történik, ha a teljes VSL esik?
mi az a VSS?
először is meg fogjuk határozni a VSS-t. A VSS a Virtual Switching System rövidítése, és amikor a VSS-ről beszélünk, akkor egy klaszterről beszélünk, nem pedig egy veremről. A verem nem más, mint portok hozzáadása, és itt arról beszélünk, hogy egy fürtöt felszerelünk mindennel, ami azt jelenti, különben is, ne aggódjon, ha ez kissé rejtélyesnek hangzik, mert ennek magyarázata pontosan ennek a hangnak a célja.
a VSS lehetővé teszi két független kapcsoló átalakítását egy új, nagyobb kapcsolóvá. Ez lehet szerelni a Cisco 4500, 6500 és 6800, amelyek az adott hardver VSS, azaz nem érdemes semmilyen 6500, hogy megtaláljuk, annak érdekében, hogy felmászik egy VSS szükségünk speciális szoftver verziók és speciális hardver.
a VSS lehetővé teszi két kapcsoló kombinációját, hogy egyetlen logikai hálózati entitást érjen el a vezérlési és menedzsment sík perspektívájából.
az útválasztási protokollok megfelelő működéséhez egyetlen entitás biztosításával a Cisco SSO (IOS Statefull SwitchOver) technológiát és NSF (Non-Stop Forwarding) kiterjesztéseket használ.
természetesen az új virtuális kapcsoló kívülről úgy fog kinézni, mint egy entitás, mintha csak egy számítógép lenne, nem pedig kettő.
mit csinál a VSS?
- vezetői szinten egyesíti az SNMP-t, az SSH-t, a telnet-et ….
- a 2. szinten felelős a BPU-kértaz LACP, a MACs Gest-je…
- a 3 .szint felelős az útválasztási protokollokért, az útválasztásért…
mint látható, ez messze túlmutat azon, ami egy egyszerű verem lenne
és a kapcsoló feldolgozása szempontjából az active végzi a DFC-k továbbításának programozását a VSS-en belül, valamint a PFC (policy feature card) programozását a processzorról a kapcsolóra készenléti állapotban.
az aktív felügyelő PFC-je (policy feature card) elvégzi az aktív virtuális swtich-en keresztül belépő forgalom, valamint a másik kapcsolón keresztül belépő másik kapcsoló PFC-jét. A DFCs pedig ugyanezt fogja tenni a kártyáin.
ezt már tudja, de a CFC-k nem hoznak döntést, mert a döntést továbbítják a felügyelőnek, ha valaki még mindig rendelkezik ilyen típusú kártyával.
VSS lehetővé teszi a központosított kezelése mindent, hogy BGP, STP, OSPF, LACP, amit akarsz.
VSL (Virtual Switch Link)
VSS már megjegyeztük, hogy ez egy két kapcsolóból álló klaszter, de természetesen ezeknek a kapcsolóknak valamilyen módon csatlakozniuk kell hozzájuk, ellentétben egy köteggel, amelyet általában saját kábelekkel végeznek itt a kapcsolók egyesítése egy VSL-en (Virtual Switch Link) keresztül történik, amely nem más, mint egy 10-es vagy 40G port étercsatornája, ez lehetővé teszi a VSS-t alkotó csapatok együtt, személy szerint nem látom hasznát a VSS elválasztásában a VSS-ben kialakuló két kapcsoló, de tudod, hogy ha megtalálod, és szolgál, használhatod.
a VSL-en áthaladó forgalom a VSH (Virtual Switch Header) fejlécbe van beágyazva, ami érdekes, hogy mindennél többet tud, mert a VSH fejléc hossza 32 bájt, abban az esetben, ha körülbelül 10g távvezérlőre kell továbbítania, hogy figyelembe vegye a keret méretét.
miután elhelyezte a VSL-t alkotó kábeleket, el kell indítania, mert ez egy LMP (Link Management Protocol) nevű protokollt játszik le, amely ellenőrzi, hogy a linkek helyesek-e, kicseréli a kapcsolók azonosítóját, majd a szükséges információkat mindkét alváz kommunikálásához.
ezután ellenőriznünk kell, hogy mind a szoftver, mind a hardver kompatibilis-e, hogy később eldönthessük, melyik számítógép lesz aktív, és melyik biztonsági mentés a VSS vezérlő síkjához.
itt jön egy RRP (Role Resolution Protocol) nevű protokoll, amely éppen ezt teszi, ellenőrizze, hogy minden kompatibilis-e, és válasszon egy aktív kapcsolót és egy készenléti kapcsolót.
és itt kezdődik az ügy húsa, mert az ellenőrzések lehetnek helyesek vagy sem, ha helyesek, mindent inicializálnak, és a switch NSF/SSO (Nonstop Forwarding / Statefull Switchover), ez jó, de ha valami rosszul megy, a VSS módban van RPR (Route-Processor Redundancy) és az összes modul ki van kapcsolva. Ez az, ahol valódi probléma merülhet fel, amikor látja, hogy a számítógépek RPR módban maradnak, ezt soha nem akarjuk látni, és amikor először látjuk, ki akarunk menni onnan, de valójában azért van, mert valami nincs rendben, több nélkül, az egyetlen dolog, amit meg kell tennünk, hogy lélegezzünk és keressük a különbségeket.
a VSL redundanciája
bizonyára rájössz, hogy a VSL a VSS alapvető része, valóban VSL nélkül nem lenne szinkron a két processzor vezérlő síkjai között, ráadásul VSL nélkül a VSS közvetlenül nem indul el, mert az SSO nem lesz képes esubler az életben, tehát a VSL redundanciája alapvető.
valójában két vagy négy VSL kábel függ az egyes kapcsolókon lévő vezérlők számától. Tulajdonképpen egy alváz vezérlő elég, és ha csak egy alváz vezérlő fogunk csatlakozni mindkét alváz egy 2-vezetékes etherchannel.
most, ha két processzorunk van, akkor egy kábellel csatlakozunk az 1.kapcsoló 1. vezérlőjéhez a swich 2. vezérlővel, egy másik pedig a 2. vezérlővel, majd az első kapcsoló második vezérlőjének másik kábelpárjával a második kettővel, vagyis az ellenkező kapcsoló kettőjéhez csatlakoztatott vezérlőkkel, és természetesen ez 4 kábel. Ezért 2 vagy 4 kábelt használnak a VSL redundanciához, az egyes kapcsolók vezérlőinek számától függően.
mint látod, ez nem olyan nehéz megérteni a működését egy VSS, valami sok új, és ezért hangzik ismeretlen, de ez nem bonyolult, csak új
akkor van egy kérdés, hogy tényleg semmi köze a VSL, de ha ez köze van az irányítást, amit mi nevezünk a dual active, amely egy olyan forgatókönyv, amelyben mindkét kapcsolók teszik ki a VSS aktív marad, mert a VSL esett teljes ez rossz, Nagyon rossz, és hogy megakadályozzák ezt a felderítő mechanizmusokra van szükségünk.
ezek a mechanizmusok alapvetően két PAGP+ (enhanced PAgP), amely egy Cisco szabadalmaztatott protokoll, ezért nem tetszik, és inkább a BFD opciót részesítem előnyben, amely kissé hosszabb konfigurációval rendelkezik, két további sorról beszélek, de ugyanazt szolgálja.
ez olyasmi, amit mindig be kell állítani az első etherchannel, hogy van beállítva, jól, és a második és a harmadik.
mind a PAGP+, mind a BFD lehetővé teszi a kapcsolók kettős aktív helyzetének azonosítását.
akkor nem felejtem el, hogy van egy gyors Hello Detection nevű dolog, amelyet később vezettek be, de még soha nem használtam, ezért nem kommentálom, csak azt mondom, hogy létezik, és hogy ez egy másik lehetőség, amit láttam, nagyon egyszerű.
és ha kettős aktívat észlel, mi történik? mmmm, mivel az egyiket újraindítják, hogy újra gyanakodjanak, elvileg semmi sem történhet, de ez nem kívánatos helyzet.
Mindenesetre, ha úgy gondolja, hogy néhány percet szentelünk a VSS hibajelenségeinek.
mi történik, ha az aktív felügyelő meghibásodik?
itt egyszerűen készenléti állapotba kapcsolja a monitort, és ennyi, ha a törött helyreállításakor beállította a preemciót, akkor ismét aktív lesz. Személy szerint nem hiszem, hogy jó ötlet a preemtion felállítása, mert legalábbis nekem tetszik, hogy amikor a dolgok szükség nélkül ingáznak, velem van az előtt, ami történhet. És ha egyenlő kapcsolókat használ, akkor nincs sok értelme, hogy az egyiket részesítsék előnyben, bár láttam, hogy az emberek kapcsolót tettek a preemtion-rel, mert ez a többi dolog bal oldalán található, így talán nem elég okok.
mi történik, ha egy VSL link meghibásodik?
tényleg semmi, riasztást kapunk, megnézzük a portot, a kábelt, és amikor helyreállítjuk a hibát, hogy a normális dolog az lenne, hogy törött SFP volt, megváltoztatjuk és dolgozunk.
mi történik, ha egy nem VSL port meghibásodik?
ugyanaz, mint korábban
mi történik, ha az összes nem VSL Port meghibásodik?
ez azt jelenti, hogy minden port, amely nem a processzor nem, ez a helyzet, amit csak láttam, amikor a kapcsoló belép RPR (Route-processzor redundancia) mód