Share via

Prestaties van Oracle-databases in Azure NetApp Files op meerdere volumes

  • Artikel

Het migreren van zeer presterende Exadata-databases naar de cloud wordt steeds belangrijker voor Microsoft-klanten. Softwaresuites van de toeleveringsketen stellen doorgaans de bar hoog in vanwege de intensieve eisen voor opslag-I/O met een gemengde lees- en schrijfworkload die wordt aangestuurd door één rekenknooppunt. De Azure-infrastructuur in combinatie met Azure NetApp Files kan voldoen aan de behoeften van deze zeer veeleisende workload. Dit artikel bevat een voorbeeld van hoe aan deze vraag voor één klant is voldaan en hoe Azure kan voldoen aan de vereisten van uw kritieke Oracle-workloads.

Oracle-prestaties op ondernemingsniveau

Bij het verkennen van de bovengrens van prestaties is het belangrijk om eventuele beperkingen te herkennen en te verminderen die onwaar scheeftrekkende resultaten kunnen opleveren. Als de bedoeling bijvoorbeeld is om prestatiemogelijkheden van een opslagsysteem te bewijzen, moet de client idealiter worden geconfigureerd, zodat CPU geen beperkingsfactor wordt voordat de opslagprestatielimieten worden bereikt. Daarom is testen gestart met het E104ids_v5 exemplaartype, omdat deze VM niet alleen is uitgerust met een netwerkinterface van 100 Gbps, maar met een even grote uitgaande limiet van 100 Gbps.

Het testen is in twee fasen opgetreden:

  1. De eerste fase was gericht op testen met behulp van het nu industriestandaard SLOB2-hulpprogramma van Kevin Closson (Silly Little Oracle Benchmark) - versie 2.5.4. Het doel is om zoveel mogelijk Oracle I/O te stimuleren van één virtuele machine (VM) naar meerdere Azure NetApp Files-volumes en vervolgens uit te schalen met behulp van meer databases om lineair schalen te demonstreren.
  2. Na het testen van schaallimieten hebben onze tests voor de goedkopere, maar bijna net zo geschikte E96ds_v5 voor een klantfase van het testen met behulp van een echte Supply Chain-toepassingsworkload en echte gegevens.

SLOB2-prestaties omhoog schalen

In de volgende grafieken wordt het prestatieprofiel vastgelegd van één E104ids_v5 Azure-VM waarop één Oracle 19c-database wordt uitgevoerd op acht Azure NetApp Files-volumes met acht opslageindpunten. De volumes worden verdeeld over drie ASM-schijfgroepen: gegevens, logboeken en archiveren. Er zijn vijf volumes toegewezen aan de gegevensschijfgroep, twee volumes aan de logboekschijfgroep en één volume aan de archiefschijfgroep. Alle resultaten die in dit artikel zijn vastgelegd, zijn verzameld met behulp van azure-productieregio's en actieve Azure-services voor productie.

Als u Oracle wilt implementeren op virtuele Azure-machines met behulp van meerdere Azure NetApp Files-volumes op meerdere opslageindpunten, gebruikt u de toepassingsvolumegroep voor Oracle.

Architectuur met één host

In het volgende diagram ziet u de architectuur waarop het testen is voltooid; Noteer de Oracle-database verspreid over meerdere Azure NetApp Files-volumes en -eindpunten.

Diagram van een Oracle-subnet met een Azure NetApp Files-capaciteitspool.

Io voor opslag met één host

In het volgende diagram ziet u een willekeurig geselecteerde workload van 100% met een databasebuffertrefferverhouding van ongeveer 8%. SLOB2 kon ongeveer 850.000 I/O-aanvragen per seconde aandrijven, terwijl een sequentiële leesgebeurtenislatentie van een db-bestand in submilliseconden wordt onderhouden. Met een databaseblokgrootte van 8K die ongeveer 6.800 MiB/s aan opslagdoorvoer bedraagt.

Grafiek met willekeurige opslag-I/O met één host.

Doorvoer met één host

In het volgende diagram ziet u dat Azure NetApp Files voor bandbreedte-intensieve opeenvolgende IO-workloads, zoals volledige tabelscans of RMAN-activiteiten, de volledige bandbreedtemogelijkheden van de E104ids_v5 VM zelf kan leveren.

Staafdiagram met sequentiële doorvoer met één host.

Notitie

Omdat het rekenproces zich op het theoretische maximum van de bandbreedte bevindt, resulteert het toevoegen van extra gelijktijdigheid van toepassingen alleen in een verhoogde latentie aan de clientzijde. Dit resulteert in SLOB2-workloads die de beoogde voltooiingsperiode overschrijden. Het aantal threads is daarom beperkt tot zes.

Uitschalen van SLOB2-prestaties

In de volgende grafieken wordt het prestatieprofiel vastgelegd van drie E104ids_v5 Azure-VM's waarop elk één Oracle 19c-database wordt uitgevoerd en elk met een eigen set Azure NetApp Files-volumes en een identieke indeling van de ASM-schijfgroep, zoals beschreven in de sectie Prestaties opschalen. In de grafische weergaven ziet u dat met Azure NetApp Files meerdere volumes/meerdere eindpunten de prestaties eenvoudig kunnen worden uitgeschaald met consistentie en voorspelbaarheid.

Architectuur met meerdere hosts

In het volgende diagram ziet u de architectuur waarop het testen is voltooid; let op de drie Oracle-databases verspreid over meerdere Azure NetApp Files-volumes en -eindpunten. Eindpunten kunnen worden toegewezen aan één host, zoals wordt weergegeven met Oracle VM 1 of gedeeld tussen hosts, zoals wordt weergegeven met Oracle VM2 en Oracle VM 3.

Diagram van automatisch opslagbeheer van Oracle voor Azure NetApp Files.

Io voor opslag met meerdere hosts

In het volgende diagram ziet u een willekeurig geselecteerde workload van 100% met een databasebuffertrefferverhouding van ongeveer 8%. SLOB2 kon ongeveer 850.000 I/O-aanvragen per seconde per seconde aanbrengen op alle drie de hosts afzonderlijk. SLOB2 kon dit bereiken tijdens het parallel uitvoeren van een collectief totaal van ongeveer 2.500.000 I/O-aanvragen per seconde, waarbij elke host nog steeds een sequentiële leesgebeurtenislatentie van een submillisecond db-bestand onderhoudt. Met een databaseblokgrootte van 8K bedraagt dit ongeveer 20.000 MiB/s tussen de drie hosts.

Lijndiagram van collectieve willekeurige opslag vanuit een IO-perspectief.

Doorvoer met meerdere hosts

In het volgende diagram ziet u dat Azure NetApp Files voor sequentiële workloads nog steeds de volledige bandbreedtemogelijkheden van de E104ids_v5 VM zelf kan leveren, zelfs wanneer deze naar buiten wordt geschaald. SLOB2 kon I/O in totaal meer dan 30.000 MiB/s op de drie hosts rijden terwijl deze parallel wordt uitgevoerd.

Gestapeld staafdiagram van collectieve opeenvolgende doorvoer.

Prestaties in de praktijk

Nadat schaallimieten zijn getest met SLOB2, werden tests uitgevoerd met een real-word supply chain-toepassingssuite tegen Oracle in Azure NetApp-bestanden met uitstekende resultaten. De volgende gegevens uit het AWR-rapport (Oracle Automatic Workload Repository) is een gemarkeerd overzicht van de uitvoering van een specifieke kritieke taak.

Deze database heeft een aanzienlijke extra I/O die wordt uitgevoerd naast de workload van de toepassing omdat flashback is ingeschakeld en een databaseblokgrootte van 16k heeft. Uit de io-profielsectie van het AWR-rapport blijkt dat er een zware verhouding van schrijfbewerkingen is in vergelijking met leesbewerkingen.

- Lezen en schrijven per seconde Lezen per seconde Schrijven per seconde
Totaal (MB) 4,988.1 1,395.2 3,592.9

Ondanks de opeenvolgende leeswachtgebeurtenis van het db-bestand met een hogere latentie van 2,2 ms dan in de SLOB2-test, zag deze klant een vermindering van de uitvoeringstijd van vijftien minuten die afkomstig is van een RAC-database op Exadata naar een individuele exemplaardatabase in Azure.

Beperkingen voor Azure-resources

Alle systemen raken uiteindelijk resourcebeperkingen, ook wel bekend als chokepoints. Databaseworkloads, met name zeer veeleisende workloads, zoals supply chain-toepassingssuites, zijn resource-intensieve entiteiten. Het vinden van deze resourcebeperkingen en het ermee werken is essentieel voor elke succesvolle implementatie. In deze sectie worden verschillende beperkingen verlicht die u in zo'n omgeving kunt tegenkomen en hoe u deze kunt doorlopen. In elke subsectie verwacht u dat u zowel best practices als logica erachter leert.

Virtuele machines

In deze sectie worden de criteria beschreven die moeten worden overwogen bij het selecteren van VM's voor de beste prestaties en de logica achter selecties die zijn gemaakt voor het testen. Azure NetApp Files is een NAS-service (Network Attached Storage), daarom is de juiste grootte van de netwerkbandbreedte essentieel voor optimale prestaties.

Chipsets

Het eerste onderwerp van belang is de chipsetselectie. Zorg ervoor dat elke VM-SKU die u selecteert, is gebouwd op één chipset om consistentieredenen. De Intel-variant van E_v5 VM's wordt uitgevoerd op een derde generatie Intel Xeon Platinum 8370C -configuratie (Ice Lake). Alle VM's in deze familie zijn uitgerust met één 100 Gbps-netwerkinterface. Daarentegen is de E_v3 serie, die bijvoorbeeld wordt genoemd, gebouwd op vier afzonderlijke chipsets, met verschillende fysieke netwerkbandbreedten. De vier chipsets die worden gebruikt in de E_v3 familie (Broadwell, Skylake, Cascade Lake, Haswell) hebben verschillende processorsnelheden, die van invloed zijn op de prestatiekenmerken van de machine.

Lees de Documentatie voor Azure Compute zorgvuldig met aandacht voor de chipsetopties. Raadpleeg ook de aanbevolen procedures voor Azure VM-SKU's voor Azure NetApp Files. Het selecteren van een VIRTUELE machine met één chipset verdient de voorkeur voor de beste consistentie.

Beschikbare netwerkbandbreedte

Het is belangrijk om inzicht te hebben in het verschil tussen de beschikbare bandbreedte van de VM-netwerkinterface en de bandbreedte met datalimiet die op hetzelfde is toegepast. Wanneer azure Compute-documentatie spreekt over netwerkbandbreedtelimieten, worden deze limieten alleen toegepast op uitgaand verkeer (schrijven). Inkomend verkeer (leesverkeer) wordt niet gemeten en wordt als zodanig alleen beperkt door de fysieke bandbreedte van de NIC zelf. De netwerkbandbreedte van de meeste VM's overschrijdt de limiet voor uitgaand verkeer die wordt toegepast op de computer.

Omdat Azure NetApp Files-volumes zijn gekoppeld aan het netwerk, kan de limiet voor uitgaand verkeer worden begrepen als worden toegepast op schrijfbewerkingen, met name terwijl inkomend verkeer wordt gedefinieerd als lees- en leesachtige workloads. Hoewel de limiet voor uitgaand verkeer van de meeste machines groter is dan de netwerkbandbreedte van de NIC, kan hetzelfde niet worden gezegd voor de E104_v5 die worden gebruikt bij het testen van dit artikel. De E104_v5 heeft ook een NIC van 100 Gbps met de limiet voor uitgaand verkeer ingesteld op 100 Gbps. Ter vergelijking: de E96_v5, met de 100 Gbps-NIC, heeft een uitgaand verkeer van 35 Gbps met inkomend verkeer van 100 Gbps. Naarmate VM's kleiner worden, nemen de limieten voor uitgaand verkeer af, maar blijven inkomend verkeer ongehinderd door logisch opgelegde limieten.

Uitgaande limieten zijn VM-breed en worden als zodanig toegepast op alle netwerkworkloads. Wanneer u Oracle Data Guard gebruikt, worden alle schrijfbewerkingen verdubbeld voor het archiveren van logboeken en moet rekening worden gehouden met overwegingen voor uitgaand verkeer. Dit geldt ook voor archieflogboeken met meerdere bestemmingen en RMAN, indien gebruikt. Wanneer u VM's selecteert, moet u vertrouwd raken met dergelijke opdrachtregelprogramma's als ethtool, die de configuratie van de NIC beschikbaar maken omdat Azure geen netwerkinterfaceconfiguraties documenteert.

Gelijktijdigheid van netwerk

Azure-VM's en Azure NetApp Files-volumes zijn uitgerust met specifieke hoeveelheden bandbreedte. Zoals eerder wordt weergegeven, kan een workload, zolang een VIRTUELE machine voldoende CPU-ruimte heeft, in theorie de bandbreedte verbruiken die beschikbaar is gesteld aan de vm, die binnen de grenzen van de netwerkkaart en of uitgaande limiet is toegepast. In de praktijk wordt echter de hoeveelheid haalbare doorvoer vooraf aangegeven door de gelijktijdigheid van de werkbelasting in het netwerk, namelijk het aantal netwerkstromen en netwerkeindpunten.

Lees de sectie netwerkstroomlimieten van het document over de bandbreedte van het VM-netwerk voor meer inzicht in. Het leerpunt: hoe meer netwerkstromen de client verbinden met opslag, hoe rijker de mogelijke prestaties zijn.

Oracle ondersteunt twee afzonderlijke NFS-clients, Kernel NFS en Direct NFS (dNFS). Kernel NFS ondersteunde tot laat één netwerkstroom tussen twee eindpunten (compute – opslag). Direct NFS, hoe beter presterend van de twee, ondersteunt een variabel aantal netwerkstromen: tests hebben honderden unieke verbindingen per eindpunt getoond, waardoor de belastingsvereisten toenemen of afnemen. Vanwege het schalen van netwerkstromen tussen twee eindpunten heeft Direct NFS verre de voorkeur boven Kernel NFS, en als zodanig de aanbevolen configuratie. Azure NetApp Files-productgroep raadt het gebruik van Kernel NFS met Oracle-workloads niet aan. Raadpleeg de voordelen van het gebruik van Azure NetApp Files met Oracle Database voor meer informatie.

Gelijktijdigheid van uitvoering

Door direct NFS te gebruiken, één chipset voor consistentie en inzicht te krijgen in netwerkbandbreedtebeperkingen, wordt u tot nu toe alleen gebruikt. Uiteindelijk worden de prestaties van de toepassing bepaald. Proofs of concept using SLOB2 and proofs of concept using a real-world supply chain application suite against real customer data waren in staat aanzienlijke hoeveelheden doorvoer te stimuleren omdat de toepassingen in hoge mate van gelijktijdigheid werden uitgevoerd; de voormalige met behulp van een aanzienlijk aantal threads per schema, de laatste met behulp van meerdere verbindingen van meerdere toepassingsservers. Kortom, gelijktijdigheidsstations, lage gelijktijdigheid, lage doorvoer, hoge gelijktijdigheid, hoge gelijktijdigheid, zolang de infrastructuur aanwezig is om hetzelfde te ondersteunen.

Versneld netwerken

Met Versnelde netwerken wordt I/O-virtualisatie met één hoofdmap (SR-IOV) mogelijk voor een VM, waarmee de netwerkprestaties van de VM aanzienlijk worden verbeterd. Dit pad met hoge prestaties omzeilt de host van het gegevenspad, waardoor latentie, jitter en CPU-gebruik worden verminderd voor de meest veeleisende netwerkworkloads op ondersteunde VM-typen. Wanneer u VM's implementeert via hulpprogramma's voor configuratiebeheer, zoals terraform of opdrachtregel, moet u er rekening mee houden dat versneld netwerken niet standaard is ingeschakeld. Voor optimale prestaties kunt u versneld netwerken inschakelen. Houd er rekening mee dat versneld netwerken per netwerkinterface is ingeschakeld of uitgeschakeld. De functie versneld netwerken is een functie die dynamisch kan worden ingeschakeld of uitgeschakeld.

Notitie

Dit artikel bevat verwijzingen naar de term SLAVE, een term die Microsoft niet meer gebruikt. Zodra de term uit de software wordt verwijderd, verwijderen we deze uit dit artikel.

Een gezaghebbende benadering voor het uitvoeren van versneld netwerken is ingeschakeld voor een NIC via de Linux-terminal. Als versneld netwerken is ingeschakeld voor een NIC, is er een tweede virtuele NIC aanwezig die is gekoppeld aan de eerste NIC. Deze tweede NIC wordt geconfigureerd door het systeem waarvoor de SLAVE vlag is ingeschakeld. Als er geen NIC aanwezig is met de SLAVE vlag, is versneld netwerken niet ingeschakeld voor die interface.

In het scenario waarin meerdere NIC's zijn geconfigureerd, moet u bepalen welke SLAVE interface is gekoppeld aan de NIC die wordt gebruikt om het NFS-volume te koppelen. Het toevoegen van netwerkinterfacekaarten aan de VIRTUELE machine heeft geen invloed op de prestaties.

Gebruik het volgende proces om de toewijzing te identificeren tussen de geconfigureerde netwerkinterface en de bijbehorende virtuele interface. Dit proces valideert dat versneld netwerken is ingeschakeld voor een specifieke NIC op uw Linux-computer en de fysieke snelheid van inkomend verkeer weergeeft die de NIC mogelijk kan bereiken.

  1. Voer de ip a opdracht uit: Schermopname van de uitvoer van een IP-opdracht.
  2. Vermeld de /sys/class/net/ map van de NIC-id die u verifieert (eth0 in het voorbeeld) en grep voor het woord lager: 
    ls /sys/class/net/eth0 | grep lower lower_eth1
  3. Voer de ethtool opdracht uit op het ethernetapparaat dat in de vorige stap is geïdentificeerd als het lagere apparaat. Schermopname van uitvoer van instellingen voor eth1.

Azure VM: bandbreedtelimieten voor netwerken versus schijven

Er is een expertiseniveau vereist bij het lezen van documentatie over prestatielimieten voor Azure-VM's. Let op:

  • Tijdelijke opslagdoorvoer en IOPS-nummers verwijzen naar de prestatiemogelijkheden van de kortstondige on-box-opslag die rechtstreeks aan de VIRTUELE machine is gekoppeld.
  • Schijfdoorvoer en I/O-nummers die niet in de cache zijn opgeslagen, verwijzen specifiek naar Azure Disk (Premium, Premium v2 en Ultra) en hebben geen invloed op opslag die is gekoppeld aan het netwerk, zoals Azure NetApp Files.
  • Het koppelen van extra NIC's aan de VIRTUELE machine heeft geen invloed op prestatielimieten of prestatiemogelijkheden van de VIRTUELE machine (gedocumenteerd en getest om waar te zijn).
  • De maximale netwerkbandbreedte verwijst naar uitgaande limieten (dat wil gezegd: schrijfbewerkingen wanneer Azure NetApp Files betrokken is) die worden toegepast op de bandbreedte van het VM-netwerk. Er worden geen toegangslimieten (dat wil gezegd, leesbewerkingen wanneer Azure NetApp Files betrokken is) toegepast. Gezien voldoende CPU, voldoende netwerk gelijktijdigheid en voldoende eindpunten kan een VIRTUELE machine theoretisch inkomend verkeer naar de limieten van de NIC sturen. Zoals vermeld in de sectie Beschikbare netwerkbandbreedte , gebruikt u hulpprogramma's om ethtool de bandbreedte van de NIC te bekijken.

Er wordt een voorbeeldgrafiek weergegeven ter referentie:

Schermopname van een tabel met voorbeeldgrafiekgegevens.

Azure NetApp Files

Azure NetApp Files biedt een maximaal beschikbare, volledig beheerde opslagoplossing die ondersteuning biedt voor de veeleisende Oracle-workloads die eerder zijn geïntroduceerd.

Aangezien de limieten voor opslagprestaties opschalen in een Oracle-database goed worden begrepen, richt dit artikel zich bewust op de prestaties van uitschalen van opslag. Het uitschalen van de opslagprestaties impliceert dat één Oracle-exemplaar toegang krijgt tot veel Azure NetApp Files-volumes waar deze volumes worden gedistribueerd over meerdere opslageindpunten.

Door een databaseworkload op een dergelijke manier over meerdere volumes te schalen, worden de prestaties van de database niet gekoppeld aan zowel volume- als eindpuntlimieten. Omdat de opslag geen prestatiebeperkingen meer oplegt, wordt de VM-architectuur (CPU-, NIC- en VM-uitgaande limieten) het knikpunt om mee te maken. Zoals vermeld in de sectie VM, zijn de E104ids_v5- en E96ds_v5-exemplaren geselecteerd, rekening houdend met dit.

Of een database nu op één volume met grote capaciteit wordt geplaatst of over meerdere kleinere volumes wordt verdeeld, de totale financiële kosten zijn hetzelfde. Het voordeel van het distribueren van I/O over meerdere volumes en eindpunten in tegenstelling tot één volume en eindpunt is het vermijden van bandbreedtelimieten. U kunt volledig gebruiken waarvoor u betaalt.

Belangrijk

Als u azure NetApp Files in een multiple volume:multiple endpoint configuratie wilt implementeren, neemt u contact op met uw Azure NetApp Files Specialist of Cloud Solution Architect voor hulp.

Database

De databaseversie 19c van Oracle is de huidige versie voor de lange termijn van Oracle en de versie die wordt gebruikt om alle testresultaten te produceren die in dit document worden besproken.

Voor de beste prestaties zijn alle databasevolumes gekoppeld met behulp van direct NFS, wordt Kernel NFS aanbevolen tegen vanwege prestatiebeperkingen. Voor een prestatievergelijking tussen de twee clients raadpleegt u de prestaties van oracle-databases op enkele volumes van Azure NetApp Files. Houd er rekening mee dat alle relevante dNFS-patches (Oracle Support ID 1495104) zijn toegepast, zoals de best practices die worden beschreven in het Rapport Oracle Databases in Microsoft Azure met behulp van het Rapport Azure NetApp Files .

Oracle en Azure NetApp Files ondersteunen zowel NFSv3 als NFSv4.1, omdat NFSv3 het meest volwassen protocol is, wordt het over het algemeen gezien als de meest stabiele en betrouwbaardere optie voor omgevingen die zeer gevoelig zijn voor onderbrekingen. Het testen dat in dit artikel wordt beschreven, is allemaal voltooid via NFSv3.

Belangrijk

Enkele van de aanbevolen patches die Oracle-documenten in de ondersteunings-id 1495104 zijn essentieel voor het behouden van gegevensintegriteit bij het gebruik van dNFS. De toepassing van dergelijke patches wordt sterk aangeraden voor productieomgevingen.

Automatisch opslagbeheer (ASM) wordt ondersteund voor NFS-volumes. Hoewel ASM doorgaans gekoppeld is aan blokopslag waarbij ASM zowel LVM (Logical Volume Management) als bestandssysteem vervangt, speelt ASM een waardevolle rol in multivolume NFS-scenario's en is het een belangrijke overweging. Een dergelijk voordeel van ASM, dynamische online toevoeging van en herbalanceren van nieuw toegevoegde NFS-volumes en -eindpunten, vereenvoudigt het beheer waardoor zowel prestaties als capaciteit kunnen worden uitgebreid. Hoewel ASM niet op zichzelf de prestaties van een database verhoogt, voorkomt het gebruik ervan hete bestanden en de noodzaak om bestandsdistributie handmatig te onderhouden, een voordeel dat gemakkelijk te zien is.

Er is een ASM via dNFS-configuratie gebruikt om alle testresultaten te produceren die in dit artikel worden besproken. In het volgende diagram ziet u de indeling van het ASM-bestand binnen de Azure NetApp Files-volumes en de bestandstoewijzing aan de ASM-schijfgroepen.

Diagram van Oracle Automatic Storage Management met Azure NetApp Files.

Er zijn enkele beperkingen met het gebruik van ASM via Azure NetApp Files NFS gekoppelde volumes als het gaat om opslagmomentopnamen die kunnen worden opgelost met bepaalde architecturale overwegingen. Neem contact op met uw Azure NetApp Files-specialist of cloudoplossingenarchitect voor een diepgaande beoordeling van deze overwegingen.

Synthetische testhulpprogramma's en tunables

In deze sectie worden de testarchitectuur, tunables en configuratiedetails in details beschreven. Hoewel de vorige sectie gericht is op redenen waarom configuratiebeslissingen worden genomen, richt deze sectie zich specifiek op de 'wat' van configuratiebeslissingen.

Geautomatiseerde implementatie

  • De database-VM's worden geïmplementeerd met behulp van bash-scripts die beschikbaar zijn op GitHub.
  • De indeling en toewijzing van meerdere Azure NetApp Files-volumes en -eindpunten worden handmatig voltooid. U moet voor hulp samenwerken met uw Azure NetApp Files Specialist of Cloud Solution Architect.
  • De rasterinstallatie, ASM-configuratie, database maken en configureren en SLOB2-omgeving op elke machine wordt geconfigureerd met Ansible voor consistentie.
  • Parallelle SLOB2-testuitvoeringen op meerdere hosts worden ook voltooid met Ansible voor consistentie en gelijktijdige uitvoering.

VM-configuratie

Configuratie Weergegeven als
Azure-regio Europa -west
VM-SKU E104ids_v5
Aantal NIC's 1 OPMERKING: Het toevoegen van vNIC's heeft geen invloed op het aantal systemen
Maximale netwerkbandbreedte voor uitgaand verkeer (Mbps) 100.000
Tijdelijke opslag (SSD) GiB 3,800

Systeemconfiguratie

Alle vereiste systeemconfiguratie-instellingen voor Oracle voor versie 19c zijn geïmplementeerd volgens de Oracle-documentatie.

De volgende parameters zijn toegevoegd aan het /etc/sysctl.conf Linux-systeembestand:

  • sunrpc.max_tcp_slot_table_entries: 128
  • sunrpc.tcp_slot_table_entries = 128

Azure NetApp Files

Alle Azure NetApp Files-volumes zijn gekoppeld aan de volgende NFS-koppelingsopties.

nfs rw,hard,rsize=262144,wsize=262144,sec=sys,vers=3,tcp

Databaseparameters

Parameters Weergegeven als
db_cache_size 2g
large_pool_size 2g
pga_aggregate_target 3g
pga_aggregate_limit 3g
sga_target 25g
shared_io_pool_size 500m
shared_pool_size 5g
db_files 500
filesystemio_options SETALL
job_queue_processes 0
db_flash_cache_size 0
_cursor_obsolete_threshold 130
_db_block_prefetch_limit 0
_db_block_prefetch_quota 0
_db_file_noncontig_mblock_read_count 0

SLOB2-configuratie

Alle generatie werkbelastingen voor testen is voltooid met behulp van het SLOB2-hulpprogramma versie 2.5.4.

Veertien SLOB2-schema's zijn geladen in een standaard Oracle-tabelruimte en uitgevoerd op basis waarvan, in combinatie met de vermelde slob-configuratiebestandsinstellingen, de SLOB2-gegevensset op 7 TiB zetten. De volgende instellingen weerspiegelen een willekeurige leesuitvoering voor SLOB2. De configuratieparameter SCAN_PCT=0 is gewijzigd SCAN_PCT=100 in tijdens sequentiële tests.

  • UPDATE_PCT=0
  • SCAN_PCT=0
  • RUN_TIME=600
  • SCALE=450G
  • SCAN_TABLE_SZ=50G
  • WORK_UNIT=32
  • REDO_STRESS=LITE
  • THREADS_PER_SCHEMA=1
  • DATABASE_STATISTICS_TYPE=awr

Voor willekeurige leestests zijn negen SLOB2-uitvoeringen uitgevoerd. Het aantal threads is met zes verhoogd, waarbij elke test-iteratie begint vanaf één.

Voor sequentiële tests zijn zeven SLOB2-uitvoeringen uitgevoerd. Het aantal threads is met twee verhoogd met elke testiteratie vanaf één. Het aantal threads is beperkt tot zes als gevolg van het bereiken van de maximale limieten voor netwerkbandbreedte.

Metrische AWR-gegevens

Alle metrische prestatiegegevens zijn gerapporteerd via de Oracle Automatic Workload Repository (AWR). Hier volgen de metrische gegevens die worden weergegeven in de resultaten:

  • Doorvoer: de som van de gemiddelde leesdoorvoer en schrijfdoorvoer uit de sectie AWR-belastingprofiel
  • Gemiddelde lees-IO-aanvragen uit de sectie AWR-laadprofiel
  • Db-bestand sequentiële lees wachtgebeurtenis gemiddelde wachttijd van de AWR Voorgrond wachtgebeurtenissen sectie

Migreren van speciaal ontworpen, ontworpen systemen naar de cloud

Oracle Exadata is een ontworpen systeem, een combinatie van hardware en software die wordt beschouwd als de meest geoptimaliseerde oplossing voor het uitvoeren van Oracle-workloads. Hoewel de cloud aanzienlijke voordelen heeft in het algemene schema van de technische wereld, kunnen deze gespecialiseerde systemen er ongelooflijk aantrekkelijk uitzien voor degenen die de optimalisaties hebben gelezen en bekeken die Oracle heeft gebouwd rond hun specifieke workload(en).

Als het gaat om het uitvoeren van Oracle op Exadata, zijn er enkele veelvoorkomende redenen waarom Exadata wordt gekozen:

  • 1-2 hoge I/O-workloads die natuurlijk geschikt zijn voor Exadata-functies en omdat voor deze workloads belangrijke exadata-functies zijn vereist, zijn de rest van de databases die samen met deze workloads worden uitgevoerd samengevoegd tot de Exadata.
  • Gecompliceerde of moeilijke OLTP-workloads waarvoor RAC moet worden geschaald en die moeilijk te ontwerpen zijn met eigen hardware zonder grondige kennis van Oracle-optimalisatie of technische schulden kunnen niet worden geoptimaliseerd.
  • Onderbenutte bestaande Exadata met verschillende werkbelastingen: dit bestaat door eerdere migraties, het einde van de levensduur op een eerdere Exadata of vanwege een wens om een Exadata intern te werken/te testen.

Het is essentieel dat elke migratie vanuit een Exadata-systeem wordt begrepen vanuit het perspectief van de workloads en hoe eenvoudig of complex de migratie kan zijn. Een secundaire behoefte is om de reden voor de aankoop van Exadata te begrijpen vanuit een statusperspectief. Exadata- en RAC-vaardigheden zijn in hogere vraag en hebben de aanbeveling mogelijk aangestuurd om er een te kopen door de technische belanghebbenden.

Belangrijk

Ongeacht het scenario, de algehele take-away moet zijn, voor elke databaseworkload die afkomstig is van een Exadata, hoe meer eigen Exadata-functies worden gebruikt, hoe complexer de migratie en planning is. Omgevingen die niet intensief gebruikmaken van eigen Exadata-functies hebben mogelijkheden voor een eenvoudiger migratie- en planningsproces.

Er zijn verschillende hulpprogramma's die kunnen worden gebruikt om deze workloadkansen te beoordelen:

  • De automatische workloadopslagplaats (AWR):
    • Alle Exadata-databases hebben een licentie voor het gebruik van AWR-rapporten en verbonden prestatie- en diagnostische functies.
    • Is altijd ingeschakeld en verzamelt gegevens die kunnen worden gebruikt om historische workloadgegevens weer te geven en het gebruik te beoordelen. Piekwaarden kunnen het hoge gebruik van het systeem beoordelen,
    • Grotere venster-AWR-rapporten kunnen de algehele werkbelasting beoordelen, wat waardevol inzicht biedt in het gebruik van functies en hoe de workload effectief naar niet-Exadata kan worden gemigreerd. Piekrapporten van AWR zijn daarentegen het meest geschikt voor prestatieoptimalisatie en probleemoplossing.
  • Het AWR-rapport Global (RAC-Aware) voor Exadata bevat ook een exadata-specifieke sectie, waarin wordt ingezoomd op specifiek Gebruik van Exadata-functies en waardevolle informatie flashcache, flashlogboekregistratie, I/O en andere functiegebruik per database en celknooppunt.

Ontkoppelen van Exadata

Houd rekening met de volgende vragen en gegevenspunten bij het identificeren van Oracle Exadata-workloads die naar de cloud moeten worden gemigreerd:

  • Gebruikt de workload meerdere Exadata-functies, buiten de hardwarevoordelen?
    • Slimme scans
    • Opslagindexen
    • Flash-cache
    • Logboekregistratie van flash
    • Hybride kolomcompressie
  • Wordt de workload efficiënt gebruikt voor exadata-offloading? Wat is de verhouding (meer dan 10% van de DB-tijd) van de workload in de bovenste tijd op de voorgrond met behulp van:
    • Slimme celtabelscan (optimaal)
    • Fysieke gelezen cel met meerdere blokkeringen (minder optimaal)
    • Fysieke leesbewerking van cel met één blok (minst optimaal)
  • Hybrid Columnar Compression (HCC/EHCC): Wat is de gecomprimeerde versus niet-gecomprimeerde verhoudingen:
    • Besteedt de database meer dan 10% van de databasetijd aan het comprimeren en decomprimeren van gegevens?
    • Inspecteer de prestatieverbeteringen voor predicaten met behulp van de compressie in query's: is de waarde die de waarde waard is ten opzichte van de hoeveelheid die is bespaard met compressie?
  • Fysieke IO van cel: Controleer de besparingen van:
    • de hoeveelheid die naar het DB-knooppunt wordt omgeleid om de CPU te verdelen.
    • het aantal bytes dat wordt geretourneerd door slimme scan. Deze waarden kunnen worden afgetrokken in IO voor het percentage fysieke leesbewerkingen van één celblok zodra deze exadata heeft gemigreerd.
  • Let op het aantal logische leesbewerkingen uit de cache. Bepaal of flashcache vereist is in een IaaS-cloudoplossing voor de workload.
  • Vergelijk de fysieke lees- en schrijftotaal bytes met de totale hoeveelheid die in de cache is uitgevoerd. Kan geheugen worden verhoogd om fysieke leesvereisten te elimineren (het is gebruikelijk dat sommigen de SGA verkleinen om offloading voor Exadata af te dwingen)?
  • Bepaal in Systeemstatistieken welke objecten worden beïnvloed door welke statistiek. Als u SQL verder kunt afstemmen, indexeren, partitioneren of andere fysieke afstemming, kan de workload aanzienlijk optimaliseren.
  • Inspecteer initialisatieparameters voor onderstrepingstekens (_) of afgeschafte parameters, die moeten worden gerechtvaardigd vanwege de impact op databaseniveau die ze kunnen veroorzaken bij de prestaties.

Exadata-serverconfiguratie

In Oracle versie 12.2 en hoger wordt een exadata-specifieke toevoeging opgenomen in het globale AWR-rapport. Dit rapport bevat secties die een uitzonderlijke waarde bieden voor een migratie van Exadata.

  • Exadata-versie en systeemdetails

  • Details van waarschuwingen voor celknooppunten

  • Exadata nononline-schijven

  • Uitbijtergegevens voor exadata-besturingssysteemstatistieken

    • Geel/roze: Van zorg. Exadata draait niet optimaal.

    • Rood: De prestaties van Exadata worden aanzienlijk beïnvloed.

    • Cpu-statistiek van exadata-besturingssysteem: topcellen

      • Deze statistieken worden verzameld door het besturingssysteem in de cellen en zijn niet beperkt tot deze database of exemplaren
      • A v en een donkergele achtergrond geven een uitbijterwaarde onder het lage bereik aan
      • A ^ en een lichtgele achtergrond geven een uitbijterwaarde boven het hoge bereik aan
      • De bovenste cellen per percentage CPU worden weergegeven en bevinden zich in aflopende volgorde van percentage CPU
      • Gemiddelde: 39,34% CPU, 28,57% gebruiker, 10,77% sys

      Schermopname van een tabel met de bovenste cellen op percentage CPU.

  • Fysieke blokleesbewerkingen in één cel

  • Flash-cachegebruik

  • Tijdelijke IO

  • Efficiëntie van kolomcache

Belangrijkste database per IO-doorvoer

Hoewel de grootte van evaluaties kan worden uitgevoerd, zijn er enkele vragen over de gemiddelden en de gesimuleerde pieken die zijn ingebouwd in deze waarden voor grote workloads. Deze sectie, aan het einde van een AWR-rapport, is uitzonderlijk waardevol omdat het zowel het gemiddelde flash- als schijfgebruik van de top 10 databases op Exadata weergeeft. Hoewel velen ervan uitgaan dat ze databases willen aanpassen voor piekprestaties in de cloud, is dit niet zinvol voor de meeste implementaties (meer dan 95% ligt in het gemiddelde bereik; met een gesimuleerde piek berekend, is het gemiddelde bereik groter dan 98%). Het is belangrijk om te betalen voor wat er nodig is, zelfs voor de hoogste vraagworkloads van Oracle en het inspecteren van de topdatabases door IO-doorvoer kan handig zijn om inzicht te krijgen in de resourcebehoeften voor de database.

De juiste grootte van Oracle met behulp van de AWR op Exadata

Wanneer u capaciteitsplanning uitvoert voor on-premises systemen, is het alleen natuurlijk dat er aanzienlijke overhead is ingebouwd in de hardware. De over-ingerichte hardware moet de Oracle-workload enkele jaren leveren, ongeacht de toevoegingen van de werkbelasting als gevolg van gegevensgroei, codewijzigingen of upgrades.

Een van de voordelen van de cloud is het schalen van resources in een VM-host en -opslag naarmate de vraag toeneemt. Dit helpt bij het besparen van cloudkosten en licentiekosten die zijn gekoppeld aan processorgebruik (relevant voor Oracle).

De juiste grootte omvat het verwijderen van de hardware uit de traditionele lift-and-shift-migratie en het gebruik van de workloadgegevens van de Automatische workloadopslagplaats (AWR) van Oracle om de werkbelasting op te tillen en te verplaatsen naar berekening en opslag die speciaal is ontworpen om deze te ondersteunen in de cloud van de keuze van de klant. Het juiste formaatproces zorgt ervoor dat de architectuur in de toekomst technische schulden van de infrastructuur verwijdert, architectuurredundantie die zou optreden als duplicatie van het on-premises systeem naar de cloud is gerepliceerd en waar mogelijk cloudservices implementeert.

Experts op het gebied van Microsoft Oracle hebben geschat dat meer dan 80% van de Oracle-databases overbeschikt zijn en dezelfde kosten of besparingen ervaren als ze de tijd nemen om de Oracle-databaseworkload te wijzigen voordat ze naar de cloud migreren. Voor deze evaluatie moeten de databasespecialisten in het team hun mindset verschuiven over hoe ze in het verleden capaciteitsplanning hebben uitgevoerd, maar het is de moeite waard de investering van de belanghebbende in de cloud en de cloudstrategie van het bedrijf.

Volgende stappen