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

在高可用性（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