Netwerktransport heeft altijd om twee verschillende technologieën gedraaid, namelijk FC (Fibre Channel) en ethernet. Deze zijn te vergelijken met twee treinsporen met verschillende spoorwijdte: een verbinding leek er niet in te zitten.

Dat terwijl bijna iedereen het erover eens is dat een bijeengebracht netwerk flinke financiële en administratieve voordeeltjes kan brengen. Maar elke keer dat ze keken naar mogelijke vereenvoudigingen van de infrastructuur in het rekencentrum, kregen klanten te maken met louter ontmoedigende en dure mogelijkheden. Denk aan het vernietigen van hun eerdere FC-investeringen, of het moeten uitbreiden van het FC-netwerk naar iedere server en iedere applicatie.

Maar begin dit jaar kwamen de eerste signalen binnen vanuit de industrie dat we de twee 'spoorwegen' eindelijk met elkaar konden verbinden. Het eerste teken van verandering kwam vanuit Brocade, die de DCX aankondigde in januari. Niet veel later kwam FCoE (een kindje van Nuova Systems, een afsplitsing van Cisco) tot wasdom met de Nexus 5000 switches. Daarmee, zo werd beloofd, kwamen de twee belangrijkste soorten netwerken onder dezelfde beheerparaplu.

Hoe verschillen de methodes van Brocade en Cisco met elkaar? Goed, hierna hou ik eindelijk op met mijn spoorweganalogie, maar zie de eerste methode als een samenkomst van twee soorten rails, en de tweede als een bij elkaar gebracht soort spoorweg, waarover dezelfde soort goederentrein dendert.

Feitelijk schuift FCoE de twee protocollen naadloos in elkaar, zodat het mogelijk wordt om elke applicatieserver te bereiken die is uitgerust met een nieuw soort adapter, treffend de Converged Network Adapter (CNA) genaamd. Een CNA transporteert eigenlijk beide protocollen, ethernet en FC op een enkele 10G poort, waardoor het aantal benodigde serveradapters met de helft wordt teruggebracht. Net zo belangrijk is ook dat het aantal verbindingen en switches flink minder wordt.

Een ander belangrijk component van de FCoE-architectuur is uiteraard de Nexus 500 switch, een apparaat dat min of meer een brug vormt tussen de FC- en ethernetnetwerken met compatibele poorten voor elk van de technologieën. Daarbij komt dat een FCoE-switch toevoegen nu met geen of minimale ingrepen in het bestaande storagenetwerk kan worden uitgevoerd. Dat zou de interesse moeten wekken van leveranciers en klanten.

Voor het eerste model, de Nexus 5020, claimt Cisco een snelheid van boven de 1 Tbit per seconde met een latency die te verwaarlozen is. In combinatie met de indrukwekkende serie 10G poorten maakt het een lekker apparaat om te hebben wanneer servervirtualisatie wordt toegepast. Om een Cisco-topman aan te halen op wat misschien een paradox is, met FCoE is een server op te zadelen met zo'n beetje elke verkeerslast.

De kern van de Nexus

Een switch die de diensten van ethernet en FC over dezelfde draad belooft, zonder pakketverlies en al te veel latency, is zeker de moeite van het recenseren waard. Maar al snel werd het duidelijk dat het nodig was om meer apparatuur bij elkaar te brengen dan praktisch te verzenden is per post. Daarom ben ik naar het terrein van Nuova Systems getogen in San Jose, om daar mijn tests uit te voeren.

Samen met de 10G ethernetpoorten is mijn testexemplaar uitgerust met een paar native FC poorten, wat het mogelijk maakt om te kijken hoe het ding reageert als het een native FC switch emuleert. Op het programma stond ook het bekijken van de beheerfuncties van de Nexus 5000, en het draaien van benchmarks op latency, I/O operaties en doorvoersnelheid.

De Nexus 5020 is een 2U racksysteem met een verbazingwekkende hoeveelheid sockets: veertig maar liefst. Elke socket kan een ethernetpoort aan op 10G. Met een optionele module (er passen twee in de switch) valt de connectiviteit uit te breiden met zes extra ethernet 10G-poorten, acht extra FC-poorten of een combinatie van vier FC- en vier110G ethernetpoorten. Deze sockets hoeven echter niet allemaal gevuld te worden. Mijn testkast had bijvoorbeeld slechts vijftien actieve 10G-poorten en vier actieve FC poorten. Toen deze test werd uitgevoerd ondersteunde de Nexus 5000 voor alle FC-snelheden tot (niet inclusief) 8G.

Normaalgesproken wordt de 5020 in hetzelfde rek of het rek ernaast geplaatst als waar de applicatieserver staat. Aangenomen dat het om een robuuste configuratie met twee 10G-verbindingen per server gaat, dan kunnen twee Nexus 5000 switches verbonden worden met veertig servers, en is er met de uitbreidingsmodules nog ruimte over.

De voorkant van de 5000 is uitgerust met vijf grote, altijd draaiende en zeer luidruchtige ventilatoren. Met slechts één voeding (het is mogelijk om met twee PSU's te werken) mat ik een verbruikt vermogen van 465 watt. De Nexus bleef doordraaien als ik een van de ventilatoren verwijderde, maar bij het weghalen van een tweede schakelde de switch zich uit. De drie overige ventilatoren bleven wel doordraaien om de interne onderdelen van koeling te voorzien.

Eenmaal opnieuw aangesloten, begonnen de ventilatoren direct weer te draaien, maar de switch zelf moest om te herstarten eerst een stroomcyclus ondergaan. Hiervan gebruik makende (het is expres zo ontworpen), mat ik op alleen de draaiende ventilatoren 243 W, waaruit volgt dat de switch zelf dus het verschil van die twee waardes verbruikt. In mijn configuratie dan.

Het vermogen zal uiteraard stijgen naarmate er meer verbindingen worden gelegd, maar het verbruik dat ik mat was in dezelfde orde van grootte als sommige 20-poortige 10G-switches van andere leveranciers.

Regels en nog eens regels

De meest belangrijke functionaliteit die de Nexus 5000 te bieden heeft, en wat het onderscheidt van andere switches met ondersteuning voor een enkel protocol, is dat ethernet en FC slechts twee van de ondersteunde applicaties zijn die zijn te beheren vanuit dezelfde interface. Het is daarom belangrijk om te weten dat de Nexus een nieuw OS draait, NX-OS. Deze brengt volgens Cisco het beste van het op ethernet gerichte IOS en het op FC gerichte SAN-OS samen.

Beheerders kunnen kiezen voor een krachtige CLI of een grafische interface gebaseerd op Fabric Manager. De taken van de switch kunnen eenvoudig worden verdeeld in meerdere soorten rollen, elk met een eigen login en beperkt tot een specifieke omgeving zoals die gedefinieerd wordt door een superadmin. Dit is een onmisbare functie voor het scharen van meerdere beheerdomeinen onder een en dezelfde vlag.

Deze en andere instellingen worden gedreven door policies, wat het beheer eenvoudig en transparant maakt. Een andere opvallende functie is de mogelijkheid om dienstklassen te definiëren die zelf verschillende applicaties kunnen indelen.

Met een simpel commandeo als 'sh policy-map interface ethernet 1/1' worden bijvoorbeeld alle verkeersstatistieken over de betreffende poort op een rij gezet, gesorteerd naar class of service (CoS) en elk met zijn eigen gegevens voor inkomende en uitgaande pakketten. Door een bepaalde CoS te combineren met de juiste policy kan een admin niet alleen het verkeer monitoren, maar ook ook controle uitoefenen over waar pakketjes naartoe gerout worden en hoe. Load balancing is een typische toepassing waar dit in uitblinkt, maar er zijn er meer denkbaar, bijvoorbeeld het automatisch laten toewijzen van MTU's aan verschillende vormen van verkeer.

De NX-OS maakt een aantal ingewikkelde zaken redelijk eenvoudig, zoals het spiegelen van verkeer tussen de ene en de andere interface, op dezelfde of een andere VLAN. Een dergelijke instelling kan nuttig zijn voor gevoelige applicaties, zoals remote monitoring, maar kan ook gebruikt worden om het effect van een nieuwe applicatie op een productie-VLAN te testen.

Een juiste policy definiëren kan er ook voor zorgen dat het FC-verkeer, of eigenlijk elk soort verkeer dat door de 5000 gestuurd wordt, ooit een frame verliest. Een frame laten vallen is een doodzonde als aan een kant van de verbinding een opslagapparaat staat aangekoppeld, en ook andere prestatiegevoelige applicaties profiteren van ononderbroken transport.

Ik was nogal verrast over de weinige commando's die nodig zijn om dit zo in te stellen:

class-map critical

match cos 4

policy-map policy-pfc

class critical

pausen o-drop

system qos

service-policy policy-pfc

In gewoon Nederlands betekent dit dat het nooit een frame mag laten vallen, en dat de doorvoer gepauzeerd moet worden als het allemaal iets te snel gaat.

Ik moet er even bij vermelden dat PFC staat voor Priority Flow Control, een functionaliteit die aan de basis van FCoE staat. Het maakt het voor ethernet mogelijk om opstoppingen zonder dataverlies te verwerken door de stroom van inkomende pakketjes te pauzeren wanneer dit nodig is.

Het volgende commando dat ik gebruikte, en dat ik niet laat zien, was om die policy toe te wijzen aan twee poorten op mijn switch.

Hoe prop ik een 10G-lijn vol?

Het testen of de policy daadwerkelijk werkt was ingewikkelder dan het opstellen ervan, en moest gebeuren met de IP Performance Tester verkeersgenerator van Ixia. Een van de problemen die ik moest oplossen was hoe ik goed verkeer kon genereren op mijn 10G-verbindingen. De IP Performance Tester is hiervoor een waardevolle tool.

Voor mijn PFC-test heb ik Ixia ingesteld om genoeg verkeer te genereren zodateen mate van opstoppoing zonder PFC normaalgesproken tot pakketverlies leidt. De switch slaagde voor in stijl voor deze test, zonder enig verlies, iets dat bewijst dat ook ethernet een betrouwbare lossless protocol kan zijn. Dit was zonder twijfel het meest ingrijpende script dat ik op de Nexus draaide. De switch levert meer krachtige functies, zoals een gegarandeerde doorvoersnelheid, automatisch beheer van bandbreedte en een geautomatiseerde verkeersspanne.

Maar het is PFC dat van FCoE een bruikbaar protocol maakt om het gat tussen applicatieserver en storage op te vullen. Dat maakt op de Nexus 5000 op zijn beurt een broodnodig component in projecten waarin het datacentrum wordt geconsolideerd.

Eén vraag bleef tijdens mijn evaluatie onbeantwoord: De Nexus 5000 heeft bewezen geschikt te zijn als verbindingspunt tussen servers en storage in een bij elkaar gebrachte omgeving, maar heeft het wel de benodigde bandbreedte en reactievermogen?

Om dat te beantwoorden heb ik de testopstelling wat gewijzigd. De Nexus 5020 werd nu aangesloten op acht hosts waarop NetPipe draait. Dat is een bijzondere benchmarktool voor prestaties, en uiterst geschikt voor switches omdat het ook end-to-end (of host-to-host)-prestaties kan meten. De resultaten worden in Excel-formaat weergegeven, samen met de mogelijke cijfers voor verschillende transfergroottes. Een samenvatting over wat NetPipe mogelijk maakt staat in dit figuurtje.

Het is mogelijk om NetPipe zo in te stellen dat het dataverkeer one-way of in beide richtingen meet, en ook geleidelijk naar verschillende groottes van de transfers toe gaat. De doorvoersnelheid wordt in megabytes per seconde weergegeven, de latency in microseconden. Mijn tests liepen van 1 byte tot 8.198 bytes, maar voor de duidelijkheid geef ik slechts de resultaten van een paar groottes weer. Ik heb ook zowel zonder als met extra verkeer getest.

Als laatste, om een meer gevoel te krijgen voor het effect van de switch zelf op de doorvoersnelheid en de latency, heb ik dezelfde test uitgevoerd bij een directe verbindingtussen twee hosts.

De resultaten voor doorvoersnelheid heb ik hier, en hier de latencycijfers.

Het is interessant om te zien hoe de doorvoer geleidelijk hoger wordt en zelfs de theoretische snelheid van 10G benadert. De latencycijfers (lager is beter) is vanzelfsprekend het meest belangrijke bewijs voor de responstijden van de switch. Zelfs al nemen we de beste resultaten op het moment dat de 5020 in het netwerk hangt, dan blijven de verschillen met een directe verbinding tussen de 3-3.5 microseconden, wat dus de latency is die door de switch veroorzaakt wordt.

Dit ligt niet alleen erg dicht bij het cijfer dat Cisco ervoor geeft, maar het is waarschijnlijk de kleinste latency die mogelijk is tussen applicatie en data.

Conclusie

Met producten als de Nexus 5000, die de eerste implementatie herbergen van nieuwe technologie, is het moeilijk om de technologie zelf te scheiden van het product. Daarom zie ik de Nexus 5020 en FCoE als een geheel, en dat klopt ook, want er is geen andere switch waarmee het protocol te implementeren valt.

Als ik beide delen dan toch uit elkaar trek, dan hebben de stukken elk hun eigen voordelen. Ik vind de samentrekking die FCoE teweeg brengt in het netwerktransport aantrekkelijk, net als dat ik de snelheid en de geringe invloed van de Nexus op de netwerkprestaties heeft een goede zaak vind.

Maar de Nexus 5000 blijft een eerste versie van een product, en hoe goed het ook is uitgebalanceerd, het valt te verwachten dat toekomstige versies de lat hoger gaan leggen. Als het gaat om de technologie, dan kan gesteld worden dat het grootste compliment voor FCoE is dat Brocade een eigen Nexus 5000-achtige oplossing op de markt gaat brengen. Kennelijk kan de windvaan voor de storagewereld nog steeds alle kanten op draaien.

Vertaling: Michiel van Blommestein (origineel) Bron: Techworld