iSCSI: LUNs por alvo?

4

A minha pergunta refere-se especificamente ao ZFS / COMSTAR, mas suponho que seja geralmente aplicável a qualquer sistema iSCSI.

Se você preferir criar um alvo para cada LUN que deseja expor? Ou é uma boa prática ter um único destino com vários LUNs?

Será que alguma dessas abordagens tem impacto no desempenho? E existe algum ponto de cruzamento onde a outra abordagem faz sentido?

O caso de uso é para discos da VM, em que cada disco (zvol) é um LUN. Até agora, criamos um destino separado para cada VM; mas um único destino que contenha todos os LUNs provavelmente simplificaria muito o gerenciamento ... mas talvez precisássemos de centenas de LUNs por um único destino. (E, em seguida, possivelmente dezenas de conexões do iniciador para esse alvo)

    
por badnews 29.10.2013 / 21:40

2 respostas

5

A melhor prática é ter várias LUNs penduradas em um único destino. Quantos alvos variam, e quantos desses alvos estão realmente expondo os mesmos LUNs. Eu costumo recomendar um alvo por caminho do MPIO que seus clientes irão configurar, então, se eu estiver configurando o sistema, haverá pelo menos dois objetivos (mas eles são apenas parte do mesmo Grupo-alvo e Grupos do Portal de Destino). oferecendo as mesmas visualizações - é inteiramente para o iSCSI MPIO).

A única razão para ultrapassar os 2 Objetivos é geralmente a separação lógica causada por negócios, rede ou outras pressões específicas de casos de uso. 4, 8, e até 16 Alvos não é assim tão louco, dependendo do tamanho e da complexidade do ambiente. Se você está com mais de 16 anos, especialmente por muito, é cada vez mais possível que você tenha um erro na arquitetura e deve contratar um especialista para revisar. Se você está fazendo uso do iSCSI MPIO (e você deve , porque se você não estiver usando o iSCSI MPIO, provavelmente a única grande vitória de zvols e iSCSI sobre sistemas de arquivos e NFS será perdida e agora há muito pouca vantagem em ir iSCSI sobre NFS, e absolutamente toneladas de desvantagens), você também deve geralmente ter um número par de Targets (2, 4, 6, 8, etc), com cada par oferecendo as mesmas visualizações ( LUN's).

Lembre-se também de que o COMSTAR é inteligente o suficiente na maneira como trata as visualizações, desde que você realmente crie e atribua grupos-alvo e grupos de hosts de forma adequada, podendo ter um único alvo oferecendo dezenas ou até centenas de LUNs O ID LUN real exposto ao iniciador de entrada (cliente) NÃO é 578 ou qualquer outro, mas pode ser tão baixo quanto 0 para cada um. Isso é importante quando se lida com algum sistema operacional cliente, como o Linux (especialmente versões mais antigas), que têm um péssimo hábito de descobrir e atribuir dispositivos automaticamente para cada LUN que encontraram e ter um número máximo de LUNs que eles podem lidar E ter um número máximo de 'LUN' (o próprio número LUN em si, ao contrário da quantidade de LUNs vista) também.

Eu nunca gastei tempo para quantificá-lo, mas minha reação instintiva seria sentir a mesma quantidade de impacto no desempenho com 128 alvos, cada um com 1 LUN, como você se sentiria com 1 alvo com 128 LUNs, ou desempenho um pouco pior com os 128 alvos. Definitivamente, a expectativa da COMSTAR é que você está configurando os destinos com vários LUNs, em vez de 1 LUN por destino, já que os dias costumavam ser pré-COMSTAR.

Sobre o comentário sobre seu ambiente em geral:

Deve-se criar um LUN separado para cada VM somente em situações em que o número total de VMs é baixo (abaixo de 100, preferencialmente abaixo de 50) OU onde você não tem nenhuma forma de alta disponibilidade que exija exportar / importar o pool em situações em que os serviços estão off-line enquanto o pool está exportando / importando.

Isso tem a ver com o tempo que leva para exportar / importar e inicializar completamente um grupo de LUNs via COMSTAR sobre o ZFS. Cada zvol adicional adiciona X milissegundos ao tempo de importação. Não é um grande negócio com um par de dúzias, mas rapidamente causando um problema perceptível como você escala até o 1000's. Eu costumava gerenciar uma Sun 7410 com mais de 3.000 zvols que levou a melhor parte de 15 minutos para fazer um failover usando sua funcionalidade de clustering (que essencialmente exportava o pool de um nó e importava-o no outro ao fazer um failover manual, como foi o caso da monstruosidade de 15 minutos). Isso se deveu em grande parte ao número de conjuntos de dados e, mais ainda, que eles eram zvols. O mesmo cenário repetido com 3.000 sistemas de arquivos (não zvols) levou apenas 5 minutos (ainda longo, mas 3x mais curto, e isso foi há anos. Embora o tempo total para concluir essas tarefas tenha melhorado no ZFS desde então, o relativo diferença de zvols para sistemas de arquivos e tempo para importar e ficar on-line totalmente, por último eu verifiquei.

Agora, se você não tiver dois ou mais nós em sua configuração e estiver esperando exportar rapidamente & importação entre eles, a maior razão para não ter lotes de zvols se foi. Isso ainda não faz deles uma idéia particularmente boa, por uma série de outras razões não diretamente pertinentes à sua pergunta. Os benefícios que você ganha separá-los são compensados de alguma forma pela dor administrativa e de desempenho induzida por ter toneladas de zvols. Pelo meu dinheiro, eu recomendo ir NFS em vez disso, mesmo que (pessimamente, especialmente se) você deseja um conjunto de dados por VM.

    
por 31.10.2013 / 07:45
1

Múltiplos alvos aumentam sua área de superfície potencial. Realmente isso depende do número de links que seus switches têm para o seu armazenamento e, potencialmente, quantos estão entre os switches iSCSI dedicados que você deve usar.

Tem a ver com hashing e balanceamento de carga e o número de caminhos que você deseja ver. Idealmente, se você tiver quatro links do dispositivo de destino para a rede, deverá ter quatro endereços IP e, potencialmente, um quinto deles para "descobrir" os destinos.

Portanto, a única resposta real é: depende.

    
por 30.10.2013 / 00:32

Tags