diff --git a/docs/udelartex/anexo/anexoInteraccion.tex b/docs/udelartex/anexo/anexoInteraccion.tex
index 746945a3de21b6544e0c2b9d98b65010d65242f0..60b7347de04cb370e2ba9679d1bc025d24309212 100644
--- a/docs/udelartex/anexo/anexoInteraccion.tex
+++ b/docs/udelartex/anexo/anexoInteraccion.tex
@@ -329,5 +329,5 @@ El administrador del Datacenter es capaz de acceder directamente a las instancia
\end{itemize}
\section*{Conclusiones}
-De esta sección se destaca la facilidad de uso que tiene la herramienta una vez que esta desplegada y operativamente funcional. La curva de aprendizaje es significativamente alta dado que para una persona con ciertos conocimientos en redes o administración de sistemas el dashboard proporcionado por Horizon resulta muy intuitivo para realizar tareas como: agregar una nueva instancia, administración de usuarios y roles, creación de redes tenants y provider, entre otras. Además de lo funcional, los dashboards con información de los recursos asignados a los proyectos junto a que porción de los mismos están siendo utilizados son muy útiles tanto para los usuarios como administradores.
+De esta sección se destaca la facilidad de uso que tiene la herramienta una vez que está desplegada y operativa. La curva de aprendizaje es significativamente baja dado que para una persona con ciertos conocimientos en redes o administración de sistemas el dashboard proporcionado por Horizon resulta muy intuitivo para realizar tareas como: agregar una nueva instancia, administración de usuarios y roles, creación de redes tenants y provider, entre otras. Además de lo funcional, los dashboards con información de los recursos asignados a los proyectos junto a qué porción de los mismos están siendo utilizados son muy útiles tanto para los usuarios como administradores.
diff --git a/docs/udelartex/anexo/anexoMigrateInstance.tex b/docs/udelartex/anexo/anexoMigrateInstance.tex
index b5e17fac83ea88953cdb249a746d1a2726d7120b..f5c29fc580ddafad0cacf65a8ef89a945c2417fe 100644
--- a/docs/udelartex/anexo/anexoMigrateInstance.tex
+++ b/docs/udelartex/anexo/anexoMigrateInstance.tex
@@ -4,29 +4,30 @@
# Provide usage
usage() {
-echo "Usage: $0 VM_ID"
-exit 1
+ echo "Usage: $0 VM_ID"
+ exit 1
}
+
[[ $# -eq 0 ]] && usage
-# Migrate the VM to an alternate hypervisor
-echo -n "Migrating instance to alternate host"
VM_ID=$1
-openstack server migrate $VM_ID
-VM_OUTPUT=$(openstack server show $VM_ID)
-VM_STATUS=$(echo "$VM_OUTPUT" | grep status | awk '{print $4}')
-while [[ "$VM_STATUS" != "VERIFY_RESIZE" ]]; do
-echo -n "."
-sleep 2
-VM_OUTPUT=$(openstack server show $VM_ID)
-VM_STATUS=$(echo "$VM_OUTPUT" | grep status | awk '{print $4}')
+
+# Show the details for the VM
+echo "Instance details:"
+openstack server show ${VM_ID}
+
+# Migrate the VM to an alternate hypervisor
+echo -n "Migrating instance to alternate host "
+openstack server migrate ${VM_ID}
+while [[ "$(openstack server show ${VM_ID} -f value -c status)" != "VERIFY_RESIZE" ]]; do
+ echo -n "."
+ sleep 2
done
-nova resize-confirm $VM_ID
+openstack server resize --confirm ${VM_ID}
echo " instance migrated and resized."
-echo;
-# Show the details for the VM
-echo "Updated instance details:"
-openstack server show $VM_ID
+# Show the details for the migrated VM
+echo "Migrated instance details:"
+openstack server show ${VM_ID}
# Pause to allow users to examine VM details
read -p "Pausing, press <enter> to exit."
diff --git a/docs/udelartex/anexo/anexoQueens.tex b/docs/udelartex/anexo/anexoQueens.tex
index 4aac5562583840c601d8581e47f26afea84593d0..375f050a74cdb977eef60eaa8a71175d56d0a864 100644
--- a/docs/udelartex/anexo/anexoQueens.tex
+++ b/docs/udelartex/anexo/anexoQueens.tex
@@ -6,7 +6,7 @@ Queens es la décimo séptima versión liberada por OpenStack. La misma fue publ
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}
+\subsection*{Deploy}
\begin{enumerate}
\item Configurar la interfaz de red eth0 de la siguiente forma:
\lstinputlisting{chap4/deploy/eth0}
@@ -96,7 +96,7 @@ $ mkdir /var/log/openstack
\end{enumerate}
-\subsubsection{Infra1}
+\subsection*{Infra1}
\begin{enumerate}
\item Configuraciones de red:
\begin{enumerate}[label*=\arabic*.]
@@ -222,7 +222,7 @@ $ iptables-restore < /etc/sysconfig/iptables
\end{enumerate}
-\subsubsection{Compute1}
+\subsection*{Compute1}
\begin{enumerate}
\item Configuraciones de red:
\begin{enumerate}[label*=\arabic*.]
@@ -276,7 +276,7 @@ $ hostname compute1
A partir de este punto, el procedimiento es idéntico al nodo infra1. Se deben realizar los puntos 4 al 11.
-\subsubsection{Storage1}
+\subsection*{Storage1}
\begin{enumerate}
\item Configuraciones de red:
\begin{enumerate}[label*=\arabic*.]
@@ -346,7 +346,7 @@ $ vgdisplay
\end{enumerate}
-\subsubsection{HAproxy1}
+\subsection*{HAproxy1}
\begin{enumerate}
\item Configurar las interfaces eth0 y eth1.
\begin{multicols}{2}
@@ -404,7 +404,7 @@ Para verificar la configuración bastará con realizar un ssh a cada servidor de
\subsection{Archivos de configuración OSA}
-\subsubsection{openstack\_user\_config.yml}
+\subsubsection*{openstack\_user\_config.yml}
A continuación se muestra las configuraciones utilizadas en el archivo, el significado de cada sección fue explicado en \ref{sec:openstack-user-config}.
\begin{lstlisting}
@@ -548,7 +548,7 @@ storage_hosts:
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}
+\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]
@@ -582,7 +582,7 @@ horizon_images_upload_mode: "legacy"
Si bien en \cite{openstack-settings-reference} se menciona que el valor por defecto de esta variable es \textsl{legacy}, durante el proceso de instalación se detectó que es configurada como \textsl{direct}. La diferencia entre estos modos es que \textsl{legacy} permite subir archivos locales desde la máquina del usuario al servidor web de Horizon y luego de este hacia el módulo Glance. Por su parte \textsl{direct} evita esta sobrecarga de red y almacenamiento en el servidor web, conectado a través de una API al usuario con el módulo Glance. Sin embargo, esto último requiere de configuraciones extras como tener acceso al puerto 9292 (API de Glance) y un correcto uso de CORS.
-\subsubsection{cinder.yml}
+\subsubsection*{cinder.yml}
En caso de utilizar un backend de storage LVM se debe indicar que este debe ser desplegado en metal, para esto se debe configurar el archivo \path{/etc/openstack_deploy/env.d/cinder-volume.yml} con lo siguiente:
\begin{lstlisting}
diff --git a/docs/udelartex/anexo/anexoStein.tex b/docs/udelartex/anexo/anexoStein.tex
index 953903a256450bbd9e76d59c711f3eaae3fd908e..4b0f5aad5842bd70dc26228ab9dba99b50501e8d 100644
--- a/docs/udelartex/anexo/anexoStein.tex
+++ b/docs/udelartex/anexo/anexoStein.tex
@@ -7,7 +7,7 @@ Al bridge br-mgmt ubicado en el servidor fÃsico renata y conectado a la interfa
Preparación de nodos
En esta sección se detallan los pasos necesarios a seguir en cada uno de los nodos para iniciar con la instalación de OpenStack. Al igual que en la instalación previa es necesario contar con conexión a internet en todos los nodos. La guÃa de referencia utilizada para setear el ambiente se encuentra en [página de openstack].
-\subsubsection{Deploy}
+\subsection*{Deploy}
\begin{enumerate}
\item Configurar la interfaces de red eth0 de la siguiente forma:
\lstinputlisting{chap5/deploy/eth0}
@@ -92,7 +92,7 @@ $ mkdir /var/log/openstack
\end{enumerate}
-\subsubsection{Infra1}
+\subsection*{Infra1}
\begin{enumerate}
\item Configuraciones de red:
\begin{enumerate}[label*=\arabic*.]
@@ -223,7 +223,7 @@ $ iptables-restore < /etc/sysconfig/iptables
\end{enumerate}
-\subsubsection{Compute1}
+\subsection*{Compute1}
\begin{enumerate}
\item Configuraciones de red:
\begin{enumerate}[label*=\arabic*.]
@@ -283,10 +283,10 @@ $ hostname compute1
A partir de este punto, el procedimiento es idéntico al nodo infra1. Se deben realizar los puntos 4 al 11.
-\subsubsection{Compute2}
+\subsection*{Compute2}
La configuración de este nodo es análoga a la del compute1 salvando la diferencias de IPs.
-\subsubsection{Storage1}
+\subsection*{Storage1}
\begin{enumerate}
\item Configuraciones de red:
\begin{enumerate}[label*=\arabic*.]
@@ -337,10 +337,10 @@ $ pvcreate --metadatasize 2048 physical_volume_device_path
\end{enumerate}
-\subsubsection{Storage2}
+\subsection*{Storage2}
La configuración de este nodo es análoga a la del storage1 salvando la diferencias de IPs.
-\subsubsection{HAproxy1}
+\subsection*{HAproxy1}
\begin{enumerate}
\item Configurar las interfaces eth0 y eth1.
\begin{multicols}{2}
@@ -368,7 +368,7 @@ $ hostname haproxy1
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.
-\subsubsection{Router}
+\subsection*{Router}
\begin{enumerate}
\item Configuraciones de red:
\begin{enumerate}[label*=\arabic*.]
@@ -536,7 +536,7 @@ La configuración de las claves SSH se realiza de forma análoga a la realizada
\section{Configuración archivos OSA}
-\subsubsection{openstack\_user\_config.yml}
+\subsection*{openstack\_user\_config.yml}
A continuación se detalla cada bloque de configuración utilizado para esta instalación haciendo especial hincapié en las modificaciones realizadas para adaptar la playbook a la nueva arquitectura planteada, en donde se utiliza ceph como el backend de cinder, se habilitan tres tipos de redes para instanciar en Openstack (flat, vlan y vxlan) y se agregan nuevos nodos.
\noindent En la sección \path{cidr_networks} se describen las subredes utilizadas, la finalidad de las mismas es análoga a la explicada para Queens.
@@ -772,7 +772,7 @@ cinder_backends:
\end{lstlisting}
-\subsubsection{cinder.yml}
+\subsection*{cinder.yml}
\noindent En este caso el despliegue de ceph se debe indicar que no será en metal dado que se crearan los osd en los nodos de storage.
\begin{lstlisting}
container_skel:
diff --git a/docs/udelartex/bibliografia/biblio.bib b/docs/udelartex/bibliografia/biblio.bib
index 52a4ff598324ed01198e7e2b3d3477307962d6b3..b6294634d44b7d0b8774aa6b0d521c382cd104f7 100644
--- a/docs/udelartex/bibliografia/biblio.bib
+++ b/docs/udelartex/bibliografia/biblio.bib
@@ -7,35 +7,35 @@ note = {Accedido: 2019-06-15}
@Misc{openstack-basic-networking,
title = {Basic networking},
-author = {Openstack},
+author = {OpenStack},
howpublished = {\url{https://docs.openstack.org/mitaka/networking-guide/intro-basic-networking.html}},
note = {Accedido: 2019-06-15}
}
@Misc{openstack-networking-concepts,
title = {Networking concepts},
-author = {Openstack},
+author = {OpenStack},
howpublished = {\url{https://docs.openstack.org/arch-design/design-networking/design-networking-concepts.html}},
note = {Accedido: 2019-06-15}
}
@Misc{openstack-history,
title = {Introduction},
-author = {Openstack},
+author = {OpenStack},
howpublished = {\url{https://docs.openstack.org/project-team-guide/introduction.html}},
note = {Accedido: 2019-06-15}
}
@Misc{openstack-software,
title = {Software},
-author = {Openstack},
+author = {OpenStack},
howpublished = {\url{https://www.openstack.org/software/}},
note = {Accedido: 2019-06-15}
}
@Misc{openstack-keystone-architecture,
title = {Keystone Architecture},
-author = {Openstack},
+author = {OpenStack},
howpublished = {\url{https://docs.openstack.org/keystone/latest/getting-started/architecture.html}},
note = {Accedido: 2019-06-20}
}
@@ -137,284 +137,305 @@ note = {Accedido: 2019-06-20}
@Misc{openstack-design,
title = {Design},
-author = {Openstack},
+author = {OpenStack},
howpublished = {\url{https://docs.openstack.org/arch-design/design.html}},
note = {Accedido: 2019-06-20}
}
@Misc{openstack-control-plane,
title = {Control plane architecture},
-author = {Openstack},
+author = {OpenStack},
howpublished = {\url{https://docs.openstack.org/arch-design/design-control-plane.html}},
note = {Accedido: 2019-06-20}
}
@Misc{openstack-conductor,
title = {Conductor as a place for orchestrating tasks},
-author = {Openstack},
+author = {OpenStack},
howpublished = {\url{https://docs.openstack.org/nova/rocky/user/conductor.html}},
note = {Accedido: 2019-06-20}
}
@Misc{openstack-compute-overview,
title = {Compute service overview},
-author = {Openstack},
+author = {OpenStack},
howpublished = {\url{https://docs.openstack.org/nova/latest/install/get-started-compute.html}},
note = {Accedido: 2019-06-20}
}
@Misc{openstack-memcached,
title = {Memcached},
-author = {Openstack},
+author = {OpenStack},
howpublished = {\url{https://docs.openstack.org/mitaka/install-guide-ubuntu/environment-memcached.html}},
note = {Accedido: 2019-06-20}
}
@Misc{openstack-messaging,
title = {Message queuing},
-author = {Openstack},
+author = {OpenStack},
howpublished = {\url{https://docs.openstack.org/security-guide/messaging.htmll}},
note = {Accedido: 2019-06-20}
}
@Misc{openstack-lvm,
title = {LVM},
-author = {Openstack},
+author = {OpenStack},
howpublished = {\url{https://docs.openstack.org/cinder/latest/configuration/block-storage/drivers/lvm-volume-driver.html}},
note = {Accedido: 2019-06-20}
}
@Misc{openstack-volume-drivers,
title = {Volume drivers},
-author = {Openstack},
+author = {OpenStack},
howpublished = {\url{https://docs.openstack.org/cinder/latest/configuration/block-storage/volume-drivers.html}},
note = {Accedido: 2019-06-20}
}
@Misc{openstack-inventory,
title = {Iventory},
-author = {Openstack},
+author = {OpenStack},
howpublished = {\url{https://docs.openstack.org/openstack-ansible/rocky/reference/inventory/inventory.html}},
note = {Accedido: 2019-06-20}
}
@Misc{openstack-user-config,
title = {openstack\_user\_config settings reference},
-author = {Openstack},
+author = {OpenStack},
howpublished = {\url{https://docs.openstack.org/openstack-ansible/queens/reference/inventory/openstack-user-config-reference.html}},
note = {Accedido: 2019-06-20}
}
@Misc{openstack-image-properties-1,
title = {Common Image Properties},
-author = {Openstack},
+author = {OpenStack},
howpublished = {\url{https://docs.openstack.org/glance/queens/user/common-image-properties.html}},
note = {Accedido: 2019-06-20}
}
@Misc{openstack-image-properties-2,
title = {Useful image properties},
-author = {Openstack},
+author = {OpenStack},
howpublished = {\url{https://docs.openstack.org/glance/latest/admin/useful-image-properties.html}},
note = {Accedido: 2019-06-20}
}
@Misc{openstack-images-instances,
title = {Images and instances},
-author = {Openstack},
+author = {OpenStack},
howpublished = {\url{https://docs.openstack.org/glance/queens/admin/troubleshooting.html}},
note = {Accedido: 2019-06-20}
}
@Misc{openstack-storage-api,
title = {Object Storage API overview},
-author = {Openstack},
+author = {OpenStack},
howpublished = {\url{https://docs.openstack.org/swift/latest/api/object_api_v1_overview.html}},
note = {Accedido: 2019-07-05}
}
@Misc{openstack-storage-characteristics,
title = {Object Storage characteristics},
-author = {Openstack},
+author = {OpenStack},
howpublished = {\url{https://docs.openstack.org/swift/latest/admin/objectstorage-characteristics.html}},
note = {Accedido: 2019-07-05}
}
@Misc{openstack-storage-intro,
title = {Introduction to Object Storage},
-author = {Openstack},
+author = {OpenStack},
howpublished = {\url{https://docs.openstack.org/swift/latest/admin/objectstorage-intro.html}},
note = {Accedido: 2019-07-05}
}
@Misc{openstack-storage-components,
title = {Components},
-author = {Openstack},
+author = {OpenStack},
howpublished = {\url{https://docs.openstack.org/swift/latest/admin/objectstorage-components.html}},
note = {Accedido: 2019-07-05}
}
@Misc{openstack-storage-architect,
title = {Swift Architectural Overview},
-author = {Openstack},
+author = {OpenStack},
howpublished = {\url{https://docs.openstack.org/swift/latest/overview_architecture.html}},
note = {Accedido: 2019-07-05}
}
@Misc{openstack-puppet,
title = {Welcome to the Puppet OpenStack Guide!},
-author = {Openstack},
+author = {OpenStack},
howpublished = {\url{https://docs.openstack.org/puppet-openstack-guide/latest/}},
note = {Accedido: 2019-07-05}
}
@Misc{openstack-ansible,
title = {OpenStack-Ansible Documentation},
-author = {Openstack},
+author = {OpenStack},
howpublished = {\url{https://docs.openstack.org/openstack-ansible/latest/}},
note = {Accedido: 2019-07-05}
}
@Misc{openstack-marketplace,
title = {The OpenStack Marketplace},
-author = {Openstack},
+author = {OpenStack},
howpublished = {\url{https://www.openstack.org/marketplace/distros/}},
note = {Accedido: 2019-07-05}
}
@Misc{openstack-nova-architecture,
title = {Nova System Architecture},
-author = {Openstack},
+author = {OpenStack},
howpublished = {\url{https://docs.openstack.org/nova/latest/user/architecture.html}},
note = {Accedido: 2019-07-05}
}
@Misc{openstack-glance-architecture,
title = {Basic architecture},
-author = {Openstack},
+author = {OpenStack},
howpublished = {\url{https://docs.openstack.org/glance/queens/contributor/architecture.html}},
note = {Accedido: 2019-07-05}
}
@Misc{openstack-container-networking,
title = {Container networking},
-author = {Openstack},
+author = {OpenStack},
howpublished = {\url{https://docs.openstack.org/openstack-ansible/rocky/reference/architecture/container-networking.html}},
note = {Accedido: 2019-07-05}
}
@Misc{openstack-networking-architecture,
title = {Network architectures},
-author = {Openstack},
+author = {OpenStack},
howpublished = {\url{https://docs.openstack.org/openstack-ansible/stein/user/network-arch/example.html}},
note = {Accedido: 2019-07-05}
}
@Misc{openstack-appendix-e,
title = {Appendix E: Container networking},
-author = {Openstack},
+author = {OpenStack},
howpublished = {\url{https://docs.openstack.org/project-deploy-guide/openstack-ansible/ocata/app-networking.html#network-diagrams}},
note = {Accedido: 2019-07-05}
}
@Misc{openstack-selinux-fix-1,
title = {AIO Build Fails on SELinux File Context Tasks},
-author = {Openstack},
+author = {OpenStack},
howpublished = {\url{https://bugs.launchpad.net/openstack-ansible/+bug/1782798}},
note = {Accedido: 2019-07-05}
}
@Misc{openstack-selinux-fix-2,
title = {Drop SELinux support for CentOS 7},
-author = {Openstack},
+author = {OpenStack},
howpublished = {\url{https://review.opendev.org/#/c/603860/}},
note = {Accedido: 2019-07-05}
}
@Misc{openstack-projects-users,
title = {Manage projects and users},
-author = {Openstack},
+author = {OpenStack},
howpublished = {\url{https://docs.openstack.org/horizon/latest/admin/manage-projects-and-users.html}},
note = {Accedido: 2019-08-03}
}
@Misc{openstack-manage-flavors,
title = {Manage flavors},
-author = {Openstack},
+author = {OpenStack},
howpublished = {\url{https://docs.openstack.org/horizon/latest/admin/manage-flavors.html}},
note = {Accedido: 2019-08-03}
}
@Misc{openstack-settings-reference,
title = {Settings Reference},
-author = {Openstack},
+author = {OpenStack},
howpublished = {\url{https://docs.openstack.org/horizon/queens/configuration/settings.html}},
note = {Accedido: 2019-08-04}
}
@Misc{openstack-obtain-images,
title = {Get images},
-author = {Openstack},
+author = {OpenStack},
howpublished = {\url{https://docs.openstack.org/image-guide/obtain-images.html}},
note = {Accedido: 2019-08-04}
}
@Misc{openstack-manage-networks,
title = {Create and manage networks},
-author = {Openstack},
+author = {OpenStack},
howpublished = {\url{https://docs.openstack.org/horizon/latest/user/create-networks.html}},
note = {Accedido: 2019-08-03}
}
@Misc{openstack-security-instances,
title = {Configure access and security for instances},
-author = {Openstack},
+author = {OpenStack},
howpublished = {\url{https://docs.openstack.org/horizon/latest/user/configure-access-and-security-for-instances.html}},
note = {Accedido: 2019-08-03}
}
@Misc{openstack-manage-instances,
title = {Launch and manage instances},
-author = {Openstack},
+author = {OpenStack},
howpublished = {\url{https://docs.openstack.org/horizon/latest/user/launch-instances.html}},
note = {Accedido: 2019-08-03}
}
@Misc{openstack-network-namespaces,
title = {Nework namespaces},
-author = {Openstack},
+author = {OpenStack},
howpublished = {\url{https://docs.openstack.org/neutron/pike/admin/intro-network-namespaces.html}},
note = {Accedido: 2020-01-08}
}
@Misc{openstack-using-openvswitch,
title = {Scenario - Using Open vSwitch},
- author = {Openstack},
+ author = {OpenStack},
howpublished = {\url{https://docs.openstack.org/openstack-ansible-os_neutron/latest/app-openvswitch.html}},
note = {Accedido: 2020-01-12}
}
@Misc{openstack-verify-cloud,
title = {Verify OpenStack-Ansible Cloud},
- author = {Openstack},
+ author = {OpenStack},
howpublished = {\url{https://docs.openstack.org/openstack-ansible/latest/admin/openstack-firstrun.html}},
note = {Accedido: 2020-01-12}
}
@Misc{openstack-maintenance-tasks,
title = {Maintenance tasks},
- author = {Openstack},
+ author = {OpenStack},
howpublished = {\url{https://docs.openstack.org/openstack-ansible/latest/admin/maintenance-tasks.html}},
note = {Accedido: 2020-01-12}
}
@Misc{openstack-troubleshooting,
title = {Troubleshooting},
- author = {Openstack},
+ author = {OpenStack},
howpublished = {\url{https://docs.openstack.org/openstack-ansible/latest/admin/troubleshooting.html}},
note = {Accedido: 2020-01-12}
}
+@Misc{openstack-bug-container-lxc,
+ title = {Redhat: stop updating system unnecessarily},
+ author = {GitHub},
+ howpublished = {\url{https://github.com/openstack/openstack-ansible-lxc_container_create/commit/b15b97fa0ab73579e4939ae767a2810196b33df2#diff-0dc9e326c64f4a15341a43e16b94ee60}},
+ note = {Accedido: 2020-01-22}
+}
+
+@Misc{openstack-migration,
+ title = {Migrate instances},
+ author = {OpenStack},
+ howpublished = {\url{https://docs.openstack.org/nova/stein/admin/migration.html}},
+ note = {Accedido: 2020-01-22}
+}
+
+@Misc{openstack-ssh-between-compute,
+ title = {Configure SSH between compute nodes},
+ author = {OpenStack},
+ howpublished = {\url{https://docs.openstack.org/nova/stein/admin/ssh-configuration.html#cli-os-migrate-cfg-ssh}},
+ note = {Accedido: 2020-01-22}
+}
+
@Misc{ansible-modules,
title = {Module Index},
author = {Ansible},
diff --git a/docs/udelartex/capitulos/futuro.tex b/docs/udelartex/capitulos/futuro.tex
index 20f1e601c47b8ceb4881e17edd122a21c42a7e75..f624050342cf93fa5e729709106cdabd0a3031b4 100644
--- a/docs/udelartex/capitulos/futuro.tex
+++ b/docs/udelartex/capitulos/futuro.tex
@@ -1,13 +1,13 @@
\chapter{Trabajo a futuro}
-\subsubsection{Firewall}
+\section*{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.
-\subsubsection{Arquitectura segura}
+\section*{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}
+\section*{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}
+\section*{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.
\ No newline at end of file
diff --git a/docs/udelartex/capitulos/gestion.tex b/docs/udelartex/capitulos/gestion.tex
index 0fc7bfa54f52767098b2253092d06534faaa9c65..521e8c18558f94f118ce87dbdce3fffe7e779822 100644
--- a/docs/udelartex/capitulos/gestion.tex
+++ b/docs/udelartex/capitulos/gestion.tex
@@ -13,23 +13,23 @@ Los servicios subyacentes de infraestructura que permiten el funcionamiento de O
\begin{itemize}
\item Revisar el estado del cluster de galera desde el nodo de deploy:
\begin{lstlisting}
-$ ansible -i /opt/openstack-ansible/inventory/dynamic_inventory.py galera_container -m shell -a "mysql -h 127.0.0.1 -e 'show status like \"%wsrep_cluster_%\";'"
+# ansible -i /opt/openstack-ansible/inventory/dynamic_inventory.py galera_container -m shell -a "mysql -h 127.0.0.1 -e 'show status like \"%wsrep_cluster_%\";'"
\end{lstlisting}
\item Revisar el estado del cluster de RabbitMQ desde el nodo de deploy:
\begin{lstlisting}
-$ ansible -i /opt/openstack-ansible/inventory/dynamic_inventory.py rabbit_mq_container -m shell -a "rabbitmqctl cluster_status"
+# ansible -i /opt/openstack-ansible/inventory/dynamic_inventory.py rabbit_mq_container -m shell -a "rabbitmqctl cluster_status"
\end{lstlisting}
Este comando puede llegar a fallar por un bug que presenta Ansible y en su lugar se debe ejecutar el siguiente comando:
\begin{lstlisting}
-$ ansible -i /opt/openstack-ansible/inventory/dynamic_inventory.py rabbit_mq_container -m shell -a "rabbitmqctl -n rabbit@<hostname_contenedor_rabbit> cluster_status"
+# ansible -i /opt/openstack-ansible/inventory/dynamic_inventory.py rabbit_mq_container -m shell -a "rabbitmqctl -n rabbit@<hostname_contenedor_rabbit> cluster_status"
\end{lstlisting}
\item En el firewall de los nodos fÃsicos es importante verificar la existencia de reglas que filtren tráfico válido. Como se mencionó en la sección de preparación de nodos en los capÃtulos donde se detalla el proceso de instalación, se deben eliminar las siguientes reglas en caso de estar presentes:
\begin{lstlisting}
-$ iptables -D INPUT -j REJECT --reject-with icmp-host-prohibited
-$ iptables -D FORWARD -j REJECT --reject-with icmp-host-prohibited
+# iptables -D INPUT -j REJECT --reject-with icmp-host-prohibited
+# iptables -D FORWARD -j REJECT --reject-with icmp-host-prohibited
\end{lstlisting}
\end{itemize}
@@ -45,23 +45,23 @@ Además de los problemas crÃticos mencionados, se pueden presentar inconvenient
\begin{itemize}
\item Ver el estado del cluster desde el contenedor \path{ceph_mon}:
\begin{lstlisting}
-$ ceph health o ceph health detail
+# ceph health o ceph health detail
\end{lstlisting}
\item Desde los nodos OSD:
\begin{itemize}
\item Ver el status de todos los demonios:
\begin{lstlisting}
-$ systemctl status ceph\*.service ceph\*.target
+# systemctl status ceph\*.service ceph\*.target
\end{lstlisting}
\item Parar todos los demonios:
\begin{lstlisting}
-$ systemctl stop ceph\*.service ceph\*.target
+# systemctl stop ceph\*.service ceph\*.target
\end{lstlisting}
\item Arrancar todos los demonios:
\begin{lstlisting}
-$ systemctl start ceph.target
+# systemctl start ceph.target
\end{lstlisting}
\end{itemize}
@@ -73,7 +73,7 @@ $ systemctl start ceph.target
Para agregar un nuevo nodo de cómputo en el Datacenter desplegado con OSA se deben seguir las siguientes instrucciones tanto para la versión Queens como Stein.
\begin{enumerate}
- \item Configurar el nuevo nodo de cómputo de forma análoga a como se detalla en \ref{chap5:preparacion:nodos}.
+ \item Configurar el nuevo nodo de cómputo de forma análoga a como se detalla en la sección \ref{chap5:preparacion:nodos} del anexo \ref{anexoStein}.
\item Editar el archivo de configuración principal \path{/etc/openstack_deploy/openstack_user_config.yml}, agregando el nuevo nodo (en este ejemplo serÃa el compute2) en la sección \path{compute_host} de la siguiente forma:
\begin{lstlisting}
@@ -87,10 +87,10 @@ compute_hosts:
\item Ejecutar los siguientes comandos desde el nodo de deploy:
\begin{lstlisting}
-$ cd /opt/openstack-ansible/playbooks
-$ openstack-ansible setup-hosts.yml --limit localhost,compute2
-$ ansible nova_all -m setup -a 'filter=ansible_local gather_subset="!all"'
-$ openstack-ansible setup-openstack.yml --limit localhost,compute2
+# cd /opt/openstack-ansible/playbooks
+# openstack-ansible setup-hosts.yml --limit localhost,compute2
+# ansible nova_all -m setup -a 'filter=ansible_local gather_subset="!all"'
+# openstack-ansible setup-openstack.yml --limit localhost,compute2
\end{lstlisting}
\item Finalmente para verificar que la instalación quedó configurada correctamente se pueden ejecutar los siguientes comandos:
@@ -146,16 +146,24 @@ $ openstack-ansible setup-openstack.yml --limit localhost,compute2
Para eliminar un nodo de cómputo hay que asegurarse que no exista ninguna instancia corriendo en él, por lo tanto hay que migrar todas las instancias.
\subsubsection*{Migrar instancias}
-La guiá de referencia utilizada es [\path{https://docs.openstack.org/nova/stein/admin/migration.html}]. Previo a comenzar el proceso de migración es necesario asegurar el acceso SSH entre los nodos de cómputo para el usuario \path{nova}. Para esto se deben ejecutar los siguientes comandos:
+La guiá de referencia utilizada es \cite{openstack-migration}. Previo a comenzar el proceso de migración es necesario asegurar el acceso SSH entre los nodos de cómputo para el usuario \path{nova}. Para esto se deben ejecutar los siguientes comandos:
\begin{lstlisting}
-$ su - nova
+# su - nova
$ ssh <IP_nodo_computo>
$ exit
\end{lstlisting}
-Ante la presencia de problemas con las conexiones SSH se puede utilizar el siguiente documento de como referencia[\path{https://docs.openstack.org/nova/stein/admin/ssh-configuration.html#cli-os-migrate-cfg-ssh}].
+\noindent Ante la presencia de problemas con las conexiones SSH se puede utilizar el siguiente documento de como referencia \cite{openstack-ssh-between-compute}.
-El host al que se migra la instancia es elegido por el componente nova scheduler en base a su configuración. Para saber qué instancias es necesario migrar se puede ejecutar el comando mencionado en la sección anterior '\$ nova hypervisor-servers $<$nombre\_nodo$>$'. Previo a realizar la migración es importante tener en cuenta que el resto de los nodos de cómputo soporten la carga de las instancias alojadas. Para esto se utiliza el comando '\$ openstack host show $<$nodo\_computo$>$' el cual muestra para los recursos CPU, RAM y disco la cantidad total, la utilizada actualmente, la utilizada por todos los proyectos y al final lo utilizado por cada proyecto.
+El host al que se migra la instancia es elegido por el componente nova scheduler en base a su configuración. Para saber qué instancias es necesario migrar se puede ejecutar el comando mencionado en la sección anterior:
+\begin{lstlisting}
+# nova hypervisor-servers <nombre_nodo>
+\end{lstlisting}
+\noindent Previo a realizar la migración es importante tener en cuenta que el resto de los nodos de cómputo soporten la carga de las instancias alojadas. Para esto se utiliza el comando:
+\begin{lstlisting}
+# openstack host show <nodo_computo>
+\end{lstlisting}
+\noindent Este último indica para cada uno de los recursos CPU, RAM y disco: la cantidad total, la utilizada actualmente, la utilizada por todos los proyectos y al final lo utilizado por cada proyecto.
Para realizar la migración se puede utilizar simplemente el comando:
\begin{lstlisting}
@@ -165,34 +173,31 @@ Para realizar la migración se puede utilizar simplemente el comando:
Por otro lado para obtener el estado de la instancia en el proceso de migración se puede utilizar el script \path{migrate_instance.sh} ubicado en el anexo \ref{anexoMigrate} de la siguiente forma:
\begin{lstlisting}
-$ ./migrate_instance.sh <id_instancia>
+# ./migrate_instance.sh <id_instancia>
\end{lstlisting}
-En ambos casos los comandos se deben a ejecutar desde el contenedor de utility.\\
+\noindent En ambos casos los comandos se deben a ejecutar desde el contenedor de utility.\\
Retomando la acción principal, luego de migrar todas las instancias del nodo de computo a remover, se deben ejecutar los siguientes comandos:
\begin{itemize}
-\item Se deben detener todos los servicios de cómputo y red corriendo en el nodo:
+ \item Se deben detener todos los servicios de cómputo y red corriendo en el nodo:
\begin{lstlisting}
-$ systemctl stop nova-compute
-$ systemctl stop neutron-linuxbridge-agent
+# systemctl stop nova-compute
+# systemctl stop neutron-linuxbridge-agent
\end{lstlisting}
-\item Luego se debe clonar el repositorio de operaciones de OSA en el nodo deploy:
+ \item Luego se debe clonar el repositorio de operaciones de OSA en el nodo deploy:
\begin{lstlisting}
-$ git clone https://opendev.org/openstack/openstack-ansible-ops /opt/openstack-ansible-ops
+# git clone https://opendev.org/openstack/openstack-ansible-ops /opt/openstack-ansible-ops
\end{lstlisting}
-\item Ejecutar la playbook \path{remove_compute_node.yml} con el parámetro indicado:
+ \item Ejecutar la playbook \path{remove_compute_node.yml} con el parámetro indicado:
\begin{lstlisting}
-$ cd /opt/openstack-ansible-ops/ansible_tools/playbooks
-
-$ openstack-ansible remove_compute_node.yml -e host_to_be_removed="<name-of-compute-host>" 2>&1 | tee /var/log/openstack/remove-compute-node.log
+# cd /opt/openstack-ansible-ops/ansible_tools/playbooks
+# openstack-ansible remove_compute_node.yml -e host_to_be_removed="<name-of-compute-host>" 2>&1 | tee /var/log/openstack/remove-compute-node.log
\end{lstlisting}
-\item Finalmente actualizar el archivo \path{openstack_user_config.yml}, eliminando la entrada del nodo de cómputo removido.
-
-
+ \item Finalmente actualizar el archivo \path{openstack_user_config.yml}, eliminando la entrada del nodo de cómputo removido.
\end{itemize}
\subsection{Infraestructura}
diff --git a/docs/udelartex/capitulos/openstack-ansible.tex b/docs/udelartex/capitulos/openstack-ansible.tex
index 4e896dc8bc28d71f48a77114eb1e8ae86eac3f9f..3ea579f582b0ba773c931b2ff0b3d817f5becf8f 100644
--- a/docs/udelartex/capitulos/openstack-ansible.tex
+++ b/docs/udelartex/capitulos/openstack-ansible.tex
@@ -59,21 +59,29 @@ Como se menciona anteriormente los contenedores que corren servicios de OpenStac
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.
\subsection{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}
\subsection{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 archivo \path{user_variables.yml}
+
\item El directorio \path{conf.d/}
+
\item El directorio \path{env.d/}
\end{itemize}
\end{itemize}
@@ -84,29 +92,31 @@ Los components hacen referencia a los diferentes servicios que serán instalados
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.
\subsection{openstack\_user\_config.yml}\label{sec:openstack-user-config}
-Es el principal archivo de configuración, creado por el operador de OpenStack. A continuación se realiza un breve resumen del rol que cumple cada sección de dicho archivo. Como referencia se utilizo el siguiente documento \cite{openstack-user-config}.
+Es el principal archivo de configuración creado por el operador de OpenStack. A continuación se realiza un breve resumen del rol que cumple cada sección del mismo. Como referencia se utilizó el siguiente documento \cite{openstack-user-config}.
-En la sección cidr\_networks, se describen las subredes utilizadas en la instalación de OpenStack.
-
-En la sección used\_ips se configuran las direcciones IP que están siendo utilizadas por los hosts fÃsicos de la infraestructura en las redes definidas para el funcionamiento de OSA, con el fin de reservarlas y que la instalación no utilice ninguna de ellas para la estructura de OpenStack.
-
-En la sección global\_overrides se especifican valores que deben ser ajustados de acuerdo a la arquitectura fÃsica establecida. Las principales opciones requeridas son: internal\_lb\_vip\_address y external\_lb\_vip\_address indicando las IPs de los balanceadores de carga tanto internos (utiliza por los servicios de OpenStack) como externos (puerta de acceso para los usuarios), los nombres de los bridges utilizados para las redes de management, storage y tunnel, y una lista de las redes provistas por los nodos fÃsicos subyacentes en la subsección provider\_networks, describiendo adicionalmente como se conectan con los contenedores.
-
-La última sección describe en qué servidor o grupo de servidores corre cada servicio de OpenStack e infraestructura.
+\begin{itemize}
+ \item En la sección \path{cidr_networks}, se describen las subredes utilizadas en la instalación de OpenStack.
+
+ \item En la sección \path{used_ips} se configuran las direcciones IP que están siendo utilizadas por los hosts fÃsicos de la infraestructura en las redes definidas para el funcionamiento de OSA, con el fin de reservarlas y que la instalación no utilice ninguna de ellas para la estructura de OpenStack.
+
+ \item En la sección \path{global_overrides} se especifican valores que deben ser ajustados de acuerdo a la arquitectura fÃsica establecida. Las principales opciones requeridas son: \path{internal_lb_vip_address} y \path{external_lb_vip_address} indicando las IPs de los balanceadores de carga tanto internos (utilizadas por los servicios de OpenStack) como externos (puerta de acceso para los usuarios), los nombres de los bridges utilizados para las redes de management, storage y tunnel, y una lista de las redes provistas por los nodos fÃsicos subyacentes en la subsección \path{provider_networks}, describiendo adicionalmente como se conectan con los contenedores.
+
+ \item La última sección describe en qué servidor o grupo de servidores corre cada servicio de OpenStack e infraestructura.
+
+\end{itemize}
\subsection{user\_variables.yml}\label{sec:user-variables}
-Los archivos llamados con el formato user\_*.yml ubicados en \path{/etc/openstack_deploy} son considerados automáticamente para cada comando de \path{openstack-ansible}. En particular las variables definidas en el archivo \path{user_variables.yml} dependen fuertemente del ambiente a desplegar.
+Los archivos llamados con el formato \path{user\_*.yml} ubicados en \path{/etc/openstack_deploy} son considerados automáticamente para cada comando de \path{openstack-ansible}. En particular las variables definidas en el archivo \path{user_variables.yml} dependen fuertemente del ambiente a desplegar.
\section{Proceso de instalación}
-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:
+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}
$ 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:
\subsection{setup-hosts.yml}
@@ -116,7 +126,7 @@ Esta playbook se encarga de configurar todos los hosts descritos en el archivo \
$ 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.
+\noindent 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.
\subsection{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 y Galera DB para luego ser configurados en la playbook final. Además se lleva a cabo la configuración de los balanceadores de carga implementados con HAproxy.
@@ -138,53 +148,53 @@ $ openstack-ansible -vvv setup-openstack.yml 2>&1 | tee /var/log/openstack/opens
Luego de que la última playbook haya terminado su ejecución sin error, se debe verificar que la instalación fue exitosa. Esto se realiza de forma manual siguiendo los pasos que se indican a continuación:
\begin{enumerate}
-\item Acceder al nodo de infra1 como usuario root.
+ \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:
+ \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:
+ \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:
+ \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:
+ \item Algunos comandos que se pueden ejecutar son:
+ \begin{itemize}
+ \item Para listar usuarios:
\begin{lstlisting}
$ openstack user list --os-cloud=default
\end{lstlisting}
-\item Para listar servidores:
+ \item Para listar servidores:
\begin{lstlisting}
$ openstack server list
\end{lstlisting}
-\item Para listar redes:
+ \item Para listar redes:
\begin{lstlisting}
$ openstack network list
\end{lstlisting}
-\item Para listar los agentes de red:
+ \item Para listar los agentes de red:
\begin{lstlisting}
$ openstack network agent list
\end{lstlisting}
-\end{itemize}
+ \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}.
+ \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}
\section{Inconvenientes}
-Durante los procesos de instalación de OSA en las versiones utilizadas y en las distintas operaciones de gestión surgieron varios problemas para los cuales se tuvieron que aplicar algunos cambios con el objetivo de su finalización satisfactoria. Algunos de los inconvenientes presentados ocurrieron en la instalación de Queens (anexo \ref{anexoQueens}) mientras que otros son problemas generales.
+Durante los procesos de instalación de OSA en las versiones utilizadas y en las distintas operaciones de gestión surgieron varios problemas para los cuales se tuvieron que aplicar algunos cambios con el objetivo de encontrar una solución. Algunos de los inconvenientes presentados ocurrieron en la instalación de Queens (anexo \ref{anexoQueens}) mientras que otros son problemas generales.
\subsection*{Bloqueo de paquetes}
En los servidores virtuales y el servidor fÃsico las reglas por defecto del firewall de CentOS bloquean tanto el tráfico utilizado para interconectar los servicios de OpenStack como el empleado para las conexiones con redes externas. Para solucionar esto de forma momentánea se eliminaron estas reglas con los comandos:
@@ -195,7 +205,7 @@ $ iptables -D FORWARD -j REJECT --reject-with icmp-host-prohibited
\end{lstlisting}
\subsection*{Módulo de seguridad SELinux}
-Como se mencionó en la sección \ref{chap4:correcciones:selinux}, OSA ha perdido el mantenimiento de este módulo de seguridad, por lo cual fue necesario aplicar los parches realizados para la siguiente versión (Rocky) a la utilizada en la instalación (Queens) para discontinuar el uso de dicho módulo.
+Como se mencionó en la sección \ref{chap4:correcciones:selinux} del anexo \ref{anexoQueens}, OSA ha perdido el mantenimiento de este módulo de seguridad, por lo cual fue necesario aplicar los parches realizados para la siguiente versión (Rocky) a la utilizada en la instalación (Queens) para discontinuar el uso de dicho módulo.
\subsection*{Percona-release}
Durante la instalación de la playbook setup-infrastructure se detecta el siguiente error a la hora de instalar los componentes del contenedor de galera :
@@ -212,24 +222,24 @@ La solución para este problema es actualizar el paquete percona-release, dentro
\begin{enumerate}
\item Acceder por ssh al nodo infra1
- \begin{lstlisting}
- $ ssh root@10.0.1.11
- \end{lstlisting}
+\begin{lstlisting}
+$ ssh root@10.0.1.11
+\end{lstlisting}
\item Listar los contenedores LXC existentes hasta el momento y obtener el nombre del contenedor pertinente:
- \begin{lstlisting}
- $ lxc-ls galera
- \end{lstlisting}
+\begin{lstlisting}
+$ lxc-ls galera
+\end{lstlisting}
\item Acceder a dicho contenedor:
- \begin{lstlisting}
- $ lxc-attach -n infra1_galera_container-15357d7d
- \end{lstlisting}
+\begin{lstlisting}
+$ lxc-attach -n infra1_galera_container-15357d7d
+\end{lstlisting}
\item Actualizar el paquete mencionado
- \begin{lstlisting}
- $ yum upgrade percona-release -y
- \end{lstlisting}
+\begin{lstlisting}
+$ yum upgrade percona-release -y
+\end{lstlisting}
\item Volver a ejecutar la playbook setup-infrastructure.
@@ -247,16 +257,16 @@ Al tratarse de una herramienta de gran magnitud, OpenStack depende de una extens
\item Las nuevas instalaciones realizadas luego de la liberación de la versión 7.7 de CentOS (6 de agosto de 2019), presentaron problemas con el servidor de repositorios del Datacenter. Particularmente el servidor mantenÃa en cache los repositorios de la nueva versión mientras que el resto de los servicios solicitaba librerÃas de la versión instalada en los nodos base (7.6). Esto generaba fallas en el proceso de instalación de todos los contenedores. La única solución encontrada fue actualizar todos los nodos a la última versión del SO.
\end{itemize}
-Luego de un tiempo de alcanzar un ambiente estable basado en la versión Queens junto con Ceph como backend de almacenamiento, donde realizar una nueva instalación era un proceso rutinario, surgieron problemas inesperados en la comunicación del módulo Cinder. Tras varios intentos buscando mitigar estos problemas, se decidió pasar a una nueva versión de OpenStack con el fin de poder avanzar con el proyecto. Es por esto que la versión utilizada para instalar la arquitectura diseñada para producción es Stein (Anexo \ref{anexoStein})
+Luego de un tiempo de alcanzar un ambiente estable basado en la versión Queens junto con Ceph como backend de almacenamiento, donde realizar una nueva instalación era un proceso rutinario, surgieron problemas inesperados en la comunicación del módulo Cinder. Tras varios intentos buscando mitigar estos problemas, se decidió pasar a una nueva versión de OpenStack con el fin de poder avanzar con el proyecto. Es por esto que la versión utilizada para instalar la arquitectura diseñada para producción es Stein (anexo \ref{anexoStein})
\subsection*{Soporte para CentOS}
Si bien en la documentación oficial se menciona el soporte de los sistemas operativos Ubuntu, CentOS y openSUSE, la experiencia adquirida demuestra que varios de los bugs y problemas enfrentados no se encuentran reportados para Ubuntu. A su vez la mayor parte de las guÃas, ejemplos de testing y producción, soporte de plugins, entre otros, sólo se encuentran detallados para este último. Esto aumenta la dificultad durante todo el proceso debido al requerimiento de utilizar un SO basado en RedHat.
\subsection*{Problema con container-setup.sh}
-En la ejecución del script container-setup.sh ubicado en \path{/opt} de los contenedores del nodo de infraestructura ocurrió un error reportado en [\path{https://github.com/openstack/openstack-ansible-lxc_container_create/commit/b15b97fa0ab73579e4939ae767a2810196b33df2#diff-0dc9e326c64f4a15341a43e16b94ee60}]. Esto se debe a que el código esta orientado a sistemas Ubuntu. El error se resuelve siguiendo el commit de la referencia mencionada.
+En la ejecución del script container-setup.sh ubicado en \path{/opt} de los contenedores del nodo de infraestructura ocurrió un error reportado en \cite{openstack-bug-container-lxc}. Este error se da debido a que el código esta orientado a sistemas Ubuntu y su solución fue seguir el commit de la referencia mencionada.
\subsection*{Repositorio}
-El problema surge para el repositorio \path{epel-lxc_hosts} en donde la URL base que se configura (\path{http://download.fedoraproject.org/pub/epel/7/x86_64/repodata/repomd.xml}) genera una redirección a un cache de fder (\path{https://espejito.fder.edu.uy/fedora/epel/7/x86_64/repodata/repomd.xml}). El error se genera por el la herramienta \path{apt-cacher-ng} la cual no maneja correctamente la redirección originando un mensaje 500. Para solucionar el problema se obtiene la URL original (\path{http://mirror.nextlayer.at/epel/7/x86_64/repodata/repomd.xml}) y se reemplaza en el archivo \path{/etc/yum.repos.d/epel-lxc_hosts.repo} en el nodo de infraestructura.
+Durante los procesos de instalación surgió en reiteradas ocasiones un inconveniente con el repositorio del paquete \path{epel-lxc_hosts} en donde la URL base que se configura (\path{http://download.fedoraproject.org/pub/epel/7/x86_64/repodata/repomd.xml}) generaba una redirección a un cache de la Facultad de Derecho (\path{https://espejito.fder.edu.uy/fedora/epel/7/x86_64/repodata/repomd.xml}). OSA utiliza la herramienta \path{apt-cacher-ng} como servidor cache de repositorios la cual no maneja correctamente la redirección originando un mensaje 500. Para solucionar el problema se obtuvo la URL original (\path{http://mirror.nextlayer.at/epel/7/x86_64/repodata/repomd.xml}) y se reemplazó en el archivo \path{/etc/yum.repos.d/epel-lxc_hosts.repo} en el nodo de infraestructura.
\section*{Conclusiones}
-El proyecto OpenStack-Ansible es una herramienta fundamental para instalar una plataforma de gran porte como es OpenStack. La alta complejidad para obtener un ambiente funcional surge de la gran cantidad de configuraciones y tecnologÃas necesarias, en donde a su vez estas ultimas son complejas por si mismas, como son las colas de mensajes, las bases de datos, entre otras. Las herramientas de automatización como es en este caso Ansible, permiten describir la arquitectura que se pretende desplegar mediante un archivo de configuración y abstraerse de los detalles para llevarlo a cabo. Otro de los factores positivos para utilizar OSA es que permite tener consistencia en la repetición de las instalaciones. Un aspecto positivo es la celeridad de OpenStack y OpenStack-Ansible para resolver los problemas que surgen y agregar nuevas funcionalidades en las liberaciones principales cada 6 meses y en los parches menores durante dicho perÃodo.
\ No newline at end of file
+El proyecto OpenStack-Ansible es una herramienta fundamental para instalar una plataforma de gran porte como OpenStack. La alta complejidad para obtener un ambiente funcional surge de la gran cantidad de configuraciones y tecnologÃas necesarias, en donde a su vez estas últimas son complejas por si mismas. Las herramientas de automatización como Ansible, permiten describir la arquitectura que se pretende desplegar mediante un archivo de configuración y abstraerse de los detalles para llevarlo a cabo. Otro de los factores positivos para utilizar OSA es que permite tener consistencia en la repetición de las instalaciones. Además cabe destacar la celeridad de OpenStack y OpenStack-Ansible para resolver los problemas que surgen y agregar nuevas funcionalidades en las liberaciones principales realizadas cada 6 meses y en los parches menores anunciados durante dicho perÃodo.
\ No newline at end of file
diff --git a/docs/udelartex/capitulos/red.tex b/docs/udelartex/capitulos/red.tex
index e4ad5fd3132dea2edda6b2d4601e5c042a704e31..dfc998a7185264f89e68c4b72ede5cab2a6aeeae 100644
--- a/docs/udelartex/capitulos/red.tex
+++ b/docs/udelartex/capitulos/red.tex
@@ -2243,11 +2243,9 @@ El procedimiento para la respuesta ICMP echo reply es similar al descrito pero e
\section{Funcionalidades avanzadas}
\subsection{Layer 3 High Availability}
-En una instalación de Neutron sin algún mecanismo de alta disponibilidad será vulnerable a posibles fallos que surjan en los nodos fÃsicos del Datacenter. Los ambientes productivos de OpenStack contienen varios nodos fÃsicos dedicados a las funciones de red. Esto no es suficiente para proporcionar alta disponibilidad de la conectividad de las instancias debido a que al crear un nuevo router virtual, los mismos se planifican para correr en un agente L3 fÃsico. Por lo tanto el funcionamiento de dicho router depende exclusivamente de un nodo fÃsico el cual al presentar algún problema provocará que las instancias pierdan conectividad con redes externas y las IPs flotantes tampoco estarán disponibles.
+Una instalación de Neutron sin ningún mecanismo de alta disponibilidad será vulnerable a posibles fallos que surjan en los nodos fÃsicos del Datacenter. Si bien los ambientes productivos de OpenStack contienen varios nodos fÃsicos dedicados a las funciones de red, esto no garantiza la alta disponibilidad de conexión en las instancias. Esto se da debido a que al crear un nuevo router virtual, este es planificado para correr en un único agente L3 fÃsico, generando que su funcionamiento dependa exclusivamente del mismo. Si este único nodo presenta algún problema, provocará que las instancias pierdan conectividad con redes externas y que las IPs flotantes no se encuentren disponibles.
-Para solucionar este problema se utiliza una configuración de alta disponibilidad basada en router con dos estados: pasivo o activo. Se utiliza el estándar VRRP (Virtual Routing Redundancy Protocol) definido en el RFC 3768. En una explicación a alta nivel lo que se realiza es planificar la creación de un router virtual en múltiples nodos de red de OpenStack, en donde únicamente se designa uno de estos routers como activo, mientras que el resto queda en un estado de espera o pasivo.
-
-Un ejemplo de esto se puede ver en las siguientes imágenes:
+Para solucionar este problema se utiliza una configuración de alta disponibilidad basada en routers con dos estados: pasivo y activo, empleando el estándar VRRP (Virtual Routing Redundancy Protocol) definido en el RFC 3768 [poner referencia]. En una explicación a alto nivel, esta implementación planifica la creación de un router virtual en múltiples nodos de red de OpenStack, en donde únicamente se designa uno de estos como activo mientras que el resto queda en un estado de espera o pasivo. Un ejemplo de esto se puede ver en las figuras \ref{fig:red:vrrp1} y \ref{fig:red:vrrp2}.
\begin{figure}[h!]
\centering
@@ -2256,8 +2254,6 @@ Un ejemplo de esto se puede ver en las siguientes imágenes:
\label{fig:red:vrrp1}
\end{figure}
-En la imagen \ref{fig:red:vrrp1} se puede apreciar como los routers 1 y 2 tiene su par de backup en el otro nodo fÃsico.
-
\begin{figure}[h!]
\centering
\includegraphics[width=0.9\columnwidth]{red/vrrp2}
@@ -2265,4 +2261,4 @@ En la imagen \ref{fig:red:vrrp1} se puede apreciar como los routers 1 y 2 tiene
\label{fig:red:vrrp2}
\end{figure}
-En la segunda imagen se puede ver como el L3 HA replanifica el/los dispositivos afectados, en este caso el Router1, a un nodo operativo en donde existe una copia en estado de espera del router afectado.
+En la figura \ref{fig:red:vrrp1} se puede apreciar como los routers 1 y 2 tienen su par de backup en el otro nodo fÃsico. Por otro lado en la figura \ref{fig:red:vrrp2} se observa como el L3 HA replanifica el/los dispositivos afectados, en este caso el Router1, a un nodo operativo en donde existe una copia en estado de espera del router afectado.
diff --git a/docs/udelartex/tesis.bbl b/docs/udelartex/tesis.bbl
index d31e7a7b0c020a59efadd172c39b36e3297e8823..f1a8c35e6d3d2163d60bb6f93ffbbe121b0e172a 100644
--- a/docs/udelartex/tesis.bbl
+++ b/docs/udelartex/tesis.bbl
@@ -73,6 +73,13 @@ Docker.
\newblock \url{https://www.docker.com/resources/what-container}.
\newblock Accedido: 2019-06-20.
+\bibitem{openstack-bug-container-lxc}
+GitHub.
+\newblock Redhat: stop updating system unnecessarily.
+\newblock
+ \url{https://github.com/openstack/openstack-ansible-lxc_container_create/commit/b15b97fa0ab73579e4939ae767a2810196b33df2#diff-0dc9e326c64f4a15341a43e16b94ee60}.
+\newblock Accedido: 2020-01-22.
+
\bibitem{redhat-conductor}
Red Hat.
\newblock Conductor.
@@ -147,278 +154,291 @@ Peter~M. Mell and Timothy Grance.
2011.
\bibitem{openstack-selinux-fix-1}
-Openstack.
+OpenStack.
\newblock Aio build fails on selinux file context tasks.
\newblock \url{https://bugs.launchpad.net/openstack-ansible/+bug/1782798}.
\newblock Accedido: 2019-07-05.
\bibitem{openstack-appendix-e}
-Openstack.
+OpenStack.
\newblock Appendix e: Container networking.
\newblock
\url{https://docs.openstack.org/project-deploy-guide/openstack-ansible/ocata/app-networking.html#network-diagrams}.
\newblock Accedido: 2019-07-05.
\bibitem{openstack-glance-architecture}
-Openstack.
+OpenStack.
\newblock Basic architecture.
\newblock
\url{https://docs.openstack.org/glance/queens/contributor/architecture.html}.
\newblock Accedido: 2019-07-05.
\bibitem{openstack-basic-networking}
-Openstack.
+OpenStack.
\newblock Basic networking.
\newblock
\url{https://docs.openstack.org/mitaka/networking-guide/intro-basic-networking.html}.
\newblock Accedido: 2019-06-15.
\bibitem{openstack-image-properties-1}
-Openstack.
+OpenStack.
\newblock Common image properties.
\newblock
\url{https://docs.openstack.org/glance/queens/user/common-image-properties.html}.
\newblock Accedido: 2019-06-20.
\bibitem{openstack-storage-components}
-Openstack.
+OpenStack.
\newblock Components.
\newblock
\url{https://docs.openstack.org/swift/latest/admin/objectstorage-components.html}.
\newblock Accedido: 2019-07-05.
\bibitem{openstack-compute-overview}
-Openstack.
+OpenStack.
\newblock Compute service overview.
\newblock
\url{https://docs.openstack.org/nova/latest/install/get-started-compute.html}.
\newblock Accedido: 2019-06-20.
\bibitem{openstack-security-instances}
-Openstack.
+OpenStack.
\newblock Configure access and security for instances.
\newblock
\url{https://docs.openstack.org/horizon/latest/user/configure-access-and-security-for-instances.html}.
\newblock Accedido: 2019-08-03.
+\bibitem{openstack-ssh-between-compute}
+OpenStack.
+\newblock Configure ssh between compute nodes.
+\newblock
+ \url{https://docs.openstack.org/nova/stein/admin/ssh-configuration.html#cli-os-migrate-cfg-ssh}.
+\newblock Accedido: 2020-01-22.
+
\bibitem{openstack-container-networking}
-Openstack.
+OpenStack.
\newblock Container networking.
\newblock
\url{https://docs.openstack.org/openstack-ansible/rocky/reference/architecture/container-networking.html}.
\newblock Accedido: 2019-07-05.
\bibitem{openstack-control-plane}
-Openstack.
+OpenStack.
\newblock Control plane architecture.
\newblock
\url{https://docs.openstack.org/arch-design/design-control-plane.html}.
\newblock Accedido: 2019-06-20.
\bibitem{openstack-manage-networks}
-Openstack.
+OpenStack.
\newblock Create and manage networks.
\newblock
\url{https://docs.openstack.org/horizon/latest/user/create-networks.html}.
\newblock Accedido: 2019-08-03.
\bibitem{openstack-design}
-Openstack.
+OpenStack.
\newblock Design.
\newblock \url{https://docs.openstack.org/arch-design/design.html}.
\newblock Accedido: 2019-06-20.
\bibitem{openstack-selinux-fix-2}
-Openstack.
+OpenStack.
\newblock Drop selinux support for centos 7.
\newblock \url{https://review.opendev.org/#/c/603860/}.
\newblock Accedido: 2019-07-05.
\bibitem{openstack-obtain-images}
-Openstack.
+OpenStack.
\newblock Get images.
\newblock \url{https://docs.openstack.org/image-guide/obtain-images.html}.
\newblock Accedido: 2019-08-04.
\bibitem{openstack-images-instances}
-Openstack.
+OpenStack.
\newblock Images and instances.
\newblock
\url{https://docs.openstack.org/glance/queens/admin/troubleshooting.html}.
\newblock Accedido: 2019-06-20.
\bibitem{openstack-history}
-Openstack.
+OpenStack.
\newblock Introduction.
\newblock
\url{https://docs.openstack.org/project-team-guide/introduction.html}.
\newblock Accedido: 2019-06-15.
\bibitem{openstack-keystone-architecture}
-Openstack.
+OpenStack.
\newblock Keystone architecture.
\newblock
\url{https://docs.openstack.org/keystone/latest/getting-started/architecture.html}.
\newblock Accedido: 2019-06-20.
\bibitem{openstack-manage-instances}
-Openstack.
+OpenStack.
\newblock Launch and manage instances.
\newblock
\url{https://docs.openstack.org/horizon/latest/user/launch-instances.html}.
\newblock Accedido: 2019-08-03.
\bibitem{openstack-lvm}
-Openstack.
+OpenStack.
\newblock Lvm.
\newblock
\url{https://docs.openstack.org/cinder/latest/configuration/block-storage/drivers/lvm-volume-driver.html}.
\newblock Accedido: 2019-06-20.
\bibitem{openstack-maintenance-tasks}
-Openstack.
+OpenStack.
\newblock Maintenance tasks.
\newblock
\url{https://docs.openstack.org/openstack-ansible/latest/admin/maintenance-tasks.html}.
\newblock Accedido: 2020-01-12.
\bibitem{openstack-manage-flavors}
-Openstack.
+OpenStack.
\newblock Manage flavors.
\newblock
\url{https://docs.openstack.org/horizon/latest/admin/manage-flavors.html}.
\newblock Accedido: 2019-08-03.
\bibitem{openstack-projects-users}
-Openstack.
+OpenStack.
\newblock Manage projects and users.
\newblock
\url{https://docs.openstack.org/horizon/latest/admin/manage-projects-and-users.html}.
\newblock Accedido: 2019-08-03.
\bibitem{openstack-memcached}
-Openstack.
+OpenStack.
\newblock Memcached.
\newblock
\url{https://docs.openstack.org/mitaka/install-guide-ubuntu/environment-memcached.html}.
\newblock Accedido: 2019-06-20.
\bibitem{openstack-messaging}
-Openstack.
+OpenStack.
\newblock Message queuing.
\newblock \url{https://docs.openstack.org/security-guide/messaging.htmll}.
\newblock Accedido: 2019-06-20.
+\bibitem{openstack-migration}
+OpenStack.
+\newblock Migrate instances.
+\newblock \url{https://docs.openstack.org/nova/stein/admin/migration.html}.
+\newblock Accedido: 2020-01-22.
+
\bibitem{openstack-networking-architecture}
-Openstack.
+OpenStack.
\newblock Network architectures.
\newblock
\url{https://docs.openstack.org/openstack-ansible/stein/user/network-arch/example.html}.
\newblock Accedido: 2019-07-05.
\bibitem{openstack-networking-concepts}
-Openstack.
+OpenStack.
\newblock Networking concepts.
\newblock
\url{https://docs.openstack.org/arch-design/design-networking/design-networking-concepts.html}.
\newblock Accedido: 2019-06-15.
\bibitem{openstack-network-namespaces}
-Openstack.
+OpenStack.
\newblock Nework namespaces.
\newblock
\url{https://docs.openstack.org/neutron/pike/admin/intro-network-namespaces.html}.
\newblock Accedido: 2020-01-08.
\bibitem{openstack-nova-architecture}
-Openstack.
+OpenStack.
\newblock Nova system architecture.
\newblock \url{https://docs.openstack.org/nova/latest/user/architecture.html}.
\newblock Accedido: 2019-07-05.
\bibitem{openstack-storage-api}
-Openstack.
+OpenStack.
\newblock Object storage api overview.
\newblock
\url{https://docs.openstack.org/swift/latest/api/object_api_v1_overview.html}.
\newblock Accedido: 2019-07-05.
\bibitem{openstack-ansible}
-Openstack.
+OpenStack.
\newblock Openstack-ansible documentation.
\newblock \url{https://docs.openstack.org/openstack-ansible/latest/}.
\newblock Accedido: 2019-07-05.
\bibitem{openstack-marketplace}
-Openstack.
+OpenStack.
\newblock The openstack marketplace.
\newblock \url{https://www.openstack.org/marketplace/distros/}.
\newblock Accedido: 2019-07-05.
\bibitem{openstack-user-config}
-Openstack.
+OpenStack.
\newblock openstack\_user\_config settings reference.
\newblock
\url{https://docs.openstack.org/openstack-ansible/queens/reference/inventory/openstack-user-config-reference.html}.
\newblock Accedido: 2019-06-20.
\bibitem{openstack-using-openvswitch}
-Openstack.
+OpenStack.
\newblock Scenario - using open vswitch.
\newblock
\url{https://docs.openstack.org/openstack-ansible-os_neutron/latest/app-openvswitch.html}.
\newblock Accedido: 2020-01-12.
\bibitem{openstack-settings-reference}
-Openstack.
+OpenStack.
\newblock Settings reference.
\newblock
\url{https://docs.openstack.org/horizon/queens/configuration/settings.html}.
\newblock Accedido: 2019-08-04.
\bibitem{openstack-software}
-Openstack.
+OpenStack.
\newblock Software.
\newblock \url{https://www.openstack.org/software/}.
\newblock Accedido: 2019-06-15.
\bibitem{openstack-storage-architect}
-Openstack.
+OpenStack.
\newblock Swift architectural overview.
\newblock
\url{https://docs.openstack.org/swift/latest/overview_architecture.html}.
\newblock Accedido: 2019-07-05.
\bibitem{openstack-troubleshooting}
-Openstack.
+OpenStack.
\newblock Troubleshooting.
\newblock
\url{https://docs.openstack.org/openstack-ansible/latest/admin/troubleshooting.html}.
\newblock Accedido: 2020-01-12.
\bibitem{openstack-image-properties-2}
-Openstack.
+OpenStack.
\newblock Useful image properties.
\newblock
\url{https://docs.openstack.org/glance/latest/admin/useful-image-properties.html}.
\newblock Accedido: 2019-06-20.
\bibitem{openstack-verify-cloud}
-Openstack.
+OpenStack.
\newblock Verify openstack-ansible cloud.
\newblock
\url{https://docs.openstack.org/openstack-ansible/latest/admin/openstack-firstrun.html}.
\newblock Accedido: 2020-01-12.
\bibitem{openstack-volume-drivers}
-Openstack.
+OpenStack.
\newblock Volume drivers.
\newblock
\url{https://docs.openstack.org/cinder/latest/configuration/block-storage/volume-drivers.html}.
\newblock Accedido: 2019-06-20.
\bibitem{openstack-puppet}
-Openstack.
+OpenStack.
\newblock Welcome to the puppet openstack guide!
\newblock \url{https://docs.openstack.org/puppet-openstack-guide/latest/}.
\newblock Accedido: 2019-07-05.
diff --git a/docs/udelartex/tesis.lof b/docs/udelartex/tesis.lof
index 0763f3c60cbba4104bcf7866aac6d2d05dded77d..e5b2545e538cc25acd21bc0aa3821245c5613fa7 100644
--- a/docs/udelartex/tesis.lof
+++ b/docs/udelartex/tesis.lof
@@ -74,39 +74,39 @@
\addvspace {10\p@ }
\addvspace {10\p@ }
\addvspace {10\p@ }
-\contentsline {figure}{\numberline {1.1}{\ignorespaces Arquitectura diseñada para desarrollo\relax }}{160}{figure.caption.182}%
-\contentsline {figure}{\numberline {1.2}{\ignorespaces Arquitectura diseñada para producción\relax }}{161}{figure.caption.183}%
-\addvspace {10\p@ }
-\addvspace {10\p@ }
-\addvspace {10\p@ }
-\contentsline {figure}{\numberline {3.1}{\ignorespaces Nueva conexión en virt-manager.\relax }}{203}{figure.caption.186}%
-\contentsline {figure}{\numberline {3.2}{\ignorespaces Configuración de redes virtuales en virt-manager.\relax }}{204}{figure.caption.187}%
-\addvspace {10\p@ }
-\contentsline {figure}{\numberline {4.1}{\ignorespaces Vista del login de Horizon.\relax }}{211}{figure.caption.201}%
-\contentsline {figure}{\numberline {4.2}{\ignorespaces Creación de un proyecto (1/2).\relax }}{212}{figure.caption.203}%
-\contentsline {figure}{\numberline {4.3}{\ignorespaces Creación de un proyecto (2/2).\relax }}{213}{figure.caption.204}%
-\contentsline {figure}{\numberline {4.4}{\ignorespaces Creación de un usuario.\relax }}{214}{figure.caption.206}%
-\contentsline {figure}{\numberline {4.5}{\ignorespaces Creación de un flavor (1/2).\relax }}{215}{figure.caption.208}%
-\contentsline {figure}{\numberline {4.6}{\ignorespaces Creación de un flavor (2/2).\relax }}{215}{figure.caption.209}%
-\contentsline {figure}{\numberline {4.7}{\ignorespaces Creación de una red provider (1/2).\relax }}{216}{figure.caption.211}%
-\contentsline {figure}{\numberline {4.8}{\ignorespaces Creación de una red provider (2/2).\relax }}{217}{figure.caption.212}%
-\contentsline {figure}{\numberline {4.9}{\ignorespaces Creación de una imagen (1/2).\relax }}{218}{figure.caption.214}%
-\contentsline {figure}{\numberline {4.10}{\ignorespaces Creación de una imagen (2/2).\relax }}{219}{figure.caption.215}%
-\contentsline {figure}{\numberline {4.11}{\ignorespaces Creación de una red (1/3).\relax }}{220}{figure.caption.217}%
-\contentsline {figure}{\numberline {4.12}{\ignorespaces Creación de una red (2/3).\relax }}{220}{figure.caption.218}%
-\contentsline {figure}{\numberline {4.13}{\ignorespaces Creación de una red (3/3).\relax }}{221}{figure.caption.219}%
-\contentsline {figure}{\numberline {4.14}{\ignorespaces Creación de un router.\relax }}{221}{figure.caption.221}%
-\contentsline {figure}{\numberline {4.15}{\ignorespaces Creación de una interfaz en un router.\relax }}{222}{figure.caption.223}%
-\contentsline {figure}{\numberline {4.16}{\ignorespaces Creación de una key pair.\relax }}{222}{figure.caption.225}%
-\contentsline {figure}{\numberline {4.17}{\ignorespaces Lanzar una nueva instancia (1/5).\relax }}{223}{figure.caption.227}%
-\contentsline {figure}{\numberline {4.18}{\ignorespaces Lanzar una nueva instancia (2/5).\relax }}{223}{figure.caption.228}%
-\contentsline {figure}{\numberline {4.19}{\ignorespaces Lanzar una nueva instancia (3/5).\relax }}{224}{figure.caption.229}%
-\contentsline {figure}{\numberline {4.20}{\ignorespaces Lanzar una nueva instancia (4/5).\relax }}{224}{figure.caption.230}%
-\contentsline {figure}{\numberline {4.21}{\ignorespaces Lanzar una nueva instancia (5/5).\relax }}{225}{figure.caption.231}%
-\contentsline {figure}{\numberline {4.22}{\ignorespaces Asignación de floating IP.\relax }}{226}{figure.caption.232}%
-\contentsline {figure}{\numberline {4.23}{\ignorespaces Asociación de floating IP.\relax }}{227}{figure.caption.233}%
-\contentsline {figure}{\numberline {4.24}{\ignorespaces Reglas security group por defecto.\relax }}{227}{figure.caption.234}%
-\contentsline {figure}{\numberline {4.25}{\ignorespaces Agregar regla para tráfico ICMP.\relax }}{228}{figure.caption.235}%
-\contentsline {figure}{\numberline {4.26}{\ignorespaces Agregar regla para tráfico SSH.\relax }}{228}{figure.caption.236}%
+\contentsline {figure}{\numberline {1.1}{\ignorespaces Arquitectura diseñada para desarrollo\relax }}{160}{figure.caption.186}%
+\contentsline {figure}{\numberline {1.2}{\ignorespaces Arquitectura diseñada para producción\relax }}{161}{figure.caption.187}%
+\addvspace {10\p@ }
+\addvspace {10\p@ }
+\addvspace {10\p@ }
+\contentsline {figure}{\numberline {3.1}{\ignorespaces Nueva conexión en virt-manager.\relax }}{203}{figure.caption.208}%
+\contentsline {figure}{\numberline {3.2}{\ignorespaces Configuración de redes virtuales en virt-manager.\relax }}{204}{figure.caption.209}%
+\addvspace {10\p@ }
+\contentsline {figure}{\numberline {4.1}{\ignorespaces Vista del login de Horizon.\relax }}{211}{figure.caption.223}%
+\contentsline {figure}{\numberline {4.2}{\ignorespaces Creación de un proyecto (1/2).\relax }}{212}{figure.caption.225}%
+\contentsline {figure}{\numberline {4.3}{\ignorespaces Creación de un proyecto (2/2).\relax }}{213}{figure.caption.226}%
+\contentsline {figure}{\numberline {4.4}{\ignorespaces Creación de un usuario.\relax }}{214}{figure.caption.228}%
+\contentsline {figure}{\numberline {4.5}{\ignorespaces Creación de un flavor (1/2).\relax }}{215}{figure.caption.230}%
+\contentsline {figure}{\numberline {4.6}{\ignorespaces Creación de un flavor (2/2).\relax }}{215}{figure.caption.231}%
+\contentsline {figure}{\numberline {4.7}{\ignorespaces Creación de una red provider (1/2).\relax }}{216}{figure.caption.233}%
+\contentsline {figure}{\numberline {4.8}{\ignorespaces Creación de una red provider (2/2).\relax }}{217}{figure.caption.234}%
+\contentsline {figure}{\numberline {4.9}{\ignorespaces Creación de una imagen (1/2).\relax }}{218}{figure.caption.236}%
+\contentsline {figure}{\numberline {4.10}{\ignorespaces Creación de una imagen (2/2).\relax }}{219}{figure.caption.237}%
+\contentsline {figure}{\numberline {4.11}{\ignorespaces Creación de una red (1/3).\relax }}{220}{figure.caption.239}%
+\contentsline {figure}{\numberline {4.12}{\ignorespaces Creación de una red (2/3).\relax }}{220}{figure.caption.240}%
+\contentsline {figure}{\numberline {4.13}{\ignorespaces Creación de una red (3/3).\relax }}{221}{figure.caption.241}%
+\contentsline {figure}{\numberline {4.14}{\ignorespaces Creación de un router.\relax }}{221}{figure.caption.243}%
+\contentsline {figure}{\numberline {4.15}{\ignorespaces Creación de una interfaz en un router.\relax }}{222}{figure.caption.245}%
+\contentsline {figure}{\numberline {4.16}{\ignorespaces Creación de una key pair.\relax }}{222}{figure.caption.247}%
+\contentsline {figure}{\numberline {4.17}{\ignorespaces Lanzar una nueva instancia (1/5).\relax }}{223}{figure.caption.249}%
+\contentsline {figure}{\numberline {4.18}{\ignorespaces Lanzar una nueva instancia (2/5).\relax }}{223}{figure.caption.250}%
+\contentsline {figure}{\numberline {4.19}{\ignorespaces Lanzar una nueva instancia (3/5).\relax }}{224}{figure.caption.251}%
+\contentsline {figure}{\numberline {4.20}{\ignorespaces Lanzar una nueva instancia (4/5).\relax }}{224}{figure.caption.252}%
+\contentsline {figure}{\numberline {4.21}{\ignorespaces Lanzar una nueva instancia (5/5).\relax }}{225}{figure.caption.253}%
+\contentsline {figure}{\numberline {4.22}{\ignorespaces Asignación de floating IP.\relax }}{226}{figure.caption.254}%
+\contentsline {figure}{\numberline {4.23}{\ignorespaces Asociación de floating IP.\relax }}{227}{figure.caption.255}%
+\contentsline {figure}{\numberline {4.24}{\ignorespaces Reglas security group por defecto.\relax }}{227}{figure.caption.256}%
+\contentsline {figure}{\numberline {4.25}{\ignorespaces Agregar regla para tráfico ICMP.\relax }}{228}{figure.caption.257}%
+\contentsline {figure}{\numberline {4.26}{\ignorespaces Agregar regla para tráfico SSH.\relax }}{228}{figure.caption.258}%
\addvspace {10\p@ }
\contentsfinish
diff --git a/docs/udelartex/tesis.out b/docs/udelartex/tesis.out
index 30d743cfef8d7cd287fe87aff8e44e7686800bd1..a3c5e33d7cb0f01fbbaed5e21ac8978f861076ea 100644
--- a/docs/udelartex/tesis.out
+++ b/docs/udelartex/tesis.out
@@ -82,11 +82,11 @@
\BOOKMARK [2][-]{subsection.8.5.1}{Layer 3 High Availability}{section.8.5}% 82
\BOOKMARK [0][-]{chapter.9}{Trabajo a futuro}{}% 83
\BOOKMARK [0][-]{chapter.10}{Conclusiones}{}% 84
-\BOOKMARK [0][-]{chapter*.180}{Referencias bibliogr\341ficas}{}% 85
-\BOOKMARK [0][-]{chapter*.180}{Glosario}{}% 86
-\BOOKMARK [0][-]{section*.181}{Ap\351ndices}{}% 87
+\BOOKMARK [0][-]{chapter*.184}{Referencias bibliogr\341ficas}{}% 85
+\BOOKMARK [0][-]{chapter*.184}{Glosario}{}% 86
+\BOOKMARK [0][-]{section*.185}{Ap\351ndices}{}% 87
\BOOKMARK [0][-]{appendix.Alph1}{Im\341genes}{}% 88
-\BOOKMARK [0][-]{section*.184}{Anexos}{}% 89
+\BOOKMARK [0][-]{section*.188}{Anexos}{}% 89
\BOOKMARK [0][-]{appendix.Anexo.1}{Instalaci\363n versi\363n Queens}{}% 90
\BOOKMARK [1][-]{section.Anexo.1.1}{Preparaci\363n de nodos}{appendix.Anexo.1}% 91
\BOOKMARK [1][-]{section.Anexo.1.2}{Configuraci\363n}{appendix.Anexo.1}% 92
diff --git a/docs/udelartex/tesis.pdf b/docs/udelartex/tesis.pdf
index 3433a8b08476df9ba7899a76fce430ef257032a2..e7ff93f149e9a2f3598f6d20544bacfa55d27e45 100644
Binary files a/docs/udelartex/tesis.pdf and b/docs/udelartex/tesis.pdf differ
diff --git a/docs/udelartex/tesis.synctex.gz b/docs/udelartex/tesis.synctex.gz
index c684b3a1d6492a3bcc62357b82a02b318a432a2e..274202bbee168041a1a690e2c3770c8d559e51ad 100644
Binary files a/docs/udelartex/tesis.synctex.gz and b/docs/udelartex/tesis.synctex.gz differ
diff --git a/docs/udelartex/tesis.toc b/docs/udelartex/tesis.toc
index 9440908be9094ea52b65038ccbd5a1e141c85201..eb7e104f4d9d586d791c75d445c46755bb1ad9c5 100644
--- a/docs/udelartex/tesis.toc
+++ b/docs/udelartex/tesis.toc
@@ -76,7 +76,7 @@
\contentsline {subsection}{\numberline {5.2.3}openstack\_user\_config.yml}{43}{subsection.5.2.3}%
\contentsline {subsection}{\numberline {5.2.4}user\_variables.yml}{44}{subsection.5.2.4}%
\contentsline {section}{\numberline {5.3}Proceso de instalación}{44}{section.5.3}%
-\contentsline {subsection}{\numberline {5.3.1}setup-hosts.yml}{44}{subsection.5.3.1}%
+\contentsline {subsection}{\numberline {5.3.1}setup-hosts.yml}{45}{subsection.5.3.1}%
\contentsline {subsection}{\numberline {5.3.2}setup-infrastructure.yml}{45}{subsection.5.3.2}%
\contentsline {subsection}{\numberline {5.3.3}setup-openstack.yml}{45}{subsection.5.3.3}%
\contentsline {section}{\numberline {5.4}Verificación}{45}{section.5.4}%
@@ -191,52 +191,30 @@
\contentsline {section}{\numberline {8.5}Funcionalidades avanzadas}{145}{section.8.5}%
\contentsline {subsection}{\numberline {8.5.1}Layer 3 High Availability}{145}{subsection.8.5.1}%
\contentsline {chapter}{\numberline {9}Trabajo a futuro}{148}{chapter.9}%
-\contentsline {subsubsection}{\numberline {9.0.0.1}Firewall}{148}{subsubsection.9.0.0.1}%
-\contentsline {subsubsection}{\numberline {9.0.0.2}Arquitectura segura}{148}{subsubsection.9.0.0.2}%
-\contentsline {subsubsection}{\numberline {9.0.0.3}Brindar conexión directa a Internet}{149}{subsubsection.9.0.0.3}%
-\contentsline {subsubsection}{\numberline {9.0.0.4}Gestión de Openstack en operación}{149}{subsubsection.9.0.0.4}%
\contentsline {chapter}{\numberline {10}Conclusiones}{150}{chapter.10}%
-\contentsline {chapter}{Referencias bibliográficas}{151}{chapter*.180}%
-\contentsline {chapter}{Glosario}{157}{chapter*.180}%
-\contentsline {chapter}{\textbf {Apéndices}}{158}{section*.181}%
+\contentsline {chapter}{Referencias bibliográficas}{151}{chapter*.184}%
+\contentsline {chapter}{Glosario}{157}{chapter*.184}%
+\contentsline {chapter}{\textbf {Apéndices}}{158}{section*.185}%
\ttl@change@i {\@ne }{chapter}{13pt}{}{ Apéndice\ \thecontentslabel \quad }{}{\titlerule *[1pc]{.}\contentspage }\relax
\ttl@change@v {chapter}{}{}{}\relax
\contentsline {chapter}{\numberline {1}Imágenes}{159}{appendix.Alph1}%
\ttl@change@i {\@ne }{chapter}{0pt}{\vspace *{0.45cm}}{\thecontentslabel \quad }{}{\bfseries \hfill \contentspage }\relax
\ttl@change@v {chapter}{}{}{}\relax
-\contentsline {chapter}{\textbf {Anexos}}{162}{section*.184}%
+\contentsline {chapter}{\textbf {Anexos}}{162}{section*.188}%
\ttl@change@i {\@ne }{chapter}{13pt}{}{ Anexo\ \thecontentslabel \quad }{}{\titlerule *[1pc]{.}\contentspage }\relax
\ttl@change@v {chapter}{}{}{}\relax
\contentsline {chapter}{\numberline {1}Instalación versión Queens}{163}{appendix.Anexo.1}%
\contentsline {section}{\numberline {1.1}Preparación de nodos}{163}{section.Anexo.1.1}%
-\contentsline {subsubsection}{\numberline {1.1.0.1}Deploy}{163}{subsubsection.Anexo.1.1.0.1}%
-\contentsline {subsubsection}{\numberline {1.1.0.2}Infra1}{166}{subsubsection.Anexo.1.1.0.2}%
-\contentsline {subsubsection}{\numberline {1.1.0.3}Compute1}{168}{subsubsection.Anexo.1.1.0.3}%
-\contentsline {subsubsection}{\numberline {1.1.0.4}Storage1}{170}{subsubsection.Anexo.1.1.0.4}%
-\contentsline {subsubsection}{\numberline {1.1.0.5}HAproxy1}{171}{subsubsection.Anexo.1.1.0.5}%
\contentsline {section}{\numberline {1.2}Configuración}{172}{section.Anexo.1.2}%
\contentsline {subsection}{\numberline {1.2.1}Configuración claves SSH}{172}{subsection.Anexo.1.2.1}%
\contentsline {subsection}{\numberline {1.2.2}Archivos de configuración OSA}{173}{subsection.Anexo.1.2.2}%
-\contentsline {subsubsection}{\numberline {1.2.2.1}openstack\_user\_config.yml}{173}{subsubsection.Anexo.1.2.2.1}%
-\contentsline {subsubsection}{\numberline {1.2.2.2}user\_variables.yml}{176}{subsubsection.Anexo.1.2.2.2}%
-\contentsline {subsubsection}{\numberline {1.2.2.3}cinder.yml}{178}{subsubsection.Anexo.1.2.2.3}%
\contentsline {subsection}{\numberline {1.2.3}Generación de claves}{178}{subsection.Anexo.1.2.3}%
\contentsline {subsection}{\numberline {1.2.4}Correcciones}{178}{subsection.Anexo.1.2.4}%
\contentsline {subsubsection}{\numberline {1.2.4.1}SELinux}{178}{subsubsection.Anexo.1.2.4.1}%
\contentsline {chapter}{\numberline {2}Instalación versión Stein}{179}{appendix.Anexo.2}%
\contentsline {section}{\numberline {2.1}Preparación de nodos}{179}{section.Anexo.2.1}%
-\contentsline {subsubsection}{\numberline {2.1.0.1}Deploy}{179}{subsubsection.Anexo.2.1.0.1}%
-\contentsline {subsubsection}{\numberline {2.1.0.2}Infra1}{182}{subsubsection.Anexo.2.1.0.2}%
-\contentsline {subsubsection}{\numberline {2.1.0.3}Compute1}{184}{subsubsection.Anexo.2.1.0.3}%
-\contentsline {subsubsection}{\numberline {2.1.0.4}Compute2}{186}{subsubsection.Anexo.2.1.0.4}%
-\contentsline {subsubsection}{\numberline {2.1.0.5}Storage1}{186}{subsubsection.Anexo.2.1.0.5}%
-\contentsline {subsubsection}{\numberline {2.1.0.6}Storage2}{187}{subsubsection.Anexo.2.1.0.6}%
-\contentsline {subsubsection}{\numberline {2.1.0.7}HAproxy1}{187}{subsubsection.Anexo.2.1.0.7}%
-\contentsline {subsubsection}{\numberline {2.1.0.8}Router}{188}{subsubsection.Anexo.2.1.0.8}%
\contentsline {section}{\numberline {2.2}Configuración archivos OSA}{192}{section.Anexo.2.2}%
-\contentsline {subsubsection}{\numberline {2.2.0.1}openstack\_user\_config.yml}{192}{subsubsection.Anexo.2.2.0.1}%
-\contentsline {subsubsection}{\numberline {2.2.0.2}user\_variables.yml}{197}{subsubsection.Anexo.2.2.0.2}%
-\contentsline {subsubsection}{\numberline {2.2.0.3}cinder.yml}{199}{subsubsection.Anexo.2.2.0.3}%
+\contentsline {subsubsection}{\numberline {2.2.0.1}user\_variables.yml}{197}{subsubsection.Anexo.2.2.0.1}%
\contentsline {section}{\numberline {2.3}Ejecución de playbooks}{199}{section.Anexo.2.3}%
\contentsline {section}{\numberline {2.4}Cambios para driver OVS}{200}{section.Anexo.2.4}%
\contentsline {chapter}{\numberline {3}Virtualización con KVM}{203}{appendix.Anexo.3}%
diff --git a/docs/udelartex/tesis.xwm b/docs/udelartex/tesis.xwm
index c2e90b8a7b50dc793c582aabbbf1ea2233c7ed7d..eb51ce7c4c159e41878972cfaa245bfbf1494a41 100644
--- a/docs/udelartex/tesis.xwm
+++ b/docs/udelartex/tesis.xwm
@@ -1,2 +1,2 @@
\relax
-\xwmnewlabel{xwmlastpage}{{5}{231}{migrate\_instance.sh\relax }{lstnumber.-283.30}{}}
+\xwmnewlabel{xwmlastpage}{{5}{231}{migrate\_instance.sh\relax }{lstnumber.-285.31}{}}