diff --git a/docs/udelartex/capitulos/fundamentos.tex b/docs/udelartex/capitulos/fundamentos.tex
index 62a994d8843d94f72e548a86de88dba89aad957a..de610796a8bf52a1e687cc9f069c71d9b1422583 100644
--- a/docs/udelartex/capitulos/fundamentos.tex
+++ b/docs/udelartex/capitulos/fundamentos.tex
@@ -1,8 +1,8 @@
 \chapter{Fundamentos teóricos}
-A continuación se presentan conceptos introductorios relevantes para comprender el estudio que se desarrollará más adelante en el informe.
+A continuación se presentan conceptos introductorios relevantes para comprender el estudio que se desarrollará más adelante en el informe. Estas definiciones intentan poner sobre la mesa terminología típica del mundo de Datacenters, principalmente orientadas a OpenStack, tales como estilos de virtualización, elementos de redes y backends de almacenamiento.
 
 \section{Cloud computing}       
-Cloud computing resulta ser un modelo que involucra tanto a los servicios computacionales provistos a los clientes a través de Internet, como a la implementación de hardware y software que logra proveerlos. Esta última se aloja en los denominados Datacenters, que integran adecuadamente los diversos recursos tales como redes, servidores, almacenamiento y software necesarios para ofrecer los mencionados servicios en función de la demanda. Este modelo computacional, impulsado durante el siglo 21, ha evolucionado velozmente y ha migrado el mundo de TI de las antiguas PCs locales de usuarios y de los cuartos de servidores empresariales a la llamada “nube” alojada en lejanos Datacenters.
+Cloud computing resulta ser un modelo que involucra tanto a los servicios computacionales provistos a los clientes a través de Internet, como a la implementación de hardware y software que logra proveerlos. Esta última se aloja en los denominados Datacenters, que integran adecuadamente diversos recursos tales como redes, servidores, almacenamiento y software necesarios para ofrecer los mencionados servicios en función de la demanda. Este modelo computacional, impulsado durante el siglo 21, ha evolucionado velozmente y ha migrado el mundo de TI de las antiguas PCs locales de usuarios y de los cuartos de servidores empresariales a la llamada “nube” alojada en lejanos Datacenters.
 
 Según la definición brindada por \gls{NIST} \cite{sp800-145}, la computación en la nube debe cumplir con 5 características esenciales:
 
@@ -18,15 +18,16 @@ Según la definición brindada por \gls{NIST} \cite{sp800-145}, la computación
 
 \item \textbf{Measured service}: los recursos consumidos deben ser monitorizados y medidos con un determinado nivel de abstracción en función del servicio provisto. Deben existir reportes de consumo que brinden absoluta transparencia tanto al proveedor como al consumidor.
 \end{itemize}
-Estas propiedades ambiciosas demuestran que brindar un servicio de cloud no es para nada trivial y requiere grandes conocimientos de TI a la hora de diseñar y poner un marcha un Datacenter.
+
+\noindent Estas propiedades ambiciosas demuestran que brindar un servicio de cloud no es para nada trivial y requiere grandes conocimientos de TI a la hora de diseñar y poner un marcha un Datacenter.
 
 En cuanto a los modelos de cloud computing, existen tres clasificaciones que se distinguen según el tipo de servicio provisto \cite{Zhang2010}:
 \begin{itemize}
-\item \textbf{\gls{SAAS}}: refiere al servicio que provee aplicaciones a través de internet que se encuentran corriendo en la infraestructura de la nube (Datacenter). Los consumidores del servicio no manipulan la infraestructura subyacente ni las configuraciones de aplicación.
+\item \textbf{\gls{SAAS}}: refiere al servicio que provee aplicaciones a través de Internet que se encuentran corriendo en la infraestructura de la nube (Datacenter). Los consumidores del servicio no manipulan la infraestructura subyacente ni las configuraciones de aplicación.
 
 \item \textbf{\gls{PAAS}}: consiste en proveer recursos a nivel de plataforma, como por ejemplo soporte de sistemas operativos, que permiten al cliente desplegar sus propias aplicaciones. El consumidor no puede manipular la infraestructura pero sí es capaz de administrar lo que se despliega sobre ella.
 
-\item \textbf{\gls{IAAS}}: se asocia al suministro de recursos de infraestructura a demanda. Se suele proveer al cliente de capacidad de procesamiento, almacenamiento y conectividad de red. Típicamente se ofrecen máquinas virtuales con la posibilidad de que el cliente manipule los sistemas operativos y las aplicaciones. Nuevamente el consumidor no es capaz de influir en la infraestructura que implementa la nube.
+\item \textbf{\gls{IAAS}}: se asocia al suministro de recursos de infraestructura a demanda. Se suele proveer al cliente de capacidad de procesamiento, almacenamiento y conectividad de red. Típicamente se ofrecen máquinas virtuales con la posibilidad de que el cliente manipule los sistemas operativos y las aplicaciones. Nuevamente el consumidor no es capaz de influir en la infraestructura que implementa la nube. Esta última clasificación es en la que se encuentra el despliegue que es realizado mediante OpenStack.
 \end{itemize}
 
 
@@ -34,7 +35,7 @@ En cuanto a los modelos de cloud computing, existen tres clasificaciones que se
 Uno de los principales conceptos que se encuentra involucrado en la implementación de cloud computing es el de virtualización \cite{redhat-virtualization}\cite{vmware-virtualization}. Esta tecnología permite simular diversos ambientes con recursos dedicados a partir de un solo sistema físico. Es posible crear aplicaciones, servidores, almacenamiento y redes, utilizando al máximo todos los recursos del sistema subyacente aumentando el rendimiento general. Los usuarios finales interactúan directamente con las virtualizaciones, llamadas máquinas virtuales. Una máquina virtual puede ser transferida de un sistema host a otro y funcionar de igual forma.
 
 
-La implementación de esta tecnología se da mediante los denominados \textbf{hipervisores} \cite{redhat-virtualization}\cite{oracle-hypervisors}, los cuales se encargan de conectar los recursos físicos de la máquina host con las máquinas virtuales. Estos trabajan sobre el sistema operativo o directamente en el hardware, creando una plataforma virtual, que divide los recursos físicos, sobre la cual se ejecutan las diferentes virtualizaciones. Por otro lado también son responsables de crear ambientes aislados que brinden seguridad entre las máquinas virtuales.
+La implementación de esta tecnología se da mediante los denominados \textbf{hipervisores} \cite{redhat-virtualization}\cite{oracle-hypervisors}, los cuales se encargan de conectar los recursos físicos de la máquina host con las máquinas virtuales. Estos trabajan sobre el sistema operativo o directamente en el hardware, creando una plataforma virtual que divide los recursos físicos, sobre la cual se ejecutan las diferentes virtualizaciones. Por otro lado también son responsables de crear ambientes aislados que brinden seguridad entre las máquinas virtuales.
 
 \begin{figure}[h!]
 	\centering
@@ -46,11 +47,11 @@ Los hipervisores se suelen clasificar en dos tipos:
 \begin{itemize}
 \item \textbf{Nativos o bare metal}: se trata de software que corre directamente sobre el hardware del sistema host, controlando el hardware y monitoreando el sistema operativo invitado. Algunos ejemplos son Oracle VM, Microsoft Hyper-V, VMware ESXi y Xen.
 
-\item \textbf{Alojados o hosted}: consisten en hipervisores que corren dentro de un sistema operativo tradicional. Se encuentran en una capa de aplicación por encima del sistema operativo del host pero por debajo del sistema operativo guest. Algunos ejemplos son Oracle VM VirtualBox, VMware Server y Workstation, Microsoft Virtual PC, KVM, QEMU y Parallels.
+\item \textbf{Alojados o hosted}: consisten en hipervisores que corren dentro de un sistema operativo tradicional. Se encuentran en una capa de aplicación por encima del sistema operativo del host pero por debajo del sistema operativo guest. Algunos ejemplos son Oracle VM VirtualBox, VMware Server y Workstation, Microsoft Virtual PC, KVM, QEMU y Parallels. Las máquinas virtuales creadas mediante la plataforma OpenStack, son instanciadas por un hipervisor de esta categoría.
 \end{itemize}
 
 \subparagraph{KVM}
-\gls{KVM} \cite{redhat-kvm} se trata de una tecnología de virtualización open source sobre Linux. Se encuentra formada por un módulo del kernel denominado KVM.ko y permite transformar un sistema operativo Linux en un hipervisor. Como módulo del kernel se encuentra incluido en Linux a partir de la versión 2.6.20. Como hipervisor se clasifica como de tipo alojado, o hosted, utilizando los componentes del sistema Linux para implementar cada máquina virtual como un proceso de Linux.
+\gls{KVM} \cite{redhat-kvm} se trata de una tecnología de virtualización open source sobre Linux. Se encuentra formada por un módulo del kernel denominado KVM.ko y permite transformar un sistema operativo Linux en un hipervisor. Como módulo del kernel se encuentra incluido en Linux a partir de la versión 2.6.20. Como hipervisor se clasifica como de tipo alojado, o hosted, utilizando los componentes del sistema Linux para implementar cada máquina virtual como un proceso de Linux. Este es el  hipervisor utilizado por OpenStack mencionado anteriormente.
 
 \section{Contenerización}
 Un contenedor \cite{docker-containers} es una unidad de software liviana diseñada para ejecutar una aplicación. Está formado únicamente por el código de la aplicación y las dependencias necesarias para que esta ejecute, creando un paquete portable e independiente. De esta forma múltiples contenedores pueden correr como procesos diferentes en una misma máquina host compartiendo el kernel del sistema operativo.
@@ -65,13 +66,13 @@ Si bien tanto contenedores como máquinas virtuales tienen como fin aislar y com
 
 La combinación de estas tecnologías provee gran flexibilidad al realizar el despliegue de aplicaciones sobre varios servidores, complementando lo ligero de los contenedores con el aislamiento de recursos físicos y la seguridad obtenidos mediante VMs.
 
-Citando la ‘Application Container Security Guide’ (SP 800-190 de NIST \cite{sp800-190}): \textsl{“A pesar de que a veces se considera que los contenedores son la siguiente fase de virtualización, sobrepasando la virtualización de hardware, la realidad de la mayoría de las organizaciones apunta menos a la revolución que a la evolución. Los contenedores y la virtualización de hardware no solo pueden, sino que frecuentemente lo hacen, coexistir y heredar las capacidades del otro. Las VMs brindan muchos beneficios, tales como fuerte aislamiento, automatización de SO, y un amplio y profundo ecosistema de soluciones. Las organizaciones no necesitan tomar una decisión entre contenedores y máquinas virtuales. Por el contrario pueden continuar utilizando VMs para desplegar, particionar y administrar su hardware, mientras que utilizan contenedores para empaquetar sus aplicaciones, aprovechando cada VM más eficientemente.”} Es por esto que ambas tecnologías serán utilizadas más adelante en la puesta en marcha de un Datacenter de prueba mediante Openstack.
+Citando la ‘Application Container Security Guide’ (SP 800-190 de NIST \cite{sp800-190}): \textsl{“A pesar de que a veces se considera que los contenedores son la siguiente fase de virtualización, sobrepasando la virtualización de hardware, la realidad de la mayoría de las organizaciones apunta menos a la revolución que a la evolución. Los contenedores y la virtualización de hardware no solo pueden, sino que frecuentemente lo hacen, coexistir y heredar las capacidades del otro. Las VMs brindan muchos beneficios, tales como fuerte aislamiento, automatización de SO, y un amplio y profundo ecosistema de soluciones. Las organizaciones no necesitan tomar una decisión entre contenedores y máquinas virtuales. Por el contrario pueden continuar utilizando VMs para desplegar, particionar y administrar su hardware, mientras que utilizan contenedores para empaquetar sus aplicaciones, aprovechando cada VM más eficientemente.”} Es por esto que ambas tecnologías serán utilizadas más adelante en la puesta en marcha de un Datacenter de prueba mediante OpenStack.
 
 \subparagraph{LXC}
-Un \gls{LXC} \cite{arch-lxc}\cite{redhat-lxc} es un contenedor formado por un conjunto de procesos que se encuentran aislados del resto del sistema host. Como tal, brinda un entorno virtual con su propia CPU, memoria, red, etc, implementado mediante el uso de los namespaces y cgroups del kernel Linux corriendo en la máquina host. Este tipo de contenedores es utilizado por Openstack durante su despliegue para ejecutar los servicios en cuya configuración se haya indicado que utilicen contenedores en lugar de correr directo sobre el servidor.
+Un \gls{LXC} \cite{arch-lxc}\cite{redhat-lxc} es un contenedor formado por un conjunto de procesos que se encuentran aislados del resto del sistema host. Como tal, brinda un entorno virtual con su propia CPU, memoria, red, etc, implementado mediante el uso de los namespaces y cgroups del kernel Linux corriendo en la máquina host. Este tipo de contenedores es utilizado por OpenStack durante su despliegue para ejecutar los servicios en cuya configuración se haya indicado que utilicen contenedores en lugar de correr directo sobre el servidor.
 
 \section{Datacenters}
-La infraestructura que se encuentra por debajo de la mencionada nube se conoce con el nombre de Datacenter. Un Datacenter \cite{cisco-datacenter} es un espacio físico que aloja múltiples componentes de hardware interconectados tales como servidores, racks, switches, routers, sistemas de almacenamiento, etc. Estos últimos proveen una red de recursos de red, cómputo y almacenamiento, necesaria para alojar diversas aplicaciones o grandes cantidades de datos. A su vez, los nuevos Datacenters escalan implementando infraestructuras virtualizadas, utilizando los mecanismos mencionados anteriormente, por encima de la física ya existente llegando a interconectar múltiples espacios físicos ubicados en diversas partes del mundo. Debido al gran potencial computacional existente en este tipo de infraestructuras, su mayor explotación se encuentra en la ejecución de tecnologías tales como big data, inteligencia artificial, aprendizaje automático, entre otras.
+La infraestructura que se encuentra por debajo de la mencionada nube se conoce con el nombre de Datacenter. Un Datacenter \cite{cisco-datacenter} es un espacio físico que aloja múltiples componentes de hardware interconectados tales como servidores, racks, switches, routers, sistemas de almacenamiento, etc. Estos proveen una red de recursos de red, cómputo y almacenamiento, necesaria para alojar diversas aplicaciones o grandes cantidades de datos. A su vez, los nuevos Datacenters escalan implementando infraestructuras virtualizadas, utilizando los mecanismos mencionados anteriormente, por encima de la física ya existente llegando a interconectar múltiples espacios físicos ubicados en diversas partes del mundo. Debido al gran potencial computacional existente en este tipo de infraestructuras, su mayor explotación se encuentra en la ejecución de tecnologías tales como big data, inteligencia artificial, aprendizaje automático, entre otras.
 
 Por su gran importancia en la tecnología de la información actual, los Datacenters no solo requieren un diseño de infraestructura de recursos computacionales sino también un diseño de componentes físicos externos que garanticen la seguridad física y una tasa de resistencia a fallas prácticamente perfecta. En función de estos aspectos es que existe un estándar internacional especificado por la \gls{ANSI} que califica y certifica el diseño de un Datacenter. Existen entonces cuatro categorías bajo el estándar ANSI/TIA-942 que se resumen a continuación:
 
@@ -80,34 +81,36 @@ Por su gran importancia en la tecnología de la información actual, los Datacen
 
 \item \textbf{TIER 2}: se corresponde a Datacenters que posean un mínimo nivel de redundancia a nivel de componentes pero no de distribución eléctrica. Además aumentan su protección en cuanto a eventos físicos, en comparación con el nivel anterior.
 
-\item \textbf{TIER 3}: suele indicarse para organizaciones que requieren un servicio con disponibilidad 24/7. Mantiene redundancia tanto a nivel de componentes como de distribución eléctrica. Tolera prácticamente cualquier tipo fallas físicas. Para mantener el sistema (ej: recambio de componentes) no es necesario paralizarlo.
+\item \textbf{TIER 3}: suele indicarse para organizaciones que requieren un servicio con disponibilidad 24/7. Mantiene redundancia tanto a nivel de componentes como de distribución eléctrica. Tolera prácticamente cualquier tipo fallas físicas. Para llevar a cabo tareas de mantenimiento en el sistema (ej: recambio de componentes) no es necesario paralizarlo.
 
 \item \textbf{TIER 4}: enfocado a grandes organizaciones mundiales. Mantiene el mayor nivel de tolerancia a fallas junto con redundancia de componentes y distribuciones eléctricas. Es posible que ocurra un mantenimiento del sistema junto con una falla inesperada sin que el servicio se vea afectado.		
 \end{itemize}
 
 \section{Redes}
-En la etapa de configuración e instalación y posteriormente en la utilización de Openstack, se referencian diversos conceptos de red, por ejemplo, protocolos, tipos de redes y componentes virtualizados. A continuación se introducirán brevemente algunos de estos conceptos.
+En la etapa de configuración e instalación y posteriormente en la utilización de OpenStack, se referencian diversos conceptos de red, por ejemplo, protocolos, tipos de redes y componentes virtualizados. A continuación se introducirán brevemente algunos de estos conceptos.
 
 \subparagraph{Flat}
 Una red flat hace referencia a una red en la cual no se utiliza ningún tipo de tag. Las interfaces físicas o virtuales se asocian directamente al switch o bridge por lo tanto solamente una red flat puede existir por cada interfaz física.
 
 \subparagraph{VLAN}
-Una \gls{VLAN} permite segmentar de manera virtual un dominio de difusión de capa 2 en múltiples dominios de difusión. Esto permite utilizar un switch como si fuera múltiples switches. A modo de ejemplo, dos host conectados a un mismo switch pero en distintas VLANs no podrán ver el tráfico generado por el otro. Para identificar a qué VLAN corresponde una trama se utiliza un nuevo campo en el cual se introduce el ID de la VLAN, estos cambios que se realizan a la trama Ethernet se establecen en el estándar IEEE 802.1Q \cite{802.1Q}. Openstack utiliza las VLANs con el fin de aislar el tráfico de datos de diferentes clientes, sin importar en qué servidor físico (nodo de cómputo) estén corriendo las máquinas de los mismos \cite{openstack-basic-networking}.
+Una \gls{VLAN} permite segmentar de manera virtual un dominio de difusión de capa 2 en múltiples dominios de difusión. Esto permite utilizar un switch como si fuera múltiples switches. A modo de ejemplo, dos hosts conectados a un mismo switch pero en distintas VLANs no podrán ver el tráfico generado por el otro. Para identificar a qué VLAN corresponde una trama se utiliza un nuevo campo en el cual se introduce el ID de la VLAN, estos cambios que se realizan a la trama Ethernet se establecen en el estándar IEEE 802.1Q \cite{802.1Q}. Openstack utiliza las VLANs con el fin de aislar el tráfico de datos de diferentes clientes, sin importar en qué servidor físico (nodo de cómputo) estén corriendo las máquinas de los mismos \cite{openstack-basic-networking}.
 
 \subparagraph{VXLAN}
-El protocolo \gls{VXLAN} se ubica dentro de los protocolos de superposición (overlay protocols) que utilizan el mecanismo de tunelización para el transporte de datos. VXLAN encapsula una trama Ethernet dentro de paquetes UDP los cuales pueden ser ruteados. Esto permite extender una red local sobre múltiples redes de capa 3 en forma transparente para los host finales. El funcionamiento del protocolo se encuentra en el RFC 7348 \cite{rfc7348}. Para diferenciar las distintas redes virtuales en lugar de utilizar un VLAN ID se utiliza un VXLAN Network Identifier (VNI), el cual puede tomar aproximadamente 16 millones de valores siendo una de las principales diferencias con las VLANs que pueden tomar 4096 valores únicos. Esta diferencia para Datacenters de gran porte es vital para poder aislar el tráfico de los clientes del mismo. Un componente necesario para encapsular y desencapsular son los VXLAN Tunnel Endpoint (VTEP) los cuales residen en los nodos físicos. Un listado con pros y contras de las redes de capa 2 y capa 3 se presenta en \cite{openstack-networking-concepts}.
+El protocolo \gls{VXLAN} se ubica dentro de los protocolos de superposición (overlay protocols) que utilizan el mecanismo de tunelización para el transporte de datos. VXLAN encapsula una trama Ethernet dentro de paquetes UDP los cuales pueden ser ruteados. Esto permite extender una red local sobre múltiples redes de capa 3 en forma transparente para los host finales. El funcionamiento del protocolo se encuentra en el RFC 7348 \cite{rfc7348}. Para diferenciar las distintas redes virtuales en lugar de utilizar un VLAN ID se utiliza un VXLAN Network Identifier (VNI), el cual puede tomar aproximadamente 16 millones de valores siendo una de las principales diferencias con las VLANs que pueden tomar 4096 valores únicos. Esta diferencia para Datacenters de gran porte es vital para poder aislar el tráfico de los clientes del mismo. Un componente necesario para encapsular y desencapsular son los VXLAN Tunnel Endpoints (VTEPs) los cuales residen en los nodos físicos. \\
+
+A la hora de decidir el tipo de red a utilizar para los clientes de un Datacenter es importante evaluar las pros y contras de cada una de ellas. En \cite{openstack-networking-concepts} se presenta un listado en el que se comparan los beneficios y perjuicios de utilizar redes de capa 2 y capa 3.
 
 \subparagraph{Network namespaces}
-El concepto de namespace es utilizado para brindar aislamiento entre dos conjuntos de recursos. Precisamente en Linux los namespaces de red aíslan diversos recursos de red permitiendo mantener disjuntos conjuntos de interfaces e incluso tablas de ruteo. Esto último es utilizado por el módulo de red de Openstack a la hora de instanciar servicios de red virtuales tales como routing y DHCP. De esta forma es posible que coexistan diferentes redes virtuales con el mismo direccionamiento IP en un mismo servidor de red sin solaparse \cite{openstack-network-namespaces}.
+El concepto de namespace es utilizado para brindar aislamiento entre dos conjuntos de recursos. Precisamente en Linux los namespaces de red aíslan diversos recursos de red permitiendo mantener disjuntos conjuntos de interfaces e incluso tablas de ruteo. Esto último es utilizado por el módulo de red de OpenStack a la hora de instanciar servicios de red virtuales tales como routing y DHCP. De esta forma es posible que coexistan diferentes redes virtuales con el mismo direccionamiento IP en un mismo servidor de red sin solaparse \cite{openstack-network-namespaces}.
 
 \section{Interfaces y bridges}
-Desde el diseño de la arquitectura física hasta la implementación de instancias virtuales por parte de Openstack, se utilizan una serie de interfaces y bridges de diferentes tipos para proveer conectividad de red. Estos tipos son detallados brevemente a continuación.
+Desde el diseño de la arquitectura física hasta la implementación de instancias virtuales por parte de OpenStack, se utilizan una serie de interfaces y bridges de diferentes tipos para proveer conectividad de red. Estos tipos son detallados brevemente a continuación.
 
 \subparagraph{Interfaces tap} 
 Estas interfaces son creadas y utilizadas por un hipervisor como QEMU/KVM para conectar una instancia de una VM con el host subyacente. Las interfaces en el host se corresponden a una interfaz de red dentro de la instancia.
 
 \subparagraph{Linux bridge} 
-Es una interfaz virtual que conecta múltiples interfaces de red. Se comporta como un switch virtual al cual se asocian uno o más segmentos de red. Particularmente, en Openstack se utilizan este tipo de bridges para bridar conexión a los servicios que se encuentran corriendo en contenedores. También son aplicados por el módulo de red a la hora de interconectar las instancias con las redes virtuales a nivel del host físico \cite{arch-network-bridge}. 
+Es una interfaz virtual que conecta múltiples interfaces de red. Se comporta como un switch virtual al cual se asocian uno o más segmentos de red. Particularmente, en OpenStack se utilizan este tipo de bridges para bridar conexión a los servicios que se encuentran corriendo en contenedores. También son aplicados por el módulo de red a la hora de interconectar las instancias con las redes virtuales a nivel del host físico \cite{arch-network-bridge}. 
 
 \subparagraph{Veth cables} 
 Son interfaces virtuales que imitan el comportamiento de un cable de red. Una trama enviada en un extremo del veth cable será recibida por el otro. El módulo de red utiliza estos dispositivos cuando realiza conexiones entre network namespaces y Linux bridges, así como cuando conecta Linux bridges con OpenvSwitch switches.
@@ -126,7 +129,7 @@ Ceph se trata de un sistema de almacenamiento de datos distribuido y libre. Unif
 	\item \textbf{OSDs}: su abreviatura viene de Object Storage Device, este tipo de demonios corre en los nodos de almacenamiento y son capaces de comunicarse entre sí sin tener que depender de una unidad central.
 \end{itemize}
 
-Ceph modela la información que recibe del cliente como objetos y la almacena en los OSDs como un archivo en un namespace sin jerarquía de directorios. Cada uno de estos objetos también mantiene un identificador y posible metadata interpretada por el cliente. Durante el proceso de escritura, el cliente primero debe obtener una copia actualizada del cluster desde un nodo monitor para luego escribir directamente sobre un OSD primario. Este último se encarga de crear réplicas en otros nodos para garantizar la seguridad y alta disponibilidad de los datos. Los monitores se encargan de controlar el estado de la información para brindar las garantías mencionadas \cite{ceph-architecture}.
+Ceph modela la información que recibe del cliente como objetos y la almacena en los OSDs como un archivo dentro de un namespace sin jerarquía de directorios. Cada uno de estos objetos también mantiene un identificador y posible metadata interpretada por el cliente. Durante el proceso de escritura, el cliente primero debe obtener una copia actualizada del cluster desde un nodo monitor para luego escribir directamente sobre un OSD primario. Este último se encarga de crear réplicas en otros nodos para garantizar la seguridad y alta disponibilidad de los datos. Los monitores se encargan de controlar el estado de la información para brindar las garantías mencionadas \cite{ceph-architecture}.
 
 \begin{figure}[H]
 	\centering
diff --git a/docs/udelartex/capitulos/planproyecto.tex b/docs/udelartex/capitulos/planproyecto.tex
index 5d79f9d44cd5de1bba1c99a7396d6a3a7c7f7d5d..8680e4a483e9bf73834af4375fe2f593b32168c0 100644
--- a/docs/udelartex/capitulos/planproyecto.tex
+++ b/docs/udelartex/capitulos/planproyecto.tex
@@ -4,7 +4,7 @@ El trabajo tuvo una duración de 18 meses, iniciando en Agosto de 2018 y extendi
 
 \textbf{Agosto - Setiembre 2018:} en el inicio del proyecto se comenzó a relevar la tecnología teniendo como único respaldo la documentación oficial. Al tratarse de una primera experiencia de despliegue con OpenStack a nivel académico, no existía ningún precedente dentro de la Udelar para tener como referencia. Planteado esto, se comenzó por entender el funcionamiento de la plataforma a nivel macro [capítulo openstack] utilizando ambientes locales meramente de aprendizaje desplegados con DevStack [métodos de instalación]. Además se debió decidir qué versión y con qué mecanismo instalar OpenStack [sección en capítulo de diseño].
 
-Octubre - Diciembre 2018: se planteó realizar una primera instalación de OSA en un ambiente local. Siguiendo la guía de despliegue de OSA se decidió una arquitectura simplificada de 4 nodos y virtualizada con VirtualBox. En este punto se esperaba tener un instalación funcional local en un periodo de 1 mes de pruebas. La realidad fue que surgieron múltiples problemas al comenzar la ejecución de las playbooks con Ansible, en donde por cada problema se investigaba su origen y se realizaban modificaciones a nivel de los archivos de configuración, de la arquitectura virtualizada o sobre los recursos creados por la propia instalación, para reintentar el proceso. Estos ciclos de prueba y error se extendieron durante dos meses, ayudando a comprender mejor diferentes aspectos de OpenStack Ansible. Sobre el final de esta etapa se llegó a la conclusión de que era necesario un ambiente de desarrollo compartido y con mejores prestaciones debido a que cada ciclo de ejecución consumía prácticamente la totalidad de los recursos durante varias horas. Además permitiría mejorar la metodología de trabajo uniformizando las pruebas gracias a la eliminación de las diferencias entre los ambientes locales.
+\textbf{Octubre - Diciembre 2018}: se planteó realizar una primera instalación de OSA en un ambiente local. Siguiendo la guía de despliegue de OSA se decidió una arquitectura simplificada de 4 nodos y virtualizada con VirtualBox. En este punto se esperaba tener un instalación funcional local en un periodo de 1 mes de pruebas. La realidad fue que surgieron múltiples problemas al comenzar la ejecución de las playbooks con Ansible, en donde por cada problema se investigaba su origen y se realizaban modificaciones a nivel de los archivos de configuración, de la arquitectura virtualizada o sobre los recursos creados por la propia instalación, para reintentar el proceso. Estos ciclos de prueba y error se extendieron durante dos meses, ayudando a comprender mejor diferentes aspectos de OpenStack Ansible. Sobre el final de esta etapa se llegó a la conclusión de que era necesario un ambiente de desarrollo compartido y con mejores prestaciones debido a que cada ciclo de ejecución consumía prácticamente la totalidad de los recursos durante varias horas. Además permitiría mejorar la metodología de trabajo uniformizando las pruebas gracias a la eliminación de las diferencias entre los ambientes locales.
 
 \textbf{Enero 2019:} el ambiente de desarrollo mencionado fue implementado por un conjunto de 4 máquinas virtuales alojadas en un servidor del INCO con el fin de replicar el ambiente local. A la hora de realizar las configuraciones requeridas, surgió la necesidad de modificar los recursos de red y almacenamiento de las VMs. Esta tarea se vio imposibilitada por no tener permisos directamente sobre el servidor físico. Como consecuencia se intentó virtualizar todo el ambiente dentro de una sola máquina virtual, lo que implicaba el uso de VirtualBox dentro de una instancia de KVM. Esta virtualización anidada generó severos inconvenientes al intentar acceder a una instancia para los cuales no se encontró una solución.  Esto apuntaba a que para trabajar en un ambiente de desarrollo era necesario contar con ciertos permisos en el servidor físico.
 
diff --git a/docs/udelartex/tesis.lof b/docs/udelartex/tesis.lof
index a45d7189b3c8561ed10e91f7d2c295cf1805c23f..0fa246b80989c4d6ddf9989b98e5c75e3f91059b 100644
--- a/docs/udelartex/tesis.lof
+++ b/docs/udelartex/tesis.lof
@@ -5,9 +5,9 @@
 \addvspace {10\p@ }
 \addvspace {10\p@ }
 \contentsline {figure}{\numberline {3.1}{\ignorespaces Hipervisores. Extraída de \cite {redhat-virtualization}.\relax }}{8}{figure.caption.6}%
-\contentsline {figure}{\numberline {3.2}{\ignorespaces Virtualización vs Contenerización. Extraída de \cite {redhat-lxc}.\relax }}{9}{figure.caption.8}%
+\contentsline {figure}{\numberline {3.2}{\ignorespaces Virtualización vs Contenerización. Extraída de \cite {redhat-lxc}.\relax }}{10}{figure.caption.8}%
 \contentsline {figure}{\numberline {3.3}{\ignorespaces Proceso de replicación en OSDs de Ceph. Extraída de \cite {ceph-architecture}.\relax }}{15}{figure.caption.17}%
-\contentsline {figure}{\numberline {3.4}{\ignorespaces Proceso de almacenamiento en pools de Ceph. Extraída de \cite {ceph-architecture}.\relax }}{15}{figure.caption.18}%
+\contentsline {figure}{\numberline {3.4}{\ignorespaces Proceso de almacenamiento en pools de Ceph. Extraída de \cite {ceph-architecture}.\relax }}{16}{figure.caption.18}%
 \contentsline {figure}{\numberline {3.5}{\ignorespaces Proceso de almacenamiento en PGs de Ceph. Extraída de \cite {ceph-architecture}.\relax }}{16}{figure.caption.19}%
 \addvspace {10\p@ }
 \contentsline {figure}{\numberline {4.1}{\ignorespaces Relacionamiento entre módulos core\relax }}{19}{figure.caption.20}%
diff --git a/docs/udelartex/tesis.pdf b/docs/udelartex/tesis.pdf
index 5413ffa48443d220c804e1bb2efd68905c195daf..4f2a82d55ad9ec397f2052dc8105ee70c1062e7a 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 55d697bf1528c04d7f9982464afc05ef07f6730b..a8469623537752d1e987a33047eaf2717471dc1b 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 677e87d886b4d635c69c27e27e9d16232acce3d9..25993fd9df62202c5e2cd58258c1b64b8205d3c3 100644
--- a/docs/udelartex/tesis.toc
+++ b/docs/udelartex/tesis.toc
@@ -12,16 +12,16 @@
 \contentsline {subparagraph}{KVM}{9}{section*.7}%
 \contentsline {section}{\numberline {3.3}Contenerización}{9}{section.3.3}%
 \contentsline {subparagraph}{LXC}{10}{section*.9}%
-\contentsline {section}{\numberline {3.4}Datacenters}{10}{section.3.4}%
-\contentsline {section}{\numberline {3.5}Redes}{11}{section.3.5}%
+\contentsline {section}{\numberline {3.4}Datacenters}{11}{section.3.4}%
+\contentsline {section}{\numberline {3.5}Redes}{12}{section.3.5}%
 \contentsline {subparagraph}{Flat}{12}{section*.10}%
 \contentsline {subparagraph}{VLAN}{12}{section*.11}%
 \contentsline {subparagraph}{VXLAN}{12}{section*.12}%
-\contentsline {subparagraph}{Network namespaces}{12}{section*.13}%
+\contentsline {subparagraph}{Network namespaces}{13}{section*.13}%
 \contentsline {section}{\numberline {3.6}Interfaces y bridges}{13}{section.3.6}%
 \contentsline {subparagraph}{Interfaces tap}{13}{section*.14}%
 \contentsline {subparagraph}{Linux bridge}{13}{section*.15}%
-\contentsline {subparagraph}{Veth cables}{13}{section*.16}%
+\contentsline {subparagraph}{Veth cables}{14}{section*.16}%
 \contentsline {section}{\numberline {3.7}Backends de almacenamiento}{14}{section.3.7}%
 \contentsline {subsection}{\numberline {3.7.1}LVM}{14}{subsection.3.7.1}%
 \contentsline {subsection}{\numberline {3.7.2}Ceph}{14}{subsection.3.7.2}%