售后服务云计算服务的大规模计算网络

1、（售后服务）云计算服务的大规模计算网络20XX年XX月峯年的企业咨询咸问经验.经过实战验证可以藩地执行的卓越萱理方案.值得您下载拥有云计算服务的大规模计算网络2010 年 04 月 21 日文/ 李延峰如果说提供云计算这种巨型计算服务的 IT 架构必然是集结了大规模基础资源的数据中心“超级航 母”，它也必然要求大规模计算网络和其相适应。云计算 IT 资源供应模型云计算既然拥有近乎无限的计算、存储、数据通信能力，那么提供云计算服务的IT 架构必然是集结了大规模基础资源的数据中心“超级航母”。云计算 IT 资源的大规模集中运营，可极大优化基础资源的分布和调度，图1 所示为理想的业务模型。对于使用云

2、计算服务的企业或个人而言，能够满足IT 业务的最佳方式为计算能力按需增长、 应用部署快速实现、工作负载可动态调整、投入成本规划可控； 对于云计算服务供应商而言，为满足大量客户（个人或企业）的 IT 资源需求，其运营的 IT 基础架构需要有壹个大规模的资源池，可基于服务客户数量的增长、客户业务负载增长的需求变化情况提供匹配的IT 资源支持能力。图 1 云计算 IT 资源供应模型大规模云计算服务运营趋势大规模的 IT 集中建设和运营带来将是大幅度的成本节约效应。据国外壹份统计数据显示（如 图 2 所示），于大规模 IT 服务环境下，网络、存储、服务器/管理等各方面的投入均会于单位资源尺度内极大降低

3、，从而于大规模运营条件下使得单位资源带来更大的产出。图 2 大规模 IT 运营的成本优势于大规模云计算运营趋势下，IT 基础组件必然走向全面标准化，以使得云所支撑各部分能够于保持发展的同时相互兼容。当前的虚拟化标准组织、云计算标准化组织已经基本形成，它们的 工作目的就是制定云计算不同组件、不同技术之间的公共接口，这样众多的软硬件供应商能够于云计算环境下提供互通、协作的标准化产品，从而可期望于远期目标上使得云计算的大规模IT 运营架构逐步摆脱隔离性、垄断性，使公共服务得以构建于开放的公共化标准技术基础上，且随着 技术发展而持续性降低成本。对于大规模的计算网络，于基础形态上主要有俩种模式：虚拟化计

4、算和集群计算。其实这俩 种方式且无完全的割离，即可能分别部署，也可能相互结合。壹、大规模虚拟化计算和网络架构虚拟化计算技术已经逐步成为云计算服务的主要支撑技术，特别是于计算能力租赁、调度的 云计算服务领域起着非常关键的作用。于大规模计算资源集中的云计算数据中心，以 X86 架构为基准的不同服务器资源，通过虚拟 化技术将整个数据中心的计算资源统壹抽象出来，形成能够按壹定粒度分配的计算资源池，如图 3 所示。虚拟化后的资源池屏蔽了各种物理服务器的差异，形成了统壹的、云内部标准化的逻辑 CPU 、逻辑内存、逻辑存储空间、逻辑网络接口，任何用户使用的虚拟化资源于调度、供应、度 量上均具有壹致性。图 3

5、 大规模虚拟化云计算虚拟化技术不仅消除大规模异构服务器的差异化，其形成的计算池能够具有超级的计算能力 （如图 4 所示），壹个云计算中心物理服务器达到数万台是壹个很正常的规模。壹台物理服务器 上运行的虚拟机数量是动态变化的，当前壹般是 4 到 20 ，某些高密度的虚拟机能够达到 100:1 的虚拟比（即壹台物理服务器上运行100 个虚拟机），于 CPU 性能不断增强（主频提升、多核多路）、当前各种硬件虚拟化 （CPU 指令级虚拟化、内存虚拟化、桥片虚拟化、网卡虚拟化）的辅助下，物理服务器上运行的虚拟机数量会迅猛增加。壹个大型IDC 中运行数十万个虚拟机是可预见的，当前的云服务 IDC 于业务规

6、划时，已经于考虑这些因素。图 4 密集的虚拟机群于虚拟化云计算网络环境，超高密度的虚拟机数量引入了有别于任何以往传统意义上数据中 心的业务承载问题，于表象相似的网络平台上， “服务器 /虚拟机” 的数量于单位空间和单位网络 接口剧增，如图 5 所示，对基础网络的转发表项、吞吐能力、突发流量吸收提出了苛刻的要求。图 5 密集的应用和性能要求虚拟化的云中，计算资源能够按需扩展、灵活调度部署，这由虚拟机的迁移功能实现，虚拟 化环境的计算资源必须于二层网络范围内实现透明化迁移（如图6 所示）。图 6 透明网络支持虚拟资源的调度迁移透明环境不仅限于数据中心内部，对于多个数据中心共同提供的云计算服务，要求

7、云计算的 网络对数据中心内部、数据中心之间均实现透明化交换（如图7 所示），这种服务能力能够使客户分布于云中的资源逻辑上相对集中 （如于相同的壹个或数个 VLAN 内） ，而不必关心具体物理位 置；对云服务供应商而言，透明化网络能够于更大的范围内优化计算资源的供应，提升云计算服 务的运行效率、有效节省资源和成本。图 7 大规模虚拟化云计算的透明化网络承载二、大规模集群计算和网络架构集群计算很早就广泛应用了， 只是于不同的领域有着不同的表现形式， 或者说有不同的术语， 如于科学计算领域的且行计算或高性能计算当前主要以集群计算的方式实现。集群通过壹组松散集成的计算机软件和 / 或硬件连接起来高度紧

8、密地协作完成计算工作， 于某种意义上， 集群能够被 见作是壹台计算机。人们使用集群的目的是为了获得强大的计算能力，虽然这能够通过购买具备超级计算能力的 大型机来实现，可是于成本投入上是巨大的。对于壹般计算机，计算能力是有限的，虽然摩尔定 律说计算能力每 18 个月能够翻壹番，但要达到大型机的性能，很长壹段时间内是难以实现的 （摩 尔定律被普遍认为于过去 30 年相当有效，未来 1015 年应依然适用 ）。因此，为突破摩尔定律 的限制，将多台低成本计算机通过集群方式，以且行计算来获取更大的计算能力，成为各种追求 高性能计算领域的主流方向（如图 8 所示）。图 8 以集群架构超越摩尔定律以互联网应

9、用为例，有的计算服务要求提供超级计算能力，如大型搜索引擎的构建，就是大 量服务器群共同协作实现的巨量计算。科研领域且行计算的主流技术是MPI（MessagePassinglnterface），但以支持 Fortran、C 语言的科学计算为优势。云计算领域的代表性技术是Hadoop（ 仍有其它类似的分布式计算技术 ），突出商用的扩展性架构、大数据量处理，大大简化开发难度，屏蔽系统底层的复杂性。Hdoop 是目前于互联网使用广泛的壹种云计算支撑架构， 借助于 Hadoop, 程序员能够轻松地 编写分布式且行程序，将其运行于大型计算机集群上，完成海量数据的计算。图9 是当前广为流传的 Hadoop

10、分布式文件系统体系架构模型，这壹类的集群架构将服务器按群分置不同角色群， 角色协同完成大规模计算任务。图 9Hadoop 分布式文件系统体系架构这些角色包括 NameNode ，它于 HDFS 内部提供元数据服务；DataNode ，它为 HDFS 提供存储块。 NameNode 是壹个通常于 HDFS 实例中的单独机器上运行的软件。它负责管理文件系统 名称空间和控制外部客户机的访问。 DataNode 响应来自 HDFS 客户机的读写请求。 NameNode 和每个 DataNode 有定期心跳（ heartbeat ）消息检查健康性。分布式文件系统的设计需求对应到网络的架构上主要有：且发吞

11、吐性能、可伸缩性、容错需求等。HDFS 的目标就是构建于大规模廉价机器上的分布式文件系统集群，壹个文件能够表示为其 内容于不同位置的多个拷贝。这样做带来了俩个好处：访问同个文件时能够从多个服务器中获取 从而改善服务的伸缩性，另外就是提高了容错能力，某个副本损坏了，仍然能够从其他服务器节 点获取该文件。同时集群内部仍通过心跳检测、集群的负载均衡等特性提升容错性。传统 HDFS 采用壹种称为 rack-aware 的策略来改进数据的可靠性、 有效性和网络带宽的利用， 典型的组网逻辑如图 10 所示 （也是流传比较广泛的壹张图，笔者未加修改）。图 10 经典的 Hadoop 组网结构图 10 中每个

12、交换及所接服务器被安装于数据中心的同壹个机架 （rack） 内，该交换机称为Topofrackswitch ，典型情况下每个机架内部署 40 台服务器 （ 国外比较流行，国内当前达到这样 密度的 IDC很少），壹般采用 48 千兆端口的交换机，传统设计中会采用4 个到 8 个千兆上行，因此每个机架上行的带宽收敛比壹般于 5:110:1 。不同机架间的俩台机器的通讯需要通过交换机，显然通常情况下，同壹个机架内的俩个节点 间的带宽会比不同机架间的俩台机器的带宽大。因此 Hadoop 的壹个假设是：机架内部节点之间 的传输速度快于机架间节点的传输速度。通过壹个称为 RackAwareness 的过程

13、， Namenode 决定了每个 Datanode 所属的 rackid 。壹 个简单但没有优化的策略就是将副本存放于单独的机架上。 这样能够防止整个机架 （非副本存放） 失效的情况，且且允许读数据的时候能够从多个机架读取。这个简单策略设置能够将副本分布于 集群中，有利于组件失败情况下的负载均衡。可是，这个简单策略加大了写的代价，因为壹个写 操作需要传输 block 到多个机架。为了降低整体的带宽消耗和读延时， HDFS 会尽量让 reader 读最近的副本。如果于 reader 的 同壹个机架上有壹个副本， 那么就读该副本。 如果壹个 HDFS 集群跨越多个数据中心， 那么 reader 也

14、将首先尝试读本地数据中心的副本。HDFS 支持数据的均衡分布处理，如果某个 Datanode 节点上的空闲空间低于特定的临界点， 那么就会启动壹个计划自动地将数据从壹个 Datanode 搬移到空闲的 Datanode 。当对某个文件的 请求突然增加，那么也可能启动壹个计划创建该文件新的副本，且分布到集群中以满足应用的要 求。我们能够见到， Hadoop 系统于开发过程中关注了数据交换对象（计算节点 ）之间的距离，实际上是考虑了网络构建模型中带宽不匹配因素。这种因素的引入，不仅编程人员需要关心，业务 部署人员、网络维护人员也均要关心，于小规模环境下仍能够勉强运行，可是如果要支持全互联 网级的大

15、规模应用，集群可能达到数千台、数万台，业务的部署、扩展、运行、支撑均会存于很 多问题。如图 11 是壹种高扩展要求的集群模型，这类集群应用自身是分层架构，每壹层应用均 是壹个大规模集群，采用传统方式构建交换网络，必将存于诸多限制，无法发挥云计算巨型计算 的服务能力。图 11 大规模集群架构随着网络交换万兆技术的发展和设备成本的不断降低，目前大规模集群的构建也发展到新的 阶段，需要新的网络结构来支持和运行：无阻塞网络架构：满足集群环境中所有服务器的对等通信要求，任意节点之间能够达到相 等带宽（当前是以千兆为主），服务器应用程序不再关注数据交互节点是于壹个机架内仍 是于其它机架。大规模集群能力：当

16、前 2 千台规模的服务器集群已经于互联网行业广泛部署，随着云计算业务的开发提供，更大规模的集群（5000-1 万台）将成为支持云计算的主流网络结构，无阻塞架构是这种网络的基本要求。足够扁平化的架构：所谓扁平化就是极大减少组网结构层次，目前数据中心扁平化结构以 俩层物理网络为主流。于仍是千兆为主的服务器端口条件下，接入交换机的用户端口数壹般为 48 个千兆，要满足无阻塞的跨机架带宽，则上行带宽需要 5 个万兆（当然也能够只使用 40 个千兆接入，4 个万兆上行），而核心交换则需要高密的万兆（120） 全线速能力。图 12 是壹种新的无阻塞网络模型，也被称为CLOS 组网结构。于接入层交换机当前可达到50 个千兆端口（常规是 48，可用俩个万兆自适应千兆），无阻塞上行 5 个万兆到 5 台高密万兆核 心设备，当核心万兆密度超过140 端口，则整个集群规模可达到7000 台服务器。网络规划上将二层终结于接入层，使用等价路由将接入交换机的上行链路带宽进行负载分担，从而能够实现整 个网络的无阻塞交换，任意服务器端口之间能够具有千兆线速的能力，完全消除了云计