diff --git a/docs/latex/references.bib b/docs/latex/references.bib
index 187e24cf548617cc01b29679dd0cb84f12786142..f6b4f1dfe5fe6bdc476af43c4ae5401fa66363c3 100644
--- a/docs/latex/references.bib
+++ b/docs/latex/references.bib
@@ -92,6 +92,27 @@ note = {Accedido: 2019-06-20}
  publisher = {Packt Publishing}
 }
 
+@InBook{openstack-networking-book-3,
+ author = {Denton, James},
+ title = {Learning Openstack Networking},
+ year = {2018},
+ isbn = {9781788392495},
+ edition = {3rd},
+ chapter = {1 Introduction to Openstack Networking},
+ publisher = {Packt Publishing}
+}
+
+@InBook{openstack-networking-book-4,
+ author = {Denton, James},
+ title = {Learning Openstack Networking},
+ year = {2018},
+ isbn = {9781788392495},
+ edition = {3rd},
+ chapter = {1 Introduction to Openstack Networking},
+ pages = {31},
+ publisher = {Packt Publishing}
+}
+
 @InBook{openstack-architects-book,
  author = {Silverman, Ben and Solberg, Michael},
  title = {Openstack for Architects},
diff --git a/docs/latex/report.pdf b/docs/latex/report.pdf
index 4f871dd6bfe501ce6b1a0d34c586f6afcf243ecb..9a38139d3a293c35c3e25bd68d86ab25601304a6 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 9b3d4b71bcc43f95300bdce322f7434ce6411ed3..04dbc3417a5639b3e3c08f832d1ba93acce8fd72 100644
--- a/docs/latex/report.tex
+++ b/docs/latex/report.tex
@@ -49,7 +49,7 @@
 			Universidad de la República, Montevideo, Uruguay. \\
 			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}
+\date{4 de Agosto de 2019}
 
 \pagestyle{fancy}
 
@@ -64,7 +64,10 @@ El presente documento estudia los aspectos fundamentales de la plataforma Openst
 \tableofcontents
 
 \chapter{Introducción}
-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.
+En la actualidad hay un fuerte potencial de crecimiento en los datacenters, principalmente dado por la demanda de sus servicios provenientes de nuevas tendencias como la digitalización de la información, el crecimiento del comercio electrónico y la adopción del cloud computing como una alternativa real. En función de esto resulta sumamente interesante investigar alternativas y procedimientos que deben ser llevados a cabo para desplegar y operar un datacenter.\\
+
+Una tendencia que fue en aumento en los últimos años es la utilización de Openstack como plataforma de despliegue y gestión. Por lo tanto la finalidad de este informe será relatar una primera experiencia con dicha plataforma en una ambiente de prueba en el Instituto de Computación de la Facultad de Ingeniería.
+
 
 \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.
@@ -252,20 +255,9 @@ Además puede servir como un lugar donde centralizar y permitir administrar las
 Este servicio se presenta como una API REST que se encarga de realizar un seguimiento de los proveedores de recursos. Los recursos pueden ser de distintas clases. A modo de ejemplo un proveedor puede ser un nodo de cómputo o un pool de storage.
 
 \subsection{Neutron}
+Neutron es el proyecto encargado de proveer y administrar recursos de red en una nube creada con Openstack. Es un sistema API-driven, escalable horizontalmente y diseñada para añadirle diversos plugins con el fin de proporcionar nuevas funcionalidades. Como otros servicios de Openstack, Neutron requiere una base de datos para persistir las configuraciones de los elementos de red. El servicio de red de Openstack permite crear desde redes y subredes hasta topologías de red avanzadas las cuales pueden contener firewalls, balanceadores, VPNs entre otros. \\
 
-\begin{figure}[H]
-	\centering
-		\includegraphics[width=0.9\columnwidth]{neutron}
-	\caption{Arquitectura de Neutron. Extraída de \cite{openstack-networking-book-1}.}
-	\label{neutron}
-\end{figure}
-
-Neutron es el proyecto encargado de proveer y administrar recursos de red en una nube creada con Openstack. Es un sistema API-driven, escalable horizontalmente y diseñada para añadirle diversos plugins con el fin de proporcionar nuevas funcionalidades. \\
-Como otros servicios de Openstack, Neutron requiere una base de datos para persistir las configuraciones de los elementos de red. \\
-El servicio de red de Openstack permite crear desde redes y subredes hasta topologías de red avanzadas las cuales pueden contener firewalls, balanceadores, VPNs entre otros.\\
-Las instalaciones del módulo de red deben tener al menos un red externa, la cual no es una SDN definida dentro de Openstack sino que es una red accesible por fuera de Openstack. Estas redes permiten que las redes virtuales construidas con neutron tengan conectividad con el mundo exterior.\\
-Por otro lado, neutron permite crear redes internas a las cuales se conectarán directamente las VMs. Para lograr que dichas VMs se conecten con las redes externas son necesarios routers que relacionen ambos tipos de redes.\\
-
+Las instalaciones del módulo de red deben tener al menos un red externa, la cual no es una SDN definida dentro de Openstack sino que es una red accesible por fuera de Openstack. Estas redes permiten que las redes virtuales construidas con neutron tengan conectividad con el mundo exterior. Por otro lado, neutron permite crear redes internas a las cuales se conectarán directamente las VMs. Para lograr que dichas VMs se conecten con las redes externas son necesarios routers que relacionen ambos tipos de redes.\\ 
 Una arquitectura simplificada de neutron se puede ver en siguiente figura \ref{neutron2}:
 
 \begin{figure}[H]
@@ -282,9 +274,24 @@ El módulo Neutron server es en donde reside la API recibiendo y respondiendo la
 Por otro lado se encuentran una serie de agentes que se distribuyen típicamente en los nodos de red y cómputo. Estos agentes se agregan a demanda según las funcionalidades y rendimiento requeridos. Estos agentes o plugins serán los encargados de crear los recursos virtuales de red del cloud.
 
 \subparagraph{Cola de mensajes}
-En general se utiliza en las instalaciones del módulo de red para llevar a cabo la comunicación entre el neutron-server y los distintos agentes.
+En general se utiliza en las instalaciones del módulo de red para llevar a cabo la comunicación entre el neutron-server y los distintos agentes.\\
+
+En la figura \ref{neutron2} se muestra como el servidor de Neutron se conecta con la base de datos que es donde se persisten los recursos de red creados. Por otro lado el servidor acepta solicitudes en la API que expone desde los usuarios y servicios.
 
-...........................
+\subsubsection{Tipos de redes en Openstack}
+En Openstack los usuarios tienen la posibilidad de crear su propio esquema de red, decidiendo libremente el direccionamiento IP a utilizar. Los recursos de red creados dentro de un proyecto son privados al mismo. En Openstack se pueden crear dos tipos de redes:
+
+\begin{itemize}
+	\item \textbf{Project/tenant network}: es una red virtual creada por un proyecto o por un administrador en nombre del proyecto. Este tipo de red se encarga de proveer conectividad a los recursos de un proyecto. Los usuarios pueden crear, modificar y eliminar redes tenants. En general este tipo de redes está aislado del resto de las redes de proyecto por VLANs o algún otro mecanismo de segmentación como VXLAN. 
+	\item \textbf{Provider network}: s una red virtual creada para mapearse a una red física de los servidores que alojan Openstack. Este tipo de redes son creadas para habilitar el acceso a recursos de red externos a la nube de Openstack. Las mismas son creadas y administradas por los administradores.
+\end{itemize}
+
+Cuando se crea una red de proyecto los aspectos físicos de como es implementada son transparentes al usuario, por lo contrario en la red de proveedor se puede especificar el tipo de red, la interfaz física y el identificador de segmentación utilizado.
+
+\subsubsection{Tipo de tráfico}
+l tráfico en openstack se puede dividir en dos categorías: plano de control y plano de datos. El plano de control está relacionado con el tráfico utilizado para administración de los nodos físicos o contenedores, para las API de los servicios de Openstack y todo el tráfico que no esté relacionado con las instancias virtuales de Openstack. El plano de datos está relacionado con el tráfico generado o dirigido hacia instancias virtuales.\\
+
+En ambientes de producción es recomendable utilizar interfaces físicas diferentes para los distintos tipos de tráficos \cite{openstack-networking-book-3}. La decisión de colapsar todo el tráfico en una sola interfaz y segmentarlo con VLANs o utilizar múltiples interfaces depende de las necesidades de cada caso. Al utilizar una sola interfaz física las probabilidades de fallas de red aumentan.
 
 \subsection{Glance}
 Glance es el nombre del proyecto utilizado por Openstack para la administración de imágenes. Este servicio permite a los usuarios, a través de una API RESTful, gestionar tanto las imágenes de las máquinas virtuales como la metadata asociada a estas. Típicamente esta gestión involucra el descubrimiento, registro y obtención de los recursos mencionados.
@@ -410,7 +417,18 @@ En general los sistemas de Openstack están construidos con servidores o nodos f
 Estos nodos en general corren las APIs de todos los servicios de los componentes de Openstack. Además estos nodos alojan la base de datos de los módulos, los servidores de mensajes y los componentes de caché en memoria como Memcache. Para escalar horizontalmente las APIs pueden ser instaladas en varios nodos de control pudiendo adicionalmente balancear la carga. 
 
 \subparagraph{Nodo de red}
-Estos nodos en general corren los servicios de metadatos y DHCP. Además permiten crear routers virtuales cuando el agente de Neutron L3 es instalado. Al igual que los nodos de control, para mejorar el rendimiento y escalar horizontalmente se pueden separar los servicios de red entre los distintos nodos de red.
+Estos nodos en general corren los servicios de metadatos y DHCP. Además permiten crear routers virtuales cuando el agente de Neutron L3 es instalado. Al igual que los nodos de control, para mejorar el rendimiento y escalar horizontalmente se pueden separar los servicios de red entre los distintos nodos de red. El uso de nodos de red dedicados mejora la seguridad y resistencia, dado que los nodos de control tendrán menor riesgo de que se sature la red y sus recursos.\\
+
+Un ejemplo de como quedan organizados los componentes de Neutron al utilizar nodos de control, red y computo se muestra a continuación:
+
+\begin{figure}[H]
+	\centering
+		\includegraphics[width=0.9\columnwidth]{neutron}
+	\caption{Arquitectura de Neutron. Extraída de \cite{openstack-networking-book-1}.}
+	\label{neutron}
+\end{figure}
+
+En este arquitectura, la API de Neutron es instalada en el nodo de control, los agentes encargados de realizar tareas específicas son instaladas en un nodo dedicado de red y por último, cada nodo de cómputo tiene un agente de red encargado de brindar conectividad a las instancias que aloja.
 
 \subparagraph{Nodo de cómputo}
 Estos nodos en general corren un hipervisor como puede ser KVM. Hyper-V o Xen; o por el lado de los contenedores LXC o Docker.
@@ -570,6 +588,17 @@ A continuación se presenta un diagrama \ref{diseño-arquitectura} de la arquite
 	\label{diseño-arquitectura}
 \end{figure}
 
+El siguiente diagrama muestra la disposición de los componentes de red en la arquitectura utilizada en donde el nodo de control y red se colapsaron a uno solo:
+
+\begin{figure}[H]
+	\centering
+		\includegraphics[width=0.6\columnwidth]{neutron3}
+	\caption{Disposición de componentes en Neutron. Extraída de \cite{openstack-networking-book-4}.}
+	\label{neutron3}
+\end{figure}
+
+
+
 \section{Ambiente de trabajo}
 
 \subsection{Hardware utilizado}
@@ -2137,16 +2166,27 @@ Debido a que no se encuentra especificado en la documentación oficial de Openst
 
 \subsubsection{Firewall}
 Deshabilitar por completo la denegación de paquetes por defecto en el firewall de CentOS deja el servidor expuesto ante vulnerabilidades, lo cual para un ambiente de producción es inadmisible. Como aspecto a mejorar se propone analizar y documentar todas las conexiones HTTP realizadas por Openstack Ansible durante su instalación y en su posterior ejecución entre cada uno de los nodos involucrados. Una vez identificadas, se debe agregar en cada nodo las reglas iptables correspondientes que habiliten dichas conexiones en particular.
-\\
 
-- generar una arquitectura segura separando adecuadamente las redes de acceso \\
-- brindar conexión directa a internet \\ 
-- investigar y documentar la gestión de openstack una vez en operación \\
+\subsubsection{Arquitectura segura}
+Se propone evaluar diversos diseños de arquitectura que involucren la utilización de un firewall que separe adecuadamente la red interna de la pública utilizando opcionalmente una DMZ. Esta evaluación debe tener en cuenta tanto accesos SSH a los nodos del datacenter por parte de administradores, como accesos directos a las instancias utilizadas por los usuarios finales. Además, debe permitir el tráfico HTTP para la correcta interacción con el dashboard de la plataforma.\\
+A la hora de tomar una decisión se debe considerar que de momento no se cuenta con una conexión directa hacia el exterior, por lo que en caso de que esto ocurra se debe reforzar adecuadamente la seguridad del datacenter.
+
+\subsubsection{Brindar conexión directa a Internet}
+Con el fin de simplificar el acceso hacia el exterior tanto durante la instalación como en su posterior ejecución, se debe evaluar una solución que permita mantener una conexión directa con el proxy de la FIng, evitando así la necesidad de realizar un túnel SSH como fue mencionado en la descripción del ambiente de trabajo.
+
+\subsubsection{Gestión de Openstack en operación}
+Es sumamente relevante investigar la gestión en caliente de un datacenter implementado mediante Openstack. Esto involucra tener un manual con pasos claros a realizar en circunstancias tales como escalar horizontalmente el datacenter, reemplazar nodos core y recuperar el funcionamiento ante eventos externos.
+
 
 \chapter{Conclusiones}
-- importancia de la herramienta openstack \\
-- vital importancia de utilizar un gestor de instalación como ansible \\
-- aun así adquirir los conocimientos necesarios para desplegar un datacenter con OSA no es para nada trivial (casi 500 horas de trabajo salu2)
+Luego de haber realizado todo el proceso de despliegue de un datacenter de pruebas mediante Openstack, se tomó conciencia de todos los aspectos y conceptos que involucra la instalación y mantenimiento de una operativa de esta magnitud. Es por esto que para llevar a cabo el trabajo fue necesario adquirir y aplicar conocimientos en diversas áreas computacionales tales como virtualización y contenerización, gestión de redes, almacenamiento de datos y administración de sistemas.\\
+
+Openstack como herramienta resulta ser muy valorada gracias a que posee una gran flexibilidad para adecuar el despliegue de un datacenter a las necesidades de cada caso, permitiendo instalar módulos con funcionalidades específicas y prescindir de aquellos que no sean necesarios. \\
+
+El proceso de instalación resulta sumamente complejo debido a la cantidad de herramientas y configuraciones a tener en cuenta, es por eso que la utilización de una herramienta de automatización de tareas resulta inevitable. Como se menciona en el documento, se utilizó Ansible para facilitar el proceso ya que permite ejecutar instalaciones reiteradas veces de forma idéntica y sobre múltiples servidores sin una carga operativa adicional. Aún así, la experiencia no fue sencilla debido a los diversos inconvenientes que se encontraron durante el camino. Esto condujo a que lograr todo el trabajo llevará un tiempo mayor al estimado.\\
+
+Finalmente se resalta el gran apoyo e inversión a nivel internacional en esta plataforma, y los niveles de crecimiento que tuvo y continúa teniendo en esta década, indicando que es algo por lo que apostar a futuro.
+
 
 % BIBLIOGRAFIA CON BIBTEX
 \clearpage \newpage
diff --git a/docs/latex/report.toc b/docs/latex/report.toc
index db5c5b004463e4ae34aa1ae2d974cb48cc2dabde..292b5474b04f04d3aaeeabbf9050e46775a9fe66 100644
--- a/docs/latex/report.toc
+++ b/docs/latex/report.toc
@@ -22,95 +22,100 @@
 \contentsline {subparagraph}{Conductor}{13}{section*.15}
 \contentsline {subparagraph}{Placement}{13}{section*.16}
 \contentsline {subsection}{\numberline {3.2.3}Neutron}{13}{subsection.3.2.3}
-\contentsline {subparagraph}{Neutron-server}{14}{section*.19}
-\contentsline {subparagraph}{Plugins y agentes}{14}{section*.20}
-\contentsline {subparagraph}{Cola de mensajes}{14}{section*.21}
+\contentsline {subparagraph}{Neutron-server}{14}{section*.18}
+\contentsline {subparagraph}{Plugins y agentes}{14}{section*.19}
+\contentsline {subparagraph}{Cola de mensajes}{14}{section*.20}
+\contentsline {subsubsection}{Tipos de redes en Openstack}{14}{section*.21}
+\contentsline {subsubsection}{Tipo de tr\IeC {\'a}fico}{15}{section*.22}
 \contentsline {subsection}{\numberline {3.2.4}Glance}{15}{subsection.3.2.4}
-\contentsline {subparagraph}{Creaci\IeC {\'o}n de una VM}{16}{section*.23}
+\contentsline {subparagraph}{Creaci\IeC {\'o}n de una VM}{16}{section*.24}
 \contentsline {subsection}{\numberline {3.2.5}Cinder}{17}{subsection.3.2.5}
 \contentsline {subsection}{\numberline {3.2.6}Swift}{19}{subsection.3.2.6}
-\contentsline {subparagraph}{Principales componentes}{19}{section*.27}
+\contentsline {subparagraph}{Principales componentes}{19}{section*.28}
 \contentsline {section}{\numberline {3.3}Tipos de nodos}{20}{section.3.3}
-\contentsline {subparagraph}{Nodo de control}{20}{section*.28}
-\contentsline {subparagraph}{Nodo de red}{20}{section*.29}
-\contentsline {subparagraph}{Nodo de c\IeC {\'o}mputo}{20}{section*.30}
-\contentsline {subparagraph}{Nodo de almacenamiento}{20}{section*.31}
-\contentsline {subparagraph}{Nodo de balanceamiento de carga}{20}{section*.32}
+\contentsline {subparagraph}{Nodo de control}{20}{section*.29}
+\contentsline {subparagraph}{Nodo de red}{20}{section*.30}
+\contentsline {subparagraph}{Nodo de c\IeC {\'o}mputo}{21}{section*.32}
+\contentsline {subparagraph}{Nodo de almacenamiento}{21}{section*.33}
+\contentsline {subparagraph}{Nodo de balanceamiento de carga}{21}{section*.34}
 \contentsline {section}{\numberline {3.4}Servicios de infraestructura}{21}{section.3.4}
-\contentsline {subparagraph}{Galera - MariaDB}{21}{section*.33}
-\contentsline {subparagraph}{Message queue}{21}{section*.34}
-\contentsline {subparagraph}{Memcached}{21}{section*.35}
-\contentsline {section}{\numberline {3.5}M\IeC {\'e}todos de instalaci\IeC {\'o}n}{21}{section.3.5}
-\contentsline {subsection}{\numberline {3.5.1}Ansible}{22}{subsection.3.5.1}
-\contentsline {subparagraph}{Nodo de control}{22}{section*.36}
-\contentsline {subparagraph}{Inventario}{22}{section*.37}
-\contentsline {subparagraph}{M\IeC {\'o}dulos}{22}{section*.38}
-\contentsline {subparagraph}{Tarea}{22}{section*.39}
-\contentsline {subparagraph}{Playbook}{22}{section*.40}
-\contentsline {section}{\numberline {3.6}Arquitectura}{22}{section.3.6}
-\contentsline {subsection}{\numberline {3.6.1}Arquitectura de red}{23}{subsection.3.6.1}
-\contentsline {subparagraph}{Management Network}{23}{section*.42}
-\contentsline {subparagraph}{Overlay Network}{23}{section*.43}
-\contentsline {subparagraph}{Storage Network}{23}{section*.44}
-\contentsline {subsubsection}{Interfaces de red}{23}{section*.45}
-\contentsline {section}{\numberline {3.7}Configuraci\IeC {\'o}n OSA}{27}{section.3.7}
-\contentsline {subsection}{\numberline {3.7.1}Convenciones}{27}{subsection.3.7.1}
-\contentsline {subsection}{\numberline {3.7.2}Inventario}{28}{subsection.3.7.2}
-\contentsline {subsection}{\numberline {3.7.3}openstack\_user\_config.yml}{28}{subsection.3.7.3}
-\contentsline {chapter}{\numberline {4}Instalaci\IeC {\'o}n}{29}{chapter.4}
-\contentsline {section}{\numberline {4.1}Dise\IeC {\~n}o de arquitectura}{29}{section.4.1}
-\contentsline {section}{\numberline {4.2}Ambiente de trabajo}{30}{section.4.2}
-\contentsline {subsection}{\numberline {4.2.1}Hardware utilizado}{30}{subsection.4.2.1}
-\contentsline {subsection}{\numberline {4.2.2}Conexi\IeC {\'o}n remota hacia el servidor renata}{31}{subsection.4.2.2}
-\contentsline {subsection}{\numberline {4.2.3}Virtualizaci\IeC {\'o}n con KVM}{32}{subsection.4.2.3}
-\contentsline {subsubsection}{Utilizaci\IeC {\'o}n virt-manager}{32}{section*.52}
-\contentsline {subsection}{\numberline {4.2.4}Especificaciones servidor renata}{39}{subsection.4.2.4}
-\contentsline {subsection}{\numberline {4.2.5}Acceso al exterior desde nodos}{40}{subsection.4.2.5}
-\contentsline {section}{\numberline {4.3}Preparaci\IeC {\'o}n de nodos}{40}{section.4.3}
-\contentsline {subsubsection}{Deploy}{41}{section*.70}
-\contentsline {subsubsection}{Infra1}{42}{section*.72}
-\contentsline {subsubsection}{Compute1}{44}{section*.73}
-\contentsline {subsubsection}{Storage1}{45}{section*.74}
-\contentsline {subsubsection}{HAproxy1}{45}{section*.75}
-\contentsline {section}{\numberline {4.4}Configuraci\IeC {\'o}n}{46}{section.4.4}
-\contentsline {subsection}{\numberline {4.4.1}Configuraci\IeC {\'o}n claves SSH}{46}{subsection.4.4.1}
-\contentsline {subsection}{\numberline {4.4.2}Archivos de configuraci\IeC {\'o}n OSA}{47}{subsection.4.4.2}
-\contentsline {subsubsection}{openstack\_user\_config.yml}{47}{section*.76}
-\contentsline {subsubsection}{user\_variables.yml}{49}{section*.77}
-\contentsline {subsubsection}{cinder.yml}{50}{section*.78}
-\contentsline {subsection}{\numberline {4.4.3}Generaci\IeC {\'o}n de claves}{50}{subsection.4.4.3}
-\contentsline {subsection}{\numberline {4.4.4}Correcciones}{50}{subsection.4.4.4}
-\contentsline {subsubsection}{SELinux}{50}{section*.79}
-\contentsline {section}{\numberline {4.5}Ejecuci\IeC {\'o}n de playbooks}{51}{section.4.5}
-\contentsline {subsubsection}{setup-hosts.yml}{51}{section*.80}
-\contentsline {subsubsection}{install-haproxy.yml}{51}{section*.81}
-\contentsline {subsubsection}{setup-infrastructure.yml}{51}{section*.82}
-\contentsline {subsubsection}{setup-openstack.yml}{52}{section*.83}
-\contentsline {section}{\numberline {4.6}Verificaci\IeC {\'o}n}{52}{section.4.6}
-\contentsline {chapter}{\numberline {5}Interaccci\IeC {\'o}n}{53}{chapter.5}
-\contentsline {section}{\numberline {5.1}Configuraciones de administrador}{54}{section.5.1}
-\contentsline {subsubsection}{Crear proyecto}{54}{section*.85}
-\contentsline {subsubsection}{Crear usuario}{55}{section*.88}
-\contentsline {subsubsection}{Crear flavor}{56}{section*.90}
-\contentsline {subsubsection}{Crear provider network}{58}{section*.93}
-\contentsline {section}{\numberline {5.2}Interacci\IeC {\'o}n de un usuario}{59}{section.5.2}
-\contentsline {subsubsection}{Crear imagen}{59}{section*.96}
-\contentsline {subsubsection}{Crear red}{61}{section*.99}
-\contentsline {subsubsection}{Crear router}{63}{section*.103}
-\contentsline {subsubsection}{Crear interfaz de router}{63}{section*.105}
-\contentsline {subsubsection}{Crear key pair}{64}{section*.107}
-\contentsline {subsubsection}{Lanzar una instancia}{64}{section*.109}
-\contentsline {section}{\numberline {5.3}Acceso a una instancia}{67}{section.5.3}
-\contentsline {subsection}{\numberline {5.3.1}Por SPICE}{67}{subsection.5.3.1}
-\contentsline {subsection}{\numberline {5.3.2}Por SSH}{68}{subsection.5.3.2}
-\contentsline {subsubsection}{Asociar una Floating IP a la instancia}{68}{section*.115}
-\contentsline {subsubsection}{Modificar security group}{68}{section*.118}
-\contentsline {subsubsection}{SSH}{70}{section*.122}
-\contentsline {chapter}{\numberline {6}Inconvenientes}{71}{chapter.6}
-\contentsline {subsubsection}{Bloqueo de paquetes}{71}{section*.123}
-\contentsline {subsubsection}{M\IeC {\'o}dulo de seguridad SELinux}{71}{section*.124}
-\contentsline {subsubsection}{Percona-release en playbook setup-infrastructure}{71}{section*.125}
-\contentsline {subsubsection}{Subred reservada}{72}{section*.126}
-\contentsline {chapter}{\numberline {7}Trabajo a futuro}{73}{chapter.7}
-\contentsline {subsubsection}{Firewall}{73}{section*.127}
-\contentsline {chapter}{\numberline {8}Conclusiones}{74}{chapter.8}
+\contentsline {subparagraph}{Galera - MariaDB}{21}{section*.35}
+\contentsline {subparagraph}{Message queue}{22}{section*.36}
+\contentsline {subparagraph}{Memcached}{22}{section*.37}
+\contentsline {section}{\numberline {3.5}M\IeC {\'e}todos de instalaci\IeC {\'o}n}{22}{section.3.5}
+\contentsline {subsection}{\numberline {3.5.1}Ansible}{23}{subsection.3.5.1}
+\contentsline {subparagraph}{Nodo de control}{23}{section*.38}
+\contentsline {subparagraph}{Inventario}{23}{section*.39}
+\contentsline {subparagraph}{M\IeC {\'o}dulos}{23}{section*.40}
+\contentsline {subparagraph}{Tarea}{23}{section*.41}
+\contentsline {subparagraph}{Playbook}{23}{section*.42}
+\contentsline {section}{\numberline {3.6}Arquitectura}{23}{section.3.6}
+\contentsline {subsection}{\numberline {3.6.1}Arquitectura de red}{24}{subsection.3.6.1}
+\contentsline {subparagraph}{Management Network}{24}{section*.44}
+\contentsline {subparagraph}{Overlay Network}{24}{section*.45}
+\contentsline {subparagraph}{Storage Network}{24}{section*.46}
+\contentsline {subsubsection}{Interfaces de red}{24}{section*.47}
+\contentsline {section}{\numberline {3.7}Configuraci\IeC {\'o}n OSA}{28}{section.3.7}
+\contentsline {subsection}{\numberline {3.7.1}Convenciones}{28}{subsection.3.7.1}
+\contentsline {subsection}{\numberline {3.7.2}Inventario}{29}{subsection.3.7.2}
+\contentsline {subsection}{\numberline {3.7.3}openstack\_user\_config.yml}{29}{subsection.3.7.3}
+\contentsline {chapter}{\numberline {4}Instalaci\IeC {\'o}n}{30}{chapter.4}
+\contentsline {section}{\numberline {4.1}Dise\IeC {\~n}o de arquitectura}{30}{section.4.1}
+\contentsline {section}{\numberline {4.2}Ambiente de trabajo}{32}{section.4.2}
+\contentsline {subsection}{\numberline {4.2.1}Hardware utilizado}{32}{subsection.4.2.1}
+\contentsline {subsection}{\numberline {4.2.2}Conexi\IeC {\'o}n remota hacia el servidor renata}{33}{subsection.4.2.2}
+\contentsline {subsection}{\numberline {4.2.3}Virtualizaci\IeC {\'o}n con KVM}{33}{subsection.4.2.3}
+\contentsline {subsubsection}{Utilizaci\IeC {\'o}n virt-manager}{34}{section*.55}
+\contentsline {subsection}{\numberline {4.2.4}Especificaciones servidor renata}{41}{subsection.4.2.4}
+\contentsline {subsection}{\numberline {4.2.5}Acceso al exterior desde nodos}{42}{subsection.4.2.5}
+\contentsline {section}{\numberline {4.3}Preparaci\IeC {\'o}n de nodos}{42}{section.4.3}
+\contentsline {subsubsection}{Deploy}{43}{section*.73}
+\contentsline {subsubsection}{Infra1}{44}{section*.75}
+\contentsline {subsubsection}{Compute1}{46}{section*.76}
+\contentsline {subsubsection}{Storage1}{47}{section*.77}
+\contentsline {subsubsection}{HAproxy1}{47}{section*.78}
+\contentsline {section}{\numberline {4.4}Configuraci\IeC {\'o}n}{48}{section.4.4}
+\contentsline {subsection}{\numberline {4.4.1}Configuraci\IeC {\'o}n claves SSH}{48}{subsection.4.4.1}
+\contentsline {subsection}{\numberline {4.4.2}Archivos de configuraci\IeC {\'o}n OSA}{49}{subsection.4.4.2}
+\contentsline {subsubsection}{openstack\_user\_config.yml}{49}{section*.79}
+\contentsline {subsubsection}{user\_variables.yml}{51}{section*.80}
+\contentsline {subsubsection}{cinder.yml}{52}{section*.81}
+\contentsline {subsection}{\numberline {4.4.3}Generaci\IeC {\'o}n de claves}{52}{subsection.4.4.3}
+\contentsline {subsection}{\numberline {4.4.4}Correcciones}{52}{subsection.4.4.4}
+\contentsline {subsubsection}{SELinux}{52}{section*.82}
+\contentsline {section}{\numberline {4.5}Ejecuci\IeC {\'o}n de playbooks}{53}{section.4.5}
+\contentsline {subsubsection}{setup-hosts.yml}{53}{section*.83}
+\contentsline {subsubsection}{install-haproxy.yml}{53}{section*.84}
+\contentsline {subsubsection}{setup-infrastructure.yml}{53}{section*.85}
+\contentsline {subsubsection}{setup-openstack.yml}{54}{section*.86}
+\contentsline {section}{\numberline {4.6}Verificaci\IeC {\'o}n}{54}{section.4.6}
+\contentsline {chapter}{\numberline {5}Interaccci\IeC {\'o}n}{55}{chapter.5}
+\contentsline {section}{\numberline {5.1}Configuraciones de administrador}{56}{section.5.1}
+\contentsline {subsubsection}{Crear proyecto}{56}{section*.88}
+\contentsline {subsubsection}{Crear usuario}{57}{section*.91}
+\contentsline {subsubsection}{Crear flavor}{58}{section*.93}
+\contentsline {subsubsection}{Crear provider network}{60}{section*.96}
+\contentsline {section}{\numberline {5.2}Interacci\IeC {\'o}n de un usuario}{61}{section.5.2}
+\contentsline {subsubsection}{Crear imagen}{61}{section*.99}
+\contentsline {subsubsection}{Crear red}{63}{section*.102}
+\contentsline {subsubsection}{Crear router}{65}{section*.106}
+\contentsline {subsubsection}{Crear interfaz de router}{65}{section*.108}
+\contentsline {subsubsection}{Crear key pair}{66}{section*.110}
+\contentsline {subsubsection}{Lanzar una instancia}{66}{section*.112}
+\contentsline {section}{\numberline {5.3}Acceso a una instancia}{69}{section.5.3}
+\contentsline {subsection}{\numberline {5.3.1}Por SPICE}{69}{subsection.5.3.1}
+\contentsline {subsection}{\numberline {5.3.2}Por SSH}{70}{subsection.5.3.2}
+\contentsline {subsubsection}{Asociar una Floating IP a la instancia}{70}{section*.118}
+\contentsline {subsubsection}{Modificar security group}{70}{section*.121}
+\contentsline {subsubsection}{SSH}{72}{section*.125}
+\contentsline {chapter}{\numberline {6}Inconvenientes}{73}{chapter.6}
+\contentsline {subsubsection}{Bloqueo de paquetes}{73}{section*.126}
+\contentsline {subsubsection}{M\IeC {\'o}dulo de seguridad SELinux}{73}{section*.127}
+\contentsline {subsubsection}{Percona-release en playbook setup-infrastructure}{73}{section*.128}
+\contentsline {subsubsection}{Subred reservada}{74}{section*.129}
+\contentsline {chapter}{\numberline {7}Trabajo a futuro}{75}{chapter.7}
+\contentsline {subsubsection}{Firewall}{75}{section*.130}
+\contentsline {subsubsection}{Arquitectura segura}{75}{section*.131}
+\contentsline {subsubsection}{Brindar conexi\IeC {\'o}n directa a Internet}{75}{section*.132}
+\contentsline {subsubsection}{Gesti\IeC {\'o}n de Openstack en operaci\IeC {\'o}n}{75}{section*.133}
+\contentsline {chapter}{\numberline {8}Conclusiones}{76}{chapter.8}
diff --git a/docs/latex/resources/neutron3.png b/docs/latex/resources/neutron3.png
new file mode 100644
index 0000000000000000000000000000000000000000..621c09648335e6d13d5500fac5d5f57371675495
Binary files /dev/null and b/docs/latex/resources/neutron3.png differ