RoCE v1 vs RoCE v2: L2 eller L3 — vilken version ska du välja?

RoCE v1 vs RoCE v2: L2 eller L3 — vilken version ska du välja?

RoCE v1 och RoCE v2 är båda RDMA-protokoll för Converged Ethernet, men de är byggda för olika nätverkslager. RoCE v1 är ett renodlat Ethernet-protokoll på L2 med Ethernettyp 0x8915, och det måste finnas i samma broadcast-domän som målnoden. RoCE v2 är i stället inkapslat i UDP/IP, använder destination port 4791 och är routbart över L3, vilket gör det användbart i större kluster och routingbaserade datacenter.

Den väsentliga prestandaskillnaden är header-overhead. RoCE v2 lägger till en IP-header och en UDP-header framför RDMA-meddelandet, medan RoCE v1 klarar sig med ett kortare Ethernet-ramverk. Fler byte per paket som går till protokoll istället för användardata innebär lägre effektiv bandbredd, särskilt när MTU är liten. Skillnaden blir påtaglig först på höghastighetslänkar, och den minskar med större ramar som jumbo frames (MTU 9000).

RoCE i korthet

RoCE står för RDMA over Converged Ethernet och låter två datorer läsa och skriva i varandras minne utan att belasta CPU:n på mellanvägen. Alla versioner av RoCE bygger på samma underliggande InfiniBand-meddelanden, som finns i en Base Transport Header (BTH) tillsammans med en kontrollsumma för dataintegritet. Skillnaden mellan v1 och v2 handlar framför allt om hur meddelandet paketeras i nätverket och om det får korsa routrar.

RoCE v1: L2 och icke-routbart

RoCE v1 skickar RDMA-paket direkt över Ethernet-tråden utan IP-inkapsling. Därför kan RoCE v1-trafik inte passera routrar eller VLAN-gränssnitt. Målnoden måste finnas i samma L2-domän, vilket sätter en gräns för hur stort ett kluster kan vara och hur det kan segmenteras. Wikipedia beskriver RoCE v1 som en Ethernet link layer-protokoll med Ethernettyp 0x8915, där vanliga Ethernet-ramar är 1500 byte och jumbo frames 9000 byte.

För mindre installationer inom ett och samma VLAN kan RoCE v1 fungera bra, men det är ett begränsat val i moderna, routade datacentermiljöer.

RoCE v2: routbart via UDP/IP

RoCE v2 löser RoCE v1:s L2-begränsning genom att kapsla in RDMA i UDP/IP. Destination port 4791 är reserverad för RoCE v2, och eftersom paketen är routbara kan de korsa IP-routrar och olika L3-nät. Det gör RoCE v2 lämpligt för distribuerade kluster, separata rack och gateway-lösningar utan fysiska L2-kopplingar.

Priset är mer header per paket. IP- och UDP-huvuden konsumerar byte som annars hade kunnat bära användardata. Det innebär att RoCE v2 har något lägre effektivitet per paket än RoCE v1, särskilt med vanliga 1500-byte-ramar. Å andra sidan ger v2 routbarhet och enklare skalning, vilket i de flesta datacenter väger tyngre än den lilla förlusten i ren paketkapacitet.

Header-overhead och MTU

Varje Ethernet-ram bär protokollhuvuden innan användardatan får plats. MTU anger den största ram som nätverket tillåter: 1500 byte för en vanlig Ethernet-ram och 9000 byte för en jumbo frame. Eftersom RoCE v2 lägger till IP- och UDP-huvuden tar dessa upp en större andel av en liten 1500-byte-ram än av en stor 9000-byte-ram.

Ju större MTU, desto mindre andel av ramen går till protokollhuvuden och desto mer av bandbredden blir tillgänglig för verklig dataöverföring. Det gäller både RoCE v1 och RoCE v2, men skillnaden mellan versionerna är mest kännbar just med vanliga 1500-byte-ramar. Med jumbo frames krymper skillnaden i effektivitet, samtidigt som det ställs högre krav på att all utrustning i vägen stöder de större ramarna.

Effektiv bandbredd vid olika länkhastigheter

Header-overhead räknas per paket, så dess inverkan på den effektiva bandbredden växer med länkhastigheten. På en långsam länk är skillnaden mellan RoCE v1 och RoCE v2 marginell i praktiken. På en 100 Gbit/s-länk, där varje protokollbyte multipliceras med miljontals paket per sekund, blir den mätbar: mer av länkens kapacitet går till att bära IP- och UDP-huvuden i RoCE v2, och mindre återstår för användardata.

Det betyder inte att RoCE v2 är dåligt på snabba länkar. Det betyder att den effektiva bandbredden – datan som faktiskt kommer fram – är något lägre än den nominella länkhastigheten, och att skillnaden mellan v1 och v2 förstärks med hastigheten. För att planera kapacitet korrekt bör du räkna med den verkliga nyttokapaciteten, inte bara switchportens hastighet.

PFC, ECN och lossless Ethernet

Ingen av versionerna löser nätverksbelastning på egen hand. För att uppnå InfiniBand-liknande prestanda krävs vanligtvis ett lossless Ethernet, vilket konfigureras via Ethernet flow control eller priority flow control (PFC). RoCE v2 använder IP:s ECN-bitar för markering och CNP-ramar för bekräftelse, vilket är en del av dess mekanismer för hantering av trängsel.

Data Center Bridging (DCB) kan vara mer komplicerat att konfigurera än ett InfiniBand-nätverk, och felaktigt konfigurerat lossless Ethernet kan leda till omsändningar, packet drops eller i värsta fall nätverksomfattande låsningar. Både v1 och v2 förutsätter därför switchar som stöder lossless Ethernet.

Vanliga misstag

Att blanda RoCE v1 och RoCE v2 i samma kluster eller broadcast-domän är ett vanligt fel. De använder olika Ethernattyper: RoCE v1 med 0x8915, RoCE v2 med vanliga IPv4- eller IPv6-ramar. En switch som inte känner igen Ethernatypen kan filtrera eller läcka paket.

Ett annat misstag är att anta att verktyg, tillägg eller drivrutiner byggda för RoCE v1 fungerar med RoCE v2. De kolliderar ofta på MAC-adresser, portnummer eller internt tillstånd.

Så väljer du

Använd RoCE v1 endast om all trafik hålls inom en och samma L2-domän och du vill ha minimalt header-overhead. I alla andra fall – routade nät, segmenterade VLAN, flera rack eller distribuerade kluster – är RoCE v2 det praktiska valet. Välj jumbo frames om hela nätverket stöder MTU 9000, och räkna alltid med den effektiva bandbredden, inte bara den nominella länkhastigheten, när du planerar kapacitet.

Fördjupning: läs om beräkning av header-overhead för RoCE v2 på roce-v2-overhead.

Källa: Wikipedia (RDMA over Converged Ethernet).