Definizione:
WebLogic 12.2.1 ha introdotto il concetto di Multitenancy nelle
architetture Middleware basate su Application server.
La
multi-tenancy si riferisce ad un principio nell’architettura del software o
dell’hardware in cui una singola istanza del software viene eseguita su un
server, offrendo il proprio servizio a più client (i tenant). Il
concetto di multi-tenancy non deve essere confuso con quello di architettura
multi-istanza, in cui istanze software separate o sistemi hardware separati
sono resi disponibili a diverse organizzazioni. In un’architettura
multi-tenant un’applicazione software è progettata per partizionare
virtualmente i suoi dati e la sua configurazione, ed ogni tenant opera con una
di queste istanze applicative personalizzate.
La
multi-tenancy costituisce una conseguenza fondamentale della tecnologia di
virtualizzazione, grazie alla quale possiamo
concretizzare un approccio multi-tenant sulle risorse infrastrutturali, in
quanto si assiste alla creazione di ambienti virtuali logicamente separati sui
medesimi componenti fisici condivisi. L’aggettivo virtuale vuole evidenziare
come tale tecnologia consenta di costruire una separazione logica delle
risorse.
Nonostante
il concetto di multi-tenancy indichi che ci sono delle infrastrutture
condivise, ciò che fa la differenza è il livello nel quale le risorse
diventano multi-tenant, con una infrastruttura Oracle si è multi-tenant sia
a livello applicativo che a livello dei dati/DB e, con riferimento al cloud
anche a livello Hardware.
Componenti necessari per la Multitenancy
in Weblogic 12.2.1:
Per poter configurare
ed utilizzare la Multitenancy in Weblogic 12.2.1 è necessario avere solo un JDK
1.8 (consigliato dalla release/patch-set update 65 in su) con il garbage
collector G1 configurato.
WLS 12.2.1
sarà in tal modo in grado di rendere “multitenant” la JVM (partizionamento
della JVM) e su di essa baserà la sua multitenancy.
L’unione
di un tenant su WLS unito ad un tenant su JVM viene chimamato Domain Partition.
Partizionamento della JVM, le Domain
Partitions:
Una JVM
quando viene eseguita in una Macchina fisica, consumerà, in base al
carico, tutti i core (cpu) presenti su
quella macchina.
Per
evitare questo problema e con il nuovo HW multicore che si trova sul mercato,
solitamente vengono create immagini virtuali, ad ognuna di esse si assegnano
risorse HW quali Cpu e Memoria, vi si reinstalla parte del software e vi si
esegue almeno una JVM.
Oltre che
per suddividere meglio le risorse presenti su una macchina, tali opersazioni
risultano necessarie in alcuni contesti applicativi per separare e/o isolare
fisicamente e logicamente le applicazioni.
WLS 12.2.1
è in grado di suddividere una singola JVM in piu zone chiamate domain partitions.
Tramite la
Console di Amministrazione di WLS 12.2.1, si è in grado di assegnare la quantità di CPU, Memoria e file descrittori
consumabili da ogni Domain Partition.
Ogni
domain partition è fisicamente isolata da un’altra ed ha:
·
una o più applicazioni deployate
·
le sue regole di consumo cpu, memoria e
file descrittori
·
un suo proprio JNDI, non ci possono
essere quindi conflitti se si usano gli stessi nome logici in domain partition
differenti
·
il suo web context root
·
le sue librerie ed il suo classloader
·
le sue configurazioni di JMS, JDBC etc
·
il suo sistema di autenticazione
Ne
consegue che è possibile deployare una stessa applicazione piu volte su una
stessa jvm ma in domain partitions diverse.
Nel caso
ad esempio di architetture a microservizi, una stessa applicazione può essere
specializzata rideployandola in domain partitions diverse, assegnando ad ognuna
di esse un suo datasource ed un suo pluggable database (Oracle DB multitenancy)
ed assegnando ad ogni domain partition uno specifico Authentication Provider.
In tale modo ogni applicazione avrà un diverso bacino di utenza ed un diverso
sistema di persistenza.
Architettura e funzionalità di WLS
12.2.1 & Domain Partitions:
Nella
precedente immagine viene rappresentata una tipica architettura basata su
Weblogic 12.2.1 con Multitenancy.
Nela caso
della presenza di un cluster e di domain partitions configurate, ogni singola
jvm di ogni Managed Server del cluster verrà partizionata nella stessa maniera.
Le
applicazioni, quindi, saranno in cluster, dentro ogni singola domain partition.
Tramite la
console di amministrazione si potranno definire delle policy di resource
sharing e di resource consumption.
Ogni
regola applicata su una domain partition può attivare degli eventi quali:
· Notify :
l’applicazione di una domain partition sta consumando piu di un primo limite
fissato e ne viene data notifica
· Slow : l’applicazione
di una domain partition sta consumando piu di un secondo limite fissato e viene
rallentata dal sistema diminuendogli i thread di esecuzione.
· Shutdown :
l’applicazione di una domain partition sta consumando piu di un terzo limite
fissato e viene “spenta” dal sistema. E’ infatti possibile fare stop o start di
una domain partition senza che le altre ne siano coinvolte
E’
evidente quindi che con un semplice wizard sulla console di Amministrazione si
può decidere quante risorse assegnare ad una domain partition ed alla sua (o
sue) applicazioni deployate e quindi se una applicazione inizia a dare
problemi, può essere disattivata (automaticamente o manualmente) prima che
rechi problemi alle altre applicazioni deployate sulla stessa jvm. Inoltre
l’applicazione che viene “spenta”, verrà spenta solo su quella partizione dello
specifico Managed su cui creava problemi e continuerà a funzionare nel cluster
delle altre partizioni sugli altri Managed.
Nel caso
di presenza di cluster dinamico e di regole di scale-up (e/o scale-down), per
ogni nuovo managed aggiunto la sua jvm verrà automaticamente partizionata e
riconfigurata come le precedenti.
Il nuovo
bilanciatore software di Oracle denominato Oracle Traffic Director (OTD) viene
aggiornato in automatico nel caso di nuove domain partitions create in un
dominio.
Grazie a
questa funzionalità di autoaggiornamento dell’OTD si può avere la
live-migration delle Domain Partitions.
La
live-migration delle domain partitions, consente di spostare a caldo le domain
partitions configurate su delle jvm, su nuove JVM (sullo stesso o su nuovo HW).
Questo consente ad esempio di aggiornare l’HW (o in generale di eseguire
operazioni di manutenzione ordinaria e/o straordinaria) senza dare disservizi.
Le domain
partitions una volta che sono configurate possono essere esportate in un file
zip con un semplice click dalla console di Amministrazione.
In una
domain partition esportata è presente oltre che l’applicazione in essa
deployata anche tutte le sue configurazioni come ad esempio, JMS, JDBC,
Datasources ... etc.
E’
ovviamente anche possibile importare uno di questi file zip e replicare quindi
con un semplice click una complessa configurazione di una qualsiasi
applicazione configurata in precedenza.
L’export e
l’import delle domain partitions semplifica e rende immediato il passaggio di
applicazioni da on-premise sul cloud, oppure da ambienti di test ad ambienti di
produzione.
Vecchie
configurazioni di domini Weblogic, dalla versione 10.3.6 in poi, possono essere
trasformate in Domain Partitions ed essere importate su WebLogic 12.2.1,
tramite il tool D-PCT (Domain to Partition Conversion Tool) scaricabile da
Oracle Technology Network.
Benefici delle Architetture basate
sulle Domain Partitions:
Oltre a
tutti i benefici descritti in precedenza, una configurazione basata su Domain
Partitions rispetto ad una equivalente senza Domain Partitions, risulta
leggermente piu veloce ma con un lieve incremento di consumo di memoria.
Solitamente
si installa meno software ed in un mondo puramente Java si può evitare di
installare ambienti di virtualizzazione (risparmio licenze) e si riduce
drasticamente il numero di processi running di JVM, con conseguente minor
consumo di RAM e CPU.
Piu domini
possono essere consolidati in un unico dominio wls 12.2.1, semplificando nel
tempo le eventuali operazioni di patching e/o upgrade.
Nel caso di ambienti di sviluppo, ogni sviluppatore può fare i suoi test su una specifica Domain Partition, sapendo in tal modo di non arrecare problemi o conflitti con Domain Partition dedicate ad altri sviluppatori. Gli ambienti di sviluppo collassano quindi in una unica installazione di prodotto.
Nel caso di ambienti di sviluppo, ogni sviluppatore può fare i suoi test su una specifica Domain Partition, sapendo in tal modo di non arrecare problemi o conflitti con Domain Partition dedicate ad altri sviluppatori. Gli ambienti di sviluppo collassano quindi in una unica installazione di prodotto.
Nessun commento:
Posta un commento