Lors de la préparation initiale de ScaleIO (voir ce premier billet), on a installé l’ensemble des packages, dont le SDS évidemment, mais aussi la partie cliente, SDC. A l’issue, tous nos noeuds sont hybrides SDS/SDC. Afin de commencer à se familiariser avec l’administration de ScaleIO (qui se passe, pour l’essentiel via ligne de commande), je vous propose d’y aller pas à pas et d’expliquer chacune des commandes. Rassurez-vous, dans ce billet, vous aurez l’impression que je maîtrise déjà la bête, ce qui est faux évidemment, mais rappelez-vous que j’ai passé quelques heures à découvrir le produit, lire la doc et faire plusieurs essais et bidouilles avant de vous proposer ce scénario “lissé” :)

On se lance ?

Par défaut, comme vous pouvez le voir ci-dessous, nous partons d’un SDS de 3 noeuds où sont déjà définis un “protection domain” (je ne rentrerai pas dans le détail de ce concept dans ce billet, il nous en faut au moins un, c’est cas, pour l’instant ça nous suffit) et un storage pool (un groupe de serveurs SDS). Au total nous disposons de 200 Go utilisables (100 Go étant dé-facto réservé à la protection des données écrites) :

Pour la clarté de la présentation, j’ai renommé, via la GUI, le cluster en “scaleio”, le protection domain en “poc” et le pool créé par défaut en “pool0” :

Première chose à faire, découvrir un peu plus en détail notre “environnement” via des commandes sur le MDM.
D’abord, on se loggue sur le MDM :

Ensuite quelques commandes de type “query”, comme la liste des SDS :

… la liste des SDC (3 pour l’instant, comme indiqué précédemment) :

… Ok, donc tout cela parait cohérent. Histoire que les commandes suivantes soient plus claires, je vous propose de renommer nos SDS et SDC par leur nom de host :

… on fait de même pour les SDC :

Notre petit cluster est prêt pour commencer à bosser. Nous allons d’abord créer un nouveau volume de 30 Go :

>

Ensuite, on va l’affecter au client SDC ionode1 (la machine qui fait également office de MDM primaire) :

En retournant sur la GUI, on constate qu’effectivement, le nouveau volume est bien là et mappé sur un de nos clients :

Il en nous reste plus qu’à préparer et utiliser notre volume. On passe donc du coté “client”. Première chose, faire un rescan sur le driver ScaleIO :

Notre driver ScaleIO SDC a bien détecté le nouveau volume. Maintenant, c’est coté OS client que ça se passe. Sous Linux, les devices ScaleIO sont identifiés par des /dev/sciniX. On va donc tout simplement inspecter ça (là les linuxiens ne seront pas perdus), trouver le nouveau volume, le formatter et le monter !

C’est terminé, le filesystem est monté et opérationnel. Avant de publier ce billet, j’ai fait quelques petits tests rapides que je vous livre “brut de décoffrage” comme on dit :

J’ai également réalisé des copies de petits de fichiers divers (copy de toute la hiérarchie “/usr” d’un de mes Linux vers le volume ScaleIO). Tout cela se comporte très bien. En supplément, voici une petite série de copies d’écran de la GUI pendant les copies et tests divers zé variés :

Enfin, histoire de tester un peu la robustesse du système, j’ai tout simplement rebooté un des noeuds. Le cluster s’est un peu “affolé” pendant quelques temps, mais j’ai pu constater une certaine forme d’admiration toute “geek” que celui-ci a tout de suite commencé à reconstruire les données manquante pour retrouver au plus vite la “double-copie” de chaque bloc de donnée. Ensuite, dès que le noeud en question est revenu online (au bout d’une trentaine de secondes), la reconstruction s’est transformée en “rebalance”. En effet, certains des blocs qui étaient déjà recopiés se son retrouvé “en triple” et le cluster a donc logiquement ré-équilibré (et supprimer du même coup) les copies inutiles.

Bref… sans aller encore trop loin dans le fonctionnement (je testerai aussi l’ajout d’un nouveau noeud dans un prochain billet) ScaleIO semble assez “magique” dans son approche de la répartition de charge et sa gestion des pannes.

A suivre !