半自动化运维之服务器信息维护

在很多的时候，随着工作的持续开展，可能会接手更多的服务器资源，这个时候我们手里就不但是一两台服务器那么简单，可能几十个，上百个，甚至上千个，这个时候服务器信息的维护就变得额外重要，抛开业务线的规划，对于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年多了，压力还是相似甚至开始加大的状态下，主库长期在这种资源紧俏的时候更容易出现问题，这个时候主库出现问题，备库的隐患还是没有解除，因为这个时候系统的压力全部都到了备库上了。如果备库压力突增，更可能出现问题。
所以这个时候与时俱进做一个前瞻的准备还是不错的，比如我们的主库资源配置较低，但是我们配备了一个高配的备库，这样就相对可以轻松很多，如果出现问题，问题处理的余地还很大，甚至我们还是希望主库能够切换到备库上来，这样出现问题之后切换系统的稳定性反而更强了。

所以说如果手头拥有大量的服务器资源，不妨还是适当规划一些，看看是否能够做一些合理的改变，在问题发生的时候更加从容一些，毕竟自动化运维是一个很大的方向，我们不能保证系统的资源都是完全一样的，可能很多时候因为各种因素，会有很大的差别，这些系统资源的权衡是自动化运维所不能完全考虑到的，所以我还是希望这是属于半自动化运维中的范畴。

半自动化运维之服务器信息维护相关推荐

服务器维护以后只有辅助能进,通过服务器信息维护进行“半自动化”运维
原标题:通过服务器信息维护进行"半自动化"运维在很多的时候,随着工作的持续开展,可能会接手更多的服务器资源,这个时候我们手里就不只是一两台服务器那么简单,可能几十个,上百个,甚至 ...
半自动化运维之快速连接到指定环境(一)
在大量的分布式环境中,可能存在着大量的主机配置,ip配置,数据库实例配置,甚至操作系统用户,数据库用户密码也不同,这个时候如果记录在10条左右还能应付,但是如果给你几百个这样的环境,每次都需要先查找对 ...
自动化运维 python 批量监控服务器_1、python自动化运维——监测服务器状态
监测服务器状态获取系统性能信息 1.CPU信息: Linux操作系统的CPU利用的几个部分: User Time;SystemTime;Wait IO;Idle psutil.cpu_times() ...
企业级自动化运维方案设计及Saltstack、Ansible等5种工具比较分析--云平台技术栈08...
导读:之前发布了云平台技术栈(ps:点击可查看),本文主要说一下其中的服务器自动化配置! 来自:公众号talkwithtrend 1.企业运维现状与发展趋势随着企业信息化的不断发展,运维人员需要面对 ...
游戏运维的最佳实践：搜狐畅游自动化运维之旅
本文讲的是游戏运维的最佳实践:搜狐畅游自动化运维之旅[编者的话]本文作者见证了畅游游戏自动化运维平台的从无到有,通过在其中踩过的坑.解过的结,他向大家来阐述游戏运维的进阶之路.本文主要围绕畅游游戏管理 ...
自动化运维工具——ansible安装及模块介绍
ansbile 前言一.主流自动化运维工具简介 1.1 Puppet 1.2 Saltstack 1.3 Ansible 二.Ansible 运维工具原理三.Ansible安装 3.1 下载软件包 ...
常见的自动化运维工具介绍及特点、安装ansible
常见的自动化运维工具介绍及特点.安装ansible 一.什么是自动化运维? 简单来说,自动化运维就是将日常重复性工作按照事先设定好的规则,在一定时间范围内自动化运行,而不需要人为参与. 将周期性.重复 ...
Puppet 自动化运维
Puppet是目前互联网主流三大自动化运维工具(Puppet.Ansible.Saltstack)之一,puppet是一种Linux.Unix平台的集中配置管理系统,所谓配置管理系统,就是管理及其里面 ...
Ansible自动化运维_超详细
Ansible自动化运维自动化运维工具简介 Puppet 自动运维工具特点: Saltstack 自动运维工具特点: Ansible 自动运维工具特点: Ansible 运维工具原理 Ansible ...
自动化运维工具Ansible
ansible简介: ansible是新出现的自动化运维工具,基于Python开发,集合了众多运维工具(puppet.cfengine.chef.func.fabric)的优点,实现了批量系统配置.批 ...

半自动化运维之服务器信息维护

半自动化运维之服务器信息维护相关推荐

最新文章

热门文章