半自动化运维之服务器信息维护(r6笔记第17天)

在很多的时候,随着工作的持续开展,可能会接手更多的服务器资源,这个时候我们手里就不但是一两台服务器那么简单,可能几十个,上百个,甚至上千个,这个时候服务器信息的维护就变得额外重要,抛开业务线的规划,对于DBA来说,掌握服务器的信息,做到知根知底,才能在问题发生的时候合理处理问题。 服务器信息可以分成几个方面来看,比如操作系统情况,内核版本,硬盘,内存,空间使用情况,累计运行时间,数据库实例运行时间,系统中的swap争用情况等等,尽可能根据实际的情况进行一些维度的划分和细粒度的归纳。 比如说在生产中,考虑容灾,会有一主一备,甚至一主多备,这个时候,我们也需要考虑主备环境中的硬件资源的情况,资源使用情况。 举几个例子。 比如我们手头有两台服务器,是作为异地容灾的,我们通过简单的解析得到了两台服务器的初步信息。 服务器一:RHEL 6,空间使用近70G,120G内存,24CPU,服务器已启动590多天,数据库实例启动自2013年, 服务器二:RHEL 4,空间分配达3.1T,使用率达2.5T,40G内存24CPU,服务器已启动280多天,数据库实例启动自2014年,swap争用较高

我们来看看这两台服务器信息在特定的场景中会有哪些考虑,当然有些细节还没有罗列出来。 第一个部分就是IP信息,dataguard的场景作为异地容灾尤为重要,如果主备在同一个机房,势必会给灾备带来一些隐患,比如机房断电,这种情况下影响就会凸显出来 然后我们来看主备的系统版本,一个是redhat 6,一个是redhat 4,其实也可以搭成主备环境,但是多多少少会有一些影响,比如有些基于操作系统级的参数在不同的系统版本中可能有不同的表现。 我们再来看一看空间分配,第一台是作为主库来使用的,可以看到使用了近70G的空间,但是备库却又3T左右的空间,使用率却要高得多,这个时候就需要评估是否空间资源使用是否合理,是否有一些额外的空间消耗没有释放。 再来看看内存资源,一台服务器是120G,一台是40G,在这种情况下,势必会对sga的配置会有一定影响,对于系统中的hugepage等的设置也会有所不同,配大了可能备库不能接受,配小了又有些浪费。 还有一些信息,比如主备库的系统运行时间,可以看到主库服务器已经运行了近600天,而备库有差不多300天的样子,在这个时间范围内,可能发生了一些资源的分配最后导致了系统资源,硬件资源出现了一些差别。 最后一个要点就是在备库中存在着较高的swap现象,这个从数据库的角度来看,还是没有能够合理的利用large page或者hugepage。而在主库中就没有明显的swap争用。这个时候如果发生了灾难切换,切换到备库之后,可能在备库中就会存在一些潜在的性能问题。 再比如我们有如下的两台数据库服务器,一部分资源作为dataguard使用,另外一部分资源作为其它的辅助资源来提供,怎么理解呢,可以简单来说,一台服务器类似主库,另外一台服务器做为备库,同时根据情况还需要跑其它的业务数据库。 比如我们得到了两台服务器的资源情况如下: RHEL 5,空间分配350G,使用近170G,8G内存,服务器已启动780多天,数据库实例启动自2013年,同时有xxxxx和xxxx两个数据库实例在跑,swap争用较高 RHEL 5,空间分配234G,使用近170G,8G内存,服务器已启动近500天,数据库实例启动自2014年,同时又xxxx和xxxx,xxxx三个数据库实例在跑,swap争用较高

在这种情况我们怎么来分析呢, 这个时候我们可以看到系统版本,空间资源使用情况都差不多,系统的内存相对有些紧张,跑了好几个数据库勉强才有8G的内存空间,主库服务器上有两个数据库实例在跑,而备库中有两个备库实例在跑,另外还有一台其他业务的数据库实例,这种情况下,就可能会有一些灾难场景,我们可以了解到主库服务器已经运行了近800天,已经两年多了,而备库也有差不多1年半了。在这种情况,系统的资源使用情况比较紧俏,很可能就会出现问题。一旦出现问题,就会有问题的放大效应,比如备库出现了介质损坏,那么额外的那个数据库实例就没有办法恢复了,因为本地的空间情况剩余也只有50G左右,如果规划系统的rman备份,也没有多少空间可用,而且同时主库已经跑了2年多了,压力还是相似甚至开始加大的状态下,主库长期在这种资源紧俏的时候更容易出现问题,这个时候主库出现问题,备库的隐患还是没有解除,因为这个时候系统的压力全部都到了备库上了。如果备库压力突增,更可能出现问题。 所以这个时候与时俱进做一个前瞻的准备还是不错的,比如我们的主库资源配置较低,但是我们配备了一个高配的备库,这样就相对可以轻松很多,如果出现问题,问题处理的余地还很大,甚至我们还是希望主库能够切换到备库上来,这样出现问题之后切换系统的稳定性反而更强了。 所以说如果手头拥有大量的服务器资源,不妨还是适当规划一些,看看是否能够做一些合理的改变,在问题发生的时候更加从容一些,毕竟自动化运维是一个很大的方向,我们不能保证系统的资源都是完全一样的,可能很多时候因为各种因素,会有很大的差别,这些系统资源的权衡是自动化运维所不能完全考虑到的,所以我还是希望这是属于半自动化运维中的范畴。

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2015-08-03

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏带你撸出一手好代码

开发了一个小工具

国庆因为有事,没有像朋友圈里的同学一样出去浪。闲暇时间, 为了克服平时使用电脑时的一个坏习惯,我开发了一个小工具来帮助自己。 平时使用电脑时, 我喜欢把所有东...

3018
来自专栏何俊林

Python爬虫之如何爬取抖音小姐姐的视频

这次爬的是当下大火的APP--抖音,批量下载一个用户发布的所有视频。各位也应该知道,抖音只有移动端,官网打开除了给你个APP下载二维码啥也没有,所以相比爬PC网...

5143
来自专栏安恒信息

预警 | Windows再爆SMB服务0day漏洞 安恒信息提供一键修复工具

在刚刚结束的2017年度DEFCON大会上,安全研究人员曝光了一个潜伏在Windows系统上长达20年之久的安全漏洞。该漏洞被命名为SMBLoris,攻击者使用...

34711
来自专栏TechBox

xxx.h file not found的非主流解决方案(目测不具普遍适用性)

1893
来自专栏深度学习计算机视觉

Performance Testing as aService for Web Applications

1、成员组成 (1)组长:张俊怡 (2)组员:孟令军 2、文献基本情况介绍 (1)文献名称:Performance Testing as aService f...

3175
来自专栏杨建荣的学习笔记

数据整合式迁移的一些总结(r8笔记第38天)

说起数据迁移,感觉也算是有些感受了,但是最近参与的几个迁移案例还是和以前大大不同,以前的迁移项目是比拼停机维护时间,尽可能在短时间诶导入大批量的 数据,有参与表...

3255
来自专栏IMWeb前端团队

Nginx能为前端开发带来什么?

本文作者:IMWeb 黎腾 原文出处:IMWeb社区 未经同意,禁止转载 Nginx那么好,我想去看看。 接连逛了两个书城后,我发现并没有Nginx相...

2525
来自专栏IT技术精选文摘

Paxos协议学习小结

一直对Paxos协议比较感兴趣,之前对这个算法 有耳闻 但只是了解皮毛,最近在学Zookeeper,趁着这股新鲜劲,就花时间研究了下Zookeeper的选举算法...

29710
来自专栏雨过天晴

原 荐 收集微信跳一跳的辅助

1882
来自专栏Ksher

Kubernetes服务网格(第10部分):服务网格API

翻译人:Ksher,该成员来自云+社区翻译社

20610

扫码关注云+社区

领取腾讯云代金券