SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

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

雲可用性:2021年的最大陷阱

12 4 月, 2021 by Jason Aw Leave a Comment

雲可用性:2021年的最大陷阱

作者Carey Nieuwhof吸引了我一個2021年最大陷阱的博客主題。 雖然沒有直接與HA交流,但僅是這個話題就讓我反思了2020年的一些趨勢。雲創新眾多,始於基礎架構的最基本層次。 更不用說人工智能,機器學習,計算能力和算法,內存管理和共享以及其他方面的進步。 所有這些進步加起來使當前的云成為最健壯,可靠和可用的數據中心。 這些中心經過優化,配備了冗餘電源,散熱,大量用於監視和警報的IoT設備,冗餘網絡,高速互連,大型服務器,存儲和磁盤,這些令人印象深刻,而且很可能是2021年可能出現的最大陷阱。

2021年最大的陷阱將是相信,僅雲可用性就可以與更高可用性相同或足夠。 這是一個複雜的陷阱。 構成許多數據中心主幹的已命名進步的清單確實是巨大而令人印象深刻的,並且僅是驅動雲的現有技術創新的一小部分。 那麼,是什麼使這種大規模冗餘,高容量和AI驅動的基礎架構成為陷阱呢? 即,硬件和基礎架構的可用性仍然使您的企業面臨風險。

雲高可用性的最大風險

磁碟

磁盤變得更快,更智能。 芯片組,訪問技術,製造,存儲容量和RAID技術方面的新突破令人矚目,這意味著雲供應商能夠為速度,訪問和冗餘設置昂貴的數字。 這樣可以降低磁盤基礎結構出現單點故障(SPOF)的風險,並確保單個磁盤甚至磁盤暫時斷電不會造成可用性不足。

儲存陣列

提供給磁盤訪問的數據中心內的存儲陣列和存儲櫃也得到了極大的改進。 這些裝置雖然體積較小,但容量和性能得到了增強,不再像閃爍的燈光和汽艇大小的風扇那樣大放異彩。 您將很難找到一個沒有冗餘電源,冗餘磁盤功能並且無法在相連的存儲單元之間(甚至在距離較遠的單元之間)提供幾乎零複製的現代機箱。 此外,這些單元還增加了AI的優勢,可以預測故障,主動解決問題並優化工作負載以減少性能瓶頸。

伺服器

請記住,很久以前,知名的製造商和技術預測者就在預測改變遊戲規則的技術,這些技術將重塑未來的前景。 好像幾十年前,人們在預測服務器技術的進步,例如:減少佔用空間,更快,更複雜的芯片組,NVMe,電池效率,散熱進步,存儲進步,內存和持久性內存進步,GPU和裸機配置。 那個未來已經到來並且被超越了。 服務器現在正在加快雲計算功能的步伐,並提高了雲提高冗餘,可靠性和健壯性的能力。

聯網

網絡解決方案,工具,軟件和設備的進步也使2020年雲可用性變得更強大的事情清單。 在過去的幾年中,供應商發布了解決方案,這些解決方案擴展了雲間和雲內網絡的速度,可能的拓撲,容量和距離功能。 像許多其他技術一樣,供應商正在利用AI和機器學習來自動化流量和模式,利用製造方面的先進優勢來構建設備冗餘,從而可以利用這些冗餘來提高可用性和可靠性。

應用領域

如果不加以保護,應用程序仍然是雲體系結構中的脆弱部分。 不受應用程序感知的高可用性模塊或框架或SIOS應用程序恢復工具包(ARK)保護的應用程序可能會在業務生命週期中最關鍵的時間或時刻崩潰。 SIOS ARK為雲中的應用程序提供關鍵的應用程序感知監視和恢復,以及在發生故障時進行故障轉移和災難恢復編排。

資料庫

雖然數據庫的數量已提高了其健壯性,甚至有些數據庫已經提供了複製增強功能,但這些數據庫本身仍然存在風險。 具有復制技術的數據庫仍然需要業務流程,自動化和智能,以確保它們對需要它們的應用程序組件高度可用。 如果您的應用程序實際上在另一個Region或DR站點上失敗,則數據庫繼續在主要Region和Availability Zone中徘徊是有什麼用的。 使用SIOS Technology Corp HANA ARK和SAP認證的SAP S / 4 HANA ARK的自動化和最佳實踐對具有復制功能的數據庫(例如SAP HANA數據庫)進行補充。 通過SIOS保護套件,SIOS DataKeeper for Linux和關聯的ARK的組合來保護沒有復制技術或技術受限的數據庫。

貯存

在磁盤和存儲領域中,令人信服的是,容量,軟件和硬件突襲的冗餘意味著您具有很高的可用性。 但是,只有在需要存儲的應用程序和虛擬機可以訪問存儲的情況下,存儲才可用。 您已部署了什麼技術來監視和恢復已安裝的雲共享和卷,例如EFS和ANF。 計劃外的停機時間及其相關的混亂情況可能與意圖良好的用戶的意外卸載或脫機操作差不多。

虛擬機

虛擬機監控程序技術使您的虛擬機按鈕變得容易。 集成雲解決方案承諾監視VM是否可用,並提供重啟或遷移等選項。 這些解決方案不足以解決您的虛擬機可能會停滯,延遲或降低可用性的問題。 除了您的雲供應商提供的產品之外,您還需要一個監視和可用性解決方案,該解決方案應了解如何監視VM運行狀況,例如:

  • 磁盤容量。
  • CPU死鎖
  • 內存爭用和錯誤
  • 資源枯竭

運行無能力處理應用程序請求的VM可能會避開僅監視雲的工作,但不應逃避對更高可用性解決方案的監視。

數據中心

讓我們現實一點。 數據中心可用性,冗餘性和可靠性方面的所有進步並沒有消除消除數據中心成為單點故障(SPOF)的需要。 作為客戶體驗副總裁,我們與一位客戶合作,該客戶在私有云數據中心內部署了一流的冗餘,這與主要的公共雲供應商非常相似。 如果不是因為SIOS Technology Corp.提供的高可用性和數據複製解決方案,當熱帶風暴席捲其區域並切斷電源,備用發電機,冷卻設備和網絡時,該客戶將遭受重大停機。

但是,借助SIOS技術,客戶能夠在風暴發生之前搶先進行故障轉移到更內陸的數據中心。 冷卻故障,施工事故以及人為和自然災害不斷提醒我們,單個數據中心與更高的可用性並不相同。

不要陷入2021年的最大陷阱 通過避免認為雲已覆蓋來確保您具有真正的高可用性。

–客戶體驗副總裁Cassius Rhue

轉載自SIOS

Filed Under: 伺服器集群简单化

改善高可用性的五十種方法

5 4 月, 2021 by Jason Aw Leave a Comment

改善高可用性的五十種方法改善高可用性的五十種方法

我喜歡第二年的開始。好吧,大部分。我喜歡樂觀,神秘,潛力和希望,隨著日曆翻到另一年,它似乎已融入生活。但是,隨著時間的推移,還有一些弊端。每年新年的開始都會帶來____種做事的方式_____。我的收件箱裡總是滿是“減肥的二十種方法”。 “建立投資組合的十種方法。” “管理壓力的三個技巧。” “使用新iPhone的19種方法。”幾乎在生活和工作的每個領域,都有很多關於自我改善,文化轉變,壓力管理和減肥的清單,其中包括“改善家庭辦公室的十三種方法”。但是,高可用性又如何呢?您每個星期只有這麼多時間。 因此,您如何使HA解決方案比以往更高效,更可靠。您的清單在哪裡?這裡有五十種方法可以使您的高可用性體系結構和解決方案更好:

  1. 更快地從集群獲取更多信息
  2. 為關鍵監控指標設置警報
  3. 添加分析。乘以你的知識
  4. 從權威的角度建立簡潔的架構
  5. 連接更多資源。 與類似的合作夥伴和其他醫管局專業人員建立聯繫
  6. 聘請專門研究高可用性的顧問
  7. 現有覆蓋率的100倍。 擴大您的保護範圍
  8. 集中您的日誌和管理平台
  9. 刪除工作
  10. 刪除黑客和變通辦法
  11. 創建可靠的可重複解決方案架構
  12. 利用您的平台:公共,私有,混合或多雲
  13. 發現你的差距
  14. 搜索單點故障(SPOF)
  15. 拒絕實施不完整的解決方案
  16. 眾包創意和增強功能
  17. 進行商業化和專用
  18. 為每個生命週期階段製定明確的策略
  19. 澄清決策過程
  20. 記錄您的過程
  21. 記錄您的操作手冊
  22. 記錄您的架構
  23. 計劃人員輪換
  24. 計劃維護
  25. 進行定期維護(補丁,更新,安全修復)
  26. 定義和完善入職策略
  27. 明確責任
  28. 改善您的溝通渠道
  29. 與利益相關者過度溝通
  30. 在危機發生前實施危機解決方案
  31. 升級基礎架構
  32. 升級您的虛擬機; CPU,內存和IOP
  33. 在區域或區域級別添加冗餘
  34. 添加數據複製和災難恢復
  35. Go OS和Cloud不可知
  36. 獲得團隊培訓(雲,操作系統,HA解決方案等)
  37. 繼續訓練團隊
  38. 探索混亂測試
  39. 模仿一流的架構
  40. 要有創造力。創新擴展了您可以保護和自動化的範圍。
  41. 提高自動化程度
  42. 調整系統
  43. 多聽
  44. 實施嚴格的變更管理
  45. 部署質量檢查群集。在更新/升級生產之前測試所有內容
  46. 對任何故障進行根本原因分析練習
  47. 解決RCA和閉環糾正措施報告
  48. 第一次學習您的課程。重用關鍵的學習成果。
  49. 整理。不要在生產集群上運行不必要的服務或應用程序
  50. 堅持不懈。繼續努力。

那麼,您學到了什麼來增加和改善企業可用性的想法和方式呢? 讓我們知道!

-客戶體驗副總裁Cassius Rhue

轉載自SIOS

Filed Under: 伺服器集群简单化

如果您要使用開源高可用性,那麼團隊需要具備七項技能

31 3 月, 2021 by Jason Aw Leave a Comment

如果您要使用開源高可用性,那麼團隊需要具備七項技能

如果您要使用開源高可用性,那麼團隊需要具備七項技能

在高可用性(HA)領域中,如果您決定採用開源方式,則團隊需要掌握某些重要技能。 開源的定義是指可以免費使用的軟件。

如今,微軟和SIOS Technology Corp等供應商為許多操作系統提供了高可用性集群的多種商業實現方案。這些商業解決方案提供了資源監視,依賴性管理,故障轉移和集群策略以及某種形式的預先打包和定價的管理方案。商業實現的替代方法是幾種開源選項,這些選項也使公司有機會為其企業提供高可用性。

隨著公司繼續尋求優化,節省成本和潛在的更嚴格控制,越來越多的公司和客戶也正在考慮轉向開源可用性解決方案。

要遷移到開源HA,您的團隊可能需要具備以下7種技能:

1.編碼技巧

在許多情況下,缺少對企業應用程序的預打包和捆綁支持意味著您的團隊將需要能夠開發解決方案來保護組件,解決捆綁組件的問題或編寫應用程序連接器以確保正確處理應用程序意識。很多人都可以編寫腳本,但是您的團隊將需要知道如何創建並遵守合理的開發實踐和標準。這方面的基本知識包括:

  • 設計和架構要求
  • 設計評論
  • 代碼/代碼審查和單元測試(最好是自動化的)

2.對技術環境的了解

許多企業應用程序需要與多個系統集成,以提供滿足服務水平協議(SLA)和服務水平目標(SLO)的高可用性。您的團隊將需要深刻的應用程序意識和對技術環境的了解,才能為與多個企業系統的集成建立保護和解決方案。您需要了解關鍵應用程序的來龍去脈,這些應用程序的技術環境,網絡,硬件,虛擬機管理程序以及對環境和應用程序依賴性的了解的人員。您還需要團隊成員了解開放源代碼社區中打算使用的HA技術的體系結構,功能和局限性。 考慮一下您的團隊了解和了解的這些領域中的多少:

  • 數據傳遞和節點通信
  • 節點故障
  • 應用管理
  • 系統恢復並重新啟動
  • 記錄和消息
  • 數據彈性和保護

3.業務流程知識

您需要有人來了解您的業務需求和業務流程。您的團隊需要專業人士,他們需要了解企業的業務以及推動業務發展的流程。您的團隊將需要了解和了解有多少預算可用於開發解決方案,企業願意承擔多少風險,以及如何收集可能未講或未指定的其他要求。

團隊還需要知道或聘請知道如何將這些業務需求轉換為軟件需求以及如何管理流程以實現最低可行的高可用性解決方案以實現滿足業務需求的成果的人,或者業務,並適合業務流程。

4.具有操作系統,應用程序和基礎架構的經驗

如果您想全力以赴,您的團隊將需要了解操作系統,應用程序和基礎架構的經驗。您需要了解各種操作系統的發行週期,包括Linux的內核版本,Windows的更新和修補程序。您內部有需要支持的應用程序,但也需要勤勉地了解應用程序更新周期,它們的依賴性以及應用程序和操作系統支持矩陣的交集。如果您的環境是均勻的,那就太好了。否則,您的團隊將需要了解RHEL,RHEL派生產品和SUSE之間的區別。如果您同時使用Linux和Windows,則也需要了解它們。您還需要了解基礎架構對應用程序和操作系統組合的影響。AWS和Azure呈現的高可用性差異與GCP,本地和其他虛擬機管理程序有所不同。

5.變更管理能力

想像一下,您擁有一支具有技術和業務知識以及對操作系統,基礎架構和應用程序有紮實了解的開發團隊來創建解決方案。但是,將腳本放在一起僅僅是個開始。您的團隊還需要變更管理功能。您的團隊將如何跟踪代碼更改以及版本,軟件包和軟件包位置?您的團隊將如何管理更新和變更的發布?您的團隊將需要精通git等源代碼存儲庫,Jira等項目管理工具以及發布訓練的熟練程度。您需要一個了解如何進行代碼更新,提供補丁和修復程序,同時又能避免不必要的影響的團隊。

6.數據分析和故障排除經驗

當您進入交付自己的HA解決方案的空間時,您的團隊將需要分析和故障排除經驗。您需要擁有能夠理解應用程序代碼,系統消息以及應用程序錯誤日誌和跟踪文件的交集的資源。發生系統崩潰時,您將不得不更深入地研究日誌以進行故障排除並找到根本原因,分析數據以提出建議,並準備推出更改(請參見上面的#5)。別忘了,即使沒有錯誤,故障或系統崩潰,您的團隊也需要了解並了解這些日誌和跟踪文件中的數據可以告訴您環境的運行狀況。

7.連接(開發,質量檢查,合作夥伴,社區)

坦白說,您的業務不是要提供高可用性,但是,如果您決定涉足開源HA領域,那麼您不僅需要團隊的智慧,還需要更多的幫助。獲得額外幫助的關鍵是了解從何處開始,然後與社區開發人員,測試專家,HA和應用程序合作夥伴以及開源社區建立正確的聯繫。開放式論壇確實很有幫助,但是您需要仔細檢查響應時間是否符合您的SLA和SLO。

使用開放源代碼解決方案是許多公司選擇的一種選擇,以解決成本問題並意識到靈活性,更低的成本和更低的風險。但是,買方要當心,新技能和管理形式可能存在隱性成本,而使用“開源自己的HA解決方案”所需的開源程序也存在隱性風險。

–客戶體驗副總裁Cassius Rhue

轉載自SIOS

Filed Under: 伺服器集群简单化

高可用性的雲遷移最佳實踐

25 3 月, 2021 by Jason Aw Leave a Comment

高可用性的雲遷移最佳實踐

高可用性的雲遷移最佳實踐

在2020年,我們看到越來越多的企業將更多的任務關鍵型應用程序,ERP和數據庫遷移到雲中。 但是,並非所有這些遷移都很順利。 我親眼目睹了由於缺乏對應用程序可用性的規劃,“ DIY高可用性”改造的複雜性,與“提升和轉變”所帶來的誤解以及意外成本有關的雲遷移項目急劇減慢,甚至停止了。

組織可以採用多種最佳實踐,雲清單和其他方式為雲做準備。 對於那些在2020年雲遷移方面遇到停頓或計劃在2021年取得進步的人們,在高可用性群集的每種遷移策略中都應考慮以下最佳實踐。

雲遷移最佳實踐

收集需求

許多遷移到雲的組織都認為雲是遷移到雲的本地架構。 當內部部署的網絡,存儲,磁盤速度和系統大小與雲現實發生衝突時,對雲遷移的這種誤解通常會導致停頓和延遲。 向雲的更平滑過渡始於收集對基礎架構,治理和合規性,安全性,規模以及相關控制和資源的實際需求。

設計與文件

在設計階段,將本地環境的體系結構映射到已選擇以實現最大可用性並進行了詳細記錄的雲環境。 在此階段,隨著架構的形成,您將確定IP,負載均衡器,IOPS和數據可用性的策略。 團隊需要研究如何通過能夠自動實現雲複雜性的強大應用程序和基礎架構可用性解決方案來增強雲固有的可用性。 在SIOS,我們的AWS和Azure群集及可用性專家與客戶合作,將本地NFS交換為AWS EFS,Azure ANF或獨立的NFS群集層。 此外,此階段成功實施的關鍵部分將記錄所有內容。 文檔是遷移成功的一個經常被忽略但必不可少的要素。

計劃高可用性

要在雲中實現高可用性,需要了解需求,創建設計並記錄計劃以規劃實現這些需求的策略的計劃。 基本計劃應包括人員配備,人員培訓,部署QA系統測試,生產前步驟,部署,部署後驗證以及正在進行的迭代。 雲遷移的最佳結果來自經過深思熟慮的計劃流程;不是臨時的,固定的解決方法。

職員

您的團隊為雲遷移配備了多少人員? 傳統的服務台,客戶/服務器IT或IT團隊可能不足以進行雲遷移。 如果您的團隊是雲計算的新手,那麼也許是時候考慮添加更多資源或基於專業服務的解決方案了。 如果沒有適當的見識,信息或培訓,遷移到雲可能會很繁瑣,繁瑣且困難。 您的員工是否需要納入與雲環境相關的培訓? 在尋找培訓和專業服務以協助您的IT團隊時,請與您的供應商聯繫以獲取有關可用性解決方案的培訓。 許多供應商為高可用性解決方案提供了靈活的培訓,可以通過雲供應商或諸如Udemy之類的流行站點獲得云培訓。

部署質量檢查

QA部署階段是團隊執行將實際系統部署到雲中的計劃的階段。 成功的部署團隊將驗證其計劃和策略,了解數據遷移過程,發現所有遺漏的依賴項,並為過程的下一步做準備,尤其是測試。 當跳過或跳過此步驟時,曾經有希望的遷移通常會停滯不前或失敗。 當您進入質量檢查系統部署階段時,您的團隊將繁重地進行雲中應用程序,數據庫和關鍵數據的初始遷移和配置。

測試您的高可用性

在您的質量檢查環境中進行測試是至關重要的一步。 這些測試不是浪費時間;他們節省時間。 與在本地部署相比,在雲中部署環境通常更容易。 您的質量檢查環境可以使用諸如Ansible之類的工具編寫腳本,可以作為雲市場中的模板或克隆映像快速部署,也可以根據云形成模板進行部署和構建。 部署後,可以在災難發生之前(而不是在災難發生之前)對災難場景進行熨平和優化。 可以利用測試方案來確定網絡,磁盤速度方面的過度配置,配置不足或瓶頸。 完整的測試方案也可以用作新員工入職策略的一部分。 此外,還應該對快照和備份執行測試。

部署生產

當測試階段完成並且您的團隊已驗證測試結果時,下一個階段是從質量檢查過渡到預生產,再從預生產過渡到上線。 測試階段是繁重的最後階段,涉及最終用戶驗收測試,最終生產數據的轉換和更新,然後是用戶。

審閱,修訂和重複

成功遷移到上線階段並不會結束,而是會持續到生命週期階段。 在雲遷移策略的上線階段中,您的團隊將繼續審查,修訂和重複從“收集”到“部署生產”的步驟。 實際上,您的團隊應根據特定於發行版,應用程序更新,安全更新,相關係統維護,操作系統版本,災難恢復計劃以及高可用性供應商自身最佳要求的要求來一次又一次地重複此過程。實踐。 雲平台一直在發展,並增加了可以增強您現有的HA解決方案和體系結構的新功能,新功能和更新。 審查,修訂和重複該過程將是成功入職的必要步驟。

在2021年,我們將看到更多的企業將更多的關鍵任務應用程序,ERP和數據庫遷移到雲中。 成功的關鍵因素將是利用雲遷移最佳實踐來避免整個過程中的延遲和失敗。 了解您的業務需求和需求,記錄設計和計劃,在具有特定目的的群集解決方案的QA環境中進行部署以及在上線之前執行廣泛的測試至關重要。 請與SIOS技術部門聯繫,以了解如何將SIOS保護套件包含在周到的雲遷移最佳實踐中。

-客戶體驗副總裁Cassius Rhue

轉載自SIOS

 

Filed Under: 伺服器集群简单化

新常態仍將包括高可用性

21 3 月, 2021 by Jason Aw Leave a Comment

新常態仍將包括高可用性

新常態仍將包括高可用性

大流行後世界中正常運行時間的重要性

隨著疫苗投入生產並推廣到設施和社區,公司開始為重返正常市場做準備。技術和非技術領域的許多文章和作家都預測,大流行後時代的“正常''看起來與我們2020年的“正常''有很大不同。專家們各不相同。 但是,我們完全同意,每個業務和行業類型都會看到“正常”情況的變化。這種變化將影響從學術機構到製造工廠再到金融機構再到禮拜堂的所有事物。 儘管新常態可能看起來與我們在2020年突然離開這些地方時的情況有所不同,但有些事情仍將是新常態的一部分。

2021年的新常態仍將包括高可用性的四個原因。

  • 新的數據庫和應用程序系統

預測表明,送貨上門,家庭學習,家庭娛樂乃至家庭體育館將成為未來蓬勃發展的一部分。這種繁榮將導致新的業務。 這意味著這些新業務將部署需要高度可用的雲服務和應用程序,以處理額外的在線購物。 更不用說運輸以及從製造到會計的相關服務的增長。對於這些新的業務和服務,宕機不是他們願意接受的選擇。 僅適用於基礎架構可用性的雲可用性SLA將需要使用應用程序級別的HA進行補貼。新的數據庫和應用程序系統將必須具備99.99%的可用性。

  • 現有的數據庫和應用程序系統

預計“一切在家”的繁榮發展必將導致新業務的新數據庫,應用程序和服務激增。但是,這些新業務和新貴的興起並不意味著現有公司會折疊帳篷並騰出空間。取而代之的是,新競爭者湧向各種“在家”空間的熱潮將使現有企業加強其數據庫和應用程序的緊迫性更大。在這個領域中存在的業務將需要擴展,以跟上競爭和增長。隨著它們的擴展,在過渡到雲,混合雲或眾多託管解決方案時,保持高可用性將是其現有數據庫和應用程序系統的重點。這些現有的應用程序既不會放棄當前位置的HA,也不會考慮在沒有高可用性和災難恢復的情況下以任何新的方式面對災難。

  • 物聯網管理系統

在家辦公的新企業將引發增長,要求更高的可用性。 航運業將繼續擴展並產生需要可用性的新系統。實際上,無論是否會繼續開展在家辦公的熱潮,物聯網熱潮幾乎肯定會實現。隨著越來越多的客戶在線購物並運送曾經手工交付的產品,他們將需要更多的產品幫助。 這些急切而急切的客戶將需要更多方式來跟踪和獲取包裹位置的更新。可能會添加其他檢查點,檢入中心和IoT設備作為新常態的主體。 同時,計劃將需要包括確保附加系統可靠且可用。 為客戶生成信任貨幣並為企業生成數據更為重要。

  • 停機的新原因

隨著全世界都期待著回歸“正常”,這種回歸將帶來新的挑戰和機遇。除了這些新技術之外,隨著數據庫和應用程序2021的擴展部署,將出現停機的新原因,導致災難的舊宿敵以及其他意外中斷。 應用程序-甚至那些具有更強大的監視和功能的應用程序-仍然會遇到編碼錯誤的老問題,這些錯誤會導致崩潰或集成問題,從而導致不穩定或掛起。系統(雲或內部部署)仍然容易受到硬件故障,人為故障,偶爾如此簡單的簡單維護的影響,以及諸如大自然之類的人或特權更高,知識減少的新手。帶來機遇的將是新的災難,這些災難需要對高可用性集群,解決方案和服務採取周到的方法。

是的,自2020年初關閉以來,公司的情況將會發生很多變化。 但是,任何企業回歸的新常態肯定需要高可用性。

編者註:

對於許多家庭來說,大流行後的世界將大不相同,椅子空著坐著,床不再被裝滿,笑聲和回憶以令人心痛的痛苦結束。 SIOS Technology Corp.對所有這些家庭致以最深切,最由衷的慰問,對您的失落表示深切的同情,並為您的慰藉和悲痛向他們祈禱。

–客戶體驗副總裁Cassius Rhue

轉載自SIOS

Filed Under: 伺服器集群简单化

  • « Previous Page
  • 1
  • …
  • 67
  • 68
  • 69
  • 70
  • 71
  • …
  • 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