Andrés Rodríguez

Hey all. Sorry for the delay in posting this tutorial, I’ve been pretty busy and I finally had some time to finish it. Enjoy :).

Well, as you may know, in previous posts (Post 1, Post 2) I’ve showed you how to install and configure DRBD in an active/passive configuration with failover, automatically, using Heartbeat. Now, I’m going to show you how to use that configuration to export the data stored in the DRBD device (make it available for other servers in a network) using NFS.

So, the first thing to do is to install NFS in both drbd1 and drbd2, stop the daemon, and remove it from the upstart process (This means that we’ll have to remove the NFS daemon from starting during the boot up process). We do this as follows in both servers:

:~$ sudo apt-get install nfs-kernel-server nfs-common
:~$ sudo /etc/init.d/nfs-kernel-server stop
:~$ sudo update-rc.d -f nfs-kernel-server remove
:~$ sudo update-rc.d -f nfs-common remove

Now, you may wonder how is NFS going to work. The NFS daemon will be working only in the active (or primary) server, and this is going to be controlled by Heartbeat. But, since NFS stores information in /var/lib/nfs, on each server, we have to make both servers have the same information. This is because if drbd1 goes down, drbd2 will take over, but its information in /var/lib/nfs will be different from drbd1’s info, and this will stop NFS from working. So, to make both servers have the same information in /var/lib/nfs, we are going to copy this information to the DRBD device and create a symbolic link, so that the information gets stored in the DRBD device and not in the actual disk. This way, both servers will have the same information. To do this, we do as follows in the primary server (drbd1):

mv /var/lib/nfs/ /data/
ln -s /data/nfs/ /var/lib/nfs
mkdir /data/export

After that, since we already copied the NFS lib files to the DRBD device in the primary server (drbd1), we have to remove them from the secondary server (drbd2) and create the link.

rm -rf /var/lib/nfs/
ln -s /data/nfs/ /var/lib/nfs

Now, since Heartbeat is going to control the NFS daemon, we have to tell Heartbeat to start the nfs-kernel-server daemon whenever it takes the control of the server. We do this in /etc/ha.d/haresources and we add nfs-kernel-server at the end. The file should look like this:

drbd1 IPaddr::172.16.0.135/24/eth0 drbddisk::testing Filesystem::/dev/drbd0::/data::ext3 nfs-kernel-server

Now that we’ve configured everything, we have to power off both servers, first the secondary and then the primary. Then we start the primary server, and during the boot up process we’ll see a message that will require us to type “yes” (This is the same message showed during the installation of DRBD in my first post).  After confirming, and If you have stonith configured, it is probable that drbd1 wont start its DRBD device, so it will remain as secondary, and won’t be able to mount it. This is because we will have to tell stonith to take over the service (To see if stonith is the problem, we can take a look at /var/log/ha-log). So, to do this, we do as follows in the primary server (drbd1):

meatclient -c drbd2

After doing this, we have to confirm. After the confirmation, Heartbeat will take the control, change the DRBD device to primary, and start NFS. Then, we can boot up the secondary server (drbd2). Enojy :-).

Note: I made the choice of powering off both servers. You could just restart them, one at a time, and see what happens :).

CISAISI 2008 (Congreso Internacional Sud-Americano de Ingeniría de Sistemas, Computación e Informática 2008), is an International Latin American event of Systems Engineers, Computing and Informatics. This event is on its XII edition and it will be in Arequipa - Perú, from the 6 to the 10th of October, at Universidad Católica de Santa María - UCSM, which is the University where I’ve studied.

This event was created to do courses and debates, give conferences and summit scientific work. On the present edition of the CISAISI 2008, a new feature has been added, which is the “Poster Contest”, that allows young people, such as students, to summit any scientific work they are working on, related to Informatics.

On this edition, I summited my Thesis as a paper for this “Poster Contest”. This means that I’ll be presenting my Thesis (”Designing a Model to Implement High Availability Web Servers”), and talk about it during the event. This event is very important because many people from different cities around Latin America are going to be present. This is a good chance to promote Ubuntu in Cluster utilization, since my Thesis was done creating clusters in Ubuntu. This will show to many people that Linux, and specially Ubuntu, is a powerful OS to create High Availability Clusters. This will also introduce DRBD to the Latin American Market.

So, whish me luck!! :).

As you may know, I applied for JJ UDS Sponsorship. I think that today was the last that people could summit their ideas. But, people can still support them I guess. Since I have been pretty busy the past few days, I just got some time to explain my ideas a little more.

My first idea is Centralized Cluster Administration. This idea is related to the creation of an application that will help us implement and manage LVS Based Clusters. I got this idea because, as you may know, I did my thesis about Designing a Model to Implement High Availability Web Servers using LVS based clusters.

My second idea is Ubuntu Centralized Image Installation/Recovery/Backup. This idea is related to the creation of an application that will help us install Ubuntu from a centralized server on a LAN, similar to what RIS is. It will also allow us to create images, and be able to recover them and create backups, and so on.

So, if you think they are good ideas, it would be great to have your support. Thanks :).

After a few weeks of being very very busy… I finally have finished most of the things I had to do and finally have some time to continue contributing to Ubuntu.

The first thing I’ve done, is to add some ideas to brainstorm and apply for JJ UDS Sponsorship. My Ideas are the following:

• Ubuntu Centralized Image Installation/Recovery/Backup
• Centralized Cluster Administration

Now, as you may know, translations are open again so let’s start translating.

And finally, I need to request my MOTU mentorship again, since I had to leave it while I was busy… so during this week… I might be restarting my Mentorship Process.

For those who have been waiting me to finish the article of DRBD/NFS and DRBD/MySQL… I will post it soon :).

Btw, if someone who works in FIU (Florida International University) gets to read this, and is willing to help me with information in admissions/assistanships (MS in Telecommunications & Networking or Computer Science) and stuff like that, please contact me or leave me your contact information. Thanks :).

As you know, in a previous post I showed how to install DRBD in Hardy Heron, in an active/passive configuration. Now, I’m gonna show you how to install and configure Heartbeat to automatically monitor this active/passive configuration, and provide High Availability. This means I’ll show you how to integrate DRBD in a simple Heartbeat V1 configuration, and as a plus, I’ll show you how to use the meatware software provided by STONITH.

To do this, we have to install Heartbeat and make changes in three files, which are /etc/ha.d/ha.cf, /etc/ha.d/haresources and /etc/ha.d/authkeys. First of all we install Heartbeat as follows, in both nodes:

sudo apt-get install heartbeat-2

After the installation is completed, the first file we need to configure, in both nodes, is /etc/ha.d/ha.cf as follows:

logfile /var/log/ha-log
keepalive 2
deadtime 30
udpport 695
bcast eth0
auto_failback off
node drbd1 drbd2

Note: Notice that the auto_failback option is in off. This means that if the drbd1 fails, drbd2 will take control over the service, and if drbd1 comes back online, drbd2 will not failback to drbd1 and drbd2 will remain as the active node.

Now, as you know this is an active/passive configuration, so we have to decide which node is going to be the primary and which node is going to be the secondary one, for the Heartbeat configuration. (If you have followed my previous post, the drbd1 node is going to be our primary node, and drbd2 will be our secondary node). We also have to consider here is where are we going to mount the DRBD resource in our filesystem, and which IP address is going to used as the VIP (The Virtual IP is going to be used to access a service, or a DRBD resource, over the network, since we are going to use DRBD for NFS and/or MySQL).

So, assuming drbd1 is the primary node, the VIP is 172.16.0.135 and we are going to mount the DRBD resource in /data (so create the directory in both nodes), we edit /etc/ha.d/haresources as follows, in both nodes:

drbd1  IPaddr::172.16.0.135/24/eth0 drbddisk::testing Filesystem::/dev/drbd0::/data::ext3

Note: Notice that we are specifying the DRBD resource with the drbddisk option.

Then, we have to edit the /etc/ha.d/authkeys file, which is going to be used by Heartbeat to authenticate with the other node. So, we edit it as follows in both nodes:

auth 3
3 md5 DesiredPassword

Finally, we change file permissions to this last file as follows:

sudo chmod 600 /etc/ha.d/authkeys

Now that we have both nodes configured, I recommend you to power off both nodes and boot the node we want to have as primary. In our case, it is drbd1. After booting up this node, we need to verify that Heartbeat has started the DRBD resource (we can see this with cat /proc/drbd) and mounted it in /data. If it has, start the secondary node and verify that it is the secondary one.

If everything has gone right, try the failover process powering off the primary node. You will notice that the node that had the DRBD resource as secondary, it’s now the primary one and it has control over the service. Also verify is the VIP address is working (should appear as eth0:0 issuing ifconfig).

After verifying everything is working as expected, it is always recommendable to have a Fencing device to ensure data integrity. This fencing device will prevent an Split-Brain condition. A well-known Fencing mechanism is known as STONITH (Shoot the Other Node in the Head). This mechanism will basically power off or reset a node which is supposed to be dead. This means that if drbd1 is supposed to be dead, drbd2 will take control of the service or, in this case, the DRBD resource. But, if drbd1 is not actually dead and drbd2 tries to take control over the shared DRBD resource, an Split-Brain condition will occur. So STONITH will ensure that drbd1 has been reseted or powered off so that drbd2 can take control of the DRBD resource.

To do this, there is an stonith package that is used to work with STONITH/Fencing devices in Heartbeat. But, since we don’t have a real Fencing device, we will use meatware. Meatware is a software provided by STONITH, that simulates the use of a STONITH/Fencing device, by not allowing the secondary node (drbd2) to take control over the shared resources If there has not been a confirmation that the primary node (drbd1) has been powered off or rebooted. This requires operator intervention. So to integrate the meatware software with Heartbeat we do as follows:

sudo apt-get install stonith

Then, we have to modify /etc/ha.d/ha.cf like this (in both nodes):

... [Output Ommitted]
auto_failback off
stonith_host drbd1 meatware drbd2
stonith_host drbd2 meatware drbd1
node drbd1 drbd2

Then we power off the primary node (in this case drbd1) and reboot secondary node (drbd2). After reboot, take a look at /var/log/ha-log until you see something like this:

As you can see, STONITH is sending a message that says that we need to confirm that drbd1 has been rebooted so that drbd2 can take control over the service. So, take a look at /proc/drbd and you will see that the DRBD resource is still as secondary. So, we do as follows:

sudo meatclient -c drbd1

And we will see something like this:

Now, we confirm that it has been rebooted and we can now see that drbd2 will take control of the resource by setting the DRBD resource as primary (cat /proc/drbd).

So we can now start drbd1. Everytime the primary node fails, the secondary node will display a message on /var/log/ha-log saying that we should confirm that the primary has been rebooted so that the secondary can take control of the service and become the new primary.

In a next post I’ll cover how to make NFS make use of DRBD. Any comments, suggestions, etc, you know where to find me :).

DRBD (Distributed Replicated Block Device) is a technology that is used to replicate data over TCP/IP. It is used to build HA Clusters and it can be seen as a RAID-1 implementation over the network.

As you may all know, the DRBD kernel module has now been included into Hardy Heron Server Edition’s kernel, so there is no more source downloading and compiling, which makes it easier to install and configure. Here I’ll show you how to install and and make a simple configuration of DRBD, using one resource (testing). I’ll not cover how to install and configure heartbeat for automatic failover (This will be showed in a next post).

First of all, we will have to install Ubuntu Hardy Heron Server Edition on to servers and manually edit the partition table. We do this to leave FREE SPACE that we will be used later on as the block device for DRBD. If you’ve seen the DRBD + NFS HowTo on HowToForge.com, creating the partitions for DRBD and leaving them unmounted will NOT work, and we won’t we able to create the resource for DRBD. This is why we leave the FREE SPACE, and we will create the partition later on, when the system is installed.

So, after the installation we will have to create the partition, or partitions (in case we are creating an external partition for the meta-data, but in this case it will be internal), that DRBD will use as a block device. For this we will use fdisk and do as follows:

fdisk /dev/sda
n (to create a new partition)
l83 (to create it as logical and format it as Filesystem # 83)
w (to write the changes)

After creating the partitions we will have to REBOOT both servers so that the kernel uses the new partition table. After reboot we have to install drbd8-utils on both servers:

sudo apt-get install drbd8-utils

Now that we have drbd8-utils installed, we can now configure /etc/drbd.conf, which we will configure a simple DRBD resource, as follows:

resource testing { # name of resources

protocol C;

on drbd1 { # first server hostname
device /dev/drbd0; # Name of DRBD device
disk /dev/sda7; # Partition to use, which was created using fdisk
address 172.16.0.130:7788; # IP addres and port number used by drbd
meta-disk internal; # where to store metadata meta-data
}

on drbd2 { # second server hostname
device /dev/drbd0;
disk /dev/sda7;
address 172.16.0.131:7788;
meta-disk internal;
}

disk {
on-io-error detach;
}

net {
max-buffers 2048;
ko-count 4;
}

syncer {
rate 10M;
al-extents 257;
}

startup {
wfc-timeout 0;
degr-wfc-timeout 120; # 2 minutos.
}
}

Note that we are using drbd1 and drbd2 as hostnames. This hostnames must be configured and the servers should be able to ping the other via those hostnames (that means we need to have a DNS server or configure hosts for both servers in /etc/hosts).

After creating the configuration in /etc/drbd.conf, we now can create the DRBD resources. For this we issue the following in both servers:

sudo drbdadm create-md testing

After issuing this, we will be asked for confirmation to create the meta-data in the block device.

Now we have to power off both servers. After powering them off, we start our first server and we will see something similar to this:

After confirming with ‘yes’, we can now start the second server. After the second server is running. both nodes resources are secondary, so we have to make one of them primary. For this, we issue the following on the server we would like to have the resource as primary:

drbdadm -- --overwrite-data-of-peer primary all

We verify this by issuing:

cat /proc/drbd

And this should show something like this:

Well, up to this point, i’ve have showed you how to install and configure DRBD on Hardy, and how to make one of the servers have its resource as primary. But, we still don’t have automatic failover or automatic mounting. In a next post I’ll show how to configure heartbeat to have automatic failover and to take control of the resources, aswell as configuring STONITH to use the meatware device, so that we won’t have a split-brain condition (or at least try). I’ll also show how to configure NFS and MySQL to use this DRBD resource.

BTW, if you have questions you know where to find me :).

Today, just few hours ago I received a notification from Nicolás Valcarcel (nxvl), who is part of the MOTU Mentors Reception Board, telling me that I have been assigned a MOTU Mentor for the Junior Mentoring Program.

When he told me that I had a mentor already, I just felt that things are going the way I planned :). My mentor is Steven Stalcup (vorian), and even though he loves KDE and I love GNOME, we will get along :). Every package is good to work with while someone is learning, but I’m really interested on Server Related stuff.

So if anyone has a suggestion for my learning process don’t hesitate to contact me. I set up a wikipage,  where I’ll keep track of everything I’ll do through the mentoring process. I already have a first task… read the Debian New Maintainer’s Guide. Should be easy since I already have worked with some tools and done some merges. But anyways… wish me luck :).

Well as you may know, I had to support my thesis yesterday (July 16) in Arequipa - Peru, at “Universidad Católica de Santa María”. I’ve been approved and finally I became an engineer in Systems Engineering.

As I said in a previous post, my thesis was about High Availability Clusters. Actually, it was about designing a Model to Implement High Availability Cluster for Web Servers. My model consists on three Layers, which provide fault tolerance (High Availability) and scalability. Everything was done using 6 Ubuntu Servers virtualized on VMWare.

Layer 1 consists in two servers in an active/passive mode. This Layer provides fault tolerance, which can be interpreted as high availability, but does not provide scalability. I used LVS (using DIrect Routing) to load balance between Web Servers on Layer 2. I also used Heartbeat, ipvsadm and ldirectord.

Layer 2 consists in 4 Web Servers (can be more), in an active/active mode. This layer provides high availability and scalability. This layer also allows us to use every kind of web server (including Windows Server), because load balancing is done in Layer 2 of OSI Model (thanks to the Direct Routing method).

And layer 3 consists on two servers in an active/passive mode, to provide data access. Here I used NFS and MySQL, to provide file access and database access on both servers, and I used DRBD to provide data replication between them. The monitoring was done by using Heartbeat. This layer also provides fault tolerance but not scalability. To provide fencing in this layer I used meatware, which is provided by STONITH for heartbeat.

As you can see, this is a classical implementation of High Availability Clusters using LVS. For some of you might be an everyday thing, but not here in Peru. This is because because there aren’t lots of organizations and companies, or even Linux experts, who know how to implement Linux based clusters (besides banks). My thesis allows those who want to know how to create them, and shows that Microsoft and Red Hat, are not the only OS’s where we can create High Availability Clusters. This also shows how powerful is DRBD when we don’t have the possibility to work with SANs or other data storage technology.

Thanks to all the developers who created these great tools, that allows us to create Linux Based High Availability Clusters, and also thanks to the Ubuntu Community to provide these packages. This made my life easier :D.

And well… now i’m unemployed and with nothing to do but contribute to Ubuntu (I guess i’ll search a job as a Sysadmin or Network admin). But finally i have more time to concentrate myself to learn more about Ubuntu Development.

Finally, after 6 months of being doing nothing but partying, contributing to Ubuntu, and finishing my thesis (not working)… I’m about to support it, tomorrow (July 16) at noon (GMT -5).

My thesis is about High Availabily Clusters and I’m glad to say that it was done using Ubuntu Servers Over VMWare. Configuration and installation was kinda hard, because it was hell to administer every single Server without a centralized administration application, but it was lots of fun.

This made me realize that we really need a Cluster Administration Application for Ubuntu servers (if it does not exist already), so that LVS based clusters can be installed as simple as using Ubuntu :).

But, anyways… wish me luck… cause tomorrow I’ll become an Engineer in Systems Engineering.