Práticas recomendadas para implantações grandes de nós do Azure com o Microsoft HPC Pack
A partir do HPC Pack 2008 R2 com o Service Pack 1, os administradores e desenvolvedores de cluster do Windows HPC podem aumentar a potência do cluster local adicionando recursos computacionais sob demanda no Azure. Esse cenário de "intermitência" do cluster HPC com instâncias de função de trabalho do Azure permite cargas de trabalho de HPC maiores, às vezes exigindo milhares de núcleos além ou no lugar de recursos de cluster locais. Este tópico fornece diretrizes e recomendações de práticas recomendadas para ajudar no planejamento e implementação de uma grande implantação de nós do Azure de um cluster local do HPC Pack. Essas práticas recomendadas devem ajudar a minimizar a ocorrência de tempos limite de implantação do Azure, falhas de implantação e perda de instâncias dinâmicas.
Observação
- Essas práticas recomendadas incluem recomendações para o ambiente do Azure e a configuração do nó principal local. A maioria das recomendações também melhorará o comportamento de implantações menores de nós do Azure. Exceções a essas diretrizes são implantações de teste nas quais o desempenho e a confiabilidade dos serviços de nó principal podem não ser implantações críticas e muito pequenas, em que os serviços de nó principal não serão altamente estressados.
- Muitas das considerações para configurar um nó principal local para uma grande implantação do Azure também se aplicam a clusters que contêm um número comparativamente grande de nós de computação locais.
- Essas recomendações complementam o cluster, a rede e outros requisitos para adicionar nós do Azure a um cluster do Windows HPC. Para obter mais informações, consulte Requirements for Azure Nodes.
- Essas recomendações gerais podem mudar ao longo do tempo e talvez precisem ser ajustadas para suas cargas de trabalho de HPC.
Versões aplicáveis do HPC Pack e do SDK do Azure para .NET
Essas recomendações geralmente se baseiam no HPC Pack 2012 R2 e no HPC Pack 2012, mas também são úteis para implantações grandes executadas com o HPC Pack 2008 R2.
A tabela a seguir lista as versões do HPC Pack e as versões relacionadas do SDK do Azure para .NET às quais essas diretrizes se aplicam.
| HPC Pack | Azure SDK |
|---|---|
| HPC Pack 2012 R2 | SDK do Azure para .NET 2.2 |
| HPC Pack 2012 com Service Pack 1 (SP1) | SDK do Azure para .NET 2.0 |
| HPC Pack 2012 | SDK do Azure para .NET 1.8 |
| HPC Pack 2008 R2 com Service Pack 4 (SP4) | SDK do Azure para .NET 1.7 |
| HPC Pack 2008 R2 com Service Pack 3 (SP3) | SDK do Azure para .NET 1.6 |
Limites para grandes implantações de nós do Azure
Uma implantação de nós do Azure para um cluster HPC é considerada "grande" quando se torna necessário considerar a configuração do nó principal e quando a implantação exigirá uma porcentagem significativa do cluster de recursos do Azure que pode ser usado por um único serviço de nuvem. Uma implantação maior arriscaria tempos limite de implantação e perderia instâncias dinâmicas.
Importante
Cada assinatura do Azure recebe uma cota de núcleos e outros recursos, o que também afeta sua capacidade de implantar um grande número de nós do Azure. Para poder implantar um grande número de nós do Azure, primeiro você precisará entrar em contato com o Suporte da Microsoft para solicitar um aumento de cota principal para sua assinatura. Observe que uma cota é um limite de crédito, não uma garantia de disponibilidade de recursos.
A tabela a seguir lista números de limite práticos de instâncias de função comumente usadas para uma grande implantação de nós do Azure em um único serviço de nuvem. O limite depende do tamanho da máquina virtual (predefinido no Azure) escolhido para as instâncias de função do Azure.
| Tamanho da instância de função | Número de instâncias de função |
|---|---|
| A9 (com suporte a partir do HPC Pack 2012 R2) | 125 |
| A8 (com suporte a partir do HPC Pack 2012 R2) | 250 |
| A7 (com suporte a partir do HPC Pack 2012 com SP1) | 250 |
| A6 (com suporte a partir do HPC Pack 2012 com SP1) | 250 |
| Extra grande | 250 |
| Large | 500 |
| Médio | 800 |
| Small | 1000 |
Para obter detalhes sobre cada tamanho de máquina virtual, incluindo o número de núcleos de CPU e memória para cada tamanho, consulte Sizes for Cloud Services.
Para implantar mais do que esses números de limite de instâncias de função em um serviço com alta confiabilidade geralmente requer o envolvimento manual da equipe de operações do Azure. Para iniciar isso, entre em contato com seu representante de vendas da Microsoft, seu gerente de conta de suporte do Microsoft Premier ou com o Suporte da Microsoft. Para saber mais sobre planos de suporte, confira Planos de Suporte do Azure.
Embora não haja um limite difícil e exequível que se aplique a todas as implantações de nó do Azure, 1.000 instâncias por serviço de nuvem são um limite prático de produção.
Práticas recomendadas para usar o Azure para implantações grandes
Veja a seguir as diretrizes gerais para criar e usar implantações grandes do Azure com seu cluster HPC com êxito.
Fornecer sinais iniciais à equipe de operações do Azure
A menos que você tenha feito arranjos para implantar em um cluster dedicado do Azure em um data center, a recomendação mais importante é comunicar a necessidade à equipe de operações do Azure (por meio de um canal de Suporte da Microsoft) para uma grande quantidade de capacidade antecipadamente e planejar implantações adequadamente para eliminar a capacidade como o gargalo. Essa também é uma oportunidade para obter diretrizes adicionais sobre estratégias de implantação além daquelas descritas neste tópico.
Distribuir implantações para vários serviços de nuvem
É recomendável dividir grandes implantações em várias implantações de tamanho menor, usando vários serviços de nuvem, pelos seguintes motivos:
Para permitir a flexibilidade em iniciar e parar grupos de nós.
Para possibilitar a interrupção de instâncias ociosas após a conclusão dos trabalhos.
Para facilitar a localização de nós disponíveis nos clusters do Azure, especialmente quando instâncias Extra Grandes são usadas.
Para habilitar o uso de vários data centers do Azure para cenários de recuperação de desastre ou continuidade de negócios.
Não há um limite fixo no tamanho de um serviço de nuvem, mas as diretrizes gerais são inferiores a 500 a 700 instâncias de máquina virtual ou menos de 1000 núcleos. Implantações maiores arriscariam tempos limite de implantação, perda de instâncias dinâmicas e problemas com a troca de endereços IP virtuais.
O número máximo testado de serviços de nuvem para um único cluster HPC em geral é 32.
Observação
Você pode encontrar limitações no número de serviços de nuvem e instâncias de função que você pode gerenciar por meio do HPC Pack ou do Portal de Gerenciamento do Azure.
Ser flexível com a localização
Ter dependências em outros serviços e outros requisitos geográficos pode ser inevitável, mas pode ajudar se a implantação do Azure não estiver vinculada a uma região ou geografia específica. No entanto, não é recomendável colocar várias implantações em regiões geográficas diferentes, a menos que elas tenham dependências externas nessas regiões geográficas ou a menos que você tenha requisitos de alta disponibilidade e recuperação de desastre.
Ser flexível com o tamanho da máquina virtual
Ter dependências estritas em um determinado tamanho de máquina virtual (por exemplo, Extra Grande) pode afetar o sucesso das implantações em grande escala. Ter flexibilidade para ajustar ou até mesmo combinar tamanhos de máquina virtual para equilibrar contagens de instâncias e núcleos pode ajudar.
Usar várias contas de armazenamento do Azure para implantações de nó
É recomendável usar diferentes contas de armazenamento do Azure para implantações simultâneas de nós grandes do Azure e para aplicativos personalizados. Para determinados aplicativos restritos por E/S, use várias contas de armazenamento. Além disso, como prática recomendada, uma conta de armazenamento usada para uma implantação de nó do Azure não deve ser usada para fins diferentes do provisionamento de nós. Por exemplo, se você planeja usar o armazenamento do Azure para mover dados de trabalho e tarefa de e para o nó principal ou de e para os nós do Azure, configure uma conta de armazenamento separada para essa finalidade.
Observação
Você incorre em encargos pela quantidade total de dados armazenados e pelas transações de armazenamento nas contas de armazenamento do Azure, independentemente do número de contas de armazenamento do Azure. No entanto, cada assinatura limitará o número total de contas de armazenamento. Se você precisar de contas de armazenamento adicionais em sua assinatura, entre em contato com o Suporte do Azure.
Ajustar o número de instâncias de nó proxy para dar suporte à implantação
Nós de proxy são instâncias de função de trabalho do Azure que são adicionadas automaticamente a cada implantação de nó do Azure de um cluster HPC para facilitar a comunicação entre nós principais locais e os nós do Azure. A demanda por recursos nos nós proxy depende do número de nós implantados no Azure e dos trabalhos em execução nesses nós. Você geralmente deve aumentar o número de nós proxy em uma grande implantação do Azure.
Observação
- As instâncias de função proxy incorrem em encargos no Azure junto com as instâncias do nó do Azure.
- As instâncias de função proxy consomem núcleos alocados para a assinatura e reduzem o número de núcleos disponíveis para implantar nós do Azure.
O HPC Pack 2012 introduziu ferramentas de gerenciamento de HPC para configurar o número de nós proxy em cada implantação de nó do Azure (serviço de nuvem). (No HPC Pack 2008 R2, o número é definido automaticamente em 2 nós proxy por implantação.) O número de instâncias de função para os nós proxy também pode ser dimensionado ou reduzido usando as ferramentas no Portal de Gerenciamento do Azure, sem reimplantar nós. O número máximo recomendado de nós proxy para uma única implantação é 10.
Implantações maiores ou muito usadas podem exigir mais do que o número de nós proxy listados na tabela a seguir, que se baseia em uma utilização de CPU abaixo de 50% e largura de banda menor que a cota.
| Nós do Azure por serviço de nuvem | Número de nós proxy |
|---|---|
| <100 | 2 |
| 100 - 400 | 3 |
| 400 - 800 | 4 |
| 800 - 1000 | 5 |
Para obter mais informações sobre as opções de configuração de nó proxy, consulte Definir o número de nós de proxy do Azure.
Práticas recomendadas para configurar o nó principal para implantações grandes
Grandes implantações de nós do Azure podem colocar demandas significativas no nó principal (ou nós principais) de um cluster. O nó principal executa várias tarefas para dar suporte à implantação:
Acessa instâncias de nó proxy criadas em uma implantação do Azure para facilitar a comunicação com os nós do Azure (consulte Ajustar o número de instâncias de nó proxy para dar suporte aode implantação, neste tópico).
Acessa contas de armazenamento do Azure para blob (como pacotes de runtime), fila e dados de tabela.
Gerencia o intervalo de pulsação e as respostas, o número de proxies (começando com o HPC Pack 2012), o número de implantações e o número de nós.
À medida que as implantações do Azure aumentam em tamanho e taxa de transferência, o estresse colocado no nó principal do cluster HPC aumenta. Em geral, os principais elementos necessários para garantir que o nó principal possa dar suporte à implantação são:
RAM suficiente
Espaço em disco suficiente
Um banco de dados do SQL Server de tamanho adequado e bem mantido para os bancos de dados de cluster HPC
Especificações de hardware para o nó principal
A seguir estão sugeridas especificações mínimas para um nó principal para dar suporte a uma implantação grande do Azure:
8 núcleos de CPU
2 discos
16 GB de RAM
Configurar bancos de dados remotos do SQL Server
Para implantações grandes, recomendamos que você instale os bancos de dados de cluster em um servidor remoto que esteja executando o Microsoft SQL Server, em vez de instalar os bancos de dados de cluster no nó principal. Para obter diretrizes gerais para selecionar e configurar uma edição do SQL Server para o cluster, consulte Planejamento e ajuste da capacidade do banco de dados para o Microsoft HPC Pack.
Não configure o nó principal para funções de cluster adicionais
Como prática recomendada geral para a maioria das implantações de produção, recomendamos que os nós principais não sejam configurados com uma função de cluster adicional (função de nó de computação ou função de nó do agente do WCF). Fazer com que o nó principal atenda a mais de uma finalidade pode impedir que ele execute com êxito sua função de gerenciamento primário. Para alterar as funções executadas pelo nó principal, primeiro coloque o nó offline usando a ação em de Gerenciamento de Recursos (chamado de Gerenciamento de Nós em algumas versões do HPC Pack) no HPC Cluster Manager. Em seguida, clique com o botão direito do mouse no nó principal e clique em Alterar Função.
Além disso, mover o armazenamento do cluster para fora do nó principal garantirá que o nó principal não ficará sem espaço e funcionará efetivamente.
Usar os Utilitários de Cliente HPC para se conectar remotamente ao nó principal
Quando o nó principal está operando sob uma carga pesada, seu desempenho pode ser afetado negativamente por ter muitos usuários conectados com conexões de área de trabalho remota. Em vez de fazer com que os usuários se conectem ao nó principal usando o RDS (Serviços de Área de Trabalho Remota), os usuários e administradores devem instalar os Utilitários de Cliente do HPC Pack em suas estações de trabalho e acessar o cluster usando essas ferramentas remotas.
Desabilitar a coleta de contadores de desempenho e o encaminhamento de eventos
Para implantações grandes, a coleta de contadores de desempenho e o encaminhamento de eventos podem colocar uma grande carga no Serviço de Gerenciamento de HPC e no SQL Server. Para essas implantações, pode ser desejável desabilitar esses recursos usando as ferramentas de gerenciamento de cluster HPC. Por exemplo, defina a propriedade CollectCounters cluster como false usando o cmdlet Set-HpcClusterProperty HPC PowerShell. Pode haver uma compensação entre melhorar o desempenho e coletar métricas que podem ajudá-lo a solucionar problemas que surgem.
Desabilitar serviços de nó de cabeçalho desnecessários
Para garantir um volume mínimo de hardware do sistema operacional e como uma prática recomendada geral do cluster HPC, desabilite todos os serviços do sistema operacional que não são necessários para a operação do cluster HPC. Incentivamos especialmente a desabilitação de todos os recursos orientados à área de trabalho que possam ter sido habilitados.
Não execute NAT no nó principal
Embora o HPC Pack permita a configuração rápida do Serviço de Roteamento e Acesso Remoto (RRAS) em execução no nó principal para fornecer NAT (conversão de endereços de rede) e permitir que nós de computação cheguem à rede corporativa, isso pode tornar o nó principal um gargalo significativo para a largura de banda de rede e também pode afetar seu desempenho. Como prática recomendada geral para implantações ou implantações maiores com tráfego significativo entre nós de computação e a rede pública, recomendamos uma das seguintes alternativas:
Forneça uma conexão de rede pública direta para cada nó de computação.
Forneça um roteador NAT dedicado, como um servidor separado executando um sistema operacional Windows Server e que seja hospedado duasmente nas duas redes e executando o RRAS.
Garantir um período razoável de armazenamento para trabalhos concluídos
A propriedade TtlCompletedJobs do comando cluscfg e do set-HpcClusterProperty controle de cmdlet HPC por quanto tempo os trabalhos concluídos permanecem no banco de dados do SQL Server para o cluster HPC. Definir um valor grande para essa propriedade garante que as informações do trabalho sejam mantidas no sistema por um longo tempo, o que pode ser desejável para fins de relatório. No entanto, um grande número de trabalhos no sistema aumentará os requisitos de armazenamento e memória do sistema, já que o banco de dados (e as consultas nele) geralmente serão maiores.
Configurar um número razoável de pulsações perdidas antes de marcar nós inacessível
O HPC Pack usa um sinal de pulsação para verificar a disponibilidade do nó. A falta de resposta de um nó de computação a essa investigação de integridade periódica pelo Serviço de Agendador de Trabalho do HPC determina se o nó será marcado como inacessível. Configurando opções de pulsação na Configuração do Agendador de Trabalho no Gerenciador de Cluster do HPC, ou usando o comando cluscfg ou o cmdlet Set-HpcClusterProperty HPC, o administrador do cluster pode definir a frequência das pulsações (HeartbeatInterval) e o número de pulsações que um nó pode perder (InactivityCount) antes de ser marcado como inacessível. Por exemplo, o padrão HeartbeatInterval de 30 segundos pode ser aumentado para 2 minutos quando o cluster inclui uma implantação grande do Azure. O padrão InactivityCount é definido como 3, que é adequado para algumas implantações locais, mas deve ser aumentado para 10 ou mais quando os nós do Azure são implantados.
Observação
A partir do HPC Pack 2012 com SP1, o número de pulsações perdidas é configurado separadamente para nós locais e nós do Azure. A propriedade de cluster InactivityCountAzure configura o número de pulsações perdidas após as quais os nós de trabalho implantados no Azure são considerados inacessíveis pelo cluster. O valor padrão de InactivityCountAzure é definido como 10. A partir do HPC Pack 2012 com SP1, a propriedade InactivityCount se aplica exclusivamente a nós locais.
Se os nós do agente do WCF ou do nó principal estiverem configurados para alta disponibilidade em um cluster de failover, você também deverá considerar o sinal de pulsação usado por cada computador de cluster de failover para monitorar a disponibilidade do outro computador (ou computadores) no cluster de failover. Por padrão, se um computador perder cinco pulsações, uma vez a cada segundo, a comunicação com esse computador será considerada com falha. Você pode usar o Gerenciador de Cluster de Failover para diminuir a frequência de pulsações ou aumentar o número de pulsações perdidas em um cluster com uma implantação grande do Azure.
Se você estiver executando trabalhos soa (arquitetura orientada a serviço) nos nós do Azure, talvez seja necessário ajustar as configurações de tempo limite de monitoramento no arquivo de registro de serviço para gerenciar sessões grandes. Para obter mais informações sobre o arquivo de configuração do serviço SOA, consulte Arquivos de Configuração do Serviço SOA no Windows HPC Server 2008 R2.
Configurar uma chave do Registro para melhorar o desempenho das operações de preparo de arquivos
A partir do HPC Pack 2008 R2 com SP2, você pode definir uma chave do Registro no computador de nó principal para melhorar o desempenho de testes de diagnóstico,
Cuidado
A edição incorreta do registro pode danificar severamente seu sistema. Antes de fazer alterações no registro, você deve fazer backup de todos os dados valorizados no computador.
Consulte também
intermitência para instâncias de trabalho do Azure com o Microsoft HPC Pack
práticas recomendadas para o design de serviços de Large-Scale nos Serviços de Nuvem do Azure
de Diretrizes Técnicas de Continuidade de Negócios do Windows Azure