Showing posts with label NFV. Show all posts
Showing posts with label NFV. Show all posts

Sunday, October 25, 2015

Things good to know before the OpenStack Tokyo Summit.

OpenStack has a 6 months release cycle and each release is given a name in which the name is associated to the location where OpenStack Summit was held and follow the sequence of the English alphabet.  The 12th OpenStack release has the name Liberty and is officially available on Oct 15, 2015.

OpenStack Summit Tokyo will be held on Oct 27 - Oct 30 in Tokyo Japan.  On this weekend, a large portion of the OpenStack community is heading to Tokyo with excitement.  Even I am not able to attend this summit in Japan, I am excited to see what new technology innovation will be announced as well as the future direction of OpenStack.  (Note: OpenStack summit actually has 2 parts.  One part is the conference and the other part is the design summit where the open source community gather together to discuss and to shape the direction and/or feature of the next OpenStack release).

What's new in the Liberty release?

Liberty is the first release with the "Big Tent" approach.

Over the weekend, I have a chance to take a look at what's new in the Liberty release.  The most comprehensive and detail description of what's new in the Liberty is of course the release note from OpenStack.  If this is too detailed then Nick Chase (@NickChase) has an good article on the 53 things that are new in Liberty.  Also OpenStack has a very informative web page that describes the Liberty release.  There are 5 categories listed on this page as new features in Liberty:
  1. Enhanced Manageability
  2. Simplified Scalability
  3. Extensibility to Support New Technologies
  4. Container Management
  5. Orchestration
The categories are all self explanatory.  It is, however, interesting to see that container management is by a category by itself and is not under extensibility to support new technologies. 

In this post let me highlight a few things that interest me the most.

Most Useful

For me the new interface to display network topology - Curvature Network Topology interface in Horizon is the most useful to visual how the network looks like.  A sample display of this new interface is:
image source: https://www.openstack.org/software/liberty/

Hot Trend

There are 2 topics that are widely discussed in the IT industry and these 2 hot technologies are opening up new use cases and to help consumer either to save money or to deploy the services faster and easier.  These 2 hot trends are:
  1. Docker container
  2. NFV
OpenStack provide a natural infrastructures for these 2 technologies as well as a platform to bring out the essence or core features.

Docker Container

Docker containers need an orchestration engine to make it powerful and there are Docker Swarm, Kubernetes, CoreOS fleet that builds on etcd and systemd as well as Mesos.

In the OpenStack Vancouver summit there is a one day special track on container in which there is Project Magnum which was initially to work with Kubernetes in OpenStack and now the Container Orchestration Engine (COE) in Magnum is expanded to Docker Swarm and Mesos.

In July Google joined the OpenStack Foundation should be able to bring in their expertise on container and Kubernetes to the Magnum project.  I have a blog post on this subject. Also, the introduction of libnetwork brings new networking options to Docker container.

There are 2 new projects related to Docker Containers in the Liberty release:

NFV

The service provider industry is embracing NFV because it provides agility and huge cost saving advantages.  AT&T is said to have saved big on capex with NFV. There is the OPNFV project that is driving the advancement of open source NFV functionality and stability.

Both VMware announced vCloud NFV in VMworld Europe 2015.  Cisco also has it NFV offering.

Similar to Docker Container, NFV needs an infrastructure and OpenStack is a able to provide this need.

Interestingly, the effort of NFV in OpenStack is under the Nova project instead of Neutron as one might think.

Security

Role Based Access Control (RBAC) is added to both Heat and Neutron to provide better security on resource management and usage.

Security is essential to all projects and if OpenStack wanted to break into the enterprise market, security is an important element that needs to be addressed.  OpenStack already has a security group to handle security related issue in OpenStack.  Any bug fix that checked in has a SecImpact keyword to flag the OpenStack security group to look at potential security risk that is introduced in the code checkin.  There is also Project Bandit that can check for security issues in Python code in which OpenStack is written in.

Looking Ahead

I am excited to listen to the keynote and the YouTube recording of the various presentations from the OpenStack Tokyo summit. 

It will be interesting to see the future direction of OpenStack as decided by the community at the OpenStack Design Summit.

Another thing that I am looking forward to is to visit Japan and to try out the local ramen and the beer. 
image source: Gary Kevorkian of Cisco when he is at the OpenStack Tokyo Summit.


Tuesday, November 18, 2014

OpenStack Series: Part 18 – Network Function Virtualization in OpenStack

NFV (Network Function Virtualization) is gaining traction these days both in the enterprise and in the carrier market.  The main driving force is NFV's ability to reduce CAPEX and OPEX by moving the the network function from purpose-built, expensive and sometimes under utilized hardware to software that can be run in a virtualized form (virtual machine or Linux container).

Open Platform NFV - OPNFV
The Linux Foundation announced the formation of the Open Platform NFV project whose goal is to focused on accelerating the evolution of Network Functions Virtualization (NFV). OPNFV will establish a carrier-grade, integrated, open source reference platform that industry peers will build together to advance the evolution of NFV and to ensure consistency, performance and interoperability among multiple open source components.  

Open Source for NFV is a key element for better integration with the other already blooming open source projects such as OpenDayLight, OpenStack and CloudStack as well as no need for vendor lock-in with hardware and support contract.

Akanda

On Nov 3, 2014, DreamHost announced launching a new company called Akanda specializing in network virtualization technology.  DreamHost had been using the NFV on their OpenStack platform for over a year in production before spinning out this new company.  Here is a nice write up on Akanda.  According to this article: "Akanda NFV implementation provides OpenStack integrated L3 network virtualization on a VMware NSX L2 overlay. It interfaces with the OpenStack Neutron REST APIs and includes a sophisticated management and orchestration platform to monitor, configure, and manage virtualized routers. In the future, Akanda will be extended to virtualize additional network functions, including load balancing and firewalls, and will feature pluggable backends to alternative L2 overlays."

image source: http://www.convergedigest.com/2014/11/akanda-debuts-open-source-nfv-platform.html

Network Function in a Container

Also as indicated on one of my previous blog post on "Networking options for Dockers" that one networking option for Docket is SDN and there is a new company called SocketPlane bringing SDN into Docker and this will open up ways  using a container for NFV or in this case NFD (Network Function Dockerization) <- a new name that I come up with based on the word "Dockerize".  

When we go to SocketPlane's website we will see "Native to Docker", "Familiar to NetOps" and "Application Friendly".  I think this 3 phases summarize the product direction that this company is heading.  One more thing to note is that the founders of this startup are all veterans of the OpenDayLight projects along with former executive from OpsCode/Chef.

A lots of efforts are being put into integrating containers to work on OpenStack especially in the area of container orchestration where OpenStack Heat can fill in the void. This provides good opportunity for Network Function to be dockerize and being deployed in OpenStack. 

Container orchestration is an important area for container to be deployed in any cloud environment.  In Amazon Web Services Re:Invent, AWS announced EC2 Container Service in addition to its Docker support in AWS Elastic BeanStalk.

When the orchestration puzzle for container is solve, putting network function in a container can provide more cost saving than putting the networking function on a virtual machine.  It can also provide better CAPEX and operational efficiency because of leaner resource utilization.

OpenStack and NFV
In the OpenStack Juno release NFV features are added to Nova to lay the groundwork for large scale providers to further abstract networking capabilities.  A sub team is formed under the Neutron and I think the feature developed under this sub team will be introduce in the Kilo release.

Service provider is looking for a open platform to deliver their services and we can see this trend by the forming of the Open Platform NFV.

OpenStack and NFV is an attractive combination because with the orchestration power of OpenStack NFV is made more powerful to deliver the virtualized network function in a quicker and automated manner.

A lots of works still needs to be done for NFV in OpenStack.

In the press release for the Juno release from OpenStack, the work done is to lay a foundation for OpenStack to be the platform for NFV deployment.  It also mentioned that: NFV represents a massive shift in how networking and telco services are developed and deployed. An NFV development team was formed in May at the OpenStack Summit and has identified nine use cases to run NFV workloads on top of OpenStack environments. Initial features arrived in the Juno release, and additional NFV-related work will continue over coming releases.
The OpenStack NFV development team has put together a good wiki page with a very comprehensive description of OpenStack and NFV including mission statement, definition of NFV, who are working on this project as well as some use cases for NFV in OpenStack.

APIs for NFV in OpenStack
On important and yet not so easy job is to define the APIs for NFV in OpenStack.  The main idea for the API for abstraction and yet user of the API will have to provide the detail parameters for deploying NFV based on individual customer's need.

How do we strike the balance between abstraction and the necessity of providing ability to tune the system by changing parameters?

OpenStack Carrier-grade NFV requirement
At this time the integration of NFV in OpenStack is geared toward Service Providers.  There seems to be more use cases for NFV in the Telco space. There are 3 requirements that is specific to carrier-grade NFV (not just for OpenStack):
  • Performance
  • Deterministic
  • Reliability
I work for the enterprise division of Alcatel-Lucent and I can see that carrier-grade does demand more in these 3 areas.  Workload for one customer may not be very high but for service providers they have a lots of average workload customer plus the service providers have to maintain the service according to the SLA (Service Level Agreement).

To satisfy the carrier-grade requirement, the OpenStack development team is working on the following technologies to make sure the OpenStack infrastructure can deliver the best "horse power" or near native performance from the underneath hardware:

SR-IOV (Single Root I/O Virtualization)
  • A PCI-SIG standard to provide native I/O virtualization to PCI Express devices.
  • Good article on this subject here, here and here.
DPDK (Data Plane Development Kit)
  • a set of software libraries and Ethernet drivers (native and virtualized) that run in Linux user space to boost packet processing throughput on Intel® architecture.
  • Works with Intel processors only.
NUMA and L3 Cache 
  • Pinning a vCPU to a physical cpu of a multi-socket processor can help access the processor's local memory (L3 Cache) and thus boosting the processing speed.
Large Page Table size
  • Larger page table size can help the VM running as NFV to keep the data in memory instead of fetching them from storage.
Big Potential for 2015
I am only touching the surface of this subject and there are lot more to it.  In the month of November 2014 both Juniper and Alcatel-Lucent announced that they are offering virtualized high end/performance router catching up with Cisco and Brocade's Vyatta Router for NFV.  Seems like the year of 2015 we will see hot competition in the carrier market NFV platform.

Again, will blog about this again since networking and security is my main subject of interest.

Related Post:
OpenStack Series Part 1: How do you look at OpenStack?
OpenStack Series Part 2: What's new in the Juno Release?
OpenStack Series Part 3: Keystone - Identity Service
OpenStack Series Part 4: Nova - Compute Service
OpenStack Series Part 5: Glance - Image Service
OpenStack Series Part 6: Cinder - Block Storage Service
OpenStack Series Part 7: Swift - Object Storage Service
OpenStack Series Part 8: Neutron - Networking Service
OpenStack Series Part 9: Horizon - a Web Based UI Service
OpenStack Series Part 10: Heat - Orchestration Service
OpenStack Series Part 11: Ceilometer - Monitoring and Metering Service
OpenStack Series Part 12: Trove - Database Service
OpenStack Series Part 13: Docker in OpenStack
OpenStack Series Part 14: Sahara - Data Processing Service
OpenStack Series part 15: Messaging and Queuing System in OpenStack
OpenStack Series Part 16: Ceph in OpenStack

OpenStack Series Part 17: Congress - Policy Service 
OpenStack Series Part 19: Storage Polices for Object Storage
OpenStack Series Part 20: Group-based Policy for Neutron

Reference:
"About." Home. N.p., n.d. Web. 03 Nov. 2014.
"OpenStackĂ‚® Juno Release Available Today." Press Release » OpenStack Open Source Cloud Computing Software. N.p., n.d. Web. 05 Nov. 2014.
"01.org." IntelĂ‚® DPDK. N.p., n.d. Web. 05 Nov. 2014.
"Q: What Is SR-IOV?" Windows IT Pro. N.p., n.d. Web. 05 Nov. 2014. 
cdn-static.zdnet.com/i/r/story/70/00/034207/opnfv-400x260.png 
"Akanda Debuts Open Source NFV Platform ~ Converge! Network Digest." Akanda Debuts Open Source NFV Platform ~ Converge! Network Digest. N.p., n.d. Web. 17 Nov. 2014.

Thursday, November 13, 2014

OpenStack Series: Part 13 - Docker in OpenStack

Often time there is the notion that with Docker, the Linux Container technology is going to replace server virtualization.  The reasoning for this thought is that with Linux Container virtualize application on the operating system level in which the hypervisor is no longer needed. 

Another camp of thought is that container does not have the robustness and enterprise ready feature such as resource allocation management, high availability or even manageability that can be offered by VMware.

I have an article that mention combining the container technology and hypervisor is the best of both world and this is why VMware is embracing this technology with project Fargo.

Docker, Inc is the company behind the open source Docker platform.

Docker is an orchestration or packaging tool that allows applications and their dependencies to run on container technology.  

Docker is also being deploy in OpenStack Nova as a form of hypervisor type.  It was introduced in the Havana release but is being left out for the main development tree and due to popularity of Docker it will be updated and introduce back to to the main project in the Kilo release.  I think a lot more development effects will be put in to integrating Docker into OpenStack and make it a powerful tool for the enterprise IT.  There are talks about putting SDN into Docker which lead to the possibility of putting Network Function Virtualization into a container instead of a full blow virtual machine - NFD (Network Function Dockerization) <- a new name that I come up with based on the word "Dockerize"

OpenStack documentation outlines the advantages of using docker in an OpenStack Infrastructure:

Docker takes advantage of containers and filesystem technologies in a high-level which are not generic enough to be managed by libvirt.
  • Process-level API: Docker can collect the standard outputs and inputs of the process running in each container for logging or direct interaction, it allows blocking on a container until it exits, setting its environment, and other process-oriented primitives which don’t fit well in libvirt’s abstraction.
  • Advanced change control at the filesystem level: Every change made on the filesystem is managed through a set of layers which can be snapshotted, rolled back, diff-ed etc.
  • Image portability: The state of any Docker container can be optionally committed as an image and shared through a central image registry. Docker images are designed to be portable across infrastructures, so they are a great building block for hybrid cloud scenarios.
  • Build facility: Docker can automate the assembly of a container from an application’s source code. This gives developers an easy way to deploy payloads to an OpenStack cluster as part of their development workflow.
Currently Docker is in two of the OpenStack projects - Nova and Heat

Docker in OpenStack Nova
Docker is not a hypervisor but in Nova it is considered as a hypervisor type.  Docker is listed as a Group C hypervisor which means not much testing is done with the driver.  I think this will be changed in the Kilo release.

The Docker drive in Nova is basically a HTTP client that passes RESTful API into Docker.  This drive will load the Docker image from OpenStack Glance and load the image into the Docker filesystem.  Older version of this Docker drive needs a private docker-registery which in turns proxy to Glance but this is no longer necessary. (I have an article that talks about Docker image, register).

image source: https://wiki.openstack.org/wiki/File:Docker-under-the-hood.png

Docker in OpenStack Heat

While Docker is an orchestration tool for containers, Heat in turn talks to Docker for container deployment.

image source: https://raw.githubusercontent.com/MarouenMechtri/Docker-containers-deployment-with-OpenStack-Heat/master/images/docker-plugin.jpg

Scott Lowe (@scott_lowe) had 2 great articles on Heat template for Dockers here and here with reference link to another post of his on OpenStack Heat. If you want a quick overview of OpenStack Heat, I have one article on this subject in my OpenStack series.

Docker + OpenStack = PaaS
I think one of the use case for using Docker in an OpenStack environment is to take advantage of the nice feature of Docker which is lightweight, fast provisioning and portable to build a Platform as a Service.  There are cases we need a mature hypervisor with all the build-in High Availability and Resource Scheduling features but in some case a container is the best way to go.  In fact OpenStack is actively working on High Availability in different parts of the infrastructure and in due time this will augment the Docker technology to be enterprise ready.

There is already a project - Solum to leverage OpenStack for application delivery. OpenStack has a page for Solum which talks about the goal, resource and FAQ of this project in the context of OpenStack.

Related Post:
OpenStack Series Part 1: How do you look at OpenStack?
OpenStack Series Part 2: What's new in the Juno Release?
OpenStack Series Part 3: Keystone - Identity Service
OpenStack Series Part 4: Nova - Compute Service
OpenStack Series Part 5: Glance - Image Service
OpenStack Series Part 6: Cinder - Block Storage Service
OpenStack Series Part 7: Swift - Object Storage Service
OpenStack Series Part 8: Neutron - Networking Service
OpenStack Series Part 9: Horizon - a Web Based UI Service
OpenStack Series Part 10: Heat - Orchestration Service
OpenStack Series Part 11: Ceilometer - Monitoring and Metering Service
OpenStack Series Part 12: Trove - Database Service
OpenStack Series Part 14: Sahara - Data Processing Service
OpenStack Series part 15: Messaging and Queuing System in OpenStack
OpenStack Series Part 16: Ceph in OpenStack
OpenStack Series Part 17: Congress - Policy Service
OpenStack Series Part 18: Network Function Virtualization in OpenStack
OpenStack Series Part 19: Storage Polices for Object Storage
OpenStack Series Part 20: Group-based Policy for Neutron

Reference:
"Docker." - OpenStack. N.p., n.d. Web. 29 Oct. 2014.

Saturday, August 23, 2014

Is VMware's NSX a SDN, NFV or NV?



Next week is VMworld 2014.  Two weeks ago, there was already a lot of traffic on the internet about this event.  People are waiting to see what new product VMware is going to introduce and how these product can help solve their business or technical problem at work. 

I believe vSphere 6 will be announced.  Both vSAN and VVol will be a hot topic.  Integration of Dockers and VMware will be another hot topic as people are saying Dockers will replace VMs and VMware will be saying otherwise.  

Many people also talk about sessions and hands on lab on NSX.  This got me to look in to what NSX is.

Acronyms
The title of this blog has lots of acronyms:
  • SDN – Software Defined Network
  • NFV – Network Function Virtualization
  • NV – Network Virtualization
  • NSX – just like ESX it is a VMware product name.  
If one is in the IT industry, one would have heard about these acronyms at some point and one can say what these acronyms is abbreviating.  But do we really understand what they really are.

SDN – Software Defined Networking
The acronym SDN is a widely used term.  When I type in “What is SDN” on my favorite search engine I got 36,300,000 hits.

Most articles defines SDN as an architecture that separate the network control plane from the forwarding plane in which the control plane is generally centralized.


NFV – Network Function Virtualization
Network Function Virtualization as the word suggested is the virtualization of network functions.  Virtualize means to abstract from the physical.  Network Function is often refers to Layer 4 to Layer 7 functions such as firewall, load balancer, DNS or IDS/IPS.  A quick reference of the OSI layer can be found here


Network Virtualization
Network virtualization is the abstraction of the physical network into logical segments with network overlay/tunneling technologies.  VXLAN, NVGRE and STT are good examples of network overlay technology.


Image source: http://www.cisco.com/c/dam/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-729383.doc/_jcr_content/renditions/white-paper-c11-729383-07.jpg

With VXLAN as the network overlay, tunnels are established between the VTEPs (VXLAN Tunnel End Point).

After reading all these, what is your answer to the title of this blog post: “Is VMware's NSX a SDN, NFV or NV?”

To me the answer is – VMware NSX is all three. While these are 3 distinct terms but they are interrelated.  All 3 technologies have the same purpose of solving the networking demand of the contemporary data center.

VMware NSX
NSX was officially announced last year at VMworld 2013.  During the announcement there is one presentation slide that caught the whole world’s attention (well part of the tech world may be).  This slide is the companies that support NSX.  Cisco was missing in that slide.  For a long time Cisco’s v1000 virtual switch is working in vSphere as the Distributed Virtual Switch option.  While VMware introduces NSX, a few months later Cisco announced Application Centric Infrastructure (ACI). These are 2 different approaches for solving problems in the contemporary data center.




This picture is from a blog by Brad Hedlund, engineering architect for VMware’s Networking and Security Business Unit (NSBU).  This is the best way to understand what NSX is - Just like how ESI virtualized the compute platform, NSX is to virtualize the network.

VMware has good articles to describe what NSX is here and here is and I am not going into the details of it in this post. 

VMware NSX comes with 2 flavors:

  • NSX for multi-hypervisor
  • NSX for vSphere

NSX can integrate with OpenStack. Scott Lowe has a nice blog series on NSX/NVP and this particular post talks about NSX and OpenStack integration

VMware NSX components
According to this article by Hatem Naguib there are 5 basic components for NSX:

  • Controller Cluster
  • Hypervisor vSwitches
  • Gateways
  • Ecosystem partners
  •  NSX Manager

Also, in another VMware document – the VMware NSX Data sheet, the key feature of NSX are

  •  Logical Switching – Reproduce the complete L2 and L3 switching functionality in a virtual environment, decoupled from underlying hardware
  • NSX Gateway – L2 gateway for seamless connection to physical workloads and legacy VLANs
  •  Logical Routing –Routing between logical switches, providing dynamic routing within different virtual networks.
  •  Logical Firewall –Distributed firewall, kernel enabled line rate performance, virtualization and identity aware, with activity monitoring 
  •  Logical Load Balancer – Full featured load balancer with SSL termination.
  •  Logical VPN – Site-to-Site & Remote Access VPN in software  
  •  NSX API – RESTful API for integration into any cloud management platform
From this we can see portion of NSX is meeting the requirement of SDN, NFV and NV.

NSX is a big topic and in the future will dig deeper but this is my preparation for next week’s VMworld 2014.