Azure 上基于SUSE Linux部署高可用NFS服务器采坑汇总


本文重点分析在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

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

×用微信扫描并分享
本文链接: https://www.pstips.net/suse-linux-setup-nfs-on-azure.html
请尊重原作者和编辑的辛勤劳动,欢迎转载,并注明出处!

关于 Mooser Lee

我是一个Powershell的爱好者,创建了PowerShell中文博客,热衷于Powershell技术的搜集和分享。本站部分内容来源于互联网,不足之处敬请谅解,并欢迎您批评指正。

发表评论

电子邮件地址不会被公开。 必填项已用*标注