更换SAP托管的经验:如何迁移系统而不痛苦不堪

更换SAP托管的经验:如何迁移系统而不痛苦不堪

或者有可能吗? 当然,SAP系统迁移是一个复杂而艰苦的过程,其成功需要所有参与者的良好协调工作。 而如果在短时间内进行迁移,任务就会变得更加复杂。 并不是每个人都决定这样做。 可能有几个原因。 例如,该过程本身漫长且组织复杂。 此外,还存在系统意外停机的风险。 或者客户不确定,在经历了这样的手术后,他们是否会获得与所付出的努力相称的收益。 不过,也有例外。

下面,我们将讨论客户在迁移和维护 SAP 系统过程中面临的困难,讨论为什么刻板印象并不总是符合现实,并分享一个案例研究,说明我们如何成功地将客户的系统迁移到 SAP 系统。新的基础设施建设仅用了三个多月的时间。

SAP系统托管

就在五年前,还很难想象客户会大量开始使用 SAP 应用程序的托管资源。 在大多数情况下,它们是在本地实施的。 然而,随着外包模式和云服务市场的发展,客户的世界观开始发生变化。 影响 SAP 选择云的论据是什么?

  • 对于刚刚计划实施SAP的初学者来说,云基础设施几乎是一个标准选择——资源可扩展以满足系统当前的需求,并且不愿意将资源转移到非核心能力的开发上。
  • 在拥有大型系统环境的公司中,在托管 SAP 系统的帮助下,CIO 可以达到质的不同水平的风险管理,因为合作伙伴对 SLA 负责。
  • 第三个最常见的论点是构建基础设施以实现高可用性和灾难恢复场景的成本高昂。
  • Factor 2027 – 供应商宣布在 2027 年终止对遗留系统的支持。 这意味着将数据库转移到 HANA,这需要现代化和购买新计算能力的成本。

俄罗斯的SAP托管市场现在可以说已经相当成熟了。 这为想要更改托管平台的客户提供了充足的机会。 然而,由于迁移程序的复杂性,此类项目理所当然地会引起企业的关注。 这迫使客户对服务提供商提出了更高的要求,他们不仅必须具备托管和维护 SAP 系统的卓越能力,而且还必须在迁移领域拥有成功的经验。

变更SAP托管有哪些困难?

托管不同。 与声明的服务水平不一致,许多“但是”和星号带有小文本保留,托管提供商的资源和能力有限,与客户的沟通缺乏灵活性,官僚作风,技术限制,技术支持能力低下专家,以及许多其他细微差别 - 这些只是客户在外包基础设施中运营其业务系统时可能遇到的陷阱的一小部分。 通常,对于客户来说,所有这些都留在阴影中,在多页合同的丛林中,并在使用服务的过程中出现。

在某些时候,客户会明显地意识到他所收到的服务水平与他的期望相去甚远。 这是一种寻找解决方案来纠正这种情况的催化剂,如果失败,当问题累积到极限并且变得非常痛苦时,他们会采取积极行动,以改变服务提供商的方向开发替代方案。

他们为什么要等到最后一刻? 原因很简单 - 为客户迁移系统的过程并不总是透明且易于理解的。 客户很难评估与迁移过程相关的实际风险。 我们可以说,客户的迁移是一种黑匣子:价格、系统停机时间、风险以及如何减轻这些风险都不清楚,总的来说,它是黑暗和可怕的。 就好像,如果不成功,那么高层和表演者都会头晕目眩。

SAP 是一个企业级系统,很复杂,而且,温和地说,并不便宜。 适当的预算用于它们的实施、修改和维护,企业的寿命取决于它们的可用性和正确运行。 现在想象一下停止一些大型生产的后果。 这些是财务损失,可以用大量零的数字来计算,以及声誉和其他同等重大的风险。

我们将分析从某个客户迁移 SAP 系统时每个阶段可能出现的困难。

准备与设计

迁移是一个包含许多不同部分的公式。 最重要的阶段之一是设计和准备目标(新)基础设施的阶段。

我们需要深入研究现有系统的实现及其架构。 在目标基础设施中,我们在某个地方重复了现有的解决方案,在某个地方补充和改进了它们,在某个地方重新设计了它们,经过深思熟虑并选择了解决方案以确保容错性和可用性,并尽可能地整合所有资源。

在设计过程中,进行了许多不同的练习,最终使我们能够为迁移做好尽可能多的准备,并考虑到各种细微差别和陷阱(稍后会详细介绍)。

我们最终得到的是基于我们的数据中心单独设计的私有云基础设施:

  • SAP HANA 专用物理服务器;
  • 用于应用服务器和基础设施服务的VMware虚拟化平台;
  • L2 VPN 数据中心之间的重复通信通道;
  • 两个主要存储系统,用于分隔产品和“其他物品”;
  • SRC 基于 Veritas Netbackup,具有独立的服务器、磁盘架和磁带库。

更换SAP托管的经验:如何迁移系统而不痛苦不堪

以下是我们如何从技术角度实现这一切。

树液

  • 为了有效地将存储用于高效的 HANA,我们使用共享磁盘,而不使用 SAP 进行系统数据库复制。 所有这些都包含在基于 Pacemaker 的主备 SUSE HAE 集群中。 是的,恢复时间比复制要长一点,但我们节省了一半的存储空间,从而节省了客户的预算。
  • 在预生产环境中,HANA集群被放弃,但技术上重复了生产配置。
  • 测试和开发环境分布在多台服务器上,没有 MCOS 配置中的集群。
  • 所有应用程序服务器均已虚拟化并托管在 VMware 中。

网络

  • 我们使用交换机堆栈将控制网络和生产网络的轮廓进行物理分离,将生产网络转向客户的数据中心。
  • 我们安装了足够数量的网络接口,以免混合大量流量。
  • 为了从存储系统传输数据,我们创建了经典的 FC SAN 工厂。

SHD

  • SAP 的生产和预生产负载留在全闪存阵列上。
  • 开发人员测试环境和基础设施服务被放置在单独的混合阵列上。

肠易激综合症

  • 使用 Veritas Netbackup 制作。
  • 我们在内置脚本中添加了一些内容来备份 MCOS 配置。
  • 我们将可操作的副本放在磁盘架上以便快速恢复,并使用磁带进行长期存储。

监控

  • 所有硬件、操作系统和 SAP 均安装在 Zabbix 下。
  • 我们在 Grafana 中收集了许多有用的仪表板。
  • 当警报发生时,Zabbix 可以在事件管理系统中创建请求;我们已在 Jira 上实现了它。 该信息也在 Telegram 频道中重复。

Telegram

更换SAP托管的经验:如何迁移系统而不痛苦不堪

HANA 的总体健康状况

更换SAP托管的经验:如何迁移系统而不痛苦不堪

SAP 应用程序服务器状态:

更换SAP托管的经验:如何迁移系统而不痛苦不堪

基础设施服务

  • 为了服务内部命名空间,建立了一个 DNS 服务器集群,该集群与客户的服务器同步。
  • 我们创建了一个单独的文件服务器用于数据交换。
  • 为了存储各种配置,添加了Gitlab。
  • 对于各种敏感信息,我们使用了 HashiCorp Vault。

迁移过程

一般来说,迁移过程由以下阶段组成:

  • 准备所有必要的项目文件;
  • 与当前提供商谈判 - 解决组织问题;
  • 项目新设备的采购、交付和安装;
  • 测试迁移和流程调试;
  • 系统转移、战斗迁移。

2019年XNUMX月底,我们签订了合同,然后设计了架构,与客户达成一致后,我们订购了必要的设备。

您首先需要关注的是设备的交货时间。 平均而言,为 SAP NAHA 交付满足软件制造商对硬件平台要求的认证硬件需要 10-12 周。 考虑到季节性(该项目的实施恰​​逢新年),这一周期可能会再延长一个月。 因此,有必要尽可能加快流程:我们与分销商供应商合作,同意通过飞机(而不是陆运和海运)加急交付。

XNUMX 月和 XNUMX 月用于准备迁移和接收部分设备。 我们在公有云的测试台上进行了准备工作,完成了所有主要步骤并发现了可能的困难和问题:

  • 为项目团队成员之间的互动制定详细的计划,并按分钟计时;
  • 以与目标基础设施中大致相同的方式为数据库和应用程序服务器构建了一个测试平台;
  • 配置必要的通信渠道和基础设施服务来测试集成的运行;
  • 制定切换方案;
  • 云还帮助我们创建预配置的虚拟机模板,然后我们只需将其导入并部署到目标环境即可。

元旦假期前夕,第一批设备抵达我们手中。 这使得在真实硬件上部署一些系统成为可能。 由于并非所有东西都已到达,我们连接了替换设备,我们设法与供应商和分销商就其供应达成一致。 我们在最后阶段收到了目标基础设施的残骸。
为了赶上最后期限,我们的工程师不得不牺牲新年假期,在 2 月 XNUMX 日假期期间开始准备目标基础设施。 是的,当它着火并且没有其他选择时,有时会发生这种情况。 企业的生存所依赖的系统性能处于危险之中。

迁移的一般顺序如下:首先是最不关键的系统(开发环境、测试环境),然后是生产系统。 迁移的最后阶段发生在一月底和二月初。

更换SAP托管的经验:如何迁移系统而不痛苦不堪

迁移过程的计划精确到分钟。 这是一份割接计划,其中列出了所有任务、完成时间和负责人。 所有步骤在测试迁移中都已经制定好了,因此在实时迁移中只需遵循计划并协调流程即可。

更换SAP托管的经验:如何迁移系统而不痛苦不堪

迁移分几个阶段系统地进行。 每个阶段有两个系统。

三个月冲刺的结果是系统在 CROC 数据中心全面运行。 总体而言,通过团队合作取得了积极的成果;整个过程中所有参与者的贡献和奉献是最大的。

客户在项目中的角色

与我们的客户即将离开的提供商进行沟通并不容易。 这是可以理解的;他们是对成功完成该项目感兴趣的人名单上的最后一个。 客户承担了升级和踩踏所有沟通问题的任务,并解决了这 100500%。 对此特别感谢他。 如果没有这种可行的参与过程,项目的结果可能会完全不同。

由于“前”提供商方面的流程正规化,基础设施支持由实际上远离问题的专家进行,当时仍然是他们的客户。 例如,导出同一数据库的过程可能需要一到五个小时。 然后这似乎是某种魔法,一个从未向我们透露的秘密。 也许技术支持工程师们在此期间沉思冥想,忘记了遥远的俄罗斯某个地方还有最后期限,工程师没有新年沙拉,客户在哭泣和痛苦……

项目结果

迁移的最后一步是转移系统以进行维护。

现在,我们为客户请求提供单一窗口服务,并与我们的合作伙伴殷智咨询一起涵盖与支持基础设施组件和 SAP 基础相关的整个任务范围。 客户已经在私有云中生活了六个月。 以下是这段时间服务案例的统计:

  • 90 起事件(20% 在不涉及客户的情况下得到解决)
  • 在 SLA 内解决 – 100%
  • 计划外的系统关闭 – 0

如果您遇到与我们客户类似的问题,并且想了解更多如何解决这些问题,请写信至: [电子邮件保护]

来源: habr.com

添加评论