Soluzioni per
“Virtual Thin SCADA”,
con Ridondanza,
Thin Client,
Alta Disponibilità,
Fault Tolerance,
Ambienti Virtualizzati
ServiTecno srl – via Koristka,10 – 20154 Milano
Tel 02 486141 – Fax 02 48614441 - [email protected] - www.servitecno.it
tto in collaborazione con
Questo documento è stato redatto
Gray Matter, www.graymattersystems.co
systems.com.
Microsoft® is a registered trademark of Microsoft Corp
poration, in the United States
and/or other countries.
VMware is a registered trademark and VMmark is a tra
rademark of VMware, Inc.
The Proficy Suite, Proficy HMI/SCADA iFIX, and Proficy Historian are registered
trademarks of GE Intelligent Platforms.
All other brands or names are property of their respect
ctive holders.
In un passato neanche troppo remoto, l’utilizzo di architetture PC based per i sistemi di controllo non ha
sempre incontrato opinione favorevole da parte degli addetti ai lavori.
E ancora oggi alcuni “specialisti” del process control che, in qualche modo, mantengono quella
posizione.
A volte, quanto più la aziende si sono mosse verso soluzioni di informatizzazione basate su PC,
l’affidabilità, la manutenzione e la facilità di deployment di questi sistemi sono diventati punti critici.
Molte aziende oggi non possono più fare a meno di sistemi SCADA (basati su PC), sia per la necessità
monitoraggio degli impianti, sia per mantenere un electronic log dei propri dati critici, sia per motivi
legali o normativi, sia per le richieste di reporting di produzione o di processo.
Per prima cosa le aziende si sono impegnate con vari mezzi per aumentare la disponibilità e l’uptime dei
sistemi. Il metodo più usato è stato mettere in servizio un Server di riserva (back-up) pronto per essere
collegato ed entrare in funzione in caso di caduta del Server primario.
Col passare del tempo, il cold backup si è trasformato in hot backup, fino a formare una
coppia ridondante per eliminare la necessità di uno startup manuale del Server di backup.
Oggi, GE Intelligent Platforms rende disponibile la soluzione di Enhanced Failover abbinata alla
propria soluzione SCADA Proficy iFIX 5.8.
Enhanced Failover automaticamente sincronizza il database di processo dei due data Server tramite
una linea dedicata, con uno dei Server che viene tenuto attivo e l’altro che rimane in standby, pronto a
intervenire in caso di caduta del Server attivo.
SCADA Network
SCADA SYNC
Primary SCADA
Backup SCADA
I/O Network
Coppia di Server SCADA con GE Intelligent Platforms Enhanced Failover
I Server non sono gli unici componenti dell’architettura che possono cadere: ci sono anche i Client
che possono avere lo stesso problema.
Il tempo necessario a rimpiazzare un PC Client può variare, ma se un tipico PC con “Fat Client” di
iFIX deve essere riavviato a partire dal sistema operativo, il tempo necessario all’operazione può
arrivare anche a qualche ora (circa mezza giornata). Questo tempo può essere ridotto disponendo
di un’immagine di ripristino da portare sul PC in sostituzione, oppure disponendo di un PC di
rimpiazzo già pronto da connettere.
Bisogna considerare che un anche PC di rimpiazzo dovrebbe anche essere configurato.
Anche il ripristino di un’ immagine richiede qualche intervento di impostazione e probabilmente
qualche intervento di updating, in funzione della frequenza con cui si sono effettuati i backup , se sono
stati previsti per tutti i Client o solo per alcune parti.
Anche con questi metodi va comunque previsto un tempo di gestione del back up e della messa in
esercizio, che può variare da una a qualche ora.
Client 1
Client 2
Client 3
Client N
SCADA Network
SCADA SYNC
Primary SCADA
Backup SCADA
I/O Network
Coppia di Server SCADA con GE Intelligent Platforms Enhanced Failover con Fat Client tradizionali
Per ovviare agli inconvenienti su indicati, in tempi recenti sono state approntate delle soluzioni che
utilizzano i prodotti della famiglia iFIX di GE Intelligent Platforms in abbinamento con VMWare,
Microsoft Remote Desktop Services ed ACP Thinmanager.
Questa soluzione consente facilità di manutenzione, gestione centralizzata, affidabilità, Alta
Disponibilità e Fault Tolerance.
Remote Desktop Services (RDS – conosciuto come Terminal Services) è un metodo di “Thin Client
Deployment”. Pur non essendo una tecnologia nuova, sta diventando molto nel settore al
crescere delle potenzialità e capacità di reti informative e risorse elettroniche.
RDS permette a un Client to di connettersi al Server attraverso una sessione di Remote Desktop
Protocol (RDP).
Tale connessione stabilisce una sessione Client sul Server, così che connettere un qualunque
device non richiede alcun programma applicativo che giri all’interno della sessione: l’elaborazione
avviene sul Server ed il Client non è che un “portale” di interfaccia sul Server.
Remote Desktop Services: molti vantaggi specifici
I file di configurazione per un progetto iFIX (immagini, parametri globali, impostazioni di configurazione,
security, …) sono tutti contenuti nel Server.
Quindi, qualunque variazione di qualsiasi file sul Terminal Server comporta una variazione globale per
tutti i Client RDS contenuti nel progetto considerato.
Se usando i tradizionali Fat Client si richiede di norma di installare variazioni ed aggiornamenti su ciascun
PC Fat Client, con RDP la sostituzione o l’aggiunta di Client risulta molto più semplice, in quanto è
sufficiente sostituire i device Thin Client e indirizzarli con il Terminal Server.
Per completare questo processo servono pochi minuti a confronto delle alcune ore necessarie per
riconfigurare un nuovo Fat Client o un PC in sostituzione.
La Licenza di iFIX si trova sul Terminal Server, allocata su base “concorrente”: una licenza è allora
utilizzata solo quando un Client sta effettivamente operando con iFIX e viene rilasciata quando non lo è.
L’ultima versione di iFIX 5.8 Terminal Server può gestire progetti multipli in un unico Server.
Ad esempio, si pensi a un sito in cui si trovano 3 linee con 3 progetti iFIX separati: un singolo
Terminal Server può elaborare tutti i 3 progetti al proprio interno.
Questo viene gestito con GE Proficy iFIX Startup Profile Manager.
Startup Profile Manager, rileva lo user name loggato e lo associa con un node name nella System
Configuration di iFIX per attivarlo. La System Configuration Utility (SCU) dispone allora di una lista di
percorsi di folder dove sono residenti i file per quel progetto.
Quando la linea 1 si logga sul Terminal Server con il proprio User Name di Windows, lo Startup Profile
Manager annota il nome ed avvia un’istanza Client con il node name della linea 1 (istanza di iFIX) e lo
appunta nei file di configurazione per la linea 1.
Da un lato le macchine con PC si collegano con RDP nel Terminal Server ed avviano una sessione,
dall’altro i Client possono avere un hardware di tipo “Thin Client” – di minor costo rispetto ai PC Fat
Client e con meno parti in movimento, con conseguente minor rischio di fuori servizio.
Non si tratta quindi di veri PC: sono “device” che fanno girare una sessione RDP semplicemente per
connettersi al Remote Desktop Server. Sono “scatole” più piccole e meno costose di tradizionali PC.
La sostituzione di un Thin Client è decisamente più semplice rispetto a un “vero PC” poiché la necessità
di configurazione è quasi inesistente: si inserisce nell’infrastruttura di rete e si collega a Terminal Server.
Rispetto alla sostituzione di un Fat Client, si tratta di minuti invece che di ore.
E diviene anche un’abitudine che si tengano a disposizione una paio di Thin Client di riserva, pronti per le
eventuali sostituzioni: tastiera, mouse e video monitor rimangono gli stessi dei “normali PC”
Se ci sono installati dei PC e non si vuole passare subito ai Thin Client, basta creare una sessione RDP da
desktop PC verso Remote Desktop Server per stabilire una sessione sul Server.
Coppia di Enhanced Failover SCADA Server di GE Intelligent Platforms con Terminal Server
e Thin Client
Client 1
Client 2
Client 3
Client N
Client 1 Client 2
Client 3 Client N
Local Server
Terminal Server
SCADA SYNC
Primary SCADA
Backup SCADA
I/O Network
Nel caso in cui si usi una coppia di Data Server (SCADA Server) ridondanti, e poi si introduce un singolo
Terminal Server per applicare la tecnologia di deployment di Client, si genera un single point of failure
nel sistema. In pratica, se cade il Terminal Server, si perdono i Client ad esso collegati.
Questo problema si può però risolvere in diversi modi.
Il primo prevede che ci sia un mix di Thin e Fat Client: in questo modo, anche se cade il
Terminal Server, i Fat Client continuano ad operare.
Tuttavia la presenza di Fat Client comporta l’aumento di risorse necessarie per gestire e
manutenere il sistema.
L’ altro metodo prevede l’utilizzo di Terminal Server di Back-up o Ridondante.
.
Coppia di Enhanced Failover SCADA Server di GE Intelligent Platforms con coppia di
Terminal Server (o Multipli) e Thin Client
L’ uso di un Terminal Server di Backup richiede di indirizzare i Client verso il corretto Terminal Server.
Questo può essere fatto manualmente impostando due shortcut sul desktop dei Client: una per
connettersi a un Server primario ed eventualmente un’altra per ristabilire le sessioni remote.
Questo processo manuale comporterebbe come conseguenza di avere il Client non collegato per il
tempo necessario a stabilire una sessione attiva sul Server di backup, tipicamente qualche minuto.
La soluzione a questo inconveniente è data da ACP ThinManager.
ACP ThinManager automatizza la connessione dei Thin Client ai
Terminal Server e indirizza i Thin Client verso il Server cui si devono
interfacciare. In pratica, quando si accende un Thin Client, questo
si connette al ACP ThinManager Server.
Questo Server può essere ridondante e tipicamente risiede con un
elemento sui Desktop Server (Terminal Server) Primary e di Backup
Remoto. In configurazione ridondante, ACP ThinManager stabilisce
una sessione RDP per il Thin Client sui Terminal Server, sia Primary
che di Backup.
I Thin Client useranno il Server primario o di backup in base alla loro disponibilità.
In caso di failure del Server che attualmente il Thin Client sta vedendo, molto semplicemente
reindirizza il Thin Client alla sessione sull’altro Server, senza che l’utente abbia un’interruzione di
connessione.
.
Log di Thin Client in ACP ThinManager: sui Terminal Server primario e secondario si hanno le sessioni stabilite da
Thinmanager
Questa è solo una delle possibilità di gestione offerte da ACP ThinManager.
Si può memorizzare l’Automatic Login per i devices . Si può impostare il lancio di applicazioni.
Via ACP ThinManager i Thin Client possono operare con monitor multipli o sessioni multiple da
un singolo device.
ACP ThinManager consente la connessione a tablet. Dispone anche di un programma chiamato
WinTMC che emula un Thin Client su PC desktop con lo scopo di connettersi a un ACP ThinManager
Server.
Altro grande beneficio è la possibilità per l’ amministratore di effettuare shadow da remoto delle
sessioni Client.
ACP ThinManager riesce a rendere quasi banale la sostituzione e il deployment dei Thin Client.
Quando si aggiunge un nuovo Thin Client, si inseriscono gli indirizzi IP dei Server ThinManager.
Alla connessione del Thin Client sarà richiesto all’utente se si tratta di un nuovo Thin Client o
una sostituzione. Se si tratta di una sostituzione indirizzerà l’utente ad un elenco di
configurazioni memorizzate.
Le configurazioni contengono informazioni relative al login, le app da lanciare, i setup dei
driver, etc. . L’ utente allora punta al Client che sta rimpiazzando e il processo è completato.
Lo stesso processo viene seguito per aggiungere un nuovo Client, ma invece di indicare che si sta
sostituendo un Client preesistente, si indica che se ne sta aggiungendo uno nuovo.
Sarà disponibile all’utente sia in caso di aggiunta di uno nuovo che di clonazione di uno esistente.
Se si è scelto di avere tutti i Thin Client uguali (consigliato), si può allora clonare una configurazione
esistente e apportare solo piccole variazioni (ad esempio il nome, o il nome di login da usare) e
procedere rapidamente al deployment.
Questi processi richiedono abitualmente un paio di minuti per essere completati.
Console di configurazione del Server di ThinManager
Coppia di Enhanced Failover SCADA Server di GE Intelligent Platforms con ACP ThinManager
Terminal Server Ridondante e Thin Client
Una volta che si è messo in funzione quanto precedentemente descritto, si può dire che è stato fatto un
buon lavoro per rendere il sistema ridondante e la manutenzione centralizzata.
Si è quindi andati bel al di là di quanto si poteva ottenere con una soluzione tradizionale basata su Server
e PC Fat Client.
Tuttavia si può fare ancora un passo ulteriore.
Si può virtualizzare il sistema e far leva sui vantaggi che una soluzione VMWare fornisce con l’offerta di
VSphere
Per virtualizzare si possono creare Server basati su software, indipendenti da hardware.
Questi Server possono funzionare su hardware differenti, fornendo innegabili benefici.
Usando Server software-based, si possono avere copie immagine del Server per effettuare test e/o
recuperi. VMWare fornisce il mezzo per catturare dinamicamente snapshot di Server virtuali che danno
modo di avere immagini del Server senza necessità di fare shut down. In tal modo, prima di applicare
delle patch o upgrade, si ottiene lo snapshot del Server, si procede con l’upgrade e, se qualcosa va
storto, si può tornare indietro all’immagine fissata.
Il processo di acquisizione dell’immagine richiede alcuni minuti, è di gran lunga più rapido del
tradizionale imaging del Server e può essere effettuato durante l’attività.
Per virtualizzare i Server, non è necessario disporre di tante piattaforme fisiche di Server per ospitare la
soluzione quanti sono i Server multipli che possono risiedere in una macchina host. Non si deve più
pensare a un Server come una macchina, un sistema operativo che gira su hardware. In una macchina
virtuale host (non un Server) le risorse sono suddivise tra più Server.
Se pensiamo a una soluzione di 4 Server (Primary e Backup iFIX Server, Primary e Backup iFix
Client Server), in passato (soluzione fisica) sarebbero stati necessari 4 Server, 4 “box”.
Questo comportava un grave dispendio di spazio e tipicamente un uso sporadico delle macchine
Server al massimo delle loro possibilità.
In molti casi, i Server SCADA sono utilizzati solo al 10-20% della capacità dell’hardware – a volte
anche meno. VMWare permette di allocare le risorse fisiche di una macchina host virtualizzata
nelle Virtual Server/Machine comprese nell’ambiente.
In più, consente di adattare dinamicamente queste impostazioni senza dover alterare l’hardware
fisico. Se un Server necessita di più o meno RAM o più o meno potenza di calcolo, si può intervenire
sulle impostazioni di quella Virtual Server/machine e cambiarle secondo necessità.
VMWare dichiara che la tecnologia VSphere consente di avere*:
•
•
•
80 % in più di utilizzo delle risorse del Server
Fino al 50 % di risparmio di costi di capitale e operativi
10:1 o più di consolidamento del Server
*Da www.VMWare.com/Virtualization/
Si può anche espandere l’ambiente virtuale per coprire host multipli in un ambiente VCenter.
Si opera nel modo prima visto, ma ora si può far leva sulle risorse di macchine host multiple.
In un certo modo si sta tornando agli anni 80, quando si disponeva di un “main-frame” e sessioni su
terminali remoti per accedere alle risorse di elaborazione.
Con VMWare, si accede all’ambiente virtuale usando Client VMWare VSphere.
Si installa il Client su un PC e lo si usa in connessione con il Virtual Center.
Da questo punto in poi, si accede a qualunque Server e si creano sessioni Console che consentono di
essere amministrate sia a livello di sistema operativo sia di Virtual Setting.
E si dispone di un set completo di gestione centralizzata, reporting e capacità di monitoring.
VCenter
Host Box 1
Virtual Servers
Host Box 2
Host Box 3
Accesso a VM Ware VCenter da VSphere Client - www.VMWare.com
In un VCenter, sono disponibili numerosi tool che aiutano a minimizzare il downtime del sistema.
VMotion consente di migrare dinamicamente un Server da un macchina host ad un’altra mentre il
Server è in funzione.
Come ipotesi, si possono migrare Server virtuali da una macchina host 1 ad una host 2 senza
interruzione di servizio.
Si può effettuare manutenzione sulla macchina host 2 quindi migrare i Server indietro alla macchina
originale senza interromperne le operazioni, dato che questa migrazione è dinamica e nelle più
recente versione di VMWare può essere fatta con i Server in servizio.
VMotion è un processo manuale, ma in VMWare si trovano altre soluzioni che automatizzano
le capacità di uptime.
.
VM Ware V Motion – www.VMWare.com
VMWare dispone di altre funzioni da utilizzare per mantenere il sistema in servizio e disponibile.
La prima funzione è chiamata VCenter High Availability.
High Availability avvia un Server virtuale su un altro host nel caso di Failure della macchina Host
primaria. Con l’ uso di High Availability si minimizza il downtime del Server per il tempo necessario al
reboot sull’altro host. Tipicamente il tempo di reboot su Server virtualizzati è decisamente inferiore alla
controparte fisica.
Spesso il boot di Server virtuali comporta qualche decina di secondi, a confronto dei minuti
necessari nel caso di macchine Server fisiche.
Con VCenter High Availability il processo di reboot è gestito automaticamente.
Qualora si utilizzassero Server SCADA ridondanti e Server Client ridondanti, l’operatore non noterebbe
alcuna interruzione di servizio nei Client.
Se l’ host primario cade, i Thin Client sono indirizzati da ACP ThinManager a vedere le sessioni già stabilite
sul Server dei Client di backup che attualmente sta ricevendo dati dal Server SCADA di backup.
Lo SCADA primario e il Server dei Client ripartono su un host disponibile e la ridondanza è ripresa in
pochi minuti, se non meno.
VM Ware High Availability – www.VMWare.com
Nella sua più evoluta versione, VMWare è dotato di una funzione chiamata Fault Tolerant. Quel che
succede è che quando un Server virtualizzato si avvia, viene attivata una versione shadow di tale
Server su un altro host: in caso di caduta dell’ host primario, il Server shadow lo sostituisce
immediatamente e questo comporta che il tempo di recovery sia nell’ordine di pochi secondi.
VM Ware FaultTolerant – www.VMWare.com
Si potrebbe erroneamente pensare che l’uso della tecnologia VMWare per la soluzione Fault Tolerant
non renda più necessarie le soluzioni di ridondanza di SCADA e Client.
Occorre però sapere che VMWare fornisce High Availability e Fault Tolerance in caso di failure hardware:
ciò che VMWare non fa è identificare riavviare un Server in caso di caduta del software.
iFIX Redundancy e ACP ThinManager forniscono strumenti per gestire la soluzione di ridondanza
software. Di conseguenza, per essere totalmente fault tolerant e ridondanti, è sicuramente più
indicato disporre di entrambe le tecnologie.
Soluzione A: Coppia di Enhanced Failover SCADA Server di GE Intelligent Platforms con ACP
ThinManager Redundant Terminal Server ospitato in ambiente VMWare VSphere
Client 1
Client 2
Client 3
Client N
VCenter
Host 1
COLL
SCADA Network
Host 3
Client 2
Client 1
Client N
Client 3
PDB
iFix 1
iHistorian
iFix TS1
Webspace
(Optional)
SAC
DRV
VCenter
Host 2
iFix 2
iFix TS2
ACP Thinmanager
Local Server
Host
Servers
Storage Area Network
(SAN)
IO Network
Storage Area Network
(SAN)
Ecco una tipica configurazione per Virtualized Thin Solution con una coppia ridondante di Server
SCADA, una coppia ridondante di Server Client, un Server per dati storici ed un web Server.
Tutti questi Server risiedono in un ambiente virtuale residente su tre macchine host con una SAN (Storage
Area Network) condivisa.
Usando questa impostazione si sono concentrati tutti i Server, i Client processing ed i file in un’unica
soluzione ad Alta Disponibilità, eventualmente Fault Tolerant ed accessibile da remoto.
Sia la configurazione che la security risiedono sui Server e, con le dovute credenziali, sono accessibili con
pochi click.
Soluzione B: Coppia di Enhanced Failover SCADA Server di GE Intelligent Platforms con ACP
ThinManager Redundant Terminal Server ospitato in ambiente Stratus EverRun MX.
In alternativa alla soluzione precedente in ambiente VMWare, ecco una tipica configurazione Con STRATUS
EverRun MX Enterprise con una coppia ridondante di Server SCADA, una coppia ridondante di Server Client,
un Server per dati storici ed un web Server, il tutto in un ambiente virtuale su solo due macchine Host SENZA
NECESSITA’ di una SAN (Storage Area Network) condivisa.
Con le soluzioni Stratus® everRun MX®, si può prevenire il downtime: ed in più, sono soluzioni pronte all’uso
che richiedono un intervento di supporto minimo da parte dell’ IT. La tecnologia Stratus everRun MX è la
prima soluzione Fault-Tolerant, software-based, che supporta single processor, symmetric multiprocessor
(SMP) e applicazioni multi-core Microsoft.
Con limitate risorse IT, si dispone di una soluzione semplice e cost-effective per avere tutte le applicazioni
disponibili anche in caso di System Failure, per garantire la continuità operativa. Con everRun MX tutte le
applicazioni Microsoft possono disporre di protezione Fault-Tolerant ad un costo inferiore delle tipiche
soluzioni di High Availability basate su recovery.
Usando tecnologia brevettata STRATUS, il software everRun MX combina le risorse fisiche di due server
standard Windows in un singolo ambiente operativo, con completa ridondanza di componenti HW e dati.
Il software everRun MX presenta ogni istanza di applicazione Windows come un singolo ambiente
am
su server
ridondanti, per mantenere attive le applicazioni anche nel caso di Failure
ailure di componenti o di sistema.
Il software everRun MX assicura la ridondanza di hardware, dati e network, per la gestione automatizzata di
situazioni di caduta. Questo è la garanzia di una vera continua disponibilità per applicazioni per le quali non è
accettabile né il downtime né la perdita di dati,
dati tipiche degli ambienti SCADA.
Caratteristiche Principali di Stratus EverRun MX per le applicazioni SCADA
Totale Fault Tolerance
La tecnologia EverRun MX e gestisce le cadute di sistema, rete e dischi, senza interventi da parte dell’ IT: le operazioni sono auto-curative
auto
e
garantiscono zero downtime.
Tecnologia ComputeThru™
La tecnologia ComputeThru brevettata da STRATUS garantisce disponibilità
dispo
di applicazioni assicurando un proattivo sbarramento al
downtime, via hardware, data e network ridondanti, così come anche la Disponibilità,
isponibilità, monitorando la creazione di una singola istanza
applicativa “always-on”.
Supporto a Multiprocessore Simmetrico e Multi-core
Multi
EverRun MX è l’unica
unica soluzione software di fault tolerance che protegge tutte le applicazioni Windows, incluse le applicazioni che richiedono
supporto di multi-processore
processore simmetrico/multi-core
simmetrico/multi
(SMP).
Soluzione Software
EverRun MX Fault Tolerance è una soluzione software, facile da installare ed usare, per aziende che dispongono di limitate risorse IT. Non
richiede modifiche applicative o script da installare e gira su piattaforme hardware x86 standard
standard di mercato.
Protezione Olistica
EverRun
verRun MX Extend protegge tutti i componenti nell’ infrastruttura applicativa, inclusi server, applicazioni Windows, storage e rete. Non
necessita di soluzioni multiple point di disponibilità, per una più facile amministrazione
amministrazione di sistema e un significativo risparmio.
Storage standard di mercato
EverRun MX è completamente indipendente
ente dall’ hardware, consente l uso di soluzioni storage standard (diretto,
(diretto e con o senza SAN, che non
è obbligatoria), abbinando il risparmio economico
economic alla flessibilità di scalare l’ ambiente secondo le necessità.
Singolo ambiente operativo
EverRun
verRun MX mantiene un singolo ambiente operativo per ciascuna istanza protetta di Windows e di applicazioni.
applicazioni Ogni istanza Windows/
applicazione dispone di un unico indirizzo IP, un nome host ed un indirizzo MAC. Questo comporta che utenti, client ed applicazioni non
necessitano mai di riconnessione (o di conoscerli)
conoscerli a nodi alternativi anche quando insorge una Failure.
In Conclusione
Sono finiti i giorni per trasferire applicazioni da macchina a macchina per gestire le configurazioni.
Sono finiti i giorni per fare backup manuali.
Sono finiti i giorni per dover manualmente ricostruire o riallocare Server e Client.
Sono finiti i giorni di spreco di risorse.
La tecnologia esiste ora per aumentare il tempo di attività, facilitare la manutenzione, ridurre la tua “footprint”, tutto con l'aggiunta di funzionalità al vostro livello di controllo dello SCADA.