Twenty people showed up. Around half of them were new to Gluster and evaluating its adoption, while the other half comprised people with previous Gluster experience, from the novice up to the software-defined storage professional from Red Hat Italy.
In the morning there have been three tech talks. Niels presentation started from an introduction to Gluster, going through some of the latest features of the just-released Gluster 4.0, and finished illustrating what to expect from the 4.x road map. Marko did a live demo of gluster-colonizer , a brand new Ansible-based project to automatically provision Gluster clusters. Jiffin talked about what the duties of a release maintainer are, and did a live release of Gluster 3.12.
In the afternoon I did my part by illustrating most of the use cases I addressed as a consultant, while Ramon Selga from Datalab gave the audience a lot of information about disperse volumes and how to host virtual machines within Gluster volumes. Both sessions included lively discussion and questions from the audience. I liked it.
Being a first, I think the event has been a success.
Will there be another one? Possibly, if the community will keep showing interest. Although it would be nice to have a larger fraction of the attendance coming from outside Italy.
]]>Last few days has been tense since a R3 3.8.5 Gluster cluster that I built has been plagued by problems.
The first symptom has been a continuous stream in the client logs of messages like:
[2016-12-17 15:55:02.047508] E [MSGID: 108009] [afr-open.c:187:afr_openfd_fix_open_cbk] 0-prod-1-replicate-0: Failed to open /galaxy/java/lib/java/jre1.7.0_51/jre/lib/rt.jar on subvolume prod-1-client-2 [Transport endpoint is not connected]
together with very frequent peer disconnections/reconnections and a continuous stream of files to be healed on several volumes.
The problem has finally been traced back to a flaky X540-T2 10GBE NIC embedded in one of the peers motherboard. The thing was incapable of keeping the correct 10Gbit speed negotiation with the switch.
The motherboard has been replaced on the peer and, after that, the volumes healed quickly to complete health. In the meantime, the users kept running some heavy-duty bioinformatics applications (NGS data analysis) on top of Gluster. No user noticed anything, despite a major hardware problem and the off-lining of a peer.
This is a RESILIENT system, in my book.
Despite the constant stream of problem reports and requests for help that you see on both the ML and IRC, rest assured that you are building a nice piece of software, at least according to my experience.
Keep-up the good work and Merry Christmas.
Ivan Rossi
PS I have the strong feeling that people running Gluster in a cloud environment will have experiences like this one more time that they would like. But it is not Gluster fault, IMHO.
]]>Gluster è un file system distribuito, che permette di aggregare in un unico file system di rete, le risorse fornite da un insieme di server, detti "peers", interconnessi tramite rete RDMA o TCP/IP, accessibile via client nativo, NFS e CIFS.
Una caratteristica saliente di Gluster è quella di non avere "single point of failure" in quanto basato su un architettura peer-to-peer: è possibile accedere ai dati sia in lettura che in scrittura da uno qualunque dei "peers" del cluster.
Nel caso in questione, un cluster di tre peers (macchine virtuali) salva i dati in triplice copia, conferendo al sistema una notevole resistenza sia ai guasti che ai picchi di carico. Inoltre i dati vengono replicati, in modalità asincrona ma continua, su un secondo Gluster cluster facente parte di una infrastruttura gemella localizzata in un secondo data center, pronta a subentrare in caso di guasti sul data center primario.
Il sistema è flessibile ed espandibile: aggiungendo risorse al cluster è possibile aumentare la capacità del sistema sia in termini di capacità di storage che di performance.
]]>Perché: L'infrastruttura informatica di un'azienda deve rendere al massimo, senza tempi morti, e senza sprechi, poiché essa – in un'impresa moderna che sfrutti al massimo le possibilità offerte dall'automazione dei processi – è l'unico tramite per erogare beni e servizi.
Come: Utilizzando sistemi basati su software libero e standard aperti: GNU/Linux (nelle distribuzioni Debian, Ubuntu, CentOS) come sistema operativo, software per la realizzazione di infrastrutture di virtualizzazione (Ganeti, KVM, OpenNebula), software per la gestione di grandi moli di dati (GlusterFS, NFS, GPFS) e software per la creazione delle necessarie componenti intermedie (OpenVPN, Openswitch, OGS e altro).
]]>I requisiti principali richiesti all'infrastruttura sono l'affidabilità, la disponibilità 24x7, la flessibilità e l'espandibilità.
Abbiamo realizzato l'infrastruttura in questione utilizzando le seguenti componenti:
Hardware: una coppia di server Linux dotati 16-core Intel e 30 TB di spazio disco cadauno, interconnessi da una rete a 10 Gigabit, che svolge le funzioni di service network, oltre alla tradizionale rete ethernet gigabit.
Software: abbiamo accoppiato un sistema di "private cloud" (Ganeti) con un sistema di "software-defined storage" (Gluster). Entrambi questi componenti sono software open-source liberamente disponibile.
Ganeti è un software open-source sviluppato da Google che si definisce un "gestore di cluster di server virtuali". Utilizza le tecnologie di virtualizzazione Xen e KVM e il sistema di storage (RAID1 su ethernet) DRBD. Ganeti è stato progettato per facilitare la gestione dei cluster di server virtuali e per fornire il recupero veloce e semplice in caso di guasti fisici e per utilizzare "commodity hardware".
Gluster è un file system distribuito, che permette di aggregare assieme le risorse fornite da un insieme di server, detti "storage building blocks", interconnessi tramite rete Infiniband o TCP/IP, in un unico filesystem di rete (NAS virtuale).
La caratteristica saliente di entrambi i sistemi software utilizzati rispetto ad altri software con funzionalità simili è quella di non avere "single point of failure" in quanto entrambi sono basati su un architettura peer-to-peer, in cui qualunque dei peer è in grado di assumere funzioni di master. Inoltre sia le macchine virtuali (Ganeti-DRBD) che i dati da distribuire (Gluster) sono replicati in doppia copia. Tutto ciò conferisce al sistema una notevole resistenza ai guasti.
Il sistema è anche flessibile ed espandibile: aggiungendo nuovi server alla service network è possibile aumentare la capacità del sistema sia in termini di capacità di storage che computazionale. O di rimpiazzare una componente divenuta obsoleta con una più moderna (funzionalità, questa, che la distingue in modo netto da soluzioni tradizionali come le SAN monolitiche, ad esempio).
L'utilizzo di macchine virtuali permette inoltre un processo di evoluzione del software di distribuzione dei dati molto naturale, in quanto è possibile sviluppare e testare nuove componenti sulla stessa infrastruttura che contiene l'applicazione di produzione.
]]>