在过去几个博客我列出一些网络问题我预见未来云计算高峰。我列为五大领域的问题是:
- 带宽-有足够的吗?
- 网络安全——你真的相信SaaS供应商多少钱?
- QoS——你的意思是没有QoS在互联网上?
- IPv4空间——你可能能够使用RFC1918地址空间与云通信。
- ——我们如何获得数据路由到云呢?
尽管悲观的预测我给,不是所有的龙卷风和洪水。有修复这些问题。准备(现在)是关键。
首先,得到一些广域网加速你的网站和你的内部数据中心。雷竞技电脑网站即使你可能需要购买更多的带宽,你不能买到更少的WAN延迟将会更糟。广域网加速会减少你所需要的额外的带宽。云应用程序的用户体验会更好;大部分数据雷竞技电脑网站中心数据中心转移将完成得更快;你会有更好的能见度所有流量。从业务的角度来看,广域网加速应该被包括在任何业务云服务。它不应该是一个单独的ROI的理由,它应该包括云服务作为整体的一部分的商业理由。接下来,开始工作现在和你信息安全架构师和CISO开发云服务安全策略。研究、讨论和同意所有云服务的通用安全模型需要最多的时间。 Once you have that, you can develop network security templates to connect to cloud services. If it's Internet-based cloud services, you'll probably need VPNs and firewall rules based on the general policies you've already created. Don't forget other InfoSec services like logging, IDPS, and content controls. Game plan different types of connections to clouds including Internet and private WAN (MPLS) based connections. How would you handle each? How will traffic flow through appropriate security devices? Put yourself in the shoes of a cloud provider and think about what you would need from a single customer. I would argue you will have 90% of solution for a cloud service before you even buy a service. For QoS, WAN acceleration will help, but it's still not end-to-end QoS. If you're using the Internet to connect to the cloud, provide QoS for all cloud-destined traffic on your internal network. At least you will eliminate any QoS problems on your internal network. Next, if you can make the routing work properly and the costs are justified, buy dedicated Internet circuits for the cloud traffic. Since the Internet bottleneck is often the local access circuit, eliminating all non-cloud traffic on that circuit (YouTube, Facebook, etc) will help. Finally, check with the cloud provider to see if they have preferred relationships will certain ISPs. Some ISPs will provide basic QoS on their Internet backbone provided the traffic never leaves their Internet backbone. If your cloud provider has an Internet circuit to ISP X, and ISP X offers basic Internet QoS, buy a dedicated Internet circuit from ISP X. If the cloud is internal (maybe off your MPLS network), then you can have end-to-end QoS. The problem here will be aligning QoS policies. Start brainstorming ways to map your QoS policies into more basic QoS policies.关注DSCP RFC标准使用。这样你准备支持无论QoS模型云提供商甚至如果不是你今天使用的精确匹配。对于IP空间,这是使用IPv6的机会,但也不尽然。不可能99%的企业已经准备好使用IPv6只与一个云提供商。你需要IPv4。但是,使用IPv6。IPv4/6双堆栈应该与任何标准服务集的一部分新云提供商。这将让你的脚湿与IPv6,让你的应用程序团队用来支持IPv6的想法,和准备你离开IPv4(也许有一天)。就目前而言,你会需要更多的公共IPv4空间。如果你缺乏自由的地址空间,努力夺回空间。 For example, you probably have your Internet router IP addresses configured with public IPv4 addresses (like loopbacks). Why? They can be private. The only thing that needs to be public on Internet routers is the interface to the ISPs. Make every effort to save and recapture public IPs. Be careful using space from ISPs since you will be tied to their Internet service, but it may be necessary. Use more NAT for inbound applications that are in your DMZ instead of directly accessible public IPv4 addresses. Saving public IPv4 space should be a call-to-arms for your networking team. Finally, routing. To make it succinct - everything (EVERYTHING!) needs to be dynamic, probably with BGP. If your routing protocol design stinks (don't lie to yourself), start fixing it now. There will be no room for poor OSPF design, unsummarized EIGRP, bad redistribution, or no written BGP policy. You won't be able to log into a cloud provider's core router and add a static route to fix a pesky routing problem. It's going to be a problem that can't be fixed because your routing protocol design is bad and some obnoxious, smart-ass network engineer from the cloud provider is going to call you on it. Now you'll be found out and have to explain to the CIO why this problem hasn't been fixed in your 4+ years with the company. Ouch! As a network engineer, I would make this topic #1 to work on to prepare for clouds.
看,现在感觉好多了,不是吗?现在有点阳光,湿度低,有凉爽的微风。现在跳过所有,天气好,呆在室内,并开始准备云。
更多的从野外>博客条目:
去思科子网思科的新闻,博客,论坛,安全警报,赠书,等等。