• partner

  • partner

  • partner

  • Homepage
  • >
  • Blog
  • >
  • De evolutie van netwerk redundantie

Blog

  • De evolutie van netwerk redundantie

    27.12.16 | Door: Telindus

    Al vroeg in de netwerk geschiedenis werd gebruik gemaakt van redundante systemen. In industriële -, militaire - en medische systemen werd gewerkt met twee volledig gescheiden en onafhankelijke paden. Als er één systeem uitviel, dan kon men overstappen naar het andere systeem. Veelal werd de software zo geschreven dat alle data op beide netwerken werd aangeboden. De ontvanger kon kiezen welk netwerk als bron gebruikt moest worden. Redundantie was hier dus ingebouwd in de endpoints. Wat is er sindsdien allemaal veranderd? Dit bespreek ik in mijn blog.

    Netwerk redundantie protocollen
    De eerste LAN- en WAN-netwerken werden enkelvoudig uitgevoerd met statische systemen. Bij een defect in één van de componenten werd deze vervangen. Dit leverde een aanzienlijke downtime op. In het streven naar een hogere beschikbaarheid werd nagedacht over redundante systemen en verbindingen. Echter, dit kan leiden tot dubbele pakketten. Om dit op te lossen werd Spanning Tree Protocol (STP) geïntroduceerd. Het STP werd in veel netwerkapparatuur met name op switches geïmplementeerd. Wanneer het protocol vaststelt dat pakketten meerdere keren naar eenzelfde segment worden gerouteerd, wordt een van de paden naar dat segment afgesloten door de desbetreffende switchpoort te blokkeren voor dataverkeer.

    Eén van de eerste routingprotocollen die werd toegepast voor redundante netwerken was het Routing Information Protocol (RIP). RIP stelt de router in staat om aan de hand van topologie informatie die van de andere routers ontvangen wordt het kortste pad naar de eindbestemming te vinden. Als de topologie wijzigt, dan wordt een ander pad gekozen met de focus op redundantie.

    Op het raakvlak van switching en routing zorgen protocollen als Virtual Router Redundancy Protocol (VRRP) en Hot Standby Router Protocol (HSRP) voor redundantie. Deze protocollen boden een automatische fail-over in enkele seconden maar maakten het netwerk wel een stuk complexer. Ze namen problemen als broadcasts storms, dual-active, en routing loops mee. Zelfs vandaag de dag liggen IT-managers nog wel eens wakker van dit soort problemen.

    Hogere beschikbaarheid
    Een downtime van seconden was nog altijd veel te veel. Dit moest terug gebracht worden naar milliseconden.  STP evolueerde naar veel snellere varianten als Rapid Spanning Tree Protocol (RSTP) en Multiple instance Spanning Tree (MST). RIP maakte plaats voor Open Shortest Path First (OSPF). Timers werden scherper maar ook kritischer. Software en configuraties werden steeds complexer en zo ook fouten in de systemen die steeds meer tijd vergden om ze op te lossen. Software downtime werd langzaamaan een groter issue dan hardware downtime. Hardware vervangen is zo gepiept, maar het uitzoeken van een complexe bug kost soms dagen.

    Gecombineerde chassis in een redundant netwerk
    Alle redundantie werd voorheen geregeld op autonome componenten die met elkaar communiceerden. Deze hadden ieder hun eigen lokale management. Dit maakte het beheer complexer en duurder. Zo ontstond bij fabrikanten een trend om meerdere chassis in één te combineren. De hardware gebruikte vanaf toen uit een gemeenschappelijke software, wat ook gelijk de mogelijkheid bood voor Multichassis Ether-Channel (MEC).

    De systemen om de chassis onderling te synchroniseren namen ook weer nieuwe problemen met zich mee. Veelal moet de softwareversie op beide platformen gelijk zijn en worden ingewikkelde procedures doorlopen om tijdens een upgrade voor continuïteit te zorgen. Als de software crasht, dan gaat vaak alsnog het hele systeem onderuit. Doordat de software omvangrijk is duurt het minimaal enkele minuten voordat alles weer opgestart is. Op gecombineerde chassis zijn vaak veel gebruikers aangesloten, waardoor downtime een grote impact heeft. Veel bedrijven zijn hier inmiddels al huiverig van geworden en zijn daarom voor de core van hun netwerk terug gegaan naar autonome chassis. Dit biedt ze ook weer de mogelijkheid om de chassis individueel van software te voorzien en daarmee eerst op één chassis te controleren of deze stabiel blijft draaien.

    Fabrics
    Doordat de storage zich buiten de servers bevindt, kan in het datacenter een korte onderbreking van het netwerk al fataal zijn. De servers gaan onderuit en het kost veel tijd en moeite om alles weer te herstellen. In moderne datacenters wordt daarom gebruik gemaakt van een Fabric. Hierbinnen vormen alle met elkaar verbonden redundante switches één grote switch. Onderliggend en onzichtbaar voor de gebruiker wordt een routing protocol gebruikt voor transport van frames in zo’n Fabric. Bij uitval van een component wordt de routering, onzichtbaar voor de gebruiker, aangepast zonder dat deze daar invloed op heeft. De controlerende software draait buiten de switches op een apart systeem. Deze methode is flexibel en levert in theorie slechts hele korte onderbrekingen op. Als onderliggend netwerk voor Software Defined networking (SDN) wordt ook een Fabric gebruikt.

    Kortom, op het gebied van netwerk redundantie is veel veranderd. In de eerste systemen werden coaxiale netwerken gebruikt. Later werden deze vervangen door switches. Tegenwoordig wordt nog gebruik gemaakt van dezelfde ethernet technologie, maar dan met moderne netwerkapparatuur. Hoe dit in de praktijk werkt, dat vertel ik in mijn volgende blog.

    Auteur: Kees de Caluwe, Technical Consultant bij Telindus

Meest gelezen op IT Executive

Meest bekeken partnercontent