@netman | 22:06 <@alejandro> La siguiente conferencia está a punto de empezar |
@netman | 22:07 <@alejandro> Evaldo Gardenali va a hablarnos sobre la virtualización Xen. |
@netman | Paulista (unesp) en Bauru-SP, Brasil |
@netman | 22:07 <@alejandro> Evaldo estudia en la Universidad Estadual Paulista (unesp) en Bauru-SP, Brasil |
@netman | 22:08 <@alejandro> y ha contribuido a varios proyectos como NetBSD, CAcert y freenode |
@netman | 22:08 <@alejandro> Las preguntas como es habitual se harán en #qc y la traducción al español en #redes |
@netman | 22:08 <@alejandro> Bienvenido Evaldo. |
@netman | 22:09 <@alejandro> :-) |
@netman | 22:09 <@E0x> uff |
@netman | 22:14 <@alejandro> Por favor, sean pacientes, hay problemas técnicos. |
@netman | 22:16 <@alejandro> Bienvenido de nuevo Evaldo, es tu turno. |
@netman | 22:21 <@Evaldo> Ante todo, necesitamos considerar la razón para virtualizar, tanto en entornos heterogéneos como en un único servidor. |
@netman | 22:21 <@Evaldo> ahhh |
@netman | 22:21 <@sarnold> Evaldo: Lo lamento, no tenías voz y el canal está moderado. |
@netman | (No ha salido nada de lo que escribió en los últimos 5 minutos) |
@netman | 22:22 <@Evaldo> (1134595089 19:18) < Evaldo> Voy a hablar sobre Xen, un motor de paravirtualización |
@netman | 22:22 <@Evaldo> (1134595114 19:18) < Evaldo> por favor, bajaos la presentación que está en http://evaldo.gardenali.biz/umeet/xen.pdf |
@netman | 22:22 <@Evaldo> (1134595153 19:19) < Evaldo> Bien, voy a hablar sobre virtualización, primero le echaremos un vistazo |
@netman | 22:22 <@Evaldo> (1134595173 19:19) < Evaldo> después procederemos con las características específicas de Xen |
@netman | 22:22 <@Evaldo> (1134595184 19:19) < Evaldo> Escalabilidad, y consideraciones de rendimiento |
@netman | 22:22 <@Evaldo> (1134595229 19:20) < Evaldo> luego presentaremos la gestión de Calidad de Servicio, mostrando una implementación "desde cero" de Xen, y debatiremos un poco sobre el futuro de Xen |
@netman | 22:23 <@Evaldo> actualmente los sistemas operativos compatibles son Linux 2.4 y 2.6, NetBSD 3.0 y Plan9 |
@netman | 22:22 <@Evaldo> (1134595272 19:21) <@Evaldo> Primero, |
@netman | necesitamos considerar la justificación de virtualizar, así |
@netman | como el soporte de entornos heterogéneos sobre un único |
@netman | servidor |
@netman | 22:23 <@Evaldo> actualmente los sistemas operativos |
@netman | compatibles son Linux 2.4 y 2.6, NetBSD 3.0 y Plan9 |
@netman | 22:24 <@Evaldo> Xen también se puede usar para consolidar trabgajo. Investigaciones recientes muestran que los servidores usan un 15% de su capacidad de media, y Xen pued ayudar a consolidar servidores inactivos sobre un mismo servidor físico |
@netman | 22:24 <@Evaldo> Los sistemas heredados que requieren bibliotecas obsoletas son también un punto a considerar. |
@netman | 22:25 <@Evaldo> También se puede usar para hacer una actualización gradual de los servicios ofrecidos. |
@netman | 22:25 <@Evaldo> Usando varios dominios dedicados, uno puede tener un buena forma de independizar servicios |
@netman | 22:26 <@Evaldo> La Calidad de Servicio se puede garantizar en base a una máquina virtual, dándonos un control más eficiente que la planificación de los sistemas operativos tradicionales. |
@netman | 22:27 <@Evaldo> la facilidad de la administración de servidores individualizados y la relocalización son unas características que hacen la migración muy flexible y nos permite ahorrar tiempo |
@netman | 22:27 <@Evaldo> Analizando las técnicas de virtualización disponibles tenemos: |
@netman | 22:28 <@Evaldo> Imágenes de Sistemas Simples, como las proporcionadas por Ensim, Virtuozzo, Solaris Zones |
@netman | 22:29 <@Evaldo> Estos sistemas agrupan procesos y recursos en contenedores especializados, pero dado que el kernel es un punto común un defecto del kernel puede comprometer todas las máquinas virtuales a la vez |
@netman | 22:30 <@Evaldo> Las técnicas de emulación son muy flexibles y permiten ejecutar la mayoría de los sistemas operativos, pero emular es una tarea ineficiente, que conduce a un rendimiento pobre |
@netman | 22:31 <@Evaldo> La virtualización, como hace VMWare es también muy flexible, permitiendo el uso de sistemas operativos sin ninguna modificación, pero las técnicas actuales de virtualización se llevan el 35% del tiempo CPU para implementar el motor de virtualización |
@netman | 22:32 <@Evaldo> Los kernels en Modo Usuario, como el User Mode Linux y CoLinux tienen la desventaja de ejecutar procesos normales bajo el sistema operativo anfitrión, lo que nos lleva de nuevo a una pobre planificación y a probelmas de cambio de contexto. |
@netman | 22:32 <@Evaldo> Finalmente, la Paravirtualización nos ofrece un excelente rendimiento, con la con la condición de que el sistema operativo invitado sea portado a una arquitectura especial |
@netman | 22:33 <@Evaldo> Así, la principal desventaja del uso de Xen para la administración de sistema y el aislamiento de servicios, minimiza los daños. Fallos de aislamiento, en el caso de un hardware defectuoso o drivers con errores, facilita la administración y la aplicación de políticas de calidad de servicio para Centros Servidores de Datos y Proveedores de Hosting, ofreciendo "Servidores Privados Virtuales" y ofrecer hosts Xen puede el |
@netman | 22:36 <@Evaldo> Y los beneficios reales de la virtualización son los costes, de por ejemplo, la compra y el alquiler de los equipos que se utilizan sólo de vez en cuando (por lo que se desperdician), espacio en el rack, costes de colocación, energía y coste de aire acondicionado, y el coste del tiempo de caída, en el caso de usemos hardware defectuoso con datos que no se puedan relocalizar |
@netman | 22:36 <@Evaldo> La transparencia nos muestra un esquema general de la arquitecutra de Xen 2.0, mostrando que el hypervisor Xen corre en una capa privilegiada, delante de los demás sistemas operativos |
@netman | 22:37 <@Evaldo y todos los sistemas operativos corren directamente encima de Xen |
@netman | 22:37 <@Evaldo> En las técnicas de paravirtualización, se saca partido de estructuras que no se usan en la arquitectura del x86 |
@netman | 22:38 <@Evaldo> El x86 tiene 4 modos de protección/operación, llamados anillos. Los sistemas operativos tracionales se ejecutan sobre el anillo 0, mientras que los programas de aplicación lo hacen sobre el anillo 3. |
@netman | 22:39 <@Evaldo> Cuando los sistemas se portan a la arquitectura Xen, Xen toma el control del anillo 0, el sistema operativo se ejecuta en el anillo 1, y la aplicación corre sin ninguna modificaión en el anillo 3. |
@netman | 22:40 <@Evaldo> Las operaciones privilegiadas se piden al hipervisor Xen en forma de hiperllamdas, un sistema que debería imaginarse como una analogía al espacio de usuario -> llamadas de sistema del kernel |
@netman | 22:40 <@Evaldo> Hacer el port de Linux 2.4 a la arquitectura Xen ha llevado menos de 3000 líneas de código, mientras que el del 2.6 no ha necesitado ningúna modificación |
@netman | 22:41 <@riel> Una pregunta: - Si no se ha necesitado ninguna modificación en el código, ¿por qué el parche de Xen para el kernel 2.6 modifica alrededor de una docena de ficheros? |
@netman | 22:42 <@Evaldo> riel: Modifica ficheros dependientes de la arquitectura en concreto, mientras que mantiene la parte independiente de la arquitectura intacta. |
@netman | 22:42 <@Evaldo> 2.6 está modelado de forma que cualquier código dependiente de la arquitectura está separado en ficheros especiales. |
@netman | 22:43 <@Evaldo> Además, ten en cuenta que estoy hablando de Xen 2.0. Xen 3.0 es una versión reciente, y es mi siguiente punto. Aún no he examinado qué cambios del 3.0 efectúa sobre el kernel de Linux. |
@netman | 22:43 <@riel> buen punto. Yo sólo he le leído el código de la versión 3.0 |
@netman | 22:46 <@Evaldo> Las mejoras de Xen 3.0 sobre la 2.0 incluyen la compatibilidad con AGP y ACPI en el dominio administrativo, invitados con capacidades SMP, compatibilidad con más arquitecturas hardware, Intel VT-X (Vanderpool) y extensiones AMD Pacifica, mejoras de las herramientas de gestión y optimización del código de red |
@netman | 22:47 <@Evaldo> para las extensiones de virtualización, hay la necesidad de un "gestor", que Xen puede hacer según sus desarrolladores. Las extensiones de hardware se crearon para permitir que los gestores de vertiualización pudieran correr sobre sistemas operativos sin modificar, sin reemplazar dichos gestores. |
@netman | 22:48 <@Evaldo> Un buen ejemplo es el motor z/VM del S/390 de IIBM. El z/VM es muy parecido a Xen, mientras que S/390 tiene instrucciones de virtualización sobre el hardware |
@netman | 22:49 <@Evaldo> El acceso a bajo nivel en los sistemas Xen está hecho de una manera bastante transparente; los sistemas operativos activan el modo protegido para usar sus propios controladores para manejar el hardware. |
@netman | 22:50 <@Evaldo> Esto permite cierto grado de tolerancia a fallos, dado que un cuelgue del kernel debido a un driver con fallos no comprometería el hipervisor Xen |
@netman | 22:51 <@Evaldo> Se permite a los dominios invitados acceder a dispositivos virtuales exportados desde los dominios privilegiados. |
@netman | 22:52 <@Evaldo> Estos dispositvos se manejan a través de un sistema eficiente de memoria compartida, evitando replicaciones de datos innecesarias. Actualmente, tanto LiNUX como NetBSD pueden exportar cualquier clase de dispositivos de bloque a dominios no privilegiados |
@netman | 22:53 <@Evaldo> Eventualmente, algunas tarjetas PCI se pueden alojar para accesos dedicados en el dominio invitado, el cual usa su propio PCI y sus propios controladores para acceder a ese dispositivo. |
@netman | 22:53 <@Evaldo> La transparencia 19 tiene un ejemplo de un dominio que maneja una sola tarjeta de sonido en su espacio PCI |
@netman | 22:54 <@Evaldo> Un fallo en el controlador de estas tarjetas no tendrán ninguna influencia en la ejecución de los otros dominios, dado que el hipervisor, cuyo dominio es 0, y los demás dominios no dependen de dispositivos de ese dominio en particular, y no tienen contacto con el dispositivo PCI ni con su controlador defectuoso |
@netman | 22:55 <@Evaldo> < ~Arador> Eso permitiría ejecutar diferentes controladores de dispositivo en diferentes máquinas virtuales, lo cual suena como una idea interesante para kernels monolíticos |
@netman | 22:56 <@Evaldo> con la excepción de que los dispositivos PCO no se han desarrollado pensando en la virtualización, así que sólo un dominio puede acceder a un dispositivo nativo PCI en cada momento |
@netman | 22:56 <@Evaldo> La transparencia 20 muestra los sistemas operativos compatibles en negro, y los que "se supone que funcionan" en rojo. |
@netman | 22:57 <@Evaldo> Se está trabajando en un port para FreeBSD de Xen 2.0, pero todavía no está integrado en el árbol FreeBSD, así que su estabilidad y usabilidad están limitadas. |
@netman | 22:58 <@Evaldo> Sun ha anunciado que lo tienen funcionando en OpenSolaris, pero no han liberado ni los fuentes ni los binarios todavía. |
@netman | 22:58 <@Evaldo> Microsoft fundó el proyecto Xen, y han conseguido que Windows funcione con él, pero Microsoft ha dedidido no liberar los parches, así que no podemos ejecutarlo sobre él. |
@netman | 22:59 <@Evaldo> Sobre las características, Xen tiene gestión de memoria de dominio dinámica |
@netman | 22:59 <@Evaldo> Uno puede usar "xm balloon Domain-5 48" y el dominio 5 se ajustará él mismo a 48 MB de RAM, por ejemplo |
@netman | 23:00 <@Evaldo> Actualmente falta algo de control automático de la gestión de memoria |
@netman | 23:00 <@Evaldo> Hay una funcionalidad de pausa, que permita hacer una pausa temporal de un sistema que se está ejecutando, mientras que la mantiene en la RAM, lista para ejecutarse de nuevo |
@netman | 23:01 <@Evaldo> La funcionalidad de Salvar, en cambio, guarda el estado de la memoria virtual en el disco, liberando recursos, y permite continuar más tarde. |
@netman | 23:01 <@Evaldo> usando el fichero de estado |
@netman | 23:02 <@Evaldo> La migración en vivo es realmente la funcionalidad más brillante de Xen. Permite a uno moverse de un sistema que se está ejecutrando en una máquina a otra máquina diferente, sin perder el estado, conexiones ni uptime. |
@netman | 23:02 <@Evaldo> La transparencia 25 muestra un diagrama del esquema de Migración en Vivo |
@netman | 23:03 <@Evaldo> En la etapa de Pre-Migración, el destino está seleccionado y marcado para la migración pero el sistema todavía está corriendo en el primer servidor |
@netman | 23:04 <@Evaldo> En la etapa de reserva, se reservan recursos en el sistema destino para facilitar la migración |
@netman | 23:05 <@Evaldo> Luego el sistema entra en "pre-copia interactiva", en donde se copian "páginas de memoria sucias" (actualizadas recientemente) en sucesivas vueltas hasta que la cantidad a transferir sea mínima |
@netman | 23:06 <@Evaldo> En la etapa 3 finalmente se suspende la máquina virtual del sistema fuente, restaurándose el estado del sistema en la máquina destino, enviado una solicitud ARP para actualizar los puertos del conmutardor y otros equipos de red, y proceder para la siguiente etapa. |
@netman | 23:06 <@Evaldo> En la etapa de compromiso, el sistema ya esa ejecutándose sobre la segunda máquina, y los recursos de la primera se han liberado |
@netman | 23:07 <@Evaldo> oops, Lo siento, quería decir en la etapa 5 |
@netman | 23:07 <@Evaldo> La etapa 5 recupera y continúa las operaciones de la máquina virtual y finaliza la migración |
@netman | 23:08 <@Evaldo> Las diapositivas 26 y 27 muestran ejemplos de migración, una con un servidor web con bastante carga y otra con un servidor de quake3, para comprobar la latencia |
@netman | 23:09 <@Evaldo> La diapositiva 26 nos muestra la reducción de ancho de banda causada por la etapa de pre-copia interactiva, y luego claramente cuando el servicio se interrumpe. La interrumpción del servicio dura 165 ms. |
@netman | 23:10 <@Evaldo> Para el servidor de quake3, se llevaron a cabo dos migraciones, y los usuarios no notaron ninguna clase de comportamiento anómalo |
@netman | 23:10 <@Evaldo> El pie de página de memoria de las estructuras internas del Xen es muy bajo, alrededor de 20 kb por cada dominio que se ejecuta |
@netman | 23:11 <@Evaldo> La sobrecarga de CPU para la paravirtualización de Xen 2.x es alrededor del 5% |
@netman | 23:13 <@Evaldo> Las diapositivas 29 al 32 nos muestra una comparativa entre servidores *L*inux nativos, *X*en, *V*MWare ESX, *U*ser mode Linux |
@netman | 23:13 <@Evaldo> Las diapositivas 33 y 34 nos muestran comparaciones de rendimiento de red. Este factor se ha mejorado en Xen 3.0 |
@netman | 23:15 <@Evaldo> en la gestión de QoS, hay una gestión de planificaón flexible, que permite personalizar los planificadores |
@netman | 23:15 <@Evaldo> El que más se usa es BVT, que se usa por defecto. |
@netman | 23:16 <@Evaldo> BVT usa "tiempo virtual" para planificar dominios, y usa algunos trucos de "warping" lo cual reduce el tiempo virtual de un dominio cuando se compara tiempos de planificación |
@netman | 23:16 <@Evaldo> Hay material de referencia detallado en la página de bibliografía |
@netman | 23:17 <@Evaldo> En la diapostiva 40 están los pasos requeridos para implementar un sistema Xen desde cero (útil para la gente de Slackware ;) |
@netman | 23:18 <@Evaldo> Xen necesita almacenamiento compartido si uno planea usar migración; así que unas buenas técnicas serían SCSI, NFS o ENBD. En otro caso, se tendría que usar alguna clase de espacio de almacenamiento. |
@netman | 23:19 <@Evaldo> La instalación de Xen necesita modificar los ficheros de configuración de grub, como muestra la diapositiva 42. |
--- Day changed jue dic 15 2005 |
@netman | 23:19 <@Evaldo> Para sistema que no manejan dependencias, hay una lista en la diapositiva 43 |
@netman | 23:20 <@Evaldo> La diapositiva 44 muestra la instalación de las aplicaciones de usuario xend y xm, para controlar el sistema Xen |
@netman | 23:21 <@Evaldo> Las transparencias 45 y 46 nos muestran cómo construir kernels personalizados de dominio-0, para pruebas de rendimiento |
@netman | 23:21 <@Evaldo> La diapositiva 47 nos muestra un ejemplo del f |
@netman | ichero de configuración de dominio. El formato es bastante cla |
@netman | ro, dado que es un fichero incluído de python, se puede automa |
@netman | tizar fácilmente. |
@netman | 3:21 <@Evaldo> La diapositiva 47 nos muestra un ejemplo del fichero de configuración de dominio. El formato es bastante claro, dado que es un fichero incluído de python, se puede automatizar fácilmente. |
@netman | 23:23 <@Evaldo> La diapositiva 48 nos muestra unas pocas técnicas |
@netman | para instalar un dominio invitado: el instalador XenU (como hace NetBSD); herramientas típicas de arranque y para construir jaulas |
@netman | "chroot"; QEMU, que se puede usar para construir una imagen del |
@netman | sistema o tarballs directamente. |
@netman | 23:23 <@Evaldo> La diapositiva 49 nos muestra cómo instalar un |
@netman | dominio BSD, que lleva el instalador de NetBSD sobre la consola de la máquina virtual |
@netman | 23:24 <@Evaldo> Lo siento; olvidé la traducción, "Rede" == network (red) |
@netman | 23:23 <@Evaldo> Las diapositivas 51-52 nos enseñan un ejemplo de implementación de QoS utilizando el planificador BVT, sin hacer warp |
@netman | ing |
@netman | 23:23 <@Evaldo> Las diapositivas 54-55 nos muestras lo fácil que es |
@netman | delegar una tarjeta PCI a un dominio, como ya vimos en el ejemplo de |
@netman | la tarjeta de sonido de esta presentación. |
@netman | 23:26 <@Evaldo> Las diapositivas 56-58 nos muestran cómo usar los |
@netman | dominios finales, los cuales usan dispositivos virtuales exportados por un dominio priviliegiado que no es el dominio 0. |
@netman | 23:26 <@Evaldo> Tan sólo basta con incluir el nombre del dominio en el parámetro. |
@netman | 23:27 <@Evaldo> y finalmente, la hoja de ruta para las siguientes ve |
@netman | rsiones de Xen. |
@netman | 23:27 <@Evaldo> Ballon auto control, la gestión automática del pie de página de memoria de un dominio. |
@netman | 23:28 <@Evaldo> Evacuación de nodo, en caso de problemas. |
@netman | 23:28 <@Evaldo> Implementar un subsistema de almacenamiento que se pueda usar fácilmente en un cluster Xen, sin depender de SCSI, NFS o ENBD, que pueden ser sub-óptimos en algunos casos. |
@netman | 23:29 <@Evaldo> Tolerancia a fallos, y posiblemente almacenar la traza de ejecución de un sistema en dos máquinas diferentes. |
@netman | 23:29 <@Evaldo> Bifurcación de máquina virtual, para conseguir picos de alto rendimiento bajo demanda. |
@netman | 23:30 <@Evaldo> y virtualización segura, implementando métodos seguros de control de acceso y gestión |
@netman | 23:30 <@Evaldo> He puesto en la diapositiva 60 algunas referencias que me parecen interesantes para la gente que experimente con Xen por primera vez. |
@netman | 23:31 <@Evaldo> Siento el retardo inicial debido a problemas de conexión y la invasión de tiempo de mi segunda charla. |
@netman | 23:32 <@Evaldo> Es el turno de preguntas :) |
@netman | 23:32 <@MJesus_> Evaldo hay algunas preguntas en #qc |
@netman | 23:33 <@Evaldo> MJesus_: Las de Arador ya las he contestado. |
@netman | 23:33 <@MJesus_> ah ok.... |
@netman | 23:33 <@MJesus_> ¿Más preguntas? |
@netman | 23:33 <@Evaldo> No he entendido lo de EOx's , quizá si él fuera más específico.... |
@netman | pero parece que lo dejó |
@netman | 23:34 <@MJesus_> ¡De acuerdo! |
@netman | 23:35 < tschwinge> Evaldo: ¡Una presentación muy interesante! ¡Gracias! |
@netman | 23:35 <@MJesus_> ¡oh, gracias riel! |
@netman | 23:35 <@MJesus_> oh, thanks riel ! |
@netman | 23:35 <@Evaldo> tschwinge: Me agrada que te haya gustado :) |
@netman | 23:35 <@MJesus_> Siempre olvido la +m |
@netman | 23:36 < tschwinge> Una pregunta: ¿De qué manera tiene que modificarse un sistema operativo para que pueda correr bajo Xen? |
@netman | 23:36 <@MJesus_> ¿Más cuestiones por favor? |
@netman | 23:36 <@MJesus_> :) Daniel |
@netman | 23:37 <@Evaldo> tschwinge: Necesita correr en el anillo 1, y pedir privilegios de operación a Xen en lugar de perdírelas a él mismo. Esto incluye el acceso a los dispostivos hardware. Sin embargo, con las más nuevas CPUs con las técnicas de virtualización de Intel o AMD, es posible correr sistemas operativos sin modificar sobre Xen |
@netman | 23:39 <@MJesus_> ¿Estás muy cansado Evaldo, o podrías seguir hablando sobre cacert? |
@netman | 23:39 < tschwinge> Se me está ocurriendo esto: Hacer que GNU Mach (un fork del Mach de CMU) corra sobre Xen. GNU Mach es el microkernel que usa el sistema operativo GNU/Hurd. |
@netman | 23:39 <@riel> Aún necesitarías un dominio 0 modificado, creo |
@netman | 23:39 <@Evaldo> MJesus_: Puedo hacerlo :) |
@netman | 23:40 < tschwinge> Echaré un vistazo a eso un día y volveré (a algún lugar, probablemente) con preguntas más concretas. :-) |
@netman | 23:40 <@Evaldo> riel: realmene, como necesitas soporte para las operaciones privilegiadas de Xen sobre el dominio 0 (controlado por el propio Xen) |
@netman | 23:40 <@MJesus_> in #redes están traduciendo al español ... con algo de retardo |
@netman | 23:41 <@riel> Evaldo: más porque necesitas controladores de dispositivo para hablar con el hardware de verdad, y no puedes correr esos controladores desde dentro de un dominio VMX |
@netman | 23:42 <@Evaldo> riel: eso también, hehe |
@netman | 23:42 <@Evaldo> MJesus_: ¿prefieres que empiece con CAcert o esperar un poco para que #redes nos alcance? |
@netman | 23:42 <@Evaldo> MJesus_: son las 20:42 hora local, así que para mí no es ningún problema :) |
@netman | 3:44 <@MJesus_> hummmm es una buena pregunta |
@netman | 23:44 < Daniel> Evaldo, en algunas pruebas de Xen 64 hemos notado que el kernel anfitrión corre en el mismo anillo que las aplicaciones, esto es en el 3. ¿Hasta qué punto se puede confiar en eso? |
@netman | 23:45 <@MJesus_> porque en Europa son las 23:50 |
@netman | 23:45 <@riel> Daniel: x86-64 sólo tiene anillos 0 y 3. Los anillos 1 y 2 no existen. |
@netman | 23:45 < Daniel> kernel del host, lo siento |
@netman | 23:45 <@riel> el kernel del invitado también |
@netman | 23:46 <@riel> su contexto va conmutando entre el kernel y el espacio de usuario |
@netman | 23:46 < Daniel> gracias riel |