PROJECT PORTFOLIO MANAGMENT

by in Gestione Progetti, Management

GESTIONE DELL’APPLICATIVO HP PPM (PROJECT PORTFOLIO MANAGMENT)

PPM è un prodotto HP che fornisce ai responsabili di progetto all’interno di un’organizzazione una gestione centralizzata dei processi, dei metodi e delle tecnologie utili ad analizzare e gestire collettivamente progetti in corso o previsti in base a numerose caratteristiche chiave. Gli obiettivi di PPM determinano un mix ottimale delle risorse per la consegna e per la programmazione delle attività per raggiungere meglio gli obiettivi operativi e finanziari di un’organizzazione (nel rispetto di vincoli imposti dai clienti, di obiettivi strategici, o fattori reali esterni)

AMBITO DI UTILIZZO

PPM è più rilevante per le aziende che desiderano intraprendere progetti multipli in una sola volta, che richiedono un efficace monitoraggio, l’assegnazione e la gestione di questi progetti.

ARCHITETTURA

L’architettura di PPM è composta da tre strati:

CLIENT TIER

ppmUn’interfaccia standard che viene eseguita usando Java Server Pages (JSP) e a cui si accede tramite un browser web. Il client comunica con il server applicativo usando un protocollo HTTP o HTTPS ed estrapola informazioni dal database tramite J2EE application server usando una session pool condivisa.Un’interfaccia Workbench visualizzata grazie ad un applet di Java installata sulla macchina del client e che viene fatta partire usando un Sun Java plug-in. Il client comunica con l’application server usando il protocollo RMI (Remote Method Invocation) oppure SRMI (Secure Remote Method Invocation) ottimizzato per l’uso di PPM.

APPLICATION SERVER TIER

Funziona sulle seguenti piattaforme: Microsoft® Windows®, Sun Solaris, HP-UX, IBM AIX, Red Hat Linux, and SUSE Linux. Utilizza JBoss Application Server. Esso contiene attività di workflow, scheduling, notifiche e motori di esecuzione che guidano attività automatizzate che eseguono rapporti pianificati e notifiche e-mail. L’application server comunica con il server Web di PPM utilizzando Apache JServ Protocol versione 1.3, o AJP13 e con il database attraverso JDBC (Java Database Connectivity)

DATABASE TIER

Il database impiegato è Oracle e contiene tutte le transazioni, le attività di configurazione e dati di audit.
Il database ha due schemi: uno schema centrale che contiene il modello di dati di PPM e il codice del pacchetto. Il primo contiene tutti i dati di configurazione e di transazione ed uno schema RML (Reporting Meta Layer) che contiene un insieme di viste del database per facilitare la segnalazione dei dati di PPM.

Autore: Francesca Peleggi

HP Non Stop Kernel

by in System Administration

HP Non Stop Kernel (aka HP NSK)

nskCosa è
Hp NonStop è un sistema disegnato e costruito per sopravvivere a fault hardware/software, situazione che per la maggior parte delle altre tipologie di sistemi, sarebbe fatale.
Queste sue caratteristiche lo portano alla realizzazione di sistemi full 24/7.

Fault-tollerance hardware
Un node server NSK implementa ridondanza HW interna. Ogni componente (unità di calcolo, unità di rete, unità di storage, etc…) è sempre costituita da ALMENO 2 unità.

Alcuni esempi di unità che costituiscono un sistema NSK:

UNITA’

 TIPOLOGIA NUMERO

CPU

 HP BLxxx 2 – 16

RAM

HP BLxxx

2+

NIC

HP DLxxx

2+
STORAGE HP DLxxx e/o (HP EVA o HP MSA)

2+


Fault-tollerance software
Il concetto stesso di sistema operativo è molto singolare;.

Qualsiasi cosa in Hp NonStop è implementato attraverso il concetto di sottosistema: dischi, connettività di rete, shell, database, il kernel stesso. Ogni CPU lavora indipendentemente dalle altre in un ambiente non condiviso ma coordinato dal sottosistema Kernel.

La scalabilità di sistema è realizzata con il parallelismo dei processi e non dei thread. E’ possibile eseguire il medesimo processo su ogni CPU del NSK. Il sistema stesso si occupa della distribuzione del carico di lavoro. L’alta affidabilità software è garantita configurando l’esecuzione in modalità transazionale di un processo (Process pair).

Dove
Telecomunicazioni, ATM bancari, servizi telefonici di emergenza, Point of Sale (POS), etc. sono alcuni esempi di sistemi in cui il completamento di transazioni è linfa vitale. Un sistema HpNon Stop garantisce tempi di inattività, in minuti, vicino allo zero annuo.

Autori: Alessandro Pioli, Manuel Quattrociocchi

Il database è lento

by in Database, Infrastruttura

Il database è lento.

Penso che chiunque lavori nell’IT, almeno una volta nella vita abbia sentito pronunciare queste parole. Se poi come mestiere fa il DBA allora gli srelational-databasesarà capitato molto ma molto spesso. Ogni volta che le sento penso, il database non può andare lento, non si muove, casomai sarà qualche processo/flusso che risponde lentamente, ma di sicuro non il database che va lento. Altrettanto spesso chi pronuncia quelle parole crede che ci sia un parametro FAST=TRUE con il quale risolvere tutti i problemi. Ovviamente quel parametro, per fortuna, non esiste altrimenti lo metterebbe direttamente a TRUE senza chiedere e non esisterebbero i DBA. Detto questo però, rimane il problema vero o percepito che sia, del quale sappiamo poco o niente e ci viene dato pochissimo tempo per risolvere. In fondo per mettere un parametro a TRUE quanto tempo ci volete mettere? Che fare a questo punto?

C’è un’equazione che riassume tutto il lavoro di un database, con la quale si può avere un’idea di massima delle sue performance e che a me è stata sempre utile ad inquadrare i problemi. Quell’equazione è:

ResponseTime = ServiceTime + WaitTime

Il lavoro di un database può essere misurato come la somma dei tempi di risposta di tutti gli statement (select, insert, create etc…) in un dato periodo di tempo. Il numero che si ricava è il ResponseTime che è uguale alla somma dei tempi di servizio (ServiceTime), ovvero il tempo in cui quello statement e’ eseguito in CPU e dei tempi di attesa (WaitTime), cioè il tempo che quello statement ha atteso una specifica risorsa.

Dunque, se il ResponseTime è simile al periodo di tempo preso in esame, ci potrebbe essere un pricon23Databaseoblema di capacità di calcolo. Se è molto piccolo il database o non fa nulla oppure ha attese elevate per qualche causa specifica. Se la percentuale di WaitTime è molto più alta di quella del ServiceTime, c’è un problema di risorse. Se invece il ServiceTime è piu alto del WaitTime e il ResponseTime è minore del periodo di tempo preso in analisi, il database va bene e se c’è un problema è molto specifico o relativo ad una frazione di tempo inferiore a quella presa in esame. Di solito si usano tempi di raccolta dei dati di circa un’ora, ma mi sono capitati casi in cui sono dovuto scendere fino a 5 minuti per trovare il problema. Si potrebbe continuare con esempi all’infinito, ma va oltre lo scopo di questa discussione. Basta mettere la formula su google per trovare infiniti documenti, quando lo farete valutate sempre bene chi scrive, non tutti dovrebbero poterlo fare, metalink e ask tom sono ottimi punti di partenza.

Oracle fornisce questi dati negli AWR report e li riassume all’inizio nei : Top 5 Wait Events

Capire il significato di questi tre numeri, come confrontarli tra loro oppure paragonarli a quelli collezionati con altri database può essere una base solida da cui far partire un’analisi per il tuning del database. Con il passare del tempo con l’esperienza diranno sempre di più e semplificheranno parecchio la vita laddove in qualche progetto dove sarete appena arrivati, senza alcuna informazione, dovrete dare una qualche risposta al cliente. Ricordate però che è solo un punto di partenza. Fare il tuning di un database è difficile richiede tempo e tanta tantissima esperienza. Per il momento si può cominciare da qui.

Autore: Stefano Compieta

VMWARE e HP C7000: velocità, facilità d’uso e sicurezza dei dati

by in System Administration

VMWARE vSphere ESX 5.0+ Enclosure HP C7000+SAN: velocità, facilità d’uso e sicurezza dei dati il tutto senza rinunciare alla scalabilità dell’infrastruttura e garantendo la continuità dei servizi anche nelle situazioni più critiche.

LE BASI

VMWARE

Il sistema di virtualizzazione che andremo ad usare è quello fornito da VMware per la sua alta affidabilità (HA). Infatti vSphere ESX, garantisce la disponibilità delle macchine virtuali all’interno di un ambiente, sapendo l’estrema importanza che questo ha per gli amministratori di sistema.
VMware HA allevia questi problemi fornendo una protezione dai guasti su i tre layer principali:

  • Infrastruttura: A questo livello, VMware HA controlla lo stato della macchina virtuale e tenterà di riavviarla, quando un guasto (come la perdita di un host fisico)si verifica. Questa protezione è indipendente dal sistema operativo utilizzato nella macchina virtuale.
    • Sistema Operativo: Attraverso l’uso dei VMware Tools installati all’interno del sistema operativo, VMware HA può monitorare il sistema operativo e il suo corretto funzionamento. Questo protegge contro possibili fallimenti (come un sistema operativo che non risponde).
    • Applicativo: Con qualche personalizzazione o con un tool di terze parti, un amministratore può anche monitorare il corretto funzionamento dell’applicazione in esecuzione all’interno del sistema operativo. In caso di guasto VMware HA può essere attivato per riavviare la macchina virtuale che ospita l’applicazione.

Enclosure HP C7000

L’enclosure hp c7000 è un contenitore di Blade, tra le sue caratteristiche ci sono la velocità (i sui virtual connect permettono un collegamento in fibra ridondato), la possibilità di espansione (può contenere fino a 16 half blade, 8 full blade), il sistema di gestione centralizzato (tramite l’onboard administrator si può controllare lo stato di tutti i blade), l’efficienza termica e la ridondanza del collegamento elettrico.
I blade utilizzati possono essere sia half  sia full, ed è possibile anche una configurazione mista che ci permette di utilizzare l’enclosure per più utilizzi.

SAN

Non è previsto l’utilizzo di una specifica SAN, le caratteristiche richieste sono:

  • Alte prestazioni;
  • Alta disponibilità;
  • Scalabilità;
  • Facilità di gestione.

LA CONFIGURAZIONE

La configurazione richiede del tempo ma i benefici sono tangibili, partendo dalla base di una SAN, quindi tutti i profitti  legati alla stessa (alta affidabilità,  ridondanza alle rotture, e velocità di accesso ai dati).
Lo zoning della San viene presentato ai Blade montati sul’enclosure c7000 grazie ai Virtual connect (moduli presenti sul c7000 che collegano l’enclosure al mondo),  il blade così è in grado di fare il boot sulla SAN bypassando i dischi locali. L’installazione del Sistema Operativo ESX prosegue in modo standard, al termine avremmo un sistema performante che sfrutta la velocità dei dischi sulla SAN.
Installato l’ESX ed effettuata la configurazione base abbiamo la possibilità di iniziare ad installare le Virtual Machines, come datastore possiamo utilizzare la stessa SAN, massimizzando e ottimizzando l’utilizzo di quest’ultima. Le macchine virtuali installate potranno essere attestate su un singolo blade ed in caso di necessità o di eventuali fault essere migrate su un altro blade mantenendo attiva l’operatività del sistema.
Il sistema permette così di migrare le macchine virtuali e mettere momentaneamente un server fuori FARM per eventuali riparazioni, o di sostituire l’intera lama senza dover reinstallare il sistema operativo minimizzando così i rischi di disservizi che tanto temono le aziende.

PRO
Il sistema prevede un’ottima scalabilità (è possibile aggiungere altri blade e collegare altre SAN)
Velocità e sicurezza
Possibilità di installare anche altri sistemi operativi su lame diverse sullo stesso c7000

CONTRO
Costo medio-alto

 

Autori: Giovanni Melis, Ermete De Luca e Gianluca Cavallari.