Usando o Gerenciador de Tráfego do Azure para um aumento imediato de capacidade

1

Eu tenho um serviço web REST no Azure que tem carga muito alta, mas variável, é tudo configurado para escala automática usando Paraleap para que ele possa lidar com os períodos de pico, mas mantenha os custos baixos quando as coisas estão mais silenciosas.

Eu nunca consegui descobrir uma maneira, usando qualquer métrica, de prever quando um servidor vai começar a estourar antes , na verdade, maximiza! Assim, a solução que tenho no momento é um programa separado que verifica constantemente se o servidor está ativo, se ele começa a retornar erros, então ele diz ao servidor para começar a retornar uma mensagem de erro para uma certa porcentagem de usuários, retornando um erro simples ocupa menos dos recursos dos servidores, o que permite que a maioria dos usuários ainda tenha um serviço e, em seguida, informa à Paraleap para aumentar o número de instâncias. Aumentar as instâncias leva de 10 a 15 minutos normalmente, portanto, durante esse período, as coisas não são boas e alguns usuários obtêm erros, mas, em última análise, a nova instância é acionada e o serviço normal é retomado.

Eu esperava que o Azure Traffic Manager fosse minha solução, minha esperança era que eu pudesse usar o modo de failover e, quando uma falha fosse detectada no meu serviço web principal, eu poderia desviar x% das solicitações para um backup, que retornaria o serviço principal para um estado de funcionamento .. ao mesmo tempo eu diria independentemente ao serviço web principal para escalar, e quando terminasse, o gerente de tráfego iria desviar tudo de volta para o serviço web principal. Em outras palavras, eu obteria um aumento de instant na capacidade que preencheria a lacuna enquanto eu inicializava novas instâncias.

Infelizmente, não consigo encontrar uma maneira de fazer isso! Parece que o Traffic Manager, ao detectar uma falha, desvia 100% do tráfego para o backup. Então, eu precisaria mais do que duplicar minha capacidade de servidor apenas para esses momentos, ou seja, ter instância X para o serviço web principal e x + 1 esperando no backup, uma falha com principal mergulharia 100% das solicitações de backup que Se eu tivesse mais capacidade, então eu lançaria mais instâncias para a principal, eventualmente, o Gerenciador de Tráfego enviaria todas as solicitações de volta lá, quando eu precisaria adicionar mais instâncias ao backup e esperar que ele ficasse novamente. Isso seria um exagero enorme e me custaria uma fortuna!

Alguém tem alguma sugestão sobre como posso gerenciar isso melhor?

Obrigado!

    
por Steven Elliott 21.01.2015 / 18:28

2 respostas

3

Steven - parece que você precisa dedicar um pouco de tempo à sua configuração e também precisa considerar custo x disponibilidade.

As VMs do Azure oferecem suporte à escalabilidade automática por meio do Serviço em Nuvem no qual são implantadas e usam os recursos do Autoscale do Serviço Cloud para impulsionar o provisionamento de novas instâncias (que precisariam ser capazes de se autoconfigurar automaticamente). Uma boa visão geral pode ser encontrada no site de documentação do Azure .

Se você perceber que está retornando erros antes de dimensionar, precisará definir um limite mais baixo para o acionador de escala (limite mínimo de CPU, por exemplo) ou executar uma configuração N + 1, em que N é o número mínimo de VMs para cenários de uso sem carga. Isso é para reduzir o TTSO da sua API.

Você nunca atingirá uma escala instantânea se não tiver uma unidade já em execução disponível.

Por fim, o Gerenciador de tráfego pode ajudar a distribuir a carga somente quando você usa roteamento de menor latência, o que significa a execução de instâncias diferentes da sua API em diferentes regiões geográficas do Azure. Se isso não for necessário, o Gerenciador de Tráfego não é a correção.

    
por 22.01.2015 / 06:18
0

Divulgação completa: eu sou Lars Larsson, arquiteto de software da Elastisys AB.

O que você está descrevendo é exatamente o que a plataforma em nuvem da Elastisys pode ajudar: coleta dados de monitoramento e pode prever aumentar a escala para atender à demanda conforme ela chega, não apenas reagir quando seu serviço já está sofrendo . Os algoritmos são baseados em pesquisas sólidas realizadas no grupo de Sistemas Distribuídos da Universidade de Umeå, na Suécia.

No entanto, ainda não há suporte para a interface com o Azure (o suporte para AWS, OpenStack e CityCloud está disponível em nossa página do GitHub ).

Por favor, entre em contato com a Elastisys se você estiver disposto a servir como um caso de uso para nós, à medida que desenvolvemos o suporte do Azure em versões futuras de nossos produtos. software.

    
por 27.01.2015 / 13:06