标签：副本 直接 特殊 ops 服务器管理 中间 ruby 电信 企业版
这是之前规划设计的IT基础架构运维规划方案，总结自己一段时间的运维经验
相关敏感信息已经去除
学无止境啊
从2016年10月XX的运维工作到现在已经有两年多了，期间进行了很多调整，部署了很多业务系统，从一开始的混乱无序，到现在算是小有成效了。现在我们需要进一步完善现有运维工作，规划完整的架构，方便日后进行调整，保证能够科学而又高效的完成运维工作，提高客户满意度。
整体架自下而上分为两个部分，基础环境和上层业务应用。
基础环境主要是提供的基础虚拟机化环境和存储支持，同时包括各种网络基础环境。
上层应用由客户业务、运维支撑和第三方业务系统构成，主要是基于虚拟机的应用软件和解决方案。
广电的基础环境主要构建是基于kvm虚拟化解决方案的超融合nutanix环境和基于vmware的vsphere虚拟化解决方案环境组成，两者为不同的异构的虚拟化，中间底层网络全部连通，相互共享网络资源和存储资源，为整体的架构提供一个虚拟化层从而支撑上层其他业务系统。值得说明的是，目前我们无法两种不同的虚拟化环境进行统一管理和调度，虽然他们都可以提供完整的虚拟机生命周期管理。
Nutanix的虚拟化环境组网如下所示：
这是一个稳定的组网架构，从2017年3月部署后，基本没有变更过，运行可靠，可用性高，性能强悍，主要的上层业务都是运行在其中，并且推荐这样做，因为它是我们唯一通过商业途径获取的商业化解决方案。
对于该环境，并无太多需要调整和规划，但是是基于kvm，运维简单，但是一旦故障，需要联系原厂技术支持解决。
以下为建议和需要规避的问题：
1、计算网络存储融合，无法直接通过第三方存储来扩容，只能另购同样的机器来进行横向扩展
2、不建议将nutanix的存储能力提供给其他平台或系统
3、若要将其他虚拟化平台虚拟机迁移到nutanix，需要原厂软件和技术支持，风险较高，不建议直接迁移，若有需要，可以考虑重搭建虚拟机
4、kvm对linux系统天生支持较好，windows系统会有bug，如蓝屏io驱动错误等，推荐nutanix部署linux操作系统的虚拟机
5、kvm无法模拟非x86架构的操作系统，定制化的虚拟机，如路由器，交换机，防火墙等操作系统，不能在nutanix上运行
6、Nutanix 上无法导出虚拟机，虚拟机备份容灾极度依赖快照功能，重要业务虚拟机需要开启数据保护
7、Nutanix 上可以直接对处于运行状态的虚拟机进行删除动作，极度危险，一旦删除，不通过技术支持无法恢复，需要加强操作管理
vsphere的虚拟化化境采用客户老旧的x86服务器实现服务器虚拟化和使用兼容服务器搭建的开源存储功能构建的。最早使用vps-here 5.5，在2017年7月完成升级到 vsphere6.5，采用注册机破解许可。
整体组网架构比较复杂，可靠性很低，提供的虚拟机的能力极度依赖共享存储，性能不高，非常容易故障。基本上只有一些测试业务在上面运行，整理利用率较低。
vsphere的组网架构如下：
架构简单说明：
1、所谓前端交换机提供vps-here管理和虚拟机业务网络
2、所谓后端交换机提供存储网络管理和存储
3、两台存储都是以NFS 协议的 NAS方式提供存储能力，目前两台存储分别是使用不同的开源解决方案，两者无法关联
4、为了提升后端存储网络带宽，后端网络上特地使用了链路聚合技术
使用vsphere的虚拟化环境，有着以下优势：
1、全虚拟化，可以模拟任何x86和一般的硬件，成熟稳定
2、商业化组件很多，满足全套解决方案所需要的各种特性，可扩展性好
3、运维管理功能健全
虽然vsphere有着很多优点，但是在我们目前的环境中，主要因为物理服务器的不稳定和性能低下，造成很多问题：
1、故障率高
2、轻微调整则会影响整体稳定
3、特别是存储，因为搭建存储的物理服务器故障，导致整体平台已经出现了多次异常
4、无有效的存储备份手段，也无法对虚拟机进行容灾管理
根据以上理由，对于vsphere的虚拟化环境使用有着如下建议：
1、尽可能的使用全新的物理服务器代替老旧的服务器
2、尽可能的使用商业存储服务器，推荐使用存储备份一体机
3、若无条件更换商业存储， 可以使用两台开源freenas实现存储备份
4、在完成vsphere环境硬件调整之前，最好不要将生产业务虚拟机放在上运行
目前我们的上层业务应用，主要是基于虚拟机的提供服务器资源，然后由服务器搭建的各种业务系统。主要根据各个功能划分，分为客户业务、运维支撑和第三方业务系统。
客户的业务虚拟机包括上线交付的业务系统和相关关联的其他虚拟机，如OA系统，性能监控，专线监控等。
运维支撑，是我方运维人员搭建的各种运维工具软件等，支持各项运维管理工作。
第三方业务系统，指客户要求其他业务部署，非本公司产品，需要利用现有虚拟化环境的，如XX通，动环监控服务器。
相关建议：
1、客户业务需要保持稳定，这也是运维工作的重点
2、第三方业务非客户提出，不要干预
3、运维支撑的应用，是重中之重，需要运维人员重点关注
关于运维支持应用，会在后面重点阐明
有很多虚拟机是处于测试目的的而使用的，有一些虚拟机是处于异常或者停止使用状态的，这些虚拟机的使用会消耗资源，所以对这些虚拟机需要进行清理。关于虚拟机的统计，见附件《虚拟机统计20190121》，这里只是提出需要清理的虚拟机。
需要清理删除的虚拟机如下表所示：
（略）
为了方便和明确运维工作内容，需要明确运维工作内容，指导运维人员工作。
关于XX运维工作的内容，如下所示：
详细运维工作见文件《XX运维工作梳理》
关于运维人员，技能要求不光需要懂网络，同时需要熟悉虚拟机存储操作系统和监控，技能要求较高。
对于运维工作内容有者如下要求：
1、每个工作内容都需要有对应的文档，包括操作，记录等等
2、对于日常解决的故障内容需要记录
3、重大操作需要通知客户
运维工作极度依赖制度，和运维人员的职业操守。
在上层业务应用重，运维支撑是运维技术人员重点需要关注的，对于运维工具的理解和使用，可以极大的提升效率，同时可以及时响应故障，解决问题。
首先，在功能上，将XX的各个上层应用区分为基础环境、生产环境、测试环境三个类别。
基础环境：构建运维架构中实现基础功能的虚拟机与应用，包括为提供时间同步的NTP服务器，提供yum加速安装的yum仓库服务，收集日志的日志服务器等。
生产环境：提供给客户业务的虚拟机上层应用，包括专线监控平台，zabbix监控等。
测试环境：运维人员进行测试使用的虚拟机，主要目的是测试各种开源工具运用等，一旦测试结果为有用，可以转化为运维工作管理的重要工具。
在整体运维支撑架构中，最核心底层的主要是由运维管理平台opsmange支持，它实现CMDB资产配置管理，自动化运维等，方便运维人员对整体进行快速调整，快速部署。
jumperserver堡垒机，主要实现运维工作的整体入口，运维人员通过堡垒机能够进行登陆各个虚拟机，做到集中登陆和审计。
opsmangege运维管理平台是完全的开源软件，简单易用，比较与其他商业软件，更加适合XX运维工作。
登陆地址：
管理员账号：
密码：
主要功能模块如下图所示：
详细的操作见公司wiki：
对于我们而言，目前侧重的资产管理和自动化运维
资产管理
任务管理
批量脚本运行模块
说明：
1、该平台可以批量对linux主机进行配置管理，无法对windows主机进行批量管理
2、很多功能可以挖掘使用
3、开源版本目前没有完善的操作手册
地址：
管理员:
密码：
该日志平台只做收集交换机等网络设备日志，不能收集系统日志，
如若有更好的商业日志收集软件，则可以选择替代
目前，所有的专线业务，包括XX各个网络的华为系列的交换机，都配置了radius认证，所有登陆账号都会被集中授权和管理。
地址：
账号：
密码：
设备记录
认证记录
目前radius 认证服务器采用破解版部署，稳定性一般，需要注意，所有的网络设备交换机配置3A认证时，优先采用本地认证，其次才是radius认证，即使没有radius认证服务器，所有的网络设备也可以正常登陆使用，推荐日后采用专业的商业radius服务器解决方案，来满足等级保护要求。
graylog 是一个用来将系统日志syslog保存到MongoDB中的工具。 包括一个用Java编写的服务器，可接收来自TCP和UDP的syslog信息，Web接口使用Ruby编写，基于?Rails?框架，可用来查看日志信息。
Wiki 地址：
地址：
管理员：
密码：
日志收集效果
可以简单使用，但是高级功能和可视化，告警等功能需要研究一段时间
Racktables?是一个用来管理机房资产的开源工具，可以用来管理成百上千台的服务器及更多的?IP?和?MAC?地址。适用于机房和数据中心的服务器管理。
公司wiki地址：
地址：
管理员：
密码：
主要功能截图如下：
此套开源软件，使用最为简单，同时操作手册也最为详尽。
堡垒机作为运维人员登陆入口，提供集中登陆和集中日志审计功能。
地址：
管理账号：
密码：
推荐运维人员主要通过堡垒机对单个运维主机进行登陆管理。
生产环境，就是对面对客户的重要业务，由研发主导交付，运维人员需要持续关注，保证环境稳定。
目前XX业务系统，包括已经交付使用的资源管理门户（OA),传输网性能监控平台，和处于试用阶段的文档管理平台和流程管理平台，前两者运行在nutanix平台之中，后两者运行在vsphere平台之中。
关于XX业务系统，公司wiki上有详细的操作指南。每个业务系统都是部署在windows操作系统之上，web服务器使用tomcat +jdk，数据库使用mysql,开发语言使用php和java，运维人员需要对这些方面有所了解。
平常运维时需要关注状态，接受故障处理反馈。
平常故障主要集中在几点：
1、tomcat服务启动失败
2、mysql服务启动失败
3、虚拟机存储空间不够
4、网络问题导致客户不能访问业务
5、windows操作系统异常需要排查
四台业务服务器，都采用数据库备份的计划任务，保证数据级别备份；
备份的数据库集中保存在共享NFS文件目录中；
依靠nutanix数据保护功能进行虚拟机级别的备份容灾
依靠nutanix的副本机制，实现主机存储级别的备份容灾。
针对重要业务的虚拟机和数据的备份容灾，大致如下图所示：
说明：
1、除了传输网性能监控平台采用第三方数据库备份之外，其他的业务虚拟机数据库备份采用mydump 脚本形式，采用计划任务形式，自动执行
2、除了传输网性能监控平台将数据库导出备份到虚拟机本地磁盘之外，其他业务虚拟机都是讲数据库导出备份到NFS共享目录服务器。
3、在nutanix平台上，开启数据保护，对重要业务虚拟机进行每月一次的定时快照备份
4、在nutanix平台上，开启副本机制，平台上的所有的虚拟机都会都会三副本的机制保存在三个节点上，实现存储级别的容灾
Vsphere 平台上没有使用任何虚拟机保护机制
针对vsphere的平台，实现容灾备份建议如下：
1、使用存储的复制技术，实现容灾备份
2、部署vpshere data protection 组件实现虚拟机级别的备份容灾
3、如有条件，更换商业版本的备份存储一体机，实现整体存储级别的备份容灾。
目前XXxxx主要是作为接入xxx使用，满足客户和运维人员远程接入光XX内网环境进行办公和调试需求。xxx服务器采用开源的SSL xxx的OPENxxx解决方案，使用二层隧道模式接入XX内网环境。登陆上采用域名解析实现多xxx服务器分配保证可靠性，规划大致下所示：
说明：
1、XX一共拥有四台xxx服务器，vpshere上两台，nutanix平台上两台，互为冷备关系
2、主域名xxx.xxx.xxx,备域名xxx.xxx.xxx,使用阿里云的域名解析服务
3、使用域名+端口号区分主用xxx和备用xxx环境，如客户使用xxx.xxx.xxx:xxx登陆主用xxx服务器，而使用xxx.xxx.xxx:xxxx登陆备用xxx服务器。
4、阿里云DNS服务，会跟根据用户的实际网络运营商环境，将域名解析为XX不同的公网地址，如用户使用电信网络登陆xxx，DNS解析为xxx.xxx.xxx.xx，如果用户使用联通的网络登陆xxx，DNS解析为xxx.xxx.xxx.xxx
5、公网地址xx.xx.xx.xx是由XX集团平台公司cdn网络提供，因为核心网络对接关系，处于联通运营商网络的用户，无法正常访问，此时需要访问备用公网地址，所以此时需要阿里云DNS系统来进行智能区分
6、每个平台上的xxx服务器使用冷备，一旦主要xxx服务器不能及时恢复，可以切换到冷备服务器上，保证用户的使用。
对于运维人员来说，除了需要关注xxx服务器的状态，账号登陆情况，还需要检测域名情况，一旦域名解析故障，失效，会导致xxx服务器的访问异常。
因为XX内网环境的特殊性，所以无法直接部署内网域名服务器，重要业务无法使用域名直接访问，所以采用阿里云域名解析+NGINX域名转发+keepalived高可用实现。
1、在阿里云DNS解析上做好了域名解析绑定，如xxx.xxx.xxx.xx，全部解析到xxx.xxx.xx.xx
2、两台nginx使用keepalived使用类似vrrp协议的方式实现高可用，对外提供vip
3、两台nginx实现双机热备的高可用，配置一样，实现域名转发到指定内网服务器。
域名转发已经是实际上客户访问业务的重要手段，它能够解决XX内网无域名解析服务器的问题，同时可以做到保证用户使用域名方式业务
运维人员需要重点关注，按照以下几点进行运维
1、保证阿里云DNS解析服务能够正常
2、保证nginx服务以及域名转发配置正常
3、保证keepalived服务器进程正常，不能处于脑裂状态
4、保证防火墙策略正常，vlan101网段可以访问vlan102网段，保证nginx网络上转发正常。
目前XX环境下，有很多跳板机，除了作为内网接入跳板提供给客户和运维人员使用之外，还作为一条屏障，阻隔外部网络病毒影响和***行为，主要是依靠360安全卫士进行。
运维人员，需要关注360安全服务器，保证能够稳定正常。
运维工作中，有很多情况，是需要进行设置告警的，在出现问题之后，能够及时知晓并进行处理。
运维人员需要及时配置相应系统的告警配置，包括nutanix平台，vsphere平台和基础环境。
标签：副本 直接 特殊 ops 服务器管理 中间 ruby 电信 企业版
原文地址：https://blog.51cto.com/11555417/2468288
