阿里云代理商-阿里云服务器-阿里云数据库-重庆典名科技

平台提供的基础设施资源

发布时间: 2020-09-17 10:23:27文章作者: 网站编辑阅读量: 298
  平台提供的基础设施资源,基础设施管理拥有许多活动部件。动态基础设施平台提供了 3 种主要的基本组件:计算、存储和网络(见图 2-2)。大部分平台提供的服务列表远远超出这 3 种,但其他服务几乎都只是这些服务的各种变化(例如不同类型的存储)或者在它们之上的服务组合。例如服务器镜像管理(支持计算的存储)、负载均衡(网络,可能基于计算实例)、消息(网络和计算)和认证(在计算实例上运行的应用程序)。甚至像 Kinesis 这样无服务器的计算服务,也是通过在常规的计算资源上运行任务来实现的。

平台提供的基础设施资源

图 2-2:动态基础设施平台提供的核心资源

  1 计算资源
  
  计算资源就是服务器实例。任何动态基础设施平台都能创建和销毁虚拟机,还有一些服务和功能让服务器管理更容易、更强大。
  
  构建、配置和管理服务器的系统和流程占用了基础设施团队大部分的时间和注意力,因此本书大部分内容都专注于这些方面。
  
  2 存储资源
  
  虚拟化基础设施消耗了数量惊人的存储——动态创建服务器吞噬磁盘空间的速度非常惊人。基础设施平台需要为服务器、快照、模板等分配磁盘空间,同时还要使运行在这些服务器上的应用程序和服务有存储可用。
  
  云平台需要透明地管理服务器资源的磁盘资源分配——虽然这是平台的实现细节,但是创建服务器的人或者流程不应该考虑它存储在哪里。虚拟化平台可能不会透明地提供存储,所以置备服务器的脚本可能需要查找空间足够的存储池,然后将其分配给新的实例。
  
  即使服务器空间的分配是透明的,但仍然会有些局限。有些可能是硬性的局限,取决于你的组织在私有云上挂载了多少物理的磁盘空间。有些可能是预算的局限,特别是使用公有云服务时——只要你的信用卡能扛得住,它可以交付惊人的磁盘空间。
  
  因此,基础设施团队管理好磁盘空间的使用非常重要。至少需要将用量和费用信息通过仪表盘清晰地展示出来(5.3.1 节有关于用好信息辐射器的讨论),这样人们就知道什么时候应该检查并剔除不需要的资源。清理旧模板和快照的自动脚本会很有用。
  
  除了计算资源所需的存储,动态基础设施平台还需要为运行于其上的服务和应用程序提供存储。大部分云平台提供两种类别的存储服务:块存储和对象存储。
  
  块存储
  
  块存储卷可以像本地磁盘一样挂载在服务器实例上。云平台提供的块存储服务的例子包括 AWS 的 EBS、OpenStack 的 Cinder 和 CGE 的持久磁盘。
  
  服务器实例通常有一个根卷(root volume),这就是服务器启动和运行的地方。但是服务器也可以挂载和卸载额外的持久化卷(persistent volume)。它们的存在可以比某个特定服务器的生命周期还长,这对于管理持久化数据和连续性策略特别有用,我们会在第 14 章进行讨论。
  
  块状卷看起来是一个本地的磁盘驱动器,但是理解这层抽象背后的实际情况很重要。这些磁盘卷通常是从网络存储中分配的,所以可能有时延的问题。最好的方式是研究其实现方式,运行测试来模拟你的用例,并且调整配置和使用存储的方式以获得合适的性能。
  
  对象存储
  
  许多云平台提供对象存储服务,其中的文件可以在基础设施的不同地方存储和访问,甚至可以公开使用。亚马逊的 S3、谷歌的 Cloud Storage、Rackspace 的 Cloud Files 以及 OpenStack 的 Swift 都是此类存储。
  
  对象存储通常是作为长期存储设计的,比块存储的可靠性更高、成本更低,但是时延会更高。它适用于存储需要从多个服务器上访问的制品,块存储与之不同,只能从挂载它的服务器上访问。
  
  网络文件系统
  
  基础设施团队经常需要在多个服务器实例之间更直接地共享存储。一种方式是使用像 NFS 或者 SMB/CIFS 之类的文件共享网络协议。服务器实例可以挂载本地或块存储,并让其他服务器挂载和使用。早在虚拟化环境出现之前,人们就一直在使用这种文件服务器技术了,但是决定在虚拟化或云化的基础设施上使用这些技术之前还是要小心求证。
  
  如果“本地”的文件系统本身就是从网络上挂载的,再在网络上共享这个文件系统会增加一些无谓的开销和复杂度。在云主机上使用传统的网络文件系统也产生了额外的管理复杂度和开销。这些文件服务器技术不一定能够很好地处理经常添加和移除的文件服务器节点,使得连续性面临重重挑战。
  
  诸如 GlusterFS、HDFS 或 Ceph 的分布式和(或)集群式文件服务工具的设计使之更适合在动态基础设施中使用。它们确保了文件在多个服务器节点间都是可用的,也能更平稳地应对服务器节点的添加或移除。但是也不要假设这能完美解决问题,你不仅一定要对性能和延迟进行测试,而且还要针对集群变更的影响以及失败场景进行测试。
  
  在决定使用何种特定的技术和工具之前,想清楚使用场景。我看到过至少一个团队实现了复杂却脆弱的 GlusterFS 集群,仅仅是为了实现容错,也就是当第一台服务器出故障的时候,另外一台灾备服务器能够确保数据继续可访问。直接使用平台内建的服务,如块存储复制,通常更加简单、可靠。
  
  3 网络资源
  
  动态基础设施平台需要管理内部元素之间以及与外部网络的网络互通。在基础设施中添加和删除服务器,需要更新网络路由、负载均衡池和防火墙规则。
  
  大部分虚拟化或者云化的基础设施平台都提供动态、虚拟化的网络来处理网络互通。然而这些平台通常都安装和运行在拥有自己网络基础设施的更大资产之上。为了让动态基础设施平台中的元素和其他部分无缝地在一起工作,需要对接周边的网络。
  
  很多时候,可以直接通过静态的方式配置周边网络,将流量转发到基础设施平台。当外部网络比较简单时,这就可以工作得足够好。像安全、路由和负载均衡这样复杂的逻辑可以由动态平台处理。目标是避免为了支持动态基础设施的变更而对网络基础设施进行手动变更。
  
  当然,自动化配置周边网络也是可能的,这样就能够容易地处理动态基础设施的变更。这给网络资产带来了基础设施即代码的所有好处:可重复性、持续测试以及一致性。
  
  网络设备供应商正在改进他们对软件定义网络的支持。有些设备也许不能直接和虚拟化或云平台对接,但是基础设施定义工具(将在第 3 章讨论)可以用来编排不同的平台,从而针对计算资源的变更对网络定义进行相应的修改。
  
  自动化网络设备配置
  
  虽然供应商已经开始支持软件定义网络,但很多已有的网络设备还是不易于自动化配置。很多网络团队习惯于在命令行界面手动修改配置,这样做有几个明显的缺陷:
  
  很容易出错,潜在地引发宕机;
  
  不容易确保设备之间的配置是一致的;
  
  依赖备份来重现配置,不容易跨设备进行移植;
  
  即便是常规的变更,也需要由很了解特定设备的人来完成。
  
  采用了基础设施即代码的团队会寻找自动化配置的方法以绕开这些问题。首先需要理解特定设备的不同配置方式,然后考虑如何自动化管理设备的各种选项。
  
  大部分网络设备有导入配置文件的选项,通常是通过 TFTP。在这种情况下,可以把配置文件签入 VCS 系统中,并使用 CI 或者 CD 服务器自动将其应用到设备上。第 4 章中描述的服务器配置定义的技术可以在这里使用。
  
  一种更精巧的方法是在上传配置文件之前动态地生成它。这允许对网络和其余的基础设施一起进行自动定义。例如,在设备添加时设置防火墙和负载均衡的配置。
  
  不管采用何种方式,拥有能够自动应用配置并进行正确性测试的测试设备都是必要的。这样可以应用变更管理流水线。有时一些特定的设备太过昂贵,让团队没法承担测试实例。在这种情况下,任何负责任的团队都应该确保能够对基础设施的关键部分做例行测试。
联系客服免费领取更多阿里云产品新购、续费升级折扣,叠加官网活动折上折更优惠