Dimensionamento do VMware VMFS5 e LUN - vários repositórios de dados menores ou 1 repositório de dados grande?

Como o VMFS5 não tem mais o limite de 2 TB para um volume VMFS, estou considerando qual cenário seria mais benéfico em geral: -

• Menos LUNs de tamanho maior ou
• Mais LUNs de tamanho menor.

No meu caso, eu tenho uma nova matriz de armazenamento de 24 discos com discos de 600 GB. Vou usar o RAID10, de aproximadamente 7,2 TB, e tentar decidir se devo usar 1 grande datastore de 7 TB ou vários repositórios de 1 TB cada.

Quais são os prós e os contras de cada abordagem?

Atualização : Evitei incluir hot spares no meu cálculo, portanto, ele fica abaixo de 7,2 TB, mas a idéia geral é a mesma. :-)

Atualização 2 : existem 60 VMs e 3 hosts. Nenhuma de nossas VMs é particularmente intensiva em E / S. A maioria deles são servidores de aplicativos / web e também coisas como monitoramento (munin / nagios), 2 Windows DCs com carga mínima e assim por diante. Os servidores de banco de dados raramente são virtualizados, a menos que tenham requisitos de E / S MUITO baixos. No momento, acho que o único servidor de banco de dados virtual que temos é uma caixa MSSQL e o banco de dados nessa caixa é <1 GB.

Atualização 3 : Mais algumas informações sobre a matriz e a conectividade FC. A matriz é um IBM DS3524, 2 controladores com cache de 2 GB cada. 4x portas FC de 8Gbit por controlador. Cada host ESXi possui 2x HBAs de 4Gbit FC.

Você não especificou quantas VMs você tem ou o que elas farão. Mesmo sem essas informações, eu evitaria fazer um grande LUN por motivos de tamanho / desempenho, contenção e flexibilidade.

Vou assumir que você vai virtualizar servidores, não desktops, certo? Em seguida, assumirei que você usará vários servidores ESX / ESXi para acessar seu armazenamento e gerenciá-los pelo vCenter Server.

Ao decidir o tamanho do LUN e o número de VMFS, você está equilibrando vários fatores: desempenho, flexibilidade de configuração e utilização de recursos, enquanto está limitado pela configuração máxima suportada de sua infraestrutura.

Você pode obter o melhor desempenho com o mapeamento de 1 VM para 1 LUN / VMFS. Não há concorrência entre máquinas no mesmo VMFS, nenhuma contenção de bloqueio, cada carga é separada e tudo fica bem. O problema é que você gerenciará uma quantidade absurda de LUNs, poderá atingir limites máximos suportados, enfrentar dores de cabeça com o redimensionamento e a migração do VMFS, ter recursos subutilizados (o espaço livre único de ponto percentual no VMFS se soma) e geralmente criar algo que não é legal de gerenciar.

O outro extremo é um grande VMFS designado para hospedar tudo. Dessa forma, você obterá a melhor utilização dos recursos, não haverá problemas em decidir o que implantar onde e os problemas com o VMFS X sendo um hot spot, enquanto o VMFS Y estiver ocioso. O custo será o desempenho agregado. Por quê? Por causa do bloqueio. Quando um ESX está gravando em um determinado VMFS, outro fica bloqueado pelo tempo que leva para concluir a E / S e precisa tentar novamente. Isso custa desempenho. Fora dos ambientes de playground / teste e desenvolvimento, é uma abordagem incorreta à configuração de armazenamento.

A prática aceita é criar datastores grandes o suficiente para hospedar várias VMs e dividir o espaço de armazenamento disponível em blocos de tamanho apropriado. Qual é o número de VMs depende das VMs. Você pode querer uma ou duas bases de dados críticas de produção em um VMFS, mas permita três ou quatro dúzias de máquinas de teste e desenvolvimento no mesmo armazenamento de dados. O número de VMs por armazenamento de dados também depende do seu hardware (tamanho do disco, rpm, cache dos controladores, etc.) e dos padrões de acesso (para qualquer nível de desempenho especificado, você pode hospedar muito mais servidores Web no mesmo VMFS do que os servidores de email.

Os repositórios de dados menores também têm mais uma vantagem: impedem que você fisicamente sobrecarregue muitas máquinas virtuais por repositório de dados. Nenhuma pressão de gerenciamento caberá a um terabyte extra de discos virtuais em um armazenamento de meio terabyte (pelo menos até que eles saibam sobre o provisionamento thin e a desduplicação).

Mais uma coisa: ao criar esses datastores, padronize em um único tamanho de bloco. Isso simplifica muitas coisas mais tarde, quando você deseja fazer algo entre os datastores e ver erros feios "não compatíveis".

Atualização : o DS3k terá controladores ativos / passivos (ou seja, qualquer LUN fornecido pode ser atendido pelo controlador A ou B, acessando o LUN por meio do controlador não proprietário incorre em penalidade de desempenho); portanto, vale a pena ter um número par de LUNs , distribuído igualmente entre controladores.

Eu poderia imaginar começando com 15 VMs / LUN com espaço para crescer para 20 ou mais.

A resposta curta para sua pergunta é: tudo depende de quais são seus padrões de IO e isso será exclusivo para o seu ambiente.

Sugiro que você dê uma olhada aqui http://www.yellow-bricks.com/2011/07/29/vmfs-5-lun-sizing/, pois isso pode ajudá-lo a considerar suas IOPS antecipadas e quantos LUNS podem ser adequados. Dito isto, se você errar por precaução, algumas pessoas recomendariam ter muitos LUNS (se minha correção para uma resposta anterior for aprovada, consulte meus comentários sobre as filas de LUN IO no lado da matriz). Eu concordo, mas iria mais longe e depois estendê-los juntos em um único / poucos volumes VMFS (não acredite no FUD sobre extensões e outros limites VMFS http://virtualgeek.typepad.com/virtual_geek/2009/03 /vmfs-best-practices-and-counter-fud.html) Isso terá o benefício de gerenciar um único / poucos datastores no vSphere e, como o vSphere equilibra automaticamente as VMs sobre as extensões disponíveis, começando com o primeiro bloco de cada extensão, o benefício de desempenho espalha sua IO por várias LUNs.

Outra coisa a considerar ... Você diz que nenhuma das VMs é particularmente intensiva em E / S. Diante disso, convém considerar uma combinação de RAID5 e RAID10, para obter o melhor dos dois mundos (espaço e velocidade).

Além disso, se você tiver suas VMs configuradas com vários VMDKs, com os padrões de E / S de aplicativo e SO espalhados por esses discos virtuais (por exemplo, SO, web, banco de dados, logs, etc, cada um em um VMDK separado), poderá localizar cada VMDK em um armazenamento de dados diferente para corresponder às habilidades de E / S desse LUN físico (por exemplo, SO no RAID5, Logs no RAID10). O objetivo é manter padrões de E / S semelhantes semelhantes para aproveitar o comportamento mecânico dos discos subjacentes, de modo que, por exemplo, as gravações de log em uma VM não afetem as taxas de leitura da Web em outra VM.

Para sua informação ... você pode virtualizar servidores de banco de dados com êxito, basta analisar os padrões de IO e taxas de IOPS e direcionar essa IO para um LUN adequado; o tempo todo ciente dos padrões de IOPS e IOPS que esse LUN já está fazendo. É por isso que muitos administradores culpam a virtualização pela baixa performance do banco de dados ... porque eles não calcularam cuidadosamente o IO / IOPS que vários servidores gerariam quando os colocassem em um LUN compartilhado (ou seja, é culpa dos administradores, não da virtualização )

Cada volume (LUN) possui sua própria profundidade de fila, portanto, para evitar contenção de E / S, muitas implementações usam LUNs menores. Dito isso, você pode fazer um armazenamento de dados abranger LUNs com bastante facilidade. A desvantagem de armazenamento de dados VMWare maiores (e menos) é, até onde eu sei, que você pode encontrar alguns limites no número de VMs que podem estar simultaneamente.

Outra consideração é o desempenho do controlador. Não conheço sua SAN especificamente, mas a maioria, se não todas, exige que um LUN seja de propriedade de um único controlador por vez. Você deseja ter LUNs suficientes no sistema para poder equilibrar sua carga de trabalho entre controladores.

Por exemplo, se você tivesse apenas um LUN, usaria apenas um controlador ativo por vez. O outro ficava ocioso, pois não tinha nada para fazer.

Se você tivesse dois LUNs, mas um fosse muito mais ocupado que o outro, estaria usando os dois controladores, mas não igualmente. À medida que você adiciona mais LUNs, os controladores compartilham a carga de trabalho de maneira mais uniforme.

Conselho específico para você:

Suas VMs são todas relativamente iguais em termos de requisitos de desempenho. Eu criaria dois LUNs, um por controlador. Comece a colocar VMs no primeiro LUN e meça a latência de E / S e a profundidade da fila ao longo do tempo à medida que as VMs se instalam. Não use o segundo LUN ainda. Continue preenchendo o LUN 1. Você chegará a um ponto em que começará a ver indicadores de desempenho de que o LUN está cheio ou migrará metade das suas VMs para esse LUN e ainda manterá o desempenho.

Se houver problemas de desempenho, eu removeria 30% das VMs do LUN 1 e as moveria para o LUN 2. Em seguida, comece a preencher o LUN 2 da mesma maneira. Vá para o LUN 3, se necessário ... isso faz sentido? A idéia é atingir a densidade máxima da VM em um determinado LUN, juntamente com uma sobrecarga de aproximadamente 30% para a sala de fudge.

Eu também faria um par de LUNs de "alto desempenho" para todas as VMs de grande impacto. Novamente, um por controlador para compartilhar a carga de trabalho.

Com base nas explicações acima, você deve ficar bem com 1 armazenamento de dados. Mais de 3 hosts de 60 vm não são tão ruins (20: 1). No entanto, eu recomendaria que você atualize os HBAs para 8Gb, se possível financeiramente em pelo menos um host, desde que seu comutador de fibra seja um comutador de 8Gb no mínimo.

Dito isto, eu faria pelo menos 2, se não 3, datastores na matriz. 1 armazenamento de dados por host, com todos os servidores acessando os outros para o vMotion. Eu não sei muito sobre a matriz IBM; com a EMC, criaria um único grupo RAID10 com 3 LUNs para cada armazenamento de dados. Com essa configuração, o host com os HBAs de 8 GB seria ótimo para seus sistemas de E / S mais altos.

Você pode fazer 1 armazenamento de dados / servidor e há algumas instâncias em que eu faço isso, mas somente na replicação da SAN em servidores especiais. O gerenciamento de 87 datastores diferentes em mais de 9 servidores para o vMotion fica confuso quando você o configura! A maioria dos meus vm está em datastores compartilhados com 5 a 10 servidores, dependendo da quantidade de espaço necessário.

Uma nota final. Se você tiver algum tipo de servidor em um par / cluster de failover ou carga equilibrada, precisará deles em diferentes datastores. Você não deseja que o armazenamento de dados falhe e fique sem servidores. É certo que, se você perder a matriz, você perdeu tudo, mas é por isso que fazemos backup, certo?