SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

使用适用于Linux的SIOS Protection Suite的SQL Server高可用性快速入门指南

by Leave a Comment

 

使用适用于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

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

by Leave a Comment

宣布版本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

关于将Amazon FSX用于SQL Server故障转移群集实例

by 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是正确的选择。

转载自《星际争霸》的许可

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

by 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

如何理解和响应可用性警报

by Leave a Comment

成功的失败

休斯顿，我们有一个问题！这是一条标志性的台词，提醒无数太空迷和电影迷想起阿波罗13号太空任务的巨大难度，潜在的灾难以及危险状态，这项任务被NASA称为“成功失败”。忽略自己的应用程序可用性警报可能不会在历史上成为决定性的时刻，但也会造成类似的破坏

现在回到1970年：

“对氧气罐进行例行搅拌会点燃其内部损坏的电线绝缘层，从而引起爆炸，从而将两个服务模块（SM）氧气罐的内容物排空。 没有呼吸和发电所需的氧气，SM的推进和生命维持系统将无法运行。 必须关闭命令模块（CM）的系统，以保留其剩余的再入资源，从而迫使机组人员以救生艇的身份转移到月球模块（LM）。 随着月球着陆的取消，任务负责人努力使机组人员还活着。”

氧气罐的爆炸触发了警报，警告，压力和电压下降，通信中断，然后是宇航员与任务控制系统之间现在著名的无线电通信。但是，如果在爆炸之后机组人员什么也没做呢？ 如果他们从未检查过爆炸，从未对警告和量具做出回应，也从未告知任务控制部有问题该怎么办？如果任务控制在控制中心的仪表板上收到通知或提醒后，从未尝试提供任何帮助怎么办？如果团队把头埋在沙子里，或者为了命运和机会而辞职，却从未尝试从遇到的失败中学习，即兴发挥或改善自己，该怎么办？结果将是悲惨的！它可能是一部纪录片，但几乎没有一部具有标志性线条的大片。

在环境中触发警报时该怎么办？

A; ert

除非您当然在NASA工作，否则太空行走与我们的日常活动相去甚远，但是最近有关Apollo 13的博客确实引发了一个有关可用性的问题。当您的环境中触发警报时，您该怎么办？ 你只是忽略它吗？您是否低估它，等待警报，日志消息或其他指示符消失？您是否与供应商支持联系以了解如何禁用这些警报，警告和消息？还是说：“我们这里有问题，需要解决”？

作为SIOS Technology Corp.客户体验的副总裁，我们在警报和指示器方面都有着丰富的经验。我们与选择忽略警告的客户进行了艰苦的交流，关闭了指示问题的严重警报，这些警告的范围从应用程序阈值到网络不稳定到潜在的数据不一致。我们还看到了一些客户，他们调动了他们的警报，调查了为什么警报响起，发现了根本原因并享受了劳动成果。这种成果通常是提高稳定性，创新和学习或避免灾难的甜蜜收获。

可用性产品触发警报时您可以做的4件事

1.确定可用性警报的类型和严重性。

警报或错误是否表示警告，错误或严重问题？ 帮助您和您的团队了解关键性的一个好地方是查阅可用的文档。 检查产品文档，在线论坛，知识库文章（KBA）以及内部团队数据和流程手册。

2.评估警报的即时性。

对于警告和错误，它们有多大可能发展为严重的问题或事件。对于关键问题和警报，这可能很明显，但是即使对关键事件进行评估，也可以为您的后续步骤提供一些指导；自我更正，问题隔离或立即升级。

3.咨询其他资源。

您还可以访问其他哪些来源来确定警报条件？ 例如，如果警报与存储有关，是否还有其他工具可以揭示存储的运行状况？如果问题是网络警报，是否部署了虚拟机监控程序工具，流量工具，NIC统计信息或其他专用的监视工具来帮助进行分析。

4.联系支持。

换句话说，如果不确定，请通知任务控制。 确定类型，评估即时性并咨询其他资源之后，最好与供应商联系以寻求支持。关于API调用阈值的警告似乎是无害的。 但是，如果一旦达到这样的限制，API调用将失败，则可能导致立即采取措施。 获得专家的授权可能有助于保持内心的平静和避免灾难。

SIOS等经验丰富的供应商可以帮助您快速确定问题的原因并推荐最佳解决方案。

反复忽略可用性环境中的问题可能会导致意外的后果，但同样会带来灾难性的后果。 解决由警报，日志消息，警告指示符或其他已安装和配置的指示符指示的问题，可以在给您的客户，企业，团队和您自己带来“解决问题的机会”之前，将其变为灾难。 同时，增强您的可用性策略和基础架构。您会选择哪一个？

– Cassius Rhue，客户体验副总裁

转载自SIOS