SAP 环境旨在随着业务增长提供相应的支持。Hitachi Vantara 的 Virtual Storage Platform One (VSP One) Block High End已通过 SAP 认证,最多可支持 1,008 个 SAP HANA 节点。该认证为平台所能支持的规模提供了经过验证的基准,让组织在整合大型 SAP 环境、推进其现代化并进行扩展时更有信心。
但规模只是关键任务 SAP 系统需求的一部分。更棘手的问题是,当出现问题时,底层基础设施能否确保业务持续运行,无论问题源于硬件故障、软件问题还是网络攻击。
增长改变了风险考量
随着 SAP 环境不断扩展,它们通常需要支持更多用户、应用程序、数据和业务流程。这使规模变得更加重要,但同时也会加大停机造成的影响。业务对平台的依赖程度越高,可容忍中断的余地就越小。
Hitachi Vantara 的最新研究凸显了这种压力。59% 的美国和加拿大业务及 IT 领导者表示,关键数据丢失将造成灾难性后果。随着组织整合并扩展其 SAP 环境,中断造成的后果也可能随之加剧。因此,规模并不仅仅意味着支持更多工作负载,还意味着在不影响可用性或业务连续性的前提下做到这一点。
作为 VSP One 整体数据平台的一部分,VSP One Block High End 将简化的数据管理与大型关键任务企业环境所需的可用性和韧性融为一体。
必须从基础层面构建韧性
补丁管理、身份控制和应用程序安全仍然至关重要。基础设施韧性并不能取代其中任何一项,而是通过帮助组织持续访问关键数据,并在发生中断时以更可预测的方式进行恢复,提供另一层保护。
这种需求正变得愈发迫切。Check Point Research 最近的研究发现,遭到勒索的勒索软件受害者数量同比增长了 48%,凸显出组织在保护关键系统以及发生中断时快速恢复方面所面临的压力日益加剧。对于运行关键任务 SAP 系统的组织而言,这再次表明,预防只是整体策略的一部分,还必须提前规划可用性和恢复能力。
美国网络安全和基础设施安全局建议组织识别对日常运营最关键的系统,维护并测试备份,并在事件发生前确定恢复优先级。这些原则对于 SAP 环境尤为重要,因为恢复并不只是让存储重新上线。企业还需要确保所需的系统和数据能够按照正确的顺序恢复。
VSP One Block High End 专为满足这一级别的可靠性要求而设计。作为 VSP One 产品组合中专为关键任务工作负载打造的解决方案,它可提供高达 99.999999% 的可用性,并享有 Hitachi Vantara 的 100% 数据可用性保证。它还支持双活、多数据中心复制和恢复功能,旨在帮助组织持续访问支持关键 SAP 应用的数据,并减少业务中断。
基础设施无法消除网络风险,但可以提供更可靠的途径,帮助组织保持对关键数据的访问,并在事件发生时进行恢复。
可靠性是一项业务成果
对 SAP 团队而言,可靠性有时被视为一项技术指标。但实际上,它是一项业务成果。可靠性有助于财务团队完成结账、确保供应链持续运转,并使面向客户的服务保持可用。一旦这些系统停止运行,其影响可能远远超出 IT 范畴。
因此,需要统筹考虑规模、安全性和恢复能力。平台或许能够支持大规模增长,但组织还应考虑它能否在计划内变更和意外事件期间保持可用,以及恢复能力是否已在实际条件下经过测试。
以下三个问题有助于明确讨论重点:
- 环境能否在无需进行中断性重新设计的情况下扩展?
- 它能否在发生故障、进行升级及其他中断期间,确保关键 SAP 工作负载保持可用?
- 团队能否在业务要求的时间范围内恢复重启运营所需的数据?
SAP HANA 认证有助于回答第一个问题。Hitachi Vantara 的可用性、复制和恢复功能旨在满足更广泛的可靠性和韧性要求,从而帮助解决另外两个问题。
为增长和中断做好规划
SAP 现代化应为未来发展留出空间,而不是引入新的风险点。
这意味着要选择既能支持更大规模环境,又能帮助企业在升级、停机和网络安全事件期间保持运营的基础设施。
规模始终至关重要。对于关键任务 SAP 环境而言,只有同时具备维持业务持续运转所需的可靠性和韧性,规模的价值才能得到充分发挥。
进一步了解Hitachi Vantara 面向 SAP HANA 的解决方案,以及组织为何选择 Hitachi Vantara 来支持其 SAP 环境。
Dan McConnell
As head of product management for infrastructure, Dan's passionate about analyzing trends and emerging technologies to meet the needs of global customers. Prior to Hitachi Vantara, he spent 20 years at Dell where he was part of the team responsible for their merger with EMC.