Spazio ftp illimitato

[Ciccio®]

Salve a tutti, possiedo un registratore per videosorveglianza in grado
di salvare su un ftp delle registrazioni quando rileva un allarme.
Per fare cio' ho acquistato uno spazio web su aruba.
Dopo circa 1 mese mi contattano per dirmi questo:

"Gentile cliente,
la presente per comunicarLe che, per evitare il possibile blocco del
dominio, è necessario rendere il sito stesso conforme alla Policy di Aruba:
http://kb.aruba.it/KB/a292/policy.aspx
Con particolare riferimento alla dicitura sottostante:
[...] utilizzare lo spazio web, eventualmente acquistato presso Aruba,
esclusivamente per la pubblicazione del sito web e non come repositorio,
ossia come strumento per la mera archiviazione di files e/o di materiale
proprio e/o scaricabile anche da altri siti"


Quindi a quanto pare aruba non permette tale salvataggio. Potete
consigliarmi un hosting che mi permetta di usare l' ftp in modo da non
incorrere in tale problema?
Grazie anticipatamente per le risposte.

[ga.n]

Ciccio® ha spiegato il 07/11/2012 :

> esclusivamente per la pubblicazione del sito web e non come repositorio,
> ossia come strumento per la mera archiviazione di files e/o di materiale
> proprio e/o scaricabile anche da altri siti"

metti una photogallery protetta da password :)

ti vieta di avere un sito di foto protetto da password

(ad esempio con le foto visibili solo ai parenti)

--
d'un tratto vorresti essere hindu per
bestemmiare singolarmente ognuna delle migliaia di divinita' che
hanno.

[ga.n]

Nel suo scritto precedente, ga.n ha sostenuto :

> Ciccio® ha spiegato il 07/11/2012 :
>> esclusivamente per la pubblicazione del sito web e non come repositorio,
>> ossia come strumento per la mera archiviazione di files e/o di materiale
>> proprio e/o scaricabile anche da altri siti"

> metti una photogallery protetta da password :)

> ti vieta di avere un sito di foto protetto da password

> (ad esempio con le foto visibili solo ai parenti)

c'era un "nulla" da qualche parte :D aggiungilo tu

--
caro amico che stai cercando di inviarmi un fax al mio telefono
dell'ufficio, dopo sei volte che non ci riesci, non ti viene il
sospetto di aver sbagliato numero?
che cazzo hai nel cervello, l'omogeneizzato di merda di cane?

[Andrea D'Amore]

In article <tZwms.4418$5b....@tornado.fastwebnet.it>,

Ciccio® <princ...@libero.it> wrote:

> Potete consigliarmi un hosting che mi permetta di usare l' ftp in
> modo da non incorrere in tale problema?

Cerca "storage ftp space" e aiuta Google premendo su uno degli avvisi a
pagamento.

[L'Innominato]

Il 07/11/12 18:35, Ciccio® ha scritto:

> [...] utilizzare lo spazio web, eventualmente acquistato presso Aruba,
> esclusivamente per la pubblicazione del sito web e non come repositorio,
> ossia come strumento per la mera archiviazione di files e/o di materiale
> proprio e/o scaricabile anche da altri siti"

Non mi pare assolutamente una novità

> Quindi a quanto pare aruba non permette tale salvataggio. Potete
> consigliarmi un hosting che mi permetta di usare l' ftp in modo da non
> incorrere in tale problema?

Direi che è molto difficile.

Ti do 3 opzioni:

1) Guarda aglio hoster esteri.. in Italia penzano più a come far cassa
che al dare servizi

2) Valuta qualche servizio CLOUD di storage files, magari ha anche
accesso ftp, magari dico pure una ca ss ata...

3) un serverino dentro casa no?

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[rootkit]

Il Wed, 07 Nov 2012 18:35:21 +0100, Ciccio® ha scritto:


> Quindi a quanto pare aruba non permette tale salvataggio. Potete
> consigliarmi un hosting che mi permetta di usare l' ftp in modo da non
> incorrere in tale problema?

a te non serve un hosting, serve uno storage di rete. ora la domanda che
ti pongo è: il protocollo ftp è obbligatorio? perché ad esempio amazon s3
lo vedo adattissimo per questo scopo.

[Ciccio®]

Il 07/11/12 23:48, rootkit ha scritto:

> a te non serve un hosting, serve uno storage di rete. ora la domanda che
> ti pongo è: il protocollo ftp è obbligatorio? perché ad esempio amazon s3
> lo vedo adattissimo per questo scopo.

Si', purtroppo solo ftp

[Ciccio®]

Il 07/11/12 19:26, ga.n ha scritto:

> metti una photogallery protetta da password :)
>
> ti vieta di avere un sito di foto protetto da password
>
> (ad esempio con le foto visibili solo ai parenti)

Questa e' un'idea (anche se materialmente non saprei farlo).

Ma non credo siano tanto stupidi, quando si rendono conto che la
cartella si ingrassa di gb ogni giorno...mah!

[Ciccio®]

Il 07/11/12 20:03, Andrea D'Amore ha scritto:

> Cerca "storage ftp space" e aiuta Google premendo su uno degli avvisi a
> pagamento.

Purtroppo non appare nessu ADs..sorry
Ad ogni modo alcuni host ci sono, ma offrono davvero poco spazio per
quanto costa.

[TripleM]

Il 07/11/2012 18:35, Ciccio® ha scritto:
> Salve a tutti, possiedo un registratore per videosorveglianza in grado

Per prima cosa l'illimitato non esiste (anche se tanti spacciano tante
cose per illimitate). Tu cercheresti un magazzino che abbia spazio
illimitato? Per cui sarebbe da stabilire una quantita' di storage
necessario (10GB, 100GB, 1TB,...?) in base a questo si puo' cercare la
soluzione migliore, se ti servono tanti TB di spazio devi comprarti uno
storage e metterlo in una server farm, se ti servono 10GB penso che con
i servizi offerti da amazon te la cavi. Nella peggiore delle ipotesi
prendi un server virtuale con lo spazio di cui necessiti...

Ciao
--
MMM

[Andrea D'Amore]

In article <YgRms.4779$5b....@tornado.fastwebnet.it>,

Ciccio® <princ...@libero.it> wrote:

> Purtroppo non appare nessu ADs..sorry

Screenshot or it didn't happen.

[rootkit]

Il Thu, 08 Nov 2012 18:12:50 +0100, TripleM ha scritto:

> Il 07/11/2012 18:35, Ciccio® ha scritto:
>> Salve a tutti, possiedo un registratore per videosorveglianza in grado
>
> Per prima cosa l'illimitato non esiste (anche se tanti spacciano tante
> cose per illimitate).

ni. forse intendi per quanto riguarda gli hosting, ma i servizi di storage
dove si paga a consumo come ad esempio amazon si possono definire, con
buona approssimazione, illimitati.

[Paolo De Dionigi]

Questo fa esattamente ciò che chiedi (e qualcosina in più, tipo la
replica su due datacenter separati e oltre all'accesso ftp, puoi
accedere con i client che si usano per AS3, puoi fare il mount dello
storage come se fosse una cartella condivisa e accedervi via http),
rimane solo da capire se il prezzo ti sta bene:

http://www.seeweb.it/cloudstorage/

--
Paolo De Dionigi

[Paolo De Dionigi]

Il 08/11/2012 17:37, Ciccio® ha scritto:

[Jeff]

Il giorno mercoledì 7 novembre 2012 17:35:22 UTC, Ciccio® ha scritto:
>
> Quindi a quanto pare aruba non permette tale salvataggio. Potete
>
> consigliarmi un hosting che mi permetta di usare l' ftp in modo da non
>
> incorrere in tale problema?
>
> Grazie anticipatamente per le risposte.

Potresti usare S3 come consigliato da RootKit e leggere qua come interfacciarlo con FTP: http://stackoverflow.com/questions/1855109/amazon-s3-ftp-interface

J.

[Ciccio®]

Il 09/11/12 09:39, Paolo De Dionigi ha scritto:

> Questo fa esattamente ciò che chiedi (e qualcosina in più, tipo la
> replica su due datacenter separati e oltre all'accesso ftp, puoi
> accedere con i client che si usano per AS3, puoi fare il mount dello
> storage come se fosse una cartella condivisa e accedervi via http),
> rimane solo da capire se il prezzo ti sta bene:
>
> http://www.seeweb.it/cloudstorage/

Contattati e chiesto se possibile interfacciare un dispositivo che salvi
immagini su un ftp...non rispondevano e andavano sul vago...credo non lo
faccia.

[Manlio Perillo]

Allora ti basta un serverino FTP che fa da proxy verso amazon s3.


Ciao Manlio

[Flavio Bosio]

Il 09/11/12 11.47, Jeff ha scritto:

Di certo conosce il detto.. un immagine vale piů di mille parole

https://s3.amazonaws.com/usenet_images/access_credential.png

Se sa spiegarmi come questo sia compatibile con il funzionamento di
https://cloudgates.net/ son tutto orecchi.

[Flavio Bosio]

Il 09/11/12 11.47, Jeff ha scritto:

[rootkit]

Il Fri, 09 Nov 2012 15:51:27 +0100, Flavio Bosio ha scritto:


> Di certo conosce il detto.. un immagine vale più di mille parole

>
> https://s3.amazonaws.com/usenet_images/access_credential.png
>
> Se sa spiegarmi come questo sia compatibile con il funzionamento di
> https://cloudgates.net/ son tutto orecchi.

creando un utente apposito e limitato sulla iam console, come specificato
anche nella procedura.

[Leonardo Serni]

On Fri, 09 Nov 2012 15:51:27 +0100, Flavio Bosio <flavio...@pec.it> wrote:

>> Potresti usare S3 come consigliato da RootKit e leggere qua come interfacciarlo con FTP: http://stackoverflow.com/questions/1855109/amazon-s3-ftp-interface

>Di certo conosce il detto.. un immagine vale più di mille parole

>https://s3.amazonaws.com/usenet_images/access_credential.png

>Se sa spiegarmi come questo sia compatibile con il funzionamento di
>https://cloudgates.net/ son tutto orecchi.

Immagino che uno crei un accesso S3, con apposita access key, e poi fornisca
questa access key a CloudGate che gli mette davanti una interfaccia FTP.

Di conseguenza, i dati su *quell'*accesso S3, anziche' essere potenzialmente
a disposizione di cani e porci di Amazon, sono potenzialmente a disposizione
di cani e porci su Amazon *e* su CloudGate.

Dato pero' appunto che i dati, senza CloudGate, avevano livello di sicurezza
APCEP-ODD[1], saranno stati opportunamente criptati, e saranno illeggibili a
CloudGate cosi' come lo erano[2] per Amazon.

E percio', il fatto che la chiave di *quell*'accesso S3 sia nota a CloudGate
non altera la sicurezza dei dati; se c'era, resta; se non c'era, beh.

("*quell*" fra asterischi perche', magari, se uno vuole tenere dati visibili
in chiaro ad Amazon ma non a CloudGate, in quel caso deve creare DUE diversi
accessi: uno in chiaro su Amazon, e uno criptato per CloudGate. Ma credo sia
uno scenario marginale).

Leonardo

[1] Accesso Potenziale a Cani e Porci - Oppuretifidi Delfornitore Diservizi?
[2] http://xkcd.com/538/

--
What would'st thou do, my squire so gay, that rides beside my reine
Were ye Glenallan's Earl this tide, and I were Roland Cheyne?
To turn the rein were sin and shame, to fight were wondrous peril:
What would ye do now, Roland Cheyne, were ye Glenallan's Earl?

[Flavio Bosio]

Il 09/11/12 21.22, Leonardo Serni ha scritto:

> On Fri, 09 Nov 2012 15:51:27 +0100, Flavio Bosio <flavio...@pec.it> wrote:
>
>>> Potresti usare S3 come consigliato da RootKit e leggere qua come interfacciarlo con FTP: http://stackoverflow.com/questions/1855109/amazon-s3-ftp-interface
>
>> Di certo conosce il detto.. un immagine vale più di mille parole
>
>> https://s3.amazonaws.com/usenet_images/access_credential.png
>
>> Se sa spiegarmi come questo sia compatibile con il funzionamento di
>> https://cloudgates.net/ son tutto orecchi.
>
> Immagino che uno crei un accesso S3, con apposita access key, e poi fornisca
> questa access key a CloudGate che gli mette davanti una interfaccia FTP.

Naturalmente, dopo essersi letto "TUTTA" la documentazione sul come
creare le policy adatte allo scopo, dopo aver appreso l'uso delle ACL ecc..

http://docs.amazonwebservices.com/AmazonS3/latest/dev/UsingIAMPolicies.html

Perfettamente in linea con la richiesta dell'utente.

> Di conseguenza, i dati su *quell'*accesso S3, anziche' essere potenzialmente
> a disposizione di cani e porci di Amazon, sono potenzialmente a disposizione
> di cani e porci su Amazon *e* su CloudGate.

Nel caso specifico, la criticità non sta nei dati in se quanto piuttosto
il dare accesso ad una risorsa quasi illimitata e certamente con un
account privilegiato.

> Dato pero' appunto che i dati, senza CloudGate, avevano livello di sicurezza
> APCEP-ODD[1], saranno stati opportunamente criptati, e saranno illeggibili a
> CloudGate cosi' come lo erano[2] per Amazon.

???
Encryption provides added security for your object data stored in your
buckets in Amazon S3. You can encrypt data on your client-side and
upload the encrypted data to Amazon S3. In this case, you manage
encryption process, the encryption keys, and related tools. Optionally,
you might want to use the server-side encryption feature in which Amazon
S3 encrypts your object data before saving it on disks in its data
centers and decrypts it when you download the objects, freeing you from
the tasks of managing encryption, encryption keys, and related tools.

ergo o li cripta prima di inviarli o vengono criptati da dal sistema ma
in quel caso chi possiede le chiavi può ovviamente anceh decrittarli.

Non vedo comunque il motivo di crittare immagini provenienti da una
telecamera di sorveglianza.

> E percio', il fatto che la chiave di *quell*'accesso S3 sia nota a CloudGate
> non altera la sicurezza dei dati; se c'era, resta; se non c'era, beh.

Ma il problema NON è che Amazon o CloudGate abbiano accesso ai suddetti
dati, il problema è che si stanno dando a terzi delle credenziali di
accesso ad un servizio, credenziali che necessariamente dovranno essere
registrate sui loro server, nei loro DB, ricordo che il limite per
single object è di 5TB mica 100GB (potrebbe arrivare una bella fattura
in caso di abuso)

[TripleM]

Il 08/11/2012 20:18, rootkit ha scritto:
> ni. forse intendi per quanto riguarda gli hosting, ma i servizi di storage
> dove si paga a consumo come ad esempio amazon si possono definire, con
> buona approssimazione, illimitati.

Esatto, "con buona approssimazione", non e' illimitato, dei limiti di
qualche tipo deve averli... e per stabilire la soluzione migliore da
adottare bisogna conoscere le esigenze e nessuno ha esigenze di storage
"illimitato".
Se avessi bisogno di 4/500 tera, andresti su amazon?

Ciao
--
MMM

[rootkit]

sicuramente dovrei valutare le esigenze, ma per quanto riguarda l'offerta
non c'è problema. e per 600$ l'anno un pensierino vale la pena di farcelo:

http://aws.amazon.com/s3/pricing/

poi sono anch'io convinto che nel caso di specie non ha senso parlare di
spazio illimitato se non altro perché i filmati di videosorveglianza è
assurdo (e talvolta illecito) volerli archiviare a tempo indeterminato.
però non è vero che nessuno ha esigenze di spazio illimitato, che non è
da confondere con esigenze di spazio infinito. se tu hai un database che
sai a priori crescerà solo nel tempo, magari con progressione non
lineare, come fai a valutare i limiti? stabilisci che ad una certa data
chiudi bottega?

[Leonardo Serni]

On Fri, 09 Nov 2012 23:53:12 +0100, Flavio Bosio <flavio...@pec.it> wrote:

>> Dato pero' appunto che i dati, senza CloudGate, avevano livello di sicurezza
>> APCEP-ODD[1], saranno stati opportunamente criptati, e saranno illeggibili a
>> CloudGate cosi' come lo erano[2] per Amazon.

[...]

>ergo o li cripta prima di inviarli

Esattamente.

>o vengono criptati da dal sistema ma
>in quel caso chi possiede le chiavi può ovviamente anceh decrittarli.

>Non vedo comunque il motivo di crittare immagini provenienti da una
>telecamera di sorveglianza.

Boh? Non dicevi che c'era un problema di sicurezza? Quello per me e' un
"motivo".

Scusa ma... mi pare che tu ti preoccupassi che chiunque puo' entrare in
casa, e ora tu ti stupisca se propongo "mettici una porta" :-D

>> E percio', il fatto che la chiave di *quell*'accesso S3 sia nota a CloudGate
>> non altera la sicurezza dei dati; se c'era, resta; se non c'era, beh.

>Ma il problema NON è che Amazon o CloudGate abbiano accesso ai suddetti
>dati, il problema è che si stanno dando a terzi delle credenziali di
>accesso ad un servizio

Non siamo mica a Hogwarts: "dare a terzi credenziali" non e' la formula
magica che permette che ti rubino l'anima :-).

Stai dando credenziali, di accesso ad un servizio, che custodisce certi
dati. Ergo: tu stai dando accesso a quei dati. Niente di meno, ma anche
niente di piu'. CloudGate puo' "impersonarti" solo limitatamente a quei
dati che sono su Amazon (puo' cancellarteli, per esempio).

Ma per dire, io sono ragionevolmente sicuro che non hai mai ispezionato
il codice sorgente del tuo client FTP in cerca di delayed logging, o di
altri tipi di backdoor. Come dire, in realta' tutti prima o poi "diamo"
le nostre credenziali a qualcuno senza avere la totale certezza su quel
qualcuno (o qualcosa).

>credenziali che necessariamente dovranno essere
>registrate sui loro server, nei loro DB, ricordo che il limite per
>single object è di 5TB mica 100GB (potrebbe arrivare una bella fattura
>in caso di abuso)

Questo e' un altro scenario ancora, pero'. Anche qui mi pare, comunque,
che le cose siano semplici - o ti fidi che CloudGate non ti voglia fare
scherzi, e non si accordi con Amazon, per fartene, oppure no. Nel primo
caso, non c'e' scelta: non fai il contratto con CloudGate e chiuso.

Il modo con cui opera CloudGate, di nuovo, non c'entra molto - tutto il
problema sta nel fatto che operino da intermediari; non nel "come".

Tanto per fare l'esempio e mostrare come questo NON risolva il problema
di fondo, possiamo immaginarci che le credenziali Amazon vengano subito
criptate da CloudGate con una chiave simmetrica che viene data soltanto
a te, ed usata come password per FTP. Quando ti logghi su CloudGate, la
tua password sblocca la credenziale e un token di verifica, e CloudGate
usa la credenziale gestendola in modo sicuro, e solo in memoria. Cosi',
senza un tuo intervento, CloudGate non ha modo di recuperare i dati ne'
di accedere ad Amazon a nome tuo.

E la cosa si riduce, di nuovo, al fidarsi che sia cosi'.

Leonardo

[Flavio Bosio]

Il 10/11/12 09.09, rootkit ha scritto:

> Il Sat, 10 Nov 2012 05:27:16 +0100, TripleM ha scritto:
>
>> Il 08/11/2012 20:18, rootkit ha scritto:
>>> ni. forse intendi per quanto riguarda gli hosting, ma i servizi di
>>> storage dove si paga a consumo come ad esempio amazon si possono
>>> definire, con buona approssimazione, illimitati.
>>
>> Esatto, "con buona approssimazione", non e' illimitato, dei limiti di
>> qualche tipo deve averli... e per stabilire la soluzione migliore da
>> adottare bisogna conoscere le esigenze e nessuno ha esigenze di storage
>> "illimitato".
>> Se avessi bisogno di 4/500 tera, andresti su amazon?
>
> sicuramente dovrei valutare le esigenze, ma per quanto riguarda l'offerta
> non c'è problema. e per 600$ l'anno un pensierino vale la pena di farcelo:

500 TB a 600$/anno ???

1 Terabyte [TB] = 1024 Gigabyte [GB]

per cui 500 TB = 512.000 GB

512.000 x 0,090 USD = 46.080 USD/mese

46.080 USD/mount x 12 mesi = 552.960 USD/anno

O sbaglio?

[rootkit]

Il Sat, 10 Nov 2012 10:29:06 +0100, Flavio Bosio ha scritto:


>> sicuramente dovrei valutare le esigenze, ma per quanto riguarda
>> l'offerta non c'è problema. e per 600$ l'anno un pensierino vale la
>> pena di farcelo:
>
> 500 TB a 600$/anno ???

si si, a colpo d'occhio avevo letto giga. comunque al di là dei costi su
cui si può discutere fino ad un certo punto il succo del discorso è che
il limite dell'offerta non c'è.

[Leonardo Serni]

On Sat, 10 Nov 2012 10:22:18 +0000 (UTC), rootkit <roo...@email.it> wrote:

>>> sicuramente dovrei valutare le esigenze, ma per quanto riguarda
>>> l'offerta non c'è problema. e per 600$ l'anno un pensierino vale la
>>> pena di farcelo:

>> 500 TB a 600$/anno ???

>si si, a colpo d'occhio avevo letto giga.

Eh, c'e' una certa differenza. Comunque, quando si parla di 500 TB, non
e' che i costi siano lontani da quell'ordine di grandezza (cosi' a naso
direi sui 100-150K annui, e 300-400K di setup).

Premesso che a simili altezze rarefatte io non sono mai arrivato: credo
che il sistema piu' massiccio che io abbia visto arrivasse a 80 TB.

[rootkit]

Il Sat, 10 Nov 2012 12:24:27 +0100, Leonardo Serni ha scritto:


>>> 500 TB a 600$/anno ???
>
>>si si, a colpo d'occhio avevo letto giga.
>
> Eh, c'e' una certa differenza. Comunque, quando si parla di 500 TB, non
> e' che i costi siano lontani da quell'ordine di grandezza (cosi' a naso
> direi sui 100-150K annui, e 300-400K di setup).

infatti, dicevo riguardo ai costi che sono discutibili fino ad un certo
punto. basti pensare che solo acquistando gli stessi tera sul mercato
consumer si arriverebbe sullo stesso ordine di grandezza...

> Premesso che a simili altezze rarefatte io non sono mai arrivato: credo
> che il sistema piu' massiccio che io abbia visto arrivasse a 80 TB.

anche per me pur non avendo chissà che esperienza sull'argomento sono
numeri che non ho mai visto neanche con il binocolo.

[perrins]

Il 07/11/2012 18:35, Ciccio® ha scritto:
> Salve a tutti, possiedo un registratore per videosorveglianza in grado

> di salvare su un ftp delle registrazioni quando rileva un allarme.
> Per fare cio' ho acquistato uno spazio web su aruba.

perché hai bisogno di illimitato?

le registrazioni vengono caricate ogni volta che suona l'allarme. penso
non suoni ogni mezz'ora...
stima/testa lo spazio che ti serve ogni volta, molitplica x3 e ottieni
quello che ti serve.

i miei miseri 2 cents

[Flavio Bosio]

Il 10/11/12 13.00, rootkit ha scritto:

> anche per me pur non avendo chissà che esperienza sull'argomento sono
> numeri che non ho mai visto neanche con il binocolo.

Allora Lustratevi gli occhi..

http://www.youtube.com/watch?v=A_4ZbhvWGcc&feature=related

Cosa si puà fare con un cappello rosso altro che bisonti..

[TripleM]

Il 10/11/2012 09:09, rootkit ha scritto:
> sicuramente dovrei valutare le esigenze, ma per quanto riguarda l'offerta
> non c'è problema. e per 600$ l'anno un pensierino vale la pena di farcelo:

A parte che come giustamente poi hai notato, 500TB per 600$ l'anno lo
compro immediatamente e lo rivendo...

> però non è vero che nessuno ha esigenze di spazio illimitato, che non è
> da confondere con esigenze di spazio infinito. se tu hai un database che

E' anche una questione di costi, premesso che anche Amazon ha i suoi
limiti, tanto per dirne uno sul traffico, che senso hanno TB infiniti se
tanto hai dei limiti di traffico? Oltre un certo limite (e con 500TB per
quanto mi riguarda quel limite e' superato), non e' piu' conveniente
andare in outsourcing.

> sai a priori crescerà solo nel tempo, magari con progressione non
> lineare, come fai a valutare i limiti? stabilisci che ad una certa data
> chiudi bottega?

Il costo dello storage diminuisce in maniera vertiginosa con gli anni,
che fai? Compri oggi 1000 Tera di storage pagandolo un botto o ti fai un
piano pluriennale, stabilendo che ad esempio per i primi 3 anni non
raggiungererari neanche i 100? Quindi compri lo storage per 100, nel
frattempo ammortizzi la spesa, da qui a tre anni il costo sara'
notevolmente inferiore per i successivi 900 TB. E anche cosi' non e'
illimitato, lo puo' essere nel tempo, sul lungo, ma nessuna azienda fa
valutazioni oltre i 10/15 anni sull'ICT da quanto mi risulta, visto il
variare vorticoso di prezzi, offerte e tecnologie.

Ciao
--
MMM

[Flavio Bosio]

Il 12/11/12 11.03, TripleM ha scritto:

> Il 10/11/2012 09:09, rootkit ha scritto:
>> sicuramente dovrei valutare le esigenze, ma per quanto riguarda l'offerta
>> non c'è problema. e per 600$ l'anno un pensierino vale la pena di
>> farcelo:
>
> A parte che come giustamente poi hai notato, 500TB per 600$ l'anno lo
> compro immediatamente e lo rivendo...
>
>> però non è vero che nessuno ha esigenze di spazio illimitato, che non è
>> da confondere con esigenze di spazio infinito. se tu hai un database che
>
> E' anche una questione di costi, premesso che anche Amazon ha i suoi
> limiti, tanto per dirne uno sul traffico, che senso hanno TB infiniti se
> tanto hai dei limiti di traffico? Oltre un certo limite (e con 500TB per
> quanto mi riguarda quel limite e' superato), non e' piu' conveniente
> andare in outsourcing.

Sorvoliamo sul fatto che un singolo armadio rack SSU (Sonexion Storage
System) offre 1.5 petabytes a 20GB/secondo e che sommandoli possono
arrivare ad oltre 500GB/secondo, basta fare un po di aritmetica per
rendersi conto che i 500TB richiesti paragonati alle potenzialità di
Amazon AWS fanno sorridere, ovviamente anche il resto
dell'infrastruttura sarà tarata sulle medesime dimensioni incluso il
traffico disponibile.

>> sai a priori crescerà solo nel tempo, magari con progressione non
>> lineare, come fai a valutare i limiti? stabilisci che ad una certa data
>> chiudi bottega?
>
> Il costo dello storage diminuisce in maniera vertiginosa con gli anni,
> che fai? Compri oggi 1000 Tera di storage pagandolo un botto o ti fai un
> piano pluriennale, stabilendo che ad esempio per i primi 3 anni non
> raggiungererari neanche i 100? Quindi compri lo storage per 100, nel
> frattempo ammortizzi la spesa, da qui a tre anni il costo sara'
> notevolmente inferiore per i successivi 900 TB. E anche cosi' non e'
> illimitato, lo puo' essere nel tempo, sul lungo, ma nessuna azienda fa
> valutazioni oltre i 10/15 anni sull'ICT da quanto mi risulta, visto il
> variare vorticoso di prezzi, offerte e tecnologie.

Ragion per cui non ha senso investire in storage in-house dato che i
prezzi sono destinati a scendere con il passare del tempo tanto vale
acquistare oggi azioni di Amazon e condividerne gli utili futuri no?

[rootkit]

Il Mon, 12 Nov 2012 11:03:15 +0100, TripleM ha scritto:


>> però non è vero che nessuno ha esigenze di spazio illimitato, che non è
>> da confondere con esigenze di spazio infinito. se tu hai un database
>> che
>
> E' anche una questione di costi, premesso che anche Amazon ha i suoi
> limiti, tanto per dirne uno sul traffico, che senso hanno TB infiniti se
> tanto hai dei limiti di traffico? Oltre un certo limite (e con 500TB per
> quanto mi riguarda quel limite e' superato), non e' piu' conveniente
> andare in outsourcing.

a parte che, come ha sottolineato leonardo serni, i costi di uno storage
di quelle dimensioni non scherzano affatto; in ogni caso sopra ti dicevo
che illimitato non è sinonimo di infinito. su amazon paghi per quello che
usi (da 5 giga in su, visto che fino a 5 giga è gratis) e non per quanto
prevedi di usare.

>> sai a priori crescerà solo nel tempo, magari con progressione non
>> lineare, come fai a valutare i limiti? stabilisci che ad una certa data
>> chiudi bottega?
>
> Il costo dello storage diminuisce in maniera vertiginosa con gli anni,
> che fai? Compri oggi 1000 Tera di storage pagandolo un botto o ti fai un
> piano pluriennale, stabilendo che ad esempio per i primi 3 anni non
> raggiungererari neanche i 100?

niente di tutto questo. semplicemente perché non funziona così: su amazon
non compri preventivamente nulla, crei un bucket e cominci a metterci
roba. poi paghi puntuale lo spazio che occupi e il traffico che generi,
poco o tanto che sia. stop. se hai occupato 10 paghi per 10, se hai
occupato 100 paghi per 100 e così via. "illimitato" all'atto pratico
significa nient'altro che questo.

[TripleM]

Il 12/11/2012 11:23, Flavio Bosio ha scritto:
> Sorvoliamo sul fatto che un singolo armadio rack SSU (Sonexion Storage
> System) offre 1.5 petabytes a 20GB/secondo e che sommandoli possono
> arrivare ad oltre 500GB/secondo, basta fare un po di aritmetica per
> rendersi conto che i 500TB richiesti paragonati alle potenzialità di
> Amazon AWS fanno sorridere, ovviamente anche il resto

Ma infatti e' ovvio che 500TB per Amazon non sono niente, lo spero per
loro, ma mica ho mai pensato che 500TB di storage mettessero in
difficolta' Amazon, se si e' inteso cosi' mi scuso, mi saro' espresso male.

> dell'infrastruttura sarà tarata sulle medesime dimensioni incluso il
> traffico disponibile.

A quali prezzi? lo spazio non e' tutto, puo' fare molto piu' traffico
un'applicazione che magari richiede 100GB rispetto ad una che richiede
100TB. E la cosa che contesto dall'inizio anche se ora si e' andato un
po' in la e' il concetto di spazio illimitato o comunque di risorse
illimitate. Per una azienda tipo Amazon puo' essere *quasi* illimitato o
virtualmente illimitato, ma per i comuni mortali cercare qualcosa di
"illimitato" ti porta solo a spese superiori a quelle necessarie e
probabilmente non avrai comunque l'illimitato.
Si tara bene le esigenze sui 3/5 anni e si cerca una soluzione per
quello. Non ci credo che esistano applicazioni che hanno bisogno di
storage illimitato sui 3 anni...

> Ragion per cui non ha senso investire in storage in-house dato che i
> prezzi sono destinati a scendere con il passare del tempo tanto vale
> acquistare oggi azioni di Amazon e condividerne gli utili futuri no?

Se non hai esigenze particolari si, ma se hai applicazioni che
richiedono tantissime richieste allo storage (oltre ad alcuni aspetti
legali che pero' non voglio approfondire), alla fine non avrai mai la
stessa velocita' di accesso allo storage che puoi avere in locale con
10Gbit di banda disponibile.
Do per scontato che uno che ha necessita' di storage "illimitato" abbia
gia' una infrastruttura che sfrutti il tutto, altrimenti non vedo
perche' non mettersi un pc pieno zeppo di hd con controller furbi e
copiare tutto li.

Ciao
--
MMM

[TripleM]

Il 12/11/2012 21:15, rootkit ha scritto:
> se hai occupato 10 paghi per 10, se hai
> occupato 100 paghi per 100 e così via. "illimitato" all'atto pratico
> significa nient'altro che questo.

Bah, continuo a non condividere il modo di ragionar cosi'... devo fare
una stima sui costi da affrontare? E come la faccio se non ho in mente
le risorse necessarie?
Ho capito cosa intendete per illimitato (per me continua a non essere
illimitato, il fatto che abbia un limite che non possiamo raggiungere
non lo rende illimitato) ma allora ci sono decine di servizi nel mondo
che fanno quanto richiesto, Aruba stessa offre un servizio simile
(almeno a parole), Google, Microsoft,...

Sara' che non mi piace l'idea di avere i dati miei e dei clienti sparsi
chissa' dove nel mondo e quindi tutti sti servizi non mi convincono se
non per un uso casalingo... :P

Ciao
--
MMM

[Jeff]

Il giorno martedì 13 novembre 2012 14:48:59 UTC, TripleM ha scritto:
> Il 12/11/2012 11:23, Flavio Bosio ha scritto:
>
>
> > dell'infrastruttura sarà tarata sulle medesime dimensioni incluso il
>
> > traffico disponibile.
>
>
>
> A quali prezzi? lo spazio non e' tutto, puo' fare molto piu' traffico
> un'applicazione che magari richiede 100GB rispetto ad una che richiede
> 100TB. E la cosa che contesto dall'inizio anche se ora si e' andato un
> po' in la e' il concetto di spazio illimitato o comunque di risorse
> illimitate. Per una azienda tipo Amazon puo' essere *quasi* illimitato o
> virtualmente illimitato, ma per i comuni mortali cercare qualcosa di
> "illimitato" ti porta solo a spese superiori a quelle necessarie e
> probabilmente non avrai comunque l'illimitato.
>
> Si tara bene le esigenze sui 3/5 anni e si cerca una soluzione per
> quello. Non ci credo che esistano applicazioni che hanno bisogno di
> storage illimitato sui 3 anni...

Il punto e' che con servizi tipo Amazon non devi fare pianificazione a 3/5 anni, perche' paghi per quello che usi. Per quanto accurate siano le pianificazioni saranno sempre distaccate dal caso reale o per sovradimensionamento dell'infrastruttura o per sottodimensionamento della stessa, inoltre con questo tipo di servizi abbatti anche il costo di setup dell'hardware ed incecchiamento dello stesso, per non parlare delle rotture o della durabilita' dei dati.

> > Ragion per cui non ha senso investire in storage in-house dato che i
> > prezzi sono destinati a scendere con il passare del tempo tanto vale
> > acquistare oggi azioni di Amazon e condividerne gli utili futuri no?
>
> Se non hai esigenze particolari si, ma se hai applicazioni che
> richiedono tantissime richieste allo storage (oltre ad alcuni aspetti
> legali che pero' non voglio approfondire), alla fine non avrai mai la
> stessa velocita' di accesso allo storage che puoi avere in locale con
> 10Gbit di banda disponibile.
>

Ovvio che se un applicazione fa cose particolari ci sia bisogno di una struttura hd apposita, ma che tipo di applicazioni hanno necessita' di accesso continuo a tonnelate di storage?
(Tra l'altro la comunicazione tra S3 ed EC2 e' veramente veloce, ma a questo punto si potrebbe optare per dischi EBS, quando uno si riempie ne monti un altro e via andare).

J.

[Leonardo Serni]

On Tue, 13 Nov 2012 16:09:51 +0100, TripleM <tri...@mailitalia.it> wrote:

>Il 12/11/2012 21:15, rootkit ha scritto:
>> se hai occupato 10 paghi per 10, se hai
>> occupato 100 paghi per 100 e così via. "illimitato" all'atto pratico
>> significa nient'altro che questo.

>Bah, continuo a non condividere il modo di ragionar cosi'... devo fare
>una stima sui costi da affrontare? E come la faccio se non ho in mente
>le risorse necessarie?

Avere uno storage illimitato ti aiuta: sai che i costi saranno non di tot
Euro, ma di tot euro a terabyte.

Se hai anche una funzione che ti da' il reddito per terabyte (perche' usi
quel terabyte per offrire servizi), allora puoi decidere che la soluzione
e' accessibile anche senza sapere quanto ti costera'; sai solo che hai un
costo fisso accessibile, e un guadagno superiore a un tot.

>Ho capito cosa intendete per illimitato (per me continua a non essere
>illimitato, il fatto che abbia un limite che non possiamo raggiungere
>non lo rende illimitato)

E' la definizione di "limite". Se non avesse limiti sarebbe INFINITO, non
illimitato :-)

[rootkit]

Il Tue, 13 Nov 2012 16:09:51 +0100, TripleM ha scritto:


>> se hai occupato 10 paghi per 10, se hai occupato 100 paghi per 100 e
>> così via. "illimitato" all'atto pratico significa nient'altro che
>> questo.
>
> Bah, continuo a non condividere il modo di ragionar cosi'... devo fare
> una stima sui costi da affrontare? E come la faccio se non ho in mente
> le risorse necessarie?

se non hai in mente le risorse necessarie una soluzione del genere ti
viene incontro anziché no. peggio sarebbe se tu dovessi decidere prima
quanto spazio ti serve e acquistarlo subito.

> Ho capito cosa intendete per illimitato (per me continua a non essere
> illimitato, il fatto che abbia un limite che non possiamo raggiungere
> non lo rende illimitato) ma allora ci sono decine di servizi nel mondo
> che fanno quanto richiesto, Aruba stessa offre un servizio simile
> (almeno a parole), Google, Microsoft,...

ma infatti amazon era un esempio, il datastore di google app engine è
certamente un altro.

> Sara' che non mi piace l'idea di avere i dati miei e dei clienti sparsi
> chissa' dove nel mondo e quindi tutti sti servizi non mi convincono se
> non per un uso casalingo... :P

bah :) se non vado errato twitter e 4square si appoggiano su amazon,
direttamente o indirettamente (4square sempre se non erro tramite heroku).
tanto si può dire su questi servizi tranne che non siano production
grade...

[Jeff]

Io la vedo diversamente.
Per un applicazione (o servizio) che ha bisogno di crescere e di essere sempre performante c'e' bisogno di scalabilita' e la scalabilita' deve poter essere sia in crescita' che in calo e con un servizio cloud (che sia amazon, rackspace, microsoft, godaddy o chiunque) questo puo' essere possibile in modo meno oneroso e soprattutto molto piu' velocemente.
La possibilita' di richiedere risorse a linea di comando solo quando ce ne' la necessita' apre mondi incredibili.

Attualmente io vedo la creazione di una webfarm interna solo come soluzione super corporate nel caso di applicativi e dati che non devono essere pubblicati all'esterno per alcun motivo.

J.


>
> Ciao
>
> --
>
> MMM

[TripleM]

Il 13/11/2012 18:43, Jeff ha scritto:
> ma che tipo di applicazioni hanno necessita' di accesso continuo a tonnelate di storage?

Non so, streaming? email?

Ciao
--
MMM

[TripleM]

Il 13/11/2012 19:40, Leonardo Serni ha scritto:
> E' la definizione di "limite". Se non avesse limiti sarebbe INFINITO, non
> illimitato:-)

Un limite c'e'...

Ciao
--
MMM

[Leonardo Serni]

Nell'ipotesi, non lo puoi raggiungere; non arriva mai il momento in cui trovi
il messaggio "nec plus ultra". Dato che il limite c'e', l'insieme e' finito e
non infinito; ma non raggiungendolo, diciamo che e' "illimitato".

Oh, eventualmente possiamo chiamarlo un insieme "gack" [1] :-)

Leonardo

[1] http://www.baenebooks.com/chapters/1416556028/1416556028___2.htm

[Roberto Tagliaferri]

No.
L'esempio classico è la formica che cammina sul mappamondo: per lei non
esiste un limite ma il mappamondo non è infinito.
Illimitato->Non trovi un limite (no che non c'è.. non lo raggiungi)
Infinito->è di fatto infinitamente grande
>
> Ciao
--
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)tosnet.it
www.robyt.eu

[Jeff]

Per lo streaming ti assicuro che S3 e' una della soluzioni migliori proprio perche' un video non sai mai quanto e' grosso, noi facciamo streaming e usiamo S3 per lo storage e cloudfront (il cdn di amazon) per la fornitura del contenuto.

Un video e' un contenuto statico quindi l'applicazione non lo deve leggere, o parsare o farci qualcosa deve solo dire al browser (o al player, e' la stessa cosa) dove andarselo a prendere, in altre parole il video non "passa" dal web server o per l'applicazione (stessa cosa per eventuali feed live).


Tra l'altro la possibilita' di scalare in automatico ci permette di fornire il servizio di conversione del video (versione hd,ld, per cellulari, per ipad, mp4/flv per rtmp ecc) in parallelo alla fine di ogni upload, quindi se ci sono 2 upload contemporanei abbiamo 2 server per la conversione, se ce ne sono 100 abbiamo 100 server che convertono, poi finita la conversione i server vengono spenti, questo perche' tenere una macchina accesa per 10 ore o 10 macchine per 1 ora ha lo stesso costo.


Ok non so per le email, ma tirando ad indovinare direi che e' piu' o meno la stessa cosa, in fondo le email sono non sono altro che file statici.

J.

[rootkit]

scusa ma è lo stesso discorso di quando vai a fare la spesa al
supermercato: ti pongono un limite su quanta frutta o quanto pane
comperare? chiaramente no (salvo casi particolari come certe offerte
chiamate, appunto, limitate). ne puoi comprare una quantità infinita?
ovviamente no, più di quello disponibile non è possibile comprare. ma
siccome il supermercato rifornisce in modo tale per cui le esigenze tue e
degli altri clienti siano soddisfatte fa in modo che le due condizioni de
facto non si escludano. infatti non ti poni il problema :)

[Ciccio®]

Il 14/11/12 15:23, Leonardo Serni ha scritto:

> Nell'ipotesi, non lo puoi raggiungere; non arriva mai il momento in cui trovi
> il messaggio "nec plus ultra". Dato che il limite c'e', l'insieme e' finito e
> non infinito; ma non raggiungendolo, diciamo che e' "illimitato".

Ragazzi scusate ma ad un certo punto mi sono perso.
Ho un'altra domanda, riguardante il mio caso.

Se volessi fare in modo che dopo tot giorni (o tot spazio riempito nella
cartella) volessi cancellare lo spazio? C'e' un modo per farlo su un ftp?

[Leonardo Serni]

"Cancellare lo spazio" sì. Ma tu vuoi cancellare solo la roba più vecchia di
un tot e/o fino a riportare lo spazio a un certo livello X? In quel caso, ci
vorrebbe uno script non banale. Si puo' fare, ma non so se sia stato fatto.

Leonardo

[TripleM]

Il 14/11/2012 20:39, Jeff ha scritto:
> Ok non so per le email, ma tirando ad indovinare direi che e' piu' o meno la stessa cosa, in fondo le email sono non sono altro che file statici.

Ok, per lo streaming sono andato ad intuito sbagliando, per le mail ti
assicuro che si tratta di un servizio molto stressante per lo storage
trattandosi di centinaia di migliaia di transazioni con file piccoli.
Il piu' grande problema di gestire grandi volumi di mail e' proprio lo
storage...

Per il resto, evidentemente sotto molti aspetti non conoscevo bene le
potenzialita' di S3, anche se rimango della mia idea sull'inutilita' di
fare progetti con spazio "illimitato" (che poi era quello che mi ha
fatto entrare nel thread ^_^), visto che a questo punto anche i costi
saranno "illimitati" :P

Ciao
--
MMM

[Jeff]

Il giorno giovedì 15 novembre 2012 10:25:02 UTC, TripleM ha scritto:
> Il 14/11/2012 20:39, Jeff ha scritto:
>
> > Ok non so per le email, ma tirando ad indovinare direi che e' piu' o meno la stessa cosa, in fondo le email sono non sono altro che file statici.
>
>
>
> Ok, per lo streaming sono andato ad intuito sbagliando, per le mail ti
> assicuro che si tratta di un servizio molto stressante per lo storage
> trattandosi di centinaia di migliaia di transazioni con file piccoli.
> Il piu' grande problema di gestire grandi volumi di mail e' proprio lo
> storage...
>

Ok, ma non vedo alcuna differenza rispetto alla gestione di video.

>
> Per il resto, evidentemente sotto molti aspetti non conoscevo bene le
> potenzialita' di S3,

Ti dico, non e' solo S3 e' in genere l'idea del cloud computing, io lo sto utilizzando da non tanto (circa 1 anno) ma ha completamente cambiato il modo di vedere l'hd e di conseguenza il software. Ora puoi veramente modellare l'hardware sulle necessita' software... (e questo, essendo programmatore, e' male perche' i danni di un ciclo infinito che continua a tirare su server sono inimmaginabili.. hihihihi ;) )

> anche se rimango della mia idea sull'inutilita' di
> fare progetti con spazio "illimitato" (che poi era quello che mi ha
> fatto entrare nel thread ^_^), visto che a questo punto anche i costi
> saranno "illimitati" :P
>

Di fatto tantissimi servizi offrono spazio e banda illimitati, pensa ad esempio a youtube, instagram, photobucket, vimeo, dropbox ecc :D


Io invece ormai non vedo piu' l'utilita' di arrovellarsi a capire quanto storage serva, quanto potente l'hardware o banda o quanto dimensionare il database.. insomma per quel che mi riguarda stiamo salvando un sacco di tempo e denari (quelli l'azienda, non io... ;) )

E questo e' un vantaggio soprattutto per il cliente finale che in diverse situazioni non ha idea delle risorse di cui ha bisogno (o avra' bisogno) e la sua bolletta crescera' con le sue necessita', il prezzario e' decisamente piu' chiaro e comprensibile.
Usi Tot paghi Tot, bom facile.


Poi sono il primo a sostenere che per situazioni particolari e' necessario avere i server in azienda, ma ormai credo sia l'eccezione.


J.

> Ciao
>
> --
>
> MMM

[Jeff]

Il giorno giovedì 15 novembre 2012 10:54:52 UTC, Jeff ha scritto:

Ok ho fallito nell'italiano...

> ....(e questo, essendo programmatore, e' male perche' i danni di un ciclo infinito che continua a tirare su server sono inimmaginabili.. hihihihi ;) )....
>
>

(e questo, essendo programmatore, so che e' male... perche' i danni di un ciclo infinito che continua a tirare su server sono inimmaginabili.. hihihihi ;) )

J.

[TripleM]

Il 15/11/2012 11:54, Jeff ha scritto:
> Ok, ma non vedo alcuna differenza rispetto alla gestione di video.

Ti dico solo che quello che probabilmente e' il piu' grande provider
email in Italia usa lo storage al 50% dell'occupazione, perche'
altrimenti rallenta in maniera mostruosa, dovendo gestire milioni di
file da pochi kb (spesso piu' piccoli di un singolo blocco) in lettura e
scrittura, il numero di IOPS e' piu' alto a parita' di banda utilizzata.

> Di fatto tantissimi servizi offrono spazio e banda illimitati, pensa ad esempio a youtube, instagram, photobucket, vimeo, dropbox ecc :D

Ma infatti loro hanno anche budget praticamente illimitati. Se tu per i
tuoi progetti hai budget illimitato beato te. Sono assolutamente
convinto che quando e' nato youtube avessero ipotizzato al dettaglio
consumo di banda, storage necessario ecc, in funzione al numero di
utenti ipotizzati.

Questo modo di vedere le risorse porta ad uno spreco esagerato, ti
faccio un esempio, volevo virtualizzare il server dove gira il programma
di contabilita' e allo stesso tempo con il loro tecnico si era deciso di
aggiornare all'ultima versione senza chiave fisica.
Alla mia domanda sulla quantita' di risorse necessarie per fare girare
il software (gira solo quello su quel server), mi e' stato risposto
quasi testualmente "RAM, piu' ne metti meglio e', CPU, idem", ecco a
cosa credo che porti il non valutare attentamente le risorse necessarie.
Se non ho idea di quanto storage andro' ad utilizzare e quanta banda,
come faccio a farmi un'idea dei costi che dovro' affrontare e quindi
fare le corrette valutazioni anche sul prezzo di vendita dei servizi
correlati?

> E questo e' un vantaggio soprattutto per il cliente finale

Ma al cliente finale farai un preventivo preciso giusto? e come lo fai
se non sai quanto costera' a te il tutto? (e non avendo la piu' pallida
idea di quante risorse userai non puoi neanche quotarlo)

> non ha idea delle risorse di cui ha bisogno (o avra' bisogno) e la sua bolletta crescera' con le sue necessita'

Sei tu che devi sapere le risorse di cui necessita... Boh, sara' che
sono abituato a clienti "old style" che non accettano un preventivo
sommario che potrebbe crescere o diminuire secondo un criterio che fara'
difficolta' a capire. Se ti commissioni un applicativo che salvi i video
di sorveglianza, a me non interessa sapere quanto storage devo
utilizzare o che protocollo utilizzare, a me interessa sapere quanto mi
costa gestire il tutto e non accetto che mi si dica "dipende da quanti
video registra"... Non sono tenuto a saperlo, io ti dico le mie
esigenze, il tuo lavoro e quotarle e mettere in piedi la soluzione con
dei costi per il cliente finale precisi. Almeno, io la vedo cosi'.

> , il prezzario e' decisamente piu' chiaro e comprensibile.
> Usi Tot paghi Tot, bom facile.

E come fa il cliente a farsi un'idea di quanto gli verra' a costare se
non sa quanto spazio potra' occupare?? e' un cane che si morde la coda,
in questo modo tu stai facendo l'Amazon in piccolo, ma il mio concetto
e' proprio rivolto al cliente finale...

> che per situazioni particolari e' necessario avere i server in azienda

No, non dico in azienda, ma o nel "cloud" o superati certi volumi in
data center... i server pubblici in azienda in un armadiettino da 20
unit senza alcuna ridondanza di alimentazione o portante non li posso
vedere :D

Ciao
--
MMM

[Jeff]

Il giorno giovedì 15 novembre 2012 15:43:40 UTC, TripleM ha scritto:
> Il 15/11/2012 11:54, Jeff ha scritto:
>
> > Ok, ma non vedo alcuna differenza rispetto alla gestione di video.
>
>
>
> Ti dico solo che quello che probabilmente e' il piu' grande provider
>
> email in Italia usa lo storage al 50% dell'occupazione, perche'
>
> altrimenti rallenta in maniera mostruosa, dovendo gestire milioni di
>
> file da pochi kb (spesso piu' piccoli di un singolo blocco) in lettura e
>
> scrittura, il numero di IOPS e' piu' alto a parita' di banda utilizzata.
>

Non vedo perche' questo tipo di cosa non possa essere fatta su un architettura di tipo cloud

> > Di fatto tantissimi servizi offrono spazio e banda illimitati, pensa ad esempio a youtube, instagram, photobucket, vimeo, dropbox ecc :D
>
> Ma infatti loro hanno anche budget praticamente illimitati. Se tu per i
> tuoi progetti hai budget illimitato beato te.

Al contrario io ho budget estremamente limitati e solo l'approccio cloud, ovvero aumento le risorse alla bisogna, ha permesso a diversi progetti che abbiamo di nascere e crescere.

> Sono assolutamente
> convinto che quando e' nato youtube avessero ipotizzato al dettaglio
> consumo di banda, storage necessario ecc, in funzione al numero di
> utenti ipotizzati.
>
>
>
> Questo modo di vedere le risorse porta ad uno spreco esagerato, ti
> faccio un esempio, volevo virtualizzare il server dove gira il programma
> di contabilita' e allo stesso tempo con il loro tecnico si era deciso di
> aggiornare all'ultima versione senza chiave fisica.
>
> Alla mia domanda sulla quantita' di risorse necessarie per fare girare
> il software (gira solo quello su quel server), mi e' stato risposto
> quasi testualmente "RAM, piu' ne metti meglio e', CPU, idem", ecco a
> cosa credo che porti il non valutare attentamente le risorse necessarie.
> Se non ho idea di quanto storage andro' ad utilizzare e quanta banda,
> come faccio a farmi un'idea dei costi che dovro' affrontare e quindi
> fare le corrette valutazioni anche sul prezzo di vendita dei servizi
> correlati?
>

In questo caso crei un server e glielo fai usare, se non e' abbastanza fai lo snapshot del server e rilanci il tutto in un server piu' potente, il tutto completamente trasparente per l'utente e in circa 10 minuti di tempo (qualsiasi fornitore di cloud offre questa cosa in un modo o nell'altrom snapshot o allocamento dinamico di risorse)

>
>
> > E questo e' un vantaggio soprattutto per il cliente finale
>
>
>
> Ma al cliente finale farai un preventivo preciso giusto? e come lo fai
> se non sai quanto costera' a te il tutto? (e non avendo la piu' pallida
> idea di quante risorse userai non puoi neanche quotarlo)
>

Ad esempio se utillizi 200 mega paghi 1 euro, se ne utilizzi 500 paghi 2 euro, dalla un pannello hai le stat dello storage/banda che stai utilizzando, un po' come la lineetta della benzina che cala e ti dice di buttarne ancora dentro.

>
> > non ha idea delle risorse di cui ha bisogno (o avra' bisogno) e la sua bolletta crescera' con le sue necessita'
>
>
>
> Sei tu che devi sapere le risorse di cui necessita... Boh, sara' che
> sono abituato a clienti "old style" che non accettano un preventivo
> sommario che potrebbe crescere o diminuire secondo un criterio che fara'
> difficolta' a capire. Se ti commissioni un applicativo che salvi i video
> di sorveglianza, a me non interessa sapere quanto storage devo
> utilizzare o che protocollo utilizzare, a me interessa sapere quanto mi
> costa gestire il tutto e non accetto che mi si dica "dipende da quanti
> video registra"... Non sono tenuto a saperlo, io ti dico le mie
> esigenze, il tuo lavoro e quotarle e mettere in piedi la soluzione con
> dei costi per il cliente finale precisi. Almeno, io la vedo cosi'.
>

Anche se la struttura e' nel cloud si possono fare piani a quota mica lo vieta nessuno, quindi supponiamo un piano fisso di tot storage, non a cosumo su architettura non cloud e su architettura cloud

Il sistema va in produzione ed in pochi giorni lo storage si riempie perche' anziche' salvare ogni giorno come aveva detto sta salvando ogni ora, che succede?

Non cloud:
Il sistema e' pieno smetti di immagazzinare dati, o cancelli i vecchi, hai comunque una perdita di dati un calo della qualita' del servizio almeno temporanea fino a quando non metti un altro harddisk o storage o quel che sia. Magari va a perdere l'unica registrazione che gli serviva.

So ho un architettura cloud, quando l'utente sfora la quota che si e' stabilito ho un allarme, quindi chiamo l'utente e gli dico: "Hey stai sforando, che vuoi fare? Aumentiamo il piano, vuoi cancellare delle registrazioni, caricarne meno?" ma nel frattempo non sono calate le prestazioni, comunque tutti i dati sono salvati, l'overconsumo a me fornitore non e' costato un granche' e non ho perso alcun dato, poi dopo aver parlato col cliente si chiarisce il dafarsi.

Nel primo caso puoi settare allarmi al 50,80% dello storage, ma significa che hai cmq il 20% di overdimensionamento per il quale sia tu che il cliente pagate senza utilizzarlo.

>> , il prezzario e' decisamente piu' chiaro e comprensibile.
>> Usi Tot paghi Tot, bom facile.
>
>
>
> E come fa il cliente a farsi un'idea di quanto gli verra' a costare se
> non sa quanto spazio potra' occupare??

Gli si dice che uno snapshot occupa per dire 10mega o quel che e', sapendo la telecamera, la risoluzione e si puo' fare una stima piuttosto precisa: oltretutto si puo' anche fare una prova.

> e' un cane che si morde la coda,
> in questo modo tu stai facendo l'Amazon in piccolo, ma il mio concetto
>
> e' proprio rivolto al cliente finale...
>
>

Non faccio l'Amazon in piccolo faccio come fanno tutti quelli che offrono servizi che possono scalare, il fatto che alcuni siano precisamente a consumo altri a vari scaglioni non cambia il concetto. Ad esempio se acquisti un piano se non a consumo hanno vari piani con limiti, per esempio supponiamo di acquistare il piano PRO di Ddropbox, 500$ e 500giga, io no credo allochino sti 500giga per me subito, ma mano a mano che li uso li allocano scalando nella loro struttura cloud, che sia amazon o chicchesia.

Ad esempio anche i benzinai vendono la benzina al litro se gli chiedo quanto mi costa mi dicono, piu' usi l'auto piu' ti costa, ed il venditore di auto mi dice esattamente le stessa cosa.

>
>
>
> > che per situazioni particolari e' necessario avere i server in azienda
>
>
>
> No, non dico in azienda, ma o nel "cloud" o superati certi volumi in
> data center... i server pubblici in azienda in un armadiettino da 20
> unit senza alcuna ridondanza di alimentazione o portante non li posso
> vedere :D
>

Sono daccordo :).. per "in azienda" intendevo in casi in cui si deve avere il 101% del controllo sui dati ed essi non possono transitare su internet

Poi e' chiaro che ci sono situazioni in cui non si puo' sfruttare, come ho scritto qualche giorno fa ogni tanto abbiamo richieste di fornitura del ns software in un server privato bla bla bla e lo si fa nessun problema (ma chissa' quando partono i preventivi per i costi di setup tutti dicono ok per il cloud :) , ma mi raccomando istanza privata.. e questo non c'e' problema [fino a quando noi poveri pigia tasti dobbiamo upgradare tutto alle versioni nuove]! )

J.

PS: non e' che sto facendo una guerra di religione procloud, e' solo che man mano che lo utilizzo ci vedo sempre piu' possibilita' e la possibilita' di avere la potenza hardware su misura ed a richiesta mi piace un casino. E soprattutto non vedo il cloud solo per applicazioni povere.

[Gabriele - onenet]

On Nov 15, 6:55 pm, Jeff <mr.ska...@gmail.com> wrote:
> Il giorno giovedì 15 novembre 2012 15:43:40 UTC, TripleM ha scritto:
>
> > Ti dico solo che quello che probabilmente e' il piu' grande provider
>
> > email in Italia usa lo storage al 50% dell'occupazione, perche'
>
> > altrimenti rallenta in maniera mostruosa, dovendo gestire milioni di
>
> > file da pochi kb (spesso piu' piccoli di un singolo blocco) in lettura e
>
> > scrittura, il numero di IOPS e' piu' alto a parita' di banda utilizzata.
>
> Non vedo perche' questo tipo di cosa non possa essere fatta su un architettura di tipo cloud

Questo thread è interessante e ti faccio una domanda banale: per te
cosa caratterizza una soluzione "cloud"? te lo chiedo perché purtroppo
si vedono tanti fornitori che usano questo termine come fosse uguale a
"hosting/housing" oppure genericamente a "outsourcing", mentre IMHO un
cloud deve avere delle caratteristiche precise che lo differenziano da
altre soluzioni.

Detto ciò, per quanto riguarda la posta elettronica, concordo che sia
molto pesante in termini di hardware perché hai da gestire documenti
di varia dimensione (la maggior parte però piccoli) che vengono
continuamente richiamati dai client e non mi pare vi sia modo agevole
di usare le cache come per i web server.
Parlo ovviamente di IMAP. Tra l'altro, un client IMAP apre per ogni
account almeno 4/5 sessioni e non le chiude subito come per il POP3.

[cut]

>
> Al contrario io ho budget estremamente limitati e solo l'approccio cloud, ovvero aumento le risorse alla bisogna, ha permesso a diversi progetti che abbiamo di nascere e crescere.

Mi incuriosisce l'aver budget limitati con il poter offrire dei
servizi gestiti all'esterno con SLA decenti :)
Soprattutto, i tuoi clienti sanno dove fisicamente sta la loro roba ?

[cut]

> Anche se la struttura e' nel cloud si possono fare piani a quota mica lo vieta nessuno, quindi supponiamo un piano fisso di tot storage, non a cosumo su architettura non cloud e su architettura cloud
>
> Il sistema va in produzione ed in pochi giorni lo storage si riempie perche' anziche' salvare ogni giorno come aveva detto sta salvando ogni ora, che succede?
>
> Non cloud:
> Il sistema e' pieno smetti di immagazzinare dati, o cancelli i vecchi, hai comunque una perdita di dati un calo della qualita' del servizio almeno temporanea fino a quando non metti un altro harddisk o storage o quel che sia. Magari va a perdere l'unica registrazione che gli serviva.
>
> So ho un architettura cloud, quando l'utente sfora la quota che si e' stabilito ho un allarme, quindi chiamo l'utente e gli dico: "Hey stai sforando, che vuoi fare? Aumentiamo il piano, vuoi cancellare delle registrazioni, caricarne meno?" ma nel frattempo non sono calate le prestazioni, comunque tutti i dati sono salvati, l'overconsumo a me fornitore non e' costato un granche' e non ho perso alcun dato, poi dopo aver parlato col cliente si chiarisce il dafarsi.

Veramente anche nel primo caso hai di norma degli alert in anticipo.
Al che chiedi un upgrade e vai avanti.

[CUT]

> Sono daccordo :).. per "in azienda" intendevo in casi in cui si deve avere il 101% del controllo sui dati ed essi non possono transitare su internet

Esistono data center con contratti di virtualizzazione o housing
proprietario e collegamento tutto in VPN, gestito con MPLS dall'ISP.
Proprio oggi ho seguito una presentazione di soluzioni simili ed erano
implementazioni anche complesse, ridondate, multi sede, con SLA
ottime. Ma volendo vanno bene anche per realtà di medie dimensioni.
Certo non sono soluzioni economiche come si vedono in TV :D

Un aspetto che va considerato è quello legale, in alcuni casi è
d'obbligo sapere *dove* stiano i dati aziendali e comunque ritengo che
in caso di controversia sia decisamente più facile agire se sono
almeno in EU :)


ciao
Gabriele

[Jeff]

Il giorno giovedì 15 novembre 2012 19:32:56 UTC, Gabriele - onenet ha scritto:
> On Nov 15, 6:55 pm, Jeff <mr.ska...@gmail.com> wrote:
>
> > Il giorno giovedì 15 novembre 2012 15:43:40 UTC, TripleM ha scritto:
>
> >
>
> > > Ti dico solo che quello che probabilmente e' il piu' grande provider
>
> >
>
> > > email in Italia usa lo storage al 50% dell'occupazione, perche'
>
> >
>
> > > altrimenti rallenta in maniera mostruosa, dovendo gestire milioni di
>
> >
>
> > > file da pochi kb (spesso piu' piccoli di un singolo blocco) in lettura e
>
> >
>
> > > scrittura, il numero di IOPS e' piu' alto a parita' di banda utilizzata.
>
> >
>
> > Non vedo perche' questo tipo di cosa non possa essere fatta su un architettura di tipo cloud
>
>
>
> Questo thread è interessante e ti faccio una domanda banale: per te
> cosa caratterizza una soluzione "cloud"? te lo chiedo perché purtroppo
> si vedono tanti fornitori che usano questo termine come fosse uguale a
> "hosting/housing" oppure genericamente a "outsourcing", mentre IMHO un
> cloud deve avere delle caratteristiche precise che lo differenziano da
> altre soluzioni.
>

Ottimo punto, per cloud intendo una struttura scalabile velocemente alla bisogna che permetta di ottimizzare l'hardware necessario, sia facilmente replicabile, scali assorbendo eventuali picchi e si ridimensioni in caso di non utilizzo per una maggiore efficenza.
Una struttura in cui (leggi permettendo, vedi sotto) tutti i contenuti vengano distribuiti attraverso cdn.
Una struttura che in caso di rottura o disastro in farm mi permetta di tornare online in minuti (sotto l'ora) e che l'hardware possa venire gestito via software

>
> Detto ciò, per quanto riguarda la posta elettronica, concordo che sia
> molto pesante in termini di hardware perché hai da gestire documenti
> di varia dimensione (la maggior parte però piccoli) che vengono
> continuamente richiamati dai client e non mi pare vi sia modo agevole
> di usare le cache come per i web server.
>
> Parlo ovviamente di IMAP. Tra l'altro, un client IMAP apre per ogni
> account almeno 4/5 sessioni e non le chiude subito come per il POP3.
>
>

Come gia' detto non conosco molto bene come un server di posta lavora, ma esattamente perche' un struttura non cloud sarebbe preferibile?

>
> [cut]
>
> >
>
> > Al contrario io ho budget estremamente limitati e solo l'approccio cloud, ovvero aumento le risorse alla bisogna, ha permesso a diversi progetti che abbiamo di nascere e crescere.
>
>
>
> Mi incuriosisce l'aver budget limitati con il poter offrire dei
> servizi gestiti all'esterno con SLA decenti :)
>

Ok, faccio un esempio, fino a qualche tempo fa' non offrivamo il servizio di conversione dei video caricati perche' e' un processo estremamente dispendioso per il processore e va fatto in un server separato rispetto al web server perche' se si rischia di schienare il server.

Quando abbiamo implementato il servizio di distribuzione attraverso RTMP abbiamo dovuto implementare la conversione, quindi abbiamo avuto bisogno di creare un server apposito.

In una situazione "non cloud" sarebbe stato necessario noleggiare o comprare un nuovo server con tutti i costi di upfront per il progetto e non essendo 100% sicuri che fosse un vero valore aggiunto per i clienti (distribuire via rtmp ha vantaggi e svantaggi a seconda dei casi).
Nel caso di una struttura cloud invece richiediamo il server ogni volta che un file viene scelto per la conversione (attualmente tutti i file vengono convertiti in svariate versioni, inizialmente solo quelli scelti per essere distribuiti via rtmp), quindi costo di upfront limitato alla creazione dell'immagine del server e della scrittura del software che si interfaccia con le api (2 giorni di sviluppo), tra l'altro avendo al possibilita' di gestire la coda di conversione molto piu' efficientemente (crei server-> converti-> distruggi server)

Questo e' quello che intendo con una migliore ottimizzazione dei costi.

>
> Soprattutto, i tuoi clienti sanno dove fisicamente sta la loro roba ?
>

Si, sempre. I dati (per AWS) sono o nella zona nella quale crei la risorsa o negli edge server per i dati distribuiti attraverso cdn.

>
> Veramente anche nel primo caso hai di norma degli alert in anticipo.
> Al che chiedi un upgrade e vai avanti.
>

Si lo so, e lo avevo scritto da qualche parte, ma perdi un po' in efficienza

>
>
> [CUT]
>
>
>
> > Sono daccordo :).. per "in azienda" intendevo in casi in cui si deve avere il 101% del controllo sui dati ed essi non possono transitare su internet
>
>
>
> Esistono data center con contratti di virtualizzazione o housing
> proprietario e collegamento tutto in VPN, gestito con MPLS dall'ISP.
>
> Proprio oggi ho seguito una presentazione di soluzioni simili ed erano
> implementazioni anche complesse, ridondate, multi sede, con SLA
> ottime. Ma volendo vanno bene anche per realtà di medie dimensioni.
>
> Certo non sono soluzioni economiche come si vedono in TV :D
>
>

Non ho mai messo in dubbio che esistano soluzioni alternative, sol

>
> Un aspetto che va considerato è quello legale, in alcuni casi è
> d'obbligo sapere *dove* stiano i dati aziendali e comunque ritengo che
> in caso di controversia sia decisamente più facile agire se sono
> almeno in EU :)
>

Il problema non e' sapere dove sono, lo sai sempre in quale farm i dati risiedono, il problema e' quando legalmente i server devono risiedere ijn un determinato paese, per esempio una grossa TV Italiana non puo' migrare al 100% su aws perche' alcuni server devono risiedere in Italia mi pare di ricordare per una questione contabile o qualcosa del genere

>
> ciao
>
> Gabriele

Ciao!

[Manlio Perillo]

Il Wed, 07 Nov 2012 18:35:21 +0100, Ciccio® ha scritto:

> Salve a tutti, possiedo un registratore per videosorveglianza in grado
> di salvare su un ftp delle registrazioni quando rileva un allarme. Per
> fare cio' ho acquistato uno spazio web su aruba. Dopo circa 1 mese mi
> contattano per dirmi questo:
>

Riprendo questo thread per segnalare anche un'altra, più economica,
alternativa ad Amazon S3, Amazon Glacier:
http://aws.amazon.com/glacier/
http://en.wikipedia.org/wiki/Amazon_Glacier

Costa 0.011$ per GB / month.

Ossia un TB di dati ti costa, al cambio attuale, 103€ all'anno.
Con S3 paghi circa 10 volte di più.

Il recuperò dei dati è un pò macchinoso, ma è voluto (Glacier serve per
archiviazione a lungo termine).

Il servizio è stato lanciato il 21 Agosto di quest'anno.


Ciao Manlio

[TripleM]

Il 15/11/2012 18:55, Jeff ha scritto:
> lo storage si riempie perche' anziche' salvare ogni giorno come aveva detto sta salvando ogni ora, che succede?

Cambi lavoro...

Ciao
--
MMM

[TripleM]

Il 15/11/2012 20:32, Gabriele - onenet ha scritto:
> Questo thread è interessante e ti faccio una domanda banale: per te
> cosa caratterizza una soluzione "cloud"? te lo chiedo perché purtroppo
> si vedono tanti fornitori che usano questo termine come fosse uguale a
> "hosting/housing" oppure genericamente a "outsourcing", mentre IMHO un
> cloud deve avere delle caratteristiche precise che lo differenziano da
> altre soluzioni.

Infatti, il termine "cloud" lo trovo molto generico, di fatto qualunque
data center e' gia' un cloud, non credo che il sito microsoft 15 anni fa
girasse su un solo server ed allo stesso tempo non credo che aruba
fornisse un server per ogni dominio.
Forse quello che e' cambiato e' lo strato sofwtare intermedio,
permettendo la virtualizzazione e la teorica espandibilita' del sistema.
Ma parliamo lato utente finale, lato data center cambia poco alla fine,
hai x server che hanno y risorse, fin quando i tuoi clienti occupano il
70/80% di y non hai urgenza di aumentarle, se arrivi al 90% devi
aumentare le risorse. Cioe' come si e' sempre fatto nel mondo
dell'informatica.
Che l'aumentare le risorse sia per te una cosa software o per Amazon una
cosa hardware cambia poco.

> Parlo ovviamente di IMAP. Tra l'altro, un client IMAP apre per ogni
> account almeno 4/5 sessioni e non le chiude subito come per il POP3.

Aggiungi tutti i dispositivi mobile connessi 24/7 che fanno una sessione
ogni 5 minuti, aggiungi tutti i blackberry che fanno una sessione ogni 3
secondi.

> Veramente anche nel primo caso hai di norma degli alert in anticipo.
> Al che chiedi un upgrade e vai avanti.

Il concetto e' sempre lo stesso, in un caso fai un upgrade hardware, in
un altro fai un upgrade commerciale e software.
Certo quello con Amazon e' piu' snello ovviamente, ma cio' non toglie
che una previsione di consumo di risorse e quindi un budget economico lo
devi per forza fare e torniamo al discorso dell'illimitatezza della
richiesta.

Ciao
--
MMM

[TripleM]

Il 16/11/2012 10:19, Jeff ha scritto:
> Ottimo punto, per cloud intendo una struttura scalabile velocemente alla bisogna

[taglio malamente perche' visto che scrivi da Google, genera righe
infinite quando rispondo con il client ed il server news rifiuta se sono
oltre i 79 caratteri]

Secondo me tutto nasce da una differente visuale delle cose. Per avere
un sistema che regge i picchi, le risorse hardware ci devono essere.
Semplicemente quando il picco non c'e' quelle risorse non vengono
utilizzate (ok, vengono riallocate, ma se le risorse non sono superiori
alle esigenze, se ci sono due picchi crolla il castello) e quindi
vengono sprecate.
Te utente finale non sprechi niente, ma te utente finale di fatto non
sprecavi niente neanche nel tuo hosting di 10 anni fa. L'unico risparmio
e' a livello economico, ma per avere un risparmio devi avere fatto un
piano preciso, altrimenti risparmi rispetto a cosa?

Se mettere l'infrastruttura su un cloud pubblico mi costa (esempio) 300k
euro annui, mentre farmi un cloud privato me ne costa 600k (ammortizzati
su 3 anni) preferisco farmelo privato. Per questo ti parlo di
relativita', l'andare su un cloud pubblico o farsi tutto in casa dipende
tutto dai numeri e dalle esigenze, ma per questo *devi* avere una stima
dei numeri e delle esigenze, non puoi dire "ho bisogno di spazio
illimitato", cosi' diventa impossibile fare una scelta ponderata.

> Una struttura in cui (leggi permettendo, vedi sotto) tutti i contenuti vengano distribuiti attraverso cdn.

Qualsiasi storage serio puo' gestire tiering e geolocalizzazione dei
contenuti con repliche e quant'altro.

> Una struttura che in caso di rottura o disastro in farm mi permetta di tornare online in minuti (sotto l'ora) e

L'HA non e' solo ad appannaggio dei cloud pubblici, tendenzialmente
tutti i servizi sono in HA, cloud o non cloud, se hai uno storage devi
avere almeno due teste che lo gestiscono, tutto ridondato, per cui
giusto se ti va a fuoco il data center hai un fermo, altrimenti e' quasi
impossibile che succeda se la struttura e' fatta a modo.

> che l'hardware possa venire gestito via software

Ma questa e' la virtualizzazione, ti prendi VMWare con 3 macchine
fisiche corrazzate come si deve, in HA, e virtualizzi tutto, potendo
fare tutto quello che ti permette di fare Amazon.

> ma esattamente perche' un struttura non cloud sarebbe preferibile?

Tanto per dirne una consigliano *almeno* 4GB di banda tra frontend e
storage (database e file). Non conosco la soluzione Amazon, ma che banda
ti garantisce nel traffico interno? Addirittura Zimbra sconsiglia alcuni
protocolli come NFS, con Amazon ho il controllo sul protocollo utilizzato?

> Questo e' quello che intendo con una migliore ottimizzazione dei costi.

Sui costi lato utente finale e' condivisibile al di sotto di determinate
esigenze, ma mi chiedo, al tuo cliente, fai pagare in base a quante
volte viene creata questa macchina? Se all'improvviso c'e' un picco e la
macchina viene creata 10 volte di piu' del previsto, il costo per il tuo
cliente e' ancora conveniente rispetto ad avere un serverino li virtuale
fisso? (ribadendo il concetto che virtualizzando hai tutto quello che
hai descritto in questa parte)

> Il problema non e' sapere dove sono, lo sai sempre in quale farm i dati risiedono,

Ah si? Interessante... ma quindi sai anche se sono replicati in piu'
farm? Perche' se sono in una sola farm non hai la garanzia di continuita'.

> il problema e' quando legalmente i server devono risiedere ijn un determinato paese

Io ci vedo un altro problema, le leggi sulla privacy in Italia le
conosciamo, siamo sicuri che se per dire Amazon mi fa una farm in India,
le leggi locali non permettano a governo o chissa' chi di mettere le
mani sui miei dati? Stessa cosa per gli USA...

Ciao
--
MMM

[Manlio Perillo]

Il Fri, 16 Nov 2012 16:34:48 +0100, TripleM ha scritto:


>> ma esattamente perche' un struttura non cloud sarebbe preferibile?
>
> Tanto per dirne una consigliano *almeno* 4GB di banda tra frontend e
> storage (database e file). Non conosco la soluzione Amazon, ma che banda
> ti garantisce nel traffico interno? Addirittura Zimbra sconsiglia alcuni
> protocolli come NFS, con Amazon ho il controllo sul protocollo
> utilizzato?
>

Con Amazon EC2 le varie macchine usano un disco locale (non affidabile)
oppure EBS, che a quanto ho letto ha prestazioni abbastanza inaffidabili
per poterlo utilizzare con un database.

> [...]


Ciao Manlio

[Jeff]

Il giorno venerdì 16 novembre 2012 15:34:50 UTC, TripleM ha scritto:
> Il 16/11/2012 10:19, Jeff ha scritto:
>
> > Ottimo punto, per cloud intendo una struttura scalabile velocemente alla bisogna
>
> [taglio malamente perche' visto che scrivi da Google, genera righe
>
> infinite quando rispondo con il client ed il server news rifiuta se sono
>
> oltre i 79 caratteri]
>
>
>

> Secondo me tutto nasce da una differente visuale delle cose, altrimenti risparmi rispetto a cosa?
>


Se li tuo server lavora mediamente al 30% perche' e' dimensionato per assorbire eventuali picchi vuol dire che il 70% e' spreco, di risorse di energia di soldi.
Se il tuo server lavora al 90% non spreca alcunche' ma non riuscira' ad assorbire eventuali picchi senza un notevole calo di prestazioni o crashando.

>
>
> Se mettere l'infrastruttura su un cloud pubblico mi costa (esempio) 300k
> euro annui, mentre farmi un cloud privato me ne costa 600k (ammortizzati
> su 3 anni) preferisco farmelo privato.

Mi stai dicendo che saresti in grado di realizzare la struttura tipo amazon con 600k? Oppure che farti il tuo cloud privato ti costa circa 2 anni di utilizzo su cloud pubblico?

Permettimi di avere qualche dubbio rispetto ad entrambe le ipotesi.

> non puoi dire "ho bisogno di spazio
> illimitato", cosi' diventa impossibile fare una scelta ponderata.
>

E in base a quale principio non puoi fare una scelta ponderata?

In una situazione si cloud computing non interessa, dal punto di vista tecnico, stimare quanti clienti avro', interessa solo capire il costo/cliente che e' una stima estremamente piu' semplice.

>
> > Una struttura in cui (leggi permettendo, vedi sotto) tutti i contenuti vengano distribuiti attraverso cdn.

[CUT]

(ribadendo il concetto che virtualizzando hai tutto quello che
>
> hai descritto in questa parte)
>
>

Ma ho forse scritto che la stuttura di amazon o di qualisiasi cloud computing provider non sia replicabile?

Ad ogni modo se per te e' piu' conveniente fare tutto quello che hai descritto anziche' una chiamata REST per creare la risorsa, libero di farlo.

Per le mie necessita' e' molto piu' conveniente investire tempo nel software.

>
>
>
> > Il problema non e' sapere dove sono, lo sai sempre in quale farm i dati risiedono,
>
>
>
> Ah si? Interessante... ma quindi sai anche se sono replicati in piu'
> farm? Perche' se sono in una sola farm non hai la garanzia di continuita'.

Ma chi ha detto che non son replicati?
Se leggi la documentazione di AWS scopriari cosa e' replicato e cosa no e come.

>
>
>
> > il problema e' quando legalmente i server devono risiedere ijn un determinato paese
>
>
>
> Io ci vedo un altro problema, le leggi sulla privacy in Italia le
> conosciamo, siamo sicuri che se per dire Amazon mi fa una farm in India,
> le leggi locali non permettano a governo o chissa' chi di mettere le
> mani sui miei dati? Stessa cosa per gli USA...

Quindi? chi ti garantisce che in Ita i dati siano piu' sicuri?

>
>
>
> Ciao
>
> --
>
> MMM

[Flavio Bosio]

Il 16/11/12 18.41, Manlio Perillo ha scritto:

> Con Amazon EC2 le varie macchine usano un disco locale (non affidabile)
> oppure EBS, che a quanto ho letto ha prestazioni abbastanza inaffidabili
> per poterlo utilizzare con un database.

Da qualche pessima fonte immagino..

Vedere http://aws.amazon.com/ebs/ per l'introduzione,

per le funzionalità avanzate vedere

http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/AmazonEBS.html

[VisualVision]

Ciccio� ha scritto:
> Salve a tutti, possiedo un registratore per videosorveglianza in grado
> di salvare su un ftp delle registrazioni quando rileva un allarme.
> Per fare cio' ho acquistato uno spazio web su aruba.
> Dopo circa 1 mese mi contattano per dirmi questo:
>

> "Gentile cliente,
> la presente per comunicarLe che, per evitare il possibile blocco del


praticamente hai scoperto che chi ti d� cose "illimitate" alla fine �
una fregatura... :-)

cmq. nel tuo caso la cosa migliore sarebbe salvare i tuoi file
direttamente in un tuo computer. Se dove hai la cam hai spazio per un
modem per la connessione Internet (devi averlo visto che riesci a
mandare questi file in FTP) hai spazio per mettere un computerino, che
so un ee pc o altro piccolo notebook da 10", tengono niente di spazio e
ormai puoi metterci un hard disk da 500GB o superiore senza spendere
granch�.
Fatto questo, se vuoi poter vedere i file remotamente, puoi collegare
questo pc a Internet e installarci sopra per esempio un server FTP
freeware (ce ne sono parecchi)....

ciao


--
www.HyperPublish.com/ita/ Cataloghi, CD e siti con un solo
programma accessibile a tutti!
www.EasyWebEditor.com/ita/ Crea il tuo sito Web
www.CDFrontEnd.com/ita/ Realizza CD, presentazioni
www.PaperKiller.com/ita/ Edita manuali o HTMLHelp, CHM
www.EBooksWriter.com/ita/ Esprimi il tuo talento!
www.visionhost.it Il tuo sito Web!

[Ciccio®]

Il 18/11/12 09:57, VisualVision ha scritto:

> cmq. nel tuo caso la cosa migliore sarebbe salvare i tuoi file
> direttamente in un tuo computer. Se dove hai la cam hai spazio per un
> modem per la connessione Internet (devi averlo visto che riesci a
> mandare questi file in FTP) hai spazio per mettere un computerino, che
> so un ee pc o altro piccolo notebook da 10", tengono niente di spazio e
> ormai puoi metterci un hard disk da 500GB o superiore senza spendere
> granch�.

Forse non ho ben spiegato il senso della mia richiesta.

Lo scopo di avere un backup sull'ftp e' di evitare che un
malintenzionato, entrato nell'abitazione, possa portarsi via i
dispositivi di archiviazione....se cio' accadesse ci sarebbe
l'intoccabile ftp.

[Ciccio®]

Il 15/11/12 09:53, Leonardo Serni ha scritto:

>> Se volessi fare in modo che dopo tot giorni (o tot spazio riempito nella
>> cartella) volessi cancellare lo spazio? C'e' un modo per farlo su un ftp?
>
> "Cancellare lo spazio" sì. Ma tu vuoi cancellare solo la roba più vecchia di
> un tot e/o fino a riportare lo spazio a un certo livello X? In quel caso, ci
> vorrebbe uno script non banale. Si puo' fare, ma non so se sia stato fatto.

Eppure non mi sembra una richiesta tanto originale, qualcuno e' al
corrente dell'esistenza di uno script del genere?

[ga.n]

Nel suo scritto precedente, Ciccio® ha sostenuto :

> Il 18/11/12 09:57, VisualVision ha scritto:

>> cmq. nel tuo caso la cosa migliore sarebbe salvare i tuoi file
>> direttamente in un tuo computer. Se dove hai la cam hai spazio per un
>> modem per la connessione Internet (devi averlo visto che riesci a
>> mandare questi file in FTP) hai spazio per mettere un computerino, che
>> so un ee pc o altro piccolo notebook da 10", tengono niente di spazio e
>> ormai puoi metterci un hard disk da 500GB o superiore senza spendere

>> granché.

> Forse non ho ben spiegato il senso della mia richiesta.

> Lo scopo di avere un backup sull'ftp e' di evitare che un malintenzionato,
> entrato nell'abitazione, possa portarsi via i dispositivi di
> archiviazione....se cio' accadesse ci sarebbe l'intoccabile ftp.

se sono sufficienti gli allarmi delle ultime ventiquattro/quarantotto
ore (e aruba ti permette di schedulare uno script)

puoi mettere su uno script che cancelli i file "vecchi"

a meno che tu non abbia assoluta necessità di andarti a controllare gli
allarmi di sei mesi fa

--
zeitgeist ha uno uno stile pseudo-documentarista che va tanto di moda:
ti copre di illazioni e sentito dire, mischia il vero col possibile e
col falso in un unico calderone e alla fine ti porta alle conclusioni
che vuole l'autore, cosa che va tanto di moda tra i giovini ritardati
che si credono di sinistra di oggi.

[Manlio Perillo]

Il Sat, 17 Nov 2012 18:41:00 +0100, Flavio Bosio ha scritto:

> Il 16/11/12 18.41, Manlio Perillo ha scritto:
>
>> Con Amazon EC2 le varie macchine usano un disco locale (non affidabile)
>> oppure EBS, che a quanto ho letto ha prestazioni abbastanza
>> inaffidabili per poterlo utilizzare con un database.
>
> Da qualche pessima fonte immagino..
>

No, da fonti che usano le instanze EC2 "standard", e non quelle
ottimizzate per EBS.

Infatti vai a vedere i prezzi di Amazon RDS o Heroku PostgreSQL.


Ciao Manlio

[TripleM]

Il 16/11/2012 18:43, Jeff ha scritto:
> Se li tuo server lavora mediamente al 30% perche' e' dimensionato per

Qualcuno sprechera' quelle risorse, per cui il risparmio energetico e'
solo apparente. Anzi, essendoci mille strati software in realta' il
consumo effettivo e' piu' alto di quello che dovrebbe essere solo con
gli applicativi.
Per l'utente finale c'e' un risparmio economico, ma solo sotto
determinati volumi.

> Mi stai dicendo che saresti in grado di realizzare la struttura tipo amazon con 600k?

A parte che ho scritto dei numeri a capocchia solo a titolo
esemplificativo. Con 600k euro tiro su un servizio con i controfiocchi
per quel che puo' servire ad una grande azienda, intorno ai 200k euro
(ribadisco che sono cifre molto, ma molto indicative) mi faccio uno
storage con i controcazzi e decine di Tera di spazio con cache SSD di
centinaia di GB. Con altrettanti 200k euro ti tiri su tranquillamente un
servizio di virtualizzazione in cui mettere in HA (comprese licenze) un
centinaio di server per applicazioni web con 4 core e 4/8GB di RAM. Il
resto metticelo in networking e probabilmente si, con 600k euro tiri
fuori una infrastruttura in grado di soddisfare le richieste della quasi
totalita' di aziende italiane (singolarmente).

> Permettimi di avere qualche dubbio rispetto ad entrambe le ipotesi.

Era un esempio per dire che oltre a determinati volumi il vantaggio
economico dato dal cloud pubblico non giustifica piu' l'utilizzo dello
stesso.

> E in base a quale principio non puoi fare una scelta ponderata?

Previsione di costi? Quale Business Plan puo' essere fatto con un
concetto di "Risorse illimitate"?

> In una situazione si cloud computing non interessa, dal punto di vista tecnico,

Decidiamoci, o parliamo dal punto di vista tecnico o parliamo dal punto
di vista economico.
Se si fa un discorso prettamente tecnico, allora ok, vale il concetto
"piu' risorse ho meglio e'", ma se facciamo un ragionamento a 360 gradi
devi avere delle stime per valutare tutto quanto.

> Ma ho forse scritto che la stuttura di amazon o di qualisiasi cloud computing provider non sia replicabile?

Ti sto continuando a dire che l'usare un cloud pubblico o farsi la
struttura in casa dipende dai volumi e tu continui a negare (non
direttamente) dicendo che conviene sempre il cloud pubblico.
Con questa frase qua per quanto mi riguarda stai ritrattando.

Ti faccio un esempio ragionando per assurdo. Parto dicendo che ho
bisogno di risorse "illimitate", se poi scopro che ho bisogno di una
quantita' di risorse spropositate tanto da occupare una parte
considerevole delle risorse attuali di Amazon? Non pensi che in quel
caso mi sarebbe convenuto farmelo in casa? Senza arrivare a questi
estremi irraggiungibili, ribadisco, ci sono volumi in cui andare sul
cloud pubblico non e' conveniente economicamente e tecnicamente.

Anche a livello di risorse, se ho necessita' di avere un centinaio di
server (virtuali) li faro' magari con 6/7 macchine in HA, di cui
praticamente una sola di spare, per cui spreco meno del 20% di risorse
che pero' sono disponibili in caso di picchi. Preferisco tecnicamente
avere in casa una situazione del genere che affidarmi ad un cloud pubblico.

> Ad ogni modo se per te e' piu' conveniente fare tutto quello che hai descritto
> anziche' una chiamata REST per creare la risorsa, libero di farlo.

Per l'ennesima volta, dipende *tutto* dalla quantita' di risorse
necessarie... per questo dico che il fare un progetto senza sapere la
quantita' di risorse necessarie puo' portare a facili errori.

> Per le mie necessita' e' molto piu' conveniente investire tempo nel software.

Ovvio, a livelli medio-piccoli e' piu' conveniente. (per la stragrande
maggioranza di aziende italiane)

>> Ah si? Interessante... ma quindi sai anche se sono replicati in piu'
>> farm? Perche' se sono in una sola farm non hai la garanzia di continuita'.
>
>
> Ma chi ha detto che non son replicati?

C'e' un punto interrogativo alla fine della mia frase perche' era una
domanda... chiedevo se fosse cosi' o meno...
Quindi realmente tu sai esattamente sempre in quale server farm sta il
tuo singolo dato?

> Se leggi la documentazione di AWS scopriari cosa e' replicato e cosa no e come.

Non ho tempo/voglia/necessita' di leggere tutta la loro
documentazione... rimarro' con il dubbio al momento visto che la
risposta sembra cosi' complessa :P

> Quindi? chi ti garantisce che in Ita i dati siano piu' sicuri?

Le leggi italiane, ogni azienda dovrebbe rispettarle, se non lo fa e me
ne accorgo gli faccio passare i guai, se lo fa una azienda con i server
nelle isole Tuvalu, come faccio a farmi rimborsare dei danni subiti da
un eventuale problema?
Se ho queste necessita' posso farmi dire dettagliatamente dal fornitore
quali misure utilizza per la sicurezza, a quanto ho capito il DPS non
sara' piu' obbligatorio, ma il concetto rimane. In Italia so a quali
leggi deve sottostare chi mi fornisce il servizio, fuori dall'Italia e
dall'Europa diventa piu' complesso capirlo e conciliare con quelle a cui
devo sottostare io.


Ciao
--
MMM

[Flavio Bosio]

Il 19/11/12 18.08, Manlio Perillo ha scritto:

> Il Sat, 17 Nov 2012 18:41:00 +0100, Flavio Bosio ha scritto:
>
>> Il 16/11/12 18.41, Manlio Perillo ha scritto:
>>
>>> Con Amazon EC2 le varie macchine usano un disco locale (non affidabile)
>>> oppure EBS, che a quanto ho letto ha prestazioni abbastanza
>>> inaffidabili per poterlo utilizzare con un database.
>>
>> Da qualche pessima fonte immagino..
>>
>
> No, da fonti che usano le instanze EC2 "standard", e non quelle
> ottimizzate per EBS.

Quindi la "pessima fonte" non è in grado di entrare nella EC2 Management
Console, selezionare Volumes, Create Volume, selezionare Volume Type da
"standard" a "Provisioned IOPS", inserire l'IOPS desiderato, attendere
qualche istante che si crei il volume, cliccarci sopra, selezionare
Attach Voleme collegandolo alla propria istanza

Una volta connesso, non è in grado fare un fdsik -l per vedere come è
stato mappato il nuovo volume, formattarlo, montarlo, copiare il
contenuto di /var/lib/mysql verificandone i permessi, smontarlo, fare un
mv /var/lib/mysql /var/lib/mysql_old, fare un mkdir /var/lib/mysql,
inserire in /etc/fstab il nuovo volume da montare sotto /var/lib/mysql e
lanciare il comando mount?

Trasferire MySQL su un volume ultra performante ed ultra affidabile
richiede 5 minuti di lavoro ad un professionista.

Evidentemente la "pessima fonte" defice anche delle più banali
conoscenze sistemistiche se non è in grado di farlo da se, oppure ha un
interesse economico diretto a venderle un proprio prodotto/servizio?

> Infatti vai a vedere i prezzi di Amazon RDS o Heroku PostgreSQL.

Lasciamo perdere và che è meglio...

[Flavio Bosio]

Il 19/11/12 09.39, Ciccio® ha scritto:

Dovremmo sapere:

1) se il server è FTP o FTPS
2) se archivia i file creando un albero directory o direttamente in /
3) il nome dei file (se usa un formato datetime o altro)

un semplice script dovrebbe:

1) connettersi al server FTP/FTPS passando le credenziali
2) scaricare la lista dei file disponibili in un file locale
3) parsare il contenuto del file locale per individuare cosa eliminare e
cosa no
4) eliminare i file non più necessari

[Ciccio®]

Il 19/11/12 12:50, ga.n ha scritto:

> se sono sufficienti gli allarmi delle ultime ventiquattro/quarantotto
> ore (e aruba ti permette di schedulare uno script)
>
> puoi mettere su uno script che cancelli i file "vecchi"

E' proprio quello che mi serve, il problema e' avere questo script...

[Jeff]

Il giorno lunedì 19 novembre 2012 17:44:55 UTC, TripleM ha scritto:
> Il 16/11/2012 18:43, Jeff ha scritto:
>
>
> Per l'utente finale c'e' un risparmio economico, ma solo sotto
> determinati volumi.

Ma il 30% e' sempre il 30% sia a bassi che alti volumi, no?

>
> > Mi stai dicendo che saresti in grado di realizzare la struttura tipo amazon con 600k?
>
>
>
> A parte che ho scritto dei numeri a capocchia solo a titolo
> esemplificativo. Con 600k euro tiro su un servizio con i controfiocchi
> per quel che puo' servire ad una grande azienda, intorno ai 200k euro

> ... [cut] (singolarmente).
>

Ribasisco, non ho negato da alcuna parte che si possa fare,
ma ti conviene questa cosa?

>
> > E in base a quale principio non puoi fare una scelta ponderata?
>
> Previsione di costi? Quale Business Plan puo' essere fatto con un
> concetto di "Risorse illimitate"?
>

Ma parli di business plan per l'azienda che fornisce il servizio
o di budget per il cliente?

>
> > In una situazione si cloud computing non interessa, dal punto di vista tecnico,
>
> Decidiamoci, o parliamo dal punto di vista tecnico o parliamo dal punto
> di vista economico.
>
> Se si fa un discorso prettamente tecnico, allora ok, vale il concetto
> "piu' risorse ho meglio e'", ma se facciamo un ragionamento a 360 gradi
> devi avere delle stime per valutare tutto quanto.
>
>

Nel business plan del fornitore del servizio si inserisce costo della
risorsa 10 al giga, prezzo di vendita 20 al giga.
Quindi se ne vendo 30 avro' un costo di 300 ed un incasso di 600.

Nel budget del cliente si mette allocazione di 600 per il servizio
Pinco che mi permette di usare fino ad un massimo di 30.

>
> > Ma ho forse scritto che la stuttura di amazon o di qualisiasi cloud computing provider non sia replicabile?
>
> Ti sto continuando a dire che l'usare un cloud pubblico o farsi la
> struttura in casa dipende dai volumi e tu continui a negare (non
> direttamente) dicendo che conviene sempre il cloud pubblico.
> Con questa frase qua per quanto mi riguarda stai ritrattando.
>
>

Dicendo che una cosa non conviene mica dico che non sia possibile
farla, dove sta la logica di questa deduzione?
(Ovviamente se dico che una cosa e' possibile farla, mica intendo
che sia conveniente da fare)

Se dico non mi conviene comprare alla Coop, non sto dicendo che
non si possa comprare alla Conad e nemmeno che non si possa
mettere su una rete di GDO personale.

Ad ogni modo io nego anche direttamente che la convenienza dipende
dai volumi, perche' se realta' grossissime usano cloud pubblici
(esempio NetFlix, Pintrest, Spotify, MTV ita usano AWS; Avelo,
Virgin Trains sono invece con RackSpace) una ragione ci sara'.

>
> Ti faccio un esempio ragionando per assurdo. Parto dicendo che ho
> bisogno di risorse "illimitate", se poi scopro che ho bisogno di una
> quantita' di risorse spropositate tanto da occupare una parte
> considerevole delle risorse attuali di Amazon? Non pensi che in quel
> caso mi sarebbe convenuto farmelo in casa? Senza arrivare a questi
> estremi irraggiungibili, ribadisco, ci sono volumi in cui andare sul
> cloud pubblico non e' conveniente economicamente e tecnicamente.
>

No, non credo perche' la complessita' dell'architettura hardware e di rete
sarebbe tale da non giustificare l'eventuale risparmio economico che, tra
l'altro, e' tutto da dimostrare visto che dovrei farmi carico di rotture
ed invecchiamento delle macchine ad esempio.

>
>
>
> > Ad ogni modo se per te e' piu' conveniente fare tutto quello che hai descritto
> > anziche' una chiamata REST per creare la risorsa, libero di farlo.
>
>
>
> Per l'ennesima volta, dipende *tutto* dalla quantita' di risorse
> necessarie...

Non penso sia piu' semplice montare un apparato fisico (perche' stavamo
parlando di creare piu' risorse, quindi non e' aggiungere una macchina virtuale,
ma creare potenza di calcolo o mememoria o quello che e') che fare una
chiamata REST in alcun case e poi ribadisco c'e' sempre la possibilita' che
per interi periodi non di abbia bisogno dell'intera struttura e quindi sia
il caso di scalare al ribasso per qualche mese.. che faccio vendo i server?

>
>
> > Per le mie necessita' e' molto piu' conveniente investire tempo nel software.
>
> Ovvio, a livelli medio-piccoli e' piu' conveniente. (per la stragrande
> maggioranza di aziende italiane)
>
>

No, e' piu' conveniente per le software house. Il fatto che ci siano
software house si occupino anche di creare l'apparato hd e' un altro discorso.

>
> >> Ah si? Interessante... ma quindi sai anche se sono replicati in piu'
> >> farm? Perche' se sono in una sola farm non hai la garanzia di continuita'.
>
> >
> >
>
> > Ma chi ha detto che non son replicati?
>
>
> C'e' un punto interrogativo alla fine della mia frase perche' era una
> domanda... chiedevo se fosse cosi' o meno...
>
> Quindi realmente tu sai esattamente sempre in quale server farm sta il
> tuo singolo dato?
>

Si. Ovviamente i dati di servizi multi az sono replicati in giro per le
zone o per gli edge server.


Ciao

J.

>
>
>
> Ciao
>
> --
>
> MMM

[Manlio Perillo]

Il Tue, 20 Nov 2012 08:59:36 +0100, Flavio Bosio ha scritto:

> Il 19/11/12 18.08, Manlio Perillo ha scritto:
>> Il Sat, 17 Nov 2012 18:41:00 +0100, Flavio Bosio ha scritto:
>>
>>> Il 16/11/12 18.41, Manlio Perillo ha scritto:
>>>
>>>> Con Amazon EC2 le varie macchine usano un disco locale (non
>>>> affidabile) oppure EBS, che a quanto ho letto ha prestazioni
>>>> abbastanza inaffidabili per poterlo utilizzare con un database.
>>>
>>> Da qualche pessima fonte immagino..
>>>
>>>
>> No, da fonti che usano le instanze EC2 "standard", e non quelle
>> ottimizzate per EBS.
>

> [...]

>
> Evidentemente la "pessima fonte" defice anche delle più banali
> conoscenze sistemistiche se non è in grado di farlo da se, oppure ha un
> interesse economico diretto a venderle un proprio prodotto/servizio?
>

Si, come lo staff di Reddit...
http://blog.reddit.com/2011/03/why-reddit-was-down-for-6-of-last-24.html


Ciao Manlio

[Flavio Bosio]

Il 20/11/12 19.17, Manlio Perillo ha scritto:

>> Evidentemente la "pessima fonte" defice anche delle più banali
>> conoscenze sistemistiche se non è in grado di farlo da se, oppure ha un
>> interesse economico diretto a venderle un proprio prodotto/servizio?
>>
>
> Si, come lo staff di Reddit...
> http://blog.reddit.com/2011/03/why-reddit-was-down-for-6-of-last-24.html

Che evidentemente all'epoca dei fatti non disponeva di un Disaster
Recovery Plane dato che hanno avuto la pessima idea di implementare
l'intera architettura in un unica zona.

Semplicemente replicando tra diverse zone avrebbero risolto il problema
in 10 secondi

Vedi anche: http://tinyurl.com/chkrnfr

[ga.n]

Ciccio® scriveva il 20/11/2012 :

che linguaggio di programmazione supporta il tuo spazio web?
(presumo php)

che budget hai?

--
se devi ascoltare i transtienti,valutare la spazialità, ricercare se
gli ottoni sono al loro posto e le soprane sono messe nella giusta
posizione nel coro allora trast = cacca
se devi andare a core e sentire gli mp3 scarricati da yutube senza
spendere fottilioni alura trast va bene e yogur è un cogl1

[Ciccio®]

Il 21/11/12 12:47, ga.n ha scritto:

>> E' proprio quello che mi serve, il problema e' avere questo script...
>
> che linguaggio di programmazione supporta il tuo spazio web?
> (presumo php)
>
> che budget hai?

Si php, budget? 50 euro bastano?
E come si fa ad aviarlo in automatico ogni tot tempo?