Migrera Oracle-arbetsbelastningar till Azure
Som en del av molnimplementeringsresan måste du migrera dina befintliga arbetsbelastningar till molnet. Oracle-arbetsbelastningar liknar andra arbetsbelastningar och kräver en metodisk metod för att säkerställa en lyckad migrering. Mer information om migreringsmetod finns i Molnmigrering i Cloud Adoption Framework för Azure. Den här artikeln beskriver begränsningar och överväganden som är specifika för Oracle-arbetsbelastningar.
Oracle-migreringsscenarier
När du migrerar Oracle-arbetsbelastningar måste du överföra databaser och program. I den här artikeln beskrivs lift-and-shift-metoden för program- och databasmigreringar. Lift-and-shift-metoden omfattar distribution av Oracle-program på Azure Virtual Machines. För databasmigrering är flera alternativ tillgängliga. Den här artikeln innehåller vägledning som gäller för Oracle Database@Azure.
program på virtuella datorer: Köra Oracle-företagsprogram, till exempel Siebel, PeopleSoft, JD Edwards, E-Business Suite eller anpassade WebLogic Server-program i Azure-infrastrukturen.
Oracle Standard Edition- eller Enterprise Edition-databaser på virtuella datorer: I det här scenariot distribuerar du oracledatabasen på en virtuell dator. Det finns flera tillgängliga alternativ, från självhanterade till hanterade databaser. Om du föredrar en hanterad databaslösning kan du läsa Tessell.
Oracle Database@Azure: Oracle Database@Azure är en Oracle-databastjänst som körs på Oracle Cloud Infrastructure (OCI) och som är samlokaliserad i Microsofts datacenter.
Anteckning
Information om vilka operativsystem som stöds för din specifika databasversion finns i databaser och operativsystem som stöds.
Oracle-migreringsprocessen
Du bör kontinuerligt omvärdera dina infrastrukturkrav för att förbättra prestanda och minska kostnaderna med hjälp av relevant typ av tjänst för din arbetsbelastning. För alla scenarier som nämnts tidigare bör du till exempel se till att det finns tillräckligt med bandbredd för migreringen. Vi rekommenderar starkt att du granskar den bandbredd som behövs när du utför ett konceptbevis (PoC).
Om du flyttar din arbetsbelastning till Oracle på virtuella datorer kontrollerar du att storleken på den virtuella datorn (VM) uppfyller dina krav. Mer information finns i Kapacitetsplanering för migrering av Oracle-arbetsbelastningar till Azure-landningszoner.
Granska migreringsresurserna för att definiera din Oracle-till Azure-migreringsprocess. Du kan även:
- Verifiera kvotgränser för Azure-prenumerationer: Kontrollera att kvotgränserna i din Azure-prenumeration kan hantera de vm-målstorlekar som du väljer om du migrerar till Oracle på virtuella datorer.
Not
Om du kör din arbetsbelastning på Oracle Database@Azure och behöver en kvotökning kan du kontakta din Oracle-kontakt.
Identifiera en distributionsmodell: Automatisera distributionen av lösningskomponenter så mycket som möjligt genom att använda infrastruktur som kod, kontinuerlig integrering och pipelines för kontinuerlig leverans och andra DevOps-metoder.
Fastställa programberoenden: Se till att migreringsaktiviteterna är så icke-störande som möjligt.
Identifiera datakapacitet: Identifiera mängden data som ska migreras och utvärdera den aktuella tillgängliga nätverksanslutningskapaciteten från lokala miljöer till Azure. Använd den här informationen för att avgöra om du kan kopiera data direkt från lokala miljöer till Azure. Du kan behöva en fysisk dataöverföringsenhet som Azure Data Box för den första datainläsningen.
Fastställ tillgänglighetskrav: Fastställ kraven för arbetsbelastningstillgänglighet eftersom de kan påverka de migreringsverktyg som du kan använda. Definiera din maximala godkända stilleståndstid. Det här måttet hjälper dig att definiera migreringsverktyget och -metoden.
Det här övervägandet gäller även för din ansökan. Om du inte kan acceptera ett avbrott i dina dagliga åtgärder måste du utföra en onlinemigrering.
- Fastställ verktygen för att migrera din arbetsbelastning till Oracle på virtuella Azure-datorer: De två primära migreringsvägarna är offline och online.
| Offlinemigrering | Online migrering |
|---|---|
| Direkt kopiering av databasen vid ett tillfälle. | Första kopian av databasen följt av insamling av ändringsdata under migreringen. |
| Kräver att det berörda programmet är offline under migreringen. | Programmet kan vara online under migreringen. |
| Verktyg som används: Data Box, DataPump, Oracle Recovery Manager (RMAN) | verktyg som används: DataGuard, Oracle Recovery Manager (RMAN), GoldenGate |
Not
Om du bestämmer dig för att utföra en onlinemigrering kontrollerar du att du konfigurerar brandväggsregler för att tillåta dataöverföring.
Arbetsbelastningsspecifika aktiviteter för Oracle-migrering
I följande avsnitt beskrivs migreringsprocessen mer detaljerat. Stegen är inte nödvändigtvis sekventiella. Du kan utföra vissa steg parallellt.
Utvärdera käll- och målsystemversionerna: Utvärdera om de lokala operativsystemversionerna, programversionerna och databasversionerna är samma lokala och i Azure.
Om du behöver uppdatera en eller flera resurser uppdaterar du dem före migreringen för att förenkla migreringsprocessen.
Om din lokala databas körs på ett storslutsoperativt operativsystem, till exempel Oracle Solaris, IBM Advanced Interactive eXecutive eller Hewlett Packard Unix, innehåller databasmigreringsprocessen en endiansk konvertering. Azure Support endast små endianska operativsystem. Den här begränsningen minskar antalet tillgängliga verktyg för migreringen. Mer specifikt kan du inte använda Oracle Data Guard eller någon annan filkopieringsmetod. Migreringsmetoder som är kompatibla med endiansk konvertering inkluderar Oracle Data Pump Export eller Oracle Data Pump Import, Oracle cross-platform transportable tablespaces (XTTS) eller datareplikeringsverktyg som Oracle GoldenGate, Quest SharePlex och Striim.
Du kan modernisera eller migrera lokala programservrar beroende på krav och kompatibilitet. Mer information finns i Scenarier för molnimplementering.
Utvärdera kraven på arbetsbelastningstillgänglighet under migreringsprocessen: Om du behöver minimera arbetsbelastningens stilleståndstid kanske inte migreringsmetoder som Export av datapump eller Import av datapump passar din arbetsbelastning. I så fall följer du den här fyrastegsprocessen:
Använd RMAN för att säkerhetskopiera och sedan återställa hela databasen i Azure. Utför en endiansk konvertering via XTTS om det behövs. Resultatet är en databas som är en tidpunktskopia av den lokala källdatabasen. Mer information finns i Transportera data mellan plattformar.
Om båda källorna använder little-endian-format, använd Oracle Data Guard för att synkronisera den nyligen återställda databasen i Azure med källdatabasen. Du kan inte använda Data Guard om migreringen inkluderar big-endian till little-endian-konvertering. Använd i stället ett SQL-baserat datareplikeringsverktyg som Oracle GoldenGate, Quest SharePlex eller Striim för att synkronisera den nyligen återställde databasen i Azure med källdatabasen.
När du har synkroniserat måldatabasen i Azure med den lokala källdatabasen kan du schemalägga en snabb uppdatering. En snabb information stänger av den lokala källdatabasen och rensar de senaste transaktionerna till måldatabasen i Azure. Sedan kan du öppna måldatabasen i Azure som den nya källdatabasen. En övergång kan ta så lite som bara några minuter, beroende på vilken synkroniseringsmetod som används.
Beroende på vilken migreringsmetod du väljer för programtjänster kan du behöva utföra flera programtjänstuppgifter innan du helt migrerar programmet till Azure.
Utvärdera nödvändiga licenser: Databasen kan kräva olika licenser, beroende på migreringsverktyget. Till exempel:
Oracle Data Guard kräver Oracle Database Enterprise Edition.
Oracle GoldenGate kräver Oracle GoldenGate-licenser.
Mer information om Oracle-licensiering i Azure finns i Licensiering av Oracle-programvara i molnbaserad databehandlingsmiljö.
Migreringsvägledning för Oracle Database@Azure
Kontrollera att Oracle Database@Azure-lösningen är tillgänglig i den region där du vill distribuera lösningen. Mer information finns i Tillgängliga regioner.
Överväg att använda Oracle Zero Downtime Migration för migreringsprocessen. Utvärdera migreringsstrategierna för att fastställa den lämpligaste metoden för dina specifika migreringskrav. För mer information, se Nollstilleståndsmigrering (ZDM). ZDM ger möjlighet att välja antingen logiska eller fysiska migreringsscenarier. Mer information finns i ZDM-migrering.
Not
Om du väljer Autonom databastjänst (ADB-S) bör du tänka på att endast scenarier för logisk migrering stöds.
Annan vägledning
Följande avsnitt kan hjälpa dig att välja rätt migreringsalternativ för dina krav och datastorlekar.
Referens för ExpressRoute-baserad migreringsvaraktighet
Följande tabell fungerar bara som baslinje. Den tar inte hänsyn till andra produktionsarbetsbelastningar som körs via samma Azure ExpressRoute-anslutning.
VMware kan behöva mer bandbredd än vad som anges. Utvärdera dina bandbreddsbehov under PoC-fasen. Kontakta din lokala kontakt om du behöver support.
| Datastorlek | Bandbredd på 1 gpbs | Bandbredd på 10 Gbit/s |
|---|---|---|
| 1 TB | 3 timmar | 15 minuter |
| 10 terabyte | 1 dag | 3 timmar |
| 35 TB | 4 dagar | 9 timmar |
| 80 TB | 8 dagar | 20 timmar |
| 100 TB | 11 dagar | 1 dag |
| 200 TB | 21 dagar | 2 dagar |
| 500 TB | 53 dagar | 5 dagar |
Om du planerar att använda ExpressRoute för migreringen kontrollerar du att dess motståndskraft uppfyller dina krav.