Este é um re-hash de uma pergunta que pedi um tempo atrás - depois de um consultor ter lançado ideias para outras equipes do departamento, toda a questão foi levantada novamente, por isso estou procurando respostas mais detalhadas.
Pretendemos configurar um cluster SQL de várias instâncias em vários blades físicos que executarão diversos sistemas diferentes em cada instância do SQL. Em geral, haverá uma instância virtual do SQL em execução em cada host da VM. Novamente, na operação geral, cada host da VM será executado em uma lâmina subjacente dedicada. A configuração deve nos dar muita flexibilidade para manutenção de qualquer VM individual ou blade subjacente, com todas as instâncias do SQL capazes de fazer failover conforme necessário.
Meu plano original era fazer o seguinte:
O consultor sugeriu que, em vez disso, fizéssemos o seguinte:
A grande diferença é a adição do passo 4, por meio do qual agrupamos todas as VMs convidadas também. O argumento é que isso melhora ainda mais a manutenção, já que não temos vínculos entre o cluster SQL e o hardware físico. Em teoria, podemos migrar as VMs convidadas pelos hosts sem afetar o cluster do SQL, então, para os blades físicos de manutenção de rotina, movemos o cluster do SQL sem interrupção e sem necessidade de failover.
Parece uma boa ideia, mas não encontrei nada na internet onde as pessoas dizem que fizeram isso e funciona bem. Posso realmente fazer as migrações ao vivo dos convidados sem o cluster SQL hospedado dentro deles ficar chateado?
Alguém tem alguma experiência com essa configuração, boa ou ruim? Existem alguns prós e contras que eu não considerei?
Eu aprecio que o espelhamento também é uma opção valiosa a considerar - nesse caso, estamos favorecendo o clustering, pois ele fará o todo de cada instância e teremos um bom número de bancos de dados. Alguns bancos de dados são para sistemas pesados de terceiros que podem nem funcionar gentilmente com o espelhamento (e meu entendimento de clustering é que os failovers são completamente transparentes para os clientes).
Obrigado.
Se esses blades forem totalmente dedicados à execução do SQL Server, por que você está se preocupando com a virtualização?
Por que você não simplesmente instala o Windows Server e o SQL Server em cada um deles e configura seu cluster de acordo, sem a sobrecarga adicional de virtualização?
Parece complicado.
Eu teria que avaliar a "complexidade" da sua solução com a confiabilidade e a relativa simplicidade de uma implementação física de cluster do SQL em cluster.
Todos os bancos de dados são críticos? Na minha experiência, geralmente não, então tenho a tendência de hospedar os bancos de dados mais importantes em servidores que são configurados com resiliência total e o restante (geralmente uma grande proporção) em servidores SQL simples.
Isso permite que você se concentre em manter os sistemas mais importantes em funcionamento e não tente manter "todas as bolas no ar ao mesmo tempo".
Todos os servidores precisarão de manutenção de rotina regular. Dada a regularidade e gravidade e importância dos patches de segurança, nós nos afastamos da tentativa de manter um tempo de atividade dos teóricos (o que os usuários gostaram, mas não realmente PRECISAM) para um mais realista "vamos manter os servidores seguros e seguro - mas haverá janelas de manutenção OBRIGATÓRIAS curtas para nos permitir manter os servidores devidamente corrigidos. "
Das opções listadas, eu escolheria o # 2, mas eu não colocaria o SQL em cluster (etapa 5) porque está adicionando uma camada de complexidade da qual você não ganha muito. O clustering Hyper-V já permitirá que você execute essa VM em qualquer um dos hosts para que você esteja coberto por falhas de hardware.
Suponho que você esteja planejando usar VHDs de tamanho fixo para o log do SQL e os volumes do banco de dados.
Eu entendo completamente os comentários de outras pessoas sobre pular o Hyper-V completamente e apenas usar os dois blades como um cluster SQL normal - essa seria certamente a abordagem tradicional. No entanto, as vantagens de flexibilidade para virtualizar cargas de trabalho são enormes para manutenção, atualizações e falhas de hardware. A portabilidade das VMs é muito atraente.
Observe, porém, que o valor dessa solução também depende do seu ambiente. Se você não tiver outros servidores Hyper-V e sua equipe não tiver muita experiência com o Hyper-V, a virtualização de uma das cargas de trabalho mais críticas pode não ser uma boa ideia. No entanto, se você for como muitas lojas de TI e começar a virtualizar servidores menos importantes, tiver alguns hosts e possuir as habilidades e os procedimentos para executar o Hyper-V com segurança, expandir esse foco para cargas de trabalho mais críticas é completamente razoável. Pessoalmente, eu prefiro gerenciar clustering no nível do host vs no nível SQL e acho que veremos isso sendo feito cada vez mais, embora ainda não seja tão comum.
Finalmente, suas perguntas sobre a execução do SQL no Hyper-V: sim, a migração ao vivo funcionará bem com SQL e não será percebida - O espelhamento do db do E-SQL é ótimo, mas não é universalmente suportado, portanto ajuste cada situação.
A vantagem da configuração do seu consultor é que, se você fizer o failover apenas do hardware, ele não o protegerá de um serviço defeituoso ou não. É sempre bom ter redundância tanto no hardware quanto no software, então se você me perguntar, eu escolheria a opção 2 (considerando que você tem o orçamento e o conhecimento necessário, é claro)
Acho que seu consultor está certo. Eu tenho a idéia exata, como ele, que eu gostaria de implementar no meu ambiente atual. 2 partes físicas de hardware, cada peça de hardware executando o Hyper-V com 2 instalações W2k8.
Isso fornece seu nível completo de cluster de failiver e Complete H / A em seu ambiente SQL.
Ou talvez minha ideia seja estúpida?
para a questão nic, você deve ser capaz de resolver isso com nics teamed, eu não sei o que é o seu hardware, mas tem havido um monte de problemas como o Dell power edge 1950s, 2950s, R710s etc onde o nic torna-se um recebimento apenas nic e não envia corretamente o tráfego quando em HyperV. As unidades mais recentes e a configuração correta da equipe não apenas fornecerão redundância adicional, mas também aumentarão o desempenho.
Realmente, a Opção 1 e a Opção 2 estão muito próximas da mesma coisa. A maior questão é como você deseja que seus dados sejam acessados e para que sua SAN é projetada. O SQL 2008, na verdade, tem aumentos de desempenho quando executado na virtualização entre volumes compartilhados em cluster e, novamente, o SQL em cluster, porque o SQL é inteligente o suficiente para descarregar seus processos em vários nós SQL. Isso não só lhe dá um grande impulso no desempenho (imagine quando a Intel apareceu pela primeira vez com hyper-threading real), mas também aumenta o desempenho da sua infraestrutura para redes aéreas altas, sendo capaz de dividir o tráfego e usar o redirecionamento de pacotes.