Consolidamento di Database

I processi di consolidamento consentono di ottenere costi di gestione meno elevati, apportare una maggiore semplicità nella gestione dei database e possono inoltre migliorare sensibilmente la qualità dei livelli di servizio.

Un recente sondaggio indipendente ha messo in luce che il consolidamento di database è molto più di un semplice fenomeno passeggero.
L’indagine ha evidenziato che già il 6 % delle imprese ha portato a termine un progetto di consolidamento, mentre quasi la metà ne sta valutando la fattibilità o si trova
nelle fasi iniziali dello stesso.
Di seguito i punti di maggior interesse emersi dall’indagine:

• Oltre il 70 % delle aziende sono coinvolte in progetti di consolidamento di database di un certo livello, ma almeno la metà di queste sono soltanto all’inizio

• Eliminare fornitori specifici non è l’obiettivo finale, ma il passaggio obbligato attraverso il quale si realizza il consolidamento. Le aziende sono intenzionate a ridurre il numero di database, ma lo fanno puntando su alcuni vendor ben precisi

• Il consolidamento dei database si prefigura come una contesa tra due fattori: il raggiungimento di una fondamentale maturità tecnologica da un lato, e gli oneri relativi
alla gestione e i costi dell’IT dall’altro

• Tra le tre grandi aziende fornitrici di database, Oracle è quella che più delle altre si sta imponendo nel mercato del consolidamento

• Alcune aziende sono disposte ad avviare un processo di consolidamento così radicale da rivalutare a fondo la scelta del loro principale fornitore di database, questo è il motivo per cui IBM DB2 sta incontrando più difficoltà a mantenere la propria quota di mercato

I motivi principali per intraprendere un processo di consolidamento:

o Ridurre il TCO (Total Cost of Ownership) – numero di licenze, personale interno, consulenze esterne;

o Migliorare il livello di affidabilità con effetti positivi a livello di SLA;

o Innalzare il livello di sicurezza;

o Migliorare la condivisione dei dati e la fruibilità degli stessi;

o Offrire un miglior supporto per la globalizzazione dei servizi;

o Determinare un miglioramento prestazionale per le applicazioni in uso;

o Offrire la possibilità di centralizzare backup e archiviazioni;

o Incrementare il ROI (Return Of Investments) per una maggior redditività

o In conclusione = ridurre il TCO di oltre il 20 %

Le aziende che hanno intrapreso questo cammino hanno posto in essere un progetto di consolidamento che si basa su un procedimento ben noto e testato suddiviso nelle tre fasi di ricerca informazioni/raccolta dati/ disegno progettuale. Tale procedimento permette di ottenere una chiara tabella di marcia contenente i passi necessari per attuare la migliore strategia di consolidamento con la scelta delle architetture hardware e software più indicate e che preveda i costi realizzativi e i benefici in termini di incremento della redditività.

Autore: Stefano Quercia

Un database per archiviare le Trap

TRAPDB

Per poter avere localmente un database che faccia da repository delle trap SNMP provenienti dai dispositivi su cui facciamo monitoraggio, possiamo creare uno schema come quello proposto in questo WP.
Lo schema può facilmente essere interrogato da un applicativo web creato ad hoc, che illustreremo più avanti, in modo da avere una dashboard capace di attingere dal database ed esporre in maniera chiara e dinamica gli allarmi provenienti dal bacino di rete.

SNMP

Il protocollo SNMP permette il monitoraggio completo delle risorse dei sistemi o device di rete che abbiano un ip address e la community SNMP configurata correttamente. I pacchetti SNMP sono spesso già installati sui sistemi, ma qualora non lo fossero, elenco quelli che sono stati usati nell’ambiente descritto:

  • net-snmp-libs-5.3.2.2-9.el5
  • net-snmp-5.3.2.2-9.el5
  • net-snmp-utils-5.3.2.2-9.el5
  • perl-Net-SNMP-5.2.0-1.2.el5.rf

E’ necessario configurare la community affinchè vi sia comunicazione tra sorgente e destinazione, editando il file “/etc/snmp/snmpd.conf ” e compilando i campi relativi alla community:

####
# First, map the community name “public” into a “security name”
# sec.name source community
com2sec notConfigUser default public
rocommunity <yourcommunity>
trapcommunity <yourcommunity>

Restart del servizio:

service snmpd start

Configurare i servizi in modo che questi si avviino automaticamente all’avvio del sistema:

chkconfig –level 23456 snmpd on
chkconfig –level 23456 snmptrapd on

Check della corretta configurazione del servizio SNMP:

snmpwalk -v2c -c <community> <ip address> system

MySQL

MySQL sarà il Database che ospiterà le trap in arrivo dalle varie sorgenti, di seguito i pacchetto utilizzati nella soluzione proposta:

  • mysql-server-5.0.77-4.el5_4.2.x86_64.rpm
  • mx-2.0.6-2.2.2.x86_64.rpm
  • MySQL-python-1.2.1-1.x86_64.rpm
  • zlib-devel-1.2.3-3.x86_64.rpm
  • e2fsprogs-devel-1.39-23.el5.x86_64.rpm
  • keyutils-libs-devel-1.2-1.el5.x86_64.rpm
  • libsepol-devel-1.15.2-3.el5.x86_64.rpm
  • libselinux-devel-1.33.4-5.5.el5.x86_64.rpm
  • krb5-devel-1.6.1-36.el5_4.1.x86_64.rpm
  • openssl-devel-0.9.8e-12.el5_4.6.x86_64.rpm
  • mysql-devel-5.0.77-4.el5_4.2.x86_64.rpm

NOTE: Alcuni di questi pacchetti potrebbero essere già installati sul sistema, quindi fare attenzione alle versioni. Una volta installato il database, si procede con la configurazione per l’avvio automatico dei servizi all’avvio del Sistema:

chkconfig –levels 235 mysqld on

Fare lo start del servizio MySQL:

service mysqld start

Set the password for root user in MySQL:

/usr/bin/mysqladmin -u root password <yourpassword>
/usr/bin/mysqladmin -u root -h <hostname> password <yourpassword>

Connessione al database :

mysql -u root -p

Un volta installato il database, bisogna creare la struttura che ospiterà le trap in arrivo. La configurazione del database che chiameremo “traps” è relativamente semplice in quanto ha una sola tabella chiamata anch’essa “traps” ed è realizzata dallo script in shell, chiamato “createdb” che allegheremo nella prossima WP.

NOTE: Lo script richiede in input i seguenti parametri “dbname”, “dbuser “ e “dbpassword”
(i.e. # ./createdb <db> <user> <password>)
Sincerarsi di avere i privilegi di root.

Lo script creerà il database “traps” come riportato di seguito:

trap1

 

 

 

 

A seguire la tabella “traps” con i relativi campi

trap2

 

 

 

 

Di seguito la descrizione dei campi contenuti in tabella:

  • trap_id, identificativo unico della trap e del relative tempo di ricezione in millisecondi (unix-time format) ;
  • timestamp, rappresenta il tempo di ricezione della trap in human language ;
  • hostname, rappresent l’hostname della sorgente che ha inviato la trap ;
  • ipaddr, , rappresenta l’ip address della sorgente che ha inviato la trap ;
  • sysuti, fornisce il valore di uptime del servizio SNMP (sysUptimeInstance) ;
  • trapent, indentifica il tipo di oggetto che ha generato la trap (TrapEnterprise) ;
  • trapoid, rappresenta la variabile OID che verrà interpretata dal protocollo ;
  • community, rappresenta la community utilizzata per l’invio della relativa trap ;
  • message, contiene il messaggio che descrive l’allarme ;
  • severity, rappresenta la severity dell’allarme (Critical, Major, Warning, Minor, Normal) ;

Per poter intercettare le traps inviate dai vari nodi, è stato creato uno script in perl chiamato “handle.pl” (che allegherò nel prossimo WP) il quale le inserirà poi nel database appena creato.
Il path dello script deve essere configurato nel file di configurazione “/etc/snmp/snmptrapd.conf ”, così come segue:

authCommunity log,execute <community>
traphandle default /usr/bin/perl /<absolute path>/handle.pl

NOTE: Ricordarsi di aver configurato correttamente il “dbname”, “dbuser” e “dbpassword” nella sezione “dbi:mysql” dello script “handle.pl”.

La parte di configurazione lato TRAPDB è terminata, una volta verificata la corretta configurazione SNMP della parte sorgente, si può controllare la corretta ricezione delle traps all’interno della tabella traps del database traps.

 

Autore: Vincenzo Capasso

Openvpn

Nei server di laboratorio, abbiamo installato vari tool aziendali di planning e gestione del personale, ovviamente raggiungibili soltanto dalla sede stessa. Avendo la necessità di esporre questi tool su internet, per usufruirne da qualsiasi sede, ed anche per eventuali condivisioni con il cliente finale. Per raggiungere questo obiettivo, abbiamo optato per un prodotto Opensource, OpenVPN.

Questo prodotto, permette ad un client opportunamente configurato, di accedere alla rete aziendale da qualsiasi parte del mondo.

Per la nostra VPN, abbiamo utilizzato un server con Centos 6.5 64 bit. Installiamo Openvpn:

yum install openvpn easy-rsa

Il pacchetto di OpenVPN fornisce una serie di script già pronti, per la gestione dei certificati di accesso. Copiamo tali script nella cartella di OpenVPN:

cp -r /usr/share/easy-rsa/2.0/ /etc/openvpn/rsaopenvpntech_logo_rounded_antialiased

Spostiamoci sotto la cartella apeena copiata:

cd /etc/openvpn/rsa

Apriamo il file “vars” e editiamo i campi, questo velocizzerà la creazione dei certificato, è comodo per chi ha la necessità di creare molti certificati. Un esempio del file vars:

export KEY_SIZE=1024
export KEY_COUNTRY="IT"
export KEY_PROVINCE="IT"
export KEY_CITY="Roma"
export KEY_ORG="Converger"
export KEY_EMAIL="info@converger.it

Creiamo la nostra CA (certificate authority)

# source vars 
# NOTE: If you run ./clean-all, I will be doing a rm -rf on /etc/openvpn/rsa/keys
# ./clean-all

Ora possiamo generare la nostra Certificate Authority: è necessario richiamare anche lo script “clean-all” per iniziare con un ambiente pulito. A questo punto siamo pronti per generare la nostra CA (certificate authority):

# ./build-ca
Generating a 1024 bit RSA private key..................................................
++++++...++++++
writing new private key to 'ca.key'----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [IT]:
State or Province Name (full name) [IT]:
Locality Name (eg, city) [Roma]:
Organization Name (eg, company) [Converger]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) [Converger CA]:
Email Address [info@converger.it]:

I valori di default vengono letti dal file vars sopra customizzato. Ora possiamo creare il certificato per il server VPN:

# ./build-key-server ConvergerVPN

ConvergerVPN è il nome della macchina su cui sto installando il server VPN, per coerenza la coppia chiave/certificato avrà il nome dell’host su cui viene usato.

Per evitare che ad ogni riavvio di OpenVPN sia richiesta una password premere invio senza inserire nulla alla richiesta di password:

Generating a 1024 bit RSA private key..................
++++++.++++++
writing new private key to ConvergerVPN .key'-----You are about to be asked to enter information that will be incorporatedinto your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [IT]:
State or Province Name (full name) [IT]:
Locality Name (eg, city) [Roma]:
Organization Name (eg, company) [Converger]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) [ConvergerVPN ]:
Email Address [info@converger.it]:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:password
An optional company name []:
Using configuration from /etc/openvpn/rsa/openssl.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName           :PRINTABLE:'IT'
stateOrProvinceName   :PRINTABLE:'IT'
localityName          :PRINTABLE:'Roma'
organizationName      :PRINTABLE:'Converger'
commonName            :PRINTABLE:' ConvergerVPN  '
emailAddress          :IA5STRING:'info@converger.it'
Certificate is to be certified until Nov 25 13:50:00 2020 GMT (3650 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

Procediamo alla creazione del file Diffie-Hellman, necessario per l’avvio delle connessioni cifrate.OpenVPN

# ./build-dh
Generating DH parameters, 1024 bit long safe prime, generator 2
This is going to take a long time
........+............

Realizziamo l’ultima chiave necessaria per l’instaurazione di una connessione sicura:

# openvpn --genkey --secret keys/ta.key

Generazione dei certificati per i client

La procedura per generare i certificati dei client è identica a quella del server, nell’esempio li creiamo nominali per una semplice identificazione, in caso di grandi numeri è possible usare la matricola aziendale.

# cd /etc/openvpn/rsa
# source vars 
# NOTE: If you run ./clean-all, I will be doing a rm -rf on /etc/openvpn/easy-rsa/keys  (ignorare il meassaggio)
# ./build-key rmassimi
Generating a 1024 bit RSA private key
..........................................++++++
................................................++++++
writing new private key to 'rmassimi.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [IT]:
State or Province Name (full name) [RM]:
Locality Name (eg, city) [Roma]:
Organization Name (eg, company) [Converger]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) [rmassimi]:
Name []:Roberto Massimi
Email Address [info@converger.it]:rmassimi@converger.it
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Using configuration from /etc/openvpn/easy-rsa/openssl.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName           :PRINTABLE:'IT'
stateOrProvinceName   :PRINTABLE:'RM'
localityName          :PRINTABLE:'Roma'
organizationName      :PRINTABLE:'Converger'
commonName            :PRINTABLE:'rmassimi'
name                  :PRINTABLE:'Roberto Massimi'
emailAddress          :IA5STRING:'rmassimi@converger.it'
Certificate is to be certified until Nov 26 14:29:37 2024 GMT (3650 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

 Configurazione del server

Ora andiamo a configurare il demone OpenVPN, anche in questo caso il pacchetto dovrebbe portare con se degli esempi.

# cp /usr/share/doc/openvpn-2.3.2/sample/sample-config-files/server.conf /etc/openvpn/

Di seguito un file di configurazione:

 # SERVER CONF
port 443
proto tcp
dev tun
ca rsa/keys/ca.crt
cert rsa/keys/rcc001ws.crt
key rsa/keys/rcc001ws.key  # This file should be kept secret
dh rsa/keys/dh2048.pem
server 10.1.1.0  255.255.255.0
ifconfig-pool-persist ipp.txt
client-config-dir ccd
route 10.1.1.0 255.255.255.0
keepalive 10 120
cipher AES-256-CBC
comp-lzo
persist-key
persist-tun
status /var/log/openvpn-status.log 5
status-version 2
log-append /var/log/openvpn-status.log
verb 3
keepalive 10 60
push route "10.31.57.0 255.255.255.0"
crl-verify /etc/openvpn/crl.pem

In questo modo, dopo connesso in vpn, tutto funzionerà come prima, ma il nostro PC avrà una nuova interfaccia di rete con IP 10.1.1.x e tutti gli IP della classe 10.31.57.x verranno dirottati sulla VPN.In questa configurazione, rilasciamo IP ai client del tipo 10.1.1.x ed aggiungiamo la rotta 10.31.57.x .

Configurazione di IPTABLES

Come ultimo step sul server, dobbiamo abilitare il fowarding e il MASQUERADE tramite IPTABLES:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.1.1.0/24 -o eth0 -j MASQUERADE

Se abbiamo IPTABLES configurato andiamo ad aggiungere anche le policy di ACCEPT:

iptables -A INPUT -i tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -j ACCEPT

Avviare il demone di OpenVPN e configurare i certificati dei client.

Configurazione dei client

Per prima cosa dobbiamo copiarci i certificati:

  • La coppia certificato/chiave per il client (i due file .key e .crt)
  • Il certificato della CA del server (il file ca.crt)
  • La chiave di autenticazione TLS (il file ta.key)

File client.opvn:

client 
dev tun
proto tcp
remote IP_SERVER_VPN 443
resolv-retry infinitenobind
persist-key
persist-tun
# THE CSR FILE:
ca ca.crt
cert rmassimi.crt
key rmassimi.key
ns-cert-type server
cipher AES-256-CBC
comp-lzo
verb 3
route-method exe
route-delay 2

Lanciando questa configurazione con openVPN del client, noterete una nuova scheda di rete 10.1.1.x . Se ora provate ad aprire un qualsiasi tool o sistema sulla rete 10.31.57.x, questo risulterà disponibile!
Autore: Roberto Massimi

Bulk Email

Bulk Mail con Mandrillapp, soluzione facile e gratuita

invio_massivo_email_intro2Molti sistemisti spesso si ritrovano davanti l’esigenza di dover inviare email automatiche a lunghe liste di destinatari. Registrare un account email dedicato e sviluppare uno script che invii le email è facile come cercare una moto usata su internet, basta avere un po’ di pazienza e trovare la soluzione più adatta alle nostre esigenze.

Ma cosa succede nel momento in cui la lista degli indirizzi diventa sull’ordine delle centina di indirizzi o addirittura migliaia?

Le regole antispam dei firewall di tutti i domini, sono molto “rigidi” quando vedono che un singolo account di posta elettronica, invia migliaia di email consecutive e finire nelle blacklist degli spammer è solo una questione di tempo.

A questo punto bisognerebbe vagliare tutte le proposte on-line di servizi di “Bulk-Send” o “messaggi massivi”. Questi provider sono provvisti di server smtp che vengono “riconosciuti” da tutti i domini come account bulk sender, quindi autorizzati ad inviare flussi di messaggi, senza essere bloccati o “rimbalzati” dai provider di posta elettronica.

La giungla delle offerte è veramente vasta, dal costo unitario per singola mail ad offerte stile supermercato all’ingrosso, più ne invii, meno ne paghi. Quindi a questo punto il sistemista, dopo aver valutato tutte le offerte, dovrebbe proporre la migliore all’eventuale cliente/commerciale per poter procedere all’acquisto del servizio ed iniziare la configurazione. Poi si torna con i piedi sulla terra, dove la richiesta dei PM è sempre “dammi la Luna, ma mi raccomando, GRATIS”.

Ed ecco arrivare in nostro aiuto Mandrillapp (www.mandrillapp.com), dove con una semplice registrazione assolutamente gratuita, si ha la possibilità di inviare fino a 12.000 messaggi al mese in modo totalmente gratuito, con una frequenza di massimo 250 messaggi l’ora.

Quest’ultima caratteristica potrebbe sembrare una limitazione, già il sistemista starà pensando a come suddividere le sue mail in trunk da 250invio_massivo_email_intro messaggi, invece no. Possiamo tranquillamente inviare tutte le nostre mail, sarà Mandrillapp a suddivere i messaggi. Una volta raggiunte le prime 250 email, le altre verranno depositate in una coda. Appena termina la prima ora di attesa, partono le 250 seguenti e così via, potendo inviare fino a 6000 email in 24h.

Già tutto questo basterebbe per convincere molti, ma i veri punti forza di questo provider sono:

– Facilità d’uso

– Grafici e statistiche personali

Infatti per utilizzare Mandrillapp, basterà usare l’smtp fornito in fase di registrazione ed il proprio utente ed ogni mail verrà inviata in modalità “on behalf of” del mittente a vostra scelta.

Una volta terminato l’invio, potremo interrogare tutte le statistiche fornite, che includono dati come:

– numero di email inviate

– numero di email consegnate

– numero di email “bounced” con motivazione

– numero di email aperte

Quindi se avete esigenza di inviare mail di segnalazione, monitoring o semplicemente la vostra app invia messaggi, questa soluzione potrebbe fare anche al caso vostro.
Autore : Marco Capacci

Private Branch Exchange

Nell’ambito delle telecomunicazioni e in particolare delle comunicazioni telefoniche, un private branch exchange o PBX (Private Branch eXchange) è una centrale telefonica per uso privato. È principalmente usato nelle aziende per fornire una rete telefonica interna. Ma può anche essere utilizzata per connettersi all’esterno e fornire servizi di supporto telefonico tramite operatore (spesso chiamato inbound) o servizi di vendita telefonica e retention degli utenti (spesso chiamato outbound).

Il termine PABX (acronimo di Private Automatic Branch eXchange) indica una versione automatica di un PBX, ma oggi i due termini sono usati come sinonimi perché tutti i PBX in commercio sono completamente automatici.

pbxOgni centralino telefonico, di base, instaura una connessione fra gli apparati telefonici dei due utenti, mappando il numero chiamato in un telefono fisico, verificando che questo non sia impegnato; ciò vale sia all’interno della stessa azienda anche con due telefoni geograficamente molto distanti tra loro, ma con il vantaggio di comporre un numero ridotto di cifre (interno). Oppure instaura una connessione fra un interno e l’esterno tramite la rete telefonica pubblica (PSTN Public Switched Telephone Network) nel caso di chiamate inbound e outbound. Inoltre mantiene questa connessione per tutto il tempo necessario tramite un meccanismo di segnalazione gestito dalla stessa architettura interna tramite opportune schede.

Oltre alle funzioni base, possono essere presenti svariate altre funzionalità che differenziano i prodotti dei vari produttori (in particolare il produttore gestito sul progetto è AVAYA) fra le quali citiamo quelle che utilizziamo frequentemente:

  • Automatic Call Distribution (ACD), cioè la gestione completamente automatica della chiamata in funzione delle configurazioni fatte sul centralino. Permette di gestire il cosiddetto callflow della chiamata per la sua corretta gestione
  • Classi di servizio, tabelle di abilitazione o limitazione dei servizi associate ai telefoni interni;
  • Computer Telephony Integration (CTI), permette l’integrazione con software dedicati che gestiscono in modo più accurato la chiamata, tramite strategie di callflow telefonico (ad esempio con la piattaforma Genesys)
  • Documentazione traffico, possibilità di documentare il traffico in entrata ed uscita, utile nel caso di reportistica chiesta dal cliente sui volumi delle chiamate.
  • Interactive Voice Response (IVR), sistema interattivo con menù vocali preregistrati selezionabili tramite tastiera che genera toni DTMF, che permette di predisporre una alberatura di scelte da far selezionare all’utente che chiama il call center per instradarlo correttamente verso il servizio più idoneo alla sua richiesta.
  • Registrazione delle conversazioni, necessaria nel caso di vendita i contratti che per legge devono essere registrati e conservati come prova dell’avvenuta vendita.

Autore: Francesco Randazzo

PROJECT PORTFOLIO MANAGMENT

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

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

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

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.

Backup a caldo per soluzioni di DR di sistemi Linux

Nel corso del progetto DSC Vodafone, il nostro gruppo di lavoro si è trovato a dover cercare una soluzione a basso impatto economico per effettuare a caldo backup DR di sistemi Linux.
Dopo varie ricerche la soluzione adottata è stata quella di MondoRescue (http://www.mondorescue.org/), sw opensource che consente appunto, previa installazione sul sistema oggetto di backup, la creazione di file ISO “bootabili” per il ripristino completo del sistema in caso di disastro, anche su sistemi HW differenti (molto utile quindi anche per istallazione “in batteria”).

L’installazione del software nell’ambiente testato (RHEL6.5) prevede il download dei seguenti pacchetti:

  • genisoimage-1.1.9-12.el6.x86_64
  • afio-2.5-1.rhel6.x86_64
  • mindi-2.1.7-1.rhel6.x86_64
  • buffer-1.19-4.rhel6.x86_64
  • mindi-busybox-1.18.5-3.rhel6.x86_64
  • mondo-3.0.4-1.rhel6.x86_64

Ovviamente le release dei packages ed a volte il nome degli stessi, può cambiare in base alla distro o del periodo di installazione.

Il comando utilizzato nel nostro caso è stato il seguente:
# mondoarchive -i -d /workarea/mondo -E “/workarea|/opt/adc/adc/cdr|/tmp|/var/tmp” -s 8500m -T /workarea/mondo/tmp -S /workarea/mondo/tmp -OV -p `uname -n`_`date +%Y-%m-%d`

Si rimanda al man per i dettagli delle opzioni possibili ed approfondimento in base alla proprie esigenze; un accorgimento utile è quello di badare allo spazio disponibile nel FS di destinazione ISO e quello temporaneo.

I test di recovery del sistema sono stati eseguiti montando la ISO precedentemente creata dal “Virtual Drives” della Java modorescueIRC di ILO.

Una volta avviata la ISO è possibile scegliere se eseguire il recovery in modalità automatica (nuke) o interattiva (interactive).
Questa ultima possibilità da modo di decidere cosa ripristinare e cosa no.

Inoltre è possibile eseguire una comparazione tra il backup a nostra disposizione e il sistema che ci accingiamo a sovrascrivere (compare).

Al termine della procedura avremo il nostro sistema ripristinato al momento del backup.

Essendo la procedura di backup eseguibile a caldo, è possibile ovviamente schedulare in crontab la creazione della iso, per mantenere il backup aggiornato e consistente.

Autore: Filiberto Mannelli