first commit

meeting.md

@@ -0,0 +1,159 @@
+
+## 天翼看家（省内版）推进例会纪要 
+
+2020年9月3日下午在武林电信大楼1407会议室，市场部、网运部、网发部、公客部、研发分公司就天翼看家（省内版）业务运行方面的网络、资源等方面的问题的展开讨论，纪要如下：
+1、中心节点双活：目前中心节点在绍兴单节点运行，为保障业务稳定运行，需在金华节点提供中心节点资源部署，实现绍兴和金华双节点存活。（责任部门：NOC、网发、研发分公司）
+2、网络保障：目前存在SDN网络流表策略导致交换机资源占尽的问题，需加强该类问题的监控和预警手段。（NOC、研发分公司）
+3、资源保障：为提前进行资源部署，研发分公司需每周定期提供业务发展量和资源使用情况，公客部提供业务发展规划，网发根据发展情况和规划进行资源部署。同时，NOC需提升对资源的实施监控手段，研发分公司需提升应对故障的快速处理手段。（网发、NOC、研发分公司、公客部）
+
+参会人员：市场部（韩靓）、网发部（吕鹏）、网运部（骆溢洪和孙仁杰）、公客部（袁江、陈桓、王利琴）、研发分公司（邹洪亮、陈赣、武俊英、商宏文）。
+
+请xx牵头定位并解决近期存在的流表策略导致丢包问题、服务器宕机等问题
+目前杭州、金华边缘节点因链路未调通，业务承载在其他节点，需xx推进尽快解决
+请网发评估推进存储方式的S3转换，集成公司和研发分公司配合确保测试和切换过程中业务稳定
+
+## 台州来访会议（江文新）
+
+1. 中置分平台
+    - 分层分级分类管理
+    - 经纬度
+2. 稳定性
+3. 客户端
+
+## 集成公司会议(20200925)
+
+1. 近期问题, 故障接应处理，如何提升资源的稳定性
+  - 丢包问题，ping，队列调整4似乎解决了，但这个问题的机制不够清晰，2C8G测试
+  - NFS问题偶发读写失败，衢州，频度一次/周
+  - 集成公司处理后，部分NFS自动挂载，部分需要手动干预才能挂载
+  - 杭州NFS - S3测试情况
+  - 网络可能问题的支撑
+
+2. 资源部署、发放加速，目前一般一周左右
+  - 部署自动化
+
+3. 监控手段完善，如何做到双向监控
+  - NFS -> S3监控
+  - 监控手段开放，云管
+  - 巡检
+  - 培训赋能
+
+4. 其他
+
+业务
+
+
+问题梳理&解决思路
+1. 门限设置
+2. S3和NFS分别部署
+   杭州
+
+   多网关的支持
+
+S3:
+   稳定
+   并发
+   1w/sec
+
+   基准测试
+
+版本升级
+
+升级灰度
+
+本地化团队
+业务测共享机制
+
+双池Pool模式AB池模式HA
+
+修复的判断依据，什么时间触发修复
+
+故障:
+   9月10日，9月13日
+
+wangzheng
+yangjingwei
+liuhonglei
+judacheng
+gongyucheng
+
+文件锁
+NFS内核态，IO
+容器化
+事件型 -> S3
+
+云管 - 智能网管对接 ，同步与自动化运维对接
+Agent推送给云管
+
+单卷<20T
+底层XFS
+
+ext4
+16TB分割提需求
+
+不断进行读写，读15%，写85%，再确认？
+极限测试&基准测试
+
+读写S3写入流程
+TTL删除，由业务方确定
+
+S3网关的承载能力
+S3网关支持多网关访问同一个bucket，建议客户端异常处理，实现多网关高可用HA
+
+bucket存放的数据量？
+10万对象 每个10M  4000000/11M
+400000
+
+本地化团队
+
+------------------------------
+1 关于资源的稳定性
+     对前期问题做了探讨，接下需要重点要对性能基准有个了解，双方协助做一个基准测试
+     建议后续采用AB多Pool的问题，需要与网发同步
+     NFS资源的修复，修复的依据和触发条件是什么
+     集成公司对资源做定期巡检，把弱存储摘除掉
+2 关于升级这块，底层资源版本升级能够提前同步，后续升级提供升级方案，便于评估影响
+3 集成公司建议后续采用ext4, 并且存储按照16TB划分，后续资源申请按这个分割提需求
+4 云网监控的计划和落地方案，尽早实现业务和资源双向监控
+5 S3深入探讨，杭州S3建设就绪，后续开展性能极限和基准测试
+6 安全生产问题
+7 本地化支撑团队
+
+补充：
+- 业务升级可以同步给集成公司
+- 定时清理，集中IO操作能告知集成公司
+- 工作群
+
+NFS - S3 如何切换
+
+事件型切换过去
+
+## 关于浙江电信天翼看家业务分布式存储项目协调沟通会
+
+2020年9月25日，浙江电信研发分公司、浙江电信网运部和集成公司人员组织召开浙江电信天翼看家业务分布式存储项目协调会。会议首先由集成公司对天翼看家云资源池存储项目问题进行了梳理和分析。随后参会各方从提升项目问题发现的效率的监控措施优化、业务存储使用改善建议、加强本地化服务团队及体系建设、建立与业务侧信息共享机制等几个方面进行了深入探讨，并形成了以下共识：
+1. 提高云资源池的稳定性，**集成公司定期及时进行资源巡检，提前发现问题，摘除弱存储**。集成公司建议全天型业务仍保留在NFS存储池内，事件型业务及NAS业务切换到对象存储。为保障对象存储交付后的可靠性与性能，建议双方协同展开对象存储的性能基准测试和极限测试，集成公司在9月30日前提供测试方案初稿，由研发分公司与NOC审核，三方共同完善，并确定后续的测试计划和测试地点；
+2. 集成公司进一步完善监控指标体系，并通过与业务侧沟通，了解业务场景特点，逐步优化阈值告警的配置参数，**并在云管监控接口具备对接条件后，与研发中心自动化运维系统进行对接**，逐步建立双向的监控数据互通机制和渠道；
+3. 对于近期文件系统故障所采取的修复措施，向研发分公司及NOC提供原理说明和操作步骤说明，并按照操作申请严格按时、按步骤执行。并对24日重启OSD操作引发的NFS无响应问题，建议**在开展重要修复前能够与业务方协商确定时间，便于提前保障**，在无正式业务加载的节点，双方配合，丰富日志采集信息或降低日志打印级别，共同分析原因；
+4. 研发分公司提议，在每个地市建立AB池架构，提供容灾；
+5. 为解决Ceph已发现的问题，提高系统整体稳定性，存储软件需要升级版本，考虑到本次版本跳跃较大，且需对操作系统内核同步升级，经集成公司产品开发团队评估后，建议采用冷升级方式，9月30日前研发分公司与集成公司组织冷升级专题讨论，在10月10日前，由集成公司提供冷升级方案初稿，由研发分公司审核，确定升级计划并执行；
+6. 根据本次文件系统损坏的故障分析结果及业务特点，建议后续NFS场景新创建卷的文件系统类型由XFS调整为Ext4，规范单卷大小为16TB，以提高文件系统的数据安全性和性能，**后续研发中心在发起资源需求时，以16TB为单元提交申请。**
+7. NOC强调了运维支撑人员需要认真学习网络安全与信息安全管理要求及相关办法，日常维护操作必须经过审核，严格按照安全生产要求进行，并确保每一位运维支撑人员通过4A认证，一人一账号，登录生产环境执行运维操作；
+8. 加强业务侧与云基础设施侧的沟通与协同，双方在进行系统变更操作时，提前通知具体操作时间，影响等情况，并对资源池使用情况，系统运行情况等形成协同周报机制，为提高沟通效率，建立由研发分公司、省网发、省网运、省NOC、系统集成公司组成的专项虚拟团队，及时沟通，监督工作计划执行。
+
+------------------------------
+
+2020/11/12 邹总
+------------------------------
+
+1. opentsdb + granfana
+2. 天翼看家
+   - 总况
+   - 在线情况详情 - 全局故障，分公司
+   - 事件存储详情
+   - 服务状况详情
+   - 边缘节点
+
+负载均衡调度
+资源利用情况，提前扩容
+
+