SD-WAN架构应该使用POP点吗?
目前市场上有多种SD-WAN可供选择。其中一个区别在于架构中是否存在供应商托管的流量处理组件。如果没有供应商托管业务处理SD-WAN组件的供应商,则业务所拥有的设备或现有网络应该处理所有流量。如果有供应商提供某些流量处理组件的托管,例如在云访问接入点(POP)中,供应商拥有的设备负责处理某些流量。虽然从表面上看是一个微不足道的环节,但必须考虑几个细微之处。了解SD-WAN解决方案所需的架构,可以实现SD-WAN解决方案的全部优势。
POP在电信架构中很常见,尤其是电信公司提供的SD-WAN解决方案。如果提供商将它们放置在终点站点的1到2跳内的所有区域中,则这将是有利的。但是,即使在大多数POP所在的Metro区域,仍然必须处理聚合层的超额订阅,以及由于上游提供商对等而导致的低效路由。
不幸,POP会将您的解决方案聚合到提供商或供应商的主干上,该骨干通常是与多个客户一起使用的共享MPLS网络,跨共享基础架构的任何聚合都可能导致基础网络超额预订,网络通信不安全,完全忽略POP SD-WAN设备中的QoS,或者可能无法在同一客户的流之间正确使用优先级。更糟糕的是,来自不同客户的流,简而言之,您的流量来自同一链路和相同SD-WAN设备上的其他客户的流量。从性能的角度来看,这提出了“当出现拥塞时,我会比其他客户获得更好的性能吗?”以及“如果我拥有该设备,其他客户的活动会影响我预期的性能吗?”
此问题进一步复杂化,包含供应商托管POP的SD-WAN解决方案可能会产生法律和合规性问题。大多数企业都会处理某种监管,论是来自支付处理,医疗保健,联邦/州/地方法律还是其他,而且WAN本身通常都在严格审查以满足某些要求。这些企业必须考虑POP本身是否存在潜在的合规性违规,无论供应商是否可以访问SD-WAN设备上的无线数据甚至内存中的未加密数据,以及这些系统和网络的相对安全性的附件条件。即使这些系统和网络是安全的,它们也会扩展合规范围和评估,***测试和漏洞管理的表面区域,这会增加组织流程的时间和成本。
- 使用 SDWebImage 应该在 AppDelegate 写的代码
- SD-WAN架构的基本要素:优势和选择
- Cisco SD-WAN (Viptela) 架构和组件(简介)
- kubernetes如何要使用用户名和密码登陆harbor以拉取docker镜像,应该如何操作?
- 应不应该使用存储过程的几个要点
- 使用visio绘制企业动静分离企业架构
- Android开发者应该使用FlatBuffers替代JSON?
- atitit.架构设计---方法调用结果使用异常还是返回值
- SSD“大忌”:什么时候不应该使用SSD
- REST应该放弃使用http头GET、POST、PUT和DELETE来表达操作
- 使用ListView应该注意的地方
- 使用(function() {}).call(this);包裹代码有什么好处,什么时候应该这样做?
- 每个程序员都应该学习使用python或ruby
- Springmvc 使用Restful架构(五)
- Android 使用log4j 保存log日志信息至sdcard中
- PHP程序员应该使用的10个组件
- 使用Apworks开发基于CQRS架构的应用程序(八):应用程序的配置与编译
- 使用Axure制作App原型应该怎样设置尺寸?
- 先读懂CapsNet架构然后用TensorFlow实现,这应该是最详细的教程了
- 使用ThinkPHP应该掌握的调试手段