专业的人说的很准确但是普通人难以理解，常常记不住，分不清，不专业的人往往又说的差点意思。无意间，笔者在领英上看到一个介绍SDN/NFV区别的公开文档，内容详实，简明扼要。 这里我将这个文档精彩的部分分享给大家。
开篇鸣谢：原作者是Riverbed的产品市场经理JustynaBak。
SDN的三个核心要点有三个：
- 将控制平面和数据平面分离，这是最核心的部分，现在经常提到的SDS其核心也是控制和转发分离，这是SDS设计重要原则之一，可见SDN是先于SDS的；
- SDN使用的都是商用化，通用的路由器和交换机，这是相对于专有的芯片，专有的架构，专有的设备而言的；
- 控制面可编程；
对应的NFV的三大关键点是：
- 将网络设备的功能从网络硬件中解耦出来；
- 将电信硬件设备从专用产品转为商业化产品；
- 数据平面可编程；
Inscrutable alphabet soup. Even the fully expanded terms are only slightly more digestible. But they’re not truly all that confusing: the underlying principles are elegant and illuminating.
Software Defined Networking (SDN) is an architecture—first defined circa 1995—that physically separates the network control plane (decisions about traffic flows) from the forwarding plane (moving chunks of data between points A and B). Practically this simply means controlling network hardware devices (think routers, switches, Wi-Fi access points) by using software that is physically hosted elsewhere (think an orchestrator or controller platform).
A SDN architecture provides numerous advantages: it abstracts (and simplifies) the entire network into a “single” entity, programmable from a distant orchestrator or management point; it enables the replication of changes to policies and decisions in the blink of an eye to every outreach of the network, independent of the location, number, configuration or distribution of network devices; it provides resilience if a node—or building, or city, or region, or country!—should go offline. A backhoe through a fiber-optic cable, power failures, hurricanes, earthquakes, and other catastrophes, small and large. SDN enables traffic flows to be securely rerouted and rebuilt via unaffected network paths. Building mobile networks, where things move around constantly, requires this concept—the control of a cellular connection must be independent from the specific cell tower (read: forwarding plane) that the current session is connected to in order to manage the session hand-off to the next cell tower—same thing for communicating devices moving between Wi-Fi access points.
Software-Defined Wide Area Network (SD-WAN) extends the SDN concept—first implemented in local area networks, typically data centers—and applies it to the WAN. SD-WAN achieves the same goals in the WAN that SDN achieved in data centers: simplified and central management and visibility; putting control into software that can be rapidly innovated and separating this from the forwarding hardware; making the installation, configuration, management and upgrades of large numbers of widely scattered branch offices simple, coherent and cost-effective; leveraging general-purpose commodity hardware to host “virtualized” functions.
SD-WAN applies a somewhat arms-length approach to SDN, primarily to allow smooth operation over the often considerable distances separating WAN devices. It is impractical to have a network device go down just because the central controller three thousand miles away is temporarily out of contact. SD-WAN mixes the best of both worlds: a central controller maintaining policies, configurations and priorities, combined with a level of local control by the network device. While the device acts on the most recent set of instructions from the controller, it also takes into consideration local conditions such as link performance and availability. This hybrid approach—distant control instructions colored with local judgment—allows the network device to be resilient, programmable, agile, as well as able to execute split-second decisions imperative to maintaining real-time traffic flows.
When determining the best SD-WAN solution for your company, there are some basic things you should test, such as scalability, failover, application performance and usability
Whenever I speak with companies starting to research SD-WANs, the question about testing invariably comes up. Like probably any enterprise device, SD-WANs are filled with features. And as with any major WAN acquisition, testing those features prior to purchase is incredibly important. SD-WAN vendors have their own nuances and strengths. You need to be sure those strengths align with your environment.
As an edge device, there’s very little in terms of packet processing that needs to be tested in an SD-WAN node. But that doesn’t mean SD-WAN node testing isn’t important. Here are some tips for what you can look for when running your proof of concept (POC) from my buddy DC Palter, CEO at network testing simulator company Apposite Technologies, and our experiences here at SD-WAN Experts.
One of the primary benefits of SD-WAN is being able to split traffic between expensive, dedicated links and lower-cost internet VPNs. Being able to differentiate mission-critical and latency- or jitter-sensitive traffic from less important or less time-sensitive traffic is key to success, but it isn’t easy to accomplish.
Each vendor has proprietary algorithms to determine which traffic should go over which link. Test these algorithms during your POC to ensure they work as expected and manually adjust as needed.
If you have a larger network, scalability will be an important consideration. Will the network be hub and spoke or full mesh. Full-mesh networks will require a more robust SD-WAN solution provider than smaller networks.
April 19, 2017
By Dave Van Everen
Mirantis Cloud Platform 1.0 is a distribution of OpenStack and Kubernetes that can orchestrate VMs, Containers and Bare Metal
SUNNYVALE, CA – April 19, 2017 – Mirantis, the managed open cloud company, today announced availability of a commercially-supported distribution of OpenStack and Kubernetes, delivered in a single, integrated package, and with a unique build-operate-transfer delivery model.
“Today, infrastructure consumption patterns are defined by the public cloud, where everything is API driven, managed and continuously delivered. Mirantis OpenStack, which featured Fuel as an installer, was the easiest OpenStack distribution to deploy, but every new version required a forklift upgrade,” said Boris Renski, Mirantis co-founder and CMO. “Mirantis Cloud Platform departs from the traditional installer-centric architecture and towards an operations-centric architecture, continuously delivered by either Mirantis or the customers’ DevOps team with zero downtime. Updates no longer happen once every 6-12 months, but are introduced in minor increments on a weekly basis. In the next five to ten years, all vendors in the space will either find a way to adapt to this pattern or they will disappear.”
Along with launching Mirantis Cloud Platform (MCP) 1.0, Mirantis is also first to introduce a unique delivery model for the platform. Unlike traditional vendors that sell software subscriptions, Mirantis will onboard customers to MCP through a build-operate-transfer delivery model. The company will operate an open cloud platform for customers for a period of at least twelve months with up to four nines SLA prior to off boarding the operational burden to customer’s team, if desired. The delivery model ensures that not just the software, but also the customer’s team and process are aligned with DevOps best practices.
Unlike any other solution in the industry, customers onboarded to MCP have an option to completely transfer the platform under their own management. Everything in MCP is based on popular open standards with no lock-in, making it possible for customers to break ties with Mirantis and run the platform independently should they choose to do so.
AT&T将容器视为其网络架构计划的“真正重大且重要的组成部分”，电信行业巨头AT&T实验室总裁兼首席技术官Andre Fuetsch表示，该运营商正在尝试将容器引入到业务中去。
Andre Fuetsch表示：“我们有一个非常强大且广泛的容器战略，不仅仅局限于核心网或核心网上的软件堆栈，该战略一直延伸到用户端的边缘，我们认为容器及其管理在未来是非常重要的。”
Andre Fuetsch表示虽然该运营商在使用不同的虚拟化平台来支持新服务的开发，但容器在一定程度上提高了该流程的敏捷性。他说：“虚拟机并不适合所有的情况，当用户查看网络的各个部分，用户需要速度、可靠性、冗余性，用户可以从容器中获得众多的优势。”
AT&T在容器上发力由来已久，但Fuetsch没有谈及任何AT&T选定的容器实时或提供商合作伙伴，只是表示AT&T正在与容器提供商进行合作。
AT&T首席战略官兼集团总裁John Donovan表示，容器是最近推出的开放网络自动化平台（ONAP）的第一个项目，ONAP项目是由ECOMP项目和Open-O项目合并而成。
AT&T秉承了一贯的开源原则，在容器的发展方式上也选择开源的方式。该运营商是Open Container Initiative（OCI）和Cloud Native Computing Foundation（CNCF）的早期成员。
CNCF近期将开源的容器网络接口（CNI）程序添加为托管项目，CNI平台的设计占地面积小，资源效率高。它对容器的网络连接到责任有限，当容器被删除时，它会删除分配的资源。
根据451 Research的数据，容器化趋势将从去年的7.62亿美元增长到2020年的近27亿美元。
451研究所的分析师格Greg Zwakman说：“我们从容器市场的研究中发现，供应商基于容器的广度和多样性的合作，将更好地支持其产品中的容器，容器软件增长的速度以及市场成熟的速度都在不断增长。”
我刚听说要去做 openstack 开发的时候，蛮激动的啊。虽然我不知道 openstack 是什么东西，但是我知道这个东西和云计算有关。云计算这东西，听着就高大上，各大互联网公司都有投人进去搞，所以大方向上是必须肯定的。于是我按捺不住了，想在自己的主机上部署 openstack，来体验下这个是什么东西。经过一顿折腾之后，终于在虚拟机里面用 devstack 把 openstack 给部署出来了（部署过程中，最坑的就是国内的防火墙）。
部署的过程，其实就是把一堆 python 包安装到主机系统的过程。openstack 有一个 python 包叫做 Dashboard，这个东西提供了一个 Web 界面，从那里我真正体验到了 openstack 是个啥。在 Dashboard 上创建一台虚拟机的过程蛮有趣的，这个过程涉及到的步骤，很多都和现实中安装电脑很像。
| Openstack | Real Life |
|---|---|
| 创建 ubuntu 镜像 | 使用 Ultraiso 刻录好一个 ubuntu 系统 的 U 盘 |
| 创建 provider 网络 | 叫电信的来给家里开通网络 |
| 创建 Instance 主机 | 买了一台主机，并用刚刚的 U 盘给它装好 Ubuntu 系统 |
| 启动 Instance 主机 | 把电信的网口插到主机网卡上 |
我在 Dashboard 创建了两台 Instance 主机，两台主机跑的好好的。就目前来说，这个效果和 VMware Workstation 软件就很像了，可以在一台物理机上，跑多虚拟主机。只不过 VMware Workstation 软件面向的是单台物理机，而 openstack 却可以 面对物理机集群 进行管理和虚拟化。当成百上千的物理机被 openstack 管理着，而终端使用用户只需要面对唯一的一个 Dashboard 界面，这个时候私有云的概念就体现出来了。
有了感性的认识后，再去 openstack 官网是什么定义自己的：
Open source software for creating private and public clouds.
OpenStack software controls large pools of compute, storage, and networking resources throughout a datacenter, managed through a dashboard or via the OpenStack API. OpenStack works with popular enterprise and open source technologies making it ideal for heterogeneous infrastructure.
Hundreds of the world’s largest brands rely on OpenStack to run their businesses every day, reducing costs and helping them move faster. OpenStack has a strong ecosystem, and users seeking commercial support can choose from different OpenStack-powered products and services in the Marketplace.
The software is built by a thriving community of developers, in collaboration with users, and is designed in the open at our Summits.
OpenStack 软件控制整个数据中心的大型计算，存储和网络资源，用户可以通过 Dashboard 或 OpenStack API 进行管理。就我理解，Openstack 更像是一个操作系统，一个强大的云计算操作系统。
目前我都是基于虚拟机来部署测试 Openstack，所以大家先去下载个 vmware workstation pro 12 以及 ubuntu server 镜像。
然后利用 vmware 新建一个 ubuntu server 的虚拟机实例，有一点要注意的是，我们需要给虚拟机分配两张网卡。一张显卡使用 NAT 模式，另一张使用 Host-only 模式。为什么需要新建两张显卡呢？我先给上面两张网卡命个名， NAT 模式的网卡叫 ens33，Host-only 模式的网卡叫 ens34。使用 DevStack 部署 Openstack 的时候，需要单独占用 ens33 这张网卡，并且部署过程中，系统有段时间无法通过 ens33 和外部通讯（也就是断网了）。但是我一般习惯在 Host 上通过 SSH 连接到虚拟机，由于 ens33 会存在掉线的情况，因此我需要一张额外的网卡保证 HOST 和 虚拟机 的网络连接保持通畅，这就是 ens34 网卡的由来。其实如果你放弃使用 SSH 的方式登陆虚拟机进行 Openstack 部署的话，你确实就只需要 ens33 一张网卡就好。
以下所有命令，都是在虚拟机实例上运行的。
首先去 github 上，下载一份 DevStack 源码，就放在 /home/ 目录下吧：1
root # git clone https://github.com/openstack-dev/devstack /home/devstack
然后，使用 DevStack 提供的脚本，新建一个 stack 的系统用户1
root # /home/devstack/tools/create-stack-user.sh
为什么要新建一个 stack 用户呢？因此用脚本新建的 stack 用户，是没有用户密码的。后续 DevStack 在部署 Openstack 会多次调用 sudo 命令，这个时候就不需要我们额外输入密码（实际上也不可能，鬼知道脚本什么时候要输入密码）。
设置 DevStack 源码的文件权限，保证 stack 用户能正常访问：1
root # chown -R stack:stack /home/devstack/
本文并未完全转载，具体内容依照学习进度而定，希望了解详细全文的童鞋，请移步至原文
The first time I heard about containers it was like – what? what’s that?
Is a container a process? What’s Docker? Are containers Docker? Help!
The word “container” doesn’t mean anything super precise. Basically there are a few new Linux kernel features (“namespaces” and “cgroups”) that let you isolate processes from each other. When you use those features, you call it “containers”.
Basically these features let you pretend you have something like a virtual machine, except it’s not a virtual machine at all, it’s just processes running in the same Linux kernel. Let’s dive in!
OpenStack Neutron ML2 Deep Dive
JUNO Neutron 中的 Plugin 和 Extension 介绍及加载机制