Saltar al contenido

Tecnología

Tecnología en General

Scrum – Libro interesante.

En este enlace:

http://www.infoq.com/minibooks/scrum-xp-from-the-trenches

Podeis descargar el libro «SCRUM desde las trincheras». Es un libro excelente (fácil y rápido de leer) de como los autores del mismo han puesto en práctica SCRUM en su organización y las lecciones aprendidas.

SCRUM es ya una de las metodologías más usadas hoy en día en las organizaciones dedicadas al desarrollo del software. Curiosamente es una metodología que no fue concebida inicialmente para desarrollar software (quizás de ahí su potencia). Para este curso debeis leer los siguientes capítulos (aunque os recomiendo la lectura completa):

– CÓMO HACEMOS PILAS DE PRODUCTO

– CÓMO HACEMOS LA PLANIFICACION DE SPRINT

– CÓMO HACEMOS PILAS DE SPRINT

– CÓMO HACEMOS LA DEMO DE SPRINT.

pg_dump – pg_restore (PostgreSQL)

  • admin 

Cuando se trabaja con base de datos, uno de las cosas más importantes de hacer es respaldar los datos en caso de que ocurra cualquier situación que dañe nuestro servidor de base de datos. De nada nos serviría hacer esos respaldos si no los podemos volver a cargar (restaurar) cuando lo necesitemos.
En este post,  trataremos la forma de hacer respaldos y restauración de datos cuando se utiliza postgreSQL como DBMS.

Respaldando los datos: pg_dump

pg_dump es una herramienta de línea de comandos que nos permita hacer un respaldo de alguna de las bases de datos  (o todas) en nuestro servidor postgres. Permite hacer el volcado de datos en diferentes formatos ya sean compresos, texto plano, etc. En resumen, escribe en un archivo (o salida estándar) las instrucciones SQL necesarias para hacer un respaldo de la base de datos.

El formato del comando pg_dump es:
   pg_dump [opciones] [nombre_base]
Entre las opciones que se pueden utilizar están:
dbname: Nombre de la base de datos de la que se desea hacer respaldo.
-a o –data-only: Hace un volcado solo de los datos y no del esquema.
-c o –clean: Crea instrucciones para eliminar los elementos antes de crearlos. Es útil para evitar los errores del tipo ‘la relacion nombre_relación ya existe’ a la hora de restaurar el respaldo.

-C o –create:  Escribe las instrucciones para la creación de la base de datos dentro del script del respaldo.

-f <archivo> o –file=<archivo>:  Escriba la salida (el volcado) en el archivo especificado. En caso de que no se utilice esta opción, el volcado se hace a la salida estándar.

-F <formato_de_archivo> o –format=<formato_de_archivo>: Permite especificar el formato de la salida del dump. El formato de salida puede ser:

p o plain: Texto plano.

c o custom:  Formato de salida customizable. Este tipo de salida siempre se realiza compreso por defecto.

t o tar: Crea la salida en formato tar.

-n <nombre_esquema> o –schema=<nombre_esquema>: Realiza el dumpúnicamente del esquema (y todos los objetos que contengan) que concuerde con el<nombre_esquema>. Si no se especifica, se hará un dump de todos los esquemas que no sean del sistema y que estén en la base destino. Si se quiere incluir en el dump más de un esquema se pueden poner multiples -n <nombre_esquema> como sean necesarios.

-N <nombre_esquema> o –exclude-schema=<nombre_esquema>: Omite los esquemas que concuerden con <nombre_esquema> del dump a realizarse. Se pueden incluir tantos -N como sean necesarios.

-s o –schema-only: Hace un volcado únicamente del esquema, no de los datos.

-t <nombre_tabla> o –table=<nombre_tabla>: Hace un volcado solo de las tablas que se especifiquen. Se pueden utilizar -t <nombre_tabla> tantas veces como se necesite. Se debe tener en cuenta que pg_dump no hace un seguimiento de las tablas de las que pueda depender la tabla que se desee volcar con el dump, así que hay que tener cuidado de incluirlas todas las que sean necesarias (que tengan relación con llaves primarias o foráneas) para garantizar que se puede hacer la restauración de los datos exitosamente.

-T <nombre_tabla> o — exclude-table: <nombre_tabla>: Excluye del dumplas tablas listadas. Esta opción puede ser utilizada más de una vez.

— inserts: Utiliza inserts en lugar de copy en las instrucciones de SQL.

— port = <puerto>: Especifica el puerto TCP o local en el cual el servidor está escuchando.

-U <nombre_de_usuario>: Especifica el nombre de usuario con el que se hará la conexión a la base de datos que se desea respaldar.

Ejemplos:
Si tenemos una base de datos llamada base_de_prueba y queremos respaldarla completamente en un archivo llamado base_de_prueba.sql, podemos utilizar el siguiente comando:
   pg_dump base_de_prueba > base_de_prueba.sql

Para hacer el volcado en un archivo de extensión personalizada (opción -F y c para custom):

   pg_dump -Fc base_de_prueba > base_de_prueba.dump

Para volcar solo una tabla de la base:

   pg_dump -t nombre_tabla base_de_prueba > mi_tabla_dump.sql

Restaurando los datos: pg_restore

Para realizar la restauración de los datos volcados con pg_dump, podemos utilizar la herramienta pg_restore. pg_restore restaura una base de datos que ha sido respaldada con pg_dump.

Entre las ventajas de utilizar esta utilidad para la restauración es que se puede seleccionar qué partes del respaldo se quieren restaurar o incluso reordenar los items antes de hacer la restauración

La sintáxis del comando es la siguiente:

   pg_restore [opciones] [fichero_a_restaurar]

Entre las opciones más comunes utilizadas con este comando están:

-a o –data-only:  Restaura solo los datos, no el esquema.

-c o –clean: Elimina los objetos antes de volverlos a crear.

-C o –create: Crea la base de datos especificada con la opción -d, sin embargo, los datos son restaurados a la base de datos que aparece en el script.
-d <nombre_base> o –dbname=<nombre_base>: Conecta a la base de datos<nombre_base> y restaura los datos directamente en ella.

-j <numero> o –jobs=<numero>: Realiza la restauración de los datos utilizando<numero> hilos o procesos (dependiendo del sistema operativo). Cada jobs es un proceso o hilo que utiliza una conexión separada. La utlización de esta opción, permite poder restaurar un dump en una forma más rápida, sin embargo, utiliza más recursos en el servidor. La velocidad de la restauración, por tanto, depende en gran medida de la configuración del hardware del servidor.

-n <nombre_esquema> o –schema=<nombre_esquema>: Realiza la restauración únicamente del esquema llamado <nombre_esquema>.

-s o –schema-only: Restura solo el esquema, no los datos.

-t <nombre_tabla> o –table=<nombre_tabla>:  Restaura únicamente la tabla con el nombre <nombre_tabla>. <nombre_tabla> puede ser una expresión regular.

-U <nombre_usuario> o –username=<nombre_usuario>:  Nombre de usuario con el que se desea hacer la conexión.
Uno de las cosas a tomar en cuenta a la hora de restaurar un respaldo es que si éste ha sido hecho en un formato particular (custom), no podrá ser visible con herramientas como more,cat o algún editor de texto.

Debido a que no se puede ver que usuarios se utilizan o a que base de debe conectar, se pueden correr problemas a la hora de quererlos restaurar en otra máquina que no tenga los usuarios o bases que correspondan con los que están en el archivo creado con pg_dump.
Una forma de solucionar esto es hacer una restauración sin especificar la base de datos a la que se desea restaurar los datos. Esto hace que pg_restore mande la salida a la salida estandar. Esta salida estandar puede ser enviada a un archivo que contendrá las instrucciones de respaldo en texto plano.
Por ejemplo, asumiendo que tenemos un archivo creado con pg_dump en formato .dump, llamado respaldo-base.dump y queremos pasarlo a texto plano en un fichero, podemos hacer lo siguiente:
$ pg_restore respaldo-base.dump > respaldo-base.sql
El operador > redirecciona la salida de la salida estándar (pantalla) al archivo respaldo-base.sql. Después de haberse ejecutado el comando, el fichero puede ser leido con cualquier editor de texto.

Otros ejemplos:

$ pg_restore -C -d postgres db.dump
Crea la base de datos postgres (por la opción -C) pero siempre vuelca los datos en la base que el script especifica.
 $ pg_restore -d mi_base db.dump
Restaura los datos en la base llamada mi_base. Esta base debe haber sido creada previamente.

 

Como habrán notado, las herramientas pg_dump y pg_restore comparten muchas opciones comunes entre sí y representan un par de herramientas bastante útiles a la hora de restaurar y manipular los respaldos hechos de nuestras bases de datos.

Escalabilidad

  • admin 

En telecomunicaciones y en ingeniería informática, la escalabilidad es la propiedad deseable de un sistema, una red o un proceso, que indica su habilidad para reaccionar y adaptarse sin perder calidad, o bien manejar el crecimiento continuo de trabajo de manera fluida, o bien para estar preparado para hacerse más grande sin perder calidad en los servicios ofrecidos.

En general, también se podría definir como la capacidad del sistema informático de cambiar su tamaño o configuración para adaptarse a las circunstancias cambiantes. Por ejemplo, una Universidad que establece una red de usuarios por Internet para un edificio de docentes y no solamente quiere que su sistema informático tenga capacidad para acoger a los actuales clientes que son todos profesores, sino también a los clientes que pueda tener en el futuro dado que hay profesores visitantes que requieren de la red por algunas aplicaciones académicas, para esto es necesario implementar soluciones que permitan el crecimiento de la red sin que la posibilidad de su uso y reutilización disminuya o que pueda cambiar su configuración si es necesario.

La escalabilidad como propiedad de los sistemas es generalmente difícil de definir en cualquier caso, en particular es necesario definir los requerimientos específicos para la escalabilidad en esas dimensiones donde se crea que son importantes. Es una edición altamente significativa en sistemas electrónicos, bases de datos, ruteadores y redes. A un sistema cuyo rendimiento es mejorado después de haberle añadido más capacidad hardware, proporcionalmente a la capacidad añadida, se dice que pasa a ser un sistema escalable.

 

La escalabilidad debe formar parte del proceso de diseño porque no es una característica separada que se pueda agregar después. Al igual que con otras funciones de aplicación, las decisiones que se tomen durante las primeras fases de diseño y codificación determinarán en gran medida la escalabilidad de la aplicación.

La escalabilidad de una aplicación requiere una pertenencia equilibrada entre dos dominios distintos, software y hardware. Puede avanzar grandes pasos que aumenten la escalabilidad de un dominio sólo para sabotearlos cometiendo errores en el otro. Por ejemplo, la creación de un grupo de servidores Web con equilibrio de carga no beneficiará una aplicación Web que se ha diseñado para ejecutarse un solo equipo. De igual modo, el diseño de una aplicación altamente escalable y su implementación en equipos conectados a una red con poco ancho de bada no controlará bien las cargas pesadas cuando se sature el tráfico en la red.

Puesto que la escalabilidad no es un problema de diseño de las aplicaciones independientes, aquí se tratan las aplicaciones distribuidas. Las aplicaciones distribuidas están también un paso más allá de las tradicionales aplicaciones de cliente-servidor. Las aplicaciones distribuidas son aplicaciones que están diseñadas como aplicaciones de n niveles. La arquitectura de estas aplicaciones distribuidas favorece el diseño de aplicaciones escalables compartiendo recursos, como bases de datos y componentes empresariales.

 

Escalar en vertical
El escalado en vertical es el término que más se utiliza para lograr escalabilidad utilizando software mejor, más rápido y más caro. El escalado incluye agregar más memoria, más procesadores o procesadores más rápidos o, simplemente, migrar la aplicación a un único equipo más potente. Normalmente, este método permite un aumento en la capacidad sin requerir cambios en el código fuente. Desde el punto de vista administrativo, las cosas permanecen igual puesto que sigue habiendo un único equipo que administrar.

escalar en vertical

Actualizar un componente de hardware en un equipo sólo mueve el limite de capacidad de procesamiento de un lado a otro. Por ejemplo, una máquina que está al 100 % de uso de la CPU podría mejorar su capacidad agregando otra CPU. Sin embargo, la limitación puede pasar de la CPU a la memoria del sistema. Agregar CPU no aporta rendimiento en un modelo lineal. En su lugar, el rendimiento va disminuyendo cada vez que se agrega un procesador adicional. Para equipos con configuraciones de varios procesadores simétricos (SMP), cada procesador adicional produce una sobrecarga del sistema. Por tanto, un equipo con cuatro procesadores no obtendrá una mejora del 400% en capacidad sobre una versión con un único procesador. Una vez que haya actualizado todos los componentes de hardware al máximo de su capacidad, llegará el momento en que alcance el límite real de la capacidad de procesamiento del equipo. Llegado ese punto, el siguiente paso es escalar en vertical para moverse a otro equipo.

Escalar en vertical conlleva también otros posibles problemas. El uso de un único equipo en el que basar una aplicación crea un único punto de error, lo que disminuye enormemente la tolerancia de errores del sistema. Si bien algunos métodos, como varias fuentes de alimentación, pueden implementar redundancia en un sistema de un único equipo, pueden resultar costosas.

 

Escalar en horizontal

Una alternativa a escalar en vertical es escalar en horizontal. Escalar en horizontal aprovecha el ahorro que supone utilizar el hardware de PC activo para distribuir la carga de procesamiento en más de un servidor. Aunque el escalado en horizontal se logra utilizando muchos equipos, la colección funciona esencialmente como un único equipo. Al dedicar varios equipos a una tarea común, mejora la tolerancia de errores de la aplicación. Por supuesto, desde el punto de vista del administrador, escalar en horizontal presenta un desafío mayor de administración debido al mayor número de equipos.

 

escalar en horizontal

Los desarrolladores y administradores utilizan una gran variedad de técnicas de equilibrio de carga para escalar en horizontal con la plataforma Windows. El equilibrio de carga permite escalar un sitio en horizontal a través de un clúster de servidores, facilitando la adición de capacidad agregando más servidores duplicados. También proporciona redundancia, concediendo al sitio capacidad de recuperación de conmutación por error, de manera que permanece disponible para los usuarios incluso si uno o más servidores fallan (o si es preciso retirarlos del servicio para realizar labores de mantenimiento). El escalado en horizontal proporciona un método de escalabilidad que no se ve mermado por limitaciones de hardware. Cada servidor adicional proporciona una mejora casi lineal de la escalabilidad.

La clave para escalar horizontalmente una aplicación con éxito es la transparencia de ubicación. Si alguna parte del código de la aplicación depende de saber qué servidor está ejecutando el código, no se ha logrado la transparencia de ubicación y será difícil el escalado en horizontal. Esta situación se denomina afinidad de ubicación. La afinidad de ubicación requiere cambios de código para escalar una aplicación en horizontal de un servidor a varios, lo que, en pocas ocasiones, constituye una opción económica. Si diseña la aplicación con transparencia de ubicación en mente, resulta más fácil escalarla en horizontal.

Virtual Linux

  • admin 

Traducción de un artículo publicado en IBM Developerworks, escrito por M. Tim Jones. Fuente original: http://www-128.ibm.com/developerworks/linux/library/l-linuxvirt/

 

Virtualización significa muchas cosas diferentes para diferentes personas. Un aspecto candente en la virtualización es la virtualización de servidores, o como alojar múltiples sistemas operativos independientes en un único ordenador anfitrion. Este artículo explora las ideas tras la virtualización y discute algunas de las múltiples maneras de implementarla. También se revisan diferentes tecnologias de virtualización, como la virtualización de sistema operativo en Linux.

 

Virtualizar significar aparentar que algo con una forma tiene otra. Virtualizar un ordenador significa aparentar que se trata de múltiples ordenadores o de un ordenador completamente diferente.

Virtualización tambien puede significar conseguir que varios ordenadores parezcan uno solo. A este concepto se le suele denominar agregación de servidores (server aggregation) o grid computing.

Comencemos con los orígenes de la virtualización.

Una visión historica de la virtualización

La virtualización no es un tema nuevo, de hecho ronda desde hace 40 años. Los primeros usos de la virtualización incluyen el IBM 7044, el Sistema de Tiempo Compartido Compatible (CTSS – Compatible Time Sharing System) desarrollado en el Instituto Tecnológico de Massachusetts (MIT – Massachussets Institute of Technology) en el IBM 704. Y el proyecto Atlas de la Universidad de Manchester (uno de los primeros superordenadores del mundo), que fué pionero en el uso de memoria virtual con paginación y llamadas de supervisor.

Virtualización de hardware

IBM reconoció la importancia de la virtualización en la década de 1960 con el desarrollo del mainframe System/360 Model 67. El Model 67 virtualizó todas las interfaces hardware a través del Monitor de Máquina Virtual (VMM – Virtual Machine Monitor). En los primeros días de la computación, el sistema operativo se llamó supervisor. Con la habilidad de ejecutar sistemas operativos sobre otro sistema operativo, apareció el termino hypervisor (termino acuñado en la década de 1970).

El VMM se ejecutaba directamente sobre el hardware subyacente, permitiendo múltiples máquinas virtuales (VMs). Cada VM podía ejecutar una instancia de su propio sistema operativo privado — al comienzo este era CMS, o Conversational Monitor System. Las máquinas virtuales han continuado avanzando, y hoy se pueden encontrar ejecutándose en el mainframe System z9. Lo que proporciona compatibilidad hacia atrás, incluso hasta la línea System/360.

Virtualización del procesador

Java Virtual Machine (JVM)
El lenguaje Java ha seguido el modelo P-code en su máquina virtual. Esto ha permitido la amplia distribución de programas Java sobre incontables arquitecturas simplemente portando la JVM.

Otro de los usos iniciales de la virtualización, en este caso de un procesador simulado, es la máquina de pseudo-código (P-code machine). P-code es un lenguaje máquina que se ejecuta en una máquina virtual en lugar de en hardware real. P-code alcanzó la fama en la década de 1970 en el sistema Pascal de la Universidad de California, San Diego (UCSD), que compilaba programas Pascal en P-code (o pseudo-código), y luego los ejecutaba en una máquina virtual P-code. Esto permitió que los programas P-code fuesen muy portables y pudiesen ejecutarse en cualquier lugar donde estuviese disponible una máquina virtual P-code.

El mismo concepto se utilizó en la decada de 1960 para el Basic Combined Programming Language (BCPL), un antepasado del lenguaje C. En este caso, un compilador compilaba código BCPL en un código máquina intermedio llamado O-code. En un segundo paso, el O-code era compilado en el lenguaje nativo de la máquina de destino. Este modelo se utiliza en los compiladores modernos para proporcionar flexibilidad al portar los compiladores hacia nuevas arquitecturas destino (separando el front-end y el back-end por un lenguaje intermedio).

Virtualización del juego de instrucciones

La virtualización del juego de instrucciones, o la traducción binaria, es un aspecto nuevo. En este modelo, un juego de instrucciones virtual se traduce al juego de instrucciones físico del hardware subyacente, normalmente de forma dinámica. Cuando se va a ejecutar el código se realiza la traducción de una porción. Si se produce una ramificación (salto), se obtiene y traduce una nueva porción de código. Este proceso es similar a las operaciones que se realizan con memoria cache, donde bloques de instrucciones se mueven desde la memoria hasta una memoria cache local rápida antes de su ejecución.

La CPU Crusoe diseñada por Transmeta es un ejemplo reciente de este modelo. Esta arquitectura implementa traducción binaria bajo la marca registrada Code Morphing. Un ejemplo similar es el análisis de código en tiempo de ejecución utilizado en las soluciones de virtualización completa, que buscan y redirigen instrucciones privilegiadas (para evitar algunos problemas con ciertos juegos de instrucciones).

Tipos de virtualización

La virtualización y los juegos
Un artículo sobre virtualización no estaría completo sin una referencia a MAME (Multiple-Arcade Machine Emulator). MAME, como su propio nombre explica, es un completo emulador de muchos juegos arcade antiguos. Además de virtualizar los procesadores utilizados en esos juegos, se virtualiza la máquina completa, incluyendo el hardware de gráficos, sonido y controles. MAME es una gran aplicación, es muy interesante revisar su código para entender el alcance de lo que ha logrado.

No existe una sola manera de realizar la virtualización. De hecho, existen diversas técnicas que alcanzan el mismo resultado a través de diferentes niveles de abstracción. Esta sección presenta tres de las técnicas de virtualización más comunes en Linux, identificando sus puntos fuertes y sus debilidades. La industria algunas veces utiliza diferentes términos para describir el mismo método de virtualización. Aquí se utilizará el término más común, con referencias a otras denominaciones.

Emulación Hardware

La virtualización más compleja consiste en la emulación de hardware. Con esta técnica, en el sistema anfitrión se utiliza una máquina virtual que emula el hardware, como muestra la Figura 1.

figure1.gif

Figura 1. La emulación de Hardware utiliza una máquina virtual (VM) para simular el hardware

Emulación y desarrollo
Uno de los usos más interesantes de la emulación hardware es el codesarrollo de firmware y hardware. En lugar de esperar hasta que el hardware real esté disponible, los desarrolladores del firmware pueden utilizar una máquina virtual del hardware para validar muchos detalles de su código en una simulación.

Como puede suponer, el principal problema con la emulación hardware es que puede resultar terriblemente lenta. Ya que cada instrucción debe ser simulada por el hardware subyacente, no es extraño obtener una velocidad 100 veces más lenta. Si se pretende conseguir una emulación muy fiel que incluya precisión en los ciclos, simulación de los pipelines de la CPU, y comportamiento de cache, la diferencia de velocidad real puede ser 1000 veces más lenta.

La emulación de hardware tiene sus ventajas. Por ejemplo, utilizando la emulación hardware, es posible ejecutar un sistema operativo sin modificar diseñado para un PowerPC sobre una máquina anfitrión con procesador ARM. Incluso es posible ejecutar múltiples máquinas virtuales, cada una simulando un procesador diferente.

Virtualización completa

La virtualización completa, también llamada virtualización nativa, es otra interesante técnica de virtualización. Este modelo utiliza una máquina virtual que media entre el sistema operativo invitado y el hardware nativo (ver Figura 2). «Mediar» es la palabra clave aquí porque la VMM está entre el sistema el sistema operativo invitado y el hardware real. Algunas instrucciones protegidas deben capturarse y manejarse dentro del hipervisor ya que el hardware subyacente no es propiedad de un sistema operativo sino que es compartido a través del hipervisor.

 

figure2.gif

Figura 2. La virtualización completa utiliza un hipervisor para compartir el hardware subyacente

Hipervisores en hardware antiguo
Parte del hardware antiguo, como el x86, crea problemas para la técnica de la virtualización completa. Por ejemplo, no se capturan ciertas instrucciones que deben ser manejadas por la VMM. Por lo tanto, los hipervisores deben revisar y capturar de forma dinámica el código en modo privilegiado para lidiar con este problema.

La virtualización completa es más rápida que la emulación hardware, pero el rendimiento es menor que cuando se utiliza hardware pelado debido a la mediación del hipervisor. La gran ventaja de la virtualización completa es que un sistema operativo puede ejecutarse sin modificaciones. La única restricción es que el sistema operativo debe soportar el hardware subyacente (por ejemplo, PowerPC).

Paravirtualización

La paravirtualización es otra técnica popular que cuenta con algunas similitudes con la virtualización completa. Este método utiliza un hipervisor para compartir el acceso al hardware subyacente pero integra código que está al tanto de la virtualización en el propio sistema operativo (ver Figura 3). Esta aproximación evita la necesidad de recompilar y capturar ya que los propios sistemas operativos cooperan en el proceso de virtualización.

 

figure3.gif

Figura 3. La paravirtualización comparte el proceso con el SO alojado (Guest OS)

Como ya he mencionado, la paravirtualización precisa que los sistemas operativos alojados sean modificados por el hipervisor, lo que es una desventaja. Pero la paravirtualización ofrece un rendimiento próximo al de un sistema no virtualizado. Del mismo modo que con la virtualización completa, es posible soportar varios sistemas operativos diferentes de manera concurrente.

Virtualización en el nivel del sistema operativo

La última técnica que exploraremos, la virtualización en el nivel del sistema operativo, utiliza una técnica diferente a las que hemos visto. Esta técnica virtualiza los servidores encima del propio sistema operativo. Este método soporta un solo sistema operativo y símplemente aisla los servidores independientes (ver Figura 4).

 

figure4.gif

Figura 4. La virtualización en el nivel del sistema operativo aisla a los servidores

La virtualización en el nivel del sistema operativo requiere cambios en el núcleo del sistema operativo, la ventaja es un rendimiento igual a la ejecución nativa.

Qué importancia tiene la virtualización ?

Antes de examinar algunas de las opciones de virtualización disponibles hoy en Linux, vamos a examinar las ventajas de la virtualización.

Desde una perspectiva de negocio, hay muchas razones para utilizar virtualización. La mayoría están relacionadas con la consolidación de servidores. Simple, si puedes virtualizar un número de sistemas infrautilizados en un solo servidor, ahorrarás energia, espacio, capacidad de refrigeración y administración ya que tienes menos servidores. Como puede ser difícil determinar el grado de utilización de un servidor, las tecnologias de virtualización soportan la migración en directo. La migración en directo permite que un sistema operativo y sus aplicaciones se muevan a un nuevo servidor para balancear la carga sobre el hardware disponible.

La virtualización también es importante para los desarrolladores. El núcleo Linux ocupa un solo espacio de direcciones, lo que significa que un fallo en el núcleo o en cualquier driver provoca la caída del sistema operativo completo. La virtualización supone que puedes ejecutar varios sistemas operativos, y si uno cae debido a un fallo, el hipervisor y el resto de sistemas operativos continuarán funcionando. Esto puede hacer que depurar el nucleo sea una tarea más parecida a depurar aplicaciones en el espacio del usuario.

Proyectos de virtualización relacionados con Linux

La Tabla 1 muestra diferentes posibilidades de virtualización en Linux, centrándose en aquellas soluciones de código abierto.

 

Proyecto Tipo Licencia
Bochs Emulación LGPL
QEMU Emulación LGPL/GPL
VMware Virtualización completa Privativa
z/VM Virtualización completa Privativa
Xen Paravirtualización GPL
UML Paravirtualización GPL
Linux-VServer Virtualización en el nivel del sistema operativo GPL
OpenVZ Virtualización en el nivel del sistema operativo GPL

Tabla 1. Proyectos de virtualización relacionados con Linux

 

 

Bochs (emulación)

Virtualización a nivel de biblioteca
Aunque aquí no se haya tratado, otro método de virtualización que emula porciones de un sistema operativo a través de una biblioteca es la virtualización a nivel de biblioteca. Algunos ejemplos son Wine (parte de la API Win32 para Linux) y LxRun (parte de la API Linux para Solaris)

Bochs simula un ordenador x86, es portable y se ejecuta sobre diferentes plataforas, incluyendo x86, PowerPC, Alpha, SPARC y MIPS. El interés de Bochs es que no solo emula el procesador sino el ordenador entero, incluyendo los periféricos, como el teclado, ratón, hardware gráfico, adaptadores de red, etc.

Bochs puede configurarse como un antiguo Intel 386, o sucesores como el 486, Pentium, Pentium Pro, o una variante de 64 bits. Incluso emula instrucciones gráficas opcionales como MMX y 3DNow.

Utilizando el emulador Bochs, puedes ejecutar cualquier distribución Linux en Linux, Microsoft Windows 95/98/NT/2000 (y una variedad de aplicaciones) en Linux, incluso los sistemas operativos BSD (FreeBSD, OpenBSD, etc…) sobre Linux.

QEMU (emulación)

QEMU es otro emulador, como Bochs, pero tiene algunas diferencias que son bienvenidas. QEMU soporta dos modos de operación. El primero es el modo de emulación de sistema completo. Este modo es similar a Bochs ya que emula todo un ordenador personal (PC) con su procesador y periféricos. Este modo emula varias arquitecturas, como x86, x86_64, ARM, SPARC, PowerPC y MIPS, con velocidad razonable utilizando traducción dinámica. Utilizando este modo es posible emular los sistemas operativos Windows (incluyendo XP) y Linux sobre Linux, Solaris y FreeBSD. Tambien se soportan otras combinaciones de sistemas operativos (consulte la sección recursos para obtener más información).

QEMU también soporta un segundo modo llamado User Mode Emulation. En este modo, que sólo puede ser alojado en Linux, puede lanzarse un binario para una arquitectura diferente. Esto permite, por ejemplo, que se ejecute en Linux sobre x86 un binario compilado para la arquitectura MIPS. Entre las arquitecturas soportadas por este modo se encuentran ARM, SPARC, PowerPC y otras que están en desarrollo.

VMware (virtualización completa)

VMware es una solución comercial para la virtualización completa. Entre los sistemas operativos alojados y el hardware existe un hipervisor funcionando como capa de abstracción. Esta capa de abstracción permite que cualquier sistema operativo se ejecute sobre el hardware sin ningún conocimiento de cualquier otro sistema operativo alojado.

VMware también virtualiza el hardware de entrada/salida disponible y ubica drivers para dispositivos de alto rendimiento en el hipervisor.

El entorno virtualizado completo se respalda en un fichero, lo que significa que un sistema completo (incluyendo el sistema operativo alojado, la máquina virtual y el hardware virtual) puede migrarse con facilidad y rapidez a una nueva máquina anfitrión para balancear la carga.

z/VM (virtualización completa)

Aunque el IBM System z estrena nombre, realmente tiene una larga historia que se origina en la decada de 1960. El System/360 ya soportaba virtualización utilizando máquinas virtuales en 1965. Es interesante observar que el System z mantiene la retrocompatibilidad hasta la antigua línea System/360.

En el System z, se utiliza como hipervisor del sistema operativo a z/VM. En su interior está el Programa de Control (CP – Control Program), que proporciona la virtualización de los recursos físicos a los sistemas operativos alojados, incluyendo Linux (ver Figura 5). Esto permite que varios procesadores y otros recursos sean virtualizados para un número de sistemas operativos alojados.

 

figure5.gif

Figura 5. Virtualización a nivel de SO utilizando z/VM

z/VM también puede emular una LAN virtual para aquellos sistemas operativos hospedados que quieren comunicarse entre sí. La emulación se realiza por completo en el hipervisor, con lo que se obtiene una gran seguridad.

Xen (paravirtualización)

Xen es la solución de fuente abierta proporcionada por XenSource para obtener paravirtualización a nivel de sistema operativo. Recuerde que en la paravirtualización el hipervisor y el sistema operativo colaboran en la virtualización, se requieren cambios en el sistema operativo pero se obtiene un rendimiento próximo a la ejecución nativa.

Como Xen precisa colaboración (modificaciones en el sistema operativo alojado), solo pueden virtualizarse en Xen sistemas operativos parcheados. Desde el punto de vista de Linux, que es de fuente abierta, se trata de un compromiso razonable porque se consigue un mejor rendimiento que con la virtualización completa. Pero desde el punto de vista de un soporte amplio (que incluya otros sistemas operativos que no sean de fuente abierta), se trata de un claro inconveniente.

Es posible ejecutar Windows como SO alojado en Xen, pero solo en sistemas hardware que soporten la tecnología Vanderpool de Intel o Pacifica de AMD. Otros sistemas operativos soportados por Xen son: Minix, Plan 9, NetBSD, FreeBSD y OpenSolaris.

User-mode Linux (paravirtualización)

User-mode Linux (UML) permite que un sistema operativo Linux ejecute otros sistemas operativos Linux en el espacio del usuario. Cada sistema operativo Linux alojado existe como un proceso en el sistema operativo Linux anfitrión (ver Figura 6). Lo que permite a varios núcleos Linux (con sus propios espacios de usuario asociados) ejecutarse en el contexto de un solo núcleo Linux.

 

figure6.gif

Figura 6. Alojamiento de Linux en User-mode Linux

Desde el núcleo Linux 2.6, UML se encuentra en la rama principal del núcleo, pero debe ser activado y recompilado antes de utilizarse. Estos cambios proporcionan, entre otras cosas, virtualización de dispositivos. Lo que permite a los sistemas operativos alojados compartir los dispositivos físicos disponibles, como los dispositivos de bloques (floppy, CD-ROM, y sistemas de ficheros), consolas, dispositivos NIC, hardware de sonido y otros.

Puesto que los núcleos alojados se ejecutan en el espacio del usuario deben estar compilados para este uso (aunque puede tratarse de diferentes versiones del núcleo). Existirá un núcleo anfitrión (que se ejecutará sobre el hardware) y uno o varios núcleos alojados (que se ejecutarán en el espacio de usuario del núcleo anfitrión). Es posible anidar estos núcleos, de manera que un núcleo alojado actúe como anfitrión de otro.

Linux-VServer (virtualización a nivel de sistema operativo)

Linux-VServer es una solución de virtualización a nivel de sistema operativo. Linux-VServer virtualiza el núcleo Linux de manera que varios entornos de espacio de usuario, también llamados Virtual Private Servers (VPS), se ejecutan de foma independiente sin tener conocimiento del resto. El aislamiento del espacio de usuario se consigue gracias a diferentes modificaciones del núcleo Linux.

Para aislar cada uno de los espacios de usuario del resto hay que estudiar el concepto de un contexto. Un contexto es un contenedor para los procesos de un VPS, de manera que herramientas como pssolo muestran información sobre los procesos del VPS. Para el arranque inicial el núcleo define un contexto por defeto. Tambien existe un contexto espectador para la administración (ver todos los procesos en ejecución). Como puede suponer, tanto el núcleo como las estructuras internas de datos se han modificado para dar soporte a esta técnica de virtualización.

Con Linux-VServer también se utiliza un tipo de chroot para aislar el directorio raíz de cada VPS. Recuerde que una chroot permite  que se especifique un nuevo directorio raíz, además se utilizan otras funciones (llamadas Chroot-Barrier) para que un VPS no pueda escapar desde su confinamiento en el directorio raíz. Cada VPS cuenta con su propia raíz y lista de usuarios y contraseñas.

Linux-VServer está soportado en los núcleos Linux v2.4 y v2.6, pudiendo funcionar sobre diferentes plataformas: x86, x86-64, SPARC, MIPS, ARM y PowerPC.

OpenVZ (virtualización a nivel de sistema operativo)

OpenVZ es otra solución de virtualización a nivel de sistema operativo, como Linux-VServer, pero tiene algunas diferencias interesantes. OpenVZ es un núcleo modificado para la virtualización que soporta espacios de usuario aislados, VPS, con un conjunto de herramientas de usuario para la administración. Por ejemplo, es fácil crear un nuevo VPS desde la línea de comandos:

Listado1. Creación de un VPS desde la línea de comandos

$ vzctl create 42 --ostemplate fedora-core-4
Creating VPS private area
VPS private area was created
$ vzctl start 42
Starting VPS ...
VPS is mounted

También puede listar los VPSs creados con vzlist, que opera de una forma similar al comando ps.

Para planificar los procesos, OpenVZ utiliza un planificador de dos niveles. Primero se determina qué VPS debe obtener la CPU. Después, el segundo nivel del planificador escoge el proceso a ejecutar basándose en las prioridades standard de Linux.

OpenVZ también incluye los llamados beancounters. Un beancounter consiste en un número de parámetros que definen la distribución de recursos para un VPS. Esto proporciona cierto nivel de control sobre un VPS, definiendo la cantidad de memoria y el número de objetos para la comunicación entre procesos (IPC) disponibles.

Una característica única de OpenVZ es la habilidad de establecer un punto de control y migrar un VPS desde un servidor físico a otro. Establecer un punto de control significa que el estado de un VPS en ejecución se congela y se guarda en un fichero. Este fichero puede llevarse a un nuevo servidor para restaurar la ejecución del VPS.

Entre las arquitecturas soportadas por OpenVZ se encuentran: x86, x86-64 y PowerPC.

Soporte hardware para la virtualización completa y la paravirtualización

Recuerde que la arquitectura IA-32 (x86) crea ciertos problemas cuando se intenta virtualizar. Algunas instrucciones del modo privilegiado no se pueden capturar y pueden devolver diferentes resultados en función del modo. Por ejemplo, la instrucción STR recupera el estado de seguridad, pero el valor que retorna depende del nivel de privilegios de quien realizó la ejecución. Lo que es problemático cuando se intenta virtualizar diferentes sistemas operativos en diferentes niveles. Por ejemplo, la arquitectura x86 soporta cuatro anillos de protección, el nivel 0 (mayor privilegio) normalmente ejecuta el sistema operativo, los niveles 1 y 2 dan soporte a los servicios del sistema operativo, y el nivel 3 (el menor de los privilegios) soporta las aplicaciones. Los fabricantes de hardware han detectado este defecto (y otros), y han producido nuevos diseños que soportan y aceleran la virtualización.

Intel está produciendo una nueva tecnologia de virtualización que soportará hipervisores en dos de sus arquitecturas, tanto en x86 (VT-x) como en Itanium (VT-i). VT-x soporta dos nuevos modos de operación, uno para la VMM (root) y otro para los sistemas operativos hospedados (no root). En el modo root se cuentan con todos los privilegios, mientras que en el modo no root no se tienen privilegios (incluso para el nivel 0). La arquitectura también permite cierta flexibilidad al definir las instrucciones que provocan que una VM (sistema operativo hospedado) retorne al VMM y almacene el estado del procesador. También se han añadido otras capacidades, consulte la sección recursos.

AMD está produciendo la tecnologia Pacifica en la que el hardware asiste a la virtualización. Entre otras cosas, Pacifica mantiene un bloque de control para los sistemas operativos hospedados que se guarda con la ejecución de instrucciones especiales. La instrucción VMRUN permite a una máquina virtual (y sus sistema operativo hospedado asociado) ejecutarse hasta que el VMM recupere el control (lo que también es configurable). Las opciones de configuración permiten que el VMM adapte los privilegios de cada uno de los huespedes. Pacifica también compensa la traducción de direcciones con unidades de gestión de memoria (MMU) para el anfitrion y los huespedes.

Estas nuevas tecnologias pueden utilizarse en varias de las técnicas de virtualización que se han discutido, como Xen, VMware, User-mode Linux y otras.

Linux KVM (Kernel Virtual Machine)

Las notícias más recientes que provienen de Linux son la incorporación de KVM en el núcleo (2.6.20). KVM es una completa solución de virtualización única al convertir al núcleo Linux en un hipervisor utilizando un módulo del núcleo. Este módulo permite a otros sistemas operativos alojados ejecutarse en el espacio de usuario del núcleo Linux anfitrión (ver Figura 7). El módulo KVM en el núcleo expone el hardware virtualizado a través del dispositivo de carácteres /dev/kvm. El sistema operativo alojado se comunica con el módulo KVM utilizando un proceso que ejecuta un QEMU modificado para obtener la emulación de hardware.

 

figure7.gif

Figura 7. Virtualización con Kernel Virtual Machine (KVM)

El módulo KVM introduce un nuevo modo de ejecución en el núcleo. Donde el kernel vanilla (standard) aporta el modo kernel y el modo user, KVM aporta el modo guest. Este modo es utilizado para ejecutar todo el código del huesped en el que no se utiliza entrada/salida, y el modo normal de usuario proporciona la entrada/salida para los huespedes.

La presentación de KVM es una interesante evolución de Linux, ya que es la primera tecnologia de virtualización que pasa a formar parte del propio núcleo Linux. Existe en la rama 2.6.20, pero puede utilizarse como un módulo del núcleo en la versión 2.6.19. Cuando se ejecuta en hardware que soporta la virtualización es posible hospedar a Linux (32 y 64 bits) y Windows (32 bits). Para más información sobre KVM consulte la sección de recursos.

Resumen

La virtualización es la nueva estrella, si se puede llamar «nuevo» a algo con unos 40 años de antiguedad. Históricamente se ha utilizado en diferentes situaciones, pero en la actualidad su principal interés es la virtualización de servidores y sistemas operativos. Como Linux, la virtualización proporciona muchas opciones de rendimiento, portabilidad y flexibilidad. Lo que significa que puede escoger la solución que mejor se ajusta a sus necesidades y a su aplicación.

Recursos

Aprender

  • La página New to IBM Systems es útil si los sistemas IBM no son territorio conocido. La página detalla entre otros los sistemas i, p, x y z.
  • En developerWorks Grid computing zone es posible aprender sobre grid computing, un conjunto abierto de standards y protocolos que virtualizan un ordenador distribuido permiten crear un sistema poderoso.
  • En la zona developerWorks Linux puede encontrar más recursos para desarrolladores Linux
  • Puede mantenerse al día con developerWorks technical events and webcasts.

    • Productos y tecnologias

    • Bochs y QEMU son emuladores de PC que permiten que sistemas operativos como Windows o Linux se ejecuten en el espacio de usuario de un sistema operativo Linux.
    • VMware es una solución comercial popular que proporciona virtualización completa y puede virtualizar sistemas operativos sin modificar.
    • z/VM es el sistema operativo VM más nuevo para la arquitectura z/Architecture de 64 bits. z/VM proporciona virtualización completa con asistencia de hardware y soporta un amplio abanico de sistemas operativos, incluido Linux.
    • Xen es una solución de fuente abierta para la paravirtualización que requiere modificaciones a los sistemas operativos hospedados pero, al colaborar con el hipervisor, alcanza rendimientos próximos a la ejecución nativa.
    • User-mode Linux es otra solución de fuente abierta para la paravirtualización. Cada sistema operativo huesped se ejecuta como un proceso del sistema operativo anfitrion.
    • coLinux, o Cooperative Linux, es una solución de virtualización que permite a dos sistemas operativos compartir de forma cooperativa el hardware subyacente.
    • Linux-Vserver es una solución de virtualización a nivel de sistema operativo para los sistemas GNU/Linux que aisla de forma segura a los servidores hospedados.
    • OpenVZ es una solución de virtualización a nivel de sistema operativo que soporta puntos de control y migración de VPSs sobre la marcha.
    • Linux KVM es la primera tecnologia de virtualización que ha sido capaz de integrarse en la línea principal de producción del núcleo Linux. Con solo un módulo del núcleo, un núcleo Linux que se ejecute sobre hardware con soporte para la virtualización es capaz de actuar como hipervisor y soportar sistemas operativos Linux y Windows  sin modificar como huespedes.
    • Order the SEK for Linux, dos DVDs con las últimas versiones de evaluación de software de IBM para Linux: DB2, Lotus, Rational, Tivoli y WebSphere.
    • Base su próximo proyecto sobre Linux en el IBM trial software disponible para descarga directa desde developerWorks.

    Comentarios

    Sobre el autor

    p-mjones.jpgM. Tim Jones es un arquitecto de software empotrado y autor de GNU/Linux Application Programming, AI Application Programming, y BSD Sockets Programming from a Multilanguage Perspective. Su experiencia como ingeniero incluye desde el desarrollo de núcleos para satélites geosíncronos hasta el desarrollo de arquitecturas para sistemas empotrados y protocolos de red. Tim es un Consultant Engineer para Emulex Corp. en Longmont, Colorado.

     

    Hot Plugging: hotplug

    • admin 

    Fuente: http://debian-handbook.info/browse/stable/sect.hotplug.html

    Introduction

    The hotplug kernel subsystem loads drivers for peripherals that can be hotplugged. This includes USB peripherals (increasingly common), PCMCIA (common expansion cards for laptops), IEEE 1394 (also called “Firewire” or “I-Link”), some SATA hard drives, and even, for some high-end servers, PCI or SCSI devices.

    The kernel has a database that associates each device ID with the required driver. This database is used during boot to load all the drivers for the peripheral devices detected on the different buses mentioned, but also when an additional hotplug device is connected.

    Once a driver is loaded, a message is sent to udevd so it will be able to create the corresponding entry in /dev/.
    The Naming Problem

    Before the appearance of hotplug connections, it was easy to assign a fixed name to a device. It was based simply on the position of the devices on their respective bus. But this is not possible when such devices can come and go on the bus. The typical case is the use of a digital camera and a USB key, both of which appear to the computer as disk drives. The first one connected may be /dev/sdb and the second /dev/sdc (with /dev/sda representing the computer’s own hard drive). The device name is not fixed; it depends on the order in which devices are connected.

    Additionally, more and more drivers use dynamic values for devices’ major/minor numbers, which makes it impossible to have static entries for the given devices, since these essential characteristics may vary after a reboot.

    udev was created precisely to solve this problem.

    NOTE: IN PRACTICE Network card management
    Many computers have multiple network cards (sometimes two wired interfaces and a wifi interface), and with hotplug support on most bus types, the 2.6 kernel no longer guarantees fixed naming of network interfaces. But a user who wants to configure their network in /etc/network/interfaces needs a fixed name!

    It would be difficult to ask every user to create their own udev rules to address this problem. This is why udev was configured in a rather peculiar manner; on first boot (and, more generally, each time that a new network card appears) it uses the name of the network interface and its MAC address to create new rules that will reassign the same name on subsequent boots. These rules are stored in /etc/udev/rules.d/70-persistent-net.rules.
    This mechanism has some side effects that you should know about. Let’s consider the case of computer that has only one PCI network card. The network interface is named eth0, logically. Now say the card breaks down, and the administrator replaces it; the new card will have a new MAC address. Since the old card was assigned the name, eth0, the new one will be assigned eth1, even though the eth0 card is gone for good (and the network will not be functional because /etc/network/interfaces likely configures an eth0 interface). In this case, it is enough to simply delete the /etc/udev/rules.d/70-persistent-net.rules file before rebooting the computer. The new card will then be given the expected eth0 name.

    How udev Works
    When udev is notified by the kernel of the appearance of a new device, it collects various information on the given device by consulting the corresponding entries in /sys/, especially those that uniquely identify it (MAC address for a network card, serial number for some USB devices, etc.).
    Armed with all of this information, udev then consults all of the rules contained in /etc/udev/rules.d/ and /lib/udev/rules.d/. In this process it decides how to name the device, what symbolic links to create (to give it alternative names), and what commands to execute. All of these files are consulted, and the rules are all evaluated sequentially (except when a file uses “GOTO” directives). Thus, there may be several rules that correspond to a given event.
    The syntax of rules files is quite simple: each row contains selection criteria and variable assignments. The former are used to select events for which there is a need to react, and the latter defines the action to take. They are all simply separated with commas, and the operator implicitly differentiates between a selection criterion (with comparison operators, such as == or !=) or an assignment directive (with operators such as =, += or :=).
    Comparison operators are used on the following variables:

     

    • KERNEL: the name that the kernel assigns to the device;
    • ACTION: the action corresponding to the event (“add” when a device has been added, “remove” when it has been removed);
    • DEVPATH: the path of the device’s /sys/ entry;
    • SUBSYSTEM: the kernel subsystem which generated the request (there are many, but a few examples are “usb”, “ide”, “net”, “firmware”, etc.);
    • ATTR{attribut}: file contents of the attribute file in the /sys/$devpath/ directory of the device. This is where you find the MAC address and other bus specific identifiers;
    • KERNELS, SUBSYSTEMS and ATTRS{attributes} are variations that will try to match the different options on one of the parent devices of the current device;
    • PROGRAM: delegates the test to the indicated program (true if it returns 0, false if not). The content of the program’s standard output is stored so that it can be reused by the RESULT test;
    • RESULT: execute tests on the standard output stored during the last call to PROGRAM.

    The right operands can use pattern expressions to match several values at the same time. For instance, * matches any string (even an empty one); ? matches any character, and [] matches the set of characters listed between the square brackets (or the opposite thereof if the first character is an exclamation point, and contiguous ranges of characters are indicated like a-z).
    Regarding the assignment operators, = assigns a value (and replaces the current value); in the case of a list, it is emptied and contains only the value assigned. := does the same, but prevents later changes to the same variable. As for +=, it adds an item to a list. The following variables can be changed:

    • NAME: the device filename to be created in /dev/. Only the first assignment counts; the others are ignored;
    • SYMLINK: the list of symbolic links that will point to the same device;
    • OWNER, GROUP and MODE define the user and group that owns the device, as well as the associated permission;
    • RUN: the list of programs to execute in response to this event.

    The values assigned to these variables may use a number of substitutions:
    $kernel or %k: equivalent to KERNEL;
    $number or %n: the order number of the device, for example, for sda3, it would be “3”;
    $devpath or %p: equivalent to DEVPATH;
    $attr{attribute} or %s{attribute}: equivalent to ATTRS{attribute};
    $major or %M: the kernel major number of the device;
    $minor or %m: the kernel minor number of the device;
    $result or %c: the string output by the last program invoked by PROGRAM;
    and, finally, %% and $$ for the percent and dollar sign, respectively.
    The above lists are not complete (they include only the most important parameters), but the udev(7) manual page should be.
    A concrete example
    Let us consider the case of a simple USB key and try to assign it a fixed name. First, you must find the elements that will identify it in a unique manner. For this, plug it in and run udevadm info -a -n /dev/sdc (replacing /dev/sdc with the actual name assigned to the key).
    # udevadm info -a -n /dev/sdc
    […]
    looking at device ‘/devices/pci0000:00/0000:00:10.3/usb1/1-2/1-2.2/1-2.2:1.0/host9/target9:0:0/9:0:0:0/block/sdc’:
    KERNEL==»sdc»
    SUBSYSTEM==»block»
    DRIVER==»»
    ATTR{range}==»16″
    ATTR{ext_range}==»256″
    ATTR{removable}==»1″
    ATTR{ro}==»0″
    ATTR{size}==»126976″
    ATTR{alignment_offset}==»0″
    ATTR{capability}==»53″
    ATTR{stat}==» 51 100 1208 256 0 0 0 0 0 192 25 6″
    ATTR{inflight}==» 0 0″
    […]
    looking at parent device ‘/devices/pci0000:00/0000:00:10.3/usb1/1-2/1-2.2/1-2.2:1.0/host9/target9:0:0/9:0:0:0’:
    KERNELS==»9:0:0:0″
    SUBSYSTEMS==»scsi»
    DRIVERS==»sd»
    ATTRS{device_blocked}==»0″
    ATTRS{type}==»0″
    ATTRS{scsi_level}==»3″
    ATTRS{vendor}==»I0MEGA »
    ATTRS{model}==»UMni64MB*IOM2C4 »
    ATTRS{rev}==» »
    ATTRS{state}==»running»
    […]
    ATTRS{max_sectors}==»240″
    […]
    looking at parent device ‘/devices/pci0000:00/0000:00:10.3/usb1/1-2/1-2.2’:
    KERNELS==»9:0:0:0″
    SUBSYSTEMS==»usb»
    DRIVERS==»usb»
    ATTRS{configuration}==»iCfg»
    ATTRS{bNumInterfaces}==» 1″
    ATTRS{bConfigurationValue}==»1″
    ATTRS{bmAttributes}==»80″
    ATTRS{bMaxPower}==»100mA»
    ATTRS{urbnum}==»398″
    ATTRS{idVendor}==»4146″
    ATTRS{idProduct}==»4146″
    ATTRS{bcdDevice}==»0100″
    […]
    ATTRS{manufacturer}==»USB Disk»
    ATTRS{product}==»USB Mass Storage Device»
    ATTRS{serial}==»M004021000001″
    […]
    To create a new rule, you can use tests on the device’s variables, as well as those of one of the parent devices. The above case allows us to create two rules like these:
    KERNEL==»sd?», SUBSYSTEM==»block», ATTRS{serial}==»M004021000001″, SYMLINK+=»usb_key/disk»
    KERNEL==»sd?[0-9]», SUBSYSTEM==»block», ATTRS{serial}==»M004021000001″, SYMLINK+=»usb_key/part%n»
    Once these rules are set in a file, named for example /etc/udev/rules.d/010_local.rules, you can simply remove and reconnect the USB key. You can then see that /dev/usb_key/disk represents the disk associated with the USB key, and /dev/usb_key/part1 is its first partition.
    GOING FURTHER Debugging udev’s configuration

    Like many daemons, udevd stores logs in /var/log/daemon.log. But it is not very verbose by default, and it’s usually not enough to understand what’s happening. The udevadm control –log-priority=info command increases the verbosity level and solves this problem. udevadm control –log-priority=err returns to the default verbosity level.