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

【简介】

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

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

欢迎拍砖，如有关技术细节表述有错误之处，请您留言或邮件（hyldba@163.com）指明，不胜感激。

【前言】

这是一部个人记录的成长杂记，既然步入到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块磁盘存储盘阵，简单阐述下存储方案，如下：

看一眼实物图：

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

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

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

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

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

第五个故事：让人郁闷的PDU

电源的固定，简单的事一拖再拖。跟协调的人有关，但之所以郁闷，本无关的事变的有关了，而后又没处理好，这就郁闷了。

这个说来，本应该负责的部门不负责，也就是机房管理方，而硬件服务商、系统集成商或我们软件开发商都表示不承担这部分的工作。所以客户头也大了，连线缆还没有进行布设（就像上图那样，凌乱呐~~）。由于线缆没有布设，机柜中的线缆凌乱的被塞到了服务器后面，给正常运行造成了安全隐患。

好在，在过了许久之后，终于，客户自行解决了这个问题，我们的硬件设备也总算是稳定下来了。

稍微了解一下PDU,PDU(电源分配单元), Power Distribution Unit也被称为“机柜电源插座”，如下两张图：

第六个故事：开阔视野——直面传说中的“oracle一体机”

原以为神秘又高大上的一体机，没成想，一个不小心，这个价值千万元级别的设备就这样活生生的展现在了我的眼前。

记得之前在一节oracle公开课中，简单了解了一下exadata（oracle一体机），在这里做个简单的回忆，从解决四方面问题入手的一体机。

（1）、如何解决传统数据库部署所带来的性能问题？

传统的数据库部署：

存储层：1、数据量增加IO瓶颈；2、数据分布不均；

网络层：带宽不足

服务器层：过多数据处理

解决思路：减轻负载、加宽带宽、提高并行

1、加宽通道

2、减少数据量传到数据库服务器

3、增加系统并行处理

理念化：

存储横向扩展，实现并行处理能力

存储层：智能化、预处理

服务器端的卸载预处理工作分担到存储层，处理完后返回给数据库服务器。

（2）、解决了资源独立，无法共享的问题？

传统数据库：

分配给不同的主机，不是共享的，分配资源不均，有些资源不足，有些资源过度。生产环境动态变化，无法动态满足负载的目标

设计原则：资源共享、资源控制

解决：

如：1、把存储服务器的资源变成一个存储池，一个存储池给一个或多个数据库使用，服务器都可以用到所有磁盘的能力，满足IO吞吐量；

2、对IO进行控制，根据业务的优先级来处理。

（3）、解决复杂的数据库系统均衡化配置？

传统数据库：

大型的存储系统，EMC存储；

分区；

设备昂贵；

技术维护管理；

总的代价开销非常大；

让一体机实现性能均衡化：

使用exadata，平衡及优化的配置

主机、存储、数据库、应用程序：调优

exadata端到端优化：硬件软件配置好了的

易于上线，不需设计、调优、维护、设置

（4）、如何解决系统的维护和扩容过程复杂

一体机：

简化部署：消除复杂部署；

当天部署完成，获得极限性能。

以上通过理论性、概述式的介绍了一下一体机，其中具体的技术细节并没有涉及到，如果对于exadata的技术真正感兴趣的朋友，不妨去看看官方手册或参考文档，相信会有所收获的。

这里对于一体机的了解我也是刚刚开始，就简单介绍这些吧，毕竟还是菜鸟，O(∩_∩)O~

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

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