WLS e domain partitions

Dal sito del Malefico Marini, ecco il suo ultimo post: WebLogic 12.2.1 & Multitenancy 

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:

Slide6

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.

Advertisements

Trunk vs. HEAD

Un repost dal blog di Gary Gregory, che contiene una spiegazione breve e chiara sui concetti di Trunk e HEAD (always ship Trunk!) in CVS e SVN:

This aim of this note is to provide the shortest and simplest explanation of the concepts of trunk and HEAD in a Version Control System like CVS and Subversion (SVN.) Like in botany, trunk is a tree’s central superstructure. All branches come out of the trunk: trunk-and-branches.jpg Main development is performed in the trunk. Releases are branched for bug fixes and maintenance releases. In the next diagram, the tip of the arrows for trunk and a branches are HEADs. Each branch and trunk have a HEAD. heads.png

Docker: docker-compose

Sperando – stavolta – di anticipare sul tempo un articolo del Malefico Marini sul suo blog, ecco alcune indicazioni per utilizzare un’istanza Oracle DB (XE) e un’istanza WebLogic attraverso docker-compose in pochi minuti. Io ho utilizzato una VM Ubuntu gestita da vagrant, ma l’operazione è estendibile a tutti gli ambienti che hanno Docker a bordo.

I passi da seguire:

  • Installare Docker (ovviamente tutti i DevOppers l’avranno già fatto, in caso contrario rivolgersi al Malefico Marini che sarà ben felice di rispondere a chiunque, in particolare a domande su Windows 🙂 ).
  • Assicurarsi di avere banda passante adeguata e gestire o spianare a fucilate i proxy che comunque troverete sulle vostre rotte.
  • Utilizzare un file docker-compose.yml siffatto (su hub.docker.com cercate la vostra immagine samplewls preferita e posizionatela opportunamente):
oracledb:
 image: wnameless/oracle-xe-11g
 ports:
 - "1521:1521"
 - "49160:22"
wlsadmin:
 image: tejten/samplewls
 links:
 - oracledb
 ports:
 - "8001:8001"
 command:
 - startWebLogic.sh
  • Utilizzare il comando docker-compose up 
  • Invocare Cthulhu o il Malefico Marini (entrambi sono entità non-euclidee)
  • Attendere il download degli artifact e l’avvio di WebLogic Server
  • Accedere alla console di WLS
  • Ringraziare Cthulhu (o il MM)
  • Profit!

 

Enjoy 😉

 

 

 

Application Builder Cloud Service

Application Builder Cloud Service è un servizio Cloud dedicato al design, alla costruzione ed al deployment di applicazioni web basate su JavaScript e HTML che non richiede particolari competenze tecniche, ed è utilizzabile da un business user.

L’ambiente, utilizzabile via browser, è semplice da utilizzare (nessuna installazione), lavora in modalità indipendente dai data sources (DB, file system, servizi REST), produce esperienze d’uso responsive e consente la creazione di mashups.

Ecco qualche interazione nel DevLet che trovate qui sotto:

 

Enjoy 😉

Oracle Cloud, Maven e il Malefico Marini

2Utilizzando Oracle Developer Cloud per testare un generatore di CV ;), ho avuto la necessità di inserire, all’interno di una webapp, le tre canoniche directory img, styles e fonts che contengono le direttive grafiche necessarie, in una JSP di risposta, per generare un modello di Curriculum Vitae degno di essere ospitato in un browser nel 2016.

Il pom.xml generato di default selezionando l’archetype webapp è sufficiente per testare il modello di CV  in un’istanza WebLogic locale pilotata da Eclipse, ma non su Oracle Cloud, dove si trasforma tragicamente in un CV (broken) del 1993… Dopo minuti di angoscia, dubbio e calo dell’autostima, si avvicina fischiettando il famigerato MM (Malefico Marini) che getta un’occhiata obliqua al pom.xml, va in modalità guru meditation per 41 secondi e ritorna al nostro mondo mortale con la seguente modifica da applicare all’interno della direttiva <build>:

    <resources>  

      <resource>  

        <directory>src/main/webapp</directory>  

        <targetPath>META-INF/resources</targetPath>  

      </resource>  

    </resources>

Mi guarda e si volta, dicendo “funzionerà… “. Mi chiedo se l’MM possa essere rinominato in MMM (il Malefico Marini di Maven).

E in effetti funziona… di seguito trovate le ormai classiche istruzioni in movimento.

Enjoy 😉