Jun 282011
 

After I wrote about Maildir replication, using ChironFS and DRBD, this time I will write how to make maildir replication, using a very well known program utility called rsync. basically, rsync itself, does not do realtime replication process. rsync only perform the synchronization/copy process when needed or scheduled by using the crontab. like cp, rsync is used to copy files from one directory to another directory in one system, or to a directory on another system. and vice versa.

How do we make the process of replication/copy that is almost realtime by using rsync?

we will use the inotify-tools (inotifywait) to monitor changes to system files or directories, in this case is the postfix maildir. Inotify has been included in the mainline Linux kernel from release 2.6.13 (June 18, 2005), and could be compiled into 2.6.12 and possibly earlier releases by use of a patch.

What is inotify?

Inotify is a Linux kernel subsystem that acts to extend filesystems to notice changes to the filesystem, and report those changes to applications. It replaces an earlier facility, dnotify, which had similar goals.

OK, without further ado, let’s continue with the first step, install inotify-tools. on my centos machine, it can be done in the following way.

$ sudo yum -y install inotify-tools

Assume that we have two servers, first server contains a postfix + maildir. second servers is used to backup maildir from the first server. using inotifywait, any changes in the maildir on first server will trigger rsync to update the maildir on the backup server. However, first we will make rsync can do the login automatically to the backup server via ssh using Public Key Based Authentication.

On First server

[first_server] $ ssh-keygen -t dsa -f ~/.ssh/identity && cat ~/.ssh/identity.pub | ssh -l postfix second_server -p 12345 'sh -c "cat - >>~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"'

Continue reading »

Jul 082008
 

RAID: That it is; What it does

RAID is something all of us have heard about but very few of us understand, at leastfully. So lets get off on the right foot. RAID stands for Redundant Array of Inexpensive (or Independent) Disks. There are a dozen or so theories as to why RAID was conceptualized, but the most accepted reason is that once upon a time, not long ago, disks were small and  expensive. In order to provide a large amount of data you had to have a bunch of disks all mounted in a single file tree, which was a real mess. So, to solve this problem RAID was born. With RAID you could take a bunch of disks at create a big virtual disk out of them which made administration much easier and more logical. Over time RAID grew to include new solutions for old problems, like disk performance, redundancy, and scalability. And for any skeptics out there, tell me where I can get a 10 terabyte disk drive…. that should make us all agree that RAID has a place in the universe.

Just to try and clear things up a bit more, lets see why we don’t simple just need RAID, but actually WANT it. Let’s say we’re building a production NFS server that will be used to store all of our software. We’ll need this system to extremely stable, because if it goes down no one can get or submit code. With RAID we could build a single virtual disk (volume) that would meet our need for 200G of disk. But we also what to make sure that if disks die that we don’t go down. So we use a mirror (another set of disks identical to the first set of disks). If a disk dies we’re okey, because the mirror will take over; we essentially have 2 identical sets of the same data which are constantly kept up to date. See? Using these 2 simple RAID concepts we’ve achieved both availability (thats our mirror saving us from disk crashes) and increased capacity (we’ve got a whole bunch of disks working together, which is cheaper than buying a single 200G disks… if you can find one!).

Okey, enough of the bad examples. Lets look at the different forms of RAID in use today.

RAID: The Details

Continue reading »