News

Nichts Neues (auf den ersten Blick)

Cumulus Linux, das Netzwerk-Betriebssystem auf Debian-Basis, macht erfahrenen Network Engineers den Einstieg leicht: Die wichtigen Einstellungen sind via CLI erreichbar, wobei sich das Interface an CLIs verbreiteter Hersteller orientiert. Dadurch finden sich Netzwerk-Spezialisten in der neuen Umgebung schnell zurecht und können auf dem Wissen aufbauen, welches sie sich bereits anderswo angeeignet haben. Auch nützliche Features, die sich in der Branche erst nach und nach durchsetzen, stehen auf Netzwerk-Geräten mit Cumulus Linux standardmässig zur Verfügung; so ist es z.B. möglich, einen Block von Kommandos in einem Rutsch anzuwenden – und auch wieder rückgängig zu machen.

Dass Cumulus Linux auf Debian basiert, eröffnet jedoch zusätzliche, entscheidende Möglichkeiten. Ein Login führt nicht in das vertraute, aber eingeschränkte CLI, sondern direkt in eine Linux-übliche Shell. Dabei ist das CLI zwar nur ein Kommando entfernt, vor allem aber kann man dank vollem root-Zugriff auch all die anderen Tools nutzen, die sich im Alltag eines System Engineers als unverzichtbar erweisen: von Utilities wie htop und watch über ein Config-Management (z.B. Ansible) bis hin zum Monitoring mittels Zabbix-Agent.

Effizienz durch Config-Management

Insbesondere die Möglichkeit, Netzwerk-Geräte mittels Config-Management zu verwalten, werden viele Cumulus-Anwender nicht mehr missen wollen. Während wir bei cloudscale.ch für das Server-Management schon länger auf Ansible setzen, ist dank Cumulus Linux nun auch die Verwaltung von Netzwerk-Geräten mittels Ansible möglich. In der einfachsten Form übernimmt Ansible die Bedienung des "NCLU" (Network Command Line Utility) genannten CLI: Mit vertrauten Kommandos lassen sich zahlreiche Switches und Router ohne manuelles Zutun einheitlich konfigurieren.

Das volle Potenzial lässt sich jedoch erst mit Jinja-Templates ausschöpfen: Statt langer Abfolgen einzelner Kommandos, bei denen man leicht die entscheidenden Variationen übersieht, pflegt man Templates in relativ kurzen und übersichtlichen Files. Dank dem Einsatz von Loops und Conditionals lassen sich lange und komplexe Konfigurationen übersichtlicher darstellen. Das Risiko von Flüchtigkeitsfehlern (z.B. inkonsistente MTU- oder VLAN-Konfigurationen) verringert sich dadurch massiv.

Die folgenden Ausschnitte illustrieren, wie wir mit dem Ansible Template-Modul /etc/network/interfaces auf unseren Switches populieren.

Ansible Inventory Variablen:

vrfs:
  mgmt:
    description: VRF Mgmt
    ipv4_address: 127.0.0.1/8
  quarantine:
    description: VRF Quarantine (for test purposes)
    ipv4_address: '{{ "10.0.0.0/24" | ipaddr(device_id) | ipaddr("address") }}/32'
  private:
    description: VRF Private (networks without a default gateway)
  public:
    description: VRF Public (networks with a default gateway)
    ipv4_address: '{{ "203.0.113.0/24" | ipaddr(device_id) | ipaddr("address") }}/32'
    ipv6_address: '{{ "2001:db8:bb::/64" | ipaddr(device_id) | ipaddr("address") }}/128'
  dci:
    description: VRF DCI (networks on data center interconnect)
    ipv4_address: '{{ "172.16.16.0/24" | ipaddr(device_id) | ipaddr("address") }}/32'

Jinja2 Template:

{% for name, vrf in vrfs.items() if name != "default" -%}
# {{ vrf.description }}
auto {{ name }}
iface {{ name }}
    {% if vrf.ipv6_address is defined -%}
    address {{ vrf.ipv6_address }}
    {% endif -%}
    {% if vrf.ipv4_address is defined -%}
    address {{ vrf.ipv4_address }}
    {% endif -%}
    vrf-table auto

{% endfor -%}

Komplett automatisiertes Provisioning

Die laufende Pflege der Konfiguration ist aber nur die halbe Miete. Wir haben uns entschieden, grössere Upgrades unserer Switches jeweils in Form einer kompletten Neuinstallation durchzuführen. Dadurch wird ein reproduzierbarer Zustand sichergestellt, und wir können den Upgrade-Prozess sowie andere Änderungen im Lab vorgängig beliebig oft testen. Für diesen Zweck hat Cumulus Networks "ONIE" (Open Network Install Environment) entwickelt: Ähnlich dem von Servern bekannten PXE-Environment ermöglicht dieses offene System das Booten und die anschliessende Installation des Betriebssystems via Netzwerk. Mit "ZTP" (Zero-Touch Provisioning) lassen sich beliebige Settings bereits vorab festlegen, so dass das neu installierte System ohne manuellen Zwischenschritt direkt mit Ansible fertig provisioniert werden kann.

Der nachfolgende Ausschnitt aus unserer ZTP-Konfiguration automatisiert Schritte, die nach der Neuinstallation eines Switches typischerweise nötig sind.

Ausschnitt aus unserem ztp.sh:

[...]

# In order to start switchd, you need to install a valid license
echo 'user@example.com|3DSpMBACDihILepwdy4/5Ecd34jlAg4h+FiE/9zZawtujnk3Fw' > /home/cumulus/license.txt
/usr/cumulus/bin/cl-license -i /home/cumulus/license.txt
systemctl restart switchd.service

# Move the eth0 (management) interface to a separate management VRF
/usr/bin/net add vrf mgmt && /usr/bin/net commit

# Drop SSH keys in order to log in without using a password
{% for key in ssh_keys %}
echo "{{ key }}" >> /home/cumulus/.ssh/authorized_keys
{% endfor %}

# The following line is required somewhere in the script file for execution to occur
# CUMULUS-AUTOPROVISIONING

[...]

Bei uns dauert die Neuinstallation eines Switches mit Cumulus Linux weniger als 10 Minuten. Dies erlaubt es uns, Anpassungen an der Konfiguration, neue Versionen oder den Upgrade-Pfad dahin praktisch beliebig oft durchzuspielen. Steht dann das Upgrade der produktiven Geräte an, wenden wir bloss noch den mehrfach getesteten Prozess an; Vertipper und Verwechslungen sind damit praktisch ausgeschlossen. Übrigens: ONIE muss von der jeweiligen Hardware unterstützt werden – Cumulus Networks selbst stellt aber keine solche her. Dass innert kürzester Zeit praktisch alle grossen Netzwerk-Hersteller ONIE integriert haben, verdeutlicht, wie sehr diese elegante Lösung zuvor gefehlt hatte.

Dass Cumulus Linux seine Wurzeln in Debian und Open-Source hat, passt natürlich gut zu unserer Philosophie. Die "Open-Source-DNA" zeigt sich aber auch in umgekehrter Richtung: Cumulus Networks hat beispielsweise die Implementation von VRF (Virtual Routing and Forwarding) im Linux-Kernel beigesteuert. Dadurch sind die Bereiche "Server" und "Netzwerk" noch näher zusammengerückt.

Offen und effizient,
Ihr cloudscale.ch-Team