diff --git a/docs/latex/report.pdf b/docs/latex/report.pdf
index 7fbfde228064e51bdfd34da23ffb187eed3c12c6..936b6562b4c9645ddf4cfd75917051d9a1359724 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 f3a353f7e7216ba75a5e08b39e13bb9fa3914839..1fafddc4942ffe97d540747727ed54803ae703a9 100644
--- a/docs/latex/report.tex
+++ b/docs/latex/report.tex
@@ -12,13 +12,25 @@
\usepackage{amsmath}
\usepackage{graphicx}
\usepackage{multicol}
-\usepackage{listings}
\usepackage{algorithm,algorithmic}
\usepackage{subcaption}
\usepackage{fancyhdr}
\graphicspath{ {resources/} }
\usepackage[colorinlistoftodos]{todonotes}
\usepackage[colorlinks=true, allcolors=black]{hyperref}
+\usepackage{enumitem}
+\usepackage{listings}
+\lstset{
+ breaklines=true,
+ basicstyle=\small\ttfamily,
+ columns=flexible,
+ gobble=4,
+ tabsize=4,
+ showstringspaces=false
+ }
+
+
+\setlength{\columnseprule}{1pt}
\setlength{\headheight}{25pt}
@@ -53,7 +65,7 @@ El presente documento estudia los aspectos fundamentales de la plataforma Openst
\tableofcontents
\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}
+Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.\cite{tesis}
\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.
@@ -176,7 +188,7 @@ Keystone es el servicio de identidad que utiliza Openstack para la autenticació
\begin{figure}[H]
\centering
- \includegraphics[width=0.8\columnwidth]{keystone}
+ \includegraphics[width=1.0\columnwidth]{keystone}
\caption{Servicios y backends soportados por Keystone}
\label{keystone}
\end{figure}
@@ -198,7 +210,7 @@ Keystone es el servicio de identidad que utiliza Openstack para la autenticació
\item Las asignaciones de roles son tripletas que contienen un rol, un recurso y una identidad.
\end{itemize}
\item El \textbf{servicio de Tokens} válida y administra los tokens utilizados para las solicitudes de autenticaciones enviadas luego que las credenciales del usuario fueron validadas.
- \item el \textbf{servicio de catálogo} utilizado para el descubrimiento de endpoints.
+ \item El \textbf{servicio de catálogo} utilizado para el descubrimiento de endpoints.
\end{itemize}
Las definiciones mencionadas fueron extraÃdas de [16] y [17].
@@ -212,7 +224,7 @@ Un dato relevante sobre los componentes de nova es que pueden ser escalados hori
\begin{figure}[H]
\centering
- \includegraphics[width=0.8\columnwidth]{nova}
+ \includegraphics[width=1.0\columnwidth]{nova}
\caption{Principales componentes de Nova}
\label{nova}
\end{figure}
@@ -244,7 +256,7 @@ Este servicio se presenta como una API REST que se encarga de realizar un seguim
\begin{figure}[H]
\centering
- \includegraphics[width=0.8\columnwidth]{neutron}
+ \includegraphics[width=0.9\columnwidth]{neutron}
\caption{Arquitectura de Neutron}
\label{neutron}
\end{figure}
@@ -259,7 +271,7 @@ Una arquitectura simplificada de neutron se puede ver en siguiente figura \ref{n
\begin{figure}[H]
\centering
- \includegraphics[width=0.8\columnwidth]{neutron2}
+ \includegraphics[width=0.7\columnwidth]{neutron2}
\caption{Arquitectura simplificada}
\label{neutron2}
\end{figure}
@@ -290,7 +302,7 @@ La implementación del servicio Glance se basa en una arquitectura cliente-servi
\begin{figure}[H]
\centering
- \includegraphics[width=0.8\columnwidth]{glance}
+ \includegraphics[width=0.9\columnwidth]{glance}
\caption{Componentes del módulo Glance}
\label{glance}
\end{figure}
@@ -372,7 +384,7 @@ La siguiente imagen ilustra la arquitectura del servicio Swift, en la cual se pu
\begin{figure}[H]
\centering
- \includegraphics[width=0.8\columnwidth]{swift}
+ \includegraphics[width=0.6\columnwidth]{swift}
\caption{Arquitectura del módulo Swift}
\label{swift}
\end{figure}
@@ -457,7 +469,7 @@ El método de instalación OSA emplea LXC para desplegar los servicios de Openst
\begin{figure}[H]
\centering
- \includegraphics[width=0.8\columnwidth]{network-components}
+ \includegraphics[width=0.6\columnwidth]{network-components}
\caption{Componentes de red en Openstack}
\label{network-components}
\end{figure}
@@ -479,7 +491,7 @@ Como se mencionó en OSA se pueden tener diversas configuraciones dependiendo de
\begin{figure}[H]
\centering
- \includegraphics[width=0.8\columnwidth]{interfaces}
+ \includegraphics[width=1.0\columnwidth]{interfaces}
\caption{Diagrama de múltiples interfaces de red}
\label{interfaces}
\end{figure}
@@ -488,7 +500,7 @@ En la figura \ref{interfaces} se utilizan dos interfaces simples, subdivididas m
\begin{figure}[H]
\centering
- \includegraphics[width=0.8\columnwidth]{bonded-interfaces}
+ \includegraphics[width=1.0\columnwidth]{bonded-interfaces}
\caption{Diagrama de bonds de múltiples interfaces de red}
\label{bonded-interfaces}
\end{figure}
@@ -501,139 +513,956 @@ A continuación se presenta un diseño que ilustra servicios desplegados en cont
\begin{figure}[H]
\centering
- \includegraphics[width=0.8\columnwidth]{containers-deploy}
+ \includegraphics[width=1.0\columnwidth]{containers-deploy}
\caption{Despliegue de servicios Openstack en contenedores}
\label{containers-deploy}
\end{figure}
Como se menciona anteriormente los contenedores que corren servicios de Openstack requieren de interfaces virtuales para conectarse con los bridges del nodo fÃsico. Además se puede observar cómo varÃan las conexiones necesarias a los distintos tipos de red, en función del tipo de agente que corre en el contenedor. Al utilizar contenedores, OSA crea automáticamente una nueva red que se utilizará para la administración de los mismos (por ejemplo para descargar paquetes). Un punto a tener en cuenta es que Ansible para crear esta subred utiliza el rango 10.0.3.0/24.
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=1.0\columnwidth]{diagrama-openstack-1}
+ \caption{}
+ \label{diagrama-openstack-1}
+\end{figure}
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=1.0\columnwidth]{diagrama-openstack-2}
+ \caption{}
+ \label{diagrama-openstack-2}
+\end{figure}
+
+\section{Configuración OSA}
+En esta sección se presentan las configuraciones y conceptos más relevantes del nodo Deploy a tener en cuenta durante un despliegue de Openstack utilizando Ansible. Estas incluyen las convenciones de directorios empleadas, la configuración estándar y el significado del contenido de los archivos que deben ser modificados.
+
+\subsubsection{Convenciones}
+\begin{itemize}
+ \item El repositorio de OSA se clona generalmente en el directorio \path{/opt/openstack-ansible}.
+ \item Los roles de Ansible utilizados por defecto se encuentran en el directorio \path{/etc/ansible/roles} los cuales son generados a partir del archivo \path{/opt/openstack-ansible/ansible-role-requirements.yml} mediante la ejecución del \path{script bootstrap-ansible.sh}.
+ \item Las configuraciones realizadas por el administrador son indicadas en el directorio \path{/etc/openstack_deploy}.
+\end{itemize}
+
+\subsubsection{Inventario}
+Define las especificaciones de los hosts y contenedores dentro del ambiente actual de Openstack. Esta información se encuentra en el archivo \path{/etc/openstack-ansible/openstack_inventory.json}, generado a partir de los host groups, containers groups y components indicados en:
+\begin{itemize}
+ \item La estructura por defecto almacenada en \path{/opt/openstack-ansible/inventory/env.d}
+ \item Lo configurado por el administrador dentro de \path{/etc/openstack_deploy/} en:
+ \begin{itemize}
+ \item El archivo \path{openstack_user_config.yml}
+ \item El directorio \path{conf.d/}
+ \item El directorio \path{env.d/}
+ \end{itemize}
+\end{itemize}
+
+Este archivo es considerado como referencia en cualquiera de los comandos asociados al despliegue de OSA por lo tanto nunca debe ser eliminado o modificado en un ambiente de producción.\\
+
+Los components hacen referencia a los diferentes servicios que serán instalados durante el despliegue de Openstack, tanto en contenedores virtuales como directamente en los target host. Los containers groups agrupan estos components, determinando los potenciales contenedores a ser creados junto con sus especificaciones.
+En las configuraciones realizadas en ambos directorios env.d/ se asocian los containers groups anteriores con los hosts groups, los cuales agrupan diversos target hosts. De esta forma se determina qué servicio debe ser instalado en qué target host.\\
+
+\subsubsection{openstack\_user\_config.yml}
+Es el principal archivo de configuración, creado por el operador de Openstack. Las especificaciones de cada sección se detallan en [35].
+
+\chapter{Instalación}
+
+\section{Ambiente de trabajo}
+\begin{itemize}
+ \item virtualización con KVM
+ \item configuración de redes en KVM (virt-manager)
+ \item limitaciones de red
+ \item diagrama renata, lulu, VMS, DNS
+ \item túneles SSH, reversos, proxys, etc
+\end{itemize}
+
+\section{Diseño de arquitectura}
+
+\section{Preparación de nodos}
+En la siguiente sección se detallan los pasos necesarios a seguir en cada uno de los nodos para iniciar con la instalación de Openstack.
+Para realizar dicha configuración inicial será necesario que los nodos cuenten con conexión a internet. En el ambiente de trabajo actual, esto es equivalente a verificar que las variables del proxy estén bien configuradas.
+
+\subsubsection{Deploy}
+\begin{enumerate}
+ \item Configurar la interfaz de red eth0 de la siguiente forma:
+ \begin{lstlisting}
+ TYPE=Ethernet
+ BOOTPROTO=none
+ DEFROUTE=yes
+ NAME=eth0
+ DEVICE=eth0
+ ONBOOT=yes
+ IPADDR=10.0.1.10
+ PREFIX=24
+ GATEWAY=10.0.1.1
+ DNS1=192.168.60.230
+ \end{lstlisting}
+
+ \item Asociar, en el virt-manager, la interfaz de red eth0 a la red virtual de management 10.0.1.0/24.
+ \begin{figure}[H]
+ \centering
+ \includegraphics[width=0.8\columnwidth]{virt-manager-eth0}
+ \caption{}
+ \label{virt-manager-eth0}
+ \end{figure}
+
+ \item Por simplificación , cambiar el hostname de la máquina a ‘deploy’ con el comando:
+ \begin{lstlisting}
+ $ hostname deploy
+ \end{lstlisting}
+
+ \item Configurar las variables de proxy en \path{/etc/environment} con los siguientes comandos:
+ \begin{lstlisting}
+ $ echo "http_proxy=http://10.0.1.1:3128" >> /etc/environment
+ $ echo "https_proxy=http://10.0.1.1:3128" >> /etc/environment
+ $ echo "HTTP_PROXY=http://10.0.1.1:3128" >> /etc/environment
+ $ echo "HTTPS_PROXY=http://10.0.1.1:3128" >> /etc/environment
+ $ source /etc/environment
+ \end{lstlisting}
+
+ Verificar el acceso a internet mediante el comando:
+ \begin{lstlisting}
+ $ curl www.google.com.
+ \end{lstlisting}
+
+ \item Instalaciones necesarias:
+ \begin{enumerate}[label*=\arabic*.]
+ \item Actualizar repositorios y reiniciar:
+ \begin{lstlisting}[gobble=8]
+ $ yum upgrade -y
+ $ reboot
+ \end{lstlisting}
+ \item Instalar repositorio openstack queens:
+ \begin{lstlisting}[gobble=8]
+ $ yum install -y https://rdoproject.org/repos/openstack-queens/rdo-release-queens.rpm
+ \end{lstlisting}
+ \item Instalar herramientas auxiliares:
+ \begin{lstlisting}[gobble=8]
+ $ yum install -y git ntp nano net-tools ntpdate openssh-server python-devel sudo '@Development Tools'
+ \end{lstlisting}
+ \end{enumerate}
+
+ \item Deshabilitar firewall de CentOS:
+ \begin{lstlisting}
+ $ systemctl stop firewalld
+ $ systemctl mask firewalld
+ \end{lstlisting}
+
+ \item Configurar el servicio de NTP mediante Chrony, sustituyendo en el archivo \path{/etc/chrony.conf} las siguientes lÃneas:
+ \begin{lstlisting}
+ server 0.south-america.pool.ntp.org
+ server 1.south-america.pool.ntp.org
+ server 2.south-america.pool.ntp.org
+ server 3.south-america.pool.ntp.org
+ \end{lstlisting}
+
+ Reiniciar el servicio mediante:
+ \begin{lstlisting}
+ $ systemctl restart chronyd
+ \end{lstlisting}
+
+ \item Clonar el repositorio de Openstack Ansible Queens
+ \begin{lstlisting}
+ $ git clone -b 17.1.10 https://git.openstack.org/openstack/openstack-ansible /opt/openstack-ansible
+ \end{lstlisting}
+
+ \item Preparar openstack-ansible:
+ \begin{lstlisting}
+ $ /opt/openstack-ansible/scripts/bootstrap-ansible.sh
+ \end{lstlisting}
+ Este script se utiliza para asegurar que Ansible y todas las dependencias necesarias para la instalación de OSA están instaladas en el nodo de deploy.
+
+ \item Copiar el contenido de configuración al \path{/etc}:
+ \begin{lstlisting}
+ $ cp -r /opt/openstack-ansible/etc/openstack_deploy /etc/
+ \end{lstlisting}
+
+ \item Crear la carpeta para logs de la instalación:
+ \begin{lstlisting}
+ $ mkdir /var/log/openstack
+ \end{lstlisting}
+
+\end{enumerate}
+
+\subsubsection{Infra1}
+\begin{enumerate}
+ \item Configuraciones de red:
+ \begin{enumerate}[label*=\arabic*.]
+ \item Configurar los bridges br-mgmt, br-storage y br-vxlan.
+ \begin{multicols}{3}
+ \begin{lstlisting}[gobble=16]
+ DEVICE={br-mgmt}
+ BOOTPROTO=none
+ IPADDR=10.0.1.11
+ PREFIX=24
+ GATEWAY=10.0.1.1
+ DNS1=192.168.60.230
+ ONBOOT=yes
+ TYPE=Bridge
+ NM_CONTROLLED=no
+ \end{lstlisting}
+
+ \columnbreak
+
+ \begin{lstlisting}[gobble=16]
+ DEVICE=br-storage
+ BOOTPROTO=none
+ IPADDR=10.0.2.11
+ PREFIX=24
+ ONBOOT=yes
+ TYPE=Bridge
+ NM_CONTROLLED=no
+ \end{lstlisting}
+
+ \columnbreak
+
+ \begin{lstlisting}[gobble=16]
+ DEVICE=br-vxlan
+ BOOTPROTO=none
+ IPADDR=10.0.10.11
+ PREFIX=24
+ ONBOOT=yes
+ TYPE=Bridge
+ NM_CONTROLLED=no
+ \end{lstlisting}
+
+ \end{multicols}
+
+ \item Configurar las interfaces eth0, eth1, eth2 y eth3.
+ \begin{multicols}{4}
+ \begin{lstlisting}[gobble=16]
+ TYPE="Ethernet"
+ BOOTPROTO=none
+ DEVICE=eth0
+ ONBOOT=yes
+ NM_CONTROLLED=no
+ BRIDGE=br-mgmt
+ \end{lstlisting}
+
+ \columnbreak
+
+ \begin{lstlisting}[gobble=16]
+ TYPE="Ethernet"
+ BOOTPROTO=none
+ DEVICE=eth1
+ ONBOOT=yes
+ NM_CONTROLLED=no
+ BRIDGE=br-storage
+ \end{lstlisting}
+
+ \columnbreak
+
+ \begin{lstlisting}[gobble=16]
+ TYPE="Ethernet"
+ BOOTPROTO=none
+ DEVICE=eth2
+ ONBOOT=yes
+ NM_CONTROLLED=no
+ BRIDGE=br-vxlan
+ \end{lstlisting}
+
+ \columnbreak
+
+ \begin{lstlisting}[gobble=16]
+ TYPE="Ethernet"
+ BOOTPROTO=none
+ DEVICE=eth3
+ ONBOOT=yes
+ NM_CONTROLLED=no
+ \end{lstlisting}
+
+ \end{multicols}
+
+ \end{enumerate}
+
+ \item Asociar, en el virt-manager, las interfaces de red:
+ \begin{enumerate}[label*=\arabic*.]
+ \item eth0 a la red virtual de management 10.0.1.0/24.
+ \item eth1 a la red virtual de storage 10.0.2.0./24.
+ \item eth2 a la red virtual de vxlan 10.0.10.0./24.
+ \item eth3 a la red virtual de vlan 10.0.4.0./24.
+ \end{enumerate}
+
+ \item Cambiar el hostname de la máquina a ‘infra1’ con el comando:
+ \begin{lstlisting}
+ $ hostname infra1
+ \end{lstlisting}
+
+ \item Configurar las variables de proxy en la sesión pero no en el sistema, porque luego el nodo deploy configura el \path{/etc/environment} en todos los nodos.
+ \begin{lstlisting}
+ $ export http_proxy=http://10.0.1.1:3128
+ $ export https_proxy=http://10.0.1.1:3128
+ $ export HTTP_PROXY=http://10.0.1.1:3128
+ $ export HTTPS_PROXY=http://10.0.1.1:3128
+ \end{lstlisting}
+
+ Verificar el acceso a internet mediante el comando:
+ \begin{lstlisting}
+ $ curl www.google.com
+ \end{lstlisting}
+
+ \item Actualizar repositorios y reiniciar:
+ \begin{lstlisting}
+ $ yum upgrade -y
+ $ reboot
+ \end{lstlisting}
+
+ \item Instalar herramientas auxiliares:
+ \begin{lstlisting}
+ $ yum install bridge-utils iputils lsof lvm2 ntp ntpdate openssh-server sudo tcpdump python net-tools nano
+ \end{lstlisting}
+
+ \item Deshabilitar el Network Manager:
+ \begin{lstlisting}
+ $ chkconfig NetworkManager off
+ $ chkconfig network on
+ $ service NetworkManager stop
+ $ service network start
+ \end{lstlisting}
+
+ \item Deshabilitar el SELinux, cambiando en \path{/etc/sysconfig/selinux}, "SELINUX=enforcing" por "SELINUX=disabled".
+
+ \item Habilitar bonding de interfaces y vlans:
+ \begin{lstlisting}
+ $ echo 'bonding' >> /etc/modules-load.d/openstack-ansible.conf
+ $ echo '8021q' >> /etc/modules-load.d/openstack-ansible.conf
+ \end{lstlisting}
+
+ \item Configurar el servicio de NTP mediante Chrony, sustituyendo en el archivo \path{/etc/chrony.conf} las siguientes lÃneas:
+ \begin{lstlisting}
+ server 0.south-america.pool.ntp.org
+ server 1.south-america.pool.ntp.org
+ server 2.south-america.pool.ntp.org
+ server 3.south-america.pool.ntp.org
+ \end{lstlisting}
+
+ Reiniciar el servicio mediante:
+ \begin{lstlisting}
+ $ systemctl restart chronyd
+ \end{lstlisting}
+
+ \item Eliminar reglas de firewall que bloquean el tráfico:
+ \begin{enumerate}[label*=\arabic*.]
+ \item Eliminar las reglas manualmente:
+ \begin{lstlisting}[gobble=8]
+ $ iptables -D INPUT -j REJECT --reject-with icmp-host-prohibited
+ $ iptables -D FORWARD -j REJECT --reject-with icmp-host-prohibited
+ \end{lstlisting}
+
+ \item Exportar las reglas a un archivo:
+ \begin{lstlisting}[gobble=8]
+ $ iptables-save > /etc/sysconfig/iptables
+ \end{lstlisting}
+
+ \item En cada reboot de la máquina, importar las reglas del archivo anterior:
+ \begin{lstlisting}[gobble=8]
+ $ iptables-restore < /etc/sysconfig/iptables
+ \end{lstlisting}
+
+ \end{enumerate}
+
+\end{enumerate}
+
+\subsubsection{Compute1}
+\begin{enumerate}
+ \item Configuraciones de red:
+ \begin{enumerate}[label*=\arabic*.]
+ \item Configurar los bridges br-mgmt, br-storage y br-vxlan.
+ \begin{multicols}{3}
+ \begin{lstlisting}[gobble=16]
+ DEVICE=br-mgmt
+ BOOTPROTO=none
+ IPADDR=10.0.1.12
+ PREFIX=24
+ GATEWAY=10.0.1.1
+ DNS1=192.168.60.230
+ ONBOOT=yes
+ TYPE=Bridge
+ NM_CONTROLLED=no
+ \end{lstlisting}
+
+ \columnbreak
+
+ \begin{lstlisting}[gobble=16]
+ DEVICE=br-storage
+ BOOTPROTO=none
+ IPADDR=10.0.2.12
+ PREFIX=24
+ ONBOOT=yes
+ TYPE=Bridge
+ NM_CONTROLLED=no
+ \end{lstlisting}
+
+ \columnbreak
+
+ \begin{lstlisting}[gobble=16]
+ DEVICE=br-vxlan
+ BOOTPROTO=none
+ IPADDR=10.0.10.12
+ PREFIX=24
+ ONBOOT=yes
+ TYPE=Bridge
+ NM_CONTROLLED=no
+ \end{lstlisting}
+
+ \end{multicols}
+
+ \item Configurar las interfaces eth0, eth1, eth2 y eth3.
+ \begin{multicols}{4}
+ \begin{lstlisting}[gobble=16]
+ TYPE="Ethernet"
+ BOOTPROTO=none
+ DEVICE=eth0
+ ONBOOT=yes
+ NM_CONTROLLED=no
+ BRIDGE=br-mgmt
+ \end{lstlisting}
+
+ \columnbreak
+
+ \begin{lstlisting}[gobble=16]
+ TYPE="Ethernet"
+ BOOTPROTO=none
+ DEVICE=eth1
+ ONBOOT=yes
+ NM_CONTROLLED=no
+ BRIDGE=br-storage
+ \end{lstlisting}
+
+ \columnbreak
+
+ \begin{lstlisting}[gobble=16]
+ TYPE="Ethernet"
+ BOOTPROTO=none
+ DEVICE=eth2
+ ONBOOT=yes
+ NM_CONTROLLED=no
+ BRIDGE=br-vxlan
+ \end{lstlisting}
+
+ \columnbreak
+
+ \begin{lstlisting}[gobble=16]
+ TYPE="Ethernet"
+ BOOTPROTO=none
+ DEVICE=eth3
+ ONBOOT=yes
+ NM_CONTROLLED=no
+ \end{lstlisting}
+
+ \end{multicols}
+
+ \end{enumerate}
+
+ \item Asociar, en el virt-manager, las interfaces de red:
+ \begin{enumerate}[label*=\arabic*.]
+ \item eth0 a la red virtual de management 10.0.1.0/24.
+ \item eth1 a la red virtual de storage 10.0.2.0./24.
+ \item eth2 a la red virtual de vxlan 10.0.10.0./24.
+ \item eth3 a la red virtual de vlan 10.0.4.0./24.
+ \end{enumerate}
+
+ \item Cambiar el hostname de la máquina a 'compute1' con el comando:
+ \begin{lstlisting}
+ $ hostname compute1
+ \end{lstlisting}
+
+\end{enumerate}
+
+A partir de este punto, el procedimiento es idéntico al nodo infra1. Se deben realizar los puntos 4 al 11.
+
+\subsubsection{Storage1}
+\begin{enumerate}
+ \item Configuraciones de red:
+ \begin{enumerate}[label*=\arabic*.]
+ \item Configurar los bridges br-mgmt y br-storage.
+ \begin{multicols}{2}
+ \begin{lstlisting}[gobble=16]
+ DEVICE=br-mgmt
+ BOOTPROTO=none
+ IPADDR=10.0.1.13
+ PREFIX=24
+ GATEWAY=10.0.1.1
+ DNS1=192.168.60.230
+ ONBOOT=yes
+ TYPE=Bridge
+ NM_CONTROLLED=no
+ \end{lstlisting}
+
+ \columnbreak
+
+ \begin{lstlisting}[gobble=16]
+ DEVICE=br-storage
+ BOOTPROTO=none
+ IPADDR=10.0.2.13
+ PREFIX=24
+ ONBOOT=yes
+ TYPE=Bridge
+ NM_CONTROLLED=no
+ \end{lstlisting}
+
+ \end{multicols}
+
+ \item Configurar las interfaces eth0 y eth1.
+ \begin{multicols}{2}
+ \begin{lstlisting}[gobble=16]
+ TYPE="Ethernet"
+ BOOTPROTO=none
+ DEVICE=eth0
+ ONBOOT=yes
+ NM_CONTROLLED=no
+ BRIDGE=br-mgmt
+ \end{lstlisting}
+
+ \columnbreak
+
+ \begin{lstlisting}[gobble=16]
+ TYPE="Ethernet"
+ BOOTPROTO=none
+ DEVICE=eth1
+ ONBOOT=yes
+ NM_CONTROLLED=no
+ BRIDGE=br-storage
+ \end{lstlisting}
+
+ \end{multicols}
+
+ \end{enumerate}
+
+ \item Asociar, en el virt-manager, las interfaces de red:
+ \begin{enumerate}[label*=\arabic*.]
+ \item eth0 a la red virtual de management 10.0.1.0/24.
+ \item eth1 a la red virtual de storage 10.0.2.0./24.
+ \end{enumerate}
+
+ \item Cambiar el hostname de la máquina a 'storage1' con el comando:
+ \begin{lstlisting}
+ $ hostname storage1
+ \end{lstlisting}
+
+\end{enumerate}
+
+A partir de este punto, el procedimiento es idéntico al nodo infra1. Se deben realizar los puntos 4 al 11.
+\begin{enumerate}
+ \setcounter{enumi}{11}
+
+ \item Crear el volumen de LVM para utilizar Cinder:
+ \begin{enumerate}[label*=\arabic*.]
+ \item Listar los devices en la máquina:
+ \begin{lstlisting}[gobble=8]
+ $ lvmdiskscan
+ \end{lstlisting}
+
+ \item Formatear la pieza fÃsica de almacenamiento de 200 GB:
+ \begin{lstlisting}[gobble=8]
+ $ pvcreate --metadatasize 2048 physical_volume_device_path
+ \end{lstlisting}
+
+ \item Crear el nuevo grupo de almacenamiento que será utilizado por Openstack:
+ \begin{lstlisting}[gobble=8]
+ $ vgcreate cinder-volumes physical_volume_device_path
+ \end{lstlisting}
+
+ \item Verificar que el grupo quedó creado correctamente:
+ \begin{lstlisting}[gobble=8]
+ $ vgdisplay
+ \end{lstlisting}
+
+ \end{enumerate}
+
+\end{enumerate}
+
+\subsubsection{HAproxy1}
+\begin{enumerate}
+ \item Configurar las interfaces eth0 y eth1.
+ \begin{multicols}{2}
+ \begin{lstlisting}[gobble=8]
+ TYPE=Ethernet
+ BOOTPROTO=none
+ DEFROUTE=yes
+ DEVICE=eth0
+ ONBOOT=yes
+ IPADDR=10.0.1.15
+ PREFIX=24
+ GATEWAY=10.0.1.1
+ DNS1=192.168.60.230
+ \end{lstlisting}
+
+ \columnbreak
+ \begin{lstlisting}[gobble=8]
+ TYPE=Ethernet
+ BOOTPROTO=none
+ DEFROUTE=yes
+ DEVICE=eth1
+ ONBOOT=yes
+ IPADDR=192.168.60.160
+ PREFIX=24
+ \end{lstlisting}
+
+ \end{multicols}
+
+ \item Asociar, en el virt-manager, las interfaces de red:
+ \begin{enumerate}[label*=\arabic*.]
+ \item eth0 a la red virtual de management 10.0.1.0/24.
+ \item eth1 al bridge alojado en el servidor renata en la red 192.168.60.0/24.
+ \end{enumerate}
+
+ \item Cambiar el hostname de la máquina a 'haproxy1' con el comando:
+ \begin{lstlisting}
+ $ hostname haproxy1
+ \end{lstlisting}
+
+\end{enumerate}
+
+A partir de este punto, el procedimiento es similar al nodo infra1. Se deben realizar los puntos 4 al 11 con la excepción del punto 7 en donde se deshabilita el NetworkManager.
+
+\section{Configuración}
+Luego de completar la preparación de los nodos y verificar la conectividad entre los mismos, los últimos pasos antes de iniciar con la instalación de Openstack son configurar los archivos que OSA utiliza y los requerimientos extras de la herramienta utilizada para la instalación.
+
+\subsection{Configuración claves SSH}
+Como se menciona en la sección de Ansible, el nodo de deploy requiere de una conexión SSH con cada uno de los servidores que componen el datacenter, para poder configurar y operar directamente sobre cada uno de ellos. Para esto se utilizan un par de claves SSH público-privada con el fin de brindarle al nodo de deploy mayor flexibilidad al momento de acceder a los servidores. Se deberá propagar la clave del usuario root dado que es este usuario el que llevará a cabo la instalación.
+El comando que se debe ejecutar para crear las claves es el siguiente:
+
+\begin{lstlisting}[gobble=0]
+$ ssh-keygen -t rsa -f ~/.ssh/id_rsa -N ""
+\end{lstlisting}
+
+Donde:
+\begin{itemize}
+ \item \textbf{-t}: especifica el tipo de encriptación.
+ \item \textbf{-f}: determina el archivo en donde quedará la clave privada (por defecto, la pública será igual con la extensión .pub).
+ \item \textbf{-N "}\textbf{"} indica que no se utilizará ninguna passphrase en la clave.
+\end{itemize}
+
+Esto genera dos archivos (\path{id_rsa} y \path{id_rsa.pub}) donde el primero es la clave privada (que no se deberá compartir) y el segundo la clave pública que se copiará al resto de los servidores con los siguientes comandos:
+
+\begin{lstlisting}[gobble=0]
+$ ssh-copy-id root@10.0.1.11
+$ ssh-copy-id root@10.0.1.12
+$ ssh-copy-id root@10.0.1.13
+$ ssh-copy-id root@10.0.1.15
+\end{lstlisting}
+
+Para verificar la configuración bastará con realizar un ssh a cada servidor desde el deploy con el usuario root, accediendo en forma directa al prompt de dicho servidor.
+
+\subsection{Archivos de configuración OSA}
+
+\subsubsection{openstack\_user\_config.yml}
+A continuación se detalla cada bloque de configuración utilizado en la instalación realizada.\\
+
+En la primera sección, cidr\_networks, se describen las subredes utilizadas en la instalación de Openstack.
+
+\begin{lstlisting}[gobble=0]
+cidr_networks:
+ container: 10.0.1.0/24
+ tunnel: 10.0.10.0/24
+ storage: 10.0.2.0/24
+\end{lstlisting}
+
+La red de container permite a los distintos servicios , ejecutados dentro de contenedores o servidores fÃsicos, comunicarse entre sÃ. La red tunnel es utilizada cuando un usuario crea una nueva red tennant dentro de un proyecto de Openstack, en el caso que corresponda se creará una red VXLAN en este red fÃsica. Por último la red de storage la utilizaran los nodos que alojan el backend y los servicios de storage de Openstack. Los rangos elegidos son totalmente arbitrarios, a excepción de la subred 10.0.3.0/24 debido a que es utilizada internamente por OSA durante su ejecución como se mencionó en la sección de arquitectura de red.\\
+
+Lo siguiente a configurar son las direcciones IP que están siendo utilizadas por los hosts fÃsicos de la infraestructura en las redes definidas previamente, con el fin de reservarlas y que la instalación no utilice ninguna de ellas para la estructura de 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}
+\begin{lstlisting}[gobble=0]
+used_ips:
+ - "10.0.1.1,10.0.1.20" # red de management
+ - "10.0.2.1,10.0.2.20" # red de storage
+ - "10.0.10.1,10.0.10.20" # red de vxlan
+\end{lstlisting}
+\vspace{8pt}
+En la sección global\_overrides se describen los bridges utilizados y detalles de las interfaces del ambiente, por ejemplo, cómo los containers se conectan a la red fÃsica de los hosts.
+\begin{lstlisting}[gobble=0]
+global_overrides:
+ internal_lb_vip_address: 10.0.1.15
+ external_lb_vip_address: 192.168.60.160
+\end{lstlisting}
+Estos parámetros refieren a las direcciones IPs pública y privada del balanceador de carga. La privada es utilizada internamente por los servicios de Openstack y la pública es la puerta de acceso para los usuarios.
+\\
+\begin{lstlisting}[gobble=0]
+ tunnel_bridge: "br-vxlan"
+ management_bridge: "br-mgmt"
+ storage_bridge: "br-storage"
+\end{lstlisting}
+
+Con estas variables se define el nombre asignado a cada uno de los bridges creados en los hosts fÃsicos.\\
+
+La sección de provider\_networks describe la relación entre la red de los contenedores y el ambiente fÃsico de los servidores.
+
+\begin{lstlisting}[gobble=0]
+ provider_networks:
+ - network:
+ group_binds:
+ - all_containers
+ - hosts
+ type: "raw"
+ container_bridge: "br-mgmt"
+ container_interface: "eth1"
+ container_type: "veth"
+ ip_from_q: "container"
+ is_container_address: true
+ is_ssh_address: true
+ - network:
+ group_binds:
+ - glance_api
+ - cinder_api
+ - cinder_volume
+ - nova_compute
+ type: "raw"
+ container_bridge: "br-storage"
+ container_type: "veth"
+ container_interface: "eth2"
+ container_mtu: "9000"
+ ip_from_q: "storage"
+ - network:
+ group_binds:
+ - neutron_linuxbridge_agent
+ container_bridge: "br-vxlan"
+ container_type: "veth"
+ container_interface: "eth10"
+ container_mtu: "9000"
+ ip_from_q: "tunnel"
+ type: "vxlan"
+ range: "1:1000"
+ net_name: "vxlan"
+ - network:
+ group_binds:
+ - neutron_linuxbridge_agent
+ container_bridge: "br-vlan"
+ container_type: "veth"
+ container_interface: "eth12"
+ host_bind_override: "eth3"
+ type: "flat"
+ net_name: "flat"
+\end{lstlisting}
+\vspace{8pt}
+La última sección describe en qué servidor o grupo de servidores corre cada servicio de Openstack y de infraestructura.
+
+\begin{lstlisting}[gobble=0]
+### Infrastructure
+# galera, memcache, rabbitmq, utility
+shared-infra_hosts:
+ infra1:
+ ip: 10.0.1.11
+# repository (apt cache, python packages, etc)
+repo-infra_hosts:
+ infra1:
+ ip: 10.0.1.11
+# load balancer
+# Dedicated hardware is best for improved performance and security.
+haproxy_hosts:
+ balancer1:
+ ip: 10.0.1.15
+# rsyslog server
+log_hosts:
+ infra1:
+ ip: 10.0.1.11
+
+### OpenStack
+# keystone
+identity_hosts:
+ infra1:
+ ip: 10.0.1.11
+# cinder api services
+storage-infra_hosts:
+ infra1:
+ ip: 10.0.1.11
+# glance
+image_hosts:
+ infra1:
+ ip: 10.0.1.11
+# nova api, conductor, etc services
+compute-infra_hosts:
+ infra1:
+ ip: 10.0.1.11
+# heat
+orchestration_hosts:
+ infra1:
+ ip: 10.0.1.11
+# horizon
+dashboard_hosts:
+ infra1:
+ ip: 10.0.1.11
+# neutron server, agents (L3, etc)
+network_hosts:
+ infra1:
+ ip: 10.0.1.11
+# nova hypervisors
+compute_hosts:
+ compute1:
+ ip: 10.0.1.12
+# cinder volume hosts
+storage_hosts:
+ storage1:
+ ip: 10.0.1.13
+ container_vars:
+ cinder_backends:
+ lvm:
+ volume_backend_name: LVM
+ volume_driver: cinder.volume.drivers.lvm.LVMVolumeDriver
+ volume_group: cinder-volumes
+ iscsi_ip_address: "10.0.2.13"
+\end{lstlisting}
+\vspace{8pt}
+Particularmente se resalta, en el último punto, la configuración de cinder necesaria para desplegar un backend de almacenamiento basado en LVM.
+
+\subsubsection{user\_variables.yml}
+Debido a las limitaciones de red mencionadas anteriormente, es necesario configurar un proxy de salida que será propagado por ansible hacia todos los contenedores y hosts durante la instalación. Para esto se deben configurar las siguientes variables:
+
+\begin{lstlisting}[gobble=0]
+## Example environment variable setup:
+## This is used by apt-cacher-ng to download apt packages:
+proxy_env_url: http://10.0.1.1:3128/
+
+## (1) This sets up a permanent environment, used during and after deployment:
+no_proxy_env: "localhost,127.0.0.1,{{ internal_lb_vip_address }},{{ external_lb_vip_address }},{% for host in groups['all_containers'] %}{{ hostvars[host]['container_address'] }}{% if not loop.last %},{% endif %}{% endfor %}"
+global_environment_variables:
+ HTTP_PROXY: "{{ proxy_env_url }}"
+ HTTPS_PROXY: "{{ proxy_env_url }}"
+ NO_PROXY: "{{ no_proxy_env }}"
+ http_proxy: "{{ proxy_env_url }}"
+ https_proxy: "{{ proxy_env_url }}"
+ no_proxy: "{{ no_proxy_env }}"
+#
+## (2) This is applied only during deployment, nothing is left after deployment is complete:
+deployment_environment_variables:
+ http_proxy: "{{ proxy_env_url }}"
+ https_proxy: "{{ proxy_env_url }}"
+ no_proxy: "localhost,127.0.0.1,{{ internal_lb_vip_address }},{{ external_lb_vip_address }},{% for host in groups['keystone_all'] %}{{ hostvars[host]['container_address'] }}{% if not loop.last %},{% endif %}{% endfor %}"
+\end{lstlisting}
+
+\subsubsection{cinder.yml}
+En caso de utilizar un backend de storage LVM se debe indicar que este debe ser deployado en metal, para esto se debe configurar el archivo \path{/etc/openstack_deploy/env.d/cinder-volume.yml} con lo siguiente:
+
+\begin{lstlisting}[gobble=0]
+container_skel:
+ cinder_volumes_container:
+ properties:
+ is_metal: false
+\end{lstlisting}
+
+\subsection{Generación de claves}
+Se deben configurar las passphrases requeridas por Openstack durante su instalación y posterior uso. Esto se alcanza mediante:
+
+\begin{lstlisting}[gobble=0]
+$ cd /opt/openstack-ansible
+$ ./scripts/pw-token-gen.py --file /etc/openstack_deploy/user_secrets.yml
+\end{lstlisting}
+
+\subsection{Correcciones}
+
+\subsubsection{SELinux}
+Durante el proceso de instalación se detectó un bug asociado a SELinux, el cual fue verificado en [49]. Debido a que en el proyecto OSA se dejó de mantener el uso de SELinux por falta de personal, se debió aplicar el commit indicado en [50] de la versión Rocky de OSA que desactiva por completo la utilización de este módulo.\\
+Concretamente el commit consiste en:
+
+\begin{itemize}
+ \item Eliminar los siguientes archivos:
+ \begin{lstlisting}
+ $ rm /etc/ansible/roles/os_nova/files/osa-nova.te
+ $ rm /etc/ansible/roles/os_nova/tasks/nova_selinux.yml
+ \end{lstlisting}
+
+ \item Modificar el archivo \path{/etc/ansible/roles/os_nova/tasks/nova_post_install.yml} eliminando las siguientes lÃneas:
+ \begin{lstlisting}
+ include_tasks: nova_selinux.yml
+ when:
+ - ansible_selinux.status == "enabled"
+ \end{lstlisting}
+\end{itemize}
+
+\section{Ejecución de playbooks}
+Finalmente para instalar Openstack con Ansible es necesario correr las playbooks principales del proyecto, las cuales se encuentran en el directorio \path{/opt/openstack-ansible/playbooks}.\\
+En primer lugar se ejecutan tres scripts para realizar un chequeo de sintaxis de la configuración preparada y los scripts a utilizar. Esto se realiza de la siguiente forma:
+
+\begin{lstlisting}[gobble=0]
+$ openstack-ansible setup-hosts.yml --syntax-check
+$ openstack-ansible setup-infrastructure.yml --syntax-check
+$ openstack-ansible setup-openstack.yml --syntax-check
+\end{lstlisting}
+\vspace{8pt}
+En caso de no tener errores, se comienza la ejecución de las playbook en el orden que se describen:
+
+\subsubsection{setup-hosts.yml}
+Esta playbook se encarga de configurar todos los hosts descritos en el archivo \path{openstack_user_config.yml}. Con el siguiente comando se ejecuta la playbook:
+
+\begin{lstlisting}[gobble=0]
+$ openstack-ansible -vvv setup-hosts.yml 2>&1 | tee /var/log/openstack/hostsXX.log
+\end{lstlisting}
+
+La opción -vvv es para que la salida sea más verbosa y el final es para mostrar la salida del comando en la consola y almacenarla en un archivo de log.
+
+\subsubsection{install-haproxy.yml}
+La configuración de los balanceadores de carga es lo siguiente a realizar. Esto se puede realizar sin tener explÃcitamente los contenedores o servidores fÃsicos con los servicios instalados gracias a Ansible. OSA como se mencionó en la sección del inventario, a partir de los archivos de configuración conoce exactamente cómo quedará instalado cada uno de los servicios de Openstack, por ejemplo las IPs y puertos de cada servicio.
+Con el siguiente comando se ejecuta la playbook:
+
+\begin{lstlisting}[gobble=0]
+$ openstack-ansible -vvv haproxy-install.yml 2>&1 | tee /var/log/openstack/haproxyXX.log
+\end{lstlisting}
+
+\subsubsection{setup-infrastructure.yml}
+En este paso demora un poco más que el primer setup y se encargará de construir todos los contenedores donde luego se instalarán los servicios de Openstack. Esta script además se encarga de instalar los servicios de infraestructura como son RabbitMQ o Galera DB para luego ser configurados en la playbook final.
+Con el siguiente comando se ejecuta la playbook:
+
+\begin{lstlisting}[gobble=0]
+$ openstack-ansible -vvv setup-infrastructure.yml 2>&1 | tee /var/log/openstack/infrastructureXX.log
+\end{lstlisting}
+
+\subsubsection{setup-openstack.yml}
+En este paso final es cuando se configuran todos los servicios, indicados en los archivos de configuración de OSA, de Openstack. Esta playbook es la que demora más tiempo en su ejecución, en el orden de las horas.
+Con el siguiente comando se ejecuta la playbook:
+
+\begin{lstlisting}[gobble=0]
+$ openstack-ansible -vvv setup-openstack.yml 2>&1 | tee /var/log/openstack/openstackXX.log
+\end{lstlisting}
+
+\section{Verificación}
+Luego de que la última playbook haya terminado su ejecución sin error, debemos verificar que la instalación fue exitosa. Esto se realizará de forma manual siguiendo los pasos que se indican a continuación:
+
+\begin{enumerate}
+ \item Acceder al nodo de infra1 como usuario root.
+
+ \item La instalación que realiza OSA crea contenedores de utilidad los cuales proveen de todas las herramientas desde la consola para utilizar Openstack. En primer lugar se deben listar todos los containers del nodo fÃsico ejecutando:
+ \begin{lstlisting}
+ $ lxc-ls -f
+ \end{lstlisting}
+
+ \item El contenedor que se utiliza es el que tiene en su nombre la palabra utility, para acceder al mismo es necesario ejecutar el siguiente comando de lxc:
+ \begin{lstlisting}
+ $ lxc-attach -n <nombre_contenedor>
+ \end{lstlisting}
+
+ \item Para utilizar los servicios de Openstack es necesario enviar las credenciales del usuario que invocará a las APIs de los servicios. Esto se debe al funcionamiento de Openstack en donde cada llamada a una API debe ser validada por el módulo de keystone. Para evitar escribir las credenciales en cada comando, OSA genera un archivo llamado openrc para cargar la información del usuario como variables de entorno. El archivo se carga con el siguiente comando:
+ \begin{lstlisting}
+ $ source openrc
+ \end{lstlisting}
+
+ \item Algunos comandos que se pueden ejecutar son:
+ \begin{itemize}
+ \item Para listar usuarios:
+ \begin{lstlisting}[gobble=8]
+ $ openstack user list --os-cloud=default
+ \end{lstlisting}
+
+ \item Para listar servidores:
+ \begin{lstlisting}[gobble=8]
+ $ openstack server list
+ \end{lstlisting}
+
+ \item Para listar redes:
+ \begin{lstlisting}[gobble=8]
+ $ openstack network list
+ \end{lstlisting}
+
+ \item Para listar los agentes de red:
+ \begin{lstlisting}[gobble=8]
+ $ openstack network agent list
+ \end{lstlisting}
+
+ \end{itemize}
+
+ \item Por otro lado se puede verificar el dashboard de horizon accediendo a la ip definida en \path{external_lb_vip_address} en el archivo \path{/etc/openstack_deploy/openstack_user_config.yml} en el puerto 443 dado que utiliza HTTPS. Para autenticarse como admin en necesaria la password que se encuentra definida en la opción \path{keystone_auth_admin_password} del archivo \path{/etc/openstack_deploy/user_secrets.yml}.
+
+\end{enumerate}
% BIBLIOGRAFIA CON BIBTEX
\clearpage \newpage
diff --git a/docs/latex/report.toc b/docs/latex/report.toc
index 6e7dbdca6ff3589a801854b48b77a1fccf86b69d..cc6d80167b651e12d82122df45da1fe311135b91 100644
--- a/docs/latex/report.toc
+++ b/docs/latex/report.toc
@@ -19,14 +19,14 @@
\contentsline {subparagraph}{API}{11}{section*.12}
\contentsline {subparagraph}{Scheduler}{11}{section*.13}
\contentsline {subparagraph}{Compute}{11}{section*.14}
-\contentsline {subparagraph}{Conductor}{11}{section*.15}
+\contentsline {subparagraph}{Conductor}{12}{section*.15}
\contentsline {subparagraph}{Placement}{12}{section*.16}
\contentsline {subsection}{\numberline {3.2.3}Neutron}{12}{subsection.3.2.3}
\contentsline {subparagraph}{Neutron-server}{13}{section*.19}
\contentsline {subparagraph}{Plugins y agentes}{13}{section*.20}
\contentsline {subparagraph}{Cola de mensajes}{13}{section*.21}
-\contentsline {subsection}{\numberline {3.2.4}Glance}{13}{subsection.3.2.4}
-\contentsline {subparagraph}{Creaci\IeC {\'o}n de una VM}{14}{section*.23}
+\contentsline {subsection}{\numberline {3.2.4}Glance}{14}{subsection.3.2.4}
+\contentsline {subparagraph}{Creaci\IeC {\'o}n de una VM}{15}{section*.23}
\contentsline {subsection}{\numberline {3.2.5}Cinder}{16}{subsection.3.2.5}
\contentsline {subsection}{\numberline {3.2.6}Swift}{17}{subsection.3.2.6}
\contentsline {subparagraph}{Principales componentes}{18}{section*.27}
@@ -38,10 +38,10 @@
\contentsline {subparagraph}{Nodo de balanceamiento de carga}{19}{section*.32}
\contentsline {section}{\numberline {3.4}Servicios de infraestructura}{19}{section.3.4}
\contentsline {subparagraph}{Galera - MariaDB}{19}{section*.33}
-\contentsline {subparagraph}{Message queue}{20}{section*.34}
+\contentsline {subparagraph}{Message queue}{19}{section*.34}
\contentsline {subparagraph}{Memcached}{20}{section*.35}
\contentsline {section}{\numberline {3.5}M\IeC {\'e}todos de instalaci\IeC {\'o}n}{20}{section.3.5}
-\contentsline {subsection}{\numberline {3.5.1}Ansible}{21}{subsection.3.5.1}
+\contentsline {subsection}{\numberline {3.5.1}Ansible}{20}{subsection.3.5.1}
\contentsline {subparagraph}{Nodo de control}{21}{section*.36}
\contentsline {subparagraph}{Inventario}{21}{section*.37}
\contentsline {subparagraph}{M\IeC {\'o}dulos}{21}{section*.38}
@@ -52,4 +52,32 @@
\contentsline {subparagraph}{Management Network}{22}{section*.42}
\contentsline {subparagraph}{Overlay Network}{22}{section*.43}
\contentsline {subparagraph}{Storage Network}{22}{section*.44}
-\contentsline {subsubsection}{Interfaces de red}{23}{section*.45}
+\contentsline {subsubsection}{Interfaces de red}{22}{section*.45}
+\contentsline {section}{\numberline {3.7}Configuraci\IeC {\'o}n OSA}{26}{section.3.7}
+\contentsline {subsubsection}{Convenciones}{26}{section*.51}
+\contentsline {subsubsection}{Inventario}{26}{section*.52}
+\contentsline {subsubsection}{openstack\_user\_config.yml}{26}{section*.53}
+\contentsline {chapter}{\numberline {4}Instalaci\IeC {\'o}n}{27}{chapter.4}
+\contentsline {section}{\numberline {4.1}Ambiente de trabajo}{27}{section.4.1}
+\contentsline {section}{\numberline {4.2}Dise\IeC {\~n}o de arquitectura}{27}{section.4.2}
+\contentsline {section}{\numberline {4.3}Preparaci\IeC {\'o}n de nodos}{27}{section.4.3}
+\contentsline {subsubsection}{Deploy}{27}{section*.54}
+\contentsline {subsubsection}{Infra1}{29}{section*.56}
+\contentsline {subsubsection}{Compute1}{31}{section*.57}
+\contentsline {subsubsection}{Storage1}{31}{section*.58}
+\contentsline {subsubsection}{HAproxy1}{32}{section*.59}
+\contentsline {section}{\numberline {4.4}Configuraci\IeC {\'o}n}{33}{section.4.4}
+\contentsline {subsection}{\numberline {4.4.1}Configuraci\IeC {\'o}n claves SSH}{33}{subsection.4.4.1}
+\contentsline {subsection}{\numberline {4.4.2}Archivos de configuraci\IeC {\'o}n OSA}{33}{subsection.4.4.2}
+\contentsline {subsubsection}{openstack\_user\_config.yml}{33}{section*.60}
+\contentsline {subsubsection}{user\_variables.yml}{36}{section*.61}
+\contentsline {subsubsection}{cinder.yml}{37}{section*.62}
+\contentsline {subsection}{\numberline {4.4.3}Generaci\IeC {\'o}n de claves}{37}{subsection.4.4.3}
+\contentsline {subsection}{\numberline {4.4.4}Correcciones}{37}{subsection.4.4.4}
+\contentsline {subsubsection}{SELinux}{37}{section*.63}
+\contentsline {section}{\numberline {4.5}Ejecuci\IeC {\'o}n de playbooks}{38}{section.4.5}
+\contentsline {subsubsection}{setup-hosts.yml}{38}{section*.64}
+\contentsline {subsubsection}{install-haproxy.yml}{38}{section*.65}
+\contentsline {subsubsection}{setup-infrastructure.yml}{38}{section*.66}
+\contentsline {subsubsection}{setup-openstack.yml}{38}{section*.67}
+\contentsline {section}{\numberline {4.6}Verificaci\IeC {\'o}n}{39}{section.4.6}
diff --git a/docs/latex/resources/diagrama-openstack-1.jpg b/docs/latex/resources/diagrama-openstack-1.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..38b3800426b8dadfa379e4a4973c1c1537122d59
Binary files /dev/null and b/docs/latex/resources/diagrama-openstack-1.jpg differ
diff --git a/docs/latex/resources/diagrama-openstack-2.jpg b/docs/latex/resources/diagrama-openstack-2.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..f10efd7329b7a59684c492007b10eb150a2ddb6c
Binary files /dev/null and b/docs/latex/resources/diagrama-openstack-2.jpg differ
diff --git a/docs/latex/resources/virt-manager-eth0.png b/docs/latex/resources/virt-manager-eth0.png
new file mode 100644
index 0000000000000000000000000000000000000000..db906265fb91a49f2d47002dffa3fb0bddeab484
Binary files /dev/null and b/docs/latex/resources/virt-manager-eth0.png differ