راهاندازی یک گروه سرور (cluster)
با رشد انفجاری اینترنت، کار بر روی سرورهای وب، ایمیل و مدیا افزایش مییابد. سایتهای زیادی در حال مبارزه برای حفظ کردن خود در برابر تقاضاهای رو به رشد هستند و تکنیکهای زیادی را برای جلوگیری از overload شدن سرورهای خود به کار میگیرند. راهاندازی یک سرور بر روی یک گروه کامپیوتر (cluster) یکی از راههایی هست که بطور موثر مورد استفاده قرار میگیرد. با این روش در صورت لزوم میتوان با اضافه کردن یک سرور جدید به گروه سرورهای موجود، تقاضاهای بیشتر را به راحتی مدیریت کرد...
[CENTER]
[IMG]http://www.newsforge.com/blob.pl?id=4172ff8f7016509d8e6ef2e0d7861832[/IMG][/CENTER]
برای درک بهتر این مفهوم قشنگ ما حصل جستجو ی خود را به صورت پیوسته تقدیم می کنم به این امید که با الطفات شما این مطلب قشنگ مفید واقع شود:
برپا سازی کلاسترهای OpenMosix
جهت برپا سازی یک کلاستر، شما به حداقل دو دستگاه مبتنی بر لینوکس که به یک شبکه داخلی متصل بوده و قادر به کامپایل کردن و اجرای هستههای سری 2.4 باشند، نیاز دارید. همچنین شبکه شما باید دارای حداقل سرعت ۱۰۰ مگابیت باشد. این سرعت به شما سرعت بسیار خوبی را اعطا خواهد نمود. سرعت اترنت استاندارد یعنی ۱۰ مگابیت به شما سرعت چندان جالب توجهی نخواهد داد. البته در صورتی که شبکه شما از این نوع است و مایل هستید تا فقط OpenMosix را تجربه نمایید، پاسخگو خواهد بود. استفاده از اترنتهای گیگابیت مفید بوده ولی انتخابی است. البته ممکن است واقعا به آن نیاز نداشته باشید و اترنت ۱۰۰ مگابیت امور شما را به خوبی انجام دهد.
اتصال گرههای کلاستر به یک سوئیچ پرسرعت سیستمهای شما را قادر خواهد ساخت تا در حالت Full Duplex عمل نموده و پهنای باند شما دو برابر گردد. همچنین میتوانید در یک کلاستر ۲ یا ۳ گرهای از سیم کشی مخصوص جهت اتصال مستقیم گرهها به هم استفاده نمایید.
داشتن فضای Swap کافی قویا توصیه میشود. به این صورت شما قادر خواهید بود تا گرهها را بصورت دینامیک از کلاستر خارج نمایید بدون اینکه با کمبود حافظه مواجه شوید. این موضوع نیز انتخابی بوده و ممکن است در شرایط خاصی که کلاستر تحت فشار کاری بالایی قرار دارد، به شما کمک کند.
در کنار مطالب بالا، باز هم اضافه میکنم که امکان ایجاد یک کلاستر مبتنی بر فقط دو دستگاه لینوکس و یک اترنت استاندارد نیز وجود دارد.
لازم نیست که تمام کامپیوترهایی که در یک کلاستر قرار میگیرند قوی باشند و یا مهم نیست که دارای سختافزارهای متنوعی باشند. هر قدرت پردازشی میتواند به سرعت جمعی کمک کند!
شروع کار
فرایند برپاسازی کلاسترهای لینوکس بسیار ساده میباشد. ابتدا باید هستههایی که OpenMosix روی آنها فعال شدهاند را روی گرههای کلاسترها نصب کرده و سپس ابزارهای کاربری را روی همه آنها نصب کرده و یک تنظیم کوچک در یک فایل پیکربندی انجام دهیم.
به عنوان نخستین مرحله از کار، باید ابزارهای نرمافزاری لازم را فراهم آورید. نخستین چیزی که به آن نیاز دارید، کد منبع هستهای است که مایلید روی آن کار کنید. کد منبع هسته خود را میتوانید از [url]http://kernel.org[/url] دریافت نمایید. من برای اجرای پروژه، از هسته 2.4.23 استفاده کردهام. در قدم بعدی باید وصلههای هسته OpenMosix و سپس ابزارهای نرمافزاری OpenMosix را دریافت نمایید. برای دانلود وصلههای هسته OpenMosix میتوانید به سایت رسمی آن در آدرس [url]http://openmosix.sf.net[/url] یا [url]http://openmosix.org[/url] مراجعه کنید و یا از لینکهای زیر برای هستههای مورد نظرتان استفاده کنید:
هسته 2.4.21:[url]http://tab.tuxfamily.org/download/openmosix/releases/patch-2.4.21-om-20030825.bz2[/url]
هسته 2.4.22:[url]http://tab.tuxfamily.org/download/openmosix/releases/patch-2.4.22-om-20031215.bz2[/url]
هسته 2.4.23:[url]http://tab.tuxfamily.org/download/openmosix/stable/patch-2.4.23-om-20031215.bz2[/url]
هسته 2.6.0 (آزمایشی):[url]http://tab.tuxfamily.org/download/openmosix/unstable/patch-2.6.0-om-0.20031202.1.bz2[/url]
ابزارهای نرمافزاری:[url]http://umn.dl.sourceforge.net/sourceforge/openmosix/openmosix-tools-0.3.5.tar.bz2[/url]
فراموش نکنید که همیشه میتوانید جدیدترین نسخههای وصله هسته و ابزارهای نرمافزاری OpenMosix را از سایت رسمی آن دریافت نمایید. پس از اتمام دریافت تمامی اقلام مورد نیاز (تنها کد منبع هسته دارای حجم زیادی است و بقیه ابزارها همگی بین ۲۰۰ تا ۳۰۰ کیلوبایت ظرفیت دارند!) باید تجهیز گرههای کلاستر را شروع کنید. ابتدا لازم است در شبکه محلی خود کامپیوترهایی را که مایلید به عنوان گرههای کلاستر استفاده کنید، تعیین نمایید. من در دفتر کار خود دو دستگاه را برای این منظور انتخاب کردم:
[CENTER][IMG]http://www.technotux.org/images/cluster.png[/IMG][/CENTER]
همانطوری که قبلا اشاره کردم، لازم نیست که گرههای کلاستر حتما قویترین ایستگاههای کاری روی شبکه باشند. دستگاههای انتخابی من دارای مشخصات زیر هستند:
[LEFT]Node No.1 : Debian (LAN SERVER)
CPU : P-III 800 MHz
RAM: 128 MB SD-RAM
NIC : SIS 100 Mbps
HDD: 2x40GB
Distro : Debian GNU/Linux 3.0 (woody)
Kernel: 2.4.23 (will be 2.4.23-om)
Node No.2 : Cyber (Workstation)
CPU : Celeron 333 MHz
RAM: 160 MB SD-RAM
NIC : D-Link 100 Mbps
HDD: 1x6.4GB
Distro : Libranet GNU/Linux 2.8.1
Kernel: 2.4.21 (will be 2.4.23-om)
[/LEFT]
پس از تعیین گرههای کلاستر، شروع به نصب نرمافزارهای لازم برای این کار میکنیم. این عملیات را برای تمام گرهها باید تکرار کرد. برای شروع هسته OpenMosix را نصب میکنیم. ابتدا کد منبع هسته را در آدرس usr/src کپی کرده و آنرا با استفاده از دستورهای زیر باز میکنیم:
[LEFT] cd /usr/src
# bzip2 -d linux-2.4.23.tar.bz2
# tar -xf linux-2.4.23.tar
# mv linux linux.old
# ln -s linux-2.4.23 linux[/LEFT]
سپس وصله هسته را در کد منبع خود اعمال میکنیم:
[LEFT]cd linux
# cat /home/alan/patch-2.4.23-om-20031215.bz2 | bzip2 -d | patch -p1 -l[/LEFT]
کد منبع هسته در چند ثانیه وصله خواهد شد. اکنون میتوانید طبق روالهای گذشته هسته را پیکربندی و کامپایل نمایید. فقط اطمینان حاصل کنید که گزینههای زیر را در بخش OpenMosix پیکربندی هسته انتخاب کنید:
[LEFT] openMOSIX process migration support[*] Stricter security on openMOSIX ports[*] openMOSIX File-System[*] Poll/Select exceptions on pipes[/LEFT]
برای شروع پیکربندی هسته، دستور زیر را وارد نمایید:
[LEFT]
# cd /usr/src/linux
# make menuconfig
[/LEFT]
پس از اتمام پیکربندی و ذخیره تغییرات، برای کامپایل شدن هسته دستورات زیر را وارد نمایید:
[LEFT]
# make-kpkg clean
# make-kpkg --revision=8:MOSIX01 kernel_image
[/LEFT]
و یا خیلی سادهتر:
[LEFT]
# make-kpkg clean
# make-kpkg kernel_image
[/LEFT]
این نحو عملیات کامپایل هسته به یک بسته دبیان ختم خواهد شد که قادرید آنرا به راحتی روی سیستم نصب نمایید. مدت زمان انجام عملیات کامپایل هسته به سرعت پردازنده سیستم بستگی دارد. پس از اتمام عملیات کامپایل هسته، بستهای را که ایجاد شده است، نصب میکنیم:
[LEFT]
# dpkg -i kernel_image-2.4.23-om_MOSIX01_i386.deb
[/LEFT]
هنگام نصب این بسته، مدیر بوت Lilo به طور خودکار پیکربندی خواهد شد. در صورتی که از گراب استفاده میکنید، باید تغییرات را بطور دستی در فایل پیکربندی آن اعمال نمایید. برای این منظور باید فایل boot/grub/menu.lst را ویرایش کرده و خطوط زیر را اضافه نمایید. البته مقادیری مانند پارتیشنهای قابل بوت و سایر آدرسها ممکن است روی سیستمهای شما متفاوت باشد که آنها را باید تغییر دهید:
[LEFT]
title Libranet GNU/Linux, kernel 2.4.23 OpenMosix
root (hd0,1)
kernel /vmlinuz-2.4.23-om root=/dev/hda3 ro hdb=scsi
savedefault
boot
[/LEFT]
پس از اتمام نصب هستهها، اکنون باید ابزارهای نرمافزاری OpenMosix را نصب نماییم. برای این منظور، فایلی را که دانلود کرده بودیم، باز کرده و کامپایل و نصب میکنیم:
[LEFT]
# bzip2 -d openmosix-tools-0.3.5.tar.bz2
# tar -xf openmosix-tools-0.3.5.tar
# cd openmosix-tools-0.3.5
# ./configure --with-kerneldir=/usr/src/linux-2.4.23/
# make
# make install
[/LEFT]
کامپایل و نصب ابزارهای نرمافزاری مدت زیادی طول نمیکشد (۱-۲ دقیقه یا کمتر روی پردازندههای قویتر). پس از اتمام آن، باید در یکی از فایلهای پیکربندی مربوطه لیست گرههای کلاستر را تعریف کرده و سپس سرویس OpenMosix را طوری تعریف کنیم تا هر بار بصورت خودکار اجرا شود. به این منظور ابتدا دستور:
[LEFT]
# vi /etc/openmosix.map
[/LEFT]
اجرا کرده و باید مشخصات گرهها را بصورت <شماره گره> <آدرس IP گره> <تعداد> وارد نماییم:
[LEFT]
<Node No.> <Node IP Address> <Node QTY>
1 192.168.0.1 1
1 192.168.0.7 1
[/LEFT]
آرگومان شماره هنگامی مفید است که بخواهیم چند آدرس IP پشت سرهم را تعریف نماییم. مثلا در صورتی که ۱۰ گره داشته باشیم که آدرس آنها از ۲۵ شروع میشود، وارد خواهیم کرد:
[LEFT]
1 192.168.0.25 10
[/LEFT]
و عملیات تایپ ما را بسیار کمتر خواهد کرد. این فایل پیکربندی روی تمام گرهها یکسان است. بنابراین میتوانید آنر روی تمام گرهها کپی کنید. پس از انجام این کار به راهاندازی خودکار OpenMosix میپردازیم. ابتدا باید تعیین کنید که سطح اجرایی پیشگزیده هر یک از گرهها کدام است. به این منظور دستور زیر را وارد نمایید:
[LEFT]# runlevel
N 2
[/LEFT]
خوب سطح اجرایی پیشگزیده ما ۲ است (سیستمهای مبتنی بر دبیان). بنابراین وارد دایرکتوری etc/rc2.d میشویم. در صورتی که سطح اجرایی شما متفاوت شد، این عملیات را با دایرکتوری مربوط به آن که میتواند rc3.d، rc4.d و... باشد انجام دهید:
[LEFT]
# cd /etc/rc2.d
# ln -s ../init.d/openmosix S20openmosix[/LEFT]
در اینجا نمیخواهم فلسفه دستورات بالا را توضیح دهم زیرا از مسیر اصلی دور خواهیم شد. پس از اتمام عملیات بالا و بوت سیستمها، سیستمهایی داریم که مبتنی بر OpenMosix بوده و سرویس آن نیز بطور خودکار اجرا میشود. برای بکار افتادن کلاستر، گرهها را بوت میکنیم. گره شماره ۱ با موفقیت OpenMosix را اجرا میکند، ولی گره شماره ۲ با پیغام Invalid Map File قادر به اتصال به کلاستر نیست. پس مقداری جستجو و بررسی فایل پیکربندی، متوجه میشوم که در فایل etc/hosts یک ورودی به صورت زیر موجود است:
[LEFT]
127.0.0.1 cyber
[/LEFT]
آنرا تبدیل به ورودی زیر میکنم:
[LEFT]
192.168.0.7 cyber
[/LEFT]
مجددا سرویس OpenMosix را با دستور etc/init.d/openmosix restart اجرا میکنم. اکنون بدون مشکل اجرا میشود. برای حصول اطمینان از شناخته شدن تمام گرههای کلاستر، با دستور زیر آنها را آزمایش میکنم:
[LEFT]# mosctl status 1
up.
# mosctl status 2
up.
[/LEFT]
بسیار عالی! هر دو گره کلاستر در حال اجرا هستند. اکنون کلاستر ما آماده است. با استفاده از دستور mosmon میتوانید وضعیت کلی کلاستر را بررسی نمایید. اینکه کدام سیستمها دارای چه مقدار بار فعال هستند و با گذاشتن بار روی یکی از آنها چه اتفاقی خواهد افتاد و ...
[URL=http://www.technotux.org/html/modules.php?op=modload&name=Sections&file=index&req=viewarticle&artid=52&page=1]منبع[/URL]
Building a Linux virtual server
اگر بخواهیم کلاستر را با استفاده از [URL=http://www.linuxvirtualserver.org] پروژهی سرور مجازی لینوکس[/URL] یاده سازی نماییم بدین صورت عمل می کنیم:
[LEFT]The main advantage of using LVS is that unlike Microsoft network load-balancing clusters, the LVS allows you to add a node running any operating system that supports TCP/IP to the cluster.
The cluster setup (shown below at right) consists of a load balancer server -- also known as the virtual server -- running on the Linux operating system and one or more real servers connected to it through a hub or a switch. The real servers -- which can run any operating system -- provide network services to the Internet clients, whereas the virtual server does IP-level load balancing of the incoming traffic to the various real servers. The virtual server acts as an interface between the users and the real servers and, therefore, makes the parallel services of the real servers to appear as a virtual service on a single IP address.
When the virtual server receives a client request for data, it transfers the request to the appropriate real server according to a scheduling algorithm. The real server then replies to the virtual server, which in turn forwards the reply to the client. Although it is actually the real server that services the client request, to the client it appears as if the response came from the virtual server. The IP address of the real server is masqueraded by the IP address of the virtual server.
The virtual server uses two network interfaces (dual-homed host), one connected to the Internet for the clients to access and the other connected to the internal local area network (LAN), where all the real servers are placed. Scalability is achieved by transparently adding or removing real servers from the internal LAN.
Rebuilding the kernel
Linux systems using kernel versions earlier than 2.4.28 do not have support for virtual server built into the kernel. Therefore, the first step involved in setting them up as a virtual server is to rebuild their kernel with the appropriate patch applied. Kernel versions 2.4.28 or later have LVS support built into them by default and, therefore, require no patching.
The patches can be downloaded from the LVS Web site. There are different patches for various kernel versions. For this article, we will be configuring a patch for the 2.4.x kernel: linux-2.4.21-ipvs-1.0.10.patch.gz.
To apply the patch to the kernel, move the patch file to the /usr/src directory and issue the following command as root:
#cd /usr/src/linux*
#gunzip ../linux-2.4.21-ipvs-1.0.10.patch.gz
#patch -p1 < ../linux-2.4.21-ipvs-1.0.10.patch
This will patch the kernel; after that you'll need to compile it. In the /usr/src/linux* directory issue these commands:
#make mrproper
#make oldconfig
#make menuconfig
This will bring up a screen with several subheadings. Select the Networking Options subhead, and then IP:Virtual Server Configuration in the following screen. Then select the following options:
virtual server support (EXPERIMENTAL)[*] IP virtual server debugging
(16) IPVS connection table size (the Nth power of 2)
--- IPVS scheduler
<M> round-robin scheduling
<M> weighted round-robin scheduling
<M> least-connection scheduling scheduling
<M> weighted least-connection scheduling
<M> locality-based least-connection scheduling
<M> locality-based least-connection with replication scheduling
<M> destination hashing scheduling
<M> source hashing scheduling
<M> shortest expected delay scheduling
<M> never queue scheduling
--- IPVS application helper
<M> FTP protocol helper
Save the current kernel configuration and exit from menuconfig. Then from the command prompt type:
#make dep && make clean && make bzImage && make modules && make modules_install
This will create a compressed kernel image (bzImage) in the /usr/src/linux*/arch/i386/boot directory and will also create and install all the modules for the new kernel. Now copy this new kernel image (bzImage) to the /boot directory.
Lastly, either edit your /etc/grub.conf or /etc/lilo.conf file or rename the new kernel image (/boot/bzImage) to the one being referred to in your bootloader configuration file, in order to make your system boot from the new kernel.
Installing IPTables and IPVsadm
After rebuilding the kernel you need to have the IPTables and IPVsadm packages installed on your system to configure it as virtual server. IPTables is used to build, maintain, and inspect IPv4 packet filtering and NAT (network address translation) rules in the Linux kernel. Using it, IP masquerading will be provided to the real servers. IPVsadm is the administrating utility for the Linux Virtual Server and will be used to set the scheduling algorithm and rules for forwarding client requests to the real servers.
The IPTables package comes bundled with most Linux distributions and can be easily installed from the installation CDs for your distribution. The source RPM for the IPVsadm utility can be obtained from the LVS Web site. For this example we'll use the ipvsadm-1.21-10.src.rpm SRPM package.
Once the packages have been installed you need to enable IP forwarding on the server. Open the file /etc/sysctl.conf in a text editor and set this value:
net.ipv4.ip_forward = 1
Next, issue the following command to start the IPTables service on your system. This allows the virtual server to forward replies from the real servers to the clients:
#service iptables start
Enabling IP masquerading
In order to enable masquerading for the real servers, we will assume that the external Internet interface on your Linux Virtual Server is eth0 and the internal LAN interface (connected to other real servers) is eth1. Therefore, on the server issue these commands:
#iptables -t nat -P POSTROUTING DROP
#iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
The first command sets up the default policy for IPTables to DROP, which means that if none of the specific rules match, the packet will be dropped. This ensures that not every packet is masqueraded by the server and, thus, provides an extra level of security. The second command enables NAT and masquerades the internal IP addresses of all the real servers to the IP address of the external Internet interface (eth0) of the virtual server. For more on IPTables, refer to its man page.
Configuring the virtual server using IPVsadm
The next step is to configure the Linux Virtual Server using the IPVsadm utility. But before that, you must allocate proper IP addresses to all the machines on your network. Put the real servers in your internal LAN on a private IP address range, such as 10.0.0.0/255.255.255.0. Also, put the internal LAN interface of the virtual server on the same subnet. Assign the IP address of the internal LAN interface of the virtual server as the default gateway for all the real servers. For the external Internet interface of the virtual server, use a public IP address or the settings provided by your ISP.
In our example setup, we used two real servers running on different operating systems. One with the IP address 10.0.0.2(providing HTTP service) and the other with IP address 10.0.0.3(providing both HTTP and FTP services), with the default gateway for both of them set as 10.0.0.1, which is the IP of the internal LAN interface of the virtual server. The external Internet interface of the virtual server had been assigned a public IP address 61.16.130.100.
Now add the virtual service and link a scheduler to it with these commands:
#ipvsadm -A -t 61.16.130.100:80 -s wlc
#ipvsadm -A -t 61.16.130.100:21 -s wrr
The above two commands add wlc (weighted least-connection scheduling) and wrr (weighted round robin scheduling) algorithms for HTTP (port 80) and FTP (port 21) traffic on the virtual server, respectively. There are several other scheduling algorithms available; you can learn more about them from the IPVsadm man page.
Next, add real servers on the virtual server to which the client requests will be forwarded:
#ipvsadm -a -t 61.16.130.100:80 -r 10.0.0.3:80 -m
#ipvsadm -a -t 61.16.130.100:80 -r 10.0.0.2:80 -m -w 2
#ipvsadm -a -t 61.16.130.100:21 -r 10.0.0.3:21 -m
This will cause all the HTTP traffic on the virtual server to be forwarded to 10.0.0.2 and 10.0.0.3 according to the scheduling algorithm. All the FTP traffic will go to 10.0.0.3 only. The real server 10.0.0.2 is given a weight of 2 for HTTP traffic by the -w 2 switch. The default weight is 1.
Testing it out
After setting everything up, use a client machine to connect to the virtual server using its external IP address. To do this, open a Web browser and type in the server's IP address (61.16.130.100 in the example) in the address bar. You will get a Web page served by the Web server running on the real servers. Open multiple connections to the virtual server and check the status of the various connections on the real servers. You will notice that the incoming load is being equally distributed among the real servers. Thus, the virtual server is performing IP load balancing.
Although the above-described virtual server setup (virtual server via NAT) can meet the performance requirements of many servers, the design is limited by the load balancer, which is a single point of failure for the whole cluster. However, you can eliminate this bottleneck by having multiple virtual servers, each connected to its own cluster of real servers, grouped together at a single domain name by round robin DNS.
[/LEFT]
[URL=http://software.newsforge.com/article.pl?sid=05/05/27/0612243&from=rss]منبع[/URL]