If you’re familiar with OpenStack at all, you’ll know that it’s a collection of different components, or projects and not a single packaged piece of software. More than 30 different pieces of software make up OpenStack in its entirety ranging from networking to compute, to storage, to bare metal, to key management, orchestration, clustering and more. While OpenStack is widely recognized as being the leading open source cloud management platform, it’s not without its complexities. This can make it difficult to build if you don’t have the right skilled resources in-house, or if you need it up and running quickly so that you can use it for your business-critical systems and data.
Build or buy?
I often compare OpenStack to a kit car – the Caterham Seven is a classic British sports car. You can choose to buy it in its component parts and build it yourself as seen in the image on the left, or you can buy it ready built (as seen on the right). Personally, while I can put together flat pack furniture without too much trouble, can change a car wheel, top up the important fluids in the engine compartment and build a home computer or rack-mounted server from the ground up, I’m not technically proficient enough to even think about building my own car. Plus with a family (my business-critical systems, if you like), I don’t want to risk driving them around in something that I’ve built myself. I also lack a garage, the necessary tools and the spare time to build a car. When I’m buying a car, I need something that has all the relevant safety features (you know – wheels, doors, seat belts, etc.), is reliable and can be driven straight away (once I have it insured, of course).
For many enterprises, software-defined infrastructure and private clouds are viewed in much the same way. Their internal IT teams are too busy keeping the lights on to build a brand new OpenStack infrastructure using online tutorials and manuals, plus when an enterprise buys a private cloud or software-defined infrastructure, they tend to buy it because they need it sooner rather than later. They want to run their business-critical systems on it, so need to know that it’s secure, reliable and stable. This is why SUSE released the very first enterprise-ready distribution of OpenStack in 2012 – SUSE OpenStack Cloud. But more on distributions another time…
Networking – a critical component
One of the many parts of any software-defined infrastructure is of course networking – in OpenStack, that’s the Neutron project. No-one can deny that networking is pretty essential in SDI, and in a virtualised world it’s not as simple as just running cables between servers and switches and assigning IP addresses. Neutron (and networking generally) is complex enough on its own, but when you realise that it has multiple parts and sub-components, that complexity grows.
One such sub-component is the Open vSwitch L2 Agent. It runs on the compute nodes in an OpenStack environment, and it provides connections to new servers, applying security group rules, and gives notifications when devices are attached or removed.
Here at SUSE, we’re very proud of our team of engineers around the globe that make sure our products are enterprise-ready, and also provide world-class support to our customers when they need it. Rossella Sblendido leads the team at SUSE that takes care of software-defined networking (SDN) and network function virtualization (NFV), was a core reviewer for OpenStack Neutron, and is widely known in the open source community for her expertise and knowledge in this field. She’s put together a video explaining a little more about the L2 Agent, to try to break down some of the complexity surrounding it. Check out the video, and if you have any specific questions around the L2 Agent, Neutron, or even OpenStack in general, let me know in the comments and we’ll try to answer them. We’re planning on putting together some more videos around OpenStack in the coming months, so watch this space for more.
No comments yet