-
Notifications
You must be signed in to change notification settings - Fork 637
运维指南
平台控制部分和用户计算机器最好不要在同一批机器上。
cube-studio通过机器label管理任务,建议cube-studio平台本身部分保留1~2台机器,不做任务计算,用户的notebook,pipeline,service使用单独的机器,因为用户任务资源使用比较多,和控制组件混部容易照成平台宕机。
1、prometheus如果存储时间过久,机器资源不足情况下,被oom,会造成重启一直oom,可以删除分布式存储中prometheus的历史数据,重启monitoring/prometheus-k8s-0 ,或者不将监控数据进行持久化
2、mysql数据做好备份,至少每天备份一次。
3、分布式存储系统,建议连接自己公司的git,代码数据git管理,每天备份个人目录下的“重要数据”目录
4、现在“服务”页面查看总体资源,再来看设置多少资源合适,如果出现pod pending,几个可能的原因 ●机器标签是否正常添加,gpu机器查看gpu插件是否正常运行 ,机器可分配资源是否能看到gpu资源 ●分布式存储在机器是否正常 ●资源是否足够,目标机器的资源现剩余多少
5、网络问题,打开juputer界面时,jupyter反应缓慢,界面会显示让清理空间,不要清理。
6、reset docker 一定要保障机器已经从k8s集群去掉,并且分布式挂载已经umount了,再执行
7、如果使用集群版本的k8s dashboard,那么会方便很多,但是有风险问题。如果使用user1版本,会使用起来没那么方便
8、aihub大模型自己下载,只商业化使用方法,不提供商业化版本大模型
9、自建k8s开启审计日志,避免事件排查
10、如果有分布式存储或者子进程未关闭,会Terminating失败,需要手动处理
11、维表不一定能正常更新到远程表,因为字段类型不一定能正常转换,不能更新的,需要人工更新
12、镜像秘钥换成自己的。gpt token换成自己的,gpt url换成自己的
13、禁用掉系统的自动更新
14、做好基础机器运维,比如磁盘满了告警。分布式存储服务的状态和数据库服务的状态,利用率频繁高的报警之类的。注意机器可能存在的定制配置更新,如机器dns,防火墙之类的,还有机器重启后基础存储服务和数据库服务,是否正常
15、如果自己做了代码二开,自己做好代码测试,和升级测试。自己根据情况来决定是否升级。代码是开放给客户的
16、新增注意事项,增加每台机器重启后的初始化脚本,避免机器复原