Balancear Carga de Trabalho em um Ambiente de Nuvem

Usar políticas de limite para balancear dinamicamente demandas de carga de trabalho

Muitos negócios e agências governamentais demandam serviços em nuvem para fornecer disponibilidade e segurança operacionais contínuas. Para tornar isso uma realidade, eles precisarão de uma política de limite em gerenciamento de recursos para testes e produção de aplicativo. Neste artigo, a autora explica o que é uma política de limite e como ela pode ajudar a balancear demandas de carga de trabalho dinamicamente em um ambiente em nuvem.

Judith M. Myerson, Systems Engineer and Architect

Judith M. Myerson é arquiteta e engenheira de sistemas. Suas áreas de interesse incluem sistemas corporativos, tecnologias de banco de dados, computação em nuvem, políticas de limite, segmentos de mercado, gerenciamento de rede, segurança, tecnologias RFID, gerenciamento de apresentação e gerenciamento de projeto.



26/Jan/2011

Em um ambiente em nuvem, uma política de limite é um importante atributo desejável — ela é usada para verificar e gerenciar recursos quando demandas de carga de trabalho precisam ser balanceadas dinamicamente após atingir um nível de limite pré-determinado. A política faz com que o sistema crie instâncias dos recursos necessários dependendo de quantas demandas de carga de trabalho excedem o nível de limite.

Antes de entrar em mais detalhes sobre considerações para estabelecer e usar uma política de limite para balancear demandas de carga de trabalho dinamicamente ao criar e liberar instâncias de recursos automaticamente, vamos definir a política de limite neste contexto.

Visão Geral da Política de Limite

Vamos dar uma olhada em alguns atributos chave da política de limite.

Tempos de resposta

O período de resposta entre o horário em que o sistema detecta demandas de carga de trabalho atingindo o nível limite e o horário em que cria as instâncias de recursos adicionais deve ser, conforme possível, o mais próximo de ser instantâneo. Quando demandas de carga de trabalho retornarem a um ponto abaixo do nível limite, o sistema desalocará esses recursos e colocará os mesmos em outro uso.

Considerações sobre Influência

As informações que devem estar em uma política de limite são influenciadas pelos seguintes fatores

  • O tipo de serviço de nuvem que o consumidor aluga.
  • Quanto de controle o consumidor tem sobre os sistemas operacionais, hardware e software.
  • O tipo de segmento de mercado no qual o consumidor está (por exemplo, varejo, energia e utilidades, mercados financeiros, assistência médica e petroquímico).

O provedor de serviços e a política

O provedor de serviços de nuvem pode ser interno em um datacenter controlado por uma organização ou estar hospedado externamente por um membro do segmento de mercado de telecomunicação (como a IBM®). O provedor deve assegurar integração com sistemas de funções administrativas de apoio, de forma que pedidos, fornecimento, medição, classificação e cobrança, faturamento e outras funções suportem atividades e transações de consumo.

Como a política de limite pode ser aplicada

Um exemplo disso é o caso de um consumidor do segmento de mercado de varejo de um serviço de nuvem que tinha um aplicativo de grande escala em um datacenter que realizava validação de cartão de crédito na nuvem enquanto as demandas de carga de trabalho estavam abaixo do nível limite. Quando chegou a época crítica de compras de Natal, o sistema detectou demandas de carga de trabalho mais altas, excedendo o nível limite. Em resposta, o sistema criou rapidamente instâncias de recursos adicionais para balancear demandas de carga de trabalho dinamicamente.

À medida que o varejista saía da época crítica de compras, as demandas de carga de trabalho caíram abaixo do nível limite, de forma que instâncias de recursos na nuvem que foram criadas foram liberadas. Como a organização tem alguns controles sobre o hardware, ela é capaz de negociar com o provedor de serviços de nuvem com base nos termos configurados na política de limite. (Sempre é bom negociar os parâmetros da política antes da época crítica de compras.)

O restante deste artigo fornece um histórico sobre os tipos de serviços de nuvem e mostra como uma política de limite para um tipo de nuvem pode ser diferente da política para outro tipo de nuvem. Além disso, discute as políticas de limite em gerenciamento de recurso para testes, produção e planejamento de capacidade de aplicativos e observa algumas das questões mais importantes a serem consideradas, como impactos de uma política de limite em um acordo de nível de serviço (SLA).


Tipos de Serviços de Nuvem

Primeiramente, considere qual destes três tipos de serviços de nuvem atendem suas necessidades:

  • Software como Serviço (SaaS)
  • Plataforma como Serviço (PaaS)
  • Infraestrutura como Serviço (IaaS)

Também vamos discutir como o tamanho de sua operação pode influenciar se sua melhor opção de um tipo de serviço de nuvem é público ou privado.

Software como Serviço

Vamos supor que, como um consumidor do segmento de mercado de varejo, você obtenha uma licença de um provedor de SaaS para sua empresa para executar um aplicativo para uso na Web como um serviço on demand. Você escolhe uma assinatura ou método de pagamento de acordo com o uso, pois você não tem hardware ou software para comprar, instalar e manter, nem precisa atualizar o aplicativo.

O único controle que você tem é, ao usar o aplicativo do provedor a partir de um desktop ou de um dispositivo remoto, processar tarefas de negócios como cobrança e faturamento computadorizados e gerenciamento de recursos humanos.

Apesar de você não controlar aplicativos implementados, sistemas operacionais, armazenamento ou redes, é necessário conhecer uma política de limite do provedor sobre gerenciamento de recurso caso haja um pico, planejado ou inesperado, na demanda de carga de trabalho:

  • Você deve saber como o provedor configura níveis de limite para assegurar a disponibilidade operacional contínua do SaaS.
  • Deve conhecer quais são os termos do SLA e a política de backup do provedor.
  • Se o serviço falhar porque o provedor não pôde tratar de um pico em demandas dinamicamente, você deve saber se é possível obter créditos, reembolsos, meses gratuitos ou rescindir o SaaS conforme determinado em um SLA.

Plataforma como Serviço

Com PaaS, você deseja desenvolver aplicativos de varejo da criação até a implementação para testes de aplicativos (ou produção como serviço).

Diferentemente do SaaS, é possível controlar todos os aplicativos localizados em um ciclo de vida de negócios integral para a plataforma (por exemplo, planilhas, processadores de texto, backups, cobrança, processamento de folha de pagamento e faturamento).

O provedor controla o sistema operacional, o hardware ou a infraestrutura de rede em que os aplicativos estão em execução. O provedor pode desenvolver, implementar, executar e gerenciar atualizações e correções em todas as funcionalidades, digamos, de um aplicativo de gerenciamento de varejo.

É claro que você deseja uma política de limite do provedor de PaaS:

  • Você deve saber como o provedor configura níveis de limite para assegurar que PaaS continuará disponível.
  • Se o serviço falhar porque o provedor não pôde tratar de um pico em demandas dinamicamente, você deve obter créditos, reembolsos, meses gratuitos ou rescindir o serviço.

Infrastructure as a Service

Com IaaS, é possível controlar os sistemas operacionais, equipamento de rede e aplicativos implementados no nível da máquina virtual:

  • É possível escalar o número de servidores virtuais ou blocos de área de armazenamento para cima ou para baixo.
  • É possível pagar por uso pela infraestrutura desses recursos de computação tradicionais no ambiente em nuvem.

Será necessário conhecer uma política de limite para a infraestrutura do provedor de IaaS:

  • Você deve saber como o provedor configura níveis de limite para assegurar que IaaS será mantida quando houver um pico nas demandas de carga de trabalho.
  • Deve ser capaz de negociar com o provedor de IaaS sobre os termos da política de limite e o SLA para sua empresa.
  • Se o serviço falhar porque a infraestrutura de recursos de computação não pôde tratar de um pico em demandas dinamicamente, resultando em tempos de resposta lentos, você deve obter créditos, reembolsos, meses gratuitos ou rescindir o serviço conforme determinado em um SLA.

Escala de Operações: O Público versus o Privado

Como um exemplo, minha empresa gera receitas maiores que US$ 1 bilhão. Achamos que as nuvens privadas podem ser mais econômicas do que as nuvens públicas. Uma nuvem interna privada tem muitas das mesmas características de negócios que uma nuvem pública, mas com níveis muitos mais altos de governança, segurança, disponibilidade e capacidade de recuperação do que pequenas empresas com receitas, digamos, inferiores a US$ 1 milhão teriam.

Com uma nuvem pública, dados podem ser armazenados em locais desconhecidos e podem não ser facilmente recuperáveis. Isso em contraste com uma nuvem privada que permite que um consumidor recupere dados de locais conhecidos em uma jurisdição específica (como os EUA). Locais desconhecidos não são adequados para armazenar dados de teste de conformidade, privacidade e sigilosos. Eles podem estar em áreas geográficas em que regulamentos de privacidade e conformidade de um país são diferentes desse tipo de lei em outro país. As leis variam de um país para outro com relação a controles de exportação de dados.

Ao criar uma política de limite, minha empresa requer os níveis mais altos de balanço dinâmico de demandas de carga de trabalho em um ambiente em nuvem. O sistema deve ser capaz de criar rapidamente instâncias adicionais de recursos quando as demandas de carga de trabalho excederem o nível limite.

Devido ao grande tamanho operacional de minha empresa, cargas de trabalho orientadas por transação são maiores do que seriam para pequenas empresas. A faixa e o número de tipos de transações são maiores para minha empresa do que para pequenas empresas. Como os tipos de transações são identificados por código numérico ou de caracteres de dois ou três bits, uma empresa grande ou uma pequena empresa precisa associar uma categoria de transação de negócios a cada tipo. Uma categoria de transação de negócios apropriada para uma empresa grande (como leasing financeiro) pode não ser apropriada para uma pequena empresa.


Tipos de Segmentos de Mercado

Para cada tipo de serviço de nuvem, a política de limite varia de um segmento de mercado para o outro. A política pode ser influenciada por tipo de organização, tamanho de organização, condições de mercado, demandas de carga de trabalho sazonais, economia, mandatos de mudanças, tecnologias emergentes e frequência de condições climáticas adversas.

O número de datacenters também depende do segmento de mercado. Por exemplo, o setor governamental é um usuário pesado de datacenters e tem procurado maneiras para economizar custos, alugando serviços on demand para assegurar disponibilidade e segurança de operação no ambiente em nuvem.

Já mencionei seis segmentos de mercado como exemplos — varejo, energia e utilidades, mercados financeiros, assistência médica, telecomunicações e petroquímico. Além desses, há outros.

  • Aeroespacial e defesa
  • Automotivo
  • Construção
  • Produtos de consumo
  • Educação
  • Eletroeletrônico
  • Floresta e papel
  • Governo
  • Seguro
  • Ciências biológicas
  • Mídia e entretenimento
  • Metais e mineração
  • Turismo e transporte
  • Fabricação e montagem
  • Produtos industriais
  • Ciências biológicas
  • Construção naval
  • Distribuição e serviços de atacado

Vamos comparar e contrastar os segmentos de mercado de varejo e petroquímico com base em considerações para política de limite. Quando o sistema de cada segmento de mercado detecta demandas de carga de trabalho que excedem o nível limite, o sistema cria rapidamente instâncias adicionais de recursos para balancear demandas de carga de trabalho dinamicamente. À medida que a demanda da carga de trabalho cai abaixo do nível limite, as instâncias de recursos que foram alocadas são liberadas.

O segmento de mercado de varejo é formado por pequenas e grandes empresas engajadas na venda de produtos acabados para consumidores usuários finais . O segmento de mercado petroquímico de instalações industriais e pequenas e grandes empresas que investem em petróleo, gás e produtos químicos e vendem esses produtos a consumidores industriais .

Picos em demandas de carga de trabalho para o segmento de mercado de varejo são geralmente previsíveis (como a época crítica de compras de Natal). Os picos para o segmento de mercado petroquímico são geralmente baseados em diferentes fatores que não são tão fáceis de prever, no entanto, eles geralmente seguem: a economia, a exigência para otimização da cadeia de fornecimento, investimentos em perfuração de petróleo profundo e condições climáticas adversas imprevisíveis (como inverno quente em um ano, nevascas no próximo).

As diferenças nos tipos de transações (industriais vs. varejistas) e a opção de nuvens públicas, privadas ou híbridas afetam a criação da política de limite. Os tipos de transações são usados para agrupar itens de receitas e despesas de acordo com grupos de negócios ou de produtos.


Boa política de Limite Interna

Bom gerenciamento de recurso é importante para balancear o consumo de recursos no ambiente em nuvem. Uma política de limite assegura que o consumo de recursos seja balanceado dinamicamente para teste e produção de aplicativos. O teste de aplicativos pode ter requisitos de limite diferentes do que aqueles para produção. Use planejamento de capacidade antecipado para preparar seu sistema para alocar instâncias de recursos adicionais quando as demandas de carga de trabalho atingirem o nível limite.

Apesar de profissionais de TI serem usados para pensarem em termos abstratos, um aspecto chave para abordar a criação da política de limite é lembrar que um componente crítico de demandas de carga de trabalho é físico. Você depende de taxas de confiabilidade de componentes físicos, mesmo com os bits wireless.

A política de limite deve configurar o que deve ser um nível limite, como o nível limite de 75 ou 85 por cento da capacidade de um ou mais discos. Deve incluir mecanismos de criação de log e monitoramento de consumo de recursos.

Além da capacidade, quando o nível limite é atingido, o número de instâncias de recursos alocadas e o tempo de resposta na alocação das instâncias devem estar nos logs. Além disso, os logs devem incluir:

  • Qualidade de stateful do aplicativo
  • Pontos de retomada
  • Mecanismo de failover
  • Segurança do serviço de nuvem

Qualidade de Stateful

Qualidade de Stateful refere-se a se um estado do aplicativo responde adequadamente a estágios subsequentes das funções do aplicativo no ambiente em nuvem. Por exemplo, um estado deve ir para o próximo estado de função na sequência neste cenário muito simplificado:

  1. O consumidor seleciona um item de varejo online
  2. O varejista coloca o item selecionado na cesta do carrinho de compras
  3. O consumidor fornece informações de cartão de crédito
  4. O consumidor envia o pedido
  5. O varejista valida as informações de cartão de crédito
  6. O varejista fornece um número de pedido e o tempo de entrega estimado
  7. O varejista agradece ao consumidor pelo pedido
  8. O consumidor obtém um e-mail de confirmação do pedido
  9. O consumidor obtém um e-mail de que o pedido está sendo enviado

Se o estado de função para a etapa 2 não tiver ido para a etapa 3, qual seria a causa do problema?

  • As novas compilações do aplicativo quebraram a lógica?
  • Quando o sistema detectou o nível limite excedendo as demandas de carga de trabalho, o nível limite estava configurado em um patamar muito alto, de forma que os recursos restantes eram insuficientes para continuar a operação?
  • Se o nível limite estava apropriado, havia instâncias adicionais de recursos suficientes na nuvem necessárias para assegurar que o estado de uma etapa fosse para a próxima?

O log deve mostrar em qual estado o aplicativo estava e se a conclusão do estado realizada com êxito.

Pontos de Retomada

O sistema deve criar um ponto de retomada (das variedades planejada, manual e de instalação) em diferentes pontos de tempo antes que ocorra um problema no sistema.

Capturas instantâneas dos discos que contêm pontos de retomada devem ter backup no disco no sistema local e em outro disco em um local remoto diferente. O log deve indicar o horário em que os pontos de retomada foram criados e qual ponto de retomada foi usado para restaurar o sistema.

Mecanismo de Failover

O sistema também deve poder iniciar mecanismos de failover para continuar a disponibilidade da operação.

Os mecanismos de failover devem incluir conexões alternativas com fio ou wireless caso, por exemplo, o provedor de telecomunicação corte acidentalmente a linha de fibra ou encerre a rede wireless conectada à instalação física do consumidor. O log deve indicar o tipo e local do dispositivo usado no failover.

Exemplos de mecanismos de failover incluem:

  • Compartilhamento de carga redundante. Dois ou mais sistemas carregados com no máximo 50 por cento da carga total. Quando um dispositivo falha, outros dispositivos assumem a carga com pouca ou nenhuma interrupção.
  • Recurso de instância redundante. Duas ou mais instâncias de recursos carregadas com no máximo 50 por cento da carga total. Quando uma instância de recurso falha, outras instâncias de recursos assumem a carga.
  • Nova tentativa de conexão alternativa. Se a interrupção de rede durar mais de dois minutos, tente reconectar com outro servidor por meio de conexões alternativas.

Segurança do Serviço de Nuvem

A segurança do serviço de nuvem pode ser ameaçada por credenciais fracas, exposição do protocolo e falhas na implementação em gerenciamento remoto. A reutilização de endereços IP pode levar a um ataque de Denial of Service (DoS) não intencional.

SaaS pode ser afetada intencionalmente com um vírus que resulta em um DoS. Hackers têm usado PaaS, assim como plataformas IaaS, como centros de Command and Control (CnC) para direcionar operações de uma botnet (rede robótica de computadores) para uso em distributed denial of service (DDoS) e instalação de software malware na nuvem.

O log deve mostrar o tipo de problema de segurança que um tipo de serviço de nuvem teve e quando e como o problema foi corrigido.


Problemas a Considerar

Apesar de seu provedor de serviços geralmente ser responsável pelos sistemas de computação subjacentes da nuvem, você ainda tem responsabilidade jurídica para assegurar que os sistemas dele atendam seus requisitos reguladores, que as práticas dele sejam razoavelmente seguras, que os administradores dele não possam acessar seus dados sem autorização e que um SLA esteja em vigor.

Certifique-se de que você entenda como o SLA funciona, como a política de limite afetaria o SLA e quais são os procedimentos e expectativas caso seu provedor de serviços o decepcione.

Componentes importantes do SLA são a disponibilidade de tempo de atividade, os padrões de desempenho, os tempos de resposta de emergência, as soluções para violações e a segurança.

Descubra como os níveis limite podem diferir daqueles especificados como os padrões de desempenho para disponibilidade de tempo de atividade no SLA. Eles não devem ser configurados nos padrões de disponibilidade nem acima deles. Escolha a disponibilidade de tempo de atividade (97 ou 99,9 por cento) e, em seguida, os níveis limites que melhor atendam as necessidades e orçamento de seus negócios.

No caso de uma violação de SLA, soluções devem ser fornecidas. Por exemplo, seu provedor de serviços deve emitir um crédito gratuito ou um reembolso se não atender um SLA (respostas lentas na criação de instâncias adicionais de recursos nas nuvens). Se o provedor não atender o SLA diversas vezes em três meses, deve ser permitido rescindir seu serviço. Assegure que a cláusula de rescisão esteja incluída no SLA e leia-a com muita atenção.

O SLA diz quem e onde a fonte de autoridade seria se você e o provedor discordarem sobre a duração de uma indisponibilidade? Você deve saber quanto tempo deve esperar após um evento para entrar com uma reclamação. Revise se sua apólice de seguro aborda itens que não são cobertas em um SLA, incluindo perda de receita, dano à reputação ou violação de dados.


Conclusão

Configurar uma política de limite para balancear dinamicamente demandas de carga de trabalho requer planejamento antecipado para resolver os problemas de criação de instâncias adicionais de recursos no ambiente em nuvem. Desenvolvedores devem se comunicar com o consumidor e o provedor de serviços de nuvem sobre as questões de economias de escalas (nuvens públicas versus privadas) e desenvolvimento de política de limite para teste e produção de aplicativos. Use planejamento de capacidade antecipado para preparar seu sistema para alocar instâncias de recursos adicionais quando as demandas de carga de trabalho atingirem o nível limite.

Recursos

Aprender

Obter produtos e tecnologias

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Cloud computing, Segmentos de mercado
ArticleID=620476
ArticleTitle=Balancear Carga de Trabalho em um Ambiente de Nuvem
publish-date=01262011