Visualizzazione post con etichetta hosting. Mostra tutti i post
Visualizzazione post con etichetta hosting. Mostra tutti i post

sabato 26 ottobre 2013

Mbps, TB/mese, traffico, banda...

Sul concetto di "traffico", "banda", e sulle relative unità di misura (Mbps, TB/mese, GB/mese, ecc.) c'è parecchia confusione.

Vediamo di chiarire:

BANDA è la "capacità di comunicazione" di un server.
Ovvero, facendo un parallelo stradale: quanto larga è la strada che collega un server ad internet? Quante corsie ha?
L'unità di misura di questa capacità è il Mbps, ovvero MEGA BIT AL SECONDO (Da NON indicare, come pur fanno molti, in MBps, che sarebbe "mega byte al secondo", oppure mbps (milli-bit al secondo)
1 Mbps significa che, in un secondo, è possibile inviare un milione di bit, corrispondenti a circa  125000 byte, ovvero circa 122 KB (kilobyte)

TRAFFICO invece è la QUANTITA' di dati che vengono fatti trasmettere in una certa quantità di tempo; questa "quantità di tempo", convenzionalmente e per scopi puramente commerciali, è spesso stabilita ad un mese.
Restando al parallelo stradale: quante automobili ho la possibilità di far viaggiare gratis su questa strada nell'arco di un mese?

Le offerte di connettività per un server, o un piano hosting, normalmente sono definite o per banda garantita, oppure per traffico.

Ad esempio, un'offerta di 1 Mbps garantito, significa che al nostro server è garantita la disponibilità di una connessione minima, sempre, di 1 Mbps. A seconda del provider, può darsi che questo limite ci sia dato modo di superarlo (tanto, poco, occasionalmente...), ma che comunque, in qualsiasi situazione, ci "garantirà" comunque questa banda minima.

A quanto corrisponde 1 Mbps, in termini di traffico?


Supponiamo che un mese abbia 30 giorni (alcuni 31, uno 28 ecc. ...  prendiamo 30 per semplicità, ok?)
In un mese ci sono 24 x 30 = 720 ore, corrispondenti a 3600 x 720 = 2.592.000 secondi
OK?

Con 1 Mbps posso trasmettere in un secondo 1048576 bit (1 Mb corrisponde, appunto, a 1048576 bit), pari a 1048576 / 8 = 131072 byte
Quindi, in un mese potrò (in teoria) trasmettere 131072 byte * 2.592.000 secondi =  339.738.624.000 byte, corrispondenti a 331.776.000 Kbyte, corrispondenti a 324.000 Mbyte, corrispondenti a 316 GB
(segnalo un  utile calcolatore di banda on line)

Incertezze e fonti di equivoci:


  • un KB non sono "1000 byte", ma 1024; un MB non sono "mille kilobyte", ma 1024 kilobyte, quindi 1048576 byte; però spesso qualcuno in questi casi arrotonda (arbitrariamente) a 1000.
  • quando trasmettiamo qualcosa in internet, oltre ai nostri dati, una certa quantità se ne va in header dei pacchetti, controlli di parità, reinvio per pacchetti persi per strada... quindi, se dobbiamo scaricare un file da 1 GB, il nostro consumo di traffico complessivo sarà sicuramente superiore ad 1 GB. Quanto superiore? Operativamente, può capitare che sia anche il doppio...
  • la "banda" sulle connessioni di un server è sempre "simmetrica": cioè significa ad esempio che, su una banda di 1 Mbps, è possibile contemporaneamente fare un download (dal server verso internet) ed un upload (da internet verso il server), ciascuno dei quali da 1 Mbps; quindi, in realtà, la banda disponibile è doppia
  • in un server il consumo di banda non sarà quasi mai simmetrico: a seconda della funzione del server, la banda in uscita sarà maggiore rispetto a quella in entrata (il caso più frequente), oppure il contrario
  • quando si parla di "traffico", si considera sempre la somma sia del traffico in entrata che di quello in uscita
    Quindi, il calcolo che abbiamo fatto sopra per determinare che con una banda di 1 Mbps posso inviare 316 GB in un mese, andrebbe raddoppiata: nel senso che, con 1 Mbps, posso fare un upload di 316 GB ed un download di 316 GB: quindi, in totale, 632 GB

Sporchi trucchi di alcuni provider


Questi sono trucchi che ho sperimentato e verificato esser messi in pratica da alcuni provider (che evito di nominare):

  • 1 Mbps dichiarato in realtà viene fatto equivalere a 0,5 Mbps in entrata e 0,5 Mbps in uscita
    Poiché la banda è simmetrica, "interpretano" che il Mbps sia complessivo, ovvero la somma di banda in entrata e di quella in uscita.
    Insomma, è un modo truffaldino per farvi credere di avere il doppio della banda che avete in realtà
  • Arrotondare 1024 a 1000
    Diversi provider "arrotondano", secondo convenienza, 1024 a 1000 nelle conversioni. Difficile da rilevare se non con calcoli abbastanza impegnativi 
  • un traffico a volume non dà nessuna garanzia di tempo
    il fatto che ad esempio abbiate 1 TB di traffico al mese, non significa che è garantita la banda minima di 3 Mbps per trasmetterlo nell'arco di un mese: potrebbe essere che in determinati momenti abbiate una banda anche molto superiore (anche 20, 30 , 50 Mbps), ed in altri invece ne abbiate pochissima (anche MOLTO meno dei 3 Mbps teorici).
    Meccanismo di per sé corretto, purché non si esageri...
    Nel senso: la banda " a traffico" costa normalmente MENO (anzi, MOLTO MENO) di una banda "flat" garantita, proprio perché permette al provider di giostrarsi, realizzandola per mezzo di banda in quel momento inutilizzata.
    Mi spiego: ai livelli superiori, la connettività non è MAI venduta a volume, ma sempre flat. Un provider può acquistare 1 Gbps di banda, ma non può acquistare invece i petabyte di traffico che è possibile realizzare con 1 Gbps: lui acquista 1 Gbps di banda garantita, che poi la utilizzi o meno è affar suo.
    Poi il provider può usare questo 1 Gbps per fornire, ad esempio, 100 Mbps di connettività garantita a un centinaio di server. Però questo centinaio di server non riuscirà MAI ad impiegarli effettivamente tutti, perchè il consumo di banda di un server nell'arco della giornata è molto vario ed altalenante: in acuni momenti consumerà 90, in altri 30, in altri quasi nulla...
    Quindi, istante per istante, "avanzerà" della banda, anche in quantità sensibile; ed è questa banda che il provider spesso poi utilizzerà per fornire, appunto, "traffico a consumo" ad altri server
    Se però il consumo di banda da parte degli altri server (quelli "a banda garantita") dovesse aumentare, il provider immediatamente taglierà la banda a disposizione di quelli con traffico "a volume"     

Quindi, in definitiva: traffico a volume o a banda flat garantita?


Se il servizio non è critico, ed il budget basso, conviene indirizzarsi verso un traffico a volume (con l'accortezza di scegliere oculatamente il provider, perchè si potrebbe comunque andare incontro a brutte sorprese)
Se il servizio è "importante", allora è di gran lunga preferibile indirizzarsi verso una connessione flat garantita.

martedì 14 agosto 2012

confronti offerte Cloud su Vmware - I parte - Aruba

Mi hanno commissionato di scegliere il "best buy" per metter su alcuni VPS su un a piattaforma cloud basata su vmware.
Poichè per il lavoro mi pagano MOLTO meno di quanto dovrebbero, non ho remore a riportare qui un po' di appunti per agevolare chi, questi confronti, se li fa da solo...

Cominciamo con l'analizzare l'offerta cloud di Aruba, basata su una tariffazione oraria che tiene conto si soli 3 parametri: CPU, RAM ed hard disk.
Il listino completo è disponibile qui: http://computing.cloud.it/it/listino
Hanno delle offerte più economiche e super-più economiche, basate su Hyper-V (BLEAH!), che non prendo neppure in considerazione, e mi concentro sull'offerta Vmware.
Cominciamo con il rendere il costo un po' più leggibile ed omogeneo, perchè il costo orario è solo uno specchietto per le allodole.

orario giornaliero mensile
CPU € 0,025 € 0.60 € 18,00
RAM (per 1 GB) € 0,005 € 0,12 € 3,60
HDD (per 10 GB) € 0,003 € 0,072 € 2,16

Sui prezzi, è presto per fare vere considerazioni; inserirò prossimamente quelli dei competitor, ed allora si che avrà senso fare confronti (e considerazioni).

Vediamo intanto i punti essenziali del resto dell'offerta Aruba e di eventuali costi collaterali, più o meno nascosti;
  • sono disponibili (a vari prezzi) MS-SQL Server in varie edizioni, ed il pannello Plesk con vari add-on.
    Ai miei fini, inutile: i VPS saranno basati su Linux e non Windows. Ma lo segnalo...
  • nel prezzo, se a qualcuno serve, è compresa la licenza di Windows Server 2008R2 64bit oppure Windows Webserver 2003R2
  • è compresa altresì banda per 1 Gbps flat
  • Aruba fornisce addirittura uno SLA, e l'uptime garantito è il seguente:
    - Uptime del 99,95% su base annuale, per la disponibilità dei nodi fisici (server) che ospitano l'Infrastruttura virtuale;
    - Uptime del 99,95% su base annuale, di accessibilità tramite rete internet alla Infrastruttura virtuale creata ed allocata dal Cliente;
    - Uptime del 100% su base annuale per alimentazione elettrica e/o climatizzazione ambientale;

sabato 15 gennaio 2011

E' importante che il tuo server sia in Italia

Ai fini di un buon posizionamento del tuo sito sui motori di ricerca (e di Google in particolare), ha una certa importanza anche dove si trova il server dove hai l'hosting.
Se ti rivolgi ad un pubblico italiano, non basta che tu abbia un dominio .it: è meglio se anche il server si trova fisicamente in Italia.

A dircelo è Matt Cutts, il guru di Google:



Nota per i niubbi: se non ve la cavate troppo con l'inglese, cliccando sull'iconcina "cc" in basso vi appariranno i sottotitoli... in italiano.
Buona visione!
Molto tempo fa, diciamo all'alba di Google, i siti si posizionavano in paesi differenti sulla base del loro TLD.
Quindi .fr voleva dire che eri francese, ma quello era anche tutto quello che sapevamo, fino a che, circa nel 2000-2001, abbiamo iniziato a guardare all'ubicazione del server, al suo indirizzo IP.
Ciò per dire che, beh, non finisce per .fr ma è localizzato in Francia sulla base del suo indirizzo IP, quindi probabilmente il sito è utile per gli utenti francesi.
E questo è principalmente il modo con cui hai un impatto sul posizionamento con Google.
Sai, se abiti negli USA, il tuo sito è negli USA e non sei mai uscito dagli Stati Uniti, potresti non accorgerti mai di questi fattori. Ma il fatto che il tuo server sia localizzato in USA o Francia, Germania o Inghilterra, Canada o un altro posto ancora può determinare il posizionamento.
Quindi per esempio se vai su google.com e cerchi "banca" ottieni risultati differenti rispetto alla situazione in cui  fai la stessa ricerca, "banca", in google.com.au o google.co.uk.
Quindi possiamo dire che cerchiamo nella maniera più assoluta di offrire i risultati più rilevanti ad ogni utente in ogni paese e l'ubicazione del server in termini di indirizzo IP rappresenta un fattore importante.

Ed approfondisce l'argomento anche in quest'altro video: