SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

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

如何解決繼承的應用程序可用性問題

26 2 月, 2021 by Jason Aw Leave a Comment

如何解決繼承的應用程序可用性問題

 

 

如何解決繼承的應用程序可用性問題

繼承混亂時該怎麼辦

我在一個大型直系家庭中長大,在更大的一群善意的阿姨,叔叔和家人朋友中長大。曾經有一個大家庭的任何人,可能不止一次獲得過貶低的待遇,或者有好心的親戚送給您免費贈品。 如果是這樣,您就會知道,在聽起來很酷的遺產的表面之下,傳聞的時髦衣服或舊的“家庭用車”可能是一場噩夢。突然,您突然在四個輪子上發了大財,這簡直就像是一個詛咒,那是三分之二的錢坑和三分之一的眼疾。

那麼,當您繼承一堆應用程序可用性問題時該怎麼辦?好吧,一些DIYer帶來了垃圾箱並重新開始。 但這不是HGTV,我們談論的不是繼承的家具,而是繼承的應用程序可用性問題。 通常,當您第一次嘗試進行集群切換以進行簡單而有計劃的維護並且應用程序脫機時,您通常會感到一團糟。現在,當您繼承了高可用性故障後該怎麼辦。

關於繼承高可用性混亂的兩個實用技巧(我的意思是責任)

一,研究

在採取行動之前,您可能要做的最好的事情之一就是盡快收集盡可能多的數據。當然,繼承狀態可能表示收集數據的速度。在研究中應解決的一些關鍵問題以解決應用程序可用性問題:

  1. 以前的所有者。 研究配置的先前所有者,包括他們的命令鏈,權限範圍,背景,團隊動態以及(如果可能)憲章。找出什麼是原始的組織結構。
  2. 研究過去為實現更高或更高可用性所進行的工作,以及遺漏的工作。在某些環境中,高可用性的重點完全放在基礎架構的一部分上,而忽略了較大的工作流程。 挖掘任何可用需求。 以及自最初提出要求以來已實施或添加的更改。如果您正在進行雲遷移,請了解將環境遷移到雲中的目標。
  3. 所有者和需求提供了很多歷史。 但是,您還將要研究為什麼關鍵決策者會在設計和解決方案以及軟件和硬件體系結構要求上做出選擇和權衡。評估這些選擇是成功還是失敗。 您的研究應關注原始問題和建議的解決方案。
  4. 您可能還需要考慮為什麼您繼承的環境感覺很混亂。例如,是否由於缺乏文檔,培訓,設計細節不佳或缺失,缺少運行手冊或其他規格細節而導致。
  5. 研究使用什麼企業級高可用性軟件解決方案來補充虛擬機,網絡和應用程序的體系結構。 目前有任職者嗎?如果沒有,以前的可用性方法是什麼?

二。行為

收集完這項研究後,下一步就是採取行動:更新,改進,實施或替換。不要犯錯,希望您永遠不需要群集故障轉移。

  1. 升級

    在某些情況下,您的研究將使您對現有解決方案有更好的了解,並將該解決方案升級到最新版本。老實說,我們一直和我們自己的客戶一起去過那裡。轉換處理不當。 多年來無法完美運行的解決方案已經過時。

  2. 提升

    如果不需要升級,請考慮其他方法。 如果數據指向其他方面的改進,例如軟件或硬件調整,遷移到雲或混合,網絡調整或其他確定的風險或單點故障。也許您的環境需要進行運行狀況檢查,或者工作負載的增加可以確保實例大小,磁盤類型或其他參數得到改善。

  3. 實行

    在其他情況下,您的研究將發現有關缺少更高可用性策略或解決方案的一些驚人細節。 在這種情況下,您將把自己的研究作為催化劑來設計和實施高可用性解決方案。 此解決方案可能需要私有云,公共雲或混合雲體系結構以及企業級HA軟件,才能成功進行監視和恢復。

  4. 代替

    在極端情況下,您的研究將帶您完全替代當前的環境。 有時,當客戶或合作夥伴遷移到雲時,這是必需的。 但是他們的高可用性軟件產品尚未準備就緒。 儘管許多應用程序都宣稱可以支持雲,但在某些情況下,它是比實際情況更多的幻燈片軟件。您的本地解決方案還沒有準備好雲? 這樣,您唯一的解決方法就是選擇一個能夠與您一起進行雲計算之旅的解決方案,例如SIOS Protection Suite產品。

作為SIOS技術客戶體驗副總裁,我遇到了一種情況,這些情況表明了這些步驟的重要性-當我們的服務團隊與企業合作夥伴合作部署SIOS Protection Suite產品時。當我們與客戶共同合作進行研究時,我們發現了悠久的歷史。 客戶自稱存在有限的停機時間或可用性問題。 但是我們的研究表明,警報,手動執行的腳本,全局團隊以及混雜在一起的工具雜亂無章的層次結構是不可持續的。 我們能夠成功設計並使用此信息將其自製解決方案替換為更加優雅和自動化的解決方案。 最好的部分是基於嚮導的,包括自動監視,恢復和系統故障轉移保護。 沒有更多的kudge。 不再需要反複試驗的DIY。 用於HA / DR保護的簡單,可靠的應用程序故障轉移和故障回复。

如果您繼承了許多應用程序可用性問題,請與SIOS Technology Corp.的部署和可用性專家聯繫。我們的團隊將引導您完成研究過程,幫助您完善需求。 最後,升級,改進,替換或實施該解決方案,以為您的企業提供更高的可用性。

–客戶體驗副總裁Cassius Rhue

轉載自SIOS

Filed Under: 伺服器集群简单化

使用適用於Linux的SIOS Protection Suite的SQL Server高可用性快速入門指南

18 2 月, 2021 by Jason Aw Leave a Comment

使用適用於Linux的SIOS Protection Suite的SQL Server高可用性快速入門指南

 

使用適用於Linux的SIOS Protection Suite的SQL Server高可用性快速入門指南

本指南旨在說明使用用於Linux的SIOS Protection Suite的Microsoft SQL Server保護。 此處使用的環境是VMware ESXi,其中添加了運行CentOS 7.6的虛擬機。 Microsoft SQL 2017正在用於創建數據庫服務器。 數據庫和事務日誌將存儲在本地磁盤上,這些磁盤將使用DataKeeper在節點之間複製–證明共享存儲可以用作本地磁盤的簡單替代。

本指南以pdf格式提供。

下載所需的Microsoft軟件

  1. 在https://docs.microsoft.com/zh-cn/sql/linux/sql-server-linux-setup?view=sql-server-ver15中打開以下Microsoft安裝SQL指南

計劃SQL環境配置

以下配置設置將用於創建本快速入門指南描述的集群環境。 根據您的特定係統環境調整您的配置設置。

常規配置

  1. 我們在此快速入門指南中安裝的示例使用CentOS。 由於CentOS與Red Hat二進制兼容,因此適用Red Hat指令。
  2. 無論它們是在VMware環境中運行,在雲環境中還是在物理安裝中運行,本快速入門指南中的示例都非常相似。

節點1配置

  • 主機名:IMAMSSQL-1
  • 公用IP:192.168.4.21
  • 專用IP:10.1.4.21
  • / dev / sdb(10GiB)
  • / dev / sdc(10GiB)

節點2配置

  • 主機名:IMAMSSQL-2
  • 公用IP:192.168.4.22
  • 專用IP:10.1.4.22
  • / dev / sdb(10GiB)
  • / dev / sdc(10GiB)

用於SQL Access的虛擬IP

  • 168.4.20,這將受到LifeKeeper和節點之間的“浮動”的保護

操作系統

  • CentOS的7.6

SQL數據庫配置

  • SQL數據庫:
  • SQL虛擬主機名:IMAMSSQL
  • SQL虛擬IP:192.168.4.20

SQL文件系統掛載點

  • /數據庫/數據
  • /數據庫/ xlog

準備安裝系統

安裝MS-SQL

初始SQL安裝

在本節中,我們將Microsoft軟件包位置添加到我們的Linux操作系統中,然後指示該操作系統安裝SQL Server。

  1. 打開以下Microsoft指南以安裝SQL Server:
    https://docs.microsoft.com/zh-cn/sql/linux/sql-server-linux-setup?view=sql-server-ver15
  2. 以root特權登錄,或者在每個命令之前使用sudo
  3. curl -o /etc/yum.repos.d/mssql-server.repo https://packages.microsoft.com/config/rhel/7/mssql-server-2017.repo
  4. 百勝安裝-y mssql-server
  5. / opt / mssql / bin / mssql-conf設置,我使用評估許可證安裝了SQL Server
  6. yum install -y mssql-tools unixODBC-devel
  7. echo‘export PATH =” $ PATH:/ opt / mssql-tools / bin”‘>>〜/ .bash_profile
  8. echo‘export PATH =” $ PATH:/ opt / mssql-tools / bin”’>>〜/ .bashrc
  9. 來源〜/ .bashrc
  10. systemctl stop mssql-server.service,我們將停止SQL服務,並且只有在標題為“存儲”的部分中配置了用作存儲的磁盤後,才能啟動SQL服務
    “創建數據庫和事務日誌文件系統以及掛載點”
    。
  11. / opt / mssql / bin / mssql-conf設置filelocation.masterdatafile /database/data/master.mdf
  12. / opt / mssql / bin / mssql-conf設置filelocation.masterlogfile /database/xlog/mastlog.ldf

創建數據庫和事務日誌文件系統以及掛載點

我們將使用xfs文件系統類型進行此安裝。 請參閱LifeKeeper支持的文件系統類型,以確定要配置的文件系統。 確保將磁盤配置為使用GUID標識符。 在這裡,我們將對本地連接的磁盤進行分區和格式化。裝載,創建和許可我們要SQL使用的數據庫位置,最後,我們將啟動SQL,這將在我們指定的位置創建新的Master DB和事務日誌。 請注意,在創建分區時,DataKeeper要求分區中的塊數為奇數。 例如。 20973567(結束)– 2048(開始)= 20971519。

  1. fdisk / dev / sdb
  2. mkfs -t xfs / dev / sdb1
  3. fdisk / dev / sdc
  4. mkfs -t xfs / dev / sdc1
  5. mkdir /數據庫; mkdir /數據庫/數據; mkdir /數據庫/ xlog
  6. chown mssql /數據庫/; chgrp mssql /數據庫/
  7. chown mssql /數據庫/數據/; chgrp mssql /數據庫/數據/
  8. chown mssql /數據庫/ xlog /; chgrp mssql /數據庫/ xlog /
  9. vi / etc / fstab
    1. 將/ dev / sdb1安裝添加到/ database / data,例如/ dev / sdb1 / database / data xfs默認值0 0
    2. 將/ dev / sdb1安裝添加到/ database / xlog,例如/ dev / sdb1 / database / xlog xfs默認值0 0
  10. 掛載/ dev / sdb1
  11. 掛載/ dev / sdc1
  12. chown mssql /數據庫/數據/; chgrp mssql /數據庫/數據/
  13. chown mssql /數據庫/ xlog /; chgrp mssql /數據庫/ xlog /
  14. systemctl啟動mssql-server.service,既然已經安裝了本地磁盤,我們就啟動SQL服務–這將創建新的主數據庫和事務日誌

安裝LifeKeeper

請參閱安裝指南
http://docs.us.sios.com/spslinux/9.5.1/en/topic/sios-protection-suite-for-linux-installation-guide

創建LifeKeeper資源層次結構

在主節點上打開LifeKeeper GUI:

#/ opt / LifeKeeper / bin / lkGUIapp&

溝通路徑

創建後端和/或前端IP路由,在我們的示例中,後端為10.2.4.21和22,前端為192.168.4.21&22

  1. [AWS only] 右鍵單擊AWS管理控制台中的每個實例,然後選擇“網絡連接''→“更改源/目的地''。 檢查並確保源/目的地檢查已禁用。
  2. 在LifeKeeper GUI中,單擊創建通訊路徑。
  3. 在``遠程服務器''對話框中,添加其他群集節點的主機名並選擇它們。

 

  1. 選擇適當的本地(10.2.4.21)和遠程(10.2.4.22)IP地址。
  2. 重複此過程,在每個網絡的所有遠程節點對之間創建通信路徑(例如12.0.1.30和12.0.2.30)。完成後,所有群集節點對之間都應存在通信路徑。

IP資源

IP資源是將用於訪問SQL Server的虛擬IP –在這種情況下為192.168.4.20

  1. 通過運行以下命令,驗證是否已從網絡接口中刪除了所有虛擬IP。
    “ ip addr show”。
  2. 為MSSQL虛擬IP創建IP資源。
  3. 在LifeKeeper GUI中,單擊“創建資源層次結構'',然後選擇IP。

4。 出現提示時,輸入IP 192.168.4.20並選擇子網掩碼255.255.0.0。


5, 輸入標籤名稱,例如ip-192.168.4.20-MSSQL。

DataKeeper資源

這是用於存儲數據庫和事務日誌,/ database / data和/ database / xlog的驅動器

數據複製資源

  1. 確保所有SQL文件系統都已安裝在主群集節點上/ database下的適當安裝點上。
    # 山
    …
    / database /數據類型xfs上的/ dev / sdb1(rw,relatime,attr2,inode64,noquota)

/ database / xlog上的/ dev / sdc1類型xfs(rw,relatime,attr2,inode64,noquota)
…

2.確保文件系統未安裝在備份群集節點上。

3。在LifeKeeper GUI中,單擊“創建資源層次結構'',然後選擇“數據複製''。

4。 對於層次結構類型,選擇複製現有文件系統。

5, 對於“現有掛載點”,選擇/ database / data

6。 為其餘的創建對話框選擇適當的值,以適合您的環境

對/ database / data和/ database / xlog文件系統重複步驟3-6。

快速服務保護

我們將使用LifeKeeper的快速服務保護ARK保護mssql-server服務,這將監視MSSQL服務並確保其正在運行。

  1. 在節點1上使用systemctl status mssql-server.service以確保MSSQL正在運行
  2. 在節點2上使用systemctl status mssql-server.service來確保MSSQL未運行,如果正在運行,則需要使用systemctl stop mssql-server.service停止該服務,然後卸載/ database / data和/ database / xlog目錄。
  3. 在LifeKeeper GUI中,單擊添加資源
  4. 從下拉列表中選擇QSP ARK
  5. 當可用服務列表填充時,選擇mssql-server.service
  6. 為其餘的創建對話框選擇適當的值,以適合您的環境
  7. 將層次結構擴展到節點2
  8. 在節點1上的Linux CLI上,運行“ / opt / LifeKeeper / bin / lkpolicy -g –v”,輸出將類似於以下內容:
  9. 如果為QSP-mssql-server設置了LocalRecovery:On,那麼我們需要在兩個節點上都禁用本地恢復,這是通過在兩個節點上執行來完成的:
  10. / opt / LifeKeeper / bin / lkpolicy -s LocalRecovery -E標籤=“ QSP-mssql-server”
  11. 確認在兩個節點“ / opt / LifeKeeper / bin / lkpolicy -g –v”上均禁用了本地恢復:

轉載自SIOS

Filed Under: 伺服器集群简单化 Tagged With: 安裝

版本8.7.2 SIOS Protection Suite-Windows和DataKeeper群集版

17 2 月, 2021 by Jason Aw Leave a Comment

SIOS Protection Suite的8.7.2版-Windows和DataKeeper群集版

宣布版本8.7.2的SIOS Protection Suite-Windows和DataKeeper Cluster Edition

我們很高興宣布發布適用於Windows的SIOS Protection Suite 8.7.2版,包括DataKeeper Cluster Edition。新版本具有以下功能:

新的Oracle可插拔數據庫(PDB)應用程序恢復工具包

  • 在Oracle 19c上建議使用Oracle Pluggable Database,而從Oracle 20c起則需要使用Oracle Pluggable Database
  • SIOS Protection Suite PDB應用程序恢復工具包不需要其他SIOS許可證,但是需要現有的Oracle資源。

支持其他平台和操作系統,包括:Azure Stack(Hub)(包括Windows Server 2019),vSphere 7和PostgreSQL 12。 有關我們支持的產品的完整列表,請訪問SIOS Protection Suite-Windows 8.7.2支持矩陣。

轉載自SIOS

Filed Under: 伺服器集群简单化

關於將Amazon FSX用於SQL Server故障轉移群集實例

14 2 月, 2021 by Jason Aw Leave a Comment

關於將Amazon FSX用於SQL Server故障轉移群集實例

使用Amazon FSX進行SQL Server故障轉移群集實例-您需要了解的知識!

如果您正在考慮在AWS EC2中部署自己的Microsoft SQL Server實例,則需要就解決方案的彈性做出一些決策。 當然,如果您在不同的可用區域中部署兩個或更多實例,AWS將為您的Compute資源提供99.99%的SLA。 但不要上當,在計算真正的應用程序可用性時,還需要考慮許多其他因素。 我最近在博客上發表了有關如何在雲中計算應用程序可用性的博客。 在繼續之前,您可能應該快速閱讀該文章。

在確保Microsoft SQL Server實例高度可用時,它實際上可以歸結為兩個基本選擇:始終可用性組(AG)或SQL Server故障轉移群集實例(FCI)。 如果您正在閱讀本文,則假定您對這兩個選項都非常了解,並正在認真考慮使用SQL Server故障轉移群集實例而不是SQL Server Always On AG。

Microsoft SQL Server故障轉移群集實例的好處

以下列表總結了AWS所說的是SQL Server FCI的優點:

當以下是您使用案例的優先考慮因素時,對於SQL Server高可用性部署,FCI通常比AG更可取:

許可證成本效率:運行AG所需的是SQL Server的企業版許可證,而運行FCI的僅需Standard Edition許可證。 它通常比企業版便宜50–60%。 儘管您可以從SQL Server 2016開始在Standard Edition上運行AG的基本版本,但它的局限性在於每個AG僅支持一個數據庫。 在處理需要多個數據庫(例如SharePoint)的應用程序時,這可能成為一個挑戰。

實例級保護與數據庫級保護:使用FCI,可以保護整個實例-如果主節點不可用,則將整個實例移到備用節點。 這將照顧存儲在系統數據庫中的SQL Server登錄名,SQL Server代理作業,證書等,這些數據庫實際上存儲在共享存儲中。 另一方面,使用AG,只能保護組中的數據庫,並且不能將系統數據庫添加到AG中-僅允許用戶數據庫。 數據庫管理員負責將更改複製到所有AG副本上的系統對象。 這留下了人為錯誤的可能性,導致數據庫無法被應用程序訪問。

DTC功能支持:如果您使用的是SQL Server 2012或2014,並且您的應用程序使用分佈式事務處理協調器(DTC),則您將無法使用AG,因為它不受支持。 在這種情況下,請使用FCI。

https://aws.amazon.com/blogs/storage/simplify-your-microsoft-sql-server-high-availability-deployments-using-amazon-fsx-for-windows-file-server/

雲中FCI面臨的挑戰

當然。 建立跨越可用性區域的FCI的挑戰是缺少通常需要的共享存儲設備。 因為群集的節點分佈在多個數據中心,所以傳統的SAN對於共享存儲來說不是可行的選擇。 這為集群存儲留出了兩個選擇:第三方存儲類資源,例如SIOS DataKeeper或新的Amazon FSx。

讓我們來看看您做出選擇之前需要了解的內容。

服務水平協議

正如我在如何計算應用程序可用性中所寫的那樣,您的整體應用程序SLA僅與最弱的鏈接一樣好。 在這種情況下,FSx SLA為99.9%。

通常99.99%的可用性代表著“高可用性”的起點。 這是當兩個或多個部署在不同的可用區域中時,AWS向您承諾的計算資源。

萬一您不知道三個九與四個九之間的區別…

  • 99.9%的可用性每月允許停機43.83分鐘
  • 99.99%的可用性每月僅允許停機4.38分鐘

儘管您具有99.99%的計算可用性,但是通過將群集存儲託管在FSx上,您的整體應用程序可用性將達到99.9%。 相比之下,跨越可用性區域的EBS卷(例如在DataKeeper部署中)在存儲和計算層均符合99.99%的SLA。 這意味著您的整體應用程序可用性為99.99%。

存儲位置

為高可用性配置FSx時,您將需要啟用多可用區支持。 通過啟用多可用區,您可以有效地擁有“首選”可用區和“備用”可用區。 部署SQL Server FCI節點時,您將希望將這些節點分佈在相同的可用區中。

現在,在正常情況下,您將需要確保活動群集節點與首選FSx存儲節點位於相同的可用區中。 這是為了最大程度地減少存儲距離和延遲。 而且還可以最大程度地減少與跨可用區進行數據傳輸相關的成本。 根據FSx價格指南中的規定,“標準數據傳輸費適用於AZ之間或區域間對文件系統的訪問。”

在不幸的情況下,如果您遇到SQL Server FCI故障,但沒有FSx故障,則沒有將存儲和計算結合在一起的機制。 如果FSx進行故障轉移,它將自動故障恢復到主要可用性區域。 但是,最佳實踐指示SQL FCI仍在輔助節點上運行,直到執行根本原因分析並且通常計劃在維護期間進行故障回复。 這使您處於存儲位於其他可用區的情況,這將產生額外的費用。 當前,跨可用區和入口的數據傳輸成本為$ 0.01 / GB。

如果不密切關注FSx和SQL Server FCI的狀態,您甚至可能都不知道它們在不同的區域中運行,直到您在月底看到數據傳輸費用為止。

相反,在使用SIOS DataKeeper的配置中,存儲故障轉移是SQL Server FCI恢復的一部分,從而確保存儲始終通過SQL Server實例進行故障轉移。 這樣可以確保SQL Server始終在讀寫直接連接到活動節點的EBS卷。 請記住,DataKeeper將產生與在AZ或區域之間複製的寫操作相關的數據傳輸成本。 通過使用DataKeeper中可用的壓縮,可以將這種數據傳輸成本降到最低。

控制故障轉移

在FSx多子網配置中,存在首選的可用性區域和備用可用性。 如果首選可用性區域中的FSx文件服務器出現故障,備用AZ中的文件服務器將恢復。 AWS報告說,使用標準共享時,此恢復時間大約需要30秒。 通過使用連續可用的文件共享,Microsoft報告此故障轉移時間可以接近15秒。 在此故障轉移時間內,將在讀取和寫入暫停的情況下發生電源不足,但是一旦恢復完成,該電源將繼續。

FSx多站點已啟用自動故障回复。 這意味著,對於FSx的每個計劃外故障轉移,您還將具有計劃外的故障回复。 相反,通常,當SQL Server FCI經歷計劃外的故障轉移時,您要么只是使其在輔助服務器上運行,要么計劃在幾個小時後或下一個維護期間進行故障回复。

FSX不支持SQL Server Analysis Services群集

如果要群集SSAS,則需要群集磁盤資源,例如SIOS DataKeeper。 如何群集SQL Server Analysis Server白皮書明確指出無法使用SMB,並且必須使用帶驅動器號的群集驅動器。 相反,DataKeeper卷資源將其自身顯示為群集磁盤,並且可以與SSAS一起使用。

概括

雖然FSx對於Windows用戶文件和其他非關鍵服務等典型的SMB使用肯定是有意義的,其中SLA滿足99.9%的可用性,但如果您的應用程序要求高可用性(99.99%)或還具有高可用性的HA / DR解決方案,則FSx是一個不錯的選擇區域,SIOS DataKeeper是正確的選擇。

轉載自《星際爭霸》的許可

Filed Under: 伺服器集群简单化 Tagged With: SQL Server故障轉移群集實例

適用於Linux的SIOS Protection Suite快速服務保護

6 2 月, 2021 by Jason Aw Leave a Comment

如何向SIOS Protection Suite添加自定義應用程序支持-適用於Linux的SIOS Protection Suite快速服務保護

使用SIOS Protection Suite for Linux快速服務保護資源

在最近與SIOS專業服務團隊的合作中,一位客戶詢問如何使用SIOS Protection Suite for Linux解決方案保護自定義應用程序。 SIOS Technology Corp.一位經驗豐富的高可用性專家之一,幫助理解了客戶的應用程序,並列出了SIOS提供的用於自定義應用程序支持的方法。

適用於Linux的SIOS Protection Suite提供了多種向自定義應用程序添加高可用性和應用程序監視的方法。這些選項包括:

  • 創建自定義應用程序恢復工具包(ARK)1
  • 創建通用應用程序資源層次結構
  • 創建快速的服務保護資源
類型 編碼複雜度 監控方式 復甦
自定義應用程序恢復工具包Resource1 最高 最高 最高
通用應用程序資源 中 高 高
快速服務保護資源 低 中 中

圖表中使用的定義

監視-定義確定受保護的應用程序,數據庫或服務的可用性,可訪問性和功能的能力。較低級別的應用程序,數據庫或服務監視提供了基本的覆蓋範圍,例如,檢查正在運行的進程,是否存在pid_file或狀態命令在執行時返回“ true”結果。注意:返回值為``true''或“0(零)''並不表示該應用程序,數據庫或服務正在運行。 但是只有執行的命令才能成功完成狀態為正(“true''或“0(零)'')的結果。最高級別的監視表明,除了較低級別的方法(例如進程狀態,ps輸出或systemd狀態返回)外,還應用了特定於應用程序的知識來確定應用程序的運行狀況和功能。最高級別的監視通常會應用有關運行狀況檢查操作的建議順序的知識,相關性的知識以及對從狀態和監視命令獲得的結果的分析。

恢復-定義為重新啟動失敗的應用程序,數據庫或服務的能力。低級別的恢復能力意味著發出了用於重新啟動的命令,並且從命令的發出中獲得了預期的輸出。最高級別的監視指示特定於應用程序的知識用於確定如何啟動應用程序,數據庫或服務的有序重新啟動,這可能需要了解操作的建議順序,依賴項,回滾或對失敗的其他相關補救措施服務。

解決方案:快速服務保護資源

在這種參與中,客戶的應用程序具有系統兼容性。 基於避免編碼的總體要求,最少的監視需求和簡單的恢復過程,我們建議使用快速服務保護(QSP)資源。

QSP資源的工作原理是為Linux資源保護的SIOS Protection Suite快速添加對systemd服務的支持。對於Customer Example.com,他們具有系統兼容的服務,並且具有啟動和停止其應用程序所需的最低要求。

[Unit]

Description = SIOS“現狀”示例服務2020

之後= network.target

類型=簡[Service]單

重啟=總是

RestartSec = 3

用戶= root

ExecStart = / example_app / bin / exampleapp開始

ExecStop = / example_app / bin / example[Install]app停止

WantedBy =多用戶目標

Example.com systemd文件

SIOS建議在嘗試使用適用於Linux的SIOS Protection Suite進行資源保護之前,請通過systemctl驗證示例應用程序已停止並相應地啟動:

#systemctl狀態示例

* example.service – SIOS“現狀”示例服務2020

已加載:已加載(/usr/lib/systemd/system/example.service;已禁用;供應商預設:已禁用)

有效:無效(無效)

#systemctl啟動示例

#systemctl狀態示例

* example.service – SIOS“現狀”示例服務2020

已加載:已加載(/usr/lib/systemd/system/example.service;已禁用;供應商預設:已禁用)

活動:自星期五2020-08-21 14:53:27開始活動(運行); 5秒前

主PID:19937(exampleapp)

CGroup:/system.slice/example.service

-19937 / usr / bin / perl / example_app / bin / exampleapp開始

#systemctl停止示例

#systemctl狀態示例

* example.service – SIOS“現狀”示例服務2020

已加載:已加載(/usr/lib/systemd/system/example.service;已禁用;供應商預設:已禁用)

有效:無效(無效)

在通過systemd驗證應用程序正常運行後,重新啟動服務並確保服務正在運行。

#systemctl啟動示例

#systemctl狀態示例

* example.service – SIOS“現狀”示例服務2020

已加載:已加載(/usr/lib/systemd/system/example.service;已禁用;供應商預設:已禁用)

活動:自星期五2020-08-21 15:59開始活動(運行); 3min 2s前

主PID:30740(exampleapp)

有關資源創建過程的更多詳細信息,請參閱適用於Linux的SIOS Protection Suite快速安裝保護套件文檔。

使用SPS-L UI選擇“創建”選項,在“全局UI資源工具欄”中通過以下圖標指示SIOS全球美國資源:

啟動創建嚮導後,在“創建資源嚮導”窗口中選擇“快速服務保護”選項。

在下一個提示“Switchback Type''的提示中,選擇使用智能切回還是自動切回。

選擇“切回類型''後,將出現``服務器''對話框,允許您選擇自定義應用程序的主服務器。

(注意:如果服務需要存儲,請確保選擇先前為存儲資源選擇的同一主服務器。)

在“服務名稱”對話框中,找到自定義應用程序的服務。

例如,選擇正確的服務後,確定要啟用監視還是禁用監視服務。請參閱文檔以了解QSP資源提供的監視。2

接下來,選擇一個資源標籤。資源標籤應該是一個有意義的名稱,它將幫助您的IT團隊快速確定哪種SPS-L資源可以保護您的應用程序或服務。

最後,按照最後的對話完成資源創建過程。創建資源後,使用UI將資源擴展到其他服務器。 如有必要,請在新保護的自定義服務/應用程序與任何其他所需資源(例如存儲或IP資源)之間創建依賴關係。


筆
記:

1可以通過與SIOS Technology Corp.專業服務團隊合作來創建客戶應用程序恢復工具包。欲了解更多信息,請聯繫professional-services@us.sios.com

2 QSP恢復工具包quickCheck只能執行簡單的運行狀況(使用service命令的“ status”操作)。 QSP不保證提供服務或過程正常運行。 如果需要復雜的啟動和/或停止操作,或者需要進行更強大的運行狀況檢查操作,則建議使用通用應用程序或自定義應用程序ARK

轉載自SIOS

Filed Under: 伺服器集群简单化

  • « Previous Page
  • 1
  • …
  • 54
  • 55
  • 56
  • 57
  • 58
  • …
  • 98
  • Next Page »

最近的帖子

  • 如何評估我的網路卡是否需要更換
  • 與高可用性相關的應用程式智能
  • 在 Nutanix 環境中選擇高可用性解決方案的 10 個注意事項
  • 我的伺服器是一次性的嗎?高可用性軟體如何適應雲端最佳實踐
  • 災難頻傳世界的資料復原策略

最熱門的帖子

加入我們的郵件列表

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