顯示具有 High Availability 標籤的文章。 顯示所有文章
顯示具有 High Availability 標籤的文章。 顯示所有文章

2014年9月22日 星期一

公司的LAB環境架設


這圖,是我在公司自己架設的實驗Lab,從無到有自己生出來的測試機,硬體、軟體、網路、應用程式跟運行。
間接證實了家用主機也能拿來做VMware底層的ESXi Server的架設,但是需要注意以下幾點事項:
1.      網卡有無支援
2.      記憶體空間是否足夠
3.      CPU運算與硬碟空間

第一點最為重要,如果網卡不支援,就需要找一張可以支援VMWare ESXi的網路卡,於是在多方評估過後我入手了一張近三千的網路卡,型號為Intel Gigabit Dual Port i350-T2 PCIe i350T2BLK,這張確定可以完整支援所有VMWare所提供的功能,包含可以跟Switch間做Teaming,關於ESXi是否有支援您的網卡,可以到VMWare官方網站查詢。

第二點,要同時執行多少Guest OSESXi上,只計算要同時開機的數量,每一台Windows Server 2008需要至少4GBRAM(Win 7也差不多是這個量),於是初步計算我需要至少執行4Guest OS,這樣得出需要16GBRAM,於是我需要添購兩條8GB速度夠快的記憶體,多方考量後,入手了KHX24C11T3K2/16X,金士頓16GB DDR3-2400桌上型電腦 8G*2支裝記憶體,這部分支出最多,超過五千。

第三點,事實上硬碟空間如果只是執行模擬,不需要太多的硬碟空間,重點是當你在執行Guest OS安裝時,記得將硬碟空間選為Thin Provisioning,這樣就能省下非常大的硬碟用量,當然,並不是要執行高速的資料存儲,所以不需要高轉速的硬碟或是SSD,如果要模擬大量資料匯入或是寫入硬碟,硬碟的IOPS(Input/Output Operations Per Second)就相對重要。關於CPU速度,以我目前的同時執行四個Guest OS來說,用I7 3770K來說,綽綽有餘,這點可以從vSphare Client上的摘要以及效能兩個主要頁籤上看得出來,大多數時間CPU用量不到兩成,而僅在同時開機顛峰期間可以到5成以上。

以上幾點印證了幾件事情,頂級家機的硬體不會比伺服器等級的差,只是少了HA跟容錯機制,如果硬碟方面要做到需要額外的RAID Card或是Storage,也要購買額外的網路卡,但是電源部分就無法用雙PowerHA,沒有可熱抽換(Hot Swap)的機制,也就是一定會有Downtime(停工時間)

*ESXi在還有Guest OS運作時,沒辦法進入維護模式,僅有在進入維護模式後,才能夠停機(關閉電源)。當然,ESXi底層相對穩定,幾乎沒有當機的情況。



2014年3月11日 星期二

VMWare 的進階功能說明描述


VMware HA (High Availability) 是各位 IT Manager 最喜愛的功能之一,原因是當 Cluster 內其中一部 ESX 伺服器發生故障,VMware HA 即時將所有 Virtual Machine 轉移到另外一部適合的 ESX 伺服器,然後重新啟動。

VMware vMotion 功能簡單來說就是將正在運行的 Virtual Machine 轉移到 Cluster 內其中一部 ESX 伺服器上,最好的例子就是當 ESX 伺服器需要作維護而停機,只要利用 vMotion 將所有 Virtual Machine 不停機地轉移,那就不會影響到公司運作。

VMware DRS (Distributed Resource Scheduler) 是一種在 ESX 伺服器高負荷環境下轉移適合 Virtual Machine 到 Cluster 內其中一部 ESX 伺服器,這個功能一定需要配合 vMotion 來使用。

以上資訊出自於http://www.hkitblog.com/部落客,文章內容與版權屬於該站站主所有,本人從該站引用,特此說明。


VMWare HA (High Availability) Operaion



上圖截自DELL官方網站,很清楚明白的闡述了叢集Cluster作完之後的狀態,硬體自有一套機制去控制哪台實體機能寫入DB,而當一台實體的Server掛點,會藉由健康監測機制去通報所有叢集區內的實體伺服器,而由他們去接手掛點Server的服務。


架構延展到虛擬化上面,例如上圖所示的Production Cluster,一定是成雙成對的實體機器(可能是兩台或是四台這樣),而這些實體機器可能透過各種不同的方式存取Database(iSCSI或是SAN架構),但是這些DB上面的資料肯定都是一致的。所以ESXi的安裝會橫跨在Cluster上面,但是VMWare實際資料會存在DB上,當任何一台實體伺服器掛點的時候,都不會影響現有服務運作,這就是HA(High Availability)

到這邊只能做到實體的HA,接下來可以談談虛擬的HA,也就是永不中斷的服務,例如網頁運作。對於一個不容許中斷服務的網站來說,我們需要Load Balance(負載平衡)的網路設備,例如Cisco ACE 4710,通常這種硬體設備很貴,用頻寬再算錢。但是它就能夠做到像是前端網址是www.most.gov.tw科技部首頁對映後台4台或更多的虛擬OS(Web Server),達到永不間斷的網頁服務,可能以輪循法或是負載偵測等等方式決定下一個連線的Session要連後面的哪一台Server,當任何虛擬OS掛點時,ACE會將他排除到服務名單中,可以自行設定檢測機制為何,當他服務恢復後,ACE會自動檢測後再將它排入服務輪循清單中。


所以這樣就能建置起一套從硬體到虛擬化完整的HA Solution,當然這些只是基礎中的基礎而已。

Database虛擬化就很難辦到了,因為I/O瓶頸速度跟VMWare並沒有人工智慧去判斷這台是DB須給予超高優先存取權跟較多的網路資源,所以MS-SQL Server裝在VMWare上是可行,但是並不實用。因此並沒有企業能夠做到100%的完全虛擬化,因為DB虛擬化的成本過高,除非實體伺服器全部使用SSD硬碟(提高實體I/O跟回應速度),還是有人這麼做,但是要價不斐。還有另外一種解決方案就是利用SSD作為Database的Cache,但是這就必須取決於第三方也就是SSD原廠的AP支援。

2014年3月10日 星期一

虛擬化的備份與還原策略


根據 How to follow the 3-2-1 backup rule with Veeam Backup & Replication本文,有以下三大原則,非常重要。

1. 同樣資料最好要有三份備份,這也是最低要求

2. 儲存媒介必須是兩種完全不同的媒介。根據此原則,你不能夠儲存磁帶兩次,或是擺在雲端兩次當作不同份的備份。

3. 至少保存一份資料在不同地理位置。因此,異地備份是非常重要的。

理想策略情況是:磁帶備份、異地備份、雲端備份同時存在,避免資料損失所造成的衝擊。
在成熟運轉的企業環境中,備份與HA(High Availability)同等重要,在災難還原演練當中,兩著都扮演著不可或缺的角色。

接下來是還原計畫,還原就相對單純的多,但是先有還原才有備份,必須先確定還原需要哪些資料確保還原成功,才開始估算要備份下多少資料。如果還原測試不能夠確實演練,備份將會流於形式上的運作,因為無法確定這項備份能夠被還原就是無效備份。

還原要點有以下各點:

1. 還原的資料的時程估算,這通常可以理解為歷史資料的平均,然後加上人為操作的時間去估計需耗掉多少時間。

2. 步驟先後順序。如果這是一個區域性的大災難,那我們必須要先起哪些服務,例如:從實體設備購置,到作業系統還原,資料復原計劃,還原原有服務的順序如何備執行,哪些可以同時間被執行,通常必須包含硬體跟軟體兩個大範圍。

3. 服務可以忍受被中斷的時間。當一間企業並不能忍受這樣的服務被中斷時,應該考慮HA機制,而不是更快的還原計畫,畢竟還原計畫再快也是需要人去執行,而不是全自動化。

根據以上資訊就能打造出一系列的備份還原SOP,而且是高可用與高可靠性的,當然,評估這些計畫往往幾落實花上更多的時間,希望以上的解釋會對企業MIS有所幫助。

2013年5月30日 星期四

常見的網路架構

*紅線代表光纖、黑線代表一般網路線、藍\紫線代表堆疊線或特殊線(也有可能是一般光纖或網路線),當然圖中省略了防火牆、負載平衡等設備,僅列出網路基礎建設的設備。

通常在竹科的公司為了產線網路都要求能做到7*24高可用性(High Availability, HA),都會要求在更新案或是建置案上,要求一個完善的Solution去解決任何硬體故障時候的切換,所以網路架構都會是一個相當固定的模式,例如上圖,網路架構通常大同小異,當然實際公司或組織的拓樸都會比這還來得複雜,有很多時候被受限在拉線長度(Cat 5e僅能拉100M)、傳輸距離(光纖物理特性)、設備功能上被迫調整網路架構而損失部分的線路容錯。
Core(核心層)網路,技術上除了Routing(路由)跟其他Layer 4服務外,HSRPVRRP所提供技術非常重要。

DistributionAccess Layer(或稱為Edge)這兩層上,關鍵技術是STP(Spanning Tree Protocol)相關協定(RSTPPVST…)VlanVTPTrunk、帶TagEtherchannel等。
安全性部分則是以ACL(Access Control List)Port Security為主。

網路高可用性(HA)通常包含幾個部分:任一裝置或結點(Device/Node)、任一連接埠或模組(Port/Module)、任一線路(Line)的損壞或故障,都必須在有限時間內以硬體內部機制自動回復原有網路服務。



因此每當任何符合HA的網路架構建置案完工後,通常會進行HA測試,包含任一層網路裝置的斷電與復電測試、層與層之間的拔線測試,以底層Client連外InternetPing來檢視連外服務是否會受到影響,Ping掉包數量多寡,耗時多久能回復正常網路運作作為驗收參考的重要資料,做不到的時候將無法驗收。


這張圖描繪了底層Switch使用雙線路連接Distribution的情況,這種情況較著重在效能運作上(每台底層Switch皆提供Redundant Uplink),但是所耗費成本較高(很多時候不切實際),而頂層設備仍是接近Mesh情況較為常見。
當然,任何的網路架構都會將Performance(效能)Cost(成本)Security(安全性)Convenience(方便性)幾個大方向列入重要考量,這些點無法同時兼顧只能視著User的需求進行調整,基於工程師立場只能給與User建議與可行的解決方案而不會涉入報價與成本,通常工程師追尋的是最適解答,而非最佳解答,因為這幾項因素都有互斥的因子存在,而在設計網路架構上,工程師通常還需要考慮到網路架構的彈性與擴張,如果一個客戶要做長久,彈性與擴張是必定要列入考量的點。如果有機會與User談網路架構的時候,務必釐清需求,很多時候會存在著資訊落差,一個專有名詞所代表的意義在各專業領域上會有所不同,很容易出現誤解(例如:Trunk這名詞在網路跟伺服器上就有明顯的不同)


上圖就是幾種下層常見網路拓樸方式,分別代表泛用單環、效能傾向的雙層架構與高成本雙環三種,可以思考一下效能與成本間的差異,以及如何被實作。

上圖代表伺服器連接網路設備的架構圖,通常會配合Teaming建置,可以進行Lab實測,之前有實測過幾種,還有幾種需要待測,例如:Switch Stacking後的ServerTeaming情況。有興趣的,仍可以實測一下幾種架構在運作上的差異性、容錯的差別,附帶一提,Cisco Nexus系列會有VPCs的連接方式。