Select Page

NETWAYS Blog

Out-of-Memory: Marathon 1.6+ und Heap Size

by | Jan 15, 2020 |

Auch wenn in Sachen Container Orchestrierung Kubernetes klar gegen Marathon und Mesos gewonnen hat bietet das Duo seit Jahren eine zuverlässig Plattform. Durch die stetige Weiterentwicklung und die Umstellung auf Systemd ändert sich leider auch immer wieder die Konfigurationen der Dienste.

Für einen stabilen Betrieb von Marathon sollte die maximale Heap-Size der Java Virtual Machine (JVM) eine angemessene Größe haben. Zu wenig Memory äußert sich z.B. durch erhöhte Antwortzeiten oder durch die Aktivierung des OOM-Killer. Wo in vergangenen Versionen und Konfigurationen noch die /etc/defaults/marathon zum Setzen der Javaoption verwendet wurde, kann man hier seit Marathon 1.6 vergeblich sein Glück suchen. Aus meiner Sicht ist ein Verzicht auf /etc/defaults/marathon und eine saubere Definition in einer systemd Unit-Datei natürlich zu begrüßen. Die Umgebungsvariablen lassen sich auch dort einfach definieren, aber wie genau muss das für Marathon aussehen?

# systemctl edit marathon.service
[Service]
Environment=JAVA_OPTS=-Xmx2g

Mit systemclt edit kann man eine bestehende Unit-Datei einfach erweitern und der Parameter Environment setzt die Umgebungsvariable.  Alternativ könnte man auch Environmentfile=/etc/defaults/marathon verwenden um das gewohnte Verhalten wieder herzustellen.

Nach dem Speichern braucht es einen Daemon-Reload, damit die neue Unit-Datei eingelesen wird.

# systemctl daemon-reload
# systemctl restart marathon.service

Eigentlich bleibt also alles beim Alten, man muss nur die zusätzlichen Parameter in die JAVA_OPTS setzen und den Service neu starten ?.

 

Achim Ledermüller
Achim Ledermüller
Senior Manager Cloud
Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist er für den Betrieb und die Weiterentwicklung unserer Cloud-Plattform verantwortlich.
Read more from Achim and meet the Team

Finde den Weg mit mtr und traceroute

by | May 8, 2019 | ,

Zum prüfen der Routing Pfade durch das eigene Netzwerk war bisher mtr mein bevorzugtes Tool. Mit  mtr -u 10.10.10.10 werden anstatt icmp udp Pakete/Pings verwendet wodurch man nach und nach alle Pfade durch das eigene Netzwerk findet.

Da sich aber seit Version 3.6 immer wieder das Verhalten des Linux Kernels bezüglich des ECMP Hashing geändert hat, kommt es auf Hosts mit mehreren Pfaden zum ersten Hop/Router immer häufiger vor, dass mtr nur einen Pfad anzeigt (je nach Kernel Version des Hosts). Dies kann sowohl an dem verwendeten Tool als auch an dem sysctl Parameter net.ipv4.fib_multipath_hash_policy liegen. Per default steht dieser auf 0 und bewirkt, dass nur die IP Adressen des Senders und des Empfängers zur Berechnung des Pfades verwendet werden. Setzt man die Hash Policy hingegen auf 1, werden zusätzlich die Ports von Sender und Empfänger mit in die Berechnung aufgenommen.

Da mtr die Ports nicht mit jedem Ping/Paket wechselt, findet man leider wieder nicht die Pfade zum ersten Hop. traceroute hingegen wechselt Sender- und Empfängerport mit jedem Paket wodurch nun alle Pfade gefunden werden. Leider ist traceroute nicht gleich traceroute. Unter Ubuntu findet man dies z.B. in den beiden Paketen inetutils-traceroute und traceroute, in zwei verschiedenen Implementationen mit unterschiedlichem Verhalten. Um unter Ubuntu alle Pfade zu finden sollte man sicherstellen, dass man die Binary aus dem Paket traceroute verwendet.

Kurz zusammengefasst gibt es für nicht angezeigte Pfade also mehrer Ursachen:

  • unterschiedliches ECMP Hashing im Linux Kernel (in Abhängigkeit der Version)
  • nicht explizit aktivierte Multipath Hash Policy
  • Verwendung von mtr oder einer unpassenden traceroute Implementation

Ich für meinen Teil werde bei mtr bleiben und einfach Sender und Empfänger vertauschen, der Router vor dem Empfänger macht ja schon immer alles richtig und berücksichtig auch Layer4.

 

 

 

Achim Ledermüller
Achim Ledermüller
Senior Manager Cloud
Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist er für den Betrieb und die Weiterentwicklung unserer Cloud-Plattform verantwortlich.
Read more from Achim and meet the Team

Infrastructure as Code mit Terraform und Openstack

by | Mar 27, 2019 | , ,

This entry is part 1 of 1 in the series Openstack und Terraform Beispiele

Der Drang weg von Hardware zu einer virtuellen oder sogar serverless Infrastruktur ist weiterhin stark. Nicht alle Administratoren oder Entwickler denken sofort an eine Containerplattform wie Kubernetes oder serverless functions sondern verlagern die eigene Infrastruktur in eine Public Cloud. Dadurch bleiben einem lästige Aufgaben in Kalt- und Warmgängen im Rechenzentrum erspart und es bleibt mehr Zeit für anderen Tätigkeiten. Cloud Plattformen wie OpenStack bieten alle nötigen virtuelle Ressourcen die auch in einem Rechenzentrum vorhanden sind, nur dass diese in wenigen Sekunden verfügbar sind. So kann man Komponente wie z.B. Router, Bridges, Interfaces, Server (VMs), Storage (von Block bis Object) und andere schnell und einfach über offene Schnittstellen erstellen und verwalten.

Dies gibt uns Administratoren auch die Möglichkeit unsere Infrastruktur in Textdateien zu beschreiben, zu automatisieren und zu verwalten. Unter dem Buzzword Infrastructure as Code findet man viele Tools die einem hier unterstützen und Terraform ist eines der bekanntesten um z.B. Ressourcen in OpenStack zu verwalten. Mit meinen nächsten Blogposts will ich mit vielen Beispielen zeigen wie man mit Terraform seine virtuelle Ressourcen in der Netways Cloud verwalten kann. Mehr zum Thema Terraform gibt es auch im Talk von Anton Babenko auf der OSDC.

Achim Ledermüller
Achim Ledermüller
Senior Manager Cloud
Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist er für den Betrieb und die Weiterentwicklung unserer Cloud-Plattform verantwortlich.
Read more from Achim and meet the Team

AJAX mit Ruby on Rails und :remote => true

by | Jan 16, 2019 | ,

Mit :remote => true bietet das das Ruby Webframework Rails eine sehr einfache Methode um mit Hilfe von AJAX eine Webseite zu aktualisieren. Dieses kann z.B. einfach zu HTML-Elementen wie Formulare, Buttons, Links und Checkboxen hinzugefügt werden. Dadurch werden z.B. gefüllte Formulare nicht mehr wie gewohnt an den Webserver gesendet, sondern mit AJAX. Man erspart dem Benutzer dadurch einen lästigen ggf. langwierigen Seitenaufbau. Im Gegenzug muss man sich aber selber um eine Aktualisierung der Webseite mit Hilfe von jQuery oder JavaScript kümmern.

Folgender Code in einem View erstellt eine Checkbox welche bei einem Klick mit Hilfe von AJAX einen HTTP Post an die angeben URL sendet:

[ruby]
check_box_tag(
"my_checkbox", "i_am_checked", false,
data: {
remote: true,
url: "my_checkbox/click",
method: "POST"
}
)
[/ruby]

Der Request muss in diesem Fall vom my_checkbox Controller angenommen und verarbeitet werden. Um die Ansicht des Benutzers zu ändern schickt man mit den bekannten Rails Methoden Javascript an den Browser zurück. Im my_checkbox_controller.rb erweitert man z.B. die respond_to einfach um ein format.js:

[ruby]
def click
respond_to do |format|
format.js {}
end
end
[/ruby]

Der dazugehörigen View (click.js.erb) wird somit an den Browser zurück gesendet und man kann per JavaScript die Webseite aktualisieren:

[javascript]
console.log(‘I am the response!’)
alert(‘You clicked the checkbox!’)
[/javascript]

Rails bietet mit :remote=>true somit eine wirklich einfach Methode um AJAX für seine Webseite einzusetzen!

Achim Ledermüller
Achim Ledermüller
Senior Manager Cloud
Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist er für den Betrieb und die Weiterentwicklung unserer Cloud-Plattform verantwortlich.
Read more from Achim and meet the Team

Get your RadosGW metrics into Ceilometer

by | Nov 21, 2018 | ,

With OpenStack it is an ease to provide an object store backed up from your Ceph RadosGW. But getting the usage metrics from Ceph into Ceilometer and Gnocchi is a little bit tricky. At least if you use OpenStack Pike. Following the official Pike documentation we need a RadosGW user with the correct credentials, usage logging enabled and a little bit of Ceilometer configuration:
 

$ radosgw-admin user create --uid ceilometer --display-name "ceilometer" --caps "usage=read;metadata=read;users=read;buckets=read"

# ceilometer.conf
[service_types]
radosgw = object-store
 
[rgw_admin_credentials]
access_key = access
secret_key = secret

 
Additionally we need to add the radosgw.* metrics to your ceilometer polling.yaml. At this point the official documentation lets you down with inconsistent metric names. In Pike, there are no entry points for radosgw.* metrics, only for the old rgw.* metrics. This is described in the bug #1726458. But following the defined entry points into the code, we see that these creates the new radosgw.* metrics. Well, adding the old metric names to your polling.yaml delivers you the new metric names… ¯\_(ツ)_/¯
 

# polling.yaml
- name: radosgw_pollsters
    interval: 1200
    meters:
    -  rgw.containers.objects
    -  rgw.containers.objects.size
    -  rgw.objects
    -  rgw.objects.size
    -  rgw.objects.containers
    -  rgw.usage

To bring it to an end, restarting “ceilometer central” will deliver your RadwosGW metrics to Gnocchi.

Achim Ledermüller
Achim Ledermüller
Senior Manager Cloud
Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist er für den Betrieb und die Weiterentwicklung unserer Cloud-Plattform verantwortlich.
Read more from Achim and meet the Team

Trainings

Web Services

Events