SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

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

SIOS LifeKeeper – Linux 的高可用性

12 7 月, 2022 by Jason Aw Leave a Comment

SIOS LifeKeeper – Linux 的高可用性

SIOS LifeKeeper – Linux 的高可用性

運行 SAP、S/4 HANA、SQL Server、MaxDB 和 Oracle 等業務關鍵型應用程序的企業面臨兩難境地。 即使是這些複雜工作負載的短暫停機時間也可能產生災難性後果。 但傳統的 HA 集群可能很複雜且成本高昂。 遷移到雲端並不是答案雲可用性 SLA僅涵蓋硬件。 他們無法在不降低雲中性能的情況下為有狀態應用程序提供 HA 和 DR。 傳統本地集群中使用的共享存儲在某些雲中不是一種選擇,而在另一些雲中過於復雜且成本高昂而無法實用。 許多 HA 集群解決方案無法對雲區域和可用區進行故障轉移——限制了它們可以提供的災難恢復級別。 開源集群不是答案。 它需要復雜的腳本,並且容易出現人為錯誤和故障。 確保複雜的 ERP 或數據庫故障轉移所需的手動步驟可以正確離開。 IT 團隊不願執行定期維護和故障轉移測試。

SIOS 有解決方案。

SIOS LifeKeeper 提供高可用性和災難恢復確保系統、數據庫和應用程序在需要時運行。

  • 獨特的應用感知恢復套件使在 SAP、S/4 HANA、SQL Server、MaxDB 和 Oracle 等複雜環境中創建和管理高可用性集群變得簡單且無錯誤。
  • 全程監控,與僅監控服務器操作的 HA 解決方案不同,SIOS LifeKeeper 監控應用程序堆棧網絡、存儲、操作系統和應用程序。
  • 先進的應用感知技術自動化配置和驗證輸入——實現準確配置的速度比開源集群軟件快五倍,並確保故障轉移可靠並維護應用程序最佳實踐。

在雲中,SIOS 集群跨區域和可用區發生故障,以獲得最大的 DR 保護。 對於想要部署多個集群的客戶,SIOS LIfeKeeper 的克隆功能允許您使用一致的預定義設置和集成的最佳實踐來創建多個相同的集群。 SIOS LIfeKeeper 包含在一個名為 SIOS Protection Suite 的捆綁包中,其中包括特定於應用程序的恢復工具包和用於 SANless 集群和 DR 的高效複製。為在本地、雲或混合雲環境中運行的關鍵 Windows 或 Linux 工作負載獲得 99.99% 的可用性和災難保護。安排演示或註冊您的免費試用今天。

經授權轉載西歐

Filed Under: 伺服器集群简单化

迪士尼和皮克斯靈魂的高可用性課程

7 7 月, 2022 by Jason Aw Leave a Comment

迪士尼和皮克斯靈魂的高可用性課程 (1)

迪士尼和皮克斯靈魂的高可用性課程

在迪士尼和皮克斯的靈魂裡,主角喬·加德納(傑米·福克斯配音)夢想成為一名專業的爵士鋼琴家。然而,儘管他做了很多嘗試,但令他母親失望的是,他發現自己離夢想很遠,過著“中年中學樂隊教師”的生活。但隨後,“由於最後一刻有機會在爵士傳奇人物多蘿西婭·威廉姆斯的四重奏中演出,他的夢想似乎終於要成為現實。直到“一個重大的失誤把他送到了偉大的前世——一個靈魂得到他們的興趣、個性和怪癖的地方——喬被迫與一個“22”一起工作,一個對生活在地球上沒有興趣的古老靈魂,以“在為時已晚之前以某種方式返回地球( D23.com )。”迪斯尼和皮克斯的靈魂是一部偉大的電影,其中有許多有趣和相關的角色,幽默,描述性的,有時令人不安的相關性對生活、目的和生活的看法。但是,這也是一部有錢的電影領導力課程、生活課程和更高可用性的課程。

來自迪士尼和皮克斯靈魂的關於更高可用性的七個想法。

1.注意正在發生的事情

在迪斯尼和皮克斯的靈魂裡,喬獲得了他夢想中的演出。但當喬開始走路並分享這個好消息時,他正忙著玩手機,以至於他走到街上,差點被一大堆磚頭壓死,然後他危險地走向一個開放但明顯標記的沙井。那麼更高可用性的教訓是什麼——注意。請注意來自監控和恢復解決方案的警報和錯誤消息。請注意您的託管服務提供商所做的更改,尤其是來自供應商、合作夥伴和安全團隊的重要通知。警報和警告的存在是有原因的,當您看到警告時未能解決它們或採取適當的措施可能會導致您陷入深淵。

2.不要掉進坑里

對警告視而不見或無視警告,喬最終落入一個敞開的沙井並變成了靈魂。這立即改變了他的夢想和計劃。那麼,您的企業可能會陷入什麼困境?您的企業發展道路上是否存在潛在漏洞,例如:覆蓋漏洞、版本差距、維護計劃和現實中的漏洞,甚至是供應商響應能力的黑洞?環顧您的環境,除了明顯的單點故障之外,您還會陷入哪些漏洞?是否有警告表明您存在與未受保護的關鍵應用程序、團隊之間的溝通差距,甚至是流程和危機管理中的漏洞相關的漏洞。不要掉入可能損壞甚至結束您的高可用性.

3.不要急於高可用

成為靈魂後,喬開始積極嘗試回到自己的身體。當他與 22 配對時,她將他帶到 Moonwind,後者同意嘗試幫助他找到自己的屍體,他們照做了。但喬變得太急於跳回他的身體,儘管月風很謹慎。在他的匆忙中,他和 22 都掉到了地上,但喬最終進入了一隻貓的身體,而 22 最終進入了他的身體。就像喬一樣,如果我們沒有耐心,跳躍發生得太快,我們最終會陷入危險甚至更糟的境地。我們可能不在貓的身體裡,但我們也可能遠離維持 HA 所需的最佳位置。跳得太快看起來像:

  1. 在沒有架構或整體解決方案的情況下部署軟件
  2. 無需在 QA 中測試即可在生產中部署
  3. 在不了解雲或云對 HA 意味著什麼的情況下部署到雲中
  4. 根據時間線部署到生產環境中且未完成驗收測試
  5. 在沒有專門構建的商業級解決方案的情況下部署應用程序監控和編排

4. 不要過早退出——高可用性絕非易事

當年輕的長號手康妮來到她老師的公寓時,她很沮喪,想辭職。她首先告訴喬(喬的身體實際上是 22 歲)她很沮喪,她只想放棄和退出。但片刻之後,她在長號上演奏了最後一首曲子,並意識到現在退出還為時過早。在更高的可用性中,我們都非常像 Connie。 有時,困難讓我們覺得自己已經走到了盡頭,想要退出。有時,中斷會讓我們確信是時候認輸了。 不要那麼快放棄。HA 絕非易事,絕非易事!但是,放棄努力結束停機時間總是為時過早,所以像康妮一樣,也許我們只需要堅持下去。這引導我進入下一課。

5. 你還沒有嘗試一切

電影中的22是一個還沒有活過的靈魂。她相信她已經嘗試了所有可能的事情來給她一個火花,但是當她落入喬的身體時,她意識到有很多她沒有嘗試過。在創建更高可用性的解決方案時,很容易讓人覺得您已經嘗試了所有產品和每種產品,但很可能您還沒有。全新的視角,或以全新的眼光看待挑戰和問題,可能會幫助您提高系統和企業可用性。

嘗試提高可用性的一些方法可能很簡單,例如:

  1. 為關鍵監控指標設置附加警報
  2. 添加分析。
  3. 執行定期維護(補丁、更新、安全修復)
  4. 記錄您的流程
  5. 記錄您的操作手冊
  6. 改善您的溝通渠道
  7. 進行定期維護

其他想法可能需要更多的工作、研究、時間和金錢,但如果你過去沒有探索過它們可能是值得的。

通過更多時間和精力提高可用性的方法包括:

  1. 刪除黑客和解決方法。
  2. 創建可靠的可重複解決方案架構
  3. 商業化和專門建造
  4. 聘請顧問
  5. 審核並記錄您的架構
  6. 升級你的虛擬機; CPU、內存和 IOP
  7. 在區域或區域級別添加額外的冗餘

6. 提出更多(更好)的問題

在扮演手套先生的喬不小心在頭髮中間剪了一條路後,手套先生和喬不得不去看看喬的理髮師德茲。當喬和德茲坐在理髮椅上時,他們開始談論目的、生活、存在主義等等。理髮後,22 詢問 Dez 為什麼他們以前從未有過這樣的對話,關於 Dez 的生活。德茲回答說他以前從未問過。有時,我們可以如此專注於解決方案、雲或本地方法、語言和架構,以及告訴別人我們在做什麼,以至於我們忘記提出可以打開一個全新世界的問題。當喬問問題時,他對德茲和他自己有了更多的了解。也許更好的 HA 的教訓是開始詢問更多關於我們的解決方案、架構、業務目標和挑戰、最終客戶目標、我們的團隊,甚至是我們在更大範圍內的角色和職責的問題。

增加我們可用性的一些簡單問題包括:

  1. 如果明天發生災難,原因是什麼系統、流程、產品或解決方案?
  2. 要保護的最重要的事情是什麼?應用程序、數據、元數據,所有這些?
  3. 我們的應用程序和數據庫可以容忍什麼 RPO?
  4. 我們的客戶不能容忍什麼?
  5. 我錯過了什麼?
  6. 我們在哪裡記錄了這個架構?
  7. 我不明白什麼?

7. 堅持有回報

“倒計時,”特里說。Terry 的任務是跟踪 The Great Beyond 的進入者,他正在仔細計算應該到達或已經到達的靈魂數量。喬繞道前往偉大的前世後,特里下定決心要找到失踪的靈魂並解決問題。 當他開始工作時,他正站在一條長長的文件櫃走廊裡,這些文件櫃一直延伸到眼睛所能看到的高度。但過了一會兒,他找到了喬的檔案,發現喬發現了一個漏洞,這就是計數被取消的原因。特里表現出的同樣毅力也將在更高的可用性領域得到回報。面對令人生畏的不確定性、大量的日誌文件和大量可能的故障場景,堅持不懈地在問題發生之前發現並解決問題,或者在問題發生後進行有效的分析和修復,這將引領我們走向更好我們想要的結果。同樣,缺乏勤奮和毅力意味著同樣的問題可能會在以後重新出現,即使在使用新軟件的新環境中也是如此。

隨著電影靈魂的結束,喬回到了偉大的過去,找到並說服 22 接受她的地球通行證並冒險。讓人想起她和喬一起摔倒在地時,她又一次冒險。令我的孩子們沮喪的是,這部電影的結尾沒有描述 22 對她的生活的看法或隨之而來的新機會。她只是從偉大的過去中跳出來,期待接下來會發生什麼。也許我們也正處於一個可以冒險的時刻……“偉大的前世”中的一個時刻,以及一個讓這一年成為更高可用性的機會。

– Cassius Rhue,客戶體驗副總裁

經授權轉載西歐

Filed Under: 伺服器集群简单化

高可用性集群的新選擇,SIOS 鞏固了對 Microsoft Azure 共享磁盤的支持

27 6 月, 2022 by Jason Aw Leave a Comment

高可用性集群的新選擇,SIOS 鞏固了對 Microsoft Azure 共享磁盤的支持

高可用性集群的新選擇,SIOS 鞏固了對 Microsoft Azure 共享磁盤的支持

微軟推出Azure 共享磁盤在 2022 年第一季度。 共享磁盤允許您將託管磁盤附加到多個主機。 實際上,這意味著 Azure 現在擁有相當於 SAN 存儲的功能,能夠高度可用集群使用雲中的共享磁盤!

將 Azure 共享磁盤與 SIOS Lifekeeper 群集層次結構結合使用的一個主要優點是,您將不再需要擁有存儲仲裁或見證節點。 這樣你就可以避免所謂的腦裂– 當節點之間的通信丟失並且幾個節點可能同時更改數據時會發生這種情況。 更少的節點意味著更少的成本和復雜性。

LifeKeeper SCSI-3 Persistent Reservations (SCSI3) 恢復套件

SIOS 推出了一個應用程序恢復工具包 (ARK)用於我們的 LifeKeeper for Linux 產品。 這稱為 LifeKeeper SCSI-3 Persistent Reservations (SCSI3) 恢復套件。 這允許將 Azure 共享磁盤與 SCSI-3 預留結合使用。 ARK 保證共享磁盤只能從當前在該磁盤上保留 SCSI-3 保留的節點寫入。

安裝 SIOS Lifekeeper 時,安裝程序將檢測到它正在 Microsoft Azure EC2 中運行。 它將自動安裝 LifeKeeper SCSI-3 Persistent Reservations (SCSI3) 恢復工具包以支持 Azure 共享磁盤。

Lifekeeper 中的資源創建簡單明了(圖 1)。 Azure 共享磁盤只需在本地安裝後作為文件系統類型資源添加到 Lifekeeper。 Lifekeeper 將為其分配一個 ID(圖 2)並自動管理 SCSI-3 鎖定。

圖1。 在 LifeKeeper 中創建 SAP 實例(sapinst)
圖 2:創建 擴展至兩個節點。

SCSI-3 預留保證 Azure 共享磁盤只能在持有預留的節點上寫入(圖 3)。 在集群節點之間失去通信的情況下,備用服務器將上線,從而導致潛在的腦裂情況。 但是,由於 SCSI-3 保留,一次只有一個節點可以訪問磁盤。 這實際上防止了實際的腦裂情況。 只有一個系統會保留預訂。 它將成為新的活動節點(在這種情況下,另一個將重新啟動)或保持活動節點。 沒有保留 Azure 共享磁盤預留的節點只會使資源處於“待機狀態”狀態。 僅僅因為他們無法獲得預訂。

圖 3 – 嘗試掛載已保留的磁盤時 Lifekeeper 日誌的輸出。

鏈接到 Microsoft 對 Azure 共享磁盤的定義https://docs.microsoft.com/en-us/azure/virtual-machines/disks-shared

你可以期待什麼

目前,SIOS 支持本地冗餘存儲 (LRS)。我們正在與 Microsoft 合作測試和支持區域冗餘存儲 (ZRS)。 理想情況下,我們想知道 ZRS 何時發生故障,以便我們可以將資源層次結構故障轉移到活動存儲的最本地節點。 SIOS 預計 Azure 共享磁盤支持將出現在其下一版本的 Lifekeeper 9.6.2 for Linux 中。

經授權轉載西歐

Filed Under: 伺服器集群简单化

什麼是“腦裂”以及如何避免它

23 6 月, 2022 by Jason Aw Leave a Comment

什麼是“腦裂”以及如何避免它

什麼是“腦裂”以及如何避免它

正如我們所討論的,在一個高可用性集群環境中有一個活動節點和一個或多個備用節點,當活動節點發生故障或停止響應時,它們將接管服務。

在考慮節點之間的網絡層之前,這聽起來像是一個合理的假設。 如果節點之間的網絡路徑出現故障怎麼辦?

任何一個節點現在都不能與另一個節點通信,在這種情況下,備用服務器可能會在它認為活動節點發生故障的基礎上將自己提升為活動服務器。 這導致兩個節點都變得“活躍”,因為每個節點都會認為另一個節點已經死了。 結果,數據完整性和一致性受到損害,因為兩個節點上的數據都會發生變化。 這被稱為“裂腦” .

為避免出現腦裂情況,應在集群中安裝 Quorum 節點(也稱為“見證”)。 添加仲裁節點(到由偶數個節點組成的集群)會創建奇數個節點(3、5、7 等),節點投票決定哪個應該充當集群中的活動節點。

在下面的示例中,包含節點 B 的服務器機架丟失了局域網連接性。 在這種情況下,通過在集群環境中添加第 3 個節點,系統仍然可以確定哪個節點應該是活動節點。

Quorum/Witness 功能包含在西歐保護套件。 安裝時,在所有節點(不僅是仲裁節點)上選擇 Quorum / Witness,並在所有節點(包括仲裁節點)之間定義通信路徑。

仲裁節點不託管任何活動服務。 它的唯一作用是參與節點通信,以確定哪些是活動的,並在通信中斷的情況下提供“平局投票”。

西歐也支持IO 防護和存儲作為仲裁設備,在這些配置中不需要額外的仲裁節點。

經授權轉載西歐

Filed Under: 伺服器集群简单化

節點之間的數據複製如何工作?

19 6 月, 2022 by Jason Aw Leave a Comment

節點之間的數據複製如何工作?

節點之間的數據複製如何工作?

在傳統的數據中心場景中,數據通常存儲在存儲區域網絡中( SAN )。 雲環境通常不支持共享存儲。

西歐DataKeeper 使用複制技術提供“共享”存儲,以創建當前活動數據的副本。 它創建一個作為 RAID1 設備工作的 NetRAID 設備(跨設備鏡像數據)。

數據更改從鏡像源(活動節點上的磁盤設備 – 下圖中的節點 A)複製到鏡像目標(備用節點上的磁盤設備 – 下圖中的節點 B)。

為了保證兩個設備之間數據的一致性,只有活動節點對複制的設備(下例中的 /datakeeper 掛載點)具有寫訪問權限。 當它是鏡像目標(即,在備用節點上)時,不允許訪問複製設備(/datakeeper 掛載點)。

經授權轉載西歐

Filed Under: 伺服器集群简单化

  • « Previous Page
  • 1
  • …
  • 3
  • 4
  • 5
  • 6
  • 7
  • …
  • 70
  • Next Page »

最近的帖子

  • 視頻:SIOS 優勢
  • AWS 中三節點集群的 SIOS DataKeeper 演示
  • 2023 年預測:數據民主化將推動對高可用性的需求
  • 了解業務關鍵型應用程序高可用性的複雜性
  • Epicure 使用 Amazon EC2 和 SIOS SANLess 集群軟件保護關鍵業務 SQL Server

最熱門的帖子

加入我們的郵件列表

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