- 掛牌上市企業(yè)
- 60秒人工響應
- 99.99%連通率
- 7*24h人工
- 故障100倍補償
詳析郵件服務器郵件存儲和日志 |
| 發(fā)布時間: 2012/6/17 23:15:11 |
|
本文以數(shù)據(jù)庫的基本原理為基礎，分析了EXCHANGE SERVER的存儲系統(tǒng)，并說明了各部分的作用。 一、IS服務和ESE的層次關系 IS服務是EXCHANGE服務器中重要的服務之一，它控制著對郵箱和PF的存儲操作請求，EXCHANGE服務器的存儲實際上是由ESE的數(shù)據(jù)庫引擎來管理的。這個ESE引擎是微軟專門為保存非關系型數(shù)據(jù)而開發(fā)的，目前在微軟的很多產(chǎn)品中都有廣泛的應用，如：AD數(shù)據(jù)庫、DHCP、WINS、SRS等等。 EXCHANGE的數(shù)據(jù)庫是由EDB文件、STM文件和LOG文件組成。在這些文件里，微軟使用了“B+樹”的內(nèi)部數(shù)據(jù)結構。ESE的引擎的任務之一，就是當IS服務請求訪問數(shù)據(jù)庫的時候，把這些請求轉化為對內(nèi)部數(shù)據(jù)結構的讀寫訪問。B+樹的特點是能夠對存儲在硬盤上的數(shù)據(jù)提供快速訪問能力。微軟利用“B+樹”作為ESE的后臺結構的主要原因，就是盡可能的提高訪問數(shù)據(jù)時I/O性能。當然，這些結構對于EXCHANGE STORE來說是透明的。 另外，作為一個數(shù)據(jù)庫系統(tǒng)，ESE有責任提供事務級別的操作的支持，并維護數(shù)據(jù)庫的完整性和一致性。對數(shù)據(jù)庫系統(tǒng)而言，我們提到事務時，一般用ACID來描述事務的特點。 A--Atomic(原子的)：事務必須是全或全無的操作，要么全部成功更新，要么全部不被更新 C--Consistent(一致的)：一個成功提交的事務必須使數(shù)據(jù)庫處于一個一致的狀態(tài)。 I--Isolated(孤立的)：所有未提交的更改都必須能夠和其他事務孤立。 D--Durable(持久的)：當事務一旦提交，所做的更改必須存儲到穩(wěn)定的介質(zhì)上，防止系統(tǒng)失敗導致的數(shù)據(jù)庫不一致。(此點非常重要!!) 二、EXCHANGE 2000/2003存儲系統(tǒng)的新特點 在EX5.5中，ESE的版本為ESE97，而在EX2000/2003里，ESE版本已經(jīng)升級ESE98了。ESE引起在以下方面得到了改進： * I/O性能進一步提高和優(yōu)化 * 對日志文件增加了計算校驗操作 * 提高了ESEUTIL等工具的維護速度 而IS也在以下方面有了更新： * 在每個SERVER上提供多個SG支持 * 數(shù)據(jù)庫STM文件格式的引入，提高了INTERNET郵件的性能 * WSS的引入，用戶可以使用多種協(xié)議訪問數(shù)據(jù)庫 三、EDB和STM的關系 常有人問，EDB文件是數(shù)據(jù)庫，那STM文件是做什么用的?可以刪除嗎? 在EX5.5里，只有EDB文件，因為在EX5.5發(fā)布時，微軟主推的是內(nèi)部 郵件系統(tǒng)，因此其主要協(xié)議為MAPI，這是微軟的私有郵件西醫(yī)，EDB文件是專門為此協(xié)議優(yōu)化過的。因此在EX5.5中，為了支持INTERNET郵件，必須在每次處理INTERNET郵件時，做一個格式轉換。這顯然帶來了性能的損失。 在EX2000里，微軟加大了對INTERNET郵件的支持，這就是STM文件的來源。MAPI格式是RPC和二進制標準的，而STM是純文本加上一些MIME編碼格式，這樣的區(qū)別使得它們不可能存儲在同一數(shù)據(jù)庫里。因此EX2000中，微軟開始使用EDB和STM兩個文件來分別保存兩種格式的郵件。并且在兩個文件之間建立了引用和關聯(lián)。對于用戶來說，它的郵箱實際上是跨越了EDB和STM文件共同組成的。另外，需要注意的是，EDB文件中還保留著用戶的郵箱結構。所以EDB文件更加重要。那么EDB和STM是怎么協(xié)同工作的呢?我們以幾個情景來分析之。 情景一：用戶使用Outlook(MAPI)發(fā)送接收郵件 在該情景下，用戶將郵件通過MAPI協(xié)議提交給數(shù)據(jù)庫，直接被保存EDB文件中。當用戶通過MAPI訪問郵箱里的郵件時，如果被訪問的郵件在EDB里，直接返回，如果在STM里(如外來郵件)，則執(zhí)行轉換，將STM轉換為EDB文件格式，再返回用戶。 情景二：用戶使用標準SMTP/POP3/IMAP4等協(xié)議訪問 用戶使用非MAPI協(xié)議提交的郵件，內(nèi)容保存在STM文件里，但是由于EDB里有郵箱結構，STM沒有，因此系統(tǒng)會把郵件的重要信息提取出來，放在EDB里。當用戶用MAPI提取郵件時，過程同上，當用戶通過標準協(xié)議訪問時，同樣需要進行格式轉換，轉換為STM文件格式返回。 這些轉換是在后臺發(fā)生的。對用戶來說是透明的。通過上面的描述，你會看到，這兩個文件是緊密聯(lián)系的缺一不可。所以，在任何時間我們都不要單獨操作這兩個文件，它們是一個整體。同時也要注意的是，無論用戶使用何方式訪問郵箱，都需要向EDB文件請求郵箱結構信息，這是需要注意的。 四、LOG文件的重大作用 在論壇里經(jīng)常會看到有人說我的硬盤怎么很快就沒了，一看原來是日志文件搞的鬼，于是就有人刪除日志文件，甚至使用循環(huán)日志來強制減少日志，甚至有人提出這樣的疑問，日志到底有什么用?是不是多余的?那我們來看看日志的重大作用。 對于一個SG來說，系統(tǒng)會產(chǎn)生一系列的日志，這些日志的擴展名為LOG，前綴一般是E00、E01……除了這些連續(xù)的日志文件外，還有一些特殊的日志文件(res1.log,res2.log,e0x.chk)))，它們又有什么用呢?我們的管理員通常不喜歡備份這一操作，因此對這些日志是痛恨不已啊。那么微軟在EXCHANGE數(shù)據(jù)庫系統(tǒng)中引入日志的作用難道真的是多此一舉嗎?我們從以下幾個方面來考察一下日志的作用： 1、作為一個企業(yè)級的郵件系統(tǒng)，必須要保證數(shù)據(jù)安全和完整。必須能夠面對隨時可能發(fā)生的意外災難，把數(shù)據(jù)損失降低到最小。 2、必須提供高性能的郵件處理能力，對數(shù)據(jù)庫中的郵件的事務操作在完成后必須馬上(或是說立即)被記錄在存儲介質(zhì)上(見前面的事務持久性說明) 3、災難發(fā)生后，使用數(shù)據(jù)庫備份恢復必須要返回到災難發(fā)生前一刻的數(shù)據(jù)庫狀態(tài)(這是至關重要的!!) 現(xiàn)在我們來更進一步的看一下，當用戶要修改郵箱中的內(nèi)容時，被修改的內(nèi)容首先被提取出來放到內(nèi)存中，實際的修改是發(fā)生在內(nèi)存里的，這是眾所周知的，當修改完成后，這些內(nèi)容必須被盡快寫回存儲介質(zhì)，這樣才表示一個事務成功完成了。 從事務的描述中我們可以看到，事務是具有原子特性的，為了保證數(shù)據(jù)庫的一致和完整，事務必須全部成功或全部失敗，如果事務失敗，則必須回滾到事務開始的狀態(tài)。而當郵件在內(nèi)存中修改完成后，此時事務并沒有完成(為什么呢?)因為一旦系統(tǒng)崩潰，這些修改就丟失了。所以要確保事務修改完成，必須盡快將修改寫回到數(shù)據(jù)庫里去(也就是硬盤上)。這也是事務的持久性要求。注意，我們這里說的第一時間或是盡快，是一個什么樣的概念。如果我們直接修改EDB文件，由于EDB文件比較大，那么在硬盤上修改一個大文件，就 需要花費大量的時間在等待和尋找數(shù)據(jù)存儲塊上(見操作系統(tǒng)原理)，當系統(tǒng)出現(xiàn)高負載的繁忙狀態(tài)時，這將是一個非常大的瓶頸。也就無法做到“盡快”了。那怎么辦呢?所以數(shù)據(jù)庫系統(tǒng)使用了日志，而日志通常很小(EXCHANGE的日志只有5MB)，向這些文件寫入修改結果是很快速的，因此當內(nèi)存的修改完成后，這些結果就會立即寫入日志中，以保證了事務的持久性。當成功寫入日志后，該事務就成功完成了(現(xiàn)在在硬盤上了，不會因為當機丟失了)接下來，ESE引擎會在后臺慢慢將這些日志里的修改記錄寫回真正的數(shù)據(jù)庫里去(這對用戶來說已經(jīng)不是那么重要了)，這就是日志的第一個作用：確保事務在第一時間(盡可能快的)保存到非易失存儲器上(提供了事務持久性支持)。 根據(jù)上面的藐視，我們看到運行中的EXCHANGE數(shù)據(jù)庫，是由三個部分組成的： * 內(nèi)存中已經(jīng)完成處理還沒有寫會到日志里的內(nèi)容(Dirt page) * 還沒有寫到數(shù)據(jù)庫文件里的日志內(nèi)容 * EDB和STM數(shù)據(jù)庫文件 對于第一個部分，一旦掉電就回丟失的，是最不安全的。而對于第二部分的內(nèi)容，系統(tǒng)通過檢查點文件(CHK)來標記哪些日志已經(jīng)被寫入數(shù)據(jù)庫了，而哪些還沒有。CHK文件類似一個指針。我們可以用“ESEUTIL /MK”來檢查CHK文件里的內(nèi)容，在該命令的輸出中的checkpoint:<0x8,26d1,29>這樣的東西就是檢查點位置，它表示E0x00008的日志的頁面序號已經(jīng)被成功寫入數(shù)據(jù)庫了。大家可以自己看看。。：) 前面提到過，EXCHANGE系統(tǒng)在出現(xiàn)災難時，應能恢復到災難發(fā)生前的時刻的狀態(tài)。這是非常重要的。但即使是最勤快的管理員，也只能在指定的預定時間內(nèi)做系統(tǒng)備份，而不可能時時刻刻的都在備份。那么在備份完成后到災難發(fā)生之前的這段數(shù)據(jù)該如何保護呢?是不是就任由它丟失呢?顯然是不可能的。那答案是什么呢?就是日志文件。前面我們知道，任何對數(shù)據(jù)庫的更改都先寫入日志里，再由日志寫入數(shù)據(jù)庫，這樣我們只要找到日志文件，就可以重新進行模擬的操作來完成備份后的數(shù)據(jù)庫文件的更改了，我們舉個例子來看看： 假設我們在凌晨3點完成了一次FULLBACKUP，備份完成后，系統(tǒng)正常運行，到下午4點的時候，系統(tǒng)突然崩潰。管理員用凌晨3點的數(shù)據(jù)恢復了數(shù)據(jù)庫，那么從凌晨3點到下午4點這段時間的數(shù)據(jù)變更，就只能依賴于日志了。當完成數(shù)據(jù)庫恢復后，系統(tǒng)會自動的跟蹤到關聯(lián)的日志文件，如果發(fā)現(xiàn)有比當前數(shù)據(jù)庫還新的日志存在，系統(tǒng)就會自動的按照日志的順序將更改寫回到數(shù)據(jù)庫中去。因此這樣一來，從凌晨3點到下午4點的數(shù)據(jù)變更就被完整的恢復了。這就是日志的第二個作用：保證系統(tǒng)備份和恢復的完整性。當然前提是沒有使用循環(huán)日志!!(看到了吧，使用循環(huán)日志的危害是相當大的，比起你的數(shù)據(jù)來說，多做幾次備份不是沒有意義的吧? 說到這里，有人可能要問，如果數(shù)據(jù)庫和日志同時損壞，如何辦?答案是：盡量避免這樣的情況發(fā)生。首先數(shù)據(jù)庫損壞的幾率要大于日志，另外，微軟建議將數(shù)據(jù)庫和日志分別存儲在不同的磁盤上，要是這樣還會同時壞，那就沒有辦法了，呵呵。。對于管理員對日志文件的抱怨，合理的解決方法是定期做備份。 本文出自：億恩科技【www.ibaoshan.net】 |
0371-60135900
京公網(wǎng)安備41019702002023號
香港服務器租用
美國服務器租用
電信骨干機房
聯(lián)通骨干機房
