De Oracle Database Appliance

In de meeste gevallen beschikken bedrijven en overheidsinstanties tegenwoordig over grotendeels gevirtualiseerde server-infrastructuur. Veelal wordt hier VMware of Oracle VM Server voor ingezet. Op deze platforms worden dan VM’s geplaatst waarin Linux of Windows Server wordt geïnstalleerd. Vanuit een systeembeheer-oogpunt is dit in het algemeen een handige, efficiënte en overzichtelijke oplossing.

We moeten echter voor ogen houden dat de meerwaarde van server-virtualisatie vooral wordt gevormd door verbetering van beheersbaarheid en kosten-efficiëntie (aangevuld met de mogelijkheid hardware-storingen te kunnen opvangen) maar dat het een generieke oplossing is en niet per definitie de énige of in alle gevallen de béste. Het redeneren vanuit “servers” is niet meer zo vanzelfsprekend als het was. Zoals ontwikkelingen rondom “de Cloud”, Linux- (en met Server 2016 ook Windows-) Containers laten zien, verlaten de voorlopers in de software-industrie in toenemende mate het “server”-concept ten gunste van “services” en ook een Oracle database kan heel goed als een service worden beschouwd. Oracle ’s eigen multitenant-architectuur van database 12c, zelf een vorm van het loslaten van de één-op-één relatie tussen databases en instances, kan ook in dat licht worden gezien.

Als we eenmaal afzien van het denken in servers wordt het zinvol om vóór elke toevoeging/vervanging van een (virtuele) server voor Oracle databases even af te wegen wat het beoogde resultaat moet zijn. Ons inziens is dat eenvoudigweg het zo (kosten)-efficiënt, flexibel en beheersbaar mogelijk aanbieden van één of meer databases. Een eventueel automatisme van het aanmaken van nieuwe VM’s en toevoegen van hypervisor-hosts is dan mogelijk niet altijd optimaal.

Waarom niet?

• Virtualisatie van disks ontneemt de database-software de mogelijkheid om zelf I/O’s te optimaliseren en te verspreiden over disks en controllers. Ook is de database-optimizer gebaat bij een voorspelbaar gedrag van de I/O, wat bij gevirtualiseerde multi-tiered shared storage een probleem kan zijn.
• Onvoorspelbare neven-effecten van tijdelijke belastingspieken op de hypervisor; deze zijn in de VM zelf niet te traceren en een DBA kan niet meer met absolute zekerheid zeggen wat de onderliggende oorzaak van eventuele slechte database-performance is (omdat de hypervisor de fysieke hardware-belasting “verbergt” voor de VM).
• Oracle software-licentiëring is complexer; u dient doorgaans hardware te licentiëren en niet VM’s.
• Efficiency-verlies: aangezien Oracle-software in verreweg de meeste gevallen per processor wordt gelicentiëerd levert het delen van deze processor met meerdere VM’s extra overhead op. Voor elke VM moet een heel Windows/Linux OS worden gedraaid en in het ergste geval moet deze processor zelfs worden gedeeld met niet-database VM’s wat betekent dat u van de gelicentiëerde processorkracht maar een deel kunt gebruiken.

Idealiter is een database-systeem zowel flexibel, goed beheerbaar, inzichtelijk als efficiënt en levert het de best mogelijke prestaties voor de erin geïnvesteerde Euro’s. Wij menen dat Oracle hiervoor een oplossing biedt die zowel consolidatie- als beheervoordelen oplevert; een beetje een on-site database-cloud-in-a-box zo u wilt.

DBA.nl levert, installeert, configureert en beheert al sinds enkele jaren dit gespecialiseerde databasesysteem dat we hierbij breder onder de aandacht willen brengen: de Oracle Database Appliance. Dit apparaat beoogt een geoptimaliseerde alles-in-één oplossing te zijn voor het aanbieden van databases waarbij verhoogde beschikbaarheid (optioneel) is ingebouwd.

Dus…. als uw nieuwsgierigheid nu is geprikkeld lees dan verder

Wat is een Oracle Database Appliance?

De Oracle Database Appliance (ODA) is wat Oracle een “engineered system” noemt. Het is de kleinere broer van de beroemde Oracle Exadata en bevat een compleet, rack-mountable pakket van CPU’s, hoogwaardige opslag, 10 GBit Ethernet en een volledige software-stack. U hoeft slechts de stroom en netwerkaansluitingen te leveren.

Op het oog lijkt het wellicht onaantrekkelijk om een nieuw type systeem in uw omgeving te introduceren want niemand zit te wachten op een onnodige introductie van nieuwe kennis-vereisten en procedures voor software-patching, firmware-updates, disk-/netwerk-configuratie, hardware-onderhoud, etc.

Die eventuele vrees is echter ongegrond. De ODA is van meet af aan bedoeld als een systeem dat zich relatief eenvoudig laat inrichten en beheren. Een zelf samengesteld geheel van opslag, netwerk-switches, server-hardware, Operating System en Oracle database vereist goede kennis van al deze componenten om het te configureren, beheren en upgraden. De ODA is daarentegen al zo gebouwd dat de componenten gegarandeerd op elkaar zijn afgestemd en is in die zin plug-and-play. Aan het beheer is ook gedacht. De ODA is voorzien van slimme tooling die het mogelijk maakt om met één utility controle te houden van systeemconfiguratie tot aan het aanmaken/verwijderen/upgraden van databases. Dit single point of control maakt het beheer van een ODA niet alleen heel consistent maar maakt het ook onnodig tot in detail te weten hoe de individuele componenten worden aangestuurd.

Omdat het een compleet systeem is levert Oracle geconsolideerde patches voor software en firmware. Er hoeven door een beheerder geen losse updates voor drivers, databases, operating system, etc. bij elkaar te worden gezocht. Dit verkleint de kans op problemen omdat geen afzonderlijke controles meer nodig zijn op het betrouwbaar samenwerken van hardware, storage, netwerk, operating system en database-software. Ook is het systeem voorzien van volledig hardware-support. De machine kan hierdoor in zijn geheel worden beheerd en onderhouden door een DBA zonder dat training of assistentie van systeembeheerders nodig is. Inderdaad, de machine staat gewoon on-site maar legt geen beslag op de capaciteit van uw systeembeheerders. Een ODA bevat (Linux) nodes voor het draaien van de databases maar door de verregaande systeemintegratie en gespecialiseerde functie ervan hoeven deze niet als te beheren platforms te worden behandeld die zouden moeten worden aangepast aan een bestaande infrastructuur.

Hoewel een ODA normaliter als bare-metal systeem wordt geleverd en ingezet is het overigens óók mogelijk om deze met behulp van Oracle VM te virtualiseren. Eerder werd betoogd dat virtualisatie niet altijd voor de hand ligt maar er zijn situaties waarbij bestaande beheerprocedures en/of rollenscheidingen het verdelen van databases over meerdere servers in de hand werkt. Ook komt het voor dat er een wens is om andere Oracle-omgevingen (zoals Weblogic servers) bij de databases te hosten. Áls er dus behoefte mocht zijn aan meerdere virtuele servers kan de ODA nog steeds van nut zijn als consolidatieplatform.

De hardware van de ODA is erop gericht om mede dankzij de geïntegreerde NVMe SSD’s, aangestuurd door Oracle’s ASM-software tot optimale database-prestaties te komen. Een zeer hoge I/O bandbreedte voor uw databases zonder dat uw SAN hier iets van merkt. Het feit dat de disks/SSD’s direct adresseerbaar zijn door het databasesysteem maakt het mogelijk om de RAID-set(s) specifiek af te stemmen en in de dagelijkse praktijk kan een DBA ook precies zien waar de I/O’s naartoe gaan zonder dat hier tijdrovende monitoring-trajecten op shared storage aan te pas komen.

Maar wat als u nog niet weet hoeveel capaciteitsbehoefte u op termijn heeft? Ook dit aspect is ondervangen. Door middel van Capacity-on-demand licensing kunt u ervoor kiezen om van de ODA slechts een klein deel (bijvoorbeeld slechts 2 CPU cores) te gebruiken en later zonodig meer CPU-cores en/of disks bij te schakelen. Dit is met een traditionele server-oplossing niet mogelijk.

Er zijn drie maten ODA’s. De modellen zijn:

De belangrijkste zaken op een rij:

• Geen SAN benodigd
• Licenties van 2 tot 72 CPU cores, u kunt variëren naar behoefte
• Standard of Enterprise Edition databases (op X6-2-HA alleen SE in een VM)
• Virtualisatie m.b.v. Oracle VM is mogelijk
• Zeer hoge prestaties in verhouding tot de te licentiëren capaciteit
• Geen losse patches of onderhoudscontracten nodig
• Één aanspreekpunt voor eventuele problemen
• Beheerbaar door een DBA, in hoge mate via slechts één tool (oakcli)
• Past in elk 19inch ServerRack
• Dankzij ILOM is de machine ook op afstand in- en uit te schakelen en te troubleshooten.
• Model X6-2HA kan worden voorzien van RAC t.b.v. hoge beschikbaarheid. DataGuard kan natuurlijk worden ingezet om een standby database bij te werken. Dit kan richting een andere ODA maar eventueel ook richting een andere server of VM.

De ODA in de praktijk

De implementatie van een ODA verloopt volgens een traject dat DBA.nl goed kent. Het begin hiervan is het vaststellen van de behoeften en het daarop afstemmen van de optimale systeemconfiguratie zoals aantal te activeren CPU-cores, disk-configuratie, netwerkverbindingen en het al dan niet virtualiseren van de ODA. Ook maken wij afspraken over het periodiek te verrichten onderhoud zoals controle op en toepassen van toekomstige ODA bundle-patches en het bijhouden van algehele gezondheidsindicatoren van de ODA en de daarop geïnstalleerde componenten, VM’s en databases. Het systeem wordt door ons ter plaatse aangesloten en geconfigureerd m.b.v. een checklist. Hierbij wordt zekergesteld dat de hardware goed functioneert, dat het systeem op afstand benaderbaar is en dat de automatische storingsmelding bij Oracle (ASR: Auto Service Request) werkt. Als alles in orde blijkt kan de configuratie van de Linux-nodes, netwerkadressen en opslag worden uitgevoerd en is het systeem klaar voor gebruik.

Voor reguliere activiteiten verloopt database-beheer op een ODA in de praktijk niet heel veel anders dan op andere systemen. Databases op een ODA zijn niet speciaal en kunnen dan ook worden gebruikt en onderhouden als elke andere Oracle-database. Het verschil wordt (voor een DBA) pas duidelijk bij het aanmaken , upgraden en of verwijderenvan een database. Deze activiteiten worden op een ODA namelijk uitgevoerd m.b.v. de “oakcli”-utility. Deze utility is het software-equivalent van een Zwitsers zakmes en wordt gebruikt voor bijna alle wijzigingen die kunnen worden uitgevoerd. Dit varieert van het configureren van beschikbare CPU’s en netwerk-adressen tot aan het aanmaken van nieuwe databases.

DBA.nl heeft inmiddels aardig wat ODA’s in beheer door heel Nederland en merkt dat bestaande klanten nadat de oude is afgeschreven wederom voor een nieuwe ODA kiezen. Wij hebben nog niet meegemaakt dat een ODA is vervangen door traditionele (virtuele) servers.

Mocht u geïnteresseerd zijn geraakt en graag meer willen weten neemt u dan gerust contact met ons op voor meer informatie of bijvoorbeeld een proof-of-concept. Wij helpen u graag verder.