RAID Theory
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
Building RPM packages as user
Load Balancing Dual DSL Speedy di Satu Router
source: http://yulian.firdaus.or.id/2007/09/07/load-balance-speedy/
Banyak pertanyaan dari teman-teman, terutama para operator warnet, admin jaringan sekolah/kampus dan korporasi tentang load balancing dua atau lebih koneksi internet. Cara praktikal sebenarnya banyak dijumpai jika kita cari di internet, namun banyak yang merasa kesulitan pada saat diintegrasikan. Penyebab utamanya adalah karena kurang mengerti konsep jaringan, baik di layer 2 atau di layer 3 protokol TCP/IP. Dan umumnya dual koneksi, atau multihome lebih banyak diimplementasikan dalam protokol BGP. Protokol routing kelas ISP ke atas, bukan protokol yang dioprek-oprek di warnet atau jaringan kecil.
Berikut beberapa konsep dasar yang sering memusingkan:
1. Unicast
Protokol dalam trafik internet yang terbanyak adalah TCP, sebuah komunikasi antar host di internet (praktiknya adalah client-server, misal browser anda adalah client maka google adalah server). Trafik ini bersifat dua arah, client melakukan inisiasi koneksi dan server akan membalas inisiasi koneksi tersebut, dan terjadilah TCP session (SYN dan ACK).
2. Destination-address
Dalam jaringan IP kita mengenal router, sebuah persimpangan antara network address dengan network address yang lainnya. Makin menjauh dari pengguna persimpangan itu sangat banyak, router-lah yang mengatur semua trafik tersebut. Jika dianalogikan dengan persimpangan di jalan, maka rambu penunjuk jalan adalah routing table. Penunjuk jalan atau routing table mengabaikan “anda datang dari mana”, cukup dengan “anda mau ke mana” dan anda akan diarahkan ke jalan tepat. Karena konsep inilah saat kita memasang table routing cukup dengan dua parameter, yaitu network address dan gateway saja.
3. Source-address
Source-address adalah alamat IP kita saat melakukan koneksi, saat paket menuju ke internet paket akan melewati router-router ISP, upstream provider, backbone internet dst hingga sampai ke tujuan (SYN). Selanjutnya server akan membalas koneksi (ACK) sebaliknya hingga kembali ke komputer kita. Saat server membalas koneksi namun ada gangguan saat menuju network kita (atau ISPnya) maka komputer kita sama sekali tidak akan mendeteksi adanya koneksi. Seolah-olah putus total, walaupun kemungkinan besar putusnya koneksi hanya satu arah.
QMT Failover replication Setup
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.
How To Compile A Kernel – The CentOS Way
Version 1.0
Author: Falko Timme <ft [at] falkotimme [dot] com>
Last edited 11/23/2006
Each distribution has some specific tools to build a custom kernel from the sources. This article is about compiling a kernel on CentOS systems. It describes how to build a custom kernel using the latest unmodified kernel sources from www.kernel.org (vanilla kernel) so that you are independent from the kernels supplied by your distribution. It also shows how to patch the kernel sources if you need features that are not in there.
I have tested this on CentOS 4.4.
I want to say first that this is not the only way of setting up such a system. There are many ways of achieving this goal but this is the way I take. I do not issue any guarantee that this will work for you!
Nano-Howto to use more than one independent Internet connection.
Nano-Howto to use more than one independent Internet connection.
by Christoph Simon
v1.0, Dec 2, 2001
—————————————————————-
1. Intro
========
1.0 Thanks
———-
The solution presented here is based on the patches by Julian Anastasov. Like several other users on the net struggling with this, I believe they fill in yet another gap for using Linux as a very advanced router. It was hard for me not only to get this running for the first time, but also to understand most of the principles. Also in this Julian has proofed to have unlimited patience. Thanks. He also agreed to expose this file on his site:
How To get A centos Kernel source
1. Maybe you do not need the full kernel source
If you need to compile a kernel driver module, the chances are you do not really need the full kernel source tree. You might just need the kernel-devel package. (If, however, you are certain that the full source tree is required, please follow the instructions in Section 2.)
In CentOS-5, there are three kernel-devel packages available:
- kernel-devel (both 32- & 64-bit architectures)
- kernel-xen-devel (both 32- & 64-bit architectures)
- kernel-PAE-devel (32-bit architecture only)
In CentOS-4, there are four kernel-devel packages available:
- kernel-devel (both 32- & 64-bit architectures)
- kernel-smp-devel (both 32- & 64-bit architectures)
- kernel-xenU-devel (both 32- & 64-bit architectures)
- kernel-hugemem-devel (32-bit architecture only)
- kernel-largesmp-devel (64-bit architecture only)
If you are running the standard kernel (for example), you can install the kernel-devel package by:
Anatomy of the Linux kernel
http://www.ibm.com/developerworks/linux/library/l-linux-kernel/
History and architectural decomposition
M. Tim Jones (mtj@mtjones.com), Consultant Engineer, Emulex Corp.
The Linux® kernel is the core of a large and complex operating system, and while it’s huge, it is well organized in terms of subsystems and layers. In this article, you explore the general structure of the Linux kernel and get to know its major subsystems and core interfaces. Where possible, you get links to other IBM articles to help you dig deeper.
Given that the goal of this article is to introduce you to the Linux kernel and explore its architecture and major components, let’s start with a short tour of Linux kernel history, then look at the Linux kernel architecture from 30,000 feet, and, finally, examine its major subsystems. The Linux kernel is over six million lines of code, so this introduction is not exhaustive. Use the pointers to more content to dig in further.