RDMA přes konvergovaný Ethernet - RDMA over Converged Ethernet

RDMA přes konvergovaný Ethernet (RoCE) je síťový protokol, který umožňuje vzdálený přímý přístup do paměti (RDMA) nad Ethernet síť. Dělá to zapouzdřením IB transportní paket přes Ethernet. Existují dvě verze RoCE, RoCE v1 a RoCE v2. RoCE v1 je Ethernet odkazová vrstva protokol a tedy umožňuje komunikaci mezi libovolnými dvěma hostiteli ve stejném Ethernetu vysílací doména. RoCE v2 je internetová vrstva protokol, což znamená, že pakety RoCE v2 lze směrovat. Ačkoli protokol RoCE těží z vlastností a konvergovaná ethernetová síť, lze protokol použít také v tradiční nebo nekonvergované síti Ethernet.[1][2][3][4]

Pozadí

Síťově náročné aplikace, jako je síťové úložiště nebo clusterové výpočty, vyžadují síťovou infrastrukturu s vysokou šířkou pásma a nízkou latencí. Výhody RDMA oproti jiné síti aplikační programovací rozhraní jako Berkeley zásuvky jsou nižší latence, nižší zatížení procesoru a vyšší šířka pásma.[5] Protokol RoCE umožňuje nižší latenci než jeho předchůdce iWARP protokol.[6] Existují RoCE HCA (Host Channel Adapter) s latencí až 1,3 mikrosekundy[7][8] zatímco nejnižší známá latence iWARP HCA v roce 2011 byla 3 mikrosekundy.[9]

Formát záhlaví RoCE

RoCE v1

Protokol RoCE v1 je protokol linkové vrstvy Ethernet s Ethertype 0x8915.[1] To znamená, že platí limity délky rámce protokolu Ethernet: 1 500 bajtů za běžný Ethernetový rámeček a 9000 bajtů pro a jumbo rám.


RoCE v1.5

RoCE v1.5 je neobvyklý, experimentální, nestandardizovaný protokol založený na protokolu IP. RoCE v1.5 používá pole protokolu IP k odlišení svého provozu od jiných protokolů IP, jako je TCP a UDP. Hodnota použitá pro číslo protokolu je nespecifikována a je ponechána na nasazení, které se má vybrat.

RoCE v2

Protokol RoCE v2 existuje nad protokolem UDP / IPv4 nebo UDP / IPv6.[2] Cílový port UDP číslo 4791 byl rezervován pro RoCE v2.[10] Protože pakety RoCEv2 jsou směrovatelné, protokol RoCE v2 se někdy nazývá Routable RoCE[11] nebo RRoCE.[3] Ačkoli obecně není zaručeno pořadí doručování paketů UDP, specifikace RoCEv2 vyžaduje, aby neměly být přeskupovány pakety se stejným zdrojovým portem UDP a stejnou cílovou adresou.[3] Kromě toho RoCEv2 definuje mechanismus řízení přetížení, který používá bity IP ECN pro značení a CNP[12] rámce pro oznámení o potvrzení.[13] Softwarová podpora pro RoCE v2 se stále objevuje. Mellanox OFED 2.3 nebo novější má podporu RoCE v2 a také Linux Kernel v4.5.[14]

RoCE versus InfiniBand

RoCE definuje, jak provádět RDMA Ethernet zatímco InfiniBand specifikace architektury definuje, jak provádět RDMA v síti InfiniBand. Očekávalo se, že RoCE přenese aplikace InfiniBand, které jsou založeny převážně na klastrech, na společnou strukturu konvergovaných sítí Ethernet.[15] Jiní očekávali, že InfiniBand bude i nadále nabízet vyšší šířku pásma a nižší latenci, než je možné přes Ethernet.[16]

Technické rozdíly mezi protokoly RoCE a InfiniBand jsou:

  • Řízení toku na úrovni propojení: InfiniBand používá algoritmus založený na kreditu k zajištění bezztrátové komunikace HCA-HCA. RoCE běží na ethernetu, implementace mohou vyžadovat bezztrátovou ethernetovou síť pro dosažení výkonových charakteristik podobných InfiniBandu, bezztrátový ethernet se obvykle konfiguruje pomocí Řízení toku Ethernet nebo prioritní řízení toku (PFC). Konfigurace a Přemostění datového centra Síť (DCB) Ethernet může být složitější než konfigurace sítě InfiniBand.[17]
  • Kontrola přetížení: Infiniband definuje řízení přetížení na základě značení FECN / BECN, RoCEv2 definuje protokol kontroly přetížení, který používá ECN pro značení implementované ve standardních přepínačích a CNP rámcích pro potvrzení.
  • Dostupné přepínače InfiniBand měly vždy nižší latenci než ethernetové přepínače. Latence mezi porty pro jeden konkrétní typ ethernetového přepínače je 230 ns[18] proti 100 ns[19] pro přepínač InfiniBand se stejným počtem portů.

RoCE versus iWARP

Zatímco protokoly RoCE definují, jak provádět RDMA pomocí rámců Ethernet a UDP / IP, iWARP protokol definuje, jak provádět RDMA přes přenos orientovaný na připojení, jako je protokol kontroly přenosu (TCP). RoCE v1 je omezen na jeden Ethernet vysílací doména. Pakety RoCE v2 a iWARP jsou směrovatelné. Požadavky na paměť velkého počtu připojení spolu s řízením toku a spolehlivosti TCP vedou k problémům se škálovatelností a výkonem při použití iWARP ve velkých datových centrech a pro rozsáhlé aplikace (tj. Velké podniky, cloud computing, aplikace web 2.0 atd.) .[20]). Vícesměrové vysílání je také definováno ve specifikaci RoCE, zatímco aktuální specifikace iWARP nedefinuje, jak provádět vícesměrové vysílání RDMA.[21][22][23]

Spolehlivost v iWARP je dán samotným protokolem, as TCP je spolehlivý. RoCEv2 na druhé straně využívá UDP který má mnohem menší režii a lepší výkon, ale neposkytuje inherentní spolehlivost, a proto musí být spolehlivost implementována společně s RoCEv2. Jedním z řešení je použití konvergovaných ethernetových přepínačů, aby byla místní síť spolehlivá. To vyžaduje konvergovanou podporu Ethernetu na všech přepínačích v místní síti a brání paketům RoCEv2 v cestování přes rozsáhlou síť, jako je internet, který není spolehlivý. Dalším řešením je přidat spolehlivost k protokolu RoCE (tj. Spolehlivý RoCE), který přidává handshaking do RoCE, aby poskytoval spolehlivost za cenu výkonu.

Otázka, který protokol je lepší, závisí na prodejci. Intel a Chelsio doporučují a výhradně podporují iWARP. Mellanox, Xilinx a Broadcom doporučují a výhradně podporují RoCE / RoCEv2. Ostatní prodejci v síťovém průmyslu poskytují podporu pro oba protokoly, jako jsou Marvell, Microsoft, Linux a Kazan.[24] Společnost Cisco podporuje obě RoCE[25] a jejich vlastní protokol VIC RDMA.

Oba protokoly jsou standardizovány, přičemž iWARP je standardem pro RDMA přes TCP definovaným IETF a RoCE je standardem pro RDMA přes Ethernet definovaným IBTA.[26]

Kritika

Některé aspekty, které mohly být definovány ve specifikaci RoCE, byly vynechány. Tyto jsou:

  • Jak překládat mezi primárními GID RoCE v1 a Ethernetem MAC adresy.[27]
  • Jak překládat mezi sekundárními GID RoCE v1 a ethernetovými MAC adresami. Není jasné, zda je možné implementovat sekundární GID v protokolu RoCE v1 bez přidání protokolu rozlišení adresy specifického pro RoCE.
  • Jak implementovat VLAN pro protokol RoCE v1. Aktuální implementace RoCE v1 ukládají ID VLAN do dvanáctého a třináctého bajtu šestnáctibajtového GID, ačkoli specifikace RoCE v1 vůbec nezmiňuje VLAN.[28]
  • Jak překládat mezi vícesměrovým vysíláním GID RoCE v1 a ethernetovými MAC adresami. Implementace v roce 2010 používaly stejné mapování adres, které bylo zadáno pro mapování adres vícesměrového vysílání IPv6 na adresy MAC MAC v síti Ethernet.[29][30]
  • Jak omezit provoz vícesměrového vysílání RoCE v1 na podmnožinu portů ethernetového přepínače. V září 2013 je ekvivalentem Zjištění posluchače vícesměrového vysílání pro RoCE v1 dosud nebyl definován protokol.

Kromě toho žádný protokol běžící přes IP nemůže předpokládat, že podkladová síť má zaručené řazení, o nic víc, než může předpokládat, že nemůže dojít k přetížení.

Je známo, že použití PFC může vést k zablokování v celé síti.[31][32][33]

Prodejci

Mezi oblíbené prodejce zařízení s povoleným RoCE patří:

Reference

  1. ^ A b „Specifikace architektury InfiniBand ™, vydání 1.2.1, příloha A16: RoCE“. InfiniBand Trade Association. 13. dubna 2010.
  2. ^ A b „Specifikace architektury InfiniBand ™, vydání 1.2.1, příloha A17: RoCEv2“. InfiniBand Trade Association. 2. září 2014.
  3. ^ A b C Ophir Maor (prosinec 2015). „Úvahy o RoCEv2“. Mellanox.
  4. ^ Ophir Maor (prosinec 2015). „RoCE a úložná řešení“. Mellanox.
  5. ^ Cameron, Don; Regnier, Greg (2002). Architektura virtuálního rozhraní. Intel Press. ISBN  978-0-9712887-0-6.
  6. ^ Feldman, Michael (22. dubna 2010). „RoCE: Ethernet-InfiniBand Love Story“. Drát HPC.
  7. ^ „Komplexní ethernetové řešení s nejnižší latencí pro finanční služby“ (PDF). Mellanox. Březen 2011.
  8. ^ „Stručný přehled konkurenční analýzy RoCE vs. iWARP“ (PDF). Mellanox. 9. listopadu 2010.
  9. ^ „Připojení serveru s nízkou latencí s novým adaptérem Terminator 4 (T4)“. Chelsio. 25. května 2011.
  10. ^ Diego Crupnicoff (17. října 2014). "Název služby a registr čísla portu transportního protokolu". IANA. Citováno 14. října 2018.
  11. ^ InfiniBand Trade Association (listopad 2013). „Stav a plány RoCE“ (PDF). IETF.
  12. ^ Ophir Maor (prosinec 2015). „RoCEv2 CNP Packet Format“. Mellanox.
  13. ^ Ophir Maor (prosinec 2015). „Správa přetížení RoCEv2“. Mellanox.
  14. ^ „Jádro GIT“. Leden 2016.
  15. ^ Merritt, Rick (19. dubna 2010). „Nová konvergovaná síť spojuje Ethernet, InfiniBand“. EE Times.
  16. ^ Kerner, Sean Michael (2. dubna 2010). „InfiniBand se stěhuje do Ethernetu?“. Enterprise Networking Planet.
  17. ^ Mellanox (2. června 2014). „Společnost Mellanox uvádí nový automatizační software ke zkrácení doby instalace ethernetové textilie z hodin na minuty“. Mellanox.
  18. ^ „SX1036 - 36portový přepínací systém 40 / 56GbE“. Mellanox. Citováno 21. dubna 2014.
  19. ^ „IS5024 - 36portový neblokující nespravovaný 40Gb / s systém InfiniBand Switch“. Mellanox. Citováno 21. dubna 2014.
  20. ^ Rashti, Mohammad (2010). „Předefinováno iWARP: škálovatelná komunikace bez připojení přes vysokorychlostní Ethernet“ (PDF). Mezinárodní konference o vysoce výkonných počítačích (HiPC).
  21. ^ H. Shah; et al. (Říjen 2007). „Přímé umisťování dat přes spolehlivý transport“. RFC 5041. Citováno 4. května 2011.
  22. ^ C. Bestler; et al. (Říjen 2007). „Přizpůsobení přímého přenosu dat (DDP) Stream Control Transmission Protocol (SCTP)“. RFC 5043. Citováno 4. května 2011.
  23. ^ P. Culley; et al. (Říjen 2007). "Marker PDU Aligned Framing for TCP Specification". RFC 5044. Citováno 4. května 2011.
  24. ^ T Lustig; F Zhang; J Ko (říjen 2007). „RoCE vs. iWARP - další“ Skvělá debata o úložišti"". Citováno 22. srpna 2018.
  25. ^ „Výhody vzdáleného přímého přístupu do paměti přes směrované textilie“ (PDF). Cisco. Říjen 2018.
  26. ^ T Lustig; F Zhang; J Ko (říjen 2007). „RoCE vs. iWARP - další“ Skvělá debata o úložišti"". Citováno 22. srpna 2018.
  27. ^ Dreier, Roland (6. prosince 2010). „Dvě poznámky k IBoE“. Blog Rolanda Dreiera.
  28. ^ Cohen, Eli (26. srpna 2010). „IB / core: Add VLAN support for IBoE“. kernel.org.
  29. ^ Cohen, Eli (13. října 2010). „RDMA / cm: Přidat podporu RDMA CM pro zařízení IBoE“. kernel.org.
  30. ^ Crawford, M. (1998). „RFC 2464 - přenos paketů IPv6 po sítích Ethernet“. IETF.
  31. ^ Hu, Shuihai; Zhu, Yibo; Cheng, Peng; Guo, Chuanxiong; Tan, Kun; Padhye1, Jitendra; Chen, Kai (2016). Zablokování v sítích Datacenter: Proč se tvoří a jak se jim vyhnout (PDF). 15. ACM Workshop o aktuálních tématech v sítích. str. 92–98.
  32. ^ Shpiner, Alex; Zahavi, Eitan; Zdornov, Vladimír; Anker, Tal; Kadosh, Matty (2016). Odemknutí zablokování úvěrové smyčky. 15. ACM Workshop o aktuálních tématech v sítích. str. 85–91.
  33. ^ Mittal, Radhika; Shpiner, Alexander; Panda, Aurojit; Zahavi, Eitan; Krishnamurthy, Arvind; Ratnasamy, Sylvia; Shenker, Scott (21. června 2018). "Přehodnocení síťové podpory pro RDMA". arXiv:1806.08159 [CS. NI ].
  34. ^ https://www.crn.com/news/components-peripherals/nvidia-mellanox-deal-may-not-close-until-early-2020
  35. ^ https://blogs.nvidia.com/blog/2019/03/27/israel-mellanox-nvidia/