熱點推薦:
您现在的位置: 電腦知識網 >> 操作系統 >> Windows服務器 >> 正文

詳析郵件服務器郵件存儲和日志

2013-11-23 21:50:53  來源: Windows服務器 

  本文以數據庫的基本原理為基礎分析了EXCHANGE SERVER的存儲系統並說明了各部分的作用
  
  IIS服務和ESE的層次關系
  IIS服務是EXCHANGE服務器中重要的服務之一它控制著對郵箱和PF的存儲操作請求EXCHANGE服務器的存儲實際上是由ESE的數據庫引擎來管理的這個ESE引擎是微軟專門為保存非關系型數據而開發的目前在微軟的很多產品中都有廣泛的應用AD數據庫DHCPWINSSRS等等
  
  EXCHANGE的數據庫是由EDB文件STM文件和LOG文件組成在這些文件裡微軟使用了B+樹的內部數據結構ESE的引擎的任務之一就是當IIS服務請求訪問數據庫的時候把這些請求轉化為對內部數據結構的讀寫訪問B+樹的特點是能夠對存儲在硬盤上的數據提供快速訪問能力微軟利用B+樹作為ESE的後台結構的主要原因就是盡可能的提高訪問數據時I/O性能當然這些結構對於EXCHANGE STORE來說是透明的
  
  另外作為一個數據庫系統ESE有責任提供事務級別的操作的支持並維護數據庫的完整性和一致性對數據庫系統而言我們提到事務時一般用ACID來描述事務的特點
  
  AAtomic(原子的)事務必須是全或全無的操作要麼全部成功更新要麼全部不被更新
  
  CConsistent(一致的)一個成功提交的事務必須使數據庫處於一個一致的狀態
  
  IIsolated(孤立的)所有未提交的更改都必須能夠和其他事務孤立
  
  DDurable(持久的)當事務一旦提交所做的更改必須存儲到穩定的介質上防止系統失敗導致的數據庫不一致(此點非常重要!!)
  
  EXCHANGE /存儲系統的新特點
  在EXESE的版本為ESE而在EX/ESE版本已經升級ESEESE引起在以下方面得到了改進
  
  * I/O性能進一步提高和優化
  
  * 對日志文件增加了計算校驗操作
  
  * 提高了ESEUTIL等工具的維護速度
  
  而IIS也在以下方面有了更新
  
  * 在每個SERVER上提供多個SG支持
  
  * 數據庫STM文件格式的引入提高了INTERNET郵件的性能
  
  * WSS的引入用戶可以使用多種協議訪問數據庫
  
  EDB和STM的關系
  常有人問EDB文件是數據庫那STM文件是做什麼用的?可以刪除嗎?
  
  在EX只有EDB文件因為在EX發布時微軟主推的是內部郵件系統因此其主要協議為MAPI這是微軟的私有郵件西醫EDB文件是專門為此協議優化過的因此在EX為了支持INTERNET郵件必須在每次處理INTERNET郵件時做一個格式轉換這顯然帶來了性能的損失
  
  在EX微軟加大了對INTERNET郵件的支持這就是STM文件的來源MAPI格式是RPC和二進制標准的而STM是純文本加上一些MIME編碼格式這樣的區別使得它們不可能存儲在同一數據庫裡因此EX微軟開始使用EDB和STM兩個文件來分別保存兩種格式的郵件並且在兩個文件之間建立了引用和關聯對於用戶來說它的郵箱實際上是跨越了EDB和STM文件共同組成的另外需要注意的是EDB文件中還保留著用戶的郵箱結構所以EDB文件更加重要那麼EDB和STM是怎麼協同工作的呢?我們以幾個情景來分析之
  
  情景一用戶使用OUTLOOK(MAPI)發送接收郵件
  
  在該情景下用戶將郵件通過MAPI協議提交給數據庫直接被保存EDB文件中當用戶通過MAPI訪問郵箱裡的郵件時如果被訪問的郵件在EDB裡直接返回如果在STM裡(如外來郵件)則執行轉換將STM轉換為EDB文件格式再返回用戶
  
  情景二用戶使用標准SMTP/POP/IMAP等協議訪問
  
  用戶使用非MAPI協議提交的郵件內容保存在STM文件裡但是由於EDB裡有郵箱結構STM沒有因此系統會把郵件的重要信息提取出來放在EDB裡當用戶用MAPI提取郵件時過程同上當用戶通過標准協議訪問時同樣需要進行格式轉換轉換為STM文件格式返回 這些轉換是在後台發生的對用戶來說是透明的通過上面的描述你會看到這兩個文件是緊密聯系的缺一不可所以在任何時間我們都不要單獨操作這兩個文件它們是一個整體同時也要注意的是無論用戶使用何方式訪問郵箱都需要向EDB文件請求郵箱結構信息這是需要注意的
  
  LOG文件的重大作用
  在論壇裡經常會看到有人說我的硬盤怎麼很快就沒了一看原來是日志文件搞的鬼於是就有人刪除日志文件甚至使用循環日志來強制減少日志甚至有人提出這樣的疑問日志到底有什麼用?是不是多余的?那我們來看看日志的重大作用
  
  對於一個SG來說系統會產生一系列的日志這些日志的擴展名為LOG前綴一般是EE……除了這些連續的日志文件外還有一些特殊的日志文件(reslogreslogexchk)))它們又有什麼用呢?我們的管理員通常不喜歡備份這一操作因此對這些日志是痛恨不已啊那麼微軟在EXCHANGE數據庫系統中引入日志的作用難道真的是多此一舉嗎?我們從以下幾個方面來考察一下日志的作用
  
  作為一個企業級的郵件系統必須要保證數據安全和完整必須能夠面對隨時可能發生的意外災難把數據損失降低到最小
  
  必須提供高性能的郵件處理能力對數據庫中的郵件的事務操作在完成後必須馬上(或是說立即)被記錄在存儲介質上(見前面的事務持久性說明)
  
  災難發生後使用數據庫備份恢復必須要返回到災難發生前一刻的數據庫狀態(這是至關重要的!!)
  
  現在我們來更進一步的看一下當用戶要修改郵箱中的內容時被修改的內容首先被提取出來放到內存中實際的修改是發生在內存裡的這是眾所周知的當修改完成後這些內容必須被盡快寫回存儲介質這樣才表示一個事務成功完成了
  
  從事務的描述中我們可以看到事務是具有原子特性的為了保證數據庫的一致和完整事務必須全部成功或全部失敗如果事務失敗則必須回滾到事務開始的狀態而當郵件在內存中修改完成後此時事務並沒有完成(為什麼呢?)因為一旦系統崩潰這些修改就丟失了所以要確保事務修改完成必須盡快將修改寫回到數據庫裡去(也就是硬盤上)這也是事務的持久性要求注意我們這裡說的第一時間或是盡快是一個什麼樣的概念如果我們直接修改EDB文件由於EDB文件比較大那麼在硬盤上修改一個大文件就 需要花費大量的時間在等待和尋找數據存儲塊上(見操作系統原理)當系統出現高負載的繁忙狀態時這將是一個非常大的瓶頸也就無法做到盡快那怎麼辦呢?所以數據庫系統使用了日志而日志通常很小(EXCHANGE的日志只有MB)向這些文件寫入修改結果是很快速的因此當內存的修改完成後這些結果就會立即寫入日志中以保證了事務的持久性當成功寫入日志後該事務就成功完成了(現在在硬盤上了不會因為當機丟失了)接下來ESE引擎會在後台慢慢將這些日志裡的修改記錄寫回真正的數據庫裡去(這對用戶來說已經不是那麼重要了)這就是日志的第一個作用確保事務在第一時間(盡可能快的)保存到非易失存儲器上(提供了事務持久性支持)
  
  根據上面的藐視我們看到運行中的EXCHANGE數據庫是由三個部分組成的
  
  * 內存中已經完成處理還沒有寫會到日志裡的內容(Dirt page)
  
  * 還沒有寫到數據庫文件裡的日志內容
  
  * EDB和STM數據庫文件
  
  對於第一個部分一旦掉電就回丟失的是最不安全的而對於第二部分的內容系統通過檢查點文件(CHK)來標記哪些日志已經被寫入數據庫了而哪些還沒有CHK文件類似一個指針我們可以用ESEUTIL /MK來檢查CHK文件裡的內容在該命令的輸出中的checkpoint:<0x8,26d1,29>這樣的東西就是檢查點位置它表示Ex的日志的頁面序號已經被成功寫入數據庫了大家可以自己看看
  
  前面提到過EXCHANGE系統在出現災難時應能恢復到災難發生前的時刻的狀態這是非常重要的但即使是最勤快的管理員也只能在指定的預定時間內做系統備份而不可能時時刻刻的都在備份那麼在備份完成後到災難發生之前的這段數據該如何保護呢?是不是就任由它丟失呢?顯然是不可能的那答案是什麼呢?就是日志文件前面我們知道任何對數據庫的更改都先寫入日志裡再由日志寫入數據庫這樣我們只要找到日志文件就可以重新進行模擬的操作來完成備份後的數據庫文件的更改了我們舉個例子來看看
  
  假設我們在凌晨點完成了一次FULLBACKUP備份完成後系統正常運行到下午點的時候系統突然崩潰管理員用凌晨點的數據恢復了數據庫那麼從凌晨點到下午點這段時間的數據變更就只能依賴於日志了當完成數據庫恢復後系統會自動的跟蹤到關聯的日志文件如果發現有比當前數據庫還新的日志存在系統就會自動的按照日志的順序將更改寫回到數據庫中去因此這樣一來從凌晨點到下午點的數據變更就被完整的恢復了這就是日志的第二個作用保證系統備份和恢復的完整性當然前提是沒有使用循環日志!!(看到了吧使用循環日志的危害是相當大的比起你的數據來說多做幾次備份不是沒有意義的吧?
  
  說到這裡有人可能要問如果數據庫和日志同時損壞如何辦?答案是盡量避免這樣的情況發生首先數據庫損壞的幾率要大於日志另外微軟建議將數據庫和日志分別存儲在不同的磁盤上要是這樣還會同時壞那就沒有辦法了呵呵對於管理員對日志文件的抱怨合理的解決方法是定期做備份啟用循環日志是不正確的做法當啟用循環日志後一旦系
From:http://tw.wingwit.com/Article/os/fwq/201311/29784.html
    推薦文章
    Copyright © 2005-2013 電腦知識網 Computer Knowledge   All rights reserved.