本文重点分析在Azure中国上按照Azure官网文档《SUSE Linux Enterprise Server for SAP applications 上的 Azure VM 上 SAP NetWeaver 的高可用性》部署高可用NFS服务器遇到的问题

SAP 文件服务器模板的问题

模板URL 指向

官网上的URL指向为国际版：SAP 文件服务器模板 国际版，我们要把它更新为中国版【SAP 文件服务器模板 中国版】才能正确跳转。

虚拟机大小问题

nfsserversize 官网给出的是：Standard_DS2_V2，我的订阅里面没有，我就改成了低配版的值Standard_DS2。

可用性集的容错域值

platformFaultDomainCount，官网给出的是3，我的订阅中不支持，于是改成2。

镜像问题

这是最难的一个问题，官网要求是sku=12-SP1,offer=SLES-SAP, 但是截至本文发稿，微软中国的镜像市场暂不支持该镜像：

所以为了能让这个模板先部署成功，我们得选择SLES 12 BYOS，而不是SLES 12。

资源前缀名长度

参数中的资源名称前缀最小长度parameters.resourcePrefix.minLength 的值默认为3，我们要改成2，并且在部署时，RESOURCEPREFIX (string)的值长度也要填写为2个，不要超过2个，否则安装完集群后hawk.service启动失败。

为什么资源前缀长度会影响hawk.service？

hawk.service会在机器的7630端口运行HA Web Konsole，协议为HTTPS，形如：https://10.0.0.5:7630/。第一次启动时，hawk.service尝试通过openssl工具创建一个ssl证书，用于配置https。

证书对应的CN名称为机器的FQDN名称，比如你填写的资源前缀名为：sh，那么第一台机器的名称则为：sh-nfs-0，整个机器的FQDN名称就变成了sh-nfs-0.lrtirht2q20ujfebsio3jpdwzf.ax.internal.chinacloudapp.cn，长度已经为64了，这已经是生成证书时中的CN参数的极限了，超过则会报错：

139652243846800:error:0D07A097:asn1 encoding routines:ASN1_mbstring_ncopy:string too long:a_mbstr.c:154:maxsize=64

那老外为什么没有遇到这个问题呢？因为Azure中国的虚拟机的FQDN名称本身就比人家多了一个china了。

2018-2-1日更新：

12-SP2以后的版本中，该问题已经得到修复，大概逻辑是如果(hostname -f)超过48，则取值(hostname -f)，否则取值（hostname ）

资源名长度超过2个如何补救？

假如你之前不小心，资源前缀名填写已经超过了2，如何补救？在机器创建完成后，先不要急着安装集群，登陆每台机器，手动编辑/srv/www/hawk/bin/generate-ssl-cert，强制硬编码CN变量值如下图，比如改成msnode-nfs0.chinacloudapp.cn，但是记得要在hosts文件中把它指向127.0.0.1：

SLES 12 BYOS 没有软件仓库的问题

在尝试安装HA扩展时，报错软件源仓库没有定义，形如：

$:~> sudo zypper install sle-ha-release fence-agents
Warning: No repositories defined. Operating only with the installed resolvables. Nothing can be installed.

你可以添加自己的库，我使用的是：

sudo zypper ar -fc https://mirrors.ustc.edu.cn/opensuse/distribution/leap/42.2/repo/oss USTC:42.2:OSS
sudo zypper ar -fc https://mirrors.ustc.edu.cn/opensuse/distribution/leap/42.2/repo/non-oss USTC:42.2:NON-OSS
sudo zypper ar -fc https://mirrors.ustc.edu.cn/opensuse/update/leap/42.2/oss USTC:42.2:UPDATE-OSS
sudo zypper ar -fc https://mirrors.ustc.edu.cn/opensuse/update/leap/42.2/non-oss USTC:42.2:UPDATE-NON-OSS

检测不到fence_azure_arm设备

对于SLES 12 BYOS镜像，所有的步骤都走通了，但是在最后一步尝试创建 STONITH 设备时报错：ERROR: stonith:fence_azure_arm:

$:~> sudo crm configure
sapuser's password:
crm(live)configure# primitive rsc_st_azure_1 stonith:fence_azure_arm \
 > params subscriptionId="" resourceGroup="" tenantId="" login="" passwd=""
crm(live)configure# primitive rsc_st_azure_2 stonith:fence_azure_arm \
 > params subscriptionId="" resourceGroup="" tenantId="" login="" passwd=""
crm(live)configure# colocation col_st_azure -2000: rsc_st_azure_1:Started rsc_st_azure_2:Started
crm(live)configure# commit
ERROR: stonith:fence_azure_arm: got no meta-data, does this RA exist?
ERROR: stonith:fence_azure_arm: no such resource agent
Do you still want to commit (y/n)?

估计是fence agent 和该镜像的兼容性问题，尚未解决，留待后来者继续努力:(，如果有方案，恳请告知。

正因为这样，我还是采用了官网上推荐的镜像sku=12-SP1,offer=SLES-SAP，从国际版上安装了一台suse的干净镜像，导出并复制到Azure中国，替换了部署模板生成的两台虚拟机。

NFS客户端挂载问题

nfs3 Connection timed out

虽然官网中没有该步骤，但是我还是想看下NFS能否正常挂载，我创建了一台linux客户端10.0.0.8，尝试通过内网负载均衡10.0.0.4来挂载NFS，结果报超时错误

$> sudo mount -t nfs 10.0.0.4:/srv/nfs/NWS /home/work3
mount.nfs: Connection timed out

但是通过物理IP 10.0.0.5 直连挂载却可以：

$> sudo mount -t nfs 10.0.0.5:/srv/nfs/NWS /home/work3

其原因是nfs v3 默认不支持集群访问，所以我们在挂载时应当指定版本号nfs4

nfs4 找不到文件资源和目录

刚开始直接把mount命令的nfs改为nfs4，提示：找不到资源或者目录

$>  sudo mount -t nfs4 10.0.0.4:/srv/nfs/NWS /home/work
mount.nfs4: mounting 10.0.0.4:/srv/nfs/NWS failed, reason given by server: No such file or directory

起初以为NFS没配好，其实，是mount命令的语法问题，如果是nfs4 ，远程机器路径只能写到根目录 10.0.0.4:/，不能写具体的子目录10.0.0.4:/srv/nfs/NWS，正确的写法如下：

$> sudo mount -t nfs4 10.0.0.4:/ /home/workv4

验证NFS的故障转移

默认按照官网步骤，nfs服务器运行在第一台机器上，我们本地创建一个10G的临时文件：

$> sudo fallocate -l 10G test.img

把文件复制到NFS服务器上，为了复制时显示进度我们使用rsync命令，大概需要4-5分钟的样子：

$> sudo rsync -a --progress test.img ./workv4/
sending incremental file list
test.img
 10,737,418,240 100% 38.52MB/s 0:04:25 (xfr#1, to-chk=0/1)

在复制的过程中，我们把第一台机器关机，你会发现关机的瞬间，拷贝进度会临时暂停，但是不会中断，因为有rsync超时尝试机制；此时NFS故障转移会发生，自动切换到第二台机器上，仍然会继续传送完成。等整个文件传送结束后，我们登陆到第一台机器上，最期望看到的一幕就会映入眼帘，机器1正在从从机器2上同步文件数据：

$> sudo drbd-overview
sapuser's password:
 0:NWS_nfs/0  SyncTarget Secondary/Primary Inconsistent/UpToDate 
	[===>................] sync'ed: 21.0% (7848/9924)M
$> sudo drbd-overview
 0:NWS_nfs/0  SyncTarget Secondary/Primary Inconsistent/UpToDate 
	[==========>.........] sync'ed: 55.4% (4436/9924)M
$> sudo drbd-overview
 0:NWS_nfs/0  SyncTarget Secondary/Primary Inconsistent/UpToDate 
	[==================>.] sync'ed: 96.0% (404/9924)M
$>  sudo drbd-overview
 0:NWS_nfs/0  SyncTarget Secondary/Primary Inconsistent/UpToDate

至此，踩完所有的坑，才算看到胜利的果实。