负载均衡基础知识（2）

二、四层和七层负载均衡的区别？ 2.1 - 技术原理上的区别。 　所谓四层负载均衡，也就是主要通过报文中的目标地址和端口，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。   　以常见的TCP为例，负载均衡设备在接收到第一个来自客户端的SYN 请求时，即通过上述方式选择一个最佳的服务器，并对报文中目标IP地址进行修改(改为后端服务器IP），直接转发给该服务器。TCP的连接建立，即三次握手是客户端和服务器直接建立的，负载均衡设备只是起到一个类似路由器的转发动作。在某些部署情况下，为保证服务器回包可以正确返回给负载均衡设备，在转发报文的同时可能还会对报文原来的源地址进行修改。       　所谓七层负载均衡，也称为“内容交换”，也就是主要通过报文中的真正有意义的应用层内容，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。   　以常见的TCP为例，负载均衡设备如果要根据真正的应用层内容再选择服务器，只能先代理最终的服务器和客户端建立连接(三次握手)后，才可能接受到客户端发送的真正应用层内容的报文，然后再根据该报文中的特定字段，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。   　负载均衡设备在这种情况下，更类似于一个代理服务器。负载均衡和前端的客户端以及后端的服务器会分别建立TCP连接。所以从这个技术原理上来看，七层负载均衡明显的对负载均衡设备的要求更高，处理七层的能力也必然会低于四层模式的部署方式。那么，为什么还需要七层负载均衡呢？

负载均衡基础知识（3）

负载均衡设备 2.2 - 应用场景的需求。 　七层应用负载的好处，是使得整个网络更"智能化", 参考我们之前的另外一篇专门针对HTTP应用的优化的介绍，就可以基本上了解这种方式的优势所在。例如访问一个网站的用户流量，可以通过七层的方式，将对图片类的请求转发到特定的图片服务器并可以使用缓存技术；将对文字类的请求可以转发到特定的文字服务器并可以使用压缩技术。   　当然这只是七层应用的一个小案例，从技术原理上，这种方式可以对客户端的请求和服务器的响应进行任意意义上的修改，极大的提升了应用系统在网络层的灵活性。很多在后台，(例如Nginx或者Apache)上部署的功能可以前移到负载均衡设备上，例如客户请求中的Header重写，服务器响应中的关键字过滤或者内容插入等功能。   　另外一个常常被提到功能就是安全性。网络中最常见的SYN Flood攻击，即黑客控制众多源客户端，使用虚假IP地址对同一目标发送SYN攻击，通常这种攻击会大量发送SYN报文，耗尽服务器上的相关资源，以达到Denial of Service(DoS)的目的。   　从技术原理上也可以看出，四层模式下这些SYN攻击都会被转发到后端的服务器上；而七层模式下这些SYN攻击自然在负载均衡设备上就截止，不会影响后台服务器的正常运营。另外负载均衡设备可以在七层层面设定多种策略，过滤特定报文，例如SQL Injection等应用层面的特定攻击手段，从应用层面进一步提高系统整体安全。   　现在的7层负载均衡，主要还是着重于应用广泛的HTTP协议，所以其应用范围主要是众多的网站或者内部信息平台等基于B/S开发的系统。 4层负载均衡则对应其他TCP应用，例如基于C/S开发的ERP等系统。   2.3 - 七层应用需要考虑的问题。 是否真的必要，七层应用的确可以提高流量智能化，同时必不可免的带来设备配置复杂，负载均衡压力增高以及故障排查上的复杂性等问题。在设计系统时需要考虑四层七层同时应用的混杂情况。   是否真的可以提高安全性。例如SYN Flood攻击，七层模式的确将这些流量从服务器屏蔽，但负载均衡设备本身要有强大的抗DDoS能力，否则即使服务器正常而作为中枢调度的负载均衡设备故障也会导致整个应用的崩溃。   是否有足够的灵活度。七层应用的优势是可以让整个应用的流量智能化，但是负载均衡设备需要提供完善的七层功能，满足客户根据不同情况的基于应用的调度。最简单的一个考核就是能否取代后台Nginx或者Apache等服务器上的调度功能。能够提供一个七层应用开发接口的负载均衡设备，可以让客户根据需求任意设定功能，才真正有可能提供强大的灵活性和智能性。

虚拟化安全威胁

虚拟化安全威胁 随着大数据、云平台的热潮席卷全球，大多数企业正在实施或者已经完成虚拟化，将传统硬件服务器系统迁移到虚拟化平台中，逐步向虚拟化方向迈进。 任何新业务的部署都会引入新的风险，因此，对于当前虚拟化大集中平台，安全风险不仅包含传统硬件架构中的风险，还会有因虚拟化引入的新的安全风险。本文主要讲解虚拟化后带来的新的安全风险。 Hypervisor安全威胁 在CVE的数据库中，虚拟化软件的漏洞累计超过超过700条，其中主要是vmware系统的。作为虚拟机的底层系统，一旦存在漏洞，将危及运行其上的所有虚拟机。 网络虚拟化安全威胁 虚拟化后，同一物理服务器上的不同虚拟机间可能通过硬件背板而不是网络进行通讯，因此这些通讯流量对标准的网络安全控制来说是不可见的，无法对它们进行监控或内嵌封堵。内嵌虚拟设备可以解决这个问题;另一个解决途径是硬件辅助虚拟化(Hardware AssistedVirtualization)，它需要与Hypervisor和虚拟化管理框架进行API级别的整合。 当一个可疑的虚拟机迁移进信任区域，在传统以网络为基础的安全控制措施下，将无法检测到它的不当行为。在每个虚拟机上安装全套的安全工具，是添加保护层的另一途径。 存储虚拟化安全威胁 虚拟化后，多租户对同一存储区域都有访问权。 租户数据迁移后，原磁盘释放给其他租户使用，原有数据未被彻底清除的话，也可能被新租户获取。 虚拟机镜像文件在休眠时是数据文件形式存数的，有被修改的风险。 对内存/存储清零或者对全部数据加密是此问题的解决方案。加密密钥应当存储在虚拟环境以外的一个基于策略的密钥服务器上。此外，如果没有使用加密或恰当的数据擦洗，虚拟机在运行的状态下迁移，自身可能面临风险。 网络边界模糊安全威胁 虚拟化后，一个物理接口上配置的不同网络的虚拟接口，逻辑网络间无明显边界，同一个租户可以运行在同一个物理机上，传统架构中的网络物理边界消失，只能通过逻辑域划分界定边界，虚拟化环境中，防火墙做逻辑隔离，内部通过虚拟交换机和VlAN标记等方式来界定防火墙保护特定的区域，以弥补防火墙在物理位置上不能清楚的体现的缺陷。 特权用户安全威胁 虚拟化环境下，除了租户可以访问自己的数据外，管理员由于需要对资源进行管理，因此也可以接触数据，SaaS提供商可能会利用其它PaaS、IaaS的服务，因此也可能会有特权用户，从而可能造成数据泄露、损坏或被修改。因此必须控制好权限分配，以防止操作不当或恶意删除等安全威胁。 总之，同其它任何新技术一样，虚拟化安全有自己的安全挑战。既不能认为虚拟化后的安全同传统架构的安全大同小异，也不能认为虚拟化后的安全不能保证，只有采取适当的安全解决方案后，虚拟化网络的安全仍然是可以保证的。

SD-WAN行业理解（2）

SD-WAN行业动态     之前提到，SD-WAN作为一种生产方式的变迁，会有自己的演化趋势，甚至很难预测。所以，通过行业动态，来揣测一下趋势，可能会有更多人关心。       1 生态加速整合   1.1 通过并购整合       Cisco收Meraki、Viptela，因为Cisco原本就有自己的iWAN产品，有自己的安全产品，所以可以整合的内容就比较多了，包括SD-Branch产品，SASE产品，这里就说一下更加宏观层面的整合：Cisco把自己的网络功能软件化，推出了“数字网络架构（DNA，Digital Network Architecture）”的概念，把自己的网络功能整合成了DNA for Wireless，DNA for Switch，DNA for SD-WAN三大类，进而进一步构建自己的“基于意图网络（Intend Based Network，IBN）”。       Vmware收Velocloud，可以看做计算虚拟化和SD-WAN结合，在虚拟化层面推云网融合。Dell EMC有一个和Vmware合作的边缘网关系列，也可以侧面说明这种整合的价值。       Oracle收Talari，可以看做是一个小型IaaS，中型SaaS厂商跟SD-WAN结合，在云服务层面推云网融合。       HPE收Silver Peak，可以看做SD-LAN（HPE的Aruba）跟SD-WAN结合，整合SD-Branch产品。之前提到，Branch里的设备实在太多了，SD-Branch可以成为一个可以想象的未来。       PAN收CloudGenix，可以看做云安全厂商跟SD-WAN结合，整合SASE产品。       Juniper收128 Technology，可以看做AI产品（Mist AI）跟SD-WAN结合，整合AI Driven Enterprise产品。       4.1.2 通过合作整合       云厂商的生态位最好，几乎所有人都想着跟云厂商合作，尤其是和SaaS厂商合作，近期比较典型的是Aryaka相继和微软、阿里达成战略合作，这样Aryaka也补齐了四大IaaS厂商的全部合作。       运营商和设备商也在加速合作，最为典型的是北美的前两大运营商和前两大SD-WAN厂商宣布达成战略合作：Verizon和Cisco；AT&T和Vmware。       2 面向未来布局   2.1 孵化未来应用       既然SD-WAN是一种服务应用的广域网，那么就需要开始面向未来的应用布局，未来有哪些可以预见的应用：5G、IoT、边缘计算。       Verizon和Cisco、AT&T和Vmware之间的战略合作，就是在孵化IoT应用。SD-WAN和IoT的契合点：       敏捷：IoT感知层的本质作用是将现实世界数字化，这些数字化大多发生在边缘，而边缘如果需要形成智能的决策，需要将边缘形成的大量数据，连接到近端（边缘计算）或远端（云计算）进行处理，所以IoT的业务类型，天然决定了它需要非常灵活的部署方式。   安全：IoT设备自身的性能较弱，外加数量庞大，需要网络层面支持灵活的基于身份的安全性。   性能：不同IoT业务的性能要求不同，会有做应用分流、应用调度、应用保障的需要。   可视化：IoT存在海量的设备需要管理和维护，统一的可视化平台，是一个必不可少的手段。       云厂商也在为未来应用布局，AWS推出Wavelength Zone，直接进运营商机房，孵化5G MEC应用。SD-WAN和边缘计算的契合点：       敏捷：大体与IoT类似。   安全：边缘计算的场景相对会更加复杂，不但需要连接到现场，还需要与其它边缘节点协同，边云协同，即所谓的ECI（Edge Computing Interconnect）网络，这部分也是需要适配不同业务，在公共基础设施之上，形成非常敏捷的动态连接，也对安全性有很强的需求。   性能：大体与IoT类似。   统一架构：边缘计算相比云计算，一个很大的优势是在数据发生地，或者事件发生地就近处理，这种业务天然就需要比较扁平的计算架构，这种扁平的计算架构和SD-WAN这种较为扁平的网络架构，可以统一考虑。       2.2 边缘下沉       AWS Wavelength Zone进运营商机房，属于5G中的MEC（Multi-access Edge Computing）场景，属于边缘计算中的云边缘形态（云延伸）。当然，运营商也有可能在合作过程中探索发展自己的边缘云形态（节点云化）。顺便说明一下，部分人员可能会觉得为什么把这归属到SD-WAN分析中？AWS没说Wavelength在做SD-WAN。这是因为这属于边缘计算互联网络（Edge Computing Interconnect，ECI）领域，其中的热点之一就是如何用SD-WAN和SRv6等解决其中面临的挑战。       除了云厂商在设法下沉之外，设备商也在设法下沉，一般是边缘网关形态（设备云化）。例如：Cisco收Meraki，HPE收Silver Peak，都是在推SD-Branch，将入口下沉到LAN；之前提到，Dell EMC也有一个和Vmware合作的边缘网关系列。