Arquitecturas de Sistemas Operativos

Transcripción

1 1 Arquitecturas de Sistemas Operativos Diseño de Sistemas Operativos (cc) José Antonio Gómez Curso

2 Objetivo Conocer las estructuras/arquitectura de SOS actuales desde el punto de vista de la adaptabilidad funcional de los mismos a nuevos servicios y hardware.

3 Índice Arquitectura monolítica: configuración del kernel configuración en el arranque configuración en tiempo de ejecución módulos de carga Máquinas virtuales: Soporte del kernel a la virtualización: namespaces, cgroups, containers. Soporte a máquinas virtuales: Xen, KVM.

4 Introducción Necesitamos estructuras (arquitecturas) que permitan dar soporte a nuevos tipos de aplicaciones y a nuevos dispositivos sistemas extensibles/adaptables. Necesitamos construir sistemas seguros, correctos, y robustos. La arquitectura puede determinar propiedades no funcionales, por ejemplo, QoS. 4

5 Arquitecturas en uso En la actualidad, las estructuras más usadas: Monolítica Linux,... Microkernel MacOS, Windows, QNX,... Máquinas virtuales Xen, VMWare, SO de internet PalmOS(WebOS) 5

6 Arquitectura Monolítica Características: Toda la funcionalidad en modo kernel. Ventaja: eficiencia Problema: no confinamiento de errores en modo kernel Adaptabilidad: De forma estática: Configuración y arranque del kernel Modificar o añadir código De forma dinámica: On-the-fly LKM (Linux Kernel Modules) 6

7 Arq. Monolítica: configuración Razones para configurar un kernel: Añadir nuevo hardware Optimizar según entorno: servidor, desktop,.., SMP, Añadir nueva funcionalidad o un manejador no oficial. Fijar errores de la versión actual. Lista opciones de configuración: [Kroadh-Hartman2006] make [config menuconfig xconfig gconfig] 7

8 Arq. Monolitica: arranque Podemos pasar parámetro al kernel en el arranque, a través de GRUB o LILO. Por ejemplo: nousb elevator=[cfq deadline noop] Todas las opciones en: Doc/Documentation/kernel-parameters.txt Libro [Kroadh-Hartman2006] 8

9 Compilación del kernel (2.6) Configurado el kernel, debemos compilarlo: Situados en /usr/src/linux, ejecutamos: % make Optimizaciones: Compilar una porción del kernel: % make [M=]drivers/usb/serial Realizar una compilación cruzada: % make ARCH=arm CROSS_COMPILER=/usr/local/bin/... Acelerar la compilación con ccache ( o distcc ( % make CC= ccache distcc Compilación mutihebra: % make -jn (donde n = 2 * número_de_procesadores). 9

10 Instalación del kernel (2.6) Instalamos los módulos: % make modules_install Instalamos la imagen del kernel: % make install verifica la correcta construcción del kernel Instala el kernel en /boot Se genera cualquier imagen ramdisk inicial (se debe generar un disco ram después de hacer make modules_install: # mkinitramfs -o /boot/initrd.img /lib/modules/ Se notificar al programa cargador de la existencia de una nueva imagen y se actualiza. Algunas distribuciones automatizan los pasos de la compilación: installkernel (paquete mkinitrd). make-kpkg en Ubuntu. 10

11 Parcheado del kernel Permite modificar funcionalidad, corregir errores o actualizar el kernel. Un parche es un archivo que contiene los elementos a cambiar respecto de un archivo original existente en la distribución. El proceso de pasar un parche se puede automatizar con la herramienta ketchup. Lo generamos con diff: diff -Naur dir_archivo_original archivo_nuevo > parche.patch 11

12 Parchear: pasos 1. Bajar los fuentes del kernel, el parche en /usr/src, y descomprimir. 2. Parchear el kernel: bzcat../patch ac1.bz2 patch -p1 3. Copiar el.config anterior al directorio actual. 4. Verificar opciones nuevas y hacer consistente con las actuales: make oldconfig 5. Configurar o modificar más opciones si lo deseamos: make menuconfig 6. Compilar como lo hacemos habitualmente. 9. Instalar como lo hacemos habitualmente. 12

13 Modificar el kernel La complejidad medida como LOC es exponencial. Ngc891, Evolution of the Linux kernel source code tarball size, en línea (6/3/2012) en 13

14 Modificar/añadir código La complejidad de modificar / añadir código es muy elevada debido a las dependencias entre componentes o 14

15 Modificaciones on-the-fly El seudo-sistema de archivos /proc nos permite configurar al vuelo ciertos parámetros del sistema. % echo mihost >/proc/sys/kernel/hostname Podemos hacer los cambios permanentes con sysctl: % sysctl w kernel.hostname=mihost Ajuste de servicios a través de órdenes (start/stop/restart/reload/status): % /etc/init.d/xinetd reload 15

16 Linux Kernel Modules Un LKM es un objeto ELF (Executable and Linkable Format) que resuelve sus símbolos cuando se carga en el kernel. Aligera el núcleo vs. Sobrecarga No es un proceso. Puede estar en un de los siguientes estados: MODULE_STATE_COMING, MODULE_STATE_LIVE, y MODULE_STATE_GOING. Órdenes relacionadas: insmod, rmmod, modprobe y lsmod. 16

17 LKM Kernel limpio Figura extraída de [CorbetRubiniKroah-Hartmanen05] 17

18 Estructura de un LKM (2.6) #include <linux/module.h> #include <linux/init.h> Includes MODULE_LICENSE( GPL ) MODULE_AUTHOR( Autor del módulo ) MODULE_DESCRIPTION( Descripción del módulo) Macros del módulo static int init funcion_entrada(void) {... return 0; } Constructor del módulo static void exit funcion_salida (void) { return; } module_init (funcion_entrada); module_exit(funcion_salida); Destructor del módulo Macros de entrada/salida 18

19 Construcción de un módulo En 2.6, la construcción es más simple gracias al sistema de construcción kbuild. Lo primero que tenemos que decidir en donde vivirá el módulo: Junto con las fuentes del kernel: ya sea como parche o mezclando el código con el árbol oficial. Fuera del árbol de fuentes. 19

20 Construcción: árbol de fuentes Si el módulo es parte una parte oficia del kernel vive en el árbol de fuentes. Por ejemplo, un manejador de un dispositivo de caracteres estará en drivers/char. Las reglas para ubicarlo no son muy estrictas, por lo que podemos crear nuestro propio directorio si es necesario. 20

21 Construcción: externo Crear un Makefile en el directorio que contiene el archivo fuente y añadir la línea: obj-m := mi_modulo.o La diferencia esta en la construcción. Debemos indicar donde estan los fuentes: make -C /kernel/source/location SUBDIRS=$PWD modules 21

22 Instalación y dependencias Los módulos instalados se sitúan en /lib/modules/version/kernel/ Esto es lo que hace make modules_install Podemos construir la información de dependencias entre módulos con depmod. Las dependencias se almacenan en /lib/modules/version/modules.dep que es usado por depmod. Por ejemplo: % cat modules.dep grep vfat kernel/fs/fat/vfat.ko: kernel/fs/fat/fat.ko 22

23 Carga de módulos Cargamos un módulo con: insmod : no controla dependencias, ni errores. modprobe: suministra resolución de dependencias, control errores e informes. Descarga de módulos: rmmod modprobe -r Las llamadas al sistema usadas son: init_module() y delete_module(). 23

24 Información Podemos obtener información de un modulo con /sbin/modinfo. % /sbin/modinfo vfat filename: /lib/modules/ desktop/kernel/fs/fat/vfat.ko author: Gordon Chaffee description: VFAT filesystem support license: GPL srcversion: 70D D7A33E0C3A depends: fat vermagic: desktop SMP preempt mod_unload modversions 686 La información se almacena en la sección.modinfo del ELF. 24

25 Qué es un módulo? Un módulo es un archivo objeto reubicable: % file vfat.ko vfat.ko: ELF 32-bit LSB relocatable,, not stripped Funciones externas del módulo: % nm vfat.ko T init_module t init_vfat_fs U iput U jiffies U kfree 25

26 qué es.. (ii)? Los símbolos marcados indefinidos (U) son símbolos del kernel o de otros módulos. % cat /proc/kallsyms grep jiffies c0946a40 D jiffies La D indica que es símbolo definido en el segmento de datos. Una T, indicaría en el de texto, ver espeficación de ELF. Esta información es la que usa depmod. Todos los símbolos que exporta el kernel están en System.map o en /proc/kallsyms. 26

27 Kernels contaminados El kernel mantiene un estado de contaminación (taint state) que es un indicador de que ha ocurrido algo que puede producir un error o cuelgue del kernel. Este estado solo se abandona reiniciando el kernel. La bandera de contaminación también indica las razones de contaminación: P: A module with a Proprietary license has been loaded, i.e. a module that is not licensed under the GNU General Public License (GPL) or a compatible license. This may indicate that source code for this module is not available to the Linux kernel developers or to Novell's developers. G: The opposite of 'P': the kernel has been tainted (for a reason indicated by a different flag), but all modules loaded into it were licensed under the GPL or a license compatible with the GPL. F: A module was loaded using the Force option "-f" of insmod or modprobe, which caused a sanity check of the versioning information from the module (if present) to be skipped. R: A module which was in use or was not designed to be removed has been forcefully Removed from the running kernelusing the force option "-f" of rmmod. S: The Linux kernel is running with Symmetric MultiProcessor support (SMP), but the CPUs in the system are not designed or certified for SMP use. M: A Machine Check Exception (MCE) has been raised while the kernel was running. MCEs are triggered by the hardware to indicate a hardware related problem, for example the CPU's temperature exceeding a treshold or a memory bank signaling an uncorrectable error. B: A process has been found in a Bad page state, indicating a corruption of the virtual memory subsystem, possibly caused by malfunctioning RAM or cache memory. 27

28 Kernels contaminados (ii) Cómo evitar la corrupción según tipo: "P", utilizar manejadores/modulos suministrados por el distribuidor. No siempre es posible ya que algunos componentes hardware solo son soportados por manejadores propietarios. "F" o "R", no utilizar la opción -f al (des)cargar el módulo. Si es necesario, obtener el módulo para versión específica del kernel. "S", no utilizar kernels SMP en sistemas con CPUs que no han sido certificadas o diseñadas para uso SMP. "M" o "B", asegurarse de que el hardware opera dentro de los parámetros establecidos de suministro de potencia, temperatura, humedad, y flujo de aire. "U" o "N", marcar YES en configuración certificada. 28

29 Kernel contaminados (y) Podemos ver el estado de contaminación de un kernel en /proc/sys/kernel/tainted. Un valor no-cero indica que el kernel esta contaminado (los valores puede estar OR'ados). En /usr/src/linux/documentation/sysctl/kernel.txt: 1 - A module with a non-gpl license has been loaded, this includes modules with no license. Set by modutils >= and module-init-tools. 2 - A module was force loaded by insmod -f. Set by modutils >= and module-init-tools. 4 - Unsafe SMP processors: SMP with CPUs not designed for SMP. 8 - A module was forcibly unloaded from the system by rmmod -f A hardware machine check error occurred on the system A bad page was discovered on the system The user has asked that the system be marked "tainted". This could be because they are running software that directly modifies the hardware, or for other reasons The system has died The ACPI DSDT has been overridden with one supplied by the user instead of using the one provided by the hardware A kernel warning has occurred A module from drivers/staging was loaded. 29

30 Limitaciones LKM No podemos modificar funcionalidad compilada estáticamente. Podemos preparar ganchos Dificultad de confinar un error dentro del módulo. Intentos de solventarlo: Módulos binarios no puede acceder a funciones explícitamente disponibles sobre licencia GPL. Su carga produce un kernel contaminado (tainted). Modularización del código fuente. 30

31 Más detalles.. W. Mauerer, Professional Linux Kernel Architecture, Wiley Publishing, Capitulo 7. D. Bovet y M. Cesati, Understanding the Linux kernel (3/e), O'Reilly, 2006, Apéndice B. 31

32 Virtualización Virtualización es una tecnología que combina o divide recursos de computación para presentar uno o varios entornos de operación utilizando metodologías como particionamiento o agregación ya sea hardware o software, simulación de máquinas completa o parcial, emulación, tiempo compartido, y otras [Susanta Nanda y Tzi-cker Chiueh, A Survey on Virtualization Technologies, RPE Report, SUNY at Stony Brook, New York. Feb ] 32

33 Virtualización Razones para virtualizar: Aislamiento de recursos Compartir recursos hardware o consolidar servidores* Desarrollo de software o SO para hardware no existente Dos enfoques: Sistemas virtualizados donde una máquina soporta varios kernels Un único kernel opera sobre una entorno virtual que abstrae los recursos globales en espacios de nombres aislados*. 33

34 Virtualización: taxonomía VM divididas en: Process virtual Machine System Virtual Machine: Emulación: ISA1 ISA2 Virtualización: Hipervisor nativo (bare-metal) o Tipo 1 Hipervisor con anfitrión o Tipo 2 API ABI ISA Aplicaciones Bibliotecas Sistema Operativo Hardware 34

35 Tipos hipervisores Según la implementación podemos separarlos: Traducción binaria dinámica del código binario crítico del invitado (no de las aplicaciones). Paravirtualización - idem pero del código fuente. Virtualización asistida por hardware (Intel VT-x o AMD SVM) trata de resolver problemas del hardware relativos a virtualización (trampas). 35

36 Virtualización total La VM simula suficiente hardware para permitir que un SO invitado sin modificar se ejecute de forma aislada. Por ejemplo, QEMU Pros: SO's anfitrión e invitado sin modificar. Cons: Peor rendimiento debido a la capa de emulación. 36

37 Paravirtualización La VM no simula necesariamente el hardware si no que en su lugar ofrece una API especial para el SO invitado modificado. Por ejemplo, Xen. Pros: Buen rendimiento. Cons: SOs anfitrión e invitados modificados (en cada versión del kernel). 37

38 Xen vs KVM: I/O path Brendan's blog, Virtualization Performance: Zones, KVM, Xen (12/3/2013) disponible en 38

39 Xen vs KVM D. Schirmer, P. Towalski, O. Kopitetzk, First experiencewith the introduction of virtualization techniques into the delta control system, Proceedings of ICALEPCS 2009, Kobe, Japan. 39

40 KVM, Xen y Linux 3.0+ Chucknology, KVM is Linux. Xen is Not., (2/2/2012) disponible en 40

41 Xen vs KVM Comparativa en Pros y contras:

42 Intel VT-x Johan De Geleas, Hardwar virtualizaion: the nuts and Bolts, AnandTech, 2008, disponible en 42

43 Rendimiento a [1] [2] [1] VMWare, Ten Reasons Why Oracle Databases Run Best on Vmware, 12/3/13 en [2] Microsoft, Get VIRTUAL Now - Virtualization and 'Green IT', 12/3/13 En 43

44 Rendimiento (y ii) DataBase Benchmark CPU intensiva Web server benchmark Memoria Intensiva L (Linux) X (Xen) V (VMWare Workstation) U (User Mode Linux) P. Barham et al., Xen and the Art of Virtualization, Proceedings of the nineteenth ACM symposium on Operating systems principles (SOSP), Volume 37, Issue 5, pages ,

45 Ejemplos de MV Nivel ISA: Boch, QEMU, Nivel HAL: VMWare, Xen, UML, KVM Nivel SO: Jail, Containers, Nivel de lenguaje de programación: JVM, Microsoft.NET CLI Nivel de biblioteca: Wine,... 45

46 Virtualización en Linux Soporta a máquinas virtuales: Xen KVM UML, y otros Virtualización ligera Namespaces (espacios de nombres) Cgroups (control groups) Container (contenedor) 46

47 Namespaces Namespaces es una forma ligera de virtualización que permite que veamos propiedades globales de un sistema bajo diferentes aspectos (un namespace es esencialmente una vista del sistema). SOs que soportan este tipo de virtualización: Namespaces Linux Zones Solaris Jail FreeBSD 47

48 Namespaces: objetivos de diseño Transparencia y compatibilidad las aplicaciones debe ejecutarse en namespace como lo hacen en el host. Rendimiento no afecta significativamente. Usabilidad y administración la herramientas existentes deben seguir funcionando. Aceptar de Linux main-stream desarrollo homogéneo del kernel (no kernel personalizado). 48

49 Namespaces: lista La lista de namespaces actualmente incluidos: UTS (Unix Timesharing System) (lwn) información del sistema (nombre, versión, tipo arquitectura, etc.) System V IPC (lwn) mecanismos de comunicación entre procesos. mounts - sistemas de archivos montados: shared subtrees (lwn) y r/o bind mount (lwn). pid (lwn) espacio de nombres de identificadores de procesos. network (lwn) conjunto de dispositivos de red. userid (lwn) permite limitar los recursos por usuario. 49

50 Namespaces: creación Podemos establecer un nuevo namespace con: Al crear un proceso con clone y los indicadores: CLONE_NEWIPC, CLONE_NEWNET, CLONE_NEWNS, CLONE_NEWPID, CLONE_NEWUTS La llamada al sistema unshare() disocia parte de los namespaces compartidos con el padre. 50

51 Namespaces: implementación Para ahorrar espacio y mejorar la eficiencia, necesitamos dos componentes: Una estructura namespace por subsistema que envuelve los componentes que anteriormente eran globales en base a un namespace (struct uts_namespace, ipc_namespace, mnt_namespace, pid_namespace, user_namespace, net_ns. Un mecanismo que asocia un proceso con su namespace (struct nsproxy). Conexión entre procesos y namespaces [Mauerer2008] 51

52 PID Namespace: relación Los namespaces pueden o no estar jerárquicamente relacionados. Podemos observar como un proceso tiene varios PIDs dependiendo del contexto en el que se observa. Jerarquía de namespaces [Mauerer2008] 52

53 Usos de los namespaces Posibles usos: Servidores Privados Virtuales (VPS) como por ejemplo Linux Containers (lxc.sourceforge.net) Application checkpoint and restart (ACS) En clusters: Sustitución de NFS Re-construcción de /proc 53

54 Pid namespace:requisitos Requisitos: Los pids en un namespace son independientes de los pids de otros namespace. El administrador debe visualizar y señalar todos los procesos. Las utilidades existentes debe poder seguir monitorizando y controlando el sistema completo: ps, top, kill, etc. 54

55 pid namespace: ED La gestión de identificadores maneja dos estructuras: pid la representación interna del kernel de un PID (ID global). struct pid { atomic_t count; /* contador de referencias */ /* lista de tareas que usan este pid */ struct hlist_head tasks[pidtype_max]; int level; /*en cuantos namespaces es visible el ID*/ struct upid numbers[1]; /*nº instancias upid por nivel*/ } upid información visible en un namespace específico (ID local). struct upid { int nr; /* valor numérico de un ID */ struct pid_namespace ns; /*namespace al que pertenece*/ struct hlist_node pid_chain; /*lista hash desbordamiento*/ } Donde struct pid_namespace {. struct task_struct child_reaper; /* proceso init local*/ int level; /* profundidad de la jerarquía namespace */ struct pid_namespace parent; /* namespace padre */ }; 55

56 PID ns: Estructuras de datos 56

57 Ejemplo: árbol de procesos con procesos en 3 pid-namespaces 57

58 Virtualización: bibliografía Susanta Nanda y Tzi-cker Chiueh, A Survey on Virtualization Technologies, RPE Report, SUNY at Stony Brook, New York. Feb J.E. Smith y R. Nair, Virtual Machines: Versatile Platforms for Systems and Processes, The Morgan Kaufmann Series in Computer Architecture and Design, San Francisco, USA, Morgan Kaufmann Inc., 2005.Disponible en Wikipedia, Comparison of platform virtual machines, consultado el 13/3/2012, disponible es 58

59 Cuestiones... 59