Seite wählen

NETWAYS Blog

Monthly Snap Oktober 2023

von | Nov 3, 2023 |

In Nürnberg standen in Oktober die Vorbereitungen und Vorfreude auf die OSMC im Vordergrund. Die Open Source Monitoring Conference ist natürlich bei NETWAYS der Höhepunkt des Herbstes, wenn nicht sogar der des ganzen Jahres. Irene bedankte sich im Blog bei den tollen Sponsoren der Konferenz.

Aber ein paar andere Themen haben uns auch beschäftigt, zum Beispiel:

 

Ceph Backfilling Crash

Achim hat langjährige Erfahrung mit Ceph Clusters und berichtete vom Auftauchen eines unerwarteten Problems und wie es sich am Ende lösen ließ.

 

 

 

Kubernetes 101

Daniel B. schließ die Blogreihe über Kubernetes ab mit dem wichtigen Thema:  „Wie sichere ich Kubernetes ab“. Er ging auf mehrere Aspekte ein, von Zugriffskontrolle zu Anwendungssicherheit, und zog dabei ein interessantes Fazit.

 

 

 

NETWAYS Schulungen

Unsere Open Source Schulungen sind sehr beliebt, und viele Teilnehmer kommen gerne wieder! Dies tritt vor Allem auf unsere Schulungen hier in Nürnberg zu, aber mittlerweile sind auch unsere Online- Schulungen sehr beliebt, da sie trotz Abstand sehr persönlich und individuell gestaltet werden, natürlich mit ganz vielen praktischen Übungen. Irene stellte einige der Trainings vor.

 

 

 

Und was war sonst so los?

Katja berichtete, dass das Archiv der stackconf 2023 jetzt online ist, Markus O. gab uns wieder die neuen GitHub Releases, in der Blogreihe NETWAYS Chefs könnt ihr den ersten von zwei Beiträgen vom Grillen der Azubis durchlesen (und die Rezepte nachkochen). In in der Blogreihe NETWAYS stellt sich vor könnt ihr diesmal Jolien und Cecilia kennenlernen!

Dein Wunschthema war im Oktober wieder nicht dabei? Schreib uns einfach, dann wissen wir Bescheid. Und Wünsche erfüllen wir total gerne 😊. Bis zum nächsten Mal!

 

Header Foto von Hari Seldon auf Unsplash

Catharina Celikel
Catharina Celikel
Office Manager
Catharina unterstützt seit März 2016 unsere Abteilung Finance & Administration. Die gebürtige Norwegerin ist Fremdsprachenkorrespondentin für Englisch. Als Office Manager kümmert sie sich deshalb nicht nur um das Tagesgeschäft sondern übernimmt nebenbei zusätzlich einen Großteil der Übersetzungen. Privat ist der bekennende Bücherwurm am liebsten mit dem Fahrrad unterwegs.
Lies mehr von Catharina und triff unser Team

Ceph Backfilling Crash: Datenintegrität manuell wiederherstellen

von | Okt 18, 2023 |

Seit vielen Jahren haben wir Ceph im Einsatz. Unser erstes produktives Cluster begleitet uns seit 2015. Auch wenn die ersten Major-Updates des Clusters holprig verliefen ist die nötige Pflege des Clusters mit jedem Release von Ceph geringer geworden. Abgesehen vom Einspielen der Updates oder dem Tauschen von kaputten Festplatten ist wenig am Ceph Cluster zu tun, umso unerwarteter traf uns ein Fehler in der Replikation der Snapshots. Die Lösung des Problems hat sich über eine längere Zeit gezogen und mit diesem Blogpost hoffe ich anderen Ceph-Administratoren schneller auf den richtigen Weg zu verhelfen. Aber zuerst eine kleine Begriffserklärung.

Wie werden Daten im Ceph gespeichert?

Speichert man Daten (z.B. Objekt O) in ein Ceph Cluster wird dieses einer Placementgruppe (PG 1.1) zugeordnet. PG 1.1 besteht aus drei Festplatten (wir nennen diese OSDs) und das Objekt O wird auf alle drei OSDs (osd.1, osd.2, osd.3) gespeichert.
Fällt nun osd.3 aus, wird eine andere Festplatte (osd.4) zu der PG 1.1 zugeordnet und Daten werden von osd.1 auf osd.4 kopiert. Dieser Prozess heißt backfilling. Die Verfügbarkeit und die Integrität der Daten ist währenddessen nie gefährdet und der Ausfall von osd.3 ist schnell wieder behoben. Die Bereitschaft wird nicht geweckt und die kaputte Festplatte wird zu normalen Betriebszeiten ersetzt.

Was ist schief gelaufen?

Beim backfilling einer PG kam es zu einem ceph_assert(clone_overlap.count(clone)) mit dem sich die OSDs der Placementgruppen selbst stoppen. In Kombination mit systemd wurden die OSDs mehrfach neu gestartet (bis zum erreichen der StartLimitsBurst) und sind immer wieder in den assert gelaufen wodurch wir folgende Ausgangslage vorfanden:

  • PG 1.1 hatte nur noch osd.1 mit vollständigen aktuellen Daten
  • osd.2 und osd.4 konnten auf Grund des Bugs nicht mit den aktuellen Daten versorgt werden (backfilling)
  • Tools zum debuggen des Problems lieferten keine Informationen
  • deep-scrub (und damit auch repair) haben den gleichen Bug ausgelöst

Wie das Cluster genau in den Zustand kam ist uns unklar. Wir vermuten eine Kombination aus einer kaputter Festplatte, durch den Bug verursachten Crashes der OSDs und dem gleichzeitigen erstellen und löschen von Snapshots.

Was bedeutet das für die Datenintegrität und Verfügbarkeit?

  • osd.1 hat alle aktuellen Objekte und ist voll funktionsfähig
  • ein Ausfall von osd.1 führt zu Datenverlust
  • ein temporärer Ausfall bzw. Neustart von osd.1 führt zur nicht Verfügbarkeit der Objekte in PG 1.1 (down)
  • eine automatische Replikation der Daten ist nicht möglich
  • Snapshots auf PG 1.1 werden nicht gelöscht und häufen sich an
  • Scrubbing für PG 1.1 wird nicht durchgeführt

 

Lösung

Die Logdatein der OSDs lassen vermuten, dass fehlerhafte Clones (osd_types.cc: In function ‚uint64_t SnapSet::get_clone_bytes(snapid_t) const‘) beim backfilling den ceph_assert(clone_overlap.count(clone)) auslösen. In den bekannten Mailinglisten haben wir erste Hinweise auf einen Bug gefunden der in allen aktuellen Versionen (Nautilus bis Quincy) zu finden ist.
Die hier aufgelisteten Befehle können sehr leicht zum Datenverlust führen. Die Informationen sollen jedem Ceph-Admin der in einer ähnlichen Lage ist Hilfestellung leisten. Wir können nicht gewähren, dass die Lösung auf allgemeingültig funktioniert!

Lösungsansätze waren dort auch zu finden, welche teilweise positiv aber auch negativ bestätigt wurden. Einige Betroffene konnten das Problem nur mit dem löschen der PG lösen, was mit Datenverlust einhergeht und natürlich zu vermeiden ist. In unserem Fall hatten wir die aktuelle Daten verfügbar und ein weiteres unabhängiges Ceph Cluster welches im Disasterfall ein maximal 24 Stunden altes Backup bereitstellt.

1. Verfügbarkeit des PG 1.1 gewährleisten

Damit der letzte verbleibende osd.1 nicht regelmäßig auf den Bug trifft und sich neu startet haben wir das backfilling verhindert (ceph daemon osd. config set osd_max_backfills 0). Damit ist osd.1 und damit PG 1.1 dauerhaft verfügbar und für alle Clients wie gewohnt nutzbar. Hiermit wird aber auch das backfilling für alle anderen PGs auf osd.0 verhindert.

2. Wiederherstellung der Replikation

Zur manuelle wiederherstellen der Replikation gibt es die Möglichkeit Placementgruppen aus einem gestoppten OSD zu exportieren und in andere OSDs wieder zu importieren. Man führt das backfilling sozusagen manuell aus. Hierbei spielt es eigentlich auch keine Rolle auf welchen OSD die PG eingespielt wird. Ceph erkennt selbstständig die PG (pg[…] transitioning to Stray) und kopiert die Daten selbstständig zum richtigen OSD. Je nach Situation kann es auch nötig sein die PG von allen OSDs zu entfernen. ceph pg 1.1 query liefert hier genauere Information zu den OSDs mit Objekten aus der PG.

Für die Prozedur benötigt man drei Befehle:

ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-1 --no-mon-config --pgid 1.1 --op export --file /tmp/pg-1.1.export 
ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-2 --no-mon-config --op import --file /tmp/pg-1.1.export

Die OSDs müssen dazu gestoppt sein und sollte die PG schon vorher auf dem OSD vorhanden sein muss diese zuerst gelöscht werden:

ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-2 --pgid 1.1 --op remove --force

 

Wer noch Filestore OSDs betreibt muss den Befehl um --type filestore --journal-path /var/lib/ceph/osd/ceph-1/journal erweitern.
Mit Filestore sollten auch owner und group kontrolliert werden. Im Beispiel muss /var/lib/ceph/osd/ceph-2/current/omap und /var/lib/ceph/osd/ceph-2/current/1.1_head und mit chwon -R ceph:ceph wieder angepasst werden.

Durch diese Maßnahme konnten wir osd.2 und osd.4 wieder auf den aktuellen Stand bringen was folgende Verbesserungen bringt:

  • alte Snapshots auf PG 1.1 werden wieder gelöscht
  • backfilling kann wieder aktiviert werden, wovon alle anderen PGs auf osd.1 profitieren
  • scrubbing und repair funktioniert wieder

Im Vergleich zum Anfang ist das Cluster wieder in einem guten Zustand. Alle Objekte werden wieder repliziert, die Verfügbarkeit und Integrität der Daten ist gewährleistet und PG 1.1 häuft nicht weiterhin alte Snapshots an. Allerdings sind die ursprünglichen Probleme noch nicht gelöst, da wir nur eine exakte Kopie der Daten an anderen Stellen eingespielt haben. Sollte ein backfilling für PG 1.1 nötig sein würde das Problem weiterhin auftreten.

3. Erkennen und löschen der fehlerhaften Clones

Mit funktionierenden (deep-)scrubbing sammelt Ceph auch wieder Daten über Integrität und Zustand der Objekte und Clones in der PG 1.1.

rados list-inconsistent-snapset 1.1 –format=json-pretty zeigt gefundene Fehler, Inkonsistenzen und die dazugehörigen Metadaten wie Objektnamen, SnapIDs (dezimal) und Fehlerbeschreibungen. Wir mussten hier die Fehler clone_missing und extra_clones manuell beheben. Weiter Fehler wie z.B. mismatch kann Ceph selbst im repair beheben.

Hinweis zum Format: Objekte und Clones werden in der Regel in folgendem Format angezeigt: rbd_data.dad3d1238e1f28.00000000000062d5:107BE rbd_data.dad3d1238e1f28 ist der block name prefix. 0000000000062d5 der Objektname. 107BE die SnapID (wird manchmal auch als Dezimalzahlen angezeigt).

Sind die Objekte identifiziert zeigt einem das ceph-objectstore-tool die nötigen Details um die Fehler zu beheben.

ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-1 --op list rbd_data.dad3d1238e1f28.00000000000062d5 
["1.1",{"oid":"rbd_data.dad3d1238e1f28.00000000000062d5","key":"","snapid":2225964,"hash":2449849216,"max":0,"pool":1,"namespace":"","max":0}] 
["1.1",{"oid":"rbd_data.dad3d1238e1f28.00000000000062d5","key":"","snapid":2226131,"hash":2449849216,"max":0,"pool":1,"namespace":"","max":0}] 
["1.1",{"oid":"rbd_data.dad3d1238e1f28.00000000000062d5","key":"","snapid":2224480,"hash":2449849216,"max":0,"pool":1,"namespace":"","max":0}]
["1.1",{"oid":"rbd_data.dad3d1238e1f28.00000000000062d5","key":"","snapid":-2,"hash":2449849216,"max":0,"pool":1,"namespace":"","max":0}]

 

Jede Zeile beschreibt einen Clone oder das Objekt selbst und wird als Parameter zum bereinigen der Fehler gebraucht.

Bereinigen von clone_missing

Im Fall von clone_missing kann man Metadaten eines Clones manuell vom Objekt entfernen. Hierfür wird remove-clone-metadata verwendet. Das Objekt des Snapshots wurde bereits entfernt.

ceph-objectstore-tool --pgid <pgid> '<Objektzeile>' remove-clone-metadata <snapid-decimal> 
ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-1 --pgid 1.1 '["1.1",{"oid":"rbd_data.dad3d1238e1f28.00000000000062d5","key":"","snapid":-2,"hash":2449849216,"max":0,"pool":1,"namespace":"","max":0}]' remove-clone-metadata 2225750

 

Bereinigen von extra_clones

Bei extra_clones handelt es sich um Clones welche im Filesystem noch zu finden sind, aber eigentlich schon gelöscht sein sollten. Man findet diese auch direkt im Filesystem. Diese kann man mit dem ceph-objectstore-tool entfernen:

ceph-objectstore-tool 'Snapshotzeile' remove 
ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-1 '["1.1",{"oid":"rbd_data.dad3d1238e1f28.00000000000062d5","key":"","snapid":2224480,"hash":2449849216,"max":0,"pool":1,"namespace":"","max":0}]' remove

 

Résumé

Das Bereinigen der Inkonsitenzen im Snapshot war der letzte Schritt zum wiederherstellen des Clusters. Diese Lösung zu finden hat mehrere Tage gedauert unter anderem auch weil wir natürlich das Löschen und wieder einspielen der PlacementGroup in einem anderen Cluster ausführlich getestet haben.

Brauchst Du Hilfe bei mit deinem Ceph Cluster? Schreibe uns gerne eine Nachricht oder melde Für mehr Inhalte zu dem Thema abonniere unser Newsletter.

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.
Lies mehr von Achim und triff unser Team

Docker Swarm auf Proxmox oder es muss nicht immer Kubernetes sein.

von | Dez 15, 2022 |

Neulich habe ich begonnen meine „Heim“-IT auf einen aktuellen Stand zu bringen. Da wir uns bei NETWAYS auch mit Proxmox Virtual Environment als Virtualisierungsplattform beschäftigen, habe ich mich ebenfalls für diese Plattform für meine drei NUC PC entschieden.

Sie bilden mit einem Ceph RBD (RADOS Block Devices) über alle drei Knoten die Basis für hochverfügbare virtuelle Maschinen oder LX Container. Für Shared Storage für Dateisysteme, z.B. für meine Nextcloud oder auch nur Zertifikate für die Web- und Mailserver ist im RBD auf Platz für mehrere CephFS.

Meine Nextcloud ist inzwischen über einige Docker Container verteilt, ich habe mich hier gegen die von Proxmox hauseigenen LXC entschieden, da ich mit Traefik als Proxy direkt auf die DockerAPI (siehe hier) zugreifen wollte, um weitere neue Webserver unkompliziert einbinden zu können. Zusätzlich versorgt mich Traefik automatisch mit benötigten Zertifikaten von Let’s Encrypt.

Kubernetes ist zwar als Technologie sehr interessant, aber meiner Ansicht nach, etwas für sehr große Umgebungen. Da ich sicherlich nicht über 200 Container hinaus komme, benutze ich Docker Swarm auf momentan drei VM. Zur Zeit ist diese Umgebung mit nur einigen Containern für die Nextcloud, Traefik und einem Webserver noch recht übersichtlich und lässt dich gut von der Kommandozeile verwalten, komme jedoch weitere Container hinzu, wird sich mit an Sicherheit grenzender Wahrscheinlichkeit auch eine webbasierte Management Console finden.

Auch durfte ich mich neulich auf der Arbeit mit SDN (Software Defined Network) im Zusammenhang mit Proxmox beschäftigen. Hiebei ging es um eine auf mehrere Standorte verteilte Umgebung, der Verbindung via VPN (hier Wireguard) und der über alle Standorte zur Verfügungsstellung eines einzigen Netzsegments. Proxmox bietet, z.Z. noch experimentell, auch hier die Konfiguration mittels GUI. Das zugrundeliegende OpenVSwitch ist aber natürlich stabil und kann notfalls auch per Hand von der Konsole in den entsprechenden Dateien eingerichtet werden.

Für mein Heimnetzwerk sicherlich zu groß gedacht, aber für den ein oder anderen vielleicht auch interessant. Bei Interesse … ihr wißt an wen ihr euch wenden könnt – NETWAYS.

Lennart Betz
Lennart Betz
Senior Consultant
Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.
Lies mehr von Lennart und triff unser Team

Ceph auf Raspberry Pi als Bastelstorage

von | Sep 22, 2022 |

Ceph auf Raspberry Pi als Bastelstorage ist eine (relativ) einfache Möglichkeit, eine Technologie wie Ceph auszuprobieren, ohne gleich Racks voller Server anschaffen zu müssen. Ceph hat mich schon sehr lange gereizt, es mal intensiver ansehen zu können, aber mich hat immer der doch nicht unerhebliche Hardware-Aufwand abgeschreckt. Nach etwas Recherche habe ich aber herausgefunden, dass man, mit einigen Kompromissen, durchaus ein taugliches System auch mit einfacher Hardware zum Laufen bekommen kann.

Da ich oft höre, dass ich zu viele Worte mache, dachte ich, ich lass den technischen Teil diesmal großteils weg und verlinke dafür auf die Anleitung, die ich selber benutzt habe. Doch eine Warnung vorweg: Das, was man sich damit bastelt, ist sicherlich nicht das, was man „Best Practices“ oder auch nur „stabil für Produktion“ nennen würde. Meiner Erfahrung nach reicht es aber auf jeden Fall für’s Home Lab, als Storage für einen Proxmox mit diversen Services für Home Automation (z.B. Homeassistant und Grafana mit InfluxDB) und als Ablöse für eine 10 Jahre alte Qnap (mit entsprechendem Backup jedenfalls).

Was ich verändert habe, zu der Anleitung ist folgendes

  • Statt PoE werden meine Raspis direkt mit Strom versorgt
  • Ich habe nur 3 Raspberry Pi, dafür weitere Knoten (siehe unten)
  • Statt der mikrigen USB Sticks, die hauptsächlich für Tests taugen, hab‘ ich jedem Raspi eine 8TB USB Platte verpasst (Muhahaha!)

Durch die insgesamt 24TB Storage, die sich bei mir ergeben haben, habe ich, trotz ausreichender Redundanz tatsächlich genug Platz, meine VMs und eben den Inhalt der Qnap dorthin übernehmen zu können. Da meine Raspberry Pi jeweils nur 4GB Ram haben, bin ich schon sehr weit von „Best Practices“ entfernt. Aber was soll ich sagen: Es funktioniert doch erstaunlich gut. Aber, es hat sich auf jeden Fall bewährt, einige der Ceph-internen Dienste auf andere Hosts auszulagern. Im nächsten Abschnitt erkläre ich kurz, wie.

Das Ceph nutze ich als Storage Backend für 3 Proxmox Hosts, wofür die drei Raspberry Pi gerade noch ausreichend sind. Spätestens wenn man aber Ceph-FS (also das Filesystem, das man direkt einbinden kann) möchte, braucht man noch weitere Dienste. Das geht sich auf den Raspberry Pis dann insgesamt nicht mehr aus. Nach der Anleitung erhält man über das Ceph Dashboard eine Möglichkeit, Dienste auf Knoten im Cluster zu verschieben. Ein „Dienst“ In diesem Zusammenhang ist dann „unter der Haube“ ein Docker Container, der auf dem angegebenen Host gestartet wird. Dabei sucht sich Ceph per Default einfach Knoten aus, auf denen die Container gestartet werden – meist mehrere für Redundanz. Wenn man das steuern will, kann man den Knoten Tags verpassen und Services an Tags binden. Um jetzt die Last von den Raspberry Pi zu bekommen, habe ich nochmal drei Knoten mit Fedora Server hochgezogen, diesmal aber in Proxmox. Um kein Henne-Ei Problem zu erschaffen liegt deren Storage auf den lokalen SSDs der Proxmox Hypervisor. Damit beantwortet sich auch die Frage, ob man in Ceph verschiedene Architekturen mischen kann: Ja. Im Endeffekt sind jetzt die „OSD“, also die Dienste, die sich ums Storage Management kümmern, auf den Raspis und alles andere auf den VMs auf dem Proxmox.

Ceph-Dashboard

Screenshot meines Ceph Dashboard

Wie geht’s weiter

Das schöne an Ceph ist, dass man beim Ausbau so flexibel ist. Wenn ich bei der Qnap mehr Speicher möchte, müsste ich aktuell eine neue Qnap kaufen und alle Platten ersetzen. Dagegen kann ich bei Ceph einfach noch einen Raspi mit einer weiteren Platte dazu stellen. Damit hätte ich nicht nur mehr Speicher, sondern auch mehr Durchsatz, mehr Ram, mehr CPU und vor allem mehr Redundanz.

Wenn’s mal zu langsam wird, könnte ich auch NUCs oder ähnliches Gerät mit anbinden und Dienste, die besonders viel Geschwindigkeit brauchen, dort laufen lassen.

Was waren die Probleme?

Am meisten geärgert hat mich, dass ich nicht kapiert hatte, dass die Ceph Container nur auf 64 bit Systemen laufen. Das heisst, man braucht erstens einen Raspberry Pi 4 (oder einen bestimmten 3er) und ein 64bit OS. Die Anleitung zeigt hier nur auf die Fedora Installationen. Die 64bit Variante muss man sich erst noch raus suchen. Bevor ich das kapiert hatte, musste ich meine Raspi ein paar mal neu aufsetzen.

Die 8TB Platten wurden mir lange nicht angezeigt. Man kann Platten in der Version des Dashboards, das mir installiert wurde, wohl nicht für die Verwendung vorbereiten. Dafür gibt’s dann folgenden Befehl, der die cephadm CLI in einem eigenen Container startet.

./cephadm ceph-volume lvm zap /dev/sda

Der Befehl plättet dann die Platte /dev/sda und stellt sie als ganzes für Ceph bereit.

Fazit

Sonderlich lange läuft meine Ceph Installation noch nicht, weshalb ich noch keine Langzeiterfahrungen damit anführen kann. Bisher lässt sie sich aber gut an, um Ceph mal kennen zu lernen und auch ausreichend Platz für zuhause bereitstellen zu können. Ich bin froh, dass ich es probiert habe und werde das System wohl langsam und nach Bedarf ausbauen.

Thomas Widhalm
Thomas Widhalm
Manager Operations
Pronomina: er/ihm. Anrede: "Hey, Du" oder wenn's ganz förmlich sein muss "Herr". Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 ist er bei der NETWAYS. Zuerst als Consultant, jetzt als Leiter vom Operations Team der NETWAYS Professional Services, das unter anderem zuständig ist für Support und Betriebsunterstützung. Nebenbei hat er sich noch auf alles mögliche rund um den Elastic Stack spezialisiert, schreibt und hält Schulungen und macht auch noch das eine oder andere Consulting zum Thema. Privat begeistert er sich für Outdoorausrüstung und Tarnmuster, was ihm schon mal schiefe Blicke einbringt...
Lies mehr von Thomas und triff unser Team

You missed out OSDC? — Sign up for OSCamp!

von | Mai 15, 2019 | , , ,

Hey folks!

The OSDC 2019 is in full swing! You didn’t get to be part of the happy DevOps crowd meeting in Berlin?

Here‘s your chance to find some relief by participating in the next big Open Source thing happening in Berlin this week: Be part of our OSCamp on Ansible!

But you gotta be really fast to grab one of the few remaining seats at opensourcecamp.de

To get a glimpse of how it feels to be one of the OSDC guys, just take a look at the photos published so far on our Twitter channel. And start getting excited what’s coming up at the OSCamp…

See you in Berlin on Thursday!

Pamela Drescher
Pamela Drescher
Head of Marketing
Seit Dezember 2015 ist Pamela Anführerin des Marketing Teams. Mit ihrer stetig wachsenden Mannschaft arbeitet sie daran, NETWAYS nicht nur erfolgreicher, sondern auch immer schöner zu machen. Privat ist sie Dompteurin einer Horde von drei Kindern, zwei Pferden, drei Katzen und einem Hund. Für Langeweile bleibt also keine Zeit!
Lies mehr von Pamela und triff unser Team

Trainings

Web Services

Events