简介华为与SAP联合打造的企业级内存计算平台解决方案面向需要实时处理海量业务数据、加速决策的IT架构师与数字化转型负责人。方案以SAP HANA为核心涵盖认证服务器、OceanStor存储、云平台及全渠道零售创新应用并给出ECI、良品铺子等落地案例与性能提升数据。资源为单个PPT演示文稿共1个pptx文件压缩包仅3.14MB内容聚焦SAP HANA一体机构成、中小企业/大型企业部署选型、Hadoop大数据平台对接等核心模块也涉及DA200数据压缩卡、ES3000 NVMe SSD等关键组件。目前已有186人学习浏览适合用于方案汇报、技术选型参考或售前材料改编。1. 华为SAP HANA行业解决方案它解决的从来不是数据库性能问题“华为SAP HANA行业解决方案”听起来像一份售前PPT但对真正要交付的工程师来说它是一套从硬件选型到部署调优的完整路线图。SAP HANA本身已经把内存计算做到极致绝大多数项目瓶颈不在数据库引擎而在底层基础设施内存配比、日志卷延迟、网络丢包、内核参数任何一个环节没对齐HANA都会用各种诡异方式惩罚你。这套方案的价值就是把华为服务器、存储、交换机与SAP HANA的组合路径固定下来让实施团队少做选择题。适合正在做S/4迁移、HANA新装或灾备建设的架构师、Basis和DBA也适合拿了方案PPT却不知道第一台机器该怎么开机的实施新人。这篇笔记不画架构大图只讲我照着这套思路落地时实际调过的参数、跑过的命令和踩过的坑。2. 拆开方案的三层架构计算、存储与网络怎么选才不翻车华为SAP HANA行业解决方案落到物理上就是三层计算层决定HANA能跑多快存储层决定数据安全与恢复速度网络层决定分布式和灾备场景的稳定性。这三层选型环环相扣多数实施团队翻车都翻在只盯着CPU核数忽视了存储和网络。2.1 计算层Intel认证机型与鲲鹏机型在HANA场景里的取舍先说结论生产环境优先看SAP官方认证清单再结合运维体系选平台而不是盲目追求某个CPU品牌。SAP HANA对底层硬件是出了名的挑剔。SAP维护一份经过认证的服务器清单型号、CPU代际、内存插法、固件版本都在列不在清单里的机器SAP原则上不提供生产支持。华为的HANA认证机型实际有两条线常规的Intel x86机架服务器以及基于鲲鹏处理器的TaiShan系列。Intel平台生态最稳所有SAP组件、第三方备份工具、监控插件都是现成的鲲鹏平台在能效比和省电上有明显优势尤其适合大规模横向扩展节点但前提是你的SAP版本和解决方案管理器版本确实在鲲鹏认证范围内。我一般会建议客户这样决策新建核心生产环境先拿SAP认证清单逐项匹配选Intel认证机型兜底开发测试、非核心分析负载可以放到鲲鹏节点上节省能耗预算。很多团队在建HANA集群之前根本不查认证清单等SAP开support ticket的时候才发现机型不在列表里这种翻车是最不值得的。计算层还有两个容易忽略的细节。第一是内存通道和插槽布局HANA是内存数据库内存带宽和NUMA拓扑直接影响性能四路机器的内存必须按厂商建议把通道插满不能只插一半第二是CPU频率策略华为服务器BIOS默认可能是均衡模式对HANA这种延迟敏感型负载要把电源策略切到Performance模式否则SQL响应时间会漂移得让人抓狂。2.2 存储层本地NvMe日志卷与全闪数据卷的分工逻辑HANA的存储设计有个铁律数据卷和日志卷要分开且日志卷的延迟必须远低于数据卷。原因是HANA的持久化机制是redo log先行事务提交时先写日志卷之后由后台把内存数据刷到数据卷。日志卷哪怕偶尔慢一下所有写事务的提交延迟都会跟着变慢这个影响是全局性的。华为这套方案常见的落地做法是日志卷放在服务器本地NvMe SSD上数据卷放在华为OceanStor全闪存阵列上通过FC或RoCE连接。本地NvMe的优势是延迟低通常在几十微秒级别能扛住高频事务提交全闪阵列的优势是容量扩展和快照能力数据卷通常要保留多个历史快照用于备份和容灾。如果预算有限也可以数据卷和日志卷都用本地NvMe但备份就得靠外部存储或备份软件传到第二台机器。这里要特别提醒不要把日志卷放到NAS或远程存储上。有些项目为了省事直接用一个大的NAS挂载点同时放data和log结果一到业务高峰日志提交排队HANA的保存点机制被拖到极限应用侧就会出现大量SQL锁等待和超时。华为方案里对日志卷的延迟建议是越低越好实际交付中我至少会要求日志卷的fio写延迟不超过0.5毫秒这个档位否则上生产前就得换配置。2.3 网络层华为交换机上无损网络对系统复制的关键影响网络层在很多HANA项目里是被低估的。单机部署时网络无所谓但一旦做HA或DRHANA系统复制依赖网络持续同步日志此时网络质量直接决定数据丢失窗口和恢复时间。HANA系统复制的原理是主库把redo log通过网络实时传到备库备库不停应用这些日志。如果网络存在丢包TCP重传会导致日志延迟堆积主库的事务提交并不会等备库但一旦主库故障备库的数据差距会远超预期。华为这套方案里通常配CE系列数据中心交换机支持PFC和ECN机制可以构建无损以太网环境为RoCE或普通TCP流量提供大缓冲区和无丢包转发。实际操作时我一般会在交换机上做几个固定动作给HANA系统复制流量划分专用VLAN单独设置队列调度优先级开启PFC并给对应队列配置无丢包能力如果用的是RoCE网卡必须确保交换机的ECN配置和网卡参数匹配。很多团队配了RDMA网卡却忘记在交换机侧开PFC结果RoCE流量在拥塞时大量丢包性能反而不如普通千兆网这就是典型的“黑匣子”问题——看起来硬件全是高配实际链路根本没有无损能力。网络层的验证不能只看ping通没通。上线前我会用iperf3压满带宽观察重传率重传率只要超过万分之一HANA系统复制延迟就可能波动。另外延迟测试要用UDP模式测TCP的拥塞控制会掩盖问题。3. 把方案落到物理机SAP HANA部署的最小实操路径架构选型定了之后真正的体力活才开始。HANA安装在华为服务器上的流程不算复杂但每一步都有坑尤其是内核参数、文件系统布局和安装命令这三个环节。下面这条路径是我在多个项目里反复用过的你照着做能少折腾一轮。3.1 装系统前先改掉3个内核参数HANA对Linux内核有硬性要求SAP的HANA安装前置检查会逐个核对。用SLES for SAP Applications镜像装完系统后先不要急着跑安装程序先改内核参数。# SLES 15 for SAP Applications写入 /etc/sysctl.d/99-sap-hana.conf vm.swappiness10 vm.max_map_count2147483647 net.ipv4.tcp_rmem4096 16384 4194304 net.ipv4.tcp_wmem4096 16384 4194304 fs.aio-max-nr1048576 kernel.numa_balancing0 # 让配置立即生效 sysctl --system配置生效后用sysctl kernel.numa_balancing确认返回值是0。这个参数的坑在于某些SLES版本安装时默认开启NUMA平衡如果不关HANA的线程可能被内核在NUMA节点间迁移导致内存访问延迟忽高忽低业务SQL性能飘忽不定。vm.max_map_count是HANA启动时映射大量内存段的保障默认值只有65530不调大启动过程就会报内存映射失败。vm.swappiness设置为10是为了告诉内核尽量别换出HANA的页HANA的页换到swap基本等于性能雪崩。还有两个文件系统层面的准备数据卷挂载点建议格式化成XFS块大小为4KHANA官方对XFS的支持最完整日志卷单独分一个文件系统不要和数据卷共用挂载点。挂载时要在/etc/fstab里加上noatime和nobarrier的逻辑——注意nobarrier只在硬件具备断电保护能力时使用华为服务器配NvMe盘时一般可以开但如果是普通SATA盘建议保留barrier。3.2 用hdblcm完成无图形化安装的完整命令图形界面安装HANA在远程机房里根本不现实几乎都靠hdblcm命令行。把介质挂载到/hana/media之后切换到root执行下面这组命令cd /hana/media ./hdblcm --actioninstall \ --sidHDB \ --number00 \ --sapadm_passwordYourAdminPass \ --system_passwordYourSystemPass \ --root_user_passwordYourRootPass \ --sapmnt/sapmnt \ --install_hana_path/hana/shared \ --datavolume/hana/data/HDB \ --logvolume/hana/log/HDB \ --backup_volume/hana/backup \ --componentsserver,client \ --silent这条命令的核心逻辑是一次性把数据库实例、客户端和目录结构都初始化好。--sid是三字母实例名尽量避开SAP保留字--number00是实例编号决定端口号基数00实例的SQL端口是30015系统DB端口是30215--datavolume和--logvolume必须指向独立文件系统这点前面强调过不能图省事写同一个路径--backup_volume指定备份目录生产环境一般放到独立存储或另一台机器挂载过来的路径。密码设置是新手最容易卡住的环节。SAP要求系统密码至少有8位且包含大小写字母和数字但别用!、、$这些特殊字符因为hdblcm会把命令行参数直接传给底层shell特殊字符会造成转义错乱报错信息还很隐晦。安装完成后不要急着删安装日志/var/tmp下的hdblcm_install_*日志文件在排查失败原因时非常有用。3.3 Studio连库前的4项检查清单数据库安装完成不等于交付。HANA Studio连接是一个高频故障点我每次都会按下面4项顺序检查能排除90%的“明明装好了却连不上”的情况第一确认实例进程状态。用sapcontrol -nr 00 -function GetProcessList检查hdbnameserver、hdbindexserver、hdbcompileserver这些进程必须显示GREEN。第二用hdbsql -u SYSTEM -n localhost:30015做本机登录测试这一步能排除Studio配置问题如果本机都登不进去说明实例本身就没起来。第三检查监听地址HANA默认监听所有网卡但如果安装时指定了主机名而系统hosts解析指向127.0.0.1外部机器就连不上这时候/etc/hosts要保证主机名映射到业务网卡IP而不是localhost。第四检查防火墙或安全组华为服务器如果启用了firewalld需要放行30015、30215和8000端口很多机房交付时操作系统防火墙是默认开启的HANA Studio连接超时十有八九是这个原因。做完这四项检查HANA实例的基本交付就算成立了。但这只是开始参数调优才决定它能不能扛住真实业务。4. HANA on华为硬件的参数调优NUMA、大页与持久化怎么一次设对HANA安装完成后默认参数能跑但不能直接上生产。我见过太多项目把HANA装完就交给业务方头一天跑查询没问题第二天业务导入数据量大一点数据库直接OOM或者保存点超时。参数调优分三个层面操作系统、HANA配置、存储对齐。4.1 大页与NUMA先让操作系统不拖后腿HANA 2.0之后内存管理采用透明大页和内部大页结合的做法操作系统层面不再强制要求手动分配hugepages但有两个参数必须注意透明大页要关闭NUMA平衡要关闭。# 关闭透明大页写入 /etc/default/grub 后重建grub配置 # 将 transparent_hugepagenever 追加到 GRUB_CMDLINE_LINUX grub2-mkconfig -o /boot/grub2/grub.cfg reboot # 确认状态 cat /sys/kernel/mm/transparent_hugepage/enabled # 期望输出: always madvise [never]透明大页对HANA的影响是玄学中翻车率最高的一个。THP开启时内核会把内存页合并成2MB的大页表面上减少TLB miss但对HANA这种随机访问密集的数据库页合并过程会造成延迟毛刺应用到SQL上就是偶尔一次查询慢得离谱。SAP官方SAP Note里明确要求生产环境禁用THP。华为服务器BIOS里如果开了超线程HANA能识别出物理核和逻辑核不需要额外配置但BIOS里的NUMA相关选项建议保持默认不要手动关闭NUMAHANA内部的多实例部署反而需要感知NUMA拓扑来分配内存。4.2 global.ini内存分配与持久化路径的正确写法HANA的核心配置在/hana/shared/HDB/global/hdb/custom/config/global.ini修改时要通过HANA的配置系统写不能直接编辑文件然后指望热生效。# 保存为 /usr/sap/HDB/HDB00/global/hdb/custom/config/global.ini 后重启实例 [database_internal] number_of_trace_files 30 [persistence] basepath_datavolume /hana/data/HDB basepath_logvolume /hana/log/HDB load_unit page savepoint_interval_s 300 [memorymanager] global_allocation_limit 471859200 asynchronous_statistics_update true [system_replication] replication_mode synchronous replication_policy fullsyncglobal_allocation_limit的单位是MB这里以512GB物理内存为例给HANA分配450GB。这个值不是越大越好要留出操作系统和SAP运维工具的内存余量。常见做法是物理内存的88%到92%之间如果本机还要跑B1或Solution Manager比例还要再降。savepoint_interval_s 300表示每5分钟生成一次保存点保存点期间数据卷写入压力比较大如果存储延迟高要相应拉长到600秒但拉长会增加故障恢复时间需要权衡。内存参数调整后用HDBSQL -U SYSTEM SELECT * FROM M_MEMORY_ALLOCATION检查实际分配情况重点看EXCLUDED_MEMORY的大小如果这个值异常大说明内核参数或系统内存本身有问题HANA能用的内存被压制了。这类问题在纸面上看不出来只有落到参数文件才暴露。4.3 multipath与文件系统对齐存储参数的隐藏雷区华为OceanStor全闪阵列通过FC组多路径时Linux自带的multipath工具配置不当会让HANA的数据卷性能缩水一半。最常见的错误是没配置path_grouping_policy导致多条路径被当成独立磁盘处理IO在两个路径间反复切换延迟升高。检查multipath配置时确认/etc/multipath.conf中存在下面这段defaults { path_grouping_policy failover path_selector round-robin 0 failback immediate user_friendly_names yes }这个配置的意义是让同一LUN的路径聚合成一个多路径设备并且故障时自动切换。HANA的持久化对IO路径稳定性要求极高路径抖动一次日志提交就可能超时SAP控制台会直接把这个实例标记为“unhealthy”。每次改完multipath配置要执行systemctl reload multipathd然后multipath -ll查看路径状态Active路径数量必须和实际物理链路数一致。文件系统对齐方面XFS格式化时块大小用4K这能避免HANA的8K或16K IO与文件系统块错位导致读放大。确认命令是xfs_info /hana/data如果输出里显示bsize4096就对了。到这里操作系统、数据库和存储三层的参数基本对齐。这套组合拳打完HANA在华为硬件上才算真正站住了脚。5. 避坑与排查从Studio连不上到系统复制翻车的5条记录这一章是血泪经验集合。以下5个问题我在不同项目里反复见过每一条都按现象、原因、解决的顺序写清楚你可以当成排错手册直接查。5.1 现象安装检查报 kernel.numa_balancing 不通过现象hdblcm跑到前置检查时日志里明确写着kernel.numa_balancing is not disabled安装进程直接终止。原因SLES 15默认把numa_balancing置为1这个参数控制内核是否自动迁移线程到其他NUMA节点。HANA的SAP Note 2205917要求必须关闭因为线程迁移会导致内存访问从本地节点变成远程节点延迟增加好几倍。解决按第3.1节写入/etc/sysctl.d/99-sap-hana.conf并执行sysctl --system。注意某些云环境或虚拟机里宿主机的内核参数不受客户机控制这时候要在启动参数里加numa_balancingdisable然后重启生效。对策不复杂但这个问题在物理机上验证最简单。5.2 现象重启之后HANA起不来日志卷说满就满现象机房意外断电后重启服务器HANA实例起不来检查日志报redo log disk full明明安装时/hana/log分配了空间存储也远没到容量上限。原因HANA的redo log文件按分区预分配每个分区大小由log_partition_size决定默认值是数据卷大小的八分之一。如果日志卷本身分得小或者数据卷增长后日志分区自动变大而日志卷没有同步扩容就会触发这个错误。很多项目安装时日志卷按“能放下文件就行”的思维给20GB等数据卷涨到几百GBreod日志分区需要好几个GB20GB瞬间被占满。解决日志卷至少按数据卷的20%到30%规划512GB数据卷对应日志卷不小于120GB已经翻车的情况下用hdbcons执行mm log resize命令调整日志分区大小然后重启实例。这个问题在规划阶段没有后悔药只能靠早规划、早验证。5.3 现象主库一忙系统复制延迟从秒级跳到分钟级现象HANA系统复制搭好后空闲时备库延迟为0业务高峰一到主库日志堆积备库延迟飙升到好几分钟。检查SAP控制台系统复制状态是ACTIVE但进程SAPHanaSystemReplication一直处于同步等待中。原因这是典型的网络链路问题通常不是带宽不够而是交换机拥塞导致丢包。HANA系统复制采用异步或同步模式持续传日志TCP丢包触发重传后备库的日志应用连续落后更隐蔽的是网络设备的默认Buffer太小瞬时的突发流量在交换机端口直接丢弃。解决把这个流量放到独立VLAN并配置服务质量策略。华为CE系列交换机上做法是给对应端口配置PFC并设置一个单独的队列给它保证这个队列在任何拥塞场景下都不丢包。做完配置后用hdbnsutil -sr_state连续观察几次延迟必须回到秒级以内。这条坑最容易被误判为数据库压力大实际上是网络黑匣子一定要用丢包率数据说话。5.4 现象备份恢复后表能查但应用报数据区错误现象从OceanStor上的备份文件恢复到一台新测试机数据库能启动SELECT也能跑但业务应用跑一段后抛出invalid page之类的错误。原因文件系统损坏或块大小错位。OceanStor上的快照备份传到测试机后测试机文件系统用了ext4而HANA数据文件写在XFS上的时候块边界已经对齐ext4的块映射逻辑无法原样还原部分页被读成了错误数据。恢复流程里只要文件系统类型或块大小和源机不一致就可能出现这种“表能查数据脏”的现象。解决恢复HANA备份的目标机器文件系统类型必须和源机保持一致XFS就XFS块大小也必须一致。建议每次恢复后跑一次HDBSQL -U SYSTEM SELECT COUNT(*) FROM M_DATA_VOLUME_STATISTICS再执行一次全库校验hdbsql -U SYSTEM ALTER SYSTEM RECLAIM DATA VOLUME确认数据卷没有逻辑错误再交给业务方。5.5 现象负载不高但SQL就是慢莫名其妙现象HANA所在服务器CPU利用率只有20%内存充足I/O也没有排队但一个简单的单表查询要跑十几秒而且时间飘忽不定。DBA查了执行计划没有问题数据量也不大。原因这种“玄学”性能问题在华为服务器上多半是CPU频率策略或NUMA平衡在作怪。BIOS默认的电源策略如果是均衡模式CPU降频后HANA的SQL响应时间会明显变差HANA对主频敏感。另一种可能是透明大页没关第4.1节说过THP合并页面的过程会造成随机毛刺。解决BIOS设置为Performance模式关闭C-states深度节能然后确认内核参数里transparent_hugepage状态是never。验证方法很简单同一个SQL连续跑10次取P95时间如果性能抖动超过30%优先检查这两项不要一上来就去调SQL。这几条避坑记录覆盖了安装、存储、网络、恢复和性能基本是目前国产化项目里最常见的重灾区值得直接截屏存档。6. 上线前用HANA自带工具做一次可信的压测参数和架构都到位后最后一步是压测验证。很多人喜欢拿第三方压测工具跑来跑去其实HANA自带工具已经够用关键是方法要对。6.1 用hdbsql跑一个贴近业务的压力脚本首先确认系统表和业务模拟表能不能承受高并发读取。下面这段脚本在HANA SQL控制台里循环读系统表模拟OLTP场景下的高频读操作DO BEGIN DECLARE i INTEGER : 0; DECLARE ts TIMESTAMP; WHILE i 30 DO SELECT COUNT(*) INTO ts FROM SYS.TABLE_STATISTICS; COMMIT; i : i 1; END WHILE; END;看一下整体耗时和单个迭代的响应时间这个值稳定说明HANA基本健康。真实业务压测时把这个脚本里的表换成核心业务表但你还没做数据导入的话可以先跑系统表验证元数据访问路径。COMMIT必须保留否则HANA会把会话保持在一个隐式事务里锁和持久化行为就不是OLTP形态了。6.2 用fio验证日志卷等待时间比看CPU更管用数据库压测跑出来的数字好看不代表存储没问题。我每次都要用fio单独打日志卷看它在高IO压力下的延迟fio --namehana-log-test \ --ioenginelibaio --direct1 \ --rwrandwrite --bs4k --numjobs8 --iodepth32 \ --size2G --runtime60 --time_based \ --filename/hana/log/HDB/fio_testfile重点看lat (usec)的avg和p99。日志卷写延迟p99如果超过500微秒HANA在高峰期提交日志就会吃紧建议把日志卷换成更快的NvMe盘或调整OceanStor的配置。这里的direct1是绕过文件系统缓存直接测块设备这样的数字才反映存储硬实力。这个方案值不值得投入最终就看这些数字能不能稳定。我个人习惯是每次交付都保存一份压测基线之后业务反馈变慢翻出基线一对比是数据库问题还是基础设施退化一目了然。希望帮到你。本文还有配套的精品资源点击获取 华为SAP HANA方案落地指南：从硬件选型到调优避坑
简介华为与SAP联合打造的企业级内存计算平台解决方案面向需要实时处理海量业务数据、加速决策的IT架构师与数字化转型负责人。方案以SAP HANA为核心涵盖认证服务器、OceanStor存储、云平台及全渠道零售创新应用并给出ECI、良品铺子等落地案例与性能提升数据。资源为单个PPT演示文稿共1个pptx文件压缩包仅3.14MB内容聚焦SAP HANA一体机构成、中小企业/大型企业部署选型、Hadoop大数据平台对接等核心模块也涉及DA200数据压缩卡、ES3000 NVMe SSD等关键组件。目前已有186人学习浏览适合用于方案汇报、技术选型参考或售前材料改编。1. 华为SAP HANA行业解决方案它解决的从来不是数据库性能问题“华为SAP HANA行业解决方案”听起来像一份售前PPT但对真正要交付的工程师来说它是一套从硬件选型到部署调优的完整路线图。SAP HANA本身已经把内存计算做到极致绝大多数项目瓶颈不在数据库引擎而在底层基础设施内存配比、日志卷延迟、网络丢包、内核参数任何一个环节没对齐HANA都会用各种诡异方式惩罚你。这套方案的价值就是把华为服务器、存储、交换机与SAP HANA的组合路径固定下来让实施团队少做选择题。适合正在做S/4迁移、HANA新装或灾备建设的架构师、Basis和DBA也适合拿了方案PPT却不知道第一台机器该怎么开机的实施新人。这篇笔记不画架构大图只讲我照着这套思路落地时实际调过的参数、跑过的命令和踩过的坑。2. 拆开方案的三层架构计算、存储与网络怎么选才不翻车华为SAP HANA行业解决方案落到物理上就是三层计算层决定HANA能跑多快存储层决定数据安全与恢复速度网络层决定分布式和灾备场景的稳定性。这三层选型环环相扣多数实施团队翻车都翻在只盯着CPU核数忽视了存储和网络。2.1 计算层Intel认证机型与鲲鹏机型在HANA场景里的取舍先说结论生产环境优先看SAP官方认证清单再结合运维体系选平台而不是盲目追求某个CPU品牌。SAP HANA对底层硬件是出了名的挑剔。SAP维护一份经过认证的服务器清单型号、CPU代际、内存插法、固件版本都在列不在清单里的机器SAP原则上不提供生产支持。华为的HANA认证机型实际有两条线常规的Intel x86机架服务器以及基于鲲鹏处理器的TaiShan系列。Intel平台生态最稳所有SAP组件、第三方备份工具、监控插件都是现成的鲲鹏平台在能效比和省电上有明显优势尤其适合大规模横向扩展节点但前提是你的SAP版本和解决方案管理器版本确实在鲲鹏认证范围内。我一般会建议客户这样决策新建核心生产环境先拿SAP认证清单逐项匹配选Intel认证机型兜底开发测试、非核心分析负载可以放到鲲鹏节点上节省能耗预算。很多团队在建HANA集群之前根本不查认证清单等SAP开support ticket的时候才发现机型不在列表里这种翻车是最不值得的。计算层还有两个容易忽略的细节。第一是内存通道和插槽布局HANA是内存数据库内存带宽和NUMA拓扑直接影响性能四路机器的内存必须按厂商建议把通道插满不能只插一半第二是CPU频率策略华为服务器BIOS默认可能是均衡模式对HANA这种延迟敏感型负载要把电源策略切到Performance模式否则SQL响应时间会漂移得让人抓狂。2.2 存储层本地NvMe日志卷与全闪数据卷的分工逻辑HANA的存储设计有个铁律数据卷和日志卷要分开且日志卷的延迟必须远低于数据卷。原因是HANA的持久化机制是redo log先行事务提交时先写日志卷之后由后台把内存数据刷到数据卷。日志卷哪怕偶尔慢一下所有写事务的提交延迟都会跟着变慢这个影响是全局性的。华为这套方案常见的落地做法是日志卷放在服务器本地NvMe SSD上数据卷放在华为OceanStor全闪存阵列上通过FC或RoCE连接。本地NvMe的优势是延迟低通常在几十微秒级别能扛住高频事务提交全闪阵列的优势是容量扩展和快照能力数据卷通常要保留多个历史快照用于备份和容灾。如果预算有限也可以数据卷和日志卷都用本地NvMe但备份就得靠外部存储或备份软件传到第二台机器。这里要特别提醒不要把日志卷放到NAS或远程存储上。有些项目为了省事直接用一个大的NAS挂载点同时放data和log结果一到业务高峰日志提交排队HANA的保存点机制被拖到极限应用侧就会出现大量SQL锁等待和超时。华为方案里对日志卷的延迟建议是越低越好实际交付中我至少会要求日志卷的fio写延迟不超过0.5毫秒这个档位否则上生产前就得换配置。2.3 网络层华为交换机上无损网络对系统复制的关键影响网络层在很多HANA项目里是被低估的。单机部署时网络无所谓但一旦做HA或DRHANA系统复制依赖网络持续同步日志此时网络质量直接决定数据丢失窗口和恢复时间。HANA系统复制的原理是主库把redo log通过网络实时传到备库备库不停应用这些日志。如果网络存在丢包TCP重传会导致日志延迟堆积主库的事务提交并不会等备库但一旦主库故障备库的数据差距会远超预期。华为这套方案里通常配CE系列数据中心交换机支持PFC和ECN机制可以构建无损以太网环境为RoCE或普通TCP流量提供大缓冲区和无丢包转发。实际操作时我一般会在交换机上做几个固定动作给HANA系统复制流量划分专用VLAN单独设置队列调度优先级开启PFC并给对应队列配置无丢包能力如果用的是RoCE网卡必须确保交换机的ECN配置和网卡参数匹配。很多团队配了RDMA网卡却忘记在交换机侧开PFC结果RoCE流量在拥塞时大量丢包性能反而不如普通千兆网这就是典型的“黑匣子”问题——看起来硬件全是高配实际链路根本没有无损能力。网络层的验证不能只看ping通没通。上线前我会用iperf3压满带宽观察重传率重传率只要超过万分之一HANA系统复制延迟就可能波动。另外延迟测试要用UDP模式测TCP的拥塞控制会掩盖问题。3. 把方案落到物理机SAP HANA部署的最小实操路径架构选型定了之后真正的体力活才开始。HANA安装在华为服务器上的流程不算复杂但每一步都有坑尤其是内核参数、文件系统布局和安装命令这三个环节。下面这条路径是我在多个项目里反复用过的你照着做能少折腾一轮。3.1 装系统前先改掉3个内核参数HANA对Linux内核有硬性要求SAP的HANA安装前置检查会逐个核对。用SLES for SAP Applications镜像装完系统后先不要急着跑安装程序先改内核参数。# SLES 15 for SAP Applications写入 /etc/sysctl.d/99-sap-hana.conf vm.swappiness10 vm.max_map_count2147483647 net.ipv4.tcp_rmem4096 16384 4194304 net.ipv4.tcp_wmem4096 16384 4194304 fs.aio-max-nr1048576 kernel.numa_balancing0 # 让配置立即生效 sysctl --system配置生效后用sysctl kernel.numa_balancing确认返回值是0。这个参数的坑在于某些SLES版本安装时默认开启NUMA平衡如果不关HANA的线程可能被内核在NUMA节点间迁移导致内存访问延迟忽高忽低业务SQL性能飘忽不定。vm.max_map_count是HANA启动时映射大量内存段的保障默认值只有65530不调大启动过程就会报内存映射失败。vm.swappiness设置为10是为了告诉内核尽量别换出HANA的页HANA的页换到swap基本等于性能雪崩。还有两个文件系统层面的准备数据卷挂载点建议格式化成XFS块大小为4KHANA官方对XFS的支持最完整日志卷单独分一个文件系统不要和数据卷共用挂载点。挂载时要在/etc/fstab里加上noatime和nobarrier的逻辑——注意nobarrier只在硬件具备断电保护能力时使用华为服务器配NvMe盘时一般可以开但如果是普通SATA盘建议保留barrier。3.2 用hdblcm完成无图形化安装的完整命令图形界面安装HANA在远程机房里根本不现实几乎都靠hdblcm命令行。把介质挂载到/hana/media之后切换到root执行下面这组命令cd /hana/media ./hdblcm --actioninstall \ --sidHDB \ --number00 \ --sapadm_passwordYourAdminPass \ --system_passwordYourSystemPass \ --root_user_passwordYourRootPass \ --sapmnt/sapmnt \ --install_hana_path/hana/shared \ --datavolume/hana/data/HDB \ --logvolume/hana/log/HDB \ --backup_volume/hana/backup \ --componentsserver,client \ --silent这条命令的核心逻辑是一次性把数据库实例、客户端和目录结构都初始化好。--sid是三字母实例名尽量避开SAP保留字--number00是实例编号决定端口号基数00实例的SQL端口是30015系统DB端口是30215--datavolume和--logvolume必须指向独立文件系统这点前面强调过不能图省事写同一个路径--backup_volume指定备份目录生产环境一般放到独立存储或另一台机器挂载过来的路径。密码设置是新手最容易卡住的环节。SAP要求系统密码至少有8位且包含大小写字母和数字但别用!、、$这些特殊字符因为hdblcm会把命令行参数直接传给底层shell特殊字符会造成转义错乱报错信息还很隐晦。安装完成后不要急着删安装日志/var/tmp下的hdblcm_install_*日志文件在排查失败原因时非常有用。3.3 Studio连库前的4项检查清单数据库安装完成不等于交付。HANA Studio连接是一个高频故障点我每次都会按下面4项顺序检查能排除90%的“明明装好了却连不上”的情况第一确认实例进程状态。用sapcontrol -nr 00 -function GetProcessList检查hdbnameserver、hdbindexserver、hdbcompileserver这些进程必须显示GREEN。第二用hdbsql -u SYSTEM -n localhost:30015做本机登录测试这一步能排除Studio配置问题如果本机都登不进去说明实例本身就没起来。第三检查监听地址HANA默认监听所有网卡但如果安装时指定了主机名而系统hosts解析指向127.0.0.1外部机器就连不上这时候/etc/hosts要保证主机名映射到业务网卡IP而不是localhost。第四检查防火墙或安全组华为服务器如果启用了firewalld需要放行30015、30215和8000端口很多机房交付时操作系统防火墙是默认开启的HANA Studio连接超时十有八九是这个原因。做完这四项检查HANA实例的基本交付就算成立了。但这只是开始参数调优才决定它能不能扛住真实业务。4. HANA on华为硬件的参数调优NUMA、大页与持久化怎么一次设对HANA安装完成后默认参数能跑但不能直接上生产。我见过太多项目把HANA装完就交给业务方头一天跑查询没问题第二天业务导入数据量大一点数据库直接OOM或者保存点超时。参数调优分三个层面操作系统、HANA配置、存储对齐。4.1 大页与NUMA先让操作系统不拖后腿HANA 2.0之后内存管理采用透明大页和内部大页结合的做法操作系统层面不再强制要求手动分配hugepages但有两个参数必须注意透明大页要关闭NUMA平衡要关闭。# 关闭透明大页写入 /etc/default/grub 后重建grub配置 # 将 transparent_hugepagenever 追加到 GRUB_CMDLINE_LINUX grub2-mkconfig -o /boot/grub2/grub.cfg reboot # 确认状态 cat /sys/kernel/mm/transparent_hugepage/enabled # 期望输出: always madvise [never]透明大页对HANA的影响是玄学中翻车率最高的一个。THP开启时内核会把内存页合并成2MB的大页表面上减少TLB miss但对HANA这种随机访问密集的数据库页合并过程会造成延迟毛刺应用到SQL上就是偶尔一次查询慢得离谱。SAP官方SAP Note里明确要求生产环境禁用THP。华为服务器BIOS里如果开了超线程HANA能识别出物理核和逻辑核不需要额外配置但BIOS里的NUMA相关选项建议保持默认不要手动关闭NUMAHANA内部的多实例部署反而需要感知NUMA拓扑来分配内存。4.2 global.ini内存分配与持久化路径的正确写法HANA的核心配置在/hana/shared/HDB/global/hdb/custom/config/global.ini修改时要通过HANA的配置系统写不能直接编辑文件然后指望热生效。# 保存为 /usr/sap/HDB/HDB00/global/hdb/custom/config/global.ini 后重启实例 [database_internal] number_of_trace_files 30 [persistence] basepath_datavolume /hana/data/HDB basepath_logvolume /hana/log/HDB load_unit page savepoint_interval_s 300 [memorymanager] global_allocation_limit 471859200 asynchronous_statistics_update true [system_replication] replication_mode synchronous replication_policy fullsyncglobal_allocation_limit的单位是MB这里以512GB物理内存为例给HANA分配450GB。这个值不是越大越好要留出操作系统和SAP运维工具的内存余量。常见做法是物理内存的88%到92%之间如果本机还要跑B1或Solution Manager比例还要再降。savepoint_interval_s 300表示每5分钟生成一次保存点保存点期间数据卷写入压力比较大如果存储延迟高要相应拉长到600秒但拉长会增加故障恢复时间需要权衡。内存参数调整后用HDBSQL -U SYSTEM SELECT * FROM M_MEMORY_ALLOCATION检查实际分配情况重点看EXCLUDED_MEMORY的大小如果这个值异常大说明内核参数或系统内存本身有问题HANA能用的内存被压制了。这类问题在纸面上看不出来只有落到参数文件才暴露。4.3 multipath与文件系统对齐存储参数的隐藏雷区华为OceanStor全闪阵列通过FC组多路径时Linux自带的multipath工具配置不当会让HANA的数据卷性能缩水一半。最常见的错误是没配置path_grouping_policy导致多条路径被当成独立磁盘处理IO在两个路径间反复切换延迟升高。检查multipath配置时确认/etc/multipath.conf中存在下面这段defaults { path_grouping_policy failover path_selector round-robin 0 failback immediate user_friendly_names yes }这个配置的意义是让同一LUN的路径聚合成一个多路径设备并且故障时自动切换。HANA的持久化对IO路径稳定性要求极高路径抖动一次日志提交就可能超时SAP控制台会直接把这个实例标记为“unhealthy”。每次改完multipath配置要执行systemctl reload multipathd然后multipath -ll查看路径状态Active路径数量必须和实际物理链路数一致。文件系统对齐方面XFS格式化时块大小用4K这能避免HANA的8K或16K IO与文件系统块错位导致读放大。确认命令是xfs_info /hana/data如果输出里显示bsize4096就对了。到这里操作系统、数据库和存储三层的参数基本对齐。这套组合拳打完HANA在华为硬件上才算真正站住了脚。5. 避坑与排查从Studio连不上到系统复制翻车的5条记录这一章是血泪经验集合。以下5个问题我在不同项目里反复见过每一条都按现象、原因、解决的顺序写清楚你可以当成排错手册直接查。5.1 现象安装检查报 kernel.numa_balancing 不通过现象hdblcm跑到前置检查时日志里明确写着kernel.numa_balancing is not disabled安装进程直接终止。原因SLES 15默认把numa_balancing置为1这个参数控制内核是否自动迁移线程到其他NUMA节点。HANA的SAP Note 2205917要求必须关闭因为线程迁移会导致内存访问从本地节点变成远程节点延迟增加好几倍。解决按第3.1节写入/etc/sysctl.d/99-sap-hana.conf并执行sysctl --system。注意某些云环境或虚拟机里宿主机的内核参数不受客户机控制这时候要在启动参数里加numa_balancingdisable然后重启生效。对策不复杂但这个问题在物理机上验证最简单。5.2 现象重启之后HANA起不来日志卷说满就满现象机房意外断电后重启服务器HANA实例起不来检查日志报redo log disk full明明安装时/hana/log分配了空间存储也远没到容量上限。原因HANA的redo log文件按分区预分配每个分区大小由log_partition_size决定默认值是数据卷大小的八分之一。如果日志卷本身分得小或者数据卷增长后日志分区自动变大而日志卷没有同步扩容就会触发这个错误。很多项目安装时日志卷按“能放下文件就行”的思维给20GB等数据卷涨到几百GBreod日志分区需要好几个GB20GB瞬间被占满。解决日志卷至少按数据卷的20%到30%规划512GB数据卷对应日志卷不小于120GB已经翻车的情况下用hdbcons执行mm log resize命令调整日志分区大小然后重启实例。这个问题在规划阶段没有后悔药只能靠早规划、早验证。5.3 现象主库一忙系统复制延迟从秒级跳到分钟级现象HANA系统复制搭好后空闲时备库延迟为0业务高峰一到主库日志堆积备库延迟飙升到好几分钟。检查SAP控制台系统复制状态是ACTIVE但进程SAPHanaSystemReplication一直处于同步等待中。原因这是典型的网络链路问题通常不是带宽不够而是交换机拥塞导致丢包。HANA系统复制采用异步或同步模式持续传日志TCP丢包触发重传后备库的日志应用连续落后更隐蔽的是网络设备的默认Buffer太小瞬时的突发流量在交换机端口直接丢弃。解决把这个流量放到独立VLAN并配置服务质量策略。华为CE系列交换机上做法是给对应端口配置PFC并设置一个单独的队列给它保证这个队列在任何拥塞场景下都不丢包。做完配置后用hdbnsutil -sr_state连续观察几次延迟必须回到秒级以内。这条坑最容易被误判为数据库压力大实际上是网络黑匣子一定要用丢包率数据说话。5.4 现象备份恢复后表能查但应用报数据区错误现象从OceanStor上的备份文件恢复到一台新测试机数据库能启动SELECT也能跑但业务应用跑一段后抛出invalid page之类的错误。原因文件系统损坏或块大小错位。OceanStor上的快照备份传到测试机后测试机文件系统用了ext4而HANA数据文件写在XFS上的时候块边界已经对齐ext4的块映射逻辑无法原样还原部分页被读成了错误数据。恢复流程里只要文件系统类型或块大小和源机不一致就可能出现这种“表能查数据脏”的现象。解决恢复HANA备份的目标机器文件系统类型必须和源机保持一致XFS就XFS块大小也必须一致。建议每次恢复后跑一次HDBSQL -U SYSTEM SELECT COUNT(*) FROM M_DATA_VOLUME_STATISTICS再执行一次全库校验hdbsql -U SYSTEM ALTER SYSTEM RECLAIM DATA VOLUME确认数据卷没有逻辑错误再交给业务方。5.5 现象负载不高但SQL就是慢莫名其妙现象HANA所在服务器CPU利用率只有20%内存充足I/O也没有排队但一个简单的单表查询要跑十几秒而且时间飘忽不定。DBA查了执行计划没有问题数据量也不大。原因这种“玄学”性能问题在华为服务器上多半是CPU频率策略或NUMA平衡在作怪。BIOS默认的电源策略如果是均衡模式CPU降频后HANA的SQL响应时间会明显变差HANA对主频敏感。另一种可能是透明大页没关第4.1节说过THP合并页面的过程会造成随机毛刺。解决BIOS设置为Performance模式关闭C-states深度节能然后确认内核参数里transparent_hugepage状态是never。验证方法很简单同一个SQL连续跑10次取P95时间如果性能抖动超过30%优先检查这两项不要一上来就去调SQL。这几条避坑记录覆盖了安装、存储、网络、恢复和性能基本是目前国产化项目里最常见的重灾区值得直接截屏存档。6. 上线前用HANA自带工具做一次可信的压测参数和架构都到位后最后一步是压测验证。很多人喜欢拿第三方压测工具跑来跑去其实HANA自带工具已经够用关键是方法要对。6.1 用hdbsql跑一个贴近业务的压力脚本首先确认系统表和业务模拟表能不能承受高并发读取。下面这段脚本在HANA SQL控制台里循环读系统表模拟OLTP场景下的高频读操作DO BEGIN DECLARE i INTEGER : 0; DECLARE ts TIMESTAMP; WHILE i 30 DO SELECT COUNT(*) INTO ts FROM SYS.TABLE_STATISTICS; COMMIT; i : i 1; END WHILE; END;看一下整体耗时和单个迭代的响应时间这个值稳定说明HANA基本健康。真实业务压测时把这个脚本里的表换成核心业务表但你还没做数据导入的话可以先跑系统表验证元数据访问路径。COMMIT必须保留否则HANA会把会话保持在一个隐式事务里锁和持久化行为就不是OLTP形态了。6.2 用fio验证日志卷等待时间比看CPU更管用数据库压测跑出来的数字好看不代表存储没问题。我每次都要用fio单独打日志卷看它在高IO压力下的延迟fio --namehana-log-test \ --ioenginelibaio --direct1 \ --rwrandwrite --bs4k --numjobs8 --iodepth32 \ --size2G --runtime60 --time_based \ --filename/hana/log/HDB/fio_testfile重点看lat (usec)的avg和p99。日志卷写延迟p99如果超过500微秒HANA在高峰期提交日志就会吃紧建议把日志卷换成更快的NvMe盘或调整OceanStor的配置。这里的direct1是绕过文件系统缓存直接测块设备这样的数字才反映存储硬实力。这个方案值不值得投入最终就看这些数字能不能稳定。我个人习惯是每次交付都保存一份压测基线之后业务反馈变慢翻出基线一对比是数据库问题还是基础设施退化一目了然。希望帮到你。本文还有配套的精品资源点击获取