Att tänka på vid migrering

24 minuter

Ett affärssystem som körs lokalt kan ha en arkitektur som är kopplad till andra tjänster som arbetar i samma miljö. Det är viktigt att förstå relationerna mellan ett system som du vill migrera och de andra program och tjänster som din organisation använder för närvarande.

I ditt teknikstartföretag används leverantörsdatabasen för att säkerställa att komponenter alltid finns i lager och anländer just-in-time för användning i tillverkningsprocessen. Lageransvariga använder mobila enheter för att uppdatera den här databasen när sändningar anländer och köpare använder en webbplats för att övervaka lagernivåer och identifiera den bästa tiden att beställa. Chefer använder en uppsättning affärskritiska rapporter för att övervaka processen och förbättra effektiviteten. Du vill se till att ingen av dessa användare påverkas negativt av migreringen till Azure.

Här får du lära dig hur du planerar och utför en smidig databasmigrering till molnet.

Undersöka beroenden

I ett komplext system fungerar en komponent sällan helt oberoende. I stället anropas andra processer och komponenter. Databaser kan till exempel vara beroende av katalogtjänster som är värdar för användarkonton. Kan du komma åt katalogtjänsten när du flyttar en databas till molnet? Om inte, hur loggar användarna in? När du förbiser ett beroende som detta kan det uppstå ett totalt fel i databasen.

Kontrollera om databasen är beroende av tjänster som följande för att minska riskerna:

Katalogtjänster, till exempel Active Directory.
Andra lager med säkerhetsobjekt.
Andra databaser.
Webb-API:er eller andra nätverkstjänster.

Kom också ihåg att andra komponenter kan vara beroende av din databas. Vilka är konsekvenserna om du flyttar databasen utan att konfigurera om de beroende komponenterna? Om du till exempel flyttar en produktkatalogdatabas och den offentliga webbplatsen är beroende av den för att avgöra vilka produkter som ska presenteras för användarna, kommer flytten att orsaka ett avbrott i tjänsten?

Kontrollera om någon av dessa typer av komponenter är beroende av databasen:

Webbplatser och webb-API:er.
Klientappar, till exempel mobilappar och skrivbordsprogram.
Andra databaser.
Rapporter.
Informationslager.

För att göra dessa kontroller kan du prata med intressenter, administratörer och utvecklare som är involverade i varje databas och systemkomponent. Läs sedan dokumentationen om du inte är säker på att du förstår systemens beteende, överväg att köra tester, till exempel nätverksinsamlingar för att observera beteendet.

Förbered för att falla tillbaka

I alla migreringsprojekt bör du alltid vara beredd på ett fel. I ett databasmigreringsprojekt till molnet är den värsta eventualiteten att den nya databasen blir otillgänglig och att användarna inte kan utföra sina jobb. Det är vanligt att minska den här risken, som kan ha stor inverkan på företagets lönsamhet, genom att planera att återställa till den ursprungliga, oförändrade databasen lokalt.

Överväg följande för reservplanen:

Hur ser du till att du kan återgå till en databas som inte berörs av den misslyckade migreringen? Vi rekommenderar till exempel att du gör en fullständig säkerhetskopia av databasen precis innan du påbörjar migreringen.
Hur länge är det acceptabelt att databasen är offline om du behöver gå tillbaka?
Hur mycket budget har du för reservplanen? Har du till exempel råd att replikera databasen till en dedikerad reservserver? I så fall kan du stänga av servern precis före migreringen. För att falla tillbaka startar du den här servern. Du skulle omedelbart ha en databas som inte påverkas av migreringen, utan att behöva återställa den från säkerhetskopian.

Offline- och onlinemigrering

Om du vill migrera en databas har du minst två alternativ:

Kommentar

Onlinealternativet är för närvarande inte tillgängligt för MySQL-databaser i Data Migration Service.

Stoppa systemet, överför databasen och konfigurera sedan om och starta om systemet för att använda den nya databasen. Det här är en offlinemigrering.
Håll systemet igång medan du flyttar databasen till den nya platsen, rulla vidare transaktioner som utförs mot den ursprungliga databasen till den nya databasen medan migreringen pågår och växla sedan dina program för att ansluta till den nya databasen. Det här är en onlinemigrering.

Det är enklare att utföra en offlinemigrering, där användarna inte kan ändra data under migreringen. Men om databasen är upptagen eller kritisk för att din organisation ska lyckas kanske det inte är möjligt.

Offlinemigrering

Anta att databasen stöder ett team av analytiker som alla arbetar i en enda tidszon under normal kontorstid. Teamet brukar inte arbeta på helgerna. Mellan 18:00 på fredag och 09:00 på söndagar används inte databasen ofta.

I den här situationen kan du utföra en offlinemigrering under helgen genom att följa dessa steg:

Ta databasen offline när alla transaktioner har slutförts på fredag kväll.
Gör en fullständig säkerhetskopiering eller export av databasen.
Stäng av den lokala servern och behåll den om du behöver falla tillbaka.
Återställ databasen i målmolnsystemet.
Aktivera målsystemet.
Konfigurera om klienter för att ansluta till molndatabasen.

I det här fallet är en offlinemigrering möjlig eftersom det finns en lång period då ett avbrott i tjänsten har liten effekt på användarna. Under den här tiden kan du göra en fullständig säkerhetskopiering och återställning av databasen med vetskapen om att du inte missar några ändringar.

Onlinemigreringar

Överväg nu en annan databas som stöder en försäljningsapp. Säljpersonal distribueras runt om i världen och arbetar även på helger. Det finns inte en period med låg aktivitet, databasen är alltid upptagen och om du tar databasen offline under en längre period kommer den att påverka användarna. Försäljningsaktiviteten är affärskritisk, så ett avbrott i tjänsten kommer att ha en direkt effekt på organisationens resultat.

I fall som detta bör du överväga att utföra en onlinemigrering. Vid en onlinemigrering är stilleståndstiden begränsad till den tid det tar att växla till den nya databasen. Använd ett verktyg som Azure Data Migration Service för att utföra en onlinemigrering. Onlinemigreringar har följande skillnader i offlinemigreringar:

Du flyttar inte den ursprungliga databasen offline innan du säkerhetskopierar eller exporterar den.
Medan migreringen pågår gäller ändringarna för den gamla databasen.
Migreringsverktyget ser till att dessa ändringar kopieras till den nya databasen innan växlingen över. Detta uppnås ofta genom att konfigurera om den gamla databasen för att replikera ändringar till den nya.

Migrering av program

När du har migrerat en databas, hur (och när) ska du gå över till det nya systemet och uppdatera program för att använda den nya databasen? Du kan:

Flytta program en i taget till den nya databasen.
Flytta delmängder av användare.
Anta en kombination av båda metoderna.

Avsikten är att du utför programmigrering i små steg som enkelt kan återställas om något går snett. Oavsett om du har följt en offline- eller onlinemetod för databasmigrering bör du fortfarande ha en fungerande konfiguration i den ursprungliga källan. I teorin kan du snabbt växla tillbaka till den ursprungliga källan. Men om data ändras hela tiden måste du tänka på var dessa ändringar har gjorts.

I en offlinemigrering är källan och destinationerna oberoende av varandra. Användare och program kanske inte längre ser en konsekvent vy över data. I ett transaktionssystem är den här situationen sannolikt oacceptabel. I det här fallet skulle du behöva underhålla någon form av dubbelriktad replikering mellan databaser medan båda systemen förblir aktiva. Om syftet med ett program är att generera månatliga eller veckovisa rapporter, generera försäljningsprognoser eller utföra andra statistiska åtgärder kanske den här bristen på konsekvens inte är så oroande. Sådana program har en "lång vy" av data i stället för att vara beroende av aktuella data. I det senare fallet använder transaktionsprogram den nya databasen, medan rapporteringsprogram flyttas långsammare.
I en onlinemigrering synkroniseras den nya databasen med den gamla, vanligtvis av någon form av replikering. Replikeringsprocessen kan vara asynkron, så det kan uppstå en fördröjning. Ändringar som görs i data i den nya databasen sprids dock inte tillbaka till det gamla, vilket resulterar i möjliga konflikter. Ett program som körs mot den gamla databasen kan göra en motstridig ändring av data som har ändrats i den nya databasen. Replikeringen skriver blind över ändringen i den nya databasen, vilket resulterar i en "förlorad uppdatering".

Metoder för testning

Om databasen spelar en viktig roll i din verksamhet kan konsekvenserna av ett fel bli omfattande. Om du vill öka ditt förtroende för att detta inte sker kan du överväga att köra prestandatester mot den migrerade databasen för att säkerställa att den hanterar belastningen som användarna kan placera på den och svara snabbt. Kom ihåg att det kan finnas perioder med hög aktivitet, när efterfrågan är mycket högre än normalt. Du måste vara säker på att det migrerade systemet hanterar den förväntade arbetsbelastningen.

Utför alltid någon typ av regressionstestning mot den nya databasen innan du tillåter åtkomst till användare. Dessa tester kontrollerar att systemets beteende och funktionalitet är korrekta.

Dessutom bör du överväga att köra ett "blötläggningstest". Ett blöttest är ett belastningstest som utformats för att se hur systemet som helhet fungerar under tryck. Ett genomblöt test belastar den nya databasen och avgör om den är stabil under hög efterfrågan. Ett blöttest körs under en betydande tidsperiod för att se vad som händer när hög efterfrågan kvarstår.

När du har fastställt att det nya systemet är stabilt kan du börja migrera användare. Du kan dock behöva ytterligare garantier för att användarna kommer att finna det nya systemet acceptabelt. Nu kan du överväga "kanarietestning". Ett kanarietest dirigerar transparent en liten delmängd användare till det nya systemet, men de är inte medvetna om att de har åtkomst till det. Det är en form av blindtest som gör att du kan hitta problem eller problem med det nya systemet. Övervaka svaren från dessa användare och gör eventuella justeringar som krävs.

Underhålla parallella system

Det finns flera orsaker till varför du kan välja att köra den gamla lokala databasen parallellt med den nya molndatabasen:

Testperioder. Som du såg i föregående avsnitt är det en bra idé att köra kanarietester mot den migrerade databasen för att utvärdera dess funktioner, stabilitet och kapacitet innan du använder den för att stödja personer. Att underhålla det lokala systemet parallellt ger dig ett snabbt sätt att återställa användare till det gamla systemet om det finns problem med det nya systemet.
Stegvisa migreringar. Ett sätt att minimera effekten av oväntade fel på produktionen är att flytta ett litet antal användare till det nya systemet först och övervaka resultatet. Om allt fungerar smidigt kan du flytta andra grupper av användare när du får förtroende för den nya databasen. Du kan flytta användare alfabetiskt, efter avdelning, plats eller roll tills alla finns i den nya databasen.
Bitmeella migreringar. En annan metod är att segmentera migreringen inte efter användare, utan efter arbetsbelastning. Du kan till exempel migrera databastabellerna som har stöd för personalresurser före dem som stöder försäljning.

I alla dessa fall finns det en period då den gamla lokala databasen körs parallellt med den nya molndatabasen. Du måste se till att ändringar som gjorts i den gamla databasen också tillämpas på den nya databasen och att de flödar i motsatt riktning. Du kan skripta den här synkroniseringen eller använda ett verktyg som Azure Data Migration Service.

Om du bestämmer dig för att underhålla parallella databaser och synkronisera ändringar kan du ställa dig följande frågor:

Konfliktlösning. Är det troligt att en ändring av en rad lokalt sker vid en liknande tidpunkt som en annan ändring av samma rad i molnet? Detta skulle skapa en konflikt, där det är oklart vilken ändring som ska behållas. Hur skulle du lösa sådana konflikter?
Nätverkstrafik. Hur mycket nätverkstrafik genereras när ändringar synkroniseras mellan databaser? Har du tillräckligt med nätverkskapacitet för den här trafiken?
Svarstid. Vilken fördröjning (om någon) är acceptabel innan ändringen når den andra databasen när det sker en ändring i en av databaserna? I en produktkatalog kan du till exempel vänta i upp till en dag innan nya produkter visas för alla användare. Men om databasen innehåller viktig transaktionsinformation, till exempel valutakurser, bör dessa data synkroniseras mycket oftare, om inte omedelbart.

Bitmeal migrering

En bitmigrering är där du delar upp ett komplett system i arbetsbelastningar och migrerar en arbetsbelastning i taget.

Flera databaser

Ett komplext system kan innehålla flera databaser som stöder flera arbetsbelastningar. Personalavdelningen kan till exempel använda StaffDB-databasen , medan säljteamet kan ha mobilappar som frågar både ProductCatalogDB-databasen och OrdersDB-databasen .

Du kan naturligtvis välja att migrera hela databassystemet till molnet på en gång. Det kan vara enklare eftersom du inte behöver köra databaser både lokalt och i molnet. Du behöver inte tänka på hur dessa databaser kommunicerar under migreringen. Risken för fel är dock högre. Ett enda problem kan påverka både personalteamet och säljteamet.

Överväg att minska dessa risker för medelstora och stora databassystem genom att utföra en bitmigrering, där du flyttar en arbetsbelastning i taget. I det här exemplet kan du överväga att migrera StaffDB-databasen först, eftersom problemen som är kopplade till ett fel skulle begränsas till personalteamet och inte skulle hindra dig från att ta order. Genom att lösa eventuella problem som uppstår med StaffDB-migreringen får du lära dig de lärdomar som gäller för andra arbetsbelastningsmigreringar.

Sedan kan du fundera på att migrera arbetsbelastningen Produktkatalog till molnet. Om du gör det kan du överväga frågor som:

Hur ser du till att produkter som nyligen har lagts till i katalogen är tillgängliga för beställning?
Behöver du synkronisera data med OrdersDB-databasen , som förblir lokal?
Vilken svarstid är acceptabel för nya produkter att nå OrdersDB-databasen från produktkatalogen?

Enkel databas bitmeal migrering

Även om du bara har en enda databas som stöder alla arbetsbelastningar kan du fortfarande överväga en bitmigrering. Du kan till exempel dela upp databasen i följande delar:

Tabeller som stöder HR-åtgärder.
Tabeller som stöder försäljning.
Tabeller som stöder analys och rapportering.

Om du migrerar HR-operationstabellerna först påverkar eventuella problem som endast uppstår HR-personal. Försäljnings- och dataanalytiker fortsätter att arbeta med den gamla databasen utan avbrott.

Innan du utför en bitmigrering måste du fullt ut förstå databaserna och hur de används av program. Vissa tabeller i databasen kan till exempel ha stöd för både försäljning och rapportering. Det innebär att du inte kan dela upp arbetsbelastningar rent. Du måste synkronisera dessa tabeller mellan lokala databaser och molndatabaser tills alla arbetsbelastningar har migrerats.

Säkerhetsfrågor

Dina databaser kan innehålla känsliga data, till exempel produktinformation, personlig personalinformation och betalningsinformation, så säkerhet är alltid en hög prioritet. Du måste bestämma hur du ska skydda dessa data under migreringen och i den nya databasen.

Brandväggsskydd

I ett Internetanslutet program skyddas databasservrar vanligtvis av minst två brandväggar. Den första brandväggen separerar Internet från klientdelsservrarna – om dessa servrar till exempel är värdar för webbplatser eller webb-API:er. Endast TCP-port 80 ska vara öppen i den yttre brandväggen, men den här porten måste vara öppen för alla käll-IP-adresser, förutom blockerade adresser.

Den andra brandväggen separerar klientdelsservrarna från databasservrarna. Vi rekommenderar att du publicerar databastjänsten på ett privat portnummer som inte är känt för omvärlden. I den andra brandväggen öppnar du endast det här portnumret för IP-adresserna för klientdelsservrarna. Det här arrangemanget förhindrar all direkt kommunikation från en illasinnad Internetanvändare till databasservrarna.

Om du planerar att migrera databasservrar till virtuella Azure-datorer använder du ett virtuellt nätverk med nätverkssäkerhetsgrupper (NSG:er) för att replikera brandväggsregler. Om du använder Azure Database for MySQL, Azure Database for MariaDB eller Azure Database for PostgreSQL kan du skapa brandväggsregler för att skydda databasen med hjälp av Anslut ionssäkerhetssidan för servern i Azure-portalen.

Autentisering och auktorisering

I de flesta databaser måste du noga kontrollera vem som kommer åt och ändrar vilka data. Den här kontrollen kräver att användarna identifieras positivt när de ansluter till databasen. Den här processen kallas autentisering och görs vanligtvis med användarnamn och lösenord. Databassystem som MySQL, MariaDB och PostgreSQL tillhandahåller egna autentiseringsmekanismer. Du måste se till att du fortsätter att autentisera användare på ett säkert sätt när du migrerar dina system till molnet.

Kommentar

Tjänsterna Azure Database for MySQL, Azure Database for MariaDB och Azure Database for PostgreSQL emulerar traditionell MySQL-, MariaDB- och PostgreSQL-autentisering.

När du vet vem användaren är måste du tilldela dem behörighet att slutföra de uppgifter som ingår i deras jobb. Den här processen kallas auktorisering.

För ett databasmigreringsprojekt måste du se till att användarna har rätt behörighet i molndatabasen:

Ta reda på var användarkonton lagras i det lokala systemet. I MySQL lagras användarkonton vanligtvis i tabellen mysql i user databasen, men det är till exempel möjligt att integrera med användarkonton som lagras i Active Directory.
Hämta en lista över alla användarkonton. I MySQL kan du till exempel använda det här kommandot:
```
SELECT host, user FROM mysql.user;
```
Ta reda på vilken åtkomst de har till databasen för varje användarkonto. I MySQL kan du till exempel använda det här kommandot för användarkontot dbadmin@on-premises-host :
```
SHOW GRANTS FOR 'dbadmin'@'on-premises-host';
```
Återskapa varje användarkonto i molndatabasen. I MySQL kan du till exempel använda det här kommandot för att skapa ett nytt konto:
```
CREATE USER 'dbadmin'@'cloud-host'
```
Auktorisera varje användarkonto till rätt åtkomstnivå i molndatabasen. I MySQL kan du till exempel använda det här kommandot för att tillåta en användare att komma åt hela databasen:
```
GRANT USAGE ON *.* TO 'dbadmin'@'cloud-host'
```

Kryptering

När data skickas över nätverket kan de fångas upp av en så kallad "man-in-the-middle"-attack. För att förhindra detta har både Azure Database for MySQL, Azure Database for MariaDB och Azure Database for PostgreSQL stöd för SSL (Secure Sockets Layer) för kryptering av kommunikation. SSL tillämpas som standard och vi rekommenderar starkt att du inte ändrar den här inställningen.

Du kan behöva ändra klientprogrammens anslutningsinställningar för att använda SSL-kryptering. Diskutera det här avsnittet med dina utvecklare för att avgöra vilka ändringar, om några, som är nödvändiga.

Övervakning och hantering

En del av planeringen för att migrera en databas är att överväga hur databasadministratörer ska fortsätta att utföra sina uppgifter efter migreringen.

Övervakning

Lokala databasadministratörer används för att övervaka regelbundet för att upptäcka problem som flaskhalsar i maskinvara eller konkurrens om nätverksåtkomst. De övervakar för att säkerställa att de kan åtgärda eventuella problem innan produktiviteten påverkas. Du kan förvänta dig att alla databaser som inte övervakas regelbundet börjar orsaka problem förr eller senare.

Du bör använda exakt samma metod för molndatabaser. Det kan vara enklare att lösa problem i ett PaaS-system som Azure, eftersom du kan lägga till resurser utan att köpa, konfigurera och konfigurera maskinvara. Du behöver dock fortfarande upptäcka problem med utveckling, så övervakning är en hög prioritet bland dina dagliga uppgifter.

Innan du migrerar databaser till molnet ska du ta reda på vilka övervakningsverktyg som administratörerna använder för närvarande. Om dessa verktyg är kompatibla med den föreslagna molnbaserade lösningen kanske du bara behöver återansluta dem till de migrerade databaserna. Annars måste du undersöka alternativ.

Tänk på att Azure innehåller en uppsättning verktyg för prestandaövervakning och samlar in en mängd olika prestandaräknare och loggdata. Du visar dessa data med hjälp av instrumentpaneler och diagram i Azure-portalen genom att konfigurera Azure Monitor. Du skapar anpassade grafer, tabeller och rapporter, särskilt utformade för dina administratörers behov.

Hantering

Databasadministratörerna använder önskade verktyg för att ändra schemat och innehållet i databasen lokalt. Om de använder samma verktyg efter migreringen kan du fortsätta att dra nytta av deras expertis. Börja med att utvärdera om den befintliga uppsättningen verktyg är kompatibel med den föreslagna molnbaserade databasen. Många verktyg är kompatibla eftersom de baseras på allmänt antagna standarder som SQL, men det är viktigt att kontrollera kompatibiliteten. Om de aktuella hanteringsverktygen inte fungerar efter migreringen kan du försöka identifiera alternativ med dina administratörer.

Azure innehåller flera verktyg som du kan använda för att administrera MySQL-, MariaDB- och PostgreSQL-databaser:

Azure-portalen. Den här webbplatsen har kraftfulla funktioner som du använder för att konfigurera, övervaka och hantera databaser – och alla andra resurser som du kan skapa i Azure-molnet.
Azure PowerShell. Det här är en skriptkörningsmiljö och ett språk som har en bred uppsättning kommandon. Använd PowerShell, som är tillgängligt för Windows- och Linux-miljöer, för att automatisera komplexa administrativa uppgifter för databaser.
Azure CLI. Det här är ett kommandoradsgränssnitt till Azure. Använd den för att hantera tjänster och resurser i Azure. Du kan använda CLI från Windows- och Linux-gränssnittsmiljöerna och inifrån Bash-skript.

Fortsätt