术语表:应用程序性能管理(APM)
定义:IT专业人员用来监视和管理软件应用程序的性能和可用性的软件和流程。
转载自SIOS
SIOS SANless clusters High-availability Machine Learning monitoring
定义:设计用于确保软件应用程序按预期运行的工具。 IT专业人员使用APM工具来确保其最终用户获得重要业务应用程序期望的服务质量。 在虚拟环境中,应用程序监视工具可帮助管理员确保应用程序服务器在其服务级别协议(SLA)的参数范围内运行。
转载自SIOS
作者Carey Nieuwhof吸引了我一个2021年最大陷阱的博客主题。 虽然没有直接与HA交流,但仅是这个话题就让我反思了2020年的一些趋势。云创新众多,始于基础架构的最基本层次。 更不用说人工智能,机器学习,计算能力和算法,内存管理和共享以及其他方面的进步。 所有这些进步加起来使当前的云成为最健壮,可靠和可用的数据中心。 这些中心经过优化,配备了冗余电源,散热,大量用于监视和警报的IoT设备,冗余网络,高速互连,大型服务器,存储和磁盘,这些令人印象深刻,而且很可能是2021年可能出现的最大陷阱。
2021年最大的陷阱将是相信,仅云可用性就可以与更高可用性相同或足够。 这是一个复杂的陷阱。 构成许多数据中心主干的已命名进步的清单确实是巨大而令人印象深刻的,并且仅是驱动云的现有技术创新的一小部分。 那么,是什么使这种大规模冗余,高容量和AI驱动的基础架构成为陷阱呢? 即,硬件和基础架构的可用性仍然使您的企业面临风险。
磁盘变得更快,更智能。 芯片组,访问技术,制造,存储容量和RAID技术方面的新突破令人瞩目,这意味着云供应商能够为速度,访问和冗余设置昂贵的数字。 这样可以降低磁盘基础结构出现单点故障(SPOF)的风险,并确保单个磁盘甚至磁盘暂时断电不会造成可用性不足。
数据中心内提供对磁盘的访问的存储阵列和存储柜也得到了极大的改进。 这些装置虽然体积较小,但不再具有闪烁的灯光和Airboat大小的风扇的大眼睛,而是具有容量和性能增强的功能。 您将很难找到一个没有冗余电源,冗余磁盘功能并且无法在相连的存储单元之间(甚至在距离较远的单元之间)提供几乎零复制的现代机箱。 此外,这些单元还增加了AI的优势,可以预测故障,主动解决问题并优化工作负载以减少性能瓶颈。
请记住,很久以前,知名的制造商和技术预测人员就在预测改变游戏规则的技术,这些技术将重塑未来的前景。 好像几十年前,人们在预测服务器技术的进步,例如:减少占用空间,更快,更复杂的芯片组,NVMe,电池效率,散热进步,存储进步,内存和持久性内存进步,GPU和裸机配置。 那个未来已经到来并且被超越了。 服务器现在正在加快云计算功能的步伐,并提高了云提高冗余,可靠性和健壮性的能力。
网络解决方案,工具,软件和设备的进步也使2020年使云可用性变得更强的事物清单。 在过去的几年中,供应商发布了解决方案,这些解决方案扩展了云间和云内网络的速度,可能的拓扑,容量和距离功能。 像许多其他技术一样,供应商正在利用AI和机器学习来自动化流量和模式,利用制造方面的先进优势来构建设备冗余,从而可以利用这些冗余来提高可用性和可靠性。
如果不加以保护,应用程序仍然是云体系结构中的脆弱部分。 不受应用程序感知的更高可用性模块或框架或SIOS应用程序恢复工具包(ARK)保护的应用程序可能会在业务生命周期中最关键的时间或时刻崩溃。 SIOS ARK为云中的应用程序提供了关键的应用程序感知监视和恢复,以及在发生故障时进行故障转移和灾难恢复编排。
虽然数据库的数量已提高了其健壮性,甚至有些数据库已经提供了复制增强功能,但这些数据库本身仍然存在风险。 具有复制技术的数据库仍然需要业务流程,自动化和智能,以确保它们对需要它们的应用程序组件高度可用。 如果您的应用程序实际上在另一个Region或DR站点上失败,则数据库继续在主要Region和Availability Zone中徘徊是有什么用的。 使用SIOS Technology Corp HANA ARK和SAP认证的SAP S / 4 HANA ARK的自动化和最佳实践对具有复制功能的数据库(例如SAP HANA数据库)进行补充。 通过SIOS保护套件,SIOS DataKeeper for Linux和关联的ARK的组合来保护没有复制技术或技术受限的数据库。
在磁盘和存储领域,令人信服的是,容量,软件和硬件突袭的冗余意味着您具有很高的可用性。 但是,只有在需要存储的应用程序和虚拟机可以访问存储的情况下,存储才可用。 您已部署了什么技术来监视和恢复已安装的云共享和卷,例如EFS和ANF。 计划外的停机时间及其相关的混乱状况可能与意图良好的用户的意外卸载或脱机操作差不多。
虚拟机监控程序技术使您的虚拟机按钮变得容易。 集成云解决方案承诺监视VM是否可用,并提供重启或迁移等选项。 这些解决方案不足以解决您的虚拟机可能会停滞,延迟或降低可用性的问题。 除了您的云供应商提供的产品之外,您还需要一个监视和可用性解决方案,该解决方案应了解如何监视VM运行状况,例如:
运行无能力处理应用程序请求的VM可能会避开仅监视云的工作,但不应逃避对更高可用性解决方案的监视。
让我们现实一点。 数据中心可用性,冗余性和可靠性方面的所有进步并没有消除消除数据中心成为单点故障(SPOF)的需要。 作为客户体验副总裁,我们与一位客户合作,该客户在私有云数据中心内部署了一流的冗余,这与主要的公共云供应商非常相似。 如果不是因为SIOS Technology Corp.提供的高可用性和数据复制解决方案,当一场热带风暴席卷其区域并切断电源,备用发电机,冷却设备和网络时,该客户将遭受重大停机。
但是,借助SIOS技术,客户能够在风暴发生之前抢先进行故障转移到更内陆的数据中心。 冷却故障,施工事故以及人为和自然灾害不断提醒我们,单个数据中心与更高的可用性并不相同。
不要陷入2021年的最大陷阱 通过避免认为云已覆盖来确保您具有真正的高可用性。
–客户体验副总裁Cassius Rhue
转载自SIOS
我喜欢第二年的开始。好吧,大部分。我喜欢乐观,神秘,潜力和希望,随着日历翻到另一年,它似乎已融入生活。但是,随着时间的推移,存在一些不利因素。每年新年的开始都会带来____种做事的方式_____。我的收件箱里总是满是“减肥的二十种方法”。 “建立投资组合的十种方法。” “管理压力的三个技巧。” “使用新iPhone的19种方法。”几乎在生活和工作的每个领域,都有很多关于自我改善,文化转变,压力管理和减肥的清单,其中包括“改善家庭办公室的十三种方法”。但是,高可用性又如何呢?您每个星期只有这么多时间。 因此,您如何使HA解决方案比以往更高效,更可靠。您的清单在哪里?这里有五十种方法可以使您的高可用性体系结构和解决方案更好:
那么,您学到了什么来增加和改善企业可用性的想法和方法是什么? 让我们知道!
-客户体验副总裁Cassius Rhue
转载自SIOS
在高可用性(HA)领域中,如果您决定采用开源方式,则团队需要掌握某些重要技能。 开源的定义是指可以免费使用的软件。
如今,微软和SIOS Technology Corp等供应商为许多操作系统提供了高可用性集群的多种商业实现方案。这些商业解决方案提供了资源监视,依赖性管理,故障转移和集群策略以及某种形式的预先打包和定价的管理方案。商业实现的替代方法是几种开源选项,这些选项也使公司有机会为其企业提供高可用性。
随着公司继续寻求优化,节省成本和潜在的更严格控制,越来越多的公司和客户也正在考虑转向开源可用性解决方案。
在许多情况下,缺少对企业应用程序的预打包和捆绑支持意味着您的团队将需要能够开发解决方案来保护组件,解决捆绑组件的问题或编写应用程序连接器以确保正确处理应用程序意识。很多人都可以编写脚本,但是您的团队将需要知道如何创建并遵守合理的开发实践和标准。这方面的基本知识包括:
许多企业应用程序需要与多个系统集成,以提供满足服务水平协议(SLA)和服务水平目标(SLO)的高可用性。您的团队将需要深刻的应用程序意识和对技术环境的了解,才能为与多个企业系统的集成建立保护和解决方案。您需要了解关键应用程序的来龙去脉,这些应用程序的技术环境,网络,硬件,虚拟机管理程序以及对环境和应用程序依赖性的了解的人员。您还需要团队成员了解开放源代码社区中打算使用的HA技术的体系结构,功能和局限性。 考虑一下您的团队了解和了解的这些领域中的多少:
您需要有人来了解您的业务需求和业务流程。您的团队需要专业人士,他们需要了解企业的业务及其发展过程。您的团队将需要了解和了解有多少预算可用于开发解决方案,企业愿意承担多少风险,以及如何收集可能未讲或未指定的其他要求。
团队还需要知道或聘请知道如何将这些业务需求转换为软件需求以及如何管理流程以实现最低可行的高可用性解决方案以实现满足业务需求的成果的人员,或者业务,并适合业务流程。
如果您想全力以赴,您的团队将需要了解操作系统,应用程序和基础架构的经验。您需要了解各种操作系统的发行周期,包括Linux的内核版本,Windows的更新和修补程序。您内部有需要支持的应用程序,但也需要勤勉地了解应用程序更新周期,它们的依赖性以及应用程序和操作系统支持矩阵的交集。如果您的环境是均匀的,那就太好了。否则,您的团队将需要了解RHEL,RHEL派生产品和SUSE之间的区别。如果您同时使用Linux和Windows,则也需要了解它们。您还需要了解基础架构对应用程序和操作系统组合的影响。AWS和Azure呈现的高可用性差异与GCP,本地和其他虚拟机管理程序有所不同。
想象一下,您拥有一支具有技术和业务知识以及对操作系统,基础架构和应用程序有扎实了解的开发团队来创建解决方案。但是,将脚本放在一起仅仅是个开始。您的团队还需要变更管理功能。您的团队将如何跟踪代码更改以及版本,软件包和软件包位置?您的团队将如何管理更新和变更的发布?您的团队将需要精通git等源代码存储库,Jira等项目管理工具以及发布训练的熟练程度。您需要一个了解如何进行代码更新,提供补丁和修复程序,同时又能避免不必要的影响的团队。
当您进入交付自己的HA解决方案的空间时,您的团队将需要分析和故障排除经验。您需要拥有能够理解应用程序代码,系统消息以及应用程序错误日志和跟踪文件的交集的资源。发生系统崩溃时,您将不得不更深入地研究日志以进行故障排除并找到根本原因,分析数据以提出建议,并准备推出更改(请参见上面的#5)。别忘了,即使没有错误,故障或系统崩溃,您的团队也需要了解并了解这些日志和跟踪文件中的数据可以告诉您环境的运行状况。
坦白说,您的业务不是要提供高可用性,但是,如果您决定涉足开源HA领域,那么您不仅需要团队的智慧,还需要更多的帮助。获得额外帮助的关键是了解从何处开始,然后与社区开发人员,测试专家,HA和应用程序合作伙伴以及开源社区建立正确的联系。开放式论坛确实很有帮助,但是您需要仔细检查响应时间是否符合您的SLA和SLO。
使用开放源代码解决方案是许多公司选择的一种选择,以解决成本问题并意识到灵活性,更低的成本和更低的风险。但是,买方要当心,新技能和管理形式可能存在隐性成本,而使用“开源自己的HA解决方案”所需的开源程序也存在隐性风险。
– Cassius Rhue,客户体验副总裁
转载自SIOS