Troubleshooting FDB table wrapping in Open vSwitch

When most people deploy an Open vSwitch configuration for virtual networking using the NORMAL rule, that is, using L2 learning, they do not think about configuring the size of the Forwarding DataBase (FDB).

When hardware-based switches are used, the FDB size is generally rather large and the large FDB size is a key selling point. However for Open vSwitch, the default FDB value is rather small, for example, in version 2.9 and earlier it is only 2K entries. Starting with version 2.10 the FDB size was increased to 8K entries. Note that for Open vSwitch, each bridge has its own FDB table for which the size is individually configurable.

This blog explains the effects of configuring too small an FDB table, how to identify which bridge is suffering from too small an FDB table, and how to configure the FDB table size appropriately.

Continue reading “Troubleshooting FDB table wrapping in Open vSwitch”


Configuring the MongoDB WiredTiger memory cache for RHMAP

This article describes how to configure MongoDB’s WiredTiger memory cache in Red Hat Mobile Application Platform (RHMAP) to prevent high-usage memory issues and Nagios alerts. If the WiredTiger cache consumes all the memory available for a container, memory issues and Nagios alerts will occur.

The WiredTiger storage engine is the default storage engine starting in MongoDB version 3.2. It uses MultiVersion Concurrency Control (MVCC) architecture for write operations in order to allow multiple different modifications to the same document at the same time.

WiredTiger also caches data and creates checkpoints to give you the ability to recover anytime it’s necessary. For example, if a MongoDB image deployed in a container fails, it is useful to recover the data that was not persisted. Additionally, WiredTiger can recover un-checkpointed data with its journal files. See the journal documentation and snapshots and checkpoint documentation for more information.

Continue reading “Configuring the MongoDB WiredTiger memory cache for RHMAP”


The rise of non-microservices architectures

This post is a short summary of my recent experiences with customers that are implementing architectures similar to microservices but with different characteristics in the current post-microservices world.

The microservices architectural style has been around for close to five years now, and much has been said and written about it. Today, I see teams deciding not to strictly follow certain principles of the “pure” microservices architecture and to break some of the “rules.” Teams are now more informed about the pros and cons of microservices, and they make context-driven decisions respecting team experience and organizational boundaries and accept the fact that not every company is Netflix. Below are some examples I have seen in my recent microservices gigs.

Continue reading “The rise of non-microservices architectures”


Dynamic IP Address Management in Open Virtual Network (OVN): Part One

Some background

For those unfamiliar, Open Virtual Network (OVN) is a subproject of OpenVswitch (OVS), a performant programmable multi-platform virtual switch. OVN provides the ability to express an overlay network as a series of virtual routers and switches. OVN also provides native methods for setting up Access Control Lists (ACLs), and it functions as an OpenFlow switch, providing services such as DHCP. The components of OVN program OVS on each of the hypervisors in the network. Many of Red Hat’s products, such as Red Hat OpenStack Platform and Red Hat Virtualization, are now using OVN. Red Hat OpenShift Container Platform will be using OVN soon.

Looking around the internet, it’s pretty easy to find high-quality tutorials on the basics of OVN. However, when it comes to more-advanced topics, it sometimes feels like the amount of information is lacking. In this tutorial, we’ll examine dynamic addressing in OVN. You will learn about IP address management (IPAM) options in OVN and how to apply them.

Continue reading “Dynamic IP Address Management in Open Virtual Network (OVN): Part One”


Asynchronous communication between microservices using AMQP and Vert.x

Microservices are the go-to architecture in most new, modern software solutions. They are (mostly) designed to do one thing, and they must talk to each other to accomplish a business use-case. All communication between the microservices is via network calls; this pattern avoids tight coupling between services and provides better separation between them.

There are basically two styles of communication: synchronous and asynchronous. These two styles applied properly are the foundation for request-reply and event-driven patterns. In the case of the request-reply pattern, a client initiates a request and typically waits synchronously for the reply. However, there are cases where the client could decide not to wait and register a callback with the other party, which is an example of the request-reply pattern in an asynchronous fashion.

In this article, I am showcasing the approach of asynchronous request-reply by having two services communicate with each other over Advanced Message Queuing Protocol (AMQP). AMQP is an open standard for passing business messages between applications or organizations. Although this article focuses on the request-reply pattern, the same code can be used to develop additional scenarios like event sourcing. Communicating using an asynchronous model can be very beneficial for implementing the aggregator pattern.

I will be using Apache QPid Proton (or Red Hat AMQ Interconnect) as the message router and the Vert.x AMQP bridge for communication between the two services.

Continue reading “Asynchronous communication between microservices using AMQP and Vert.x”


Intro to Podman (Red Hat Enterprise Linux 7.6 Beta)

Red Hat Enterprise Linux (RHEL) 7.6 Beta was released a few days ago and one of the first new features I noticed is Podman. Podman complements Buildah and Skopeo by offering an experience similar to the Docker command line: allowing users to run standalone (non-orchestrated) containers. And Podman doesn’t require a daemon to run containers and pods, so we can easily say goodbye to big fat daemons.

Podman implements almost all the Docker CLI commands (apart from the ones related to Docker Swarm, of course). For container orchestration, I suggest you take a look at Kubernetes and Red Hat OpenShift.

Podman consists of just a single command to run on the command line. There are no daemons in the background doing stuff, and this means that Podman can be integrated into system services through systemd.

We’ll cover some real examples that show how easy it can be to transition from the Docker CLI to Podman.

Continue reading “Intro to Podman (Red Hat Enterprise Linux 7.6 Beta)”


Improving rsync performance with GlusterFS

Rsync is a particularly tough workload for GlusterFS because with its defaults, it exercises some of the worst case operations for GlusterFS. GlusterFS is the core of Red Hat Gluster’s scale-out storage solution. Gluster is an open, software-defined storage (SDS) platform that is designed to scale out to handle data intensive tasks across many servers in physical, virtual, or cloud deployments. Since GlusterFS is a POSIX compatible distributed file system, getting the best performance from rsync requires some tuning/tweaking on both sides.

In this post, I will go through some of the pain points and the different tunables for working around the pain points.  Getting rsync to run as fast on GlusterFS as it would on a local file system is not really feasible given its architecture, but below I describe how to get as close as possible.

Continue reading “Improving rsync performance with GlusterFS”


Natively compile Java code for better startup time

Microservices and serverless architectures are being implemented, or are a part of the roadmap, in most modern solution stacks. Given that Java is still the dominant language for business applications, the need for reducing the startup time for Java is becoming more important. Serverless architectures are one such area that needs faster startup times, and applications hosted on container platforms such as Red Hat Openshift can benefit from both fast Java startup time and a smaller Docker image size.

Let’s see how GraalVM can be beneficial for Java-based programs in terms of speed and size improvements. Surely, these gains are not bound to containers or serverless architectures and can be applied to a variety of use cases.

Continue reading “Natively compile Java code for better startup time”


Improving .NET Core Kestrel performance using a Linux-specific transport

ASP.NET Core is the web framework for .NET Core. Performance is a key feature. The stack is heavily optimized and continuously benchmarked. Kestrel is the name of the HTTP server. In this blog post, we’ll replace Kestrel’s networking layer with a Linux-specific implementation and benchmark it against the default out-of-the-box implementations. The TechEmpower web framework benchmarks are used to compare the network layer performance.

Continue reading “Improving .NET Core Kestrel performance using a Linux-specific transport”


How to migrate your SOAP web service to REST with Camel

SOAP-based services are plentiful in many enterprise solutions and are slowly being replaced by RESTful services to simplify their use. There is a new wizard to help you make the transition with Apache Camel’s Rest DSL added in the latest version of Red Hat Fuse Tooling. This article shows how to use the new wizard to transition from older SOAP-based services to more modern REST-based services.

If you aren’t familiar, Red Hat Fuse is an integration platform based on Camel and a number of other projects. The updating Fuse Tooling is available in Red Hat Developer Studio 12.0.0, the desktop IDE that is based on Eclipse 4.8 Photon. You can also get the new wizard by adding JBoss Tools 4.6 to your existing Eclipse 4.8 Photon installation by downloading it directly, or installing via the Eclipse Marketplace.

Continue reading “How to migrate your SOAP web service to REST with Camel”