运维平台的建设思考-元数据管理(r7笔记第57天)

之前也写过一篇比较基本的文章,也算是自己对运维平台的一个基本思考。运维平台的建设思考(r6笔记第20天) 当然想法简单,而且缺乏实践,但是朝着这个方向迈进是没有错的。从我的观点来看,现在能够实现半自动化运维已经很了不得了。而且把这些工作能够落到实处,更是不易 。 比如举几个简单的例子。 比如对于数据库的数据文件添加这个功能来说,其实完全可以实现自动化扩容。但是是否完全可行呢,我觉得还有待斟酌。比如temp设置为自动增长,如果出现 了sql语句导致的问题,结果导致temp被撑爆,听说过temp无限扩展达到TB级的问题,最后还是sql语句的问题导致。 那么这个数据文件是否支持扩展,怎么扩展,这个应该一方面是根据系统资源进行权衡,另一方面就得根据具体的系统情况来决定了。这也就引申出我今天想说的关于元数据的管理。 顺便讲个小段子,几个同事跑过来找我,说有一个紧急操作需要DBA配合,然后想让我去和他们开个会,我就不喜欢那种没有结果的会议讨论,从DBA的角度来 说,提供完整的操作步骤,正确的脚本,你们来评估业务可行性,我们来评估从安全,性能,业务上是否需要支持和改进,当然我说的也很简单,我就是个干活的, 你来提供详细的步骤和参考,我来评估和执行,会我还是不参加了吧。其实话说回来,如果我们只是简单评估和执行,那么我们工作的含金量会大大降低,外企都很 强调的design,DBA也是需要加强这方面的功底的。老是搬砖,时间长了就只会搬砖了。 所以这些design的工作怎么做,不是一下子高屋建瓴,我们来想想我们能够做些什么。从整个运维系统,运维平台的角度来考虑,元数据管理还是根本,但是似乎没有什么人重视。 从我的角度来讲,我认为元数据的管理,除了资产层面的资源状态管理,从运维平台来说,还是有很多值得注意的地方。 我大体列举了一部分,从我的角度来看认为还是非常有必要去考虑的。

这些元数据看起来非常琐 碎,但是一旦管理起来,作用就非常巨大了。比如给你最短的时间做资源盘点,查看当前的5000台服务器中哪些服务器是在redhat的某个子版本,简单评 估是否可以升级等等。这些没有元数据管理,简直不可想象。所以我把元数据的考虑划分成了下面的几个部分,当然还需要不断完善。 系统情况,内核版本,补丁,操作系统版本。 硬件配置:基本的硬件配置情况

cpu cpu合数,物理CPU数

内存 内存大小

swap分区设置:swap分区的设置,swap的大小是否合理,如果是在有些云服务器中,默认是不开启swap的。

磁盘分区设置:磁盘分区的情况,盘数,raid级别等

crontab: 自动任务的情况,是否有ntp的自动同步,是否有定时的业务调度,是否有定时的备份和系统检查。

防火墙:防火墙开设的端口,开放的客户端

主机名:服务器的主机名管理,尤其是在很多系统迁移中,做了大量的主从切换等情况下,有时候从主机名根本分不出来一台服务器到底是主库还是备库。

ip配置 内网外网,网络ip的设置,/etc/hosts中的配置,比如在mysql中的主机名dns权限解析。如果主从切换之后,是否备库一定会有主库所拥有的权限。

主备,主从关系配置:主从切换之后,是否从库或者备库一定能够胜任,备库是否已经完全做好了时刻切换的准备。根据主库是否能够找到匹配的备库,或者根据备库关联到主库。

内核参数配置,内核参数的设置,是否初始化的时候 已经合理规划还是根据感觉想到哪里做到哪里。有些内核参数设定是否是按照系统硬件资源来设定,是否考虑周全。之前就碰到过一个数据库进程数设置为150, 但是资源配置非常好,但是自己申请调高process之后重启数据库的时候,发现原来的内核参数就取的默认值,所以资源好,但是软件层面的性能跑不上去。

端口配置:对于数据库来说,开放了哪些端口,哪些端口处于闲置状态

数据库参数 init.ora my.cnf,对于oracle,mysql而言,参数的管理也很有必要,如果一台服务器宕机,想找到之前的一些完整配置,不一定备库的就和主库一样,到 底哪里不同,哪些参数可能设置不和规范,通过统一的参数管理就可以得到一些答案,比如对于oltp,olap来说,哪些参数需要考虑,10g,11g中的 特性参数如何取舍,哪些需要统一。

外部文件挂载,系统中是否有外部的挂载点,比如nfs,其它共享存储等。

备份情况,系统的备份情况,数据的备份情况等等。

当然从数据库的层面进行更多的思考,需要做到具体的事情就更多了,我们后续再做补充。 最后说一句,圣诞快乐,其实提这个节日的人多,过节的少,该加班加班,干睡觉睡觉,生活快快乐乐,天天都是节日:)

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

原文发表时间:2015-12-24

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏北京马哥教育

微服务化的十个设计要点

在实施微服务的过程中,不免要面临服务的聚合与拆分,当后端服务的拆分相对比较频繁的时候,作为手机 App 来讲,往往需要一个统一的入口,将不同的请求路由到不同的服...

1042
来自专栏WeTest质量开放平台团队的专栏

浅谈服务器性能测试的全生命周期——从测试、结果分析到优化策略

服务器性能测试是一项非常重要而且必要的工作,本文是作者Micheal在对服务器进行性能测试的过程中不断摸索出来的一些实用策略,通过定位问题,分析原因以及解决问题...

1883
来自专栏社区的朋友们

浅聊 API 网关

在微服务概念流行之前,API 网关的就已经诞生了,如银行、证劵等领域常见的前置机系统,解决访问认证、报文转换、访问统计等;而我今天的切入点是从 API-cent...

1.4K2
来自专栏小白课代表

集中式播放,给你更好的听歌体验。

随着音乐正版化的推进,想要在单一的平台听到想听的所有歌曲越来越困难,正版化是好事,但对用户来说,却绝对算不上是方便。虾米音乐、QQ音乐、网易云音乐、豆瓣音乐等等...

882
来自专栏搜云库

分布式和集群区别?什么是云计算平台?分布式的应用场景?

分布式是指将一个业务拆分不同的子业务,分布在不同的机器上执行,集群是指多台服务器集中在一起,实现同一业务,可以视为一台计算机,一个云计算平台,就是通过一套软件系...

85610
来自专栏JAVA高级架构

多研究些架构,少谈些框架(3)-- 微服务和事件驱动

接上篇,我们采用了领域驱动的开发方式,使用了充血模型,享受了他的好处,但是也不得不面对他带来的弊端。这个弊端在分布式的微服务架构下面又被放大。 事务一致性 事务...

3434
来自专栏CSDN技术头条

Autodesk基于Mesos的通用事件系统架构

【编者按】本文由Autodesk Cloud软件架构师Olivier Paugam撰写,解释了如何集合Mesos、Kafka、RabbitMQ、Akka、Spl...

2115
来自专栏calvin

我的devops实践经验分享一二

随着系统越来越大,开发人员、站点、服务器越来越多,微服务化推进,......等等原因,实现自动化的devops越来越有必要。 当然,真实的原因是,在团队组建之...

1915
来自专栏Java架构师学习

深入理解大型网站架构的核心——了解性能

1503
来自专栏谈补锅

iOS10之Expected App Behaviors

  昨天上架到appStore的时候碰到个问题,构建好后上传到itunesconnect的的包都用不了,

983

扫码关注云+社区