Trots att vi har arbetat så mycket med VMware vSAN när det gäller webbplatsinnehåll och recensioner, kan det komma som en överraskning för vissa att vi inte har använt något vSAN i produktionen. När uppdateringen av våra labservrar är klar (12x Dell EMC PowerEdge R740xd ) bestämde vi oss för att lösa problemet genom att omgestalta ett antal PowerEdge R730 -servrar och extra SSD-diskar som vi hade till hands. Resultatet är en blygsam vSAN 6.6-konfiguration som vi kommer att använda för att vara värd för virtuella maskiner som behövs för testning, förutom att fungera som en plattform för att testa och rapportera om nya vSAN-funktioner. Denna implementering väcker dock en omedelbar fråga som vSAN-köpare ofta är nyfikna på: hur migrerar jag befintliga arbetsbelastningar till vSAN?
Som med de flesta företag är vår primära labblagring en blandning av iSCSI-resurser och Fibre Channel-lagring med de flesta av våra data som finns på Dot Hill-arrayer och en Fusion-io ION. Det finns ett antal olika sätt att närma sig denna migrering, från att flytta virtuella datorer mellan datalager med ett grundläggande SVMotion-kommando med lagringen lokalt kopplad till en värd som kan se båda datalagren, eller en tvåstegsmigrering där både värden och datalagringen ändras.
Om du har en lagringsuppsättning med iSCSI LUN:er är den här processen ganska enkel. Lägg till iSCSI-lagringsenheten till en av dina vSAN-värdar om du inte redan har gjort det, lägg till iSCSI-målet från din lagringsarray och få snabbt tillgång till den virtuella datorn i vSAN-klustret utan att ens behöva migrera datalagret ännu. Om du har en lagringsuppsättning som kommunicerar över FC kan du antingen använda en FC HBA om en redan finns på din server eller lägga till en till värden. Om FC-lagringen inte kommer att användas mycket i framtiden, kan kostnaden och stilleståndstiden i samband med installationen av HBA inte vara värt det, om så är fallet går vi vidare till tvåstegsprocessen.
När du flyttar virtuella datorer mellan ESXi-värdar där beräkningen och lagringen kommer att ändras i samma rörelse, kan du flytta den virtuella datorn var som helst i din miljö så länge som enheterna kan kommunicera med varandra i ditt vCenter. Detta är ett alternativ som har mest kompatibilitet, men som kanske inte är den snabbaste överföringsvägen om det redan finns en inbyggd. För enskilda virtuella datorer eller små grupper kanske detta inte är ett problem, men med ganska stora virtuella datorer eller stora partier kan en snabbare överföringsväg vara motiverad.
I vårt fall kan vi se att överföringen av den virtuella datorn tog bara några minuter, med 10G-nätverkslänken mellan de två värdarna som hjälpte till att pressa hastigheter upp till runt 400MB/s. Sammantaget är detta ett av de enklare stegen för att få igång din vSAN-plattform, men det finns några sätt att närma sig det beroende på dina behov eller hårdvarukapacitet.
I den här artikeln har vi pratat en hel del om hur enkelt det är att migrera befintliga VMware VMDK:er och iSCSI-resurser till vSAN. I alla organisationer som redan är virtualiserade är denna process ganska enkel. VMware har också ett verktyg för migrering av bare metal-system; vi använde VMware vCenter Converter innan vi fick äldre arbetsbelastningar till ett virtualiserat tillstånd. Oavsett hur du kommer dit erbjuder vSAN en hel del när det gäller driftseffektivitet och besparingar på ägandekostnader jämfört med traditionella IT-distributioner. Vi är entusiastiska över att förverkliga dessa fördelar i vårt labb och ser fram emot att publicera mer innehåll kring verkliga erfarenheter.
Amazon