A menudo creo máquinas virtuales con VMware Server 2.X que luego al llevo a otros equipos, pero cuando voy a inciar la máquina virtual me encuentro que nunca termina de iniciar. Al consultar la consola de VMware me encuentro que VMware me está preguntando qué he hecho con esa máquina y no la iniciará hasta que responda a la pregunta.
Para evitarlo, podemos añadir al fichero .VMX las siguientes líneas:
uuid.action = "create"
msg.autoAnswer = "TRUE"
Llevo ya varios posts escribiendo sobre software Multipath y acabo de caer en la cuenta... vaaleee ... ¿qué es esto del software MultiPath?, ¿para qué sirve?, ¿por qué tanto interés en documentar todo esto?. Bien, habrá que empezar por el principio.
Desde los años setenta nos han machacado con el concepto de jerarquía de memoria
: La memoria cuanto más cerca de la CPU más rápida y más cara, y cuanto más lejos, más barata y más lenta. Desde entonces hemos asistido a una desenfrenada evolución de las tecnologías de almacenamiento, para acercar a la CPU más cantidad de almacenamiento, a menor coste y a mayor velocidad ... pero ... ¿por qué?... porque la información es el recurso más valioso de cualquier organización
, como siempre fue y será, y ya se sabe desde hace siglos que la información es poder
. Si combinamos estas ideas aparece un mercado que vende almacenamiento masivo y rápido a un precio razonable, dirigido a cubrir las necesidades de almacenamiento de cualquier organización. Estas necesidades se suelen empaquetar y distribuir en forma de discos duros, relegando las cintas magenéticas a la copia de seguridad de los primeros en el siguiente escalón de la jerarquía de memoria... pero claro, la tecnología tiene sus limitaciones y no podemos empaquetar toda la información que requiere el poder en un único disco duro: necesitamos varios discos duros con la máxima capacidad, los metemos en una caja que los contenga todos y los conectamos entre sí, superando así las limitaciones que nos impone la tecnologia y sumando la capacidad de todos ellos, y los organizamos en cajones dentro de la caja, para poder ampliar con más discos en el futuro.
Confiar toda la información de nuestra organización y el poder a una única caja de discos duros, en la que el fallo de uno de ellos pondría en peligro el resto de la información, es bastante arriesgado: Sacrifiquemos algo de capacidad a cambio de seguridad de la información y nos encontraremos con lo que se conoce por RAID, y sus distintos tipos: RAID-0, RAID-1, RAID-5 etc. RAID viene del acrónimo conjunto redundante de discos independientes
, pero en inglés (Redundant Array Independient Disks) y los distintos tipos se corresponden con distintas combinaciones para repartir la información entre los discos de la caja, y ganar velocidad y/o seguridad, pero claro... ¿quién implementará esto?, ¿quien se encargará de distribuir la información entre los discos de la caja? ... está claro que necesitamos un elemento nuevo en la caja que implemente esta lógica de acceso: Este elemento lo llamaremos controladora y no deja de ser un pequeño computador dedicado a implementar estas funcionalidades. Vale, ya tenemos solucionado el problema de que falle alguno de los discos... ¿pero qué pasa si falla la controladora? ... que lo perdemos todo, nada, nada, metemos una segunda controladora y un mecanismo para detectar que si una cae entre en funcionamiento la segunda.
Como no se puede acercar todo el almacenamiento que necesitemos a la CPU, había que buscar un método para llevarle la información y se usó lo que se conocía hasta entonces que era bueno: SCSI es un estándard para la transferencia de información hacia la CPU, que se implementó en las controladoras de la caja de discos... pero claro... ¿cómo hacemos llegar los bytes del poder hasta la CPU, desde las controladoras de la caja? ... mediantes cables de red (iSCSI) o de fibra óptica (FC-ALL): Pinchamos una tarjeta de expansión especial (que llamaremos HBA) al ordenador de la que salga un cable de fibra óptica y que se conecte a la controladora. Esta tarjeta se encargará de convertir los rayos de luz en señales eléctricas SCSI y a través del bus del sistema llevar los bytes hasta la CPU. Perfecto, todo solucionado, pero ¿qué pasará si se rompe esta HBA? ... que nos quedamos sin bytes ... la solución: Poner una segunda HBA en el equipo, o vender tarjetas de expansión con doble HBA, y conectamos cada HBA a una controladora.
¿Y si queremos conectar más de un ordenador a la caja de discos? ... en ese caso necesitaremos usar un elemento intermedio que realice labores de conmutación, igual que hacemos con los switches de red, y ya podremos conectar muchos equipos a nuestra caja de discos: todos conectados a este switch especial y las controladoras también, pero claro ... ¿y si se rompe ese switch?, pues lo de siempre: nos quedamos sin información; nada, nada pongamos dos switches, y conectemos una de las HBAs y una controladora a uno de los switches y la otra HBA y la otra controladora al otro switch.
En esta pequeña historia, nos encontramos que los actores reales que fabrican cajas de discos son muchos, aunque es habitual encontrarnos:
cajas de discos: Unas permiten que las dos controladoras trabajen simultáneamente sobre los mismos discos, otras trabajan las dos controladoras pero no sobre los mismos discos, en otras, el almacenamiento global se gestiona como un todo sobre el que vamos haciendo particiones y asignando a los servidores, en otras solo vemos como un todo el espacio de los discos del mismo cajón, etc...
Esta semana necesité configurar DeviceMapper Multipath en Oracle Unbreakable Linux 5 update 7, conectado a una SAN de EMC Clariion CX3-20.
El primer paso será crear el fichero /etc/multipah.conf con el siguiente contenido:
defaults {
user_friendly_names yes
udev_dir /dev
}
blacklist {
devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
devnode "^hd[a-z][[0-9]*]"
devnode "^cciss!c[0-9]d[0-9]*[p[0-9]*]"
}
devices {
device {
# Identificar la cabina (EMC Clariion)
vendor "DGC*"
product "*"
# Como comprobar si los caminos estan arriba...
path_checker emc_clariion
# Como agrupar los caminos (por prioridad)
path_grouping_policy group_by_prio
# Como obtener los IDs de los discos...
getuid_callout "/sbin/scsi_id -g -u -s /block/%n"
# Como obtener las prioridades de los discos...
# ... podemos obtener los valores disponibles...
# rpm -ql device-mapper-multipath-libs-0.4.9-23.0.9.el5 | grep libprio | cut -c25- | cut -d'.' -f1
prio "emc"
# ..esto era en Ubuntu
# prio_callout "/sbin/mpath_prio_emc /dev/%n"
# Algoritmo para presentar io al kernel por los caminos vivos
path_selector "round-robin 0"
# Esto es casi que así, porque es lo unico que hay implementado
#features "0"
features "1 queue_if_no_path"
# Cada cuando se reintenta si el camino esta vivo (aunque
# lo que manda muchas veces el valor del firmware y nvram)
no_path_retry 300
# Esto es así para Cabinas EMC
hardware_handler "1 emc"
# Le dice al demonio como manejar los caminos caídos...
failback immediate
}
}
multipaths {
multipath {
wwid 360060160066021007ebcc08b0c38df11
alias LunDatos
}
}multipath -F
multipath -v3
multipath -ll
En la línea de initrd, SquashFS se diseñó como un sistema de archivos genérico con compresión, para sistemas embebidos. Este sistema de archivos se ha hecho muy popular con la proliferación de LiveCDs, y se usa para almacenar el sistema Linux con todas las aplicaciones ya instalados, como si comprimiéramos el directorio raíz de un equipo ya instalado y configurado: Cuando la LiveCD! arranca e initrd lleva el kernel a memoria, monta este fichero squashFS en modo sólo lectura y se convierte en el directorio raíz del sistema, teniendo a partir de ese momento todas las aplicaciones disponibles.
Es posible que se nos despierte la curiosidad, y queramos husmear en el contenido de uno de estos archivos,
cd
mkdir squash_descomp
mkdir /tmp/test.squash
mount -t squashfs -o loop filesystem.squashfs /tmp/test.squash
rsync -v -rlt -a /tmp/test.squash/ squash_descomp/
umount /tmp/test.squash/
cd squash_descomp
rm -f ../filesystem.squashfs
mksquashfs . ../filesystem.squashfs
Los ficheros initrd(initial ramdisk) contienen un pequeño sistema con los ficheros básicos que permitan iniciar un kernel de Linux en memoria RAM al arrancar nuestro sistema. A partir de él, ya se puede montar el directorio raíz e ir cargando el resto de módulos del núcleo que configuran nuestro hardware.
Aunque ya hemos hablado aquí sobre cómo examinar el contenido de uno de estos ficheros, quería mejorar la entrada, porque no suelo usar aquel procedimiento, sino este otro que quiero contar hoy que me resulta menos litúrgico, y que he tenido que usar demasiado a menudo en los últimos meses, porque ando editando el arranque de distribuciones LiveCD como Clonezilla, Trinity Rescue, y otras tantas que finalmente no cuajan
porque no me sirven.
Como ya comentamos en aquella entrada encontramos dos tipos de ficheros initrd:
cp initrd.original initrd.paramodificar.gz
mkdir contenido-initrd
gunzip initrd.paramodificar.gz
mount -o loop initrd.paramodificar contenido-initrd
mkdir contenido-initrd
cd contenido-initrd
gzip -S img -dc ../initrd | cpio -id
cd contenido-initrd
find ./ | cpio -H newc -o | gzip -c > ../initrd
cd
umount contenido-initrd
cat initrd.paramodificar | gzip -c > initrd
La semana pasada supimos que la Junta de Extramdura había decidido no renovar los contratos al personal del Centro de Excelencia de Software José de Espronceda, organismo encargado del desarrollo de LinEX. En el foro oficial podemos escribir nuestras condolencias. Según el propio gobierno autonómico, la decisión se fundamenta en la insostenibilidad del proyecto y la necesidad de ahorrar en estos tiempos de crisis económica.
Este anuncio llena de incertidumbre el futuro de la apuesta más importante de una administración pública española por el uso de software libre, que además fue un referente a nivel mundial y nacional, y sentó las bases para el nacimiento del resto de distribuciones autonómicas: Guadalinex, Molinux, Lliurex, Max, y otras cuantas más.
A mi juicio el experimento ha sido un éxito rotundo, pero no dejan de preocuparme las causas reales que se esconden tras esta decisión:
A menudo nos encontramos con la necesidad de poder conectar con un servidor Windows, desde otro equipo, en las mismas condiciones que cuando lo hacemos entre servidores Linux usando SSH.
Normalmente esta necesidad podíamos cubrirla usando CygWin, pero nunca me ha terminado de convencer porque al final terminábamos convirtiendo nuestro servidor Windows en un servidor Linux al que le faltaban bastantes cosas, además del inconveniente de la doble gestión de cuentas de usuario, el lío con las barras separadoras de directorios ("/" y "\") según el comando que ejecutáramos, y por supuesto, el hecho de que muchos comandos no están al nivel de implementación de Linux y les faltan opciones... todo esto siempre me causó la impresión de que no estaba usando ni un Linux, ni un Windows, sino un refrito que funciona a medias. Nunca consideré CygWin como una opción seria para servidores en producción.
Afortunadamente, disponemos de alternativas libres para ello como FreeSSHd. Este es un simple servidor SSH y Telnet para equipos Windows, y permite hacer esto que reclamo: Instalarnos un servicio que escucha conexiones por el puerto 22 y/o 23 y al autenticarnos nos abre una consola del intérprete de comandos de Windows. Luego usaremos los mismos comandos que usaríamos frente a una ventana.
La instalación es bastante sencilla, y no ofrece ninguna complicación. Una vez lo hayamos instalado, tendremos que editar la configuración del servidor, y configurar qué puertos queremos escuchar: SSH y/o Telnet.
SFTP desde Linux para poder copiar ficheros al equipo Windows: El comando SCP no nos funcionará :(.
