OpenStack – Introduzione

OpenStack Cloud Software

OPENSTACK – PARTE PRIMA

Si parla molto di OpenStack e delle sue applicazioni. Ma che cos’è davvero, perché è stato sviluppato e quali sono i suoi vantaggi?

Che cos’è?
OpenStack è un sistema operativo per il cloud computing in grado di controllare componenti di storage, networking e computing. È open source e gratuito, di solito è installato sotto forma di soluzione IaaS. OpenStack fornisce un insieme di strumenti che servono a costruire e gestire piattaforme cloud sia pubbliche sia private. Permette agli utenti di installare macchine virtuali e si può accedere al codice sorgente per modificarlo in qualsiasi modo sia utile per gli scopi specifici del progetto.

Chi lo ha sviluppato?
Nel 2010 Rackspace e la NASA hanno collaborato a un progetto congiunto che è poi diventato OpenStack. Il codice iniziale è stato usato per Nebula, la piattaforma cloud della NASA, poi il progetto si è dato l’obiettivo più ampio di aiutare le aziende a far girare software cloud su hardware standard.

Chi lo usa?
Tra i vendor, alcuni dei nomi più importanti che attualmente supportano e distribuiscono OpenStack sono Canonical, Cisco, EMC, HP, Huawei, IBM, Oracle, Google e Red Hat. Tra gli utenti attuali ci sono Bloomberg, Comcast, PayPal e Wells Fargo. Ci sono incontri internazionali periodici su OpenStack – gli OpenStack Summit – in tutto il mondo, che raccolgono programmatori e utenti della piattaforma.

E’ quindi ormai innegabile l’interesse che tutto il mondo IT ha riservato in questi ultimi anni ad OpenStack.

Qual’è la ragione di tutto questo?

L’ormai tradizionale paradigma client-server, in progetti in cui la scalabilità e le finestre di picchi di carico sono variabili essenziali all’interno dell’equazione della produttività, presenta oggi giorno evidenti limiti di gestione dei carichi e della velocita’ di evoluzione dei progetti. Ecco quindi nascere l’esigenza di uno strumento che fosse flessibile ed allo stesso momento affidabile.

Questo concetto spiega quindi le motivazioni che possono spingere ad adottare una piattaforma cloud, ma perché fra tutte le piattaforme esistenti si parla sempre di OpenStack?

OpenStack è un progetto aperto
La sua natura aperta ha fatto sì che tutti i vendor interessati all’introduzione di specifiche funzionalità o determinati ambiti potessero contribuire in maniera attiva e funzionale al progetto, innescando un circolo virtuoso in cui ogni miglioramento apportato per favorire se stessi va a beneficio della comunità.

La sua natura aperta fa sì che chi adotta OpenStack per il proprio ambiente cloud è di fatto esente dal cosiddetto vendor lock-in, ossia l’essere vincolato ad un rivenditore specifico per le proprie tecnologie. Infatti se lo standard OpenStack è garantito, ogni venditore potrà essere valutato in modo paritetico a tutti gli altri, rendendo così il mercato più competitivo e conveniente per il cliente finale.

I presupposti di un progetto OpenStack

Bisogna subito tenere presente che “non tutti i progetti sono adatti al cloud“, nonostante cio che viene erroneamente interpretato leggendo in giro per il web, infatti questo principio sfugge a molti che guardano verso le nuvole vedono unicamente un posto differente da cui erogare i propri servizi. Esistono dei requisiti da tenere presente per capire se un progetto è adatto al cloud.

Un progetto OpenStack quindi deve essere:

** Non persistente: non deve basarsi sulla persistenza dei dati all’interno delle macchine coinvolte. Questo aspetto non va confuso con l’esigenza di avere uno storage solido e sicuro, si tratta invece di non giudicare le istanze che concorrono al progetto come perenni, ma come componenti utili al loro scopo e liberamente sacrificabili;

** Scalabile: deve supportare applicazioni che nativamente siano in grado di scalare. L’applicazione nasce già dallo sviluppo come pensata per il cloud;

** Dinamico: a fronte di un innalzamento delle richieste ricevute il progetto deve essere in grado in maniera autonoma di gestire le nuove componenti. Gli interventi manuali successivi all’implementazione sulle istanze coinvolte devono essere inesistenti;

** Rapido: deve essere passibile di provisioning, favorendo la velocità di creazione (e distruzione) di nuove istanze;

Se il vostro progetto risponde a questi requisiti messi in evidenza qui sopra, allora potete pensare ad integrare OpenStack ed è giunto quindi il momento di capire in cosa consiste.

Le componenti di OpenStack

La parola stack descrive un insieme di entità che concorrono ad uno scopo comune. OpenStack è composto da numerose elementi che devono comunicare fra loro, lo strato di comunicazione passa attraverso due filoni fondamentali: la memorizzazione delle informazioni e la coda delle azioni da svolgere. Queste due azioni sono coperte ciascuna da un elemento specifico:

MySQL

Il database MySQL è necessario per la memorizzazione delle informazioni di configurazione generali del sistema, per la memorizzazione delle informazioni di autenticazione relative a ciascun componente e per il mantenimento dinamico dello stato del sistema.
Ogni azione eseguita all’interno dell’infrastruttura OpenStack è tracciata all’interno del database. L’importanza di questa componente è evidentemente capitale.

RabbitMQ

RabbitMQ è uno scheduler, un software didicato alla gestione delle code ed all’organizzazione delle sequenze di operazioni. Tutti i nodi facenti parte dell’infrastruttura OpenStack comunicano con lo scheduler, ed anche in questo caso è presto spiegato come questa componente ricopra enorme importanza per il regolare funzionamento dell’ambiente.

Determinato quindi il sistema di circolazione e reperimento delle informazioni si può focalizzare l’attenzione sugli elementi peculiari di OpenStack, riassunti in questo diagramma che si trova sul sito ufficiale del progetto:

OpenStack Diagramma Software

                                                     OpenStack Diagramma Software

Keystone

Keystone è il software che gestisce il sistema di autenticazione di OpenStack. Il principio su cui si fonda è quello classico degli utenti e dei gruppi, ma di fatto si occupa di gestire le tre tipologie di utenti configurabili in OpenStack:

  • Cloud Provider Admins: ossia gli amministratori del sistema OpenStack;
  • Tenants: ossia i profili delle compagnie fruitrici dei servizi;
  • Users: ossia gli utenti delle compagnie fruitrici dei servizi;

Il concetto di “compagnia” si riferisce ad un sotto-ambiente interno alla stessa installazione di OpenStack. Applicato ad un provider esso potrebbe essere rappresentato dai clienti, mentre all’interno di un cloud privato potrebbe essere associato ad un dipartimento interno.

Glance

Glance si occupa del provisioning (ossia di fornire) delle immagini all’interno dell’ambiente. Questa componente fornisce un bacino di istanze gia preconfigurate, disponibili ai fruitori dei servizi, per effettuare il deploy (ossia la messa in produzione) dell’istanza desiderata all’interno del proprio ambiente.
Le immagini sono supportate nei formati KVM qcow, Aws, VMWare purché esista su queste un Master Boot Record.

Nova

Nova è il compute service, un servizio che permette di gestire i sistemi virtuali erogati all’interno dell’ambiente. All’interno della macchina definita controller il servizio nova-api guiderà l’avvio e la terminazione delle istanze comandando la sua controparte nova-compute, attiva su tutte le macchine hypervisor facenti parte della struttura OpenStack.
Le decisioni su dove e come le istanze dovranno essere avviata saranno gestite dal servizio nova-compute-service (basato su libvirt).

Horizon

Horizon è l’interfaccia web dalla quale è possibile controllare agevolmente le istanze in modalità point-and-click oltre che le immagini gestite da Glance. Il software Horizon è basato sul modulo wsgi del webserver Apache.

C’è ancora un’ultimo aspetto da tenere presente, come è deducibile dallo schema, lo storage.
In un setup base le macchine possono essere erogate direttamente dai dischi degli hypervisor, ma in ambienti di larga scala ciò potrebbe non essere auspicabile. In questi casi fare riferimento ad un gestore dello spazio centralizzato permetterebbe di utilizzare gli hypervisor come semplici erogatori, valorizzando la scalabilità generale del progetto, ed ecco dunque venirci in aiuto questo componente per la gestione dei volumi, Cinder.

Cinder

In origine parte del progetto Nova (chiamato nova-volume) e dal 2012 progetto a se stante, Cinder è il servizio che fornisce il block storage per le istanze, uno storage gestito e centralizzato che funziona da dispositivo a blocchi per le virtual machines. Le macchine virtuali risiedono quindi su un device dedicato, definito sulla base di quello che è la modalità con cui l’hypervisor ha accesso allo storage.
Cinder supporta diverse modalità per essere visto dagli hypervisors: è possibile infatti utilizzare dischi locali o sistemi storage esterni, quali NFS, FibreChannel, DRBD o iSCSI.

Swift

A differenza di Cinder, Swift è un servizio di storage online che si occupa di rendere disponibile spazio all’interno dell’ambiente OpenStack mediante la modalità object storage. I dati non vengono registrati direttamente su dispositivi a blocchi, ma preventivamente convertiti in oggetti binari, distribuiti all’interno di più device in modo da garantirne la massima accessibilità oltre che la replica.
Swift è compatibile con il servizio di storage Amazon S3 e funziona con lo stesso principio: fornire uno storage web accessibile e scalabile.

Conclusioni

In questa lunga introduzione sono stati illustrati filosofia, componenti e soprattutto potenzialità di OpenStack, ma sebbene la lettura possa essere apparsa lunga, questa tocca appena la superficie dell’universo relativo a questo grande progetto.
Nel prossimo articolo verrà avviato un piccolo studio di fattibilità vero e proprio con lo scopo di mettere su strada tutti i vari software che lo compongono ed iniziare cosi ad adoperare OpenStack.

Breve corso di Vagrant – Puntata 1

Vagrant Stack-LAMP

Vagrant Stack-LAMP

Dopo aver gia scritto in precedenti articoli di Vagrant ho sentito l’esigenza di metter, come si suol dire, nero su bianco un piccolo corso/progetto da portare avanti su queste pagine in cui verra’ spiegato non solo l’uso piu’ avanzato di Vagrant ma anche alcuni concetti fondamentali inerenti la creazione di un servizio WEB moderno, introducendo i concetti di “scalabilita’” e di “high availability“.

Iniziamo con un breve elenco dei comandi di vagrant usati più comunemente :
vagrant init [nome-box] [url-box] = inizializza la directory corrente come ambiente per Vagrant e crea il file di configurazione Vagrantfile
vagrant up = crea, configura e avvia la macchina virtuale definita in Vagrantfile . Se la macchina virtuale già esiste, la fa solo partire
vagrant halt <nome macchina> = ferma una macchina virtuale
vagrant destroy = elimina la macchina virtuale
vagrant ssh <nome macchina> = si collega alla macchina virtuale via ssh

Nel seguente esempio verra’ creata una directory che conterra’ il progetto di Vagrant, poi, inizializzemo il progetto, configureremo una macchina virtuale, la lanceremo e infine ci collegheròemo. I seguenti comandi creeranno una macchina virtuale con Ubuntu 14.04 (64bit). Notate che la prima volta che eseguirete questa serie di comandi, verrà scaricata dalla rete un’immagine del sistema operativo Ubuntu. Per farlo ci potranno volere svariati minuti, a seconda anche del tipo di connessione ADSL di cui disponete. Le volte successive, il processo sara’ molto più rapido, perché l’immagine usata per creare la macchina virtuale sarà già stata memorizzata nel vostro sistema.

PARTIAMO
Questi sono i primi comandi che useremo: vagrant init ubuntu/trusty64  &  vagrant up

<> vagrant init ubuntu/trusty64
A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`vagrantup.com` for more information on using Vagrant.

<> vagrant up
Bringing machine ‘default’ up with ‘virtualbox’ provider…
==> default: Box ‘ubuntu/trusty64’ could not be found. Attempting to find and install…
default: Box Provider: virtualbox
default: Box Version: >= 0
==> default: Loading metadata for box ‘ubuntu/trusty64’
default: URL: https://atlas.hashicorp.com/ubuntu/trusty64
==> default: Adding box ‘ubuntu/trusty64’ (v20151214.0.0) for provider: virtualbox
default: Downloading: https://atlas.hashicorp.com/ubuntu/boxes/trusty64/versions/20151214.0.0/providers/virtualbox.box
default: Progress: 6% (Rate: 115k/s, Estimated time remaining: 0:43:23)))
==> default: Preparing network interfaces based on configuration…
default: Adapter 1: nat
==> default: Forwarding ports…
default: 22 => 2222 (adapter 1)
==> default: Booting VM…
==> default: Waiting for machine to boot. This may take a few minutes…
default: SSH address: 127.0.0.1:2222
default: SSH username: vagrant
default: SSH auth method: private key
…………..etc etc !!

> vagrant ssh
Welcome to Ubuntu 14.04.3 LTS (GNU/Linux 3.13.0-73-generic x86_64)

* Documentation: https://help.ubuntu.com/

System information disabled due to load higher than 1.0

Get cloud support with Ubuntu Advantage Cloud Guest:
http://www.ubuntu.com/business/services/cloud

vagrant@vagrant-ubuntu-trusty-64:~$ ifconfig
eth0 Link encap:Ethernet HWaddr 08:00:27:6b:55:0f
inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fe6b:550f/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:544 errors:0 dropped:0 overruns:0 frame:0
TX packets:392 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:69053 (69.0 KB) TX bytes:53324 (53.3 KB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

vagrant@vagrant-ubuntu-trusty-64:~$ exit

Dato che il nostro obiettivo è arrivare ad avere uno Stack LAMP, sappiamo che dovremo tenere conto di dover ancora installare e configurare gli altri software necessari ossia,  Apache, MySQL e PHP. Ci sono però anche altri componenti meno ovvi di cui va tenuto conto. Iniziamo studiando lo stack LAMP su di un modello di web application 2.0. Vediamo quindi di spiegare alcuni concetti fondamentali per questo tipo di architetture che vanno decisi prima d’iniziare a creare fisicamente le macchine/server che ci servono.

Scalabilità VS Disponibilità

Scalabilità verticale
Si può scalare un sistema senza aumentarne la disponibilità o il tempo di uptime. Esemplifichiamo, diciamo che vogliate gestire più utenti, più traffico e più carico per l’applicazione web, se si tratta di un server fisico, potreste spegnerlo, installare più memoria e potenziare la CPU, ad esempio. Potreste anche copiare tutti i dati da un solo piccolo server ad un server più grande che abbia più memoria, una CPU più potente e dischi più veloci. Se invece state usando un server virtuale, potreste fermarlo, allocare maggiori risorse e riavviarlo. Se il server è posizionato nel cloud, potrete cambiare il tipo di istanza ad uno che abbia più risorse. Questo si chiama scalare verticalmente. Non c’è niente di male in questo tipo di scalabilità, soprattutto se avete applicazioni in cui il tempo di fermo e’ accettabile.

Scalabilità orizzontale
Un’ altro modo per scalare è di aggiungere altri server, che a volte vengono indicati con il termine di nodi. Questo si chiama scalabilità orizzontale. Per scalare orizzontalmente, si deve fare prima un po’ di lavoro in anticipo, e progettare bene la transizione. Per andare ad esempio da un server web a due, dovrete trovare un modo per instradare il traffico al nodo aggiuntivo, e preferibilmente suddividere il carico tra i due server. Se vi servono più risorse, aggiungete un terzo server,  un quarto, un quinto e cosi’ via. Quando invece avete un solo server, e questo va giù, il servizio si interrompe, ma se avete più di un server che fanno gestiscono la stessa funzione, e uno di loro ha un malfunzionamento, lo scenario peggiore è che il servizio è degradato e non altrettanto prestante come di solito. Lo scenario migliore avviene quando un singolo malfunzionamento non viene nemmeno notato.

Il meglio di entrambi i mondi
In molti casi ha senso scalare il server web in modo orizzontale, e il server di database in modo verticale. Vedremo piu’ avanti, nei prossimi articoli, come prendere il meglio di entrambi i mondi, eliminando, o almeno riducendo moltissimo, il tempo di fermo per il servizio.

Nel secondo capitolo inizieremo la configurazione del file Vagrant per la preparazione delle 5 macchine necessarie al nostro progetto.

Stay Tuned !

Le novita’ di Debian 8

Debian 8 Jessie

Debian 8 Jessie

Il 25 aprile 2015 è stato annunciato il rilascio di Debian 8 (alias Jessie), che e’ l’ultima versione di uno dei più noti ed apprezzati sistemi operativi basati su Linux. Questo rilascio, atteso da moltissimi utenti e da altrettante aziende, porta con sè alcune novità significative, frutto di un lavoro di sviluppo durato circa due anni, e culminato in un sistema operativo che sarà supportato fino al 2020.

In questo articolo vedremo le principali novità introdotte su Debian 8, di cui è possibile effettuare il download direttamente dal sito ufficiale del progetto.

Una distribuzione universale
Debian, ad oggi vanta una vasta gamma di pacchetti software (circa 43 mila), che consentono a chiunque di personalizzarla a proprio piacimento, in base al tipo di applicazione per cui questo sistema sarà utilizzato: dai server alle workstation, passando per il cloud, i mainframe o le board che implentano l’Internet of Things.

L’idea della distribuzione universale, adatta a tanti contesti, ha spinto negli anni la comunità open source a creare un gran numero di derivate (ed il caso più noto risponde al nome di Ubuntu). Il fatto che molti sistemi Linux si basino su Debian aumenta quindi l’importanza di ogni aggiornamento apportato a questa distribuzione in ogni rilascio, dal momento che ciò si ripercuote su tutte le sue derivate (ufficiali e non).

Il passaggio a systemd
La novità più significativa, che ha creato molti dibattiti accesi, introdotta con Debian 8, riguarda il passaggio definitivo a systemd quale sistema di init principale, sebbene sia possibile utilizzare sysvinit come alternativa. Tale scelta trova le sue motivazioni nella riduzione dei tempi di avvio ed arresto del sistema, sebbene non tutti gli utenti sembrano convinti di ciò. Inoltre, systemd non si occupa solo della fase di boot: in quanto gestore di sistema, esso incorpora anche la gestione di diverse altre funzioni (alimentazione, dispositivi, login, eccetera), con conseguenze che potrebbero comportare, ad esempio, la necessità di riavviare il sistema in caso di aggiornamento. Un problema significativo per una distribuzione server, dovuto proprio a systemd. Il problema piu’ grande sorge per via del fatto che oggettivamente, l’attuale sistema usato, SysVInit, è oggettivamente un sistema antiquato, con un elenco di noti difetti, il principale dei quali è sicuramente la grande lentezza derivante dall’approccio seriale all’avvio dei servizi. L’idea di sostituirlo con un prodotto più moderno e meglio ingegnerizzato è, quindi, tutt’altro che sbagliata.

Il problema reale è che systemd sta andando ben oltre questo encomiabile tentativo, ma sta fagocitando al suo interno tutta una serie di servizi che con la gestione dei processi e la creazione dello ‘spazio utente’ poco hanno a che fare. Approccio, questo, che viola radicalmente le logiche della filosofia Unix, che sono alla base non solo dei Linux che usiamo oggi, ma in larga parte di quella che è l’informatica moderna.

Va detto, però, che il passaggio a systemd era già in atto da tempo, e non soltanto sulle distribuzioni basate su Debian: anche Red Hat, Fedora e SUSE (per citare alcune grandi distribuzioni Linux) sono già passate a questo nuovo gestore.

Desktop e applicazioni
Dal punto di vista dell’interfaccia utente, il grande grado di personalizzazione offerto da Debian si traduce nella possibilità di scegliere il proprio desktop environment preferito tra un gran numero di possibilità. L’ultimo rilascio è infatti compatibile con GNOME 3.14, KDE Plasma 4.11.13, Xfce 4.10, MATE 1.8 e Cinnamon 2.2.16.

Ai sopra citati desktop environment si aggiungono anche diverse applicazioni, tra cui Iceweasel 31.6, GIMP 2.8.14 e LibreOffice 4.3.3 per la sfera desktop, Apache 2.4.10, Tomcat 7.0.56 e 8.0.14, MariaDB 10.0.16 e MySQL 5.5.42 per quella server, nonchè OpenJDK 7u75, PHP 5.6.7 e Python 2.7.9 e 3.4.2 per gli sviluppatori.

Altre novità
Per concludere ricordiamo che Debian 8 è basato sul kernel Linux 3.16.7, che garantisce la compatibilità con le più recenti tecnologie disponibili. È altresì interessante notare che, con il nuovo rilascio, viene garantito il supporto a ben dieci architetture diverse, tra cui x86, PowerPC, MIPS, ARM e diverse altre.

 

#DebianottoJessie

Cisco Academy nuovo corso NDG Linux Essentials

Back to School Cisco Academy

Back to School Cisco Academy

Oggi vi segnalo il nuovo corso “NDG Linux Essentials” realizzato dal Programma Cisco Networking Academy e proposto da Linux Professional Institute (LPI).

NDG Linux Essentials
Un nuovo percorso formativo arricchisce il Programma Cisco Networking Academy, promosso dall’azienda in tutto il mondo per consentire di acquisire le competenze professionali ICT più richieste nel mercato del lavoro: si tratta di NDG Linux Essentials, dedicato alla conoscenza dei principi fondamentali del sistema operativo Linux.
Il corso NDG Linux Essentials è stato ideato dal gruppo di sviluppo della NDG (Network Development Group), è conforme alle linee guida proposte da Linux Professional Institute (LPI) ed insegna i fondamenti di un sistema la cui adozione è in costante crescita, generando una importante domanda di personale qualificato.

Il corso NDG Linux Essentials è disponibile in tutto il mondo sulla piattaforma Cisco NetSpace Learning, dedicata ai corsi del programma Cisco Networking Academy, ed è erogato secondo l’approccio pratico tipico del programma: si offre una piattaforma operativa che consente agli studenti una continua interazione con il materiale formativo a loro disposizione, aumentando il loro coinvolgimento e le loro conoscenze.

Il Cisco NetSpace Learning è una piattaforma cloud e questo costituisce un ulteriore valore aggiunto, perché l’integrazione al suo interno di un vero ambiente di laboratorio Linux consentirà a università, scuole, enti formativi di inserire l’istruzione open source nella propria offerta senza dovere sviluppare in proprio una struttura dedicata.

Per maggiori informazioni consultare la sezione dedicata a NDG Linux Essentials dal portale Cisco.

 

#CiscoAcademyCorsoLinuxEssentials

Server Virtuali – Quali scegliere

VPS Cloud Hosting

VPS Cloud Hosting

Quali sono le migliori offerte per un VPS ?

Cercando sul Web la parola chiave “VPS” (Virtual Private Server) compaiono decine di offerte, tutte piu’ o meno interessanti, ma come trovare quelle piu’ adatta alle nostre esigenze ?
Un server virtuale e’ fondamentalmente un computer che viene messo a nostra disposizione per installarci la nostra distribuzione Linux preferita ed ogni altro pacchetto (web o db o altro..) che possa servire ai nostri scopi ma, con la differenza che, la manutenzione non spetta a noi e costa meno (sempre che non si abbia intenzione di realizzare un progetto di dimensioni medio-grandi).

Proviamo quindi a dare un’occhiata ad alcune delle migliori offerte di VPS che possiamo scovare oggi sul Web :

# Amazon EC2

ha un’offerta di VPS su rete Cloud, che quindi costa poco e permette di avere anche un buon controllo sul server. L’offerta Linux T2 Small prevede 1 CPU e 2 GB di RAM. Costo 10,25 $ dollari al mese per un anno di contratto.
Per maggiori info : https://aws.amazon.com/ec2/instance-types/

# MyHosting

offre dei server con Ubuntu gia preinstallato, purtroppo propone solo 1 GB di RAM ma ben 11 processori virtuali. Costo 15,95 $ dollari al mese/
Per maggiori info : http://myhosting.com/ubuntu-vps

# Aruba Cloud Smart Server

il servizio offerto da Aruba “Small” consiste in 1 CPU ed 1 GB di RAM e 20 GB di disco. Costo 6,70 $ al mese.
Per maggiori info : http://www.cloud.it/cloud-computing/caratteristiche.aspx

# Dotblock

propone dei VPS Redundant oppure Scalable composti da 1 CPU 20 GB SSD per lo spazio disco ed 1 GB di RAM. Costo 9,95 $ dollari al mese.
Per maggiori info : http://www.dotblock.com/redundant.php – http://www.dotblock.com/scalable.php

# Dreamhost 

offre un servizio base VPS con banda illimitata 1 GB di RAM e 30 GB SSD di spazio disco.
Costo 15 $ al mese.
Per maggiori info : http://www.dreamhost.com/hosting/vps/

# Google Compute Engine

l’offerta di Google e’ davvero molto varia e direi componibile, ma per par condicio , rimanendo sulla stima degli altri vendor ho scelto l’opzione “g1-small” che e’ formata da 1,7 GB di RAM ed una condivisione dei processori all’interno del Cloud. Costo (calcolato in base al listino orario attuale pari a 0,023 $ all’ora)16,56 $ dollari al mese.
Per maggiori info : https://cloud.google.com/compute/

*Nota: ovviamente le offerte che possiamo trovare in giro sono molte di piu’ quindi questa e’ solo una piccola carrellata per aiutare a capire com’e’ composta la media dei servizi offerti.

PS: le caratteristiche dei servizi (cpu, ram, spazio disco ecc…) riportati nell’articolo non sono da considerarsi fissi, in quanto i vendor cambiano molto spesso i listini.