51CTO第2本书样章曝光:DHCP服务器规划与应用案例
生活随笔
收集整理的這篇文章主要介紹了
51CTO第2本书样章曝光:DHCP服务器规划与应用案例
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
??????? 痛苦(手疼)并快樂的寫書過程,51CTO博友們對第一本書的關注超出了我的預期,[url]http://blog.51cto.com/book/[/url]第2本書定位在Windows Server 2003 R2 和Windows Server 2008 倆個平臺之上,之所以這樣,是因為我們不能忽悠大家,2008的案例本來就不多,因為現在大家還都是用這2003,這是一個事實。 下面是第2本書的樣章目錄,以及DHCP規劃的一些建議,與各位分析吧 ? 第3章 DHCP服務器規劃與應用案例 3<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /> 3.1????????? DHCP協議的前生今世··· 4 3.1.1 DHCP協議概述··· 4 1.DHCP的前身··· 4 2.DHCP與BOOTP的對比··· 5 BOOTP與DHCP 相似性··· 5 BOOTP與DHCP 的差別··· 5 DHCP與BOOTP混合應用的案例··· 6 3.1.2 DHCP的工作原理··· 6 1.DHCP端口號的問題··· 6 2.客戶端獲取IP地址的過程··· 7 第1步:尋找DHCP服務器··· 7 第2步:提供IP租用地址··· 8 第3步:接受IP租約··· 8 第4步:租約確認··· 8 3.沒有DHCP服務器也能獲取IP?··· 8 4.DHCP 消息類型小結··· 9 3.1.3 DHCP服務的相關概念··· 9 1.作用域··· 10 2.超級作用域··· 10 3.排除范圍··· 10 4.地址池··· 10 5.租約··· 10 6.保留··· 10 7.選項類型··· 10 8.選項類別··· 10 3.1.4 Windows Server DHCP圖標狀態解密··· 11 1.與服務器狀態相關的圖標··· 11 2.與作用域相關的圖標··· 11 3.與選項有關的圖標··· 12 4.常被提問疑問的控制臺圖標··· 12 3.1.5 DHCP安裝清單··· 13 3.2替換路由器DHCP服務案例··· 14 3.2.1案例需求描述··· 14 1.寬帶路由器的DHCP服務··· 14 2.網絡服務水平有待提高··· 14 3.2.2案例中的問題剖析··· 15 1.負載與DHCP功能問題··· 15 2.DHCP配置的問題··· 16 3.IP地址分配是否合理?··· 16 4.使用淘汰下來的服務器··· 17 5.避免IP沖突的研究··· 17 3.2.3服務器替換與DHCP部署過程··· 18 1.安裝DHCP服務··· 18 2.確定 DHCP 作用域內容··· 19 3.配置DHCP參數··· 20 4.啟用IP地址沖突監聽··· 25 5.本案例中的缺憾··· 26 網絡拓撲改變··· 26 DNS 集成··· 26 WINS服務··· 26 安全性問題··· 26 3.3 VLAN劃分后的DHCP部署案例··· 26 3.3.1 案例需求描述··· 27 3.3.2案例問題分析··· 28 1.未能獲取IP地址的分析··· 28 2.DHCP中繼代理程序··· 28 3.中繼代理工作原理··· 29 4.配置DHCP中繼程序及參數··· 30 啟用DHCP中繼的步驟··· 30 躍點計數閾值··· 33 啟動閾值··· 34 3.3.3案例解決方案··· 34 1.配置核心交換機··· 34 2.配置DHCP服務器選項··· 35 3.為各VLAN創建作用域··· 37 3.4 DHCP冗余規劃建議匯總··· 39 3.4.1 DHCP容錯50/50故障轉移··· 39 3.4.2 DHCP容錯80/20故障轉移··· 40 3.4.3 DHCP容錯100/100故障轉移··· 41 3.4.4 DHCP中繼服務器規劃建議··· 42 1.推薦的設計思路··· 42 2.不推薦的實現方法··· 43 3.4.5 待機作用域的方法··· 43 3.4.6 真正的冗余是群集服務··· 44 3.5 配置DHCP支持MAC地址與IP綁定案例··· 44 3.5.1案例需求··· 44 3.5.2 需求分析與試驗··· 45 1.查找客戶機MAC地址··· 45 2.新建保留··· 45 3.驗證的DHCP保留··· 46 4.獲取全部的MAC地址表··· 46 5.用于DHCP的Netsh命令··· 47 Netsh與DHCP自動管理··· 47 Netsh范例··· 47 DHCP Netsh保留選項語法··· 48 6.關于“保留”的注意事項··· 49 3.5.3案例實施··· 49 3.5.4 DHCP保留技術的反思··· 51 3.6超級作用域與多播作用域的應用··· 51 3.6.1 超級作用域的應用范疇··· 51 3.6.2 創建超級作用域··· 52 3.6.3 多播作用域的應用··· 53 1.典型的視頻會議配置需求··· 53 2.了解多播環境的組建··· 54 3.配置DHCP多播作用域··· 55 3.7 Windows Server 2008 IPv6組網案例··· 57 3.7.1 IPv6組網需求··· 57 3.7.2 DHCPv6與IPv6地址獲取技術分析··· 58 1.IPv6的地址格式··· 58 2.IPv6 地址前綴··· 59 3.IPv6 地址類型··· 59 4.IPv6的地址范圍··· 60 可聚合全局單播地址··· 60 本地使用單點傳送地址··· 61 特殊地址··· 62 兼容性地址··· 62 5.IPv6的地址分配方式··· 62 手動地址配置··· 62 自動地址配置方式··· 63 6.Windows Vista與Windows Server 2008 中IPv6 的自動獲取··· 64 IEEE 802 地址··· 64 IEEE EUI-64 地址··· 64 更改IPv6 自動配置行為··· 64 路由器信息與 DHCPv6配置地址··· 65 Windows Vista 中的 IPv6 自動配置過程··· 66 3.7.3 Windows Server 2008 DHCPv6 的實現··· 67 1.設置DHCP Server IPv6地址屬性··· 67 2.設置路由器屬性··· 68 3.安裝DHCP服務器角色··· 68 4.配置DHCP IPv6 選項··· 72 5.信息驗證與問題分析··· 73 3.8????????? 本章小結··· 74 ? ? ? 3.4 DHCP冗余規劃建議匯總
?????????有人說“DHCP不重要”?我再次反對這樣的說法!DHCP停止工作將會讓無法訪問網絡的用戶火冒三丈。因此在DHCP環境中建立冗余并在其中一臺犧牲的時候,另外一個服務器可以迅速的接過他手中的槍,這樣的網絡才有意義!
???????? 不幸的是,DHCP服務并沒有一種辦法來動態的與另外一個DHCP服務器協同工作以同步客戶端租約情況。我花費了很長時間收集“51CTO專家博客”的建議,對于DHCP冗余,他們提供了多種可供選擇的規劃方案,而每種選項的優缺點可能要你與公司的情況相對應。
3.4.1 DHCP容錯50/50故障轉移
DHCP容錯的50/50故障轉移方法將使用2臺DHCP服務器,每臺服務器在子網上處理同等數量的客戶端請求流量。每臺服務器采用了非常相似的作用域配置,但作用域的范圍不能重疊,以避免IP尋址沖突。
有一個偶然的機會,我的一位朋友參與了一個科研所的辦公網絡改造工程。該網絡擁有200臺以1921.68.100/24 定義的客戶端,原本網絡中只有一臺DHCP服務器,一次意外的硬件故障發生時,這臺服務器停止了服務。由于所有客戶端都采用自動獲取IP的方式,這次整個網絡炸了鍋,網絡管理員迅速手工輸入了幾臺重要客戶端主機的IP地址,但200臺的客戶端主機數量讓他非常恐懼。
他設計了個非常簡單的方法,如圖3-39所示,只要設定服務器排除掉重疊的IP地址段就可以了。
?
圖 3-39 50/50故障轉移方法
每臺服務器包覆蓋了整個網絡中所有IP地址的范圍,Server A 的作用域被配置成排除了192.168.100.1到192.168.100.125范圍以外的所有IP;而Server B的作用域被設置成負責后一半IP地址的范圍。
這種方法的優點為DHCP環境建立了某種程度的冗余,同時無需為客戶端保留額外的IP地址作用域。但是要將這種方法付諸于實踐之前,某些DHCP服務的限制還需要我們仔細斟酌。
從理論上講有某一臺服務器距離大多數客戶端較近,因此多數的客戶端被定向到這臺服務器,千分之一秒的差距使得另外一臺服務器無法得到負載均衡的功能。在理論上這將導致它的DHCP地址池很快就處于飽和狀態,之后,另外一臺DHCP服務器才開始接受客戶端請求。如果Server A 不能提供服務了,Server B 所能提供的IP地址范圍也不能夠完全處理200臺客戶端的請求。
注意這是在同一子網網段上的范例,我想這個網絡非常適用于100臺左右的網絡規模,這樣的話每臺服務器所能分配的地址空間是所需的1倍以上,而排除地址范圍后,就能夠實現Server A和Server B無縫配合了。
3.4.2 DHCP容錯80/20故障轉移
實現 DHCP 遠程故障轉移的另一種方式是在企業網絡中使用兩個 DHCP 服務器,使二者共享一個基于 80/20 規則的分隔作用域配置。
為了確保DHCP的可用性,往往在不同的網段均安裝一臺DHCP。各網段的DHCP遵循80/20原則,即:本地網段的80%地址由本地網段的DHCP負責,其余20%的地址由另一個網段的DHCP負責。具體實現的方法是將負責本地網段的DHCP上排除掉那20%的地址,另一個網段的DHCP上排除掉那80%的地址。
下面這個企業的網絡就采用了80/20的容錯機制,如圖3-40所示。
?
圖 3-40 80/20故障轉移方法
不過這樣的網絡設計也存在局限性。以北京建國門辦公網絡的DHCP服務器為例,如果它停機時間過長,它也許會耗盡北京大興工業園區DHCP服務器的客戶端租約,導致兩地的客戶端都不能續約。因此,作為負責80%的服務器應制定災難恢復計劃,將停機時間縮至最短。
提示:80/20規則是微軟所建議的分配比例,在實際應用時可以根據情況進行調整,比如70/30 的比例。另外,在一個子網中的兩個DHCP服務器上所建的DHCP作用域不能有地址交叉的現象。
3.4.3 DHCP容錯100/100故障轉移
在討論這個方法前,你必須要有足夠多的IP地址可供客戶端使用,通常需要超過實際客戶端數量的2倍或者更多。有人會問,這可能嗎?對于已經被總公司規劃好的網絡,僅僅有限的IP地址范圍可供分公司使用,這是不可能實現100/100的DHCP設計,但對于那些擁有自主權,或者沒有對整個網絡中的IP地址進行配置的網絡來說,使用專用的網絡配置(10.x.x.x)是可以實現這種理想化的目標的。
下面是一所工商管理學院的DHCP規劃案例。他們采用了最簡單的100/100故障轉移方法,包括了兩臺運行著DHCP的服務器,每臺服務器都為公司的同一個子網分配IP地址,但是,每臺服務器上的作用域包含有地址不同而容量相同的IP范圍,如圖3-41所示。
?
圖 3-41 80/20故障轉移方法
這兩臺服務器中的一臺服務器(Server A)中斷后,第二臺服務器(Server B)將會接管它的工作,對客戶端做出響應。這樣的話,客戶端的IP地址就將被分配到10.88.5.0-10.88.8.254的范圍了。這里唯一的一個缺點是所有在企業中的網關設備的網絡接口和路由條目,都需要擁有至少兩套方案中的IP管理方法。
這對于Windows系統管理員可以輕松了許多,但對網絡管理員來說這將是一件非常麻煩的事,只要他不罵你,就能夠實現這樣的完美結局。
3.4.4 DHCP中繼服務器規劃建議
在大型網絡上安裝中繼代理之前,需要考慮一些重要的設計問題。
當你有多個 DHCP 服務器時,Microsoft 建議你將 DHCP 服務器置于不同的子網上而不是將所有的服務器置于一個子網上,以獲得更強的容錯能力。服務器在其作用域中不應有公用的 IP 地址(每個服務器應有唯一的地址池)。
如果本地子網上的 DHCP 服務器關閉,請求將被轉發到遠程子網。如果該位置的 DHCP 服務器維護著請求子網的 IP 地址作用域,它將可以響應 DHCP 請求。如果遠程服務器沒有為請求子網定義作用域,那么即使它有其他作用域的可用地址,也不能提供 IP 地址。如果每個 DHCP 服務器有用于每個子網的地址池,則它能為其自己 DHCP 服務器脫機的遠程客戶端提供 IP 地址。
1.推薦的設計思路
為獲得最佳路由型 DHCP 網絡性能,建議采用圖3-42中繼代理實現方法。使用連接于兩個不同子網的兩臺 DHCP 服務器。在每個用于連接子網的路由器上運行的中繼代理有不同的延遲間隔(一個設置為 4 秒,另一個不使用延遲)。它通過隨機選擇的網絡路徑排除了不希望出現的 DHCP 數據包溢出危險。
?
圖3-42 最佳路由型 DHCP 網絡
2.不推薦的實現方法
不推薦下列中繼代理實現方法,如圖3-43所示。它與上例有相同數量的 DHCP 服務器和子網,但使用時的警告更少。DHCP 客戶端啟動時廣播的 DHCP 查找消息 (DHCPDISCOVER) 存在較大風險,它們在前往其他子網時可以隨意被轉發或復制。另外,中繼代理不使用任何延遲間隔,這將會增加中繼代理(路由器)復制任何客戶端廣播消息的可能性,并可能導致遠程子網擁塞。
?
圖 3-43 DHCPDISCOVER消息隨意轉發
3.4.5 待機作用域的方法
待機DHCP服務器就是安裝了一臺DHCP服務器,我們配置了作用域,但沒有啟用。這和前面的幾個例子有些不同,我們可以設置相同的作用域范圍,但備用的DHCP服務器通常都處于休眠狀態,直到生產網絡上的DHCP犧牲后才喚醒它。當出現問題的時候,只要激活睡眠狀態的作用域。可以使用網絡管理工具以及編成實現自動化的激活程序。
提示:有一定基礎的系統管理員應學習一些命令行工具,這些工具的效率非常高,比如使用netsh dhcp server [\\ServerName] SubCommand 命令就可以管理DHCP服務器,例如“Dhcp Server 192.168.1.20 Scope 192.168.29.0 set state 1” 可以激活待機DHCP服務器上的192.168.29.0 作用域。
3.4.6 真正的冗余是群集服務
DHCP的最后一種冗余設計就是部署一個群集服務器組(Clusters)來運行DHCP,和上面所有的規劃設計相比,這才是真正的冗余設備,不過也是最昂貴的(需要增加雙機共享存儲設備)的方法。
群集的優點之一就是運行在服務器群集上的應用程序和服務可以用虛擬服務器的形式出現在用戶和工作站面前。用戶和客戶端在連接到以群集化的虛擬服務器形式運行的應用程序或服務時,就如同連接到一臺物理性的服務器。
事實上,群集中的任何節點都可以接受這樣的虛擬服務器連接。用戶或客戶端不會知道虛擬服務器真正駐留在哪個節點上。一旦DHCP應用程序或服務器發生故障,群集服務就會將整個虛擬服務器資源組轉移到群集中的另一個節點上。在發生這樣的故障時,客戶端將會同該應用程序的會話中檢測到故障,并且試圖用與先前連接完全一致的方式進行重新連接。由于群集服務在恢復操作中可以簡單地將虛擬服務器的公開 IP 地址映射到群集中幸存的節點,因此客戶端的上述努力將可以獲得成功。客戶端會話不必知道相關的應用程序現在是否已實際駐留到了群集中的不同節點上就可以重建同該應用程序的連接。
動態主機配置協議(DHCP)服務算是群集服務中最基本的一個。DHCP 客戶端的 IP 地址租約信息保存在 DHCP 數據庫中。如果 DHCP 服務器資源發生故障,上述 DHCP 數據庫將可以被轉移到群集中可用的節點上,DHCP 數據庫的內容不會變更。詳細內容請看本書中關于Windows 群集服務配置的章節案例。
?????????有人說“DHCP不重要”?我再次反對這樣的說法!DHCP停止工作將會讓無法訪問網絡的用戶火冒三丈。因此在DHCP環境中建立冗余并在其中一臺犧牲的時候,另外一個服務器可以迅速的接過他手中的槍,這樣的網絡才有意義!
???????? 不幸的是,DHCP服務并沒有一種辦法來動態的與另外一個DHCP服務器協同工作以同步客戶端租約情況。我花費了很長時間收集“51CTO專家博客”的建議,對于DHCP冗余,他們提供了多種可供選擇的規劃方案,而每種選項的優缺點可能要你與公司的情況相對應。
3.4.1 DHCP容錯50/50故障轉移
DHCP容錯的50/50故障轉移方法將使用2臺DHCP服務器,每臺服務器在子網上處理同等數量的客戶端請求流量。每臺服務器采用了非常相似的作用域配置,但作用域的范圍不能重疊,以避免IP尋址沖突。
有一個偶然的機會,我的一位朋友參與了一個科研所的辦公網絡改造工程。該網絡擁有200臺以1921.68.100/24 定義的客戶端,原本網絡中只有一臺DHCP服務器,一次意外的硬件故障發生時,這臺服務器停止了服務。由于所有客戶端都采用自動獲取IP的方式,這次整個網絡炸了鍋,網絡管理員迅速手工輸入了幾臺重要客戶端主機的IP地址,但200臺的客戶端主機數量讓他非常恐懼。
他設計了個非常簡單的方法,如圖3-39所示,只要設定服務器排除掉重疊的IP地址段就可以了。
?
圖 3-39 50/50故障轉移方法
每臺服務器包覆蓋了整個網絡中所有IP地址的范圍,Server A 的作用域被配置成排除了192.168.100.1到192.168.100.125范圍以外的所有IP;而Server B的作用域被設置成負責后一半IP地址的范圍。
這種方法的優點為DHCP環境建立了某種程度的冗余,同時無需為客戶端保留額外的IP地址作用域。但是要將這種方法付諸于實踐之前,某些DHCP服務的限制還需要我們仔細斟酌。
從理論上講有某一臺服務器距離大多數客戶端較近,因此多數的客戶端被定向到這臺服務器,千分之一秒的差距使得另外一臺服務器無法得到負載均衡的功能。在理論上這將導致它的DHCP地址池很快就處于飽和狀態,之后,另外一臺DHCP服務器才開始接受客戶端請求。如果Server A 不能提供服務了,Server B 所能提供的IP地址范圍也不能夠完全處理200臺客戶端的請求。
注意這是在同一子網網段上的范例,我想這個網絡非常適用于100臺左右的網絡規模,這樣的話每臺服務器所能分配的地址空間是所需的1倍以上,而排除地址范圍后,就能夠實現Server A和Server B無縫配合了。
3.4.2 DHCP容錯80/20故障轉移
實現 DHCP 遠程故障轉移的另一種方式是在企業網絡中使用兩個 DHCP 服務器,使二者共享一個基于 80/20 規則的分隔作用域配置。
為了確保DHCP的可用性,往往在不同的網段均安裝一臺DHCP。各網段的DHCP遵循80/20原則,即:本地網段的80%地址由本地網段的DHCP負責,其余20%的地址由另一個網段的DHCP負責。具體實現的方法是將負責本地網段的DHCP上排除掉那20%的地址,另一個網段的DHCP上排除掉那80%的地址。
下面這個企業的網絡就采用了80/20的容錯機制,如圖3-40所示。
?
圖 3-40 80/20故障轉移方法
不過這樣的網絡設計也存在局限性。以北京建國門辦公網絡的DHCP服務器為例,如果它停機時間過長,它也許會耗盡北京大興工業園區DHCP服務器的客戶端租約,導致兩地的客戶端都不能續約。因此,作為負責80%的服務器應制定災難恢復計劃,將停機時間縮至最短。
提示:80/20規則是微軟所建議的分配比例,在實際應用時可以根據情況進行調整,比如70/30 的比例。另外,在一個子網中的兩個DHCP服務器上所建的DHCP作用域不能有地址交叉的現象。
3.4.3 DHCP容錯100/100故障轉移
在討論這個方法前,你必須要有足夠多的IP地址可供客戶端使用,通常需要超過實際客戶端數量的2倍或者更多。有人會問,這可能嗎?對于已經被總公司規劃好的網絡,僅僅有限的IP地址范圍可供分公司使用,這是不可能實現100/100的DHCP設計,但對于那些擁有自主權,或者沒有對整個網絡中的IP地址進行配置的網絡來說,使用專用的網絡配置(10.x.x.x)是可以實現這種理想化的目標的。
下面是一所工商管理學院的DHCP規劃案例。他們采用了最簡單的100/100故障轉移方法,包括了兩臺運行著DHCP的服務器,每臺服務器都為公司的同一個子網分配IP地址,但是,每臺服務器上的作用域包含有地址不同而容量相同的IP范圍,如圖3-41所示。
?
圖 3-41 80/20故障轉移方法
這兩臺服務器中的一臺服務器(Server A)中斷后,第二臺服務器(Server B)將會接管它的工作,對客戶端做出響應。這樣的話,客戶端的IP地址就將被分配到10.88.5.0-10.88.8.254的范圍了。這里唯一的一個缺點是所有在企業中的網關設備的網絡接口和路由條目,都需要擁有至少兩套方案中的IP管理方法。
這對于Windows系統管理員可以輕松了許多,但對網絡管理員來說這將是一件非常麻煩的事,只要他不罵你,就能夠實現這樣的完美結局。
3.4.4 DHCP中繼服務器規劃建議
在大型網絡上安裝中繼代理之前,需要考慮一些重要的設計問題。
當你有多個 DHCP 服務器時,Microsoft 建議你將 DHCP 服務器置于不同的子網上而不是將所有的服務器置于一個子網上,以獲得更強的容錯能力。服務器在其作用域中不應有公用的 IP 地址(每個服務器應有唯一的地址池)。
如果本地子網上的 DHCP 服務器關閉,請求將被轉發到遠程子網。如果該位置的 DHCP 服務器維護著請求子網的 IP 地址作用域,它將可以響應 DHCP 請求。如果遠程服務器沒有為請求子網定義作用域,那么即使它有其他作用域的可用地址,也不能提供 IP 地址。如果每個 DHCP 服務器有用于每個子網的地址池,則它能為其自己 DHCP 服務器脫機的遠程客戶端提供 IP 地址。
1.推薦的設計思路
為獲得最佳路由型 DHCP 網絡性能,建議采用圖3-42中繼代理實現方法。使用連接于兩個不同子網的兩臺 DHCP 服務器。在每個用于連接子網的路由器上運行的中繼代理有不同的延遲間隔(一個設置為 4 秒,另一個不使用延遲)。它通過隨機選擇的網絡路徑排除了不希望出現的 DHCP 數據包溢出危險。
?
圖3-42 最佳路由型 DHCP 網絡
2.不推薦的實現方法
不推薦下列中繼代理實現方法,如圖3-43所示。它與上例有相同數量的 DHCP 服務器和子網,但使用時的警告更少。DHCP 客戶端啟動時廣播的 DHCP 查找消息 (DHCPDISCOVER) 存在較大風險,它們在前往其他子網時可以隨意被轉發或復制。另外,中繼代理不使用任何延遲間隔,這將會增加中繼代理(路由器)復制任何客戶端廣播消息的可能性,并可能導致遠程子網擁塞。
?
圖 3-43 DHCPDISCOVER消息隨意轉發
3.4.5 待機作用域的方法
待機DHCP服務器就是安裝了一臺DHCP服務器,我們配置了作用域,但沒有啟用。這和前面的幾個例子有些不同,我們可以設置相同的作用域范圍,但備用的DHCP服務器通常都處于休眠狀態,直到生產網絡上的DHCP犧牲后才喚醒它。當出現問題的時候,只要激活睡眠狀態的作用域。可以使用網絡管理工具以及編成實現自動化的激活程序。
提示:有一定基礎的系統管理員應學習一些命令行工具,這些工具的效率非常高,比如使用netsh dhcp server [\\ServerName] SubCommand 命令就可以管理DHCP服務器,例如“Dhcp Server 192.168.1.20 Scope 192.168.29.0 set state 1” 可以激活待機DHCP服務器上的192.168.29.0 作用域。
3.4.6 真正的冗余是群集服務
DHCP的最后一種冗余設計就是部署一個群集服務器組(Clusters)來運行DHCP,和上面所有的規劃設計相比,這才是真正的冗余設備,不過也是最昂貴的(需要增加雙機共享存儲設備)的方法。
群集的優點之一就是運行在服務器群集上的應用程序和服務可以用虛擬服務器的形式出現在用戶和工作站面前。用戶和客戶端在連接到以群集化的虛擬服務器形式運行的應用程序或服務時,就如同連接到一臺物理性的服務器。
事實上,群集中的任何節點都可以接受這樣的虛擬服務器連接。用戶或客戶端不會知道虛擬服務器真正駐留在哪個節點上。一旦DHCP應用程序或服務器發生故障,群集服務就會將整個虛擬服務器資源組轉移到群集中的另一個節點上。在發生這樣的故障時,客戶端將會同該應用程序的會話中檢測到故障,并且試圖用與先前連接完全一致的方式進行重新連接。由于群集服務在恢復操作中可以簡單地將虛擬服務器的公開 IP 地址映射到群集中幸存的節點,因此客戶端的上述努力將可以獲得成功。客戶端會話不必知道相關的應用程序現在是否已實際駐留到了群集中的不同節點上就可以重建同該應用程序的連接。
動態主機配置協議(DHCP)服務算是群集服務中最基本的一個。DHCP 客戶端的 IP 地址租約信息保存在 DHCP 數據庫中。如果 DHCP 服務器資源發生故障,上述 DHCP 數據庫將可以被轉移到群集中可用的節點上,DHCP 數據庫的內容不會變更。詳細內容請看本書中關于Windows 群集服務配置的章節案例。
總結
以上是生活随笔為你收集整理的51CTO第2本书样章曝光:DHCP服务器规划与应用案例的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 对 Jquery 表单插件 Form.j
- 下一篇: 售前日记