You are currently browsing the category archive for the 'Generale' category.
Essendo ormai da anni nel campo dell’ hosting mi sono accorto come spesso, i clienti, soprattutto quelli che si sono appena affacciati in questo mondo, siano confusi nel comprendere il vero singnificiato della parola banda.
Banda, in se non significa molto, infatti rappresenta la velocità della connessione disponibile. Per banda infatti si intende la misura della capacità e non la misura della quantità. Per fare un’ esempio, quando si dice 10Mbps, la banda disponibile è da 0 a 10Mbps, quindi la capacità, non quantità. Una parola decisamente più significativa, soprattutto nel campo dell’ hosting è “trasferimento”. In questo campo però ormai, il termine banda viene usato per rappresentare la quantità di dati trasferibili su una determinata linea, quindi per non generare confusione userò banda inteso come trasferimento.
Nel mrcato dell’ hosting, ci sono principalmente due tipi di banda disponibili, La banda flat (Unmetered, in cui paghi in base all’ ampiezza di banda disponibile) e la banda a trasferimento (Metered , in cui paghi in base ai GB disponibili di traffico mensile). Chi utilizza il termine illimitata, è nell’ errore, in quanto, il trasferimento di dati mensile generabile, anche nella banda Unmetered, è limitato dall’ ampiezza di banda disponibile. Entrambi le soluzioni possono essere di tipo “Banda Condivisa” o “Banda Dedicata”.
Banda Condivisa
Quando un’ hoster dice che puoi generare un X GB mensili di trasferimento dati puoi essere quasi sicuro di essere nella tipologia di Banda Condivisa. Spesso, non sempre, si è connessi a 10Mbps o 100Mbps al proprio Switch e il traffico verso internet viene suddiviso da più clienti. Il motivo è semplice, i clienti non sempre utilizzano tutta la banda ad essa assegnata e quindi poterla ripartire su più cliente permette all’ hoster e conseguentemente al cliente di contenere i costi, garantendo un livello qualitativo del servizio (ovviamente se l’hoster non condivide la banda con troppi clienti) a costi ottimali. La cosa può essere paragonato ai servizi di telefonia, in cui lo stesso modem, per esempio, ha un rapporto utenza 16:1 o 20:1 (20utenti per modem), tale prassi è molto comune, in quanto sfrutta il fatto che tutti gli utenti non sono connessi contemporaneamente. Tale prassi però non deve essere utilizzata eccessivamente, infatti se per esempio l’ ISP ha un solo modem, significa che solo un’ utente potrà connettersi, e gli altri troveranno occupato. Lo stesso vale per l’ hoster che, in caso di eccessiva condivisione della banda il cliente soffrirà di poca disponibilità della stessa, latenze elevate e trasferimenti lenti. Nella banda condivisa, non si hanno garanzie di disponibilità, il primo che arriva è il primo ad essere servito.
Questo tipo di banda è utile se hai siti che non richiedono un’ ampiezza di banda costante ed elevata, infatti anche se sei connesso a 100Mbps puoi avere un momento disponibilità per tutti i 100Mbps e il momento dopo essere limitato a 10Mbps e così via.
Banda Dedicata
La banda dedicata, non è condivisa con alcun cliente, il rapporto è 1:1 e tutta la banda acquistata è disponibile ed utilizzata unicamente dal singolo cliente. Quando acquisti una banda dedicata il provider ti assegnerà un CBR (come il bit rate, solamente definito come constant bit rate), che sarà, solitamente, pari al 70% della banda totale. Se la tua banda è a 10Mbps, avrai una garanzia di disponibilità pari a 7Mbps. Tale banda è molto utile per chi necessita di garanzie certe.
Conoscere quanta banda ti servirà
Quando un cliente si appresta ad acquistare un servizio è importantissimo che conosca quanto traffico mensile dovrà generare e quale sarà l’ ampiezza della banda necessaria. L’ ampiezza di banda viene misurata in bits al secondo, mentre la quantità di dati trasferiti viene misurata in bytes.
Per esempio un’ ampiezza di banda di 1,5Mbps permette un trasferimento teorico di 474.609375GB in entrambe le direzioni (Ingresso e Uscita) nel corso del singolo mese (30 giorni). Se prospetti che verrà generato meno traffico, allora probabilmente non avrai problemi nell’ acquistare 1,5Mbps di banda. Dico probabilmente perchè in verità entrano in gioco molti fattori. Per esempio se avete un servizio di streaming, che in totale genera 450GB mensili probabilmente 1,5Mbps non saranno sufficienti in quanto può capitare che nel pomeriggio il consumo salga a 5-6Mbps per scendere quasi a zero durante la notte. In questo caso una connettività a consumo farà al caso vostro.
Se dovete, per esempio conoscere quanta banda consuma avere 50 utenti contemporanei, relativi ad un server audio con streaming a 28Kbps dovete fare il seguente conteggio:
28Kb*50= X Mbp
Il conteggio sarà: 1.3671875Mb .. Teoricamente vi basterà una connessione da 1,5Mbps. Purtroppo, per il particolare funzionamento del protocollo IP, la disponibilità di banda dovrà essere maggiore, in quanto dovrete tenere onto delle collisioni, dell’ overhead dei pacchetti e altri fattori che causeranno la necessità di reinviare i pacchetti. Inoltre dovrete considerare del CBR (citato precedentemente) pari al 70%, quindi dovrete almeno riservare il 30% della banda per tutte queste variabili, quindi nell’ esempio, per fare streaming a 28kb con 50utenti contemporanei necessiterete di una 2Mbps.
Come vedete, nel scegliere un servizio è importante non solo conoscere quanto trasferimento dati verrà generato mensilmente, ma anche l’ ampiezza di banda che si necessita (Mbps) durante i momenti di picco. Per i servizi di streaming, il calcolo è abbastanza semplice, basta consultare l’ esempio fatto precedentemente. Per i siti con molti file in download potete prendere il massimo numero di file che vi aspettate verranno trasferiti contemporaneamente e usarlo insieme al file con dimensione maggiore per calcolare l’ampiezza di banda disponibile necessaria.
Prendiamo per esempio che metterete un vostro software in download e vi aspettate che il numero massimo di download contemporanei sarà 50, potete lavorare nel seguente modo:
- Determinare l’ ampiezza minima disponibile per singolo download. 1,5Mbps è un limite molto alto, solitamente 128 o 256kb sono più che sufficienti.
- Moltiplicare il numero massimo di download contemporanei per l’ ampiezza minima disponibile, nel nostro esempio: 50 * 1,5 = 75Mbps
Considerando anche l’ overhead, le collisioni il CBR (ricordate cosa abbiamo detto prima?) la banda da acquistare sarà una 100Mbps.
Se il vostro servizio non è ne di streaming ne di download, calcolare la banda necessaria è molto più difficile, infatti dovrete considerare cosa gli utenti faranno sul vostro sito e misurare il peso (la dimensione) media delle pagine del vostro sito web. Calcolare il numero massimo di utenti contemporanei sul vostro sito ed eseguire il conteggio come nell’ esempio precedente. In questo caso il conteggio non sarà molto accurato in quanto l’ utente e il sito web non trasmettono dati in maniera costante, se per esempio hai 20 utenti connessi in contemporanea, ma 10 stanno leggendo un file di testo, durante la lettura i dati non verranno scambiati, quindi la banda consumata dal vostro sito sarà solo quella degli altri 10 utenti che stanno navigando. In questo caso il consiglio che vi posso dare è di tagliare del 30% la banda stimata. Se nel conteggio precedente vi risulta che il consumo sarà pari a 5Mbps, iniziate acquistando una 3Mpbs e vedere come lavora, in caso è possibile in qualsiasi momento effettuare l’ upgrade per le vostre necessità.
mail: matteob@seflow.net
msn: matteob@seflow.net
A risentirci presto…
Correva la seconda decade del 2007 quando SeFlow lanciò il servizio di VPScube v.2 portando dietro a se speranze, prestazioni, costi contenuti, e tanta voglia di rivoluzionare l’ hosting. Il servizio prese subito piede e vedemmo quintuplicare in poche settimane le macchine programmate per il lancio del servizio. Ogni macchina è dotata di un’ ottimo livello di failure tollerance, con hard disk hot swap in raid 10, alimentatori ridondati e rete interna gigabit per migrazioni “lampo” in caso di necessità.
Proprio ieri sera, parlando su msn con un cliente, notavo come, fino ad allora, la somma di uptime di tutti i nodi era pari al 99,9%. Quell’ 1% perso per strada era semplicemente dovuto agli aggiornamenti notturni che abbiamo eseguito con l’ uscita di centos 5.1 che ci ha permesso di increementare e migliorare le prestazioni e la stabilità del sistema con le nuove versioni del software di virtualizzazione, tale modifica, ovviamente, ha richiesto un riavvio, in orario notturno di tutte le macchine. Sembra quasi che “me la sia cercata”, infatti ieri sera ho speso ottime parole, stracolme di orgoglio per non aver avuto alcun downtime non programmato dalla nascita del servizi, non sapendo che la jella fosse pronta a colpire.
Ore 7.18, il telefono del lavoro squilla e ancora frastornato da quell’ orrenda suoneria che prima o poi deciderò di cambiare, vengo folgorato da 6 parole che mi rimbombano nella testa cariche di paura: <<sig. Berlonghi, abbiamo un problema coi vps….>,dopo qualche secondo di smarrimento mi faccio spiegare la situazione. Una macchina attivata proprio 2 giorni prima al riavvio mostra il fatidico messaggio di errore
“Operating system not found….”
Il bios del controller raid da un failure hardware su 3 dei 4 hard disk presenti.
Inizialmente penso ad uno scherzo, come è possibile che una macchina con 3 giorni di vita riesca a folgorare contemporaneamente 3 hard disk?
Liquido il tecnico di primo livello che mi ha contattato per sentire il mio collega “jo” che ritengo un’ ottimo sistemista ed è lui di turno in quel momento, con voce tremolante mi conferma la triste realtà. in 2 minuti netti mi vesto, cambio lavo, faccio colazione (una briosche che passa direttamente dal freezer alla mia bocca) e sfidando qualsiasi autovelox presente sulla ovest mi presento in farm e constato la triste realtà: oggi 17 gennaio 2008 c’è stato il primo downtime di un nodo dei vps SeFlow! (prima o poi doveva succedere, anche se speravo in un poi millenario!! ). Smonto la macchina e mi arriva una vampata di odore di bruciato che mi fa capire subito quale sia il problema. A quel punto prendo gli hard disk, li metto sotto una nuova macchina e la faccio partire, l’ output mi mostra qualsiasi tipo di errore esistente sulla faccia della terra sul filesystem e capisco che quel *bellissimo* alimentatore Zippy Emacs ridondanto, pagato 5 giorni prima la bellezza di 400euro (iva esclusa) in barba a tutte le protezioni decantate si era portato con se anche gli hard disk. Avvio così un live cd (ovviamente ubuntu ndr.), monto l’ array come secondario (gli array dei 3ware possono essere montati come semplici filesystem lvm) e inizio a prelevare i dati dei singoli vps. Ore 14.20 riesco a salvare tutti i dati, mi sento un’ entità quasi superiore, stacco gli hard disk, lancio la macchina, il sistema riparte… Per sicurezza faccio fare un check del filesystem delle vps, ci vuole un pò, ma vista la sfortuna che mi ha assillato voglio essere sicuro. Ad un certo punto il messaggio tanto agoniato
“Filesystem marked clean…”
Tra i miei colleghi parte la ola, i vps tornano a rispondere al ping…
Berlonghi 1 sfortuna 0
!!!!!!
Contatto i clienti (per fortuna il server essendo nuovo erano solo 8), mi scuso, loro son rincuorati e comunico che lo SLA offerto verrà “personalizzato”. Mi raduno con i commerciali e arrivo ad una conclusione: upgrade gratuito con raddoppio di numero di CPU disponibili per tutti a tempo indeterminato!. Lo comunico ai clienti, il più felice sembra essere un cliente che ha preso una vps da 2cpu che ora se ne trova 4….
Guardo le risorse consumate dalle vps dopo l’ upgrade gratuito e penso “Per fortuna sono sfighe che capitano una volta nella vita….”
… o forse no?
p.s. se i dati non fossero stati recuperati ci sarebbero stati i backup aggiornati a 4 ore prima 
Matteo Berlonghi
All’ estero è ormai prassi comune per le aziende avere un proprio spazio di comunicazione, informale, unilaterale, con i propri clienti e tutti gli utenti interessati al modus operandi dell’ azienda. SeFlow, da sempre attenta alle relazioni con i propri clienti ha scelto il blog per scrivere articoli, notizie sui nostri prodotti, sul nostro modo di lavorare, su vicende internet che permettano di abbattere quel muro di formalismi che spesso non permette al cliente di comprendere a pieno, e quindi di poter sfruttare, le potenzialità dei servizi offerti dall’ azienda stessa.
Personalmente non ho mai amato la comunicazione formale, la trovo troppo limitativa, spesso sono costretto a scrivere fiumi di parole senza dire nulla, senza riuscire ad esprimere il concetto, creando (per fortuna raramente) incomprensioni. Con il blog, SeFlow , cerca di stabilire un nuovo rapporto con i clienti, qui non troverete paroloni, semplicemente verranno raccontati momenti di vita d’ azienda, o come preferisco chiamarla “vita da farm”. Troverete articoli su nuovi prodotti prossimi al lancio, le nostre idee, sul nostro modo di intendere la new economy (che ormai di new ha ben poco), e a grande richiesta anche reportage sul modo di attivare i nostri servizi. Questo è possibile perchè siamo un’ azienda trasparente, nessun segreto è nascosto dietro il nostro successo.
L’ idea è nata dopo un reportage da me eseguito su hostingtalk.it, che troverete qui , in cui illustro i passi per l’ attivazione di un server dedicato. Il post ha mostrato subito forte interesse, sintomo che gli utenti sono curiosi e vogliono sapere cosa ”ci sta dietro”. Noi, in completa trasparenza vi porteremo in questo viaggio.
A risentirci presto…..
Matteo Berlonghi
