隔离网关TOA认证组件异常 是什么意思啊

医院是一个高度依赖信息系统运行的机构，如今从看病挂号到检查拿药，每个环节都是医生、患者与信息系统三者协同完成的。信息化使得医生看病诊断以及对患者信息管理等工作变得更加高效，但是，一旦HIS、PACS等信息系统发生故障，医院的诸多业务也将马上中断，后果不堪设想。

可靠性高于一切的医院信息化系统

相比性能与丰富的功能，可靠性始终是医院信息化系统的首要考量因素，因为一旦服务器宕机，业务中断马上会造成大量病人无法得到及时救治。数据中心的稳定为患者提供持续化的服务，数据中心的高效为医院带来更大的利润空间。可见，可靠性作为基石，高效作为亮点，已经成为医院信息化建设原则。

正是因为医院对业务连续有着近乎苛刻的需求，双活数据中心解决方案得以在医院的应用和普及。从2005年最早的主机双活，到之后的网关双活，再到如今基于阵列的双活方案，医院IT双活解决方案已经发展了十余年。

双活方案在医院

早期的主机双活以及之后的网关双活分别借助主机镜像软件以及虚拟化网关实现，目的都是避免底层存储故障造成的业务中断。但是主机双活需要每台主机上都安装镜像软件，而网关双活则需要增加网关设备，两者运维复杂度和成本都非常高。

当前双活解决方案已经进一步简化，以华为OceanStor Dorado V3为代表的阵列双活方案摆脱了对网关的依赖。对于块业务的医院信息化系统，基于OceanStor Dorado V3的华为HyperMetro 免网关阵列双活方案无疑是双活的最优选择。

OceanStor Dorado V3

高可用与高性能一个都不能少

双活是数据中心级的解决方案，需要存储阵列、主机以及网络的紧密配合。华为 HyperMetro 免网关阵列双活方案，是由两套独立的 OceanStor Dorado V3 存储系统同时提供两个实时一致的数据副本供业务主机读写访问，任意一副本故障，都不影响业务的连续运行。当下可靠性与性能最高的双活整体解决方案是华为KunLun与OceanStor Dorado V3的组合。

KunLun+ OceanStor Dorado V3

打造业界最可靠、最高效的双活解决方案

华为KunLun拥有可以媲美小型机的RAS2.0高可靠架构，并且实现了KunLun的CPU与内存热插拔功能，通过充分的故障预测机制，将可能发生故障的内存组件进行标记，并对故障内存进行在线隔离。随后对内存进行热插拔操作。这项技术使得内存故障引发的计划外宕机时间缩减为0。

对于医院而言，既有数据库为核心的HIS系统，又有存储大量影像资料的PACS系统，这种现状使得统一存储成为必需。另一方面OceanStor Dorado V3全闪存阵列支持SAS和PCIe接口的SSD，通过自研的控制器芯片以及磨损均衡算法，OceanStor Dorado V3的SSD组件级的高可靠以及高性能得以保障。性能方面，OceanStor Dorado V3可以实现400万IOPS的同时保障0.5ms延迟，在性能上具有传统磁盘阵列无法比拟的优势，而可用性更是可以做到6个9，全面保障业务连续。

解决方案层面，华为HyperMetro免网关阵列双活方案提供双重仲裁模式，既支持第三方仲裁和预定优先两种模式，又支持两种模式间自动转换。第三方仲裁可以采用物理或者虚拟服务器的方式实现，且生产中心与仲裁服务器只需要 IP 网络可达即可，相比传统的FC方案成本更低。

此外，即便第三方仲裁发生故障，华为 HyperMetro 免网关双活方案可自动进入预定优先模式，较传统双活方案的仲裁机制更完善，业务连续性更高。双活架构不仅可以提高系统可靠性，保障业务连续，同时也可以实现业务就近访问，以求缩短I/O路径，降低数据传输量系统延迟。

某三甲医院双活方案实践

上图是某三甲医院的一个典型的双活系统架构，针对传统小型机搭配磁盘阵列的性能不足以及存在单点风险，华为为其构建了基于OceanStor Dorado V3全闪存阵列的HyperMetro双活解决方案。HIS等关键业务系统统一部署于全闪存阵列上，消除存储系统性能瓶颈，同时借助HyperMetro技术将两台OceanStor Dorado V3阵列组合成为相互冗余的集群，消除单点故障。上层则部署全网x86服务器，采用高性能机架服务器构成双机系统承载数据库等关键业务。

OceanStor Dorado V3从SSD等组件到阵列拥有一系列的软硬件核心技术，保障其高可靠性以及高性能，同时借助HyperMetro技术可以为医院高效地构建双活系统。免网关、统一存储以及全面的自动化设计使得系统运维复杂度将至最低。对于医院一类需求众多并且要求十分严苛的客户，OceanStor Dorado V3与华为KunLun等服务器搭配的双活系统无疑是当下业界最佳方案。

智汇华云 | 负载均衡源地址可见技术

2022-12-13 14:13之家网站 (-)

摘要

在非网关型负载均衡器中，通常使用 FullNat 模式。在这种模式下，客户端访问后端服务器的源 IP 在负载均衡器上会被改变，导致在后端服务器上服务不能正确确定客户端的真实 IP 地址。在一些应用场景下，为了实现安全或者大数据分析等应用，需要感知客户端的真实 IP。本文介绍了一种 FullNat 模式下负载均衡的源地址可见方法。

概述

负载均衡有三种模式：DR，NAT，Tunnel。FullNat 模式在 NAT 模式下增加了源 IP NAT。FullNat 模式的优点：解决了 NAT 对 Director 和 RS 要求在同一个 vlan 的问题，适用更复杂的部署形式不要求配置 Director 作为网关，Director 与 RS 可以通过三层通讯。缺点：RS 看不到客户端真实 IP。

为了解决后端服务器感知客户端真实 IP，本文介绍了如下的方法。

四层源地址可见

四层流量通常是 TCP 和 UDP 协议报文。源地址可见的通常方法是在报文中某些字段携带客户端的真实 IP。在后端通过内核模块来获取客户端 IP。

TCP 源地址可见

TCP 流量是 TOA 来实现源地址可见。TOA 名字全称是 tcp option address，是 FullNat 模式下能够让后端服务器获取客户端 IP 的一种实现方式，它的基本原理比较简单。

客户端用户请求数据包到达负载均衡器时，负载均衡器在数据包的 tcp option 中插入源 IP 信息。

数据包到达后端服务器（装有 toa 内核模块）后，应用程序正常调用 getpeername 系统函数来获取连接的源端 IP 地址。

由于在 toa 代码中 hook（修改）了 inet_getname 函数（getpeername 系统调用对应的内核处理函数），该函数会从 tcp option 中获取负载均衡器填充的源 IP 信息。

这样后端服务器应用程序就获取到了真实客户端 IP，而且对应用程序来说是透明的。

TCP 头部格式如下：

在 option 选项部分携带客户端的 IP 地址。

IPv4 TOA 格式

opcode: opcode = 254

opsize: toa 大小 8 字节

port: 客户端端口

clientIP: 客户端 IP（4 字节）

注：opsize 大小包含了自身 opsize (2B) + port (2B) + ip (4B)

修改 option 的时机

负载均衡器需要对每个 tcp 数据包都要插入 toa 信息么？如果这样会影响到负载均衡器整体性能的，而且后端服务器也没必要对每个 tcp 数据包进行解析，当然也很影响服务器性能。其实只需要在第 3 次握手 ack 数据包中插入 toa 选项即可，后端服务器从 ack 数据包中解析并获取即可。

后端服务器上获取客户端 IP 获取。

TCP 协议栈中处理三次握手的 ack 数据包的函数是 tcp_v4_syn_recv_sock，完成连接的建立，并创建 newsock。在 TOA 内核模块中修改

1.hook tcp_v4_syn_recv_sock_toa 函数，从 TCP 的 skb 中获取 tcp option 的携带的 IP 信息，保存到 socket 中

2. Hook inet_getname，应用程序在调用 getpeername 时，会使用 inet_getname_toa 函数处理，从 socket 中将保存的 ip 信息返回

---