Pós-Graduação em Ciência da Computação
FRANCISCO DALADIER MARQUES JÚNIOR
OTIMIZANDO REDES VIRTUAIS AO LONGO DO TEMPO ATRAVÉS DA INTEGRAÇÃO DE MODELOS MULTIPLICATIVOS DA DATA ENVELOPMENT ANALYSIS (DEA) COM A AVALIAÇÃO DA ESTRUTURA FRACTAL
Universidade Federal de Pernambuco [email protected] www.cin.ufpe.br/~posgraduacao
Recife 2019
FRANCISCO DALADIER MARQUES JÚNIOR
OTIMIZANDO REDES VIRTUAIS AO LONGO DO TEMPO ATRAVÉS DA INTEGRAÇÃO DE MODELOS MULTIPLICATIVOS DA DATA ENVELOPMENT ANALYSIS (DEA) COM A AVALIAÇÃO DA ESTRUTURA FRACTAL
Tese apresentada ao Programa de Pós- Graduação em Ciências da Computação da Universidade Federal de Pernambuco, como requisito parcial para a obtenção do título de Doutor em Ciências da Computação.
Área de concentração: Redes de Computadores
Orientador: Paulo Roberto Freire Cunha Co-orientador: Kelvin Lopes Dias
Recife 2019
Catalogação na fonte Bibliotecária Arabelly Ascoli CRB4-2068
M357o Marques Júnior, Francisco Daladier Otimizando redes virtuais ao longo do tempo através da integração de modelos multiplicativos da Data Envelopment Analysis (DEA) com a avaliação da estrutura fractal / Francisco Daladier Marques Júnior. – 2019. 175 f.: il., fig., tab.
Orientador: Paulo Roberto Freire Cunha Tese (Doutorado) – Universidade Federal de Pernambuco. CCEN. Ciências da Computação. Recife, 2019. Inclui referências e apêndices.
1. Autossimilaridade. 2. Multiplicativos DEA. 3. Absorção multifotônica. 4. Termometria óptica. I. Cunha, Paulo Roberto Freire (orientador). II. Título.
004.6 CDD (22. ed.) UFPE-MEI 2019-126
FRANCISCO DALADIER MARQUES JÚNIOR
OTIMIZANDO REDES VIRTUAIS AO LONGO DO TEMPO ATRAVÉS DA INTEGRAÇÃO DE MODELOS MULTIPLICATIVOS DA DATA ENVELOPMENT ANALYSIS COM A AVALIAÇÃO DA ESTRUTURA FRACTAL
Tese apresentada ao Programa de Pós- Graduação em Ciências da Computação da Universidade Federal de Pernambuco, como requisito parcial para a obtenção do título de Doutor em Ciências da Computação.
Aprovada em: 07/02/2019.
BANCA EXAMINADORA
______Prof. Dr. José Augusto Suruagy Monteiro Centro de Informática/UFPE
______Prof. Dr. Paulo Romero Martins Maciel Centro de Informática/UFPE
______Prof. Dr. Ricardo Massa Ferreira Lima Centro de Informática/UFPE
______Profª. Dra. Ana Lúcia Miranda Lopes Faculdade de Ciências Econômicas/UFMG
______Prof. Dr. Jorge Luiz de Castro e Silva Centro de Ciências e Tecnologia/UECE
Dedico este trabalho a Deus, aos meus pais, esposa, família, professores, amigos e colegas.
“A geometria fractal é baseada na Lei dos Grandes Números, devido ao fato de que a média de um conjunto de números altamente aleatórios tende a ser próximo da média da população inteira.” (MANDELBROT; TALEB, 2012., pg 2)
AGRADECIMENTOS
Glória e louvores à Santíssima Trindade pelo discernimento e perseverança que me foram concedidos nesta longa caminhada.
Aos meus pais, Daladier, Neide e Mãe Corrinha, que nunca pouparam esforços, amor, carinho, palavras de incentivo e orações, desde o início do processo educativo, até chegar ao tão sonhado momento da defesa do doutorado.
A minha esposa – Máisa Vitório – que com amor, inteligência, afeto, orações, paciência, incentivos e compreensão, ainda teve forças para me apoiar em todos os momentos, desde a graduação.
Agradeço toda a forma de apoio, orações e carinho dos meus avós paternos – Juarez (In memoriam) e Belinha – e maternos – Chico Tomaz (In memoriam) e Santú (In memoriam).
Aos meus irmãos, D´Sávio e Raphaella, pelo incentivo e irmandade.
Ofereço este trabalho a todos meus familiares das famílias Tomaz, Aquino, Dantas, Feitosa e Marques, em especial, ao meu padrinho Zé Pedro, Tia Gracineide, Tia Lizieux, enfim, tios, primos, entre outros familiares que me acolheram e incentivaram ao longo do processo educativo.
Agradeço a todos os meus professores, desde a infância até hoje, em especial a Tia Ilzineide Mangueira e Carmelita Gonçalves. Estendo o agradecimento, também, aos amigos e colegas de estudo e pesquisa que fiz em vários rincões do Brasil e pelo mundo, os quais muito acrescentaram à minha formação científica.
Em especial, aos meus cunhados – Marcelo Vitório (minhas sobrinhas e afilhada) e Emmanuel Marcílio Vitório (In memoriam) e aos colegas: Marcelo Damasceno, Enyo José Tavares, Wallison Pereira, Diego Ernesto, Fabio Gomes e aos demais colegas da área de Informática do IFPB/Campus Cajazeiras. Acrescento homenagem ao meu
amigo e conterrâneo sertanejo – Doutor André Pereira – que foi uma grande fonte de inspiração pela forma como se dedicou incansavelmente aos estudos.
Outrossim, agradeço ao IFPB/Campus Cajazeiras, por investir em minha qualificação desde o mestrado, provendo condições para que eu pudesse atingir sempre meu nível máximo como cientista.
Agradeço, em especial, ao Professor Jorge Luiz, da UECE, por ter acreditado no meu trabalho desde o mestrado até o doutorado. O mentor que apresentou os nortes da autossimilaridade e otimização multicritério de redes.
Agradeço também ao Professor Clécio Thomaz, pela paciência, orientações e ensinamentos sobre DEA.
À UECE, seu corpo docente do mestrado acadêmico, especificamente aos Professores: Joaquim Celestino Júnior, Gustavo Augusto Campos, Jerffeson Teixeira, José Everardo Bessa, Marcial Fernandez, Valdísio Viana em Ciência da Computação. Além de todos os funcionários daquele programa, em especial, ao amigo Marcos.
Ao meu orientador e co-orientador do doutorado, respectivamente, o Professor Paulo Cunha e o Professor Kelvin Lopes. Vale ressaltar que ambos me reservaram atenção especial durante o doutorado, ajudando sempre proativamente, corrigindo-me nas horas certas. Enfim, agindo de alguma forma para que eu chegasse neste momento especial da minha carreira.
Ao Centro de Informática da UFPE todo o meu respeito, admiração e agradecimento por ter aprendido a avaliar uma rede virtual ao longo. Por isso, agradeço em especial aos Professores Paulo Maciel, Ricardo Massa, Stênio Fernandes e Djamel Sadok, pois, através do conhecimento repassado por todos, consegui chegar à defesa do doutorado ao otimizar redes virtuais com os modelos multiplicativos DEA. Agradeço, também, ao Professor José Augusto Suruagy que pontualmente ajudou no aperfeiçoamento da tese.
Gratidão especial à Professora Ana Lúcia Miranda Lopes, pela confiança, apoio, solicitude e, principalmente, por ter aberto as portas do mundo, ao me indicar como pesquisador visitante da Aston Bussiness School (ABS). A esta relevante instituição internacional, agradeço com afeto especial e estendo o agradecimento aos demais Professores, pessoal de apoio da ABS, bem como aos colegas e amigos ingleses, em especial, à minha amiga Debashree De.
Agradeço, imensamente, ao Professor Ali Emrouznejad, pelas orientações, paciência, simplicidade e ensinamentos sobre os modelos multiplicativos DEA, bem como por ter me transformado em um cientista mais maduro. A ele e a todos, o meu muito obrigado será traduzido no trabalho doutoral adiante.
RESUMO Recentemente, a predição da configuração mais eficiente entre um vasto conjunto de dispositivos usados para montar um ambiente otimizado de serviços de computação, em nuvem e redes virtuais, tem atraído uma atenção crescente. Esta tese propõe uma mudança de paradigma na modelagem do comportamento do Transmission Control Protocol (TCP), ao longo do tempo, em redes virtuais, usando modelos da Data Envelopment Analysis (DEA). Em primeiro lugar, é mostrado que a autossimilaridade com dependência de longo alcance é apresentada de forma diferente em todos os dispositivos de rede. De fato, este trabalho implementa uma nova aplicação da dimensão fractal em redes virtuais para previsão, no qual esse índice chave informa se a camada de transporte encaminha serviços de tráfego com comportamento suave ou irregular ao longo do tempo. Outra contribuição substancial é mostrar que os dispositivos de rede virtual possuem valores distintos relativos à dimensão fractal, desempenho da largura de banda do TCP e memória fractal ao longo do tempo. Portanto, esses índices fractais elencados são usados por esta tese para a predição de dados espaço-temporais em redes virtuais. Assim, uma metodologia de avaliação de desempenho fractal em etapas é desenvolvida como um sistema especialista para avaliação de redes virtuais, bem como, implementa esta análise fractal como representação de conhecimento. Todavia, devido às limitações dos modelos clássicos DEA, são introduzidos modelos multiplicativos estáticos e dinâmico da DEA para avaliar as séries temporais dos diversos hipervisores de redes. Para a aquisição do conhecimento, 50 hipervisores de redes virtuais diferentes foram avaliados como unidades de tomada de decisão ou uma decision-making unit (DMU). Outrossim, os experimentos foram escalados usando um hipervisor de tipo-I, no qual variaram-se parâmetros de CPU e RAM virtuais. Os experimentos escalados geraram 288 DMUs, que foram avaliadas segundo o modelo Super-Cobb-Douglas DEA com orientação à entrada, também concebido por este trabalho. Resumindo, esse sistema especialista também funciona como um hipervisor matemático capaz de determinar o padrão fractal mais eficiente para fornecer serviços de tráfego TCP. Enfim, os resultados obtidos, ao empregar as variáveis de decisão elencadas em qualquer um dos modelos multiplicativos DEA aqui lançados, garantem que a escolha da DMU mais eficiente irá fornecer um serviço de rede virtual, com desempenho da largura de banda do TCP superior e estável por um maior período de tempo.
Palavras-chave: Autossimilaridade. Modelos Multiplicativos DEA. Virtualização de Redes. Hipervisor Matemático. Tomada de Decisão Multicritério em Redes Virtuais. Metodologia de Avaliação da Estrutura Fractal do Tráfego TCP.
ABSTRACT Recently, the prediction of the most efficient configuration among a vast set of devices used for mounting an optimised cloud computing services and virtual networks environments have attracted growing attention. This thesis proposes a paradigm shift in modelling transmission control protocol (TCP) behaviour over time in virtual networks by using data envelopment analysis (DEA) models. Firstly, it is shown that self-similarity with long-range dependency is presented differently in every network device. Indeed, this work implements a novel fractal dimension concept on virtual networks for prediction, where this key index informs if the transport layer forwards traffic services with smooth or jagged behaviour over time. Another substantial contribution is proving that virtual network devices have a distinct fractal memory, TCP bandwidth performance, and fractal dimension over time. However, these fractal indices are employed by thesis for forecasting of spatiotemporal data. Thus, a stepwise performance evaluation framework methodology of fractal structure is developed as an expert system for virtual network assessment, as well as it performs a fractal analysis as a knowledge representation. In addition, due to the limitations of classical DEA models, they are introduced static and dynamic multiplicative DEA models to assess the fractal time series from diverse network hypervisors. For knowledge acquisition, 50 different virtual network hypervisors were appraised as a decision-making unit (DMU). In addition, the experiments were scaled up using a type-I hypervisor where virtual parameters related to CPU and RAM are varying. The scaled experiments generated 288 DMUs, which were evaluated according to the input-oriented Super-Cobb-Douglas DEA model herein also devised. In summary, this expert system also functions as a mathematical hypervisor, capable of determining the most efficient fractal pattern to provide TCP traffic services. Finally, the results obtained by employing the decision variables used in any of the multiplicative DEA models launched is the guarantee that the choice of the most efficient DMU will provide a virtual network service, with superior and stable TCP bandwidth performance by one longer period of time.
Keywords: Self-similarity. Multiplicative DEA Models. Network Virtualization. Mathematical Hypervisor. Multicriteria Decision Making in Virtual Networks. Methodology for Evaluating the Fractal Structure of TCP Traffic.
LISTA DE FIGURAS
Figura 1 - Ilustra a diferença visual entre três das principais técnicas de virtualização acima descritas - (a) Full Virtualization 37 Figura 2 - Ilustra a diferença visual entre três das principais técnicas de virtualização acima descritas - (b) Virtualização de Hardware 38 Figura 3 - Ilustra a diferença visual entre três das principais técnicas de virtualização acima descritas - (c) Contêiner 38 Figura 4 - Encaminhamento de pacotes em redes virtuais – LXC 45 Figura 5 - Encaminhamento de pacotes em redes virtuais - Docker 45 Figura 6 - Triângulo de Sierpinski 47 Figura 7 - Fronteira CCR (reta) e BCC (convexa) 63 Figura 8 - Retornos de Escala CCR x BCC 64 Figura 9 - Raio ilimitado (ray unboundness) x fronteira geométrica 69 Figura 10 - Convexidade geométrica dos modelos multiplicativos DEA, com fronteira em forma de S 70 Figura 11 - O envelope, raio ilimitado e VRS 72 Figura 12 - Garantia de alcançabilidade entre a VM DUT e a VM TG 79 Figura 13 - Fluxograma algorítimico do framework de avaliação de desempenho por etapas da estrututra fractal do tráfego TCP em redes virtuais 82 Figura 14 - Saída do comando Lscpu do Host Principal usado no cenário de 83 experimentação dos roteadores virtuais Figura 15 - Configurações básicas para montagem das redes virtuais no VirtualBox - Rede exclusiva do hospedeiro (host-only) 84 Figura 16 - Configurações básicas para montagem das redes virtuais no VirtualBox - Tipos de placas de redes emuladas pelo VirtualBox 84 Figura 17 - Topologia de experimentação GGC 85 Figura 18 - Topologias de Experimentação em Hipervisores de Tipo-I - Guest-to-Guest-to-Container (GGC) 88 Figura 19 - Topologias de Experimentação em Hipervisores de Tipo-I - Guest-to-Guest (GG) 88 Figura 20 - Fronteira de eficiência e PPS do Modelo CCR com orientação às 111 saídas Figura 21 - Fronteira de eficiência e PPS do Modelo SMDEA com orientação 112
às saídas Figura 22 - PPS do Modelo WMDEA 121 Figura 23 - Fronteira de eficiência e PPS do Modelo WDEA 121 Figura 24 - Fronteira de eficiência com raio ilimitado do Modelo WMDEA 122 Figura 25 - Fronteira de eficiência com raio ilimitado do Modelo WDEA 122 Figura 26 - Preços do Amazon Elastic Cloud Computing (EC2) 125 Figura 27 - Super-Cobb-Douglas DEA CCR-I 140 Figura 28 - Modelo Super-CCR-I DEA 140 Figura 29 - Super-Cobb-Douglas DEA CCR-I destacando DMUs (com rótulos) 140
LISTA DE QUADROS
Quadro 1 - Escalas de comparação de desempenho entre estratégias de virtualização 40 Quadro 2 - Escalas de comparação de desempenho entre estratégias de virtualização 42 Quadro 3 - Código da implementação do parâmetro de Hurst no R. 90
LISTA DE TABELAS
Tabela 1 - Comparação da AS em redes de computadores tradicionais versus nossa pesquisa 54 Tabela 2 - Exemplo do problema da proporcionalidade em modelos DEA padrão 71 Tabela 3 - Versões e características dos Softwares e SOs usados nas medições GGC 86 Tabela 4 - Matriz de Correlação das variáveis do cenário 1 – avaliação estática – sem transformação logarítmica 91 Tabela 5 - Matriz de Correlação das variáveis do cenário 1 – avaliação estática – com transformação logarítmica. 91 Tabela 6 - Matriz de Correlação das variáveis do cenário 2 – sem transformação logarítmica 92 Tabela 7 - Matriz de Correlação das variáveis do cenário 2 – com transformação logarítmica 92 Tabela 8 - Equações dos modelos multiplicativos e de supereficiência multiplicativo DEA (SMDEA) com CRS e orientação à saída 95 propostos Tabela 9 - Fórmulas usadas para computar alguns índices do modelo de janela multiplicativo DEA 98 Tabela 10 - Variáveis de Entrada e Saída – Cenário 1 e 2 – Estático 103 Tabela 11 - Variáveis de Entrada e Saída – Cenário 1 – Dinâmico 103 Tabela 12 - Montagem das DMUs para avaliação com modelos multiplicativos DEA estáticos orientados à saída, além da avaliação fractal dos resultados sem as DMUs com SRD 105 Tabela 13 - Montagem das DMUs para avaliação com modelos multiplicativos DEA estáticos orientados à saída, após a transformação logarítmica das variáveis de entrada e saída 107
Tabela 14 - , eficiência, análise de sensibilidade e classificação de cada DMU no modelo de avaliação SMDEA 109 Tabela 15 - Série temporal 1 de 10 da avaliação de desempenho fractal nas redes virtuais 113 Tabela 16 - Série temporal 10 de 10 da avaliação de desempenho fractal nas
redes virtuais 115 Tabela 17 - Média dos escores de eficiêmcia por janela e por DMU calculados usando o modelo de Janela Multiplicativo DEA 117 Tabela 18 - Cinco DMUs selecionadas para mostrar os resultados do modelo original de Janela DEA 119 Tabela 19 - Comparação percentual entre as DMUs selecionadas do modelo de janela multiplicativo DEA (Tabela 17) versus a formulação original de Janela DEA (Tabela 18) 120 Tabela 20 - Ranqueamento das TOP5 DMUs segundo modelo WMDEA 123 Tabela 21 - Análise de desempenho fractal por configuração/DMU em um 127 hipervisor de tipo-I. Tabela 22 - Lista de publicações científicas no período do doutorado 146 Tabela 23 - Contendo respectivamente os gráficos do histograma, periodograma e ACF das DMUs mais eficientes segundo o modelo SMDEA CCR-O 164 Tabela 24 - Contendo respectivamente os gráficos do histograma, periodograma e ACF das DMUs mais eficientes, segundo o modelo WMDEA CCR-I, em cada uma das dez séries temporais usadas para análise em janelas 165 Tabela 25 - Contendo respectivamente os gráficos do Histograma, Periodograma e ACF das DMUs mais eficientes segundo o modelo Super-Cobb-Douglas CCR-I 176
ABREVIAÇÕES
ACF Auto-Correlation Function
AIMD Additive Increase, Multiplicative Decrease
AHP Analytical Hierarchy Process
API Application Program Interface
ARP Address Resolution Protocol
AS Autossimilaridade
BCC Banker, Charnes & Cooper
CapEx Capital Expenditure
CCR Charnes, Cooper & Rhodes
CSP Cloud Services Providers
CRS Constant Return to Scale
DEA Data Envelopment Analysis
DevOps Development Operators
DFA Detrended-FluctuactionAnalsysis
DMU Decision-Making Unit
DPI Deep Packet Inspection
DUT Device Under Test
EB Efficient Bandwidth
ECDF Empirical Cumulative Distribution Function
FBM Fractal-Brownian Motion (FbM)
FDH FreeDisposal Hull
FDC Função de Distribuição Cumulativa
FDEC Função de Distribuição Empírica Cumulativa
FDP Função de Distribuição de Probabilidade
IaaS Infrastructure as a Service
IETF Internet Engineering Task-Force
IP Internet Protocol
IPC Inter-Process Commnunication
ITE Isolated Test Environment
LRD Long-Range Dependency
MCDM Multi-Criteria Decision-Making
ME-DEA Multiplicative Environmental Data Envelopment Analysis
MLE Maximum Likelihood Estimator
MPSS Most Productive Scale Size
MNCP Multiplicative Non-Parametric Corporate Performance
NOS Network Operating System
NS Network Simulator
PL Programação Linear
PO Pesquisa Operacional
PoC Proof-of-Concept
PPS Production Possibility Set
PR Potential Ratio
R/S Rescaled Range Analysis
QoS Quality-of-Services
RFC Requests for Comments
RPG Raw Packet Generator
SBM Slack-Based Model
SCTP Stream Control Transmission Protocol
SDEA Super-Efficiency DEA
SDN Software-Defined Network
SDNFV Sofware-Defined Network With Function Virtualization
SE Supereficiente
SLA Service-Level Agreement
SKI Single Kernel Image
SO Sistema Operacional
SMDEA Supereficiência Multiplicativo DEA
SRD Short-Range Dependency
SR-IOV Single Root – I/O Virtualization
TCP Transmission Control Protocol
TPA Third Party Audit vCPU Virtual CPU veth Virtual Ethernet
VIF Virtual Interface
VMM Virtual Machine Monitor
VRS Variable Return To Scale
UDP User Datagram Protocol vNIC Virtual Network Interface Card (vNIC)
WDEA Windows DEA
WMDEA Windows Multiplicative DEA (WMDEA)
SUMÁRIO
1 INTRODUÇÃO ...... 21 1.1 Motivação e Contextualização ...... 25 1.2 Hipótese e questões de partida ...... 29 1.3 Objetivos ...... 30 1.4 Estrutura da Tese ...... 31 2 REFERENCIAL TEÓRICO ...... 32 2.1 Avaliação de Desempenho ...... 32 2.2 Virtualização ...... 34 2.2.1 Contêineres de Virtualização ...... 39 2.3 Virtualização de Redes ...... 43 2.4 Autossimilaridade...... 46 2.4.1 Autossimilaridade nas redes de computadores ...... 53 2.4.2 Novas Aplicações de Fractais em Redes ...... 55 2.5 Data Envelopment Analysis (DEA) ...... 58 2.5.1 Modelos multiplicativos DEA ...... 66 3 METODOLOGIA DE OTIMIZAÇÃO FRACTAL EM REDES VIRTUAIS ...... 75 3.1 Metodologia geral ...... 75 3.1.1 Análise de Desempenho de Dispositivos de Redes ...... 75 3.1.2 Framework de Avaliação de Desempenho por Etapas da Estrututra Fractal do Tráfego TCP em redes virtuais (Stepwise Performance Evaluation Framework of Fractal Structure of TCP traffic on Virtual Networks)...... 78 3.2 Cenários de experimentação ...... 82 3.2.1 Cenários de Experimentação 1 – Roteadores Virtuais...... 82 3.2.2 Cenários de Experimentação 2 – Roteadores Virtuais...... 87 3.3 Análise da Estrutura Fractal do Tráfego TCP nas redes virtuais ...... 89 3.4 Geração das fronteiras de eficiência dos modelos multiplicativos DEA ...... 90 4 MODELOS MULTIPLICATIVOS DEA PROPOSTOS ...... 93 4.1. Cenário 1 – Medições com hipervisores de tipo-II ...... 93 4.1.1 Modelos multiplicativos estáticos com CRS ...... 93 4.1.2 Modelo multiplicativo dinâmico com CRS ou de janela multiplicativo (Windows multiplicative DEA model) com orientação às saídas ...... 96 4.2 Cenário 2 – Medições escaladas em Hipervisor de Tipo-I ...... 101 4.2.1 Modelo estático orientado à entrada – Super-Cobb-Douglas com CRS ...... 101 5 ANÁLISE DOS RESULTADOS ...... 103 5.1 Cenário 1 – Medições com hipervisores de Tipo-II ...... 103 5.1.1 Modelo SMDEA com CRS orientado às saídas ...... 103 5.1.3 Modelo de Janela Multiplicativo com CRS ...... 112 5.2 Cenário 2 – Medições escaladas com hipervisores de Tipo-I ...... 124 5.2.1 Caracterização do Problema ...... 124 5.2.2 Modelo Super-Cobb-Douglas orientado à entrada com CRS ...... 126 6 CONSIDERAÇÕES FINAIS ...... 142 6.1 Conclusão e trabalhos futuros ...... 142 6.2 Publicações científicas...... 146 REFERÊNCIAS ...... 148
APÊNDICE A – ANÁLISE EXPLORATÓRIA DOS DADOS ...... 163 APÊNDICE B - CENÁRIO I – SMDEA CCR-O ...... 164 APÊNDICE C - CENÁRIO I – WMDEA – CRS CCR-I ...... 165 APÊNDICE D - CENÁRIO II – SUPER-COBB-DOUGLAS CCR-I ...... 176
21
1 INTRODUÇÃO
Este capítulo introduz o trabalho doutoral e relata as principais motivações para a sua realização. Ademais, é apresentada a justificativa, bem como a lista dos objetivos almejados, além demostrar como está estruturada a tese. A virtualização é uma abstração de software capaz de particionar os recursos de hardware de forma isolada entre diversas máquinas virtuais (virtual machines (VMs)). O objetivo da virtualização é permitir a portabilidade de funções de mais alto nível, além do compartilhamento e/ou agregação de recursos físicos (SAHOO; MOHAPATRA; LATH, 2010). De acordo com Chowdhury; Boutaba (2010), a virtualização de rede é o principal componente da infraestrutura dos datacenters, bem como para os provedores de serviços em computação em nuvem (cloud services providers (CSP)). Segundo Khan et al. (2012), a analogia entre a virtualização de SO com a de rede fez com que os autores chamassem a virtualização de rede de “hipervisor para a Internet”. Contudo, apesar das vantagens da virtualização, como a consolidação de servidores e armazenamento, esta pode afetar o desempenho da rede quando a infraestrutura da nuvem for dividida entre múltiplos inquilinos. No artigo de Casado et al. (2010) afirma- se que o papel de um hipervisor de rede é determinar como implementar a desejada funcionalidade lógica, através da configuração da rede física. Assim, o hipervisor de rede deveria ser visto como o ponto onde a rede lógica é mapeada para dentro da rede física. Alternativamente, a virtualização leve, ou baseada em contêiner, é um dos tipos de virtualização na qual os processos e dispositivos do kernel do sistema operacional (SO) convidado (guest) são compartilhados para execução de instâncias/fatias do mesmo SO, que atuam como contêineres executados em paralelo (SAHOO et al., 2010). Uma avaliação de estratégias para ativar roteadores virtuais abertos mostrou que as tecnologias de virtualização mais proeminentes são àquelas que usaram a abordagem com contêineres (RATHORE; HIDELL; SJÖDIN, 2011). Portanto, as tecnologias de virtualização, baseadas em contêineres, são a chave para se alcançar a escalabilidade e desempenho em relação ao aumento do número de nós de computação, com melhor performance de rede, representando uma economia de escala, também chamada de Capital Expenditure (CapEx). Desta forma, este trabalho 22 usou contêineres como uma das peças na montagem dos hipervisores de redes virtuais. O trabalho de Ha; Lopez-Pacheco; Urvoy-Keller (2013) afirma que a raiz para um tráfego de rede mais justo é encontrar o melhor switch virtual dentro da infraestrutura virtual. No entanto, esta tese afirma que a sintonia fina das infraestruturas de redes virtuais é primordial para garantir serviços mais adequados aos clientes. Por isso, o entendimento do comportamento do tráfego do principal protocolo de transporte – transmission control protocol (TCP) – em infraestruturas de redes virtuais ao longo do tempo, detém papel crucial na predição estocástica deum arcabouço de software para prestar serviços otimizados. De fato, é notório que o protocolo TCP fornece serviços de tráfego fim a fim dos dados na camada de transporte. Logo, ao se implementar uma aplicação que ofereça serviços na Internet, esta não precisa tratar da complexidade de prover um canal de comunicação confiável, para garantir que os dados cheguem corretamente e em ordem no destino final, mesmo ao atravessar redes congestionadas e remotas, pois este é o papel do TCP. O trabalho de Cronkite-Ratcliff et al. (2016) introduziu um mecanismo para modular o comportamento do TCP nas redes virtuais chamado de virtualized congestion control (vCC). Segundo os autores, o vCC permite que o dono do datacenter ative um novo algoritmo de controle de congestionamento em seus hipervisores de rede virtual. Esta abordagem suporta soluções customizadas pelos inquilinos, com hipervisores e aplicativos personalizados, de acordo com poucas abordagens de controle de congestionamento do TCP avaliadas. Essa estratégia permitia uma tradução entre o novo algoritmo de controle de congestionamento e um mecanismo de controle de congestionamento legado, permitindo que os aplicativos legados aproveitem os benefícios de aumentar sua capacidade na camada de transporte, ao usar a melhor das estratégias comparadas. Diante da lacuna científica na predição do melhor serviço de transporte em redes virtuais, esta tese desenvolveu uma ferramenta analítica capaz de ajustar estocasticamente o comportamento do TCP de hipervisores de rede, otimizando o controle de fluxo nas redes virtuais que devem seguir este melhor padrão estatístico ao transportar os serviços dos inquilinos, de forma mais eficiente, ao longo do tempo. O comportamento tradicional do tráfego de rede tem sido amplamente analisado, baseado nas descobertas da autossimilaridade (AS), em diversos ambientes, segundo trabalhos seminais sobre fractais nas telecomunicações (MANDELBROT, 1965), 23 tráfego Ethernet (LELAND; TAQQU; WILSON, 1994) e tráfego web (CROVELLA; BESTAVROS, 1997), dentre outros. Todos esses estudos anteriores, que provararm que o tráfego de rede é estatisticamente autossimilar com dependência de longo alcance (long-range dependency (LRD)), demonstraram a existência deste padrão estocástico avaliando apenas uma configuração de rede por um longo período de tempo. Desta forma, as avaliações anteriores trouxeram análises só de uma grande e única série temporal. Portanto, uma das contribuições desta tese é mostrar que todos os hipervisores de redes avaliados, como unidades tomadoras de decisão (decision-making unit (DMU)), têm um comportamento fractal distinto relativo ao tráfego do TCP. Ainda de acordo com os trabalhos acima citados, o tráfego AS com LRD tinha implicações perigosas para o projeto, controle e análise de redes de alta velocidade. Contudo, até esta tese, uma profunda análise da estrutura fractal do tráfego de redes virtuais ainda não tinha sido propriamente realizada pela indústria ou academia. Outra contribuição desta tese é a introdução da dimensão fractal, ou dimensão de Hausdorff, como medida de suavidade/irregularidade para avaliar o tráfego TCP. Outrossim, esse índice fractal é aplicado como variável de decisão para predição de séries temporais nas redes virtuais. Portanto, a dimensão fractal é um índice robusto de suavidade ou irregularidade, porque não varia quando uma série temporal é dimensionada, traduzida ou corrompida por qualquer ruído, bem como não é estacionária (LLOYD; BERBEROGLU; CURRAN et al., 2004). Outra medida para atestar a AS com LRD usado como variável de decisão é o parâmetro de Hurst ou memória fractal. As duas variáveis já elencadas estão relacionadas à teoria dos fractais e, neste sentido, uma compreensão profunda do comportamento autossimilar de cada infraestrutura de rede virtual é obrigatória. O objetivo desta análise é realizar uma correta avaliação de desempenho entre as opções disponíveis, além de predizer a decisão mais correta em um vasto conjunto de dados comparados. De fato, este é um problema multicritério a ser resolvido e uma técnica de pesquisa operacional (PO) deve ser aplicada para resolver esta complexa questão matemática. No contexto de redes ou sistemas computacionais, essas técnicas são nomeadas como ferramentas de otimização de rede. Consistem, pois, em um conjunto de problemas multicritérios de redes, resolvidos por formulações de programação linear, onde múltiplos objetivos desejáveis competem entre si, em que o tomador de 24 decisão tem que eleger uma dentre várias soluções avaliadas (IQBAL; NAEEM; ANPALAGAN et al., 2016). A técnica de tomada de decisão multicritério (multi-criteria decision-making (MCDM)), escolhida para otimização de rede, foi a análise envoltória de dados (data envelopment analysis (DEA)), criada por Charnes, Cooper; Rhodes (1978). DEA é geralmente empregada em problemas relacionados à produção em administração de empresas, educação, cadeia de suprimentos, big data, indústria e assim por diante (EMROUZNEJAD; YANG, 2017). Devido a sua natureza de otimização das variáveis de entrada e saída, DEA ora procura minimizar as variáveis de entrada, ou maximizar as variáveis de saídas, ou ambas simultaneamente, dependendo do modelo e orientação usados para resolver cada problema. No entanto, os modelos tradicionais da DEA não são recomendados quando as variáveis em análise são números reais ou resultados de proporções/razões (ratios). Para sanar este problema da técnica DEA com variáveis em forma de razão, foram propostos modelos multiplicativos por Seiford; Charnes; Cooper; Stutz (1982). Os modelos multiplicativos DEA são apropriados para tratar a elasticidade de escala usando variáveis de razão, ou seja, foram projetados para trabalhar com problemas que exibem uma fronteira de eficiência log-linear com partes côncavas e convexas simultaneamente (BANKER; COOPER; SEIFORD et al., 2004). Comumente, DEA é usada para avaliar a eficiência de cada DMU em um único período de tempo estaticamente. Porém, quando os dados das séries temporais estão disponíveis, é possível usar DEA para avaliar um conjunto de DMUs, ao longo do tempo, dinamicamente. O primeiro desses modelos inter-temporal desenvolvido foi o de análise em janela (windows analysis) (CHARNES; CLARK; COOPER et al., 1984). Enfim, outra contribuição deste trabalho é a concepção de dois modelos multiplicativos estáticos e um dinâmico da DEA para otimização/predição de serviços de tráfego TCP em infraestrutura de redes virtuais, segundo as variáveis fractais escolhidas. Outra contribuição foi a introdução de uma metodologia de avaliação de desempenho, baseada na análise das estruturas fractais do TCP acerca dos hipervisores de redes. Esta metodologia também pode ser empregada como um sistema especialista, capaz de resolver problemas complexos como um especialista humano (MARTÍN DE DIEGO; SIORDIA; FERNÁNDEZ-ISABEL et al., 2019). O objetivo desse sistema especialista é aplicar os modelos multiplicativos DEA como mecanismos de inferência, com o intuito de predizer, dentre as diversas séries temporais analisadas, qual o melhor padrão fractal do tráfego TCP entre as 25 configurações em análise. Em suma, a aplicação desta metodologia atua como um hipervisor matemático para otimizar o tráfego TCP nas redes virtuais. Enfim, o uso deste modelo analítico possibilita ao tomador de decisão escolher qual seria o hipervisor de rede ótimo, fomentando a melhor forma de criar uma rede virtual para fornecer serviços usando o TCP, pois, ao se eleger a configuração mais eficiente, tem-se a garantia estocástica de se levar um maior volume de tráfego, com estabilidade do comportamento da camada de transporte, por um maior período de tempo.
1.1 Motivação e Contextualização
Técnicas de avaliação de desempenho são essenciais para planejar como serão prestados os serviços estocasticamente. Segundo Jain (1991), existem três técnicas para se avaliar o desempenho de um sistema, são elas: a) medição; b) simulação, e; c) modelagem analítica. Contudo, as medições representam avaliações mais reais de um sistema em funcionamento, sendo usadas não só para fins comparativos, mas também para prover uma sintonia fina dos sistemas. A união de roteadores virtuais abertos com computadores pessoais é uma alternativa cada vez mais adotada para fazer com que cada VM possa atuar como um roteador virtual. Contudo, o uso de computadores pessoais, para este fim, pode trazer uma série de degradações de desempenho, o que, em alguns casos, pode comprometer o funcionamento normal da rede, ampliando seus efeitos para os demais serviços que dela dependem. Uma minuciosa avaliação de estratégias para ativação de roteadores virtuais abertos mostrou que as tecnologias de virtualização mais recomendadas, para criar roteadores virtuais, são àquelas que usam contêineres (RATHORE, 2013). É factual que nas redes tradicionais o comportamento fractal do tráfego já tenha sido bastante estudado, segundo várias tecnologias de interconexão. Contudo, a investigação da dimensão fractal no tráfego TCP, em infraestruturas de redes virtuais, até este estudo, ainda era ausente. Particularmente, os termos fractal e autossimilaridade (self-similarity) foram introduzidos por Mandelbrot (1965) que, inicialmente, apresentou o conceito em sistemas de telecomunicações. Em seguida, foi provado que a natureza tem um comportamento fractal ou autossimilar, através de aplicações em hidrologia e geofísica (MANDELBROT; WALLIS, 1969). O trabalho de Leland et al. (1994) demonstrou, inicialmente, que o tráfego 26
Ethernet é estatisticamente autossimilar, divergindo dos modelos de tráfego de rede até então usados. Assim, modelos matemáticos anteriores a AS não capturavam a natureza fractal do tráfego, gerando sérias implicações ao projeto, controle e análise de redes de alta velocidade, no qual a agregação de tráfego intensifica a característica de burstiness, em vez de suavizá-la. Como técnica de tomada de decisão multi-critério não-paramétrica, para otimização de redes, foi escolhida a data envelopment analysis (DEA). A natureza não- paramétrica da DEA permite que as variáveis em análise não necessitem ser convertidas antes da avaliação. Assim, não é preciso que as variáveis possuam uma unidade em comum (NAKANISHI; FALCOCCHIO, 2004). Ademais, DEA compara quaisquer entes produtivos como DMUs, com o intuito de apontar a eficiência, quem são os benchmarks (parceiros de excelência/referência) e como as DMUs avaliadas como ineficientes podem tornar-se eficientes, caso copiem o desempenho de seus benchmarks. Estas unidades, ou DMUs, em análise podem ser firmas avaliadas, escolas, roteadores virtuais, hotéis, dentre outros. DEA foi introduzida no trabalho de Charnes et al. (1978) com o intuito de avaliar estaticamente o desempenho de atividades ou organizações, através da análise de eficiência de unidades, associada a conceitos como produtividade e eficiência técnica. O modelo inicial recebeu o nome dos seus criadores Charnes, Cooper e Rhodes (CCR), sendo baseado numa fronteira de eficiência linear por partes, associada ao conceito de retornos constantes de escala (constant return to scale (CRS)). Já os modelos baseados no conceito de retorno variável de escala (variable return to scale (VRS)), introduzidos por Banker; Charnes; Cooper (1984), apresentam informações adicionais aos escores de eficiência por DMU. Enfim, tais modelos conseguem distinguir se cada DMU está operando eficientemente e corretamente, ou não. Em DEA, a eficiência técnica é usada para comparar o que foi produzido por uma unidade, com o que poderia ser produzido. Segundo Ferreira; Gomes (2009), a eficiência de escala resulta do nível de eficiência máxima mais adequada, em razão da tecnologia a ser adotada. A eficiência de escala é obtida através da razão entre a eficiência técnica do modelo CCR, sobre a eficiência técnica do modelo de Banker, Charnes; Cooper (BCC). Como DEA é baseada na geração de uma fronteira de eficiência Pareto- Koopmans, cada modelo deve possuir uma orientação, através do qual: a) caso seja orientado à entrada, busca a minimização proporcional das variáveis de entrada, sem 27 afetar as variáveis de saída; b) caso seja orientado à saída, objetiva a maximização proporcional das variáveis de saída, sem afetar as variáveis de entrada; e, c) caso seja sem-orientação ou não-radial, objetiva simultaneamente minimizar as variáveis de entrada e maximizar as variáveis de saída. Contudo, os modelos tradicionais da DEA retornam apenas se uma DMU é eficiente ou não, em um ponto no tempo, ou em uma única série temporal. Sendo assim, caso seja preciso ranqueá-las, o tomador de decisão deveria fazer uma análise de sensibilidade dos resultados DEA, segundo o modelo e orientação escolhido. Entretanto, Andersen; Petersen (1993) introduziram um modelo de ranqueamento entre as DMUs, denominado de modelo de supereficiência (super-efficiency DEA (SDEA)), que são idênticos aos DEA tradicionais, mas que retiram a DMU em análise do conjunto de equações lineares a serem avaliadas. Portanto, se em modelos tradicionais uma DMU é eficiente, então nos modelos SDEA esta DMU terá um escore de eficiência acima da unidade (>100%), pois a referida DMU, em análise, é retirada da sua própria avaliação. Assim, todas as DMUs possuem escores diferentes entre si, tornando esses modelos efetivos para ranqueamento. Adiante, DEA será pormenorizada, delineando suas aplicações, formalismos e a proposições de novos modelos multiplicativos para otimizar/predizer serviços TCP mais eficientes ao longo do tempo em redes virtuais, como se propõe este trabalho. Esses mesmos modelos tradicionais da DEA, que servem como base para criação de outros modelos mais complexos, possuem uma limitação quando as variáveis de entrada e saída, em análise, são números reais ou razões (ratios). Tal limitação é relacionada, principalmente, aos axiomas da convexidade e da proporcionalidade que geram escores de eficiência inacurados (EMROUZNEJAD; AMIN, 2009). Desta forma, para contornar estas limitações, faz-se necessário, segundo Banker; Maindiratta (1986), trocar a fronteira linear por partes, dos modelos tradicionais, por uma fronteira com pedaços log-lineares denominada de fronteira geométrica. Modelos multiplicativos DEA foram introduzidos no trabalho de Seiford et al. (1982), com o propósito de retificar os modelos tradicionais DEA, para gerarem escores de eficiência acurados, quando as variáveis de entrada e/ou de saída são razões, a fim de que esses obedeçam também aos axiomas do raio ilimitado, extrapolação mínima, dentre outros que serão explicados adiante. O modelo de análise de janelas (window analysis) DEA foi desenvolvido por 28
Charnes et al. (1984), com o intuito de usar os modelos tradicionais para avaliar as DMUs em janelas de tempo independentes entre si, de forma intertemporal e dinâmica. Logo, como o modelo de janelas DEA é baseado em modelos tradicionais, caso as variáveis de entrada e/ou de saída sejam razões, é necessário convertê-lo para um modelo multiplicativo que, até este trabalho, ainda não havia sido proposto. As variáveis de entrada e saída dos modelos multiplicativos DEA desenvolvidos foram adquiridas através da investigação do tráfego TCP, em ambientes de redes virtuais. As medições obedecem às metodologias de avaliação de dispositivos de redes chamadas de requests for comments (RFC), de números 2544 e 6815. Após análise exploratória das variáveis aleatórias contínuas, obtidas nas medições, vislumbrou-se a presença de funções de distribuição/densidade de probabilidade (FDP) de cauda pesada (heavy tail) que remetem a um padrão log-logístico (Ex: Cauchy, Dagum, Burr, Kumaraswamy, Pareto, etc.). Esta proposta de tese também visa mostrar como realizar uma avaliação da estrutura fractal do TCP nos hipervisores de redes, analisados como DMUs, pelos modelos DEA propostos. A avaliação fractal desenvolvida atesta que cada configuração, ao fornecer serviços de tráfego com TCP nas redes virtuais, possui dimensão fractal, média de largura de banda e memória fractal distintas. Então, se o tomador de decisão tiver um ferramental formal disponível para eleger qual das configurações avaliadas é a mais eficiente de todas, ao longo do tempo, logo poderá predizer qual o melhor dispositivo para prestação dos serviços TCP nas redes virtuais. Assim, ao usar a configuração mais eficiente na infraestrutura de rede virtual, serão entregues serviços de tráfego TCP fim a fim com desempenho superior da largura de banda e comportamento mais estável da camada de transporte ao longo do tempo. Portanto, este problema multicritério necessita de uma técnica de MCDM ajustada para apontar uma solução otimizada, na prestação de serviços de rede virtuais, ao longo do tempo. Resumindo, esta tese tem o objetivo de analisar ambientes de rede virtualizadas, em uma perspectiva autossimilar, e propor um framework de avaliação, como um sistema especialista que adquire seu conhecimento nas medições em redes virtuais. Em seguida, as regras de avaliação fractal, por hipervisor de rede, determinam a representação do conhecimento. Os modelos multiplicativos DEA, aqui lançados, atuam como mecanismos de inferência, servindo para avaliar todas as possibilidades e 29 prever qual é o melhor conjunto de ferramentas, que possa oferecer serviços de rede virtual com desempenho superior da largura de banda e estabilidade do tráfego TCP. Enfim, a aplicação das técnicas de otimização de rede propostas garantirá a satisfação do cliente, pela qualidade de experiência nos serviços e melhor provisionamento de rede em uma maior escala de tempo.
1.2 Hipótese e questões de partida
No contexto no qual o consumo de serviços em ambientes de rede virtuais tende só a crescer, com a popularização dos serviços na computação em nuvens, faz-se necessária a sintonia fina da infraestrutura virtual para se prestar serviços otimizados por um maior período de tempo. Todavia, é necessário que sejam respeitados contratos entre as partes denominados service-level agreements (SLA), bem como é recomendável que os serviços ofertados sejam entregues sem a presença de alta variabilidade no tráfego TCP, causado pelo efeito de suavização ou irregularidade presentes na AS, que possui memória e, consequentemente, tem LRD. Vale ressaltar que até este momento nenhum trabalho mostrou que o tráfego TCP em ambientes de rede virtuais é AS, com desempenho da largura de banda do TCP, dimensão e memória fractal distintos por dispositivo avaliados como hipervisores de rede. Tampouco, que modelos DEA podem ser aplicados para predizer o melhor conjunto de ferramentas para minimizar os efeitos da AS e, ao mesmo tempo, ofertar serviços mais estáveis com desempenho superior da largura de banda do TCP. Dessa forma, este trabalho será desenvolvido com base na seguinte hipótese: 1) Desenvolvimento de um hipervisor matemático como um framework de avaliação da estrutura fractal do tráfego TCP, que atua na avaliação e otimização de redes virtuais visando a predição da configuração com maior volume de tráfego transferido, segundo a largura de banda do TCP, aliado a um comportamento estável da camada de transporte ao longo do tempo.
Diante dessa hipótese, surgem algumas questões de partida (QP) para o desenvolvimento desta tese. São elas: 1) QP01– Qual o comportamento da estrutura fractal do tráfego TCP, usando diferentes estratégias de virtualização em infraestruturas de redes virtuais? 2) QP02 – Como a AS se comporta diante do aumento de escala de hardware (VMs, componentes de software) em geral? 30
3) QP03 – É possível construir modelos DEA acurados que possam, ao mesmo tempo, minimizar os efeitos da AS, bem como maximizar a largura de banda do TCP para prestação de serviços otimizados em redes virtuais em uma maior escala de tempo? 4) QP04 – É factível desenvolver um framework de avaliação de desempenho, baseado em análise fractal e MCDM, com o objetivo de apontar qual a melhor solução, em relação às demais, para prestação de serviços TCP em redes virtuais ao longo do tempo?
1.3 Objetivos
Diante do que foi exposto, este trabalho apresenta o seguinte objetivo geral: Desenvolver um framework de avaliação de desempenho, como um sistema especialista, baseado em análise da estrutura fractal do tráfego fim a fim e na aplicação de modelos multiplicativos DEA estáticos e dinâmico ajustados, como mecanismo de inferência, para fomentar a prestação de serviços otimizados de tráfego TCP em redes virtuais. Enfim, predizer a DMU mais eficiente dentre as avaliadas, garantindo aos clientes serviços TCP mais estáveis e com desempenho de largura de banda do TCP superior, por um longo período de tempo em infraestruturas de redes virtuais.
Adicionalmente, além do objetivo geral apresentado, alguns objetivos específicos (OE) devem ser destacados: 1) OE01 – Investigar se todo o tráfego TCP, em diversos ambientes, topologias, escalas e componentes de hardware/software em redes virtuais é autossimilar com LRD e quais são as causas (QP01, QP02). 2) OE02 – Selecionar as melhores variáveis decisórias de entrada e saída relacionadas ao problema, para eleger dentre todas as configurações a mais eficiente, para prestação de serviços TCP em redes virtuais ao longo do tempo (QP03, QP04). 3) OE03 – Investigar modelos e orientações DEA que criem as melhores fronteiras de eficiência para selecionar componentes otimizados em ambientes de redes virtuais usando o TCP, segundo as variáveis de decisão escolhidas (QP03, QP04). 4) OE04 – Implementar e avaliar os modelos multiplicativos DEA estáticos e dinâmico ajustados para montagem de ambientes de redes virtuais otimizados 31
usando o TCP (QP03, QP04). 1.4 Estrutura da Tese
Diante da motivação e contextualização apresentadas, considerando a hipótese, questões de partida, objetivo geral e objetivos específicos, o restante desta tes e está organizada da seguinte maneira:
No Capítulo 2, será apresentado o referencial teórico sobre as principais tecnologias e alguns trabalhos relacionados à tese. Neste caso, os conceitos e os trabalhos relacionados à avaliação de desempenho e otimização, virtualização, tecnologias de contêineres de virtualização que serão usadas para montagem dos experimentos. Será apresentado, com detalhes, a AS, dimensão fractal e temas referentes à avaliação fractal em redes de computadores. Finalmente, mostra a DEA e os modelos multiplicativos usados para um ranqueamento mais acurado e que foram usados para geração das fronteiras de eficiência, que refletem os anseios do tomador de decisão. No Capítulo 3, é descrito todo o framework de avaliação fractal de desempenho, ou seja, a metodologia usada por esta proposta de tese como sistema especialista para se provar a hipótese levantada. Neste, é apresentado um fluxograma algorítmico, no qual as camadas da metodologia e os seus processos são pormenorizados. Todavia, serão descritas as topologias de experimentação criadas para se avaliar o tráfego TCP nas redes virtuais. Ademais, é detalhado todo o arcabouço ferramental de hardware e software usados nas medições, em conformidade com as RFCs 2544 e 6815. O Capítulo 4 apresenta os resultados obtidos por esta tese. Assim, os resultados são agregados, ranqueados e analisados segundo os modelos multiplicativos DEA aqui desenvolvidos. Finalmente, o Capítulo 5 dedica-se às conclusões e considerações finais, além dos trabalhos futuros oriundos deste trabalho doutoral.
32
2 REFERENCIAL TEÓRICO
Este capítulo apresenta inicialmente os principais conceitos envolvidos com o arcabouço de redes virtuais, partindo de uma visão geral sobre a virtualização, seu surgimento, tipos e ferramentas. Também, a autossimilaridade seus formalismos, dimensão fractal, causas e efeitos serão apresentados, bem como sua presença nas redes de computadores. Finalmente, será apresentada a técnica de avaliação não- paramétrica DEA com suas formas, orientações, além de apresentar os modelos multiplicativos e seus princípios basilares, adequados aos objetivos deste trabalho.
2.1 Avaliação de Desempenho
Avaliar o desempenho consiste em uma combinação de medições e interpretações que visam ao estudo da capacidade de comunicação de um sistema (ou parte dele), de acordo com métricas como velocidade, atraso (latência), números de cálculos por intervalo de tempo, etc. (LILJA, 2000). A avaliação de desempenho, nas redes de computadores, vem passando por constante escrutínio acadêmico, profissional e mercadológico para prestar serviços com maior “eficiência”. Cada serviço ou sistema é comparado, segundo métrica previamente definida, com o intuito de prover informações comparativas para tomada de decisão. Essas avaliações nas redes podem ser feitas por análises comparativas, que geralmente são relacionadas à largura de banda ou taxa de transferência, disponibilidade e qualidade com que as ferramentas ou serviços se comunicam, dentre outros fatores. Técnicas de medição vêm sendo desenvolvidas com o objetivo de perturbar minimamente o funcionamento dos sistemas, enquanto fornecem acurácia, precisão e reprodutibilidade dos resultados. Ao montar os cenários de experimentação e, em seguida, aplicar tais técnicas, é necessária uma criteriosa análise estatística e exploratória dos dados coletados para que os resultados capturados sejam corretamente interpretados. O processo de análise de desempenho de sistemas ou de componentes é dependente da habilidade, experiência e interesses do analista. Neste contexto, Lilja (2000) identifica alguns objetivos comuns da análise de desempenho, tais como: a) comparação de alternativas – provimento de informações quantitativas sobre quais configurações são melhores que outras em certas condições; 33
b) determinar o impacto de uma funcionalidade (feature) – analisando o impacto da inserção ou remoção de um componente em um dado sistema; c) sintonia fina do sistema (system fine-tuning) – encontrar os melhores componentes que produzem a melhor configuração geral do sistema; d) identificar o desempenho relativo – quantificar a mudança de desempenho relativa ao histórico evolutivo de um sistema, ou seja, avaliar se a versão mais recente de um software tem um desempenho melhor ou pior do que a versão anterior. Além disso, pode-se quantificar o desempenho relativo às expectativas dos clientes, ou mesmo de sistemas dos competidores, e; e) definir expectativas – analisa o que o sistema se propõe a fazer. As principais técnicas de avaliação que podem ser usadas para se comparar o desempenho de sistemas são (JAIN, 1991): Medições: técnica que geralmente apresenta os melhores resultados, pois, ao se usar as ferramentas corretas, nenhuma suposição adicional é necessária, o que torna os resultados desta técnica mais críveis para especialistas. Lilja (2000) afirma que esta técnica tem baixa flexibilidade para montagem de cenários de experimentação, porém, especificamente nos ambientes virtualizados essa premissa não se aplica, porque se consegue elasticamente aprovisionar recursos e, por conseguinte, montar cenários diferentes mais facilmente. Contudo, faz-se necessário bastante tempo, tanto para realização dos experimentos, quanto para interpretação dos resultados, casos estes também não tenham sido automatizados, o que não foi o caso desta tese.
Simulação: utiliza programas computacionais desenvolvidos para modelar algumas características do sistema em análise. Os custos da simulação são o tempo e o esforço necessários para escrever, modificar e debugar programas de simulação, além do tempo para execução das simulações. Outra limitação é que nem toda característica de um sistema poderá ser modelada, limitando a técnica. Entretanto, não é necessário um investimento em equipamentos para fins da montagem dos cenários de comparação, pois se faz necessário apenas o hardware mínimo para execução dos programas de simulação.
Modelagem analítica: descrição matemática ou formal de um sistema. Logo, esta técnica fornece um rápido ensaio comportamental do sistema (ou 34
parte dele). Tal modelagem é adquirida após a interpretação matemática dos dados obtidos, atrelada a uma definição formal acerca dos resultados das técnicas anteriores. Assim, a modelagem analítica é o primeiro passo para se construir ambientes de simulação.
Ainda de acordo com Lilja (2000), as métricas de desempenho devem: a) contar o número de vezes que um dado evento ocorre (por exemplo: largura de banda, atraso, instruções de entrada/saída, número de cálculos por unidade de tempo, etc.); b) possuir a duração de certo intervalo de tempo; e, c) medir o tamanho de algum parâmetro. Segundo Lilja (2000), as principais propriedades das métricas a serem elencadas nas avaliações são: i) linearidade – ao se dobrar o tamanho da memória, o desempenho do sistema melhora em quanto percentualmente? ii) confiabilidade – os resultados gerados possuem credibilidade estocástica, i.e., se um sistema A sempre supera um sistema B ao executar uma certa aplicação em um período de tempo; iii) repetibilidade – quando os resultados dos experimentos tendem a se repetir, de acordo com um dado nível de confiança, ou seja, se ao longo do tempo a métrica é determinística; iv) facilidade de medição – diretamente proporcional a quantidade de ferramentas disponíveis para se conseguir obter os valores acerca das métricas de um experimento; v) consistência – as unidades usadas podem ser replicadas para comparar outros sistemas, e; vi) independência. Enfim, uma das principais contribuições desta tese é criar uma ferramenta de tomada de decisão multicritério, para montagem de infraestruturas de redes virtuais com tráfego TCP otimizado na prestação destes serviços. Logo, o hipervisor matemático proposto é capaz de avaliar o desempenho de hipervisores de redes, baseado em medições e avaliação da estrutura fractal do tráfego TCP, usando os modelos multiplicativos DEA desenvolvidos para predizer/eleger, dentre todas as configurações avaliadas, qual a que possui o contrato fim a fim mais eficiente para prestação de serviços de rede virtuais, usando o TCP.
2.2 Virtualização
A virtualização consiste em estender ou trocar um recurso (CPU, memória, armazenamento), ou interface (de rede ou uma application program interface (API)), existente por um(a) outro(a) que tenta imitar seu comportamento. Logo, é uma técnica 35 que possibilita a divisão de um único sistema computacional em diversos outros chamados de máquinas virtuais. O termo monitor de máquina virtual (virtual machine monitor (VMM)) surgiu na segunda metade da década de 60 do século passado nos laboratórios da IBM, para fomentar o funcionamento dos SOs de tempo compartilhado (time sharing). Assim, o VMM funcionava como uma camada de software capaz de particionar recursos físicos de uma máquina em partes de software, denominadas de máquinas virtuais (ROSENBLUM; GARFINKEL, 2005). O trabalho de Popek; Goldberg (1974) aponta que os VMMs tinham três características essenciais que são: 1) imitação de comportamento – em que o VMM provém um ambiente idêntico ao da máquina física, com as devidas diferenças causadas pela indisponibilidade de recursos, além de algumas diferenças causadas pelas dependências do tempo compartilhado; 2) eficiência – programas que são executados nestes ambientes possuem desempenho levemente pior que suas execuções diretas em máquinas reais e que garantem uma economia de capital; e, 3) isolamento – o VMM tem controle completo dos recursos do sistema, caso: a) não é possível que uma aplicação sendo executada dentro da VMM acesse recursos não explicitamente alocados a ela; e, b) é possível sobre certas circunstâncias que a VMM recupere o controle de recursos já alocados. Segundo Williams (2007), os objetivos da virtualização são: i) adicionar uma camada de abstração entre as aplicações e o hardware; ii) permitir redução nos custos em infraestrutura de servidores; iii) prover isolamento de recursos para aumentar a confiabilidade e segurança do ambiente virtualizado; iv) melhorar (manter) o nível e a qualidade dos serviços; v) alinhar, mais eficientemente, os processos da tecnologia da informação (TI) com as necessidades das empresas/clientes; e, vi) eliminar a redundância, maximizando a utilização, de infraestruturas de TI. O hipervisor é o nome popular atribuído ao VMM. Para ativar várias formas de virtualização, existem diversos tipos de hipervisores que, segundo Sahoo et al.(2010) podem ser: Virtualização completa ou full-virtualization – O VMM é chamado de virtual machine manager e está localizado acima do SO hospedeiro ou host, em que o SO guest roda no topo do hardware virtualizado provido pelo VMM. Assim, os dispositivos de entrada/saída serão alocados ao SO guest que imitará os recursos físicos no hipervisor e, então, fará com que o SO host tenha acesso ao hardware virtualizado. Uma das suas desvantagens é ter uma queda de 36
desempenho de 30% em relação à execução direta no hardware. Exemplo: alguns produtos da família VMWare, Microsft Virtual Server, etc.;
Virtualização na Camada de SO/Contêiner de Virtualização – Também chamada de virtualização leve ou single kernel image (SKI), sendo caracterizada pela execução de múltiplas instâncias do mesmo SO (kernel) em paralelo, nas quais o SO e seus processos serão virtualizados. Com esta arquitetura leve, um administrador de sistema pode alocar recursos (CPU, memória, armazenamento, rede, etc.) executando VMs sob demanda, o que vem atraindo mais adeptos, pois a abordagem possui desempenho superior às outras formas de virtualização, sendo a técnica mais recente. Uma das desvantagens desta abordagem é o isolamento, além do que limita os SOs ao kernel atualmente compartilhado (e.g. se o kernel é de um Linux não se pode instalar um contêiner Windows e vice-versa). Exemplos: Docker, LXC, OpenVZ, Zones, Jails, Virtuozzo, ZeroVM, etc.;
Virtualização na camada de hardware ou hipervisorde tipo-I – A técnica que possui melhor desempenho e isolamento, sendo a preferida para implementação de servidores virtualizados em datacenters. Nesta técnica, o hipervisor roda diretamente sobre o hardware, controlando e sincronizando o acesso do SO guest aos recursos de hardware. Exemplo: KVM, VMWare ESXi, Cytrix Xen Server, Hyper-V, etc.;
Para-virtualização ou hipervisorde tipo-II – Diferente da virtualização completa, o SO guest, com esta técnica, deverá ser modificado para que possa ser operado no ambiente virtual. Sendo assim, a para-virtualização é um subconjunto da virtualização de hardware, provendo uma simples interface entre o hardware do SO host com o SO guest modificado. Neste tipo de hipervisor, o desempenho é próximo ao do hardware não virtualizado. A diferença entre os hipervisor de tipo-I e de tipo-II é que o primeiro atua como o próprio SO, acessando diretamente o hardware, enquanto o segundo atua numa camada de software acima do SO principal. Portanto, o de tipo-II demanda maior penalidade de desempenho em relação aos hipervisores de tipo-I. Exemplo: Oracle VirtualBox, VMWare Workstation/Player, Parallels, etc.; 37
Virtualização de Aplicação – O usuário é capaz de executar uma aplicação do tipo servidor, localmente, usando recursos remotos do servidor sem a necessidade de instalar aplicações servidor nas suas máquinas, o que demanda elevada complexidade, além do próprio espaço em disco. Assim, cada aplicação virtualizada é projetada para execução em um pequeno ambiente virtualizado, capaz de oferecer somente os recursos necessários ao seu funcionamento. Exemplo: Ferramentas para development operators (DevOps): Docker, Vagrant, Puppet, etc.;
Virtualização de Recursos – Tipo de virtualização em que se pode virtualizar, tanto um recurso de hardware como CPU, memória, disco, etc., quanto recursos de software. Este tipo de virtualização vem se tornando mais popular em ambientes de redes definidas por software com função de virtualização (sofware-defined network with function virtualization (SDNFV)) e, consequentemente, na computação em nuvem, pois se pode virtualizar recursos de middleboxes como proxies, firewalls, inspeção profunda de pacotes (deep packet inspection (DPI)), ferramentas de detecção de intrusões, e diversas funções de rede, etc. Exemplo: virtual CPU (vCPU), virtual network interface card (vNIC), sistemas operacionais de rede (network operating system (NOS)), como OpenDayLight e ONOS, dentre outros.
Figura 1- Ilustra a diferença visual entre três das principais técnicas de virtualização acima descritas - (a) Full Virtualization
Fonte: Sahoo et al.(2010)
38
Figura 2 – Ilustra a diferença visual entre três das principais técnicas de virtualização acima descritas - (b) Virtualização de Hardware
Fonte: Sahoo et al. (2010)
Figura 3 - Ilustra a diferença visual entre três das principais técnicas de virtualização acima descritas - (c) Contêiner
Fonte: Sahoo et al. (2010)
O trabalho de Sahoo et al. (2010) ainda elenca outras vantagens da virtualização que são: 1) flexibilidade; 2) disponibilidade; 3) escalabilidade; 4) utilização do hardware; 39
5) segurança; 6) custo; 7) adaptação a variações de carga de trabalho; 8) balanceamento de carga; e, 9) suporte a aplicações legadas. Todavia, o mesmo trabalho apresenta algumas desvantagens da virtualização, tais como: i) sobrecarga (overhead); ii) único ponto de falha; iii) interface de gerenciamento. A maioria dos conceitos usados, ao longo desta tese, está direta ou indiretamente ligada ao conceito de virtualização de redes.
2.2.1 Contêineres de Virtualização
É interessante reforçar que os SOs desenvolvidos para PCs foram adaptados dos antigos SOs de tempo compartilhado, provendo fraca capacidade de isolamento, em detrimento da facilidade de compartilhamento (sistema de arquivos e identificação de processos globais). Entretanto, os hipervisores se esforçam para prover um completo isolamento entre as VMs, fornecendo apenas o compartilhamento de recursos de comunicação suficientes para ativar redes entre as VMs, quando necessário for. Portanto, SOs desenvolvidos para PCs rodam múltiplas aplicações para um único usuário, priorizando o compartilhamento, em detrimento do isolamento. Por outro lado, os hipervisores foram desenvolvidos para rodar várias VMs num único host que podem conter aplicações diferentes de diversas empresas ou clientes, cujas aplicações não necessitam compartilhar informações entre si. Por isso, hipervisores priorizam o isolamento em detrimento do compartilhamento (SOLTESZ et al., 2007). Com a popularização das técnicas de virtualização que emergiram em diversos cenários (clusters, organizações de hosting de aplicações web/jogos/banco de dados, hosting distribuído (Ex: PlanetLab, Akamai, Amazon elastic cloud computing (EC2), etc.)), um dos principais benefícios trazidos é o isolamento de diversos grupos de usuários e suas aplicações. Ao longo dos anos, a experiência mostrou que muitos problemas de configuração nos softwares dos datacenters (compute farms) se davam pela incompatibilidade dos próprios softwares com as versões de um dado SO, sem levar em consideração seu kernel. Assim, oferecer ao usuário a habilidade de escolher sua própria distribuição, ou suas versões especializadas das bibliotecas do sistema, poderia ser a solução para resolver este problema. Pensando nisso, empresas de hosting distribuído vislumbraram uma grande economia de escala (capital expenditure 40
(CapEx)) ao empilharem quantas VMs suas infraestruturas poderiam dar suporte (SOLTESZ et al., 2007). O crescente interesse nos contêineres deve-se ao fato que esta estratégia é mais leve que os hipervisores que, por sua vez, consomem muitos recursos devido ao fato de serem baseados na emulação de hardware. De acordo com Vaughan-Nichols apud (RASTOGI et al., 2017), um sistema baseado em contêiner bem configurado pode ter um número de instâncias de aplicações servidoras de 4 a 6 vezes maior do que hipervisores como Xen, KVM, etc. usando o mesmo hardware. Nesse sentido, a diferença crucial entre hipervisores e contêineres é que a primeira estratégia abstrai todo o hardware, enquanto a segunda, apenas o kernel do SO. Assim, hipervisores podem possuir diversos SOs distintos e com núcleos diferentes, sendo que os contêineres só podem executar várias cópias do mesmo SO. Logo, uma VM host que execute um SO Linux não poderá rodar um contêiner Windows/Mac OS. Portanto, poderá executar somente instâncias que contenham distribuições rodando sob o mesmo kernel da VM guest. Bui (2015) afirma que a virtualização leve (lightweight virtualization), ou virtualização baseada em contêineres, funciona no nível de SO, permitindo que múltiplas aplicações funcionem sem, redundantemente, executarem outros kernels de SOs no host. Assim, os contêineres são vistos como processos de fora que rodam no topo do kernel compartilhado da máquina guest. Desta forma, os contêineres podem prover ambientes com os recursos necessários para a execução de uma aplicação na qual estes recursos podem ser compartilhados com o SO guest, ou instalados separadamente dentro dos contêineres. O Quadro 1 ilustra uma comparação entre VMs e contêineres, sob a ótica de múltiplos fatores relacionados ao desempenho, isolamento, segurança, armazenamento, rede e outros.
Quadro 1 - Escalas de comparação de desempenho entre estratégias de virtualização Paramêtro Máquinas Virtuais Contêineres SO guest Cada VM é executada no Todos os contêineres hardware virtualizado e seu compartilham o mesmo kernel kernel é carregado dentro de do SO guest, onde a imagem do sua própria região de memória. kernel é carregada dentro da memória física compartilhando recursos/processos entre as aplicações. Rede/Comunicação Funciona com uso de redes Usam mecanismos de virtuais ativadas usando comunicação inter-processos dispositivos virtualizados como (inter-process commnunication virtuais switches e interfaces (IPC)) como sinais, pipes, 41
virtuais ethernet. sockets, etc. Segurança Depende da implementação do Controle de acesso deve ser hipervisor. oferecido obrigatoriamente aos contêineres. Desempenho VMs sofrem com pequeno Contêineres oferecem overhead quando as instruções desempenho próximo das virtuais são traduzidas do SO máquinas físicas ao serem guest para o SO host. comparadas com o desempenho do SO host. Isolamento Compartilhamento de Tanto processos, quanto bibliotecas, arquivos, bibliotecas, dispositivos e até dispositivos e recursos entre os subdiretórios podem ser SOs guest e host não é possível. montados e compartilhados transparentemente. Armazenamento VMs consomem muito mais Menor espaço de espaço em disco do que apenas armazenamento, pois o espaço o kernel, além do que seus em disco de todos os programas devem ser instalados contêineres é um reflexo do e executados. tamanho do SO guest. Tempo de inicialização Necessitam de poucos Necessitam de milissegundos ou segundos ou até minutos para segundos para serem inicialização. inicializados. Fonte: adaptado de Dua et al. (2014)
De acordo com Kang et et al. (2016), os sistemas definidos por software permitem que desenvolvedores possam tratar a infraestrutura de nuvens e datacenters como códigos programáveis, usando contêineres. Tais sistemas garantem que toda a infraestrutura virtual seja gerenciada de forma automatizada, flexível e eficiente, através do emprego de contêineres com microserviços. Como principais vantagens desses sistemas, podem ser citados: a) portabilidade de código – ao empacotar softwares e suas dependências em uma imagem simples os contêineres ativam um processo de desenvolvimento baseado em imagens que oferece a liberdade de desenvolver uma vez, executar em qualquer lugar, cuja abordagem diminui a complexidade de configuração e alivia a execução dos softwares de infraestrutura; b) gerenciamento do ciclo de vida – atualmente as aplicações em nuvem demandam contínua entrega e integração de códigos. Para cobrir essa demanda, operadores de infraestrutura preferem fazer este gerenciamento usando imagens para evitar atualizações in loco. Assim, quando existe um problema em uma release, logo os operadores não precisam debugar e corrigir o problema no ambiente de produção, ao invés disso, eles podem simplesmente voltar (rollback) para versões ou imagens funcionais anteriores e esperar até que novas imagens, com correções, estejam disponíveis; e, c) utilização de recursos – contêineres podem ser armazenados em um único servidor para aumentar a utilização dos recursos, bem como contêineres são 42 mais eficientes que VMs ao acessar os recursos virtuais, provendo bom isolamento entre os contêineres. Enfim, uma melhor utilização dos recursos facilita o provisionamento dos serviços elásticos no ambiente de nuvem. Contêineres são capazes de prover ambientes virtuais com densidade muito mais alta, visto que não necessitam incluir um SO inteiro, então, o tamanho e os recursos requeridos para executar uma aplicação são menores do que uma VM rodando uma mesma aplicação. Portanto, o uso de contêineres gera uma economia de escala, maximizando o CapEx, pois se pode ter muito mais contêineres do que VMs em um mesmo host. Para ilustrar a economia de escala que gera uma maximização no CapEx com contêineres, observe o Quadro 2.
Quadro 2 - Escalas de comparação de desempenho entre estratégias de virtualização Aplicações Configuração Configuração Boot Tecnologia (re)iniciadas manual do automática do (inicalização) em... ambiente em... ambiente em... em...
Bare metal Dias Horas Minutos Minutos
Virtualização Minutos Minutos Segundos < 1minuto
Contêiner Segundos Minutos Segundos (mili)ssegundos
Fonte: dados da pesquisa / 2019
Existem diversas estratégias de contêineres de virtualização disponíveis, dentre elas destacam-se: Linux V-Server, OpenVZ, ZeroVM, Lmctfy, Docker, LXC, etc. (MORABITO et al., 2015). Contudo, este trabalho utilizou LXC e Docker para montagem de cenários de experimentação com roteadores virtuais, abertos ou não, visto que existem vários trabalhos que comprovam o desempenho superior dos contêineres em relação às demais estratégias de virtualização (MORABITO et al., 2015; RATHORE, 2013). Os experimentos deste trabalho foram construídos usando hipervisores de tipo I (VMWare ESXi) e tipo-II (VMWare Workstation e Oracle VirtualBox) no bare metal, segundo documentos chamados de request for comments (RFC) de número 25441, além de seu complemento a RFC 68152. Foram criadas topologias de experimentação próprias, a fim de ser analisado o comportamento fractal do tráfego TCP ao longo do tempo, de diversas configurações distintas, usadas para ativar redes virtuais
1 RFC 2544 – Disponível na URL: http://www.ietf.org/rfc/rfc2544.txt 2 RFC 6815 – Disponível na URL: http://www.ietf.org/rfc/rfc6815.txt 43 empregando os contêineres LXC e Docker. Entretanto, uma análise pormenorizada dos resultados dos processos estocásticos, capturados nas medições, será apresentada no Capítulo 4. 2.3 Virtualização de Redes
A virtualização é amplamente usada em datacenters, permitindo que se executem vários servidores de rede ou serviços numa mesma máquina física. Tal técnica permite a economia de energia e reduz o custo de manutenção, permitindo grande flexibilidade, pois cada VM pode ter seu próprio SO, aplicações, regras de configuração e procedimentos administrativos. A virtualização de redes é semelhante à virtualização computacional, sendo que os recursos a serem compartilhados são os da rede (KHAN; ZUGENMAIER; JURCA et al., 2012). A virtualização de redes permite instanciar, deletar e monitorar redes virtuais, além de migrar elementos de rede e um conjunto de parâmetros de alocação de recursos, ou seja, estas VMs irão realizar funções de rede, podendo, inclusive, ativar o paradigma de programabilidade de redes, denominado software-defined network (SDN), se preciso. De acordo com Rathore (2013), uma forma interessante de se implementar a virtualização de redes é empregando o conceito de roteadores virtuais, tal como realizado nesta tese. Contudo, devido à degradação de desempenho inerente à virtualização, as causas da queda de desempenho ao longo do tempo devem ser investigadas. A Figura 5 mostra como o Docker cria uma pilha de rede virtual independente para cada contêiner, que possui seu próprio endereço IP, tabelas de rota, dispositivos, políticas de segurança, etc. A conectividade entre os contêineres e os hosts é realizada usando uma interface de ponte (bridge) chamada virtual ethernet (veth). Destarte, é criada uma interface docker0 que repassará pacotes entre as interfaces de rede virtual, sendo que esta interface bridge funciona como um hub, capaz de conectar múltiplas interfaces de rede. Assim, os quadros ethernet, anexados ao bridge, são transmitidos para os outros dispositivos. Vale salientar que esta é a configuração básica do Docker que, por sinal, é imune a ataques de spoofing e inundação (flooding) de MAC, com o address resolution protocol (ARP) (BUI, 2015). 44
Ao criar um novo contêiner, é estabelecida uma nova interface virtual (veth), de nome único, que será conectada ao bridge. Porém, a interface virtual será conectada à interface eth0 (ou outra) do contêiner para permitir que a veth possa enviar pacotes para o bridge (ver Figura 5). Por outro lado, a Figura 4 ilustra o processo de encaminhamento de pacotes em um contêiner LXC. Nesta figura, pode-se notar que os pacotes entram pela interface física, depois são mapeados dentro do espaço do kernel (tal processo aumenta o desempenho por não precisar realizar nenhuma troca de contexto). Em seguida, é realizada a identificação da interface virtual (virtual interface (VIF)). Todo este processo é feito em software, o que traz degradação de desempenho. Contudo, o trabalho de Rathore (2013) apresenta o single root – i/o virtualization (SR-IOV) como alternativa de hardware para prover suporte à virtualização em interfaces físicas de rede, gerando descarregamento (offloading) de processamento. Os resultados do referido trabalho mostraram que o LXC, com SR-IOV, apresentava melhor desempenho que a KVM (adaptada). Na base destas redes virtuais estão os roteadores virtuais que podem atuar tanto no plano de controle quanto no de dados (foco deste trabalho), ou em ambos (FERNANDES et al., 2011). Portanto, o estudo do impacto do desempenho do tráfego TCP usando roteadores virtuais, em infraestruturas de redes virtuais, é de suma importância para predizer a provisão de serviços TCP ótimos. Esta premissa torna-se ainda importante, principalmente, porque as redes virtuais estão presentes em todos os serviços virtualizados e de nuvem, tais como computação, armazenamento, segurança, interface, etc. Desta forma, os roteadores virtuais são peças obrigatórias para a montagem de toda a infraestrutura de redes virtuais em computação em nuvem e/ou datacenters. Nestas infraestruturas, todos os serviços virtuais oferecidos são entregues remotamente aos inquilinos e aos seus clientes, com o uso efetivo e obrigatório destas ferramentas. No entanto, até este trabalho doutoral, nenhum trabalho anterior avaliou o comportamento da estrutura fractal do tráfego TCP nas redes virtuais. Ao adquirir este conhecimento fractal, aliado à aplicação de uma técnica MCDM correta, pode-se configurar um ambiente virtual ótimo, para prestação de serviços TCP ao longo do tempo.
45
Figura 4 - Encaminhamento de pacotes em redes virtuais - LXC
Fonte: Rathore; Hidell; Sjödin (2013)
Figura 5 - Encaminhamento de pacotes em redes virtuais - Docker
Fonte: pesquisa/2019
46
2.4 Autossimilaridade
A autossimilaridade (AS) foi apresentada no trabalho pioneiro de Mandelbrot (1965), que propôs um modelo de perturbações aleatórias em clusters e rajadas presentes na telecomunicação. Assim, observou-se que canais sem memória (memoryless) são incapazes de contabilizar o comportamento de circuitos de telecomunicação de alta qualidade ou baixa taxa de erros. É necessário destacar que, embora esses erros sejam ocasionalmente encontrados, muitos deles parecem estar sempre agrupados, os quais aparecem agrupados em rajadas (bursts) que vão se agrupando sucessivamente ao longo do tempo. Então, a AS é um “contágio” entre as ocorrências de erros em símbolos adjacentes. Na teoria Markoviana, é sugerido que os canais de comunicação têm somente dois estados, um estado bom (com baixa probabilidade de erros) e outro ruim (com alta probabilidade de erros), e que possuem probabilidades de transição entre estes estados (GILBERT, 1960). Como em canais que apresentam a AS existe um agrupamento independente entre si, então seria necessário um modelo não de apenas dois estados, mas com diversos estados estocásticos a serem analisados. Segundo a definição formal e original da AS (MANDELBROT, 1965), com o tempo sendo uma variável aleatória contínua, considere Tk para designar os momentos de ocorrências de “certos” eventos que são recorrentes. Isso significa que os intervalos
U, entre sucessivos Tk, são estatisticamente independentes. Assim, eventos autossimilares recorrentes serão definidos como eventos, cujo intervalo U segue a “lei de probabilidade uniformemente autossimilar” que designará qualquer expressão hiperbólica da forma:
( ) ( ) (2.1)
Onde o expoente é um valor entre zero e um, sendo que a variável u pode variar de zero ao infinito continuamente. Logo, quando , então ( ) pode tornar- se exponencial, ou seja, a cauda vai pesando quanto maior for o valor de . Os termos fractal e AS foram introduzidos por Mandelbrot; Wallis (1969). A geometria fractal, também introduzida por Mandelbrot (1982), foi criada com o objetivo de matematicamente acomodar objetos da natureza que exibiam padrões de irregularidade e fragmentação, através da identificação de formas irregulares 47
denominadas de fractais. Este mesmo trabalho descreve essas estruturas como galerias de monstros ou patologias. Segundo Millan et al. (2014), a AS é uma singularidade pela qual a propriedade de um objeto se preserva sob sucessivas escalas de tempo e/ou espaço. Este mesmo trabalho define ainda dois tipos formais conceituais da AS, que são: 1) AS exata – inerente aos objetos matemáticos abstratos, tal como o clássico exemplo do Triângulo de Sierpinski que é formado por um k -k conjunto Sk que consiste de 3 triângulos, cada um com lado 2 . Outros exemplos da AS exata, são o flocos de neve de Koch, além de outras formas fractais geradas computacionalmente, capazes de produzir ilustrações realísticas de alguns padrões irregulares que estão presentes na natureza (MANDELBROT, 1982).
Figura 6 - Triângulo de Sierpinski
Fonte: (MANDELBROT, 1982)
2) AS estocástica – compreende o comportamento dos processos estocásticos que correspondem a processos de comportamento altamente aleatórios, inclusive caóticos, tal como observado no tráfego TCP das redes de computadores, sequência de DNA, meteorologia, mercado financeiro, etologia, dinâmica cardíaca, entre outros.
Uma das formas de se calcular o coeficiente ou o grau de AS, de um conjunto de variáveis aleatórias contínuas, é através do método de análise de escala reescalonada (rescaled range analysis (R/S)) (MANDELBROT; WALLIS, 1969). Através da análise R/S, é calculado o parâmetro de Hurst ou H, em homenagem ao engenheiro que deu 48 origem a esse cálculo. O cômputo de H objetivava conhecer o comportamento irregular das enchentes de um açude perenizado pelo rio Nilo no Egito, estudando um benchmark de 100 anos de inundações (HURST, 1951). Tal parâmetro serve para capturar a intensidade da LRD numa série temporal, também associado à memória fractal. Para obter H, observe a equação (2.2), na qual o numerador refere-se à escala de uma série temporal. Além disso, a estatística R/S é calculada para computar o desvio padrão da amostra para complementar a computação de H.
( ) ( )
( ) (2.2) ( ∑ ( ) ) ⁄ )
De acordo com o valor de H, existem três tipos de processos estocásticos autossimilares, são eles: 1) Dependência de curto alcance (short-range dependency (SRD)) – quando , também chamado de processo anti-persistente ou sem memória (memoryless). Exibe efeito Noé, pois esses eventos são improváveis de acontecer, tal como o dilúvio que ocorrera na Bíblia. 2) Dependência de longo alcance (long-range dependency (LRD)) – quando , nomeado como processo persistente. Exibe efeito José, porque esses eventos são reverberados ou possuem memória ao longo do tempo. 3) Movimento fractal Browniano ou movimento aleatório (fractal-brownian motion (FbM) or random walk) – quando , nos quais os incrementos são inteiramente independentes uns dos outros, esses geralmente são causados pela fonte geradora.
O termo “domínio browniano de atração” foi introduzido por Mandelbrot; Wallis (1969) que afirmam que os processos estocásticos são caracterizados por três propriedades:
(i) a lei dos grandes números; (ii) o teorema do limite central; e, (iii) a independência assintótica entre passado e futuro. Assim, em relação aos valores de H, temos que: a) quando , existe uma correlação positiva entre os dados de tráfego passados e futuros, ou seja, esses processos possuem memória infinita ao longo do tempo; b) quando 49
, a propriedade do número (iii) é violada, mostrando que as séries temporais com fBM não pertencem ao domínio browniano de atração; e, c) quando , a correlação entre passado e presente é negativa, isto é, as variáveis aleatórias contínuas referentes ao tráfego TCP são sem memória, mostrando-se sem utilidade para predição.
Segundo Weron (2002), existem outros métodos para se calcular a intensidade da AS ou memória fractal em uma série temporal, tais como o estimador da máxima verossimilhança (maximum likelihood estimator (MLE)), detrended-fluctuaction analsysis (DFA), métodos de regressão de periodogramas, estimador de Hill (Hill, 1975), procedimento de Whittle (PAXSON; FLOYD, 1995) e muitos outros. Contudo, este trabalho usou o método da análise R/S e algumas de suas outras formas para calcular o parâmetro de Hurst de todas as medições nos roteadores virtuais. Outrossim, também realizou análise exploratória das medições com periodogramas, gráficos de função de distribuição empírica cumulativa e FDP, como formas alternativas de demonstração do comportamento fractal de algumas séries temporais. De acordo com De Lima; De Almeida Amazonas (2013), quando uma série temporal com LRD tem valor de H próximo de 1, então sua memória (grau de persistência) é maior. Logo, H é usado como variável decisória de saída nos problemas de otimização multicritério em redes virtuais, que serão resolvidos com a aplicação dos modelos multiplicativos DEA criados nesta tese. Outro importante conceito relacionado a AS com LRD, introduzido por este trabalho nas redes de computadores, como forma de avaliação de tráfego TCP, é a dimensão fractal ou dimensão de Hausdorff. Esse índice fractal serve como medida de irregularidade em séries temporais (ou outro conjunto de dados), contendo valores variando em um intervalo [1,2) (GNEITING et al., 2012). A dimensão fractal já é bastante empregada em mercados financeiros, como medida de volatilidade no mercado de ações, sendo usada para predição de tendências de mercado. Segundo Mandelbrot; Taleb (2012), H está de certa forma relacionada à dimensão fractal D que serve para mostrar se uma série temporal exibe aleatoriedade suave (mild) ou selvagem/irregular (wild). As séries de tempo usadas neste trabalho são consideradas como unidirecionais, pois as variáveis aleatórias contínuas, obtidas por configuração, foram 50 adquiridas em intervalos homogêneos (a cada 1 (um) segundo) e, por esta razão, existe um padrão monofractal das séries temporais analisadas ( ( ) ) por esta tese. A geometria fractal é baseada na Lei dos Grandes Números (MANDELBROT; TALEB, 2012), devido ao fato de que a média de um conjunto de números altamente aleatórios tende a ser próximo da média da população inteira. A dimensão fractal D foi definida inicialmente como um parâmetro para medir o grau de irregularidade das costas oceânicas em mapas. Logo, D aumenta quando a irregularidade (roughness ou burstiness) cresce, diminuindo quando existe um efeito de suavização (smoothness effect) (MANDELBROT, 1975). A função de autocorrelação (auto-correlation function (ACF)) tem um papel importante em descobrir um índice de dependência presente nas variáveis das séries temporais. Em um processo estocástico autossimilar, a ACF indica uma forte relação entre valores que se repetem com aderência, devido à sua memória de autocorrelação positiva (SHANG et al., 2007). Como indicado por Mandelbrot apud (CAMPBELL; ABHYANKAR, 1978), uma definição formal de fractal é relacionada a um objeto, cuja dimensão (D) é maior que sua dimensão topológica (Dtopo). Esta Dtopo é associada à dimensão topológica do gráfico de uma função aleatória, logo Dtopo tem valor 1, para séries temporais (como nesta tese); 2, para um mapa ou gráfico; e 3, para volume (DAUPHINÉ, 2013). Contudo, é necessário realizar uma análise precisa para se obter a dimensão fractal. Por isso, foram propostos diversos métodos para se computar a dimensão fractal, incluindo rodograma, madograma, Genton, Hall-Wood, box-count, variograma, densidade espectral, estimadores baseados em wavelet, etc. (GNEITING et al., 2012). Esta tese usou os dois primeiros métodos, previamente citados, para obtenção da dimensão fractal que foi avaliada como variável de entrada pelos modelos multiplicativos DEA aqui propostos. Aliás, foram também computados diversos outros índices de dimensão fractal, tal como Hall-Wood e Genton, mas, devido a eles serem altamente correlacionados, logo os modelos multiplicativos DEA só usaram separadamente o rodograma e o madograma que são consideradas versões superiores do variograma, por serem menos sensíveis a eventos extremos ou outliers (LLOYD et al., 2004), (BEZ; BERTRAND, 2011). O variograma é a metade da diferença quadrada entre os valores dos pontos de dados, separados pelo intervalo de tempo ou vetor distância ( ). Então, o variograma da população amostral é calculado como na equação (2.3) para o par de observações 51
( ) relacionado à função aleatória ( ) e seus pontos, respectivamente ( ) e
( ) com ( )
̂( ) ∑ ( ){| ( ) ( )|} (2.3) ( )
Como o rodograma é definido pela raiz quadrada da diferença absoluta entre as observações emparelhadas, logo seu valor ̂( ) ou pode ser calculado como na fórmula 2.4:
( ) ̂( ) ∑ {| ( ) ( )|} (2.4) ( )
O madograma é uma medida de variabilidade que descreve o relacionamaento entre similaridade e a distância dos pontos x e (x+h) (STEIN; SHI; BIJKER, 2008). Então, considere ( ) e ( ) como dois valores da variável localizada sobre os pontos e , nos quais estes pontos são separados por um intervalo de tamanho . O madograma ( ̂( )) é computado como a média da soma de todas as diferenças entre os pares de valores, que são divididos por 2, como:
̂( ) ( ) ∑ | ( ) ( )| (2.5)
Depois da computação dos índices fractais, rodograma e madograma, para cada série temporal por hipervisor de rede, logo pode-se chegar a duas importantes conclusões sobre o valor de D, que são: 1) Quando D tende a 1, então as variáveis aleatórias contínuas em análise apresentam um efeito de suavização (smoothing effect), i.e., as médias da largura de banda do TCP mantêm-se mais estáveis ao longo do tempo. 2) Quando D tende para 2, então a série de tempo mostra um efeito irregular (roughness effect), isto é, o tráfego TCP é irregular com infinita variância e alta variabilidade no tempo (GNEITING et al., 2012). Esta mesma conclusão foi inicialmente encontrada por Mandelbrot (1967), que afirma que o valor de D relativo à costa oceânica da África do Sul (D=1,02) tem o efeito mais suave no atlas. Nesta mesma pesquisa, a costa britânica tinha a(o) aparência/comportamento mais irregular (D=1,25) que todas as outras costas oceânicas avaliadas. 52
A dimensão fractal possui grande importância para comparar um dataset com outro para ranqueamento (HALL; ROY, 1994). Todavia, nas redes de computadores, esse conceito não havia sido explorado anteriormente. Assim, para cobrir esta lacuna, este trabalho propôs-se a usar este índice como uma variável de decisão a ser minimizada, ou seja, os modelos multiplicativos DEA desenvolvidos são capazes de ranquear a DMU com tráfego TCP mais suave, através dos menores valores de D. Logo, é mandatório que qualquer ferramenta MCDM escolhida para solucionar este tipo de problema possa considerar H como variável de saída (output), tal como preconiza esta tese. Assim, maximizar H, juntamente com uma significante largura de banda do TCP, buscando um menor valor de D é a garantia de uma maior quantidade de dados transferidos entre OD na camada L3 pelo TCP, com memória e suavidade do tráfego ao longo do tempo. Portanto, é imprescindível aprender como avaliar séries temporais para mirar predições em relação a eventos extremos ou comportamento de tendências futuras, usando a análise da estrutura fractal. Em suma, a análise da estrutura fractal é uma poderosa ferramenta formal aplicada para representar processos estocásticos em uma resolução dimensionalmente pequena (KANTELHARDT, 2008). Análise e ferramentas fractais são um campo crescente de pesquisas relacionadas à resolução de problemas multiobjetivo e/ou multicritério, no qual é necessário predizer algo dos dados relacionados às séries temporais. Por exemplo, em López-Ortega; López-Popa (2012) é concebida uma suíte para assistir a criação de pedaços de músicas aplicando fractais, lógica fuzzy e sistemas especialistas. Ademais, o trabalho de Przystalski; Ogorzałek (2017) mostra a utilidade de métodos fractais usados com imagens em multinível e métodos de binarização aplicados para reconhecimento de padrões em câncer de pele. A pesquisa de Florindo; Bruno (2013) propõe uma análise de multiresolução de texturas, baseada na aplicação de descritores fractais, com resultados superiores do que os métodos clássicos. Em Ni et et al. (2011) é apresentado um método de predição de mercados, embasado na seleção fractal e suporte à máquina de vetores para prever a direção diária do índice de preço das ações. De fato, esta tese serve para atestar que toda série temporal, relacionada às variáveis aleatórias contínuas por DMU, tem diferentes valores de dimensão fractal, desempenho da largura de banda do TCP e memória fractal de forma independente entre si. Estas novas conclusões/aplicações sobre a teoria da AS é uma das contribuições deste trabalho, pois não foi explorada anteriormente pela academia, ora 53 para comparação, ora para predição de serviços TCP ótimos nas redes de computadores. Por esta razão, foram utilizadas variáveis fractais para resolver o problema de como manter desempenho superior da largura de banda do TCP, de forma estável, em um maior período de tempo, ao se prestar serviços de transporte em uma rede virtual.
2.4.1 Autossimilaridade nas redes de computadores
A AS tem ganhado crescente atenção nas redes de computadores, desde o trabalho de Leland et al. (1994), que mostrou sua presença na rede de teste Ethernet Bellcore e que foi avaliada durante 3 anos e meio (agosto de 1989 a fevereiro de 1992). Esse mesmo trabalho mostrou que o tráfego de rede apresentava um padrão de tráfego irregular (burstiness) que permanece em larga escala ao longo do tempo. Assim, foi provado que o tráfego de rede tinha um comportamento diferente de outros modelos formais empregados anteriormente, para modelar o tráfego de redes de telecomunicação (Ex: teoria de Markov ou teoria das filas, modelos relacionados à Poisson, dentre outros). Em Paxson; Floyd (1995) destaca-se a falha da modelagem de Poisson ao afirmar que a AS é uma boa aproximação para entender o comportamento de redes. Em seguida, o trabalho de Crovella; Bestavros (1997) apresentou a AS nas medições para avaliar o tamanho de arquivos em servidores web. O artigo de Wisitpongphan; Peha (2003) propôe a conclusão de que o protocolo TCP provavelmente carrega a AS com LRD em todas as redes que usam este protocolo. Smith (2011) afirma que mesmo se o TCP não pudesse criar um efeito autossimilar completo, ele poderia ser responsável por propagar a AS, além do tráfego por ele originado, tal como um contágio. Contudo, nenhum trabalho anterior a este atestou que o TCP tem comportamento fractal diferente ao longo do tempo, quando se varia o conjunto de ferramentas usadas para ativar redes virtuais. Esta descoberta ajudará aos tomadores de decisão a ter uma acurada ferramenta, para sintonia fina de seus serviços TCP em redes virtuais. Vale ressaltar que o artigo de Yan (2005) traz uma conclusão errada sobre a AS afirmando que, depois da aplicação da modelagem de tráfego (traffic shaping) em uma rede, o parâmetro de Hurst diminuiu de 0,832 para 0,764. Entretanto, esse referido trabalho não citou a dimensão fractal e, por esta razão, as conclusões deste ensaio estão incorretas. Portanto, a conclusão correta seria que 54 depois da modelagem de tráfego a memória fractal da série temporal em análise diminuiu de 0,832 para 0,764, porque H é relacionado à memória, onde a dimensão fractal está ligada com a irregularidade de uma série de tempo. A Tabela 1 apresenta uma comparação de como os principais trabalhos científicos demonstraram a existência da AS em redes de computadores covencionais, sendo que a última linha é destinada a este trabalho, que atesta a AS com LRD nas redes virtuais.
Tabela 1 - Comparação da AS em redes de computadores tradicionais versus nossa pesquisa Onde a AS foi Trabalho Método(s) de prova utilizado(s) encontrada?
(LELAND et al., Ethernet (IEEE Parâmetro de Hurst e Periodograma 1994) 802.3)
Tamanho de (CROVELLA; Estimador de Hill e gráficos de Distribuição Complementar arquivos em BESTAVROS, 1997) Log para Log servidores web
(PAXSON; FLOYD, Procedimento de Whittle, Gráfico de Distribuição Empírica, Tráfego WAN 1995) Gráfico Variância-Tempo e Periodogramas
(OLIVEIRA et al., Wi-Fi (IEEE Parâmetro de Hurst 2003) 802.11x)
Parâmetro de Hurst e Gráfico de Função de Distribuição (LIU et al., 2012) Tráfego ICMP Cumulativa Complementar em escala Logarítmica
(RIZO et al., 2008) Jitter UDP Estimador de Hill e gráficos PP
Otimização de rede virtual usando dimensão fractal, parâmetro de Hurst e desempenho da largura de banda TCP em Redes Estre trabalho do TCP, além de análise exploratória com gráficos PDF, Virtuais função de distribuição empírica cumulativa (FDEC), periodogramas e gráficos ACF.
Fonte: pesquisa/2019
Uma interessante revisão do estado da arte da AS, em redes de computadores convencionais, é apresentado na Tabela I de Liu et al. (2012).
55
2.4.2 Novas Aplicações de Fractais em Redes
Esta seção destaca as novas aplicações da teoria dos fractais para avaliar o tráfego de redes, aumentar a eficiência do tráfego de redes, bem como a eficiência energética de datacenters, melhorar a robustez e detectar anomalias, etc. Neste estudo de Joveini et al. (2018), os valores das probabilidades de redes multifractais são empregados para analisar, modelar e visualizar redes de big data. O método usa uma rede complexa em um espaço n-dimensional, no qual os vértices estão localizados em diferentes zonas do modelo fractal. Uma das vantagens citadas por este método que usa produto de matrizes é que ele se torna mais acurado ao aumentar o número de níveis dos nós conectados ao grafo. Outra vantagem é a economia de memória e diminuição do tempo de execução comparado a outros métodos tradicionais, sendo útil para classificação e clusterização. Finalmente, este trabalho buscava modelar o grafo ou estrutura da rede, a fim de interpretar as características de novas redes e entender como elas estão organizadas. No artigo de Cuesta et al. (2016) a dimensão fractal foi calculada pelo método box-counting e a regra de Rule, sendo empregada no contexto de redes livres de escala (scale-free networks). O objetivo é criar topologias de rede que sejam robustas e tolerantes a falhas. O estudo foi aplicado simulando a invasão de patologias como vírus ou vermes, em redes biológicas e tecnológicas. Tal processo evolucionário, de transformar nós saudáveis (residentes) em doentes (invasores), foi introduzido no trabalho de Lieberman et al. (2005), contudo não empregava fractais para criação de redes livres de escala. No trabalho de Wang et al. (2013) é mostrado um estudo sobre o gerenciamento de energia em datacenters baseado em fractais. Nesta pesquisa, é apresentada uma análise espaço-temporal em relação à demanda de energia de datacenters executados pela Microsoft, durante um período de seis meses, entre julho e dezembro de 2011. Esses dados são referidos a 8 clusters de servidores que executam uma grande quantidade de cargas de trabalho, incluindo pesquisa na web, e-mail, tarefas MapReduce e alguns outros serviços em nuvem, para atender a milhões de usuários em todo mundo. O trabalho de Wang et al. (2013) ainda cria abstrações da AS para capturar demandas de potência de energia, na forma de picos e vales em nuvens. O parâmetro de Hurst é calculado para descobrir a presença da AS, bem como foram usados alguns gráficos fractais para mostrar a AS com LRD, dentro dessas cargas de trabalho de serviços em nuvem. 56
O trabalho de He et al. (2012) realiza detecção de anomalias no tráfego de rede usando o método da monotonicidade de múltiplas janelas deslizantes do TCP, através da aplicação da teoria dos fractais. O método mostrou-se mais eficiente que K-means e clusterização ARIMA na taxa de detecção e taxa de falsos positivos. O trabalho de Kaklauskas; Sakalauskas (2009) analisou o tráfego de rede passivamente na Universidade de Šiauliai – Lituânia, durante 12 dias. As séries temporais do tráfego obtidos foram agregadas para se calcular a medida de correlação, análise de cluster, parâmetro de Hurst, bem como os atratores. Índices de atração servem para apontar se uma série temporal pertence ao grupo de fatores atratores estranhos, cujos atratores são obtidos via cálculo da dimensão fractal. Contudo, a pesquisa de Kaklauskas; Sakalauskas (2009) não aplicou este estudo em redes virtuais; tampouco usou a dimensão fractal e o parâmetro de Hurst para predição do melhor padrão fractal a ser seguido na prestação de serviços de tráfego de rede (virtual). Outrossim, o trabalho também não caracteriza o tráfego como suave, altamente aleatório e irregular ao tratar da dimensão fractal. Além disso, o trabalho só avaliou uma única rede, gerando novamente uma grande série temporal que foi agregada, onde foram calculados todos os índices fractais. Em suma, o parâmetro de Hurst variou de 0,61 a 0,79, sendo que D variou de 1,23 a 1,82. A pesquisa de Zhou et al. (2011) usou o pacote raw packet generator (RPG) do simulador de rede OPNET que implementa tráfego autossimilar. O objetivo era compreender a natureza fractal do tráfego para implementar redes com melhores parâmetros de eficiência e qualidade de serviço. Neste sentido, a primeira crítica ao trabalho é que ele não especifica qual o tempo e nem como foram realizadas estas medições. Outra crítica é afirmar erroneamente que a largura de banda, tamanho da janela do TCP e tamanho do pacote têm impacto em processos estocásticos com SRD. Outra crítica, é que nenhum formalismo foi apresentado, bem como nenhum resultado dos cálculos para abalizar as contribuições. Outrossim, como a fonte geradora de tráfego já é autossimilar (criado sinteticamente), os resultados alcançados não são efetivos e nem foram avaliados em situações que pudessem comparar se houve melhora/piora nos parâmetros de eficiência e qualidade de serviço das redes Ethernet de controle industrial. Daqing et al. (2011) avaliaram modelos de redes embutidas espacialmente, tal como redes de linhas aéreas globais e Internet, mostrando como a dimensão pode ser determinada topologicamente. Este trabalho atenta para o fato que a dimensão de uma 57 rede é importante não apenas do ponto de vista estrutural, mas também crucial para entender à função da rede, visto que a esta governa os processos dinâmicos em uma rede. Os resultados mostram que as redes caracterizadas por uma grande variedade na distribuição de tamanhos de links, entre os nós, possuem uma dimensão maior que o espaço embutido. O trabalho de Baccelli; Hong (2002) propôs o modelo additive increase, multiplicative decrease (AIMD) usando a dinâmica dos fluídos para compreender o protocolo TCP. Neste estudo, os produtos de matrizes aleatórias são aplicados em um modelo de evolução do conjunto de taxas de transferência de várias sessões TCP que compartilham um roteador em comum que está em gargalo. Este modelo propõe-se a predizer as flutuações na taxa de transferência de cada sessão TCP como uma função da taxa de sincronização no roteador. No entanto, o modelo foi apenas validado usando simulações no network simulator (NS) aplicando um gerador de tráfego wavelet. Todavia, o trabalho aplica um tráfego sempre fractal que apresentava um comportamento do tráfego instantaneamente injusto (unfair). Vale ressaltar que o TCP busca implementar uma sincronização justa (TCP fairness), na qual as médias das taxas de transferência a longo prazo tendem a ser as mesmas em várias sessões. Contudo, a solução estacionária do modelo AIMD mostra que existe uma alta dispersão de taxas de transferência para diferentes sessões em um dado período de tempo. O trabalho de Liu (2019) usou dois métodos para estudar o tráfego de rede fractal que foram: a análise de segunda ordem autossimilar e a análise multifractal. O trabalho separa o tráfego AS em duas regiões de escala: SRD e LRD. Segundo o trabalho, o delay, largura de banda, tamanho da janela TCP e o tamanho do pacote têm impacto na SRD. Outrossim, afirma-se que a estatística de cauda pesada β (parâmetro de forma de Pareto) afeta a estrutura da LRD. Assim, a fórmula para quantificar a irregularidade (burstiness) é derivada de uma propriedade da AS. Uma crítica ao trabalho é que ele, erroneamente, associa a SRD para escalas muito pequenas de tempo (ms ~ seg) e LRD para escalas de tempo maiores (>seg). Neste sentido, são tiradas algumas conclusões (errôneas) sobre o tráfego de rede multifractal, tais como: a) em grandes escalas de tempo, aumentar a largura de banda não aumenta a taxa de transferência. Para o trabalho os dois fatores que afetam a taxa de transferência são delay e o tamanho da janela do TCP. Todavia, afirma-se que aumentar o número de conexões simultâneas “suaviza o tráfego”, o que poderia resultar em uma melhora na eficiência 58 de rede; b) em pequenas escalas de tempo, a irregularidade varia, logo, para aumentar a eficiência da rede, é necessário controlar a largura de banda, tamanho da janela do TCP e atraso para reduzir a irregularidade da rede; c) processos estocásticos referentes ao tráfego de rede têm um expoente de Holder ou dimensão fractal α variando entre 0,7 e 1,3. Ainda, de acordo com Liu (2019), seu trabalho lançou a noção de efficient bandwidth (EB) ao aplicar a análise multifractal para aumentar o desempenho da rede, reduzindo a irregularidade da rede. No entanto, não é apresentado como este impacto teria alguma relação com a dimensão fractal, mas com os expoentes fractais α ([α_S-ε, α_S+ε]) que correspondem à entropia de partição de conjuntos fractais. De acordo com Chakraborty et al. (2004), esta pesquisa introduziu o conceito de dimensão fractal na análise de tráfego da Internet. Os autores afirmam que é necessário encontrar um índice para predição de valores futuros que consiga preservar as características das séries temporais. O objetivo é ajudar ao administrador de rede entregar o tráfego com qualidade de serviço mais satisfatória. No entanto, o trabalho não fala das conclusões que podem ser tiradas na análise do tráfego de rede ao se calcular o valor da dimensão fractal, tampouco, indica quais os protocolos que foram analisados nas medições reais. Vale ressaltar que todos os valores da dimensão fractal calculados ficaram abaixo de 1, o que invalida os resultados. Porém, a dimensão fractal é maior do que a topológica sendo que, para séries temporais, o valor da dimensão topológica deveria ser 1. Para diferenciar os quatro datasets, foram calculados os parâmetros H, β e D. Ao final, conclui-se que as características espaciais e temporais são aspectos independentes uns dos outros, além de que seria necessário testar esta metodologia usando uma diversidade de datasets, oriundos de outros experimentos. Outro fato a ser trabalhado, seria avaliar diversas redes parecidas usando as mesmas escalas de tempo, a fim de aplicar os índices encontrados para predição de redes. Apesar de alguns destes trabalhos citados abordarem a importância do uso da dimensão fractal para predição, nenhum deles desenvolveu uma ferramenta MCDM ajustada usando variáveis fractais referentes ao tráfego TCP em redes virtuais para otimização.
2.5 Data Envelopment Analysis (DEA)
59
A análise envoltória de dados (data envelopment analysis (DEA)) é uma técnica não-paramétrica que avalia a eficiência técnica e/ou de escala de unidades tomadoras de decisão (decision-making units (DMU)). A técnica surgiu no trabalho de Charnes et al. (1978), sendo usada para avaliar a eficiência técnica de escolas que participavam de um programa de inclusão chamado Follow Through. DEA emprega programação matemática linear, com o intuito de obter avaliações ex post facto de organizações gerenciais, analisadas como DMUs (BANKER et al., 1984). DEA compara cada conjunto a ser avaliado como uma DMU, calculando sua eficiência através da combinação linear das variáveis de entrada empregadas para gerar como resultados, as variáveis de saída. Esta técnica fora escolhida, devido sua natureza não-paramétrica, ou seja, usa a programação linear para calcular a eficiência relativa das DMUs, através da identificação da combinação linear ótima entre as variáveis de entrada e saída, em comparação com as outras unidades. Além disso, ao usar tais técnicas, não é preciso computar nenhuma estatística a priori das variáveis de decisão. DEA é uma técnica de MCDM capaz de gerar uma fronteira de produção linear convexa por partes entre as DMUs ou firmas. As DMUs, em análise, devem possuir variáveis de decisão em comum, particionadas em variáveis de entrada e saída. As unidades, em comparação, podem ser órgãos governamentais, setores, roteadores virtuais, hospitais, instituições de ensino, prestadores de serviço em geral, dentre outras. DEA é baseada na premissa da produção em que insumos (entradas) são convertidos, por processos produtivos, em produtos (saídas) visando um lucro maior. Assim, DEA está ligada ao conceito de produtividade que atesta como os recursos de uma empresa estão sendo empregados a fim da obtenção do(s) produto(s). De posse das informações acerca das produtividades das DMUs, a metodologia poderá avaliar como as empresas consideradas ineficientes poderiam tornar-se eficientes, ao acompanhar o desempenho das empresas mais eficientes em análise, que são chamadas de benchmarks ou parceiros de referência. Este deslocamento de uma unidade ineficiente, para buscar seu parceiro de referência, que é eficiente, é denominado de movimento radial, em modelos DEA radiais. DEA cria uma fronteira linear de eficiência de Pareto-Koopmans, na qual se pressupõe que esta possa: a) minimizar a quantidade de entradas, para produzir a(s) mesma(s) saída(s); e b) maximizar o(s) valor(es) da(s) saída(s), preservando a(s) mesma(s) entrada(s) (COOPER et al., 2007). 60
Assim, existem vários modelos DEA que dependem do objetivo que o tomador de decisão deseja alcançar. Então, se ele(a) escolher um modelo i) orientado às entradas o objetivo será minimizar o número de entradas, enquanto produz as mesmas saídas; ii) no modelo orientado às saídas, o objetivo é maximizar as saídas, enquanto conserva as mesmas entradas; ou, iii) no modelo sem-orientação, o objetivo é coletivamente minimizar as entradas e maximizar as saídas, esses modelos também podem ser chamados de alocativos ou não-radiais. DEA utiliza o conceito de eficiência técnica para comparar as DMUs, no qual é confrontado o que é produzido por uma dada DMU, com o que poderia ser produzido de forma mais adequada (DE CARVALHO FERREIRA; PROVEZANO GOMES, 2009), formando um conjunto de possibilidades de produção (production possibility set (PPS)). Primeiramente, para caracterização de qualquer modelo DEA, é obrigatório conhecer o conceito de um PPS estático, i.e., de uma única série temporal. Logo, o PPS é obtido através da estimação da distância de cada unidade para a fronteira que irá definir se a DMU é, ou não, eficiente. Por isso, considere que a DMU/unidade usa m entradas para produzir s saídas. Considere o conjunto de n DMUs avaliadas, sendo DMUj (para cada
) ligada ao vetor de entradas de ( ) e vetor de saídas
( ), logo o PPS pode ser descrito por:
{( ) } (2.6)
A programação fracionária pode levar a soluções infinitas, além de não garantir a restrição da não negatividade. Então, para contornar estas dificuldades, DEA usa a programação linear (PL), mais especificamente, o algoritmo Simplex para realizar todos os cálculos e gerar a fronteira de eficiência linear por partes (piecewise linear frontier), com características convexas. De acordo com Lins; Calôba (2006), problemas de PL são compostos pelos seguintes elementos: Variáveis de Decisão, as quais são relevantes ao problema em questão, passíveis de quantificação e disponíveis para comparação de todas as unidades.
Função objetivo, que define o problema que será resolvido através da otimização, em que tal função poderá ser minimizada ou maximizada. 61
Restrições, são os elementos restritivos do problema como, por exemplo, restrições de capital, atraso, largura de banda, etc.
Ao usar a PL, em DEA, existem duas formas de modelagens para calcular as funções objetivo, são elas: 1) primal ou dos multiplicadores – existem s restrições (n+1) que se encontram no limite superior (upper bound), em uma combinação linear de n variáveis; e, 2) dual ou envoltório – as restrições (m+s) se encontram no limite inferior (lower bound). A diferença entre as duas formas é o desempenho computacional, visto que o modelo dual possui menos restrições, do que o primal. Contudo, os resultados gerados por ambas as formas são idênticos. Entretanto, como o modelo do envoltório é o mais usado, o mesmo empresta o nome à técnica DEA. A escolha do modelo apropriado é mandatória, para realizar um processo positivo de tomada de decisão. Assim, para entender qual o modelo deverá ser usado de acordo com o problema a ser solucionado, além da forma correta de escolher as variáveis de decisão, interpretação dos resultados e planejamento, leia sobre o COOPER framework em Emrouznejad; Witte (2010). Ademais, para revisitar as principais áreas em que DEA tem sido empregada, durante os últimos 40 anos de uso, bem como mostrar as áreas de pesquisa mais interessantes para se aplicar DEA, além do nome dos principais periódicos onde esta técnica é mais publicada, veja Emrouznejad; Yang (2017). O primeiro modelo DEA, que surgiu do seminal trabalho de Charnes et al.(1978), é denominado CCR em homenagem aos seus criadores, respectivamente, Charnes, Cooper e Rhodes. O modelo CCR é baseado na premissa do retorno constante de escala (CRS), ou seja, reflete o fato que as mudanças proporcionais devem ser consideradas. Tal conceito da economia é ligado à elasticidade, que computa a mudança relativa nas saídas comparada às mudanças relativas das entradas (COOPER et al., 2007). DEA calcula a eficiência relativa de uma DMU, através da divisão da sua produtividade, pela maior produtividade das DMUs em análise, gerando uma reta como fronteira de eficiência, formando um ângulo de 45º. Depois da definição do PPS, pode-se descrever a formulação linear do modelo CCR orientado à saída (output-oriented) que é formalizado como na equação (2.7). As folgas (slacks) nos modelos DEA podem servir para mostrar se uma DMU está operando com excesso de entrada, em que tal entrada deveria ser diminuída ( ), para alcançar a fronteira de eficiência, ou um excesso nas variáveis de produção/saída. 62
Logo, estas variáveis deveriam ser aumentadas ( ) para buscar a fronteira de eficiência. Portanto, as folgas ( ) nas restrições da equação (2.7) são representadas pelos coeficientes na formulação, para entradas e saídas respectivamente, então:
(2.7)
∑
∑
O modelo BCC proposto por Banker, Charnes e Cooper (BANKER et al., 1984), serve para ajustar o CCR em situações que existem restrições de capital, competição imperfeita, regulamentações governamentais, dentre outros. Tal modelo pressupõe os retornos variáveis de escala (RVE ou variable return to scale (VRS)), que podem ser: Crescente ou Não-Decrescente – quando o aumento no número de entradas produz um aumento desproporcional maior, em relação às saídas. Assim, as DMUs operam muito abaixo de sua capacidade ótima. Constante – quando o aumento no número de entradas produz um aumento proporcional, em relação às saídas. Logo, as DMUs operam na sua capacidade ótima. Decrescente ou Não-crescente – quando o aumento no número de entradas produz um aumento desproporcional menor, em relação às saídas. Portanto, as DMUs operam muito acima de sua capacidade ótima.
O modelo BCC pode incluir o conceito de eficiência de escala, que geralmente é maior que o valor da eficiência técnica do modelo CCR. Assim, a eficiência de escala é obtida através da divisão entre a eficiência técnica do CCR, sobre a eficiência técnica do BCC. Esta razão entre a eficiciência técnica do modelo CCR sobre a do modelo BCC resulta no conceito de eficiência máxima mais adequada, ou tamanho de escala mais produtiva (most productive scale size (MPSS)). 63
Outra diferença é que o modelo BCC gera uma fronteira de eficiência convexa, curva e não-radial, tornando este modelo com maior possibilidade de encontrar benchmarks. A figura a seguir apresenta um comparativo entre as fronteiras CCR e BCC.
Figura 7 - Fronteira CCR (reta) e BCC (convexa)
Fonte: (COOPER et al., 2007)
Na Figura acima, a fronteira de eficiência do modelo CCR é a linha pontilhada, partindo da origem e passando apenas pelo ponto B. Já a fronteira de eficiência do modelo BCC é formada pelos pontos A, B e C que estão na linha em negrito. No entanto, a fronteira de possibilidades é a área que compreende as fronteiras CCR e BCC. No contexto de retornos de escala em DEA, suponha que existem cinco DMUs chamadas de A, B, C, D e H, como pode ser observado na figura 8. O raio OBC é a fronteira com CRS. Já os pontos AB, BC e CD formam a fronteira BCC, exibindo retornos crescentes (increasing return to scale (IRS)), constante (CRS) e decrescente (decreasing return to scale (DRS)) respectivamente. Logo: a) O segmento BC exibe CRS; b) No segmento AB, o IRS prevalece à esquerda de B, para o modelo BCC; e, c) No segmento CD, o DRS prevalece à direita 64 de C. Em relação ao ponto H, se for usado um modelo CCR de orientação à entrada, haverá uma projeção para o ponto H’ no segmento de reta AB, no qual o IRS prevalece. Caso seja usado um modelo BCC de orientação à saída, a projeção é sobre o ponto H”, entre o segmento de reta CD, que prevalece o DRS. Isso se dá devido ao fato que modelos BCC, com orientação a entrada e com orientação a saída, produzem diferentes pontos de projeção na fronteira de eficiência, sendo que é na fronteira que é determinado o RTS.
Figura 8 - Retornos de Escala CCR x BCC
Fonte: (BANKER et al., 2004)
O modelo de supereficiência DEA (SDEA) foi proposto por Andersen; Petersen (1993), como forma de ranquear as DMUs eficientes em uma tecnologia de referência estendida para todas as outras unidades, visto que os modelos DEA só dizem se uma DMU é eficiente ou não, ou seja, não geram ranqueamento. Logo, Thrall (1996) mostrou que esse modelo poderia ser viável com CRS, bem como era capaz de identificar as DMUs extremamente eficientes. Nesses modelos, a solução de um problema linear impossível (infeasible linear problem solution) (efficiency score = 1) é causada pela impossibilidade de modelos SDEA com VRS (XUE; HARKER, 2002) ou, de acordo com Cooper et al. (2007), causado pela invariância de unidade para estas medidas e que se estende para o conjunto de possibilidades sem solução que estão sendo avaliadas, e.g., como em um modelo de VRS (como BCC). 65
Além disso, a pesquisa de Andersen; Petersen (1993) abordou como estes problemas podem ser removidos. Segundo Seiford; Zhu (1999), o modelo SDEA CCR é impossível se, e somente se, certos padrões de zero acontecer nas variáveis em análise. No entanto, esta limitação foi isolada, porque este trabalho emprega modelos multiplicativos DEA que usam uma transformação log-linear das variáveis em forma de razão. A esse respeito, o trabalho de Seiford; Zhu (1999) ainda destaca a importância da análise de sensibilidade em modelos e resultados SDEA, além de apresentar situações nas quais estes modelos deveriam ser empregados, bem como contornar as impossibilidades numéricas.
A abordagem de SDEA remove a unidade em avaliação, chamada de DMU0, do conjunto de observações durante as avaliações. O escore de supereficiência é definido computando a distância entre as variáveis de entrada e saída de ambas as unidades
DMU0 e DMU*. Logo, a formulação SDEA da equação (2.7), com suas respectivas folgas (slacks), pode ser observada na equação 2.8.
(2.8)
∑
∑
Onde:
representa o valor da eficiência técnica de cada DMU;
o vetor das variáveis de entrada de todas as DMUs; é o vetor das variáveis de entrada da DMU em análise;
é o vetor das variáveis de saída de todas as DMUs;
é o vetor das variáveis de saída somente da DMU em análise;
é o vetor dos pesos referentes aos parceiros de excelência ou benchmarks de uma DMU. 66
Vale ressaltar que este padrão relacionado às variáveis de decisão é seguido em todas as demais formulações DEA desta tese. A diferença entre os escores de eficiência DEA e SDEA é que quando uma DMU é eficiente nos modelos clássicos da DEA, então seu escore nos modelos SDEA é acima da unidade (>1). Já as unidades consideradas como ineficientes apresentam o mesmo escore em ambos os modelos DEA e SDEA. Mais explicações e formalismos referentes aos modelos SDEA estão presentes em Cooper et al. (2007) e Seiford; Zhu (1999). Este trabalho avaliou diversas fronteiras de eficiência DEA, com e sem orientação, nos modelos CCR, BCC, modelo baseado em folgas (slack-based model (SBM)), SBM com supereficiência ou super SBM, super BCC-I, super CCR-I, free disposal hull (FDH) usando orientações à entrada e à saída, além de modelos sem orientação (super SBM-C e super SBM-V). Todavia, todos estes modelos não foram ajustados para trabalhar com variáveis de entrada e saída na forma de ratios, o que torna todas estas fronteiras de eficiência inacuradas. No entanto, este trabalho implementou modelos multiplicativos DEA estáticos e dinâmico, a fim de gerar fronteiras de eficiências acuradas, na presença de variáveis em forma de ratio e que serão detalhados adiante.
2.5.1 Modelos multiplicativos DEA
Variáveis em forma de razão (ratio) podem ser usadas para representar o desempenho de uma produção ou serviço, como por exemplo, o número de pacotes TCP entregues em um determinado período de tempo, variáveis fractais relativas ao tráfego TCP ou qualquer outro problema em questão, etc. Variáveis de ratio são aplicadas frequentemente como variáveis contextuais, tais como: renda per capta, taxa de desemprego, média de pessoas que recebem benefício (OLESEN et al., 2015), dentre outros tipos de variáveis que representam números reais e que são empregadas no cotidiano, para qualquer tipo de avaliação de eficiência. Além do que, variáveis de entrada e saída em forma de ratio podem ser usadas diretamente, tal como neste trabalho, sem que estas funcionem como complementos para medidas de volume, ou advindas de alguma relação entre variáveis de entrada e saída. Segundo Olesen et al. (2015), nenhum dos modelos convencionais da DEA com CRS ou VRS são apropriados para avaliar situações nas quais as variáveis de entrada 67 e saída sejam ratios. De acordo com Banker et al. (1984), as suposições de fronteira de produção DEA só são verdadeiras nos padrões de CRS e VRS, caso alguns axiomas sejam satisfeitos. De modo contrário, o modelo de tecnologia de produção DEA torna- se uma extensão arbitrária do conjunto de dados em observação. Logo, a análise baseada na tecnologia de produção é geralmente incorreta quando se tem variáveis em forma de ratio, usando modelos DEA padrão (OLESEN et al., 2015). Para remediar as deficiências de modelos com VRS, o trabalho de Emrouznejad; Amin, (2009) desenvolveu modelos quando as entradas são ratios e as saídas não, quando as saídas são ratios e as entradas não, além de um modelo em que entradas e saídas são ratios. O trabalho de Olesen et al.(2017) criou a noção de eficiência de razão potencial (potential ratio efficiency (PR)) para modelos com CRS e VRS, no qual uma DMU é eficiente, se e somente se, possuir um escore de eficiência na unidade e a soma de todas as suas folgas for igual a zero. Segundo Førsund (1996), informações qualitativas sobre economias ou "deseconomias" de escala são baseadas no cálculo da escala de eficiência, mas estas podem ser calculadas de forma inacurada quando existe o efeito de elasticidade de escala na presença de variáveis em forma de ratio. Contudo, esta ambiguidade pode ser solucionada de três formas: a primeira é especificar os CRS (como um dispositivo de diagnóstico, já a escolha da tecnologia é de VRS) e inspecionar se o ponto na fronteira, que corresponde a uma observação ineficiente se está crescendo ou diminuindo, segundo a unidade de referência; a segunda é inspecionar a interceptação do suporte ao hiperplano na unidade de referência; e, a terceira é calcular a eficiência em relação às três diferentes tecnologias: constante, crescente e decrescente. Lembrando que estas alternativas permitem avaliações qualitativas, ou seja, sem calcular a elasticidade de escala. O trabalho de Banker et al. (2004) descreve que os modelos multiplicativos devem ser empregados quando é necessário realizar uma avaliação quantitativa dos retornos de escala em DEA. Os modelos multiplicativos não estão confinados a trabalhar exclusivamente com fronteira de eficiência côncavas, mas geométricas, pois elas foram designadas para permitir fronteira de eficiência, que são côncavas em algumas partes e convexas em outras. Para clarificar o entendimento a respeito da convexidade geométrica, que permite a identificação da não-concavidade da função de produção, atente para a Figura 9. 68
Neste exemplo serão consideradas três DMUs com apenas uma variável de entrada e uma de saída (BANKER et al., 1984). Aqui a função de produção representa a quantidade máxima de saída que pode ser produzida por qualquer entrada especificada. As DMUs, associadas aos pontos P1 e P2, alcançam o máximo possível das saídas com as suas entradas, enquanto a DMU relacionada ao ponto P3 fica aquém do nível de produção, em relação ao valor de sua variável de entrada x3. Para avaliar a eficiência das DMUs com apenas uma variável de entrada e uma de saída pode-se usar a formulação fracionária 2.9:
(2.9)
Onde xi e yi representam, respectivamente, as coordenadas de entrada e saída da DMU associada ao Pi, i=1,2,3. O raio tangencial da origem para a função de produção em P1 encontra-se acima do raio, através dos pontos P2 e P3, que significa que a DMU associada a P1 é eficiente e as demais não são. Logo o valor de de P1
é igual a um e os escores de eficiência, , de P2 e P3 são menores que 1.
Conclui-se que as DMUs associadas aos pontos P2 e P3 são igualmente ineficientes, relativas à DMU associada com o ponto P1. Esta caracterização pode ser satisfatória em alguns casos, mas não para casos nos quais existem variáveis na forma de ratio. Assim, faz-se necessário sintonizar os modelos CCR e BCC para localizar as diferenças de escala, apresentadas pelos pontos P2 e P3, usando uma função de produção log-linear para gerar uma fronteira com convexidade geométrica, tal como na Figura 9. 69
Figura 9 - Raio ilimitado (ray unboundness) x fronteira geométrica
Fonte: (BANKER et al., 1984)
Na Figura 10, que também ilustra a fronteira geométrica, considere que pontos eficientes como B e C seriam classificados como ineficientes por modelos radiais, que estimam uma fronteira linear por partes como o BCC e o CCR. Se em uma aplicação empírica existem razões, a priori, para acreditar que produtos marginais estão crescendo ou diminuindo em uma certa região, então os modelos log-lineares são os modelos DEA apropriados para executar estes tipos de avaliações. Segundo Banker; Maindiratta (1986), a modificação ao BCC, que permitia representar produtos marginais crescentes/decrescentes em forma de ratio, foi a principal contribuição daquele trabalho. É interessante notar que em modelos multiplicativos DEA a função de produção estimada tem a forma de S (s-shaped) (COOK; ZHU, 2014), que não é possível no BCC. Portanto, modelos multiplicativos DEA são modelos não-radiais.
70
Figura 10 - Convexidade geométrica dos modelos multiplicativos DEA, com fronteira em forma de S
Fonte: (BANKER; MAINDIRATTA, 1986).
O principal efeito de trocar a convexidade padrão pela geométrica é que a fronteira de produção é estimada segundo os envelopes Cobb-Douglas (log-linear), em vez de uma fronteira linear por partes (COOK; ZHU, 2015). Vale ressaltar que o modelo multiplicativo DEA de Banker; Maindiratta (1986) tratou da estimação do VRS e do MPSS, além de agregar índices como a eficiência técnica e a de escala que podem ser empregados em situações nas quais as saídas não competem, característica de modelos não-radiais. Modelos multiplicativos DEA proporcionam avaliações dotadas de propriedades não-dimensionais, ou de unidades invariantes (COOPER et al., 2007). Para ilustrar um dos principais problemas, o da proporcionalidade, ao se usar variáveis em forma de razão ou ratio, considere dois hospitais cujas variáveis estão na Tabela 2. Os Hospitais A e B, em análise, terão uma variável de entrada (número de pacientes) e duas variáveis de saída (números de tratamentos e taxa de sucesso no tratamento). Considere o Hospital C como uma média simples dos Hospitais A e B, ou seja, o Hospital virtual C foi criado pela combinação linear convexa dos Hospitais A e B com pesos iguais (0,5) para ambos. Sendo assim, o Hospital C deveria ser uma combinação convexa possível, com valor de 1000 para o número de pacientes, já o 71 número de tratamentos seria de 440, com uma taxa de sucesso nos tratamentos de 50%. No entanto, esta taxa de sucesso deveria ser de 44%, mas que não pode ser alcançada, pois o axioma da proporcionalidade é violado ao se usar modelos tradicionais DEA com variáveis na forma de ratio. Variáveis de ratio podem ser relacionadas a alguma razão das variáveis de entrada e saída, ou simplesmente variáveis que usam números reais sem nenhuma relação entre as variáveis de entrada e saída, como é o caso deste trabalho. Este problema acontece devido ao fato de que os denominadores das duas razões (ratio), em análise, são diferentes, o que, de fato, irá acontecer em muitas avaliações no cotidiano. Partindo deste mesmo raciocínio, a propriedade da convexidade também será violada, porque nesta assume-se que, dadas duas combinações de entrada x saída produzíveis, sua média deveria ser também produzível.
Tabela 2–Exemplo do problema da proporcionalidade em modelos DEA padrão Número de Pacientes Número de Taxa de Sucesso no Hospital (Entrada) Tratamentos (Saída) Tratamento (Saída) A 1200 240 20% B 800 640 80% 50% (incorreto), 44% C = 0,5 A + 0,5 B 1000 440 (correto)
Fonte: dados da pesquisa/2019.
De acordo com o PPS anterior, já definido em Banker; Maindiratta (1986), foram demonstrados alguns dos axiomas que são retificados ao serem empregados modelos multiplicativos DEA, quando existem variáveis em forma de ratio, são eles:
1) Convexidade geométrica – Se ( ) são escalares
não negativos, tal que ∑ , então ( ) , onde ∏ e
∏ . Enfim, a suposição da convexidade se dá quando dadas duas DMUs, com suas respectivas variáveis de entrada-saída, produzem uma DMU virtual com os valores médios entre as variáveis de entrada-saída em análise. Logo, a convexidade geométrica prevê a elasticidade de escala para contornar o problema da convexidade. 72
2) Monotonicidade. (a) Se ( ) ( ) , (b) Se ( ) ( ) .
3) Inclusão de observações – todos os vetores das variáveis de entrada-saída
( ) .
4) Extrapolação mínima – P é a interseção de todos os conjuntos ̅, satisfazendo os três postulados anteriores.
5) Raio ilimitado – Se ( ) ( ) ( Banker et al., 1984). Este postulado é equivalente a assumir que o PPS exibe CRS em tudo e implica que se o vetor ( ) é eficiente, então qualquer outro vetor ( ) Suponha que o PPS exiba VRS como na Figura 11. Na Figura 11 os pontos A e B são eficientes, porque fazem parte da fronteira de eficiência do PPS. Contudo, um raio partindo da origem, até o ponto A dominará todos os pontos localizados abaixo do raio. Este raio será o envelope estimado do conjunto de produção, e é relativo a este envelope estimado, sendo o ponto B considerado como ineficiente. Nesta Figura 11, k é uma constante positiva.
Figura 11- O envelople, raio ilimitado e VRS
Fonte: (Emrouznejad; Cabanda, 2010)
Juntamente com estes quatro postulados, foram também apresentados alguns problemas como o da convexidade e da proporcionalidade (Emrouznejad; Cabanda, 2010) quando são usados modelos DEA tradicionais, nos quais as variáveis de entrada-saída estão na forma de ratios, como é o caso deste trabalho, conforme pode ser observado nas Tabelas (12, 13, 15 e 16) com os dados das DMUs, que representam hipervisores de rede distintos para montagem de redes virtuais. 73
As Tabelas 12 e 13 representam o comportamento do tráfego TCP, em uma única série temporal (modelos multiplicativos DEA estáticos) e em várias séries temporais independentes entre si (modelo de janela multiplicativo), como pode ser visto nas Tabelas 15 e 16. Para abarcar a convexidade geométrica, monotonicidade, inclusão de observações e extrapolação mínima, Banker; Maindiratta (1986) propuseram uma função de produção log-linear estática atrelado ao PPS multiplicativo abaixo:
{( )| ∏ ∏ } (2.10)
Usando uma estratégia diferente da desta tese, outros trabalhos anteriores usando DEA propuseram relaxar o axioma da convexidade, tanto nos modelos multiplicativos, quanto em outros, para contornar esta e outras restrições. Uma miríade destas estratégias pode ser encontrada em Emrouznejad; Amin (2009). Pesquisadores usaram diferentes modelos multiplicativos DEA para resolver diversos problemas, por exemplo, Emrouznejad et al. (2016) desenvolveram um modelo multiplicativo para ranquear diversas técnicas de previsão do tempo, usando variáveis de entrada e saída na forma de ratios. Um modelo multiplicativo ambiental (multiplicative environmental data envelopment analysis (ME-DEA)) foi usado por Valadkhani et al. (2016) para avaliar o desempenho dos 46 países que produziam mais poluentes de dióxido de carbono no mundo. Charnes et al. (1996) propuseram um modelo multiplicativo para comparar a indústria de empresas aéreas na América Latina. Ademais, Emrouznejad; Cabanda (2010) implementaram a formulação denominada de multiplicative non-parametric corporate performance (MNCP) para avaliar o desempenho de 27 indústrias do Reino Unido, usando seis variáveis financeiras na forma de ratios. Similarmente, Emrouznejad et al. (2012) introduziram dois modelos DEA para comparar as eficiências relativas de DMUs, com variáveis de intervalo usando ratios para comparar 20 bancos como DMUs. Resumindo, nenhum trabalho anterior a este implementou modelos multiplicativos DEA estáticos e/ou dinâmico para avaliar o comportamento fractal do tráfego TCP em redes virtuais, com o intuito de predizer qual das ferramentas em análise é a mais indicada para prestar serviços de redes virtualizadas mais suaves, com maior desempenho da largura de banda do TCP e memória ao longo do tempo. 74
No capítulo 3 serão apresentados os modelos multiplicativos propostos por este trabalho, em concomitância com a metodologia de avaliação fractal por etapas (Stepwise Performance Evaluation Framework of Fractal Structure of TCP traffic on Virtual Networks), desenvolvida na perspectiva de um sistema especialista.
75
3 METODOLOGIA DE OTIMIZAÇÃO FRACTAL EM REDES VIRTUAIS
Este capítulo descreve os métodos que direcionaram este trabalho doutoral. Logo, será descrita a metodologia de avaliação de desempenho, baseada na análise da estrutura fractal usada para avaliação e predição de qual dos hipervisores de rede virtuais comparados têm melhor padrão de tráfego fim a fim usandoo TCP. Esta metodologia também serve como um sistema especialista, bem como hipervisor matemático para otimização de redes virtuais. Assim, serão descritas as topologias de experimentação, mostrando como foram formadas as DMUs a serem avaliadas pelos modelos multiplicativos DEA estáticos e dinâmico para tomada de decisão multicritério. Enfim, este capítulo objetiva montar todo o arcabouço matemático, a fim de se predizer qual a configuração ótima para prestar serviços com desempenho da largura de banda do TCP estável e superior que perdure por um longo período de tempo nas redes virtuais.
3.1 Metodologia geral
Esta seção apresenta uma nova forma de análise de desempenho em dispositivos chamados de hipervisores de redes. Tal metodologia foi concebida, implementada e empregada para demonstrar a viabilidade formal desta tese, empregando a teoria dos fractais para avaliar o tráfego TCP em redes virtuais. Finalmente, serão apresentados os modelos multiplicativos DEA desenvolvidos para uma acurada tomada de decisão multicritério.
3.1.1 Análise de Desempenho de Dispositivos de Redes
Este trabalho usou medições ativas para adquirir o conhecimento da estrutura fractal do tráfego TCP e realizar avaliação de desempenho de diversos hipervisores de rede para predição. O uso de ferramentas ativas, para geração de tráfego sintético de rede, reflete situações reais do que se deseja comparar, além de serem amplamente usadas na academia e indústria (CRONKITE-RATCLIFF et al., 2016; RATHORE et al., 2013). Portanto, todas as séries temporais foram adquiridas usando a métrica da largura de banda (bandwidth) do tráfego TCP nas redes virtuais. O intuito era observar o comportamento estocástico, ao longo do tempo, das séries temporais de cada 76 hipervisor de rede para avaliação e predição de qual o melhor padrão fractal a ser seguido, na prestação de serviços de transporte fim a fim em redes virtuais. Para referendar a acurácia e confiança sob os resultados obtidos, os experimentos foram conduzidos seguindo a metodologia de experimentação e análise da RFC 2544. Este documento – da Internet Engineering Task-Force (IETF) – é amplamente aceito na comunidade acadêmica internacional, a fim de discutir como devem ser implementados os experimentos. A RFC 2544 é aplicada quando se necessita comparar o desempenho dos dispositivos de rede. Ademais, o documento ainda descreve formatos para que sejam reportados os resultados das medições. A RFC 2544 apresenta a figura de um dispositivo sob teste (device under test (DUT)) ou nó de coleta (sink node), que recebe conexões de um dispositivo testador através de portas. Todavia, foi também obedecida a RFC 68153, complementar à RFC 2544, que dita que os experimentos devem ser conduzidos em um ambiente de teste isolado (isolated test environment (ITE)) para que os resultados conservem as características da acurácia, repetibilidade e consistência. Na avaliação de largura de banda do TCP, foi usada a ferramenta de geração de tráfego ativa iperf. O iperf é capaz de analisar o tráfego dos protocolos TCP, user datagram protocol (UDP), stream control transmission protocol (SCTP), além de opções na camada do internet protocol (IP). A ferramenta ainda permite variação nos parâmetros como: tamanho da janela deslizante, tamanho do buffer, tamanho máximo dos segmentos, versões do TCP, estratégias de controle de fluxo ou congestionamento do TCP (CRONKITE-RATCLIFF et al., 2016). Outra característica do iperf é a possibilidade de se impor limites ao número de clientes e conexões simultâneas analisadas. Neste trabalho, o cliente iperf foi chamado de traffic generator (TG) nas topologias experimentadas. Inicialmente, foram executadas medições da largura de banda e taxa de transferência do TCP. Todos os experimentos foram repetidos diversas vezes, em intervalos de tempo com duração de 60 segundos por hipervisor de rede. Vale salientar que 60 segundos é o período mínimo indicado para a duração das medições, segundo a RFC 2544. Contudo, ao se aprofundar na análise exploratória das variáveis aleatórias contínuas, obtidas nas medições, observou-se forte presença de PDFs de padrão semiexponencial ou log-logístico. Portanto, as séries temporais adquiridas nos
3 RFC 6815 – Declaração de Aplicabilidade da RFC 2544: uso em redes de produção considerada nociva, disponível na URL: https://tools.ietf.org/html/rfc6815. 77 experimentos possuem a cauda pesada, remetendo a um padrão autossimilar ao longo do tempo. As escalas de tempo das medições foram aumentando, chegando a medições com até 28800 segundos por hipervisor de rede, ou seja, oito horas. O intuito de aumentar o tamanho das séries temporais, em análise, era buscar uma avaliação mais criteriosa dos processos estocásticos, visto que, no trabalho de Leland et al. (1994), fizeram medições de uma única configuração de rede durante três anos e meio. Este padrão de avaliação autossimilar do trabalho pioneiro de Leland et al. (1994), fora seguido por todos os outros trabalhos subsequentes, que tentaram mostrar a AS em diversos tipos de redes e protocolos. Portanto, todos os cientistas avaliavam apenas uma única grande série temporal (CROVELLA; BESTAVROS, 1997), (KAKLAUSKAS; SAKALAUSKAS, 2009), (OLIVEIRA et al., 2003). No entanto, este trabalho vislumbrou que deveria concentrar-se em avaliar o maior número possível de séries temporais, representando diferentes hipervisores de rede, para ativar redes virtuais com período de tempo igual para todas as séries analisadas. Calculou-se o número de repetições da primeira DMU em análise e, em seguida, repetiu-se este padrão de repetição para as demais DMUs. Em seguida, é realizada uma avaliação da estrutura fractal do tráfego TCP de cada uma das séries temporais extraídas. Os resultados de cada um dos hipervisores de rede – avaliados como DMUs – foram transformados em variáveis de entrada e saída para tomada de decisão multicritério com os modelos DEA ajustados. Todas as medições, ao longo do trabalho, foram armazenadas para posteriormente serem computadas as estatísticas referentes às variáveis aleatórias contínuas. Todas as variáveis são relacionadas ao tráfego TCP, segundo as topologias, estratégias de contêiner (ou versões da mesma tecnologia), interfaces virtualizadas e hipervisores usados nos experimentos nas redes virtuais. Como a RFC 2544 é clara ao explicitar que devem ser incluídas, tanto as versões dos softwares, quanto as configurações dos DUTs e TGs, logo, nas subseções a seguir serão apresentados detalhes das configurações de hardware e software, bem como das topologias montadas para experimentação.
78
3.1.2 Framework de Avaliação de Desempenho por Etapas da Estrututra Fractal do Tráfego TCP em redes virtuais (Stepwise Performance Evaluation Framework of Fractal Structure of TCP traffic on Virtual Networks)
Toda a metodologia de como serão montados os cenários de experimentação, tratados e avaliados os dados obtidos nas medições até a tomada de decisão, é apresentada através de um fluxograma algorítmico. Esta metodologia pode atuar, também, como um sistema especialista para otimização multicritério em redes virtuais. A Figura 12 detalha cada uma das camadas do framework. Outrossim, cada um dos processos será transformado em subseção adiante. O ponto de partida foi a Montagem dos Cenários, segundo as distintas topologias de experimentação, que serão apresentadas. Para que sejam realizadas as medições, é necessário que o DUT e o TG possuam alcançabilidade, ou seja, se as VMs e demais ferramentas de rede virtual, como os contêineres atuando como roteadores virtuais consigam comunicar-se entre si. Caso consigam, as medições são realizadas. Caso contrário, o cenário deverá ser remontado a fim de que DUT e TG tenham alcançabilidade. Ao descrever tal processo, parece que o mesmo é trivial, porém é preciso um conhecimento aprofundado das ferramentas do SO Linux, virtualização, protocolos, regras de roteamento a serem implementadas, bem como todos os pacotes de software necessários para suportar a instalação e montagem de todo este complexo ferramental. Observe que na Figura 12, tanto a VM DUT da distribuição Linux Arch12, quanto a VM TG, da mesma distribuição, conseguem trocar dados entre elas. Para atestar a comunicação entre elas, são disparadas requisições ICMP ping que são respondidas com sucesso pela outra VM, o que atesta a alcançabilidade entre as VMs.
79
Figura 12 - Garantia de alcançabilidade entre a VM DUT e a VM TG
Fonte: dados da pesquisa / 2019.
O próximo processo a ser realizado é a Execução das Medições, usando a ferramenta de geração de tráfego de redes ativa chamada iperf. Estas medições foram realizadas ao longo de um período de tempo uniforme, entre todas as configurações avaliadas. Portanto, as medições partiram do valor de tempo mínimo de 60 segundos, em conformidade com a RFC 2544. Ainda de acordo com as espeficações da RFC, é necessário computar as médias e variâncias de cada configuração avaliada, de uma série temporal com apenas 60 segundos. Entretanto, foi calculado o número de repetições da primeira DMU (DMU1) da Tabela 12 e 13, de acordo com a equação (3.1).
( ) (3.1) ̅
Onde z é relacionada ao intervalo de confiança (95% em nosso caso) da média da largura de banda do TCP ligada à tabela t-student4 pré-computada para uma série temporal, de tamanho igual a 60 segundos. Assim, δ é o desvio padrão da série temporal, e é a percentagem que o valor médio verdadeiro está dentro de um valor médio atual. Assim, sua metade é considerada como o erro permitido, i.e., se a percentagem de erros é 10%, logo seu erro permitido é 0,05.
4 A tabela t-student é comumente empregada para computar os intervalos de confiança. A distribuição t tem forma de sino e é simétrica em torno de uma média de zero, i.e., similar à distribuição normal ou gaussiana (LILJA, 2000). 80
Finalmente, ̅ é a média da série temporal com 60 segundos. Como este framework atua como um sistema especialista, logo o decisor pode escolher diferentes valores para aplicar na equação 3.1. Enfim, esta equação serve para determinar quantas medições devem ser realizadas, para obter um intervalo de tamanho desejado, baseado nos valores das variáveis obtidas após análise dos experimentos. Em seguida, os resultados das medições serão minerados através da camada de Captura e tratamento. O objetivo deste processo é a geração dos arquivos textos das variáveis aleatórias contínuas, individualmente, por hipervisor de rede, segundo o tráfego TCP. Contudo, os mecanismos usados neste parágrafo não terão subseções para explicá-los, pois existe vasta documentação sobre as ferramentas usadas nesta etapa. Este preparo dos dados é o início do processo de aquisição de conhecimento fractal sobre as variáveis de decisão. O processo de Avaliação Fractal dos Dados é de extrema importância para esta tese, visto que, é nesta etapa que são executados todos os procedimentos estatísticos para análise dos processos estocásticos inerentes ao tráfego TCP. É nesta camada que é adquirido, verdadeiramente, o conhecimento da estrutura fractal do tráfego TCP, para, em seguida, ser executado um dos hipervisores matemáticos. Assim, serão calculados a dimensão fractal (D), média de largura de banda do TCP e o parâmetro de Hurst (H) das variáveis aleatórias contínuas de cada um dos hipervisores de rede, por topologia. Neste processo, podem ainda ser gerados gráficos de Função de Distribuição Cumulativa Empírica (empirical cumulative distribution function (ECDF)), histogramas, gráficos de função de autocorrelação (autocorrelation function (ACF)), periodogramas, entre outras ferramentas de avaliação da estrutura fractal do tráfego TCP. É aqui nesta camada que é finalizado o processo de aquisição do conhecimento do framework. A suíte EasyFit5 foi usada para acomodação das FDP se função de distribuição cumulativas (FDC) que melhor se adequavam às variáveis aleatórias contínuas por DMU. O ambiente gráfico de programação estatística RKWard foi responsável pela geração dos histogramas, periodogramas e dos gráficos ACFs das medições. Todas estas ferramentas pictóricas servem como formas alternativas de se demonstrar a AS com LRD graficamente. Ainda na camada de Avaliação Fractal dos Dados, após a análise, é a realizada a montagem das DMUs que passarão por um processo, passo a passo (stepwise), de seleção de variáveis de decisão, denominada matriz de correlação para
5EasyFit: Disponível na URL: URL http://www.mathwave.com 81 checar se as variáveis de entrada e saída das DMUs possuem correlação ou não. Caso possuam, elas devem ser removidas; daí, novamente, deve ser executado o cálculo da matriz de correlação até não existir mais correlação entre as variáveis de decisão. Por esta razão, é que esta metodologia de avaliação aqui lançada é por etapas (stepwise), pois seleciona só as variáveis que se adéquam à solução ótima deste problema multicritério. Caso as variáveis de entrada e saída não possuam correlação, logo será gerada a fronteira de eficiência, de acordo com os modelos multiplicativos, implementados nesta tese, na camada de Execução dos modelos multiplicativos DEA. Estes modelos DEA, ajustados por este trabalho, atuam como mecanismos de inferência ou predição. Assim, o tomador de decisão, quando as DMUs tiverem séries temporais pequenas para popular as variáveis fractais de entrada e saída, pode optar pelo: 1) modelo estático, aplicando o modelo super-multiplicativo DEA (SMDEA), orientado às saídas; ou; 2) modelo super-Cobb-Douglas, orientado à entrada. Contudo, encoraja-se usar o modelo de janela multiplicativo DEA (Windows multiplicative DEA (WMDEA)) quando for disponível um dataset de medições com séries temporais maiores. Desta forma, é possível avaliar o comportamento fractal do tráfego TCP, em várias séries temporais dentro de uma mesma DMU, o que dota o tomador de decisão de uma ferramenta ainda mais acurada e completa para predição do hipervisorde rede virtual, com mellhor comportamento fractal do TCP, para ativar redes virtuais. A última camada é a de Otimização de Rede. Aqui o tomador de decisão deve escolher o melhor conjunto de ferramentas, ou hipervisor de rede, eleito pelo hipervisor matemático para entregar serviços TCP mais eficientes em redes virtuais ao longo do tempo. Portanto, deve-se aplicar um dos modelos multiplicativos selecionados na camada anterior, como último passo do sistema especialista para sintonia fina dos serviços de transporte nas redes virtuais. Logo, os resultados serão analisados para eleger a DMU ótima, a fim de oferecer serviços TCP em redes virtuais com melhor desempenho da largura de banda do TCP, com estabilidade do tráfego por um maior período de tempo. Enfim, o tomador de decisão deve adotar este hipervisor de rede predito pelo hipervisor matemático para prestação de serviços de transporte mais eficientes em redes virtuais, até que novas ferramentas virtuais sejam lançadas e avaliadas novamente.
82
Figura 13 - Fluxograma algorítimico do framework de avaliação de desempenho por etapas da estrututra fractal do tráfego TCP em redes virtuais
. Fonte: dados da pesquisa/2019 3.2 Cenários de experimentação
3.2.1 Cenários de Experimentação 1 – Roteadores Virtuais
Os experimentos nos roteadores virtuais foram realizados usando como hardware principal um Intel® Core™ i7 CPU M620 @ 2.67GHz × 4, com 8 GB de RAM e disco de 1 TB. O SO usado no host que abrigava os hipervisores de tipo-II foi o Ubuntu 14.04 LTS de 64 bits. Os hipervisores de tipo-II utilizados foram o Oracle VirtualBox4.3.106 e o VMWare Workstation Player7 7.1.3. As demais características do hardware usado nas
6VirtualBox – Disponível na URL: https://www.VirtualBox.org/wiki/Downloads 83 medições, bem como valores de benchmarks de performance de hardware padrões serão expressos como saída do comando lscpu do Linux na Figura 14.
Figura 14 - Saída do comando lscpu do Host Principal usado no cenário de experimentação dos roteadores virtuais
Fonte: dados da pesquisa / 2019 As medições do tráfego TCP foram conduzidas em todas as interfaces de rede emuladas pelo VirtualBox, quais sejam: AMD PCNet PCI II (Am79C970A), AMD PCNet FAST III (Am79C973, padrão), Intel PRO/1000 MT Desktop (82540EM) e Intel PRO/1000 T Server (82543GC), ver figuras 15 e 16. No VMWare Player Workstation os experimentos foram executados apenas em uma única interface de rede virtualizada Contudo, a interface de rede para-virtualizada (virtio-net) do VirtualBox, que pode ser customizada, não foi usada nas medições deste trabalho. A Figura 15 apresenta como foram realizadas as configurações de rede no VirtualBox. Estas configurações são relacionadas a cada um dos roteadores virtuais em análise. Note que o Adaptador 1 deve estar conectado a uma Placa de rede exclusiva de hospedeiro (host-only), onde ambas as VMs Guest devem fazer parte da mesma rede virtual de nome vboxnet0. Em seguida, observe a Figura 16 que especifica qual o Tipo de Placa de rede emulada pelo VirtualBox que foi usada para realizar as medições. Vale ressaltar que tanto a VM atuando como DUT, quanto a VM atuando como TG, devem ter todas estas configurações descritas idênticas. Tal padrão foi repetido em todas as distros do Linux
7 VMWare Workstation Player – Disponível na URL: https://my.vmware.com/en/web/vmware/free#desktop_end_user_computing/vmware_workstation_player/ 12_0 84 usadas para formar a configuração completa do hipervisor de rede, tanto no hipervisor de tipo-I, quanto no hipervisor de tipo-II. Uma observação é que cada hipervisor de tipo-I ou tipo-II possui (ou não) suas próprias interfaces de rede emuladas que, quando disponíveis, foram avaliadas individualmente. Contudo, este trabalho não avaliou os hipervisores de rede virtual com interfaces de rede emuladas distintas entre DUT e TG, mas somente as iguais o que, de certo, traria outros resultados, abrindo novas possibilidades de avaliação.
Figura 15 - Configurações básicas para montagem das redes virtuais no VirtualBox - Rede exclusiva do hospedeiro (host-only)
Fonte: dados da pesquisa / 2019 Figura 16 - Configurações básicas para montagem das redes virtuais no VirtualBox - Tipos de placas de redes emuladas pelo VirtualBox
Fonte: dados da pesquisa / 2019 85
Para avaliar o desempenho dos roteadores virtuais, de todas as estratégias, foi criada a topologia de avaliação Guest-to-Guest-to-Container para cada um dos hipervisores de rede avaliados que serão detalhados, bem como ilustrados, na Figura 17. A seguir será descrita a topologia: Guest-to-Guest-to-Container (GGC) – Medições foram conduzidas do SO da VM Guest (DUT/sink node), passando pelo virtual switch do VirtualBox, ou VMWare Player Workstation que repassa os pacotes ou requisições para outra VM Guest. A VM Guest, enfim, encaminha os fluxos, via virtual bridge, para o contêiner (TG) e vice-versa. Cabe ressaltar que ambas VMs rodam dentro dos hipervisores tipo-II, com a diferença que o VMWare Player Workstation não é multithread como o VirtualBox. Além disso, foi criado um esquema de roteamento, para que as redes tivessem alcançabilidade, além de que as informações fluissem da origem para o destino (e vice-versa). Tal topologia é a mesma usada, tanto para o Docker (docker0, Figura 5), quanto para o LXC (veth, Figura 4) e pode ser observada na Figura 17.
Figura 17 - Topologia de experimentação GGC
Fonte: pesquisa/2019
Para criar um roteador virtual em uma VM Guest, é necessário montar todo o arcabouço de experimentação. Logo, este ferramental é formado inicialmente pelo hipervisor de tipo-II (VMWare Workstation x VirtualBox) com uma das intefaces de rede emulada da ferramenta VirtualBox ou a interface emulada do VMWare, além da distribuição Linux, que abriga o SO principal da VM Guest (Arch 12, Fedora 24, 86
OpenSUSE 42.2, Ubuntu 14.04 Server e Ubuntu 16-04 Server) e, finalmente, uma das ferramentas de contêiner em análise (Docker versus LXC). A aplicação da ferramenta de benchmark iperf usada tinha a versão 2.0.5. Vale ressaltar que em ambas as VMs Guest, nesta topologia, todas as configurações avaliadas possuíam 1 GB de RAM virtual (vRAM) e 1 CPU virtual (vCPU). Ademais, para a padronização e avaliação pontual de cada uma das distros do Linux, os SOs das VMs Guest e o SO do contêiner rodavam a mesma distribuição, ou seja, quando a VM DUT rodava Arch12, a VM Guest oposta também executava Arch12, bem como o contêiner – que atua como TG – também executa o Arch12. Para descrever todo este arcabouço de ferramentas, para montagem das redes virtuais observe a Tabela 3. Tabela 3 – Versões e características dos Softwares e SOs usados nas medições GGC SO Guest Contêiner
Distribuição Versão Kernel Ferramenta Versão Distribuição
Docker 1.12.3 Arch Linux 12 4.8.13-1-ARCH Arch Linux LXC 2.0.6
Docker 1.10.3 Fedora 24 4.8.15-200.fc24-x86_64 Fedora LXC 2.0.6
Docker 1.12.3 OpenSUSE 42.2 4.4.36-8-default OpenSUSE LXC 1.1.12
Docker 1.4.1 Ubuntu 14.04 3.13.0-44generic Ubuntu Server LXC 1.0.7
Ubuntu Docker 1.12.1 16.04 4.4.0-31-generic Ubuntu Server LXC 2.0.6
Fonte: dados da pesquisa / 2019
Vale ressaltar que este cenário rodou uma avaliação estática (com apenas uma grande série temporal) e uma dinâmica (com várias séries temporais independentes entre si) por DMU para predição.
87
3.2.2 Cenários de Experimentação 2 – Roteadores Virtuais
Neste cenário, as medições foram escaladas, sendo realizadas em um servidor Dell R900 com 4x quad-core Xeon e 2.4 GHz de clock, 64 GB de RAM e 450 GB de disco rodando sobre o hipervisor de tipo-I – VMWare ESXi com versão 6.5. Esta é uma configuração típica de um servidor de datacenter, juntamente com uma das ferramentas de hipervisor mais usadas no mundo. Ambas as topologias objetivavam implementar a análise da estrutura fractal do tráfego TCP para avaliar, predizer e apontar as possíveis causas da queda de desempenho resultante da degradação causada pela virtualização e AS, ao longo do tempo da camada de transporte, em redes virtuais. Outrossim, eleger dentre os hipervisores de rede virtual, em análise, qual que apresenta melhor padrão fractal na entrega dos serviços TCP em uma escala de tempo mais prolongada. Cada experimento executado nas duas topologias, a serem descritas adiante, foram realizados usando distintas distribuições do Linux (Fedora 24, Ubuntu 14 e Ubuntu 16). Para isso, foram importadas as mesmas VMs usadas nas medições do cenário anterior (exceto àquelas que não conseguiram ser importadas, por problemas de compatibilidade entre as ferramentas de virtualização). Estas topologias apresentam características similares ao cenário anterior, mas agora variando a quantidade de vCPU (1, 2, 4 e 8), vRAM (1 GB, 2 GB, 4 GB e 8 GB), com as respectivas interfaces de rede emuladas pela ferramenta VMWare ESXi (E1000 ou VMXNET3). Neste cenário, as topologias criadas foram: 1) Guest-to-Guest-to-Container (GGC) – com a presença de contêineres de virtualização (LXC versus Docker). Assim, se a VM Guest do TG executa o Ubuntu 16, logo seu contêiner também será o Ubuntu 16, bem como a VM Guest que roda o DUT também executará o Ubuntu 16. Este mesmo esquema foi replicado com as outras distros do Linux, tal como no cenário anterior; ou, 2) Guest-to-Guest (GG) – sem a presença de ferramentas de contêiner. Sendo assim, é usada a mesma versão da distro do Linux em ambas as VMs Guest, no caso DUT e TG. Veja ambas as topologias nas Figuras 18 e 19.
88
Figura 18 - Topologias de Experimentação em Hipervisores de Tipo-I Guest-to-Guest-to-Container (GGC)
Fonte: pesquisa /2019 Figura 19 - Topologias de Experimentação em Hipervisores de Tipo-I Guest-to-Guest (GG)
Fonte: pesquisa /2019
A equação (3.2) computa o número de experimentos a serem realizados, i.e., o número de diferentes configurações de hipervisores de rede a serem avaliados.
( ) ( ) (3.2)
( ) ( ) ( ) ( )
89
3.3 Análise da Estrutura Fractal do Tráfego TCP nas redes virtuais
Nesta etapa, são realizados todos os cálculos para realizar a análise exploratória e avaliação fractal das variáveis aleatórias contínuas capturadas nas medições por configuração. A variabilidade do tráfego TCP será coletada através dos cálculos da dimensão fractal, das médias da largura de banda do TCP e da memória fractal das medições, agrupadas por interface, estratégia de contêiner, além da topologia de experimentação, para cada uma das configurações analisadas separadamente como hipervisor de rede. Todos os arquivos textos, dos processos estocásticos em análise, foram armazenados, visando atestar a AS com LRD nas redes virtuais. Esses também servem como um dataset para outras formas de avaliação da estrutura fractal do tráfego TCP em redes virtuais. Esta etapa foi realizada quase totalmente no RKWard, uma ferramenta gráfica da linguagem de programação estatística R. Assim, foram ativados os pacotes (packages) pracma e fractadim no RKWard que possuem respectivamente as funções: a) hurstexp(x) – que computa simultaneamente: i) estimação simples do parâmetro de Hurst; ii) estimação do parâmetro de Hurst com R corrigido sobre o S; iii) parâmetro de Hurst empírico; iv) parâmetro de Hurst empírico ajustado; e, v) parâmetro de Hurst teórico, de um conjunto de variáveis aleatórias contínuas. b) fd.estimate(x, method=”rodogram”) – cálcula a dimensão fractal de cada série temporal segundo os métodos boxcount, hallwood, genton, madogram (equação (2.5)), periodogram, rodogram (equação (2.4)), wavelet, etc. Cabe ressaltar que no valor do parâmetro de Hurst empírico ajustado, independentemente de quais sejam as variáveis aleatórias contínuas das séries temporais, de acordo com o tamanho das amostras, o valor sempre será o mesmo. Por exemplo, se existirem três arquivos, cada um com uma série temporal com 120 valores, logo o valor do parâmetro de Hurst empírico ajustado será o mesmo para os três arquivos. Já os outros cálculos apresentam valores diferentes para cada conjunto de variáveis aleatórias contínuas distintas entre si. Foi implementada uma função no RKWard denominada simpleHurst, cuja implementação no R pode ser observada no Quadro 3. Esta implementação seguiu a equação 2.2. Vale ressaltar que os valores gerados por esta função e o estimador do 90 parâmetro de Hurst, com R corrigido sobre o S (hurstexp(x)) são idênticos, exceto quando o número de variáveis aleatórias contínuas seja ímpar. Quadro 3 - Código da implementação do parâmetro de Hurst no R. simpleHurst<- function(y) { 1 sd.y<- sd(y) 2 m <- mean(y) 3 y <- y - m 4 max.y<- max(cumsum(y)) 5 min.y<- min(cumsum(y)) 6 RS <- (max.y - min.y)/sd.y 7 H <- log(RS) / log(length(y)) 8 return(H) }
3.4 Geração das fronteiras de eficiência dos modelos multiplicativos DEA O ajuste na DEA foi obtido devido a uma série de testes, aliado à experiência do tomador de decisão para lidar com tal problema. Desta forma, houve um processo de seleção passo a passo (stepwise) do melhor modelo DEA e quais as melhores variáveis de entrada e saída que deveriam compor as funções objetivo. O primeiro filtro para uma tomada de decisão refinada e contínua em DEA é a matriz de correlação de Pearson, que serve para mostrar se as variáveis de entrada e saída, em análise, são ou não correlacionadas e qual o grau de correlação entre elas. De acordo com Jenkins; Anderson (2003), o resultado obtido pela aplicação da matriz de correlação é a habilidade de identificar variáveis de entrada que estão fortemente correlacionadas com outras variáveis de entradas e, similarmente, com variáveis de saída. Contudo, o trabalho de Jenkins; Anderson (2003) propôs o uso de um teste de correlação parcial para determinar a relevância das variáveis de entrada e saída usando a covariância. O artigo de Fernandez-Palacinet et al. (2018) traz uma revisão criteriosa com evolução cronológica de uma série de trabalhos em DEA, que tratam de métodos contínuos ou passo a passo (stepwise) de seleção de variáveis. Assim, se a correlação se aproximar ou for igual a 1 e -1, então as variáveis de entrada e/ou de saída devem ser retiradas da avaliação DEA. Em seguida, deve ser novamente calculada a matriz de correlação até que as variáveis não sejam mais 91 correlacionadas entre si. É preferível que as variáveis tenham correlação negativa, de que positiva acima de 0,85. A seguir, serão apresentadas quatro Tabelas, sendo as duas primeiras –Tabela 4 e 5 – referentes ao primeiro cenário estático. A Tabela 4 é referente aos valores sem a transformação logarítmica e a Tabela 5 com a transformação logarítmica das variáveis de decisão. As outras duas Tabelas restantes – Tabela 6 e 7 – são referentes ao segundo cenário, com os mesmos padrões usados no primeiro cenário. Como na avaliação dinâmica, do primeiro cenário, cada série temporal tem que passar pela avaliação da matriz de correlação e estas refletem o mesmo padrão do primeiro cenário estático. Logo, estas matrizes de correlação das variáveis sem e com a transformação logarítmicas não serão exibidas, mesmo que a dimensão fractal tenha sido calculada usando o método madogram. Todas as matrizes de correlação podem ser também acessadas via datasets públicos dos resultados no Mendeley, a serem mencionados adiante. Outra informação pertinente é que X1 nas tabelas refere-se à variável de entrada, que é a dimensão fractal, sendo que Y1 e Y2 são respectivamente as variáveis de saída, referentes à média da largura de banda do TCP e o parâmetro de Hurst.
Tabela 4 - Matriz de Correlação das variáveis do cenário 1 – avaliação estática – sem transformação logarítmica. X1 Y1 Y2 X1 1 -0,12664 -0,38573 Y1 -0,12664 1 0,050013 Y2 -0,38573 0,050013 1 Fonte: dados da pesquisa/2019
Tabela 5 - Matriz de Correlação das variáveis do cenário 1 – avaliação estática – com transformação logarítmica. X1 Y1 Y2 X1 1 -0,10313 -0,38765 Y1 -0,10313 1 -0,03038 Y2 -0,38765 -0,03038 1 Fonte: dados da pesquisa/2019
92
Tabela 6 - Matriz de Correlação das variáveis do cenário 2 – sem transformação logarítmica. X1 Y1 Y2 X1 1 0,09691 0,18874 Y1 0,09691 1 0,31455 Y2 0,18874 0,31455 1 Fonte: dados da pesquisa/2019
Tabela 7 - Matriz de Correlação das variáveis do cenário 2 – com transformação logarítmica. X1 Y1 Y2 X1 1 -0,31577 0,241418 Y1 -0,31577 1 0,290916 Y2 0,241418 0,290916 1 Fonte: dados da esquisa/2019
Apesar dos modelos multiplicativos DEA serem a garantia de uma fronteira de eficiência mais acurada, a seleção das variáveis fractais por etapas escolhidas é válida mesmo para modelos DEA tradicionais. Portanto, em nenhuma das tabelas de correlação exibidas existem variáveis correlacionadas, atestando a validade, qualidade e confiabilidade do processo de tomada de decisão desenvolvido. 93
4 MODELOS MULTIPLICATIVOS DEA PROPOSTOS
O presente capítulo apresenta uma das principais contribuições deste trabalho doutoral, pois lança e detalha os hipervisores matemáticos, que são os modelos multiplicativos DEA usados para otimização do tráfego TCP em redes virtuais. Estes modelos DEA foram ajustados para dar um suporte formal acurado ao uso de variáveis de decisão em forma de razão (ratio) nas avaliações. Variáveis de razão são corriqueiras nas avaliações de desempenho de sistemas, além de outras comparações do cotidiano. Logo, modelos DEA tradicionais precisam ser modificados, para que os resultados reflitam uma fronteira de eficiência geométrica que obedecem a uma série de axiomas dos modelos multiplicativos DEA, já apresentados no capítulo 2. Aqui serão descritos os modelos multiplicativos DEA, de natureza estática ou dinâmica, apresentando qual a situação que estes devem ser aplicados para otimização do tráfego TCP em redes virtuais.
4.1. Cenário 1 – Medições com hipervisores de tipo-II
4.1.1 Modelos multiplicativos estáticos com CRS
Considere a suposição da orientação às saídas, uma vez que o objetivo deste modelo é manter constantes as variáveis de entrada, porém maximizando as variáveis de saída. Logo, objetiva-se manter menores valores de dimensão fractal e, ao mesmo tempo, busca-se valores mais altos para largura de banda do TCP, bem como valores mais altos do parâmetro Hurst. Assim, os modelos multiplicativos aqui desenvolvidos servem para avaliar ou predizer quais os padrões da estrutura fractal do tráfego TCP é (são) mais eficiente(s), para prestação de serviços de transporte em redes virtuais. Cabe ressaltar que estes modelos multiplicativos lançados não servem apenas para avaliar redes virtuais, mas podem ser utilizados para qualquer avaliação multicritério DEA em situações, nas quais todas as variáveis de decisão estão em forma de razão. Porém, apesar de neste trabalho serem usadas apenas uma variável de entrada e duas de saídas, todos os modelos multiplicativos DEA podem avaliar, conjuntamente, diversas variáveis de entrada e de saída. Estes modelos multiplicativos DEA orientados à saída são customizações dos modelos duais DEA – CCR, após passar por processo de log-linerização, que é obrigatório destes modelos DEA ajustados. Portanto, baseado no PPS multiplicativo da 94 equação 2.10, apresentado previamente, os modelos multiplicativos DEA com CRS, em sua forma log-linear, são formulados como:
(4.1)
∏
∏
Onde:
representa o valor da eficiência técnica de cada DMU;
o vetor das variáveis de entrada de todas as DMUs; é o vetor das variáveis de entrada da DMU em análise;
é o vetor das variáveis de saída de todas as DMUs;
é o vetor das variáveis de saída somente da DMU em análise;
é o vetor dos pesos referentes aos parceiros de excelência ou benchmarks de uma DMU.
Para converter as inequações e identificação de folgas/excessos na equação
(4.1) é necessário adicionar os coeficientes multiplicativos na formulação para as variáveis de entrada e saída, então:
∏ (4.2)
∏
Seguindo os axiomas/postulados da convexidade geométrica, monotonicidade e extrapolação mínima de Banker; Maindiratta (1986), o conjunto fechado e convexo ̂, ou seja, o PPS dos dados observados deve ser definido como: 95
̂ {( ̂ ̂)| ̂ ∑ ̂ ̂ ∑ ̂ }(4.3)
Onde ̂ ̂ são relacionados com a transformação para uma base logarítmica dos valores das variáveis de entrada e saída, avaliadas para alcançar a correta elasticidade de escala da fronteira de eficiência geométrica. O uso do mapeamento um a um das variáveis, para uma base logarítmica, transforma as formulações multiplicativas originais (equações (4.1) e (4.2)) em um modelo de programação log- linear, obedecendo a estrita monotonicidade. Aplicando logaritmos e, respectivamente, ̂ (equação (4.3)) na equação (4.2), resulta nas formulações multiplicativas DEA com CRS estáticas dispostas na Tabela 8.
Tabela 8 - Equações dos modelos multiplicativos e de supereficiência multiplicativo DEA (SMDEA) com CRS e orientação à saída propostos Modelo multiplicativo com orientação à saída Modelo supermultiplicativocom orientação à saída (SMDEA) Função Objetivo: Função Objetivo:
(4.4) (4.5) Sujeito a: Sujeito a:
∑ ̂ ̂ ∑ ̂ ̂
∑ ̂ ̂ (4) ∑ ̂ ̂ (4)
Fonte: dados da pesquisa / 2019
O trabalho de Olesen et al. (2017) criou a noção de razão de eficiência potencial (potential ratio (PR)) para modelos com CRS e VRS, nos quais uma DMU só será considerada como completamente eficiente se, e somente se, tiver escore de supereficiência maior ou igual a um. Além disso, a soma de todas as folgas/excessos seja zero. Logo, o PR satisfaz aos postulados da convexidade seletiva e a livre disposição (freely disposable) de todas as variáveis de entrada e saída. 96
Para Banker et al. (2004), a condição que uma DMU deveria satisfazer para alcançar a eficiência é ter escore de supereficiência maior ou igual a um, com todas as folgas/excessos com valor zero. Por empregar um modelo de maximização, então o escore de eficiência deve ser computado com o valor inverso do seu valor ótimo – obtidos nas equações (4.4) e (4.5) – por DMU. Logo, para se obter o escore de eficiência e supereficiência de cada DMU nas equações (4.4) e (4.5) é necessário fazer esta computação:
(4.6)
Ressalta-se que as DMUs consideradas como supereficientes possuem escore_de_eficiência>1. É proposto o modelo de super eficiência multiplicativo DEA (SMDEA) com CRS e orientado às saídas, para eleger a unidade mais eficiente, em relação às várias outras unidades comparadas, segundo variáveis fractais elencadas, acerca do tráfego TCP em redes virtuais. Todos os modelos multiplicativos DEA, propostos e apresentados por este trabalho, foram implementados no software LINDO8. As formulações foram comparadas com outros solvers DEA customizados, sendo que todos os valores dos resultados obtidos foram exatamente iguais. Cabe, ainda, citar que estes modelos multiplicativos DEA servem apenas para avaliações estáticas, i.e., em uma única série temporal por DMU.
4.1.2 Modelo multiplicativo dinâmico com CRS ou de janela multiplicativo (Windows multiplicative DEA model) com orientação às saídas
É factual que todos os modelos matemáticos precisam ser designados para solucionar o problema em questão, corrigindo possíveis causas de erros de computação. Como mencionado anteriormente, é indispensável ajustar os modelos tradicionais DEA para computar corretamente as fronteiras de eficiência, na presença de variáveis em forma de razões, transformando modelos clássicos em formas multiplicativas (BANKER; MOREY, 1986). Como um modelo de janela DEA avalia as DMUs, dinamicamente, em várias séries temporais por DMU, logo, considere quando uma DMU utiliza m entradas para produzir s saídas por um período de tempo T. Considere o conjunto de n DMUs avaliadas, sendo t um sub-vetor das séries temporaisT (onde t=1-2-3-4-5, 2-3-4-5-6, 3-
8Linear, Interactive, and Discrete Optimizer - LINDO software for linear programmingavailable at URL: http://www.lindo.com/index.php/ls-downloads 97
4-5-6-7, 4-5-6-7-8, 5-6-7-8-9 e 6-7-8-9-10), com o mesmo tamanho da janela de avaliação. Sendo a ( ), referente a um vetor de entrada
( ) e um vetor de saída ( ), então o PPS dinâmico ou inter- temporal deve ser formalizado como:
{( ) } (4.7)
Considere a dimensão fractal, média da largura de banda do TCP e Hurst como, respectivamente, uma variável de entrada e duas variáveis de saídas, obtidas nas avaliações da estrutura fractal do tráfego TCP nas redes virtuais. Selecionando apenas duas DMUs (ver Tabela 15 ou 16), de acordo com , por exemplo, e (ou qualquer outra combinação) deveria criar uma unidade virtual . Contudo, isto não é matematicamente possível, devido ao problema da proporcionalidade, quando as variáveis de entrada ou saída não podem ser aumentadas ou diminuídas proporcionalmente, devido à falta de suporte da elasticidade de escala em modelos DEA clássicos. Assim, a violação do axioma da proporcionalidade, dentre outros postulados, já foi apresentada no Capítulo 2. Outra questão é a convexidade, correspondente à falha na computação das somas ponderadas das variáveis usando ratios, que não corresponderão aos valores corretos, porque esse problema é causado pelo erro no cálculo dos escores de eficiência (EMROUZNEJAD; AMIN, 2009). Trabalhos anteriores em DEA tentaram relaxar a restrição da convexidade em modelos multiplicativos e em outros modelos para corrigir esta restrição, como descrito em Emrouznejad; Amin (2009). A pesquisa de Emrouznejad et al.(2010) apresenta um modelo multiplicativo que usa o conceito de média geométrica não-dimensional (invariância da unidade), como propriedade. No entanto, este trabalho preferiu continuar seguindo os axiomas da convexidade, proporcionalidade (EMROUZNEJAD; CABANDA, 2010), extrapolação mínima, monotonicidade (BANKER; MAINDIRATTA, 1986), etc. Assim, o uso da convexidade geométrica, para prover uma interpolação acurada das possibilidades de produção, é obrigatória quando as variáveis estão na forma de ratios.
Até este trabalho, todos os modelos multiplicativos DEA realizavam apenas avaliações estáticas. Contudo, esta tese está lançando um novo modelo de janela multiplicativo DEA (Windows multiplicative DEA (WMDEA)), apropriado para avaliações 98 de DMUs usando as mesmas variáveis de decisão, em vários períodos de tempo independentes, por isso é um modelo dinâmico. Porém, é necessário amplificar o tamanho do PPS para o tamanho da janela a ser analizada, como mostrada no anteriormente (equação (4.7)). Para facilitar o entendimento, n é um símbolo relacionado ao número de DMUs, k é o número de períodos de tempo a serem avaliados, p é o tamanho da janela ( ) e w é o número total de janelas de avaliação. Todos os símbolos usados são relacionados às seguintes fórmulas na Tabela 9.
Tabela 9 - Fórmulas usadas para computar alguns índices do modelo de janela multiplicativo DEA
Descrição Fórmula
Número de janelas
Número de DMUs em cada janela
Número de diferentes DMUs
Número total de DMUs ( ) ( )
Fonte: dados da pesquisa/2019
O modelo WMDEA é orientado às saídas, porque seu objetivo é maximizar as variáveis de saída, mantendo as entradas constantes. Sua formulação busca os valores mais baixos da dimensão fractal, mas principalmente valores maiores das médias da largura de banda do TCP e memória fractal (Hurst). Baseado no PPS multiplicativo ao longo do tempo, o modelo de janela multiplicativo DEA com CRS e orientação às saídas, em sua forma inicial é dado por:
(4.9)
∏
∏
99
Para converter as inequações e identificação das restrições das folgas/excessos ( ) da equação (4.9), é obrigatório adicionar estes coeficientes multiplicativos
na formulação para entradas e saídas respectivamente, então:
∏ (4.10)
∏
Segundo Banker et al. (1984), modelos multiplicativos DEA são classificados como estimadores de retorno de escala, sendo ativados para realizar uma acurada estimação de elasticidade de escala (BANKER et al., 2004). Modelos multiplicativos são apropriados para serem empregados em problemas que exibam convexidade geométrica, i.e., sua função de produção é não-côncava em algumas regiões, com o PPS sendo não-convexo, como exemplificado pelas três variáveis usadas nas avaliações nas redes virtuais. Então, o modelo de estimação linear dos métodos tradicionais DEA precisa ser modificado pela função de produção log-linear por partes, ao longo do tempo com o seguinte PPS:
̂ ̂ ̂ {( )| ∑ ̂ ̂ ∑ ̂ ̂ } (4.11)
Assim, ̂ ̂ são ligados ao processo de transformação logarítmica das variáveis, de entrada e saída coletivamente, para alcançarem a correta elasticidade de escala da fronteira de eficiência. A aplicação de logaritmos em (4.10) introduz a formulação do modelo de janela multiplicativo DEA com CRS e orientação às saídas, na sua forma log-linear a seguir:
(4.12)
∑ ̂ ̂ 100
∑ ̂ ̂
O uso do circunflexo (^) nas variáveis de entrada e saída em (4.12) está representando a transformação logarítmica das variáveis em forma de ratios. Além disso, por ser um modelo de maximização, o cálculo do escore de eficiência deve ser computado pelo inverso do valor ótimo obtido em (4.12), em cada série temporal da janela de avaliação por DMU. Assim, para obter o escore de eficiência de cada DMU sobre o tempo em uma janela realize a computação abaixo:
(4.13)
Finalmente, para completar a avaliação com o modelo WMDEA calcule a média do escore_de_eficiênciada por janela, bem como calcule a média de todos os escore_de_eficiência em todas as janelas por , para gerar o ranqueamento. O modelo WMDEA foi implementado no LINDO, bem como foi feita uma completa transformação logarítmica dos dados para executar o modelo de janela multiplicativo DEA no DEA-SOLVER9 e PIM-DEA10, no qual os resultados foram novamente todos idênticos. O WMDEA deve ser aplicado quando as DMUs possuem diversas séries temporais independentes, avaliando o mesmo conjunto de variáveis de entrada e saída em janelas de tempo diferentes. O objetivo desta avaliação dinâmica é avaliar o comportamento das DMUs ao longo de vários períodos de tempo distintos. Por isso, este o WMDEA é adequado para comparar DMUs dinamicamente quando todas as variáveis estiverem em forma de ratio, ou seja, o modelo pode ser aplicado para resolver problemas além do apresentado nesta tese.
9 DEA-SOLVER – Mais informações e descrições disponíveis na URL URL: http://www.saitech- inc.com/products/prod-dsp.asp 10 Performance Improvement Management (PIM-DEA) – Informações disponíveis na URL: http://deazone.com/en/software and http://www.deasoftware.co.uk/ 101
4.2 Cenário 2 – Medições escaladas em Hipervisor de Tipo-I
4.2.1 Modelo estático orientado à entrada – Super-Cobb-Douglas com CRS
Outro nome dado para os modelos multiplicativos DEA são modelos Cobb- Douglas (COOK; ZHU, 2014). Por esta razão, o nome deste modelo a ser definido adiante é Super-Cobb-Douglas com CRS orientado à entrada. Modelos multiplicativos DEA, introduzidos por Seiford et al. (1982), recebem este nome porque sua função objetivo inicial (por exemplo: equações (4.1 e (4.9)) tem um produtório (∏) que será transformado em um somatório (∑) para computação da programação linear das variáveis de decisão em forma de ratio como na equação (4.14). Esta formulação proposta altera a fronteira de eficiência reta e linear por partes (piecewise linear frontier) dos modelos com CRS, por outra distinta com forma de S (s- shaped), através de uma estratégia de Cobb-Douglas (Cook & Zhu, 2014). Assim, o modelo de supereficiência com orientação à entrada Cobb-Douglas com CRS, em sua forma de programação log-linear, é apresentada na equação da seguinte maneira:
(4.14)
∑ ̂ ̂
∑ ̂ ̂
Considere um conjunto de n DMUs em avaliação como a DMUj (para cada
) relacionado ao vetor de entradas Cobb-Douglas de ̂ ( ̂ ̂ ) e um vetor de saídas Cobb-Douglas de ̂ ( ̂ ̂ ). Ademais, as variáveis de folgas da entrada e excessos das saídas, respectivamente, como s- e s+, foram empregadas na formulação 4.14, para desvendar se uma DMU é ou não completamente eficiente. Para satisfazer esta condição, é obrigatório que o escore_de_eficiência>=1, com zero em todas as folgas e excessos (BANKER et al., 2004). Em modelos de supereficiência DEA (ANDERSEN; PETERSEN, 1993), a unidade sob avaliação chamada de DMU0 é retirada do conjunto de observações durante sua avaliação. Esta deleção da DMU, em análise, aumenta seu escore_de_eficiência, para um valor superior a um, quando a DMU é considerada 102 como eficiente pelos modelos clássicos. No entanto, as DMUs consideradas ineficientes continuam com seu mesmo escore_de_eficiência nos modelos de supereficiência. O modelo Super-Douglas DEA CCR-I foi implementado no LINDO, com os mesmos resultados e análise de sensibilidade de outros solvers DEA já consolidados. Cabe dizer que este modelo deve ser usado quando cada uma das DMUs tiver apenas uma série temporal a ser avaliada. Outrossim, este modelo pode ser usado para avaliar problemas de decisão multicritério de DMUs com diversas variáveis de entrada e saída, em forma de razão, não se restringindo ao problema de otimização de redes virtuais, como o apresentado nesta tese. 103
5 ANÁLISE DOS RESULTADOS
Os resultados obtidos foram agrupados por cenário, topologia, além do modelo multiplicativo DEA desenvolvido associado ao cenário, que foram apresentados nos dois capítulos anteriores. Contudo, este trabalho, por ter realizado normalização passo a passo (stepwise) das variáveis fractais ao longo de todo o trabalho doutoral, através de matrizes de correlação (Tabelas 4 a 7), logo, algumas variáveis foram retiradas das avaliações multicritério desenvolvidas. Assim, as variáveis de entrada e saída ficaram:
Tabela 10 - Variáveis de Entrada e Saída – Cenário 1 e 2 – Estático Tipo Nome Método/Equação Entrada – X1 Dimensão fractal – método rodogram Equação (2.4) Média arimética da série Saída – Y1 Média de largura de banda do TCP temporal Saída – Y2 Parâmetro de Hurst/Memória Fractal Equação (2.2) Fonte: dados da pesquisa / 2019
Tabela 11 - Variáveis de Entrada e Saída – Cenário 1 – Dinâmico Tipo Nome Método/Equação Entrada – X1 Dimensão fractal – método madogram Equação (2.5) Média arimética da série Saída – Y1 Média de largura de banda do TCP temporal Saída – Y2 Parâmetro de Hurst/Memória Fractal Equação (2.2) Fonte: dados da pesquisa / 2019
A seguir, serão apresentados e interpretados os resultados obtidos. No entanto, como no início deste trabalho foi realizada uma análise exploratória das séries temporais, obtidas nas avaliações, observou-se um padrão log-logístico que remete às FDPs de cauda pesada, típico da AS com LRD. Assim, no apêndice deste trabalho serão apresentados alguns gráficos que atestam este padrão nas redes virtuais, em uma ou várias das DMUs avaliadas.
5.1 Cenário 1 – Medições com hipervisores de Tipo-II
5.1.1 Modelo SMDEA com CRS orientado às saídas
Esta seção discute os resultados referentesàs três últimas camadas da metodologia de avaliação fractal de desempenho proposta (Figura 12). A Tabela 12 contém os resultados das medições usando TCP da topologia GGC nas redes virtuais criadas, ou seja, o cenário 1 - estático. Note que qualquer conjunto de ferramentas para fornecer serviços TCP em uma rede virtual, por linha, é considerado como DMU ou hipervisor de rede, bem como os resultados são ordenados alfabeticamente. 104
No entanto, a Tabela 12 deve ser apresentada completa, porque é obrigatório fazer uma análise fractal detalhada do maior conjunto de possibilidades de configurações para ativar redes virtuais, que podem ser consideradas cada uma como um hipervisor de rede. Portanto, quanto mais se avalia a quantidade de dispositivos virtuais, maior a chance de se encontrar o padrão fractal desejado para se prestar um serviço ótimo com o TCP ou outro protocolo. Contudo, escalar o conjunto de possibilidades das configurações dos hipervisores de rede pode ser dispendioso do ponto de vista do tempo que se levará para montagem, análise e otimização destas DMUs. Como mostrado na Tabela 12, os nomes das DMUs sempre seguem o mesmo formato com a distro do Linux usada, seguido da ferramenta de hipervisor, mais sua interface de rede emulada (se existir) e o aplicativo de contêiner. As variâncias foram computadas, porém a dimensão fractal já carrega essa informação intrinsecamente. Por esse motivo, como o framework de avaliação fractal é uma metodologia contínua. ou passo a passo, então este descartou esta e outras variáveis ao longo do trabalho. Como destacado anteriormente, (veja na Tabela 12), cada DMU tem um comportamento fractal inteiramente distinto ao longo do tempo, com diferente dimensão fractal, largura de banda do TCP e memória (H), e que são independentes entre si. Observe que ao se alterar apenas um conjunto de ferramentas (cada linha na Tabela 12) a sua dimensão fractal, largura de banda do TCP e memória fractal da DMU muda. Esta descoberta lança uma nova abordagem para avaliar o tráfego TCP com AS e LRD nas redes virtuais, introduzindo a dimensão fractal como índice para diagnosticar a irregularidade no tráfego TCP. Por exemplo, conforme observado na Tabela 12, a configuração com a maior largura de bandado TCP (ou seja, DMU19) tem a largura de banda do TCP 463,313% maior do que a menor configuração com largura de banda do TCP (isto é, DMU21). Logo, este mesmo padrão se repete em todas as outras DMUs avaliadas, até com as demais variáveis. Para se fazer o cálculo da diferença de desempenho entre apenas duas configurações, calcule a média da largura de banda do TCP (ou cada uma das outras variáveis avaliadas) de cada DMU e encontre a diferença da ( ) porcentagem usando como exemplo.
Além disso, observe que esse padrão de desempenho tem uma enorme diferença, até em DMUs que possuem o mesmo sistema operacional. Observe que as cinco DMUs com as médias mais altas da largura de bandado TCP (DMU19, DMU48, DMU29, DMU18 e DMU47, respectivamente) usam o hipervisor tipo-II – VMWare, já as 105 três médias mais altas da largura de banda do TCP também estão relacionadas à ferramenta de contêiner LXC. Assim, a Tabela 12 detalha e introduz uma análise fractal inovadora em redes de computadores, lançando um ponto de inflexão na avaliação de desempenho de redes/computadores, na qual a natureza fractal de um conjunto de ferramentas precisa sempre ser considerada separadamente para predição e comparação. Em resumo, como na Tabela 12 (e demais), cada DMU tem dimensão fractal, desempenho da largura de banda do TCP e memória fractal (Hurst) distintos ao longo do tempo. Então, o tomador de decisão precisa escolher ou predizer qual o melhor conjunto de ferramentas, de acordo com estas variáveis, criando um problema multicritério a ser resolvido. Desta forma, o modelo analítico desenvolvido deverá garantir a eleição do hipervisor de rede ou DMU mais eficiente, segundo a melhor combinação linear dentre as possibilidades das variáveis fractais avaliadas.
Tabela 12 - Montagem das DMUs para avaliação com modelos multiplicativos DEA estáticos orientados à saída, além da avaliação fractal dos resultados sem as DMUs com SRD (OUTPUT) (INPUT) (OUTPUT) Média DMU Dimensão Hurst TCP em Fractal # kbps 1 ARCH12 – VIRTUALBOX – PCNet PCI – DOCKER – GGC 1,753393 40208,64 0,6149959 2 ARCH12 – VIRTUALBOX – PCNet FAST – DOCKER – GGC 1,653052 39310,5 0,6380813 ARCH12 – VIRTUALBOX – PRO 1000 MT DESKTOP – 3 DOCKER – GGC 1,514416 51299,79 0,7139144 ARCH12 – VIRTUALBOX – PRO 1000 T SERVER – DOCKER 4 – GGC 1,429046 57252,49 0,6303365 5 ARCH12 – VIRTUALBOX – PCNet PCI – LXC – GGC 1,819048 45993,36 0,6542005 6 ARCH12 – VIRTUALBOX – PCNet FAST – LXC – GGC 1,758913 45400,68 0,7290385 ARCH12 – VIRTUALBOX – PRO 1000 MT DESKTOP – LXC – 7 GGC 1,732166 121542,6 0,5670684 ARCH12 – VIRTUALBOX – PRO 1000 T SERVER – LXC – 8 GGC 1,583254 96962,65 0,8320479 9 ARCH12 – VMWARE – DOCKER – GGC 1,147171 45114,94 0,7176149 10 ARCH12 – VMWARE – LXC – GGC 1,310753 60895,55 0,8115613 11 FEDORA24 – VIRTUALBOX – PCNet PCI – DOCKER – GGC 1,638401 55586,69 0,5340552 FEDORA24 – VIRTUALBOX – PCNet FAST – DOCKER – 12 GGC 1,722559 55881,09 0,5435163 FEDORA24 – VIRTUALBOX – PRO 1000 MT DESKTOP – 13 DOCKER – GGC 1,972882 140166,7 0,522739 FEDORA24 – VIRTUALBOX – PRO 1000 T SERVER – 14 DOCKER – GGC 1,696524 120597,2 0,5856474 15 FEDORA24 – VIRTUALBOX – PCNet PCI – LXC – GGC 1,779845 49936,99 0,7378332 16 FEDORA24 – VIRTUALBOX – PCNet FAST – LXC – GGC 1,675085 54199,33 0,6086283 FEDORA24 – VIRTUALBOX – PRO 1000 T SERVER – LXC – 17 GGC 1,551302 115458,8 0,607753 18 FEDORA24 – VMWARE – DOCKER – GGC 1,396388 213201,2 0,6737299 106
19 FEDORA24 – VMWARE – LXC – GGC 1,355828 220979,0 0,8155753 OPENSUSE42.2 – VIRTUALBOX – PCNet PCI – DOCKER – 20 GGC 1,759395 44457,31 0,7755444 OPENSUSE42.2 – VIRTUALBOX – PCNet FAST – DOCKER – 21 GGC 1,69321 39228,46 0,6776561 OPENSUSE42.2 – VIRTUALBOX – PRO 1000 MT DESKTOP 22 – DOCKER – GGC 1,954307 144008,7 0,6322082 OPENSUSE42.2 – VIRTUALBOX – PRO 1000 T SERVER – 23 DOCKER – GGC 1,706839 113361,1 0,5502623 24 OPENSUSE42.2 – VIRTUALBOX – PCNet PCI – LXC – GGC 1,895940 43281,01 0,6908904 OPENSUSE42.2 – VIRTUALBOX – PCNet FAST – LXC – 25 GGC 1,637878 48302,53 0,6469991 OPENSUSE42.2 – VIRTUALBOX – PRO 1000 MT DESKTOP 26 – LXC – GGC 1,981541 136795,8 0,6177616 OPENSUSE42.2 – VIRTUALBOX – PRO 1000 T SERVER – 27 LXC – GGC 1,685670 113857,6 0,5861757 28 OPENSUSE42.2 – VMWARE – DOCKER – GGC 1,522748 80704,14 0,7692495 29 OPENSUSE42.2 – VMWARE – LXC – GGC 1,446501 213607,4 0,6591165 30 UBUNTU14 – VIRTUALBOX – PCNet PCI – DOCKER – GGC 1,708281 40606,23 0,6374863 UBUNTU14 – VIRTUALBOX – PCNet FAST – DOCKER – 31 GGC 1,779336 41057,64 0,6240196 UBUNTU14 – VIRTUALBOX – PRO 1000 MT DESKTOP – 32 DOCKER – GGC 1,729518 146780,8 0,8451504 UBUNTU14 – VIRTUALBOX – PRO 1000 T SERVER – 33 DOCKER – GGC 1,861722 95542,23 0,6515093 34 UBUNTU14 – VIRTUALBOX – PCNet PCI – LXC – GGC 1,698271 41681,55 0,7819212 35 UBUNTU14 – VIRTUALBOX – PCNet FAST – LXC – GGC 1,824841 41195,93 0,7150646 UBUNTU14 – VIRTUALBOX – PRO 1000 MT DESKTOP – 36 LXC – GGC 1,743032 140712,6 0,7451546 UBUNTU14 – VIRTUALBOX – PRO 1000 T SERVER – LXC – 37 GGC 1,518187 95067,18 0,7007306 c3 8 UBUNTU14 – VMWARE – DOCKER – GGC 1,412104 73706,68 0,6205952 39 UBUNTU14 – VMWARE – LXC – GGC 1,621151 105727,1 0,7187318 40 UBUNTU16 – VIRTUALBOX – PCNet PCI – DOCKER – GGC 1,610912 44675,4 0,5748441 UBUNTU16 – VIRTUALBOX – PCNet FAST – DOCKER – 41 GGC 1,689229 43207,5 0,7135971 UBUNTU16 – VIRTUALBOX – PRO 1000 T SERVER – 42 DOCKER – GGC 1,661918 123330,8 0,5855856 43 UBUNTU16 – VIRTUALBOX – PCNet PCI – LXC – GGC 1,394481 61309,08 0,6616379 44 UBUNTU16 – VIRTUALBOX – PCNet FAST – LXC – GGC 1,434656 57188,68 0,8082247 UBUNTU16 – VIRTUALBOX – PRO 1000 MT DESKTOP – 45 LXC – GGC 2,000000 131292,4 0,5152529 UBUNTU16 – VIRTUALBOX – PRO 1000 T SERVER – LXC – 46 GGC 1,802845 111738,8 0,5759278 47 UBUNTU16 – VMWARE – DOCKER – GGC 1,488392 183325,3 0,8549348 48 UBUNTU16 – VMWARE – LXC – GGC 1,319123 217319,8 0,6895153
Fonte: dados da pesquisa / 2019
Como discutido anteriormente, é preciso obrigatoriamente fazer uma transformação logarítmica de todos os valores da Tabela 12 (e de qualquer outra Tabela que usar um modelo multiplicativo DEA). No entanto, como ambas variáveis, 107 tanto uma de entrada - dimensão fractal, quanto uma de saída - Parâmetro de Hurst são números pequenos, então seus logaritmos serão negativos. Por esta razão, uma log-normalização destes pequenos números deve ser feita, dividindo-os por um pequeno número infinitesimal ( ), em seguida calcule o logaritmo destas divisões ( ( )) Em contraste, como a outra variável de saída – média da largura de banda do TCP tem valores grandes, então é necessário apenas obter os logaritmos desses números
( ( )). A Tabela 13 mostra os valores das variáveis de entrada e saída, após o processo de transformação logarítmica.
Tabela 13 - Montagem das DMUs para avaliação com modelos multiplicativos DEA estáticos orientados à saída, após a transformação logarítmica das variáveis de entrada e saída # DMU (Î)X1 (Ô)Y1 (Ô)Y2 1 ARCH12 – VIRTUALBOX – PCNet PCI – DOCKER – GGC 5,2438793 4,6043194 4,7888722 ARCH12 – VIRTUALBOX – PCNet FAST – DOCKER – 2 GGC 5,2182865 4,5945086 4,8048760 ARCH12 – VIRTUALBOX – PRO 1000 MT DESKTOP – 3 DOCKER – GGC 5,1802452 4,7101156 4,8536461 ARCH12 – VIRTUALBOX – PRO 1000 T SERVER – 4 DOCKER – GGC 5,1550462 4,7577944 4,7995725 5 ARCH12 – VIRTUALBOX – PCNet PCI – LXC – GGC 5,2598442 4,6626951 4,8157109 6 ARCH12 – VIRTUALBOX – PCNet FAST – LXC – GGC 5,2452444 4,6570624 4,8627505 ARCH12 – VIRTUALBOX – PRO 1000 MT DESKTOP – 7 LXC – GGC 5,2385895 5,0847285 4,7536354 ARCH12 – VIRTUALBOX – PRO 1000 T SERVER – LXC 8 – GGC 5,1995506 4,9866045 4,9201483 9 ARCH12 – VMWARE – DOCKER – GGC 5,0596282 4,6543204 4,8558914 10 ARCH12 – VMWARE – LXC – GGC 5,1175209 4,7845856 4,9093213 FEDORA24 – VIRTUALBOX – PCNet PCI – DOCKER – 11 GGC 5,2144202 4,7449708 4,7275861 FEDORA24 – VIRTUALBOX – PCNet FAST – DOCKER – 12 GGC 5,2361741 4,7472649 4,7352126 FEDORA24 – VIRTUALBOX – PRO 1000 MT DESKTOP – 13 DOCKER – GGC 5,2951011 5,1466448 4,7182849 FEDORA24 – VIRTUALBOX – PRO 1000 T SERVER – 14 DOCKER – GGC 5,2295600 5,0813372 4,7676362 15 FEDORA24 – VIRTUALBOX – PCNet PCI – LXC – GGC 5,2503822 4,6984224 4,8679582 16 FEDORA24 – VIRTUALBOX – PCNet FAST – LXC – GGC 5,2240368 4,7339939 4,7843521 FEDORA24 – VIRTUALBOX – PRO 1000 T SERVER – 17 LXC – GGC 5,1906964 5,0624270 4,7837271 18 FEDORA24 – VMWARE – DOCKER – GGC 5,1450061 5,3287896 4,8284858 19 FEDORA24 – VMWARE – LXC – GGC 5,1322046 5,3443510 4,9114641 OPENSUSE42.2 – VIRTUALBOX – PCNet PCI – 20 DOCKER – GGC 5,2453634 4,6479432 4,8896067 OPENSUSE42.2 – VIRTUALBOX – PCNet FAST – 21 DOCKER – GGC 5,2287108 4,5936013 4,8310094 OPENSUSE42.2 – VIRTUALBOX – PRO 1000 MT 22 DESKTOP – DOCKER – GGC 5,2909928 5,1583887 4,8008601 108
OPENSUSE42.2 – VIRTUALBOX – PRO 1000 T SERVER 23 – DOCKER – GGC 5,2321926 5,0544641 4,7405698 OPENSUSE42.2 – VIRTUALBOX – PCNet PCI – LXC – 24 GGC 5,2778246 4,6362974 4,8394092 OPENSUSE42.2 – VIRTUALBOX – PCNet FAST – LXC – 25 GGC 5,2142815 4,6839699 4,8109037 OPENSUSE42.2 – VIRTUALBOX – PRO 1000 MT 26 DESKTOP – LXC – GGC 5,2970031 5,1360728 4,7908209 OPENSUSE42.2 – VIRTUALBOX – PRO 1000 T SERVER 27 – LXC – GGC 5,2267726 5,0563620 4,7680278 28 OPENSUSE42.2 – VMWARE – DOCKER – GGC 5,1826280 4,9068958 4,8860672 29 OPENSUSE42.2 – VMWARE – LXC – GGC 5,1603187 5,3296163 4,8189622 UBUNTU14 – VIRTUALBOX – PCNet PCI – DOCKER – 30 GGC 5,2325593 4,6085927 4,8044709 UBUNTU14 – VIRTUALBOX – PCNet FAST – DOCKER – 31 GGC 5,2502580 4,6133940 4,7951982 UBUNTU14 – VIRTUALBOX – PRO 1000 MT DESKTOP – 32 DOCKER – GGC 5,2379251 5,1666693 4,9269340 UBUNTU14 – VIRTUALBOX – PRO 1000 T SERVER – 33 DOCKER – GGC 5,2699148 4,9801954 4,8139206 34 UBUNTU14 – VIRTUALBOX – PCNet PCI – LXC – GGC 5,2300070 4,6199439 4,8931630 35 UBUNTU14 – VIRTUALBOX – PCNet FAST – LXC – GGC 5,2612250 4,6148543 4,8543453 UBUNTU14 – VIRTUALBOX – PRO 1000 MT DESKTOP – 36 LXC – GGC 5,2413054 5,1483330 4,8722464 UBUNTU14 – VIRTUALBOX – PRO 1000 T SERVER – 37 LXC – GGC 5,1813253 4,9780306 4,8455511 38 UBUNTU14 – VMWARE – DOCKER – GGC 5,1498667 4,8675068 4,7928084 39 UBUNTU14 – VMWARE – LXC – GGC 5,2098235 5,0241863 4,8565669 UBUNTU16 – VIRTUALBOX – PCNet PCI – DOCKER – 40 GGC 5,2070718 4,6500684 4,7595501 UBUNTU16 – VIRTUALBOX – PCNet FAST – DOCKER – 41 GGC 5,2276885 4,6355591 4,8534531 UBUNTU16 – VIRTUALBOX – PRO 1000 T SERVER – 42 DOCKER – GGC 5,2206096 5,0910715 4,7675904 43 UBUNTU16 – VIRTUALBOX – PCNet PCI – LXC – GGC 5,1444126 4,7875248 4,8206204 44 UBUNTU16 – VIRTUALBOX – PCNet FAST – LXC – GGC 5,1567478 4,7573101 4,9075321 UBUNTU16 – VIRTUALBOX – PRO 1000 MT DESKTOP – 45 LXC – GGC 5,3010300 5,1182396 4,7120204 UBUNTU16 – VIRTUALBOX – PRO 1000 T SERVER – 46 LXC – GGC 5,2559584 5,0482040 4,7603680 47 UBUNTU16 – VMWARE – DOCKER – GGC 5,1727173 5,2632224 4,9319330 48 UBUNTU16 – VMWARE – LXC – GGC 5,1202853 5,3370993 4,8385439
Fonte: dados da pesquisa / 2019
A Tabela 14 apresenta todos os valores ótimos da função objetivo ( ), escores de eficiência, com análise de sensibilidade (valores das folgas/excessos) e classificação para avaliação das DMUs usando o modelo SMDEA proposto na equação (4.5), com suas respectivas variáveis de entrada e saída (Tabela 5.1). Como todas as variáveis estavam em forma de razão, logo estas passaram pelo processo obrigatório de log-transformação, como pode ser visto na Tabela 13. 109
Apenas os escores de supereficiência das DMUS do TOP3, segundo modelo SMDEA são destacadas na coluna de classificação da Tabela 14. Deve ser notado que a DMU mais eficiente (DMU19), que não tem nenhuma folga ou excesso, está apresentando um CRS, isto é, a DMU19 é a solução ideal para este problema multicritério (ver Teorema 6 de Banker et al. (2004)). Logo, a DMU19 tem a maior média de largura de banda do TCP, a quinta maior memória fractal e a quarta menor dimensão fractal, refletindo um efeito de suavização do tráfego TCP, tal como acontece com as outras DMUs supereficientes (DMU48 e DMU9). Já a DMU48 possui a segunda maior largura de banda do TCP, a segunda menor dimensão fractal, representando um efeito mais suave do tráfego TCP na rede virtual, esta DMU também possui uma memória fractal considerável ao longo do tempo. Também é importante observar que a formulação SMDEA não tem solução inviável para DMU zero, demonstrando a corretude matemática deste modelo, para a previsão de serviços TCP em redes virtuais ao longo do tempo. Foi realizada uma avaliação multiplicativa DEA (equação (4.4)), e, como esperado, os escores de eficiência obtidos para todas as DMUs ineficientes são os mesmos. Logo, a avaliação completa do modelo SMDEA é apresentada na Tabela 14.
Tabela 14 - , eficiência, análise de sensibilidade e classificação de cada DMU no modelo de avaliação SMDEA
# Eficiência S1- S2+ S3+ Classificação DMU1 1,050851 95,16% 0 0 0 39 DMU2 1,042308 95,94% 0 0,011375 0 28 DMU3 1,024042 97,65% 0 0 0 13 DMU4 1,030067 97,08% 0 0 0 19 DMU5 1,048019 95,42% 0 0 0 32 DMU6 1,035224 96,60% 0 0,003967 0 23 DMU7 1,055049 94,78% 0 0 0 41 DMU8 1,013001 98,72% 0 0 0 9 DMU9 0,9995659 100,04% 0 0,078160 0 3 DMU10 1,000078 99,99% 0 0 0 4 DMU11 1,057507 94,56% 0 0 0 44 DMU12 1,060235 94,32% 0 0 0 46 DMU13 1,071560 93,32% 0 0 0 47 DMU14 1,050227 95,22% 0 0 0 37 DMU15 1,034976 96,62% 0 0 0 22 DMU16 1,047215 95,49% 0 0 0 31 DMU17 1,039088 96,24% 0 0 0 25 DMU18 1,006395 99,36% 0 0 0,002541 6 DMU19 0,9911065 100,90% 0 0 0 1 DMU20 1,029561 97,13% 0 0,039837 0 17 DMU21 1,038741 96,27% 0 0,038297 0 24 DMU22 1,055009 94,79% 0 0 0 40 110
DMU23 1,056745 94,63% 0 0 0 42 DMU24 1,046678 95,54% 0 0,002328 0 30 DMU25 1,039855 96,17% 0 0 0 26 DMU26 1,058477 94,48% 0 0 0 45 DMU27 1,049704 95,26% 0 0 0 36 DMU28 1,016955 98,33% 0 0 0 10 DMU29 1,009234 99,09% 0 0 0,012916 8 DMU30 1,045230 95,67% 0 0 0 29 DMU31 1,050727 95,17% 0 0 0 38 DMU32 1,018281 98,20% 0 0 0 11 DMU33 1,048879 95,34% 0 0 0 34 DMU34 1,025801 97,48% 0 0,071909 0 15 DMU35 1,040176 96,14% 0 0,039510 0 27 DMU36 1,030193 97,07% 0 0 0 20 DMU37 1,024678 97,59% 0 0 0 14 DMU38 1,029931 97,09% 0 0 0 18 DMU39 1,027814 97,29% 0 0 0 16 DMU40 1,049543 95,28% 0 0 0 35 DMU41 1,033735 96,74% 0 0,016978 0 21 DMU42 1,048392 95,38% 0 0 0 33 DMU43 1,023412 97,71% 0 0 0 12 DMU44 1,008227 99,18% 0 0 0 7 DMU45 1,076660 92,88% 0 0 0 48 DMU46 1,057264 94,58% 0 0 0 43 DMU47 1,004175 99,58% 0 0 0 5 DMU48 0,9990332 100,10% 0 0 0,066192 2 Fonte: dados da pesquisa / 2019
Todas as formulações, resultados, ranqueamento e análise de sensibilidade podem ser encontrados no dataset público do Mendeley, referente ao modelo SMDEA11. Para uma demonstração de como o modelo SMDEA supera as formulações tradicionais de SDEA, com variáveis de razão, observe as Figuras 20 e 21. Note que na Figura 20 todas as DMUs estão próximas uma da outra dentro do PPS, devido à transformação logarítmica dos dados, e na Figura 21 apenas a DMU48 é supereficiente, sendo que as outras DMUs estão espalhadas dentro do PPS, porque a formulação original super-CCR DEA, com orientação à saída, não avalia com precisão as DMUs que estão operando acima ou abaixo de suas capacidades. De fato, é demonstrado que é necessário usar uma fronteira com convexidade geométrica, ao invés de uma convexidade padrão para alcançar uma estimativa de elasticidade de escala correta. Ainda na Figura 21, a DMU9 considerada como eficiente possui uma pequena Média_TCP (média da largura de banda do TCP), mostrando que
11Resultados do modelo orientado a saída SMDEA, disponíveis no dataset do Mendeley, podem ser encontrados na URL: https://data.mendeley.com/datasets/yj24sgch7m/3 111 essa fronteira de eficiência apresenta uma fronteira incorreta que precisa ser retificada pelo modelo SMDEA. Esses e outros gráficos podem ser encontrados no conjunto de dados públicos do Mendeley, já mencionado. Em suma, os destaques da avaliação SMDEA são, respectivamente, o hipervisor tipo-II VMware e a ferramenta baseada em contêiner LXC. Estas aplicações estavam presentes em 2/3 das DMUs supereficientes (SE) do TOP3, apontadas como soluções ótimas para resolver o problema da AS com LRD no tráfego TCP em redes virtuais. Os destaques dos SOs foram o Fedora 24, Ubuntu 16 e Arch 12. Porém, é obrigatório selecionar apenas o conjunto de ferramentas do TOP1 da DMU supereficiente, ou seja, o hipervisor de rede ótimo, não um aplicativo isolado (ou SO, ou hipervisor, ou contêiner e assim por diante). No entanto, se o administrador da rede virtual escolher a DMU ranqueada como a mais eficiente para executar seus aplicativos/serviços e, assim, o tomador de decisão garantirá serviços TCP mais estáveis e com desempenho superior da largura de banda para seus clientes em uma escala de tempo de longo prazo.
Figura 20: Fronteira de eficiência e PPS do Modelo CCR com orientação às saídas
Fonte:https://data.mendeley.com/datasets/yj24sgch7m/3
112
Figura 21: Fronteira de eficiência e PPS do Modelo SMDEA com orientação às saídas
Fonte: https://data.mendeley.com/datasets/yj24sgch7m/3
5.1.3 Modelo de Janela Multiplicativo com CRS
As Tabelas 15 e 16 mostram apenas alguns resultados das medições usando TCP nas redes virtuais na topologia GGC com 50 DMUs, que foram avaliadas em 10 séries temporais diferentes e independentes, ou seja, as 10 repetições usadas na avaliação das DMUs pelo modelo SMDEA na subseção anterior. Cada linha das Tabelas 15 e 16 foi considerada como uma DMU, ou seja, um conjunto separado de ferramentas para fornecer serviços de rede virtual. Além disso, os resultados também são ordenados alfabeticamente. Por economia de espaço, apenas a primeira e a última série temporal são exibidas nas Tabelas 15 e 16. Os dados e resultados completos podem ser acessados no dataset público, na plataforma Mendeley, do modelo WMDEA12. As Tabelas 15 e 16 devem ser apresentadas completas, porque é obrigatório fazer a análise fractal do maior conjunto de hipervisores de rede, quanto for possível. Portanto, estas medições são o reflexo apenas das redes virtuais montadas no hardware que foi usado para experimentação. Isso quer dizer que se mudar ou o hardware, ou mesmo qualquer uma das versões das ferramentas para montar um hipervisor de rede, os resultados serão diferentes. Assim, deve-se avaliar o maior
12Modelo de Janela Multiplicativo (Windows Multiplicative DEA) – Dataset dos resultados com comparação do modelo de Janela Multiplicativo DEA versus tradicional modelo de Análise em Janela DEA com análise de sensibilidade estão disponíveis na URL: DOI:10.17632/776sjbz7z5.5. 113 número de cenários para montar redes virtuais, segundo os protocolos que serão usados para fornecer um serviço na nuvem ou nestes ambientes virtualizados. Conforme mostrado nas Tabelas 15 e 16, os nomes das DMUs seguem o mesmo padrão das Tabelas 12 e 13. Assim, inicialmente, é apresentada a distribuição do Linux usada, além de sua ferramenta de hipervisor tipo-II, com sua interface emulada de rede (se existir) e, finalmente, a ferramenta baseada em contêiner utilizada nas medições. Como o modelo WMDEA faz parte de uma metodologia de avaliação fractal passo a passo por etapas, logo foram excluídas algumas variáveis ao longo da pesquisa como, por exemplo, as variâncias e os diferentes índices de dimensão fractal. Observe nas Tabelas 15 e 16 que todas as DMUs têm dimensão fractal, desempenho da largura de banda do TCP e memória (H) diferentes ao longo do tempo. Portanto, se o administrador da rede alterar apenas um conjunto de ferramentas, seu desempenho da largura de banda do TCP, dimensão e memória poderão aumentar, ou diminuir com o tempo. Esta conclusão lança uma nova abordagem para avaliar o tráfego TCP em redes virtuais, em relação à análise da estrutura fractal, em que é necessário predizer o melhor padrão fractal comparando diversas séries temporais, independentes entres si, de cada uma das unidades em análise, gerando um problema multicritério, que trata as DMUs em diferentes janelas de tempo para um ranqueamento ainda mais acurado. Para fins de compreensão, considere na Tabela 15 que a configuração com a maior média de largura de banda do TCP (DMU19) tem um desempenho da largura de banda do TCP 518.47% superior à que possui menor largura de banda (DMU42) dentre todas as configurações.
Tabela 15 - Série temporal 1 de 10 da avaliação de desempenho fractal nas redes virtuais SÉRIE TEMPORAL 1 (INPUT) (OUTPUT) (OUTPUT) Dimensão Média Hurst # Descrição completa do hipervisor de rede /DMU Fractal TCP em kbps 1 ARCH12 – VIRTUALBOX – PCNet PCI – DOCKER – GGC 1,785209 40130,15 0,6183077 ARCH12 – VIRTUALBOX – PCNet FAST – DOCKER – 1,433192 38563,87 0,5827894 2 GGC ARCH12 – VIRTUALBOX – PRO 1000 MT DESKTOP – 3 DOCKER – GGC 1,661116 48895,95 0,7726983 ARCH12 – VIRTUALBOX – PRO 1000 T SERVER – 4 DOCKER – GGC 1,421768 61124,30 0,547809 5 ARCH12 – VIRTUALBOX – PCNet PCI – LXC – GGC 1,5399 43250,30 0,6675938 6 ARCH12 – VIRTUALBOX – PCNet FAST – LXC – GGC 1,793746 50667,15 0,6319927 ARCH12 – VIRTUALBOX – PRO 1000 MT DESKTOP – 7 LXC – GGC 1,63196 117504,8 0,651435 114
ARCH12 – VIRTUALBOX – PRO 1000 T SERVER – LXC – 8 GGC 1,730482 125510,0 0,589394 9 ARCH12 – VMWARE – DOCKER – GGC 1,253107 38543,98 0,6082866 10 ARCH12 – VMWARE – LXC – GGC 1,251156 45294,92 0,7683398 FEDORA24 – VIRTUALBOX – PCNet PCI – DOCKER – 11 GGC 1,62871 54551,93 0,5367957 FEDORA24 – VIRTUALBOX – PCNet FAST – DOCKER – 12 GGC 2,000000 56601,18 0,4353884 FEDORA24 – VIRTUALBOX – PRO 1000 MT DESKTOP – 13 DOCKER – GGC 1,902914 140952,8 0,5034535 FEDORA24 – VIRTUALBOX – PRO 1000 T SERVER – 14 DOCKER – GGC 1,685922 125431,2 0,5479436 15 FEDORA24 – VIRTUALBOX – PCNet PCI – LXC – GGC 1,832019 44044,10 0,7534088 16 FEDORA24 – VIRTUALBOX – PCNet FAST – LXC – GGC 1,570973 55193,28 0,55449 FEDORA24 – VIRTUALBOX – PRO 1000 MT DESKTOP – 17 LXC – GGC 1,947529 138655,8 0,4322091 FEDORA24 – VIRTUALBOX – PRO 1000 T SERVER – LXC 18 – GGC 1,686683 104569,0 0,5835325 19 FEDORA24 – VMWARE – DOCKER – GGC 1,506438 231164,1 0,7329962 20 FEDORA24 – VMWARE – LXC – GGC 1,412505 206155,7 0,5759402 OPENSUSE42.2 – VIRTUALBOX – PCNet PCI – DOCKER 21 – GGC 1,626723 47673,52 0,6713221 OPENSUSE42.2 – VIRTUALBOX – PCNet FAST – 22 DOCKER – GGC 1,837157 40177,47 0,620998 OPENSUSE42.2 – VIRTUALBOX – PRO 1000 MT 23 DESKTOP – DOCKER – GGC 1,735738 143066,2 0,5398554 OPENSUSE42.2 – VIRTUALBOX – PRO 1000 T SERVER – 24 DOCKER – GGC 1,76282 110523,1 0,5563244 OPENSUSE42.2 – VIRTUALBOX – PCNet PCI – LXC – 25 GGC 1,713208 44282,12 0,6401471 OPENSUSE42.2 – VIRTUALBOX – PCNet FAST – LXC – 26 GGC 1,400178 47227,53 0,7249415 OPENSUSE42.2 – VIRTUALBOX – PRO 1000 MT 27 DESKTOP – LXC – GGC 1,916209 136452,1 0,5981887 OPENSUSE42.2 – VIRTUALBOX – PRO 1000 T SERVER – 28 LXC – GGC 1,516177 119193,4 0,5418862 29 OPENSUSE42.2 – VMWARE – DOCKER – GGC 1,422791 78763,75 0,5508929 30 OPENSUSE42.2 – VMWARE – LXC – GGC 1,732926 209598,3 0,5778727 UBUNTU14 – VIRTUALBOX – PCNet PCI – DOCKER – 31 GGC 1,614789 40339,02 0,6057512 UBUNTU14 – VIRTUALBOX – PCNet FAST – DOCKER – 32 GGC 1,808033 42718,55 0,7461761 UBUNTU14 – VIRTUALBOX – PRO 1000 MT DESKTOP – 33 DOCKER – GGC 1,652687 139935,0 0,5463445 UBUNTU14 – VIRTUALBOX – PRO 1000 T SERVER – 34 DOCKER – GGC 2,000000 94764,83 0,6809666 35 UBUNTU14 – VIRTUALBOX – PCNet PCI – LXC – GGC 1,372066 43070,47 0,6899069 36 UBUNTU14 – VIRTUALBOX – PCNet FAST – LXC – GGC 1,84254 44271,33 0,6012703 UBUNTU14 – VIRTUALBOX – PRO 1000 MT DESKTOP – 37 LXC – GGC 2,000000 135731,8 0,7624681 UBUNTU14 – VIRTUALBOX – PRO 1000 T SERVER – LXC 38 – GGC 1,905901 91079,55 0,6279829 39 UBUNTU14 – VMWARE – DOCKER – GGC 1,463917 75191,63 0,6818153 40 UBUNTU14 – VMWARE – LXC – GGC 1,613873 108825,8 0,6693658 UBUNTU16 – VIRTUALBOX – PCNet PCI – DOCKER – 41 GGC 1,733046 45606,92 0,6231167 UBUNTU16 – VIRTUALBOX – PCNet FAST – DOCKER – 42 GGC 1,788994 37376,77 0,4993106 115
UBUNTU16 – VIRTUALBOX – PRO 1000 MT DESKTOP – 43 DOCKER – GGC 2,000000 140416,3 0,4966934 UBUNTU16 – VIRTUALBOX – PRO 1000 T SERVER – 44 DOCKER – GGC 1,745759 124744,5 0,611291 45 UBUNTU16 – VIRTUALBOX – PCNet PCI – LXC – GGC 1,567779 63122,28 0,6886994 46 UBUNTU16 – VIRTUALBOX – PCNet FAST – LXC – GGC 1,422496 61896,33 0,6145179 UBUNTU16 – VIRTUALBOX – PRO 1000 MT DESKTOP – 47 LXC – GGC 2,000000 133828,1 0,6155002 UBUNTU16 – VIRTUALBOX – PRO 1000 T SERVER – LXC 48 – GGC 1,741076 125823,1 0,5863453 49 UBUNTU16 – VMWARE – DOCKER – GGC 2,000000 153872,8 0,7219129 50 UBUNTU16 – VMWARE – LXC – GGC 1,259653 213151,1 0,6522807
Fonte: dados da pesquisa/2019
Veja nas Tabelas 15 e 16 que alguns valores estão em vermelho quando , apresentando o efeito de Noé, ou seja, são fatos isolados que dificilmente acontecem. Portanto, essas DMUs apresentam uma dependência de curto alcance (short-range dependency (SRD)) ao longo do tempo. Todavia, DMUs com SRD poderiam ser retiradas da avaliação, mas para que estas DMUs não causem um desequilíbrio nas matrizes de entrada-saída, usadas no cálculo no modelo WMDEA, as DMUS que apresentam variáveis SRD também devem ser consideradas na avaliação. Além disso, como o modelo multiplicativo DEA intertemporal proposto visa automaticamente às DMUs com maiores valores de H, logo, por mais esta razão, as DMUs com SRD devem ser mantidas.
Tabela 16 - Série temporal 10 de 10 da avaliação de desempenho fractal nas redes virtuais SÉRIE TEMPORAL 10 (INPUT) (OUTPUT) (OUTPUT) Dimensão Média Hurst # Descrição completa do hipervisor de rede /DMU Fractal TCP em kbps 1 ARCH12 – VIRTUALBOX – PCNet PCI – DOCKER – GGC 1,874132 39820,07 0,5147301 ARCH12 – VIRTUALBOX – PCNet FAST – DOCKER – 1,561356 39022,27 0,6822004 2 GGC ARCH12 – VIRTUALBOX – PRO 1000 MT DESKTOP – 3 DOCKER – GGC 1,34878 49447,10 0,6837165 ARCH12 – VIRTUALBOX – PRO 1000 T SERVER – 4 DOCKER – GGC 1,551851 60248,58 0,6283762 5 ARCH12 – VIRTUALBOX – PCNet PCI – LXC – GGC 2,000000 45230,37 0,7551821 6 ARCH12 – VIRTUALBOX – PCNet FAST – LXC – GGC 1,624124 40399,67 0,6716724 ARCH12 – VIRTUALBOX – PRO 1000 MT DESKTOP – 7 LXC – GGC 1,765941 126680,00 0,4934648 ARCH12 – VIRTUALBOX – PRO 1000 T SERVER – LXC 8 – GGC 1,412594 65236,30 0,7393426 9 ARCH12 – VMWARE – DOCKER – GGC 1,395341 43181,63 0,7616619 10 ARCH12 – VMWARE – LXC – GGC 1,439252 49597,13 0,696772 FEDORA24 – VIRTUALBOX – PCNet PCI – DOCKER – 11 GGC 1,696643 56905,22 0,6030927 116
FEDORA24 – VIRTUALBOX – PCNet FAST – DOCKER – 12 GGC 1,734330 53544,65 0,5458348 FEDORA24 – VIRTUALBOX – PRO 1000 MT DESKTOP – 13 DOCKER – GGC 1,820041 140923,80 0,559229 FEDORA24 – VIRTUALBOX – PRO 1000 T SERVER – 14 DOCKER – GGC 1,651150 123265,80 0,5702495 15 FEDORA24 – VIRTUALBOX – PCNet PCI – LXC – GGC 1,741402 52742,78 0,5736909 16 FEDORA24 – VIRTUALBOX – PCNet FAST – LXC – GGC 1,468697 56279,52 0,5509028 FEDORA24 – VIRTUALBOX – PRO 1000 MT DESKTOP – 17 LXC – GGC 1,755400 138221,4 0,5633642 FEDORA24 – VIRTUALBOX – PRO 1000 T SERVER – 18 LXC – GGC 1,473790 129838,0 0,5306936 19 FEDORA24 – VMWARE – DOCKER – GGC 1,399664 208904,5 0,6114788 20 FEDORA24 – VMWARE – LXC – GGC 1,264375 295963,0 0,7102069 OPENSUSE42.2 – VIRTUALBOX – PCNet PCI – 21 DOCKER – GGC 1,639504 48031,82 0,6591689 OPENSUSE42.2 – VIRTUALBOX – PCNet FAST – 22 DOCKER – GGC 1,713966 39535,63 0,6484466 OPENSUSE42.2 – VIRTUALBOX – PRO 1000 MT 23 DESKTOP – DOCKER – GGC 1,864384 147263,8 0,5351587 OPENSUSE42.2 – VIRTUALBOX – PRO 1000 T SERVER 24 – DOCKER – GGC 1,821741 136428,8 0,6189044 OPENSUSE42.2 – VIRTUALBOX – PCNet PCI – LXC – 25 GGC 2,000000 38364,76 0,6526942 OPENSUSE42.2 – VIRTUALBOX – PCNet FAST – LXC – 26 GGC 1,724465 50379,95 0,6763286 OPENSUSE42.2 – VIRTUALBOX – PRO 1000 MT 27 DESKTOP – LXC – GGC 2,000000 133626,4 0,6396128 OPENSUSE42.2 – VIRTUALBOX – PRO 1000 T SERVER 28 – LXC – GGC 1,368765 105891,2 0,5738729 29 OPENSUSE42.2 – VMWARE – DOCKER – GGC 1,776797 78939,85 0,5726417 30 OPENSUSE42.2 – VMWARE – LXC – GGC 1,338175 222197,2 0,7378387 UBUNTU14 – VIRTUALBOX – PCNet PCI – DOCKER – 31 GGC 1,782305 40194,51 0,6970738 UBUNTU14 – VIRTUALBOX – PCNet FAST – DOCKER – 32 GGC 1,791108 40927,50 0,6635941 UBUNTU14 – VIRTUALBOX – PRO 1000 MT DESKTOP – 33 DOCKER – GGC 1,82119 138834,8 0,6510289 UBUNTU14 – VIRTUALBOX – PRO 1000 T SERVER – 34 DOCKER – GGC 1,973121 98211,78 0,6155717 35 UBUNTU14 – VIRTUALBOX – PCNet PCI – LXC – GGC 1,852894 40747,51 0,6635777 36 UBUNTU14 – VIRTUALBOX – PCNet FAST – LXC – GGC 1,801588 40284,15 0,6948283 UBUNTU14 – VIRTUALBOX – PRO 1000 MT DESKTOP – 37 LXC – GGC 1,840504 133292,0 0,6551226 UBUNTU14 – VIRTUALBOX – PRO 1000 T SERVER – 38 LXC – GGC 1,480778 94701,2 0,5423257 39 UBUNTU14 – VMWARE – DOCKER – GGC 1,493367 76047,93 0,6803698 40 UBUNTU14 – VMWARE – LXC – GGC 1,339931 110447,1 0,6646793 UBUNTU16 – VIRTUALBOX – PCNet PCI – DOCKER – 41 GGC 1,640841 43935,75 0,5564401 UBUNTU16 – VIRTUALBOX – PCNet FAST – DOCKER – 42 GGC 1,748226 44108,12 0,6057765 UBUNTU16 – VIRTUALBOX – PRO 1000 MT DESKTOP – 43 DOCKER – GGC 1,728400 140463,8 0,5984046 UBUNTU16 – VIRTUALBOX – PRO 1000 T SERVER – 44 DOCKER – GGC 1,773500 119848,0 0,6313183 45 UBUNTU16 – VIRTUALBOX – PCNet PCI – LXC – GGC 1,673387 58509,8 0,7924933 46 UBUNTU16 – VIRTUALBOX – PCNet FAST – LXC – GGC 1,598299 47367,53 0,7010329 117
UBUNTU16 – VIRTUALBOX – PRO 1000 MT DESKTOP – 47 LXC – GGC 1,600833 133921,9 0,4694506 UBUNTU16 – VIRTUALBOX – PRO 1000 T SERVER – 48 LXC – GGC 1,634944 112703,4 0,6007014 49 UBUNTU16 – VMWARE – DOCKER – GGC 1,319365 210437,2 0,6053503 50 UBUNTU16 – VMWARE – LXC – GGC 1,177439 233141,9 0,6147959
Fonte: dados da pesquisa/2019
Tal como mostrado na subseção anterior, como foi usado um modelo multiplicativo DEA, é necessário transformar as variáveis de entrada e saída, que estão em forma de razão, em uma base logarítmica. Portanto, foi seguida a mesma metodologia da subseção anterior em que, quando os números são pequenos, divide- se o valor por um pequeno valor infinitesimal para que o logaritmo calculado seja positivo. Por outro lado, quando o número for grande, como a média de largura de banda do TCP, logo se calcula apenas o seu logaritmo. A Tabela 17 apresenta a média dos escores de eficiência do modelo de janela multiplicativo DEA, por janela e por DMU, com uma variável de entrada (dimensão Fractal - madograma) e duas de saídas (média de largura de banda do TCP e parâmetro de Hurst), além do ranqueamento completo. O tamanho da janela é 5 (cinco) na qual existem 10 séries temporais com 6 janelas de avaliação (1-2-3-4-5, 2-3- 4-5-6, 3-4-5-6-7, 4-5- 6-7-8, 5-6-7-8-9 e 6-7-8-9-10) do comportamento fractal das redes virtuais, por DMU, ao longo do tempo.
Apenas as DMUs mais eficientes do TOP2 ( ) são destacadas na Tabela 17. As DMUs do TOP2 têm um desempenho bastante regular ao longo do tempo, mantendo a dimensão fractal próxima de um valor suave (D tende a ser 1), elevada média da largura de banda do TCP e grande memória fractal ao longo do tempo. Alternativamente, as piores configurações classificadas estão vinculadas às DMUs que apresentam efeito irregular da dimensão fractal (D tende a ser 2). Tabela 17 - Média dos escores de eficiência por janela e por DMU calculados usando o modelo de Janela Multiplicativo DEA Janela Média de Janela Janela Janela Janela Janela Classifi 6-7-8-9- Todas as 1-2-3-4-5 2-3-4-5-6 3-4-5-6-7 4-5-6-7-8 5-6-7-8-9 cação 10 Janelas
DMU1 0,954496 0,946824 0,942984 0,898177 0,894023 0,8902994 0,921134 47 DMU2 0,958680 0,951730 0,958573 0,905260 0,904784 0,9037211 0,930458 32 DMU3 0,980968 0,976533 0,973489 0,925730 0,922497 0,9223650 0,950264 13 DMU4 0,978003 0,972938 0,975764 0,929315 0,926084 0,9240278 0,951022 12 DMU5 0,959532 0,951675 0,958791 0,907572 0,906699 0,9048267 0,931516 29 118
DMU6 0,959381 0,955007 0,946710 0,901228 0,899835 0,9022974 0,927410 37 DMU7 0,960522 0,947696 0,945655 0,939210 0,936257 0,9319253 0,943544 21 DMU8 0,963555 0,955433 0,962335 0,937180 0,934294 0,9358558 0,948109 14 DMU9 0,989665 0,984524 0,982707 0,932784 0,931747 0,930963 0,958732 8 DMU10 0,979966 0,975082 0,980675 0,941167 0,940810 0,9399382 0,959606 6 DMU11 0,952795 0,946536 0,947675 0,907059 0,905001 0,9048826 0,927325 38 DMU12 0,938260 0,938721 0,942789 0,908218 0,906756 0,906512 0,923543 45 DMU13 0,944695 0,935219 0,933476 0,929286 0,922051 0,9227154 0,931240 31 DMU14 0,952582 0,944576 0,945237 0,932834 0,930109 0,9338343 0,939862 22 DMU15 0,958899 0,948022 0,945328 0,901344 0,899915 0,9007728 0,925714 42 DMU16 0,951453 0,936128 0,934123 0,896808 0,894995 0,8993484 0,918809 49 DMU17 0,939361 0,932928 0,931289 0,926109 0,914611 0,9166846 0,926831 40 DMU18 0,957930 0,947535 0,952728 0,936915 0,935792 0,9380123 0,944819 18 DMU19 0,988737 0,975089 0,974592 0,973160 0,965837 0,9649462 0,973727 3 DMU20 0,985124 0,977005 0,974475 0,975778 0,975115 0,9821107 0,978268 2 DMU21 0,957690 0,946603 0,946765 0,895078 0,894217 0,8996362 0,923331 46 DMU22 0,958995 0,958617 0,959228 0,905431 0,908637 0,9075044 0,933069 28 DMU23 0,941443 0,928988 0,928981 0,930754 0,923371 0,9257259 0,929877 33 DMU24 0,956345 0,950067 0,949763 0,930288 0,923499 0,9275634 0,939588 23 DMU25 0,947310 0,936434 0,935979 0,893295 0,893670 0,8918247 0,916419 50 DMU26 0,965295 0,951378 0,949994 0,903193 0,901748 0,9042729 0,929313 34 DMU27 0,946105 0,933338 0,926817 0,923977 0,916841 0,9184384 0,927586 36 DMU28 0,957731 0,946115 0,941909 0,930521 0,925745 0,9310937 0,938852 24 DMU29 0,967291 0,958951 0,962210 0,934596 0,929554 0,9282797 0,946813 16 DMU30 0,979469 0,976355 0,975988 0,974217 0,965749 0,9689723 0,973458 4 DMU31 0,954465 0,947831 0,952304 0,901650 0,904634 0,9011700 0,927009 39 DMU32 0,953181 0,943755 0,942488 0,895357 0,895099 0,895693 0,920929 48 DMU33 0,962709 0,950217 0,952493 0,943197 0,935008 0,9361267 0,946625 17 DMU34 0,960622 0,946249 0,939496 0,918438 0,917484 0,9170233 0,933219 27 DMU35 0,965146 0,952950 0,946694 0,916823 0,918339 0,9159457 0,935983 25 DMU36 0,950701 0,945107 0,949584 0,897748 0,904898 0,9049523 0,925498 43 DMU37 0,963617 0,950349 0,948586 0,937708 0,931875 0,9314938 0,943938 20 DMU38 0,977379 0,974382 0,973774 0,946452 0,943326 0,9377278 0,958840 7 DMU39 0,981940 0,975719 0,976363 0,936799 0,935306 0,9335654 0,956615 9 DMU40 0,970672 0,957584 0,954979 0,934689 0,927846 0,9368952 0,947111 15 DMU41 0,950654 0,945543 0,953678 0,906886 0,904344 0,9058429 0,927825 35 DMU42 0,954506 0,951234 0,947746 0,901493 0,898524 0,9007893 0,925715 41 DMU43 0,947424 0,936571 0,932621 0,927475 0,921349 0,9233247 0,931461 30 DMU44 0,958765 0,948618 0,949676 0,937874 0,935209 0,9353974 0,944257 19 DMU45 0,977922 0,971144 0,970336 0,932186 0,929738 0,9296238 0,951825 11 DMU46 0,983147 0,978672 0,978207 0,932933 0,928280 0,9244682 0,954285 10 DMU47 0,937231 0,920388 0,927090 0,924581 0,916661 0,9194039 0,924226 44 DMU48 0,953795 0,944461 0,943626 0,925870 0,922506 0,9238298 0,935681 26 DMU49 0,971140 0,961810 0,966762 0,970381 0,966616 0,9670905 0,967300 5 DMU50 0,995743 0,982883 0,980896 0,980889 0,969053 0,9711770 0,980107 1
Fonte: dados da pesquisa / 2019 119
Também é importante mostrar a diferença substancial entre o escore de eficiência de ambos os modelos orientados a saída, respectivamente o novo modelo de janela multiplicativo DEA e a formulação de análise em janela original da DEA. Para compreensão e tamanho, serão apresentadas apenas as pontuações de eficiência das
DMUs do TOP3 (DMU50, DMU20, e DMU19) e as duas piores unidades em análise
(DMU16 e DMU25) da Tabela 17. Assim, a Tabela 18 reflete os escores de eficiência do modelo de janela DEA original destas 5 DMUs selecionadas da Tabela 17, embora o ranqueamento das configurações seja bem diferente, no tocante aos resultados da fronteira de eficiência do modelo original de janela DEA versus a do WMDEA.
Tabela 18 - Cinco DMUs selecionadas para mostrar os resultados do modelo original de Janela DEA Eficiência Eficiência Eficiência Eficiência Eficiência Eficiência Média de Janela Janela Janela Janela Janela Janela todas as 1-2-3-4-5 2-3-4-5-6 3-4-5-6-7 4-5-6-7-8 5-6-7-8-9 6-7-8-9-10 Janelas DMU50 0,948434 0,815921 0,797499 0,797064 0,669838 0,6901776 0,786489 DMU20 0,831128 0,760373 0,737956 0,737586 0,728085 0,7991422 0,765712 DMU19 0,877658 0,747120 0,741333 0,721182 0,642681 0,6370103 0,727831 DMU16 0,559688 0,473719 0,459795 0,269869 0,263233 0,2798766 0,384364 DMU25 0,532888 0,467498 0,465257 0,265039 0,266925 0,2615000 0,376518
Fonte: dados da pesquisa / 2019
As tabelas 17 e 18 demonstram a superioridade dos resultados alcançados, relacionados ao novo modelo de janela multiplicativo DEA, comparados à formulação original de janela DEA. Considere na Tabela 19 a diferença percentual apenas entre as cinco DMUs selecionadas do modelo de janela multiplicativo DEA (Tabela 17) versus a formulação de janela original DEA (windows DEA (WDEA)) – na Tabela18.
É bastante comum em modelos multiplicativos DEA, que os escores de eficiência tenham valores próximos a 90% a 100% para todas as DMUs, devido à pequena diferença entre variáveis convertidas para base logarítmica. Em suma, a suposição radial nem sempre é adequada para calcular a eficiência técnica corretamente nos resultados, na qual é mandatório empregar um modelo não-radial, tal como os modelos multiplicativos DEA que são capazes de permitir que múltiplas variáveis de entrada e saída em forma de ratios reflitam uma correta proporcionalidade nos resultados.
120
Tabela 19 - Comparação percentual entre as DMUs selecionadas do modelo de janela multiplicativo DEA (Tabela 17) versus a formulação original de Janela DEA (Tabela 18)
Diferença em % Diferença em % Diferença em % Diferença em % Diferença em % Diferença em % Janela 1 Janela 2 Janela 3 Janela 4 Janela 5 Janela 6
DMU50 -4,7511429 -16,986964 -18,696863 -18,740685 -30,87702 -28,933899 DMU20 -15,632185 -22,173047 -24,271437 -24,410466 -25,33342 -18,630128 DMU19 -11,234443 -23,379264 -23,934021 -25,892788 -33,458625 -33,984892 DMU16 -41,175460 -49,395911 -50,777877 -69,907841 -70,588335 -68,880069 DMU25 -43,747245 -50,076775 -50,291927 -70,330191 -70,131600 -70,678093
Fonte: dados da pesquisa / 2019
Outra ferramenta importante para provar que o modelo WMDEA faz uma avaliação correta dos dados na presença de variáveis de razão é mostrando uma comparação entre o PPS e a fronteira de eficiência do modelo aqui proposto, em comparação com a formulação original do WDEA. As Figuras 22 e 23 ilustram a comparação apenas do PPS da primeira janela em análise para os dois modelos em avaliação. Na Figura 23, algumas DMUs estão próximas ou espalhadas ao longo da fronteira de eficiência, em vez da Figura 22, onde as DMUs estão próximas umas das outras no PPS. Ou seja, a formulação original do Windows DEA não trata adequadamente algumas DMUs que estão operando acima ou abaixo de suas capacidades (ver também Emrouznejad & Amin, (2009)). Observe que, na Figura 23, algumas DMUs consideradas eficientes têm uma pequena média TCP (TCP_AVG), o que significa que alguns desses resultados de eficiência trazem uma pontuação de eficiência incorreta que precisa ser corrigida pela formulação WMDEA. Assim, é necessário alterar a convexidade padrão da Figura 23, pela convexidade geométrica da Figura 22 para alcançar a justa convexidade das possibilidades de produção observadas. As Figuras 24 e 25 apresentam um raio ilimitado que surge na fronteira de eficiência de ambos os modelos dinâmicos DEA comparados. Além disso, devido aos axiomas multiplicativos, algumas DMUs nesta janela de avaliação (1-5) estão distantes do raio, como na Figura 25, ao invés da Figura 24 onde todas as DMUs estão próximas ao raio ilimitado devido à log-normalização. Esta característica é um reflexo da concavidade geométrica sobre o PPS multiplicativo. Como o número de DMUs sob avaliação em cada janela de análise é de 250, as Figuras 24 e 25 não apresentam os rótulos das DMUs desses gráficos. Em suma, outros gráficos do restante da comparação entre esses modelos dinâmicos de DEA 121 apresentam esses mesmos padrões e podem ser encontrados no conjunto de dados público do WMDEA já mencionado. Figura 22 - PPS do Modelo WMDEA
Fonte: dados da pesquisa / 2019
Figura 23 – Fronteira de eficiência e PPS do Modelo WDEA
Fonte: dados da pesquisa / 2019
122
Figura 24 – Fronteira de eficiência com raio ilimitado do Modelo WMDEA
Fonte: dados da pesquisa / 2019
Figura 25 – Fronteira de eficiência com raio ilimitado do Modelo WDEA
Fonte: dados da pesquisa / 2019
Considerando o ranqueamento do TOP5 em todas as janelas de avaliação do modelo WMDEA da Tabela 20, a DMU50 – destacada em negrito – foi eleita como a melhor configuração para fornecer serviços TCP em redes virtuais ao longo do tempo. Como pode ser visto na Tabela 20 – a DMU50 – é ranqueada quatro vezes como o primeiro lugar e duas vezes na segunda posição. Logo, o comportamento fractal da DMU50 está evidenciando sua superioridade na entrega de serviços TCP em redes virtuais em todas as janelas de avaliação. A DMU20, considerada como TOP2 em 123 todas as janelas, teve três segundas posições e dois quartos lugares na classificação da Tabela 20. Finalmente, a DMU19 ranqueada na terceira posição teve duas terceiras colocações, uma classificação como quarto e outra como quinto, em todas as janelas de avaliação. Portanto, o modelo WMDEA está sempre buscando predizer uma DMU que possua um pequeno valor para a dimensão fractal e que, ao mesmo tempo, tenha elevado desempenho da largura de banda do TCP com um grande valor do parâmetro de Hurst. Conclui-se que a formulação WMDEA faz a escolha certa ao selecionar a DMU50 como a solução deste problema de otimização de rede multicritério.
Tabela 20 - Ranqueamento das TOP5 DMUs segundo modelo WMDEA Todas Classificação Janela 1 Janela 2 Janela 3 Janela 4 Janela 5 Janela 6 janelas 1° DMU50 DMU9 DMU10 DMU50 DMU50 DMU50 DMU50 2° DMU9 DMU50 DMU50 DMU20 DMU20 DMU20 DMU20 3° DMU19 DMU46 DMU9 DMU30 DMU19 DMU30 DMU19 4° DMU20 DMU20 DMU46 DMU19 DMU49 DMU49 DMU30 5° DMU46 DMU3 DMU39 DMU49 DMU30 DMU19 DMU49
Fonte: dados da pesquisa / 2019
Resumindo, os destaques dos resultados do modelo de WMDEA são o hipervisor do tipo II VMWare e a ferramenta baseada em contêineres LXC respectivamente. Essas aplicações estão presentes em todas as TOP3 DMUs apontadas como soluções ótimas, para resolver este problema de otimização de rede no tráfego TCP em redes virtuais. Os destaques em relação ao SO são o Fedora 24 e o Ubuntu 16. Tal como explicitado na subseção anterior é mandatório selecionar apenas o conjunto de ferramentas da DMU que é a TOP1, como sendo o hipervisor de rede, não uma ferramenta isolada (ou SO, ou hipervisor, ou container, dentre outros). Portanto, se o administrador da rede virtual escolher a DMU melhor ranqueada para executar seus aplicativos/serviços usando o TCP, então a formulação de janela multiplicativa DEA concederá aos clientes um transporte de dados fim a fim mais eficiente, do ponto de vista fractal em redes virtuais, i.e., a rede proverá tráfego virtual com desempenho da largura de banda do TCP superior e tráfego mais suave (ou mais estável) em um longo período de tempo. Finalmente, esta tese propôs-se a desenvolver um framework da avaliação da estrutura fractal do tráfego TCP em redes virtuais, atuando como hipervisor matemático. Este introduz uma maneira analítica de ajustar estocasticamente o comportamento do TCP dos hipervisores de rede, visando aumentar o goodput e o 124 controle de fluxo do tráfego nas redes virtuais, que devem seguir o melhor padrão fractal – predito pelo framework – no encaminhando de serviços mais eficientes dos inquilinos ao longo do tempo. Ademais, o modelo WMDEA é o mais indicado, dentre os criados nesta tese para otimização do tráfego TCP nas redes virtuais.
5.2 Cenário 2 – Medições escaladas com hipervisores de Tipo-I
5.2.1 Caracterização do Problema
As medições deste cenário foram escaladas tendo resultados semelhantes relacionados ao padrão fractal do cenário anterior. No entanto, como são tiradas conclusões diferentes, relacionadas à forma de como são cobrados e avaliados os serviços em uma infrastrutura como serviço (infrastructure as a service (IaaS)) pelos provedores destes serviços, na computação em nuvem, então, faz-se necessário uma caracterização do problema antes da interpretação dos resultados. Os resultados obtidos aqui podem causar um forte impacto na contabilização dos serviços já pagos, sob demanda, pelos clientes de computação em nuvem, que foram servidos por provedores de serviços denominados de cloud service providers (CSP) nos últimos anos. Isso acontece porque todos os CSPs seguem o mesmo padrão de cobrança da indústria de hardware/PC, que cobra aos seus clientes com base na quantidade de algumas configurações como CPU (versão, clock e tipo), quantidade de RAM, armazenamento e outros. Vale ser ressaltado que neste trabalho serão apresentados apenas os três principais CSPs do mundo para efeito de comparação. O Amazon web services (AWS), considerado o principal provedor CSP do mundo, define seus preços por meio da quantidade de algumas métricas, relacionadas a uma instância ou VM, bem como do sistema operacional escolhido. Observe que cada configuração tem um custo distinto, determinado principalmente pela quantidade de cada configuração, SO escolhido e o continente, no qual o serviço será entregue. Veja a Figura 26 para observar um padrão simplificado de contabilidade de serviços de computação ou IaaS pela AWS. De acordo com as políticas de contabilização dos CSPs, se uma VM retiver uma quantidade superior de vCPU e/ou vRAM, logo o preço do serviço de computação daquela instância será maior. Portanto, da mesma maneira que a indústria de PCs tradicional vende seus produtos “físicos”. 125
Considere o trecho abaixo de General Purpose – Current Generation na Figura 26, vinculada pela especificação de um alias ou apelido por configuração em cada linha. Considere a instância t3.nano detendo preço mais baixo do que a t3.micro, e assim por diante. Este tipo de taxação se dá devido à forma de como os CSPs cobram seus clientes, em relação aos valores de algumas métricas, relacionadas aos recursos virtuais, sem considerar os gargalos da degradação da virtualização. Outro fato relevante levantado é que, ao se usar esta forma de contabilização, não são observadas as discrepâncias – causadas pela AS com LRD no tráfego TCP – no transporte dos serviços fornecidos por estas instâncias ao longo do tempo. Enfim, tanto o impacto da virtualização, quanto da AS com LRD devem ser avaliados, para efeito de contabilização e de análise de desempenho, nas redes virtuais dentro das IaaS. De fato, a totalidade dos CSPs segue esse mesmo padrão contábil apresentado.
Figura 26 - Preços do Amazon Elastic Cloud Computing (EC2)13
Fonte: Extraída da página de preços do AmazonElastic Cloud Computing (EC2)14
O Google Cloud15, o Microsoft Azure16 e muitos outros CSPs também cobram a seus clientes da mesma forma mostrada na Figura 26. Assim, em todos os CSPs, cada
13Amazon Web Services (AWS) – preços dos serviços de computação podem ser encontrados na URL: https://aws.amazon.com/ec2/pricing/on-demand/?nc1=h_ls 14Amazon Web Services (AWS) – preços dos serviços de computação podem ser encontrados na URL: https://aws.amazon.com/ec2/pricing/on-demand/?nc1=h_ls 15Google Cloud – preços dos serviços de computação podem ser encontrados na URL:https://cloud.google.com/compute/pricing 16Microsoft Azure Cloud – preços dos serviços de computação podem ser encontrados na URL: https://azure.microsoft.com/en-us/pricing/details/virtual-machines/linux/ 126 configuração tem um preço distinto, determinado principalmente por sua configuração, métricas, sistema operacional e continente onde o serviço é prestado. Antes de mencionar os impactos causados pelos resultados, é interessante introduzir o conceito de service-level agreement (SLA) na computação em nuvem. De acordo com Zhao et al. (2015), os SLAs são contratos declarativos entre duas partes – o contratante (inquilino) e o contratado (CSP) – que servem para estabelecer parâmetros na qualidade dos serviços (quality-of-services (QoS)), que os CSPs devem fornecer aos seus clientes. Por outro lado, se os termos acordados forem violados, o CSP poderá sofrer penalidades e vice-versa. Segundo Yeet al. (2012), a conta paga pelos clientes está fortemente relacionada aos SLAs. As métricas padrões dos SLAs podem ser vCPU, vRAM, largura de banda da rede, tempo de atividade do sistema (system uptime) e dependem do serviço a ser entregue. De acordo com o trabalho de Ye et al. (2012), uma auditoria de terceira parte (third party audit (TPA)) deve ser empregada para resolver o dilema de confiança entre ambas as partes do contrato, porque o CSP pode facilmente ocultar os detalhes dos SLAs, fornecendo menos recursos do que o acordado, aumentando seus lucros. Vale ressaltar que, em ambientes de computação em nuvem, todos os serviços dependem da rede para funcionar adequadamente. Então, os impactos no desempenho da rede em uma nuvem serão reverberados por todos os serviços na nuvem, pois esta carrega intrinsecamente a AS com LRD, atestando a importância desta tese.
5.2.2 Modelo Super-Cobb-Douglas orientado à entrada com CRS
Uma conclusão simples trazida pela caracterização do problema apresentada previamente é que quanto maior a quantidade combinada de vCPU e/ou vRAM, maior será o preço pago de uma instância, pelo seu uso dentro de uma IaaS pelos inquilinos. Então, de acordo com as principais regras contábeis destes provedores, o cliente pagará mais por uma VM, quando houver a necessidade de um desempenho maior. No entanto, este trabalho é capaz de atestar matematicamente que os TOP3 CSPs, e todos os demais CSPs, induzem os clientes ao erro, porque a quantidade de vCPU e/ou vRAM não está necessariamente relacionada ao aumento do desempenho de uma instância. Em contraste, deve ser pior, devido aos efeitos da virtualização e, principalmente, pelos efeitos da AS com LRD ao longo do tempo por instância. 127
Portanto, os CSPs deveriam apresentar aos seus clientes uma análise fractal por configuração ou instância, mostrando métricas relacionadas à dimensão fractal, média de largura de banda do TCP (ou outro protocolo de transporte) e a memória fractal, a fim de obedecerem aos contratos entre os inquilinos e os CSPs, que são chamados de SLAs. Destarte, os consumidores poderiam ser tributados de maneira mais justa. Isso acontece porque os serviços de tráfego de rede virtual são usados, obrigatoriamente, para o fornecimento de todos os outros tipos de serviços na nuvem. Portanto, de acordo com os resultados anteriormente apresentados neste capítulo, se um inquilino escolhesse uma instância com um padrão fractal considerado ruim, para carregar seu tráfego TCP, esse padrão estocástico seria tomado como um contágio para todo o ambiente virtual, degradando o desempenho dos serviços ofertados pelos clientes e pelo próprio CSP, pois este efeito pode reverberar-se dentro de uma IaaS, afetando os outros inquilinos, tal como um efeito dominó. Na Tabela 21 está a prova de conceito (proof-of-concept (PoC)), de como os CSPs deveriam fazer sua avaliação de desempenho, a fim de garantir os SLAs, aumentando assim a confiança entre as partes. Assim, a Tabela 21 exibe 288 configurações ou hipervisores de rede distintos, adquiridos por medições para obter o comportamento fractal do tráfego TCP ao longo do tempo. Apesar do tamanho da Tabela 21, ela deve ser exibida na íntegra para provar os conceitos levantados. Todos os resultados podem ser encontrados em nosso dataset público no Mendeley17, relativo ao modelo Super-Cobb-Douglas CCR, com orientação às entradas (CCR-I).
Tabela 21 - Análise de desempenho fractal por configuração/DMU em um hipervisor de tipo-I (OUTPUT) (INPUT) (OUTPUT) Média # Descrição completa do hipervisor de rede /DMU Dimensão Hurst TCP Fractal em kbps Fedora24 – ESXI 6.5 – GG – E1000 – 1vCPU – 1GB 1 VRAM 2,000000 599853,8 0,8622781 Fedora24 – ESXI 6.5 – GG – E1000 – 1vCPU – 2GB 2 VRAM 2,000000 552623,8 0,8444985 Fedora24 – ESXI 6.5 – GG – E1000 – 1vCPU – 4GB 3 VRAM 1,622085 378719,2 0,8634234 Fedora24 – ESXI 6.5 – GG – E1000 – 1vCPU – 8GB 4 VRAM 1,756555 443682,1 0,7890162 Fedora24 – ESXI 6.5 – GG – VMXNET3 – 1vCPU – 1GB 5 VRAM 1,365223 452180,4 0,7807921
17Dataset público no Mendeley do modelo Super-Cobb Douglas CCR-I – Todos os resultados do modelo Super-Cobb-Douglas CRS DEA versus o modelo tradicional Super-CCR-I DEA, com análise de sensibilidade, estão disponíveis na URL: http://dx.doi.org/10.17632/fx4rhhxrdm.2 128
Fedora24 – ESXI 6.5 – GG – VMXNET3 – 1vCPU – 2GB 6 VRAM 1,675527 508714,7 0,7482798 Fedora24 – ESXI 6.5 – GG – VMXNET3 – 1vCPU – 4GB 7 VRAM 1,409517 569266,3 0,7976480 Fedora24 – ESXI 6.5 – GG – VMXNET3 – 1vCPU – 8GB 8 VRAM 1,438168 558170,6 0,7777546 Fedora24 – ESXI 6.5 – GGC – E1000 – Docker – 1vCPU 9 – 1GB VRAM 1,840123 628785,1 0,8709777 Fedora24 – ESXI 6.5 – GGC – E1000 – Docker – 1vCPU 10 – 2GB VRAM 1,697673 600281,3 0,8508286 Fedora24 – ESXI 6.5 – GGC – E1000 – Docker – 1vCPU 11 – 4GB VRAM 1,968903 429422,9 0,7746587 Fedora24 – ESXI 6.5 – GGC – E1000 – Docker – 1vCPU 12 – 8GB VRAM 1,783634 446275,1 0,7784236 Fedora24 – ESXI 6.5 – GGC – E1000 – LXC – 1vCPU – 13 1GB VRAM 1,360472 491219,2 0,8705131 Fedora24 – ESXI 6.5 – GGC – E1000 – LXC – 1vCPU – 14 2GB VRAM 1,609192 492466,6 0,8461629 Fedora24 – ESXI 6.5 – GGC – E1000 – LXC – 1vCPU – 15 4GB VRAM 2,000000 425575,5 0,6675033 Fedora24 – ESXI 6.5 – GGC – E1000 – LXC – 1vCPU – 16 8GB VRAM 1,818638 417452,3 0,7830622 Fedora24 – ESXI 6.5 – GGC – VMXNET3 – Docker – 17 1vCPU – 1GB VRAM 1,607577 636331,4 0,8909964 Fedora24 – ESXI 6.5 – GGC – VMXNET3 – Docker – 18 1vCPU – 2GB VRAM 1,437804 498467,8 0,8364798 Fedora24 – ESXI 6.5 – GGC – VMXNET3 – Docker – 19 1vCPU – 4GB VRAM 1,285770 477547,8 0,8152481 Fedora24 – ESXI 6.5 – GGC – VMXNET3 – Docker – 20 1vCPU – 8GB VRAM 1,262214 479065,7 0,7643432 Fedora24 – ESXI 6.5 – GGC – VMXNET3 – LXC – 21 1vCPU – 1GB VRAM 1,257745 640995,4 0,8768186 Fedora24 – ESXI 6.5 – GGC – VMXNET3 – LXC – 22 1vCPU – 2GB VRAM 1,509386 661215,0 0,8906738 Fedora24 – ESXI 6.5 – GGC – VMXNET3 – LXC – 23 1vCPU – 4GB VRAM 1,616141 935506,1 0,8172886 Fedora24 – ESXI 6.5 – GGC – VMXNET3 – LXC – 24 1vCPU – 8GB VRAM 1,918494 861103,5 0,7375975 Fedora24 – ESXI 6.5 – GG – E1000 – 2vCPU – 1GB 25 VRAM 1,485484 515970,2 0,7694101 Fedora24 – ESXI 6.5 – GG – E1000 – 2vCPU – 2GB 26 VRAM 1,443181 382965,0 0,8180248 Fedora24 – ESXI 6.5 – GG – E1000 – 2vCPU – 4GB 27 VRAM 1,522681 311532,6 0,7329937 Fedora24 – ESXI 6.5 – GG – E1000 – 2vCPU – 8GB 28 VRAM 1,566613 374983,6 0,8276436 Fedora24 – ESXI 6.5 – GG – VMXNET3 – 2vCPU – 1GB 29 VRAM 1,486449 403025,7 0,7208605 Fedora24 – ESXI 6.5 – GG – VMXNET3 – 2vCPU – 2GB 30 VRAM 1,411010 411511,7 0,6908409 Fedora24 – ESXI 6.5 – GG – VMXNET3 – 2vCPU – 4GB 31 VRAM 1,459466 539570,5 0,7633838 Fedora24 – ESXI 6.5 – GG – VMXNET3 – 2vCPU – 8GB 32 VRAM 1,387182 435963,4 0,7628480 Fedora24 – ESXI 6.5 – GGC – E1000 – Docker – 2vCPU 33 – 1GB VRAM 1,792029 485511,4 0,7950194 Fedora24 – ESXI 6.5 – GGC – E1000 – Docker – 2vCPU 34 – 2GB VRAM 1,628248 430202,2 0,8568018 Fedora24 – ESXI 6.5 – GGC – E1000 – Docker – 2vCPU 35 – 4GB VRAM 1,541816 346917,3 0,7945423 Fedora24 – ESXI 6.5 – GGC – E1000 – Docker – 2vCPU 36 – 8GB VRAM 1,578113 299706,1 0,7706661 129
Fedora24 – ESXI 6.5 – GGC – E1000 – LXC – 2vCPU – 37 1GB VRAM 1,549422 405519,0 0,791399 Fedora24 – ESXI 6.5 – GGC – E1000 – LXC – 2vCPU – 38 2GB VRAM 1,411782 418872,5 0,8341241 Fedora24 – ESXI 6.5 – GGC – E1000 – LXC – 2vCPU – 39 4GB VRAM 1,488872 310712,1 0,7496859 Fedora24 – ESXI 6.5 – GGC – E1000 – LXC – 2vCPU – 40 8GB VRAM 1,506452 348354,7 0,7249664 Fedora24 – ESXI 6.5 – GGC – VMXNET3 – Docker – 41 2vCPU – 1GB VRAM 1,403958 451529,1 0,6976512 Fedora24 – ESXI 6.5 – GGC – VMXNET3 – Docker – 42 2vCPU – 2GB VRAM 1,409987 442127,5 0,6968825 Fedora24 – ESXI 6.5 – GGC – VMXNET3 – Docker – 43 2vCPU – 4GB VRAM 1,419054 477568,3 0,7415787 Fedora24 – ESXI 6.5 – GGC – VMXNET3 – Docker – 44 2vCPU – 8GB VRAM 1,783246 427622,8 0,7222347 Fedora24 – ESXI 6.5 – GGC – VMXNET3 – LXC – 45 2vCPU – 1GB VRAM 1,403804 442316,8 0,7746050 Fedora24 – ESXI 6.5 – GGC – VMXNET3 – LXC – 46 2vCPU – 2GB VRAM 1,226449 455011,4 0,6358840 Fedora24 – ESXI 6.5 – GGC – VMXNET3 – LXC – 47 2vCPU – 4GB VRAM 1,572290 407145,1 0,7476854 Fedora24 – ESXI 6.5 – GGC – VMXNET3 – LXC – 48 2vCPU – 8GB VRAM 1,245367 436264,7 0,7062761 Fedora24 – ESXI 6.5 – GG – E1000 – 4vCPU – 1GB 49 VRAM 1,458278 425370,2 0,6998240 Fedora24 – ESXI 6.5 – GG – E1000 – 4vCPU – 2GB 50 VRAM 1,376487 499410,6 0,7762305 Fedora24 – ESXI 6.5 – GG – E1000 – 4vCPU – 4GB 51 VRAM 1,779745 289627,6 0,8523676 Fedora24 – ESXI 6.5 – GG – E1000 – 4vCPU – 8GB 52 VRAM 1,657480 276064,4 0,6682717 Fedora24 – ESXI 6.5 – GG – VMXNET3 – 4vCPU – 1GB 53 VRAM 1,422384 465831,9 0,7962063 Fedora24 – ESXI 6.5 – GG – VMXNET3 – 4vCPU – 2GB 54 VRAM 1,455360 479651,0 0,8722649 Fedora24 – ESXI 6.5 – GG – VMXNET3 – 4vCPU – 4GB 55 VRAM 1,689595 385218,4 0,7032043 Fedora24 – ESXI 6.5 – GG – VMXNET3 – 4vCPU – 8GB 56 VRAM 1,368618 462923,8 0,7302491 Fedora24 – ESXI 6.5 – GGC – E1000 – Docker – 4vCPU 57 – 1GB VRAM 1,230158 448506,0 0,8181064 Fedora24 – ESXI 6.5 – GGC – E1000 – Docker – 4vCPU 58 – 2GB VRAM 1,449665 405719,0 0,8478713 Fedora24 – ESXI 6.5 – GGC – E1000 – Docker – 4vCPU 59 – 4GB VRAM 1,664947 318709,3 0,8380729 Fedora24 – ESXI 6.5 – GGC – E1000 – Docker – 4vCPU 60 – 8GB VRAM 1,785599 261258,5 0,7480820 Fedora24 – ESXI 6.5 – GGC – E1000 – LXC – 4vCPU – 61 1GB VRAM 1,494444 394071,5 0,7096968 Fedora24 – ESXI 6.5 – GGC – E1000 – LXC – 4vCPU – 62 2GB VRAM 1,444430 379117,1 0,6777392 Fedora24 – ESXI 6.5 – GGC – E1000 – LXC – 4vCPU – 63 4GB VRAM 1,655797 286919,1 0,7604456 Fedora24 – ESXI 6.5 – GGC – E1000 – LXC – 4vCPU – 64 8GB VRAM 1,674902 288057,7 0,7696611 Fedora24 – ESXI 6.5 – GGC – VMXNET3 – Docker – 65 4vCPU – 1GB VRAM 1,472849 432786,6 0,7275639 Fedora24 – ESXI 6.5 – GGC – VMXNET3 – Docker – 66 4vCPU – 2GB VRAM 1,605384 447222,2 0,7090799 Fedora24 – ESXI 6.5 – GGC – VMXNET3 – Docker – 67 4vCPU – 4GB VRAM 1,468304 449255,4 0,7355668 130
Fedora24 – ESXI 6.5 – GGC – VMXNET3 – Docker – 68 4vCPU – 8GB VRAM 1,545455 406211,7 0,7802759 Fedora24 – ESXI 6.5 – GGC – VMXNET3 – LXC – 69 4vCPU – 1GB VRAM 1,535351 440874,8 0,7129534 Fedora24 – ESXI 6.5 – GGC – VMXNET3 – LXC – 70 4vCPU – 2GB VRAM 1,688592 414138,0 0,8066114 Fedora24 – ESXI 6.5 – GGC – VMXNET3 – LXC – 71 4vCPU – 4GB VRAM 1,293277 429670,0 0,6944894 Fedora24 – ESXI 6.5 – GGC – VMXNET3 – LXC – 72 4vCPU – 8GB VRAM 1,551137 397174,9 0,7582603 Fedora24 – ESXI 6.5 – GG – E1000 – 8vCPU – 1GB 73 VRAM 1,365223 452180,4 0,7807921 Fedora24 – ESXI 6.5 – GG – E1000 – 8vCPU – 2GB 74 VRAM 1,458771 371508,2 0,7717239 Fedora24 – ESXI 6.5 – GG – E1000 – 8vCPU – 4GB 75 VRAM 2,000000 250177,0 0,7027693 Fedora24 – ESXI 6.5 – GG – E1000 – 8vCPU – 8GB 76 VRAM 1,745241 337380,6 0,7838119 Fedora24 – ESXI 6.5 – GG – VMXNET3 – 8vCPU – 1GB 77 VRAM 1,329774 395840,7 0,7418650 Fedora24 – ESXI 6.5 – GG – VMXNET3 – 8vCPU – 2GB 78 VRAM 1,631820 440009,5 0,8082909 Fedora24 – ESXI 6.5 – GG – VMXNET3 – 8vCPU – 4GB 79 VRAM 1,219203 385299,1 0,7535994 Fedora24 – ESXI 6.5 – GG – VMXNET3 – 8vCPU – 8GB 80 VRAM 1,450138 444293,5 0,8092235 Fedora24 – ESXI 6.5 – GGC – E1000 – Docker – 8vCPU 81 – 1GB VRAM 1,456891 412270,9 0,8124578 Fedora24 – ESXI 6.5 – GGC – E1000 – Docker – 8vCPU 82 – 2GB VRAM 1,405067 457014,6 0,7968377 Fedora24 – ESXI 6.5 – GGC – E1000 – Docker – 8vCPU 83 – 4GB VRAM 1,833553 280116,1 0,7839918 Fedora24 – ESXI 6.5 – GGC – E1000 – Docker – 8vCPU 84 – 8GB VRAM 1,857707 280218,9 0,7500630 Fedora24 – ESXI 6.5 – GGC – E1000 – LXC – 8vCPU – 85 1GB VRAM 1,284406 427035,2 0,8120693 Fedora24 – ESXI 6.5 – GGC – E1000 – LXC – 8vCPU – 86 2GB VRAM 1,496741 416308,1 0,7214540 Fedora24 – ESXI 6.5 – GGC – E1000 – LXC – 8vCPU – 87 4GB VRAM 1,824144 278586,0 0,7847654 Fedora24 – ESXI 6.5 – GGC – E1000 – LXC – 8vCPU – 88 8GB VRAM 1,656053 289698,0 0,7411744 Fedora24 – ESXI 6.5 – GGC – VMXNET3 – Docker – 89 8vCPU – 1GB VRAM 1,659138 429774,6 0,6842462 Fedora24 – ESXI 6.5 – GGC – VMXNET3 – Docker – 90 8vCPU – 2GB VRAM 1,517280 403013,1 0,8026025 Fedora24 – ESXI 6.5 – GGC – VMXNET3 – Docker – 91 8vCPU – 4GB VRAM 1,516983 402280,9 0,7983080 Fedora24 – ESXI 6.5 – GGC – VMXNET3 – Docker – 92 8vCPU – 8GB VRAM 1,394975 441589,8 0,7228633 Fedora24 – ESXI 6.5 – GGC – VMXNET3 – LXC – 93 8vCPU – 1GB VRAM 1,576571 423068,1 0,7303977 Fedora24 – ESXI 6.5 – GGC – VMXNET3 – LXC – 94 8vCPU – 2GB VRAM 1,751621 439579,5 0,7247823 Fedora24 – ESXI 6.5 – GGC – VMXNET3 – LXC – 95 8vCPU – 4GB VRAM 1,682733 426415,6 0,6500688 Fedora24 – ESXI 6.5 – GGC – VMXNET3 – LXC – 96 8vCPU – 8GB VRAM 1,536958 424408,5 0,7898316 Ubuntu14 – ESXI 6.5 – GG – E1000 – 1vCPU – 1GB 97 VRAM 2,000000 333994,0 0,7625156 Ubuntu14 – ESXI 6.5 – GG – E1000 – 1vCPU – 2GB 98 VRAM 2,000000 343746,3 0,7302295 131
Ubuntu14 – ESXI 6.5 – GG – E1000 – 1vCPU – 4GB 99 VRAM 1,937989 426081,6 0,7551634 Ubuntu14 – ESXI 6.5 – GG – E1000 – 1vCPU – 8GB 100 VRAM 1,641689 393441,6 0,7193429 Ubuntu14 – ESXI 6.5 – GG – VMXNET3 – 1vCPU – 1GB 101 VRAM 2,000000 640294,0 0,7884155 Ubuntu14 – ESXI 6.5 – GG – VMXNET3 – 1vCPU – 2GB 102 VRAM 1,744527 624790,9 0,8050647 Ubuntu14 – ESXI 6.5 – GG – VMXNET3 – 1vCPU – 4GB 103 VRAM 1,977501 558539,8 0,7616748 Ubuntu14 – ESXI 6.5 – GG – VMXNET3 – 1vCPU – 8GB 104 VRAM 2,000000 609119,0 0,8567471 Ubuntu14 – ESXI 6.5 – GGC – E1000 – Docker – 1vCPU 105 – 1GB VRAM 1,454607 524488,0 0,8831294 Ubuntu14 – ESXI 6.5 – GGC – E1000 – Docker – 1vCPU 106 – 2GB VRAM 1,553891 547644,7 0,8592403 Ubuntu14 – ESXI 6.5 – GGC – E1000 – Docker – 1vCPU 107 – 4GB VRAM 1,537467 474905,7 0,8367876 Ubuntu14 – ESXI 6.5 – GGC – E1000 – Docker – 1vCPU 108 – 8GB VRAM 1,442463 403203,4 0,7484581 Ubuntu14 – ESXI 6.5 – GGC – E1000 – LXC – 1vCPU – 109 1GB VRAM 1,467318 641751,9 0,7527090 Ubuntu14 – ESXI 6.5 – GGC – E1000 – LXC – 1vCPU – 110 2GB VRAM 1,670030 337219,0 0,8230709 Ubuntu14 – ESXI 6.5 – GGC – E1000 – LXC – 1vCPU – 111 4GB VRAM 1,483744 510419,8 0,6818728 Ubuntu14 – ESXI 6.5 – GGC – E1000 – LXC – 1vCPU – 112 8GB VRAM 1,426879 385591,6 0,7791948 Ubuntu14 – ESXI 6.5 – GGC – VMXNET3 – Docker – 113 1vCPU – 1GB VRAM 1,746334 798433,4 0,7986200 Ubuntu14 – ESXI 6.5 – GGC – VMXNET3 – Docker – 114 1vCPU – 2GB VRAM 1,257754 838487,4 0,8066167 Ubuntu14 – ESXI 6.5 – GGC – VMXNET3 – Docker – 115 1vCPU – 4GB VRAM 2,000000 851713,9 0,8401227 Ubuntu14 – ESXI 6.5 – GGC – VMXNET3 – Docker – 116 1vCPU – 8GB VRAM 2,000000 716357,7 0,8171992 Ubuntu14 – ESXI 6.5 – GGC – VMXNET3 – LXC – 117 1vCPU – 1GB VRAM 2,000000 670705,4 0,8537771 Ubuntu14 – ESXI 6.5 – GGC – VMXNET3 – LXC – 118 1vCPU – 2GB VRAM 1,587434 759658,3 0,7914099 Ubuntu14 – ESXI 6.5 – GGC – VMXNET3 – LXC – 119 1vCPU – 4GB VRAM 1,437616 732101,5 0,7897564 Ubuntu14 – ESXI 6.5 – GGC – VMXNET3 – LXC – 120 1vCPU – 8GB VRAM 1,403634 752139,8 0,7678688 Ubuntu14 – ESXI 6.5 – GG – E1000 – 2vCPU – 1GB 121 VRAM 1,952193 428972,5 0,8529678 Ubuntu14 – ESXI 6.5 – GG – E1000 – 2vCPU – 2GB 122 VRAM 1,955401 432585,2 0,8574674 Ubuntu14 – ESXI 6.5 – GG – E1000 – 2vCPU – 4GB 123 VRAM 1,614405 536136,3 0,6518181 Ubuntu14 – ESXI 6.5 – GG – E1000 – 2vCPU – 8GB 124 VRAM 1,511022 410030,8 0,5964899 Ubuntu14 – ESXI 6.5 – GG – VMXNET3 – 2vCPU – 1GB 125 VRAM 1,590424 592508,9 0,6944251 Ubuntu14 – ESXI 6.5 – GG – VMXNET3 – 2vCPU – 2GB 126 VRAM 1,704998 642657,9 0,7713142 Ubuntu14 – ESXI 6.5 – GG – VMXNET3 – 2vCPU – 4GB 127 VRAM 1,608345 500931,6 0,7091057 Ubuntu14 – ESXI 6.5 – GG – VMXNET3 – 2vCPU – 8GB 128 VRAM 1,796882 525931,8 0,7157065 Ubuntu14 – ESXI 6.5 – GGC – E1000 – Docker – 2vCPU 129 – 1GB VRAM 1,557212 556259,3 0,8157288 132
Ubuntu14 – ESXI 6.5 – GGC – E1000 – Docker – 2vCPU 130 – 2GB VRAM 1,544878 587359,6 0,7935915 Ubuntu14 – ESXI 6.5 – GGC – E1000 – Docker – 2vCPU 131 – 4GB VRAM 1,348463 465320,2 0,6502395 Ubuntu14 – ESXI 6.5 – GGC – E1000 – Docker – 2vCPU 132 – 8GB VRAM 1,395260 352702,4 0,6883132 Ubuntu14 – ESXI 6.5 – GGC – E1000 – LXC – 2vCPU – 133 1GB VRAM 1,474698 623234,4 0,7458058 Ubuntu14 – ESXI 6.5 – GGC – E1000 – LXC – 2vCPU – 134 2GB VRAM 1,467318 641751,9 0,7527090 Ubuntu14 – ESXI 6.5 – GGC – E1000 – LXC – 2vCPU – 135 4GB VRAM 1,439842 453155,7 0,7459557 Ubuntu14 – ESXI 6.5 – GGC – E1000 – LXC – 2vCPU – 136 8GB VRAM 1,433769 367611,0 0,7379024 Ubuntu14 – ESXI 6.5 – GGC – VMXNET3 – Docker – 137 2vCPU – 1GB VRAM 1,310416 619625,7 0,6653814 Ubuntu14 – ESXI 6.5 – GGC – VMXNET3 – Docker – 138 2vCPU – 2GB VRAM 1,780189 747678,5 0,7453575 Ubuntu14 – ESXI 6.5 – GGC – VMXNET3 – Docker – 139 2vCPU – 4GB VRAM 1,525461 637594,7 0,7804198 Ubuntu14 – ESXI 6.5 – GGC – VMXNET3 – Docker – 140 2vCPU – 8GB VRAM 1,156970 560505,1 0,7199373 Ubu2ntu14 – ESXI 6.5 – GGC – VMXNET3 – LXC – 141 2vCPU – 1GB VRAM 1,551960 759662,4 0,7518296 Ubuntu14 – ESXI 6.5 – GGC – VMXNET3 – LXC – 142 2vCPU – 2GB VRAM 1,569671 773151,0 0,7759469 Ubuntu14 – ESXI 6.5 – GGC – VMXNET3 – LXC – 143 2vCPU – 4GB VRAM 1,754581 747350,1 0,7107665 Ubuntu14 – ESXI 6.5 – GGC – VMXNET3 – LXC – 144 2vCPU – 8GB VRAM 1,235873 767953,8 0,7245085 Ubuntu14 – ESXI 6.5 – GG – E1000 – 4vCPU – 1GB 145 VRAM 1,724560 649317,1 0,6957200 Ubuntu14 – ESXI 6.5 – GG – E1000 – 4vCPU – 2GB 146 VRAM 2,000000 609253,6 0,7315251 Ubuntu14 – ESXI 6.5 – GG – E1000 – 4vCPU – 4GB 147 VRAM 1,510287 535719,2 0,5998924 Ubuntu14 – ESXI 6.5 – GG – E1000 – 4vCPU – 8GB 148 VRAM 1,736069 400618,5 0,6693752 Ubuntu14 – ESXI 6.5 – GG – VMXNET3 – 4vCPU – 1GB 149 VRAM 1,330236 561890,6 0,6780564 Ubuntu14 – ESXI 6.5 – GG – VMXNET3 – 4vCPU – 2GB 150 VRAM 2,000000 537840,8 0,8129834 Ubuntu14 – ESXI 6.5 – GG – VMXNET3 – 4vCPU – 4GB 151 VRAM 1,727527 444432,8 0,7102633 Ubuntu14 – ESXI 6.5 – GG – VMXNET3 – 4vCPU – 8GB 152 VRAM 1,558626 678604,5 0,7282200 Ubuntu14 – ESXI 6.5 – GGC – E1000 – Docker – 4vCPU 153 – 1GB VRAM 1,481934 631186,1 0,7381701 Ubuntu14 – ESXI 6.5 – GGC – E1000 – Docker – 4vCPU 154 – 2GB VRAM 1,403260 482996,1 0,8765232 Ubuntu14 – ESXI 6.5 – GGC – E1000 – Docker – 4vCPU 155 – 4GB VRAM 1,492757 467798,1 0,6473884 Ubuntu14 – ESXI 6.5 – GGC – E1000 – Docker – 4vCPU 156 – 8GB VRAM 1,387932 361447,6 0,6711729 Ubuntu14 – ESXI 6.5 – GGC – E1000 – LXC – 4vCPU – 157 1GB VRAM 1,677652 550528,3 0,8656485 Ubuntu14 – ESXI 6.5 – GGC – E1000 – LXC – 4vCPU – 158 2GB VRAM 1,798873 614595,3 0,6591862 Ubuntu14 – ESXI 6.5 – GGC – E1000 – LXC – 4vCPU – 159 4GB VRAM 1,455481 450311,1 0,6716860 Ubuntu14 – ESXI 6.5 – GGC – E1000 – LXC – 4vCPU – 160 8GB VRAM 1,420339 360090,0 0,7699698 133
Ubuntu14 – ESXI 6.5 – GGC – VMXNET3 – Docker – 161 4vCPU – 1GB VRAM 1,130110 560248,5 0,6720698 Ubuntu14 – ESXI 6.5 – GGC – VMXNET3 – Docker – 162 4vCPU – 2GB VRAM 1,394930 552112,3 0,8186685 Ubuntu14 – ESXI 6.5 – GGC – VMXNET3 – Docker – 163 4vCPU – 4GB VRAM 2,000000 716874,6 0,7991031 Ubuntu14 – ESXI 6.5 – GGC – VMXNET3 – Docker – 164 4vCPU – 8GB VRAM 1,695753 775605,4 0,7851360 Ubuntu14 – ESXI 6.5 – GGC – VMXNET3 – LXC – 165 4vCPU – 1GB VRAM 1,251505 637629,3 0,8663825 Ubuntu14 – ESXI 6.5 – GGC – VMXNET3 – LXC – 166 4vCPU – 2GB VRAM 1,363358 783457,3 0,7619633 Ubuntu14 – ESXI 6.5 – GGC – VMXNET3 – LXC – 167 4vCPU – 4GB VRAM 1,441216 696109,0 0,8057923 Ubuntu14 – ESXI 6.5 – GGC – VMXNET3 – LXC – 168 4vCPU – 8GB VRAM 1,906329 614511,2 0,7819088 Ubuntu14 – ESXI 6.5 – GG – E1000 – 8vCPU – 1GB 169 VRAM 2,000000 575121,4 0,8043073 Ubuntu14 – ESXI 6.5 – GG – E1000 – 8vCPU – 2GB 170 VRAM 2,000000 520065,3 0,7656403 Ubuntu14 – ESXI 6.5 – GG – E1000 – 8vCPU – 4GB 171 VRAM 1,715474 385955,4 0,8408575 Ubuntu14 – ESXI 6.5 – GG – E1000 – 8vCPU – 8GB 172 VRAM 1,747997 390441,4 0,7523469 Ubuntu14 – ESXI 6.5 – GG – VMXNET3 – 8vCPU – 1GB 173 VRAM 1,543767 653514,2 0,8224202 Ubuntu14 – ESXI 6.5 – GG – VMXNET3 – 8vCPU – 2GB 174 VRAM 2,000000 612047,9 0,7571618 Ubuntu14 – ESXI 6.5 – GG – VMXNET3 – 8vCPU – 4GB 175 VRAM 2,000000 539167,4 0,7813568 Ubuntu14 – ESXI 6.5 – GG – VMXNET3 – 8vCPU – 8GB 176 VRAM 2,000000 617712,5 0,7191582 Ubuntu14 – ESXI 6.5 – GGC – E1000 – Docker – 8vCPU 177 – 1GB VRAM 1,829002 632661,9 0,6725378 Ubuntu14 – ESXI 6.5 – GGC – E1000 – Docker – 8vCPU 178 – 2GB VRAM 1,629684 595054,1 0,7186075 Ubuntu14 – ESXI 6.5 – GGC – E1000 – Docker – 8vCPU 179 – 4GB VRAM 1,556820 454871,1 0,6456279 Ubuntu14 – ESXI 6.5 – GGC – E1000 – Docker – 8vCPU 180 – 8GB VRAM 1,463079 358197,0 0,6959901 Ubuntu14 – ESXI 6.5 – GGC – E1000 – LXC – 8vCPU – 181 1GB VRAM 1,432683 571847,4 0,8255561 Ubuntu14 – ESXI 6.5 – GGC – E1000 – LXC – 8vCPU – 182 2GB VRAM 1,552181 646815,2 0,7378247 Ubuntu14 – ESXI 6.5 – GGC – E1000 – LXC – 8vCPU – 183 4GB VRAM 1,550349 461865,3 0,6302724 Ubuntu14 – ESXI 6.5 – GGC – E1000 – LXC – 8vCPU – 184 8GB VRAM 1,354629 361891,4 0,6482105 Ubuntu14 – ESXI 6.5 – GGC – VMXNET3 – Docker – 185 8vCPU – 1GB VRAM 1,228386 499626,2 0,6874143 Ubuntu14 – ESXI 6.5 – GGC – VMXNET3 – Docker – 186 8vCPU – 2GB VRAM 1,469820 747628,7 0,8182165 Ubuntu14 – ESXI 6.5 – GGC – VMXNET3 – Docker – 187 8vCPU – 4GB VRAM 1,636667 646556,1 0,7782739 Ubuntu14 – ESXI 6.5 – GGC – VMXNET3 – Docker – 188 8vCPU – 8GB VRAM 1,542289 792295,8 0,7487437 Ubuntu14 – ESXI 6.5 – GGC – VMXNET3 – LXC – 189 8vCPU – 1GB VRAM 1,091241 517699,5 0,7192438 Ubuntu14 – ESXI 6.5 – GGC – VMXNET3 – LXC – 190 8vCPU – 2GB VRAM 1,521688 758626,6 0,8049834 Ubuntu14 – ESXI 6.5 – GGC – VMXNET3 – LXC – 191 8vCPU – 4GB VRAM 1,583087 626504,0 0,8238757 134
Ubuntu14 – ESXI 6.5 – GGC – VMXNET3 – LXC – 192 8vCPU – 8GB VRAM 1,230172 675724,3 0,7292515 Ubuntu16 – ESXI 6.5 – GG – E1000 – 1vCPU – 1GB 193 VRAM 2,000000 555775,7 0,8551706 Ubuntu16 – ESXI 6.5 – GG – E1000 – 1vCPU – 2GB 194 VRAM 2,000000 573305,2 0,8387462 Ubuntu16 – ESXI 6.5 – GG – E1000 – 1vCPU – 4GB 195 VRAM 1,958839 575014,6 0,7548844 Ubuntu16 – ESXI 6.5 – GG – E1000 – 1vCPU – 8GB 196 VRAM 1,851067 490751,9 0,5689861 Ubuntu16 – ESXI 6.5 – GG – VMXNET3 – 1vCPU – 1GB 197 VRAM 1,422542 590009,7 0,8630033 Ubuntu16 – ESXI 6.5 – GG – VMXNET3 – 1vCPU – 2GB 198 VRAM 1,434396 572231,4 0,8363349 Ubuntu16 – ESXI 6.5 – GG – VMXNET3 – 1vCPU – 4GB 199 VRAM 1,678138 744989,9 0,7882783 Ubuntu16 – ESXI 6.5 – GG – VMXNET3 – 1vCPU – 8GB 200 VRAM 1,532329 509282,5 0,7480315 Ubuntu16 – ESXI 6.5 – GGC – E1000 – Docker – 1vCPU 201 – 1GB VRAM 1,559614 409604,7 0,8197266 Ubuntu16 – ESXI 6.5 – GGC – E1000 – Docker – 1vCPU 202 – 2GB VRAM 2,000000 469378,9 0,7952643 Ubuntu16 – ESXI 6.5 – GGC – E1000 – Docker – 1vCPU 203 – 4GB VRAM 1,828886 612597,9 0,7929348 Ubuntu16 – ESXI 6.5 – GGC – E1000 – Docker – 1vCPU 204 – 8GB VRAM 1,829477 466342,0 0,8147619 Ubuntu16 – ESXI 6.5 – GGC – E1000 – LXC – 1vCPU – 205 1GB VRAM 1,433261 405306,2 0,7544088 Ubuntu16 – ESXI 6.5 – GGC – E1000 – LXC – 1vCPU – 206 2GB VRAM 1,938610 614948,9 0,8057393 Ubuntu16 – ESXI 6.5 – GGC – E1000 – LXC – 1vCPU – 207 4GB VRAM 1,936371 583595,4 0,7708489 Ubuntu16 – ESXI 6.5 – GGC – E1000 – LXC – 1vCPU – 208 8GB VRAM 1,824781 462689,2 0,7600294 Ubuntu16 – ESXI 6.5 – GGC – VMXNET3 – Docker – 209 1vCPU – 1GB VRAM 1,206699 481126,3 0,8043134 Ubuntu16 – ESXI 6.5 – GGC – VMXNET3 – Docker – 210 1vCPU – 2GB VRAM 1,814752 437047,4 0,6082218 Ubuntu16 – ESXI 6.5 – GGC – VMXNET3 – Docker – 211 1vCPU – 4GB VRAM 1,715322 855778,2 0,7275159 Ubuntu16 – ESXI 6.5 – GGC – VMXNET3 – Docker – 212 1vCPU – 8GB VRAM 1,582979 760062,3 0,8688238 Ubuntu16 – ESXI 6.5 – GGC – VMXNET3 – LXC – 213 1vCPU – 1GB VRAM 1,869314 433283,2 0,6042390 Ubuntu16 – ESXI 6.5 – GGC – VMXNET3 – LXC – 214 1vCPU – 2GB VRAM 1,506321 872721,0 0,8816679 Ubuntu16 – ESXI 6.5 – GGC – VMXNET3 – LXC – 215 1vCPU – 4GB VRAM 1,652274 987275,5 0,8756274 Ubuntu16 – ESXI 6.5 – GGC – VMXNET3 – LXC – 216 1vCPU – 8GB VRAM 1,526004 779287,4 0,8413546 Ubuntu16 – ESXI 6.5 – GG – E1000 – 2vCPU – 1GB 217 VRAM 2,000000 503720,9 0,7088196 Ubuntu16 – ESXI 6.5 – GG – E1000 – 2vCPU – 2GB 218 VRAM 1,829487 466616,2 0,7382315 Ubuntu16 – ESXI 6.5 – GG – E1000 – 2vCPU – 4GB 219 VRAM 1,576252 460480,7 0,6485018 Ubuntu16 – ESXI 6.5 – GG – E1000 – 2vCPU – 8GB 220 VRAM 1,520465 346982,8 0,6815449 Ubuntu16 – ESXI 6.5 – GG – VMXNET3 – 2vCPU – 1GB 221 VRAM 1,396286 605367,7 0,8008318 Ubuntu16 – ESXI 6.5 – GG – VMXNET3 – 2vCPU – 2GB 222 VRAM 1,335933 618258,7 0,7800006 135
Ubuntu16 – ESXI 6.5 – GG – VMXNET3 – 2vCPU – 4GB 223 VRAM 1,39231 453631,3 0,8350838 Ubuntu16 – ESXI 6.5 – GG – VMXNET3 – 2vCPU – 8GB 224 VRAM 1,479294 543286,5 0,8036644 Ubuntu16 – ESXI 6.5 – GGC – E1000 – Docker – 2vCPU 225 – 1GB VRAM 1,49999 452301,4 0,6844687 Ubuntu16 – ESXI 6.5 – GGC – E1000 – Docker – 2vCPU 226 – 2GB VRAM 1,664167 502936,3 0,8057091 Ubuntu16 – ESXI 6.5 – GGC – E1000 – Docker – 2vCPU 227 – 4GB VRAM 1,627195 467026,3 0,5858719 Ubuntu16 – ESXI 6.5 – GGC – E1000 – Docker – 2vCPU 228 – 8GB VRAM 1,486964 328310,7 0,7026058 Ubuntu16 – ESXI 6.5 – GGC – E1000 – LXC – 2vCPU – 229 1GB VRAM 1,416631 451003,5 0,6879283 Ubuntu16 – ESXI 6.5 – GGC – E1000 – LXC – 2vCPU – 230 2GB VRAM 1,565078 512124,0 0,7717764 Ubuntu16 – ESXI 6.5 – GGC – E1000 – LXC – 2vCPU – 231 4GB VRAM 1,670987 444981,5 0,7155903 Ubuntu16 – ESXI 6.5 – GGC – E1000 – LXC – 2vCPU – 232 8GB VRAM 1,479527 329733,1 0,7108144 Ubuntu16 – ESXI 6.5 – GGC – VMXNET3 – Docker – 233 2vCPU – 1GB VRAM 1,345684 453946,6 0,7235741 Ubuntu16 – ESXI 6.5 – GGC – VMXNET3 – Docker – 234 2vCPU – 2GB VRAM 1,388865 472966,7 0,7047518 Ubuntu16 – ESXI 6.5 – GGC – VMXNET3 – Docker – 235 2vCPU – 4GB VRAM 1,513423 487230,5 0,6832894 Ubuntu16 – ESXI 6.5 – GGC – VMXNET3 – Docker – 236 2vCPU – 8GB VRAM 1,343832 550754,5 0,6993785 Ubuntu16 – ESXI 6.5 – GGC – VMXNET3 – LXC – 237 2vCPU – 1GB VRAM 1,588891 497351,9 0,7415298 Ubuntu16 – ESXI 6.5 – GGC – VMXNET3 – LXC – 238 2vCPU – 2GB VRAM 1,374191 478348,3 0,6742153 Ubuntu16 – ESXI 6.5 – GGC – VMXNET3 – LXC – 239 2vCPU – 4GB VRAM 1,419322 458098,5 0,6632547 Ubuntu16 – ESXI 6.5 – GGC – VMXNET3 – LXC – 240 2vCPU – 8GB VRAM 1,256305 521930,0 0,7025298 Ubuntu16 – ESXI 6.5 – GG – E1000 – 4vCPU – 1GB 241 VRAM 2,000000 453271,1 0,7853073 Ubuntu16 – ESXI 6.5 – GG – E1000 – 4vCPU – 2GB 242 VRAM 1,791631 440895,2 0,7092681 Ubuntu16 – ESXI 6.5 – GG – E1000 – 4vCPU – 4GB 243 VRAM 1,484080 364857,3 0,6556718 Ubuntu16 – ESXI 6.5 – GG – E1000 – 4vCPU – 8GB 244 VRAM 1,554278 297297,4 0,7559630 Ubuntu16 – ESXI 6.5 – GG – VMXNET3 – 4vCPU – 1GB 245 VRAM 1,271094 515787,5 0,7868026 Ubuntu16 – ESXI 6.5 – GG – VMXNET3 – 4vCPU – 2GB 246 VRAM 1,689466 396526,4 0,6288369 Ubuntu16 – ESXI 6.5 – GG – VMXNET3 – 4vCPU – 4GB 247 VRAM 1,311647 458122,9 0,7445946 Ubuntu16 – ESXI 6.5 – GG – VMXNET3 – 4vCPU – 8GB 248 VRAM 1,333216 453781,1 0,7481359 Ubuntu16 – ESXI 6.5 – GGC – E1000 – Docker – 4vCPU 249 – 1GB VRAM 1,421408 434180,2 0,7099229 Ubuntu16 – ESXI 6.5 – GGC – E1000 – Docker – 4vCPU 250 – 2GB VRAM 1,368117 416611,0 0,6299195 Ubuntu16 – ESXI 6.5 – GGC – E1000 – Docker – 4vCPU 251 – 4GB VRAM 1,606874 367395,0 0,6953359 Ubuntu16 – ESXI 6.5 – GGC – E1000 – Docker – 4vCPU 252 – 8GB VRAM 1,546254 290198,5 0,6909892 Ubuntu16 – ESXI 6.5 – GGC – E1000 – LXC – 4vCPU – 253 1GB VRAM 1,386571 449452,5 0,662485 136
Ubuntu16 – ESXI 6.5 – GGC – E1000 – LXC – 4vCPU – 254 2GB VRAM 1,367240 462694,4 0,6596066 Ubuntu16 – ESXI 6.5 – GGC – E1000 – LXC – 4vCPU – 255 4GB VRAM 1,521256 359427,0 0,6343241 Ubuntu16 – ESXI 6.5 – GGC – E1000 – LXC – 4vCPU – 256 8GB VRAM 1,549522 273116,1 0,6454539 Ubuntu16 – ESXI 6.5 – GGC – VMXNET3 – Docker – 257 4vCPU – 1GB VRAM 1,300404 452678,9 0,6293906 Ubuntu16 – ESXI 6.5 – GGC – VMXNET3 – Docker – 258 4vCPU – 2GB VRAM 1,470835 428864,5 0,7223793 Ubuntu16 – ESXI 6.5 – GGC – VMXNET3 – Docker – 259 4vCPU – 4GB VRAM 1,444857 434308,3 0,7021769 Ubuntu16 – ESXI 6.5 – GGC – VMXNET3 – Docker – 260 4vCPU – 8GB VRAM 1,404679 448433,0 0,6570848 Ubuntu16 – ESXI 6.5 – GGC – VMXNET3 – LXC – 261 4vCPU – 1GB VRAM 1,507808 434241,6 0,6298639 Ubuntu16 – ESXI 6.5 – GGC – VMXNET3 – LXC – 262 4vCPU – 2GB VRAM 1,406243 453467,2 0,7672264 Ubuntu16 – ESXI 6.5 – GGC – VMXNET3 – LXC – 263 4vCPU – 4GB VRAM 1,361217 436079,2 0,6955308 Ubuntu16 – ESXI 6.5 – GGC – VMXNET3 – LXC – 264 4vCPU – 8GB VRAM 1,342008 448349,2 0,6324591 Ubuntu16 – ESXI 6.5 – GG – E1000 – 8vCPU – 1GB 265 VRAM 1,533190 434463,7 0,6918410 Ubuntu16 – ESXI 6.5 – GG – E1000 – 8vCPU – 2GB 266 VRAM 1,656214 436092,9 0,7532888 Ubuntu16 – ESXI 6.5 – GG – E1000 – 8vCPU – 4GB 267 VRAM 1,578733 367209,0 0,7565369 Ubuntu16 – ESXI 6.5 – GG – E1000 – 8vCPU – 8GB 268 VRAM 1,505511 288462,6 0,6834822 Ubuntu16 – ESXI 6.5 – GG – VMXNET3 – 8vCPU – 1GB 269 VRAM 1,438889 443237,9 0,6727544 Ubuntu16 – ESXI 6.5 – GG – VMXNET3 – 8vCPU – 2GB 270 VRAM 1,506176 499765,8 0,7603618 Ubuntu16 – ESXI 6.5 – GG – VMXNET3 – 8vCPU – 4GB 271 VRAM 1,237870 562034,4 0,7697965 Ubuntu16 – ESXI 6.5 – GG – VMXNET3 – 8vCPU – 8GB 272 VRAM 1,429207 481259,8 0,7363296 Ubuntu16 – ESXI 6.5 – GGC – E1000 – Docker – 8vCPU 273 – 1GB VRAM 1,293243 451301,1 0,6345809 Ubuntu16 – ESXI 6.5 – GGC – E1000 – Docker – 8vCPU 274 – 2GB VRAM 1,366808 457063,9 0,6262415 Ubuntu16 – ESXI 6.5 – GGC – E1000 – Docker – 8vCPU 275 – 4GB VRAM 1,478638 369815,1 0,7206657 Ubuntu16 – ESXI 6.5 – GGC – E1000 – Docker – 8vCPU 276 – 8GB VRAM 1,432171 285566,3 0,6762566 Ubuntu16 – ESXI 6.5 – GGC – E1000 – LXC – 8vCPU – 277 1GB VRAM 1,433515 437698,2 0,7218853 Ubuntu16 – ESXI 6.5 – GGC – E1000 – LXC – 8vCPU – 278 2GB VRAM 1,378472 430690,8 0,6996545 Ubuntu16 – ESXI 6.5 – GGC – E1000 – LXC – 8vCPU – 279 4GB VRAM 1,507085 365595,8 0,6737488 Ubuntu16 – ESXI 6.5 – GGC – E1000 – LXC – 8vCPU – 280 8GB VRAM 1,491149 278045,5 0,7125484 Ubuntu16 – ESXI 6.5 – GGC – VMXNET3 – Docker – 281 8vCPU – 1GB VRAM 1,374189 430092,9 0,7083250 Ubuntu16 – ESXI 6.5 – GGC – VMXNET3 – Docker – 282 8vCPU – 2GB VRAM 1,410146 424266,3 0,5691196 Ubuntu16 – ESXI 6.5 – GGC – VMXNET3 – Docker – 283 8vCPU – 4GB VRAM 1,352652 446975,4 0,7474979 Ubuntu16 – ESXI 6.5 – GGC – VMXNET3 – Docker – 284 8vCPU – 8GB VRAM 1,348383 431016,8 0,7430269 137
Ubuntu16 – ESXI 6.5 – GGC – VMXNET3 – LXC – 285 8vCPU – 1GB VRAM 1,428902 445508,9 0,6400232 Ubuntu16 – ESXI 6.5 – GGC – VMXNET3 – LXC – 286 8vCPU – 2GB VRAM 1,483192 433623,2 0,6183943 Ubuntu16 – ESXI 6.5 – GGC – VMXNET3 – LXC – 287 8vCPU – 4GB VRAM 1,451210 406667,3 0,7466697 Ubuntu16 – ESXI 6.5 – GGC – VMXNET3 – LXC – 288 8vCPU – 8GB VRAM 1,459691 451051,1 0,6228883
Fonte: disponível em http://dx.doi.org/10.17632/fx4rhhxrdm.2
Este trabalho está lançando outra descoberta importante, relacionada ao impacto da AS com o LRD nas redes virtuais que pode causar alterações na forma de como é avaliado o comportamento fractal, de forma escalada, em cada uma das configurações, usadas como hipervisor de rede para fornecimento de serviços usando o TCP. É importante notar que a diferença de desempenho da configuração com a média mais significativa da largura de banda do TCP – a DMU215 – é 294,630% maior, do que a configuração com menor largura de banda do TCP – a DMU75. Vale salientar, que esse padrão fractal, de valores distintos para todas variáveis de decisão, é mantido em todas as configurações virtuais avaliadas. Estas diferenças de desempenho das variáveis de decisão acerca do TCP, relacionadas a cada um dos hipervisores de rede, podem levantar questionamentos quanto aos erros de cálculos na contabilidade dos clientes dos CSPs, em que provavelmente esses inquilinos na nuvem foram cobrados de forma errada, certamente com valores mais altos, em relação aos serviços contratados aos CSPs. De fato, mesmo uma instância sendo considerada com desempenho superior por um CSP, esta poderá ter um pior comportamento fractal do tráfego TCP ao longo do tempo. Isto ocorre porque o desempenho de uma instância deve ser composto pela tríade dimensão fractal, média da largura de banda do TCP e memória fractal em um período de tempo. Portanto, o desempenho de uma instância não está relacionado apenas à combinação da quantidade de algumas métricas. Por exemplo, considere a DMU75 (Fedora24 - ESXi 6.5 - GG - E1000 – 8 vCPUs – 4 GB VRAM) e a DMU215 (Ubuntu16 - ESXi 6.5 - GGC - VMXNET3 - LXC – 1 vCPU – 4 GB VRAM). Assim, de acordo com as políticas contábeis dos CSPs, a DMU75 deve ter um preço maior, do que a DMU215, porque a DMU75 tem 8 vCPUs, contra 1 vCPU da DMU215, em que ambas as configurações possuem 4 GB de vRAM. Logo, todos os CSPs deveriam seguir essa abordagem de avaliação de desempenho baseada em fractais. 138
A proposta desta tese serve para fomentar uma política tributária mais justa, sugerindo uma retificação de contrato ou SLA que, ao mesmo tempo, seja fácil de auditar e avaliar, visto que as informações obtidas em séries temporais do tráfego TCP das infraestruturas das nuvens apontam que o comportamento da rede pode ser resumido nos três índices fractais supracitados. O fator mais importante a ser considerado é a dimensão fractal na qual um tráfego TCP mais suave ou estável é preferível a um mais irregular. Do ponto de vista matemático, o comportamento do tráfego TCP ao longo do tempo mais adequado é aquele em que a dimensão fractal tenha um tráfego TCP mais suave, com desempenho da largura de banda do TCP e memória fractal superiores, para fornecer um serviço de rede otimizado ao longo do tempo. Por isso, foi criado um modelo Cobb- Douglas DEA orientado à entrada, visando tanto minimizar a dimensão fractal, quanto maximizar a média da largura de banda do TCP e memória fractal, visto que este modelo DEA é também não-radial. No entanto, a configuração com maior média TCP na Tabela 21 (DMU23) não é adequada para fornecer serviços de transporte nas redes virtuais, pois tem largura de banda do TCP altamente irregular, relacionado ao seu valor de dimensão fractal. Então, é necessário empregar uma técnica MCDM, como DEA (BANKER et al., 1984; BANKER; MAINDIRATTA, 1986; CHARNES et al., 1978; CHARNES et al., 1984; EMROUZNEJAD; WITTE, 2010; EMROUZNEJAD; YANG, 2017), ou mesmo um conjunto híbrido das principais técnicas ao se misturar DEA com lógica Fuzzy, processo de hierarquia analítica (analytical hierarchy process (AHP)), dentreoutras combinações de estratégias (WHAIDUZZAMAN et al., 2014). O intuito do emprego destas várias técnicas de avaliação é prover alternativas para resolver o complexo problema de otimização multicritério nas redes virtuais. Depois de executar o modelo Super-Cobb-Douglas DEA orientado à entrada, as duas únicas configurações supereficientes, que têm folga zero, são a DMU114 e a DMU165, com escores de eficiência de 1,006526 e 1,004616 respectivamente, ou seja, são ideais para entregar serviços TCP nas redes virtuais ao longo do tempo. Devido à economia de espaço estes resultados e o ranqueamento deste modelo não serão apresentados aqui. Todavia, caso haja interesse na visualização dos resultados completos, deve-se acessar o dataset público do Mendeley, contendo uma comparação completa entre o modelo padrão super-CCR-I e o super-Cobb-Douglas DEA CCR-I. O dataset traz, além 139 das fronteiras de eficiência, gráficos do PPS e todo o processo de transformação de variáveis logarítmicas que é obrigatório nos modelos Cobb-Douglas da DEA. A DMU114 tem apenas 1 vCPU e 2 GB de vRAM e a DMU165 tem 4 vCPUs e 1 GB vRAM, ou seja, está comprovado que o desempenho de uma instância não está relacionado ao aumento da quantidade de algumas métricas. Assim sendo, é necessário empregar uma análise fractal da máxima quantidade de hipervisores de rede possíveis, a fim de avaliar o comportamento fractal do TCP nas DMUs ao longo do tempo, corretamente, para uma predição ainda mais acurada. As Figuras 27, 28 e 29 comparam o PPS dos modelos Super-Cobb-Douglas CCR-I versus odo Super-CCR-I. Portanto, a Figura 27 mostra como a transformação logarítmica das variáveis atinge uma normalização justa das variáveis de entrada e saída, com o intuito de alcançar a proporcionalidade, a convexidade, a elasticidade de escala e muitas outras vantagens da aplicação de uma fronteira de eficiência com formato de S (s-shaped). Em vez disso, na Figura 28, há uma dispersão das DMUs dentro do PSS, porque os modelos clássicos da DEA não estão preparados para avaliar corretamente as DMUs trabalhando acima ou abaixo de suas capacidades, então é obrigatório mudar a fronteira de eficiência padrão para uma na forma de S. Essa comparação entre os PPS também está disponível no dataset online mencionado anteriormente. Na Figura 29, mostra-se o aumento do poder discriminativo desta formulação Super-Cobb-Douglas CCR-I DEA que deixa longe da fronteira de eficiência as DMUs com mau comportamento fractal do TCP, ou seja, aquelas com alta irregularidade ou baixa média de largura de banda do TCP, ou menor memória fractal ou todos simultaneamente. De fato, o modelo Super-Cobb-Douglas CCR-I acomoda as DMUs, consideradas como as mais adequadas, próximas ou dentro da fronteira de eficiência. Considere os rótulos das DMUs ineficientes localizados no meio da Figura 29, respectivamente, DMU90 e DMU264, onde a DMU90 tem o valor de 1,51728 para o rodograma, sua média de largura de banda do TCP é de 403013,1kbps, e seu parâmetro de Hurst é igual a 0,8026025. Já os valores da DMU264 são respectivamente, 1,342008, 448349,2 kbps e 0,6324591. Este mesmo mau comportamento fractal é seguido pelas DMUs de número 24, 31, 52, 54, 201, etc.
140
Figura 27 - Super-Cobb-Douglas DEA CCR-I Figura 28 - Modelo Super-CCR-I DEA
Fonte: dados da pesquisa / 2019 Fonte: dados da pesquisa / 2019
Figura 29 - Super-Cobb-Douglas DEA CCR-I destacando DMUs (com rótulos).
Fonte: dados da pesquisa / 2019
Finalmente, como existe uma grande quantidade de inquilinos unicórnios (com valor de mercado acima de U$$ 1 bilhão), que consomem serviços fornecidos pelos provedores de serviços em nuvem, tal como Uber, DropBox, AirBnb, Booking, Spotify e muitos outros, esses poderiam pressionar os CSPs para que mudassem a maneira de tributar seus clientes, a fim de aumentar a confiança entre as partes. É importante ressaltar, que a Tabela 21 mostra apenas o impacto da virtualização e AS com LRD de um subconjunto de VMs avaliadas. Portanto, é altamente possível que o desempenho diminua muito mais na presença de múltiplos 141 inquilinos que consomem, simultaneamente, todos esses serviços de infraestrutura e rede em nuvem, oferecidos por cada uma VM ou um conjunto de VMs, nos ambientes de redes virtuais.
142
6 CONSIDERAÇÕES FINAIS
O último capítulo deste trabalho apresenta, nas considerações finais, os resultados relacionados aos objetivos iniciais da pesquisa, além das possibilidades para realização de trabalhos futuros, juntamente com a conclusão final do trabalho.
6.1 Conclusão e trabalhos futuros
A avaliação do desempenho das redes de computadores e sistemas computacionais é primordial para que se possa planejar como serão prestados os serviços mais eficientes a toda cadeia de clientes. É importante que estes serviços, após sintonizados matematicante, possam transportar os dados na L3 de forma mais rápida e estável, ao usar o TCP de forma mais justa. Logo, tal ajuste pode garantir a QoS e a qualidade de experiência (quality-of- experience (QoE)) nos serviços de transporte fim a fim ofertados aos usuários, ao mesmo tempo que atenda a requisitos CapEx e operation expenditure (OpEx), um trade-off entre os anseios dos clientes e provedores dos serviços. Este trabalho propôs-se a avaliar o tráfego TCP em ambientes de redes virtuais, em que se observou forte presença da AS. A presença deste contágio estocástico, de certo, impactará na qualidade do serviço prestado, pois a AS perdura numa LRD, fazendo com que tais serviços possam ser prestados de forma irregular. Esta irregularidade na prestação de serviços de transporte fim a fim se dará caso sejam escolhidas as configurações que perduram com este padrão fractal ruim do TCP, ao longo do tempo. Visando à prestação de serviços de transporte mais eficientes em redes virtuais, esta tese, também, utilizou-se de ferramentas mais leves de virtualização, no caso Docker e LXC, para montagem de roteadores virtuais. A finalidade de usar tais ferramentas era realizar uma avaliação de desempenho minuciosa de um conglomerado destas tecnologias de virtualização, em diversas topologias distintas, para formar redes virtuais diferentes a serem avaliadas como DMUs. Contudo, ao realizar a análise exploratória das variáveis aleatórias contínuas, captadas nas medições, observou-se que as FDPs que melhor se acomodavam a estas variáveis aleatórias eram de cauda pesada e que apresentavam padrão log- logístico ou semi-exponencial, que são padrões típicos da AS com LRD. Este trabalho desenvolveu um framework para avaliação de desempenho e predição, de acordo com a análise da estrutura fractal do tráfego TCP. Assim, esta 143 metodologia pode atuar como um sistema especialista de avaliação fractal, centrado em adquirir conhecimento, sobre o TCP, acerca da tríade dimensão fractal, média da largura de banda do TCP e memória fractal. Seu objetivo é predizer qual o melhor hipervisor de rede ou DMU na montagem de uma rede virtual ótima. Ademais, a eleição da configuração virtual mais eficiente, segundo os modelos multiplicativos DEA e as variáveis em análise, é uma premissa para se prestar serviços de transporte em redes virtuais que, ao mesmo tempo, tenham tráfego TCP estável, com desempenho superior da largura de banda e com maior memória fractal em uma larga escala de tempo. Foram avaliados dois cenários distintos: a) o primeiro com medições em hipervisores de tipo-II e com VMs com 1 GB de vRAM e apenas 1 vCPU; e, b) o segundo com medições escaladas em um hipervisor de tipo-I nas quais as VMs variavam a quantidade de vRAM (1, 2, 4 e 8 GB) e vCPU (1, 2, 4 e 8). Em ambos os cenários, usou-se a ferramenta de benchmark iperf para avaliar a quantidade máxima de tráfego TCP que duas VMs poderiam trocar, em um período de tempo de 600 segundos, por hipervisor de rede que foram avaliados como DMUs. Após as medições e tratamento dos dados obtidos, era necessário o emprego de uma técnica MCDM para uma tomada de decisão mais efetiva. Logo, para cada um dos cenários, foram desenvolvidos modelos multiplicativos DEA a fim de selecionar dentre o conjunto de hipervisores de rede avaliados qual o que possuía a melhor combinação linear das variáveis fractais comparadas. Foram criados modelos multiplicativos ou de Cobb-Douglas DEA, visto que os modelos tradicionais da DEA geram escores de eficiência errados quando as variáveis de entrada e saída estão em forma de proporção ou razão (ratio). Modelos tradicionais da DEA violam os axiomas da proporcionalidade, convexidade, extrapolação mínima, raio ilimitado, dentre outros, ao usar variáveis em forma de ratio. Portanto, como neste trabalho todas as variáveis estão em forma de ratio, então é necessário corrigir as formulações tradicionais da DEA pelas multiplicativas, a fim de uma avaliação mais acurada e com resultados mais confiáveis da fronteira de eficiência. Outrossim, foram lançados modelos multiplicativos DEA de avaliação estática (em uma única série temporal) e dinâmica (várias e independentes séries temporais), para resolver estes problemas de otimização multicritério em redes virtuais. Seguem os nomes dos modelos criados sequencialmente, segundo o cenário empregado, são eles: a) estáticos – super-multiplicativo (SMDEA) e multiplicativo com orientação às saídas; 144 dinâmico – janela multiplicativo (WMDEA) com orientação às saídas; e, b) Super-Cobb- Douglas com orientação à entrada. Vale salientar que todos os modelos são com CRS, assim como muitos outros modelos foram desenvolvidos e avaliados ao longo deste trabalho doutoral, mas sem dúvidas estes trouxeram os melhores resultados para o tomador de decisão, pois selecionaram o menor número de unidades eficientes para ranqueamento. Este trabalho também mostrou que as partes que fazem um acordo ou SLA, para prestação de serviços de IaaS, devem mudar a forma de taxar, auditar, avaliar e apresentar o desempenho da infraestrutura virtual, com base na análise fractal aqui lançada. Em suma, é recomendável fazer essa retificação proposta, porque a rede é uma das principais peças da engrenagem, para fazer que todos os serviços em nuvem funcionem adequadamente. Portanto, se um hipervisor de rede, usado para fornecer serviços de tráfego TCP em redes virtuais, apresentar um comportamento fractal ruim, então este padrão seria levado a todo o ambiente virtual como um contágio. Entretanto, é necessário escolher o melhor dos padrões fractais do tráfego TCP, dentre um conjunto de ferramentas avaliadas, segundo os critérios fractais elencados. Enfim, ao se implementar uma rede virtual, usando a DMU eleita como a mais eficiente para um dado cenário, tem-se a garantia estocástica do melhor acordo fim a fim para prestação de serviços L3 usando o TCP ao longo do tempo. Como sugestões de extensão deste trabalho pode-se destacar: a) aumentar o escopo da aprendizagem fractal em ambientes de nuvem, relacionado à computação, carga de trabalho, outros protocolos de rede, objetivando o desenvolvimento de um modelo multiplicativo de rede dinâmico DEA (dynamic-network multiplicative DEA) para entrega de serviços de infraestrutura em nuvem mais estáveis e com desempenho superior, segundo uma análise interrelacionada de um conjunto de camadas componentes da IaaS; b) fazer uma comparação entre as formulações multiplicativas DEA, usando as mesmas variáveis fractais deste trabalho, com as principais técnicas MCDM, aliadas à abordagens da inteligência artificial, tal como redes neurais, algoritmos evolucionários, lógica fuzzy, etc.; c) aplicar este sistema especialista para avaliar orquestradores SDN, ou sistemas operacionais em nuvem, ou algoritmos de congestionamento do TCP (ou mesmo versões deste protocolo); e, d) conceber um serviço de orquestração de redes virtuais, em computação em nuvem, ao se estender este trabalho para avaliar o tráfego real, tanto na mesma nuvem, quanto em nuvens que trocam tráfego entre continentes. 145
Destaca-se, ainda, que uma das limitações do trabalho foi não ter avaliado o tráfego real nas redes virtuais. Outra limitação é não ter empregado mais variáveis de decisão na avaliação, porém todos os modelos multiplicativos DEA lançados por esta tese já estariam aptos para avaliar qualquer quantidade de variáveis de decisão em forma de razão. Portanto, os efeitos da AS com LRD podem afetar o mecanismo de controle de fluxo do TCP, pois, ao se variar um hipervisor de rede, este pode carregar um bom ou mau comportamento do TCP ao longo do tempo. Tais efeitos são influenciados pelo acordo para controle de como serão transmitidos os fluxos ou bursts entre origem e destino no TCP, denominado de janela deslizante. Logo, buscar um padrão fractal ótimo é a chave para prestar serviços de transporte mais eficientes usando o TCP. Finalmente, este trabalho atingiu seu objetivo geral e os específicos para contribuir com a oferta de serviços de redes virtuais otimizados, através da aplicação da metodologia desenvolvida, juntamente com as formulações multiplicativas DEA, para predição ou tomada de decisão multicritério nas redes virtuais. Enfim, garante que a escolha da DMU mais eficiente irá fornecer um serviço de rede virtual, com desempenho da largura de banda do TCP superior e estável por um maior período de tempo. Dentre os modelos multiplicativos criados, destaca-se o modelo WMDEA, pois este avalia o desempenho das DMUs em janelas de tempo distintas e independentes, dinamicamente. Adicionalmente, algumas contribuições marginais foram apresentadas, a partir do momento que a maioria dos objetivos específicos foram alcançados. Nesse caso, as contribuições que merecem destaque são: 1) A certificação que a AS no tráfego TCP de redes virtuais tem dimensão, desempenho da largura do TCP e memória fractal distintas por configuração. 2) A predição com sucesso de componentes otimizados, através da aplicação de modelos multiplicativos DEA estáticos e dinâmico, para montagem de ambientes de redes virtuais com desempenho da largura de banda do TCP superior e estável, além de considerável memória fractal ao longo do tempo, garantindo melhor QoS para os usuários destes serviços. 3) Proposta para se fomentar uma política tributária mais justa, sugerindo uma retificação de contrato ou SLA que ao mesmo tempo seja fácil de auditar e avaliar. Nota-se que as informações obtidas em séries temporais do tráfego TCP, das infraestruturas das nuvens, apontam que o comportamento do TCP e uma rede podem ser resumidos nos três índices fractais elencados por esta tese. 146
Os resultados apresentados neste trabalho atestam a prova de conceito deste trabalho doutoral.
6.2 Publicações científicas
Diante da importância de contribuições científicas para construção da tese de doutorado, na Tabela 22 estão listadas as publicações científicas referentes ao período do doutorado (2014 a 2019).
Os trabalhos foram realizados nesse período e estão diretamente relacionados ao conteúdo central da tese.
Tabela 22 - Lista de publicações científicas no período do doutorado # Título Autores Evento/Periódico Ano Performance evaluation of agricultural 12th International municipalities in MARQUES Conference on Data Paraíba State from JUNIOR, F. D.; Envelopment 1 Brazil with Data THOMAZ, A. C. F.; Analysis, University 2014 Envelopment PEREIRA, W. F.; of Malaya, Kuala Analysis (DEA), the LOPES, A. L. M. Lumpur – Malaysia. models with SBM and SBM with super efficiency MARQUES 58th The JUNIOR, F.D; Operational EUFRAZINO Research Society Electing efficient TEIXEIRA, G; Annual Conference 2 elements in SDNFV 2016 LOPES DIAS, K; – DEA Stream, environments FREIRE CUNHA, Portsmouth, P.; DAMASCENO England, 6-9 DE MELO, M. September 2016. A Multiobjective way to select the best
settings using 15th International MARQUES Super-Efficiency Conference on Data JUNIOR, F. D.; SBM DEA models to Envelopment 3 DIAS, K. L.; 2017 deliver network Analysis, Prague – CUNHA, P. R. F.; virtualization Czech Republic, DOMINGUES, M. A. services - a 2017. O stochastic case of study Evaluating the MARQUES fractal behaviour of JUNIOR, F. D.; DEA40: International Virtual Networks EMROUZNEJAD, A; Conference on Data through of an Inter- 4 DIAS, K. L.; Envelopment 2018 temporal DEA model CUNHA, P. R. F.; Analysis, 2018, - Introducing the DE CASTRO E Birmingham, UK Windows SILVA, JORGE L. Multiplicative model MARQUES SMDEA output- Mendeley public 5 JUNIOR, F. D.; 2018 oriented results Dataset EMROUZNEJAD, 147
A.; DIAS, K. L.; CUNHA, P. R. F.; DE CASTRO E SILVA, JORGE L. MARQUES JUNIOR, F. D.; Windows EMROUZNEJAD, A; Mendeley public 6 Multiplicative CCR- DIAS, K. L.; 2018 Dataset O DEA Model CUNHA, P. R. F.; DE CASTRO E SILVA, JORGE L. Marques Júnior, Francisco Daladier; Emrouznejad, Ali; Super-Cobb- Dias, Kelvin; Freire Mendeley public 7 Douglas - SMDEA Cunha, Paulo 2018 Dataset CCR-I – results Roberto; de Castro e Silva, Jorge Luiz; Eufrazino Teixeira, Gervasio MARQUES Optimising virtual JUNIOR, F. D.; Expert System with networks over time EMROUZNEJAD, A; Application 8 by using Windows DIAS, K. L.; 2019 Journal da Elsevier Multiplicative DEA CUNHA, P. R. F.; – Qualis A1 model DE CASTRO E SILVA, JORGE L. Ranking virtual MARQUES XVI EUROPEAN networks accurately JUNIOR, F. D.; WORKSHOP ON using EMROUZNEJAD, A; EFFICIENCY AND output-oriented MIRANDA LOPES, PRODUCTIVITY 9 2019 multiplicative DEA A. L.; DIAS, K. L.; ANALYSIS model with CUNHA, P. R. F.; (EWEPA) variable return to DE CASTRO E LONDON, JUNE 10- scale SILVA, JORGE L. 13 2019 Fonte: dados da pesquisa / 2019 148
REFERÊNCIAS
Alcalde Cuesta, F., González Sequeiros, P., & Lozano Rojo, Á. (2016). Exploring the topological sources of robustness against invasion in biological and technological networks. Scientific Reports, 6, 20666. Retrieved from https://doi.org/10.1038/srep20666 Andersen, P., & Petersen, N. C. (1993). A Procedure for Ranking Efficient Units in Data Envelopment Analysis. Management Science, 39(10), 1261–1264. https://doi.org/10.1287/mnsc.39.10.1261 Baccelli, F., & Hong, D. (2002). AIMD, fairness and fractal scaling of TCP traffic. In Proceedings.Twenty-First Annual Joint Conference of the IEEE Computer and Communications Societies (Vol. 1, pp. 229–238 vol.1). https://doi.org/10.1109/INFCOM.2002.1019264 Banker, R. D., Charnes, A., & Cooper, W. W. (1984). Some models for estimating technical and scale inefficiencies in data envelopment analysis. Management Science, 30(9), 1078–1092. https://doi.org/10.1287/mnsc.30.9.1078 Banker, R. D., Cooper, W. W., Seiford, L. M., Thrall, R. M., & Zhu, J. (2004). Returns to scale in different DEA models. European Journal of Operational Research, 154(2), 345–362. https://doi.org/https://doi.org/10.1016/S0377-2217(03)00174-7 Banker, R. D., & Maindiratta, A. (1986). Piecewise Loglinear Estimation of Efficient Production Surfaces. Manage. Sci., 32(1), 126–135. https://doi.org/10.1287/mnsc.32.1.126 Banker, R. D., & Morey, R. C. (1986). Efficiency Analysis for Exogenously Fixed Inputs and Outputs. Oper. Res., 34(4), 513–521. https://doi.org/10.1287/opre.34.4.513 Barat Zadeh Joveini, M., Sadri, J., & Alavi Khoushhal, H. (2018). Fractal Modeling of Big Data Networks. Bez, N., & Bertrand, S. (2011). The duality of fractals: Roughness and self-similarity. Theoretical Ecology, 4(3), 371–383. https://doi.org/10.1007/s12080-010-0084-y Bui, T. (2015). Analysis of Docker Security. Computing Research Repository, abs/1501.0, 7. Retrieved from http://arxiv.org/abs/1501.02967 Campbell, P., & Abhyankar, S. (1978). Fractals, form, chance and dimension. The Mathematical Intelligencer, 1(1), 35–37. https://doi.org/10.1007/BF03023043 Casado, M., Koponen, T., Ramanathan, R., & Shenker, S. (2010). Virtualizing the Network Forwarding Plane. In Proceedings of the Workshop on Programmable Routers for Extensible Services of Tomorrow (p. 8:1--8:6). New York, NY, USA: ACM. https://doi.org/10.1145/1921151.1921162 Chakraborty, D., Ashir, A., Suganuma, T., Mansfield Keeni, G., Roy, T. K., & Shiratori, N. (2004). Self-similar and fractal nature of Internet traffic. International Journal of Network Management, 14(2), 119–129. https://doi.org/10.1002/nem.512 Charnes, A., Clark, C. T., Cooper, W. W., & Golany, B. (1984). A developmental study of data envelopment analysis in measuring the efficiency of maintenance units in the U.S. air forces. Annals of Operations Research, 2(1), 95–112. https://doi.org/10.1007/BF01874734 149
Charnes, A., Cooper, W. W., & Rhodes, E. (1978). Measuring the efficiency of decision making units. European Journal of Operational Research, 2(6), 429–444. https://doi.org/10.1016/0377-2217(78)90138-8 Charnes, A., Gallegos, A., & Li, H. (1996). Robustly efficient parametric frontiers via Multiplicative DEA for domestic and international operations of the Latin American airline industry. European Journal of Operational Research, 88(3), 525–536. https://doi.org/https://doi.org/10.1016/0377-2217(94)00216-9 Chowdhury, N. M. M. K., & Boutaba, R. (2010). A survey of network virtualization. Computer Networks, 54(5), 862–876. https://doi.org/10.1016/j.comnet.2009.10.017 Cook, W. D., & Zhu, J. (2014). DEA Cobb–Douglas frontier and cross-efficiency. Journal of the Operational Research Society, 65(2), 265–268. https://doi.org/10.1057/jors.2013.13 Cook, W. D., & Zhu, J. (2015). DEA cross efficiency. In International Series in Operations Research and Management Science (Vol. 221, pp. 23–43). https://doi.org/10.1007/978-1-4899-7553-9_2 Cooper, W. W., Seiford, L. M., & Tone, K. (2007). Data envelopment analysis: A comprehensive text with models, applications, references and DEA-solver software: Second edition. Data Envelopment Analysis: A Comprehensive Text with Models, Applications, References and DEA-Solver Software: Second Edition. https://doi.org/10.1007/978-0-387-45283-8 Cronkite-Ratcliff, B., Bergman, A., Vargaftik, S., Ravi, M., McKeown, N., Abraham, I., & Keslassy, I. (2016). Virtualized Congestion Control. In Proceedings of the 2016 ACM SIGCOMM Conference (pp. 230–243). New York, NY, USA: ACM. https://doi.org/10.1145/2934872.2934889 Crovella, M. E., & Bestavros, A. (1997). Self-similarity in World Wide Web traffic: evidence and possible causes. IEEE/ACM Transactions on Networking, 5(6), 835– 846. https://doi.org/10.1109/90.650143 Daqing, L., Kosmidis, K., Bunde, A., & Havlin, S. (2011). Dimension of spatially embedded networks. Nature Physics, 7, 481. Retrieved from https://doi.org/10.1038/nphys1932 Dauphiné, A. (2013). A Fractal World. In Fractal Geography (pp. 1–19). John Wiley & Sons, Inc. https://doi.org/10.1002/9781118603178.ch1 de Carvalho Ferreira, C. M., & Provezano Gomes. (2009). Introdução à Análise Envoltória de Dados (1st ed.). Editora UFV. Retrieved from https://editoraufv.com.br/produto/1591265/introducao-a-analise-envoltoria-de- dados de Lima, A. B., & de Almeida Amazonas, J. R. (2013). Internet Teletraffic Modeling and Estimation. Wharton, TX, USA: River Publishers. Dua, R., Raja, A. R., & Kakadia, D. (2014). Virtualization vs containerization to support PaaS. In Proceedings - 2014 IEEE International Conference on Cloud Engineering, IC2E 2014 (pp. 610–614). https://doi.org/10.1109/IC2E.2014.41 Emrouznejad, A., & Amin, G. R. (2009). DEA models for ratio data: Convexity consideration. Applied Mathematical Modelling, 33(1), 486–498. 150
https://doi.org/https://doi.org/10.1016/j.apm.2007.11.018 Emrouznejad, A., & Cabanda, E. (2010). An aggregate measure of financial ratios using a multiplicative DEA model. International Journal of Financial Services Management, 4(2), 114–126. Retrieved from https://econpapers.repec.org/RePEc:ids:ijfsmg:v:4:y:2010:i:2:p:114-126 Emrouznejad, A., Cabanda, E., & Gholami, R. (2010). An alternative measure of the ICT-Opportunity Index. Information & Management, 47(4), 246–254. https://doi.org/https://doi.org/10.1016/j.im.2010.04.002 Emrouznejad, A., Rostami-Tabar, B., & Petridis, K. (2016). A novel ranking procedure for forecasting approaches using Data Envelopment Analysis. Technological Forecasting and Social Change, 111(Supplement C), 235–243. https://doi.org/https://doi.org/10.1016/j.techfore.2016.07.004 Emrouznejad, A., Rostamy-Malkhalifeh, M., Hatami-Marbini, A., & Tavana, M. (2012). General and multiplicative non-parametric corporate performance models with interval ratio data. Applied Mathematical Modelling, 36(11), 5506–5514. https://doi.org/https://doi.org/10.1016/j.apm.2011.12.040 Emrouznejad, A., & Witte, K. De. (2010). COOPER-framework: A unified process for non-parametric projects. European Journal of Operational Research, 207(3), 1573– 1586. https://doi.org/https://doi.org/10.1016/j.ejor.2010.07.025 Emrouznejad, A., & Yang, G. liang. (2017). A survey and analysis of the first 40 years of scholarly literature in DEA: 1978-2016. Socio-Economic Planning Sciences. https://doi.org/10.1016/j.seps.2017.01.008 Fernandes, N. C., Moreira, M. D. D., Moraes, I. M., Ferraz, L. H. G., Couto, R. S., Carvalho, H. E. T., … Duarte, O. C. M. B. (2011). Virtual networks: Isolation, performance, and trends. Annales Des Telecommunications/Annals of Telecommunications, 66(5–6), 339–355. https://doi.org/10.1007/s12243-010-0208- 9 Fernandez-Palacin, F., Lopez-Sanchez, M. A., & Munoz-Márques, M. (2018). STEPWISE SELECTION OF VARIABLES IN DEA USING CONTRIBUTION LOADS. Pesquisa Operacional, 38, 31–52. Retrieved from http://www.scielo.br/scielo.php?script=sci_arttext&pid=S0101- 74382018000100031&nrm=iso Florindo, J. B., & Bruno, O. M. (2013). Texture analysis by multi-resolution fractal descriptors. Expert Systems with Applications, 40(10), 4022–4028. https://doi.org/https://doi.org/10.1016/j.eswa.2013.01.007 Førsund, F. R. (1996). On the calculation of the scale elasticity in DEA models. Journal of Productivity Analysis, 7(2), 283–302. https://doi.org/10.1007/BF00157045 Gilbert, E. N. (1960). Capacity of a burst-noise channel. The Bell System Technical Journal, 39(5), 1253–1265. https://doi.org/10.1002/j.1538-7305.1960.tb03959.x Gneiting, T., Sevčíková, H., & Percival, D. B. (2012). Estimators of Fractal Dimension: Assessing the Roughness of Time Series and Spatial Data. Statistical Science Donald B. Percival Is Principal Mathematician Applied Physics Laboratory, 27(2), 247–277. https://doi.org/10.1214/11-STS370 151
Ha, S., Lopez-Pacheco, D., & Urvoy-Keller, G. (2013). Networking in a virtualized environment: The TCP case. In 2013 IEEE 2nd International Conference on Cloud Networking (CloudNet) (pp. 50–57). https://doi.org/10.1109/CloudNet.2013.6710557 Hall, P., & Roy, R. (1994). On the Relationship Between Fractal Dimension and Fractal Index for Stationary Stochastic Processes. The Annals of Applied Probability, 4(1), 241–253. Retrieved from http://www.jstor.org/stable/2245054 He, Y. M., Wang, B. M., & Qiao, D. J. (2012). Application in Anomaly Detection of Network Traffic Based on Fractal Technology. Applied Mechanics and Materials, 195–196, 987–991. https://doi.org/10.4028/www.scientific.net/AMM.195-196.987 Hill, B. M. (1975). A Simple General Approach to Inference About the Tail of a Distribution. Ann. Statist., 3(5), 1163–1174. https://doi.org/10.1214/aos/1176343247 HURST, H. E. (1951). LONG-TERM STORAGE CAPACITY OF RESERVOIRS. TRANSACTIONS OF THE AMERICAN SOCIETY OF CIVIL ENGINEERS, 116, 770–799. https://doi.org/10.1119/1.18629 Iqbal, M., Naeem, M., Anpalagan, A., Qadri, N. N., & Imran, M. (2016). Multi-objective optimization in sensor networks: Optimization classification, applications and solution approaches. Computer Networks, 99, 134–161. https://doi.org/https://doi.org/10.1016/j.comnet.2016.01.015 Jain, R. (1991). The art of computer systems performance analysis - techniques for experimental design, measurement, simulation, and modeling. Wiley. Jenkins, L., & Anderson, M. (2003). A multivariate statistical approach to reducing the number of variables in data envelopment analysis. European Journal of Operational Research, 147(1), 51–61. https://doi.org/https://doi.org/10.1016/S0377- 2217(02)00243-6 Kaklauskas, L., & Sakalauskas, L. (2009). Application of Chaos Theory to Analysis of Computer Network Traffic. Kang, H., Le, M., & Tao, S. (2016). Container and microservice driven design for cloud infrastructure DevOps. In Proceedings - 2016 IEEE International Conference on Cloud Engineering, IC2E 2016: Co-located with the 1st IEEE International Conference on Internet-of-Things Design and Implementation, IoTDI 2016 (pp. 202–211). https://doi.org/10.1109/IC2E.2016.26 Kantelhardt, J. W. (2008). Fractal and Multifractal Time Series. Encyclopedia of Complexity and Systems Science, 59. https://doi.org/10.1007/SpringerReference_60393 Khan, A., Zugenmaier, A., Jurca, D., & Kellerer, W. (2012). Network virtualization: a hypervisor for the Internet? IEEE Communications Magazine, 50(1), 136–143. https://doi.org/10.1109/MCOM.2012.6122544 Leland, W. E., Taqqu, M. S., & Wilson, D. V. (1994). On the Self-Similar Nature of Ethernet Traffic (Extended Version). IEEE/ACM Transactions on Networking, 2(1), 1–15. https://doi.org/10.1109/90.282603 Lieberman, E., Hauert, C., & Nowak, M. A. (2005). Evolutionary dynamics on graphs. 152
Nature, 433(7023), 312–316. https://doi.org/10.1038/nature03204 Lilja, D. J. (2000). Measuring Computer Performance: A Practitioner’s Guide. Cambridge University Press. https://doi.org/10.1017/CBO9780511612398 Lins, M. P. E., & Calôba, G. M. (2006). Programação linear: com aplicações em teoria dos jogos e avaliação de desempenho (data envelopment analysis). Interci{ê}ncia. Retrieved from https://books.google.com.br/books?id=SFxSSAAACAAJ Liu, J. (2019). Fractal Network Traffic Analysis with Applications. Liu, W., Yan, Y., Tang, D., & Tang, R. (2012). Self-Similarity and Heavy-Tail of {ICMP} Traffic. JCP, 7(12), 2948–2954. https://doi.org/10.4304/jcp.7.12.2948-2954 Lloyd, C. D., Berberoglu, S., Curran, P. J., & Atkinson, P. M. (2004). A comparison of texture measures for the per-field classification of Mediterranean land cover. International Journal of Remote Sensing, 25(19), 3943–3965. https://doi.org/10.1080/0143116042000192321 López-Ortega, O., & López-Popa, S. I. (2012). Fractals, fuzzy logic and expert systems to assist in the construction of musical pieces. Expert Systems with Applications, 39(15), 11911–11923. https://doi.org/https://doi.org/10.1016/j.eswa.2012.02.089 Mandelbrot, B. (1965). Self-Similar Error Clusters in Communication Systems and the Concept of Conditional Stationarity. Communication Technology, IEEE Transactions On, 13(1), 71–90. https://doi.org/10.1109/TCOM.1965.1089090 Mandelbrot, B. (1967). How Long Is the Coast of Britain? Statistical Self-Similarity and Fractional Dimension. Science, 156(3775), 636–638. https://doi.org/10.1126/science.156.3775.636 Mandelbrot, B. B. (1975). Stochastic Models for the Earth’s Relief, the Shape and the Fractal Dimension of the Coastlines, and the Number-Area Rule for Islands. Proceedings of the National Academy of Sciences of the United States of America, 72(10), 3825–3828. Retrieved from http://www.jstor.org/stable/65184 Mandelbrot, B. B. (1982). The Fractal Geometry of Nature. 1997. Retrieved from https://books.google.com.br/books?id=SWcPAQAAMAAJ Mandelbrot, B. B., & Taleb, N. N. (2012). mild vs wild randomness focusing on those risks that matter. In the Known, the Unknown and the Unknowable in Financial Risk Management : Measurement and Theory Advancing Practice. https://doi.org/10.1017/CBO9781107415324.004 Mandelbrot, B. B., & Wallis, J. R. (1969). Computer Experiments with Fractional Gaussian Noises: Part 2, Rescaled Ranges and Spectra. Water Resources Research, 5(1), 242–259. https://doi.org/10.1029/WR005i001p00242 Martín de Diego, I., Siordia, O. S., Fernández-Isabel, A., Conde, C., & Cabello, E. (2019). Subjective data arrangement using clustering techniques for training expert systems. Expert Systems with Applications, 115, 1–15. https://doi.org/https://doi.org/10.1016/j.eswa.2018.07.058 Millan, G., Juan, E. S., & Jamett, M. (2014). A simple estimator of the Hurst exponent for self-similar traffic flows. IEEE Latin America Transactions, 12(8), 1349–1354. https://doi.org/10.1109/TLA.2014.7014500 153
Morabito, R., Kjällman, J., & Komu, M. (2015). Hypervisors vs. lightweight virtualization: A performance comparison. In Proceedings - 2015 IEEE International Conference on Cloud Engineering, IC2E 2015 (pp. 386–393). https://doi.org/10.1109/IC2E.2015.74 Nakanishi, Y. J., & Falcocchio, J. C. (2004). PERFORMANCE ASSESSMENT OF INTELLIGENT TRANSPORTATION SYSTEMS USING DATA ENVELOPMENT ANALYSIS. Research in Transportation Economics, 8, 181–197. https://doi.org/https://doi.org/10.1016/S0739-8859(04)08009-6 Ni, L.-P., Ni, Z.-W., & Gao, Y.-Z. (2011). Stock trend prediction based on fractal feature selection and support vector machine. Expert Systems with Applications, 38(5), 5569–5576. https://doi.org/https://doi.org/10.1016/j.eswa.2010.10.079 Olesen, O. B., Petersen, N. C., & Podinovski, V. V. (2015). Efficiency analysis with ratio measures. European Journal of Operational Research, 245(2), 446–462. https://doi.org/https://doi.org/10.1016/j.ejor.2015.03.013 Olesen, O. B., Petersen, N. C., & Podinovski, V. V. (2017). Efficiency measures and computational approaches for data envelopment analysis models with ratio inputs and outputs. European Journal of Operational Research, 261(2), 640–655. https://doi.org/https://doi.org/10.1016/j.ejor.2017.02.021 Oliveira, C., Kim, J. B., & Suda, T. (2003). Long-range dependence in IEEE 802.11b wireless LAN traffic: an empirical study. In 2002 14th International Conference on Ion Implantation Technology Proceedings (IEEE Cat. No.02EX505) (pp. 17–23). https://doi.org/10.1109/CCW.2003.1240784 Paxson, V., & Floyd, S. (1995). Wide Area Traffic: The Failure of Poisson Modeling. IEEE/ACM Transactions on Networking, 3(3), 226–244. https://doi.org/10.1109/90.392383 Popek, G. J., & Goldberg, R. P. (1974). Formal Requirements for Virtualizable Third Generation Architectures. Commun. ACM, 17(7), 412–421. https://doi.org/10.1145/361011.361073 Przystalski, K., & Ogorzałek, M. J. (2017). Multispectral skin patterns analysis using fractal methods. Expert Systems with Applications, 88, 318–326. https://doi.org/https://doi.org/10.1016/j.eswa.2017.07.011 Rastogi, V., Niddodi, C., Mohan, S., & Jha, S. (2017). New Directions for Container Debloating. In Proceedings of the 2017 Workshop on Forming an Ecosystem Around Software Transformation (pp. 51–56). New York, NY, USA: ACM. https://doi.org/10.1145/3141235.3141241 Rathore, M. (2013). KVM vs. LXC: Comparing Performance and Isolation of Hardware- assisted Virtual Routers. American Journal of Networks and Communications, 2, 88. Rathore, M. S., Hidell, M., & Sjödin, P. (2011). Data plane optimization in open virtual routers. In Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics) (Vol. 6640 LNCS, pp. 379–392). https://doi.org/10.1007/978-3-642-20757-0_30 Rizo, L., Torres, D., Dehesa, J., & Munoz, D. (2008). Cauchy Distribution for Jitter in IP Networks. https://doi.org/10.1109/CONIELECOMP.2008.39 154
Rosenblum, M., & Garfinkel, T. (2005). Virtual machine monitors: current technology and future trends. Computer, 38(5), 39–47. https://doi.org/10.1109/MC.2005.176 Sahoo, J., Mohapatra, S., & Lath, R. (2010). Virtualization: A survey on concepts, taxonomy and associated security issues. In 2nd International Conference on Computer and Network Technology, ICCNT 2010 (pp. 222–226). https://doi.org/10.1109/ICCNT.2010.49 Seiford, L., Charnes, A., W. Cooper, W., & A. Stutz, J. (1982). A Multiplicative Model for Efficiency Analysis. Socio-Economic Planning Sciences, 16, 223–224. Seiford, L. M., & Zhu, J. (1999). Infeasibility of super-efficiency data envelopment analysis models. Infor, 37(2), 174–187. https://doi.org/Http://Dx.Doi.Org/10.1080/03155986.1999.11732379 SMITH, R. D. (2011). THE DYNAMICS OF INTERNET TRAFFIC: SELF-SIMILARITY, SELF-ORGANIZATION, AND COMPLEX PHENOMENA. Advances in Complex Systems, 14(06), 905–949. https://doi.org/10.1142/S0219525911003451 Soltesz, S., Pötzl, H., Fiuczynski, M. E., Bavier, A., & Peterson, L. (2007). Container- based operating system virtualization: a scalable, high-performance alternative to hypervisors. ACM SIGOPS Operating Systems Review, 41(3), 275. https://doi.org/10.1145/1272998.1273025 Stein, A., Shi, W., & Bijker, W. (2008). Quality Aspects in Spatial Data Mining (1st ed.). Boca Raton, FL, USA: CRC Press, Inc. Thrall, R. M. (1996). Duality, classification and slacks in DEA. Annals of Operations Research, 66(2), 109–138. https://doi.org/10.1007/BF02187297 Valadkhani, A., Roshdi, I., & Smyth, R. (2016). A Multiplicative Environmental DEA approach to measure efficiency changes in the world’s major polluters. Energy Economics (Vol. 54). https://doi.org/10.1016/j.eneco.2015.12.018 Wang, D., Ren, C., Govindan, S., Sivasubramaniam, A., Urgaonkar, B., Kansal, A., & Vaid, K. (2013). ACE: Abstracting, characterizing and exploiting datacenter power demands. In 2013 IEEE International Symposium on Workload Characterization (IISWC) (pp. 44–55). https://doi.org/10.1109/IISWC.2013.6704669 Weron, R. (2002). Estimating long-range dependence: Finite sample properties and confidence intervals. Physica A: Statistical Mechanics and Its Applications, 312(1– 2), 285–299. https://doi.org/10.1016/S0378-4371(02)00961-5 Whaiduzzaman, M., Gani, A., Anuar, N. B., Shiraz, M., Haque, M. N., & Haque, I. T. (2014). Cloud service selection using multicriteria decision analysis. The Scientific World Journal. https://doi.org/10.1155/2014/459375 Williams, D. E. (2007). Virtualization with Xen(Tm): Including XenEnterprise, XenServer, and XenExpress: Including XenEnterprise, XenServer, and XenExpress. Syngress Publishing. Wisitpongphan, N., & Peha, J. M. (2003). Effect of TCP on self-similarity of network traffic. In Proceedings. 12th International Conference on Computer Communications and Networks (IEEE Cat. No.03EX712) (pp. 370–373). https://doi.org/10.1109/ICCCN.2003.1284196 155
Xue, M., & Harker, P. T. (2002). Note: Ranking DMUs with Infeasible Super-Efficiency DEA Models. Management Science, 48(5), 705–710. https://doi.org/10.1287/mnsc.48.5.705.7805 Yan, W. (2005). Measuring the Histogram Feature Vector for Anomaly Network Traffic BT - Computational Intelligence and Security. In Y. Hao, J. Liu, Y.-P. Wang, Y. Cheung, H. Yin, L. Jiao, … Y.-C. Jiao (Eds.) (pp. 279–284). Berlin, Heidelberg: Springer Berlin Heidelberg. Ye, L., Zhang, H., Shi, J., & Du, X. (2012). Verifying cloud Service Level Agreement. In 2012 IEEE Global Communications Conference (GLOBECOM) (pp. 777–782). https://doi.org/10.1109/GLOCOM.2012.6503207 Zhao, X., Shen, L., Peng, X., & Zhao, W. (2015). Toward SLA-constrained service composition: An approach based on a fuzzy linguistic preference model and an evolutionary algorithm. Information Sciences, 316, 370–396. https://doi.org/10.1016/J.INS.2014.11.016 Zhou, S., Han, J., & Tang, H. (2011). Fractal Traffic Analysis and Applications in Industrial Control Ethernet Network BT - Emerging Research in Artificial Intelligence and Computational Intelligence. In H. Deng, D. Miao, F. L. Wang, & J. Lei (Eds.) (pp. 34–42). Berlin, Heidelberg: Springer Berlin Heidelberg. Alcalde Cuesta, F., González Sequeiros, P., & Lozano Rojo, Á. (2016). Exploring the topological sources of robustness against invasion in biological and technological networks. Scientific Reports, 6, 20666. Retrieved from https://doi.org/10.1038/srep20666 Andersen, P., & Petersen, N. C. (1993). A Procedure for Ranking Efficient Units in Data Envelopment Analysis. Management Science, 39(10), 1261–1264. https://doi.org/10.1287/mnsc.39.10.1261 Baccelli, F., & Hong, D. (2002). AIMD, fairness and fractal scaling of TCP traffic. In Proceedings.Twenty-First Annual Joint Conference of the IEEE Computer and Communications Societies (Vol. 1, pp. 229–238 vol.1). https://doi.org/10.1109/INFCOM.2002.1019264 Banker, R. D., Charnes, A., & Cooper, W. W. (1984). Some models for estimating technical and scale inefficiencies in data envelopment analysis. Management Science, 30(9), 1078–1092. https://doi.org/10.1287/mnsc.30.9.1078 Banker, R. D., Cooper, W. W., Seiford, L. M., Thrall, R. M., & Zhu, J. (2004). Returns to scale in different DEA models. European Journal of Operational Research, 154(2), 345–362. https://doi.org/https://doi.org/10.1016/S0377-2217(03)00174-7 Banker, R. D., & Maindiratta, A. (1986). Piecewise Loglinear Estimation of Efficient Production Surfaces. Manage. Sci., 32(1), 126–135. https://doi.org/10.1287/mnsc.32.1.126 Banker, R. D., & Morey, R. C. (1986). Efficiency Analysis for Exogenously Fixed Inputs and Outputs. Oper. Res., 34(4), 513–521. https://doi.org/10.1287/opre.34.4.513 Barat Zadeh Joveini, M., Sadri, J., & Alavi Khoushhal, H. (2018). Fractal Modeling of Big Data Networks. Bez, N., & Bertrand, S. (2011). The duality of fractals: Roughness and self-similarity. 156
Theoretical Ecology, 4(3), 371–383. https://doi.org/10.1007/s12080-010-0084-y Bui, T. (2015). Analysis of Docker Security. Computing Research Repository, abs/1501.0, 7. Retrieved from http://arxiv.org/abs/1501.02967 Campbell, P., & Abhyankar, S. (1978). Fractals, form, chance and dimension. The Mathematical Intelligencer, 1(1), 35–37. https://doi.org/10.1007/BF03023043 Casado, M., Koponen, T., Ramanathan, R., & Shenker, S. (2010). Virtualizing the Network Forwarding Plane. In Proceedings of the Workshop on Programmable Routers for Extensible Services of Tomorrow (p. 8:1--8:6). New York, NY, USA: ACM. https://doi.org/10.1145/1921151.1921162 Chakraborty, D., Ashir, A., Suganuma, T., Mansfield Keeni, G., Roy, T. K., & Shiratori, N. (2004). Self-similar and fractal nature of Internet traffic. International Journal of Network Management, 14(2), 119–129. https://doi.org/10.1002/nem.512 Charnes, A., Clark, C. T., Cooper, W. W., & Golany, B. (1984). A developmental study of data envelopment analysis in measuring the efficiency of maintenance units in the U.S. air forces. Annals of Operations Research, 2(1), 95–112. https://doi.org/10.1007/BF01874734 Charnes, A., Cooper, W. W., & Rhodes, E. (1978). Measuring the efficiency of decision making units. European Journal of Operational Research, 2(6), 429–444. https://doi.org/10.1016/0377-2217(78)90138-8 Charnes, A., Gallegos, A., & Li, H. (1996). Robustly efficient parametric frontiers via Multiplicative DEA for domestic and international operations of the Latin American airline industry. European Journal of Operational Research, 88(3), 525–536. https://doi.org/https://doi.org/10.1016/0377-2217(94)00216-9 Chowdhury, N. M. M. K., & Boutaba, R. (2010). A survey of network virtualization. Computer Networks, 54(5), 862–876. https://doi.org/10.1016/j.comnet.2009.10.017 Cook, W. D., & Zhu, J. (2014). DEA Cobb–Douglas frontier and cross-efficiency. Journal of the Operational Research Society, 65(2), 265–268. https://doi.org/10.1057/jors.2013.13 Cook, W. D., & Zhu, J. (2015). DEA cross efficiency. In International Series in Operations Research and Management Science (Vol. 221, pp. 23–43). https://doi.org/10.1007/978-1-4899-7553-9_2 Cooper, W. W., Seiford, L. M., & Tone, K. (2007). Data envelopment analysis: A comprehensive text with models, applications, references and DEA-solver software: Second edition. Data Envelopment Analysis: A Comprehensive Text with Models, Applications, References and DEA-Solver Software: Second Edition. https://doi.org/10.1007/978-0-387-45283-8 Cronkite-Ratcliff, B., Bergman, A., Vargaftik, S., Ravi, M., McKeown, N., Abraham, I., & Keslassy, I. (2016). Virtualized Congestion Control. In Proceedings of the 2016 ACM SIGCOMM Conference (pp. 230–243). New York, NY, USA: ACM. https://doi.org/10.1145/2934872.2934889 Crovella, M. E., & Bestavros, A. (1997). Self-similarity in World Wide Web traffic: evidence and possible causes. IEEE/ACM Transactions on Networking, 5(6), 835– 846. https://doi.org/10.1109/90.650143 157
Daqing, L., Kosmidis, K., Bunde, A., & Havlin, S. (2011). Dimension of spatially embedded networks. Nature Physics, 7, 481. Retrieved from https://doi.org/10.1038/nphys1932 Dauphiné, A. (2013). A Fractal World. In Fractal Geography (pp. 1–19). John Wiley & Sons, Inc. https://doi.org/10.1002/9781118603178.ch1 de Carvalho Ferreira, C. M., & Provezano Gomes. (2009). Introdução à Análise Envoltória de Dados (1st ed.). Editora UFV. Retrieved from https://editoraufv.com.br/produto/1591265/introducao-a-analise-envoltoria-de- dados de Lima, A. B., & de Almeida Amazonas, J. R. (2013). Internet Teletraffic Modeling and Estimation. Wharton, TX, USA: River Publishers. Dua, R., Raja, A. R., & Kakadia, D. (2014). Virtualization vs containerization to support PaaS. In Proceedings - 2014 IEEE International Conference on Cloud Engineering, IC2E 2014 (pp. 610–614). https://doi.org/10.1109/IC2E.2014.41 Emrouznejad, A., & Amin, G. R. (2009). DEA models for ratio data: Convexity consideration. Applied Mathematical Modelling, 33(1), 486–498. https://doi.org/https://doi.org/10.1016/j.apm.2007.11.018 Emrouznejad, A., & Cabanda, E. (2010). An aggregate measure of financial ratios using a multiplicative DEA model. International Journal of Financial Services Management, 4(2), 114–126. Retrieved from https://econpapers.repec.org/RePEc:ids:ijfsmg:v:4:y:2010:i:2:p:114-126 Emrouznejad, A., Cabanda, E., & Gholami, R. (2010). An alternative measure of the ICT-Opportunity Index. Information & Management, 47(4), 246–254. https://doi.org/https://doi.org/10.1016/j.im.2010.04.002 Emrouznejad, A., Rostami-Tabar, B., & Petridis, K. (2016). A novel ranking procedure for forecasting approaches using Data Envelopment Analysis. Technological Forecasting and Social Change, 111(Supplement C), 235–243. https://doi.org/https://doi.org/10.1016/j.techfore.2016.07.004 Emrouznejad, A., Rostamy-Malkhalifeh, M., Hatami-Marbini, A., & Tavana, M. (2012). General and multiplicative non-parametric corporate performance models with interval ratio data. Applied Mathematical Modelling, 36(11), 5506–5514. https://doi.org/https://doi.org/10.1016/j.apm.2011.12.040 Emrouznejad, A., & Witte, K. De. (2010). COOPER-framework: A unified process for non-parametric projects. European Journal of Operational Research, 207(3), 1573– 1586. https://doi.org/https://doi.org/10.1016/j.ejor.2010.07.025 Emrouznejad, A., & Yang, G. liang. (2017). A survey and analysis of the first 40 years of scholarly literature in DEA: 1978-2016. Socio-Economic Planning Sciences. https://doi.org/10.1016/j.seps.2017.01.008 Fernandes, N. C., Moreira, M. D. D., Moraes, I. M., Ferraz, L. H. G., Couto, R. S., Carvalho, H. E. T., … Duarte, O. C. M. B. (2011). Virtual networks: Isolation, performance, and trends. Annales Des Telecommunications/Annals of Telecommunications, 66(5–6), 339–355. https://doi.org/10.1007/s12243-010-0208- 9 158
Fernandez-Palacin, F., Lopez-Sanchez, M. A., & Munoz-Márques, M. (2018). STEPWISE SELECTION OF VARIABLES IN DEA USING CONTRIBUTION LOADS. Pesquisa Operacional, 38, 31–52. Retrieved from http://www.scielo.br/scielo.php?script=sci_arttext&pid=S0101- 74382018000100031&nrm=iso Florindo, J. B., & Bruno, O. M. (2013). Texture analysis by multi-resolution fractal descriptors. Expert Systems with Applications, 40(10), 4022–4028. https://doi.org/https://doi.org/10.1016/j.eswa.2013.01.007 Førsund, F. R. (1996). On the calculation of the scale elasticity in DEA models. Journal of Productivity Analysis, 7(2), 283–302. https://doi.org/10.1007/BF00157045 Gilbert, E. N. (1960). Capacity of a burst-noise channel. The Bell System Technical Journal, 39(5), 1253–1265. https://doi.org/10.1002/j.1538-7305.1960.tb03959.x Gneiting, T., Sevčíková, H., & Percival, D. B. (2012). Estimators of Fractal Dimension: Assessing the Roughness of Time Series and Spatial Data. Statistical Science Donald B. Percival Is Principal Mathematician Applied Physics Laboratory, 27(2), 247–277. https://doi.org/10.1214/11-STS370 Ha, S., Lopez-Pacheco, D., & Urvoy-Keller, G. (2013). Networking in a virtualized environment: The TCP case. In 2013 IEEE 2nd International Conference on Cloud Networking (CloudNet) (pp. 50–57). https://doi.org/10.1109/CloudNet.2013.6710557 Hall, P., & Roy, R. (1994). On the Relationship Between Fractal Dimension and Fractal Index for Stationary Stochastic Processes. The Annals of Applied Probability, 4(1), 241–253. Retrieved from http://www.jstor.org/stable/2245054 He, Y. M., Wang, B. M., & Qiao, D. J. (2012). Application in Anomaly Detection of Network Traffic Based on Fractal Technology. Applied Mechanics and Materials, 195–196, 987–991. https://doi.org/10.4028/www.scientific.net/AMM.195-196.987 Hill, B. M. (1975). A Simple General Approach to Inference About the Tail of a Distribution. Ann. Statist., 3(5), 1163–1174. https://doi.org/10.1214/aos/1176343247 HURST, H. E. (1951). LONG-TERM STORAGE CAPACITY OF RESERVOIRS. TRANSACTIONS OF THE AMERICAN SOCIETY OF CIVIL ENGINEERS, 116, 770–799. https://doi.org/10.1119/1.18629 Iqbal, M., Naeem, M., Anpalagan, A., Qadri, N. N., & Imran, M. (2016). Multi-objective optimization in sensor networks: Optimization classification, applications and solution approaches. Computer Networks, 99, 134–161. https://doi.org/https://doi.org/10.1016/j.comnet.2016.01.015 Jain, R. (1991). The art of computer systems performance analysis - techniques for experimental design, measurement, simulation, and modeling. Wiley. Jenkins, L., & Anderson, M. (2003). A multivariate statistical approach to reducing the number of variables in data envelopment analysis. European Journal of Operational Research, 147(1), 51–61. https://doi.org/https://doi.org/10.1016/S0377- 2217(02)00243-6 Kaklauskas, L., & Sakalauskas, L. (2009). Application of Chaos Theory to Analysis of 159
Computer Network Traffic. Kang, H., Le, M., & Tao, S. (2016). Container and microservice driven design for cloud infrastructure DevOps. In Proceedings - 2016 IEEE International Conference on Cloud Engineering, IC2E 2016: Co-located with the 1st IEEE International Conference on Internet-of-Things Design and Implementation, IoTDI 2016 (pp. 202–211). https://doi.org/10.1109/IC2E.2016.26 Kantelhardt, J. W. (2008). Fractal and Multifractal Time Series. Encyclopedia of Complexity and Systems Science, 59. https://doi.org/10.1007/SpringerReference_60393 Khan, A., Zugenmaier, A., Jurca, D., & Kellerer, W. (2012). Network virtualization: a hypervisor for the Internet? IEEE Communications Magazine, 50(1), 136–143. https://doi.org/10.1109/MCOM.2012.6122544 Leland, W. E., Taqqu, M. S., & Wilson, D. V. (1994). On the Self-Similar Nature of Ethernet Traffic (Extended Version). IEEE/ACM Transactions on Networking, 2(1), 1–15. https://doi.org/10.1109/90.282603 Lieberman, E., Hauert, C., & Nowak, M. A. (2005). Evolutionary dynamics on graphs. Nature, 433(7023), 312–316. https://doi.org/10.1038/nature03204 Lilja, D. J. (2000). Measuring Computer Performance: A Practitioner’s Guide. Cambridge University Press. https://doi.org/10.1017/CBO9780511612398 Lins, M. P. E., & Calôba, G. M. (2006). Programação linear: com aplicações em teoria dos jogos e avaliação de desempenho (data envelopment analysis). Interci{ê}ncia. Retrieved from https://books.google.com.br/books?id=SFxSSAAACAAJ Liu, J. (2019). Fractal Network Traffic Analysis with Applications. Liu, W., Yan, Y., Tang, D., & Tang, R. (2012). Self-Similarity and Heavy-Tail of {ICMP} Traffic. JCP, 7(12), 2948–2954. https://doi.org/10.4304/jcp.7.12.2948-2954 Lloyd, C. D., Berberoglu, S., Curran, P. J., & Atkinson, P. M. (2004). A comparison of texture measures for the per-field classification of Mediterranean land cover. International Journal of Remote Sensing, 25(19), 3943–3965. https://doi.org/10.1080/0143116042000192321 López-Ortega, O., & López-Popa, S. I. (2012). Fractals, fuzzy logic and expert systems to assist in the construction of musical pieces. Expert Systems with Applications, 39(15), 11911–11923. https://doi.org/https://doi.org/10.1016/j.eswa.2012.02.089 Mandelbrot, B. (1965). Self-Similar Error Clusters in Communication Systems and the Concept of Conditional Stationarity. Communication Technology, IEEE Transactions On, 13(1), 71–90. https://doi.org/10.1109/TCOM.1965.1089090 Mandelbrot, B. (1967). How Long Is the Coast of Britain? Statistical Self-Similarity and Fractional Dimension. Science, 156(3775), 636–638. https://doi.org/10.1126/science.156.3775.636 Mandelbrot, B. B. (1975). Stochastic Models for the Earth’s Relief, the Shape and the Fractal Dimension of the Coastlines, and the Number-Area Rule for Islands. Proceedings of the National Academy of Sciences of the United States of America, 72(10), 3825–3828. Retrieved from http://www.jstor.org/stable/65184 160
Mandelbrot, B. B. (1982). The Fractal Geometry of Nature. 1997. Retrieved from https://books.google.com.br/books?id=SWcPAQAAMAAJ Mandelbrot, B. B., & Taleb, N. N. (2012). mild vs wild randomness focusing on those risks that matter. In the Known, the Unknown and the Unknowable in Financial Risk Management : Measurement and Theory Advancing Practice. https://doi.org/10.1017/CBO9781107415324.004 Mandelbrot, B. B., & Wallis, J. R. (1969). Computer Experiments with Fractional Gaussian Noises: Part 2, Rescaled Ranges and Spectra. Water Resources Research, 5(1), 242–259. https://doi.org/10.1029/WR005i001p00242 Martín de Diego, I., Siordia, O. S., Fernández-Isabel, A., Conde, C., & Cabello, E. (2019). Subjective data arrangement using clustering techniques for training expert systems. Expert Systems with Applications, 115, 1–15. https://doi.org/https://doi.org/10.1016/j.eswa.2018.07.058 Millan, G., Juan, E. S., & Jamett, M. (2014). A simple estimator of the Hurst exponent for self-similar traffic flows. IEEE Latin America Transactions, 12(8), 1349–1354. https://doi.org/10.1109/TLA.2014.7014500 Morabito, R., Kjällman, J., & Komu, M. (2015). Hypervisors vs. lightweight virtualization: A performance comparison. In Proceedings - 2015 IEEE International Conference on Cloud Engineering, IC2E 2015 (pp. 386–393). https://doi.org/10.1109/IC2E.2015.74 Nakanishi, Y. J., & Falcocchio, J. C. (2004). PERFORMANCE ASSESSMENT OF INTELLIGENT TRANSPORTATION SYSTEMS USING DATA ENVELOPMENT ANALYSIS. Research in Transportation Economics, 8, 181–197. https://doi.org/https://doi.org/10.1016/S0739-8859(04)08009-6 Ni, L.-P., Ni, Z.-W., & Gao, Y.-Z. (2011). Stock trend prediction based on fractal feature selection and support vector machine. Expert Systems with Applications, 38(5), 5569–5576. https://doi.org/https://doi.org/10.1016/j.eswa.2010.10.079 Olesen, O. B., Petersen, N. C., & Podinovski, V. V. (2015). Efficiency analysis with ratio measures. European Journal of Operational Research, 245(2), 446–462. https://doi.org/https://doi.org/10.1016/j.ejor.2015.03.013 Olesen, O. B., Petersen, N. C., & Podinovski, V. V. (2017). Efficiency measures and computational approaches for data envelopment analysis models with ratio inputs and outputs. European Journal of Operational Research, 261(2), 640–655. https://doi.org/https://doi.org/10.1016/j.ejor.2017.02.021 Oliveira, C., Kim, J. B., & Suda, T. (2003). Long-range dependence in IEEE 802.11b wireless LAN traffic: an empirical study. In 2002 14th International Conference on Ion Implantation Technology Proceedings (IEEE Cat. No.02EX505) (pp. 17–23). https://doi.org/10.1109/CCW.2003.1240784 Paxson, V., & Floyd, S. (1995). Wide Area Traffic: The Failure of Poisson Modeling. IEEE/ACM Transactions on Networking, 3(3), 226–244. https://doi.org/10.1109/90.392383 Popek, G. J., & Goldberg, R. P. (1974). Formal Requirements for Virtualizable Third Generation Architectures. Commun. ACM, 17(7), 412–421. https://doi.org/10.1145/361011.361073 161
Przystalski, K., & Ogorzałek, M. J. (2017). Multispectral skin patterns analysis using fractal methods. Expert Systems with Applications, 88, 318–326. https://doi.org/https://doi.org/10.1016/j.eswa.2017.07.011 Rastogi, V., Niddodi, C., Mohan, S., & Jha, S. (2017). New Directions for Container Debloating. In Proceedings of the 2017 Workshop on Forming an Ecosystem Around Software Transformation (pp. 51–56). New York, NY, USA: ACM. https://doi.org/10.1145/3141235.3141241 Rathore, M. (2013). KVM vs. LXC: Comparing Performance and Isolation of Hardware- assisted Virtual Routers. American Journal of Networks and Communications, 2, 88. Rathore, M. S., Hidell, M., & Sjödin, P. (2011). Data plane optimization in open virtual routers. In Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics) (Vol. 6640 LNCS, pp. 379–392). https://doi.org/10.1007/978-3-642-20757-0_30 Rizo, L., Torres, D., Dehesa, J., & Munoz, D. (2008). Cauchy Distribution for Jitter in IP Networks. https://doi.org/10.1109/CONIELECOMP.2008.39 Rosenblum, M., & Garfinkel, T. (2005). Virtual machine monitors: current technology and future trends. Computer, 38(5), 39–47. https://doi.org/10.1109/MC.2005.176 Sahoo, J., Mohapatra, S., & Lath, R. (2010). Virtualization: A survey on concepts, taxonomy and associated security issues. In 2nd International Conference on Computer and Network Technology, ICCNT 2010 (pp. 222–226). https://doi.org/10.1109/ICCNT.2010.49 Seiford, L., Charnes, A., W. Cooper, W., & A. Stutz, J. (1982). A Multiplicative Model for Efficiency Analysis. Socio-Economic Planning Sciences, 16, 223–224. Seiford, L. M., & Zhu, J. (1999). Infeasibility of super-efficiency data envelopment analysis models. Infor, 37(2), 174–187. https://doi.org/Http://Dx.Doi.Org/10.1080/03155986.1999.11732379 SMITH, R. D. (2011). THE DYNAMICS OF INTERNET TRAFFIC: SELF-SIMILARITY, SELF-ORGANIZATION, AND COMPLEX PHENOMENA. Advances in Complex Systems, 14(06), 905–949. https://doi.org/10.1142/S0219525911003451 Soltesz, S., Pötzl, H., Fiuczynski, M. E., Bavier, A., & Peterson, L. (2007). Container- based operating system virtualization: a scalable, high-performance alternative to hypervisors. ACM SIGOPS Operating Systems Review, 41(3), 275. https://doi.org/10.1145/1272998.1273025 Stein, A., Shi, W., & Bijker, W. (2008). Quality Aspects in Spatial Data Mining (1st ed.). Boca Raton, FL, USA: CRC Press, Inc. Thrall, R. M. (1996). Duality, classification and slacks in DEA. Annals of Operations Research, 66(2), 109–138. https://doi.org/10.1007/BF02187297 Valadkhani, A., Roshdi, I., & Smyth, R. (2016). A Multiplicative Environmental DEA approach to measure efficiency changes in the world’s major polluters. Energy Economics (Vol. 54). https://doi.org/10.1016/j.eneco.2015.12.018 Wang, D., Ren, C., Govindan, S., Sivasubramaniam, A., Urgaonkar, B., Kansal, A., & 162
Vaid, K. (2013). ACE: Abstracting, characterizing and exploiting datacenter power demands. In 2013 IEEE International Symposium on Workload Characterization (IISWC) (pp. 44–55). https://doi.org/10.1109/IISWC.2013.6704669 Weron, R. (2002). Estimating long-range dependence: Finite sample properties and confidence intervals. Physica A: Statistical Mechanics and Its Applications, 312(1– 2), 285–299. https://doi.org/10.1016/S0378-4371(02)00961-5 Whaiduzzaman, M., Gani, A., Anuar, N. B., Shiraz, M., Haque, M. N., & Haque, I. T. (2014). Cloud service selection using multicriteria decision analysis. The Scientific World Journal. https://doi.org/10.1155/2014/459375 Williams, D. E. (2007). Virtualization with Xen(Tm): Including XenEnterprise, XenServer, and XenExpress: Including XenEnterprise, XenServer, and XenExpress. Syngress Publishing. Wisitpongphan, N., & Peha, J. M. (2003). Effect of TCP on self-similarity of network traffic. In Proceedings. 12th International Conference on Computer Communications and Networks (IEEE Cat. No.03EX712) (pp. 370–373). https://doi.org/10.1109/ICCCN.2003.1284196 Xue, M., & Harker, P. T. (2002). Note: Ranking DMUs with Infeasible Super-Efficiency DEA Models. Management Science, 48(5), 705–710. https://doi.org/10.1287/mnsc.48.5.705.7805 Yan, W. (2005). Measuring the Histogram Feature Vector for Anomaly Network Traffic BT - Computational Intelligence and Security. In Y. Hao, J. Liu, Y.-P. Wang, Y. Cheung, H. Yin, L. Jiao, … Y.-C. Jiao (Eds.) (pp. 279–284). Berlin, Heidelberg: Springer Berlin Heidelberg. Ye, L., Zhang, H., Shi, J., & Du, X. (2012). Verifying cloud Service Level Agreement. In 2012 IEEE Global Communications Conference (GLOBECOM) (pp. 777–782). https://doi.org/10.1109/GLOCOM.2012.6503207 Zhao, X., Shen, L., Peng, X., & Zhao, W. (2015). Toward SLA-constrained service composition: An approach based on a fuzzy linguistic preference model and an evolutionary algorithm. Information Sciences, 316, 370–396. https://doi.org/10.1016/J.INS.2014.11.016 Zhou, S., Han, J., & Tang, H. (2011). Fractal Traffic Analysis and Applications in Industrial Control Ethernet Network BT - Emerging Research in Artificial Intelligence and Computational Intelligence. In H. Deng, D. Miao, F. L. Wang, & J. Lei (Eds.) (pp. 34–42). Berlin, Heidelberg: Springer Berlin Heidelberg.
163
APÊNDICE A – ANÁLISE EXPLORATÓRIA DOS DADOS
Para se chegar a uma conclusão inicial, de que o tráfego TCP nas redes virtuais é AS com LRD, foi realizada uma extensa análise exploratória das séries temporais por hipervisor de rede. O objetivo deste apêndice é apresentar mais uma contribuição deste trabalho doutoral, relacionado à avaliação de alguns gráficos das DMUs mais eficientes, segundo os modelos multiplicativos DEA desenvolvidos por este trabalho. A primeira ferramenta, o histograma, exibe um grau de variabilidade dos dados mostrando a distribuição de frequências em forma de barras. Nesta ferramenta, pode- se obter a FDP que mais se adequa aos dados, i.e., às variáveis aleatórias contínuas de cada série temporal por DMU. O periodograma captura a densidade espectral, para detectar cada periodicidade nos dados e analisar os picos das variáveis aleatórias contínuas ao longo do tempo.
O gráfico ACF mostra a relação entre os valores de e , em intervalos de tempo para analisar o comportamento das escalas de tempo. Assim, uma correlação positiva é um sinal de persistência, o que significa que um sistema tem a tendência de continuar um padrão do passado para o futuro. A existência de autocorrelação também deve ser usada para previsão e análise precisa de uma série temporal. A seguir serão exibidos os gráficos das DMUs consideradas mais eficientes ou supereficientes, segundo os modelos multiplicativos DEA estáticos ou dinâmicos, de acordo com os dois cenários de avaliação.
164
APÊNDICE B - CENÁRIO I – SMDEA CCR-O
Tabela 23 - Contendo respectivamente os gráficos do histograma, periodogramae ACF das DMUs mais eficientes segundo o modelo SMDEA CCR-O TOP 1 (única DMU SE) – DMU19 –FEDORA24 – VMWARE – LXC – GGC
Figura A1- PDF da DMU19 Figura A2 -Periodograma da DMU19 Figura A3 -Gráfico ACF da DMU19 TOP 2 – DMU48 – UBUNTU 16 – VMWARE – LXC – GGC
Figura A4 - PDF da DMU48 Figura A5 -Periodograma da DMU48 Figura A6 - Gráfico ACF da DMU48
165
APÊNDICE C - CENÁRIO I – WMDEA – CRS CCR-I
Tabela 24 - Contendo respectivamente os gráficos do histograma, periodogramae ACF das DMUs mais eficientes, segundo o modelo WMDEA CCR-I, em cada uma das dez séries temporais usadas para análise em janelas TOP 1 – DMU50 –UBUNTU 16 – VMWARE – LXC – GGC – SÉRIE TEMPORAL #1
Figura A7 - PDF da DMU50#1 Figura A8 - Periodograma da DMU50#1 Figura A9 - Gráfico ACF da DMU50#1 TOP 1 – DMU50 –UBUNTU 16 – VMWARE – LXC – GGC – SÉRIE TEMPORAL #2
Figura A10 - PDF da DMU50#2 Figura A20 - Periodograma da DMU50#2 Figura A31 -Gráfico ACF da DMU50#2
166
TOP 1 – DMU50 – UBUNTU 16 – VMWARE – LXC – GGC – SÉRIE TEMPORAL #3
Figura A12 - PDF da DMU50#3 Figura A43 - Periodograma da DMU50#3 Figura A5 4 - Gráfico ACF da DMU50#3 TOP 1 – DMU50 – UBUNTU 16 – VMWARE – LXC – GGC – SÉRIE TEMPORAL #4
Figura A15 - PDF da DMU50#4 Figura A66 - Periodograma da DMU50#4 Figura A77 - Gráfico ACF da DMU50#4 TOP 1 – DMU50 –UBUNTU 16 – VMWARE – LXC – GGC – SÉRIE TEMPORAL #5
Figura A18 - PDF da DMU50#5 Figura A89 -Periodograma da DMU50#5 Figura A20 - Gráfico ACF da DMU50#5
167
TOP 1 – DMU50 – UBUNTU 16 – VMWARE – LXC – GGC – SÉRIE TEMPORAL #6
Figura A21 - PDF da DMU50#6 Figura A22 - Periodograma da DMU50#6 Figura A23 - Gráfico ACF da DMU50#6 TOP 1 – DMU50 – UBUNTU 16 – VMWARE – LXC – GGC – SÉRIE TEMPORAL #7
Figura A24 - PDF da DMU50#7 Figura A25 - Periodograma da DMU50#7 Figura A26 - Gráfico ACF da DMU50#7
168
TOP 1 – DMU50 – UBUNTU 16 – VMWARE – LXC – GGC – SÉRIE TEMPORAL #8
Figura A27- PDF da DMU50#8 Figura A28 - Periodograma da DMU50#8 Figura A29 - Gráfico ACF da DMU50#8 TOP 1 – DMU50 – UBUNTU 16 – VMWARE – LXC – GGC – SÉRIE TEMPORAL #9
Figura A30 - PDF da DMU50#9 Figura A31 - Periodograma da DMU50#9 Figura A32 - Gráfico ACF da DMU50#9
169
TOP 1 – DMU50 – UBUNTU 16 – VMWARE – LXC – GGC – SÉRIE TEMPORAL #10
Figura A33 - PDF da DMU50#10 Figura A34 - Periodograma da DMU50#10 Figura A35 - Gráfico ACF da DMU50#10 TOP 2 – DMU20 – FEDORA24 – VMWARE – LXC – GGC – SÉRIE TEMPORAL #1
Figura A36 - PDF da DMU20#1 Figura A37 - Periodograma da DMU20#1 Figura A38 - Gráfico ACF da DMU20#1
170
TOP 2 – DMU20 – FEDORA24 – VMWARE – LXC – GGC – SÉRIE TEMPORAL #2
Figura A39 - PDF da DMU20#2 Figura A40 - Periodograma da DMU20#2 Figura A41 - Gráfico ACF da DMU20#2
TOP 2 – DMU20 – FEDORA24 – VMWARE – LXC – GGC – SÉRIE TEMPORAL #3
Figura A42 - PDF da DMU20#3 Figura A43 - Periodograma da DMU20#3 Figura A44 - Gráfico ACF da DMU20#3
171
TOP 2 – DMU20 – FEDORA24 – VMWARE – LXC – GGC – SÉRIE TEMPORAL #4
Figura A45 - PDF da DMU20#4 Figura A46 - Periodograma da DMU20#4 Figura A47 - Gráfico ACF da DMU20#4 TOP 2 – DMU20 – FEDORA24 – VMWARE – LXC – GGC – SÉRIE TEMPORAL #5
Figura A48 - PDF da DMU20#5 Figura A49 - Periodograma da DMU20#5 Figura A50 - Gráfico ACF da DMU20#5
172
TOP 2 – DMU20 – FEDORA24 – VMWARE – LXC – GGC – SÉRIE TEMPORAL #6
Figura A51 - PDF da DMU20#6 Figura A52 - Periodograma da DMU20#6 Figura A53 - Gráfico ACF da DMU20#6 TOP 2 – DMU20 – FEDORA24 – VMWARE – LXC – GGC – SÉRIE TEMPORAL #7
Figura A54 - PDF da DMU20#7 Figura A55 - Periodograma da DMU20#7 Figura A56 - Gráfico ACF da DMU20#7
173
TOP 2 – DMU20 – FEDORA24 – VMWARE – LXC – GGC – SÉRIE TEMPORAL #8
Figura A57 - PDF da DMU20#8 Figura A58 - Periodograma da DMU20#8 Figura A59 - Gráfico ACF da DMU20#8 TOP 2 – DMU20 – FEDORA24 – VMWARE – LXC – GGC – SÉRIE TEMPORAL #9
Figura A60 - PDF da DMU20#9 Figura A61 -Periodograma da DMU20#9 Figura A62 -Gráfico ACF da DMU20#9
174
TOP 2 – DMU20 – FEDORA24 – VMWARE – LXC – GGC – SÉRIE TEMPORAL #10
Figura A63 - PDF da DMU20#10 Figura A64 - Periodograma da DMU20#10 Figura A65 - Gráfico ACF da DMU20#10
Outra ilustração gráfica do comportamento fractal ao longo do tempo, pode ser vista observando o padrão de volatilidade de séries temporais de três DMUs selecionadas que foram agregadas em 600 segundos, como exemplos de efeito suave, fBM e irregular em um intervalo de tempo. Observe que, na Figura A66, as médias da largura de banda do TCP são mais estáveis, ou seja, os picos são mais regulares. Na Figura A67 há um padrão de tráfego altamente aleatório, caracterizando um processo estocástico caótico, e a Figura A68 apresenta um efeito irregular (burstiness), porque as médias são irregulares ao longo do tempo. Além disso, observe o efeito da dimensão fractal nas três imagens das Figuras A66, A67 e A68 com uma interpretação semelhante como em Mandelbrot (1982). Logo, quando D aumenta seu valor, detalhes invisíveis do tráfego de rede virtual tornam-se muito aparentes, em vez de mais separados quando D diminui, tal como aumentar a resolução de uma imagem quando D é maior e reduzi-la quando D é menor. Ademais, as Figuras A66, A67 e A68 são interessantes para a demonstração da importância da predição dos melhores serviços TCP em redes virtuais, não apenas segundo a dimensão fractal, mas relacionada às três variáveis fractais utilizadas nesta pesquisa para otimização de redes que buscam eleger uma DMU com desempenho maior da largura de banda do TCP, sendo estável por um longo período de tempo. Enfim, atente para comparação entre asDMUs com diferentes padrões da estrutura fractal do tráfego TCP nas figuras adiante.
175
Figura A66 - Tráfego TCP estável
Figura A67 - Tráfego TCP próximo do padrão fBM
Figura A68 -Tráfego TCP irregular
176
APÊNDICE D - CENÁRIO II – SUPER-COBB-DOUGLAS CCR-I
Tabela 25 - Contendo respectivamente os gráficos do Histograma, Periodograma e ACF das DMUs mais eficientes segundo o modelo Super-Cobb-Douglas CCR-I TOP 1 – DMU114 – Ubuntu14 – ESXI 6.5 – GGC – VMXNET3 – Docker – 1vCPU – 2GB VRAM
Figura A69 - PDF da DMU114 Figura A70 - Periodograma da DMU114 Figura A71 - Gráfico ACF da DMU114
TOP 2 – DMU165 – Ubuntu14 – ESXI 6.5 – GGC – VMXNET3 – LXC – 4vCPU – 1GB VRAM
Figura A72 - PDF da DMU48 Figura A73 - Periodograma da DMU48 Figura A74 - Gráfico ACF da DMU48