Você tem alguma experiência boa ou ruim para compartilhar a execução de sistemas OLTP SQL Server em dispositivos NetApp? Tenho trabalhado com um cluster pequeno e de volume relativamente baixo com um dispositivo NetApp de baixo custo e descobri que o ambiente é geralmente instável, pelo menos em comparação com minhas experiências com outras SANs, arrays iSCSI e configurações de DAS. Tenho dificuldade em acreditar que RAID DP e WAFL são mais do que tecnologias de pó de fada. Foi-me proposta uma solução de que só preciso de um NetApp maior e melhor, com cartões PAM e outras tecnologias interessantes das quais nunca ouvi falar, e sinto que seria melhor gastar um quarto disso em boas conexões diretas. unidades e um servidor robusto. Ao mesmo tempo, sinto que uma SAN de classe empresarialdeveser algo com que posso contar para ser consistentemente mais estável e com melhor desempenho do que a solução mais barata que eu poderia propor. Você é um DBA SQL Server em um ambiente OLTP e adora NetApp? Se você não gosta deles, por que não?
Responder1
O SQL Server não funcionará (ou pelo menos não funcionaria recentemente) em um volume compartilhado SMB, pois o SMB não oferece suporte à semântica de bloqueio de arquivo necessária. Você precisará de LUNs expostos por meio de iSCSI, FC over Ethernet ou Fibre Channel para fazer isso. Se você estiver usando o NetApp como um arquivador compartilhando volumes SMB, essa pode ser a origem do seu problema.
Compre uma SAN se desejar recursos SAN (backups de instantâneos, etc.), caso contrário, compre o armazenamento de conexão direta. Se você realmente deseja apenas que uma caixa executando o SQL Server suporte um portfólio de aplicativos com carga moderada, uma única caixa grande do SQL Server com armazenamento de conexão direta provavelmente funcionará bem. Será mais barato, mais rápido e provavelmente custará menos no licenciamento do SQL Server.
Para alguns valores grandes, uma caixa Nelahem padrão de dois soquetes, como uma DL380 G6, provavelmente se qualificará. Isso custará dois soquetes de licenciamento do SQL Server, vem com 8 núcleos e ocupa até 192 GB de RAM. Pode acomodar 16 discos internamente e você pode conectar 100 ou mais externamente com opções de controlador de estoque e prateleira externa (MSA70). A maioria dos outros fornecedores oferece uma caixa com especificações semelhantes.
Se você estiver usando o SQL Server EE, a máquina e uma caixa DR provavelmente custarão menos do que o licenciamento do SQL Server para dois soquetes. Se você está começando aos poucos, preencha apenas um soquete e economize US$ 20 mil ou mais no licenciamento.
Acho que esse tipo de caixa é subestimado e está cada vez mais subestimado atualmente - já que VMs e blades estão na moda agora. No entanto, esta é uma máquina muito poderosa, capaz de suportar uma carga de trabalho de banco de dados bastante agressiva por apenas dois soquetes de licenciamento do SQL Server. Se você estiver atualmente em uma SAN de baixo custo, isso custará menos e gerará anéis para obter desempenho.
Responder2
Se tudo o que importa é executar o MSSQL em um cluster, sugiro que seria muito melhor optar por um array FC dedicado de 8 Gbps - certamente se o desempenho sob carga for a principal preocupação e o preço final for um problema menor . Obviamente, se você não precisa de clustering, a postagem do CoTW acima apresenta um forte argumento a favor do DAS (eu também adoro MSAs;))
Somos principalmente uma casa HDS/HP-XP e HP-EVA, mas ainda temos MUITAS caixas NetApps por aí, simplesmente porque são um compromisso realmente bom. Ter uma única caixa que geralmente é melhor do que suficiente em todos esses protocolos pode ser uma verdadeira vantagem. Dito isso, na minha opinião, eles não fazem FC/FCoE tão bem quanto caixas dedicadas e não são muito melhores que OpenFiler etc. para iSCSI/NFS - eu também acho que eles são um porco para configurar a partir de 'bare metal ' se você tiver um ambiente razoavelmente complexo. Mas não há como negar que os NetApps parecem ser de grande valor para muitas pessoas, só tenho minhas dúvidas pessoalmente.