SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

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

Archives for 6 月 2020

企業可用性:法院的教訓

29 6 月, 2020 by Jason Aw Leave a Comment

企業可用性:法院的教訓

企業可用性:法院的教訓

我愛籃球。我喜歡玩遊戲,觀看遊戲並仔細思考遊戲的大腦方面;思想和動機,策略和戰術。我想尋找能正常工作或失敗的小東西,屏幕設置太早或滾動太晚。我喜歡防守和輪換。我想知道教練的練習,演練,旅行等策略。  幾個月前我自然而然地離開了24/7全天候工作日,想像一下,我抽出一天時間去看籃球,更具體地說是我女兒在中學籃球練習。

在觀看的大約三分之一時間內,我無法控制自己。我吹口哨,“勸誘”那個年輕的女孩,惡作劇地著小跑到球場上,大喊:“快跑!忙!”她做到了,耳邊的隊友也做到了。  接下來的幾分鐘,戲劇和演習充滿了活力,清晰的切割,流暢的動作和動力。  但是,它並沒有持續。  取而代之的是,需要更多的哨聲,需要更多的舉動來移動和奔跑,努力發揮,大刀闊斧,下潛,專心,專注,學習和糾正。2個小時快結束時,我將最後一刻的注意力轉移到預言上,“練習的方式就是演奏的方式!”

我幾乎可以感覺到您傳達了AI的精神,而不是人工智能(AI),艾倫·艾弗森(AI)。  “我們在談論,練習。  實踐!”我認為這與可用性有關。  好吧,當我考慮女兒和隊友時,我對籃球的熱愛滿足了我對可用性的熱愛。怎麼樣?

籃球策略與可用性策略類似的三種方式:

  • 在籃球運動中,每個團隊都需要一個計劃,以確保企業可用性。
  • 在籃球運動中,每個團隊都需要練習該計劃,同上以確保可用性,災難恢復,尤其是計劃好的維護。
  • 在籃球比賽中,該計劃在火中受到考驗的情況下,其執行效果只會與實施該計劃時一樣好

企業可用性需要計劃 

您的可用性(特別是災難,計劃的維護和中斷恢復策略)僅與您創建的一樣好。簡而言之,您對中斷的計劃是什麼(請注意,雲故障,服務器崩潰,網絡飽和以及人為錯誤)。  您有書面計劃嗎?您是否已確定所有者和備份所有者?您是否知道您的體系結構和拓撲(什麼服務器做什麼,它位於什麼位置,它屬於哪個團隊,服務什麼功能,與它相關的業務優先級以及它需要什麼SLO / SLA)?誰是您的主要供應商,他們的召喚清單是什麼?您的檢查點,數據保護計劃和備份策略是什麼?您要驗證該計劃的測試計劃和驗證計劃是什麼?

企業可用性需求實踐 

一個好的計劃,檢查一下。現在練習。  實施災難恢復步驟和計劃外的停機策略是每個企業配置的必要組成部分。但是,不進行演練的策略並不是真正的策略。在這種情況下,這只是一種可能的提議方法。  它更像是一個建議,而不是實際的記錄計劃。第二步是練習。逐步了解您的計劃策略。排練維護時間。恢復備份和數據。驗證假設和失敗模式。

企業可用性需要測試 

一個計劃和一個演練,檢查。現在您擁有三個中的兩個,讓我回到女兒的團隊。  作為“非官方教練”,我的臨別詞如下:“練習的方式就是比賽的方式!”快進三天。比賽已經結束了。他們所參加的球隊在運動能力上不匹配,並且與去年一樣,當時該球隊的比賽在半場結束時規模過大。  但是今年,人員不足和規模較小的團隊顯然已經做好了更多準備。本來應該是輕鬆的勝利現在進入了接近並列的最後一分鐘。主隊,即對手,開始進行新聞報導。儘管如此,我女兒的球隊還是為這種命運的練習而無意中做出了準備。  隨之而來的不是很好。四次失誤的失誤,三分球命中兩次關鍵犯規,四分命中或零失誤,以及一系列挫敗感最終導致毀滅性的一分失誤。

我的最後一點是,您在實際中斷,災難或計劃內維護方面做得如何?您是否使用真實的數據,真實的客戶以及真正的緊迫感進行練習?您的高層管理人員多久簽到一次?相信我,在充滿壓力的時刻出現老闆會讓人做出奇怪而不明智的事情!您的沙盒和測試系統看起來像生產環境嗎?在過去的生活中,我曾經與一位客戶在產品和質量保證之間使用不同的硬件,存儲和Linux OS版本進行過合作。當他們進入應用程序更新的過程中,災難就來了。  您是否有用戶和數據以及測試期間運行的作業?實際的災難模擬呢?這是一項難以接受的工作,它會測試具有潛在破壞性後果的硬崩潰,從異地恢復,甚至更難於模擬同時發生的多點,多個系統故障,但這種做法往往不可行,往往會使2小時的計劃維護變成八小時的多團隊企業災難。  練習不足或實踐不佳是您的戰略和團隊取得驚人勝利,還是團隊,供應商,企業和客戶遭受慘敗和代價高昂的失敗之間的區別。

在籃球運動中,受到抨擊的計劃只能維持與計劃相同的狀態。  在實施恢復和災難計劃時,關鍵是要製定良好的計劃和驗證,但是出色的實踐才是王道。

請與SIOS的銷售代表聯繫,以了解我們的可用性專家和產品如何幫助您制定計劃,程序和實踐。

回訪有關您永遠不應避免進行模擬的測試的帖子。

—客戶體驗副總裁Cassius Rhue

文章轉載自SIOS

Filed Under: 伺服器集群简单化

循序漸進:Azure中的ISCSI目標服務器群集

13 6 月, 2020 by Jason Aw Leave a Comment

Azure中的分步ISCSI目標服務器群集

循序漸進:Azure中的ISCSI目標服務器群集

我最近幫助某人在Azure中構建了iSCSI目標服務器群集,並意識到我從未針對該特定配置編寫分步指南。因此,為了彌補這一點,如果您需要自己執行此操作,請按以下逐步說明進行操作。

先決條件

我假設您對Azure和Windows Server相當熟悉,所以我將為您省去一些細節。假設您至少已完成以下操作

  • 在不同的可用區中分別提供兩台服務器(SQL1,SQL2)(也可以使用可用性集,但是可用區具有更好的SLA)
  • 通過Azure門戶為其分配靜態IP地址
  • 將服務器加入現有域
  • 在兩個節點上均啟用了故障轉移群集功能和iSCSI Target服務器功能
  • 將三個Azure高級磁盤添加到每個節點。
    注意:這是可選的,最少需要一個磁盤。為了提高IOPS,我們將在存儲池中將三個Premium Azure磁盤條帶化,並創建一個簡單的(RAID 0)虛擬磁盤
  • SIOS DataKeeper將用於提供集群中使用的複制存儲。如果您需要DataKeeper,則可以在此處請求試用。

創建本地存儲池

再次,此步驟是完全可選的,但是為了提高IOPS,我們將三個Azure Premium磁盤分條到一個存儲池中。您可能會傾向於使用動態磁盤和跨區卷,但不要這樣做!如果使用動態磁盤,則會發現存在一些一般性的不兼容性,這將阻止您以後創建iSCSI目標。

不用擔心,如果您知道可能會遇到的陷阱(如下所述),那麼創建本地存儲池將非常簡單。官方文檔可以在這裡找到。

陷阱#1-儘管文檔說存儲池中使用的捲的最小大小為4 GB,但我發現無法識別P1高級磁盤(4GB)。因此,在我的實驗室中,我使用了16GB的P3高級磁盤。

陷阱2-您必須至少具有三個磁盤才能創建存儲池。

陷阱#3-在創建集群之前先創建存儲池。如果您在創建群集後嘗試執行此操作,那麼Microsoft會為您創建群集存儲池時,您將一團糟。我們將不會創建集群存儲池,因此在創建集群之前先創建存儲池,以免造成混亂。如果必須在創建集群後添加存儲池,則必須首先從集群中逐出該節點,然後再創建存儲池。

根據此處找到的文檔,以下是屏幕快照,它們表示在兩個群集節點中的每個節點上構建本地存儲池時應看到的屏幕截圖。在構建集群之前,請在兩台服務器上完成這些步驟。

循序漸進:Azure中的ISCSI目標服務器群集

您應該在兩台服務器上都看到原始池。

循序漸進:Azure中的ISCSI目標服務器群集

右鍵單擊並選擇“新建存儲池”。

循序漸進:Azure中的ISCSI目標服務器群集

循序漸進:Azure中的ISCSI目標服務器群集

循序漸進:Azure中的ISCSI目標服務器群集

循序漸進:Azure中的ISCSI目標服務器群集

關閉此嚮導後,選擇“創建虛擬磁盤”

循序漸進:Azure中的ISCSI目標服務器群集

循序漸進:Azure中的ISCSI目標服務器群集

循序漸進:Azure中的ISCSI目標服務器群集

請注意,如果您決定結合使用Standard,Premium和Ultra SSD,則可以創建存儲層

循序漸進:Azure中的ISCSI目標服務器群集

循序漸進:Azure中的ISCSI目標服務器群集

為了獲得最佳性能,請使用簡單的存儲佈局(RAID 0)。不必擔心可靠性,因為Azure託管磁盤在後端具有三重冗餘。需要簡單才能獲得最佳性能。

循序漸進:Azure中的ISCSI目標服務器群集

為了性能起見,請使用固定配置。無論如何,您已經為完整的Premium磁盤付費,因此無需全部使用。循序漸進:Azure中的ISCSI目標服務器群集

循序漸進:Azure中的ISCSI目標服務器群集

循序漸進:Azure中的ISCSI目標服務器群集

循序漸進:Azure中的ISCSI目標服務器群集

循序漸進:Azure中的ISCSI目標服務器群集

循序漸進:Azure中的ISCSI目標服務器群集

循序漸進:Azure中的ISCSI目標服務器群集

循序漸進:Azure中的ISCSI目標服務器群集

循序漸進:Azure中的ISCSI目標服務器群集

循序漸進:Azure中的ISCSI目標服務器群集

循序漸進:Azure中的ISCSI目標服務器群集

現在,您的第一個節點上將有一個45 GB X的驅動器。對第二個節點重複此整個過程。

創建您的集群

現在每個服務器都有自己的45 GB X驅動器,我們將創建基本集群。最好通過Powershell在Azure中創建群集,以便我們可以指定靜態IP地址。如果通過GUI進行操作,您很快就會意識到Azure為您的群集IP分配了一個必須清理的重複IP地址,所以不要這樣做!

這是用於創建新集群的示例Powershell代碼。

 New-Cluster-名稱mycluster -NoStorage -StaticAddress 10.0.0.100-節點sql1,sql2

輸出看起來像這樣。

PS C: Users  dave.DATAKEEPER>新建群集-名稱mycluster -NoStorage 
-StaticAddress 10.0.0.100-節點sql1,sql2
警告:在創建群集角色時存在問題 
可能會阻止它啟動。
有關更多信息,請查看下面的報告文件。
警告:報告文件位置:C: windows  cluster  Reports  Create Cluster 
2020.05.20上的嚮導mycluster 
在16.54.45.htm

名稱     
----     
集群

報告中的警告將告訴您沒有見證人。由於此群集中沒有共享存儲,因此您必須創建一個Cloud Witness或File Share Witness。我不會指導您完成該過程,因為這些鏈接上已對此進行了很好的記錄。

不要拖延這一步,現在就繼續創建見證人,然後再繼續下一步!

現在,您應該擁有一個基本的2節點群集,看起來像這樣。

循序漸進:Azure中的ISCSI目標服務器群集

為群集核心IP地址配置負載均衡器

Azure中的群集是唯一的,因為Azure虛擬網絡不支持免費的ARP。如果您不知道這意味著什麼,請不必擔心,您真正要知道的是無法直接訪問群集IP地址。相反,您必須使用Azure負載平衡器,它將客戶端連接重定向到活動群集節點。

為Azure中的群集配置負載均衡器有兩個步驟。第一步是創建負載均衡器。第二步是更新群集IP地址,以便它偵聽負載平衡器的運行狀況探測器,並使用255.255.255.255子網掩碼,從而可以避免IP地址與ILB衝突。

我們將首先為集群核心IP地址創建一個負載均衡器。稍後,我們將編輯負載均衡器,以解決在本文檔結尾處將創建的iSCSI群集資源IP地址。

循序漸進:Azure中的ISCSI目標服務器群集

循序漸進:Azure中的ISCSI目標服務器群集

請注意,我們使用的靜態IP地址與用於創建核心群集IP資源的地址相同。

循序漸進:Azure中的ISCSI目標服務器群集

創建負載均衡器後,您將如下所示編輯負載均衡器

循序漸進:Azure中的ISCSI目標服務器群集

將兩個群集節點添加到後端池

循序漸進:Azure中的ISCSI目標服務器群集

將兩個群集節點添加到後端池

循序漸進:Azure中的ISCSI目標服務器群集

添加健康狀況探針。在此示例中,我們使用59999作為端口。請記住該端口,下一步將需要它。

循序漸進:Azure中的ISCSI目標服務器群集

創建新的路線以重定向所有HA端口,請確保已啟用“浮動IP”。

第2步–編輯群集IP地址以與負載均衡器一起工作

如前所述,將負載均衡器配置為正常工作有兩個步驟。現在我們有了負載均衡器,我們必須在一個集群節點上運行Powershell腳本。以下是需要在群集節點之一上運行的示例腳本。

$ ClusterNetworkName =“集群網絡1” 
$ IPResourceName =“集群IP地址” 
$ ILBIP =“ 10.0.0.100” 
導入模塊故障轉移群集
Get-ClusterResource $ IPResourceName | Set-ClusterParameter 
-多個@ {地址= $ ILBIP; ProbePort = 59998; SubnetMask =“ 255.255.255.255”
; Network = $ ClusterNetworkName; EnableDhcp = 0} 

除了使所有變量都適合您的環境之外,上述腳本的重要之處還在於確保將ProbePort設置為您在負載均衡器設置中為此特定IP地址定義的端口。稍後您將看到我們將為使用另一個端口的iSCSI群集IP資源創建第二個健康狀況探針。另一個重要的事情是確保將子網設置為255.255.255.255。它可能看起來錯了,但這就是需要設置的內容。

運行它後,輸出應如下所示。

 PS C: Users  dave.DATAKEEPER> $ ClusterNetworkName =“集群網絡1” 
$ IPResourceName =“集群IP地址” 
$ ILBIP =“ 10.0.0.100” 
導入模塊故障轉移群集
Get-ClusterResource $ IPResourceName | Set-ClusterParameter 
-多個@ {地址= $ ILBIP; ProbePort = 59999; SubnetMask =“ 255.255.255.255”
; Network = $ ClusterNetworkName; EnableDhcp = 0}
警告:屬性已存儲,但並非所有更改都會生效 
直到群集IP地址脫機,然後再次聯機。

您將需要使核心群集IP資源脫機並使其重新聯機,然後它才能在負載均衡器中正常運行。

假設您在創建負載均衡器時做得正確,則兩台服務器上的服務器管理器都應將群集列為“聯機”,如下所示。

循序漸進:Azure中的ISCSI目標服務器群集

檢查兩個群集節點上的服務器管理器。您的群集在“可管理性”下應顯示為“在線”。

安裝DataKeeper

我不會在這裡完成所有步驟,但是基本上到此為止,您已經準備好在兩個集群節點上安裝SIOS DataKeeper。這是一個非常簡單的設置,只需運行設置並選擇所有默認值即可。如果您在使用DataKeeper時遇到任何問題,通常是兩件事之一。第一個問題是服務帳戶。您需要確保用於運行DataKeeper服務的帳戶位於每個節點上的Local Administrators組中。

第二個問題是關於防火牆的。儘管DataKeeper安裝將自動更新本地Windows防火牆,但是如果您的網絡已鎖定,則需要確保群集節點可以通過所需的DataKeeper端口相互通信。此外,您需要確保ILB健康狀況探針可以到達您的服務器。

一旦安裝了DataKeeper,就可以創建第一個DataKeeper作業了。對於要使用DataKeeper界面複製的每個卷,請完成以下步驟。

循序漸進:Azure中的ISCSI目標服務器群集

循序漸進:Azure中的ISCSI目標服務器群集

使用DataKeeper界面連接到兩個服務器

循序漸進:Azure中的ISCSI目標服務器群集

單擊創建新作業並為其命名

循序漸進:Azure中的ISCSI目標服務器群集

循序漸進:Azure中的ISCSI目標服務器群集

循序漸進:Azure中的ISCSI目標服務器群集

循序漸進:Azure中的ISCSI目標服務器群集

單擊“是”以在集群中註冊DataKeeper卷。

循序漸進:Azure中的ISCSI目標服務器群集

註冊該卷後,它將顯示在故障轉移群集管理器的“可用存儲”中

創建ISCSI目標服務器群集

在下一步中,我們將在集群中創建iSCSI目標服務器角色。在理想的情況下,我將擁有一個Powershell腳本來為您完成所有這些工作,但是為了節省時間,我現在僅向您展示如何通過GUI進行操作。如果您碰巧編寫了Powershell代碼,請隨時與我們其他人分享!

GUI方法存在一個問題。創建IP資源時,您將獲得一個重複的IP地址,這將導致您的群集資源在我們修復之前失敗。我還將逐步完成該過程。

循序漸進:Azure中的ISCSI目標服務器群集

循序漸進:Azure中的ISCSI目標服務器群集

循序漸進:Azure中的ISCSI目標服務器群集

循序漸進:Azure中的ISCSI目標服務器群集

循序漸進:Azure中的ISCSI目標服務器群集

循序漸進:Azure中的ISCSI目標服務器群集

循序漸進:Azure中的ISCSI目標服務器群集

轉到失敗的IP地址資源的屬性,然後選擇靜態IP,然後選擇您的網絡上未使用的IP地址。請記住該地址,我們將在下一步中更新負載均衡器時使用它。

現在,您應該可以使iSCSI群集資源聯機。

循序漸進:Azure中的ISCSI目標服務器群集

更新ISCSI目標服務器群集資源的負載均衡器

如前所述,客戶端無法直接連接到我們剛剛為iSCSI目標服務器群集創建的群集IP地址(10.0.0.110)。我們將必須更新我們之前創建的負載均衡器,如下所示。

循序漸進:Azure中的ISCSI目標服務器群集

首先添加一個新的前端IP地址,該前端IP地址使用與iSCSI Target群集IP資源使用的IP地址相同的地址。

循序漸進:Azure中的ISCSI目標服務器群集

在另一個端口上添加另一個健康狀況探針。記住這個端口號,我們將在接下來運行的powershell腳本中再次使用它

循序漸進:Azure中的ISCSI目標服務器群集

我們再添加一個負載平衡規則。確保將“前端IP地址”和“運行狀況”探針更改為使用我們剛創建的探針。還要確保啟用直接服務器返回。

允許負載平衡器工作的最後一步是在一個群集節點上運行以下Powershell腳本。確保使用新的Healthprobe端口,IP地址和IP資源名稱。

 $ ClusterNetworkName =“集群網絡1” 
$ IPResourceName =“ IP地址10.0.0.0” 
$ ILBIP =“ 10.0.0.110” 
導入模塊故障轉移群集
Get-ClusterResource $ IPResourceName | Set-ClusterParameter 
-多個@ {地址= $ ILBIP; ProbePort = 59998; SubnetMask =“ 255.255.255.255”
; Network = $ ClusterNetworkName; EnableDhcp = 0} 

您的輸出應如下所示。

 PS C: Users  dave.DATAKEEPER> $ ClusterNetworkName =“集群網絡1” 
$ IPResourceName =“ IP地址10.0.0.0” 
$ ILBIP =“ 10.0.0.110” 
導入模塊故障轉移群集
Get-ClusterResource $ IPResourceName | Set-ClusterParameter 
-多個@ {地址= $ ILBIP; ProbePort = 59998; SubnetMask =“ 255.255.255.255”
; Network = $ ClusterNetworkName; EnableDhcp = 0}
警告:屬性已存儲,但並非所有更改都會生效 
直到IP地址10.0.0.0脫機,然後再次聯機。

確保使資源脫機和聯機以使設置生效。

創建您的群集ISCSI目標

在開始之前,最好檢查一下以確保兩台服務器上的服務器管理器都能看到兩個群集節點以及兩個群集名稱資源,並且在可管理性下它們都顯示為“聯機”,如下所示。

循序漸進:Azure中的ISCSI目標服務器群集

如果任一服務器在查詢這些群集名稱中的任何一個時出現問題,則後續步驟將失敗。如果有問題,我將仔細檢查創建負載平衡器和運行的Powershell腳本所採取的所有步驟。

現在,我們準備創建我們的第一個群集iSCSI目標。從任一群集節點中,按照以下說明的步驟進行操作,以作為有關如何創建iSCSI目標的示例。

循序漸進:Azure中的ISCSI目標服務器群集

循序漸進:Azure中的ISCSI目標服務器群集

循序漸進:Azure中的ISCSI目標服務器群集

循序漸進:Azure中的ISCSI目標服務器群集

循序漸進:Azure中的ISCSI目標服務器群集

循序漸進:Azure中的ISCSI目標服務器群集

循序漸進:Azure中的ISCSI目標服務器群集

當然,將其分配給將要連接到該iSSI目標的服務器。

循序漸進:Azure中的ISCSI目標服務器群集

循序漸進:Azure中的ISCSI目標服務器群集

循序漸進:Azure中的ISCSI目標服務器群集

循序漸進:Azure中的ISCSI目標服務器群集

有了它,您現在在Azure中就可以使用功能正常的iSCSI目標服務器。

如果您對此進行構建,請發表評論,我知道您打算如何使用它!

經群集的凡有凡人許可複制的文章

Filed Under: 伺服器集群简单化

解決方案簡介:適用於混合雲環境的無SAN群集

9 6 月, 2020 by Jason Aw Leave a Comment

適用於混合雲環境的無SAN群集

解決方案簡介:適用於混合雲環境的無SAN群集

SIOS SANless集群是一種簡便,經濟高效的方法,可以為基於物理服務器的集群環境添加災難保護,而無需額外的數據中心或災難恢復站點的成本和復雜性。將雲中的SIOS SANless群集節點添加到基於物理服務器的群集環境中,以便為關鍵業務應用程序提供高效,實時,塊級複製和災難保護。SIOS軟件支持跨地理位置和雲可用區域或區域的應用程序實例故障轉移,以提供站點範圍,本地和區域災難保護。SIOS SANless軟件使您可以使用物理,虛擬或云系統可用的本地存儲來構建集群。SIOS軟件使本地存儲保持同步,以實現高可用性保護,而無需共享存儲。

配置靈活性

無論您是要保護物理服務器,組織內的私有云,公共雲還是混合雲中的應用程序,SIOS SANless軟件都可以讓您靈活地選擇構建完全自動化的,以應用程序為中心的集群和復制解決方案。行業標準的硬件,複製架構和部署(主動/主動,主動/被動)。

適用於混合雲環境的無SAN群集
SIOS SANless集群跨越各種環境,可讓您以高可用性和災難恢復來保護數據,而無需花費遠程災難恢復站點的成本和復雜性。

SIOS軟件使您可以在自己選擇的配置之間進行複制–在SAN和SANless環境之間以及物理,虛擬和雲配置的任意組合之間進行複制。沒有供應商鎖定。在源和目的地不需要相同的硬件。

易於使用。容易擁有

您可以使用我們直觀的界面構建SIOS SANless集群並在幾分鐘內對其進行配置。SIOS還使對群集的監視和管理變得容易。用戶友好的管理控制台使您可以一目了然地監視受保護服務器,通信路徑,資源和應用程序的狀態。

主要好處

防災

•為關鍵業務應用程序提供簡單,經濟高效的高可用性和災難保護

靈活性

•混合物理服務器和雲環境以實現最高效率。

使用方便

•直觀的控制台,可輕鬆進行持續的監視和管理。

下載有關混合雲環境的SANless群集的解決方案簡介

Filed Under: 伺服器集群简单化

解決方案簡介:針對虛擬服務器環境的SANless群集解決方

9 6 月, 2020 by Jason Aw Leave a Comment

虛擬服務器環境的SANless群集解決方案

解決方案簡介:針對虛擬服務器環境的SANless群集解決方案

SIOS SANless軟件可讓您在虛擬化環境中構建集群,而無需共享存儲。您可以使用虛擬機管理程序提供的任何本地存儲類型。SIOS軟件使用有效的塊級複製來保持本地存儲同步,從而使群集中的備用服務器在故障轉移後可以訪問最新數據,從而繼續運行。

集群虛擬機

SIOS SANless軟件使您可以使用位於任何虛擬機管理程序(VMware,Xen,Microsoft Hyper-V等)之上的虛擬機創建集群。它使用實時復制將主VM上的存儲與位於同一數據中心,災難恢復站點或兩者中的備用VM上的存儲同步。萬一發生災難,備用VM可以立即投入使用,從而消除了從備份介質還原所需的時間。您只需直接在DR站點中訪問複製的VM。

支持實時遷移的Hyper-V主機群集

在Microsoft Hyper-V環境中,SIOS SANless軟件使您可以在虛擬機管理程序級別對整個Hyper-V主機進行群集,以實現完整的VM可移植性和故障轉移保護。通過在另一台Hyper-V主機上保持正在運行的VM的實時副本同步,SIOS軟件使您可以輕鬆地將VM從一台Hyper-V主機故障轉移或實時遷移到另一台Hyper-V主機。您具有完全的可移植性,可以將主機上的單個VM或所有VM移動到群集中的另一個Hyper-V主機。

使用虛擬服務器(A)構建SIOS SANless集群。在Microsoft Hyper-V環境(B)中,可以在虛擬機級別使用SIOS SANless群集,以實現輕鬆的實時遷移和完整的服務器可移植性。

輕鬆進行災難恢復測試

SIOS軟件還允許您還原複製的VM,以執行災難恢復測試,而不會中斷生產站點。測試完成後,SIOS軟件將消除測試過程中在目標服務器上所做的更改,並從停止的位置恢復複製。

下載有關針對虛擬服務器環境的SANless群集解決方案的解決方案簡介

Filed Under: 伺服器集群简单化

最近的帖子

  • 在 Nutanix 環境中選擇高可用性解決方案的 10 個注意事項
  • 我的伺服器是一次性的嗎?高可用性軟體如何適應雲端最佳實踐
  • 災難頻傳世界的資料復原策略
  • DataKeeper 與棒球:災難復原的策略性舉措
  • SQL Server 停機風險預算

最熱門的帖子

加入我們的郵件列表

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