论自主IDC运维

朋友~已经从平安夜折腾到圣诞节了你们造吗?首先表述下自己—-一枚屌丝IDC管理人员,提供主机托管的那种!这篇文章主要是谈谈小客户或说初创小型公司自主IDC机房运维管理方面的事情。先来一句鄙视的话:一个差劲的前期IDC机房部署规划(亦或者说是直接完全没有规划),是后期运维成本高低的最大杀手。

之所以有此一论,看着客户从平安夜折腾到圣诞节我真的不是很过意得去。同时也希望那些有需要的人读此文章能够得到些许帮助。先介绍下背景,某公司打算在IDC机房自主部署几台设备作为公司官网的提供http web源。需求比较简单吧,当然这也是最主要的目的,或多或少还会带搭点其它用处。

部署规划是重点,需要考虑的问题特别多:

1.需求量
业务需求,开发需求,管理需求等等。这些问题都要一一满足,并且要有明显的划分界限为佳。将各个需求进行隔离的好处就是方便管理,一旦某个节点障碍了能够快速找到障碍源。
2.扩展性
扩展行,小型转到大型的过程,包括计划,实施,部署一系列的事情。这些东西都要前期规划,虽然都是说计划赶不上变化,但至少,一个良好的扩展性规划方案能帮上忙,可以节省后期更多的劳作。
3.资产管理
对于一个公司,固定资产是要有明显标识的。从安全方面考虑,个人认为比较好的就是使用独立的,公司自识的标识方法来管理设备标签信息。见过很多公司的设备都是直接上IP地址,用户信息,当然,直接标签上有系统密码的倒少见了。所以,最好就是公司自由一套用来标识设备的命名规则啦。
4.运维成本
运维成本,上面三点都属规划类,这里,就是实施以后运营的问题,这方面一般要围绕上面提到过的事情进行优化和展开,所以,还是那句话---规划很重要,作为设备技术运维来说,有相关运维文档是很必要的。也许这里说的都是比较低层次的东西。从第4点关联到本文由来也引出下面说法。

事情的大概背景上面也说了写,主要是某客户需要在现有的架构中添加一个防火墙设备。

前期架构也是挺简单:isp上联--->自有交换机--->{自有服务器等设备}(交换机是傻瓜化默认配置)
变更架构:isp上联--->自有防火墙设备--->自有交换机--->{自有服务器等设备}(交换机是傻瓜化默认配置)

从上面前后两期架构变更的情况来看本来是很简单的事情。客户的做法:直接购买防火墙叫厂商将防火墙设备带来机房。而后现场变更,我在现场看得都纠结,重要的是,还带上我一起飞到凌晨6点啊。

这里想说的,应该提前准备,自有服务器设备本来就不多,当然,即使内网地址是需要变化的,所有服务器设备不都是可以配置一个虚拟IP地址的呢,我们就利用这一点变可实现比较平滑的变更架构了。首先,运维在所有的设备上起一个虚拟IP地址网络(要配置成防火墙设备指定的网络,在原来架构中测试没有问题后便将预期配置好的防火墙设备上架就ok啦,之后再去清理残留的ip地址)

没什么水平,写不下去了~

发布者

酷特尔

你不改变,时间又能为你做些什么?

《论自主IDC运维》上有12条评论

  1. 新的一年了,首先祝酷特尔新年快乐。原来的wordpressnote域名到期了,当时找人代备案,感觉不爽,于是自己备案换了个域名,www.wpfast.net。搞了台阿里云的学生机,重新上路。

  2. 看需求,确实很简单。准备妥当的话平滑没有的话,10-20分钟内搞定,基本就是个配置重启的时间了。咋看你写得搞到凌晨6点。

      1. 我木有参加调试啊,就静静着看着他们调!卡的地方也不多,就是配置IP的时候,连特么网关也没给配上,这方面鉴于原来有默认路由,可以先给所以机器指定一个网络的特定路由条目,用route指令就可以。还有就是子网掩码也错了。导致ifdown eth0之后原来eth1的网络地址也不连通了。其实,ifdown eth0就是错误执行来的,本来要ifdown eth0:x 这样才保险,因为ifdown eth0就是把整块eth0网卡设备都down掉了。

评论已关闭。