蓝的成长记——追逐DBA(13):协调硬件厂商,六个故事:所见所感的“服务器、存储、交换机......”

版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/huangyanlong/article/details/43989939

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

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

 

 

【简介】

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

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

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

【前言】

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

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

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

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

 

 

___________________________________________________________________

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

                                                                                                              ——深蓝

___________________________________________________________________

 

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

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

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

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

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

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

点击“esc”,可以看到启动过程,如下:

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

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

第二个故事:多问——什么叫多路径?

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

 

几款多路径软件:

1)、IBM主机和IBM存储:RDACMPIOSDDPCM

2)、日立的存储:HDLM

3)、EMC存储:PowerPath

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

1)、初探LUN

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

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

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

2)、SAN

         下面展示一个SAN存储架构图(来源于电子书中),如下:

SANstorage area network):关于存储区域网络

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

        将磁盘放到了主机外部,存储设备和主机之间,就形成了又一个独立的网络:存储区域网络(Storage Area NetworkSAN)。

 (摘自,张冬瓜,大话存储2)。

 

3)、存储的规划方案

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

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

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

存储名称

RAID方案

物理容量

可用容量

LUN划分

数据库存储

RAID5+热备盘1

12*3TB

10*3TB

3*20G+55*500G

备份存储

RAID5+热备盘1

6*3TB

4*3TB

2*5119G

数据库服务器

RAID5

6*1TB

5*1TB

4T+1T

看一眼实物图:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

传统的数据库部署:

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

网络层:带宽不足

服务器层:过多数据处理

  

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

1、加宽通道

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

3、增加系统并行处理

 

理念化:

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

存储层:智能化、预处理

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

 

2)、解决了资源独立,无法共享的问题?

传统数据库:

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

 

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

 

解决:

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

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

 

3)、解决复杂的数据库系统均衡化配置?

传统数据库:

大型的存储系统,EMC存储;

分区;

设备昂贵;

技术维护管理;

总的代价开销非常大;

 

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

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

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

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

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

 

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

一体机:

简化部署:消除复杂部署;

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

 

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

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

 

 

*******************************************蓝的成长记系列_20150820*************************************

原创作品,出自 “深蓝的blog” 博客,欢迎转载,转载时请务必注明出处(http://blog.csdn.net/huangyanlong)。

蓝的成长记——追逐DBA(1):奔波于路上,挺进山东

蓝的成长记——追逐DBA(2):安装!安装!久违的记忆,引起我对DBA的重新认知

蓝的成长记——追逐DBA(3):古董上操作,数据导入导出成了问题

蓝的成长记——追逐DBA(4):追忆少年情愁,再探oracle安装(Linux下10g、11g)

蓝的成长记——追逐DBA(5):不谈技术谈业务,恼人的应用系统

蓝的成长记——追逐DBA(6):做事与做人:小技术,大为人

蓝的成长记——追逐DBA(7):基础命令,地基之石

蓝的成长记——追逐DBA(8):重拾SP报告,回忆oracle的STATSPACK实验

蓝的成长记——追逐DBA(9):国庆渐去,追逐DBA,新规划,新启程

蓝的成长记——追逐DBA(10):飞刀防身,熟络而非专长:摆弄中间件Websphere

蓝的成长记——追逐DBA(11):回家后的安逸,晕晕乎乎醒了过来

蓝的成长记——追逐DBA(12):七天七收获的SQL

蓝的成长记——追逐DBA(13):协调硬件厂商,六个故事:所见所感的“服务器、存储、交换机......”

蓝的成长记——追逐DBA(14):难忘的“云”端,起步的hadoop部署

蓝的成长记——追逐DBA(15):以为FTP很“简单”,谁成想一波三折

蓝的成长记——追逐DBA(16):DBA也喝酒,被捭阖了

蓝的成长记——追逐DBA(17):是分享,还是消费,在后IOE时代学会成长

蓝的成长记——追逐DBA(18):小机上WAS集群故障,由一次更换IP引起

蓝的成长记——追逐DBA(19):路上的插曲:触碰“框架”与“软件系统”

******************************************************************************************************************

 

  

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

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

展开阅读全文

没有更多推荐了,返回首页