记得那是好几年前的事儿了，公司里那几台跑核心数据库的服务器，时不时地就给我来点小状况。说不上宕机，但就是那种时不时卡顿一下，或者IO性能突然就往下掉的感觉，特别让人心里犯嘀咕。大家伙都知道，数据库这玩意儿，稳字当头，一点儿也马虎不得。
本站为89游戏官网游戏攻略分站，89游戏每日更新热门游戏，下载请前往主站地址:www.gm89.icu
当时我就琢磨，这单链路跑存储，风险太大了。万一哪天光纤线磨损了，或者存储那边控制器有点儿小脾气，那数据库可就直接歇菜了，想想都冒冷汗。于是我就把心思动到了“多路径”这上面，寻思着怎么能让服务器多几条道儿去连存储。
那会儿，我对这玩意儿也是一知半解。就听过大概能让服务器通过几条不同的路去访问存储，一条路要是断了，还有别的路可以顶上。可具体要怎么个弄法，心里完全没谱。于是乎，我就开始在网上搜，各种技术论坛、博客，翻了个底朝天。慢慢地，就摸索出来一个叫 multipathd 的守护进程，说是能搞定这事儿。
上手第一步：把工具装上
知道了有这么个玩意儿，第一步当然是把它请进门。我们当时服务器跑的是CentOS，所以安装起来还算方便。我直接打开终端，敲了个命令：
sudo yum install device-mapper-multipath -y
回车一按，屏幕上哗地就滚过一大堆信息，下载、安装、依赖，一气呵成。看着显示“Complete!”，心里总算是松了一口气，第一步成功拿下。
核心大挑战：捣鼓配置文件
软件装好了，我天真地以为这事儿就算成了大半。结果一查，发现这东西还得配个文件才能跑起来，就是那个 /etc/*。第一次打开这文件，里面密密麻麻的都是英文和各种参数，看得我眼睛都花了，头皮都有点发麻。
先说清楚谁不该管：黑名单
翻了好多文档，才搞明白这配置文件怎么弄。得告诉 multipathd 哪些设备是你不想它去管的。比如服务器自己本地的硬盘、光驱、U盘之类的，这些都不需要多路径。我就找到了 blacklist 区块，把我本地的那些设备类型和名称给加了进去。我记得当时就琢磨着，把那些什么 ram、loop、fd、sr0、sda 这些都给列进去，省得它瞎折腾。
定规矩：默认参数得设好
接着就是 defaults 区块，这里面设置的是一些通用的、默认的参数。这块儿是重头戏，我当时是这么搞的：
user_friendly_names yes：这个绝对是必须开的！不然multipathd给你生成的设备名字，都是一长串数字字母组合，看着就晕。开了这个，它就能自动生成像mpatha、mpathb这种简单好记的名字，一下子就清爽多了。path_grouping_policy multibus：这个是决定多条路径怎么分组和工作的。我反复对比了好几种策略，觉得multibus最适合我们当时的情况。它能让所有可用的路径都同时处于激活状态，一起跑数据，这样IO性能就能上去不少。path_selector "round-robin 0"：路径选择器，我选择了轮询模式。这意味着数据会以轮流的方式，平均地分摊到每一条可用的路径上，避免某条路径过载，也算是提升性能的一个小技巧。failback immediate：这个也很关键。万一某条路径出了问题，multipathd会自动把IO切换到其他健康的路径上。当这条故障路径恢复正常后，设置成immediate就能让它立马自动切回来，不用人工干预。no_path_retry 5：如果所有的路径都挂了，multipathd也不会立马放弃，它会再重试几次。我设了5次，就是给它一个短时间的缓冲，避免因为网络短暂抖动就直接报错。polling_interval 10：这个参数就是告诉multipathd，每隔10秒钟去检查一下所有路径的状态，看看有没有挂掉的，或者有没有恢复正常的。
给特殊存储开小灶：指定设备参数
我们用的是EMC的存储，我记得当时还特地去EMC的官网和社区找了它们的最佳实践文档。结果发现，EMC对于自己家存储的 multipathd 配置，有一些特别的推荐值，跟 defaults 里我设的可能不太一样。那怎么办？
我就在 文件的 devices 区块里，专门给我们的EMC存储开辟了一个小天地。我找到了存储的厂商（vendor）和产品型号（product），然后把EMC推荐的比如 hardware_handler、特定的 path_grouping_policy 等参数，针对这个存储型号单独写了进去。这样，这些专门的设置就会覆盖掉前面 defaults 里的通用设置，只对我的EMC存储生效。这就像是给个别“VIP”客户单独定制服务一样。
看效果：启动和验证
配置文件改好了，这还没完事儿，得让它生效。我当时的步骤是这样的：
- 先把
multipathd服务重启一下：sudo systemctl restart multipathd。 - 然后，就是最激动人心的验证环节了。我最常用的命令就是
multipath -ll。
一敲下去，屏幕上密密麻麻地输出了一大堆，但仔细看，就能看到每个存储LUN对应的都有一个 mpath 开头的设备名，下面还清清楚楚地列着所有跟它相连的路径。每一条路径的状态都写着 active 或者 ready。如果看到有路径显示 faulty 或者 failed，那我就知道得去检查光纤线、HBA卡或者存储那头是不是出问题了。
为了看得更细致，我有时候还会用 multipath -v3 这个命令，它能输出更详细的诊断信息，哪个参数生效了，哪个被覆盖了，都能看得清清楚楚。
实战演练：模拟故障
光是看命令输出是远远不够的，这东西得经受住考验才算真正成功。我当时是跟存储工程师提前打好招呼，找了个业务不忙的时间，进行了一次模拟故障测试。我们先是小心翼翼地拔掉了一根服务器到存储的光纤线。然后我立马跑回服务器，用 multipath -ll 命令去查看。
果然，有一条路径变成了 faulty 状态。但让人欣慰的是，数据库业务根本没有受到影响，依旧平稳运行，数据还在正常读写。确认没问题之后，我们又把那根光纤线插了回去，再一看，故障的路径很快就自动恢复了正常。
整个过程虽然有点提心吊胆，生怕一个手抖把生产环境给搞崩了，但都顺利通过了。经历这回配置和测试，心里那块悬着的石头才算彻底落地。后来服务器的IO确实也比以前稳当多了，再也不用担心单点故障了。这东西虽然刚接触时看着有点复杂，但真自己动手实践一遍，也就那么回事儿，慢慢就摸清门道了。多看文档，多动手，总能搞定。