Fibre Vs Rame – 2010 Vs 1960

In questo periodo sto facendo test senza scopo tirando in mezzo cavi seriali, paralleli, ethernet e fibre, tecnologie vecchie di 30 anni, e ne sto misurando latenze e velocità. Credo pubblicherò un report completo a breve, ma qualche appunto preso “on the road” lo trovate già QUI.

Oggi parlando con un amico mi è venuto in mente un paragone, tecnicamente non proprio completo e rigoroso*, ma veramente utile per capire, con una tecnica che definirei “da fruttivendolo”, il progresso e gli enormi vantaggi portati dalle fibre ottiche.

Un cavo in fibra ottica può portare 160 lunghezze d’onda. Ognuna di queste lunghezze d’onda porta un segnale da 10 Gbps. Ci sono quindi 1600 Gbps disponibili**. Un cavo seriale porta, in totale, al massimo 115200 bps. Quindi:

Velocità max fibra ottica = MaxFC = 1600 Gbps = 1 600 000 Mbps

Velocità max cavo seriale = MaxSC = 115200 bps = 0.1152 Mbps

Calcoliamo quindi quanti cavi seriali ci servono per raggiungere la velocità di una fibra ottica:

Numero cavi seriali = NSC = MaxFC / MaxSC = 1 600 000 Mbps / 0.1152 Mbps = 13 888 889

Adesso arriva la perla: un metro di cavo seriale pesa 50 grammi. Un metro di fibra ottica ne pesa meno di 2:

Peso fibra ottica = PFC = 2 g

Peso cavo seriale = PSC = 50 g

Per finire dobbiamo quindi calcolare quanti Kg di cavi seriali ci servono per raggiungere la velocità di un singolo cavo in fibra, dal peso di 2 grammi (0.002 Kg):

PtotSC = NSC x PSC = 13 888 889 x 50 g = 694 444 450 g = 694 444 , 450 Kg

Concludendo: per sostituire un cavo in fibra ottica (dal peso, come già detto, di due soli grammi) utilizzato per connettere due punti ad una velocità di 1600 Gbps ed alla distanza di un metro, ci servirebbero 14 milioni di cavi seriali, che avrebbero un peso totale di circa 700 tonnellate. Per UN SOLO metro di distanza. Vi lascio solo immaginare cosa vorrebbe dire sostituire anche solo le fibre transatlantiche.

C’è un’altro dato interessante: la fibra ottica ha una latenza di 5 microsecondi al Km, mentre un cavo seriale ha una latenza di 5 millisecondi al metro.

Latenza fibra ottica = LFC = 5 microsec / Km = 0.005 ms / Km

Latenza cavo seriale = LSC = 5 ms / m = 5000 ms / Km

Immaginiamo di dover collegare Amsterdam a New York e consideriamo una distanza in linea retta tra le due città di circa 6000 Km (inutile dire che chiaramente quella reale percorsa dai cavi sarebbe maggiore). Calcoliamo quindi la latenza, ovvero il tempo impiegato per percorrere questa distanza sui due tipi di cavi:

Distanza = D = 6000 Km

Tempo di percorrenza fibra ottica = TFC = LFC x D = (0.005 ms/Km) * 6000 Km = 30  ms

Tempo di percorrenza cavo seriale = TSC = LSC x D = (5000 ms / Km) * 6000 Km = 30 000 000 ms = 30 000 secondi = 500 minuti = 8 ore e 30 minuti

Questo, in linea teorica. Perchè per percorrere distanze così enormi il segnale deve essere rigenerato, e questo introduce tremendi ritardi nella trasmissione. Ricordo che per percorrere questi 6000 Km il segnale sul cavo in fibra (che percorre 50 Km senza rigenerazione) dovrebbe essere rigenerato (amplificato) 120 volte, mentre quello seriale dovrebbe essere rigenerato ogni 8 metri, ovvero 750 000 volte.

Numero rigenerazioni fibra ottica = NrFC = 120

Numero rigenerazioni cavo seriale = NrSC = 750 000

Qui azzardo una serie di conti, di cui non garantisco l’accuratezza teorica. Quello che è certo, è che comunque i numeri che otterrò saranno inferiori a quelli reali:

Il tempo reale di percorrenza in fibra ottica della linea Amsterdam – New York è di circa 80 ms. Quello teorico calcolato in linea retta è di 30 ms, quindi sembra ragionevole calcolare 40 ms teorici sulla tratta realmente percorsa. Significa che abbiamo circa 40 ms (sottraggo i 40 di tempo teorico agli 80 di tempo reale misurato) di tempo perso nelle 120 rigenerazioni. Questo vuol dire che una rigenerazione del segnale in fibra ottica ritarda il tutto di 0.34 ms.

Tempo reale percorrenza fibra ottica = TpFC = 80 ms

Tempo totale rigenerazione fibra ottica = TtotrFC = 40 ms

Tempo rigenerazione fibra ottica = TrFC = 0.34 ms

Con questi dati, calcolo il tempo impiegato da una rigenerazione del segnale per un cavo seriale. Uso la relazione LFC : TrFC = LSC : TrSC, quindi:

Tempo rigenerazione cavo seriale = TrSC = (LSC x TrFC) / LFC = (5000 ms / Km x 0.34 ms) / 0.005 ms/Km = 340 000 ms

Come già detto, per percorrere questa distanza, il segnale di un cavo seriale deve essere rigenerato 750 000 volte, quindi calcoliamo il tempo totale di rigenerazione:

Tempo totale rigenerazione cavo seriale = TtotrSC = TrSC * NrSC = 340 000 ms * 750 000 = 225 000 000 000 ms

Per concludere devo calcolare il tempo totale impiegato per la percorrenza di questa tratta tramite cavo seriale:

Tempo reale percorrenza cavo seriale = TpSC = TtotrSC + TSC = 255 000 000 000 ms + 30 000 000 ms = 255 030 000 000 ms = 255 030 000 secondi = 4 250 500 minuti = 70 842 ore = 2951 giorni = 8 anni.

In fibra ottica, andiamo da Amsterdam a New York in 80 millisecondi. Con un cavo seriale, impiegheremmo 8 anni. Probabilmente sarebbe molto più conveniente inviare una lettera invece che una mail.

Giorgio

* RS 232 non è stato concepito per comunicazioni a lunga distanza: era usato per collegare i modem o i nodi di un cluster, comunque entro pochi metri. La sua portata è intorno agli 8 metri, questo vuol dire che ogni 8 metri serve un rigeneratore di segnale. Le fibre vanno invece per 50 Km o più senza essere toccate. Per finire, ad oggi non esiste modo di connettere due singoli punti utilizzando tutta la banda disponibile su un cavo in fibra ottica. Allo stesso modo non esiste un modo per connettere due host con 14 milioni di cavi seriali.

** Metto lì un dato senza approfondirlo ulteriormente: abbiamo una velocità di 1600 Gbps per singolo cavo. Le linee transoceaniche sono però composte di fasci di 864 cavi, e di solito sono stese a coppie.

FlareVM – Server Virtuali XEN

Nell’ultima settimana mi è stata concesso in prova da FlareVM.it un server virtuale “Flare 256“.

L’offerta è molto competitiva: per poco meno di 10 € viene offerta una macchina virtuale XEN-Based con 256 MB di RAM, 10 GB di HD e 2 mbit di banda flat. Il servizio offerto da FlareVM si pone come una valida alternativa all’ormai conosciutissimo  Linode, che tra l’altro non offre connettività italiana.

La prima impressione è stata ottima. La latenza è veramente molto bassa (i server che ospitano le macchine virtuali dei clienti di FlareVM sono ospitati nel DC2 di KPN, in via Caldera a Milano), e le prestazioni della VM eccezionali (con il pacchetto Flare 256 viene assegnato un singolo core -Xeon E5504-).

Una peculiarità del servizio è FlarePanel, il pannello di gestione XEN, totalmente sviluppato dalla compagnia. Pur presentando qualche difetto di impaginazione o qualche bug nel layout si pone come un pannello funzionale, semplice da usare e anche, perchè no, bello da vedere. C’è da segnalare che tutti i bug che ho riscontrato (che comunque, va specificato, non compromettevano l’utilizzo normale della macchina virtuale) sono stati corretti in poche ore.

Nei prossimi giorni mi dedicherò agli stress-test e prove sulla banda e uptime, poi pubblicherò un report completo.

Intanto, se volete provare il servizio, utilizzando il codice promozionale FLARE256PROMO avrete diritto ad una VM Flare256 scontata del 50 % per il primo mese.

Giorgio

DNS Resolvers

Ho una lista, ma puntualmente la perdo, quindi credo sia il caso di appuntarsi qui i vari servizi di risoluzione DNS ed i loro IP (in prima riga i primari, in seconda, se disponibili, i secondari):

Google Public DNS:

8.8.8.8, 8.8.4.4

Level3 DNS (Unofficial*):

4.2.2.1, 4.2.2.2, 4.2.2.3, 4.2.2.4

4.2.2.5, 4.2.2.6

OpenDNS:

208.67.222.222, 208.67.220.220

208.67.222.220, 208.67.220.222

DNSAdvantage (UltraDNS):

156.154.70.1, 156.154.71.1

* Il servizio non è mai stato reso pubblico. Questi resolver funzionano, funzionano perfettamente, ma Level3 li ha mai resi disponibili al pubblico ufficialmente.

Spamassassin – Bug di Capodanno

spamassassin

Stavo notando un improvviso incremento dello spam, senza notare un incremento del numero totale di mail ricevute su alcuni server che gestisco. Cosa chiaramente anomala.

Con un pò di smanettamenti ho notato che le email che venivano falciate risultavano positive per “FH_DATE_PAST_20XX”.

Con ulteriori smanettamenti sono arrivato qui:

http://wiki.apache.org/spamassassin/Rules/FH_DATE_PAST_20XX

In pratica il test verifica se l’header “Date:” è palesemente nel futuro. Come fa? Controlla se è tra il 2010 e il 2099. Con conseguenze catastrofiche visto che ormai siamo veramente nel 2010.

Mi sembra strano che nessuno ne parli, son l’unico pistola che lo ha notato?

Al momento comunque l’unica soluzione credo sia inserire nel local.cf questo:

score FH_DATE_PAST_20XX 0.0

Giorgio

No al Low-Cost – Davvero una scelta?

Eh si. Questa è la domanda.

Mi ricordo un post su un blog che ho letto tempo fa, TANTO tempo fa, quando il low-cost come lo intendiamo oggi (per intenderci, parlo dell’era “tophost” non dell’era “aruba”) era ancora agli inizi. Non ricordo le parole precise e non riesco a ritrovarlo (la rete è grande), ma diceva qualcosa tipo:

“Per offrire hosting a 30 € annui servono un server e una licenza Plesk. Per offrire hosting a 10 o 1200 € serve una infrastruttura.”

La frase può sembrare banale, ma racchiude una interessante distinzione. In pratica, offrire un servizio a 10 € è complicato e richiede investimenti come un servizio di alto livello. Non a caso, e qui il riscontro è immediato, tutte le aziende che nascono in questi anni, si stabilizzano su quella fascia di offerte e prezzi, non sul low-cost estremo o sull’alto livello.

Le realtà che offrono low-cost estremo, come lo ho definito, infatti, quali sono, in italia? Tophost, che ha una infrastruttura leggendaria e che sicuramente ha alzato all’infinito i costi di startup. Netsons che ha potuto lanciare questo tipo di servizi solo dopo 3 anni di esperienza sull’hosting gratuito. OVH, che non è proprio l’ultima arrivata (qui però va fatto notare che il loro pacchetto gratuito e quello a 14 €/anno sono spariti da qualche mese). Per ultimo, in ordine di tempo, Web4Web, che nasce dalla decennale esperienza della Guest SRL. Così, a memoria, altri non me ne vengono.

I motivi? Prima di tutto, va minimizzato l’intervento umano, perchè far fare una cosa ad un umano costa. Far far la stessa cosa ad una macchina, nella maggior parte dei casi, ha un costo trascurabile. Questo significa studiare un sistema di gestione clienti automatico, creare una buona KB per i clienti, semplificare e minimizzare le procedure.

Il secondo problema è relativo alle macchine stesse. In questo tipo di low-cost si arriva a toccarne i limiti. Mettere 10 000 siti a carico 0 su un server non è semplice come lo è metterne 300 molto frequentati: servono sistemi di gestione e di controllo del carico, perchè il minimo overload, il minimo bug di uno script o un semplice errore di un utente possono, in ambienti normali, far volare giù la macchina, creando disagi agli altri 9999 clienti.

Insomma, parliamo di problemi non indifferenti, che richiedono soluzioni non indifferenti che hanno costi non indifferenti. Siamo abbastanza lontani dall’ordinare un server da ovh, installarci plesk, aprire una partita IVA e iniziare a rivendere hosting.

Alla luce di tutto questo discorso la domanda è: le realtà di piccola/media grandezza, che dichiarano di “non voler entrare nel low-cost”, lo fanno per reale scelta o perchè, semplicemente, non possono entrarci?

Credo che la mia risposta sia chiara dopo questo articolo :) , però sarebbe interessante avere altri pareri.

Giorgio

Quanto resta agli ambienti LAMP mono-server?

lamp

Come dicevo, negli ultimi mesi ho dedicato moltissimo tempo allo studio delle infrastrutture che stanno dietro ai servizi cosiddetti “Cloud” più utilizzati al giorno d’oggi (Google, Youtube, Facebook, Amazon, Linkedin, Azure etc).

Il motivo è semplice: gli ambienti LAMP usati fino ad ora (e qui mi riferisco alle classiche strutture utilizzate dalla maggior parte degli hosting provider, un server con su installato mysql, apache, php), non coprono le più basilari necessità di un sito web. Stiamo parlando, sia chiaro, di un sito qualunque, quale può essere il mio blog.

Mi spiego meglio: fino a qualche anno fa (ma, oserei dire, qualche mese fa, perchè, alla fine, l’esplosione di questo cloud computing è stata tutta questa estate), era assolutamente normale, quando il pacchetto hosting non bastava più (spazio esaurito, costanti abusi di cpu), acquistarne uno più grande, scaricare files e db dal vecchio spazio, spostarli sul nuovo e riconfigurare il tutto (io stesso lo ho fatto più volte con il mio blog: partito da tophost, passato a netsons, poi a eticoweb openhost e poi ad un piano personalizzato eticoweb).

Ma, riflettendoci, che senso ha? Perchè stressarsi con questo lavoro quando con un account Blogger/WordPress ho un sito esattamente uguale a questo in grado di reggere praticamente qualunque carico di lavoro? Stessa cosa dicasi per i server dedicati. Quando il mio dedicatino non regge più ne prendo uno nuovo più potente e ci sposto tutto. Anche qui, c’è un senso? Perchè comprare un piccolo dedicato quando con una VPS (mi riferisco a RackSpace CloudServers, Amazon EC2 e GoGrid) ho lo stesso servizio, scalabilità immediata e semplice, ridondanza ed in più i vantaggi di un ambiente “burstable”?

Altro problema ricorrente è l’uptime. Leggevo tempo fa “The Big Switch” di Nicholas Carr. Fa un interessante paragone tra gli anni 70, in cui, se cadeva il server aziendale, si chiamava IBM che lo ritirava su in 3/4 giorni, gli anni 80/90 in cui c’è stata la corsa all’offerta del servizio di supporto onsite più efficiente (il down di un server con un gestionale iniziava ad essere un serio problema, avendo completamente sostituito gli archivi cartacei), e oggi, dove si è capito che l’erogazione del servizio semplicemente NON PUO’ più interrompersi (basti pensare allo scompiglio creato dal down di 12 minuti di GMail di qualche mese fa).

Il servizio, è ovviamente erogato da servers. L’ultimo passaggio è quindi immediato: ogni singolo componente dell’infrastruttura, per quanto ridondato possa essere, può fermarsi. Servono quindi strutture che sappiano utilizzare gruppi (pool) di macchine, e che possano gestire il down di uno o più componenti in modo totalmente trasparente all’utente finale, l’utlizzatore del servizio. La struttura deve essere in grado di gestire la caduta di un singolo server, rack, sala o datacenter, come se fosse una cosa di routine che può accadere tutti i giorni.

E qui abbiamo una ulteriore divisione: per grandi servizi come Google, per cui adattare gli strumenti esistenti sarebbe complicato se non impossibile, sono state create strutture proprietarie, perfettamente ottimizzate, volte a svolgere precisi compiti. In altre parole, “su misura”.

C’è poi chi sta lavorando per “accogliere” gli utenti che vengono dagli ambienti che ho definito mono-server, che sta quindi lavorando per creare piattaforme che pur essendo basate su quello che compone i sistemi LAMP (banalmente, Linux, Apache, MySQL e PHP), godano di caratteristiche che a questi mancavano, come, ancora una volta, scalabilità e ridondanza (io resto comunque abbastanza convinto che tuttora ci siano limiti sopra i quali non si può andare. non ho infatti trovato uno di questi servizi “cloud hosting” in cui mysql scali a dovere).

Quindi, concludendo, mi chiedo: per quanti anni ancora vedremo siti ospitati su server singoli senza alcun tipo di fail-over? Questi vecchi ambienti, alla luce di queste considerazioni, sono davvero così terribili? Strutture come RackSpace CloudSites e Seeweb Cloud Hosting, prenderanno piede così velocemente?

Adminspotting!

Adminspotting-600x600w

Si tratta di un “remake” del monologo iniziale del film Trainspotting, in versione per sysadmin. Già di suo è commovente. Se poi lo paragonate al testo originale, che è l’esatto opposto, è la fine.

A sto punto mi chiedo: perchè?

Giorgio

Hard Disk Online – Dropbox

logo

Lo uso da tempo, su consiglio di un amico, e ne sono davvero molto soddisfatto.

Oltre che incredibilmente veloce negli upload/download, è molto funzionale. A differenza dei suoi simili, che richiedono l’installazione di un piccolo programma sul pc e l’impostazione delle directory da tenere sincronizzate, Dropbox si installa in 5 minuti. Durante il processo di installazione crea una cartella che terrà sempre sincronizzata con i server centrali e quindi con gli altri computer associati all’account.

E’ poi possibile inserire i files caricati in una directory pubblica; Questa funziona è utile per esempio quando c’è necessità di far scaricare ad altri un file in modo semplice e veloce.

Per finire, le foto caricate nell’apposita cartella, vengono automaticamente divise in album e rese disponibili al pubblico.

E’ assolutamente da provare. Registrandovi con il link fornito da me (che contiene il mio codice di affiliazione), avrete fin da subito 250 MB di spazio extra (per un totale di 2 GB e 250 MB).

Giorgio

Infrastrutture – La Nuova Serie

Seguo da tempo highscalability. Sono stato particolarmente colpito da una sua tipologia di articoli, quella in cui vengono presentati schemi delle infrastrutture che stanno dietro ai servizi cloud-based che usiamo tutti i giorni (facebook, twitter, google).

Non viene fatto questo grandissimo lavoro, semplicemente recuperano tutte le informazioni disponibili in rete, le espongono in forma schematica e uniforme, e ne vengono fuori articoli, a mio parere, molto ben fatti e utili.

Ho pensato di fare lo stesso, descrivendo le strutture di alcuni hosting-provider a cui mi sono interessato in passato.

Per ora la lista è questa:

Si tratta ovviamente solo dell’inizio, pubblicati questi primi 5 articoli, su richiesta dei lettori o seguendo quel mio mitico sesto senso continuerò.

Quello su OVH è praticamente pronto (l’ho descritta qualche giorno fa su hostingtalk), devo solo riordinarlo poi lo pubblico.

Giorgio

ByetHost – 3 Anni Dopo

bhlogonew

Ne avevo parlato 3 anni fa, descrivendolo come un grande miracolo, una tremenda e fortissima realtà commerciale. Ad oggi sono passati 3 anni e hanno 500 000 siti a confermare quello che avevo “previsto”.

Chiarisco un attimo lo scenario per chi non lo conoscesse:

Ad inizio 2005 un gruppo di persone non meglio definito inizia lo sviluppo di un pannello di controllo open source specifico per servizi di free-hosting, oserei dire il primo facciotuttoio della storia. Server Debian appena installato, due comandi (“wget http://lorosito/install.sh” e “sh install.sh”) e ti ritrovavi con un’interfaccia web dalla quale creavi il sito web con layout predefiniti, che conteneva già tutto (sistema di registrazione utenti, vhost e il resto). In due ore era possibile lanciare un servizio di hosting fatto e finito.

Iniziano quindi a crearsi decine e decine di siti, che usando questo pannello offrono free hosting. Tutte piccole realtà ovviamente, servizi lanciati da ragazzini su VPS o piccoli dedicati e gestiti grazie al tool di amministrazione in php.

A metà 2006, termina lo sviluppo di questo pannello. Niente più aggiornamenti, niente più supporto. Ovviamente a fine anno, senza saper nemmeno come aggiornare php per tappare le gravissime falle di sicurezza, tutte le piccole realtà sopradescritte vanno in panico totale.

All’inizio dell’anno seguente, uno di questi servizi, byethost.com, si sveglia, crea un nuovo pannello compatibile, amplia la struttura, e nell’arco di un mese acquista tutti i suoi simili, facendoli di fatto sparire. Con una sola grande mossa commerciale acquisiscono e disintegrano ogni concorrente.

Fine del racconto.

A tre anni di distanza ovviamente i dubbi restano: Hanno creato loro quel sistema per far avviare dei servizi ad altri e poi comprarli a poco prezzo? Era una cosa già studiata fin dall’inizio? Insomma sono ragazzi che hanno avuto una grande idea e hanno fatto il botto o sono dei mostri che vogliono conquistare il mondo?

Comunque, al di là di tutto quello che c’è dietro, che comunque sia è storia e basta. Sicuramente una solidissima realtà. Tra l’altro l’infrastruttura è anche ad un livello tecnico non da poco. Non si tratta di semplici server con tutti i servizi mischiati, è un cluster con diversi pool di servers che svolgono le diverse funzioni, tutto questo basato su una SAN in fibra ottica (non vengono dati in giro molti dettagli).

Che ne pensate?

(ah, ovviamente ci risentiamo tra 3 anni)

Giorgio

Posted in Web-Hosting. Tags: , , . 4 commenti »