OVM (Oracle VM) e' l'ambiente di virtualizzazione
basato su Xen fornito dalla Oracle Corporation.
Oracle e' il DBMS relazionale commerciale piu' diffuso al mondo.
La gestione dell'asset delle licenze Oracle e' quindi un problema comune
a moltissimi clienti.
Oltre che da aspetti commerciali vi sono elementi tecnici
resi complicati dalle piu' recenti tecnologie di
consolidamento, di partizionamento e
di virtualizzazione dei sistemi.
In questa paginetta cerchiamo di descrivere
le modalita' di virtualizzazione
presenti sui principali ambienti operativi
distinguendo tra HARD e SOFT Partitioning
e valutandone l'impatto sul licensing dei prodotti Oracle.
Il documento contiene i dettagli tecnici per applicare
un Oracle-approved hard partitioning
sulle principali tecnologie quali:
Processor Pinning (OVM/Xen, OLVM/KVM),
Capacity on Demand (Exadata, ODA),
LDom (SPARC),
Zones (Solaris),
NPAR (HP),
LPAR (IBM),
...
Tutte le tecnologie indicate fondamentalmente impongono un limite massimo
al numero di core/processori di ogni partizione ed e' su tale limite che
si effettua il conteggio per calcolare il numero di licenze necessarie.
Questo e' un documento tecnico che richiede competenze specifiche sull'RDBMS Oracle.
Oracle e' l'RDBMS tecnologicamente piu' avanzato ed il costo e' corrispondente. Gli aspetti relativi al licensing di Oracle sono quindi molto importanti. E' importante utilizzare la licenza corretta per il proprio ambiente per disporre di tutte le funzionalita' necessarie e massimizzare i propri investimenti. L'RDBMS Oracle e' disponibile in diverse Edition con funzionalita' differenti:
Se si dispone di una licenza Oracle Enterprise Edition e' possibile utilizzare le Oracle Options. Le Options introducono ulteriori funzionalita' e sono a pagamento: vanno quindi attivate solo quando necessarie.
Il costo di una Option ed il relativo canone di supporto sono diffenti opzione per opzione e vanno verificate sul listino e/o con un referente commerciale Oracle. Semplificando molto vi sono alcune Option piu' care che hanno un costo pari a circa il 50% della licenza Enterprise (eg. RAC, In-Memory, Advanced Analytics, ...) ed altre con un costo vicino al 25% (eg. Active Data Guard, Partitioning, Real Application Testing, Advanced Compression, Diagnostics Pack+Tuning Pack, ...). Maggiori dettagli sulle Oracle Option sono riportati il Le mille ed una... Option.
Nel calcolo del costo della licenza si adottano due metriche: a processore oppure ad utente nominale. Quella comunemente piu' utilizzata e' quella a processore, anche perche' anche il calcolo per utente nominale ha comunque un limite minimo basato sul numero di processori. La base di calcolo e' il numero di core fisicamente presenti moltiplicata da un eventuale core factor come specificato dalla Oracle Processor Core Factor Table. I core factor vanno da 0.25 ad 1.0; ad esempio i diffusi processori Intel Xeon hanno un core factor 0.5, quindi contano la meta'.
Il riferimento completo si trova sul listino prezzi e sulla documentazione ufficiale. Il contratto tra Oracle ed il cliente finale e' riassunto nell' OLSA (Oracle License and Service Agreements). L'argomento e' complesso ed articolato (NP/OCPU, ten day rule, two day rule, ...) per tale ragione la Oracle Corp. ha emesso una utile Software Investment Guide di facile lettura ed interpretazione.
In un ambiente Enterprise sono tipicamente presenti molteplici database Oracle in Enterprise Edition, spesso su piattaforme diverse, e con un insieme variabile di opzioni che dipendono dalle ulteriori funzionalita' necessarie: per un DWH il Partitioning, per l'HA il RAC, per il DR l'Active Data Guard, ...
Oracle supporta un numero molto elevato di tecnologie di virtualizzazione per i sistemi che ospitano una base dati Oracle. La pagina ufficiale riporta in modo dettagliato l'elenco aggiornato delle tecnologie supportate; nell'elenco sono presenti anche le piu' recenti tecnologie quali i Container LXC e Docker. Ma una cosa e' il supporto di una tecnologia di virtualizzazione/partizionamento ed un altra e' il licensing!
Una concetto molto importante per il licensing di Oracle
su sistemi Enterprise e' la distinzione tra Hard e Soft Partitioning.
La documentazione ufficiale
riporta in modo dettagliato la definizione.
Il documento e' stato aggiornato di recente [NdA 2019-10-07]
[NdE aggiornato il 2022-06]
e prevede l'Hard Partitioning con Oracle Linux KVM.
Volendo riassumere molto quando si riesce ad associare un processore fisico ad un ambiente
in modo fisso e documentabile il sistema utilizza una Hard Partition (partizione fisica) ed i calcoli
del licensing possono essere basati sui soli processori assegnati.
Se invece l'assegnazione e' solo virtuale, il numero di processori e' variabile in modo dinamico,
i server ospite possono variare, ...
allora il sistema utilizza una Soft Partition (partizione logica) ed i calcoli
del licensing vanno basati sul numero totale di processori fisici presenti.
Per ottenere il massimo delle prestazioni con il costo minore per le licenze
vanno utilizzati i sistemi alla massima densita'.
Questo per sfruttare al massimo i core disponibili fornendo un adeguato livello di servizio.
Da questo punto il partizionamento offre notevoli vantaggi nella flessibilita'
della configurazione.
Quanto riportato sopra e' una notevole semplificazione... nei prossimi capitoli vedremo gli esempi piu' significativi di applicazione del Partitioning.
OVM (Oracle VM) e' l'ambiente di virtualizzazione
basato su Xen fornito dalla Oracle Corporation.
L'architettura di OVM e' basata su Xen a cui sono stati aggiunti strumenti di amministrazione. La configurazione di OVM e' costituita un Oracle VM Manager e diversi Oracle VM Server:
Gli OVM Server sono organizzati in Server Pool e fanno uso di risorse comuni come lo storage repository ed il networking configurati graficamente dalla console. Sempre da console vengono definite e gestite le VM (Virtual Machine). Le risorse, i servizi e le VM possono essere scambiati solo tra server appartenenti allo stesso pool.
Alle VM vengono assegnate le risorse come le CPU e la memoria in modo dinamico:
in una normale configurazione OVM utilizza il Logical Partitioning e se vengono
ospitate istanze dell'RDBMS Oracle vanno acquisite licenze corrispondenti a tutti
i processori fisici degli OVM Servers.
Con OVM e' tuttavia possibile definire il processor pinning: ovvero assegnare
alcuni processori ad una specifica VM.
Per effettuare il pinning delle CPU si utilizza il comando ovm_vmcontrol
(contenuto nelle Oracle VM Utilities opzionali):
./ovm_vmcontrol -u $OVMU_USER -p $OVMU_PASS -h $OVMU_HOST -v OVMname -c setvcpu -s 0,7
La verifica dell'assegnazione delle CPU fisiche alle VCPU assegnate alla VM (affinity) si effettua con i comandi:
xm info
xenpm get-cpu-topology
xm vcpu-list
xm vcpu-list VMname
Vi sono alcuni importanti dettagli tecnici per attivare correttamente il processor pinning.
Il parametro setvcpu fa riferimento all'elenco delle CPU come viste dal sistema
ovvero considera sia il numero di core che l'eventuale hypertrading.
E' importante assegnare tutte le CPU dei processori che si vogliono
assegnare alla VM.
Il file di configurazione della VM (vm.cfg) al termine dell'assegnazione
dovra' avere il parametro cpus impostato.
La funzionalita' di live migration non e' consentita e non vanno abilitate le funzionalita' di
DRS (Distributed Resource Scheduler) e DPM (Distributed Power Management).
Per ottenere l'HA delle istanze Oracle vanno utilizzate due VM su OVM Server distinti e la configurazione in RAC.
Con OVM il processor pinning o affinity, impostato come descritto,
e' considerata da Oracle un'assegnazione fisica dei processori
e quindi corrisponde ad un Hard Partitioning, con tutti i relativi vantaggi nel calcolo del licensing.
Il documento ufficiale e' Hard Partitioning with Oracle VM Server for x86.
KVM e' un ambiente di virtualizzazione nativo sul kernel Linux.
OLVM (Oracle Linux VM), fornito dalla Oracle Corporation
consente la gestione di Virtual Machine KVM ospitate su nodi Oracle Linux.
L'architettura di OLVM e' basata su oVirt, in realta' con pochissime differenze.
L'oVirt Engine e' il motore scritto in Java che gestisce i nodi.
Gli oVirt node sono server Linux con KVM su cui gira il demone VDSM (python)
che, con interfaccia libvirt, gestiscono le varie VM.
L'implementazione Oracle fornisce alcune utility aggiuntive installabili con:
yum install olvm-vmcontrol
olvm-vmcontrol consente di definire l'affinita' ai processori con una modalita' che viene riconosciuta come Hard Partitioning dalla Oracle Corp.
Per impostare il pinning delle CPU il comando sull'Engine e':
E' possibile indicare con -s una singola CPU (eg. 0), una lista (eg. 1,2) o un range (eg. 0-3).
L'impostazione puo' essere eseguita anche con la VM attiva tuttavia sara' effettiva solo quando
la VM verra' riattivata dal portale.
Utilizzando l'opzione di olvm-vmcontrol getvcpu -e si ottiene lo stato del pinning.
Il controllo del pininng puo' anche essere eseguito sul nodo ospite con il comando:
virsh --readonly vcpuinfo ora19 --pretty
Altri comandi utili sui node KVM sono lscpu per elencare le CPU presenti e virsh --readonly list per elencare le VM attive.
Con la macchina virtuale impostata in questo modo il numero di core conteggiate
per il licensing Oracle
e' quello assegnato e non il totale dei core presenti sul sistema ospite.
La live migration delle virtual machines con CPU pinned non e' permessa nei termini dell'hard partitioning
con l'eccezione delle
Trusted Partitions che sono limitate agli approved Oracle Engineered Systems (eg. Exadata).
Il documento ufficiale e' Hard Partitioning with Oracle Linux KVM, e' molto recente [NdA 2019-10-11] ed e' importante poiche' tutti i piu' recenti ambienti Oracle sono virtualizzati con KVM ed OLVM.
L'ODA (Oracle Database Appliance) e' un sistema ingegnerizzato dalla Oracle,
e' costituito da due server x86 e da uno storage integrato che occupano
nel complesso 4 o 6 rack unit. Sono possibili due modalita' di configurazione:
Sia con la configurazione Bare Metal che con la configurazione Virtualized e' possibile attivare
solo alcuni dei core fisicamente presenti.
L'ODA permette di licenziare i soli
processori necessari al business:
da un minimo di due fino al totale HW disponibile
(che naturalmente dipende dal modello, ad esempio sono 72 con il modello X5-2).
Nel caso in cui fossero necessari piu' processori e' sempre possibile abilitarli
in tempi brevi richiedendo al supporto una chiave di attivazione e lanciando il comando:
/opt/oracle/oak/bin/oakcli apply core_configuration_key /home/newkey.txt
Dal punto di vista del licensing per l'abilitazione dei processori su ODA si applica la tabella dei core factor (fattore 0.5).
L'attivazione on demand dei processori e' disponibile anche sulla maggioranza
dei sistemi Oracle engineered
come l'Exadata.
Il discorso tuttavia e' poco piu' complesso perche' il numero
minimo di processori attivabili dipende dal modello
(cfr. Capacity on Demand).
Si tratta di sistemi di grandi dimensioni, altamente configurabili
ed adatti a soli clienti Enterprise.
Ovviamente la possibilita' di utilizzare i processori al meglio e la scalabilita' per supportare la crescita delle esigenze di business sono importanti vantaggi stategici.
I sistemi SUN (ora Oracle) hanno una grande tradizione sulla linea Enterprise
ed i modelli di fascia piu' alta supportano da tempo il partizionamento
fisico.
Ad esempio i domini di un Sun Fire E25K (fino a 18) sono elettricamente separati tra loro
e l'architettura e' chiaramente un esempio di Hard Partitioning.
Successivamente sono state introdotte nel
sistema operativo ulteriori possibilita' di partizionamento logico
con i Logical Domains (LDOM) e con le Zone (Solaris Containers).
In questo paragrafo analizzeremo l'Hard Partitioning con
i logical domains e nel prossimo con le Solaris Zones...
I Logical Domains (LDoms or LDOM) e' una tecnica di virtualizzazione disponibile sui
processori SPARC.
Con l'acquisto di Sun da parte di Oracle e' stata commercializzata con il nome di
Oracle VM Server for SPARC, quindi i due termini sono ora equivalenti.
Ad ogni dominio vengono assegnate una serie di risorse HW.
I domini sono molto flessibili perche' supportano
l'aggiunta di CPU, di RAM e di device di I/O senza reboot
e possono eseguire una live migration senza interruzione di servizio.
Per effettuare una configurazione che venga considerata Hard Partitioning
dal punto di vista del licensing Oracle e' necessario assegnare in modo
specifico i core ad un dominio e definere un cap constraint
[NdA per default la configurazione di un dominio associa threads e non un intero core].
Inoltre per l'Hard Partitioning non e' consentita la live migration dei domini,
naturalmente questo limite e' presente per i soli domini che ospitano istanze/prodotti Oracle.
Ecco i comandi corretti:
ldm create oradom01ldm set-core 2 oradom01ldm set-domain max-cores=2 oradom01ldm bind oradom01 ldm start oradom01
Per verificare la configurazione del sistema i comandi sono:
psrinfo -pv
ldm list oradom01
ldm list -o resmgmt oradom01
ldm list -o core oradom01
Il riferimento tecnico ufficiale e' Hard Partitioning with Oracle VM Server for SPARC.
Dalla versione 10 di Solaris sono supportate le Solaris Zones,
commercialmente chiamate per un certo periodo anche Solaris Containers.
Ogni installazione di Solaris 10+ utilizza sempre
almeno una zona: la global zone (GZ).
E' inoltre possibile creare zone agguntive che vengono definite non-global zones (NGZ).
Le zone NGZ sono particolarmente efficienti poiche' condividono il SO e le risorse con la GZ.
Le zone consentono di separare le applicazioni in modo efficace
e possono fingere di avere
versioni di sistema operativo diverso dalla GZ con il branding
(eg. una GZ con Solaris 10 ed una NGZ con Solaris 8) [NdE con Solaris 11 e' possibile creare
NGZ con Solaris 11 e Solaris 10, mentre con Solaris 10 e' possibile creare NGZ Solaris 10, 9 ed 8].
In una configurazione tipica una zona NGZ puo' utilizzare tutte le CPU
disponibili in HW e sono anche consentite configurazioni in overbooking...
Per rispettare i vincoli stringenti dell'Hard Partitioning con le Solaris Zones sono disponibili tre differenti metodi:
root:~# zonecfg -z ora01-zonezonecfg:ora01-zone> add dedicated-cpuzonecfg:ora01-zone:dedicated-cpu> set ncpus=4zonecfg:ora01-zone:dedicated-cpu> endzonecfg:ora01-zone> verifyzonecfg:ora01-zone> commitzonecfg:ora01-zone> exit
root:~# zonecfg -z ora02-zonezonecfg:ora02-zone> add capped-cpuzonecfg:ora02-zone:capped-cpu> set ncpus=12zonecfg:ora02-zone:capped-cpu> endzonecfg:ora02-zone> verifyzonecfg:ora02-zone> commitzonecfg:ora02-zone> exit
root:~# pooladm –eroot:~# poolcfg -dc 'create pset orapset'root:~# poolcfg -dc 'modify pset orapset (uint pset.max=16)'root:~# poolcfg -dc 'modify pset orapset (uint pset.min=16)'root:~# poolcfg -dc 'create pool orapool'root:~# poolcfg -dc 'associate pool orapool (pset orapset)'root:~# pooladm -sroot:~# zonecfg -z ora03-zone set pool=orapoolroot:~# zonecfg -z ora04-zone set pool=orapool
I tre metodi possono essere utilizzati anche contemporaneamente, nel calcolo per il licensing semplicemente vengono sommati i valori massimi di ogni assegnazione.
Per verificare la configurazione del sistema i comandi sono:
psrinfo -pv
zoneadm list
zonecfg -z NomeZona info dedicated-cpu
zonecfg -z NomeZona info capped-cpu
zonecfg -z NomeZona info pool
poolcfg -c 'info pool NomePool'
Poiche' le zone sono ospitate sul sistema operativo dalla zona global sono visibili tutti i processi delle zone attive (con il comando ps -efaZ viene evidenziata anche la zona dei processi). Mentre collegandosi sulla zona specifica si possono vedere solo i processi locali.
Facile vero?
In realta' l'HW e' costituito da processori fisici diversi,
ciascuno composto da piu' core che ospitano piu' thread.
Il sistema operativo Solaris, sia con processori SPARC che i processori x86-64,
vede i singoli thread.
Di converso il licensing e' basato sul numero di processori calcolati
con il core factor e basati sul numero di core effettivamente abilitati
[NdE in alcuni casi e' necessario identificare il numero di socket e non di core].
E' quindi molto importante
eseguire correttamente le associazioni per non superare il licensing
ovvero per non disporre del numero thread previsti.
Il calcolo e' comunque semplice: sommare tutti i thread assegnati, dividere per il
numero di thread/core ed applicare il core factor.
Il riferimento tecnico ufficiale e' Hard Partitioning With Oracle Solaris Zones.
HP ha una lunga tradizione sui sistemi Enterprise. Sui modelli di fascia piu' alta (eg. Superdome) e' disponibile sia il partizionamento fisico (NPAR) che logico (VPAR). E' quindi possibile suddividere l'HW fisico del sistema in piu' partizioni e su ciascuna di queste installare un sistema operativo o un hypervisor.
I modelli di fascia piu' alta sono i Superdome che forniscono un'elevatissima affidabilita'
grazie ai componenti ridondati ed un'elevatissima scalabilita' (fino a 16 celle).
I Superdome piu' recenti sono
HP Superdome 2, con processori Itanium e sistema operativo HP-UX,
e HPE Integrity Superdome X, con processori Intel Xeon e
supporto di SLES, RHEL, Microsoft Windows Server, Hyper-V, VMware vSphere e KVM/RHEV.
La configurazione di un Superdome richiede competenze specifiche ma e'
ora notevolmente semplificata dall'utilizzo dei wizard dell'Onboard Administrator.
A seconda del modello i server HP sono costituiti da una o piu' celle che possono essere utilizzate come un unico server di grandi capacita' elaborative o raggruppate in NPAR. Ciascuna NPAR e' costituita da una o piu' celle ed I/O Chassis ed e' elettricamente separata dalle altre.
Il partizionamento con NPAR e' riconosciuto da Oracle come Hard Partitioning ed e' quindi utilizzabile per configurare server che ospitino istanze Oracle con un calcolo vantaggioso del licensing.
Il comando per verificare la configurazione delle NPAR e' parstatus:
# parstatus
[Complex]
Complex Name : SuperDomeComplex
Complex Capacity
Compute Cabinet (8 cell capable) : 1
Active MP Location : cabinet 0
Model : 9000/800/SD32000
Original Serial Number : USR6969XYZ
Current Product Order Number : 6969AB
Original Manufacturer : HP
Complex Profile Revision : 1.0
The total number of partitions present : 3
[Cabinet]
Cabinet I/O Bulk Power Backplane
Blowers Fans Supplies Power Boards
OK/ OK/ OK/ OK/
Cab Failed/ Failed/ Failed/ Failed/
Num Cabinet Type N Status N Status N Status N Status MP
=== ============ ========= ========= ========== ============ ======
0 8 cell slot 4/0/N+ 5/0/NA 5/0/N+ 3/0/N+ Active
[Cell]
CPU Memory Use
OK/ (GB) Core On
Hardware Actual Deconf/ OK/ Cell Next Par
Location Usage Max Deconf Connected To Capable Boot Num
========== ============ ======= ======== =================== ======= ==== ===
cab0,cell0 Active Core 4/0/4 8/0 cab0,bay0,chassis1 yes yes 0
cab0,cell1 Active Base 2/0/4 4/0 - no yes 2
cab0,cell2 Inactive 4/0/4 4/0 cab0,bay1,chassis3 yes yes 1
cab0,cell3 Inactive 2/0/4 4/0 - no - -
cab0,cell4 Active Core 2/0/4 4/0 cab0,bay0,chassis3 yes yes 2
cab0,cell5 Powered off 0/0/4 ? ? ? no 0
cab0,cell6 Active Core 2/0/4 4/0 cab0,bay1,chassis1 yes yes 1
cab0,cell7 Powering on 0/0/4 ? ? ? - -
...
[Partition]
Par # of # of I/O
Num Status Cells Chassis Core cell Partition Name (first 30 chars)
=== ============ ===== ======== ========== ===============================
0 Active 2 1 cab0,cell0 dbserv01
1 Active 3 2 cab0,cell6 appserv01
2 Active 2 1 cab0,cell4 appserv02
In questo caso si tratta di un Superdome costituito da un cabinet con celle
che sono state associate a tre differenti partizioni.
Se le istanze Oracle vengono ospitate sulla sola partizione 0 (dbserv01),
sara' solo questa da utilizzare per il conteggio dei processori da licenziare
(tenendo naturalmente conto del core factor).
Analoghe considerazioni valgono per tutti i sistemi HP partizionabili in NPAR. Il partizionamento con VPAR non offre invece vantaggi nel calcolo del licensing dell'RDBMS Oracle [NdE in realta' vi sarebbe un'ulteriore possibilita' con le capped VPAR].
Ultimi, ma solo in questo elenco, sono i sistemi IBM:
i primi sistemi partizionati sono stati proprio i Mainframe IBM.
La gamma attuale dei modelli e' molto ampia. I sistemi entreprise di maggiori dimensioni sono
i Power System che ospitano i recenti processori POWER8 [NdA 2021-09 Power10].
I sistemi IBM con sistema operativo AIX hanno un elevato grado di configurabilita'
e possibilita' di virtualizzazione: LPAR, DLAPR, Micro-Partitioning, ...
Le LPAR sono approvate come Hard Partitioning per Oracle e sono particolarmente efficienti.
Alcuni sistemi vengono gestiti con un l'HMC (Hardware Management Console),
un'appliance dedicato, ma e' anche possibile utilizzare comandi in linea
per creare una LPAR:
mksyscfg -r lpar -m MACHINE -i name=LPARNAME, profile_name=normal, lpar_env=aixlinux, shared_proc_pool_util_auth=1, \ min_mem=512, desired_mem=2048, max_mem=4096, proc_mode=shared, min_proc_units=0.2, desired_proc_units=0.5, \ max_proc_units=2.0, min_procs=1, desired_procs=2, max_procs=2, sharing_mode=uncap, uncap_weight=128, \ boot_mode=norm, conn_monitoring=1, shared_proc_pool_util_auth=1
Per verificare la configurazione sono utilizzabili i comandi:
lparstat
lparstat -i
I comandi forniscono tutti i dettagli sulla configurazione della LPAR,
da cui ricavare il numero di core assegnati
[NdE il core factor per i processori POWER e' tipicamente 1.0].
E' importante sottolineare che per l'Hard Partitiong
non e' possibile utilizzare l'LPM (Live Partition Mobility) delle LPAR.
L'LPM e' una funzionalita' che si imposta a livello di frame.
E' una situazione limite... ma anche con l'LPM attivo a livello di Frame
e' possibile impostare il parametro Disable Migration per le LPAR che ospitano
istanze oracle (cfr. documentazione IBM)
oppure con:
chsyscfg -r lpar -m MANAGEDSYS -p LPARNAME -i "migration_disabled=0"
Eventuali variazioni della configurazione sono monitorati come eventi e possono essere riportati
con il comando:
lssvcevents -t console | grep vclient
E' opportuno tuttavia analizzare caso per caso perche' anche piccole differenze, tecniche o contrattuali, possono diventare determinanti.
La documentazione ufficiale Oracle riporta in modo esplicito che VMware utilizza solo il Soft Partitioning e quindi vanno sempre licenziati tutti i processori fisici presenti nel cluster vSphere. L'impostazione delle vcpu alle VM che ospitano istanze Oracle non ha alcun effetto per il calcolo del licensing.
Il punto di vista sostenuto da VMware e' diverso ed e' riassunto in questo documento. Tuttavia la mia opinione e' che, trattandosi di licensing dell'RDBMS Oracle, i riferimenti definitivi possano essere solo i contratti e la documentazione ufficiale Oracle.
Quanto segue e' OOT...
Un failover cluster fornisce funzioni di HA e di bilanciamento del carico. I servizi possono migrare, in caso di fault o per decisione del sistemista, sui diversi nodi presenti.
Sono disponibili molteplici prodotti di failover cluster con caratteristiche e funzionalita' differenti: Veritas ClusterServer, HP ServiceGuard, IBM PowerHA, Red Hat Cluster Suite Red Hat, Pacemaker/Corosync, e... Oracle Clusterware.
Con un cluster vanno licenziati tutti i processori di tutti i nodi presenti.
Quello che generalmente avviene e' che si dedica l'intero failover cluster ai DB Oracle,
in questo si possono utilizzare meno processori ed in totale il costo per le licenze risulta
inferiore.
La configurazione Active-Active non e' possibile per le normali istanze Oracle ma e' richiesta la configurazione in RAC.
Nel caso in cui venga utilizzato un solo nodo di un failover cluster installato su un unico datacenter, che lo storage sia fisicamente lo stesso e che l'eventuale utilizzo sia inferiore a 10 giorni (conteggiati come 24 ore) non e' necessario acquistare licenze ulteriori.
Coming soon!
Per il momento potete leggere: Oracle Cloud e Oracle Database Cloud Service.
Questo documento e' stato scritto con attenzione ma e' necessario fare riferimento alla documentazione ufficiale per verificare ogni dettaglio ed eventuali variazioni che possono occorrere nel tempo.
Sulle Opzion disponibili in Oracle puo' essere utile leggere Le mille ed una Option.
Sul partizionamento dei sistemi unix puo' essere utile il documento DIVIDE ET IMPERA!
Titolo: Hard or Soft?
Livello: Avanzato
Data: 1 Aprile 2017
Versione: 1.0.2 - 31 Ottobre 2022 🎃 Halloween
Autore:
mail [AT] meo.bogliolo.name