Become a partner   | Request Support  | Contact Sales

KNOWLEDGE BASE

Knowledge Base
1Backup
Acronis
Antivirus
Email
Firewall
GFI Software
Mail
Monitoring
N-Able
Sicurezza
TSPlus
Diventa Autore per CoreTech | Scopri di più

Vai al Video

Stellar - Le 3 architetture più utilizzate in ambiente Cloud da software house, system integrator e MSP

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:

  • un ambiente dedicato (privato) al cliente;
  • uno per Cloud Provider e Managed Service Provider;
  • uno per applicazioni remotizzate (quindi fornite tramite desktop remoto, RPD ecc.), servizi SaaS.

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:

  • disporre di un ambiente dedicato e privato, non condiviso;
  • avere la possibilità di effettuare una migrazione trasparente P2V – V2V (Physical to Virtual – Virtual to Virtual);
  • avere la massima personalizzazione dei server e delle risorse (RAM, spazio su disco ecc.).

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:

  • è meglio installare da zero il Domain Controller rispetto a effettuare una conversione?
  • quanto incidono i problemi di linea?

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.

Ambiente dedicato al cliente Full Cloud

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.

Ambiente dedicato al cliente Hybrid Cloud

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à.

Banner

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:

  • affidabilità;
  • accessibilità everywere;
  • continuità di rete grazie alla VPN site-to-site;
  • nessuna manutenzione hardware richiesta;
  • non ci sono costi hardware e software da ammortizzare, perché i costi del servizio cloud sono certi e scalabili in base alle esigenze.

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:

  • Firewall dedicato Kerio 1vcpu 4gb ram -> 52€ mese
  • Server AD – 1vcpu, 2gb ram , 40GB os velocità disco 35mb -> 66€ mese
  • File Server – 2 vcpu, 4GB ram , 40GB os + 100 GB dati velocità disco 66Mb -> 150€ mese
  • Server Gestionale - 4 VCPU, 4GB ram, 40GB os + 40 GB dati velocità disco 66Mb, SQL web -> 153€ mese
  • In tutto, il costo ammonta a 421 euro/mese, che rappresentano una soluzione accettabile.

Cloud Provider e Managed Service Provider

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. 

Banner

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.

Banner

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:

  • massima offerta di servizi hosting gestiti;
  • nessuna esigenza di VPN;
  • costi ridotti e spalmati sui clienti.

La soluzione, peraltro, porta questi vantaggi:

  • gestione completa dei servizi dei vostri clienti, posta, web ecc.;
  • unica gestione dei vari servizi, a condizione che i servizi stessi siano sparsi sui vari provider.

Impone anche qualche limitazione, ossia:

  • un solo firewall per tutto l’ambiente;
  • possibilità limitate di fare VPN, ossia si può realizzare una VPN ma impone una più elevata mole di lavoro da parte vostra in termini di creazione delle regole;
  • regole troppo specifiche o numerose per singolo servizio.

Sul piano dei costi della soluzione Cloud Stellar va detto che:

  • tutti i costi vengono ripartiti sul servizio che offrite al vostro cliente;
  • i costi dipendono dai servizi che si desidera erogare con propri server: ad esempio utilizzando un solo server per offrire il servizio di posta elettronica, il costo potrebbe partire da 50-60 euro al mese.

Ambiente per applicazioni remotizzate

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:

  1. server di autenticazione (ActiveDirectory);
  2. SQL server per la base dati;
  3. Gateway Server / Connection Broker / Load Balancing;
  4. Application Server.

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:

  • accesso al Web;
  • Gateway;
  • Servizio di licenze (installato sul Domain Controller);
  • Connection Broker (il gestore di connessione);
  • Host Sessioni Desktop Remoto (2 server).

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).

Stellar: i gestionali supportati

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:

  • Server Gestionale su hardware composto da 2 VCPU, 8GB ram, 40GB OS + 60 GB dati (velocità disco 66Mb);
  • Server web per accesso a Navision con 1 VCPU, 8GB RAM e 40 GB OS.

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):

  • Server Gestionale (SQL) – 2 VCPU, 4GB ram, 40GB OS + 20 GB dati (velocità disco 66Mb);
  • Server AD – 1 VCPU, 2GB RAM, 40 gb OS + 20GB dati (33mbps di velocità disco);
  • Application Server (RDP) – 2 VCPU, 8GB ram, 40GB OS + 40GB dati (velocità disco 66Mb).

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.

Web Application per servizi SaaS

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.