mail伺服器集群
大俠們：
我現在在做mail伺服器的集群，兩台伺服器。
目前我已經做了mysql的數據雙向同步，郵件數據的同步。但是http的集群、smtp、pop3的集群不知道怎麼搞，如何在一台機器上這些服務無法提供的時候自動切換到另一台？希望各位大俠多指教指教。
《解決方案》
回復 1# tstianzy
轉一個E文大家來討論下。
Mail server clustering
1. Using Network File System (NFS)
Very large mail clusters can be built by keeping the Maildirs on fileservers shared by NFS
External interfaces (public)
| | | | |
+------+ +------+ +------+ +------+ +-------+
| MX | | MX | | POP3 | | POP3 | |webmail|
+------+ +------+ +------+ +------+ +-------+
^ | | | | |
NFS +---------+----+-----+----+-----+----------+ private
v | | network
+-----+ +-----+
| NFS | | NFS |
+-----+ +-----+
Notes:
File locking does not always work correctly over NFS. However the Maildir storage format was designed with this in mind. Maildir on NFS is always safe.
If you run out of CPU power at the front, add more front ends.
If you have more than one NFS fileserver, they are mounted separately (e.g. /mail1, /mail2). If you run out of CPU power or disk space, add more NFS servers.
Commercial dedicated NFS servers are available (e.g. Network Appliance); these are very expensive but give extremely high performance and reliability.
Careful design can give a resilient service which continues to work in the event of failure of an individual component
2. Using Proxies
| | | |
+------+ +------+ +------+ +------+
| MX | | MX | | POP3 | | POP3 |
|proxy | |proxy | |proxy | |proxy |
+------+ +------+ +------+ +------+
| | | |
SMTP ^ +-----+----+-----+----+-----+----+
v POP3 | | |
+------+ +------+ +------+
| mail | | mail | | mail |
+------+ +------+ +------+
Backend servers are mailservers, accessed via SMTP and POP3. Incoming mail is delivered to the appropriate server by means of an SMTP proxy (e.g. Exim); users collect their mail via a POP3 proxy, e.g.
Perdition (http://www.vergenet.net/linux/perdition/)
Smunge (http://www.i2pi.com/smunge/)
This solution avoids the use of NFS, but is somewhat inelegant and is more difficult to manage (the backends need to have information about user accounts, whereas NFS servers are "dumb"). An NFS solution is likely to be more reliable and easier to scale.
3. Load Balancing
How do you spread the load between your various machines?
1. MX receivers
Just use equal-priority MX records. This also gives you resilience, because the sender will retry if one of the machines is down.
example.com MX 10 mx-1.mail.example.com.
MX 10 mx-2.mail.example.com.
2. POP3 servers and smarthost
You can use round-robin DNS to share the load:
pop3.example.com A 192.0.2.17
A 192.0.2.18
smtp.example.com A 192.0.2.1
A 192.0.2.2
However, in the event of an outage, some customers may find themselves unable to connect (Windows clients tend to 'stick' with the first IP address they get from the DNS). Solutions:
Set a very short TTL in the DNS (e.g. 60 seconds) and change the DNS when there is an outage
Use a layer 4 load-balancing switch. This will give a single 'virtual' IP address which the clients connect to, and in turn passes the connections to the real machines behind.
You can implement load-balancing using PCs (e.g. Linux Virtual Server)
NOTE: By keeping your SMTP (smarthost) service separate from your POP3 service, the SMTP machines can be scaled separately and do not need to be connected to the shared backend at all.
4. Databases
With any clustering solution, each of the servers needs access to information about usernames, passwords and mail directories. This information needs to be consistent across all the boxes, and updated whenever accounts are added/deleted or people change their passwords. In fact, other parts of your ISP probably need the same information (e.g. RADIUS servers)
Essentially there are two main approaches:
Keep separate database files on each machine; generate them from a central database and distribute them periodically, say once per hour. You can use 'rsync' to efficiently distribute the text versions of these files (e.g. /etc/userdb) and then locally convert them to database files on each machine (e.g. /etc/userdb.dat).
Have all your service machines talk directly to a 'live' database, e.g. mysql or ldap. This saves having to distribute files and means that any changes are immediately effective, but it gives a critical core to the service which needs to be made scalable and reliable.
In both cases, you will probably want to tie this information into your billing system so that people do not receive service without paying for it. I strongly recommend that you give each customer a unique 'customerID' (not related to their access username) which links the service(s) they take to their billing account. Note that userdb lets you add additional fields, so one of these could be customer ID. Having this information from the start makes it very easy to migrate to a future billing/provisioning system.
5. FreeBSD NFS
NOTE: NFS is an insecure protocol. You are strongly recommended to run NFS on a completely private network, using RFC1918 address space, with a separate NIC. Keep this NFS network completely separate from any office network or other RFC1918 network you have.
Client Side
# mkdir /mail1
# mount ns.t1.ws.afnog.org:/usr/mail1 /mail1
# mount
By default, NFS servers do not allow accesses from "root" - but you can perform accesses as another user. In our case, this directory is owned by 'exim' so you should be able to create files as this user.
# su exim
$ vi /mail1/somefilename
$ ls /mail1
$ exit
#
/etc/rc.conf
# This optimises NFS client performance but is not essential
nfs_client_enable="YES"
Note that there is currently no way for a FreeBSD client to request a lock on an NFS server. Hence it is essential only to use mechanisms that don't depend on locking (such as Maildir)
Test exercise:
# pw useradd tevie -d /mail1/12/34/tevie -u 2001 -s /nonexistent
# passwd tevie
Changing local password for tevie.
New password:
Retype new password:
passwd: updating the database...
passwd: done
In /usr/exim/configure:
domainlist local_domains = @ : .......... : cluster.t1.ws.afnog.org
Then hup your Exim daemon, and send a mail to tevie@cluster.t1.ws.afnog.org
Server Side
This is how ns.t1.ws.afnog.org was configured:
# mkdir /usr/mail1
# chown exim:exim /usr/mail1
# mkdir -p /usr/mail1/12/34/tevie
# chown 2001:2001 /usr/mail1/12/34/tevie
/etc/exports
/usr/mail1 -network 81.199.110.0 -mask 255.255.255.128
/etc/hosts.allow
(If you are restricting access with TCP wrappers, you have to add a rule to permit portmap from your NFS clients)
portmap : 81.199.110.0/255.255.255.128 : allow
portmap : ALL : deny
/etc/rc.conf
portmap_enable="YES"
nfs_server_enable="YES"
This ensures the correct daemons are started when the machine is next rebooted.
《解決方案》
回復 1# tstianzy
解決mail的群集實際上也是很簡單的一個思路就是郵件存儲資料庫
群集中有一個多個主機同時提供smtp和pop3通過調度來分配訪問的請求，數據都放到資料庫中。
通過調度提供多個webmail訪問資料庫提取郵件內容。
這樣就是實現幾個服務的調度問題。
核心是資料庫是否能夠承載足夠大的訪問量，已經郵件附件的存放問題，附件大小的限制等。
