© Leekris / 123RF.com

Suse versucht sich einmal mehr an einem Storage-Produkt und lanciert auf Basis von Ranchers Longhorn einen S3-Speicher, der auch Komponenten von Ceph recycelt. Dürfen Admins sich auf langfristigen Support verlassen, oder zieht Suse auch seinem neuesten Produkt bald einfach wieder den Stecker?

Als Technikjournalist ist man täglich mit einer Vielzahl von Pressemitteilungen konfrontiert, die einen oft genug ratlos zurücklassen. Andere Meldungen passen eher in die Kategorie “Kurioses” und lassen instinktiv eine Augenbraue nach oben schnellen. So auch neulich: Da verkündete Suse, dass man an einem Produkt für das Bereitstellen von Speicher nach Amazons S3-Standard arbeite, das im Hintergrund auf Longhorn basiert – eben jener verteilten Speicherlösung, die Suse sich zusammen mit Rancher ins Haus geholt hat.

Suse und Speicherlösungen? Nicht wenige Admins reagieren da allergisch – schließlich ist der Weg der Nürnberger gesäumt von Storage-Produkten, die sie früher oder später sang- und klanglos wieder in der Versenkung verschwinden ließen. Worum geht es diesmal? Wird dem Produkt ein langes Leben beschert sein? Wozu soll es dienen? Fragen über Fragen, denen wir im Folgenden nachgehen.

Der Nutzen von S3

Amazons S3-Protokoll hat sich in den vergangenen Jahren kontinuierlich gemausert. Das Simple Storage Protocol oder kurz S3 (Abbildung 1) war im AWS-Portfolio ganz am Anfang der simpelste Weg, die On-demand-Storage-Komponente zu liefern, die als einer der beiden zentralen Bausteine jedes Cloud Computings agiert: Online-Speicher.

Weil aber nicht jedes Unternehmen seine Daten direkt in Amazons echtem S3 ablegen möchte, schossen zwischenzeitlich etliche Nachbauten wie die Pilze aus dem Boden. Sie versprechen eine Art lokales S3, bei dem der Vorteil im Wesentlichen das genutzte Protokoll sein soll. Logisch: S3-Clients gibt es am Markt mittlerweile in allen Ausprägungen, es ist also sehr verbreitet und auch an etliche Skript- und Programmiersprachen gut angebunden.

Abbildung 1: Amazon S3 gilt heute als absolutes Standardprotokoll für das Speichern von Daten im Netz, auch wenn es sich um ein proprietäres Format handelt. Clients gibt es für alle gängigen Betriebssysteme. Quelle: Macgasm

Es ist bemerkenswert, dass S3 sich so schnell verbreitet hat: Weder handelt es sich um ein freies Protokoll, noch steht es unter einer freien Lizenz. Es gibt auch keinen Standard, der die serverseitigen Funktionen öffentlich dokumentiert. Alles, was am Markt in Sachen S3-Nachbau existiert, basiert stattdessen ausschließlich auf Reverse Engineering. Am RADOS-Gateway, der S3-Schnittstelle für Ceph, lässt sich das gut nachzuvollziehen: Die Ceph-Entwickler weisen in ihrer Dokumentation an etlichen Stellen darauf hin, dass das RADOS-Gateway den S3-Standard gut genug nachahmt, um mit den meisten Clients und den meisten Funktionen kompatibel zu sein.

Volle und vor allem zuverlässige Kompatibilität mit S3 bietet das RADOS-Gateway aber ebenso wenig wie alle anderen S3-Nachbauten. Gerade die neuesten Funktionen, die Amazon bei S3 bis heute regelmäßig liefert, fehlen den Surrogaten oft ganz. Kritiker werfen ein, dass von diesem etwas unklaren Schwebezustand sogar die Gefahr ausgeht, dass Amazon zu jedem beliebigen Zeitpunkt gegen S3-Nachbauten vorgehen und diesen vor Gericht den Garaus machen könnte.

Dass S3 trotz dieser Risiken weitverbreitet ist, dürfte handfeste praktische Gründe haben. Vielerorts hat S3 nicht weniger als die Art und Weise verändert, wie insbesondere Webanwendungen auf ihre Assets zugreifen. Assets sind aus Sicht von Webentwicklern eine heikle Angelegenheit. Jede Website hat sie: Bilder, Produktfotos, Gestaltungselemente für die Seiten selbst. Diese Elemente müssen, damit die Website oder die Umgebung beim Nutzer wie gewünscht aussieht, irgendwie zu dessen Client gelangen, also zu dessen Webbrowser. Zu den Assets können aber auch Multimediadaten zählen, Videos etwa, die der Client ebenfalls auf irgendeine Weise erhalten muss.

Direkte Einbindung

Wer früher schon mal Webserver-Setups gebaut hat, weiß, wie diese Daten üblicherweise in digitale Dienste integriert werden: Sie liegen auf einem geteilten Speicher (früher oft und gern per NFS implementiert), von wo sie ein Applikationsserver an die Clients ausliefert. Das hat mehrere unschöne Nachteile: Zunächst liegt die Systemlast für das Ausliefern der Assets bei den Applikationsservern. Auch der anfallende Traffic geht zulasten dieser Systeme. Und schließlich kann der geteilte Speicher im Hintergrund durchaus zum Nadelöhr werden, was sich negativ auf die Performance des gesamten Diensts auswirkt.

S3 ist in der Szene auch deshalb so schnell so beliebt geworden, weil es diesem Zirkus effektiv ein Ende setzen kann. Assets lassen sich in S3 abspeichern, und zwar so, dass es zu jedem Asset eine eindeutige URL gibt. Programmiert man die eigene Webanwendung dann so um, dass sie auf S3 verweist und die richtigen Links nutzt, lassen sich sämtliche der beschriebenen Nachteile der lokalen Speicher umgehen. Aus einer S3-Installation wird quasi eine Art kleines CDN (Abbildung 2), das man obendrein mit Caches und ähnlichen Funktionen anreichern kann. Nicht zuletzt ermöglicht S3, ein Setup auf angenehme Weise geografisch zu verteilen: Die Instanz eines Diensts generiert dann Links zum lokalen S3, und der Client vor Ort lädt die Assets unmittelbar aus der S3-Instanz herunter.

Abbildung 2: Lokale S3-Setups bieten die Möglichkeit einer geografischen Aufteilung oder einer Art Mini-CDN, sodass der Zugriff dann regional erfolgt. Quelle: mgm technology partners GmbH

Nun auch Suse

Diese Tatsachen verdeutlichen, dass es gute Gründe geben kann, eine lokale S3-Instanz zu haben. Auf eben diesen Zug will Suse jetzt aufspringen. Der technische Ansatz, den die Firma dabei nutzt, verwundert allerdings etwas: Statt auf eine etablierte, auf dem Markt existierende Lösung zu setzen und daraus ein Produkt zu schnüren, greift man kurzerhand zu einer wenig erprobten Inhouse-Komponente und entwickelt dafür nach Vorlage ein neues Frontend.

Um die Motivation hinter der etwas seltsam anmutenden Aktion zu verstehen, hilft ein Blick auf die Details. Zunächst fällt hier die durchaus wechselvolle Geschichte auf, die Suse und Ceph eint. Zur Erinnerung: Ceph mit seinem Objektspeicher RADOS gilt bis heute am Markt als der Königsweg für skalierbaren Speicher auf Open-Source-Basis. Das liegt auch und vor allem an der Vielseitigkeit der Lösung: Der Objektspeicher im Kern des Produkts lässt sich von außen über verschiedene Schnittstellen ansteuern. Eine dieser Schnittstellen ist das RADOS-Gateway, das RADOS im Hintergrund als Storage-Lösung nutzt, nach außen jedoch eine mit Amazons S3 kompatible ReST-Schnittstelle exponiert.

Kombiniert mit klassischer Infrastruktur wie einem Load Balancer und einer passenden DNS-Konfiguration, lässt sich das Gespann problemlos als lokale Instanz betreiben. Auch der mit Abstand größte und am häufigsten vorgetragene Kritikpunkt an Ceph spielt in diesem Konstrukt zur Abwechslung einmal keine Rolle: Die hohe Latenz bei Schreibzugriffen, mit der RADOS es durchaus zu tun hat, ist egal, wenn die Latenz zwischen Client und Server das Vielfache der Storage-Latenz beträgt. Und genau das ist beim Aufruf von Websites oder webbasierten Diensten ja regelmäßig der Fall.

Suse selbst gehörte einst zu den größten Befürwortern von RADOS und Ceph. Noch 2014 munkelten manche Beobachter der Szene, Suse wolle Inktank kaufen, die Firma hinter RADOS. Die roten Hüte kamen den Nürnbergern dann aber zuvor und übernahmen Inktank, um es danach als weitgehend autarke Firma weiter Ceph entwickeln zu lassen. Nur langsam ging Inktank irgendwann in Red Hat auf; heute gehört das Unternehmen zur Storage Division von IBM.

Suse ging seinerzeit leer aus, berief sich jedoch darauf, dass Ceph ja noch immer eine Open-Source-Komponente sei und man es entsprechend weiter als Bestandteil eines eigenen Produkts nutzen könne. Suse Storage verschwand vor ein paar Jahren dann jedoch in der Versenkung: Im Rahmen der Fokussierung auf Container und Lean IT wollte man sich die Pflege eines eigenen Storage-Produkts offensichtlich nicht mehr zumuten. Dass sich die Begeisterung innerhalb der Nutzerschaft in engen Grenzen hielt, kann man sich auch ohne viel Fantasie vorstellen.

Longhorn als Kaufmasse

Wahr ist aber auch, dass Ceph seinerzeit noch nicht sonderlich gut mit der modernen Welt von Containern und Kubernetes kooperierte. Wer Ceph als Backend für K8s nutzen wollte, installierte üblicherweise einen autarken und selbst gemanagten Cluster mit Ceph und band Kubernetes an diesen Cluster mittels eines passenden CSI-Plugins an. Die komplette Pflege von Ceph war dann aber Handarbeit. Zwar ruft ein richtig konfigurierter Ceph-Cluster, sobald er einmal funktioniert, nur wenig Wartungs- oder Betriebsaufwand hervor, in einer reinen Kubernetes-Umgebung wirkt er aber dennoch wie ein Fremdkörper. Und Rook, das Ceph komplett innerhalb von Kubernetes ausrollt, existierte noch gar nicht, als Suse dem eigenen Ceph-Produkt den Garaus machte.

Hinzu kommt, dass Suse sich quasi versehentlich zusammen mit Rancher eine weitere Lösung für das Speichern von Daten ins Haus geholt hatte: Longhorn. Zwar wie RADOS eine verteilte Speicherlösung, funktioniert Longhorn aber unter der Haube völlig anders, schon weil es sich dabei nicht um einen Objektspeicher handelt. Dadurch lässt es sich leichter warten als Ceph, vor allem aber deutlich besser in Kubernetes integrieren. Freilich gab es im Rahmen des Suse-Rancher-Deals die Kubernetes-Integration für Longhorn gleich mit dazu, die bei Rancher als Inhouse-Lösung ein elementarer Bestandteil des Longhorn-Angebots war. So erklärt sich, wieso Suse auf der Suche nach einem Storage-Backend für eine eigene S3-Lösung nicht alte Ceph-Verbindungen reaktiviert hat, sondern lieber auf das Wissen und die Technik zugriff, die im Unternehmen bereits vorhanden sind.

Dumm nur: Für Longhorn existiert kein S3-Frontend, nativ lässt der Dienst sich also für den Zugriff per ReST-S3-Protokoll nicht verwenden. Über Umwege kam so doch wieder Ceph zum Handkuss. Das RADOS-Gateway ist innerhalb von Ceph schließlich eine autarke Komponente, die mit jedem beliebigen RADOS-Cluster kommunizieren kann. Baut man das RADOS-Gateway im Hintergrund auf ein anderes Storage-Backend um, behält aber den S3-Teil der Software, bekommt man eine Art generische S3-Schnittstelle. Eben das ist der Weg, für den Suse sich entschieden hat.

Ein alter Bekannter

Die S3gw-Software ist ein alter Bekannter, eine stark veränderte Version des RADOS-Gateway für Ceph. Weil Ceph vollständig unter freier Lizenz steht, stellt ein solcher Fork kein Problem dar. Ebenfalls hoch anrechnen muss man Suse, dass die Nürnberger auf bestehende und erprobte Technologie zurückgreifen, statt das Rad neu zu erfinden. Am Ende der Entwicklung steht heute ein S3-Cluster mit Longhorn im Backend, der sich komplett automatisiert innerhalb von Kubernetes in Betrieb nehmen lässt. Zu Suses aktueller Strategie passt der Dienst mithin wie die sprichwörtliche Faust aufs Auge.

Entsprechend solide zeigt sich das Gespann aus Longhorn und dem modifizierten S3gw in einem ersten Test. Das Setup geht, wie zu erwarten, leicht von der Hand. Der Administrator benötigt lediglich einen laufenden Kubernetes-Cluster, in dem auch der Paketmanager Helm aktiviert ist. Die einzelnen Komponenten, also Longhorn und S3gw, kommen dann in Form von Helm-Charts auf das System. Suses Dokumentation sieht hier zwar vor, zusätzlich zu Kubernetes auch noch Rancher auszurollen, technisch notwendig ist das allerdings nicht.

Hat man alle benötigten Charts ausgerollt, funktioniert Longhorn bereits. Zum Setup gesellen muss sich im nächsten Schritt aber auch noch eine Instanz des Cert-Managers, die für das Setup dynamische SSL-Zertifikate ausstellt. Das ist auch deshalb notwendig, weil S3 sich ohne SSL nicht sinnvoll betreiben lässt: Die meisten Clients würden aus guten Gründen eine unverschlüsselte Verbindung ablehnen. Ganz am Ende beschafft der Admin sich schließlich S3gw (Abbildung 3), das Suse in einem eigenen Github-Verzeichnis [1] ebenfalls als Helm-Chart zur Verfügung stellt (Abbildung 4).

Abbildung 3: Dank fertiger Helm-Charts gestaltet sich das Deployment von S3gw auf Longhorn aus Rancher heraus sehr simpel. Reif für den produktiven Einsatz ist die Lösung aber noch lange nicht. Quelle: Suse

Abbildung 4: Nach dem Setup von Longhorn und S3gw per Helm registriert sich das S3-Gateway automatisch als Client, der ein von Longhorn gestelltes Volume nutzt. Quelle: Suse

Mehraufwand

Das beschriebene Deployment-Szenario für Longhorn und S3gw ist sehr rudimentär und nicht produktionsreif, denn dafür fehlen viele Details. Wie bei Ceph üblich will man auch bei Longhorn das S3gw als skalierten Dienst hinter Load Balancern betreiben. Hier böte sich etwa der Einsatz von Istio an, das ganz im Vorbeigehen auch noch das Thema SSL abhandeln könnte, und zwar spezifisch für Verbindungen zur Außenwelt, also ins “echte” Internet.

Darüber hinaus macht das originale S3 einige Vorgaben im Hinblick auf die zu nutzenden Host-Namen und URLs. Noch immer gibt es beispielsweise zwei Formen, einen S3-Bucket anzusteuern. Die offizielle S3-Dokumentation bezeichnet diese als »https://bucket-name.s3.region-code.amazonaws.com/key-name« einerseits sowie »https://s3.region-code.amazonaws.com/bucket-name/key-name« andererseits. Letzterer Variante, den sogenannten Path-Style-URLs, wollte Amazon eigentlich bereits vor Jahren den Stecker ziehen. Letztlich gewährte der Anbieter seiner Kundschaft aber etliche Aufschübe, und aktuell steht gar kein finales Datum für die Abschaltung dieser URLs mehr im Raum. Gut möglich, dass AWS es sich also anders überlegt hat und die alte URL-Form auch weiterhin unterstützt.

Aus Anwendersicht wäre das eine gute Nachricht, denn gerade Nachbauten kommen mit den Path-Style-URLs deutlich besser zurecht als mit jenen URLs, bei denen der Name des Buckets Teil der URL ist. Wie wohl jeder Admin sich leicht vorzustellen vermag, ist für dieses Schema die Implementierung von SSL deutlich unkomplizierter und einfacher möglich. Bis auf Weiteres tun Admins jedenfalls gut daran, das Schema auch für private S3-Setups zu nutzen.

In der Praxis

Von den beiden Komponenten der Lösung, also Longhorn und S3gw, ist Longhorn mit Abstand die spannendere. Schließlich liegen hier echte Nutzdaten, also Daten von Wert, die sich im Zweifelsfall nur aus einem Backup wiederherstellen ließen. Aus Admin-Sicht ist die gute Nachricht, dass Longhorn als Vertreter einer Software-defined-Storage-Generation moderner Art ab Werk etliche Tools und Werkzeuge mitbringt, die die Arbeit mit der Software und vor allem deren Administration erleichtern.

Über eine Dekade haben etwa die Ceph-Entwickler gebraucht, bis für Ceph endlich ein brauchbares grafisches Frontend zur Verfügung stand, das Admins einen schnellen Überblick über den Zustand des Clusters vermitteln konnte. Longhorn kam hier deutlich schneller aus dem Quark: Eine grundlegende GUI gehörte hier im Grunde von Anfang an zum Lieferumfang. Sie lässt auch das Ändern mancher Einstellung zu, dient vorrangig aber zur Visualisierung und zur Statusabfrage (Abbildung 5).

Abbildung 5: Longhorn kommt ab Werk mit einer grafischen Oberfläche daher, die die Administration des Clusters aus Sicht des Administrators etwas angenehmer gestaltet. Quelle: Suse

Kritik an Longhorn

Wie Recherchen im Netz schnell zeigen, ist längst nicht jeder Nutzer glücklich mit Suses Entscheidung, Longhorn als Storage-Backend zu nutzen. Ähnlich wie Ceph hat Longhorn manche designbedingte Schwäche, doch wirken diese sich bei Longhorn zum Teil deutlich dramatischer auf den administrativen Alltag aus, als es etwa bei Ceph/RADOS der Fall wäre. Ein Beispiel aus der Praxis verdeutlicht das.

Geht bei einem Ceph-Cluster eine Festplatte kaputt, ist Ceph darauf ausgerichtet, mit dem Problem allein fertig zu werden. Nach einer Grace Period von zehn Minuten – wenn man die Standardkonfiguration nicht verändert – markiert RADOS die ausgefallene Platte als »down« und »out« und beginnt mit einem Recovery-Prozess. Der dient vorrangig dazu, nun nicht mehr im Cluster vorhandene Replikate von Objekten neu anzulegen. Das geht dann so lange, bis es für alle Objekte im Objektspeicher wieder die vorgeschriebene Anzahl an Replikaten gibt.

In der Theorie verfügt Longhorn über ähnliche Fähigkeiten, doch sind etliche Foren im Netz gepflastert von Berichten verärgerter Benutzer, wonach Longhorns Recovery-Funktionen mehr schaden als nutzen. Regelmäßig behaupten Longhorn-Administratoren etwa, dass ein simpler Recovery-Vorgang für eine ausgefallene Platte in Longhorn absurd lange dauere, zum Teil ist von mehreren Stunden die Rede. Hinzu kommen Berichte über instabiles Verhalten im laufenden Betrieb und miserable Performance, besonders bei der Verwendung von Festplatten. Auch SSD-basierte Longhorn-Cluster kommen in vielen Fällen nicht besser weg und erreichen laut den Aussagen ihrer Admins IOPS-Werte, die man eigentlich eher von Platten erwarten würde.

Inwiefern mancher Bericht dem Ärger des Augenblicks geschuldet ist, lässt sich aus der Ferne freilich nicht sagen. Dass eine relativ junge Storage-Lösung wie Longhorn anfangs aber mit vielen Kinderkrankheiten zu kämpfen hat, erscheint normal. Auch die Ceph-Entwickler können davon ein Lied singen. Anders als Longhorn existiert Ceph mittlerweile aber eben schon so lange und kommt so flächendeckend zum Einsatz, dass die meisten typischen Anfangsprobleme mittlerweile behoben sind.

Wer als Admin den Betrieb eines Longhorn-Clusters in Kubernetes für den S3-Zugang plant, sollte die Themen Recovery und Performance jedenfalls auf dem Zettel haben und den Cluster ausführlichen Tests unterziehen, bevor die Lösung live geht.

Noch nicht produktionsreif

Apropos live: Reif für den Einsatz in produktiven Umgebungen ist das Werkzeug laut Suse explizit noch nicht. Das macht sich tatsächlich auch an manchen Stellen bemerkbar, etwa bei der Benutzerverwaltung, in S3 ein komplexes Thema: Jeder Bucket ist einem Benutzer zugeordnet, der über den Zugriff darauf entscheidet. Beim offiziellen AWS fallen die benötigten Credentials automatisch aus der AWS-Konsole heraus. Ceph implementiert im RADOS-Gateway gleich eine komplett autarke Benutzerverwaltung, die sich per Kommandozeilenwerkzeug steuern lässt. Dabei beherrscht die im RADOS-Gateway implementierte Benutzerverwaltung alle relevanten Funktionen, um den Zugriff auf Buckets zu steuern.

S3gw, also der Longhorn-basierte Fork der Software, unterstützt die ja eigentlich vorhandenen Funktionen aber samt und sonders nicht. Aktuell besteht bei S3gw lediglich die Möglichkeit, einen einzelnen Benutzer mit statischem Passwort anzulegen, der anschließend Buckets erstellen und ändern kann. Hinzu kommt, dass sich aktuell kaum absehen lässt, in welche Richtung Suse dieses Thema entwickeln will. Secret Management und IAM sind in Kubernetes-basierten Umgebungen immer wieder Anlass für Debatten und teils hitzige Streitereien, und so etwas wie den heiligen Gral als Standardimplementierung gibt es bis heute nicht. Auf welche Weise Suse einen ohnehin schon nicht gut definierten Standard in einen in Kubernetes laufenden Dienst integrieren will, ist also eine durchaus interessante Frage. Dasselbe gilt für die Frage, ob Suse es hinbekommt, eine Anbindung an andere Dienste wie OpenID zu bauen. Im Augenblick wirkt es jedenfalls nicht so, als sei die an S3gw arbeitende Truppe sonderlich groß.

Obendrein hat sie genug andere Aufgaben am Hut. In ihrer Roadmap weisen die Entwickler beispielsweise darauf hin, dass ein erheblicher Teil der S3-Operationen, die das echte RADOS-Gateway problemlos beherrscht, in S3gw aktuell nicht funktionieren. Die fehlende Benutzerverwaltung zum Beispiel birgt quasi implizit das Problem, dass man auch keine ACLs verwenden kann. Nahezu sämtliche Bucket-Vorgänge funktionieren nicht, darunter das Lifecycle-Management eines Buckets, die Objektversionierung für Buckets oder Benachrichtigungen für Buckets. Dasselbe gilt für etliche Objektoperationen, etwa jene mit POST-Anfragen oder zum Kopieren von Objekten. Daran zeigt sich, dass es eben keine triviale Operation war, dem RADOS-Gateway seine RADOS-Anbindung unter den Füßen wegzuziehen und durch den Zugriff auf Longhorn zu ersetzen.

Fazit: Wirklich nötig?

Aus technischer Sicht erscheint Suses Lösung gut und funktional, befindet sich aber noch in einem sehr frühen Entwicklungsstadium. Auf dem Markt dürften nur wenige Lösungen existieren, mit denen sich ein kompletter, funktionierender S3-Cluster so schnell und unkompliziert in Betrieb nehmen lässt wie mit dem einmal ausgereiften Gespann aus Longhorn und S3gw.

Dennoch muss der Anbieter sich im Kontext der Lösung mehrere unangenehme Fragen gefallen lassen, beispielsweise, für wen diese Software denn letztlich echten Mehrwert bieten soll? Wie bereits erwähnt besteht kein Zweifel daran, dass ein S3-Dienst im Kontext einer modernen Webapplikation erhebliche Vorteile mit sich bringen kann, gerade, wenn er als Mini-CDN mit Cache-Funktion zum Einsatz kommt. Es erscheint jedoch unwahrscheinlich, dass der Betreiber eines Setups diese Funktionalität dezentral organisieren will. Wer sich auf Basis von S3 ein eigenes Inhouse-CDN bauen möchte, tut das in der Regel auf separater Hardware und mit entsprechender hochspezieller Konfiguration. Ob es dann aber noch ein Kubernetes braucht, scheint zumindest zweifelhaft.

Gleichzeitig muss Suse damit leben, dass unklar bleibt, wie ernst das Unternehmen es mit dem Produkt wirklich meint. Nach DeepSea, Suse Cloud, Suse Storage und etlichen anderen Produkten, die bei der Firma aus Nürnberg in der Vergangenheit im Mülleimer gelandet sind, erscheinen Sorgen und Bedenken von Admins und Nutzern jedenfalls nachvollziehbar. Wer auf der Suche nach einer lokalen S3-Implementierung ist, sollte sich die Produkte anderer Anbieter – von denen am Markt hinreichend viele existieren – jedenfalls ebenfalls anschauen und den Faktor der Nachhaltigkeit und der Investitionssicherheit eines Setups unbedingt mit in die Überlegungen einbeziehen. (jcb)