Captulo

1
Grandes Massas de Dados na Nuvem:
Desaos e T ecnicas para Inovac ao
Lus Henrique M. K. Costa
1
, Marcelo D. de Amorim
2
,
Miguel Elias M. Campista
1
, Marcelo G. Rubinstein
3
,
Patricia Florissi
4
e Otto Carlos M. B. Duarte
1
1
GTA/PEE-COPPE/DEL-Poli - Universidade Federal do Rio de Janeiro - RJ, Brasil
2
LIP6/CNRS - Universit e Pierre et Marie Curie - Paris, Franca
3
PEL/DETEL/FEN - Universidade do Estado do Rio de Janeiro - RJ, Brasil
4
EMC Nova Iorque, Estados Unidos
Resumo
A era das grandes massas de dados j a iniciou. Usu arios s ao agora fontes de
dados; empresas armazenam incont aveis informac oes de clientes; milh oes de sensores
monitoram o mundo real, criando e trocando dados na Internet das coisas. As arquite-
turas em nuvem obrigam indivduos e organizac oes a lidarem com um verdadeiro dil uvio
de dados que exp oem as limitac oes das soluc oes tradicionais de armazenamento, geren-
ciamento, an alise e transfer encia. Este minicurso foca o impacto das grandes massas de
dados nas redes de computadores em centros de dados e na Internet. S ao identicadas as
raz oes das transfer encias das grandes massas de dados serem um desao e quais as de-
ci encias das atuais tecnologias empregadas. S ao apresentadas as principais propostas
e iniciativas da area.
Abstract
We are living today the dawn of big data era. Users have become data sources;
companies store uncountable information from clients; millions of sensors monitor the
real world; create and exchange data in the Internet of things. Cloud architectures enable
individuals and organizations to cope with a true deluge of data, which expose the limits
of traditional solutions for storage, management, analysis, and transference. This short
course focuses on the impact of big data on computer networks in datacenters and also
on the Internet. We identify the reasons why big data is an issue and what the weaknesses
of the legacy Internet are and we visit the main proposals and initiatives in this area.
Este trabalho utilizou recursos da CAPES, CNPq, FAPERJ, FUJB, FUNTTEL, FINEP e CNRS.
1.1. Introduc ao
A quantidade de dados produzidos e armazenados no mundo tem aumentado de ma-
neira vertiginosa e j a n ao se mede mais em giga ou terabytes, mas em peta, exa e at e
zetabytes
1
. Um recente estudo da International Data Corporation (IDC) junto com a
EMC em junho de 2011 indica que a quantidade de dados na Internet j a ultrapassou
a marca de 2 zettabytes em 2010 e a previs ao e que esse valor chegue a 8 zettabytes
em 2015 [Gantz e Reinsel, 2010, Gantz e Reinsel, 2011]. Esse n umeros representam um
aumento de mais de 300% em apenas cinco anos (Figura 1.1). Como consequ encia,
estima-se que soluc oes existentes envolvendo manipulac ao de dados como armazena-
mento, visualizac ao e transmiss ao n ao tenham propriedades sucientemente resistentes
para suportar t ao fortes requisitos de escalabilidade.
V arias s ao as raz oes que justicam tal crescimento na quantidade de dados mani-
pulados no mundo. Usu arios est ao permanentemente interconectados ` a Internet, criando
bilh oes de conex oes e se transformando em fontes de dados; empresas armazenam um
sem n umero de informac oes de seus clientes, de seus fornecedores e de suas operac oes co-
merciais; milh oes de sensores monitoram o mundo real; celulares, medidores eletr onicos
de energia, dispositivos port ateis, e autom oveis sensoriam, criam e trocam dados remo-
tamente na Internet das coisas. A inovac ao, a competic ao e a produtividade em todos os
setores da economia dependem agora da captura, da transfer encia, da agregac ao, da arma-
zenagem e da an alise de grandes massas de dados (big data). Os servidores do Facebook,
por exemplo, estocam aproximadamente 40 bilh oes de fotos dos seus usu arios, o que j a
signicaria petabytes de volume de dados armazenados assumindo-se fotos de apenas al-
gumas dezenas de kbytes [The Economist, 2010]. Experimentos de fsica de partculas
realizados no CERN (Centre Europ een de Recherche Nucl eaire) podem gerar at e 40 te-
rabytes de dados a cada segundo. Valores quase t ao grandes s ao tamb em encontrados
em aplicac oes comerciais, como no caso da rede Walmart, onde milhares de usu arios s ao
tratados a cada hora, gerando cerca de 2,5 petabytes de dados a serem inseridos nos cen-
tros de dados (datacenters) da empresa [The Economist, 2010]. V arios outros exemplos
podem ser citados.
Uma observac ao importante e com relac ao ` a velocidade na qual os dados po-
dem ser processados, em oposic ao ` a velocidade de gerac ao de dados. Por exemplo, a
decodicac ao do genoma humano exigiu cerca de dez anos de c alculos antes dos pri-
meiros resultados divulgados em 2003; a mesma operac ao exige aproximadamente uma
semana com as possibilidades atuais. Os dados gerados, por outro lado, ainda ultrapassam
signicativamente as capacidades de armazenamento das estruturas de base envolvidas no
procedimento. Desta forma, se torna imprescindvel a concepc ao de novos procedimentos
para o tratamento desses dados. Inclusive, n ao e descartada a possibilidade de que novas
observac oes sejam feitas com relac ao aos mesmos dados, procedimentos anteriormente
considerados invi aveis por causa de limitac oes na infraestrutura.
Uma das principais caractersticas dos sistemas que lidam diretamente com gran-
des massas de dados e o fato de se basearem sobre arquiteturas do tipo nuvem compu-
1
Zetta (smbolo Z), peta (smbolo P) e exa (smbolo E) s ao prexos que denotam os fatores 10
21
, 10
18
e
10
15
, respectivamente. Esses prexos v em do Latim e signicam sete (1000
7
), seis (1000
6
) e cinco (1000
5
),
respectivamente.
2005 2010 2015
0
2000
4000
6000
8000
A
r
m
a
z
e
n
a
m
e
n
t
o
(
e
m
e
x
a
b
y
t
e
s
)
Fonte: IDCs Digital Universe Study, patrocinado pela EMC, Junho de 2011
Figura 1.1. Aumento dos dados armazenados estimados pela IDC [Gantz e Reinsel, 2011].
tacional (cloud computing). Atributos das arquiteturas em nuvem como escalabilidade,
baixo custo, agilidade e elasticidade permitem de fato n ao somente a criac ao de enormes
massas de dados como o tratamento desses dados. Um ciclo e formado, pois quanto mais
dados s ao introduzidos na nuvem, novos desaos surgem e soluc oes inovadoras s ao ne-
cess arias. Cada vez mais grandes massas de dados (big data) e nuvem computacional
(cloud) se associam atr as de um mesmo conceito. Alguns analistas prev eem que por volta
de 2020 a maior parte dos dados digitais no mundo ser ao manuseados, monitorados e/ou
armazenados em nuvens se n ao durante todo o ciclo de vida, pelo menos em parte.
A implementac ao de nuvens e intimamente relacionada ` a noc ao de centros de
dados, que podem ser denidos como aglomerac oes de computadores interconectados
que prov eem, de maneira eciente, hospedagem e manipulac ao de dados. Aplicac oes de
enorme sucesso da Internet (como o Yahoo, Amazon e Facebook) utilizam centros de
dados distribudos onde dados s ao replicados de forma a diminuir o tempo de resposta
e melhorar a satisfac ao do usu ario. Esse cen ario ser a ainda mais importante em um fu-
turo pr oximo, visto que as principais empresas consumidoras de recursos j a anunciaram
seus planos de expans ao para seus centros de dados. A Figura 1.2 ilustra a previs ao do
crescimento dos dados armazenados para os pr oximos anos.
Al em da preocupac ao com os servicos de armazenamento e de manipulac ao de
dados, outro desao de grande import ancia e relativo ` a transmiss ao das informac oes en-
tre pontos distantes na Internet. O desempenho dos protocolos de comunicac ao con-
vencionais nem sempre e satisfat orio para muitas aplicac oes tpicas de centros de da-
dos (por exemplo, a computac ao paralela). Adicionalmente, a manipulac ao de massas
de dados envolve um custo energ etico e nanceiro crescente. Onde armazenar, quando
transmitir, como movimentar os dados, tornam-se quest oes primordiais tanto do ponto
de vista ecol ogico quanto econ omico. Novos protocolos de comunicac ao e t ecnicas de
virtualizac ao [Fernandes et al., 2011] s ao pecas-chave para o suporte de grandes massas
de dados na Internet, al em de novas estrat egias nas areas de economia de energia, bancos
de dados, minerac ao de dados, computac ao paralela e visualizac ao de dados.
Um recente estudo levando em conta 106 operadores de centros de dados revelou
que 77% deles replicam seus dados em tr es ou mais c opias [Forrester Research, 2010].
Microsoft
Dublin, Irlanda
$500 milhoes
19 acres
Google
Dublin, Irlanda
$101 milhoes
11 acres
Microsoft
Virginia, EUA
$150 milhoes
Microsoft
Iowa, EUA
$200 milhoes
Google
Oklahoma, EUA
$600 milhoes
130,000 pes
2
IBM
Langfang, China
620,000 pes
2
Facebook
NC, EUA
$450 milhoes
300,000 pes
2
Google
Singapura
Google
Hong
Kong
Google
Taiwan
Fonte: OnlineTech, Outubro de 2011
Figura 1.2. Planos de expans ao de centros de dados em 2012 [(Online Tech), 2011].
Al em disso, mais de 50% deles anunciaram que a quantidade de dados armazenadas
nos seus centros de dados ultrapassa a marca de um petabyte e que a banda passante
necess aria para interconectar esses centros de dados de maneira satisfat oria dobrar a ou
triplicar a nos pr oximos quatro anos [Forrester Research, 2010]. De uma maneira mais
geral, sabendo-se que o tr afego IP dever a alcancar mais de um zetabyte antes do m de
2015 [Cisco, 2011], soluc oes ecientes para a transfer encia de grandes quantidades de
dados em modo bulk ser ao mais do que necess arias.
Neste minicurso, s ao estudadas as principais aplicac oes que geramgrandes massas
de dados, e quais as implicac oes dessas massas.

E dado foco ao problema da migrac ao
dos dados j a que envolvem redes de comunicac ao. Em especial, s ao apresentados de-
saos de interconex ao de milhares de computadores em centros de dados e desaos de
interconex ao de centros de dados, que demonstram as diferencas do ambiente interno a
um centro de dados (intra datacenter) com a Internet e os desaos de se migrar massas
de dados entre centros de dados (inter datacenters). Em cada um desses ambientes, di-
ferentes tecnologias podem ser utilizadas para aumentar o desempenho como o uso da
virtualizac ao de redes combinada a novas tecnologias de denic ao de redes por software
(Software Dened Networking SDN) [Lantz et al., 2010]. Todas essas quest oes justi-
cam a import ancia que vem sendo dada a essa area de pesquisa no meio industrial e
acad emico.
1.2. Grandes Massas de Dados
Inicialmente, esta sec ao busca denir o qu ao grande devem ser os dados para serem de-
nominados grandes massas de dados (big data) e quais s ao as suas fontes de gerac ao.
A melhor denic ao para grandes massas de dados n ao indica, intencionalmente, um ta-
manho exato.

E prefervel a denic ao relativa como um volume de dados que excede
a capacidade de gerenciamento das ferramentas usadas para lidar com tamanhos tpicos
de uma determinada aplicac ao ou area. Essa denic ao e mais adequada porque as tec-
nologias utilizadas para gerenciar as grandes massas de dados evoluem e o valor limite
aumenta ano a ano. Al em disso, a denic ao pode depender dos softwares frequente-
mente utilizados e dos tamanhos tpicos dos dados usados em uma determinada area de
produc ao. Portanto, vislumbra-se que tal denic ao exata n ao possa ser concluda de ma-
neira denitiva em curto-prazo e que ela n ao surja enquanto a escalabilidade n ao for uma
caracterstica permanente da maioria dos sistemas computacionais.
Como mencionado, a denic ao do que seriam as grandes massas de dados de-
pende do setor de produc ao relacionado. Nesse sentido, nota-se que as fontes de dados
s ao in umeras e est ao ligadas aos diferentes segmentos da sociedade. Um dos principais
motores do aumento da quantidade de dados e a digitalizac ao dos sistemas que impul-
siona ainda mais a gerac ao dessas massas. Com a crescente quantidade de dados gerados,
manipulados, transferidos e armazenados, novos problemas surgem envolvendo muitas
areas interdisciplinares como banco de dados, minerac ao de dados, arquitetura de compu-
tadores, sistemas digitais, provis ao de energia e tecnologias de baixo consumo energ etico
(tecnologias verdes), recuperac ao da informac ao e redes de computadores.
1.2.1. Aplicac oes e valores tpicos de grandes massas de dados
O tamanho das massas de dados para que sejam consideradas realmente grandes n ao e
facilmente denido. Apesar de sua complexidade, o termo vem sendo utilizado mesmo
que leve a ambiguidades. Um conceito equivocado, entretanto, e que as grandes massas
de dados referem-se somente ao tamanho absoluto desses dados. Apesar de o tamanho ser
certamente um elemento a ser considerado na denic ao, h a outros aspectos ou proprieda-
des das grandes massas de dados, n ao diretamente associados ao tamanho, que devem ser
tamb em levados em considerac ao. A velocidade na qual as grandes massas de dados s ao
geradas, assim como o n umero e a variedade de fontes que geram dados simultaneamente
devem ser considerados. Observando em detalhes cada uma das fontes, verica-se como
a classicac ao e dependente do prop osito dos dados e do setor de produc ao no qual eles
est ao inseridos. Dessa forma, uma apresentac ao de 40 megabytes, uma imagem m edica
de 1 terabyte ou um lme de 1 petabyte podem ser igualmente considerados grandes mas-
sas de dados mesmo tendo tamanhos t ao diferentes. Para isso, basta vericar que cada um
desses arquivos extrapola os limites disponveis das tecnologias comumente utilizadas por
cada uma deles. Os argumentos abaixo reforcam esse conceito:
uma apresentac ao de 40 megabytes representa uma grande massa de dados se n ao
for possvel envi a-la por correio eletr onico a um colega ou cliente;
uma imagem m edica de 1 terabyte representa uma grande massa de dados se n ao
for possvel exibi-la de forma simples e acurada em uma tela remota em tempo real
durante uma consulta m edica com um paciente;
um lme de 1 petabyte representa uma grande massa de dados se n ao for possvel
edit a-lo dentro dos limites plausveis de tempo estabelecidos pelo neg ocio corrente.
Logo, conclui-se que o tamanho n ao e a unica propriedade que deve ser considerada ao
classicar o qu ao grande s ao as massas de dados. Uma denic ao mais abrangente para
classicar as grandes massas de dados deve considerar tamb em se os limites m aximos
disponveis para o uso desses dados foram alcancados ou n ao.
Os argumentos apresentados t em como objetivo negar o conceito comum no qual
se dene as grandes massas de dados tendo somente o tamanho como base. Tal denic ao
deve englobar outros atributos que atingem os limites da capacidade do sistema utilizado.
Outros atributos que aumentam a abrang encia da denic ao s ao a velocidade na qual os
dados s ao gerados e o n umero e a variedade de fontes geradoras. Ambos contribuem
para uma denic ao mais ampla do que seriam as grandes massas de dados. Tal denic ao
e, ent ao, baseada em volume, j a que e possvel imaginar que as massas de dados s ao
geradas a partir do produto entre n umero de fontes e quantidade de bytes. Mesmo quando
criado em pequenos fragmentos, o composto agregado pode se tornar uma grande massa
de dados correlacionados. Esse composto dene, ent ao, um grande volume de dados.
Por exemplo, tais volumes podem ser vistos no contexto de medidores inteligentes de
energia que s ao empregados em resid encias ao redor do mundo. Esses medidores podem
enviar ` as companhias el etricas a energia gerada e consumida em uma casa a cada 10 ou
15 minutos. O produto da quantidade de dados gerados individualmente pelo n umero de
resid encias em um vilarejo ou em uma pequena cidade gera um volume de dados enorme.
Tais dados devem ser analisados dentro de um dado intervalo de tempo ou dentro de uma
determinada fronteira geogr aca.
Outro aspecto a ser ressaltado das grandes massas de dados e que elas se dife-
renciam tamb em sob o ponto de vista estrutural. Algumas massas de dados t em o seu
formato bem denido, como requisic oes a um banco de dados, nas quais cada entrada
pode ser dividida em campos, cada um armazenando dados de um tipo pr e-estabelecido
e j a bem denido. Por outro lado, algumas grandes massas de dados podem ser somente
uma colec ao de entradas de blogs que contenham texto, tabelas, imagens, voz e vdeo
armazenados em um mesmo reposit orio de dados. As caractersticas desses dados le-
vam a outros aspectos das grandes massas de dados que s ao a diversidade de gerac ao e a
correlac ao entre os dados. Apesar do tamanho, velocidade ou fonte dos dados serem di-
ferentes, as grandes massas de dados impulsionam a necessidade de se extrair sentido do
aparente caos. Para tal, e necess ario encontrar signicado dos dados que est ao em cons-
tante evoluc ao, al em de encontrar as relac oes entre eles. A compreens ao dessa correlac ao
e da possibilidade de obter informac oes preciosas, muitas vezes escondidas nas grandes
massas de dados, ajuda a revelar o valor do esforco. Assim sendo, coletar, analisar e
compreender as grandes massas de dados (Sec ao 1.2.2) est a se tornando atualmente uma
estrat egia diferenciada e vislumbra-se que ela ainda se tornar a fundamental em um futuro
pr oximo. O local onde a an alise precisa ser executada, seja em um unico centro de dados
(datacenter) ou em um centro de dados distribudo geogracamente, sem perder a con-
cis ao, acur acia e relev ancia dos resultados e um dos desaos abordados neste minicurso.
1.2.2. Ciclo de vida dos dados
Semelhantemente ao ciclo de vida biol ogico, os dados tamb em passam por est agios desde
a sua gerac ao at e o nal da sua utilidade. De maneira geral, um ciclo de vida pode ser
classicado em quatro est agios: nascimento, crescimento, reproduc ao e morte. Por ana-
logia, como ilustrado na Figura 1.3, pode-se pensar em um ciclo de vida similar para os
dados, no qual a gerac ao dos dados substitui o nascimento; a agregac ao dos dados substi-
geracao
analise
agregacao apagamento
Figura 1.3. Ciclo de vida dos dados e os seus respectivos est agios.
tui o crescimento; a an alise dos dados substitui a reproduc ao; e, nalmente, o apagamento
dos dados substitui a morte. Percebe-se que durante o est agio de agregac ao, mais dados
com sem antica semelhante, ou mesmo dados que sejam de alguma forma correlaciona-
dos, s ao adicionados aos dados originais. Em ambos os casos, a agregac ao enriquece o
valor dos dados, ampliando a sua import ancia.
Durante o est agio de an alise, a combinac ao dos dados obtidos resulta em novos
dados com melhor e mais acurado signicado. Uma observac ao importante sobre os
dados, que tamb em poderia ser associada ` a vida biol ogica, e que durante o est agio de
crescimento, os dados podem ser migrados para outros locais. Portanto, os dados podem
ser movidos de um local para outro em busca de melhores condic oes de an alise. Uma
diferenca, nesse caso, entre os ciclos de vida dos dados e o biol ogico, e que o primeiro
pode ser tanto movido quanto replicado. J a no segundo caso, no ciclo de vida biol ogico,
n ao h a a possibilidade de replicac ao.
O primeiro est agio, a gerac ao dos dados, pode produzir arquivos com diferentes
tamanhos dependendo da aplicac ao geradora e do prop osito do dado. Enquanto aplicac oes
web tipicamente lidam com arquivos de tamanhos da ordem de kilo at e megabytes, ima-
gens 3D de alta denic ao podem atingir tamanhos de at e tera ou petabytes. Indepen-
dentemente dos seus tamanhos individuais, a quantidade agregada pode compor grandes
volumes de dados, que n ao podem nem ser salvos em sistemas de armazenamento co-
muns nem ser transferidos atrav es das redes de acesso atuais. Logo, em termos de escala,
o resultado nal e o mesmo que haveria se eles fossem uma unica massa de dados.
Outra quest ao importante e o tipo ou o formato que os dados s ao gerados. Eles
podem ter ou n ao uma correlac ao clara se eles seguirem uma estrutura pr e-denida.
Nesse sentido, os dados podem ser classicados em quatro tipos: estruturados, quasi-
estruturados, semi-estruturados e desestruturados. Entradas em bancos de dados relaci-
onais s ao ditos estruturados j a que seguem um formato xo; dados que incluem auto-
descric oes conforme um esquema pr evio s ao considerados quasi-estruturados, por exem-
plo, dados descritos em uma estrutura XML; dados com algumas inconsist encias em seus
valores ou formatos s ao considerados semi-estruturados; enquanto imagens, vdeos e tex-
tos s ao considerados desestruturados. O processo de extrac ao de valor dos dados pode ser
classicado em uma ordem crescente de complexidade, na qual os dados desestruturados
Figura 1.4. Tipos de dados caracterizados de acordo com as suas principais
caractersticas de gerac ao.
s ao os que oferecem maiores diculdades para a extrac ao de valor.
A partir do n umero de fontes, volume e estrutura pode-se visualizar tr es carac-
tersticas ortogonais. A Figura 1.4 mostra a posic ao no espaco de dados conhecidos
conforme suas caractersticas principais. Registros e dados sensoriais comp oem gran-
des volumes a partir da agregac ao de dados de diferentes fontes. Transac oes comerciais
s ao feitas cada vez mais e seguem tipicamente uma estrutura rgida para n ao gerarem da-
dos err oneos. Os backups comumente resultam em arquivos grandes, enquanto imagens
e vdeos podem variar entre pequenos e grandes arquivos.
O segundo est agio, a agregac ao dos dados, est a relacionado ao modo como os da-
dos com sem antica semelhante ou de alguma forma correlacion aveis s ao continuamente
coletados e armazenados. Em geral, esses dados devem ter um signicado claro para ter
utilidade e podem ser armazenados de forma centralizada ou distribuda. Encontrar tal
signicado, entretanto, n ao e sempre obvio. Dada a diversidade das fontes e a diferenca
entre as estruturas dos dados, a correlac ao entre eles e a extrac ao de valor e um desao
que vai al em do armazenamento das grandes massas. Nesse est agio, apesar dos clientes
reconhecerem as possveis informac oes escondidas, eles preferem perder os dados a enve-
redar em uma busca incessante por correlac ao e, posteriormente, valor. Ao fazer isso, os
clientes sabem que podem perder informac oes de interesse como problemas operacionais,
comportamento de usu arios e possibilidades de falhas de seguranca que poderiam levar
a ganhos substanciais de desempenho. Al em da correlac ao dos dados gerados, e ainda
desej avel agregar esses dados com os sistemas legados que est ao mais adaptados ao setor
de produc ao especco dos clientes.
Em seguida, h a o est agio da an alise dos dados que e crucial e com frequ encia re-
quer soluc oes especcas para os diferentes dados. Durante a an alise, e necess ario lidar
com duas direc oes opostas: o volume e a complexidade dos tipos emergentes de dados,
que vem continuamente aumentando; e o tempo de processamento necess ario para trans-
formar as grandes massas de dados eminformac ao util emtempo real. Emoutras palavras,
o desao durante a an alise e transformar as grandes massas de dados em informac ao util
em um tempo sucientemente pequeno para que os usu arios sejam capazes de reagir a
possveis mudancas dos seus setores de interesse. Entretanto, mesmo considerando da-
dos estruturados, frequentemente os usu arios n ao sabem nem como lidar com os dados e
nem o que pode ser extrado deles. Tipicamente, os usu arios est ao habituados com da-
dos que j a possuem caractersticas conhecidas e cujos valores a serem extrados assim
como a probabilidade desses valores serem encontrados j a s ao previamente conhecidos.
A obtenc ao de informac oes das grandes massas de dados e diferente e essa nova oportuni-
dade e desaadora. Dessa forma, novas ferramentas que revelem diferentes signicados
s ao necess arias. A total falta de percepc ao sobre a exibilidade deste novo ambiente,
que possivelmente poderia levar a direc oes de interesse, assim como a falta de conheci-
mento pr evio sobre essa nova area de grandes massas de dados s ao atualmente os grandes
obst aculos.
As grandes massas de dados s ao tamb em atualizadas em altas taxas de forma inte-
rativa e incremental. As mudancas constantes nos dados gerados os tornam mais acurados
e mais precisos ao longo do tempo. Al em disso, sobre os dados atuais, mais dados s ao
criados, calculados e inferidos. Os novos dados criados s ao derivados dos originais de-
pois de requisic oes, resumos ou infer encias estatsticas. Adicionalmente, an alises podem
ser tamb em efetuadas atrav es do uso de t ecnicas de visualizac ao, especialmente impor-
tantes em casos nos quais a representac ao espacial pode contribuir na compreens ao e
manipulac ao dos dados. Um problema que surge como consequ encia do aumento nunca
visto antes da quantidade de dados e foco de novas t ecnicas de visualizac ao.
Aexecuc ao de an alises emmaiores detalhes, mantendo resultados concisos, acura-
dos e relevantes em um dado contexto de interesse leva a ac oes mais precisas e, como con-
sequ encia, maiores ganhos nanceiros. Por exemplo, provedores de energia e olica anali-
sam dados clim aticos para auxiliar no posicionamento dos seus equipamentos em campo.
Essa possibilidade permite encontrar os pontos otimos em que os captadores de vento de-
vem ser instalados para que, por conseguinte, a produc ao de energia aumente. Empresas
do ramo de mdias digitais podemtamb emse interessar em an alises de conte udo de vdeos
para detectar pirataria ou exibic ao n ao autorizada de seus vdeos em p aginas de redes so-
ciais. Ainda, o setor comercial de uma empresa pode se interessar em melhorar a an alise
de correios eletr onicos para observar o relacionamento entre os usu arios e, assim, apoiar
atividades que eles possam desempenhar em suas corporac oes. Por m, seria de interesse
dos setores t ecnicos de empresas a an alise de registros dos seus sistemas em execuc ao
para que seja possvel a realizac ao de manutenc ao preventiva. Descobrir problemas nos
equipamentos antes mesmo que eles ocorram permite melhorar o servico prestado aos
clientes ao planejar com anteced encia as intervenc oes de manutenc ao.
A extrac ao de valor dos dados tamb em tem que lidar com o aspecto de tempo util.
Enquanto v alidas as grandes massas de dados podemse encaixar emdiferentes prop ositos.
Entretanto, depois de certo tempo, o valor contido desaparece e toda a informac ao desses
dados se torna in util ou totalmente absorvida por dados mais recentes. Durante o ciclo de
vida, os dados n ao s ao necessariamente armazenados em discos rgidos j a que eles podem
ser exibidos por mdias em difus ao. Entretanto, quando armazenados, o desao e saber
por quanto tempo. Essa quest ao surge como um compromisso entre a disponibilidade da
informac ao e a acessibilidade dela. Frequentemente, dados em potencial s ao deixados de
lado ou mesmo descartados devido ` a falta de infraestrutura para an alise e armazenamento.
Por um lado, apesar de frustrados, os clientes descartam os dados que eles sabem que s ao
fontes empotencial de informac ao representativa para n ao saturar a sua infraestrutura. Por
outro lado, identicar o exato momento para descartar os dados, ou seja, o nal do seu
ciclo de vida, e complexo e pode levar ao armazenamento in util de quantidades macicas
de dados.
Durante o ciclo de vida, uma importante quest ao a ser considerada e como e por
qual motivo os dados devem ser movidos. Consequentemente, onde armazen a-los deve
ser cuidadosamente escolhido. A movimentac ao incessante dos dados ou a replicac ao
deles entre pontos geogracamente distantes e um desao abordado neste minicurso.
Essa tarefa pode envolver muitas t ecnicas de otimizac ao, como a localizac ao do lugar
mais apropriado para o armazenamento dos dados, que pode ser atrav es de t ecnicas de
agregac ao em um unico centro de dados (datacenter) con avel ou atrav es da manutenc ao
distribuda desses dados na vizinhanca dos seus consumidores.

E de suma import ancia
que a soluc ao adotada faca o melhor uso dos recursos disponveis para evitar impactos
negativos sobre o sistema de comunicac oes, sobre o meio ambiente ou ainda sobre a qua-
lidade de servico oferecida aos clientes. Uma soluc ao trivial e manter os dados no mesmo
ambiente de armazenamento e distribu-los sob demanda considerando propriedades de
localizac ao. Entretanto, essa estrat egia nem sempre e possvel j a que as grandes massas
de dados s ao transferidas muitas vezes usando a Internet ou outras redes de comunicac ao
que possuem limitac oes. Logo, os dados s ao distribudos entre m ultiplos centros de dados
mesmo fora da infraestrutura do seu propriet ario. Esses centros de dados externos podem
ser acessveis atrav es da pr opria Internet e podem estar disponveis publicamente.
1.3. Arquiteturas em Aglomerac ao
Como mencionado na sec ao anterior, o est agio de an alise e de suma import ancia. Uma
soluc ao para agilizar e viabilizar a an alise das grandes massas de dados e a partir das
arquiteturas em aglomerac ao (cluster), que est ao se tornando cada vez mais utilizadas
com esse objetivo. As principais raz oes para isso s ao o alto desempenho que as arquitetu-
ras em aglomerac ao apresentam e as vantagens j a mencionadas obtidas do paradigma de
computac ao em nuvem tais como a escalabilidade, a agilidade e a elasticidade dos recur-
sos. Essas caractersticas s ao pr e-requisitos muito importantes para a an alise das grandes
massas de dados. Uma quest ao chave, entretanto, e como as arquiteturas em aglomerac ao
podem atingir todas essas caractersticas e como elas podem ser comparadas ` as arqui-
teturas tradicionais utilizadas nas empresas. Primeiramente, e crucial compreender as
diferencas fundamentais oriundas dos princpios entre as arquiteturas tradicionais usadas
nas empresas e a arquitetura em aglomerac ao. O projeto das arquiteturas tradicionais
e baseado na premissa da exist encia de tr es tipos principais de recursos de hardware a
serem gerenciados:
servidores de custo elevado contendo alto potencial de processamento e de armaze-
namento que n ao devem car ociosos em nenhum momento;
matrizes de armazenamento (storage arrays) contendo mdias com diferentes tipos
de desempenho, capacidade e custo por GB, variando desde mdias de estado s olido
(Solid State Drives - SSD) at e discos rgidos SATAs;
redes de armazenamento (Storage Area Networks - SAN) conectando conjuntos de
servidores aos conjuntos de matrizes de armazenamento.
Uma das principais peculiaridades das arquiteturas tradicionais e a separac ao en-
tre os servidores e as matrizes de armazenamento, que podem expandir, podem ser atu-
alizadas ou removidas do uso, independente umas das outras. A SAN, por outro lado,
permite que aplicac oes sendo executadas em qualquer servidor tenham acesso aos dados
armazenados em qualquer elemento da matriz, se tiverem credenciais que as atribuam
esse direito. Em uma congurac ao empresarial, todos os componentes da arquitetura s ao
construdos para serem robustos e com modos de operac ao com toler ancia a falhas para
assegurar disponibilidade, muito embora n ao se espere que os componentes falhem com
frequ encia. Caso isso ocorra, eles s ao substitudos rapidamente. Essas propriedades de
robustez e alta disponibilidade, entretanto, conduzem a um maior valor agregado e, por
conseguinte, maiores custos.
A arquitetura tradicional foi projetada para aplicac oes de computac ao intensiva
que tipicamente requerem muitos ciclos de processamento, mas apenas em um subcon-
junto dos dados da aplicac ao, que ent ao s ao transferidos atrav es da SAN dos locais de
armazenamento at e os servidores para o processamento. Da mesma forma, os resultados
s ao transferidos de volta dos servidores at e os locais de armazenamento. Por exemplo,
considere as estatsticas e as an alises realizadas no nal do dia sobre o consumo di ario de
um determinado produto em todo o Brasil de uma empresa como a Americanas.com. Da-
das as in umeras opc oes de produtos disponveis nas Americanas.com, esse determinado
produto em especial representa um pequeno subconjunto do total de dados disponvel.
Considere ainda que seja necess ario ordenar uma grande massa de dados, e que atrav es da
ordenac ao, os dados s ao organizados conforme um dado crit erio, como ordem alfab etica,
num erica ou outra relacionada com o tempo, como o caso ocorrido com a Google em
2008 [Dean e Ghemawat, 2008a]. Para se ordenar dados, o conjunto inteiro pode precisar
ser examinado e isso e uma operac ao computacional altamente intensiva, especialmente se
as massas de dados forem da ordem de petabytes todo o dia. Essa tarefa fundamental em
computac ao e realmente muito importante porque, uma vez que os dados sejam ordena-
dos, todas as operac oes sobre esses dados podem ser executadas em ordens de magnitude
mais r apidas, como a busca e a combinac ao dos dados. De fato, acredita-se que cerca de
25% de todos os ciclos de CPU sejam gastos atualmente com operac oes de ordenac ao.
Portanto, considerando a quantidade de dados gerados por mdias sociais e outras fontes
com alterac oes di arias e considerando que todos esses dados s ao provavelmente ordena-
dos antes de serem analisados, deve-se denitivamente compreender como as diferentes
arquiteturas s ao utilizadas hoje para essas tarefas intensivas. Isso e o que leva as arquite-
turas em aglomerac ao (cluster) a serem mais ecientes, mesmo sendo projetadas a partir
de alguns princpios b asicos como:
baixo custo com o uso de hardware de prateleira, no qual os n ucleos de processa-
mento e os discos rgidos est ao mais em conta com a comunicac ao em nuvem.
Uma comprovac ao do baixo custo e o PennySort, que e um benchmark usado
como m etrica para medir a quantidade de dados que podem ser ordenados em um
tempo de processamento equivalente ao que se compraria com um centavo de d olar
(penny). De acordo com a Sortbenchmark, em 2011, a Universidade de Padova na
It alia registrou o recorde do PennySort com 334 GB. Os precos de equipamentos de
prateleira permitiram tamb em que empresas desenvolvessem arquiteturas altamente
escal aveis. Considerando, por exemplo, que a Google possua milh oes de n ucleos
de processadores em todos os seus centros de dados, apesar desses componentes
falharem com frequ encia, componentes redundantes fazem com que essas falhas
sejam imperceptveis aos usu arios;
viabilizac ao de aplicac oes com uso intensivo de dados em larga escala, nos quais
a computac ao seja feita frequentemente sobre o conjunto inteiro de dados e n ao
somente sobre um subconjunto deles. Considere, por exemplo, os estudos sobre
o genoma humano que analisa milhares de indivduos em busca de diferencas ou
mutac oes que possam ser a causa de uma doenca em particular. Uma vez que o ge-
noma consiste de uma sequ encia de 3,2 bilh oes de caracteres, a comparac ao deles
requer o uso intensivo de grandes dados. Outra m etrica poderia ser o MinuteSort,
que e umbenchmark usado para medir a quantidade de dados que pode ser ordenado
em exatamente 60 segundos. De acordo com o Sortbenchmark, em 2011, a Univer-
sidade da Calif ornia, em S ao Diego, estabeleceu um novo recorde do MinuteSort
com 1.353 GB;
atendimento dos requisitos das grandes massas de dados que requerem uma alta
vaz ao de leitura e cujo volume pode facilmente tornar a SAN um gargalo. Para
avaliar esse requisito, a m etrica GraySort pode ser usada. O GraySort mede a taxa
de ordenac ao, em termos de terabytes por minuto, que pode ser atingida durante
a ordenac ao de uma grande quantidade de dados. Novamente, de acordo com o
Sortbenchmark, em 2011, a Universidade da Calif ornia, em S ao Diego, estabeleceu
o novo recorde do GraySort com 0,938 TB/min, ou seja, quase 1 TB/min.
O conhecimento dos requisitos para an alise das grandes massas de dados permite
compreender o projeto da arquitetura. Uma arquitetura em aglomerac oes (clusters) e ba-
seada em um conjunto b asico de componentes que podem estar disponveis aos milhares
ou centenas de milhares e que podem ser facilmente montados em conjunto. Tudo e
iniciado a partir de um n o, que consiste de um conjunto de n ucleos de processamento
e mem orias principais de equipamentos de prateleira anexadas a um conjunto de dis-
cos rgidos tamb em de prateleira; uma pilha de n os formam um bastidor (rack); e um
grupo de bastidores formam um aglomerado (cluster). Todos os componentes s ao co-
nectados atrav es de uma rede de alta velocidade para troca r apida de informac oes. A
Figura 1.5 ilustra a arquitetura em aglomerac ao, assim como os seus principais compo-
nentes.

E importante destacar alguns princpios fundamentais e benefcios da arquitetura
em aglomerac ao. Primeiro, a arquitetura e altamente modular e escal avel. A capacidade
de execuc ao de suas tarefas se mant em crescente se novos n os e bastidores forem adicio-
nados. Segundo, as arquiteturas em aglomerac ao usam o conceito de localidade de dados,
no qual os dados podem ser processados pelos n ucleos computacionais localizados no
mesmo n o ou pelo menos no mesmo bastidor, onde est ao os discos com os dados, elimi-
nando ou minimizando qualquer transfer encia de dados pela rede. Como consequ encia, a
rede n ao deve se constituir em um potencial gargalo.
Adicionalmente, a arquitetura induz ` a paralelizac ao das atividades, tornando-se ideal para
o Processamento Paralelo Macico (Massive Parallel Processing - MPP). Portanto, retor-
nando ` a quest ao da ordenac ao dos dados, cada n o em um aglomerado pode ordenar o
fragmento da grande massa de dados que esteja localizado no mesmo n o. Isso leva ` a
Figura 1.5. Arquitetura em aglomerac ao e seus principais componentes: n o,
bastidor e interconex ao em alta velocidade.
transfer encia de dados somente de um disco local para a mem oria principal. De acordo
com a Universidade da Calif ornia em S ao Diego, o recorde do MinuteSort foi alcancado
com um cluster consistindo de 52 n os, cada um com dois processadores quad-core, 24
gigabytes (GB) de mem oria e discos de 16.500 GB, todos interconectados por um comu-
tador Cisco Nexus 5020. Por m, a paralelizac ao das leituras dos discos atrav es dos n os
pode aumentar o n umero de operac oes de entrada e sada por segundo (Input/Output Ope-
rations Per Second - IOPS) mesmo mantendo os mesmos custos com unidades de discos
rgidos.
Um exemplo simples comparativo entre o custo de armazenamento por IOPS entre
as arquiteturas tradicionais das empresas e da arquitetura em aglomerac ao permite enten-
der como esta ultima pode ser economicamente mais interessante. Nos c alculos apresenta-
dos, s ao usados dados publicados em um relat orio do Cr edit Suisse [Winslow et al., 2011]
em marco de 2011.

E importante observar que, nos c alculos, a proporc ao relativa entre os
n umeros e mais importante que os seus valores absolutos, j a que os valores continuam a
diminuir. Em uma arquitetura empresarial tradicional, as unidades de discos rgidos em
uma matriz de armazenamento variam em desempenho, capacidade, e custo por GB. As
unidades de discos de estado s olido (Solid State Drive - SSD), de acordo com o relat orio,
s ao capazes de executar 5.000 operac oes de escrita por segundo e 30.000 operac oes de
leitura por segundo com um custo por GB na faixa de 1,20 d olares. O SATA, por outro
lado, e capaz de executar apenas 250 IOPS, mas a um custo por GB na faixa de 0,04
d olares. Supondo um aglomerado com 120 n os, cada um capaz de realizar 250 IOPS, j a
que 120250 = 30.000, os 120 n os lendo dados em paralelo alcancam 30.000 IOPS, que
e o mesmo desempenho do SSD, mas a um custo por GB igual ao SATA. Portanto, o em-
prego da arquitetura em aglomerac ao se torna nanceiramente muito interessante. O com-
promisso, entretanto, e que essa arquitetura e baseada em hardware de prateleira e possui
componentes que podem falhar com frequ encia. Portanto, o software de gerenciamento
da arquitetura e as aplicac oes executadas nessa arquitetura devem detectar e responder
a falhas de forma automatizada e eciente. Isso traz um grande nvel de complexidade
j a que e necess ario considerar o compromisso. Para evitar perda de dados, tipicamente,
os dados s ao replicados em muitos n os, o que eleva a uma dada quantidade de recursos
de armazenamento necess aria para guardar os dados em um aglomerado. Se forem ne-
cess arias tr es r eplicas de 1 petabyte de dados, por exemplo, s ao necess arios 4 petabytes de
armazenamento. Finalmente, para atingir o m aximo proveito em termos de desempenho e
relac ao custo-benefcio, os dados precisam ser igualmente distribudos atrav es dos n os do
aglomerado. Logo, a aplicac ao precisa ser projetada tendo como meta o processamento
paralelo macico (MPP) de dados e o gerenciamento empregado precisa ser cuidadoso na
troca de resultados, nais ou intermedi arios, entre os n os do aglomerado. Por isso, os
princpios do Hadoop s ao apresentados na pr oxima sec ao para que seja possvel compre-
ender como e possvel utilizar as arquiteturas em aglomerac ao de forma eciente.
1.4. Modelos de Programac ao para Arquiteturas em Aglomerac ao
Para se utilizar a arquitetura em aglomerac ao e necess ario uma infraestrutura de software
de sistema distribudo. Essa infraestutura pode ser vista como o sistema operacional da
arquitetura em aglomerac ao usada em centros de dados. A infratestrutura e composta
por sistemas de arquivos distribudos, escalonadores, chamadas a procedimentos remo-
tos e modelos de programac ao para simplicar o uso dos recursos na escala dos centros
de dados, tais como: Hadoop [Apache, 2012], MapReduce [Dean e Ghemawat, 2008b],
Dryad [Isard et al., 2007], Dynamo [DeCandia et al., 2007] etc. Esta sec ao descreve o Ha-
doop que foi desenvolvido para um ambiente tpico de provedores de servico de nuvens
e que, al em disso, ele foi projetado para uma arquitetura em aglomerac ao construda a
partir de hardware de prateleira. Portanto, uma aglomerac ao e composta de componentes
simples, disponveis aos milhares e que podem ser combinados. Os n os s ao compostos
de tais componentes, uma pilha de n os forma um bastidor (rack) e um grupo de bas-
tidores forma um aglomerado (cluster). Todos conectados atrav es de uma rede de alta
velocidade para troca r apida de informac oes. Assim, o Hadoop e um software de c odigo
aberto para computac ao distribuda de modo con avel e escal avel. O Hadoop permite
o processamento distribudo de grandes conjuntos de dados atrav es de um aglomerado
de computadores usando um modelo simples de programac ao. O Hodoop e projetado
com o objetivo de escalar de um unico servidor at e milhares de m aquinas, cada uma com
processamento e mem oria local. A alta disponibilidade do sistema e obtida por software
projetado para detectar e tratar falhas, evitando assim maiores custos de hardware.
O Hadoop foi desenvolvido para aproveitar os recursos e a estrutura disponvel
em uma arquitetura em aglomerac ao. O objetivo e possibilitar que as aplicac oes utilizem
todo o potencial de um aglomerado ao levar em considerac ao dois pontos chave: (i) a
distribuic ao dos dados pelo aglomerado, assegurando que os dados estejam distribudo
igualmente e (ii) o desenvolvimento de aplicac oes que se beneciem da localizac ao dos
dados. Esses dois pontos fundamentais levam o projeto do Hadoop a empregar dois me-
canismos:
o Sistema de Arquivos Distribudo (Hadoop Distributed File System - HDFS) que
e um sistema de arquivos para dividir, espalhar, replicar e gerenciar dados ao longo
dos n os em um aglomerado;
o MapReduce que e um mecanismo computacional para executar aplicac oes em
paralelo. As aplicac oes s ao executadas atrav es da divis ao emtarefas que manipulam
apenas uma parcela dos dados, coletando e redistribuindo resultados intermedi arios
e gerenciando falhas atrav es de todos os n os do aglomerado.
Inicialmente, o sistema de arquivos distribudo do Hadoop e abordado para, em
seguida, ser apresentado o MapReduce. O sistema de arquivos distribudo do Hadoop se
baseia em conceitos simples e princpios de uniformidade em seu projeto. Um arquivo
consiste de blocos com tamanhos iguais e m ultiplos dos tamanhos dos blocos de arma-
zenamento. No Apache Hadoop Community Edition, por exemplo, os blocos de arquivo
s ao de 64 MB, enquanto os blocos de armazenamento s ao de 512 kB. O Hadoop usa o
bloco de arquivos como a unidade a ser empregada para distribuir partes de arquivo entre
os discos rgidos dos n os. Como n ucleos de processadores e discos em um n o e tamb em
n os em um bastidor (rack) podem falhar, o mesmo bloco de arquivo pode ser armazenado
em m ultiplos n os por todo o aglomerado. O n umero de c opias pode ser congurado, mas
por padr ao, e tipicamente igual a tr es.
O sistema de arquivos do Hadoop e classicado como distribudo porque ele
gerencia o armazenamento por todas as m aquinas da rede e os arquivos s ao distribudos
por entre diversos n os, no mesmo ou em diferentes bastidores ou aglomerados (clusters).
OHadoop trata todos os n os como n os de dados, o que signica que eles podemarmazenar
dados. Entretanto, ele elege ao menos um n o para ser o Name Node. Esse Name Node
decide, para cada arquivo do Hadoop, em qual disco rgido cada uma das c opias de cada
um dos blocos de arquivo e armazenada. Al em disso, o Name Node mant em todas as
informac oes em tabelas armazenadas localmente em seus discos. Quando um n o falha, o
Name Node identica todos os blocos de arquivo que foram afetados; recupera as c opias
desses blocos de arquivo de n os operacionais; encontra novos n os para armazenar outras
c opias dos dados afetados; armazena essas c opias no n o escolhido e atualiza a informac ao
em sua tabela. Quando uma aplicac ao precisa ler um arquivo, ele primeiro se conecta ao
Name Node para obter o endereco dos blocos do disco onde os blocos do arquivo est ao
armazenados. Assim, emseguida, a aplicac ao pode ler esses blocos diretamente semoutra
intervenc ao do Name Node.
Um dos maiores problemas apontados do sistema de arquivos distribudos do Ha-
doop e o fato do Name Node poder se tornar um ponto unico de falha. Se o n o que falhar
for o mesmo onde o Name Node est a, todas as informac oes de mapeamento entre nomes
de arquivos e enderecos de seus respectivos blocos de arquivo podem ser perdidos. Ent ao,
um novo n o precisa ser designado como o Name Node com o mesmo endereco IP do an-
terior que falhou. Para abordar tal quest ao, o Hadoop salva c opias das tabelas criadas
pelo Name Node em outros n os do cluster. Adicionalmente, algumas vers oes do Hadoop,
especialmente as edic oes empresariais, t em outros n os desempenhando o papel de Name
Node de backup.
O segundo mecanismo fundamental do Hadoop e o MapReduce. Como o pr oprio
nome sugere, o MapReduce enxerga uma tarefa computacional como consistindo de duas
fases, a fase de mapeamento (Map) e a fase de reduc ao (Reduce), que s ao executadas
nessa mesma sequ encia. Durante a fase de mapeamento, todos os n os desempenham a
mesma tarefa computacional a partir de um subconjunto dos dados que est a localizado no
pr oprio n o ou pr oximo dele. Em outras palavras, o MapReduce usa o princpio da locali-
dade dos dados para aumentar o seu desempenho e para minimizar a movimentac ao dos
dados pela rede.

E importante notar que devido a todos os blocos de arquivos no sistema
de arquivos distribudos do Hadoop terem o mesmo tamanho, a computac ao na fase de
mapeamento pode ser igualmente dividida entre os n os. Se os blocos de arquivo n ao tives-
sem o mesmo tamanho, o tempo de processamento seria predominantemente ditado pelo
tempo necess ario para processar o bloco de arquivo mais longo, enquanto os outros n os
permaneceriam ociosos. Se considerado, por exemplo, um arquivo utilizado para agregar
entradas de blogs relacionadas a grandes massas de dados postadas nas ultimas 24 horas,
este arquivo seria armazenado de forma dividida no sistema de arquivos distribudos do
Hadoop. Esse arquivo poderia ter o nome de BigData.txt e poderia ser dividido
em blocos de arquivos, cada um gerando pelo menos tr es c opias, armazenadas nos 50 n os
de um aglomerado. A partir desse exemplo, pretende-se iniciar uma an alise dessa grande
massa de dados atrav es, primeiramente, da contagem do n umero de vezes que as palavras
Computador, Rede e Dados s ao mencionadas. Assume-se que a func ao de mape-
amento recebe como entrada o endereco de um bloco de arquivo e oferece como sada o
n umero de vezes que cada uma dessas palavras apareceu. Para tal, cada n o participante
da fase de mapeamento recebe um ponteiro para a func ao de mapeamento e o endereco
do bloco de arquivos localizado no n o. No exemplo, assume-se ainda que a rede seja
composta por tr es n os, sendo eles o N o 1, o N o 2 e o N o 3.
O MapReduce possui outro princpio simples no que se refere a sua estrutura de
sada da fase de mapeamento e entrada e sada da fase de reduc ao, j a que ela consiste de
uma lista de pares <chave, valor>. Esse conceito e t ao importante no MapReduce
que tamb em e apresentado no contexto do exemplo dado a seguir. Ap os a execuc ao da
func ao de mapeamento, cada n o produz uma lista de pares chave-valor, na qual cada
chave e o nome da palavra e o valor e um n umero que indica o n umero de vezes que o
nome aparece no texto. Pode-se, ent ao, utilizar a fase de reduc ao para somar os resultados
obtidos por cada n o para reduzir a sada das func oes de mapeamento a uma unica lista
de pares chave-valor.
No MapReduce, um n o e selecionado para executar a func ao de reduc ao. Todos
os outros n os precisam enviar a lista <chave, valor> criada pela pr opria func ao de
mapeamento ao n o designado. Assumindo que o N o 2 seja cumpra esse papel durante
a execuc ao da func ao de reduc ao, ent ao os N os 1 e 3 t em que os seus resultados para
o N o 2. Tipicamente, durante a fase de reduc ao, as entradas s ao ordenadas e combina-
das antes da reduc ao propriamente dita ocorrer. No exemplo ilustrado na Figura 1.6,
a entrada da fase de reduc ao e <Computador, 7>, <Rede, 5>, <Dados, 4>,
<Computador, 9>, <Rede, 8>, <Dados, 6>, <Computador, 3>, <Rede,
4>, <Dados, 9> que e a sada da fase de mapeamento referente a execuc ao dos N os 1,
2 e 3, respectivamente. O primeiro procedimento executado agrupa os pares <chave,
valor> com a mesma chave de forma ordenada. Em seguida, o procedimento execu-
tado e o procedimento de combinac ao que agrupa os pares <chave, valor> com a
mesma chave em uma unica entrada. O agrupamento e realizado de forma que cada en-
trada seja composta de uma chave e uma lista com todos os valores relacionadas a mesma
chave no procedimento anterior. Finalmente, o procedimento de reduc ao soma os valores
associados a cada chave existente do par <chave, valor>.
Figura 1.6. Fase de reduc ao do MapReduce.
No arcabouco MapReduce, ambas operac oes de mapeamento e reduc ao s ao con-
sideradas rotinas, que combinadas formam uma tarefa. O arcabouco MapReduce requer
que exista:
um JobTracker para coordenar todas as tarefas executadas no sistema atrav es da
divis ao da tarefa em rotinas e para agendar cada uma dessas tarefas para serem
executadas em um n o. O JobTracker tamb em mant em informac oes de todos os n os
participantes da computac ao, monitora os status individuais, orquestra o uxo de
dados e se encarrega de contornar as falhas dos n os;
um n umero de TaskTrackers que executem tarefas e enviem relat orios de progresso
ao JobTracker. Caso a tarefa falhe, o JobTracker pode reagend a-la emumTaskTrac-
ker diferente. O TaskTracker mant em informac oes de todas as tarefas em execuc ao
em seus n os, seja uma tarefa de mapeamento ou reduc ao.
Semelhantemente ao sistema de arquivos distribudos do Hadoop, no qual um n o
assume o papel de um Name Node, no MapReduce, um n o assume o papel de JobTracker.
Antes de executar uma tarefa, um programador de Hadoop deve prover ao MapReduce as
seguintes informac oes: (i) a localizac ao dos dados a serem processados, que consiste em
uma lista de blocos de arquivo e enderecos de todas as c opias oferecidas pelo sistema
de arquivos distribudos do Hadoop, (ii) a func ao de mapeamento a ser executada du-
rante a fase de mapeamento e (iii) a func ao de reduc ao a ser executada durante a fase de
reduc ao. O programador obt em como resultado, uma lista de pares <chave, valor>
consolidada.
De certa forma, a computac ao com o Hadoop em uma arquitetura em aglomerado
prov e uma extens ao de computac oes tpicas realizadas em congurac oes empresariais,
possibilitando que eles desempenhem an alises intensivas em grandes massas de dados.
De acordo com previs oes realizadas pelo Yahoo, at e a segunda metade desta d ecada, 50%
dos dados empresariais estar ao sendo processados e armazenados usando o Hadoop.
Apesar do alto potencial de aprimoramento do desempenho das an alises em gran-
des massas de dados que aproveitam propriedades de localizac ao dos dados, nem sempre
e possvel contar com tal possibilidade. Em centros de dados, os dados podem ser movi-
dos de uma m aquina para outra ou entre diferentes bastidores. Al em disso, os centros de
dados podem estar espalhados por diferentes cidades ou at e mesmo pases. Essa ultima
possibilidade e frequente j a que muitas empresas est ao criando infraestrutura de arma-
zenamento de provedores de servico em nuvem. Para acessar seus dados armazenados
externamente ou at e mesmo para migrar seus dados entre centros de dados geograca-
mente distantes, as empresas podem se servir de redes p ublicas como a Internet. Este
minicurso investiga essa movimentac ao dentro de um unico centro de dados e entre dois
ou mais datacenters chamando esse tipo de comunicac ao de, respectivamente, migrac ao
intra e inter-datacenter.
1.5. Modelos de Interconex ao para Arquiteturas em Aglomerac ao
Um dos principais fatores a serem levados em considerac ao na implantac ao de cen-
tros de dados e o custo. Por quest oes de compatibilidade e de custo, a maioria dos
sistemas de comunicac ao para aglomerados utiliza comutadores Ethernet e roteadores
para interconectar as m aquinas dos aglomerados [Al-Fares et al., 2008]. A agilidade
2
e
uma outra propriedade que deve ser provida por esses sistemas em aglomerados. Nesta
subsec ao, s ao apresentadas as arquiteturas tpicas e propostas de novas arquiteturas de
centros de dados, incluindo suas principais caractersticas, tais como topologias, esque-
mas de enderecamento e mecanismos de roteamento e de encaminhamento.
As arquiteturas tpicas de centros de dados consistem em arvores hier arquicas de
dispositivos de roteamento e de comutac ao com equipamentos cada vez mais especiali-
zados e caros conforme se sobe na hierarquia.

E comum se ter arvores de dois ou tr es
nveis de comutadores e de roteadores [Al-Fares et al., 2008]. Na topologia de tr es nveis,
servidores s ao conectados a comutadores topos de bastidores (Top-of-Racks - ToRs), co-
mutadores de agregac ao conectam comutadores ToRs e s ao conectados a roteadores de
n ucleo, como apresentado na Figura 1.7. A topologia de dois nveis somente possui as
camadas n ucleo e ToR. Comutadores nas folhas de uma arvore possuem tipicamente de
48 a 288 portas Gigabit Ethernet que conectam servidores e algumas portas a 10 Gb/s de
subida (uplink). Os comutadores de nveis mais altos somente possuem portas a 10 Gb/s
(tipicamente de 32 a 128 portas).
2
Agilidade signica capacidade de associar qualquer hospedeiro a qualquer servico em uma topologia
em aglomerado [Greenberg et al., 2009].
Figura 1.7. Arquitetura em camadas tpica de centros de dados.
Considerando essas arquiteturas tpicas de centros de dados, um dos principais ar-
tifcios utilizados para diminuir o custo e a velocidade do enlace para um nvel mais alto
n ao corresponder ` a soma de todos os enlaces de nvel mais baixo, artifcio denominado
sobreinscric ao (oversubscription). Por exemplo, uma sobreinscric ao 1:4 signica que os
dispositivos da camada de agregac ao ou de n ucleo possuem capacidade menor do que a
capacidade total dos dispositivos do nvel mais baixo, na proporc ao de 1 para 4, ou seja,
para cada 4 Gb/s de banda passante dos servidores, corresponde somente 1 Gb/s no nvel
superior (uplinking). Por outro lado, uma sobreinscric ao 1:1 signica que todos os servi-
dores podemse comunicar comoutros servidores usando a taxa m axima de suas interfaces
de rede, alcancando o que se denomina m axima banda passante agregada (full bisection
bandwidth). A sobreinscric ao 1:1 na verdade corresponde ` a aus encia de sobreinscric ao.
A capacidade de comunicac ao utilizando a banda total entre quaisquer pares de
servidores e um requisito que as novas arquiteturas de centros de dados procuram atender.
No caso em que um unico roteador de n ucleo e utilizado, h a uma restric ao quanto ao
n umero m aximo de servidores da rede. Por exemplo, considere um dispositivo comercial
tpico de grande porte que possui 128 portas de 10 Gb/s sendo utilizado na camada de
n ucleo. A cada porta de 10 Gb/s conecta-se o enlace de subida de um comutador de
menor porte ao qual podem ser conectados em suas portas de 1 Gb/s at e 10 servidores,
para que seja garantida a banda total de 10 Gb/s sem sobreinscric ao. Assim, considerando
uma sobreinscric ao 1:1 e a banda disponvel nesse unico dispositivo do n ucleo, o n umero
m aximo de servidores na rede do centro de dados seria limitado a 1.280.
Este exemplo mostra a diculdade de se interconectar um grande n umero de ser-
vidores em um aglomerado sem sobreinscric ao usando a topologia em arvore. Uma
forma de se contornar a restric ao de n ao se conseguir equipamentos de baixo custo com
enlaces de subida de taxas muito altas e a utilizac ao de m ultiplos enlaces de subida
ou topologias diferentes da mencionada acima. Em func ao disso, utilizam-se arvores
com m ultiplas razes e t ecnicas de m ultiplos caminhos, tais como o algoritmo Equal-
Cost Multi-Path (ECMP) [Hopps, 2000]. O ECMP realiza um balanceamento est atico
de carga se caminhos de um mesmo custo estiverem disponveis. Contudo, o n umero de
m ultiplos caminhos e baixo e o n umero de entradas nas tabelas de roteamento cresce
bastante com o n umero de caminhos, aumentando o custo e lat encia de busca na ta-
bela [Al-Fares et al., 2008].
1.5.1. Fat-tree
Uma das arquiteturas cujo principal objetivo e reduzir o custo mantendo a capacidade de
comunicac ao utilizando a banda total entre quaisquer pares de servidores e denominada
Fat-tree [Al-Fares et al., 2008], ou arvore gorda. Diferentemente da arvore comum, a
arvore gorda e mais parecida com uma arvore real, pois esta ca cada vez mais grossa
partindo-se das folhas. Na arvore gorda, quanto mais se sobe na hierarquia, maior e o
n umero de enlaces utilizados conectando um n o lho ao seu pai; consequentemente a
banda passante aumenta [Leiserson, 1985].
Essas redes cont em m ultiplos est agios construdos como uma matriz de peque-
nos elementos de conex ao. Na topologia Fat-tree, comutadores Ethernet de prateleira
3
s ao utilizados, de forma a reduzir o custo da arquitetura. Por exemplo, comutadores de
48 portas de 1 Gb/s poderiam ser usados em uma Fat-tree.
A regra de formac ao de uma Fat-tree e apresentada a seguir. Uma k- esima Fat-
tree e composta por k pods e (k/2)
2
comutadores de n ucleo com k portas. Um pod possui
duas camadas (borda e agregac ao) de k/2 comutadores cada e tamb em inclui k servidores.
Cada comutador com k portas na camada de borda e conectado a k/2 servidores. As ou-
tras k/2 portas de um comutador de borda s ao conectadas a k/2 de k portas na camada de
agregac ao. Cada comutador de n ucleo possui uma porta conectada a cada um dos k pods.
Nesta arquitetura, no total podem ser conectados k
3
/4 servidores. Todos os servidores co-
nectados ao mesmo comutador de borda pertencem a uma mesma sub-rede, enquanto que
a comunicac ao entre servidores de diferentes sub-redes envolve roteamento. A Figura 1.8
mostra um exemplo de uma topologia Fat-tree com k = 4. Nessa topologia caso sejam
utilizados comutadores de 48 portas de 1 Gb/s haveria 48 pods, com 24 comutadores em
cada uma das camadas de borda e de agregac ao e 24 servidores ligados a um pod, em um
total de 27.648 servidores.
Figura 1.8. Exemplo de topologia Fat-tree com k=4.
Para atingir a capacidade m axima de comunicac ao utilizando a banda total entre
quaisquer pares de servidores e necess ario distribuir de forma mais uniforme possvel o
tr afego de sada de um dado pod entre os comutadores de n ucleo. H a ent ao a neces-
sidade de se utilizar um m etodo de distribuic ao que seja simples e que tire vantagem
3
Em [Al-Fares et al., 2008], os autores usam o termo comutador se referindo a dispositivos que realizam
comutac ao no nvel 2 e roteamento no nvel 3. A mesma notac ao ser a utilizada nesta subsec ao.
da estrutura da topologia. Dessa forma, os autores prop oem o uso de tabelas de rotea-
mento de dois nveis para espalhar o tr afego baseando-se nos bits menos signicativos
do endereco IP de destino. A seguir o esquema de enderecamento e descrito e posterior-
mente as tabelas de roteamento ser ao apresentadas. De forma a simplicar as tabelas de
roteamento, um esquema especial de enderecamento e utilizado. Enderecos IP s ao aloca-
dos a partir de um bloco 10.0.0.0/8. Comutadores de um pod utilizam enderecos da forma
10.pod.comutador.1, onde pod se refere ao n umero do pod, de 0 a k1, da esquerda para
direita, enquanto comutador signica a posic ao daquele comutador no pod, de 0 a k 1,
da esquerda para direita, de baixo para cima. Os enderecos dos comutadores de n ucleo
seguem o padr ao 10.k. j.i, onde j e i est ao relacionados ` a coordenada do comutador na
grade de (k/2)
2
comutadores, cada um de 1 a k/2, comecando em cima e ` a esquerda.
Os servidores utilizam enderecos da forma 10.pod.comutador.id, onde id e a posic ao do
servidor naquela sub-rede, de 2 a k/2+1, da esquerda para direita. A Figura 1.8 tamb em
inclui um exemplo do esquema de enderecamento.
Fares et al. assumem que existe uma entidade central com conhecimento da topo-
logia do aglomerado que gera e carrega todas as tabelas de roteamento nos comutadores
durante a fase de estabelecimento da rede. Algoritmos especcos para gerar as tabelas
de roteamento dos comutadores de agregac ao e de n ucleo e para distribuir essas tabe-
las s ao apresentados em [Al-Fares et al., 2008]. Al em disso, duas t ecnicas opcionais de
roteamento din amico s ao tamb em apresentadas.
A arquitetura Fat-tree tamb em inclui extens oes ao encaminhamento IP de forma a
atingir o uso efetivo da capacidade da topologia. Essas extens oes envolvem modicac oes
nos comutadores. De uma maneira geral, uma vez que o pacote chega a um comutador
de n ucleo, existe um enlace para o seu pod de destino. Ap os o pacote chegar ao seu pod
de destino, ele e enviado ao seu comutador de sub-rede de destino e depois e nalmente
enviado ao servidor de destino. Tabelas de roteamento de dois nveis s ao utilizadas para
espalhar o tr afego baseando-se nos bits menos signicativos do endereco IP de destino.
Cada entrada da tabela (pre f ixo, porta) possui um ponteiro adicional para uma tabela se-
cund aria com entradas do tipo (suf ixo, porta). Uma tabela secund aria pode ser apontada
por mais de um prexo de primeiro nvel. Se a busca pelo prexo mais longo coinci-
dente obt em como resultado um prexo que cont em um suxo de segundo nvel, o suxo
mais longo coincidente na tabela secund aria e utilizado. Para comunicac oes inter-pods,
os comutadores de um pod possuem um prexo padr ao /0 com a tabela secund aria coin-
cidindo com os identicadores dos hospedeiros (byte menos signicativo do endereco IP
de destino). Por exemplo, na Figura 1.9 e apresentada a tabela do comutador 10.2.2.1
(Figura 1.8). Um pacote com endereco de destino 10.2.1.2 e encaminhado na porta 1,
enquanto que um pacote para 10.3.0.3 e enviado na porta 3. Na Figura 1.8, dados do
servidor 10.0.1.2 para o 10.2.0.3 seguem o caminho indicado em tracejado.
As tabelas de roteamento de dois nveis podem ser implementadas em hardware
usando mem orias CAM (Content-Addressable Memory). Mais especicamente, um tipo
especial de mem oria CAMdenominado TCAM(Ternary CAM) e utilizado. Uma mem oria
TCAM permite buscas mais exveis por utilizar Xs (dont cares) al em dos 0s e 1s. As-
sim, a TCAM pode por exemplo armazenar o valor 0x0C.3F.XX.XX, onde alguns bits
n ao s ao denidos. Assim, em vez de apenas enderecos IP completamente denidos de
32 bits, a TCAM permite armazenar prexos e suxos de enderecos. Estes indexam uma
mem oria RAM que armazena o endereco IP do pr oximo salto e a porta de sada.
Figura 1.9. Tabela de roteamento de dois nveis no comutador 10.2.2.1 da Figura 1.8.
1.5.2. BCube
O BCube [Guo et al., 2009] tamb em procura resolver os problemas de custo e de desem-
penho relacionados ` a necessidade de enlaces de subida de alta taxa de transmiss ao para
diminuic ao da sobreinscric ao, por em utilizando uma abordagem diferente da Fat-tree. O
BCube foi especicamente projetado para centros de dados modulares (Modular Data
Centers - MDCs) montados em cont eineres, que s ao estruturas mais ecientes em relac ao
` a refrigerac ao dos equipamentos. Como os cont eineres s ao selados e depois colocados em
operac ao, torna-se bastante difcil a manutenc ao de seus componentes [Guo et al., 2009].
Assim, a infraestrutura de rede nos MDCs necessita alta toler ancia a falhas. O BCube
foi projetado para possuir uma queda de desempenho lenta quando submetido a falhas
em seus comutadores ou servidores. Outra caracterstica importante que e atendida por
essa arquitetura corresponde ao suporte aos diferentes padr oes de comunicac ao: um-para-
um, um-para-muitos, um-para-todos e todos-para-todos. Essa medida visa atender v arias
aplicac oes que demandam grande banda passante, tais como sistemas de arquivos dis-
tribudos (um-para-muitos) e MapReduce (muitos-para-muitos).
No BCube, os servidores s ao conectados a m ultiplas camadas de pequenos comu-
tadores. O BCube corresponde a uma estrutura denida de forma recursiva. Um BCube
de nvel 0, denominado BCube
0
, consiste de n servidores conectados a um comutador de
n portas. J a um BCube
1
e composto por n BCube
0
s e por n comutadores de n portas. De
uma maneira geral, um BCube
k
(k 1) e formado por n BCube
k1
s e n
k
comutadores de
n portas. Os n BCube
k1
s s ao numerados de 0 a n1 e os servidores em cada BCube
k1
s ao numerados de 0 a n
k
1. A porta do nvel k do i- esimo servidor localizado no j- esimo
BCube
k1
e conectada ` a j- esima porta do i- esimo comutador de nvel k. A Figura 1.10
apresenta um BCube
1
com n = 4.

E importante ressaltar que o BCube mostrado na Fi-
gura 1.10, ao contr ario da Fat-tree mostrada na Figura 1.8, requer mais de uma interface
Ethernet no servidor.
Existe um mapeamento de um-para-um entre um endereco IP e um endereco
BCube. O BCube tamb em utiliza enderecos de 32 bits. O BCube armazena um ndice
de pr oximo salto (Next Hop Index - NHI) e o caminho completo (array de NHIs) no
cabecalho de cada pacote. Um vers ao de 8 bits do NHI, chamada NHA, pode ser usada
para reduzir o tamanho do cabecalho. Um NHA e dividido em duas partes: DP e DV.
O DP indica qual dgito do pr oximo salto e diferente do atual servidor de retransmiss ao
enquanto que o DV corresponde ao valor daquele dgito.
Figura 1.10. Um exemplo de BCube
1
com n=4.
O BCube prov e m ultiplos caminhos paralelos e curtos para permitir comunicac oes
servidor-para-servidor. Al em de prover uma grande banda passante na comunicac ao um-
para-um, esses caminhos tamb em aumentam a toler ancia a falhas e melhoram o balan-
ceamento de carga. Um protocolo de roteamento pela fonte denominado BSR (BCube
Source Routing) e utilizado por tr es motivos. Primeiro, a fonte pode controlar o cami-
nho sem coordenac ao com os servidores intermedi arios. Segundo, esses servidores inter-
medi arios n ao se envolvem no roteamento e somente encaminham pacotes, simplicando
suas operac oes. Por ultimo, ao sondar a rede de modo reativo, pode-se evitar a difus ao
de estados de enlaces, que possui um problema de escalabilidade quando milhares de ser-
vidores est ao em operac ao. Ao tirar proveito dos m ultiplos caminhos e por ativamente
sondar a rede, o BSR prov e balanceamento de tr afego e lida com falhas sem necessitar
distribuir os estados dos enlaces. Com o BSR, a capacidade do BCube diminui de modo
n ao abrupto quando as falhas dos servidores/comutadores aumentam.
O funcionamento do BSR e apresentado a seguir. Quando um uxo deve ser
transmitido, a fonte envia sondas em m ultiplos caminhos. Os servidores intermedi arios
incluem informac oes nesses pacotes que ser ao utilizadas para selecionar um dos m ultiplos
caminhos, por exemplo, mnima banda passante disponvel. Quando uma sonda chega
ao destino, o destino envia uma resposta para a fonte. Ao receber as respostas, a fonte
seleciona o melhor caminho baseado em alguma m etrica, por exemplo, a m axima banda
passante disponvel. O algoritmo usado para calcular os k +1 caminhos paralelos entre
dois servidores e apresentado em [Guo et al., 2009].
O procedimento de encaminhamento utiliza uma tabela de status de vizinhos,
mantida por um protocolo de manutenc ao de vizinhos. Cada entrada na tabela corres-
ponde a umvizinho e possui tr es campos: NeighborMAC, OutPort e StatusFlag. ONeigh-
borMAC e o endereco MAC do vizinho, o qual e obtido do protocolo de manutenc ao de
vizinhos, OutPort indica a porta de conex ao com o vizinho e o StatusFlag indica se o
vizinho est a disponvel. Cada entrada e indexada pelo valor de NHA do vizinho. Quando
um hospedeiro intermedi ario recebe um pacote, ele obt em o NHA do pr oximo salto do
cabecalho do pacote. Ent ao ele extrai o status e o endereco MACdo pr oximo salto, usando
o NHA como ndice. Se o pr oximo salto est a funcional, ele atualiza os enderecos MAC,
o NHA e a soma de vericac ao (checksum) do cabecalho do BCube e encaminha o pacote
pela porta de sada.
Figura 1.11. Exemplo da topologia Camada Virtual 2 (VL2).
1.5.3. Camada Virtual 2 (VL2)
A proposta Camada Virtual 2 (Virtual Layer 2 - VL2) [Greenberg et al., 2009] utiliza co-
mutadores de baixo custo
4
em uma topologia Clos para lidar com o problema de custo e
tamb em com a quest ao da agilidade. O VL2 prov e a ilus ao de que os servidores est ao co-
nectados a um grande comutador n ao interferente de Camada 2 que abrange um centro
de dados. Essa caracterstica do comutador equivale ` a propriedade de n ao-bloqueio em
redes de comutac ao de circuitos, enquanto as taxas de distribuic ao de tr afego forem uni-
formes e os padr oes de tr afego oferecido n ao violarem restric oes da borda (por exemplo,
velocidade da placa).
Os enlaces entre os comutadores de n ucleo e de agregac ao formam um grafo com-
pleto bipartido, facilitando assim o balanceamento de carga entre os diversos comutadores
de n ucleo. Os comutadores ToR s ao conectados a dois comutadores de agregac ao. Cada
servidor e conectado a um comutador ToR. Um exemplo de uma rede VL2 e apresentado
na Figura 1.11.
OVL2 utiliza dois tipos de enderecos IP. Todos os comutadores usamenderecos IP
especcos de localizac ao (Location-specic IP Addresses - LAs), enquanto os servidores
e os comutadores ToR usam enderecos IP especcos de aplicac ao (Application-specic
IP Addresses - AAs). Um AA n ao e modicado mesmo se a localizac ao do servidor
mudar por migrac ao ou reprovisionamento. Cada servidor e associado com um LA, o
identicador do comutador ToR ao qual o servidor est a conectado. Existe um sistema
de diret orios que mapeia AAs em LAs. Os enderecos LAs de comutadores de n ucleo
s ao um s o, pois essa opc ao simplica o procedimento de balanceamento de carga (a ser
apresentado a seguir). Al em disso, como alguns comutadores baratos n ao proveem su-
porte a tuplas com cinco elementos (por exemplo, para o TCP: protocolo, endereco fonte,
porta fonte, endereco de destino e porta de destino) quando um pacote e encapsulado
com m ultiplos cabecalhos IP, um agente na fonte calcula um hash dos cinco valores e
escreve esse hash no campo endereco IP da fonte, usado pelos comutadores nas tomadas
de decis ao de encaminhamento utilizando o ECMP, como descrito a seguir.
Os comutadores executam o protocolo OSPF disseminando somente enderecos
4
Em [Greenberg et al., 2009], os autores utilizam o termo comutador se referindo a dispositivos que
realizam roteamento no Nvel 3. A mesma notac ao ser a utilizada nesta subsec ao.
Figura 1.12. Exemplo de enderec amento da Camada Virtual 2 (VL2). O H(ft) cor-
responde ao hash da tupla de cinco valores.
LAs. Al em disso, dois mecanismos de balanceamento de carga s ao usados: o VLB e o
ECMP. O objetivo dos dois mecanismos e similar: o VLB distribui tr afego atrav es de n os
intermedi arios enquanto que o ECMP o faz atrav es de caminhos de mesmo custo.
O VLB (Valiant Load Balancing) distribui tr afego pelos comutadores de n ucleo
sem uma coordenac ao centralizada ou usar engenharia de tr afego. Usando o VLB, cada
servidor independentemente seleciona um caminho aleat orio para cada um dos uxos que
envia para outros hospedeiros. O VLB usa uxos como unidade b asica de espalhamento
para evitar a entrega fora de ordem de pacotes. J a o ECMP lida com a entrega de pacotes
encapsulados com o endereco anycast a qualquer um dos comutadores de n ucleo. O uso
de enderecos anycast simplica o sistema de diret orios. No caso de falha de comutadores
ou de enlaces, o ECMP ir a reagir, eliminando a necessidade de noticar os agentes e
assegurando a escalabilidade.
A Figura 1.12 mostra um exemplo do encaminhamento junto com os mecanismos
VLB e ECMP. Para encaminhar tr afego entre os hospedeiros 20.0.0.55 e 20.0.0.56, um
agente VL2 no hospedeiro captura o pacote e o encapsula com o endereco LA do co-
mutador ToR de destino (10.0.0.6 na Figura 1.12). Al em disso, o pacote e encapsulado
com o endereco anycast 10.1.1.1. Depois de passar pelo comutador ToR, o pacote ent ao
e entregue a um dos comutadores de n ucleo, desencapsulado pelo comutador, entregue
ao comutador ToR utilizando o endereco LA, desencapsulado de novo e ent ao enviado ao
destino.
1.5.4. Jellysh
O Jellysh [Singla et al., 2011] aborda a quest ao da expans ao incremental dos datacen-
ters. Esse problema e comumente deixando de lado por outras propostas da literatura,
principalmente aquelas que prop oem o uso de topologias rgidas. Tipicamente, o n umero
de servidores em topologias conhecidas e determinado pelo n umero de portas dos comuta-
dores disponveis. Como visto, em uma topologia do tipo Fat-Tree [Al-Fares et al., 2008],
o n umero m aximo de servidores e func ao do n umero de portas dos seus comutadores. Se-
melhantemente, no BCube [Guo et al., 2009], o n umero m aximo de servidores depende
no n umero de portas por comutador e tamb em do n umero de nveis da sua estrutura mo-
dular. O n umero m aximo de servidores, nesse caso, e func ao do n umero de portas por
comutador e do n umero de nveis do modelo de interconex ao.
Tanto no Fat-Tree [Al-Fares et al., 2008] quanto no BCube [Guo et al., 2009], o
aumento do n umero de servidores pode desbalancear a estrutura se for feita de maneira
a n ao levar em conta a rigidez da topologia. A consequ encia e a possibilidade de perda
de duas propriedades principais dos centros de dados (datacenters) que s ao a vaz ao de
bissec ao e a toler ancia a falhas. Logo, se mais servidores forem necess arios, todos os
comutadores devem ser substitudos para manter as propriedades desejadas. Essa carac-
terstica n ao e interessante j a que as demandas dos clientes por armazenamento e pro-
cessamento de dados est ao crescendo a passos largos. O Jellysh permite que as co-
nex oes sejam realizadas de forma aleat oria no nvel dos comutadores, resultando em uma
distribuic ao uniforme que n ao compromete as propriedades de interesse dos centros de
dados. O modelo de interconex ao de um centro de dados que utilize o Jellysh e formado
por comutadores e servidores. Assumindo que cada comutador i tenha k
i
portas, c
i
delas
s ao conectadas a outros comutadores, enquanto as portas restantes, k
i
c
i
, s ao conectadas
a servidores. Para simplicar, se existirem n comutadores na rede e se todos eles tiverem
o mesmo n umero de portas (k =k
i
) e comutadores conectados (c =c
i
), ent ao o n umero de
servidores suportados e n(k c). Ao amostrar o espaco de possibilidades, a topologia
resultante se mostra aleat oria e uniformemente distribuda.
A construc ao segue um algoritmo que empiricamente oferece as propriedades de-
sejadas atrav es da interconex ao dos comutadores e dos comutadores com os servidores.
O algoritmo usado no Jellysh inicia escolhendo e, posteriormente, conectando um par
aleat orio de portas entre as disponveis no centro de dados. Esse procedimento e recur-
sivamente repetido at e que n ao sobrem mais portas disponveis ou um unico comutador
permaneca com duas ou mais portas desconectadas. Caso o ultimo caso ocorra, um dos
enlaces existentes e aleatoriamente escolhido e removido. A remoc ao aumenta o n umero
de portas disponveis na topologia para que as portas que haviam sobrado possam ser
conectadas.
A Figura 1.13 mostra comutadores de quatro portas (k
i
=k =4), os quais cada um
est a conectado a dois servidores e dois comutadores (c
i
= c = 2). Logo, ao nal, todos os
comutadores devem ter suas c portas conectadas a outros comutadores e k c portas co-
nectadas a servidores. Na topologia ilustrada, o n umero m aximo de servidores e, portanto,
n (k c) = 5 (4 2) = 10. No exemplo, a execuc ao do algoritmo de interconex ao
da rede termina com um comutador (Comutador S) com duas portas disponveis. Quando
isso ocorre, enlaces existentes devem ser removidos at e que as portas que tenham sobrado
sejam conectadas. Cada enlace e removido por vez, at e que o n umero de portas disponi-
bilizadas seja suciente. A Figura 1.13(b) mostra a mesma topologia depois da remoc ao
dos enlaces A e da posterior conex ao das portas que haviam sobrado no Comutador S ` a
topologia.

E importante mencionar que outra vantagem do Jellysh e de n ao exigir que os
equipamentos sejam iguais e, portanto, comutadores com um n umero diferentes de portas
podem ser usados.
1.6. A Internet e a Migrac ao de Grandes Massas de Dados
A arquitetura atual da Internet imp oe diferentes desaos para a migrac ao de grandes mas-
sas de dados. A movimentac ao de grandes quantidades de dados, seja em uma unica
localidade, como uma rede interna de um centro de dados, ou entre localidades geo-
gracamente distantes apresentam limitac oes devido ` a arquitetura e protocolos atuais da
(a) Topologia incompleta. (b) Topologia completa.
Figura 1.13. A topologia Jellysh com conex ao aleat oria.
Internet. Em um sistema de comunicac ao interno a um centro de dados, o TCP apre-
senta diferentes obst aculos a grandes transmiss oes de dados. No cen ario distribudo,
muito frequentemente diferentes parceiros precisam reunir massas de dados que est ao
globalmente distribudas. Por exemplo, colaboradores em uma nuvem computacional
com m ultiplos centros de dados podem precisar mover dados da ordem de alguns Teraby-
tes para um unico centro de dados [Cho e Gupta, 2011], com as mais diversas nalidades
como por exemplo consolidac ao de dados cientcos. Assim, podem-se dividir o escopo
das limitac oes da Internet para a migrac ao de grandes massas de dados em cen arios inter-
nos a um centro de dados (intra-datacenter) e cen arios de comunicac ao entre centros de
dados (inter-datacenters).
1.6.1. Cen arios de sistema de comunicac ao interno a um centro de dados
O processamento e armazenamento de grandes quantidades de dados de forma escal avel
requer um processamento distribudo em um aglomerado (cluster) ou uma rede de centro
de dados. Ap os o processamento pelos servidores, os resultados s ao enviados para um
unico servidor agregador atrav es de m ultiplas conex oes TCP. Essas conex oes comparti-
lham o mesmo buffer do comutador de topo de bastidor (Top of Rack) no qual o agregador
est a conectado.
`
A medida que o n umero de servidores cresce, a capacidade do buffer
se esgotar a e o comutador comecar a a descartar pacotes. Em algumas aplicac oes, como
o Map Reduce, o n o remetente n ao poder a enviar um novo bloco de dados at e que os
blocos de todos outros servidores tenham sido transmitidos com sucesso. Como no TCP
um remetente precisa esperar uma temporizac ao ou tr es ACKs duplicados para reenviar
os pacotes perdidos, todos os outros remetentes estar ao bloqueados e n ao poder ao enviar
novos blocos, degradando o desempenho geral da aplicac ao. Muito esforco e atualmente
empregado para contornar essas limitac oes do TCP [Zhang et al., 2011]. Uma soluc ao e
evitar temporizac oes no TCP. O TCP possui um valor mnimo de temporizac ao (RTO
min
)
de 200ms, mas a lat encia emenlaces de centros de dados pode ser da ordemde centenas de
microssegundos. Assim, a espera de temporizac ao pode provocar uma reduc ao de desem-
penho severa. Para evitar temporizac oes Phanishayee et al. [Phanishayee et al., 2008]
prop oem a reduc ao do limiar de ACKs duplicados de 3 para 1. Al em disso, a fase de
partida lenta (slow-start) do TCP e desativada. Uma outra soluc ao, proposta por Vasude-
van et al., e a reduc ao da granularidade do RTO
min
de milissegundos para microssegun-
dos. Outros trabalhos prop oem a mudanca no esquema de controle de congestionamento.
Alizadeh et al. [Alizadeh et al., 2010] emprega noticac ao de congestionamento explcita
(ECN - Explicit Congestion Notication) na qual os comutadores da rede marcam pacotes
quando detectam congestionamento. Nesse trabalho e proposto um esquema de controle
no qual os remetentes reagem ` as marcas ECN pela reduc ao da janela de congestionamento
de acordo com a frac ao de marcas recebidas. Wu et al. [Wu et al., 2010] prop oem um con-
trole de congestionamento executado pelo receptor, ao inv es de deixar essa func ao para os
remetentes como feito pelo TCP padr ao. Para isso, nesse trabalho e utilizado o controle
de taxa padr ao do TCP, no qual o receptor pode ajustar a m axima janela de congestiona-
mento permitida para o remetente. Assim, o receptor ajusta a janela de congestionamento
de todos os remetentes baseado na informac ao da banda disponvel.
Outro desao relacionado ao TCP em redes locais de centro de dados diz respeito
` a lat encia. O TCP foi projetado para fornecer o envio ordenado de dados, conabili-
dade dos dados e controle de congestionamento. Todas as conex oes TCP que dividem
um enlace de gargalo da rede reagem ao congestionamento de forma que cada uma das
conex oes obtenha uma parcela justa da banda passante disponvel naquele enlace. Por
outro lado, muitas aplicac oes de centros de dados tem na lat encia o principal requisito de
desempenho, uma vez que nestas aplicac oes o usu ario espera respostas do sistema quase
em tempo real. Aplicac oes de redes sociais como o Facebook pertencem a esta categoria.
Para estas aplicac oes de tempo quase real, se um uxo enviado na rede n ao completar
antes de um prazo m aximo, todo o uxo de rede foi desperdicado, porque a resposta ao
usu ario n ao chegou a tempo. O TCP n ao foi projetado para transportar estes uxos com
prazo m aximo, e propostas como o D
3
, descrito na Sec ao 1.7.2, tentam preencher esta
lacuna.
1.6.2. Cen arios de sistema de comunicac ao entre centros de dados
No contexto de aplicac oes distribudas que lidam com grandes massas de dados, a arqui-
tetura atual da Internet apresenta diferentes desaos para a movimentac ao de dados. A
Internet e composta por em torno de 60.000 sistemas aut onomos [BGP Reports, 2012], in-
terconectados em uma topologia de livre-escala [Barabasi e Bonabeau, 2003]. Enlaces de
longa dist ancia s ao frequentemente os mais caros nanceiramente e, como consequ encia,
a banda passante e normalmente mais escassa considerando este tipo de enlace que nas re-
des locais. Outra caracterstica inevit avel dos enlaces de longa dist ancia e, naturalmente,
maior lat encia.
Propostas como o Netsticher, descrita mais ` a frente na Sec ao 1.8.1, tentam orga-
nizar as grandes transfer encias de dados no eixo do tempo. A observac ao motivadora e
que, como uma consequ encia dos hor arios de trabalho das pessoas, os enlaces de longa
dist ancia apresentam utilizac ao da banda passante que e heterog enea ao longo do dia. Es-
tes enlaces podem apresentar nada passante inutilizada, por exemplo, de 2:00 ` as 06:30
da manh a. Essas oportunidades de transmiss ao podem ser usadas para transferir grandes
massas de dados. Por exemplo, o procedimento de backup de um grande banco de dados
pode ser realizado atrav es da divis ao dos dados em pedacos e sua transmiss ao de acordo
com as oportunidades de transmiss ao que ocorram. Al em disso, os pedacos dos dados
podem ser armazenados em n os intermedi arios para aguardar a pr oxima oportunidade de
transmiss ao. O Netstitcher e um sistema que realiza o agendamento das transmiss oes para
aproveitar a banda passante de sobra.
Outros tipos de soluc oes propostas na literatura levam em considerac ao o custo
nanceiro para decidir que m etodos de transmiss ao de informac ao ser ao utilizados para
transmitir as massas de dados. Um exemplo e o sistema Pandora (People and Networks
Moving Data Around) [Cho e Gupta, 2011], em uma traduc ao livre, pessoas e redes mo-
vimentando dados. O Pandora considera como meios de transmiss ao de dados a Internet
e o envio de discos rgidos por empresas de entrega expressa. O custo de envio mnimo
e a m etrica de desempenho utilizada como objetivo. J a os dados de entrada s ao os cus-
tos de transmiss ao de dados pela Internet, que dependem do tipo de conex ao, enlaces de
longa dist ancia, etc., os custos de envio utilizando diferentes servicos de empresas como
os correios. Al em disso o tempo de envio tamb em e contabilizado. Este depende do tipo
de servico escolhido no caso de envio de discos pelo correio, ou das taxas de transmiss ao
no caso de envio pela Internet.
1.7. Soluc oes para a Migrac ao dentro de um Centro de Dados
Um grande n umero de estrat egias foram propostas na literatura para enfrentar os desa-
os que surgem como consequ encia das grandes massas de dados e, de maneira mais
geral, quando o cen ario de rede envolve centros de dados. Nesta sec ao, s ao apresenta-
das soluc oes de sistemas de comunicac ao que tratam diferentes problemas deste tipo de
cen ario, focando o problema de qualidade de servico intra centro de dados (intra datacen-
ter). Para cada uma das soluc oes, primeiro e apresentado o problema tratado e em seguida
seu funcionamento. Embora o objetivo neste trabalho n ao seja reunir todas as soluc oes
em um mesmo arcabouco, estas soluc oes ilustram os diferentes problemas que podem ser
encontrados em redes de centros de dados.
1.7.1. Enlaces multi-gigabit para aumentar a capacidade de centros de dados
Halperin et al. [Halperin et al., 2011] prop oem uma arquitetura hbrida misturando enla-
ces cabeados e sem o para melhorar o desempenho da rede. A adic ao de alguns poucos
enlaces sem o denominados yways pode aliviar pontos com alta carga (hotspots) e
aumentar o desempenho das aplicac oes. Nessa arquitetura hbrida, a rede cabeada pode
ser uma arquitetura tpica de centros de dados ou uma das novas arquiteturas que eli-
minam o problema de sobreinscric ao, tais como [Al-Fares et al., 2008, Guo et al., 2009,
Greenberg et al., 2009]. Al em disso, esta rede cabeada pode ser provisionada para uma
carga m edia. Na parte sem o, cada comutador topo de bastidor (ToR) e equipado com um
ou mais dispositivos que trabalham a 60 GHz, com antenas direcionadas eletronicamente.
Atrav es do uso de antenas direcionais, os enlaces de 60 GHz podem prover suporte a taxas
de v arios Gb/s a dist ancias de v arios metros.
O objetivo dessa arquitetura e congurar os enlaces yways e o roteamento para
melhorar o tempo necess ario para satisfazer demandas de tr afego. A arquitetura possui
tr es tarefas principais: medir e estimar demandas de tr afego, decidir quais yways ins-
tanciar e realizar mudancas no roteamento para enviar tr afego atrav es dos yways. Um
controlador central monitora padr oes de tr afegos de centros de dados e comuta os fei-
(a) Sem yway. (b) Com um yway de C para B (enlace ponti-
lhado).
Figura 1.14. Exemplo de yway.
xes dos dispositivos sem o para estabelecer yways entre comutadores topo de bastidor
que proveem banda passante adicional quando necess ario. Um mecanismo de tr afego
de tr ansito indireto e utilizado para aumentar o desempenho. O algoritmo proposto pe-
los autores para selecionar os yways a serem instanciados escolhe o que desvia a maior
quantidade de tr afego de um enlace de gargalo. Isso resulta em utilizar yways entre
n os que estejam pr oximos e que tenham alta capacidade. Ao permitir tr afego em tr ansito,
garante-se que qualquer yway que possa descarregar tr afego de umenlace de gargalo ser a
util, mesmo que esse enlace n ao seja entre o par straggler, isto e, o par ToR que envia
a maior quantidade de tr afego no enlace de gargalo e termina a comunicac ao por ultimo.
Mais informac oes sobre o algoritmo podem ser obtidas em [Halperin et al., 2011]. A Fi-
gura 1.14 ilustra um exemplo de uso de yways. S ao mostrados seis comutadores topo
de bastidor, A, C, D, E, F e G, que possuem tr afego para o comutador topo de bastidor
B. O comutador A possui 100 unidades de tr afego para enviar enquanto os comutadores
de C a G possuem 80 unidades cada, em um total de 500 unidades a serem enviadas para
B. A capacidade de entrada e de sada dos enlaces cabeados dos comutadores topo de
bastidor e de 10 unidades/s. O enlace de descida (downlink) para B e o gargalo, pois
por ele devem passar as 500 unidades e s ao necess arios 50 s para que B receba todas as
unidades (Figura 1.14(a)). Se um yway est a habilitado de C para B (enlace pontilhado
na Figura 1.14(b)) com capacidade de 6 unidades/s, as unidades de C s ao enviadas dire-
tamente a B, deixando de ocupar o enlace de gargalo. Essa comunicac ao duraria 13,3 s,
por em as outras 420 unidades ainda seriam enviadas pelo enlace de gargalo, com durac ao
da comunicac ao de 42 s. Ao permitir o tr afego de tr ansito, unidades de outras fontes al em
de C podem usar o yway. Neste caso, aplicando-se o algoritmo dos autores, o tempo para
completar as comunicac oes seria reduzido a 312/10 = 188/6 = 31, 2 s, correspondendo
aos envios de 312 unidades no enlace cabeado para B e de 188 unidades no yway.
Um mecanismo simples roteia tr afego atrav es de potenciais m ultiplos caminhos
que s ao realiz aveis com yways. Os yways s ao tratados como enlaces ponto-a-ponto.
Cada caminho no yway transita por exatamente um enlace, logo o tudo que roteamento
precisa fazer e encapsular os pacotes para o endereco da interface apropriada. Por exem-
plo, na Figura 1.14(b), para enviar tr afego atrav es de A-Agregac ao-C-B, os hospedeiros
ligados a A encapsulam pacotes com o endereco da interface yway de C para B. Um
controlador de yways calcula a frac ao do tr afego que deve passar em cada caminho e
retransmite essas decis oes aos hospedeiros. Ao mudar o estabelecimento de um yway, o
encapsulamento e desabilitado e as rotas anteriormente adicionadas s ao removidas.
1.7.2. Deadline-Driven Delivery control protocol (D
3
)
Wilson et al. [Wilson et al., 2011] prop oem o protocolo de controle de envio orientado
a prazo m aximo (Deadline-Driven Delivery control protocol D
3
), um protocolo de ca-
mada de transporte projetado especialmente para redes de comunicac ao internas de cen-
tros de dados. A motivac ao principal do D
3
se deve ao fato de muitas das aplicac oes
de centros de dados requerem um prazo m aximo para a transfer encia de um uxo e a
transfer encia n ao ser necess aria se o prazo n ao for atendido. Por outro lado, protocolos
de transporte tradicionais da Internet n ao levam a vari avel tempo em considerac ao, em
outras palavras, n ao prov eem garantias de tempo m aximo para que um uxo seja enviado.
O protocolo TCP se preocupa, por outro lado, com a transfer encia con avel dos dados e
com o compartilhamento justo da banda passante disponvel nos enlaces de gargalo entre
os uxos TCP dividindo este enlace.
Muitas das aplicac oes atuais de centros de dados pertencem ` a categoria chamada
de aplicac oes de interac ao direta com o usu ario (user-facing applications), ou aplicac oes
de tempo quase-real: os usu arios esperam que a resposta do sistema chegue dentro de
um limite de tempo razo avel, se a resposta do sistema chegar tarde demais, ela e in util
e os recursos da rede e de processamento utilizados para transmitir esta resposta foram
desperdicados. Exemplos destas aplicac oes interativas incluem mecanismos de busca na
web, redes sociais e sistemas de recomendac ao, apenas para citar alguns. Muitas destas
aplicac oes de centros de dados tornam-se escal aveis atrav es do particionamento da tarefa
de responder ` a requisic ao do usu ario entre m ultiplos servidores. Os servidores s ao in-
terconectados atrav es de m aquinas agregadoras, hierarquicamente organizadas, que s ao
respons aveis por combinar os resultados das subtarefas realizadas pelos servidores em
uma resposta a ser enviada ao usu ario. Como consequ encia, para chegar a um tempo de
resposta m aximo visto pelo usu ario, podem ser denidos tempos m aximos para as subta-
refas realizadas pelos servidores, pelos agregadores, e para a transmiss ao da informac ao
entre eles. Outra hip otese importante feita no projeto do D
3
e que uma rede de centro de
dados pertence a uma unica organizac ao, o que signica que o compartilhamento justo da
banda passante, assim como quest oes de seguranca, s ao de menor prioridade, alargando o
espectro de soluc oes possveis para o controle de uxo na camada de transporte.
A ideia b asica do D
3
e transportar tantos uxos de rede quantos forem possveis,
ao mesmo tempo em que o prazo m aximo de cada um deles e garantido. Para garantir
que o prazo m aximo de um uxo seja respeitado, e preciso conhecer o prazo m aximo
do uxo (d) e o tamanho dos uxos (s), por exemplo em bytes. Assim, uma primeira
aproximac ao para garantir o prazo m aximo d e reservar uma taxa de transmiss ao r =
s/d em todos os roteadores ao longo do caminho entre a fonte e o destino. No entanto,
reservar banda passante por uxo nos roteadores possui a desvantagem da quantidade de
estado armazenado na mem oria dos roteadores, o que n ao e escal avel. Os autores do D
3
evitam reservas explcitas observando que uxos de redes de centros de dados possuem
prazos m aximos para completar, mas n ao precisam de uma taxa constante de envio de bits
durante toda sua durac ao. Assim, o D
3
se baseia nos emissores do uxo requisitando e
armazenando as taxas de transmiss ao reservadas com sucesso nos roteadores, em vez de
os roteadores armazenarem esta informac ao. Os roteadores apenas precisam armazenar a
quantidade de uxos com prazo m aximo e a quantidade total de banda passante reservada.
Para acomodar a din amica gerada uma vez que os uxos de rede podem comecar em
instantes diferentes de tempo, as reservas s ao v alidas apenas durante uma janela de tempo,
que no caso da implementac ao do D
3
e igual a um tempo de ida e volta (RTT - round-trip
time).
O algoritmo de controle de taxa do D
3
funciona da seguinte forma. Ao iniciar
um uxo com prazo m aximo, as aplicac oes informam o tamanho e o prazo m aximo do
uxo ao D
3
. A estac ao fonte usa essa informac ao para requisitar inicialmente uma taxa de
envio r = s/d. Esta taxa inicial desejada e encaminhada pelos roteadores na direc ao da
estac ao de destino. Cada roteador ao longo do caminho informa a taxa alocada com su-
cesso de volta para a estac ao fonte, usando o caminho reverso. Assim, a fonte obt em uma
lista das taxas que podem ser alocadas por cada um dos roteadores ao longo do caminho
para o destino, e assim pode concluir qual taxa de envio pode ser utilizada durante aquela
janela de tempo (igual a um RTT). Logicamente, a taxa de envio possvel e a menor das
taxas de envio possveis em todos os roteadores. Como consequ encia, durante o pr oximo
RTT a fonte envia dados a esta taxa e aproveita um dos pacotes de dados para enviar junto
o pedido de taxa de transmiss ao para a pr oxima rodada. A cada RTT, a fonte continua
requisitando taxas de envio aos roteadores, at e que todo o uxo de prazo m aximo tenha
sido transmitido.
Os roteadores tentam alocar, no mnimo, a taxa de transmiss ao requisitada pela
fonte emcada rodada, de forma que os uxos completemo mais r apido possvel. Por outro
lado, se h a banda passante de sobra, o roteador aloca uma taxa para o uxo igual a a =
r+ f s para o uxo de prazo m aximo, onde r e a taxa de transmiss ao atualmente requisitada
e f s e a uma parcela da banda passante de sobra, igual ` a banda passante de sobra dividida
pelo n umero de uxos passando pelo roteador, ou seja, a parcela justa da banda passante
disponvel. Por outro lado, se o roteador n ao tem capacidade disponvel sequer para
satisfazer as demandas de todos os uxos de prazo m aximo, o algoritmo guloso tenta
satisfazer tantos uxos quanto for possvel. Fluxos com prazo m aximo e uxos regulares
que n ao poder ao ser satisfeitos t em, no entanto, atribuda a eles uma taxa de transmiss ao
b asica que permite que eles enviem um pacote de dados a cada RTT, dando-lhes uma
chance de conseguir alocar uma taxa de transmiss ao ao longo do caminho, na pr oxima
rodada. Assim, diminui-se a probabilidade de que estes uxos terminem por inanic ao.
A principal inovac ao do protocolo de transporte D
3
e o algoritmo de alocac ao de
taxas de transmiss ao projetado para garantir que o prazo m aximo dos uxos de rede seja
respeitado. No entanto, o D
3
tamb em fornece o envio de dados con avel e em ordem,
baseando-se em n umeros de sequ encia, reconhecimentos, retransmiss oes baseadas em
temporizadores e algoritmos de controle de uxo, de forma similar ao TCP.
1.7.3. Centros de dados preditivos
Uma das consequ encias diretas do manuseio de grandes massas de dados e o aumento da
complexidade nas operac oes de gerenciamento de redes, tanto no caso de comunicac oes
internas a um centro de dados como entre centros de dados. A n ao ser que o cliente
aceite pagar valores extremamente altos para terem servicos de comunicac ao dedica-
dos [Amazon, 2011], normalmente a soluc ao adotada pelos operadores de centros de
dados consiste em implementar, na pr atica, a t ecnica de sobreinscric ao conforme apresen-
tado na Sec ao 1.5. Nessa t ecnica, os operadores aceitam mais clientes do que o m aximo
nominal do sistema, esperando que os picos de utilizac ao individuais n ao acontecam ao
mesmo tempo. Operadores utilizam c alculos estatsticos de forma a prover o servico pro-
metido aos usu arios e melhorar a utilizac ao dos recursos da rede.
Agrande diculdade dos operadores e o balanceamento entre eci encia e sobreinscric ao.
O gerenciamento do espaco reservado aos clientes se torna uma tarefa complexa quando
o n umero de clientes aumenta de forma signicativa. Dois aspectos inuenciam a qua-
lidade do servico oferecido aos clientes. Em primeiro lugar, como os clientes dividem o
mesmo substrato fsico, os tr afegos de dados gerados pelos diferentes clientes interferem
entre eles, principalmente durante momentos em que esses tr afegos atingem seus valores
m aximos. Em segundo lugar, os clientes n ao t em controle sobre o posicionamento de suas
m aquinas virtuais respectivas. Como resultado, nem os clientes, nem os operadores s ao
totalmente satisfeitos.
A principal ideia dos centros de dados preditivos e de aprimorar a interface entre
os clientes e os provedores de forma a facilitar o gerenciamento dos recursos disponveis
levando-se em conta os desejos de ambas as partes [Ballani et al., 2011]. Na pr atica, os
clientes n ao t em a oportunidade de informar o provedor sobre suas exig encias em termos
de recursos de rede. Essa falta de interac ao e uma das principais causas da variabilidade
da qualidade de servico. Ora, se essa exig encia for explicitamente exposta ao provedor,
este ultimo pode mais facilmente e ecientemente atender seus clientes. Os autores desse
trabalho prop oem o uso de redes virtuais como soluc ao de base e que os clientes espe-
ciquem o n umero e o tipo de m aquinas virtuais, al em de explicitamente denirem a
topologia da rede. Para tal, dois tipos de abstrac oes de topologia de rede s ao propostos,
adotadas em func ao do padr ao de tr afego gerado pelo cliente:
Clusters virtuais. Esta abstrac ao pretende simular redes do tipo usadas em empre-
sas, nas quais os n os s ao conectados por interm edio de uma rede do tipo estrela
(com comutadores Ethernet). A Figura 1.15 ilustra esse tipo de abstrac ao.
Clusters virtuais sobreinscritos. Muitas aplicac oes do tipo em nuvem n ao preci-
sam de uma rede estrita e aceitam uma certa forma de exibilidade com relac ao
a qualidade do servico fornecido. A segunda abstrac ao proposta visa esse tipo de
situac ao, como ilustrado na Figura 1.16.
Os autores prop oem um sistema, chamado Oktopus, que implementa as abstrac oes
acima explicitadas. Neste sistema, os clientes denem os par ametros desejados caso quei-
ram adotar uma das abstrac oes; caso contr ario, n ao precisam denir nada e recebem um
servico do tipo melhor esforco (best effort). Oktopus se baseia em dois componentes que
s ao o plano de gerenciamento e o plano de dados. Enquanto o plano de gerenciamento e
respons avel principalmente pela implementac ao dos algortmos de alocac ao de recursos,
o plano de dados controla a utilizac ao dos recursos por parte dos clientes.
Atrav es de simulac oes e avaliac oes em ambientes reais, os autores mostram que
as abstrac oes propostas s ao sucientes para representar a maioria dos padr oes de uso em
situac oes reais al em de facilitarem outras funcionalidades como a tarifac ao individual dos
clientes.
comutador virtual
maquina
virtual
1
maquina
virtual
2

maquina
virtual
N

Figura 1.15. Abstrac ao do tipo cluster virtual representando uma rede de em-
presa. Neste caso, o cliente pede < N, >, onde N e o n umero de m aquinas
virtuais e e a banda passante entre cada m aquina virtual e o comutador.
1.7.4. Orchestra
Como muitas aplicac oes de aglomerados transferem grandes quantidades de dados en-
tre seus est agios de computac ao, essas transfer encias podem ter um impacto signicativo
no desempenho dos jobs. Chowdhury et al. [Chowdhury et al., 2011] argumentam que
para maximizar o desempenho dos jobs, e necess ario otimizar o desempenho ao nvel
de transfer encias, ao inv es de ao nvel de uxos individuais. Para atacar esse problema,
eles prop oem uma arquitetura de gerenciamento global e um conjunto de algoritmos de-
nominados Orchestra para otimizar o desempenho das transfer encias de dados. Eles
denem uma transfer encia como um conjunto de todos os uxos que transportam dados
entre dois est agios de um job. A Orchestra diminui o tempo de transfer encia de padr oes
de comunicac ao comuns, tais como a difus ao (um-para-muitos) e o padr ao muitos-para-
muitos (shufe), e permite o uso de polticas de escalonamento ao nvel de transfer encias,
tais como o estabelecimento de prioridades para transfer encias.
A Orchestra gerencia transfer encias concorrentes que pertencem a um ou mais
jobs usando um controlador inter-transfer encias (Inter-Transfer Controller - ITC). O ITC
pode reduzir o tempo m edio de transfer encia em um workload de m ultiplas transfer encias,
comparado comquando uxos de transfer encias arbitrariamente compartilhama rede. Por
exemplo, o ITC pode priorizar transfer encias de consultas ad hoc ao inv es de jobs em ba-
telada. O ITC gerencia m ultiplos controladores de transfer encias (Transfers Controllers
- TCs), um para cada transfer encia no aglomerado. Os TCs selecionam o mecanismo a
ser usado para as suas transfer encias baseados no tamanho dos dados, no n umero de n os
da transfer encia, nas suas localizac oes e em outros fatores. Eles tamb em ativamente mo-
nitoram e controlam os n os que participam de uma transfer encia. Os TCs gerenciam a
transfer encia na granularidade dos uxos, atrav es da escolha de quantos uxos concor-
rentes devem ser abertos para cada n o, quais destinos devem receber os uxos e quando
deve-se mover cada pedaco de dados. O ITC usa um compartilhamento justo ponderado
(weighted fair sharing) como poltica de escalonamento. A cada transfer encia e associ-
ado um peso e cada enlace congestionado na rede e compartilhado proporcionalmente ao
comutador virtual raiz
maquina
virtual
1
maquina
virtual
2

maquina
virtual
S

maquina
virtual
1
maquina
virtual
2

maquina
virtual
S

maquina
virtual
1
maquina
virtual
2

maquina
virtual
S

S
O
grupo 1 grupo 2 grupo
N
S
comutador virtual
de grupo comutador virtual
de grupo
comutador virtual
de grupo
S
O
S
O
Figura 1.16. Abstrac ao do tipo cluster virtual sobreinscrito usada no caso de
reservas de recursos de redes com sobreinscric ao. Clientes pedem <N, , S, O>,
onde N e o n umero de m aquinas virtuais e e a banda passante entra cada
m aquina virtual e o grupo de comutadores virtuais, S e o n umero de grupos e O
e o fator de sobreinscric ao.
peso das transfer encias que passam por aquele enlace. Quando uma aplicac ao quer reali-
zar uma transfer encia, ela invoca uma API que lanca um TC para aquela transfer encia. O
TC se registra no ITC para obter sua parte no compartilhamento da rede. O ITC periodica-
mente consulta uma poltica de escalonamento para associar fatias no compartilhamento
` as transfer encias ativas e envia essas fatias aos TCs. Cada TC pode dividir sua parte en-
tre seus pares fonte-destino como quiser. O ITC tamb em atualiza o compartilhamento
de transfer encias periodicamente em func ao de mudancas no conjunto de transfer encias
ativas. Finalmente, cada TC solicita a eliminac ao do registro quando a sua transfer encia
acaba.
Adifus ao corresponde ao padr ao de comunicac ao um-para-muitos entre sequ encias
de est agios de processamento. Para transfer encias em difus ao, os autores prop oem um TC
que implementa um protocolo otimizado parecido com o BitTorrent denominado Cornet.
Esse protocolo inclui um algoritmo de agrupamento adaptativo de forma a tirar vanta-
gem da alta velocidade e da baixa lat encia nas tpicas topologias de centros de dados, da
aus encia de pares egostas e do fato de n ao haver n os maliciosos que podem modicar os
dados. Diferentemente do BitTorrent, n ao existe subdivis ao em blocos e grandes blocos
(4 MB por padr ao) s ao utilizados, cada n o usa sua capacidade total durante todo o tempo
da transfer encia e e realizada uma unica vericac ao da integridade sobre os dados.
Para as transfer encias do padr ao muitos-para-muitos, os autores prop oem um
algoritmo otimo denominado WSS (Weighted Shufe Scheduling). Considerando uma
comunicac ao muitos-para-muitos na qual um receptor r
i
precisa obter d
i j
unidades de da-
dos do transmissor s
j
, o WSS aloca taxas para cada uxo usando o compartilhamento
justo ponderado, de forma que o peso do uxo entre r
i
e s
j
seja proporcional a d
i j
.
A Orchestra pode ser implementada em nvel de aplicac ao e sobreposta acima
de diversas topologias de roteamento, esquemas de controle de acesso e camadas de
virtualizac ao. Essa abordagem permite ` a Orchestra ser utilizada em aglomerados j a exis-
tentes sem a necessidade de modicac oes em roteadores e comutadores.
1.7.5. NetLord
O principal objetivo do NetLord [Mudigonda et al., 2011] e reduzir a carga de gerenci-
amento em centros de dados de pequenas e m edias empresas. O NetLord simplica as
tarefas de gerenciamento atrav es do uso da infraestrutura em nuvem ao inv es do uso de
uma infraestrutura local em uma empresa. Como consequ encia, e possvel evitar despe-
sas de gerenciamento relacionadas a grandes tarefas computacionais ou relacionadas ` a
manutenc ao de grande estrutura de equipamentos e de funcion arios de rede. Ao trans-
ferir os servicos do centro de dados para a nuvem, as despesas s ao reduzidas porque os
provedores do servico podem otimizar o uso dos pr oprios recursos atrav es dos m ultiplos
clientes. Essa otimizac ao e atingida com a virtualizac ao do substrato fsico usando hi-
pervisores como o Xen [Egi et al., 2007]. Assim, o uso de m ultiplas m aquinas virtuais
leva ao compartilhamento do substrato fsico, o que evita a subutilizac ao dos recursos.
O benefcio da reduc ao dos custos se torna mais evidente caso haja um grande n umero
de clientes compartilhando a mesma infraestrutura fsica. Entretanto, o gerenciamento
da nuvem e complexo e ferramentas automatizadas para congurac ao e operac ao devem
ser propostas. O maior desao torna-se gerenciar o compartilhamento dos recursos e,
ao mesmo tempo, garantir qualidade de servico em grandes escalas. Nessa direc ao, o
NetLord tem por objetivo aprimorar os servicos em nuvem focando em tr es pilares prin-
cipais: reduc ao dos custos com a escala, aprimoramento do suporte a multiusu arios e
simplicac ao das tarefas administrativas da rede. A principal raz ao para a escolha desses
tr es pilares vem da observac ao sobre o desempenho dos centros de dados. O argumento
usado e que muito da eci encia dos centros de dados e desperdicada com congurac oes
manuais e com sobrecarga operacional desnecess aria inserida por soluc oes mal adaptadas.
A ideia chave do NetLord e utilizar o encapsulamento em quadros da camada
de enlace (Camada 2) para transfer encia de pacotes atrav es do uso de comutadores es-
cal aveis. Para isso, o NetLord usa uma combinac ao de encapsulamento em Camada 2
e 3, ou seja, ele usa respectivamente o Ethernet e o IP para combinar os benefcios de
ambas as camadas. Cada cliente deve, ent ao, ter m aquinas virtuais conguradas com
enderecos MAC, atribudos a partir de um espaco de enderecamento privado, e enderecos
IP, que n ao possuem restric oes. O encapsulamento permite a utilizac ao de um unico
endereco MAC nas m aquinas virtuais do cliente e um endereco MAC univocamente re-
lacionado na rede entre os clientes. Tal abordagem e semelhante ` a utilizada pelo LISP
(Loc/ID Split Protocol), cuja diferenca e usar enderecos de rede ao inv es de enderecos
MAC [Saucez et al., 2009].
O encapsulamento permite que todos os enderecos de m aquinas virtuais sejam
escondidos dentro de uma rede local atrav es do uso externo do endereco do comutador
de borda da rede. Esse procedimento e similar ao tunelamento, comumente utilizado
na Internet. Observe que a execuc ao de m ultiplas m aquinas virtuais levaria a tamanhos
maiores de tabelas de encaminhamento (Forwarding Information Base - FIB) porque ha-
veria um n umero maior de enderecos MAC inseridos pelas m ultiplas m aquinas virtuais.
O encapsulamento, entretanto, permite a reduc ao dos tamanhos das FIBs, que e um re-
quisito importante de escalabilidade. Um efeito indireto do encapsulamento e a reduc ao
da sobrecarga de gerenciamento da rede que diminui a complexidade de manutenc ao e
operac ao. O encapsulamento tamb em atribui benefcios ` a camada de rede atrav es do uso
de um identicador de cliente. Esse identicador e inserido no cabecalho externo da ca-
mada de rede que pode ser visto na rede entre as redes dos clientes. Esse identicador
pode ser usado para prover servicos personalizados.
Um desao acarretado pelo encapsulamento e a garantia de conectividade m-a-
m entre as m aquinas virtuais (Virtual Machines - VMs). O NetLord prop oe o uso do
Agente NetLord (NetLord Agent - NLA), em execuc ao no hipervisor da m aquina virtua-
lizada para realizar o encapsulamento e assegurar a correta entrega dos pacotes. A ac ao
do NLA durante o encaminhamento depende se o destino est a sendo executado na mesma
m aquina fsica ou n ao. Como todo cliente anuncia ao NetLord os conjuntos de enderecos
IP que possui e os enderecos MAC correspondentes, o NLA pode identicar se o destino
est a executando na mesma m aquina. Sempre que uma m aquina virtual (VM) envia um pa-
cote, o seu NLA local intercepta o pacote e extrai dele o cabecalho IP e MAC para checar
se os enderecos pertencem a algum dos seus clientes. Caso pertenca, o NLA encapsula
o pacote e o envia ao destino nal. Caso contr ario, se a busca n ao for bem sucedida e o
destino n ao estiver sendo executado na mesma m aquina fsica, o NLA deve encapsular o
pacote contendo toda a informac ao necess aria para que o NLA do destino possa identi-
car de forma unvoca a interface de rede virtual do destino. Essa informac ao e obtida a
partir de uma tupla contendo o endereco MAC do destino, o identicador do cliente do
destino e o identicador do espaco de enderecos MAC (MAC Address Space ID - MAC
AS ID) atribudo tamb em ao destino. Esses dados s ao inseridos no cabecalho do pacote,
respectivamente, no lugar do endereco MAC de destino original no cabecalho Ethernet,
no campo do endereco IP do destino e no campo do endereco IP da origem.
A Figura 1.17 ilustra o cabecalho Ethernet externo usando como os seus enderecos
MAC de origem e destino, os enderecos MAC de origem e destino dos comutadores de
borda da rede, ou seja, do comutador de borda (Edge Switch - ES) da origem e do comu-
tador de borda (Edge Switch - ES) do destino. Na mesma gura, e tamb em apresentado o
campo VLAN (Virtual Local Area Network), usado para sinalizar opc oes adicionais como
o uso de encaminhamento por m ultiplos caminhos. Ao receber o pacote, o comutador de
borda do destino desencapsula o cabecalho Ethernet externo e procura o endereco IP de
destino na sua tabela de encaminhamento para vericar se possui uma entrada correspon-
dente. Caso a encontre, as informac oes do NLA do pr oximo salto s ao obtidas e outro
cabecalho Ethernet e adicionado para garantir o encaminhamento correto do pacote at e o
NLA do destino. O NLA do destino identica o cliente baseado no cabecalho IP e pode
ainda identicar a m aquina virtual de destino ap os desencapsular completamente o pacote
recebido. Finalmente, o pacote e entregue para a interface virtual do destino.
O NLA da fonte requer informac oes sobre o endereco MAC do comutador de
borda remoto e o n umero da porta para encapsular o pacote a ser enviado. Al em disso,
ele precisa mapear a interface da m aquina virtual do destino ao comutador de borda do
destino. Para realizar essa tarefa, um protocolo semelhante ao ARP (NetLord-Address
Resolution Protocol - NL-ARP) e usado para manter uma tabela em cada hipervisor, que
e consequentemente, acessvel aos NLAs. Sempre que uma m aquina virtual desejar enviar
um pacote, a informac ao sobre o comutador de borda do destino pode estar armazenada
Figura 1.17. Procedimentos de encapsulamento e desencapsulamento utilizados
pelo NetLord durante o encaminhamento de pacotes.
em uma tabela local. Caso a informac ao n ao esteja disponvel, uma requisic ao NL-ARP
e realizada. Para evitar requisic oes sucessivas, o mapeamento entre as interfaces das
m aquinas virtuais e os comutadores de borda e mantido permanentemente ao acesso de
todos os NLAs atrav es do uso de uma estrat egia pr o-ativa. Sempre que um mapeamento
e alterado, essa informac ao e enviada para todos os NLAs da rede.
1.7.6. Eliminac ao de tr afego redundante
Outra forma de reduzir o custo da banda passante e atrav es da aplicac ao de t ecnicas de
eliminac ao de tr afego redundante (Trafc Redundancy Elimination - TRE). Aredund ancia
no tr afego surge dos comportamentos dos usu arios da nuvem, tais como repetidamente
baixar e distribuir o mesmo conte udo ou conte udo similar (por exemplo, texto, imagem,
vdeo etc.). Zohar et al. [Zohar et al., 2011] prop oem um novo sistema de TRE deno-
minado PACK (Predictive ACK). Diferentemente de outras soluc oes de TRE, o PACK
e baseado em uma abordagem orientada ao receptor. Com isso o transmissor n ao ne-
cessita manter de forma contnua os status dos receptores. O PACK permite ao receptor
utilizar os rec em recebidos pedacos da dados para identicar correntes de pedacos previa-
mente recebidos, as quais podem ser usadas como preditores con aveis de pedacos ainda
a serem transmitidos. Atrav es da utilizac ao de informac ao de meta-dados mantida local-
mente, o receptor envia ao transmissor as predic oes que incluem assinaturas de pedacos e
informac oes f aceis de serem vericadas dos dados a serem transmitidos. No caso de uma
correspond encia das informac oes, o transmissor dispara a operac ao de TRE.
Essa abordagem e detalhada a seguir. Quando chegam novos dados, o receptor
calcula a assinatura de cada pedaco e procura uma correspond encia com os dados arma-
zenados localmente. Se uma correspondente assinatura de pedaco e encontrada, o recep-
tor determina se ela e parte de uma sequ encia anteriormente recebida de pedacos sub-
sequentes, denominada uma corrente, atrav es da vericac ao dos meta-dados do pedaco
que incluem a assinatura do pedaco e um ponteiro para o pedaco sucessivo na ultima cor-
rente recebida que cont em aquele pedaco. Usando a corrente construda, o receptor envia
a predic ao ao transmissor relativa aos dados subsequentes. Parte de cada predic ao de
pedaco, denominado um palpite (hint), e uma func ao f acil de ser calculada com um valor
pequeno o suciente de falsos positivos, tal como uma soma de vericac ao (checksum)
dos dados usando um ou-exclusivo byte-a-byte. A predic ao enviada ao transmissor inclui
o intervalo dos dados preditos, o palpite e a assinatura daquele pedaco. O transmissor
identica o intervalo predito em seu buffer de dados e verica o palpite para aquele in-
tervalo. Se o resultado corresponde ao palpite recebido, o transmissor realiza a operac ao
SHA-1 ((Secure Hash Algorithm) mais intensiva computacionalmente e a compara ` a as-
sinatura recebida na predic ao. Se h a uma correspond encia das assinaturas, o transmissor
envia uma mensagem de conrmac ao ao receptor, permitindo a ele copiar os dados cor-
respondentes de seu armazenamento local.
Al em da operac ao orientada a receptor, os autores tamb em prop oem o uso de
uma abordagem orientada a transmissor em alguns casos. Usando a abordagem baseada
no receptor, quando os dados s ao espalhados, as sequ encias de predic oes s ao frequen-
temente interrompidas at e que uma nova correspond encia seja encontrada no receptor e
comunicada ao transmissor. Esse tipo de dados torna o modo de TRE menos eciente.
Permitindo ao PACK reconhecer uma sequ encia de mudancas dispersas, ele pode esco-
lher acionar uma abordagem baseada no transmissor. Al em disso, quando um dispositivo
m ovel alimentado por bateria e usado, o PACK pode deslocar a sobrecarga de computac ao
do TRE de volta para a nuvem (transmissores) atrav es do acionamento do TRE baseado
no transmissor.
1.7.7. Roteamento por m ultiplos caminhos
A tecnologia de rede tipicamente utilizada em centros de dados e o Ethernet. Suas prin-
cipais vantagens s ao o poder de auto-congurac ao, as t ecnicas para comutac ao r apida
que permitem operar em dezenas de Gb/s e o baixo custo da infraestrutura e equipe de
administrac ao da rede. Entretanto, muitas redes Ethernet operam baseadas em topologias
do tipo arvores de espalhamento (spanning tree) que concentram o tr afego nos enlaces
e comutadores selecionados. Por conseguinte, essa concentrac ao pode impactar a esca-
labilidade da rede. Uma soluc ao para melhorar o desempenho e a divis ao da rede em
sub-redes conectadas atrav es de roteadores. Essa alternativa melhora o desempenho ao
aliviar o tr afego dos possveis enlaces congestionados, especialmente se considerado que
os centros de dados podem ter milhares de m aquinas. Apesar de realmente aumentar
a escalabilidade, o uso de roteadores requer equipamentos adicionais, o que pode levar
a custos mais elevados. Outra possibilidade surge com as t ecnicas de virtualizac ao que
possivelmente precisariam de exibilidade suciente para alterar a topologia da rede sob
demanda, ou seja, atrav es da migrac ao de m aquinas virtuais de uma sub-rede para outra.
A migrac ao de m aquinas virtuais entre diferentes redes e um problema conhecido, se a
manutenc ao da topologia original for um pr e-requisito [Wang et al., 2008].
Uma abordagem para aprimorar o desempenho da Ethernet, atendendo a todos
os requisitos acima citados, e o encaminhamento por m ultiplos caminhos. Uma con-
sequ encia comum desse tipo de encaminhamento e, entretanto, a substituic ao de todos os
equipamentos de prateleira por equipamentos especiais com funcionalidades adicionais.
Essa contrapartida n ao e desej avel e deve ser contornada pelo uso de t ecnicas de rede que
possibilitem o uso dos m ultiplos caminhos em centros de dados [Mudigonda et al., 2010]
sem a necessidade de aquisic ao de novos equipamentos. O SPAIN (Smart Path Assign-
ment In Networks) [Mudigonda et al., 2010] prop oe o uso de um controlador central de
rede para calcular ofine todos os m ultiplos caminhos disponveis, e assim, melhorar a
redund ancia da rede. O objetivo e aumentar tanto a vaz ao de bissec ao quanto a toler ancia
a falhas em centros de dados. Todos os caminhos calculados s ao combinados em um con-
junto de arvores que s ao mapeadas individualmente em uma VLAN (Virtual Local Area
Networks). Como a maioria dos comutadores de prateleira prov e suporte a VLANs, esse
requisito n ao afetaria os custos da rede. O controlador central do SPAIN deve aprender
a topologia atual e congurar individualmente as VLANS calculadas em seus respectivos
comutadores. O conhecimento da topologia e obtido utilizando o protocolo LLDP (Link-
Layer Discovery Protocol) enquanto a congurac ao dos comutadores e obtida atrav es do
controlador central que programa as VLANs em cada comutador.
Figura 1.18. M ultiplas arvores calculadas pelo SPAIN. Cada uma das arvores e
mapeada em uma VLAN, entre as quais a VLAN
1
cobre todos os n os.
Todas as VLANs s ao conguradas nos comutadores da rede com o objetivo de
maximizar a utilizac ao dos enlaces fsicos. Portanto, todos os servidores podem usar
as diferentes VLANs para diferentes uxos. A Figura 1.18 ilustra uma topologia sim-
ples composta de duas arvores alternativas, chamadas de VLAN
1
e VLAN
2
. No SPAIN,
pelo menos uma VLAN deve conectar todos os n os por quest oes de conabilidade e, por
padr ao, usa-se a VLAN
1
para isso. Considerando que todas as VLANs j a estejam progra-
madas no exemplo, os Servidores A e B e os Servidores C e D j a poderiam se comunicar
usando caminhos com enlaces disjuntos, o que n ao seria possvel usando a abordagem
tpica que envolve as arvores de espalhamento. O SPAIN, portanto, evita particionamen-
tos da rede em m ultiplas sub-redes IP e n ao requer nenhuma topologia em especial como
a Fat-Tree ou um Hipercubo.
Deve-se mencionar que os centros de dados virtualizados j a prov eem suporte
ao encaminhamento por m ultiplos caminhos (ex. o NetLord [Mudigonda et al., 2011]).
Logo, explorar os m ultiplos caminhos fsicos deve ser considerado nas camadas superio-
res. Esse e uma conclus ao importante especialmente ao utilizar o TCP e seu conhecido
problema de reordenac ao de pacotes. Apesar do SPAIN j a considerar essa quest ao, h a ou-
tros trabalhos mais focados na operac ao do TCP em centros de dados que empreguem en-
caminhamento por m ultiplos caminhos. O MPTCP (MultiPath TCP) [Raiciu et al., 2010,
Raiciu et al., 2011] e um exemplo que divide um unico uxo em m ultiplos subuxos en-
tre o par origem-destino da comunicac ao. Ele se baseia na possibilidade dos m ultiplos
caminhos existirem e serem descobertos pelo protocolo de roteamento da camada infe-
rior. O desao que surge e o mecanismo de controle de congestionamento, originalmente
projetado para a operac ao do TCP com apenas um uxo. O MPTCP, portanto, acopla
o mecanismo de controle de congestionamento aos m ultiplos caminhos, concentrando
tr afego nos subuxos que atravessam os caminhos menos congestionados. Globalmente,
o tr afego da rede se torna mais balanceado, o que leva ao aumento do desempenho geral.
O uso do MPTCP e denido durante o estabelecimento de conex ao, quando o
servidor anuncia ao cliente se possui ou n ao mais enderecos IP. Os m ultiplos subuxos
s ao iniciados usando diferentes enderecos IP ou, no pior caso, usando o mesmo par de
enderecos IP, mas diferentes portas. Ap os o estabelecimento dos diferentes subuxos,
o n o de origem divide os dados entre eles e utiliza opc oes adicionais do TCP para que
os dados sejam reordenados na recepc ao. Uma vez divididos em m ultiplos subbuxos,
cada um mantem o seu pr oprio espaco de n umeros de sequ encia e a sua pr opria janela de
contenc ao. Cada subuxo pode, ent ao, se adaptar individualmente ` as condic oes do ca-
minho percorrido. Assim, um subuxo que encontre congestionamentos pode ajustar os
seus pr oprios par ametros para reduzir a inserc ao de tr afego, enquanto os subuxos atra-
vessando caminhos menos congestionados podem aumentar as suas taxas de transmiss ao.
A rede, como consequ encia, melhora balanceamento de carga de forma natural.
(a) TCP original. (b) MPTCP.
Figura 1.19. Diferenc a entre o TCP que usa um unico caminho e o MPTCP com
m ultiplos caminhos. O TCP concentra carga no enlace A, enquanto o MPTCP
realiza um melhor balanceamento de carga entre os diferentes enlaces da rede.
O uso do TCP para m ultiplos caminhos pode aumentar a vaz ao agregada da rede
em centros de dados sem o comprometimento das topologias fsicas, como e necess ario
com o Fat-Tree [Al-Fares et al., 2008] ou BCube [Guo et al., 2009]. Essa caracterstica e
relevante para poupar os administradores de redes do uso de topologias xas.
1.7.8. Interconex ao do centro de dados com pontes
Duas tecnologias s ao proeminentes na interconex ao dos servidores em centros de dados, o
Ethernet e a Fibre Channel. A Ethernet e a tecnologia mais usada e continua com desem-
penho crescente de 10, para 100 e 1000 Mb/s e agora para 10, 40 e 100 Gb/s. Por outro
lado, a Fibre Channel est a em 16 Gb/s e com maiores diculdades para escalar. Assim, a
Ethernet vem se tornando cada vez mais comum e foi desenvolvido o Fibre Channel over
Ethernet (FCoE) para encapsular os quadros do Fibre Channel em quadros Ethernet. No
entanto, a tecnologia Ethernet segue o modelo de melhor esforco e e menos con avel que
a tecnologia Fibre Channel, podendo perder pacotes quando os dispositivos receptores
est ao ocupados e n ao conseguem receber na taxa que lhe e transmitida. Quando o Ether-
net e usado, de uma maneira geral, a recuperac ao de quadros perdidos e deixada para os
protocolos das camadas superiores, na Internet, por exemplo, as perdas s ao recuperadas
pelo TCP. No entanto, nos centros de dados, deixar a recuperac ao dos quadros perdidos
para o TCP n ao e conveniente, por causa do seu baixo desempenho devido ` a complexi-
dade e ao grande custo operacional. Pode-se dizer que e mais r apido e melhor reagir a
congestionamentos e recuperar perdas de pacotes na camada de enlace do que esperar
para faz e-lo na camada de transporte pelo TCP. No caso de centro de dados, isso se torna
crucial por causa das altas taxas.
Em decorr encia das deci encias do uso do Ethernet em centros de dados, uma
s erie de normas relativas ` a interconex ao de Centro de Dados com Pontes (Data Center
Bridging - DCB) est ao em desenvolvimento para evitar congestionamentos e eliminar as
perdas de quadros em ambiente de centros de dados. Quatro tecnologias procuram melho-
rar as propriedades da rede Ethernet: Controle de Fluxo baseado em Prioridade (Priority-
based Flow Control - PFC) [Hugh Barras et al., 2008], Selec ao Aperfeicoada de Trans-
miss ao (Enhanced Transmission Selection) [Manoj Wadekar et al., 2008b], Troca DCB
(DCB Exchange) [Manoj Wadekar et al., 2008a] e Noticac ao de Congestionamento (Con-
gestion Notication) [CN, 2009]. O Controle de Fluxo baseado em Prioridade (Priority-
based Flow Control - PFC), tamb em conhecido como PAUSA por prioridade, denido na
norma IEEE 802.1Qbb [Hugh Barras et al., 2008], e um mecanismo usado quando uma
estac ao deseja que um dado uxo de quadros recebido seja interrompido temporaria-
mente. O mecanismo PCF indica um tempo de pausa em quanta para cada uma das
oito classes de prioridade separadamente, diferente do quadro de PAUSA convencional
que inibia a transmiss ao de todos os quadros de forma indiscriminada. O PCF acrescenta
campos que permitem identicar cada classe de prioridade e, assim, selecionar qual ou
quais delas devem ser inibidas. Para tal, um quadro de pausa PCF cont em um vetor com
oito campos que inclui dois octetos de campo de habilitac ao do vetor de prioridade (pri-
ority enable vector Field) e dois octetos de campo do vetor de tempo (octet time vector
eld). O valor do tempo e medido em unidade de pause quanta que e igual a 512 vezes o
tempo do bit de uma camada fsica particular.
O mecanismo Selec ao Aperfeicoada de Transmiss ao (Enhanced Transmission Se-
lection - ETS), denido pela norma IEEE 802.1Qaz [Manoj Wadekar et al., 2008b], prove
um modelo operacional para processamento de prioridade e alocac ao de banda, em termos
de percentagem da banda total, em enlaces convergentes de comutadores e estac oes. O
mecanismo ETS introduz um novo campo de 4 bits chamado Priority Group ID (PGID).
Assim, tem-se 16 valores de PGID sendo que o valor PGID=15 e especial e signica
sem nenhum limite de banda passante e os valores 8-14 s ao reservados. Cada PGID
e alocado como um percentual da banda disponvel no enlace, onde banda disponvel se
refere ao valor m aximo percentual disponvel depois das prioridades com PGID=15 se-
rem alocadas. Portanto, usando processamento com prioridade e alocac ao de banda e
possvel a congurac ao de diferentes classes de tr afego, tais como: LAN, SAN, IPC e
gerenciamento, para prover caractersticas de transmiss ao com baixa lat encia. Para que
esses objetivos sejam atendidos os dispositivos devem suportar (i) a atribuic ao de priori-
dades em grupos de prioridades (Priority Groups), como por exemplo 40% LAN, 40%
SAN e 20% IPC de alocac ao de banda passante para cada grupo de tal forma que a prio-
Figura 1.20. Operac ao da troca DCB (DCB Exchange) com priorizac ao de tr afego
e reserva de banda.
ridade atenda a demanda por um certo comportamento; (ii) o escalonamento da ocupac ao
de um enlace para minimizar o impacto da converg encia em um unico enlace ao mesmo
tempo; (iii) a coexist encia de tr afego de baixa lat encia com tipos de tr afegos que deman-
dam alta banda passante e s ao sensveis a perda e (iv) uma plataforma de gerenciamento
para congurac ao via objetos MIB.
Na Figura 1.20, tr es classes de tr afego s ao agrupados em dois grupos distintos,
um grupo de alta prioridade e um de baixa prioridade. O tr afego IPC, de alta prioridade e
totalmente atendido, enquanto os dois tr afegos de baixa prioridade, LAN e SAN, dividem
igualmente a banda passante restante.
A Troca DCB (Data Center Bridging eXchange - DCBX), denido na norma
IEEE 802.1Qaz [Manoj Wadekar et al., 2008a], e um protocolo de descoberta de capaci-
dades que e usado para adequar capacidades e congurac oes entre n os diretamente conec-
tados por enlaces, de forma a garantir congurac oes consistentes atrav es da rede. O DCB
usa o protocolo de descoberta de enlaces (Link Layer Discovery Protocol - LLDP) para
troca par ametros. A noticac ao de congestionamento (Congestion Notication - CN),
denida na norma 802.1Qau [CN, 2009], e um mecanismo para transmitir informac ao
de congestionamento m-a-m por uxo. A nvel de enlace, um quadro de pausa traz
como consequ encia uma propagac ao de congestionamento do uxo que e pausado, pro-
vocando gargalos secund arios. Logo, um algoritmo de controle de congestionamento na
Camada 2 permite que um gargalo prim ario reduza diretamente a taxa das fontes gera-
doras do tr afego evitando gargalos secund arios. A noticac ao de congestionamento e
dividida em dois algoritmos: Congestion Point Dynamics (CP) e Reaction Point Dyna-
mics (RP).
Todos os protocolos apresentados se destinam a tornar a tecnologia Ethernet mais
con avel e praticamente sem perdas de pacotes, atendendo a exig encia de interconex ao
de centros de dados.
1.7.9. Transparent Interconnection of Lots of Links (TRILL)
O Ethernet foi originalmente projetado para ser usado em um barramento e depois em
uma topologia em estrela, com estac oes conectadas atrav es de um unico enlace restrito a
um alcance m aximo de alguns poucos quil ometros em barramento e a em estrela poucas
centenas de metros. Com o intuito de permitir a criac ao de redes maiores, tanto em al-
cance quanto no n umero de estac oes, foram criadas as pontesque encaminham quadros
Ethernet entre diferentes enlaces. No entanto, os mecanismos criados para encaminhar
quadros Ethernet atrav es de pontes, na camada de enlace, n ao t em todas as caractersticas
necess arias para o encaminhamento como ocorre no roteamento efetuado na camada di-
retamente superior, pelo protocolo IP . Os principais desaos do encaminhamento na
camada de enlace s ao a aus encia de um campo de contagem de saltos no cabecalho Ether-
net; a forma plana de enderecamento do protocolo Ethernet que, por isso, n ao reete a
localizac ao dos n os e n ao permite a agregac ao de enderecos; e a aus encia de protocolos
de descoberta de novos n os e de protocolos de roteamento em camada de enlace. Logo,
foi adotada uma maneira simples de encaminhar os quadros na camada de enlace cha-
mada comutac ao transparente. Os n os encaminhadores aprendem por qual porta uma
determinada estac ao nal e acessvel e passam a utilizar essa porta para encaminharem
tr afego para essa estac ao. No entanto, esse m etodo funciona somente quando h a apenas
um caminho entre quaisquer pares de n os nais. Assim, para permitir o funcionamento do
encaminhamento em camada de enlace para topologias arbitr arias, foi criado o algoritmo
de arvore de cobertura (spanning tree) [Touch e Perlman, 2009]. O algoritmo de arvore
de cobertura garante a formac ao de caminhos na rede sem lacos ao custo de desativar
enlaces da rede fsica, fazendo com que todo o tr afego da rede que restrito a um unico
caminho. Outra limitac ao desse algoritmo e a sua instabilidade. A perda de conectivi-
dade em um enlace pertencente ` a arvore de cobertura pode signicar o rec alculo de toda
a arvore e consequentes mudancas em toda a sua organizac ao [Touch e Perlman, 2009].
Dessa forma, o algoritmo de arvore de cobertura apresenta comportamento inst avel em
redes extensas interligadas por comutadores.
Uma proposta para realizar o encaminhamento de pacotes na camada de enlace,
com suporte a m ultiplos caminhos e sem a necessidade de se denir uma arvore de cober-
tura, e o TRILL (Transparent Interconnection of Lots of Links), um protocolo padronizado
pelo IETF (Internet Engineering Task Force) que aplica t ecnicas de roteamento da camada
de rede para criar a interconex ao de redes, na camada de enlace [Touch e Perlman, 2009,
Perlman et al., 2011]. A interconex ao dos enlaces e feita de forma transparente para o
protocolo IP. Os enlaces interconectados pelo TRILL s ao vistos pela camada de rede
como uma unica sub-rede IP. O TRILL encapsula, com um cabecalho pr oprio, os qua-
dros Ethernet a serem encaminhados. Como o quadro Ethernet e mantido inalterado, o
TRILL garante as funcionalidades da camada de enlace, como VLAN (Virtual Local Area
Network), e permite o uso de multicast e broadcast.
O TRILL permite a autocongurac ao da camada de enlace, assim como o Ether-
net, mas tamb em permite o uso de t ecnicas de roteamento como as da camada de rede.
Os equipamentos de rede que implementam o TRILL s ao chamados de Routing Bridges
ou RBridges. A ideia central de uma RBridge e agir como um comutador Ethernet para as
estac oes nais, mas que no n ucleo da rede e capaz de rotear os pacotes encapsulados pelo
TRILL como se fosse o roteamento da camada de rede. As RBriges podem coexistir com
os comutadores Ethernet. Quanto maior o n umero de RBridges em relac ao ao n umero
de comutadores Ethernet, menores s ao as arvores de cobertura denidas entre os comu-
tadores. Consequentemente, menos enlaces s ao desativados, melhorando o uso da banda
passante disponvel na rede.
O funcionamento do TRILL ocorre da seguinte forma [Perlman et al., 2011]. Ao
iniciar uma rede TRILL, as RBridges escolhem identicadores aleat orios e os divulgam.
Se um identicador escolhido j a estiver em uso por outra RBridge, um novo identica-
dor e escolhido. As RBridges executam um protocolo de roteamento de estado do enlace
que permite ` as RBridges conhecerem a topologia da rede e calcularem o caminho mais
curto entre duas RBriges. O encaminhamento dos quadros entre os n os TRILL e baseado
no cabecalho de encapsulamento que apresenta tr es campos principais. O primeiro e o
ingress RBridge que cont em o identicador da RBridge de entrada na rede TRILL. O se-
gundo e o egress RBridge que cont emo identicador da RBridge de destino do pacote. Por
m, o campo hop count guarda a contagem de saltos do pacote na rede TRILL para evitar
o encaminhamento dos pacotes em lacos. H a ainda uma marcac ao no cabecalho que iden-
tica se o pacote tem m ultiplas destinac oes ou e um pacote com destinac ao unica. Cada
RBridge est a conectada a um conjunto de estac oes nais, como se fosse um comutador
Ethernet. Quando uma estac ao nal envia um quadro Ethernet para a RBridge, esta ve-
rica a destinac ao do quadro. Caso o destino do quadro esteja associado a uma RBridge
conhecida, a RBridge que recebeu o quadro, o encapsula com o cabecalho TRILL e o
envia na rede. Caso o quadro que chega ` a RBridge tenha como destino uma estac ao as-
sociada a uma RBridge desconhecida, ou caso seja um quadro de broadcast/multicast,
marca-se o quadro com m ultiplas destinac oes e o quadro e inundado na rede. Ao chegar
na RBridge de destino, o quadro e desencapsulado, resgata-se o quadro Ethernet original
e este e entregue ` a estac ao nal de destino, de maneira transparente para as estac oes.
O protocolo de estado de enlace que executa entre as RBridges e o IS-IS (Interme-
diate System - Intermediate System). Esse protocolo e o mais adequado para o cen ario do
TRILL, pois executa diretamente na camada de enlace, ao contr ario do OSPF que executa
sobre o IP, e permite a criac ao de novos campos na divulgac ao das informac oes do enlace.
1.7.10. Distributed Overlay Virtual Ethernet (DOVE)
A tend encia atual para a organizac ao de sistemas de comunicac ao de centros de dados e
tratar os servidores virtuais como estac oes nais da rede fsica. Dessa forma, o n umero
de estac oes nais conectadas na rede do centro de dados cresce substancialmente, em
relac ao ` a interconex ao de somente servidores fsicos, aumentando a complexidade da
rede. Assim, as redes dos centros de dados necessitam de mais investimentos, aumen-
tando a quantidade de comutadores disponveis ou aumentando a capacidade dos existen-
tes, seja em termos de mem oria disponvel, seja em termos de aprendizagem de novos
enderecos MAC. Por outro lado, as cargas de trabalho dos centros de dados podem variar
dependendo de fatores externos e dos requisitos de aplicac ao que executam no centro de
dados. Hoje, a infraestrutura de rede dos centros de dados permanece est atica mesmo
com as mudancas de carga de trabalho. Portanto, da mesma forma como a virtualizac ao
de computadores permitiu o melhor compartilhamento dos recursos computacionais oci-
osos, uma proposta para melhor compartilhar a rede de centros de dados e atrav es da
virtualizac ao. O uso da virtualizac ao de redes permite criar redes virtuais independentes
das caractersticas da infraestrutura fsica, isolando umas das outras, de forma din amica,
congur avel e gerenci avel.
O Distributed Overlay Virtual Ethernet (DOVE) [Barabash et al., 2011] e uma
proposta de arquitetura de virtualizac ao de protocolos para centro de dados que prov e
isolamento entre redes virtuais, capacidade de recongurac ao din amica da rede e de ge-
renciamento da rede virtual, independentemente da infraestrutura fsica preexistente no
centro de dados. A arquitetura DOVE permite a criac ao de redes virtuais com espacos de
enderecamentos isolados e din amicas sobre uma infraestrutura fsica comum. Ofunciona-
mento do DOVE baseia-se no encapsulamento de pacotes e na criac ao de uma rede de so-
brecamada para permitir a separac ao entre a rede virtual e a rede fsica subjacente. Assim
que s ao enviados por uma m aquina virtual, os quadros Ethernet s ao tratados pelo servidor
fsico que hospeda tal m aquina virtual. O servidor fsico, ent ao, encapsula os quadros
Ethernet que deixam uma m aquina virtual em um pacote UDP, que tamb em possui um
cabecalho DOVE. Os pacotes encapsulados possuem um campo para a marcac ao de qual
rede virtual tal pacote pertence. Os pacotes encapsulados, por sua vez, s ao enderecados
ao IP do servidor fsico que hospeda a m aquina virtual de destino. No caso de pacotes de
difus ao (broadcast ou de multicast), o pacote encapsulado e enviado a todos os servidores
fsicos que hospedam m aquinas virtuais de rede virtual a que o pacote encapsulado se
destina. No servidor fsico ao qual o pacote encapsulado se destina, o quadro Ethernet
original e recuperado ap os o desencapsulamento do pacote. O encaminhamento baseado
nos cabecalhos IP e UDP mais externos garante a compatibilidade do pacote encapsulado
com a infraestrutura de rede. O encaminhamento e o roteamento dos pacotes encapsu-
lados ocorrem na infraestrutura fsica da rede, logo, as propriedades de conectividade e
seguranca da rede de sobrecamada s ao as mesmas da infraestrutura fsica.
As duas principais vantagens do DOVE s ao a separac ao dos espacos de enderecos
e a migrac ao facilitada de m aquinas virtuais. A separac ao dos espacos de enderecos
refere-se ao fato de que o tr afego de cada rede virtual s o e visvel para as estac oes nais
que pertencam ` aquela rede virtual. A separac ao das redes virtuais permite que cada uma
possa ser gerenciada individualmente. Outra vantagem e a migrac ao de m aquinas virtuais.
Como a participac ao de uma m aquina virtual a uma rede virtual depende somente da
congurac ao do sistema fsico que a hospeda, uma m aquina virtual pode ser migrada para
qualquer servidor fsico do centro de dados e mesmo assim manter a sua conectividade ` a
rede virtual bastando recongurar o servidor fsico.
1.7.11. OpenFlow
O OpenFlow [McKeown et al., 2008, Mattos et al., 2011b] permite que a infraestrutura
fsica de redes seja compartilhada pela rede de produc ao e por redes experimentais. A
ideia chave do OpenFlow e centralizar o controle da rede e simplicar a congurac ao
dos elementos de rede. O OpenFlow promove a criac ao de redes denidas por software
(Software Dened Networks - SDN), usando elementos comuns de rede, tais como comu-
tadores, roteadores, pontos de acesso ou, at e mesmo, computadores pessoais. Assim, o
OpenFlow e uma plataforma que permite congurar o encaminhamento dos pacotes com
base em denic oes de uxos nos elementos de rede. Esta enorme exibilidade oferecida
pelo OpenFlow e vantajosa para centros de dados, pois os uxos podem ser recongura-
dos de acordo com a demanda dos servidores. Um uxo e denido como um conjunto
de doze caractersticas da comunicac ao entre dois n os na rede, obtidas nos cabecalhos
das camadas de enlace, de rede e de transporte de cada pacote [McKeown et al., 2008].
Como em um comutador padr ao, o comutador OpenFlow tamb em possui uma tabela de
encaminhamento, que e chamada de tabela de uxo. As entradas nessa tabela relacio-
nam um uxo com um conjunto de ac oes denidas pelo controlador sobre cada pacote.
Quando um pacote chega ao comutador OpenFlow, o comutador verica se o pacote se
adequa a algum uxo j a existente. Em caso positivo, as ac oes denidas para aquele uxo
s ao aplicadas ao pacote. Em caso negativo, o primeiro pacote do uxo e enviado ao con-
trolador, que dene um novo uxo e determina as ac oes a serem tomadas. A Figura 1.21
mostra a organizac ao de uma rede OpenFlow e a comunicac ao dos elementos de rede com
o controlador centralizado.
Figura 1.21. Arquitetura de uma rede OpenFlow. Os comutadores OpenFlow
comunicam-se com o controlador atrav es do protocolo OpenFlow em um canal
seguro. O controlador executa as aplicac oes de controle de cada rede virtual.
O controlador e um elemento centralizado que executa aplicac oes de controle so-
bre a rede OpenFlow, congurando as tabelas de uxo dos elementos encaminhadores. O
controlador implementa o protocolo OpenFlow para se comunicar com os elementos de
rede e, atrav es desse protocolo, congura os elementos da rede. Um dos controladores
OpenFlow mais usados e o Nox [Gude et al., 2008]. O Nox age como um sistema ope-
racional de rede, provendo as func oes b asicas de congurac ao e monitoramento da rede
para as aplicac oes que controlam a rede. Dessa forma, o controlador age somente como
uma interface entre a rede e as aplicac oes. O plano de controle e exercido pelas aplicac oes
que executam sobre o Nox. Sendo assim, uma rede virtual no OpenFlow e representada
pelo seu conjunto de uxos, plano de dados, e pelas suas aplicac oes de controle, plano de
controle.
A virtualizac ao do plano de controle em redes OpenFlow e feita pelo FlowVi-
sor [Sherwood et al., 2009]. O FlowVisor e um controlador especial do OpenFlow, que
funciona de forma transparente entre os dispositivos em uma rede OpenFlow e os outros
controladores, como por exemplo o Nox. O FlowVisor permite que mais de um controla-
dor controle a rede OpenFlow, para tanto, o FlowVisor introduz o conceito de fatia. Cada
fatia de rede e controlada por um controlador e e denida por polticas no FlowVisor.
As mensagens de controle trocadas entre os dispositivos e os controladores s ao interme-
diadas pelo FlowVisor, que verica para cada mensagem, quais polticas s ao aplic aveis.
Al em disso, verica se um determinado controlador pode controlar um dado uxo em um
dispositivo.
Figura 1.22. Arquitetura do FlowVisor, um controlador especial do OpenFlow,
que permite a denic ao de redes virtuais.
O FlowVisor, como mostrado na Figura 1.22, executa a virtualizac ao do plano
de controle da rede, isolando o controle, mas compartilhando o plano de dados dos co-
mutadores da rede OpenFlow. O fatiamento da rede realizado pelo FlowVisor e focado
no compartilhamento de cinco recursos primitivos da rede [Sherwood et al., 2009]: isola-
mento de banda, descoberta de topologia, engenharia de tr afego, monitoramento de CPU
e controle das tabelas de encaminhamento. O FlowVisor executa apenas a virtualizac ao
do plano de controle, permitindo que mais de um controlador troque mensagens de con-
trole com um dispositivo OpenFlow. No entanto, cada controlador exerce o controle em
uma fatia da rede e, nessa fatia, s o um controlador exerce o controle. Dessa forma, o
FlowVisor cria ilhas de controle em uma rede OpenFlow, de forma que o controle global
da rede ca distribudo, enquanto o controle de cada fatia de rede ca centralizado em um
controlador por fatia.
O XenFlow [Mattos et al., 2011a] e uma plataforma de virtualizac ao hbrida, na
qual m aquinas virtuais Xen [Moraes et al., 2011] agem como o plano de controle de ro-
teadores e o encaminhamento e baseado no OpenFlow. O XenFlow tem como vantagem
tornar o plano de dados do Xen program avel e com isto fazer a migrac ao de enlaces de
forma mais simples, sem a necessidade de criac ao de t uneis e com perda zero de pacotes.
1.8. Soluc oes para a Migrac ao entre Diferentes Centros de Dados
Apesar da maioria das soluc oes se concentrarem nos cen arios internos aos centros de
dados, transmitir os dados atrav es de centros de dados distribudos distantes geograca-
mente e um desao ainda maior. Envolver a Internet signica herdar todas as limitac oes
dessa rede para esse tipo de aplicac ao. Esta sec ao descreve soluc oes que se dedicam
principalmente ao caso de comunicac oes entre centros de dados.
1.8.1. NetStitcher
A ideia b asica da soluc ao Netsticher [Laoutaris et al., 2011] e explorar banda passante
(periodicamente) n ao utilizada para movimentar grandes massas de dados entre cen-
tros de dados distribudos. A estrat egia do Netstitcher e combinar a transmiss ao utili-
zando m ultiplos caminhos e a t ecnica de armazenamento e encaminhamento (store-and-
forward) para mover os dados na direc ao do destino, de acordo com as oportunidades
de transmiss ao que acontecam. O Netstitcher se baseia em uma rede sobreposta, seme-
lhante ` a implementada por sistemas baseados em armazenamento e encaminhamento bem
conhecidos, como o Bit Torrent. No entanto, diferentemente destes sistemas, o Netstit-
cher leva em considerac ao a durac ao, o instante de tempo e a localizac ao das janelas de
transmiss ao.
A principal observac ao que motivou os autores a proporem o Netstitcher e que os
enlaces de longa dist ancia da rede que interconecta os centros de dados apresentam banda
passante n ao utilizada durante alguns perodos do dia, por exemplo como consequ encia
dos hor arios de jornada de trabalho das pessoas. Por outro lado, estas oportunidades de
transmiss ao podem ocorrer em diferentes instantes de tempo para os diferentes stios de
um centro de dados distribudo, como consequ encia da diferenca de fuso hor ario entre
localidades distantes. Assim, para transmitir um grande arquivo de backup da costa leste
para a costa oeste dos Estados Unidos, e possvel agendar as transfer encias de dados
para ocorrerem durante os perodos onde os enlaces de transmiss ao est ao sub-utilizados.
Utilizando a capacidade de armazenamento dos n os intermedi arios, e possvel esperar pela
pr oxima oportunidade de transmiss ao. Por outro lado, caso m ultiplos caminhos existam
e possuam banda passante disponvel, o arquivo pode ser dividido pelo Netstitcher em
pedacos e cada um transmitido utilizando um caminho diferente.
A Figura 1.23 ilustra um backup realizado entre um centro de dados localizado
em Nova Iorque (NYC) e outro localizado em Palo Alto (PAL), explorando o fato de que,
como consequ encia das jornadas de trabalho, h a banda passante de sobra nos enlaces de
longa dist ancia e, como consequ encia, oportunidades de transmiss ao. O ret angulo da Fi-
gura 1.23 representa o perodo durante o qual cada um dos centros de dados pode executar
o backup porque h a banda passante de sobra. Por exemplo, em Nova Iorque o backup e
possvel das 3:00 ` as 6:00 horas da manh a, no fuso hor ario EST (Eastern Standard Time)
enquanto que em Denver o backup pode ser realizado tamb em das 3:00 ` as 6:00 da manh a,
por em no fuso hor ario local, MST (Mountain Standard Time). Assim, gracas aos dife-
rentes fusos hor arios, as oportunidades de transmiss ao de durac ao de 3 horas podem se
sobrepor total ou parcialmente. O diagrama mostra a operac ao de uma soluc ao baseada na
t ecnica de armazenamento e encaminhamento onde foi utilizado o armazenamento tem-
por ario em cinco localidades diferentes, Boston (BOS), Chicago (CHI), Phoenix (PHO),
Denver (DEN) e Seattle (SEA). Utilizando a banda passante de sobra do enlace de sada
de Nova Iorque (NYC), tr es blocos de dados s ao transmitidos e ent ao temporariamente
armazenados em Boston (1), Chicago (2) e Denver (3). O bloco de dados armazenado em
Boston (BOS) e mais tarde transmitido para Phoenix (4), entre 5:00 e 6:00 da manh a no
hor ario local de Boston (entre 3:00 e 4:00 da manh a no fuso hor ario de Phoenix). Este
Figura 1.23. Exemplo do diagrama de tempo de uma transfer encia de
grande massa de dados usando oportunidades de transmiss ao (adaptado
de [Laoutaris et al., 2011]).
bloco de dados e depois transmitido de Phoenix para Seattle (7) e ent ao de Seattle para
Palo Alto (8). Os outros dois blocos de dados resultantes do particionamento inicial em
Nova Iorque s ao transmitidos utilizando oportunidades de transmiss ao e caminhos dife-
rentes, como ilustrado na gura.
O Netstitcher foi implementado baseado em uma rede sobreposta e um sistema
composto de quatro m odulos. O m odulo de gerenciamento da rede sobreposta e res-
pons avel pela manutenc ao da conectividade na rede sobreposta. O m odulo de predic ao
de volume e respons avel pela medic ao e/ou estimac ao da banda passante disponvel nos
enlaces e espaco de armazenamento disponvel nos n os. O m odulo de escalonamento e
respons avel por executar um algoritmo para decidir quando as transfer encias devem ocor-
rer e por quanto tempo os blocos de dados devem ser armazenados nos n os intermedi arios,
de maneira que o tempo de transfer encia do volume total de dos seja minimizado. Final-
mente, o m odulo de gerenciamento de transmiss ao e respons avel pela execuc ao propria-
mente dita das transfer encias de dados decididas pelo m odulo de escalonamento.
O m odulo de escalonamento e o principal do Netstitcher. O escalonamento e mo-
delado como umproblema de mnimo tempo de transfer encia (MTT), onde umn o v deseja
enviar um arquivo de tamanho F para um n o de destino u [Laoutaris et al., 2011]. O n o
v pode usar qualquer banda passante n ao utilizada e n os da rede sobreposta como arma-
zenamento tempor ario. O modelo divide o tempo sem slots. Tanto os recursos de banda
passante quanto os de armazenamento s ao denidos em termos da quantidade de dados
(por exemplo, em bytes) que podem ser transmitidos (respectivamente, armazenados) du-
rante um slot de tempo t. A rede e modelada atrav es de um grafo evolucion ario. Assim,
Figura 1.24. Exemplo de um grafo tradicional obtido a partir de um grafo evolucion ario.
considerando um n o v, v(1) e v(2) representam o n o v durante os slots de tempo 1 e 2, res-
pectivamente. N
vw(1)
representa o gargalo de rede, ou a banda passante disponvel, entre
os n os v e w durante o slot de tempo 1. S
w(1)
representa a capacidade de armazenamento
do n o w durante o slot de tempo 1. Expandindo o n o v em T
max
n os (v(1), . . . , v(T
max
)),
onde T
max
e o n umero m aximo de slots de tempo, o grafo evolucion ario pode ser trans-
formado em um grafo tradicional, onde N
vw(t)
representa os gargalos da rede e S
w
(t) a
capacidade de armazenamento do n o w durante o slot de tempo t. Assim, enlaces conec-
tando n os no mesmo slot de tempo (cada slot corresponde a uma linha horizontal no grafo)
representam a capacidade da rede, enquanto enlaces conectando n os localizados em slots
de tempo diferentes (enlaces verticais) representam a capacidade de armazenamento dos
n os, como mostrado na Figura 1.24.
Considerando o grafo expandido da topologia, a ideia b asica do Netstitcher e re-
solver um problema de uxo m aximo (max-ow), ou seja, encontrar uma combinac ao de
caminhos na rede e capacidades dos uxos a transmitir em cada caminho tal que a quanti-
dade de dados transmitido da fonte v(1) para o destino z(T
max
) seja m axima. O algoritmo
de Ford-Fulkerson e usado para resolver o problema de uxo m aximo. Existe, no entanto,
um problema com esta soluc ao, uma vez que o Netstitcher tem como objetivo minimizar
o tempo de transmiss ao, e n ao maximizar o uxo entre fonte e destino. Na denic ao do
problema de uxo m aximo, o tempo de transmiss ao m aximo e um dado de entrada, no
caso, igual a T
max
multiplicado pelo tamanho do slot de tempo. A soluc ao utilizada pelo
Netstitcher e executar o algoritmo de Ford-Fulkerson T
max
vezes em vez de apenas uma
vez, a cada vez, utilizando a cada vez uma topologia diferente. Cada topologia utilizada e
um sub-grafo da topologia geral, com 1, 2, . . . T
max
1 slots. Em seguida, e realizada uma
busca bin aria entre as soluc oes encontradas nas diferentes execuc oes do algoritmo para
escolher, entre as que obtiveramo uxo m aximo, a que utilizou a subtopologia commenos
Figura 1.25. Um caminh ao APC oferecendo InfraStruXure Express On-demand
Mobile Data Center.
slots de tempo, minimizando o tempo de transmiss ao como era o objetivo do Netstitcher.
1.8.2. Descarregamento de tr afego
Uma caracterstica comum ` as soluc oes apresentadas at e agora e que todas visam melho-
rias na utilizac ao dos recursos da Internet, mas ao mesmo tempo dependem da infraes-
trutura Internet para a transfer encia de dados. Recentemente, uma soluc ao alternativa
tem sido explorada: o descarregamento de tr afego (trafc ofoading). A id eia de des-
carregar o tr afego de uma rede sobre uma outra rede de forma a aliviar a primeira tem
sido proposta em v arios contextos, principalmente em relac ao ` a infrastrutura 3G que tem
sofrido com o aumento do tr afego gerados pelos smatphones. De fato, de acordo com
a Cisco, dados relacionados ` as redes m oveis aumentou cerca de 26 vezes no perodo
2010-2015 [Cisco, 2011]. Entretando, o descarregamento de tr afego pode ser aplicado
em in umeras outras situac oes.
No contexto desse minicurso, o exemplo mais interessante e o de centros de dados
m oveis (data-centers-to-go), os quais se baseiam em arquiteturas do tipo modulares (ver
exemplo do BCube na Sec ao 1.5.2) no qual cont eineres carregados de computadores e uni-
dades de armazenamento religam pontos geogracamente distribudos [Waldrop, 2007].
Apesar da lat encia, a quantidade de dados transferidas durante esse tipo de operac ao e bem
superior ` aquela oferecida se a Internet fosse usada. V arias soluc oes de centros de dados
m oveis t em sido propostas por empresas do ramo. Por exemplo, a empresa APC deno-
minou seu produto InfraStruXure Express On-demand Mobile Data Center, utilizando
caminh oes como o ilustrado na Figura 1.25 [APC, 2012]. Esse cont einer e constitudo
um gerador de energia, um sistema de resfriamento e um centro de operac oes, cujo custo
total e da ordem de 1,5 milh oes de d olares. Outras soluc oes similares ` a da APC s ao a
Blackbox da Sun (Oracle), Portable Modular Datacenter da IBM, ICE Cube da Rackable
e Portable Optimized Datacenter da HP [Waldrop, 2007].
1.9. Conclus ao e Perspectivas Futuras
Este minicurso apresentou a import ancia do crescimento das massas de dados, impulsi-
onado pelo uso das comunicac oes em nuvens. Ainda, foi detalhada uma denic ao mais
precisa que a comumente utilizada que relaciona as grandes massas de dados apenas a
sua quantidade de bytes. Normalmente, outros aspectos relevantes s ao deixados de lado
como o n umero de fontes, a variabilidade dos dados e a velocidade com que os dados
s ao gerados. Todos eles contribuem com a denic ao mais abrangente que relaciona uma
grande massa de dados a um grande volume de dados.
Os grandes volumes de dados escondem informac oes frequentemente n ao apro-
veitadas por falta de recursos de infraestrutura para armazenamento e an alise. Novas
t ecnicas para agilizar a extrac ao de valor v em sendo propostas. Um dos principais pon-
tos de otimizac ao e evitar que os dados sejam movidos entre os centros de dados onde
est ao armazenados. Para tal, s ao considerados fatores como localidade na organizac ao
dos dados. Entretanto, encontrar a melhor localizac ao nem sempre e possvel ou trivial
j a que fatores como a proximidade dos clientes aos dados diminuem o tempo de resposta
a requisic oes. Dessa maneira, grandes massas de dados precisam ser movidas dentro
dos centros de dados ou at e mesmo entre diferentes centros de dados afastados geogra-
camente. Essa movimentac ao pode utilizar redes p ublicas tradicionais, em especial a
Internet, revelando as limitac oes dessas redes.
As limitac oes da Internet s ao muitas j a que a rede foi inicialmente projetada para
transfer encia con avel de dados com poucos kilobytes. Mover uma enorme massa de
dados, da ordem de petabytes oferece problemas que v ao desde a organizac ao dos centros
de dados at e a reformulac ao de protocolos conhecidos como o TCP. Neste minicurso,
foram abordados propostas que atacam tal gama de problemas desde as comunicac oes
internas ao centros de dados (intra-datacenters) at e as comunicac oes entre centros de
dados (inter-datacenters) ou na nuvem. Vale ressaltar que o tema e bastante complexo
e muitas soluc oes v em sendo propostas na literatura, principalmente as intra-centros de
dados. Nota-se que as soluc oes que envolvem movimentac ao entre centros de dados ainda
n ao s ao t ao exploradas como decorr encia da adic ao das redes de comunicac ao, que tornam
a soluc ao ainda mais complexa.
As grandes massas de dados ainda possuem outras quest oes n ao abordadas neste
minicurso devido ` a impossibilidade de se realizar uma pesquisa exaustiva. Dentre as
quest oes n ao abordadas est ao a seguranca dos dados, especialmente durante a trans-
fer encia; o consumo excessivo de energia; e os impactos sociais. A seguranca dos dados e
bastante controversa, j a que muitas vezes os dados dos usu arios s ao mantidos em centros
de dados de provedores de servico em nuvem, cujo controle de acesso e frequentemente
posto em xeque. J a a segunda quest ao citada e consequ encia das enormes quantidades
de energia gastas para manter refrigerados todos os servidores de um centro de dados.

E sabido que empresas de grande porte chegam a migrar os seus centros de dados para
regi oes mais frias do globo para economizar energia em resfriamento. A quest ao social e
consequ encia das novas oportunidades que surgem com a an alise dos dados, que revelam
tend encias a serem exploradas e, consequente, retorno econ omico.
Observa-se que o tema e bastante amplo e ainda h a muita pesquisa e desenvol-
vimento em potencial. Este minicurso ressalta o problema iminente resultante do surgi-
mento das grandes massas de dados, principalmente na area de comunicac ao em redes.
Entretanto, um vasto caminho ainda est a em aberto nas mais diferentes areas.
Refer encias
[CN, 2009] (2009). IEEE 802.1Qau/D1.4. draft standard for local and metropolitan area
networks - virtual bridged area networks - Amendment 7: congestion notication.
[Al-Fares et al., 2008] Al-Fares, M., Loukissas, A. e Vahdat, A. (2008). A scalable, com-
modity data center network architecture. Em ACM Sigcomm, p. 6374.
[Alizadeh et al., 2010] Alizadeh, M., Greenberg, A., Maltz, D., Padhye, J., Patel, P.,
Prabhakar, B., Sengupta, S. e Sridharan, M. (2010). Data center TCP (DCTCP). Em
Proceedings of the ACM SIGCOMM 2010, p. 6374. ACM.
[Amazon, 2011] Amazon (2011). Amazon cluster compute. Acessado em http://
aws.amazon.com/ec2/hpc-applications.
[Apache, 2012] Apache (2012). The Hadoop Project. Acessado emhttp://hadoop.
apache.org.
[APC, 2012] APC (2012). InfraStruXure express on-demand mobile data cen-
ter. Acessado em http://www.apc.com/solutions/display.cfm?id=
AFE229A7-5056-9170-D39270DFE3F5E617&ISOCountryCode=us.
[Ballani et al., 2011] Ballani, H., Costa, P., Karagiannis, T. e Rowstron, A. (2011).
Towards predictable datacenter networks. Em ACM Sigcomm, p. 242253.
[Barabash et al., 2011] Barabash, K., Cohen, R., Hadas, D., Jain, V., Recio, R. e Ro-
chwerger, B. (2011). A case for overlays in dcn virtualization. Em Proceedings of the
3rd Workshop on Data Center-Converged and Virtual Ethernet Switching, p. 3037.
ITCP.
[Barabasi e Bonabeau, 2003] Barabasi, A. L. e Bonabeau, E. (2003). Scale-free
networks. Scientic American, 288(5):5059.
[BGP Reports, 2012] BGP Reports (2012). BGP routing table analysis reports. Acessado
em http://www.potaroo.net/tools/asn32.
[Cho e Gupta, 2011] Cho, B. e Gupta, I. (2011). Budget-constrained bulk data transfer
via internet and shipping networks. Em 8th ACM International Conference on Auto-
nomic Computing, p. 7180.
[Chowdhury et al., 2011] Chowdhury, M., Zaharia, M., Ma, J., Jordan, M. I. e Stoica,
I. (2011). Managing data transfers in computer clusters with Orchestra. Em ACM
Sigcomm, p. 98109.
[Cisco, 2011] Cisco (2011). Cisco visual networking index: Forecast and methodology,
2010-2015. Acessado em http://www.cisco.com/en/US/solutions/
collateral/ns341/ns525/ns537/ns705/ns827/white_paper_
c11-481360_ns827_Networking_Solutions_White_Paper.html.
[Dean e Ghemawat, 2008a] Dean, J. e Ghemawat, S. (2008a). MapReduce: simplied
data processing on large clusters. Communications of the ACM, 51:107113.
[Dean e Ghemawat, 2008b] Dean, J. e Ghemawat, S. (2008b). MapReduce: simplied
data processing on large clusters. Communications of the ACM, 51(1):107113.
[DeCandia et al., 2007] DeCandia, G., Hastorun, D., Jampani, M., Kakulapati, G.,
Lakshman, A., Pilchin, A., Sivasubramanian, S., Vosshall, P. e Vogels, W. (2007).
Dynamo: Amazons highly available key-value store. Em ACM SIGOPS Symposium
on Operating Systems Principles, p. 205220.
[Egi et al., 2007] Egi, N., Greenhalgh, A., Handley, M., Hoerdt, M., Mathy, L. e Schoo-
ley, T. (2007). Evaluating Xen for router virtualization. Em International Conference
on Computer Communications and Networks (ICCCN), p. 12561261.
[Fernandes et al., 2011] Fernandes, N. C., Moreira, M. D. D., Moraes, I. M., Ferraz, L.
H. G., Couto, R. S., Carvalho, H. E. T., Campista, M. E. M., Costa, L. H. M. K. e
Duarte, O. C. M. B. (2011). Virtual networks: Isolation, performance, and trends.
Annals of Telecommunications, 66(56):339355.
[Forrester Research, 2010] Forrester Research (2010). The future of data center
wide-area networking. Acessado em http://www.infineta.com/sites/
default/files/pdf/Special_Forrester_Report_Skyrocketing_
WAN_Traffic.pdf.
[Gantz e Reinsel, 2010] Gantz, J. e Reinsel, D. (2010). The digital universe de-
cade - are you ready? Acessado em http://www.emc.com/collateral/
analyst-reports/idc-digital-universe-are-you-ready.pdf.
[Gantz e Reinsel, 2011] Gantz, J. e Reinsel, D. (2011). Extracting value from chaos.
Acessado em http://www.emc.com/collateral/analyst-reports/
idc-extracting-value-from-chaos-ar.pdf.
[Greenberg et al., 2009] Greenberg, A., Hamilton, J. R., Jain, N., Kandula, S., Kim, C.,
Lahiri, P., Maltz, D. A., Patel, P. e Sengupta, S. (2009). VL2: a scalable and exible
data center network. Em ACM Sigcomm, p. 5162.
[Gude et al., 2008] Gude, N., Koponen, T., Pettit, J., Pfaff, B., Casado, M., McKeown,
N. e Shenker, S. (2008). Nox: towards an operating system for networks. SIGCOMM
Comput. Commun. Rev., 38(3):105110.
[Guo et al., 2009] Guo, C., Lu, G., Li, D., Wu, H., Zhang, X., Shi, Y., Tian, C., Zhang, Y.
e Lu, S. (2009). BCube: A high performance, server-centric network architecture for
modular data centers. Em ACM Sigcomm, p. 6374.
[Halperin et al., 2011] Halperin, D., Kandula, S., Padhye, J., Bahl, P. e Wetherall, D.
(2011). Augmenting data center networks with multi-gigabit wireless links. Em ACM
Sigcomm, p. 3849.
[Hopps, 2000] Hopps, C. (2000). Analysis of an equal-cost multi-path algorithm. RFC
2992.
[Hugh Barras et al., 2008] Hugh Barras et al. (2008). IEEE 802.1Qbb/D1.0.
draft standard for local and metropolitan area networks - virtual bridged lo-
cal area networks - Amendment XX: Priority-based ow control. Aces-
sado em http://www.ieee802.org/1/files/public/docs2008/
bb-pelissier-pfc-proposal-0508.pdf.
[Isard et al., 2007] Isard, M., Budiu, M., Yu, Y., Birrell, A. e Fetterly, D. (2007). Dryad:
distributed data-parallel programs from sequential building blocks. Em ACM SI-
GOPS/EuroSys European Conference on Computer Systems, p. 5972.
[Lantz et al., 2010] Lantz, B., Heller, B. e McKeown, N. (2010). A network in a laptop:
rapid prototyping for software-dened networks. Em ACM HotNets, p. 19:119:6,
Monterey, EUA.
[Laoutaris et al., 2011] Laoutaris, N., Sirivianos, M., Yang, X. e Rodriguez, P. (2011).
Inter-datacenter bulk transfers with NetStitcher. Em ACM Sigcomm, p. 7485.
[Leiserson, 1985] Leiserson, C. E. (1985). Fat-trees: Universal networks for hardware-
efcient supercomputing. IEEE Transactions on Computers, 34(10):892901.
[Manoj Wadekar et al., 2008a] Manoj Wadekar et al. (2008a). DCB ca-
pability exchange protocol base specication Rev 1.01. Acessado em
http://www.ieee802.org/1/les/public/docs2008/az-wadekar-dcbx-capability-
exchange-discovery-protocol-1108-v1.01.pdf.
[Manoj Wadekar et al., 2008b] Manoj Wadekar et al. (2008b). IEEE 802.1Qaz/D0.2.
draft standard for local and metropolitan area networks - virtual bridged local area
networks - Amendment XX: Enhanced transmission selection for bandwidth sharing
between trafc classes. Acessado em http://www.ieee802.org/1/files/
public/docs2008/az-wadekar-ets-proposal-0608-v1.01.pdf.
[Mattos et al., 2011a] Mattos, D., Fernandes, N. C. e Duarte, O. C. M. B. (2011a). Xen-
ow: Um sistema de processamento de uxos robusto e eciente para migrac ao em
redes virtuais. Em XXIX Simp osio Brasileiro de Redes de Computadores e Sistemas
Distribudos - SBRC2011, p. 309322.
[Mattos et al., 2011b] Mattos, D. M. F., Fernandes, N. C., Cardoso, L. P., da Costa, V. T.,
Mauricio, L. H., Barretto, F. P. B. M., Portella, A. Y., Moraes, I. M., Campista, M.
E. M., Costa, L. H. M. K., e Duarte, O. C. M. B. (2011b). Omni: Uma ferramenta
para gerenciamento aut onomo de redes openow. Em Sal ao de Ferramentas do XXIX
Simp osio Brasileiro de Redes de Computadores e Sistemas Distribudos - SBRC2011,
p. 957964.
[McKeown et al., 2008] McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., Pe-
terson, L., Rexford, J., Shenker, S. e Turner, J. (2008). Openow: enabling innovation
in campus networks. SIGCOMM Comput. Commun. Rev., 38(2):6974.
[Moraes et al., 2011] Moraes, I. M., Pisa, P. S., Carvalho, H. E. T., Alves, R. S., Ferraz,
L. H. G., Ferreira, T. N., Couto, R. S., da Silva Neto, D. J., da Costa, V. P., Lage, R. A.,
dos Santos, L. V., Fernandes, N. C., Campista, M. E. M., Costa, L. H. M. K. e Duarte,
O. C. M. B. (2011). Vnext: Uma ferramenta de controle e gerenciamento para redes
virtuais baseadas em xen. Em Sal ao de Ferramentas do XXIX Simp osio Brasileiro de
Redes de Computadores e Sistemas Distribudos - SBRC2011, p. 981988.
[Mudigonda et al., 2010] Mudigonda, J., Yalagandula, P., Al-Fares, M. e Mogul, J. C.
(2010). SPAIN: COTS data-center Ethernet for multipathing over arbitrary topologies.
Em USENIX Symposium on Networked Systems Design and Implementation (NSDI),
p. 265280.
[Mudigonda et al., 2011] Mudigonda, J., Yalagandula, P., Mogul, J., Stiekes, B. e Pouf-
fary, Y. (2011). Netlord: A scalable multi-tenant network architecture for virtualized
datacenters. Em ACM Sigcomm, p. 6273.
[(Online Tech), 2011] (Online Tech), T. P. (2011). Cloud computing prompts 2012 data
center expansion plans. http://resource.onlinetech.com/cloud-computing-prompts-
2012-data-center-expansion-plans/.
[Perlman et al., 2011] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S. e Ghanwani, A.
(2011). Routing Bridges (RBridges): Base Protocol Specication. RFC 6325.
[Phanishayee et al., 2008] Phanishayee, A., Krevat, E., Vasudevan, V., Andersen, D.,
Ganger, G., Gibson, G. e Seshan, S. (2008). Measurement and analysis of TCP th-
roughput collapse in cluster-based storage systems. Em Proceedings of the 6th USE-
NIX Conference on File and Storage Technologies, p. 12. USENIX Association.
[Raiciu et al., 2011] Raiciu, C., Barre, S., Pluntke, C., Greenhalgh, A., Wischik, D. e
Handley, M. (2011). Improving datacenter performance and robustness with multipath
TCP. Em ACM Sigcomm, p. 266277.
[Raiciu et al., 2010] Raiciu, C., Pluntke, C., Barre, S., Greenhalgh, A., Wischik, D. e
Handley, M. (2010). Data center networking with multipath TCP. Em ACM HotNets,
p. 10:110:6, Monterey, EUA.
[Saucez et al., 2009] Saucez, D., Iannone, L. e Bonaventure, O. (2009). OpenLISP: An
open source implementation of the locator/ID separation protocol. Em ACM SIG-
COMM Demos Session, p. 12.
[Sherwood et al., 2009] Sherwood, R., Gibb, G., Yap, K., Appenzeller, G., Casado, M.,
McKeown, N. e Parulkar, G. (2009). Flowvisor: A network virtualization layer. Open-
Flow Switch Consortium, Tech. Rep.
[Singla et al., 2011] Singla, A., Hong, C.-Y., Popa, L. e Godfrey, P. B. (2011). Jellysh:
Networking data centers, randomly. Em Usenix HotCloud.
[The Economist, 2010] The Economist (2010). Data, data everywhere. Aces-
sado em http://www.emc.com/collateral/analyst-reports/
ar-the-economist-data-data-everywhere.pdf.
[Touch e Perlman, 2009] Touch, J. e Perlman, R. (2009). Transparent Interconnection of
Lots of Links (TRILL): Problem and Applicability Statement. RFC 5556.
[Waldrop, 2007] Waldrop, M. (2007). Data center in a box: A shipping container stuffed
with servers could usher in the era of cloud computing. Scientic American, 297(2):90
93.
[Wang et al., 2008] Wang, Y., Keller, E., Biskeborn, B., van der Merwe, J. e Rexford, J.
(2008). Virtual routers on the move: live router migration as a network-management
primitive. Em ACM SIGCOMM, p. 231242.
[Wilson et al., 2011] Wilson, C., Ballani, H., Karagiannis, T. e Rowstron, A. (2011). Bet-
ter never than late: Meeting deadlines in datacenter networks. Em ACM Sigcomm, p.
5061.
[Winslow et al., 2011] Winslow, P., Simson, D. e Panigrahi, S. (2011). The need for
speed. Relat orio t ecnico, Credit Suisse.
[Wu et al., 2010] Wu, H., Feng, Z., Guo, C. e Zhang, Y. (2010). ICTCP: Incast conges-
tion control for TCP in data center networks. Em Proceedings of the 6th International
Conference, p. 13. ACM.
[Zhang et al., 2011] Zhang, J., Ren, F. e Lin, C. (2011). Modeling and understanding
TCP incast in data center networks. Em Proceedings of the IEEE INFOCOM 2011, p.
13771385. IEEE.
[Zohar et al., 2011] Zohar, E., Cidon, I. e Mokryn, O. (2011). The power of prediction:
Cloud bandwidth and cost reduction. Em ACM Sigcomm, p. 8697.