SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

  • Home
  • 產品
    • SIOS DataKeeper for Windows
    • SIOS Protection Suite for Linux
  • 新闻与活动
  • 伺服器集群简单化
  • 成功案例
    • 台灣成功案例
  • 聯繫我們
  • English
  • 中文 (中国)
  • 中文 (台灣)
  • 한국어
  • Bahasa Indonesia
  • ไทย

了解虛擬化可用性選項

21 1 月, 2018 by Jason Aw Leave a Comment

什麼是虛擬化可用性選項?

Microsoft Windows Server 2008 R2和vSphere 4.0是最新發布的。 在考慮您的虛擬服務器及其上運行的應用程序的可用性時,我們來看看一些虛擬化可用性選項。

我也將藉此機會介紹一些啟用虛擬機可用性的功能。此外,我已將這些功能歸入其功能角色,以幫助突出其功能。

計劃停機

實時遷移和VMware的VMotion都是一種解決方案,允許管理員將虛擬機從一台物理服務器移到另一台物理服務器,而無需意識到停機時間。有一個關鍵的事情要記住。此舉必須是有計劃的事件,才能將虛擬機從一台服務器移到另一台服務器,而不會造成任何停機。計劃的事件是在實際切換發生之前,虛擬機的內存在服務器之間同步。微軟和VMware的解決方案都是如此。另請注意,這兩種技術都需要使用共享存儲來保存虛擬硬盤(VMDK和VHD文件),這限制了實時遷移和VMotion到局域網。這也意味著計劃存儲陣列的任何停機時間必須以不同的方式處理。需要注意的是,如果您想限制對虛擬機的影響。

意外停機

微軟的Windows服務器故障轉移群集和VMware的高可用性(HA)是在發生意外宕機時保護虛擬機的解決方案。兩種解決方案都很相似 他們監視虛擬機的可用性。如果發生故障,VM將移動到備用節點。然後,機器重新啟動以進行此恢復過程。在故障轉移之前沒有時間同步內存。

災難恢復

如果在完全丟失網站的情況下如何恢復我的虛擬機?好消息是虛擬化使這個過程變得更加簡單。虛擬機只是一個可以拾取並移動到另一台服務器的文件。到目前為止,VMware和微軟的可用性特性和功能非常相似。但是,這是微軟真正閃耀的地方。VMware提供Site Recovery Manager,這是一款很好的產品。但僅限於支持SRM認證的基於陣列的複制解決方案。另外,故障轉移和故障恢復過程並不是微不足道的,可以花費更多時間從災難恢復站點返回主要數據中心。它確實有一些很好的功能,如DR測試。 根據我使用Microsoft的災難恢復解決方案的經驗,在災難恢復方面他們有更好的解決方案。

微軟的Hyper-V DR解決方案

Microsoft Hyper-V DR解決方案是多站點群集配置中的Windows Server故障轉移群集(請參閱視頻演示)。在此配置中,性能和行為與局域集群相同,但它可以跨越數據中心。從本質上講,您實際上可以將您的虛擬機跨越數據中心,幾乎沒有可感知的停機時間。故障回復是相同的過程,只需點擊並點擊即可將虛擬機資源移回主數據中心。沒有內置的“DR測試”。儘管我認為最好在一兩分鐘內做一次實際的災難恢復測試,而不會發生意外的停機時間。

基於主機的複制供應商

我還喜歡WSFC多站點群集的另一件事是複制選項不僅包括基於陣列的複制供應商,還包括基於主機的複制供應商。這確實為您提供了各種價格範圍的複制解決方案,並且不需要升級現有的存儲基礎架構。

容錯

容錯功能基本上消除了在出現意外故障的情況下重新啟動虛擬機的需要。VMware在這方面具有優勢,因為它提供了VMware FT。還有一些其他的第三方硬件和軟件供應商也在這個領域發揮作用。實施FT系統時有很多限制和要求。如果您需要確保硬件組件故障導致零宕機時間與在標準HA配置中啟動VM時所需的一兩分鐘時間,這是一個選項。您可能希望確保現有服務器已滿載熱備用CPU,RAM,電源等。你有冗餘的路徑到網絡和存儲。否則,你可能會在糟糕的時候投入很多錢。容錯性對於防止硬件故障非常有用。如果您的應用程序或虛擬機的操作系統表現不佳,會發生什麼情況?這就是當你需要應用程序級集群時,如下所述。

應用可用性

到目前為止,我所討論的所有內容都只考慮了物理服務器和整個虛擬機的健康狀況。這一切都很好,但是,如果你的虛擬機藍屏?或者如果最新的SQL服務包破壞了你的應用程序?在這些情況下,這些解決方案都不會對你有一點幫助。對於那些最關鍵的應用程序,您確實必須在應用程序層進行集群。研究在虛擬機上操作系統內部與管理程序內部運行的群集解決方案。在微軟的世界裡,這意味著MSCS / WSFC或第三方集群解決方案。在虛擬機內進行群集時,您的存儲選項的範圍受到iSCSI目標或基於主機的複制解決方案的限制。 目前,VMware確實沒有解決這個問題的方法。它將遵循在虛擬機內運行的解決方案以進行應用程序層監視。

概要

隨著虛擬化的出現,這實際上不是您是否需要可用性的問題。還有更多關於什麼是虛擬化可用性選項將有助於滿足您的SLA和/或DR要求的問題。我希望這些信息可以幫助您了解可用的可用性選項。

轉載https://clusteringformeremortals.com/2009/08/14/making-sense-of-virtualization-availability-options-2/許可

閱讀我們的成功案例,了解SIOS如何為您提供幫助

Filed Under: 伺服器集群简单化

刪除最薄弱的鏈接,確保高可用性群集配置

21 1 月, 2018 by Jason Aw Leave a Comment

構建高可用性群集配置

構建高可用性群集配置時,您的應用程序可用性僅與其最薄弱的鏈接一樣好。這意味著,如果您購買了具有冗餘一切(CPU,風扇,電源,RAID,RAM等)和具有多路徑連接的超豪華SAN的優質服務器。與多個SAN交換機配合使用,並將您的應用程序與您喜歡的群集軟件集中在一起。 你可能有一個非常可靠的應用程序 – 對吧?嗯,不一定。服務器是否插入同一台UPS?它們是否在同一個網絡交換機上?它們是否由同一個交流單元冷卻?他們在同一棟樓裡嗎?您的SAN真的可靠嗎?其中任何一個問題都是高可用性群集配置中的單點故障。

尋找和刪除群集配置中最薄弱的環節

當然,你必須知道什麼時候“足夠好”是“足夠好”的。你的預算和你的SLA將有助於決定什麼是好的。但是,我擔心人們可能正在掠過的一個領域是存儲領域。隨著廉價或免費的iSCSI目標軟件解決方案的出現,我看到一些人建議你只是將一些iSCSI目標軟件放在備用服務器上,並且即時共享存儲。

請注意,我不是在談論內置故障轉移技術和/或其他可用性功能的OEM iSCSI解決方案;甚至是FalconStor等存儲虛擬化解決方案。我正在談論那些運行Windows Server 2008的服務器,他裝載了存儲並希望將其變成iSCSI目標。這在實驗室很棒。但如果你認真對待醫管局,你應該再考慮一下。即使是微軟也只提供他們的iSCSI目標軟件給合格的OEM製造商,他們在提供企業級存儲陣列上經驗豐富。

你實際上得到了什麼?

首先,這是Windows。 沒有一些經過強化的操作系統只能用於存儲。這將需要維護,安全更新,硬件修復等。它基本上與您要保護的應用程序服務器具有相同的可靠性。集群應用程序服務器是否有意義。然而,使用相同類別的服務器和操作系統來託管您的存儲?您基本上已將單點故障從應用程序服務器移開並將其移至存儲服務器。就我而言,這不是一個聰明的舉動。

某些企業級iSCSI目標軟件包括同步和/或異步複製軟件和快照功能。此功能肯定有助於恢復點目標(RPO)。雖然它不會幫助您恢復時間目標(RTO),除非故障轉移是自動且無縫到您的群集軟件。假設主iSCSI存儲陣列在半夜失敗。誰將在那裡激活複製副本?在您意識到存在問題之前,您可能已經停機了很長時間。再次,這可能是“足夠好”;你只需要知道你正在註冊的東西。這是您正在尋找的高可用性群集配置嗎?

SIOS DataKeeper

為提高iSCSI目標服務器的可靠性,您可以做的一件事是使用SteelEye DataKeeper Cluster Edition等複制產品來消除單點故障。讓我來說明一下。

典型的共享存儲配置
圖1 – 典型的共享存儲配置。如果iSCSI目標不可用,則所有節點都將脫機。

如果我們採用上面顯示的相同配置並使用SteelEye DataKeeper Cluster Edition添加熱備用iSCSI目標來執行複制和自動故障轉移,那麼您剛剛為iSCSI目標解決方案提供了全新的可用性級別。這個解決方案看起來非常像這樣。

DataKeeper Cluster Edition  - 高可用性群集配置
圖2 – 在這種情況下,DataKeeper Cluster Edition正在將主動節點上的iSCSI附加卷複製到被動節點上的iSCSI附加卷上,被動節點連接到完全不同的iSCSI目標服務器。

使用SteelEye DataKeeper Cluster Edition的解決方案與某些iSCSI目標供應商提供的複制解決方案的主要區別在於與WSFC的集成。要問你的iSCSI解決方案供應商的問題是這樣的…

如果我拔下活動的iSCSI目標服務器上的電源線,會發生什麼情況?

如果恢復過程是手動過程,則不是真正的HA解決方案。但是如果它是自動的並且與WSFC完全集成呢?然後,您可以獲得更高級別的可用性,並將iSCSI陣列作為單點故障排除在外。

與我們聊天也可以實現高可用性群集配置

經Clusteringformortals許可轉載。

Filed Under: Datakeeper, 伺服器集群简单化

Steeleye Datakeeper Cluster Edition榮獲Windows It Pro最佳高可用性/災難恢復獎

20 1 月, 2018 by Jason Aw Leave a Comment

我很高興地宣布,Windows IT Pro授予SteelEye DataKeeper Cluster Edition兩個類別的最佳高可用性和災難恢復產品;社區選擇金獎和編輯最佳銀獎。

SteelEye DataKeeper集群版 - 最佳高可用性災難恢復產品SteelEye DataKeeper集群版 - 最佳高可用性災難恢復產品

作為SteelEye DataKeeper團隊的一員,我感到非常自豪,我很欣賞在社區選擇獎中為我們投票的所有Windows IT Pro社區!

轉載https://clusteringformeremortals.com/2009/11/20/steeleye-datakeeper-cluster-edition-wins-windows-it-pro-best-high-availabilitydisaster-recovery-awards/的許可

Filed Under: Datakeeper, 伺服器集群简单化

如何在多站點群集中使用異步複製?數據不同步?

18 1 月, 2018 by Jason Aw Leave a Comment

我被問過這個問題不止幾次,所以我想我會在我的第一篇博客文章中回答這個問題。基本答案是肯定的,在多站點集群中使用異步複製時,可能會導致意外失敗的數據丟失。在一個理想的世界裡,每個公司都會有一個到他們災難恢復站點的暗光纖連接,並使用與他們的多站點集群同步複製,消除數據丟失的可能性。但是,現實情況是,在許多情況下,到災難恢復站點的廣域網連接有太多的延遲來支持同步複製。在這種情況下,異步複製是一個很好的選擇。選擇WSFC多站點群集使用的異步複製解決方案時,有多種選擇,包括來自EMC,IBM,HP等公司的基於陣列的解決方案。以及基於主機的解決方案,就像“SteelEye DataKeeper Cluster Edition”中那樣近乎親愛的解決方案。由於我最了解DataKeeper,所以我將解釋DataKeeper的這一切是如何工作的。當使用SteelEye DataKeeper和異步複製時,我們允許將一定數量的寫入存儲在異步隊列中。可以排隊的寫入次數由“高位標記”確定,“高位標記”是DataKeeper用來確定鏡像狀態從“鏡像”更改為“暫停”之前隊列中有多少數據的可調整值。。當輔助服務器和主服務器之間發生通信故障時,也會進入“暫停”狀態。處於暫停狀態時,多站點群集中的自動故障轉移將被禁用,從而限制意外故障中可能丟失的數據量。如果原始數據集被認為是“永久丟失”,則可以手動解鎖目標服務器上的剩餘數據,然後可以使集群節點投入使用。在“暫停”狀態下,DataKeeper允許異步隊列耗盡,直到達到“低水位”,此時鏡像將進入“重新同步”狀態,直到所有數據再次同步。此時,鏡像再次處於“鏡像”狀態,並且自動故障轉移再次啟用。只要你的廣域網鏈路沒有飽和或破壞,在這個異步隊列中的任何時候,你永遠不應該看到更多的寫入。如果出現意外的故障(請拔掉電源線),您將失去異步隊列中的任何寫入。當您需要使用多站點群集實現的卓越恢復點目標(RPO)和恢復時間目標(RTO)時,這是您所做的交易,但是您的WAN鏈路有太多的延遲來有效支持同步複製。如果您需要花時間通過Windows性能日誌和警報來監視DataKeeper異步隊列,那麼由於DataKeeper複製引擎的高效性,我認為您會驚喜地發現大部分時間異步隊列都是空的。即使在大量寫入的時候,異步隊列也很少會變得非常大,並且幾乎立即就會排空,所以在任何給定時間處於風險的數據量都是最小的。如果考慮到災難中的備選方案可能是從昨晚的備份中恢復,那麼使用異步複製可能導致意外故障的寫入次數極少!當然,也有一些情況下,即使丟失一個單一的寫是不可容忍的。在這種情況下,建議在高速,低延遲的LAN或WAN連接上使用SteelEye DataKeeper的同步複製選項。轉載https://clusteringformeremortals.com/2009/07/的許可

Filed Under: Datakeeper, 伺服器集群简单化

為什麼我應該把我的#AZURE集合轉換為管理磁盤今天!

9 8 月, 2017 by Jason Aw Leave a Comment

您可能已經聽說過最近的存儲中斷,影響了美國東部地區在3月16日的一些情況。 停電的根本原因分析在這裡張貼。

3月16日美國東部存儲中斷

客戶影響:在美國東部地區使用Storage的客戶的一小部分可能在單個存儲量表單元訪問其存儲帳戶時遇到錯誤和超時

您可能會問:“什麼是單個存儲量表單元”。 那麼,你可以把它看成一個單一的存儲集群,或是一個SAN,或者你想要考慮它。 我不認為Azure發布其精確的基礎架構,但是您可以假設幕後使用的是擴展文件服務器來進行後端存儲。

所以問題是,如何以最短的停機時間在這種停電中倖存下來?如果你進一步閱讀根本原因分析,你會遇到這個小塊。

在可用性集中使用託管磁盤的虛擬機將在此事件期間保持可用性。

什麼是託管磁盤你問?那麼就在2月8日,科里·桑德斯(Corey Sanders)宣布管理磁盤陣列。 您可以在這裡閱讀有關託管磁盤的所有信息。 https://azure.microsoft.com/en-us/services/managed-disks/

託管磁盤有助於中斷這一原因是通過利用可用性集合與託管磁盤組合,您可以確保可用性集中的每個實例都連接到不同的“存儲量表單元”。 因此,在這種特殊情況下,只有一個集群節點將失敗,剩下的節點才能接管工作負載。

在託管磁盤可用之前(任何部署在2/8/2016之前),沒有辦法確保連接到您的服務器的存儲位於不同的存儲容量單位上。 當然,您可以為每個實例使用不同的存儲帳戶,但實際上並不能保證這些存儲帳戶在不同的存儲量表單元上配置存儲。

因此,當可用性集確保您的實例駐留在不同的故障域和更新域中以確保實例本身的可用性時,附加到每個實例的額外存儲確實代表了單點故障。 雖然存儲本身俱有高度的靈活性,但可以使用三個數據副本和地理冗餘選項,在這種情況下,電源故障,整個存儲量表單元與連接的所有服務器一起下降。

這麼長的故事簡短…盡快遷移到託管磁盤,以幫助最小化停機時間

https://docs.microsoft.com/en-us/azure/virtual-machines/virtual-machines-windows-migrate-to-managed-disks

如果您真的想減少停機時間,那麼您應該考慮跨雲提供商的混合雲部署或云計算的一體機。

Filed Under: 伺服器集群简单化

  • « Previous Page
  • 1
  • …
  • 104
  • 105
  • 106
  • 107
  • Next Page »

最近的帖子

  • 保障建築物安全:維護和安防系統的高可用性
  • 透過模組化和抽象化設計高可用性
  • QA 和生產環境在高可用性中的關鍵作用
  • 高可用性思考的危險性:關掉它,再打開它——
  • SIOS 合作夥伴關係

最熱門的帖子

加入我們的郵件列表

Copyright © 2026 · Enterprise Pro Theme on Genesis Framework · WordPress · Log in