-
Notifications
You must be signed in to change notification settings - Fork 0
/
cap-revisao_bibliografica.tex
150 lines (113 loc) · 22.4 KB
/
cap-revisao_bibliografica.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
\chapter{Revisão Bibliográfica}
\label{cap:revisao_bibliografica}
\section{Objetivo}
O objetivo dessa revisão foi analisar e estudar os problemas existentes na área de virtualização de dispositivos de rede.
Também foi estudadas as estratégias de agregar interrupções tanto em dispositivos de redes virtuais como físicas.
\subsection{Resumo Sintetizado}
No artigo de Walters, Chaudhary, Cha, Jr. e Gallo \cite{chaudhary2008comparison}, foi feito uma comparação entre o \textit{XEN}, \textit{VMWare} e \textit{OpenVZ}.
A partir dos experimentos foi concluído que o \textit{hypervisor} \textit{XEN} tem um desempenho baixo em termos de latência, porém alto em termos de largura de banda em relação a um ambiente com \textit{OpenVZ} e um ambiente sem virtualização, enquanto que o \textit{OpenVZ} tem uma perda em largura de banda, mas um atraso pequeno. Quanto ao \textit{VMWare}, ele teve um desempenho baixo tanto em atraso quanto em largura de banda. Os autores não entram em detalhes sobre os motivos dos resultados terem sido esses.\newline
O artigo de Ekanayake e Fox \cite{ekanayake2010high} estudou a relação entre o número de núcleos e o número de máquinas virtuais usando \textit{XEN} e \textit{Eucalyptus} como infraestrutura de nuvem. Foi concluído que a virtualização funciona bem para aplicações que não se comunicam muito,
enquanto que em aplicações que são sensíveis a latência, houve uma perda de desempenho em relação a um ambiente não virtualizado. Outra conclusão foi que quanto maior o número de máquinas virtuais, maior a sobrecarga na \textit{CPU}. A explicação para isso, segundo o autor, está na forma como é implementada a virtualização da rede. O hardware físico só pode ser controlado por um sistema (\texttt{dom0}), enquanto que os outros (\texttt{domUs}) para conseguirem fazer alguma operação de E/S pela rede, devem passar por esse sistema através de um canal. Isso forma um gargalo no \texttt{dom0}.\newline
No artigo de Rixner \cite{Rixner:2008:NVB:1348583.1348592}, foi feita uma revisão sobre a virtualização de rede.
No texto o autor cita que a virtualização de rede impacta diretamente no número de servidores que podem ser diretamente consolidados dentro de uma única máquina física. Porém, as técnicas modernas de virtualização têm gargalos significantes, o que limita o desempenho da rede.
Ele sugere um ganho de desempenho fazendo o dispositivo ter a capacidade de ler e escrever diretamente na memória da máquina virtual ao invés do processador da máquina virtual gerar interrupções cada vez que alguma informação entra ou sai pelo dispositivo. Essa funcionalidade é chamada acesso direto a memória (\textit{DMA}).
Apesar disso, o dispositivo pode escrever em uma posição da memória que não pertence a máquina virtual, podendo assim, causar problemas em outros processos da máquina física. Assim, foi criado a unidade de gerenciamento de E/S da memória (\textit{IOMMU} -- \textit{input/output memory management unit}). No \textit{IOMMU} a memória é restrita para o dispositivo de acordo com a máquina virtual que controla esse dispositivo. Atualmente os \textit{hypervisors} modernos, como o \textit{XEN}, utilizam essas técnicas \cite{barham2003xen} .
Como atualmente um processador possui vários núcleos, pode-se aproveitar esses núcleos para criar multi-filas nas interfaces de rede. O autor cita que pesquisadores do laboratório da HP e \textit{Citrix} eliminaram a ponte no domínio de E/S para associar as máquinas virtuais diretamente com o \textit{driver} de \textit{backend} através das multi-filas, evitando a necessidade de sincronização das mensagens e multiplexação/demultiplexação da rede. Como benefícios do uso da multi-fila se teve: a redução da carga extra na fila e a eliminação de cópias entre o domínio de E/S e a máquina virtual, pois, a multiplexação não é feita. Por outro lado, é necessário que cada informação seja enviada para a fila correta e que a \textit{CPU} consiga aguentar a carga extra gerada pelas múltiplas filas.
Ainda no mesmo artigo, na arquitetura de virtualização de rede CDNA (do inglês \textit{concurrent direct network access} -- acesso direto a rede concorrente) foi empregada a proposta de multi-filas, em adição foi removido o domínio de E/S. Sem o responsável por controlar as filas, o \textit{hypervisor} passa a considerar cada conjunto de fila como uma interface de rede física e associa o controlador a uma máquina virtual. Assim, cada máquina virtual consegue enviar ou receber informações diretamente da rede sem nenhuma intervenção do domínio de E/S. Como consequência, a carga extra é reduzida pelo número reduzido de interrupções (antes era necessário interromper tanto o domínio de E/S como as máquinas virtuais em cada transmissão/recepção).
Pela máquina virtual poder acessar diretamente a interface de rede, ela também pode acessar algum local indevido da memória por \textit{DMA}. Para contornar esse problema o autor sugeriu o uso de \textit{IOMMU}.\newline
No artigo de Waldspurger e Rosenblum \cite{Waldspurger:2012:IV:2063176.2063194}, são citados diversos desafios e problemas na área de virtualização de E/S: a carga extra no \textit{hypervisor}, a complexidade em gerenciar recursos (escalonamento e prioridades) e a dificuldade de dar uma semântica ao hardware virtual.\newline
No artigo de Liu \cite{liu2010evaluating}, foram feitos diversos experimentos com virtualização de E/S baseados em \textit{software} usando \textit{Virtio} e em hardware usando \textit{SR-IOV} (do inglês \textit{single root I/O virtualization} -- virtualização de E/S de raiz única) usando o \textit{hypervisor} \textit{KVM}.
O \textit{Virtio} é um padrão do Linux para \textit{drivers} de rede e disco que estão rodando em um ambiente virtual cooperado com um \textit{hypervisor} para-virtualizado. Ele tem um padrão arquitetural similar aos \textit{drivers} de rede do \textit{Xen}, apesar de serem diferentes.
Já o \textit{SR-IOV} é uma especificação que permite a dispositivos \textit{pci-express} fornecerem interfaces extras com funcionalidades reduzidas para serem usadas pelas máquinas virtuais diretamente.
Foram analisada as seguintes métricas nesse experimento: a largura de banda, a latência e uso do processador.
Na latência, o \textit{Virtio} teve um desempenho muito baixo. A explicação, provada desabilitando a função de agregação de interrupções na transmissão, é que o hospedeiro atrasa o envio do pacotes para ser enviado em rajadas, mas mesmo assim, seu desempenho sem mitigação ainda perdeu próximo de 20 microssegundo em relação a máquina não virtualizada.
Quando a opção de agregação é desabilitada, isso provoca uma perda de desempenho pois cada pacote que é transmitido gera uma carga de trabalho no \textit{CPU}. Com a mitigação a carga por pacote é reduzida.
Já o \textit{SR-IOV} teve um desempenho próximo da máquina pura perdendo apenas alguns microssegundos devido a virtualização da interrupção.
Na largura de banda, a transmissão em todas as configurações tiveram o mesmo desempenho. Já na recepção o \textit{SR-IOV} se aproximou da máquina pura, mas o uso da sua \textit{CPU} foi muito maior que as demais. No \textit{Virtio}, ele não conseguiu um bom desempenho, mas o uso de sua \textit{CPU} foi baixa. No experimento de uso da memória na recepção, o \textit{SR-IOV} teve um uso muito menor que o \textit{Virtio}, assim, o autor concluiu que o mal uso da largura de banda na recepção do \textit{Virtio} foi pelo uso excessivo da memória, o que explica também o baixo uso da \textit{CPU}.\newline
No artigo de Santos, Turner, Janakiraman e Pratt \cite{Santos:2008:BGS:1404014.1404017}, foi proposto modificar a arquitetura do \textit{driver} de E/S do \textit{XEN} para conseguir melhorar o uso da \textit{CPU}.
Dentro dos problemas que o autor encontrou está o excesso de cópias de dados.
Para reduzir o excesso de cópias, foram propostos otimizações nas operações de remapeamento de páginas tanto na transmissão como na recepção.
No \textit{hypervisor}, ele conseguiu uma economia de 56\% no uso do processador.\newline
No artigo de Oi e Nakajima \cite{oi2009performance}, foi analisado o desempenho de um sistema virtualizado com \textit{XEN} aplicando a estratégia \textit{LRO (large receive offload)} onde ainda dentro do \textit{driver} da placa de rede são recebidos e reunidos os pacotes de informações que tiveram que ser segmentados. Nesse experimento foram medidos a vazão da rede variando o tamanho da mensagem e o tamanho da \textit{MTU}. Os resultados mostraram um ganho de 8\% a 14\% na vazão da rede.\newline
No artigo de Apparao, Makineni e Newell \cite{apparao2006characterization}, foram pesquisadas as principais causas de carga extra na virtualização de E/S. No experimento eles estudaram dois modos de virtualização de E/S: o \texttt{domU} e o \texttt{dom0} na mesma \textit{CPU} e em \textit{CPUs} distintas.
O resultado mostrou que nos dois métodos, tanto a transmissão como a recepção de pacotes apresentaram uma perda de desempenho de mais de 50\% quando comparado com a máquina física. Também foi notado que executar o \texttt{domU} e o \texttt{dom0} em \textit{CPUs} distintas é mais custoso que executar elas juntas na mesma \textit{CPU}.\newline
No artigo de Jang, Seo, Jo e Kim \cite{jang2011low}, foi estudado sacrificar o isolamento que existe entre as máquinas virtuais para conseguir reduzir a carga extra do processador. Os resultados mostram uma redução de 29\% no uso do processador e 8\% de ganho de largura de banda na transmissão de pacotes grandes. \newline
No artigo de Fortuna e Adamczyk \cite{fortuna2012improving}, foram feitos experimentos em torno do problema da carga extra na virtualização da rede. Para isso, os autores propuseram adequar o balanceamento de interrupções para demostrar a possibilidade de reduzir o número de pacotes perdidos. O resultado foi que um balanceamento adequado pode melhorar muito o desempenho, porém, o comportamento é difícil de ser previsto, dificultando a elaboração de um algoritmo.
Uma proposta futura sugerida foi deixar o núcleo do sistema automatizar o processo de balanço e analisar os resultados. Quando aparecerem bons resultados, congelar a configuração de interrupção.
Eles também, discutiram a possibilidade de usar a função de agregação existentes nos \textit{drivers} das placas de rede modernas para um trabalho futuro.\newline
\subsubsection{Evaluating System Performance in Gigabit Networks \cite{salah2005analysis}}
No artigo de Salah e El-Badawi \cite{salah2005analysis}, é feita uma análise e simulação sobre o impacto da sobrecarga de interrupções no desempenho do sistema operacional em redes de alta velocidade.
O principal problema que eles exploraram é a grande quantidade de interrupções gerada na recepção de pacotes.
Como a interrupção tem prioridade máxima em relação a outras tarefas, em excesso, ela acaba consumindo todo tempo de processamento, impedindo outras tarefas de serem realizadas e, consequentemente, reduzindo a taxa de transferência do sistema a 0. Essa situação é conhecida como \textit{``livelock''}.
Na Figura \ref{livelock}, é mostrado um gráfico de carga do sistema por taxa de transferência.
Na curva ideal, conforme a carga do sistema aumenta, a taxa de transferência passa a aumentar proporcionalmente, ou seja, quanto maior a velocidade de chegada dos pacotes, maior a quantidade de pacotes processada.
Porém, como praticamente todo sistema tem uma capacidade finita de processamento, ele não recebe e processa pacotes além de sua velocidade máxima.
Essa velocidade é chamada de \textit{MLFRR} (do inglês \textit{Maximum Loss-Free Receive Rate} -- máxima velocidade de recepção livre de perdas).
Na curva aceitável, quando o sistema chega à \textit{MLFRR}, ele passa a não ter ganho na taxa de transferência pelo limite de processamento, e depois disso, a curva se comporta praticamente como uma constante.
Por outro lado, se a rede for sobrecarregada na entrada, as interrupções geradas na chegada dos pacotes irão impedir que o pacote seja processado e a taxa de transferência do sistema cairá para 0 como é possível ver na curva \textit{livelock}.
\begin{figure}[h!]
\begin{center}
\includegraphics[width=300px,height=250px]{./img/livelock.eps}
\caption{Livelock na recepção de pacotes \cite{salah2005analysis}}
\label{livelock}
\end{center}
\end{figure}
Para analisar a situação de sobrecarga de interrupções, os autores modelaram o sistema como uma fila M/M/1/B com chegada de pacotes em \textit{Poisson} de velocidade $\lambda$ e média efetiva de tempo de serviço de $1/\mu$ que tem uma distribuição geral (os autores não justificam o motivo de terem modelado segundo essa distribuição).
O sistema pode usar ou não \textit{DMA}.
Sem \textit{DMA}, o processador gerencia a recepção de pacotes. Quando o processador é interrompido enquanto está processando um pacote pela chegada de um outro pacote, o tempo para processar é estendido para realizar uma cópia individual do outro pacote que chegou para a memória do sistema.
Com \textit{DMA}, a placa de rede tem acesso direto a memória. Quando um ou mais pacotes chegam enquanto que o sistema está ainda processando um outro pacote, todos são processados sem estender o tempo de processar.
Foram feitos experimentos analisando o sistema ideal, \textit{DMA} habilitado e \textit{DMA} desabilitado. Com pouco tráfego de pacotes, a taxa de transferência de todos foi a mesma.
Já com muito tráfego, a taxa de transferência do sistema com o \textit{DMA} habilitado teve uma queda menor na taxa de transferência que o sistema sem o \textit{DMA} habilitado e o sistema ideal se apresentou com taxa de transferência constante.
\subsubsection{To Coalesce or Not To Coalesce \cite{salah2007coalesce}}
No artigo de Salah \cite{salah2007coalesce}, continuação do artigo anterior \cite{salah2005analysis}, é analisado o desempenho de duas técnicas de agregação de interrupções: baseada em contagem e baseada em tempo. Na técnica baseada em tempo, o \textit{driver} da placa de rede não gera interrupções no sistema quando um pacote é recebido.
Ao invés disso, uma interrupção é gerada depois de um intervalo de tempo que um pacote é recebido.
Já na técnica baseada em contagem, é gerada uma interrupção quando uma quantidade de pacotes é recebida.
A conclusão tirada nos modelos analíticos é que a agregação funciona melhor que o modelo de interrupção comum quando se tem um grande tráfego na rede. Porém, para um tráfego pequeno, a interrupção comum superou a agregação. Os autores sugerem monitorar o tráfego e fazer a troca entre a interrupção comum e a agregação de interrupções. Eles também citam um momento que pode ser usado para indicar a condição de sobrecarga. Este momento pode ser usado para a troca.
Outras importantes conclusões são que na agregação, são necessários valores altos de parâmetros em tráfegos intensivos, que para tráfegos tolerantes a latência, o uso de agregação é interessante independente do tráfego e que para tráfegos de tempo não-real é interessante usar a agregação baseada em tempo ao invés da baseada em contagem por impor um limite de atraso na agregação.
No artigo de Salah e Qahtan \cite{salah2009implementation}, foi apresentada uma estratégia de recepção de pacotes chamada ativação-desativação de interrupções e implementada uma estratégia híbrida de recepção no \textit{driver} de dispositivo de rede.
A ativação-desativação de interrupções funciona como a estratégia comum de gerar uma interrupção a cada pacote que chega, porém, durante a recepção do pacote, as interrupções de recepção são desabilitadas impedindo os pacotes que chegam durante o processo de recepção de gerarem interrupções desnecessárias.
A estratégia híbrida alterna entre a \textit{NAPI} e a ativação-desativação de interrupções dependendo do tráfego. Em tráfegos moderados, o \textit{driver} recebe pacotes ativando-desativando interrupções. Já em tráfegos intensivos o \textit{driver} passa a usar \textit{NAPI}.
Nos experimentos, foram comparadas as estratégias de ativação-desativação de interrupções, \textit{NAPI} e a proposta de estratégia hibrida.
A estrátegia híbrida teve um desempenho melhor que a \textit{NAPI} tanto para tráfegos intensivos como moderados, mas isso foi devido ao parâmetro limite da \textit{NAPI} que foi configurado diferente nas duas estratégias.
\subsubsection{Interrupt Moderation Using Intel GbE Controllers \cite{intel_interrupt}}
No artigo da Intel \cite{intel_interrupt}, é citado o problema da grande quantidade de interrupções gerada na transmissão e recepção de pacotes.
Para resolvê-lo, os autores propuseram o uso de temporizadores internos da placa de rede para moderar a quantidade de interrupções geradas.
Os temporizadores são divididos em temporizador absoluto, pacote e mestre. O temporizador absoluto inicia uma contagem regressiva quando o primeiro pacote chega ou é enviado.
No momento que a contagem chega a zero, é gerada uma interrupção no sistema. Este temporizador é eficiente quando se tem muito tráfego de pacotes, pois muitos pacotes chegam/são enviados até o temporizador gerar a interrupção, reduzindo a quantidade de interrupções por pacote.
Por outro lado, ele não é eficiente quando há pouco tráfego porque poucos pacotes chegam/são enviados até o temporizador gerar a interrupção e por atrasar as interrupções e, consequentemente, as informações que devem chegar ao sistema.
O temporizador de pacotes também inicia uma contagem regressiva quando o primeiro pacote chega ou é enviado e também gera uma interrupção quando a contagem chega a zero, mas ele é reiniciado sempre que um novo pacote chega.
Isso reduz a latência quando há pouco tráfego no enlace, pois a interrupção é gerada quando o temporizador percebe que nenhum pacote será mais enviado/recebido, mas quando há muito tráfego, ele pode nunca gerar a interrupção, pois o temporizador estará sempre sendo reinicializado pelos pacotes que chegam/são enviados.
O temporizador mestre é usado para otimizar os outros temporizadores.
O temporizador absoluto e o temporizador de pacotes podem ser combinados para chegar a um bom resultado.
Além dos temporizadores já citados, existe um outro mecanismo chamado limitador de interrupções.
Esse mecanismo também é um temporizador de contagem regressiva e limita o número de interrupções por segundo.
Quando o temporizador inicia a contagem regressiva, este também começa a contar o número de interrupções que foi gerado.
Quando a contagem chega a zero, o contador de interrupções também é zerado. Se o número de interrupções ultrapassar o limite estabelecido, as interrupções geradas são adiadas até o contador ser reinicializado.
Um algoritmo foi proposto para moderação de interrupções que ajusta dinamicamente o valor do limitador de interrupções.
Dependendo do padrão de E/S, é usado um valor no limitador.
O padrão de E/S é categorizado em: baixíssima latência, onde o tráfego é mínimo e predomina os pacotes pequenos, baixa latência, onde o tráfego também é minimo e há um significante percentual de pacotes pequenos, e intermediário, onde há muito tráfego de pacotes medianos.
Não foi possível entender como os autores chegaram a esses valores e porque eles resolveram dividir o padrão de E/S dessa forma.
\subsubsection{Placas de rede da Intel}
Atualmente, a \textit{Intel} é uma empresa que tem investido em pesquisas de dispositivos de rede.
Suas placas de rede implementam várias funcionalidades exclusivas como a interrupção de baixa latência e a moderação de interrupções dita anteriormente em \cite{intel_placa_de_rede}.
A interrupção de baixa latência permite que seja gerada uma interrupção imediatamente após a recepção de um pacote que segue algum critério.
Este critério pode ser o valor da porta de destino do pacote, o tamanho do pacote ou o tipo de protocolo \textit{Ethernet}.
Apesar dessas funcionalidades ajudarem muito na pesquisa de agregação de interrupções, uma placa de rede da Intel possui um custo muito alto, o que inviabiliza fazer experimentos com ela.
\subsubsection{Linux}
\textit{Linux} é um clone do sistema operacional \textit{Unix} escrito do zero por Linus Torvalds com ajuda de uma equipe de \textit{hackers} espalhada por todo o mundo. Seu código-fonte pode ser obtido em \url{http://github.com/torvalds/linux}.
É importante destacar que tanto o código quanto a documentação são de alta qualidade e atualizados diariamente sendo uma importante fonte de informação confiável para pesquisas. Muitos detalhes e dúvidas tanto de implementação quanto para entender melhor o funcionamento do \textit{driver} de rede foram esclarecidos quando navegamos pelo seu repositório.
Estudando o código-fonte dos \textit{drivers} encontrados no repositório do \textit{Linux}, percebemos que a grande maioria implementava \textit{NAPI} por padrão.
Outras estratégias para reduzir interrupções como a agregação por intervalo de tempo e por pacotes dificilmente foram implementadas.
\subsection{Resumo Conclusivo}
Nessa revisão, foram encontrados diversos artigos com propostas que modificam diferentes partes da infraestrutura: \textit{driver} de rede, placa de rede física, arquitetura da virtualização da rede e núcleo do sistema operacional.
No artigo da Intel \cite{intel_interrupt}, foi proposto um algoritmo para a moderação de interrupções de acordo com o padrão de E/S.
Não ficou claro como os autores criaram o algoritmo, e é necessário a funcionalidade de moderação de interrupção que apenas alguns \textit{drivers} implementam.
No segundo artigo de Salah \cite{salah2007coalesce}, foi criado um modelo analítico e simulador para analisar a analisar a estratégia de agregação de interrupções por intervalo de tempo e por quantidade de pacotes. Porém, atualmente, não foi possível encontrar \textit{drivers} que implementem essas funcionalidades.
No terceiro artigo de Salah \cite{salah2009implementation}, foi apresentada uma estratégia híbrida de interrupções em dispositivos físicos.
Uma desvantagem dessa estratégia é a necessidade de definir o momento em que se deve trocar entre \textit{NAPI} e ativação-desativação de interrupções.
Experimentos com placas que implementam \textit{SR-IOV} e placas da \textit{Intel} apresentaram progressos na virtualização de rede, porém, são muito caras atualmente.
A \textit{NAPI} pareceu ser a estratégia mais utilizada atualmente pelos fabricantes de dispositivos de rede. Nesse estudos vimos os \textit{drivers}: e1000, r8169, virtio e tg3, todos implementavam \textit{NAPI}. Não foi encontrado muitos artigos relacionados.
A revisão ajudou a entender melhor a área de virtualização de rede.
Porém, foi notada também a falta de detalhes técnicos nos artigos o que dificulta demais a continuação deles.
Outro problema é a rápida desatualização das pesquisas.
O progresso tanto do \textit{Linux} quanto dos \textit{drivers} deixaram muitas propostas de agregação de interrupções obsoletas. Como a agregação por intervalo de tempo e por pacotes.