一个完整和全面的云服务器安全方案应该是什么样子

安全的改变
随着云计算技术的普及，越来越多的企业将其系统向云端迁移，云计算便捷、可靠和廉价的特性被广大用户接受。
从另一方面来说，尽管距离商业化公有云业务的推出已经超过10年，根据CSA（CloudSecurityAlliance，云安全联盟）在今年年初发布的《CloudAdoption,PracticesandPrioritiesSurveyReport》调研报告，73%的受访对象表示安全仍旧是企业上云的首要顾虑。
对于很多企业用户来来说，由于云服务器替代传统服务器承载了与企业生存发展息息相关的互联网业务，使得用户对云安全的疑问很大程度上聚焦在云服务器的安全上。
云服务器安全吗？这个问题不仅仅限定在看不到摸不着的虚拟化层面，让用户感触更为深刻的是——突然发现，之前很多常见和常用的安全防护系统，特别是“硬件盒子”，都从采购名单上消失了。云计算环境对于安全防护的改变可见一斑。
这样一来，云服务器的安全该如何实现呢？
不变的安全
正像云计算对于互联网业务革命性的改变一样，对安全的改变也是彻底的，不仅体现在安全防护理念上，还对安全交付方式的改变。
不过，安全的本质并没有因为云计算技术的引入发生改变。事实上，部署在传统环境下的服务器和云环境下的服务器，从安全风险角度上讲没有太多不同。
从上图可见，云服务器的安全风险主要包括：
（1）自身存在的脆弱性，例如漏洞（包括虚拟化层面）、错误的配置、不该开放的端口等；
（2）外部威胁，例如后门、木马、暴力破解攻击等。
不管是部署在传统数据中心还是云数据中心中，服务器安全都要面对和解决上述两个方面的风险。
对于云服务器来说，首先需要解决的是自身脆弱性的问题，特别是漏洞。存在漏洞的系统就像一间打开窗户的房间，不管安装了多么先进的门禁系统，也无法阻挡小偷的光临。此外，对服务器关键配置和端口的检查和监控，一方面可以减少攻击面，另一个方面可以随时掌握系统安全状态。从外部威胁角度上讲，暴力破解仍旧是云服务器最大的网络威胁。暴力破解防护需要覆盖系统、应用和数据库三个层面，任何一个层面的缺失都会增大系统遭受入侵的概率。最后，能否快速发现和清除云服务器上的病毒、木马和后门是对防护能力的重大考验。
双重挑战
然而，现实是骨感的。云服务器安全面临来自内部和外部的双重挑战。
首先，云服务器的脆弱性突出体现在未被修复的漏洞上。根据国外某安全机构的统计，在金融行业，漏洞平均修复时间长达176天。采用云计算后这个数字稍微有所改善，然而，云服务器漏洞的平均修复时间仍旧是50天。无论是176天还是50天，对于进攻一方来说，足够遍历整个服务器。
其次，根据国外某安全公司的测试，“黑客”成功入侵AWS服务器只需要4个小时。表面看是系统脆弱性导致，背后实际上是黑客的暴力破解行为。在云计算环境中，大部分云服务提供商并不提供暴力破解防护服务，而是建议用户在服务器上安装三方防护软件。事实上，市面流行的云服务器安全软件一般只提供 *** 作系统层面的暴力破解防护，并没有覆盖到应用和数据库层面。应用和数据库层面的缺失无疑是在云服务器防护上玩起了“锯箭”法—— *** 作系统我管，上面的找别人。
第三，绝大多数云服务器安全系统／方案体现为单点防护。单点防护具有两个特点：横向上针对服务器个体的防护以及纵向上在服务器一个层面进行防护。横向上的单点防护体现为每个云服务器都是彼此孤立的个体。在木马、后门变异样本层出不穷的今天，如果恶意样本采集不是实时的，分析和策略分享、下发不能快速完成，将无异于将主动权拱手让给入侵者。纵向上的单点体现在，同时也是常见云服务器安全软件的“通病”，无论是网络、系统、应用和数据防护都依靠安装在云服务器上的软件来完成。先不说防护效果，启用防护功能需要调用大量的系统资源，等同于发起一场自残式的拒绝服务攻击。
最后，安全攻防的背后是人的技能、智慧以及经验的对抗。在特定情况下，要求人员介入，快速完成样本收集、取证、分析和攻击阻断。然而，对于大多数企业来说，建立一支具有专业技能的安全攻防团队是不现实的。
因此，云服务器的安全防护是对平台化、体系化以及包括快速响应、技术经验在内运营能力的全面挑战，而不是简简单单安装一个主机防护软件就可以实现的。
云服务器防护应该是什么样子？
一个完整和全面的云服务器防护方案应该包含对内部脆弱性（漏洞、配置、端口等）的快速定位、修复以及对外部威胁的迅速发现和阻断。
对于内部脆弱性，特别是严重威胁云服务器安全的漏洞，不仅要求精准定位，对于绝大部分漏洞来说，自动化的漏洞修复将有效提升安全防护的效率和效果。对于关键服务器或有严格合规／业务规定的服务器，云服务商应该提供漏洞修复的风险提示，这个工作不应该交给用户。云盾安骑士软件提供自动化漏洞修复功能，以及针对补丁的风险评估及修复建议。
其次，对于云服务器首要的外部威胁——暴力破解，防护系统必须涵盖系统、应用和数据库。云盾安骑士软件支持WINDOWS系统和LINUX系统两大平台，同时针对SSH，RDP，Telnet，Ftp，MySql，SqlServer等等常见应用和数据库提供安全监控，随时发现黑客的暴力破解行为。

Dryad：MapReduce之外的新思路 目前各大软件巨头都搭建了自己的分布式平台解决方案，主要包括Dryad，DynamoSDMapReduce等框架。2010年12月21日，微软发布了Dryad的测试版本，成为谷歌MapReduce分布式并行计算平台的竞争对手。Dryad是微软构建云计算基础设施的重要核心技术之一，它可以让开发人员在Windows或者，NET平台上编写大规模的并行应用程序模型，并能够让在单机上编写的程序运行在分布式并行计算平台上。工程师可以利用数据中心的服务器集群对数据进行并行处理，当工程师在 *** 作数千台计算机时，无需关心分布式并行计算系统方面的细节。
DryadgDDryadLINO是微软硅谷研究院创建的研究项目，主要用来提供一个分布式并行计算平台。DryadLINO是分布式计算语言，能够将LINQ编写的程序转变为能够在Dryad上运行的程序，使普通程序员也可以轻易进行大规模的分布式计算。它结合了微软Dryad和LINO两种关键技术，被用于在该平台上构建应用。Dryad构建在Cluster Service(集群服务)和分布式文件系统之上，可以处理任务的创建和管理、资源管理，任务监控和可视化、容错，重新执行和调度等工作。




Dryad同MapReduce样，它不仅仅是种编程模型，同时也是一种高效的任务调度模型。Dryad这种编程模型不仅适用于云计算，在多核和多处理器以及异构机群上同样有良好的性能。在VisualStudio 2010 C++有一套并行计算编程框架，支持常用的协同任务调度和硬件资源(例如CPU和内存等)管理，通过WorkStealing算法可以充分利用细颗粒度并行的优势，来保证空闲的线程依照一定的策略建模，从所有线程队列中“偷取”任务执行，所以能够让任务和数据粒度并行。Dryad与上述并行框架相似，同样可以对计算机和它们的CPU进行调度，不同的是Dryad被设计为伸缩于各种规模的集群计算平台，无论是单台多核计算机还是由多台计算机组成的集群，甚至拥有数千台计算机的数据中心，都能以从任务队列中创建的策略建模来实现分布式并行计算的编程框架。

Dryad系统架构

Dryad系统主要用来构建支持有向无环图(Directed Acycline Graph，DAG)类型数据流的并行程序，然后根据程序的要求进行任务调度，自动完成任务在各个节点上的运行。在Dryad平台上，每个任务或并行计算过程都可以被表示为一个有向无环图，图中的每个节点表示一个要执行的程序，节点之间的边表示数据通道中数据的传输方式，其可能是文件、TCPPipe、共享内存
用Dryad平台时，首先需要在任务管理(JM)节点上建立自己的任务，每一个任务由一些处理过程以及在这些处理过程问的数据传递组成。任务管理器(JM)获取无环图之后，便会在程序的输入通道准备，当有可用机器的时候便对它进行调度。JM从命名服务器(NS)那里获得一个可用的计算机列表，并通过一个维护进程(PD)来调度这个程序。
Dryad的执行过程可以看做是一个二维管道流的处理过程，其中每个节点可以具有多个程序的执行，通过这种算法可以同时处理大规模数据。在每个节点进程(VerticesProcesses)上都有一个处理程序在运行，并且通过数据管道(Channels)的方式在它们之间传送数据。二维的Dryad管道模型定义了一系列的 *** 作，可以用来动态地建立并且改变这个有向无环图。这些 *** 作包括建立新的节点，在节点之间加入边，合并两个图以及对任务的输入和输出进行处理等。

Dryad模型算法应用

DryadLINQ可以根据工程师给出的LINQ查询生成可以在Dryad引擎上执行的分布式策略算法建模(运算规则)，并负责任务的自动并行处理及数据传递时所需要的序列化等 *** 作。此外，它还提供了一系列易于使用的高级特性，如强类型数据、Visual Studio集成调试以及丰富的任务优化策略(规则)算法等。这种模型策略开发框架也比较适合采用领域驱动开发设计(DDD)来构建“云”平台应用，并能够较容易地做到自动化分布式计算。
我们经常会遇到网站或系统无法承载大规模用户并发访问的问题，解决该问题的传统方法是使用数据库，通过数据库所提供的访问 *** 作接口来保证处理复杂查询的能力。当访问量增大，单数据库处理不过来时便增加数据库服务器。如果增加了三台服务器，再把用户分成了三类A(学生)、B(老师)，C(工程师)。每次访问时先查看用户属于哪一类，然后直接访问存储那类用户数据的数据库，则可将处理能力增加三倍，这时我们已经实现了一个分布式的存储引擎过程。
我们可以通过Dryad分布式平台来解决云存储扩容困难的问题。如果这三台服务器也承载不了更大的数据要求，需要增加到五台服务器，那必须更改分类方法把用户分成五类，然后重新迁移已经存在的数据，这时候就需要非常大的迁移工作，这种方法显然不可取。另外，当群集服务器进行分布式计算时，每个资源节点处理能力可能有所不同(例如采用不同硬件配置的服务器)，如果只是简单地把机器直接分布上去，性能高的机器得不到充分利用，性能低的机器处理不过来。
Dryad解决此问题的方法是采用虚节点，把上面的A、B、C三类用户都想象成一个逻辑上的节点。一台真实的物理节点可能会包含一个或者几个虚节点(逻辑节点)，看机器的性能而定。我们可以把那任务程序分成Q等份(每一个等份就是一个虚节点)，这个Q要远大于我们的资源数。现在假设我们有S个资源，那么每个资源就承担Q／S个等份。当一个资源节点离开系统时，它所负责的等份要重新均分到其他资源节点上；当一个新节点加入时，要从其他的节点1偷取2一定数额的等份。
在这个策略建模算法下，当一个节点离开系统时，虽然需要影响到很多节点，但是迁移的数据总量只是离开那个节点的数据量。同样，～个新节点的加入，迁移的数据总量也只是一个新节点的数据量。之所以有这个效果是因为Q的存在，使得增加和减少节点的时候不需要对已有的数据做重新哈希(D)。这个策略的要求是Q>>s(存储备份上，假设每个数据存储N个备份则要满足Q>>SN)。如果业务快速发展，使得不断地增加主机，从而导致Q不再满足Q>>S，那么这个策略将重新变化。
Dryad算法模型就是一种简化并行计算的编程模型，它向上层用户提供接口，屏蔽了并行计算特别是分布式处理的诸多细节问题，让那些没有多少并行计算经验的开发 人员也可以很方便地开发并行应用，避免了很多重复工作。这也就是Dryad算法模型的价值所在，通过简化编程模型，降低了开发并行应用的入门门槛，并且能大大减轻了工程师在开发大规模数据应用时的负担。
通过上述的论述，我们可以看到Dryad通过一个有向无环图的策略建模算法，提供给用户一个比较清晰的编程框架。在这个编程框架下，用户需要将自己的应用程序表达为有向无环图的形式，节点程序则编写为串行程序的形式，而后用Dryad方法将程序组织起来。用户不需要考虑分布式系统中关于节点的选择，节点与通信的出错处理手段都简单明确，内建在Dryad框架内部，满足了分布式程序的可扩展性、可靠性和对性能的要求。

使用Drvad LINO

通过使用DryadLINQ编程，使工程师编写大型数据并行程序能够轻易地运行在大型计算机集群里。DryadLINO开发的程序是一组顺序的L_NQ代码，它们可以针对数据集做任何无副作用的 *** 作，编译器会自动将其中数据并行的部分翻译成并行执行的计划，并交由底层的Dryad平台完成计算，从而生成每个节点要执行的代码和静态数据，并为所需要传输的数据类型生成序列化代码；
LINQ本身是，NET引入的组编程结构，它用于像 *** 作数据库中的表一样来 *** 作内存中的数据集合。DryadLINQ提供的是一种通用的开发／运行支持，而不包含任何与实际业务，算法相关的逻辑，Dryad和DryadLINQ都提供有API。DryadLINQ使用和LINQ相同的编程模型，并扩展了少量 *** 作符和数据类型以适用于数据并行的分布式计算。并从两方面扩展了以前的计算模型(SQL，MapReduce，Dryad等)它是基于，NET强类型对象的，表达力更强的数据模型和支持通用的命令式和声明式编程(混合编程)，从而延续了LINQ代码即数据(treat codeas data)的特性。
DryadLINQ使用动态的代码生成器，将DryadLINQ表达式编译成，NET字节码。这些编译后的字节码会根据调度执行的需要，被传输到执行它的机器上去。字节码中包含两类代码完成某个子表达式计算的代码和完成输入输出序列化的代码。这种表达式并不会被立刻计算，而是等到需要其结果的时候才进行计算。DryadLINQ设计的核心是在分布式执行层采用了一种完全函数式的，声明式的表述，用于表达数据并行计算中的计算。这种设计使得我们可以对计算进行复杂的重写和优化，类似于传统的并行数据库。从而解决了传统分布式数据库SQL语句功能受限与类型系统受限问题，以及MapReduce模型中的计算模型受限和没有系统级的自动优化等问题。
在Dryad编程模式中，应用程序的大规模数据处理被分解为多个步骤，并构成有向无环图形式的任务组织，由执行引擎去执行。这两种模式都提供了简单明了的编程方式，使得工程师能够很好地驾驭云计算处理平台，对大规模数据进行处理。Dryad的编程方式可适应的应用也更加广泛，通过DryadLINQ所提供的高级语言接口，使工程师可以快速进行大规模的分布式计算应用程序的编写。

Dryad技术的应用

云计算最重要的概念之～就是可伸缩性，实现它的关键是虚拟化。通过虚拟化可以在一台共享计算机上聚集多个 *** 作系统和应用程序，以便更好地利用服务器。当一个服务器负载超荷时，可以将其中一个 *** 作系统的一个实例(以及它的应用程序)迁移到一个新的，相对闲置的服务器上。虚拟化(Virtualization)是云计算的基石，企业实现私有云的第一步就是服务器基础架构进行虚拟化。基础设施虚拟化之后。接下来就是要将现有应用迁移到虚拟环境中。
Dryad结合Hyper-V(Windows Server 2008的一个关键组成部分)虚拟化技术。可以实现TB级别数据的在线迁移。中小型企业也可以针对企业内部小型集群服务器进行分布式应用系统编程，以及制定私有云开发与应用解决方案等设计。Windows Azure是微软的公有云解决方案，但是目前要大规模应用还为时过早。使用现有Windows第三方产品实现私有云，花费成本却很大。然而Dryad技术给我们带来了不错的折中选择，当我们基于Windows Server台运行应用系统或者网站时，便可以基于Dryad分布式架构来开发与设计实现。当公有云时机成熟和各种条件完备时，系统可以很轻易地升级到公有云，企业而无需花费太多成本。

写在最后

云计算可以看成是网络计算与虚拟化技术的结合，利用网络的分布式计算能力将各种IT资源筑成一个资源池，然后结合成熟的存储虚拟化和服务虚拟化技术，让用户实时透明地监控和调配资源。Dryad是实现构建微软云计算基础设施的重要核心技术之一，其具有诸多优点，如DryadLINQ具有声明式编程并将 *** 作的对象封装为，NET类数据，方便数据 *** 作，自动并行化、VisualStudio IDE和，NET类库集成，自动序列化和任务图的优化(静态和动态(主要通过DryadAPI实现))，对J0in进行了优化，得到了比BigTable+MapReduee更快的Join速率和更易用的数据 *** 作方式等。
不过，Dryad和DryadLINQ也同样具有局限性。其一，它更适用于批处理任务，而不适用于需要快速响应的任务；这个数据模型更适用于处理流式访问，而不是随机访问。其二，DryadLINQ使用的是，NET的LINO查询语言模型，针对运行Windows HPC Server的计算机集群设计，而目前高性能计算市场被Einux所占领。此外，和MapReduce的应用时间和实践相比，Dryad的可靠性还明显不足，据了解除了微软AdCenter中的数据分析和Trident项目之外，其它应用Dryad的地方还很少。不过总的来看，Dryad平台在将来仍具有很广泛的发展前景，尤其对NET开发人员来说是―次很重要的技术革新机遇。
名词解释
任务管理器(Job Manager，JM)：每个Job的执行被一个Job Manager控制，该组件负责实例化这个Job的工作图，在计算机群上调度节点的执行；监控各个节点的执行情况并收集一些信息，通过重新执行来提供容错：根据用户配置的策略动态地调整工作图。
计算机群(Cluster)：用于执行工作图中的节点。
命名服务器(Name Server,Ns)：负责维护cluster中各个机器的信息。
维护进程(PDaemon,PD)：进程监管与调度工作。

首先要结合具体的业务场景，不根据业务就云设计就是在耍流氓。

业务场景

首先你要确定你所架构的系统服务于什么业务。假如我们现在是一个小创业公司，注册用户就20万，每天活跃用户就1万，每天单表数据量就1000，然后高峰期每秒钟并发请求最多就10。但是你要考虑到后面注册用户数达到了2000万！每天活跃用户数100万！每天单表新增数据量达到50万条！高峰期每秒请求量达到1万。

静态资源

大宽带、CDN、缓存（页面缓存、对象缓存），WEB服务器缓存等N级分布式缓存，Redis、Memcached缓存集群。

动态资源

计算：多组服务器，负载均衡等技术控制流量。

存储：存储这里就比较麻烦，按照KV存储简单的资源，然后在计算部分进行整合。真的没办法做KV的，采用跨库索引来做。单机存储数量要合理，不能太多。还有就是事务性的问题，解决方案就是BASE思想或者采用日志方式。

纵向拆分、水平扩展

系统按照模块功能纵向拆分，再水平扩展，抽象服务层利用各种中间件完善，优化JVM应用服务器。

消息中间件

用mq解决稳定性。将耗时比较长或者耗费资源的请求排队，异步处理，减轻服务器压力增加稳定性

数据库

关系型、非关系型数据库上最牛比SSD硬盘，分库分表，读写分离，读的流量多时还要增加从库提高IO性能。每秒1万请求到5台数据库上，每台数据库就承载每秒2000的请求，相应的压力也就会减少。

SQL语句避免跨表查询，优化好存储过程，此时注意存储过程利用好了是把利剑，利用不好就成为了累赘。

负载均衡

负载均衡由多种实现方式，一种是在硬件上的，常用软件由F5、NetScaler、Radware和Array等商用的，但是价格较昂贵。另外一种就是软件的，常见的软件有LVS、Nginx、Apache等,它们是基于Linux系统并且开源的负载均衡策略。

简单架构图

结语

系统架构中需要注意的点太多，具体业务也不尽相同。实现方案也有多种，此处只提供一个思路。

云服务器ecs在云计算saas三层体系中属于最底层的服务。

云服务器（Elastic Compute Service，简称ECS）是阿里云提供的性能卓越、稳定可靠、d性扩展的IaaS级别云计算服务。云服务器ECS免去了您采购IT硬件的前期准备，让您像使用水、电、天然气等公共资源一样便捷、高效地使用服务器，实现计算资源的即开即用。

阿里云ECS持续提供创新型服务器，解决多种业务需求，助力您的业务发展。ecs（云服务器）在云计算三层体系中属于最底层。通常用作应用程序的运行环境，其最重要的特点是d性。

为什么选择云服务器ECS：

选择云服务器ECS，您可以轻松构建具有以下特点的计算资源：

1无需自建机房，无需采购以及配置硬件设施。

2分钟级交付，快速部署应用，缩短准备周期。

3在全球范围内持续扩张的数据中心和BGP机房。

4成本透明，按需使用，支持根据业务发展随时扩展资源，以及随时释放多余资源。

5提供GPU和FPGA等异构计算服务器、d性裸金属服务器以及通用的x86架构服务器。

6支持通过内网访问其他阿里云服务，形成多种行业解决方案，降低公网流量成本。

7提供虚拟防火墙、角色权限控制、内网隔离、防病毒攻击及流量监控等多重安全方案。

8提供性能监控框架和主动运维体系。

9提供行业通用标准API，提高易用性和适用性。

前几周有人问我，如果有一个环境中给你10多个交换机和路由器，应该如何配置。这是一个很好的问题，关键不在端口安全、Port Channel、STP、和路由的配置，而是在于针对终端应用服务特点选择相应适合的网络架构。

近十年来，虽然云服务的扩展性需求促进了相关解决方案快速发展，然而数据中心常见的网络拓扑仍然可以归纳为两种：传统的三层网络架构，和Leaf-Spine二层网络架构。

传统的三层网络架构由三层交换机组成：即访问层，聚合层(有时称为分发层)和核心层。服务器连接到其中一个边缘层访问交换机(常称Top of Rack Switch，或 TOR Switch)，聚合层交换机则将多个接入层交换机互连在一起，所有聚合层交换机通过核心层交换机相互连接。核心层交换机还负责将数据中心连接到Internet。传统的数据中心过去采用的就是这种三层架构。

下图是我参与优化设计的有数万台服务器的传统数据中心网络架构示意图。

在这个拓扑中，除了经典的三层（分发路由器，网络分区汇聚路由器，服务器接入交换机）外，核心层还包括了： WAN核心骨干路由器，WAN发路由器，WAN优化加速，LAN核心路由器，外部Choke路由器，Internet边界路由器，Transit，防火墙，用于联接数据包分析器的Network TAP。网络负载均衡器放在了聚合层。另外还有一个专用的OOB接入层，用于设备维护管理。

三层架构虽然容易部署、易于诊断，但是其已无法满足日益增长的云计算需求。三层架构面临的主要问题包括：低可扩展性、低容错性、内部服务器之间横截面带宽低、较高层超额使用（Oversubscription）、高层次的拓扑中使用的大型模块化交换机成本非常高。

我过去常采用以下这几个方法缓解三层架构中网络分离问题：
(1)、PVLAN: 专用VLAN，也称为端口隔离，是计算机网络中的一种技术，其中VLAN包含受限制的交换机端口，使得它们只能与给定的端口通信。这个常用于后端的NFS网络。
(2)、VRF虚拟化路由表，用于路径隔离。
(3)、GRE Tunnel。
(4)、使用一些Overlay network封装协议并结合一 *** 作系统虚似化实现网络分离。

Leaf-Spine网络架构解决了传统三层网络架构所面临的Oversubscription和内部服务器之间横截面带宽问题。Leaf-Spine网络架构在过去几年里已开始接管主要的云服务数据中心。Leaf-Spine结构也称为Clos结构，其中每个Leaf交换机（ToR交换机）以全网状拓扑连接到每个Spine交换机。这是一种两层的Fat-tree网络。这种架构中Leaf之间只有一个跳，最大限度地减少了任何延迟和瓶颈。Spine网络的扩展非常简单，只要在需增长的情况下逐步添加Spine交换机。

Leaf-Spine架构使用定制的寻址方案和路由算法，而非传统的STP。根据网络交换机中可用的功能，可以使用第2层或第3层技术实现Leaf-Spine网格。第3层的Leaf-Spine要求每个链路都被路由，并且通常使用开放最短路径优先（OSPF）或等价多路径路由（ ECMP ）来实现的边界网关协议（BGP）动态路由。第2层采用loop-free的以太网fabric技术，例如多链接透明互联（TRILL）或最短路径桥接（SPB, IEEE 8021aq）。其中，思科的FabricPath 和Brocade的Virtual Cluster Switching是基于TRILL发展而来的私有data plane。核心网络还可使用带有ECMP的动态路由协议通过第3层连接到主干网。华为、联想、Brocade、HP、 Extreme Networks等公司都有基于TRILL的产品或其它Leaf-Spine架构的解决方案。

Leaf-Spine结构的优点是：

(1)、使用所有链路互连，而不像传统网络中冗余链路被STP阻塞。
(2)、所有内部Leaf之间横向通信都是等距的，因此数据流延时时间是确定的。
(3)、Underlay的交换机配置和核心网络配置是固定的，因此变更Overlay Network的路由不需要更改核心网络。
(4)、产品安全区域能虚拟分离，扩展了VLAN和多租户安全性。
(5)、基础设施的物理网络可以和逻辑网络(Overlay network)分离。

Leaf-Spine结构也有些缺点，比如：

(1)、网络交换机的数量远远大于三层网络架构。
(2)、扩展新的Leaf时需要大量的线缆、并占用大量Spine交换机端口。
(3)、Spine交换机端口数量决定了最大可联接的Leaf交换机数量，也就决定了最大主机总数量。

下图是我参与过的一个公有云Leaf-Spine方案示意草图。

现代的数据中心部署中，我们一般将网络设备、服务器和机架在出厂时应模块化。对于使用Leaf-Spine 网络的数据中心，出厂时预装配成四种类型的标准工程系统：Transit 机柜, Spine 机柜, Fabric 机柜, 和 Server 机柜。Leaf 交换机和服务器一样被预装配于 Server 机柜，基本上做到开柜上电即可上线使用。

当下全球主流公有云基本上采用的都是Leaf-Spine 网络架构。然而，各家公有云服务商Leaf-Spine网络中的Underlay Network和Overlay Network使用的协议和方案有很大区别。比如，你可以基于Leaf-Spine架构使用VXLAN来设计你的SDN解决方案，也可以基于ECMP的BGP-labeled-unicast的underlay 网络，使用MPLS L3***s构建另一种多租户的数据中心SDN解决方案。

聊完了两种层数据中心网络架构，相信大家如有机会搭建新的网络时，应该知道如何选择您的网络架构方案了。

欢迎大家发表留言，谈谈你所熟悉的Leaf-Spine网络架构方案中，Underlay Network和Overlay Network使用的协议分别是什么。

参考资料：

(1)、 Building Multi tenant Data Centers with MPLS L3***s
(2)、 Cisco Data Center Spine-and-Leaf Architecture: Design Overview White Paper

---