分类归档: 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;[email protected]\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 会导致的问题:

alignment_offset.png

如图所示,一个 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