1. 引言



如何为Ceph分布式存储选择合适的SSD这个问题看似简单,其实内藏不少玄机,不是所有的SSD都适合用,因为SSD有很多我们平时可能没有关注过的一些特性,这些特性会影响Ceph的使用性能或寿命,下面我们一一道来。



2. 如何为Ceph选择SSD?



2.1 – 类别


其实SSD是有分为企业级SSD和消费级SSD,企业级SSD磁盘的参数,如:性能、可靠性、耐久度都不是消费级SSD能比的,所以为Ceph选择合适的SSD规则就是:

不要使用消费级SSD,一定要使用企业级SSD。

按照固态硬盘应用场景的分类,可以分成三种:写入密集型、读取密集型和混合读写型。

  1. 写入密集型环境下对SSD耐写度要求高,通常使用MLC存储单元,要求SSD能长时间承受连续写入而不会导致性能严重下降。常用型号:英特尔 SSD DC P3700 系列,DWPD=10 (800G)。
  2. 读取密集型应用环境的SSD通常采用TLC甚至更低的存储单元,在NAND技术加持下,容量和耐写度得到了提升,而价格却很低廉。常用型号:英特尔 SSD DC S4500 系列,DWPD=1。
  3. 常用型号:混合型其实就是读密集型的基础上,能够承受更大一点的写入,性能依然不能和写密集型的相比。DWPD一般在1-10之间。

九月技术周|如何为Ceph选择合适的SSD?

如果SSD做为Ceph日志盘使用,那么就选择写入密集性SSD。

2.2 – 耐久度


SSD耐久度就是SSD的寿命,那为什么SSD要有寿命呢,不像HDD没有听过还有耐久度这个参数,那是因为这两种磁盘原理不同,SSD的数据存储原理是使用闪存NAND存储数据,而NAND是有写入次数限制,以浮栅极型NAND闪存为例,闪存是通电与否代表计算机可识别的1、0状态,加电瞬间会产生强大的电场(大于1000万 vt/cm),这么强的电场会破坏隧道氧化层的原子结合,脱离的电子就会上升到浮栅极上以形成电位变化,断电之后电子还会恢复正常位置,这样反复的断电-加压就形成了不同的电位信号。

加电的过程等同于HDD硬盘的数据写入操作,它被称为“Program(编程)”,断电的过程电位恢复,这相当于HDD硬盘的擦除数据,这里成为“Erase(擦除)”,完整的一次P/E循环就是NAND的写入循环,从这里也可以看出SSD要想写入数据就需要恢复默认电位,也就是以“擦除”为前提,这原理最直接的影响就是SSD寿命,因为P/E循环次数是有限的,而不同类型的闪存P/E次数是不一样的。

一般厂家使用DWPD或TBW这两个指标衡量SSD耐久度,下面我们分别介绍下这两个参数:

  • DWPD:每日整盘写入次数 Drive Writes Per Day (DWPD) ,指在预期寿命内可每日完整写入SSD固态硬盘所有容量的次数,也有的文章写成DW/D也是同样的意思。


  • TBW/PBW:写入的字节 Terabytes Written (TBW),Petabytes Written(PBW),指在 SSD 使用寿命结束之前指定工作量可以写入 SSD 的总数据量。PBW也有的文章写成是TBW(PB),其实这两个单位是相同的,PBW = TBW(PB) 。

现在大家看到SSD参数用的TBW/PBW会多一些,如下面intel dc p4500 ssd参数:

九月技术周|如何为Ceph选择合适的SSD?
九月技术周|如何为Ceph选择合适的SSD?

其实这两个标准是可以相互转换的,通过PBW可以推算出DWPD,反之也可以。

DWPD或DW / D:每日完整写入SSD固态硬盘所有容量的次数。
GB /Day:每天写入的GB。
TBW:写入的总字节数,通常以TB-TBW(TB)或PB-TBW(PB)表示。
PBW :写入PB
S表示磁盘容量(以GB为单位)
T表示保修/使用寿命(以年为单位)

  • DWPD = GB/day ÷ S
  • DWPD = (TBW(TB) × 1000) ÷ (S × T × 365)
  • GB/day = S ×DWPD  
  • GB/day = (TBW(TB) × 1000) ÷ (T × 365)
  • TBW(TB) = (DWPD × S × T × 365) ÷ 1000
  • TBW(TB) = (GB/day × T × 365) ÷ 1000
  • PBW = TBW(PB) = TBW(TB) ÷ 1000

如我们已知一个SSD TBW为1432TB,想计算下DWPD用到以下公式:

DWPD = (TBW(TB) × 1000) ÷ (S × T × 365)

九月技术周|如何为Ceph选择合适的SSD?

可以算出DWPD为0.43,现通过以公式算出每天写入量:

GB/day = S  × DWPD
1800GB × 0.43 = 774

当然如果觉得这么麻烦的话,可以使用在线计算工具,网址如下:https://wintelguy.com/dwpd-tbw-gbday-calc.pl

我们再用这个计算工具检查下上面的结果,可以看到最终结果是一样的。

九月技术周|如何为Ceph选择合适的SSD?

为什么写入耐久性对SSD很重要呢?因为Ceph使用SSD作为日志盘使用,会有大量的写操作,有可能超过SSD的额定耐久性,也就是超出了SSD的P/E循环次数,所以选择SSD一定要:

选择TBW/PBW或DWPD大的SSD。

因为Ceph写入日志大量使用,最佳选择是包括5年内每天超过10次设备写入(DWPD)的设备,这相当于在整个生命周期内写入的总容量为28PB(PBW)。

2.3 – 断电保护


断电保护几乎是企业级固态硬盘的标配功能,它的作用是在发生意外断电(非正常关机)时,保护板载DRAM缓存中的数据不致丢失。

九月技术周|如何为Ceph选择合适的SSD?

超级电容器用于断电保护至关重要。在电源故障的情况下,超级电容器的大小必须适当,以允许驱动器将所有正在进行的写入保存到非易失性NAND存储中。

由于固态硬盘的DRAM缓存中除了用户读写的数据缓存之外,还包含了相当大容量的FTL闪存映射表,这张虚拟表对固态硬盘工作极为重要,一旦丢失的话固态硬盘就会变砖(无法被识别),所以必须得有断电保护电容。

选择有断电保护电容的SSD。

2.4 – 性能


如果SSD为作日志盘使用,SSD设备的写入吞吐量额定值应超过该日志设备所服务的所有底层OSD设备的总写入吞吐量额定值,如下图可以查看到该SSD的写吞吐量。

九月技术周|如何为Ceph选择合适的SSD?

2.5 – 总结


上面总结了几条为Ceph选择SSD的参数,有SSD类别、耐久度、断电保护、性能,断电保护一般企业级的SSD都会有,SSD吞吐量一般SSD也不是相差太多,还有就是SSD类别中其实也隐含了不同的耐久度,所以精简下就是为Ceph选择SSD的最佳实践就是:

选择写入密集性的企业级SSD!!!
 

 

关于九州云99Cloud


九州云成立于2012年,是中国早期从事开放基础架构服务的专业公司。公司成立八年,秉承“开源 · 赋能变革”的理念,不断夯实自身实力,先后为政府、金融、运营商、能源、制造业、商业、交通、物流、教育、医疗等各大行业的企业级客户提供高质量的开放基础架构服务。目前拥有国家电网、南方电网广东公司、中国人民银行、中国银联、中国移动、中国电信、中国联通、中国资源卫星、eBay、国际陆港集团、中国人寿、万达信息、东风汽车、诺基亚等众多重量级客户,被用户认可为最值得信赖的合作伙伴。

九月技术周|如何为Ceph选择合适的SSD?



1. 前言



新⼀代数据中⼼的典型特点是从 “物理服务器互联” 转变为 “虚拟机” 互联。虚拟化技术为数据中⼼带来了服务器整合、业务连续性和弹资源性等优势,也给数据中⼼带来了新的挑战,即:如何实现针对虚拟机的服务器⽹络接⼊技术。




2VEB技术



VEB(Virtual Ethernet Bridge,虚拟以太⽹交换机)是虚拟机与服务器⽹络接⼊层之间的⼀个新的⽹络层。解决的是同⼀服务器中不同虚拟机如何通过同⼀张物理⽹卡与外部⽹络进⾏通信,以及这些虚拟机之间如何互相通信的问题。最初为通过纯软件⽅式实现的 vSwitch,后续为了解决性能问题也出现了基于 SR-IOV ⽹卡的 Hardware-based VEB 实现。


数据中心服务器网络接入技术 — VEB、VEPA、VN-Tag

vSwitch


以软件实现的 vSwitch:实现⽅式简单,技术兼容性好,典型软件有:Open vSwitch、VMware ESXi。


  • VMware ESXi,由 VMM 内嵌的 VEB:

数据中心服务器网络接入技术 — VEB、VEPA、VN-Tag


  • Open vSwitch,在服务器上运⾏的(第三⽅)VEB:


数据中心服务器网络接入技术 — VEB、VEPA、VN-Tag


vSwitch ⽅案具有以下优点:


  • 本地虚拟机之间的报⽂转发性能好,流量不出卡。

  • 节省接⼊层物理交换机设备,⼀张物理⽹卡⽀持多个虚拟机。


与外部⽹络的兼容性好,不需要对外部⽹络进⾏改造。缺点:


  • 占⽤服务器的 CPU 资源。

  • 只能实现简单的 L2 转发。

  • 缺乏⽹络流量的可视性,例如:端⼝报⽂统计、端⼝流镜像、Net Stream 等,导致虚拟机之间的流量⽆法被⽹管系统所监管,另⼀⽅⾯也使得⽹络发⽣故障时,难于定位问题原因。

  • 缺乏⽹络控制策略的实施能⼒,例如:端⼝安全,QoS、ACL 等,导致限制了数据中⼼的端到端⽹络控制策略的部署能⼒。

  • 缺乏管理可扩展性,vSwitch 数量剧增,且与外部⽹络⽆法进⾏统⼀管理。

  • VEB 的以上这些缺陷,最终导致了计算资源和⽹络资源的管理界⾯模糊,继⽽解决了服务器团队和⽹络团队的管理定界问题。


HW VEB


以硬件实现的 SR-IOV ⽹卡设备:借助⽀持 SR-IOV 特性的⽹卡可以实现基于 HW VEB。


HW VEB 的设计思想是:将 vSwitch 的交换功能 offload 到硬件设备,通过⽹卡硬件改善 vSwitch 占⽤ CPU 资源⽽影响虚拟机性能的问题。HW VEB ⽅案必须采⽤⽀持 SR-IOV(Single-Root I/O Virtualization)特性的 PCIe⽹卡,否则⼀张物理⽹卡⽆法映射到多个虚拟机上。


  • Intel x710 VEB


数据中心服务器网络接入技术 — VEB、VEPA、VN-Tag


在 HW VEB ⽅案中的 VMM(e.g. ESXi、KVM)只需要实现 SR-IOV ⽹卡设备的驱动程序(e.g. 资源分配、中断处理等)⽽不再参与虚拟机与外部⽹络,以及虚拟机之间的报⽂转发流程。


  • 对于虚拟机发往外部⽹络的报⽂,由虚拟机操作系统的驱动程序直接操作⽹卡寄存器进⾏发送;

  • 对于外部⽹络发往虚拟机的报⽂,⽹卡设备根据 dstMAC,将报⽂放⼊虚拟机对应的接收队列,虚拟机操作系统的驱动程序再通过 DMA 或中断⽅式进⾏接收处理;

  • 对于同⼀物理服务器中的虚拟机之间的报⽂转发,⽹卡通过查讯内部 MAC table(静态配置,通常不⽀持 MAC 学习)进⾏转发处理。


数据中心服务器网络接入技术 — VEB、VEPA、VN-Tag


基于 SR-IOV 技术的 HW VEB ⽅案的优点:


  • 硬件设备、SR-IOV VF 直通,所以报⽂转发性能⾼。


但是,HW VEB 依然存在不能有效解决虚拟机流量可视化、⽹络策略实施及管理可扩展性等问题,甚⾄会由于硬件设计、成本等原因还恶化了这些问题。




3虚拟机流量感知技术



为了解决 VEB 技术存在的问题:缺乏⽹络流量的可视性、缺乏⽹络控制策略的实施能⼒、 缺乏管理可扩展性,需要反思两点原因:


1. 虚拟机之间的本地流量不出卡。

2. 虚拟机在外部⽹络的流量没有标识信息。


所以,解决问题的办法⾃然是:


1. 把虚拟机的⽹络流量纳⼊传统⽹络交换设备的管理之中

2. 同时还需要对虚拟机的流量做标识。


这就是所谓的虚拟机流量感知技术。对此,思科和惠普两⼤联盟分别提出了⾃⼰的解决⽅案:


  • 思科和 VMware 主推的是 VN-Tag 技术,标准为 802.1Qbh BPE(Bridge Port Extension,端⼝扩展设备):尝试从接⼊层到汇聚层提供⼀个完整的虚拟化⽹络解决⽅案,尽可能达到软件定义⼀个可控⽹络的⽬的。它扩展了传统的⽹络协议,因此需要新的⽹络设备⽀持,成本较⾼。

  • 惠普、Juniper、IBM、Qlogic、Brocade 主推的是 VEPA(Virtual Ethernet Port Aggregator,虚拟以太端⼝汇聚器),标准为 802.1Qbg EVB(Edge Virtual Bridging,边缘虚拟交换机):尝试以较低成本利⽤现有设备改进软件模拟的⽹络。


EVB


EVB 将 VEPA 作为基本实现⽅案,将多通道技术(Multi-Channel Technology)作为扩展⽅案。由于EVB 要求将所有的虚拟机流量都引向外部的物理交换机,因此与虚拟机相关的流量监管、控制策略和管理可扩展性问题得以解决。但同时也带来了更多⽹络带宽开销和转发时延的问题。需要注意的是,EVB的出现并不是完全替换 VEB ⽅案,但是 EVB 对于需要对虚拟机流量进⾏感知的场景⽽⾔,是⼀种优选的⽅案。


  • VEPA


数据中心服务器网络接入技术 — VEB、VEPA、VN-Tag


上图显示了 VEPA 的基本概念:在服务器中,物理⽹卡将虚拟端⼝根据⼀定的规则进⾏分组,完成端⼝分组(Port Group)功能。同时这个⽹卡设备能够对外抽象出被分为⼀组的端⼝,将属于同⼀组端⼝的数据⼀起投递出去,完成端⼝汇聚功能(Port Aggregation)。


VEPA 的核⼼思想是:将虚拟机产⽣的⽹络流量(包括本地流量和外部流量)全部强制地交由与服务器相连的物理交换机进⾏处理,然后物理交换机再将数据返回进来,⽽不再通过本地虚拟交换机来处理。我们知道,传统物理交换机的数据帧是不能从进⼝出去的,所以需要对物理交换机硬件作修改,允许其绕回。如下图,由 VM1 发往 VM2 或 VM3 的报⽂,⾸先被发往外部交换机,查表后,报⽂沿原路返回服务器,这种⼯作模式称之为发卡弯(hairpin turn)转发。


NOTE 1:以太⽹交换机在处理报⽂转发时,对于从⼀个端⼝上收到的报⽂,不会再将该报⽂从该端⼝发回。因此,当使能 VEPA 特性的服务器接⼊到⼀个外⽹交换机上时,该交换机相应端⼝必须⽀持上述 “发卡弯” 转发⽅式。可幸的是,当前⼤多数交换机的硬件芯⽚都能⽀持这种 “发卡弯” 转发特性,只要修改驱动程序即可实现,不必为⽀持 “发卡弯” ⽅式⽽增加新的硬件芯⽚。


NOTE 2:另⼀个由 VEPA 技术引起的变化是服务器对从外部⽹络接收到组播或⼴播报⽂的处理⽅式。由于 VEPA 从物理⽹卡上收到的报⽂可能是来⾃外部交换机的 “发卡弯” 报⽂,也就是说 srcMAC 可能是服务器上的虚拟机的 MAC 地址,这种报⽂必须进⾏过滤处理,以避免发送该报⽂的虚拟机再次从⽹络上收到⾃⼰发出的组播或⼴播报⽂。因此,当前的操作系统或⽹卡驱动都需要做相应的修改。


数据中心服务器网络接入技术 — VEB、VEPA、VN-Tag


相对于 VN-Tag,VEPA 的优点在于:完全基于 IEEE 标准,不需要专⽤的报⽂格式,⽽且容易实现。通常只需要对⽹卡驱动、VMM 的 Bridge 模块和外部交换机的软件做很⼩的改动,从⽽实现低成本⽅案⽬标。


与 VEB 类似,VEPA 也同样具有纯软件和基于 SR-IOV 技术的硬件两种实现⽅式:


Intel x710 VEPA:


数据中心服务器网络接入技术 — VEB、VEPA、VN-Tag


  • Multi-Channel


在数通⽹络⾥,想要标识流量,肯定是要使⽤特定的字段来做。HP 使⽤的是 QinQ(802.1ad),在标准 VEPA 的基础上使⽤ QinQ 的 S-TAG 来标识虚拟机流量,形成了增强型 VEPA,即:802.1Qbg MultiChannel(多通道技术)。


多通道技术是⼀种通过给虚拟机报⽂增加 IEEE 标准报⽂标签,以增强 VEPA 功能的⽅案。通过标签机制,可以实现 VEB、Director IO 和 VEPA 的混合部署⽅案,借助多通道技术,管理员可以根据⽹络安全、性能以及可管理等⽅⾯的需求,灵活的选择虚拟机与外部⽹络的接⼊⽅案(VEB、Director IO 或 VEPA)。


多通道技术由 HP 公司提出,最终被 IEEE 802.1 ⼯作组接纳为 EVB 标准的⼀种可选⽅案。多通道技术⽅案将交换机端⼝或⽹卡划分为多个逻辑通道,并且各通道间逻辑隔离。每个逻辑通道可根据⽤户需要定义成 VEB、VEPA 或 Director IO 的任何⼀种。每个逻辑通道作为⼀个独⽴的到外部⽹络的通道进⾏处理。多通道技术借⽤了 802.1ad S-TAG(QinQ)标准,通过⼀个附加的 S-TAG 和 VLAN-ID来区分⽹卡或交换机端⼝上划分的不同逻辑通道。


多通道技术使外部物理交换机通过报⽂的 S-TAG 识别⽹络流量来⾃哪个 VEAP/VEB,或来⾃哪个Director IO 的⽹卡。反之亦然。


数据中心服务器网络接入技术 — VEB、VEPA、VN-Tag


如上图,多通道技术可组合出多种⽅案:


1. 管理员通过多通道技术解决 VEB 与 VEPA 共享⼀个外部⽹络(⽹卡)的需求,多个 VEB 或 VEPA共享同⼀个物理⽹卡。管理员可以为特定的虚拟机使⽤ VEB,以获得较好的交换性能;也可以为其他虚拟机使⽤ VEPA,以获得更好的⽹络控制策略可实施性和流量可视性。


2. 直接将⼀个虚拟机映射到物理⽹卡上(SR-IOV VF Director IO),⽽其它的虚拟机仍然通过 VEB 或VEPA 共享物理⽹卡。


BPE


BPE(Bridge Port Extension,端⼝扩展设备)是⼀种功能有限的物理交换机,通常作为⼀个上⾏物理交换机的线卡使⽤。端⼝扩展技术需要在标准的以太⽹数据帧中增加⼀段 TAG,端⼝扩展设备借助 TAG中的信息,将端⼝扩展设备上的物理端⼝映射成上⾏物理交换机上的⼀个虚拟端⼝,并且使⽤ TAG 中的信息来实现报⽂转发和策略控制。当前市场上的端⼝扩展设备主要由思科的 Nexus 2K 和 Nexus 5K。


数据中心服务器网络接入技术 — VEB、VEPA、VN-Tag


BPE 有 VN-Link 和 FEX 两⼤部分组成。VN-Link 部署在服务器的交换组件上,负责虚拟机的接⼊,⽽FEX 部署在接⼊层的物理交换机上,负责虚拟机间的互通。两者配合在⼀起实现了虚拟机的实时感知和分布式接⼊,接⼊配置和策略的集中式分发保证了虚拟机的⽆缝迁移。


图中,Port Extender 向下为 VN-Link 技术,向上为 FEX 技术:


  • VN-Link 由⽀持 VN-TAG 的⽹卡实现,如 Cisco UCS ⼑⽚服务器中集成的 Palo,该⽹卡只负责 VNTAG 的封装/解封装,不做任何策略相关的⼯作。

  • FEX 技术由 Cisco 的 N2K/N5K 组合实现,⽀持以级联⽅式组⽹,其中 N5K 负责寻址转发和策略的制定,N2K 则作为 N5K 的远端板卡部署在 TOR 实现分布式接⼊,N5K 通过 VIC 协议分发给N2K,实现分布式转发。


VN-TAG 体系将数据中⼼的接⼊⽹络虚拟成了⼀个⼤的接⼊交换机,由 VN-Link 充当⽹线,由 N2K 充当分布式线卡,N5K 充当主控板,处于任何物理位置的虚拟机都好像连接在这个⼤的接⼊交换机上。⾼带宽、⽆阻塞和低时延的优良特性使得 N2K/N5K 间⽹络连接能够与单机内总线相当,保证了分布式接⼊的性能。在 N5K 上可以基于虚拟机对应的 SVI_ID/DVI_ID 制定 ACL,QoS 和流控等⾼级接⼊策略,⽀持⽹络策略随虚拟机任意的漂移。


  • VN-Tag


为了实现端⼝扩展(Port Extension),思科和 VMware 共同推出了 VN-TAG 标准。其核⼼思想是:在标准以太⽹数据帧中增加⼀段专⽤的标记 VN-Tag,⽤以区分不同的 vNIC(虚拟机的虚拟接⼝),从⽽识别特定的虚拟机的流量,并且标明了报⽂的⼴播域。可⻅ VN-Tag 技术是思科的⼀套闭源的全栈⽅案,VN-Tag 报⽂格式并不建⽴在 IEEE 已定义的各种标准之上的。


数据中心服务器网络接入技术 — VEB、VEPA、VN-Tag


VN-TAG 将 6 个字节的新字段插⼊到 VLAN 的前⾯,这些字节只在 VN-TAG 设备中出现,现有的协议(包括 VLAN 的使⽤)不会受到任何的影响。其中,DVIF_ID/SVIF_ID 是⽬的/源虚拟机被分配的唯⼀标识,各有 12 位,通过 Port Profile 的配置与虚拟机接⼊端⼝进⾏⼀对⼀的通道绑定,VN-TAG 物理交换机将根据这个标识来识别虚拟机,实现⽹络接⼝虚拟化。其他的标志位⽤于 FEX 系统中,D 位标识报⽂的⾛向,P 位标识报⽂是否需要复制,L 位标识源主机和⽬的主机是否连接在同⼀台物理交换机上,R 位作为保留。


通信流程:服务器中的交换组件不进⾏ MAC 寻址,它接受源虚拟机的流量,封装好 VN-TAG(标记SVI_ID),然后直接交给上游的物理交换机,上游的交换机完成 SVI_ID 对源 MAC 地址、VLAN 和⼊端⼝的学习,根据⽬的 MAC 地址标记 DVI_ID,然后转发给⽬标服务器,⽬标服务器根据 DVI_ID 进⾏通道转发,剥掉 VN-TAG 后转发给⽬标虚拟机。


思科针对 VN-Tag ⼜推出了名为 Palo 的虚拟服务器⽹卡,Palo 卡为不同的虚拟机分配并打上 VN-Tag 标签。如下图,上联交换机与服务器之间通过 VN-Tag,使上联交换机能区分不同虚拟机产⽣的流量,并在物理交换机上⽣成对应的虚拟接⼝ vIF(Virtual InterFace),和虚拟机的 vNIC ⼀⼀对应起来,这就好像把虚拟机和物理交换机直接对接起来,全部交换⼯作都在上联交换机上进⾏,即使是同⼀个物理服务器内部的不同虚拟机之间的流量交换,也通过上联交换机转发。


数据中心服务器网络接入技术 — VEB、VEPA、VN-Tag


相对于 VEPA,VN-TAG 技术有⼀些缺点:


  • VN-TAG 是⼀种新提出的标签格式,没有沿⽤现有的标准(如 IEEE 802.1Q、 IEEE 802.1ad、IEEE 802.1X tags)。

  • 必须要改变交换机和⽹卡的硬件,⽽不能只是简单的对现有的⽹络设备软件进⾏升级。也就是说,VN-TAG 的使⽤需要部署⽀持 VN-TAG 的新⽹络产品(⽹卡、交换机、软件)。


最初 IEEE 802.1 ⼯作组曾考虑将 “端⼝扩展” 作为 EVB 标准的⼀部分,但是最终决定将端⼝扩展发展成⼀个独⽴的标准,即 802.1 Bridge Port Extension。Cisco 曾向 IEEE 802.1Q ⼯作组建议,将其私有的VN-TAG 技术作为实现 EVB 的⼀种可选⽅案,但⼯作组最终没有接纳这个提案。Cisco 后来修改了 VN-TAG 技术草案,修改后的草案称为 M-TAG,该⽅案的主要⽬标仍是为了实现端⼝扩展设备与上⾏交换机

之间的通信标准化。


参考⽂档:

https://wenku.baidu.com/view/fc085465312b3169a551a41d.html 

https://www.internet2.edu/presentations/jt2009jul/20090719-congdon.pdf



 

关于九州云99Cloud


九州云成立于2012年,是中国早期从事开放基础架构服务的专业公司。公司成立八年,秉承“开源 · 赋能变革”的理念,不断夯实自身实力,先后为政府、金融、运营商、能源、制造业、商业、交通、物流、教育、医疗等各大行业的企业级客户提供高质量的开放基础架构服务。目前拥有国家电网、南方电网广东公司、中国人民银行、中国银联、中国移动、中国电信、中国联通、中国资源卫星、eBay、国际陆港集团、中国人寿、万达信息、东风汽车、诺基亚等众多重量级客户,被用户认可为最值得信赖的合作伙伴。

数据中心服务器网络接入技术 — VEB、VEPA、VN-Tag

QEMU Guest Agent,简称 QGA,是运⾏在 QEMU 虚拟机内部的⼀个守护程序 qemu-guest-agent.service,类似于 VMware tools,主要⽤于辅助 Hypervisor 实现对 Guest 的管理。


官⽅⽹站:

https://wiki.qemu.org/Features/GuestAgent

https://wiki.libvirt.org/page/Qemu_guest_agent


QEMU 通过建⽴ Host 和 Guest 之间的⼀个数据通道(channel)来实现两者之间的通讯功能,继⽽增 Host  Guest 的控制能⼒。这种通讯⽅式是不依赖与⽹络的,⽽是依赖于 virtio-serial(默认⾸选⽅式)或者 isa-serial,在 Domain XML ⽂件中称为 org.qemu.guest_agent.0QEMU 提供了串⼝设备的模拟及数据交换的通道,最终呈现出来的是⼀个串⼝设备(Guest)和⼀个 UNIX Socket ⽂件Host)。


<channel type=‘unix‘> <source mode=‘bind‘path=‘/var/lib/libvirt/qemu/org.qemu.guest_agent.0.instance-00000011.sock‘/><target type=‘virtio‘ name=‘org.qemu.guest_agent.0‘/><address type=‘virtio-serial‘ controller=‘0‘ bus=‘0‘ port=‘1‘/></channel>


QGA 通过读写串⼝设备与 Host UNIX Socket 进⾏交互,在宿主机上则通过常规的⽅式对 UNIX Socket⽂件进⾏读写,最终实现两者的交互,交互的协议与 qmpQEMU Monitor Protocol)相同,简单的说就是使⽤ JSON 格式进⾏数据交换。串⼝设备的速率通常都较低,所以⽐较适合⼩数据量的交换。


Libvrit也提供了专⻔的virDomainQemuAgentCommand API,在终端中通过virsh qemu-agent-command指令暴露,与QGA进⾏通信和操作,常⽤于实现 QEMU Guest 的监控和后台管理,例如:修改虚拟机的密码。


virsh qemu-agent-command <domain> '{"execute":"guest-ping"}'virsh qemu-agent-command <domain> '{"execute":"guest-info"}'virsh qemu-agent-command <domain> '{"execute":"guest-network-get-interfaces"}'virsh reboot --mode agent <domain># 修改密码virsh qemu-agent-command <domain> '{"execute":"guest-set-userpassword","arguments":{"username":"admin","password":"cGFzc3cwcmQ=","crypted":false}}'# orvirsh set-user-password --domain <domain> --user admin --password cGFzc3cwcmQ=


安装 QGA


⼿动安装:


$ yum install qemu-guest-agent$ setenforce 0$ systemctl restart qemu-guest-agent.service

在 OpenStack 环境中,⾃ L 版只需要为 Image 设置 hw_qemu_guest_agent 属性即可启⽤ QGA,前提 image 以及安装了相应的软件包:


nova image-meta <image-id> set hw_qemu_guest_agent=yes# orglance image-create --name cirros--disk-format raw--container-format bare--file cirros-0.3.3-x86_64-disk.raw--public--property hw_qemu_guest_agent=yes--progress# oropenstack image set --property hw_qemu_guest_agent=yes <image-id>


然后就可以使⽤ novaclient 修改虚拟机密码了,详⻅:

https://specs.openstack.org/openstack/nova-specs/specs/liberty/implemented/libvirt-set-admin-password.html。


openstack server set --root-password <instance-uuid>


QGA 接⼝


NOTE:不同的 GuestOS 具有不同的指令⽀持程度,这⾥需要注意,Windows OS 因为是闭源的操作系统,所以⽀持有限,详⻅:https://fedoraproject.org/wiki/Windows_Virtio_Drivers.


  • guest-sync-delimited:宿主机发送⼀个 Int 数字给 QGA,QGA 返回这个数字,并且在后续返回字符串响应中加⼊ ascii 码为 0xff 的字符,其作⽤是检查宿主机与 QGA 通信的同步状态,主要⽤在宿主机上多客户端与 QGA 通信的情况下客户端间切换过程的状态同步检查,⽐如:有两个客户端ABQGA 发送给 A 的响应,由于 A 已经退出,⽬前 B 连接到 QGA,所以这个响应可能被 B 到,如果 B 连接后,⽴即发送该请求给 QGA,响应中加⼊了这个同步码就能区分是 A 的响应还是的响应。 QGA 返回宿主机客户端发送的 Int 数字之前,QGA 返回的所有响应都要忽略。

  • guest-sync:同上,只是不在响应中加⼊ 0xff 字符。

  • guest-ping:Ping the guest agent, a non-error return implies success。

  • guest-get-time:获取虚拟机时间(返回值为相对于 1970-01-01 in UTC,Time in

  • nanoseconds)。

  • guest-set-time:设置虚拟机时间(输⼊为相对于 1970-01-01 in UTC,Time in nanoseconds)。

  • guest-info:返回 QGA ⽀持的所有命令。

  • guest-shutdown:关闭虚拟机,⽀持 halt、powerdown、reboot ⽅式,默认为 powerdown。

  • guest-file-open:打开虚拟机内的某个⽂件(返回⽂件句柄)。

  • guest-file-close:关闭打开的虚拟机内的⽂件。

  • guest-file-read:根据⽂件句柄读取虚拟机内的⽂件内容(返回 base64 格式的⽂件内容)。

  • guest-file-write:根据⽂件句柄写⼊⽂件内容到虚拟机内的⽂件。

  • guest-file-seek:Seek to a position in the file, as with fseek(), and return the current file position afterward. Also encapsulates ftell()’s functionality, just Set offset=0, whence=SEEK_CUR

  • guest-file-flush:Write file changes bufferred in userspace to disk/kernel buffers。

  • guest-fsfreeze-status:Get guest fsfreeze state. error state indicates。

  • guest-fsfreeze-freeze:Sync and freeze all freezable, local guest filesystems。

  • guest-fsfreeze-thaw:Unfreeze all frozen guest filesystems。

  • guest-fstrim:Discard (or “trim”) blocks which are not in use by the filesystem。

  • guest-suspend-disk*:Suspend guest to disk。

  • guest-suspend-ram*:Suspend guest to ram。

  • guest-suspend-hybrid:Save guest state to disk and suspend to ram(This command requires the pm-utils package to be installed in the guest.)。

  • guest-network-get-interfaces:Get list of guest IP addresses, MAC addresses and netmasks。guest-get-vcpus:Retrieve the list of the guest’s logical processors。

  • guest-set-vcpus:Attempt to reconfigure (currently: enable/disable) logical processors inside the guest

 

 

关于九州云99Cloud


九州云成立于2012年,是中国早期从事开放基础架构服务的专业公司。公司成立八年,秉承“开源 · 赋能变革”的理念,不断夯实自身实力,先后为政府、金融、运营商、能源、制造业、商业、交通、物流、教育、医疗等各大行业的企业级客户提供高质量的开放基础架构服务。目前拥有国家电网、南方电网广东公司、中国人民银行、中国银联、中国移动、中国电信、中国联通、中国资源卫星、eBay、国际陆港集团、中国人寿、万达信息、东风汽车、诺基亚等众多重量级客户,被用户认可为最值得信赖的合作伙伴。

QEMU Guest Agent

11月4日,开放基础设施峰会在上海世博中心隆重召开,会议第一天就成功吸引数千名集聚一堂,共同构建用户所需的开源基础设施以支持在边缘计算、持续集成/持续交付(CI / CD)、人工智能(AI)、高性能计算(HPC)等领域的应用。与往届一样,小编会从参与者的角度为大家带来重要的会议信息,今天将第一天主论坛的精彩内容分享一二。


本次Open Infrastructure summit是从第一次奥斯丁峰会以来首次登陆中国大陆,国内的云厂商做东,在本次的赞助商中,国内的云厂商也占据了半壁江山,九州云作为黄金会员给与了基金会大力的支持。


开放基础设施上海峰会 | 中国首秀会送出哪些重磅内容呢?


市场预测:用数据说话


在当前的中美关系的背景下,基金会坚持把峰会举办地点定在了上海,说明基金会更加关注亚洲的市场,更加关注OpenStack在中国的发展。在面对市场上“唱衰”OpenStack的噪音,本次峰会给出了大量的统计数据,本次峰会的Keynote上,基金会预测到2023年亚太地区的OpenStack市场体量还会再增加36%。


开放基础设施上海峰会 | 中国首秀会送出哪些重磅内容呢?


并且,基金会预测到了2023年全球商业规模将达到7.7Billion USD的市场,这证明了在开源的基础设施架构的整个体量来说,还是非常巨大的。


开放基础设施上海峰会 | 中国首秀会送出哪些重磅内容呢?


Open Infra集成了容器和OpenStack,在容器市场蓬勃发展的同时,也带动了OpenStack的发展,两者全球合并的市场规模在2023年将达到12billion的规模。


开放基础设施上海峰会 | 中国首秀会送出哪些重磅内容呢?


另外,基金会给出了这几年OpenStack市场的规模,从2015年的1.27Billion,到今年2019年的3.39Billion,以及在规模了有了巨大的增加,另外下图还预测了从2019年的市场规模到2023年的增加预测,即OpenStack市场的规模在下一个4年会持续增长,并且会比2019年的市场规模增加一倍之巨。


开放基础设施上海峰会 | 中国首秀会送出哪些重磅内容呢?


基金会给出了一个统计,目前OpenStack已经管理了上千万个计算内核,而且还在不断增长,图中是使用了OpenStack服务的用户,OpenStack作为全球前三的开源组织,经过多年社区运营和开发人员的努力,逐渐成为了云计算操作系统的标准,取得了市场的认可和用户的信任。


开放基础设施上海峰会 | 中国首秀会送出哪些重磅内容呢?


坚持开源,开源推动创新


OpenStack还会继续坚持开源,秉承着“开源推动创新”的理念,开源才能聚集全球大量优秀的开发者,开源才能赋能产品的持续创新能力,开源才能满足自主可控取得用户的信任。


开放基础设施上海峰会 | 中国首秀会送出哪些重磅内容呢?


在最新版本Train项目上,来自各个国家的贡献者,来自中国的贡献者已经非常接近于美国了,正是基金会看到了大量优秀的来自中国的开发人员,由此在上海举办的峰会上重点强调中国的市场和贡献者是不容忽视的,正是大量的来自中国的开发者和优秀的案例,才能保证OpenStack社区持久的活力。


开放基础设施上海峰会 | 中国首秀会送出哪些重磅内容呢?


媲美公有云


OpenStack除了适用于私有云,其实目前来说,OpenStack具备了公有云的成熟的能力,在全球范围来说,OpenStack已经成功帮助了70多个数据中心提供了公有云的解决方案,这证明了OpenStack拥有不输于商业产品的稳定性和高可用性。


开放基础设施上海峰会 | 中国首秀会送出哪些重磅内容呢?


欧洲核子研究组织CERN


CERN很早就将IT的基础设施架构采用了OpenStack进行管理,目前云平台的规模已经上升到291.4k个物理CPU核。


开放基础设施上海峰会 | 中国首秀会送出哪些重磅内容呢?


国内三大运营商同台分享


本次峰会最大的特点是中国的三大运营商中国电信、中国移动、中国联通同台介绍OpenStack给运营商带来了哪些好处,主要是针对OpenStack开放架构和强大的社区开发能力,并且可以增加IT资源的利用效率,特别是近两年,面对5G、边缘计算旺盛的需求,三大运营商都在研究StarlingX边缘计算项目,并且也在展开一些试点。


开放基础设施上海峰会 | 中国首秀会送出哪些重磅内容呢?


三大顶级项目最新动态


Airship是一组用于自动化云配置和管理的开源工具。Airship提供了一个声明性框架,用于定义和管理开放式基础架构工具和底层硬件的生命周期。这些工具包括用于虚拟机的OpenStack,用于容器编排的Kubernetes和用于裸机的MaaS,并计划支持OpenStack Ironic,即Airship是一种管理工具,可以用于管理数据中心中目前繁杂的裸机、IaaS、PaaS平台。


开放基础设施上海峰会 | 中国首秀会送出哪些重磅内容呢?


kata containers是由OpenStack基金会管理,但独立于OpenStack项目之外的容器项目。它是一个可以使用容器镜像以超轻量级虚机的形式创建容器的运行时工具。百度利用Kata管理了大量的容器来对外提供服务,并为百度节省了大量的IT资源。


开放基础设施上海峰会 | 中国首秀会送出哪些重磅内容呢?


StarlingX 2.0通过实现集成OpenStack和Kubernetes强化平台的交付,为混合工作负载提供灵活性、稳健性以及相关支持,进而利用构建块来构建开源基础设施。


九州云黄舒泉作为技术委员会成员介绍了“StarlingX项目旨在为边缘计算重新配置经过验证的云技术,在大规模分布式计算环境中提供成熟且稳健的云平台。StarlingX是适用于裸机、虚拟机和容器化部署环境的完整边缘云基础设施平台,适用于对高可用性(HA)、服务质量(QoS)、性能和低延迟等有严格要求的应用场景。


开放基础设施上海峰会 | 中国首秀会送出哪些重磅内容呢?



END

九州云成立于2012年,是中国早期从事开放基础架构服务的专业公司。成立七年,秉承“开源 · 赋能变革”的理念,不断夯实自身实力,先后为政府、金融、运营商、能源、制造业、商业、交通、物流、教育、医疗等各行业的企业级客户提供高质量的开放基础架构服务。目前拥有国家电网、南方电网广东公司、中国人民银行、中国银联、中国移动、中国电信、中国联通、中国资源卫星、eBay、国际陆港集团、中国人寿、万达信息、东风汽车、诺基亚等众多重量级客户,被用户认可为最值得信赖的合作伙伴。


开放基础设施上海峰会 | 中国首秀会送出哪些重磅内容呢?


点击“阅读原文”,了解九州云议题详情!


赋能故事 | 3年匠心“智”造,铸就华金证券上云梦


《赋能故事》编者按:

从云计算到边缘计算,九州云始终相信“开源·赋能变革”。7年时间里,九州云不断突破和超越,用开源技术创造了一个又一个精彩的赋能故事。


2019年10月,九州云《赋能故事》系列正式推出,我们将用一个个经典的客户案例故事,为您展现不一样的九州云产品、不一样的九州云服务。


曾几何时,股票是人们发财和一夜暴富的手段,那时的人们用拷克箱来装实物股票,数目大的股民需要用麻袋装实物股票到交易所办理转让过户手续……


曾几何时,办理交易的人们需要到窗口排队,远远望去像极了一条条“长龙”,场面十分壮观,那时的交易工作需要大量的人力来完成……


曾几何时,中国的证券行业正处于熊市,那时电话委托、网上交易取代了传统的交易方式,券商的IT工程师们“马不停蹄”地奔走于各大城市,调研自己所在券商公司各地营业厅的交易以及系统运行情况,一轮又一轮扩容相应的IT系统……


而今,对于跃然云上的华金证券来说,那样的日子已经一去不复返了。

赋能故事 | 3年匠心“智”造,铸就华金证券上云梦

华金证券股份有限公司(以下简称:“华金证券”)前身是设立于2000年9月的上海久联证券经纪有限责任公司,而后经历引进战投、增资扩股、股份改制等一系列事宜,2016年12月正式更名为华金证券。作为一家拥有全牌照的综合性证券公司,华金证券业务范围涵盖证券承销与保荐、证券资产管理、证券经纪、证券自营、另类投资等诸多领域。


目前,华金证券业务主要依托股票期权、沪港通、期货、私募、债券投资、新三板、投资银行等板块,重点围绕“三大引擎+两大支撑”,即:以固定收益、资产管理、投资银行为主导业务,以经纪(含融资融券)、研究销售为核心支撑业务,立足沪上金融制高点,依托珠海横琴区位、政策优势,欲通过创新与互联网金融的发展方向,走出一条多元化、国际化的道路,然而证券企业的创新之路并不好走。



“互联网+”带来的“焦虑” 用私有云“破局”



2016年前后,“互联网+”概念引发了全民狂欢。所谓“互联网+”就是“互联网+各个传统行业”,但这并不是简单的相加,而是利用信息通信技术以及互联网平台,让互联网与传统行业进行深度融合,创造新的发展生态。证券作为金融业的大龙头,自然也被推向了“互联网+”的风口,众多公司把一部分业务搬到了线上,例如网上开户、网上金融商场等,华金证券也在“互联网+”的浪潮下,不断利用最新技术升级产品和业务,从而提升用户体验。


然而,“互联网+”犹如硬币的正反两面,给用户带来良好体验的同时,对行业的技术架构也提出了新的要求:产品迭代越来越快、交易量峰值无法预测等挑战要求证券企业必须尽快利用IT技术提升自身信息化水平,这时候,云计算无疑是最佳选择。


为什么说云计算是最优解?有数据显示,2016年前后,云计算逐步向以金融行业为代表的传统行业加速渗透,证券领域中应用私有云IaaS的企业逐年增多,加速系统上线、降低成本、提升运维效率是他们建设私有云的主要驱动力。


面对如此形势,华金证券结合自身业务特点,决定在上海小范围采用新型技术加速业务发展的思路下,开展内部私有云建设。在云计算飞速发展的当下,立体式的金融服务平台需要有一个强大的后端支撑平台,对于在金融投资数据服务领域快速发展的华金证券来说更是如此。



私有云建设之路困难重重



当时,华金证券对国内外现有的云平台服务做了细致的测试和对比,涉及经济性、自主可控性、未来发展趋势等多个方面,对比之后最终选择采用OpenStack技术路线来构建私有云。华金证券希望通过逐步上云的策略和开放的技术架构,建设有行业有特色的证券私有云,为集团内部提供一套完整且高效的金融IT服务能力。


私有云平台需要承载多个任务:为IT运维部门提供一整套完整的IT基础设施、基础IT资源管理系统,为IT开发人员和第三方解决方案厂商提供云平台标准接口,为内部业务人员和外部客户提供应用数据服务。整个云平台从架构上要符合云计算未来的建设标准,提供标准的对外接口和可扩展能力。对于华金证券来说,要建设这样一个私有云平台是有一定难度的:


首先是云平台的部署和扩展方面,华金证券将建设互联网金融业务云平台,如何通过该平台为金融行业提供互联网金融业务开展所需的软件服务、基础架构服务;


其次是定制化开发服务方面,如何缩短系统开发周期、实现产品的快速迭代,最大程度地满足市场需求和用户体验;


再次是计费计量方面,如何根据客户的使用量进行按需计费和计量,实现按需的弹性资源供给;


最后是高标准运维支持服务(SLA:99.99%)方面,如何确保各计算节点和控制节点在交易时段内全年累计达到99.99%的可用性。


除了面对上述困难之外,华金证券内部也缺乏专业的技术人员,处理云平台日常运维管理中存在的问题。



基于九州云解决方案打造健壮的私有云平台



为了解决上述难题,华金证券找到了九州云。根据华金证券云平台的建设成本、开放架构以及所面临的难题,九州云为其提供了一套高效的解决方案:从物理层、虚拟化层、管理层、业务层、运维监控层和用户层面,以OpenStack核心组件为基础进行管理,通过分期建设的方式,帮助华金证券逐步构建私有云平台。


第一阶段采用 OpenStack 成熟的模块,把计算虚拟化、存储虚拟化进行统一管理,并结合开源的监控工具完成对整个私有云业务系统的监控。整个云平台从资源上通过OpenStack管理平台整合了原有的计算、存储、网络的管理,为华金证券的业务提供了标准的IaaS的API服务。通过九州云的Animbus服务门户,让管理员可以通过统一门户为企业IT管理人员提供自助服务。整个私有云平台在构建初期就考虑到平台的稳定性,云控制部分采用多节点、高可用的方式,整体解决方案遵循以下设计原则:


计算资源池资源池架构标准化与充分整合以降低运维成本,提高资源池的运行保障效率,通过资源池的设计实现计算资源弹性化,缩短服务部署时间以提升业务竞争能力。从安全可靠、适应性、可扩展性、实用性、先进性、高效性、标准化、易管理的角度出发,通过业界领先的方法论和对金融行业应用业务的理解,并参照金融业界最佳实践经验来规划计算资源池。


存储资源池根据金融业务的特点,存储资源池的设计需要从数据安全性、性能以及可扩展性进行设计,遵循架构灵活性、易管理、资源调配统一性和便捷性、数据保护性、存储层次化,多样性等原则。存储资源池的设计需要纳管传统商业存储(例如:SAN、NAS),同时需要在扩展性方面对软件定义、分布式存储作为业务的扩展,实现多种存储的统一设计和统一管理。


网络资源池采用“先分层,后分区”的设计思路,根据不同业务功能区域的隔离需求,整个网络系统按照整体业务流向划分为外联接入层、网络交换层、核心网络层、存储区域层。同时,为了更好的支持云平台的运行管理,将网络分为服务、业务、管理3个网络平面,通过层与平面结合形成7个区域,各业务区域之间实现网络逻辑隔离,有利于系统的拓展,也便于日后的运维管理,同时也为业务的拓展奠定基础,只需增加相应功能区域的设备就可以满足新业务的网络通讯需求。


另外,证券企业有大量的业务系统需要和硬件的USB-KEY进行通讯,在本方案中,需要把原有的USB-KEY的业务系统逐步迁移到整个私有云平台上。考虑到今后对USB-KEY的统一管理,在私有云平台控制节点上接入应用平台所需要的USB-KEY,通过IP网络挂载给私有云平台的虚拟机,从而提供基于KEY的安全认证。考虑到USB-KEY业务的连续性,在两个控制节点同时具备接入USB-KEY的能力,在必要的情况下,可以切换USB-KEY到备份节点。


在云平台运维方面,通过Zabbix+ELK的方式,从物理设备、基础OpenStack 服务、存储服务等多个维度对整个平台的监控状况做一个合理的评估,并通过Grafana为运维人员提供统一的监控展现平台。


在上述设计原则的指导下,华金证券IaaS基础支撑云平台整体高可用架构的设计如下图所示:


赋能故事 | 3年匠心“智”造,铸就华金证券上云梦

IaaS基础支撑云平台整体高可用架构设计图


如上图,华金证券云平台底层基于计算存储融合的x86服务器以及网络交换设备的部署,通过虚拟化技术整合,基于超融合架构,实现计算资源池、存储资源池和网络资源池构建。超融合技术将x86服务器的本地存储资源汇集成统一的存储资源池,通过网络路径冗余、网络分平面设计、存储多副本、小IO聚合、自动负载均衡等高可用技术实现高可靠的云计算资源池建设;上层通过云资源管理平台建设实现用户管理、运维和运营管理、开发管理、安全管理、日志管理以及计费管理等功能。通过IAAS云平台提供的云主机或容器以支撑上层业务系统相关模块的部署和运行。


云平台计算资源通过虚拟化管理软件实现资源池化,主要用于提供CPU、内存等计算资源以承载业务应用,基于硬件服务器自身的双电源、RAID卡等机制实现设备的高可用性。


云平台存储资源IaaS云架构实现存储和计算资源的融合,即每台x86服务器既是计算节点,又是存储节点,通过分布式存储引擎将每台节点机本地不同访问速率的硬盘融合成全局的存储资源池,用于存放云主机镜像以及业务数据等;通过分布式存储引擎构建的存储资源池具备分布式架构,通过软件定义方式实现分布式集群HA、分布式无状态机头、分布式智能Cache(冷热数据分离)及数据的多副本存取机制。


云平台网络资源每台IaaS管理服务器和计算服务器的万兆和千兆网卡和外置的万兆以及千兆以太网交换机提供云平台的高冗余网络架构。


云平台管理用于对云平台的资源池进行统一的调度和管理,以HA方式部署在管理节点服务器组成的集群上。云管理可对资源池中所有节点上的资源进行统一管理并提供web接口给管理员和用户,以实现访问门户的负载均衡和高可用。



全方位提高经济效益和业务效率



IaaS云平台上线之后,华金证券的研发测试系统、部分交易系统、办公系统逐步迁移到了该平台上。由于最初选择采用九州云提供的云平台解决方案,在过去3年多的时间里,IaaS云平台给华金证券带来了巨大的经济效益,与此同时,公司的业务效率也得到了全面提升:


资源使用率得到大幅度提升以传统开发测试环境为例,服务器CPU使用率通常不足10%(业界平均),而通过云平台虚拟化以及资源共享调配的手段可以将CPU使用率提高到60%以上,同时也提高了空间、能源的使用效率。


应用部署效率得到有效提升在传统开发测试中,大量工作花费在基础设施供应上,而通过云平台自动化实现了自动供应,将原来数周的供应时间降为数分钟,极大提高了应用部署上线时间,减少工作量的同时,缩短了新业务上市周期,从而使得华金证券的业务在竞争中夺得先机。


解放人力,提升了单位人工生产力由于云平台采纳了自动化方式,以机器替代了人工工作,从而提升了部分工作效率。另外,通过自助化方式的申请资源,相当于将许多基础设施工作“众包”给最终用户,不但减少了中间环节,还极大解放了运维人员的生产力,把他们从繁重的重复劳动中解放出来,投入到更加高附加值的工作中去,资源得到了合理配置。


IT管理水平得到大幅度提升云平台通过统一自助门户管理资源,所有管理方法通过流程化手段固化,使得管理理念得以贯彻落实,降低了由于传统IT管理中存在的“灰色地带”而导致的资源浪费。此外,人员知识技能以自动化脚本的方式被重复使用,降低了企业的人力资源成本。由于云平台自带配置管理、告警、报表和仪表盘工具等,这为IT运维和管理辅助决策提供了现成的工具。


提升IT合规水平,降低了风险发生的概率由于云平台采纳了自动化、流程化等辅助手段减少了人工操作,从而降低了由于人工失误带来的潜在风险。有了标准化流程保障,使得人为违规的可能性降低,再次降低了风险发生的概率,从而降低了企业所需承担风险的隐性成本。


如今,云计算已经成为证券机构“技术引领业务”转型中的推动者,华金证券上云的案例为其他证券机构上云提供了有效借鉴。在过去3年多的时间里,九州云在为华金证券提供服务的同时,也见证了其一步一脚印踏入云端的辛路历程。未来,九州云在不断进行技术创新的同时,把以往累积的丰富经验和能力输出给更多行业客户,最大限度地发挥自身价值,为更多行业赋能。



END

九州云成立于2012年,是中国早期从事开放基础架构服务的专业公司。成立七年,秉承“开源 · 赋能变革”的理念,不断夯实自身实力,先后为政府、金融、运营商、能源、制造业、商业、交通、物流、教育、医疗等各行业的企业级客户提供高质量的开放基础架构服务。目前拥有国家电网、南方电网广东公司、中国人民银行、中国银联、中国移动、中国电信、中国联通、中国资源卫星、eBay、国际陆港集团、中国人寿、万达信息、东风汽车、诺基亚等众多重量级客户,被用户认可为最值得信赖的合作伙伴。


赋能故事 | 3年匠心“智”造,铸就华金证券上云梦


点击“阅读原文”,了解九州云更多信息!


2019年9月20日,边缘计算深度交流会StarlingX2.0发布庆功会将在北京举行,Intel、风河、烽火、九州云、联通云、联通研究院、中国移动、中国银联等企业均出席,并带来精彩分享。欢迎扫描二维码进行注册,报名参与本次活动。


边缘计算深度交流会StarlingX2.0发布庆功会



END

九州云成立于2012年,是中国早期从事开放基础架构服务的专业公司。成立七年,秉承“开源 · 赋能变革”的理念,不断夯实自身实力,先后为政府、金融、运营商、能源、制造业、商业、交通、物流、教育、医疗等各行业的企业级客户提供高质量的开放基础架构服务。目前拥有国家电网、南方电网广东公司、中国人民银行、中国银联、中国移动、中国电信、中国联通、中国资源卫星、eBay、国际陆港集团、中国人寿、万达信息、东风汽车、诺基亚等众多重量级客户,被用户认可为最值得信赖的合作伙伴。


边缘计算深度交流会StarlingX2.0发布庆功会


点击“阅读原文”,了解StarlingX 2.0版本!



StarlingX社区发布2.0版本!


StarlingX,一个专注于对低延迟和高性能应用进行优化的开源边缘计算及物联网云平台,今天正式发布其2.0版本。2018年发布的StarlingX 1.0在专用物理服务器上提供了强化的OpenStack平台,StarlingX 2.0通过实现集成OpenStack和Kubernetes强化平台的交付,为混合工作负载提供灵活性、稳健性以及相关支持,进而利用构建块来构建开源基础设施。


点击文末“阅读原文”,

或登陆官网 git.starlingx.io/starlingx

可下载StarlingX 2.0


StarlingX项目旨在为边缘计算重新配置经过验证的云技术,在大规模分布式计算环境中提供成熟且稳健的云平台。StarlingX是适用于裸机、虚拟机和容器化部署环境的完整边缘云基础设施平台,适用于对高可用性(HA)、服务质量(QoS)、性能和低延迟等有严格要求的应用场景。


StarlingX通过利用Ceph, Linux, KVM, OpenStack和Kubernetes等其他开源项目的组件,并通过添加配置和故障管理等服务对这些组件加以完善,可同时满足运营商和行业应用对边缘计算的严格要求。应用案例包括基于交通运输的物联网应用,工业自动化,5G,智能建筑与智慧城市,自动驾驶,定位零售业,虚拟化无线接入网络(vRAN),增强现实和虚拟现实,高清媒体内容分发,监测,医疗成像、诊断和监测,以及通用型客户终端设备(uCPE)等。


  StarlingX 2.0的主要特性  

●       在专用物理服务器上集成Kubernetes和OpenStack的强化云原生平台

●       基于Stein版本的容器化OpenStack

●       容器化工作负载的边缘应用场景基于Kubernetes


StarlingX与OpenStack的代码库密切相关,随着新版StarlingX的推出,Out-of-tree补丁持续减少,并计划在今年秋季即将发布的Train版本中将其完全消除。


StarlingX社区正不断成长,今天发布的新版本包含来自132位贡献者的2365次代码提交,其中包括来自九州云、中国银联、烽火、英特尔、InerDynamix、红帽、SUSE和风河等企业的开发者。诚挚邀请业内用户、运营者和开发者们试用新版软件,并加入StarlingX社区的IRC(Freenode上的#starlingx)和邮件列表(lists.starlingx.io),进行及时的社区交流与反馈。


了解StarlingX社区在开源基础设施上海峰会的活动日程

StarlingX社区成员将齐聚11月4-6日在上海举行的开源基础设施峰会,

  相关峰会议题如下  

●       一种可协助进行目标识别的边缘框架(Joy Liu, Ruoyu Ying, Shane Wang)

●       中国联通采用边缘编排系统在5G环境中管理StarlingX、K8S及OpenStack边缘数据中心(Dan Chen, Li Kai, Wei Hu)

●       扩展:边缘计算工作组更新(Beth Cohen, David Paterson, Gergely Csatari, Ildiko Vancsa, Shuquan Huang)

●       中国电信运营商眼中的边缘计算(Dan Chen, Shuquan Huang, Qihui Zhao, Wei Hu, Yongbing Fan)

●       如何实现电信运营商多异构边缘云的协同与管理(Shuquan Huang, Tao Jiang, Qihui Zhao)

●       StarlingX:边缘硬件加速驱动的网络策略(Chenjie Xu, Yingnan Chen)

●       非接触式支付系统的安全边缘基础设施(Haitao Wang, Lijun Zu, Yih Leong Sun)

●       可支持Kubernetes和/或OpenStack边缘云的StarlingX混合分布式云平台(Brent Rowsell, Greg Waines)

访问以下链接,详细了解StarlingX社区在开源基础设施上海峰会的活动日程:

https://www.starlingx.io/blog/starlingx-shanghai-schedule-blog.html


业内评价

九州云 – 黄舒泉, 解决方案架构总监:

“5G正成为现实,很开心看到StarlingX 2.0的发布,现在正是采用StarlingX构建边缘云基础设施平台实现5G低延迟和高性能应用的好时机。九州云将持续为StarlingX社区做贡献,助力5G部署。”


英特尔 – Mark Skarpness, 数据中心系统栈工程总监,英特尔架构、图形及软件部副总裁:

“StarlingX社区自成立以来已在短时间内取得了显著进展,在将项目代码库与OpenStack Stein进行融合的同时,还添加了新的功能。StarlingX 2.0将云原生服务带到边缘计算,不仅消除了技术债,还为边缘计算的持续创新创建了一个高效能的平台。”


OpenStack基金会 – Iidiko Vancsa,生态技术主管:

“运行和管理混合工作负载对边缘环境至关重要。新的StarlingX平台是一个很好的应用实例,OpenStack服务在容器化平台中应用的同时,还可提供统一的接口来管理最适合您的边缘应用程序的工作负载类型。”


风河 – Glenn Seiler,开源战略副总裁:

“这是StarlingX项目的一个关键里程碑,在那些对基础设施有严格要求的行业看来,边缘云技术向前迈出了重要一步。StarlingX现在可为有低延迟需求的分布式边缘云用例交付容器和基于VM的工作负载。风河致力于与社区合作,进一步推动边缘云技术的发展。”


关于StarlingX

StarlingX是一个专注于对低延迟和高性能应用进行优化的开源边缘计算和物联网云平台,提供可伸缩的、高度可靠的边缘基础设施,已经过测试,可作为完整的软件栈使用。其应用范围包括工业物联网、电信、视频传输以及其他有超低延迟要求的应用领域。StarlingX可兼容不同的开源组件,可为故障管理和服务管理提供独特项目组件,以确保用户应用程序的高可用性。StarlingX代码库蓄势待发,随时准备部署边缘计算可扩展解决方案。

该项目由OpenStack基金会托管,更多StarlingX详情请访问www.starlingx.io


Nova Conductor


Conductor 服务作为 Nova 核心部件之一最初在 Grizzly 版本中发布,在整个 Nova 中充当着组织者的角色。主要提供了 3 个功能:


  • nova-conductor 连接了 nova-api、nova-compute 和 nova-scheduler 服务,提供了 长时任务编排(Task Orchestration)功能。Nova 将所有耗时长,跨节点,易出错但相对固定的处理流程抽象成 Task,包括启动虚拟机、冷迁移和热迁移等。Conductor 作为 Task 的组织者,在执行 Task 的时候 Conductor 会一直追踪它的状态,并且能够执行错误处理、恢复等一系列工作。


  • nova-conductor 为 nova-computee 提供了 数据库的代理访问机制。因为计算节点是 OpenStack 云环境中与用户业务接触最近、数据最多、最容易被攻击的目标,所以 nova-compute 被设计成无法直接访问数据库,以此来保障数据库的安全。


  • nova-conductor 为版本较旧的 nova-compute 提供了 数据库版本向下兼容性。OpenStack 作为一个分布式系统,不同的服务可能运行在不同的代码版本上,在这些模块通信的过程中,Conductor 为传输的数据对象提供了版本兼容功能。让处于不同版本的 Nova 服务能够识别 RPC 请求中数据对象的版本,并完成不兼容的对象转换。但需要注意的是,这种兼容性是向下的。


Conductor 的代码包目录结构


  1. [root@localhost nova]# tree conductor/

  2. conductor/

  3. ├── api.py

  4. ├── __init__.py

  5. ├── manager.py

  6. ├── rpcapi.py

  7. └── tasks

  8. ├── base.py

  9. ├── __init__.py

  10. ├── live_migrate.py

  11. └── migrate.py


其中,在 manager 模块中主要实现了 ComputeTaskManager 任务编排封装类和 ConductorManager 数据库访问代理封装类。


数据库访问代理机制


Conductor 实现的数据库访问代理机制带来的好处:


  • 为 nova-compute 服务的数据库访问提供了一层额外的安全保障。


  • 在保证 Conductor API 兼容性的前提下,数据库 schema 升级的同时不需要升级 nova-compute 的代码版本。


  • nova-compute 可以通过创建多个协程来使用非阻塞的 nova-conductor RPC 调用。


需要注意的是,nova-conductor 作为代理服务成为了 nova-compute 访问数据库速度的瓶颈,好在由于 Conductor 服务是无状态服务,所以在性能和稳定性要求较高的环境中可以任意横向扩展 Conductor 节点的数量。


Versioned Object Model 机制


Versioned Object Model(版本化对象模型)机制在 Icehouse 版本被引入。Object Model 将每一张数据库表都与一个 Object 对应,将对数据库表的操作都封装到 Object 实例中,需要通过 Object 实例来进行数据库的操作。这听起来了 ORM 很相似,但实际上 Object Model 是比 ORM 更上一层的封装。ORM 只是单纯将数据库表结构映射成为了一个 Python 对象,但 Object Model 是在此之上做了更多的数据库操作实践和优化,Object Model 使用面向对象的思想对数据进行了封装,并为封装的数据提供了数据库代理、RPC 向下版本兼容、流量优化等一些列高级特性。


  • Nova 数据库访问方式与对象构建过程解耦:Object Model 支持 remote 和 local 两种数据库访问方式,并非成功构建了 Object 就可以直接操作数据库,在 nova-compute 中通一个 Object 来执行数据库操作实际上是远程的,是一种间接的数据库访问。这是实现数据库访问代理功能的关键。


  • nova-compute 和数据库的在线升级:nova-compute 通过 RPC 传递 Object 到 nova-conductor 时,Object 会维护一个版本号。假设 nova-compute 传递的是一个低版本的 Object,那么 nova-conductor 就会对该 Object 进行版本兼容处理,使得低版本的 Object 也能如常对高版本 DB schema 进行操作。


  • 对象属性类型的声明:Python 是一门动态的强类型解释语言,Python 不具有对象类型声明语句,这是 Python 轻便简单的根本,也是 Python 难以支撑开发超大型项目的病因。在 Web API 层面,我们可以通过 validation.schema 和 view_builder 来严格规范输入、输出的数据结构。而在后端程序的内部实现,我们则可以通过 Object Model 来实现对 Object 每个属性字段的类型声明,这帮助我们编写出来的程序具有更好的可读性和稳定性。


  • 减少写入数据库的数据量:Object Model 支持增量更新数据库记录属性值,而无需将整个对象的所有属性都更新一遍,每个 Object 都具有一个 _change_field 实例属性用来记录变化的值。


  1. def remotable(fn):

  2. """Decorator for remotable object methods."""

  3. @six.wraps(fn)

  4. def wrapper(self, *args, **kwargs):

  5. ctxt = self._context

  6. if ctxt is None:

  7. raise exception.OrphanedObjectError(method=fn.__name__,

  8. objtype=self.obj_name())

  9. if self.indirection_api:

  10. # indirection_api: 间接数据库访问 API,就是 conductor_rpcapi.ConductorAPI()

  11. # object_action: remotable 装饰器中调用,Versioned Object 实例通过这个方法来远程访问数据库

  12. # 相对的,object_class_action_versions: remotable_classmethod 装饰器中调用,Versioned Object 类通过这个方法来远程访问数据库

  13. updates, result = self.indirection_api.object_action(

  14. ctxt, self, fn.__name__, args, kwargs)

  15. for key, value in six.iteritems(updates):

  16. if key in self.fields:

  17. field = self.fields[key]

  18. # NOTE(ndipanov): Since VersionedObjectSerializer will have

  19. # deserialized any object fields into objects already,

  20. # we do not try to deserialize them again here.

  21. if isinstance(value, VersionedObject):

  22. setattr(self, key, value)

  23. else:

  24. setattr(self, key,

  25. field.from_primitive(self, key, value))

  26. # obj_reset_changes 重新设置 change 数据

  27. # 相对的,obj_get_changes 获取 change 数据

  28. self.obj_reset_changes()

  29. # _changed_fields 存放增量更新的数据

  30. self._changed_fields = set(updates.get('obj_what_changed', []))

  31. return result

  32. else:

  33. return fn(self, *args, **kwargs)


  34. wrapper.remotable = True

  35. wrapper.original_fn = fn

  36. return wrapper


END

九州云成立于2012年,是中国早期从事开放基础架构服务的专业公司。成立七年,秉承“开源 · 赋能变革”的理念,不断夯实自身实力,先后为政府、金融、运营商、能源、制造业、商业、交通、物流、教育、医疗等各行业的企业级客户提供高质量的开放基础架构服务。目前拥有国家电网、南方电网广东公司、中国人民银行、中国银联、中国移动、中国电信、中国联通、中国资源卫星、eBay、国际陆港集团、中国人寿、万达信息、东风汽车、诺基亚等众多重量级客户,被用户认可为最值得信赖的合作伙伴。


技术周 | Nova Conductor Versioned Object Model 机制


点击“阅读原文”,了解九州云更多信息!

虚拟存储器系统


在早期的计算机系统中,程序员会直接对主存储器的物理地址进行操作,这种编程方式导致了当程序出现寻址错误时有可能会导致整个系统崩溃,当一个进程出现寻址错误时也可能会导致另一个进程崩溃。显然,直接操作主存的物理地址不是一个好的方法。而且,由于不存在分页或分段的存储空间管理手段,所以 CPU 寻址宽度就成为了存储容量的限制,例如:32 位 CPU 只支持 4GB 内存的寻址。这导致了该计算机无法运行存储空间需求大于实际内存容量的应用程序。


为了解决这些问题,现代计算机系统通过操作系统和硬件的结合,把主存储器和辅存储器从逻辑上统一成了一个整体,这就是虚拟存储器,或称为虚拟存储系统。虚拟存储器是硬件异常、硬件地址翻译、主存、磁盘文件和内核软件的完美交互,它为每个进程提供了一个大的、一致的和私有的地址空间。


虚拟存储器的两大特点:


  • 允许用户程序使用比实际主存空间大得多的空间来访问主存

  • 每次访存都要进行虚实地址转换。


理地址,即物理主存的地址空间主存被组织成一个由 M 个连续的、字节大小的单元组成的数组,每字节都有一个唯一的物理地址(Physical Address,PA)。第一个字节的地址为 0,接下来的字节的地址为 1,依此类推。给定这种简单的结构,CPU 访问存储器的最自然的方式就是使用物理地址,即物理寻址。


虚拟地址,即虚拟存储地址空间,它能够让应用程序误以为自己拥有一块连续可用的 “物理” 地址,但实际上从程序视角所见的都是虚拟地址,而且这些虚拟地址对应的物理主存空间通常可能是碎片的,甚至有部分数据还可能会被暂时储存在外部磁盘设备上,在需要时才进行数据交换。


虚拟存储器的核心思路是根据程序运行时的局部性原理,一个程序运行时,在一小段时间内,只会用到程序和数据的很小一部分,仅把这部分程序和数据装入主存即可,更多的部分可以在需要用到时随时从辅存调入主存。在操作系统和相应硬件的支持下,数据在辅存和主存之间按程序运行的需要自动成批量地完成交换。


页式虚拟存储器


在页式虚拟存储器中,通过将虚拟存储空间分割成为了大小固定的虚拟页(Vitual Page,VP),简称虚页,每个虚拟页的大小为 P=2^n 字节。类似地,物理存储空间被分割为物理页(Physical Page,PP)也称为页帧(Page Frame),简称实页,大小也为 P 字节。


同任何缓存设计一样,虚拟存储器系统必须有某种方法来判定一个虚拟页是否存放在物理主存的某个地方。如果存在,系统还必须确定这个虚拟页存放在哪个物理页中。如果物理主存不命中,系统必须判断这个虚拟页存放在磁盘的哪个位置中,并在物理主存中选择一个牺牲页,然后将目标虚拟页从磁盘拷贝到物理主存中,替换掉牺牲页。这些功能是由许多软硬件联合提供,包括操作系统软件,MMU(存储器管理单元)地址翻译硬件和一个存放在物理主存中的叫做页表(Page Table)的数据结构,页表将虚拟页映射到物理页。页表的本质就是一个页表条目(Page Table Entry,PTE)数组。


CPU 通过虚拟地址(Virtual Address,VA)来访问存储空间,这个虚拟地址在被送到存储器之前需要先转换成适当的物理地址。将一个虚拟地址转换为物理地址的任务叫做地址翻译(Address Translation)。就像异常处理一样,地址翻译需要 CPU 硬件和操作系统之间的紧密合作。比如:Linux 操作系统的交换空间(Swap Space)。如果当 CPU 寻址时发现虚拟地址找不到对应的物理地址,那么就会触发一个异常并挂起寻址错误的进程。在这个过程中,对其他进程没有任何影响。


虚拟地址与物理地址之间的转换主要有 CPU 芯片上内嵌的存储器管理单元(Memory Management Unit,MMU)完成,它是一个专用的硬件,利用存放在主存中的查询表(地址映射表)来动态翻译虚拟地址,该表的内容由操作系统管理。


当页表已经存放在主存中,那么当 CPU 访问(虚拟)存储器时,首先要查询页面得到物理主存地址之后再访问主存完成存取。显然,地址转换机制让 CPU 多了一次访问主存的操作,相当于访问速度下降一半。而且当发生页面失效时,还要进行主存-辅助的页面交换,那么 CPU 访问主存的次数就更多了。为了解决这个问题,在一些影响访问速度的关键地方引入了硬件的支持。例如:采用按内容查找的相联存储器并行查找。此外,还进一步提出了 “快表” 的概念。把页表中最活跃的部分存放在快速存储器中组成快表,是减少 CPU 访问时间开销的一种方法。


快表由硬件(门电路和触发器)组成,属于 MMU 的部件之一,通常称为转换旁路缓冲器(Translation lookaside buffer,TLB)。TLB 的本质也是一个 Cache,它比页表小得多,一般在 16 个条目 ~ 128 个条目之间,快表只是页表的一个小小的副本。查表时,带着虚页好同时差快表和慢表(原页面),当在快表中找打条目时,则马上返回主存物理地址到主存地址寄存器,并使慢表查询作废。此时,虽然使用了虚拟存储器但实际上 CPU 访问主存的速度几乎没有下降(CPU 不再需要多次访问主存)。如果快表不命中,则需要花费一个访主存时间查慢表,然后再返回主存物理地址到主存地址寄存器,并将此条目送入到快表中,替换到快表的某一行条目。


大页内存


在页式虚拟存储器中,会在虚拟存储空间和物理主存空间都分割为一个个固定大小的页,为线程分配内存是也是以页为单位。比如:页的大小为 4K,那么 4GB 存储空间就需要 4GB/4KB=1M 条记录,即有 100 多万个 4KB 的页。我们可以相待,如果页太小了,那么就会产生大量的页表条目,降低了查询速度的同时还浪费了存放页面的主存空间;但如果页太大了,又会容易造成浪费,原因就跟段式存储管理方式一般。所以 Linux 操作系统默认的页大小就是 4KB,可以通过指令查看:


  1. $ getconf PAGE_SIZE

  2. 4096


但在某些对性能要求非常苛刻的场景中,页面会被设置得非常的大,比如:1GB、甚至几十 GB,这些页被称之为 “大页”(Huge Page)。大页能够提升性能的主要原因有以下几点:


  • 减少页表条目,加快检索速度。


  • 提升 TLB 快表的命中率,TLB 一般拥有 16 ~ 128 个条目之间,也就是说当大页为 1GB 的时候,TLB 能够对应 16GB ~ 128GB 之间的存储空间。


值得注意的是,首先使用大页的同时一般会禁止主存-辅存页面交换,原因跟段式存储管理方式一样,大容量交换会让辅存读写成为 CPU 处理的瓶颈。再一个就是大页也会使得页内地址检索的速度变慢,所以并非是页面的容量越大越好,而是需要对应用程序进行大量的测试取得页面容量与性能的曲线峰值才对。


启用 HugePage 的优点


  • 无需交换,不存在页面由于内存空间不足而换入换出的问题。

  • 减轻 TLB Cache 的压力,也就是降低了 CPU Cache 可缓存的地址映射压力。

  • 降低 Page Table 的负载。

  • 消除 Page Table 地查找负载。

  • 提高内存的整体性能。


Linux 服务器的大页内存设置


在 Linux 中,物理内存是以页为单位来管理的。页的大小为 4096 字节。1MB 的内存能划分为 256 页;1GB 则等同于 256000 页。CPU 中有一个内置的内存管理单元(MMU),用于存储这些页的列表(页表),每页都有一个对应的入口地址。在这种情况下,内存管理单元的大小(注:实际上是页表的大小)决定了服务器能使用的最大内存大小。


如果为服务器分配的内存远大于现有内存管理单元能管理的量,则会造成内存的浪费。CentOS 6 中为解决这个问题,使用了大页面的方式。简单来说,大页面即大小为 2MB 或者 1GB 的页。2MB 的页适用于管理 GB 级单位的内存;1GB 的页适用于 TB 级单位的内存。


手动去管理大页面较麻烦,往往需要更改代码。为了便于系统管理员和开发人员使用, CentOS 引入了 transparent huge pages (简称 THP )的概念。THP 是一个抽象层,其自动化了创建,管理和使用大页面的大多数步骤。


大页面配置需要连续的内存空间,因此在开机时就分配是最可靠的设置方式。配置大页面的参数有:


  • hugepages :在内核中定义了开机启动时就分配的永久大页面的数量。默认为 0,即不分配。只有当系统有足够的连续可用页时,分配才会成功。由该参数保留的页不能用于其他用途。


  • hugepagesz:在内核中定义了开机启动时分配的大页面的大小。可选值为 2MB 和 1GB 。默认是 2MB 。


  • default_hugepagesz:在内核中定义了开机启动时分配的大页面的默认大小。


要调整页的尺寸,必须将配置以参数格式写入到 Linux 操作系统启动命令中。如要为系统配置 10 个 1GB 的大页面,则启动命令中要包含:default_hugepagesz=1Ghugepagesz=1Ghugepages=10。配置 1GB 的大页面,CPU 特性需要支持 pdpe1gb ,系统内核也需要支持。e.g.


  1. grub


  2. GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX default_hugepagesz=1G hugepagesz=1G hugepages=100"


查看大页的相关配置:


  1. $ sysctl -a | grep -I huge


  2. $ cat /proc/meminfo | grep -i Huge


配置大页面后,系统在开机启动时会首选尝试在内存中找到并预留连续的大小为 hugepages *hugepagesz的内存空间。如果内存空间不满足,则启动会报错 KernelPanic,Outof Memory 等错误。


使用大页面后,能减少系统管理和访问页的时间(扩大了 TLB 快页表查询的内存地址范围);内核中的 swap 守护进程也不会管理大页面占用的这部分空间。合理设置大页面能减少内存操作的负担,减少访问页表造成性能瓶颈的可能性,从而提升系统性能。


如只配置了一个大小的大页面,可以通过 /proc/meminfo 中的 HugepagesizeHugePages_Total 计算出大页面所在内存空间的大小。这部分空间会被算到已用的内存空间里,即使还未真正被使用。因此,用户可能观察到下面现象:使用 free 命令查看已用内存很大,但 top 或者 ps 中看到 %mem 的使用总量加起来却很少。


注意:一般情况下,配置的大页面可能主要供特定的应用程序或服务使用,其他进程是无法共享这部分空间的(如 Oracle SGA )。请根据系统物理内存和应用需求来设置合适的大小,避免大页面使用的浪费;以及造成其他进程因竞争剩余可用内存而出现内存溢出的错误,进而导致系统崩溃的现象。


Nova 虚拟机的大页内存设置


绝大多数现代 CPU 都支持多种内存页尺寸,从 4KB 到 2M/4M,最大可以达到 1GB。所有 CPU 都默认使用最小的 4KB 页,如果具有较大的内存可以选择启用大页内存进行分配,这将会明显减少 CPU 的页表项,因此会增加 TLB 页表缓存的命中率,降低内存访问延迟。如果操作系统使用默认的小页内存,随着运行时间,系统会出现越来越多的碎片,以至于后来难以申请到大页的内存。在大页内存大小越大时,该问题越严重。因此,如果当你有使用大页内存的需求时,最好的办法是在系统启动时就预留好内存空间。当前的 Linux 内核不允许针对特定的 NUMA 节点进行这样的设定,不过,在不久的将来这个限制将被取消。更进一步的限制是,由于 MMIO 空洞的存在,内存开始的 1GB 不能使用 1GB 的大页。


Linux 内核已经支持 THP(Transparent Huge Pages,透明巨型页)特性,该特性会尝试为应用程序预分配大页内存。依赖该特性的一个问题是,虚拟机的拥有者并不能保证给虚拟机使用的是大页内存还是小页内存。


内存块是直接指定给特定的 NUMA 单元的,这就意味着大页内存也是直接指定在 NUMA 单元上的。因此在 NUMA 单元上分配虚拟机时,计算服务需要考虑在 NUMA 单元或者主机上可能会用到的大页内存。为虚拟机内存启用大页内存时,可以不用考虑虚拟机操作系统是否会使用。


Linux 内核有一项特性,叫做内核共享存储(KSM),该特性使得不同的 CPU 可以共享相同内容的内存页。内核会主动扫描内存,合并内容相同的内存页。如果有 CPU 改变这个共享的内存页时,会采用写时复制(COW)的方式写入新的内存页。当一台主机上的多台虚拟机使用相同操作系统或者虚拟机使用很多相同内容内存页时,KSM 可以显著提高内存的利用率。因为内存扫描的消耗,使用 KSM 的代价是增加了 CPU 的负载,并且如果虚拟机突然做写操作时,会引发大量共享的页面,此时会存在潜在的内存压力峰值。虚拟化管理层必须因此积极地监控内存压力情况并做好现有虚拟机迁移到其他主机的准备,如果内存压力超过一定的水平限制,将会引发大量不可预知的 Swap 操作,甚至引发 OOM。所以在性能要求严格的场景中,我们建议关闭内存共享特性。


计算节点可以配置 CPU 与内存的超配比例,但是一旦使用了大页内存,内存便不能再进行超配。因为当使用大页内存时,虚拟机内存页必须与主机内存页一一映射,并且主机操作系统能通过 Swap 分区分配大页内存,这也排除了内存超配的可能。大页内存的使用,意味着需要支持内存作为专用资源的虚拟机类型。


尽管设置专用资源时,不会超配内存与 CPU,但是 CPU 与内存的资源仍然需要主机操作系统提前预留。如果使用大页内存,必须在主机操作系统中明确预留。对于 CPU 则有一些灵活性。因为尽管使用专用资源绑定 CPU,主机操作系统依然会使用这些 CPU 的一些时间。不管怎么样,最好可以预留一定的物理 CPU 专门为主机操作系统服务,以避免操作系统过多占用虚拟机 CPU,而造成对虚拟机性能的影响。Nova可以保留一部分 CPU 专门为操作系统服务,这部分功能将会在后续的设计中加强。


允许内存超配时,超出主机内存的部分将会使用到 Swap。ZSWAP 特性允许压缩内存页被写入 Swap 设备,这样可以大量减少 Swap 设备的 I/O 执行,减少了交换主机内存页面中固有的性能下降。Swap 会影响主机整体 I/O 性能,所以尽量不要把需要专用内存的虚拟机机与允许内存超配的虚拟机放在同一台物理主机上。如果专用 CPU 的虚拟机与允许超配的虚拟机竞争 CPU,由于 Cache 的影响,将会严重影响专用 CPU 的虚拟机的性能,特别在同一个 NUMA 单元上时。因此,最好将使用专用 CPU 的虚拟机与允许超配的虚拟机放在不同的主机上,其次是不同的 NUMA 单元上。


关于虚拟机在主机上的 CPU 与内存的布局决策,也会影响其他的主机资源分配。例如,PCI 设备与 NUMA 单元关系密切,PCI 设备的 DMA 操作使用的内存最好在本地 NUMA 单元上。因此,在哪个 NUMA 单元上分配虚拟机,将会影响到 PCI 设备的分配。


Nova 内存页设置


  1. openstack flavor set FLAVOR-NAME

  2. --property hw:mem_page_size=PAGE_SIZE


PAGE_SIZE


  • small (default):使用最小的 page size,e.g. x86 平台的 4KB。

  • large:只使用最大的 page size,e.g. x86 平台的 2MB 或 1GB。

  • any:取决于 Hypervisor 类型。如果是 Libvirt 的话,会根据服务器的大页内存设置进行决策,优先使用大的大页,依次递减。

  • pagesize:指定具体的 pape size,e.g. 4KB、2MB、2048、1GB。


e.g.

  1. openstack flavor create --vcpus 2 --ram 2048 --disk 40

  2. --property hw:mem_page_size=2MB Flavor1


  3. openstack flavor create --vcpus 2 --ram 2048 --disk 40

  4. --property hw:mem_page_size=1GB Flavor2


NOTELarge pages can be enabled for guest RAM without any regard to whether the guest OS will use them or not. If the guest OS chooses not to use huge pages, it will merely see small pages as before. Conversely, if a guest OS does intend to use huge pages, it is very important that the guest RAM be backed by huge pages. Otherwise, the guest OS will not be getting the performance benefit it is expecting.


手动为 KVM 虚拟机中设置大页内存(http://www.linux-kvm.org/page/UsingLargePages):


  1. # 2G 内存设置 256

  2. # 4G 内存设置 512

  3. # 8G 内存设置 1024


  4. echo 1024 > /proc/sys/vm/nr_hugepages


END

九州云成立于2012年,是中国早期从事开放基础架构服务的专业公司。成立七年,秉承“开源 · 赋能变革”的理念,不断夯实自身实力,先后为政府、金融、运营商、能源、制造业、商业、交通、物流、教育、医疗等各行业的企业级客户提供高质量的开放基础架构服务。目前拥有国家电网、南方电网广东公司、中国人民银行、中国银联、中国移动、中国电信、中国联通、中国资源卫星、eBay、国际陆港集团、中国人寿、万达信息、东风汽车、诺基亚等众多重量级客户,被用户认可为最值得信赖的合作伙伴。


技术周 | OpenStack 高性能虚拟机之大页内存


点击“阅读原文”,了解九州云更多信息!

概览


技术周 | Kuryr对接之Baremetal containers networking


packstack安装openstack


准备


控制节点与计算节点同时运行。

关闭防火墙

1.  systemctl stop firewalld  

2.  systemctl disable firewalld  

 

关闭SELinux

1.  sed -i ‘s#SELINUX=enforcing#SELINUX=disabled#g’ /etc/selinux/config  

2.  setenforce 0  

 

修改yum源

1.  yum -y install wget  

2.  wget http://mirrors.aliyun.com/repo/Centos-7.repo  

3.  yum update  

 

下载安装包


控制节点与计算节点同时运行。

1.  yum install -y centos-release-openstack-rocky  

2.  yum install -y openstack-packstack  

 

控制节点生成并修改answer文件


控制节点运行下述命令生成answer file。

1.  packstack –gen-answer-file answer.txt  

修改生成的answer.txt,根据实际控制节点与计算节点的IP,修改下述信息。

1.  #关闭非必须组件减少安装时间  

2.  CONFIG_CINDER_INSTALL=n  

3.  CONFIG_MANILA_INSTALL=n  

4.  CONFIG_SWIFT_INSTALL=n  

5.  CONFIG_AODH_INSTALL=n  

6.  CONFIG_CONTROLLER_HOST=<控制、网络节点IP>  

7.  CONFIG_COMPUTE_HOSTS=<计算节点IP>  

8.  CONFIG_NETWORK_HOSTS=<控制、网络节点IP>  

9.  #启用LB  

10.CONFIG_LBAAS_INSTALL=y  

11.CONFIG_NEUTRON_METERING_AGENT_INSTALL=n  

12.CONFIG_NEUTRON_ML2_TYPE_DRIVERS=vxlan,flat  

13.CONFIG_NEUTRON_ML2_TENANT_NETWORK_TYPES=vxlan  

14.#将默认的OVN backend切换为ovs  

15.CONFIG_NEUTRON_ML2_MECHANISM_DRIVERS=openvswitch  

16.CONFIG_NEUTRON_L2_AGENT=openvswitch  

 

控制节点运行安装


1.  packstack –answer-file answer.txt  


准备openstack中K8S所需项目、用户及网络信


创建K8S所需资源可以在dashboard中进行,也可以直接通过命令行操作。


创建K8S专用的项目,用户信息

1.  openstack project create k8s  

2.  openstack user create –password 99cloud k8s-user  

3.  openstack role add –project k8s –user k8s-user admin  


在K8S项目下创建pod 网络子网及service 网络子网

1.  openstack network create pod_network  

2.  openstack network create service_network  

3.  openstack subnet create –ip-version 4 –subnet-range 10.1.0.0/16 –network pod_network pod_subnet  

4.  openstack subnet create –ip-version 4 –subnet-range 10.2.0.0/16 –network service_network service_subnet  


在K8S项目路由器连接pod网络子网与service网络子网


1.  openstack router create k8s-router  

2.  openstack router add subnet k8s-router pod_subnet  

3.  openstack router add subnet k8s-router service_subnet  


在K8S项目创建pod安全组


1.  openstack security group create service_pod_access_sg  

2.  openstack security group rule create –remote-ip 10.1.0.0/16 –ethertype IPv4 –protocol tcp service_pod_access_sg  

3.  openstack security group rule create –remote-ip 10.2.0.0/16 –ethertype IPv4 –protocol tcp service_pod_access_sg  


注意,这里的创建的project id,user name,password,pod subnet id,service subnet id,security group id均需要记录,用于后期配置kuryr controller。

 

kubeadm安装Kubernetes

准备

master节点


以下操作在master节点和work 节点均执行。

关闭虚拟内存

1.  swapoff -a  

2.  sed -i ‘s/.*swap.*/#&/’ /etc/fstab  

配置转发参数

1.  cat <<EOF >  /etc/sysctl.d/k8s.conf  

2.  net.bridge.bridge-nf-call-ip6tables = 1  

3.  net.bridge.bridge-nf-call-iptables = 1  

4.  EOF  

5.  sysctl –system  

配置kubernetes阿里源

1.  cat <<EOF > /etc/yum.repos.d/kubernetes.repo  

2.  [kubernetes]  

3.  name=Kubernetes  

4.  baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/  

5.  enabled=1  

6.  gpgcheck=1  

7.  repo_gpgcheck=1  

8.  gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg  

9.  EOF  

设置docker源

1.  wget https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo -P /etc/yum.repos.d/  

安装docker

1.  yum install docker-ce-18.06.1.ce -y  

 

设置镜像仓库加速

1.  sudo mkdir -p /etc/docker  

2.  sudo tee /etc/docker/daemon.json <<-‘EOF’  

3.  {  

4.    “registry-mirrors”: [“https://hdi5v8p1.mirror.aliyuncs.com”]  

5.  }  

6.  EOF  

 

启动docker

1.  systemctl daemon-reload  

2.  systemctl enable docker  

3.  systemctl start docker  

安装kubernetes相关组件

1.  yum install kubelet-1.12.2 kubeadm-1.12.2 kubectl-1.12.2 kubernetes-cni-0.6.0 -y  

2.  systemctl enable kubelet && systemctl start kubelet  

开启IPVS

加载ipvs内核,使node节点kube-proxy支持ipvs代理规则。

1.  modprobe ip_vs_rr  

2.  modprobe ip_vs_wrr  

3.  modprobe ip_vs_sh  

4.    

5.  cat <<EOF >> /etc/rc.local  

6.  modprobe ip_vs_rr  

7.  modprobe ip_vs_wrr  

8.  modprobe ip_vs_sh  

9.  EOF  

 

下载镜像


1.  cat <<EOF >> master.sh  

2.  #!/bin/bash  

3.  kube_version=:v1.12.2  

4.  kube_images=(kube-proxy kube-scheduler kube-controller-manager kube-apiserver)  

5.  addon_images=(etcd-amd64:3.2.24 coredns:1.2.2 pause-amd64:3.1)  

6.    

7.  for imageName in ${kube_images[@]} ; do  

8.    docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/$imageName-amd64$kube_version  

9.    docker image tag registry.cn-hangzhou.aliyuncs.com/google_containers/$imageName-amd64$kube_version k8s.gcr.io/$imageName$kube_version  

10.  docker image rm registry.cn-hangzhou.aliyuncs.com/google_containers/$imageName-amd64$kube_version  

11.done  

12.  

13.for imageName in ${addon_images[@]} ; do  

14.  docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/$imageName  

15.  docker image tag registry.cn-hangzhou.aliyuncs.com/google_containers/$imageName k8s.gcr.io/$imageName  

16.  docker image rm registry.cn-hangzhou.aliyuncs.com/google_containers/$imageName  

17.done  

18.  

19.docker tag k8s.gcr.io/etcd-amd64:3.2.24 k8s.gcr.io/etcd:3.2.24  

20.docker image rm k8s.gcr.io/etcd-amd64:3.2.24  

21.docker tag k8s.gcr.io/pause-amd64:3.1 k8s.gcr.io/pause:3.1  

22.docker image rm k8s.gcr.io/pause-amd64:3.1  

23.EOF  

24.  

25.chmod u+x master.sh  

26../master.sh  


kubeadm init安装master节点


注意这里的pod network cidr与service cidr必须和前文中创建的openstack中pod subnet cidr及service subnet cidr保持一致。


1.kubeadm init –kubernetes-version=v1.12.2 –pod-network-cidr=10.1.0.0/16 –service-cidr=10.2.0.0/16  在成功运行该命令后会输出类似如下图所示的结果:


技术周 | Kuryr对接之Baremetal containers networking


①  表示kubernetes master节点安装成功。

②  根据命令执行同样操作。

③  记录该指令,用于后期添加kubernetes node节点。


配置flannel


这里配置flannel网络插件,仅用于对接kuryr前简单验证kubernetes功能是否正常。


下载配置文件


1.  curl -LO https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml  

 

修改pod network cidr

1.  sed -i “s/10.244.0.0/10.1.0.0/g” kube-flannel.yml  

 

启动flannel

1.  kubectl apply -f kube-flannel.yml  


设置API代理

1.  kubectl proxy –port=8080 –accept-hosts=’.*’ –address=’0.0.0.0′  

 

node节点


下载镜像

1.  cat <<EOF >> node01.sh  

2.  #!/bin/bash  

3.  kube_version=:v1.12.2  

4.  coredns_version=1.2.2  

5.  pause_version=3.1  

6.    

7.  docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/kube-proxy-amd64$kube_version  

8.  docker tag registry.cn-hangzhou.aliyuncs.com/google_containers/kube-proxy-amd64$kube_version k8s.gcr.io/kube-proxy$kube_version  

9.  docker image rm registry.cn-hangzhou.aliyuncs.com/google_containers/kube-proxy-amd64$kube_version  

10.  

11.docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/pause-amd64:$pause_version  

12.docker tag registry.cn-hangzhou.aliyuncs.com/google_containers/pause-amd64:$pause_version k8s.gcr.io/pause:$pause_version  

13.docker image rm registry.cn-hangzhou.aliyuncs.com/google_containers/pause-amd64:$pause_version  

14.  

15.docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/coredns:$coredns_version  

16.docker tag registry.cn-hangzhou.aliyuncs.com/google_containers/coredns:$coredns_version k8s.gcr.io/coredns:$coredns_version  

17.docker image rm registry.cn-hangzhou.aliyuncs.com/google_containers/coredns:$coredns_version  

18.EOF  

19.  

20.chmod u+x node01.sh  

21../node01.sh  

 

添加node节点


使用在master节点安装成功后保存的hubedem join命令,添加node节点。

1.  kubeadm join 192.168.1.12:6443 –token lgbnlx.ehciqy1p1rpu6g6g –discovery-token-ca-cert-hash sha256:0acd9f6c7afcab4f4a0ebc1a1dd064f32ef09113829a30ce51dea9822d2f4afd  

 

验证


在master节点运行下述命令可以看到node节点被正确加入

1.  [root@kuryra-1 ~]# kubectl get nodes  

2.  NAME       STATUS   ROLES    AGE   VERSION  

3.  kuryra-1   Ready    master   21h   v1.12.2  

4.  kuryra-2   Ready    <none>   21h   v1.12.2  

 

安装配置kuryr


安装kuryr-k8s-controller


安装

1.  mkdir kuryr-k8s-controller  

2.  cd kuryr-k8s-controller  

3.  virtualenv env  

4.  git clone https://git.openstack.org/openstack/kuryr-kubernetes -b stable/rocky  

5.  . env/bin/activate  

6.  pip install -e kuryr-kubernetes  

 

配置

1.  cd kuryr-kubernetes  

2.  ./tools/generate_config_file_samples.sh  

3.  mkdir /etc/kuryr  

4.  cp etc/kuryr.conf.sample /etc/kuryr/kuryr.conf  

这里需要修改配置文件kuryr.conf。具体配置项需根据上文中在openstack内创建的用于K8S环境的信息填写。

1.  [DEFAULT]  

2.  use_stderr = true  

3.  bindir = /usr/local/libexec/kuryr  

4.    

5.  [kubernetes]  

6.  api_root = http://192.168.1.11:8080  

7.    

8.  [neutron]  

9.  # 需根据上文章节中创建的项目、用户信息填写  

10.auth_url = http://192.168.1.11:5000/v3  

11.username = k8s-user  

12.user_domain_name = Default  

13.password = 99cloud  

14.project_name = ks  

15.project_domain_name = Default  

16.auth_type = password  

17.  

18.[neutron_defaults]  

19.ovs_bridge = br-int  

20.# 下面的网络资源ID需根据上文章节中创建的资源ID填写  

21.pod_security_groups = a19813e3-f5bc-41d9-9a1f-54133facb6da  

22.pod_subnet = 53f5b742-482b-40b6-b5d0-bf041e98270c  

23.project = aced9738cfd44562a22235b1cb6f7993  

24.service_subnet = d69dae26-d750-42f0-b844-5eb78a6bb873  

 

运行

1.  kuryr-k8s-controller –config-file /etc/kuryr/kuryr.conf -d  


安装kuryr-cni


安装

1.  mkdir kuryr-k8s-cni  

2.  cd kuryr-k8s-cni  

3.  virtualenv env  

4.  . env/bin/activate  

5.  git clone https://git.openstack.org/openstack/kuryr-kubernetes -b stable/rocky  

6.  pip install -e kuryr-kubernetes  

 

配置

1.  cd kuryr-kubernetes  

2.  ./tools/generate_config_file_samples.sh  

3.  mkdir /etc/kuryr  

4.  cp etc/kuryr.conf.sample /etc/kuryr/kuryr.conf  

此处需要修改配置文件kuryr.conf。

1.  [DEFAULT]  

2.  use_stderr = true  

3.  bindir = /usr/local/libexec/kuryr  

4.  lock_path=/var/lib/kuryr/tmp  

5.     

6.  [kubernetes]  

7.  # 填k8s master的IP  

8.  api_root = http://192.168.1.11:8080  

 

修改cni配置


执行下述命令。

1.  mkdir -p /opt/cni/bin  

2.  ln -s $(which kuryr-cni) /opt/cni/bin/  

由于前文安装k8s时已经安装过flannel,这里/opt/cni/bin目录已经存在。新增/etc/cni/net.d/10-kuryr.conf文件,按如下信息修改配置文件,同时删除同目录下flannel的配置文件。

1.  {  

2.      “cniVersion”: “0.3.1”,  

3.      “name”: “kuryr”,  

4.      “type”: “kuryr-cni”,  

5.      “kuryr_conf”: “/etc/kuryr/kuryr.conf”,  

6.      “debug”: true  

7.  }  

安装相应依赖包

1.  sudo pip install ‘oslo.privsep>=1.20.0’ ‘os-vif>=1.5.0’  

运行

1.  kuryr-daemon –config-file /etc/kuryr/kuryr.conf -d  

 


END

九州云成立于2012年,是中国早期从事开放基础架构服务的专业公司。成立七年,秉承“开源 · 赋能变革”的理念,不断夯实自身实力,先后为政府、金融、运营商、能源、制造业、商业、交通、物流、教育、医疗等各行业的企业级客户提供高质量的开放基础架构服务。目前拥有国家电网、南方电网广东公司、中国人民银行、中国银联、中国移动、中国电信、中国联通、中国资源卫星、eBay、国际陆港集团、中国人寿、万达信息、东风汽车、诺基亚等众多重量级客户,被用户认可为最值得信赖的合作伙伴。


技术周 | Kuryr对接之Baremetal containers networking


点击“阅读原文”,了解九州云更多信息!