May 31, 2017 发布

Elasticsearch 新边界:Elastic Cloud 企业版 1.0 通用版本

作者 Haley EshaghBaha Azarmi

Elastic Cloud 企业版 (ECE) 1.0 正式发布通用版本,我们为此激动不已。这款新产品能够让您在您选择的环境中,按照您想要的方式,通过单个控制台配置、监控、编排一系列 Elasticsearch 集群和 Kibana 实例。

(如果您想要深入了解, 欢迎试用并享受它带给您的体验。此外,您或许正在期待我们即将推出的网络研讨会和产品演示。)

今天发布通用版本之前,我们已经探讨了产品架构, 业务价值目标用户。现在,我们想更加详细地介绍用户应用 ECE 这款产品的具体方法。

我们的很多用户在产品应用方面都有类似的经历。以 X 公司为例,他们的开发人员处理与数据相关的问题时,偶然发现了 Elasticsearch,就将它下载下来并启用了测试集群,输入了一些数据后发现操作成功。同事听说后就增加了自己的数据,而集群为了支持这些新增的数据,不得不扩大规模。不久之后,X 公司在发挥生产支持作用的任务关键型功能中运行的 Elasticsearch 节点就增加到了几十个。

而这仅仅是开始。

假设 X 公司是一家银行。他们的多节点生产集群目前支持将日志用例应用到多个应用范围,但是他们现在希望将安全分析和交易分析应用到新的应用范围。此外,营销团队、人力资源团队和 SRE 团队都听说了 Elastic,并且要求试用或者应用它来解决各自的业务问题。

现在的局面变得越来越有意思了。各种各样的问题聚在了一起,这些问题带来的麻烦是由集群规模的管理难题自然衍生出来的,例如多用例、多租户、越来越多的数据。

elasticsearch-multitenant-multi-use-case-management-monitoring-orchestration.png

这样的问题是我们乐于面对的,不过解决起来颇具挑战。为了解释清楚,我们先进行分解,聚焦两个(自然而然存在的)问题:1) 你们是谁;2) 你们想要做什么?

第一个问题:你们是谁?

如果你们是集群的租户。你们会关心获取洞察所需的时间、快速响应、自定义体验以及能否满足期望。但是,如果对所有租户都等而视之,这是不明智的做法。他们有不同的需求、习惯和要求 — 每个要素都可能导致摩擦和挫败。

  • 不同的访问控制配置。 租户会有不同的用例。有些可能要进行全文搜索或需要智能提示和推荐。其他可能要对安全数据进行繁重的聚合、日志分析或扫描和遍历。

  • 不同的服务水平协议 (SLA)。执行威胁追踪的安全团队可能并不希望他们的分析所获得的响应有延迟,但是他们对集群进行的任务量繁重的查询可能会对其他租户的 SLA 预期产生负面影响。
  • 不同的版本 并非所有租户都运行相同版本的 Elastic 产品。他们可能出于特定的原因而必须使用某个特定的版本,因此如果硬要他们在没有准备好的情况下升级,会适得其反。

还有其他要考虑的因素。例如,不同的备份策略会产生额外的工作量,或给基础设施带来负担。还有些租户可能会构建任务量繁重的告警,需要查询的数据量相当于一年的数据量,这会妨碍其他租户的集群。

如果你们是生产团队。Elastic 的所有魔力都会通过你们发挥出来。你们会关注如何提供良好的用户体验,为项目或部门带来更高的投资回报率(ROI),并且要确保不会因为处理应急问题而导致时间过于紧张。从这个角度来看,我们需要考虑另外一组要素。

  • 何时维护。 这是个老生常谈的问题:为了将系统和用户影响降至最低,应该何时维护?如何协调不同的时区和不同的使用模式?
  • 一个租户让全盘崩溃。如果某个租户执行大型查询,阻塞整个集群,内部客户可能会因此提出访问受阻的问题。
  • 安全合规性。有些租户出于安全原因,不能将自己的数据与其他租户的数据放在同一个集群中。
  • 大家都爱用 Kibana。目前,Kibana 没有多租户架构,因此用户不得不启用多个 Kibana 实例,这就意味着会带来额外的管理工作。

那该怎么做呢? 

软件运作如此顺利,并且给组织许下了如此多的承诺,那么生产团队应该怎么做来防集群(或者可能是他们的精神)崩溃呢?

elasticsearch-kibana-clusters-instances-at-scale-manage-monitor-elastic-cloud-enterprise.png

因为,这就是你们的现状……

你们有一个选择(事实上,终究会发展到这一步):拆分集群。将集群拆分成小块能够解决我们讨论过的部分痛点,但的确要付出一些代价。

部署和配置需要考虑使用配置管理工具或编排工具、跨各个集群管理不同的 Elastic 版本(这对于 5.x 之前的版本会有些困难)、支持不同的 SLA 甚至不同类型的基础设施,等等。

现在,我们来啦。

ECE 能够轻松、彻底地解决这一类难题。它能够通过单个控制台满足所有这些需求,并将所有操作简化。

无论是新建集群、根据需要调整规模、托管和升级多个版本,还是启用 Kibana 和 X-Pack — 您只需单击或提交 API 调用即可。您可以通过单一管理平台监控整个部署,并确保所有人满意。然后,您就可以专注于处理项目,推进业务发展。

现在,无论任何时候,只要有人想要试用 Elastic 或全面投入生产,都能够轻松实现。想要一点 POC 测试时间?可以启用新的集群。需要一个短期存在的环境?没问题。想要求提供符合安全计划的硬件却有顾虑?别担心。(人们不会仅仅出于测试的原因,就要求提供新的虚拟机或专用机器……)ECE 已经处理好了。项目需要多个环境进行 QA 和预生产?听上去也没有问题。

ECE 的设计初衷,就是为了解决这些问题,并且圆满地解决这些问题。ECE 所用的代码库与我们 Elastic Cloud 服务所用的代码库是一样的。截至目前,Elastic Cloud 服务已经在过去几年里托管了成千上万个集群。总而言之,只要您希望与 Elastic 共同成长,ECE 这款产品就是您的理想选择。事实上,在我们的第一批客户中,有一个客户只有 5 个生产集群,但是他们发现,这款产品的集中式管理特性能够为他们实现未来发展期望带来价值。

快快行动起来试用这款产品吧!让分步介绍文档带您详细了解其中的细节。