如果您要使用开源高可用性，那么团队需要具备七项技能

在高可用性（HA）领域中，如果您决定采用开源方式，则团队需要掌握某些重要技能。 开源的定义是指可以免费使用的软件。

如今，微软和SIOS Technology Corp等供应商为许多操作系统提供了高可用性集群的多种商业实现方案。这些商业解决方案提供了资源监视，依赖性管理，故障转移和集群策略以及某种形式的预先打包和定价的管理方案。商业实现的替代方法是几种开源选项，这些选项也使公司有机会为其企业提供高可用性。

随着公司继续寻求优化，节省成本和潜在的更严格控制，越来越多的公司和客户也正在考虑转向开源可用性解决方案。

要迁移到开源HA，您的团队可能需要具备以下7种技能：

1.编码技巧

在许多情况下，缺少对企业应用程序的预打包和捆绑支持意味着您的团队将需要能够开发解决方案来保护组件，解决捆绑组件的问题或编写应用程序连接器以确保正确处理应用程序意识。很多人都可以编写脚本，但是您的团队将需要知道如何创建并遵守合理的开发实践和标准。这方面的基本知识包括：

• 设计和架构要求
• 设计评论
• 代码/代码审查和单元测试（最好是自动化的）

2.对技术环境的了解

许多企业应用程序需要与多个系统集成，以提供满足服务水平协议（SLA）和服务水平目标（SLO）的高可用性。您的团队将需要深刻的应用程序意识和对技术环境的了解，才能为与多个企业系统的集成建立保护和解决方案。您需要了解关键应用程序的来龙去脉，这些应用程序的技术环境，网络，硬件，虚拟机管理程序以及对环境和应用程序依赖性的了解的人员。您还需要团队成员了解开放源代码社区中打算使用的HA技术的体系结构，功能和局限性。 考虑一下您的团队了解和了解的这些领域中的多少：

• 数据传递和节点通信
• 节点故障
• 应用管理
• 系统恢复并重新启动
• 记录和消息
• 数据弹性和保护

3.业务流程知识

您需要有人来了解您的业务需求和业务流程。您的团队需要专业人士，他们需要了解企业的业务及其发展过程。您的团队将需要了解和了解有多少预算可用于开发解决方案，企业愿意承担多少风险，以及如何收集可能未讲或未指定的其他要求。

团队还需要知道或聘请知道如何将这些业务需求转换为软件需求以及如何管理流程以实现最低可行的高可用性解决方案以实现满足业务需求的成果的人员，或者业务，并适合业务流程。

4.具有操作系统，应用程序和基础架构的经验

如果您想全力以赴，您的团队将需要了解操作系统，应用程序和基础架构的经验。您需要了解各种操作系统的发行周期，包括Linux的内核版本，Windows的更新和修补程序。您内部有需要支持的应用程序，但也需要勤勉地了解应用程序更新周期，它们的依赖性以及应用程序和操作系统支持矩阵的交集。如果您的环境是均匀的，那就太好了。否则，您的团队将需要了解RHEL，RHEL派生产品和SUSE之间的区别。如果您同时使用Linux和Windows，则也需要了解它们。您还需要了解基础架构对应用程序和操作系统组合的影响。AWS和Azure呈现的高可用性差异与GCP，本地和其他虚拟机管理程序有所不同。

5.变更管理能力

想象一下，您拥有一支具有技术和业务知识以及对操作系统，基础架构和应用程序有扎实了解的开发团队来创建解决方案。但是，将脚本放在一起仅仅是个开始。您的团队还需要变更管理功能。您的团队将如何跟踪代码更改以及版本，软件包和软件包位置？您的团队将如何管理更新和变更的发布？您的团队将需要精通git等源代码存储库，Jira等项目管理工具以及发布训练的熟练程度。您需要一个了解如何进行代码更新，提供补丁和修复程序，同时又能避免不必要的影响的团队。

6.数据分析和故障排除经验

当您进入交付自己的HA解决方案的空间时，您的团队将需要分析和故障排除经验。您需要拥有能够理解应用程序代码，系统消息以及应用程序错误日志和跟踪文件的交集的资源。发生系统崩溃时，您将不得不更深入地研究日志以进行故障排除并找到根本原因，分析数据以提出建议，并准备推出更改（请参见上面的＃5）。别忘了，即使没有错误，故障或系统崩溃，您的团队也需要了解并了解这些日志和跟踪文件中的数据可以告诉您环境的运行状况。

7.连接（开发，质量检查，合作伙伴，社区）

坦白说，您的业务不是要提供高可用性，但是，如果您决定涉足开源HA领域，那么您不仅需要团队的智慧，还需要更多的帮助。获得额外帮助的关键是了解从何处开始，然后与社区开发人员，测试专家，HA和应用程序合作伙伴以及开源社区建立正确的联系。开放式论坛确实很有帮助，但是您需要仔细检查响应时间是否符合您的SLA和SLO。

使用开放源代码解决方案是许多公司选择的一种选择，以解决成本问题并意识到灵活性，更低的成本和更低的风险。但是，买方要当心，新技能和管理形式可能存在隐性成本，而使用“开源自己的HA解决方案”所需的开源程序也存在隐性风险。

– Cassius Rhue，客户体验副总裁

转载自SIOS

在2020年，我们看到越来越多的企业将更多的任务关键型应用程序，ERP和数据库迁移到云中。 但是，并非所有这些迁移都很顺利。 我亲眼目睹了由于缺乏对应用程序可用性的规划，“ DIY高可用性”改造的复杂性，与“提升和转变”所带来的误解以及意外成本有关的云迁移项目急剧减慢，甚至停止了。

组织可以采用多种最佳实践，云清单和其他方式为云做准备。 对于那些在2020年云迁移方面遇到停顿或计划在2021年取得进步的人们，在高可用性群集的每种迁移策略中都应考虑以下最佳实践。

云迁移最佳实践

收集需求

许多迁移到云的组织都认为云是迁移到云的本地架构。 当内部部署的网络，存储，磁盘速度和系统大小与云现实发生冲突时，对云迁移的这种误解通常会导致停顿和延迟。 向云的更平滑过渡始于收集对基础架构，治理和合规性，安全性，规模以及相关控制和资源的实际需求。

设计与文件

在设计阶段，将本地环境的体系结构映射到已选择以实现最大可用性并进行了详细记录的云环境。 在此阶段，随着架构的形成，您将确定IP，负载均衡器，IOPS和数据可用性的策略。 团队需要研究如何通过能够自动实现云复杂性的强大应用程序和基础架构可用性解决方案来增强云固有的可用性。 在SIOS，我们的AWS和Azure群集及可用性专家与客户合作，将本地NFS交换为AWS EFS，Azure ANF或独立的NFS群集层。 此外，此阶段成功实施的关键部分将记录所有内容。 文档是迁移成功的一个经常被忽略但必不可少的要素。

计划高可用性

要在云中实现高可用性，需要了解需求，创建设计并记录计划以规划实现这些需求的策略的计划。 基本计划应包括人员配备，人员培训，部署QA系统测试，生产前步骤，部署，部署后验证以及正在进行的迭代。 云迁移的最佳结果来自经过深思熟虑的计划流程；不是临时的，固定的解决方法。

职员

您的团队为云迁移配备了多少人员？ 传统的服务台，客户/服务器IT或IT团队可能不足以进行云迁移。 如果您的团队是云计算的新手，那么也许是时候考虑添加更多资源或基于专业服务的解决方案了。 如果没有适当的见识，信息或培训，迁移到云可能会很繁琐，繁琐且困难。 您的员工是否需要纳入与云环境相关的培训？ 在寻找培训和专业服务以协助您的IT团队时，请与您的供应商联系以获取有关可用性解决方案的培训。 许多供应商为高可用性解决方案提供了灵活的培训，可以通过云供应商或诸如Udemy之类的流行站点获得云培训。

部署质量检查

QA部署阶段是团队执行将实际系统部署到云中的计划的阶段。 成功的部署团队将验证其计划和策略，了解数据迁移过程，发现所有遗漏的依赖项，并为过程的下一步做准备，尤其是测试。 当跳过或跳过此步骤时，曾经有希望的迁移通常会停滞不前或失败。 当您进入质量检查系统部署阶段时，您的团队将繁重地进行云中应用程序，数据库和关键数据的初始迁移和配置。

测试您的高可用性

在您的质量检查环境中进行测试是至关重要的一步。 这些测试不是浪费时间；他们节省时间。 与在本地部署相比，在云中部署环境通常更容易。 您的质量检查环境可以使用诸如Ansible之类的工具编写脚本，可以作为云市场中的模板或克隆映像快速部署，也可以根据云形成模板进行部署和构建。 部署后，可以在灾难发生之前（而不是在灾难发生之前）消除和优化灾难场景。 可以利用测试方案来确定网络，磁盘速度方面的过度配置，配置不足或瓶颈。 完整的测试方案也可以用作新员工入职策略的一部分。 此外，还应该对快照和备份执行测试。

部署生产

当测试阶段完成并且您的团队已验证测试结果时，下一个阶段是从质量检查过渡到预生产，再从预生产过渡到上线。 测试阶段是繁重的最后阶段，涉及最终用户验收测试，最终生产数据的转换和更新，然后是用户。

审阅，修订和重复

成功迁移到上线阶段并不会结束，而是会持续到生命周期阶段。 在云迁移策略的上线阶段中，您的团队将继续审查，修订和重复从“收集”到“部署生产”的步骤。 实际上，您的团队应根据特定于发行版，应用程序更新，安全更新，相关系统维护，操作系统版本，灾难恢复计划以及高可用性供应商自身最佳要求的要求来一次又一次地重复此过程。实践。 云平台一直在发展，并添加了可以增强您现有的HA解决方案和体系结构的新功能，特性和更新。 审查，修订和重复该过程将是成功入职的必要步骤。

在2021年，我们将看到更多的企业将更多的关键任务应用程序，ERP和数据库迁移到云中。 成功的关键因素将是利用云迁移最佳实践来避免整个过程中的延迟和失败。 了解您的业务需求和需求，记录设计和计划，在具有特定目的的群集解决方案的QA环境中进行部署以及在上线之前执行广泛的测试至关重要。 请与SIOS Technology联系，以了解如何将SIOS Protection Suite包含在您周到的云迁移最佳实践中。

-客户体验副总裁Cassius Rhue

转载自SIOS

如何构建高度可用的服务器解决方案？

任何高可用性解决方案的关键组成部分都是弄清楚如何重定向客户端流量。 几乎每个基于用户的应用程序都需要连接到服务器。 重定向客户端流量将允许用户连接，而不必知道应用程序或数据库实际位于何处。

大多数解决方案建议基于网络的IP重定向或基于网络的DNS重定向。 这行得通。 但是，根据我们的经验，针对高可用性服务器的最佳解决方案是使用可以从一台服务器切换到另一台服务器的虚拟IP地址。 该服务器正在监听来自虚拟IP地址的连接，该地址今天托管在一台服务器上，另一天又切换到另一台。

要更进一步，您可以使故障转移自动化。 在此处，系统会做出决策并在检测到故障时切换应用程序。 请记住，此步骤是构建高可用性解决方案的关键。

购买与构建高可用性解决方案的好处

这可以使用脚本和逻辑来检查从一台服务器到另一台服务器的进程和虚拟IP地址的状态来实现。 但是，我们在购买与构建高可用性解决方案中面临的挑战之一是，我们真正需要花费多少时间来构建。 这包括进行脚本编码，API开发（例如cloudwatch API或lambda函数）的时间。 让我们不要忘记测试和维护。

小时候，我很想写那个代码。 但是在为《财富》 100强公司工作之后，并被一位高级经理大喊大叫后，当我的一个脚本在凌晨3点无法正常工作时，我的感受就不同了。 当我发现一年前编写的代码的问题时，这个问题更加严重。 我的经理们希望这种高度可用的解决方案能够100％工作。 如果没有用，请花时间打电话给某人并大喊大叫。

SIOS实现高可用性自动化

从长远来看，购买解决方案并花一点时间对其进行调整以适应我们的环境是否更便宜？ 无论应用程序或数据库如何，这都是SIOS高可用性（HA）解决方案出现的地方。 SIOS具有将进程堆栈从一台服务器切换到另一台服务器的代码。 这使用户和管理人员可以放心地从自动执行故障转移流程和高可用性而来。

关于SIOS HA伞，我最喜欢两件事。 第一，虚拟IP的代码，其中IP地址已添加到服务器，并且重新启动了应用程序以侦听连接。 第二个是通过使用SIOS提供的与应用程序无关的API集启用的。 这样，任何人都可以使用插件来保护任何应用程序。 立即联系SIOS，以了解有关您的环境的高可用性解决方案的更多信息。

– Edmond Melkomian，PMP，MCSD，SIOS Technology，Inc.顾问

转载自SIOS

IT灾难恢复的痛苦阶段

如果您没有实施正确的企业可用性体系结构，灾难恢复的痛苦可能使您无所适从。 在IT中与我们的朋友Dave会面，向我们介绍灾难的5个阶段。

阶段1：拒绝

Dave in IT：“哦，哦。那是什么警报？只是有一点应用程序崩溃，对吗？没什么大不了。我将立即启动并运行。”

在企业可用性方面，几乎没有应用程序崩溃或没什么大不了的事情。公司拥有SLA，并且拥有真实的资金。您的选择现实可能与您的客户和利益相关者的观点不同。

阶段2：愤怒

戴夫（Dave）：“你在开玩笑吗？在所有时间[censored]中……今天，该应用程序将无法启动。嗯我讨厌这[censored]个…[censored]…应用程序。等等，这是什么新提醒。严重的是，现在，数据中心已关闭！”

在快速的节奏和高风险的环境中，它确实变得非常非常杂乱。 当未经检查的警报和故障发生时，问题会随着压力，沮丧和愤怒而迅速增加。

状态3：讨价还价

IT中的Dave：“嘿，在应用程序中，这就是IT中的Dave。你们有App1环境的任何备份吗？ 。 。你确定吗？您能再检查一次吗？我知道您已经检查了两次，但您可以再检查一次。我要在星期二的Taco买饮料！”

Dave in IT：“嘿Donna DBA，这就是Dave in IT。 应用程序中的Art表示您可能会帮助我。您是否偶然为该财务数据库或库存管理系统设置了任何数据库复制？ 。 。 。 你确定吗？嗯，你还记得我们是否有办法从嗯中恢复过来。 。 。数据中心崩溃了？”

当我的女儿遇到麻烦时，讨价还价是她的第一个去。好的，第二。首先是消失，但你太聪明了，只能走开火焰。但是，IT中的戴夫（Dave）并不是唯一意识到讨价还价和乞讨不能很好地替代为高可用性和灾难恢复制定明确策略的人。跳过讨价还价，乞求您的灾难，因为“ 80％的人不在乎，而20％的人很高兴是您（由Les Brown改写）。”

阶段4：悲伤

Dave in IT：“这真是太好了。应用程序服务器崩溃，数据中心关闭，如果可以找到备份并可以加载它们，则备份将花费数小时才能恢复。我没有办法摆脱……我把更新的简历放在哪里了。”

当然，您有备份，并且已经对其进行了验证。但是回到这些备份会对RTO和RPO产生影响。这次你能吸收吗？当然，那是在您的数据中心恢复之后。

步骤5：验收

戴夫（Dave）：“已经两个小时了。我从来不知道我们以前有这么多的执行干系人。在那之后我永远都无法庆祝自己的2周年纪念日。好吧，我想明天我要打扫办公室。我绝对不可能做到这一点！”

失败会发生。数据中心出现故障。应用程序失败。不能否认丢失数据中心，服务器故障或应用程序崩溃的可能性。这种接受是正常的，这是提高可用性的一部分。SIOS Technology Corp.的专家希望确保避免因无法实施可用性策略而失业或变得更糟。

不要像IT中的Dave。通过设计和实施企业可用性架构来避免灾难性灾难以及灾难恢复和停机时间，该架构包括最佳的混合，内部部署或云以及最佳的监视，恢复和系统故障转移自动化解决方案。

–客户体验副总裁Cassius Rhue

转载自SIOS