No results found
di Alessandro Davanzo
In questo tutorial analizzeremo le tre architetture più utilizzate in ambiente Cloud da Software House, System Integrator e Managed Service Provider relative ad altrettante tipologie di ambiente per lavorare nel Cloud. Ci sono infatti tre tipologie di ambiente Cloud:
Poi, eventualmente ci sono versioni wep più complesse (Web Application SaaS - Software As A Service- complessa) come un’infrastruttura basata su Sigma, con la quale si offrono dei servizi tipo i ticket ecc. Poi vedremo come costruire una soluzione di questo tipo.
Ambiente dedicato al cliente
Iniziamo analizzando l’architettura Cloud per lo sviluppo di un ambiente dedicato e per prima cosa elenchiamo quelle che possono essere le necessità del cliente:
Per quanto riguarda la migrazione, il caso tipico è quello in cui abbiamo una macchina fisica e la portiamo nel Cloud virtualizzandola, ma anche quello in cui il cliente ha già un’infrastruttura virtuale che va spostata nel cloud.
I problemi che si pongono in casi del genere sono:
Quanto al Domain Controller, se abbiamo un Domain Controller fisico non lo possiamo virtualizzare, ma per ovviare alla cosa bisogna creare un nuovo Domain Controller e poi unirlo (effettuare la Join) e migrare su quello. Nel caso peggiore, ossia se la macchina oltre a fare da domain controller svolge altri compiti (ad esempio file server) si può creare una macchina che fungerà solo da domain controller e poi fare il mood del vecchio Domain Controller, dopodiché si può effettuare un Physical to Virtual, piuttosto che la migrazione della macchina virtuale di un Domain Controller virtuale.
Questo andrebbe fatto a macchina spenta possibilmente, perché sennò si incorre in un problema di sincronizzazione dei seed, degli orari eccetera, che può generare problemi lato dominio e lato computer; infatti anche proprio le linee guida di Microsoft e di VM Ware suggeriscono che il Domain Controller venga creato da zero e non sia virtualizzato.
Per quanto riguarda l’incidenza della linea, il problema che si può incontrare dalla parte del cliente è quello che è un po' si verifica in ambito di VoIP, soprattutto in Italia, ed è un problema di linea ADSL. Per darvene un’idea, il grafico nell’immagine seguente mostra una situazione di un ufficio con 15 dipendenti, dove tutto, compreso il file server, è esternalizzato nel Cloud, ossia il Server Domain Controller, il centralino eccetera. C'è solo ed esclusivamente il firewall che fa da DHCP (da DNS server).
Come vedete, abbiamo un picco di utilizzo in download di 10,32 megabit al secondo (1,32MBps) ed un picco in upload da 0,35 MBps = 3 Mbps.
Ora questi sono picchi generici di utilizzo della banda, che possono comprendere download di aggiornamenti del computer e download vari, quindi non necessariamente traffico di infrastruttura Cloud ma può trattarsi di traffico del nostro computer, quindi traffico interno.
Andiamo adesso a vedere esempi più pratici, prendendo il caso di un ambiente privato completamente. Con questo tipo di ambiente possiamo andare a esternalizzare tutti server del cliente e renderli disponibili nel Cloud, senza che ne venga compromessa l’integrità.
Per esempio esternalizziamo tutti i servizi, AD, DNS, File Server, Application Server, Server di posta elettronica.
Il tutto in una VLAN Dedicata e protetta da un firewall dedicato al cliente, cui abbiamo pieno accesso.
Nella sede del cliente è sufficiente avere installato un firewall che faccia da VPN site-to-site.
Sul firewall andremo ad impostare il DHCP Server e il Relay dei DNS verso il server in Cloud di AD. Inoltre sono possibili connessioni dall’esterno tramite client VPN. Il firewall può essere uguale a quello che c'è in farm, che abbiamo deployato in farm perché così almeno riusciamo meglio a fare le cose (tipo il Kerio Control) così realizziamo la VPN site-to-site in modo molto veloce.
La situazione è schematizzata nell’immagine seguente.
Quindi installiamo un firewall che abbia la possibilità di fare una VPN site-to-site che abbia la possibilità di gestire DNS, fare il relay DNS, e che gestisca il DHCP.
Cosa succederà, quindi? Accadrà che i PC che sono in azienda tramite la VPN site-to-site accederanno in modo trasparente ai servizi di cui abbiamo spiegato prima, senza dover rifare la configurazione (basta specificare nelle impostazioni DNS del firewall che il dominio è raggiungibile a un determinato IP) quindi problemi zero.
Lo stesso discorso vale per il File Server eccetera. Non bisogna fare alcunché, a meno che non ci siano delle mappature fatte via IP invece che via Host, quindi andranno ritoccate, cambiando la LAN interna e invertendo le reti, oppure no.
Quindi abbiamo la possibilità, se siamo fuori sede, di collegarci tramite VPN client al firewall installato a protezione dei servizi cloud, in completa mobilità da portatile.
Un altro caso che esaminiamo è quello di un’azienda presso la cui sede c’è qualche problema di linea, la quale non è molto performante, però bisogna ugualmente lavorare con file grafici o CAD e comunque pesanti; in questo caso mettere tali file sul Cloud può costituire un problema.
In questo caso la soluzione consiste nell’esternalizzare buona parte del sistema, creando così una situazione ibrida.
Nell’esempio proposto dalla figura seguente, lasciamo il File Server presso il cliente ma l’autenticazione con Active Directory la facciamo in Cloud; in questo modo i file restano localmente e vi si può accedere con rapidità.
L’immagine mostra a sinistra la parte Cloud con i server virtualizzati ecc. accessibile passando da firewall dedicato. Il tutto si trova in una VLAN dedicata (VPN) non accessibile da nessun altro e gestita da noi tramite il firewall, che separa la parte che sta nella sede del cliente.
In questa soluzione, che consideriamo ibrida, nel nostro Cloud andiamo a creare un firewall dedicato, andiamo a mettere server di posta, Active Directory, Application Server, desktop remoto e poi presso il cliente manteniamo il File Server, che può essere anche un NAS dove ci si autentica su Active Directory e localmente si accede sempre tramite VPN.
Dunque, per i servizi accediamo al server che si trova su cloud e per quello che riguarda i file, accediamo da rete locale al nostro server sul posto.
Considerate che per l'autenticazione Active Directory servono veramente pochi kilobyte/s. e lo stesso vale per il desktop remoto; l'unico problema che ci potrebbe essere è quello del File Server, se disponiamo di Fastweb in fibra ottica o di linee a 10 megabit.
L’immagine seguente mostra la configurazione del firewall in Stellar, del sistema proposto.
Vediamo i vantaggi di questa architettura:
In tema di costi passiamo, ad analizzare quelli di una soluzione Cloud, prendendo come esempio un'infrastruttura Full Cloud composta da 4 server con firewall dedicato:
Vediamo adesso un altro caso applicativo, ossia quello dei Cloud Provider e Managed Service Proveder. In questo caso gestite da voi i vostri server e offrite direttamente i servizi al vostro cliente, intendendo con servizi Mail, hosting, monitoring ecc. Il tutto dietro ad un vostro firewall dedicato.
A differenza del caso di prima con infrastruttura dedicata al cliente, qui si tratta di offrire servizi come caselle di posta ecc. Servizi non richiesti ma offerti.
La figura seguente propone una serie di server virtualizzati sul Cloud di Stellar che forniscono servizi come Web Server, caselle di posta elettronica (e-mail) gestione patch, monitoring ecc. accessibili dietro a un firewall dedicato del provider. Tramite l'impostazione di alcune regole, è possibile dare ai vari clienti l'accesso ad uno o più servizi.
La figura seguente mostra alcune regole del firewall che consentono l'accesso dall'esterno al Cloud di Stellar e che nel caso specifico riguardano la configurazione di un Web Server virtualizzato.
Notiamo nella sona a destra l'elenco di tutti i servizi e protocolli implementati, come FTP, FTPS, HTTP, HTTPS, SSH ecc., nonché le porte di amministrazione (TCP8443 ecc.) e le regole in uscita (la spunta su Allow indica che tutto quel che viene elencato è permesso.
Nella parte in basso della figura notate le porte aperte per il server di posta elettronica, che in questo caso è Kerio Connect Service.
Da Sigma è possibile gestire l'intera struttura Cloud, come mostra l'immagine seguente, dove troviamo tutti i server che abbiamo implementato su Cloud, ciascuno con le proprie caratteristiche: per esempio il sistema operativo installato, lo stato (attivo o disattivo), le istanze corrispondenti, i relativi cluster su disco, e i nomi host di ciascun server.
Vediamo anche se è previsto e c'è un backup della macchina Virtuale (icona a forma di cassetta a nastro) eseguito, in questo caso, con 1 Backup: la spia rossa indica che c'è stato un errore o che non è stato ancora eseguito, verde che è stato eseguito con successo e arancione che non è ancora stato effettuato il primo dei backup schedulati.
Altre informazioni riportate nella finestra riportata in figura sono la presenza di eventuali snapshot, il numero di CPU utilizzate dal server virtuale, quanta RAM gli è riservata e quanto spazio su disco utilizza ecc.
Ma che cosa potrebbe spingere un provider di servizi a ricorrere all'implementazione su su Cloud come quella schematizzata e realizzata con Stellar? Ebbene, tra i principali abbiamo:
La soluzione, peraltro, porta questi vantaggi:
Impone anche qualche limitazione, ossia:
Sul piano dei costi della soluzione Cloud Stellar va detto che:
Andiamo adesso a vedere l'ultimo caso applicativo, ossia all'ambiente Cloud utilizzato per implementare applicazioni remotizzate.
Partiamo dalle Remote App, che permettono di offrire ai vostri cliente l’accesso in RDP o via WEB ad applicazioni specifiche, come ad esempio un gestionale. Potete così offrire ai vostri clienti un servizio di applicazioni condiviso tra tutti ma non per questo meno sicuro. Il caso d'uso è schematizzato nell'immagine seguente.
In questo caso su Cloud abbiamo un Domain Controller (AD Server) per gestire le applicazioni, uno o più server SQL per gestire i database, un gateway e Web Server per gestire gli accessi alle applicazioni e i server per le applicazioni, che saranno in numero variabile. Proprio i server dedicati alle applicazioni (gli Application Server) potranno essere condivisi, utilizzati in modalità load-balancing, oppure riservati a uno specifico cliente.
Quindi se abbiamo un cliente che necessita dell'accesso esclusivo ad un'applicazione, basta deployare un Application Server su Cloud ad esso riservato.
Con questa soluzione possiamo a creare un ambiente flessibile che possa crescere in base alle esigenze, ovvero possiamo partire da un server singolo e andare a creare un ambiente più grande aggiungendo in pochi passaggi altri application server, grazie all’utilizzo di Microsoft Terminal Service distribuito o con altre soluzioni quali TerminalService Plus, possiamo creare un unico punto di accesso ai nostri application server e averne diversi ad un load balancer avendo così la possibilità di scalare in caso di necessità.
Nella figura seguente proponiamo una soluzione dove possiamo vedere:
In questa configurazione abbiamo la possibilità di utilizzare RDP classico o interfaccia WEB in html5 in base a cosa utilizziamo.
Vediamo dunque come si presenta ad esempio una struttura di questo tipo realizzata con Remote Desktop di Microsoft, guardando la figura seguente.
In questa struttura vediamo i relativi componenti, che possono essere installati ciascuno su macchine diverse, ovvero trovarsi sulla stessa macchina; i componenti che vediamo nell'immagine sono:
Possono comunque essercene di ulteriori. Con una situazione di questo tipo, come vediamo nella figura seguente (che ci mostra l'impostazione delle regole del caso), apriamo la porta HTTP e HTTPS solo verso il GateWay. Che poi tramite Connection Broker penserà a smistare le connessioni, e tutto il traffico passerà sempre dal nostro Gateway.
La stessa cosa può essere fatta con TerminalService Plus (Tsplus). In questo caso avremo bisogno di una licenza TSplus da usare come Gateway; e poi di “N” Licenze di TSPLUS da installare sui vari Application Server in base agli utenti che andiamo a implementare. Anche qui avremo un unico punto di accesso (Gateway) che smisterà le richieste ai vari server (vedere l'immagine seguente).
La figura che segue mostra la finestra di dialogo nella quale, in Remote Desktop, si aggiungono, modificano o rimuovono server dal Gateway Portal.
Anche nel caso in esempio (Remote App) possiamo centralizzare tutta la gestione mediante un FARM Controller, da cui vedere e gestire tutte le sessioni attive sui vari host e gestire le impostazioni in modo centralizzato (immagine seguente). Inoltre con questo sistema possiamo anche configurare i server in modalità loadbalancing quindi sarà TS plus a gestire il carico dei server, o assegnare ad un utente un server specifico.
Anche in questo modo, come per RDP visto prima possiamo abilitare l’accesso solo al server Gateway senza aprire direttamente connessioni verso i vari server.
L'immagine seguente mostra la gestione mediante TS Plus (Terminal Service Plus).
Tra le applicazioni remotizzabili con Stellar abbiamo gestionali su server Cloud come Danea Easyfatt Enterprise, Team System, Microsoft Dynamics NAV e MAGO con Microarea.
Parliamo adesso di costi di soluzioni del genere remotizzate: partiamo con un singolo server con Shared Firewall (adatto a contesti fino a 20 utenti) e vediamo per esempio il costo per Server con dimensionamento per 3-5 utenti RDP, ossia un Server Gestionale – 4 VCPU, 4GB ram, 40GB OS + 40 GB dati (velocità disco 66Mb), SQL web, che è intorno a 153€ mese. A questo costo va aggiunta la licenza Microsoft RDP circa 5 euro/mese.
Invece con 2 Server con Firewall (adatto a contesti fino a 20 utenti) e utilizzo di Dynamics Navision, supponendo questa configurazione:
In questo caso il costo totale mensile si aggira sui 370€.
Vediamo infine un esempio con 3 Server con Firewall (adatto a contesti superiore ai 20 utenti):
Con questa configurazione raggiungiamo un costo totale di 343€ al mese con inclusa la licenza di SQL Web edition. La licenza di TerminalService Plus va conteggiata a parte.
L'ultima soluzione di cui dobbiamo parlare è quella di fornire con Stellar applicazioni web come ad esempio Sigma e andare a creare degli ambienti web complessi con bilanciatori di carico e più Web Server.
In pratica si tratta di fornire servizi SaaS (Software as a Service) e poi eventualmente versioni web un po' più complesse tipo quello che potrebbe essere infrastruttura di Sigma con la quale si offrono dei servizi tipo i ticket.
Nell’esempio riportato nella figura seguente abbiamo un Load Balancer (che può essere Nginx o HAProxy) per il Front-End, con due o più web server (Apache o Tomcat) a cui smistare le richieste, uno o più server di BackEnd, Database Cluster (mySQL Galera) composto da quattro server e un server di session caching (come Redis) per le sessioni in modo che la nostra connessione possa passare da un server web all’altro senza perdere la sessione e dover rieseguire la login.
Andando più nel dettaglio, possiamo avere 2 LB o con Haproxy o con Nginx. Su entrambi andiamo ad installare Keepalived in modo da avere un IP «virtuale» che sarà il nostro IP di accesso al sistema e poi due IP privati assegnati ai due server, e grazie a Keepalived se uno dei due server non è disponibile l’IP «virtuale» verrà spostato sull’altro server (vedere l'immagine seguente).
Mentre per MySQL possiamo andare a creare un cluster con GALERA, e per fare LB anche qui come per i webserver, dobbiamo avere 2 server HAPROXY con KEEPALIVED installato e avremo una situazione tipo quella descritta nell'immagine seguente.
Come possiamo vedere, la nostra applicazione farà la richiesta all’indirizzo IP «virtuale» di Keepalived che farà andare la richiesta sul HAProxy attivo, che smista le richieste ai vari nodi SQL che sono in cluster con Galera.
