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.