WebLogic 12.2.1 & Multitenancy - (Document in Italian Language)

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.