Pablo Iranzo Gómez's blog

A bunch of unrelated data

mar 28, 2015

Install RHEL7/Centos/Fedora on a software raid device

Table of contents

  1. Why or why not use a RAID via software
    1. Pros
    2. Cons
  2. Performing the setup
  3. Creating the raid devices with Multiple Devices mdadm

Installing Linux on a RAID has lot of advantages, from using RAID1 to enjoy protection against drive failures or RAID0 to combine the size of several drives to create bigger space for files with all the smaller disks we have.

There are several RAID level definitions and may have different uses depending on our needs and hardware availability.

For this, I focused on using raid1 for the system disks (for greater redundancy/protection against failures) and raid0 (for combining several disks to make bigger space available for non important data)..

Why or why not use a RAID via software


  • There's no propietary data on the disks that could require this specific controller in case the hardware fails.
  • Can be performed on any system, disk combination, etc


  • The use of dedicated HW RAID cards allows to offload the CPU intensive tasks for raid calculation, etc to the dedicated processor, freeing internal CPU for system/user usage.
  • Dedicated cards may have fancier features that require no support from the operating system as are all implemented by the card itself and presented to the OS as a standard drive.

Performing the setup

As I was installing on a HP Microserver G8 recently, I had to first disable the advanced mode for the included controller, so it behaved like a standard SATA one, once done, I was able to boot from my OS image (in this case EL7 iso).

Once the ISO is booted in rescue mode, I could switch to the second console with ALT-F2 so I could start executing commands on the shell.

First step is to setup partitioning, in this case I did two partitions, first one for holding /boot and the second one for setting up the LVM physical volume where the other Logical Volumes will be defined later.

I've elected this setup over others because mdadm allows transparent support for booting (grub supports booting form it) and easy to manage setup.

For partitions, remember to allocate at least 500mb for /boot and as much as needed for your SO, for example, if only base OS is expected to have RAID protection, having a 20Gb partition will be enough, leaving the remaining disk to be used for a RAID0 device for allocating non-critical files.

For both partitions, set type with fdisk to fd: Linux RAID autodetect, and setup the two drives we'll use for initial setup using the same values, for example:

fdisk /dev/sda
n # for new partition
p # for primary
<ENTER> # for first sector
+500M # for size
t # for type
fd # for Linux RAID autodetect
n # new partition
p # primary
+20G #for size
t #for type
2 # for select 2nd partition
fd # for Linux RAID autodetect
# n for new partition
p # for primary
<ENTER> # for first sector
<ENTER> # for remaining disk
t # for type
3 # for third partition
fd # for Linux RAID Autodetect
w # for Writing changes

And repeat that for /dev/sdb

At this point, we'll have both sda and sdb with the same partitions defined: sd{a,b}1 with 500Mb for /boot and sd{a,b}2 with 20Gb for LVM and the remaining disk for RAID0 LVM.

Now, it's time to create the raid device on top, for simplicity, I tend to use md0 for /boot, so let's start with it.

Creating the raid devices with Multiple Devices mdadm

Let's create the raid devices for each system, starting with /boot:

mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda1 /dev/sdb1
mdadm --create /dev/md1 --level=1 --raid-devices=2 /dev/sda2 /dev/sdb2
mdadm --create /dev/md2 --level=0 --raid-devices=2 /dev/sda3 /dev/sdb3

Now, check the status of the raid device creation by issuing:

cat /proc/mdstat

Personalities : [raid1] [raid6] [raid5] [raid4]
md0 : active raid1 sda1[0] sdb1[1]
      534760 blocks level 1, 64k chunk, algorithm 2 [2/2] [UU]
            [==>..................]  recovery = 12.6% (37043392/292945152) finish=127.5min speed=33440K/sec
md1 : active raid1 sda2[0] sdb2[1]
      20534760 blocks level 1, 64k chunk, algorithm 2 [2/2] [UU]
            [=====>...............]  recovery = 25.9% (37043392/692945152) finish=627.5min speed=13440K/sec

When it finishes, all the devices will appear as synced, and we can start the installation of the operating system.

What I did, after this point, is to reboot the install media, so I could use anaconda installer to select manually the filesystems, creating /boot on /dev/md0, then the Physical Volume on /dev/md1 for the operating system.

Select the manual partitioning during the installation to define above devices as their intended usage, and once it has been installed, create the additional Physical volume on /dev/md2 and define the intended mountpoints, etc.


Click to read and post comments

ene 23, 2010

Customize RHEL/CentOS installation media (EL4/EL5+)

Table of contents

  1. Introduction
  2. Preparing everything
  3. DVD background image at boot prompt
  4. Including updates
  5. Removing unused packages
  6. Adding extra software
  7. Recreating metadata
    1. EL4
    2. EL5
  8. Finishing


A standard install media, (let's talk about a DVD for easier start) has several files/folders at his root, but most important are:

  • isolinux (where the loader lives)
  • images (for extra files for installer to load)
  • Packages for installation (RedHat/ for EL4, Server/Client for EL5)

Usually, a distribution has for it's main binaries more than 2 Gb of data, that enables one target to act as a multifunction server/workstation, but that you will not usually load on the same system. Furthermore, since the DVD creation, there have been so many updates/patches that make your installation a 'outdated' install that you'll need to upgrade to have recent patches.

Wouldn't it be better to have one install media suited for your target systems with all available updates applied?

Preparing everything

First, we'll need to copy all of our DVD media to a folder in our harddrive, including those hidden files on DVD root (the ones telling installer which cd-sets are included and some other info).

Let's asume that we'll work on /home/user/DVD/

After we've copied everything from our install media, we'll start customizing :)

DVD background image at boot prompt

We can customize DVD background image and even keyboard layout by tweaking "isolinux/isolinux.cfg" with all required fields (Check Syslinux Documentation to check proper syntax)

On Kickstart: instalaciones automatizadas para anaconda (spanish) you can also check how to create a kickstart, so you can embed it on this DVD and configure isolinux.cfg to automatic provision a system

Including updates

The easiest way would be to install a system with all required package set from original DVD media, and then connect that system to an update server to fetch but not install them.

  • EL4: up2date -du # yum upgrade —downloadonly
  • EL5: yum upgrade —downloadonly

After you download every single update, you'll need to copy them to a folder like /home/user/DVD/updates/.

Well, now let's start the funny work:

For each package in updates/, you'll need to remove old version from original folder (remember: Client/ Server/ or RedHat/RPMS ), and place in that folder the updated one...

After some minutes, you'll have all updates in place... and you can remove the DVD/updates/ folder as it will be empty after placing each updated RPM in the folder where the previous versions was.

Removing unused packages

Well, after having everthing in place, we'll start removing unused files. Usually, we could check every package install status on 'test' system by checking rpm, but that's going to be a way looooong task, so we can 'automate' it a bit by doing:

  • If you have ssh password less connection between your systems (BUILD and TARGET):

On BUILD system:

for package in *.rpm
    NAME=`rpm -q —queryformat '%NAME' $package` ssh TARGET "rpm -q $NAME >/dev/null 2>&1 || echo rm $package" |tee things-to-do
  • If you don't have ssh password-less setup (using private/public key auth or kerberos), you can do something similar this way:

On BUILD system:

for package in *.rpm
    NAME=`rpm -q —queryformat '%NAME' $package` echo "$package:$NAME" > packages-on-DVD

Then copy that file on your TARGET system and running:

On TARGET system:

for package in `cat packages-on-DVD`
    QUERY=`echo $package|cut -d ":" -f 2` FILE=`echo $package|cut -d ":" -f 1` rpm -q —queryformat '%NAME' $QUERY >/dev/null 2>&1 || echo rm $FILE|tee things-to-do

After you finish, you'll have a file named things-to-do, in which you'll see commands like 'rm packagename-version.rpm'

If you're confident about it's contents, you can run sh things-to-do and have all 'not installed on TARGET' packages removed from your DVD folder.

Adding extra software

In the same way we added updates, we can also add new software to be deployed along base system like monitoring utilities, custom software, HW drivers, etc, just add packages to desired folders before going throught next steps.

Recreating metadata

After all our adds and removals, we need to tell installer that we changed packages, and update it's dependencies, install order, etc.


This one is trickier, but it is still possible in a not so hard way, first of all, we need to update some metadata files (hdlist) and Package order for installation, it can be dificult if we add extra packages, as we'll have special care:

Gererate first version of hdlists:

export PYTHONPATH=/usr/lib/anaconda-runtime:/usr/lib/anaconda
/usr/lib/anaconda-runtime/genhdlist —withnumbers /home/user/DVD/
/usr/lib/anaconda-runtime/pkgorder /home/user/DVD/ i386 |tee /home/user/order.txt

Review order.txt to check all packages added by hand to check correct or include missing packages and then continue with next commands:

export PYTHONPATH=/usr/lib/anaconda-runtime:/usr/lib/anaconda
/usr/lib/anaconda-runtime/genhdlist —withnumbers /home/user/DVD/ —fileorder /home/user/order.txt


Using createrepo we'll recreate metadata, but we've to keep care and use comps.xml to provide 'group' information to installer, so we'll need to run:

createrepo -g /home/DVD/Server/repodata/groupsfile.xml /home/DVD/Server/


At this step you'll have a DVD structure on your hard drive, and just need to get an ISO to burn and test:

mkisofs -v -r -N -L -d -D -J -V NAME -b isolinux/isolinux.bin -c isolinux/ -no-emul-boot -boot-load-size 4 -boot-info-table -x lost+found -m .svn -o MyCustomISO.iso /home/user/DVD/

Now, it's time to burn MyCustomISO.iso and give it a try ;-)

PD: While testing is just better to keep using rewritable media until you want to get a 'release'

Click to read and post comments

dic 13, 2008

iSCSI y Clustering en RHEL/CentOS

Tabla de contenidos

  1. Introducción
  2. Manos a la obra
    1. Target iSCSI
    2. Resto de equipos
    3. El clúster
    4. GFS: Global File System
    5. ¿Y si falla la red
    6. Conclusión


Durante la última semana estuve jugando de nuevo con iSCSI en el curso de RH436 Enterprise Clustering and Storage Management. Hace tiempo había seguido dos artículos Instalando un target iSCSI y su continuación Montando un iniciador iSCSI.

iSCSI es una tecnología que permite acceder a almacenamiento remoto como si de unidades locales se tratara. A nivel 'barato', podemos utilizar el espacio de un sevidor central del que hacemos copias de seguridad, etc para ofrecer ese almacenamiento a distintas máquinas.

Con la entrada en juego de las ofertas de virtualización integradas con el SO, como por ejemplo Xen, podemos tener un servidor 'grande' y potente que albergue distintas máquinas virtuales que sirvan las páginas de dicho volumen en red, actualizarlo centralmente y tener muchos servidores actualizados....

Bueno, a medias :-)

Siempre es complicado compartir sistemas de ficheros, existen problemas de bloqueos de ficheros, accesos recurrentes, etc, en el caso de iSCSI no sólo es el FS sino la unidad, desde cualquier equipo podemos particionarla, etc, es por ello que se necesitan algunas utilidades preparadas para dicho funcionamiento en red, así como por supuesto, un sistema de ficheros que soporte dicho uso simultáneo.

Con las últimas versiones del kernel, disponemos tanto de clvm (Cluster LVM) como de GFS (Global File System), que permiten, por un lado, poder operar en red desde varios equipos con los volúmenes lógicos, redimensionarlos, etc sin afectar a la producción, como de un sistema de ficheros preparado para trabajar en red con varios equipos.

Piensa por un momento, la posibilidad de tener ese host tan potente o una SAN con copias de seguridad bien controladas, etc

Añádele la posibilidad de tener máquinas virtuales que monten por la red una unidad iSCSI.

Añádele que esa unidad iSCSI puede ser de Lectura escritura, y que puedes utilizar enlaces simbólicos con variables que según el host que acceda guarde los logs en una carpeta.

Imagina lanzar tantas máquinas virtuales como sea necesario para atender la demanda, poder distribuirlas en la red.

Manos a la obra

Target iSCSI

Si no tenemos un target iSCSI, podemos definirlo en nuestro anfitrión, utilizando la versión Tech Preview de iSCSI Target llamada: scsi-target-utils

Esta utilidad contiene un comando tgtadm que podemos utilizar para definir las unidades.

Deberemos activar el demonio de tgtd para que esté disponible en cada arranque con los comandos:

chkconfig tgtd on
service tgtd start

Actualmente y como tech preview, debemos repetir cada vez los comandos que necesitamos para definir la unidad iSCSI, por ejemplo:

tgtadm --lld iscsi --mode target --op new --tid=1 --targetname iqn.2008-12.tld.dominio.maquina:TARGET tgtadm --lld iscsi --mode logicalunit --op new --tid=1 --lun=1 -b /dev/vg0/TARGET tgtadm --mode target --op bind --tid=1 --initiator-address=

Con estos comandos definimos un nuevo target con ID 1, de nombre IQN iqn.2008-12.tld.dominio.maquina:TARGET y le añadimos una unidad lógica (LUN) que se basa en el contenido del volumen LVM /dev/vg0/TARGET.

Además, le permitimos el acceso a dicho target desde la ip

Si todo esto está bien, deberemos, hasta que salga de la Tech Preview, añadir estos comandos al fichero /etc/rc.local para que se ejecuten en cada arranque

Resto de equipos

El primer paso, es instalar en todas las máquinas los paquetes de lvm2-cluster, así como ricci. En todas ellas deberemos ejecutar lvm —enable-cluster para modificar los parámetros de locking para utilizarlo en red.

Para arrancar ricci tendremos que hacer algo parecido a lo que hicimos con tgtd

chkconfig ricci on
service ricci start`

Por otro lado necesitaremos tener kmod-gfs, gfs-util y iscsi-initiator-utils.

Las unidades iSCSI se reconocerán a partir de la primera detección de forma automática, para ello deberemos ejecutar los siguientes comandos:

iscsiadm -m discovery -t sendtargets -p IPTARGETISCSI iscsiadm -m node -T iqn.2008-12.tld.dominio.maquina:TARGET -l

Que descubrirá los targets disponibles para nuestra IP y luego hará 'login' en la máquina. A partir de este momento tendremos nuevas unidades disponibles que se presentarán como SCSI a nuestro pc, podremos particionarlas, etc.

El clúster

Si queremos hacer las cosas de la forma 'sencilla', deberemos instalar luci en una de las máquinas, ya sea en un nodo de control, o en el anfitrión Xen.

Luci es un interfaz web que permite la gestión y creación de clusters y para ello utiliza el demonio 'ricci' que hemos instalado en cada máquina.

Si tenemos las máquinas configuradas con los repositorios necesarios, ricci se hará cargo de la instalación de los paquetes necesarios para configurar todo.

Desde el interfaz web de luci podemos ir añadiendo cada uno de los nodos a utilizar, indicando sus claves de 'root' y se encargará de contactarlos y a través de ricci, instalar el software necesario y reiniciarlos para integrarlos en el cluster.

Los nodos, una vez en el cluster pueden utilizarse para albergar servicios, que estén de forma exclusiva (por ejemplo una bbdd porque necesite prioridad absoluta), o bien en failover para que no se deje de dar el servicio.

Por defecto tenemos una serie de servicios preconfigurados que podemos dar, como http, nfs, etc que podremos configurar rápidamente desde luci, que se encargará de desplegar dicha configuración a todo el cluster.

La forma de hacerlo es sencilla, se definen recursos (IP, NFS Exports, NFS Clients, http, mount points) que luego se agrupan por cadenas de dependencia en servicios y se les asignan grupos de failover, para que en caso de fallo, podamos definir prioridades.

Imagina el caso de una empresa con dos servidores, uno con la bbdd y otro con la web. En caso de fallo de uno de ellos, podemos hacer 'saltar' los servicios a la máquina que está operativa hasta que arreglemos la dañada y luego, cada servicio, volvería a su máquina 'preferida' o en el orden necesario.

En el caso de máquinas virtuales, en caso de que dejen de responder, CMAN realizará un reinicio (siempre que hayamos distribuido las claves de xen que podemos crear en la interfaz tanto a los guests como al anfitrión que estará escuchando con el demonio de fencing para XVM activado).

En el caso de tener enchufes 'con red' o bien máquinas con tarjetas de gestión remota (iLO, RemoteView Service Board, etc), definiremos los parámetros de acceso.

En caso de detectar un problema con cualquier equipo, el resto de ellos hará votaciones y si la mayoría considera que no responde, lo reiniciarán, por un lado para liberar cualquier tipo de acceso a disco, etc que hubiera estado haciendo a los recursos del cluster, como para intentar recuperarlo.

GFS: Global File System

¿Qué pinta GFS en todo esto?

GFS1 nos permite crear un sistema de ficheros que tendrá un journal para cada nodo del cluster y que si lo creamos sobre el volumen iSCSI podemos hacer disponible a todos los equipos, si un equipo se bloquea, otro toma el control del journal no acabado, lo verifica y aplica sobre el FS hasta que la máquina retorna para dejarlo en un estado limpio.

Por otro lado, CLVM y GFS permiten aumentar dinámicamente el tamaño de los volúmenes, de forma que no tenemos que dejar inoperativos nuestros sistemas para hacer mantenimientos par añadir más capacidad, etc.

Permite también crear enlaces simbólicos de forma que una unidad con FS GFS1 pueda quedar:

logs -> hosts/@hostname/logs/

Esto permite que diversos servidores web tengan configurado como ruta para los logs la carpeta 'logs' que se expandirá al hostname de la máquina, haciendo que queden todos recogidos en un lugar central para posterior análisis de estadísticas, etc

Este tipo de enlaces se denominan CDPN: Context-dependent pathnames y nos permiten jugar con este tipo de cosas y aprovechar las ventajas de un almacenamiento único.

¿Y si falla la red

Como siempre podemos tener problemas con la red, la forma de solucionarlos consiste en tener varios interfaces de red en los equipos a través de distintos switches, etc y en las máquinas, una vez descubiertos los targets, configurar el fichero /etc/multipathd.conf y habilitar el demonio.

Nos creará las rutas necesarias y una serie de dipositivos /dev/mpath/* para acceder de forma tolerante a fallos a nuestros recursos, si configuramos las tarjetas de red en modo bonding, ya tenemos el acceso más o menos asegurado ante las catástrofes más comunes y nuestros datos disponibles


Tenemos a nuestro alcance muchas herramientas para hacer sencilla la utilización y creación de sistemas equivalentes a lo que hace años sólo tenía una alternativa excesivamente cara.

Sinceramente vale la pena perder un rato y probar estas cosas y maravillarnos de las posibilidades que abre de cara a la gestión de los equipos, la información y su acceso y lo mejor de todo, siempre con Software Libre.

Espero que esta introducción os despierte el gusanillo para explorar las diversas funcionalidades que estas tecnologías nos ofrecen!

Click to read and post comments