Variantenreiches Release: Das bietet Ihnen das neue evoila Service Broker Framework

[et_pb_section bb_built=“1″][et_pb_row][et_pb_column type=“4_4″][et_pb_text _builder_version=“3.0.105″ background_layout=“light“]

Vor der Entwicklung und Einführung eines neuen Release sieht man sich als Entwickler doch meist mit den gleichen Fragestellungen konfrontiert:

1. Wie können wir unser Produkt weiter verbessern?
2. Welche Features sind für unsere Kunden am nützlichsten?
3. Hoffentlich haben wir mit unseren Tests als Fehlerquellen abgedeckt?
4. Gibt es einschneidende Änderungen in der User Experience

Genau diese Fragen haben wir bei der Überarbeitung des Service Brokers aufgenommen und mit den Kundenerwartungen ergänzt. Herausgekommen ist ein variantenreiches Release, das sich u. a. durch folgende Eigenschaften auszeichnet:

• Hochverfügbarkeit durch Clustering aller Komponenten
• Load Balancing bei allen notwendigen Deployments (bspw. Postgres, MySQL) für optimale Performance
• Integrierte Auto Discovery für Monitoring der Services
• Mehr Insights in den Service Status durch verbesserte Monitoring Dashboards
• Möglichkeit von Pipeline Based Deployments via Concourse
• Erneuerung alle Deployments auf Bosh 2.0

[/et_pb_text][et_pb_text _builder_version=“3.0.105″ background_layout=“light“]

Und welche Änderungen des Service Brokers haben wir jetzt genau durchgeführt?

Konzentrieren wir uns doch zunächst auf den MongoDB Service Broker:

Hier war es unser Ziel, den bestehenden MongoDB Service Broker noch robuster zu machen. Um das zu erreichen, war es notwendig, einige Änderungen vorzunehmen. Das waren im Einzelnen:

• Dynamisches Scaling der Cluster Größe eines Replica Sets
• Transformation einer Single Instanz in ein Replica Set
• Erweiterung der Konfigurationsmöglichkeiten für MongoDB
• Update der Node und MongoDB Exporter und Erweiterung der Monitoring Dashboards für noch besseres Monitoring

PostgreSQL Service Broker – neue Architektur:

Beim Aufbau der neuen Architektur des evoila PostgreSQL Service Brokers stand für uns vor allem eines im Vordergrund:

„Wir wollten den PostgreSQL Service Broker vor allem die Ausfallsicherheit verbessern und flexibilität der deployments erhöhen.“

Dieses Ziel und dessen Umsetzung ist uns gelungen durch:

• Eine Erhöhung der Read Performance durch Verteilung der Anfragen an alle Cluster Knoten
• Die dynamische Skalierung ab einer Clustergröße von 2 Instanzen
• Ein gezieltes Update der Node und PostgreSQL Exporter und eine konsequente Erweiterung der Monitoring Dashboards für noch besseres Monitoring

[/et_pb_text][et_pb_text admin_label=“Update für den RabbitMQ Service Broker und den LBaaS Service Broker“ _builder_version=“3.0.105″ background_layout=“light“]

Update für den RabbitMQ Service Broker und den LBaaS Service Broker
Keine Frage, dass im Zuges dessen auch der RabbitMQ Service Broker und der LBaaS Service Brokers auf der to-do-Liste unserer Entwickler standen. Und was hat sich hier genau geändert? Das haben wir in der folgenden Übersicht für Sie zusammengefasst:

RabbitMQ Service Broker

• Update auf die aktuellsten Erlang und RabbitMQ Versionen
• Verbesserung der Parametrisierung kleiner Deployments durch dynamisch Disk-Threshold Angabe
• Dynamische Skalierung ab einer Clustergröße von 1 Instanz
• Update der Node und RabbitMQDB Exporter und Erweiterung der Monitoring Dashboards für noch besseres Monitoring

MySQL Service Broker

• Dynamische Skalierung ab einer Clustergröße von 2 Instanzen
• Update der Node und MySQL Exporter und Erweiterung der Monitoring Dashboards für noch besseres Monitoring

Dynamische Skalierung, Skalierungsentscheidungen und lernbasierte Skalierung – das können Sie vom neuen CF Autoscaling Service Broker erwarten:

Dynamische Skalierung
Die dynamische Skalierung war ein ganz entscheidendes Kriterium bei der Überarbeitung des CF Autoscaling Service Brokers. So ermöglicht der Service Broker nun die Skalierung basierend auf:

• Cpu (Unter- und Obergrenze)
• RAM (Unter- und Obergrenze)
• Latenz (Unter- und Obergrenze)
• Requests (quotientenbasiertes Verfahren)

[/et_pb_text][et_pb_text _builder_version=“3.0.105″ background_layout=“light“]

Skalierungsentscheidungen
Zudem können jetzt verschiedene Metriken miteinander kombiniert werden. Denn als Skalierungsentscheidungen gelten jetzt nicht oder, sondern und/oder basierte Regeln.
Des Weiteren ermöglicht es der Autoscaler auch eine lernbasierte Skalierung, die historische Datenintervalle betrachtet um Skalierungsentscheidungen zu treffen.
Als weitere grobe Rahmenparameter stehen neben den Skalierungsfaktoren die Definition von Ober- und Untergrenzen zur Verfügung, sowie die Definition einer Cooldown Time und unnötige Skalierung zu vermeiden.

Schnittstellen für die Anbindung von Kubernetes
Durch die generische Implementierung des CF Autoscaling Service Brokers ist auch bereits eine Schnittstelle für die Anbindung von Kubernetes vorgesehen. Diese können wir gerne auf Anfrage für Sie bereitstellen.

Jetzt testen und noch mehr erfahren:
Nutzen Sie jetzt die Chance, die Funktionalität des neuen CF Autoscaling Service Brokers selbst kennenzulernen und zu testen. Nehmen Sie dazu jetzt Kontakt mit uns auf unter: osb@evoila.de

[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]