Introdução aos Clusters Verdes de Servidores - ic.uff.brjulius/stre/CapClustersVerdes.pdf · As...

Introdução aos Clusters Verdes de Servidores

Daniel Mossé, Julius C. B. Leite, Antonio Gil Borges de Barros

Abstract

Server clusters have been progressively more used in businesses and industry, as for example in

search and electronic commerce systems. However, studies demonstrate that the associated energy

expenditure of running them has increased dramatically world-wide. This not only implies in larger

financial costs, but also may cause significant environmental problems. Energy expenses come not

only from running the servers and other IT equipment. A significant part of the electricity bill is due to

cooling.

This Chapter will present an introduction to the techniques for the reduction of energy consump-

tion in computer clusters (i.e., techniques to help design the so-called ”power-aware clusters“). The

techniques presented here encompass automatic reconfiguration of the clusters (i.e., which servers

will be on and which will be off), configuration of CPU frequencies, virtualization, and thermal modeling

of the servers, racks, and rooms of servers/racks.

Resumo

Clusters de servidores têm sido cada vez mais empregados no dia a dia da economia. Exemplos de

sua utilização são os sistemas de busca e de comércio eletrônico. Contudo, estudos demonstram que

o gasto energético associado ao uso desses sistemas tem aumentado dramaticamente em escala

mundial. Isso implica não somente em maiores dispêndios financeiros, mas também em significativos

problemas ambientais. O gasto de energia não provem somente do consumo dos servidores e de

outros equipamentos de TIC (Tecnologia da Informação e Comunicação). Uma parte significativa do

consumo é associada aos gastos com resfriamento desses equipamentos.

Este Capítulo discutirá uma introdução às técnicas de redução do consumo energético em clus-

ters de computadores (ou seja, aquelas empregadas na construção dos chamados ”power-aware

clusters“). Essas técnicas abrangem reconfiguração automática dos clusters (quais servidores serão

ligados e quais serão desligados), configuração das frequências dos processadores (como controlar a

velocidade de execução das tarefas), virtualização, e modelagem térmica dos servidores, bastidores

(racks) e salas de servidores.

1.1. Introdução e motivaçãoEste Capítulo trata dos conceitos associados à chamada Computação Verde

aplicados aos clusters de servidores. Sinteticamente, essa área da Ciência da

1

D. Mossé, J.C.B. Leite, A.G.B. de Barros

Computação trata de economia de energia nos equipamentos de TIC (Tecno-logia da Informação e Comunicação) e, como consequência, da diminuiçãodo impacto ambiental decorrente dos seus métodos de geração e utilização.Grandes clusters são cada vez mais comuns em nossa sociedade, como, porexemplo, os empregados em sistemas de busca e de comércio eletrônico e osempregados na implementação de computação em nuvem (cloud computing),bem como os pequenos clusters, existentes, por exemplo, no processamentode dados em universidades e pequenas empresas.

Com os avanços tecnológicos e o aumento da dependência de sistemasde computação de alto desempenho, a cada ano aumenta a necessidade dautilização de clusters para atender a demanda do mercado. Consequente-mente, aumenta também o consumo de energia necessária para o seu funci-onamento. Um levantamento feito pela U.S. Environmental Protection Agencyestimou a demanda de pico desses sistemas, no ano de 2007, em 7 gigawattse que, se mantida a tendência, esse número saltará para 12 gigawatts em2011 [EPA 2007]. A título de comparação, a usina de Itaipu gera aproximada-mente 12 gigawatts [Itaipu 2009].

Muitos Data Centers estão sendo construídos perto de usinas geradoras deeletricidade para poder suprir as necessidades de energia para processamentoe arrefecimento. As hidrelétricas são particularmente interessantes pois, alémda energia elétrica, se localizam perto de rios que podem ajudar no sistemade resfriamento (com consequências ambientais, certamente). Um relatório daMcKinsey & Co. [Forrest e Brill 2000] indica uma série de dados preocupantesem relação ao impacto ambiental causado pela geração de energia necessáriaà alimentação de centros de processamento de dados (Data Centers). A Ta-bela 1.1 mostra a situação mundial das emissões de dióxido de carbono paraalgumas indústrias, incluindo o percentual relativo a Data Centers e servidores.O mais preocupante é que o consumo energético dessa última indústria vemcrescendo 9% ao ano, e é projetado que sua participação na emissão de dió-xido de carbono em nível mundial ultrapassará a das companhias aéreas em2020.

Tabela 1.1. Percentagem mundial da emissão de dióxidode carbono para algumas indústrias

Indústria Percentual

Aviação 0,6Estaleiros 0,8

Siderúrgicas 1,0

Data Centers 0,3

Apresentando os dados de emissão de dióxido de carbono em uma ou-tra perspectiva, observando as emissões geradas pela alimentação de Data

2

Clusters Verdes

Centers comparativamente às emissões totais de alguns países, podemos teruma boa ideia do impacto dessa indústria1. Isso está indicado na Tabela 1.2.Claramente, em função da dependência da sociedade em relação aos sistemascomputacionais, é necessário o desenvolvimento de novas técnicas e produtos,envolvendo componentes energeticamente mais eficientes, controle inteligentedo resfriamento de servidores e Data Centers, gerenciamento de consumo,entre outros tópicos. A IBM Global Technology Services, no Reino Unido, emrecente relatório [McBrayne e Lanyon-Hogg 2007], prevê que a área de TICtornar-se-á um alvo importante para economia de energia e para as preocupa-ções ambientais, assim como hoje são mundialmente as indústrias de aviaçãoe automobilística.

Tabela 1.2. Emissões de carbono por país

País CO2 por ano (Mt)

Argentina 142Holanda 146Malásia 178

Data Centers 170

Resultados preliminares do Balanço Energético Nacional 2009 (ano base2008) [EPE 2009], da Empresa de Pesquisa Energética (MME/Brasil), indicamque, na oferta interna de eletricidade, 85,4% vêm de fontes renováveis, sendo80% hidráulica. Assim, embora o Brasil tenha uma posição privilegiada relati-vamente ao resto do mundo, há fontes de preocupação.

A construção de novas usinas hidrelétricas (e.g., Belo Monte, Santo Antô-nio, Jirau) tem causado grandes questões ambientais, e o impacto do aque-cimento global no regime de chuvas nas regiões de represas traz preocupa-ções. Adicionalmente, novas represas no Brasil só serão construídas em re-giões afastadas dos grandes centros consumidores, o que aumenta a demandapara o uso de usinas térmicas (e.g., gás natural), que são mais poluidoras.

Uma grande parte da energia necessária para alimentar esses clusters é,contudo, perdida. Isso porque esses sistemas são projetados para garantirqualidade de serviço (e.g., tempo de resposta exato ou médio para cada usuá-rio) quando a carga for máxima. Assim, estima-se que eles operem usualmentesomente entre 20% a 30% de sua capacidade, permanecendo ociosos namaior parte do tempo [Elnozahy 2009, Kusic et al. 2008, Meisner et al. 2009].Medidas realizadas no Laboratório Tempo (www.tempo.uff.br) mostraramque o gasto de energia de servidores (computadores) ociosos pode facilmenteatingir 55% daquele necessário à sua operação em carga máxima.

1 O Brasil emite aproximadamente 360 Mt de CO2 por ano.

3


Um outro ponto muitas vezes negligenciado é o gasto de energia associadoao resfriamento dos equipamentos de um Data Center. Salas climatizadas re-querem o uso de sistemas de ar condicionado (AC), que normalmente são pro-jetados e utilizados como se o sistema computacional operasse durante todoo tempo à sua carga máxima. Grandes clusters comerciais requerem milharesde processadores e uma grande área para a sua localização. Assim, natural-mente, surge um desbalanceamento de temperatura em diversas localidadesdo Data Center. Em diversos pontos da(s) sala(s), mesmo que o equipamentocomputacional ali localizado não esteja operando no máximo, a refrigeraçãoatuará como se ele estivesse. Estima-se que para cada watt gasto com o pro-cessamento de dados, um outro watt é gasto com resfriamento.

Dessa forma, o estudo das técnicas associadas à Computação Verde éeconomicamente e ambientalmente fundamental. Este Capítulo trata exata-mente desse problema.

O objetivo básico das técnicas apresentadas na literatura sobre computa-ção verde é diminuir o gasto energético do cluster, mas mantendo a qualidadede serviço (QoS - Quality of Service; por exemplo, estabelecendo prazos parao término das tarefas) especificada em contrato (SLA - Service Level Agree-ment). Dessa forma, pode-se entender um tal cluster como um sistema detempo real não crítico (soft real-time system). Nesse sentido, o fundamental édiminuir o tempo ocioso dos servidores ativos do cluster, estimado entre 70%a 80% para Data Centers típicos, diminuir o gasto energético, mas garantindouma QoS pré-definida.

Os trabalhos apresentados na literatura especializada podem ser classifi-cados em 4 vertentes para efeito da discussão deste Capítulo: (i) Controle dafrequência de operação do processador, através da técnica DVFS - DynamicVoltage and Frequency Scaling; (ii) Configuração dinâmica, geralmente utili-zando técnicas de otimização para definição dos servidores que devem estaroperando para uma determinada carga; (iii) Virtualização, pelo uso de servido-res virtuais associados às aplicações, que podem ser migradas entre as má-quinas físicas; e, (iv) Controle térmico, via técnicas de distribuição de carga eatuação em sistemas de resfriamento ambiental (ar condicionado).

1.2. Composição de centros de processamento de dadosAntes de discutirmos arquitetura de clusters de servidores na próxima Se-

ção, vale expor os vários elementos que são necessários na construção deData Centers. A título de ilustração, o metro quadrado de um Data Center va-ria de acordo com o tipo de sala requerida. Em Março de 2010, para sala cofre,cujas paredes corta-fogo são de aço e suportam inundações externas de até1m de água, o custo é aproximadamente de R$ 130.000,00 o m2. Para salasseguras, que suportam temperaturas externas podendo atingir 1000◦C por 1hora, o custo diminui para aproximadamente R$ 90.000,00 o m2. Para salasconvencionais, de alvenaria pura e simplesmente, o custo é de aproximada-mente R$ 60.000,00 o m2. As salas cofre e seguras estão normatizadas pela

4

Clusters Verdes

ABNT, em normas número NBR 15247 e 10636. A Figura 1.1 exemplifica adisposição de bastidores em um Data Center típico.

Figura 1.1. Organização de um Data Center [de Barros 2010]

Além dos servidores, diversos outros elementos são importantes para aconstituição de um Data Center :

• Piso técnico elevado faz parte do ambiente, em geral. O piso elevadopossibilita que o ar condicionado seja direcionado para corredores friosentre as fileiras de racks, sendo o ar frio insuflado pelo piso. Em locaisdeterminados há furos no piso e exaustores que puxam o ar criando umcorredor frio. Do outro lado do rack ficam os corredores quentes, de ondesai o ar quente, que sobe, e os aparelhos de ar condicionado puxam eretiram o ar de dentro do ambiente para subsequente resfriamento.

Esses pisos elevados e a criação de corredores frios é padrão em DataCenters, pois evitam equipamentos de resfriamento com potências muitosuperiores à necessidade de dissipação de potência do ambiente, dimi-nuindo os custos de construção e operacional. Adicionalmente, podehaver um aproveitamento melhor do ambiente físico, aumentando o nú-mero de fileiras de racks; se aparelhos de ar condicionado “normais”fossem usados, os racks teriam que ser voltados para os equipamentosde ar condicionado com suficiente espaço para a circulação do ar frio.

Os métodos de climatização são normalmente classificados em “de pre-cisão” e “de conforto”. Para o primeiro, de precisão, não pode havervariação de temperatura (que deve ficar em torno dos 21◦C) em mais doque 5% na temperatura requisitada, ou na umidade relativa do ar (que

5


deve ficar em aproximadamente 50% e não poderá passar dos 85%), aopasso que no segundo tipo, o ar condicionado de conforto, a variaçãopode ser maior. Obviamente, deve-se colocar o maior número possívelde equipamentos em ar condicionado de conforto, já que o custo do arde precisão é aproximadamente 50% mais caro que o de conforto (emMarço de 2010, R$115.000,00 e R$75.000,00, respectivamente, paraum equipamento de 23 KVA que resfria aproximadamente 130 cores eoutros equipamentos necessários 24x7x365 horas no ano2).Há diversas configurações para colocação dos racks e das saídas de arno piso elevado, como mostra a Figura 1.2. O ar pode vir de cima oude baixo. O ar passa por dentro dos racks, mas pode ser retirado portrás ou por baixo (ou por cima). A facilidade e o custo de construçãonormalmente direcionam a configuração supracitada.

Figura 1.2. Saídas de ar [Liebert 2007]

• Controle de acesso e CFTV (Circuito Fechado de Televisão) do ambi-ente, câmeras IP, e controles biométricos. Esses equipamentos estão

2 Ignoramos propositalmente neste capítulo introdutório qualquer quantificação de dispo-nibilidade e de tolerância a falhas de equipamentos.

6

Clusters Verdes

conectados a sistemas para armazenamento dos vídeos. Todos eles re-presentam gastos adicionais de energia.

• Além da parte de arrefecimento, há também a parte de cabeamento (elé-trico e lógico). Em um ambiente de Data Center, cada servidor de pro-cessamento tem de 2 a 4 cabos de rede, cada servidor de base de dadostem mais 2 cabos de fibra ótica ligados ao storage e ao SAN (StorageArea Network), cada servidor (base de dados ou processamento) temainda mais 2 cabos de energia. Portanto, considera-se entre 4 a 8 cabospor servidor que têm que ser colocados em local onde não causem danoao equipamento e nem provoquem acidentes. Não raro, em um DataCenter de 100 servidores há mais de 500 cabos de rede/fibras, mais de200 cabos de energia, e todos passam sob o piso elevado.

• Fora os servidores utilizados pelas aplicações, há ainda no ambiente doData Center infraestrutura para suportar o gerenciamento da rede, ge-renciamento da segurança, vídeoconferência, telepresença, telefonia IP,e rede sem fio. Há também outros ambientes que compõem o Data Cen-ter como um todo: sala de controle e de segurança com display wall,ambiente para a equipe técnica de suporte, monitoramento e manuten-ção.

• Sistema de energia ininterrupta (no-break e grupo gerador) ficam forada sala do Data Center, mas fazem parte da solução. No caso de no-breaks, é necessário ambiente com ar condicionado, podendo ser o deconforto, com piso elevado. A célula nesse caso não precisa ser salacofre, talvez corta fogo ou, o mais utilizado, alvenaria.

• Finalmente, é importante a existência de sistemas de deteção precoce econtrole de incêndio. Esses sistemas incluem equipamentos de monito-ração do ambiente, com baixíssimo consumo de energia, mas que sãonecessários no ambiente. Além disso, um sistema de distribuição de gásFM200, interligado ao sistema de deteção precoce de incêndio, pode serusado para rapidamente controlar eventuais incêndios no Data Center eestruturas associadas.

1.2.1. Leituras adicionaisOs artigos a seguir podem ser consultados por leitores que desejarem

se aprofundar no assunto: [42U 2010, CSU 2006, Hydeman 2006, Intel 2008,Intel 2010, Rasmussen 2008, Samson 2008].

1.3. Organização e teste de um clusterA arquitetura de um web cluster pode assumir várias formas [Cardellini et al. 2002].

Para efeito da apresentação dos conceitos deste Capítulo, estamos assumindouma arquitetura em 3 camadas (3-tiers), como a indicada na Figura 1.3. Aprimeira camada desse cluster é aquela composta pelo front-end (FE), que re-cebe e distribui as tarefas a serem executadas; a segunda é composta pelosprocessadores da aplicação; e a terceira camada é onde residem as bases de

7


Figura 1.3. Arquitetura de um web cluster de servidores

dados e os processadores para acessá-las. Embora quando colocados inici-almente em serviço esses sistemas possam ser homogêneos, naturalmente,em situações reais, os clusters tornam-se heterogêneos pela adição de novosservidores ou pela troca de servidores defeituosos.

Não é nossa intenção discutir alternativas a essa arquitetura; isso está forado escopo deste Capítulo. Contudo, é importante dizer que na maioria dostrabalhos apresentados na área essa arquitetura é modificada e somente 2camadas são utilizadas. Isso é feito pois os autores desses trabalhos nãoquerem tratar problemas associados a bases de dados3, e procuram focar suasapresentações nos aspectos fundamentais das técnicas que estão propondopara gerenciamento energético de clusters.

O tipo de arquitetura presumido neste Capítulo, com um elemento cen-tral (FE), é bastante indicado quando se deseja implementar políticas de con-trole global. Por exemplo, tipicamente, no FE são executados o gerenciadorde configuração dinâmica, ações de balanceamento de carga, o controladordas frequências dos processadores dos servidores, e a medição de tempos deresposta de requisições, entre outras funções.

Por exemplo, para a medição do tempo de resposta de requisições, os au-tores de [Bertini et al. 2007] modificaram um servidor Apache, acrescentando

3 Os maiores problemas são os de consistência da base de dados (depois que o servidorfica fora do ar, tem que se sincronizar com os outros servidores e atualizar a sua cópiada base de dados) e de gargalo (bottleneck ) que afeta diretamente o desempenho dossistemas de clusters considerados.

8

Clusters Verdes

Figura 1.4. Medindo tempo de resposta em um clusterde servidores [Bertini et al. 2007]

um rótulo à página solicitada e a seus objetos embutidos, de forma a poderidentificar a chegada do último objeto de uma requisição web (diferentes obje-tos de uma página podem ser servidos por diferentes servidores do cluster ),como indicado na Figura 1.4, retirada do artigo referido. Essa ação é facilitadapelo fato de haver um FE central. Problemas de escalabilidade do cluster le-vam a implementação do FE por soluções hierárquicas ou hardware dedicado(essas soluções estão fora do escopo deste Capítulo introdutório).

Na avaliação de clusters como o da Figura 1.3, muitos trabalhos realizamexperimentos com base em simulação, outros fazem suas análises com basena implementação de sistemas de tamanho reduzido (i.e., menos de 30 servi-dores). Para a geração de tráfego, o programa httperf [Mosberger e Jin 1998]é frequentemente utilizado. De forma a obter resultados mais próximos da-queles de uma instalação real, traces como o da Copa do Mundo de Futebolde 1998 são empregados; vários traces de tráfego da Internet podem ser ob-tidos em [LBNL 2010]. Contudo, esse ainda é um problema na área: a dis-ponibilidade de traces mais realísticos, que possam adequadamente refletir ocomportamento (em constante mudança) de diversas classes de usuários.

Adicionalmente, os benchmarks mais citados na literatura são TPC-W [TPPC 2010],Rubis [OW2 Consortium 2010] e Trade6 [IBM 2010]. TPC-W é um benchmarktransacional para comércio eletrônico, onde a carga é oferecida em um ambi-ente de Internet controlado, que suporta múltiplas sessões de browsers, ge-ração de páginas dinâmicas, conexões seguras, entre outras características.Rubis é um protótipo de servidor web que modela um ambiente de leilão, simi-lar ao do e-Bay ou MercadoLivre. Trade6 é uma aplicação que simula compra

9


e venda de ações, integrada ao ambiente WebSphere da IBM.

1.4. Conceitos introdutóriosDe forma a poder discutir as soluções para power-aware clusters encontra-

das na literatura, precisamos apresentar alguns conceitos iniciais. Assim, nestaSeção veremos algumas noções de sistemas de tempo real, de consumo ener-gético, e de controle de frequências em processadores.

1.4.1. Sistemas de tempo realUm sistema computacional de tempo real (STR) é aquele em que os resul-

tados não devem ser apenas corretos do ponto de vista lógico, mas tambémdevem ser produzidos antes de um prazo pré-definido. Tipicamente, um STRrecebe requisições do ambiente para executar tarefas, adquire os dados ne-cessários (do ambiente, via sensores ou de bases de dados), faz algum tipo deprocessamento, e produz resultados desse processamento dentro dos prazosdefinidos pelo usuário.

Um STR, como a maioria dos sistemas de computação, é complexo, podeser distribuído ou não, utiliza diferentes subsistemas de hardware e software(e.g., sistemas de aquisição de dados e protocolos de comunicação), e cadaum desses subsistemas deve produzir resultados de forma a atender uma res-trição temporal. Obviamente, isso coloca uma carga extra sobre o SistemaOperacional (SO).

Na área de tempo real, as unidades escalonáveis (sejam elas processos outhreads) são comumente chamadas de tarefas. As tarefas de um STR podemser divididas em 2 classes: periódicas e aperiódicas. Tarefas periódicas sãocolocadas na fila dos processos prontos (ativadas) em intervalos fixos, chama-dos períodos. Por exemplo, uma tarefa associada a uma atualização de umabase de dados coletados do ambiente via sensores é geralmente uma tarefaperiódica. Tarefas aperiódicas podem ser ativadas a qualquer momento, porexemplo, para o processamento de um alarme ou para processamento de umarequisição de atualização via pedido feito através da web.

Normalmente, uma tarefa é caracterizada por um tripla: (C, T , D). C é otempo máximo de execução da tarefa (WCET - Worst Case Execution Time);T é o seu período, e D é o prazo (relativo à ativação). Na maioria das análisesde escalonabilidade de tarefas periódicas, assume-se que T = D, e no caso detarefas aperiódicas não é necessário definir T . T e D são dependentes da apli-cação; C é condicionado pela implementação (incluindo as características dehardware), e tem que ser avaliado pelo projetista via uma ferramenta específicaou através de testes.

Há momentos em que o processador estará ocupado executando tarefase outros nos quais o processador se encontrará ocioso. Estes espaços vazios(ou seja, onde há ociosidade do processador) são chamados de folga (slack ),e podem ser utilizados por uma política de economia de energia.

Um STR pode ser de dois tipos: crítico (hard real-time), ou não-crítico (softreal-time). STRs críticos são aqueles em que o seu mau funcionamento pode

10

Clusters Verdes

causar grandes perdas econômicas ou humanas. Por exemplo, aqueles em-pregados em aviônica ou em automóveis são sistemas críticos, pois seu maufuncionamento pode levar à morte de passageiros. Sistemas não-críticos sãoempregados quando a perda de prazos pode ser tolerada, como por exemplonos clusters de servidores discutidos neste Capítulo. A perda do prazo esti-pulado de uma requisição pode ser um aborrecimento para o usuário ou umapequena penalidade financeira direta ou indireta, mas não é razoável admitirque esse prejuízo seja tão grave quanto o do caso anterior.

A palavra-chave na área de tempo real crítico é previsibilidade. Isto signi-fica que devem ser dadas garantias de que todas as execuções de tarefas irãoocorrer antes de prazos especificados. Garantias, neste contexto, devem serexpressas através de uma análise matemática. Utilizar processadores rápidospode ser suficiente em muitos casos, mas isso não garante que em uma situ-ação especial prazos não sejam perdidos, com graves consequências para osistema.

Para oferecer garantias, hipóteses devem ser feitas em relação ao ambi-ente do sistema. Por exemplo, em sistemas críticos, a carga oferecida deve serbem quantificada, bem como os tempos envolvidos no processamento destacarga. Isto significa que todos os WCET das tarefas devem ser conhecidos.Isso não é um problema trivial, tendo em conta não apenas os caminhos diver-sos pelos quais um programa pode passar em sua execução, mas também pelofato do WCET ser dependente do hardware, da linguagem e das técnicas deprogramação utilizadas. Por exemplo, caches e loops ilimitados são fontes deimprevisibilidade. Além disso, se o sistema tiver de ser tolerante a falhas (TF),dependendo das técnicas empregadas, tempo extra de processamento deveser considerado e, também, levado em conta na análise de escalonabilidade.Em sistemas não-críticos, normalmente, controle de admissão de tarefas/re-quisições e comportamentos médios podem ser especificados.

Os dois algoritmos mais importantes para escalonamento de tarefas emSTRs são o RM (Rate Monotonic) e o EDF (Earliest Deadline First) [Liu e Layland 1973].O primeiro desses algoritmos é um esquema de atribuição de prioridades fixasàs tarefas, e assume que essas tarefas são periódicas. No segundo algoritmo,tarefas aperiódicas e periódicas são admitidas, e a atribuição de prioridades éfeita de forma dinâmica. Não iremos nos aprofundar no estudo desses algorit-mos; os leitores interessados encontram uma boa descrição em [Burns e Wellings 2009].

Sistemas de tempo real não críticos, por outro lado, podem funcionar comSOs onde o escalonador de tarefas não ofereça garantias temporais (e.g., Li-nux, Windows Server). No entanto, é esperado algum tipo de contrato entre ocliente e o provedor do serviço, onde uma especificação probabilística para aqualidade do serviço seja oferecida (e.g., 98% das requisições devem ter seusprazos atendidos).

11


1.4.2. Consumo e controle de potência em processadoresVários processadores atuais permitem o gerenciamento do consumo de po-

tência através da técnica de DVFS (Dynamic Voltage and Frequency Scaling).Essa técnica é baseada na constatação que para circuitos CMOS a potênciado processador é proporcional ao quadrado da tensão (voltagem) de operação:P ∝ V 2 f . Adicionalmente, V e f mantêm uma relação de proporcionalidade, eportanto pode-se aproximar o consumo de potência pela relação P ∝ f 3. Alémdisso, a energia consumida é obtida pela integral no tempo da função/curvaP. Pode-se também considerar que E = P× t, quando definimos P como a po-tência média consumida, fazendo com que a energia consumida tenha umarelação quadrática com a frequência utilizada, ou seja, E ∝ f 2.

Sendo o tempo de execução inversamente proporcional à frequência deoperação, a simples diminuição do valor da frequência, embora reduzindo ogasto de potência, não implicará em economia energética. Contudo, a redu-ção da tensão de alimentação pode oferecer um ganho quadrático em termosde economia de energia. Nos circuitos reais, entretanto, uma diminuição datensão de alimentação obriga a uma diminuição na frequência de operação.Dessa forma, nesse texto, quando falarmos sobre incremento/decremento defrequência está implícito que a tensão de operação também é alterada.

A mudança da frequência de operação, contudo, tem um custo. Para arealização dessa operação, uma certa potência é consumida (desprezível), epara a sua efetivação são gastas algumas unidades de tempo. Dependendo dalocalização do regulador de voltagem (dentro ou fora da UCP), essa transiçãopode levar entre 5 microssegundos (e.g, Core i7 da Intel) até centenas de mi-crossegundos ou milissegundos (e.g., nos AMD Athlon 64) [Hsu e Feng 2005].

Na implementação de um sistema com controle DVFS o projetista fica li-mitado ao número de frequências discretas disponíveis no processador. Porexemplo, um dos processadores AMD Athlon 64 3800+ oferece 5 frequênciasde operação: 1,0GHz, 1,8GHz, 2,0GHz, 2,2GHz, e 2,4GHz (ver Tabela 1.3abaixo para outros processadores da mesma família AMD Athlon 64). Certa-mente, a possibilidade de controlar o gasto de potência dessa maneira é umgrande avanço. Contudo, imaginemos a seguinte situação. Seja um sistemacomputacional (usando o processador acima) que, para tratar adequadamentea carga sendo oferecida (i.e., respeitando algum critério de QoS), pode operarem uma frequência de 1,0GHz. Vamos agora admitir que a carga cresça em10%; nessa situação, o sistema tem que aumentar a frequência para continuarrespeitando a QoS requisitada. Contudo, eleva-se a frequência do processa-dor à próxima frequência possível, que é 1,8GHz. Sendo o gasto de potênciarelacionado à frequência por uma relação cúbica, ela irá ser multiplicada por1,83 ∼= 5,8. Ou seja, um gasto suplementar de potência necessariamente ocor-rerá, pela obrigatoriedade do processador ser configurado em 1,8GHz.

Na situação acima descrita, uma perda de QoS poderia ser admitida se ocritério primordial fosse minimizar o gasto energético. Contudo, alguns resul-tados foram apresentados em [Ishihara e Yasuura 1998] que permitem fazer o

12

Clusters Verdes

Tabela 1.3. Alguns processadores AMD

Arquitetura Frequência máxima Número de(GHz) frequências

AMD Athlon 64 X2 3800+ 2,0 3AMD Athlon 64 3800+ 2,2 5AMD Athlon 64 3500+ 2,4 4AMD Athlon 64 3800+ 2,4 5AMD Athlon 64 X2 5000+ 2,6 6

processador “operar” na frequência teórica (ideal) desejada. Sinteticamente,eles demonstram que:

• Se um processador somente pode utilizar um número discreto de frequên-cias, o escalonamento com o uso máximo de duas frequências, paraqualquer restrição temporal, minimiza o consumo de energia;

• Se um processador somente pode utilizar um número discreto de frequên-cias, aquelas que minimizam o consumo de energia, para uma dada res-trição temporal, são as imediatamente vizinhas à frequência ideal.

Esses resultados permitem viabilizar um processador “ideal” que suportariaum esquema de frequências “contínuas”. Vamos admitir que, para uma dadacarga, o sistema devesse operar em uma frequência fideal para atender às suasrestrições temporais e minimizar o gasto energético. Vamos também admitirque durante um período T , N ciclos de máquina devam ser executados nessafrequência fideal . Para tornar a explicação mais clara, vamos olhar a Figura 1.5.

Nesse caso, poderíamos ter um desempenho equivalente se o sistema exe-cutasse por N1 ciclos na frequência f−, e por N2 ciclos na frequência f +, onde,obrigatoriamente, N = N1 +N2, e f + e f− são frequências reais do processador,imediatamente acima e abaixo de fideal , respectivamente.

Para encontrar o ponto t onde o chaveamento de f− para f + deve ocorrer,basta resolver a equação

t × f− +(T − t)× f + = T × fideal (1)

onde, à exceção de t, todas as variáveis são conhecidas.Para viabilizar esse esquema, deve-se construir uma rotina (de alta prio-

ridade) que executa com um período de T unidades de tempo. Conhecidaa frequência ideal de operação para uma dada carga, a frequência do pro-cessador é alternada de f− a f + nos instantes t + kT (k = 0,1, ...) e de f + af− nos instantes kT (k = 1,2, ...). Adicionalmente, T e t deverão ser definidosem função da dinâmica de variação da carga, e levando em consideração otempo de mudança entre frequências em um processador real (da ordem de

13


Figura 1.5. Simulando frequências contínuas

dezenas de microssegundos). Esse tipo de controle foi utilizado, por exemplo,em [Bertini et al. 2009].

Como observações finais, deve-se mencionar que:

1. A solicitação de alteração de frequências ocorre através do SO, masdeve haver suporte na placa-mãe para essa operação. No caso da AMD,a técnica é chamada de Cool’n’Quiet [AMD 2010], e no caso da Intel échamada de SpeedStep [Intel 2004].

2. Nos novos processadores, com múltiplos cores, há a possibilidade decontrolar a frequência de cada um deles individualmente.

3. Nos instantes t + kT pode-se chavear de f + a f− para cada tarefa, maschaveando-se de f− a f + pode-se economizar mais energia em geral.Esse comportamento é uma extensão dos trabalhos PACE [Lorch e Smith 2004],GRACE [Yuan e Nahrstedt 2003], e PPACE [Xu et al. 2004], pois é umcomportamento otimista: as tarefas podem terminar prematuramente4,e assim elas já teriam executado na frequência e voltagem mais baixaspor mais tempo, economizando energia.

4 Normalmente, os sistemas de tempo real têm que garantir que as tarefas terminarãodentro dos prazos requisitados e, assim, são dimensionados para o máximo de tempoque a tarefa pode levar a executar; frequentemente as tarefas executam por aproxima-damente 10% do tempo máximo [Ernst e Ye 1997], ou até menos [Rusu et al. 2004].

14

Clusters Verdes

1.4.3. Uma Interface para configuração de potência

Apesar de os modelos iniciais levarem em consideração somente umaúnica fonte de consumo de energia pela UCP, logo se notou que existem ou-tras fontes de consumo em processadores e em sistemas de computação emgeral. Em relação ao processador, em [Zhu et al. 2004] a energia foi modeladacom a relação quadrática mencionada acima e, além disso, notou-se que oconsumo pode ser dividido em duas partes, uma que depende diretamente dafrequência, e uma parte que independe da frequência de operação. A primeiraé o consumo suplementar que ocorre quando o processador está em operação(potência dinâmica), e a segunda corresponde ao consumo do processadordesocupado, devida às polarizações internas (potência estática).

Devido à complexidade dos microprocessadores hoje em dia, existem vá-rios estados de diferentes consumos de potência que são definidos por pa-drões/normas. O padrão mais adotado é a ACPI (Advanced Configuration andPower Interface, ou Interface Avançada para Configuração de Potência), queespecifica os estados que o SO pode usar; obviamente, esses estados têmque ter suporte do hardware, particularmente da placa-mãe e do processador.O mapeamento das capacidades do hardware é feito pelos drivers do SO. Ainterface ACPI determina 4 estados globais do sistema, chamados G-states:G0 – Working (ativo), G1 – Sleeping (suspenso, hibernando), G2 – Soft-off (oprocessador está parado, mas pode ser reiniciado via interrupções de hard-ware dos dispositivos de entrada e saída), e, finalmente, G3 – Mechanical off,que é quando a máquina está realmente desligada. Como se pode perceber,os números menores indicam maior gasto de potência.

O padrão ACPI ainda prevê uma hierarquia de estados de menor potência,dependendo da atividade no processador. Particularmente interessante são ossub-estados dos estados G0 (Working), que são chamados de C-states, e G1(Sleeping), que são chamados S-states. O processador pode estar em váriosC-states, a saber, C0 (execução normal, atividade plena), C1 (ocioso), C2 (me-nor consumo de potência do que C1, mas com mais latência para se retornarao estado ativo), ou C3 (menor consumo de potência do que C2, mas com maislatência para se retornar ao estado ativo). O estado C0 (ativo) é por sua vezsub-dividido em vários estados de processamento (P-states, correspondendoàs diferentes frequências possíveis do processador), sendo o P0 o de maiordesempenho e consumo energético, e o Pn o de menor desempenho e con-sumo energético. Os possíveis S-states vão de S0 a S4, sendo os já definidos(e mais importantes) o estado S3, também chamado de “suspend”, e o estadoS4, ou “hibernate”. O estado G2 também é chamado de S5.

Exemplos de processadores, com suas frequências e respectivas volta-gens, em cada um dos estados definidos pela ACPI são mostrados nas Ta-belas 1.4 e 1.5.

15


Tabela 1.4. AMD Phenom II [AMD 2009]

Frequência (GHz) Voltagem (V) Estado

3,0 1,425 P02,3 1,325 P11,8 1,225 P20,8 1,150 P3

Tabela 1.5. Intel Pentium M, frequência máxima 1,6GHz[Chen 2010]

Frequência (GHz) Voltagem (V) Estado

1,6 1,484 P01,4 1,420 P11,2 1,276 P21,8 1,164 P30,8 1,036 P40,6 0,956 P5

1.4.4. Wake-on-LANQuando se faz o gerenciamento de clusters, é obviamente necessário ligar

e desligar servidores. Mais especificamente, é necessário passá-los de umestado a outro. Como vimos na Seção 1.4.3, quando se está num estado debaixo consumo energético, pode-se sair deste via interrupções de entrada esaída. Normalmente, essas interrupções são feitas via o mecanismo de Wake-on-LAN, ou seja, a placa de rede fica ligada, esperando a recepção de umpacote de rede com dados (bits) específicos. Quando chega esse pacote, aplaca de rede passa a informação para a placa mãe que “desperta” a UCP,retornando-a a um estado de atividade maior. Vale mencionar que nos proces-sadores Athlon 64 o consumo de potência quando o servidor está em estadode Wake-on-LAN é de aproximadamente 5W, quando ocioso é de aproximada-mente 70W, e quando em frequência e voltagem máximas é de 140W.

1.5. Trabalhos iniciais em economia de energiaAs pesquisas na área de economia de energia não foram iniciadas, obvia-

mente, em clusters de servidores. Inicialmente, os pesquisadores concentraram-se em sistemas de um único processador. Nessa Seção vamos apresentar oprimeiro trabalho na área, o primeiro trabalho que combinou gerenciamento deenergia com características temporais, e um trabalho representativo na área desistemas embarcados. Em todos esses casos a técnica de DVFS é explorada,a partir de política embutida no escalonador do sistema operacional.

16

Clusters Verdes

1.5.1. O artigo seminal de Weiser, Welch, Demers e Shenker

O primeiro trabalho publicado na área de economia de energia em siste-mas computacionais, envolvendo técnicas controladas pelo sistema operacio-nal, foi [Weiser et al. 1994]. Nele os autores propõem três algoritmos de es-calonamento de processos para atuar no controle de DVFS do processador.Para os testes apresentados no artigo, os autores realizaram simulações combase em dados de traces de um escalonador Unix, obtidos de várias horas deexecução de estações de trabalho.

O primeiro algoritmo, OPT, analisa todo o trace e atua nos momentos deescalonamento para diminuir a frequência de operação, de forma a reduzir osperíodos ociosos do processador. O segundo algoritmo, FUTURE, olha so-mente uma pequena janela de tempo a frente, e toma a decisão que otimiza ogasto energético. O terceiro algoritmo, PAST, analisa o ocorrido em uma janelade tempo passada, e atua no controle de frequência admitindo que o futuropróximo se comportará como o passado imediato.

Claramente, os dois primeiros algoritmos, por dependerem de conheci-mento perfeito do futuro, não são implementáveis. Contudo, servem de referên-cia para comparação com PAST, o único dos algoritmos que é implementável.É interessante observar como a qualidade de serviço é tratada. No único al-goritmo realizável, PAST, a proposta é observar quantos ciclos de instruçãodeixaram ou não de ser executados na última janela e atuar na frequência deoperação. Um esquema de banda (deadzone) é empregado para garantir es-tabilidade no controle (evitar comportamento oscilatório).

Os gastos de potência (normalizados) dos algoritmos desse artigo estãoindicados na Figura 1.6, para 3 diferentes pontos de operação (voltagens) eem função do período de ativação do mecanismo de ajuste de frequências. Oalgoritmo OPT é insensível a esse último parâmetro, já que olha todo o trace. Éinteressante observar que PAST tem melhor desempenho que FUTURE, poisciclos não executados na última janela podem ser transferidos para o intervaloseguinte. A medida que o intervalo diminui, a velocidade da UCP é ajustadamais frequentemente e, assim, acompanha melhor a carga oferecida, mas gas-tando mais energia.

Um outro ponto interessante do artigo é a classificação das tarefas a se-rem executadas em diferentes classes (background, periódicas e foreground).Os autores propõem que para a execução de tarefas do tipo background nãohá necessidade de aumentar a velocidade do processador. Tarefas periódi-cas, que apresentam uma carga constante e a indicação de um prazo, podemser executadas com velocidade suficiente para atender esse último. Quandohá uma combinação dos diversos tipos de tarefas, a sugestão é escalonar pri-meiro as tarefas periódicas, acomodar as do tipo foreground na sequência e,finalmente, encaixar as tarefas do tipo background.

17


Figura 1.6. Gasto de potência: OPT, FUTURE ePAST [Weiser et al. 1994]

1.5.2. Combinando gerenciamento de energia e tempo realUm dos primeiros artigos que combinou explicitamente DVFS com os pro-

blemas de tempo real foi publicado no ano 2000 [Mossé et al. 2000], e propôs 3algoritmos para economizar energia enquanto respeitava os prazos das tarefas.Esses três algoritmos, Proportional, Greedy, e Statistical, tratam de distribuir otempo extra antes do prazo limite entre as tarefas de maneiras distintas. O Pro-portional distribui proporcionalmente ao pior caso do tempo de execução decada tarefa, enquanto o Greedy dá todo o tempo extra para a próxima tarefaa ser executada, e o Statistical distribui o tempo extra baseado na média dotempo de execução das tarefas. Esse trabalho inicial tratava somente de con-juntos de tarefas com um único prazo em comum, presumia que as frequênciasdo processador eram continuamente sintonizadas entre 0 e 1, e não admitiapreempção das tarefas.

Impulsionados por esse trabalho inicial, mesmo sendo um trabalho teórico,os mesmos autores sugeriram métodos mais formais para provar que há algo-ritmos que são ótimos do ponto de vista de redução de energia em sistemasde tempo real [Aydin et al. 2001, Aydin et al. 2004]. Nesses trabalhos, aindaum único servidor é considerado, mas leva-se em conta que tarefas podem serinterrompidas para executar tarefas de maior prioridade. Definindo um esca-lonamento ótimo, que também não é realista, os autores sugerem heurísticascom desempenho próximo ao algoritmo ótimo, com um parâmetro de agressivi-dade (otimismo) que se pode variar. Quanto mais otimista o algoritmo, mais de-vagar o sistema configura a frequência do processador. Intuitivamente, dessaforma, mais energia (em média) seria economizada no sistema. Entretanto,

18

Clusters Verdes

quando o algoritmo é otimista demais, algumas vezes o sistema executa tare-fas tão devagar que fica sendo necessário executar outras tarefas muito maisrapidamente, elevando-se desnecessariamente a frequência do processador,causando maiores gastos de energia no cômputo geral.

1.5.3. Uma proposta em sistemas embarcadosO artigo de [Pillai e Shin 2001] propõe algoritmos para controle de gasto

energético em sistemas de tempo real embarcados, sistemas esses que mui-tas vezes são do tipo tempo real crítico. Nesse trabalho os autores apresentamabordagens estáticas (off-line) e dinâmicas (on-line) para sistemas de temporeal críticos. Na abordagem estática seleciona-se a menor freqüência operaci-onal possível que ainda permita ao escalonador, no caso EDF ou RM, garantirtodos os prazos do conjunto de tarefas. A redução é feita com base nos testesde escalonabilidade conhecidos para esses dois algoritmos, pela introduçãode um fator de escala (relação entre a freqüência de operação pretendida e afreqüência máxima permitida pelo processador) para os tempos de execuçãomáximos das tarefas.

Na abordagem dinâmica, ou seja, para o caso em que as tarefas execu-tam por menos tempo que o seu WCET (Worst Case Execution Time), sãoapresentados dois algoritmos: o Cycle Conserving, desenvolvido para escalo-nadores RM e EDF, e o Look Ahead, desenvolvido somente para EDF. Ambosos algoritmos se baseiam no cálculo da utilização do processador ao términoda execução de cada tarefa, de forma a recuperar quaisquer ciclos (previstosno WCET) não utilizados. A diferença entre esses algoritmos é que no LookAhead é assumida uma abordagem otimista, mais agressiva, onde, no inícioda execução da tarefa, ela é processada em uma frequência inferior, podendoessa freqüência ser aumentada para garantir o atendimento à restrição tempo-ral (como mencionado acima e sugerido nos trabalhos de [Lorch e Smith 2004,Xu et al. 2004, Yuan e Nahrstedt 2003]).

Para se ter uma ideia de como essa proposta funciona, vejamos o casomais simples, o da abordagem off-line, para um escalonador EDF. Sob determi-nadas condições (ver, por exemplo, [Burns e Wellings 2009]), um conjunto de ntarefas é escalonado pelo algoritmo EDF se a condição indicada na Equação 2for atendida (as variáveis foram descritas na Seção 1.4.1), admitindo opera-ção na frequência máxima do processador, fmax, e sem considerar overheads(nesse exemplo, fmax é normalizada e igual a 1):

n

∑i=1

Ci

Ti≤ 1 (2)

Admitindo um conjunto de tarefas que não usa o processador 100% do tempo,se a frequência do processador for alterada para f = α fmax, 0 ≤ α ≤ 1, o tempode execução das tarefas será agora de Ci/α . Ou seja, o processador seráoperado em uma frequência menor, gastando menos potência, mas as tarefaslevarão mais tempo para serem completadas. Assim, para garantir que a esca-

19


lonabilidade do sistema será mantida, é necessário e suficiente que a condiçãoestabelecida pela Equação 3 seja satisfeita:

n

∑i=1

Ci

Ti≤ α (3)

A Figura 1.7 exemplifica o método estático, onde durante toda a operação oprocessador executará em somente uma das suas possíveis frequências. Paraesse exemplo, um processador teórico com 3 frequências (normalizadas) é uti-lizado; são elas 1,00, 0,75 e 0,50. O conjunto de tarefas desse exemplo estáindicado na Tabela 1.6. Um simples cálculo, utilizando a Equação 3, demons-tra que nessa situação é factível operar o processador em uma frequência 75%do valor da frequência máxima, atendendo aos prazos das tarefas, e economi-zando energia.

Figura 1.7. Exemplo de DVFS estático comEDF [Pillai e Shin 2001]

Tabela 1.6. Conjunto de tarefas para o exemplo da Figura 1.7

Tarefa WCET (ms) Período (ms) Prazo (ms)

T1 3 8 8T2 3 10 10T3 1 14 14

20

Clusters Verdes

1.5.4. Leituras adicionaisOs artigos a seguir podem ser consultados por leitores que desejarem se

aprofundar no assunto: [Ellis 1999, Kim et al. 1999, Novelli et al. 2005].

1.6. Economizando energia em clustersNesta seção descreveremos trabalhos representativos que especificamente

tratam de economia de energia em clusters.

1.6.1. O primeiro trabalho na áreaO primeiro trabalho publicado sobre configuração dinâmica em clusters de

servidores foi do grupo da Universidade de Rutgers, EUA, [Pinheiro et al. 2001].A ideia central do artigo é desenvolver técnica para dinamicamente ligar umservidor (nó), e dessa forma configurar o sistema para tratar eficientemente acarga crescente, e desligar servidores para diminuir o consumo de potênciaquando a capacidade de processamento do cluster for superior aquela neces-sária para tratar a carga. A proposta dos autores é concentrar (desbalancear)a carga em alguns servidores, para poder desligar outros e gastar menos po-tência. Gastar menos potência implica em menores gastos com o sistemade resfriamento (cooling), e, obviamente, acarreta em economia de energia.Nesse trabalho, um cluster homogêneo é assumido, e a técnica de DVFS nãoé empregada.

Basicamente, o algoritmo proposto executa periodicamente, e aceita a re-moção de um nó do sistema se a degradação do desempenho esperada paraqualquer aplicação executando nesse nó é menor do que um limiar pré-definido(degrad), e o período desde a última reconfiguração é maior do que um valordefinido por outro limiar (elapse). A adição de um nó é necessária se a degra-dação atual do desempenho é pelo menos degrad, e o tempo decorrido desdea última reconfiguração é maior do que elapse. A implementação do algoritmoé centralizada, e a previsão da demanda por recursos do sistema (UCP, rede ediscos; cada nó envia informação ao nó controlador central) é feita com baseem uma média exponencial amortizada [Makridakis et al. 1997]. Um esquemade migração de aplicações é necessário, tanto para desbalancear o cluster(desligamento), quanto para ligar um nó (e balancear o processamento entreos nós ativos).

A Figura 1.8 abaixo mostra o resultado do consumo de potência de umcluster com 8 máquinas, para uma dada carga oferecida, e para duas políti-cas. Na primeira, Static Configuration, nenhuma alteração de configuração érealizada. Na segunda, Dynamic Configuration, a configuração do cluster édinamicamente adaptada para atender às variações da demanda. Uma eco-nomia de energia de 43% é reportada, indicando o grande potencial de umapolítica que adapta a configuração do cluster em função da carga oferecida.

1.6.2. Juntando configuração dinâmica e DVFSO trabalho apresentado em [Elnozahy et al. 2002] foi o primeiro a discutir o

uso conjunto de DVFS e configuração dinâmica em clusters de servidores, isto

21


Figura 1.8. Consumo para servidor WWW com elapse =

200s [Pinheiro et al. 2001]

é, a determinação de quais servidores estarão ligados e quais serão desliga-dos, e em que frequências operarão. Nesse trabalho, os autores cunharam oacrônimo VOVO para essa última operação, significando Vary-On / Vary-Off, eapresentaram 5 políticas globais (cluster wide) de gerenciamento de potênciapara clusters de servidores homogêneos. É importante frisar que nesse traba-lho a avaliação de desempenho foi feita com base em simulação, o que reduzem muito a quantidade de problemas a serem tratados, mas o que tambémdiminui a fidedignidade dos resultados, pois ignora vários detalhes que existemem uma implementação real.

As 5 políticas propostas e suas formas de operação são descritas a seguir.Nas duas primeiras, todos os nós estão ativos durante toda a operação dosistema, mesmo que a carga do sistema seja baixa.

• Independent Voltage Scaling (IVS): cada nó do cluster gerencia inde-pendentemente (localmente) o seu consumo de potência, fazendo usode DVFS. Não há nenhuma comunicação de estado entre nós, e nempara um controlador central. Como há uma política de balanceamentode carga, os nós operam, aproximadamente, na mesma frequência. Va-riações nas frequências de operação entre os nós são possíveis, emvirtude de flutuações na carga.

• Coordinated Voltage Scaling (CVS): cada nó reporta a um nó central asua frequência de operação. Esse nó central periodicamente calcula a

22

Clusters Verdes

frequência média de operação desses diversos servidores, e envia essainformação a todos eles. Cada um dos nós servidores procura, então,operar em uma pequena faixa de frequências em torno dessa frequênciamédia difundida. Essa política deve fornecer um melhor resultado emtermos do consumo de potência, já que um cluster de servidores ope-rando em uma frequência f é mais eficiente que um outro operando comos nós em frequências distintas mas com média f , dadas as relações defrequência e potência descritas na Seção 1.4.2.

• VOVO: nesse caso, servidores serão ligados ou desligados conforme avariação da carga oferecida ao sistema. Um balanceamento de cargaexiste entre os nós ativos; cada um desses nós informa a um controladorcentral a sua utilização. Neste caso, os servidores ativos não tem políticade DVFS.

• VOVO-IVS: é uma combinação das técnicas VOVO e IVS acima descri-tas.

• VOVO-CVS: é uma combinação das técnicas VOVO e CVS acima descri-tas. Um novo nó é ligado quando é observado que os nós operacionaisdeverão funcionar em uma frequência acima da frequência máxima doprocessador. De forma similar, se é observado que a frequência de ope-ração deverá ficar abaixo da frequência mínima do processador, um dosnós será desligado.

Os autores propõem uma modelagem analítica para otimizar o consumode potência, onde assumem que a potência consumida em cada nó é umafunção cúbica da frequência de operação. A frequência de operação é ajus-tada em função da utilização dos processadores dos nós (limiares superior einferior são utilizados: 95% e 85%, respectivamente). Como resultado dessamodelagem, para uma dada configuração de n servidores, são calculadas emque frequências de operação o cluster deverá se encontrar quando tiver deser reconfigurado para n−1 ou n + 1 nós. Não há o uso direto de alguma mé-trica de qualidade de serviço (e.g., tempo de resposta); o trabalho apresentadopresume que essa QoS será obtida mantendo-se os processadores entre oslimiares de utilização acima referidos.

A Figura 1.9 apresenta resultados de gasto energético para as 5 técnicas ci-tadas, para dois workloads distintos (um da área de Finanças e outro dos jogosJogos Olímpicos de inverno de 1998), dois custos fixos distintos (potência es-tática de 6W e 8,6W), e traces cobrindo um período de 24 horas. Nessa figuraé importante observar o ganho obtido por IVS e CVS sobre um sistema semnenhum controle de potência. Adicionalmente, um novo salto ocorre quandoconfiguração dinâmica é adicionada a esses mecanismos. Os autores tambémressaltam que, em função de características dos traces, no último experimentonão há um ganho claro pela adição de VOVO a IVS e CVS.

23


Figura 1.9. Energia consumida em 4 experimentos dis-tintos [Elnozahy et al. 2002]

1.6.3. Introduzindo heterogeneidade e uma implementação r ealO trabalho apresentado em [Rusu et al. 2006] foi um dos primeiros traba-

lhos a tratar clusters heterogêneos baseados em medição e não em simula-ções. Desta forma, os detalhes que normalmente eram omitidos nas simula-ções, como por exemplo o tempo e a energia requeridas para se iniciar umservidor depois de desligado, começaram a surgir como fatores importantes.De fato, notou-se que o tráfego de rede devido à troca de informações de cargae resultados de violações de prazos não é um fator significativo em ambientesde clusters para tráfego de Internet.

Na organização proposta, o cluster tem um front-end que serve de dis-tribuidor de carga, bem como é o nó responsável pelo cálculo da frequênciaaproximada a ser usada em cada servidor. Entretanto, cada um dos servidoresexecuta uma política de DVFS local, que depende do número e tipo de requisi-ções, bem como do tempo de execução das requisições. Uma política de pilhapara ligar e desligar é adotada nesse trabalho: o próximo servidor a ser ligadoé o que requer menor potência para processar as requisições que excedem acapacidade do cluster na configuração corrente. O front-end desliga o últimoservidor a ser ligado, ou seja, o que tem a maior potência dissipada entre osservidores ativos.

O front-end distribui as requisições web aos servidores da camada 2 le-vando em consideração a capacidade de cada servidor, que foi medida a prioripara levantar quantas requisições e de que tipo cada servidor tem a habilidade

24

Clusters Verdes

de processar por segundo, de várias formas diferentes, a saber: (i) distribuiçãopor carga; (ii) distribuição por custo de cada requisição; e, (iii) distribuição porenergia consumida pelas requisições. Um dos problemas identificados foi amedição das métricas sugeridas nos itens (i) a (iii); por exemplo, no cálculo dacarga, se os servidores forem muito rápidos em relação ao tempo de execuçãodas requisições, a carga pode ser subestimada, causando que a frequênciado servidor seja configurada abaixo do necessário. Esse problema pode sersolucionado calculando cada métrica em um intervalo suficientemente longo,causando, contudo, perda da informação de granularidade fina sobre a cargaobservada.

Os resultados reportados (ver Figura 1.10) mostram que a configuraçãodinâmica é a que tem a maior contribuição para economia de energia, poisdesliga os servidores ociosos. Nota-se na figura que quando a carga é zero, ocluster consome aproximadamente 32W, pois cada um dos servidores Athlon64 utilizados consome aproximadamente 8W quando em estado de hibernação(ver Wake-on-LAN na Seção 1.4.4) e o servidor Transmeta empregado tambémconsome 8W quando ativo (esse é o primeiro servidor a ser ligado). O DVFStem a sua maior contribuição quando: (a) a carga do cluster está acima de70%, pois todos os servidores estão ativados; e, (b) quando um novo servidoré ativado. A importância do DVFS diminui a medida que a carga aumenta, paraum número fixo de servidores.

0

50

100

150

200

250

300

350

400

0 20 40 60 80 100

Pot

enci

a m

edia

(W

)

Carga (%)

Sem gerenciamentoDVFS

On/OffOn/Off + DVFS

Figura 1.10. Comparação de políticas de DVFS e VOVOem clusters heterogeneos [Rusu et al. 2006]

25


1.6.4. Adicionando controle e independência de modeloTradicionalmente, a qualidade de serviço em clusters de servidores web é

medida pelo quociente entre o número de requisições atendidas no prazo e onúmero total de requisições, em uma determinada janela de tempo. No trabalhoapresentado por [Bertini et al. 2007] foi observado que, em vez de quantificaro número de transações completadas com sucesso, como é praxe nesse tipode trabalho, seria possível fazer o gerenciamento energético com base em umpercentil da função de distribuição da folga (ou do atraso) do tempo de res-posta em relação ao prazo estabelecido para a requisição. Estudar o atrasoacumulado numa janela de tempo fornece mais informações sobre o estado dosistema (quanto mais atrasadas as tarefas, mais aceleração é necessária nosservidores).

Com base no percentil de requisições que devem ser atendidas no prazo(e.g., 95%), um controlador PIDF (Proportional Integral Derivative with a low-pass Filter ) altera as velocidades de operação das máquinas do cluster (ouseja, atua no mecanismo de DVFS). Esse controlador é executado no front-end, onde são guardadas as informações de configuração do cluster. Sendoo FE um ponto central, a medida dos tempos de resposta das requisições éfacilitada. Adicionalmente, o FE executa o balanceamento de carga, com distri-buição dependente da capacidade de cada servidor (ou seja, é assumido queo cluster pode ser heterogêneo).

Nesse trabalho, os autores modelam essa variável, ou seja, a folga ou oatraso (que chamam de tardiness), através das distribuições Pareto e Lognor-mal, e os resultados reportados, em termos de gasto energético e QoS, indicamganhos em relação a outras propostas. Esse método, denominado métodoTQM (Tardiness Quantile Metric), foi aplicado a um cluster de 2 camadas; aterceira camada não foi tratada nesse trabalho.

Em trabalho posterior [Bertini et al. 2009], os mesmos autores generaliza-ram o método TQM para qualquer distribuição, através do uso de aproximaçãoestocástica [Kushner e Yin 2003]. Esse método é chamado de GTQM - Gene-ralized TQM, e se baseia no algoritmo de Robbins-Monro [Robbins e Monro 1951],que faz a avaliação do percentil de uma função de distribuição durante a exe-cução do sistema, independentemente do conhecimento da forma da função.

Os autores compararam a proposta desse último trabalho com a solução jáotimizada de [Rusu et al. 2006] (ver também Seção 1.6.3). Para um teste de1,8h de duração, e com uma carga sintética, eles demonstraram que um ganhoadicional de até 5,2% poderia ser obtido, conforme indicado na Figura 1.11.

Os mesmos autores apresentaram uma solução para a questão da con-figuração dinâmica, através de um método de otimização. O problema emquestão consiste em definir, para uma dada carga, qual a melhor configuraçãoa ser aplicada a um cluster de servidores heterogêneos. Ou seja, como otimi-zar o número de máquinas ativas (ligadas), bem como definir a frequência deoperação de cada uma dessas máquinas [Bertini et al. 2010]. Eles trataram oproblema através de Programação Inteira Mista (PIM), e testaram com sucesso

26

Clusters Verdes

Figura 1.11. Eficiência do método GTQM [Bertini et al. 2009]

a técnica proposta em um protótipo real.Nesse mesmo trabalho os autores discutem duas alternativas para a im-

plementação do mecanismo de controle de QoS. Na primeira, SISO (SingleInput Single Output), existe um único controlador PIDF cuja saída (normali-zada) serve de entrada para tabelas geradas off-line (pela otimização via PIM),onde uma frequência de operação é obtida para cada máquina do cluster, alémda indicação de quais máquinas estarão on-line. Na segunda, SIMO (Single In-put Multiple Output), a referência de tardiness é enviada para N controladoresindependentes (um por servidor), e não há nenhum mecanismo de otimiza-ção global para DVFS, somente para decidir que máquinas estarão ligadas.O primeiro mecanismo, embora ótimo, tem como desvantagem a necessidadede gerar tabelas off-line, o que pode ser um problema para Data Centers demédio e grande porte (i.e., com mais que 30 servidores). O segundo meca-nismo dispensa a procura por uma configuração global ótima de frequências,deixando o seu ajuste para os N controladores PIDF locais, um por servidor.No artigo os autores demonstram que a primeira alternativa oferece um de-sempenho energético ligeiramente melhor, conforme indicado na Figura 1.12,e que a vantagem da SISO aumenta para uma carga crescente de requisições.

1.6.5. Tratando arquiteturas de 3 camadasEmbora em sua topologia mais geral clusters de servidores possam ser re-

presentados por um modelo de 3 camadas (3-tiers), ou seja, front-end (primeiracamada, ou camada 1), camada de aplicação (segunda camada, ou camada 2)

27


Figura 1.12. Comparação entre SISO e SIMO [Bertini et al. 201 0]

e camada de dados (terceira camada, ou camada 3), a maioria dos trabalhosapresentados na literatura trata somente do controle DVFS e configuração di-nâmica da segunda camada. Isso ocorre por duas razões: (i) esses trabalhosnão querem se envolver com problemas de consistência das bases de dados(afinal, não é o foco do que querem discutir) e, assim, evitam configuraçãodinâmica na terceira camada; e, (ii) a coordenação para controle conjunto deDVFS das camadas 2 e 3 coloca novos desafios, complicando o problema.

Sem discutir configuração dinâmica nas camadas 2 e 3, o trabalho apresen-tado em [Horvath et al. 2007] mostra uma solução para o controle do retardofim a fim das requisições em clusters de n camadas (via DVFS), e ao mesmotempo minimiza o consumo de energia. O retardo controlado é definido em umcontrato (SLA), e múltiplos tipos de requisições (ou usuários) são tratados damaneira mais simples: resolve-se o problema daqueles que estiverem com aQoS abaixo da especificada, um de cada vez, mesmo que fornecendo a outrosuma QoS superior a contratada.

Os autores pressupõem que a carga entregue a cada camada é balance-ada, o que simplifica o problema e permite estudar o comportamento do quechamaram de um caminho (path). Um caminho é entendido como a conca-tenação de um servidor por camada. Na verdade, para evitar problemas dedefinição das características desses servidores, eles também tratam o sistemacomo se fosse homogêneo por camada. Considerando um único caminho, osproblemas de heterogeneidade e balanceamento desaparecem.

O artigo apresenta dois algoritmos, Feedback DVS (FDVS), e WeightedFeedback DVS (WFDVS). O primeiro algoritmo tem um funcionamento bemsimples, indicado pela heurística abaixo:

Se o retardo fim a fim em um caminho excede um determinadolimite superior, a máquina com maior utilização no caminho tem

28

Clusters Verdes

sua frequência aumentada; se o retardo cai abaixo de um limiteinferior, a máquina com menor utilização tem a sua frequência di-minuída.

No trabalho é assumido que o front-end conhece os retardos fim a fim detodas as requisições, bem como a utilização de cada máquina no caminho. Umesquema de banda (deadzone) é definido, e um estudo baseado em teoria decontrole é feito para definir valores para os limites dessa banda (para evitarinstabilidades).

O segundo algoritmo é baseado no mesmo princípio, mas decorre de umamodelagem das máquinas em um caminho como filas M/M/1 (o que limita asdistribuições do tempo entre requisições consecutivas e do tempo de serviçode cada requisição a terem comportamento exponencial, mas é analiticamentetratável), ou seja, é uma aproximação proposta para o modelo real (que é des-conhecido). O que se busca, então, são as frequências que minimiza a potên-cia consumida em cada camada (nesse caso, em cada servidor do caminho) emantém o retardo abaixo de uma latência pré-definida. A solução apontada éaquela que equaliza o produto do peso de cada camada por uma função quedepende da utilização dessa camada. O peso de uma camada é uma funçãoda taxa de chegada de requisições e do tempo médio de serviço na camada,além de depender de uma constante oriunda da modelagem do consumo depotência da camada.

Os resultados apresentados indicam que o desempenho do algoritmo com-plexo (WFDVS) é praticamente igual ao do modelo heurístico mais simples(FDVS). Em particular, uma série de parâmetros de cada máquina (profiling)deve ser obtida. A Figura 1.13 mostra o comportamento dos dois algoritmospropostos em um dos experimentos do artigo, quando comparados a duas ou-tras implementações. Nessa Figura, Baseline refere-se a um sistema com to-das as UCPs de um path em sua frequência máxima (o único controle é dopróprio SO Linux, que desliga a UCP quando o sistema está idle). O sistemaindicado na figura como Independent DVS é uma implementação do algoritmoPAST em cada servidor, descrito na Seção 1.5.1, independentemente da si-tuação de QoS. Claramente, FDVS e WFDVS têm um comportamento muitopróximo e, portanto, a implementação dessa política em um cluster real pode-ria ser feita seguindo-se FDVS, pela sua simplicidade relativa.

Embora o trabalho de [Horvath et al. 2007] seja aplicável a um cluster de ncamadas, não há na literatura nenhuma arquitetura onde mais de 3 delas se-jam empregadas. Em artigo recente, [Leite et al. 2010] propõem um esquemapara tratar esse último caso, também usando o conceito de path. A princi-pal característica desse trabalho é não fazer nenhuma hipótese em relaçãoàs distribuições dos tempos de serviço, nem do tempo entre chegadas dasrequisições. Para tanto, os autores utilizaram uma modelagem baseada emaproximação estocástica, que permite o cálculo, on-line, tanto de um percentilda distribuição (que é desconhecida) dos retardos ou avanços da execução dasrequisições em relação a seus prazos, quanto a estimação das frequências das

29


Figura 1.13. Consumo de potência para FDVS eWFDVS [Horvath et al. 2007]

máquinas do path que minimizam a potência instantânea consumida.Os autores usam uma modelagem do consumo de potência estático e dinâ-

mico dos computadores do path, bem como dos tempos de execução envolvi-dos, para demonstrarem que, para um dado tempo de resposta alvo, existe umaconfiguração de frequências das máquinas do path que minimiza a frequênciaconsumida. Intuitivamente, quando se aumenta a frequência de uma camada,pode-se diminuir a da outra camada. Com base nessa constatação e com ouso de aproximação estocástica para obter o mínimo da função de potênciatotal consumida (que é desconhecida), os autores propõem um esquema comdois controladores, executando em um front-end, que trabalham cooperativa-mente, um controlando consumo mínimo de potência e o outro controlando aQoS (percentil do tempo de resposta). Os resultados demonstram que o es-quema (feitos por simulação, utilizando carga sintética) consegue economizarenergia enquanto mantém o tempo de resposta fim-a-fim como requerido.

1.6.6. Leituras adicionaisOs artigos a seguir podem ser consultados por leitores que desejarem

se aprofundar no assunto: [Bianchini e Rajamony 2004, Meisner et al. 2009,Pinheiro et al. 2003].

1.7. Métodos de previsãoAlguns trabalhos têm incorporado métodos de previsão de carga ou de utili-

zação de UCP às técnicas de economia de energia [Kalyniavianaki et al. 2009,Santana et al. 2008, Santana et al. 2010]. Assim, um sistema que consiga esti-mar a evolução da carga de trabalho submetida (ou da utilização dos processa-

30

Clusters Verdes

dores) possibilita que medidas possam ser tomadas proativamente, direciona-das tanto para economia de energia (DVFS ou configuração dinâmica), quantopara manutenção da qualidade de serviço. Ou seja, uma política de economiade energia baseada nesse paradigma passará de reativa a pró-ativa.

Para prever a evolução da carga oferecida, ou da utilização dos servido-res, pode-se lançar mão de técnicas desenvolvidas para análise de sériestemporais. Dentre aquelas existentes para realizar previsão nessas sériespodem ser citadas as médias móveis, o amortecimento exponencial, as re-gressões, as redes neurais e modelos não lineares. Em [Santana et al. 2008,Santana et al. 2010] os autores usaram o Método Linear de Holt (HLM) [Makridakis et al. 1997]para prever a carga do sistema. Eles propõem o uso do previsor HLM juntocom uma heurística para economizar energia e oferecer um determinado nívelde QoS. Essa QoS é mantida com base em observações sobre uma janela detempo. Se a QoS está baixa, o algoritmo pode comandar tanto uma nova confi-guração quanto uma simples atuação no mecanismo de DVFS, dependendo dequal dessas atuações levará à situação de consumo mínimo de energia para acarga oferecida.

Para demonstrar a aplicabilidade do método, os autores compararam o mé-todo HLM com uma política padrão do Linux, o OnDemand Governor (OG), quealtera as frequências do processador baseada na carga oferecida; um clusterde 5 máquinas foi utilizado nessa comparação. Em ambos os casos, há distri-buição de carga entre os servidores do cluster de acordo com sua capacidade(i.e., opera com sistemas heterogêneos), e no caso do OG não há nenhumtipo de coordenação entre os servidores. A Figura 1.14 indica a frequênciaagregada do cluster para os dois métodos (uma forma indireta de representaro consumo total de potência no cluster ). Como OG não faz configuração di-nâmica, os períodos (aproximados) entre 0 e 3 horas, e entre 9,5 e 12 horasdevem ser desconsiderados nessa comparação. Notar que em todas as outrassituações o método HLM opera em uma frequência agregada menor que o OG.


aprofundar no assunto: [Cunha et al. 2008, Kusic et al. 2008].

1.8. VirtualizaçãoVirtualização, no contexto de clusters de servidores, é a técnica que per-

mite a criação de diversas máquinas virtuais (MV), cada uma com seus pró-prios recursos virtuais, seu próprio SO, etc., em um mesmo sistema físico. Oconceito não é novo, tendo sido empregado em mainframes na década de 60,como no IBM System/360; essas máquinas eram computacionalmente pode-rosas, mas extremamente caras. O uso dessa técnica tornou-se possível hojeem dia pelo extraordinário avanço atingido na construção de circuitos integra-dos, barateamento dos microprocessadores e também pela escalabilidade dossubsistemas de memória.

A outra razão para a sua aplicação vem da constatação que a grande mai-

31


0

4000

8000

12000

16000

0 2 4 6 8 10 12

Mhz

time (hours)

OGHLM

Figura 1.14. HLM vs. OG [Santana et al. 2010]

oria das instalações de servidores comerciais, configuradas para atender comqualidade picos de carga, permanecem subutilizadas durante um grande pe-ríodo de sua operação. Números como 20% a 30% são mencionados para autilização média desses sistemas [Elnozahy 2009, Kusic et al. 2008, Meisner et al. 2009].A consequência é óbvia: mais máquinas gastando energia desnecessaria-mente, tanto para alimentar o cluster quanto para resfriá-lo.

A virtualização oferece uma abordagem eficiente para a consolidação devários serviços em um menor número de recursos computacionais de um DataCenter [Kusic et al. 2008]. Esta tecnologia permite que um único servidor possaser compartilhado por diversas máquinas virtuais, onde cada máquina virtualpode executar um único ou diversos aplicativos. Virtualização também facilitaa migração de processos entre servidores, pois as MVs são completamentemigradas e não tão somente os processos com estados parciais. Isso permitea utilização de recursos por demanda, ou seja, UCP, memória e espaço emdisco são disponibilizados para as aplicações somente quando necessários,acabando com a alocação estática feita com base na demanda pelo pico dacarga de trabalho. Com isso, pode-se consolidar várias MVs em um único ser-vidor físico e desligar os outros servidores que estão ociosos. Através do pro-visionamento dinâmico e da consolidação da carga, diferentes níveis de QoSpodem ser contratados pelos clientes, ao mesmo tempo em que se consegueuma maior eficiência energética [Kusic et al. 2008].

Em [Kalyniavianaki et al. 2009] os autores integram um filtro de Kalmancom controladores realimentados para alocar dinamicamente capacidade de

32

Clusters Verdes

processador a máquina virtuais (MV), em um cluster de servidores de 3 cama-das. O filtro de Kalman [Welch e Bishop 2006] é um estimador ótimo (signifi-cando que ele minimiza a variância do erro estimado), quando certas hipótesessão atendidas. No artigo são propostos 3 diferentes controladores, que alocamUCP a MVs individuais (método SISO - Single Input Single Output), ou aindaque fazem a alocação com base não só na necessidade de cada MV, mas tam-bém considera a possível correlação entre componentes do sistema (métodoMIMO - Multiple Input Multiple Output). Para esse último caso também é pro-posta uma solução onde parâmetros do filtro são adaptativos (e.g., a matriz devariância do ruído do processo é não estacionária).


aprofundar no assunto: [Kalyniavianaki et al. 2009, Kusic e Kandasamy 2007,Kusic et al. 2009, Petrucci et al. 2009, Wang et al. 2008].

1.9. Controle térmicoNas seções anteriores fica claro que, desde os anos 90, pesquisadores

se preocupam com gerência de energia e potência visando economizar ener-gia. Mais recentemente, alguns trabalhos visam limitar a temperatura máxima,pois a temperatura afeta o desempenho dos sistemas e é extremamente im-portante para garantir a integridade do microprocessador. Conforme o vídeomostrado no site “Tom’s Hardware” [Hardware 2006], um processador pode seauto-destruir por excesso de temperatura, se não existir dissipação de calor enenhum mecanismo de proteção contra alta temperatura.

A maioria das pesquisas executadas na área de controle térmico tem sepreocupado com manter um alto fluxo de trabalho realizado mas limitando atemperatura máxima. Claramente, o uso de throttling (essa técnica interrompea execução do processador quando esse atinge uma temperatura limite paranão danificar o processador) é útil para limitar a temperatura, mas pode causarproblemas de desempenho. Um caso particular é o de sistemas de tempo real,pois caso o escalonador desconheça o efeito do throttling uma tarefa podeperder o prazo e afetar a QoS.

Alguns trabalhos também se preocupam com aspectos de microarquiteturado processador, projetando chips e mecanismos que regulam a temperaturado chip. Estes mecanismos tentam distribuir a carga pelas diferentes unidadesde execução visando harmonizar a temperatura nos subcomponentes da UCP,por exemplo colocando a unidade aritmética longe do banco de registradores.Um trabalho que é considerado seminal nesta área é o simulador de efeitostérmicos em nível de arquitetura incorporado ao HotStop [Huang et al. 2006].

Em nível de SO, o trabalho de [Wang e Bettati 2006] modifica um escalo-nador de tempo real, também usando DVFS, para restringir a temperatura alimites seguros. Esse escalonador usa um modelo simples baseado somentenas características térmicas da UCP. Abaixo descrevemos dois modelos maiscompletos, que tratam não só da UCP, mas também da modelagem térmica do

33


servidor e do Data Center.A gerência de temperatura de Data Centers normalmente considera o ser-

vidor como um caixa preta. Alguns pesquisadores propuseram modelos de sis-temas com respeito as suas características térmicas usando um sistema RC,e outros utilizam uma modelagem mais complexa baseada em simuladorescomerciais, que são baseados em simulações termodinâmicas (computationalfluid dynamics, ou CFD simulators) [Moore et al. 2005].

1.9.1. Mercury e FreonO pacote Mercury [Heath et al. 2006] é um software que emula as tempe-

raturas de um Data Center, baseado na planta baixa, no fluxo de ar e calorentre os componentes, no tipo de servidores (incluindo detalhes de seus com-ponentes, especialmente várias constantes que têm que servir de entrada parao emulador) e na utilização das UCPs dos servidores. Os autores demonstramque experimentos podem ser facilmente repetidos (o que não é verdade comexecuções em hardware) e que o Mercury executa relativamente rápido emum servidor dedicado. O Mercury computa a temperatura via um algoritmo deelementos finitos, mas com uma granularidade maior do que a de simuladorescomerciais. Esse cálculo é feito dividindo-se o espaço tridimensional em cubosrelativamente grandes (quando comparados com os simuladores comerciais)e simulando-se a transferência de calor entre partes do espaço. A simulaçãotambém usa interpolações das temperaturas ao invés de calcular exatamentea transferência de calor entre partículas do ambiente.

Um dos principais feitos do Mercury é que foi o primeiro pacote que de-monstrou que se pode fazer simulação desse tipo de uma forma eficiente sim-plesmente com um servidor dedicado. Para Data Centers de grande porte,dedicar um servidor para tais cálculos não é raro. O Mercury também demons-tra, com experimentos em servidores reais, que o erro de previsão é pequeno(aproximadamente 1◦C), e que as tendências (de aumento ou diminuição) dastemperaturas modeladas são sempre certas. Essa validação foi feita com sis-temas reais, já que o Mercury permite execução de aplicativos no emulador.

Os mesmos autores desenvolveram também um pacote chamado Freon,que gerencia a temperatura num cluster com um front-end que faz a distribui-ção de carga entre os servidores da segunda camada. O objetivo do Freoné gerenciar temperaturas sem desligar servidores, pois o tempo de reinicia-ção dos servidores pode afetar o desempenho dos aplicativos e, consequen-temente, afetar a QoS requerida do sistema. Uma extensão do Freon é umapolítica de conservação de energia baseada na temperatura; essa combinaçãosimultânea de gerenciamento térmico e energético faz com que (mesmo quenão seja a política do Freon) alguns servidores sejam desligados para minimi-zar energia, quando a QoS não vai ser degradada substancialmente.

1.9.2. O modelo RCEm [Ferreira et al. 2007] foi apresentado um modelo para descrever uma

estrutura térmica hierárquica da UCP, do servidor e dos Data Centers, visando

34

Clusters Verdes

Figura 1.15. Um exemplo do modelo térmico RC

o cálculo eficiente da temperatura. O modelo pode ser usado para prever ocomportamento da temperatura de cada elemento baseado no conhecimentoda temperatura atual e da carga aplicada. O modelo incorpora não somenteos elementos que geram calor, mas também os dispositivos que removem ocalor do sistema (dissipadores, ventiladores, etc.) e o comportamento desseselementos quando uma falha ocorre (for exemplo, um ventilador quebrado).

O modelo RC térmico é derivado de um simples modelo RC elétrico, ondeR e C são a resistência e a capacitância, descritas a seguir. A resistência tér-mica é a diferença de temperatura necessária para transferir um certo fluxo decalor. As propriedades físicas dos materiais que compõem os elementos dosistema e o formato, área de superfície e volume determinam o valor da re-sistência térmica. A capacitância térmica mede a quantidade de calor que éarmazenada ou removida para aumentar ou diminuir a temperatura de um ele-mento (lembrar que um capacitor acumula energia). A capacitância dependeda composição química e da massa do elemento. Por exemplo, um dissipadoracoplado a uma UCP normalmente apresenta um capacitância elevada porquepossui um massa elevada e o material usado tem uma razoável capacidade dearmazenamento de calor (alumínio ou cobre).

A Figura 1.15 mostra um exemplo simplificado das características térmicasde uma UCP, do interior e do exterior (ambiente) de um servidor. Na figura umnó é uma interseção entre linhas e representa um componente ou um conjuntode componentes (TCPU ,TBOX ,TOUT SIDE ). Com esse modelo é possível computara temperatura de cada componente, conhecendo a temperatura atual e a cargaaplicada, pois normalmente há uma relação linear entre a carga executada pelosistema e a potência dissipada (que é diretamente proporcional à temperatura).

Para ilustrar o efeito dos valores de R e C, considere o modelo da Fi-gura 1.15 com dois valores de capacitância do servidor (2J/C e 20J/C), mascom as mesmas temperaturas iniciais (UCP a 50◦C e servidor a 20◦C). Comose pode ver na Figura 1.16, uma maior capacitância exige maior quantidade de

35


0

50

100

150

200

250

0 100 200 300 400 500 600 700 800 900 1000

Tem

pera

tura

(C)

Tempo(s)

UCP

Servidor

0

50

100

150

200

250

0 100 200 300 400 500 600 700 800 900 1000

Tem

pera

tura

(C)

Tempo(s)

UCP

Servidor

Figura 1.16. Temperaturas da UCP e gabinete para C =2J/C (esquerda) e C = 20J/C (direita)

calor para aumentar a temperatura, reduz a taxa de aumento de temperaturae, consequentemente, leva mais tempo (1000s) para atingir a temperatura má-xima. Quando a capacitância é menor, em 100s atinge-se a temperatura má-xima. Conforme esperado, a temperatura máxima atingida é a mesma. Noteque a diferença entra a temperatura do servidor e da UCP é constante depoisde 100 segundos, mesmo que a temperatura do servidor esteja variando. Istomostra que a capacitância térmica da UCP tem pouco impacto na temperaturada UCP, mas a capacitância do servidor produz um profundo impacto.

1.9.2.1. Modelo térmico composto

Baseado no modelo mostrado para um componente, pode-se facilmenteconstruir um modelo de um servidor que utiliza modelos da UCP, discos, e ou-tros elementos. A Figura 1.17 mostra um modelo simplificado, porém preciso,onde a potência dissipada pela UCP não é constante, mas varia de 10,53W a46W, conforme medições reais. O modelo do servidor representa o ar existenteno servidor e a estrutura de metal que o compõe. A placa de vídeo e a placamãe são representadas pelo gerador de calor de 12,63W. A fonte de alimenta-ção tem uma eficiência de 70%, sendo modelada como um consumo estáticode 22W, e uma parte variável que é proporcional a potência consumida pelosoutros elementos, 0,154xPconsumed . Note que a fonte de alimentação é posicio-nada fora do servidor por possuir uma entrada separada de ar e um ventiladorpróprio, e não utiliza o ar existente dentro do servidor.

A validação desse modelo foi feita com medições reais usando sensores detemperatura (termômetros) disponibilizados pela lm-sensors e pela UCP AMD.O servidor utilizado possui também termômetro interno que apresentava a tem-peratura em um LCD externo. Esse modelo térmico prevê que a temperaturavarie exponencialmente; verificou-se que uma curva exponencial (especifica-mente (δT (1− e0,01t)+ T0) se ajusta com bastante acuidade aos valores medi-dos. Mediante esses valores, os erros encontrados foram todos menores que2◦C. Note que uma variação de 2◦C é razoável quando se considera que a tem-

36

Clusters Verdes

Figura 1.17. Modelo térmico para um servidor

peratura de um processador é pelo menos 20 vezes maior que esse erro. Emcomparação, o pacote Mercury/Freon tem uma maior acuidade, mas necessitaum servidor dedicado e muito mais informações para fazer as previsões.

1.9.2.2. Modelo de falhas térmicas

Uma parte importante do trabalho em [Ferreira et al. 2007] é o tratamentodo efeito de falhas em sistemas de dissipação de calor na temperatura doscomponentes. Normalmente presume-se que essas ocorrem externamente aomodelo e, no caso de ventiladores, são detetadas diretamente pela medida davelocidade de rotação. Contudo, nem sempre é possível a deteção desse tipode falhas.

Quando foram introduzidas falhas no ventilador, dois parâmetros foram mu-dados no modelo térmico: (a) a resistência térmica do dissipador aumentou devalor 4,7 vezes, o que significa que, quando há falhas de ventilador, é apro-ximadamente cinco vezes mais difícil dissipar o calor gerado pela UCP; e, (b)a resistência térmica do servidor dobrou de valor, um fator menor que do dis-

37


sipador, devido ao volume de ar e da estrutura metálica do servidor. Essasmudanças são intuitivas porque os ventiladores aumentam a eficiência dos dis-sipadores e a falha dos mesmos reduz a eficiência, aumentando a resistênciatérmica.

Para tratar de falhas nos componentes de dissipação, o modelo foi modi-ficado acrescentando-se duas chaves, representando a falha dos ventiladoresdo processador e do servidor (ver Figura 1.17). Como o valor da resistência au-menta quando a falha ocorre, a chave aberta apresenta uma resistência maiselevada, o que causa maior geração de calor, modelando adequadamente essafalha.

1.9.3. Leituras adicionais

Os artigos a seguir podem ser consultados por leitores que desejarem seaprofundar no assunto: [Chen et al. 2009, Meisner et al. 2009, Patterson 2008,Sharma et al. 2005].

1.10. Conclusões

Neste Capítulo discutimos vários aspectos da construção de Data Centerspara acomodar clusters “verdes” de servidores, principalmente aqueles quetêm um contrato para execução das tarefas requisitadas em prazos determi-nados pelos usuários. Adicionalmente, discutimos aspectos introdutórios detempo real, de gerenciamento de energia em servidores, da interface usadapara tal gerenciamento, gerenciamento de energia em clusters de servidores(homogêneos e heterogêneos), bem como diversas formas de controle de taisclusters e de máquinas virtuais. Apresentamos também aspectos de refrigera-ção e elementos constituintes de um Data Center, como os pisos elevados eequipamentos de ar condicionado, até a modelagem térmica dos componentesde um Data Center.

A conclusão que se chega é que as técnicas de configuração dinâmicade clusters, cujo objetivo é desligar servidores ociosos, são as mais efetivasna economia de energia, devido ao custo energético estático para manter-seservidores ligados. As diferentes políticas de DVFS também conseguem dimi-nuir os gastos de energia, porém com ganhos menores que os de configuraçãodinâmica. As técnicas de previsão de carga, para fazer previsões sobre a confi-guração dinâmica ou para serem usadas em esquemas de DVFS, têm um efeitoainda menor. As técnicas baseadas em teoria de controle podem ser utilizadasquando outras técnicas não conseguem atingir os objetivos de minimização deenergia enquanto mantêm a QoS requerida.

Apesar de ter várias vantagens quanto ao gerenciamento de processos emigração de processos em um Data Center, o efeito de virtualização ainda nãoestá bem avaliado na literatura quando se trata de aplicações com requisitosde QoS.

38

Clusters Verdes

1.11. Direções futuras para pesquisaApesar dos esforços despendidos nos últimos anos para o estudo do con-

sumo e economia de energia em clusters de servidores, vários tópicos aindaprecisam ser explorados, principalmente como teses e dissertações. Por exem-plo:

• Aprofundamento da área de economia de energia em clusters de 3 ca-madas, incluindo a camada de base de dados e/ou armazenamento deinformações em discos.

• Quantificação dos gastos e/ou economia energética com o uso da téc-nica de virtualização em clusters.

• Combinação de algoritmos de controle de refrigeração e de alocação derecursos para tarefas em Data Centers (esse projeto seria feito conjun-tamente com a área de Engenharia Mecânica).

• Estudo da aplicação das técnicas já desenvolvidas para: (i) clustersexecutando vários aplicativos concorrentemente (técnicas desenvolvidasque sejam independentes dos aplicativos); e, (ii) escalabilidade das so-luções, em termos de gargalo no front-end, aplicabilidade de algoritmosdistribuídos, e experimentos em grandes clusters reais (com 500 ou maisservidores).

• Desenvolvimento de software de teste apropriado. Os benchmarks usa-dos hoje em dia são de difícil obtenção, em função de sua natureza pro-prietária, ou são em muitos casos ultrapassados.

• Extensão das técnicas para soluções que incluam todos os subsistemas.Já há algoritmos que tratam simplesmente de outros subsistemas (e.g.,memória, rede, armazenamento, etc), mas não soluções que tratem for-malmente de todos os subsistemas de um Data Center como um todo.

• Estudar o impacto dos novos processadores, onde diferentes cores po-dem ter sua frequência de operação controlada isoladamente, por exem-plo observando a relação dessa característica com as hierarquias de ca-che e memória.

• Inclusão de outras métricas de QoS na avaliação, como por exemplo osconceitos de Disponibilidade e Segurança. Alguns trabalhos já definiramfunções de custo para escolha da configuração mais adequada em umdado instante, mas essa área ainda precisa ser melhor explorada.

• Modelar classes de clientes e oferecer QoS conforme contratos explici-tamente definidos.

Referências bibliográficas[42U 2010] 42U (2010). The data center temperature debate. http://www.42u.com/cooling/data-center-temperature.htm.

[AMD 2009] AMD (2009). AMD family 10h power and thermal data sheet.http://support.amd.com/us/Processor_TechDocs/43375.pdf.

39


[AMD 2010] AMD (2010). Cool’n’Quiet technology. http://www.amd.com/us/products/technologies/cool-n-quiet/Pages/cool-n-quiet.aspx.

[Aydin et al. 2001] Aydin, H., Alvarez, P. M., Mossé, D. e Melhem, R. (2001).Dynamic and aggressive scheduling techniques for power-aware real-timesystems. In 22nd IEEE Real-Time Systems Symposium, pp. 95–105, Lon-dres, Reino Unido.

[Aydin et al. 2004] Aydin, H., Melhem, R., Mossé, D. e Alvarez, P. M. (2004).Power-aware scheduling for periodic real-time tasks. IEEE Transactions onComputers, 53(5):584–600.

[Bertini et al. 2007] Bertini, L., Leite, J. C. B. e Mossé, D. (2007). StatisticalQoS guarantee and energy-efficiency in web server clusters. In 19th Euro-micro Conference on Real-Time Systems, pp. 83–92, Pisa, Itália.

[Bertini et al. 2009] Bertini, L., Leite, J. C. B. e Mossé, D. (2009). Generalizedtardiness quantile metric: Distributed DVS for soft real-time web clusters.In 21st Euromicro Conference on Real-Time Systems, pp. 227–236, Dublin,Irlanda.

[Bertini et al. 2010] Bertini, L., Leite, J. C. B. e Mossé, D. (2010). Optimal dyna-mic configuration in web server clusters. Journal of Systems and Software,83(4):585–598.

[Bianchini e Rajamony 2004] Bianchini, R. e Rajamony, R. (2004). Power andenergy management for server systems. IEEE Computer, 37(11):68–74.

[Burns e Wellings 2009] Burns, A. e Wellings, A. (2009). Real-Time Systemsand Programming Languages. Pearson Education.

[Cardellini et al. 2002] Cardellini, V., Casalicchio, E., Colajanni, M. e Yu, P. S.(2002). The state of the art in locally distributed web-server systems. ACMComputing Surveys, 34(2):263–311.

[Chen et al. 2009] Chen, J.-J., Wang, S. e Thiele, L. (2009). Proactive speedscheduling for real-time tasks under thermal constraints. In 15th IEEE Real-Time and Embedded Technology and Applications Symposium, pp. 141–150,San Francisco, CA, EUA.

[Chen 2010] Chen, S. (2010). Intel. http://www.cs.pitt.edu/PARTS/ShiminChen.pptx.

[CSU 2006] CSU (2006). Energy efficiency in computer data centers. Whitepaper #10, Colorado Spring Utilities.

[Cunha et al. 2008] Cunha, I., Viana, I., Palotti, J., Almeida, J. e Almeida, V.(2008). Analyzing security and energy tradeoffs in autonomic capacity ma-nagement. In IEEE/IFIP Network Operations and Management Symposium,pp. 302–309, Salvador, BA, Brasil.

[de Barros 2010] de Barros, A. (2010). Cáritas Informática: Exemplo de orga-

40

Clusters Verdes

nização de CPD. Comunicação interna.

[Ellis 1999] Ellis, C. (1999). The case for higher-level power management. In7th IEEE Workshop on Hot Topics in Operating Systems, pp. 162–167, RioRico, AZ, EUA.

[Elnozahy 2009] Elnozahy, M. (2009). Efficient data centers through virtuali-zation? Distinguished Lecturer Series, 18 de Setembro 2009, ComputerScience Department, University of Pittsburgh, EUA.

[Elnozahy et al. 2002] Elnozahy, M., Kistler, M. e Rajamony, R. (2002). Energy-efficient server clusters. In 2nd Workshop on Power Aware Computing Sys-tems, pp. 179–196, Cambridge, MA, EUA.

[EPA 2007] EPA (2007). Report to Congress on server and data center energyefficiency. U.S. Environmental Protection Agency, EUA.

[EPE 2009] EPE (2009). Balanço energético nacional: Resultados prelimina-res. Empresa de Pesquisa Energética, Ministério de Minas e Energia, Bra-sil. https://www.ben.epe.gov.br/downloads/Resultados\_Pre\_BEN\_2009.pdf.

[Ernst e Ye 1997] Ernst, R. e Ye, W. (1997). Embedded program timing analy-sis based on path clustering and architecture classification. In ICCAD ’97:Proceedings of the 1997 IEEE/ACM international conference on Computer-aided design, pp. 598–604.

[Ferreira et al. 2007] Ferreira, A., Mossé, D. e Oh, J. (2007). Thermal faults mo-deling using a RC model with an application to web farms. In 19th EuromicroConference on Real-Time Systems, pp. 113–124, Pisa, Itália.

[Forrest e Brill 2000] Forrest, W. e Brill, K. (2000). Revolutionizing data cen-ter efficiency. McKinsey & Co. Report. http://uptimeinstitute.org/content/view/168/57.

[Hardware 2006] Hardware, T. (2006). CPU cooling. http://www.youtube.com/watch?v=NxNUK3U73SI.

[Heath et al. 2006] Heath, T., Centeno, A. P., George, P., Ramos, L., Jaluria,Y. e Bianchini, R. (2006). Mercury and Freon: Temperature emulation andmanagement for server systems. In 12th International Conference on Archi-tectural Support for Programming Languages and Operating Systems, pp.106–116, San Jose, CA, EUA.

[Horvath et al. 2007] Horvath, T., Abdelzaher, T. F., Skadron, K. e Liu, X.(2007). Dynamic voltage scaling in multitier web servers with end-to-enddelay control. IEEE Transactions on Computers, 56(4):444–458.

[Hsu e Feng 2005] Hsu, C.-H. e Feng, W.-C. (2005). A power-aware run-timesystem for high-performance computing. In ACM/IEEE Conference on Su-percomputing, pp. 1–9, Seattle, WA, EUA.

[Huang et al. 2006] Huang, W., Ghosh, S., Velusamy, S., Sankaranarayanan,

41


K., Skadron, K. e Stan, M. R. (2006). Hotspot: A compact thermal modelingmethod for CMOS VLSI systems. IEEE Transactions on, 14:501–513.

[Hydeman 2006] Hydeman, M. (2006). HVAC and control system design forimproved energy performance in data centers. Apresentação na EPA Confe-rence on Data Centers - Dia 2, Fevereiro.

[IBM 2010] IBM (2010). Wesphere application server. http://www-01.ibm.com/software/websphere/.

[Intel 2004] Intel (2004). Enhanced Intel SpeedStep technology for theIntel Pentium M processor. ftp://download.intel.com/design/network/papers/30117401.pdf.

[Intel 2008] Intel (2008). Reducing data center cost with an air economizer.IT@Intel Brief, Intel Information Technology, Computer Manufacturing EnergyEfficiency.

[Intel 2010] Intel (2010). Intel air economizer. http://video.intel.com/?fr_story=2d6e0fbbef76b72c6119cc7fe7889bba20cb5192&rf=bm.

[Ishihara e Yasuura 1998] Ishihara, T. e Yasuura, H. (1998). Voltage schedulingproblem for dynamically variable voltage processors. In International Sympo-sium on Low Power Electronics and Design, pp. 197–202, Monterey, CA,EUA.

[Itaipu 2009] Itaipu (2009). Geração atualizada. Página da Itaipu Binacional.http://www.itaipu.gov.br/.

[Kalyniavianaki et al. 2009] Kalyniavianaki, E., Charalambous, T. e Hand, S.(2009). Self-adaptive and self-configured CPU resource provisioning for vir-tualized servers using Kalman filters. In 6th IEEE International Conferenceon Autonomic Computing, pp. 117–126, Barcelona, Espanha.

[Kim et al. 1999] Kim, W., Shin, D., Yun, H., Kim, J. e Min, S. (1999). Perfor-mance comparison of dynamic voltage scaling algorithms for hard real-timesystems. In 8th IEEE Real-Time and Embedded Technology and Applicati-ons, pp. 219–228, San Jose, CA, EUA.

[Kushner e Yin 2003] Kushner, H. e Yin, G. (2003). Stochastic Approximationand Recursive Algorithms and Applications. Springer.

[Kusic e Kandasamy 2007] Kusic, D. e Kandasamy, N. (2007). Risk-aware limi-ted lookahead control for dynamic resource provisioning in enterprise com-puting systems. Cluster Computing, 10(7):395–408.

[Kusic et al. 2008] Kusic, D., Kephart, J. O., Hanson, J. E., Kandasamy, N. eJiang, G. (2008). Power and performance management of virtualized com-puting environments via lookahead control. In 5th IEEE International Confe-rence on Autonomic Computing, pp. 3–12, Chicago, IL, EUA.

[Kusic et al. 2009] Kusic, D., Kephart, J. O., Hanson, J. E., Kandasamy, N. e

42

Clusters Verdes

Jiang, G. (2009). Power and performance management of virtualized com-puting environments via lookahead control. Cluster Computing, 12(1):1–15.

[LBNL 2010] LBNL (2010). The Internet traffic archive. Lawrence BerkeleyNational Laboratory, EUA, http://ita.ee.lbl.gov.

[Leite et al. 2010] Leite, J. C. B., Mossé, D., Kusic, D. e Bertini, L. (2010). Sto-chastic approximation control of power and tardiness in a three-tier web-hosting cluster. In 7th IEEE International Conference on Autonomic Com-puting, Washington, DC, EUA.

[Liebert 2007] Liebert (2007). Liebert Hiross HPM - 4-99 kw indoor room coo-ling units. Product documentation.

[Liu e Layland 1973] Liu, C. L. e Layland, J. W. (1973). Scheduling algorithmsfor multiprogramming in a hard real-time environment. Journal of the ACM,20(1):46–61.

[Lorch e Smith 2004] Lorch, J. e Smith, A. (2004). PACE: A new approach todynamic voltage scaling. IEEE Transactions on Computers, 53(7):856–869.

[Makridakis et al. 1997] Makridakis, S. G., Wheelwright, S. C. e Hyndman, R. J.(1997). Forecasting: Methods and Applications. Wiley.

[McBrayne e Lanyon-Hogg 2007] McBrayne, C. e Lanyon-Hogg, R. (2007).“Green” IT - The next burning issue for business. IBM Global TechnologyServices, Reino Unido.

[Meisner et al. 2009] Meisner, D., Gold, B. e Wenisch, T. (2009). PowerNap:Eliminating server idle power. In 14th International Conference on Archi-tectural Support for Programming Languages and Operating Systems, pp.205–216, Washington, DC, EUA.

[Moore et al. 2005] Moore, J., Chase, J., Ranganathan, P. e Sharma, R. (2005).Making scheduling “Cool”: Temperature-aware workload placement in datacenters. In Usenix Annual Technical Conference, Anaheim, CA, EUA.

[Mosberger e Jin 1998] Mosberger, D. e Jin, T. (1998). httperf: A tool for me-asuring web server performance. In Workshop on Internet Server Perfor-mance, pp. 59–67, Madison, WI, EUA.

[Mossé et al. 2000] Mossé, D., Aydin, H., Childers, B. e Melhem, R. (2000).Compiler-assisted dynamic power-aware scheduling for real-time applicati-ons. In Workshop on Compiler and OS for Low Power, Filadélfia, PA, EUA.

[Novelli et al. 2005] Novelli, B. A., Leite, J. C. B., Urriza, J. M. e Orozco, J.(2005). Regulagem dinâmica de voltagem em sistemas de tempo real. InXXXII Seminário Integrado de Software e Hardware - SBC, pp. 1772–1786,São Leopoldo, RS, Brasil.

[OW2 Consortium 2010] OW2 Consortium (2010). RUBIS: Rice University Bid-ding System. http://rubis.ow2.org/.

[Patterson 2008] Patterson, M. (2008). The effect of data center temperature

43


on energy efficiency. In 11th Intersociety Conference on Thermal and Ther-momechanical Phenomena in Electronic Systems, pp. 1167–1174, Orlando,FL, EUA.

[Petrucci et al. 2009] Petrucci, V., Loques, O. e Mossé, D. (2009). Dynamicconfiguration support for power-aware virtualized server clusters. In 21st Eu-romicro Conference on Real-Time Systems, WiP Session, pp. 33–36, Dublin,Irlanda.

[Pillai e Shin 2001] Pillai, P. e Shin, K. G. (2001). Real-time dynamic voltagescaling for low-power embedded operating systems. In 18th Symposium onOperating Systems Principles, pp. 89–102, Banff, Alberta, Canadá.

[Pinheiro et al. 2001] Pinheiro, E., Bianchini, R., Carrera, E. V. e Heath, T.(2001). Load balancing and unbalancing for power and performance incluster-based systems. In Workshop on Compilers and Operating Systemsfor Low Power, pp. 4–1 – 4–8, Barcelona, Espanha.

[Pinheiro et al. 2003] Pinheiro, E., Bianchini, R., Carrera, E. V. e Heath, T.(2003). Dynamic cluster reconfiguration for power and performance. In Com-pilers and Operating Systems for Low Power. Kluwer Academic Publishers.

[Rasmussen 2008] Rasmussen, N. (2008). Electrical efficiency measurementfor data centers. White paper #154, APC.

[Robbins e Monro 1951] Robbins, H. e Monro, S. (1951). A stochastic approxi-mation method. The Annnals of Mathematical Statistics, 22(3):400–407.

[Rusu et al. 2006] Rusu, C., Ferreira, A., Scordino, C., Watson, A., Melhem, R.e Mossé, D. (2006). Energy-efficient real-time heterogeneous server clus-ters. In 12th IEEE Real-Time and Embedded Technology and ApplicationsSymposium, pp. 418–428, San Jose, CA, EUA.

[Rusu et al. 2004] Rusu, C., Xu, R., Melhem, R. e Mosse, D. (2004). Energy-efficient policies for request-driven soft real-time systems. In ECRTS ’04:Proceedings of the 16th Euromicro Conference on Real-Time Systems, pp.175–183.

[Samson 2008] Samson, T. (2008). Intel pushes the limits of free coolingto 90 degrees. InfoWorld, http://www.infoworld.com/d/green-it/intel-pushes-limits-free-cooling-90-degrees-852.

[Santana et al. 2010] Santana, C. H., , Leite, J. C. B. e Mossé, D. (2010). Loadforecasting applied to soft real-time web clusters. In 25th ACM Symposiumon Applied Computing, Sierre, Suíça.

[Santana et al. 2008] Santana, C. H., Bertini, L., Leite, J. C. B. e Mossé, D.(2008). Applying forecasting to interval based DVS. In 10th BrazillianWorkshop on Real-Time and Embedded Systems, pp. 1–8, Rio de Janeiro,RJ, Brasil.

[Sharma et al. 2005] Sharma, R., Bash, C., Patel, C., Friedrich, R. e Chase, J.

44

Clusters Verdes

(2005). Balance of power: Dynamic thermal management for internet datacenters. IEEE Internet Computing, 9(1):42–49.

[TPPC 2010] TPPC (2010). Transaction Processing Performance Council.http://www.tpc.org/.

[Wang e Bettati 2006] Wang, S. e Bettati, R. (2006). Delay analysis intemperature-constrained hard real-time systems with general task arrivals.In 27th IEEE Real-Time Systems Symposium, pp. 323–334, Rio de Janeiro,RJ, Brasil.

[Wang et al. 2008] Wang, Y., Wang, X., Chen, M. e Zhu, X. (2008). Power-efficient response time guarantees for virtualized enterprise servers. In 29thIEEE Real-Time Systems Symposium, pp. 303–312, Barcelona, Espanha.

[Weiser et al. 1994] Weiser, M., Welch, B., Demers, A. e Shenker, S. (1994).Scheduling for reduced CPU energy. In 1st Symposium on Operating Sys-tems Design and Implementation, pp. 13–23, Monterey, CA, EUA.

[Welch e Bishop 2006] Welch, G. e Bishop, G. (2006). An introduction to theKalman filter. Relatório técnico TR 95-041, Department of Computer Sci-ence, University of North Carolina at Chapel Hill, EUA.

[Xu et al. 2004] Xu, R., Xi, C., Melhem, R. e Mossé, D. (2004). Practical PACEfor embedded systems. In 4th ACM International Conference on EmbeddedSoftware, pp. 54–63, Pisa, Itália.

[Yuan e Nahrstedt 2003] Yuan, W. e Nahrstedt, K. (2003). Energy-efficient softreal-time CPU scheduling for mobile multimedia systems. In 19th ACM Sym-posium on Operating Systems Principles, pp. 149–163, Bolton Landing, NY,EUA.

[Zhu et al. 2004] Zhu, D., Mossé, D. e Melhem, R. (2004). The effects of energymanagement on reliability in real-time embedded systems. In InternationalConference on Computer Aidded Design, pp. 35–40, San Jose, CA, EUA.

45

Introdução aos Clusters Verdes de Servidores - ic.uff.brjulius/stre/CapClustersVerdes.pdf · As...

Documents

Transcript of Introdução aos Clusters Verdes de Servidores - ic.uff.brjulius/stre/CapClustersVerdes.pdf · As...