Il 28/01/23 08:32, Marco Giustini ha scritto:
[...]c'è un abisso di affidabilità che separa il servizio fornito da Libero da quello fornito da Google.[...]
La modalita' con la quali eroghi un servizio è un elemento fondamentale dei livelli di affidabilita' dello stesso.
In altri termini: posso scegliere di servire la posta elettronica in una modalita'.... e avro' vantaggi/svantaggi (e costi... e rischi), oppure posso sceglierne un'altra (con altri vantaggi, svantaggi, costi, rischi).
Ho gestito personalmente (e praticamente "da solo") una infrastruttura di posta di media complessita' per oltre 15 anni. L'ho trovata che erano meno di 1000 caselle su un singolo server (sendmail) con account di sistema (era il 2003).
L'ho lasciata (2021) che era su 10 server (VM), 3500 mailbox, con 15TB di storage "netto" ed altre cosettine...
Non lo dico per dire: "Ero bravo!".Lo dico per dire che... il tempo "passa"... le esigenze utente "crescono" (e ~6/7 anni fa, la mailbox era fondamentale piu' di oggi, in un Ateneo) e, soprattutto, la tecnologia "avanza".
Ho pianificato e implementato personalmente _TRE_ upgrade "massicci" dell'intera infrastruttura (di cui gli utenti NON si sono mai accorti). Non è stato mai "facile". Erano operazioni da "notti insonni".
Vengo al punto.Io avevo "solo" 15TB di caselle. Penserete: "15T? Solo? ...stanno su un disco S-ATA da 20TB!". Eppure, quando "ci lavori" (_SE_ ci lavori!), capisci che il Backup "full", off-site, delle mailbox, su nastro... richiede _OLTRE_ 24 ore. Quando lo capisci... allora _DEVI_ prendere una decisione: "che succede se devo fare un restore [dei soli dati]? Quanto tempo mi serve?". Ed inoltre: "Che succede se SERVER e STORAGE vanno KO, e devo ripristinare il servizio DA ZERO?". Sono concetti BASILARI (i tecnici li chiamano RTO e RPO) che --se sei "serio"-- _DEVI_ considerare.
Poi diventa un problema "politico" (di strategia aziendale): vai dal manager e gli dici: "Giovane! Guarda che se tutto va a rotoli, cosi' come siamo messi NON siamo in grado di ripartire prima di N ore/giorni. Che dobbiamo fare?". Ed il manager (il cui stipendio è funzione dell'importanza delle sue decisioni) decide.
Sempre sul punto... Se dovessi allestire una piattaforma _GROSSA_ (...e gia' quella di un singolo Ateneo, per me, è GROSSA), il concetto di Backup _NON_ è applicabile. Punto. Ed è li che, a mio parere, i "nuovi" attori (Google e Microsoft in primis) hanno fatto la scelta giusta: cambiare "modello". Utilizzare storage "a basso costo", ma con livelli di ridondanza tali per cui lo storage, di fatto, non lo perdi (al piu', ne perdi un pezzo... che comunque è replicato N volte [N >= 5, ad esempio] altrove).
Se dai per scontato che lo storage ti assiste (prendendoti la responsabilita' di tale assunzione)... e non puoi perderlo... a quel punto tutto cambia. Il concetto di "backup" diventa semplicemente implementabile con qualcosa di simile agli snapshot, che poi, comodamente, mandi off-site (senza fermare il servizio).
Tutto questo, pero', comporta che: * devi implementare una soluzione di software-defined-storage (come CEPH, ad esempio), che... magari oggi in diversi conoscono, ma che comunque i "tuoi tecnici" _DEVONO_ studiarsi e imparare a gestire; * devi "inventarti" una infrastruttura "fisica" a supporto (i dischi, da qualche parte, li devi pure infilare...). E' meglio un DELL 740-XD (che poteva ospitare --un solo server-- 14 dischi), oppure è meglio prendere 6 server piu' piccoli, ognuno con tre dischi? Sembra una domanda banale ma.... _NON_ c'e' un "manuale" che te lo dice. _NON_ c'e' un "corso di laurea che te lo insegna". _NON_ c'e' un "collega" che ti aiuta. Sei _TU_. Da solo. Che _DEVI_ spendere N ore (N dell'ordine del centinaio) per... "capire" cosa fare. "Sapro' farlo?", "Funzionera'?". Sono domande che --se sei "responsabile"-- ti fanno fare qualche notte insonne.Capite bene che è molto piu' semplice.... aprire il portafoglio, comprare una bella unita' di storage "classica", con relativo contratto di supporto e... chi s'e' visto s'e' visto.
Credo sia _esattamente_ quello che è capitato loro. Lo storage "classico"... è andato KO... ed il backup "classico" mostra tutti i suoi limiti.
Insomma (e chiudo): non trovo corretto confrontare gli SLA di GMAIL con quelli di Libero. NON stiamo parlando della stessa cosa. Datemi la possibilita' di lavorare con tre/quattro persone "a cui piace non-dormire la notte", datemi un manager che è guidato dalla spinta "politica" di innovare e far crescere "il sistema" e... allestire una piattaforma di posta che abbia SLA del 99,9999%, sara' possibile. Oggi, tra l'altro, non bisognerebbe neanche inventarsi nulla: è praticamente gia' pronta [1].
Non serve la "tecnologia"; servono "manager" che hanno la voglia di implementarla. Diversi da quelli di Libero (che --ricordo-- _DEVONO_ fare "business"; qui, invece, parliamo di altro).
Un saluto, DV [1] https://www.youtube.com/watch?v=uA775icp-kk -- Damiano Verzulli e-mail:dami...@verzulli.it --- possible?ok:while(!possible){open_mindedness++} --- "...I realized that free software would not generate the kind of income that was needed. Maybe in USA or Europe, you may be able to get a well paying job as a free software developer, but not here [in Africa]..." -- Guido Sohne - 1973-2008 http://ole.kenic.or.ke/pipermail/skunkworks/2008-April/005989.html
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
