SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

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

我是否仍應在AWS中使用Zabbix?

16 1 月, 2021 by Jason Aw Leave a Comment

我是否仍應在AWS中使用Zabbix

我是否仍應在AWS中使用Zabbix?

Amazon EC2監控

Zabbix作為集成OSS監視工具具有很高的市場份額。儘管已在內部部署環境中廣泛使用它,但仍有許多在AWS環境中使用Zabbix的示例。儘管AWS還具有Amazon CloudWatch之類的監控服務,但為什麼還要使用Zabbix?本節說明監視EC2實例和其他實例的好處以及配置過程。

為什麼使用Zabbix代替Amazon CloudWatch?

在AWS環境中,所有基礎架構均由AWS操作,但您必須負責Amazon EC2實例本身以及在Amazon EC2上構建的應用程序的操作。 換句話說,您必須監視應用程序以確保它們正常運行,並且在出現問題時必須採取措施。Zabbix是此類監視工具的不錯選擇。

Zabbix的優點是不僅可以監視本地。 而且還有云和虛擬環境的集成方式。

鑑於標準Amazon CloudWatch僅限於監視AWS資源(CPU,內存等), Zabbix允許您甚至詳細監視應用程序的狀態。

以下是Zabbix的其他優點的列表。

具有多個AWS賬戶的環境集成監控

Amazon CloudWatch在每個AWS帳戶的基礎上執行監視。Zabbix可以監視多個AWS賬戶的環境,該環境可以監視由多個賬戶組成的業務系統。它還不僅可以通過基於閾值的簡單警報來檢測異常,還可以通過組合多個閾值和條件來檢測異常。 

可以配置詳細通知以適合實際操作條件

發生異常時,Amazon CloudWatch可以通過消息通知您。例如,如果系統因維護而停機,則無需通過消息通知您。在這裡Zabbix允許您配置這些情況,從而抑制不必要的消息。這樣,您可以確保僅在確實有錯誤需要解決時才通知您。

沒有指標保留期(監視日誌)

使用Amazon CloudWatch,指標最多可以存儲15個月。此外,您只能按小時增量存儲指標15個月,並且如果將監視間隔設置為少於60秒,則最多只能存儲3小時。Zabbix允許長期存儲指標,而無需更改信息的粒度。

如何使用Zabbix監控AWS環境

如果要在AWS中使用Zabbix,則需要創建一個Amazon EC2和數據庫實例並在其上安裝Zabbix。安裝後,除了需要設置以下內容外,配置Zabbix的過程與內部部署基本相同。

  1. 用戶帳戶(除了Zabbix的Admin用戶之外,您還需要創建一個供生產使用的用戶)
  2. Zabbix主機代理(確定從何處收集數據)
  3. 項目(設置要收集的數據)
  4. 觸發(定義數據處於異常狀態)
  5. 操作(定義發生錯誤時要採取的操作)

此外,您可以配置特定於AWS的設置,例如在AWS IAM中創建具有Zabbix必要權限的用戶,這將允許Zabbix監視應用程序以及AWS環境的其他方面。

使用正確的工具來滿足您的監控需求

並非所有公司係統都是孤立運行的,但是許多系統鏈接在一起以交換數據並確保整體一致性。在這些環境中,Zabbix是監視和檢測多個服務器和系統中異常情況的絕佳工具。例如,如果基於DB的Web應用程序在Web應用程序服務器上存在異常,則可以禁用數據。

另一方面,Zabbix具有許多配置選項,因此您將必須決定監視什麼以及如何監視以及哪些情況異常。

另一方面,Zabbix有很多設置,因此您必須準確地設計操作要監視的內容,要執行的操作以及要執行的操作。 當然,對於關鍵系統來說,這樣的設計是必不可少的,但是,對於相對簡單的系統,例如“如果進程停止,只需重新啟動它”,就無法與Zabbix監視匹配。對於此類情況,SIOS AppKeeper是一個很好的解決方案,因為它可以監視在EC2實例上運行的應用程序的服務(進程),並在檢測到問題時重新啟動應用程序。 這使得簡單的監視和操作成為可能。

當然,並不是在每個系統上都必須使用Zabbix。通過為每種類型的監視使用正確的工具,您將能夠更有效地操作系統。

將SIOS AppKeeper添加到您的EC2監視和恢復操作中。

轉載自SIOS

Filed Under: 伺服器集群简单化

需要高可用性時如何選擇雲

8 1 月, 2021 by Jason Aw Leave a Comment

需要高可用性時如何選擇雲

需要高可用性時如何選擇雲

了解雲市場

許多分析公司預測,雲中應用程序,數據庫和解決方案的部署將越來越多。 根據Gartner的說法,公司“正在以越來越快的速度遷[1]移到雲中”。實際上,Gartner和其他分析師預計,雲遷移和部署的步伐將繼續加快,這在很大程度上是由於雲技術創新的步伐所推動。 在MarkoInsights的Kurt Marko發表的“技術目標”文章中,Marko指出“由於在公共雲中具有彈性,可擴展性和按需性質,因此無法在本地複制在雲中進行的創新步伐”服務。”

我們看到越來越多的公司僅將雲用於其業務非必需的DevOps應用程序和數據庫,現在正將需要高可用性保護的關鍵任務應用程序,ERP和數據庫遷移到雲中。

如果您正在考慮遷移到雲-似乎您已經遷移到雲-有幾項關鍵要理解何時需要高可用性。

熟悉雲高可用性選項

要為雲或混合雲部署計劃適當的可用性解決方案,請考慮可用性(99.9%正常運行時間)和高可用性(99.99%正常運行時間)的痛點。 您還需要了解遷移到雲的計劃,以了解可用於高可用性的選項。 著名的分析師和專家建議尋找一種解決方案,該解決方案不僅可以減輕和減輕遷移工作負載的痛苦,而且可以為您在雲體系結構的整個生命週期中提供一種平衡,全面的可用性方法。 請注意,考慮可以為一部分工作負載提供保護和高可用性的解決方案也是明智的選擇,這些工作負載有一天可能會從雲中退回到本地環境中。

在雲中比較可用性選項時,需要考慮以下十件事:

1。 部署方法。 是否可以使用映像,CLI,UI或其他可重複解決方案(例如雲形成模板或打包腳本)來部署您正在考慮的可用性解決方案。

2。 系統要求。最值得注意的是,請考慮操作系統(OS),磁盤,CPU和內存要求。

3。 部署環境。您的可用性選項僅支持本地,一個或多個公共雲,還是可以支持混合和/或混合雲部署。 還提供SaaS產品嗎?

4。 應用程序保護的廣度和深度。 “廣度”意味著可以保護哪些類型的應用程序,數據庫,前端,網絡和基礎結構組件?是否有用於添加新應用程序和變體的靈活框架? “深度”的含義–解決方案是否可識別應用程序–並能夠在整個應用程序故障轉移/故障回復過程中維護特定於應用程序的最佳實踐?

5, 性能要求。 我們經常想到RTO和RPO,但是解決方案的其他性能需求又如何呢? 您的可用性解決方案會在故障轉移時引起性能問題嗎?

6。 彈性要求。可用性解決方案可以支持多大的集群?, 它可以檢測到多少故障和故障並從中恢復。 在保持元數據同步的同時如何處理複製?

7 可維護性和維護。可用性供應商是否具有廣泛的可用性需求和配置方面的經驗? 他們是否有長壽,是否有旨在解決可能超出其解決方案的問題的支持系統? 它們可以幫助您在系統管理和維護(補丁,升級和常規維護)期間最大程度地減少中斷和計劃內的停機時間。

8。 總擁有成本。整個行業和服務都致力於幫助您計算總擁有成本,因此我們在這裡不做介紹。 可以說,您的計算對於組織,雲提供商,應用程序和IT團隊而言是唯一的。 您應該考慮可用性解決方案供應商是否可以幫助您確定節省利用率,許可和其他成本的策略? 解決方案是否可以自動執行手動任務,從而減少IT勞動時間?

9。 許可和定價模型。您如何消耗軟件成本? 是否有訂閱費,訂閱模式,隨用隨付產品,自帶許可證(BYOL)或靈活選項的組合。 您將如何啟用產品許可?是否有基於虛擬機部署詳細信息(例如地址,主機名,MAC地址)的許可證服務器,許可證服務或加密密鑰。

10。 對IT人員的影響。該解決方案需要多少培訓? 如果發生應用程序故障或災難,需要多少人工干預? 是否需要維護專用的腳本? 誰負責日常維護?

權衡利弊

像每個重要的決定一樣,您需要了解您的權衡並選擇最佳的平衡來滿足您的需求。 例如,最近我問一個朋友推荐一款好的步行鞋。 我買了一雙他喜歡的鞋-注意到它們的重量輕,織物的堅固耐用,以及時尚。我參加了他們的第一次長跑訓練,此後立即捐贈了我的第一雙“單跑”鞋。 當我去“ Fleet Feet”徵詢專家的意見時,我最終得到了更重的鞋子,更透氣的面料(也不太耐用),以及無與倫比的醜陋程度。 我在外觀和功能之間進行了權衡,以適應我的需求和預算。

就像跑鞋一樣,沒有解決方案適合所有公司,每個應用程序,每個數據庫以及每個可能的服務器和體系結構。 您可以自由地停止尋找它。 取而代之的是權衡取捨權衡活動,以確定最適合您公司需求的活動。 考慮一下您的權衡。 例如,如果您確定自己將成為一家完整的Microsoft公司,那麼在評估過程中,GCP和AWS支持的重要性應略低一些。

考慮您的IT基礎架構動態

全面考慮整個IT基礎架構(在本地和在雲中)的可用性。 最好用另一個類比解釋這樣做的原因。 2018年,我擔任南卡羅來納州哥倫比亞市一個無家可歸者和飢餓者進餐的外展計劃的協調員。 我們小組每週開會一次,為100多名男女老少提供飯食和希望的信息。 當我們考慮擴展時–增加一周中的更多天,更多小時或其他服務,我們必須考慮超出簡單的計劃要求。 知道我們正在為依賴我們的客戶提供關鍵服務後,我們必須考慮所有影響我們長期持續提供這些服務的能力的因素,例如:成本,我們團隊成員的年齡,外部義務,在母公司內部實現目標,風險因素和其他動態的替代方法。

在選擇解決方案時,在了解市場,熟悉各種選擇並權衡取捨之後,最後一步是考慮整體環境中的其他各種因素。 該解決方案能否滿足您整體業務的需求? 您的關鍵數據會受到保護嗎? 可以保護最終用戶的生產力免受停機影響嗎? 遷移到雲將需要進行哪些培訓,這將如何影響您管理或維護所選解決方案的能力? 在您的雲之旅中將添加,刪除或更改哪些IT角色?應用程序可用性的任何責任將移交給任何業務部門所有者嗎? 以及責任轉移或團隊組成將如何改善或減少您獲得成功的整體潛力。 考慮您的團隊是否需要採取逐步的方法,首先遷移較小的工作負載。

作為客戶體驗副總裁,我已經看到了各種各樣的雲遷移計劃,其中一些簡單易懂,而其他卻極具破壞性。 在一個例子中,客戶遷移到雲上引起了很大爭議,因為管理層將其視為消除整個IT部門的機會。 我並不是建議您參與政治活動,但您應該意識到這些複雜項目中的所有因素。

遷移到雲應該可以節省金錢,時間和資源,同時還可以提高可用性和彈性。 無論選擇哪種雲,請確保您考慮了這些技巧並選擇了相應的可用性解決方案,該解決方案使您可以靈活地在所需的配置中提供所需的保護。

了解有關SIOS的雲高可用性選項的更多信息。

– SIOS客戶體驗副總裁Cassius Rhue

經SIOS許可轉載

Filed Under: 伺服器集群简单化

如何以更好的結果克隆雲中的可用性

30 12 月, 2020 by Jason Aw Leave a Comment

如何以更好的結果克隆雲中的可用性

如何以更好的結果克隆雲中的可用性

電影提示–多重性

多樣性是一部1996年的美國科幻喜劇電影,由邁克爾·基頓(Michael Keaton)飾演道格·金尼(Doug Kinney)。 當一位科學家提出克隆他的建議時,道格同意只是讓實現他的時間表和承諾更加容易。 但是後來他的副本開始復制自己。 到最後一次復制時,重點已經清楚了。 克隆可能並非一帆風順,或者至少帶有一些強烈的警告,挑戰和副作用。 著名的原始《星際迷航》插曲“麻煩與瑣事”也說明了類似的觀點。

就像在大屏幕(或小屏幕)上進行克隆一樣,在雲中進行克隆是一個很好的工具,但並非沒有挑戰。

在雲中克隆可用性時如何獲得更好結果的提示

1.克隆操作系統

這聽起來很明顯,但是我已經看到它在真實的企業環境中不止一次發生。 如果克隆了無法正常運行的系統,則克隆將同樣無法正常運行,並且在還原時會出現問題。 確保您創建的克隆來自可操作和功能的系統。

2.將數據同步到磁盤並在還原時重新同步

文件系統的完整性至關重要。 如果您不確定自己的應用程序和/或VM處於一致狀態,那麼大多數供應商將無法保證所生成的映像已得到保證。 由於快照僅捕獲發出快照命令時已寫入卷中的數據,因此這可能會排除任何由任何應用程序或操作系統緩存的數據。 確保數據已正確同步到文件系統是重要的一步,在集群環境中絕對至關重要。

從映像還原時,記住文件系統完整性也很重要。 如果您正在使用數據複製並將映像還原為群集中的源或目標,則確保兩個節點同步至關重要。 否則可能會導致故障轉移或切換時文件系統出錯,甚至可能導致數據丟失。 在雲中克隆可用性以獲得所需的結果。

3.停止您的實例

許多環境不需要您停止實例來創建映像,而某些環境(例如AWS)將在製作副本之前執行關閉節點電源的步驟。但是,許多工具和站點建議確保應用程序已停止並且文件系統訪問已正確同步,以避免損壞,完整性喪失或創建啟動,停止或運行已安裝的應用程序時遇到問題的映像。

4.標記云中的所有內容(節點,磁盤,NIC等)

儘管創建克隆是一項免費操作,但生成的磁盤和組件通常不是。例如,AWS聲明“對快照收費,直到註銷映像並刪除快照為止。”如果未標記事物,則知道正在使用或未使用的東西以及創建它的原因可能會成為問題。 它還會受到短暫的記憶或現有團隊成員注意力不集中的影響。標記所有內容。

5.經常修剪克隆和快照(節省成本和減少頭痛)

修剪舊快照和克隆不僅可以節省成本,而且還可以減少麻煩。較舊的快照可能會帶來重新引入已在較新副本中解決或解決的漏洞的風險。作為SIOS Technology Corp.客戶體驗副總裁, 當我們與從快照還原的客戶一起工作時,我親眼看到了後果。 他們在重新啟動應用程序時遇到了幾個問題。 在進行故障排除之後,我們確定克隆正在運行較舊版本的安全軟件。 用戶配置文件中存儲的緩存憑據和元數據不再與存儲在外部安裝的數據驅動器上的實際應用程序數據同步。

6.限製或限制雲中克隆的克隆

最後,並不是您在雲中所做的一切都需要克隆。 考慮限制要克隆的工作負載的類型,並限制可以在環境中創建克隆的數量或角色。

在電影中,當道格的克隆人引發了自己的一系列重複時,已經不堪重負的道格(邁克爾·基頓)被迫投入更多精力來管理他的許多克隆人,同時試圖掩蓋他從妻子身上造成的混亂。 在雲中以更好的結果實現克隆可用性並不困難。 小心地進行克隆,以避免進行更多的工作,並避免使用原本可以使您的工作更輕鬆,環境更安全的工具增加風險。

–客戶體驗副總裁Cassius Rhue

轉載自SIOS

Filed Under: 伺服器集群简单化

新產品發布:適用於Linux的SIOS保護套件9.5.1

26 12 月, 2020 by Jason Aw Leave a Comment

新產品發布:適用於Linux的SIOS保護套件9.5.1

SIOS會不斷更新我們的產品,以滿足客戶不斷增長的對關鍵任務應用程序的高可用性的需求。 我們很高興宣布SIOS Protection Suite for Linux版本9.5.1全面上市!此發行功能增加了對更廣泛平台的支持,並增強了我們的命令行界面功能。

新產品發布:適用於Linux的SIOS保護套件9.5.1

關鍵更新包括

      • 支持以下操作系統和平台:VMware Vsphere 7,Red Hat Enterprise Linux(RHEL)8.2,Oracle Linux 8.2,CentOS 8.2,SUSE Linux Enterprise(SLES)12 SP5,RHEL 7.8,CentOS 7.8,Oracle Linux 7.8,SLES 15 SP2
      • CLI自動安裝和增強的設置腳本-更快,更輕鬆地實施
      • 擴展的CLI支持ARK和克隆–支持簡單,一致地部署多個集群

經SIOS許可轉載

Filed Under: 伺服器集群简单化

雲遷移停滯的六個原因

22 12 月, 2020 by Jason Aw Leave a Comment

您的雲遷移停滯的六個原因

 

 

雲遷移停滯的六個原因

越來越多的客戶正在尋求利用雲的靈活性,可擴展性和性能。 隨著做出這一轉變的應用程序,解決方案,客戶和合作夥伴的數量增加,請確保您的遷移不會停止。

避免以下六個原因導致雲遷移停滯

1.不完整的雲遷移項目計劃

人們普遍認為,項目計劃是項目成功的關鍵因素。 計劃在幫助指導利益相關者,多樣化的實施團隊和合作夥伴完成項目階段中起著至關重要的作用。 規劃可幫助確定所需目標,使資源和團隊與這些目標保持一致,降低風險,避免錯過最後期限,並最終在雲中提供高可用性解決方案。計劃不完整和計劃不完整通常是導致項目停滯的主要原因。在第九個小時,確定了關鍵依賴性。 在服務器意外重啟期間,將識別應用程序監視和HA漏洞(請參閱下文)。 確保您的雲遷移有一個計劃,然後執行該計劃。

2.在本地過度設計

“這就是我們在本地節點上做到的方式”,這是開始最近的客戶對話的短語。 當客戶嘗試遷移到雲時,他們與SIOS專業服務項目經理Edmond Melkomian進行了接觸。在一次發現會議中,Edmond能夠發現許多與內部部署和雲架構有關的過度設計的項目。 對於某些項目,複製在場所進行的操作可能會成為膨脹,複雜和延遲的簡歷。 分析您的架構和遷移計劃,並無情地消除過度設計的組件和設計,尤其是在網絡和存儲方面。

3.預留空間不足

控製成本和防止蔓延是雲遷移的重要和關鍵方面。但是,一些擔心每小時收費以及磁盤和帶寬相關成本的客戶陷入了配置不足的陷阱。在此陷阱中,資源的大小不正確,例如具有錯誤的速度特徵的磁盤,使用錯誤的CPU或內存佔用量來計算資源或具有錯誤數目的節點的群集。在這種配置不足的情況下,當用戶接受測試(UAT)開始並且預期/預期的工作負載在容量不足的資源上造成日誌阻塞時,就會出現問題。或者目標節點的成本優化無法在故障轉移方案中正確處理資源。 雖然在雲中調整虛擬機的大小是一個簡單的過程,但是在建築師和首席財務官試圖了解重新配置資源的影響時,這些大小調整問題通常會造成延遲。

4.內部IT流程

每個偉大的企業公司都有一套內部流程,您的團隊和公司也不例外。在流程中,IT流程通常是關鍵的,可能會對您的雲遷移策略的成功產生重大影響。 過去,許多公司的採購和採購流程都很漫長,包括投標,規模調整指南,訂單批准,服務器準備和配置以及最終部署。雲過程極大地改變了獲取,部署計算,存儲和網絡資源的方式。但是,如果您的流程跟不上雲的速度,那麼當計劃更改時,遷移可能會遇到障礙。

5.高可用性計劃不佳

雲遷移可能會停止的另一個原因涉及高可用性計劃。 高可用性不僅需要一捆工具或企業許可證。HA需要仔細,徹底和周到的系統設計。部署高可用性解決方案時,您的計劃將需要考慮容量,冗餘以及恢復和更正的要求。 通過計劃,可以正確識別需求,提出解決方案,考慮風險並管理部署和驗證的依賴性。 如果沒有計劃,項目和部署將容易受到風險,單點故障問題,安裝不當以及缺少應用程序保護或恢復策略的層次和級別的威脅。通常,在缺乏高可用性計劃的情況下,項目會停頓,而需求卻沒有得到解決。

6.不完整或無效的測試

羅恩(Ron)是將其最終客戶遷移到雲的合作夥伴,計劃在接下來的三天週末上線。 “執行/不執行”的最後決定點是在登台服務器上進行了一批用戶接受測試。第一次測試失敗。為了彌補由於其他遷移障礙而造成的時間浪費,Ron和團隊跳過了一些測試案例,這些測試案例與將最新的安全性和備份軟件最終集合集成到支持補丁的最新操作系統上有關。 這種模擬負載是新創建的服務器上的第一個負載,它解決了Ron體系結構中的一系列問題,包括內核錯誤,CPU和內存供應問題以及存儲佈局和容量問題。 該項目被推遲了四個多星期,以解決客戶的信心,正確的測試和驗證,調整大小和架構以及應用軟件和操作系統修復的問題。

雲的前景令人鼓舞,精心計劃的雲遷移將使您和您的團隊能夠利用這些優勢。 無論您是開始遷移還是正在進行雲遷移,我們希望本文可以幫助您更多地了解常見的陷阱,以期可以避免它們。

–客戶體驗副總裁Cassius Rhue

 

 

轉載自SIOS

Filed Under: 伺服器集群简单化

  • « Previous Page
  • 1
  • …
  • 70
  • 71
  • 72
  • 73
  • 74
  • …
  • 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