hdfs优化

• Z时代
• 2024-01-10
• 分类：技术分享

思考：

1. 现目前的架构是什么？业务逻辑？
   

   ​ 研发一台，测试&生产共用一套k8s集群。
   

   ​ 目前前端已经迁移到k8s，生产后端暂时没有上k8s。

2. 造成目前架构的原因是什么？
   

   ​ 历史遗留原因 造成架构不合理

3. 那些地方不合理，为什么？
   

   （1）.使用经典公网模式，会自动分配局域网ip地址 ， nginx-ingress-controller lb没有固定
   

   （2）.使用名称空间做测试和生产环境的隔离，安全几乎无保障
   

   （3）.线上只有一套环境而且是生产&测试两用，对于运维来讲等于没有测试环境(因为大多数系统应用具备全域穿透)
   

   （4）.研发代码可以直接通过gitlab上生产，却不具备回滚功能，一旦出现未知bug(之前没有检测到的)，恢复不能做到快速简捷
   

   （5）.集群架构和业务逻辑图没有做到实时更新，现有架构图不能清晰展示生产&测试 应用逻辑
   

   （6）.权限不严格，目前公司内部的权限很混乱，目录结构也混乱，不能根据目录名称看出目录内容
   

   （7）. 服务器优化不够，服务器上存在大量无效内容，造成服务器的运行不是很理想
   

   （8）.服务器设备配置不合理，存在相当一部分小服务器，实用性不高

4. 要改造的架构是什么？他们的优点？
   

   ​ 对目前架构主要改造点：
   

   ​ （1）.将目前测试环境剥离出线上K8S集群
   

   ​ （2）.增配一套线上预发环境(缩小版生产环境)
   

   ​ （3）.将原集群的网络模式有经典公网改为专用网络+弹性IP
   

   ​ 优点：
   

   ​ （1）.提高生产环境的稳定性和安全性
   

   ​ （2）.使用预发环境完全模拟生产环境，提高应用上生产的靠保障性

5. 改造后能给公司带来什么？是效率更高？更安全？还是更省钱？

   改造后的集群系统，形成，测试、预发、生产三套系统，测试在线下，预发和生产在线上，应用app 经过预发环境验证后再上生产环境，安全性得到保障。将小服务器更换大服务器，既省钱又便于管理维护。

6. 改造牵涉的人有多少？需不需要动代码？

   ​ 监管协助人：XXX

   ​ 业务协助人：XXX

   ​ 实际操作人：XXX

   目前方案，确定不动代码。

考虑优化点：

统一环境名称： 研发 预发 生产

研发环境： 线下 供研发人员使用

预发环境： 线上 缩小版的生产环境，并且两者环境应尽可能一致（版本、应用等）

生产环境：线上 只有在预发环境经过验证的应用，且总结有相应操作步骤和故障演练的文档才能改动生产环境。

对生产的操作严格要求

（1）对生产的操作应提前在预发环境完成并得到验证(而不是在线下的研发环境)。

（2）对生产的操作要严格进行：公司内部通知、官网通告、预案报告

（3）对生产的操作要严格按照权限进行。生产的操作权限缩小到个别人。提高安全级别。

对集群的优化

（1）. 合理设置各目录的作用。如：

​ /data 目录放数据

/var/log/xxx 放日志

/service/scripts 目录放脚本文件

/yaml/xxx/xxx xxx是大的方向 比如日志系统(elfk) xxx是资源文件

（2）. 对集群的登陆 生产环境只能在公司办公区域内登陆，预发环境可以公网登陆 加强对集群的管理

（3）. 公司内部业务、集群(业务)拓扑图及时更新 有应用改动就更新

（4）. 加强对集群的稳定性优化 比如：对磁盘空间进行及时清理

（5）. 网络这块原：经典公网ip 新：专用网络 + 弹性IP

（6）.故障演练，每隔一段时间(半年)进行一次故障演练，可以及时有效的检验集群的健壮性

操作流程规范化

生产环境：

1. 每次改动要提前提交邮件进行确认
2. 每次改动要形成文档
3. 每次在线上的改动要记录下操作命令和重要信息
4. 线上的改动除紧急bug外，一律先在预发环境进行验证
5. 对cicd流程 进行切分，预发cicd，线上cd。
6. 对线上环境的改动要在办公区进行，且改动涉及到的所有人员都应该在现场。

响应等级

业务可用类故障等级表

故障响应时间表

架构图优化

优化点：

​ 1. 权限分明

2. 测试、预发、生产区分明

3. 可靠性、安全性比优化前更高

以上是 hdfs优化 的全部内容， 来源链接： utcz.com/a/62027.html