Oracle-workloads migreren naar Azure
Als onderdeel van uw overstap naar de cloud moet u uw bestaande workloads migreren naar de cloud. Oracle-workloads zijn vergelijkbaar met andere workloads en vereisen een methodische benadering om een succesvolle migratie te garanderen. Zie Cloudmigratie in het Cloud Adoption Framework voor Azurevoor meer informatie over migratiemethodologie. In dit artikel worden beperkingen en overwegingen beschreven die specifiek zijn voor Oracle-workloads.
Oracle-migratiescenario's
Wanneer u Oracle-workloads migreert, moet u databases en toepassingen overstappen. In dit artikel wordt de lift-and-shift-benadering voor toepassings- en databasemigraties besproken. De lift-and-shift-benadering omvat de implementatie van Oracle-toepassingen op virtuele Azure-machines. Voor databasemigratie zijn verschillende opties beschikbaar. Dit artikel bevat richtlijnen die van toepassing zijn op Oracle Database@Azure.
toepassingen op virtuele machines: Oracle-bedrijfstoepassingen uitvoeren, zoals Siebel, PeopleSoft, JD Edwards, E-Business Suite of aangepaste WebLogic Server-toepassingen in de Azure-infrastructuur.
Oracle Standard Edition- of Enterprise Edition-databases op virtuele machines: In dit scenario implementeert u uw Oracle Database op een virtuele machine. Er zijn verschillende opties beschikbaar, van zelfbeheerd tot beheerde databases. Als u liever een beheerde databaseoplossing hebt, raadpleegt u Tessell-.
Oracle Database@Azure: Oracle Database@Azure is een Oracle-databaseservice die wordt uitgevoerd op Oracle Cloud Infrastructure (OCI) en die zich in Microsoft-datacenters bevindt.
Notitie
Zie ondersteunde databases en besturingssystemenom ondersteunde besturingssystemen voor uw specifieke databaseversie te bepalen.
Het Oracle-migratieproces
U moet uw infrastructuurvereisten voortdurend opnieuw beoordelen om de prestaties te verbeteren en de kosten te verlagen met behulp van het relevante type service voor uw workload. Voor alle eerder genoemde scenario's moet u er bijvoorbeeld voor zorgen dat er voldoende bandbreedte beschikbaar is voor uw migratie. We raden u ten zeerste aan om de bandbreedte te controleren die nodig is wanneer u een proof of concept (PoC) uitvoert.
Als u uw workload verplaatst naar Oracle op virtuele machines, moet u ervoor zorgen dat de grootten van de virtuele machine (VM) voldoen aan uw vereisten. Zie Capaciteitsplanning voor het migreren van Oracle-workloads naar Azure-landingszones voor meer informatie.
Bekijk de migratiebronnen om uw Oracle-migratieproces naar Azure te definiëren. U kunt ook het volgende doen:
- Quotumlimieten voor Azure-abonnementen controleren: Zorg ervoor dat de quotumlimieten in uw Azure-abonnement geschikt zijn voor de doel-VM-grootten die u kiest als u migreert naar Oracle op virtuele machines.
Notitie
Als u uw workload host op Oracle Database@Azure en een quotumverhoging nodig hebt, neemt u contact op met uw Oracle-contactpersoon.
Een implementatiemodel identificeren: De implementatie van oplossingsonderdelen zoveel mogelijk automatiseren met behulp van infrastructuur als code, continue integratie en pijplijnen voor continue levering en andere DevOps-procedures.
Toepassingsafhankelijkheden bepalen: Zorg ervoor dat migratieactiviteiten zo niet storend mogelijk zijn.
Gegevenscapaciteit identificeren: de hoeveelheid gegevens identificeren die moet worden gemigreerd en de huidige beschikbare netwerkverbindingscapaciteit van on-premises omgevingen naar Azure beoordelen. Gebruik deze informatie om te bepalen of u de gegevens rechtstreeks vanuit on-premises omgevingen naar Azure kunt kopiëren. Mogelijk hebt u een fysiek apparaat voor gegevensoverdracht nodig, zoals Azure Data Box voor de eerste gegevensbelasting.
Beschikbaarheidsvereisten bepalen: De beschikbaarheidsvereisten voor workloads bepalen, omdat deze van invloed kunnen zijn op de migratiehulpprogramma's die u kunt gebruiken. Definieer uw maximaal acceptabele downtime. Deze metrische gegevens helpen u bij het definiëren van uw migratiehulpprogramma's en -benadering.
Deze overweging geldt ook voor uw toepassing. Als u een onderbreking van uw dagelijkse bewerkingen niet kunt accepteren, moet u een onlinemigratie uitvoeren.
- Uw hulpprogramma's bepalen voor het migreren van uw workload naar Oracle op virtuele Azure-machines: De twee primaire migratiepaden zijn offline en online.
| Offlinemigratie | Onlinemigratie |
|---|---|
| Eenmalige directe kopie van de database. | Eerste kopie van de database, gevolgd door wijzigingsgegevens vastleggen tijdens de migratie. |
| Vereist dat de betrokken toepassing offline is tijdens de migratie. | De toepassing kan online blijven tijdens de migratie. |
| Hulpprogramma's die worden gebruikt: Data Box, DataPump, Oracle Recovery Manager (RMAN) | Tools gebruikt: DataGuard, Oracle Recovery Manager (RMAN), GoldenGate |
Notitie
Als u besluit een onlinemigratie uit te voeren, moet u ervoor zorgen dat u firewallregels configureert om gegevensoverdracht toe te staan.
Specifieke activiteiten voor Oracle-migratieworkloads
In de volgende sectie wordt het migratieproces gedetailleerder beschreven. De stappen zijn niet noodzakelijkerwijs opeenvolgend. U kunt enkele stappen parallel uitvoeren.
Evalueer de bron- en doelsysteemversies: Beoordelen of de on-premises besturingssysteemversies, toepassingsversies en databaseversies hetzelfde on-premises en in Azure zijn.
Als u een of meer resources moet bijwerken, moet u deze bijwerken vóór de migratie om het migratieproces te vereenvoudigen.
Als uw on-premises database wordt uitgevoerd op een big-endian-besturingssysteem, zoals Oracle Solaris, IBM Advanced Interactive eXecutive ofHe Unix, bevat het databasemigratieproces een endiane conversie. ondersteuning voor Azure alleen little-endian-besturingssystemen. Deze beperking vermindert het aantal beschikbare hulpprogramma's voor de migratie. U kunt Oracle Data Guard of een andere methode voor het kopiëren van bestanden niet gebruiken. Migratiemethoden die compatibel zijn met endiane conversie zijn onder andere Oracle Data Pump Export of Oracle Data Pump Import, Oracle cross-platform transportable tablespaces (XTTS) of hulpprogramma's voor gegevensreplicatie zoals Oracle GoldenGate, Quest SharePlex en Striim.
U kunt on-premises toepassingsservers moderniseren of migreren, afhankelijk van vereisten en compatibiliteit. Zie Scenario's voor cloudimplementatie voor meer informatie.
Evalueer de vereisten voor de beschikbaarheid van de workload tijdens het migratieproces: Als u de downtime van de werkbelasting wilt minimaliseren, zijn migratiemethoden zoals Gegevenspomp exporteren of Gegevenspomp importeren mogelijk niet geschikt voor uw workload. In dat geval volgt u dit proces met vier stappen:
Gebruik RMAN om een back-up te maken en vervolgens de volledige database in Azure te herstellen. Voer indien nodig een endian-conversie uit via XTTS. Het resultaat is een database die een punt-in-time kopie is van de on-premises brondatabase. Zie Gegevens transporteren op verschillende platforms voor meer informatie.
Als beide bronnen een little-endian-indeling hebben, gebruikt u Oracle Data Guard om de zojuist herstelde database in Azure te synchroniseren met de brondatabase. U kunt Data Guard niet gebruiken als de migratie big-endian-conversie naar little-endian bevat. Gebruik in plaats daarvan een hulpprogramma voor gegevensreplicatie op basis van SQL, zoals Oracle GoldenGate, Quest SharePlex of Striim om de zojuist herstelde database in Azure te synchroniseren met de brondatabase.
Nadat u de doeldatabase in Azure hebt gesynchroniseerd met de on-premises brondatabase, kunt u een cutover plannen. Met een cutover wordt de on-premises brondatabase afgesloten en worden de laatste paar transacties naar de doeldatabase in Azure leeggemaakt. Vervolgens kunt u de doeldatabase in Azure openen als de nieuwe brondatabase. Een cutover kan slechts een paar minuten duren, afhankelijk van de synchronisatiemethode die u gebruikt.
Afhankelijk van de migratiebenadering die u kiest voor toepassingsservices, moet u mogelijk verschillende toepassingsservicetaken uitvoeren voordat u de toepassing volledig naar Azure migreert.
Vereiste licenties evalueren: Uw database kan verschillende licenties vereisen, afhankelijk van de migratiehulpprogramma's. Bijvoorbeeld:
Oracle Data Guard vereist Oracle Database Enterprise Edition.
Oracle GoldenGate vereist Oracle GoldenGate-licenties.
Zie Oracle-software in de cloud-computingomgeving voor meer informatie over Oracle-licenties in Azure.
Migratierichtlijnen voor Oracle Database@Azure
Controleer of de Oracle Database@Azure-oplossing beschikbaar is in de regio waar u de oplossing wilt implementeren. Zie Beschikbare regio's voor meer informatie.
Overweeg om Oracle Zero Downtime-migratie te gebruiken voor het migratieproces. Evalueer de migratiestrategieën om de meest geschikte benadering voor uw specifieke migratievereisten te bepalen. Zie Zero Downtime Migration (ZDM)voor meer informatie. ZDM biedt de mogelijkheid om logische of fysieke migratiescenario's te kiezen. Zie ZDM-migratievoor meer informatie.
Notitie
Als u Autonome databaseservice (ADB-S) kiest, moet u er rekening mee houden dat alleen logische migratiescenario's worden ondersteund.
Andere richtlijnen
In de volgende sectie kunt u de juiste migratieoptie kiezen voor uw vereisten en gegevensgrootten.
ExpressRoute-gebaseerde naslaginformatie over migratieduur
De volgende tabel fungeert alleen als basislijn. Er wordt geen rekening gehouden met andere productieworkloads die via dezelfde Azure ExpressRoute-verbinding worden uitgevoerd.
VMware heeft mogelijk meer bandbreedte nodig dan aangegeven. Evalueer uw bandbreedtebehoeften tijdens de PoC-fase. Neem contact op met uw lokale contactpersoon als u ondersteuning nodig hebt.
| Gegevensgrootte | Bandbreedte van 1 gpbs | Bandbreedte van 10 Gbps |
|---|---|---|
| 1 TB | 3 uur | 15 minuten |
| 10 TB | 1 dag | 3 uur |
| 35 TB | 4 dagen | 9 uur |
| 80 TB | 8 dagen | 20 uur |
| 100 TB | 11 dagen | 1 dag |
| 200 TB | 21 dagen | 2 dagen |
| 500 TB | 53 dagen | 5 dagen |
Als u ExpressRoute wilt gebruiken voor uw migratie, moet u ervoor zorgen dat de tolerantie voldoet aan uw vereisten.