Dela via


Översikt över Azure Storage-bandmigrering

Den här artikeln fokuserar på bandmigreringar. Syftet är att förenkla, ge vägledning och överväganden för att köra genom en lyckad migrering av data som lagras på olika bandmedier till Azure Storage-tjänster.

Översikt

Band lagrar en stor del av världens data och är fortfarande en av de dominerande typerna av lagringsmedier. Bandmedier finns i årtionden och används fortfarande kraftigt med hundratals exabyte nya band som skickas varje år.

Band är ett bra medium för lagring av kalla data. De är snabba i sekventiell läsning, men steg som kräver mekaniska rörelser (som lastning och lossning av band, bandsökningar osv.) är långsammare. Det gör band oanvändbara för traditionell, slumpmässig baserad åtkomst, och är den främsta anledningen till att data som lagras på band än i dag sällan används. Dessutom är band ett magnetiskt medium som kräver särskild hantering. De är känsliga för miljön, särskilt temperatur och luftfuktighet. Om de hålls inom sitt operativa miljöintervall kan de uppnå hög hållbarhet och bra återställningsframgång. Men när det hålls i ovänlig miljö sker försämring ofta och gör bandet oläsligt.

Stora delar av band lagrar mörka data (data som skapas och lagras, men som inte används för något ändamål). Mörka data ger dataägaren inget värde. Med den ökade AI-kapaciteten och tillgängligheten förändras trenden. Kunderna undersöker hur mörka data kan hjälpa dem att öka effektiviteten, öppna nya intäktsströmmar eller öka sin konkurrensfördel. För att dra nytta av mörka data överväger många organisationer att migrera data från band till molnlagring. Molnlagring är ett enkelt sätt att analysera data, extrahera affärsvärde (med tjänster som AI, Mašinsko učenje, Azure Search osv.) eller minska kostnaderna genom att dra nytta av arkivlagring för långsiktig kvarhållning.

Några av de främsta orsakerna till att vi ser en ökning av band till molnmigreringar är:

  • Extrahera affärsvärde från mörka data,
  • Minska den ansträngning som krävs för att hantera data med långsiktig kvarhållning,
  • Undvik migreringsprocessen från en bandgenerering till en annan,
  • Minska risken för dataförlust, särskilt för äldre generationer av band,
  • Byt ut bandlagringsutrymmen utanför platsen,
  • Förenkla haveriberedskapsprocesser,
  • Tillämpa moderna verktyg som AI och ML på historiska data.

Att tänka på

Innan en bandmigreringsprocess startar måste alternativen övervägas noggrant. Det första du bör tänka på är att bestämma vem som ska utföra migreringen. Två alternativ används ofta:

  • Kunden utförde migrering där kunden kör migreringen från slutpunkt till slutpunkt,
  • Bandmigreringspartner där kunden skickar banden till partnern och partnern utför migreringsprocessen.
Metod Fördelar Nackdelar
Kunden utförde migrering – Data lämnar aldrig webbplatsen
- Ingen logistik för fraktband
– Kräver maskinvaruresurser
– Lägger till mer arbete till personalen
– Kräver specifik kunskap om hantering av band
– Möjliga okända kostnader
Bandmigreringspartner – Enkel prissättning och kända kostnader i förskott (betalas per band)
- Ingen påverkan på produktionen
- Ingen påverkan på personalen
– Kräver logistik för fraktband
– Säkerhetsöverväganden som krävs på grund av fraktband
– Flera kopior som behövs för datatillgänglighet under migreringen

Flera viktiga överväganden kan enkelt vägleda vårt beslut om vem som kan utföra migreringen, kunden eller partnern.

Resurser

Resurser är den mest kritiska delen av bandmigreringsprocessen och vi delar upp dem i följande kategorier:

Kategori Kommentar
Folk - Specifika kompetensuppsättningar krävs
- Processen är arbetsintensiv
Maskinvara – Olika bandgenerationer kräver olika typer av maskinvara
– Migreringens hastighet är proportionell mot tillgängliga enheter och nätverksbandbredd
Programvara – Åtkomst till programvara som skapade data behövs
– Åtkomst till krypteringsnycklar krävs

Maskinvara är vanligtvis den mest utmanande delen. Om vi migrerar befintliga bandgenerationer är maskinvara tillgänglig men används som en del av den befintliga produktionen. Men för äldre bandgenerationer är maskinvara ofta livets slut, och det är svårare att skaffa sig. Med äldre bandgenerering är det ett föredraget och enklare alternativ att använda en bandmigreringspartner. När produktionsmaskinvara används för migreringar krävs noggrann planering för att se till att migreringen inte stör produktionsarbetsbelastningarna. Här kan vi använda tre olika modeller:

  1. Använd dedikerad maskinvara för migrering: enklaste migreringsmodellen, det är enkelt att schemalägga och planera utan påverkan på produktionen. Det lägger till kostnader för att hämta maskinvaran (om den inte redan är tillgänglig) och orsakar en låg maskinvaruanvändning efter migreringen.
  2. Kör migrering utanför arbetstid på produktionsmaskinvara: migreringsmodell utan påverkan på produktionen. Kräver komplex schemaläggning, körning och personer som arbetar utanför arbetstid. Endast möjligt om produktionsmaskinvaran inte används dygnet innan.
  3. Kör produktion och migrering tillsammans: minst föredragen migreringsmodell eftersom den enkelt kan påverka produktionen. Den här modellen minskar den maskinvara som är tillgänglig för produktion, kräver komplex schemaläggning och planering. Om den här modellen används är processer för att minska påverkan på produktionen avgörande för att hålla migreringstidslinjen under kontroll. Den här modellen rekommenderas endast när produktionsmaskinvaran har låg användning.

Alternativ för dataöverföring

När data har lästs från band måste de flyttas till Azure Storage. Data kan flyttas med hjälp av nätverk eller offlineenheter som Azure Data Box. Några av de parametrar som påverkar valet av dataöverföringsalternativ är:

  • Tillgänglig nätverksbandbredd
  • Tidslinje som krävs för att slutföra migreringen
  • Frekvens för dataändringar

Läs mer om vägledning för att välja det optimala alternativet här. Nätverksöverföring är enklare och det bästa alternativet. Kombination av nätverk och offlinemetod är också möjlig, men kräver mer planering för att se till att migrerade data inte överlappar varandra.

Om det inte finns några tillgängliga resurser för att utföra migreringen, oavsett vilken typ av resurs, är vårt enda alternativ att använda en bandmigreringspartner. I så fall kan vi välja mellan två alternativ:

  1. Migrering som utförs på kundens webbplats: bandmigreringspartner skickar maskinvaran, anställer personer och utför arbetet på kundens plats. Kunden måste ge åtkomst till band, dedikerat utrymme för utrustning, nätverksanslutningar och åtkomst till Azure Storage-tjänsten. Partner ansvarar för alla andra aktiviteter.
  2. Migrering som utförs på partnerns webbplats: kunden skickar banden till partnern och ger åtkomst till Azure Storage-tjänsten. Bandmigreringspartner utför allt arbete för att migrera data från band till Azure Storage.

Det andra alternativet är enklare och vanligare. Bandmigreringspartner har anläggningar som är utformade och utrustade för att utföra bandmigrering i stor skala. Det här alternativet minskar också risken och tidslinjen eftersom partner har fler tillgängliga maskinvaruresurser. Att utföra migrering på kundens webbplats används endast när säkerhets- och sekretessproblem inte tillåter kunden att skicka banden till partnern.

Flera partner kan utföra bandmigreringar till Azure. Den fullständiga listan över partner finns vid import av offlinemedier.

Här är ett enkelt flödesschema som underlättar urvalsprocessen. Diagram som visar urvalsprocessen för bandmigrering.

Dataformat

Dataformatet har stor inverkan på migreringsdesignen och är avgörande för framtida dataanvändning. Data kan lagras i ett egenutvecklat eller inbyggt format. Egna format lagras ofta som virtuella band. Internt format kräver återställning av filer från band och lagring av dem som filer eller objekt.

Modell Fördelar Nackdelar
Virtuella band – Enklare och snabbare migrering
– Kan återskapa identiska bandmedier som originalet
– Du behöver inte ha åtkomst till den ursprungliga programvaran för att skriva data
– Kräver underhåll av virtuell bandinventering
– Data som lagras i programberoende format, kräver ursprunglig programvara för att återställa data
– Data som inte är tillgängliga för Azure-tjänster (AI/ML) utan återställning
Interna filer – Filer som är tillgängliga för alla program och tjänster (AI/ML)
– Möjligt att tjäna pengar på data
- Du behöver inte ha åtkomst till den ursprungliga programvaran för återställningar
– Mer komplex migrering
– Kräver åtkomst till ursprunglig programvara för att skriva data

Det viktigaste kriteriet för att bestämma formatet är hur vi planerar att använda data. Om data endast migreras för långsiktig kvarhållning är virtuella band ett bra val. I andra fall är lagring av data i internt format ett föredraget alternativ. Det möjliggör enkel användning av data i framtiden och öppnar många möjligheter med dataanalys.

Migreringsprocessen

När vi har fattat beslut om migreringskörning och önskat dataformat kan vi börja med migreringen. Migreringen går igenom flera faser. Diagram som visar faser för bandmigrering.

Informationsfas

Informationsfasen är viktig för att samla in viktiga krav. Insamlad information vägleder korrekt design och planering. Även om viss information kan uppdateras i senare skeden, anger exakt information scenen och undviker behovet av att göra stora ändringar i processen. Några av de viktigaste frågorna som den här fasen måste besvara är:

  • Vilken typ av band måste migreras (till exempel LTO3, LTO6, 3592JC osv.)?
  • Vilken mängd band för varje modell som behöver migreras (till exempel 100xLTO3, 200xLTO6 osv.)?
  • Vilken programvara användes för att skriva data på band, är programvaran fortfarande tillgänglig?
  • Vilket format används för att skriva data på band, är formatet öppet eller proprietärt, tillämpas komprimering?
  • Användes kryptering, och om ja, vilket är det säkraste alternativet för att byta krypteringsnycklar?
  • Vilken är målregionen?
  • Vilken lagringstjänst används?
  • Vilka regelkrav är kritiska (HIPAA, GDPR osv.)? Är kedjan av vårdnad obligatorisk?
  • Vad är tidsgränsen för migrering? Finns det några kritiska milstolpar?
  • Hur mycket nätverksbandbredd är tillgänglig för migrering?
  • Var lagras band fysiskt och kan de skickas?
  • Har du redan hash-värden för alla filer? Om ja, vilken hashalgoritm används?
  • Behövs band efter migreringen?
  • Hur underhåller man temperatur och luftfuktighet för band under migrering/transport?
  • Vilka är de viktigaste intressenterna?

Förberedelsefas

När vi har samlat in grundläggande information kan vi förbereda migreringen. Förberedelsefasen kan innehålla många olika steg, men det finns några vanliga steg som de flesta migreringar går igenom:

  1. Dataanalys innehåller information om de data som behöver migreras. Information är viktig för att uppskatta hur snabbt data kan läsas från band och hur mycket parallellitet vi behöver uppnå för att slutföra migreringen före tidsgränsen. Det påverkar uppskattningar på nödvändig maskinvara (bibliotek, robotar, enheter). Dataanalys görs genom sampling av flera band som representerar datauppsättningen som ska migreras. Typisk information som vi letar efter är:

    • filstorlekar,
    • mängden data som lagras per band,
    • antal filer per band,
    • minsta och högsta filstorlekar.
    • filtyper.
  2. Datakvaliteten hjälper dig att beräkna den slutgiltiga och unika datamängden som måste migreras. Ett av de vanligaste problemen med bandmigrering är duplicering av data. Bandmigrering är den perfekta tiden för att rensa duplicerade data. Den här processen förbättrar datakvaliteten för framtida användning, minskar kostnaden och varaktigheten för migreringen.

  3. Dataprioritering avgör i vilken ordning data kan migreras. Helst vill vi uppnå direktuppspelning från varje band i stället för att slumpmässigt läsa filer från olika band (för att undvika konstant inläsning, lossning och sökningar). Den här metoden uppnår högsta möjliga dataflöde och är alltid den snabbaste migreringsvägen. Dataprioritering kräver affärskrav och teknisk genomförbarhet för att uppnå bästa resultat.

  4. Migreringsdesignen innehåller alla tekniska aspekter av migreringen och den insamlade informationen för att bilda en slutlig migreringsprocess. Det är ett skriftligt dokument som blir sanningskälla för de återstående stegen. Den måste innehålla minst:

    • tydlig migreringsprocess och tidsgräns för migrering,
    • maskin- och personalkrav,
    • infrastruktur och nätverksdesign,
    • Säkerhetshänsyn
    • hur man hanterar oläsliga band,
    • roller och ansvarsområden osv.

Migreringsfas

När migreringsdesignen är klar startar vi migreringsprocessen. Innan vi ökar till full migreringstakt utför vi alltid ett test med ett mindre exempel. Målet med testet är att se till att processen från slutpunkt till slutpunkt fungerar. Det gör att vi kan göra justeringar och förbättra processen. När testet har lyckats och vi är nöjda med resultatet kör vi migreringen. Migreringsfasen är något annorlunda om vi använder inbyggda filer jämfört med virtuella band. I båda fallen är det en repetitiv process som cirklar genom alla band och läser hela innehållet. Det här flödesschemat visar migreringsfasen när du migrerar till interna filer. Flödesschema som visar information om en migreringsfas.

Datavalidering

För varje fil som vi migrerar måste vi utföra dataverifiering för att se till att data inte skadades under migreringsprocessen. Dataverifiering görs genom att jämföra hash-värden före migreringen och efter migreringen. Det finns många typer av hash-algoritmer som kan användas. En vanlig metod är att använda MD5 eftersom Azure Storage innehåller ett fördefinierat metadatafält Content-MD5 som kan fyllas i under migreringen. Med den här metoden kan du kontrollera samma MD5-värde när vi kommer åt data för att verifiera att data inte har ändrats eller skadats. I idealiska situationer innehåller källdata redan hash-värden som enkelt kan jämföras med hashvärden efter migreringen. Om hashvärden inte finns måste de beräknas innan filen migreras. Om hashvärden matchar markeras filen som migrerad. Annars ignoreras filen och migreras igen. Ibland är data skadade på källbanden. Att ha de ursprungliga hashvärdena hjälper till att fånga dessa sällsynta fall. Om de inträffar kan vi läsa data från den sekundära kopian om de finns. Dataverifieringsprocessen är en viktig komponent för en migreringsdesign. Processen för hantering av misslyckad validering måste definieras. Migreringsfasen övervakas också ständigt för att se till att vi kan reagera på oförutsägbara situationer och anpassa oss till den. Regelbunden rapportering till de viktigaste intressenterna är viktigt för att hålla migreringen på rätt spår.

Fas efter migrering

När migreringen är klar finns det fortfarande några steg som vi måste tänka på innan du stänger migreringsprojektet. Vi måste ta bort maskinvara som används för migreringen, om det inte behövs längre. Den viktigaste frågan är hur man gör sig av med banden. Bandhantering är en process i två steg. Om band lagrar känslig och konfidentiell information (och det gör de vanligtvis) måste de först degausseras. Degaussing säkerställer att alla data tas bort magnetiskt från mediet. Efter borttagningen måste band förstöras korrekt och återvinnas. Om vi använde en bandmigreringspartner kan vi också låta partnern ta bort banden på ett säkert sätt.

Nästa steg