高度可用还是高度脆弱？ 高可用性清单

高度可用还是高度脆弱？ 高可用性清单

各种规模的企业对 IT 系统的需求都在不断增长，这已不是什么秘密。 但是，只有当 IT 系统具有可操作性、弹性和高可用性时，它们才对这些企业及其客户有效。 当企业希望扩大其企业可用性时，拥有衡量和评估漏洞的基线可能会产生成功合并基础架构、软件、服务和支持的差异，从而提高您的成功率。

有时，最基本的清单可以帮助您确定您的解决方案是高度可用还是高度易受攻击？

您的组织是否有适当的基础设施来支持高可用性?

• 您的数据中心是否安装了环境传感器来测量建筑系统？
• 您的数据中心是否有 24x7x365 全天候运营？
• 您的数据中心是否包括来自不同来源的冗余电源和网络连接？
• 您的数据中心是否包含多层主机和存储服务？
• 作为客户体验副总裁，我看到客户试图创建一个高度可用的解决方案，而没有解决其基础架构中的基本问题。

他们部署软件，但在网络基础设施、服务器和数据中心本身内部存在不稳定性。 云解决了许多基础架构问题，但并非所有云平台的架构都相同。 请务必了解您的数据中心、本地或云。

您的组织是否有涵盖设计、架构和流程的运行手册（或剧本）？

• 您的操作手册是否有据可查、公开且易于访问？
• 运行手册的常规部分是否足够自动化？
• 谁有权访问您的企业操作手册？
• 它是最新的和当前维护的吗？
• 您的运行手册和其中的任何自动化工具是否有版本控制？

如果您回答了什么是 Runbook 或 playbook，那么您的第一步就是找到或创建一个。 运行手册（或剧本）可帮助您的组织维护与高可用性系统架构相关的系统和流程。 一些公司使用自动化工具来创建部署和配置服务器的脚本，其他公司使用版本控制文档来概述所有事物如何协同工作以提供弹性和成功。 您的团队需要有一个新人和现有团队成员可以去了解环境、流程和正在使用的工具的地方。

您的组织是否拥有专门用于维护高可用性最佳实践的资源？

• 您的组织是否为这些员工和承包商提供支持和培训？
• 您的组织是否赋予这些团队自主权以适应和创造更好的最佳实践？

“我没有设置这些系统，”IT 管理员说，“我只是用其他一些服务器继承了这些系统。”哀叹是组织中一种诚实且经常观察到的现象。 无论是并购、成本削减、外包还是一般人员流动的结果，高可用性企业的一个关键组成部分是足够的人员配备。 一个高度脆弱的企业的一个关键是人员不足、训练不足或支持不足。

您的组织是否有适当的变更管理控制措施？

• 您是否有定期更新政策和时间表？
• 您是否有明确的补丁维护流程？
• 您是否有针对补丁（漏洞、威胁等）的审核流程？

变更管理很重要。 变更管理控制和政策对于降低风险和确保您的系统可用是绝对必要的。 没有适当限制的用户可以添加破坏稳定性的包或更新，或进行破坏组织数小时的更改。 此外，没有明确的政策通常会在预期（记录）和实际（现有）之间产生偏差。 变更管理对于确保备用集群与主/源系统处于相同的补丁和软件级别以及确保 QA（或预生产）不会严重偏离生产环境也至关重要。

您的组织是否有适当的访问控制？

• 您是否有用于服务器管理的帐户管理层？
• 您是否有防止意外停机的控制措施？

我们的服务团队加入了客户呼叫并等待、等待、等待有权运行一组提升命令的管理员加入会话以配置和更新他们的软件。 几周后，我们的团队加入了一个不同的客户电话会议，并惊恐地看到多个具有管理权限的用户在同一个集群上运行了一系列命令。 两次调用的差异清楚地指出访问控制很重要。 高可用性企业需要确保适当的访问控制到位，以防止用户运行可能损坏配置或削弱其操作的提升命令。 确保用户根据他们的角色、需求甚至经验限制他们可以做什么。

贵公司是否有定期的测试流程？

• 您的组织是否在生产前在预生产或 QA 环境中进行测试？
• 您的组织是否执行定期备份和备份测试？
• 您的组织是否实施灾难恢复方案和混沌测试以实现持续改进？

测试需要时间，但我的职责是帮助客户完成他们的云迁移和高可用性部署，时间一直都花得很好。 通常，高可用性和易受攻击之间的区别可以归结为客户或合作伙伴的测试过程。 随着解决方案变得越来越复杂，测试和验证对于降低风险和漏洞变得越来越重要。 如果一切都从设计到生产，那么您正在运行一个高度易受攻击的系统。 但是，如果您有测试和检查点，那么在将更改投入生产之前验证更改的过程会大大降低您的风险。 作为客户体验副总裁，我们的服务团队与一位重要客户合作，该客户在完成上线迁移之前在 QA 中部署了整整一年的系统。 在那一年，他们模拟了中断、灾难、客户负载、停机时间、维护、修补策略、备份、从备份中恢复，以及一系列其他测试套件。 因此，它们在性能、流程遵从性、高可用性和企业成功方面取得了显著成果。

虽然没有清单能够涵盖高可用性中的每个潜在漏洞，但回答这些问题将为您了解您的企业是高可用性还是高度易受攻击奠定坚实的基础。

经授权转载西欧

Disney's Encanto – 关于高可用性、IT 团队和停机时间的课程

迪士尼 Encanto 中关于高可用性、IT 团队和克服停机时间的课程

周末，我加入了收看迪士尼 Encanto 并成为这个故事的粉丝、课程和机会的学生以及 Lin-Manuel Miranda 的绝对粉丝的人群中。 迪士尼的 Encanto 在高可用性、集群和弹性方面提供了什么？

课程高可用性，IT 团队，并从迪士尼的 Encanto 中克服停机时间[Warning: movie spoilers ahead]在 Encanto 中，您很快就会了解到 Family Madrigal 是一个特殊的家庭。 在其中一首开场歌曲“The Family Madrigal”中，我们了解到所有家庭成员都有独特而特殊的天赋；超人的力量，听数英里的能力，预言和预测，召唤美丽花卉和植物的能力，变形的能力，治愈的能力，以及控制天气的能力。 好吧，似乎每个人都有“礼物”，除了米拉贝尔。

第 1 课：你不需要超人的天赋才能有所作为。

米拉贝尔虽然不像其他兄弟姐妹和家庭成员那样有天赋，但却是了解家庭健康和疾病的核心人物。 此外，她能够帮助家人在一切都崩溃时将事情重新组合起来，而无需其他礼物。 您需要高可用性，但您不必打破预算、开发超自然能力或依靠奇迹来实现它。

随着电影的继续，佩帕的小儿子安东尼奥已经准备好参加他的礼物仪式。 然而，在聚会和庆祝活动期间，Abuela 注意到 Casita 的地基出现裂缝。 但她的警告无人理会。

第 2 课：不要忽视裂缝。

当米拉贝尔看到裂缝时，她开始寻求找出危及卡西塔的原因以及她可以如何提供帮助。 起初，她被其他人忽视甚至斥责。 如果您发现您的 IT 基础设施存在裂缝或缺陷，或者您的架构和设计存在裂缝，您将如何应对？ 你会忽略这些裂缝，假装没有看到它们，甚至责备团队发现它们吗？ 不要忽视裂缝。 响应问题的第一个迹象通常是防止更大问题的完美方法。

在她寻求答案并拯救奇迹的魔法的过程中，多洛雷斯让米拉贝尔与她超级强壮的姐姐路易莎交谈，路易莎最初表示一切都很好，绝对没有错。 但路易莎最终开始透露，知道有一个人的重量对她来说变得太大了。

第 3 课：HA 的重量对于一个人或一个团队来说太大了。

正如路易莎所说，“压倒骆驼的是压力，是永不停息的压力。”。 开发高可用性解决方案、设计和架构弹性和数据可用性并不是一个简单的过程，而且绝对不是一个人或单个团队的任务。 您的 DBA、IT 管理员和 ERP 管理员无法独自承担维护关键企业可用性的重任。 同样，一维方法不能承载四 (4) 个 9 的可用性。 相反，它需要一个完全一致的团队与完整的 HA 解决方案协同工作，以理解、设计、开发和部署工具和技术。 您的 IT 团队的角色和职责分布和定义如何？ 确保没有人独自承担 HA 的责任。

当米拉贝尔向布鲁诺寻求她正在寻找的答案时，每个人都说：“我们不谈论布鲁诺。”布鲁诺的天赋是预知，但由于他的警告和看似消极的愿景，他消失了。

第 4 课：不要害怕看到前方麻烦的人。

作为客户体验副总裁，我帮助客户对其基础架构和集群解决方案进行健康评估。 运行状况检查完成后，并非所有客户都乐于听到他们有问题需要解决。 我们都尽我们所能避免坏消息。 但是，忽略升级、忘记维护以及淡化团队布鲁诺发现的风险不会让问题消失。 事实上，它可能会让你最担心的事情成为现实。

米拉贝尔最终找到了一条通往布鲁诺的秘密通道，发现布鲁诺从未离开，但觉得他必须破坏她的视力来保护她和他自己。

第 5 课：企业文化可以压制或创造更高的可用性

您的文化可以粉碎或创造更高可用性和弹性的空间。

米拉贝尔问布鲁诺是否一直在修补小屋的裂缝，但布鲁诺回答说他害怕裂缝。

第6课：不要害怕裂缝

HA 需要持续、协调的持续努力。 这项工作的一个重要部分是为那些可能危及您的应用程序或架构与执行之间的差距的 IT 漏洞找到解决方案和修复程序。

即使布鲁诺（或埃尔南多）试图修补裂缝，很明显基础问题对于散乱和肤浅的解决方案来说太多了。

第 7 课：Spackle 无法解决基本问题

查看您的基础架构并查看解决问题的方式。 您是在部署变通办法、创可贴和临时“黑客”，还是在寻找解决集群、企业可用性和灾难期间执行问题的根本原因的架构和基础解决方案？

第 8 课：找到你的 Jorge

如果您一直在部署比根本原因解决方案更多的黑客和变通方法，请找到您的 Jorge。 寻找熟练的团队成员、合作伙伴或解决方案提供商，并允许他们努力实施能够解决问题或加强基础设施的基础解决方案。

布鲁诺看到了另一个愿景，即如果 Mirable 拥抱 Isabela，Casita 就可以得救。 Mirabel 为 Isabela 提供了一个开花的机会，但 Abuela 不这么看。 Mirabel 和 Abuela 之间发生争执，Abuela 将“Casita”中的裂缝归咎于 Mirabel。 Mirabel 指责 Abuela 提出了不可能的要求、不切实际的期望和错误的希望。

第 9 课：责备会产生更多问题

Pass the Blame 是一款很棒的派对游戏，但它对于 HA、集群弹性或数据保护来说并不是很好。 我曾经帮助过一个客户，他的组织说明了责备是徒劳的。 在概念验证集群遇到导致延迟的问题后，项目经理将延迟归咎于应用程序团队。 应用程序团队责怪备份管理员，后者又责怪基础设施管理员。 在整个指责过程中，他们的集群仍然不可用，概念验证仍然停滞不前，唯一取得的进展是团队之间的愤怒裂缝越来越大。 只有当他们将这些差异放在一边时，他们才能做出解决问题所需的调整并继续成功的 POC。

“小屋”倒塌，米拉贝尔逃跑。 后来，阿尔玛找到了米拉贝尔，和解后，他们和家人和村庄一起建造了比以往更好的小屋。

第 10 课：将其重建得更强大

当然，Encanto 的最后一幕充满了 Alma (Abuela) 忏悔的教训，例如：

1. 不要隐藏你所看到的或忽略裂缝
2. 对重要的人（或者在你的情况下是团队和业务）说实话
3. 建立一种文化，让他人超越他们的角色或天赋
4. 尽早寻求（并接受）帮助
5. 痛苦不需要成为监狱
6. 领导者有能力将人们聚集在一起或将他们推开

但最后一课中最重要的是重建得更好、更强大、更团结。 在每次计划外或计划内的停机之后，都会从根本原因分析、经验和新的理解中吸取教训。 因此，还将有机会为您的高可用性和灾难恢复构建更强大的解决方案和架构。

考虑一个客户在发现中断是由直接部署到生产环境的代码导致后能够创建标准部署管道和 QA 系统的案例。 或者另一位客户发现磁盘和数据库警告在中断前被抑制了数周。 不要浪费停机时间带来的时间和机会。 一定要共同努力，避免孤岛、对单一优势的依赖，或者将基础设施的希望寄托在错误的事情上。

当然，您应该自己观看整部电影，但当您了解电影的魔力和音乐并了解其他几个角色的生活和教训时，HA 会有更多的教训

• 卡米洛：适应性强且灵活
• 路易莎：力量是好的，但不要否认你感到软弱和脆弱的地方
• 佩帕：你可以控制自己的态度和行为
• 多洛雷斯：倾听一切，但也要采取行动
• 布鲁诺：如果你热爱你的工作，你会一直寻找解决方案
• 伊莎贝拉：它不一定是完美的工作。 HA 是一场持续的战斗：设计、开发、测试、部署、重复
• 喝咖啡的孩子：喝太多咖啡对你不好
• Mirabel：你需要一个有希望和远见的人才能成功
• 阿尔玛：不要浪费你的第二次机会，也不要忽视真正重要的事情

电影以重聚结束，米拉贝尔和牧歌站在完工的房子前。 当米拉贝尔触碰门把手时，“小屋”就恢复了生机，家和家人的神奇礼物都回来了。 试试 Encanto 的这 10 节高可用性课程，欣赏这部电影，并记住“没有什么是您不能做的……与您的客户、合作伙伴、解决方案提供商和管理员团队一起”。

如何激活 SIOS Protection Suite for Linux 的许可证

如何激活 SIOS Protection Suite for Linux 的许可证

既然你已经获得了你的适用于 Linux 软件的 SIOS 保护套件，您将需要激活您的许可证。这个 7 分钟的视频将帮助您入门。 它会引导您完成开始运行 SIOS Protection Suite for Linux 软件所需的所有步骤。观看 SIOS 支持代表演示安装 SIOS 许可证所需的步骤：如何插入授权/激活 ID、如何获取和插入主机 ID，以及下载激活文件。

该视频说明了在何处访问软件以供下载、如何从购买或试用的权利中查看和验证主机名和 ID，以及如何下载包含在您的欢迎电子邮件中的激活文件以完成该过程。 您还将学习如何访问我们的SIOS 文档门户网站，您可以在其中找到有关 SIOS Protection Suite for Linux 的发行说明、安装指南、技术文档和深入信息，以及每个 SIOS 产品的广泛主题。

接收有关如何快速轻松地完成这些步骤的有用提示和方便的见解。 了解开始运行 SIOS Protection Suite for Linux 是多么简单。

如何激活 SIOS Protection Suite for Linux 的许可证

如何为 Linux 许可证密钥安装 SIOS 保护套件

如何为 Linux 许可证密钥安装 SIOS 保护套件

一旦你安装了适用于 Linux 软件的 SIOS 保护套件并已激活您的许可证，您需要先安装许可证密钥，然后才能开始运行它。 这个 4 分钟的视频将回顾如何安装 SIOS Protection Suite for Linux 软件，并演示如何激活您的许可证以开始使用您的 SIOS Protection Suite for Linux 软件。

观看 SIOS 支持代表向您展示如何检查您的 SPS 映像文件是否已安装，以确保您拥有许可证文件，以及如何安装和输入完整的路径名。 使用我们简单的许可证密钥管理器来验证您的激活的许可证从购买的权利中下载并应用许可证密钥并启动您的 SIOS Protection Suite for Linux 软件。

该视频还介绍了如何访问我们的SIOS 文档门户，您可以在其中找到详细说明 SIOS Protection Suite for Linux 的发行说明、安装指南、技术文档和信息，以及有关 SIOS 的各种主题。

查看有关如何快速简单地完成步骤的提示和方便的见解。现在，您可以开始使用 SIOS Protection Suite for Linux 保护您的关键应用程序。

如何为 Linux 许可证密钥安装 SIOS 保护套件

如何使用高可用性集群消除云中的单点故障

如何使用高可用性集群消除云中的单点故障

在提供高可用性保护时，一般原则是确保所有组件都是冗余的，以避免单点故障 (SPOF)。 也就是说，确保没有单个元素导致整个系统在失败时停止。 但是，需要注意的是，运营基础设施很难在公共云中访问。

在一个基于云的高可用集群，备用节点有可能位于同一主机服务器上，在同一机架中，并使用与操作节点相同的网络交换机。 除非您使用冗余配置这些元素，否则它们中的任何一个都可能是 SPOF 并使应用程序面临灾难性故障的风险。

有必要确保集群节点位于不同的云“区域”和“可用区”上，这些“区域”和“可用区”将数据中心和运营基础设施物理隔离在不同的地理位置。

确保可用性的主要原则是什么？

您不能期望构成物理 IT 基础架构的各种组件永远按照规范运行。 零件磨损，系统变得不兼容，设置发生变化。 尽管定期维护可以降低停机风险，但在产品生命周期中可能会出现故障。

在极少数情况下，您可能会在操作系统或嵌入式软件中发现一个严重的错误，导致应用程序停止工作。

您可能已经注意到，High Availability 集群配置正是符合这一原则，通过将重要服务器及其资源冗余到活动系统（生产系统）来消除单点故障。 但是，重要的是要记住两件事。 一，服务器硬件不是唯一的关键组件。 第二点，在公共云基础架构中，您可能看不到其他关键的 SPOF 组件。

谨防隐藏在云的无形基础设施中的单点故障陷阱

大多数公共云以所谓的“多租户”模式运行。 也就是说，它们在同一物理主机服务器上运行多家公司的虚拟机。 对于常规合同，您无法指定您的系统在哪个主机服务器上运行。 这可能会导致问题，因为云集群中的备用节点可能放置在运行活动节点的同一主机服务器上。 即使配置了 HA 集群配置，如果主机服务器宕机，运行节点和备用节点也会同时宕机。 在这种情况下，您的云运营商决定何时以及如何恢复您的系统。

运行活动节点的主机服务器和运行备用节点的主机服务器可以在同一个机架中。 在这种情况下，机架变成了 SPOF，因此如果那里发生故障，其下的活动节点和备用节点也会发生故障。

此外，在基础架构的上层，例如捆绑多个机架的网络交换机、网关和路由器以及数据中心的电源单元，操作系统节点和备用系统节点可能共存于同一系统中。 如果这些关键组件不是冗余的，那么您将面临不可避免的单点故障。 同样，对于作为公共云用户的公司来说，这样的数据中心基础设施是一个黑匣子。 可能无法查看详细配置以识别 SPOF。

应利用公共云可用性区域和区域来提高可用性

我们如何才能明确避免公共云中隐藏的单点故障？ 最稳健的方法是使用云端准备的“Availability Zones”和“Regions”。

可用区是数据中心内基础设施的独立物理隔离。 区域是地理上分开的独立数据中心。 一些公共云允许您故意将这些可用区或区域用于不同目的。

例如，亚马逊网络服务 (AWS) 在全球有 12 个区域。 此外，Microsoft Azure 有 22 个区域。通过构建一个 HA 集群配置，其中运行节点和备用节点分布在这两个或多个区域的不同可用区中，几乎可以肯定地避免所有 SPOF。如果您遵守这些最佳实践，您可以自信地确保可用性，DR （灾难恢复) 和 BCP（业务连续性计划）。