UPDATE Jan 16th: new OSP10 + CEPH 2 Hyper Converged Infrastructure Reference Architecture
It’s that time of the year. We all look back at 2016, think about the good and bad things, and wish that Santa brings us the gifts we deserve. We, at Red Hat, are really proud to bring you a present for this holiday season: a new version of Red Hat OpenStack Platform, version 10 (press release and release notes). This is our best release ever, so we’ve named it our first Long Life release (up to 5 years support), and this blog post will show you why this will be the perfect gift for your private cloud project.
Continue reading “Red Hat OpenStack Platform 10 is here! So what’s new?”
Written by Jiri Benc, Senior Software Engineer, Networking Services, Linux kernel, and Open vSwitch
By introducing a connection tracking feature in Open vSwitch, thanks to the latest Linux kernel, we greatly simplified the maze of virtual network interfaces on OpenStack compute nodes and improved its networking performance. This feature will appear soon in Red Hat OpenStack Platform.
It goes without question that in the modern world, we need firewalling to protect machines from hostile environments. Any non-trivial firewalling requires you keep track of the connections to and from the machine. This is called “stateful firewalling”. Indeed, even such basic rule as “don’t allow machines from the Internet to connect to the machine while allowing the machine itself to connect to servers on the Internet” requires stateful firewall. This applies also to virtual machines. And obviously, any serious cloud platform needs such protection.
Continue reading “How connection tracking in Open vSwitch helps OpenStack performance”
Network troubleshooting can be hard. Network troubleshooting in a complex distributed system like OpenStack can be even harder. With a typical Neutron deployment using the Open vSwitch (OVS) plug-in, one can expect rich networking configurations on the Red Hat Enterprise Linux OpenStack Platform nodes, the Compute and Controller nodes in particular.
While the network implementation details are well hidden from the end customer (who interfaces with the Neutron API or the Horizon Dashboard), the actual backend implementation involves the creation of various Linux devices, bridges, tunnel interfaces, and network namespaces. This is where the “magic” happens, and how OpenStack tenants can create and consume network resources such as networks, IP subnets and virtual routers, and get proper communication for their applications.
Continue reading “Troubleshooting Networking with RHEL OpenStack Platform: meet ‘plotnetcfg’”