Hinder för infiniband

MItt val för lagring stod mellan glusterfs och nfs. Det var svårt att välja, eftersom det visserligen går att hitta mycket information, med den säger inte så mycket. Det man förstår är att det är labbmiljö guide-skribenterna oftast kör i, precis som jag. Men jag installerar glusterfs-servern och lite tillbehör på min lagringsserver. Tanken är att lagringen ska vara på ett ställe och sedan ska jag ha två kvm-värdar som kör sina vitruella maskiner på lagrings-servern. Sammanlagt handlar det om tre servrar, två stycken Dell R710, på vilka jag kör kvm-värdar. Lagringsservern har en enkel maskin, ett Gigabyte-moderkort (770T-D3L) med en två-kärnig AMD-processor som heter Athlon II 240e. Så det här installerar jag på lagringsservern till att börja med.

På grund av beroenden blir det sammanlagt tolv paket som går in i stället för två på min Fedora 23. De här har jag redan installerat sedan tidigare:

# dnf install infiniband-diags rdma libibverbs libibcommon libmthca libmlx4 libibmad ibutils

Och nu sätter jag in ytterligare paket. Om det skulle se något annorlunda ut gör det inget. Pakethanteraren dnf sköter beroenden på ett förtjänstfullt sätt. Här ser ni t ex att jag försöker få in librdmacm, och dnf säger inte emot. Men det bror på att jag aldrig utförde ovanstående kommando, alltås det där libdmacm ingick. Hade jag kört 


Sen går jag enligt anvisningarna i Red Hats manualer till /etc/rdma/mlx4.conf och skriver in en rad i filen. 
00:08:f1:04:03:99:1f:c9 ib ib 
Vad betyder det nu detta? Ja, det som ser mac-adressen för infinibandporten får jag på genom att skriva # ib link show ib0 i konsolen.
Ta sen de åtta sista sifferparen från mac-adressen, altså området som har fått fet stil. "link/infiniband 80:00:04:04:fe:80:00:00:00:00:00:00:00:08:f1:04:03:99:1f:c9 brd"
Sen är det bara att ange om länken ska ha infiniband eller ethernet eller auto. Ytterligare anvisningar finns i konfigurationsfilen /etc/rdma/mlx4.conf
Därefter ska man av någon anledning, vilken jag inte fått klar för mig, byta namn på ib-enheterna. Det gör man /etc/udev/rules.d/70-persistent-ipoib.rules. Där anger man samma mac-adress som man gjorde tidigare och det nya namnet på enheten.

Det är alltså address och "?*" som manska lägga till macadressen för infiniband. Och i slutet av raden anger du namnet. Här är namnet mlx4_ib0. Man får inte använda vare sig ib0 eller ib1 för det är standard i linuxkärnan att använda dessa namn, och gör man det rör man till det.
Vi gör samma med den andra porten, men ger den givetvis namnet mlx4_ib1.
Sen ska vi ordna med konfigurationsfilerna i /etc/sysconfig/network-scripts. Har du en annan Linux-distribution blir det annorlunda. I Ubuntu och Debian går man till /etc/inet/interfaces och skriver in direktiven.
Då gör man båda filerna vilka då kan heta ifcfg-mlx4_ib0 och ib1 på slutet. Nedan visar jag en av filerna.

Eftersom båda enheterna får en ip-adress rekommenderar vissa sajter att man skriver in följande rader i /etc/sysctl.conf. Det ska vara för att det ska bli mer stabilt. Det kan tydligen bli så att infiniband ibland fungerar och ibland inte. Jag väljer att följa råden, eftersom jag inte kan argumentera emot. Däremot tar jag givetvis bort direktiven om det längre fram framkommer att det är fel att göra så här.

Nu ska det bli spännande att testa. Här kommer ett resultat från mina tester. Jag har alltså tre maskiner. Och på varje maskin finns ett infiniband-kort med två portar. De här tre maskinerna har jag kopplat ihop så att alla maskinerna har kontakt med varandra via en kabel. Det vore lättare att förklara om jag gjorde en bild av hur det ser ut. Ska nog snart göra en. Och de är kopplade så att från port två går en kabel till port 1 på nästa maskin där det går en opensm subnetmanager. 
Så för att maskinerna ska kunna ha kontakt vi ibping måste man starta ibping-servern på en maskin. Den går i gång på den port där opensm-subnetmanagern går. Det visade sig att jag inte kan ibpinga, eller ponga, annat än till en adress där opensmubnetmanagern går på port 1. Väljer jag att starta subnetmanagern på port 2 går det inte att ibpinga till maskinen. Om det här gäller när man ska pinga med ip-adresser har jag ännu inte testat. Får se om det behövs. Hur som helst har jag nu kontakt från varje maskin när jag använder port 2 till att ponga den maskin som den är kablad till. Och där går det alltså en subnetmanager. Krångligt? Nja, inte om vi hade en bild på det hela. Men krångligt är det såtillvida att att vi måste ha en subnetmanager för varje kabel vi har anslutit, eller mellan varje port. 
Det skulle säkerligen bli helt annorlunda om vi hade en infiniband-switch med en egen subnet-manager. Så är läget just nu. Ska försöka ordna med att jag kan pinga till ip-adresserna. 
Ping fugnerar inte än. En fil som kanske kan göra skillnad är /etc/modprobe.d/mlx4.conf. Där kan jag utöka debugging level, dvs att Linux spottar ur sig mer om orsaken till att det inte fungerar. Ska försöka med det.
Verkar inte göra någon skillnad. Nu ska vi gå vidare genom att ange något som kallas p-key. Det är ett medel genom vilket man kan knyta samman olika subnät, som vlan i vanliga ethernet-nät. P-key anges i /etc/rdma/partitions.conf
Okej! Nu ska vi konstatera en sak till. Att ha tre maskiner sammankopplade utan en infiniband-switch innebär mycket krångel. I alla fall räcker inte mina kunskaper för tillfället till rätta till det. Jag har ju kopplat i hop tre maskiner med tvåports-infinibandkort. För att ta ett exempel: då har den ena kabeln fått från maskin A till maskin B. Från den andra porten har andra kabeln gått från port 2 till den maskin A till maskin C. På så sätt har alla maskiner varit ihopkopplade. Och då har jag tänkt att maskin A ska ha lagringen gemensamt för maskinerna B och C. Men det har blivit för mycket för infiniband. Ibping fungerar. Alla portar går till aktivt läge och ibdiagnet visar inte på vare sig några fel eller varningar. Men när det gäller att pinga på vanligt sätt, fungerar det sällan. Däremot går det bra om jag kopplar ihop två maskiner med varandra via båda portarna. 
Nu har vi kommit en bit på väg. Nu fungerar ping åt båda hållen, på båda portarna när båda mellan de båda maskinerna A och C. Jag ska strax komma till lösningen. I alla fall är det min lösning. Det kanhända att det går att konfigurera så att alla tre maskinerna når varandra på något annorlunda sätt. Nu fungerar det i alla fall. Jag ska bara koppla in den tredje maskinen så får vi se om det fungerar med den också.
Ja, nu fungerar det. Lösningen låg i förståelsen av att varje kontakt mellan två portar via en Cx4-kabel bildar ett nätverk bestående av två noder, eller maskiner. På varje sådant nätverk ska man ha en subnetmanager. Jag valde att konsekvent köra igång en på den första porten. Dessutom måste varje sådant två-nodigt nätverk ha ett eget klassnät. Så mellan de två första portartna, alltså port 1 på maskin B och port 2 på maskin C hade jag opensm igång på port 1 i maskin B. De fick ip-adresserna 192.168.0.1 och 192.168.02. Därefter fortsatte jag med att starta en opensm-subnetmanager på maskin A:s första port. Från den porten drog jag en kabel till maskin B:s andra port och de fick ip-adresserna 192.168.1.1 och 192.168.1.2. Så jag valde att ge maskinen med en subnetmanager körandes slutsiffran 1. Och så vidare till maskin C, där en subnetmanager kördes i gång på dess första port. Ja, ni förstår säkert. Det var det som fick det att slutligen fungera med IPoIB. 
Nu äntligen kan vi börja med att köra igång lagringen som ska skötas av glusterfs. Det kommer att bli en utmaning anar jag. Vi ska påminna oss om att tanken från första början var att ha en lagringsplats, och denska både maskin A och maskin B kunna använda för sina virtuella maskiner. Och det ska också kunna gå att göra live migration. Det betyder att själva virtualiseringsvärdarna med KVM ska kunna bytas av. Exempelvis kanske jag har en virtuell Centos-maskin körandes på maskin A, lagringen är på maskin B och sedan föra över den maskinen till att köras på maskin B. Eftersom de ligger på olika subnät anar jag att det innebär problem. Det kanske ändå slutar med att jag blir tvungen att köpa en infiniband-switch. Men hur som helst har denna resa varit lärorik.
Vi fortsätter med nästa del på nästa sida. Ta en nattlig paus och fortsätt genom att klicka på länken nere till höger när du känner dig redo.