Planera en datamigrering
Ett dataplattformsmoderniseringsprojekt har fem steg som vanligtvis slutförs i ordning.
I vårt globala detaljhandelsscenario har din styrelse godkänt moderniseringsprojektet och du börjar organisera personal och andra resurser. Om du vill konfigurera och tilldela uppgifter optimalt måste du förstå projektfaserna på djupet.
I den här lektionen utforskar du var och en av de fem stegen mer detaljerat.
Initiera och identifiera
Dataplattformsmoderniseringsprojekt initieras vanligtvis för att uppfylla affärs- eller juridiska krav. Därför är det viktigt att ta hänsyn till dessa behov och få stöd från ledningen. Det första steget är att slutföra en identifieringsövning som innehåller följande överväganden:
Utvärdera aktuell miljö
Många IT-infrastrukturer utvecklas vanligtvis under många år, kanske till och med årtionden. Under den tiden kan företag och personal förändras enormt i den utsträckning som det kanske inte längre finns experter i de system som en organisation har. I vissa sällsynta fall kan organisationer till och med glömma att de fortfarande har vissa system.
Sök efter beroenden mellan befintliga program och databaser
Du bör ta dig tid att förstå hur dina program interagerar med de databaser som finns i nätverket. Dessutom bör du också förstå eventuella beroenden mellan databaser som kan finnas så att du kollektivt kan gruppera databaser i logiska grupper. Genom att utföra den här övningen använder du logiska grupper av databaser som grund för att migrera dem till Azure som en enhet.
Visa en lista över arbetsbelastningstyperna för dina system
En lista över arbetsbelastningstyper mot identifierade databasservrar ger insikt i deras användning. Arbetsbelastningar kan kategoriseras som analytiska (OLAP) eller transaktionella (OLTP) baserat på om de är läs- eller skrivintensiva. Detta hjälper dig att avgöra vilken dataplattformsteknik som ska migreras till. Ytterligare kategorisering kan omfatta batch- eller beslutsstödarbetsbelastningar.
Utvärdering
Under utvärderingsfasen används den information som samlats in under identifieringsfasen för att genomföra en omfattande utvärdering av de identifierade arbetsbelastningarna för att fastställa följande:
- Eventuella migreringsblockerare
- Eventuella icke-bakåtkompatibla ändringar som kräver korrigeringar efter migreringen
- Azure-funktioner som arbetsbelastningarna kan använda
Du upprättar detta genom att slutföra en aktuell utvärdering av arbetsbelastningen och en utvärdering av arbetsbelastningskriterier:
Aktuell arbetsbelastningsbedömning
De identifierade databasservrarna och programmen kategoriseras och bekräftas för att upprätta följande: datavolym och förväntad tillväxt, genomsnittlig resursanvändning och deras allvarlighetsgrad för verksamheten. Det här steget ger också möjlighet att överväga att kombinera eller inaktivera lokala databaser för att minska antalet databaser som ska migreras och sänka den totala ägandekostnaden.
Utvärdering av arbetsbelastningsvillkor
I utvärderingen av arbetsbelastningskriterier använder du resultaten från den aktuella arbetsbelastningsutvärderingen och definierar kriterierna efter migreringen för att köra de identifierade arbetsbelastningarna.
Anta att du har identifierat en mycket använd transaktionsdatabasserver under hög belastning men med låg användning under låg belastning. I utvärderingen av arbetsbelastningskriterier definierar du ett villkor efter migreringen, till exempel att migrera till en Azure SQL Database med automatisk skalning för att hantera högsta belastning.
Planerad
Planeringssteget för ett dataplattformsmoderniseringsprojekt omfattar att fastställa målplattformen, migreringsmetoden och åtgärdsplaner för eventuella planerade eller oplanerade avbrott.
I planeringsfasen av dataplattformens moderniseringsprocess finns det sju termer som beskriver hur du kan hantera program- och dataövergång från en befintlig lokal miljö till en ny molnbaserad miljö (antingen offentlig eller privat):
| # | Fas | Åtgärd | beskrivning |
|---|---|---|---|
| 1. | Förbli | Gör ingenting | Fortsatt modernisering med tanke på långsiktiga alternativ för återstående lokala tjänster. |
| 2. | Värdbyte | Migrera till IaaS | Den här metoden tar bort behovet av datacenterhantering och ger en högre avkastning på investeringen (ROI) genom en lägre total ägandekostnad (TCO). |
| 3. | Refaktorisering | Migrering till IaaS eller PaaS med minimala programändringar | Den här metoden tar bort behovet av datacenterhantering och ger en högre avkastning på investeringen (ROI) genom en lägre total ägandekostnad (TCO). Det kan också ge lägre hanteringskostnader genom konsolidering av databaser. |
| 4. | Arkitekturomarbetning | Skriva om viktiga aspekter av programmet för att använda molntekniker | Det möjliggör användning av moderna komponenter, minskar koddistributionen och underlättar DevOps-distribution av infrastruktur och tjänster. |
| 5. | Återskapa | Återskapa programmet för att använda PaaS- eller serverlösa tekniker | Om du återskapar dataplattformar och program med nyare teknik kan du använda Azures inbyggda hög tillgänglighet, öka programmets portabilitet och skalbarhet och minimera potentiella kunskapsluckor mellan den teknik som används och personalen som stöder/utvecklar programmet. |
| 6. | Replace | Ersätt programmet med ett nyare program eller En SaaS-lösning | Överväg att ersätta när ett program har beroenden på fysiska enheter som är anslutna till servern eller när det är nära integrerat med lokal infrastruktur. |
| 7. | Pensionera | Inaktivera program som inte längre krävs | Metoden dra tillbaka bör övervägas när äldre program och databaser inte längre används eftersom det inte finns något affärs- eller lagkrav för att behålla dem. |
Diagrammet nedan visar hur mycket arbete varje term kräver jämfört med det värde som företaget får från migreringen.
Plattformsmålalternativ
Det finns två tillgängliga alternativ på hög nivå när det gäller att välja målplattform.
Infrastruktur som en tjänst (IaaS) – I den här metoden migrerar du dina data till en virtuell dator som har SQL Server installerat.
Plattform som en tjänst (PaaS) – I den här metoden migrerar du dina data till en dataplattformstjänst som passar din arbetsbelastning. För transaktionsarbetsbelastningar skulle det omfatta Azure SQL Database eller Azure SQL Managed Instance. För arbetsbelastningar av typen Online Analytical Processing (OLAP) skulle detta omfatta Azure Synapse Analytics.
Välja målplattform efter funktioner
Azure SQL Database – Använd om programytan är databasomfång. SQL Database erbjuder en lösning med lågt underhåll som kan vara ett bra alternativ för vissa arbetsbelastningar.
Elastiska Pooler i Azure SQL Database – Med elastiska pooler kan du allokera lagrings- och beräkningsresurser till en grupp databaser i stället för att behöva hantera resurser för varje databas individuellt. Dessutom är elastiska pooler enklare att skala än enskilda databaser, där skalning av enskilda databaser inte längre behövs på grund av ändringar i den elastiska poolen.
Serverlös Azure SQL Database – Det är effektivt för att sänka kostnaderna i utvecklings- och testmiljöer. Med funktionen för automatisk pausfördröjning kan du ange den inaktiva perioden innan databasen pausas automatiskt. Du kan välja mellan 1 timme och 7 dagar eller inaktivera den. När du öppnar databasen igen återupptas den och medför endast lagringsavgifter under pausen.
Azure SQL Managed Instance – skulle vara lämpligt för användning om programytan är instansomfång och kräver funktioner som inte är tillgängliga i Azure SQL Database, till exempel:
- SQL Agent
- MSDTC
- DQS
- MDS
- Database Mail
- PolyBase
- Stöd för länkade servrar
- Stöder nya Azure-molntjänster som hotidentifiering
SQL Server på en virtuell Azure-dator – Används om programytan är instansomfång och kräver funktioner som inte är tillgängliga i Azure SQL Managed Instance, till exempel SQL Server Reporting Services (SSRS), SQL Server Analysis Services (SSAS) och SQL Server Integration Services (SSIS).
Azure Synapse Analytics – Använd om du har program som kör komplexa frågor över stora mängder data som kan dra nytta av massivt parallell bearbetning (MPP) för att minska frågebearbetningstiderna.
Om du vill visa en lista över funktioner som stöds i varje PaaS-erbjudande för SQL kan du läsa Om hur du jämför funktioner: Azure SQL Database och Azure SQL Managed Instance.
Välja målplattform efter kostnad
Azure SQL Database – Azure SQL Databases plattform som en tjänst-karaktär minskar avsevärt administrations- och hanteringskostnaderna jämfört med den mer traditionella SQL Server på Azure IaaS-topologin, eftersom det mesta av det arbete som krävs slutförs tyst i bakgrunden av Microsoft. I stor skala kan man göra betydande besparingar i tid och ansträngning.
Elastiska Pooler i Azure SQL Database – Elastiska Pooler i Azure SQL Database ger betydande besparingar för flera databaser med oförutsägbara användningskrav. Beräkningsresurser delas, vilket undviker överetablering och minskar kostnaderna för serverunderhåll och administration.
Azure SQL Managed Instance – SQL Managed Instance erbjuds till de kunder som vill ha en fullständigt hanterad tjänst, där de enkelt kan lyfta och flytta sin lokala miljö med minimala konfigurationsändringar. Miljön erbjuder minst 8 kärnor och upp till 8 TB lagringsutrymme och finns i ett isolerat virtuellt nätverk. Det här erbjudandet är bra för kunder som snabbt vill komma till molnet och som vill undvika att behöva underhålla virtuella datorer.
SQL Server på en virtuell Azure-dator – Jämfört med PaaS-erbjudanden har SQL Server som körs på virtuella Azure-datorer högre kostnader för beräkning, lagring och hantering, men ger större kontroll över SQL Server och infrastruktur.
Azure Synapse Analytics – Azure Synapse Analytics kan minska kostnaderna genom att använda MPP-arkitekturen för att bearbeta komplexa frågor på några minuter i stället för timmar.
Offline- eller onlinemigreringar
I planeringsfasen bör du överväga om du utför en offlinemigrering eller en onlinemigrering. Med offlinemigreringar börjar programavbrott samtidigt som migreringen startar. Om du vill begränsa stilleståndstiden till den tid som krävs för att skära ned till den nya miljön när migreringen är klar använder du en onlinemigrering. Vi rekommenderar att du testar en offlinemigrering för att avgöra om stilleståndstiden är acceptabel. om inte, gör en onlinemigrering. Dessutom kanske alternativen online och offline inte är tillgängliga beroende på vilken Azure-plattform som valts.
Transformera och optimera
Din utvärdering och planering skulle ha identifierat aspekter av dina program och databaser som skulle kräva arbete efter migreringen som antingen transformerar eller optimerar en funktion för att säkerställa en lyckad migrering. Omvandling innebär vanligtvis arbete som kräver att du åtgärdar eller ändrar en aspekt av en databas.
Optimering innebär vanligtvis att du gör en ändring i den migrerade databasen för att dra nytta av en funktion eller optimerar dess användning i Azure.
En transformering kan till exempel innebära att du ändrar en lagrad procedur eller SQL-fråga som innehåller syntax som inte stöds i måldatabasen. Detta skulle kräva att syntaxen justeras för att säkerställa kompatibilitet med den nya databasplattformen, vilket säkerställer att den lagrade proceduren eller frågan körs smidigt utan problem i målmiljön.
Transformera
För att säkerställa en lyckad upplevelse efter migreringen kan en eller flera av följande ändringar behöva göras i en databas.
Installera versionsuppgraderingar före migrering
Åtgärda eventuella fel som identifieras av migreringsutvärderingsverktygen
Implementera ändringar i databasschemat
Migrera befintliga integrerade databastjänster till Azure
Hantera SSIS-arbetsbelastningar i molnet
Optimize (Optimera)
Det kan finnas en eller flera av följande optimeringsriktlinjer som du vill följa under migreringen för att säkerställa att din organisation får ut mesta möjliga av sin investering i Azure.
Utvärdera vilka nya funktioner som kan vara tillgängliga på målplattformen
Omstrukturera arbetsbelastningar till mer kostnadseffektiva eller prestandaeffektiva uppsättningar
Välj den högsta tjänstnivån och prestandanivån under migreringen och skala ned när migreringen är klar
Se till att arbetsbelastningarna har rätt storlek
Minimera avståndet mellan BACPAC-filen och måldatacentret
Inaktivera automatisk statistik under migreringen
Partitionstabeller och index
Ta bort indexerade vyer och återskapa dem när de är klara
Migrera, verifiera och åtgärda
Den här fasen omfattar själva migreringen, och framför allt de verifieringssteg och reparationssteg som krävs för att bekräfta en lyckad migrering. De tidigare planerings-, utvärderings- och omvandlingsstegen har säkerställt att allt är redo att migreras och fungera korrekt när det har flyttats till Azure. Allt som återstår att göra är att förbereda de migreringsverktyg som krävs, slutföra migreringen och köra funktions- och prestandavalidering efter migreringen för att säkerställa datakonsekvens med källdatabasen.
Överväganden för migrering, validering och reparation
Det finns ett brett utbud av verktyg som kan användas för att utföra migreringen till den valda målplattformen. De här verktygen beskrivs i andra moduler. Under tiden är det viktigt att tänka på följande när du slutför migreringen:
- Förstå dina arbetsbelastningskrav som utgångspunkt
- Välj icke-kritiska arbetsbelastningar eller databaser med låg prioritet för migrering från början
- Kör en testmigrering
- Testa databasen för problem
- Testa planen för att minska risken för driftstopp och kompatibilitetsproblem
- Utvärdera migreringsverktyg baserat på avbrott för att minska risken för databasavbrott
- Iterera kontinuerligt om migreringsprocessen
- Överväg underhållsperioderna som är tillgängliga för programmet och databasen som är avsedda för migrering
- Koppla från gamla databaser och program
- Testa program från tredje part
- Skapa nya planer för haveriberedskap och underhåll