温州建设诚信网站,制作好的网页,外包公司能不能去,最近楼市行情走势图片描述从2001~2021#xff0c;20年中博主亲手搭建或深度运维的企业SAP系统#xff0c;它们由多种服务器软、硬件#xff0c;数据库构成。从第一套系统开始#xff0c;博主就一直研究并致力于搭建出完美架构的SAP系统#xff0c;这个课题#xff0c;今天貌似在S4 HANA的… 图片描述从2001~202120年中博主亲手搭建或深度运维的企业SAP系统它们由多种服务器软、硬件数据库构成。从第一套系统开始博主就一直研究并致力于搭建出完美架构的SAP系统这个课题今天貌似在S4 HANA的X86架构上最终完结了。
一、博主追求的完美架构是什么呢
1、架构应该尽量使用硬件最大资源。2001年的项目中硬件资源是羸弱的DB所在的主机负载总是很高在2007年新项目中博主尝试把数据库放在热备机上提高服务器性能。
2、架构应该尽最大限度保证服务器高可用。2012年虚拟化盛行在接手的项目架构中虽然SAP服务软件层有单点但在硬件底层有冗余无单点让博主体会到了轻松运维的便利。
3、架构应该让管理员管理轻松故障出现时完全可控包括数据库。2014年新项目中硬件已经非常强大安装时我们取消了使用UNIX双机集群HA软件这样的架构非常简单直接对SAP服务器软件管理减少了HA软件层出现问题识别快速切换出故障点也是一气呵成。这样解决问题的时间比原来提高了10倍不止博主因此有了多余的时间喝喝茶学习ABAP模块成为了一名ABAPer。 站在2021年回首从前SAP BASIS服务器系统管理这条路一路走来在erphome、大榕树QQ群、实际项目中结识了很多SAP资深玩家大家讨论最纯粹的技术何其快哉。博主所有经手过的系统也都做到了没有重大事故发生这也是博主最欣慰和自豪的事情。当然SAP BASIS技术工作也就像黑洞一样吞噬了博主20年大部分的精力不过BASIS工作其实就是计算机软、硬件、网络技术的集合还是满和自己胃口。 现在的博主已经不像从前那个少年热衷于技术的细节而是更注重更高层级的东西了。也许细节都经历过太多次了也许是思想升华了现在更关注解决事情的方法比如愿意冒险去实现一个完美的架构而不愿意去调整什么ST02中的参数。比如在部署前愿意去花很多沟通协调的时间从顶层解决曾经出现的痛点而不愿去一遍又一遍地重复解决部署后的问题。 二、S4 hana出现以前架构的痛点
1、UNIX环境技术门槛高。
2、小型机硬件和SAN环境架构昂贵硬件很难复制某种意义上看整套架构是一个单点因为数据机房中没有更多的UNIX硬件可以测试或备份。
3、无论是HP-UX的集群软件还是AIX的集群软件在故障点不能正常切换的故障率超高。其实根本原因是SAP服务器设计和HA软件集成的问题SAP集群通过NFS文件系统共享同步服务器配置数据故障的切换前提是NFS功能完整但是故障发生时多半就是主机死掉这个时候NFS服务也一起失效了如果什么都不做必然影响切换。如果要排除NFS功能死掉的情况下能够顺利切换就需要重置服务器实例前在OS脚本里面KILL和重启实例请问SAP这是一个服务器集群的正常设计吗 三、S4 hana三机架构解决了什么痛点
1、X86环境没有技术门槛。
2、在X86环境中现在的硬件已经非常强大PC server普遍拥有大内存超多线程CPU和SSD的高IO在企业的机房里x86 PC server很好的获得如果整套的SAP服务器垮掉只要有HANA数据库的全库备份重建一套系统那是很快捷的。
3、在ECC6开始的后面版本中SAP开始把ASCS服务实例分离出来最初有案例开始把这个ASCS实例单独安装在一套冗余的硬件存储上来保证切换时MS服务和“锁对象清单”的完整但最初它只能做到硬件层的冗余。现在X86的虚拟机技术能够对整个服务安装的服务器硬件软件实现冗余。三机架构只要用VM平台提供的HA功能保护ASCS安装的整个服务器减少了原来UNIX HA软件的资源块打包调度切换再不需要自己去OS里面写脚本kill实例来保证切换正常了。最终的结果就是BASIS甩掉了UNIX厂家HA这块黑盒子。
4、在DB层面因为全新的软硬件设计HANA数据库备份恢复的技术门槛大幅降低管理及其便利。备份一次HANA全库的耗时是按分钟计算恢复一次全库也是在全图形化的管理界面中轻松完成。 如果今天你安装的S4服务器你还在使用suse 里面的HA软件来实现故障切换你一定还会被原来老架构的一些痛点困扰。
Today, if the S4 server you installed is still using the HA software in SUSE to realize the fail over, you will certainly be troubled by some pain points of the old architecture.
