© Vladislav Zhukov, 123RF

Load Balancer gibt es als fertige Appliance oder als Software für Linux-Server. Wir stellen die wichtigsten Software-Load-Balancer mit ihren Stärken und Schwächen vor und geben Empfehlungen für Einsatzszenarien.

Kommt das Gespräch auf implizit skalierbare Setups, können sich die Admins von Webserver-Farmen oft ein Grinsen nicht verkneifen. Cloud-native-Anwendungen gelten heute als besonders innovativ, wenn man sie so baut, dass für jede Aufgabe ein einzelner Dienst zuständig ist und von jedem Dienst beliebig viele Instanzen laufen können, die ihre Arbeit im kollegialen Verbund untereinander aufteilen.

Als PostgreSQL vor ein paar Jahren echte Multi-Master-Replikation erlernte und dann MySQL mit ein paar Jahren Abstand folgte, war das für viele durchaus bemerkenswert. Wer es im beruflichen Alltag mit Webservern zu tun hat, kann da freilich nur lächeln: Hier ist es quasi seit Anbeginn der Zeit ganz normal, einen Load Balancer zu nutzen, der eine beliebige Anzahl von Backend-Servern hinter sich weiß. Wird die Last des Setups zu hoch, stellt der Admin zusätzliche Server dazu. So lässt sich beinahe jeder Ressourcenengpass verhindern.

Insofern ist der Load Balancer in nahezu jedem Web-Setup eine sehr wichtige Komponente – funktioniert er nicht, ist die Website offline. Das hat einige Anbieter zur durchaus richtigen Annahme verleitet, dass in diesem Bereich des IT-Markts viel Geld zu machen sei. Appliances von F5, Citrix, Radware & Co. galten deshalb im Load-Balancer-Umfeld lange als der Quasi-Standard, obwohl leistungsfähige Software-Lösungen für den Betrieb als Dienst auf normalen Linux-Servern zur Verfügung standen, etwa HAProxy oder Nginx.

Nicht zuletzt der Cloud-native-Trend beschleunigt dieser Tage allerdings den Wandel hin zum Software Defined Load Balancing, weil die typischen Appliances sich in Cloud-native-Anwendungen nur schwer integrieren lassen. Grund genug für eine kurze Marktübersicht: Welche Tools für Software-basiertes Load Balancing stehen Linux-Admins zur Verfügung? Was sind deren spezifischen Stärken und Schwächen? Und für welches Szenario eignet sich welche Software am besten? Dieser Artikel verrät es.

Bevor es losgeht, steht aber noch ein kleiner theoretischer Exkurs an: Nicht jeder der vorgestellten Load Balancer bietet dieselben Features.

OSI lässt grüßen

Bei Software-Load-Balancern gilt genauso wie bei Hardware-Load-Balancern, dass grundsätzlich verschiedene Balancing-Techniken zur Verfügung stehen. Im Kern unterscheiden sich viele Load Balancer vor allem im Hinblick auf den Layer des OSI-Modells voneinander, auf dem sie arbeiten. Manche Load Balancer bieten auch Unterstützung für mehrere OSI-Layer. Was in der Theorie dröge klingt, hat in der Praxis erhebliche Auswirkungen.

Die meisten Software-Load-Balancer für Linux operieren auf dem OSI-Layer 4, also der Transportebene. Sie nehmen somit eingehende Verbindungen bestimmter Protokolle – in der Regel TCP/IP – auf der einen Seite entgegen und leiten sie auf der anderen Seite an ihre Backends. Load-Balancing auf dieser Ebene ist agnostisch im Hinblick auf das Protokoll, das zum Einsatz kommt. Ein Layer-4-Load Balancer kann deshalb ebenso gut HTTP-Verbindungen verteilen wie MySQL-Connections oder auch jedes beliebige andere Protokoll.

Im Umkehrschluss bedeutet der Layer 4 aber auch, dass protokollspezifische Optionen beim Balancing nicht zur Verfügung stehen. Für klassisches Load Balancing bei Webservern erwarten viele Anwendungen etwa Stickiness für ihre Sessions. Das heißt, dass dieselben Clients anhand verschiedener Parameter wie Session-IDs bei mehreren aufeinander folgenden Requests stets auf demselben Webserver landen.

Das kann der Webserver aber nur garantieren, wenn er nicht nur auf der Protokollebene Pakete weiterleitet, sondern den Datenfluss auch analysiert und interpretiert. Viele Load Balancer unterstützen das; man spricht dann aber von Level-7-Load-Balancing. Zur Erinnerung: Der Layer 7 ist die Applikationsschicht.

Für die Wahl des zu nutzenden Load Balancers hat die Frage nach Support für Layer-7-Load-Balancing freilich große Relevanz. Manche Balancer in diesem Vergleich unterstützen explizit nur den Layer 4, andere bieten auch Protokoll-Support. Auf die OSI-Ebenen, die die vorgestellten Lösungen unterstützen, geht der Artikel bei jedem Probanden einzeln ein.

Hochverfügbarkeit

Wenn Admins sich mit Software-Load-Balancern beschäftigen, sollten sie neben der Funktionalität der Website auch den Load Balancer selbst als potenzielle Problemquelle im Hinterkopf behalten. Die Appliance-Konkurrenz nutzt das als willkommene Gelegenheit, gleich noch einmal ordentlich Kasse zu machen. Load-Balancer-Appliances aller Hersteller lassen sich zwar in hochverfügbarer Art und Weise betreiben, dafür müssen aber zwei der Geräte vorhanden sein. Dass die Firmware die Funktionalität so oder so beherrscht, tut nichts zur Sache: Zusätzlich zum zweiten Gerät wird in der Regel auch noch eine Lizenzerweiterung fällig, damit man die beiden Balancer in einen HA-Cluster einbauen kann.

Bei Load Balancern im Eigenbau kümmert sich der Admin selbst um das Thema HA, wozu er die Hardware redundant auslegen muss. Angesichts der Tatsache, dass aber selbst die berüchtigten Pizzaboxen in halber Bautiefe mittlerweile 256 GByte RAM und Mehrkern-CPUs mitbringen, hält sich der finanzielle Aufwand in Grenzen. Zudem erweisen sich die im Artikel vorgestellten Software-Load-Balancer alle als nicht besonders gefräßig, was die Ressourcen angeht. Etwas unangenehmer ist da schon die Software-Seite: Umschwenkende IP-Adressen in Kombination mit bestimmten Diensten lassen sich in Linux etwa als typischer HA-Cluster mit Pacemaker realisieren.

Der Klassiker: HAProxy

Der erste Proband im Vergleich dürfte als echtes Urgestein den meisten Admins schon einmal begegnet sein: HAProxy [1] gehört mit zu den ältesten Lösungen im Testfeld, denn seine erste Version erblickte Ende 2001 das Licht der Welt. Im Hinblick auf das OSI-Modell fußt HAProxy grundsätzlich auf Layer 4; er kann Balancing daher für beliebige TCP/IP-Verbindungen realisieren. Grundsätzlich eignet HAProxy sich damit auch als Load Balancer für MySQL oder andere Datenbanken. Komplementär dazu lässt sich Layer-7-Funktionalität nutzen, allerdings nur für HTTP – andere Protokolle bleiben außen vor.

Weil HAProxy bereits seit so langer Zeit im Geschäft ist, bietet er etliche Features, die man sicher nicht in jedem Use Case benötigt. Bei den Grundfunktionen leistet HAProxy sich aber keine Schwächen. HTTP/2 unterstützt er deshalb ebenso wie komprimierte Verbindungen mittels Gzip, das Umschreiben von HTTP-URLs sowie Rate Limiting, um DDoS-Angriffen ein Stück weit entgegenzutreten. Weil das Programm seit etlichen Jahren Multithreading beherrscht, profitiert es von modernen Mehrkern-CPUs, besonders von solchen, die auch Hyperthreading anbieten. Ein halbwegs aktueller Multi-Core-Prozessor lässt sich durch HAProxy jedenfalls eher nicht aus der Ruhe bringen.

SSL und Load Balancing ist ein komplexes Thema, weil ein Mittelsmann wie HAProxy und SSL-Verschlüsselung einander eigentlich ausschließen. Es hat sich deshalb etabliert, den Load Balancer selbst anstelle des HTTP-Servers die SSL-Terminierung vornehmen zu lassen. Freilich kann der Admin in solchen Fällen zusätzlich SSL-Verschlüsselung zwischen den einzelnen Webservern und dem Load Balancer einrichten. HAProxy beherrscht beides: Der Dienst terminiert auf Wunsch SSL-Verbindungen und spricht mit den Backends ebenfalls verschlüsselt, beispielsweise dann, wenn er deren Zustand prüft: HAProxy verfügt über umfangreiche Möglichkeiten, die eigenen Backends einer Funktionskontrolle zu unterziehen. Geht ein Backend offline oder liefert der dort laufende Webserver nicht das gewünschte Resultat, nimmt HAProxy ihn automatisch aus der Rotation.

In Summe präsentiert HAProxy sich als zuverlässiger Load Balancer mit einem riesigen Funktionsumfang. Die Konfigurationsdatei des Programms fällt gerade deshalb allerdings nicht sehr übersichtlich aus. Im modernen Rechenzentrum wird der Admin sie aber in der Regel ohnehin aus seiner Automation heraus generieren, sodass das keine Schwierigkeit darstellt.

Für alle gängigen Automatisierer gibt es Anbindungen von HAProxy entweder vom Hersteller selbst oder von Drittanbietern. Nicht unerwähnt bleiben soll an dieser Stelle zudem die kommerzielle Variante von HAProxy: Sie hat neben Support auch ein paar Plugins für Zusatzfunktionen im Gepäck, etwa ein SSO-Modul sowie ein Real-Time-Dashboard, mit dem sich diverse Metrikdaten aus HAProxy anzeigen lassen.

Apropos Metrikdaten: Die Einbindung von HAProxy in konventionelle wie moderne Monitoring-Systeme gestaltet sich ob der Vorarbeit vieler Nutzer und Entwickler als sehr einfach. Das Tool kommt zudem mit einer eigenen Status-Page daher, die einen grundlegenden Überblick bietet (Abbildung 1). In Summe darf HAProxy als die Nummer sicher gelten, wenn es um Load Balancer geht.

Abbildung 1: HAProxy bietet eine Status-Page mit grundlegenden Details zur aktuellen Nutzung des Diensts. Quelle: HAProxy

Der Unerwartete: Nginx

Der zweite Kandidat im Vergleich ist vielen Admins als potenzieller Load Balancer gar kein Begriff, obwohl sie das Programm selbst gut kennen: Nginx [2] kommt in vielen Unternehmen zum Einsatz, üblicherweise als hochperformanter Webserver, und zweifelsohne beherrscht das Programm diese Aufgabe wirklich gut. Allerdings kommt Nginx mit einem Modul namens Upstream daher, das aus dem eigentlichen Webserver flugs einen Load Balancer macht. Getreu dem Motto “Schuster, bleib bei deinen Leisten” beschränkt Nginx sich dabei ausschließlich auf das HTTP-Protokoll im Layer 7 des OSI-Modells.

Dass Nginx primär ein Webserver und kein Load Balancer ist, ändert nichts daran, dass er es in Sachen Features mit HAProxy durchaus aufnehmen kann. Hier erwächst dem Programm seine modulare Struktur zum Vorteil: SSL etwa beherrscht Nginx selbstverständlich ebenso wie das modernere HTTP/2-Protokoll. Komprimierte Verbindungen und Metrikdaten in Echtzeit gehören ebenfalls zum Funktionsumfang.

Per Upstream-Modul (Abbildung 2) definiert der Admin dann quasi einfach noch einen weiteren Schritt für den Weg, den eingehende Pakete zurücklegen. Falls SSL zum Einsatz kommt, erledigt Nginx die SSL-Terminierung anstandslos mit. Dabei beherrscht es, übrigens wie HAProxy, mehrere Betriebsmodi, was das Weiterleiten von Clients an die Backend-Server betrifft. Neben typischem Round-Robin steht der Modus Least Connections zur Verfügung, der das Backend mit der geringsten Last auswählt. Der IP-Hash-Algorithmus als dritte Option errechnet das Ziel-Backend anhand eines Hash-Werts, den er aus der IP-Adresse des Clients gewinnt.

Abbildung 2: Auch wenn die meisten Admins Nginx eher als Webserver denn als Load Balancer kennen, beherrscht das Programm beides, und die Konfiguration gestaltet sich unkompliziert.

Von Nginx gibt es zudem eine kommerzielle Variante namens Nginx Plus. Sie bietet zusätzlich einen Least-Time-Modus, in dem immer jenes Backend eine Verbindung erhält, das aktuell vom Nginx aus betrachtet die geringste Latenz liefert. Sitzungspersistenz bietet jedoch auch die normale Nginx-Variante ohne Plus. Ob der IP-Hashing-Algorithmus oder ein zufälliger Modus mit persistierenden Sitzungen die bessere Option darstellt, hängt zum Teil vom Setup ab und lässt sich letztlich nur durch Ausprobieren herausfinden.

Das eingangs beschriebene HA-Problem lösen Admins bei Nginx übrigens ebenfalls sehr elegant, indem sie die kommerzielle Distribution Nginx Plus des Produkts kaufen. Sie hat einen eingebauten HA-Modus und lässt sich im Aktiv-Passiv-Modus oder sogar im Aktiv-Aktiv-Modus betreiben. Möglicherweise unliebsame Werkzeuge wie Pacemaker bleiben in diesem Szenario außen vor.

Robuste Lösung: Seesaw

Dass Google als eine der aktivsten Firmen im IT-Umfeld überhaupt eine eigene Meinung zum Thema Load-Balancing hat, verwundert wenig. Dass das Unternehmen sich zumindest stark an der Entwicklung eines Load Balancers beteiligt, auch wenn dieser offiziell kein Google-Produkt sein darf, vermag ebenso wenig zu irritieren. Seesaw [3] heißt das gute Stück, übersetzt also Wippe, was den Kernaspekt eines Load Balancers ganz gut umschreibt.

Seesaw fußt auf dem Linux-Virtual-Server-Funktionen des Kernels (LVS) und kommt im Hinblick auf seine Funktionalität deshalb eher nach Keepalived. Es richtet sich ausschließlich an Nutzer des OSI-Layers 4, womit es explizit der erste Load Balancer im Test ist, der keine Sonderfunktionen für HTTP bietet. Das Protokoll des World Wide Web dürfte bei den Google-Entwicklern jedoch ohnehin nicht im Fokus gestanden haben, als sie vor ein paar Jahren mit der Arbeit an Seesaw begannen.

Das wird schon beim grundlegenden Betriebskonzept der Lösung deutlich. Hacks mittels Pacemaker & Co. zum Erreichen von Hochverfügbarkeit gibt es bei Seesaw so nicht. Stattdessen will es stets als Cluster aus zumindest zwei Instanzen betrieben werden, die miteinander kommunizieren. Das umgeht de facto die HA-Problematik: Der Admin konfiguriert auf der Seesaw-Ebene die virtuellen IPs (VIPs), die nach außen verkündet werden sollen, sowie die IPs der internen Zielsysteme.

Weil Seesaw sogar Anycast und Load Balancing für Anycast unterstützt, gerät das Setup gegebenenfalls etwas komplexer: Bindet der Admin den BGP-Daemon Quagga an Seesaw an, verkündet dieses Anycast-VIPs, sobald man sie auf einem der Systeme von Seesaw aktiviert. Ein Anycast-Load-Balancing können Nginx oder HAProxy nur bedingt leisten – hier liefert Seesaw also innovative Features.

Im Gegenzug stellt Seesaw aber stramme Anforderungen. Es verlangt pro Maschine mindestens zwei Netzwerkanschlüsse im selben Layer-2-Netz. Einer kommt für die eigene IP des Systems zum Einsatz, über die anderen verkündet Seesaw die VIPs für laufende Dienste. Allerdings merken die Entwickler an, dass Seesaw sich auch problemlos in Form mehrerer virtueller Maschinen betreiben lässt, was die Sache etwas entspannter macht.

Das in Go geschriebene Seesaw soll dem Administrator nach der ersten Einrichtung im Idealfall nicht mehr viel Kummer bereiten. Die übersichtliche Konfigurationsdatei kommt im INI-Format daher und umfasst in der Regel nicht mehr als 20 Zeilen – wobei sie im Seesaw-Kontext ohnehin nur eine untergeordnete Rolle spielt. Google war es bei dem Dienst wichtig, dass er sich leicht zentral administrieren lässt. Zu Seesaw gehört deshalb auch ein Config-Server genannter Dienst, in dem der Admin die Backend-Server dynamisch konfiguriert und der die Information anschließend an Seesaw weitergibt (Abbildung 3).

Abbildung 3: Seesaw lässt sich denkbar leicht konfigurieren, weil es seine Hauptkonfiguration von einem eigenen Dienst bezieht statt über eine Datei.

Das mag im ersten Moment etwas überkandidelt klingen und zahlt sich tatsächlich nur bedingt aus, wenn man lediglich ein einzelnes Load-Balancer-Pärchen betreibt. Wer jedoch in Google-Maßstäben denkt und sich mit etlichen Seesaw-Instanzen konfrontiert sieht, versteht schnell die Eleganz hinter diesem Ansatz. Das gilt umso mehr, als Seesaw bei seiner Konfiguration dem KISS-Ansatz folgt und nicht etwa versucht, einen der gängigen Automatisierer nachzubauen. Wer also auf der Suche nach einem versatilen Load Balancer für die OSI-Ebene 4 ist, sollte sich Seesaw genauer ansehen – es lohnt sich.

Kommerzielles Zevenet

Als letzter Kandidat im Vergleich geht Zevenet [4] ins Rennen, als Beweis dafür, dass Load Balancer durchaus kommerziellen Ursprungs sein können, ohne als eigene Appliance daherzukommen. Wer möchte, bekommt den Dienst bei Zevenet zwar auch samt Hardware, notwendig ist das aber nicht. Zevenet bezeichnet sich auch als Cloud-ready, der Hersteller liefert es sogar als fertige Appliance für den Betrieb in verschiedenen Clouds aus.

Inhaltlich ist Zevenet dabei gar nicht so spektakulär. Es handelt sich um einen Standard-Load-Balancer, den es in einer Community- und einer Professional-Variante gibt. Die Community-Version hat grundlegenden Balancing-Support für die OSI-Layer 4 und 7 im Gepäck, wobei der Fokus im Layer 7 auf HTTP liegt. Das Konzept dahinter ist allerdings klar Do-it-yourself, Support vom Hersteller gibt es höchstens in Form von Best-Effort-Anfragen in dessen Forum.

Deutlich mehr Spaß macht die Enterprise-Edition von Zevenet. Sie bietet wie Nginx und Seesaw eingebaute Hochverfügbarkeit für den Betrieb im Rahmen eines Clusters, liefert eigene Monitoring-Meldungen via SNMP aus und bietet auch eine eigene API für den Zugriff. Anders als die bisher vorgestellten Tools hat Zevenet Enterprise zudem ein erweitertes GUI im Schlepptau, über das der Admin die Konfiguration schnell und unkompliziert erledigt.

Eine Basis-Version gibt es zwar für die Community-Edition auch (Abbildung 4), doch bietet die Enterprise-Variante deutlich mehr Funktionen (Abbildung 5). Was versierten Admins eher ein Dorn im Auge ist, kann im Meeting mit dem Management den Tag retten. Dabei lässt sich Zevenet über das GUI auch an eine externe Benutzerverwaltung anschließen oder bringt alternativ seine eigene mit, die sogar einen Audit-Trail hat. Wer also die Konfiguration des Load Balancers ändern darf, lässt sich in Zevenet auf der Dienstebene festlegen.

Abbildung 4: Zevenet bietet nicht nur API-Zugriff zur Konfiguration, sondern kommt auch mit einem GUI daher. Quelle: Zevenet

Abbildung 5: Das Enterprise-GUI von Zevenet bietet diverse Features, die in der Community-Variante fehlen. Quelle: Zevenet

Die L4- und L7-Fähigkeiten der Community-Version baut die Variante für das Enterprise-Umfeld erheblich aus. So lassen sich etwa verschiedene Protokolltypen gesondert überwachen und loggen. Dabei kann man sogar das Ziel für die Log-Meldungen bestimmen. Auf der Ebene des OSI-Layers 7 für HTTP bietet Zevenet Features wie Support für SSL-Wildcard-Zertifikate, Cookie-Injektion und Support für OpenSSL 1.1 an.

Nicht alle diese Features sind für alle Use Cases ähnlich relevant, in Summe vermag der Funktionsumfang von Zevenet jedoch zu überzeugen. Dabei kann man an vielen Stellen Liebe zum Detail erkennen: Verbindungen transferiert Zevenet etwa von einem Knoten eines Clusters auf einen anderen, ohne den Zustand zu verlieren. Auch an der Gebetsmühle für Sicherheit dreht Zevenet, indem es verschiedene externe DNSBL/RBL-Dienste sowie Dienste zur DDoS-Prävention einbindet und etwaigen Clients falls nötig den Zugang verweigert. Damit verlässt Zevenet bereits die Sphären des Load Balancings und wird eher zu einer kleinen Firewall.

Load Balancing für Container

Die bis hierhin vorgestellten Load Balancer haben allesamt gemeinsam, dass der Admin sie oft auf separater Hardware betreibt und in ein HA-Setup integriert. Das ist von großer Relevanz für klassische Applikationen, konventionelle Webserver-Umgebungen und andere Standard-Software. Am Trend für Cloud Native Computing geht es allerdings vorbei, denn hier ist ja nach Möglichkeit so gut wie alles Software Defined und obendrein auch noch durch die Anwender selbst verwaltet. Den zentralen Load Balancer, der für eine Website oder mehrere Installationen die Weiterleitung erledigt, gibt es in diesem Szenario also nicht.

Stattdessen hat der Admin Kubernetes oder eine der darauf basierenden Distributionen am Hals. Darin rollt er die App in Pods aus, die der jeweilige Container-Orchestrierer beliebig über physische Systeme verteilt. Deren Netz ist rein virtuell und nicht auf einen bestimmten Host festzulegen, sodass die typische Load-Balancer-Architektur ins Leere läuft. Braucht ein Setup also Load Balancing, etwa um diverse Mikrokomponenten einer Anwendung verteilt miteinander kommunizieren zu lassen, läuft der klassische Ansatz also ins Leere.

Nicht selbst schnitzen

Nun könnte man als Entwickler oder als Administrator auf die Idee kommen, sich einen Container mit Load Balancer selbst zu schnitzen, den man dann als Teil des Pod-Designs mit ausrollt. Technisch spricht erst einmal nichts dagegen, dass sich etwa ein entsprechend vorkonfiguriertes Nginx zuverlässig als Balancer betätigt. Allerdings sind Setups, die in Container-Orchestrieren laufen, meist sehr dynamisch. Die Anzahl von potenziellen Quell- und Zielservern auf beiden Seiten ändert sich regelmäßig, womit klassische Software-Load-Balancer nicht gut zurechtkommen.

Lösung per Sidecar

Zum Glück haben sich Entwickler für dieses Problem aber bereits eine Lösung ausgedacht: Software-basierte, speziell auf eben solche Container-Architekturen ausgelegte Load Balancer. In diesem Software-Segment ist Istio [5] gerade so etwas wie der Shooting-Star. Die Software implementiert zunächst banales Load Balancing mit integrierter Terminierung für SSL-Verbindungen. Auf Wunsch legt Istio dabei auch SSL-Zertifikate etwa mittels ACME-Script bei Let’s Encrypt an.

Dazu stellt Istio den Containern in Pods sogenannte Sidecars zur Seite, die für die einzelnen Container als eine Art Proxy fungieren. Und es geht noch mehr als nur einfaches Balancing: Istio implementiert auch Sicherheitsregeln. Es kann zudem das Load Balancing von verschiedenen dynamischen Parametern abhängig machen – etwa von der Last, die gerade an einzelnen Diensten im Backend anliegt. Zudem kommt Istio als Container vorkonfiguriert und lässt sich in Kubernetes ohne Verrenkungen integrieren.

Für Anwendungen, die den Prinzipien der Mikroarchitektur folgen, bieten speziell darauf ausgelegte Ansätze wie Istio insofern den besseren Ansatz. Man sollte sie händischer Bastelei mit selbstgebauten, statisch ausgerollten Load-Balancer-Containern in jedem Fall vorziehen. Sie bieten deutlich mehr Funktionen und haben üblicherweise eine breit aufgestellte Community hinter sich, die dem Admin ein ganzes Stück Arbeit abnimmt.

Fazit

Es gibt eine Vielzahl gut funktionierender Load Balancer auf Software-Basis für praktisch alle Lebenslagen. HAProxy, Nginx, Seesaw sowie Zevenet sind vor jeweils ganz unterschiedlichen Hintergründen entstanden und legen das Hauptaugenmerk insofern auf leicht unterschiedliche Themen. Ihre Sache machen sie aber so gut, dass man für normale Use Cases bedenkenlos zu jedem der vorgestellten Programme greifen darf. Am Ende ist also auch die persönliche Präferenz ein Faktor, der in die Überlegungen einfließen sollte. (jcb/jlu)