Sheepdog est un système évolutif qui fournit des périphériques de blocs distribués aux machines virtuelles. Son développement a commencé en 2009 par des développeurs de la société japonaise Nippon Telegraph and Telephone Corporation . Sheepdog est une application open source sous licence GPL2. La dernière version 0.9.3, sortie en novembre 2015, sera l'héritage de la version 1.0, adaptée à un usage commercial ¹ . (est déjà devenu - environ par.)

Pour des raisons d'intérêt, la première version (0.1.0) a été publiée par les développeurs en août 2010 - et en même temps, le support du chien de berger a été immédiatement inclus dans la branche principale de développement de QEMU.
Les premiers tests sur un chien de berger que j'ai effectués en novembre 2011 ² et les résultats étaient bons pour les opérations d'E / S. Cependant, le système Sheepdog avait encore des problèmes avec la restauration du nœud tombé. Ce problème a probablement été résolu rapidement, car le développement de l'application est assez dynamique, mais à l'époque, j'utilisais une solution différente.

Les possibilités

Le principe de fonctionnement de Sheepdog est très bien décrit dans la présentation publiée, je me limiterai donc à un bref aperçu.

Il est évolutif
Le volume de cluster peut être augmenté arbitrairement à la fois au niveau du nœud, augmentant la capacité et l'espace pour les données pendant le fonctionnement, et en augmentant le nombre de nœuds. Plus il y a de nœuds, meilleures sont les performances des E / S VDI.

Il est simple
Contrairement à d'autres systèmes, tels que CEPH, Sheepdog ne fonctionne pas directement avec le système de fichiers mais fonctionne avec des blocs de taille fixe, par conséquent, il ne nécessite pas de démons distincts pour servir les métadonnées. Tout le contrôle est effectué à l'aide d'un seul outil de chien qui communique directement avec les moutons
(ceph utilise également des objets - environ par.)

Calcule un nœud tombé
Chaque VDI se compose de ces blocs (objets) qui sont répliqués simultanément sur plusieurs nœuds.Par conséquent, si l'un d'entre eux tombe, les données restent disponibles et les objets des nœuds tombés commencent à se répliquer sur l'autre nœud.

Prend en charge les instantanés de périphérique de bloc
Les instantanés de Sheepdog fonctionnent de la même manière que Btrfs. Les blocs VDI attachés sont enregistrés et les nouvelles données sont écrites dans de nouveaux blocs.

Les fonctions suivantes peuvent être problématiques dans certaines circonstances:

Sheepdog ne prend pas en charge SPOF
Si VDI est utilisé comme périphérique de bloc via QEMU, un problème peut survenir s'il est connecté en même temps à plusieurs endroits. SPOF ³ aurait pu empêcher cela. Sheepdog n'a pas. Cependant, dans la nouvelle version de Sheepdog, VDI peut être bloqué afin de ne pas autoriser plus d'une connexion.

Le cycle de vie des objets de données
Les objets VDI ne peuvent être supprimés que lorsque tous les clones et instantanés qui leur sont associés sont supprimés. C'est exactement la même chose que pour Btrfs. Par conséquent, la suppression d'instantanés inutilisés peut ne pas être suffisante pour faire de la place pour le stockage.

Démon de communication

Sheepdog est ridiculement petit par rapport à Ceph ou GlusterFS. En effet, il n'essaie pas de résoudre lui-même tous les problèmes, mais utilise au maximum ce qui fonctionne déjà.

À son tour, il fournit un périphérique de bloc qui peut être utilisé comme disque physique, ainsi qu'un raid logiciel, etc.

Il ne se soucie que de la distribution des objets de données entre les nœuds sur lesquels il s'exécute.

Cependant, il a besoin des informations fournies par le démon de communication - un composant clé sans lequel Sheepdog ne fonctionnera pas.

Démon de communication - n'offre pas la possibilité d'échanger des données entre les nœuds. C'est ce que font les démons moutons . Grâce à elle, les moutons découvrent uniquement les nœuds actuellement en vie.

corosync

Tout d'abord, Sheepdog suppose que les nœuds communiqueront entre eux via corosync . Il prend en charge jusqu'à 64 nœuds, bien qu'il devrait théoriquement être en mesure de servir davantage, son utilisation est optimale pour les petits clusters jusqu'à 16 nœuds.

En règle générale, corosync utilise également Pacemaker, il n'est donc pas nécessaire d'installer autre chose.

Installer corosync sur Debian

Corosync est dans les référentiels de distribution, et son installation est simple:

$ apt-get install corosync libcorosync-common4 

Configuration de Corosync

gardien de zoo

Les développeurs de Sheepdog recommandent d'utiliser zookeeper pour les clusters plus importants. Selon les développeurs, un stockage de test Sheepdog avec 1000 nœuds a été construit et testé ⁴ .

Installer zookeeper sur Debian

 $ apt-get install zookeeper zookeeperd 

Lancement du démon ..

 $ /usr/share/zookeeper/bin/zkServer.sh start 

Le port par défaut sur lequel s'exécute zookeeper est 2181

Exécuter le chien de berger avec le support zookeeper

 $ sheep -c zookeeper:IP1:PORT1,IP2:PORT2,IP3:PORT3 ...other...option... 

Le bonus de zookeeper est que dans son cas, Sheepdog a une configuration plus claire et plus simple des nœuds, mais il y a un problème que le paquet d'installation Debian n'inclut pas son support.

Par conséquent, pour obtenir un Sheepdog avec le support de zookeeper, vous devez le compiler à partir du code source. Bien que je ne puisse pas exclure que la situation puisse être différente à l'heure actuelle.
(Le support de zookeeper nécessite toujours une compilation à partir de la source - environ par.)

Configuration du démon mouton

Le nœud fait partie du Sheepdog lorsque le gestionnaire d'objets, le démon mouton , démarre. Il fonctionne toujours en deux exemplaires:

1. La première instance du processus commence comme une passerelle, qui reçoit les demandes d'E / S des clients (par exemple, des pilotes des périphériques de bloc QEMU), calcule les nœuds cibles et envoie des demandes de traitement ultérieur entre eux. Autrement dit, il établit de nombreuses connexions réseau.

   
   
2. Un autre fonctionne comme un gestionnaire d'objets local (gestionnaire d' objets )

Les paramètres de configuration du démon mouton peuvent être passés comme arguments de ligne de commande lors de l'exécution. S'il n'y en a pas, les valeurs par défaut seront utilisées, avec lesquelles vous devez faire attention:

Numéro de port
Sauf indication contraire, le démon mouton s'exécute sur le port 7000

Chemin d'accès au coffre-fort
Sauf indication contraire, le répertoire shep utilise le répertoire / var / lib / moutdog et les objets VDI sont stockés dans son sous-répertoire obj .

Théoriquement, rien n'empêche plusieurs instances de moutons de travailler sur un nœud - la condition principale est que chacun utilise son numéro de port et son propre stockage. Le problème de l'adresse IP du nœud est presque résolu. Chaque instance en cours d'exécution du démon mouton s'exécutant sur un port différent se connectera automatiquement à un cluster existant!

Informations importantes: le numéro de port fait partie de la configuration du conteneur VDI. Vous devez savoir si vous souhaitez reconfigurer le démon mouton pour qu'il s'exécute sur l'autre port du cluster existant.

Par conséquent, si vous exécutez une instance du démon mouton avec un numéro de port différent, mais avec le même chemin d'accès au magasin d'objets, vous risquez de perdre des informations dans les conteneurs VDI existants.

Le mouton démon comme porte d'entrée

Sur les machines qui n'ont pas d'espace de stockage pour les objets VDI, le démon mouton peut être exécuté exclusivement en mode passerelle, avec l'indicateur -G .

Dans ce cas, lors de la distribution d'objets VDI, le stockage local ne sera pas utilisé du tout et les données seront distribuées directement aux autres nœuds.

Démon mouton en tant que gestionnaire d'objets

La deuxième instance en cours d'exécution, agit en tant que gestionnaire d'objets local, reçoit les demandes d'E / S d'une instance qui démarre en tant que passerelle et effectue des opérations de r / w dans le stockage d'objets local ( stockage d'objets )

Stockage d'objets

Par défaut, le stockage des objets VDI dans Sheepdog est le répertoire /var/lib/sheepdog/obj mouton /var/lib/sheepdog/obj , qui est également utilisé par le démon mouton dans le cadre de sa structure de répertoire interne - c'est le chemin de stockage par défaut.

Si vous souhaitez que les objets VDI soient stockés ailleurs, vous pouvez passer le chemin où un autre périphérique de bloc est monté en tant que paramètre au démarrage.

 sheep ... /cesta_do_přípojného_bodu 

Il existe encore plus de moyens de transmettre. La nouvelle version de Sheepdog prend en charge la technologie dite multi-périphérique, qui vous permet d'augmenter dynamiquement la capacité de mémoire, si nécessaire, sans avoir à redémarrer le Sheepdog . L'augmentation de la capacité de stockage fonctionne de manière similaire à Btrfs.

 sheep ... /cesta_do_A,/cesta_do_B,/cesta_do_C 

(le premier répertoire spécifié ne sera utilisé que pour les métadonnées - environ par)

Un stockage supplémentaire peut également être ajouté (ou supprimé) via le nœud de chien md

...

La fonctionnalité offerte par le multi-périphérique est particulièrement utile lorsque le système de fichiers de stockage ne prend pas en charge cette "par conception" (contrairement à Btrfs ou ZFS). En général, le choix d'un système de fichiers pour stocker des objets, leurs propriétés, paramètres et réglages peut affecter de manière significative les performances du système de fichiers IO d'une machine virtuelle.

La technologie multi-périphérique nécessite des attributs avancés côté fichier, ce qui n'est pas un problème pour les systèmes de fichiers modernes tels que btrfs ⁵ ou ext4. Mais certains systèmes de fichiers plus anciens comme reiserfs ou ext2 ⁶ Ne les soutenez pas.

Si vous souhaitez utiliser un système de fichiers qui ne prend pas en charge les attributs étendus pour stocker des objets, nous devons compiler Sheepdog sans prise en charge multi-périphérique.

Type de stockage - simple contre arbre

Lors du formatage d'un cluster, entre autres options, vous pouvez spécifier le type de stockage (stockage backend). Vous pouvez définir le type sur plain ou tree . Pour un type simple , la structure du répertoire ressemblera à ceci:

 | |- obj | |- <id > | | |-< > | | |-< > | | |-< > | | |- ... | |- <id  > | | ... |- config [] |- epoch | |- < > | |- < > | |- ... |- journal \- sheep.log [] 

Tous les objets VDI du répertoire obj seront envoyés vers un sous-répertoire dont le nom est basé sur l'identifiant de l'ère actuelle. Autrement dit, pour chaque époque, les objets VDI correspondants seront stockés séparément. Cependant, à une époque, un grand nombre d'objets VDI peuvent apparaître dans le répertoire, ce qui ralentit par la suite l'accès aux fichiers. Par conséquent, vous pouvez choisir la deuxième option, qui est l' arborescence :

 |- obj | |- aa | | |-< > | | |-< > | | |-< > | | |- ... | |- ab | | ... | |- meta | | |- < > | | |- ... | |- 0a | | ... |- config [] |- epoch | |- < > | |- < > | |- ... \- sheep.log [] 

Dans ce type de stockage, le démon mouton crée un ensemble de 256 sous-répertoires avec les noms 0a, ..., 99 dans le répertoire obj , puis disperse les objets en fonction des deux derniers caractères de l' ID VDI , ce qui est unique non seulement pour chaque conteneur VDI mais aussi ses instantanés ou clones.

Noms des objets VDI

Lorsque Sheepdog enregistre les données dans le conteneur VDI, les fichiers commencent à apparaître dans le magasin de données obj , chacun aura son propre nom composé de plusieurs éléments:

 ../obj/8f/00e8b18f00000005 ^^ 

Les deux premiers caractères indiquent le type d'objet. Les objets de données commencent par 00... et les métadonnées (qui peuvent être stockées dans un autre répertoire) 80...

 ../obj/8f/00e8b18f00000005 ^^^^^^ 

Vient ensuite le VDI. Il est unique non seulement pour chaque conteneur, mais également pour son instantané ou son clone.

 ../obj/8f/00e8b18f00000005 ^^ ^^ 

Les deux derniers chiffres de l'identifiant VDI indiquent - dans le cas du type de stockage d' arborescence - dans lequel se trouve le sous-répertoire auquel appartient l'objet.

 ../obj/8f/00e8b18f00000005 ^^^^^^^^ 

Et l'identifiant du conteneur VDI en hexadécimal est suivi du numéro de série de l'objet dans le conteneur VDI

Époque

Le sous-répertoire epoch contient des listes binaires d'objets appartenant à l'époque. Le nombre d'époques augmente, chaque fois que chaque cluster change - lorsqu'un nœud est ajouté ou supprimé. Chacun de ces changements démarre le processus de récupération , au cours duquel l'état actuel des objets locaux sera vérifié sur les nœuds, suivi d'une augmentation de l'ère.

Comment choisir le stockage d'objet VDI optimal

La capacité de stockage disponible est calculée en fonction de l'espace libre sur les nœuds. L'espace choisi par les moutons dépend toujours de la quantité d'espace disponible dans le périphérique de bloc où les objets VDI sont stockés.

La taille d'un conteneur VDI n'est qu'une forme virtuelle qui n'est aucunement liée à l'espace occupé par les objets VDI. Il est important de savoir comment Sheepdog traite les données dans un cluster:

Sheepdog essaie toujours de stocker les données uniformément entre toutes les machines de l'époque.

Cela signifie que si l'un des nœuds tombe, l'ère change et Sheepdog démarre immédiatement le processus de récupération, il créera les objets VDI manquants sur les nœuds restants pour compenser la perte.

Une situation similaire se produira lors de l'ajout d'un nouveau nœud. Sheepdog commencera à déplacer uniformément les objets VDI des nouveaux nœuds vers son référentiel, afin que le pourcentage de remplissage de l'espace de données sur les nœuds soit aussi équilibré que possible. Utilisez la commande suivante pour obtenir un aperçu global de l'espace actuellement utilisé sur vos nœuds:

 nod1 ~ # collie node md info -A Id Size Used Avail Use% Path Node 0: 0 1.1 TB 391 GB 720 GB 35% /local/sheepdog-data/obj Node 1: 0 702 GB 394 GB 307 GB 56% /local/sheepdog-data/obj Node 2: 0 794 GB 430 GB 364 GB 54% /local/sheepdog-data/obj Node 3: 0 1.6 TB 376 GB 1.2 TB 22% /local/sheepdog-data/obj Node 4: 0 1.2 TB 401 GB 838 GB 32% /local/sheepdog-data/obj Node 5: 0 1.5 TB 370 GB 1.1 TB 24% /local/sheepdog-data/obj Node 6: 0 1.6 TB 388 GB 1.2 TB 23% /local/sheepdog-data/obj 

Performances d'E / S

Il est important de dire ici que Sheepdog fonctionne différemment de Ceph et a des priorités différentes.

Pour Ceph, le «poids» du périphérique OSD est critique lors du placement d'objets de données, ainsi que les performances du périphérique de blocage, la connectivité de l'hôte et la vitesse de réponse. (en fait pas - environ par)

Sheepdog fait-il quelque chose comme ça, je ne sais pas. C'est possible. Les données pour lui viennent en premier. Les performances en termes d'opérations d'E / S sont secondaires. Bien sûr, avec des nœuds plus puissants, ses performances d'E / S peuvent s'améliorer, mais cela dépend toujours de la structure spécifique. (cependant, les tests montrent une meilleure performance du chien de berger par rapport au céph - environ par personne)

J'ai ajouté un nouveau nœud à Sheepdog avec des données stockées sur un disque SATA II rotatif de 2 To. La vitesse d'écriture maximale de ce disque est d'environ 80 M / s. En fait, cela varie beaucoup car les disques SATA ne peuvent pas lire et écrire en même temps.

Initialement, la vitesse d'écriture moyenne sur VDI sur ce disque était d'environ 20 à 30 M / s, car en plus des données de VDI, les données du conteneur 392G y étaient répliquées dans le cadre du processus de récupération. Cela a duré 6,5 heures. La vitesse d'écriture variait entre 40 et 55 M / s.

De toute évidence, dans ce cas, la vitesse d'écriture était limitée par les performances d'E / S du périphérique de bloc local.

Pour Sheepdog, la règle suivante s'applique: "Plus il y a d'objets VDI sur les nœuds avec une connexion rapide, meilleures sont les performances des opérations d'E / S."

Étant donné que le déplacement d'objets VDI en arrière-plan signifie que la «mort rapide d'un nœud» ralentira la réplication des objets de données qui occupent le plus d'espace, cela se manifestera par une diminution des performances des opérations d'E / S du conteneur VDI.

Espace occupé

Lors du placement d'objets de données, la quantité d'espace libre est critique pour le démon mouton . Le mécanisme semble simple. Le démon mouton , à travers lequel les données sont communiquées avec le conteneur VDI, détermine de temps en temps l'utilisation de l'espace libre et occupé sur les nœuds, ce qui le trie. Ensuite, les données sont réparties entre les nœuds avec le taux d'utilisation le plus bas.

S'il existe un chemin d'écriture principalement rapide, l'opération d'écriture dans le conteneur VDI sera également rapide. Étant donné que plus les opérations d'E / S du conteneur VDI sont rapides, plus le démon mouton peut passer à l'opération suivante.

L'important est qu'avec Sheepdog, il n'y ait pas de situation où l'un des nœuds est complètement plein. Si le taux d'utilisation sur le nœud devient bien pire, le démon mouton commence à déplacer ses objets de données vers un autre emplacement.

Sheepdog fonctionne comme Btrfs - en utilisant uniquement de l'espace vraiment occupé. Ainsi, vous pouvez créer un conteneur VDI virtuel d'une capacité de 1 To, qui prendra en fait autant d'espace que les données qui y sont stockées. De ce point de vue, il est souhaitable d'utiliser de tels formats de disques virtuels et de systèmes de fichiers dans des conteneurs VDI qu'ils peuvent nettoyer l'un après l'autre.

Lancement du cluster

Alors que tous les nœuds peuvent être arrêtés en même temps, les nœuds ne peuvent pas être démarrés à la fois !!! Les nœuds doivent être connectés progressivement. En commençant par le nœud qui a été spécifié en premier dans la liste des nœuds.
(c'est une déclaration extrêmement étrange - environ par)

Vdi

Il s'agit d'une abréviation générique dans Sheepdog pour disque virtuel, et non de son format spécifique. . En général, il s'agit d'une boîte virtuelle avec des compartiments de taille fixe, dans laquelle Sheepdog place ensuite les données que le client transmet.

Création de VDI

Avant de créer ou d'importer le premier VDI, nous devons formater le cluster. Lors du formatage d'un cluster, des paramètres sont définis qui seront ensuite utilisés par défaut lors de la création de chaque VDI suivant.

Un exemple démontrant la création d'un nouveau VDI nommé Disk1 et 1 Go de taille

 root@nod1 :~# collie vdi create disk1 1G root@nod1 :~# collie vdi list Name Id Size Used Shared Creation time VDI id Copies Tag Block Size Shift disk1 0 1.0 GB 0.0 MB 0.0 MB 2015-12-04 14:07 e8b18f 2 22 

Id
Identifiant VDI

La taille
La taille du VDI qui ne sera pas nécessairement immédiatement préallouée.
Si ce VDI est au format incrémentiel (qcow2 et similaire) créé à l'aide de qemu-img convert , il ne correspondra pas à la taille du disque virtuel, mais il augmentera constamment.

Utilisé
Informations sur l'espace occupé par les objets de données VDI.
VDI, qui ne nécessite pas d'allocation d'objets de données lors de la création, n'occupera rien du tout, car les objets de données n'ont pas encore été créés pour lui.

Partagé
Le volume d'objets de données partagés par d'autres VDI

Heure de création
Heure de création VDI

Taille de bloc
La taille de l'objet VDI. Attention! Il n'est pas spécifié en Mo, mais comme une puissance de deux octets. Dans les anciennes versions, seuls 4 Mo d'objets de taille fixe étaient utilisés. Actuellement, VDI peut avoir des objets plus grands. La taille optimale pour l'objet VDI d'une machine virtuelle ordinaire ressemble à 64 Mo (26). La taille par défaut de 22 (4 Mo) est également minime. Moins ne peut pas être installé. Plus la taille de l'objet est petite, plus le nombre de fichiers que Sheepdog devra traiter lors de l'utilisation de VDI est important, et travailler avec des fichiers n'est pas un problème bon marché du point de vue d'E / S. Un grand nombre de fichiers, en particulier avec des contrôleurs SATA lents, peuvent entraîner une forte détérioration des vitesses de lecture et d'écriture. La taille maximale des objets pouvant être utilisés est de 31 (2 Go). Cela peut être avantageux si VDI stocke systématiquement une grande quantité de données statiques, telles que des sauvegardes.

Vdi id
Identifiant VDI.

Que contient VDI?

Le contenu VDI est constitué de données. Ceci est un périphérique de bloc distribué, donc Sheepdog ne résout pas ces données ou ces ordures. De ce point de vue, VDI ressemble à un volume logique LVM. Un VDI pré-rempli correspond à une partition LV classique avec une plage dédiée, tandis que le VDI ressemble à une partition LV mince créée dans un pool (voir LVM (thin_provisioning)), mais avec la différence que les étendues de données (objets) ne sont pas enregistrées sur local bloquer les périphériques et sont dispersés entre les nœuds.

Le format VDI fonctionne dans cette analogie comme un système de fichiers. Certains occupent des étendues réservées (objets) de manière séquentielle, d'autres les mappent en tant qu'inodes, puis leur envoient directement des données. Une combinaison incorrecte du système de fichiers de stockage de noeud, du format VDI et du système de fichiers interne peut entraîner une dégradation significative des performances d'E / S.

Comment obtenir des informations sur VDI

Pour en savoir plus sur le format VDI, vous pouvez utiliser qemu-img info :

 root@nod1 :~# qemu-img info sheepdog:localhost:8000:disk1 image: sheepdog:localhost:8000:test2 file format: qcow2 virtual size: 12G (12884901888 bytes) disk size: 4.0G cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false 

À la sortie de la commande, vous pouvez découvrir que disk1 a une taille nominale de 12G. Actuellement, il ne prend que la 4G. Puisqu'il est au format qcow2, il est évident qu'il a été créé comme incrémental.

 root@nod1 :~# collie vdi list Name Id Size Used Shared Creation time VDI id Copies Tag Block Size Shift disk2 0 4.0 GB 4.0 GB 0.0 MB 2015-12-04 16:07 825dc1 2 31 root@nod1 :~# qemu-img info sheepdog:localhost:8000:disk2 image: sheepdog:localhost:8000:disk2 file format: raw virtual size: 4.0G (4294967296 bytes) disk size: 4.0G root@nod1 :~# find /datastore/obj/ | grep 825dc1 /datastore/obj/meta/80825dc100000000 /datastore/obj/c1/00825dc100000000 /datastore/obj/c1/00825dc100000001 

Dans ce cas, Disk2 a été créé en tant que VDI préalloué de 4 Go au format brut avec une taille de bloc de 2 Go, ce qui ne prend en fait que deux 2 Go

Exporter VDI dans un fichier

Le contenu VDI peut être exporté de Sheepdog de plusieurs manières. Le plus rapide est peut-être d'utiliser la lecture de chien . La commande est un peu déroutante, mais signifie simplement: "Chargez le contenu du VDI et envoyez-le à STDOUT ..", qui peut être redirigé vers un fichier:

 root@nod1 :~# collie vdi read disk1 > /backups/soubor.raw 

Si VDI a 10G mais seulement 2G est utilisé, il créera un fichier avec une pleine capacité de 10 Go.

Dans cette commande, le contenu du VDI est inchangé , donc si le contenu du VDI, par exemple, un disque virtuel au format qcow2 compressé, peut être utilisé directement

 .. -drive file=file:/disk1_exportovany_z_vdi,..,format=qcow2 .. 

Une autre façon d'obtenir le contenu de VDI dans un fichier est d'utiliser qemu-img convert . Ce n'est pas si rapide, mais cela vous permet de convertir VDI en un autre format en utilisant différentes options du format de disque virtuel correspondant.

 root@nod1 :~# qemu-img convert -f qcow2 -O file -o preallocation=full,nocow=on sheepdog:localhost:8000:disk1 /disk1_exportovany_z_vdi 

Sauvegarde incrémentielle

Créer une sauvegarde incrémentielle

Delta entre le premier et le deuxième instantané ..

 root@nod1 :~# collie vdi backup test -F snap1 -s snap2 /backups/soubor_diff 

Restaurer VDI à partir d'une sauvegarde incrémentielle

 root@nod1 :~# collie vdi restore test -s snap1 /tmp/backup restoring /tmp/backup... done 

Lors de l'importation d'une sauvegarde incrémentielle, le VDI doit bien sûr avoir l'instantané à partir duquel la sauvegarde a été effectuée.

Vérification en lisant le contenu original du test d'image ...

  root@nod1 :~# collie vdi read test 0 512 -s 3 

Importer VDI à partir d'un fichier

L'importation d'un disque virtuel existant en tant que fichier FS local peut être effectuée de la même manière pour l'exportation. Mais avec la différence que l' écriture de chien est utilisée ("Lecture des données de STDIN et écriture dans un fichier VDI ..")

 root@nod1 :~# collie vdi write disk1 < /backups/soubor.raw 

• Le contenu ne peut être importé que dans un VDI existant.
• Le VDI importé occupe toujours plus d'espace que le fichier d'origine, car les blocs de données à partir desquels le VDI est restauré contiennent des données sur la zone marquée.

Si VDI n'existe pas encore et que nous ne savons pas combien d'espace sera nécessaire pour le disque virtuel, nous pouvons utiliser qemu-img convert

 root@nod1 :~# qemu-img convert -f file -O qcow2 -o redundancy=2:1 ./disk_ukladany_do_vdi sheepdog:localhost:8000:disk 

Bien que les formats VDI tels que qcow2, qed et autres puissent être utilisés dans VDI. Pour l'efficacité des E / S, il est préférable de préallouer les blocs de données.
, Sheepdog VDI.

http://www.sheepdog-project.org/doc/vdi_read_and_write.html

VDI

VDI , .

 root@nod1 :~# collie vdi check disk1 

VDI, . Sheepdog , . , .

: 'dog node kill' , ethernet , sheep . (, Ethernet), sheep . .

IO VDI

VDI . . , IO VDI.

Sheepdog SYNC, . -, VFS, , , .

VDI Sheepdog , . . Sheepdog VDI-.

VFS-

IO VDI sheep -n . SYNC , , VFS . , VFS , , !

. , — , , .

  sheep -n ... 

Sheepdog . -D

- . sheep - IO — SSD . , VDI, SYNC . .

, VDI , VDI . , , , VDI.

 sheep -w size=20000,directio,dir=/dir ... 

size

directio
sheep , . SSD.

dir

      ,     . 

( ) dog .

VDI dog vd cashe flush , VDI!

— . VDI, VFS , (/store_dir/journal/[epoch]/[vdi_object_id]), , .

IO , (cik, cak), (sequence).

, Sheepdog VDI , , SSD-. , VDI , , VDI.

sheep —

 $ sheep -j size=256M ... 

, VDI , . -, — — -:

 $ sheep -j dir=/dir,size=256M ... 

dir = , . , SW RAID SSD.

: sheep , . , skip, .

 $ sheep -j dir=/dir,size=256M,skip ... 

1. ^{↑ . 2015 . http://events.linuxfoundation.jp/sites/events/files/slides/COJ2015_Sheepdog_20150604.pdf}
2. ^{↑ http://www.abclinuxu.cz/blog/kenyho_stesky/2011/11/sheepdog-hrajeme-si-v-hampejzu}
3. ^{↑ SPOF ( S ingle p oint o f f ailure) , . SPOF VDI iSCSI tgtd}
4. ^{↑ 1}

5. ^{↑ Btrfs — COW, , . , -, . , , . , , . , :}

   
   

   ^{autodefrag — , .}

   
   
   
   

   ^{nocow — (), — GlusterFS}

   
   

   ^{Btrfs , , FS, Sheepdog .}

   
   
   • ^{, , ,}
   • ^{multipath, .}
   
   

   ^{, , , Sheepdog.}

   
   

6. ^{↑ Ext2 . - FS Btrfs, ext2, inode. ext3 ext4 . inode , Sheepdog . , -, . , Sheepdog , dog vdi check . , ext2 , — - dog vdi md , VDI .}

   
   
7. ^{↑ , , vdi QEMU_Block_Disk}

Les références

https://github.com/collie/sheepdog/wiki — ,
http://www.osrg.net/sheepdog/ — Nippon Telegraph and Telephone Corporation
http://www.sheepdog-project.org/doc/index.html — Sheepdog 0.8.0; — Valerio Pachera
http://www.admin-magazine.com/Archive/2014/23/Distributed-storage-with-Sheepdog — Udo Seidela Sheepdog , 23- Admin 2014