Cisco Discovery Protocol, ese gran desconocido 
domingo, octubre 23, 2011, 12:43 PM - Tecnología


Todos los que nos dedicamos a sistemas nos hemos encontrado alguna vez con el problema de tener que seguir un cable a través de una maraña para saber a qué puerto del conmutador está conectado.

Como yo soy de "dedos porruos" me puse a buscar una manera de solucionar esto por software en vez de por hardware. Y aquí es donde entra en juego el Cisco Discovery Protocol

Los que usamos vmware vsphere podemos ver en la configuración de las vmnics en los vswitches en qué puertos están conectados, en el campo "Port Id"





En el caso de que sea una máquina Unix/Linux física, podemos usar la herramienta cdpr para saber en qué puerto del conmutador está conectado un interfaz de red.
[root@mimaquina~]# cdpr -d eth1
cdpr - Cisco Discovery Protocol Reporter
Version 2.4
Copyright (c) 2002-2010 - MonkeyMental.com

Using Device: eth1
Waiting for CDP advertisement:
(default config is to transmit CDP packets every 60 seconds)
Device ID
  value:  correo1
Addresses
  value:  192.168.6.151
Port ID
  value:  GigabitEthernet2/0/41
¿Alguien sabe si hay algún protocolo similar para conmutadores HP Procurve?



[ 81 comentarios ] ( 7973 visualizaciones )   |  [ 0 trackbacks ]   |  enlace permanente  |   ( 3 / 515 )
Artículo introductorio: IOPs, los grandes olvidados en la virtualización 
sábado, octubre 15, 2011, 05:18 PM - Tecnología


El otro día estaba hablando con un amigo que había empezado la aventura de montar su propia empresa relacionada con la TI. Me contaba que se había comprado un potente servidor y que iba a virtualizar sus entornos de desarrollo y producción sobre este sistema, 5-6 máquinas virtuales Linux y 1-2 windows server, y tal vez un par de windows 7 para probar las aplicaciones web con Internet Explorer.

Pregunté por las características hardware del servidor y parecían más que suficientes para esas necesidades: 8 cores Xeon, 64 gigabytes de ram, raid integrado, fuentes redundantes... hasta que llegó a la parte de almacenamiento: dos discos internos SATA de 2 TB cada uno

Le pregunté qué cosas iba a lanzar en sus máquinas virtuales, y me hablaba de pruebas de integración continua (compliaciones incluidas), pequeñas / medianas bases de datos mysql/postgresql, un proxy http para los ordenadores de la oficina, un servidor de ficheros, un pequeño gestor documental y algunos servidores web de prueba /wiki.

Había algo que no me cuadraba: tenía potencia de cálculo de sobra, tenía memoria ram de sobra, y le sobraba mucho espacio en disco (ocupaba apenas 100-120 GB del RAID 1 de 2 TB). Y así se lo dije: te has equivocado al elegir el almacenamiento.

¿Y por qué se había equivocado? Pues porque no tenía un sistema equilibrado. El número de IOPs (operaciones de entrada/salida) que dan esos dos discos SATA en raid1 es muy escaso. Tal vez 90-100 IOPs, insuficientes para la carga que iban a provocar esas máquinas virtuales.

¿Y cuál es la solución? Pues si el presupuesto lo permite, lo siguiente:

- Elegir una controladora de disco con al menos 512 MB de caché y batería de caché (BBU), para así poder tener escrituras asíncronas. Esto puede mejorar un 30-40% la E/S independientemente del tipo de discos que se elijan.

- Poner discos con un número elevado de IOPs/Terabytes, eligiendo SAS antes que SATA y a la mayor velocidad de giro que podamos permitirnos (10.000 o 15.000 rpm)

- Procurar poner la mayor cantidad de ejes posibles: Desde el punto de vista de IOPs, es mucho mejor poner 4 discos de 146 GB en raid 1+0 antes que un raid1 de dos discos de 300 GB.

- Por último, si las necesidades de E/S son realmente elevadas, y el espacio en disco que necesitamos es pequeño, elegir tecnología SSD, que da un número de IOPs tremendo.

Parafraseando a Seymoure Cray, es sencillo hacer un procesador rápido. Lo difícil es hacer un sistema rápido.



[ 58 comentarios ] ( 1863 visualizaciones )   |  [ 0 trackbacks ]   |  enlace permanente  |   ( 3.3 / 670 )
7200 rpm: mejor SAS MDL que SATA 
sábado, octubre 15, 2011, 04:56 PM - Tecnología, Opinión


Impresionante artículo de Ian Vogelesang en este blog de Hitachi Data Systems. Largo pero de lectura obligada si en vuestro trabajo gestionáis algún sistema de almacenamiento.

Yo ya había medido que el número de IOPS en un disco SAS de 7.200 rpm es 30-40% mayor que en un disco SATA a las mismas revoluciones, pero hasta leer este artículo se lo achacaba sencillamente al TCQ de SAS, pero veo que hay más cosas a tener en cuenta.

En resumen: SATA para una conexión DAS "punto a punto". Para meter muchos discos SATA en un array o JBOD es mucho mejor idea usar SAS MDL. La gran mayoría de controladoras RAID (como la serie P4XX de las Smart Array de HP) soportan indistintamente discos SAS o SATA.

Por tanto, un disco SAS MDL a 7.200 rpm es más eficiente que su homólogo SATA girando a las mismas revoluciones. ¿Y qué diferencia hay de precio? Pues veamos en la web de HP:

Precio de un disco SATA de 7.200 rpm y 3 TB: 630 € + IVA precio en la web de HP

Precio de un disco SAS MDL de 7.200 rpm y 3 TB: 660 € + IVA precio en la web de HP

30 € de diferencia por un 30% más de rendimiento y por interfaz 6G en vez de un 3G, un 5% de diferencia respecto al precio total, así que está claro: si necesitáis mucho espacio para un servidor NAS/ servidor de backup / VTL, elegid discos SAS MDL antes que sus equivalentes SATA, y en cualquier caso, aseguraos que el rendimeiento de entrada/salida que necesitáis se cumple con discos de tan baja relación de IOPs/terabyte.

Gufete



[ 95 comentarios ] ( 4185 visualizaciones )   |  [ 0 trackbacks ]   |  enlace permanente  |   ( 3 / 177 )
zpaq: cuando el tamaño importa 
domingo, octubre 9, 2011, 02:18 PM - GNU/Linux, Tecnología


Donde trabajo tenemos un Apache que genera casi un giga de log diario. Tenemos puesto en el logrotate que en vez de usar gzip se use xz como compresor, y nos ahorramos bastante espacio en disco con esta configuración

Hoy he hecho un experimiento: coger un fichero ssl_access.log de 915 Megabytes y probar con distintos compresores, este es el resultado.

gzip -9: 61 megabytes , 20 segundos ( usando 1 core Xeon i7 X5560@2.8ghz )
pbzip2 -9: 32 megabytes ,94 segundos ( usando 4 cores Xeon i7 X5560@2.8ghz )
xz -9: 35 megabytes , 180 segundos ( usando 1 core Xeon i7 X5560@2.8ghz )
zpaq -m1: 23 megabytes , 44 segundos ( usando 4 cores Xeon i7 X5560@2.8ghz)
zpaq -m4: 16 megabytes , 3064 segundos ( usando 1 core Xeon i7 X5560@2.8ghz )


Al final el ganador ha sido zpaq, que me ha sorprendido gratamente con el parámetro -m1, que comprime más que xz y pbzip2 y tarda realmente poco. Me voy a entrener en hacer un paquete RPM, por si a alguien le interesa.

[ 143 comentarios ] ( 15432 visualizaciones )   |  [ 0 trackbacks ]   |  enlace permanente  |   ( 3 / 950 )
Dos imágenes 
sábado, julio 23, 2011, 04:58 PM - Yo mismo
Que valen más que 2.000 palabras :)

Con un F-14 Tomcat en el USS Intrepid



Autodescriptiva:





[ 71 comentarios ] ( 2156 visualizaciones )   |  [ 0 trackbacks ]   |  enlace permanente  |   ( 3 / 1195 )
La Policia me ha hecho un regalo (Carta abierta de David Benavides) 
viernes, mayo 27, 2011, 10:42 AM - Opinión
Gracias Agentes. Gracias a los más agresivos. Gracias a los que me habéis dejado el brazo magullado, torcido y con hematomas. Gracias por vuestra fuerza al arrestarme y arrastrarme. Gracias por vuestros insultos y vejaciones. Gracias por el sudor en el coche durante la detención por falta de aire acondicionado. Gracias por llevarme al médico esposado.

Gracias a aquél agente que al estar detenido me ha llamado payaso, sinvergüenza y otros mal sonantes insultos y que al rogarle educadamente que por favor no se excediera de sus funciones y no me insultara, contestó diciendo que él hacía lo que le salía de sus genitales. Gracias por eso y mucho más porque de eso he aprendido mucho. He aprendido que si eres Profesor Titular y tienes impacto mediático te sueltan en tres horas. Que hay funcionarios amables y correctos y hay algunos, lamentablemente con cierta complacencia por los otros, que se exceden de sus funciones, no miden sus actos, persiguen a discreción y maltratan.

Lo del día 24 de Mayo ha sido una anécdota para mí. Quiero huir del victimismo y sé que, aunque me duele mucho, aunque he pasado momentos de mucha ansiedad que van y vienen o aunque esta carta tengo que escribirla usando los dedos de mi compañera porque no puedo sentarme al ordenador, lo que yo he vivido es poco comparado con el sufrimiento de tantos. Aquellos que no tienen impacto mediático, aquellos que ignoran sus derechos o simplemente no los tienen.

Mis agradecimientos se multiplican porque he recibido un baño de afecto que me durará mucho tiempo. De todas partes, de todos los matices: mi barrio, mi alumnado, mi grupo de investigación, mis colegas de trabajo de aquí y del extranjero, mi Escuela, mi Universidad, el AMPA del colegio de mi hijo, mis compañeros, mis amigos, mi familia.

La Policía me ha hecho un regalo porque me ha enseñado que al pedir justicia y recibir violencia hay que responder con más justicia, más cariño, más solidaridad y más lucha.

Sevilla, 24 de Mayo de 2011

David Benavides Cuevas, profesor titular de la ETSII (Universidad de Sevilla)



[ 57 comentarios ] ( 2257 visualizaciones )   |  [ 0 trackbacks ]   |  enlace permanente  |   ( 3 / 1195 )
GNU Parallel, un buen descubrimiento 
domingo, enero 16, 2011, 08:00 PM - Tecnología



Imaginemos que tenemos un directorio de logs con cientos de ficheros .gz (o bz2). Has decidido pasar a usar xz en vez de gzip/bzip2 (por cierto, xz ya viene "de serie" en la rhel 5.5 y los rpms de rhel6 ya vienen empaquetados con xz). ¿No es un atraso hacer esto de manera secuencial si mi servidor tiene varios cores?

Un posible comando para pasar todos los ficheros de un formato a otro es el siguiente:

ls *.bz2 | while read i; do bzip2 -d $i && j=`basename $i .bz2` && xz -9 $j; done

Pero claro, esto es secuencial, no en paralelo :(

Habrá alguno que diga que use un compresor multithread (ej: 7zip), pero resulta que lo que tengo es un programa, xz, que la única manera que tengo de paralelizarlo es a nivel de procesos, vamos que tengo que lanzar varios xz en paralelo (por ejemplo, tantas instancias como cores de CPU tenga)

Veamos que sencillo es usando GNU parallel

ls *.bz2 | time parallel -j+0 --eta 'bzcat {} | xz -9 > {.}.xz'

Con este comando tengo 4 procesos bzcat lanzados (tantos como cores tengo) que "alimentan" a 4 procesos xz que comprimen los datos. Y si tuviese 8 cores, el comando sería exactamente el mismo. Ahora el cuello de botella estará en la entrada/salida, no en la potencia de CPU.

En resumen, que GNU Parallel es una herramienta muy interesante para paralelizar a base de forks() aquellas tareas sobre muchos ficheros que no aprovechen de forma nativa todos los cores de nuestra máquina. Así, podemos acelerar el trabajo de herramientas de análisis de logs, compresores, backup, antivirus tipo clamav y demás procesos limitados por su uso de CPU.

Todos aquellos que tengáis mucha potencia de entrada/salida (ejemplo, los que tengáis SSD o SANs muy rápidas) seguro que os encontráis que este tipo de herramientas son imprescindibles para aprovechar la barbaridad de IOPs que os dan esos cacharrines...





[ 168 comentarios ] ( 7584 visualizaciones )   |  [ 0 trackbacks ]   |  enlace permanente  |   ( 3 / 1483 )
Primeras impresiones de la RHEL 6 
martes, noviembre 16, 2010, 09:25 PM - GNU/Linux, Tecnología


El pasado día 10 de noviembre Red Hat publicó oficialmente la Red Hat Enterprise Linux 6 (en adelante, RHEL6). La RHEL 5 tenía de "apodo" Tikanga, la RHEL 6 en cambio se llama Santiago. Por cierto, invito a una cervecita a quien cuente en un comentario la (oscura) razón de los "codenames" de cada una de las versiones de RHEL.

Lo primero que hay que hacer, antes de instalar nada, es leer. Y mucho. Yo me he llevado dos días con documentación, y reconozco que me he saltado más de un trozo.

Lo primero: leerse las notas de lanzamiento y las notas técnicas aquí y aquí para ver los problemas conocidos y todas las nuevas funcionalidades que tiene la RHEL 6 respecto a la RHEL 5.

Una vez "digerido" estos dos primeros bocados, el siguiente paso es ver si el hardware que tenemos es compatible con nuestros sistemas, por lo que tenemos que irnos a la HCL (Hardware Compatibiluty List) . Por lo general cualquier sistema "de marca" o plataforma de virtualización extendida en sus últimas versiones (Xen / VMware) soporta la nueva RHEL 6, pero mejor comprobarlo antes de empezar.

Desde mi punto de vista aún es "demasiado pronto" para montar RHEL 6 para sistemas de producción (no tanto por madurez como que no hay muchos ISVs que la soporten en estos momentos), pero si alguien se anima a migrar algún sistema de preproducción / desarrollo, que se lea antes la guía de migración aquí

Pues venga, vamos a la "chicha". La guía de instalación nos cuenta los pasos a seguir para pasar de una ISO a un sistema instalado.

Aquí viene la primera sorpresa agradable para los que tenemos RHEL sobre VMware: la RHEL6 soporta nativamente (es decir, sin tener que instalar vmware tools) tanto el driver de red optimizado (vmxnet3) como el más interesante driver optimizado de entrada/salida (pvscsi). Este último es especialmente interesante poder tener nativamente este driver desde el momento de la instalación.

Por cierto, la manera de comprar suscripciones (que no "licenciar" ) la RHEL 6 ha variado, pero en este blog no voy a entrar en esto, sino que me centraré en los aspectos técnicos.

La RHEL6 tiene muchas más opciones de instalación que la RHEL5. Por defecto activa el SELinux, arranca menos servicios de red y por defecto el sistema de ficheros es ext4.

Si el hardware de almacenamiento con el que contamos soporta escritura diferida (write back cache), típicamente controladoras raid con batería de caché o sistemas SAN es buena idea activar la opción "nobarrier" a la hora de montar el sistema de ficheros. Más información aquí y en general, en la Storage Administration Guide

Otra lectura muy interesante es la guía de gestión de recursos , porque hay funcionalidades muy interesantes respecto a la RHEL5, como el soporte de CFS (Completely Fair Scheduler) y el novedoso sistema cgroups que permite asociar recursos (cpu, memoria y potencia de E/S) por aplicación o incluso por entorno virtual.

Hablando de modificaciones, la lista de cambios es muy grande: KVM como motor de virtualización es impresionante (si bien la gestión está aún por detrás en facilidad respecto a vmware), un kernel con muchas mejoras en multi-cores, NUMA y gestión de energía, un soporte de RAS que se acerca (pero sin llegar) al de sistemas como Solaris o HP-UX, seguridad mejorada en la gestión de identidades con el nuevo SSDD o la integración mejorada de SELinux, mejor soporte de tecnologías de comunicaciones como FCoE, NFSv4, iSCSI, IPv6...

Todo esto sin hablar de las versiones actualizadas de paquetes, como dovecot 2.0, LAMP actualizado, tomcat, squid, samba, gcc, python, perl, ruby, así como paquetes nuevos como memcached, bacula, el plugin de presto de yum (para los que tienen poco ancho de banda), dracut, tuned...

No me ha dado mucho tiempo de "trastear a fondo", por lo que no puedo contar mucho más. Ahí os dejo el comando 'uname -a' de mi máquina de prueba, ya iré contando más cosas en este blog.

Linux gufete 2.6.32-71.7.1.el6.x86_64 #1 SMP Wed Oct 27 03:44:59 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux

En 4-6 semanas se espera la CentOS 6, para los que prefieren no tener soporte o búscarselo por su cuenta.



Sigamos cacharreando.

Gufete



[ 205 comentarios ] ( 48628 visualizaciones )   |  [ 0 trackbacks ]   |  enlace permanente  |   ( 3 / 1607 )

| 1 | 2 | 3 | 4 | 5 | 6 | 7 | Siguiente> >>


eXTReMe Tracker