企业官网建设流程全解析

1. 存储节点扩容前的整体思路与方案选型

OpenStack增加存储节点这件事，说白了就是给云平台“加硬盘”。很多刚接触OpenStack的运维兄弟一上来就急着装包、改配置，结果部署完了发现卷创建失败、调度不上去，最后才回头研究架构，白白浪费半天时间。作为跑过生产环境的过来人，我建议动手之前先把扩容的整体思路捋清楚，知道自己加的是什么角色、加完有什么效果、会牵动哪些服务。

1.1 搞清楚你要加的是哪类存储节点

OpenStack里的存储角色其实分两种路线。一种是走Cinder块存储路线，提供的是云硬盘（类似云主机的系统盘和数据盘），底层一般用LVM、Ceph这类方案，通过iSCSI或RBD协议把存储资源暴露给计算节点。另一种是Swift对象存储路线，提供的是桶和对象（类似网盘接口），底层是普通硬盘加Swift服务。

绝大多数场景下，我们说“增加一个存储节点”默认指的是Cinder的存储后端节点。因为Swift扩容更像“加服务器跑Swift服务”，而Cinder扩容则是把一台物理机作为独立的Block Storage节点，通过cinder-volume服务对外提供块存储能力。

我这次要拆解的就是Cinder存储节点的扩容流程。你的架构里如果已经有一台控制节点、一台或几台计算节点，现在需要把业务数据容量扩上去，那新增的这台机器就是专门的存储节点。它不跑nova-compute，不跑neutron-agent，只负责承载cinder-volume，以及底层的LVM卷组和iSCSI Target。

1.2 为什么单独加存储节点而不是堆计算节点本地盘

有一个常见误区：既然计算节点的本地盘也能通过LVM配置成Cinder后端，为什么不直接在每个计算节点上把本地剩余空间加入存储池？理论上确实可以，很多小型测试环境也就是这么干的。但在生产环境里，我强烈不建议这么玩。

原因有三个。第一，计算节点本地盘扩容会导致存储资源分散，你没法统一规划卷组容量，而且某台计算节点宕机时，它本地承载的Cinder卷可能无法被其他计算节点正常访问，除非底层有分布式复制机制。第二，计算节点本身的CPU、内存、网络要承担虚拟机业务，再叠加cinder-volume的LVM快照、iSCSI export操作，容易出现IO争抢。第三，独立存储节点故障域更清晰。存储节点挂了只影响卷IO，不影响计算节点上的虚拟机生命周期管理，而计算节点挂了还得考虑HA迁移。

所以在生产架构里，存储节点独立化是标准做法。新增的这台存储节点，本质上是把“容量”和“计算”解耦，容量不够就横向加存储节点，计算不够就纵向加计算节点，互不干扰。这也是OpenStack横向扩展的精髓。

1.3 存储后端方案选型：LVM、NFS还是Ceph

加存储节点之前，还得先确定后端选型，因为这决定了你后面要装的软件包、要做的配置完全不同。我见过不少团队在OpenStack部署时前期没定死后端，结果扩容阶段才纠结，临时改后端导致数据迁移惊心动魄。所以这里给个明确建议。

后端方案主要有三种。第一种是LVM iSCSI方案，也就是我本文要详细展开的。它适合起步阶段，成本低、操作直观、易排查故障，单个存储节点的数据可靠性依赖硬件RAID或上层备份。第二种是NFS后端，适合已经有NAS存储阵列的团队，配置相对简单，但性能和并发能力依赖网络存储设备的规格。第三种是Ceph RBD后端，适合大规模生产环境或对扩展性和数据副本有要求的场景，它天然支持多副本、自我修复，但部署复杂度高，扩容时还要考虑Ceph集群自身的OSD扩容。

如果你现在只是“增加一个存储节点”，而且环境里其他节点走的是LVM方案，那就继续走LVM，不要在中途切换后端。存储最忌讳频繁更换底层技术方案，数据迁移的代价远高于你省下的那点运维成本。

2. 新增存储节点前的环境准备与磁盘规划

想清楚架构和方案之后，就可以开始准备“新兵上阵”了。这一步做扎实了，后面安装配置就会很顺，很多扩容失败案例都是因为前期环境没准备好，配置到一半才发现缺依赖、缺时间同步、磁盘分区不对。

2.1 硬件配置和系统版本要求

一台Cinder存储节点需要什么样的硬件配置？我直接给一个基准参考：CPU建议8核及以上，因为快照、克隆操作时会触发比较多的CPU计算；内存建议不低于16GB，虽然cinder-volume本身不算吃内存，但Linux的文件缓存、iSCSI target的内部缓存都会占用内存；硬盘上，系统盘建议单独一块SSD或小容量SAS盘，用于装系统，另外至少准备一块独立数据盘（机械盘或SSD盘均可，取决于你的性能需求），这块盘才是真正给云平台提供存储容量的。

网络方面，存储节点至少需要两个网口，一个走管理网络，用于API通信、OpenStack内部服务互访，另一个走存储网络，用于iSCSI数据传输。如果环境规模不大，网络可以复用，但生产环境一定建议物理隔离存储流量，否则高峰期虚拟机的IO会把管理网络打爆。

系统版本建议和现有OpenStack环境保持一致。比如你的控制节点是CentOS 7 + OpenStack Queens版本，那新存储节点也用同样的系统和版本，别自己整个Ubuntu或者Rocky版本来混搭。OpenStack各服务间的版本兼容性最好保持齐平，跨版本混用很容易出现API版本不匹配、消息队列协议不一致的怪问题。

2.2 主机名、hosts解析与时区规划

新节点加进来之前，主机名必须规范。我遇到过因为主机名带下划线导致OpenStack服务注册异常的事，所以这里强调一下：主机名只能用字母、数字和连字符，不能用下划线，首尾也不能是连字符。

比如你这台新存储节点可以命名为block-storage-01。设置完主机名后，记得在所有节点的/etc/hosts里加上新存储节点的解析记录。OpenStack服务之间会通过主机名互相访问，如果hosts文件不全，控制节点上cinder-scheduler调度卷的时候根本不知道该往哪里发请求。

时区同步同样不能偷懒。你可以在新节点上先把时间手动校准一遍，再安装NTP客户端并指向已有的NTP服务器。如果控制节点自己就是NTP服务器，那新存储节点直接配置为server controller_ip iburst即可。不要小看时间同步，Cinder创建卷、删除卷都会有状态机流转，时间偏差过大轻则日志时间线混乱，重则影响消息队列的时序逻辑。

2.3 新增节点前的软件源和基础依赖

系统装好后，先配好OpenStack软件源。以CentOS为例，需要启用OpenStack对应版本的yum源和extras源，然后执行系统更新。建议先把python3-openstackclient等基础客户端工具装上，这样后面验证服务状态时可以直接在存储节点上执行OpenStack命令。

基础依赖方面，LVM后端方案需要安装lvm2、targetcli或scsi-target-utils、openstack-cinder这几个核心包。这里要提醒一点，targetcli和tgtadm是两套不同的iSCSI target工具，配置不能混用。OpenStack的LVM驱动默认支持tgtadm，也可以通过配置使用targetcli的LIO模式。我这次踩过坑，所以后面配置时会专门展开讲这个选择，避免你重蹈覆辙。

2.4 数据盘分区与LVM逻辑卷规划

数据盘的处理是重头戏。假设你的存储节点有一块2TB的独立数据盘/dev/sdb，操作步骤是这样的：先用fdisk或parted对/dev/sdb做分区，建议创建为Linux LVM分区类型（8e），也可以直接把整个盘建成PV。生产环境我一般建议做分区再建PV，这样后续扩展维护更清晰。

然后创建物理卷（PV）和卷组（VG）：

pvcreate /dev/sdb1 vgcreate cinder-volumes /dev/sdb1

这里的关键点在于卷组名字。OpenStack的Cinder LVM驱动默认会找名为cinder-volumes的卷组，虽然可以通过配置文件自定义卷组名，但为了减少出错概率，直接使用cinder-volumes最省事。另外，卷组空间不要一次性全部分配给逻辑卷，因为你还需要考虑为卷快照预留空间。通常的做法是，创建一个thin pool，后续所有云硬盘都从这个thin pool里分配逻辑卷。

LVM精简配置（Thin Provisioning）在生产环境中确实很实用，它实现了“超额分配”，即多个逻辑卷可以共享同一个底层存储池，只有真正写入数据时才占用实际物理空间。比如你创建一个1TB的thin pool，可以在里面创建20个100GB的云硬盘，只要实际写入总和不超过1TB就不会出问题。但这种模式需要监控到位，一旦thin pool空间用完，所有卷会同时变成只读状态，这是生产事故级别的故障。所以我建议新手先把普通线性卷模式跑通，后续熟悉了再尝试thin pool。

3. cinder-volume服务安装与LVM后端配置实战

前期规划和环境准备就绪，接下来进入实操环节。这一章我会把从安装软件到完成iSCSI后端配置的完整过程拆开讲清楚，每一步都配上说明和验证命令，你照着操作基本不会跑偏。

3.1 安装cinder相关软件包

SSH登录到新存储节点，执行以下安装命令：

yum install -y openstack-cinder targetcli lvm2

安装过程中有一个容易被忽视的细节：openstack-cinder这个包会同时把cinder-api、cinder-scheduler、cinder-volume等组件全部装到系统里。但作为专业存储节点，只需要运行cinder-volume服务就够了，其他组件应该保持关闭状态。有些人图省事，会把openstack-cinder-api和openstack-cinder-scheduler也一并启动，这虽然不至于立刻引发故障，但会造成服务逻辑混乱，而且在多存储节点环境中会造成多个scheduler并发调度，出现不可预知的问题。

安装完成后，确认一下这些组件的状态：

systemctl list-unit-files | grep cinder systemctl list-unit-files | grep target

你期望看到的是openstack-cinder-volume、target等服务的unit文件存在即可，暂时不要启动它们，等配置完成后再统一拉起。

3.2 cinder.conf配置文件详解

OpenStack服务的套路都是配置文件驱动一切。Cinder的配置文件位于/etc/cinder/cinder.conf，它是INI格式的文本文件，其中控制节点和存储节点的配置内容不完全一样。存储节点上的cinder.conf需要重点关注[DEFAULT]段、[database]段、[keystone_authtoken]段和自定义后端段。

先看核心的[DEFAULT]段配置：

[DEFAULT] transport_url = rabbit://openstack:rabbit_pass@controller_ip:5672/ auth_strategy = keystone enabled_backends = lvm-1 my_ip = 10.0.0.21 glance_api_servers = http://controller_ip:9292

其中transport_url是消息队列的连接地址，存储节点的cinder-volume服务需要通过消息队列和控制节点上的cinder-api、cinder-scheduler通信，这里填RabbitMQ的连接信息。注意密码里的特殊符号，如果RabbitMQ密码设的是Fusion@2024这种带@符的，整个URL就会解析错误，建议选择纯字母数字组合的密码作为服务账号密码。或者做URL编码处理。

enabled_backends = lvm-1是重中之重，它声明了该存储节点启用的后端名称列表。如果有多个后端，可以用逗号分隔，如lvm-1, lvm-2。这个名称是一个逻辑标识，后续配置其他段时引用它。

my_ip是存储节点自身的管理IP地址，我这里写的是10.0.0.21，实际填你新节点的管理IP即可。Cinder在创建iSCSI target时，会用这个IP去注册target的IP地址，如果填错或填成不回环地址，后面虚拟机挂载云硬盘时会发现target地址对不上，导致连接超时。

再看数据库和认证相关配置。存储节点上的cinder-volume也需要访问数据库，因为创建卷时，cinder-volume会更新数据库中的卷状态记录。它也需要通过Keystone做认证，这样才能调用Glance获取镜像信息。

[database] connection = mysql+pymysql://cinder:cinder_pass@controller_ip/cinder [keystone_authtoken] www_authenticate_uri = http://controller_ip:5000 auth_url = http://controller_ip:5000 memcached_servers = controller_ip:11211 auth_type = password project_domain_name = Default user_domain_name = Default project_name = service username = cinder password = cinder_pass

这里不推荐在存储节点上单独配置[database]和[keystone_authtoken]，更优雅的做法是直接复用控制节点生成的cinder.conf，然后修改其中和本机相关的部分。很多生产团队的做法是：先在控制节点上把cinder.conf配置好，然后scp到存储节点，再改my_ip、enabled_backends等关键项。这种方式能保证配置一致性，减少手写错漏。

不过有个地方必须手动加，就是后端段的声明。在cinder.conf末尾追加：

[lvm-1] volume_driver = cinder.volume.drivers.lvm.LVMVolumeDriver volume_group = cinder-volumes target_protocol = iscsi target_helper = tgtadm target_ip_address = 10.0.0.21 volume_backend_name = LVM_iSCSI

这段配置决定了Cinder如何与底层LVM和iSCSI交互。volume_driver指LVM驱动类，volume_group使用我们在前文创建的cinder-volumes卷组，target_helper选择tgtadm，target_ip_address则是存储节点在存储网络中的IP地址。volume_backend_name是一个便于识别的后端名称，它会作为该存储节点的唯一身份出现在调度结果中，建议设置为和环境匹配的显眼名称，比如LVM_STORAGE_01。

3.3 iSCSI Target工具选型：tgtadm还是targetcli

这一节单独拎出来讲，是因为它确实是个容易踩坑的点。OpenStack的LVM驱动支持两种iSCSI Target工具：tgt和LIO（通过targetcli管理）。

传统方案是用tgtadm配tgt，它的优点是配置简单、和OpenStack的默认驱动配合最顺，兼容性比较好。但tgt的bug也不少，特别是高并发场景下可能出现target服务假死、连接中断的情况，生产环境经过充分测试后使用还是能接受的。

现代方案是用LIO内核级iSCSI Target，也就是targetcli。它的性能更好，因为是内核态实现，数据路径更短。但OpenStack的LVM驱动要使用LIO时，需要确保系统里安装的是targetcli包，并在配置文件中把以下参数配好：

[lvm-1] target_helper = lioadm target_protocol = iscsi

说实话，我测试过两种方式，在中小规模部署（并发IO不算极端的场景）下差距不大。如果你是新环境且没有历史包袱，推荐直接用LIO模式，也就是targetcli，它有原生openstack兼容性，管理工具也更现代。如果环境中已经存在基于tgt后端的存量卷，那就要保持一致性，别混用。

混用target工具是我见过的最致命的坑之一。比如系统里tgt和targetcli的配置文件同时存在，两个服务都在监听iSCSI端口3260，创建卷时可能出现两个target daemon互相干扰。所以在配置之前，检查一下系统里现有的iSCSI target工具，只保留一种方式。

3.4 启动服务并注册存储节点

配置完成后，就可以启动服务了。依次执行：

systemctl enable --now lvm2-lvmetad systemctl enable --now openstack-cinder-volume systemctl enable --now target

等等，这里有个先后顺序的问题。openstack-cinder-volume服务启动的时候，会去检查卷组是否存在，如果LVM卷组还没创建好，服务会启动失败或无法正常初始化后端。所以务必保证cinder-volumes卷组已经存在再启动服务。LVM后端的Cinder驱动要求卷组里必须有空闲空间，哪怕是1GB也好，否则初始化时也可能报错。

验证服务状态：

systemctl status openstack-cinder-volume tail -f /var/log/cinder/volume.log

日志里看到类似successfully initialized或Driver init successful字样，说明后端初始化成功。

接下来在控制节点上验证存储节点是否成功注册。在控制节点执行：

openstack volume service list

输出中应该能看到新存储节点对应的cinder-volume服务状态为up，并且显示对应的host名称，比如block-storage-01@lvm-1。如果这里看不到新节点，多半是配置文件有问题或者服务没注册消息队列，排查顺序建议是：先看存储节点的volume.log，再看RabbitMQ中队列是否创建，接着确认Keystone中cinder服务账号是否有效。

4. 调度验证、连通性测试与日常监控

服务启动成功只是第一步，真正的好戏在于验证新存储节点能否正常接收卷创建请求、虚拟机能否成功挂载卷。这个阶段往往能暴露很多只有实际业务流量才会触发的问题。

4.1 创建测试卷验证调度逻辑

Cinder的调度器（cinder-scheduler）由一个称为FilterScheduler的组件实现。它通过过滤器（Filter）和权重（Weigher）两个阶段来选择最佳存储后端。常见的过滤器包括AvailabilityZoneFilter、CapacityFilter和BackendFilter，它们从不同维度筛选出满足条件的候选节点。当控制节点接收到创建卷请求后，scheduler会根据后端可用信息来评估，最终把请求路由到合适的存储节点上。

为了验证新存储节点是否真的被纳入调度，我们在控制节点上创建一个测试卷：

openstack volume create --size 1 --availability-zone nova test_vol_001

创建后，用openstack volume list查看卷的Status和Attached to列。如果状态能从creating变为available，说明整个链路正常。更具体的验证是查看卷被分配到了哪个主机上：

openstack volume show test_vol_001 | grep properties

或者直接查数据库：

mysql -ucinder -pcinder_pass -e "select id, host, status from cinder.volumes where display_name='test_vol_001';"

看到host字段里有block-storage-01@lvm-1，就说明新存储节点真正接入了业务。倘若卷一直在creating状态，大概率是scheduler没选到新节点，优先查cinder-scheduler日志、新节点的cinder-volume日志以及RabbitMQ连接状态。

4.2 iSCSI挂载连通性测试

卷创建成功以后，还要验证计算节点到新存储节点的iSCSI链路是否畅通。在计算节点上安装iscsi-initiator-utils，然后手动挂载这个卷测试连通性：

openstack volume list openstack volume show test_vol_001 | grep attachments

把卷附加到虚拟机时，OpenStack会通过nova-compute触发iSCSI discovery。如果手动做连通性测试，可以先找到卷对应的iSCSI target：

iscsiadm -m discovery -t sendtargets -p 10.0.0.21

正常情况下能看到类似10.0.0.21:3260,1 iqn.2010-10.org.openstack:volume-...的target输出。如果没有显示，检查存储节点上的target服务状态和防火墙设置。很多初装环境最后排查一圈发现是防火墙拦了3260端口，所以直接先执行：

firewall-cmd --permanent --add-port=3260/tcp firewall-cmd --reload

或者干脆测试阶段先临时关闭防火墙，验证通了再按生产需求配置精确放行策略。

4.3 多存储节点环境下的后端权重调整

如果你的环境里现在不止一台存储节点，那就涉及后端权重分配的问题。Cinder的权重机制通过CapacityWeigher实现，默认策略下，剩余容量更大的节点会被优先选中。这个逻辑在大多数场景下没问题，它能均衡各节点的容量消耗。

但有一种情况需要手动调整：当所有存储节点的硬件性能差异明显时，比如一台是普通机械盘，另一台是全闪存盘，仅仅按容量加权轮询会把IO压力同时打到两台设备上，导致性能定义混乱。这时你可以通过修改配置来调整后端权重：

[DEFAULT] weight_slopes = -1.0

需要注意的是，这个参数设置的是可用容量权重斜率，正值显示偏好大容量节点（默认），负值反之。它并不能完全做到“性能优先”，更合理的做法是通过启用不同的存储后端类型来实现不同性能级别的卷服务。

在实际生产环境里，我更推荐按照业务范围划分存储后端。比如后端A定义为LVM_SATA，专门给归档类业务提供大容量低成本存储；后端B定义为LVM_SSD，给核心数据库提供高性能存储。通过创建卷类型（Volume Type）来约束业务归属，配合调度过滤器，实现逻辑隔离。

4.4 存储节点的日常巡检与容量监控

新节点上线后，日常运维不能只靠跑一次systemctl status就完事。存储节点的核心关注指标有三个：卷组剩余空间、iSCSI target连接数、磁盘IO健康度。

卷组剩余空间可以用以下命令快速检查：

vgs

重点关注VFree列，当剩余空间低于20%时就该规划扩容了。我经历过一次事故，某存储节点的卷组剩余空间跌到5%，当时还在大量创建卷，结果某次快照写入直接导致thin pool空间耗尽，所有卷瞬间不可写。所以至少在VG里预留20%以上的空间冗余，有条件的直接上thin pool并使用容量告警阈值监控。

iSCSI target连接数可以这样看：

targetcli ls tgtadm --op show --mode conn

正常情况下，target连接数应该和计算节点上附加到该存储节点的卷数量线性对应。如果连接数异常波动，可能是网络不稳定或计算节点上的iscsi initiator服务异常循环重连，这时需要查看计算节点上的/var/log/messages和iscsid日志。

磁盘IO健康度建议用iostat、iotop组合，重点看%util是否长期超过80%。机械盘长期满载会加速老化甚至导致IO timeout事件，SSD盘则要看写入寿命。

我再分享一个小经验。日常巡检时在存储节点配置一个cron脚本，定期往一个非关键目录写入文件并校验内容，比如每5分钟写入一个health_check文件，然后读取确认一致。这个方案能快速暴露底层文件系统或LVM映射异常。相比单纯的systemctl status，这个更贴近实际IO路径，我曾经靠它提前发现过一次RAID卡固件异常导致的偶发读写错误。

5. 常见问题与排查技巧实录

加了这么多次存储节点，我总结出几类高频故障和排查思路，这里直接以表格加实例的方式整理出来，建议你收藏备用。

5.1 排查实例：新节点状态down但服务进程正常

有一次我加一台新存储节点，cinder-volume进程在跑，但控制节点上一直显示down。排查了很久，最后发现问题出在/etc/hosts上。新存储节点没有把自己加进hosts文件，hostname解析指向了回环地址，导致服务注册时上报的主机名解析失败，控制节点无法确认它的心跳。

这个问题的解决很简单，把主机名写进/etc/hosts并重启服务就恢复了。但教训很深刻：OpenStack内部服务自检依赖完整的域名解析，/etc/hosts哪怕漏了自己都可能导致看似正常的服务不正常注册。

5.2 排查实例：卷能够创建但下发到虚拟机后无法识别

还有一种情况是卷创建成功，附加到虚拟机后虚拟机操作系统里看不到新硬盘。这种问题通常是物理链路和协议层面的错误。

先从计算节点检查iSCSI会话状态：

iscsiadm -m session -P 3

如果session显示连接正常但LUN数量为0，说明target导出有问题；如果session都建立不了，就要看存储节点上tgtadm --op show --mode target的输出的target配置是否完整。我记得有一次就是因为在多路径环境下没有安装multipathd，导致一个卷被识别成多个异常路径，虚拟机里看到的设备号错乱，最终无法正常分区格式化。装上device-mapper-multipath并重启iscsi服务后问题解决。

5.3 经验性建议：扩容存储节点前应该先做什么

结合我自己的经验，扩容前还应该做三件不紧急但重要的事情。第一，备份控制节点上的cinder.conf和nova.conf，扩容过程中如果误改了配置，可以快速回滚。第二，标记现有卷的容量分布情况，记录哪些存量卷已经占用了多少空间，方便预估新节点加入后是否需要做容量均衡。第三，制定回滚方案。虽然加存储节点不算高风险操作，但如果你是在业务高峰期操作，万一碰到预期之外的问题，至少能快速回到扩容前的状态。

有一说一，LVM后端的扩容不是特别复杂，但它非常考验对OpenStack内部机制的熟悉程度。你理解了调度器如何选后端、cinder-volume如何注册状态、iSCSI target如何暴露存储，再遇到新场景就不会手足无措。

最后再聊一个实用技巧。新节点加入到现有环境后，建议先在控制节点上调整卷创建时默认的可用域（Availability Zone）。如果你创建卷时不指定可用域，调度器会按照默认可用域过滤节点，如果新节点没有归属到正确的可用域，创建请求可能永远轮不到它。在生产环境中，如果一个可用域里的存储节点数量较多，合理划分可用域能显著减少调度压力。这里就涉及OpenStack的可用域机制了，它本质上是一个逻辑分组，需要保证每个存储节点至少归属于一个可用域，并且该可用域下包含可用的存储容量。把一个新存储节点划归到承载核心业务的可用域时，务必确认该可用域下的网络、计算节点等也配套到位，否则卷创建成功却无法被虚拟机拉取时，排查起来更加耗时。