Você não especificou quantas VMs você tem ou o que elas farão. Mesmo sem essa informação, eu evitaria que alguém fizesse um grande LUN para fins de tamanho de bloco / desempenho, contenção e flexibilidade.
Com o VMFS5 não mais tendo o limite de 2 TB para um volume VMFS, estou considerando qual cenário seria mais benéfico em geral: -
No meu caso, tenho um novo storage array de 24 discos com discos de 600GB. Estarei usando o RAID10, aproximadamente 7,2 TB, e tentando decidir se devo ir com um grande armazenamento de dados de 7 TB, ou várias lojas de 1 TB cada.
Quais são os prós e contras de cada abordagem?
Atualização : Claro, deixei de incluir as peças de reposição quentes em meus cálculos, então será apenas 7,2 TB, mas a ideia geral é a mesma. : -)
Atualização 2 : existem 60 VMs e três hosts. Nenhuma de nossas VMs é particularmente intensiva em E / S. A maioria deles são servidores web / de aplicativos e também coisas como monitoramento (munin / nagios), 2 DCs do Windows 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 é de < 1GB.
Atualização 3 : mais algumas informações sobre a matriz e a conectividade do FC. A matriz é um IBM DS3524, 2 controladores com cache de 2 GB cada. 4 portas FC de 8 Gbit por controlador. Cada host do ESXi tem 2x HBAs FC de 4 Gbit.
Você não especificou quantas VMs você tem ou o que elas farão. Mesmo sem essa informação, eu evitaria que alguém fizesse um grande LUN para fins de tamanho de bloco / desempenho, contenção e flexibilidade.
Suponho que você virtualizará servidores, não desktops, tudo bem? Em seguida, vou assumir que você usará vários servidores ESX / ESXi para acessar seu armazenamento e gerenciá-los pelo vCenter Server.
Ao decidir sobre o tamanho da LUN e o número de VMFS, você está equilibrando vários fatores: desempenho, flexibilidade de configuração e utilização de recursos, embora limitado pela configuração máxima suportada de sua infraestrutura.
Você pode obter o melhor desempenho com 1 mapeamento de VM para 1 LUN / VMFS. Não há competição entre máquinas no mesmo VMFS, nenhuma contenção de bloqueio, cada carga é separada e tudo é ruim. O problema é que você vai gerenciar uma quantia invulgar de LUNs, atingir limites máximos suportados, enfrentar dores de cabeça com redimensionamento e migração de VMFS, ter recursos subutilizados (aquele espaço livre de ponto percentual único no VMFS) e geralmente criar uma coisa que não é legal administrar.
O outro extremo é um grande VMFS designado para hospedar tudo. Você obterá a melhor utilização de recursos dessa maneira, não haverá problemas em decidir o que implantar onde e os problemas com o VMFS X sendo um ponto de acesso, enquanto o VMFS Y estiver inativo. O custo será o desempenho agregado. Por quê? Por causa do bloqueio. Quando um ESX está gravando em um determinado VMFS, outro é bloqueado pelo tempo necessário para concluir o pedido de inserção e ter que tentar novamente. Isso custa desempenho. Fora dos ambientes de playground / teste e desenvolvimento, é uma abordagem errada para a configuração de armazenamento.
A prática aceita é criar datastores grandes o suficiente para hospedar um número de VMs e dividir o espaço de armazenamento disponível em partes de tamanho apropriado. Qual é o número de VMs depende das VMs. Você pode querer um único ou um par de bases de dados de produção críticas em um VMFS, mas permitir 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 de seu hardware (tamanho do disco, rpm, cache de controladores, etc.) e padrões de acesso (para qualquer nível de desempenho, você pode hospedar muito mais servidores da Web no mesmo VMFS que servidores de email).
Armazenamentos de dados menores também têm mais uma vantagem: impedem que você armazene fisicamente muitas máquinas virtuais por armazenamento de dados. Nenhuma pressão de gerenciamento atenderá a um terabyte extra de discos virtuais em um armazenamento de meio-terabyte (pelo menos até que eles ouçam sobre provisionamento thin e desduplicação).
Mais uma coisa: ao criar esses datastores, padronize em um único tamanho de bloco. Simplifica muitas coisas mais tarde, quando você quer fazer algo em datastores e ver erros feios "não compatíveis".
Atualização : O DS3k terá controladores ativos / passivos (ou seja, qualquer LUN pode ser servido pelo controlador A ou B, acessando o LUN através do controlador não-proprietário incorre em penalidade de desempenho), por isso vai pagar para ter um número par de LUNs, distribuídos uniformemente entre os controladores.
Eu poderia imaginar começar com 15 VMs / LUN com espaço para crescer até 20 ou mais.
A resposta curta à sua pergunta é: tudo depende de quais são seus padrões de IO, e isso será exclusivo para seu ambiente.
Eu sugiro que você dê uma olhada aqui link como este pode ajudá-lo a considerar sua IOPS prevista e quantas LUNS podem ser adequadas. Dito isto, se você errar do lado da cautela, algumas pessoas recomendariam ter muitas LUNS (se a minha correção para uma resposta anterior for aprovada, veja meus comentários sobre as filas LUN IO no lado da matriz). Eu tenho a tendência de concordar, mas iria mais além e, em seguida, colocá-los juntos em um único / poucos volumes VMFS (não acredito no FUD sobre extensões, e outros limites do VMFS link . Isso terá o benefício de gerenciar um / poucos armazenamentos de dados no vSphere e, como o vSphere equilibra automaticamente as VMs nas extensões disponíveis, começando com o primeiro bloco de cada extensão, o benefício de desempenho distribui seu IO por vários LUNs.
Outra coisa a considerar ... Você diz que nenhuma das VMs é particularmente intensiva em IO. Sendo assim, você pode 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 do aplicativo e do aplicativo espalhados nesses discos virtuais (por exemplo, SO, Web, DB, logs, etc. em um VMDK separado), você poderá localizar cada VMDK em um datastore diferente para corresponder às habilidades de IO desse LUN físico (por exemplo, OS em RAID5, Logs on RAID10). Tudo se resume a manter padrões de E / S semelhantes juntos para aproveitar o comportamento mecânico dos discos subjacentes de modo que, por exemplo, gravações de log em uma VM não afetem suas taxas de leitura da Web em outra VM.
FYI ... você pode virtualizar com sucesso os servidores de BD, você só precisa analisar os padrões de IO & Taxas de IOPS e segmentar esse IO para um LUN adequado; o tempo todo, ciente dos padrões de IO e IOPS que esse LUN já está fazendo. É por isso que muitos administradores culpam a virtualização pelo baixo desempenho do banco de dados ... porque eles não calcularam cuidadosamente o IO / IOPS que vários servidores gerariam quando eles os colocavam em um LUN compartilhada (ou seja, culpa do administrador, não culpa da virtualização).
Cada volume (LUN) tem sua própria profundidade de fila, portanto, para evitar a contenção de IO, muitas implementações usam LUNs menores. Dito isso, você pode criar LUNs de intervalo de dados com bastante facilidade. A desvantagem de datastores VMWare maiores (e menos) é, até onde eu sei, que você pode ter alguns limites no número de VMs que podem estar ativadas simultaneamente.
Outra consideração é o desempenho do controlador. Não conheço sua SAN especificamente, mas a maioria, senão todas, as SANs exigiam que um LUN fosse de propriedade de um único controlador por vez. Você deseja ter LUNs suficientes no sistema para poder equilibrar sua carga de trabalho entre os controladores.
Por exemplo, se você tivesse apenas um LUN, só usaria um controlador ativo de cada vez. O outro ficaria ocioso, pois não teria nada para fazer.
Se você tivesse dois LUNs, mas um era muito mais ocupado que o outro, você usaria os dois controladores, mas não da mesma forma. À medida que você adiciona mais LUNs, os controladores compartilham a carga de trabalho de maneira mais uniforme.
Conselhos específicos 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 as VMs no primeiro LUN e meça sua latência de E / S e a profundidade da fila ao longo do tempo conforme 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 terá migrado metade de suas VMs para esse LUN e ainda terá mantido o desempenho.
Se você vir problemas de desempenho, removerei 30% das VMs do LUN 1 e mova-as para LUN 2. Em seguida, comece a preencher o LUN 2 da mesma maneira. Vá para LUN 3 se necessário ... isso faz sentido? A ideia é atingir a densidade máxima de VMs em um determinado LUN, juntamente com uma sobrecarga de aproximadamente 30% para a sala de fudge.
Eu também criaria um par de LUNs de "alto desempenho" para VMs com grande impacto. Novamente, um por controlador para compartilhar a carga de trabalho.
Com base nas suas explicações acima, você deve estar bem com 1 datastore. Mais de 3 hosts de 60 vm não são tão ruins (20: 1). No entanto, eu recomendaria que você atualizasse os HBA's para 8Gb se financeiramente possível em pelo menos um host, desde que seu switch de fibra seja um mínimo de 8 Gb.
Dito isso, eu criaria pelo menos 2 datastores, se não 3, no array. 1 datastore por host, com todos os servidores acessando os outros para o vMotion. Eu não sei muito sobre o array IBM; com a EMC, eu 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 datastore / server, e há algumas instâncias que eu mesmo faço, mas só faço isso com a replicação SAN em servidores especiais. Gerenciando 87 datastores diferentes em 9 servidores para o vMotion fica confuso quando você o configura! A maioria dos meus vms estão em datastores compartilhados com 5-10 servidores dependendo de quanto espaço precisam.
Uma nota final. Se você tiver qualquer tipo de servidor em um par de failover / cluster ou carga balanceada, você os desejará em diferentes armazenamentos de dados. 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?
Parece que não há opção para evitar este erro: "Verificar o código de retorno: 20 (não é possível obter o certificado do emissor local)". Existe uma maneira de evitar a verificação SSL do emissor com AB (como a opção -no-check-certificate do wget)
Obrigado antecipadamente
Resposta curta: NÃO.
Relacionado link do contém algumas soluções alternativas .