分类归档: Tech.Memo

如何避免 Unix 环境中的 ‘rm -f’ 灾难

在 ITPub 论坛上，最近有朋友发起了一个”请列出你在从事DBA生涯中,最难以忘怀的一次误操作“话题讨论，如果有足够的耐心看下去的话，会发现很多误操作都是类似的，最上镜的就是这个操作系统级别的 “rm -f” / “rm -rf” 了。

在那本著名的 Unix 痛恨者手册上，rm 问题也作为一个罪状而提出。的确，Unix/Linux 的这个 rm 的 -f 参数是系统管理员（SA)乃至数据库管理员(DBA)最容易引发系统灾难的导火索。

如何避免这样的灾难发生呢?

如果一个人能不犯任何误操作就好了。但这是不可能的。我相信肯定有很多 DBA 或 SA 到现在也没烦过这样的错误，但不要忘了墨菲定律的诅咒。

1.有安全的 rm 命令麽?

一种比较理想的是如果编译源代码的时候把这个 -f 选项去掉，肯定能让不少人少犯错误。不过搜索了整个网络，好像还真没有具体如何操作的。Sun 的 Solaris 10 对 rm 作了一点改进处理，”rm -rf /” 是不允许的。可惜的是 “rm -rf *”类似的操作是没限制的。另外，对于其他系统也不可用。或许，将来 GNU/Linux 能有改进。

2.Alias 方式

第二个方式是在 Profile 层次上设置命令别名( alias ).

alias rm="rm -i"

这也是最常用的方式。如果脚本上直接调用了 rm 命令的全路径，还是不管用的。这其实也是如果功能上没办法完全禁止，那就提高用户的使用成本 :)

3.替代命令

第三个方法是使用替代命令。如用一个 del 命令来替代 rm. 这个就要挑战用户的使用习惯了。真的会始终用替代命令麽? 这个方式需要注意的是，无论如何不要真的把 rm 命令挪走(比如物理的 rename 名字)，如果这样，是很糟糕的策略。

4.修改权限

也有不少人直接把 rm 的权限修改，比如只允许 root 用户而不允许普通用户执行命令。这在调用一些脚本或者编译文件的时候，很容易引来很多麻烦。

任何一种策略，如果要扩大应用到一个团队的话，还需要考虑使用习惯对其他成员带来的影响。毕竟，”不爽”也会让很多人更容易犯错。

最后，友情提示，有的人经常通过层层跳板 Login 到主机上，可能会因为忘记了”身在何处” 而犯错误，最管用的方式是设置一下 PS1 环境变量。比如我在 Dreamhost 上用这样的：

PS1="\n\e[1;37m[\e[m\e[1;32m\u\e[m\e[1;33m@\e[m\e[1;35m\h\e[m \e[4m\`pwd\`\e[m\e[1;37m]\e[m\e[1;36m\n\e[m\\$ "

–EOF–

Linux 的多路径 IO 技术

作为 DBA，多多少少要关注点儿关于主机到存储这段链路上 IO 的可靠性问题，Multipath I/O(MPIO) 是需要要了解一下的。业界 MPIO 相关的软件不下几十种，但商业软件居多，开源的似乎只有 Device-Mapper，这也是 Linux Kernel 支持的多路径 IO 软件解决方案。

Redhat 应该是从 RHEL4 U2 开始正式增加的对 Device Multipath IO (MPIO) 的支持。SuSE Linux 则是在 SLES9.2 以后就提供支持了，谁先谁后我还真的不知道，不过SuSE 在这方面还真是一直比较激进，或许这也反映了追赶者的一些急躁心态。

关于如何设置 DM 可以参考 RedHat 站点上的一篇 FAQ：How do I setup device-mapper multipathing in Red Hat Enterprise Linux 4?。对于 RHEL 5 ，有一本 Using Device-Mapper Multipath 手册。另外，这里有篇中文的测试，步骤比较详细。

有些存储厂商在 Linux 上没有自己专有的多路径工具，如果需要类似的功能一般是推荐用 DM，但是我对负载均衡算法还有些持保留意见。 IO 路径选择器只有默认的 round-robin 。在负载均衡配置下，似乎这东西每个路径在 1000 个 IO 之上就会重新选择路径(这个地方我不确定，谁来澄清一下?)。没有最小 IO 队列算法和最小服务时间等算法可供选择。

涉及到的 Oracle 支持情况: Oracle ASM 支持 DM 映射出来的设备.

–EOF–

Linux 如何不重启而识别新增的 LUN

插播一则广告：来自 ITpub 的朋友请帮忙投一票。
拉票这事情我还真的干得不多，第一次搞，脸皮虽然厚也有些发烧，因为已经有DBA在说“熙熙攘攘"了。

有些 Linux 数据库服务器用的比较低端的存储，因为业务的变化，有时候需要新增一些 LUN。Linux 服务器添加 LUN 后必须要重启动 ? 有的时候存储厂商工程师也这么说，不过这似乎是一个一直被误解的信息。

从专攻存储的同事那里得知利用 QLogic FC HBA LUN Scan Utility 这个脚本即可无需重启动系统而识别新添加的 LUN。也无需对 QLogic FC driver 的重新 Load。

场景：Linux Server + QLogic 的 HBA 卡。以 QLogic 的 Qla2340 HBA 卡为例。下载该脚本(顺便说一下，该页面的 QLogic FC HBA Information Utility 也比较有用)。然后看一下脚本说明文件。

用法最简单只需要运行：

# ./ql-dynamic-tgt-lun-disc.sh

脚本会提示在没有活动 IO 的情况下运行。其实问题不大的了。之后确认 OS 识别到新设备:

 # fdisk -l

如果系统中有 PowerPath ,还需要运行：

# powermt config

OK。多少提高了一点系统可用性，你可以不用向老板申请停机维护了。

附：另外一篇参考文档.

–EOF–

EMC CLARiiON 的 Alignment offset

今天参加了 EMC 组织的存储技术培训。因为频繁被电话打扰，导致听课效果并不是那么好。很多内容似曾相识，只是都断断续续的，几乎每次培训都是这样的，总有”断点”。

上午是 CLARiiON 的简单介绍，在模拟操作的时候我发现了以前漏掉的一个盲点：Binding LUN 的时候，那个 Alignment Offset 的选项到底是干啥的? 讲师简单说了一下，感觉不太对路子。刚才闲下来，查找了一下这个信息，大致搞明白了这个 ”Alignment offset“。

用 ”Alignment offset EMC“ 作关键字搜索到的第一篇文档是 Dell 工程师写的。这里面用了一个词 “signature block” , 莫名的一个词，我相信是 Dell 工程师自己发明的(用 Metadata 不就得了)。另外两个关键词是 “Windows” 和 “31.5KB” ，为啥是 31.5KB ，不知道。接下来在 EMC 的 Powerlink 网站上找到了比较详细的说明。

首先确定一下，这个问题更多是影响 Windows 系统。

老的 BIOS 代码，使用 ”柱面、磁头、扇区数“这一套机制而不是 LBA （Logical block addressing ）的模式来寻址。Linux 的 fdisk 工具还是 Windows 磁盘管理器，在每个格式化的设备上都放置一份 MBR 。这个 MBR 占用 63 个隐含扇区 (63*512=31.5KB, Bingo!)。这个问题在 Windows 上存在，在 VMware 上也存在，offset 同样是 63。在有些 Linux 上，因为 Boot Loader 的不同，也会有类似的问题。

无视 Alignment offset 会导致的问题:

如图所示，一个 IO 会分裂到两个 Disk(Device/LUN) 上去，后果很严重。和我以前描述过的 4k Offset 问题本质上是一样的。只是这个是针对文件系统的。

那么，如何校正这个 ”对齐偏移量” 呢?

存储厂商的推荐是如果用 Snap View / SAN Copy 等存储级别的操作的话，不要折腾，用系统默认的就成，否则，用主机端的解决方案。

主机端的解决方案分为 Windows 32位、Windows 64 位、Linux、VMware 几种。

1）对于 32 位的 Windows ，使用 Windows 系统资源包的 diskpar.exe 来设定 offset ( 据说 Windows 2003 SP1 上的 diskpart.exe 已经具备了 diskpar.exe 的功能。refer)

2）对于 64 位的 Windows ，GPT(GUID Partition Table)类型的分区默认有 32M 保留区，MBR 类型的分区自动校准。不存在这个问题。这就是 64位的 Windows 众多优点之一啊。

3) 对于 Linux ，fdisk /dev/{devicename} 然后进入 expert 模式, 然后输入 b …

4) 对于 VMware，分为两种情况。虚拟机层（用虚拟机下操作系统的方案) 以及 ESX 服务器层 (fdisk).

上面几个步骤描述不详细，更详细的介绍你需要寻找一份白皮书： EMC CLARiion Best Practices for Fibre Channel Storage ，这个白皮书有针对 Flare 不同版本的，Flare 2.6 对这个问题有了比较好的改进。

是的，有的时候白皮书就在那里，只是没有人注意，没有看而已。

–EOF–