早期白癜风要怎么治疗 http://m.39.net/pf/a_6489068.html现在很多客户都在纠结要不要把数据库上容器云，实际上老白前阵子也发过两篇文章讨论这个问题。数据库能不能上容器云并不是一个问题，万物皆可容器化，关键是值不值得上容器云。如果你只有二三十个数据库，还有好多种业务模式，有些运维起来还挺麻烦，那么把这些数据库迁移到容器云上还不够你折腾呢。如果你有成百上千个十分类似的小型数据库，那么上容器云后获得的益处可能是远远高于云化改造的成本的。上不上容器云，除了你的数据库的数量与数据库的大小外，还取决于你的数据库运维管理的模式、企业的技术能力和企业在运维自动化上的投入。如果你的数据库运维十分粗放，技术能力也不是很高，出了问题严重依赖于外部服务商，那么还是使用传统架构更适合你的现状。如果企业的自身技术能力较强，运维管理也比较规范，运维自动化的能力也比较强，大量的数据库大多数是为微服务而创建的规模不大、负载类似的数据库，企业也愿意在数据库云上做持续的投入，那么你的企业是具备上容器云的基础的。其实，企业的数据库要想上容器云，还有一个门槛就是Operator。有些朋友读到这里就会有些疑惑？现在大多数主流数据库，甚至包括Oracle都能找到开源的Operator了，这怎么又成了一个门槛了呢？确实是这样的，目前有很多开源的Operator可供你的数据库上容器云使用，但是数据库使用Operator的目的是什么呢？数据库这种有状态的应用和无状态的应用最大的区别是其复杂性十分强。你必须拥有一个足够强大的Operator才能让你上了容器云之后，真正的获得到好处。有很多问题是你必须考虑清楚的：首先，你的数据库高可用架构如何构建才能支撑你的企业的SLA？SLA运行的可用性是4个9还是5个9，你如何实现这个服务级别协议？你可以采用目前流行的主从复制集群的方式来实现高可用，那么主从切换以及切换后的集群恢复是否能够做到高度自动化？主从复制出现异常或者复制延时超过正常范围能否自动你定位并自动修复？数据库备份采用何种策略，能否保证备份时不会因为资源不足导致业务应用受到影响，当数据库出现故障时，恢复工作是否足够的自动化？如果数据库处于亚健康状态或者性能出现一些问题，你是否有足够的手段分析出问题处在哪里？如何确保当前负载与资源是匹配的，当系统负载过高，容器资源不足的时候，我们能否准确发现，并提出预警，甚至能够自动化处置？实际上上面几个问题都对Operator提出了很高的技术要求，每个企业对数据库的运维管理模式，管理要求都是不同的，而Operator是贯彻这些运维管理目标与运维管理手段最为核心的组件。目前我们能够免费获得到的Operator往往都过于简单了，仅仅考虑到了实现数据库上容器云的基本需求。对于运维要求较高，负载较大的企业级应用需求并未提供很好的支撑。企业的数据库从传统架构向容器云演进是一个十分谨慎的工作，因此我觉得企业数据库上容器云应该从开发自己的Operator开始。如果你觉得你的企业没有能力开发自己的Operator，或者说企业连开发自己的Operator的资金都不愿意投入，那么我还是建议你放弃上容器云的想法吧。否则如果你上了容器云后，一旦遇到一些问题，那么除了你需要像传统DBA那样面对数据库本身的问题，还要面对容器云的复杂性，这对DBA来说就是灾难了。预览时标签不可点收录于话题#个上一篇下一篇