Avance reporte latex

docs/latex/report.tex

@@ -168,11 +168,234 @@ En esta sección se describirán los módulos Nova, Neutron, Glance, Cinder, Key
 	\centering
 		\includegraphics[width=1.0\columnwidth]{openstack-modules}
 	\caption{Relacionamiento entre módulos core}
-	\label{containers}
+	\label{modules}
 \end{figure}
 
 En [20] se muestra un esquema de una arquitectura lógica estándar de Openstack, en donde se puede apreciar las interacciones internas entre los componentes de un proyecto, las interacciones entre proyectos y las interacciones entre agentes externos y openstack.
 
+\subsection{Keystone}
+Keystone es el servicio de identidad que utiliza Openstack para la autenticación y autorización. El mismo se organiza como un conjunto de servicios internos, que se exponen en uno o varios endpoints, listados a continuación:
+
+\begin{figure}[H]
+	\centering
+		\includegraphics[width=0.8\columnwidth]{keystone}
+	\caption{Servicios y backends soportados por Keystone}
+	\label{keystone}
+\end{figure}
+
+\begin{itemize}
+	\item El \textbf{servicio de identidad} autenticación e información de usuarios y grupos. En una instalación estándar este servicio se encarga de todas las operaciones referentes a estos datos, sin embargo en instalaciones más complejas se pueden configurar distintos backends para llevar a cabo estas tareas. Un ejemplo de esto puede ser LDAP.
+	\begin{itemize}
+		\item Un usuario representa a un consumidor individual de la API el cual necesariamente debe pertenecer a un dominio y es único dentro del mismo.
+		\item Un grupo representa un conjunto de usuarios, los cuales al igual que los usuarios, deben pertenecer a un único dominio.
+	\end{itemize}
+	\item El \textbf{servicio de recursos} provee información sobre proyectos y dominios.
+	\begin{itemize}
+		\item Los proyectos representan la unidad base de propiedad en Openstack, debido a que todos los recursos deben pertenecer a un proyecto necesariamente. Los proyectos son únicos dentro de cada dominio.
+		\item Los dominios son grandes contenedores para los proyectos, grupos y usuarios. Por defecto Openstack crea el dominio “Default”. Dada la naturaleza de los dominios los mismos pueden ser utilizados para delegar la administración de los recursos.
+	\end{itemize}
+	\item El \textbf{servicio de asignación} provee información sobre roles y asignaciones.
+	\begin{itemize}
+		\item Un rol indica el nivel de autorización que un usuario final puede obtener. Un rol se puede otorgar a nivel de dominio o proyecto. Por otro lado un rol puede ser asignado a nivel de usuario o grupo.
+		\item Las asignaciones de roles son tripletas que contienen un rol, un recurso y una identidad.
+	\end{itemize}
+	\item El \textbf{servicio de Tokens} válida y administra los tokens utilizados para las solicitudes de autenticaciones enviadas luego que las credenciales del usuario fueron validadas.
+	\item el \textbf{servicio de catálogo} utilizado para el descubrimiento de endpoints.		
+\end{itemize}
+
+Las definiciones mencionadas fueron extraídas de [16] y [17].
+
+\subsection{Nova}
+Nova es el proyecto que se encarga de proveer una forma para provisionar instancias o servidores virtuales. El proyecto soporta la creacion de imagenes, servidores baremetal con la ayuda del proyecto ironic y un soporte limitado para el manejo de containers.\\
+Nova se compone por un conjunto de demonios que permiten ofrecer los servicios mencionados. Adicionalmente para poder desarrollar las funciones básicas, este módulo requiere de los siguientes servicios core de openstack: keystone, glance, neutron y placement.\\
+\\
+En la figura \href{nova} se puede apreciar un esquema conceptual de los principales componentes de una instalación de nova estándar. 
+Un dato relevante sobre los componentes de nova es que pueden ser escalados horizontalmente, siendo independiente el grado de escalado para cada servicio.
+
+\begin{figure}[H]
+	\centering
+		\includegraphics[width=0.8\columnwidth]{nova}
+	\caption{Principales componentes de Nova}
+	\label{nova}
+\end{figure}
+
+Internamente los componentes de nova se comunican mediante RPC mientras que la interfaz de cara al usuario es una API REST.\\
+
+Los principales componentes de nova son:
+
+\subparagraph{API}
+Se encarga de recibir y responder las solicitudes HTTP y comunicarse con los otros componentes de nova mediante la cola de mensajes.
+
+\subparagraph{Scheduler}
+Se encarga de decidir en qué host de cómputo se aloja cada instancia. Para tomar estas decisiones existen diversos algoritmos que pueden ser configurados, siendo algunos ejemplos el algoritmo simple donde selecciona el host con menor carga actual, chance en donde se elige un nodo de forma randómica, entre otros. Esta tarea puede ser muy sencilla como es el caso del algoritmo random o muy complicada para los casos donde se requiera realizar un uso eficiente de los recursos [25].
+
+\subparagraph{Compute}
+El módulo nova-compute es principalmente un demonio que se encarga de administrar la comunicación con el hypervisor y con las máquinas virtuales. Esto lo lleva a cabo mediante las APIs del hipervisor. Algun ejemplos de APIs son: libvirt para KVM o QEMU, XenAPI para XenServer y VMwareAPI para VMware.\\
+Haciendo a un lado la complejidad del módulo, básicamente el demonio acepta acciones de la cola de mensajes para luego realizar una serie de comandos contra la API del hipervisor. Además se encarga de actualizar el estado de la base de datos [26].
+
+\subparagraph{Conductor}
+En las primeras versiones de Openstack, todos los servicios del componente de cómputo tenían acceso directo a la base de datos hosteada en el nodo controlador. Esto presentaba dos grandes problemas: seguridad y performance. En lo que respecta a la seguridad, en el caso que un nodo de cómputo sea vea comprometido, el atacante tendrá acceso a la base de datos de Openstack. Por el lado de la performance, las llamadas realizadas desde el nodo de cómputo soportan un único hilo y son bloqueantes. Esto generaba un cuello de botella debido a no poder paralelizar las invocaciones. \\
+Para mejorar estos dos aspectos se introdujo el servicio nova-conductor el cual se presenta como una capa por encima del servicio de cómputo. Nova-compute en lugar de acceder directamente a la BD, delega la responsabilidad al servicio nova-conductor. En otras palabras este servicio actúa como un proxy para el servicio nova-compute. \\
+El problema de seguridad se resuelve dado que los nodos de cómputo dejan de acceder directamente a la BD y el de performance se resuelve gracias a que el servicio de nova-conductor es no bloqueante, permitiendo realizar múltiples invocaciones en paralelo [22].
+Por los motivos de su existencia, este servicio no se debe instalar en los nodos de cómputo. [23]. \\
+Además puede servir como un lugar donde centralizar y permitir administrar las operaciones que involucran al scheduler y el servicio de computo cómo construir, cambiar el tamaño o migrar instancias. Esto se realiza con el fin de separar las responsabilidades entre los servicios de nova. En [23] se muestra un ejemplo de los beneficios que este cambio presenta.
+
+\subparagraph{Placement}
+Este servicio se presenta como una API REST que se encarga de realizar un seguimiento de los proveedores de recursos. Los recursos pueden ser de distintas clases. A modo de ejemplo un proveedor puede ser un nodo de cómputo o un pool de storage.
+
+\subsection{Neutron}
+
+\begin{figure}[H]
+	\centering
+		\includegraphics[width=0.8\columnwidth]{neutron}
+	\caption{Arquitectura de Neutron}
+	\label{neutron}
+\end{figure}
+
+Neutron es el proyecto encargado de proveer y administrar recursos de red en una nube creada con Openstack. Es un sistema API-driven, escalable horizontalmente y diseñada para añadirle diversos plugins con el fin de proporcionar nuevas funcionalidades. \\
+Como otros servicios de Openstack, Neutron requiere una base de datos para persistir las configuraciones de los elementos de red. \\
+El servicio de red de Openstack permite crear desde redes y subredes hasta topologías de red avanzadas las cuales pueden contener firewalls, balanceadores, VPNs entre otros.\\
+Las instalaciones del módulo de red deben tener al menos un red externa, la cual no es una SDN definida dentro de Openstack sino que es una red accesible por fuera de Openstack. Estas redes permiten que las redes virtuales construidas con neutron tengan conectividad con el mundo exterior.\\
+Por otro lado, neutron permite crear redes internas a las cuales se conectarán directamente las VMs. Para lograr que dichas VMs se conecten con las redes externas son necesarios routers que relacionen ambos tipos de redes.\\
+
+Una arquitectura simplificada de neutron se puede ver en siguiente figura \href{neutron2}:
+
+\begin{figure}[H]
+	\centering
+		\includegraphics[width=0.8\columnwidth]{neutron2}
+	\caption{Arquitectura simplificada}
+	\label{neutron2}
+\end{figure}
+
+\subparagraph{Neutron-server}
+El módulo Neutron server es en donde reside la API recibiendo y respondiendo las solicitudes de recursos de red. El servidor se comunica con la base de datos para almacenar las configuraciones existentes como se mencionó previamente. 
+
+\subparagraph{Plugins y agentes}
+Por otro lado se encuentran una serie de agentes que se distribuyen típicamente en los nodos de red y cómputo. Estos agentes se agregan a demanda según las funcionalidades y rendimiento requeridos. Estos agentes o plugins serán los encargados de crear los recursos virtuales de red del cloud.
+
+\subparagraph{Cola de mensajes}
+En general se utiliza en las instalaciones del módulo de red para llevar a cabo la comunicación entre el neutron-server y los distintos agentes.
+
+...........................
+
+\subsection{Glance}
+Glance es el nombre del proyecto utilizado por Openstack para la administración de imágenes. Este servicio permite a los usuarios, a través de una API RESTful, gestionar tanto las imágenes de las máquinas virtuales como la metadata asociada a estas. Típicamente esta gestión involucra el descubrimiento, registro y obtención de los recursos mencionados.
+\\
+La implementación del servicio Glance se basa en una arquitectura cliente-servidor, comprendida por los siguientes componentes principales:
+
+\begin{itemize}
+	\item \textbf{Cliente}: es quien realiza pedidos a través de la API REST provista.
+	\item \textbf{API REST}: permite exponer todos los servicios ofrecidos por Glance.
+	\item \textbf{Database Abstraction Layer}: es una API interna encargada de comunicar el servicio glance con la base de datos.
+	\item \textbf{Glance Domain Controller}: se trata de un middleware que implementa las principales funcionalidades (autorización, notificaciones, políticas, conexiones a la base de datos).
+	\item \textbf{Glance Store}: formado por un conjunto de drivers que permiten comunicar Glance con los diferentes backends de almacenamiento posibles.
+\end{itemize}
+
+\begin{figure}[H]
+	\centering
+		\includegraphics[width=0.8\columnwidth]{glance}
+	\caption{Componentes del módulo Glance}
+	\label{glance}
+\end{figure}
+
+Las imágenes son un concepto fundamental en Openstack debido a que son necesarias para crear instancias. Una instancia es una determinada máquina virtual que corre físicamente en un nodo de cómputo específico, siendo creada a partir de una imagen. Además de la imagen es necesario seleccionar un sabor (flavor) que determina las especificaciones de los recursos virtuales asignados a la VM, como pueden ser cantidad de CPUs, MB de memoria RAM y espacio en disco. 
+
+\subparagraph{Creación de una VM}
+Cuando se lanza una VM, en general y a grandes rasgos se llevan a cabo los siguientes pasos:
+\begin{enumerate}
+	\item Se selecciona una imagen administrada por Glance y un flavor que indica tanto los recursos de cómputo necesarios a ser instanciados por Nova como de almacenamiento gestionados por Cinder.
+	\item El nodo de cómputo copia la imagen de base copiada desde Glance hacia el disco principal de la VM conectándose en forma remota con el servicio de Cinder.
+	\item El nodo de cómputo provee los recursos virtuales como vCPUs y memoria. 
+	\item La instancia levanta y comienza a ejecutar. Cualquier modificación almacenada en el disco de la instancia no altera la imagen de base original que seguirá estando disponible para lanzar nuevas instancias.
+\end{enumerate}
+
+\begin{figure}[H]
+	\centering
+		\includegraphics[width=0.8\columnwidth]{glance2}
+	\caption{}
+	\label{glance2}
+\end{figure}
+
+Cuando la instancia deja de existir, se liberan todos los recursos con excepción del almacenamiento persistente en Cinder.\\
+
+Cada imagen tiene asociada su metadata, que incluye conjunto mínimo de propiedades [37]:
+
+\begin{itemize}
+	\item \textbf{arquitecture}: indica la arquitectura de CPU que debe ser soportada por el hipervisor.
+	\item \textbf{instance_uuid}: en caso de tratarse de una snapshot de una instancia, es utilizada para determinar con cual de ellas se encuentra asociada.
+	\item \textbf{kernel_id}: el identificador de la imagen que puede ser utilizada como kernel cuando se inicia una imagen AMI (Amazon Machine Image).
+	\item \textbf{ramdisk_id}: el identificador de la imagen que puede ser utilizada como ramdisk cuando se inicia una imagen AMI.
+	\item \textbf{os_distro}: el nombre común de la distribución del sistema operativo (en minúsculas).
+	\item \textbf{os_version}: la versión del sistema operativo, especificada por el distribuidor.
+\end{itemize}
+
+La lista completa de propiedades se encuentra en [38]. Una de las características principales a especificar es el formato de disco o contenedor. El formato de disco de imagen de VM no es más que el formato de la imagen de disco subyacente, este puede ser alguno de los siguientes: raw, vhd, vhdx, vmdk, vdi, iso, ploop, qcow2, aki, ari, ami. Por su parte, el formato de contenedor refiere a aquellos formatos de imágenes que incluyen metadata en sí mismos, pueden ser: bare, ovf, aki, ari, ami, ova, docker. 
+
+\subsection{Cinder}
+El servicio de almacenamiento de bloques proporciona administración de almacenamiento de bloques persistente para discos duros virtuales. Las operaciones básicas que permite realizar son:
+
+\begin{itemize}
+	\item Crear, listar y eliminar volúmenes.
+	\item Crear. listar y eliminar snapshots.
+	\item Atachear y desatachear volúmenes a máquinas virtuales.
+\end{itemize}
+
+Los volúmenes son utilizados como una solución para persistir los datos de una instancia incluso luego de destruir la misma. Los volúmenes pueden ser asignados a una instancia a la vez.\\
+
+A continuación se muestra la arquitectura de alto nivel de los componentes de Cinder y cómo interactúan:
+
+\begin{figure}[H]
+	\centering
+		\includegraphics[width=0.8\columnwidth]{cinder}
+	\caption{Principales componentes de Cinder}
+	\label{cinder}
+\end{figure}
+
+El servicio \textbf{cinder-volume} administra la interacción con los dispositivos de almacenamiento de bloque. Al recibir una nueva solicitud del scheduler, el servicio crea, modifica o elimina volúmenes a demanda.\\
+Este servicio incluye en su repositorio un conjunto de drivers para soportar diversos dispositivos de almacenamiento para proveer volúmenes. La instalación por defecto utiliza volúmenes locales administrados por Logical Volume Manager (LVM). Además los drivers pueden soportar diversos protocolos de transporte, en el caso de LVM son iSCSI y iSER [31]. En [32] muestran un listado de los drivers disponibles.\\
+
+El servicio \textbf{cinder-api} recibe y responde las solicitudes del módulo. Este servicio al recibir un nuevo mensaje se encarga en primer lugar de verificar que se cumplan los requerimientos de identidad (tokens), luego en base al mensaje construye uno nuevo indicando las acciones a realizar sobre los volúmenes. El mensaje se envía al broker de mensajes para ser procesado por otros servicios del bloque de almacenamiento.\\
+
+El servicio \textbf{cinder-backup} permite crear backups de los volúmenes a repositorios de almacenamiento externos al proyecto, como por ejemplo realizar los respaldos en Swift.\\
+
+El servicio \textbf{cinder-scheduler} planifica y realiza el ruteo de las solicitudes a los servicios cinder-volume apropiados bajo un criterio definido. Dicho criterio puede ser sencillo como realizar un round robin entre los distintos servicios de volúmenes o ser más sofisticado utilizando filtros de planificación. Estos filtros pueden ser fijados sobre la capacidad, el tipo de volumen, las capacidades funcionales, entre otros.\\
+
+\subsection{Swift}
+Se trata del componente de almacenamiento de objetos de Openstack, implementado mediante un sistema distribuido de alta disponibilidad y accesible a través de una API REST. Gestiona el almacenamiento a largo plazo de grandes cantidades de información utilizando redundancia de datos en clusters bajo una arquitectura que evita tener un único punto de control, permitiendo escalar fácilmente.\\
+
+Swift maneja una jerarquía en tres niveles para organizar el almacenamiento de objetos [41]:
+
+\begin{itemize}
+	\item \textbf{Account}: la cuenta es el nivel mas alto en la jerarquía, creando un namespace en el cual residen las instancias del siguiente nivel. A nivel de Openstack una cuenta está dada por un proyecto o usuario tenant.
+	\item \textbf{Container}: no es mas que un contenedor de objetos, pero permite gestionar un control de acceso a estos mediante ACLs (no es posible tener ACLs directamente sobre objetos). Como contenedor, define un namespace para los objetos que almacena. 
+	\item \textbf{Objeto}: es el contenido a almacenar propiamente dicho, como documentos o imágenes, incluyendo la metadata asociada a estos. Todos los objetos tienen una URL que los identifica para poder ser accedidos. 
+\end{itemize}
+
+La siguiente imagen ilustra la arquitectura del servicio Swift, en la cual se pueden identificar componentes clave que serán definidos a continuación.
+
+\begin{figure}[H]
+	\centering
+		\includegraphics[width=0.8\columnwidth]{swift}
+	\caption{Arquitectura del módulo Swift}
+	\label{swift}
+\end{figure}
+
+\subparagraph{Principales componentes}
+\begin{itemize}
+	\item \textbf{Proxy servers}: se encargan de comunicar los diferentes componentes del servicio Swift y brindan un acceso público a los usuarios, manejando todos los pedidos que llegan a la API. Para cada uno de los pedidos, busca la ubicación del elemento (cuenta, contenedor u objeto) dentro del anillo para luego acceder al nodo de almacenamiento adecuado.
+	\item \textbf{Rings}: un anillo simboliza el mapeo entre los nombres de los elementos almacenados en el cluster y sus ubicaciones físicas, existiendo anillos separados para cada uno de los tipos de elementos. Cuando el sistema debe realizar una operación sobre un elemento debe interactuar con el anillo correspondiente para poder accederlo. A su vez, los anillos gestionan:
+	\begin{itemize} 
+		\item zonas: para generar aislamiento de información.
+		\item dispositivos: determina qué dispositivos se encuentra en uso y cuáles utilizar en caso de falla.
+		\item particiones: distribuidas en forma balanceada en todos los dispositivos.
+		\item réplicas: cada partición es replicada al menos 3 veces, para no tener un único punto de falla.
+	\end{itemize}
+	\item \textbf{Zones}: las zonas son utilizadas para aislar la información almacenada y evitar una pérdida total en caso de fallas. Cada réplica de las mencionadas, intenta ser almacenada en una zona diferente. Cada zona puede ser representada desde un solo disco físico separado, hasta racks servidores completos.
+	\item \textbf{Accounts and containers}: anteriormente se definieron en forma conceptual, pero como componentes cada cuenta o contenedor es implementado mediante una base de datos SQLite distribuida a lo largo del cluster.
+	\item \textbf{Partitions}: cada partición puede estar compuesta por un conjunto de bases de datos de cuentas, bases de datos contenedores y objetos propiamente dichos. Se trata de un agrupamiento de elementos para poder ser trasladados dentro del cluster, facilitando operaciones de replicación.
+\end{itemize}
+
+
 %Estos valores servirán de referencia para tomar las decisiones a la hora de bajar y subir de estado. Los estados consisten en los pares (power, rate) asociados a la transmisión entre las terminales y son ordenados de forma que un mayor estado implica menor power y mayor rate. El pseudocódigo asociado al orden entre estados puede verse en el algoritmo \ref{alg1}.
 %
 %\begin{algorithm}[H]