设想:
客户最近将群集 HANA DB 服务器迁移到 Azure 云平台,但这些是 Azure 上的物理服务器(产品:Azure HLI)。通常,无法直接访问 Azure 中的这些 HLI(HANA DB 服务器),甚至无法从 Azure VNET 访问。换句话说,HLI 无法访问托管在其他 VNET 或客户本地数据中心上的服务器,反之亦然。因此,客户已在 HLI 和其中一个生产 VNET 之间配置了快速路由。因此,任何服务器或 VM 都可以访问这些 HLI。但其他 VNET(如 DEV、TEST)或从客户位置,这些 HLI 是无法访问的。因此,为了解决上述问题,我们在生产 VNET 上配置了 SLES 12 VM,并将其作为 NAT 转换的 IPTABLE 服务器,以解决两类问题 a) 当 HLI 服务器需要访问 APP/DB(此处为 Hadoop 服务器)时。
b) 当本地数据中心服务器需要访问 HLI 时。因此,在这种情况下,我们为本地服务器和 HLI 分配了 Natted IP,如下所示。请参阅附图
原始子网 – 10.10.xx
HADNA001-192.168.1.2
HADNA002-192.168.1.3
HADNA003-192.168.1.4
原始子网 – 172.168.xx
HANANA001 – 192.168.1.5
HANANA002 – 192.168.1.6
HANANA003 – 192.168.1.7
问题:
情况1:当客户的 SAP 支持团队开始从 Hadoop spark 控制器提取数据时,他们会看到超时请求。据他们说,只有在高负载的情况下才会看到这种情况。对于正常负载,这种情况不会发生。提取数据的阶段:
1)使用安装在用户笔记本电脑上的 HANA Studio。
2) 连接到任意一个 HLI 服务器(本例中为 HANANA001)
3)通过 HLI(HANANA001)从 Hadoop 控制器(HADNA001)配置负载并触发负载
并且请求超时是动态的,在4小时的负载中可能发生1到10次。
案例 2:我们观察到,当我们尝试使用具有多个并行会话的 rsync 通过 iptable 将数据从本地服务器复制到 HLI 时,一段时间后会话会停滞。如果 rsync 具有 5 个会话,则不会发生这种情况。如果会话超过 5 个,会话就会停滞。我们尝试复制的数据为 2 TB,每个文件有 5 GB。这就是我们尝试使用多个并行会话的原因,假设一次将复制更多 5 GB 文件。
我们尝试捕获 tcpdump 并分析日志,我们只看到 [F] 和 [R] 标志,这并没有提供太多信息。此外,本地和 HLI 之间还有其他网络设备,这些设备未显示在附图中,我们也不知道这些设备是什么。
不同环境或 VNET 上的其他 iptable 服务器不存在此问题。到目前为止,客户向我们报告了他们在 HANA Studio 中看到的一些错误
1)SQL错误,403请求超时
2)无法创建虚拟表,请求超时。