EBSCO信息服务公司的企业架构师Nate Baechtold说，将公司的VMware环境自动化将会非常困难，所以公司转向了OpenStack，它将底层组件抽象得很像AWS。但下一个症结是如何让开发人员构建负载平衡?使用现有的基于硬件的自助服务模式太复杂了，Baechtold告诉《网络世界》主编John Dix，但是一个新的软件定义的工具正符合这个要求。有个足球雷竞技app
EBSCO信息服务
内特Baechtold，在EBSCO信息服务企业架构师
让我们从组织的缩略描述开始。
EBSCO信息服务是许多东西，包括私人刊物，研究数据库，历史档案，医学参考数据库，电子图书和企业学习工具的发现服务提供商。很多这些东西你不能在公共互联网上找到。所以，大学和其他组织订阅我们的服务，我们能够联合搜索在所有这些数据库提供他们正在寻找的信息。在过去的一年，我们在达到峰值接近的地方，每天4次亿的搜索。
它是否会吸引某些垂直市场，比如法律或医疗市场，或者是其中任何一个或所有这些市场?
任何和所有的人。大量的流量来自图书馆和大学向学生提供研究服务。
技术环境是什么样的?
我们总部设在AWS和三个私有数据中心，二是支持我们的实时应用和一个主要支持开发资源公共云。雷竞技电脑网站我们的大部分现场运行的应用程序是由我们的设计的OpenStack之上的私有云支持。
主要的数据中心在波雷竞技电脑网站士顿和伊普斯维奇质量。冗余的缘故，并创建故障域，和我们之间有一个较大的光纤链路，但这个想法是每个数据中心是独立的，可以在不另一种运行。我们在每个数据中心大约400台物理服务器，而我国大多数工作负载进行虚拟化，所以我们有500雷竞技电脑网站0-6000虚拟机。从虚拟化角度看，我们使用VMware和OpenStack的组合，但我们实际上是在哪个是建立在KVM之上的OpenStack迁移的一切。
你有多久了构建OpenStack的环境？
我们在两年前打开了它的发展，大约一年前，我们开始用它为我们的生活资源。从那时起，我们已经有使用它的自助服务供应开发的很大比例，而改编成我们开始的地方自动配置，自动部署模型，真的想自动化我们所有的基础设施。
为什么转移到OpenStack的？
因为这将是太难自动化我们的VMware平台。当你在一个云平台像AWS，你去弄一个虚拟机，它会自动分配一个IP地址，并接收它需要从云平台上运行的一切。您是从很多其他的底层硬件实现的绝缘。VMware的抽象的一些元素，但最终你还是需要知道什么数据存储穿上它，你需要命名的网络，也许VLAN标识符或其他什么东西，它关系到你的基础设施。有很少的抽象，并试图以此为基础将是非常困难的顶部完全自动化模式。
这就是为什么有在VMware的顶部，这样许多管理平台 - 从该API隔离你 - 而OpenStack的原生抽象底层实现。You create a consistent platform the same way you do in AWS, so you have an instance very analogous to Amazon’s EC2 (Elastic Compute Cloud), you have a volume in OpenStack that’s just like an EBS (Elastic Block Store) volume in AWS, you’ve got load balancing as a service, you’ve got images and many other things. They’re not API compatible, but they operate in a very similar way so it is easy to build infrastructure automation for your continuous integration/continuous deployment (CI/CD) pipeline.
我们认为通过该API的OpenStack作为一个简单的匝道用于获得充分的基础设施自动化，也越来越与我们的CI / CD过程的整合。此外，由于它的建成是一个公共云产品，我们没有与权限战斗。使用vSphere你必须处理权限的文件夹，资源组，和许多其他的事情。相反，具有单独的权限打的，我们给开发商一个项目。该项目是逻辑上的所有其他基础设施分开，像他们经营自己私有的数据中心。雷竞技电脑网站
这很容易让，因为他们并不需要担心摔东西，打倒整个环境或影响人们对共享资源他们写的自动化。它降低了进入的门槛，以写自动化，以实验和测试。这些都是真正的核心能力，OpenStack的给我们，这就是为什么我们用它去。它主要是重点围绕API和加快我们的开发力度，加快我们的基础设施自动化的努力。
有多大比例的工作量对OpenStack的在这一点？
在我们的虚拟基础设施中，我认为大约有一半。目标是迁移所有内容。
你提到你有一些AWS云资源。是去与OpenStack的，因为这将使其更容易在溢出容量使用AWS的原因之一？
由于数据局部性和一大堆其他问题，这是不容易实现混合云，你透明地迁移工作负载来回。我们一样，可能是大多数公司，正在积极进入AWS，并获得到公共云，但我们意识到我们仍然需要一个私有云能够为我们自己的内部数据中心，在此期间。雷竞技电脑网站
你认为从长远来看，你会全身心地投入到公共IaaS服务中，而远离管理自己的东西吗?
是的。我想说，这是我们的长期目标。需要多长时间才能实现是另一个问题，但那将是我们的长期目标。今天，我们使用AWS进行BI处理和托管一些运行时服务。
据我所知，你虚拟化的另一件事是你的应用程序交付控制器。是什么让你走上这条路？
我们创建了这个私有云，用户可以在其中提供和关闭虚拟机，以满足他们的核心内容，他们这样做的频率非常高。这种环境下的变化速度是难以置信的。在过去的两年中，我们已经创建和销毁了超过420,000个虚拟机。
但是，在您让您的开发和运营团队能够自服务于构建其实时应用程序所需的所有功能之前，云实际上是没有用的。他们可以开箱即用地构建vm。太好了。但是，他们不能将它们连接到负载平衡或许多其他需要的东西上。负载平衡是最令人头疼的问题，因为如果没有一些表面上的负载平衡，就无法构建高可用性应用程序。
所以首先我们试图建立我们现有的基于硬件的负载平衡系统，在那里我们可以使团队能够提供新的内容规则，新的虚拟IP，他们需要建立和管理自己的应用程序的一切之上的自助服务模式。但令人惊讶的是很难做到的。要创建可以完全自动化的系统是在我们现有的解决方案几乎是不可能的。
难道你的硬件ADC供应商提供其设备的软件版本？
是的,他们做到了。他们提供了一个VM版本，但它所做的只是转移了问题。这并没有解决问题。它帮助我们的唯一方法是说:“好了，团队，现在您可以配置和管理自己的虚拟负载平衡器了。”“他们对此不太满意，因为这增加了复杂性。
它不会是非常有效的利用这个问题，是由一个专门的负载均衡的团队之前得到解决，移动它，这样现在大家都不得不成为一个特定的负载均衡技术主题专家。于是我们看着窃听到的负载平衡器作为OpenStack的服务并使其指向我们现有的供应商，并没有工作得非常好。司机不是很在那个时间点的成熟，它清盘造成的各种问题。这是什么原因造成我们开始寻找替代品。
你能不能给我们什么样的负载均衡是被要求做一些方面的角度？
我们有一个非常SOA的架构重。我们可能不得不在我们的中期和背层相互通信约80个左右的服务，这样的边缘，前层，是什么样的负载均衡是在这样的环境下做一小部分。
什么解决问题的吗？
我们在OpenStack峰会上看到了一家叫Avi Networks的公司，他们有一些非常有趣的演示。它的吸引力是多方面的:
*首先，从接入的角度和API的角度看，他们完全符合的OpenStack的多租户系统对齐。他们所做的就是查看负载均衡器作为一个项目，一个租户，就像OpenStack的创建项目和租客，并表示你对世界的看法。你只能看到你的房客的东西，你只能影响你的房客的东西。如果我给你通过一个租户阿维的逻辑片，就像通过OpenStack的，你只能破坏东西在自己的世界。它可以很容易地用手负载平衡的职责关闭以不同的球队。我们给你访问你的负载平衡器的视图，可以执行所有的你需要建立的功能和从地面自动管理应用程序。这是真的很酷。
*第二件更吸引我们的是它所附带的洞察和分析引擎。我们过去常常从负载均衡器得到一些非常原始的指标，但是我们从Avi得到的分析是非常有价值的;比如更好的端到端性能结果和自动异常检测和跟踪。重要事件检测是非常有用的。它记录它认为重要的事件，我们已经使用它来发现以前没有检测到的网络问题。
我们的开发运营团队清盘可能喜欢该元素最出所有的因为现在他们已经得到了这一切的知名度，这一切洞悉应用程序的性能，他们以前是没有的。它创造了一个强烈的愿望，迁移到该产品。
阿维怎么解决需要为简单起见，您与其他产品进行了有问题？
安装和AVI的使用是直截了当的。只花了我们20分钟即可到达一个高度可用的情况下部署，配置和集成到我们的OpenStack云计算，这是真棒。
从用户的角度来看，界面非常直观，易于使用。没有任何多余的选项，如果有的话，他们会被封锁在自己的小范围内;例如，网络设置在网络配置文件中，除非您关心它，否则您不需要处理它，也不需要知道它的存在。不管标准是什么，你都可以取。我们可以向开发团队指出这一点，而没有负载平衡经验的人能够快速创建高可用的负载平衡环境。
过去，我们有一个集中的网络团队来完成所有的负载平衡功能，编写自定义规则，试图将它们提取出来供其他人使用，现在我们可以将这些功能分发给所有的操作团队，因为它们非常简单。
它是如何部署的？
我们把它指向我们的OpenStack云，它就会与之集成。它与项目集成，与它的多租户模型保持一致，并在OpenStack云上提供负载平衡器供使用。它们被称为服务引擎。它会根据需求自动扩大和缩小服务引擎。从我们的角度来看，我们开发了一个OpenStack项目，我们告诉Avi把负载均衡器VMs放在这里，它会根据自己的需要自动对它们进行伸缩。
是你关注的所有关于潜在的性能损失，从硬件转移到基于软件的产品吗？
起初我们很担心，但到目前为止，我们所做的每一个性能测试，以及我们转换的每一个实时应用程序，都没有显示任何性能下降。事实上，在某些情况下，由于洞察和分析引擎指出了我们之前没有注意到的低效率，我们最终获得了更好的性能。
您是否根据承诺的易用性来证明迁移的合理性，或者是否还有成本因素?
我要说的是易用性。与我们的战略、与我们的私有云的整合是真正的驱动因素，但它也有一个节省成本的因素。它比我们现有的解决方案要便宜得多，因为它不依赖于专有硬件，我们只是为软件付费，而且它可以在我们所有系统运行的同一个x86虚拟化平台上扩展。
在实施或经验方面沿途的任何打嗝学到了什么？
总有一些打嗝。在将我们的应用在我们发现的性能设置，我们有设定结束，目前效率低下的应用程序的类型之一，它是非常发送大量HTTP的POST数据到这个服务，我们不知道它。其清盘的是，我们看到了业绩增长，一旦我们调整了TCP窗口缩放设置的应用程序。
听起来这个产品很适合你。
它有。现在，我们使用它来实现应用程序的蓝绿色部署，以实现完全的基础设施自动化。作为软件发布的一部分，我们将启动一个全新的服务器群，将其连接到我们的负载均衡器上，独立地验证它，并仅通过一个原子动作切换负载均衡器来为新软件提供流量。我们通过完全自动化自动地建立新的环境、虚拟服务和负载平衡器规则，而且我们仍然获得所需的可见性。这是我们公司最成功的事情之一。