高可用性架构和最佳实践

高可用性架构和最佳实践

关于高可用性的 13 个鲜为人知的事实

1. Hypervisor HA 与应用程序 HA 不同

一个关键的误解是，我之所以具有高可用性，是因为我的硬件或虚拟机管理程序中有冗余。 但是，硬件和管理程序冗余并不能保证高可用性用于应用程序。 也不能保证应用程序的编排将在失败时正确执行。

2. 在高可用性中，更大并不等于更好

如果你是一名力量举运动员，更大的重量更好，更小的代表更好。 或者，如果我们谈论拥抱。 （你还记得拥抱是我们见到来自不同城镇的朋友时经常做的事情，我们有一段时间没见过了。）但是，更大并不总是意味着更好。 例如，更大的肾结石肯定不是更好。 在更高的可用性中，创建更大、更复杂的解决方案并不总是意味着您将提高您的高可用性。 这可能意味着您的可用性相同或更少。 这也可能意味着您有一个更大、更复杂的系统，其中包含许多移动部件，需要在停机时进行分类。

3. 一切都失败了……有时

应用程序编程语言可以追溯到 1950 年代。 虽然语言、处理器、IDE 和代码质量有所提高，但现实是“所有应用程序都会在某个时候失败”。由于异常、错误、未处理的终止、意外终止、资源耗尽等导致的失败时有发生。 仍然需要一个主动/主动或主动/被动应用程序可用性策略。

4. 关注“为什么”和“如何”一样多

我们跳入任务完成模式的自然倾向是一种必要的资产，但需要通过我们对为什么的问题的回答来加以调节和引导。 在不了解业务、应用程序、数据库和利益相关者要求的情况下向环境添加解决方案将导致：

• 失败
• 超支
• 表现不佳
• 混乱和过度架构
• 上述所有的

与其只关注实现可用性，不如花费必要的资源和精力来了解业务需求和“为什么”的答案

5. 未修补的问题是常见的遗憾来源

做或不做，后果自负。 所有未修补的问题的后果是后悔。 作为客户体验副总裁，我亲眼目睹了由于客户未能及时解决已知问题而导致的停机。

6. 未记录的问题也会导致停机

描绘场景。 一位新管理员正在调查网络上的服务器。 使用情况报告表明服务器未处于活动状态，并且没有连接任何客户端。 新管理员无法识别服务器，也没有发现“标签”、文档或其他标识符，因此认为应该关闭它。 不幸的是，未记录和未通信的实例实际上是一个备用服务器，当主服务器意外崩溃时，删除它会导致停机。 这不是虚构的故事，而是一个新管理员的真实故事，他错误地将服务器识别为空闲 QA 系统并在修补练习之前将其关闭。

7、自满也是敌人

如果内部或云中或介于两者之间的任何地方的可用性是我们可以“设置并忘记”的，我们都会喜欢它。但是，生活中很少有事情真的像“设置并忘记它”那样简单。未来可用性的最大敌人之一是您现在的高可用性成功。 当灾难很少发生并且团队确信他们已经实现了持续稳定时，自满情绪就会介入。 成功诱使我们认为什么都不会改变，因此对高可用性的自满是高可用性的敌人。 企业周围和企业内部的事物正在发生变化。 云在变化，您的业务需求在变化，应用程序和操作系统也在变化。

8.改变很难

改变很难。 问问那些一直试图在睡前放弃第二块蛋糕的爱吃甜食的人吧。 即使在高可用性中也会出现类似的阻力。 团队，即使是那些经历过灾难的团队，即使改变是好的，也往往不愿意改变。 他们需要远见、对原因的理解和支持。 其他拥有解决方案的团队不愿意提高高可用性，因为害怕引入不稳定或将自己暴露在新的风险中。

9.所有的改变都不是好的改变

改变是好的，当改变是好的。 在考虑对更高可用性解决方案和架构进行更改时，必须针对目标、要求以及在提高可用性的范围内分析更改。 提高稳定性、增加对关键组件的保护、消除变通方法、优化服务可用性并经过全面测试的更改都是很好的更改。

10. 便宜并不总是更好

便宜并不总是更好。 虽然更便宜的解决方案通常具有较低的价格标签，但它们也可能带有许多限制，使其不太理想。 当价格标签较低时，请注意缺少的功能，例如缺乏应用程序意识、有限的编排、隐藏的复杂性、手动恢复和故障转移，并且仅限于没有用户验证。 更便宜的解决方案也可能不包括客户支持。 请务必了解您的更便宜的解决方案是否包含支持，或者支持是否是额外的、大量的附加成本。

这同样适用于减少计算、磁盘或存储的更便宜的部署。 虽然价格标签和每月成本可能较低，但您的解决方案也可能以不太理想的容量运行。

11.响亮不等于有效

听说过那个叫狼来了的男孩的故事。 产生警报风暴的应用程序监控解决方案迟早会被忽略。 拥有提供警报的解决方案固然很棒，但如果该解决方案错误地或过多地触发了关键警报，则它是无效的。

12. 高可用性是一种文化和心态，而不仅仅是产品或硬件解决方案

软件、硬件、流程、解决方案和服务都是高可用性的一部分。 但是，如果没有跨 IT 职能和业务部门的支持，它将充满挫败感并不断成为预算讨论的来源，而不是关于价值、业务稳定性、提高客户满意度和降低风险的讨论。

13.现在还不晚

希望不是实现高可用性的策略，希望您不会遇到严重灾难或应用程序故障也不需要成为策略。 即使距离上次灾难已经过去数周或数月，现在也可以设计和构建高度可用的企业架构。

联系 SIOS了解更多高可用性解决方案为您的应用程序。

– 客户体验副总裁 Cassius Rhue 转载自SIOS