2.9. Red Hat Ceph Storage RBD 集成故障排除
Compute (nova)、块存储(cinder)和镜像(glance)服务可以与红帽 Ceph Storage RBD 集成,以将其用作存储后端。如果此集成无法按预期工作,您可以执行增量故障排除过程来逐渐消除可能的原因。
以下示例演示了如何对镜像服务集成进行故障排除。您可以调整相同的步骤来对 Compute 和块存储服务集成进行故障排除。
如果您在完成此步骤前发现问题的原因,则不需要执行任何后续步骤。您可以退出这个过程并解决问题。
流程
通过评估
Ready
条件是否为True
来确定 control plane 中的任何部分没有正确部署:$ oc get -n openstack OpenStackControlPlane \ -o jsonpath="{range .items[0].status.conditions[?(@.status!='True')]}{.type} is {.status} due to {.message}{'\n'}{end}"
如果您识别未正确部署的服务,请检查该服务的状态。
以下示例检查 Compute 服务的状态:
$ oc get -n openstack Nova/nova \ -o jsonpath="{range .status.conditions[?(@.status!='True')]}{.type} is {.status} due to {.message}{'\n'}{end}"
注意您可以使用
oc get pods -n openstack
命令以及特定服务的日志(oc logs -n openstack <service_pod_name>
; 命令检查所有部署的服务的状态。将<service_pod_name
> 替换为您要检查的服务 pod 的名称。如果您识别没有正确部署的 Operator,请检查 Operator 的状态:
$ oc get pods -n openstack-operators -lopenstack.org/operator-name
注意使用
oc logs -n openstack-operators -lopenstack.org/operator-name=<operator_name> 命令来检查
Operator 日志。
检查 data plane 部署的
Status
:$ oc get -n openstack OpenStackDataPlaneDeployment
如果 data plane 部署的
Status
是False
,请检查关联的 Ansible 作业的日志:$ oc logs -n openstack job/<ansible_job_name>
将
<ansible_job_name
> 替换为关联的作业的名称。作业名称列在oc get -n openstack OpenStackDataPlaneDeployment
命令的Message
字段中。
检查 data plane 节点设置部署的
Status
:$ oc get -n openstack OpenStackDataPlaneNodeSet
如果 data plane 节点设置部署的
Status
为False
,请检查关联的 Ansible 作业的日志:$ oc logs -n openstack job/<ansible_job_name>
-
将
<ansible_job_name
> 替换为关联的作业的名称。它列在oc get -n openstack OpenStackDataPlaneNodeSet
命令的Message
字段中。
-
将
如果任何 pod 处于
CrashLookBackOff
状态,您可以使用oc debug
命令重复它们以排查目的:oc debug <pod_name>
将
<pod_name
> 替换为要重复的 pod 的名称。提示您还可以在以下对象调试活动中使用
oc debug
命令:-
要在第一个容器以外的容器中运行
/bin/sh
,命令默认行为,使用oc debug -container <pod_name> <container_name>
。这对 pod 很有用,如第一个容器跟踪文件的 API,第二个容器是您要调试的容器。如果使用这个命令表单,您必须首先使用oc get pods | grep <search_string&
gt; 命令来查找容器名称。 -
要在调试过程中将流量路由到 pod,请使用命令表单
oc debug <pod_name> --keep-labels=true
。 -
要创建任何创建 pod 的资源,如
Deployments
、StatefulSets
和Nodes
,请使用命令形式 oc debug <resource_type>/<resource_name>
。创建StatefulSet
示例为oc debug StatefulSet/cinder-scheduler
。
-
要在第一个容器以外的容器中运行
连接到 pod,并确认
/etc/ceph
目录中存在ceph.client.openstack.keyring
和ceph.conf
文件。注意如果 pod 处于
CrashLookBackOff
状态,请使用oc debug
命令,如上一步中所述,复制 pod 并将流量路由到它。$ oc rsh <pod_name>
将
<pod_name
> 替换为适用的 pod 的名称。提示如果缺少 Ceph 配置文件,请检查
OpenStackControlPlane
CR 中的extraMounts
参数。
通过从 pod 连接 Ceph Monitor 的 IP 和端口,确认 pod 具有与 Red Hat Ceph Storage 集群的网络连接。IP 和端口信息位于
/etc/ceph.conf
中。以下是此过程的示例:
$ oc get pods | grep glance | grep external-api-0 glance-06f7a-default-external-api-0 3/3 Running 0 2d3h $ oc debug --container glance-api glance-06f7a-default-external-api-0 Starting pod/glance-06f7a-default-external-api-0-debug-p24v9, command was: /usr/bin/dumb-init --single-child -- /bin/bash -c /usr/local/bin/kolla_set_configs && /usr/local/bin/kolla_start Pod IP: 192.168.25.50 If you don't see a command prompt, try pressing enter. sh-5.1# cat /etc/ceph/ceph.conf # Ansible managed [global] fsid = 63bdd226-fbe6-5f31-956e-7028e99f1ee1 mon host = [v2:192.168.122.100:3300/0,v1:192.168.122.100:6789/0],[v2:192.168.122.102:3300/0,v1:192.168.122.102:6789/0],[v2:192.168.122.101:3300/0,v1:192.168.122.101:6789/0] [client.libvirt] admin socket = /var/run/ceph/$cluster-$type.$id.$pid.$cctid.asok log file = /var/log/ceph/qemu-guest-$pid.log sh-5.1# python3 Python 3.9.19 (main, Jul 18 2024, 00:00:00) [GCC 11.4.1 20231218 (Red Hat 11.4.1-3)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import socket >>> s = socket.socket() >>> ip="192.168.122.100" >>> port=3300 >>> s.connect((ip,port)) >>>
提示如果无法连接到 Ceph 监控器,请对集群和 pod 之间的网络连接进行故障排除。上例使用 Python 套接字从
ceph.conf
文件连接到 Red Hat Ceph Storage 集群的 IP 和端口。执行
s.connect ((ip,port)
函数时有两个潜在的结果:- 如果命令成功执行,且没有类似以下示例的错误,pod 和集群间的网络连接可以正常工作。如果连接正常工作,则命令执行将根本不提供返回值。
- 如果命令需要很长时间才能执行并返回类似以下示例的错误,则 pod 和集群间的网络连接无法正常工作。应进一步调查该连接以对连接进行故障排除。
Traceback (most recent call last): File "<stdin>", line 1, in <module> TimeoutError: [Errno 110] Connection timed out
如以下示例所示,检查
cephx
密钥:bash-5.1$ cat /etc/ceph/ceph.client.openstack.keyring [client.openstack] key = "<redacted>"c caps mgr = allow * caps mon = profile rbd caps osd = profile rbd pool=vms, profile rbd pool=volumes, profile rbd pool=backups, profile rbd pool=images bash-5.1$
从
caps osd
参数列出池的上下文,如下例所示:$ /usr/bin/rbd --conf /etc/ceph/ceph.conf \ --keyring /etc/ceph/ceph.client.openstack.keyring \ --cluster ceph --id openstack | wc -l
提示如果这个命令返回数字 0 或更高版本,cephx 密钥提供足够的权限来连接,并从中读取信息,即 Red Hat Ceph Storage 集群。
如果此命令未完成,但已确认至集群的网络连接,请与 Ceph 管理员合作来获取正确的
cephx
密钥环。另外,存储网络上可能存在 MTU 不匹配。如果网络使用巨型帧( MTU 值为 9000),则必须使用接口的服务器之间的所有交换机端口都必须更新,以支持巨型帧。如果交换机没有进行此更改,则在 Ceph 应用层可能会出现问题。使用网络验证所有主机都可以通过所需的 MTU 进行通信,例如
ping -M do -s 8972 <ip_address>
。将测试数据发送到 Ceph 集群上的
images
池。以下是执行此任务的示例:
# DATA=$(date | md5sum | cut -c-12) # POOL=images # RBD="/usr/bin/rbd --conf /etc/ceph/ceph.conf --keyring /etc/ceph/ceph.client.openstack.keyring --cluster ceph --id openstack" # $RBD create --size 1024 $POOL/$DATA
提示可以从集群中读取数据,但没有权限向它写入数据,即使
cephx
密钥环中授予了写入权限。如果已授予写入权限,但您无法向集群写入数据,这可能表示集群过载且无法写入新数据。在示例中,
rbd
命令没有成功完成,并已取消。因此,它会确认集群本身没有用于写入新数据的资源。这个问题已在集群本身中解决。客户端配置没有不正确的。