Sheepdog é um sistema escalável que fornece dispositivos de bloco distribuídos para máquinas virtuais. Seu desenvolvimento começou em 2009 por desenvolvedores da empresa japonesa Nippon Telegraph and Telephone Corporation . Sheepdog é um aplicativo de código aberto sob a licença GPL2. A versão mais recente 0.9.3, lançada em novembro de 2015, será o legado da versão 1.0, adequada para uso comercial 1 . (já se tornou - aprox. por.)
Por uma questão de interesse, a primeira versão (0.1.0) foi lançada pelos desenvolvedores em agosto de 2010 - e, ao mesmo tempo, o suporte do sheepdog foi imediatamente incluído no principal ramo de desenvolvimento do QEMU.
Os primeiros testes em um cão pastor que realizei em novembro de 2011 2 e os resultados foram bons para operações de E / S. No entanto, o sistema Sheepdog ainda tinha problemas com a restauração do nó caído. Esse problema provavelmente foi resolvido em breve, pois o desenvolvimento do aplicativo é bastante animado, mas naquela época eu usava uma solução diferente.
As possibilidades
O princípio de funcionamento do Sheepdog é muito bem descrito na apresentação publicada, portanto, me limitarei a apenas uma breve visão geral.
É escalável
O volume do cluster pode ser arbitrariamente aumentado no nível do nó, aumentando a capacidade e o espaço para dados durante a operação e aumentando o número de nós. Quanto mais nós, maior o desempenho da E / S de VDI.
Ele é simples
Diferentemente de outros sistemas, como o CEPH, o Sheepdog não funciona diretamente com o sistema de arquivos, mas opera com blocos de tamanho fixo; portanto, não é necessário daemons separados para servir metadados. Todo o controle é realizado usando uma única ferramenta para cães que se comunica diretamente com as ovelhas
(o ceph também usa objetos - aprox. por.)
Calcula um nó caído
Cada VDI consiste nesses blocos (objetos) que são replicados simultaneamente para vários nós; portanto, se um deles cair, os dados permanecerão disponíveis e os objetos dos nós caídos começarão a se replicar para o outro nó.
Suporta instantâneos de dispositivo de bloco
Os instantâneos do Sheepdog funcionam da mesma forma que os Btrfs. Os blocos VDI anexados são salvos e novos dados são gravados em novos blocos.
As seguintes funções podem ser problemáticas em determinadas circunstâncias:
Sheepdog não suporta SPOF
Se o VDI for usado como um dispositivo de bloco via QEMU, poderá ocorrer um problema se ele estiver conectado ao mesmo tempo em vários locais. O SPOF 3 poderia ter evitado isso. Sheepdog não tem. No entanto, na nova versão do Sheepdog, o VDI pode ser bloqueado para não permitir mais de uma conexão.
O ciclo de vida dos objetos de dados
Os objetos VDI podem ser excluídos apenas quando todos os clones e instantâneos associados a eles forem excluídos. É exatamente o mesmo que para o Btrfs. Portanto, a remoção de instantâneos não utilizados pode não ser suficiente para liberar espaço para armazenamento.
Daemon de comunicação
O Sheepdog é ridiculamente pequeno comparado ao Ceph ou GlusterFS. Isso ocorre porque ele não tenta resolver todos os problemas sozinho, mas usa ao máximo o que já está funcionando.
Por sua vez, fornece um dispositivo de bloco que pode ser usado como um disco físico, bem como uma invasão de software, etc.
Ele se preocupa apenas com a distribuição de objetos de dados entre os nós nos quais está executando.
No entanto, ele precisa das informações que o daemon de comunicação fornece - um componente-chave sem o qual o Sheepdog não funcionará.
Daemon de comunicação - não fornece a capacidade de trocar dados entre nós. É isso que os demônios das ovelhas estão fazendo. Por meio dele, a ovelha só descobre quais nós estão vivos no momento.
corosync
Primeiro, o Sheepdog supõe que os nós se comuniquem entre si por meio de corosync . Ele suporta até 64 nós, embora teoricamente deva servir mais, seu uso é ideal para pequenos grupos de até 16 nós.
Normalmente, o corosync também usa o Pacemaker, portanto, não há necessidade de instalar mais nada.
Instale o corosync no Debian
O Corosync está nos repositórios de distribuição e sua instalação é simples:
$ apt-get install corosync libcorosync-common4
Configuração do Corosync
tratador
Os desenvolvedores de Sheepdog recomendam o uso do zookeeper para grupos maiores. Segundo os desenvolvedores, um armazenamento de teste Sheepdog com 1000 nós foi construído e testado 4 .
Instale o zookeeper no Debian
$ apt-get install zookeeper zookeeperd
Ativando o daemon ..
$ /usr/share/zookeeper/bin/zkServer.sh start
A porta padrão na qual o tratador é executado é 2181
Executando cão pastor com suporte a tratador:
$ sheep -c zookeeper:IP1:PORT1,IP2:PORT2,IP3:PORT3 ...other...option...
O bônus do zookeeper é que, no seu caso, o Sheepdog possui uma configuração mais clara e mais clara dos nós, mas há um problema que o pacote de instalação da Debian não inclui seu suporte.
Portanto, para obter um Sheepdog com suporte a zookeeper, você deve compilá-lo a partir do código-fonte. Embora eu não possa descartar que a situação possa ser diferente no momento.
(o suporte ao tratador de zoológico ainda requer compilação da fonte - aprox. por.)
Configurando o daemon de ovelhas
O nó se torna parte do Sheepdog quando o gerenciador de objetos, o daemon de ovelhas , é iniciado. Sempre funciona em duas cópias:
A primeira instância do processo inicia como um gateway, que recebe solicitações de E / S de clientes (por exemplo, dos drivers dos dispositivos de bloco QEMU), calcula os nós de destino e envia solicitações para processamento adicional entre eles. Ou seja, estabelece muitas conexões de rede.
- Outro funciona como um gerenciador de objetos local ( Gerenciador de Objetos )
Os parâmetros de configuração do daemon de ovelha podem ser passados como argumentos de linha de comando no tempo de execução. Se não houver nenhum, os valores padrão serão usados, com os quais você deve ter cuidado:
Número da porta
Salvo especificação em contrário, o daemon de ovelhas é executado na porta 7000
Caminho do Vault
A menos que especificado de outra forma, o diretório shep usa o diretório / var / lib / sheepdog e os objetos VDI são armazenados em seu subdiretório obj .
Teoricamente, nada impede que várias instâncias de ovelhas trabalhem em um nó - a principal condição é que todos usem seu número de porta e seu próprio armazenamento. A questão do endereço IP do nó está quase resolvida. Cada instância em execução do daemon de ovelhas em execução em uma porta diferente se conectará automaticamente a um cluster existente!
Informações importantes são que o número da porta faz parte da configuração do contêiner VDI. Você precisa saber se deseja reconfigurar o daemon do sheep para executar na outra porta do cluster existente.
Portanto, se você executar uma instância do daemon de ovelhas com um número de porta diferente, mas com o mesmo caminho para o armazenamento de objetos, poderá perder informações nos contêineres VDI existentes.
A ovelha demoníaca como uma porta de entrada
Em máquinas que não possuem espaço de armazenamento para objetos VDI, o daemon de ovelha pode ser executado exclusivamente no modo de gateway, com o sinalizador -G .
Nesse caso, ao distribuir objetos VDI, o armazenamento local não será usado e os dados serão distribuídos diretamente para outros nós.
Demônio das ovelhas como gerente de objetos
A segunda instância em execução, atua como um gerenciador de objetos local, recebe solicitações de E / S de uma instância que inicia como um gateway e executa operações de E / S no armazenamento de objetos local ( armazenamento de objetos )
Armazenamento de objetos
Por padrão, o armazenamento para objetos VDI no Sheepdog é o diretório /var/lib/sheepdog/obj , que também é usado pelo daemon sheep como parte de sua estrutura interna de diretórios - esse é o caminho de armazenamento padrão.
Se você deseja que os objetos VDI sejam armazenados em outro lugar, pode passar o caminho em que outro dispositivo de bloco está montado como parâmetro na inicialização.
sheep ... /cesta_do_přípojného_bodu
Existem ainda mais maneiras de transmitir. A nova versão do Sheepdog suporta a chamada tecnologia multi-dispositivo, que permite aumentar dinamicamente a capacidade da memória, se necessário, sem precisar reiniciar o Sheepdog . Aumentar a capacidade de armazenamento funciona de maneira semelhante ao Btrfs.
sheep ... /cesta_do_A,/cesta_do_B,/cesta_do_C
(o primeiro diretório especificado será usado apenas para metadados - aprox. por)
Armazenamento adicional também pode ser adicionado (ou removido) através do nó do cão md
...
A funcionalidade oferecida pelo dispositivo múltiplo é especialmente útil quando o sistema de arquivos de armazenamento não suporta isso "por design" (diferente dos Btrfs ou ZFS). Em geral, a escolha de um sistema de arquivos para armazenar objetos, suas propriedades, parâmetros e configurações pode afetar significativamente o desempenho do sistema de arquivos IO de uma máquina virtual.
A tecnologia para vários dispositivos requer atributos avançados no lado do arquivo, o que não é um problema para sistemas de arquivos modernos, como o btrfs 5 ou ext4. Mas alguns sistemas de arquivos mais antigos, como reiserfs ou ext2 6 Não os apoie.
Se você deseja usar um sistema de arquivos que não suporta atributos estendidos para armazenamento de objetos, precisamos compilar o Sheepdog sem suporte para vários dispositivos.
Tipo de armazenamento - comum versus árvore
Ao formatar um cluster, entre outras opções, você pode especificar o tipo de armazenamento (armazenamento de back-end). Você pode definir o tipo como simples ou em árvore . Para um tipo simples , a estrutura de diretórios terá a seguinte aparência:
| |- obj | |- <id > | | |-< > | | |-< > | | |-< > | | |- ... | |- <id > | | ... |- config [] |- epoch | |- < > | |- < > | |- ... |- journal \- sheep.log []
Todos os objetos VDI no diretório obj serão enviados para um subdiretório cujo nome se baseia no identificador de época atual. Ou seja, para cada época, os objetos VDI correspondentes serão armazenados separadamente. No entanto, durante uma época, um grande número de objetos VDI pode aparecer no diretório, o que atrasa o acesso aos arquivos posteriormente. Portanto, você pode escolher a segunda opção, que é a árvore :
|- obj | |- aa | | |-< > | | |-< > | | |-< > | | |- ... | |- ab | | ... | |- meta | | |- < > | | |- ... | |- 0a | | ... |- config [] |- epoch | |- < > | |- < > | |- ... \- sheep.log []
Nesse tipo de armazenamento, o daemon sheep cria um conjunto de 256 subdiretórios com os nomes 0a, ..., 99 no diretório obj e depois espalha objetos com base nos dois últimos caracteres do ID de VDI , que é exclusivo não apenas para cada contêiner de VDI, mas também para seus instantâneos ou clones.
Nomes de objetos VDI
Quando o Sheepdog salva os dados no contêiner VDI, os arquivos começam a aparecer no armazenamento de dados obj , cada um com seu próprio nome, composto por vários elementos:
../obj/8f/00e8b18f00000005 ^^
Os dois primeiros caracteres indicam o tipo de objeto. Os objetos de dados começam com 00... e metadados (que podem ser armazenados em outro diretório) 80...
../obj/8f/00e8b18f00000005 ^^^^^^
Depois vem o VDI. É exclusivo não apenas para cada contêiner, mas também para seu instantâneo ou clone.
../obj/8f/00e8b18f00000005 ^^ ^^
Os dois últimos dígitos do identificador VDI indicam - no caso do tipo de armazenamento em árvore - em que o subdiretório ao qual o objeto pertence está localizado.
../obj/8f/00e8b18f00000005 ^^^^^^^^
E o identificador do contêiner VDI em hexadecimal é seguido pelo número de série do objeto no contêiner VDI
Era
O subdiretório da epoch contém listas binárias de objetos pertencentes à época. O número da época aumenta, cada vez que cada cluster é alterado - quando um nó é adicionado ou removido. Cada uma dessas alterações inicia o processo de recuperação , durante o qual o estado atual dos objetos locais será verificado nos nós, seguido por um aumento na era.
Como escolher o armazenamento ideal de objetos VDI
A capacidade de armazenamento disponível é calculada com base no espaço livre nos nós. O espaço escolhido pelo sheep sempre depende de quanto espaço está disponível no dispositivo de bloco em que os objetos VDI estão armazenados.
O tamanho de um contêiner VDI é apenas uma forma virtual que não está de forma alguma relacionada à quantidade de espaço que os objetos VDI ocupam. É importante saber como o Sheepdog processa dados em um cluster:
O Sheepdog sempre tenta armazenar dados de maneira uniforme entre todas as máquinas da época.
Isso significa que, se um dos nós cair, a era mudar e o Sheepdog iniciar imediatamente o processo de recuperação, ele criará os objetos VDI ausentes nos nós restantes para compensar a perda.
Uma situação semelhante surgirá ao adicionar um novo nó. O Sheepdog começará a mover objetos VDI igualmente de novos nós para seu repositório, para que a porcentagem de preenchimento do espaço de dados nos nós seja o mais equilibrada possível. Use o comando a seguir para obter uma visão geral global de quanto espaço é atualmente usado em seus nós:
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
Desempenho de E / S
É importante dizer aqui que o Sheepdog funciona de maneira diferente do Ceph e tem prioridades diferentes.
Para Ceph, o "peso" do dispositivo OSD é crítico ao colocar objetos de dados, bem como o desempenho do dispositivo de bloco, a conectividade do host e a velocidade de resposta. (na verdade não - aprox. por)
Sheepdog faz algo assim, eu não sei. Possivelmente. Os dados para ele vêm em primeiro lugar. O desempenho em termos de operações de E / S é secundário. Obviamente, com nós mais poderosos, seu desempenho de E / S pode melhorar, mas sempre depende da estrutura específica. (no entanto, os testes mostram melhor desempenho do cão pastor em comparação com ceph - aprox. por)
Adicionei um novo nó ao Sheepdog com os dados armazenados em um disco rotativo de 2 TB SATA II. A velocidade máxima de gravação para este disco é de cerca de 80M / s. De fato, isso varia muito porque as unidades SATA não podem ler e escrever ao mesmo tempo.
Inicialmente, a velocidade média de gravação no VDI nesse disco era de cerca de 20 ~ 30M / s, pois além dos dados do VDI, os dados do contêiner 392G foram replicados nele como parte do processo de recuperação. Isso continuou por 6,5 horas. A velocidade de gravação variou entre 40 ~ 55M / s.
Obviamente, nesse caso, a velocidade de gravação foi limitada pelo desempenho de E / S do dispositivo de bloco local.
Para Sheepdog, a seguinte regra se aplica: "Quanto mais objetos VDI houver nos nós com conexão rápida, melhor o desempenho das operações de E / S".
Como mover objetos VDI em segundo plano significa que a “morte rápida de um nó” diminuirá a replicação dos objetos de dados que ocupam mais espaço, isso se manifestará como uma diminuição no desempenho das operações de E / S do contêiner VDI
Espaço ocupado
Ao colocar objetos de dados, a quantidade de espaço livre é crítica para o daemon de ovelhas . O mecanismo parece simples. O daemon de ovelhas , através do qual os dados são comunicados com o contêiner de VDI, de tempos em tempos determina a utilização do espaço livre e ocupado nos nós, que os classifica. Em seguida, os dados são distribuídos entre os nós com a menor taxa de utilização.
Se houver um caminho de gravação predominantemente rápido, a operação de gravação no contêiner VDI também será rápida. Como quanto mais rápidas as operações de E / S do contêiner de VDI são executadas, mais cedo o daemon do sheep pode prosseguir para a próxima operação.
O importante é que, com o Sheepdog, não haverá situação em que um dos nós esteja completamente cheio. Se a taxa de utilização no nó se tornar muito pior, o daemon de ovelhas começará a mover seus objetos de dados para outro local.
O Sheepdog funciona como o Btrfs - usando apenas o espaço realmente ocupado. Assim, você pode criar um contêiner VDI virtual com capacidade de 1 TB, que ocupará tanto espaço quanto os dados armazenados nele. Desse ponto de vista, é desejável usar esses formatos de discos virtuais e sistemas de arquivos em contêineres VDI que eles possam limpar um após o outro.
Lançamento de cluster
Embora todos os nós possam ser parados ao mesmo tempo, os nós não podem ser iniciados por vez !!! Os nós devem ser conectados gradualmente. Começando com o nó que foi especificado pela primeira vez na lista de nós.
(esta é uma afirmação extremamente estranha - aprox. por)
Vdi
Esta é uma abreviação genérica no Sheepdog para disco virtual, não no formato específico. . Geralmente, essa é uma caixa virtual com compartimentos de tamanho fixo, na qual o Sheepdog coloca os dados que o cliente transmite.
Criando VDI
Antes de criar ou importar o primeiro VDI, precisamos formatar o cluster. Ao formatar um cluster, são definidos parâmetros que serão usados por padrão ao criar cada VDI subsequente.
Um exemplo demonstrando a criação de um novo VDI chamado Disk1 e 1 GB de tamanho
root@nod1 :~
Id
Identificador VDI
Tamanho
O tamanho do VDI que não será necessariamente pré-alocado imediatamente.
Se esse VDI estiver no formato incremental (qcow2 e similares) criado usando o qemu-img convert , não corresponderá ao tamanho do disco virtual, mas aumentará constantemente.
Usado
Informações sobre quanto espaço os objetos de dados VDI ocupam.
O VDI, que não requer a alocação de objetos de dados durante a criação, não ocupará nada, pois os objetos de dados ainda não foram criados para ele.
Partilhado
O volume de objetos de dados que são compartilhados por outros VDIs
Tempo de criação
Hora de criação do VDI
Tamanho do bloco
O tamanho do objeto VDI. Atenção! Não é especificado em MB, mas como uma potência de dois bytes. Nas versões anteriores, apenas objetos de tamanho fixo de 4 MB eram usados. Atualmente, o VDI pode ter objetos maiores. O tamanho ideal para o objeto VDI de uma máquina virtual comum parece 64MB (26). O tamanho padrão de 22 (4 MB) também é mínimo. Menos não pode ser instalado. Quanto menor o tamanho do objeto, maior o número de arquivos que o Sheepdog terá que processar ao trabalhar com VDI, e trabalhar com arquivos não é um problema barato do ponto de vista do IO. Um grande número de arquivos, especialmente com controladores SATA lentos, pode levar a uma deterioração acentuada nas velocidades de leitura e gravação. O tamanho máximo de objetos que podem ser usados é 31 (2 GB). Isso pode ser benéfico se o VDI armazenar consistentemente uma grande quantidade de dados estáticos, como backups.
ID do Vdi
Identificador VDI.
O que contém o VDI?
Conteúdo VDI são dados. Como é um dispositivo de bloco distribuído, o Sheepdog não resolve esses dados ou lixo. Desse ponto de vista, o VDI parece um volume lógico do LVM. Um VDI pré-preenchido corresponde a uma partição LV clássica com um intervalo dedicado, enquanto o VDI se assemelha a uma partição LV fina criada em um pool (consulte LVM (thin_provisioning)), mas com a diferença de que a extensão de dados (objetos) não é armazenada localmente dispositivos de bloco e estão espalhados entre nós.
O formato VDI funciona nessa analogia como um sistema de arquivos. Alguns ocupam extensões reservadas (objetos) sequencialmente, outros os mapeiam como seus inodes e depois enviam dados diretamente para eles. Uma combinação incorreta do sistema de arquivos de armazenamento do nó, formato VDI e sistema de arquivos interno pode levar a uma degradação significativa do desempenho de E / S.
Para saber mais sobre o formato VDI, você pode usar as informações qemu-img :
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
Na saída do comando, você pode descobrir que o disco1 tem um tamanho nominal de 12G. Atualmente, são necessários apenas 4G. Como está no formato qcow2, é óbvio que foi criado 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
Nesse caso, o Disk2 foi criado como um VDI pré-alocado de 4 GB no formato bruto com um tamanho de bloco de 2 GB, que na verdade leva apenas dois
Exportar VDI para arquivo
O conteúdo VDI pode ser exportado do Sheepdog de várias maneiras. Talvez o mais rápido seja usar a leitura de cães . O comando é um pouco confuso, mas significa apenas: "Carregue o conteúdo do VDI e envie para STDOUT ..", que pode ser redirecionado para um arquivo:
root@nod1 :~
Se o VDI tiver 10G, mas apenas 2G for usado, ele criará um arquivo com capacidade total de 10 GB.
Nesse comando, o conteúdo do VDI permanece inalterado ; portanto, se o conteúdo do VDI, por exemplo, um disco virtual no formato qcow2 compactado, puder ser usado diretamente
.. -drive file=file:/disk1_exportovany_z_vdi,..,format=qcow2 ..
Outra maneira de obter o conteúdo da VDI em um arquivo é usar o qemu-img convert . Não é tão rápido, mas permite converter VDI para outro formato usando opções diferentes do formato de disco virtual correspondente.
root@nod1 :~
Backup incremental
Criar backup incremental
Delta entre o primeiro e o segundo instantâneo.
root@nod1 :~
Restaurar VDI do backup incremental
root@nod1 :~
Ao importar um backup incremental, é claro que o VDI deve ter a captura instantânea a partir da qual o backup foi feito.
Verificação através da leitura do conteúdo original do teste de imagem ...
root@nod1 :~
Importar VDI do arquivo
A importação de um disco virtual existente como um arquivo FS local pode ser executada de maneira semelhante à exportação. Mas com a diferença de que a gravação do cão é usada ("Lendo dados do STDIN e gravando em um arquivo VDI ..")
root@nod1 :~
- O conteúdo pode ser importado apenas para um VDI existente.
- A VDI importada sempre ocupa mais espaço que o arquivo original, porque os blocos de dados dos quais a VDI é restaurada contêm dados na área marcada.
Se o VDI ainda não existe e não sabemos quanto espaço será necessário para o disco virtual, podemos usar o qemu-img convert
root@nod1 :~
Embora formatos VDI como qcow2, qed e outros possam ser usados no VDI. Para eficiência de E / S, é melhor pré-alocar blocos de dados.
, Sheepdog VDI.
http://www.sheepdog-project.org/doc/vdi_read_and_write.html
VDI
VDI , .
root@nod1 :~
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 ...
- ↑ . 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
- ↑ 1
↑ Btrfs — COW, , . , -, . , , . , , . , :
autodefrag — , .
nocow — (), — GlusterFS
Btrfs , , FS, Sheepdog .
, , , Sheepdog.
↑ Ext2 . - FS Btrfs, ext2, inode. ext3 ext4 . inode , Sheepdog . , -, . , Sheepdog , dog vdi check . , ext2 , — - dog vdi md , VDI .
- ↑ , , vdi QEMU_Block_Disk
Referências
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