作者 主題: Mail Service Redundant Design  (閱讀 99116 次)

0 會員 與 1 訪客 正在閱讀本文。

fleece

  • 榮譽博士
  • 可愛的小學生
  • *
  • 文章數: 29
    • 檢視個人資料
    • http://zserver.vlabtaiwan.com
Mail Service Redundant Design
« 於: 2002-06-05 17:24 »
Hi NetMan,

拜讀了站長在 『第五章﹕架設 DNS』有段關於 MX 的說明(節錄如下)
[前略]
當外面的郵件伺服器通過 DNS 查詢到我們的郵件伺服器﹐如果發現超過一台主機負責郵件交換的話﹐數值越低的就越先被查詢。但有時候該主機沒有回應呢﹖那麼就由下一個數值的主機負責了。這樣有一個好處就是﹕就算第一台郵件伺服器出現故障﹐也不至於導致郵件交換功能癱瘓掉。我們通常會將各自的 MX 主機儘量分佈在不同的位置上(例如別的城市或國家的分公司主機)﹐假如萬一發生專線﹑甚至 ISP 的問題﹐我們還能將郵件轉往下一台 MX 主機。然而﹐在設計上﹐由於帳號和 client 端的設定因素﹐我們的郵件並非真的完全轉到下一個 MX 主機接收﹐而是先將郵件暫時佇列( queue ) 在那台機器上﹐當原來的 MX 主機恢復連線之後﹐郵件會自動的從佇列主機那邊送回來﹐這樣就能避免郵件丟失或被退信。

在我的認知裡
Mail Server Redundant 乃透過 DNS MX 的機制來完成的
亦即對 Mail Server 而言 備援機制的存在是 Transparent 的
也就是範例中的 rh71.siyongc.domain. 跟 lp64.dmz.domain
兩者之間並沒有其他聯繫的機制在吧 (?_?)
那當原來的 MX 主機恢復連線之後.
真的會有『郵件會自動的從佇列主機那邊送回來』種種的動作嗎
可以請站長指點一下迷津或者提供其他可以研究參考的資料嗎

kenny

  • 訪客
Mail Service Redundant Design
« 回覆 #1 於: 2002-06-05 18:39 »
在往下翻兩段文章﹐您就看到﹕

現在很多大型郵件系統﹐都可以同時使用多台郵件主機來提供郵件交換服務﹐這時候您可以將 MX 的 preference 設為相同﹐然後利用 NIS 和 NFS 服務﹐將郵件同步到相同的帳號去。您已經在前面的章節裡面學會了 NIS 和 NFS﹐等日後學習郵件主機架設的時候﹐不妨玩玩看﹗

fleece

  • 榮譽博士
  • 可愛的小學生
  • *
  • 文章數: 29
    • 檢視個人資料
    • http://zserver.vlabtaiwan.com
Mail Service Redundant Design
« 回覆 #2 於: 2002-06-05 19:02 »
找到了篇 RFC, Mail Routing and the Domain System
http://www.ietf.org/rfc/rfc0974.txt?number=974
裡面並沒有提到這方面具體的說明
我比較感興趣的是下列的機制
--
『我們的郵件並非真的完全轉到下一個 MX 主機接收﹐而是先將郵件暫時佇列( queue ) 在那台機器上﹐當原來的 MX 主機恢復連線之後﹐郵件會自動的從佇列主機那邊送回來』
--
除非當備援的 Mail Server 能夠提供設定 Domain Relay 吧
--
如果在 Domain Name Server 設定不同 Preference 的 MX
照一般設計邏輯來講 當備援的應該要將信收下才是
而 Mail-Client 這時收信就必須透過備援系統
(看來似乎比較不方便些 不過會設計這樣的機制是有原因的)
這裡我假設 Primary 所有的系統都掛了
包括 SMTP Server, POP Server, or NIS, NFS...

duncanlo

  • SA 苦力組
  • 俺是博士!
  • *****
  • 文章數: 7312
    • 檢視個人資料
Mail Service Redundant Design
« 回覆 #3 於: 2002-06-05 19:36 »
DNS MX的機制有點像掛號信,沒人在家,當然是最近的分局先暫收(Queue),
郵差試幾次信(Retry)還是寄不到那就退回寄信人...

跟你想要的Redundant 備援機制是不一樣的,
你說的應該是HA式的System吧!

參考一下人家的作法!
http://www.turbolinux.com.cn/solutions/solutioncolumn/3Rsoftsolution.pdf

kenny

  • 訪客
Mail Service Redundant Design
« 回覆 #4 於: 2002-06-05 20:09 »
引述: "fleece"
找到了篇 RFC, Mail Routing and the Domain System
http://www.ietf.org/rfc/rfc0974.txt?number=974
裡面並沒有提到這方面具體的說明
我比較感興趣的是下列的機制
--
『我們的郵件並非真的完全轉到下一個 MX 主機接收﹐而是先將郵件暫時佇列( queue ) 在那台機器上﹐當原來的 MX 主機恢復連線之後﹐郵件會自動的從佇列主機那邊送回來』
--
除非當備援的 Mail Server 能夠提供設定 Domain Relay 吧


朋友﹐這篇是討論 DNS 而不是 mail。 DNS 只負責解釋名稱﹐其中當然包括 MX 的解釋。至於解析出來的 IP 之主機上面怎麼設定﹐那是 mail 的設定。

就好像您在 DNS 將一個 www 的 A 記錄設定為 12.3.4 這個 IP 。在 DNS 的立場來說﹐任務已經完成。至於您能否連 12.3.4 關 DNS 什麼事﹖1.2.3.4 上面是否跑 www 服務管 DNS 什麼事﹖

同樣的﹐DNS 告訴您 MX 的下一個 preference 在哪裡﹐已經完成任務了。至於那台機器怎麼設﹐關 DNS 什麼事﹖當我們要 B server 而 A server 做 queue 的時候﹐當然得設定 relay ﹐要不然怎麼 queue 啊﹖但關 DNS 什麼事﹖

引用

如果在 Domain Name Server 設定不同 Preference 的 MX
照一般設計邏輯來講 當備援的應該要將信收下才是
而 Mail-Client 這時收信就必須透過備援系統

我就偏不要透過備援系統﹗假如您公司有 1 萬個 client ﹐難到今天 A server 掛了﹐要 1 萬個 client 都改到 B server 嗎﹖然後 A server 起來之後再改一次﹖沒人那麼蠢的啦~~

引用

(看來似乎比較不方便些 不過會設計這樣的機制是有原因的)
這裡我假設 Primary 所有的系統都掛了
包括 SMTP Server, POP Server, or NIS, NFS...


連閣下都認為這很麻煩了﹐難道別的 mail 管理員不覺得麻煩﹖
最方便就是讓 B 來 queue 信﹐等 A 起來再餵回來。難道您還想在 B 上面設定一萬個帳號然後要所有的 client 來收信嗎﹖

如果 primary 掛了﹐儘快搶修啊~~ 如果是永久性的(如地震壓壞了)﹐那還不簡單﹐再用一台新的機器來取得 A server 就好了啊(這樣和在 B 上面建 1 萬個帳號有很大差別嗎﹖)。這樣 B 就會將新送回新建的取得舊的那台 A server 了。

您還有更好的設計嗎﹖

fleece

  • 榮譽博士
  • 可愛的小學生
  • *
  • 文章數: 29
    • 檢視個人資料
    • http://zserver.vlabtaiwan.com
Mail Service Redundant Design
« 回覆 #5 於: 2002-06-05 20:53 »
是有比較好的設計方法
--
建議您不妨回到原點再重新思考看看
不讓自己侷限在單一的角度上看問題反而可以將問題看得更深入

kenny

  • 訪客
Mail Service Redundant Design
« 回覆 #6 於: 2002-06-05 21:17 »
願意洗耳恭聽。請...

duncanlo

  • SA 苦力組
  • 俺是博士!
  • *****
  • 文章數: 7312
    • 檢視個人資料
Mail Service Redundant Design
« 回覆 #7 於: 2002-06-05 21:30 »
引述: "duncanlo"
DNS MX的機制有點像掛號信,沒人在家,當然是最近的分局先暫收(Queue),
郵差試幾次信(Retry)還是寄不到那就退回寄信人...

跟你想要的Redundant 備援機制是不一樣的,
你說的應該是HA式的System吧!

參考一下人家的作法!
http://www.turbolinux.com.cn/solutions/solutioncolumn/3Rsoftsolution.pdf


(Sorry!我又來插花了...)

Queue在另一台MX的主機上,
它好像每隔一斷時間會去重試重寄信到正確的主機!

假如是要HA的系統,LVS可以作到類似的!
解決了資料的儲存問題,LVS可以用另一台去取代
發生問題的DNS,POP3,SMTP服務,
而使用者只會感到一小段時間的斷線!

kenny

  • 訪客
Mail Service Redundant Design
« 回覆 #8 於: 2002-06-05 21:43 »
嗯~~ 想想應該有很多更好方法的。只是不同環境有不同的因應方案。

我首先想到的是中小型的系統﹕不能有太大的資金做到 site-to-site redundent 設計。那麼最簡單的就是利用 mail queue 的辦法來做了﹐這樣可以隨時跟友公司或分公司的 mail server 相互儲列郵件﹐暫時解決退信問題。當然了﹐這個設計理不開 relay 設定﹐不是單一的 DNS 就能解決(容我再強調 DNS 的解釋功能)。

如果要做到 real time 的備緣﹐事實上牽涉的東西真的很多。而前面提到的使用 DNS 的 MX round robin 是其中一個方法﹐但問題需要解決後端的帳號和 storage ﹐如果能解決的話﹐那就是一個不錯的設計了。

嗯~~ 真不知道像 yahoo 它們是怎麼玩的﹐看樣子它們的驗證系統也是獨立的。

p.s. 發現剛纔對 fleece 兄不怎麼禮貌﹐這裡陪個不是...

fleece

  • 榮譽博士
  • 可愛的小學生
  • *
  • 文章數: 29
    • 檢視個人資料
    • http://zserver.vlabtaiwan.com
Mail Service Redundant Design
« 回覆 #9 於: 2002-06-05 21:46 »
Suppose Primary and Second Domain Name Servers & Mail Servers are designed for 異地備援
Primary DNS 設定 Primary MX w/  better Preference
and Secondary MX w/ worse Preference
and longer expired timer for entries in Primary Domain Name Server
While Primary Domain Name Server and Mail Server are down,
Secondary Domain Name Server and Mail Server are active.
The RRs in Secondary Domain Name Server are set w/
shorter expired timer,
and the Secondary Mail Server is set for auto-forward to
user's secondary E-Mail Address,
they will not lose they mail sent to primary E-Mail Address.
While Primary Domain Name Server and Mail Server recover,
they will take care of everything very soon.

duncanlo

  • SA 苦力組
  • 俺是博士!
  • *****
  • 文章數: 7312
    • 檢視個人資料
Mail Service Redundant Design
« 回覆 #10 於: 2002-06-05 21:51 »
引述: "netman"
嗯~~ 真不知道像 yahoo 它們是怎麼玩的﹐看樣子它們的驗證系統也是獨立的。


Kimo/Yahoo的帳號好像是記在DB,
然後smtp,pop3就要另外設計了,
像我用的3rsoft @message也是,
以前有一份openfind的mail system也是,
備份超容易的,只要把某個目錄下全備起來就好了,
系統部份只要一兩個管理帳號!

假如你是Domino/Notes系統,
他有自已的Cluster機制,
多台mail server除了可以同步user mail外,
Load Balance,Load Sharing或Take Over都可以,
而且不同平台都可以(真的有人用NT+Linux),
這是我目前看到滿成熟的Message System之一!

kenny

  • 訪客
Mail Service Redundant Design
« 回覆 #11 於: 2002-06-05 21:58 »
啊~~ 看起來怎麼有點感覺考證照的題目~~  ^_^

嗯﹐fleece 兄的設計非常妙﹗不過有一點﹕secondary mail box for every user 。換句話說﹐所有 user 必須都設定兩個帳號來收信。既然這樣﹐乾脆就在下一個 MX 主機上面建立帳號就好了。

假如我們排除了 IDC 的 hosting 方式﹐一般的企業都是在自己的機房牽專線(哦﹐現在似乎很多人情鐘 ADSL )。換而言之﹐client 和 server 非常有可能在同一個 site 中。假如這時候是正個 site down 下來的話﹐使用 mail queue 的辦法就可以解決。

但如果是單純的 server 掛點﹐而 client 連線是 active 的話。我想﹐不如花時間在單純的 mail server 上的 redudant 設計就好。是否還要扯上 DNS 和 MX 的設計﹐我猜﹐離開了具體評估﹐實在沒辦法在短時間作答。

而另外一點﹐在 fleece 的設計上﹐忽略了一個很重要的元素﹕RR 的 TTL 。假如當初的 DNS 所設定的 TTL 過長的話﹐就算 secondary DNS 起來應答查詢也必須等其他所有已經作過查詢的 name server 之 cache expired 之後才有用。

個人觀念或有錯漏﹐歡迎指教。謝謝﹗

fleece

  • 榮譽博士
  • 可愛的小學生
  • *
  • 文章數: 29
    • 檢視個人資料
    • http://zserver.vlabtaiwan.com
Mail Service Redundant Design
« 回覆 #12 於: 2002-06-05 22:10 »
幾個 Key Point 我再補充:
1. Primary Domain Name Server 中設定 Primary MX, and Secondary MX
    Secondary Domain Name Server 中只設定 Secondary 之 MX
2. Primary Domain Name Server 基本上跟
    Secondary Domain Name Server 在此 ZONE 的設定上大致是相同的
3. 由於 Secondary Mail Server 只作 Forwarding
    所以只會用到 mqueue (當然還是需要 Username List, 但不需密碼, mbox...)
4. 即使 Primary Domain Name Server Down 後 Cache 還沒 Expire 前
    這些 Cache 的資料對 Secondary Mail Server 一樣有效
    因為其 Preference 劣於 Primary Mail Server
5. 這是目前自家社群在用的設計 只是為了省錢方便罷了

kenny

  • 訪客
Mail Service Redundant Design
« 回覆 #13 於: 2002-06-05 22:22 »
的確﹐cache 問題似乎不大﹐多謝提醒。

但是 forwarding 的設計還是會卡在帳號問題﹐因為您必須要幫所有帳號 forward 到新的帳號去。假如其中一人沒有後備 mbox 的話﹐就會遭到退信了。也就是說﹐日後每增加一個帳號﹐都必須要具備 secodary mbox ﹐同時﹐(可能更麻煩的)是所有帳號在 client 端設計上﹐需要再多一次設定。這樣的話﹐在數量多﹑變動頻的環境中﹐在下不認為是非常理想的方案。

如果真要這樣玩﹐我乾脆就在下一個 MX 主機上為所有帳號設定備份帳號了。這樣又回到我們的原點﹕client 端設計﹑帳號同步等等問題。

所以﹐我寧願考慮為 primary mail server 做 redudant ﹐也就是全世界在任何時候都能夠 access 得到 primary mail server ﹐只要能解決好 accrount 和 storage 就行了。

再回到 fleece 的 DNS 設計﹐由於 primary 和 secondary 的不一致﹕其一有兩個 MX﹑另一只有一個 MX﹐而且 ttl 設計也不一樣。這樣的 requirement 下﹐只能採用手工的方式來維護兩台同 zone 的 DNS 。那麼﹐master/slave 的 zone transfer 就沒用了。同樣的﹐在數量大﹑變動頻的環境下﹐在下也不認為是非常理想的方案。

kenny

  • 訪客
Mail Service Redundant Design
« 回覆 #14 於: 2002-06-05 22:30 »
引述: "duncanlo"

參考一下人家的作法!
http://www.turbolinux.com.cn/solutions/solutioncolumn/3Rsoftsolution.pdf


duncan 兄提供的這個文件﹐似乎沒太多技術資訊可以參考。給 sales 用或許是不錯的~~  ^_^

fleece

  • 榮譽博士
  • 可愛的小學生
  • *
  • 文章數: 29
    • 檢視個人資料
    • http://zserver.vlabtaiwan.com
Mail Service Redundant Design
« 回覆 #15 於: 2002-06-05 22:33 »
當然不用 Domain Relay 的話 一定會有 E-Mail Account 相關的問題衍生
回到最開始的地方好了 記得您寫過的一段敘述(也是我感興趣之處):
--
『我們的郵件並非真的完全轉到下一個 MX 主機接收﹐而是先將郵件暫時佇列( queue ) 在那台機器上﹐當原來的 MX 主機恢復連線之後﹐郵件會自動的從佇列主機那邊送回來』
--
如果郵件可以自動代收, 又提供自動佇列, 之後郵件又會自動從佇列主機送回
那我這麼辛苦幹嘛^^ Take easy

duncanlo

  • SA 苦力組
  • 俺是博士!
  • *****
  • 文章數: 7312
    • 檢視個人資料
Mail Service Redundant Design
« 回覆 #16 於: 2002-06-05 22:33 »
引述: "netman"
引述: "duncanlo"

參考一下人家的作法!
http://www.turbolinux.com.cn/solutions/solutioncolumn/3Rsoftsolution.pdf


duncan 兄提供的這個文件﹐似乎沒太多技術資訊可以參考。給 sales 用或許是不錯的~~  ^_^


這是把Mail的服務拆開來獨立,
對於比較大的Mail System來說,
每個服務可以增加主機或是改成HA架構....

kenny

  • 訪客
Mail Service Redundant Design
« 回覆 #17 於: 2002-06-05 22:43 »
引述: "fleece"
當然不用 Domain Relay 的話 一定會有 E-Mail Account 相關的問題衍生
回到最開始的地方好了 記得您寫過的一段敘述(也是我感興趣之處):
--
『我們的郵件並非真的完全轉到下一個 MX 主機接收﹐而是先將郵件暫時佇列( queue ) 在那台機器上﹐當原來的 MX 主機恢復連線之後﹐郵件會自動的從佇列主機那邊送回來』
--
如果郵件可以自動代收, 又提供自動佇列, 之後郵件又會自動從佇列主機送回
那我這麼辛苦幹嘛^^ Take easy


嗯﹐這樣好了﹐說一萬遍﹐不如實作一遍。要留意的是﹕sendmail 預設是 4 小時清一次 queue ﹐如果想手工清﹐則可以在任何時候輸入﹕sendmail -q

歡迎將測試結果回來和大家分享。
我記得以前有整理過設定步驟的﹐等我找到再貼上來。抱歉﹐網站上的文章﹐ NAT 之後就沒更新了﹐等我寫到 mail 的部份﹐再補上吧﹐現在沒有目前的步驟啦。

kenny

  • 訪客
Mail Service Redundant Design
« 回覆 #18 於: 2002-06-05 23:17 »
胡亂翻了一下舊信﹐一時之間沒找到相關的信件。我想﹐這裡將步驟打一次應該更快﹕

先假設彼此都使用 sendmail 8.1x.x ﹐然後 DNS 如下﹕

$ORIGIN my.domain.com.
@  IN  MX  10  a.my.domain.com.
@  IN  MX  20  b.my.domain.com.
a    IN  A  1.2.3.4
b    IN  A  1.2.3.5

接下來在 a 機器上面做如下動作﹕
echo "my.domain.com" >> /etc/mail/local-host-names
echo "a.my.domain.com" >> /etc/mail/local-host-names
service sendmail restart

再於 b 機器上面做如下動作﹕
echo "b.my.domain.com" >> /etc/mail/local-host-names
echo "my.domain.com      RELAY"  >> /etc/mail/access
echo "a.my.domain.com      RELAY"  >> /etc/mail/access
makemap hash /etc/mail/access.db < /etc/mail/access
service sendmail restart
# 注﹕在 b 機器上的 /etc/mail/local-host-names 檔案中不能有 my.domain.com ﹗否則會視為 local 而不是 queue ﹐請再三確認。

用外面的 client 測試郵件(user@my.domain.com)能成功的寄達 a 之後﹐然後將 a 的 sendmail 關閉﹕
service sendmail stop

然後再寄出相同的郵件﹐確定能 queue 到 b 機器上﹐可檢查 /var/log/maillog
確定後﹐將 a 機器的 sendmail 從新啟動﹕
service sendmail start

再於 b 上面清理 queue ﹕
sendmail -q

應該就知道這個機制是否有用了。上面的步驟是我記憶所述﹐我之前公司的機器就是這樣做的﹐而我也在家中的環境測試過了。如果您這邊不行﹐我們再來 review 好了。

另外﹐我剛纔查了一下﹐sendmail 好像不是 4 個小時﹐而是 1 個小時清一次 queue ﹐如果 4 小時還不能完成﹐會送一個通知給 sender ﹔如果五天還不成功﹐才退信。若想縮短 sendmail 的 queue 時間﹐可以修改 /etc/sysconfig/sendmail﹐將 QUEUE= 設為 5m ﹐再重新啟動 sendmail ﹐這樣最多等 5 分鐘就見分曉了。

關於 sendmail 的一些工作流程﹐可以參考如下討論﹕
http://phorum.study-area.org/viewtopic.php?t=9531

老實說﹐小弟關於 mx 的理解以前也存在很大的錯誤﹐後來在 network 版上得網友指正才得以修正。若想知道這個討論﹐可以參考﹕
http://www.study-area.org/tips/sendmail_mx.htm
(我給它的題目就叫 sendmail 與 mx )

fleece

  • 榮譽博士
  • 可愛的小學生
  • *
  • 文章數: 29
    • 檢視個人資料
    • http://zserver.vlabtaiwan.com
Mail Service Redundant Design
« 回覆 #19 於: 2002-06-05 23:29 »
謝謝您的資料 Domain Relay 的方式我很久以前就試過了
目前我用作備援的 Secondary Mail Server 不允許我做這樣的事
--
我的建議 (真的純粹只是建議 您愛聽不聽)
您那段 DNS MX 的說明雖說 DNS 只是 DNS 不談 Mail Server
十個有九個半 會有跟我一樣的想法 一樣的疑惑
我自認我的中文算是非常優的 也許是我一開始就誤解了 就算是雞同鴨講吧

kenny

  • 訪客
Mail Service Redundant Design
« 回覆 #20 於: 2002-06-05 23:35 »
引述: "fleece"
我的建議 (真的純粹只是建議 您愛聽不聽)
您那段 DNS MX 的說明雖說 DNS 只是 DNS 不談 Mail Server
十個有九個半 會有跟我一樣的想法 一樣的疑惑
我自認我的中文算是非常優的 也許是我一開始就誤解了 就算是雞同鴨講吧


多謝您的意見。看來我補充說明一下好了。

duncanlo

  • SA 苦力組
  • 俺是博士!
  • *****
  • 文章數: 7312
    • 檢視個人資料
Mail Service Redundant Design
« 回覆 #21 於: 2002-06-05 23:47 »
看來Mail/Queue的那一段要特別說明!

另外再請較前輩一個問題,
這種機制,除了把信從SenderServer移到2nd MX Server,
並把Queue的時間延長外,還有什麼優點?

kenny

  • 訪客
Mail Service Redundant Design
« 回覆 #22 於: 2002-06-05 23:51 »
引述: "duncanlo"
看來Mail/Queue的那一段要特別說明!

已經補上﹐請參考﹕
http://www.study-area.org/linux/servers/linux_dns.htm#mx

引用

另外再請較前輩一個問題,
這種機制,除了把信從SenderServer移到2nd MX Server,
並把Queue的時間延長外,還有什麼優點?


應該不是問在下我吧﹖

duncanlo

  • SA 苦力組
  • 俺是博士!
  • *****
  • 文章數: 7312
    • 檢視個人資料
Mail Service Redundant Design
« 回覆 #23 於: 2002-06-06 00:13 »
引述: "netman"

已經補上﹐請參考﹕
http://www.study-area.org/linux/servers/linux_dns.htm#mx


假如可以把你上面那個sendmail設定的範例加進去更好,
很多人知道這MX觀念,但mail/queue那一段不會設啦!
因為有些人以為多建一台mail server就行了...


引用

另外再請較前輩一個問題,
這種機制,除了把信從SenderServer移到2nd MX Server,
並把Queue的時間延長外,還有什麼優點?

應該不是問在下我吧﹖


也請教您的意見!

因為除非是設計過的備援主機,
不論是HA或Domino那種,
多設這個感覺起來效用不大,
(因連線問題,轉移負載的情況不算)
反而很多防毒牆到是用這個機制來作!

kenny

  • 訪客
Mail Service Redundant Design
« 回覆 #24 於: 2002-06-06 00:29 »
引述: "duncanlo"
假如可以把你上面那個sendmail設定的範例加進去更好,
很多人知道這MX觀念,但mail/queue那一段不會設啦!
因為有些人以為多建一台mail server就行了...


嗯﹐因為那邊是講 DNS 的﹐所以沒將太多東西扯進去了﹐否則沒完沒了。目前我已經埋下伏筆說將在另外文章說明﹐同時也提供一個 link 回來這看討論。應該夠了吧~~

事實上﹐只要對 sendmail 清楚的話﹐都應該知道怎麼做的。

引用
也請教您的意見!

因為除非是設計過的備援主機,
不論是HA或Domino那種,
多設這個感覺起來效用不大,
(因連線問題,轉移負載的情況不算)
反而很多防毒牆到是用這個機制來作!

呵﹐忽然丟個‘前輩’出來﹐誰敢接啊~~ ^_^

以這個 queue 的設計來說﹐假如已經有 redudant 設計的話﹐的確沒太大好處。唯一好處是不至於馬上退信。這應該也是蠻重要的﹐尤其對新客戶來說﹗當系統管理員最擔心就是一不小心把公司的財路擋了。所以得非常小心謹慎﹐時時刻刻站在公司整體利益為立足點去解決問題﹐就很多事情都很順利﹐否則不會是一個好的管理員。財力夠的話﹐當然考慮更好的辦法﹐但財力有限或環境不允許(請參考晚輩前面提到的‘中小系統’之說明)﹐用目前的方法是比較便宜而且容易實作的方案﹐因為牽涉的資源﹑設定都沒那麼複雜。

kenny

  • 訪客
Mail Service Redundant Design
« 回覆 #25 於: 2002-06-06 00:43 »
啊~~ 突然想起 fleece 竟然就是 vlab 的站長﹗

恕罪恕罪﹐真是有眼不識泰山﹗居然還在前輩面前獻醜呢~~ 真是班門弄斧了﹗(好丟臉哦~~~  :p )

duncanlo

  • SA 苦力組
  • 俺是博士!
  • *****
  • 文章數: 7312
    • 檢視個人資料
Mail Service Redundant Design
« 回覆 #26 於: 2002-06-06 01:11 »
引述: "netman"
以這個 queue 的設計來說﹐假如已經有 redudant 設計的話﹐的確沒太大好處。唯一好處是不至於馬上退信。這應該也是蠻重要的﹐尤其對新客戶來說﹗當系統管理員最擔心就是一不小心把公司的財路擋了。所以得非常小心謹慎﹐時時刻刻站在公司整體利益為立足點去解決問題﹐就很多事情都很順利﹐否則不會是一個好的管理員。財力夠的話﹐當然考慮更好的辦法﹐但財力有限或環境不允許(請參考晚輩前面提到的‘中小系統’之說明)﹐用目前的方法是比較便宜而且容易實作的方案﹐因為牽涉的資源﹑設定都沒那麼複雜。


即然可以有多一台硬體主機,
那應該就可以作HA的可能,
除非其中有一台是"兼差"的!

仔細想想,規劃真的很重要,
有時比擴充還要花成本...

大家有興趣真的可以去參考一下Domino/Notes的作法,
它的架構和Cluster真的是有特別設計過的,
現在用OpenSource想作到像它那樣都不是可以很輕易的達成!

fleece

  • 榮譽博士
  • 可愛的小學生
  • *
  • 文章數: 29
    • 檢視個人資料
    • http://zserver.vlabtaiwan.com
Mail Service Redundant Design
« 回覆 #27 於: 2002-06-06 02:27 »
站長您太客氣了
很多東西本來就是很直觀的 談不上對錯好壞
對我來講 Secondary Mail Server 只是當個 Buffer 作用罷了
(誠如您所說的 只是不想 Lose 任何一封信 特別是可能重要的信)
Mail-Forwarding 機制修改一下
又何曾不能待 Primary Server Ready 時再 Forward 回去
我用了一個 Internet 上免費的 Service http://www.zoneedit.com
滿好用的 我拿來當 vLAB Domain 的備援
Zoneedit 提供免費的 Domain Name 託管
提供免費的 E-Mail Forwarding
另外也有免費 Dynamic DNS 的服務 (使用自己註冊的 Domain 喔)
這麼好用又免費的東西 總不能還叫他們提供其他諸如 RELAY 的功能吧
--
對於 Operating System & Programming Design 是我生疏好一陣子的東西了
整天都是在弄 Internetwork Infrastructure 的東西
不過再一些些時間 我就可以把 Routing/Switching & Security 的東西打發了
關於 Redundant 成本是最大的考量 其他種種何嘗不也是如此
Solution 很多很好沒錯 但是 Sorry 沒錢就是沒錢
什麼都要錢 硬體要錢 軟體要錢 頻寬也要錢 東西弄起來了要人管理也要錢
--
另外, 請問一下 study-area 是放在什麼地方ㄚ
有個 Routing/Switching LAB 想 Free Share 給大家
八顆 Cisco 2500 Router & 一顆跟 Catalyst 5002 同等級的 LAN Switch
可以練習所有的 IGP(RIP/IGRP/EIGRP/OSPF/ISIS) & BGP 及複雜的 Topology
只是一直找不到適合的地點 (空間, 電力, 網路) 而且最好是免費的
然後可以有人可以出來主持這個 LAB 的 協助大家以 Remote LAB 方式使用
--
study-area 經營的滿好的
看出站長們花了很多心力 (Sorry, vlab 差多了)
如果有網友在 CCIELAB 需要協助的
我們還是很樂意幫忙的

fleece

  • 榮譽博士
  • 可愛的小學生
  • *
  • 文章數: 29
    • 檢視個人資料
    • http://zserver.vlabtaiwan.com
Mail Service Redundant Design
« 回覆 #28 於: 2002-06-06 03:56 »
遺漏了一點 只收不能送 問題只算解決了一半
介紹另一個好用的 Shareware
http://www.mailutilities.com/adr
直接拿自己的電腦當 SMTP Server 使用
Mail-Server 即使掛掉了
送出去的信依然帶著自己常用的那個 E-MAIL Address
(當然要拿來冒用別人的 E-Mail Address 發信也是可以的)
--
一些不痛不癢的經驗 大家隨便看看
--
之前東森 Cable Modem 十幾萬用戶用的 Mail System 就是我帶的所屬部門負責的其中一項
只是在兵荒馬亂中才調整好就被賣掉了 現在有沒有人管也不知道-_-"

kenny

  • 訪客
Mail Service Redundant Design
« 回覆 #29 於: 2002-06-06 10:03 »
fleece 兄好﹐昨晚多有失敬﹐望大人大量不記小人之過。還想起去年也曾受教於您﹐尚未有機會報答呢﹗真不好意思。這次再次感謝您的指正與教導﹐實在感謝啦﹗

因為小弟沒什麼機會接觸 infrastructure 的東西(頂多是小公司機房而已)﹐因此不常上 vlab 受教﹐不過看來經營得不錯啊﹐從討論版的熱烈程度來說就可見一斑了。辛苦各位大大了﹗像 fleece 兄如此熱心的人﹐現在的環境中﹐還真是不可多得呢﹗

目前 study-area 放在學術網路﹐一台主機(www)在高雄縣教網中心﹑另外一台(phorum)則放在致遠管理學院﹐都是人家好心施捨的啦~~ ^_^  然而目前正和 slat 合作﹐籌建新的 www 平臺﹐主機將在中研院計算機中心﹐屆時應該有更多的資源和支援的。不知道 fleence 兄所提的 Remote LAB 是怎麼一回事呢﹖不正是 vlab 目前的經營經營項目之一嗎﹖還是閣下還有多餘的資源能夠提供出來而需要額外的場地﹖然則﹐或許我再幫忙問問看~~~  等我先打探一下﹐稍後可能需要 fleece 兄提供進一步的資料﹐界時再麻煩您就是了。當然﹐如有其他資訊﹐歡迎隨時來信指教啦。

p.s.
對了﹐網路中人都習慣那麼晚才睡覺嗎﹖多注意身體哦~~