Configurando uma SAN multi-host

1

Estou procurando alguns conselhos sobre como configurar acesso de E / S de vários hosts em nossa SAN:

Eu tenho um blade blade (PowerEdge1000e) contendo um blade de armazenamento Equallogic PS-M4110 com um único volume RAID6 atualmente formatado como ext4.

Isso é conectado via iSCSI a um dos outros blades (todos executando o servidor Ubuntu 14.04) e montado lá como uma unidade padrão.

Agora estou tentando conectar outro dos blades no gabinete ao SAN de uma maneira que permita a E / S de vários hosts.

De preferência, tentando evitar a solução óbvia do NFS, porque algumas das ferramentas ligeiramente questionáveis codificadas que usamos têm o hábito de travar e gravar ao fazer alta E / S para NFS. Isso é particularmente problemático, uma vez que essas ferramentas levam semanas para serem executadas e não têm muitas oportunidades de verificação (você já imaginou que esse é um ambiente acadêmico?).

No entanto, tudo funciona bem com a configuração atual do iSCSI. Então, eu estava me inclinando para um sistema de arquivos + iSCSI com reconhecimento de cluster ou distribuído como a melhor opção, mas estou preocupado com problemas de divisão de cérebros, etc., pois temos apenas 1 nó.

1) Algum dos itens acima é sensato?

2) Você tem alguma recomendação de qual fs usar (compatível com FOSS e Linux preferível)?

    
por Eric S Nyberg 11.08.2014 / 15:51

2 respostas

0

O iSCSI é um protocolo em nível de bloco que lê / grava em disco bruto em uma rede. Não possui o conceito de bloqueio de arquivo. Como também é um protocolo de rede, ele permite várias conexões para um único destino. Você tem que ser capaz de garantir que o nível do sistema de arquivos acima do iSCSI tenha um bloqueio de arquivo adequado para evitar gravações simultâneas.

Eu nunca tentei (muito assustador). Já ouvi falar de exemplos em que as pessoas permitiram um acesso de leitura / gravação de uma máquina e outras apenas de leitura. Obviamente, muito depende do que você quer desses volumes. Por exemplo, o conteúdo baseado em disco de um servidor SQL obviamente exigiria um conhecimento profundo do mecanismo de bloqueio usado por esse servidor e, talvez, de um recurso de tabela somente leitura.

    
por 11.08.2014 / 17:43
0

O iSCSI, como foi mencionado, é um protocolo de acesso em bloco - acontece que ele viaja através de ethernet. É um plano terrível tentar fazer o IO de vários hosts em um dispositivo de bloco único. A maioria dos clusters não suporta isso por um motivo. Você precisa se preocupar com o armazenamento em cache em várias camadas por meio do SO e com a atomicidade de suas operações de E / S.

Mesmo com um 'gravável' e outro 'somente leitura' - o host 'somente leitura' está efetivamente sempre lendo um sistema de arquivos 'sujo'. Eu escrevi soluções de backup que - efetivamente - fazem isso tirando cópias clone, consistência, checa os clones e os monta para backup. Isso ainda funciona JUST, porque estou explicitamente liberando buffers de dados / host e assegurando que eu capture separadamente os logs de transações para que eu possa 'reproduzir' e corrigir o sistema de arquivos sujo.

O NFS existe por um motivo, e ele lida com acesso multi-host a sistemas de arquivos Unix de uma maneira bem limpa. Não é perfeito - você pode acabar tropeçando no sistema de arquivos, mas pelo menos não está corrompendo o sistema de arquivos toda vez que o usa.

Descobrir por que suas ferramentas estão bombardeando no NFS para iniciantes - você pode achar que é baixo para montagem brusca ou difícil, ou tempos limite no NFS. Ou tente mudar de TCP para UDP ou vice-versa.

Se você realmente precisa usar o iSCSI, sugiro que o que você queira fazer seja, como eu descrevi acima, uma abordagem de instância clone, em vez de uma IO concorrente compartilhada.

    
por 12.08.2014 / 16:50