SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

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

保護系統免於停機

1 5 月, 2022 by Jason Aw Leave a Comment

保護系統免於停機

在當今的業務環境中,組織依賴於應用程序、數據庫和 ERP 系統,例如 SAP、SQL Server、Oracle 等。 這些應用程序統一併簡化了您最關鍵的業務運營。 當他們失敗時,他們花費的不僅僅是金錢。 保護這些複雜的系統免於停機至關重要。

經驗證的高可用性和災難恢復

SIOS 在以下領域擁有 20 多年的經驗高可用性和災難恢復.SIOS 知道沒有一種萬能的解決方案。 當今的數據系統是本地、公共雲、混合雲和多雲環境的組合。 應用程序本身可以創造更多的複雜性。 但是配置開源集群軟件可能很費時費力,而且容易出現人為錯誤。

SIOS 擁有為關鍵應用程序提供高可用性和災難恢復的解決方案。 這些解決方案是根據我們在不同行業和用例中的實際經驗開發的。 我們的產品包括適用於 Windows 的 SIOS DataKeeper 集群版和適用於 Linux 的 SIOS LifeKeeper或窗戶。 這些強大的應用程序提供故障轉移保護。 LifeKeeper 隨附的應用程序恢復工具包通過自動配置和驗證輸入來加快應用程序配置時間。

本地、雲端或混合環境中的系統保護

SIOS 為關鍵業務應用程序提供所需的保護,並降低管理它們的複雜性,無論是在本地、雲中還是在混合雲環境中。 在下面的視頻中了解更多關於我們的信息或聯繫我們了解有關業務關鍵應用程序的高可用性和災難恢復的更多信息。

經授權轉載西歐

Filed Under: 伺服器集群简单化

如何使用 WSFC 在雲中實現高可用性

29 4 月, 2022 by Jason Aw Leave a Comment

如何使用 WSFC 在雲中實現高可用性

圖 1:在 Azure 中實現高可用性的故障轉移群集

Microsoft Windows Server 包括 Windows Server 故障轉移群集 (WSFC) 軟件,以確保關鍵應用程序的可用性。 在本地環境中,集群中的主節點和備用節點連接到同一個共享存儲。 但是,此基礎架構不能直接帶到雲端。 跨主系統和備用系統的共享存儲在 WSFC 中必不可少,但共享存儲不能與 AWS、Azure 或 Google Cloud 中的 IaaS(基礎設施即服務)等公共雲服務一起使用。

地理分離的共享存儲對於 WSFC在雲中不可用

在將本地應用程序遷移到雲端時,公司更願意將其整個基礎架構(包括 WSFC)遷移到雲端,而無需更改本地操作流程。 這使他們能夠通過在雲中應用相同的 WSFC 技能和專有技術來最大程度地減少中斷。

圖 2:AWS EC2 中的故障轉移集群。 集群節點位於地理上分離的可用區中,以提供 DR 保護。

組成集群的服務器分為主節點(應用程序運行的地方)和備用節點。 WSFC 軟件監控應用程序和服務器節點以確保它們正常運行。 如果 WSFC 檢測到主節點出現問題,它會在稱為“故障轉移”的過程中將應用程序的操作切換到備用節點。

在 WSFC 環境中,主服務器和備用服務器連接到共享存儲——通常稱為 SAN(存儲區域網絡)或 iSCSI-SAN 存儲的存儲。

要將操作從主服務器故障轉移到備用服務器,必須切換網絡鏈接,以便備用服務器可以讀取和寫入通常讀取和寫入主服務器的 SAN。 這樣,可以在短時間內重新啟動服務,讓備用服務器訪問與主節點相同的數據並滿足低恢復點目標(RPO)。

查看相關內容:災難恢復基礎.

但是,將 WSFC 遷移到雲時,沒有可用的 SAN。 例如,您不能將 Amazon Web Services (AWS) 和 Microsoft Azure 鏈接到多個節點(服務器)以用作共享存儲。 這同樣適用於其他雲服務的 IaaS。

可以在沒有共享存儲的情況下基於 WSFC 構建 HA 集群配置,但需要非常高級的技能,例如創建自己的程序來恢復備用節點上的數據。 操作複雜,事件發生時不易驗證。

數據複製軟件解決問題

要解決此問題,您可以安裝數據複製專用於 HA 集群的軟件 – 例如 SIOS DataKeeper Cluster Edition – 並在本地服務器之間同步存儲。 使用基於主機的塊級複製實時同步主節點和備用節點本地磁盤上的數據。 使用這種方法,您不需要共享存儲。 相反,您可以使用熟悉的 WSFC 構建 HA 集群配置,而不會中斷已建立的流程。

使用 DataKeeper,同步節點在 WSFC 管理屏幕(故障轉移集群管理)中顯示為 SAN。 如果您的運營經理使用過 WSFC,那麼他們幾乎不需要使用這種方法進行培訓。

雲中的高可用性超越了本地 HA使用 SIOS DataKeeper 和 WSFC

DataKeeper 集群版是與 Windows Server 故障轉移群集 (WSFC) 無縫集成的軟件插件,可添加性能優化的基於主機的同步或異步複製。 萬一 HA 集群發生故障,WSFC 將協調操作故障轉移到備用節點並訪問共享存儲,就像它是共享存儲一樣。 這種簡單的機制可以在不改變現有系統操作的情況下遷移到 AWS。

在不影響熟悉的 WSFC 操作的情況下,可以使用相當於或優於本地部署的 DataKeeper 來保證雲中的高可用性高可用性. 這種集群配置的優點是非常簡單,可以輕鬆應用於任何云環境。

與 WSFC 無縫集成

SIOS DataKeeper Cluster Edition 通過提供性能優化的、基於主機的數據複製機制與 Windows Server Failover Clustering (WSFC) 無縫集成並進行了擴展。 在 WSFC 管理軟件集群的同時,SIOS 執行數據複製以在共享存儲集群不可能或不切實際的情況下(例如在雲、虛擬和高性能存儲環境中)實現災難保護並確保零數據丟失。

經授權轉載西歐

Filed Under: 伺服器集群简单化

部署仲裁/見證的最佳方式

26 4 月, 2022 by Jason Aw Leave a Comment

部署仲裁/見證的最佳方式

部署仲裁/見證的最佳方式

在最近的一次會議上,一位客戶提出了一個關於高可用性 (HA) 和仲裁/見證可行性需求的問題。 他們的問題是,“部署法定人數/見證人的最佳方式是什麼?”他們的問題的答案很簡單,沒有單一的最佳方式來部署仲裁。為了理解為什麼,讓我們從定義三個關鍵的東西開始:什麼是見證資源、仲裁資源和裂腦場景。

什麼是裂腦?

在正常的集群環境中,受保護的應用程序在集群的主節點上運行。如果該主節點的應用程序發生故障,集群軟件會將應用程序操作移動到輔助節點或遠程節點,該節點承擔主節點的角色。 在任何給定時間,只有一個主節點。

裂腦是指集群成員之間無法相互通信,但處於運行和可操作狀態,隨後同時擁有公共資源的情況。 實際上,您有兩個公交車司機在爭奪方向盤。裂腦,由於其破壞性,可能導致數據丟失或數據損壞,最好通過使用圍欄、仲裁、見證或集群仲裁的仲裁/見證功能來避免。

在大多數集群管理器中,在以下情況下會維持仲裁:

  1. 所有服務器都能夠看到所有集群對等方和見證服務器的相同狀態
  2. 所有服務器都能夠看到所有集群對等方的相同狀態,但不是見證服務器
  3. 所有服務器都可以看到見證資源,儘管彼此看不到,並避免出現腦裂情況

在大多數集群管理器中,仲裁會在以下情況下丟失:

  1. 服務器無法看到所有集群對等點和見證服務器
  2. 服務器無法看到大多數集群對等方,即使它們可以看到見證服務器
  3. 服務器無法訪問或維持對仲裁資源的訪問以成功仲裁仲裁成員資格和資源訪問

什麼是見證資源(或服務器)?

見證資源是服務器、網絡端點或設備,用於在集群具有偶數個成員時實現和維護仲裁。具有奇數成員的集群,使用集群多數,不需要使用見證資源作為集群服務器的所有成員來仲裁多數成員資格。

什麼是仲裁和仲裁資源?

仲裁資源是一種資源(設備、系統、塊存儲、文件存儲、文件共享等),用作仲裁集群狀態和成員資格的手段。在某些集群管理器中,仲裁是集群內的一種資源,它幫助或需要任何集群狀態和集群成員資格決策。在其他集群管理器中,quorum 起到了決勝局的作用,以避免腦裂。

部署仲裁的不止一種方法

鑑於仲裁的關鍵性質,HA 架構必須正確部署仲裁/見證資源,並且幸運(或不幸)沒有單一的,部署仲裁的最佳方式。有幾個因素可能會影響您的見證和仲裁資源的行為方式。這些因素包括:

1. 您的部署是本地、雲還是混合

在存在額外存儲設備(例如光纖通道存儲、電源控制設備或連接或傳統 stonith 設備)的本地數據中心中部署將為客戶提供可能不駐留在雲中的仲裁和見證功能的額外選項。同樣,雲和混合環境在可以部署的內容以及正在部署哪些用例仲裁以防止這些方面存在差異。 此外,延遲要求和差異可能會限制可用於仲裁/見證配置的設備和資源類型。  

2. 你的恢復目標

在設計和構建仲裁和見證資源時,恢復目標也很重要。在示例兩節點集群(節點 A 和節點 B)中,當節點 A 失去與節點 B 的連接時,恢復的最高優先級是什麼。 如果見證/仲裁資源與節點 A 在同一網絡中,這可能導致節點 A 保持在線,但與客戶端斷開,而節點 B 無法評估仲裁和接管。同樣,如果仲裁設備僅存在於具有節點 B 的區域、數據中心或網絡中,則丟失可能導致資源故障轉移到已失效的網絡或中心或遠離功能和操作的主節點。

3. 基礎架構中可用數據中心(或區域)的冗餘

數據中心或區域的冗餘也是具有仲裁/見證的 HA 拓撲中的一個重要因素。 如果您的數據中心只有兩個級別的冗餘,您必須了解將仲裁/見證節點放置在與主集群節點或備用集群節點相同的數據中心之間的權衡。 如果數據中心有兩個以上的冗餘層,例如第三個可用區或訪問第二個區域,此選項將為集群提供更高級別的冗餘。

4. 容災要求

了解您真正的災難恢復需求也是您設計中的一個主要因素。 如果您的集群管理器軟件需要訪問仲裁/見證以便從整個數據中心中斷(或區域故障)中恢復,那麼您需要了解這對您的設計的影響。許多高可用性軟件包都有適用於這種情況的工具或方法,但如果您的軟件沒有,您的仲裁/見證人的設計和放置可能需要適應這一現實。

5. 集群內的成員數量及其位置

當集群包含奇數個節點時,通常不需要額外的仲裁/見證服務器。但是,如果在一個集群中只使用兩個節點或部署一個並不總是可用的 DR 節點可能會改變您的架構。作為客戶體驗副總裁,我曾與部署了三個節點架構的客戶合作,但為了節省成本,他們會自動定期關閉第三台服務器。

6.操作系統和集群管理器

關於仲裁/見證的最後一個因素是集群管理器和操作系統。在仲裁/見證的部署或仲裁狀態的仲裁方面,並非所有的 HA 軟件和集群管理器都是平等的。一些集群軟件需要共享磁盤進行仲裁,其他更靈活地允許共享(NFS、SMB、EFS、Azure 文件和 S3)。了解您的集群管理器需要什麼,以及它在仲裁方面支持的模式(簡單多數、見證、文件共享等)不僅會影響您部署的內容,還會影響您的部署方式。

部署仲裁/見證服務器的唯一最佳方法是了解供應商對仲裁/見證的定義及其可用選項,了解您的要求,考慮數據中心(或云環境)提供的限製或機會並構建解決方案為您的關鍵系統提供最高級別的保護,防止出現裂腦、錯誤故障轉移和停機。

-Cassius Rhue,客戶體驗副總裁

轉載自西歐

Filed Under: 伺服器集群简单化

使用 SIOS DataKeeper for Windows 測量和提高 GCP 上的寫入吞吐量性能

21 4 月, 2022 by Jason Aw Leave a Comment

使用 SIOS DataKeeper for Windows 測量和提高 GCP 上的寫入吞吐量性能

背景

這篇文章用於記錄我在 GCP 中關於將性能寫入複製到 GCP 的磁盤的發現。 但首先,一些背景信息。 一位客戶表示擔心,在同一區域的 Google 區域之間使用同步鏡像進行測試時,DataKeeper 會為其寫入性能增加大量開銷。 他們執行的原始測試是使用 C 驅動器上的位圖文件,這是一個持久的 SSD。 在這種配置中,他們只推動了大約 70 MBps。 他們嘗試將位圖重新定位到一個極端的 GCP 磁盤,但性能並沒有提高。

將位圖移動到本地 SSD

我建議他們將位圖移動到本地 SSD,但他們猶豫不決,因為他們認為他們用於位圖的極端磁盤的延遲和吞吐量與本地 SSD 一樣好或更好,因此他們懷疑它是否會不同之處。 此外,添加本地 SSD 並非易事,因為它只能在最初配置 VM 時添加。

選擇實例類型

當我著手完成我的任務時,我發現的第一件事是並非所有實例類型都支持本地 SSD。 例如,E2-Standard-8 不支持本地 SSD。 在我的第一個測試中,我選擇了一種 C2-Standard-8 實例類型,它被認為是“計算優化的”。 我連接了一個 500 GB 的持久 SSD 並開始運行一些寫入性能測試,很快發現我只能讓磁盤以大約 140MBps 的速度寫入,而不是最大速度 240MBps。 客戶確認他們看到了同樣的東西。 這很令人困惑,但我們決定繼續嘗試不同的實例類型。

我們選擇的第二種實例類型是 N2-Standard-8。 使用這種實例類型,我們能夠在不復制磁盤時將磁盤推到其最大吞吐速度 240 MBps。 我將位圖移動到我已配置的本地 SSD 並在同步鏡像(DataKeeper v8.8.2)上重複相同的測試,並得到如下所示的結果。

結果

Diskspd測試參數diskspd.exe -c96G -d10 -r -w100 -t8 -o3 -b64K -Sh -LD:data.dat diskspd.exe -c96G -d10 -r -w100 -t8 -o3 -b8K -Sh -LD:data .dat diskspd.exe -c96G -d10 -r -w100 -t8 -o3 -b4K -Sh -LD:data.dat

MBps

數據

寫入大小 MB/s MBps 開銷百分比
64k-鏡子 240.01 0.00%
64k-無鏡 240.02
8k-鏡子 58.87 39.18%
8k-無鏡 96.8
4k-鏡子 29.34 21.84%
4k-無鏡 37.54

 

寫入大小 平均緯度 平均開銷
64k-鏡子 6.247 -0.02%
64k-無鏡 6.248
8k-鏡子 3.183 39.21%
8k-無鏡 1.935
4k-鏡子 3.194 21.88%
4k-無鏡 2.495

結論

64k 和 4k 寫入大小都會產生開銷,這對於同步複製來說是“可接受的”。 儘管 3.183 毫秒的平均延遲仍然相當低,但 8k 寫入大小似乎會產生更大的開銷。

-Dave Bermingham,客戶成功總監 經許可轉載西歐

Filed Under: 伺服器集群简单化 Tagged With: Google雲端平台

COVID-19 如何影響高可用性

17 4 月, 2022 by Jason Aw Leave a Comment

COVID-19 如何影響高可用性

COVID-19 如何影響高可用性

與朋友、家人和需要治療、住院或重症監護的人相比,我的 COVID 症狀較輕。 這可能是健康狀況良好的結果,包括兩劑疫苗、加強注射以及早期發現和治療。而且,我向在這場大流行的任何方面失去親人的每個家庭,以及所有失去機會和特殊時刻的人表示衷心的感謝。隨著我和我們 SIOS 團隊的幾位成員從 COVId-19 中恢復過來,我們想分享您的 IT 團隊在應對 COVID 和企業停機時可能正在處理的五件事,以及您可以做的五件事來幫助他們。

IT 團隊面臨的五個 COVID 問題

  1. 個人和家庭的擔憂和恐懼

    最初,我的症狀幾乎不明顯,喉嚨有輕微刺激,還有一點鼻竇引流,我自我診斷為季節性過敏。但是當問題惡化時,伴隨著劇烈的咳嗽,我開始擔心。當然,我們都願意認為我們的工作績效和職責保持不變,但現實可能更難評估。 儘管最初的測試結果為陰性,但我繼續出現症狀,最終影響了我的工作能力,增加了我的個人健康問題,並引發了一些恐懼。 如果您的團隊直接受到 COVID-19 的影響,請了解除了可能影響其日程安排、任務和活動的真正健康挑戰之外,他們可能還要處理個人擔憂、恐懼和擔憂。每個團隊成員可能還處理更大的問題,即對家庭的擔憂。在我生病期間,謝天謝地,我的孩子們都很好。然而,我的妻子就沒有那麼幸運了。她在我出現症狀三天后病了,病的時間更長,症狀和挫折也更嚴重。雖然我們有一個大家庭單位、一名有執照的青少年司機和一輛不是由 COVID 陽性父母駕駛的額外汽車的好處,但您的團隊可能沒有這些奢侈品。即使他們這樣做了,也不會讓他們免於擔憂,也不會減少他們為家庭消毒、讓孩子上學和健康、處理法規、授權和密切接觸所需的時間和精力問題。更不用說對收入和支出的擔憂了。面臨個人和家庭問題的團隊成員可能會難以集中註意力、脾氣暴躁,以及難以滿足最後期限和時間表。

  2. FODO——害怕讓別人失望

    即使沒有 COVID-19 疾病,世界各地的企業也感受到了勞動力減少的影響。被恰當地描述為“大轉變”、“大辭職”或“大洗牌”的事件已經極大地重塑了勞動力,包括那些與 HA 打交道的員工,使執行關鍵任務的人更少的團隊。 團隊成員的這種不足可能會導致那些患有 COVID 的人與害怕讓他人失望 (FODO) 作鬥爭。生病的團隊成員可能會出於對團隊的忠誠或害怕讓老闆、同事或利益相關者失望而繼續努力工作。這種 FODO 經常導致已經在壓力環境中工作的工人(參見上面的 #1 和 2)試圖保持 COVID 之前的活動水平。 雖然英勇,但它也對個人和職業恢復適得其反。

  3. 疲勞

    當我繼續處理 COVID-19 症狀時,我繼續面臨的最大問題之一是疲勞。最初,由 FODO 引起的疲勞使我無法得到充分的休息和恢復。因為我已經看到我們的團隊是多麼的人手不足,並且目睹了其他人試圖冒著疾病來跟上需求,所以我也嘗試做同樣的事情。但是,沒有任何警告,我發現自己精疲力竭,不是在一天結束時,而是在一天中的一段時間內。對我來說,從早上 5 點前開始,繼續專注於工作、任務、策略和人事事務 8 到 12 小時是正常的。(我們可以稍後討論這是否健康)。 現在有些人想在早上 8 點之前攀登珠穆朗瑪峰。我收到的最好建議來自一位朋友和同事,他說:“不要抗拒。 當你的身體說休息時,休息吧!”

  4. 腦霧

    大約在我開始感到不適的同時,一位同事分享說,在出現 COVID 症狀後,他們感覺自己就像是一頭霧水。 像我一樣,他們完全接種了疫苗,症狀和持續時間都很輕微。 事實上,他們實際上從未測試過陽性。儘管如此,他們還是在我們都稱之為“腦霧”的情況下度過了幾天。我們將這種體驗描述為回憶細節的緩慢,一種知道答案的感覺,但缺乏某種不同於身體疲勞和精神疲勞的精神敏銳度。在某些情況下,它表現為對問題的響應較慢、擊鍵暫停或房間燈亮起延遲。

  5. 恢復失敗

    感染新冠病毒五天后,我從早睡中醒來,感覺比以往任何時候都好。 我跳進了我的日常生活,到中午發現我還沒有完全康復。相反,我正在耗盡前一天晚上睡得好所獲得的一小部分能量。試圖克服這種疲憊給我的康復帶來了新的挫折。第二天我感覺比以前更糟了。恢復失敗的痛苦和對如何避免更多挫折的擔憂加重了我的疲勞和迷茫。

因此,當 IT 團隊遇到 COVID-19 問題時,IT 團隊領導、利益相關者和經理應該怎麼做。

幫助 IT 團隊對抗 COVID 的五種方法

  1. 練習同理心

    請注意,COVID 對每個人和家庭的影響不同。您的一些同事和管理員會遇到小問題,沒有症狀,也沒有並發症。而其他人,單親家庭,多代家庭,或有孩子或弱勢群體的家庭將有更多的問題和擔憂。知道病毒也會對每個人產生獨特的影響。即使在我自己的家庭中,我的症狀和我妻子的症狀也不同。當我感到更疲勞時,她卻經歷了更多的頭痛。 對可能正在處理腦霧、兼顧工作日程、照顧生病的親人或處理與 COVID 相關的無數問題的同事要有耐心。

  2. 評估需求

    與流感或普通感冒不同,COVID 的恢復是不規則的。 一位團隊成員可能有一天會出現在工作中,感覺好多了,但第二天就生病待在家裡。 您的企業仍有高可用性和災難恢復的技術需求和要求。但是,對於因疾病而進出的人員,請務必了解團隊中當前所需的角色和職責。當一個人生病時,一定要評估他們的角色、他們對團隊的影響、他們對基礎設施的責任程度等。您可能還需要評估團隊或組織中的哪些人可以在發生嚴重停機事件時提供保障。

  3. 優先處理問題

    通過確定關鍵問題的優先級來幫助您的團隊。在正常情況下,您的 IT 團隊正在平衡從瑣碎(USB 鍵盤)到關鍵(與停機時間、安全威脅或存儲問題相關的問題)的數十個請求。雖然這對您和團隊來說可能很明顯,但其他利益相關者可能需要了解 IT 團隊的狀態以及如何處理運營,直到恢復到更“正常”的人員配備。

  4. 確保您的流程是最新的

    隨著團隊成員的進出,保持 IT 維護和管理流程保持最新狀態至關重要。這些流程將幫助團隊中的每個成員在執行不屬於他們正常職責的任務時有效且高效地為您的企業服務。 它還將減少每個團隊成員在同事康復期間研究他們所覆蓋的系統狀態所需的時間。

  5. 給人們時間

    我已經比我應該更多地匆忙回到日常生活中,只是在第二天遭受挫折和更大的疲勞的後果。作為團隊的領導者或個人貢獻者,一定要給自己和團隊時間“恢復正常”。

隨著大流行的繼續,我們都希望未來與常態非常相似,包括減少疾病、恐懼和擔憂。同時,更多地了解您的團隊成員在 COVID 疾病和康復期間所面臨的問題將極大地幫助您積極準備和度過當前的風暴。此外,從這次大流行中吸取的重要經驗教訓可以應用於許多其他組織、員工生活和全球問題。

經授權轉載西歐

Filed Under: 伺服器集群简单化

  • « Previous Page
  • 1
  • …
  • 49
  • 50
  • 51
  • 52
  • 53
  • …
  • 113
  • Next Page »

最近的帖子

  • 什麼是高可用性(HA)?
  • 如何在周五晚上的系統崩潰中倖存下來:從簡陋的裸機到無縫的數據複製
  • 接地氣:錯過Percona Live Amsterdam讓我對HA有了哪些新的認識
  • SIOS LifeKeeper 與 Red Hat 高可用性附加元件:
  • 應用彈性現況:2026 年 SIOS 高可用性調查

最熱門的帖子

加入我們的郵件列表

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