REDUNDANTIE. 2 april 2006 SNB LIA Gert Bon en Rob Prickaerts

REDUNDANTIE

2 april 2006 SNB LIA Gert Bon en Rob Prickaerts

Inleiding Van alle onderwerpen van de IT, roept een onderwerp als redundantie niet veel vreugde op binnen een organisatie. De extra uitgaven en de complexiteit, boven op een toch al complexe IT omgeving, worden veelal ervaren als een moeilijke en intensieve opgave. De kracht van redundantie is de beschikbaarheid verhogen door het opheffen van een Single Point of Failure (SPoF). Het is echter niet altijd mogelijk om alle onderdelen binnen een organisatie redundant uit te voeren. Twee maal dezelfde componenten, verbindingen en voorzieningen zijn niet alleen extreem kostbaar, maar ook volledig overkill voor 99% van alle organisaties. Toch kan redundantie niet meer worden weg gedacht in de hedendaagse IT systemen. Doordat organisaties steeds afhankelijker worden van de IT voorzieningen binnen de organisaties, moeten de IT systemen een hele hoge beschikbaarheid kunnen leveren. Ondanks de betrouwbaarheid van de apparatuur en software, is het niet meer mogelijk om zonder redundante systemen te werken. Het is dan ook aan de beheersorganisatie om een passende oplossing te vinden. Deze is er in de vorm van redundantie. Al dan niet, alleen op de meest kwetsbare plaatsen. Het is van belang om drempels te vinden in het systeem en alleen daar redundantie toe te passen waar ook strikt noodzakelijk. Vaak kan met het redundant uitvoeren van bepaalde onderdelen van apparatuur of een netwerk, al heel veel bereikt worden. Allereerst moet een analyse worden gedaan binnen de organisatie naar alle bedrijfskritische services. Een duidelijk overzicht van al deze services, kan vervolgens de minimale efficiency en onderlinge afhankelijkheden van iedere dienst en service in kaart brengen. Management zal concrete getallen moeten stellen bij elk van deze services en aan moeten geven welke vormen van beschikbaarheid noodzakelijk zijn voor de business. Nadat er duidelijkheid bestaat over de minimale beschikbaarheid, en de onderlinge afhankelijkheden, kunnen de verschillende services worden geclassificeerd. Binnen alle bedrijven zijn er altijd een aantal services welke altijd aan de top staan met betrekking tot redundantie. Bedrijfsdata, het netwerk, internet toegang en applicatieservers zijn slechts enkele voorbeelden van services waar redundantie op word toegepast. Echter betekend dit niet dat al deze onderdelen volledig in tweevoud worden uitgevoerd. De florerende tijd van de IT sector, is reeds enkele jaren voorbij. De onbeperkte bron van geld en de vrijheid van de beheersorganisatie met betrekking tot aankopen en implementaties van nieuwe technologieën, is veelal een Utopia waar de meeste organisaties al lang niet meer op lijken. Tegenwoordig moeten alle keuzes verantwoord worden naar de organisatie, en zijn budgetten klein tot misschien wel helemaal niet aanwezig. Het is dan ook daarom dat redundantie alleen daar moet worden toegepast waar er een duidelijke noodzaak voor bestaat. Dit betekend dat slechts Redundantie

1

bepaalde onderdelen binnen een service redundant worden uitgevoerd en andere juist niet. Op die manier probeert een organisatie de gewenste minimale beschikbaarheid te kunnen behalen. Minimaal kan gelijk zijn aan de reeds aanwezige beschikbaarheid maar kan ook zeer zeker een mindere mate van beschikbaarheid beteken. Misschien zelfs geen beschikbaarheid, en alleen een melding dat een dienst buiten werking is. Hoe dan ook moet de vorm van redundantie moet ten alle tijden passen in het business model van de organisatie. Naast de financiële implicaties welke redundantie met zich mee brengt, moet er ook worden nagedacht over de technische gevolgen. Redundantie kan voorkomen in veel soorten en maten. Direct aanwezig in het systeem, of als non actieve backup. Hoe dan ook, er moet duidelijk worden gekeken naar de technische gevolgen van redundante oplossingen. Het beheer van, gebruik maken van en het configureren van redundante systemen kan een moeizame en zware opgave zijn. Redundantie kan meer problemen binnen een organisatie veroorzaken dan oplossen. Daarom is het van belang, altijd goed na te denken over het gebruik maken van redundantie!

Redundantie

2

ABSTRACT

4

1

6

1.1 1.2 2.3 2.4 2 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 3

NETWERK REDUNDANTIE HET NETWERK LINK REDUNDANTIE DEVICE REDUNDANTIE NETWERKEN EXTERN SERVICES REDUNDANTIE MULTIPATH I/O CLUSTERING LOAD BALANCING HOT SPARE HOT SWAP SLB PROTOCOL GLBP PROTOCOL REDUNDANT ARRAY OF INDEPENDENT DISKS BRONVERMELDING

Redundantie

6 11 15 23 27 27 28 31 31 32 34 35 37 47

3

Abstract Voor het inbouwen van redundantie in componenten en systemen zijn er tal van technische (hardware) oplossingen mogelijk. Welke allen moeten voorkomen dat een Single Point of Failure de beschikbaarheid van een service in gevaar brengt. Redundantie lijkt op het eerste gezicht de oplossing voor alle problemen binnen een IT organisatie. Echter brengt redundantie veel meer met zich mee dan een hogere beschikbaarheid. Wanneer verkeerd geïmplementeerd dan blijkt zelfs die hogere beschikbaarheid nog ver te zoeken. In redundantie schuilen vele gevaren, welke eenvoudig over het hoofd gezien kunnen worden. Het is dan ook daarom, dat redundantie alleen daar moet worden toegepast waar strikt noodzakelijk. Redundantie staat niet gelijk aan twee identieke situaties, aan elkaar gekoppeld om elkaars functies over te nemen. Redundantie betekend niets meer dan het ondervangen van een Single Point of Failure tot een acceptabele niveau. Dit kan een gelijk niveau zijn, maar dit kan ook terdege een asymmetrische redundantie zijn, waarbij de noodoplossing slechts in een beperkte beschikbaarheid resulteert. Binnen een organisatie zijn er vele diensten en services actief en een van de aller belangrijkste daarin is het netwerk. Alle ander diensten en services maken op een of andere manier gebruik hiervan. En het is dan ook daarom dat redundantie binnen het netwerk design van enorm belang is. Om een goed netwerk design te kunnen realiseren, zal het netwerk moeten worden opgedeeld in kleinere stukken. Een veel gebruikte methode hiervoor is werken volgens de Cisco Composite Network model. Deze methode zorgt dat alle belangrijke onderdelen van het netwerk apart te benaderen zijn en op deze manier ook eenvoudig te dupliceren. Dit maakt een netwerk overzichtelijk en schaalbaar. Netwerk redundantie doorkruist het hele ontwerp, van link redundatie middels Etherchannels, tot device redundantie met virtuele routers. Multihoming en Out-of-Band management zijn nog enkele andere varianten van Netwerk redundantie. Al deze technieken gecombineerd, kunnen ervoor zorgen dat het netwerk beschikbaar blijft. Wanneer het netwerk stabiel is en alle cruciale punten redundant zijn uitgevoerd, kan er gekeken worden naar de bovenliggende services. De bovenliggende services zijn meestal afhankelijk van servers. Op dit niveau zijn er vele technieken om redundantie op toe te passen. Deze verschillen van redundantie binnen de hardware, tot protocollen om volledige servers aan elkaar te koppelen. Een mogelijke techniek om redundante datakanalen te realiseren is Multipath I/O wat bijvoorbeeld in de Space Shuttle's is gebruikt. Naast redundante datakanalen kunnen services ook ondersteund worden door het koppelen van meerdere systemen. Hierbij gaat het om het gebruik van clusters waarbij een groep computers een bepaalde dienst leveren. Dit Redundantie

4

kan bijvoorbeeld een website zijn waarbij de klant de website transparant getoond wordt maar waarbij meerdere computers betrokken zijn voor de afhandeling van de interactie met de bezoeker. Voor het verwisselen van apparatuur in redundante systemen, welke ten alle tijden dienen te draaien, zijn technieken als Hot Spare en Hot Swap beschikbaar. Hierbij kunnen actieve componenten worden vervangen, zonder dat de host machine down hoeft te gaan. Deze onderwerpen zijn nauw verweven met bijvoorbeeld harddisks in RAID systemen, redundant uitgevoerde harde schijf configuraties welke voor redundantie en extra snelheid kunnen zorgen. Op netwerk niveau is het Gateway Load Balancing Protocol en Server Load Balancing een van de protocollen welke aan bod komen voor redundante netwerk toepassingen. Deze services zorgen ervoor dat een locatie via meerdere wegen bereikbaar blijft en zijn erg afhankelijk van het netwerk. Redundantie is al met al een noodzakelijk kwaad, gezien de hoge eisen welke heden ten dagen aan een IT omgeving worden gesteld. Het bedenken, ontwerpen en implementeren van redundante systemen lijkt eenvoudiger dan het is en op veel plaatsen wordt hinder ondervonden door slecht uitgevoerde oplossingen. Daarom is het van belang te bepalen waar de belangrijkste afhankelijkheden zijn voor de organisatie. Redundantie moet, net als alle andere maatregelen, de organisatie ondersteunen.

Redundantie

5

1

Netwerk Redundantie

Van alle services binnen een organisatie, is het netwerk een van de meest cruciale services aanwezig. Het is bijna ondenkbaar voor een organisatie om bijvoorbeeld geen gebruik te kunnen maken van services als het Internet, Email, of NTP. Ook services als netwerkapplicaties, LDAP of andere database storages zijn tegenwoordig niet meer weg te denken. Al deze services zijn afhankelijk van de beschikbaarheid van het netwerk, of een deel daarvan. Het is daarom belangrijk om het netwerk op te delen in verschillende onderdelen. De volgende secties zullen dieper ingaan op de verschillende netwerk onderdelen en de verschillende vormen van netwerk redundantie. Daarnaast worden enkele problemen besproken welke voorkomen bij de verschillende vormen van netwerk redundantie.

1.1

Het netwerk

Het netwerk kan onderverdeeld worden in een aantal verschillende onderdelen. Een veel gebruikte vorm voor het opsplitsen van de verschillende netwerkonderdelen is het Enterprise Composite netwerkmodel zoals Cisco dit hanteert. Het zorgt voor een overzichtelijke scheiding van alle belangrijke netwerkonderdelen. De doelen van het Enterprise Composite Network Model zijn: • Het ontwikkelen van een netwerk met duidelijk aangegeven grenzen tussen de modules. Het model heeft duidelijke afbakeningen. Een netwerk designer weet precies welke verkeer wel en niet toegestaan is door deze afbakeningen en kan dit verkeer gemakkelijker filteren. • Vergemakkelijken van het designproces en verbeterde schaalbaarheid van een netwerk. Er kan nu ook gebruik worden gemaakt van de “divide and conquer” methode voor het oplossen van problemen, omdat de problemen meestal terug te voeren zijn tot een bepaalde module. • Vereenvoudigde schaalbaarheid. Een gebouw toevoegen aan de Campus, een remote locatie aan de WAN module toevoegen of servers aan de Server Farm toevoegen is een heel eenvoudige taak. Het model is opgebouwd uit de volgende 3 modules: Enterprise Campus, Enterprise Edge en Service Provider Edge.

Figuur 1.1 ‘The Enterprise Composite Network Model’

Redundantie

6

Deze modules worden vervolgens nog verder onderverdeeld: • Enterprise Campus: deze module bevat alle netwerkelementen, die afhankelijk van elkaar functioneren binnen één locatie. Er zijn geen externe verbindingen of internet toegang. • Enterprise Edge: deze module is belast met het filteren van verkeer afkomstig van de Service Provider Edge modules en routers, bestemt voor de Enterprise Campus. In de Enterprise Edge zijn alle netwerkelementen ondergebracht die bijdragen tot efficiënte en beveiligde communicatie tussen de Enterprise Campus en externe locaties, business partners, mobiele gebruikers en het internet. • Service Provider Edge: deze module wordt meestal niet geïmplementeerd door de organisatie zelf, maar is wel noodzakelijk voor de communicatie met andere netwerken. Vaak worden in deze module verschillende WAN-technologieën en verschillende ISP’s gebruikt.

Enterprise Campus Module De Enterprise Campus module is vervolgens weer verder onderverdeeld in een viertal submodules, namelijk: 1. Campus Infrastructure module • Building Access • Building Distribution • Campus Backbone 2. Network Management module 3. Server Farm module 4. Edge Distribution module

Figuur 1.2 ‘The Enterprise Campus Module’ The Campus Infrastructure Module is opgebouwd uit de submodules Building Access, Building Distribution en Campus Backbone.

Redundantie

7

Building Access De Building Access module bevat de werkstations van de eindgebruikers, IP telefoons, netwerk printers en OSI-layer 2 Access switches voor het verbinden van de verschillende netwerkelementen met de Building Distribution module. De Building Access module zorgt voor belangrijke services, zoals broadcast onderdrukking, protocol filtering, netwerk toegang en het markeren van Quality of Service. Building Distribution De Building Distribution zorgt voor het samenvoegen van de Building Access netwerken, door gebruikt te maken van OSI-layer 3 switching. De Building Distribution module zorgt voor routing, QoS en Access control. Als iemand van de Building Access bepaalde data opvraagt, dan gaat deze request door de Building Distribution naar de Campus Backbone. Campus Backbone De Campus Backbone zorgt voor een snelle verbinding tussen de verschillende locaties en tussen de Server Farm en Edge Distribution modules. In de Backbone moet het verkeer zo snel mogelijk gerouteerd en geswitched worden tussen de verschillende modules. In de Campus Backbone kunnen OSI-layer 2 en 3 switches zitten, die zorgen voor de snelle doorvoermogelijkheden en de daarbij toegevoegde routing, Quality of Service en security eigenschappen.

Network Management Een ander onderdeel van de Enterprise Campus is de Network Management module. Deze module zorgt voor de intrusion detection, system logging en authenticatie. Verder zorgt deze module voor het monitoren van het netwerk en voor het algemene configuratiemanagement. Voor deze configuratie doeleinden is het aanbevolen dat er een connectie, vanuit een netwerk waar geen productie plaatsheeft, aanwezig is naar alle andere netwerk componenten. De Network Management module zorgt voor het configuratiemanagement van bijna alle apparatuur binnen het netwerk met behulp van routers en dedicated network management werkstations. Hiervoor is dan een applicatie benodigd, zoals bijvoorbeeld een Cisco Works of een HP OpenView.

Server Farm In de Server Farm worden alle interne e-mail en bedrijfsservers, die services aanbieden voor de interne users, ondergebracht. Bij deze services kunnen de volgende zaken zijn inbegrepen: applicatie, file, print, e-mail en Domain Name System (DNS) en LDAP services. Om dat de toegang tot deze servers voor het bedrijf van vitaal belang is, worden de servers verbonden met 2 switches. Op deze manier is er volledige redundantie en kan er gebruik worden gemaakt van load-sharing. De Server Farm switches zijn op hun beurt weer redundant verbonden met de switches uit de Core (Campus Backbone). Dit zorgt voor een hoge betrouwbaarheid en beschikbaarheid van alle servers in de Server Farm.

Redundantie

8

Edge Distribution De laatste module die nog bij de Enterprise Campus is inbegrepen, is de Edge Distribution module. Deze voegt de verschillende modules van de Enterprise Edge samen en routeert dit verkeer naar de Campus Backbone. De Edge Distribution is op dezelfde manier opgebouwd als de Building Distribution module. Ook de Edge Distribution gebruikt ACL’s (access control lists) om het verkeer te filteren, hoewel bij de Edge Distribution nog extra beveiliging is ingebouwd, omdat een gedeelte van het verkeer afkomstig is van de buitenwereld.

Enterprise Edge Naast de Enterprise Campus bevat het Enterprise Composite Model ook een Enterprise Edge module. De Enterprise Edge module is opgebouwd uit de volgende submodules: • E-commerce • Internet Connectivity • Remote Access en VPN • WAN

Figuur 1.3 ‘The Enterprise Edge’ E-commerce De E-commerce module zorgt ervoor dat de organisatie gebruik kan maken van E-commerce applicaties en dat op die manier een concurrentie voordeel kan worden behaald ten opzichte van andere organisatie met behulp van het internet. Internet Connectivity Gebruikers van het internet maken via de Internet Connectivity module verbinding met de publieke servers van de organisatie. Ook wordt via de Internet Connectivity module Virtual Private Network (VPN) verkeer doorgelaten richting de Remote Access en VPN module, die hierna besproken zal worden. Dit VPN verkeer is afkomstige van externe gebruikers of externe locaties Redundantie

9

Remote Access en VPN Zorgt voor het VPN verkeer, afkomstig van de Internet Connectivity module, van de externe locaties en gebruikers. Deze module kan zowel VPN verkeer beëindigen alsook initiëren. In deze module komen ook de gebruikers binnen, die inbellen via een analoog netwerk, het zogenaamde Public Switched Telephone Network (PSTN). Nadat deze gebruikers zijn geauthentificeerd, worden ze toegelaten tot het interne netwerk. WAN De laatste submodule van de Enterprise Edge is de WAN module. De WAN modules routeert het verkeer tussen de externe locaties en het interne netwerk. In de WAN module zijn alle gehuurde, optische, kabel, Digital Subscriber Lines (DSL) en draadloze verbindingen ondergebracht. Ook zijn hier de data link protocollen, Frame Relay, ATM en PPP ondergebracht. Implementatie Hieronder zien we een voorbeeld van een netwerk welk is ingedeeld volgens het Enterprise Composite Network model. Dit standaard netwerk is volledig operationeel zoals weergegeven, echter zit er nog geen enkele vorm van redundantie in verwerkt.

Figuur 1.4 ‘Netwerk design basis’

Redundantie

10

1.2

Link redundantie

De meest eenvoudige manier van netwerk redundantie is link redundantie. Door een link te vervangen door een twee links wordt de kans kleiner dat onderdelen van het netwerk niet meer bereikbaar zijn. Echter zou het dubbel uitvoeren van alle links in een netwerk een enorme kostenpost met zich mee brengen. Niet alleen zouden de kosten voor bekabeling verdubbelen, maar ook het aantal switchpoorten, walloutlets, patchpunten, netwerkkaarten en router interfaces zouden verdubbelen. Dit zou daarmee ook de kosten voor de apparatuur drastisch omhoog halen. Daarom is het van belang te bepalen waar in een netwerk een dubbele link voordelen biedt, en waar niet. Wanneer? In de Building Access is er niet overal een noodzaak link redundantie aan te brengen. Een link naar de werkplek is erg belangrijk voor de eindgebruiker, maar een organisatie komt niet stil te liggen wanneer een eindgebruiker tijdelijk geen verbinding kan maken met het netwerk en de daarvan afhankelijke services. De reden waarom er op de meeste werkplekken toch meerdere aansluitingen beschikbaar zijn, komt doordat er tijdens het aanleggen van het netwerk rekening gehouden is met eventuele groei. Een link tussen Building Access en Building Distribution, of de koppeling daarvan met de bijvoorbeeld de Campus Backbone daarentegen, zijn van een veel groter belang. Bij het uitvallen van een dergelijke link, zijn veel meer eindgebruikers en andere services gemoeid dan bij een link naar de desktop. Daarom zien we dan ook dat dergelijke koppelingen redundant worden uitgevoerd. Ook de aanwezige servers in de ServerFarm moeten redundant worden gekoppeld aan het netwerk. Servers worden benaderd door een grote groep gebruikers. Veel services zijn afhankelijk van de fysieke servers waarop ze draaien. Daarom is de ServerFarm Distribution een cruciaal koppelpunt van het hele netwerk. De koppeling naar de Campus Backbone moet dubbel worden uitgevoerd. Ondanks de redundantie die in een server kan worden ingebouwd, is het verstandig om ook de koppeling met het netwerk van de servers ten alle tijden redundant uit te voeren. Dit kan eenvoudig door het plaatsen van een tweede netwerkkaart. Etherchannels Redundantie kan worden gebruikt om de beschikbaarheid te verhogen, echter is het volkomen onzinnig om een tweede link in het netwerk te plaatsen, en deze vervolgens niet gebruiken. Door beide links te gebruiken, kunnen hogere snelheden worden behaald, of kunnen bepaalde services beter worden bedient over een aparte link. het verkeer spreiden over het netwerk om zo de links en de aangesloten devices te ontzien van een te hoge load. Wanneer men dit echter toepast, moet er wel rekening gehouden worden met de maximale belasting van een enkele link. Zodat, wanneer een van de beide links uit valt, de andere link niet overbelast raakt en ook faalt.

Redundantie

11

Een goed voorbeeld van link redundantie welke tevens een hogere bandbreedte oplevert, is de 802.3ad Link Aggregation standaard van IEEE. Echter is het niet gelukt om deze standaard te bemachtigen vanwege de daaraan verbonden kosten. Hieronder volgt een omschrijving van Etherchannel zoals Cisco deze heeft opgezet. Foundry gebruikt nagenoeg dezelfde vorm van Etherchannel en beide zijn gebaseerd op dezelfde principes. Een Etherchannel voorziet in een eenvoudige en relatief goedkope manier om groei op te vangen in een netwerk en tevens een extra vorm van redundantie aan het netwerk toe te voegen. Het is niet noodzakelijk om nieuwe apparatuur te kopen om gebruik te kunnen maken van Etherchannels. Meerdere actieve parallelle links op een switch zorgen normaal gesproken voor bridging loops. Door middel van Etherchannel voorkom je dit door het bundelen van meerdere fysieke parallelle links naar een logische link, die te gebruiken is als access link of trunk link. Het is wel vereist voor beide switches, of andere netwerkcomponenten, aan de beide uiteinden van de Eterchannel dat deze zijn geconfigureerd voor Etherchannel. Ondanks het feit dat een Etherchannel Link wordt gezien als één logische link, zal deze link desalniettemin niet de totale bandbreedte overnemen die gelijk is aan de som van de bandbreedten van de fysieke links. Bijvoorbeeld, stel je hebt een FEC link van 4 full-duplex, 100 Mbps Fast Eternet links. Ondanks dat het mogelijk is voor de FEC link om een throughput te leveren van 800Mbps, zal de FEC niet werken op deze snelheid. In plaats daarvan, zal het verkeer worden gespreid door middel van load-balancing, over de individuele fysieke links. Ieder van deze links werkt op een snelheid van 200 Mbps full-duplex, maar draagt alleen de frames die door de Etherchannel hardware op de link worden geplaatst. Etherchannel biedt redundantie door deze verschillende gebundelde links. Wanneer een van de links in de bundel niet werkt, zal het verkeer worden omgeleid via een naastliggende link. Failover vindt plaats in minder dan een paar milliseconden en is niet merkbaar voor de eindgebruiker. Wanneer er meerdere links down gaan, zal de data verder worden verschoven naar andere links. Terug redenerend, wanneer links worden hersteld, zal het verkeer weer worden verdeeld over de actieve links. Etherchannels kunnen alleen worden opgebouwd uit dezelfde ethernet type en snelheden. Data over een Etherchannel wordt gedistribueerd over de individuele gebundelde links op een weloverwogen wijze. Desondanks wordt de data niet evenredig verdeeld over alle links, maar zullen frames op specifieke links worden geplaatst aan de hand van een special hashing algoritme. Dit algoritme maakt gebruik van het source IP adres, destination IP adres, een combinatie van source en destination IP adres, source IP en MAC adres, of TCP/UDP poortnummers. Het algoritme creëert een binair patroon welke een link nummer in de bundel zal selecteren.

Redundantie

12

Wanneer slechts één adres of poortnummer wordt gehashed, zal de switch ieder frame forwarden door een of meer low-order bits van de hash waarde als een index naar de gebundelde links te gebruiken. Als twee adressen of poortnummers worden gehashed, zal een switch een XOR uitvoeren op een of meer van de low-order bits van de adressen of TCP/UDP poortnummers, en deze als een index naar de gebundelde links te gebruiken. Bijvoorbeeld, een Etherchannel bestaande uit 2 gebundelde links vereist een one-bit index. Of wel de lowest order adres bit of de XOR van het laatste bit van het adres in het frame wordt gebruikt. Een 4 link bundel gebruikt een hash van de laatste twee bits. Vergelijkbaar, een 8 link bundel gebruikt een hash van de laatste 3 bits. De uitkomst van deze gehashte bits selecteert de juiste Etherchannel link. De tabel op de volgende bladzijde laat de resultaten zien van een XOR op een 2 link bundel, gebruik makend van het source en destination IP adres. Binair adres Addr1: …xxxxxxx0 Addr2: …xxxxxxx0 Addr1: …xxxxxxx0 Addr2: …xxxxxxx1 Addr1: …xxxxxxx1 Addr2: …xxxxxxx0 Addr1: …xxxxxxx1 Addr2: …xxxxxxx1

2-link Etherchannel XOR en Link nummer …xxxxxxx0: gebruik link 0 …xxxxxxx1: gebruik link 1 …xxxxxxx1: gebruik link 1 …xxxxxxx0: gebruik link 0

De XOR wordt onafhankelijk uitgevoerd op iedere bit positie in de adres waarde. Als de twee adres waardes dezelfde bit waarde hebben, zal de XOR uitkomst 0 zijn. Als de twee adres bits anders zijn, wordt de XOR uitkomst 1. Op deze wijze kunnen frames statistisch gezien verdeeld worden onder de links met de veronderstelling dat de MAC en IP adressen statistisch gezien verdeeld zijn over het netwerk. In een 4 link bundel wordt de XOR uitgevoerd op de 2 lower bits van de adres waarde welke resulteert in een, 2-bit XOR waarde (ieder bit wordt apart gecreëerd), of een link nummer van 0 tot 3.

Bundel 2-link 4-link 8-link

A1: … xxxxx000 A2: … xxxxx000 (Dezelfde Adres bits) Link index 0 (0) (laagste) Link index 00 (0) (laagste) Link index 000 (0) (laagste)

A1: … xxxxx000 A2: … xxxxx111 (Verschillende Adres bits) Link index 1 (1) (hoogste) Link index 11 (3) (Hoogste) Link index 111 (7) (Hoogste)

Als voorbeeld, neem een packet dat wordt verzonden van IP adres 192.168.1.1 naar 172.31.67.46. Omdat Etherchannels kunnen worden opgebouwd van 2 tot 8 individuele links, hoeven alleen de 3 meest rechtse (minst belangrijke) bits worden gebruikt als link index. Deze bits zijn respectievelijk 001 (1) en 110 (6). Voor een 2 link bundel zal een one-bit XOR worden uitgevoerd op de meest rechtse adres bit: 1 XOR 0 = 1, welke resulteert in het gebruik van link 1. In een 4 link Etherchannel produceert een two-bit XOR: 01 XOR 10 = 11, welke resulteert in het gebruik van link 3 in de Redundantie

13

bundel. Als laatste zal er in een 8 link bundel een drie bit XOR worden uitgevoerd. 001 XOR 110 = 111, welke resulteert in het gebruik van link 7. Een conversatie tussen twee apparaten zal altijd plaatsvinden over dezelfde links, omdat de eind IP adressen hetzelfde blijven. Echter wanneer een apparaat met verschillende andere apparaten zal communiceren, is de kans groot dat de eind IP adressen even en oneven waarden zullen hebben en zal dit resulteren in een andere XOR waarde en hierdoor een andere link. Implementatie Figuur 1.5 laat duidelijk zien welke links redundant kunnen worden uitgevoerd binnen een netwerk. Alle koppelingen tussen de Backbone en de Distribution laag, redundant zijn uitgevoerd om connectiviteit te behouden tussen alle belangrijke componenten. Alle servers hebben een redundante verbinding gekregen met de ServerFarm Distribution. Servers zijn vele malen belangrijker, omdat grote groepen van eindgebruikers van een enkel systeem gebruik maken. Als laatste zien we dat er is gekozen voor een FEC oplossing tussen de Building Access en de Building Distribution om hogere snelheden te kunnen realiseren met goedkopere UTP oplossingen met een beperkte vorm van redundantie doormiddel van de meerdere fysieke links.

Figuur 1.5 ‘Netwerk Design met link redundantie’ Redundantie

14

2.3

Device Redundantie

Naast link redundantie kan er op netwerk niveau ook gekeken worden naar Device redundantie. Het vervangen van een link verdubbeld weliswaar de beschikbaarheid van de fysieke link, echter wanneer een van de aangesloten devices van de links uitvalt, is er nog altijd geen verbinding mogelijk. De kans dat een interface uitvalt is natuurlijk vele malen groter, dan de kans dat een volledig device uitvalt. Op cruciale punten binnen het netwerk is het toch van belang om deze vorm van redundantie toe te voegen. Device redundantie kan op meerder manieren worden toegepast. Zo kan actief een extra device mee draaien binnen het netwerk. Volledig ingericht met vergelijkbare capaciteiten als het hoofd device, maar kan het ook voorkomen dat er van de aanwezige apparatuur een apparaat, voor geconfigureerd, op de plank staat. Deze kan dan worden ingezet op het moment dat een actief component uitvalt. Passieve device redundantie Deze vorm van redundantie resulteert in korte downtime, echter het grote voordeel hiervan is dat, wanneer er meerdere dezelfde apparaten in het netwerk draaien, deze spare op meerdere plaatsen kan worden ingezet en daarmee de kosten van redundantie flink kan verlagen. Het enige dat verandert hoeft te worden zijn de configuratie files op de spare. Doordat veel kosten worden bespaard, moet genoegen worden genomen met een lagere beschikbaarheid door de beperkte downtime bij het omwisselen van de spare met het actieve device. Deze vorm van redundantie kan goed worden toegepast op de Building Access. Wanneer een netwerk modulair is opgebouwd, zijn alle switches binnen de Building Access van vergelijkbaar niveau. Zeker wanneer er standaardisatie is uitgevoerd op de apparatuur. Door de minder grote impact op de organisatie kan een Access switch best 5 minuten down gaan, zonder dat dit catastrofale gevolgen heeft voor het bedrijfsproces. Het zijn alleen maar enkele eindgebruikers welke offline gaan, en geen belangrijke services. Natuurlijk is dit volledig afhankelijk van de organisatie. Een helpdesk kan bijvoorbeeld niet onbereikbaar zijn, en zal daarom ook een actieve vorm van redundantie prefereren. Actieve device redundantie Actieve redundantie kan op vele manieren worden toegepast. Veelal worden in grote netwerken de multi-layer switches in de Campus Backbone en alle Distribution switches door het hele netwerk actief redundant uitgevoerd. Dit is noodzakelijk vanwege de grote impact op de organisatie in het geval van uitval. Door het hele netwerk komen er kruiskoppeling tussen alle belangrijke componenten. Het grote voordeel van deze vorm van redundantie is dat gebruik kan worden gemaakt van de extra switching power and bandbreedte van de extra switch zolang beide systemen volledig functioneren. Deze extra bandbreedte en switching capaciteit zijn zeker erg nuttig voor de Backbone. Echter moet er wel rekening worden gehouden met de maximale belasting van de Redundantie

15

apparatuur. Een enkele switch moet eenvoudig alle load van het netwerk kunnen dragen. Het mag namelijk niet zo zijn dat wanneer een van de switches uitvalt, de ander switch volloopt en ook uitvalt. Dit zou een enorm probleem opleveren voor de organisatie. Onderhoud Bij zowel actieve alsook passieve redundantie, kan een organisatie zijn voordeel opdoen wanneer er onderhoud moet worden gedaan. Doordat devices uitval kunnen opvangen, zal onderhoud minder problemen en risico’s met zich mee brengen. Er zijn altijd risico’s verbonden aan onderhoud, maar op het moment dat een netwerk nog kan blijven functioneren bij onderhoud, maakt het werk vele malen eenvoudiger. Echter moet onderhoud ten alle tijden worden gepland op low-impact momenten, bijvoorbeeld ’s nachts of in het weekend. Ook bij redundante opstellingen kan het voorkomen dat functionaliteit komt te vervallen of zelfs volledig weg valt in tijden van onderhoud. Dit komt omdat er op het moment van onderhoud, misschien geen redundantie meer in plaats is of alleen nog maar passieve redundantie in plaats van actieve redundantie. Bij actieve redundantie kan in korte tijd het netwerk onder handen worden genomen. Eerst wordt de eerste helft van de redundante devices down gebracht, gepatched, geupdate of opnieuw geconfigureerd. Wanneer deze onderdelen wederom actief in het netwerk mee draaien, worden de resterende devices onder handen worden genomen. Dit is een maximale belasting van de redundante omgeving, en het wordt dan ook aangeraden om dit in meer dan twee fases uit te voeren, om de risico’s en impact te minimaliseren Bij passieve redundantie kan ervoor gekozen worden om een actief apparaat te vervangen door de reeds aangepaste spare, en de devices een voor een uit de opstelling te rouleren om zo alle onderdelen te kunnen onderhouden. Er moet rekening worden gehouden met de risico’s van het inzetten van de spare. Op dit moment is er geen volledig functionerende spare aanwezig en is de redundantie gecompromitteerd. Wederom, plan onderhoud op low-impact tijden. Deze manier van onderhoud kan ook worden toegepast bij actieve redundantie, wanneer er ook hier een spare aanwezig is. Dit zou de risico’s nog verder minimaliseren. Switch redundantie Door het hele netwerk worden er vele multi-layer switches ingezet zodat naast het normale switchen van het verkeer, bijvoorbeeld ook Quality of Service (QoS) kan worden toegepast en routing capaciteiten kunnen worden benut om het verkeer in de distribution layer zo effectief mogelijk te kunnen afhandelen. Dankzij deze intelligente switches is het mogelijk om naast het redundant uitvoeren van de switches ook Load Balancing toe te passen. Zowel de Campus Backbone, alsook alle Distribution switches zijn redundant uit te voeren. Dankzij deze redundantie, heeft een Building Access switch ten alle tijden een tweede pad naar de Distribution laag. Hiertussen zal spanning tree voorkomen dat er loops ontstaan. Door het spanning tree protocol te Redundantie

16

beïnvloeden op de Distribution Layer kan er vrij eenvoudig een scheiding worden aangebracht tussen het verkeer van de verschillende VLAN’s van de Building Access switches. Op de Distribution switches kan er eenvoudig load balancing worden toegepast op de trunks naar de beide Campus Backbone switches. Deze switches zijn niet bedoelt om QoS of routing functies uit te voeren, maar om met hoge snelheden, massa’s data te switchen. Om deze functies goed uit te kunnen voeren is het van groot belang dat alle intelligentie op de Distribution layer plaatsvindt. Router redundantie Voor belangrijke koppelingen naar externe netwerken, kunnen routers redundant worden uitgevoerd om zo geen single point of failure te veroorzaken. Voor router redundancy maakt men gebruik van virtual routers. Dit is zijn twee of meer fysieke routers, welke logisch gekoppeld zijn aan een virtueel IP adres. Een router zal als ‘standby’ fungeren voor de ‘master’ router. De clients spreken niet met een fysiek IP adres, maar het virtueel IP adres van de groep. Op het moment dat de ‘master’ router uitvalt, zal binnen enkele seconden de ‘standby’ router de rol van zijn master overnemen en kan het verkeer gewoon verder stromen. Een client merkt hier nagenoeg niets van. Er zijn een aantal verschillende router redundancy protocollen beschikbaar, afhankelijk van het merk van de apparatuur. De meeste van deze protocollen zijn helaas proprietary. Zo is er het Hot Standby Routing Protocol (HSRP) van Cisco, het Foundry Standby Routing Protocol (FSRP) van Foundry en het IP Standby (IPSTB) protocol van DEC alleen bruikbaar op deze platvormen. HSRP, ondanks dat het een proprietary protocol is, vind veel ondersteuning vanuit de IT wereld. Het is iets uitgebreider dan alle andere protocollen en geeft de gebruiker meer vrijheid bij het configureren van de virtual routing groups. Echter het is een proprietary product en hierdoor heeft Cisco een enorme markt laten liggen. Door het succes van HSRP mede alsook IPSTB, ontstond er de behoefte naar een standaard, die is er gekomen in het Virtual Router Redundancy Protocol VRRP, RFC 2338. Virtual Router Redundancy Protocol Het Virtual Router Redundancy Protocol kan doormiddel van de standby / master opstelling ten alle tijden een router actief laten routeren. De enige downtime welke overbrugt moet, zijn de een á twee seconden welke het duurt alvorens de standby router begrepen heeft dat de master is komen te vervallen, en de Master functie overneemt. Wanneer een Virtual Routing group is gedefinieerd vind er een electie procedure plaats binnen het Virtual Routing Protocol. Alle communicatie tussen de routers in de routing group gaan naar het Virtual Router multicast adres 224.0.0.18. Alle routers binnen een zelfde routing group zullen tijdens de electie periode een master router kiezen, en vervolgens hun rol van master of standby aannemen. Een virtuele router bestaat altijd uit twee of meer routers. Redundantie

17

Figuur 1.6 ‘Virtuele Router met VRRP’ Figuur 1.6 laat twee routers zien welke zijn geconfigureerd in een Virtual Routing Group met VRID 1. Een van de routers heeft duidelijk de rol van master aangenomen, en zal al het verkeer bestemd voor de virtuele router afhandelen. Tevens zal de master router op 224.0.0.18 naar de standby router in laten weten dat deze nog steeds actief is. VRRP maakt gebruikt van de volgende attributen: • VRID: De Virtual Router Identifier geeft het nummer aan van de Virtual Router group waarvan de router lid is. Dit kan een waarde zijn tussen de 1 en de 255. Er bestaat geen default waarde. • Priority: Het priority veld wordt gebruikt door VRRP om tijdens de router electie procedure te bepalen welke router Master wordt. De priority waarde van 255 is gereserveerd voor de router welke de eigenaar is van het IP adres van de virtuele router. De waarde van 0 is gereserveerd voor een actieve master van een virtual router om aan te geven dat deze de verantwoordelijkheid van master wil afstaan.de range van 1-254 is beschikbaar voor VRRP routers welke niet master zijn, en niet eigenaar van het IP adres van de virtuele router. De default waarde is 100. • IP_addresses: Een of meer IP adressen welke worden geassocieerd met de virtual router. Er is geen default. • Adver_interval: tijd interval tussen advertisements. De default is 1 sec. • Skew_time: tijd tussen het overnemen van de master functie door de backup na het verlopen van de Master_down_int( (256 – priority)/256 ) • Master_down_interval: tijdinterval voordat de backup de master als down beschouwd ( (3 x Advertisement_interval) + skew_time ) • Preempt_mode: Een router met een hogere priority kan master functie overnemen, van een actieve master op het moment dat de waarde van deze flag op true staat. Default staat deze altijd op true. Ongeacht de waarde van deze flag, zal de router welke eigenaar is van het IP adres tem alle tijden de master functie overnemen wanneer deze functioneel is. Redundantie

18

Virtuele routers met VRRP kunnen drie states aannemen, Initialize, Master of Backup. Initieel staan alle routers van de routing group in de Initialize state. In deze state zal de router VRRP berichten multicasten naar 224.0.0.18 en verder wachten tot er een startup event getriggered wordt. Dit kan gebeuren doordat de router een VVRP pakket ontvangt welk is bestemd voor de routing group waar deze deel van uitmaakt. Op dat moment gaat de router het ontvangen pakket bekijken en zal de electie procedure beginnen. De router met priority 255, of te wel de eigenaar van het virtueel IP adres, zal de Master state aannemen. Alle andere routers waarmee gecommuniceerd wordt, zullen Backup state aannemen. Een router in Master state heeft een aantal verantwoordelijkheden. Allereerst moet de master router moet alle ARP request welke aan het virtueel IP adres zijn gericht afhandelen. Daarnaast moet deze alle pakketten welke aan het MAC adres, het virtueel IP adres of een van de IP adressen op zijn eigen fysieke interfaces is gericht afhandelen. De Master moet echter geen verkeer afhandelen dat aan fysieke interfaces van andere routers in de routing group is geadresseerd. Een router in Backup state moet allereerst opletten of de Master router nog steeds periodiek updates verstuurd. Wanneer de Master_down_timer hoger is dan de Master_down_interval ( (3 x Advertisement_interval) + skew_time ) dan moet de Backup Router met de hoogste priority de Master state overnemen. Daarnaast moet een Backup router de Master state aannemen wanneer de Master een update verstuurd met Priority 0. Dit betekend dat deze (gepland) down zal gaan en zijn rol van Master wil afstaan. Een Backup Router mag geen aan het virtueel IP adres gerichte ARP request afhandelen. Pakketten gericht aan het MAC adres, alsook IP adressen van de virtuele router moeten worden negeert door de Backup router. Pakketen gericht aan zijn eigen fysieke IP adressen mogen wel worden geaccepteerd. Binnen VRRP kunnen routers lid zijn van meerdere routing groups. Op deze manier kunnen routers meerdere subnets bedienen. Een virtual routing group kan slechts lid zijn van 2 subnets. Een aan de inbound interface, en de andere aan de outbound interface. Door de routers lid te maken van twee routing groups, kunnen er 2 + 2 = 4 subnets worden bediend. Voor iedere routing group waaraan een router wordt toegevoegd kunnen twee extra subnets worden bediend. Figuur 1.7 laat de routers uit het eerdere voorbeeld zien, maar nu geconfigureerd om deel uit te maken van twee routing groups. Router A is Master van VRID 1 en is tevens Backup voor VRID2. Router 2 is Backup voor VRID 1 en Master voor VRID 2.

Redundantie

19

Figuur 1.7 ‘Virtuele Router in twee Routing Groups’ Router Redundancy problemen Naast de toch soms lastige configuratie en tuning van bijvoorbeeld het VRRP protocol brengt een virtuele router ook nog enkele problemen met zich mee. Zo is het vrij eenvoudig om middels verkeerde configuraties de beschikbaarheid vervalt, of dat moedwillig verkeerde informatie wordt verzonden naar de virtuele router om op die manier deze te ontregelen. Een virtuele router werkt doordat een Master en een of meer Standby routers met elkaar communiceren middels speciale multicast pakketten. Op zich zelf een goed systeem, ware het niet dat iedereen zo een multicast pakket kan genereren en daarmee het systeem in de war brengen. Door een multicast te verzenden naar het multicast adres van de virtuele router, kan een kwaadwillend persoon de routing group bijvoorbeeld laten denken dat deze deel uit maakt van de routing group en dus deel mag nemen aan het proces. Wanneer deze een Preemt flag verstuurd, met daarbij valse gegevens, kan een master zijn rol afstaan. Om deze problemen te ondervangen zijn er een aantal oplossingen bedacht met betrekking tot de beveiliging van virtuele routers. VRRP is ontworpen voor vele verschillende omgevingen met verschillende security policies hanteren. VRRP heeft verschillende technieken tot zijn beschikking om dergelijke aanvallen op de beschikbaarheid van een virtuele router te voorkomen. Allereerst is er een mechanisme ingebouwd om extern verkeer af te vangen en zijn verschillende authenticatie mogelijkheden in het protocol opgenomen. Ongeacht welke vorm van authenticatie wordt toegepast, beschikt VRRP over een mechanisme welk voorkomt dat een VRRP multicast pakket wordt geïnjecteerd vanaf een extern netwerk. Dit controleert een router aan de hand van het TTL veld in een VRRP message. VRRP routers accepteren allen messages met TTL value van 255. Wanneer een bericht uit een ander Redundantie

20

netwerk komt zal deze waarde zijn afgenomen, zal het bericht als ongeldig worden gezien en komt het te vervallen. Buiten de TTL waarde waarop VRRP controleert, zijn er ook verschillende vormen van authenticatie mogelijk. Er kan gekozen worden om geen authenticatie te gebruiken. Dit is de default setting binnen VRRP, maar dit biedt geen enkele vorm van bescherming en moet dan ook alleen gebruikt worden in omgevingen waar er weinig tot geen security risico’s zijn. Naast deze default ‘onveilige’ instelling, kan ook gekozen worden voor een aantal veiliger methoden en de eerste daarvan is VRRP met een Simple Text Password. VRRP multicast worden verzonden met een clear text password. Deze vorm van authenticatie voorkomt dat een router aan een verkeerde routing group wordt toegevoegd, doordat het wachtwoord niet overeenkomt. Hierdoor kunnen er geen onverwachte fouten optreden door misconfiguratie. Deze vorm van authenticatie beschermd niet tegen kwaadwillende, gezien ze het wachtwoord kunnen opvangen door het VRRP verkeer allereerst af te luisteren. Deze vorm van authenticatie moet net als de vorige methode alleen gebruikt worden in omgevingen waar er weinig tot geen security risico’s zijn. Tevens moet het wachtwoord welk wordt gebruikt, niet gelijk zijn aan een ander wachtwoord. De laatste vorm van authenticatie maakt gebruikt van HMAC-MD5-96. HMAC staat voor key-Hashed Message Authentication. Deze vorm van authenticatie maakt gebruikt van een secret key, welke bekend is op alle routers binnen de routing group. Middels deze key kan een router niet alleen het bericht authenticeren, maar tevens de data integriteit ervan controleren. Deze vorm van authenticatie zorgt voor een optimale bescherming en is te gebruiken in security gevoelige omgevingen. Implementatie In figuur 1.8 zien we dat er tussen de Building Access switches en de distribution switches de FEC’s zijn verbonden aan twee verschillende Distribution switches. Op deze manier is er gezorgd voor link redundantie op de access-layer. De volledige Building Distribution, alsook de Serverfarm Distribution en Edge Distribution zijn actief redundant uitgevoerd. Daarnaast kan er een spare Multilayer switch en Access layer switch beschikbaar zijn om ook te voldoen aan de passieve redundantie. In de Enterprise Edge Internet Connectivity module is de router welke zorgt voor de verbinding naar de ISP samen met de router van de Remote Access / VPN module gekoppeld. Deze vormen nu twee virtuele routers welke als backup van elkaar zijn geconfigureerd.

Redundantie

21

Figuur 1.8 ‘Netwerk Design met device redundantie’

Redundantie

22

2.4

Netwerken extern

Binnen het netwerk kunnen er door middel van het redundant uitvoeren van links, switches en routers veel problemen met betrekking tot de beschikbaarheid worden opgevangen. Echter zijn er nog enkele onderdelen met betrekking tot het netwerk in dit verslag nog niet aan bod gekomen. Dit zijn de koppelingen met externe netwerken, dan wel het Internet. In dit hoofdstuk zal verder worden ingegaan op Multihoming en Out-of-Band Management. Multihoming Organisaties worden tegenwoordig steeds meer afhankelijk van een betrouwbare verbinding met het Internet. Diensten als E-mail, E-commerce en VPN alsook eventuele remote vestigingen moeten 24x7 beschikbaar zijn. Om deze continuïteit te kunnen waarborgen kan er niet meer worden volstaan met een koppeling naar slechts een ISP. Veelal wordt er gekozen om het netwerk te koppelen met twee verschillende ISP’s. Het koppelen aan twee verschillende netwerken wordt Multihoming genoemd. Multihoming komt voor in meerdere varianten: • 1 link, meerdere IP adres (spaces) • meerdere links, een IP adres per interface • meerdere links, een IP adres (space) Alle drie de varianten van Multihoming hebben verschillende eigenschappen. De eerste oplossing beperkt de organisatie nog altijd met één fysieke uplink, en wanneer een probleem bestaat met de link, zullen beide verbindingen komen te vervallen omdat ze gebruik maken van dezelfde fysieke interface en router. De tweede oplossing maakt gebruik van twee fysieke interfaces met verschillende IP adressen. Wanneer er gebruik wordt gemaakt van A records, of in het geval van IPv6 AAAA records, kan een van de links uitvallen, en zal de organisatie nog steeds bereikbaar zijn. Alleen de reeds openstaande sessies zullen verbroken worden. De laatste oplossing is wat over het algemeen bedoelt wordt met Multihoming en is waar Multihoming in dit verslag naar verwijst. De organisatie adverteert haar eigen IP adres space over twee verschillende links naar de buitenwereld. Ongeacht wat gebeurd met de links, het routing protocol (BGP) zal ervoor zorgen dat de routes op een correcte manier gepropageerd worden. Op organisatie niveau binnen het bedrijf heeft Multihoming een veel grotere impact. Allereerst de overeenkomsten met de ISP’s. Het is belangrijk dat er met beide ISP’s overeen wordt gekomen dat er maar een IP adres space wordt geadverteerd en dat beide ISP’s deze moeten opnemen in hun routingtabel. Daarnaast is het van belang dat onderzocht wordt of ISP’s gebruik maken van dezelfde faciliteiten. Dit kan catastrofaal zijn in het geval van problemen bij de ISP. Als organisatie ben je in de veronderstelling dat alle Redundantie

23

gevaren zijn afgedekt, echter wanneer er zich problemen voordoen blijken beide ISP’s gebruik te maken van dezelfde faciliteiten. Een redundante koppeling met het internet zal niet voor alle organisaties haalbaar zijn doordat de kosten vaak erg hoog uitvallen. In deze gevallen kan er worden gekozen voor een asymmetrische koppeling met twee ISP’s. In het geval dat de hoofdverbinding met het internet komt te vervallen, kan de lagere kwaliteit internet verbinding het internet verkeer overnemen. Zo kan bijvoorbeeld gekozen worden voor in plaats van een tweede gigabit koppeling voor een 100 mbit koppeling. Om te voorkomen dat deze tweede verbinding overbelast wordt, moeten voor deze koppeling andere policies worden toegepast, en kan op prioriteit van verkeer worden gefilterd. Zo zal bijvoorbeeld E-mailverkeer en HTTP requests voor de website worden toegestaan, maar FTP of Streaming media worden tegen gehouden. Out-of-Band Management Redundantie ook voorkomen op volledige netwerken in plaats van alle losse onderdelen daarvan. Externe locaties zijn veelal gekoppeld met de hoofdlocatie via een snelle WAN verbinding waarover al het normale, alsook het netwerkmanagement verkeer overheen gaat. Deze verbindingen worden meestal niet redundant uitgevoerd omdat het hier om dure ‘leased lines’ gaat. Zolang de verbinding tussen beide locaties operationeel is kan er centraal vanuit de hoofdlocatie worden beheer worden uitgevoerd op de nevenlocatie(‘s). Echter wanneer de verbinding tussen de hoofd- en nevenlocatie wordt verbroken is het onmogelijk om te bepalen waar de problemen zich voordoen. Omdat er geen inzicht is in de status van het netwerk en haar onderdelen op de nevenlocatie, kan niet worden vastgesteld of het probleem zich voordoet op de eigen apparatuur of bij de provider van de leased line. Er kan alleen worden vastgesteld dat de link verbroken is. Nadat de router op de hoofdlocatie is gecontroleerd, kan het zijn dat deze het probleem veroorzaakt en kan het probleem vrij snel worden opgelost. Echter wanneer deze router niet de oorzaak is van het probleem zal er iemand op de externe locatie moeten gaan kijken of de router aldaar de oorzaak is. Juist om dit soort problemen te ondervangen wordt er bij organisaties met een of meerdere nevenlocaties vaak Out-of-Band Management toegepast. Out-ofBand staat voor communicatie welke niet het zelfde pad volgt als de normale data. Aan de hand van deze definitie is kan gesteld worden dat ieder parallel managementnetwerk een Out-of-Band Management netwerk is. Echter wordt deze naam meestal geassocieerd met netwerkmanagement voor externe locaties. Het netwerkmanagement beschikt over een tweede koppeling met de nevenlocatie, welke gebruikt kan worden in het geval dat de normale WAN verbinding is verbroken. Hier is echter geen spaken van een tweede leased line, maar een goedkopere On-demand oplossing zoals bijvoorbeeld ISDN of zelfs PSTN. Het gebruik van bijvoorbeeld ADSL is ook mogelijk, maar het probleem daarvan is dat het managementverkeer over een publiek netwerk

Redundantie

24

wordt verstuurd, namelijk het Internet. Dit is om security redenen normaal gesproken niet wenselijk. Wanneer een verbinding met een van de nevenlocaties wordt verbroken, kan op de hoofdlocatie kan middels bijvoorbeeld een ISDN router een verbinding worden opgezet met de nevenlocatie. Via deze verbinding kan er op de nevenlocatie onderzocht worden of de WAN router het probleem veroorzaakt, en kan het probleem wellicht worden opgelost. Wanneer blijkt dat zowel de router op de hoofdlocatie, alsook de router op de nevenlocatie niet de veroorzakers zijn van het probleem, kan contact worden opgenomen met de provider van de WAN link, en kan deze verantwoordelijk worden gesteld. Het is van groot belang om, in het geval van On-demand oplossingen als bijvoorbeeld ISDN, de routering en beveiliging van de routers van en naar de externe locatie goed af te stemmen. Zo moet er gebruikt worden gemaakt van statische routes, of moet het routing protocol zo worden ingesteld dat deze geen routing updates verstuurd over de Out-of-Band management interface. Op het moment dat er bijvoorbeeld om de 60 seconden een update wordt verstuurd over de ISDN lijn, zal deze iedere keer verbinding maken met de ISDN router op de nevenlocatie en zal er iedere keer betaald moeten worden voor het opzetten van de link en de duur van het gesprek. Naast het tegenhouden van automatisch gegenereerd verkeer, moet er ook voor gezorgd worden dat alleen netwerkmanagement verkeer over de lijn gaat. Dit kan op de eerste plaats worden afgedwongen door alleen verkeer uit het Netwerkmanagement VLAN toe te staan over de koppeling. Daarnaast moet de route over de WAN link ten alle tijden geprefereerd worden over de route over de ISDN lijn. Op het moment dat de route over de WAN verbinding komt te vervallen, zal de ISDN route automatisch de hoogste prioriteit krijgen, omdat het de enige aanwezige route zal zijn. Problemen Zowel bij Multihoming, alsook Out-of-Band Management doen zich vaak problemen voor omdat de routing configuraties niet goed zijn afgesteld. Doordat routing protocollen niet begrijpen wat met het verkeer moet gebeuren kan het zijn dat pakketten verloren gaan, of dat zelfs verbindingen helemaal niet meer tot stand kunnen komen. Daarom is het van groot belang om alvorens Multi-homing of Out-of-Band Management toe te passen, goed te onderzoeken hoe de routing policy van de Organisatie is, en aan de hand van die gegevens de correcte routing configuratie te maken. Naast de complexiteit van de Routing, komt er bij Out-of-Band management nog meer kijken. Door een ISDN router te plaatsen kan er van buitenaf door iedereen toegang verkregen worden tot een router binnen het netwerk. Zodra een van de telefoonnummers bekend kan erop worden in gebeld. Het is daarom erg belangrijk om goede beveiliging toe te passen op de inbelvoorzieningen. Allereerst moet alleen inbound verkeer van het telefoonnummer van de hoofdlocatie worden toegelaten. Daarnaast moet er geen telnet verkeer worden toegelaten, maar alleen SSH. Als laatste moet er een strenge toegangscontrole plaatsvinding. Gebruikersnaam, wachtwoord, Redundantie

25

en liefs geconfirmeerd aan een Radius server of vergelijkbaar. Op deze manier kunnen kwaadwillende van buitenaf geen toegang krijgen tot het netwerk.

Redundantie

26

2

Services redundantie

Wanneer het netwerk redundant is uitgevoerd, kan ervan worden uitgegaan dat alle services bereikbaar zijn. Wanneer een service niet functioneert, komt dit doordat de service zelf is uitgevallen. Daarom is het van belang om ook andere services redundant uit te voeren. Dit hoofdstuk zal verder ingaan op de verschillende methoden van redundantie die services redundantie kunnen bewerkstelligen

2.1

Multipath I/O

De techniek In computer opslag en transport is multipath I/O (input / output) een fout tolerantie techniek waar fysiek gezien meer dan 1 pad bestaat tussen de verschillende componenten. Dit kunnen paden zijn tussen de CPU en opslag apparaten zoals harde schijven. Deze paden ontstaan door bijvoorbeeld bussen, controllers switches en bridge componenten. Multipath principes worden ook toegepast bij Out of Band Management.

Voorbeelden Een goed voorbeeld waarin multipathing wordt gebruikt staat in een thesis van IBM over “Redundancy Management Technique for Space Shuttle Computers” uit 1976. Deze thesis beschrijft hoe er gebruik wordt gemaakt van redundante circuits waar 5 onafhankelijke computers de beschikking hebben om de Space Shuttle aan te sturen. http://www.research.ibm.com/journal/rd/201/ibmrd2001E.pdf Een ander voorbeeld zou een SCSI harde schijf zijn welke is verbonden met 2 SCSI controllers, in dezelfde computer. Zie figuur 2.1 hieronder. Zou een controller, poort of switch uitvallen dan kan het besturingssysteem automatisch de I/O routeren via de overgebleven controller. Dit alles kan transparant voor de applicaties verlopen, mogelijk met een kleine vertraging.

Schijf Mo e d e rb o rd

C C

U /D

B1

R e se t

B4

C a rry o u t EN B

Figuur 2.1, een harde schijf verbonden met 2 controllers.

Redundantie

27

Mogelijkheden Multipath software lagen kunnen de paden bundelen voor performance verhogende mogelijkheden zoals dynamic load balancing of traffic shaping. (Traffic shaping tracht het verkeer in een computernetwerk te beheren en reguleren.). Men moet niet uit het oog verliezen dat wanneer men teveel gaat vertrouwen op de bundeling van paden dat wanneer er 1 pad uitvalt de rest van de paden overbelast kunnen raken.

Ondersteuning Een aantal besturingssystemen bieden ondersteuning voor multipath I/O. - AIX – MPIO Driver, AIX 5L 5.2 (Oktober 2002) - Linux – multipath driver. Linux kernel 2.4.17 - Solaris Multiplexed I/O (MPxIO), Solaris 8 (Februari 2000) - Windows MPIO driver, Windows 2003 Server (April 2003) Ook zijn er andere software producten welke multipath I/O ondersteunen. Hieronder volgt een kleine selectie. - EMC Powerpath - FalconStor IPStor DynaPath - Fujitsu Siemens Multipath for Linux and Windows - Hitachi Dynamic Link Manager - HP Secure Path

2.2

Clustering

Historie Het eerste cluster product was ARCnet wat ontwikkeld was door Datapoint in 1977. Commercieel gezien was het geen succes en clustering kwam niet van de grond totdat DEC zijn VAX cluster product in de jaren na 1980 introduceerde voor het VAX/VMS besturingssysteem. ARCnet en VAXcluster ondersteunden niet alleen parallel computing maar deelde ook het file systeem en andere componenten. Het was de bedoeling van deze systemen om de voordelen van parallel processing te bieden terwijl de data betrouwbaar bleef. VAXcluster staat tegenwoordig bekend als VMScluster en is beschikbaar op OpenVMS systemen van HP. De historie van cluster computing is nauw verweven met de evolutie van netwerk technologie. Sinds netwerk technologieën goedkoper en sneller zijn geworden, worden cluster computers steeds aantrekkelijker.

De techniek Een computer cluster is een groep van gekoppelde computers welke nauw samenwerken, zodat ze als één computer gezien kunnen worden. In de meeste gevallen zijn de computers van een cluster verbonden met een snel LAN netwerk.

Redundantie

28

Een cluster wordt vaak ingezet voor een verbeterde snelheid en / of betrouwbaarheid ten opzichte van één losse computer. Daarnaast is in de meeste gevallen een cluster beter betaalbaar dan één of een paar computers van vergelijkbare snelheid of betrouwbaarheid. In de hierna volgende paragrafen zullen een aantal type clusters behandeld worden.

High-Availability Cluster Een high-availability (hoge beschikbaarheid) cluster wordt primair geïmplementeerd voor het verbeteren van de beschikbaarheid van diensten welke de cluster levert. Dit type cluster werkt met redundant uitgevoerde nodes. Wanneer een node uitvalt, zullen de taken overgenomen worden door een andere node waardoor de dienst transparant blijft werken voor de eindgebruiker. Het minimum aantal nodes wat benodigd is voor een high-availability cluster zijn 2 nodes. Een high-availability cluster probeert redundantie na te streven inherent probeert het om de single points of failures weg te werken. Er zijn verschillende commerciële implementaties van dit type cluster voor verschillende besturingssystemen. Het Linux-HA project is een veel gebruikte open source implementatie voor het Linux besturingssyteem.

Load balancing Cluster Een load balancing cluster fungeert middels één of meerdere load balancing front ends waar alle workload binnenkomt en daarna gedistribueerd word over een verzameling van back end servers. Deze cluster implementatie, ook wel gerefereerd als server farm, wordt primair ingezet voor een verbeterde performance. Daarnaast bevat dit type cluster ook high-availability mogelijkheden. Er zijn verschillende commerciële load balancers beschikbaar waaronder Platform LSF HPC, Moab Cluster Suite en Maui Cluster Scheduler. Een open source implementatie is Linux Virtual Server voor het Linux besturingssysteem.

High-Performance Cluster Een high-performance cluster wordt primair geïmplementeerd om een verbeterde performance te bieden. Dit wordt bewerkstelligd door een rekenkrachtige taak te verdelen over een aantal verschillende nodes binnen een cluster. De toepassing van dit type cluster komt vaak voor bij scientific computing. Sara heeft bijvoorbeeld de expertise in high performance computing en de mogelijkheden hiervoor. Een populaire implementatie van een high performance cluster zijn nodes welke Linux draaien als besturingssysteem en de open source software om parallellisatie te implementeren. Naar deze configuratie wordt meestal gerefereerd als Beowulf cluster. Het concept van een Beowulf cluster is dat het gebruik maakt van veel goedkope computers om een kosten effectief alternatief te bieden naast een Redundantie

29

traditionele supercomputer. Een voorbeeld van een vergelijkbaar project was de “Stone Soupercomputer”. High performance clusters zijn geoptimaliseerd voor workloads welke jobs of processen vereisen op de afzonderlijke nodes om actief te communiceren tijdens de berekening. Deze berekeningen omvatten tijdelijke resultaten van de ene node welke benodigd zijn voor toekomstige berekeningen op andere nodes.

Grid Computing Grid computing of grid clusters is een techniek welke nauw gerelateerd is aan cluster computing. Een belangrijk verschil tussen grids en traditionele clusters is de relatie tussen de verzameling computers onderling. Grids verbinden een verzameling van computers welke elkaar niet volledig vertrouwen en opereren meer als een dienst dan als één losse computer. Daarnaast ondersteunen grids meer heterogene systemen wat in andere cluster vormen meestal niet het geval is. Grid computing is geoptimaliseerd voor workloads welke bestaan uit verschillende onafhankelijke jobs of pakketten van werk. Deze jobs of pakketten hoeven geen data te delen tijdens de uitvoer. Grids zijn in staat jobs toe te kennen aan computers welke onafhankelijk van elkaar het werk doen. Bronnen, zoals opgeslagen data, kunnen gedeeld worden door alle nodes, maar tussentijdse resultaten van een job hebben geen invloed op de vooruitgang van de andere nodes in het grid.

Ondersteuning Onder Linux zijn er verschillende cluster software pakketten beschikbaar. Hieronder volgt een kleine selectie. - Linux Virtual Server - Linux-HA - Mosix - OpenSSI - DragonFly BSD - TORQUE Een commerciële high-availability cluster oplossing voor Windows is Microsoft Clustering Services (MSCS). Deze oplossing is gebaseerd op techniek welke ontworpen is door Digital Equipment Corporation (DEC). Nog een aantal andere (commerciële) cluster oplossingen volgen hieronder. - BOINC - HP’s OpenVMS - IBM’s HACMP - IBM Parallel Sysplex - MC Service Guard for HP-UX

Redundantie

30

2.3

Load balancing

Load balancing is een techniek welke gebruikt wordt om een bepaalde hoeveelheid werk te verdelen over meerdere processen, computers of andere bronnen.

Webserver load balancing Een probleem voor populaire en veelbezochte Internet sites is de afhandeling van het grote aantal bezoekers dat zij genereren. Wanneer een site groeit in het aantal bezoekers wordt dit meestal als een schaalbaarheids probleem gezien. Een van de manieren om dit op te lossen is om gebruik te maken van een layer 4 router. Dit is een speciale router die inkomende pakketjes doorstuurt naar een bepaald IP adres op het eigen netwerk waarbij layer 4 verwijst naar het 7 laags OSI model. De router werkt op de transport layer en maakt beslissingen waar de pakketjes naar toe gaan. Deze routes maken gebruik van verschillende regels om te bepalen hoe ze het verkeer routeren. Dit kan gebaseerd zijn op de minste load, snelste respons tijd of het verdelen van de aanvragen. Een alternatieve methode kan het gebruik van Linux Virtual Server zijn. Dit is een geavanceerde open source load balancing oplossing voor netwerk diensten. Een andere methode is een combinatie van - Round Robin DNS, dit is een techniek waarbij load balancing wordt toegepast door een DNS server. Voor een DNS request wordt een lijst van IP adressen gebruikt om een van deze IP adressen als een DNS response te sturen. Het IP adres aan de top van de lijst wordt een aantal keer gebruikt waarna het onderaan de lijst wordt geplaatst. - Squid cache servers, deze servers gebruiken de respons tijd om page requests te verdelen en te versturen naar de web servers. Daarnaast hebben ze pagina’s in de cache staan waardoor de web servers ontlast worden. - PHP scripts, deze scripts draaien op de web servers om de load naar een van de databbase servers te versturen, dit is afhankelijk van het type aanvraag. Een update query kan zo bijvoorbeeld op de ene database server uitkomen en een simpele select query kan bij een slave database server uitkomen.

2.4

Hot spare

Hot spare wordt gebruikt als fail-over mechanisme voor het leveren van betrouwbaarheid in systemen. Een hot spare component is actief en verbonden als onderdeel van een werkend systeem. Wanneer een component defect raakt schakelt het hot spare component in werking. Een hot spare component reduceert de Mean Time to Repair (MTTR).

Redundantie

31

Voorbeeld Een voorbeeld kan een harde schijf zijn. De schijf staat aan, dit is wat men verstaat onder “hot”, maar functioneert niet in het systeem. In het geval van een harde schijf kan de data in mirror staan (een exacte kopie). Wanneer de hot spare het werk overneemt draait het systeem verder waardoor deze een minimale downtime heeft. Een hot spare schijf is een schijf of groep van schijven welke automatisch of handmatig, afhankelijk van de hot spare policy, ter vervanging dient voor een falende schijf, of falende schijf in een RAID configuratie. RAID configuraties komen nog uitgebreid aan bod in het hoofdstuk Redundant Array of Independent Disks.

2.5

Hot swap

Hot swap is de mogelijkheid tot het verwijderen en vervangen van componenten van een machine, meestal een computer, terwijl deze functioneert. Wanneer de benodigde software geïnstalleerd is op de computer kunnen hot swap componenten aangesloten en verwijderd worden zonder te herstarten. Een voorbeeld is Universal Serial Bus (USB) welke de mogelijkheid biedt tot het veilig verwijderen en toevoegen van bijvoorbeeld muizen, toetsenborden en printers. Een hot swap onderdeel kan zonder interactie met het besturingssysteem vervangen worden.

Historie Vroeger beschikten alleen heel dure systemen over de mogelijkheden van hot swap technologie, omdat het moeilijk te beheren viel. Sinds de laatste jaren begint de techniek op verschillende niveaus zijn intrede doen in computer systemen.

Implementatie Een aantal bus technologieën welke hot swap ondersteunen zijn bijvoorbeeld PCMCIA, USB, FireWire, Fibre Channel en SATA. Een bus technologie welke dit niet ondersteunt is bijvoorbeeld IDE. Een hot swap component kan variëren een USB flash drive tot server harde schijven, PCI Express uitbreidings kaarten, PCMCIA kaarten en zelfs sommige voedingen. Switching Power Inc. en Comix Computer Inc. zijn bijvoorbeeld leveranciers van hot swap voedingen.

Overwegingen Machines welke hot swap ondersteunen moeten kunnen detecteren of een onderdeel verwijdert is. Daarnaast moeten alle elektrische en mechanische verbindingen zo ontworpen zijn dat de het component zelf, de componenten waarop het aangesloten was, en de gebruiker geen schade ondervinden wanneer het onderdeel verwijderd wordt. Eenvoudige implementaties vereisen een component shut down procedure voordat het verwijderd kan worden. Dit versimpelt de implementatie maar is niet robuust in het geval een component defect raakt. Redundantie

32

Ingewikkelde implementaties adviseren dat een component shut down procedure, maar hebben genoeg redundantie in het systeem dat wanneer een component wordt vervangen het systeem door blijft draaien. In deze systemen wordt hot swap gebruikt voor onderhoud aan een computer of voor het vervangen van kapotte hardware.

Connectoren De meeste moderne hot swap methodes vertrouwen op speciale connectoren met speciaal uitstekende pinnen. Bij de meeste van deze ontwerpen zijn de aarding pinnen langer dan bij de andere pinnen. Dit is om verzekerd te zijn dat ieder gevoelig circuit nooit eerder verbonden is voordat er een veilig circuit aarding gerealiseerd is. De rest van de connectoren bestaat uit kortere pinnen of in sommige gevallen zijn er 3 verschillende pin lengtes. De snelheid waarmee een component aangesloten word, kan niet precies gecontroleerd worden maar andere beperkingen kunnen ervoor zorgen dat er geen worst case scenario’s ontstaan. Ground Sense Signal Power Signal Pre-Charge Ground

Figuur 2.2: Connector met lange en korte pinnen Voor een pin waar het verschil in lengte 0,5 mm is, is de tijd voordat de langste en kortste pin contact maken tussen de 25 ms en 250 ms. Praktisch gezien is het noodzakelijk dat hot swap componenten overweg kunnen met een dergelijk overspanning. Daarbij kan het zijn dat pinnen van dezelfde lengte niet exact op het zelfde tijdstip contact maken vanwege mechanische (in)toleranties.

Stroom Hot swap componenten hebben meestal een pre-charged pin welke contact maakt voordat de hoofdstroompin dat doet. Deze pre charged pin is beveiligd door een circuit dat de inkomende stroom gecontroleerd tot een acceptabel niveau laat komen. Dit zorgt ervoor dat er geen schade ontstaat door bijvoorbeeld voltage verschillen. Een mogelijk voorkomende volgorde voor het aansluiten van een connector kan zijn: • 1 De lange aarding pin maakt contact, de basis voor elektrische veiligheid en ESD protectie komt beschikbaar. • 2 Lang (of medium lange) pre-charged pinnen maken contact, condensatoren laden zich op. • 3 Een vertraging van een aantal milliseconden. Redundantie

33

• • • • • •

4 De kortere stroom en signaal pinnen maken contact. 5 De connector is volledig aangesloten. 6 Het soft-start circuit start met het toeleveren van stroom. 7 Een vertraging van een aantal milliseconden. 8 Het soft-start circuit voltooid zijn routine. 9 Het component begint normaal te fungeren.

Signaal elektronica Circuits welke aangesloten zijn via de signaal pinnen in een hot-swap component moeten beveiligd zijn tegen Electro Static Discharge (ESD). Dit wordt vaak bewerkstelligd door diodes. De effecten van ESD kunnen beperkt worden door een goed ontwerp van het omhulsel van het hot-swap component. Middels bijvoorbeeld een speciale coating kan het geleidend materiaal afgeschermd worden. Zorgvuldig moet omgegaan worden wanneer systemen ontworpen worden waarbij meerdere hot-swap componenten met elkaar verbonden zijn. Als een hot-swap component aangesloten wordt kunnen de input en output signaal pinnen een tijdelijke kortsluiting veroorzaken door de aarding. Dit kan weer resulteren in bepaalde pulsen in het signaal wat de werking van de hot-swap componenten in het systeem kan beïnvloeden. Dit was een probleem bij de eerste parallelle SCSI harde schijven. Dit werd opgelost door de signaalpinnen te beveiligen met diodes en weerstanden.

2.6

SLB protocol

Het Server Load Balancing (SLB) protocol is een Cisco proprietary protocol. Het maakt beslissingen om de load te verdelen afhankelijk van de beschikbaarheid van een toepassing of de server capaciteit. SLB gebruikt 2 algoritmes voor de pakketdistributie. Het SLB protocol is een IOS-gebaseerde oplossing dat IP server load balancing biedt. Een virtuele server representeert een groep van echte servers in een cluster van netwerk servers (server farm). De cliënts verbinden op het IP adres van de virtuele server. Het virtuele server IP adres is geconfigureerd als een loopback adres, of secondair IP adres, op elke van de echte servers. Als een cliënt een verbinding maakt met de virtuele server, dan kiest het SLB protocol een echte server uit voor de verbinding gebaseerd op het geconfigureerd load balancing algoritme. Figuur 2.3 illustreert een SLB netwerk.

Redundantie

34

Figuur 2.3: een SLB netwerk

Algoritmes Het SLB protocol levert 2 load balancing algoritmes: - weighted round-robin - weighted least-connection Het weighted round-robin algoritme specificeert dat de echte server welke gebruikt wordt voor een nieuwe verbinding met de virtuele server gekozen wordt van de server farm in een circulerende methode. Elke echte server krijgt een waarde toegewezen, n, dat de capaciteit voor het afhandelen van connecties weergeeft in vergelijking met de andere echte servers. Nieuwe verbindingen worden toegewezen aan een echte server een n aantal malen totdat de volgende echte server uit de farm gekozen wordt. Het weighted least-connections algoritme specificeert dat de volgende echte server met de minst actieve verbindingen gekozen wordt van de server farm voor een nieuwe verbinding met de virtuele server. Elke echte server krijgt ook een waarde toegewezen door dit algoritme. De waarden worden toegewezen aan de hand van het aantal actieve verbindingen en op de relatieve capaciteit van elke server.

2.7

GLBP protocol

Het Gateway Load Balancing Protocol is een Cisco proprietary protocol en levert automatische router backup voor de IP hosts, geconfigureerd met een default gateway, in een IEEE 802.3 LAN netwerk. Meerdere routers in een LAN netwerk combineren de mogelijkheid om een virtuele router te leveren terwijl ze de IP pakketten load verdelen. Andere routers op het LAN kunnen dienen als redundante GLBP routers welke actief worden als een bestaande forwarding router uitvalt.

Werking GLBP dient als een vergelijkbare, maar niet identieke, functie voor de gebruiker als HSRP en VRRP doen. GLBP doet load balancing over meerdere routers (gateways) gebruik makend van een virtueel IP adres en alle routers in de virtuele router groep participeren in het doorsturen van pakketten. GLBP leden communiceren met elkaar door ‘hello’ pakkketjes Redundantie

35

iedere 3 seconden uit te sturen over het multicast adres 224.0.0.102 met behulp van het User Datagram Protocol (UDP) poort 3222 (source en destination). Leden van een GLBP groep activeren een virutele gateway (AVG) voor die groep met behulp van een election procedure. De andere leden van die groep leveren een backup mogelijkheid wanneer de AVG uitvalt. De AVG kent een virtueel MAC adres toe aan elke lid van de GLBP groep. Elke gateway is verantwoordelijk voor het doorsturen van pakketjes welke gestuurd zijn aan het virtuele MAC adres. Deze gateways zijn bekend als active virtual forwarders (AVF) voor hen eigen virtuele MAC adres. De AVG is verantwoordelijk voor het beantwoorden van het Address Resolution Protocol (ARP) aanvragen. Load sharing wordt bereikt doordat de AVG antwoord op de ARP pakketjes met verschillende virtuele MAC adressen. In figuur 2.4 is Router A de AVG voor de GLBP groep en is verantwoordelijk voor het virtuele IP adres 10.21.8.10. De router A is ook een AVF voor het virtuele MAC adres 0007.b400.0101. Router B is een lid van dezelfde GLBP groep en is een AVF voor het virtuele MAC adres 0007.b400.0102. Client 1 heeft als default gateway 10.21.8.10 en het gateway MAC adres van 0007.b400.0101. Client 2 deelt hetzelfde default gateway IP adres maar heeft een ander gateway MAC adres, 0007.b400.0102 omdat router B de load deelt met router A.

Figuur 2.4: GLBP groep

Algoritme GLBP gebruikt een waarden methode om te bepalen wat de doorstuur capaciteit is van elke router in het GLBP groep. De waarden die worden toegekend aan een router in de GLBP groep bepalen of het pakketten doorstuurt en zo ja voor hoeveel hosts in het netwerk deze pakketjes zal doorsturen. Thresholds kunnen het doorsturen uit- en inschakelen wanneer een waarde onder- of overschreden wordt. Redundantie

36

De GLBP groep kan automatisch de waarden aanpassen door de staat van de interfaces van de router te monitoren. Als een interface uitvalt wordt de waarde van de interface gereduceerd met een specifiek getal.

2.8

Redundant Array of Independent Disks

Redundant Array of Independent Disks, ook bekend als Redundant Array of Inexpensive Disks, (RAID) is een system welke gebruik maakt van meerdere harde schijven om data te repliceren of te delen over de schijven. Afhankelijk van de gekozen versie kan RAID een verhoogde data integriteit, fouttolerantie, dataoverdracht of capaciteit bieden ten opzichte van losse schijven. In de originele implementaties (redundant array of inexpensive disks) was het grote voordeel de mogelijkheid om meerdere goedkope oude schijven te combineren tot 1 grote voor een grotere capaciteit, betrouwbaarheid, snelheid of een combinatie hiervan. Dit was vaak een goedkopere oplossing ten opzichte van een schijf met de nieuwste technologie welke deze karakteristieken ook kon bieden. De simpelste vorm van RAID combineert meerdere harde schijven tot een logische. In plaats dat je meerdere schijven ziet, ziet het besturingssysteem er 1. RAID wordt over het algemeen gebruikt in server systemen en meestal, maar niet noodzakelijk, geïmplementeerd met schijven van dezelfde grootte. Door de prijsverlagingen van schijven komt RAID breder beschikbaar en worden RAID opties in moederbord chipsets ingebouwd zodat het ook voor de geavanceerdere computer gebruikers beschikbaar komt. Vooral bij video en audio bewerking toepassingen zijn RAID oplossingen uitermate geschikt en gewenst. De originele RAID specificatie stelde een aantal prototypes voor, genaamd RAID levels. Elk had theoretisch voor- en nadelen. Na verloop van jaren verschenen verschillende implementaties van het RAID concept. De meesten hebben kleine verschillen van de originele ‘ideale’ RAID levels en kan tot verwarring leiden. Over de definitie van RAID is jaren verschil van mening geweest. Bij de term redundant gaan bij verschillende mensen de haren overeind staan omdat RAID 0 dan wel een echt RAID type is. Ook de verandering van inexpensive naar independent lijdt tot verwarring vanwege de oorspronkelijke intentie van het gebruik van RAID.

Historie Norman Ken Ouchi van IBM kreeg in 1978 het U.S. Patent 4,092,732 getiteld “System for recovering data stored in failed memory unit” en claimt dit patent wat later beschreven werd als RAID 5 met full strip writes. Dit patent benoemt ook disk mirroring of duplexing (wat later de term RAID 1 kreeg) en de beveiliging met dedicated parity (wat later de term RAID 4 kreeg). In 1988 werden de RAID levels 1 tot en met 5 formeel gedefinieerd door David A. Patterson, Garth A. Gibson en Randy H. Katz in de thesis “A case for redundant arrays of inexpensive disks (RAID)”. Dit werd gepubliceerd tijdens de SIGMOD conferentie in 1988. Redundantie

37

Inexpensive vs. independent De I in RAID staat in de meeste gevallen voor independent in plaats van inexpensive. Een van de voordelen van RAID was het gebruik van goedkope (inexpensive) apparatuur en dit geldt nog steeds in veel gevallen wanneer IDE / ATA schijven gebruikt worden. Vaker wordt independent gebruikt (en duurder: expensive) voor SCSI of Fibre Change harde schijven. Hoewel de kosten van zulke schijven tegenwoordig stukken lager zijn dan voorheen.

Hardware vs. software RAID kan geïmplementeerd worden met ene hardware of een software oplossing. Ook zijn er hybride varianten die een combinatie vormen van een hardware en software oplossing. Bij een software implementatie stuurt het besturingssysteem de verzameling schijven aan met een normale schijf controller (IDE/ATA, SCSI, Fibre Channel etc.). Met de huidige processor snelheden kan software RAID een snellere oplossing zijn dan hardware RAID. Hoewel de processor capaciteiten beter benut kunnen worden voor andere taken. Een ander nadeel van software RAID is, afhankelijk van welke schijf er uitvalt en de boot configuratie, dat de computer mogelijk niet in staat is te herstarten totdat de RAID compleet herbouwt is. Een hardware implementatie van RAID vereist een speciale RAID controller. Voor een desktop systeem kan dit in de vorm van een PCI uitbreidingskaart of een functie die het moederbord standaard biedt. In grotere RAID implementaties worden de controller en de schijven ondergebracht in een speciale externe behuizing. De schijven kunnen IDE, ATA, SATA, SCSI, Fibre Channel of een combinatie hiervan zijn. De controller is direct of indirect verbonden met de computer door middel van een of meerdere snelle SCSI, Fibre Channel of iSCSI verbindingen. Ook kunnen ze benaderd worden via een network attached storage (NAS). De controller handelt het disk management af en maakt pariteit berekeningen (noodzakelijk voor de meeste RAID levels). Deze optie geeft over het algemeen een betere performance en maakt de ondersteuning voor het besturingssysteem gemakkelijker. Een hardware implementatie ondersteunt meestal hot swapping wat de mogelijkheid biedt dat schijven vervangen kunnen worden terwijl het systeem werkt. Zie ook het hoofdstuk over Hot-Swap. In sommige gevallen kunnen hardware controllers kapot raken wat resulteert in data verlies. Hybride RAID oplossingen zijn erg populair geworden met de introductie van goedkope hardware RAID controllers. De hardware is een gewone schijf controller welke geen RAID mogelijkheden biedt. Tijdens het laden van het systeem is er een programma dat gestart wordt wat de gebruiker de mogelijkheid biedt om RAID op te zetten via het BIOS. Moderne besturingssystemen vereisen speciale RAID drivers om de verzameling als een apparaat te zien. Deze controllers doen eigenlijk alle berekeningen in de software en niet in de hardware en worden meestal fakeraids genoemd. In Redundantie

38

tegenstelling tot software RAID kunnen deze fakeraids niet meerdere controllers aansturen. Beide hardware en software versies kunnen Hot Spare ondersteunen. Zie ook het hoofdstuk Hot Spare. Dit is mechanisme om een schijf het werk over te laten nemen mocht een schijf uitvallen.

RAID 0 Een RAID 0 implementatie (ook bekend als Striped Set) verdeelt data gelijkmatig over twee of meerdere schijven zonder pariteit informatie voor redundantie. Belangrijk om te weten is dat RAID 0 niet een van de originele RAID levels is en niet redundant is. RAID 0 wordt normaal gesproken gebruikt voor verbeterde prestaties maar kan ook gebruikt worden om een aantal fysieke schijven te vormen tot een of meerdere grote virtuele schijven. Een RAID 0 kan gecreëerd worden met verschillende groottes aan opslag maar is beperkt tot de grootte van de kleinste schijf. Een combinatie van een 100 GB en een 120 GB schijf vormt dan een schijf van in totaal 200 GB en niet 220 GB. Stuk data : [0001][1001 ][1011 ][1100 ][0001][1011 ][1100 ][0001 ][1001 ]

Schijf 1

Schijf 2

Schijf 3

[0001] [1100] [1100]

[1001] [0001] [0001]

[1011] [1011] [1001]

RAID 0

Figuur 2.5: RAID 0, een stuk data wordt weggeschreven over 3 schijven. RAID 0 was niet gespecificeerd in de originele thesis maar een ideale implementatie van RAID 0 verdeeld I/O operaties in gelijke blokken en kan deze gelijk spreiden over meerdere schijven. RAID 0 implementaties met meer dan 2 schijven zijn ook mogelijk hoewel de betrouwbaarheid gelijk is aan de gemiddelde betrouwbaarheid van elke schijf, gedeeld door het aantal schijven in de verzameling. De betrouwbaarheid wordt gemeten in mean time to failure (MTTF) of mean time between failures (MTBF) en is ruim genomen omgekeerd evenredig aan het aantal schijven. Een set van 2 schijven is half zo betrouwbaar als 1 schijf, dit komt omdat het filesysteem gedistribueerd is over alle schijven. Als een schijf uitvalt kan het filesysteem niet omgaan met de grote dataverlies die dan optreed omdat de data striped over de schijven opgeslagen is. Data kan gerepareerd worden met speciale tools hoewel het hoogst waarschijnlijk incompleet en corrupt zal zijn. Een blok data kan technisch zo klein zijn als een byte maar wordt meestal een veelvoud van een harde schijf sector grootte van 512 bytes. Dit laat elke schijf onafhankelijk zoeken terwijl random data geschreven of gelezen wordt. Redundantie

39

Als alle benaderde sectoren op 1 schijf zitten dan is de zoek tijd gelijk aan die van een schijf. Als de benaderde sectoren gelijkmatig verspreid zijn over schijven kan de zoektijd verminderd worden tot de helft van 2 schijven, tot tweederde voor drie schijven etc. Aannemende dat het om identieke schijven gaat. Voor normale data toegangspatronen ligt de gemiddelde zoektijd tussen deze 2 extremen. De data overdracht snelheid van de verzameling is de overdracht snelheid van alle schijven bij elkaar opgeteld. RAID 0 is bruikbaar voor omgevingen waar het invoegen van schijven tijdrovend of onmogelijk is en redundantie niet relevant is. Een andere reden om voor RAID 0 te kiezen is het waar het besturingssysteem de beperkende factor is in het aantal schijven. Een andere populaire keuze hiervoor is de gewenste performance bij games, video of audio bewerking en data integriteit niet van belang is. Daarbij is het niet mogelijk Hot Swap te gebruiken omdat de data niet redundant over de schijven verdeeld is. Alle schijven zijn afhankelijk van elkaar.

Concatenatie (JBOD) Een concatenatie van schijven (Just a Bunch Of Disks JBOD) is geen genummerd RAID level. Het is een populaire methode voor het combineren van meerdere fysieke schijven tot een grote virtuele schijf. De schijven zijn als het ware geconcateneerd. In deze vorm is het eigenlijk het omgekeerde van partitioneren waarbij je een fysieke schijf in meerdere ‘logische’ schijven verdeeld. Voor JBOD zijn er minimaal 2 fysieke schijven benodigd. JBOD bestaat uit een Array of Independent Disks, zonder redundantie en is enigszins verwant aan RAID en wordt door de meeste RAID controllers ondersteund. Vaak wordt het gebruikt om schijven van ‘vreemde’ groottes tot een bruikbaardere virtuele schijf te maken. Hierbij moet men bijvoorbeeld denken aan een combinatie van een 4 GB, 15 GB en 6 GB schijf wat samen een virtuele schijf van 25 GB vormt wat meestal bruikbaarder is. JBOD is vergelijkbaar met de Logical Volume Manager (LVM) en Logical Storage Manager (LSM) in UNIX en UNIX gebaseerde besturingssystemen. JBOD is bruikbaar voor besturingssystemen die geen LVM of LSM ondersteunen. Het verschil van JBOD en LSM / LVM is dat het herplaatsen van adressen tussen logische adressen, van de geconcateneerde schijf, en het fysieke adres op de schijf gedaan wordt door de RAID hardware in plaats van in de kernel van het besturingssysteem zoals bij LVM en LSM het geval is. JBOD heeft ten opzichte van RAID 0 een voordeel bij de uitval van een schijf. Als er bij RAID 0 een schijf uitvalt treed er meestal volledige data verlies op. Wanneer dit bij JBOD gebeurt treed er alleen data verlies op bij de uitgevallen schijf. De overgebleven schijven blijven leesbaar. Echter heeft JBOD niet de snelheidswinst welke RAID 0 wel heeft. Redundantie

40

RAID 1 Een RAID 1 implementatie creëert een exacte kopie (ook wel mirror genoemd) van een set data op twee of meer schijven. Zie figuur 2.6. Dit is bruikbaar wanneer de lees snelheid belangrijker is dan het minimaliseren van de opslag capaciteit welke gebruikt wordt voor redundantie. De capaciteit van de schijf is zo groot als de kleinste schijf is. Een klassieke RAID 1 mirrored pair bevat 2 schijven, welke de betrouwbaarheid met een factor 2 vergroot ten opzichte van het geval er een schijf gebruikt wordt. Het is echter ook mogelijk om meer dan 2 schijven te gebruiken voor kopieën. Elke schijf van de array kan onafhankelijk benadert worden wanneer een schijf uitvalt. De betrouwbaarheid is lineair aan het aantal schijven wat in de array zit. Om de volledige voordelen van redundantie in RAID 1 te krijgen wordt het aangeraden om onafhankelijke disk controllers te gebruiken voor elke schijf. In de praktijk wordt dit splitting of duplexing genoemd.

Schijf 1

Schijf 2

[0001] [1001] [1011] [1100] [0001]

[0001] [1001] [1011] [1100] [0001] RAID 1

Figuur 2.6: RAID 1, ieder blok [….] bevat op iedere schijf exact dezelfde data. Bij leesbewerkingen kunnen de schijven onafhankelijk benaderd worden. Zoals bij RAID 0 wordt de gemiddelde zoektijd met de helft gereduceerd maar omdat elke schijf een exacte kopie heeft van de data kunnen de opgevraagde sectoren altijd gelijk verspreid worden over de schijven waardoor de zoektijden laag blijven. Ook de overdrachtsnelheid wordt verdubbeld. Voor 3 schijven wordt de zoektijd eenderde en de overdrachtsnelheid verdrievoudigd ten opzichte van 1 schijf. De enige beperking is hoeveel schijven verbonden kunnen zijn met de controller en de maximale overdrachtsnelheid. Veel oudere IDE RAID 1 kaarten lezen in het paar maar van 1 schijf af zodat de lees snelheid die van een enkele schijf is. Sommige oudere RAID 1 implementaties lezen van beide schijven tegelijk en vergelijken de data om fouten op te sporen waardoor ook hier de lees snelheid gelijk is aan die van een enkele schijf. Fout detectie en correctie op moderne schijven maakt dit minder bruikbaar in omgevingen welke een normale commerciële beschikbaarheid vereisen. Ook bij het schrijven is de snelheid gelijk aan die van een enkele schijf, omdat alle schijven de data moeten opslaan. Een van de vele beheervoordelen van RAID 1 is bijvoorbeeld de mogelijkheid, in omgevingen waar het systeem altijd moet draaien, de mogelijkheid tot “Split the mirror”. Hierbij wordt een schijf inactief gezet om een backup te maken van die schijf. Daarna wordt de schijf terug geplaatst waarna de mirror opnieuw gebouwd wordt. Dit vereist een programma die dit ondersteund. Redundantie

41

Deze procedure is ook minder kritisch in vergelijking met de snapshot mogelijkheid van sommige file systemen. Hierbij is een bepaalde ruimte gereserveerd om een kopie van een bepaald moment te maken. Een alternatief zou een set van schijven kunnen zijn die dezelfde functie vervullen zoals tape backups doen. Een andere toepassing is een extra kopie van een volume, bekend onder de naam Business Continuance Volume (BCV), welke gesplitst word van de RAID set en onafhankelijk gebruikt kan worden. In sommige implementaties is het zelfs mogelijk dat de kopieën gespleten worden en dan incrementeel bijgewerkt worden in plaats van dat het in zijn geheel bijgewerkt moet worden. Als een bedrijf genoeg geld over heeft voor een volledig redundante RAID oplossing is dit de beste maar tevens de duurste oplossing.

RAID 2 Een RAID 2 verdeelt (striped) data in bits in plaats van blokken over de schijven. Hierbij wordt gebruik gemaakt van een Hamming code voor fout correctie. De schijven zijn gesynchroniseerd met de controller om perfect te functioneren. Dit is het enige originele RAID level wat niet gebruikt wordt maar waarbij wel extreme hoge dataoverdracht snelheden mogelijk zijn. Hamming codes kunnen enkele en dubbel-bit fouten detecteren maar alleen enkele-bit fouten corrigeren.

RAID 3 Bij een RAID 3 configuratie wordt op byte-niveau verdeeld over meerdere schijven waar 1 schijf gebruikt wordt als pariteit schijf. In de praktijk komt RAID 3 niet veel voor en een nadeel van RAID 3 is dat er niet meerdere aanvragen tegelijkertijd afgehandeld kunnen worden. Dit komt omdat elke enkele blok van data verspreid wordt over alle schijven in de set en verblijft op dezelfde locatie. Dus elke I/O operatie vereist activiteit op elke schijf. Schijf 1

Schijf 2

Schijf 3

Schijf 4

[0001] [1001] [1011] [1100] [0001]

[0001] [1001] [1111] [1100] [0001]

[0001] [1001] [1011] [1100] [0101]

[P1-3] [P4-6] [P1-3] [P4-6] [P7-9]

RAID 3

Figuur 2.7: RAID 3, twee stukken data (blauw & zwart) met pariteit op schijf 4. In het voorbeeld hierboven moet de bij een gelijktijdige aanvraag van 2 stukken data, blauw en zwart, de een wachten op de ander. Na het antwoord van de eerste aanvraag kan pas gezocht worden voor de tweede aanvraag.

Redundantie

42

RAID 4 Ook RAID 4 gebruikt een vorm van het verdelen (striping) van data over meerdere schijven met 1 pariteit schijf. Het verdelen van data gebeurt op blok-niveau en lijkt op RAID 3 behalve dat het op blok-niveau verdeelt en niet op byte-niveau. Dit geeft de mogelijkheid voor ieder lid van de set schijven onafhankelijk te kunnen werken wanneer maar 1 blok data aangevraagd wordt. Als de controller het toelaat kan een RAID 4 set meerdere leesbewerkingen tegelijkertijd afhandelen.

Schijf 1

Schijf 2

Schijf 3

Schijf 4

[0001] [1101] [1011]

[0001] [1001] [1111]

[0001] [1001] [1011]

[P1-3] [P1-3] [P1-3]

RAID 4

Figuur 2.7: RAID 4, er hoeft niet gewacht te worden tot een andere schijf klaar is. Zoals het figuur 2.7 illustreert hoeft een leesbewerking van het blauwe blok op schijf 1 niet te wachten op een gelijktijdige leesbewerking van het zwarte blok op schijf 2. De aanvragen kunnen gelijktijdig plaatsvinden en afgehandeld worden.

RAID 5 In een RAID 5 configuratie wordt, zoals RAID 4 ook doet, de data verdeelt (striped) over verschillende schijven. In tegenstelling tot RAID 4 voert het de pariteit berekeningen uit welke gedistribueerd over alle schijven opgeslagen worden. RAID 5 is populair geworden dankzij de lage kosten van redundantie. Meestal wordt RAID 5 geïmplementeerd met speciale hardware welke de pariteit berekeningen uitvoert omdat dit nogal rekenkrachtige bewerkingen zijn.

Schijf 1

Schijf 2

Schijf 3

Schijf 4

[0001] [1101] [1011] [P1-3]

[0001] [1001] [P1-3] [1000]

[0001] [P1-3] [1011] [1110]

[P1-3] [1001] [1111] [1010]

RAID 5

Figuur 2.8, RAID 5 met gedistribueerde pariteit. Redundantie

43

Een het voorbeeld hierboven kan een aanvraag voor het blauwe blok op schijf 2 afgehandeld worden. Een gelijktijdige aanvraag welke op schijf 2 plaats moet vinden moet wachten op de eerste aanvraag. Een aanvraag voor het groene blok op schijf 3 kan gelijktijdig afgehandeld worden. Iedere keer als een blok geschreven word naar schijf in een RAID 5 configuratie moet het pariteit blok opnieuw berekend en herschreven worden binnen dezelfde stripe (in het figuur weergeven in de vorm van de kleuren blauw, rood, zwart en groen). Een blok wordt vaak opgesteld uit meerdere opeenvolgende sectoren op een schijf. Een serie van blokken wordt collectief een stripe (in dit geval blauw, rood, zwart en groen) genoemd. Voor een kleine schrijf handeling kan dit betekenen dat de oude pariteit gelezen moet worden, de oude data gelezen moet worden, de nieuwe pariteit berekend en geschreven moet worden en de nieuwe data weggeschreven wordt. De term gedistribueerde pariteit blokken is te danken aan het feit dat de pariteit blokken gelijkmatig verdeeld worden over de set van schijven. RAID 5 schrijf bewerkingen zijn duur vanwege het feit dat het veel schijf operaties en data uitwisseling met zich meebrengt tussen de schijven en de controller. De pariteit blokken worden niet gelezen wanneer er data gelezen wordt, omdat deze onnodige overhead verzorgen en een negatief effect hebben op de performance. De pariteit blokken worden wel gelezen wanneer een data sector een cyclic redundancy check (CRC) fout oplevert. In dit geval zal de sector in dezelfde relatieve positie binnen elk van de overgebleven datablokken in de stripe en binnen het pariteit blok in de stripe worden gebruikt om de kapotte sector te reconstrueren. De CRC fout is dus verborgen voor de computer. Als een schijf faalt in de set, worden de pariteit blokken van de overgebleven schijf rekenkundig gecombineerd met de data blokken van de overgebleven schijven om de data direct te reconstrueren van de kapotte schijf. Dit wordt ook wel Interim Data Recovery Mode genoemd. De computer weet dat een schijf defect is geraakt, het besturingssysteem geeft de beheerder dan een melding dat de schijf vervangen dient te worden terwijl alle programma’s blijven draaien op de computer. Lezen en schrijven naar de schijven set kan nog steeds met een kleine terugval in performance. Het verschil tussen RAID 4 en RAID 5 is dat bij interim data recovery mode, RAID 5 mogelijk iets sneller is dan RAID 4, omdat de CRC en pariteiten van de kapotte schijf niet herberekent hoeven te worden in tegenstelling tot RAID 4. Wanneer er in RAID 5 één pariteit blok gebruikt wordt per stripe zal bij 2 defecte schijven volledige data verlies optreden. In theorie is het maximum aantal schijven voor redundantie in een RAID 5 set onbeperkt maar vaak wordt een beperkt aantal van schijven gebruikt. Als het aantal schijven in een RAID 5 set vergroot wordt zal de mean time between failure (MTBF) dalen ten opzichte van een enkele schijf. Wanneer een tweede schijf uitvalt binnen de tijd dat een eerdere schijf uitgevallen is, gedetecteerd dat deze uitgevallen is, vervangen is en compleet herbouwt is, kan het nuttig

Redundantie

44

zijn meerdere schijven in te zetten, bijvoorbeeld een minimum van 3. RAID 6 is een alternatief welke dubbele pariteit beveiliging biedt. Een nadeel van RAID 5 implementaties is dat ze lijden aan een mindere performance wanneer ze te maken hebben met een grote workload. Dit kunnen vele kleine schrijf bewerkingen zijn waarbij elke keer de pariteit herlezen, herberekent en herschreven moet worden. Complexere implementaties hebben vaak en cache geheugen om de negatieve impact op de performance te beperken van incrementele pariteit updates. Wanneer een systeem uitvalt terwijl er actieve schrijf bewerkingen plaatsvinden, zal de pariteit van de stripe inconsistente data bevatten. Als dit niet gedetecteerd en het datablok niet gerepareerd word, kan dit tot data verlies leiden, omdat de incorrecte pariteit gebruikt wordt om het missende blokje in de stripe her te berekenen. Dit probleem wordt vaak omschreven als write hole. Er zijn een aantal technieken om hiertegen te beschermen bijvoorbeeld door de geldige pariteit tijdelijk op te slaan op de opslag controller tijdens de schrijfbewerkingen.

RAID 6 RAID 6 is een uitbreiding op RAID 5 welke een extra pariteit blok toevoegt en was niet een originele RAID versie. Het voegt dus 2 pariteit blokken toe waarbij de data verdeeld wordt over meerdere schijven op blok-niveau. Zoals bij RAID 5 worden de pariteiten gedistribueerd in de stripes op verschillende plekken in elke stripe opgeslagen. Zoals in figuur 2.9 wordt weergegeven worden de pariteiten (respectievelijk P en Q) op meerdere schijven opgeslagen.

Schijf 1

Schijf 2

Schijf 3

Schijf 4

Schijf 5

[0001] [1101] [1011] [P1-3]

[0001] [1001] [P1-3] [Q1-3]

[0001] [P1-3] [Q1-3] [1110]

[P1-3] [Q1-3] [1011] [1000]

[Q1-3] [1001] [1111] [1010]

RAID 6

Figuur 2.9, RAID 6 waarbij de pariteiten op meerdere schijven verdeeld zijn. RAID 6 is inefficiënt wanneer er een klein aantal schijven gebruikt wordt. Als het aantal schijven groter wordt de kans weer groter dat meerdere schijven tegelijk uitvallen. RAID 6 levert bescherming tegen dubbele schijf fouten en fouten tijdens het herbouwen van een enkele schijf. In het geval dat er een set is, is het aannemelijker om een hot-spare schijf te gebruiken. De capaciteit van een RAID 6 set is N-2, waar N het totale aantal schijven in de set is. RAID 6 levert geen negatieve invloed op lees operaties, maar heeft wel negatieve invloed bij schrijf bewerkingen door de overhead welke de pariteitberekeningen met zich meebrengen. Redundantie

45

Nested RAID Veel opslag controllers geven de mogelijkehid om RAID levels te combineren (nesting). Dit betekent dat een RAID vorm gebruikt kan worden als de basis voor een andere RAID vorm in plaats van een fysieke schijf te gebruiken. Op deze wijze worden RAID sets gelaagd op elkaar met de fysieke schijven aan de onderkant. Nested RAID configuraties worden vaak gekenmerkt door de cijfers die voor de RAID versies staan te combineren, soms met een ‘+’ in het midden. Bijvoorbeeld RAID 10 (of RAID 1+0) bestaat conceptueel uit meerdere RAID 1 sets met een RAID 0 versie bovenop. Dit wordt geïllustreerd in figuur 2.10. RAID 0

RAID 1

RAID 1

Schijf 1

Schijf 2

Schijf 3

Schijf 4

[0001] [1101] [1011] [1010]

[0001] [1001] [1101] [1010]

[0001] [1011] [1100] [1110]

[0000] [0100] [1011] [1000]

Nested RAID

Figuur 2.10: Nested RAID combineert RAID versies (getoond RAID 1+0). Een gecombineerde RAID versie kan een zijn welke een RAID type met redundantie combineert met een RAID versie welke een verhoogde snelheid levert. In dit geval is het aannemelijk RAID 0 aan de top te hebben en een redundante RAID versie onderaan, omdat minder schijven herberekent hoeven te worden wanneer een schijf uitvalt.

Redundantie

46

3

Bronvermelding

Boeken Cisco Press CCDP 2004

Self-Study: Designing Cisco Network Architectures (ARCH) Self-study: Building Cisco Multilayer Switched networks (BCMSN) 2005 Self-study: Building Scalable Cisco internetworks (BSCI) 2005 Self-Study: Building Cisco remote Acces Networks (BCRAN) 2005

Thomas A. Limocelli The practice of system and network administration 2002 Papers Rob Prickaerts Architecture and Management, Tennessee Technological University 2005 Internet http://www.wikipedia.org/ http://www.cisco.com/ http://www.ecommercetimes.com/ http://www.faqs.org/rfcs/ http://www.foundry.com/ http://www.microsoft.com/ http://www.colt.net/ http://www.supinfo-projects.com/

Redundantie

47