蓝的成长记——追逐DBA（13）：协调硬件厂商，六个故事：所见所感的“服务器、存储、交换机”

浏览数：35 / 时间：2015年06月12日

原创作品，出自 “深蓝的blog” 博客，欢迎转载，转载时请务必注明出处，否则追究版权法律责任。

深蓝的blog：http://blog.csdn.net/huangyanlong/article/details/43989939

【简介】

个人在oracle路上的成长记录，其中以蓝自喻，分享成长中的情感、眼界与技术的变化与成长。敏感信息均以英文形式代替，不会泄露任何企业机密，纯为技术分享。

创作灵感源于对自己的自省和记录。若能对刚刚起步的库友起到些许的帮助或共鸣，欣慰不已。

欢迎拍砖，如有关技术细节表述有错误之处，请您留言或邮件（[email protected]）指明，不胜感激。

【前言】

这是一部个人记录的成长杂记，既然步入到oracle的这片蓝海，免不了一路的奔波与不断的考验。借由此杂记与库友们分享蓝的成长历程。

不知何时起对蓝有了一种说不出来的痴迷，痴迷其广博，痴迷其深邃，痴迷于近在咫尺却又遥不可及。

而又说不清从何时起，注视于oracle的红色耀眼，照亮出眼前的一道光，未知与迷惑在自己的脚下开始初露些许人生的充实与青春的回馈。

在追逐于DBA梦想的道路上步步前行。

___________________________________________________________________

面对自己不懂的知识面，抓住机会，就要“多问多学多看”。

——深蓝

___________________________________________________________________

第一个故事：多看——服务器磁盘的损坏

现象：服务器启动不正常。

开始说之前，想提的是，作为一个想从事数据库方面或是IT领域的人士们，不要认为小概率的事情就不会发生。因为这次发生的就是小概率。

下面记录了一个小操作，源于服务器的一块磁盘损坏，致使服务器在安装操作系统后，启动卡在滚动条界面。开始的时候，不知道这是怎么回事。看到系统厂商的工程师，敲击了下“ESC”，这才云开雾散，因为这时我看到了系统的启动过程，报出了检测一块dev设备(磁盘)时遇错了，而无法继续下去。突然想到这块磁盘在昨天硬盘指示灯确实红灯亮起过，报过故障了。只不过后来恢复正常绿灯了（不知道为什么），想毕应该是这块硬盘仍然存在不确定问题（排除了松动，怀疑存在坏道或控制器损坏等原因）。于是借由硬件厂商联系了服务器厂商（浪潮原厂工程师），一番描述后，联系好第二天会到现场检测。再之后，浪潮来的工程师更换了这块故障磁盘，系统启动恢复正常。因为磁盘做了RAID5，允许一块磁盘损坏。所以操作系统和原磁盘数据并未损坏和丢失。而最终确定，系统无法启动是因为自检这块磁盘时不通过，因为系统不通过检测，系统就会反复的对这块磁盘进行检测，从而出现了卡顿现象。

最后想说的是，这个服务器是跟随项目全新上线的，从系统集成商来装系统，到我方在现场检查硬件情况，前前后后，不出一周时间。而就在没有任何业务压力的情况下，一块磁盘莫名其妙的坏掉了。但遇到这种情况，见得多了就不以为新奇了，任何电子产品都有可能出现不确定问题。这也就是为什么会有容灾方案的原因吧。哈，所以这才意识到，硬件厂商的质保期不是没有用的，因为在出厂的时候，可能厂商就预见到了会有损坏的，这种情况是目前人为所不能控制的。但转念一想，是不是暴漏本身产品的质量缺陷呢？联想到了锤子手机的碎屏险，是不是因为工程师预见了屏幕的破损概率大，于是就做出了一个质保的方案呢（我这里胡思乱想了）。也怀念曾经的“诺基亚”，假设不给质保也不会担心有损坏问题（质量好啊）。但，或许这正是人类科技水平发展的道路上，在探索的过程中必然要经历的，进步是需要付出一定代价的。

至此，想再提一下这个简单的操作：就是在启动LINUX系统时，在进度条界面，如果我们点击ESC就会看到系统启动时进行的操作。如下图：

技术分享

点击“esc”，可以看到启动过程，如下：

技术分享

说实话，以前还真不知道。

学到了点皮毛，还是感觉惭愧，这个小操作竟然才知道，诶呀~~~。引以为戒了，不知道大家都知道不，反正我以前不知道，以后就知道了。

第二个故事：多问——什么叫多路径？

来源于主机（PC-server）、小型机连接“光纤交换机”时，再连接“光纤存储”，这样就会形成多条链路，如果在主机上从存储划出一块盘，可能会在主机上映射出很多块盘，会让操作者无法选择应该操作那一块磁盘。为了避免这个繁琐的磁盘链路，就会使用到多路径软件，将多条路径聚合到一起。既起到方便管控磁盘的作用，也起到负载均衡的效果，假设一条链路断掉，其它链路仍然可用，这样不会影响对于磁盘的访问。

几款多路径软件：

（1）、IBM主机和IBM存储：RDAC、MPIO、SDDPCM

（2）、日立的存储：HDLM

（3）、EMC存储：PowerPath

第三个故事：多学——存储中的LUN？

（1）、初探LUN

LUN是SCSI协议中的名词，是SCSI ID的更细一级的地址号，每个SCSI ID（Target ID）下面还可以有更多的LUN ID。对于大型磁盘阵列，可以生产几百甚至几千个虚拟磁盘，为每个虚拟磁盘分配一个SCSI ID是远远不够用的。因为没有SCSI总线最多允许16个设备接入（目前32位SCSI标准最大允许32个设备）。要在一条总线上放置多于16个物理设备也是不可能的，LUN就是这样一个次级寻址ID。磁盘阵列可以在一个SCSI ID下虚拟多个LUN地址，每个LUN地址对应一个虚拟磁盘，这样就可以在一条总线上生成众多虚拟磁盘，以满足需求。

后来，人们把硬件层次生成的虚拟磁盘，统一称为“LUN”，不管是不是在SCSI环境下，虽然LUN最初只是SCSI体系里面的一个概念。而由软件生成的虚拟磁盘，统一称为“卷”，比如各种卷管理软件、软RAID软件等所生成的虚拟磁盘。

--摘自张冬瓜，大话存储2

（2）、SAN

下面展示一个SAN存储架构图（来源于电子书中），如下：

技术分享

SAN（storage area network）：关于存储区域网络

网络，不仅仅指以太网、TCP/IP网，可以是SCSI网、PCI总线网、USB网等。RAID控制器，就相当于一个路由器，也就是协议转换器。

将磁盘放到了主机外部，存储设备和主机之间，就形成了又一个独立的网络：存储区域网络（Storage Area Network，SAN）。

（摘自，张冬瓜，大话存储2）。

（3）、存储的规划方案

最后，由于方案前期采购出现的错误（因为当时我方还未介入），没有采购光纤交换机，而是采购的华为的S5700S系列，虽然效率上有些失望，但还是把我们应该做的工作做好吧。

完成存储的划分，其中包括存储的RAID部署、存储初始化、RAID分区（划分存储分区方案由我方提出，硬件厂商给予实施）、完成映射（在多服务器系统内需要安装多路径软件）。

面对着12块、6块磁盘存储盘阵，简单阐述下存储方案，如下：

存储名称	RAID方案	物理容量	可用容量	LUN划分
数据库存储	RAID5+热备盘1块	12*3TB	10*3TB	（320G）+（55500G）
备份存储	RAID5+热备盘1块	6*3TB	4*3TB	2*5119G
数据库服务器	RAID5	6*1TB	5*1TB	4T+1T

看一眼实物图：

技术分享

第四个故事：犯了低级错误之断电

凌乱的线缆，还没来得及整理的线缆，先体验了一把突然断电的爽快。这是发生的一次意外断电以致使服务器宕机。其实恢复这个很简单，只需要到机房重启即可。而这次，我犯了低等的错误。由于之前有过一次网络部门随意拔掉了我们一次网线的经历，我下意识的把这次认为是“人为事故”，看了一眼数据库服务器的状态，指示灯运行正常的，就跑到了机柜的后部查看电缆，如下图：

技术分享

而这次我犯了错误。由于自己的粗心大意，直接去了网络部，找到了网络部门的工程师，并表示服务器没有问题，但是网络不通了。而网络工程师倒也没有任何隐瞒说昨天有过一次断电，不知道是否和这有关系。于是去查看了接入局域网的端口线，但是没有发现问题。然后查看了我方交换机的vlan设置，表示说可能断电引起设置冲掉了。截止到此，我们在错误的方向上开始了天方夜谭。为什么这么说，原因有下：

1、路由器断电不能使其配置失效（不知道当时网络工程师是故弄玄虚还是真的这么想的，我差点就信了，诶呀~~，这里我承认，我弱智了，难道还有把配置信息放到内存里的不成，额~~(⊙o⊙)。）

2、断电后直接反应应该确认服务器是否启动，而不是去直接联系网络部（这里我又二了一把，诶呀~~，又弱智一次）。之所以会产生如此低级错误，其实原因很简单。其实我原本查看了服务器，不过只是查看了数据库服务器，因为这两台服务器设置了通电后自动启机了。而没看其它服务器，造成了这次低级错误的发生。