Mecanismos para consolidação de servidores

Mecanismos para consolidação de servidores

Max Rosan dos Santos Júnior<[email protected]>

Orientador: Prof. Dr. Daniel Macêdo BatistaInstituto de Matemática e Estatística

Universidade de São Paulo

31 de março de 2014

IntroduçãoMotivação para uso da virtualização

AlgoritmoConclusão

Referências

Sumário

1 Introdução

Problema

Consolidação de servidores

Objetivos

2 Motivação para uso da virtualização

Motivação

Ferramentas

Resultados

3 Algoritmo

Introdução

Heurística

Modelo

Programação Linear

4 Conclusão

Conclusão

Max Rosan dos Santos Júnior <[email protected]> Mecanismos para consolidação de servidores


AlgoritmoConclusão

Referências

ProblemaConsolidação de servidoresObjetivos

Problema

Houve um crescimento no número e na complexidade deserviços na nuvem.Jogos (OnLive [2013]), armazenamento de arquivos(Dropbox), edição e formatação de texto (Google [2014]), etc.Passaram a exigir uma quantidade maior de recursos dos CPDs(Centro de Processamento de Dados).Os CPDs, para cumprir a demanda, cresceram bastante emtermos de infraestrutura, com um número cada vez maior deservidores (ou máquinas físicas).



AlgoritmoConclusão

Referências


Problema

Inevitavelmente, o crescimento dos CPDs também aumentoubastante o custo energético para mantê-los.Grande parte do custo energético dos CPDs é atribuída aosservidores neles instalados.Notou-se então que havia um subuso nos servidores. Em 2008,Vogels [2008] já relatava que o uso dos servidores das grandesempresas de TI ficavam em torno de 15% a 20% das suascapacidades.Google, em 2013, revelou por meio um monitoramento de 3meses de alguns dos servidores um uso de 10 a 50% de suascapacidades.O custo energético de um servidor ocioso ainda é alto.



AlgoritmoConclusão

Referências


Problema

O baixo uso dos servidores pode ser causado por diversosfatores:

Falta de balanceamento adequado de carga computacional;Servidores dedicados a determinados serviços;Imprevisibilidade do uso dos servidores;etc.

Esses fatores causam o espalhamento inadequado deaplicações/serviços pelos servidores.



AlgoritmoConclusão

Referências


Consolidação de servidores

Uma das formas de tentar fazer o uso mais eficiente é realizara consolidação:

Por meio da virtualização;Ou por meio das aplicações.

A segunda opção pode não assegurar o isolamento.Problema com os serviços/aplicações dependentes deplataforma.



AlgoritmoConclusão

Referências


Figura: Servidores dedicados.



AlgoritmoConclusão

Referências


Figura: Migra os serviços para máquinas virtuais.



AlgoritmoConclusão

Referências


Figura: Consolidação por meio da virtualização.



AlgoritmoConclusão

Referências


O primeiro passo para a consolidação é realizar a migração dosserviços para máquinas virtuais.O segundo o passo é fazer uma alocação de servidores pararodar as máquinas virtuais.Surge então o problema de como alocar os servidores para asmáquinas virtuais.Os contratos devem ser obedecidos pelos servidores.



AlgoritmoConclusão

Referências


A alocação de servidores pode ser estática ou dinâmica.A alocação dinâmica não é custosa hoje em dia graça ao livemigration (Clark et al. [2005]).O problema da alocação foi modelado em vários trabalhoscomo um problema de bin packing.É possível ter outra abordagem ?



AlgoritmoConclusão

Referências


Principal:

Propor uma heurística alternativa para realizar a consolidaçãode servidores.

Os objetivos secundários são:

Desenvolver um modelo para estimar o consumo de energia emum CPD;Verificar como é afetado o desempenho de serviços executadosem MVs;Verificar o consumo de energia de um servidor com e sem MVs.



AlgoritmoConclusão

Referências

MotivaçãoFerramentasResultados

É interessante usar a virtualização?O uso da virtualização pode introduzir um overhead no usodos recursos das máquinas físicas.Dependendo do overhead, pode haver um consumo maior deenergia ou mesmo quebra nos contratos dos serviços.A fim de motivar o uso da virtualização para a consolidação emostrar que esse overhead é pequeno se comparado àeconomia de energia que se tem, foram realizados diversosexperimentos de estresse de uma máquina física, com e semmáquinas virtuais.



AlgoritmoConclusão

Referências


Máquina física:CPU: Intel i7-3610QM (4 núcleos reais mais 4 núcleosvirtuais);Frequência de operação: 2,3 GHz até 3,3 GHz;Memória RAM: 8 GB;Disco rígido: 750 GB - 5.400rpm;Sistema operacional: Linux Fedora 18 x64.



AlgoritmoConclusão

Referências


Máquina virtual:vCPU: 1;Memória: 512 MB;Disco Rígido: 1 GB;Arquitetura emulada: i386;Sistema operacional: Ubuntu 12.04.2 LTS.

Até 12 máquinas virtuais foram utilizadas.



AlgoritmoConclusão

Referências


Ferramentas utilizadas para mensurar o desempenho:sysbench: Forçar o uso da CPU e da memória;cpulimit: Limitar o uso de CPU a um determinado percentual;qemu c/ kvm: Emulador com aceleração para tradução dasintruções;libvirt: Hypervisor.



AlgoritmoConclusão

Referências


Ferramentas utilizadas para mensurar o consumo:Wattímetro digital simples;Câmera digital para filmar o visor do wattímetro;FFMpeg: Amostrar a filmagem;SSOcr: Para extrair os valores de 7 segmentos dos frames.



AlgoritmoConclusão

Referências




AlgoritmoConclusão

Referências


Figura: Utilização da CPU em função da quantidade de MVs

Comando: sysbench –test=cpu –cpu-max-prime=50000 runTempo médio pouco varia até usar os quatro núcleos.



AlgoritmoConclusão

Referências


Figura: Vazão no acesso à memória RAM em função da quantidade deMVs

Comando: sysbench –test=memory –memory-block-size=1M–memory-total-size=10G runCom 12 MVs, a vazão foi 27% menor. Com 4 MVs, foi 2%.



AlgoritmoConclusão

Referências


Figura: Gráfico comparativo do consumo no processamento em umservidor sem MV e um servidor com MV.

A diferença nas medições ficou em torno de 4 a 20%.



AlgoritmoConclusão

Referências


Figura: Consumo de energia de 2 máquinas físicas versus consumo deenergia do servidor com 2 MVs em função do tempo (estimativa)

É possível notar que há diferença considerável entre os doisconsumos.



AlgoritmoConclusão

Referências


Figura: Consumo de energia do servidor com várias MVs (até 12) emfunção do tempo.

Boot é um processo custoso. O consumo aumenta de maneirasignificativa até 4 MVs.



AlgoritmoConclusão

Referências


Figura: Consumo de energia real do servidor versus regressão linear emfunção da porcentagem de uso de CPUs



AlgoritmoConclusão

Referências


Figura: Consumo de energia em função do uso da memória

As mudanças nos padrões de acesso influenciam mais( Hicks et al. [1997]).



AlgoritmoConclusão

Referências


A virtualização causa um pequeno overhead no uso dosrecursos e, consequetemente, um pequeno acréscimento noconsumo de energia, se comparado ao uso da máquina físicasem virtualização.Por o overhead ser pequeno, pode ser vantajoso o uso davirtualização.Em cenários de ociosidade, a virtualização permite umaeconomia maior de energia.É preciso mapear as máquinas virtuais para os servidores deforma a não quebrar os contratos.



AlgoritmoConclusão

Referências

IntroduçãoHeurísticaModeloProgramação Linear

Dos resultados anteriores, é possível ver que a virtualização évantajosa se houver uma alocação adequada dos servidores.Se pensar no problema envolvendo todos os servidores e asmáquinas virtuais, o problema da alocação é de minimização.Se considerar cada servidor de forma individual, e que a formade fazer minimizar o número de servidores é maximizar onúmero de máquinas virtuais nos servidores com mais recursos,há então um problema de maximização para cada servidor.Foi considerando essa hipótese que o problema da alocação foiaqui modelado como um Problema da Mochila.



AlgoritmoConclusão

Referências


Surgiu então outra questão: tentar consolidar maximizando ouso dos recursos de servidores com maior poder computacionalde fato economiza energia?Como comparar a heurística proposta aqui com outraspropostas em outros trabalhos?



AlgoritmoConclusão

Referências


Foram desenvolvidos então:Trace de um workload do Google para representar um cenáriode um CPD próximo do real.Simulador simples de evento discreto baseado nesse trace.Um modelo, com base nos resultados dos experimentos, paracalcular o consumo de energia dos servidores alocados pelosalgoritmos.



AlgoritmoConclusão

Referências


Problema da alocação de servidores como Problema daMochila:

Máquina virtual como item.Servidor como mochila.Ganho associado a cada máquina virtual.

Recursos considerados: CPU e memória (valoresnormalizados).



AlgoritmoConclusão

Referências


Toyoda [1975] propôs uma algoritmo para resolver grandesinstâncias do Problema da Mochila com mais de umadimensão.Não usa enumeração. Menor complexidade temporal parainstâncias grandes.Para lidar com mais de uma dimensão, Toyoda define umapenalidade associada a cada objeto.Exemplo:

Mochila tem como recursos: (1.0, 1.0);Já foi utilizado: Pu = (0.6, 0.3);Dois itens com o mesmo ganho: P1 = (0.1, 0.4) eP2 = (0.4, 0.1).Qual colocar?



AlgoritmoConclusão

Referências


Solução:

P1 vai usar mais do recurso dois, vai balancear mais o uso damochila;P1 deve ter prioridade sobre P2;Pode ser calculado usando produto interno: P1 . Pu = 0.18 eP2 . Pu = 0.27.Pu é o vetor de penalidade.



AlgoritmoConclusão

Referências


A prioridade de um item i é dada por Gi =KiUi.

Ui = Pi .Pu|Pu | .

Ki é o ganho associado ao item i .Pu muda a cada iteração sobre os itens não selecionados aindapara mochila.



AlgoritmoConclusão

Referências


Antes de usar a heurística, é necessário ordenar as máquinasvirtuais e os servidores em ordem decrescente.Servidores com mais recursos computacionais devem ter maiorprioridade em receber as máquinas virtuais.Máquinas virtuais que usam mais recursos devem ter maiorprioridade.A prioridade de um servidor e de uma MV é dada por:(cpu)2 + (mem)2.O ganho de uma MV é dado por max(cpu,mem).Essas funções apresentaram os melhores resultados para otrace do Google.



AlgoritmoConclusão

Referências


Foi necessário fazer processamento com threads.Apesar da heurística do Toyoda ser para instâncias grandes, háum volume grande de dados no trace do Google.Após a ordenação, as listas de servidores e MVs são divididas edistribuidas entre as threads.



AlgoritmoConclusão

Referências


Os valores das tarefas no trace do Google foram amostrados acada 300 segundos.Com base nisso, os algoritmos para fazer a realocação dosservidores são chamados a cada 300 segundos simulados.Intervalo de 300 segundos simulados = 1 rodada.Os comparativos foram construídos usando "rodada" comounidade de tempo.First Fit Decreasing (FFD) vs. Toyoda-based Algorithm ForServer Consolidation (TASC)



AlgoritmoConclusão

Referências


Figura: Total de tarefas em função do tempo

119131 MVs por rodada.3756 MVs novas chegam em cada rodada.



AlgoritmoConclusão

Referências


Figura: Número de servidores em função do tempo



AlgoritmoConclusão

Referências


Figura: Servidores utilizados ao longo do tempo



AlgoritmoConclusão

Referências


Figura: Número de migrações das heurísticas

Em média, o TASC provocou 5053 migrações a menos que oFFD.



AlgoritmoConclusão

Referências


O número de servidores utilizados pode não ser parâmetrosuficiente para afirmar que há de fato um menor consumo deenergia.Mesmo o número de migrações pode pouco falar sobre oconsumo de energia.Foi desenvolvido um modelo para calcular o consumo deenergia com base nos experimentos com consumo.



AlgoritmoConclusão

Referências


Seja x o uso da CPU.

g(x) =

{1, 5+ 3, 9x , se x ≤ 0, 25,2, 05+ 1, 8x , caso contrário.

(1)

Won(x) =

{1, 5 se x ≤ 0, 25,2, 05 caso contrário.

(2)

Wcpu(x) =

{3, 9 se x ≤ 0, 25,1, 8 caso contrário.

(3)

E (x) = Won(x) + xWcpu(x)x (4)



AlgoritmoConclusão

Referências


Figura: Consumo de energia das heurísticas (Bezier)

Em média, o TASC faz o consumo por rodada ser 6125 Wh amenos que o FFD.



AlgoritmoConclusão

Referências


O TASC se baseia na hipótese que maximizando o uso dosservidores com mais recursos, há a consolidação e umaredução de energia.Maximizando o uso, de fato há economia?Para verificar quão distante o TASC ficaria de uma abordagemexata baseada no consumo, o modelo para cálculo de energiafoi modificado para ser um problema de Programação Linear.



AlgoritmoConclusão

Referências


min∑

j∈Macs

zjWon +

∑i∈Tasks

xij

Cti

Csj

Wcpu + yijWmig

(5)

∀j ∈ Macs ,

∑i∈Tasks

xij Cti

− zj Csj ≤ 0 (6)

∀j ∈ Macs ,

∑i∈Tasks

xij Mti

− zjMsj ≤ 0 (7)

∀i ∈ Tasks ,∑

j∈Macs

xij = 1 (8)

∀i ∈ Tasks ∀j ∈ Macs , 0 ≤ xij ≤ 1 (9)

∀j ∈ Macs , 0 ≤ zj ≤ 1 (10)

∀i ∈ Tasks ∀j ∈ Macs , xij ∈ Z (11)

∀j ∈ Macs , zj ∈ Z (12)



AlgoritmoConclusão

Referências


O CPLEX foi utilizado para resolver a Programação Linear.Um problema de Programação Linear foi construído a cadarodada no simulador, com base nos resultados da rodadaanterior.Não foi utilizado o trace do Google. Foi construído um tracecom valores aleatórios para as máquinas virtuais.Foi utilizado um valor constante para os servidores.



AlgoritmoConclusão

Referências


Número de MVs Número de servidores TASC Exato10 10 313,32 Wh 261,12 Wh20 20 611,65 Wh 516,36 Wh30 30 871,01 Wh 724,71 Wh40 40 1204,93 Wh 998,30 Wh50 50 1519,93 Wh 1258,10 Wh

Tabela: Total de energia consumida de acordo com a alocação de cadaalgoritmo

Em média o TASC retornou alocações que consumiram 20%mais energia do que as alocações retornadas pelo algoritmoexato.



AlgoritmoConclusão

Referências


Número de MVs Número de servidores TASC Exato10 10 73 2120 20 145 4930 30 208 7440 40 304 10750 50 387 136

Tabela: Número de migrações de acordo com a alocação de cadaalgoritmo



AlgoritmoConclusão

Referências


Número de MVs Número de servidores TASC Exato10 10 0,00075s 7,82s20 20 0,00208s 8,1s30 30 0,00348s 9,14s40 40 0,00558s 18,23s50 50 0,00795s 16,67s

Tabela: Tempo médio para execução de cada algoritmo



AlgoritmoConclusão

Referências

Conclusão

Para o trace do Google, o TASC apresentou melhoresalocações do que o FFD implementado.

Menor número de servidores utilizados;Menor número de migrações;Menor consumo de energia.

TASC pode ser utilizado com grandes instâncias.Programação Linear baseado no modelo retorna melhoresresultados para instâncias pequenas.



AlgoritmoConclusão

Referências

Referências

Clark et al.(2005) C. Clark et al. Live migration of virtual machines. Em Proceedings of the 2nd conference on

Symposium on Networked Systems Design & Implementation-Volume 2, páginas 273–286. USENIX

Association.

Dropbox() Dropbox. Dropbox - Sobre o Dropbox. https://www.dropbox.com/about. Acessado em 12/3/2014.

Google(2014) Google. Google Docs, Planilhas e Apresentacoes do Google - Ajuda do Drive, 2014.

https://support.google.com/drive/answer/49008?hl=pt-BR. Acessado em 12/3/2014.

Hicks et al.(1997) P. Hicks, M. Walnock e R. M. Owens. Analysis of power consumption in memory hierarchies.

Em Proceedings of the 1997 International Symposium On Low Power Electronics and Design, páginas

239–242. ACM.

OnLive(2013) OnLive. OnLive Background, 2013. https://www.onlive.com/about. Acessado em 12/3/2014.

Toyoda(1975) Y. Toyoda. A simplified algorithm for obtaining approximate solutions to zero-one programming

problems. Management Science, 21(12):1417–1427.

Vogels(2008) W. Vogels. Beyond server consolidation. Queue, 6(1):20–26.


Technology

Mecanismos para consolidação de servidores