Sistemi Informativi Architetture. BPM Monitoring. Architettura di progetto 27 febbraio 2012 filippo magnani

Transcript

1 Sistemi Informativi Architetture BPM Monitoring Architettura di progetto 27 febbraio 2012 filippo magnani

2 Versione documento Versione Data Sommario modifiche /02/2012 Stesura Documento Accettazione ultima versione Funzione Data Firma CDC Sistemi CDQ Sicurezza Pagina 2 di 18

3 Indice 1.Informazioni funzionali e raccolta requisiti...4 Elenco requisiti... 4 Livello di servizio... 4 Note riferite al contesto funzionale della richiesta Analisi architetturale Architettura della soluzione...8 Schema architetturale del prodotto web methods...8 Architettura fisica Uso del BPM per monitor processi...12 Valutazione impatti della sorgente dati...13 Architettura della soluzione Principi di implementazione del BPM per il monitoraggio...17 Impatti su applicazioni nuove che dovranno essere monitorate...18 Criticità residue Pagina 3 di 18

4 1. Informazioni funzionali e raccolta requisiti L iniziativa ha lo scopo di fornire una soluzione di architettura generale di monitoraggio dei flussi applicativi utilizzando un business process management (BPM). L uso del BPM è esclusivamente di monitoring. Elenco requisiti Di seguito si riportano i requisiti funzionali rilevanti ai fini della costruzione dell architettura. Eseguire monitoring processo tramite BPM. Livello di servizio Al momento della stesura del documento non si sono definiti livelli di servizio. Si è comunque stabilito una review del livello di servizio in fase di rodaggio dle progetto. Una possibile data di review è settembre Note riferite al contesto funzionale della richiesta Non vi sono specifiche in merito. Pagina 4 di 18

5 2. Analisi architetturale L analisi della problematica prevede i seguenti considerazioni: La scelta del prodotto è ricaduta sul sofware di softwareag. I moduli compresi nella licenza e descritti successivamente nel capitolo 3 sono : o Business Process Management (BPM) o Broker (JMS Messaging) o Business Applicatrion Monitoring (BAM) o My Webmethods Server o Mash zone o Complex Event Processing (CEP) o Adapter JDBC o Adapter OFTP L architettura viene divisa su tre macchine virtuali sia per esigenze di prodotto sia per la separazione logica del lavoro. Per i runtime di adapter, flow service e BPM che risiedono nello stesso container chiamato integration server è predisposta una macchina. Per il controllo delle applicazioni deployate e per la gestione delle stesse è predisposta un altro server; il controllo e gestione possono essere accorpate sia dal punto di vista di mansione che dal punto di vista di installazione del prodotto e della dimensione del carico. Il terzo server è stato pianificato per motivi di carico in quanto il complex event processing sarà per il momento usato marginalmente. Avendo individuato le competenze di ciascun modulo e carico la soluzione scelta risulta scalabile in quanto: o Il broker residente sulla macchina degli integration manager può essere staccato e installato su una macchina a parte senza richiedere ulteriori licenze. o la macchina interessata a carichi applicativi è isolata con la possibilità di aggiungere nuove risorse fisiche in totale trasparenza all architettura messa in opera, dunque un carico futuro può essere facilmente dimensionato ed inserito nell architettura esistente. Si è verificato la compatibilità dei moduli di software AG con la virtualizzazione delle risorse. L alta affidabilità (HA) per il progetto di monitoring non avendo i requisiti di SLA, RPO (Recovery Point Objective) e RTO (Recovery time objective) non viene per ora predisposta. Successivamente avendo indicazioni in merito al livello del servizio verrà considerata una soluzione in alta affidalità. Pagina 5 di 18

6 Coerentemente con quanto deciso per HP Openview, non essendo una applicazione di business, il SO scelto è Linux RedHat I flussi BPM e i vari componenti (Adapter e rules) hanno gli engines gestiti in un macromodulo chiamato Integration Server. Al suo interno risiederanno gli engine dei pacchetti sviluppati (sia i flussi BPM che Flow Service). Per tali motivi si è scelto di dimensionare una macchina virtuale con capacità di memoria di 32Gbytes. Inoltre, su questa macchina, sarà anche installato il broker di messaging, dunque si è scelto di dimensionare più memoria alla macchina virtuale. Per i moduli di BAM, MashZone e lo strumento di amministrazione chiamato MyWebMethodsServer non si prevede un grosso carico di calcolo e dimensione di memoria in quanto l uso del BAM e Mashzone sono relegati ad attività di monitoraggio del softwareag. La console di amministrazione è l interfaccia grafica (GUI) dove si accede per le operazioni di deploy e verifica dei processi. Si è prevista una macchina virtuale dimensionata con 16GBytes di memoria. Per la parte del solo Complex Event Processing è stata previsto l uso di una macchina virtuale con 6Gbytes di memoria ed un solo core. Sia per limitato uso dell applicazione è stata dimensionata con minore risorse rispetto alle altre applicazioni. Per gli ambienti di test e preproduzione sono predisposte tutte macchine virtuali dimensionate in base al bisogno di risorse dei relativi moduli SoftwareAG. La tecnologia VM può rivelarsi una valida soluzione negli ambienti di test, preproduzione e gestione temporanea del software. Consente infatti di eseguire procedure dettagliate di debug e monitoraggio delle prestazioni di singoli carichi di lavoro e può essere utilizzata anche per creare scenari di testing per garantire l'esecuzione delle operazioni appropriate in specifici scenari e configurazioni hardware. Può essere inoltre impiegata per simulare il funzionamento di un carico di lavoro in esecuzione in una rete costituita da più server, in un unico sistema hardware fisico. Per l ambiente di test il dimensionamento di memoria è di 4Gbytes rispetto a quello di pre-produzione che è di 20Gbytes in quanto per lo sviluppo si ha un esigenza di verifica delle correttezza dei flussi rilasciati, di integration test e si ha solo una parte dei flussi sviluppati attivi in memoria senza avere la necessità di tutto il software rilasciato attivo. Al contrario per l ambiente di preproduzione si è dovuto dimensionare 20GBytes di memoria in quanto saranno eseguiti test completi delle applicazioni rilasciate. Le dimensioni degli spazi per dimensionare gli storage vengono calcolati in base ad un uso futuro che l applicazione farà per l installazione, file di log delle Pagina 6 di 18

7 applicazioni che verranno sviluppate e utilizzo generale quali directory di scambio file in input e output. La dimensione stimata è di 10Gbytes. Gli storage saranno di tipo interno non dovendo condividere con altre entità esterne nessun tipo di dato. In caso di HA sarà necessario rivedere la condivisione interna e lo spazio messo a disposizione. L integration Server, che è il contenitore delle applicazioni BPM, Adapter e Flow Manager sviluppate, in memoria è sostanzialmente una Java Virtual Machine. Questa JVM può essere può essere ulteriormente dimensioniata con parametri di limite minimo e massimo di memoria. La memoria totale delle tre macchine virtuali sarà dimensionata in base al numero di applicativi che saranno sviluppati. La macchina virtuale più impattata è senza dubbio quella su cui risiederanno i vari Integration Server. Il dimensionamento è stato pensato per circa 25 applicazioni da un 1Gb ciascuno. Pagina 7 di 18

8 3. Architettura della soluzione Schema architetturale del prodotto web methods Viene inserito per completezza uno schema logico architetturale del software Webmethods di software AG con una breve descrizione dei componenti. Pagina 8 di 18

9 Vengono ora elencati i componenti della Suite e la loro funzione all interno del disegno architetturale. INTEGRATION MANAGER E la suite che contiene i componenti che servono per gestire le più comuni esigenze di integrazione la suite ESB è dunque responsabile dell esecuzione dei processi,della trasformazione dei dati e del loro monitoraggio. Nell elenco vengono descritti brevemente tali componenti. 1. ADAPTER In generale un adapter è un componente in grado di interfacciarsi al sistema finale sia esso AS/400,un database,o un sistema Tuxedo. Più adapter software AG fornisce tramite la suite ESB più sistemi finali si possono integrare. Più specificatamente per il sistema AS400 l adapter preposto fornisce una comunicazione real time con il server stesso. L adapter consente di eseguire comandi, programmi RPG scrivere e leggere dati dai data queues dell AS BPM Il business process management gestisce i processi di business che sono una serie di attività svolte in un specifico ordine in accordo con le regole di business. Inoltre un processo di business è definito come un job long running, cioè un processo la cui esecuzione può durare giorni e che può prevedere interazioni con attività umane. L engine del bpm, dunque controlla e orchestra l esecuzione di tali processi. 3. RULES RUNTIME Le regole possono essere espresse come una decision tables o come event rules. Esse possono invocare servizi e operare su processi; ad esempio possono fermare o fare partire processi. Le regole viste come decision tables sono formate da righe,dove ogni riga è una regola e le colonne sono le condizioni. Le regole del tipo event rules sono formate da un evento di una determinata condizione. STRUMENTI DI MONITORING 2. BAM (Business Applicatin Monitoring) Le risorse di sistema e i processi di business possono essere monitorati e ottimizzate tramite questo applicativo integrato nella suite. I dati vengono quantificati tramite indicatori KPI (Key Performance Indicator). I KPI vengono definiti dall amministratore. 3. MASH ZONE E un applicazione browser-based che analizza e visualizza i dati dai vari data source integrati. Puo costruire interfacce complesse come dashboards,leggere dati derivanti da diversi formati tipo xml, excel e creare query complesse per ottenere precisamente i dati che dobbiamo visionare. Pagina 9 di 18

10 WEB METHODS BROKER E un message router che funge principalmente da bus-messaging basato su standard Java Message Service.WebMethods Broker fa da intermediario da l applicazione publisher e l applicazione subscriber. Lo scambio di messaggi può essere sia in modalità queues o in modalità topic. Le modalità si differenziano in quanto la prima viene usata principalmente come point-topoint application mentre la seconda una applicazione pubblica e più client leggono il messaggio pubblicato. MY WEB METHODS SERVER Il server MWS è una console di interfaccia di amministrazione per avere con un'unica applicazione sia il monitoraggio dei prodotti Sofwtare AG con la possibilità di sviluppare anche piccole applicazioni WEB e/o portlets che possono essere eseguite sul framework stesso. Da MWS possiamo dunque collegarci al monitoring BAM,ai processi,ai servizi di integrazione e alle regole di gestione di questi ultimi. COMPLEX EVENT PROCESSING L applicazione chiamata Business Event segue l architettura Event-Driven-Architecture (EDA). webmethods BE intercetta degli eventi di particolare interesse per il business per monitorare in tempo reale il numero di processi in un determinato stato di business. La sequenza di stati di interesse può essere tramite un flusso BE in modo tale da poter verificare anche eventuali colli di bottiglia nella logica stessa di business. Pagina 10 di 18

11 Architettura fisica Pagina 11 di 18

12 Architettura fisica Ruolo Test Preproduzione Produzione Note Test Note PRE PROD Note PROD IS- BROKER NOME NOME NOME Hardware Virtuale Virtuale Virtuale 2core 2core 2core 8 GB 20 GB 32 GB Interno 10 GB 20 GB su DB usato per OpenView (anche per Storage Interno 10 GB Interno 10 GB webmethserver bam e IS) Software Linux Red Hat Linux Red Hat Linux Red Hat Web Methods Integration Server Web Methods Integration Server Web Methods Integration Server Broker Broker Broker BPM BPM BPM WebMethServer NOME NOME NOME Hardware Virtuale Virtuale Virtuale 2core 2core 2core 4 GB 8 GB 10 GB Storage Interno 10 GB Interno 10 GB Interno 10 GB Software Linux Red Hat Linux Red Hat Linux Red Hat Web Methods Server Web Methods Server Web Methods Server BAM BAM BAM Mash Zone Mash Zone Mash Zone CEP NOME NOME NOME Hardware Virtuale Virtuale Virtuale 1core 1core 1core 4 GB 4 GB 6 GB Storage Software Linux Red Hat Linux Red Hat Linux Red Hat CEP CEP CEP Macchina Fisica 2 CPU - 4 Core - Memory 64GB. Per gli Macchina Fisica 2 ambienti di test e pre CPU - 4 Core - produzione abbiamo la stessa Memory 64GB machcina fisica. Uso del BPM per monitor processi Si dà un indicazione teorica sulle procedure di analisi dei processi tramite log applicativi e log sistemistici. Le indicazioni vengono fornite in base all as is e standard carrefour. Sulla base delle applicazioni in essere, dunque già in produzione, è preferibile adottare la tecnica meno invasiva, senza cioè cambiare logiche e riscrivere parzialmente gli applicativi per un eventuale monitoraggio con il BPM. Le possibilità di utilizzo del software BPM per monitoraggio si basa essenzialmente alle possibile lettura, non esclusive, di file,database, sistema operativo (syslog, event log, code su as/400) e applicativo di monitoring OVO (HP OpenView). Pagina 12 di 18

13 Valutazione impatti della sorgente dati Valutando le possibili modalità di estrapolazione dei dati si schematizzano le seguenti possibilità: 1. Lettura diretta con diverse modalità (file,db,code) da applicazioni 2. Lettura dei log da HP OpenView OVO Pagina 13 di 18

14 Ove possibile si può rendere necessaria anche una lettura che renda il sistema OVO come una possibile applicazione avendo cosi un sistema di lettura riportato qui nel disegno sottostante; questa esigenza si può avere quando il sistema OVO ha informazioni Incomplete o totalmente mancanti per l applicazione da monitorare. Partendo da questi presupposti analizziamo in dettaglio le quattro possibilità di lettura legate risolvibili con la tecnologia adottata: 1. File I log delle applicazioni scritte su file possono essere lette in modo continuo,come se fosse un istruzione di tail, costruendo una procedura custom in linguaggio java ed inserendola in ambiente web methods. L uso dell adapter per file in questo caso sarebbe scorretto in quanto non leggere solo le ultime informazioni scritte, ma tutto il file. 2. Database Per le applicazioni che usano database relazionali (DB2, DB2 per AS400,Oracle o sqlserver) come recipiente per i log applicativi l adattatore predisposto allo scambio di dati in scrittura o lettura è l adapter JDBC. Con questo connettore si ha la possibilità di leggere realtime dati relativi scritti su una o più tabelle relazionale e pubblicarli direttamente sul WebMethods broker. Pagina 14 di 18

15 3. Sistemi Operativi AS/400 Per le applicazioni basate su sistema as/400 per il recupero di informazioni,esecuzioni programmi rpg e comandi verrà usato l adattatore per AS/400. Esso è in grado di comunicare in base alla connessione configurata se eseguire programmi o di leggere in realtime DataQueue. Tutt ora la maggior parte delle applicazioni scritte in RPG usano tali code per comunicare il risultato di un operazione applicativa. UNIX/Linux Per le applicazioni che scrivono direttamente su file log del sistema si il metodo di lettura è il medesimo descritto per il file. Windows Per le applicazioni che scrivono direttamente su file log del sistema si il metodo di lettura è il medesimo descritto per il file. 4. HP OpenView (OVO) I log delle applicazioni monitorate da OVO vengono salvate all interno dell applicativo OVO appoggiandosi ad un Database relazionale Oracle. Quindi per recuperare i log delle applicazioni,che vengono poi visti e monitorati attualmente da utenti, si userà un jdbc adapter. Riassumendo schematizziamo con una matrice modalità di lettura/sistema operativo la tecnologia di connettori adatta per interfacciarsi al sistema di log. Windows Unix OS 400 FILE libreria java interna flow service libreria java interna flow service libreria java interna flow service Database jdbc adapter jdbc adapter jdbc adapter OS (syslog, event log, code as/400) libreria java interna flow service libreria java interna flow service adapter as/400 OVO (OpenView) jdbc adapter jdbc adapter jdbc adapter In base all analisi fatta sulle possibilità di estrapolare i dati di log diamo un ordine di preferenza della sorgente dati : a. HP OpenView OVO L applicativo OpenView centralizza tutti i file di log delle applicazioni e registra questi dati in un database oracle. Qui i log delle varie applicazioni possono essere estratti per definire se un flusso di business abbia concluso il suo normale iter. In aggiunta, OpenView è in grado di filtrare in base alle Pagina 15 di 18

16 esigenze determinati informazioni, per cui un eventuale ricerca di nuove stringhe nei log può essere compiuta da tale applicativo. Per la centralizzazione delle informazioni e la facilità di recupero grazie all uso del jdbc adapter l uso di OpenView come fonte di informazioni è preferibile rispetto alle altre. b. Database I log scritti nei database, siano essi su sistema operativo windows,unix o OS/400 sono facilmente recuperabili tramite l adapter messo a disposizione dalla tecnologia software AG senza scrivere codice aggiuntivo. c. File Per monitorare real-time un file di log con tecnologia software AG si necessità di scrivere in java un modulo per poterlo monitorare come farebbe un istruzione tail. Questo modulo deve poter interagire con l integration server se costruito come applicativo standalone o inglobato all interno di un adapter custom. d. SO Per monitorare syslog su UNIX e i file di log di windows (eventi) si usa la stessa modalità per i file di log descritti nel punto (c). Per i sistemi basati su OS/400, invece si ha la possibilità di leggere realtime i dataqueue. Per questa possibilità in ambiente AS/400 risulta più semplice monitorare i log di una applicazione. Pagina 16 di 18

17 Architettura della soluzione Principi di implementazione del BPM per il monitoraggio L utilizzazione del business process management in ambito di monitoring prevede il delineamento e la costruzione di flussi per il monitoraggio degli stati di avanzamento applicativo. Il livello di personalizzazione di controllo applicativo dei flussi di monitoring verrà eseguito sui flussi BPM, dunque dettate ove possibile dalla logica del business. Il flusso BPM dovrà essere studiato per gestire delle informazioni date dai Flow Service i quali si occuperanno di amministrare lo scambio di dati con le entità esterne. Questi moduli sono realizzati internamente all integration service e rappresentano lo strato logico software orientato al sistema finale o moduli generalizzati per uso comune. All interno dei moduli flow service abbiamo l interfacciamento a chiamate verso gli adapter in base al sistema coinvolto. Essi rappresentano l integrazione fisica con il sistema finale. Pagina 17 di 18

18 La segnalazione della comunicazione dell alert per il non completamento dell iter di business di un determinato processo deve essere inviata ad OpenView. La possibilità di comunicazione è tramite protocollo SNMP o tramite web service esposti da OpenView Per maggior completezza del sistema di monitoraggio si può usare in aggiunta allo strumento BMP anche il Business Activity Monitoring per un più completo monitoraggio. Inoltre, l uso del mash zone per una reportistica grafica è consigliata per statistiche (KPI). Utilizzando degli indici possiamo avere delle indicazioni numeriche sul numero di processi andati a buon fine o quanti hanno avuto problemi. Per la comunicazione dei vari componenti la messaggistica deve essere garantita (modello di comunicazione message queue). Il tempo di expiration dei messaggi deve essere infinito in quanto se i messaggi servono per statistiche non devono essere tolti dalle rispettive code. Contrariamente se le statistiche riguardanti errori,warning e controlli dei step non si vorranno valutare andrà rivista l eliminazione del messaggio entro un lasso di tempo dettato da logiche di business. Impatti su applicazioni nuove che dovranno essere monitorate Per standardizzare sia l architettura coinvolta nel monitoraggio sia le applicazioni monitorate si delineano le seguenti considerazioni : L implementazione di una o più tabelle di audit centralizzate per gestire tutti i logs delle applicazioni facenti parte di un sistema è auspicabile per uniformare la logica e le informazioni dei log. Sui sistemi AS/400 dove risiede un istanza DB2 per AS/400 si può assumere quanto detto sopra. Se ciò non fosse possibile i dati verrebbero scambiati tramite data queue. La scrittura dell informazione dei log e l uniformità della logica deve essere rispettata anche per gli applicativi. Ogni applicativo deve rispettare una struttura di informazioni in modo che la singola informazione scritta possa essere identificata univocamente. Creare in base all ambiente di riferimento una procedura ad hoc per la scrittura dei log sulle tabelle specifiche di audit. Ad esempio su software Oracle si possono creare delle stored procedure in modo che gli applicativi si interfaccino con esse e non accedere direttamente sulle tabelle. Criticità residue Nessuna criticità residua è stata identificata. Pagina 18 di 18