Sheepdog Project — Sheepdog Project. Gestion des snapshots dans MooseFs. En regardant les statistiques de visite sur ce blog et notamment les mots clés qui permettent d’y aboutir, la question de la gestion des snapshots dans MooseFS revient fréquemment.
Voici donc un (tout) petit article sur le sujet. Définition A l’instar de la virtualisation, un snapshot permet de figer l’état ‘E’ d’un objet (ici fichier, répertoire ou arborescence) à un instant ‘T’. Il est ensuite possible de continuer à modifier le dit objet et de revenir à l’état E si nécessaire. C’est un mécanisme de sécurisation particulièrement souple. Gérer les snapshots dans MooseFS Dans les faits, prendre un snapshot ressemble à une copie de fichier à ceci prêt que dans le cas d’un système de fichier distribué les contraintes sont plus fortes. Pour prendre un snapshot dans MooseFS la commande est simple: # mfsmakesnapshot [-o] source destination Deux petites remarques: La source peut être un fichier, un répertoire ou une arborescence de répertoires. Conclusion C’est déjà terminé. Ceph: un système de fichier distribué à surveiller. A l’instar de MooseFS , Ceph est un système de fichier distribué.
Son architecture matériel & logiciel repose sur: un groupe de serveurs de stockage (appelés OSDs), un ensemble de serveurs de métadonnée (MDS) et quelques services de monitoring qui ont pour vocation de gérer la cohérence de l’ensemble en fonction de l’états des différents noeuds. L’architecture logique, quant à elle, se compose de deux couches: la première est une couche d’abstraction intitulé RADOS qui fournit un espace de stockage distribué, évolutif (scalable) et à tolérance de panne. La seconde, Ceph lui même, utilise les services de la précédente pour stocker les fichiers et fournit un jeu de commande compatible POSIX pour y accéder. Il existe différentes méthodes pour intéragir avec Ceph: Les serveurs de metadonnées : il s’agit d’un ensemble de serveurs qui conservent les informations relatives au fichiers sous la forme de métadonnées et en propose l’accès via un point de montage.
Clustered, replicated Storage with GlusterFS - Tutorials / Howtos - Sysconfig's Wiki. In an environment where high availability is crucial, you won't be able to work without cross-machine replication in the long run.
While normal RAIDs, backups, and networked file systems are reasonable ways to protect yourself from data loss and allow to access the same data from multiple hosts, they still leave you with a single point of failure, the storage itself. There are plenty of rather expensive solutions out there, which come with two machines and multiple NICs in one box, accessing the same RAID array (for example NetApp®). But for most environments this is overkill, or just not affordable. GlusterFS can help here. In this mini tutorial, I'd like to describe how to create a replicated clustered storage with two machines. Clustered Filesystem with DRBD and OCFS2 on CentOS 5.5 - Tutorials / Howtos - Sysconfig's Wiki. Months ago I've published Clustered Filesystem with DRBD and GFS2 on CentOS 5.4 in this wiki.
Now I would like to give another option – OCFS2, which is a clustered filesystem developed by Oracle. OCFS initially was focused on use with Oracle's databases, but with OFCS2 it's a general-pupose cluster filesystem. It's available as open source, and Oracle does a quite good job publishing packages and modules for each and every kernel version (so you don't need to re-compile it over and over again when you update your kernel).
That at least holds true for RHEL and derivates. OCFS2 works very similar to GFS2, except that it doesn't use RedHat's Cluster Manager, but instead ships with O2CB, Oracle's own cluster manager. You will notice that this howto is very similar to the GFS2 howto mentioned earlier. For this short tutorial, I assume that Unless stated otherwise, please do everything on both nodes! For DRBD, install the required software: , for example: Install both RPMs as you normally would: Tahoe-lafs.