Desafios da nuvem: heterogeneidade

  • 9 minutos

Os datacenters de nuvem são compostos por várias coleções de componentes, incluindo computadores, redes, SOs (sistemas operacionais), bibliotecas de código e linguagens de programação. Em princípio, se houver variedade e diferença nos componentes do datacenter, a nuvem será chamada de nuvem heterogênea. Caso contrário, será chamada de nuvem homogênea. Na prática, a homogeneidade nem sempre se mantém, por dois motivos principais:

  • Os provedores de nuvem normalmente mantêm várias gerações de recursos de TI, adquiridos em diferentes períodos.
  • Os provedores de nuvem estão cada vez mais aplicando tecnologias de virtualização nas nuvens a fim de consolidar servidores, aprimorar a utilização do sistema e simplificar o gerenciamento. As nuvens públicas são, basicamente, datacenters virtualizados. Mesmo em nuvens privadas, espera-se que ambientes virtualizados se tornem a norma.1

A heterogeneidade é um resultado direto dos ambientes virtualizados e a colocalização de VMs (máquinas virtuais) em computadores físicos semelhantes pode causar heterogeneidade. Considere, por exemplo, dois computadores físicos idênticos, A e B. Mesmo imaginando VMs idênticas que executam os mesmos programas, colocar uma VM no computador A e 10 VMs no computador B sobrecarregará o segundo computador mais do que o primeiro. Ter VMs diferentes e programas variados e exigentes é algo ainda mais provável na nuvem e a situação lá é pior. Uma configuração especialmente interessante é o Azure, que oferece mais de 30 tipos de VM5 para milhões de usuários com programas diferentes. Claramente, essa situação cria ainda mais heterogeneidade. Em resumo, a heterogeneidade já é e continuará sendo a norma na nuvem.

E ela traz vários desafios para a execução de programas distribuídos na nuvem. Os programas distribuídos devem ser projetados de maneira a mascarar a heterogeneidade das linguagens programação, hardwares, redes e SOs subjacentes. A ilusão de homogeneidade permite que as tarefas distribuídas se comuniquem; caso contrário, a passagem de mensagens e todo o conceito dos programas distribuídos falharão. Considere o problema da representação de dados: mensagens trocadas entre tarefas geralmente contêm tipos de dados primitivos, como inteiros. Entretanto, nem todos os computadores armazenam inteiros na mesma ordem. Em particular, alguns computadores usam a chamada ordem big-endian, na qual o byte mais significativo vem primeiro, enquanto outros usam a chamada ordem little-endian, na qual o byte mais significativo vem por último. Os números de ponto flutuante também podem variar de acordo com as arquiteturas de computador. Outro problema é o conjunto de códigos usados para representar os caracteres. Alguns sistemas usam caracteres ASCII, enquanto outros usam o padrão Unicode. De maneira resumida, os programas distribuídos precisam solucionar essa heterogeneidade para existir. A parte que pode ser incorporada aos programas distribuídos para solucionar a heterogeneidade costuma ser chamada de middleware. Felizmente, a maioria dos middlewares é implementada nos protocolos de Internet, que por sua vez mascaram as diferenças nas redes subjacentes. O protocolo SOAP2 é um exemplo de middleware. O SOAP define um esquema para usar a linguagem XML, um formato textual autodescritivo, para representar o conteúdo das mensagens e permitir que tarefas distribuídas em diferentes computadores interajam. Outro exemplo é a Transferência de Estado Representacional ou REST.

De modo geral, o código adequado para um computador pode não ser adequado para outro computador na nuvem, especialmente quando as ISAs (arquiteturas de conjunto de instruções) variam entre os computadores. Ironicamente, a tecnologia de virtualização, que leva à heterogeneidade, pode servir para resolver o problema. Algumas VMs podem ser iniciadas para um cluster de usuários e mapeadas para computadores físicos com ISAs subjacentes diferentes. Depois disso, o hipervisor de virtualização cuidará da emulação de qualquer diferença entre os ISAs das VMs provisionadas e as máquinas físicas subjacentes (se houver). Da perspectiva de um usuário, todas as emulações ocorrem de maneira transparente. Por fim, os usuários sempre podem instalar os próprios SOs e as próprias bibliotecas em VMs do sistema, garantindo, assim, a homogeneidade nos níveis do SO e da biblioteca.

Outro problema grave de heterogeneidade que exige atenção dos desenvolvedores de programas distribuídos é a variação de desempenho3, 4 na nuvem. Variação de desempenho descreve a situação em que executar o mesmo programa distribuído duas vezes no mesmo cluster pode resultar em tempos de execução diferentes. Por exemplo, os tempos de execução podem variar em um fator de cinco para o mesmo aplicativo no mesmo cluster privado.4 A variação de desempenho se deve principalmente à heterogeneidade da nuvem, imposta por ambientes virtualizados, e a picos e vales na demanda por recursos ao longo do tempo. Como consequência, as VMs de nuvem raramente executam o trabalho com a mesma velocidade, impedindo assim que as tarefas avancem em ritmos (aproximadamente) constantes. Claramente, essa situação pode criar um desequilíbrio de carga complicado e degradar o desempenho geral, pois o desequilíbrio de carga faz com que o desempenho do programa dependa de sua tarefa mais lenta. Os programas distribuídos podem tentar aliviar isso detectando tarefas lentas e agendando as tarefas especulativas correspondentes em VMs rápidas, para que elas sejam concluídas antes. Especificamente, duas tarefas com a mesma responsabilidade podem competir sendo executadas em duas VMs diferentes, com aquela que terminar antes sendo confirmada e a outra sendo eliminada. O Hadoop MapReduce segue uma estratégia semelhante para resolver o mesmo problema, chamada de execução especulativa. Entretanto, a distinção entre tarefas/VMs lentas e rápidas é um desafio na nuvem. Pode acontecer que uma VM que executa uma tarefa esteja passando temporariamente por um pico de demanda ou ela pode simplesmente ser defeituosa. Teoricamente, nem todos os nós detectados como lentos são defeituosos e a diferenciação entre nós defeituosos e lentos é difícil.6 Devido a esse problema, o Hadoop MapReduce não tem bom desempenho em ambientes heterogêneos.5, 7 Os motivos para isso e os detalhes sobre a execução especulativa do Hadoop são apresentados na seção sobre o Hadoop MapReduce.


Referências

  1. M. Zaharia, A. Konwinski, A. Joseph, R. Katz e I. Stoica (2008). Melhorando o desempenho do MapReduce em ambientes heterogêneos OSDI
  2. G. Coulouris, J. Dollimore, T. Kindberg e G. Blair (maio de 2011). Sistemas Distribuídos: conceitos e projeto Addison-Wesley
  3. B. Farley, V. Varadarajan, K. Bowers, A. Juels, T. Ristenpart e M. Swift (2012). Mais para seu dinheiro: explorando a heterogeneidade de desempenho em nuvens públicas SOCC
  4. M. S. Rehman e M. F. Sakr (Nov. 2010). Descobertas iniciais para variação de provisionamento na computação em nuvem CloudCom
  5. Tamanhos para Máquinas Virtuais do Linux no Azure
  6. A. S. Tanenbaum e M. V. Steen (12 de outubro de 2006). Distributed Systems: Principles and Paradigms Prentice Hall, Segunda Edição
  7. T. D. Braun, H. J. Siegel, N. Beck, L. L. Blni, M. Maheswaran, A. I. Reuther, J. P. Robertson, M. D. Theys, B. Yao, D Hensgen e R. F. Freund (junho de 2001). Uma comparação de onze heurísticas estáticas para mapear uma classe de tarefas independentes em sistemas de computação distribuídos heterogêneos JPDC