部署时钟服务器
在分布式集群中，时钟同步是至关重要的，由于分布式的各个组件通常运行在不同的节点上，为了实现组件之间的同步，组件之间必须借助时间来确保不会混乱。
在生产环境中，我们通常建议在集群内部安装多个时钟服务器，确保所有节点都能得到低延迟的一致的时钟，之所以要安装多个，是因为时钟服务器太过于重要，以至于如果只有单个时钟服务器，一旦其不可用，将会导致各个节点的时钟紊乱，进一步导致集群不可用，业务中断。
目前在linux平台有多种时钟系统，我们推荐使用chrony时钟服务来给集群的各个节点做时钟的同步。
开始前，我们确保节点的时区和时钟格式符合使用，所有节点保持一致，避免不必要的问题
ansible all -i nodes -m shell -a '/usr/bin/timedatectl'
timedatectl set-timezone Asia/Shanghai
echo "LC_TIME=en_DK.UTF-8" >> /etc/default/locale
在我们的环境中，我们选取deployhost节点作为我们集群的时钟服务器，首先安装软件包chrony
sudo apt install chrony
ansible all -i nodes -m shell -a 'apt install chrony -y'
完成后，对chrony server进行配置，这个chrony服务，除了给集群节点同步时钟外，还要到互联网的公共时钟服务器同步自己的时钟，以确保自身的时钟也是正确的，注意，在使用ntp源之前，最好先ping一下延迟情况，选取延迟最低的ntp源，推荐使用腾讯云的时钟服务器来做我们的chrony的上级时钟服务器，当然如果同学们所在的环境，离阿里云的时钟服务器更近的话也可以使用阿里云的时钟服务器作为上级服务器：
ping ntp1.tencent.com
ping ntp2.aliyun.com
chrony作为服务器时配置文件为
nano /etc/chrony/chrony.conf
这个字段就是指定上级时钟服务器，默认它是使用Pool的方式，我们不用Pool方式而是指定server
一般来说我们可以配置多个server,这里我们就配置两个
server ntp1.tencent.com iburst
server ntp2.tencent.com iburst
下面这些字段默认即可
keyfile /etc/chrony/chrony.keys
driftfile /var/lib/chrony/chrony.drift
logdir /var/log/chrony
maxupdateskew 100.0
rtcsync
makestep 1 3
我们还规定了只有来自192.168.183网段的主机才能够进行时钟同步服务
同学们根据自己实际的网络环境来进行添加
allow 192.168.183.0/24
这里local这一个字段表示，当chrony服务器无法连接到上级服务器的时候，它自己就成为一个时钟服务器
local stratum 10
保存修改后，我们重启时钟服务，然后进行验证systemctl restart chrony.service
chrony进程起来后，我们查看一下chrony服务是否正常运行，主要是看chrony是否能正常与上级时钟服务器对时
root@debian:~# chronyc tracking
Reference ID : 6A37B8C7 (106.55.184.199) --> 表示当前我们的时钟服务器所对应的上级时钟服务器
Stratum : 3 --> 服务器距离源时间有多远，这里本服务器为第3层
Ref time (UTC) : Tue Feb 27 06:38:07 2024 --> chrony同步的最后一次UTC时间
System time : 0.000192805 seconds fast of NTP time --> 系统时间比NTP服务器时间快或慢多少
Last offset : +0.000419843 seconds
RMS offset : 0.000562249 seconds
Frequency : 3.282 ppm fast
Residual freq : +0.203 ppm
Skew : 7.279 ppm
Root delay : 0.009290155 seconds
Root dispersion : 0.018624386 seconds
Update interval : 64.8 seconds
Leap status : Normal
root@debian:~# chronyc sources
210 Number of sources = 1
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* 106.55.184.199 2 7 377 14 -1818us[-1981us] +/- 22ms
如上述所示，chrony服务器端就正常运行了，客户端的配置则更为简单，只需要将配置文件的server指向我们自建的chrony服务即可
nano /etc/chrony/chrony.conf
server 192.168.183.100 iburst
修改完成后重启本地的chrony服务
root@debian:~# systemctl restart chrony.service
修改完一台节点的配置后，我们可以使用ansible工具，将配置文件分发到所有的节点上，并批量重启这些节点的chrony服务，确保所有节点的配置是一致且正确的。
服务端的chrony可以检查一下客户端的同步情况
root@debian:~# chronyc clients
Hostname NTP Drop Int IntL Last Cmd Drop Int Last
===============================================================================
192.168.183.100 1 0 - - 40 0 0 - -
192.168.183.101 1 0 - - 31 0 0 - -
192.168.183.102 1 0 - - 16 0 0 - -
由输出可知，客户端的同步请求正常完成同步，到此，所有节点就实现了低延迟的时钟同步，由于内网的网络延迟极低，这种时钟同步保证了集群的时钟一致性，有效地规避了时钟带来的问题。
集群节点的其他配置
防火墙与selinux
ufw status
ufw disable
sed -i 's/enforcing/disabled/g' /etc/selinux/config
Debian Buster系统最小化安装，其默认不安装ufw和selinux，所以无需单独关闭，如果有安装，则需要检查是否关闭
关于关闭防火墙和selinux可能带来安全风险的问题，实际上我们可以这么考虑：
集群主机通常处于内部网络，一般情况下所有集群节点都是不允许访问外部网络的，只有像rgw、块网关这类服务节点才允许配置外部ip，因此在拓扑上就实现了一定程度的隔离，主要的安全加固也应该放在网关节点上
当然，如果不希望关闭防火墙和selinux，也可以为其添加iptables规则，放行关于ceph组件的相关端口和ip段，这样做安全性会更好，只是步骤较多较为繁琐。
ssh安全配置
我们对sshd进行一定的设定，修改/etc/ssh/sshd_config文件：
Protocol 2 -> 取消注释，强制仅接受更安全的sshv2
GSSAPIAuthentication no -> 禁止使用其他方法认证
PasswordAuthentication no ->禁止密码认证
PubkeyAuthentication yes -> 允许用key认证
UseDNS no -> 取消注释，不解析用户dns，加快ssh的连接接速度
PermitEmptyPasswords no -> 禁止空密码登录
PermitRootLogin no -> 禁止root用户登录
前面有提到，目前集群属于创建阶段，使用root用户来去创建集群可以避免很多不必要的麻烦，尤其是权限问题，所以关于安全配置这一块，我们将在后续集群部署好之后，来禁止密码登录和禁止使用root的登录，只允许使用key登录的方式，生产部署中我们也应该遵循这样一个好的安全习惯。
命令行历史记录
在实际运维过程中，我们会执行各种命令，为shell历史操作记录增加时间戳是个很好的习惯，尽管平时我们Linux的命令行历史记录通常是不受关注的，但是在需要定位相关问题故障的时候，这个历史记录的时间戳就非常的有用，从生产实践来看，很多问题可能是因为管理人员命令使用的不规范或者是误操作而引发的，因此根据时间戳来确定哪一些命令是导致问题的根源，有时候是非常有用的，给shell命令行执行的历史记录，添加时间戳的方法比较简单，只需要在/etc/profile下面增加这么一行即可：
echo 'HISTTIMEFORMAT="%F %T "'>>/etc/profile
source /etc/profile
在完成profile的配置并确认无误后，我们仍然建议使用ansible的copy模块将配置同步到所有节点，这样所有节点的配置也就一致且正确了。
创建运维专用账户及sudo权限
在集群搭建好之后，为了更方便使用ansible工具对集群节点进行管理，所有节点都应该配置一个专用的非root用户，并且配置当前节点到集群其他节点的ssh免密登录，这是因为，线上环境的运维管理，如果默认使用root，可能会有一些风险，所以建议单独创建管理用户并且授予免密的sudo权限，虽然免密的sudo权限也很大，但是毕竟跟root相比，它其实还是有一点差别的，习惯使用sudo，而不是直接使用root的用户来进行集群的管理操作，也是我们线上运维人员的重要的，好的习惯。
在我们的环境中，我们安装debian系统的时候，默认要求创建一个用户，我们就创建了一个名为cluster的用户，所以我们这里就不重新创建了，继续下面的操作：
首先安装sudo模块
apt install -y sudo
然后，如果没有创建用户的话，先创建用户，如果已经有用户了，直接设置免密的sudo权限
useradd -m cluster -s /bin/bash
echo "cluster ALL = (root,ceph) NOPASSWD:ALL" | tee /etc/sudoers.d/cluster
chmod 0440 /etc/sudoers.d/cluster
最后设置一下cluster用户的密码，即便不需要密码做sudo，出于安全考虑，也应该为用户设置密码
passwd cluster
上述操作可以编写为shell脚本，使用ansible的copy模块进行分发，并使用shell模块进行执行，使得所有节点的配置一致且正确。
运维账户的免密key登录
在集群搭建好之后，为了更方便使用ansible工具对集群节点进行管理，所有节点都应该配置一个专用的非root用户，并且配置当前节点到集群其他节点的ssh免密登录，这是因为，线上环境的运维管理，如果默认使用root，可能会有一些风险，所以建议单独创建管理用户并且授予免密的sudo权限，虽然免密的sudo权限也很大，但是毕竟跟root相比，它其实还是有一点差别的，习惯使用sudo，而不是直接使用root的用户来进行集群的管理操作，也是我们线上运维人员的重要的，好的习惯。
首先生成本地的ssh key
ssh-keygen -t rsa -b 4096 -C "deployhost"
方便起见，我们使用脚本在集群节点上创建用户并导入deployhost的公钥，使得deployhost节点可以免密登录到其他所有集群节点
#!/bin/bash
useradd -m clusteruser -s /bin/bash
mkdir /home/clusteruser/.ssh
chmod 700 /home/clusteruser/.ssh
ansible all -i nodes -m copy -a 'src=add_user.sh dest=/tmp/'
ansible all -i nodes -m shell -a '/bin/bash /tmp/add_user.sh'
将公钥分发到其他节点上，最后修改权限
ansible all -i nodes -m copy -a 'src=/home/clusteruser/.ssh/id_rsa.pub dest=/home/clusteruser/.ssh/authorized_keys'
ansible all -i nodes -m shell -a 'chown clusteruser.clusteruser -R /home/clusteruser/.ssh'
ansible all -i nodes -m shell -a 'chmod 600 /home/clusteruser/.ssh/authorized_keys'
我们将使用cluster这个用户来进行集群的运维管理，在集群搭建方面，我们仍然可以使用root的用户来进行集群的搭建，因为这样可以省去很多的麻烦。
关于ceph集群在搭建之前，硬件和软件方面的准备，我们到现在为止就已经准备完成了，后面我们将正式开始ceph集群的搭建。
扫一扫
1392
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
