Met alle hypes rondom CEE/FCoE en netwerkconvergentie is het wellicht eens goed om stil te staan bij een netwerkconvergentie-oplossing die al sinds midden jaren '90 beschikbaar is en die tot op de dag van vandaag wordt toegepast binnen het datacenter: IPoFC, ofwel IP over Fibre Channel.
CEE en FCoE zullen zeker hun plek krijgen in het datacenter, het zal echter nog geruime tijd duren voor het breed ingezet wordt. Eén van de redenen hiervoor is het ontbreken van een aantal key functies zoals bijvoorbeeld routering en load balancing (TRILL -Transparent Interconnection of Lots of Links) die pas medio 2010 verwacht worden. Waarom zouden we nu FC gaan vervangen door een nieuwe technologie die probeert dezelfde karakteristieken als FC te hebben ten aanzien van betrouwbaarheid, schaalbaarheid en performance, maar die zich nog lang niet bewezen heeft en waarvoor de volledige standaarden nog niet zijn ingevuld door commissies als IETF, ANSI T11 en IEEE?
Zoals het IP-protocol op een Ethernet-segment gemapped kan worden, zo kan men IP ook mappen over verschillende andere data link layers zoals ADSL, GPRS, SONET/SDH, ATM en een FC-netwerk. Dus als men snelle performance wil voor IP-verkeer, waarom zouden we dan niet eens kijken wat er met FC mogelijk is?
Een FC-netwerk beschikt over een aantal zeer belangrijke karakteristieken die men in CEE/FCoE wil implementeren, te weten high performance, low latency en lossless. Het lijkt dus logisch om eens te zien of we het bestaande FC-netwerk ook als transportmedium voor IP-verkeer kunnen inzetten. Vrijwel alle HBA-leveranciers hebben hardware- en softwareversies beschikbaar die IPoFC ondersteunen. Omdat IPoFC geen directe interactie heeft met storage arrays, is er geen support noodzakelijk vanuit die hoek (interoperability testing), dat maakt het leven ook nog eenvoudiger.
Eén van de voordelen is dat men met FC meer keuze heeft uit beschikbare snelheden dan bij Ethernet, waardoor de applicatiebehoefte beter afgestemd kan worden. Met Ethernet als datalink layer is men beperkt tot 1 of 10 Gbit, waarbij de keuze voor een 10 Gbit Ethernet infrastructuur hoge hardware-investeringen vergt en verder hoge kosten voor energie, koeling, SFPs, etc. Bij FC kan men vandaag de dag kiezen uit 1, 2, 4, 8 en 10 Gbit FC en binnen afzienbare tijd komt 16 Gbit FC beschikbaar. Vraag blijft natuurlijk of de server de data vandaag de dag met die snelheden kan aanbieden.
Indien men gebruik maakt van HBA's die virtual channels ondersteunen, dan kan men de quality of service (QoS) gebruiken om verschillende performance-karakteristieken toe te wijzen aan IPoFC- en FC-verkeer door dezelfde HBA. Virtual channel (VC) en QoS kan ook worden gebruikt voor bijvoorbeeld VM instances (vanaf ESX 3.5). Verschillende performance-testen zijn uitgevoerd met twee moderne Linux-servers die beiden waren uitgerust met twee 4 Gbit FC HBA's en twee keer een 1 Gbit NICs uitgerust met TOE (TCP Offload Engine). Allereerst bleek uit de tests dat het uitstekend mogelijk is om gelijktijdig FC en IP over dezelfde HBA te laten lopen waarmee bewezen is dat netwerkconvergentie vandaag al mogelijk is en we dus niet hoeven te wachten tot CEE/FCoE volledig beschikbaar is. Uit de performance-testen bleek dat IPoFC over 4 Gbit FC niet zoals verwacht vier keer sneller was dan 1 Gbit Ethernet, maar een factor twaalf meer payload kon verwerken! Het CPU-verbruik in de test met IPoFC liep op tot 90 procent en dit kwam vrijwel geheel voor rekening voor het aansturen van de applicatie die de IOs genereerde. Met andere woorden: zeer weinig protocol overhead voor IPoFC. Het CPU-verbruik was 30 procent voor de TOE (voornamelijk veroorzaakt door Ethernet driver overhead). Verder bleek dat performance voor IPoFC beperkt werd door de snelheid waarmee de applicatie de interface kon aansturen.
Omdat IPoFC minder CPU overhead heeft dan Ethernet TOE kan men dus meer CPU-resources gebruiken om applicaties te draaien en kan men tegelijkertijd meer IOs verwerken. Over de gehele linie zal dit leiden tot minder infrastructuurkosten, ofwel betere TCO, of bijvoorbeeld meer virtuele servers per fysieke server hosten.
FC-frames zijn efficiënter dan standaard Ethernet of zelfs Jumbo-frames omdat ze een betere ratio payload per frame header hebben. Verder zijn de frame headers kleiner en eenvoudiger te processen wat resulteert in minder processing overhead tijdens het transport. Het FC-protocol kan 65.000 frames in één enkele CPU-sequence verwerken wat met een 2K-frame resulteert in één enkele sequence van 130 MB data. Een Ethernet-stack met Jumbo-packets zouden 13.000 sequences nodig hebben om dezelfde hoeveelheid data te versturen hetgeen een behoorlijke CPU-overhead met zich mee brengt.
Dezelfde discussie geldt overigens ook voor FC versus FCoE, puur FC zal ook in die vergelijking vele malen efficiënter zijn voor large-block storageverkeer en ook efficienter voor large block IP-verkeer (factor 3 tot 8); FCoE heeft namelijk soortgelijke beperkingen als traditioneel IP.
IPoFC is ideaal voor streaming IP-omgevingen, LAN free back-upapplicaties is waarschijnlijk de eerste toepassing waar men aan denkt voor IPoFC, maar er zijn meer toepassingen waar IO-performance en korte 'round trip delay' grote performance-winst kan opleveren. Andere toepassingen zijn data base sharing, high availability clustering, HPC, virtual server platforms, VM mobility, etc.
Niet alle besturingssystemen ondersteunen IPoFC op dit moment maar het is zeker de moeite waard om eens te onderzoeken wat er wel mogelijk is!
