Sheepdog es un sistema escalable que proporciona dispositivos de bloques distribuidos a máquinas virtuales. Su desarrollo comenzó en 2009 por desarrolladores de la compañía japonesa Nippon Telegraph and Telephone Corporation . Sheepdog es una aplicación de código abierto bajo la licencia GPL2. La última versión 0.9.3, lanzada en noviembre de 2015, será el legado de la versión 1.0, adecuada para uso comercial ¹ . (ya se ha convertido en - aprox. por.)

En aras del interés, la primera versión (0.1.0) fue lanzada por los desarrolladores en agosto de 2010, y al mismo tiempo, el soporte del perro pastor se incluyó de inmediato en la rama principal de desarrollo de QEMU.
Las primeras pruebas en un perro pastor que realicé en noviembre de 2011 ² y los resultados fueron buenos para las operaciones de E / S. Sin embargo, el sistema Sheepdog todavía tenía problemas con la restauración del nodo caído. Este problema probablemente se resolvió pronto, ya que el desarrollo de la aplicación es bastante dinámico, pero en ese momento utilicé una solución diferente.

Las posibilidades

El principio de funcionamiento de Sheepdog está muy bien descrito en la presentación publicada, por lo que me limitaré a una breve descripción general.

Es escalable
El volumen del clúster se puede aumentar arbitrariamente tanto a nivel de nodo, aumentando la capacidad y el espacio para datos durante la operación, como aumentando el número de nodos. Cuantos más nodos, mayor será el rendimiento de E / S VDI.

El es simple
A diferencia de otros sistemas, como CEPH, Sheepdog no funciona directamente con el sistema de archivos sino que funciona con bloques de tamaño fijo, por lo tanto, no requiere demonios separados para servir metadatos. Todo el control se realiza utilizando una herramienta de perro único que se comunica directamente con las ovejas.
(ceph también usa objetos - aprox. por.)

Calcula un nodo caído
Cada VDI consta de estos bloques (objetos) que se replican simultáneamente en varios nodos, por lo tanto, si uno de ellos cae, los datos permanecen disponibles y los objetos de los nodos caídos comienzan a replicarse en el otro nodo.

Admite instantáneas de dispositivos de bloque
Las instantáneas del perro pastor funcionan igual que Btrfs. Los bloques VDI adjuntos se guardan y los nuevos datos se escriben en nuevos bloques.

Las siguientes funciones pueden ser problemáticas en ciertas circunstancias:

Perro pastor no es compatible con SPOF
Si se usa VDI como un dispositivo de bloque a través de QEMU, puede surgir un problema si está conectado al mismo tiempo en varios lugares. SPOF ³ podría haber evitado esto. Perro pastor no tiene. Sin embargo, en la nueva versión de Sheepdog, VDI puede bloquearse para no permitir más de una conexión.

El ciclo de vida de los objetos de datos.
Los objetos VDI solo se pueden eliminar cuando se eliminan todos los clones y las instantáneas asociadas con ellos. Esto es exactamente lo mismo que para Btrfs. Por lo tanto, eliminar instantáneas no utilizadas puede no ser suficiente para dejar espacio para el almacenamiento.

Demonio de comunicación

El perro pastor es ridículamente pequeño en comparación con Ceph o GlusterFS. Esto se debe a que no intenta resolver todos los problemas por sí mismo, sino que utiliza al máximo lo que ya está funcionando.

A su vez, proporciona un dispositivo de bloque que puede usarse como un disco físico, así como una incursión de software, etc.

Solo le importa la distribución de objetos de datos entre los nodos en los que se ejecuta.

Sin embargo, necesita la información que proporciona el daemon de comunicación , un componente clave sin el cual Sheepdog no funcionará.

Demonio de comunicación : no proporciona la capacidad de intercambiar datos entre nodos. Esto es lo que los demonios de ovejas están haciendo. A través de él, la oveja solo descubre qué nodos están actualmente vivos.

corosync

En primer lugar, Sheepdog supone que los nodos se comunicarán entre sí a través de corosync . Admite hasta 64 nodos, aunque en teoría debería poder servir más, su uso es óptimo para pequeños grupos de hasta 16 nodos.

Por lo general, corosync también usa Pacemaker, por lo que no es necesario instalar nada más.

Instale corosync en Debian

Corosync está en los repositorios de distribución, y su instalación es simple:

$ apt-get install corosync libcorosync-common4

Configuración Corosync

cuidador del zoológico

Los desarrolladores de Sheepdog recomiendan usar zookeeper para grupos más grandes. Según los desarrolladores, se construyó y probó un almacenamiento de prueba de Sheepdog con 1000 nodos ⁴ .

Instalar zookeeper en Debian

 $ apt-get install zookeeper zookeeperd

Lanzando el demonio ..

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

El puerto predeterminado en el que se ejecuta zookeeper es 2181

Ejecución de perro pastor con el apoyo del cuidador del zoológico:

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

La ventaja de Zookeeper es que, en su caso, Sheepdog tiene una configuración de nodos más clara y fácil, pero existe el problema de que el paquete de instalación de Debian no incluye su soporte.

Por lo tanto, para obtener un perro pastor con soporte de zookeeper, debe compilarlo a partir del código fuente. Aunque no puedo descartar que la situación pueda ser diferente en este momento.
(el soporte de Zookeeper todavía requiere compilación de la fuente - aprox. por.)

Preparando el demonio de las ovejas

El nodo se convierte en parte del perro pastor cuando se inicia el administrador de objetos, el demonio ovino . Siempre funciona en dos copias:

La primera instancia del proceso comienza como una puerta de enlace, que recibe las solicitudes de E / S de los clientes (por ejemplo, de los controladores de los dispositivos de bloque QEMU), calcula los nodos de destino y envía solicitudes para su posterior procesamiento entre ellos. Es decir, establece muchas conexiones de red.
Otro funciona como administrador de objetos local ( Object Manager )

Los parámetros de configuración del daemon de ovejas se pueden pasar como argumentos de línea de comandos en tiempo de ejecución. Si no hay ninguno, se utilizarán los valores predeterminados, con los que debe tener cuidado:

Número de puerto
A menos que se especifique lo contrario, el daemon de ovejas se ejecuta en el puerto 7000

Camino de la bóveda
A menos que se especifique lo contrario, el directorio shep usa el directorio / var / lib / sheepdog, y los objetos VDI se almacenan en su subdirectorio obj .

Teóricamente, nada impide que varias instancias de ovejas trabajen en un nodo; la condición principal es que todos usen su número de puerto y su propio almacenamiento. El problema de la dirección IP del nodo está casi resuelto. ¡Cada instancia de ejecución del demonio de ovejas que se ejecuta en un puerto diferente se conectará automáticamente a un clúster existente!

La información importante es que el número de puerto es parte de la configuración del contenedor VDI. Debe saber si desea volver a configurar el daemon de oveja para que se ejecute en el otro puerto del clúster existente.

Por lo tanto, si ejecuta una instancia del demonio oveja con un número de puerto diferente, pero con la misma ruta al almacén de objetos, puede perder información en los contenedores VDI existentes.

La oveja demoníaca como puerta de entrada

En máquinas que no tienen espacio de almacenamiento para objetos VDI, el daemon de ovejas se puede ejecutar exclusivamente en modo de puerta de enlace, con el indicador -G .

En este caso, al distribuir objetos VDI, el almacenamiento local no se utilizará en absoluto, y los datos se distribuirán directamente a otros nodos.

Ovejas demonio como administrador de objetos

La segunda instancia en ejecución, actúa como un administrador de objetos local, recibe solicitudes de E / S de una instancia que comienza como una puerta de enlace y realiza operaciones de r / w en el almacenamiento de objetos locales ( almacenamiento de objetos )

Almacenamiento de objetos

De forma predeterminada, el almacenamiento de objetos VDI en Sheepdog es el directorio /var/lib/sheepdog/obj , que también utiliza el daemon de ovejas como parte de su estructura de directorio interno; esta es la ruta de almacenamiento predeterminada.

Si desea que los objetos VDI se almacenen en otro lugar, puede pasar la ruta donde se monta otro dispositivo de bloque como parámetro al inicio.

 sheep ... /cesta_do_přípojného_bodu

Hay incluso más formas de transmitir. La nueva versión de Sheepdog es compatible con la llamada tecnología de dispositivos múltiples, que le permite aumentar dinámicamente la capacidad de memoria, si es necesario, sin tener que reiniciar el Sheepdog . El aumento de la capacidad de almacenamiento funciona de manera similar a Btrfs.

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

(el primer directorio especificado se usará solo para metadatos - aprox. por)

También se puede agregar (o eliminar) almacenamiento adicional a través del nodo de perro md

...

La funcionalidad que ofrece el dispositivo múltiple es especialmente útil cuando el sistema de archivos de almacenamiento no es compatible con este "por diseño" (a diferencia de Btrfs o ZFS). En general, la elección de un sistema de archivos para almacenar objetos, sus propiedades, parámetros y configuraciones puede afectar significativamente el rendimiento del sistema de archivos IO de una máquina virtual.

La tecnología de dispositivos múltiples requiere atributos avanzados en el lado del archivo, lo que no es un problema para los sistemas de archivos modernos como btrfs ⁵ o ext4. Pero algunos sistemas de archivos más antiguos como reiserfs o ext2 ⁶ No los apoyen.

Si desea utilizar un sistema de archivos que no admite atributos extendidos para almacenar objetos, necesitamos compilar Sheepdog sin compatibilidad con múltiples dispositivos.

Tipo de almacenamiento: simple versus árbol

Al formatear un clúster, entre otras opciones, puede especificar el tipo de almacenamiento (almacenamiento de fondo). Puede establecer el tipo en simple o en árbol . Para un tipo simple , la estructura del directorio se verá así:

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

Todos los objetos VDI en el directorio obj se enviarán a un subdirectorio cuyo nombre se basa en el identificador de la era actual. Es decir, para cada era, los objetos VDI correspondientes se almacenarán por separado. Sin embargo, durante una era, una gran cantidad de objetos VDI pueden aparecer en el directorio, lo que posteriormente ralentiza el acceso a los archivos. Por lo tanto, puede elegir la segunda opción, que es árbol :

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

En este tipo de almacenamiento, el daemon de ovejas crea un conjunto de 256 subdirectorios con los nombres 0a, ..., 99 en el directorio obj , y luego dispersa los objetos en función de los dos últimos caracteres de la identificación de VDI , que es exclusivo no solo para cada contenedor de VDI sino también para sus instantáneas o clones

Nombres de objetos VDI

Cuando Sheepdog guarda los datos en el contenedor VDI, los archivos comenzarán a aparecer en el almacén de datos obj , cada uno tendrá su propio nombre que consta de varios elementos:

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

Los primeros dos caracteres indican el tipo de objeto. Los objetos de datos comienzan con 00... y los metadatos (que pueden almacenarse en otro directorio) 80...

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

Luego viene el VDI. Es único no solo para cada contenedor, sino también para su instantánea o clon.

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

Los dos últimos dígitos del identificador VDI indican, en el caso del tipo de almacenamiento en árbol , en qué se encuentra el subdirectorio al que pertenece el objeto.

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

Y el identificador del contenedor VDI en hexadecimal es seguido por el número de serie del objeto en el contenedor VDI

Era

El subdirectorio de epoch contiene listas binarias de objetos que pertenecen a la era. El número de época aumenta, cada vez que cambia cada clúster, cuando se agrega o elimina un nodo. Cada uno de estos cambios inicia el proceso de recuperación , durante el cual se comprobará el estado actual de los objetos locales en los nodos, seguido de un aumento en la era.

Cómo elegir el almacenamiento óptimo de objetos VDI

La capacidad de almacenamiento disponible se calcula en función del espacio libre en los nodos. El espacio elegido por ovejas siempre depende de la cantidad de espacio disponible en el dispositivo de bloque donde se almacenan los objetos VDI.

El tamaño de un contenedor VDI es solo una forma virtual que no está relacionada con la cantidad de espacio que ocupan los objetos VDI. Es importante saber cómo Sheepdog procesa los datos en un clúster:

Sheepdog siempre intenta almacenar datos de manera uniforme entre todas las máquinas de la época.

Esto significa que si uno de los nodos cae, la era cambia y Sheepdog inicia inmediatamente el proceso de recuperación, creará los objetos VDI que faltan en los nodos restantes para compensar la pérdida.

Una situación similar surgirá al agregar un nuevo nodo. Sheepdog comenzará a mover de manera uniforme los objetos VDI de los nuevos nodos a su repositorio, de modo que el porcentaje de llenado del espacio de datos en los nodos sea lo más equilibrado posible. Use el siguiente comando para obtener una descripción global de cuánto espacio se usa actualmente en sus nodos:

 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

Rendimiento de E / S

Es importante decir aquí que Sheepdog funciona de manera diferente a Ceph y tiene diferentes prioridades.

Para Ceph, el "peso" del dispositivo OSD es crítico al colocar objetos de datos, así como el rendimiento del dispositivo de bloque, la conectividad del host y la velocidad de respuesta. (en realidad no - aprox. por)

Sheepdog hace algo como esto, no lo sé. Posiblemente Los datos para él son lo primero. El rendimiento en términos de operaciones de E / S es secundario. Por supuesto, con nodos más potentes, su rendimiento de E / S puede mejorar, pero siempre depende de la estructura específica. (sin embargo, las pruebas muestran un mejor rendimiento del perro pastor en comparación con ceph - aproximadamente por)

Agregué un nuevo nodo a Sheepdog con datos almacenados en un disco giratorio SATA II de 2TB. La velocidad máxima de escritura para este disco es de aproximadamente 80M / s. De hecho, varía mucho porque las unidades SATA no pueden leer y escribir al mismo tiempo.

Inicialmente, la velocidad de escritura promedio en VDI en este disco era de aproximadamente 20 ~ 30M / s, ya que además de los datos de VDI, los datos del contenedor 392G se replicaron como parte del proceso de recuperación. Esto continuó durante 6.5 horas. La velocidad de escritura osciló entre 40 ~ 55M / s.

Obviamente, en este caso, la velocidad de escritura estaba limitada por el rendimiento de E / S del dispositivo de bloque local.

Para Sheepdog, se aplica la siguiente regla: "Cuantos más objetos VDI haya en los nodos con conexión rápida, mejor será el rendimiento de las operaciones de E / S".

Debido al hecho de que mover objetos VDI en segundo plano significa que la "muerte rápida de un nodo" ralentizará la replicación de los objetos de datos que ocupan más espacio, esto se manifestará como una disminución en el rendimiento de las operaciones de E / S del contenedor VDI

Espacio ocupado

Al colocar objetos de datos, la cantidad de espacio libre es crítica para el demonio ovino . El mecanismo parece simple. El demonio ovino , a través del cual los datos se comunican con el contenedor VDI, de vez en cuando determina la utilización del espacio libre y ocupado en los nodos, lo que lo ordena. Luego, los datos se distribuyen entre los nodos con la tasa de utilización más baja.

Si hay una ruta de escritura predominantemente rápida, la operación de escritura en el contenedor VDI también será rápida. Como cuanto más rápido se realicen las operaciones de E / S del contenedor VDI, antes el demonio ovino puede proceder a la siguiente operación.

Lo importante es que con Sheepdog no habrá situación cuando uno de los nodos esté completamente lleno. Si la tasa de utilización en el nodo empeora mucho, entonces el demonio oveja comienza a mover sus objetos de datos a otra ubicación.

Sheepdog funciona igual que Btrfs, utilizando solo el espacio realmente ocupado. Por lo tanto, puede crear un contenedor VDI virtual con una capacidad de 1 TB, que en realidad ocupará tanto espacio como los datos almacenados en él. Desde este punto de vista, es deseable utilizar tales formatos de discos virtuales y sistemas de archivos en contenedores VDI que puedan limpiarse uno tras otro.

Lanzamiento de clúster

Si bien todos los nodos se pueden detener al mismo tiempo, los nodos no se pueden iniciar a la vez. Los nodos deben conectarse gradualmente. Comenzando con el nodo que se especificó por primera vez en la lista de nodos.
(Esta es una declaración extremadamente extraña - aproximadamente por)

Vdi

Esta es una abreviatura genérica en Sheepdog para disco virtual, no su formato específico. . En general, esta es una caja virtual con compartimentos de tamaño fijo, en la que Sheepdog luego coloca los datos que el cliente transmite.

Creando VDI

Antes de crear o importar el primer VDI, debemos formatear el clúster. Al formatear un clúster, se establecen parámetros que luego se usarán de manera predeterminada al crear cada VDI posterior.

Un ejemplo que demuestra la creación de un nuevo VDI llamado Disk1 y 1 GB de tamaño

 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
Identificador VDI

Tamaño
El tamaño del VDI que no necesariamente se asignará previamente de forma inmediata.
Si este VDI está en formato incremental (qcow2 y similares) creado usando qemu-img convert , no coincidirá con el tamaño del disco virtual, pero crecerá constantemente.

Usado
Información sobre cuánto espacio ocupan los objetos de datos VDI.
VDI, que no requiere la asignación de objetos de datos durante la creación, no ocupará nada en absoluto, ya que los objetos de datos aún no se han creado para ello.

Compartido
El volumen de objetos de datos que comparten otros VDI

Tiempo de creación
Tiempo de creación de VDI

Tamaño del bloque
El tamaño del objeto VDI. Atencion No se especifica en MB, sino como una potencia de dos bytes. En versiones anteriores, solo se usaban objetos de tamaño fijo de 4 MB. Actualmente, VDI puede tener objetos más grandes. El tamaño óptimo para el objeto VDI de una máquina virtual normal se parece a 64 MB (26). El tamaño predeterminado de 22 (4 MB) también es mínimo. Menos no se puede instalar. Cuanto más pequeño sea el tamaño del objeto, mayor será el número de archivos que Sheepdog tendrá que procesar mientras trabaja con VDI, y trabajar con archivos no es un problema barato desde el punto de vista de IO. Una gran cantidad de archivos, especialmente con controladores SATA lentos, puede conducir a un fuerte deterioro en las velocidades de lectura y escritura. El tamaño máximo de los objetos que se pueden usar es 31 (2 GB). Esto puede ser beneficioso si VDI almacena constantemente una gran cantidad de datos estáticos, como copias de seguridad.

Identificación de Vdi
Identificador de VDI.

¿Qué contiene VDI?

El contenido de VDI son datos. Este es un dispositivo de bloque distribuido, por lo que Sheepdog no resuelve estos datos o basura. Desde este punto de vista, VDI parece un volumen lógico LVM. Un VDI rellenado previamente corresponde a una partición LV clásica con un rango dedicado, mientras que VDI se asemeja a una partición LV delgada creada en un grupo (consulte LVM (thin_provisioning)), pero con la diferencia de que las extensiones de datos (objetos) no se almacenan localmente bloquean dispositivos y están dispersos entre nodos.

El formato VDI funciona en esta analogía como un sistema de archivos. Algunos ocupan extensiones reservadas (objetos) secuencialmente, otros los asignan como sus inodos y luego les envían datos directamente. Una combinación incorrecta del sistema de archivos de almacenamiento de nodos, el formato VDI y el sistema de archivos interno puede provocar una degradación significativa del rendimiento de E / S.

Cómo obtener información sobre VDI

Para obtener más información sobre el formato VDI, puede usar 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

A partir de la salida del comando, puede descubrir que disk1 tiene un tamaño nominal de 12G. Actualmente solo toma 4G. Como está en formato qcow2, es obvio que se creó como incremental.

 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

En este caso, Disk2 se creó como un VDI de 4 GB preasignado en formato sin formato con un tamaño de bloque de 2 GB, que en realidad solo toma dos 2 GB

Exportar VDI a archivo

El contenido VDI se puede exportar desde Sheepdog de varias maneras. Quizás lo más rápido es usar la lectura del perro . El comando es un poco confuso, pero solo significa: "Cargue el contenido del VDI y envíelo a STDOUT ..", que puede redirigirse a un archivo:

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

Si VDI tiene 10G pero solo se usa 2G, creará un archivo con una capacidad total de 10 GB.

En este comando, el contenido del VDI no cambia , por lo que si el contenido del VDI, por ejemplo, un disco virtual en el formato comprimido qcow2, se puede usar directamente

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

Otra forma de obtener el contenido de VDI en un archivo es usar qemu-img convert . No es tan rápido, pero le permite convertir VDI a otro formato utilizando diferentes opciones del formato de disco virtual correspondiente.

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

Copia de seguridad incremental

Crear copia de seguridad incremental

Delta entre la primera y la segunda instantánea.

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

Restaurar VDI de copia de seguridad incremental

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

Al importar una copia de seguridad incremental, el VDI debería tener, por supuesto, la instantánea desde la que se realizó la copia de seguridad.

Verificación leyendo el contenido original de la imagen de prueba

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

Importar VDI desde archivo

La importación de un disco virtual existente como un archivo FS local puede realizarse de manera similar a la exportación. Pero con la diferencia de que se usa la escritura de perro ("Leer datos de STDIN y escribir en un archivo VDI ...")

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

El contenido solo se puede importar a un VDI existente.
El VDI importado siempre ocupa más espacio que el archivo original, porque los bloques de datos desde los que se restaura el VDI contienen datos en el área marcada.

Si todavía no existe VDI y no sabemos cuánto espacio se necesitará para el disco virtual, podemos usar qemu-img convert

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

Aunque los formatos VDI como qcow2, qed y otros se pueden usar en VDI. Para la eficiencia de E / S, es mejor preasignar bloques de datos.
, 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!

Revista

— . 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 ...

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

^{autodefrag — , .}

^{nocow — (), — GlusterFS}

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

Referencias

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

Perro pastor