在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

为什么高可用性必须如此复杂？

这是Hallmark电影季，我的意思是圣诞节季节，我的意思是Hallmark圣诞节电影季……（别太苛刻，我是六位年轻女士的父亲，一个没有希望的浪漫主义者，并且嫁给了一位享有美好生活的配偶。假期笑声和幸福的结局）。 如果您是在Hallmark电影季，那么您很可能会听到“为什么爱情如此复杂？”这句话。这句话将在这位伤心欲绝的年轻人对新的爱情产生新的感情之前，并准备在他们怀中跳起夜晚，就像老火焰走进晚会一样。如果您不喜欢霍尔马克（Hallmark）的假日恋情，那也许不是您想知道的爱情。也许您想知道：“为什么高可用性必须如此复杂。

高可用性如此复杂的十个原因：

1. 创新的速度
   

   云计算，边缘计算，超融合，多云，容器和机器学习正以惊人的速度改变着企业可用性的格局。据保守估计，AWS目前拥有175多种服务，并且“在云中提供了高度可靠，可扩展的低成本基础架构平台，为全球190个国家/地区的数十万企业提供了动力。”选择一种HA解决方案，以允许在所有这些环境中进行一致的管理，并具有基础结构和应用程序意识，这是降低复杂性的一种重要方法。

2. 灾难的随机性

   有人曾经说过：“使您的解决方案具有防灾能力，而Universe将建立更好的灾难。”我们不仅在技术领域看到了创新，而且在灾难世界中也看到了创新。 资源匮乏，冷却系统灾难，自然灾难，电网故障以及许多新的和随机的灾难通常使隔离整个企业变得更加困难。 去年的解决方案可能需要更新，以应对今年前所未有的停机。 与多年致力于高可用性的供应商合作非常重要，该供应商在寻找灾难随机性解决方案方面拥有第一手经验。

3. 应用程序复杂度

   随着技术在虚拟化和云计算领域的发展，应用程序也在紧随其后。 这些应用程序供应商增加了利用云的新选项时，也增加了额外的复杂性。您的应用程序应受旨在在AWS，Azure，GCP或其他环境中提供更高可用性和群集的解决方案保护。寻找能够提供更多应用程序意识，最佳实践理解并提供可用性解决方案的供应商，这些解决方案在设计时考虑到了应用程序的架构方式，并能够优化应用程序在云中的编排。

4. 威胁的进展
   

   对企业的威胁也影响您的可用性。 系统始终必须处理来自入侵者，黑客甚至是自欺欺人的攻击。这些攻击已经变得更加复杂，避免受害的解决方案和方法通常会影响组织内部署的布局，体系结构和软件。 该软件必须与您的可用性解决方案和您的应用程序“完美融合”。 作为SIOS技术客户体验副总裁，我已经看到过于激进的病毒扫描程序如何影响您的应用程序和可用性解决方案。确保您了解安全系统对HA / DR环境的影响，并选择适用的HA解决方案，而不违反您的安全目标。

5. 法规要求

   数据泄露会影响您的应用程序，虚拟机管理程序和环境的体系结构，但法规要求也是如此。现在，已成为全球业务的企业必须确保它们符合多个国家/地区的数据处理法规。这可能会影响您的解决方案可以部署在哪个区域，以及可以用于冗余的区域数量。另外，法规要求也会影响可以为您的组织提供支持的团队，这可能会影响可用性软件和支持的选择。

6. 缩小窗户
   

   在24/7全天候搜索，购物，游戏，银行和研究领域，窗口正在缩小。查询必须运行得更快并且花更少的时间。响应必须更快，并且必须有更好的数据。这意味着您的环境所允许的停机时间比您以前想象的要快得多。这也意味着维护窗口要更紧凑，更紧凑，并且必须进行优化和高度协调。 与HA供应商合作，后者可提供有关优化集群配置以提高应用程序性能和快速恢复时间的指导。

7. 竞争压力增加
   

   我在一个小镇长大。 五金店有一个竞争对手。 杂货店有一个竞争对手。 书店，古董店，汽车经销店，出租办公室和银行都拥有一个竞争对手。 如今，您有成千上万的竞争者，他们除了在结帐购物车中看到您的客户外，只想要什么。 这种竞争会影响整个业务的复杂性。 它在维护窗口，升级以及您以何种速度进行创新方面具有重大影响。 可能每五年刷新一次的环境已移至云端，可以在几秒钟或几分钟内优化和提高处理器速度和内存。 曾经只有一本简单的应用程序清单，涵盖简单应用程序列表的系统现在看起来更像“战争与和平”，涵盖了不断增加的流程，产品，服务和情报，以增加利润，同时努力降低风险和停机时间。

8. 高可用性解决方案成本

   我们都希望我们有一个无限的预算，但是有时您所拥有的预算之间的现实有时还很有限。团队通常被迫在消耗与固定成本，备用集群上的应用程序的许可成本以及可用性软件的相关成本之间进行权衡。企业许可证通常会在可用性环境中为备用服务器添加一个“难以下咽”的价格标签。即使您是核心的“ DIY”团队，架构可用性解决方案也不是免费的。DIY附带维护，管理，源代码控制，测试，部署，版本管理和版本控制，补丁程序和补丁程序管理方面的额外费用。虽然您的专家团队可能显然已准备好应对挑战，但您的企业可能希望将其高价值的人才用于创造更多的收入机会。

9. 业务成长
   

   创新带来的业务增长意味着您的团队现在负责更关键的应用程序，更多的站点，更多的办公室以及更多需要访问和高度可用的数据。 随着业务的发展和蓬勃发展，向上扩展和向外扩展所带来的挑战不仅增加了前面提到的复杂性，而且还扩展了您必须准备和计划的内容。

10. 团队失误
    

    环境的复杂性，创新的速度，业务的增长，应用程序层的进步以及竞争格局的增长，带来了保持顶级人才以保持基础架构平稳运行的挑战。大多数公司都知道可用性是人员，流程，产品和体系结构的结合。 因此，寻找方法通过自动配置，记录的运行手册，在整个基础架构中采用一致的HA策略来降低集群环境的复杂性，既是保留安装和管理基础架构的人才，又是减轻风险和沉重负担的关键。负责可用性关键部分的人员。

面对现实吧，爱需要艰苦的工作，良好的沟通，时间，投入，技巧和决心。 建立成功关系没有捷径。在企业内部不断发展，日益复杂和灵活的技术空间中实现最佳结果也可以说同样的话。可用性，集群，灾难恢复和正常运行时间如此之高，因为它需要认真，专注，不间断的从上到下的文化转变，这要考虑到创新的速度，应用程序和业务流程的复杂性，竞争和增长，以及使应用程序，数据库和关键基础架构在需要时可供其他人使用的其他组件。

-客户体验副总裁Cassius Rhue