Anécdotas de virtualización ...

La semana pasada, el servidor de Source Control (Subversion) en donde se encuentran alojados todos los proyectos informáticos de la empresa comienzo a presentar problemas SERIOS de rendimientos. Con problemas serios me refiero a tardar 2 o 3 minutos para realizar un commit de 13 Kbs...


Todo esto comenzó a suceder justo en el momento en el que tres de los proyectos principales se estaban convirtiendo a TAGS ("Estable") y se comenzó a realizar un control mas minucioso de los commits realizados (se realizo lock en el main branch de los mismos). Así que la cosa se puso bastante seria cuando de un momento a otro, el rendimiento de este servidor, que se ha mantenido estable y confiable disminuyo, y en un momento, hasta se pensó que había "tronado", justo como trono el servidor CVS que le antecedía.

Como nunca había visto el dichoso servidor, pues me decidí a buscar en donde se encontraba, así como buscar al responsable del mantenimiento del mismo, o al menos al que había configurado el SubVersion ahí, y realizar la típica sesión de preguntas de novato curioso (de buena intención, pero molestas), y de paso como ya había leido de un problema similar en el servidor SVN del código de KDE, que es al menos, unas 10 veces mayor que el de la empresa, sabia "mas o menos" que decir/mencionar/sugerir para la mejora del problema.
Resulta que el administrador mas inmediato de la maquina es un amigo (RobMV), así que le comente la situación, y mas o menos la conversación se dio similar a esto:

- Mira, el SVN esta lento, podes revisar que sucede?
- Ok veamos... hmmmm, la máquina esta lenta. (Despues de un rato) Ah! tiene menos memoria RAM asignada
- Asignada? - pregunte.
- Si, asignada, es una máquina virtual.
- Ah! Nice! (me brillan los ojos cuando dicen virtual).

Resulta que el servidor REAL (Sun Blade Server con 16 GB, y dos procesadores Intel Xeon de 3 GHz c/u) había pasado recientemente por una "reasignación de recursos" para TODAS (al menos 13) las máquinas virtuales que en el se ejecutan, para mejorar asi el rendimiento de otras máquinas virtuales...


El "Blade", posee 3 niveles de prioridades en las que resuelve o "cede" el uso del procesador para cada máquina virtual. El servidor SVN estaba en la prioridad más baja. Ademas, la memoria RAM del servidor SVN se redujo de 1 GB a 512 MB. Y para colmo el servidor SVN se ejecuta en nada mas y nada menos que Windows 2003 Server.... Ah!!!! con razón esta lento.

La solución inmediata, fue reasignar la prioridad al servidor, a un nivel de prioridad "alto" (nivel de producción), y santo remedio... No digo que no funciono, pero creo que si alguien tiene algun problema similar, existen más opciones para solventar el problema. Creo firmemente, que ese mismo servidor SVN puede ejecutarse perfectamente en esas condiciones, y con mejores resultados que como lo hacia antes.

Mi solución, radical y simple:

quitar Windows 2003 Server y usar un SO especifico para maquinas virtuales.

Si bien Windows 2003 Server, es bastante estable, cualquier experto puede concordar conmigo con que este no es un Sistema Operativo optimizado para ejecutarse como una máquina virtual, ¿entonces para que molestarse en tenerlo instalado en una, y gastar además en su licencia?

Para las máquinas virtuales, siempre hay que usar una regla de oro:

Usa un sistema operativo OPTIMIZADO para máquinas virtuales.

Un PERFECTO ejemplo de esto: Ubuntu Server Edition JeOS (que se pronuncia como jugo en Ingles: "Juice"). Beneficios inmediatos de usar JeOS son:

• Mejor rendimiento en el mismo "hardware" comparado a un sistema operativo completo no optimizado.
• Menos espacio en disco
• Menor cantidad de actualizaciones (mas consolidadas y de mas importancia), lo que reduce la cantidad de mantenimiento del mismo.

Sistemas operativos como Ubuntu Jeos están afinados, de manera que aprovechen el máximo rendimiento de productos como VMware y KVM, lo que se traduce en mas eficiencia para escenarios de virtualización mayores.

"JeOS = núcleo de SO {Kernel, Drives, Login} + Mínimo Mantenimiento + Mínimo "user space tools""

Si la idea es "sacarle" el jugo a los equipos actuales, y mejorar el rendimiento sin incurrir en gastos por la "crisis", entonces hay que hacer conciencia sobre soluciones que usen Software Libre, y ofrecerlo como una opción REALISTA a los problemas informáticos empresariales.

¿En tu trabajo, usan virtualización?

ubuntu jeos ubuntu jeos virtualizacion virtual vmware linux svn subversion

Anécdotas de virtualización ...

La semana pasada, el servidor de Source Control (Subversion) en donde se encuentran alojados todos los proyectos informáticos de la empresa comienzo a presentar problemas SERIOS de rendimientos. Con problemas serios me refiero a tardar 2 o 3 minutos para realizar un commit de 13 Kbs...


Todo esto comenzó a suceder justo en el momento en el que tres de los proyectos principales se estaban convirtiendo a TAGS ("Estable") y se comenzó a realizar un control mas minucioso de los commits realizados (se realizo lock en el main branch de los mismos). Así que la cosa se puso bastante seria cuando de un momento a otro, el rendimiento de este servidor, que se ha mantenido estable y confiable disminuyo, y en un momento, hasta se pensó que había "tronado", justo como trono el servidor CVS que le antecedía.

Como nunca había visto el dichoso servidor, pues me decidí a buscar en donde se encontraba, así como buscar al responsable del mantenimiento del mismo, o al menos al que había configurado el SubVersion ahí, y realizar la típica sesión de preguntas de novato curioso (de buena intención, pero molestas), y de paso como ya había leido de un problema similar en el servidor SVN del código de KDE, que es al menos, unas 10 veces mayor que el de la empresa, sabia "mas o menos" que decir/mencionar/sugerir para la mejora del problema.
Resulta que el administrador mas inmediato de la maquina es un amigo (RobMV), así que le comente la situación, y mas o menos la conversación se dio similar a esto:

- Mira, el SVN esta lento, podes revisar que sucede?
- Ok veamos... hmmmm, la máquina esta lenta. (Despues de un rato) Ah! tiene menos memoria RAM asignada
- Asignada? - pregunte.
- Si, asignada, es una máquina virtual.
- Ah! Nice! (me brillan los ojos cuando dicen virtual).

Resulta que el servidor REAL (Sun Blade Server con 16 GB, y dos procesadores Intel Xeon de 3 GHz c/u) había pasado recientemente por una "reasignación de recursos" para TODAS (al menos 13) las máquinas virtuales que en el se ejecutan, para mejorar asi el rendimiento de otras máquinas virtuales...


El "Blade", posee 3 niveles de prioridades en las que resuelve o "cede" el uso del procesador para cada máquina virtual. El servidor SVN estaba en la prioridad más baja. Ademas, la memoria RAM del servidor SVN se redujo de 1 GB a 512 MB. Y para colmo el servidor SVN se ejecuta en nada mas y nada menos que Windows 2003 Server.... Ah!!!! con razón esta lento.

La solución inmediata, fue reasignar la prioridad al servidor, a un nivel de prioridad "alto" (nivel de producción), y santo remedio... No digo que no funciono, pero creo que si alguien tiene algun problema similar, existen más opciones para solventar el problema. Creo firmemente, que ese mismo servidor SVN puede ejecutarse perfectamente en esas condiciones, y con mejores resultados que como lo hacia antes.

Mi solución, radical y simple:

quitar Windows 2003 Server y usar un SO especifico para maquinas virtuales.

Si bien Windows 2003 Server, es bastante estable, cualquier experto puede concordar conmigo con que este no es un Sistema Operativo optimizado para ejecutarse como una máquina virtual, ¿entonces para que molestarse en tenerlo instalado en una, y gastar además en su licencia?

Para las máquinas virtuales, siempre hay que usar una regla de oro:

Usa un sistema operativo OPTIMIZADO para máquinas virtuales.

Un PERFECTO ejemplo de esto: Ubuntu Server Edition JeOS (que se pronuncia como jugo en Ingles: "Juice"). Beneficios inmediatos de usar JeOS son:

• Mejor rendimiento en el mismo "hardware" comparado a un sistema operativo completo no optimizado.
• Menos espacio en disco
• Menor cantidad de actualizaciones (mas consolidadas y de mas importancia), lo que reduce la cantidad de mantenimiento del mismo.

Sistemas operativos como Ubuntu Jeos están afinados, de manera que aprovechen el máximo rendimiento de productos como VMware y KVM, lo que se traduce en mas eficiencia para escenarios de virtualización mayores.

"JeOS = núcleo de SO {Kernel, Drives, Login} + Mínimo Mantenimiento + Mínimo "user space tools""

Si la idea es "sacarle" el jugo a los equipos actuales, y mejorar el rendimiento sin incurrir en gastos por la "crisis", entonces hay que hacer conciencia sobre soluciones que usen Software Libre, y ofrecerlo como una opción REALISTA a los problemas informáticos empresariales.

¿En tu trabajo, usan virtualización?

ubuntu jeos ubuntu jeos virtualizacion virtual vmware linux svn subversion

Kernel, Almendras, Ventanas y Circulos Viciosos...

En el oscuro y ofuscado mundo de los Sistemas Operativos, un Kernel (también conocido en español como núcleo) es el componente central que se responsabiliza en manejar los recursos del sistema (manejo de memoria por ejemplo) y la comunicación entre el Hardware (parte física de una computadora) y el Software (programas).

Como componente básico de cualquier sistema operativo, un Kernel provee el nivel mas bajo en la capa de abstracción antes de llegar al Hardware... algo mas "abajo" del sistema operativo... son unos y ceros... o cambios voltaje.

La tarea del Kernel es ejecutar procesos (Software, aplicaciones, programas, como le quieran decir) y facilitarles a los mismos la tarea de interacción con el Hardware, mediante la comunicación entre procesos y llamadas al sistema (system calls).

Existen una gran variedad de Kernels: Micro Kernel y Mono Kernel y además esta el ExoKernel, el Kernel Híbrido y el Nano Kernel...

"Macro (Mono), Micro y Exo Kernel... el concepto"

...el diseño y creación de estos obedece usualmente a la implementación de los "anillos de protección". Estos anillos obedecen a un mecanismo que busca proteger datos y funcionalidad: de fallos y de comportamiento malicioso.

Los dos tipos de Kernel más usados son: Micro Kernel y Mono Kernel... y entre ellos existen un sin fin de implementaciones. Esto es como decir que solo existen Negros y Blancos... mentira, hay morenos, mulatos, cheles, chilucos, etc... Lo mismo es con las diversas implementaciones que existen entre el Micro Kernel y el Mono Kernel.

La forma mas fácil de imaginar un Kernel es como una almendra...

"Kernel en ingles, es el centro comestible de una almendra"

Hay que mencionar, que Microsoft decidió omitir esta regla de "anillos de protección" desde Windows 3.x hasta Windows 98. ¿Por qué?... bueno, la comunicación entre los anillos de protección requiere MUCHOS ciclos de procesamiento. Y con Windows siendo un sistema operativo elementalmente visual, Microsoft no tenia mas remedio que ELIMINAR los anillos de protección para mejorar el rendimiento general del sistema. Claro, esto llevo a problemas terribles muy bien conocidos en todos los Windows de la serie 3.x y 9x, como la famosa BSOD (Pantalla Azul).

"Así se vería el Kernel de Windows 98 después de una BSOD"

Ahora la serie de sistemas Windows XP/Vista eliminan (enormemente) este problema implementando en su Kernel los una vez desplazados anillos de protección... que se asemejan mucho con las capas de una cebolla... pero basta de hablar de comida.

El tema del Kernel no sera muy tratado por los usuarios de Windows... pero crean cuando les digo que es un tema muy interesante y elegido como tema de conversación (bueno, ni tanto) por muchos usuarios de GNU\Linux... y no es solo interesante, sino también controversial y ¡extenso!.

Lo "bonito" del Kernel de Linux, es que como es Open Source, todo mundo sabe como funciona y esto permite algunas características muy interesantes a la hora del famoso proceso de "compilación del Kernel".

Compilar el Kernel en un sistema, no se trata de una tarea exclusiva para "geeks", basta con leer un poco y entender la dinámica. Lo que si aburre, es el TIEMPO que tarda en compilarse, y sumado a esto, tener que re-iniciar la maquina para probar el nuevo kernel, y sino funciona, hacer el proceso de nuevo.

Pues para este circulo vicioso, existe un método que simplifica MUCHO las cosas, y además, sirve de ejemplo perfecto de la flexibilidad que presenta el Software Libre.
Este método consiste en la utilización de una maquina virtual para probar nuestro Kernel, y definitivamente NO consiste en copiar el kernel a la maquina virtual y arrancarla o peor aun, compilar el kernel en una maquina virtual, NO NO NO!
Es mucho mejor que eso (y menos tedioso), consiste en arrancar la imagen de un disco duro virtual con un Kernel (el que hemos compilado) EXTERNO a esta maquina virtual.

"Logo de QEmu"

Esta fantástica característica parte de QEMU (QEmu es un emulador de computadoras virtuales), se llama "Direct Linux Boot":

"Captura de pantalla de Qemu Laucher con Direct Linux Boot habilitado"

Direct Linux Boot, permite ahorrar tiempo de una manera increíble, al evitar estar re-iniciando la maquina constantemente y evitando el infame "Kernel Panic".

"Captura de pantalla de Direct Linux Boot con Kernel EXTERNO 2.6.21rac
Click para hacerlo más grande"

En el transcurso de la semana escribo un tutorial sobre como compilar y probar un Kernel usando QEMU.

Hasta Luego!

Kernel, Almendras, Ventanas y Circulos Viciosos...

En el oscuro y ofuscado mundo de los Sistemas Operativos, un Kernel (también conocido en español como núcleo) es el componente central que se responsabiliza en manejar los recursos del sistema (manejo de memoria por ejemplo) y la comunicación entre el Hardware (parte física de una computadora) y el Software (programas).

Como componente básico de cualquier sistema operativo, un Kernel provee el nivel mas bajo en la capa de abstracción antes de llegar al Hardware... algo mas "abajo" del sistema operativo... son unos y ceros... o cambios voltaje.

La tarea del Kernel es ejecutar procesos (Software, aplicaciones, programas, como le quieran decir) y facilitarles a los mismos la tarea de interacción con el Hardware, mediante la comunicación entre procesos y llamadas al sistema (system calls).

Existen una gran variedad de Kernels: Micro Kernel y Mono Kernel y además esta el ExoKernel, el Kernel Híbrido y el Nano Kernel...

"Macro (Mono), Micro y Exo Kernel... el concepto"

...el diseño y creación de estos obedece usualmente a la implementación de los "anillos de protección". Estos anillos obedecen a un mecanismo que busca proteger datos y funcionalidad: de fallos y de comportamiento malicioso.

Los dos tipos de Kernel más usados son: Micro Kernel y Mono Kernel... y entre ellos existen un sin fin de implementaciones. Esto es como decir que solo existen Negros y Blancos... mentira, hay morenos, mulatos, cheles, chilucos, etc... Lo mismo es con las diversas implementaciones que existen entre el Micro Kernel y el Mono Kernel.

La forma mas fácil de imaginar un Kernel es como una almendra...

"Kernel en ingles, es el centro comestible de una almendra"

Hay que mencionar, que Microsoft decidió omitir esta regla de "anillos de protección" desde Windows 3.x hasta Windows 98. ¿Por qué?... bueno, la comunicación entre los anillos de protección requiere MUCHOS ciclos de procesamiento. Y con Windows siendo un sistema operativo elementalmente visual, Microsoft no tenia mas remedio que ELIMINAR los anillos de protección para mejorar el rendimiento general del sistema. Claro, esto llevo a problemas terribles muy bien conocidos en todos los Windows de la serie 3.x y 9x, como la famosa BSOD (Pantalla Azul).

"Así se vería el Kernel de Windows 98 después de una BSOD"

Ahora la serie de sistemas Windows XP/Vista eliminan (enormemente) este problema implementando en su Kernel los una vez desplazados anillos de protección... que se asemejan mucho con las capas de una cebolla... pero basta de hablar de comida.

El tema del Kernel no sera muy tratado por los usuarios de Windows... pero crean cuando les digo que es un tema muy interesante y elegido como tema de conversación (bueno, ni tanto) por muchos usuarios de GNU\Linux... y no es solo interesante, sino también controversial y ¡extenso!.

Lo "bonito" del Kernel de Linux, es que como es Open Source, todo mundo sabe como funciona y esto permite algunas características muy interesantes a la hora del famoso proceso de "compilación del Kernel".

Compilar el Kernel en un sistema, no se trata de una tarea exclusiva para "geeks", basta con leer un poco y entender la dinámica. Lo que si aburre, es el TIEMPO que tarda en compilarse, y sumado a esto, tener que re-iniciar la maquina para probar el nuevo kernel, y sino funciona, hacer el proceso de nuevo.

Pues para este circulo vicioso, existe un método que simplifica MUCHO las cosas, y además, sirve de ejemplo perfecto de la flexibilidad que presenta el Software Libre.
Este método consiste en la utilización de una maquina virtual para probar nuestro Kernel, y definitivamente NO consiste en copiar el kernel a la maquina virtual y arrancarla o peor aun, compilar el kernel en una maquina virtual, NO NO NO!
Es mucho mejor que eso (y menos tedioso), consiste en arrancar la imagen de un disco duro virtual con un Kernel (el que hemos compilado) EXTERNO a esta maquina virtual.

"Logo de QEmu"

Esta fantástica característica parte de QEMU (QEmu es un emulador de computadoras virtuales), se llama "Direct Linux Boot":

"Captura de pantalla de Qemu Laucher con Direct Linux Boot habilitado"

Direct Linux Boot, permite ahorrar tiempo de una manera increíble, al evitar estar re-iniciando la maquina constantemente y evitando el infame "Kernel Panic".

"Captura de pantalla de Direct Linux Boot con Kernel EXTERNO 2.6.21rac
Click para hacerlo más grande"

En el transcurso de la semana escribo un tutorial sobre como compilar y probar un Kernel usando QEMU.

Hasta Luego!