EBSCO Information Services的企业架构师Nate Baechtold说，实现公司VMware环境的自动化太困难了，因此公司转向OpenStack, OpenStack从本质上抽象底层组件，就像AWS一样。但下一个问题是如何让开发人员构建负载平衡?Baechtold告诉《网络世界》主编John Dix，使用现有的基于硬件的系统的自助服务模型太复杂了，但是一种新的软件定义工具正好符合要求。足球竞猜app软件
EBSCO信息服务
Nate Baechtold, EBSCO信息服务的企业架构师
让我们从组织的缩略图描述开始。
EBSCO信息服务是许多东西，包括私人刊物，研究数据库，历史档案，医学参考数据库，电子图书和企业学习工具的发现服务提供商。很多这些东西你不能在公共互联网上找到。所以，大学和其他组织订阅我们的服务，我们能够联合搜索在所有这些数据库提供他们正在寻找的信息。在过去的一年，我们在达到峰值接近的地方，每天4次亿的搜索。
它呼吁某些垂直市场，比如法律或医疗保健，或者是它的任何和所有的人？
任何和所有的。大量的流量来自为学生提供研究服务的图书馆和大学。
技术环境是什么样的?
我们总部设在AWS和三个私有数据中心，二是支持我们的实时应用和一个主要支持开发资源公共云。2020欧洲杯预赛我们的大部分现场运行的应用程序是由我们的设计的OpenStack之上的私有云支持。
主要的数据中心在波2020欧洲杯预赛士顿和伊普斯维奇。为了冗余和创建故障域，我们在它们之间有一个很大的光纤连接，但其思想是每个数据中心是自主的，可以在没有另一个中心的情况下运行。2020欧洲杯预赛每个数据中心大约有400个物理服务器，大部分工作负载都是虚拟化的，所以我们有5000 - 2020欧洲杯预赛6000个vm。从虚拟化的角度来看，我们使用的是VMware和OpenStack的组合，但是我们实际上是将所有东西都迁移到OpenStack，而OpenStack是在KVM之上构建的。
您构建OpenStack环境有多久了?
两年前，我们为了开发而开放了它，大约一年前，我们开始使用它作为我们的生活资源。从那时起，我们就有很大比例的开发人员将其用于自服务配置，并将其应用到一个模型中，在这个模型中，我们开始自动化配置、自动化部署，真正尝试自动化我们所有的基础设施。
为什么转向OpenStack?
因为这将是太难自动化我们的VMware平台。当你在一个云平台像AWS，你去弄一个虚拟机，它会自动分配一个IP地址，并接收它需要从云平台上运行的一切。您是从很多其他的底层硬件实现的绝缘。VMware的抽象的一些元素，但最终你还是需要知道什么数据存储穿上它，你需要命名的网络，也许VLAN标识符或其他什么东西，它关系到你的基础设施。有很少的抽象，并试图以此为基础将是非常困难的顶部完全自动化模式。
这就是为什么有那么多管理平台在VMware之上——将您与那个API隔离开来——而OpenStack本身抽象了底层实现。您创建一个一致的平台同样你在AWS,所以非常类似于Amazon的EC2实例(Elastic Compute Cloud),你有一个在OpenStack,就像一个EBS卷在AWS(弹性块存储)卷,你有负载平衡服务,你有图片和许多其他的事情。它们不兼容API，但它们以非常相似的方式运行，因此很容易为持续集成/持续部署(CI/CD)管道构建基础设施自动化。
我们认为通过该API的OpenStack作为一个简单的匝道用于获得充分的基础设施自动化，也越来越与我们的CI / CD过程的整合。此外，由于它的建成是一个公共云产品，我们没有与权限战斗。使用vSphere你必须处理权限的文件夹，资源组，和许多其他的事情。相反，具有单独的权限打的，我们给开发商一个项目。该项目是逻辑上的所有其他基础设施分开，像他们经营自己私有的数据中心。2020欧洲杯预赛
这使他们很容易编写自动化，因为他们不需要担心破坏东西、破坏整个环境或影响共享资源上的人员。它降低了编写自动化、实验和测试的门槛。这些都是OpenStack提供给我们的核心功能，这也是我们使用它的原因。它主要集中在API和加速我们的开发工作和加速我们的基础设施自动化工作。
此时，您的工作负载中有多少百分比位于OpenStack上?
在我们的虚拟基础设施中，我认为大约有一半。目标是迁移所有东西。
您提到您有一些AWS云资源。使用OpenStack的部分原因是不是因为它将使AWS更容易以溢出能力使用?
由于数据局部性和一大堆其他问题，要实现透明地来回迁移工作负载的混合云并不容易。我们，可能像大多数公司一样，正在积极努力进入AWS，进入公共云，但我们意识到，我们仍然需要一个私有云，在此期间能够为我们自己的内部数据中心提供服务。2020欧洲杯预赛
你认为从长远来看，你会全身心投入到公共IaaS服务中去吗?
是的。我认为这是我们的长期目标。到达那里需要多长时间是另一个问题，但那将是我们的长期目标。今天，我们使用AWS来处理和托管一些运行时服务。
据我所知，你的虚拟化的另一件事是你的应用交付控制器。是什么让你走上这条路?
我们创建了这个私有云，用户可以在其中根据自己的意愿配置和拆卸vm，他们非常非常频繁地这样做。在这种环境下，变化速度之快令人难以置信。在过去的两年里，我们已经创建和销毁了超过42万台虚拟机。
但是，在您为开发和操作团队提供自助服务的能力之前，云实际上是没有用的。他们可以开箱即用地构建vm。太好了。但是，他们无法将它们连接到负载平衡或其他需要的东西上。负载平衡是最大的痛点，因为如果没有负载平衡的表象，就无法构建高可用性的应用程序。
因此，我们首先尝试在现有的基于硬件的负载平衡系统上创建一个自助服务模型，在这个模型中，我们可以让团队提供新的内容规则、新的虚拟ip以及构建和管理应用程序所需的一切。但这是出乎意料的困难。在我们现有的解决方案中，创建一个完全自动化的系统几乎是不可能的。
难道你的硬件ADC供应商提供其设备的软件版本？
是的，他们确实。他们提供了一个虚拟机版本，但它所作的只是转移问题。它并没有解决问题。它帮助我们唯一的办法是说，“好了队，现在你配置和管理自己的虚拟负载平衡器。”他们不太乐意这么做，因为它增加了复杂性。
它不会是非常有效的利用这个问题，是由一个专门的负载均衡的团队之前得到解决，移动它，这样现在大家都不得不成为一个特定的负载均衡技术主题专家。于是我们看着窃听到的负载平衡器作为OpenStack的服务并使其指向我们现有的供应商，并没有工作得非常好。司机不是很在那个时间点的成熟，它清盘造成的各种问题。这是什么原因造成我们开始寻找替代品。
你能不能给我们什么样的负载均衡是被要求做一些方面的角度？
我们有一个非常重soa的架构。我们的中、后层中大概有80个左右的服务在互相通信，所以在这个环境中，前端层只是负载平衡器工作的一小部分。
什么解决问题的吗？
我们在OpenStack峰会上看到了一家名为Avi Networks的公司，他们有一些非常有趣的演示。吸引力是多方面的:
*首先，从接入的角度和API的角度看，他们完全符合的OpenStack的多租户系统对齐。他们所做的就是查看负载均衡器作为一个项目，一个租户，就像OpenStack的创建项目和租客，并表示你对世界的看法。你只能看到你的房客的东西，你只能影响你的房客的东西。如果我给你通过一个租户阿维的逻辑片，就像通过OpenStack的，你只能破坏东西在自己的世界。它可以很容易地用手负载平衡的职责关闭以不同的球队。我们给你访问你的负载平衡器的视图，可以执行所有的你需要建立的功能和从地面自动管理应用程序。这是真的很酷。
*第二件事，结业更吸引我们，是洞察力和与它来分析引擎。我们用来获取来自负载平衡器的一些非常原始指标，但分析我们得到阿维出来是非常难能可贵的;之类的东西更好的终端到终端的性能测试结果，并自动异常检测和跟踪。而一些清盘是非常有用的是显著事件检测。它记录它认为显著的事件，我们已经使用，要找到以前没有发现的网络问题。
我们的开发运营团队清盘可能喜欢该元素最出所有的因为现在他们已经得到了这一切的知名度，这一切洞悉应用程序的性能，他们以前是没有的。它创造了一个强烈的愿望，迁移到该产品。
阿维怎么解决需要为简单起见，您与其他产品进行了有问题？
安装和AVI的使用是直截了当的。只花了我们20分钟即可到达一个高度可用的情况下部署，配置和集成到我们的OpenStack云计算，这是真棒。
从用户的角度来看，界面非常直观，易于使用。没有任何多余的选项，如果有他们封锁了进入自己的小界上下文区域;网络设置，例如，在网络配置文件部分，除非你在乎的是，你不需要处理它或者知道它的存在。你只是采取一切的标准是。我们可以在它指向开发团队和人民没有负载均衡体验能够快速创建高可用性负载平衡的环境。
我们曾经有一个集中式的网络团队来完成我们所有的负载平衡功能，编写自定义规则，试图提取这些功能供其他人使用，现在我们能够将这些功能分发给所有的操作团队，因为它们非常简单。
它是如何部署的?
我们将它指向我们的OpenStack云，然后它与OpenStack云集成。它与项目集成，与多租户模型一致，并提供OpenStack云上使用的负载平衡器。它们被称为服务引擎。它会根据需要自动放大和缩小服务引擎。从我们的角度来看，我们创建了一个OpenStack项目，我们告诉Avi在这里放置负载平衡器vm，它会根据自己的需要自动对它们进行进进出出。
从硬件转向基于软件的产品，您是否担心潜在的性能问题?
一开始我们很担心，但是到目前为止，我们所做的每一个性能测试，以及我们转换的每一个活动应用程序，都没有显示任何性能下降。事实上，在某些情况下，由于insight和分析引擎指出了我们之前没有注意到的低效，我们最终获得了更好的性能。
您是否证明迁移符合承诺的易用性，或者是否存在成本因素?
我会说是易用性。与我们战略的整合，与我们的私有云，是真正的驱动因素，但它也有成本节约的因素。它最终比我们现有的解决方案要便宜得多，因为它不依赖于专有硬件，我们只是为软件付费，而且它是在我们所有系统都运行的x86虚拟化平台上扩展的。
在实施或经验方面沿途的任何打嗝学到了什么？
总会有打嗝的时候。在转换我们的一个应用程序时，我们发现我们设置的一个性能设置对应用程序的类型来说效率很低，它正在向这个服务发送大量的HTTP post数据，而我们并不知道这一点。当我们调整了TCP Windows缩放设置后，它的性能得到了提升。
听起来你们的产品效果不错。
它有。我们已经到了这样一个阶段，现在我们正在使用它来进行应用程序的蓝绿色部署，以实现完全的基础设施自动化。作为软件发布的一部分，我们将启动一个全新的服务器群，将其与负载平衡器连接起来，独立地对其进行验证，然后只需切换负载平衡器以在一个原子操作中为新软件提供流量。通过完全的自动化，我们可以自动地建立新的环境、虚拟服务和负载平衡规则，并且我们仍然可以得到所需的可见性。这是我们公司比较成功的事情之一。