Aber natürlich weit gefehlt. Eigentlich ist das Asus M2A-VM Moterhboard ein ganz gutes Board, doch die Einrichtung eines simplen Raid 1 (2x 500GB) stellte sich doch als schwieriger heraus als zuerst angenommen.

Zum Glück fand ich nach mehrtägiger Suche und drei Installationen von Windows endlich einen Forenbeitrag, der mich letztendlich auf die Lösung brachte:

Dopo una veloce installazione (molto semplice) mi sono accorto di aver acquistato qualcosa di molto più potente, perché con alcune semplici procedure è possibile trasformare la black-box in una white-box ultra personalizzabile, su cui è possibile installare quasi di tutto.
Si può partire con dei binari precompilati (Telnet, bittorrent, httpd, php, svn, ...) fino ad installare una porta seriale che permette di aggiornarela flash ed installare Debian.

Sono rimasto anche positivamente impressionato dalla ricca configurabilità di alert di diagnostica.

E meus senhores, cá entre nós...

RAID 1 hoje é importantissimo.

As an analogy, a magnetic head slider flying over a disk surface with a flying height of 25 nm with a relative speed of 20 meters/second is equivalent to an aircraft flying at a physical spacing of 0.2 µm at 900 kilometers/hour. This is what a disk drive experiences during its operation. -Magnetic Storage Systems Beyond 2000, George C. Hadjipanayis from Wikipedia

We all know we need to back-up our data. But it is a chore that often gets forgotten at the most critical periods. Here are my hints for preparing yourself for that inevitable 'click of death'.

• Buy an external USB/Firewire harddrive. 500GB drives are ridiculously cheap these days. Personally I don't like back-up tapes due to experiences of them stretching and corrupting data.
• Back-up images of the entire OS, not just the data. You can use Acronis TrueImage on Windows and SuperDuper on MacOSX. This can save you days restoring your entire development environment and applications from scratch.
• Back-up individual files as well as entire OS images. You don't want to have to restore a whole image to retrieve one critical file. Windows Vista and Mac OS X Leopard both have back-up applications built into the OS.
• Use a separate machine to your development machine as source code server.
• Use a RAID-1 (mirrored) disk on your main development machine[1]. It is worth noting that this actually doubles the likelihood of harddisk failure, but makes the likelihood of a catastrophic failure much lower. Keep an identical 3rd drive on hand to swap in when a drive fails.
• Back-ups aren't much use if they get incinerated along with your office in a fire, so store copies off-site. For example you can:
  • ftp copies to your webserver
  • use a service such as Amazon S3 + JungleDisk[2] or specialised on-line back services such as Mozy or Carbonite
  • give DVDs to friends and family

• Make sure any off-site copies are securely encypted, for example using Axcrypt.
• Automate your back-ups as far as possible. Computers are much better at the dull repetitive stuff.
• Test restoring data once in a while. There is not much point backing up data only to find you can't restore it when needed.

There are lots of applications for backing up individual files. So many in fact, that no-one has any hope of evaluating them all (marketing tip: don't write another back-up application - really). I also worry that data stored in their various proprietary formats might not be accessible in future due to the vendor going out of business. I find the venerable DOS xcopy adequate for my needs. I run it in a scheduled Windows batch file to automatically synch file changes on to my usb harddrive (i:) every night. Here it is in all its glory:

The exclude.txt file is used to exclude subversion folders and intermediate compiler files:

Which of the above do I do? Pretty much all of them actually. At least I try, I haven't yet automated the offsite backup. This may seem rather excessive, but it paid dividends last month when gremlins went on the rampage here in the Oryx Digital office. I had 2 harddrive failures in 2 weeks. The power supply+harddisk+network card on my old XP development machine failed then, while I was in the process of moving everything to my new Vista development machine, one of the RAID-1 disks on the new machine failed.

Things didn't go quite according to plan though. The new RAID-1 box wouldn't boot from either harddisk. I have no idea why.

Also the last couple of weekly Acronis image back-ups had failed and I hadn't done anything about it. I had recent back-ups of all the important data, but I faced a day or more reinstalling all the apps I had installed since the last successful image. It took several hours on the phone to Dell technical support and much crawling around on the floor before I could I get the new RAID-1 box to boot off one harddisk. I was then able to rebuild RAID-1 using the spare harddisk I had on standby for such an eventuality. Nothing was lost, apart from my sense of humour.

Dell offered to replace the defective harddisk under warranty, but I declined on the grounds that there is far too much valuable information on this disk (source code, digital certificate keys, customer details etc) for me to entrust it to any third party. Especially given that Dell reserve the right to refurbish the harddisk and send it to someone else. What if they forgot to wipe it? My experiences with courier companies also haven't given me great confidence that the disk would reach Dell. And I didn't want to receive a reburbished disk as a replacement. It just isn't worth relying on a refurb given how cheap new harddisks are. So the harddisk has joined the back of the growing queue to see Mr Lump Hammer.

The availability of cheap harddisks and cheap bandwidth means that it has never been easier to backup your systems. No more fiddling with mag tapes. Of course it is possible that your harddisk will work perfectly until it becomes obselete, but I think it would be very unwise to assume that this will be the case. Don't say I didn't warn you...

Further reading:

What's your backup strategy? (the prolific and always worth reading Jeff Atwood beats me to the punch)

[1] RAID-1 is built in to some Intel motherboards and is available as a relatively inexpensive extra from Dell. You may have to ask for it though - it wasn't listed as a standard configuration option when I purchased my Dell Dimension 9200.

[2] Since I wrote this article I installed the latest version of JungleDisk on my Vista box. On the 3 occasions I have tried to use it it hung Vista to the point where I had to I had to cut the power in order to reboot. I have now uninstalled it. 

La versión utilizada para este documento es la 8.2.4 y está probado en kernels 2.6.21.5 y 2.6.23.1 en distribuciones Debian Etch, utilizaremos dos nodos, el primario será Atlantis y el secundario será Dedalos.

Lo primero que haremos será bajarnos en ambos servidores el paquete drbd-8.2.4 de http://oss.linbit.com/drbd/8.2/drbd-8.2.4.tar.gz , lo colocamos en las fuentes y lo descomprimimos.

# tar xvzf drbd-8.2.4.tar.gz

Ahora compilaremos drbd con ‘make’ y ‘make install’, primero en Atlantis y luego en Dedalos:

Atlantis:/usr/src/drbd-8.2.4/drbd# make

    Calling toplevel makefile of kernel source tree, which I believe is in

    KDIR=/lib/modules/2.6.21.5/build

test -f ../scripts/adjust_drbd_config_h.sh && \

         KDIR=/lib/modules/2.6.21.5/build O= /bin/bash ../scripts/adjust_drbd_co                                             nfig_h.sh

/lib/modules/2.6.21.5/build /usr/src/drbd-8.2.4/drbd

/usr/src/drbd-8.2.4/drbd

  Using unmodified drbd_config.h

make -C /lib/modules/2.6.21.5/build SUBDIRS=/usr/src/drbd-8.2.4/drbd  modules

make[1]: se ingresa al directorio `/usr/src/linux-2.6.21.5'

  CC [M]  /usr/src/drbd-8.2.4/drbd/drbd_buildtag.o

  CC [M]  /usr/src/drbd-8.2.4/drbd/drbd_bitmap.o

  CC [M]  /usr/src/drbd-8.2.4/drbd/drbd_proc.o

  CC [M]  /usr/src/drbd-8.2.4/drbd/drbd_worker.o

  CC [M]  /usr/src/drbd-8.2.4/drbd/drbd_receiver.o

  CC [M]  /usr/src/drbd-8.2.4/drbd/drbd_req.o

  CC [M]  /usr/src/drbd-8.2.4/drbd/drbd_actlog.o

  CC [M]  /usr/src/drbd-8.2.4/drbd/lru_cache.o

  CC [M]  /usr/src/drbd-8.2.4/drbd/drbd_main.o

  CC [M]  /usr/src/drbd-8.2.4/drbd/drbd_strings.o

  CC [M]  /usr/src/drbd-8.2.4/drbd/drbd_nl.o

  LD [M]  /usr/src/drbd-8.2.4/drbd/drbd.o

  Building modules, stage 2.

  MODPOST 1 modules

  CC      /usr/src/drbd-8.2.4/drbd/drbd.mod.o

  LD [M]  /usr/src/drbd-8.2.4/drbd/drbd.ko

make[1]: se sale del directorio `/usr/src/linux-2.6.21.5'

mv .drbd_kernelrelease.new .drbd_kernelrelease

Memorizing module configuration ... done.

Atlantis:/usr/src/drbd-8.2.4/drbd# make install

install -d //lib/modules/2.6.21.5/kernel/drivers/block

install -m 644 drbd.ko //lib/modules/2.6.21.5/kernel/drivers/block

/sbin/depmod -a || /sbin/depmod -e drbd.ko 2>&1 >/dev/null || true

La salida de los comandos se pone para tener una guía mas exacta de lo que se supone que debe ser el resultado. Una vez instalado DRBD, cargamos el modulo DRBD en ambos servidores:

Atlantis:/# modprobe drbd

Atlantis:/# cat /proc/drbd

version: 8.2.4 (api:88/proto:86-88)

GIT-hash: fc00c6e00a1b6039bfcebe37afa3e7e28dbd92fa build by root@Atlantis, 2008-01-22 13:08:17

En esta versión de DRBD no hay un paquete drbdx.y-tools, sino que se encuentra dentro del tar.gz que nos bajamos anteriormente, concretamente en drbd-8.2.4/user. Como nota adicional se deberá instalar el paquete ‘flex’ para la correcta compilación de las utilidades de DRBD en ambos servidores:

Atlantis:/# apt-get install flex

Leyendo lista de paquetes... Hecho

Creando Árbol de dependencias... Hecho

Paquetes sugeridos:

  bison

Se instalarán los siguientes paquetes NUEVOS:

  flex

0 actualizados, 1 se instalarán, 0 para eliminar y 75 no actualizados.

Necesito descargar 313kB de archivos.

Se utilizarán 1008kB de espacio de disco adicional después de desempaquetar.

Des:1 ftp://ftp.es.debian.org etch/main flex 2.5.33-11 [313kB]

Descargados 313kB en 0s (1077kB/s)

Preconfigurando paquetes ...

Seleccionando el paquete flex previamente no seleccionado.

(Leyendo la base de datos ...

36600 ficheros y directorios instalados actualmente.)

Desempaquetando flex (de .../flex_2.5.33-11_amd64.deb) ...

Configurando flex (2.5.33-11) ...

Atlantis:/# cd /usr/src/drbd-8.2.4/user

Atlantis:/usr/src/drbd-8.2.4/user# make

flex -s -odrbdadm_scanner.c drbdadm_scanner.fl

gcc -g -O2 -c -W -Wall -I../drbd   -c -o drbdadm_scanner.o drbdadm_scanner.c

gcc -g -O2 -c -W -Wall -I../drbd   -c -o drbdadm_parser.o drbdadm_parser.c

gcc -g -O2 -c -W -Wall -I../drbd   -c -o drbdadm_main.o drbdadm_main.c

gcc -g -O2 -c -W -Wall -I../drbd   -c -o drbdadm_adjust.o drbdadm_adjust.c

gcc -g -O2 -c -W -Wall -I../drbd   -c -o drbdtool_common.o drbdtool_common.c

gcc -g -O2 -c -W -Wall -I../drbd   -c -o drbdadm_usage_cnt.o drbdadm_usage_cnt.c

cp ../drbd/drbd_buildtag.c drbd_buildtag.c

gcc -g -O2 -c -W -Wall -I../drbd   -c -o drbd_buildtag.o drbd_buildtag.c

gcc -o drbdadm drbdadm_scanner.o drbdadm_parser.o drbdadm_main.o drbdadm_adjust.o drbdtool_common.o drbdadm_usage_cnt.o drbd_buildtag.o

gcc -g -O2 -c -W -Wall -I../drbd -fno-strict-aliasing   -c -o drbdmeta.o drbdmeta.c

flex -s -odrbdmeta_scanner.c drbdmeta_scanner.fl

gcc -g -O2 -c -W -Wall -I../drbd -fno-strict-aliasing   -c -o drbdmeta_scanner.o drbdmeta_scanner.c

gcc -o drbdmeta drbdmeta.o drbdmeta_scanner.o drbdtool_common.o drbd_buildtag.o

gcc -g -O2 -c -W -Wall -I../drbd -I/lib/modules/2.6.21.5/build/include -fno-strict-aliasing   -c -o drbdsetup.o drbdsetup.c

cp ../drbd/drbd_strings.c drbd_strings.c

gcc -g -O2 -c -W -Wall -I../drbd -I/lib/modules/2.6.21.5/build/include -fno-strict-aliasing   -c -o drbd_strings.o drbd_strings.c

gcc -o drbdsetup drbdsetup.o drbdtool_common.o drbd_buildtag.o drbd_strings.o

Atlantis:/usr/src/drbd-8.2.4/user# make install

install -d /sbin/

if getent group haclient > /dev/null 2> /dev/null ; then        \

                install -g haclient -m 4750 drbdsetup /sbin/ ;  \

                install -g haclient -m 4750 drbdmeta /sbin/ ;   \

                install -m 755 drbdadm /sbin/ ;         \

        else                                                            \

                install -m 755 drbdsetup /sbin/ ;               \

                install -m 755 drbdmeta /sbin/ ;                \

                install -m 755 drbdadm /sbin/ ;                 \

        fi

Ahora editamos el archivo /etc/drbd.conf, en ambos servidores ha de ser exactamente el mismo. Para saber qué parámetros poner ir a http://www.drbd.org/fileadmin/drbd/doc/8.0.2/en/drbd.conf.html , pero bastará con una configuración sencilla como ésta:

resource data {

  protocol C;

  startup {

    degr-wfc-timeout 120;    # 2 minutes.

  }

  disk {

    on-io-error   detach;

  }

  net {

  }

  syncer {

    rate 100M;

    al-extents 257;

  }

  on Atlantis {

    device     /dev/drbd0;

    disk       /dev/sdb1;

    address    10.0.0.1:7788;

    meta-disk  internal;

  }

  on Dedalos {

    device    /dev/drbd0;

    disk      /dev/sdb1;

    address   10.0.0.2:7788;

    meta-disk internal;

  }

}

Nota: Se han puesto las direcciones en clase A puesto que se va a utilizar una comunicación local a través de cable cruzado en vez de usar( y por consiguiente, saturar) las direcciones públicas de ambos servidores.

Ahora inicializamos el area de metadatos para drbd en ambos servidores, el uso debido es ‘drbdadm create-md nombre_del_recurso’ en nuestro caso:

Atlantis:/# drbdadm create-md data

                --== This is a new installation of DRBD ==--

Please take part in the global DRBD usage count at http://usage.drbd.org.

The conter works completely anonymous. A random number gets created on

you machine, and that randomer number (as identifier for this machine) and

DRBD's version number are sent to usage.drbd.org.

The benifits for you are:

 * As a respose to your data, the server (usage.drbd.org) will tell you

   how many users before you have installed this version (8.2.4).

 * With a high counter the DRBD developers have a high motivation to

   continue development of the software.

http://usage.drbd.org/cgi-bin/insert_usage.pl?nu=5198341406454345055&git=fc00c6e                                             00a1b6039bfcebe37afa3e7e28dbd92fa

In case you want to participate but know that this machines is firewalled

simply issue the query string with your favourite web browser or wget.

You can control all this by setting 'usage-count' in your drbd.conf.

* You may enter a free form comment about your machine, that gets

  used on usage.drbd.org instead of the big random number.

* Enter 'no' to opt out.

* To count this node without comment, just press [RETURN]

  --==  Thank you for participating in the global usage survey  ==--

The server's response is:

you are the 157th user to install this version

In the future drbdadm will only contact usage.drbd.org when you update

DRBD or when you use 'drbdadm create-md'. Of course it will continue

to ask you for confirmation as long as 'usage-count' is at its default

value of 'ask'.

Just press [enter] to continue:

v08 Magic number not found

v07 Magic number not found

v07 Magic number not found

v08 Magic number not found

Writing meta data...

initialising activity log

NOT initialized bitmap

New drbd meta data block sucessfully created.

                --== Creating metadata ==--

As with nodes we count the total number of devices mirrored by DRBD at

at http://usage.drbd.org.

The counter works completely anonymous. A random number gets created for

this device, and that randomer number and the devices size will be sent.

http://usage.drbd.org/cgi-bin/insert_usage.pl?nu=5198341406454345055&ru=88757185                                             88670100790&rs=400085812224

Enter 'no' to opt out, or just press [return] to continue:

Success

Procedemos ahora a inicializar los recursos detallados en el archivo de configuración en ambos servidores. Es MUY IMPORTANTE tener en cuenta que los discos utilizados para el RAID 1 por red han de estar desmontados:

Atlantis:/# drbdadm up all

Atlantis:/# cat /proc/drbd

version: 8.2.4 (api:88/proto:86-88)

GIT-hash: fc00c6e00a1b6039bfcebe37afa3e7e28dbd92fa build by root@Atlantis, 2008-01-21 10:34:37

 0: cs:WFConnection st:Secondary/Unknown ds:Inconsistent/DUnknown C r---

    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0

        resync: used:0/31 hits:0 misses:0 starving:0 dirty:0 changed:0

        act_log: used:0/257 hits:0 misses:0 starving:0 dirty:0 changed:0

Dedalos:/# drbdadm up all

Dedalos:/# cat /proc/drbd

version: 8.2.4 (api:88/proto:86-88)

GIT-hash: fc00c6e00a1b6039bfcebe37afa3e7e28dbd92fa build by root@Dedalos, 2008-01-21 10:45:20

 0: cs:Connected st:Secondary/Secondary ds:Inconsistent/Inconsistent C r---

    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0

        resync: used:0/31 hits:0 misses:0 starving:0 dirty:0 changed:0

        act_log: used:0/257 hits:0 misses:0 starving:0 dirty:0 changed:0

Como se observa, después de haber inicializado los recursos en los dos nodos, el estado de drbd es Secondary/Secondary. Para nombrar uno de ellos como primario deberemos hacer sólo en el servidor primario:

Atlantis:/# drbdsetup /dev/drbd0 primary -o

Ésta es la orden que hay que darle, puesto que en la versión utilizada aquí está obsoleto el comando "drbdadm --do-what-I-say primary all". Si observamos la salida de /var/log/kern.log veremos lo siguiente:

Atlantis kernel: drbd0: role( Secondary -> Primary ) disk( Inconsistent -> UpToDate )

Atlantis kernel: drbd0: Forced to conisder local data as UpToDate!

Atlantis kernel: drbd0: Creating new current UUID

Atlantis kernel: drbd0: Writing meta data super block now.

Atlantis kernel: drbd0: Becoming sync source due to disk states.

Atlantis kernel: drbd0: Writing meta data super block now.

Atlantis kernel: drbd0: writing of bitmap took 41 jiffies

Atlantis kernel: drbd0: 372 GB (97674210 bits) marked out-of-sync by on disk bit-map.

Atlantis kernel: drbd0: Writing meta data super block now.

Atlantis kernel: drbd0: conn( Connected -> WFBitMapS )

Atlantis kernel: drbd0: conn( WFBitMapS -> SyncSource )

Atlantis kernel: drbd0: Began resync as SyncSource (will sync 390696840 KB [97674210 bits set]).

Atlantis kernel: drbd0: Writing meta data super block now.

El tiempo de sincronización de los dos discos duros fisicos depende del tamaño de éstos y de la tasa de transferencia que soporte la red local a la que estén comunicados, aun así tardará un buen rato. Para ver el progreso de la sincronización:

Atlantis:/# cat /proc/drbd

version: 8.2.4 (api:88/proto:86-88)

GIT-hash: fc00c6e00a1b6039bfcebe37afa3e7e28dbd92fa build by root@Atlantis, 2008-01-21 10:34:37

 0: cs:SyncSource st:Primary/Secondary ds:UpToDate/Inconsistent C r---

    ns:46842688 nr:0 dw:0 dr:46842688 al:0 bm:2859 lo:0 pe:0 ua:0 ap:0

        [=>..................] sync'ed: 12.0% (335795/381539)M

        finish: 8:26:31 speed: 11,256 (10,240) K/sec

        resync: used:0/31 hits:2924808 misses:2860 starving:0 dirty:0 changed:2860

        act_log: used:0/257 hits:0 misses:0 starving:0 dirty:0 changed:0

Nótese la diferencia del comando si se ejecuta en Atlantis o en Dedalos, cambia el orden de referencia de status:

Dedalos:/# cat /proc/drbd

version: 8.2.4 (api:88/proto:86-88)

GIT-hash: fc00c6e00a1b6039bfcebe37afa3e7e28dbd92fa build by root@Dedalos, 2008-01-21 10:45:20

 0: cs:SyncTarget st:Secondary/Primary ds:Inconsistent/UpToDate C r---

    ns:0 nr:46883648 dw:46883648 dr:0 al:0 bm:2861 lo:0 pe:0 ua:0 ap:0

        [=>..................] sync'ed: 12.1% (335755/381539)M

        finish: 8:31:37 speed: 11,040 (10,240) K/sec

        resync: used:0/31 hits:2927366 misses:2862 starving:0 dirty:0 changed:2862

        act_log: used:0/257 hits:0 misses:0 starving:0 dirty:0 changed:0

Una vez que se haya terminado el proceso de sincronización de los dos discos físicos por red, repetimos la ultima orden y nos saldrá lo siguiente:

Atlantis:/# cat /proc/drbd

version: 8.2.4 (api:88/proto:86-88)

GIT-hash: fc00c6e00a1b6039bfcebe37afa3e7e28dbd92fa build by root@Atlantis, 2008-01-21 10:34:37

 0: cs:Connected st:Primary/Secondary ds:UpToDate/UpToDate C r---

    ns:44 nr:0 dw:44 dr:478 al:0 bm:0 lo:0 pe:0 ua:0 ap:0

        resync: used:0/31 hits:0 misses:0 starving:0 dirty:0 changed:0

        act_log: used:0/257 hits:11 misses:0 starving:0 dirty:0 changed:0

Ahora solo falta montar el disco en el nodo primario, pero OJO! No hay que montar la partición física sino la ‘virtual’, es decir /dev/drbd0, no /dev/hdb1 o /dev/sdb1. Con ‘df -h’ comprobaremos que efectivamente está montado:

Atlantis:/# mount /dev/drbd0 /data

Atlantis:/# df -h

S.ficheros          Tamaño Usado  Disp Uso% Montado en

/dev/sda1             179G  2,3G  168G   2% /

tmpfs                 2,0G     0  2,0G   0% /lib/init/rw

udev                   10M   72K   10M   1% /dev

tmpfs                 2,0G     0  2,0G   0% /dev/shm

/dev/drbd0            367G  723M  348G   1% /data

PUNTO IMPORTANTE: REINICIO DE

LOS NODOS QUE POSEEN DRBD

Si crees que ahora que tienes sincronizado los discos duros de los dos nodos por red puedes apagar o reiniciar los nodos con un simple ‘init 0’ o ‘init 6’... estás equivocado, si haces esto, puedes corromper los datos de ambos discos duros o quizá peor, los puedes dejar inutilizados físicamente. No digo, que no se pueda a hacer con un simple ‘init 6’, lo que digo es que no es ni recomendable ni seguro.

La secuencia de comandos a seguir es la siguiente:

En el nodo primario

umount /dev/drbd0

df -h (no debería verse /dev/drbd0)

Atlantis:/# df -h

S.ficheros          Tamaño Usado  Disp Uso% Montado en

/dev/sda1             179G  2,3G  168G   2% /

tmpfs                 2,0G     0  2,0G   0% /lib/init/rw

udev                   10M   72K   10M   1% /dev

tmpfs                 2,0G     0  2,0G   0% /dev/shm

drbdadm secondary all (se comprueba que el status de los discos son ambos secundarios)

Atlantis:/# drbdadm secondary all

Atlantis:/# cat /proc/drbd

version: 8.2.4 (api:88/proto:86-88)

GIT-hash: fc00c6e00a1b6039bfcebe37afa3e7e28dbd92fa build by root@Atlantis, 2008-01-21 10:34:37

 0: cs:Connected st:Secondary/Secondary ds:UpToDate/UpToDate C r---

    ns:52 nr:0 dw:52 dr:715 al:0 bm:2 lo:0 pe:0 ua:0 ap:0

        resync: used:0/31 hits:0 misses:0 starving:0 dirty:0 changed:0

        act_log: used:0/257 hits:13 misses:0 starving:0 dirty:0 changed:0

En ambos nodos

drbdadm down all

Atlantis:/# drbdadm down all

Atlantis:/# cat /proc/drbd

version: 8.2.4 (api:88/proto:86-88)

GIT-hash: fc00c6e00a1b6039bfcebe37afa3e7e28dbd92fa build by root@Atlantis, 2008-01-21 10:34:37

 0: cs:Unconfigured

rmmod drbd

Con estos dos últimos comandos la salida de /proc/drbd debería ser la siguiente:

Atlantis:/# rmmod drbd

Atlantis:/# cat /proc/drbd

cat: /proc/drbd: No existe el fichero o el directorio

Ahora Atlantis y Dedalos(Primario y Secundario) están listos para reiniciarse sin problemas. En cuanto arranquen la secuencia de comandos sería:

En ambos nodos

modprobe drbd

drbdadm up all (esto hace que ambos nodos se inicialicen como secundarios)

En el nodo primario

drbdadm primary all

mount /dev/drbd0 /data

Se comprueba que todo está bien y ha de quedar idéntico a esto:

Atlantis:/# cat /proc/drbd

version: 8.2.4 (api:88/proto:86-88)

GIT-hash: fc00c6e00a1b6039bfcebe37afa3e7e28dbd92fa build by root@Atlantis, 2008-01-22 13:08:17

 0: cs:Connected st:Primary/Secondary ds:UpToDate/UpToDate C r---

    ns:4 nr:0 dw:4 dr:237 al:0 bm:0 lo:0 pe:0 ua:0 ap:0

        resync: used:0/31 hits:0 misses:0 starving:0 dirty:0 changed:0

        act_log: used:0/257 hits:1 misses:0 starving:0 dirty:0 changed:0

Así es como se hace un reinicio limpio de los nodos.

ANEXO: DRBD CON

VARIOS RECURSOS

Googleando por internet nos encontramos con que hay escasez de manuales o HOWTO's que traten sobre la sincronización de varios discos, no solo de un disco en cada servidor, sino varios.

El funcionamiento de DRBD permite crear un RAID 1 por cada par de discos. En ningún caso (por lo menos que yo conozca) se pueden sincronizar los cuatro discos a la vez, sino que deberán sincronizarse por pares. Para ello, modificamos el archivo /etc/drbd.conf editado anteriormente y le añadimos un nuevo recurso llamado "data2", quedando así:

resource data {

  protocol C;

  startup {

    degr-wfc-timeout 120;    # 2 minutes.

  }

  disk {

    on-io-error   detach;

  }

  net {

  }

  syncer {

    rate 100M;

    al-extents 257;

  }

  on Atlantis {

    device     /dev/drbd0;

    disk       /dev/sdb1;

    address    10.0.0.1:7788;

    meta-disk  internal;

  }

  on Dedalos {

    device    /dev/drbd0;

    disk      /dev/sdb1;

    address   10.0.0.2:7788;

    meta-disk internal;

  }

} resource data2 {

  protocol C;

  startup {

    degr-wfc-timeout 120;    # 2 minutes.

  }

  disk {

    on-io-error   detach;

  }

  net {

  }

  syncer {

    rate 100M;

    al-extents 257;

  }

  on Atlantis {

    device     /dev/drbd1;

    disk       /dev/sdc1;

    address    10.0.0.1:7789;

    meta-disk  internal;

  }

  on Dedalos {

    device    /dev/drbd1;

    disk      /dev/sdc1;

    address   10.0.0.2:7789;

    meta-disk internal;

  }

}

Como se observa, se ha nombrado otro dispositivo virtual como /dev/drbd1, se usan los discos /dev/sdc1 y lo más importante, se utiliza la misma dirección IP pero con distinto puerto, esto quiere decir que no hace falta interfaces adicionales por cada recurso añadido, si bien puede ser recomendable en caso de disponer de interfaces Ethernet de sobra.

Ahora se procederá a la sincronización del nuevo par de discos con las mismas órdenes que se usaron para sincronizar el primer par de discos, a saber:

1) Se desmontan los dispositivos /dev/sdc1 de cada servidor (si estuvieran montados)

2) En ambos nodos creamos una nueva área de metadatos en los discos:

drbdadm create-md data2

3) En ambos nodos levantamos el recurso "data2"

drbdadm up data2

4) En el nodo primario indicamos que va a ser el primario del nuevo dispositivo /dev/drbd1

drbdsetup /dev/drbd1 primary -o

5) Comprobamos que el segundo par de discos se estan sincronizando:

Atlantis:/# cat /proc/drbd version:  8.2.4 (api:88/proto:86-88)  GIT-hash: fc00c6e00a1b6039bfcebe37afa3e7e28dbd92fa build by root@Atlantis, 2008-01-22 13:08:17   0: cs:Connected st:Primary/Secondary ds:UpToDate/UpToDate C    r---     ns:180 nr:0 dw:180 dr:540822 al:3 bm:0 lo:0 pe:0    ua:0 ap:0            resync: used:0/31 hits:0 misses:0 starving:0 dirty:0 changed:0   act_log: used:0/257 hits:42 misses:3 starving:0 dirty:0 changed:3 1: cs:SyncSource st:Primary/Secondary ds:UpToDate/Inconsistent C  r---     ns:184973828 nr:0 dw:0 dr:184981440 al:0 bm:11289 lo:1  pe:261 ua:238 ap:0   [========>...........] sync'ed: 47.4% (200909/381539)M          finish: 0:40:49 speed: 83,808 (63,888) K/sec          resync: used:2/31 hits:11549551 misses:11291 starving:0 dirty:0  changed:11291  act_log: used:0/257 hits:0 misses:0 starving:0  dirty:0 changed:0 

Como se observa, hay un recurso "0", que se sincronizó anteriormente, y un recurso "1", que es el que se esta sincronizando. Tras terminar la sincronización del segundo par de discos, comprobaremos que se puede acceder sin problemas:

Atlantis:/# mount /dev/drbd1 /data2

Atlantis:/# df -h

S.ficheros          Tamaño Usado  Disp Uso% Montado en

/dev/sda1             179G  2,3G  168G   2% /

tmpfs                 2,0G     0  2,0G   0% /lib/init/rw

udev                   10M   72K   10M   1% /dev

tmpfs                 2,0G     0  2,0G   0% /dev/shm

/dev/drbd0            367G  723M  348G   1% /data  /dev/drbd1            367G  723M  348G   1% /data2

Espero que este sencillo manual haya ayudado a quien lo haya leido, con mi experiencia he de decir que DRBD es mucho más sencillo y versatil que rsync para sincronizar los datos de dos servidores.

PD: Por lo menos hay una entrada en español de Google de DRBD que no tiene que ver con la serie de RBD, hasta en la sopa...

PD2: Por los cojones esto es WYSIWYG -.-' si hay cosas que no se ven, es por wordpress. Que yo soy de sistemas, no un diseñador.