viernes, 30 de noviembre de 2012

Tarjetas de video híbridas

Mi ordenador es un samsung RC512 tiene instalado debian squeeze y el siguiente kernel:
Linux usuario 2.6.32-5-amd64 #1 SMP Sun Sep 23 10:07:46 UTC 2012 x86_64 GNU/Linux

El hardware tiene las siguientes características:

00:00.0 Host bridge: Intel Corporation Sandy Bridge DRAM Controller (rev 09)
00:01.0 PCI bridge: Intel Corporation Sandy Bridge PCI Express Root Port (rev 09)
00:02.0 VGA compatible controller: Intel Corporation Sandy Bridge Integrated Graphics Controller (rev 09)
00:16.0 Communication controller: Intel Corporation Cougar Point HECI Controller #1 (rev 04)
00:1a.0 USB Controller: Intel Corporation Cougar Point USB Enhanced Host Controller #2 (rev 04)
00:1b.0 Audio device: Intel Corporation Cougar Point High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation Cougar Point PCI Express Root Port 1 (rev b4)
00:1c.3 PCI bridge: Intel Corporation Cougar Point PCI Express Root Port 4 (rev b4)
00:1c.4 PCI bridge: Intel Corporation Cougar Point PCI Express Root Port 5 (rev b4)
00:1d.0 USB Controller: Intel Corporation Cougar Point USB Enhanced Host Controller #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation Cougar Point LPC Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation Cougar Point 6 port SATA AHCI Controller (rev 04)
00:1f.3 SMBus: Intel Corporation Cougar Point SMBus Controller (rev 04)
01:00.0 3D controller: nVidia Corporation Device 0dec (rev a1)
02:00.0 Network controller: Intel Corporation Centrino Advanced-N + WiMAX 6250 (rev 5f)
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06)
04:00.0 USB Controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04)

Como se puede observar se pueden ver las dos tarjetas de video:

00:02.0 VGA compatible controller: Intel Corporation Sandy Bridge Integrated Graphics Controller (rev 09)
01:00.0 3D controller: nVidia Corporation Device 0dec (rev a1)

Desde que instalé debian 6, estuve luchando por querer setear NVidia como mi tarjeta principal, al cabo de unos pocos intentos e indagación me di cuenta sobre el funcionamiento de video híbrido que poseia mi maquina. Cuando reinstale windows note que al intentar instalar el driver NVidia el mismo driver me pidió instalar el driver Intel primero ya que no encontraba hardware NVidia alguno en el ordenador, así que procedí a instalar el controlador Intel y luego volví a instalar NVidia y funcionó exitosamente. Así que al instalar GNU/Linux procedí de la misma forma y exitosamente logre instalar Intel y NVidia, solo que había un problema, Probando con OpenSUSE ya que decidí probar como levantaba otra distribución me seteaba exitosamente NVidia como principal sin embargo el GPU por ser el principal consumia mucho recurso de energia y el fan trabajaba como loco, en Debian al usar la Intel mis recursos de hardware funcionan con mejor desempeño, lo cual me pareció perfecto.

Una vez definido el problema, decidí quedarme con Debian claro, ya que OpenSUSE solo era mero estudio y prueba, me despreocupe con la idea de que no estaba trabajando mi video correctamente, solo me quedaba la duda de como usar la tarjeta de video NVidia, así que me dí la tarea de investigar sobre como usar la segunda tarjeta de video y descubrí que para linux esto se llama proceso híbrido y encontré la siguiente página que resolvió mis dudas y mi problema:

https://wiki.debian.org/Bumblebee

El proyecto Bumblebee tiene como objetivo usar las tarjetas de video NVidia para renderizar y mostrar el resultado a travez de la Intel, la solución perfecta de mi problema ahora ya tengo habilitadas mis dos tarjetas de video, pero solo uso la Intel como principal y ejecuto los programas pesados con NVidia.

:wq

lunes, 19 de noviembre de 2012

Cluster de alto desempeño

Bueno y que pasa con el alto desempeño, investigando un poco y entrando en el mundo de los clusters, me fascino el tema de cluster Beowulf, tanto que me hacia la idea de tener un super computador, sin embargo la idea inicial que tenía es muy distinta a la idea que tuve al terminar de leer sobre el tema y sucede que para crear un cluster de alto desempeño generalmente es para fines determinados y aplicaciones únicas compiladas para trabajar especialmente en ese cluster.

Mi idea es crear un cluster donde los procesos sean distribuidos en todo el nodo, no para dar mayor velocidad si no capacidad al servicio para realizar cantidades de tareas teniendo hardware que no sería capaz de cumplir dicha tarea por si solo pero unido tenga la capacidad de un supercomputador.

Por lo tanto mi idea y mi objetivo es la creación de un cluster donde un proceso P ejecutandose en el nodo pueda ser ejecutado en uno u otro servidor, es decir que pueda ser migrado y ejecutado en otro servidor si el servidor que ejecuto el proceso esta ocupado.

Durante la investigación descubrí dos paqueterias que realizan la magia para hacer un cluster de alto desempeño estos paquetes son PVM y MPI, al leer sobre ambos, me despeje muchas de las dudas e inquietudes que tenia y a la vez se me cayo la idea del proyecto que pretendía montar, descubrí que ambas herramientas son poderosas sin embargo funcionan con programas que deben de incluir dichas librerias, por lo tanto son para fines específicos y no generales.

Mi idea es usar un cluster de alto desempeño para fines generales y no específicos  orientado al desempeño y capacidad para procesar trabajos en el nodo y no necesariamente orientado a su velocidad de respuesta.

Descubrí trucos y métodos para crear clusters de aplicaciones colocando un proxy en medio o maquina maestra encargada de dar acceso por turnos a cada una de las maquinas internas del nodo así cliente1 solicita un proceso P1 al servicio S el cual seria servido por maquina1, luego cliente2 solicita un proceso P2 al servicio S el cual seria servido por maquina2 si el cluster o nodo de clusters solo cuenta de dos maquinas entonces el cliente3 solcita un proceso P3 y seria servido por maquina1 y asi sucesivamente, mas sin embargo esta solución plantea que cada cluster es una maquina independiente con un nfs para sincronizar y tener la misma información sin embargo cada una usaría recursos independiente llevaría un problema adicional que es el acceso de los datos desde dos lugares distintos, esto podría conllevar a datos corruptos en paginas dinámicas en caso que el cluster sea un servicio web, claro esta que soluciona el load balancing de una forma rústica sin embargo de forma muy interesante.

Sin embargo este no era mi objetivo así que procedí a seguir investigando y abandone la idea de usar la filosofía de un cluster Beowulf para propósitos generales, generalmente descubrí que muchos de los servicios  en la internet hablan mas de balanceo que potencia para solventar el problema. Es decir que no es necesario que un servicio de base de datos tanga mayor potencia si el problema se soluciona mediante balanceo y el alto desempeño para procesamiento de cálculos. Por lo tanto he decidido crear otro post a futuro tratando sobre como crear balanceadores de carga y hablar sobre el tema.

Es así entonces que descubrí los paquetes PVM y MPI, generalmente ambos me parecen genial, sin embargo tienen sus pros y sus contras, el PVM es mas abstracto y el MPI mas detallado, por lo tanto el PVM no se necesita conocer como realiza el traslado de los procesos en cambio en el MPI si se requiere conocer como se realiza, esto conlleva que el MPI es más flexible y mas transparente que el PVM y por otro lado el PVM ofrece mayores herramientas para monitoreo y control que MPI, MPI por su lado no posee herramientas de control ni monitoreo pero ofrece a bajo nivel control total de como realizará y cuando realizar el traslado de los procesos a los demás nodos y como hacerlo.

Estuve pensando y esto es muy útil cuando se desea crear un supercomputador que realice cálculos estadísticos enormes. Y tocando este tema de supercomputadores, entre al tema del grid computing, otro tema del cual pienso hablar más tarde.

En mi caso por motivos de desarrollo y aprendizaje me fue muy útil crear clusters mediante PVM y MPI sin embargo por ahora desarrollar en c++ usando estas librerías no me es de utilidad sin embargo es un tema muy interesante ver como un proceso que requiere mucho tiempo procesarse en un solo ordenador en un cluster con varias virtuales toma quizás un cuarto de tiempo algo muy interesante. De ahí vino la idea de procesar servicios con estas dos librerías sin embargo es muy razonable el por que no es necesario procesos ni servicios más rápidos si no mas bien de como pueden ser servidos en un nodo de ordenadores sin provocar sobrecarga alguna.

Una nube en el horizonte

Pongámonos del lado de un usuario de la informática de una empresa, cuando hablamos como usuario vamos desde la recepcionista hasta el gerente, e incluso nosotros mismos como administradores, soporte técnico o jefes de IT.

Vemos como la empresa y sus servicios crecen por lo tanto también el contenido de información que cada usuario produce. Esto nos produce un dilema, "¿Cómo manejar y controlar de forma segura toda esa información?", es donde entraremos con el tema de la nube, cuando surgió la nube trajo grandes respuestas y soluciones, esto permitió que toda la información sin importar que pase con el hardware, la información permanezca en un solo sitio, sin embargo trajo nuevos retos, primero acostumbrar al usuario a usar las nuevas plataformas y acostumbrar a explicarle del por que es mejor tener algo en la nube y no en su equipo local, el usuario no se mueve a la nube si no hasta después de perder la información ya sea a causa de robo o fallo en el hardware local, por mucho que se le explique a un usuario que su sistema local puede fallar, este no se moverá por comodidad de no aprender algo nuevo o tener que hacer algo extra para guardar su información o por el contrario el usuario está consiente de los problemas que conlleva tener todo local esta decidido a moverse a la nube sin embargo no puede por problemas de ancho de banda y tiempo que toma en recuperar o almacenar uno o mas datos de su ordenador local a la nube.

Ahora que más o menos hemos introducido un poco del problema puede que se nos formule una o más de las siguientes preguntas:
1.- Si me muevo hoy a la nube ¿Puedo acceder a esa información siempre de forma fácil y rápida?
2.- ¿El país esta listo y preparado para movernos a la nube?
3.- ¿Tengo tiempo para mover toda mi insfraestructura?
4.- ¿Haré una migración total, parcial o híbrida?
5.- ¿Puedo realizar esa inversión?

Para empezar con el problema de nuestro país y que el internet es como agua en el desierto, por lo tanto hay que realizar un buen estudio para que la solución de un problema no cause otro, se supone que necesitamos solucionar un problema y no crear otro, por lo tanto necesitamos atacar el problema de dos formas, en la empresa tenemos distintos tipos de usuarios, los fijos y los moviles, los fijos pueden gozar de la nube a su total cabalidad ya que gozan del ancho de banda local de nuestra LAN, en cambio los usuarios móviles lo disfrutarán a tiempo parcial o casi a cuenta de gotas ya que si andan fuera de la empresa tendrán que luchar con el acceso que poseen dependiendo del lugar en el que se encuentren, por lo tanto pueden usar acceso de internet movil sin embargo estarán limitados al ancho de banda y si el servicio tiene o no cobertura, por lo tanto tendran limitancia al servicio que ofrezca el ISP, por lo que los usuarios fijos pueden tener una migración total hacia la nube en cambio los usuarios móviles tienen como mejor solución usar la nube de forma híbrida, manejar sus datos locales y usar la nube como backup y sincronización solo cuando su ancho de banda sea lo suficiente bueno como para realizar la sincronización.

Por ahora hemos solucionado parte del problema, sin embargo se formula otro, "¿Donde debemos de tener la nube?", aquí entran a jugar una palabrita que hace que la empresa tome una decisión respecto a donde debe de tener la nube ya sea local o en la internet, la palabrita mágica que hace que todo se mueva que es "costo", cuanto cuesta tenerla la nube local o en la internet, podemos adivinar que es más costoso tener una nube local que tenerla fuera, sin embargo tiene muchos beneficios tenerla local solo si se cuenta con el personal informático dedicado y especializado en el tema y si se requiere mejores tiempos de respuesta ya que se trabaja con ancho de banda propio, en cambio si se opta por trabajar con nubes en la internet se depende del ancho de banda de la empresa por lo tanto el servicio es un poco mas lento sin embargo es mucho mas económico. 

La nube aun esta lejos en el horizonte pero poco a poco es una tecnología que toca las puertas de las empresas que necesitan proteger su información en momentos de perdidas por robos o fallos de hardware.

Generando un cluster de alta disponibilidad


Esta vez estuve trabajando con clusters, me vi forzado a investigar como desarrollar un cluster de alta disponibilidad con heartbeat, ultimamente ya no trabajo con OpenSuse, creo haberlo mencionado en uno de los posts anteriores y decidi trabajar con Debian por su alto desempeño y estabilidad de la cual e quedado maravillado.

Un cluster en resumidas cuentas no es nada mas que un conjunto de ordenadores en red que funcionan como uno solo ya sea para evitar problemas de fallos o para hacer que todos los ordenadores trabajen como uno solo sumarizando sus recursos y realizar calculos enormes que un solo ordenador no podria realizar.

Empezaremos el desarrollo con heartbeat, este es HA (High Availability). Antes de continuar cabe mencionar que debian ya tiene este paquete en su repositorio solo basta con instalar y listo no hay que hacer mucho pero como siempre me gusta hacer las cosas desde cero y para los que les gusta hacerlo así, este post les gustará

Hay varias razones del por que usar un paquete de debian y otras muchas razones del por que hacerlo desde cero, esto va en dependencia de la necesidad de cada quien, ultimamente me agrada mas trabajar con la paqueteria de debian que compilar paquetes, sin embargo siempre es interesante hacerlo por ambas formas siempre hay algo nuevo que aprender:

Empezaremos instalando todos los paquetes necesarios para la compilacion, hago mencion que esto fue realizado con un servidor usando debian squeeze, hago mencionar que es 64 bits y es la arquitectura de mi preferencia x86 ya la considero obsoleta o al menos ya no veo en mi campo ese tipo de hardware.

Los siguientes pasos son complementarios para realizar la instalación de heartbeat, antes de realizar estos pasos favor leer:
http://www.linux-ha.org/doc/users-guide/users-guide.html

Los pasos de la instalación se muestran en el siguiente link:
http://www.linux-ha.org/doc/users-guide/_building_and_installing_from_source.html

Antes de proceder recomiendo que lean muy bien el users guide, pero como se que muchos no lo harán no haré un paso a pass ya que no pretendo copiar y pegar algo que ya esta hecho por que el objetivo no es duplicar lo que ya está, sino solo anexar o complementar, por lo tanto aquí me salto los pasos que se suponen descargas los paquetes, recomiendo que lean bien la guía y anexar lo que muestro aquí.

1) Instalamos la paquetería:
apt-get install hgsvn uuid-dev build-essential flex bison libsnmp-dev openipmi python autoconf libtool xsltproc libextutils-pkgconfig-perl libglib2.0-dev libxml2-dev libbz2-dev

2) Primero empezamos instalando algo que se llama Cluster Glue, entonces primero descargamos el tar, ya sea el ultimo release (Desarrollo) o el mas estable, yo obte por el estable. (Ver y leer el link de la guia de usuario)

3) Descargamos el paquete cluster-glue
http://www.linux-ha.org/doc/users-guide/_building_and_installing_from_source.html#_downloading_cluster_glue_sources

4) Antes de proceder a compilar descargar el patch para el cluster-glue, ya que sin este patch dará un error que no permitirá compilarlo completamente por un error de tipos de variables:

cat > /gatomic.h.patch << "EOF"
--- /usr/include/glib-2.0/glib/gatomic.h.orig   2010-04-14 18:16:59.853768126 +0000
+++ /usr/include/glib-2.0/glib/gatomic.h        2010-04-14 18:17:39.409810040 +0000
@@ -64,16 +64,16 @@
 #else
 # define g_atomic_int_get(atomic) \
  ((void) sizeof (gchar [sizeof (*(atomic)) == sizeof (gint) ? 1 : -1]), \
-  (g_atomic_int_get) ((volatile gint G_GNUC_MAY_ALIAS *) (void *) (atomic)))
+  (g_atomic_int_get) ((volatile gint G_GNUC_MAY_ALIAS *) (volatile void *) (atomic)))
 # define g_atomic_int_set(atomic, newval) \
  ((void) sizeof (gchar [sizeof (*(atomic)) == sizeof (gint) ? 1 : -1]), \
-  (g_atomic_int_set) ((volatile gint G_GNUC_MAY_ALIAS *) (void *) (atomic), (newval)))
+  (g_atomic_int_set) ((volatile gint G_GNUC_MAY_ALIAS *) (volatile void *) (atomic), (newval)))
 # define g_atomic_pointer_get(atomic) \
  ((void) sizeof (gchar [sizeof (*(atomic)) == sizeof (gpointer) ? 1 : -1]), \
-  (g_atomic_pointer_get) ((volatile gpointer G_GNUC_MAY_ALIAS *) (void *) (atomic)))
+  (g_atomic_pointer_get) ((volatile gpointer G_GNUC_MAY_ALIAS *) (volatile void *) (atomic)))
 # define g_atomic_pointer_set(atomic, newval) \
  ((void) sizeof (gchar [sizeof (*(atomic)) == sizeof (gpointer) ? 1 : -1]), \
-  (g_atomic_pointer_set) ((volatile gpointer G_GNUC_MAY_ALIAS *) (void *) (atomic), (newval)))
+  (g_atomic_pointer_set) ((volatile gpointer G_GNUC_MAY_ALIAS *) (volatile void *) (atomic), (newval)))
 #endif /* G_ATOMIC_OP_MEMORY_BARRIER_NEEDED */

#define g_atomic_int_inc(atomic) (g_atomic_int_add ((atomic), 1))
EOF

3) No olvidemos agregar el grupo haclient y el usuario hacluster:
groupadd haclient
useradd -g haclient hacluster

4) Compilamos e instalamos
http://www.linux-ha.org/doc/users-guide/_building_and_installing_from_source.html#_building_cluster_glue

5) Descargamos el heartbeat
http://www.linux-ha.org/doc/users-guide/_building_and_installing_heartbeat_from_source.html#_downloading_heartbeat_sources

6) Compilamos e instalamos el paquete
http://www.linux-ha.org/doc/users-guide/_building_and_installing_heartbeat_from_source.html#_building_heartbeat

Listo ya tenemos instalado heartbeat desde cero sin embargo ahora veamos como sería instalarlo a la manera de debian:

# aptitude install heartbeat cluster-glue cluster-agents pacemaker

Como vemos depende de la necesidad de cada quien, ambos métodos de instalación funcionan pero quizás mas de algún usuario vea útil ver que opciones de compilación permite cada paquete.

De vista al futuro

Mas de una que otra vez siempre escucho hablar opiniones sobre la virtualización, muchas opiniones son buenas pero siempre escucho que llevan piedras, la realidad es que la virtualización ya llegó, sin embargo el problema es el miedo al cambio, e intentan dar mil argumentos del por que preferir hardware físico y no virtual.

Para empezar la virtualización inicia con varios propósitos y necesidades, buscando hacer uso de mayor cantidad de ordenadores en menos equipos físicos, ahorrando energía, espacio y costos, y obteniendo mejores resultados económicos.

Actualmente la virtualización a mejorado tanto que se pueden crear ordenadores virtuales con características identicas a uno real. Se pueden virtualizar ordenadores con capacidades de un pentium I a 500MHz y con 256 ram, lo suficiente para correr aplicaciones tan personalizadas en el hardware necesario sin desutilizar el hardware y aprovecharlo para otras tareas en otras maquinas con mayor capacidad.

Así ordenadores con grandes capacidades pueden poseer cientos de maquinas virtuales con distintas características y propiedades. La virtualización a sido también de muy buena ayuda para crear en el área de los desarrolladores laboratorios que replican un ambiente de producción y que permitan realizar pruebas sin afectar lo ya existente, tanto en el ambiente de producción como de desarrollo la virtualización a tomado un gran espacio y mercado.

La verdad es que la virtualización a llegado para quedarse y es el nuevo futuro, actualmente ya no solo se habla de virtualizar servicios y servidores si no que ahora se habla de virtualizar los mismos escritorios personales a lo que ahora se le ha llamado VDI (Virtual desktop infrastructure), quien aun teme a la virtualización queda atrás es como negar lo que ya está, para empezar que servicio que usemos no está virtual, si el mismo correo gratuito personal es un servicio que correo en un servidor virtual. Muchas páginas corren en servidores virtuales.

Claro quien no querría tener su propio server y poder obtener una propia imagen que puede ser levantada en minutos en otro lugar sin necesidad de reconfigurar solo trasladar la imagen y listo. Servidores físicos no permiten eso, para una exportación se requiere tener dos servidores con el mismo Sistema Operativos, mismos paquetes y la migración no es algo que cualquiera puede hacer, se requiere al menos un conocimiento de todo el servicio y ajustes personales de la aplicación. En cambio con la virtualización adiós a todo eso, el jefe de IT solo necesita tomar la imagen, moverla y arrancarla desde el nuevo destino y listo.

Lo que generalmente uno escucha de muchos del por que no optan por la virtualización es por uno o varios de los siguientes tabues:
* El hardware no es físico y no es lo mismo.
* Con el virtual no tengo el mismo desempeño.
* Miedo a la seguridad y la información que por que esta virtual no existe y no es igual.
* Si es virtual no puedo verlo.
* No se puede crear redes de maquinas con la virtualización, por que no puedo verlas físicamente, no puedo hacer el mapa de red.

Todas estas dudas y miedos y tabues, solo son temores por entrar a lo desconocido y aprender lo nuevo, ya no es verdad que por que algo virtual no tiene el mismo desempeño que algo real ya que existen tantos métodos de virtualización que uno escoge el que mejor calza con la necesidad que uno busco, hay virtualizaciones que funcionan para sacar el mejor desempeño del hardware existen otras que hacen su tarea aunque a un costo de desempeño o velocidad, sin embargo todo esto depende de la necesidad y fin por el cual uno necesita virtualizar uno o mas servicios.

Ya habíamos hablado de los distintos métodos de virtualización (http://gnu-linux-opensource.blogspot.com/2009/06/linux-y-la-virtualizacion.html), existen virtualizaciones que virtualizan todo el hardware, otras que semivirtualizan el hardware y otras que no virtualizan el hardware y solo crean ambientes enjaulados. Cada una de estas virtualizaciones funcionan para un fin y una necesidad unas tienen mejores ventajas que otras pero cada una tiene su desventaja con respecto a otra, algunas requiren mayor trabajo para configurar y mayor o menor tiempo para su afinamiento, sin embargo todas cumplen su tarea y su trabajo de acuerdo a lo deseado.

Al final es decisón de uno quedarse atrás o dar un paso hacia adelante hacia el progreso. Virtualización ¿por que nó?