Selecionando um subsistema de disco para SQL 2008 / Hyper-V

Question

Atualmente, tenho um banco de dados do SQL Server 2005 de tamanho médio (4 GB) em execução em um Windows 2003 Server de 3 anos. [Xeon 2.8-2core, 2GB, 2x 73GB SCSI 10k - RAID 1]. Esse banco de dados termina um aplicativo ASP.NET OLTP em execução no mesmo servidor. O aplicativo também suporta relatórios do mesmo banco de dados (sem data warehouse, apenas algumas desnormalizações, onde são críticas).

A utilização da CPU no servidor atual não vale a pena mencionar, a utilização da memória é "tempo para considerar uma atualização" alta. O desempenho / utilização de disco é ... Não tenho certeza ... mas o desempenho de aplicativos e consultas permanece suficientemente rápido.

Pretendemos atualizar o hardware no próximo ano para contabilizar algum crescimento antecipado. Gostaria de migrar para o Windows 2008 R2 com Hyper-V para mais flexibilidade, etc ...

Pergunta: Uma SAN iSCSI fornece desempenho suficiente para executar o SQL 2008 em uma VM? Eu não estou achando uma boa orientação no google. Eu sei que a configuração é suportada (enquanto NAS não é), mas parece que o consenso é 'talvez, mas Fiber / HBA ou DAS é melhor'.

Quais são as métricas que devo avaliar no meu sistema atual para ajudar a orientar essa decisão? Há algum limite que eu deveria procurar que indicasse que o iSCSI não o cortaria?

Qualquer orientação ou informação muito apreciada!

ATUALIZAÇÃO: Além disso, alguns googling adicionais apareceram este artigo que tem algumas informações e links úteis:

    

Answer 1

Você deve fazer alguns benchmarks em sua atual utilização de disco com o Perfmon. Se você estiver migrando para um sistema com mais RAM, provavelmente verá algum tipo de redução na utilização do disco (como resultado de mais memória para o SQL Server com cache), mas o padrão de acesso específico de seus clientes determinará que finalmente.

Uma verificação muito rápida e realmente suja seria capturar "Disco Físico - Bytes de Disco / s" do servidor atual. Isso vai lhe dar um limiar de "limite inferior" sobre o que você gostaria em uma nova tecnologia de disco. Você deve ser capaz de obter alguns números dos vários fornecedores de iSCSI da taxa de transferência de suas soluções e usá-los como um dispositivo de medição bruto. Eu vi o SQL Server 2005 fornecendo desempenho muito aceitável em dois ambientes VMware diferentes, nos quais os alvos iSCSI estavam sendo usados. Mais uma vez, porém, o desempenho necessário para sua aplicação específica será o fator decisivo.

Eu já vi o throughput do iSCSI em todo o mapa, dependendo de quão complicado é o encanamento. Uma vez vi um VMware ESX instalado com arquivos VMDK em alvos iSCSI que são realmente arquivos VHD sendo exportados por uma máquina do Windows Server 2003 Storage Server Edition por Ethernet Gigabit, com esses arquivos VHD sendo armazenados em volumes NTFS respaldados por um gabinete DASD anexado o computador do servidor com um controlador RAID de gabinete, dirigindo catorze discos SAS de 146 GB. Ele não apresentou um desempenho estelar, como você pode imaginar. Por outro lado, fiquei satisfeito com o throughput (embora eu não tenha, na mão, um número que eu possa dar a você) sobre os arrays Dell EqualLogic sendo usados em alguns sites do Cliente (pré-datando meu envolvimento em ambos os casos, então eu não especifiquei ou selecionei - eu apenas os uso).

Procure a melhor solução para obter o desempenho necessário para o preço que você deseja gastar. Certifique-se de usar fatores além do desempenho em sua avaliação também. (considerações de garantia e serviço, o que acontece quando um disco falha, capacidade de redimensionamento de volume dinâmico, capacidade de expansão para unidades / gabinetes adicionais no futuro, capacidade de adicionar placas de rede / largura de banda etc.).

    

Answer 2

Eu teria pensado que a métrica principal do Perfmon era o comprimento da fila do disco, em vez de bytes / segundo do disco. O iSCSI é capaz de alta taxa de transferência, mas possui alta latência em comparação ao armazenamento conectado diretamente. Eu nunca usei iSCSI para um banco de dados SQL, mas, na minha experiência, o desempenho do SQL Server tende a ser dominado pelo acesso aleatório em vez de pelo acesso sequencial e quanto menor a latência, melhor. Se assim for, o iSCSI não é a escolha óbvia.

JR