Orchestration via SaltStack

This post will be about my approach to something, that is almost obsolete. It is about orchestration. Back in the old days, people used to have a real computers or virtual machines and used to install and configure software. And also maintain it for years to come. I know that nowadays, you just create a bunch of pods, each one consisting from multiple containers you downloaded from DockerHub and whenever you need to reconfigure or update something, you just throw them away. Or even the whole datacenter. But I’m old and I still maintain individual systems with multiple services running. And jokes aside, when you do that, you want to have some automation to make it easier. That is what orchestration is for – to manage multiple machines from one central point and to make sure that everything is up to date and configured consistently.

Datacenter scale by XKCD

Datacenter scale by XKCD

Sentinel View report – October 2023

An interesting dynamic is happening at the top of the attackers’ chart. First of all, Iranian attacks were overshadowed by other countries to the degree that we no longer see them in higher positions. To mention the current top four most significant, we would highlight Romania, Germany, Bulgaria, and the Netherlands. There had been consistent attacks from Germany that came into prominence about the 4th of October and then slowly started to disappear on the 16th until the final dissolution on the 18th of October. The graph line for German attacks looks very stable and consistent. On the other hand, Romania’s malicious activity, which took the top of the charts, looked erratic and unorganized in the graph. To the degree that Sentinel View graphs in the Incidents section, except for Top countries by recorded incidents, are rendered almost useless.

BIRD Journey to Threads. Chapter 4: Memory and other resource management.

BIRD is mostly a large specialized database engine, storing mega/gigabytes of Internet routing data in memory. To keep accounts of every byte of allocated data, BIRD has its own resource management system which must be adapted to the multithreaded environment. The resource system has not changed much between v2 and v3, yet it deserves a short chapter.

BIRD Journey to Threads. Chapter 2: Asynchronous route export

Route export is a core algorithm of BIRD. This chapter covers how we are making this procedure multithreaded. Desired outcomes are mostly lower latency of route import, flap dampening and also faster route processing in large configurations with lots of export from one table.

BIRD Journey to Threads. Chapter 1: The Route and its Attributes

Data structures used by BIRD have to be changed in order to allow multithreading safely. This chapter covers necessary changes of them. BIRD is a fast, robust and memory-efficient routing daemon designed and implemented at the end of 20th century. We’re doing a significant amount of BIRD’s internal structure changes to make it possible to run in multiple threads in parallel.