We won’t be going into much details on how exactly @Mail was installed as their own website provides very clear instructions about the installation in multiserver mode. You should make sure the NFS mount and all the required services  For more details on these you can visit this knowlegde base article from the @Mail site itself. We will be looking into the Round Robin DNS setup which would need to be done for this setup.

You can run Pop3/IMAP , SMTP and Webmail services from different servers when you run @Mail in multiserver mode.You would need edit the DNS records for your domain to be able to utilize the cluster setup on your domain. We normally use ISC Bind as the nameserver on our setups and we used the same for this setup. We will consider the hypothetical domain used for the setup as yourdomain.com throughout this article.

Our cluster had three nodes namely: node1.yourdomain.com (123.123.123.126), node2.yourdomain.com (123.123.123.127) and node3.yourdomain.com (123.123.123.128) . We installed @Mail on all of them as per the official multiserver installation instuctions and it shared the same MySQL db and used the central NFS storage area as well. The setup requires the MX records for the domain to be pointed to all the 3 nodes. The MX priority for each of these mail servers should be the same so that the mails are distributed properly to these nodes.

The DNS entries for the nodes would be as below in the zone file:

node1         IN      A       123.123.123.126
node2         IN      A       123.123.123.127
node3         IN      A       123.123.123.128

The MX record for the domain needs to point to each of the nodes as below. The priority would remain the same. It is set to 0 in this case.

yourdomain.com.           IN      MX      0       node1
yourdomain.com.           IN      MX      0       node2
yourdomain.com.           IN      MX      0       node3

The above setup will set the incoming mails to be handled by any of the 3 nodes.

The remaining services would need to be load balanced to the different nodes in the same manner. This includes the Webmail and POP3/IMAP services. The setup in the DNS zone file would be as below. Using the round robin setup, if a node goes down in the cluster the request is automatically forwarded to the next node.

mail  IN      A       123.123.123.126
mail  IN      A       123.123.123.127
mail  IN      A       123.123.123.128

You would need the reload the DNS zone after making these changes or restart the service. You would need to verify the changes you made as below:

# dig yourdomain.com mx
 
;; QUESTION SECTION:
;yourdomain.com.                    IN      MX
 
;; ANSWER SECTION:
yourdomain.com.             86400   IN      MX      0 node3.yourdomain.com.
yourdomain.com.             86400   IN      MX      0 node1.yourdomain.com.
yourdomain.com.             86400   IN      MX      0 node2.yourdomain.com.

You can find below that mail.yourdomain.com resolves to 3 Ips as below.

# nslookup mail.yourdomain.com
Server:         127.0.0.1
Address:        127.0.0.1#53
 
Name:   mail.yourdomain.com
Address: 123.123.123.126
Name:   mail.yourdomain.com
Address: 123.123.123.127
Name:   mail.yourdomain.com
Address: 123.123.123.128

Using this method you can setup a load balanced mail cluster using @Mail. If you have additions to make, they are always welcome

No related posts.

• Cpanel/WHM (Linux & Windows to be soon available)
• Plesk 8.x (Windows and Linux)
• Parallels Helm 4.0 (Windows)
• ISPConfig (OpenSource Control panel – Linux)
• Hsphere (Linux and Windows)
• DirectAdmin (Linux)
• Webmin (Linux)

We have our own custom designed control panel for dedicated mail clusters as well as qmail based mail cluster solutions. For further information on this setup, please contact us via the Contact Form.

Related posts:

1. Wide Choice for Operating Systems As part of

1. CentOS 4.x/5.x

2. RHEL 4.x/5.x

3. Fedore Core

4. Windows Server 2003

5. Windows Server 2008

6. FreeBSD 6.x

We will soon also be expanding our services to offer a wide choice on Control Panels for the servers on the cluster as well.

Related posts:

1. New Control Panels Available We have ne

This site gained a huge membership base in just a few months and had traffic which could not be manged by a single dedicated server. The site involved an autosurf bar which checked for the banner/ads existence on the member site and rotated it amongst the members every few minutes. The amount of hits the member’s website would receive is dependent on the amount of sites he would surf via his own autosurf area.The cluster we setup had the structure as below:

WebServers: The webservers were the most busy nodes of this cluster. Their site was all about generating http traffic and their members were on the site almost all the time. The autosurf structure made sure that no member was idle and so the http hits were continous and enormous in number. We had to use 3 webservers to be able to manage the amount of traffic this site was getting. Each of the webserver nodes was setup with Lighttpd + PHP as Fastcgi for faster site performance and dynamic page generation.

The configuration for the webservers we used was:

• Intel Pentium Dual Xeon 2.8 Processor
• 2GB DDR2 RAM / 160GB SATA HDD Drive
• CentOS 4.6
• 1000Mbps Uplink
• Private LAN Connections to other Nodes on the Cluster

Master Mysql Server: All the three webservers connected internally via private switch to the master Mysql server. All the site’s membership data and hits stats were being stored in the database and database traffic was huge as well as each hit was being logged into mysql. The client needed managed mysql backups and redundancy and so mysql replication was used for the cluster. Due to the amount of mysql activity on the master mysql server, generation of backups from this node was almost impossible. We used replication to sync the db data on the slave server and used the slave server for generating mysql backups. The configuration we used for the Mysql Server is as below:

• Intel Pentium Quad Core Q6600 Processor
• 8GB DDR2 RAM/ 1×300GB SCSI 10k RPM Drive
• CentOS 4.6
• 100Mbps Uplink
• Private LAN Connections to other Nodes on the Cluster

The slave Mysql server also acts as the mail server for the setup. The mailing activity for the site is moderate and so only one mail server is being used.

• Intel Pentium Quad Core Q6600 Processor
• 4GB DDR2 RAM/ 1×300GB SCSI 10k RPM Drive
• CentOS 4.6
• 100Mbps Uplink
• Private LAN Connections to other Nodes on the Cluster

This setup distributes the traffic for the site to the three nodes using round robin DNS which is managed by the TTL. Comments are welcome as always.

No related posts.

Environment:

• The organization is a medium enterprise with work area related to Engineering drawing and CAD designing.
• The employee strength is around 250.
• Their mailing activity is heavy as the huge design files are being passed along internally within the organization and even to their end clients mostly using mails and heavy attachments.
• The staff is located in two different countries with almost the same strength at each office.

Our Task and Resources:

Our primary task to build a robust and fail over enabled cluster for their mailing activity. The volume of mails being sent via this cluster was substantial due to the fact that mails were the most important aspect of their daily chores. We were approved to use a six node cluster for their mails. Even though this was a corporate setup, we had to use open source softwares as the client wanted to keep it cost effective.  We used a qmail, vpopmail etc for their cluster preventing the use of any paid softwares.

The Setup:

As we were allowed to use six nodes for the cluster, we decided to use two nodes for outbound mails ,two nodes for inbound mails and one node for a pop3/imap connector and one as a mail gateway.

The hardware configurations for all these nodes was as below:

• Intel Pentium Dual Xeon 2.8Ghz
• 2GB DDR2 RAM, 2×500GB SATA Drives
• Fedora Linux Base OS, 100Mbps Uplink on each node

The setup flow was as below:

The Actual Functionality:

As you can see above, the domain was setup to use seperate nodes to send and receive the mails. A brief explanation of how it all worked together and each node’s function is below:

MX Records: The domain had two MX records. One was the primary MX which accepted the mails for the domain and prepared them to be fetched by the pop3 connector. The second backup MX record’s node was a failover to the primary MX and stored the inbound mails while the primary MX was down.

SMTP Servers: The company had a very high volume of outbound mails and so two smtp servers needed to be used. As they had two offices, each of them got a dedicated SMTP server to use.

Mail Gateway: Both the SMTP servers were connected to a single Qmail based mail gateway. The mail gateway provided functions like archiving mails to monitor employee activity, filtering content and proper monitoring of the outbound mail stats for the entire company.

Pop3 connector: The pop3 connector retrieved and redistributed the mails received by the primary MX server for the domain to the user mailboxes which were made available via webmail or regular POP3 as well as IMAP based mail clients to the employees.

This particular mail setup did not require use of round robin DNS as failover functionality was more important than distribution of traffic. This type of setup also gives us the scope of expansion if there is a surge in the mail activity for the client. Another SMTP server for outbound mails or another node to act as the primary mail server can always be added due to the architecture used. I hope you find this case study useful for deploying mail server clusters. Comments are always welcome

No related posts.

Internet Protocol Address (IP Address) Lookup:

This is the most common procedure we use on our setups. The visitors are traced on the basis of the whois lookups done to their current IP address. These lookups are automated, real-time and are implemented using special server side modules or even third party lookup services. These lookups can provide the most accurate locations of the visitors as these IP whois databases can always have updates.

Media Access Control Address (MAC Address):

Media Access Control or MAC addresses is an Unique Identifier assigned to most network adapters or Ethernet Cards by their Manufacturer. It contains a combination of the manufacturer’s unique Identification number and some other codes to generate an unique MAC address for the physical device. The location of this device can be traced based on the Sales data for the manufacturer or some other similar methods.

Radio Frequency Identification (RFID):

Radio Frequency Identification or RFID uses Radio waves to transmit data with the help of devices like Transponders. RFID does not have much applications on internet related geolocation but it has wide uses in corporate and enterprise supply chain management systems for inventory tracking and other applications.

Global Positioning System (GPS):

Global Positioning System or GPS uses different Artificial Satellites to interpret the microwave signals obtained from certain GPS enabled mobile devices to calculate the exact geographical location of the device. The device receives this interpreted data which it can use to locate itself and obtain navigation instructions for a particular destination from its current location.

The IP whois lookup method is the most commonly used method for clusters. We will study the exact implementation of this technique in the actual case studies we will be releasing soon.

No related posts.

Although the design changes or tweaks depend on the type of site you have or are building but we will just try and touch base to some of the major points that can be taken into consideration during the site design phase for hosting it on a cluster. We will be adding some case studies later on our site for particular types of sites we have hosted and their design changes we implemented for optimal performance. The general tweaks would be as below :

1. Distribution of static and Dynamic Content

The site design can be done in such a way that there is scope to distribute static and dynamic content to different servers. Use of subdomain paths on the is a method which is helpful to achieve such distribution.

2. Prevention of Excessive Remote Includes

URL includes from the site to its own URLs causes and increase in the http traffic. This needs to be avoided as far as possible so that http does not have heavy traffic from the server itself.

3. Mysql Based Session Management

Websites which require sessions need to use mysql based sessions in order to maintain proper sessions on the site. The session mechanism can use a different mysql server if needed as well.

We will elaborate more on each of these points with examples in the case studies we will be posting.

No related posts.

1. If you need a site’s http traffic to be distributed to multiple servers, you need to set the A records in the DNS zone for the domain as below :

domain.com. 300 IN A 123.123.123.123
domain.com. 300 IN A 123.123.124.124
domain.com. 300 IN A 111.112.113.114

2. If you need a site’s mail traffic to be distributed to multiple servers, you should point the domain’s MX record to mail.domain.com and then you need to set the A records in the DNS zone for the mail record as below :


domain.com 3600 IN MX 0 mail.domain.com.
domain.com. 300 IN A 123.123.123.123
domain.com. 300 IN A 123.123.124.124
domain.com. 300 IN A 111.112.113.114

In the above examples you will see that the TTL for the A record has been set to 300 seconds. This is lower than normal and so the traffic will be rotated in Round Robin Mode.

No related posts.

DNS: DNS is the short name used for Domain Name System (or Service or Server). This is an Internet service which translates domain names into IP addresses.

FQDN: Fully Qualified Domain Name. This is the fully resolvable  DNS name for any  server  on a network.

Network: A group of computers or devices connected to each other is called a network.

Server: A server is a computer or device on a network which manages network resources. Like file server just stores files which a web server handles web requests.

Node: A node is a server or device on a complex network which is commissioned to a specific job on the network.

Load Balancing: Distribution of network traffic evenly across multiple nodes on a network is
called as load balancing.

Fault Tolerance: A systems ability to react and implement auto corrective measures when a fault it detected on one of its components is called as fault tolerance.

Server Clusters: Connecting two or more servers/nodes together to perform a single task form clusters. Clusters are used for Load Balancing

Related posts:

1. GeoLocation – Explained Geolocatio

We have to check for some prerequisites here before doing this installation. I will list them out as below :

• MySQL Server Installation
• Openssl Installed
• Pcre and Pcre-devel packages installed

These are just basic requirements and if you need some other special modules installed these may change as well. I am assuming the OS for the server would be CentOS 5.x in this how to but I do believe this how to should work for Fedora, CentOS or RHEL as well. You can use “yum” to install the above requirments or use “up2date” on RHEL . Lets assume that the prerequisites are already satisfied and we will proceed with the actual installation. We will make a temporary directory for the installation so that we can remove this directory once the installation is successful.

mkdir /usr/src/lighttpd_install

We will download the latest lighttpd source file from their site and uncompress it.

cd /usr/src/lighttpd_install
wget http://www.lighttpd.net/download/lighttpd-1.4.19.tar.gz
tar xzf lighttpd-1.4.19.tar.gz
cd lighttpd-1.4.19
./configure --prefix=/usr
make
make install

Once Lighttpd is installed we need to copy the init.d script for Lighttpd and also the spawn-php.sh script to /etc/init.d/ . This spawn-php.sh will be used to spawn php-fcgi processes later after we build PHP.

cp -av doc/rc.lighttpd.redhat /etc/init.d/lighttpd
cp -av doc/spawn-php.sh /etc/init.d/spawn-php.sh

Now we need to build fastcgi on the server.

wget http://www.fastcgi.com/dist/fcgi-2.4.0.tar.gz
tar xvf fcgi-2.4.0.tar.gz
cd fcgi-2.4.0
./configure --prefix=/usr
make
make install

Php needs to be built after this step. You can either use php4 or php5 as per your requirement. You need to download the php source from the PHP site (http://www.php.net) into the /usr/src/lighttpd_install before proceeding to the next step. We will be using PHP5 in this case and the php version used for the tutorial is php 5.2.6 . Once you have downloaded the source the steps would be as below: If you have an existing and working php installation on the server, you can use the same configure options for building php again. The following code snippet should get you the existing config line without the options we need for the build

php -i | grep config | sed s/"'"/""/g | sed s/"<.*> "/""/g |\
sed s/"<\/.*>"/""/g | sed s/".* =>  "/""/g | sed s/"'"/""/g |\
sed s/"--with-apxs=.*apxs "/""/g | sed s/".\/configure "/""/g |\
sed s/"--prefix=\/usr\/local "/""/g | sed s/"--with-apxs2=.*apxs "/""/g |\
grep -v ^tidy

Use this output from the above command along with the options below as your configure line to build php as fastcgi

--prefix=/usr/local/php5-fcgi --enable-force-cgi-redirect\
--enable-fastcgi --enable-discard-path

If you do not have an existing php installation, just build php with whatever options you need and add the –enable-fastcgi options as above. The procedure would be as below:

cd /usr/src/lighttpd_install
tar zxf php-5.2.6.tar.gz
./configure ---(add options you need to add or use\
 the config line generated from above)\--prefix=/usr/local/php5-fcgi\
--enable-force-cgi-redirect --enable-fastcgi --enable-discard-path
make
make install

If the installation is successfull you should should see php built with cgi-fcgi mode as below. Please node the php binary name could also be php-cgi.

[root@server ~]# /usr/local/php5-fcgi/bin/php -v
PHP 5.2.6 (cgi-fcgi) (built: May  8 2008 02:38:11)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
    with eAccelerator v0.9.5.2, Copyright (c) 2004-2006 eAccelerator, by eAccelerator
    with the ionCube PHP Loader v3.1.32, Copyright (c) 2002-2007, by ionCube Ltd., and
    with Zend Extension Manager v1.2.2, Copyright (c) 2003-2007, by Zend Technologies
    with Zend Optimizer v3.3.3, Copyright (c) 1998-2007, by Zend Technologies

After successfully building Lighttpd and PHP in Fastcgi mode, its times to now configure them to work together. In this tutorial we are considering a single site environment and so we will set the configuration files accordingly. We will be adding some more how to’s soon which will show the configurations that need to be done for multi site environments or even complex setups like load balancing using Apache and Lighttpd together.

mkdir /etc/lighttpd
cd /usr/src/lighttpd_install/lighttpd-1.4.19
cp -v doc/lighttpd.conf /etc/lighttpd/
vi /etc/lighttpd/lighttpd.conf

We need to make sure the following modules are now enabled in the lighttpd.conf . They just need to be uncommented.

• mod_rewrite
• mod_redirect
• mod_alias
• mod_access
• mod_cml
• mod_auth
• mod_status
• mod_setenv
• mod_fastcgi
• mod_simple_vhost
• mod_cgi
• mod_ssi
• mod_accesslog

Your server modules section of lighttpd.conf should look as below after the change :

server.modules              = (
                               "mod_rewrite",
                               "mod_redirect",
                               "mod_alias",
                               "mod_access",
                               "mod_cml",
                               "mod_auth",
                               "mod_status",
                               "mod_setenv",
                               "mod_fastcgi",
                               "mod_simple_vhost",
                               "mod_cgi",
                               "mod_ssi",
                               "mod_accesslog" )

The other options that need to be changed are:

server.document-root        = "/home/username/public_html"

The document root can even be in /var/www/html or just anywhere you want . We choose /home/username/public_html for easier ftp access to the location for updates.

server.errorlog             = "/home/username/logs/error.log"

Changing this setting is optional. If you want the user to have access to the error log then change the above option. Otherwise you can leave the setting as it is. Just make sure you have created the file folder /var/log/lighttpd and chowned it to the username you run lighttpd and php as.

accesslog.filename          = "/home/username/logs/access.log"

Again this setting is also optional. If you want the user to have access to the access log then change the above option.

server.port                = 80

The default port is 80. If you want to test or run your lighttpd installation on a non-standard port, you need to change this.

server.bind                = "xxx.xxx.xxx.xxx"

This is the Ip address lighttpd listens on. By default it listens on all IPs. If you want it binded to just one Ip on the server you need specify this option.

server.username            = "username"
server.groupname           = "username"

The username and group which lighttpd will run as. We are going to have the server running in suexec mode when we specify these options. Files created by the webserver will be owned by the username itself.

fastcgi.server = ( ".php" =>
  (( "host" => "127.0.0.1",
     "port" => 1026,
     "bin-path" => "/usr/local/php5-fcgi/bin/php"
  ))
 
)

In the above section we are specifying how php files will be handled. The bin-path will change as well as the port based on the spawn-php.sh script which we will be configuring next. After all these changes, the lighttpd.conf is all setup for use once you save the file. We will now configure the spawn-php.sh script which we have previously copied to /etc/init.d/

cd /etc/init.d/
vi spawn-php.sh

The following options need to be edited in this script:

SPAWNFCGI="/usr/bin/spawn-fcgi"

The path to spawn-fcgi will be as above as we have configured it with /usr prefix before.

FCGIPROGRAM="/usr/local/php5-fcgi/bin/php"

This path would be the absolute path to the php-fcgi binary. Please note it can be be /usr/local/php5-fcgi/bin/php-cgi as well.

FCGIPORT="1026"
FCGI_WEB_SERVER_ADDRS="127.0.0.1"

These can be left alone as they are unless you want a different Ip or Port specifically.

USERID=username
GROUPID=username

The userid and groupid for the script would be same as the one you have used in the lighttpd.conf before. Save the script and then chmod it to 755 and run it. You should see something like below as the output:

spawn-fcgi.c.197: child spawned successfully: PID: 10985

Now it is time to start lighttpd . Make sure the lighttpd logs folders are created and the user ownerships are set correctly. Once that is done, you can start lighttpd using the command as below:

[root@server ~]#/etc/init.d/lighttpd start
Starting lighttpd: [  OK  ]

Check the status to make sure it is running otherwise check the error log as set in the config file.

[root@server ~]# /etc/init.d/lighttpd status
lighttpd (pid 11210) is running...

This completes the installation steps. To test php you can upload a phpinfo file in the document root folder. A sample phpinfo.php would have the code like :

If your installation is running correctly, you should see the server API as CGI/FastCGI as it shows in the image below.
If you see the above, you have completed a successful installation of lighttpd and php running as a fastcgi. We hope you liked this how to and it is useful for setting up high performance lighttpd+php fastcgi setups for your site.

No related posts.