容器云存储的需求考量与方案选择

大数据、人工智能都需要数据来支撑，所以这块的数据存储量将会越来越大。比如每天的日志数据可能就有几十个G，几百个G，这些数据经过清洗处理分析，可能会带来新的价值增长点，也会带来越来越多的新业务创新。但随着数据量的累积，也会给存储带来压力。所以不同的数据可能需要考虑采用不同的存储方案。这可能有涉及到数据的治理问题了。远程卷有NFS、NAS、SAN、Ceph、GusterFS等产品可以选择，不同需求选择不同的产品。

镜像对存储的需求相对简单，镜像通常也是需要不断的更新的。不过镜像需要考虑不同环境镜像库的镜像存储。通常情况下，镜像仓库可以非容器化部署，相对来说主机存储资源管理起来会更方便。

中间件存储更多是因为中间件部署时，不同中间件对存储的需求可能不同。最典型的比如Kafka，需要多块磁盘、文件系统使用XFS以及Mount 文件系统时使用noatime选项等以达到更好的性能。这就需要基于不同的组件来确定选择什么样的存储。不过在容器云上实现目前还不是特别便利。可以考虑非容器部署。

五、无容器存储思路

目前说起容器云存储，大家都会想到Ceph或GlusterFS等。我们PoC测试的时候也随大流测试了一下。大家都说这么配，所以我们也就这么配了。不过后来想想，我们mount存储卷，目的是为了数据持久化，为了有状态应用。但是如果按照云原生的理念，不是为了云而硬性迁云，可能不需要太多存储资源。还有就是数据可以通过实时数据流方式采集到数据中心或数据处理终端，让数据运转起来、流转起来，而不是仅仅存储起来，充分开发数据的价值。沉睡和静止的数据无法带来价值，运转起来的数据才有价值，实时性越高的数据越有价值。这也是构建大数据平台大数据分析的价值。

从这个角度来说，我们可以让数据运转起来，不用都存储于磁盘，或者在容器云平台可以采用这种思想，把数据从容器中抛出来，然后再进一步处理或存储。这样存储资源的使用可能就简单多了。比如应用服务日志，可以直接从容器中把日志信息从日志文件或标准输出中采集到，然后扔到ES或Kafka等消息中间件。这个功能由容器云平台来提供，用户也就不需要关心实现的细节。更重要的是，通过ES或Kafka可以实时进行数据的进一步处理，也避免数据在容器平台持久化存储的一些问题。

这只是个人的一点想法，具体的可能更多还是要考虑数据在容器云平台的持久化存储。相应的产品和技术，大家讨论的也挺多，这里就不赘述。

六、容器云存储方案选择

采用容器云选择存储时，需要基于实际的业务需求来确定，深刻理解容器云平台是用来承载应用的，是为企业业务应用服务的。这也是我们在选择容器云产品时一再强调的。我们采用容器云不是为了容器，而是为了业务应用，为了业务。不同业务对存储的需求不同。有安全性要求比较高的，也有可以容忍数据丢失的等。不同的业务需求，采取的存储方案、存储产品就会不同，因为产品不一样，所付出的资金代价是不一样的。

选择产品时还需要考虑企业自身的技术实力，开源产品有开源产品的优点，商用产品也有商用产品的优点，对于像我们这样的金融公司来说，更多要考虑的是数据的安全性，在采用开源产品时就会很谨慎，后期服务是一个很重要因素。得有公司来兜底，哪怕多花些钱，买个心安。

另外还要考虑是否有能力驾驭选择产品或技术。开源产品对技术能力要求比较高，选择开源产品，最好有相应的技术人员储备。开源产品技术领先，版本迭代变化也比较快，需要有相应的人力去把控。如果做不到这点，选择商用产品是合适的，虽然成本高点，但经过了众多企业的技术验证。特别对传统企业来说，技术实力一时还比较难达到要求，无法把控产品，最好不要轻易使用开源的产品。

还有可能需要考虑容器云产品和架构方案，以及是否有IaaS层的技术支持，IaaS层采用的技术等方面。

七、存储、容器云和大数据

我们考虑存储不仅仅是容器云需要，大数据平台也需要，存储可以单独作为一块来考虑，可以不绑在容器云项目上。综合容器云平台，大数据平台建设，统一来考虑存储资源的建设，可能会更好些。我们的最终目的是能为容器云平台提供存储资源也就够了。

（编辑：源码网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!