Desempenho de wrt de ambiguidade SAN LUN
O MSDN diz para dividir as operações de leitura/gravação em uma unidade, gravações sequenciais em outra unidade. (O grupo de arquivos PRIMARY normalmente usa dados com atividade de leitura, atualização e gravação, enquanto o grupo de arquivos LOG é principalmente de gravação sequencial) A documentação é anterior às redes de área de armazenamento.
Eu recebo que o armazenamento de agrupamento para atividade de leitura/gravação otimizaria as cabeças no disco - minimizaria o thrashing do disco, tipo de coisa ... muitos discos?
O "gargalo" de E/S é então o controlador de E/S na SAN e controla o fluxo de dados dos dados em grupos de discos distribuídos? Ou seja, LUN1 exposto ao SO Server1 como 2 unidades de 500 GB, cada uma dividida em 2 unidades lógicas D:, E:; F:,G: de 250 GB cada: Um banco de dados com uma tabela de 750 GB criada em um grupo de arquivos de 4 arquivos (D:\f1.mdf, E:\f2.ndf, F:\f3.ndf, G:\f4.ndf ) terá paralelismo em todas as unidades lógicas (driver de arquivo do SO otimizado?) e o SQL pode usar mais threads de manipulador de arquivos? mas todo o IO ainda passa pelo controlador LUN com um máximo de 1 GB/s.
Ou a separação do DISK está implícita em divisões de nível de LUN? Significando LUN1 250GB, LUN2 250GB, LUN3 250, LUN4 250... cada um exposto ao SO como uma unidade física separada, mapeado para uma unidade lógica cada, e a MESMA divisão do GRUPO DE ARQUIVOS SOMENTE perceberia o benefício da taxa de transferência otimizada de IO? Acho que minha pergunta depende se o controlador de armazenamento SAN pode sustentar uma taxa de transferência de 1 GB/s em cada LUN.
Ou significa um controlador de armazenamento para cada LUN?
Alguém mais experiente pode aconselhar se a pegadinha de alinhar o striping ao tamanho do bloco NTFS é participante desta discussão? Blocos de tamanho de alocação do SO NTFS... oh! e o tamanho do pacote de rede - isso também é um fator de influência em termos de transferência de dados para o cliente? IPv6 vs IPv4 - isso também é um fator?
Fale com o administrador da SAN. Essa é a fonte que deve ser capaz de explicar com informações detalhadas que tipo de SAN você possui e do que ela é capaz. Você tem MPIO? Qual é a estrutura do seu tecido?
Às vezes, faz sentido usar vários LUNs para arquivos diferentes. Nos bastidores, pode haver diferentes tipos de armazenamento disponíveis.
Uma SAN com alguma capacidade SSD pode oferecer camadas. Ou seja, os dados mais quentes são elevados à parte do sistema com suporte de SSD, enquanto os dados mais frios são mantidos em HDDs. Alguns modelos fornecem autotiering, em que o sistema decide o que é bom e o que não é. Alguns modelos requerem ação administrativa.
Os HP EVAs fornecem níveis de VRAID 0, 1 e 5. Usá-los espalhará um LUN em todos os discos em um array. Isso aumenta a confiabilidade, mas o custo com o VRAID 5 é o aumento do uso da CPU do controlador. O administrador da SAN precisa equilibrar o aumento dos custos de armazenamento com o aumento do uso da CPU.
O alinhamento de blocos NTFS com armazenamento depende da SAN. Se você também estiver usando virtualização (Hyper-V, VMWare, o que for), isso é uma complexidade adicional. Seu fornecedor de armazenamento provavelmente oferecerá white papers, práticas recomendadas e serviços de consultoria sobre como configurar o armazenamento para obter um desempenho ideal.
O tamanho do pacote de rede é relevante - se você usar iSCSI. Para FibreChannel, as configurações de IP não são relevantes.