ExtraHop挖掘网络以收集行动情报

杰西Rothstein

杰西Rothstein

F5旗舰产品线的首席架构师杰西·罗斯坦(Jesse Rothstein)创立了F5ExtraHop在2007年开发产品,从从网络收集的数据中获取IT运营情报。有个足球雷竞技appNetwork World主编John Dix最近采访了Rothstein,了解了该公司的最新情况,以及它对虚拟丢包等事情的了解(提示:这可能是高度虚拟化环境的危害)。

你在F5的背景对你在ExtraHop有什么帮助?

我的联合创始人拉贾·穆克吉(Raja Mukerji)和我都在F5工作了很多年。我们在F5做的是把应用意识和应用流畅性带到负载均衡器上,这创造了一个全新的产品类别叫做应用交付控制器。在ExtraHop在美国,我们在高速数据包处理和应用流畅性方面利用了相同的领域专业知识,但我们把它带到一个新的领域,更多地是在it运营方面,我们开始把它称为it运营智能。

拉贾和我对话组织和我们一起工作的人在过去,很明显我们的最终结果大趋势像服务器虚拟化,虚拟机自旋向上和自旋向下和跳跨数据中心,和敏捷开发,我们推出新版本的应用程序每两周或每两天,雷竞技电脑网站导致了前所未有的规模、复杂性和活力。公司用来管理这些环境的上一代工具和技术已经不再站得住脚了。这是如果他们有这些工具的话。通常情况下,公司只是让聪明人来解决问题,弄清楚到底发生了什么。

所以我想说,第一,现在的情况已经超出了我们的能力,让聪明人来解决这个问题,然后开几个通宵,点披萨。第二,上一代工具是为更小的非动态环境而构建的。这些工具基本上都是从砖块开始的,然后你空降销售工程师、系统工程师和顾问团队来配置它们,以提供你需要的可视性。然后,如果环境发生了变化,而不是自动检测到变化,您必须冲洗并重复该过程。

因此,我们从这样一个概念开始:这些IT大趋势正在发生,我们有领域专业知识来解决有关规模和动态的一些问题,我们可以提供这些环境的可见性。

在当前这一代的工具中,你把哪些东西归为一类?

这是我思考了一段时间的分类。在企业IT中,您可以使用四个左右的数据源来获取有关环境的一些信息。

首先,我们有机器数据,我用的是Splunk推广的一个术语。机器数据包括日志文件、SNMP和WMI,而且所有这些数据源在很大程度上都是非结构化的。Splunk和其他类似的公司意识到,企业正在产生大量这种非结构化的机器数据,而实际上并没有对它们做任何事情。所以他们建立了一个平台来索引它,存档它,并分析它,从中获得一些智慧。

我有时开玩笑说,它的变革就像水力压裂法在能源市场上的变革一样。我的意思是,价值一直存在,但通过应用新技术,我们现在可以获取和提取它。所以我认为IT环境中的一个数据源就是这种非结构化的机器数据。

另一个来源是我称之为代码级插装的东西。这也是传统应用程序性能管理的基础。Wily(被CA收购)确实建立了这个市场,但像DynaTrace和AppDynamics甚至New Relic这样的公司都在使用代码级检测。它们有代理,可以使用Java JVM或. net公共语言运行时,它们可以围绕服务的执行情况获得一些智能和性能指标。热点和瓶颈在哪里?它在做什么?对于熟悉代码并希望了解代码在生产环境中如何运行的开发人员来说,这些工具非常有用。

我称之为服务检查的第三个数据源。有很多设施可以做到这一点。如果您正在运行某种合成事务(基本上是一个镜像普通用户操作的脚本),您可以使用内部检查,这是惠普的Mercury SiteScope和Nagios现在所做的,或者使用Keynote或Compuware的Gomez这样的外部服务检查。这些信息可以让您了解服务或应用程序是上升还是下降,以及在某种程度上它是如何执行的。但这种方法存在一些挑战,因为这些东西在本质上是周期性的,存在固有的欠采样问题。这意味着如果你有任何间歇性的问题你很可能会错过它。

最后,情报的第四个基本数据来源是我们所说的有线数据。这是网络上的所有东西,从数据包到单个交易的有效载荷。这是一个非常深入、非常丰富的数据来源。事实上,所有迹象都表明,有线数据至少比其他数据源大一到两个数量级,因为在我们的网络中有太多的移动。这是确定的。如果我们能在网络上观察到事务的完成,我们就知道事务已经完成,并且我们可以观察到对话中的对等节点承认事务已经完成。

电线数据在很大程度上被忽略了。是的,像网络探测器和包嗅探器这样的产品已经存在了30年或更久,但我认为它们只是网络上可用产品的皮毛。在ExtraHop,我们成立公司的前提是网络上有非常丰富、非常深入的数据来源,通过利用处理能力和存储容量,我们可以提取、分析并从这些数据中获得情报。它需要一种完全不同于其他任何数据源的技术方法。但我相信,它的价值是一样的。

我告诉组织,作为一个最佳实践,他们应该有一个专注于这四个来源的产品。我希望我能说有一种能做到所有这些的方法,但是没有,因为它们确实需要非常不同的方法。

APM提供商辩称,他们可以看到所有内容,因为它们嵌入到应用程序中。你能提供什么他们不能提供的?

APM真正关注的是代码级插装,我们和APM之间可能有三个基本区别。一个是哲学。我们以不同的方式定义应用程序。APM倾向于将应用程序定义为在服务器上运行的代码,并对其进行检测。在ExtraHop中,我们将应用程序定义为整个应用程序交付链。这包括客户端设备、网络传输、前端、中间件、事务队列、后端存储甚至其他辅助服务。它是一个链,因为如果任何一个链接失败,整个应用程序就会宕机,而任何一个链接都可能成为瓶颈。我不能告诉你有多少应用程序,我看到的代码运行良好,但应用程序失败,因为一些东西,如DNS解析不完成。这应该被认为是配送链的一部分。

[也:按绩效结果排名前5的APM供应商

第二是观众。传统的APM往往更多地由熟悉应用程序代码的开发人员使用,而IT运营团队可以从我们的有线数据分析中获得更多,因为它专注于生产级系统。我们回答他们最关心的问题,比如“现在发生了什么?”我的环境发生了什么变化吗?事务是成功还是失败?这比平时更好还是更糟?人们想要获得什么资源?”

第三个区别是定制应用程序和现成的打包应用程序之间的区别。APM解决方案在开发自定义应用程序的组织中更受欢迎,因为他们正在编写代码,代码正在变化,他们需要看到代码的执行情况。我们对两者都有销售。是的,我们确实被那些编写自定义应用程序的组织所使用,但也被那些依赖于打包应用程序的组织所使用,这些组织对打包应用程序并不是很了解,但仍然非常关心它的工作情况。

你们就像个设备一样送货,对吧?

是的。我们以实体设备或虚拟设备的形式出售。

你在哪里充电?

对于我们来说,我们只是获取网络流量的副本,完全没有开销。我们不守规矩,我们越界了。我们如何得到交通的副本取决于环境。有时它直接从一个或多个交换机使用SPAN端口或VACL捕获。有时会有一个完整的聚合点击层。一些组织甚至使用一些相当先进的SDN技术来让我们分析流量。在一天结束的时候,如果我们得到流量的反馈,我们就能理解它。

但我想强调的是,尽管我们是一个网络部署,我们分析我所说的有线数据,但我们实际上是在回答有关业务关键应用程序的健康和性能的问题。所以不仅仅是网络团队使用ExtraHop系统。这是一个重要的区别,因为我经常看到这种混淆。

在客户规模方面,你有一个最佳点吗?

我们的高端物理设备可以支持20gb的行速率分析和每秒几十万个事务。因此,大型企业和运营商在数据中心使用多个EH8000设备,并通过ExtraHop中央管理器提供统一的视图。雷竞技电脑网站我们最初的客户是大型企业,但我们开始看到越来越多的中型企业采用我们的产品,因为我们也有虚拟设备,可以分析千兆流量,成本不到1万美元。

如何使用虚拟设备?

首先,虚拟设备实际上可以终止来自物理系统和虚拟系统的流量。因此,它在虚拟设备中运行的事实实际上只是我们提供的一个形式因素。但我们通过了思科认证,可以在思科UCS环境下运行,在那里可以很灵活地利用虚拟流量。在VMware vSphere 5.1和分布式vSwitch中,他们引入了对RSPAN和ERSPAN的支持,以及为安全和监控目的而获取虚拟流量的能力。还有一些公告VMworld围绕新NSX提供更大的灵活性。所以有很多方法可以解决这个问题,但我认为简单的答案是,虚拟网络在过去的24个月左右已经迅速成熟,我们看到了利用虚拟流量的强大能力,就像你利用物理流量一样。

所有虚拟化的努力是否增加了对你的产品类型的需求?

绝对的。任何时候出现额外的抽象层,它不仅增加了对我们产品的需求,还增加了对帮助管理复杂性的解决方案的需求。这是一个大趋势。当然,服务器虚拟化和SDN是额外的抽象层和复杂性。但是,我们已经与许多客户合作过,这些客户围绕着物理到虚拟的迁移这样简单的事情,他们需要向应用程序所有者证明,当他们将应用程序从物理环境迁移到虚拟环境时,性能和可用性是相同的,甚至更好。或者如果他们不是,他们需要能够衡量他们不是。

在虚拟环境中,您不能通过查看资源利用率来衡量性能——它占用多少CPU或需要多少内存。资源利用率和性能不一样,和响应时间也不一样。事实上,在虚拟环境中,我们通过减少空间和更有效地利用CPU和内存资源来获得更高的效率和成本节约。实际上,您希望物理主机的CPU得到高度利用,但又不希望它处于供应状态。这就是平衡。

在这些环境中增加复杂性的一个很好的例子是我们所说的虚拟丢包。管理程序基本上就是调度程序。它们必须在多个客户机器之间共享资源,包可能会被延迟,有时延迟到被底层网络堆栈认为丢失了。现在TCP对损失很有弹性。如果在网络上发生丢失,TCP将重新传输,因此您可能会在网络上看到额外的包,这可能会影响您的吞吐量,但不一定会影响性能。

12 第1页
第1页共2页
SD-WAN买家指南:向供应商(和您自己)提出的关键问题