Newsgroup: it.lavoro.informatica
Titolo: Cloud computing fail

Quando anche strutture del calibro di amazon crashano per ore come si fa 
a dire che il cloud è una buona soluzione:
Questi e altri servizi sono tutti down
http://www.quora.com/
http://paper.li
http://friendfeed.com/
a causa di amazon:
http://mashable.com/2011/04/21/amazon-aws-server-problems/
http://tinyurl.com/3tjegcd
Il bello è che si vantavano che con la ridondanza dei server in tutto il 
mondo non ci dovrebbero essere pericoli di down...
-- 
http://www.evilripper.net
http://www.flickr.com/photos/evilripper/

 mondo non ci dovrebbero essere pericoli di down...
Infatti. Come è successo?

 Infatti. Come è successo?
spero che amazon spieghi bene che cavolo è successo!


Le signore di pulizie in raid... :-DDD


stra-LOL :-)

 a dire che il cloud è una buona soluzione:
E' un po' che valuto il cloud come idea... IMHO è una grande idea se
sviluppata in una certa direzione ma assolutamente non è questo il
periodo... le infrastrutture e le connessioni fan cagare...
Al3x

mondo non ci dovrebbero essere pericoli di down...
Solo se chi si appogggia ai loro servizi paga per avere ridondanza
geografica, altrimenti ciccia.
-- 
Living in Barbaropoli
http://www.barbaropoli.com

 Le signore di pulizie in raid... :-DDD
LOL!

 Le signore di pulizie in raid... :-DDD
:-D

 geografica, altrimenti ciccia.
se č cosě allora quora ha il braccino corto... -_-'

 mondo non ci dovrebbero essere pericoli di down...
e infatti così è.
solo che la ridondanza *non* *è* trasparente a chi utilizza ec2.
quando tiri su un istanza decidi su che zona geografica la vuoi, se la
vuoi ridondata su un'altra zona geografica allora devi essere tu,
naturalmente, a provvedere alla ridondanza della *tua* infrastruttura.
anche perché avere due istanze in esecuzione costa il doppio.

 anche perché avere due istanze in esecuzione costa il doppio.
Quindi sono andati giů perchč loro non gestivano questa cosa! ok č molto 
probabile, ma mi pare strano che quora che dovrebbe svontare di soldi 
non abbia fatto questa cosa! -_-

 non abbia fatto questa cosa! -_-
io cosa ha fatto o non ha fatto quora non ne ho la più pallida idea,
rispondevo ad una osservazione in cui mi pareva si desse la colpa ad
amazon perché alcune infrastrutture ospitate non erano ridondate su
zone geografiche diverse.




Se ne hai un'altra in un datacentre in un altro continente hai
O in un altro datacentre nello stesso continente...


 rispondevo ad una osservazione
hai fatto bene a farla, perchč molto probabilmente č come avete detto tu 
e Freddy Krueger. Io davo per scontato troppe cose. :D

Il 22/04/2011 12.35, Freddy Krueger ha scritto:
comunque molti articoli danno la colpa ad amazon! :-D
http://bits.blogs.nytimes.com/2011/04/21/amazon-cloud-failure-takes-down-web-sites/?src=busln


http://bits.blogs.nytimes.com/2011/04/21/amazon-cloud-failure-takes-down-web-sites/?src=busln
Bah.
Visto che quando si parla di cloud computing pare di fare la caccia
alle streghe, molto semplicemente rispondi a questa domanda banale:
La tua azienda ha tutti i suoi bei server con i loro applicativi che
girano e che erogano servizio all'utenza ospitati in un datacentre a
glandate brianza.
La societa' che ti ospita ha altri 10 datacentre sparsi per l'italia,
ma il datacentre in cui sei tu va a fuoco.
Siccome nessuno aveva fatto un piano di disaster recovery c'e'
disservizio.
La mancanza di redundancy e' colpa tua che non l'hai pianificata e
pagata o del datacentre che comunque ti offriva altre location a
pagamento?
Al messimo c'e' da chiedersi se Amazon o equivalente in caso di fault
esteso non debba di sua sponte migrare il migrabile altrove, sempre
che sia possibile tecnicamente mantenere IP e MAC address in maniera
trasparente per loro..


 Questi e altri servizi sono tutti down
[cut]
rettid :-(((((((((((((
Ciao,
Giulio
--

 trasparente per loro..
concordo!

 periodo... le infrastrutture e le connessioni fan cagare...
io ci passo... tra massimo un mese avrò la prima applicazione in
cloud.. e speriamo che non piova.

 ridonzanza, alrimenti no.
Fammi capire. Per "ridondanza" si intende qualche macchina in più nel
singolo datacenter di zona geografica? Ed in una zona c'è sempre un
solo datacenter?

 trasparente per loro..
Trascuri il piccolo particolare che una parte importante del richiamo
commerciale del "cloud" sta proprio in questa vera o presunta
ridondanza.
Magari ora scopriamo che anche la ridondanza tra server nello stesso
datacenter deve essere esplicitamente dichiarata e richiesta.


Remane il fatto che se vuoi ridondanza geografica la devi pagare,
cloud o non cloud. Poi se va tutto giu' lo stesso ti puoi incazzare.
Lamentarsi che non c'e' ridondanza quando la tua stessa infrastruttura
non la prevedeva secondo me e' un po' come lamentarsi che non si e'
vinto alla lotteria senza neanche aver comprato il biglietto.



Da quello che ho capito Amazon ti fa girare la tua istanza in un
datacentre ed eventualmente ti sposta da un datacentre all'altro nella
stessa regione in caso di problemi.
Pero' sta a te mettere in piedi una architettura in alta
affidabilita', non ad Amazon.
In termini non cloud vorrebbe dire che metti un server nel datacentre
A e un server nel datacentre B e prevedi un meccanismo di controllo
per redirigere il traffico verso B se A muore.
Visto che a parita' di costo non ha senso tenere A e B nella stessa
citta', sarebbe meglio avere A e B in regioni diverse.
Quindi Reddit e soci avrebbero dovuto tenere in piedi una istanza in
north carolina e una in north california e a quanto pare non l'hanno
fatto.


 datacenter deve essere esplicitamente dichiarata e richiesta.
dipende.
se ti riferisci alla ridondanza dell'hardware su cui girano le
immagini non credo sia da mettere in discussione, almeno in questo
contesto, visto che il down (correggimi se sbaglio) riguardava la
connettività di una region e nessuna istanza mi risulta si sia fermata
e/o sia andata persa.
se invece ti riferisci al failover dei tuoi servizi mi sembra naturale
debba provvedere te, con la ridondanza, disaster recovery o quello che
ti pare.

 citta', sarebbe meglio avere A e B in regioni diverse.
il fatto č che le aziende passano al cloud per risparmiare e quindi comprano 
solo "A" confidando nell'affidabilita' del fornitore o nella buona sorte. 



Tale e quale a quando metti un server fisico in un datacentre
confidando nel fatto che che ha le telecamere di sorveglianza, gli
UPS, il sistema antiincendio e via dicendo.
Poi fuori arriva una ruspetta, ti fa un buco per terra e ti trancia la
fibra che ti collegava il server al resto del mondo. :)


 vinto alla lotteria senza neanche aver comprato il biglietto.
Mah, l'outsourcing hardware si faceva già decenni fa, e si è
continuato a fare senza bisogno del "cloud".

 ti pare.
Non credo che la polemica nasca dal failover di un singolo servizio,
che ovviamente sarebbe roba del cliente del cloud.
Se realmente nulla si è fermato, se tutte le istanze sono state
riavviate automaticamente su qualche altra macchina, che senso ha
tutto il discorso?

On 24 Apr, 18:45, Freddy Krueger <inva...@invalid.invalid> wrote:

E decenni fa se ti andava a fuoco il datacentre e dentro avevi tutto
l'hardware se non lo avevi previsto rimanevi a piedi.
Quindi?



ripeto, il down riguardava (correggimi sempre se sbaglio) la
connettività quindi le istanze sono rimaste isolate e/o hanno avuto
connettività ridotta. quindi l'hardware si poteva rimpallare le
istanze quanto voleva visto che il problema di connettività riguardava
l'intera region.

tutto il discorso?
Da quello che leggo in giro, ci sono stati problemi non ben definiti
(Amazon non dice piu; di tanto) che hanno tirato giu' piu' datacentre
nella stessa regione e i meccanismi di failover sono andati a gambe
all'aria.
Le istanze in A hanno iniziato ad avere problemi, sono state spostate
automaticamente in B.
B e' stato "contagiato" dagli stessi problemi di A.
Spostamento in automatico verso C.
C e' stato "contagiato" dai problemi di A e B e cosi' via fino al
collasso anche se sulla carta A B e C erano a compartimenti stagni.
Per rimettere in piedi il giocattolo hanno iniziato a migrare a mano
tutto in un'altra area geografica.
Magari tra X mesi diranno che era un bug nel software.


 continuato a fare senza bisogno del "cloud".
infatti niente ti vieta di continuare ad affidare i tuoi server fisici
ad aruba, se ti sembra sia la stessa cosa.

 Quindi?
Quindi qual'è la novità del cloud? Forse il costo basso, che lo rende
alla portata del piccolo.

basso costo da decine di megabit, a facilitare la ridondanza.
ecco sul basso costo e sulle decine di MB qualche perplessita' ce
l'avrei (io che un sistema HA, ridondato, ce l'ho e so bene quanto mi
costa)

 costa)
Bè, insomma, non mi dirai che negli anni 70-80 c'erano reti nazionali/
mondiali più capaci e più economiche di quelle attuali.
Che poi oggi il costo sia comunque alto e fuori della portata dei
"piccoli" può anche essere. Anche perchè nel frattempo è aumentato in
modo esponenziale il quantitativo di dati da ridondare, quindi bisogna
vedere quanto questo va a controbilanciare la caduta del costo
dell'hardware e servizio di rete.

dell'hardware e servizio di rete.
Io ti parlo per esperienza diretta, noi abbiamo un sistema a Roma, ed
un altro a Milano, gemelli, e costantemente durante la giornata si
auto-alimentano a vicenda. E la cosa non e' economica ne cosi' spedita
come sembra (e non siamo poggiati al peggior carrier che ci sia,
anzi). 
Un cliente che voleva ridondare i sistemi degli stabilimenti in
Romania sulla sede di Treviso alla fine c'ha rinunciato, la latenza
delle linee non era sufficiente, il sw che gestiva l'allinemanto
andava in timeout, alla fine ha preferito farsi un bel ftp nottetempo
ed amen, c'erano meno grattacapi da gestire.
Io dico solo che su questo argomento (che pure per e' molto
importante) spesso si ragiona piu' per frasi fatte e da marketing che
per esperienze di vita vissuta.
Altro nanetto, 18 mesi fa e' accaduto l'impossibile (la taglio un po'
con l'accetta ma vado di fretta), nel nostro dc di Roma, e' andato giu
il router che connetteva i nostri armadi al gw del dc, anche il
secondo router e' andato giu' (o meglio non e' mai entrato in
funzione), quindi i sistemi di Milano, sentendo che i loro fratellini
avevano una qualche bua hanno cominciato a funzionare, solo che per
qualche motivo il fortigate di $cliente, non li ha riconosciuti e si
rifiutava di far entrare i loro bit nella sua lan, bloccando tutte le
postazioni di lavoro di $cliente, risultato si saturava la banda,
dacche in uscita verso i nostri sistemi il fortigate di cliente'
faceva passare tutti i click di un migliaio di utenti che furiosamente
davanti ai loro browser provavano erirpovavano a connettersi alla loro
applicazione, ma poi in entrata droppava tutti i pacchetti. Il nostro
fortigate otando un traffico anomalo dopo un po' segava la
comunicazione con $cliente, poi la riprendeva dopo un 15 d'ora salvo
richiuderla e prima che ci accorgessimo della cosa passavano un pajo
d'ore (dalle 7 alle 9) poiche' anche il gw sms (attraverso cui
spedivamo gli allarmi) del dc era giu' per fatti suoi.
Praticamente una Cambogia di bit in viaggio.

alla portata del piccolo.
La novita' del cloud e' che scala, in alcuni casi se ci sono risorse
libere, in altri casi sempre (perche' e' previsto come servizio).
Detto tra noi, se non hai necessita' di scalare e sei una piccola
azienda, una macchina fisica costa meno (es. 29 euro/mese per un amd
dual core e 1GB di ram in germania).
Pero' non hai il vantaggio di poterla mettere in
piedi/clonare/smandruppare remotamente da un pannello di controllo.


 per esperienze di vita vissuta.
La mia non era frase da marketing, ma, penso, un dato di fatto: che la
tecnologia di rete oggi sia migliore di 20-30 anni fa. Come tu stesso
sei d'accordo, mi sembra.
Direi che è più marketing l'idea suggerita (se non dichiarata) nella
pubblicità, che il cloud dovrebbe fornire ridondanza ad ampio raggio
tutta inclusa nel "pacchetto".
Ma magari ho letto male io, nessuno suggerisce o dichiara nulla del
genere, non sia mai... ;-)

 piedi/clonare/smandruppare remotamente da un pannello di controllo.
Certo, ma bisogna vedere se questo controllo remoto totale è sempre
realmente necessario. E comunque l'accesso remoto funziona bene se
funziona bene la rete. Quindi tutto il discorso regge se le risorse
hardware/software per accedere alla rete sono di capacità sufficiente
ed abbastanza economiche, come già dicevo.
E se questi fornitori centralizzati di cloud sono in grado di
mantenere quel che promettono.

mantenere quel che promettono.
Se vuoi fare le cose in casa e hai 12k euro da investire solo per il
software, ti puoi fare la virtualizzazione in casa su ferro tuo con
Vmware Vsphere.
Cosi' hai anche la gestione delle "macchine" da remoto via pannellino
di controllo.
Fatto molto bene tra l'altro.
Il vantaggio maggiore e' che se hai la possibilita' di giostrarti conm
le immagini a tuo piacimento, la VM e' hardware independent e la puoi
anche preparare sul PC dell'ufficio con calma.


 intorno e che ogni 5 minuti ti chiede a che punto sei. :/
Mi sembrano le condizioni standard di lavoro di un qualsiasi
consulente IT, non solo sistemista, presso un qualsiasi cliente
italiano  :-)))

italiano  :-)))
Aumenta il rumore X100 e restringi il tavolino X5. :)


 tutta inclusa nel "pacchetto".
i termini del servizio sono chiari, se poi qualcuno (non te, sia
chiaro) equivoca per ignoranza sono decisamente fatti suoi.  il cloud
non è altro che il paradigma per l'utilizzo di risorse remote e
distribuite, non descrive come queste risorse devono essere
distribuite (anzi, astrae da queste problematiche) ne suggerisce
soluzioni di ridondanza ad ampio o stretto raggio. questo vuol dire
che *niente* può essere dato per scontato oltre ai "terms of service"
del singolo servizio e nella fattispecie amazon.
per inciso niente vieta che una azienda si doti della propria cloud
privata che avrà la propria topologia e la propria distribuzione
geografica, che può essere in parti opposte del pianeta piuttosto che
in due bunker dello stesso stabile o su due server uno a fianco
all'altro, quindi anche l'associazione cloud=outsourcing è del tutto
sbagliata.

 ed amen, c'erano meno grattacapi da gestire.
[CUT]
Scusa, che tipo di linee erano state prese in considerazione? Con che ISP?
Se ti interessa ancora una cosa del genere, con VPN a banda garantita (e 
latenze basse) tra estero e Italia, parliamone :)
ciao
Gabriele

 sbagliata.
Bè, hai ragione,  i termini del servizio naturalmente dipendono dal
fornitore, non certo dal paradigma.
Ma qualcosa di scontato sicuramente c'è. Come dire, se ti vendono
un'auto senza ruote, potrà anche essere chiaramente scritto nei
termini del servizio, ma insomma... :-))
Quindi direi che, tra gli aspetti scontati in un offerta seria di
cloud, c'è un grado non banale e non super limitato di ridondanza.
Questo va sicuramente ed attentamente verificato.  Da quanto detto
finora sembrerebbe che siamo invece all'auto senza ruote, salvo
esplicito accordo...

 cloud.. e speriamo che non piova.
premesso che è un applicazione MIA extra (nel senso fuori dal normale 
lavoro di consulente)
posso chiederti dove ti appoggi per la tua applicazione, ne sto finendo 
una anchio, fra un mesetto sara su un server di test "casalingo" con 
accesso esterno per fare test (3,4 utenti di prova per test, debug, e 
prova generale) almeno per un paio di settimane, poi non so se valutare 
un VPS o EC2 o altro.
tu come sei messo ??
Ciao

> tu come sei messo ??
Beh io sono in ambiente windows, per me il cloud è Azure.

latenze basse) tra estero e Italia, parliamone :)
E' cosa di un pajo d'anni fa', il carrier era BT, la tipologia delle
linee sinceramente non la ricordo, ricordo che era uno dei pochi che
ti permetteva d'identificare gli hop che ogni bit faceva limitando al
massimo i passaggi intermedi (l'ho detta un po' alla carlona ma non
sono uno specialista di reti, mi occupo della parte applicativa).
Il problema applicativo in questo caso non era dato tanto
dall'ampliezza di banda, quanto dalla latenza

 dall'ampliezza di banda, quanto dalla latenza
Nel caso specifico, per cui le macchine per forza stanno nelle sedi del 
cliente, IMHO serve una HDSL o fibra. Nel caso della fibra si può fare la 
raccolta del traffico direttamente sul POP del provider. Ad es. tra Padova e 
Milano, per dirne una.
Quindi nel primo tratto la latenza è bassissima e la banda sempre piena.
Poi dalla sede dell'ISP, ci vuole un routing serio e qualche accordo col 
provider estero, poi di nuovo HDSL o fibra verso le 2a sede del cliente.
Se ti capitano altre richieste simili, scrivimi !
grazie, ciao :)
Gabriele

Se ti capitano altre richieste simili, scrivimi !
Ti terro' presente grazie.