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 »

Jul 082008
 

source: http://wiki.qmailtoaster.com/index.php/QMT_Failover_replication_Setup

QMT Failover replication Setup

Craig Smith – 26th October 2006 – craig@doc-net.com

Thanks to Jake for taking the time to review this for me before posting. It always helps to have a sounding board and Jake was kind enough to be that board for me.

This page gives you a procedure to configure a backup qmt server that will be available for failover in the event of primary server failure. The backup server will only ever be 10 minute out from the primary.(depending on cronjob timing)

Please note initial replication (the first run) will take some time, so schedule this for off peak hours. Once the first run has finished and unison has a db of what it is working with subsequent runs are pretty quick. So enable the cron job settings at a time that you can manage the traffic for initial replication.

Also this setup is based on 2 servers where the port used is internal and not visible publically. If you cannot do this on a private network, then read up on using ssh for replication as this is not a secure transport and should not be used on open networks.

This was setup and tested on Fedora core 5 on both servers, and it works without any hiccups.

The details are pretty much cut and paste.

Continue reading »