Partilhar via

Dimensionamento de clusters do Azure Service Fabric

  • Artigo

Um cluster do Service Fabric é um conjunto ligado à rede de máquinas virtuais ou físicas, no qual os microsserviços são implementados e geridos. Uma máquina ou VM que faz parte de um cluster é chamada de nó. Os clusters podem conter potencialmente milhares de nós. Depois de criar um cluster do Service Fabric, você pode dimensioná-lo horizontalmente (alterar o número de nós) ou verticalmente (alterar os recursos dos nós). Você pode dimensionar o cluster a qualquer momento, mesmo quando as cargas de trabalho estão em execução no cluster. À medida que o cluster é dimensionado, seus aplicativos também são dimensionados automaticamente.

Por que dimensionar o cluster? O aplicativo exige mudanças ao longo do tempo. Talvez seja necessário aumentar os recursos do cluster para atender ao aumento da carga de trabalho do aplicativo ou do tráfego de rede ou diminuir os recursos do cluster quando a demanda cair.

Dimensionamento para dentro e para fora ou dimensionamento horizontal

Altera o número de nós no cluster. Depois que os novos nós ingressam no cluster, o Gerenciador de Recursos de Cluster move os serviços para eles, o que reduz a carga nos nós existentes. Você também pode diminuir o número de nós se os recursos do cluster não estiverem sendo usados de forma eficiente. À medida que os nós saem do cluster, os serviços saem desses nós e a carga aumenta nos nós restantes. Reduzir o número de nós em um cluster em execução no Azure pode economizar dinheiro, já que você paga pelo número de VMs que usa e não pela carga de trabalho nessas VMs.

  • Vantagens: Escala infinita, em teoria. Se seu aplicativo foi projetado para escalabilidade, você pode habilitar o crescimento ilimitado adicionando mais nós. As ferramentas em ambientes de nuvem facilitam a adição ou remoção de nós, por isso é fácil ajustar a capacidade e você paga apenas pelos recursos que usa.
  • Desvantagens: Os aplicativos devem ser projetados para escalabilidade. Os bancos de dados de aplicativos e a persistência também podem exigir trabalho de arquitetura adicional para serem dimensionados. No entanto, coleções confiáveis nos serviços stateful do Service Fabric facilitam muito o dimensionamento dos dados do aplicativo.

Os conjuntos de dimensionamento de máquinas virtuais são um recurso de computação do Azure que você pode usar para implantar e gerenciar uma coleção de máquinas virtuais como um conjunto. Cada tipo de nó definido em um cluster do Azure é configurado como um conjunto de escala separado. Cada tipo de nó pode então ser dimensionado para dentro ou para fora independentemente, ter diferentes conjuntos de portas abertas e pode ter métricas de capacidade diferentes.

Ao dimensionar um cluster do Azure, lembre-se das seguintes diretrizes:

  • Os tipos de nó primário que executam cargas de trabalho de produção sempre devem ter cinco ou mais nós.
  • Os tipos de nós não primários que executam cargas de trabalho de produção com estado sempre devem ter cinco ou mais nós.
  • Os tipos de nó não primários que executam cargas de trabalho de produção sem monitoração de estado sempre devem ter dois ou mais nós.
  • Qualquer tipo de nó de nível de durabilidade de Ouro ou Prata deve sempre ter cinco ou mais nós.
  • Não remova instâncias/nós aleatórios de VM de um tipo de nó, sempre use o recurso escala do conjunto de escala da máquina virtual no recurso. A exclusão de instâncias aleatórias de VM pode afetar negativamente a capacidade do sistema de balancear a carga corretamente.
  • Se estiver usando regras de dimensionamento automático, defina as regras para que o dimensionamento (remoção de instâncias de VM) seja feito um nó de cada vez. Reduzir mais de uma instância de cada vez não é seguro.

Como os tipos de nó do Service Fabric em seu cluster são compostos por conjuntos de dimensionamento de máquina virtual no back-end, você pode configurar regras de dimensionamento automático ou dimensionar manualmente cada tipo de nó/conjunto de escala de máquina virtual.

Dimensionamento programático

Em muitos cenários, dimensionar um cluster manualmente ou com regras de dimensionamento automático são boas soluções. Para cenários mais avançados, no entanto, eles podem não ser o mais adequado. As potenciais desvantagens destas abordagens incluem:

  • O dimensionamento manual exige que você entre e solicite explicitamente operações de dimensionamento. Se as operações de dimensionamento forem necessárias com frequência ou em momentos imprevisíveis, essa abordagem pode não ser uma boa solução.
  • Quando as regras de dimensionamento automático removem uma instância de um conjunto de dimensionamento de máquina virtual, elas não removem automaticamente o conhecimento desse nó do cluster associado do Service Fabric, a menos que o tipo de nó tenha um nível de durabilidade Silver ou Gold. Como as regras de dimensionamento automático funcionam no nível do conjunto de dimensionamento (em vez de no nível do Service Fabric), as regras de dimensionamento automático podem remover nós do Service Fabric sem desligá-los normalmente. Essa remoção rude do nó deixará o estado do nó "fantasma" do Service Fabric para trás após as operações de expansão. Um indivíduo (ou um serviço) precisaria limpar periodicamente o estado do nó removido no cluster do Service Fabric.
  • Um tipo de nó com um nível de durabilidade de Ouro ou Prata limpa automaticamente os nós removidos, portanto, nenhuma limpeza adicional é necessária.
  • Embora existam muitas métricas suportadas por regras de dimensionamento automático, ainda é um conjunto limitado. Se o seu cenário exigir dimensionamento com base em alguma métrica não coberta nesse conjunto, as regras de dimensionamento automático podem não ser uma boa opção.

A forma como você deve abordar o dimensionamento do Service Fabric depende do seu cenário. Se o dimensionamento for incomum, a capacidade de adicionar ou remover nós manualmente provavelmente será suficiente. Para cenários mais complexos, regras de dimensionamento automático e SDKs que expõem a capacidade de dimensionar programaticamente oferecem alternativas poderosas.

Existem APIs do Azure que permitem que os aplicativos trabalhem programaticamente com conjuntos de dimensionamento de máquina virtual e clusters do Service Fabric. Se as opções de dimensionamento automático existentes não funcionarem para o seu cenário, essas APIs possibilitarão a implementação da lógica de dimensionamento personalizada.

Uma abordagem para implementar essa funcionalidade de dimensionamento automático "caseira" é adicionar um novo serviço sem estado ao aplicativo Service Fabric para gerenciar operações de dimensionamento. Criar seu próprio serviço de dimensionamento fornece o mais alto grau de controle e personalização sobre o comportamento de dimensionamento do seu aplicativo. Isso pode ser útil para cenários que exigem controle preciso sobre quando ou como um aplicativo é dimensionado para dentro ou para fora. No entanto, esse controle vem com uma compensação da complexidade do código. Usar essa abordagem significa que você precisa possuir código de dimensionamento, o que não é trivial. Dentro do método do serviço, um conjunto de gatilhos RunAsync pode determinar se o dimensionamento é necessário (incluindo a verificação de parâmetros como tamanho máximo do cluster e resfriamentos de escala).

A API usada para interações do conjunto de dimensionamento de máquinas virtuais (tanto para verificar o número atual de instâncias de máquina virtual quanto para modificá-lo) é a biblioteca fluente do Azure Management Compute. A biblioteca de computação fluente fornece uma API fácil de usar para interagir com conjuntos de dimensionamento de máquinas virtuais. Para interagir com o próprio cluster do Service Fabric, use System.Fabric.FabricClient.

No entanto, o código de dimensionamento não precisa ser executado como um serviço no cluster para ser dimensionado. Ambos IAzure e FabricClient podem se conectar aos recursos do Azure associados remotamente, portanto, o serviço de dimensionamento pode facilmente ser um aplicativo de console ou serviço do Windows executado de fora do aplicativo Service Fabric.

Com base nessas limitações, você pode querer implementar modelos de dimensionamento automático mais personalizados.

Dimensionamento para cima e para baixo ou dimensionamento vertical

Altera os recursos (CPU, memória ou armazenamento) dos nós no cluster.

  • Vantagens: A arquitetura de software e aplicativos permanece a mesma.
  • Desvantagens: Escala finita, uma vez que há um limite para o quanto você pode aumentar os recursos em nós individuais. Tempo de inatividade, porque você precisará colocar máquinas físicas ou virtuais offline para adicionar ou remover recursos.

Os conjuntos de dimensionamento de máquinas virtuais são um recurso de computação do Azure que você pode usar para implantar e gerenciar uma coleção de máquinas virtuais como um conjunto. Cada tipo de nó definido em um cluster do Azure é configurado como um conjunto de escala separado. Cada tipo de nó pode ser gerenciado separadamente. O dimensionamento de um tipo de nó para cima ou para baixo envolve a adição de um novo tipo de nó (com SKU de VM atualizado) e a remoção do tipo de nó antigo.

Ao dimensionar um cluster do Azure, lembre-se da seguinte diretriz:

  • Se reduzir um tipo de nó primário, você nunca deve reduzi-lo mais do que o permitido pela camada de confiabilidade.

O processo de dimensionamento de um tipo de nó para cima ou para baixo é diferente, dependendo se é um tipo de nó não primário ou primário.

Dimensionamento de tipos de nós não primários

Crie um novo tipo de nó com os recursos necessários. Atualize as restrições de posicionamento dos serviços em execução para incluir o novo tipo de nó. Gradualmente (um de cada vez), reduza a contagem de instâncias da contagem de instâncias do tipo de nó antigo para zero para que a confiabilidade do cluster não seja afetada. Os serviços migrarão gradualmente para o novo tipo de nó à medida que o tipo de nó antigo for desativado.

Dimensionamento do tipo de nó primário

Implante um novo tipo de nó primário com SKU de VM atualizada e, em seguida, desabilite as instâncias do tipo de nó primário original, uma de cada vez, para que os serviços do sistema migrem para o novo conjunto de escala. Verifique se o cluster e os novos nós estão íntegros e, em seguida, remova o conjunto de escala original e o estado do nó para os nós excluídos.

Se isso não for possível, você pode criar um novo cluster e restaurar o estado do aplicativo (se aplicável) a partir do cluster antigo. Você não precisa restaurar nenhum estado de serviço do sistema, eles são recriados quando você implanta seus aplicativos no novo cluster. Se você estava apenas executando aplicativos sem estado em seu cluster, então tudo o que você faz é implantar seus aplicativos no novo cluster, você não tem nada para restaurar.

Próximos passos