Hejdå, VMware – Hej Proxmox! ⚓

20 Feb 2021

​Jag har ju uppenbarligen svårt att lära mig av tidigare misstag, eller så är jag bara oerhört envis. Jag har nämligen försökt migrera mitt hemmalabb till Proxmox tidigare. Två gånger till och med. Varje gång har jag ångrat mig, men denna gång gick det faktiskt vägen och detta tack vare två nya faktorer i sammanhanget.

Det ena är det faktum att jag numera endast behöver köra en enda server istället för två som tidigare. Det andra är att jag byggt en ny lagringslösning.

Låt mig förklara

Mina gamla grejer i hemmalabbet byggde på ett SAN som använde Fibre Channel för sin kommunikation. När jag försökte köra Proxmox i ett kluster med en delad lagringslösning baserad på Fibre Channel slutade det inte väl – det hela baserades på att ena klusternoden initierade och “ägde” anslutningen till SAN:et som monterades som en LVM, som man i sin tur sedan delade ut till andra noder i klustret. Problemet var att trafiken till SAN:et då gick från en nod till en annan nod till SAN:et och sedan tillbaka, och prestandan blev därefter. Man kunde lösa det genom att köra Multipath men det blev aldrig riktigt bra, åtminstone inte så bra som det fungerade i VMware ESXi 6.5 som jag var van vid.

Servrarna var inte heller särskilt purfärska men då jag de senaste 18-månaderna samlat på mig modernare grejer (mest genom gåvor och fynd jag gjort) har jag pö om pö uppgraderat mitt hemmalabb med. Detta första faktum har lett till att jag nu har aningen modernare servrar (två Dell R620) som jag migrerat ihop till enda server genom att trycka in allt minne från den ena i den andra. Detta har gett en maskin med 32 CPU-kärnor och 384 gigabyte internminne. Det räcker gott och väl för mina behov.

Det andra är att jag också investerat i ett bättre nätverk där jag kan köra 10GbE mellan alla servrar. Detta, plus det faktum att jag byggt ett nytt SAN med en HP-server (D170 generation åtta, nedklockad till sin lägsta hastighet för att spara ström), åtta 3TB-diskar, tre SSD-diskar och lite mer minne i den maskinen och vips så kunde jag bygga mig en snabb modern lagringslösning baserad på TrueNAS (före-detta FreeNAS).

Varför vill jag då byta bort VMware och mitt gamla FC-SAN?

Problemen är flera: mina Dell R620-servrar stöds inte av något nyare än VMware ESXi 6.5, vilket börjar bli till åren kommet. Det andra är att mitt FC-SAN, som visserligen fortfarande fungerar, är 16-17 år gammalt och inte fungerar något vidare med hårddiskar större än 1TB. Det gör att jag är begränsad till hur mycket yta jag kan få ut från det SAN:et vilket ger drygt 12TB i RAID-5. I takt med att diskarna går sönder, för de gör ju det till slut, så är det heller inte särskilt roligt att behöva köpa 1TB-diskar att ersätta de gamla med.

FC-SAN:et är inte överdrivet snålt när det gäller elförbrukning heller så det vore också trevligt att hyvla bort några watt på elräkningen så det fick bli ett nytt bygge.

Kort sagt: jag ville bygga en ny miljö på modernare hårdvara och mjukvaror som fortfarande uppgraderas och som också är gratis.

Så jag satte igång att åter igen titta på Proxmox. Och om det ska jag berätta om nu.

Migrering

Förr i tiden (det vill säga, i mina två tidigare försök, fick man vackert överföra filerna från VMware i form av VMDK-filer till en annan storage och sedan konvertera dem till qcow2 eller vad man nu ville har för format på sina virtuella diskar. Jag hade helt missat att det finns ett verktyg som heter OVFTool som gör det väldigt enkelt att överföra VMware-maskiner till Proxmox via SSH och HTTPS. Den eller de maskiner du vill överföra måste vara avstängda vid flytten men i övrigt är det bara att på din Proxmox-server, eller på en annan maskin du vill använda köra, kommandot och sedan vänta. För det tar en del tid, i synnerhet om diskfilerna till dina virtuella servrar är flera hundra gigabyte stora.

Efter att man migrerat över sina virtuella maskiner är det dags att importera det hela till Proxmox. Detta sker med fördel i CLI-gränssnittet som du kommer åt genom att SSH:a till din Proxmox-server:

qm importovf vm_id /namn_på_vm/namn_på_vm.ovf namn_på_lagring

Det ovanstående kan behöva en förklaring, så här kommer den:

vm_id = nästa lediga ID i Proxmox. När du skapade din första virtuella maskin i Proxmox fick den ett ID, ett siffervärde, som är 100. Därifrån stiger nummerserien automatiskt för varje ny server du skapar, men om du importerar en virtuell maskin på det ovanstående sättet måste du själv ange ID-numret. Enklast att göra detta är att kolla i Proxmox webbgränssnitt hur läget är – om den sista virtuella maskinen du kör har ID 110 så använder du 111 vid importen, och så vidare.

namn_på_vm/namn_på_vm.ovf = när du exporterar en virtuell maskin med OVFTool skapas en katalog automatiskt som döps till samma namn som den virtuella maskinen. I denna katalog läggs sedan de filer som du ska importera. Om du har exporterat en virtuell maskin från VMware som heter “mail” så kommer sökvägen således vara “/mail/mail.ovf”.

namn_på_lagring = namnet på den lagringslösning du vill placera den importerade virtuella maskinen. Har du ett SAN så kanske det heter “SAN01”. Växla över vyn i Proxmox webbgränssnitt till “Datacenter” och välj sedan “Storage” så ser du vad dina lagringslösningar heter i kolumnen döpt “ID”.

Dags att starta

När du migrerat och senare importerat dina virtuella servrar är det dags att börja starta dem. I mitt fall har jag tre olika typer av virtuella maskiner: FreeBSD, CentOS 7 och Windows Server.

I fallet FreeBSD är det inte svårt att komma igång: lägg till ett nätverkskort till den importerade virtuella maskinen, se till att det är av typen VirtIO, se till att hårddisken/hårddiskarna är satt som en SCSI-hårddisk och sedan är det bara att starta den virtuella servern. Du kommer behöva redigera /etc/rc.conf och ändra namnet på nätverkskortet till vtnet0, ta bort eventuella referenser till VMware och sedan är det bara att starta om och köra vidare.

I fallet CentOS kommer den virtuella maskinen att vägra boota om du sätter hårddiskgränssnittet till något annat än IDE. Det är också det långsammaste gränssnittet och därför vill du väldans gärna kunna köra VirtIO som gränssnitt för det. Innan du startar den virtuella maskinen skapar du ett nätverkskort som du sätter som VirtIO. Därefter konfigurear du hårddiskarna som IDE, starta sedan upp den virtuella maskinen, gå in i nätverkkonfigurationen i /etc/sysconfig/network-scripts och döp först och främst om konfigurationsfilen, som innan kanske heter ifcfg-ens160 till ifcfg-eth0. Därefter öppnar du filen med en vettig editor, raderar raden med UUID-värdet och ändrar sedan dessa två värden till eth0:

NAME="eth0"
DEVICE="eth0"

Med detta klart är det dags att lösa problemet med varför din virtuella maskin inte vill boota med VirtIO som gränssnitt för diskarna:

sudo dracut --add-drivers "virtio_pci virtio_blk virtio_scsi virtio_net virtio_ring virtio" -f -v /boot/initramfs-uname -r.img uname -r

Följt av:

sudo sh -c "echo 'add_drivers+=\" virtio_pci virtio_blk virtio_scsi virtio_net virtio_ring virtio \"' >> /etc/dracut.conf"

Sedan kan du stänga ner den virtuella maskinen, avmontera hårddisken/hårddiskarna och montera upp dem igen och då välja VirtIO som gränssnitt.

Kör du Debian redigerar du filen /etc/initramfs-tools/modules och lägger till följande:

virtio
virtio-blk
virtio-ring
virtio-pci
virtio-net

Därefter kör du kommandot update-initramfs -u -v och sedan kan du stänga ner den virtuella maskinen, avmontera hårddisken/hårddiskarna och montera upp dem igen och då välja VirtIO som gränssnitt.

Windows då? Här blir det lite knepigare. Se till att alla hårddiskar är satta med IDE som gränssnitt. Skapa sedan en ny hårddisk som du kopplar till den virtuella maskinen, den kan vara en gigabyte stor eller så, som du sätter som VirtIO. Innan du startar maskinen ser du till att ha laddat ner denna ISO-fil som du gjort tillgänglig i Proxmox. Denna ISO-fil monterar du som en virtuell CD-ROM-enhet till din virtuella Windowsmaskin. När detta är gjort startar du upp maskinen.

Om du inte avinstallerat VMware Tools från servern så är det dags att göra det nu. När det är avinstallerat går du in i Device Manager, slår på visning av gömda enheter och därefter avaktiverar du eventuella andra nätverkskort som hängt med från VMware. Starta sedan om den virtuella maskinen.

Installera därefter drivrutinerna från ISO-filen med hjälp av installationsprogrammet, och installera också gästagenten som finns i samma ISO-fil. Därefter kan du konfigurera nätverkskortet med rätt IP-adress, och så vidare. Stäng sedan ned den virtuella maskinen. Slutligen avmonterar du alla hårddiskarna, monterar upp de som faktiskt hör till maskinen (du kan radera den lilla extradisken du skapade förut) med VirtIO-gränssnittet och sedan kan du starta din virtuella Windowsmaskin igen och nu ska den fungera finfint.

Övriga intryck och råd

När man går från en beprövad plattform som VMware ESXi till Proxmox och inser att ens virtuella Windowsservrar faktiskt blir snabbare på samma fysiska hårdvara och med samma inställningar i sin virtuella hårdvara så inser man snart att Proxmox och dess underliggande virtualiseringsmotor KVM sparkar stjärt. Det finns inget annat sätt att beskriva det.

Med det sagt så är Proxmox inte bara guld och gröna skogar. Jag fick exempelvis inte kopplingen mot iSCSI att fungera ordentligt i en klusterinstallation, åtminstone inte med TrueNAS som operativsystem på lagringsenheten. Jag fick därför, akompanjerat av åtskilliga svordomar, tömma iSCSI-lagringen, radera den och köra allt via NFS istället vilket har fungerat över förväntan. Om du ändå vill köra iSCSI kan det vara värt att nämna att det inte är en vidare god ide att göra detta över en LACP-trunk där du kombinerar flera 1GbE-gränssnitt till ett enda, då iSCSI vad jag förstår inte reagerar så bra på det. I mitt fall har jag 10GbE-nätverk mellan alla servrar och min lagringsenhet varför det i kombination med NFS har fallit ut extremt väl. 10GbE-switchar är så pass billiga numera så det är varmt rekommenderat att investera i en sådan om du ska nyttja nätverksbaserad lagring, oavsett om det är iSCSI eller NFS-baserad dito.

Det finns mycket annat som jag gillar i Proxmox, som exempelvis att konsolen till de virtuella maskinerna fungerar i de allra flesta webbläsare utan att bråka det minsta. Den inbyggda backuplösningen i Proxmox fungerar också riktigt bra, vilket jag är glad för eftersom backuplösningar för virtuella maskiner i VMware ESXi kan bli en kostsam, och komplicerad, historia.

Huruvida Proxmox är “enterprise ready” som de själva säger ska jag kanske låta vara osagt, men det finns en hel del kvar att jobba på där.

Exempel på det är att en server med redan existerande virtuella maskiner i sig inte kan gå med i ett kluster – rådet från Proxmox-teamet är att ta backup på alla sina virtuella maskiner, ta bort dem från Proxmox, gå med i klustret och sedan importera dem igen. Ett annat exempel är om man kör flera fysiska maskiner i ett kluster så kan samma lagringsenhet visa olika storlek så väl som olika ledig diskyta beroende på vilken nod i klustret du tittar på detta i. Ett exempel för mig var när min NFS-lagring på ena noden i klustret var på 14TB och i den andra noden var på 400GB. Det är kanske en skitsak, men för mig blir det snabbt också en fråga om ett mindre magsår – vilken av noderna visar rätt egentligen, och, kommer något bli helt galet om man skriver data till nätverkslagringen från den nod som visar fel?

En sak som irriterar mig rätt mycket är vad som visas i bilden ovan. Här håller jag på och live-migrerar en virtuell maskins hårddisk till en annan lagring. Samtidigt vill jag ge samma server mer internminne, men tji fick jag – pågår en operation med en virtuell maskin i Proxmox så är den låst för alla andra former av justeringar eller operationer. Det går inte ens att stänga av en virtuell maskin från det grafiska gränssnittet så länge en annan operation på samma virtuella maskin pågår. Tyvärr får man, om man verkligen vill stänga av en virtuell maskin riktigt jävla mycket, SSH:a in på Proxmox-servern och leta fram vilken process som kör den virtuella maskinen i fråga och döda den med kill -9 pid.

Proxmox kostar ingenting att använda, och med tanke på allt man faktiskt får så är det en trevlig lösning. Det är klart det vore trevligt med automatisk balansering i klustret där virtuella maskiner skickas till en viss nod i klustret beroende på belastning och lediga resurser i andra noder i samma kluster men då pratar vi inte bara VMware ESXi utan också VCenter, och det kostar ordentligt med penningar.

Det tog mig en vecka av pillande, meckande och trixande innan hela min VMware-installation med strax över 40 virtuella maskiner var migrerad till Proxmox. Jag kunde använda mig av en extra server jag har i racket som “mellanlandning” medan jag tömde min VMware ESXi-server så nedtiden för sajter och annat blev inte så jobbigt stor som jag först hade fruktat. Jag har inte, så här tredje gången gillt, ångrat bytet eller haft en jobbig känsla i magen som jag hade efter de två första försöken så jag hoppas (ta i trä, med mera) att detta kommer fungera väl i framtiden.

Spotifys Dropbox-problem ⚓

4 Feb 2021

Spotify är utan tvekan ett fenomen. Sedan bolaget startades i maj 2006 har bolaget vuxit till en global gigant inom musikdistribution via Internet. 2019 hade bolaget enligt Wikipedia 4405 anställda och under tredje kvartalet 2020 hade bolaget 130 miljoner betalande användare.

Med allt det sagt borde Spotify anses vara en framgångssaga, men det är inte riktigt så enkelt. För att Spotify skulle överleva från starten för snart 15 år sedan fram till idag har det levt på främst investeringar och lånade pengar och fram till tredje kvartalet förra året hade bolaget gått med 29,3 miljarder kronor i förlust eller drygt 2,5 miljarder i förlust per år i genomsnitt från 2008 fram till tredje kvartalet 2020, och än så länge visar de inga tecken på att faktiskt gå med vinst.

Missförstå mig inte, intäkter från 130 miljoner betalande användare är inget att fnysa åt, men det är många som ska dela på de pengarna och bolaget är ännu så länge väldigt långt ifrån att ens kunna bära sina egna kostnader, än mindre visa en faktisk vinst.

Givetvis ökar bolagets intäkter, dels i takt med att de får fler och fler betalande användare men också genom återkommande prishöjningar. Sedan oktober förra året har bolaget exempelvis höjt priset på sitt Premium-konto, vilket medger upp till sex separata konton på en räkning, med 20 kronor per gång vilket gör att priset gått från 149 kronor till 189 kronor i månaden, 40 kronor dyrare än Apples motsvarande erbjudande för samma antal användare i ett konto genom Apple Music.

Spotify har på olika sätt försökt utöka sitt utbud i sin musikspelare med exempelvis poddar. Bolaget har haft poddar i många år men enskilda publicister som undertecknad och Fredrik Björeman kunde inte ansluta vår podd till tjänsten förrän till för några år sedan då Spotify plötsligt bestämde sig för att låta alla lägga till sina poddar i tjänsten. Spotify har också köpt ett par företag som arbetar med att producera poddar och på så sätt fått över en viss mängd innehåll som har kunnat göras exklusivt för Spotifys kunder. Men det är också allt som egentligen hänt, utöver att bolaget fortsatt etablera sig i nya länder och fortsatt ta in pengar från nya investerare för att överleva.

Antalet betalande användare av tjänsten har som synes ökat stadigt genom åren och från 2016 får man anse att tillväxten varit stadigt växande.

Ok, vad är då problemet som Spotify står inför? Börskursen ser överlag bra ut (se nedan) så “marknadens” förtroende har de ju?

Problemet är nämligen enkelt att identifiera men desto svårare att lösa : vad ska Spotify göra härnäst?

Givetvis kan de lägga till videomaterial, locka över kända Youtubers med miljoner prenumeranter till plattformen och betala dem väl för besväret precis som de gjort med en handfull utvalda kända poddare. Men sen då? Ska de bli en plattform för allt som rör media där även tv, film och liknande material ingår? Ska de som Apple försöka startade strömmande radiostationer?

Dropbox-problemet

Spotify har ett Dropbox-problem. Precis som Spotify är Dropbox ett företag som startade med ett problem och en lösning på detta: synka filer mellan datorer. De löste problemet med en genial lösning som under många år var geniunt uppskattad av miljontals användare, men precis som Spotify så ställdes Dropbox inför samma problem: vad ska vi göra nu? Precis som med Spotify så eldades Dropbox på av investerare som ville se fler betalande användare, högre omsättning och därmed potentiellt en högre avkastning på sin investering den dag de bestämde sig för att sälja sin andel. Inga konstigheter med det, men Dropbox var piskade att bygga ut sin enkla, geniala plattform med funktioner som få faktiskt vill ha.

Vad som en gång var en enkel lösning för att synkronisera filer har nu förvandlats till en plattform för att samarbeta med andra i olika webbaserade verktyg. Plattformen och dess erbjudande är rörig och så långt ifrån vad Dropbox en gång var som man kan komma, och numera finns det gott om alternativ, både gratis och inbyggda funktioner i form av iCloud Drive från Apple och OneDrive från Microsoft som har en tajtare integration i sina plattformar.

Steve Jobs hade rätt när han beskrev Dropbox som “en funktion, inte en produkt” – det var bara en tidsfråga innan Apple och andra bolag erbjöd samma funktion för samma, mindre eller inget pris alls.

Kanske är möjligheten att lyssna på musik över Internet på väg att bli en funktion? Apple verkar tro det – Spotifys huvudkonkurrent som öser in användare och intäkter från sina olika tjänsteerbjudanden där musik är ett av dem.

Apple insåg för länge sedan att de hade ett problem: de kommer inte kunna sälja datorer, telefoner och surfplattor i all framtid, och även om de tar fram nya produkter som säljer som glass i Saharaöknen så kommer marknaden för Apples dyra, exklusiva produkter inte att växa i den takt bolaget behöver för att kunna fortsätta leverera nya fantastiska resultat. Så de började med .Mac, som senare blev MobileMe, som senare blev iCloud. Under tiden denna transformation pågick hade Apple också börjat sälja musik via iTunes-butiken och snart sålde de också filmer och tv-serier. Snart kunde man hyra filmer och vips så hade bolaget en separat post i sin redovisning som de kort och gott kallar “tjänster”.

Apple kunde göra detta för att de hade redan ett ben att stå på i form av hårdvara (först iPod, senare iPhone, iPad, Mac, Apple watch osv) som behövde innehåll i form av bland annat musik. De kunde helt enkelt ställa ner andra benet på backen och vips så hade de tjänster och produkter. Två ben som kompletterar varandra där ett ben tar ett steg framåt och snart följer det andra benet efter.

Ett ben att stå på

Spotify, precis som Dropbox, står och hoppar på ett ben och det benet kommer de inte kunna hoppa på i all framtid. Det finns en smärtgräns för hur mycket kunderna vill betala för Spotifys utbud, oavsett hur mycket Daniel Ek vill maximera bolagets tillväxt. Spotifys jakt på nya betalande kunder ska betalas av de redan befintliga kunderna, och som en (numera före-detta) betalande kund är det inte vad man vill höra, eller inse.

Jag tror inte Spotify kommer försvinna imorgon. De har överlevt i snart 15 år men i takt med att bolaget fortsätter försöka växa och bli ännu större så har de också en utmaning i att inte tappa de tre faktorer som tog dem dit de är idag: skivbolagen, investerarna och kunderna.

Björeman // Melin, avsnitt 241: En kille som vill rädda en tjej ⚓

13 Jan 2021

Avsnitt 241 av min och Fredriks podd är speciell av flera anledningar: vår gemensamme vän Christian är med och vi fick också chansen att diskutera Microsofts kommande ändringar av Outlook, President Trumps senaste äventyr och amerikansk politik i största allmänhet. Vi hann också med en kortare diskussion om filmen Tenet.

Lyssna gärna.

Fiber är nyttigt ⚓

11 Jan 2021

Ända sedan Fibre Channel dök upp i slutet på 90-talet så har konsensus varit att det är en snabb teknik som kostar sjuka mängder pengar. Båda dessa ståndpunkter gäller även idag om man är ute efter den absolut senaste tekniken, men är man beredd att ligga några år efter och ändå få konkurrenskraftig prestanda för en spottstyver är Fibre Channel ett val som i undertecknads ögon inte är att förakta.

Vad är Fibre Channel, kanske du undrar? Enkelt uttryckt är det ett transportmedium för datatrafik till och från lagring. Fibre Channel är inte en ersättare till vanlig tcp/ip och ethernet, det är inte en ersättare till NFS, Samba eller AFP, utan det är något mycket, mycket mer.

Utvecklingen av Fibre Channel startade redan i slutet på 80-talet då den standard som senare spikades 1994 kom att i praktiken bygga på att du kan skicka SCSI-kommandon över en fiber-baserad länk. Fibre Channel sågs som ett svar på de tillkortakommanden som SCSI och HIPPI, det senare en punkt-till-punkt-länk för lagringsanslutning i stordatorvärlden stod för. SCSI var även det vanligt i stordatorer och även här fanns begränsningar i form av den fysiska anslutningens maximalt anslutna diskar, medan protokollet som sådant ansågs fungera bra nog för att användas för att styra den till fiberlänken fysiskt anslutna lagringen.

Fiber Channel kan byggas som nätverk där man har en eller flera switchar som knytpunkter, och på detta sätt liknar Fiber Channel också vanliga datornätverk. Under den senare delen på 90-talet byggdes det stora, dyra, lagringsenheter som byggde på SCSI-hårddiskar och anslöts med hjälp av fiberanslutningar till just stordatorer och andra liknande installationer. Tack vare att fiberkabeln inte byggde på koppar, som i sin tur erbjöd utmaningar i allt från maximal längd på den faktiska kabeln till det faktum att koppar har en inbyggd tröghet som i sin tur påverkar prestanda negativt, kunde man nu klämma ut hela 1Gbit/s över en fiberkabel som kunde vara flera hundra meter lång.

Några år senare, år 2001, kom nästa uppgradering av standarden och nu hade hastigheten fördubblats till 2Gbit/s. Tre år senare var vi uppe i 4Gbit/s, året efter det hade hastigheten dubblerats ännu en gång till 8Gbit/s och år 2008 var Fibre Channel uppe i 10Gbit/s. Under senare år har prestandan gått från 16Gbit/s (år 2011) till 128Gbit/s (år 2016), och givetvis ska man ha klart för sig att ska man pressa 128Gbit/s över en fiberkabel så kräver det ordentlig, och givetvis svindyr, infrastruktur.

Fibre Channel har som jag tidigare nämnt ofta haft en given kundkrets i form av stordatorer och liknande, men för gemene man var det bland annat Apples intåg i lagringsbranschen som blev det definitiva genombrottet för andra kundgrupper. 2003 släppte nämligen bolaget en lagringsenhet de kallade Xserve RAID - en produkt som rymde 14 vanliga IDE-hårddiskar, dubbla kontrollerkort, dubbla Fibre Channel-anslutningar och dubbla kraftaggregat och givetvis var allt detta byggt i ett lagringschassi så hyperdesignat så det fick andra tillverkares produkter att se ut som Trabanter jämte Apples vinröda sportbilar. Huruvida detta faktiskt spelar någon roll i en serverhall råder det väl skilda meningar om.

Vad som gjorde att Xserve RAID blev ett sådant genombrott var givetvis prislappen. En enhet kostade började på 55000 svenska kronor i 2003-års valuta och kunde landa på runt 120000 svenska kronor om man fläskade på sin konfiguration ordentligt. Detta var, och är fortfarande, obscent mycket pengar men betänk då att Apples prislapp var något av en revolution på marknaden, och när Apple inte bara vände sig till sin egna kundkrets utan också certifierade Xserve RAID för operativsystem från Microsoft, Linux, Solaris och givetvis det egna Mac OS X började försäljningen dra iväg ordentligt. Under en period mellan 2004-2006 var Apple en av de största leverantörerna på Fibre Channel-baserad lagring i världen, vilket kan låta helt otroligt nu med tanke på Apples fundamentala ointresse för allt som rör just servrar och lagring, men det är en annan historia.

Xserve RAID erbjöd en prestanda på 2Gbit/s över Fibre Channel och i övrigt var det en relativt simpel produkt utan en massa smarta finesser vilket gjorde att den också sålde bra till olika medieföretag som behövde kopiösa mängder snabb lagring för exempelvis videoredigering men de ville inte nödvändigtvis ha denna snabba lagring under skrivbordet. Det faktum att Apple också gjorde det förhållandevis enkelt att koppla in arbetsstationen Mac Pro till dessa lagringsenheter via Fibre Channel gjorde att Apples kunder snabbt blev en av de större användarna av Fibre Channel. Än idag sitter det exempelvis rackvis med Fibre Channel-lagring, varav en del fortfarande är Apples Xserve RAID, i en datorhall tillhörande den största svenska kvällstidningen. Då det som jag nämnde tidigare går att ansluta många datorer till en Fibre Channel-baserad lagring via en switch avsedd för ändamålet är det inte underligt att denna teknik lever vidare.

Därför ska du överväga Fibre Channel

Ok, har du läst så här långt så undrar du säkert: varför ska du inte köra iSCSI över tio gigabit ethernet?

Fibre Channel erbjuder extremt korta svarstider för din lagring tack vare att länken bygger på fiber, det är en av de viktigaste egenskaperna att lägga på minnet. iSCSI är en snabb och kraftfull teknik, det är inget snack om saken, och man kan uppnå helt okej prestanda även över en hyfsat kraftfull gigabit ethernet-switch, i synnerhet om man kombinerar flera samtidiga anslutningar mellan exempelvis en server, switch och lagring, men det finns nackdelar med detta.

Först och främst: inte vilken ethernet-switch som helst kommer orka med att skyffla iSCSI-trafik, och ska du använda dig av någon form av trunking, alltså där flera fysiska ethernetkablar skyfflas ihop och blir ett enda logiskt nätverksgränssnitt och därmed i teorin också erbjuder en högre prestanda än en enda kabelanslutning, så innebär det massor av nätverkskablar, både i dina servrar och i din lagringsenhet. En ethernetswitch som klarar tio gigabit per sekund och port är då att föredra men de kostar fortfarande 6000 kronor och uppåt för de enklaste modellerna och sitter man med ett hemmalabb eller något liknande så ska man givetvis lägga på minnet att man också behöver köpa nätverkskort som klarar tio gigabit per sekund och de är inte gratis heller.

Till det kan man lägga det klassiska problemet med kopparkablar som är tjocka och inte kan dras över längre sträckor.

Dags att shoppa

Fibre Channel i tio gigabit per sekund är dyra grejer. Men om du däremot kan leva med att köra i fyra gigabit per sekund så kommer du sannolikt bli ganska chockad över vad jag har att berätta för dig nu.

Ett Fibre Channel-kort från exempelvis Qlogic, som är den tillverkare jag rekommenderar då deras produkter stöds i en rad olika operativsystem, kostar om du köper det via eBay under en femtiolapp styck. Undertecknad köpte fem stycken förra året och i de flesta fall var portot från Tyskland eller Estland dyrare än själva produkten. Ja, det är begagnade grejer vi pratar om men de här prylarna är inte direkt slitna utan levereras så gott som alltid i sin orginalförpackning. En trevlig egenskap med Fibre Channel är att man inte behöver en switch om man exempelvis enbart koppla ihop två datorer. Men ska man koppla in fler så kan det vara en god ide att köpa sig en Fibre Channel-switch. Sedan några år tillbaka äger jag en äldre Fibre Channel-switch som klarar max två gigabit per sekund. Mina Fibre Channel-kort klarar fyra, och det gör också mitt SAN (mer om det strax) så jag bestämde mig för att uppgradera. Ett par sökningar senare på eBay så har jag köpt en Fibre Channel-switch från HP för 268 kronor, plus 119 kronor i frakt från England. I samtliga fall kan du notera att jag inte köpt saker från USA utan enbart inom EU vilket innebär att allt är tullfritt. Jag behövde köpa några SFP-moduler också, som konverterar fiberkabelns anslutning till själva anslutningen i switchen. Prislapp? 15 kronor styck från en fransk säljare, även detta via eBay.

Nu låter ju allt detta lite för bra för att vara sant, och jag kan meddela att det är det också. Nästan. Som du märkt har jag utelämnat en “liten” sak: själva lagringen. Oftast brukar dessa kallas Storage Area Network, eller SAN, och de som äger ett SAN brukar oftast påpeka att det inte är en NAS…

I mitt fall har jag tidigare ägt flera Apple Xserve RAID, men dessa är svåra att få tag i, kan inte uppgraderas till snabbare Fibre Channel-anslutningar än två gigabit per sekund och ska man importera dem från USA (där man vanligen hittar dessa produkter) får man belåna bostaden eller ta ett blankolån för att betala frakt och tullavgiften. Jag hade turen att få tag i ett Fibre Channel-SAN från Promise vid namn VTrak E610F, för övrigt den produkt som Apple själva sålde i sin webbutik som ersättare till Xserve RAID, till ett obscent lågt pris. Låt gå att jag fick byta ut samtliga 16 hårddiskar i den och att det inte är en enhet man kan ha i en garderob eller under sängen (om du besitter en källare hemma eller har ett väl ventilerat och hyfsat ljudisiolerat utrymme på kontoret kan det vara läge att ta något av dessa i besittning ganska omgående) men jag har numera drygt 18 terabyte lagringsyta anslutet över Fibre Channel till mina VMware-servrar och till en Xserve som står som mediaserver.

Låt gå för det faktum att du inte vill, eller kan, ha ett rackskåp att bygga upp en mindre serverfarm i - kanske vill du bara ha snabb lagring till en eller flera datorer hemma och är beredd att kavla upp ärmarna och bygga det hela själv. Det finns alternativ för dig också - man kan relativt enkelt bygga sig ett Fibre Channel-SAN med hjälp av rätt hårdvara och en mjukvara i form av FreeNAS eller liknande. Ska man exempelvis endast ansluta två servrar eller datorer till sin lagringsserver kan man köpa sig ett Fibre Channel-kort med två portar och sedan två kort med en port vardera och ansluta server/klientdatorerna direkt till lagringsenhetens två portar.

Det är faktiskt precis så enkelt.

Ett par tips så här till slut:

Brocade är duktiga på mycket men undvik deras Fibre Channel-produkter. Korten har ett mer begränsat stöd i operativsystem bortom Linux och Windows och ska man bygga på FreeNAS så krävs det att man väljer ett kort från QLogic.

Om du köper en Fibre Channel-switch, kontrollera noga vilka licenser som är förinstallerade. En switch kan exempelvis ha tolv eller 16 portar men inte sällan innehåller de endast en grundlicens som låter dig använda åtta portar och där flera intressanta funktioner är avslagna.

Köper du ett Fibre Channel-SAN, räkna kallt med att byta ut alla hårddiskar (om det ens är några installerade). Kontrollera noga vilken typ av diskar som stöds och att SAN:et inte är en del av ett större system från exempelvis NetApp.

Om du köper ett SAN, kontrollera att du får med diskslädar, rackskenor och annat. Räkna med att alla såna tillbehör kan vara svåra att få tag i. Om SAN:et har dubbla kontrollerkort, vilket de flesta har, se till att båda kontrollerkorten medföljer och att de fungerar ordentligt.

Ska du köpa fiberkablage? Nya kablar är billigast i Kina, ironiskt nog. Se vår länklista för mer information.

Länklista

AliExpress: här köper du bra fiberkablage väldigt, väldigt billigt. Alltid fraktfritt och oftast tullfritt, underligt nog.

Bygg ett Fibre Channel-SAN med FreeNAS

Bygg ett Fibre Channel-SAN med OpenFiler

Installera Mastodon i FreeBSD 12.2 ⚓

29 Dec 2020

Som tidigare meddelats har jag börjat migrera bort mina CentOS 7 servrar till FreeBSD 12.2 istället. I vissa fall har det varit enkelt, och i andra fall har det varit ett rent helskotta. I skrivande stund har jag precis klarat av en migrering: min Mastodon-server, och jag har 2-3 kvar som är riktigt jobbiga också, men vi korsar den bron när vi kommer till den som det brukar heta. Om du vill läsa lite mer om mina tankar om Mastodon kan du göra det här.

Att installera Mastodon

Börja med att installera Mastodon på en server med FreeBSD. Om du gör den till en server som tillåter registreringar så kan du tänka på att gott om minne, processorkraft och diskyta kommer bespara dig problem i framtiden. Min Mastodon-server har ett 20-tal användare, mer eller mindre, aktiva, och min databas låg på närmare en gigabyte i storlek och katalogen med bilder och annat som användarna postat eller fått i sina flöden uppgick till 70-80 gigabyte. Servern jag kör det på har två processorkärnor och åtta gigabyte internminne, vilket säkert går att banta lite men jag gillar marginaler och servern tuffar på bra som den är:

Innan du sätter igång och installerar Mastodon är det bra att läsa på lite. Det finns gott om dokumentation att läsa, och det enda som saknas egentligen är det där lilla problemet: det finns ingen installationsguide för oss som kör FreeBSD. Tidigare fanns Mastodon paketerat via FreeBSD:s inbyggda pakethanterare men det har försvunnit av någon anledning.

När du installerat din server, gett den ett fullständigt värdnamn i /etc/rc.conf (inklusive domän och tld) så kan du börja installera lite paket:

$ pkg install bash sudo

Därefter är det dags att installera ännu fler paket. Här är det frestande att installera senare versioner än de jag listar här nedan men problemet är att Mastodon exempelvis inte stödjer den senaste versionen av Ruby så följ denna guide så ska det gå bra:

$ pkg install git imagemagick-nox11 ffmpeg libxml2 libxslt gcc protobuf pkgconf autoconf automake gmake bison python readline ncurses openssl libyaml icu libffi gdbm libidn redis postgresql96-server postgresql96-contrib postgresql96-client ruby-2.6 ruby-26-gems rubygem-bundler node yarn npm nginx

Därefter skapar du användaren för Mastodon:

<br /> $ pw useradd -n mastodon -u 144 -c "Mastodon User" -m -d /usr/local/www/mastodon -s /usr/local/bin/bash<br />

Sedan är det dags att “installera” Mastodon:

<br /> $ su - mastodon<br /> $ git clone <a href="https://github.com/tootsuite/mastodon.git">https://github.com/tootsuite/mastodon.git</a> live<br /> $ cd ~/live<br /> $ git checkout $(git tag -l | grep -v 'rc[0-9]*$' | sort -V | tail -n 1)<br /> $ bundle install -j$(getconf NPROCESSORS_ONLN) --deployment --without<br /> development test<br /> $ yarn install --pure-lockfile<br /> $ exit<br />

Konfigurera PostgreSQL

Att lattja med databasen som körs med Mastodon är ett kapitel för sig. Det finns många varianter på hur man gör detta men jag listar hur jag gjort här och det har fungerat.

Först initierar du databasen:

<br /> $ /usr/local/etc/rc.d/postgresql initdb<br />

Därefter startar du PostgreSQL:

<br /> service postgresql onestart<br />

Därefter skapar du användare och databas för Mastodon:

<br /> $ sudo su - postgres<br /> $ psql<br /> CREATE USER mastodon CREATEDB;<br /> CREATE DATABASE mastodon_production;<br /> GRANT ALL PRIVILEGES ON DATABASE mastodon_production TO mastodon;<br /> \q<br />

Konfigurera Nginx

Nginx fungerar som en proxy mellan Mastodon och resten av omvärlden. Det är mot Nginx du skickar trafiken från ditt LAN och WAN där Nginx tar emot trafiken på port 80 eller 443 och skickar den “bakåt” till Mastodon på port 3000 och 4000.

Jag har lagt upp mina konfigurationsfiler här som du kan ladda ned och titta på. Notera att konfigurationsfilen för Mastodon ska placeras under katalogen conf.d i rootkatalogen för Nginx som är /usr/local/etc/nginx/.

Det är också en god idé att du tittar på att installera Let’s Encrypt och skaffar dig ett certifikat till din Mastodon-server. I och med att certifikatet hanteras av Nginx är detta enkelt och inget denna guide går igenom.

Starta sedan Nginx med kommandot service nginx onestart

Skapa serviceobjekt för Mastodon

Mastodon består av tre olika komponenter som ska startas av operativsystemet genom att placera tre filer i /usr/local/etc/rc.d. Mina tre exempel på dessa filer kan du ladda ner här. Värt att notera är att dessa filer placerar process-id-filerna (pid) i /var/run – du kan ändra detta själv i filerna efter tycke och smak, men notera att du sedan måste göra motsvarande ändringar i andra filer i Mastodon oavsett om du använder samma inställningar som jag eller egna, nämligen dessa två:

~/live/config/pumba.rb – på rad 4 lägger du in följande rad:
pidfile '/var/run/mastodon_web.pid'

~/live/config/sidekiq.yml – längst ner i filen lägger du in följande rad:
:pidfile: /var/run/mastodon_workers.pid

Du kan behöva justera rättigheterna för /var/run om PID-filerna inte skrivs där.

Gör de tre processfilerna körbara med följande kommando:

chmod +x /usr/local/etc/rc.d/mastodon_*

Justera Redis för lokala anslutningar

I Redis konfigurationsfil finns det tydliga tecken på att Redis ska acceptera anslutningar från localhost (127.0.0.1) på port 6379 i och med denna rad:

bind 127.0.0.1

Av någon anledning räcker inte detta utan jag fick modifiera raden så här:

bind 127.0.0.1 192.168.1.10 där 192.168.1.10 är IP-adressen på Mastodon-servern. Denna IP-adress ersätter du givetvis med den faktiska adressen på din egna server.

Förbered Mastodon

Det är dags att förbereda Mastodon för sin första körning.

Skapa katalogen för loggar:

$ mkdir /var/log/mastodon<br /> $ chown mastodon /var/log/mastodon

Gå över till Mastodon-användaren med följande kommando:

sudo su - mastodon

Ge sedan följande kommando:

$ cd ~/live
$ RAILS_ENV=production bundle exec rake mastodon:setup
$ RAILS_ENV=production bundle exec rails assets:precompile

När detta är klart kan du sedan redigera ~/live/.env.production. Notera särskilt att du måste konfigurera någon form av e-postfunktion så användare kan registrera sig hos dig, få e-post med information om nya följare, och så vidare.

Starta alla tjänster automagiskt

Det är trevligt när ens tjänster startar automagiskt vid omboot och liknande. Lägg in följande rader i /etc/rc.conf:

<br /> redis_enable="YES"<br /> postgresql_enable="YES"<br /> nginx_enable="YES"<br /> mastodon_stream_enable="YES"<br /> mastodon_web_enable="YES"<br /> mastodon_workers_enable="YES"<br />

Boota till sist om din server och se att allt kommer upp ordentligt. Kolla i loggarna för Nginx och Mastodon efter felmeddelanden från uppstarten. Ser allt rimligt bra ut kan du testa att surfa till din nya Mastodon-server, registrera ditt konto och se till att du blir administratör för servern innan du släpper på användare utifrån.

Lycka till!