解决现代大数据服务部署的最佳方案: Mesosphere DC/OS
|
副标题[/!--empirenews.page--]
《解决现代大数据服务部署的最佳方案: Mesosphere DC/OS》要点： 1. 部署一个数据服务耗时耗力首先,运维人员在安装像Kafka或者Cassandra这类的数据服务时,需要掌握一些特殊的知识；即使对于大牛和专家来说,部署这类数据服务也是非常耗时间的.举个例子,最早的时候,AirBnB的运维人员用了差不多几个月的时间才部署Kafka成功.其间碰到了无数的问题,踩了无数的坑.还有一点就是,有一些没有架构好的数据服务,可能只有少数大牛知道如何正确的维护这些系统,可能你都找不到填坑的方法. 在过去的5到10年间,涌现出了很多数据存储和分析引擎.它们之中很多都是开源的.因为维护和部署这些系统相当复杂,工程师和数据专家没法很方便地去尝试这些新的数据技术和框架.这也是为什么简化部署数据服务能够大大提高开发者效率的原因. 存储和分析引擎的井喷 2. 人工运维数据服务非常容易出错运维数据服务也是主要的挑战之一；通常,运维人员需要人工地处理升级,更新,错误后回滚,健康监控,存储管理等工作.这些人工处理的工作都是非常容易出篓子的.企业通常需要化很多人力在运维上,间接导致了在其他创新领域上投入的减少. 通常运维人员需要不断的更新软件使得开发人员能够用上新的特性,修复重要的问题.同时,新的版本也通常可以降低运维的开销.软件更新通常是一个非常耗时的工作.运维人员要么人工进行更新,或者需要编写一些脚本来进行自动化更新.同时,运维人员还需要保证在上生产环境之前,更新和回滚都在测试环境下被完整的测试过. 3. 低效的基础设施利用率还有一个很大的挑战是保证数据服务能有一个很好的资源利用率.数据中心一般的平均利用率在6%到12%之间.这个数字在2006年到2012年之间基本没有什么变化.究其主要原因,是大部分公司都希望能够保证在流量顶峰时候服务的质量.
传统的静态分割,非常的低效 通过虚拟机来增加资源利用率的方法在分布式系统里面并不适用.运维人员通常创建单独的Spark,Kafka,Cassandra等集群.这样做的原因是因为这些系统是分布式系统,它们有着自己弹性伸缩逻辑,所以运维人员会在不同的集群里面运行这些系统,从而来保证没有资源上的冲突. 举个例子来说,Spark会希望拿到尽可能多的资源来完成一个任务.Kafka可能需要能够支持高吞吐量的磁盘资源.Cassandra则需要稳定的磁盘资源来存储数据.显而易见,在单独集群部署这些服务的后果就是资源的严重浪费.如果在集群层面上使得这些服务能够共享资源,这样就可以很好的提高资源利用率. 公有云是出路么? 很多公司正在往公有云(或者混合云)迁移数据服务.往公有云迁移主要有以下两个原因：
在最近的一次调查中,只有不到三分之一的公司在私有云中部署数据流水线,其他的公司都在公有云中部署. 虽然公有云在数据服务上有着明显的优势,缺点也非常明显.主要缺点是可能会被公有云提供商绑架.针对公有云服务开发的应用通常会和公有云提供的API绑定.当应用开发完成后,想要迁移基本没有可能. 最近有个很好的例子：Snapchat上市前,在它们的公开招股书中提到了一些数据.从中不难发现,Snapchat其实已经被Google公有云绑架了. 在去年5亿美金的亏损中,有80%是因为其在Google公有云上的花销.在招股书中,Snapchat宣称它们的应用非常针对Google公有云的服务,没有其他公有云提供商可以提供备选.这样导致的结果就是,除非Snapchat花很大的力气去重新构建它们的应用,否则它们永远地和Google公有云绑定了. 还有很多其他公司在盲目地往公有云里面跳,导致的被绑定的风险大大的提高.你可能会问,有没有公有云之外的选择呢? Mesosphere DC/OS: 简化数据服务的部署和运维 Mesosphere致力于简化现代化弹性分布式软件的开发. Mesosphere DC/OS是市面上唯一一个在生产环境中被验证的能够同时运行容器和数据服务的平台. DC/OS 能够提高很多数据服务的部署速度,并简化它们的运维.这些数据服务包括数据库,消息队列,大数据分析引擎等等. DC/OS的核心是Apache Mesos?,一个分布式系统内核. 它拥有一个两层资源调度机制,使得分布式系统之间能够更好的分享集群资源.正因为有了两层调度机制,使得DC/OS能够在和其他容器编排系统(Kubernetes,Docker Swarm)的对比中脱颖而出.它简化了数据服务的部署和运维,并且大幅度提高了资源利用率.
（编辑：辽源站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
