<p dir="ltr">Purtroppo non posso aiutarti</p>
<p dir="ltr">Il 04/nov/2015 23:40, "Tasslehoff Burrfoot" <<a href="mailto:tasslehoff@burrfoot.it">tasslehoff@burrfoot.it</a>> ha scritto:<br>
><br>
> Buonasera a tutti, lavoro da anni presso il datacenter di un cliente (PA) dove ho un gestione parecchi sistemi ad elevata criticità; da un po' di tempo a questa parte la tendenza è quella a virtualizzare qualunque cosa consolidando un datacenter storico e composto da tante macchine indipendenti su blade con storage in san tendenzialmente performanti.<br>
> Come è facilmente immaginabile uno dei problemi storici che stiamo riscontrando è la disponibilità di storage, non tanto in chiave qualitativa (stiamo curando con particolare attenzione la distribuzione del carico sui datastore per ridurre l'impatto prestazionale dovuto a troppo carico di I/O) quanto quantitativa, questo perchè come spesso accade il cliente tende a considerare solo storage ad elevate prestazioni (SAS 15k FC, per ora non SSD ma solo per i costi proibitivi su larga scala) e a scartare a priori storage "quantativo" magari meno performante.<br>
><br>
> Avendo però a che fare con parecchie vm vorremmo implementare anche un piano di disaster recovery che vada oltre dei semplici backup fatti lato guest, ma che includa backup periodici delle vm oppure backup bare metal dei server fisici, in modo da ridurre le finestre temporali di restore in caso di disastro "serio".</p>
<p dir="ltr">Il disaster ricovery però non è solo la disponibilità del dato, ma la sua riallocazione su altre macchine e non opzionalmente in un sito diverso. È quindi uno scenario che giocoforza prevede un approccio progettuale con focus allineamento dati e dei requisiti su tempi e modi espressi dal Cliente. Qualunque altra soluzione, comprese le citate che non conosco, sono un irrobustimento del backup o una maggiore resilienza della piattaforma di erogazione attuale.<br></p>
<p dir="ltr">> Chiaramente per fare questo occorre tanto storage non necessariamente ultra performante, trattandosi di PA però la fornitura di hw è molto lenta, macchinosa e dipendente da meccanismi burocratici gargantueschi.<br>
> Per questo motivo mi stavo documentando per implementare un repository basato su filesystem distribuito che permettesse di riciclare i vecchi server o le vecchie SAN (ormai ampiamente ammortizzati) da usare per questi backup bare metal, backup delle vm o dei vari repository usati dai tanti progetti ormai migrati a hw più recente e in molti casi virtualizzati.<br>
><br>
> In rete ho letto che è possibile implementare una soluzione simile tramite glusterfs, qualcuno ha esperienza in merito e può farmi un feedback sull'affidabilità di questa soluzione?<br>
> Non trattandosi di un utilizzo mission critical (i normali backup continuerebbero comunque a girare tramite i normali canali con Tivoli Storage Manager e EMC Networker) non prevedo esiti catastrofici in caso di down di un nodo o dell'intero repository, si tratterebbe in sostenza di un backup supplementare per garantire un miglior servizio.<br>
><br>
> Pareri?<br>
><br>
> Grazie<br>
><br>
> Tas<br>
></p>
<p dir="ltr">Ciao, Alessandro </p>
<p dir="ltr">> ---<br>
> "Così continuiamo a remare, barche contro corrente,<br>
> risospinti senza posa nel passato"<br>
> ---<br>
> Public PGP key block at<br>
> <a href="http://tasslehoff.burrfoot.it/url/pgp">http://tasslehoff.burrfoot.it/url/pgp</a><br>
><br>
><br>
> --<br>
> Sito BgLUG: <a href="http://www.bglug.it">http://www.bglug.it</a><br>
> Mailing list: <a href="http://lists.linux.it/listinfo/bglug">http://lists.linux.it/listinfo/bglug</a><br>
</p>