SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

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

Archives for 2月 2021

如何解决继承的应用程序可用性问题

2月 26, 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高可用性快速入门指南

2月 18, 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群集版

2月 17, 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故障转移群集实例

2月 14, 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: 服务器集群简单化

适用于Linux的SIOS Protection Suite快速服务保护

2月 6, 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: 服务器集群简单化

最近的帖子

  • (无标题)
  • 避免未预见的灾难:制定弹性灾难恢复计划
  • 增强业务连续性的最佳滚动升级策略
  • 如何不间断地打补丁:HA 带来近乎零的停机时间
  • SIOS LifeKeeper 演示:滚动更新和故障转移如何在 AWS 中保护 PostgreSQL

最热门的帖子

加入我们的邮件列表

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