基础设施

QQ群

视频号

微信

微信公众号

知识星球

Chinese, Simplified
SEO Title
infrastructure

AWS Nitro系统的安全设计

QQ群

视频号

微信

微信公众号

知识星球

Chinese, Simplified
本文地址
https://architect.pub/security-design-aws-nitro-system
SEO Title
The Security Design of the AWS Nitro System

【云安全】AWS Nitro系统的安全设计 --Nitro 系统的变更管理

QQ群

视频号

微信

微信公众号

知识星球

Chinese, Simplified

Nitro系统的软件和固件由不同的全球分布的工程师团队开发。所有与Nitro系统相关的配置和代码更改都要经过多方审查和批准,并在测试和生产环境中分阶段推出。软件开发从设计文档和评审开始,并通过代码评审。独立AWS安全团队和亚马逊EC2工程团队将对重大更改或功能进行安全审查。

所有变更均由至少一名额外的工程团队成员或利益相关者进行审查,并由一名拥有大量EC2任期的工程师进行审查,该工程师是我们变更管理Bar Raiser项目的成员。除了专家人工审查之外,所有代码签入都必须通过一系列的自动质量和安全检查,这些检查无法通过,并且在中央构建服务的控制下自动运行,确保遵循部署最佳实践,包括适当的监控和回滚。

一旦代码审查和批准完成,并且所有自动化检查都通过,我们的自动化包部署过程就接管了。作为自动化部署管道的一部分,构建二进制工件,团队运行端到端、验证和安全特定测试。如果任何类型的验证失败,部署过程将停止,直到问题得到补救。

软件和固件二进制文件使用非对称私钥进行加密签名,该私钥只能通过记录所有密钥签名活动的自动管道访问。

签名的软件和固件由专门的EC2部署系统部署到EC2车队,该系统配置为遵循定义的部署策略和时间表。更改在可用性区域和地区之间一波又一波地展开。对部署进行监控,以确保只有按预期运行的软件版本保持部署状态,并且任何异常行为都会触发自动回滚。

笔记

有关Amazon如何构建和操作软件的更多信息,请参阅Amazon Builder的库。具体而言,AWS高级首席工程师Clare Liguri自动化了安全、无需手动的部署,AWS软件开发高级经理Mark Mansour加快了持续交付,AWS高级主工程师Sandeep Pokkunuri确保了部署期间的回滚安全

本文地址
https://architect.pub
SEO Title
AWS The Security Design of the AWS Nitro System --Change management for the Nitro System

【云安全】AWS Nitro系统的安全设计 --Nitro 系统的部件

QQ群

视频号

微信

微信公众号

知识星球

Chinese, Simplified

如前所述,Nitro系统由三个主要部件组成:

  • 专用Nitro卡
  • Nitro安全芯片
  • Nitro虚拟机监控程序

Nitro卡

现代EC2服务器由一个主系统板和一个或多个Nitro卡组成。系统主板包含主机CPU(Intel、AMD或Graviton处理器)和内存Nitro卡是具有强大的64位处理能力和专用专用集成电路(ASIC)的专用硬件组件,独立于运行所有客户计算环境(包括代码和数据处理操作)的系统主板运行

Nitro卡实现了EC2服务用于提供和管理计算、内存和存储的所有面向外部的控制接口。它们还提供所有I/O接口,例如提供软件定义的网络、Amazon EBS存储和实例存储所需的接口。这意味着,在主系统板之外与EC2服务的外部世界交互的所有组件,无论是逻辑上入站还是出站,都在独立的计算设备上运行,这些设备在物理上与运行客户工作负载的系统主板分离。

Nitro系统设计用于在主机组件和Nitro卡之间提供强大的逻辑隔离,两者之间的物理隔离提供了一个牢固可靠的边界,有助于实现该设计。虽然在逻辑上隔离且物理上独立,但Nitro卡通常包含在与主机系统主板相同的物理服务器机柜中,并共享其电源及其PCIe接口

笔记

对于EC2 mac1.metal和mac2.metal实例。一个Nitro控制器与一个Mac Mini在同一个金属外壳中,两者通过Thunderbolt连接在一起。请参阅Amazon EC2 Mac实例。

Nitro卡的主要组件是AWS设计的运行专用固件的片上系统(SoC)包。AWS已仔细推动了这些卡的硬件和固件的设计和实现过程。硬件由负责AWS内部硅设计的团队Annapurna Labs从头开始设计。这些卡的固件由专门的AWS工程团队开发和维护。

笔记

Annapurna实验室于2015年被亚马逊收购,此前在AWS Nitro系统关键技术开发的初始阶段成功建立了合作伙伴关系。Annapurna不仅负责制造AWS Nitro系统硬件,还负责AWS定制的基于Arm的Graviton处理器、用于ML训练和推理的AWS Trainium和AWS Infrentia硬件加速器芯片、AWS NitroSSD和用于Amazon Redshift的Aqua(高级查询加速器)。

Nitro卡上的关键控制固件可以使用加密签名软件包实时更新。Nitro卡可以独立于Nitro系统的其他组件进行更新,包括彼此以及系统主板上的任何可更新组件,以便部署新功能和安全更新。Nitro卡的更新对客户的工作负载几乎没有影响,也没有放松Nitro系统的任何安全控制。

Nitro卡通过PCIe物理连接到系统主板及其处理器,但在逻辑上与运行客户工作负载的系统主板隔离。Nitro系统可以包含一个或多个Nitro卡;如果有多个,则通过服务器机柜内的内部网络进行连接。该网络提供了独立于系统主板的Nitro卡之间的专用通信信道,以及与基板管理控制器(BMC)的专用连接(如果服务器设计中存在)。

Nitro控制器

主要的Nitro卡称为Nitro控制器。Nitro控制器为整个系统提供硬件信任根。它负责管理服务器系统的所有其他组件,包括加载到系统其他组件上的固件。整个系统的固件存储在直接连接到Nitro控制器的加密固态驱动器(SSD)上。SSD的加密密钥设计为受可信平台模块(TPM)和SoC的安全引导功能的组合保护。本节介绍了Nitro控制器的安全引导设计及其作为服务器和网络之间的可信接口的作用。

笔记

在AWS前哨部署的情况下,Nitro安全密钥也与TPM和SoC的安全引导功能一起使用,以保护直接连接到Nitro控制器的SSD的加密密钥。

Nitro控制器安全引导设计

Nitro控制器中SoC的安全引导过程从其引导ROM开始,然后通过测量和验证存储在连接到Nitro Controller的闪存中的早期固件来扩展信任链。随着系统初始化的进行,使用可信平台模块(TPM)记录初始启动代码测量值,然后将测量值扩展到其他系统固件。嵌入防篡改TPM中的加密密钥用于对已知良好系统测量的完整集合进行数字签名。然后在每次重新启动时,将此数字签名文件与所有后续系统测量值进行比较,以检测任何意外更改。

如果未检测到任何更改,则使用由TPM中锁定的密钥加密的附加解密密钥来解密系统中的附加数据,以允许引导过程继续。如果检测到更改,则不会解密附加数据,系统将立即停止服务,因此不会托管客户工作负载。

前面的步骤详细说明了Nitro控制器在启动时建立系统软件完整性和有效性的过程。为了使安全引导设计真正安全,SoC引导代码的每个阶段不仅必须有效且未修改,而且必须在实现时功能正确。这一点尤其适用于作为设备物理制造一部分的静态ROM代码。为此,AWS在我们的设计中应用了正式的方法来验证早期启动代码的内存安全属性。

Nitro控制器作为EC2服务器和网络之间的接口

Nitro Controller是EC2、Amazon EBS和Amazon虚拟私有云(Amazon VPC)的物理服务器和控制平面之间的专用网关。虽然逻辑上不同,并且由多个子组件微服务组成,但这三个控制平面在下文中通常称为EC2控制平面。

笔记

在AWS中,一种常见的设计模式是将系统分成负责处理客户请求的服务(数据平面)和负责管理和销售客户配置的服务(例如,创建、删除和修改资源)(控制平面)。Amazon EC2是包括数据平面和控制平面的架构的示例。数据平面由运行客户EC2实例的EC2物理服务器组成。控制平面由许多服务组成,这些服务负责与数据平面通信,并执行诸如中继命令以启动或终止实例或接收操作遥测等功能。

A diagram depicting Nitro System control architecture.

Nitro系统控制架构

Nitro控制器向专用EC2控制平面网络提供一组经过严格认证和加密的网络API,用于系统管理。每一个API操作都会被记录,所有调用API的尝试都会使用细粒度访问控制模型进行加密认证和授权。每个控制平面组件仅被授权用于完成其业务目的所需的一组操作。使用正式方法,我们已经证明Nitro控制器的控制消息解析实现的面向网络的API在面对任何配置文件和任何网络输入时都不会出现内存安全错误。

用于I/O的Nitro卡

除Nitro控制器外,一些系统还使用其他专用Nitro卡来执行特定功能。这些从属Nitro卡与Nitro控制器共享相同的SoC和基本固件设计。这些Nitro卡根据其特定功能的需要设计了附加硬件和专用固件应用程序。例如,包括用于VPC的Nitro卡、用于EBS的Nitro卡和用于本地NVMe存储的NitroCard。

这些卡使用集成在SoC中的安全密钥存储的硬件卸载引擎实现网络和存储的数据加密。这些硬件引擎提供本地NVMe存储和远程EBS卷的加密,而不会对其性能产生实际影响。VPC的Nitro Card的最后三个版本(包括所有新发布的实例类型上使用的版本)对所有VPC流量进行透明加密,使其能够传输到运行在同样配备加密兼容Nitro卡的主机上的其他EC2实例,而不会影响性能。

笔记

AWS在所有类型的EC2实例之间提供安全的私有连接。此外,一些实例类型使用底层Nitro系统硬件的卸载功能,使用AES-256-GCM自动透明地加密和匿名化实例之间的传输流量。对网络性能没有影响。为了支持实例之间的这种额外的传输流量加密,实例必须是支持的实例类型,在同一个Region中,并且在同一VPC或对等VPC中。流量不得通过虚拟网络设备或服务,如负载平衡器或传输网关。有关其他信息和支持的实例类型列表,请参阅传输中的加密。

用于EBS、本地实例存储和VPC网络的加密密钥仅以明文形式存在于Nitro卡的受保护易失性存储器中;AWS操作员以及在主机系统主处理器上运行的任何客户代码都无法访问它们。Nitro卡提供通过PCIe连接到主服务器处理器NVMe的硬件编程接口,用于块存储(EBS和实例存储)、用于网络的弹性网络适配器(ENA)、用于带外操作系统控制台日志记录和调试的串行端口等。

笔记

EC2为客户提供了访问实例控制台输出以进行故障排除的权限。Nitro系统还使客户能够连接到串行控制台会话,以便对引导、网络配置和其他问题进行交互式故障排除。在此上下文中,“带外”是指客户通过与实例本身或其网络连接分离的通道获取信息或与其实例交互的能力。

当系统配置为使用Nitro Hypervisor时,Nitro卡提供的每个PCIe功能都使用单根输入/输出虚拟化(SR-IOV)技术细分为虚拟功能。这有助于将硬件接口直接分配给VM。客户数据(客户传送给我们用于处理、存储或托管的内容)直接在Nitro卡提供的实例和这些虚拟化I/O设备之间移动。这将使I/O中涉及的软件和硬件组件集最小化,从而降低成本、提高性能和提高安全性。

Nitro安全芯片

Nitro控制器和其他Nitro卡一起作为Nitro系统中的一个域运行,系统主板与Intel、AMD或Graviton处理器一起运行,客户工作负载运行在该主板上。虽然Nitro控制器及其安全引导过程为Nitro系统提供了硬件信任基础,但使用了一个附加组件来扩展对系统主板的信任和控制。Nitro安全芯片是这两个域之间的链接,它将Nitro控制器的控制扩展到系统主板,使其成为系统的从属组件,从而扩展了Nitro Controller的信任链以覆盖它。以下各节详细介绍Nitro控制器和Nitro安全芯片如何共同工作以实现这一目标。

系统硬件的Nitro安全芯片保护

Nitro安全芯片是集成到服务器系统主板中的设备。在运行时,它拦截并调节对本地非易失性存储设备和低速系统管理总线接口(如串行外围接口(SPI)和I2C)的所有操作,换句话说,对所有固件的操作。

Nitro安全芯片也位于BMC和主系统CPU之间的高速PCI连接上,这使得该接口能够在生产系统上进行逻辑防火墙。Nitro安全芯片由Nitro控制器控制。因此,Nitro控制器通过其对Nitro安全芯片的控制,能够调解和验证系统主板或Nitro卡上固件的更新或其他非易失性设备的编程。

一种常见的行业实践是依靠管理程序来保护这些系统硬件资产,但当不存在管理程序时,例如当EC2以裸机模式使用时,需要一种替代机制来确保用户无法操作系统固件。Nitro安全芯片提供关键的安全功能,确保主系统CPU不能在裸机模式下更新固件。此外,当Nitro系统与Nitro Hypervisor一起运行时,Nitro安全芯片除了为管理程序提供的系统硬件资产提供保护外,还提供深度防御。

系统启动或重置时的Nitro安全芯片

Nitro安全芯片还在系统启动或重置期间提供第二个关键安全功能。它控制服务器系统主板的物理复位引脚,包括其CPU和BMC(如果存在)。这使Nitro控制器能够完成自己的安全引导过程,然后在指示Nitro安全芯片释放主CPU和BMC以使其不被重置之前,验证基本输入/输出系统(BIOS)、BMC和所有其他系统固件的完整性。只有这样,CPU和BMC才能使用刚刚通过Nitro控制器验证的BIOS和固件开始启动过程。

Nitro虚拟机监控程序

Nitro Hypervisor是一个有限的、精心设计的组件,已被有意地最小化,并专门构建,具有执行其指定功能所需的功能,不再需要。Nitro Hypervisor被设计为接收从Nitro控制器发送的虚拟机管理命令(启动、停止等),并通过PCIe将Nitro硬件接口(用于EBS和实例存储的NVMe块存储、用于网络的弹性网络适配器(ENA)等)提供的SR-IOV虚拟功能分配给适当的VM。

笔记

虽然Nitro体系结构的独特之处在于它不需要使用管理程序来提供软件定义的基础架构,但在大多数客户场景中,虚拟化是非常有价值的,因为它允许将非常大的服务器细分为多个实例(VM)同时使用,以及其他优势,如更快的资源调配。虚拟化配置中需要Hypervisor,以提供来宾和系统的隔离、调度和管理。因此,在这些常见场景中,Nitro Hypervisor在保护基于Nitro的EC2服务器方面发挥着关键作用。

在Nitro系统上构建的一些实例类型包括硬件加速器,它们都由AWS和第三方(如图形处理单元或GPU)构建。Nitro Hypervisor还负责将这些硬件设备分配给VM,从硬件错误中恢复,并执行无法通过带外管理接口执行的其他功能。

在Nitro Hypervisor中,根据设计,没有网络堆栈,没有通用文件系统实现,也没有外围设备驱动程序支持。Nitro Hypervisor的设计仅包括其任务所需的服务和功能;它不是一个通用系统,既不包括外壳,也不包括任何类型的交互式访问模式。与常规管理程序相比,Nitro管理程序的体积小且相对简单,这本身就是一个显著的安全优势。

Nitro Hypervisor代码是一个托管的、加密签名的类似固件的组件,存储在连接到Nitro控制器的加密本地存储上,因此链接到Nitro控制器的硬件信任根。当系统配置为使用Nitro虚拟机监控程序时,Nitro控制器以类似于固件的方式将虚拟机监控代码的已知良好副本直接加载到系统主板上。

笔记

此虚拟机监控程序注入过程的机制是使用Nitro控制器提供给主板的只读NVMe设备作为系统引导驱动器。

将数据处理和I/O虚拟化卸载到分立硬件,并减少在主机CPU上运行的管理程序的责任,这是Nitro系统设计的核心。它不仅通过隔离提供了改进的性能和更强的安全性,还支持EC2的裸机实例类型功能,因为管理程序现在是一个可选的分立组件,不再需要它来提供I/O虚拟化、系统管理或监视。

笔记

Nitro系统通过在Nitro卡上而不是在主机的系统主板CPU上运行虚拟化系统的几乎所有功能,实现了有效的“裸机”性能。请参阅AWS Nitro系统的裸金属性能。

Nitro Hypervisor对非必要功能的严格排除消除了其他Hypervisor可能遭受的各种错误,例如远程网络攻击或基于驱动程序的权限升级。即使Nitro Hypervisor中存在允许访问特权代码的错误,但由于缺少标准操作系统功能(如交互式shell、文件系统、通用用户空间实用程序、,或获得可促进较大基础设施内横向移动的资源。

例如,如前所述,Nitro Hypervisor没有网络堆栈,也无法访问EC2网络。相反,Nitro控制器和其他Nitro卡调解对外部网络的所有访问,无论主服务器处理器是运行Nitro Hypervisor还是以裸机模式运行。此外,正如下面详细讨论的,Nitro的被动通信设计意味着任何试图从在管理程序环境中运行的代码到Nitro卡的“扩展”都将被拒绝和警告。

Nitro Hypervisor的更新过程

维护系统安全的一个关键方面是例行更新。Nitro Hypervisor允许全系统实时更新。当Nitro Hypervisor的新版本可用时,将替换完整运行的Hypervisor代码,同时保留客户EC2实例,对这些实例的性能几乎没有影响。这些更新过程的设计使得任何时候都不需要放弃或放松Nitro系统的任何安全协议或防御。此整体实时更新功能旨在为客户的实例提供零停机时间,同时确保不仅可以定期快速应用新功能,还可以快速应用安全更新。

客户实例停机时间与Nitro系统组件更新的分离消除了EC2服务在计划系统更新时仔细权衡客户体验和潜在安全影响之间的需要,从而提高了安全性。

本文地址
https://architect.pub
SEO Title
AWS The Security Design of the AWS Nitro System --The components of the Nitro System

【云安全】AWS Nitro系统的安全设计 --Nitro系统上下文安全

QQ群

视频号

微信

微信公众号

知识星球

Chinese, Simplified

本文中讨论的Nitro系统设计功能是在AWS的全套强大控制的背景下运行的,以维护AWS云中的安全和数据保护。在本节中,我们将对相关AWS安全和合规实践进行高级概述。作为AWS客户,您继承了AWS政策、体系结构和运营流程的所有最佳实践,以满足我们最安全敏感客户的要求。

AWS环境不断接受审计,并获得来自不同地区和垂直行业的认证机构的认证。如果需要,AWS前哨站还为客户提供了在位于自己设施内的基于Nitro System的硬件上本地运行AWS计算、存储、数据库和其他服务的能力。

基础设施安全

AWS的安全始于我们的核心基础设施,即运行AWS云服务的硬件、软件、网络和设施。我们为云定制,旨在满足世界上最严格的安全要求,我们的基础设施全天候监控,以帮助确保客户数据的机密性、完整性和可用性。使用AWS,您可以建立在最安全的全球基础设施上,知道您始终拥有客户数据,包括加密、移动和管理保留的能力。

物理访问

专业安全人员使用视频监控、双因素和生物特征认证、入侵检测系统和其他电子手段,对AWS数据中心的物理访问进行严格控制,无论是在周界还是在建筑物入口。授权员工必须至少通过两次双重身份验证才能访问数据中心楼层。所有访客都必须出示身份证明,并由授权人员签字并持续陪同。AWS仅向有合法业务需要的员工和承包商提供数据中心访问和信息。

当员工不再需要这些特权时,即使他们继续是亚马逊或亚马逊Web服务的员工,其访问权限也会立即被撤销。AWS员工对数据中心的所有物理访问都会定期记录和审核。

媒体净化

AWS将用于存储客户数据的媒体存储设备分类为“关键”。AWS对如何安装、维修和最终销毁不再有用的设备制定了严格的标准。当存储设备达到其使用寿命时,AWS使用NIST 800-88中详述的技术停用介质。存储客户数据的介质在安全停用之前不会从AWS控制中删除。

数据保护

通过AWS全球网络(连接我们的数据中心和地区)传输的所有数据在我们的安全设施之间传输之前,都会在物理层自动加密。还存在其他加密层;例如,所有区域间VPC对等流量以及客户或服务到服务TLS连接。我们提供的工具允许您在传输和休息时轻松加密客户数据,以确保只有授权用户才能使用AWS KMS管理的密钥访问,或使用FIPS 140-2 Level 3验证HSM使用AWS CloudHSM管理加密密钥。

我们还为您提供所需的控制和可见性,以帮助您遵守区域和本地数据隐私法律法规。我们全球基础设施的设计允许您选择客户数据所在的地区,帮助您满足数据驻留要求。

本文地址
https://architect.pub/aws-security-design-aws-nitro-system-nitro-system-security-context
SEO Title
AWS The Security Design of the AWS Nitro System --Nitro System security in context

【云安全】AWS Nitro系统的安全设计 --Nitro系统之旅

QQ群

视频号

微信

微信公众号

知识星球

Chinese, Simplified

Nitro系统是多年来为AWS云基础设施重新构想虚拟化技术的产物。在这一过程中,虚拟化技术的每个组件都得到了重新实施和替换。虽然客户在这个过程中看到了早些时候发布的EC2实例的成本、性能和安全性的提高,但基于最终的完整Nitro系统(其中每个组件都已更换)的实例与以前的实例类型有着显著的不同。Nitro系统为Amazon EC2的客户提供了增强的安全性、保密性和性能,并为快速交付新的创新技术提供了基础。

Nitro系统的引入包括将通用数据中心CPU上Dom0中运行的软件组件逐步分解为独立的专用服务处理器单元。最初是一个紧密耦合的单片虚拟化系统,一步步转变为专门构建的微服务体系结构。从2017年引入的C5实例类型开始,Nitro系统完全消除了对EC2实例上Dom0的需求。相反,基于KVM的定制开发的最小化管理程序提供了一个轻量级的VMM,同时将以前由Dom0中的设备模型执行的其他功能卸载到一组分立的Nitro卡中。

A diagram depicting Nitro System virtualization architecture.

Nitro System virtualization architecture

 

本文地址
https://architect.pub
SEO Title
AWS The Security Design of the AWS Nitro System --The Nitro System journey

【云安全】AWS Nitro系统的安全设计 --将工件放在一起:EBS卷附件

QQ群

视频号

微信

微信公众号

知识星球

Chinese, Simplified

为了更好地了解Nitro系统的多个部分一起运行,让我们来回顾一下当客户发出公开的EC2API调用以更改其在Nitro上的EC2实例的运行状态时会发生什么。特别是,我们将研究客户将现有加密EBS卷附加到正在运行的实例的情况。

在第一步中,客户使用AWS命令行界面(AWS CLI)、AWS SDK或AWS管理控制台以实例为目标调用AttachVolume命令。验证客户的IAM身份是否经过验证并被授权执行AttachVolume命令后,API调用由EC2和EBS控制平面内的一组微服务处理。最后,控制平面服务调用由Nitro控制器提供的一组定义的加密、认证的网络API,其中包含分配附加卷所需的资源所需的信息。此操作涉及多个服务,每个微服务都有各自的职责,限制了对Nitro Controller API的访问范围。

EC2控制平面为EBS分配Nitro卡的PCIe设备资源,这些资源用于逻辑EBS卷的读写服务(虚拟化实例的NVMe虚拟功能或裸机实例的NVMe物理功能)。EBS控制平面提供连接到EBS服务器所需的信息,EBS服务器通过网络存储加密卷数据,还提供存储为卷元数据的卷数据密钥的加密副本。加密数据密钥受AWS密钥管理服务(AWS KMS)内部的AWS KMS密钥保护;因此,作为附加卷过程的一部分,加密密钥必须发送到AWS KMS进行解密。

假设发出AttachVolume命令的客户IAM身份也被授权使用预期的AWS KMS密钥在AWS KMS中发出Decrypt命令,则加密卷的数据密钥将被解密。Nitro系统对此操作的访问受到AWS KMS授权和IAM转发访问会话的保护。(请参阅AWS副总裁兼杰出工程师Colm MacCárthaigh在演讲中关于弹性负载平衡、AWS证书管理器和AWS密钥管理服务的IAM前向访问会话的解释。)

总之,这些机制以密码方式确保Nitro系统只有在客户最近授权并验证了该访问时才被授予使用客户的AWS KMS管理密钥的权限。Nitro系统不允许在临时基础上使用AWS KMS管理的密钥,或者没有最近的客户授权。

在AWS KMS内部解密后,在使用加密传输层安全(TLS)网络连接发送到Nitro控制器之前,AWS KMS使用公钥再次加密数据密钥,该公钥用作单个生产Nitro主机服务器的加密数字标识。EBS控制平面将该公钥与加密卷的数据密钥一起发送给AWS KMS。因此,除了通过TLS在网络上加密整个消息之外,数据密钥也在网络上双重加密的消息中不对称加密。只有具有特定客户计算环境的特定生产主机的Nitro卡具有解密加密数据密钥所需的私钥。一旦本地解密,在卷连接和使用期间,该明文数据密钥仅存储在单个Nitro卡的易失性存储器中。

现在,Nitro EBS卡已准备好通过NVMe接口的PCIe附件将EBS卷呈现给EC2实例。当主机配置为使用Nitro Hypervisor时,Nitro控制器通过PCIe接口发送一条消息,指示Nitro Hypervisor将该EBS卷的NVMe虚拟功能分配给相应的EC2实例。然后,管理程序向VM发送虚拟硬件热插拔事件,以警告客户提供的系统软件有新的NVMe块设备可用。在裸机实例的情况下,EBS的Nitro卡直接向服务器处理器发出PCIe热插拔事件的信号,并且在处理器上运行的客户提供的系统软件与在任何其他服务器上一样处理NVMe设备的PCIe热插拔。

此时,作为虚拟客户机或裸机实例运行的客户实例操作系统通过PCIe接口与Nitro Card for EBS提供的NVMe设备交互。这种交互在虚拟化EC2实例的情况下作为SR-IOV功能发生,或者在裸机EC2实例情况下作为PCIe物理功能发生。通过PCIe接口发送的NVMe命令由运行在用于EBS的Nitro卡上的固件处理,该固件又通过Nitro SoC的集成网络接口与EBS服务交互。而且,如前所述,Nitro EBS卡还能够卸载AES-256 XTS加密EBS卷的加密操作,以便在离开Nitro卡之前,对每个客户数据块进行完全加密,而不会影响性能。客户还可以选择在操作系统级别使用加密文件系统,以便在将所有客户数据写入或传输到用于EBS的Nitro卡之前对其进行完全加密。这种方法还为在线和EBS存储系统中的EBS数据建立了额外的加密层。

本文地址
https://architect.pub/aws-security-design-aws-nitro-system-putting-pieces-together-ebs-volume-attachment
SEO Title
AWS The Security Design of the AWS Nitro System --Putting the pieces together: EBS volume attachment

【云安全】AWS Nitro系统的安全设计 --无AWS操作员访问

QQ群

视频号

微信

微信公众号

知识星球

Chinese, Simplified

根据设计,Nitro系统没有操作员访问权限。没有任何系统或人员登录EC2 Nitro主机、访问EC2实例的内存或访问存储在本地加密实例存储或远程加密EBS卷上的任何客户数据的机制。如果任何AWS操作员(包括具有最高权限的操作员)需要在EC2服务器上执行维护工作,他们只能使用一组经过验证、授权、记录和审核的管理API。这些API都没有为操作员提供在EC2服务器上访问客户数据的能力。由于这些都是在Nitro系统中设计和测试的技术限制,AWS操作员无法绕过这些控制和保护。

与大多数工程决策一样,选择在没有操作员访问机制的情况下设计Nitro系统需要权衡。在极少数情况下,可能会出现微妙的问题,因为我们的生产硬件上没有通用的访问功能,AWS操作员无法就地调试。在这种罕见的情况下,我们必须根据客户的要求与他们合作,在专用的非生产Nitro调试硬件上重现这些微妙的问题。这可能比我们的运营商能够就地调试更不方便,但我们坚信这对我们的客户来说是更好的选择。因此,我们必须在产品发布之前坚持系统质量和测试的最高标准。

本文地址
https://architect.pub/aws-security-design-aws-nitro-system-no-aws-operator-access
SEO Title
AWS The Security Design of the AWS Nitro System --No AWS operator access

【云安全】AWS Nitro系统的安全设计 --结论

QQ群

视频号

微信

微信公众号

知识星球

Chinese, Simplified

AWS Nitro系统提供了一套独特的功能,使其能够在多租户、超大规模的云环境中支持最敏感的工作负载。这些功能基于AWS对定制硅和相关固件的投资,以创建专门针对该定制硅的虚拟化堆栈。自2018年初以来,所有新的Amazon EC2实例类型都基于AWS Nitro系统,为客户提供了本文中讨论的所有安全性和其他好处。鉴于这些深厚的技术投资和AWS在工作负载隔离方面的出色记录,客户可以依靠AWS计算环境为其最敏感的工作负载提供卓越的安全性。

本文地址
https://architect.pub/aws-security-design-aws-nitro-system-conclusion
SEO Title
AWS The Security Design of the AWS Nitro System --Conclusion

【云安全】AWS Nitro系统的安全设计 --被动通信设计

QQ群

视频号

微信

微信公众号

知识星球

Chinese, Simplified

AWS Nitro系统遵循“无源通信”设计原则。这意味着,在生产操作期间,系统的组件从不启动出站通信,包括到任何控制平面、管理或云服务的通信。相反,有一个单一的强化的可信服务在网络上侦听,它们侦听网络或系统总线上的命令,根据这些命令采取行动,然后通过定义良好的API返回结果,这些API具有范围向下的访问控制。这些通信路径的两侧还执行参数验证,以确保仅发送和接收有效参数。

此模式从管理程序本身开始。它通过PCIe在专用信道上等待来自Nitro控制器的命令。它从不启动与Nitro系统其余部分的出站通信。它无法启动任何出站网络连接,因为如前所述,它没有网络堆栈。如果在任何时候通过一系列不太可能的动作,Nitro管理程序应尝试启动与其他Nitro系统组件的通信,则这种情况将是固件缺陷或可能的系统损坏的明显信号,并且EC2服务被设计为相应地做出反应,以防操作员响应受到影响和发出警报。

笔记

在裸机模式下,服务器处理器上没有运行管理程序来等待Nitro控制器发出的启动、停止或重置主机服务器的指令。在这种情况下,Nitro控制器通过其专用BMC连接和Nitro安全芯片控制主板。

被动通信模型在硝基系统的下一层重复。Nitro控制器在安全网络信道上侦听,等待EC2控制平面调用的特定API形式的认证和授权命令。Nitro控制器从不启动EC2控制平面网络上的任何出站通信。甚至逻辑上的“推送”功能(如发布主机上运行的EC2实例的CloudWatch度量,或将Nitro API日志发送到EC2控制平面)也被实现为“拉”过程。控制平面定期轮询Nitro控制器,以使用定义良好的API检索度量。任何尝试从Nitro控制器进行出站通信的行为都将是固件错误或可能的系统损坏的明确信号,EC2服务将据此做出反应,以防止对操作员响应的影响和警报。

被动通信模式的净效应是高度隔离和安全。由于正常操作仅涉及监听定义明确的参数验证消息,并使用定义明确的、参数验证的响应对其进行响应,因此该系统旨在明确识别和警告潜在的异常活动。该系统的设计使得,在系统主板出现固件错误的情况下,很可能会检测到、阻止和警告试图从系统主板向外逃到Nitro卡的潜在对手。此外,即使在极不可能发生的情况下,前一种情况下的潜在对手能够逃离系统主板并以某种方式访问硝基卡,硝基系统的设计再次使得该对手逃离硝基卡的任何尝试都很有可能因同样的原因被检测、阻止和警报。这些多层防御不仅保护EC2服务本身,还保护在EC2系统内运行工作负载的所有客户。

本文地址
https://architect.pub/aws-security-design-aws-nitro-system-passive-communications-design
SEO Title
AWS The Security Design of the AWS Nitro System --Passive communications design

【云安全】AWS Nitro系统的安全设计 --防止侧通道的EC2方法

QQ群

视频号

微信

微信公众号

知识星球

Chinese, Simplified

自成立以来,EC2一直采用保守的方法为客户设计和操作安全的多租户系统。我们的设计方法支持简单可靠的抽象,它在安全域之间提供了强大的隔离,并限制了客户之间关键系统资源的共享。AWS设计我们的系统,不仅可以针对已知的安全威胁提供纵深防御,还可以避免不具备已知实用开发技术的潜在安全问题的影响。除了我们在生产中采用的经过彻底测试和完善的安全机制外,AWS还积极参与最前沿的安全研究,以确保我们不仅保持最新状态,而且代表客户积极寻找安全问题。

在过去几年中发表的微结构侧通道领域的研究和披露已经将围绕这一主题的担忧推到了最前沿。旁道是一种机制,通过对从计算机系统收集的间接数据进行分析,有可能泄露计算机系统中的秘密信息。这种间接数据的一个示例可以是系统对输入进行操作所需的时间量。在某些情况下,尽管系统从未直接披露秘密数据,但外部方可能能够通过仔细分析处理精心选择的输入所花费的时间差异来确定该秘密的价值

笔记

这种情况的一个简单示例是一个程序,它接收字符串形式的密码作为输入,并验证该字符串是否与机密值匹配。该程序一次一个字符地分析所提供的字符串,将每个字符与机密的对应字符进行比较,并在遇到不匹配时立即返回错误。尽管程序从未向请求者提供秘密的值,但对于以一个或多个与秘密相同的字符开头的输入,程序会以不同的响应时间的形式“泄漏”有关秘密的信息。通过一个系统的试错过程,观察者可以测量响应某些输入所花费的时间,以便一次确定一个字符的秘密值。

仔细部署应对措施,如AWS的开源SSL/tls实现s2n tls所采用的应对措施,可用于防止这些形式的侧信道数据泄露。

仔细部署应对措施,如AWS的开源SSL/tls实现s2n tls所采用的应对措施,可用于防止这些形式的侧信道数据泄露。

笔记

s2n-tls结合并证明了使用形式化方法的时间平衡对策,以确保过程计时受机密的影响可以忽略不计,因此攻击者可观察到的计时行为不会依赖于机密。有关s2n tls中的这些对策以及这些对策的正式证明的更多信息,请参阅SideTrail:验证密码系统的时间平衡。

微体系结构侧通道特别涉及在某些情况下对系统处理器的低级行为的操纵,以允许在该系统上运行的一个进程通过系统资源(如缓存、内部缓冲区和其他不允许直接访问的有状态数据源)间接地确定秘密数据的值。关键的是,这些副通道围绕着两个系统之间共享对低级硬件资源的访问。

AWS对EC2租户隔离采用了一种保守的方法,这将在后面的章节中讨论,其设计目的是使客户实例永远无法共享系统资源,例如L1/L2缓存或在同一CPU复合体上运行的线程。这种基本的设计选择排除了通过基于租户之间共享访问这些资源的微架构侧通道从客户实例泄漏数据的可能性。

更广泛的EC2服务中的侧通道保护

所有EC2实例都包含对侧信道的强大保护。这包括基于Nitro系统或Xen管理程序的两个实例。虽然本节讨论了Nitro系统的这些保护,但这些保护也存在于基于Xen的EC2实例中。

虚拟化EC2实例类型分为两类:

  • 固定性能实例,其中CPU和内存资源在主机上的虚拟化实例的生命周期内预先分配并专用于该实例
  • 突发性能实例,其中CPU和内存资源可以被过度使用,以支持在服务器上运行的大量虚拟化实例,从而为客户提供了CPU利用率低到中等的应用程序的相对实例成本。请参阅Burstable性能实例。

无论哪种情况,Nitro Hypervisor的设计和实现都包括对潜在侧通道的多重保护。

对于固定性能的实例,与其他虚拟机管理程序相比,专用资源既提供了对侧通道的自然保护,又提供了更高的性能。例如,一个c5.4xlarge实例分配了16个虚拟CPU(八个内核,每个内核提供两个线程)以及32 GiB的内存。当实例启动时,EC2控制平面指示Nitro控制器分配必要的CPU、内存和I/O资源以支持该实例。

Nitro管理程序由Nitro控制器指导,为实例分配全部物理内核和内存。这些硬件资源被“固定”到该特定实例。CPU内核不用于运行其他客户工作负载,也不以任何方式在实例之间共享任何实例内存页,这与许多管理程序不同,这些管理程序可以合并重复的数据和/或指令页以节省物理内存。

即使在资源有限的非常小的Nitro EC2实例上,CPU内核也不会通过同时多线程(SMT)在两个客户实例之间同时共享。客户实例提供了两个vCPU的倍数,对于采用SMT的处理器,代表单核的两个线程,对于使用专用全核线程的处理器配置(例如AWS Graviton处理器),代表单vCPU。不共享内核意味着不共享1级或2级缓存或其他特定于内核的资源,如推测执行或节能状态。

某些实例大小可以非同时共享某些最后一级缓存行。虽然可以将最后一级缓存线的启动和探测作为一个超低带宽信号在两个协作进程之间使用,但这与实际的侧通道不同。由于其功能,在最后一级缓存行中只引用相对较少访问的数据。侧信道通常需要非常大且统计上相关的样本数量,以克服系统中存在的噪声。

与EC2一样,当内存页不在实例之间共享时,还没有演示过实际的攻击。迄今为止,所有实用的微体系结构侧通道攻击都使用了通过SMT或共享L1/L2缓存的共享内核,或其他低级内核属性(如浮点单元)。在EC2中,侧信道攻击缓解措施非常强大,因为这些资源从未在EC2 Nitro环境中共享。

笔记

EC2准确地暴露了硬件的底层CPU拓扑,包括最后一级(通常为L3)缓存和非统一内存访问(NUMA)信息,直接传递到实例。因此,客户可以通过检查来确定分配了多大大小的实例,即“填充”共享L3缓存的一个或多个CPU段所需的CPU内核数量;从而确定给定实例是否与另一实例共享任何L3高速缓存。三级缓存共享拓扑在CPU设计之间有所不同,并且可以在核心、CPU复合体或核心复合体裸片之间共享,具体取决于处理器架构。例如,在典型的基于Intel的双插槽EC2系统中,一个大小为最大大小一半的实例将填充CPU内核,并且不会与另一个实例共享L3缓存。

如前所述,突发性能EC2实例(例如,T3、T3a和T4g)可以利用过度使用的CPU和内存资源。运行突发性能实例所需的CPU资源根据基于信用的分配进行调度。在这种低成本但相对高性能的实例系列中,即使是最小的实例类型,在使用SMT的处理器上,仍然为客户提供至少两个vCPU(一个内核,两个线程)。

然而,两个可突发性能EC2实例可以在同一内核上顺序(而不是同时)运行。物理内存页也可以作为虚拟内存页进行重用、重新映射和交换。然而,即使是可突发的实例也不会同时共享同一个内核,虚拟内存页也不会在实例之间共享。

Nitro Hypervisor在实例之间的每个上下文切换处使用了许多安全策略,以确保在同一内核上运行另一个实例之前,删除前一个实例的所有状态。这种做法对可能的侧信道攻击提供了强有力的缓解措施。

对于突发性能EC2实例,Nitro系统可以采用内存管理技术,例如将物理内存重新使用、重新映射或交换为虚拟内存页,但该系统的设计使得虚拟内存页不会在实例之间共享,以保持强隔离边界。

最后,可突发性能实例——无论是目标性能实例还是通过侧信道技术检测数据的实例——都可以在不同于以前使用的内核上重新调度,从而进一步限制任何类型基于时间的成功安全问题的可能性。

Nitro系统的附加副通道优势

除了EC2为Xen和Nitro提供的保护外,在涉及侧信道问题时,Nitro系统和NitroHypervisor的设计中还有一些不明显但非常重要的好处。例如,虽然一些管理程序需要进行大量更改以实现地址空间隔离,作为L1终端故障瞬时执行侧通道攻击缓解措施的一部分(例如,请参阅针对L1终端故障的Hyper-V HyperClear缓解措施),但Nitro系统的设计和实现提供了自然的免疫力,因为Nitro Hypervisor的虚拟地址空间与分配给客户实例的内存隔离。

我们还应用了从设计Nitro系统中学到的知识,以减轻社区版Xen管理程序中微架构侧通道攻击的新威胁。请参阅在没有直接映射的情况下运行Xen。

如前所述,Nitro系统大大减少了运行在主服务器处理器上的EC2系统代码量,这大大缩小了管理程序的攻击面,并将客户I/O数据处理与系统的其他部分隔离开来。提供EC2的软件定义I/O功能所需的AWS代码不在运行客户工作负载的处理器上运行。

专用硬件的这种划分和使用意味着I/O子系统中的客户数据处理在硬件功能级别上是隔离的,并且不驻留在主机内存、处理器缓存或其他内部缓冲区中,这与通用虚拟化软件不同,通用虚拟化软件将这些数据混合在一起,作为在共享主机CPU上运行的副作用。

所有这些保护措施的基础是AWS处于安全研究的前沿,经常领导研究和发现影响行业的问题,以及缓解和协调问题。

Nitro胶囊

Nitro Enclaves是Nitro系统的一个功能,它允许客户将其工作负载划分为独立的组件,这些组件不需要彼此完全信任,同时也是运行高度信任的代码和处理客户EC2实例管理员无法访问的数据的一种方式。本文没有介绍它的特点和优点,但以下内容值得注意。

Nitro Enclave继承了与运行在同一服务器处理器上的每个其他EC2实例相同的隔离和侧通道缓解措施。父实例必须分配固定数量的vCPU(最小数量等于一个完整内核)以及固定数量的内存页。该固定的CPU和内存资源集从父实例中减去(使用Linux和Windows内核中支持的“硬件资源热插拔”功能),然后由Nitro Hypervisor用于创建另一个完全受保护的独立VM环境,在其中运行Nitro Enclave映像。

当使用Nitro Enclaves时,上面讨论的所有保护都会自动到位,因为没有与父实例共享内核或内存。

关闭侧频道的想法

总之,Nitro和EC2平台中谨慎的设计决策提供了一系列非常有力的缓解措施,以防止实际的侧通道攻击,包括删除这些攻击所需的CPU和内存资源实例之间的共享访问。此外,客户可以选择不将其实例与属于其他客户的实例配置在同一主机上。此外,如果任何未来的研究发现新的挑战,AWS参与针对Linux、KVM、Xen和其他关键技术的协调漏洞响应小组,以及Nitro系统的实时更新技术设计,将使AWS能够快速做出反应,保护客户免受新的威胁,而不会干扰客户的工作负载。AWS是在公开披露之前从事Spectre和Meltdown项目的一小部分公司的成员,并在公开披露前减轻了其基础设施中的所有风险。

笔记

通过使用EC2的“专用实例”或“专用主机”功能,客户可以选择不与其他客户共享计算硬件。这些特性表示实例放置策略,该策略导致单个客户在任何给定时间都是唯一的客户,并且实例调度在特定的EC2物理主机上。请参阅Amazon EC2专用主机。

我们继续与Intel、AMD和ARM等关键合作伙伴合作,进行硬件安全研究和协调漏洞响应,并继续通过计算机隔离的其他创新提高标准。一个这样的例子是开源的Firecracker VMM,它使无服务器容器和基于功能的服务(如AWS Fargate和AWS Lambda)能够从虚拟化的安全性、隔离性和一致性中获益,而不会影响客户对这些工作负载所需的速度、灵活性和性能。

笔记

Firecracker是一种虚拟化技术,专门用于创建和管理安全的多租户容器和基于功能的服务。Firecracker是一种虚拟机监视器,用于管理轻量级microVM中的工作负载。它实现了一个最小的设备模型,排除了所有非必要的功能,并减少了microVM的攻击面积。除了采用的安全性和隔离优化外,Firecracker还可以在短短125ms内快速启动用户空间或应用程序代码,并为每个microVM提供低至5 MiB的内存开销。

旁道问题是一个不断发展的研究领域,并由此产生了创新和缓解措施。我们相信,依靠AWS凭借其深厚的专业知识和对这一主题的持续关注,是客户在防范未来风险方面下注的好地方。

笔记

请参阅AWS副总裁兼杰出工程师Eric Brandwine关于侧渠道问题的演示。在演讲中,他谈到了从Xen到Nitro的过渡(42.40)及其带来的优势,但也重要地指出,这一主题已经成为一个类似密码学的主题,其中最合理的方法是依赖深度专家并重用他们的工作(49.29)。

本文地址
https://architect.pub/aws-security-design-aws-nitro-system-ec2-approach-preventing-side-channels
SEO Title
AWS The Security Design of the AWS Nitro System --The EC2 approach to preventing side-channels

【云安全】AWS Nitro系统的安全设计 -传统虚拟化入门

QQ群

视频号

微信

微信公众号

知识星球

Chinese, Simplified

虚拟化在高级别上使单个物理计算机系统能够同时运行多个操作系统。虚拟化系统(“主机”)实现了转换、仿真和限制功能,使其能够为一个或多个虚拟化操作系统(“客户机”)提供其自身独立硬件(“虚拟机”或“VM”)的虚拟表示。换句话说,虚拟化主机。虚拟化的主要好处之一是能够通过在多个虚拟机之间分配其资源来高效利用单个功能强大的服务器,每个虚拟机都分配了最适合其分配任务的资源量。

笔记

本节中对虚拟化的讨论提供了对该主题的一般性的高级介绍,并没有深入到Paravirtualization之类的主题,在Paravirtualization中,必须修改来宾软件才能在虚拟化环境中运行。有关虚拟化技术的更详细入门知识,请参阅AWS副总裁兼杰出工程师Anthony Liguri的虚拟化技术演示

负责管理虚拟化系统中来宾虚拟机(VM)的生命周期和操作的核心组件称为虚拟机监视器(VMM)或管理程序。对于它执行的大多数统计操作,客户机在系统的物理CPU上本地运行指令,而不需要VMM的任何参与。例如,当客户试图计算两个值的和或积时,它可以直接与系统的CPU硬件通信,以发出必要的机器代码指令。

然而,有些敏感或特权指令,例如从CPU控制寄存器读取或写入,不应允许访客直接在CPU硬件上运行,以保持系统整体的稳定性和隔离。当客户机试图向CPU发出这些指令中的一条而不是运行时,该指令将被重定向到VMM,VMM将模拟该指令的允许结果,然后将控制权返回给客户机,就像该指令是在CPU上本地执行的一样。

VMM本身是一个相对简单的软件。然而,虚拟化主机需要的不仅仅是VMM的核心功能,以便为来宾提供对网络接口、存储驱动器和输入外围设备等设备的访问。为了提供这些功能,主机依赖于称为设备模型的附加软件组件。设备模型与系统的共享物理I/O硬件通信,并模拟暴露给客户VM的一个或多个唯一虚拟设备接口的状态和行为。

Hypervisor通常使用通用操作系统来与各种系统硬件接口,运行设备模型,并运行虚拟化系统的其他管理软件。此操作系统通常被实现为一个特殊的特权虚拟机,例如,Xen项目调用系统的dom0,Hyper-V调用系统的根/父分区。在早期的EC2实例中,这采用了一种特殊的AmazonLinuxVM的形式,在Xen术语中称为domain0或dom0。

A diagram depicting classical virtualization architecture.

本文地址
https://architect.pub
SEO Title
The Security Design of the AWS Nitro System --Traditional virtualization primer

【云安全】AWS Nitro系统的安全设计 -摘要和简介

QQ群

视频号

微信

微信公众号

知识星球

Chinese, Simplified

摘要

Amazon Elastic Compute Cloud(Amazon EC2)是一种web服务,在云中提供安全、可调整大小的计算能力。它旨在使开发人员更容易进行web规模的云计算。AWS Nitro系统是所有现代EC2实例的基础平台。本白皮书详细描述了Nitro系统的安全设计,以帮助您评估敏感工作负载的EC2。

介绍

每天,世界各地的客户都将他们最敏感的应用程序委托给Amazon Web Services(AWS)。在AWS,保持客户工作负载的安全和机密性,同时帮助他们满足安全、隐私和数据保护要求,是我们的首要任务。我们投资了严格的运营实践和安全技术,以满足甚至超过我们最苛刻的客户的数据安全需求。

AWS Nitro系统的开发是一个多年的旅程,旨在重塑Amazon EC2的基础虚拟化基础设施。自2006年推出亚马逊EC2测试版以来,我们不断完善、优化和创新服务的各个方面,以满足客户的需求。借助AWS Nitro系统,我们致力于戏剧性地重新构想虚拟化架构,以提供客户所需的安全性、隔离性、性能、成本和创新速度。

从第一天起,安全性就一直是该流程的基本原则,我们继续投资于设计的实施,作为我们持续改进方法的一部分,以不断提高客户的安全性和数据保护标准。AWS Nitro系统是专门构建的服务器设计、数据处理器、系统管理组件和专用固件的组合,为自2018年初以来推出的所有Amazon EC2实例提供了基础平台。AWS Nitro系统的有限和离散设计组件共同为EC2客户提供更快的创新、增强的安全性和改进的性能。

Nitro系统的三个关键组件实现了这些目标:

  • 专门构建的Nitro卡-AWS设计的硬件设备,提供独立于主系统板及其CPU和内存的整体系统控制和输入/输出(I/O)虚拟化。
  • Nitro安全芯片-基于硬件信任根、提供裸机实例的能力以及纵深防御,为整个系统提供安全引导过程,防止服务器未经授权修改系统固件。
  • Nitro虚拟机监控程序-一个故意最小化的、类似固件的虚拟机管理程序,旨在提供强大的资源隔离,性能几乎与裸机服务器无法区分。

笔记

这些组件是互补的,但不需要一起使用。

本文简要介绍了Nitro系统引入的虚拟化和基本架构更改。它讨论了Nitro系统的三个关键组件中的每一个,并通过将新的Amazon Elastic Block Store(Amazon EBS)卷添加到正在运行的EC2实例中来演示这些组件如何协同工作。白皮书讨论了Nitro系统在设计上如何消除管理员访问EC2服务器的可能性、Nitro的总体被动通信设计以及Nitro更改管理过程。最后,本文调查了EC2系统设计的重要方面,这些方面为计算环境中可能出现的潜在侧信道问题提供了缓解措施。

本文地址
https://architect.pub/security-design-aws-nitro-system-abstract-and-introduction
SEO Title
The Security Design of the AWS Nitro System --Abstract and introduction

OpenStack

Chinese, Simplified
SEO Title
OpenStack

【OpenStack】OpenStack和虚拟化:有什么区别?

Chinese, Simplified

如果你对OpenStack和虚拟化之间的区别感到困惑,你并不孤单。它们确实是不同的,本文将描述如何为OpenStack回顾一些实用的“良好匹配”用例,并最终消除关于这个不断增长的开源云平台的一些误解。

首先,有几点基本知识:

虚拟化源于分区,分区将单个物理服务器划分为多个逻辑服务器。通过提供计算资源的逻辑视图,而不是物理视图,可以做两件非常有用的事情:允许您“欺骗”您的操作系统,使其认为一组服务器是一个计算资源池,并允许您在一台机器上同时运行多个操作系统。一旦划分了物理服务器,每个逻辑服务器就可以独立运行操作系统和应用程序。

虚拟化提供了内置于基础架构中的冗余和高可用性,但增加容量以提高性能输出需要花费大量时间。获得更高的性能意味着通过添加更多内存和处理器来“向上扩展”或“垂直扩展”,以使物理虚拟机监控程序的性能更好——但在服务器硬件容量达到最大值之前,您只能添加这么多。

另一方面,云计算将重点从硬件消费转向共享资源即服务消费。OpenStack是一款开源软件,用于创建私有和公共云;i、 e.提供消费性服务,而不是硬件本身。云计算之所以具有吸引力,有几个原因,其中最重要的一个原因是它的实用模式,即只为你使用的东西付费,并且能够非常快速地增加或减少更多资源。

因为虚拟化已经存在了几十年,它提供了详细的参考体系结构和常见实践;另一方面,OpenStack提供了极大的灵活性,但伴随着这种灵活性,还有额外的责任:你必须告诉它你想要它做什么。对于一般的云计算,参考体系结构和常见做法仍在制定中。

运营OpenStack还需要一种不同的基础设施理念:采用DevOps,即运营和开发工程师从设计到开发过程再到生产支持的合作实践。DevOps的目标是创造一种文化和环境,让软件的构建、测试和发布更快、更可靠。

更多差异:

  • 云资源是不可知的,是可支配的,而虚拟化需要虚拟机的照料、喂养和培育。使用OpenStack,您可以告别重建和重新部署。
  • 云提供了自动化以前手动功能的能力——开箱即用。
  • 云实现了真正的自助服务,释放了您昂贵的资源,专注于提供业务价值。云让你的用户在需要的时候提供他们需要的东西。
  • 云生态系统是为最终用户设计的。

用例角色

  • 对于那些仍在总体上评估云计算的人,或者如果你不确定OpenStack是否适合你的业务需求,下面是一个简短的列表,其中列出了被证明适合OpenStack的用例角色:
  • 运行一个需要可扩展且面向客户的电子商务平台;
  • 运行多层分布式应用程序(工作负载);
  • 作为CI/CD管道的一部分运行开源开发工具;
  • 利用敏捷方法作为应用程序开发方法;
  • 公开面向客户的API,这些API需要根据负载进行扩展;
  • 寻求将遗留应用程序迁移到云平台和
  • 开始组织IT转型,以部署新应用程序。
  • 在权衡选择时,还需要记住以下几点:
  • OpenStack不是虚拟机监控程序。它是一个“虚拟机监控程序管理器”,旨在消除对硬件及其管理的担忧。
  • 灵活性就是力量——OpenStack从设计和部署方面提供的灵活性是所有基础设施管理员想要和需要的力量。
  • 自动化带来的进步——只有尽可能多地实现自动化,才能充分利用OpenStack带来的好处。

打破神话的OpenStack

最后,我想澄清我多年来听到的关于OpenStack的一些误解,其中许多与当今虚拟化平台上存在的一些功能直接相关。

误解:OpenStack不支持虚拟机或VM迁移。

事实:

  • 在OpenStack中,ProjectNova能够通过KVM(建议的虚拟机监控程序)从计算主机迁移或撤离实例。
  • 负责处理此问题的特定Nova组件是Nova调度程序。
  • 在迁移过程中可能会出现两秒钟的光点。

谬论:在OpenStack中,没有任何功能可以在整个云计算中平均消耗资源。

事实:

  • 如前所述,OpenStack确实具有实例迁移功能——但它不是一项自动智能任务;人们必须建立自动化来处理这项任务或手动执行。
  • 云与稳态计算:为可支配动态资源设计的应用程序,也就是云,不会因丢失计算节点和/或实例而受到影响。

误解:并非所有OpenStack存储解决方案都是分布式的。

事实:

  • OpenStack生态系统中的一个非常高级的功能和项目是Cinder,它提供了为块存储卷定义多个后端的功能。每个后端都可以指向本地临时存储或共享存储设备。
  • 这些后端也可以定义为卷类型;反过来,Nova是卷类型感知的。

误解:OpenStack不了解虚拟机监控程序的运行状况。

事实:

  • OpenStack只使用服务模型,即每个组件都被视为一个服务。这意味着OpenStack对其生态系统中运行的所有服务都有健康意识。
  • 如果计算节点或实例失败,OpenStack将不会尝试重新启动它;该服务将被标记为“关闭”,请求将继续由其他资源处理(请记住,云是关于可支配资源的)。

谬论:OpenStack中没有恢复数据的解决方案。

事实:

半真半假。通过Cinder和Swift等OpenStack项目,您可以无缝集成许多不同的外部存储设备。

但是,OpenStack通过分布式模型处理数据保存——重要数据不应存储在短暂的本地存储上,而应存储在某种类型的共享存储上(如EMC、NetApp、Pure)……这将是一种高可用性的解决方案。

谬论:在OpenStack中,如果你失去了一个计算节点,你的应用程序就会失败。

事实:

  • OpenStack具有可用于处理计算节点故障的保护措施。
  • Nova scheduler组件管理实例在多个计算节点之间的分布;将其视为资源的平衡。
  • OpenStack提供了几种机制来实现这一点,具体取决于它们的具体需求。例子包括:
    • ServerGroupAntiAffinityFilter筛选器
    • 可用区

原文:https://www.rackspace.com/blog/openstack-and-virtualization-whats-the-d…

本文:https://jiagoushi.pro/node/1923

SEO Title
OpenStack and Virtualization: What's the Difference?

【私有云平台】理解OpenStack

Chinese, Simplified

OpenStack®为您提供了一个模块化的云基础设施,使用标准硬件,您可以在需要时从一个地方部署所需的工具。

什么是OpenStack?

OpenStack是一个开源平台,它使用汇集的虚拟资源来构建和管理私有云和公共云。构成OpenStack平台的工具称为“项目”,处理计算、网络、存储、身份和图像服务等核心云计算服务。十几个可选项目也可以捆绑在一起,以创建独特的、可部署的云。

在虚拟化中,存储、CPU和RAM等资源是从各种特定于供应商的程序中抽象出来的,并在根据需要分发之前由虚拟机监控程序进行分割。OpenStack使用一组一致的应用程序编程接口(API)将这些虚拟资源进一步抽象为离散池,用于为管理员和用户直接交互的标准云计算工具提供动力。

OpenStack只是一个虚拟化管理平台吗?

不完全是。有很多相似之处,但它们不一样。

是的,OpenStack和虚拟化管理平台都位于虚拟化资源之上,可以在不同供应商的环境中发现、报告和自动化流程。

但是,虽然虚拟化管理平台使虚拟资源的特性和功能更容易操作,但OpenStack实际上使用虚拟资源来运行一系列工具。这些工具创建的云环境符合美国国家标准与技术研究所(National Institute of Standards and Technology)云计算的5个标准:网络、资源池、用户界面、资源调配能力和自动资源控制/分配。

OpenStack是如何工作的?

OpenStack本质上是一系列被称为脚本的命令。这些脚本被捆绑到名为projects的包中,这些包传递创建云环境的任务。为了创建这些环境,OpenStack依赖于两种其他类型的软件:

  • 虚拟化,创建一层从硬件抽象出来的虚拟资源
  • 执行OpenStack脚本给出的命令的基本操作系统(OS)

可以这样想:OpenStack本身并不虚拟化资源,而是使用它们来构建云。OpenStack也不执行命令,而是将它们转发到基本操作系统。OpenStack、虚拟化和基本操作系统这三种技术必须协同工作。这种相互依赖性就是为什么这么多OpenStack云使用Linux®部署的原因,Linux®是RackSpace和NASA决定将OpenStack作为开源软件发布的灵感来源。

OpenStack组件

OpenStack的架构由许多开源项目组成。这些项目分别用于设置系统管理员和云用户使用的OpenStack的undercloud和overcloud。Underclouds包含系统管理员设置和管理最终用户OpenStack环境所需的核心组件,称为overclouds。

有6个稳定的核心服务,处理计算、网络、存储、身份和图像,而十几个可选服务在开发成熟度上有所不同。这6个核心服务是基础设施,允许其他项目处理仪表板、编排、裸机资源调配、消息传递、容器和治理。

Nova

Nova是一个完整的管理和访问工具,用于处理OpenStack计算资源的调度、创建和删除。

Neutron

Neutron通过其他OpenStack服务连接网络。

Swift

Swift是一种高度容错的对象存储服务,它使用RESTful API存储和检索非结构化数据对象。

Cinder

Cinder提供了可通过自助API访问的持久块存储。

Keystone

Keystone对所有OpenStack服务进行身份验证和授权。它也是所有服务的端点目录。

Glance

Glance从不同的位置存储和检索虚拟机磁盘映像。

我能用OpenStack做什么?

私有云

在OpenStack上运行的私有云发行版可以提供比使用自定义代码构建的私有云更大的好处。IDC评估了 OpenStack平台对私有云的价值,发现企业实现了681万美元的年收益。

网络功能虚拟化

451项研究发现,使用OpenStack进行网络功能虚拟化(NFV)——这涉及分离网络的关键功能,以便它们可以分布在环境中——很可能是下一件大事。该分析师调查的几乎每一家全球通信服务提供商都把它列在议事日程上。

公共云

OpenStack是构建公共云环境的领先开源选项。无论你的公司是一家价值数十亿美元的上市企业还是一家初创企业,你都可以使用OpenStack建立公共云,并提供与主要公共云提供商竞争的服务。

容器

OpenStack是公有云和私有云的稳定基础。容器加快了应用程序交付,同时简化了应用程序部署和管理。在OpenStack上运行容器可以将容器的好处从单一的、孤立的团队扩展到企业范围的跨部门操作。

原文:https://www.redhat.com/en/topics/openstack

本文:https://jiagoushi.pro/node/1921

SEO Title
Understanding OpenStack

【数据中心】2023年全球数据中心市场比较

QQ群

视频号

微信

微信公众号

知识星球

Chinese, Simplified

关键要点

  • 数据中心市场继续快速增长,我们2023年的排名中估计在线容量为7.4吉瓦,而去年为4.9吉瓦。
  • 随着超大规模租户和主机代管提供商在全球范围内评估并宣布新项目,向二级市场和新兴市场迈出了重大步伐。
  • 电力供应变得越来越受限,尤其是在顶级市场。电力成本上升,我们这一系列市场的公用事业成本平均上涨了16%。
  • 尽管面临着激烈的土地竞争和可用电力不足的不利因素,但更大的市场仍在继续增长和表现。

3月8日,星期三,来自全球各地的戴德梁行数据中心专家齐聚一堂,讨论了这份报告,并揭示了全球每个地区最有趣的数据中心市场背后的关键驱动因素。

为了适应我们的全球时区,我们组织了两次会议。

global

Americans

APAC

 

EMEA

 

Cloud Availability

云服务已经成为租户、开发商和投资者对新市场感兴趣的战略决定因素。主要云服务的存在保证了未来需求的可扩展性,也验证了市场的基本面。在本报告中介绍的63个市场中,有34个现在提供了来自美国三大云服务的某种形式的存在,计划进行相当大的进一步扩张,并且已经在几个地方获得了土地。

market

Market Size

在新数据中心开发的规划、批准、建设和电力供应方面,大容量市场与地方政府和公用事业公司有着良好的合作关系。该指标能够衡量市场相对风险状况的一个组成部分,较大的市场代表较小的风险,而较小、更紧急的市场通常代表较高的风险。更大的市场规模也确保了现场员工、销售团队和其他辅助人力资本到位,以支持未来的发展。因此,最大的市场处于持续增长的位置,至少在当地电网出现容量紧张或政治需求改变之前是这样。

Market Size

Power Cost

数据中心运营费用的一个关键组成部分是本地电力成本。根据可用能源、基础设施和政府政策的不同,不同市场的电力成本可能差异很大。随着越来越大的部署变得普遍,电源成本及其可用性是数据中心开发人员的一个关键因素。在过去的一年里,随着许多市场的能源价格大幅上涨,这已成为可行性分析的一个备受讨论的领域。通货膨胀、供应链问题和地缘政治危机都导致了终端消费者的电力成本上升。虽然电力成本并不包括2022年出现的所有电力可用性问题,但它确实为市场比较提供了一个有用的指标。

Power Cost

美洲

2022年,北美成熟的核心市场开始感受到电力和土地有限带来的越来越大的压力。北弗吉尼亚州是世界上最大的数据中心市场,由于公用事业公司正在努力解决大规模的开发管道问题,某些子市场的开发出现了前所未有的多年停顿。因此,随着运营商寻求更大、电力更实惠的场地,人们对波特兰、菲尼克斯、哥伦布、加拿大市场等二级市场的兴趣越来越大。在更成熟的市场,如北弗吉尼亚州、硅谷、芝加哥、达拉斯和亚特兰大,仍有很大的势头,因为人们的目光转向了土地和电力可能更可用的未开发的次级市场。

01/ Northern Virginia*                 06/ Dallas
       Portland*                       07/ Phoenix
03/ Atlanta* 08/ Seattle
       Chicago* 09/ Toronto
       San Francisco Bay Area* 10/ Montreal
  • 01/ Northern Virginia*                     
  •  Portland*                     
  • 03/ Atlanta*      
  • Chicago*     
  •  San Francisco Bay Area*
  • 06/ Dallas
  •  07/ Phoenix
  • 08/ Seattle 
  • 09/ Toronto
  • 10/ Montreal

APAC

尽管由于某些地区缺乏可用的土地、电力供应和监管框架,该地区的顶级市场在2022年继续增长。顶级市场新加坡取消了暂停令,并制定了新的政策和参数,向能够满足政府新要求的精明开发商重新开放了这个关键市场。另一个关键趋势是,亚太地区对小型新兴数据中心市场的兴趣日益浓厚。其中包括曼谷、柔佛、海得拉巴、胡志明和马尼拉,所有这些都已加入我们2023年的选定市场名单。

01/ Singapore 06/ Beijing
02/ Hong Kong                       07/ Mumbai
03/ Sydney*                   08/ Shanghai
       Seoul* 09/ Melbourne
05/ Tokyo 10/ Kuala Lumpur

 

EMEA

尽管某些FLAP-D市场的发展阻力仍在继续,但所有这些市场在该地区仍处于领先地位。二级市场的增长是过去一年的标志之一,人们对马德里、米兰、苏黎世、柏林、华沙、奥斯陆、挪威和巴塞罗那等市场的兴趣与日俱增。随着官方法规的制定,阿姆斯特丹、法兰克福和都柏林等市场的政治阻力也变得更加明显,这些法规旨在减轻当地电网和土地的压力,同时激励可持续发展。随着该地区的整体发展活动继续增长,大市场和小市场的挑剔投资者仍有机会。

01/ Amsterdam 06/ London
02/ Paris                     07/ Frankfurt
03/ Zurich 08/ Stockholm*
04/ Madrid*        Oslo*
       Dublin* 10/ Berlin

 

本文地址
https://architect.pub/2023-global-data-center-market-comparison
SEO Title
2023 GLOBAL DATA CENTER MARKET COMPARISON

【数据中心】APAC 数据中心更新:H1 2023

QQ群

视频号

微信

微信公众号

知识星球

Chinese, Simplified

亚太地区*继续在一级和二级数据中心市场进行积极扩张,在该地区运营9.7GW,在建3.3GW,计划阶段8.5GW。

通常的一级市场,北京、香港、孟买、首尔、上海、悉尼和东京,尽管由于缺乏地块和电力供应而受到不利影响,但仍在继续增长。因此,作为扩张战略的一部分,正在对附属地点进行评估。暂停对新加坡IT能力的限制导致市场需求未得到满足,并蔓延到柔佛等近海市场,该市场正在开发一条巨大的管道,并承诺向土地银行提供资金。同样,大雅加达的大型管道是由其位于东南亚的中心地理位置推动的,该国巨大的人口增长保持了对主要投资者和运营商的吸引力。

全球云服务提供商(CSP)继续对整个地区的二级市场表现出明显的兴趣。超大型CSP计划在奥克兰、曼谷、釜山、吉隆坡、大阪、浦那和台北的二级市场开展业务。主机代管运营商、开发商和投资者倾向于跟随CSP进入新的领域,部署自己的数据中心,这将使二级市场吸引新的参与者,并在未来几年见证快速增长。

亚太数据中心地区正经历着不同的发展速度,因此,我们首次推出了亚太数据中心市场成熟度指数,以跟踪每个季度许多著名市场的演变。本报告将深入研究12个著名市场:东京、孟买、悉尼、新加坡、首尔、柔佛、雅加达、香港、马尼拉、曼谷、奥克兰和胡志明市。

APAC+DC+Markets+Maturity+Index+H1+2023_background_lores

*For all analysis, Asia Pacific region includes Australia, Mainland China, Hong Kong, India, Indonesia, Japan, Malaysia, New Zealand, Philippines, Singapore, South Korea, Taiwan, Thailand and Vietnam only.

 

本文地址
https://architect.pub/apac-data-centre-update-h1-2023
SEO Title
APAC DATA CENTRE UPDATE: H1 2023

【网络术语】网络术语汇编

Chinese, Simplified

基本网络术语汇编,与深入定义链接。

要找到您正在寻找的网络术语的简要定义,请使用浏览器的“查找”功能,然后按照链接进行更全面的解释。

5G

5G是用于企业物联网、IIoT和手机的快速蜂窝无线技术,可以将无线吞吐量提高10倍。

网络切片(Network slicing)

网络切片可以有效利用运营商的无线容量,实现完全符合客户需求的5G虚拟网络。

开放式RAN(O-RAN)

O-RAN是一项无线行业倡议,旨在使用软件定义技术和通用、供应商中立硬件设计和构建5G无线电接入网络。

波束赋形(Beamforming)

波束形成是一种将无线信号聚焦到特定接收设备的技术,而不是像广播天线那样使信号在所有方向上扩展。所产生的连接比没有波束形成的连接更快、更可靠。

数据中心

数据中心是企业用来存放关键业务应用程序和信息的物理设施,正在从集中式、本地设施发展到边缘部署和公共云服务。

超融合基础设施(HCI)

超融合基础设施将计算、存储和网络结合在一个系统中,经常用于数据中心。企业可以从单个供应商选择设备,也可以在白盒服务器上安装硬件无关的hyperconvergence软件。

防火墙

网络防火墙被创建为大多数组织的主要外围防御,但自创建以来,该技术已经催生了许多迭代:代理、有状态、Web应用、下一代。

下一代防火墙(NGFW)

下一代防火墙保护网络周界,包括在精细级别检查流量的功能,包括入侵防御系统、深度数据包检查和SSL检查,所有这些都集成到单个系统中。

互联网

互联网是一个全球计算机网络,使用互联网协议(IP)通过部署在合作网络中的交换机和路由器进行全球通信,该网络旨在有效地引导流量,并在互联网的某部分出现故障时提供弹性。

互联网主干网

一级互联网服务提供商(ISP)将其高速光纤网络融合在一起,以创建互联网主干网,从而在地理区域之间高效地传输流量。

IP地址

IP地址是一组唯一的数字或字母和数字的组合,分配给IP网络上的每个设备,使交换机和路由器能够将数据包传送到正确的目的地。

IPv6

IPv6是互联网协议的最新版本,它将可能的IP地址数量从IPv4可能的43亿扩展到340万亿,以便为可能连接到公共互联网的每个设备提供唯一地址。

物联网(IoT)

物联网(IoT)是一个连接的智能设备网络,为企业提供丰富的运营数据。这是一个综合术语,指越来越多的电子设备不是传统的计算设备,而是连接到互联网以收集数据、接收指令或两者兼而有之。

工业物联网(IIoT)

工业物联网(IIoT)连接工业中的机器和设备。它是在运输、能源和制造部门的机械和车辆上应用仪器和连接的传感器及其他设备。

工业4.0

工业4.0融合了各种技术,以创建更好地利用资源的定制工业解决方案。它将供应链和ERP系统直接连接到生产线,形成集成、自动化和潜在自主的制造流程,更好地利用资本、原材料和人力资源。

物联网标准和协议

围绕物联网的协议、标准和技术通常有一个难以理解的字母表,这是基本物联网术语的指南。

窄带物联网(NB-IoT)

NB IoT是一种为IoT设备设计的通信标准,可通过运营商网络在某些蜂窝服务使用的现有GSM带宽内、LTE信道之间未使用的“保护频带”内或独立运行。

IP

网际协议(IP)是管理通过IP网络发送的数据格式的一组规则。

DHCP

DHCP代表动态主机配置协议(dynamic host configuration protocol),这是一种IP网络协议,用于服务器在运行中自动分配具有IP地址的网络设备,并将其他信息共享给这些设备,以便它们可以与其他端点进行有效通信。

域名服务器

域名系统(DNS)将网站的公共名称与其基础IP地址进行解析,从而提高了效率,甚至提高了安全性。

IPv6

IPv6是互联网协议的最新版本,它可以识别整个互联网上的设备,以便定位它们,还可以更有效地处理数据包,提高性能并提高安全性。

IP地址

IP地址是一个数字或字母和数字的组合,用于标记连接到互联网协议用作通信介质的网络的设备。IP地址为IP网络上的设备提供了自己的身份,以便它们可以找到彼此。

网络管理

网络管理是管理和管理计算机网络的过程。

基于意图的网络

基于意图的网络(IBNS)是一种网络管理,它使网络管理员能够用简单的语言定义他们希望网络做什么,并让网络管理平台自动配置网络上的设备,以创建所需的状态并实施策略。

微分段

微分段是一种在网络、数据中心和云部署中创建安全区域的方法,它通过隔离分区,只有指定的用户和应用程序才能访问每个分段。

软件定义网络(SDN)

软件定义网络(SDN)是一种网络管理方法,可实现动态、编程高效的网络配置,以提高网络性能和监控。它通过将网络控制平面与数据平面分离来运行,从而实现网络范围内的更改,而无需手动重新配置每个设备。

网络安全

网络安全包括用于防止、检测和监控计算机网络和网络可访问资源上未经授权的访问、误用、修改或拒绝服务的策略、过程和实践。

基于身份的网络

基于身份的网络将用户的身份与用户可以接收的网络服务联系起来。

微分段

微分段是一种在网络、数据中心和云部署中创建安全区域的方法,它通过隔离分区,只有指定的用户和应用程序才能访问每个分段。

网络访问控制(NAC)

网络访问控制是一种计算机安全方法,试图统一端点安全技术、用户或系统身份验证和网络安全实施。

SASE

安全访问服务边缘(SASE)是一种网络架构,它将软件定义的广域网(SD-WAN)和安全性集成到云服务中,该云服务承诺简化广域网部署,提高效率和安全性,并为每个应用程序提供适当的带宽。

网络交换机

网络交换机是在OSI模型第2层的数据链路层上运行的设备。它接收连接到其物理端口的设备发送的数据包,并再次发送它们,但仅通过通向数据包预期到达的设备的端口。它们也可以在网络层-第3层进行路由选择。

开放系统互连(OSI)参考模型

开放系统互连(OSI)参考模型是一个用于结构化网络中任意两个实体之间传输的消息的框架。

以太网供电(PoE)

PoE是通过将网络设备连接到LAN的相同数据电缆向网络设备提供电力。这通过消除对电插头和电源转换器的需要而简化了设备本身,并且使得不需要在每个设备附近安装单独的交流电线和插座。

路由器

路由器是在计算机网络之间转发数据包的网络设备。路由器在OSI模型的第3层运行,并在组织内的子网之间和互联网上执行流量引导功能。

边界网关协议(BGP)

边界网关协议是一种标准化协议,用于在互联网上的大型自治系统之间交换路由和可达性信息。

UDP端口

UDP(用户数据报协议)是一种通信协议,主要用于在互联网上的应用程序之间建立低延迟和容错连接。它通过在接收设备同意连接之前实现数据传输来加速传输。

存储网络

存储网络是通过网络将外部存储资源互连到所有连接的计算机/节点的过程。

网络连接存储(NAS)

网络连接存储(NAS)是一种文件级存储,它连接到网络,支持跨异构客户端和服务器环境进行数据访问和文件共享。

非易失性快速内存(NVMe)

NVMe是专门为所有闪存开发的通信协议,与传统协议相比,它具有更快的性能和更高的密度。它适用于需要最高性能的企业工作负载,如实时数据分析、在线交易平台和其他延迟敏感工作负载。

存储区域网络(SAN)

存储区域网络(SAN)是一种专用的高速网络,提供对块级存储的访问。采用SAN是为了通过将存储流量与LAN的其余部分隔离来提高应用程序的可用性和性能。

虚拟化

虚拟化是创建虚拟版本的东西,包括虚拟计算机硬件平台、存储设备和计算机网络资源。这包括可以共存于同一硬件上但行为独立的虚拟服务器。

管理程序(Hypervisor)

管理程序是一种软件,它将计算机的操作系统和应用程序与底层物理硬件分离,允许在多个虚拟机之间共享硬件。

网络虚拟化

网络虚拟化是将具有网络功能的网络硬件和软件资源组合成一个基于软件的管理实体,称为虚拟网络。网络虚拟化涉及平台虚拟化,通常与资源虚拟化相结合。

网络功能虚拟化(NFV)

网络功能虚拟化(NFV)使用商品服务器硬件取代专用网络设备,提供更灵活、高效和可扩展的服务。

应用程序交付控制器(ADC)

应用程序交付控制器(ADC)是一个网络组件,用于管理和优化客户端计算机如何连接到web和企业应用程序服务器。通常,ADC是一种硬件设备或软件程序,可以管理和引导数据流到应用程序。

虚拟机(VM)

虚拟机(VM)是运行程序或应用程序而不与物理机绑定的软件。在VM实例中,一个或多个客户机可以在物理主机上运行。

VPN(虚拟专用网络)

虚拟专用网络可以以低廉的成本创建安全的远程访问和站点到站点的连接,是软件定义的广域网的垫脚石,在物联网中证明是有用的。

分裂隧道(Split tunneling)

拆分隧道是一种设备配置,可确保只有指定用于公司资源的流量通过组织的internet VPN,其余流量在VPN之外直接到达internet上的其他站点。

广域网

WAN或广域网是一种网络,它使用各种链路专用线路、多协议标签交换(MPLS)、虚拟专用网络(VPN)、无线(蜂窝)和互联网连接组织的地理分布站点。在企业中,WAN可以将分支机构和单个远程工作人员与总部或数据中心连接起来。

重复数据消除

重复数据消除或重复数据消除是指识别和消除数据集中的重复块,从而减少必须通过WAN连接的流量。重复数据消除可以在来自不同目录、不同数据类型、甚至不同位置的不同服务器的文件中找到冗余数据块。

MPLS

多协议标签交换(MPLS)是一种确保实时应用程序可靠连接的分组协议,但价格昂贵,导致许多企业将SD-WAN视为限制其使用的一种手段。

SASE

安全访问服务边缘(SASE)是一种网络架构,它将软件定义的广域网(SD-WAN)和安全性集成到云服务中,该云服务承诺简化广域网部署,提高效率和安全性,并为每个应用程序提供适当的带宽。

SD-WAN

软件定义的广域网(SD-WAN)是一种软件,可以基于策略管理和强制WAN流量路由到适当的广域连接,策略可以考虑成本、链路性能、时间和基于策略的应用需求等因素。像其更大的技术兄弟软件定义网络一样,SD-WAN将控制平面与数据平面分离。

虚拟专用网

虚拟专用网络(VPN)可以以低廉的成本创建安全的远程访问和站点到站点连接,可以作为SD WAN中的一个选项,并被证明在物联网中非常有用。

无线局域网

Wi-Fi指的是利用IEEE 802.11标准进行通信的无线LAN技术。Wi-Fi产品使用无线电波将数据发送到带有Wi-Fi软件客户端的设备,并从设备发送到将数据路由到连接的有线网络的接入点。。

802.11ad

802.11ad是对IEEE 802.11无线网络标准的修订,旨在提供60GHz频率的多千兆位无线系统标准,是WiGig网络的网络标准。

802.11ay

802.11ay是对当前(2021)Wi-Fi技术标准的拟议增强。它是IEEE 802.11ad的后续,将带宽增加了四倍,并增加了多达8个流的MIMO。这将是第二个WiGig标准。

802.11ax(Wi-Fi 6)

802.11ax由Wi-Fi联盟正式销售为Wi-Fi 6和Wi-Fi 6E,是无线局域网的IEEE标准,是802.11ac的继承者。它也被称为高效Wi-Fi,用于在密集环境下对Wi-Fi 6客户端的整体改进。

Wi-Fi 6E

Wi-Fi 6E是在6GHz频段运行的Wi-Fi 6无许可无线技术的扩展,它提供了比Wi-Fi 5更低的延迟和更快的数据速率。该频谱的范围也更短,支持的信道也比已经专用于Wi-Fi的频段更多,因此适合在体育场等高密度区域部署。

波束赋形(Beamforming)

波束形成是一种将无线信号聚焦到特定接收设备的技术,而不是像通常那样从广播天线向所有方向传播信号。所产生的更直接的连接比没有波束成形的情况更快且更可靠。

无控制器Wi-Fi

企业不再需要在其数据中心安装专用Wi-Fi控制器,因为该功能可以分布在接入点之间或移动到云中,但并非每个人都需要。

MU-MIMO

MU-MIMO代表多用户、多输入、多输出,是路由器和终端设备支持的无线技术。MU-MIMO是单用户MIMO(SU-MIMI)的下一个演进,通常称为MIMO。MIMO技术的创建是为了帮助增加单个接入点可以支持的同时用户数量,这最初是通过增加无线路由器上的天线数量来实现的。

OFDMA

正交频分多址(OFDMA)通过允许多个客户端同时连接到单个接入点,为Wi-Fi 6提供了高吞吐量和更高的网络效率。

Wi-Fi 6(802.11ax)

802.11ax由Wi-Fi联盟正式销售为Wi-Fi 6和Wi-Fi 6E,是无线局域网的IEEE标准,是802.11ac的继承者。它也被称为高效Wi-Fi,用于在密集环境下对Wi-Fi 6客户端的整体改进。

Wi-Fi标准和速度

不断提高的Wi-Fi标准使Wi-Fi网络更密集、更快。

WPA3

WPA3 Wi-Fi安全标准解决了WPA2的缺点,以更好地保护个人、企业和物联网无线网络。

本文:

本文地址
https://architect.pub/glossary-networking-terms
SEO Title
Glossary of networking terms

存储架构

Chinese, Simplified
SEO Title
storage_architecture

「存储」硬盘与SSD:存储的未来是什么?-第2部分(数据中心)

Chinese, Simplified

「存储」硬盘与SSD:存储的未来是什么?-第2部分(数据中心)

 

在第2部分中,我们将深入探讨HDD和SSD之间的差异,HDD和SSD技术如何发展,以及如何在我们的运营和数据中心中利用SSD。

第一次在具有固态驱动器(SSD)的计算机上启动计算机或打开应用程序时,您可能很高兴。我知道我是。我喜欢这种新技术的速度,沉默和令人惊叹的因素,与硬盘驱动器相比,它几乎在所有方面看起来都更好。

我已经准备好完全接受SSD的承诺了。我有。我的桌面使用SSD进行引导,应用程序和工作文件。我的笔记本电脑有一个512GB的SSD。不过,我仍然使用硬盘。我的台式计算机中的第二,第三和第四个驱动器是HDD。我用于本地备份的外部USB RAID使用四个驱动器托架中的HDD。当我的笔记本电脑放在我的桌面时,它连接到1.5TB USB备份硬盘。硬盘驱动器在我的个人计算环境中仍然占有一席之地,因为它们可能在您的个人计

然而,长期以来,没有什么能保持不变,特别是在快速变化的计算世界中,所以我们肯定会看到新的存储技术脱颖而出,可能还有更多令人惊叹的因素。

在我们了解即将发生的事情之前,让我们在下表中更详细地回顾一下HDD和SSD之间的主要区别。

HDD与SSD的比较

电力消耗/电池寿命更多功耗,

  • HHD:平均为6-7瓦,因此使用更多电池更少的功耗,
  • SSD: 平均2-3瓦,导致30+分钟的电池提升

成本

  • HHD: 仅为每千兆字节0.03美元,非常便宜(购买4TB型号)昂贵,
  • SSD: 大约0.20美元至0.30美元每千兆字节(基于购买1TB硬盘)

容量

通常为笔记本电脑大小的驱动器大约500GB和2TB;

台式机最大10TB笔记本电脑尺寸驱动器通常不超过1TB;适用于台式机的4TB

操作系统启动时间

  • 大约30-40秒平均启动时间
  • 大约8-13秒平均启动时间

噪音

  • 可听到咔嗒声和旋转盘片没有活动部件,因此没有声音
  • 振动盘片的旋转有时会导致振动没有振动,因为没有活动部件

热量

  • 产生的硬盘驱动器不会产生太多热量,但由于移动部件和更高的功率消耗,它将具有比SSD更多的可测量的热量
  • 更低的功率消耗和没有移动部件因此产生的热量很少

故障率

  • 平均故障间隔时间为150万小时
  • 平均故障间隔时间为200万小时

文件复制/写入速度

  • 范围可以是50-120MB / s,通常高于200 MB / s,
  • 高达550 MB / s用于尖端驱动器

加密

  • 在某些型号上受支持全盘加密(FDE)
  • 全盘加密(FDE)某些型号支持

文件打开速度

  • 比SSD慢,
  • 比HDD快30%

受磁力影响

  • 磁铁可以擦除数据
  • SSD不受任何磁力影响

坚固耐用

  • 易受物理颠簸和运动影响
  • 不易受到颠簸和振动的影响

硬盘的前景如何?

硬盘具有惊人的改进和创新历史。自1956年成立以来,硬盘的尺寸减少了57,000倍,存储量增加了100万次,成本降低了2000倍。换句话说,每千兆字节的成本在大约60年内减少了20亿次。

硬盘制造商通过减小盘片的尺寸,从而减少盘片的寻道时间,提高盘密度,改进磁盘读取技术,增加多臂和读/写头,开发更好的总线接口,提高旋转速度和减少,从而取得了这些显着进步。与诸如用氦气填充驱动器之类的技术摩擦。

2005年,驱动器行业引入了垂直记录技术来取代旧的纵向记录技术,这使得面密度达到每平方英寸100千兆位以上。纵向记录相对于驱动器的旋转盘片水平对齐数据位,平行于盘的表面,而垂直记录垂直对齐位,垂直于盘表面。

「存储」硬盘与SSD:存储的未来是什么?-第2部分(数据中心)

 

其他技术如位图案媒体记录(BPMR)也有助于提高密度。 BPMR于2010年由东芝推出,是一种可以成功实现垂直记录的硬盘驱动器技术。它使用纳米光刻技术在磁岛中记录数据,每个岛一位。这与当前的磁盘驱动器技术形成对比,其中每个位存储在连续磁性薄膜内的20至30个磁性颗粒中。

叠瓦式磁记录(SMR)是一种用于HDD的磁存储数据记录技术,用于提高存储密度和整体每驱动器存储容量。叠瓦式录音会写入与先前写入的磁道部分重叠的新轨道,使之前的轨道更窄并允许更高的轨道密度。因此,轨道部分地重叠类似于屋顶瓦片。选择这种方法是因为物理限制阻止记录磁头具有与读头相同的宽度,从而使记录头更宽。

「存储」硬盘与SSD:存储的未来是什么?-第2部分(数据中心)

 

为了增加存储在驱动器盘片上的数据量,需要将磁性区域更紧密地塞入,这意味着晶粒需要更小,以便它们不会相互干扰。 2002年,希捷成功演示了热辅助磁记录(HAMR)。 HAMR使用激光热辅助记录磁力,最终可能在2019年之前产生20TB的驱动器。(请参阅我们关于HAMR的文章,希捷的CTO Mark Re,什么是HAMR以及它如何实现未来的高容量需求?)

西部数据声称其竞争的微波辅助磁记录(MAMR)可以使驱动器容量在2025年之前增加到40TB。一些行业观察者和驱动器制造商预测面密度将从今天的0.86 tbpsi太比特每平方增加到到2025年,英寸(TBPSI)达到10 tbpsi,在未来十年内可提供高达100TB的驱动器容量。

除了热量和微波之外,正在研究的其他技术包括使用极冷来增加HDD密度。

对于继续与我们保持一段时间的硬盘驱动器,未来肯定会看起来很明亮。

固态硬盘的展望

固态硬盘也取得了一些惊人的进步。

接口

SATA(串行高级技术附件)是通用硬件接口,允许与HDD和SSD之间传输数据。 SATA SSD适用于大多数家庭用户,因为它们通常更便宜,速度更低,写入寿命更短。

虽然适用于日常计算,在RAID(独立磁盘冗余阵列),服务器阵列或数据中心环境中,但通常更好的选择是使用“SAS”驱动器,它代表串行连接SCSI。这是另一种类型的接口,同样可用于HDD或SSD。 'SCSI'代表小型计算机系统接口(这就是为什么SAS驱动器有时被称为'scuzzy'驱动器)。 SAS通过SATA增加了IOPS(每秒输入输出),这意味着它能够更快地读写数据。这使SAS成为需要高性能和可用性的系统的最佳选择。

在企业级别,SAS优先于SATA,因为SAS支持过度配置以延长写入寿命,并且专门设计为在需要持续驱动器使用的环境中运行。

输入PCIe

PCIe(Peripheral Component Interconnect Express)是一种高速串行计算机扩展总线标准,由于有更多可用于数据流的通道,因此可通过SATA或SAS接口支持极高的数据传输速率。

许多领先的驱动器制造商已经采用PCIe作为新家庭和企业存储以及一些外围设备的标准。例如,您会看到最新的Apple Macbook附带基于PCIe的闪存存储,这是Apple多年来一直采用的消费设备。

PCIe还可以在数据中心内用于RAID系统,并创建高速网络功能,提高整体性能并支持更新,更高容量的HDD。

存储密度

正如我们在第1部分中所述,SSD基于一种称为NAND的非易失性闪存.NAND闪存的最新趋势是四电平单元(QLC)NAND。 NAND基于在每个物理存储器单元中存储多少位数据而被细分为类型。 SLC(单级单元)存储一位,MLC(多级单元)存储两个,TLC(三级单元)存储三个,QLC(四级单元)存储四个。

「存储」硬盘与SSD:存储的未来是什么?-第2部分(数据中心)

 

每个单元存储更多数据会使NAND更加密集,但它也会使存储器变慢 - 当在存储器的同一单元内存储如此多的附加信息(以及更多的电荷状态)时,读取和写入数据需要更多时间。

QLC NAND存储器构建在较旧的工艺节点上,具有较大的单元,可以更容易地存储多位数据。 新的NAND技术具有更高的整体可靠性和更高的编程/擦除周期(P / E周期)。

「存储」硬盘与SSD:存储的未来是什么?-第2部分(数据中心)

 

QLC NAND承诺生产更快,更密集的SSD。对价格的影响也可能是戏剧性的。 Tom's Hardware预测QLC的问世可能会将512GB SSD降至100美元。

超越HDD和SSD

我们在2015年撰写了关于未来数据存储技术的文章,并继续努力推动数据存储的范围超越旋转盘片和微电路的可能性。

例如,哈佛大学的一个团队使用基因组编辑将视频编码成活细菌。在英格兰,南安普顿大学光电子研究中心(ORC)的科学家们通过飞秒激光写入开发了五维(5D)数字数据的记录和检索过程。由于采用石英石英玻璃激光纳米结构的“5D数据存储”,这些光盘可容纳360 TB的数据,理论上可稳定长达140亿年。 Space-X的Falcon Heavy最近将这项技术带入了太空。

无论是热量,微波,DNA,细菌,石英晶体还是全息术,很明显,正在探索多种途径来提高存储容量,速度和寿命。

「存储」硬盘与SSD:存储的未来是什么?-第2部分(数据中心)

 

SSD在数据中心中的优势

我们已经讨论过SSD的好处。特别适用于数据中心的SSD的优点是:

  • 低功耗 - 当您运行大量驱动器时,功耗会增加。在任何可以节省电力的地方都是一种胜利。
  • 速度 - 可以更快地访问数据,这对于缓存数据库和影响整体应用程序或系统性能的其他数据尤其有用。
  • 振动不足 - 减少振动可提高可靠性,从而减少问题和维护。机架不需要容纳SSD的尺寸和结构刚性,它们需要容纳HDD。
  • 低噪音 - 随着更多SSD的部署,数据中心将变得更加安静。
  • 低热量产生 - 产生的热量越少,数据中心所需的冷却和功率就越少。
  • 启动速度更快 - 存储机箱上线速度越快或者维护或问题后重启服务器就越好。
  • 更大的面密度 - 数据中心将能够在更小的空间内存储更多数据,从而提高所有区域的效率(电源,冷却等)

顶级驱动器制造商表示,他们希望硬盘和固态硬盘在可预见的未来在家庭,商业和数据中心的所有领域共存,客户可以选择哪种技术和产品最适合他们的应用。

如何使用SSD

在几乎所有方面,SSD都优于HDD。那么,为什么我们不用SSD替换我们在数据中心中使用的100,000多个硬盘?

主要原因是成本。

我们希望能够为我们的Storage Pod提供SSD的性能和密度(请参阅我们的帖子Seagate推出60TB SSD - 下一个是3.6PB存储盒吗?),但SSD的成本/效益比尚未在我们的青睐。

我们的运营团队尽可能利用SSD的优势和优势,在主要数据存储以外的任何适当位置使用它们。它们在我们的缓存和恢复层中特别有用,我们在策略上使用它们来加速数据传输。 SSD还加快了对B2云存储元数据的访问速度。我们的运营团队正在考虑转向使用SSD来启动我们的存储盒,其中小型SSD的成本与硬盘驱动器相比具有竞争力,而且其他属性(小尺寸,低振动,速度,低功耗,可靠性)都是加号。

硬盘和固态硬盘的未来

IDC预测,创建的总数据将从2018年的大约33个zettabytes增长到2025年的大约160个zettabytes。(如果您想了解zettabyte的大小,请参阅什么是字节?)

「存储」硬盘与SSD:存储的未来是什么?-第2部分(数据中心)

 

据IDC称,目前超过90%的企业驱动器出货量都是硬盘驱动器。 到2025年,SSD将占驱动器出货量的近20%。 固态硬盘将获得份额,但创造的数据总量增长将导致硬盘和固态硬盘的大量销售。

「存储」硬盘与SSD:存储的未来是什么?-第2部分(数据中心)

 

随着HDD和SSD销量的增长,两种技术的容量也在增长。鉴于固态硬盘在许多应用中的优势,我们可能会看到固态硬盘替代硬盘驱动器,但容量最高。

很明显,HDD和SSD都有优点。如果您没有运行数据中心,并且家庭或企业计算机上没有超过一或两TB的数据存储,那么您的第一选择应该是SSD。它们在启动和数据传输期间提供了显着的性能改进,并且更小,更安静,更可靠。将HDD保存在系统中的辅助驱动器,NAS,RAID和本地备份设备中。

也许有一天,我们会回顾旋转盘片的日子,我们回顾立体声LP的同样的怀旧情绪,我们中的一些人将在我们的浮动反重力桌上作为对话片有一个硬盘镇纸。

直到SSD的性能,容量以及最终价格将最后一个硬盘驱逐出家庭和数据中心的那一天,我们可以期待生活在包含固态SSD和磁盘HDD的世界中,作为用户,我们将从两种技术中获益。

SEO Title
"Storage" hard drives and SSDs: What is the future of storage? - Part 2 (Data Center)

「存储」硬盘与SSD:存储的未来是什么?第一部分(区别)

Chinese, Simplified

「存储」硬盘与SSD:存储的未来是什么?

 

客户经常询问我们是否以及何时计划将云备份和数据存储迁移到SSD(固态硬盘)。 考虑到SSD相对于磁盘式驱动器(也称为HDD(硬盘驱动器))的许多优点,这并不是一个令人惊讶的问题。

我们的数据中心是HDD的大用户(目前拥有超过500 PB数据的100,000个硬盘)。 我们希望为云备份和云存储服务提供最佳性能,可靠性和经济性,因此我们不断评估用于运营和数据中心的驱动器。 虽然我们将SSD用于某些应用程序(我们将在下面介绍),但有理由认为在可预见的未来,HDD将继续成为我们和其他云提供商的首选驱动器。

HDDs vs SSDs

「存储」硬盘与SSD:存储的未来是什么?

 

我写的笔记本电脑有一个512GB的SSD,这已成为高端笔记本电脑的常见功能。 SSD对于笔记本电脑的优势很容易理解:它们比HDD小,更快,更安静,使用寿命更长,功耗更低,并且不易受振动和磁场的影响。它们还具有更低的延迟和访问时间。

今天2.5“512GB SSD的典型在线价格是140到170美元。 3.5“512 GB硬盘的典型在线价格为44至65美元。这在价格上是一个非常显着的差异,但由于SSD有助于使笔记本电脑更轻,使其能够更好地抵抗日常使用中不可避免的冲击和颠簸,并增加了更快启动,更快从睡眠中醒来的好处,更低功耗,更快启动应用程序和处理大文件,在这种情况下SSD的额外成本是值得的。

其中一些SSD优势(主要是速度)也将适用于台式计算机,因此台式机越来越多地配备了SSD,特别是用于保存经常访问的操作系统,应用程序和数据。用SSD替换启动驱动器已经成为一种流行的升级选择,可以为计算机注入新的活力,特别是那些似乎需要永久启动或用于臭名昭着的缓慢加载应用程序(如Photoshop)的计算机。

数据中心是一个完全不同的鱼群。数据中心存储的主要问题是可靠性,存储密度和成本。虽然SSD在前两个领域表现强劲,但它是第三个尚未具备竞争力的领域。在Backblaze,我们采用更高密度的硬盘驱动器 - 我们目前在数据中心使用10TB和12TB驱动器(以及其他容量)。更高密度的驱动器可为每个Storage Pod和Vault提供更高的存储密度,并通过减少所需维护和降低总功耗来降低我们的间接成本。这些尺寸的可比较SSD每TB的成本约为1,000美元,远高于相应的HDD。简单地说,固态硬盘还没有在价格范围内使用它们所带来的好处,这就是我们期望在可预见的未来使用硬盘驱动器作为主要存储介质的原因。

什么是硬盘驱动器(HDD)?

自IBM于1956年推出硬盘驱动器以来,硬盘驱动器已经存在了60多年。第一个磁盘驱动器的大小与汽车相当,仅存储3.75兆字节,今天的成本为30万美元。

350磁盘存储系统是IBM 305 RAMAC(会计和控制随机访问方法)系统的主要组件,该系统于1956年9月推出。它由40个盘片和一个单臂上的双读/写头组成。 上下堆叠的磁盘盘片。

「存储」硬盘与SSD:存储的未来是什么?

 

从那时起,硬盘驱动器的基本机制保持不变,尽管它经历了不断的改进。 HDD使用磁力将数据存储在旋转盘片上。 读/写头固定在一个臂上,该臂漂浮在旋转盘片上方读取和写入数据。 盘片旋转得越快,HDD就越快。 今天典型的笔记本电脑驱动器以5400 RPM(每分钟转数)或7200 RPM旋转,尽管一些基于服务器的盘片以更高的速度旋转。

「存储」硬盘与SSD:存储的未来是什么?

 

驱动器内部的盘片涂有磁性敏感薄膜,磁性薄膜由微小的磁性颗粒组成。当磁写头在旋转盘正上方飞行时,记录数据;写入头快速翻转晶粒的一个磁性区域的磁化,使其磁极向上或向下指向,以二进制编码编码1或0。如果所有这些听起来像硬盘容易受到冲击和振动,那么你就是对的。它们也容易受到磁铁的攻击,如果你摆脱它,这是破坏硬盘上数据的一种方法。

HDD的主要优点是它可以廉价地存储大量数据。如今,一台和两台TB(1,024和2,048千兆字节)的硬盘驱动器对于笔记本电脑来说并不罕见,10TB和12TB硬盘现在可用于台式机和服务器。密度和旋转速度继续增长。但是,如果将在线销售的普通HDD与SSD的成本进行比较,SSD的成本大约是每千兆字节成本的3-5倍。因此,如果您想要便宜的存储空间和大量存储空间,使用标准硬盘驱动器肯定是更经济的方式。

HDD的最佳用途是什么?

  • 需要高容量的磁盘阵列(NAS,RAID等)
  • 低成本的桌面是优先​​考虑的
  • 媒体存储(照片,视频,当前未处理的音频)
  • 驱动器具有极高的读写次数

什么是SSD?

固态硬盘几乎与硬盘驱动器一样,第一个半导体存储设备与1978年推出的硬盘驱动器接口兼容,即StorageTek 4305。

「存储」硬盘与SSD:存储的未来是什么?

 

StorageTek是一款针对IBM大型机兼容市场的SSD。 STC 4305的速度比IBM流行的2305硬盘系统快七倍(也是价格的一半左右)。它由一个装满电荷耦合器件的机柜组成,45MB容量的成本为400,000美元,吞吐速度高达1.5 MB /秒。

SSD基于一种称为NAND的非易失性存储器(以布尔运算符“NOT AND”命名,并且是两种主要类型的闪存之一)。闪存将数据存储在由浮栅晶体管组成的各个存储单元中。虽然它们是基于半导体的存储器,但是当它们没有通电时它们会保留信息 - 这一功能显然是与基于磁盘的数据存储竞争的必要条件。

与HDD相比,SSD具有更高的数据传输速率,更高的区域存储密度,更高的可靠性以及更低的延迟和访问时间。对于大多数用户来说,SSD的速度主要是吸引他们。在讨论驱动器的速度时,我们所指的是它们可以读取和写入数据的速度。

对于HDD,盘片旋转的速度强烈决定了读/写时间。当访问HDD上的数据时,读/写头必须物理地移动到盘上磁性部分上编码数据的位置。如果正在读取的文件按顺序写入磁盘,则会快速读取。但是,随着更多数据写入磁盘,文件可能会跨多个部分写入,从而导致数据碎片化。使用HDD读取碎片数据需要更长时间,因为读取头必须移动到盘片的不同区域以完全读取所请求的所有数据。

由于SSD没有移动部件,因此它们的运行速度远远高于典型HDD。碎片不是SSD的问题。文件可以在任何地方写入,对读/写时间影响很小,导致读取时间远远快于任何HDD,无论碎片如何。

但是,由于数据写入和读取到驱动器的方式,SSD单元可能会随着时间的推移而磨损。 SSD单元通过栅极推动电子以设置其状态。这个过程在单元上磨损,随着时间的推移会降低其性能,直到SSD磨损。此效果需要很长时间,并且SSD具有最小化此效果的机制,例如TRIM命令。无论块中的页面有多少更新,闪存都会写入整个存储块。这需要读取和缓存现有数据,擦除块并重写块。如果空块可用,则写操作要快得多。 TRIM命令必须在OS和SSD中都受支持,使操作系统能够通知驱动器不再需要哪些块。它允许驱动器提前擦除块,以使空块可用于后续写入。

「存储」硬盘与SSD:存储的未来是什么?

 

在SSD上重复读取和擦除的影响是累积的,并且SSD可以减慢甚至随着年龄显示错误。但是,更有可能的是,在SSD开始显示读/写错误之前,使用SSD的系统将被废弃以进行淘汰。硬盘驱动器最终也会因持续使用而磨损,因为它们使用物理记录方法,因此大多数用户不会根据预期的寿命来选择HDD或SSD驱动器。

总体而言,由于缺少机械部件,SSD被认为比HDD更耐用。 HDD内的移动机构不仅容易随着时间的推移而磨损,而且容易因移动或强力接触而损坏。如果要丢弃带有硬盘的笔记本电脑,那么所有这些移动部件很可能会发生碰撞,从而导致潜在的数据丢失甚至破坏性的物理损坏,可能直接杀死硬盘。固态硬盘没有可移动部件,但由于使用率高,它们可能会缩短使用寿命,因此它们可以承受我们对便携式设备和笔记本电脑的严格限制。

SSD的最佳用途是什么?

  • 笔记本电脑,笔记本电脑,性能,重量轻,面积存储密度,抗冲击性和一般坚固性是理想的
  • 引导驱动器保存操作系统和应用程序,这将加速启动和应用程序启动
  • 工作文件(正在编辑的媒体:照片,视频,音频等)
  • 交换驱动器,SSD将加速磁盘分页
  • 缓存驱动器
  • 数据库服务器

振兴旧电脑。如果您的计算机启动速度慢,加载应用程序和文件的速度很慢,那么使用SSD更新启动驱动器可能会让它看起来(如果不是新的话),至少就好像它刚刚花了一些时间才重新刷新在沙滩上。

请继续关注HDD与SSD的第2部分

这是第1部分。在我们的第二部分中,我们将深入研究HDD和SSD之间的差异,HDD和SSD技术如何发展.

SEO Title
"Storage "HDD and SSDs: What is the future of storage? first part

「存储架构」数据可用性与耐用性-您应该知道的重要差异

Chinese, Simplified

事情可以而且确实会出错。这是生活中的事实,企业花费时间和金钱为意外打嗝做准备。数据存储行业花费了数十年的时间,通过假设其组件在某些时候出现故障来提高存储架构的可靠性。链式电缆,电源,冷却,驱动器,软件(甚至系统管理员)中的所有元件可能都会失败,无需预先警告,并且会中断对用户数据的访问。

可靠性通常等同于数据可访问性,即确保在给定SLA下的数据访问。更现代的视角以不同的方式看待这两种关键的独立测量:可用性和耐用性。

让我们探讨一些差异以及它们对您的业务的重要性。

数据可用性与耐用性 - 它们不是同一件事

可用性和持久性是数据可访问性的两个非常不同的方面。可用性是指系统正常运行时间,即存储系统可操作并且可以根据请求提供数据。从历史上看,这是通过硬件冗余实现的,因此如果任何组件发生故障,将以数据访问为主。另一方面,耐久性是指长期数据保护,即存储的数据不会遭受比特腐烂,退化或其他损坏。它不关注硬件冗余,而是关注数据冗余,以便数据永不丢失或受损。

可用性和耐用性有不同的目标。对于数据中心,可用性/正常运行时间是操作的关键指标,因为任何一分钟的停机都是昂贵的。测量侧重于存储系统可用性。但是当组件,系统甚至数据中心发生故障时会发生什么?当故障得到纠正时,您的数据是否完好无损?

这说明了数据持久性的同等重要性。更正可用性故障时,必须恢复对未损坏数据的访问。随着数据的爆炸式增长,挖掘的潜力以及对更长保留率(对所有事物)的需求不断增长,您可以想象这对于商业成功至关重要。

考虑无法检索存档的主数据/参考数据副本的潜在竞争,财务或法律影响。因此,数据可用性和数据持久性对于短期和长期业务成功至关重要。

确保数据可用性 - RAID或无速率擦除编码?

确保数据可用性的常用方法是通过基于RAID的架构。跨多个驱动器划分数据可以防止一个或两个驱动器发生故障,但在重建操作期间性能会急剧下降,这可能会对业务运营产生负面影响。多年的数据中心经验表明,驱动器故障通常不是孤立事件:当RAID组中的一个驱动器发生故障时,其他组成员失败的可能性会增加。重建操作期间出现不可恢复的读取错误意味着数据现在永久丢失,从而使您的企业面临风险。

随着驱动器容量的大幅增加,重建时间也在增加。以前花费几分钟的时间现在可能需要数小时甚至数天。此外,这需要尽快更换故障驱动器,无论是周末,节假日还是半夜。

对象存储通过高级擦除编码实现数据可用性,从而将数据与奇偶校验信息组合,然后在存储池中进行分片和分布。由于只需要一部分分片来重新水化数据,因此没有重建时间或性能下降,并且在方便时可以替换故障存储组件。

数据持久性 - 单独RAID无法提供

您可能已经猜测,实现数据可用性与访问最初存储的数据并不完全相同。诸如钻头腐烂之类的介质故障,其中驱动表面的一部分或其他介质变得不可读,破坏数据,从而使得不可能以其原始未改变的形式检索数据。简单地防止诸如RAID之类的完整硬盘驱动器故障,不能防止存储在磁介质上的位逐渐失效。

广泛分布的擦除编码数据(例如18/8编码策略)和数据清理技术的组合可以持续验证写在介质上的数据,使您可以实现15个九的数据持久性。简单来说:对于每1000兆对象,只有一个对象不可读。数据持久性如何?超大规模数据中心和云服务提供商使用基于对象的存储来满足最高数据可用性和数据持久性的需求并不奇怪。

数据可用性与耐用性 - 一个错误的选择

每个组织都需要在需要时访问其数据,并且不会出现损坏或其他损失。它不是高可用性和高耐用性之间的选择;两者都很重要。

请记住,这是您的数据需要保护,而不是您的磁盘驱动器。

SEO Title
Storage Architecture Data Availability and Durability - Important Differences You Should Know

【Ozone】与Apache Ozone共度一年

QQ群

视频号

微信

微信公众号

知识星球

Chinese, Simplified

为什么选择Apache Ozone?

为了解决首选网络PFN中不断增长的数据需求和新的使用案例,我们一直在寻找一种可以伪无限扩展的新存储系统。由于对模拟和人工智能的战略关注[1],数据使用量的增长远远超过预期,这使得存储系统比以往任何时候都更加重要。

尽管我们的文章(ja) Hadoop in Preferred Networks Hadoop – Preferred Networks Research 中描述的基本要求没有太大变化,而且自那时以来仍然对我们至关重要[2],但我们目前运行的Hadoop(HDFS)集群存在几个操作问题。例如,我们最大的Hadoop集群,其容量约为10PB,仍在Ubuntu 16.04上运行。由于我们对大型集群的就地升级(包括操作系统的升级)没有任何知识或经验,并且Ubuntu 16.04的生命周期已经延长[3],我们已经放弃了系统升级,并一直在寻找新的软件来取代HDFS。我们制定了选择替代存储软件、建立新集群以及逐步迁移数据的计划。

升级底层操作系统只是我们面临的问题之一。我们的用例中还有其他几个不适合典型的HDFS用法。然而,由于其稳定性和操作方便性,我们妥协并绕过了它们。以下是列表:

  • 小文件问题[4]:文件数量的增加会导致元数据的增加。NameNode的负载取决于元数据、一组文件和文件的块位置列表。如果平均文件大小小于标准块大小,则文件数量增加得更快。特别是,在NameNode重新启动后从磁盘加载元数据需要花费大量时间。

为了解决这个问题,我们将一组小文件存储到HDFS上的一个大型ZIP档案中,并使用PFIO等库直接从ZIP读取文件(而不压缩档案)。

  • 高密度磁盘服务器(HDD):当单个节点中包含更多硬盘驱动器时,每个磁盘容量的性价比会变得更好。另一方面,数据节点中完整块报告(FBR)的时间较长会影响数据的持久性和可用性。例如,最受欢迎的Hadoop分发提供商之一Cloudera不支持容量超过100TB的DataNodes和容量超过8TB的硬盘驱动器。相比之下,我们在PFN的一些数据节点配备了36个硬盘,容量为14TB。
  • 与Python运行时更好的亲和力:从Python访问HDFS的标准方法是使用libhdfs2通过JNI中的Java Hadoop客户端读取和写入数据。复杂的软件堆栈施加了各种限制,使HDFS难以使用。最难的例子是PyTorch DataLoader,它并行分叉许多进程以更快地加载数据。为了在不使用JVM的情况下正确运行DataLoader,代码中需要非常小心,通过仅在分叉之后启动JVM来防止分叉已启动的JVM。
  • 经典身份验证:尽管基于Kerberos的身份验证系统可靠且成熟,但其通过kinit(1)获取令牌的身份验证方法并不适合在Kubernetes Pods中执行,因为它需要额外的身份验证工具。在PFN中,我们通常在运行主容器之前在initContainer中运行kinit,使用存储为Kubernetes机密的keytab文件。更简单的身份验证方法,例如仅在初步环境变量中要求机密,会使我们的清单更加简单。
  • NameNode可扩展性:为了扩展HDFS中的元数据管理,已经发布了许多系统,如HDFS Federation。它们主要涉及名称节点数量的增加,例如系统中更多的移动部件,这增加了整个系统管理的复杂性。

虽然这些问题一直让管理员感到非常疲惫,但它们也是系统用户抱怨的根源。Hadoop开发人员肯定已经意识到了这一点,因此Apache Ozone是从Hadoop中派生出来的,以解决这些问题。Apache Ozone如何解决这些问题如下:

  • 小文件问题:在Ozone中,管理过去属于NameNode的元数据和块位置的职责分别分配给Ozone Manager(OM)和Storage Container Manager(SCM)。定义了一个称为“容器”的新块单元集,SCM只管理容器及其复制和位置。这种拆分还使得元数据的增加仅与文件数量成比例,并且仅影响OM中文件表的内存大小。目录树访问变得更快,因为文件表存储在更高效的数据库RocksDB中
  • 高密度磁盘服务器:由于设计的改变,FBR变得更快。DataNodes只需要向SCM报告容器。一个容器最多可以存储2^64个块——通过控制容器中块的平均数量,我们可以控制SCM的总体负载。
  • 与Python运行时更好的相关性:添加了新的API端点。它与AWS S3兼容。它的生态系统如此庞大,以至于不仅它的SDK以各种语言提供,而且许多软件都有一个AWS S3(以及兼容的对象存储系统)的抽象来读取
  • NameNode可扩展性:由于NameNode的职责被划分并转移到OM和SCM,底层数据存储被迁移到RocksDB,元数据扫描和更新的性能得到了很大的提高。我们不能说我们不再需要像HDFS联邦这样的扩展噱头,但一个相当大的集群可以通过当前的设计进行管理。Cloudera测试了插入100亿个物体的Ozone [5]。

就在我去年发表了这篇博客文章[2]之后,我们开始测试Apache Ozone作为下一代对象存储系统,并且已经运行了几个月。

虽然在测试过程中,我发现并报告了CVE-2020-17517[6],但没有任何严重或关键的问题值得使用阻断剂。我们将该服务作为阿尔法服务向内部用户开放,并继续不断添加知识。API的覆盖范围远不是AWS S3的全部功能,但我们认为我们可以为社区贡献重要的功能和修复,因为社区一直非常活跃。

群集配置和设置

我们在MN-2中的一台管理服务器上安装了OM和SCM,在4台存储服务器上安装DataNode[7]。它们的物理规格如表1和表2所示。表1适用于DataNode;36个硬盘驱动器都被格式化为ext4分区(每1个驱动器1个分区),并被Ozone用作JBOD。

表1:DataNode的服务器规范

Type Amount
CPU Intel(R) Xeon(R) Silver 4114 1
Memory 32GB DDR4 12 ※1
HDD 14TB SATA 6GB/s 7200rpm 36
Network Mellanox ConnectX-6 (100GbE) 2

表2是运行OM和SCM的管理服务器的规范。为了持久保存元数据,它配备了四个15TB NVMe SSD,这些SSD捆绑为raidz分区。我们选择ZFS是因为我们在OpenZFS方面有一些经验,而且它有一组简单一致的CLI,很容易理解。在该分区中,OM和SCM存储它们的元数据。这种配置在SSD出现单次故障时仍然有效。

表2:Ozone 管理器和存储容器管理器的服务器规格

Type Amount
CPU Intel(R) Xeon(R) Silver 4114 1
Memory 32GB DDR4 12 ※1
NVMe 15TB PCIe Gen3 4
Network Mellanox ConnectX-6 (100GbE) 2

※1稍后,通过添加四个32GB棒,每个节点的内存将扩展到512GB。

操作系统是Ubuntu 18.04,它是我们在MN-2集群中设置物理服务器时安装的。由于之前在另一台服务器中有NVMe SSD管理的经验,我们在元数据服务器上安装了Linux 5.4.0 HWE内核。我们重新使用了构建MN-2集群时安装的Oracle JDK 8u162。

我们使用Apache Ozone 1.0.0从这些服务器构建了一个安全的集群。

图1描述了Ozone 集群的简单配置。在存储服务器中,DataNode和S3Gateway正在运行。在元数据服务器中,OM和SCM正在运行。S3Gateway是一个网关过程,它将S3 API访问转换为Ozone 原生API。S3Gateway进程公开为HTTP API服务器。来自客户端的访问通过DNS循环分布在网关进程中。我们没有使用HAProxy之类的反向代理进程来消除HDD到客户端进程内存空间的任何潜在瓶颈。在Ozone 1.0.0中,OM已经具有通常可用的高可用性(HA)功能,但它会引入一些操作复杂性,并且由于SCM没有HA,无法删除SPoF(单点故障)。因此,我们没有使用OM的HA功能。

 simplified picture of processesFigure 1: simplified picture of processes

我们运行了一个访问大小约为200GB的文件的简单基准测试。我们构建了一个并行读取的基准脚本,将其部署为Kubernetes集群中的几个客户端Pod,并在更改并发量的同时测量其性能。图2显示了所有客户端的总吞吐量。当并发量为128时,最大吞吐量略低于4GB/s。潜在的最大吞吐量将通过64和256之间的客户端中的某个并行点来获得。目标数据的大小小于磁盘缓存总容量的大小,我们有4个节点有20个核心CPU(总共80个核心处理来自所有客户端的请求),以及DataNodes的总CPU使用率饱和在100%左右,这表明瓶颈在服务器端。

Ozone

Figure 2: performance of parallel download of a blob file

在这个基准测试之后,我们开放了该服务供内部使用。几个月后,我们现在有几个内部用例,例如机器学习和备份。起初,我想我可以在这里详细分享其中的一些,但事实证明,它们中的大多数与深度学习中的标准工作负载没有太大区别。

历史和当前状态

在我们于2021年初建立集群后,Ozone 1.1.0于4月发布。我们在发布后立即升级了集群。

不是因为新版本,而是集群的管道(多Raft实例的单元)分布不平衡。我们期望4个节点和36个硬盘驱动器——期望SCM创建36*4/3=48个管道。但它没有起作用;SCM只创建了36个管道,我们没有充分利用144个HDD,只有108个存储了数据。后来,我们添加了另外两个存储服务器作为DataNodes,总共在6个DataNodes中创建了72个管道,最后我们充分利用了所有的HDD。如果你想了解更多关于管道的信息,请参阅Cloudera的博客文章[8]。

我们已经运行Apache Ozone好几个月了。它拥有所有具有HTTPS侦听/prom端点的组件,并以Prometheus Exposition格式公开了各种度量。我们使用普罗米修斯收集这些指标,并使用格拉法纳进行可视化。此外,我们还设置了Alertmanager,以便在出现某些异常情况时获得通知。截至今天,它拥有3000多万件物品和400多个水桶。图3描述了最近数据量的增加。

Figure 3: Historical and total disk usage and capacity of our Ozone cluster (physical)

Figure 3: Historical and total disk usage and capacity of our Ozone cluster (physical)

设置后,我们做了一些上游贡献,以解决操作过程中发现的问题。我们已经报告了1.1的CVE-2020-17517。1.2的主要贡献如下:

  • HDDS-5197(修补程序)
  • HDDS-5620(修补程序)
  • HDDS-5893(修补程序)
  • HDDS-4856(报告)
  • HDDS-5005(报告)
  • HDDS-5393(报告)

还有几个其他贡献合并到1.3.0或仍在进行中。对这些问题的描述将很长,并将在单独的博客文章中介绍。除了上游贡献外,我们精心挑选了HDDS-5472,并于9月将其应用于集群。这个补丁极大地提高了OM的性能,集群变得非常稳定。10月,我们切换到了OpenJDK 1.8.0。Ubuntu 18.04提供了补丁级别1.8.0-292,其中包括服务器端的TLS处理性能。

11月,1.2.0发布,并针对过去版本中的漏洞进行了多次修复。我们在发布后立即进行了升级,进展非常顺利,没有出现任何重大问题。毫无疑问,我们未来还有很多工作要做,分为三大类。。

OM和SCM中的高可用性

在当前设置中,OM和SCM中的元数据使用ZFS在多个磁盘上复制。但我们在服务本身仍有几个单点故障。例如,如果运行OM和SCM的机器出现故障,这些进程肯定会停止,因此服务将全部停止。Ozone 1.2.0具有通过Raft复制这些服务的HA功能,Raft运行三个复制的进程,并允许在单节点故障的情况下进行服务故障切换。该服务的可用性将大大提高,并降低在PFN中更广泛的实际工作负载用例中采用Apache Ozone的门槛。

Ozone 的集群扩展与HDFS的迁移

截至目前,HDFS集群总共存储约9PB的数据,而Ozone 中的数据量仍在200TB左右。基本上,我们希望HDFS中的所有数据都迁移到Ozone 层。此外,我们的业务工作量产生的新数据将新存储在Ozone 中。绝对需要更多的容量——随着数据迁移的进展,我们确实计划逐步将HDFS数据节点转移到Ozone,但在全面迁移真正开始之前,我们对可以从HDFS移动多少节点的前景很渺茫。我确实记得,过去一些存储系统中的数据量甚至在其使用寿命结束之前都没有减少,我们只能无奈地手动清理这些数据。

有几种方法和路径可以迁移数据。在具有相同KDC(Kerberos的密钥分发中心,我们有多个)的集群之间,我们将能够在它们之间运行distcp。在使用不同KDC的情况下,distcp可以使用s3a协议,并且似乎是可行的。但有一个问题是HDFS对文件大小没有限制,S3 API的最大文件大小为5TB。我们在HDFS中确实有几个超过5TB的文件。

新特点与上游贡献

没有一个软件是完美的,因此,当我们继续使用它时,我们可能会发现一些缺点。我们不仅会等待社区改进或解决这些缺点,还会尝试自己去做。我们将继续努力发送补丁。我们已经有了其中的一些;一些重要补丁和建议如下:

  • HDDS-5656–多部分上传优化
  • HDDS-5905–潜在的数据丢失
  • HDDS-5975–ListObjects错误修复

结论

在PFN中,从Apache Hadoop到Apache Ozone的迁移一直在进行中。我们介绍了它的背景、实际设置和基准。我们预计数据将持续增加,我们将扩大我们的集群。我们还努力在行动期间不断向社区发送我们的反馈和贡献。

参考

本文地址
https://architect.pub/year-apache-ozone
SEO Title
A Year with Apache Ozone

【Ozone】使用Apache Ozone第二年

QQ群

视频号

微信

微信公众号

知识星球

Chinese, Simplified

自2021年初以来,我们优选网络(PFN)正处于从HDFS转向Ozone的过程中。我们的Ozone集群已经被我们的ML/DL项目所采用,集群的使用量正在迅速增长,在过去两年中,我们已经多次扩大了集群。然而,随着集群的逐渐扩展,磁盘使用不平衡成为了一个问题。例如,将完全空的数据节点添加到所有现有磁盘已满80%的Ozone集群中,将导致集群使用率严重失衡。将数据移动到新添加的空服务器称为再平衡,但它的具体工作方式并不明显。在HDFS中,有平衡器,它在每个节点的指定阈值内均匀地移动块,还有磁盘平衡器,它将块在单个数据节点内的磁盘之间对齐。另一方面,Ozone有一个容器平衡器,起初再平衡在Ozone.2.0中似乎不起作用,因为它仍然是一个年轻的功能。因此,当我们最近添加新的数据节点时,我们决定执行手动再平衡作为紧急维护。在这篇文章中,我们从背景开始展示我们的全部故事。

(有关建立Ozone集群的更多信息,请阅读2021年的博客文章“与Apache Ozone共度一年”。)

存储系统在PFN的计算基础设施中的作用是提供一个地方来保存我们的ML/DL研究活动所需的数据,并在需要时高速读取数据。“所需数据”包括各种内容,如数据集、程序执行结果和作业检查点文件。最近,公司中通过使用CG和模拟进行计算来生成数据的用例[1][2][3][4]的数量有所增加,而且数据不断从无到有。我们一直在通过根据磁盘使用统计数据预测需求来购买和构建服务器,但最近很难估计,而且磁盘的填充速度比预期的要快。

通过购买服务器和磁盘设备来扩展集群实际上需要花费大量时间。如果我们在可用空间较低的阶段购买服务器,我们将无法跟上数据增长的步伐。我们购买并添加了新的服务器,同时收缩了HDFS集群,并多次将退役的HDFS数据节点重新部署为新的Ozone数据节点。值得庆幸的是,HDFS和Ozone都支持扩展和删除数据节点。然而,如上所述,由于采购条件和使用预测的困难,我们的集群扩展进展很小。图1显示了过去一年中我们集群的系统容量(橙色)和实际使用量(蓝色)的发展情况,这表明使用量的增长速度快于容量,而我们一直在重复添加服务器。我们计划进行系统扩展,以将数据使用率保持在80%以下,但最近几个月,使用率已达到这一极限。

Fig. 1: Physical system capacity and actual usage of the Ozone cluster (Unit: TB)

Fig. 1: Physical system capacity and actual usage of the Ozone cluster (Unit: TB)

增量群集扩展导致磁盘失衡

虽然整个集群的可用空间即将耗尽,但数据节点之间的磁盘使用不平衡也是一个问题。图2显示了每个数据节点的物理磁盘使用情况。在该图中,磁盘使用率高的数据节点是旧节点,而新添加的节点可以观察到磁盘使用率低。这种分布是不可取的,因为为了实现I/O负载平衡,磁盘使用应该尽可能均匀。此外,磁盘使用率高的节点会引起对磁盘已满的担忧。

Ozone Datanodes with an imbalanced state.

数据节点配置如表1所示,图2中各服务器的数据节点配置如下:

Table 1: Ozone Datanode configuration
Software Apache Ozone 1.2.0 based custom version
CPU Intel(R) Xeon(R) Silver 4114 x1 20c
RAM 32GB DDR4 x16
HDD 14TB SATA 6GB/s 7200rpm x36
Network Mellanox ConnectX-6 (100GbE) x2

在Apache Ozone和Hadoop中,没有自动磁盘使用平衡的功能。对于HDFS,有一个Node Reblancer,它在启动时在数据节点之间移动数据,以实现磁盘使用均衡。Ozone有一个名为Container Balancer的组件,它可以在数据节点之间重新平衡数据,类似于HDFS,但不幸的是,Ozone 1.2中不支持它,因此我们还无法使用它。

在此期间,数据节点保持不平衡状态,并以相同的速度在所有节点上填充,无论是高使用率还是低使用率。一些数据节点的磁盘利用率超过90%,接近100%。当时,我们对Datanodes的磁盘将满时的行为一无所知。为了避免出现不可预测的状态,我们决定尝试停用接近磁盘满状态的Datanode。停用是一种从集群中安全删除数据节点、将数据节点上的所有数据复制到其他数据节点并将其从集群中删除的操作。如果我们有额外的空间,停用高利用率的数据节点不仅会防止磁盘满,而且我们可以期望数据统一写入其他数据节点。

由于每个数据节点的磁盘容量为每个硬盘14TB,并且线速足够快,因此我们开始停用时假设拷贝可以在几天内完成,即使考虑到它是一个硬盘。然而,它并没有像最初预期的那样在期限内结束,两个月过去了,节点状态仍处于“断开”状态。由于用于检查停用进度的CLI尚未实现,我们不得不直接在SCM中读取Replication Manager日志,我们发现停用在某个时候被卡住了。就在那时,我们放弃了通过删除节点重新定位和重新平衡数据的想法。

出现满磁盘节点

虽然我们尝试了容器平衡器和停用,但不幸的是,它对我们不起作用,时间一天天过去了,集群中的一些节点最终变成了磁盘满状态。在达到100%使用率的磁盘上,容器无法打开,如图3所示。容器[5]是Ozone的一个管理单元,它将最多5 GB的区块分组[6]。Ozone不像HDFS那样直接管理块,但它决定了容器单元中的数据放置和复制计数。

Ozone在打开容器时总是以写入模式打开RocksDB以读取元数据,并且似乎未能写入打开RocksDB.所需的日志[7]。对于这些情况,磁盘已满的节点上的容器将无法读取。

2022-09-07 15:36:24,555 [grpc-default-executor-8298] ERROR org.apache.hadoop.ozone.container.common.utils.ContainerCache: Error opening DB. Container:150916 ContainerPath:/data/21/ozone/hdds/CID-xxx/current/containerDir38/150916/metadata/150916-dn-container.db
java.io.IOException: Failed init RocksDB, db path : /data/21/ozone/hdds/CID-xxx/current/containerDir38/150916/metadata/150916-dn-container.db, exception :org.rocksdb.RocksDBException While appending to file: /data/21/ozone/hdds/CID-xxx/current/containerDir38/150916/metadata/150916-dn-container.db/MANIFEST-001861: No space left on device; status : IOError(NoSpace); message : While appending to file: /data/21/ozone/hdds/CID-xxx/current/containerDir38/150916/metadata/150916-dn-container.db/MANIFEST-001861: No space left on device

Fig. 3: Failure when opening RocksDB

即使某些数据节点的磁盘已满,唯一的影响是这些节点上的副本变得不可读,因此读取其他副本和写入不会受到影响。在PFN,尽管一些数据节点的磁盘已经满了,但每天都会生成大量数据并写入Ozone集群。几天后,更多的数据节点变为磁盘已满状态。如果复制集的副本计数不满足所需的复制因子,则无法读取此集中的数据。发生这种情况时,集群用户报告集群中的某些数据不可读。9月12日,集群中12个数据节点中有5个数据节点的磁盘已满。这意味着集群中超过一半的数据节点的磁盘已满。如果我们能够等待Ozone1.3.0的发布,容器平衡器可能会帮助我们,但我们需要尽快修复磁盘已满的数据节点,以最大限度地减少对我们研究活动的负面影响。

“手动”重新平衡的一种选择

通常,对于有状态的应用程序(如文件系统和数据库系统),应避免手动操作。这是因为系统应该保持一致性,而手动干预很容易由于简单的人为错误而破坏系统保证的完整性。基本上,管理所需的所有功能都应该以管理工具的形式提供。这是一个确保统一维护质量并提前避免一些意外操作错误的框架。

然而,由于Ozone目前的标准功能无法解决磁盘满的问题,而且预计手动再平衡将解决这个问题,而不是寻求现有功能的解决方案,因此我们决定尝试使用手动再平衡来恢复集群。

我们熟悉Ozone的内部数据结构,并有可能手动操作它。曾经有一段时间,我们定期聚集在一起阅读Ozone的源代码,如果有任何可疑或不清楚的地方,我们会检查当前工作版本的源代码。这一次对我们有所帮助。在接下来的部分中,我们将简要解释如何通过手动重新平衡来实际传输数据。

Ozone1.2.0的内部数据结构遵循容器布局V2,如图4所示。容器布局V2是一种格式,每个容器包含一个目录,称为容器目录。容器目录由元数据(RocksDB和YAML)和块(Blob)组成。

Ozone数据节点具有hddsVolumes,每个卷都将容器(由Ozone SCM管理)存储为由容器id标识的容器目录。容器id由SCM按顺序编号。

在PFN中,Ozone数据节点是以JBOD方式设置的,每个HDD对应一个hddsVolume。从理论上讲,容器只是文件系统中的一个目录,我们认为,如果我们能够在保持目录结构的同时将它们移动到其他数据节点,那么我们可能可以做与复制或容器再平衡相同的事情。

 HddsVolume structure in Container Layout V2

Fig. 4: HddsVolume structure in Container Layout V2

人工再平衡还有一个问题。如果我们可以手动移动容器位置,那么容器位置元数据的一致性是否存在问题?当数据节点启动时,它会扫描本地磁盘中的所有数据,然后将收集到的有关现有和可读容器的信息作为ContainerReport发送给SCM。这相当于HDFS中的BlockReport。如果我们完全停止Ozone,我们认为在数据节点之间移动容器是安全的,我们实际上通过一个小的测试案例证实了在停止一些数据节点的同时移动容器是成功的。

由于我们用小型测试用例确认了计划的操作,我们决定使用上述内部数据结构手动重新平衡磁盘使用情况。同时,由于我们可以通过缩小HDFS集群来添加七个新的数据节点,我们还决定通过添加数据节点来扩展Ozone集群。我们的手动再平衡政策是:

  • 准备具有相同配置(相同数量的磁盘、相同容量)的数据节点
  • 选择磁盘使用率高的(旧的)数据节点,并将一半的容器复制到新的数据节点
    • 我们将数据节点(旧的)和数据节点(新的)配对,并且这些对是独占的和唯一标识的(为了简化和避免容器副本之间的冲突)
    • 维护目录结构,使其在新旧之间遵循Container Layout V2,包括SCM ID和Container ID迁移
    • 复制完成后从旧数据节点中删除容器
  • 完全停止Ozone集群只是为了维护
    • 停止服务是一个合理的选择,因为群集中超过一半的数据节点由于磁盘已满而无法为文件提供服务
    • 向用户清楚地解释,在维护期间,存储服务将完全不可用,这是一项非常重要的维护

由于此次维护需要停止服务,我们决定制定更具体的时间表和详细的任务清单。

离线维护:计划和行动

进度计划

离线维护的注意事项包括:

  • 确保有足够的操作时间
    • 最小化维护周期,因为离线维护将暂停我们的研究活动
  • 提供足够长的准备期
    • 更长的时间允许用户为数据迁移做准备,并允许管理员验证维护说明
    • 这是一种权衡,因为较短的周期可能会避免即将出现的其他与磁盘相关的意外问题
    • 由于9月中旬有连续假期,增加了更多的宽限期(日本“白银周”)
  • 在我们的工作时间内进行维护,为用户和管理员留出空间,以便快速处理一些意外问题
  • 确保缓冲日

至于操作所需的时间,假设复制过程具有足够的并行性,我们可以估计维护时间相当于在每个数据节点中复制一半物理HDD卷大小的时间(14 TB/2=7 TB)。每个数据节点都通过100GbE网络相互连接,因此我们最初估计复制将在一天内完成。此外,我们还分配了一天作为缓冲区,并最终决定停止集群最多两天。为了确保有足够的准备时间,我们决定从维护公告到复制操作之间至少需要两周的宽限期。

抢救重要数据

由于我们将两周设置为修复该问题的准备时间,因此我们需要为那些希望立即使用由于磁盘满问题而当前不可用的文件的群集用户提供另一个选项。我们从集群中抢救了一些文件,直到维护完成,方法是从OM中获取元数据,从SCM中获取块的位置以识别数据节点,然后从数据节点上的容器中收集块以恢复原始文件。对于数据抢救,我们准备了读取Ozone元数据、下载块和重建块等操作,并使这些功能在集群之外普遍可用。实际上,手动执行这些操作很复杂,所以我们将它们作为自动化脚本来实现。

手动重新平衡的准备

手动再平衡说明的初步示意图为:

  1. 停止所有与Ozone有关的过程
  2. 准备新的数据节点并将其添加到集群中
  3. 将数据节点(旧)的一半数据复制到数据节点(新)
  4. 从数据节点删除完全传输的数据(旧)
  5. 启动Ozone

对于复制容器,因为实际上这些副本只是服务器之间的简单目录传输,所以我们决定使用rsync。这一次,由于我们只希望Datanode中有一半的容器,所以我们使用偶数容器ID传输容器。接受列表格式的传输目标作为其参数也是我们使用rsync的原因之一。图5显示了使用rsync传输容器的示例。在实践中,我们在一个Datanode中有36个HDD,因此我们对磁盘和服务器的数量重复此命令,但由于它可以充分并行化,因此传输时间相当于一个磁盘。

Fig. 5: An example of filtering target containers and transferring them with rsyncFig. 5: An example of filtering target containers and transferring them with rsync

由于这种维护需要停止Ozone集群,我们希望提前确保数据传输时间在维护窗口内合理。因此,我们发现,单个数据节点的完整拷贝仅拷贝7 TB就需要长达五天的时间。数据节点包含许多目录和条目,这会导致低吞吐量。为了最大限度地减少停机时间,我们使用了差异副本作为维护的前期工作。最后,维修说明如下:

  1. 预备:列出要复制的目标容器
  2. 预备:将目标数据的完整副本从数据节点(旧)复制到数据节点(新)
  3. 在窗口中:停止所有与Ozone有关的过程
  4. 在窗口中:在数据节点之间获取目标数据的差异副本
  5. 在窗口中:从Datanode(旧)中删除已完成的容器
  6. 在窗口中:从Datanode中删除步骤2中完整复制后删除的容器(新)
  7. 在窗口中:启动Ozone

当我们等待两周的平稳期时,又出现了两个磁盘已满的节点,现在有八个节点处于这种状态。图6显示了当时Datanode的磁盘使用情况。由于我们要添加七个节点,因此在实践中需要将维护过程更改为将两个数据节点中的容器合并为一个。

Fig. 6: Disk usage of Datanodes at the before the maintenance dayFig. 6: Disk usage of Datanodes at the before the maintenance day

维护日

尽管我们不得不处理一些比预期更多的新的满磁盘节点,但由于作为前期工作执行的完整拷贝已经成功完成,直到维护日,我们停止了集群,并按计划执行了差异拷贝。对于差异复制,rsync有两种模式:比较时间戳和在文件之间进行校验和。我们没有使用校验和模式来加快速度。使用校验和模式需要计算所有目标文件的校验和,在这种情况下吞吐量很低。

最终,我们按时完成了维修工作。在这个维护日,我们通过手动重新平衡,从8个磁盘已满的数据节点减少到零,通过添加新的数据节点,整个集群的磁盘使用率也从85%减少到69%。图7显示了维护后集群的磁盘使用情况报告。与Ozone相关的磁盘使用率指示绿色条,这些条在集群之间几乎重新平衡,最终没有磁盘满的数据节点。

Fig. 7: The disk usage report after the maintenance

Fig. 7: The disk usage report after the maintenance

手动重新平衡,一个月后

9月22日进行了手动再平衡。截至目前,我们还没有因手动再平衡工作而引起的任何问题。此外,我们还修复了集群的其他一些配置问题。

已修复:某些复制已停止

我们注意到Datanodes在维护后使用的证书已过期。这些证书由数据节点之间的特定复制过程使用,并在第一次启动数据节点时自动初始化。Ozone RPC使用Kerberos进行身份验证,但一些复制操作依赖于SCM使用自签名CA颁发的此证书。实际上,有效期为一年,但Ozone 1.2.0中没有实现续订证书的功能。由于我们的集群具有长时间运行的Datanodes,因此节点中的一些证书已经过期。

这次我们手动续订了证书,这使复制工作正常。虽然更新后退役仍在进行中,但我们最初遇到的退役停滞的原因可能是证书过期。

已修复:修改的ContainerPlacementPolicy

我们仍然看到数据增长的不平衡。我们将尝试更改ContainerPlacementPolicy、PipelineChoosingPolicy和LeaderChoosePolicy等政策来改善这种情况。特别是,我们将用于选择数据节点作为容器放置的ContainerPlacementPolicy更改为用于选择最空闲数据节点的容量感知策略。由于该政策在Ozone 1.2.0中确实存在问题(由HDDS-5804修复),我们为内部分发备份了一个补丁。

未来的工作

Ozone仍然是一个年轻的软件,但社区非常活跃。虽然我们这次面临的问题包含在1.2.0版本中,但这些问题中的大多数都是为即将发布或未来的版本修复的,因此我们介绍以下内容。在PFN中,我们正在运行Ozone 1.2.x集群和主HEAD集群,以预测即将发布的1.3.0版本。从现在起,如果有必要,我们将在后台移植最新补丁的同时操作集群。

自动证书续订(HDDS-7453)

社区建议自动续订证书。这使我们能够通过手动更新来节省劳动。

退役可观测性改进(HDDS-2642)

退役进度现在作为指标导出。目前,我们需要读取SCM日志和Datanode状态,这是检查退役进度的唯一方法。这一建议使我们能够提高退役的可观察性。

保留卷空间(HDDS-6577和HDDS-6901)

HddsVolume现在可以在数据节点中声明一些保留空间。通过此更改,可以将磁盘空间限制为磁盘的某些边距,并防止磁盘已满,从而减少元数据故障。

容器平衡器(HDDS-4656)

现在我们有了Ozone容器平衡器。这就消除了像我们所做的那样手动重新平衡工作的必要性。这是我们运营集群的一个重要特征,我们将仔细评估我们的集群。

结论

由于集群的增量扩展,我们遇到了磁盘使用不平衡的情况,而且一些数据节点达到了磁盘已满的状态。这种情况使我们无法从这些节点读取数据。在这篇文章中,我们分享了我们的背景以及为什么我们做出手动再平衡的决定,并通过介绍Ozone数据节点的内部数据结构来分享我们的维护操作。我们决定通过停止集群来进行离线维护,因为超过一半的数据节点处于降级状态,并且精心设计了计划以最大限度地减少停机时间。

为了进行维护,一开始我们向Ozone集群添加了七个新的数据节点,然后手动将一半的容器从旧的数据节点移动到新的数据结点。虽然这次的维护需要对Ozone执行情况及其内部数据结构有深入的了解,但幸运的是,我们完成了维护,没有遇到任何问题,一个月后集群仍然健康。

参考文献

本文地址
https://architect.pub
SEO Title
Two Years with Apache Ozone

【云计算】软件定义存储的四大好处

Chinese, Simplified

软件定义的存储正在帮助各行各业的客户管理他们的数据。它也可以帮助你的公司。最近的一篇eWeek文章揭穿了围绕软件定义存储的一些常见神话,展示了这种技术如何被误解。但是,有一些很大的好处,因此了解软件定义的存储在公司的旅程中可以发挥的作用非常重要。

什么是软件定义存储(SDS)?

软件定义存储(SDS)是一种存储架构,可根据一组松散耦合的软件和硬件组件满足各种数据存储要求。 SDS是一种包含传统和较新类型工作负载的模型,并针对硬件和软件解决方案之间的互操作性进行了优化。简而言之,它为您提供了更高的灵活性,使您可以接收,使用和探索不同的数据存储选项,并更好地利用数据来获得更多业务洞察。

「云计算」软件定义存储的四大好处

 

有什么好处?

  1. 更聪明地工作。 SDS在工作负载和存储之间创建更智能的交互。它支持更动态的存储配置,帮助存储更好地适应工作负载需求,并在服务器上提供存储功能。
  2. 实现敏捷的存储消耗。 SDS支持新兴和传统的IT消费模型,实现跨云,移动,社交和分析基础架构的技术灵活性。
  3. 获得控制和效率。 SDS提供满足快速变化的业务需求所需的灵活性,控制和效率。它动态优化基础架构功能以满足应用程序服务级别的要求。
  4. 获取实时可扩展性。 SDS按服务级别提供分层容量,并能够按需配置存储,根据当前业务需求实现最佳容量。 SDS还为您提供存储基础架构使用情况的指标报告。

SDS提供的自动化和灵活性将有助于提高存储和员工效率,从而真正影响您的利润。我们的优化评估显示SDS策略可以减少花费的总金额。

SEO Title
"Cloud Computing" four benefits of software defines storage

【存储】2022 年的 4 个开源对象存储平台

Chinese, Simplified

介绍


在处理大量非结构化数据时,我们需要一个地方来存储它。 我们选择存储数据的方式有很多种,但今天我们要关注的一种是对象存储或基于对象的存储。 这是处理大量数据时的最佳选择,特别是因为它并不昂贵,并且可以更轻松地管理这些数据。
如果您不熟悉它,对象存储是一种数据存储架构,允许您将大量非结构化数据存储在可扩展的对象结构中。 它将数据存储为具有元数据和唯一标识符的对象,从而更容易访问该数据。 现在,有许多平台提供对象存储设施。
这就是为什么在本文中,我们将告诉您四个有用的开源对象存储平台,它们包含强大的功能,使它们成为 2022年的重大投资。


1.LakeFS

LakeFS 是一种开源数据环境工具,可让您管理基于对象存储的数据湖。 这些数据湖是存储库,您可以在其中转储所有结构化和非结构化类型的数据。 LakeFS 还集成了许多工具并支持 Amazon S3 和 Google Cloud Storage。 此外,它适用于所有主要数据框架,例如 Hive、Spark、Presto、AWS Athena 等。
使用 LakeFS,您可以扩展 PB 级数据,还可以通过其类似于 Git 的分支和版本控制方法向其中添加数据,这使您可以在不破坏数据的情况下添加更新。 这种类似于 Git 的方法还有助于轻松撤消数据更改,这使得处理数据更加容易和安全。
您还可以通过查看 LakeFS 文档了解其他特性和功能。


2.Ceph

Ceph 是对象存储、块存储和文件系统的开源平台。 它提供与 Amazon 的 S3 REST API 和 OpenStack 的 API Swift 完全兼容的对象存储功能。
Ceph 的对象存储允许您使用本地语言绑定和 Ceph 提供的其他技术轻松访问数据对象。 如果您想转变公司的 IT 基础架构及其管理大量非结构化数据的能力,这是一个很好的解决方案。 他们还有一些软件库,使用 Java、C、C++、Python、PHP 和其他几个编写的软件能够使用原生 API 的强大功能访问 Ceph 的对象存储系统。


3. MinIO

MinIO 是一款开源云存储软件,提供高性能分布式对象存储,专为大规模数据基础设施而设计。 它与 Amazon S3 API 兼容,并且它在 GitHub 上拥有超过 26,000 颗星,有超过 680 名贡献者在为它工作。
MinIO 服务器存储所有类型的非结构化数据,例如照片、视频、日志文件等。 它也可在开源 Apache V2 许可下使用,许多最强大的大数据和机器学习应用程序都使用 MinIO S3 对象存储。 您可以在 MinIO 网站上查看许多其他功能。


4.OpenIO

OpenIO 是一种开源对象存储解决方案,用于管理和保护大量非结构化数据。 它允许您构建和操作具有弹性且安全的大规模存储基础架构。
OpenIO 与 S3 兼容,可以在任何硬件上部署或云托管。 添加新硬件时也不需要重新分配数据; 您可以立即使用额外的容量。 OpenIO 还专为大规模基础设施和大数据工作负载而设计。 除此之外,它还提供了一个直观的用户界面来简化存储管理员的日常生活。 因此,您的数据变得非常易于访问且易于管理。


结论


您可以使用许多开源对象存储提供程序,它们提供了我们提到的许多功能中的一些功能。 它们为您的所有存储需求提供了良好的解决方案,并避免了高昂的财务成本。 因此,选择具有您需要的所有功能的对象存储平台非常重要。

原文:https://betterprogramming.pub/4-open-source-object-storage-platforms-fo…

本文:

SEO Title
4 Open Source Object Storage Platforms for 2021

【存储架构】云上坚不可摧的存储Apache Bookkeeper

Chinese, Simplified

关键点

  • 使存储系统具有云感知的传统方法是提升和转移方法。虽然它是有效的,但根据我们的经验,投资重构架构,使其更能感知云,可以产生更好的结果。
  • 在跨区域环境中部署Apache BookKeeper的当前解决方案需要将BookKeeper存储节点手动映射到特定的区域/可用性区域,但这并不能在区域中断期间提供相同的持久性和可用性保证。
  • Salesforce使Apache BookKeeper具有云感知的独特方法包括为BookKeeper存储节点提供智能,以便它们在基于云的部署中有效运行,同时保持BookKeeper保证的持久性和可用性。
  • 这些新增功能使集群更容易打补丁、升级和重新启动,对使用服务的影响最小。

在Salesforce,我们需要一个可以处理两种流的存储系统,一种是写前日志(write-ahead logs  WAL)流,另一种是数据流。但是我们有来自两个流的竞争需求。预写日志流应该是写的低延迟和读的高吞吐量数据流应该具有高的写吞吐量,但具有低的随机读延迟。作为云计算的先驱,我们也要求我们的存储系统能够感知云,因为对可用性和持久性的要求越来越高。我们的部署模型被设计为不可变的,以便能够扩展到大规模的级别并在普通硬件上运行。

开源替代

我们对这种存储系统的最初研究遇到了构建还是购买的问题。

考虑到我们所有的期望和需求都取决于上市时间、资源、成本等主要业务驱动因素,我们决定采用开源存储系统。

在研究了开源所能提供的服务之后,我们确定了两种最终的选择:Ceph和Apache BookKeeper。随着系统对我们的客户可用的需求,规模到大规模的水平,也作为一致的事实来源,我们需要确保系统可以满足我们用例的CAP定理的方面。让我们鸟瞰一下BookKeeper和Ceph在CAP定理(一致性、可用性和分区容忍度)和我们独特的要求方面的立场。

Ceph提供了一致性和分区容忍而读路径可以提供不可靠读取的可用性和分区容忍。要让写路径提供可用性和分区容忍度,还有很多工作需要做。我们还必须记住部署的不可变数据需求。

我们决定Apache BookKeeper是我们用例的明确选择。它接近于我们所需要的CAP系统,因为它的数据存储设计是只附加/不可变的,并且是高度复制的分布式日志。其他主要特点:

  • 一旦一个写入被确认,它总是可读的。
  • 一旦一个条目被读取,它总是可读的。
  • 没有中央主服务器,厚客户机,使用Apache Zookeeper来达成共识和元数据。
  • 没有复杂的散列/计算的数据放置。

此外,Salesforce一直鼓励开源,Apache BookKeeper社区是一个活跃且充满活力的社区。

Apache BookKeeper -几乎完美,但需要更多的工作

虽然Apache BookKeeper已经为我们的需求检查了大多数框,但仍然有差距。在我们进入差距之前,让我们了解一下Apache BookKeeper提供了什么。

  • 每个存储节点都被称为赌徒(bookie)。“Ensemble”是一组赌徒。
  • “条目”(Entry)是你能写的最小单位。它也是不可变的。
  • 一个“分类账”(Ledger)是由一系列的条目组成的,这些条目也遵循了一个不可变的只添加的模型。
  • “写入仲裁”(write quorum)是指将数据写入或复制到该条目的最大复制数。
  • “ack quorum”是在确认写入之前确认数据的赌徒数量——条目的最小复制。

从耐久性的角度来看,账本被复制到一个赌徒的集合中,账本内的条目也贯穿于整个集合中。

Ensemble Size: 5 Write Quorum Size: 3 Ack Quorum Size: 2

写入是基于可配置的写入和确认仲裁进行确认的。这提供了较低的写延迟和扩展能力。

然而,事实证明,在云中的商用硬件上运行BookKeeper具有挑战性。

数据放置策略不是原生云感知的,也没有考虑到底层的公共云提供商(云底层)。一些用户目前部署它的方式是手动识别不同可用性区域中的节点,将它们逻辑地分组在一起,并在这些节点组上改进现有的放置策略。虽然这是一种解决方案,但它不提供对区域故障的任何支持,也不提供维护和升级大规模集群时的易用性。

众所周知,所有的云底层都经常出现跨可用性区域的宕机,一般的理解是应用程序应该针对这些故障进行设计。一个很好的例子是Netflix在2012年圣诞节期间受到了亚马逊网络服务可用区中断的影响。Netflix的服务一直以有限的容量运行,即使它所依赖的底层公共云基础设施宕机了。

公共云中的问题

互联网——从网站到应用程序,甚至企业软件——大多运行在公共云提供商提供的基础设施上。这是因为公共云基础设施易于扩展,并且在一定程度上使用和维护成本更低。然而,它也有其缺陷,其中之一就是节点、区域或区域级别的不可用性。如果底层基础设施不可用,那么用户实际上什么也做不了。这可能是由于某些机器、区域或区域的停机。它甚至可能是由于硬件故障导致的网络延迟增加。因此,最终,作为在这个公共云基础设施上运行的应用程序,我们——开发人员——在设计时要考虑到它的缺点。

Apache BookKeeper没有针对这种可能性的内置答案,因此我们需要设计一个修复程序。

Salesforce 的重新架构

现在我们对问题有了大致的了解,我们开始思考如何修复它们,以便使Apache BookKeeper具有云感知并符合我们的需求。我们将这些差距归纳如下:

  • Bookies 需要在公共云中的集群中提供一个身份。
  • 为了提供更好的可用性、更容易的维护和更平滑的部署,需要将数据放置策略设计为根据可用性区域分布的集成。
  • 现有的博彩功能(如读、写和数据复制)需要更改,以便利用多区域布局,并考虑跨这些区域传输数据的成本。
  • 所有这些都应该是云底物不可知的。

让我们看看我们是如何解决这些差距的。

用于云感知的cookie和Kubernetes

现有的BookKeeper架构为每个赌徒提供了在其首次启动时分配的唯一标识。这个标识持久化在元数据存储中(Zookeeper),其他赌徒或客户可以访问它。

让Apache BookKeeper具有云感知的第一步是让每个赌徒知道他们在Kubernetes中部署的集群中的位置。我们认为这些饼干是最好的信息来源。

我们在cookie中添加了一个名为“networkLocation”的字段,该字段由两个可以定位赌徒的主要组件组成——可用性区域和升级域。使用Kubernetes允许我们不考虑底层,所以我们使用Kubernetes api来查询底层可用性区域信息。我们还根据一个涉及主机名序号索引的公式生成' upgradeDomain '。upgradeDomain可以用于滚动升级,而不影响集群的可用性。

所有这些信息都是在启动时生成的,并持久化到元数据存储中以供访问。

现在可以在生成集合、向集合指定赌徒以及决定从哪个赌徒复制或复制到哪个赌徒时使用这些信息。

公共云放置策略

现在我们在客户端中有了智能,这样它就可以与特定区域的赌徒通信,我们需要确保我们有一个利用这些信息的数据放置策略。我们的一个独特的发展是ZoneAwareEnsemblePlacementPolicy (ZEPP)。它是专为基于云的部署而设计的两级分层放置策略。ZEPP知道可用分区(AZ)和升级域(UD)。

AZ是区域内逻辑隔离的数据中心。UD是AZ内的一组节点,可以一起关闭,对服务没有影响。它还提供了理解区域何时停止和何时恢复的启发式方法。

下面是ZEPP可以使用的一个可视化部署。此部署考虑来自cookie的AZ和UD信息来对赌徒节点进行分组,如图所示。

可用性、延迟和成本

通过这些改变,我们已经能够使Apache BookKeeper真正具有云意识。然而,在设计此架构时考虑成本也很重要。大多数云基质对其服务之外的单向数据传输收费,跨可用性区域时收费是不同的。对于BookKeeper客户端来说,这是需要考虑的一个重要因素,因为它目前从集合中任意选择一个赌徒来满足读取。

如果赌徒是来自另一个可用区域比客户,这将导致不必要的收费。数据复制现在将在分布在可用性区域的赌徒之间进行,在可用性区域下降的情况下将导致更多的成本。

让我们看看如何处理这些特定的场景。

重新排序读取

目前,簿记员(BookKeeper )客户端从一个集合中任意选择一个赌徒来满足阅读。

通过我们的重新排序读取功能,客户端现在选择了一个赌徒,这样可以最小化读取延迟,同时降低成本。

重新排序读取功能开启后,客户端按以下顺序选择赌徒:

  • 从本地区域按能满足请求和有更少未决请求的赌徒顺序排序。
  • 从一个远端区域按能满足请求和有较少待处理请求的赌徒顺序。
  • 下一个来自本地区域的赌徒,其失败次数最少或未挂起的请求超过配置的阈值
  • 下一个来自远程区域的赌徒,其失败次数最少或未挂起的请求超过配置的阈值

按照这个顺序,我们在一个运行了很长时间并经历过故障的系统中进行了适当的权衡,以满足延迟和成本需求。

处理区域故障

在区域下降的情况下,现在来自不同集合的所有赌徒将开始复制他们的数据到当前可用区域的赌徒,以满足集合的规模约束和法定人数要求,造成一个“雷鸣群体问题”。

我们处理这个问题的方法是,首先决定一个区域什么时候实际上是下降的。故障可能是短暂的信号;我们不希望仅仅因为一个网络信号导致一个区域不可用而开始复制tb级的数据。与此同时,我们想要为真正的失败做好准备。

我们的解决方案有两个阶段:

  • 识别一个区域什么时候真正下降,什么时候是暂时的波动。
  • 将整个区域的大规模自动复制移动到手动操作中。

下面的图表显示了我们在声明区域关闭和区域恢复时考虑的启发式。

HighWaterMark和LowWaterMark是两个值,它们是根据一个区域中可用的赌徒数量与该区域中总赌徒数量计算的。这两个值的阈值是可配置的,因此用户可以根据他们认为的故障来决定故障的灵敏度。

当一个区域被标记为down时,我们还禁用自动复制,以避免跨区域自动复制tb级的数据。我们在其位置上添加了警报,以提醒用户可能出现的区域故障。我们相信,运营专家能够区分噪音和真正的故障,并决定是否启动整个区域的自动复制。

我们还提供了启动已禁用的自动复制的赌徒shell命令。

我们学到了什么

Apache BookKeeper是一个非常活跃的开源项目,并拥有一个令人惊讶的支持社区,社区中对该系统面临的所有挑战进行了充满活力的讨论。由于它是许多用户的真实来源,它需要成为云感知。

然而,这样的架构更改在每个级别上都有权衡和决定因素——可用性、延迟、成本、部署和维护的便利性。上述考虑和改变已经在Salesforce进行了战斗测试,现在我们可以使用Apache BookKeeper支持AZ和AZ+1故障。我们已经合并了一些更改,并将在未来的版本中继续为社区做出更多贡献。这些添加的目的是使集群更容易打补丁、升级和重新启动,同时对使用服务的影响最小。

关于作者

Anup Ghatage是旧金山的一位软件开发人员。

他喜欢在维护和开发高度可伸缩的系统中挑战问题。他目前是Salesforce的技术人员领导成员,在那里他致力于云基础设施和数据工程。他也是Apache Bookkeeper的提交者和积极贡献者。他曾任职于SAP和思科系统公司,拥有浦那大学计算机科学学士学位和卡内基梅隆大学硕士学位。你可以在推特@ghatageanup上联系到Anup。

原文:https://www.infoq.com/articles/storage-cloud-apache-bookkeeper/

本文:http://jiagoushi.pro/node/1505

讨论:请加入知识星球【首席架构师圈】或者小号【cea_csa_cto】或者QQ【2808908662】

SEO Title
Indestructible Storage in the Cloud with Apache Bookkeeper

【存储架构】块存储、文件存储和对象存储(第1节)

Chinese, Simplified

Storage

全球传输和生成的数据比以往任何时候都多。国际数据公司(IDC)的分析师预计,到2025年,全球数据层将增至163zb。这比2016年16.1 ZB的数据增长了1000%以上。数据大量增加的原因是多方面的:

生成数据的来源和设备比以前多得多——嵌入式系统和设备正在收集数据并将其传输到大数据应用程序和解决方案中进行实时分析。使用移动设备、社交媒体平台、在线购物以及随时随地使用各种应用程序的持续趋势每天都在产生大量数据。此外,企业正在进行一场向客户提供数据的转型,以满足他们对从未见过的新闻和实时数据日益增长的需求。

根据Gartner的最新预测,到2020年,超过一半的主要业务流程和系统将在其组织中加入物联网(Internet of things)的某些元素。与此同时,由大数据应用程序生成、传输和分析的数据量(这些数据将被存储在内部或外部)将大幅增长。

由于对存储的需求,管理部门和IT部门的代表已经大大增加了能够处理和存档比以往任何时候都多的数字内容的解决方案。

然而,从硬件的角度来看,现在不仅需要更大数量的存储设备——例如硬盘、ssd或SSHDs——而且还需要一个适当的文件系统来处理这种大数据增长的结果。这是因为即使不是所有的数据都存储在存储设备上,最重要的数据以及分析结果也会被存储在存储设备上。这将导致存储空间的需求增加。此外,大部分存储需求将由企业内部处理,也可以通过Amazon的S3或Microsoft Azure等云服务处理。

带有文件存储和块存储的旧的存储概念将不适用于未来的数据增长,对企业和云提供商都是如此。存储这些海量数据的解决方案是对象存储(也称为基于对象的存储)。但是,与以前的概念相比,它们之间的区别是什么?是什么使对象存储更好地适应数据爆炸?

要理解对象存储所提供的好处,必须首先了解文件存储和块存储的旧概念,因为它们之间有很大的差异。

文件、块和对象存储之间的区别

文件存储和块存储是在NAS和SAN存储系统上存储数据的方法。

在NAS系统上,它将其存储作为网络文件系统公开。当设备附加到NAS(网络附加存储)系统时,将显示一个挂载文件系统,用户可以使用适当的访问权限访问其文件。因为NAS系统必须管理用户权限、文件锁定和其他安全措施,以便多个用户可以访问文件。对NAS的访问通过NFS和SMB/CIFS协议进行处理。与任何服务器或存储解决方案一样,文件系统负责在NAS中定位文件。这对于数十万甚至数百万的文件非常有效,但对于数十亿的文件就不行了。

块存储的工作方式与此类似,但与在文件级管理数据的文件存储不同,数据存储在数据块中。几个块(例如在SAN系统中)构建一个文件。一个块由一个地址组成,如果SAN应用程序对这个地址发出scsi请求,那么它将获得这个块。存储应用程序然后决定数据块是否存储在系统中,以及存储在什么特定的磁盘或存储介质上。最后如何组合这些块以及如何访问它们决定了存储应用程序。SAN中的块没有与存储系统或应用程序相关的元数据。换句话说:块是没有描述、关联和存储解决方案所有者的数据段。一切都由SAN软件处理和控制。由于SAN和块存储经常用于需要性能的应用程序,如数据库或事务,因为数据可以访问、修改和保存。

这两种存储数据的方法多年来都运行良好。那么,为什么需要另一个概念呢?这是因为这两个概念的解决方案都需要实现用户访问权限的功能,以便对数据进行更改。

我们现在看到的是,产生的大部分数据是“固定的”或非结构化数据。内容或材料不会再改变。这就是对象存储发挥作用的地方:

对象存储中的对象是与相应元数据“绑定的数据”(即文件)。该对象获取一个惟一的ID(标识符),该标识符是从文件内容和元数据中计算出来的。应用程序通过这个ID标识对象。对象存储系统中的许多对象都存储在给定的存储磁盘上。在纯形式的对象存储中,“只能”保存一个文件(对象)的一个版本。如果用户进行了更改,相同文件的另一个版本将存储为新对象。因此,对象存储是备份或归档解决方案的完美解决方案。或者,例如,存储大量的视频或电影,这些视频或电影只能被观看,不能像在线电影流媒体网站或YouTube上的视频那样被改变。

其他概念之间的主要区别是通过支持对象存储的应用程序本身来管理对象。这意味着这里不需要真正的文件系统。这一层已经过时了。使用对象存储的应用程序将存储查询发送到解决方案中存储对象的位置。然后,在巨大的存储空间中给对象一个地址,并由应用程序本身保存在那里。

由于数据管理非常简单——没有真正的文件系统——对象存储解决方案比文件存储或基于块存储的系统更容易扩展。您只需在解决方案中添加一些磁盘,就不再需要大的管理来获得更多的存储空间。这是一个主要的好处,尤其是在指数级数据增长的时代。

因此,对象存储是处理大量数据的完美解决方案,因此被Amazon、谷歌等大型云服务提供商高度使用。但是数据保护和数据恢复呢?我们将在本文的第二部分提供这些问题的答案。

 

讨论:请加入知识星球【首席架构圈】

本文地址
https://architect.pub/block-storage-vs-file-storage-vs-object-storage-pt-1
SEO Title
Block Storage vs. File Storage vs. Object Storage (Pt. 1)

容器云架构

Chinese, Simplified
SEO Title
container cloud architecture

【容器云架构】了解 Kubernetes 网络模型

Chinese, Simplified

Kubernetes 网络支持容器化组件之间的通信。这种网络模型的主要优点是不需要在主机和容器之间映射端口。然而,配置 Kubernetes 网络模型并不是一件容易的事。在本文中,您将了解什么是 Kubernetes 网络,探索常见的实现,并发现关键的 Kubernetes 网络变化。

什么是 Kubernetes 网络?


Kubernetes (k8s) 是一个开源容器编排平台。您可以使用它来自动化本地或云中容器的部署、更新和操作。使用 k8s,您可以跨多个基础架构管理容器化工作负载,而无需担心操作系统或环境。

Kubernetes 网络是 k8s 用来实现其组件之间通信的模型。它基于扁平的网络结构,不需要你在主机和容器之间映射端口。尽管 Kubernetes 网络设置起来可能是一个挑战,但它是任何 k8s 操作的重要组成部分,并且您需要了解它才能成功部署。

常见的 Kubernetes 网络实现


使用 Kubernetes 时,平台会强制实施需要第三方工具来实现的网络模型。您可以选择许多第三方工具,但以下三个是流行的选项。

  • Flannel——一种为 k8s 设计的开源网络结构。 Flannel 通过每个主机上的二进制代理运行。该代理将子网租用分配给主机并使用 etcd 来存储配置数据。
  • Project Calico——一个开源网络供应商和政策引擎。 Calico 使您能够创建一个可扩展的网络解决方案来连接 k8s pod。它还使您能够在主机网络或服务网格层上实施安全策略。
  • Weave Net — 一种专有网络工具包,可用于创建虚拟网络。 Weave Net 包括弹性、可扩展性、安全性、多播网络和服务发现等功能。它基于去中心化架构,不需要任何外部配置服务或存储。

Kubernetes 网络变化


在标准的 Kubernetes 部署中,您应该注意多种网络变化。以下是需要了解的最常见的网络情况。

容器到容器网络


网络的高级视图描述了直接与以太网设备通信的设备或虚拟机。然而,实际上(至少对于 Linux),您机器上的每个进程都在网络命名空间内进行通信。

这个命名空间创建了一个逻辑网络堆栈,它有自己的网络设备、防火墙规则和路由。当您运行一个进程时,它默认分配给您的根网络命名空间。这为进程提供了外部访问。

在 Kubernetes 中,您的容器被分组为 pod,每个 pod 都有一个共享的命名空间。在这个 pod 中,所有容器都具有相同的端口和 IP 地址以及端口空间。为了通信,Pod 中的容器可以使用 localhost,因为它们都在同一个命名空间中运行。如果不同 Pod 中的容器需要通信,则您正在使用下面描述的 Pod 到 Pod 网络过程。

Pod 到 Pod 网络


Pod 到 Pod 网络可以发生在同一节点内或跨节点的 Pod 中。您的每个节点都有一个无类域间路由 (CIDR) 块。该块是分配给该节点内的 Pod 的一组已定义的唯一 IP 地址。这确保了每个 pod 都被提供了一个唯一的 IP,而不管它在哪个节点。

当 Pod 需要通信时,会使用虚拟以太网设备 (VED) 或 veth 对来连接 Pod。 Veth 对是分布在命名空间中的耦合网络接口。一对中的一个分配给根命名空间,另一个分配给 pod 命名空间。然后,VED 用作两个命名空间之间的中介连接。

Pod 到服务网络


Kubernetes 旨在允许根据需要动态替换 pod。这意味着 pod IP 地址不是持久的,除非采取特殊的预防措施,例如有状态的应用程序。为了解决这个问题并确保保持与 Pod 之间的通信,Kubernetes 使用了服务。

Kubernetes 服务管理 pod 状态并使您能够随时间跟踪 pod IP 地址。这些服务通过将单个虚拟 IP(集群 IP)分配给一组 pod IP 来抽象 pod 地址。然后,发送到虚拟 IP 的任何流量都会分发到相关联的 pod。

此服务 IP 允许根据需要创建和销毁 pod,而不会影响整体通信。它还使 Kubernetes 服务能够充当集群内负载均衡器,根据需要在关联的 pod 之间分配流量。

互联网到服务网络


大多数部署所需的最终网络情况是在 Internet 和服务之间。无论您是将 Kubernetes 用于内部还是外部应用程序,您通常都需要 Internet 连接。这种连接使用户能够访问您的服务和分布式团队进行协作。

在设置外部访问时,您需要使用两种技术——出口和入口。您可以使用白名单或黑名单来设置这些策略,以控制进出网络的流量。

  • Egress(出口):出口是将流量从您的节点路由到外部连接的过程。它通常通过连接到您的虚拟私有云 (VPC) 的 Internet 网关完成。此网关使用网络地址转换 (NAT) 在您的用户和您的节点所在的机器之间映射 IP。但是,它无法映射到您节点上的各个 Pod。对于这一步,Kubernetes 使用 IP 表和集群 IP 来完成通信。
  • Ingress:Ingress 是 Egress 的相反过程,涉及从外部客户端到您的 Kubernetes 服务的通信。它作为一组规则运行,定义允许哪些连接以及阻止哪些连接与您的服务进行通信。

结论


Kubernetes 网络使您能够在 k8s 网络内配置通信。它基于扁平网络结构,无需在主机和容器之间映射端口。但是,要强制实施此网络模型,您需要使用第三方工具(开源或付费的),例如 Flannel、Project Calico 和 Weave Net。

此外,在配置 Kubernetes 网络时,您需要考虑某些网络方面,这在传统网络中是不会遇到的。其中包括容器到容器网络、Pod 到 Pod 网络、Pod 到服务网络和 Internet 到服务网络。请务必妥善规划您的网络,因为错误配置可能会导致漏洞。

原文:https://www.networkcomputing.com/data-centers/understanding-kubernetes-…

本文:https://jiagoushi.pro/node/1654

SEO Title
Understanding the Kubernetes Networking Model

数据中心

Chinese, Simplified
SEO Title
data center

【数据中心】Cisco数据中心Spine and Leaf架构:Spine and Leaf架构

Chinese, Simplified

图4显示了典型的两层脊椎和叶子拓扑。

Title: Typical spine-and-leaf topology

图4. 典型的脊椎和叶子拓扑

在这个两层Clos体系结构中,每个较低层交换机(叶层)都连接到全网格拓扑中的每个顶层交换机(脊椎层)叶层由连接到服务器等设备的访问交换机组成。spine层是网络的主干,负责互连所有的leaf交换机。每个叶子开关都连接到织物中的每个脊椎开关。该路径是随机选择的,使得业务负载在顶层交换机之间均匀分布。如果其中一个顶级交换机发生故障,它只会略微降低整个数据中心的性能。

如果发生链路的超额订阅(即,如果一次生成的流量超过了活动链路上可聚合的流量),则扩展容量的过程是简单的。可以增加一个额外的spine交换机,并且可以将上行链路扩展到每个leaf交换机,从而增加层间带宽并减少超额订阅。如果设备端口容量成为一个问题,可以通过将新的叶子交换机连接到每个spine交换机并将网络配置添加到交换机来添加它。易扩展性优化了IT部门扩展网络的过程。如果较低层交换机与其上行链路之间没有发生超额订阅,则可以实现非阻塞体系结构。

对于spine和leaf架构,无论哪一个leaf交换机连接到哪一个服务器,它的流量总是必须通过相同数量的设备才能到达另一个服务器(除非另一个服务器位于同一个leaf上)。这种方法将延迟保持在可预测的水平,因为负载只需跳到一个spine开关和另一个leaf开关就可以到达目的地。

原文:https://www.cisco.com/c/en/us/products/collateral/switches/nexus-7000-series-switches/white-paper-c11-737022.html#Spineandleafarchitecture

本文:http://jiagoushi.pro/node/1032

讨论:请加入知识星球【首席架构师圈】或者加微信小号【intelligenttimes】

SEO Title
Cisco Data Center Spine-and-Leaf Architecture: Design Overview White Paper:Spine-and-leaf architecture

【数据中心】Cisco数据中心Spine and Leaf架构:数据中心演进

Chinese, Simplified

系列:Cisco数据中心Spine and Leaf架构:设计概述白皮书

数据中心是现代软件技术的基础,在企业拓展能力方面起着至关重要的作用。传统的数据中心使用三层体系结构,服务器根据位置划分为pod,如图1所示。

Title: Traditional three-tier data center design

图1. 传统的三层数据中心设计

该架构由核心路由器、聚合路由器(有时称为分发路由器)和访问交换机组成。在聚合路由器和接入交换机之间,使用生成树协议(Spanning Tree Protocol  STP)为网络的第2层部分构建无环拓扑。生成树协议提供了几个好处:它简单,是一种只需很少配置的即插即用技术VLAN在每个pod内扩展,服务器可以在pod内自由移动,无需更改IP地址和默认网关配置。然而,生成树协议不能使用并行转发路径,它总是阻塞VLAN中的冗余路径

2010年,思科引入虚拟端口通道(vPC)技术,克服了生成树协议的局限性。vPC消除了生成树阻塞端口,提供从接入交换机到聚合路由器的主动主动上行链路,充分利用了可用带宽,如图2所示。在vPC技术中,生成树协议仍然是一种故障安全机制。

vPC技术在一个相对较小的数据中心环境中工作得很好,在这个环境中,大多数流量由客户端和服务器之间的南北向通信组成。

Title: Data center design using vPC

图2. 基于vPC的数据中心设计

自2003年以来,随着虚拟技术的引入,在三层数据中心设计中,在第2层的pod中隔离的计算、网络和存储资源可以被汇集起来。这项革命性的技术创造了对更大的第2层域的需求,从访问层到核心层,如图3所示。

Title: Data center design with extended Layer 3 domain

图3. 扩展三层域的数据中心设计

随着第2层分段在所有pod中扩展,数据中心管理员可以创建一个中心的、更灵活的资源池,可以根据需要重新分配。服务器被虚拟化为一组虚拟机,这些虚拟机可以在服务器之间自由移动,而无需更改其操作参数

随着虚拟化服务器的出现,应用程序越来越多地以分布式方式部署,这导致东西方流量增加。此通信量需要有效处理,具有低且可预测的延迟。然而,vPC只能提供两个活动的并行上行链路,因此带宽成为三层数据中心体系结构中的一个瓶颈。三层体系结构中的另一个挑战是,服务器到服务器的延迟取决于使用的通信路径

为了克服这些限制,开发了一种新的数据中心设计,称为基于Clos网络的脊椎和叶子架构。这种架构已经被证明能够提供高带宽、低延迟、无阻塞的服务器到服务器连接。

 

原文:https://www.cisco.com/c/en/us/products/collateral/switches/nexus-7000-series-switches/white-paper-c11-737022.html

本文:http://jiagoushi.pro/node/1031

讨论:请加入知识星球【首席架构师圈】或者加作者小号【intelligenttimes】

 

SEO Title
Cisco Data Center Spine-and-Leaf Architecture: Design Overview White Paper :Data center evolution

【数据中心】Cisco数据中心Spine and Leaf架构:覆盖(Overlay)网络

Chinese, Simplified

 

 

现代虚拟化数据中心结构必须满足某些要求,以加快应用程序部署并支持DevOps需求。例如,结构需要支持转发表的缩放、网段的缩放、第2层网段扩展、虚拟设备移动性、转发路径优化和虚拟化网络,以便在共享物理基础设施上支持多租户。

尽管网络覆盖的概念并不新鲜,但在过去几年中,人们对网络覆盖的兴趣有所增加,因为它们有可能满足其中的一些要求。随着专门为数据中心构建的新封装帧格式的引入,人们对覆盖网络的兴趣也增加了。这些格式包括虚拟可扩展局域网(VXLAN)、使用通用路由封装(NVGRE)的网络虚拟化、大量链路的透明互连(TRILL)和位置/标识符分离协议(LISP)。网络覆盖是由共享底层物理网络的互连节点组成的虚拟网络,允许部署需要特定网络拓扑的应用程序,而无需修改底层网络(图5)。

Title: Network overlay concept

图5 网络覆盖概念

网络虚拟化覆盖的好处包括:

  • 优化设备功能:覆盖网络允许根据设备在网络中的使用位置分离(和专门化)设备功能。边缘或叶设备可以基于终端状态信息和规模优化其功能和所有相关协议,核心或脊椎设备可以基于链路状态更新优化其功能和协议,并具有快速收敛性。
  • 结构可扩展性和灵活性:覆盖技术通过聚焦于网络覆盖边缘设备的扩展,允许网络扩展。通过在结构边缘使用覆盖层,脊椎和核心设备不再需要向其转发表中添加终端主机信息。
  • 重叠寻址:数据中心中使用的大多数重叠技术允许虚拟网络ID具有唯一的作用域和标识单个专用网络。此作用域允许租户之间的MAC和IP地址可能重叠。覆盖封装还允许底层基础设施地址空间与租户地址空间分开管理。

本文档回顾了Cisco在最近的过去提供的几种spine和leaf架构设计,以及当前的设计,以及Cisco希望在不久的将来提供的设计,以满足现代虚拟化数据中心的结构要求:

  • Cisco®FabricPath脊椎和树叶网络
  • Cisco VXLAN flood and learn spine and leaf网络
  • Cisco VXLAN多协议边界网关协议(MP-BGP)以太网虚拟专用网(EVPN)脊椎和叶网络
  • 思科大规模可扩展数据中心(MSDC)第3层脊椎和叶网络

每个部分概述了撰写本文时最重要的技术组件(封装;终端主机检测和分发;广播、未知单播和多播通信转发;底层和覆盖控制平面、多租户支持等)、通用设计和设计注意事项(第3层网关等)。

原文:https://www.cisco.com/c/en/us/products/collateral/switches/nexus-7000-series-switches/white-paper-c11-737022.html#Overlaynetwork

本文:http://jiagoushi.pro/node/1033

讨论:请加入知识星球【首席架构师圈】或者小号【intelligenttimes】

SEO Title
Cisco Data Center Spine-and-Leaf Architecture:Overlay network

【数据中心】思科数据中心Spine和Leaf架构:Cisco MSDC第3层脊椎和叶网络

Chinese, Simplified

大规模可扩展数据中心(MSDCs)是一个大型数据中心,拥有数千台物理服务器(有时几十万台),其设计目的是在不影响现有基础设施的情况下扩展规模和计算能力。这种规模的环境有一组独特的网络需求,重点是应用程序性能、网络的简单性和稳定性、可见性、容易故障排除和容易的生命周期管理等。MSDCs的示例是大型云服务提供商,它们托管了成千上万的租户,以及承载大型分布式应用程序的门户网站和电子商务提供商。

思科的MSDC拓扑设计使用了第3层spine和leaf架构。叶层负责在网络结构中公布服务器子网。Spine设备负责学习基础设施路由和终端主机子网路由。在大多数情况下,spine交换机不用于直接连接外部世界或其他MSDC网络,但它会将此类流量转发到充当边界叶交换机的专用叶交换机。Border leaf交换机可以插入默认路由以吸引用于外部目的地的流量。根据需要支持的服务器的数量,MSDC设计有不同的风格:两层spine-leaf拓扑、三层spine-leaf拓扑、超大规模fabric-plane Clos设计。有关Cisco Nexus 9000和3000交换机的MSDC设计的更多详细信息,请参阅“Cisco的大规模可扩展数据中心网络结构白皮书”。

在路由设计方面,Cisco MSDC控制平面使用动态第3层协议(如eBGP)来构建路由表,该路由表最有效地将数据包从源路由到spine节点。由于eBGP的可伸缩性和稳定性,大多数客户都使用它。

图20显示了具有eBGP控制平面(AS=自治系统)的第3层MSDC脊椎和叶网络的示例。

Title: Example of MSDC Layer 3 spine-and-leaf network with BGP control plane

图20。

带BGP控制平面的MSDC第3层棘叶网络实例

第3层spine和leaf设计故意不支持跨ToR交换机的第2层vlan,因为它是第3层结构。每个主机都与一个主机子网相关联,并通过第3层路由与其他主机通信。不支持主机移动性和多租户。

由于fabric网络如此庞大,MSDC客户通常使用基于软件的方法来向网络引入更多的自动化和模块化。自动化工具可以处理不同的结构拓扑和形状因素,创建一个模块化解决方案,可以适应不同大小的数据中心。MSDC高度自动化,可以在设备上部署配置,发现结构中任何新设备的角色,监视和排除结构故障等。许多MSDC客户编写脚本以进行网络更改,使用Python、Puppet和Chef以及其他DevOps工具和Cisco技术,如开机自动配置(POAP)。

表4总结了第3层MSDC脊柱和叶网络的特征。

表4。Cisco第3层MSDC网络特性

Item

Description

Transport medium requirement

Layer 3

End-host detection

None (localized IP subnet)

End-host reachability and distribution

Unicast routing protocol (eBGP

Broadcast and unknown unicast traffic

Stops at leaf ToR switch

Underlay control plane

Unicast routing protocol (eBGP)

Layer 3 function

●  Leaf ToR switch for internal routing

●  Border leaf switch for external routing

Multicast traffic

Supports:

●  Layer 3 IP multicast traffic

Multitenancy

No

Supported hardware

●  Cisco Nexus 7000 Series Switches including the Cisco Nexus 7700 platform switches

●  Cisco Nexus 3000 Series Switches

●  Cisco Nexus 9000 Series Switches

 

原文:https://www.cisco.com/c/en/us/products/collateral/switches/nexus-7000-series-switches/white-paper-c11-737022.html#CiscoMSDCLayer3spineandleafnetwork

本文:http://jiagoushi.pro/node/1037

讨论:请加入知识星球【首席架构师圈】或者小号【intelligenttimes】

SEO Title
Cisco MSDC Layer 3 spine-and-leaf network

【数据中心】思科数据中心Spine和Leaf架构:Cisco VXLAN MP-BGP EVPN脊椎和叶网络

Chinese, Simplified

在RFC 7348定义的VXLAN泛洪学习模式下,终端主机信息学习和VTEP发现都是基于数据平面的,没有控制协议在VTEP之间分配终端主机可达性信息。为了克服flood的局限性并学习VXLAN,Cisco VXLAN MP-BGP EVPN spine and leaf架构使用多协议边界网关协议以太网虚拟专用网(MP-BGP EVPN)作为VXLAN的控制平面。该技术为VXLAN覆盖网络中的第2层和第3层转发提供了控制平面和数据平面分离以及统一的控制平面。本节介绍Cisco Nexus硬件交换机(如Cisco Nexus 5600平台交换机和Cisco Nexus 7000和9000系列交换机)上的VXLAN MP-BGP EVPN。

封装格式和标准符合性

VXLAN MP-BGP EVPN spine and leaf架构使用VXLAN封装。原始的第2层帧被封装在一个VXLAN报头中,然后放置在UDP-IP包中,并通过IP网络传输。该设计符合IETF RFC 7348和IETF bess evpn覆盖标准草案。

底层网络

VXLAN MP-BGP EVPN spine and leaf架构使用第3层IP作为底层网络。

覆盖网络

VXLAN MP-BGP EVPN spine and leaf架构使用MP-BGP EVPN作为VXLAN覆盖网络的控制平面。

广播和未知单播流量

底层IP PIM或入口复制功能用于发送广播和未知单播通信量。

在底层网络中启用IP多播时,每个VXLAN段或VNID都映射到传输IP网络中的IP多播组。每个VTEP设备都与这个多播组独立配置,并参与PIM路由。该组的多播分发树是根据参与vtep的位置通过传输网络构建的。

使用入口复制功能,底层网络是无多播的。VXLAN VTEP使用网络中其他VTEP的IP地址列表来发送广播和未知的单播通信量。这些IP地址通过BGP EVPN控制平面或静态配置在VTEPs之间交换。请注意,入口复制功能仅在Cisco Nexus 9000系列交换机上受支持。

主机检测和可达性

MP-BGP EVPN控制平面通过为驻留在VXLAN覆盖网络中的终端主机分发第2层和第3层可达性信息,提供集成路由和桥接。每个VTEP执行本地学习以从其本地连接的主机获取MAC地址(尽管是传统的MAC地址学习)和IP地址信息(基于地址解析协议[ARP]snooping)。然后,VTEP通过MP-BGP EVPN控制平面分发该信息。通过MP-BGP控制平面远程学习连接到远程VTEP的主机。该方法减少了网络洪泛现象对终端主机学习的影响,更好地控制了终端主机可达性信息的分布。

多播通信量

VXLAN MP-BGP EVPN支持使用底层IP多播或入口复制功能的覆盖租户第2层多播通信。注意,入口复制仅在Cisco Nexus 9000系列交换机上受支持。

覆盖租户第3层多播通信有两种支持方式:(1)在Cisco Nexus 7000系列交换机(包括Cisco Nexus 7700平台交换机和Cisco Nexus 9000系列交换机)的外部路由器上基于第3层PIM的多播路由。(2) Cisco Nexus 9000云级系列交换机的租户路由多播(TRM)。TRM基于IETF RFC 6513和6514中描述的基于标准的下一代控制平面(ngMVPN)。它以一种高效且有弹性的方式提供租户第3层多播流量。请注意,TRM仅在新一代Nexus9000交换机上受支持,如基于云级ASIC的交换机。有关TRM的功能支持和更多信息,请参阅本文档末尾列出的配置指南、发行说明和参考文档。

您需要仔细设计多播组缩放,如前面讨论Cisco VXLAN flood和学习多播流量的部分所述。

第三层路由功能

VXLAN MP-BGP EVPN spine and leaf网络需要提供第3层内部VXLAN路由,并保持与VXLAN结构外部网络(包括校园网、广域网和因特网)的连接。VXLAN MP-BGP EVPN使用分布式选播网关进行内部路由通信。外部路由功能集中在特定交换机上。

用于内部路由的分布式选播网关

在MP-BGP EVPN中,通过支持相同的虚拟网关IP地址和虚拟网关MAC地址,VNI中的任何VTEP都可以是其IP子网中终端主机的分布式选播网关(如图16所示)。通过EVPN中的anycast网关功能,VNI中的终端主机始终可以使用其本地vtep作为其默认网关,将流量发送到其IP子网之外。此功能使VXLAN覆盖网络中的终端主机能够为北行通信量提供最佳转发。分布式选播网关还提供了在VXLAN覆盖网络中透明主机移动性的好处。由于网关IP地址和虚拟MAC地址在VNI中的所有VTEP上都是相同的,因此当终端主机从一个VTEP移动到另一个VTEP时,它不需要发送另一个ARP请求来重新学习网关MAC地址。

Title: Distributed anycast gateway for internal routing

图16. 用于内部路由的分布式选播网关

边界叶的外部路由

图17显示了一个典型的设计,使用一对边界叶交换机连接到外部路由设备。border leaf交换机在内部运行MP-BGP EVPN,与VXLAN结构中的其他vtep交换EVPN路由。同时,它在租户VRF实例中运行正常的IPv4或IPv6单播路由,外部路由设备在外部。路由协议可以是常规的eBGP或任意选择的内部网关协议(IGP)。border leaf交换机学习外部路由,并将它们作为EVPN路由播发到EVPN域,以便其他VTEP leaf节点也可以学习用于发送出站流量的外部路由。

border leaf交换机还可以配置为将在第2层VPN EVPN地址系列中学习到的EVPN路由发送到IPv4或IPv6单播地址系列,并将它们播发到外部路由设备。在这种设计中,租户流量需要通过两个底层跳(VTEP到spine到border leaf)才能到达外部网络。但是,spine交换机只需要运行BGP-EVPN控制平面和IP路由,不需要支持VXLAN VTEP功能。

Title: Design for external routing at the border leaf

图17. 边界叶外部路由的设计

边界脊椎处的外部布线

图18显示了一个典型的设计,其中一对脊椎交换机连接到外部路由设备。在这种设计中,spine交换机需要支持VXLAN路由。spine交换机在内部运行MP-BGP EVPN,与VXLAN结构中的其他vtep交换EVPN路由。同时,它在租户VRF实例中运行正常的IPv4或IPv6单播路由,外部路由设备在外部。路由协议可以是常规的eBGP或任意选择的IGP。spine交换机学习外部路由,并将它们作为EVPN路由播发到EVPN域,以便其他VTEP叶节点也可以学习用于发送出站流量的外部路由。

spine交换机还可以配置为将在第2层VPN EVPN地址系列中学习到的EVPN路由发送到IPv4或IPv6单播地址系列,并将它们播发到外部路由设备。在这种设计中,租户流量只需要一个底层跃点(VTEP到spine)就可以到达外部网络。但是,spine交换机需要运行BGP-EVPN控制平面和IP路由以及VXLAN VTEP功能。

Title: External routing with border spine design

图18. 带边框脊椎设计的外部布线

多租户技术

VXLAN MP-BGP EVPN spine and leaf架构使用MP-BGP EVPN作为控制平面。作为MP-BGP的扩展,MP-BGP EVPN使用VRF构造继承了VPN对多租户的支持。在MP-BGP EVPN中,多个租户可以共存并共享一个公共IP传输网络,同时在VXLAN覆盖网络中拥有自己的独立VPN(图19)。

在VXLAN MP-BGP EVPN spine and leaf网络中,VNIs通过不允许第2层通信量穿越VNI边界来定义第2层域并实施第2层分割。类似地,VXLAN租户之间的第3层分割通过应用第3层VRF技术和通过使用映射到每个VRF实例的单独第3层VNI来强制租户之间的路由隔离来实现。每个租户都有自己的VRF路由实例。给定租户的VNI的IP子网位于将第3层路由域与其他租户分离的同一个第3层VRF实例中。

Title: Cisco VXLAN MP-BGP EVPN spine-and-leaf network multitenancy

图19.Cisco VXLAN MP-BGP EVPN脊椎和叶网络多租户

Cisco VXLAN MP BGP-EVPN脊椎和叶网络摘要

VXLAN MP-BGP EVPN spine and leaf架构使用MP-BGP EVPN作为VXLAN的控制平面。该设计符合IETF VXLAN标准RFC 7348和IETF-bess-evpn覆盖图草案。它为VXLAN覆盖网络中的第2层和第3层转发提供控制平面和数据平面分离以及统一的控制平面。控制平面学习终端主机第2层和第3层的可达性信息(MAC和IP地址),并通过EVPN地址族分发该信息,从而在VXLAN覆盖网络中提供集成的桥接和路由。它通过基于控制平面的主机MAC和IP地址路由分布以及对本地vtep的ARP抑制来减少网络洪泛。第3层内部路由通信量通过每个ToR交换机上的分布式选播网关以横向扩展的方式直接路由。

表3总结了VXLAN MP-BGP EVPN脊椎和叶网络的特点。

表3。Cisco VXLAN MP-BGP EVPN网络特性

Item

Description

Transport medium requirement

Layer 3

Encapsulation

VXLAN (MAC-in-IP packet encapsulation)

Unique node identifier

VTEP

End-host detection

Localized flood and learn with ARP suppression

Silent host discovery

Yes

End-host reachability and distribution

MP-BGP EVPN

Broadcast and unknown unicast traffic

Forwarded by underlay multicast (PIM) or ingress replication

(Note: Ingress replication is supported only on Cisco Nexus 9000 Series Switches.)

Underlay control plane

Any unicast routing protocol (static, OSPF, IS-IS, eBGP, etc.)

Overlay control plane

MP-BGP EVPN

Layer 3 VXLAN gateway

●  Distributed anycast gateway on leaf ToR switch for inter-VXLAN routing

●  Border leaf switch for external routing

(Note: The spine switch only needs to run BGP-EVPN control plane and IP routing.)

●  Border spine switch for external routing

(Note: The spine switch needs to support VXLAN routing VTEP on hardware.)

Layer 2 VXLAN gateway

Leaf ToR switch

Multicast traffic

Supports:

●  Layer 2 multicast traffic (forwarded by underlay PIM or ingress replication

Note: Ingress replication is supported only on Cisco Nexus 9000 Series Switches.)

●  Layer 3 IP multicast traffic (forwarded by Layer 3 PIM-based multicast routing on external router or TRM [Tenant Routed multicast, only on Cisco Nexus 9000 Cloud Scale Series Switches])

Multitenancy

Supports both Layer 2 multitenancy and Layer 3 multitenancy

Standard reference

RFC 7348 and RFC8365 (previously draft-ietf-bess-evpn-overlay)

Supported hardware

●  Cisco Nexus 7000 Series Switches including the Cisco Nexus 7700 platform switches

●  Cisco Nexus 9000 Series Switches

有关VXLAN MP-BGP EVPN的功能支持和更多信息,请参阅本文档末尾列出的配置指南、发行说明和参考文档。

 

原文:https://www.cisco.com/c/en/us/products/collateral/switches/nexus-7000-series-switches/white-paper-c11-737022.html#CiscoVXLANMPBGPEVPNspineandleafnetwork

本文:http://jiagoushi.pro/node/1036

讨论:请加入知识星球【首席架构师圈】或者小号【intelligenttimes】

SEO Title
Cisco VXLAN MP-BGP EVPN spine-and-leaf network

【数据中心】思科数据中心Spine和Leaf架构:Cisco VXLAN flood and learn spine and leaf网络

Chinese, Simplified

VXLAN是众多可用的网络虚拟化覆盖技术之一,它具有许多优点。它是一个工业标准协议,使用底层IP网络。它将第2层分段扩展到第3层基础设施上,以构建第2层覆盖逻辑网络。它将以太网帧封装到IP用户数据协议(UDP)报头中,并使用普通的IP路由和转发机制将封装的数据包通过底层网络传输到远程VXLAN隧道端点(VTEPs)。思科在2014年左右开始支持VXLanFlood,并在思科Nexus5600平台、思科Nexus7000和9000系列等多种思科Nexus交换机上学习spine和leaf技术。本节介绍Cisco VXLAN洪水和学习这些Cisco硬件交换机的特性。

封装格式和标准符合性

Cisco VXLAN flood and learn技术符合IETF VXLAN标准(RFC 7348),该标准定义了基于多播的flood,并在没有控制平面的情况下学习VXLAN。最初的第2层帧用一个VXLAN报头封装,然后放在UDP-IP包中并通过IP网络传输。

底层网络

VXLAN flood and learn spine and leaf网络使用第3层IP作为底层网络。底层IP多播用于减少参与VXLAN段的主机集的泛洪范围。每个VXLAN段都有一个VXLAN网络标识符(VNID),VNID被映射到传输IP网络中的IP多播组。每个VTEP设备都与这个多播组独立配置,并参与PIM路由。该组的多播分发树是根据参与vtep的位置通过传输网络构建的。在底层网络中启用多播功能的要求对一些组织提出了挑战,因为它们不希望在其数据中心或广域网中启用多播。

Cisco Nexus 9000系列引入了入口复制功能,因此底层网络是无多播的。VXLAN VTEP使用网络中其他VTEP的IP地址列表来发送广播和未知的单播通信量。这些IP地址通过静态入口复制配置在VTEP之间交换(图10)。

Title: VXLAN IP Underlay Network

 

图10. VXLAN IP底层网络

覆盖网络

VXLAN flood and learn spine and leaf网络没有覆盖网络的控制平面。第二层覆盖网络是在第三层IP底层网络之上通过VTEP隧道机制来传输第二层包而建立的。覆盖网络使用flood和learn语义(图11)。

Title: VXLAN Overlay network

图11. VXLAN覆盖网络

广播和未知单播流量

底层IP PIM或入口复制功能用于发送广播和未知单播通信量。请注意,入口复制功能仅在Cisco Nexus 9000系列交换机上受支持。

主机检测和可达性

VXLAN flood和learn spine和leaf网络依赖于初始数据平面流量泛洪,使VTEPs能够发现彼此,并学习每个VXLAN段的远程主机MAC地址和MAC到VTEP映射。完成MAC到VTEP映射后,VTEPs在单播流中转发VXLAN流量。

多播通信量

在VXLAN flood and learn spine and leaf网络中,overlay tenant Layer 2多播流量支持使用underlay IP PIM或入口复制功能。注意,入口复制仅在Cisco Nexus 9000系列交换机上受支持。

第三层IP多播业务通过基于第三层PIM的多播路由转发。

多播组缩放需要仔细设计。理想情况下,您应该将一个VXLAN段映射到一个IP多播组,以提供最佳的多播转发。您也可以让多个VXLAN段共享核心网络中的单个IP多播组;但是,多播组的过载会导致次优的多播转发。

第三层路由功能

与传统的VLAN环境一样,在许多情况下都需要在VXLAN段之间或从VXLAN段到VLAN段之间进行路由。在典型的VXLAN flood和learn spine和leaf网络设计中,leaf Top of Rack(ToR)交换机作为VTEP设备启用,以扩展机架之间的第2层网段。这些vtep是VXLAN到VLAN或VLAN到VXLAN桥接的第2层VXLAN网关。当需要在VXLAN段之间或从VXLAN段路由到VLAN段和vice visa时,需要在一些vtep上启用第3层VXLAN网关功能。常用的设计是脊椎层的内部和外部布线,以及叶层的内部和外部布线。两种设计都提供集中路由:即第3层内部和外部路由功能集中在特定交换机上。

脊椎层的内部和外部布线

如图12spine层的内部和外部路由设计所示,leaf-ToR-VTEP交换机是一个第2层VXLAN网关,用于在第3层IP网络上传输第2层网段。脊椎开关有两个功能。它是底层第3层IP网络的一部分,传输VXLAN封装的数据包。它还执行内部VXLAN路由和外部路由。内部和外部路由通信量需要从叶VTEP到要路由的脊椎交换机进行一次底层跃点。

注意,使用热备用路由器协议(HSRP)和vPC配置时,VXLAN间活动活动网关的最大数量为两个。另外,spine Layer 3 VXLAN网关学习主机MAC地址,因此您需要考虑MAC地址规模,以避免超过硬件的可扩展性限制。

Title: Internal and external routing on the spine layer

图12. 脊椎层的内部和外部布线

边界页上的内部和外部路由

如图13边界叶上的内部和外部路由设计所示,叶ToR VTEP交换机是一个用于在底层第3层IP网络上传输第2层网段的第2层VXLAN网关。spine交换机只是底层第3层IP网络的一部分,用于传输VXLAN封装的数据包。它不会学习覆盖主机的MAC地址。border leaf路由器通过第3层VXLAN网关启用,并执行内部VXLAN路由和外部路由。内部和外部路由流量需要从叶VTEP到脊椎交换机,然后到边界叶交换机的两个下层跃点才能到达外部网络。

在HSRP和vPC配置下,VXLAN间活动网关的最大数量为两个。另外,border leaf Layer 3 VXLAN gateway学习主机MAC地址,因此您需要考虑MAC地址规模,以避免超出硬件的可扩展性限制。

Title: Internal and external routing on the border leaf

图13. 边界页上的内部和外部路由

多租户技术

VXLAN flood and learn spine and leaf网络支持第2层多租户(图14)。VXLAN使用一个24位的段ID,或者VNID,它允许多达1600万个VXLAN段在同一个管理域中共存。为了支持多租户,相同的VLAN可以在不同的VTEP交换机上重用,并且VTEP上接收到的IEEE 802.1Q标记帧被映射到特定的vni。vni用于在第2层为每个租户提供隔离。VLAN在叶VTEP交换机上具有局部意义,VNI在VXLAN网络上具有全局意义。

Title: Layer 2 multitenancy example using the VNI

图14.使用VNI的第2层多租户示例

VXLAN flood and learn spine and leaf网络还支持使用VRF lite的第3层多租户(图15)。VXLAN泛洪学习网络是一个第二层覆盖网络,第三层SVI位于第二层覆盖网络的顶部。使用VRF-lite,VXLAN泛洪学习网络支持的vlan数量为4096。

Title: Layer 3 multitenancy example using VRF-lite

图15. 使用VRF lite的第3层多租户示例

Cisco VXLAN flood and learn spine and leaf网络概述

VXLAN flood and learn spine and leaf网络符合IETF VXLAN标准(RFC 7348)。它在第3层IP底层网络上传输第2层帧。然而,它仍然是一个洪水和学习为基础的第二层技术。随着广播域中主机数量的增加,它面临着与FabricPath spine和leaf网络相同的泛洪挑战。第3层功能位于第2层网络的顶部。常见的第3层设计提供集中路由:即第3层路由功能集中在特定交换机(脊椎交换机或边界叶交换机)上。VXLAN flood and learn spine和leaf网络最多支持两个活动网关和vPC,用于内部VXLAN路由。

表2总结了VXLAN洪水和学习脊椎和叶网络的特征。

表2。Cisco VXLAN泛洪学习网络特性

Item

Description

Transport medium requirement

Layer 3

Encapsulation

VXLAN (MAC-in-IP packet encapsulation)

Unique node identifier

VTEP

End-host detection

Flood and learn

Silent host discovery

Yes

End-host reachability and distribution

Flood and learn

Broadcast and unknown unicast traffic

Forwarded by underlay PIM or

ingress replication

(Note: Ingress replication is supported only on Cisco Nexus 9000 Series Switches)

Underlay control plane

Any unicast routing protocol

(static, Open Shortest Path First [OSPF], IS-IS, External BGP [eBGP], etc.)

Overlay control plane

Layer 3 VXLAN gateway

●  Internal and external routing at spine VTEP

●  Internal and external routing at border leaf VTEP

●  Up to 2 active-active gateways with vPC

Layer 2 VXLAN gateway

Leaf ToR switch

Multicast traffic

●  Supports:

●  Layer 2 IP multicast traffic (forwarded by underlay PIM)

●  Layer 3 IP multicast traffic (forwarded by Layer 3 PIM–based multicast routing

Multitenancy

●  Layer 2 multitenancy with VNI

●  Layer 3 multitenancy with VRF-lite

Standard reference

RFC 7348

Supported hardware

●  Cisco Nexus 7000 Series Switches including the Cisco Nexus 7700 platform switches

●  Cisco Nexus 9000 Series Switches

有关Cisco VXLAN flood和learn技术的功能支持和更多信息,请参阅本文档末尾列出的配置指南、发行说明和参考文档。

原文:https://www.cisco.com/c/en/us/products/collateral/switches/nexus-7000-series-switches/white-paper-c11-737022.html#CiscoFabricPathspineandleafnetwork

本文:http://jiagoushi.pro/node/1035

讨论:请加入知识星球【首席架构师圈】或者小号【intelligenttimes】

 

SEO Title
Cisco VXLAN flood-and-learn spine-and-leaf network

【数据中心】思科数据中心Spine和Leaf架构:思科FabricPath Spine和Leaf网络

Chinese, Simplified

思科在2010年引入了FabricPath技术。FabricPath提供了新的功能和设计选项,使网络运营商能够创建以太网结构,从而提高带宽可用性,提供设计灵活性,并简化和降低网络和应用程序部署和操作的成本。典型的FabricPath网络使用脊椎和叶子结构

FabricPath技术使用了传统第2层和第3层技术的许多最佳特性。它保留了第2层环境的简单配置、即插即用的部署模型。还介绍了一种称为FabricPath中间系统到中间系统(IS-IS)的控制平面协议。此最短路径优先(SPF)路由协议用于确定FabricPath网络中任何给定目的FabricPath交换机的可达性并选择最佳路径。其结果是增加了稳定性和可扩展性,快速收敛,以及使用第3层路由环境中典型的多条并行路径的能力。

封装格式和标准符合性

FabricPath spine and leaf网络是Cisco的专有网络,但基于TRILL标准。它在MAC帧封装中使用FabricPath-MAC。

底层网络

FabricPath spine和leaf网络在MAC帧封装中使用第2层FabricPath MAC,在底层网络中使用FabricPath IS-IS作为控制平面。每个FabricPath交换机由FabricPath交换机ID标识。FabricPath is-is控制平面构建关于如何到达其他FabricPath交换机的可达性信息。

覆盖网络

FabricPath没有覆盖网络的覆盖控制平面。覆盖网络中的终端主机信息是通过会话学习的泛洪学习机制来学习的。

广播和未知单播流量

对于FabricPath网络,FabricPath IS-IS控制平面默认创建两个多目标树,通过FabricPath网络承载广播流量、未知单播流量和多播流量。FabricPath中的广播和未知单播流量被淹没到VLAN或广播域中的所有FabricPath边缘端口。

主机检测和可达性

FabricPath交换机依靠初始数据平面流量洪泛来学习终端主机可达性信息。随着广播域中主机数量的增加,泛洪数据包的负面影响更加明显。在FabricPath网络设计中,需要仔细考虑广播和未知单播流量泛滥的影响。FabricPath多拓扑特性等特性的存在,有助于限制FabricPath网络的一个子区域中的流量泛滥。

多播通信量

对于FabricPath网络,FabricPath IS-IS控制平面默认创建两个多目标树,通过FabricPath网络承载广播流量、未知单播流量和多播流量。默认情况下,IP多播流量仅限于那些连接了感兴趣的多播接收器或多播路由器并使用Internet组管理协议(IGMP)侦听的FabricPath边缘端口。对于第2层多播通信量,进入FabricPath交换机的通信量被散列到要转发的多目标树。对于第3层IP多播通信量,需要使用协议无关多播(PIM)通过第3层多播转发通信量。将通信量路由到目标VLAN后,使用目标VLAN中的多目标树将其转发。

第三层路由功能

FabricPath是一种第2层网络结构技术,它允许您通过在第2层添加更多的spine节点和leaf节点来轻松地扩展网络容量。但大多数网络都不是纯的第二层网络。服务器可以与不同子网中的其他服务器通信,也可以通过广域网或Internet与远程分支办公室中的客户端通信。该流量需要由FabricPath交换机(默认网关和边界交换机)上启用的第3层功能路由。

在FabricPath网络中放置第3层函数需要仔细设计。有两个主要的设计选项可供选择:边界脊椎处的内部和外部布线,以及边界叶处的内部和外部布线。两种设计都提供集中路由:即第3层路由功能集中在特定交换机上。

边界脊椎处的内部和外部布线

如图6边界spine的内部和外部路由设计所示,spine交换机充当第2层和第3层边界和服务器子网网关。Spine交换机正在执行VLAN内FabricPath帧交换。spine交换机上的交换机虚拟接口(svi)对东西向内部流量执行VLAN间路由,并与第3层路由上行链路交换路由邻接信息以路由南北向外部流量。路由流量只需经过一个跃点即可到达要路由的脊椎交换机上的默认网关。

FabricPath技术目前最多支持四个FabricPath选播网关。如果spine和leaf网络有四个以上的spine交换机,则第2层和第3层边界需要分布在spine交换机上。此外,在spine交换机上启用SVIs时,spine交换机禁用会话学习并学习相应子网中的MAC地址。您需要考虑MAC地址规模,以避免超出硬件的可伸缩性限制。

Title: Internal and external routing at the border spine

图6。边界脊椎处的内部和外部布线

边界页上的内部和外部路由

如图7边界页的内部和外部路由设计所示,spine交换机充当第2层FabricPath交换机,仅执行VLAN内FabricPath帧交换。它不会学习主机MAC地址。第2层和第3层功能在一些叫做border leaf switches的FabricPath leaf switches上启用。边界叶交换机上的SVI对东西向内部流量执行VLAN间路由,并与第3层路由上行链路交换路由邻接,以路由南北向外部流量。

但是路由流量需要通过两个跳:叶到脊椎,然后到要路由的边界叶上的默认网关。在设计中,最多可以启用四个FabricPath选播网关,并在边界页上进行路由。您需要考虑MAC地址规模,以避免超过border leaf交换机的可伸缩性限制。

Title: Internal and external routing at the border leaf

图7。边界页上的内部和外部路由

多租户技术

FabricPath spine和leaf网络通过VXLAN网络(VN)段特性支持第2层多租户(图8)。VN段特性提供了一种在线路上标记数据包的新方法,取代了传统的IEEE 802.1qvlan标记。此功能使用24位增加的名称空间。客户边缘链路(访问和中继)承载传统的VLAN标记和未标记帧。这些是VN段边缘端口。

FabricPath链路(交换端口模式:FabricPath)为定义了VXLAN网络标识符(vni)的vlan携带VN段标记帧。这些是VN段核心端口。为了支持多租户,相同的vlan可以在不同的FabricPath叶子交换机上重用,IEEE 802.1Q标记的帧被映射到特定的VN段。VN段用于在第2层为每个租户提供隔离。VLAN在FabricPath叶子交换机上具有局部意义,VN段在FabricPath网络上具有全局意义。在每个FabricPath leaf交换机上,网络保留4096个VLAN空间,但在整个FabricPath网络中,至少理论上可以支持1600万个VN段。

Title: Layer 2 multitenancy example with FabricPath VN-Segment feature

图8. 具有FabricPath VN段特性的第2层多租户示例

FabricPath spine和leaf网络还支持使用虚拟路由和转发lite(VRF lite)的第3层多租户,如图9所示。FabricPath网络是一个第二层网络,第三层svi位于第二层FabricPath交换机的顶部。使用VRF lite,FabricPath网络支持的VLAN数量为4096。

Title: Layer 3 multitenancy example with VRF-lite

图9. VRF lite的第3层多租户示例

Cisco FabricPath脊椎和叶网络摘要

FabricPath spine and leaf网络是Cisco的专有网络,但它是一种成熟的技术,已经得到了广泛的应用。它提供了一个简单、灵活、稳定的网络,具有良好的可扩展性和快速收敛特性,并且可以在第2层使用多条并行路径。但是FabricPath网络是基于flood和learn的第二层技术。它的控制平面协议FabricPath IS-IS是用来确定FabricPath交换机ID可达性信息的。FabricPath交换机依靠初始数据平面流量洪泛来学习终端主机可达性信息。随着广播域中主机数量的增加,泛洪数据包的负面影响变得更加明显。第三层功能位于第二层网络的顶部。常见的第3层设计使用集中路由:即第3层路由功能集中在特定交换机(脊椎交换机或边界叶交换机)上。FabricPath网络支持多达四个用于内部VLAN路由的选播网关。

表1总结了FabricPath脊柱和叶网络的特征。

表1.Cisco FabricPath网络特性

Item

Description

Transport medium

Layer 1

Encapsulation

FabricPath (MAC-in-MAC frame encapsulation)

Unique node identifier

FabricPath switch ID

End-host detection

Flood and learn

Silent host discovery

Yes

End-host reachability and distribution

Flood and learn plus conversational learning

Broadcast and unknown unicast traffic

Flood by FabricPath IS-IS multidestination tree

Underlay control plane

FabricPath IS-IS

Overlay control plane

Layer 3 routing function

●  Internal and external routing at border spine

●  Internal and external routing at border leaf

●  Up to 4 FabricPath anycast gateways supported

Multicast traffic

Supports:

●  Layer 2 multicast traffic (forwarded by multidestination tree)

●  Layer 3 IP multicast traffic (forwarded by Layer 3 multicast using PIM)

Multitenancy

●  Layer 2 multitenancy with VN-segment

●  Layer 3 multitenancy with VRF-lite

Standard reference

TRILL based (Cisco proprietary)

Supported hardware

●  Cisco Nexus ® 7000 Series Switches including the Cisco Nexus 7700 platform switches

●  Cisco Nexus 5500 and 5600 platform switches

●  Cisco Nexus 6000 Series Switches

 

有关功能支持和Cisco FabricPath技术的更多信息,请参阅本文档末尾列出的配置指南、发行说明和参考文档。

原文:https://www.cisco.com/c/en/us/products/collateral/switches/nexus-7000-series-switches/white-paper-c11-737022.html#CiscoFabricPathspineandleafnetwork

本文:http://jiagoushi.pro/node/1034

讨论:请加入知识星球【首席架构师圈】或者加小号【intelligenttimes】

 

SEO Title
Cisco Data Center Spine-and-Leaf Architecture: Cisco FabricPath spine-and-leaf network

【数据中心】思科数据中心Spine和Leaf架构:数据中心结构管理、自动化和总结

Chinese, Simplified

数据中心结构管理和自动化

建立数据中心没有单一的方法。同样,没有单一的方法来管理数据中心结构。Cisco、第三方和开源社区提供了许多不同的工具,可用于监视、管理、自动化和排除数据中心结构的故障。

思科数据中心网络管理器

Cisco Data Center Network Manager(DCNM)是Cisco®统一结构的管理系统。它使您能够配置、监视和排除数据中心网络基础架构的故障。Cisco DCNM可以以四种模式安装:

  • 经典LAN模式:管理部署在传统设计中的Cisco Nexus数据中心基础设施,如vPC设计、FabricPath设计等。它提供实时运行状况摘要、警报、可见性信息等。
  • 媒体控制器模式:为媒体解决方案管理Cisco IP结构网络,并帮助从SDI路由器过渡到基于IP的基础设施。它提供工作流自动化、流策略管理和第三方工作室设备集成等(此模式与本白皮书无关)
  • 存储区域网络(SAN)控制器模式:管理Cisco MDS系列交换机以进行存储网络部署,并对所有SAN管理功能进行图形控制。它提供丰富的洞察遥测信息和其他高级分析信息等(此模式与本白皮书无关)
  • LAN结构模式:提供结构生成器,用于自动VXLAN EVPN结构底层部署、覆盖部署、端到端流跟踪、报警和故障排除、配置符合性和设备生命周期管理等。

Cisco DCNM 11.2版支持Cisco Network Insights应用程序;这些应用程序由可添加到数据中心网络管理器(DCNM)的监视实用程序组成。支持两个Cisco Network Insights应用程序:

  • Cisco网络洞察-顾问(NIA):监控数据中心网络并确定可以解决的问题,以保持可用性并减少意外停机。NIA不断扫描客户的网络,并提供前瞻性建议,重点是维护可用性,并提醒客户可能影响正常运行时间的潜在问题。
  • Cisco Network Insights–Resources(NIR):提供一种通过数据收集收集信息的方法,以获得整个数据中心网络管理器(DCNM)中可用资源及其活动流程和配置的概述。

有关Cisco DCNM的更多信息,请参阅https://www.cisco.com/c/en/us/products/cloud-systems-management/prime-d…

有关Cisco Network Insights的更多信息,请参阅https://www.cisco.com/c/en/us/support/data-center-analytics/network-ins…

 

结论

本文档介绍了Cisco的几种spine和leaf架构设计,包括编写本文档时每个架构最重要的技术组件和设计考虑事项。

Cisco FabricPath spine and leaf网络是Cisco的专有网络。它简单、灵活、稳定,具有良好的可扩展性和快速收敛性,支持第二层多条并行路径。但是FabricPath网络是一种基于洪水和学习的第二层技术。其控制平面协议为FabricPath is-is,用于确定FabricPath交换机ID可达性信息。FabricPath交换机依靠初始数据平面流量洪泛来学习终端主机可达性信息。随着广播域中主机数量的增加,泛洪数据包的负面影响变得更加明显。第三层路由功能位于第二层网络之上。常见的第3层设计使用集中路由:即第3层路由功能集中在特定交换机(脊椎交换机或边界叶交换机)上。FabricPath网络支持多达四个用于内部VLAN路由的选播网关。

Cisco VXLAN flood and learn spine and leaf网络符合IETF VXLAN标准(RFC 7348)。它通过第3层IP底层网络传输第2层帧。但它仍然是一种基于洪水和学习的第二层技术。随着广播域中主机数量的增加,它将面临与FabricPath spine和leaf网络相同的泛洪挑战。第三层路由功能位于第二层网络之上。常见的第3层设计使用集中路由:即第3层路由功能集中在特定交换机(脊椎交换机或边界叶交换机)上。VXLAN flood and learn spine和leaf网络最多支持两个活动网关和vPC,用于内部VXLAN路由。

Cisco VXLAN MP-BGP EVPN spine and leaf架构使用MP-BGP EVPN作为VXLAN的控制平面。它符合IETF VXLAN标准RFC 7348和RFC8365(先前起草的IETF-bess-evpn覆盖)。它为VXLAN覆盖网络中的第2层和第3层转发提供控制平面和数据平面分离以及统一的控制平面。第3层内部路由通信量通过每个ToR交换机上的分布式选播网关以横向扩展的方式直接路由。VXLAN MP-BGP EVPN spine and leaf架构具有以下主要优点:

  • MP-BGP EVPN协议基于行业标准,允许多供应商互操作。
  • 它使终端主机第2层和第3层可达性信息的控制平面学习成为可能,使组织能够建立更健壮和可扩展的VXLAN覆盖网络。
  • 它使用已有十年历史的MP-BGP VPN技术来支持可扩展的多租户VXLAN覆盖网络。
  • EVPN地址族携带第2层和第3层可达性信息,从而在VXLAN覆盖网络中提供集成桥接和路由。
  • 通过基于协议的主机MAC地址IP地址路由分配和本地VTEP上的ARP抑制,减少网络洪泛。
  • ●通过每个ToR交换机上的分布式选播功能,为东西和南北交通提供最佳转发,并支持工作负载移动性。
  • 它提供VTEP对等发现和认证,降低VXLAN覆盖网络中恶意VTEP的风险。
  • 它提供了在第2层建立主动-主动多址的机制。
  • 其底层和覆盖管理工具提供许多网络管理功能,简化工作负载可见性,优化故障排除,自动化结构组件供应,自动化覆盖租户网络供应等。

Cisco VXLAN MP-BGP EVPN spine and leaf架构是Cisco的最新创新之一。它旨在简化、优化和自动化现代多租户数据中心结构环境。

 

Cisco脊椎和叶子第2层和第3层结构的比较

表5比较了本文中讨论的四种Cisco spine和leaf架构:FabricPath、VXLAN flood和learn、VXLAN MP-BGP EVPN和MSDC Layer 3网络。请仔细阅读此表和本文档的每个部分,并阅读参考文档以获取更多信息,帮助您选择最适合您的数据中心环境的技术。

表5. Cisco脊椎和叶子第2层和第3层结构的比较

注:自2019年7月起更新

Cisco Spine-and-Leaf Layer 2 and Layer 3 Fabric

Cisco FabricPath

Cisco VXLAN Flood and Learn

Cisco VXLAN MP-BGP EVPN

Cisco MSDC Layer 3

Transport medium requirement

Layer 1

Layer 3

Layer 3

Layer 3

Encapsulation

FabricPath (MAC-in-MAC frame encapsulation)

VXLAN (MAC-in-IP packet encapsulation)

VXLAN (MAC-in-IP packet encapsulation)

Unique node identifier

FabricPath switch ID

VTEP

VTEP

Layer 3 IP address or loopback address

End-host detection

Flood and learn

Flood and learn

Localized flood and learn with ARP suppression

None (localized IP subnet)

Silent host discovery

Yes

Yes

Yes

No

End-host reachability and distribution

Flood and learn plus conversational learning

Flood and learn

MP-BGP EVPN

Unicast routing protocol (eBGP)

Broadcast and unknown unicast traffic

Flood by FabricPath IS-IS multidestination tree

Forwarded by underlay PIM or ingress replication

(Note: Ingress-replication is supported only on Cisco Nexus 9000 Series Switches.)

Forwarded by underlay PIM or

ingress replication

(Note: Ingress replication is supported only on Cisco Nexus 9000 Series Switches.)

Stops at leaf ToR switch

Underlay control plane

FabricPath IS-IS

Any unicast routing protocol (static, OSPF, IS-IS, eBGP, etc.)

Any unicast routing protocol (static, OSPF, IS-IS, eBGP, etc.)

Unicast routing protocol (eBGP)

Overlay control plane

MP-BGP EVPN

Layer 3 gateway

●  Internal and external routing at border spine

●  Internal and external routing at border leaf

●  Up to 4 FabricPath anycast gateways supported

●  Internal and external routing at spine VTEP

●  Internal and external routing at border leaf VTEP

●  Up to 2 active-active gateways with vPC supported

●  Distributed anycast gateway on leaf ToR switch for inter-VXLAN routing

●  Border leaf switch for external routing

(Note: The spine switch only needs to run BGP-EVPN control plane and IP routing.)

●      Border spine switch for external routing

(Note: The spine switch needs to support VXLAN routing on hardware.)

●  Leaf ToR switch for internal routing

●  Border leaf switch for external routing

Layer 2 VXLAN gateway

Leaf ToR switch

Leaf ToR switch

Multicast traffic

Supports:

●  Layer 2 multicast traffic (forwarded by multidestination tree)

●  Layer 3 IP multicast traffic (forwarded by Layer 3 PIM)

Supports:

●  Layer 2 multicast traffic (forwarded by underlay PIM)

●  Layer 3 IP multicast traffic (forwarded by Layer 3 PIM)

Supports:

●  Layer 2 multicast traffic (forwarded by underlay PIM or ingress replication

(Note: Ingress-replication is supported only on Cisco Nexus 9000 Series Switches.)

●  Layer 3 IP multicast traffic (forwarded by Layer 3 PIM-based multicast routing on external router or Tenant Routed Multicast (TRM)).

(Note: TRM is supported on Cisco Nexus 9000 Cloud Scale Series Switches)

Supports:

●  Layer 3 IP multicast traffic

Multi-tenancy

●  Layer 2 multitenancy with VN-segment

●  Layer 3 multitenancy with VRF-lite

●  Layer 2 multitenancy with VNI

●  Layer 3 multitenancy with VRF-lite

●  Support for both Layer 2 multitenancy and Layer 3 multitenancy

No

Standard reference

TRILL-based (Cisco proprietary)

RFC 7348

RFC 7348 and RFC8365 (previously draft-ietf-bess-evpn-overlay)

Routing protocol

Supported hardware

●  Cisco Nexus 7000 Series Switches including the Cisco Nexus 7700 platform switches

●  Cisco Nexus 5500 and 5600 platform switches

●  Cisco Nexus 6000 Series Switches

●  Cisco Nexus 7000 Series Switches including the Cisco Nexus 7700 platform switches

●  Cisco Nexus 9000 Series Switches

●  Cisco Nexus 7000 Series Switches including the Cisco Nexus 7700 platform switches

●  Cisco Nexus 9000 Series Switches

●  Cisco Nexus 7000 Series Switches including the Cisco Nexus 7700 platform switches

●  Cisco Nexus 3000 Series Switches

●  Cisco Nexus 9000 Series Switches

For more information

For additional information, see the following references:

●      Data center overlay technologies: https://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-730116.html

●      VXLAN network with MP-BGP EVPN control plane: https://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/guide-c07-734107.html

●      Cisco Massively Scalable Data Center white paper: https://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-743245.html

●      XLAN EVPN TRM blog:
https://blogs.cisco.com/datacenter/vxlan-innovations-on-the-nexus-os-part-1-of-2

 

 

原文:https://www.cisco.com/c/en/us/products/collateral/switches/nexus-7000-series-switches/white-paper-c11-737022.html#Conclusion

本文:http://jiagoushi.pro/node/1038

讨论:请加入知识星球【首席架构师圈】或者微信小号【intelligenttimes】

SEO Title
Data Center fabric management and automation and Conclusion

【数据中心运维】集成和自动化的平台 StackStorm概述

Chinese, Simplified

关于

StackStorm是一个用于跨服务和工具进行集成和自动化的平台。它将您现有的基础结构和应用程序环境联系在一起,这样您就可以更容易地自动化该环境。它特别关注在事件发生后采取的行动。

StackStorm帮助自动化常见的操作模式。一些例子:

  • 方便的故障诊断——触发Nagios、senu、New Relic和其他监控系统捕获的系统故障,对物理节点、OpenStack或Amazon实例和应用程序组件进行一系列诊断检查,并将结果发布到共享的通信上下文,如HipChat或JIRA。
  • 自动修复——识别和验证OpenStack计算节点上的硬件故障,适当地疏散实例,并向管理员发送关于潜在停机时间的电子邮件,但如果出现任何问题——冻结工作流并调用PagerDuty唤醒人工。
  • 持续部署——使用Jenkins构建和测试,提供一个新的AWS集群,使用负载均衡器打开一些流量,并根据NewRelic的应用程序性能数据进行前滚或后滚。

StackStorm帮助您将这些和其他操作模式组合为规则和工作流或操作。这些规则和工作流(StackStorm平台内的内容)被存储为代码,这意味着它们支持与现在用于代码开发的协作方法相同的方法。它们可以与更广泛的开源社区共享,例如通过StackStorm社区。

工作原理

_images/architecture_diagram.jpg

StackStorm通过可扩展的包含传感器和操作的适配器集插入到环境中。

  1. 传感器是Python插件,用于接收或监视事件的入站或出站集成。当来自外部系统的事件发生并由传感器处理时,将向系统发出StackStorm触发器。
  2. 触发器是外部事件的StackStorm表示。有通用触发器(如计时器、网络挂钩)和集成触发器(如senu alert、JIRA issue updated)。可以通过编写传感器插件来定义新的触发器类型。
  3. 操作是StackStorm出站集成。有通用操作(ssh、REST调用)、集成(OpenStack、Docker、Puppet)或自定义操作。操作可以是Python插件,也可以是任何脚本,都可以通过添加几行元数据在StackStorm中使用。用户可以通过CLI或API直接调用操作,或者作为规则和工作流的一部分使用和调用操作。
  4. 规则将触发器映射到操作(或工作流),应用匹配标准并将触发器有效负载映射到操作输入。
  5. 工作流将操作缝在一起形成“超级操作”,定义顺序、转换条件并传递数据。大多数自动化操作不止一步,因此需要多个操作。工作流与“原子”操作一样,可以在操作库中使用,可以手动调用或由规则触发。
  6. 包是内容部署的单元。它们通过分组集成(触发器和操作)和自动化(规则和工作流)简化了StackStorm可插内容的管理和共享。越来越多的包可用于StackStorm交换。用户可以创建自己的包,在Github上共享它们,或者提交到StackStorm Exchange。
  7. 动作执行的审计跟踪,手动或自动,记录和存储触发上下文和执行结果的完整细节。它还被捕获在审计日志中,以便与外部日志和分析工具集成:LogStash、Splunk、statsd、syslog。

StackStorm是一个具有模块化架构的服务。它由通过消息总线通信的松散耦合的服务组件组成,并水平扩展以按比例交付自动化。StackStorm有一个Web UI,一个CLI客户端,当然还有一个完整的REST API。我们还提供了Python客户端绑定,以简化开发人员的工作。

StackStorm是一个新产品,正在积极开发中。我们非常渴望参与社区,获得反馈并完善我们的方向。

 

原文:https://docs.stackstorm.com/overview.html

本文:http://jiagoushi.pro/node/835

讨论:请加入知识星球【首席架构师圈】或者飞聊小组【首席架构师智库】

SEO Title
StackStorm Overview

服务网格

Chinese, Simplified
SEO Title
service mesh

网络架构

Chinese, Simplified
SEO Title
network architecture

【AWS网络架构】AWS VPN features

Chinese, Simplified

AWS VPN

AWS VPN由两种服务组成:AWS站点对站点VPN和AWS客户端VPN。通过站点到站点VPN IP安全(IPSec)设置或客户机VPN传输层安全(TLS)隧道,您可以安全地、私有地访问云资源。AWS站点到站点VPN允许您安全地将您的本地网络或分支机构站点连接到您的Amazon虚拟私有云(Amazon VPC)。AWS客户端VPN使您能够安全地将用户连接到AWS或on-premises网络。

AWS站点到站点VPN功能

AWS站点到站点VPN通过IP安全(IPSec)隧道将您的数据中心或分支机构扩展到云,并支持连接到虚拟专用网关和AWS传输网关。您可以选择在IPSec隧道上运行边界网关协议(BGP),以获得高可用性的解决方案。

安全连接

AWS站点到站点VPN允许您创建到虚拟网关或AWS传输网关的IPSec隧道。这些端点之间的隧道通信可以使用AES128或AES256加密,并使用Diffie-Hellman组进行密钥交换,提供了完美的正向保密。AWS站点到站点VPN将使用SHA1或SHA2散列功能进行身份验证。

高可用性

AWS站点到站点VPN允许您使用AWS Direct Connect创建故障转移和CloudHub解决方案。CloudHub使您的远程站点能够彼此通信,而不仅仅是与VPC通信。它运行在一个简单的轮辐模型上,您可以使用或不使用VPC。这种设计适合具有多个分支机构和现有internet连接的客户,这些客户希望为这些远程办公室之间的主连接或备份连接实现一个方便的、潜在的低成本轮辐模型。

配置和性能

AWS站点到站点VPN提供了可定制的隧道选项,包括隧道内部IP地址、预共享密钥和边界网关协议自主系统编号(BGP ASN),因此您可以设置多个安全VPN隧道,以增加应用程序的带宽或在停机时的弹性。此外,AWS过境网关上的AWS站点到站点VPN提供了等成本的多路径路由(ECMP),以帮助增加多路径上的流量带宽。

网络地址转换(NAT)遍历

AWS站点到站点VPN支持NAT遍历应用程序,这样您就可以在路由器背后的私有网络上使用私有IP地址,并且只有一个面向internet的公共IP地址。

监控

AWS站点到站点VPN可以向CloudWatch发送度量,从而为您提供更好的可见性和监视。CloudWatch还允许您发送自己的自定义指标,并以您选择的任何顺序和速度添加数据点。您可以将这些数据点的统计信息作为一组有序的时间序列数据检索。

 

AWS站点到站点VPN的限制

  1. 每个AWS帐户每个AWS区域最多可以有五(5)个客户网关
  2. 每个AWS帐户每个AWS区域最多可以有五(5)个虚拟网关
  3. 您可以有多达50(50)个站点到站点VPN连接每个AWS帐户每个AWS区域
  4. 每个虚拟网关最多可以有50个站点到站点的VPN连接。
  5. 您可以为每个虚拟网关提供多达100条路由。

*更多信息,请查看亚马逊VPC用户指南中的VPN限制。如果您需要超过这些限制,请创建一个支持案例。

AWS客户端VPN功能

AWS客户端VPN提供了一个完全托管的VPN解决方案,可以通过Internet连接和兼容openvpn的客户端从任何地方访问该解决方案。它是弹性的,并自动缩放,以满足您的需求。它使您的用户能够连接到AWS和on-premises网络。AWS客户机VPN与现有的AWS基础设施(包括Amazon VPC和AWS目录服务)无缝集成,因此无需更改网络拓扑。

AWS客户端VPN提供以下功能:

身份验证

AWS客户端VPN将使用Active Directory或证书进行身份验证。客户端VPN与AWS目录服务集成,AWS目录服务连接到现有的on-premises Active Directory,因此不需要将数据从现有Active Directory复制到云。使用客户端VPN的基于证书的身份验证与AWS证书管理器集成,可以轻松地提供、管理和部署证书。

授权

AWS客户机VPN提供基于网络的授权,因此您可以定义访问控制规则,根据Active Directory组限制对特定网络的访问。客户端VPN可以为使用安全组的客户端VPN用户提供对特定应用程序的细粒度访问。

安全连接

AWS客户端VPN使用安全的TLS VPN隧道协议对流量进行加密。一个VPN隧道在每个客户机VPN端点终止,并为用户提供对所有AWS和内部资源的访问。

连接管理

您可以使用Amazon CloudWatch日志从AWS客户机VPN连接日志监视、存储和访问日志文件。然后,您可以从CloudWatch日志中检索相关的日志数据。因此,您可以轻松地监视、进行取证分析并终止特定连接,从而控制谁可以访问您的网络。

与员工设备的兼容性

AWS客户端VPN旨在将设备连接到您的应用程序。它允许您从基于openvpn的客户机中进行选择,让员工可以选择使用他们选择的设备,包括Windows、Mac、iOS、Android和基于linux的设备。

 

原文:https://aws.amazon.com/cn/vpn/features/

本文:

讨论:请加入知识星球或者小红圈【首席架构师圈】

SEO Title
AWS VPN features

【网络协议】HTTP2和SPDY协议——使HTTP更快更安全

Chinese, Simplified

HTTP2和SPDY协议——使HTTP更快更安全

 

HTTP/2是HTTP/1的下一个版本,HTTP/1无法处理现在的web,因为现在的web资源更加密集,它无法有效地处理多个请求。HTTP/2有许多技术可以利用当前web体验的需求。

SPDY是HTTP/2协议的核心部分,许多HTTP/2协议技术都是SPDY的一部分。

SPDY(speed)是一种网络协议,它通过压缩报头、预测客户端请求(下面讨论的示例)和其他技术来操纵http协议,以加强web体验。

SPDY是由谷歌开发的。但是,由于支持使用SPDY技术的http/2,所以不赞成使用SPDY。谷歌说,在使用http/1之前,SPDY会提高你的网站速度,speed (SPDY)会将网站速度提高到55%。

SPDY支持所有主要的浏览器(firefox, chrome, opera, safari, ie)。

为什么速度快:

1。压缩。

快速压缩报头,它将跟踪这个特定会话中的报头是否已经发送,如果发送报头已经完成,那么在会话过期之前重新发送报头是没有用的。

2。预取:

如果客户机请求包含一些链接(css样式表)的html文件,那么在http/1协议中,客户机应该发送请求以获取这些链接(css样式表)。在这种情况下,快速服务器可以解析html、包含这些链接并发送,而无需等待客户端请求链接。

3.优先级:

HTTP/1处理有限的并行连接,如基于浏览器的6-8,如果连接更多,则我们必须等到以前的连接被解决,所以即使有重要的连接,我们也要等待。通过使用优先级流来快速解决问题,所以最紧急的请求将首先得到解决。

4 最重要的是多路复用:

如上所述,关于有限的并行连接,multiplexing可以解决这个问题,multiplexing基本上就是将多个信号组合成一个,所以快速浏览器将它的多个请求合并为一个请求并发送到服务器,然后服务器将请求(多路复用)划分为原始请求数并进行响应。

快速是快速的,因为额外的工作是由客户端和服务器完成上面的任务。

虽然http/2的核心速度很快,但http/2可以处理多主机多路复用,加密速度更快,压缩速度更快。

HTTP / Nginx 2:

Nginx从1.9.5版本开始支持http/2,所以如果您使用的是长期支持OS版本,比如Ubuntu 14.04,那么在安装Nginx之前,您应该向源列表中添加最新的Nginx deb repo。

如果您的nginx版本低于1.9.5,请遵循以下命令

wget - o - http://nginx.org/keys/nginx_sign. key | sudo ap -key add -

echo " deb http://nginx.org/packages/mainline/ubuntu/ trusty nginx " | sudo tee -a /etc/apt/sources.list

echo“deb-src http://nginx.org/packages/mainline/ubuntu/ trusty nginx”| sudo tee -a /etc/apt/sources.list。

sudo apt-get更新

sudo apt-get安装nginx

最后替换:

listen 443 ssl;

listen 443 ssl http2;

重新加载Nginx。

这是它. .你已经准备好出发了。

要检查http2是否打开,请访问:https://tools.keycdn.com/http2-test或checkout chrome嗅探扩展,显示站点的详细信息,无论是使用nginx、jquery、disqus等。如果启用了http2或spdy协议,它将显示spdy。

SEO Title
HTTP2 and SPDY protocols - making HTTP faster and safer

【网络技术】带宽与延迟:有什么区别?

Chinese, Simplified

在阅读或讨论internet服务时,“带宽”和“延迟”这两个术语始终是最重要的。但它们是什么意思?它们有何不同?它们会影响你的上网速度吗?

虽然这两个术语经常混淆,但它们不是一回事。带宽和延迟之间有一些微妙但重要的区别,知道哪一个是你的问题可能是让你的互联网连接发挥最大效用的关键。

带宽与延迟

什么是带宽?

带宽是在特定时间内从网络中的一个点传输到另一个点的数据量的度量。它通常用于测量您可以从internet上的服务器下载到设备上的数据量。

把你的连接带宽想象成一条高速公路,把你的数据想象成六辆车以同样的速度行驶。高带宽的高速公路将有六条车道,允许所有车辆在1秒内同时到达。一条低带宽的高速公路只有一条车道,允许所有车辆在6秒内到达。

由于网络拥塞、网络开销和其他外部因素,您的实际带宽通常会小于最大带宽。例如,您的internet连接可能支持1000 Mbps的宽带(高速公路),但您的internet计划可能会关闭一些车道,并将带宽限制为400 Mbps。再加上网络拥塞、本地布线问题等,您的最高带宽可能只有300 Mbps。

一句话:带宽越高越好。

什么是延迟?

延迟是指信号到达目的地和返回目的地所需的时间。

例如,延迟在在线游戏中扮演着重要角色。在低延迟的情况下,您的输入会像跳过障碍一样立即出现在屏幕上,因为在按下按钮、服务器确认您的操作和屏幕上呈现的返回确认之间的时间间隔很短。

对于高延迟,您将看到控制器输入和屏幕上产生的跳转之间的延迟,因为往返服务器需要更长的时间。这种延迟称为输入滞后。

延迟不仅仅是一个游戏问题。每次你向你的互联网连接发出请求(在谷歌上搜索、查看社交媒体等),它都会向服务器发送一个信号,让服务器检索信息,然后将其返回给你。由于这种情况通常发生得很快,所以延迟以毫秒为单位。

底线:延迟越低越好。

专业提示:

为了测试延迟,您的计算机可以向远程服务器发送少量数据以测量往返时间。例如,您可以使用Ping实用程序查看数据到达目的地和返回目的地所需的时间。游戏玩家使用它来确定哪台服务器的连接速度更快,或者找出他们在线游戏时动作迟缓的原因。此往返时间也称为“ping速率”

带宽和延迟对您的影响

游戏

大多数具有在线连接的游戏不需要非常快速的互联网连接,因此带宽对游戏体验的影响相当小(除非有很多人同时在同一连接上玩游戏)。

您需要播放的所有内容都已安装在您的计算机或控制台上。当您的游戏和服务器交换诸如控制器输入、世界状态、玩家坐标、玩家通信等信息时,互联网连接开始发挥作用。如果你在玩离线游戏或者没有多人游戏组件(如质量效应和辐射4),带宽甚至不是问题。

但是,正如我们前面提到的,延迟对于在线游戏的良好体验至关重要,特别是在快节奏的游戏中,如Fortnite和Overwatch。高延迟表现为延迟,可能导致输入和角色动作之间的显著延迟。换言之,你可能已经死了,而你仍然试图摆脱拍摄,但你不会知道它,直到你的连接赶上。

专业提示:缓慢的互联网是否让你成为团队中的薄弱环节?了解在线游戏需要多少速度。

流处理

由于流媒体涉及从服务器下载内容,带宽往往是视频和音频流媒体的主要因素。这是因为流媒体在您端几乎没有输入的情况下进行:您只需单击并等待。

低带宽通常有两种表现。当您的连接试图跟上内容的大小时,它将表现为痛苦的缓冲量。或者,它将显示为糟糕的视频质量,因为您的流媒体服务正试图弥补下载速度慢的问题。

专业提示:

缓冲是指流媒体下载停止时。开始播放流时,视频或音频将被下载并临时存储在播放设备上。一旦视频或音频启动,服务将继续在后台下载其余部分。如果下载因任何原因停止,视频或音频会暂停,屏幕上会显示“缓冲”消息。当有足够的视频或音频文件继续播放时,该消息消失。

视频聊天

视频聊天,如FaceTime或Skype,会受到低带宽和高延迟的负面影响。低带宽会影响你的聊天质量,使事情很难被看到。延迟将导致同步问题和冻结。

浏览

即使是最基本的,每天的网络浏览也不会受到不良互联网连接的影响。低带宽将导致页面缓慢加载并分段加载(就像以前的拨号时代一样)。

由于延迟很高,页面的加载速度可能会非常快,但在开始时会有令人抓狂的延迟,看起来什么都没有发生。

提高连接速度的技巧

如果你的互联网连接让你情绪低落,你可以做一些事情。

确保您的路由器设置是可靠的

登录调制解调器和路由器,确保您的设置没有造成瓶颈。大多数路由器和无线网关都有一个设置页面,您可以在其中更改密码、调整路由器使用的频道等。

通常,登录信息直接打印在设备底部的标签上。查看我们的《提高Wi-Fi速度指南》,了解更多有关操作的详细信息。

升级你的路由器

是的,我们明白了:这些东西是永恒的。但是,如果您仍然使用2008年的旧型号,很有可能您的无线连接无法发挥其真正的潜力。虽然新的路由器不能增加你计划的带宽,但它可以提高你的无线速度。

升级您的internet软件包

如果您已经升级了设备并调整了设置,但仍然没有达到您想要的速度,下一步就是升级到更快的internet软件包。不知道你需要多少速度?我们有一个方便的速度推荐工具来帮助实现这一点。

查找新的提供商

如果其他一切都失败了,你不能从你目前的供应商那里得到一笔好交易,那么也许是时候换一个新的供应商了。互联网服务领域的竞争非常激烈,大多数地方都至少有两个很好的提供商选择。

如果您不确定从哪里开始,我们将提供最快互联网提供商的综述。通过在下面的工具中输入邮政编码,您还可以查看所有可用选项。

结论是:带宽和延迟都至关重要

带宽和延迟对于良好的在线体验都是至关重要的,但两者之间的区别可能有点令人困惑。但是有了你新发现的知识,你可以利用你所知道的快速获得更好的互联网体验。

如果你想更多地了解互联网速度是如何工作的,请查看我们全面的互联网速度指南。

关于带宽与延迟的常见问题解答

延迟和ping速率之间有什么区别?

延迟和ping速率之间没有区别。两者都指在线执行操作和看到结果之间的延迟。

什么类型的internet连接具有最低的延迟?

一般来说,有线和光纤互联网的延迟最低,而卫星互联网的延迟最高。除此之外,路由器及其位置等其他因素也会影响使用Wi-Fi时的延迟水平。

什么是好的延迟?

对于一般的浏览和流媒体,任何低于100毫秒的都可以。对于激烈的游戏,你会希望拍摄的最大50毫秒,但30毫秒以下将是理想的。

如何检查我的网速?

检查网速最简单、最快捷的方法是使用在线速度测试。这将告诉您当前的连接速度。你可以将其与你的计划宣传的内容进行比较,以帮助解决任何问题。

 

原文:https://www.highspeedinternet.com/resources/bandwidth-vs-latency-what-i…

本文:http://jiagoushi.pro/node/1520

讨论:请加入知识星球【超级工程师】或者微信【ceo_engr】或者QQ【449846958】

SEO Title
Bandwidth vs. Latency: What is the Difference?

【网络架构】OpenStack 脊页网络(Spine and Leaf Networking) 介绍

Chinese, Simplified

本指南提供了有关如何为Red Hat OpenStack平台环境构建脊椎叶网络拓扑的信息。这包括完整的端到端场景和示例文件,以帮助在您自己的环境中复制更广泛的网络拓扑。

1.1  棘叶(Spine and Leaf) 网络

Red Hat OpenStack平台的可组合网络架构允许您调整网络以适应流行的路由脊椎叶数据中心拓扑结构。在路由spine leaf的实际应用中,leaf通常表示为数据中心机架中的可组合计算或存储角色,如图1.1“路由spine leaf示例”所示。Leaf 0机架有一个云下节点控制器和计算节点。将可组合网络呈现给已分配给可组合角色的节点。在这个图表中:

  • 将Storage Leaf网络提供给Ceph存储和计算节点。
  • Network Leaf代表您可能要组成的任何网络的示例。

图1.1 路由脊椎叶示例

OpenStack Spine Leaf 466050 0218 routed

1.2 网络拓扑

路由的spine leaf裸机环境具有一个或多个支持第3层的交换机,这些交换机在单独的第2层广播域中的独立vlan之间路由通信。

本设计的目的是根据功能对流量进行隔离。例如,如果控制器节点在内部API网络上承载API,那么当计算节点访问API时,它应该使用自己版本的内部API网络。要使此路由工作,您需要强制内部API网络的流量使用所需接口的路由。这可以使用supernet路由进行配置。

例如,如果使用172.18.0.0/24作为控制器节点的内部API网络,则可以使用172.18.1.0/24作为第二个内部API网络,使用172.18.2.0/24作为第三个内部API网络,依此类推。因此,您可以有一个指向更大的172.18.0.0/16 supernet的路由,该supernet为每个第2层域中的每个角色使用本地内部API网络上的网关IP。

此方案使用以下网络:

表1.1 Leaf 0网络

Network Roles attached Interface Bridge Subnet

Provisioning / Control Plane

All

nic1

br-ctlplane (undercloud)

192.168.10.0/24

Storage

Controller

nic2

 

172.16.0.0/24

Storage Mgmt

Controller

nic3

 

172.17.0.0/24

Internal API

Controller

nic4

 

172.18.0.0/24

Tenant

Controller

nic5

 

172.19.0.0/24

External

Controller

nic6

br-ex

10.1.1.0/24

Table 1.2. Leaf 1 Networks

Network Roles attached Interface Bridge Subnet

Provisioning / Control Plane

All

nic1

br-ctlplane (undercloud)

192.168.11.0/24

Storage1

Compute1, Ceph1

nic2

 

172.16.1.0/24

Storage Mgmt1

Ceph1

nic3

 

172.17.1.0/24

Internal API1

Compute1

nic4

 

172.18.1.0/24

Tenant1

Compute1

nic5

 

172.19.1.0/24

Table 1.3. Leaf 2 Networks

Network Roles attached Interface Bridge Subnet

Provisioning / Control Plane

All

nic1

br-ctlplane (undercloud)

192.168.12.0/24

Storage2

Compute2, Ceph2

nic2

 

172.16.2.0/24

Storage Mgmt2

Ceph2

nic3

 

172.17.2.0/24

Internal API2

Compute2

nic4

 

172.18.2.0/24

Tenant2

Compute2

nic5

 

172.19.2.0/24

Table 1.4. Supernet Routes

Network Subnet

Storage

172.16.0.0/16

Storage Mgmt

172.17.0.0/16

Internal API

172.18.0.0/16

Tenant

172.19.0.0/16

OpenStack Spine Leaf 466050 0218 API network

1.3 脊叶要求

要在具有第3层路由体系结构的网络上部署过云,必须满足以下要求:

第三层路由

网络基础设施必须配置路由以启用不同第2层网段之间的通信。这可以静态或动态配置。

DHCP中继

非云下本地的每个第2层段必须提供dhcp中继。必须将DHCP请求转发到连接undercloud的设置网段上的undercloud。

注意

undercloud使用两个DHCP服务器。一个用于裸机节点自省,另一个用于部署过云节点。配置DHCP中继时,请确保读取DHCP中继配置以了解要求。

1.4 棘叶限制

  • 某些角色(如控制器角色)使用虚拟IP地址和群集。此功能背后的机制需要这些节点之间的第2层网络连接。这些节点都放在同一个叶中。
  • 类似的限制适用于Networker节点。网络服务使用虚拟路由器冗余协议(VRRP)在网络中实现高可用的默认路径。由于VRRP使用虚拟路由器IP地址,因此必须将主节点和备份节点连接到同一L2网段。
  • 在使用带有VLAN分段的租户或提供程序网络时,必须在所有Networker和计算节点之间共享特定的VLAN。

注意

可以使用多组Networker节点配置网络服务。每组网络共享路由,VRRP将在每组Networker节点中提供高可用的默认路径。在这种配置中,共享网络的所有Networker节点必须位于同一L2网段上。

 

原文:https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13/html-single/spine_leaf_networking/index#alternative-provisioning-network-methods

本文:http://jiagoushi.pro/openstack-spine-leaf-networking-introduction

讨论:请加入知识星球【首席架构师圈】或者加小号【intelligenttimes】

 

SEO Title
Openstack SPINE LEAF NETWORKING Introduction

【网络架构】Openstack SPINE LEAF NETWORKING 备用供应网络方法

Chinese, Simplified

本节包含有关其他方法的信息,这些方法用于配置配置配置网络,以适应带有可组合网络的路由spine leaf。

3.1 VLAN配置网络

在本例中,控制器通过供应网络部署新的超云节点,并在第3层拓扑中使用VLAN隧道(参见图3.1,“VLAN供应网络拓扑”)。这允许控制器的DHCP服务器向任何叶发送DHCPOFFER广播。为了建立这个隧道,在机架顶部(ToR)叶交换机之间中继VLAN。在这个图中,StorageLeaf网络呈现给Ceph存储和计算节点;NetworkLeaf表示您可能要组成的任何网络的示例。

图3.1 VLAN配置网络拓扑

OpenStack Spine Leaf 466050 0218 VLAN

3.2 VXLAN供应网络

在本例中,控制器通过供应网络部署新的过云节点,并使用VXLAN隧道跨越第3层拓扑(参见图3.2,“VXLAN供应网络拓扑”)。这允许控制器的DHCP服务器向任何叶发送DHCPOFFER广播。要建立此通道,请在机架顶部(ToR)叶型交换机上配置VXLAN端点。

图3.2。VXLAN配置网络拓扑

OpenStack Spine Leaf 466050 0218 VXLAN

原文:https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13/html-single/spine_leaf_networking/index#alternative-provisioning-network-methods

本文:

讨论:请加入知识星球【首席架构师圈】或者微信小号【intelligenttimes】

 

SEO Title
Openstack Alternative provisioning network methods

【网络架构】nginxinc / kubernetes-ingress和kubernetes / ingress-nginx入口控制器之间的差异

Chinese, Simplified

有两个基于NGINX的Ingress控制器实现:你可以在这个repo中找到的那个(nginxinc / kubernetes-ingress)和一个来自kubernetes / ingress-nginx repo的实现。在本文档中,我们将解释这些实现之间的主要区别。此信息可帮助您根据需求选择适当的实现,或从一个实现转移到另一个实现。

我用的是哪一个?


如果您不确定正在使用哪个实现,请检查正在运行的Ingress控制器的容器映像。对于nginxinc / kubernetes-ingress Ingress控制器,其Docker镜像在DockerHub上发布,可作为nginx / nginx-ingress使用。

关键差异


下表总结了nginxinc / kubernetes-ingress和kubernetes / ingress-nginx Ingress控制器之间的主要区别。请注意,该表有两列用于nginxinc / kubernetes-ingress Ingress控制器,因为它可以与NGINX和NGINX Plus一起使用。有关使用NGINX Plus的nginxinc / kubernetes-ingress的更多信息,请阅读此处

Aspect or Feature kubernetes/ingress-nginx nginxinc/kubernetes-ingress with NGINX nginxinc/kubernetes-ingress with NGINX Plus
Fundamental      
Authors Kubernetes community NGINX Inc and community NGINX Inc and community
NGINX version Custom NGINX build that includes several third-party modules NGINX official mainline build NGINX Plus
Commercial support N/A N/A Included
Load balancing configuration via the Ingress resource      
Merging Ingress rules with the same host Supported Supported via Mergeable Ingresses Supported via Mergeable Ingresses
HTTP load balancing extensions - Annotations See the supported annotations See the supported annotations See the supported annotations
HTTP load balancing extensions -- ConfigMap See the supported ConfigMap keys See the supported ConfigMap keys See the supported ConfigMap keys
TCP/UDP Supported via a ConfigMap Supported via a ConfigMap with native NGINX configuration Supported via a ConfigMap with native NGINX configuration
Websocket Supported Supported via an annotation Supported via an annotation
TCP SSL Passthrough Supported via a ConfigMap Not supported Not supported
JWT validation Not supported Not supported Supported
Session persistence Supported via a third-party module Not supported Supported
Canary testing (by header, cookie, weight) Supported via annotations Supported via custom resources Supported via custom resources
Configuration templates *1 See the template See the templates See the templates
Load balancing configuration via Custom Resources      
HTTP load balancing Not supported See VirtualServer and VirtualServerRouteresources. See VirtualServer and VirtualServerRouteresources.
Deployment      
Command-line arguments *2 See the arguments See the arguments See the arguments
TLS certificate and key for the default server Required as a command-line argument/ auto-generated Required as a command-line argument Required as a command-line argument
Helm chart Supported Supported Supported
Operational      
Reporting the IP address(es) of the Ingress controller into Ingress resources Supported Supported Supported
Extended Status Supported via a third-party module Not supported Supported
Prometheus Integration Supported Supported Supported
Dynamic reconfiguration of endpoints (no configuration reloading) Supported with a third-party Lua module Not supported Supported

 

笔记:

* 1  -  Ingress控制器用于生成NGINX配置的配置模板是不同的。 因此,对于相同的Ingress资源,生成的NGINX配置文件与一个Ingress控制器不同,这反过来意味着在某些情况下NGINX的行为也可能不同。

* 2  - 由于命令行参数不同,因此无法使用相同的部署清单来部署Ingress控制器。

如何交换入口控制器


如果您决定交换Ingress控制器实现,请准备好处理上一节中提到的差异。 至少,您需要开始使用其他部署清单。

原文:https://github.com/nginxinc/kubernetes-ingress/blob/master/docs/nginx-ingress-controllers.md

本文:http://pub.intelligentx.net/differences-between-nginxinckubernetes-ingress-and-kubernetesingress-nginx-ingress-controllers

讨论:请加入知识星球或者小红圈【首席架构师圈】

SEO Title
Differences Between nginxinc/kubernetes-ingress and kubernetes/ingress-nginx Ingress Controllers

【网络架构】了解活动目录及其体系结构

Chinese, Simplified

使用Active Directory管理生态系统

在任何商业组织中,都有一个复杂的、不断发展的用户、计算机、文件服务器、打印机、应用程序等生态系统。这些系统和资源可能分布在多个物理网络、站点或多个国家。即使是一个小组织也可能希望为其外部伙伴提供对其系统的访问。管理所有这些可能会很快成为一个行政头痛。

Microsoft(R)活动目录(AD)是一套工具,可帮助系统管理员管理这些复杂的网络生态系统。其基本目的是集中系统管理,帮助用户快速找到和使用组织内的资源。

活动目录产品组合

简单地说,AD常常被比作计算机系统的一种公司电话簿形式:提供一个集中的目录,存储有关网络资源的信息,以便用户能够查找并以正确的权限安全地访问这些资源。因此,例如,用户可以很容易地找到他们最近的打印机并获得使用它的权限。

事实上,这只是一个方面,而AD是一个技术组合,提供以下广泛的认证、标识和安全设施:

  • 系统目录-活动目录®域服务(AD DS)
  • 管理用户访问和使用内容的权限–活动目录®权限管理服务(AD RMS)
  • 跨组织和跨组织之间的用户身份联合–活动目录®联合服务(AD FS)
  • 处理数字证书–活动目录®证书服务(AD CS)

AD提供了一种集中处理所有这些问题的方法。它使系统和资源管理更加高效和安全,提高用户生产力,保护知识产权,并有助于解决公司政策和法规遵从性问题。

应用程序集成

许多关键的企业应用程序使用AD服务与更广泛的网络生态系统集成,并改进它们为用户提供的支持。主要示例包括Microsoft自己的企业产品,如Exchange、Office和SQL Server,以及第三方产品,如Adobe®Acrobat。

活动目录的体系结构

广告分为两层:物理层和逻辑层。物理层描述并控制AD在Windows®操作系统体系结构中的工作方式(例如,它可以访问哪些低级操作系统服务和组件)。逻辑层更加概念化,允许描述组织及其运作方式。

活动目录物理层

在物理上,AD是一个网络操作系统,建立在Windows Server®的各种迭代之上。它是安全子系统的一部分,使用了一些关键组件,如Kerberos身份验证和NET LOGON。AD使用轻量级目录访问协议(LDAP)作为其主要协议,LDAP是一种行业标准。

物理层还描述了目录信息如何存储在硬盘上,关键目录信息(如核心AD Ntds.dit文件)存储在提供服务的物理服务器上的数据库文件中。

Active Directory®还利用了域名系统(DNS),即互联网上使用的基于标准的命名和定位系统。这意味着AD需要访问DNS服务器,尽管几乎所有的组织都已经在运行一个用于Internet地址解析的服务器。Microsoft®提供了一个DNS服务器,可以在安装AD时进行配置,但也可以使用其他现有解决方案(例如Berkeley Internet Name Domain(BIND))。

活动目录逻辑层

逻辑层确定存储在这些物理组件中的数据的概念结构以及如何访问这些数据。在设计这个层时,目的是描述一个组织及其员工是如何组织和工作的,而不是担心诸如站点之间的网络连接等物理细节。

本质上,被管理的所有内容(用户、打印机、服务器等)都被认为是AD存储中的一个对象,并且具有相关的属性(遵循基本的LDAP协议模型)。因此,例如,用户对象将具有诸如名字和中间名之类的属性。逻辑层的能力来自于将对象组织到层次结构和组中,以及分配类或类型的能力。

因此,例如,AD可以设置组策略、规则和权限,这些策略、规则和权限适用于整个生态系统中的所有用户和计算机,或应用于较小的用户子组。使用组策略,管理员可以控制网络环境的许多方面,例如用户在系统上的行为(例如定义桌面配置,例如节能)、控制谁有权访问哪些资源(例如共享文件夹)和自动化关键任务(例如更新应用程序)。

逻辑层可能会与许多构建块(域、组、目录树和林、命名模式和组织单元)一起变得相当复杂。这些逻辑结构可以按层次结构进行组织,因此,例如,林就是树的集合。对象之间的安全安排和信任在这些不同类型的构建块中有所不同。

设计和规划逻辑层是一项复杂的任务,但如果做得正确,它可以让AD支持组织更有效地运作,并有助于行政管理和安全。

总之,AD是一套工具,有助于对用户和网络资源进AD行有效的管理和管理,支持一些关键业务流程,如数字权限管理。在许多组织中,它已经成为一项关键任务服务,因此需要认真考虑灾难恢复和威胁保护。

原文:https://activereach.net/support/knowledge-base/connectivity-networking/understanding-active-directory-its-architecture/

本文:http://jiagoushi.pro/node/939

讨论:请加入知识星球【首席架构师圈】或者微信圈子【首席架构师圈】

SEO Title
Understanding Active Directory® & its architecture

【网络架构】什么是应用交付控制器(ADC)?

Chinese, Simplified

应用交付网络


应用程序交付网络是创建技术框架的实践,这些技术协同工作以为网络应用程序提供适当级别的可用性,安全性,可见性和加速。这些应用程序交付网络技术具有自己的专有CPU,通常驻留在网络端点。它们通过各种优化技术增强了跨Internet的应用程序交付。

什么是应用交付控制器?


顾名思义,应用交付控制器(ADC)提供应用服务并控制客户端和应用服务器之间的通信。在此上下文中,术语控制器是管理(或控制)计算系统(例如客户端设备和应用程序服务)之间的数据流,优化应用程序性能,可用性和安全性的功能。

ADC充当反向代理


客户端请求与ADC交互,ADC充当反向代理,代表客户端与应用程序服务器交互。由于ADC位于数据路径中,因此可以在流中执行应用程序加速,监视,管理和安全服务。

下图显示了一种常见配置,ADC位于DMZ网络子网中,检查并保护驻留在Internet上的客户端的网络访问。

 

Application Delivery Controller服务


服务器负载平衡(SLB)


服务器负载均衡器是许多企业和云基础架构的标准组成部分。 SLB系统提供应用程序:

  • 可用性
  • 可扩展性
  • 性能

健康监测


由于ADC位于客户端和应用程序之间的数据路径中,因此可以看到应用程序行为和性能。 ADC系统可以监控,分析和记录进入应用程序的客户端请求以及应用程序响应。通常只有在收到性能问题后,才能通过最终用户轻松获得此可见性。 ADC系统可以监控和分析应用程序或服务器不良行为。

应用程序加速


应用程序加速使用多种技术来提高网络连接的应用程序性能和响应时间。这些技术包括数据压缩,高速缓存,连接多路复用和流量整形

加速技术包括网络优化。网络优化克服了WAN延迟,数据包丢失和带宽拥塞等网络问题。网络优化还解决了对应用程序性能产生负面影响的挑战,例如“聊天”协议,例如: HTTP和CIFS / SMB,以及TCP / IP堆栈实现中的低效率。

SSL卸载


ADC通常具有SSL卸载功能,可将终止SSL会话的负载从应用服务器移至ADC。 ADC从应用程序服务器中移除负载,应用程序服务器通常在软件中执行SSL操作,并在驻留在ADC平台中的SSL硬件平台中执行此操作。

DDoS保护


DDoS攻击频率逐年增加三到四倍。这些攻击会对企业造成严重破坏,通常会花费数百万美元。

ADC平台通常提供DDoS预防和缓解系统,可以阻止网络边缘的攻击,防止这些攻击到达应用服务器。当ADC启用SSL卸载时,可以在ADC上安全地检测和阻止使用SSL隧道流量的DDoS攻击,而不会暴露应用程序和服务器。

DNS应用程序防火墙


已部署ADC以保护,负载平衡并确保Internet和DNS服务提供商对关键DNS基础架构的可用性。

保护和优化DNS基础架构的挑战

  • 攻击DNS基础结构的恶意和无效流量
  • DNS基础设施上的分布式DDoS攻击
  • 增加DNS基础架构压力(增长和浏览器)

减少受保护服务器的负载(最高70%)

  • 仅允许合法的DNS协议流量,可以拒绝非DNS流量
  • 通过高性能浪涌保护可预测负载
  • 增加受保护的DNS服务器容量,同时释放资源以解决增加的负载

提高后端服务器的安全性

  • 可选的隔离(重定向)恶意或无效流量以供检查
  • 无论DDoS攻击如何,都可以保证正常运行时间(基于硬件的SYN Flood保护,每秒高达5000万)

Web应用防火墙


一些ADC产品内置在Web应用程序防火墙(WAF)中。 WAF用于防范Web攻击并保护应用程序免受安全漏洞的影响。这些安全威胁包括跨站点脚本(XSS),SQL注入,cookie中毒,数据形式溢出以及各种格式错误的HTTP数据包。一些供应商在此许可证中包含此功能。

中心认证


应用程序交付控制器可以充当中央身份验证点。客户端可以将其身份验证会话发送给ADC,然后ADC负责验证身份验证和授权。 ADC系统可以与各种AAM系统连接。提供中央身份验证服务可以从此处理负载中卸载应用程序服务器,并降低应用程序环境的复杂性。

多租户支持


SDN和多租户网络很复杂,需要网络系统了解这些新协议和技术。覆盖SDN协议(如VxLAN和NVGRE)封装了IP数据流。网络设备(如ADC系统)通常需要在这些封装的网络流中查看,以正确控制和控制流量。

相关条款

 

  • 硬件负载均衡器
  • 网络负载均衡器

 

原文:https://www.a10networks.com/blog/application-delivery-controller/

本文:

讨论:请加入知识星球或者小红圈【首席架构师圈】

SEO Title
What is an Application Delivery Controller (ADC)?

【网络架构】介绍NGINX单位

Chinese, Simplified

此博客文章是来自nginx.conf 2017的NGINX团队成员的六个主题演讲之一。这些博客文章共同介绍了NGINX应用程序平台,新产品以及产品和战略更新。

博客文章是:

Nick Shadrin:现代应用已发生变化。 他们从非常小的网站,从设计为一件事的简单应用程序,到非常大而复杂的网络属性,发展壮大。 今天,它们由多个部分组成:您创建小型服务,然后将它们连接在一起。 随着基础架构的新变化,您还可以轻松地上下扩展。 您可以创建新容器 - 云中的新计算机 - 以及与应用程序的连接。 应用程序部件之间的连接非常重要。

作者:Matt Britt [CC BY 2.5]来自Wikimedia Commons


使用NGINX,您已经知道如何连接到您的应用程序。 您知道应用程序的工作原理以及与其连接的工作方式。 但是通过Unit项目,我们进一步深入到应用程序代码。 它为您提供了运行应用程序和运行应用程序代码的平台。

我们研究了现有的解决方案,发现它们缺乏一些基础技术。 其中许多都很大,很慢,并且不适合云原生应用程序。

NGINX Unit从头开始构建。 它是由核心工程团队使用NGINX工程的核心原则构建的。 Unit是NGINX应用平台的重要组成部分。 对于单片应用程序和微服务应用程序,它的工作方式相同。 它为您提供了从旧式应用程序迁移和分离服务的方法。 它为您提供了一种统一的方式,不仅可以连接到您当前正在构建的应用程序,还可以连接到明天将要构建的应用程序。

我们来谈谈NGINX Unit为您提供的功能。

首先,它是一个专为云原生应用程序设计的全动态应用程序服务器。

“动态”是什么意思?使用NGINX,您熟悉众所周知的重载命令。你可能已经经常重装了。

当重新加载完成后,你就不会失去联系。你很好 - 应用程序正在运行。您可以通过重新加载整个服务器继续进行更改。但是,重新加载有时会对服务器资源造成负担,而且我们的许多大用户和客户都无法像他们希望的那样频繁地重新加载。

使用Unit,系统不会重新加载进程,它只会更改其内存的一部分以及特定更改所需的进程部分。它给你的是能够随时随地进行更改。

接下来是它是如何配置的。它是通过一个简单的API配置的。

今天,每个人都喜欢进行API调用以配置服务器。每个管理系统都了解这一点,我们构建了一个非常易于理解的API,它基于行业标准的JSON。

非常重要的是这个API可以远程使用。当您无法以远程方式配置服务器时,您在做什么?您正在构建一个小代理 - 一种各种类型的代理 - 以执行这些配置步骤。

使用Unit,您可以将API公开给您的专用网络和远程代理,以便以非常简单,本机和远程方式进行配置。

接下来,Unit是多语言。

它了解多种语言。我们支持PHP,Python和Go,其他语言即将推出。这给你的是能够在同一台服务器上同时运行用这些语言编写的任何代码。但更有趣的是,您可以在同一台服务器上运行同一语言的多个版本。

您是否曾将旧的PHP应用程序从PHP 5迁移到PHP 7?现在,它就像一个API调用一样简单。您是否曾尝试在Python 2.7和Python 3.3中运行相同的应用程序?我看到有些人在观众中大笑。是的,有时甚至不起作用。现在,我们为您提供了相同的平台,可以使用该应用程序理解的语言和语言版本来运行应用程序。有趣的是,这是如何实现的。

我会请NGINX的原作者Igor Sysoev到舞台上讨论NGINX Unit的架构。 Igor具有惊人的品质:Igor以一种基本的方式构建应用程序。他在更深层次上看待问题。当他在研究如何构建应用程序时,他没有任何先入为主或妥协。

伊戈尔,请上台。我们来谈谈NGINX Unit的架构。

Igor Sysoev:早上好。我的名字是Igor Sysoev。我是NGINX的原作者,NGINX公司的联合创始人,以及我们新项目Unit的架构师。

这是Unit的架构方案:所有部件都是一个系统中的独立过程。 出于安全原因,这些过程是隔离的; 只有主进程以root身份运行。 其他进程可以作为非特权用户运行。

这个架构非常复杂,所以我将详细介绍最重要的部分。

Unit的关键特性是动态配置。 性能与现有应用程序服务器相当。

“动态配置”是什么意思? 这意味着根本没有实际的配置文件。 您使用UNIX域套接字或TCP套接字上的RESTful JSON API与Controller进程进行交互。 您可以一次上传整个配置,也可以只上传一部分。

您可以更改或删除配置的任何部分,Unit不会重新加载整个配置 - 只重新加载相关部分。 这意味着您可以根据需要随时更改配置。 当Controller进程接受更改配置的请求时,它将更新[full stored]配置并将相应的部分发送到路由器和主进程。

 

路由器进程有几个与客户端交互的工作线程。它们接受客户端的请求,将请求传递给应用程序进程,从应用程序获取响应,并将响应发送回客户端。每个工作线程都会轮询epoll或kqueue,并且可以异步处理数千个同时连接。

当Controller向路由器发送新配置时,路由器的工作线程开始使用新配置处理新的传入连接,而现有(旧)连接继续由工作线程根据先前的配置进行处理。

因此路由器工作线程可以与几代配置同时工作而无需重新加载。

当路由器收到尚未启动的应用程序的请求时,它会要求主进程启动该应用程序。目前,应用程序进程仅在需要时启动。稍后,我们将添加prefork功能。

因此,主进程分叉新进程,在新进程中动态加载所需的应用程序模块,设置适当的凭据,然后在新进程中运行应用程序代码。

模块系统允许您在一台服务器中运行不同类型的应用程序,甚至在一台服务器中运行不同版本的PHP或Python。

Go应用程序是不同的动物。典型的Go应用程序自己侦听HTTP端口。您必须在应用程序中构建所有内容,包括所有网络和管理功能。使用Unit,您可以在没有此附加代码的情况下控制应用程序。

对于PHP或Python应用程序,您根本不需要更改代码[使用Unit运行它]。对于Go应用程序,您进行了一些微小的更改:您必须为Unit导入Go包,在Go应用程序的源代码中仅更改两行(调用Unit包而不是标准HTTP包),并构建Go应用程序包。

当主进程需要运行Go应用程序时,它会分叉一个新进程并在新进程中执行静态构建的Go应用程序。

Unit包与标准Go HTTP包兼容,因此您的应用程序仍可作为独立的HTTP服务器运行,或作为Unit服务器的一部分运行。当它独立运行时,它会侦听HTTP端口并像往常一样处理HTTP请求。

当Go运行Go应用程序时,它不会侦听HTTP端口。相反,它与Unit路由器进程通信,该进程处理所有HTTP请求并在内部与Go应用程序通信。

路由器和应用程序进程通过Unix套接字对和几个共享内存段进行通信。 套接字对和共享内存段对于每个应用程序进程都是私有的,因此如果应用程序进程异常退出,路由器进程将正常处理此故障,并且不会影响其他进程和连接。

当Go应用程序由Unit运行时,它将与路由器进程通信。 路由器进程将处理所有HTTP请求,并在内部与应用程序的线程套接字对和共享段内存进行通信。

现在,Nick Shadrin将告诉您有关Unit API配置和未来路线图的更多信息。

尼克沙德林:谢谢,伊戈尔。

我是否告诉您使用NGINX Unit API很容易? 嗯,是的,确实如此。

在这里,您可以看到Unit API的一个简单示例。我想谈谈它是如何配置的,以及如何使用此API对环境进行更改。

您可以定义的第一个对象是[在配置的应用程序部分中]的应用程序对象。您可以为其提供一个友好,用户友好的名称,并将应用程序的类型定义为语言和语言版本。然后,您可以根据应用程序类型为应用程序定义其他参数。 PHP应用程序有一些特定的参数。 Go应用程序将具有一些其他参数。

您还可以使用UNIX系统中组名称的不同用户名定义应用程序,以便在您的环境中出于安全原因将它们分开。

除了定义应用程序之外,您还将定义侦听器,侦听器将是应用程序的IP地址和/或端口。

然后指定特定侦听器如何绑定到您定义的应用程序。您可以创建许多侦听器和许多应用程序,并以您喜欢的方式将它们绑定在一起。

现在,你如何做出改变?第一种也是最简单的方法是重新加载服务器。你可能不想这样做。您可以将整个JSON有效负载作为PUT请求发送到NGINX Unit控件套接字,或者您可以逐个进行更改,通过自己的URL分别访问每个对象和每个字符串。我们为您提供灵活的变更方式。

这就是你现在拥有的。我们来谈谈这个项目的计划。

昨天,我们在开源中发布了NGINX Unit。它可以在公共测试版中使用。我们鼓励每个人尝试并使用它。

我们现在的首要任务是为您提供稳定版本和稳定代码的记录,我们希望您对NGINX装置的信心与NGINX一样。

我们将向Unit添加一长串新语言,但我们将要开发的第一批语言是Java和Node.js.一旦我们从社区获得更多语言和更多不同语言的贡献,您将看到扩展NGINX单元以支持您喜欢的应用程序语言非常容易。

接下来,我们将围绕HTTP / 2和更多HTTP功能添加功能。对于服务网格和服务到服务通信,我们将直接向NGINX单元添加代理和网络功能。

昨天,我们将代码上传到GitHub并公开发布给所有人。我们已经在社交媒体上看到了数百条评论。我们是这个项目的黑客新闻的头条新闻。

我们有数百颗星。我们已经在GitHub仓库中创建了拉取请求和问题。社区的反应非常热烈,自项目发布以来只有24小时。

我们鼓励您前往GitHub开始浏览代码,阅读并为其做出贡献。 我们将与您一起制作此软件,NGINX Unit核心工程团队将与您一起处理拉取请求和GitHub问题。

现在,让我们看看我们准备了哪些其他资源,以便您可以开始使用NGINX Unit。

我们在unit.nginx.org上传了文档,代码也可以在我们的标准Mercurial存储库和GitHub存储库中找到。您可以使用众所周知的处理NGINX项目的过程或使用GitHub过程来为代码做出贡献。

今天,在休息之后,我们将在这个会议室的NGINX部门进行深度探讨。在深度潜水课程中,我们不会有任何幻灯片。当我们处理项目的现场演示时,我们发现为了向您展示所有功能以及如何使用它,演示实际上将采用整个会话。

准备好看到很多命令行输出和许多在同一服务器上运行多个PHP,Python和Go应用程序的新方法。如果您想在邮件列表中与我们合作,请发送电子邮件至unit@nginx.org。它已经可用,您可以通过网络订阅,也可以发送电子邮件至unit-subscribe@nginx.org

对于我们的NGINX Plus商业用户来说更令人惊奇的是,他们已经在NGINX的NGINX技术表上拥有了这个惊人的通信渠道。如果您对NGINX Unit有疑问,可以使用您已知的相同支持渠道询问他们。

这就是我今天对你有关NGINX Unit的看法。让我们一起构建软件,让我们看看它是如何工作的,让我们看看如何使用Unit运行新的应用程序。谢谢。

 

原文:https://www.nginx.com/blog/introducing-nginx-unit/

本文:http://pub.intelligentx.net/introducing-nginx-unit

讨论:请加入知识星球或者小红圈【首席架构师圈】

SEO Title
Introducing NGINX Unit

【网络架构】维基百科:应用交付控制器

Chinese, Simplified

应用程序交付控制器(ADC)是数据中心中的计算机网络设备,通常是应用程序交付网络(ADN)的一部分,它帮助执行常见任务,例如由Web加速器完成的任务,以从Web服务器本身移除负载。 许多还提供负载平衡。 ADC通常放置在外部防火墙或路由器与Web场之间的DMZ中。

特征

一个常见的误解是ADC是一种先进的负载均衡器。 这不是一个充分的描述。 ADC是一种网络设备,可帮助站点引导用户流量,以消除两台或多台服务器的多余负载。 实际上,ADC包括许多OSI第3-7层服务,包括负载平衡。 大多数ADC中常见的其他功能包括SSL卸载,Web应用程序防火墙,NAT64,DNS64和代理/反向代理等。 它们倾向于提供更高级的功能,例如内容重定向以及服务器运行状况监视。

ADC供应商

有许多类型的ADC供应商。 纯软件ADC供应商包括Avi Networks,KEMP Technologies,Buoyant,NGINX,Snapt Inc,LiteSpeed Technologies和Pulse Secure。 传统的ADC供应商包括A10 Networks,F5 Networks和Citrix Systems。 随着市场的发展,将会有越来越多的供应商提供云集成和以软件为中心而非基于硬件。

历史

第一代ADC从2004年左右开始,提供简单的应用加速和负载平衡。 2006年,ADC开始应用高级应用服务,如压缩,缓存,连接多路复用,流量整形,应用层安全,SSL卸载和内容交换,以及服务器负载均衡等服务,优化和优化的集成服务框,架安全的业务关键应用程序流

 

市场

到2007年,许多公司都提供了应用程序加速产品,例如F5 Networks,Juniper Networks,Microsoft,KEMP Technologies,AVANU WebMux,Snapt Inc和aiScaler。[2]思科系统公司提供应用交付控制器,直到2012年离开市场。像F5 Networks,Radware和Citrix这样的市场领导者在过去几年中一直在从思科获得市场份额。[3]

ADC市场细分为两大领域:1)通用网络优化和2)应用/框架特定优化。这两种类型的设备都可以提高性能,但后者通常更了解最适合特定应用程序框架的优化策略,例如,专注于ASP.NET或AJAX应用程序。

 

原文:https://en.wikipedia.org/wiki/Application_delivery_controller

本文:http://pub.intelligentx.net/application-delivery-controller-0

讨论:请加入知识星球或者小红圈【首席架构师圈】

 

SEO Title
Wikipedia: Application delivery controller

【网络架构】让我们来谈谈代理:第一部分

Chinese, Simplified

不久前,我的队友Yariv在博客中介绍了OpenDNS智能代理,该代理使我们能够超越DNS层并阻止恶意HTTP通信。 此后,我们的团队一直专注于其他项目,例如拥有并整合了我们基础架构中最古老的部分之一,即着陆器,从而释放了70多个服务器,以及一些我们将要讨论的令人兴奋的新功能 关于什么时候开始

今天,我想更详细地介绍智能代理及其支持的技术,即Nginx。

按照惯例,代理是在操作系统的网络设置中或在特定程序(例如HTTP代理的Chrome或Firefox)中明确配置的。

osx-network-settings-proxy

ff-proxy-settings

此外,协议还可以确保代理服务器始终可以在请求时确定客户端的预期目的地。但是,正如Yariv在他的帖子中所解释的那样,我们采用了一种非常规的方法,而不是代理所有内容(无论是否是显性的),而是通过DNS层选择性地将对可疑域的请求重新路由到我们的代理。这种选择性对于减少延迟,负载和影响非常有用,但同时也带来了一些有趣的工程挑战-主要围绕识别用户并确定原始目的地。

例如,当用户尝试浏览到“ some-website.net”时,如果该域被归类为可疑,则OpenDNS解析器将返回最近的Intelligent Proxy服务器的IP地址。客户,例如Firefox或Chrome对此一无所知,并假设接收到的IP地址属于实际托管“ some-website.net”的服务器。对于纯HTTP,很容易确定原始目标是什么,因为HTTP / 1.1要求在每个HTTP请求中设置Host标头,现代浏览器将正确包含此标头。例如,共享主机提供商在为单个IP后面的多个网站提供服务时依赖于此标头。同样,可以利用TLS协议的服务器名称指示(SNI)扩展来代理HTTPS通信。对于其他端口和协议,此过程更为复杂(甚至不可能)。

另一个重要的概念是“正向”代理与“反向”代理的思想。前向代理服务于一组客户端,充当单个访问点并代表客户端查询原始服务器。如前所述,这是在操作系统或Firefox之类的浏览器中配置代理时使用的类型。

反向代理的作用相反,它充当多个服务器组件(例如CGI脚本,文件服务器或数据库)的单点访问。这些代理也通常用作负载平衡器和SSL终结点。

基于此,在服务已路由到它的客户端请求时,我们的智能代理是前向代理。但是它在内部也有一些反向代理,特别是当我们添加新功能和新的数据检查层时。一开始我也提到过,我们选择的技术是Nginx,熟悉Nginx的读者会知道它的设计纯粹是一种反向代理。

在下一篇文章中,我将讨论我们因此而采取的更多非常规方法,以及我们必须解决的挑战。

 

原文:https://umbrella.cisco.com/blog/2015/09/18/lets-talk-about-proxies/

本文:http://jiagoushi.pro/lets-talk-about-proxies

讨论:请加入知识星球或者微信圈子【首席架构师圈】

SEO Title
Let’s Talk About Proxies

【网络架构】让我们来谈谈代理,第二部分:Nginx作为转发HTTP代理

Chinese, Simplified

当我刚开始使用OpenDNS时,我的首要任务是弄清楚Nginx的工作方式,并为其编写一个自定义C模块来处理一些业务逻辑。 Nginx将反向代理到Apache Traffic Server(ATS),它将执行实际的正向代理。 这是一个简化图:

proxy-arch-old

事实证明,Nginx易于理解和使用。 这与ATS相反,后者更大,更复杂,而且简直不好玩。 结果,“为什么我们不整个使用Nginx?”成为一个流行的问题,尤其是在确定代理将不进行任何缓存之后。

正向代理
尽管Nginx是旨在与明确定义的上游一起使用的反向代理:

http {
 upstream myapp1 {
  server srv1.example.com;
  server srv2.example.com;
  server srv3.example.com;
 }

 server {
  listen 80;
  location / {
   proxy_pass http://myapp1;
  }
 }
}

也可以将其配置为基于某些变量使用上游,例如Host标头:

http {
 server {
  listen 80;
  location / {
   proxy_pass http://$http_host$request_uri;
  }
 }
}

这实际上工作得很好。 主要警告是Host标头可以匹配配置中的预定义上游{}(如果存在):

http {
 ...
 upstream foo {
  server bar;
 }
 ...
 server {
  listen 80;
  location / {
   proxy_pass http://$http_host$request_uri;
  }
 }
}

然后,这样的请求将匹配foo并被代理到bar:

GET / HTTP/1.1
Accept: */*
Host: foo

可以通过在自定义模块中使用新变量来扩展此方法,而不是使用内置的$ http_host和$ request_uri进行更好的目标控制,错误处理等。

一切工作都非常好-请注意,这是一个HTTP(端口80)代理,在此我们不考虑HTTPS情况。 一方面,Nginx无法识别显式HTTPS代理中使用的CONNECT方法,因此将永远无法工作。 正如我在之前的博客文章中提到的那样,我们的智能代理通常采用一种更加非常规的方法。

一个大问题是性能。 我们使用ATS进行的初始负载测试得出的数据少于理想值。 Nginx的“ hack”对其性能有没有影响?

负载测试

proxy-load-test

跳过更详细的信息,我们的设置使用wrk作为负载生成器,并使用自定义C程序作为上游。 定制上游是非常基本的。 它所做的就是接受连接,并通过静态二进制Blob响应任何看起来像HTTP的请求。 永远不会显式关闭连接,以消除不必要的额外TCP会话导致的结果中的任何潜在偏差。

我们首先通过直接加载上游服务器来建立基准:

Running 30s test
 10 threads and 100 connections
 Thread Stats Avg Stdev Max +/- Stdev
 Latency 3.27ms 680.48us 5.04ms 71.95%
 Req/Sec 3.21k 350.69 4.33k 69.67%
 911723 requests in 30.00s, 3.19GB read
 100 total connects (of which 0 were reconnects)
Requests/sec: 30393.62
Transfer/sec: 108.78MB

一切看起来都不错,wrk按预期创建了100个连接,并设法每秒挤出3万个请求。

现在,让我们通过Nginx转发代理(2个工作组)进行重复:

Running 30s test
 10 threads and 100 connections
 Thread Stats Avg Stdev Max +/- Stdev
 Latency 6.42ms 14.37ms 211.84ms 99.50%
 Req/Sec 1.91k 245.53 2.63k 83.75%
 552173 requests in 30.00s, 1.95GB read
 5570 total connects (of which 5470 were reconnects)
Requests/sec: 18406.39
Transfer/sec: 66.53MB

这几乎使可能的吞吐量减半。

通过手动请求,我们发现通过Nginx并不会真正增加任何明显的延迟。 Nginx工作人员在测试期间获得了接近100%的CPU使用率,但是增加工作人员人数并没有多大帮助。

上游情况如何,在两种情况下会看到什么?

快速更新以打印一些统计信息后,在直接情况下一切看起来都很好-wrk和上游服务器报告的数字符合预期。 但是,在查看上游服务器统计信息时,我们在代理情况下发现了一些令人吃惊的事情:

status: 552263 connects, 552263 closes, 30926728 bytes, 552263 packets


看起来Nginx为往上游的每个请求创建了一个新连接,尽管wrk仅向下游进行了100个连接…

深入Nginx核心并更全面地阅读文档,事情开始变得有意义。 Nginx是一个负载均衡器,其中“负载”等于请求,而不是连接。连接可以发出任意数量的请求,重要的是在后端之间平均分配这些请求。就目前而言,Nginx在每个请求之后关闭上游连接。上游keepalive模块尝试通过始终保持一定数量的持久连接保持打开状态来对此进行轻微补救。 Nginx Plus提供了诸如会话持久性(Session Persistence)之类的额外功能(顺便说一句,还存在一个等效的开源模块)—使请求可以更一致地路由到相同的上游。

我们真正想要的是客户端及其各自上游之间的一对一持久连接映射。在我们的案例中,上游是完全任意的,我们要避免创建不必要的连接,更重要的是,不要以任何方式“共享”上游连接。我们的会议是整个客户连接本身。

补丁


该解决方案非常简单,我们已经在Github 上提供了该解决方案。

通过此更改重新运行负载测试,我们可以获得更好的结果,概述了保持TCP连接持久性并避免那些昂贵的打开/关闭操作的重要性:

Running 30s test
 10 threads and 100 connections
 Thread Stats Avg Stdev Max +/- Stdev
 Latency 10.82ms 48.67ms 332.65ms 97.72%
 Req/Sec 3.00k 505.22 4.46k 95.81%
 854946 requests in 30.00s, 3.02GB read
 8600 total connects (of which 8500 were reconnects)
Requests/sec: 28498.99
Transfer/sec: 103.01MB

上游的数字与wrk的数字匹配:

status: 8600 connects, 8600 closes, 47882016 bytes, 855036 packets


但是,仍然存在问题。有8600个连接,而不仅仅是100个。 Nginx决定关闭上游和下游的许多连接。当进行调试以查看原因时,我们最终追溯到“ lingering_close_handler”:

...
nginx: _ngx_http_close_request(r=0000000000C260D0) from ngx_http_lingering_close_handler, L: 3218
nginx: ngx_http_close_connection(00007FD41B057A48) from _ngx_http_close_request, L: 3358
...


由于即使使用此行为,整体效果还是令人满意的,因此我暂时不这样做了。

收盘中


我们已经将Nginx作为生产中的正向HTTP代理运行了一段时间,几乎没有问题。我们希望继续扩展Nginx的功能,并推动新的界限。请留意未来的博客文章和代码片段/补丁。

*这是一个重写的补丁程序(原始补丁有点笨拙),这个新代码最近才投入生产。如果有任何问题,我将进行任何调整以更新公共补丁。

 

原文:https://umbrella.cisco.com/blog/2015/11/03/lets-talk-about-proxies-pt-2-nginx-as-a-forward-http-proxy/

本文:http://jiagoushi.pro/node/917

讨论:请加入知识星球或者微信圈子【首席架构师圈】

SEO Title
Lets Talk About Proxies, Pt. 2: Nginx as a Forward HTTP Proxy