Balancear carga de trabalho em um ambiente de nuvem

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, com o objetivo de
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.

01.   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.

02.   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).

03.   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.

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.

04.   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.

01.  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 com o objetivo de 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.

02.   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.

03.   Infraestrutura como serviço:

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.

04.   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% 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

01.   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:

• O consumidor seleciona um item de varejo online
• O varejista coloca o item selecionado na cesta do carrinho de compras
• O consumidor fornece informações de cartão de crédito
• O consumidor envia o pedido
• O varejista valida as informações de cartão de crédito
• O varejista fornece um número de pedido e o tempo de entrega estimado
• O varejista agradece ao consumidor pelo pedido
• O consumidor obtém um e-mail de confirmação do pedido
• 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.

02.   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.

03.  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.

04.  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%) 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

• A autora discute política
  de limite no artigo “Cloud computing versus grid computing: Service
  types, similarities and differences, and things to
  consider.”
• Nos recursos para desenvolvedores de nuvem do
  developerWorks, descubra e compartilhe o
  conhecimento e a experiência dos desenvolvedores de
  aplicativos e serviços que estão desenvolvendo os
  seus projetos de implementação de nuvem.
• Mais recursos do
  developerWorks que correspondem a este artigo podem
  ser encontrados em SOA e serviços da Web no developerWorks e segmentos de mercado no developerWorks.
• As próximas etapas:
  Descubra como acessar o IBM Smart Business Development and Test
  on the IBM Cloud.

Obter produtos e tecnologias

• Consulte as imagens do produto disponíveis no IBM
  Smart Business Development and Test IBM Cloud.

Discutir

• Participe de um grupo de computação em nuvem no
  developerWorks.
• Leia todos os excelentes blogs sobre nuvem no
  developerWorks.

***

artigo publicado originalmente no developerWorks Brasil, por Judith M. Myerson

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.