Quando falamos de cargas de trabalho virtualizadas, os bancos de dados podem estar em uma classe de tamanho só para eles. Este e outros fatores podem levar a vários desafios exclusivos que, na superfície, podem não parecer tão significativos, mas que, na realidade, podem afundar rapidamente um projeto ou sua implementação, se não for dada a devida atenção.
Se você precisa navegar em uma carga de trabalho do tamanho de um transatlântico no oceano virtual, passando por águas infestadas de iceberg, você vai querer se certificar de que seja capitão do Queen Mary – não do Titanic. Como você faz isso? O primeiro passo é entender onde estão os icebergs.
Recentemente, tive uma conversa com Thomas LaRock, presidente da Associação Profissional para SQL Server (PASS), que também vem a ser um dos nossos "geeks" aqui na SolarWinds, para ter sua opinião sobre este tópico. Veja o que aprendi:
CPU e alocação de memória
Primeiro, não trate um banco de dados como um servidor de arquivos quando falamos de configuração e alocação de recursos virtuais. As configurações típicas permitem um excesso de alocação de memória e CPU. No entanto, a configuração de CPU não deve ter mais de 1,5-2 vezes o número de núcleos lógicos que você tem. Quando se trata de memória, não permita uma alocação excessiva, se possível; chegue a no máximo 80 por cento. Como a utilização da memória chega perto de 100 por cento, você pode não ter recursos suficientes nem mesmo para reiniciar a máquina. Se forçar seus sistemas, certifique-se de que você não apenas tenha uma ferramenta de monitoramento de virtualização, mas que a utilize ativamente.
Estratégia de alta disponibilidade
A maioria dos administradores de virtualização usam instantâneos e vMotion (a opção preferida de Thomas) como abordagem principal para enfrentar preocupações de alta disponibilidade. No lado do Windows especificamente, os grupos de cluster e disponibilidade também são comuns. Embora as duas tecnologias possam ser eficazes, provavelmente não devem ser usadas em conjunto. Este é um exemplo de por que uma VM de banco de dados não utiliza o vMotion em outra VM como resultado de um problema de desempenho, mas o grupo de disponibilidade apenas vê isso como uma instância de servidor que não está mais respondendo. Se você usar as duas, certifique-se de que você não permita que o vMotion automático, por isso há sempre um operador na mistura para (espera-se) evitar problemas; caso contrário, coisas ruins podem acontecer.
Para a VM monstro ou não?
Você pode se perguntar se uma maneira fácil de superar os desafios dos bancos de dados virtualizados é simplesmente alocar uma das "VMs monstro" da VMware ou do Hyper-V para a instância do banco de dados e apenas resolver os problemas dando-lhes mais hardwares. No entanto, a melhor abordagem é colocar as VMs do banco de dados em um host de uso misto que inclui uma gama de produção, desenvolvimento, teste e outros tipos de carga de trabalho. A lógica é que, se você tem um host com nada além de um ou mais servidores de banco de dados em execução, então você não tem opções se acidentalmente ficar sem recursos. Com um host típico de uso misto, é menor a probabilidade de você ficar martelando um tipo de recurso, e, se você chegar a um gargalo de recursos, o impacto de desligar a VM de desenvolvimento ou de teste para fornecer recursos de curto prazo normalmente é menor do que desligar um banco de dados de produção.
Levar estas considerações e dicas em conta pode ajudar a garantir que seus bancos de dados virtualizados se mantenham flutuando por um bom tempo, em vez de se perderem por causa de um iceberg potencialmente evitável na viagem inaugural.
Michael Thompson, diretor de marketing de produtos para gestão de sistemas na SolarWinds
