diff --git a/docs/PropuestaInstanciaModuloTaller_OpenStack.odt b/docs/PropuestaInstanciaModuloTaller_OpenStack.odt
new file mode 100644
index 0000000000000000000000000000000000000000..cbd58630f06081924ef6911ddfd00a179bfd2ae1
Binary files /dev/null and b/docs/PropuestaInstanciaModuloTaller_OpenStack.odt differ
diff --git a/docs/installation b/docs/installation
index 3723c771faf222ce42657e9996920e0844000416..c5a18bb57933ef817912e7c5608d82ccd1fe5af0 100644
--- a/docs/installation
+++ b/docs/installation
@@ -86,7 +86,7 @@ Pasos para llevar a cabo la instalación de Openstack Ansible
-- 3.6) Instalar herramientas auxiliares:
$ yum install bridge-utils iputils lsof lvm2 ntp ntpdate openssh-server sudo tcpdump python net-tools nano
--- 3.7) Desahabilitar el Network Manager:
+-- 3.7) Deshabilitar el Network Manager:
$ chkconfig NetworkManager off
$ chkconfig network on
$ service NetworkManager stop
diff --git a/docs/latex/report.pdf b/docs/latex/report.pdf
index c5bf60197f8c4d0a9bcb6d34daf93cc86af051c1..1fc0e9ca0c2114da47a4bc0553f8b6a26b2ea534 100644
Binary files a/docs/latex/report.pdf and b/docs/latex/report.pdf differ
diff --git a/docs/latex/report.tex b/docs/latex/report.tex
index 2b979acc882f917fed5fda8127622aa54b7a741a..f5db54db7118c436d7995ebcf7eef36533760f6d 100644
--- a/docs/latex/report.tex
+++ b/docs/latex/report.tex
@@ -1,4 +1,4 @@
-\documentclass[a4paper, 10pt]{article}
+\documentclass[a4paper, 10pt]{report}
%% Language and font encodings
\usepackage[spanish]{babel}
@@ -21,10 +21,20 @@
\usepackage[colorlinks=true, allcolors=black]{hyperref}
+\addto\captionsspanish{% Replace "english" with the language you use
+ %% Cambio el nombre del Ãndice
+ \renewcommand{\contentsname}{Ãndice}
+ %% Remuevo la palabra capÃtulo de los tÃtulos
+ \renewcommand{\chaptername}{}
+}
+
+
+\renewcommand{\chaptername}{}
+
\title{Despliegue de un Datacenter con Openstack}
\author{MatÃas Capucho, Santiago Elizondo \\
Universidad de la República, Montevideo, Uruguay. \\
- Email: \href{mailto:matias.capucho@fing.edu.uy}{selizondo@fing.edu.uy}, \href{mailto:santiago.elizondo@fing.edu.uy}{santiago.elizondo@fing.edu.uy} }
+ Email: \href{mailto:matias.capucho@fing.edu.uy}{matias.capucho@fing.edu.uy}, \href{mailto:selizondo@fing.edu.uy}{selizondo@fing.edu.uy} }
\date{4 de Junio de 2019}
@@ -35,571 +45,261 @@
\maketitle
\begin{abstract}
-El presente documento relata el proceso de diseño, instalación, y configuración básica de un Datacenter mediante la utilización de Openstack. Durante el mismo se especifican los pasos necesarios a seguir y se detallan puntos sumamente relevantes a tener en cuenta.
+El presente documento estudia los aspectos fundamentales de la plataforma Openstack. A su vez, relata el proceso de diseño, instalación, y configuración básica de un Datacenter mediante la utilización de dicha plataforma. Se especifican los pasos necesarios a seguir y se detallan puntos sumamente relevantes a tener en cuenta.
\end{abstract}
-\section{Introducción}
-En la actualidad es muy común encontrar redes inalámbricas IEEE 802.11 (WiFi) en la mayorÃa de los sitios urbanos. Estas redes tienden a ser denominadas de alta densidad debido a la gran cantidad de Access-Points (AP) cuyas áreas de cobertura se encuentran solapadas. Generalmente, la disposición de los AP no es planificada adecuadamente y sumado a la alta y fija potencia de transmisión de todos estos dispositivos genera que la calidad del servicio y el ancho de banda se vean altamente perjudicados. Esto impacta directamente en los usuarios que demandan un servicio de alta velocidad.\\
+\tableofcontents
-Para lidiar con este problema existen diversos algoritmos que intentan regular de forma personalizada la tasa y la potencia de transmisión (rate y power) para cada terminal asociada al AP. El estándar IEEE 802.11 permite modificar estas variables pero no define cómo se deben tomar las decisiones de modificación. Dentro de los algoritmos mencionados, pondremos foco en el Robust Rate and Power Adaptation Algorithm (RRPAA) diseñado por MatÃas Richart como parte de su tésis de MaestrÃa \cite{tesis} y analizaremos su comportamiento para ajustar y mejorar el desempeño del mismo.
-
-\section{Análisis inicial}
-\subsection{Algoritmo RRPAA}
-El RRPAA tiene por objetivo central minimizar el power y maximizar el rate que en conjunto maximizan el throughput para cada sesión entre el AP y sus terminales asociadas. Para esto, se intenta mantener el porcentaje de pérdida de tramas, denominado Frame Loss Rate (FLR), dentro de determinado rango para una cierta ventana de tramas enviadas. Durante la sesión entre ambos terminales se recolecta información estadÃstica que permite determinar el valor del FLR y compararlo contra dos valores lÃmites:
-\begin{itemize}
- \item Maximum Tolerable Loss (MTL)
- \item Opportunistic Rate Increase (ORI)
-\end{itemize}
-
-Estos valores servirán de referencia para tomar las decisiones a la hora de bajar y subir de estado. Los estados consisten en los pares (power, rate) asociados a la transmisión entre las terminales y son ordenados de forma que un mayor estado implica menor power y mayor rate. El pseudocódigo asociado al orden entre estados puede verse en el algoritmo \ref{alg1}.
-
-\begin{algorithm}[H]
- \floatname{algorithm}{Algoritmo}
- \caption{Orden entre estados}
- \label{alg1}
- \begin{multicols}{2}
- \begin{algorithmic}[1]
- \IF{$p_{0} == p_{max}$}
- \STATE $anterior(r_{0}, p_{0}) = (r_{-1}, p_{0})$
- \ELSE
- \STATE $anterior(r_{0}, p_{0}) = (r_{0}, p_{1})$
- \ENDIF
- \end{algorithmic}
- \begin{algorithmic}[1]
- \IF{$r_{0} < r_{max}$}
- \STATE $siguiente(r_{0}, p_{0}) = (r_{1}, p_{0})$
- \ELSE
- \STATE $siguiente(r_{0}, p_{0}) = (r_{0}, p_{-1})$
- \ENDIF
- \end{algorithmic}
- \end{multicols}
-\end{algorithm}
-
-Debido a que el medio de transmisión entre dos terminales puede variar continuamente afectando la estabilidad del algoritmo, se define un mecanismo llamado Probabilistic Rate Increase que busca asegurar la convergencia del mismo. Se maneja entonces una tabla de probabilidades que mantiene la probabilidad de ingresar a cada uno de los estados previamente definidos.\\
-Cuando durante la transmisión se dan demasiadas pérdidas y el RRPAA decide pasar a un estado anterior, utilizará previamente una variable aleatoria que comparará contra la probabilidad del estado al que quiere acceder. En caso de caer dentro de la probabilidad, luego de bajar de estado bajará la probabilidad de todos los estados superiores para evitar volver facilmente a una situación con alta tasa de pérdidas.\\
-Análogamente, luego de alcanzar un estado superior se sube la probabilidad de todos los estados anteriores para volver rápidamente en caso de que se produzca un exceso de pérdidas.\\
-
-\begin{algorithm}[H]
- \floatname{algorithm}{Algoritmo}
- \caption{Pseudocódigo RRPAA}
- \label{alg2}
- \begin{algorithmic}[1]
- \IF{$FLR > MTL(rate)$ \AND $power < maxPower$}
- \STATE {$priTable[rate][power] /= \gamma$}
- \STATE {$power++$}
- \ELSIF {$FLR > MTL(rate)$ \AND $power == maxPower$}
- \STATE {$priTable[rate][power] /= \gamma$}
- \STATE {$rate--$}
- \ENDIF
- \IF{$FLR < ORI(rate)$}
- \FORALL {$r < rate$}
- \STATE {$priTable[r][power] *= \delta$}
- \ENDFOR
- \IF {$rate < maxRate$ \AND $rand() < priTable[rate+1][power]$}
- \STATE {$rate++$}
- \ELSE
- \FORALL {$p > power$}
- \STATE {$priTable[rate][p] *= \delta$}
- \ENDFOR
- \IF {$power > 0$ \AND $rand() < priTable[rate][power-1]$}
- \STATE {$power--$}
- \ENDIF
- \ENDIF
- \ELSIF {$FLR >= ORI(rate)$ \AND $loss < MTL(rate)$ \AND $power > 0$}
- \FORALL {$p > power$}
- \STATE {$priTable[rate][p] *= \delta$}
- \ENDFOR
- \IF {$power > 0$ \AND $rand() < priTable[rate][power-1]$}
- \STATE {$power--$}
- \ENDIF
- \ENDIF
- \end{algorithmic}
-\end{algorithm}
-
-El pseudocódigo del algoritmo utilizado por el RRPPA se encuentra en el algoritmo \ref{alg2}. Mientras que un resumen del comportamiento del mismo puede apreciarse en la figura \ref{flr}.
-
-\begin{figure}[H]
- \centering
- \includegraphics[width=0.8\columnwidth]{linea_flr}
- \caption{Decisiones tomadas segun FLR}
- \label{flr}
-\end{figure}
-
-Una descripción mas detallada de su comportamiento puede encontrarse en \cite{proyecto}, \cite{tesis} y \cite{articulo}.
-
-
-\subsection{Implementación}
-El algoritmo RRPAA fue implementado en hardware como parte del proyecto de grado de MatÃas Irland y Jorge Artave en marco de la carrera IngenierÃa en Computación de la Facultad de IngenierÃa, UdelaR \cite{proyecto}. Para su desarrollo se utilizó como base la implementación existente de Minstrel incluida en el kernel de OpenWrt. Minstrel se trata de un algoritmo de control de rate que basa su comportamiento en la recolección de estadÃsticas mediante el envÃo de tramas de sondeo. No entraremos en mayor detalle sobre este algoritmo pero cabe mencionar que suele ser el estándar incluido en las distribuciones de OpenWrt.\\
-
-La implementación de RRPAA fue realizada sobre el driver Ath9k desarrollado por Qualcomm Atheros para controladores WiFi y basada en el estándar IEEE 802.11g.\\
-El código implementado se encuentra en tres archivos dentro del módulo kmod-mac80211:
-\begin{itemize}
- \item \textbf{rc80211\_rrpaa.h}: Definición de constantes y estructuras a utilizar y funciones a ser utilizadas por otros archivos del módulo.
- \item \textbf{rc80211\_rrpaa.c}: Implementación del algoritmo.
- \item \textbf{rc80211\_rrpaa\_debugfs.c}: Funciones para la recolección de datos estadÃsticos.
-\end{itemize}
+\chapter{Introducción}
+Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged. It was popularised in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages, and more recently with desktop publishing software like Aldus PageMaker including versions of Lorem Ipsum.\cite{tesis}
-El ciclo de la ejecución consta de cuatro etapas bien definidas:
-\subparagraph{Inicialización}En primer lugar se da la inciailización de las estructuras reservando la memoria necesaria para mantener la sesión con cada terminal cada vez que uno de estos se asocia al AP. Dentro de esta etapa se define el rango de rates y powers soportados por ambos terminales, se calculan los valores de ORI y MTL y se inicializa la tabla de probabilidades asociada.
-\subparagraph{Recolección de datos}La siguiente etapa se trata de la recolección de datos. Esta consiste en almacenar la cantidad de intentos realizados y exitosos para cada estado asociado luego del envÃo de cada paquete. Esta información es utilizada posteriormente para la ejecucción del algoritmo antes descrito.
-\subparagraph{Toma de decisiones}La tercera etapa se denomina toma de decisiones, es aquà en donde se ejecuta explÃcitamente el algoritmo diseñado y se determina en función de los datos previamente recolectados y de la tabla de probabilidades, cuál será el próximo estado a ser utilizado en la transmisión de las restantes tramas. Para manejar adecuadamente la representación númerica del kernel, se mapearon las probalidades en el rango $(0,1]$ al rango $[1,4096]$, aplicando un shifteo a la izquierda de doce posiciones.
-\subparagraph{Asignación}Finalmente, se asignan las parejas de rate y power asociadas a la retry chain para la próxima transmisión. La retry chain se trata de una estructura de datos que almacena los parámetros a utilizar en cada intento de transmisión de una trama. En este caso, la cadena tendrá largo 4 y almacenará los pares $(rate, power)$ y la cantidad $c$ de intentos posibles a utilizar hasta saltar al siguiente valor de la cadena. En caso de que se den mas de $c$ pérdidas durante el envÃo de la trama, se intentará enviar con los valores de la siguiente posición y asà sucesivamente hasta el final de la misma. Este mecanismo busca disminuir el overhead necesario para el cálculo del valor de las variables en caso de pérdidas. En esta implementación, los siguientes valores de la retry chain serán calculados en función del estado determinado por RRPAA siguiendo el pseudocódigo \ref{alg3}. Cabe resaltar que para la última posición de la cadena se optó por asignar el menor estado posible (power máximo y rate mÃnimo) con el fin de asegurar el envÃo de la trama en cuestión.
-
-\begin{algorithm}[H]
- \floatname{algorithm}{Algoritmo}
- \caption{Asignación de valores a la retry chain}
- \label{alg3}
- \begin{algorithmic}[1]
- \WHILE {$can\_add\_items\_to\_retry\_chain$}
- \IF {$power < p_{max}$}
- \STATE {$power = next_power$}
- \ELSIF {$rate > rate_{min}$}
- \STATE {$rate = previous_rate$}
- \ENDIF
- \ENDWHILE
- \end{algorithmic}
-\end{algorithm}
-
-\section{Detección de errores}
-Luego de tener claro el diseño del algoritmo RRPAA y de analizar la implementación en hardware del mismo, se detectaron ciertas inconsistencias en el código que no seguÃan fielmente la idea original. Estos errores podrÃan generar que los resultados obtenidos durante las pruebas no fueran significativos y por ende requerÃan de su correción para poder continuar con el proyecto.\\
-A continuación se detallan los errores detectados según la función correspondiente y su solución aplicada.
-
-\subparagraph{\textbf{rrpaa\_tx\_status}} Uno de los primeros errores se daba durante la recolección de datos. EspecÃficamente en la función $rrpaa\_tx\_status$ encargada de recorrer la retry chain y determinar para cada rate la cantidad de intentos realizados y exitosos en caso de que corresponda. El error se debÃa a que si la trama se habÃa transmitido con éxito, se sumaba 1 a la cantidad de éxitos de los rates de la cadena que se posicionaban desde el inicio hasta el verdadero rate exitoso. Para corregirlo se sumó correctamente sólo al rate que efectivamente obtuvo un éxito en la retry chain.
-
-\subparagraph{\textbf{rrpaa\_update\_stats}} Los siguientes errores se corresponden todos a la etapa de toma de decisiones. La función $rrpaa\_update\_stats$ es la responsable de ejecutar el algoritmo \ref{alg2} pero luego de analizarla se detectaron cuatro errores importantes que no seguÃan la idea original, todos estos se detallan a continuación:
+\chapter{Marco teórico}
+A continuación se presentan conceptos introductorios relevantes para comprender el estudio que se desarrollará más adelante en el informe.
+\section{Cloud computing}
+Cloud computing resulta ser un modelo que involucra tanto a los servicios computacionales provistos a los clientes a través de Internet, como a la implementación de hardware y software que logra proveerlos. Esta implementación se aloja en los denominados datacenters, que integran adecuadamente los diversos recursos tales como redes, servidores, almacenamiento y software necesarios para ofrecer los mencionados servicios en función de la demanda.
+Este modelo computacional, impulsado durante el siglo 21, ha evolucionado velozmente y ha migrado el mundo de TI de las antiguas PCs locales de usuarios y de los cuartos de servidores empresariales a la llamada “nube†alojada en lejanos datacenters.\\
+Según la definición brindada por The National Institute of Standards and Technology (NIST) [7], la computación en la nube debe cumplir con 5 caracterÃsticas esenciales:
\begin{itemize}
-\item Al momento de tomar la decisión de cambio de estado, se recorrÃa todo el arreglo de rates manejado con la terminal y se aplicaba el algoritmo múltiples veces ya que se consideraba el FLR de cada uno de estos. Esto no es correcto ya que para determinar las transiciones entre estados, sólo se debe tener en cuenta el estado actual y no todos los posibles. La solución consistió en seguir estrictamente el pseudocódigo planteado y utilizar solo el estado actual para tomar la decisión.
-
-\item Cuando el algoritmo planteado debÃa aumentar de estado bajando el power, se utilizaba la probabilidad del estado anterior subiendo el power. Este posiblemente fuera un error de tipeo al colocar un $+$ en lugar de un $-$ pero afectaba significativamente el uso de la tabla de probabilidades para la convergencia del algoritmo. Su correción fue trivial.
-
-\item Cuando el estado actual contenÃa el máximo power posible y se debÃa aumentar el estado bajando esta variable, no se consultaba la tabla de probabilidades para tomar la decisión. Esta determinación no se encuentra en lo especificado por el pseudocódigo y por lo tanto fue removida.
-
-\item Además de tomar las decisiones de transición entre estados, esta función se encarga de actualizar los datos históricos de intentos realizados y exitosos para cada rate y bajar a cero los contadores correspondientes. Esto se realiza cada vez que se ejecuta el $rrpaa\_update\_stats$, sin embargo la bajada a cero de estos contadores solo se estaba realizando para aquellos rates que habÃan alcanzado el tamaño de ventana requerido para ejecutar el algoritmo en función del FLR. Esto generaba que en los datos históricos aparecieran cantidades mucho mayores que las reales debido a que se sumaban al mismo los mismos intentos más de una vez. Su correción consistió en bajar explÃcitamente estas variables para todos los rates al final de la función.
+ \item \textbf{On-demand self-service}: los servicios alojados deben poder obtener capacidad de cómputo a demanda, consumiendo los recursos requeridos y sin que exista interacción humana con proveedores.
+ \item \textbf{Broad network access}: los servicios deben encontrarse disponibles a través de la red y accesibles mediante mecanismos estándares.
+ \item \textbf{Resource pooling}: los recursos computacionales se mantienen en grupos pudiendo ser asignados a múltiples consumidores en forma dinámica según la demanda necesaria.
+ \item \textbf{Rapid elasticity}: los recursos deben poder escalar en forma sencilla e incluso automática en función de la demanda. De esta forma, los consumidores de servicios tendrán una visión de la nube como una fuente de recursos ilimitada.
+ \item \textbf{Resource pooling}: los recursos consumidos deben ser monitorizados y medidos con un determinado nivel de abstracción en función del servicio provisto. Deben existir reportes de consumo que brinden absoluta transparencia tanto al proveedor como al consumidor.
\end{itemize}
-\section{Escenarios de prueba}
-El objetivo de estos escenarios consiste en analizar el comportamiento de RRPAA en comparación con Minstrel en tres situaciones muy distintas entre sÃ. En una primera instancia se analizará un escenario simple. En él se plantea evaluar el comportamiento de un router emisor con un nodo receptor a medida que se aumenta y disminuye la distancia entre ellos.\\
-
-Para una segunda prueba se plantea un escenario mas adecuado al funcionamiento de RRPAA. En este existen dos routers transmitiendo información, cada uno a un nodo particular de forma que ambos routers generan interferencias entre sÃ. En este caso se busca verificar que el algoritmo reducirá el power utilizado para evitar interferencias innecesarias, obteniendo un canal más libre y limpio.\\
-
-Finalmente, se plantea un escenario que en la teorÃa revelarÃa una falla inevitable del algoritmo RRPAA. Este consiste en tener un nodo N1 asociado a un router R1 a una distancia significativamente amplia, generando que R1 utilice una potencia alta. Por otro lado, sobre la frontera del radio de alcance de R1, se encuentra otro router R2 asociado a un nuevo nodo N2 pero a una distancia muy cercana entre ambos.
+Estas propiedades ambiciosas demuestran que brindar un servicio de cloud no es para nada trivial y requiere grandes conocimientos de TI a la hora de diseñar y poner un marcha un datacenter.
-\subsection{Distancias}
-\label{Distancias_escenario}
-Con este escenario se busca analizar el comportamiento de la implementación de RRPAA en función de la distancia respecto al router, asà como evaluar el algoritmo en un escenario simple. Para esto se propone un escenario en donde se coloca un router y una terminal a una distancia inicial de 3 metros. Tras comenzar la prueba, se alejará el terminal una distancia de 6m cada 3 minutos hasta llegar a una distancia máxima de 63m. Luego de alcanzar esta distancia, se realizará el proceso inverso disminuyendo la misma en intervalos análogos hasta alcanzar el punto inicial.\\
-
-Esta prueba es realizada 10 veces con RRPAA y 10 veces con la implementación original de Minstrel. Por otro lado se utilizarán los resultados obtenidos en las primeras tiradas de la prueba en cuestión para realizar un ajuste inicial del algoritmo buscando mayor estabilidad y convergencia de los resultados.
-
-\begin{figure}[h]
- \centering
- \includegraphics[width=0.6\columnwidth]{diagrama_distancias}
- \caption{Diagrama del escenario distancias}
- \label{Distancias}
-\end{figure}
+En cuanto a los modelos de cloud computing, existen tres clasificaciones que se distinguen según el tipo de servicio provisto:
-\subparagraph{Resultado esperado}
-En este escenario es esperable que el rendimiento de ambos algoritmos sea similar, es decir, que tanto Minstrel como RRPAA garanticen el máximo throughput posible otorgado a un único cliente asociado. Además es esperable que el power utilizado incremente en cuanto se aumenta la distancia y decremente en el caso contrario. Debido a la disminución del power y tiempo de adaptación requerido para el funcionamiento de RRPAA, se espera que exista una tasa de pérdidas levemente superior en comparación con Minstrel.
-
-
-\subsection{Overlapping}
-En este escenario se busca analizar el comportamiento de RRPAA en un ambiente con conexiones solapadas, buscando simular un ambiente denso. Para esto se hará uso de dos terminales asociadas cada una a un router diferente.
-El experimento consistirá de varias etapas con el fin de cubrir los siguientes casos:
-\begin{itemize}
- \item no es posible aislar las transmisiones entre cada par de nodos
- \item es posible aislar las transmisiones entre cada par de nodos
-\end{itemize}
-
-Para llevar a cabo lo planteado, se colocará cada par (router, terminal) a diferentes distancias entre sÃ, en particular serán:
\begin{itemize}
- \item 3
- \item 6
- \item 18
- \item 36
- \item 66
+ \item \textbf{Software as a Service (SaaS)}: refiere al servicio que provee aplicaciones a través de internet que se encuentran corriendo en la infraestructura de la nube (datacenter). Los consumidores del servicio no manipulan la infraestructura subyacente ni las configuraciones de aplicación.
+ \item \textbf{Platform as a Service (Paas)}: consiste en proveer recursos a nivel de plataforma, como por ejemplo soporte de sistemas operativos, que permiten al cliente desplegar sus propias aplicaciones. El consumidor no puede manipular la infraestructura pero sà es capaz de manipular lo que se despliega sobre ella.
+ \item \textbf{Infrastructure as a Service (IaaS)}: se asocia al suministro de recursos de infraestructura a demanda. Se suele proveer al cliente de capacidad de procesamiento, almacenamiento y conectividad de red. TÃpicamente se ofrecen máquinas virtuales con la posibilidad de que el cliente manipule los sistemas operativos y las aplicaciones. Nuevamente el consumidor no es capaz de influir en la infraestructura que implementa la nube.
\end{itemize}
-Los terminales estarán a una distancia de 60cm de sus respectivos routers en todas las etapas.
-
-\begin{figure}[h]
-\centering
-\begin{subfigure}{.5\textwidth}
- \centering
- \includegraphics[width=.85\linewidth]{diagrama_overlapping_1}
- \caption{Es posible aislar transmisiones}
- \label{fig:sub1}
-\end{subfigure}%
-\begin{subfigure}{.5\textwidth}
- \centering
- \includegraphics[width=.5\linewidth]{diagrama_overlapping_2}
- \caption{No es posible aislar transmisiones}
- \label{fig:sub2}
-\end{subfigure}
-\caption{Diagrama del escenario overlapping}
-\label{overlapping}
-\end{figure}
-
-\subparagraph{Resultado esperado}
-En estos escenarios se esperan distintos comportamientos a medida que avanzan las etapas y por lo tanto se aumenta la distancia. En las distancias iniciales se espera un comportamiento similar en ambos algoritmos, con un degradamiento significativo en el throughput de los routers.
-Luego, a medida que alejamos los dispositivos se espera que las transmisiones mejoren debido a que las interferencias disminuirán. En estos casos RRPAA deberÃa mejorar más rápido que minstrel ya que puede regular la potencia y evitar aún más las interferencias.
-Llegando a la última prueba deberÃa ser insignificante las interferencias entre las transmisiones y el comportamiento de ambos routers se espera que sea similar.
-
-\subsection{Starvation problem}
-\label{Starvarion_Escenario}
-El algoritmo RRPAA busca ajustar los niveles de potencia con los que se envÃan los paquetes con el fin de evitar la interferencia en redes densas. Esta técnica puede mejorar la performance en algunos escenarios pero conducir la red a un problema de acceso injusto al medio.\\
-
-Para explicar el problema utilizaremos la figura \ref{starvation} que nos permitirá definir dos rangos distintos:
-\begin{itemize}
-\item \textbf{Rango de transmisión:} un receptor dentro del rango de transmisión de un emisor recibirá los paquetes satisfactoriamente, siempre que no haya interferencia.
-\item \textbf{Rango del Carrier Sense:} un nodo dentro del rango del carrier sense de un emisor podrá sensar si el medio está siendo ocupado cuando hay transmisiones. Entre otras cosas, esto depende de la potencia de transmisión del emisor y de los lÃmites del carrier sense del receptor.
-\end{itemize}
+\section{Virtualización}
+Uno de los principales conceptos que se encuentra involucrado en la implementación de cloud computing es el de virtualización [9][10]. Esta tecnologÃa permite simular diversos ambientes con recursos dedicados a partir de un solo sistema fÃsico. Es posible crear aplicaciones, servidores, almacenamiento y redes, utilizando al máximo todos los recursos del sistema subyacente aumentando el rendimiento general. Los usuarios finales interactúan directamente con las virtualizaciones, llamadas máquinas virtuales. Una máquina virtual puede ser transferida de un sistema host a otro y funcionar de igual forma.
+La implementación de esta tecnologÃa se da mediante los denominados \textbf{hipervisores} [9][11], los cuales se encargan de conectar los recursos fÃsicos de la máquina host con las máquinas virtuales. Estos trabajan sobre el sistema operativo o directamente en el hardware, creando una plataforma virtual, que divide los recursos fÃsicos, sobre la cual se ejecutan las diferentes virtualizaciones. Por otro lado también son responsables de crear ambientes aislados que brinden seguridad entre las máquinas virtuales.
\begin{figure}[H]
\centering
- \includegraphics[width=0.6\columnwidth]{diagrama_starvation}
- \caption{Diagrama del starvation problem}
- \label{starvation}
+ \includegraphics[width=0.4\columnwidth]{hypervisors}
+ \caption{Hipervisores}
+ \label{hiper}
\end{figure}
-En la figura anterior, T0 y T1 son los transmisores y N0 y N1 los receptores. Las flechas indican un flujo de transmisión, mientras que
-los cÃrculos cerrados y punteados representan los rangos de transmisión y de Carrier Sense respectivamente.
-La figura muestra un escenario en el que se genera un problema de terminal expuesta asimétrico. En el mismo, T0 puede sensar a T1 y por lo tanto podrá pausar su transmisión pero T1 no puede sensar a T0 por lo que transmitirá continuamente, generando un acceso al medio injusto.
-
-\subparagraph{Resultado esperado} Bajo estas condiciones se espera que RRPAA no sea capaz de evitar el Starvation problem y generar un acceso injusto al medio. En la teorÃa, el emisor T0 no serÃa capaz de transmitir hacia N0 debido a que T1 nunca liberarÃa el medio transmitiendo a un potencia mucho mas alta.
-
-\section{Scripts y herramientas}
-Para la ejecución de todas las pruebas realizadas, se utilizaron diversos scripts tanto a nivel del AP en el sistema OpenWrt como de los terminales Ubuntu asociados al mismo. También fueron requeridos scripts y herramientas para la recolección de datos estadÃsticos y su posterior análisis gráfico y para el registro de logs de debugging en el propio código. Cada uno de estos será descrito a continuación.
-
-\subsection{Scripts}
-\subparagraph{Access Point:}
-\begin{itemize}
-\item \textbf{clear\_log.sh:} su función es limpiar el registro de $time\_states$ almacenados hasta el momento para cada estación conectada al router.
-
-\item \textbf{list\_device.sh:} este script es utilizado para obtener las MAC de todas las estaciones que se encuentran asociadas al router.
-
-\item \textbf{live\_stats.sh:} utilizado para mostrar en consola la información obtenida por el $rc\_time\_state$ de una estación cuya MAC es pasada como parámetro.
-
-\item \textbf{macState.sh:} brinda información relativa a las frecuencias manejadas por el router.
-
-\item \textbf{save\_time\_state\_log.sh:} en primer lugar limpia los logs de cada estación al igual que en $clear\_log$. Luego, recorre cada estación asociada al router 35 veces y guarda la salida del $rc\_time\_state$ dentro del $/tmp/\$now/\$station$, donde now resulta ser una carpeta con la fecha y hora de cuando se lanzó el script y station es la MAC de cada estación.
-
-\item \textbf{install.sh:} instala en el AP los ipks con el algoritmo en cuestión colocados previamente en la carpeta $tmp$.
-
-\item \textbf{statistics.sh:} se encarga de registrar los datos obtenidos por el $rc\_time\_state$ de cada estación asociada al router dentro de una carpeta $logs/$ ubicada en una unidad USB montada en el directorio $/mnt/usb/$. Además, recibe como parámetro la cantidad de segundos que ejecutará la obtención de datos. Para hacer este control hace uso de la variable $SECONDS$ del sistema que retorna la cantidad de segundos desde que se ha comenzado a ejecutar el script.
-
-\item \textbf{time\_state.sh:} imprime en consola cada 1 seg la información obtenida por el $rc\_time\_states$ para una estación hardcodeada.
-
-\item \textbf{time\_state.sh:} imprime en consola cada 1 seg la información obtenida por el $rc\_stats$ para una estación hardcodeada.
-\end{itemize}
-
-
-\subparagraph{Terminal:}
+Los hipervisores se suelen clasificar en dos tipos:
\begin{itemize}
-\item \textbf{generate\_test\_rrpaa.sh:} utilizado para iniciar el flujo de tráfico necesario durante una prueba desde el AP hacia el terminal desde el que se ejecuta. Para esto utiliza la herramienta $iperf3$ \cite{iperf}.
-
-\item \textbf{calculate\_graph.py:} su función consiste en generar las gráficas correspondientes a los datos estadÃsticos obtenidos en cada prueba. Para esto hace uso de scripts auxiliares que generan los cálculos necesarios para obtener las gráficas finales mediante la herramienta $gnuplot$ \cite{gnuplot}.
-
+ \item \textbf{Nativos o bare metal}: se trata de software que corre directamente sobre el hardware del sistema host, controlando el hardware y monitoreando el sistema operativo invitado. Algunos ejemplos son Oracle VM, Microsoft Hyper-V, VMware ESXi y Xen.
+ \item \textbf{Alojados o hosted}: consisten en hipervisores que corren dentro de un sistema operativo tradicional. Se encuentran en una capa de aplicación por encima del sistema operativo del host pero por debajo del sistema operativo guest. Algunos ejemplos son Oracle VM VirtualBox, VMware Server y Workstation, Microsoft Virtual PC, KVM, QEMU y Parallels.
\end{itemize}
-\subsection{Herramientas}
-\subparagraph{iperf3:}\cite{iperf}
-Iperf3 se trata de una herramienta para la medición del máximo ancho de banda alcanzable en una red IP. Soporta la personalización de diversos parámetros como pueden ser el tiempo, buffers y protocolos utilizados. Para cada rest reporta, entre otros parámetros, el ancho de banda y la tasa de pérdidas. Esta herramienta fue utilizada para la generación de tráfico entre los terminales y los AP con un ancho de banda de 54Mb y flujo de paquetes UDP para evitar el overhead de la capa de transporte del protocolo TCP.
-
-\subparagraph{gnuplot:}\cite{gnuplot}
-Gnuplot consiste en una funcionalidad por lÃnea de comandos portable para realizar gráficas en Linux. Fue utilizada para el tratamiento gráfico de los datos recolectados durante cada prueba. Estos datos eran almacenados en un formato $.csv$ y utilizados por gnuplot para la generación de gráficas que contienen la cantidad de intentos realizados, los exitosos, la tasa de pérdidas, los rate y powers utilizados y el ancho de banda, entre otros.
-
-\subparagraph{kprint:}\cite{kprint}
-\label{Kprint}
-Kprint es un comando que permite escribir en los logs del sistema. La salida generada por el mismo puede ser dirigida a un archivo o directamente a memoria. Para configurar la herramienta se siguieron los pasos mencionados en la referencia. Se debe tener en cuenta que en caso de utilizar un archivo, es importante que su tamaño sea muy chico debido a la escasa memoria del router. Una de las ventajas de utilizar estos logs es que permanecen intactos en los casos en que el dispositivo se crashea por algún error inesperado, siendo muy útil para debbugear lo desarrollado.
-
-\subparagraph{aircrack-ng}\cite{aircrack}
-\label{aircrack}
-Aircrack-ng es una suite de herramientas por lÃnea de comandos que permite evaluar la seguridad de una red wifi. De las herramientas ofrecidas se utilizaron dos: airmon-ng y airodump-ng. La primera fue utilizada para habilitar el modo monitor en la tarjeta de red inalámbrica y la segunda permite visualizar información de las redes wifi detectadas como el essid, bssid, channel, privacy, beacons, data, etc. También muestra información sobre los clientes conectados a dichas redes. Esta herramienta se utilizó para el escenario de Starvation problem, en donde era necesario conocer la distancia a la cual la señal del router que envÃa a potencia mÃnima no es detectada porrouter que envÃa a mayor potencia. Los pasos realizados para utilizar la herramienta son los siguientes:
-\begin{enumerate}
-\item sudo airmon-ng check, con esto se verifica que procesos pueden causar problemas al utilizar estas herramientas.
-\item sudo airmon-ng check kill, con este comando se finalizan los procesos detectados. En algunos casos es necesario ejecutarlo mas de una vez.
-\item sudo airmon-ng start nombre\_interface\_wifi, se inicializa la interfaz en modo monitor.
-\item sudo airodump-ng nombre\_interface\_monitor, con este comando se comienza a sensar las redes wifi vecinas y sus respectivos clientes. Para conocer el nombre de la interfaz en modo monitor se puede averiguar con el comando $ifconfig$.
-\item sudo airmon-ng nombre\_interface\_monitor, para deshabilitar el modo monitor.
-\item sudo service nerwork-manager restart, por ultimo hay que reiniciar el network-manager.
-\end{enumerate}
-
-\subsection{Procedimiento}
-Los pasos a seguir para la recolección de datos en cada prueba son los siguientes:
-\begin{enumerate}
-\item Conectar un terminal por WiFi al AP.
-\item Conectar un pendrive con una carpeta $logs$ al AP
-\item Montar el pendrive (ubicado en $/dev/sda1$) con $ mount /dev/sda1 /mnt/usb/$
-\item Ejecutar el script $generate\_test\_rrpaa.sh$ con los parámetros necesarios
-\item Al finalizar, desmontar el pendrive con $umount /dev/sda1$
-\item Analizar los resultados obtenidos en formato $.csv$ con el script $calculate\_graph.py$
-\end{enumerate}
-
-\section{Primeras pruebas}
-Luego de haber definido los escenarios, se comenzaron a realizar las primeras pruebas al algoritmo y analizar los resultados de las mismas.
-El comienzo de la etapa de pruebas fue un tanto ambicioso, iniciando directamente con el escenario de distancias descrito en \ref{prueba_distancias}. Con una primera ejecución se detectaron algunos problemas importantes en el RRPAA y por lo tanto se debió realizar un estudio más minuicioso con ejecuciones más cortas y controladas, definidas en el punto \ref{pruebas_individuales}.\\
-Cabe resaltar que debido a los distintos problemas que surgieron durante el análisis de la implementación y de los primeros resultados obtenidos, no fue posible seguir completamente el plan de pruebas diseñado. Esto llevó a realizar una única ejecución de la prueba de distancias con el algoritmo RRPAA y poner mayor énfasis en el tercer caso de prueba. Sin embargo, no fue posible comparar ninguna de las ejecuciones contra el algoritmo Minstrel.
-
-\subsection{Prueba de distancias}
-\label{prueba_distancias}
-Esta prueba consistió en llevar a cabo el primer escenario planteado en los escenarios de prueba \ref{Distancias_escenario}. Los resultados obtenidos en una primera ejecución de la prueba pueden apreciarse en las figuras \ref{prueba_distancias} y \ref{throughput_distancias}.
+\subparagraph{KVM}
+KVM [12], siglas de Kernel-based Virtual Machine, se trata de una tecnologÃa de virtualización open source sobre Linux. Se encuentra formada por un módulo del kernel denominado kvm.ko y permite transformar un sistema operativo Linux en un hipervisor. Como módulo del kernel se encuentra incluido en Linux a partir de la versión 2.6.20. Como hipervisor se clasifica como de tipo nativo, o bare metal, utilizando los componentes del sistema Linux para implementar cada máquina virtual como un proceso de Linux.
-\begin{figure}[H]
- \centering
- \includegraphics[width=\columnwidth]{resultado_distancias}
- \caption{Resultados prueba de distancias}
- \label{prueba_distancias}
-\end{figure}
-
-En las gráficas anteriores puede apreciarse la inestabilidad presente en el algoritmo. Se esperaba que la potencia de transmisión comenzara a incrementar, alcanzando su máximo sobre la mitad del tiempo y que posteriormente disminuyera volviendo al estado original. Sin embargo, esta variable se mantuvo oscilando la mayor parte del tiempo, siendo predominantes los valores más altos.\\
-Por otro lado, la tasa de transmisión tampoco tuvo un comportamiento deseado. La tasa de pérdidas, a pesar de algunos picos puntuales, se mantuvo dentro de los valores esperados.
+\section{Contenerización}
+Un contenedor [13] es una unidad de software liviana diseñada para ejecutar una aplicación. Está formado únicamente por el código de la aplicación y las dependencias necesarias para que esta ejecute, creando un paquete portable e independiente. De esta forma múltiples contenedores pueden correr como procesos diferentes en una misma máquina host compartiendo el kernel del sistema operativo.
+Si bien tanto contenedores como máquinas virtuales tienen como fin aislar y compartir recursos de la máquina host, lo hacen en diferentes niveles. Los primeros virtualizan únicamente el sistema operativo guest, utilizando el kernel del host subyacente, mientras que las VMs virtualizan a nivel de hardware.
\begin{figure}[H]
\centering
- \includegraphics[width=\columnwidth]{throughput_distancias}
- \caption{Throughput: prueba de distancias}
- \label{throughput_distancias}
+ \includegraphics[width=0.8\columnwidth]{containers}
+ \caption{Virtualización vs Contenerización}
+ \label{containers}
\end{figure}
-
-\subsection{Pruebas individuales}
-\label{pruebas_individuales}
-Estas pruebas fueron realizadas luego de analizados los resultados anteriores. Su objetivo consistió en detectar la causa de la inestabilidad del algoritmo y el motivo de la predominancia de la utilización de valores de power elevados.
-\subsubsection{Prueba 1}
-Consistió en una prueba simple, donde se situaron los terminales a una distancia corta de aproximadamente 3m.
-
-\begin{figure}[H]
- \centering
- \includegraphics[width=\columnwidth]{resultado_prueba_1}
- \caption{Resultados prueba inicial 1}
- \label{prueba_1}
-\end{figure}
-
-Nuevamente, se observa una inestabilidad durante la toma de decisiones entre estados y valores de power muy elevados para la distancia entre terminales.
-
-\subsubsection{Prueba 2}
-Luego de realizar los ajustes mencionados más adelante en la sección \ref{ajustes_algoritmo}, se repetió el escenario de la prueba anterior obteniendo resultados favorables.
-
-\begin{figure}[H]
- \centering
- \includegraphics[width=\columnwidth]{resultado_prueba_2}
- \caption{Resultados prueba inicial 2}
- \label{prueba_1}
-\end{figure}
+La combinación de estas tecnologÃas provee gran flexibilidad al realizar el despliegue de aplicaciones sobre varios servidores, complementando lo ligero de los contenedores con el aislamiento de recursos fÃsicos y la seguridad obtenidos mediante VMs.\\
-Finalmente, se logró obtener estabilidad en ambos parámetros del RRPAA y la utilización de powers casi nulos para una distancia muy corta.
+Citando la ‘Application Container Security Guide’ (SP 800-190 de NIST [14]): \textsl{“A pesar de que a veces se considera que los contenedores son la siguiente fase de virtualización, sobrepasando la virtualización de hardware, la realidad de la mayorÃa de las organizaciones apunta menos a la revolución que a la evolución. Los contenedores y la virtualización de hardware no solo pueden, sino que frecuentemente lo hacen, coexistir y heredar las capacidades del otro. Las VMs brindan muchos beneficios, tales como fuerte aislamiento, automatización de SO, y un amplio y profundo ecosistema de soluciones. Las organizaciones no necesitan tomar una decisión entre contenedores y máquinas virtuales. Por el contrario pueden continuar utilizando VMs para desplegar, particionar y administrar su hardware, mientras que utilizan contenedores para empaquetar sus aplicaciones, aprovechando cada VM más eficientemente.â€}\\
+Es por esto que ambas tecnologÃas serán utilizadas más adelante en la puesta en marcha de un datacenter de prueba mediante Openstack.
-\subsection{Análisis de resultados}
-A partir de los resultados generados en estas dos pruebas se obtuvieron varias conclusiones sobre el comportamiento del algoritmo:
-\begin{itemize}
-\item El mismo no logró estabilizarse en ningún momento, tanto en las pruebas de distancias en donde los estados oscilaban independientemente de la distancia en la que se encontraba la estación del router, como en la primera de las pruebas individuales, con resultados similares en donde el algoritmo no lograba tender a un estado en particular.
-\item Estudiando la tabla de probabilidades se observó que los estados más altos, dada la inestabilidad del algorimo, tendÃan a disminuir su probabilidad de ingreso hasta llegar a 1. Esto afectaba en varios sentidos el funcionamiento del algoritmo:
- \begin{itemize}
- \item En primer lugar, en el supuesto caso que se pueda mejorar el estado actual del algoritmo, esto se iba a ver dificultado debido a que las probabilidades de entrar a un estado mayor serÃan demasiado pequeñas. En estos casos el algoritmo le estarÃa asignando mayor importancia al comportamiento histórico que a la situación actual de la estación.
- \item Al llegar una probabilidad a 1, era imposible que la misma comience a incrementarse nuevamente debido a que el factor por el que se multiplica al momento de incrementarla es muy pequeño.
- \end{itemize}
-\item Un aspecto a estudiar para mejorar la estabilidad del algoritmo es el valor de los parámetros cuando se multiplica y divide una probabilidad. Un detalle observado respecto a estos es que si una probabilidad es disminuida, luego para alcanzar el mismo valor se debe incrementar aproximadamente 8 veces. Es por esto que si el algoritmo no es muy estable las probabilidades de los estados más altos tienden a disminuir rápidamente.
-\end{itemize}
+\subparagraph{LXC}
+Un “Linux container†es un contenedor formado por un conjunto de procesos que se encuentran aislados del resto del sistema host. Como tal, brinda un entorno virtual con su propia CPU, memoria, red, etc, implementado mediante el uso de los namespaces y cgroups del kernel linux corriendo en la máquina host.\\
+Este tipo de contenedores es utilizado por Openstack durante su despliegue para ejecutar los servicios en cuya configuración se haya indicado que utilicen contenedores en lugar de correr directo sobre el servidor.
-Durante las ejecuciones de las pruebas para observar el valor de los distintos parámetros, el comportamiento del algoritmo o la búsqueda de errores se utilizó la herramienta kprint descrita en \ref{Kprint}. Esta herramienta como se mencionó se utilizó para debuggear las funciones implementadas, permitiendo encontrar los puntos en los cuales ocurrÃan errores en tiempo de ejecución.\\
-Dado que la memoria del router es muy reducida, al no considerar ésta variable los logs utilizados ocuparon toda la memoria disponible dejando inutilizable el router. Esto fue solucionado asignando un valor pequeño al tamaño máximo del archivo de logs.
+\section{Datacenters}
+La infraestructura que se encuentra por debajo de la mencionada nube se conoce con el nombre de Datacenter. Un Datacenter [21] es un espacio fÃsico que aloja múltiples componentes de hardware interconectados tales como servidores, racks, switches, routers, sistemas de almacenamiento, etc. Estos últimos proveen una red de recursos de red, cómputo y almacenamiento, necesaria para alojar diversas aplicaciones o grandes cantidades de datos. A su vez, los nuevos Datacenters escalan implementando infraestructuras virtualizadas, utilizando los mecanismos mencionados anteriormente, por encima de la fÃsica ya existente llegando a interconectar múltiples espacios fÃsicos ubicados en diversas partes del mundo.
+\\
+Debido al gran potencial computacional existente en este tipo de infraestructuras, su mayor explotación se encuentra en la ejecución de tecnologÃas tales como big data, inteligencia artificial, aprendizaje automático, entre otras.
+\\
+Por su gran importancia en la tecnologÃa de la información actual, los Datacenters no solo requieren un diseño de infraestructura de recursos computacionales sino también un diseño de componentes fÃsicos externos que garanticen la seguridad fÃsica y una tasa de resistencia a fallas prácticamente perfecta. En función de estos aspectos es que existe un estándar internacional especificado por la ANSI que califica y certifica el diseño de un datacenter. Existen entonces cuatro categorÃas bajo el estándar ANSI/TIA-942 que se resumen a continuación:
-\section{Ajustes al algoritmo}
-\label{ajustes_algoritmo}
-Luego de las primeras pruebas realizadas se modificó el algoritmo con el fin de lograr mejorar la estabilidad del mismo:
\begin{itemize}
-\item Se estableció un lÃmite inferior para las probabilidades equivalente al 1\% del valor máximo de las mismas. Con esto se soluciona el problema de las probabilidades estancadas en 1.
-\item Siguiendo el algoritmo propuesto, las probabilidades son aumentadas cuando se realiza una transición a un estado mayor. Esto generaba que el estado más alto nunca podÃa aumentar su probabilidad de ingreso. La solución a esto fue modificar el algoritmo para las situaciones en que el estado es el más alto y el porcentaje de pérdidas es menor que el ORI, en lugar de incrementar de estado se incrementará la probabilidad de dicho estado.
-\item Una de las razones por las cuales el algoritmo aumenta las probabilidades de los estados menores al pasar a un estado mayor es tener la posibilidad de regresar rápidamente en caso de que se generen demasiadas pérdidas por el cambio. Lo que realizaba el algoritmo era aumentar las probabilidades de los estados menores del estado actual pero no el actual, lo cual no es consistente con el razonamiento previo, por lo tanto se ajustó para aumentar la probabilidad del estado del que se parte.
+ \item \textbf{TIER 1}: especificado para pequeñas empresas y organizaciones con una infraestructura básica. Ofrece una escasa protección ante riesgos fÃsicos externos, sin la implementación de ninguna redundancia.
+ \item \textbf{TIER 2}: se corresponde a Datacenters que posean un mÃnimo nivel de redundancia a nivel de componentes pero no de distribución eléctrica. Además aumentan su protección en cuanto a eventos fÃsicos, en comparación con el nivel anterior.
+ \item \textbf{TIER 3}: suele indicarse para organizaciones que requieren un servicio con disponibilidad 24/7. Mantiene redundancia tanto a nivel de componentes como de distribución eléctrica. Tolera prácticamente cualquier tipo fallas fÃsicas. Para mantener el sistema (ej: recambio de componentes) no es necesario paralizarlo.
+ \item \textbf{TIER 4}: enfocado a grandes organizaciones mundiales. Mantiene el mayor nivel de tolerancia a fallas junto con redundancia de componentes y distribuciones eléctricas. Es posible que ocurra un mantenimiento del sistema junto con una falla inesperada sin que el servicio se vea afectado.
\end{itemize}
-\section{Pruebas finales}
-El objetivo principal de estas pruebas fue llevar a cabo el escenario de pruebas de Starvation problem definido en \ref{Starvarion_Escenario}.
-Antes de comenzar con las pruebas centrales de esta sección se realizaron otras auxiliares para verificar el funcionamiento del algoritmo luego de los ajustes realizados, ubicando a la estación en una posicion cercana y otra lejana respecto del router.
-
-\subsection{Prueba cercana}
-Esta prueba consistió en tener una estación asociada a un router a una distancia aproximada de 1m. Los resultados obtenidos (ver figura \ref{prueba_cerca}) fueron los esperados, enviando prácticamente siempre con el rate máximo, power mÃnimo y una tasa de pérdidas pequeña.
-
-\begin{figure}[H]
- \centering
- \includegraphics[width=\columnwidth]{resultado_prueba_cerca}
- \caption{Resultados prueba estación cercana al router}
- \label{prueba_cerca}
-\end{figure}
-
-Con el fin de tener otra medida para comparar resultados mostraremos el throughput instantáneo en cada momento. Este dato lo podemos ver en la figura \ref{thruoghput_cerca}.
-
-\begin{figure}[H]
- \centering
- \includegraphics[width=\columnwidth]{throughput_prueba_cerca}
- \caption{Throughput: prueba con estación cercana al router}
- \label{thruoghput_cerca}
-\end{figure}
-
-Como conclusión el algoritmo con una estación cercana funciona correctamente.
-
-\subsection{Prueba lejana}
-Esta prueba consistió en tener una estación asociada a un router a una distancia aproximada de 60m. Los resultados obtenidos no fueron óptimos mas allá que el power y rate parecen estabilizarse. Los aspectos negativos son: el power utilizado era casi el máximo y el rate no llegaba ni a la mitad del valor máximo considerando que prácticamente no habÃa ruido de otros routers. Por otro lado la tasa de pérdidas fue muy elevada ubicandose aproximadamente en 30\%. Los valores obtenidos se pueden observar en la siguiente figura \ref{prueba_lejos}.
-
-\begin{figure}[H]
- \centering
- \includegraphics[width=\columnwidth]{resultado_prueba_lejos}
- \caption{Resultados prueba estación lejana al router}
- \label{prueba_lejos}
-\end{figure}
-
-Respecto al throughput obtenido se puede observar en la figura \ref{throughput_lejos} que se vio reducido a más de la mitad del obtenido en la prueba con la estación cercana.
-
-\begin{figure}[H]
- \centering
- \includegraphics[width=\columnwidth]{throughput_prueba_lejos}
- \caption{Información transferida y throughput: prueba con estación lejana al router}
- \label{throughput_lejos}
-\end{figure}
-
-Los resultados ideales para esta prueba hubieran sido que el rate y power se logren estabilizar un poco más y que la tasa de pérdidas sea menor aunque implique utilizar mayor potencia o menor rate.
-
-\subsection{Prueba lejana con power máximo}
-Dado que los resultados obtenidos en la prueba anterior no fueron muy convincentes y generaron la interrogante de si utilizar un power superior (eventualmente el power máximo) mejorarÃa la tasa de pérdidas y el rate utilizado, se realizó la misma prueba pero hardcodeando el power en su nivel máximo.
-
-Los resultados obtenidos los podemos observar en la figura \ref{prueba_lejos_max}. Los mismos no fueron buenos, el rate nunca se pudo estabilizar oscilando en un amplio rango de valores. Además se obtuvo una tasa de error superior al 15\% que se considera alta dado que se está utilizando el power máximo.
-
-\begin{figure}[H]
- \centering
- \includegraphics[width=\columnwidth]{resultado_prueba_lejos_max}
- \caption{Resultados prueba estación lejana al router con power máximo}
- \label{prueba_lejos_max}
-\end{figure}
-
-Como era de esperar el throughput aumentó considerablemente comparado al caso anterior \ref{throughput_lejos_max}.
-
-\begin{figure}[H]
- \centering
- \includegraphics[width=\columnwidth]{throughput_prueba_lejos_max}
- \caption{Información transferida y throughput: prueba con estación lejana al router utilizando power máximo}
- \label{throughput_lejos_max}
-\end{figure}
-
-Como conclusión general de las pruebas con la estación lejos del AP, se genera cierta incertidumbre sobre el correcto funcionamiento del router debido a que se utiliza en ambas pruebas los powers más altos y aún asà las tasas de pérdidas son elevadas teniendo en cuenta que la distancia está lejos de ser la máxmima soportada. Estos resultados no sugieren un buen indicio sobre los valores que se obtendrán en las siguientes pruebas.
-
-\subsection{Pruebas del escenario Starvation problem}
-Estas pruebas fueron realizadas en base al escenario definido en \ref{Starvarion_Escenario}. Para ejecutar el caso de prueba se utilizó la herramienta aircrack-ng mencionada en \ref{aircrack}.\\
-En total fueron realizadas tres pruebas bajo este escenario, en dos de ellas la estación que comenzaba primera con la transmisión de información era la lejana y en la otra el caso contrario. Esto fue realizado con el objetivo de observar si afectaba al rendimiento el orden en que se comenzaba a transmitir.\\
-La duración de las pruebas realizadas fue de 7 minutos.
-
-\subsubsection{Prueba 1 y 2}
-La ejecución de estas pruebas se realizó de la siguiente forma:
-\begin{enumerate}
-\item Se encienden ambos routers.
-\item Se comienza con la ejecución del test en la computadora que estaba cerca del router.
-\item Luego que se estabilice (100s aprox.) se comienza con la ejecución de la pc lejana al router.
-\end{enumerate}
-La diferencia de las pruebas es simplemente el rol de las pcs utilizadas, la pc que era la cercana en una prueba, en la siguiente era la lejana y lo mismo con la otra pc utilizada. Esto se realizó para verificar que los resultados obtenidos no eran dependientes de las terminales utilizadas.
-
-Mostraremos solamente los resultados de una prueba debido a que ambas fueron similares.
-
-\subparagraph{Resultados PC cercana}
-Los resultados los podemos observar en las figuras \ref{starvation_1_cerca} y \ref{starvation_throughput_1_cerca}.
-
-\begin{figure}[H]
- \centering
- \includegraphics[width=\columnwidth]{resultado_starvation_1_cerca}
- \caption{Resultados caso 1 y 2 prueba starvation problem de la pc cercana al router }
- \label{starvation_1_cerca}
-\end{figure}
-
-\begin{figure}[H]
- \centering
- \includegraphics[width=\columnwidth]{starvation_1_cerca_throughput}
- \caption{Throughput: caso 1 y 2 prueba starvation problem de la pc cercana al router}
- \label{starvation_throughput_1_cerca}
-\end{figure}
-
-De los resultados se puede ver que el estado del algoritmo fue prácticamente en todo momento el máximo. El segundo aspecto a observar es cómo el throughput se ve disminuida drásticamente en el momento que la segunda pc comienza con la prueba.
-
-\subparagraph{Resultados PC lejana}
-Los resultados los podemos observar en las figuras \ref{starvation_1_lejos} y \ref{starvation_throughput_1_lejos}.
-
-\begin{figure}[H]
- \centering
- \includegraphics[width=\columnwidth]{resultado_starvation_1_lejos}
- \caption{Resultados caso 1 y 2 prueba starvation problem de la pc lejana al router }
- \label{starvation_1_lejos}
-\end{figure}
+\section{Redes}
+En la etapa de configuración e instalación y posteriormente en la utilización de Openstack, se referencian diversos conceptos de red, por ejemplo, protocolos, tipos de redes y componentes virtualizados. A continuación se introducirán brevemente algunos de estos conceptos:
-\begin{figure}[H]
- \centering
- \includegraphics[width=\columnwidth]{starvation_1_lejos_throughput}
- \caption{throughput: caso 1 y 2 prueba starvation problem de la pc lejana al router}
- \label{starvation_throughput_1_lejos}
-\end{figure}
+\subparagraph{Flat}
+Una red Flat hace referencia a una red en la cual no se utiliza ningún tipo de tag. Las interfaces fÃsicas o virtuales se asocian directamente al switch o bridge por lo tanto solamente una red flat puede existir por cada interfaz fÃsica.
-En este caso como era de esperar dados los antecedentes de las pruebas realizadas, los resultados no fueron muy buenos. Las tasas de pérdidas fueron muy altas y aunque el power oscilaba entre los powers más altos, el rate no logró estabilizarse en ningún momento.
+\subparagraph{VLAN}
+Una Virtual Local Area Network (VLAN) permite segmentar de manera virtual un dominio de difusión de capa 2 en múltiples dominios de difusión. Esto permite utilizar un switch como si fuera múltiples switches. A modo de ejemplo, dos host conectados a un mismo switch pero en distintas VLANs no podrán ver el tráfico generado por el otro.
+Para identificar a qué VLAN corresponde una trama se utiliza un nuevo campo en el cual se introduce el ID de la VLAN, estos cambios que se realizan a la trama Ethernet se establecen en el estándar IEEE 802.1Q [1].\\
+Openstack utiliza las VLANs con el fin de aislar el tráfico de datos de diferentes clientes, sin importar en qué servidor fÃsico (nodo de cómputo) estén corriendo las máquinas de los mismos [2].
-\subsubsection{Prueba 3}
-La ejecución de esta prueba se realizó de la siguiente forma:
-\begin{enumerate}
-\item Se encienden ambos routers.
-\item Se comienza con la ejecución del test en la computadora que estaba lejos del router.
-\item Luego que se estabilice (100s aprox.) se comienza con la ejecución de la pc cercana al router.
-\end{enumerate}
+\subparagraph{VXLAN}
+El protocolo Virtual extensible local area network (VXLAN) se ubica dentro de los protocolos de superposición (overlay protocols) que utilizan el mecanismo de tunelización para el transporte de datos. VXLAN encapsula una trama Ethernet dentro de paquetes UDP los cuales pueden ser ruteados. Esto permite extender una red local sobre múltiples redes de capa 3 en forma transparente para los host finales. El funcionamiento del protocolo se encuentra en el RFC 7348 [3].\\
+Para diferenciar las distintas redes virtuales en lugar de utilizar un VLAN ID se utiliza un VXLAN Network Identifier (VNI), el cual puede tomar aproximadamente 16 millones de valores siendo una de las principales diferencias con las VLANs que pueden tomar 4096 valores únicos. Esta diferencia para datacenters de gran porte es vital para poder aislar el tráfico de los clientes del mismo. Un componente necesario para encapsular y desencapsular son los VXLAN Tunnel Endpoint (VTEP) los cuales residen en los nodos fÃsicos. Un listado con pros y contras de las redes de capa 2 y capa 3 se presenta en [4].
-Los resultados obtenidos fueron similares a las casos 1 y 2, la pc cercana tuvo un throughput reducido mientras la otra pc estaba transmitiendo, lograba estabilizar correctamente el estado y tenÃa una tasa de pérdida muy reducida. Por otro lado la pc lejana continua con un comportamiento irregular, con altos niveles de error y sin poder estabilizar el rate utilizado.
+\chapter{Openstack}
-\clearpage
-\textbf{Resultados PC cercana}
-\begin{figure}[H]
- \centering
- \includegraphics[width=\columnwidth]{resultado_starvation_2_cerca}
- \caption{Resultados caso 1 y 2 prueba starvation problem de la pc cercana al router }
- \label{starvation_2_cerca}
-\end{figure}
+\section{Origen y definición}
+Openstack fue creado en los primeros meses del 2010. En ese momento Rackspace querÃa reescribir el código de infraestructura que corrÃa en sus servidores cloud y además estaban considerando hacer open source el código cloud existente. En ese entonces, Anso Labs, quienes trabajaban para la NASA, publicaron el código beta para Nova, un proyecto basado en Python descrito como “cloud computing fabric controllerâ€. \\
+Dadas las semejanzas en las necesidades de ambas empresas, decidieron en unir fuerzas dando como resultado una base de Openstack. \\
+El primer Summit de diseño tuvo lugar en Austin, TX del 13 al 14 de julio de 2010, en donde participaron aproximadamente 25 compañÃas: AMD, Autonomic Resources, Citrix, Cloud.com, Cloudkick, Cloudscaling, CloudSwitch, Dell, enStratus, FathomDB, Intel, iomart Group, Limelight, Nicira, NTT DATA, Opscode, PEER 1, Puppet Labs, RightScale, Riptano, Scalr, SoftLayer, Sonian, Spiceworks, Zenoss y Zuora. El proyecto fue oficialmente anunciado el 21 de julio de ese mismo año. \\
+Originalmente la misión de Openstack era “to produce the ubiquitous Open Source Cloud Computing platform that will meet the needs of public and private clouds regardless of size, by being simple to implement and massively scalableâ€. Luego en 2016 se actualizó la misma incluyendo interoperabilidad y mejor servicio a los usuarios finales.\\
+En septiembre de 2012, fue lanzada la fundación de Openstack como una institución independiente proporcionando recursos para proteger, potenciar y promover el software Openstack y la comunidad que lo rodea. [5]\\
+\\
+Como es definido en el sitio de Openstack, \textsl{“es un sistema operativo en la nube que controla grandes grupos de recursos de computación, almacenamiento y redes a través de un centro de datos, administrados y provisionados a través de APIsâ€}[6].\\
+Openstack es un software open source gobernado por una fundación. Ser parte de la misma es gratis y está abierta a todo el mundo.\\
+El proyecto tiene una arquitectura modular, en donde cada instalación de Openstack tendrá instalados y configurados los módulos que se ajusten a las necesidades del caso. Dichos módulos están implementados en Python. Seis de estos proyectos se denominan como módulos core dado que se encargan de las funciones principales del cloud como son las conexiones de red, el almacenamiento, el servicio de identidad, servicios de imágenes y de cómputo.\\
+Permite construir nubes públicas y privadas ofreciendo principalmente servicios de infraestructura (IaaS) y en un grado menor, servicios de plataforma (PaaS).
-\begin{figure}[H]
- \centering
- \includegraphics[width=\columnwidth]{starvation_2_cerca_throughput}
- \caption{Throughput: caso 1 y 2 prueba starvation problem de la pc cercana al router}
- \label{starvation_throughput_2_cerca}
-\end{figure}
+\section{Módulos Core}
+En esta sección se describirán los módulos Nova, Neutron, Glance, Cinder, Keystone y Swift, llamados core, profundizando en los aspectos más importantes de cada uno. Conceptualmente los módulos se relacionan de la siguiente forma:
-\clearpage
-\textbf{Resultados PC lejana}
\begin{figure}[H]
\centering
- \includegraphics[width=\columnwidth]{resultado_starvation_2_lejos}
- \caption{Resultados caso 1 y 2 prueba starvation problem de la pc lejana al router }
- \label{starvation_2_lejos}
+ \includegraphics[width=1.0\columnwidth]{openstack-modules}
+ \caption{Relacionamiento entre módulos core}
+ \label{containers}
\end{figure}
-\begin{figure}[H]
- \centering
- \includegraphics[width=\columnwidth]{starvation_2_lejos_throughput}
- \caption{Throughput: caso 1 y 2 prueba starvation problem de la pc lejana al router}
- \label{starvation_throughput_2_lejos}
-\end{figure}
-
-
-\subsection{Análisis de resultados}
-En primer lugar se puede concluir que existe un problema presente en todas las pruebas en el router con su estación asociada a gran distancia. Las razones pueden ser que el canal es malo, que el algoritmo tenga problemas para estabilizarse al aumentar la distancia router-estación o algún problema presente en los dispositivos.\\
-Uno de los resultados positivos es que se pudo observar la asimetrÃa presente en dicho escenario, en donde la $pc_lejos$ en todas las pruebas afecta notoriamente a la $pc_cerca$ y en ningún caso ocurre lo contrario.\\
-El resultado esperado que se planteó para este escenario en donde el router con la estación cercana sea totalmente anulada por el otro router no ocurrió por consecuencia del funcionamiento irregular de este otro. Este último no llega a transmitir al medio un volumen de infomación tal que el router cercano no tenga la posibilidad de enviar paquetes en intervalos pequeños de tiempo.
-\section{Conclusiones y trabajo a futuro}
-En primer lugar, se resalta que el alcance del proyecto se vio afectado por los errores encontrados y la dificultad que implicaba corregirlos. Esto generó que el tiempo disponible para ejecutar las pruebas fuera reducido, quedando pendiente su ejecución formal con varias iteraciones y posterior comparación con el algoritmo Minstrel.\\
-Como aspectos positivos, luego de diferentes correciones, se logró estabilizar el RRPAA tanto a distancias cercanas como lejanas y seguir fielmente el diseño original del algoritmo.\\
-Dado el estado actual del proyecto, aún quedan varias tareas por realizar:
-\begin{itemize}
-\item Analizar posibles ajustes sobre los parámetros $\gamma$ y $\delta$ utilizados para modificar las probabilidades.
-\item Estudiar de forma adecuada cuál es el mejor lÃmite inferior para las probabilidades.
-\item Comparar formalmente el RRPAA con Minstrel.
-\item Ejecutar adecuadamente los tres escesarios definidos.
-\item Extender RRPAA a estánderes WiFi más modernos que 802.11g.
-\end{itemize}
-
+En [20] se muestra un esquema de una arquitectura lógica estándar de Openstack, en donde se puede apreciar las interacciones internas entre los componentes de un proyecto, las interacciones entre proyectos y las interacciones entre agentes externos y openstack.
+
+%Estos valores servirán de referencia para tomar las decisiones a la hora de bajar y subir de estado. Los estados consisten en los pares (power, rate) asociados a la transmisión entre las terminales y son ordenados de forma que un mayor estado implica menor power y mayor rate. El pseudocódigo asociado al orden entre estados puede verse en el algoritmo \ref{alg1}.
+%
+%\begin{algorithm}[H]
+% \floatname{algorithm}{Algoritmo}
+% \caption{Orden entre estados}
+% \label{alg1}
+% \begin{multicols}{2}
+% \begin{algorithmic}[1]
+% \IF{$p_{0} == p_{max}$}
+% \STATE $anterior(r_{0}, p_{0}) = (r_{-1}, p_{0})$
+% \ELSE
+% \STATE $anterior(r_{0}, p_{0}) = (r_{0}, p_{1})$
+% \ENDIF
+% \end{algorithmic}
+% \begin{algorithmic}[1]
+% \IF{$r_{0} < r_{max}$}
+% \STATE $siguiente(r_{0}, p_{0}) = (r_{1}, p_{0})$
+% \ELSE
+% \STATE $siguiente(r_{0}, p_{0}) = (r_{0}, p_{-1})$
+% \ENDIF
+% \end{algorithmic}
+% \end{multicols}
+%\end{algorithm}
+%
+%
+%
+%\begin{algorithm}[H]
+% \floatname{algorithm}{Algoritmo}
+% \caption{Pseudocódigo RRPAA}
+% \label{alg2}
+% \begin{algorithmic}[1]
+% \IF{$FLR > MTL(rate)$ \AND $power < maxPower$}
+% \STATE {$priTable[rate][power] /= \gamma$}
+% \STATE {$power++$}
+% \ELSIF {$FLR > MTL(rate)$ \AND $power == maxPower$}
+% \STATE {$priTable[rate][power] /= \gamma$}
+% \STATE {$rate--$}
+% \ENDIF
+% \IF{$FLR < ORI(rate)$}
+% \FORALL {$r < rate$}
+% \STATE {$priTable[r][power] *= \delta$}
+% \ENDFOR
+% \IF {$rate < maxRate$ \AND $rand() < priTable[rate+1][power]$}
+% \STATE {$rate++$}
+% \ELSE
+% \FORALL {$p > power$}
+% \STATE {$priTable[rate][p] *= \delta$}
+% \ENDFOR
+% \IF {$power > 0$ \AND $rand() < priTable[rate][power-1]$}
+% \STATE {$power--$}
+% \ENDIF
+% \ENDIF
+% \ELSIF {$FLR >= ORI(rate)$ \AND $loss < MTL(rate)$ \AND $power > 0$}
+% \FORALL {$p > power$}
+% \STATE {$priTable[rate][p] *= \delta$}
+% \ENDFOR
+% \IF {$power > 0$ \AND $rand() < priTable[rate][power-1]$}
+% \STATE {$power--$}
+% \ENDIF
+% \ENDIF
+% \end{algorithmic}
+%\end{algorithm}
+%
+%El pseudocódigo del algoritmo utilizado por el RRPPA se encuentra en el algoritmo \ref{alg2}. Mientras que un resumen del comportamiento del mismo puede apreciarse en la figura \ref{flr}.
+%
+%\begin{figure}[H]
+% \centering
+% \includegraphics[width=0.8\columnwidth]{linea_flr}
+% \caption{Decisiones tomadas segun FLR}
+% \label{flr}
+%\end{figure}
+%
+%Una descripción mas detallada de su comportamiento puede encontrarse en \cite{proyecto}, \cite{tesis} y \cite{articulo}.
+%
+%
+%\subsection{Implementación}
+%El algoritmo RRPAA fue implementado en hardware como parte del proyecto de grado de MatÃas Irland y Jorge Artave en marco de la carrera IngenierÃa en Computación de la Facultad de IngenierÃa, UdelaR \cite{proyecto}. Para su desarrollo se utilizó como base la implementación existente de Minstrel incluida en el kernel de OpenWrt. Minstrel se trata de un algoritmo de control de rate que basa su comportamiento en la recolección de estadÃsticas mediante el envÃo de tramas de sondeo. No entraremos en mayor detalle sobre este algoritmo pero cabe mencionar que suele ser el estándar incluido en las distribuciones de OpenWrt.\\
+%
+%La implementación de RRPAA fue realizada sobre el driver Ath9k desarrollado por Qualcomm Atheros para controladores WiFi y basada en el estándar IEEE 802.11g.\\
+%El código implementado se encuentra en tres archivos dentro del módulo kmod-mac80211:
+%\begin{itemize}
+% \item \textbf{rc80211\_rrpaa.h}: Definición de constantes y estructuras a utilizar y funciones a ser utilizadas por otros archivos del módulo.
+% \item \textbf{rc80211\_rrpaa.c}: Implementación del algoritmo.
+% \item \textbf{rc80211\_rrpaa\_debugfs.c}: Funciones para la recolección de datos estadÃsticos.
+%\end{itemize}
+%
+%El ciclo de la ejecución consta de cuatro etapas bien definidas:
+%\subparagraph{Inicialización}En primer lugar se da la inciailización de las estructuras reservando la memoria necesaria para mantener la sesión con cada terminal cada vez que uno de estos se asocia al AP. Dentro de esta etapa se define el rango de rates y powers soportados por ambos terminales, se calculan los valores de ORI y MTL y se inicializa la tabla de probabilidades asociada.
+%\subparagraph{Recolección de datos}La siguiente etapa se trata de la recolección de datos. Esta consiste en almacenar la cantidad de intentos realizados y exitosos para cada estado asociado luego del envÃo de cada paquete. Esta información es utilizada posteriormente para la ejecucción del algoritmo antes descrito.
+%\subparagraph{Toma de decisiones}La tercera etapa se denomina toma de decisiones, es aquà en donde se ejecuta explÃcitamente el algoritmo diseñado y se determina en función de los datos previamente recolectados y de la tabla de probabilidades, cuál será el próximo estado a ser utilizado en la transmisión de las restantes tramas. Para manejar adecuadamente la representación númerica del kernel, se mapearon las probalidades en el rango $(0,1]$ al rango $[1,4096]$, aplicando un shifteo a la izquierda de doce posiciones.
+%\subparagraph{Asignación}Finalmente, se asignan las parejas de rate y power asociadas a la retry chain para la próxima transmisión. La retry chain se trata de una estructura de datos que almacena los parámetros a utilizar en cada intento de transmisión de una trama. En este caso, la cadena tendrá largo 4 y almacenará los pares $(rate, power)$ y la cantidad $c$ de intentos posibles a utilizar hasta saltar al siguiente valor de la cadena. En caso de que se den mas de $c$ pérdidas durante el envÃo de la trama, se intentará enviar con los valores de la siguiente posición y asà sucesivamente hasta el final de la misma. Este mecanismo busca disminuir el overhead necesario para el cálculo del valor de las variables en caso de pérdidas. En esta implementación, los siguientes valores de la retry chain serán calculados en función del estado determinado por RRPAA siguiendo el pseudocódigo \ref{alg3}. Cabe resaltar que para la última posición de la cadena se optó por asignar el menor estado posible (power máximo y rate mÃnimo) con el fin de asegurar el envÃo de la trama en cuestión.
+%
+%\begin{algorithm}[H]
+% \floatname{algorithm}{Algoritmo}
+% \caption{Asignación de valores a la retry chain}
+% \label{alg3}
+% \begin{algorithmic}[1]
+% \WHILE {$can\_add\_items\_to\_retry\_chain$}
+% \IF {$power < p_{max}$}
+% \STATE {$power = next_power$}
+% \ELSIF {$rate > rate_{min}$}
+% \STATE {$rate = previous_rate$}
+% \ENDIF
+% \ENDWHILE
+% \end{algorithmic}
+%\end{algorithm}
+%
+%\section{Detección de errores}
+%Luego de tener claro el diseño del algoritmo RRPAA y de analizar la implementación en hardware del mismo, se detectaron ciertas inconsistencias en el código que no seguÃan fielmente la idea original. Estos errores podrÃan generar que los resultados obtenidos durante las pruebas no fueran significativos y por ende requerÃan de su correción para poder continuar con el proyecto.\\
+%A continuación se detallan los errores detectados según la función correspondiente y su solución aplicada.
+%
+%\subparagraph{\textbf{rrpaa\_tx\_status}} Uno de los primeros errores se daba durante la recolección de datos. EspecÃficamente en la función $rrpaa\_tx\_status$ encargada de recorrer la retry chain y determinar para cada rate la cantidad de intentos realizados y exitosos en caso de que corresponda. El error se debÃa a que si la trama se habÃa transmitido con éxito, se sumaba 1 a la cantidad de éxitos de los rates de la cadena que se posicionaban desde el inicio hasta el verdadero rate exitoso. Para corregirlo se sumó correctamente sólo al rate que efectivamente obtuvo un éxito en la retry chain.
+%
+%\subparagraph{\textbf{rrpaa\_update\_stats}} Los siguientes errores se corresponden todos a la etapa de toma de decisiones. La función $rrpaa\_update\_stats$ es la responsable de ejecutar el algoritmo \ref{alg2} pero luego de analizarla se detectaron cuatro errores importantes que no seguÃan la idea original, todos estos se detallan a continuación:
+%\begin{itemize}
+%\item Al momento de tomar la decisión de cambio de estado, se recorrÃa todo el arreglo de rates manejado con la terminal y se aplicaba el algoritmo múltiples veces ya que se consideraba el FLR de cada uno de estos. Esto no es correcto ya que para determinar las transiciones entre estados, sólo se debe tener en cuenta el estado actual y no todos los posibles. La solución consistió en seguir estrictamente el pseudocódigo planteado y utilizar solo el estado actual para tomar la decisión.
+%
+%\item Cuando el algoritmo planteado debÃa aumentar de estado bajando el power, se utilizaba la probabilidad del estado anterior subiendo el power. Este posiblemente fuera un error de tipeo al colocar un $+$ en lugar de un $-$ pero afectaba significativamente el uso de la tabla de probabilidades para la convergencia del algoritmo. Su correción fue trivial.
+%
+%\item Cuando el estado actual contenÃa el máximo power posible y se debÃa aumentar el estado bajando esta variable, no se consultaba la tabla de probabilidades para tomar la decisión. Esta determinación no se encuentra en lo especificado por el pseudocódigo y por lo tanto fue removida.
+%
+%\item Además de tomar las decisiones de transición entre estados, esta función se encarga de actualizar los datos históricos de intentos realizados y exitosos para cada rate y bajar a cero los contadores correspondientes. Esto se realiza cada vez que se ejecuta el $rrpaa\_update\_stats$, sin embargo la bajada a cero de estos contadores solo se estaba realizando para aquellos rates que habÃan alcanzado el tamaño de ventana requerido para ejecutar el algoritmo en función del FLR. Esto generaba que en los datos históricos aparecieran cantidades mucho mayores que las reales debido a que se sumaban al mismo los mismos intentos más de una vez. Su correción consistió en bajar explÃcitamente estas variables para todos los rates al final de la función.
+%\end{itemize}
% BIBLIOGRAFIA CON BIBTEX
\clearpage \newpage
\bibliographystyle{plain}
\bibliography{references}
-
\end{document}
diff --git a/docs/latex/report.toc b/docs/latex/report.toc
new file mode 100644
index 0000000000000000000000000000000000000000..56e024310ece4b2a37cfeb587c742ca78c13ee08
--- /dev/null
+++ b/docs/latex/report.toc
@@ -0,0 +1,16 @@
+\babel@toc {spanish}{}
+\contentsline {chapter}{\numberline {1}Introducci\IeC {\'o}n}{2}{chapter.1}
+\contentsline {chapter}{\numberline {2}Marco te\IeC {\'o}rico}{3}{chapter.2}
+\contentsline {section}{\numberline {2.1}Cloud computing}{3}{section.2.1}
+\contentsline {section}{\numberline {2.2}Virtualizaci\IeC {\'o}n}{4}{section.2.2}
+\contentsline {subparagraph}{KVM}{4}{section*.3}
+\contentsline {section}{\numberline {2.3}Contenerizaci\IeC {\'o}n}{4}{section.2.3}
+\contentsline {subparagraph}{LXC}{5}{section*.5}
+\contentsline {section}{\numberline {2.4}Datacenters}{5}{section.2.4}
+\contentsline {section}{\numberline {2.5}Redes}{6}{section.2.5}
+\contentsline {subparagraph}{Flat}{6}{section*.6}
+\contentsline {subparagraph}{VLAN}{6}{section*.7}
+\contentsline {subparagraph}{VXLAN}{6}{section*.8}
+\contentsline {chapter}{\numberline {3}Openstack}{7}{chapter.3}
+\contentsline {section}{\numberline {3.1}Origen y definici\IeC {\'o}n}{7}{section.3.1}
+\contentsline {section}{\numberline {3.2}M\IeC {\'o}dulos Core}{7}{section.3.2}
diff --git a/docs/latex/resources/containers.png b/docs/latex/resources/containers.png
new file mode 100644
index 0000000000000000000000000000000000000000..9bf638b47fe76d683f272b0d26a2a5438d149ec5
Binary files /dev/null and b/docs/latex/resources/containers.png differ
diff --git a/docs/latex/resources/diagrama_distancias.png b/docs/latex/resources/diagrama_distancias.png
deleted file mode 100644
index 0aa04075060120d5878bbbe66ef9452483c6e82f..0000000000000000000000000000000000000000
Binary files a/docs/latex/resources/diagrama_distancias.png and /dev/null differ
diff --git a/docs/latex/resources/diagrama_overlapping_1.png b/docs/latex/resources/diagrama_overlapping_1.png
deleted file mode 100644
index 1f760328a643c6e052b4d7c45cc4fcaa8a19f701..0000000000000000000000000000000000000000
Binary files a/docs/latex/resources/diagrama_overlapping_1.png and /dev/null differ
diff --git a/docs/latex/resources/diagrama_overlapping_2.png b/docs/latex/resources/diagrama_overlapping_2.png
deleted file mode 100644
index ad1325e8d593464639a66bb82a7ecbe22d7495b3..0000000000000000000000000000000000000000
Binary files a/docs/latex/resources/diagrama_overlapping_2.png and /dev/null differ
diff --git a/docs/latex/resources/diagrama_starvation.png b/docs/latex/resources/diagrama_starvation.png
deleted file mode 100644
index 70e0b805e6e99571da8de613c134449a7b172879..0000000000000000000000000000000000000000
Binary files a/docs/latex/resources/diagrama_starvation.png and /dev/null differ
diff --git a/docs/latex/resources/hypervisors.png b/docs/latex/resources/hypervisors.png
new file mode 100644
index 0000000000000000000000000000000000000000..db5a0a51918f41f4bf2921d09f0c770fec893c35
Binary files /dev/null and b/docs/latex/resources/hypervisors.png differ
diff --git a/docs/latex/resources/linea_flr.png b/docs/latex/resources/linea_flr.png
deleted file mode 100644
index 76caad429098a069815cb013917712ecea21ca10..0000000000000000000000000000000000000000
Binary files a/docs/latex/resources/linea_flr.png and /dev/null differ
diff --git a/docs/latex/resources/openstack-modules.png b/docs/latex/resources/openstack-modules.png
new file mode 100644
index 0000000000000000000000000000000000000000..2802e7b6817568b4049228b8d639a1fd07fa007d
Binary files /dev/null and b/docs/latex/resources/openstack-modules.png differ
diff --git a/docs/latex/resources/resultado_distancias.png b/docs/latex/resources/resultado_distancias.png
deleted file mode 100644
index 03393366c95a44c568ec9780165b1cfee2a8fc78..0000000000000000000000000000000000000000
Binary files a/docs/latex/resources/resultado_distancias.png and /dev/null differ
diff --git a/docs/latex/resources/resultado_prueba_1.png b/docs/latex/resources/resultado_prueba_1.png
deleted file mode 100644
index 701b7ea210341d797de65e61a611aa1d78b985df..0000000000000000000000000000000000000000
Binary files a/docs/latex/resources/resultado_prueba_1.png and /dev/null differ
diff --git a/docs/latex/resources/resultado_prueba_2.png b/docs/latex/resources/resultado_prueba_2.png
deleted file mode 100644
index 1570241e431eaa7d269a81c0b1745a951314bf4a..0000000000000000000000000000000000000000
Binary files a/docs/latex/resources/resultado_prueba_2.png and /dev/null differ
diff --git a/docs/latex/resources/resultado_prueba_cerca.jpg b/docs/latex/resources/resultado_prueba_cerca.jpg
deleted file mode 100644
index 1d20780bb0c751218fb216b89e87f62bed6d6e89..0000000000000000000000000000000000000000
Binary files a/docs/latex/resources/resultado_prueba_cerca.jpg and /dev/null differ
diff --git a/docs/latex/resources/resultado_prueba_lejos.png b/docs/latex/resources/resultado_prueba_lejos.png
deleted file mode 100644
index 6ca004da4a8644c6e3c9b84f87e917c92de4c343..0000000000000000000000000000000000000000
Binary files a/docs/latex/resources/resultado_prueba_lejos.png and /dev/null differ
diff --git a/docs/latex/resources/resultado_prueba_lejos_max.png b/docs/latex/resources/resultado_prueba_lejos_max.png
deleted file mode 100644
index f4dea9f1e8659544476175c426aae7990024a8e7..0000000000000000000000000000000000000000
Binary files a/docs/latex/resources/resultado_prueba_lejos_max.png and /dev/null differ
diff --git a/docs/latex/resources/resultado_starvation_1_cerca.jpg b/docs/latex/resources/resultado_starvation_1_cerca.jpg
deleted file mode 100644
index 76d1f0e841a55d91eaa761655b265a5a9d94c510..0000000000000000000000000000000000000000
Binary files a/docs/latex/resources/resultado_starvation_1_cerca.jpg and /dev/null differ
diff --git a/docs/latex/resources/resultado_starvation_1_lejos.png b/docs/latex/resources/resultado_starvation_1_lejos.png
deleted file mode 100644
index d2fe596a178e3b6403f7be2eaa2ba6d9872f3852..0000000000000000000000000000000000000000
Binary files a/docs/latex/resources/resultado_starvation_1_lejos.png and /dev/null differ
diff --git a/docs/latex/resources/resultado_starvation_2_cerca.png b/docs/latex/resources/resultado_starvation_2_cerca.png
deleted file mode 100644
index ae34dbb11b48e7b081305791bb31c164ec8cd359..0000000000000000000000000000000000000000
Binary files a/docs/latex/resources/resultado_starvation_2_cerca.png and /dev/null differ
diff --git a/docs/latex/resources/resultado_starvation_2_lejos.png b/docs/latex/resources/resultado_starvation_2_lejos.png
deleted file mode 100644
index f4fbd60669d2ce0c9b25a5204bb5138eb70345e1..0000000000000000000000000000000000000000
Binary files a/docs/latex/resources/resultado_starvation_2_lejos.png and /dev/null differ
diff --git a/docs/latex/resources/starvation_1_cerca_throughput.png b/docs/latex/resources/starvation_1_cerca_throughput.png
deleted file mode 100644
index 0d463a2281cd323ae9f2308942ff27600e718375..0000000000000000000000000000000000000000
Binary files a/docs/latex/resources/starvation_1_cerca_throughput.png and /dev/null differ
diff --git a/docs/latex/resources/starvation_1_lejos_throughput.jpg b/docs/latex/resources/starvation_1_lejos_throughput.jpg
deleted file mode 100644
index f40dd4c7d048cbc63bd55edd0f994a81d38efd36..0000000000000000000000000000000000000000
Binary files a/docs/latex/resources/starvation_1_lejos_throughput.jpg and /dev/null differ
diff --git a/docs/latex/resources/starvation_2_cerca_throughput.png b/docs/latex/resources/starvation_2_cerca_throughput.png
deleted file mode 100644
index ce1a9f64882181ce4203e33ae78f021b96074817..0000000000000000000000000000000000000000
Binary files a/docs/latex/resources/starvation_2_cerca_throughput.png and /dev/null differ
diff --git a/docs/latex/resources/starvation_2_lejos_throughput.png b/docs/latex/resources/starvation_2_lejos_throughput.png
deleted file mode 100644
index ce2ddabe84faec6c1ae4b5508fe18ffb98ed30b3..0000000000000000000000000000000000000000
Binary files a/docs/latex/resources/starvation_2_lejos_throughput.png and /dev/null differ
diff --git a/docs/latex/resources/throughput_distancias.jpg b/docs/latex/resources/throughput_distancias.jpg
deleted file mode 100644
index 4f409f3dea9ec6e9ced67c16492fe9760734cc2f..0000000000000000000000000000000000000000
Binary files a/docs/latex/resources/throughput_distancias.jpg and /dev/null differ
diff --git a/docs/latex/resources/throughput_prueba_cerca.jpg b/docs/latex/resources/throughput_prueba_cerca.jpg
deleted file mode 100644
index 95cc318c85b766a4930b8c3cd187291c66927450..0000000000000000000000000000000000000000
Binary files a/docs/latex/resources/throughput_prueba_cerca.jpg and /dev/null differ
diff --git a/docs/latex/resources/throughput_prueba_lejos.png b/docs/latex/resources/throughput_prueba_lejos.png
deleted file mode 100644
index 310db138bc7415d4995da989c3abe7d3f236c0cf..0000000000000000000000000000000000000000
Binary files a/docs/latex/resources/throughput_prueba_lejos.png and /dev/null differ
diff --git a/docs/latex/resources/throughput_prueba_lejos_max.jpg b/docs/latex/resources/throughput_prueba_lejos_max.jpg
deleted file mode 100644
index 258bb22a0a865f220f89ac1fc63d663e33346c60..0000000000000000000000000000000000000000
Binary files a/docs/latex/resources/throughput_prueba_lejos_max.jpg and /dev/null differ
diff --git a/src/deploy/user_variables.yml b/src/deploy/user_variables.yml
index e27625b2f15a66a3c2d0471802214ebe122738f0..45b39346c2c7fcd0d31ed22b263cf179e9124a29 100644
--- a/src/deploy/user_variables.yml
+++ b/src/deploy/user_variables.yml
@@ -176,6 +176,6 @@ deployment_environment_variables:
# Variables para usar HTTPS
-openstack_service_publicuri_proto: https
-openstack_service_adminuri_proto: https
-openstack_service_internaluri_proto: https
\ No newline at end of file
+#openstack_service_publicuri_proto: https
+#openstack_service_adminuri_proto: https
+#openstack_service_internaluri_proto: https