Flexible IT in mittelständischen Unternehmen durch Open-Source: CEPH, , & Co

Tobias Doerffel

27.01.15 | 17.30 Uhr | Altes Heizhaus | TU Chemnitz Überblick

● Firmenvorstellung

● Rückblick

● Storage

● Virtualisierung

● Infrastrukturmanagement und -dienste

● AD und CIFS mit Samba

● E-Mail und Groupwaredienste

● Weitere Dienste

● Ausblick

2 Firmenvorstellung

● Gründung 2008 als Startup aus der TU Chemnitz heraus

● Entwicklung, Fertigung und Verkauf von kunden- und anwendungsspezifischen diskreten und integrierten elektronischen Lösungen

➔ ASICs

➔ Steuerungs- und Automatisierungstechnik

➔ Leistungselektronik

➔ Softwaresysteme für Microcontroller und Eingebettete Systeme (ARM)

● Heute: ca. 30 Mitarbeiter sowie 5 Studenten

● Neues Firmengebäude auf dem Technologie-Campus seit 2013

3 Rückblick I

● Die Anfangszeiten im TCC:

● einfaches Consumer-NAS für Projekt- und Homelaufwerke

● einfacher Plastikrouter für DNS/DHCP

● Webseite, E-Mail etc. bei Hostinganbieter

● 1 Jahr später im startup-Gebäude:

● Dedizierte Workstation mit HW-RAID5 und einfachen Samba-Freigaben ohne ACLs

● E-Box als Managementoberfläche für Nutzer, Freigaben, DNS usw.

● Bare-Metal-Installation

● Erste Virtualisierungsversuche mit KVM und einfachen Verwaltungsscripts: Linux- Terminalserver für ASIC-Entwicklung

4 Rückblick II

● 2010 – ca. 10 Mitarbeiter

● Gewachsene Anforderungen an Terminalserver: weiterer Server (HW-RAID5), jetzt mit Proxmox als KVM-Frontend

● VM-Plattenimages als Dateien im Host-Dateisystem

● 2011

● Mit der ASIC-Abteilung wächst auch der Bedarf an Rechenleistung für Simulationen → weiterer Server mit schneller CPU (VM-Storage: SW-RAID 1 lokal)

● Umstellung auf OpenAFS, da CIFS auf Linux-Clients in Multi-User-Umgebungen im Zusammenspiel mit Dateizugriffskontrolle nicht praktikabel (war)

● Differenzierte Dateizugriffsrechte via AFS-ACLs

5 Rückblick III

● 2012 – ca. 20 Mitarbeiter

● Lokaler Storage als Single-Point-of-Failure

● 2 neue Server mit SW-RAID5, 6 TB gespiegelt über DRBD → Live-Redundanz

● DRBD als LVM-PV → VM-Platten in LVM-LVs → VM-Live-Migration möglich

● Bereitstellung von LVM-LVs via iSCSI

● 2013 – Umzug in eigenes neues Firmengebäude

● viele neue Anforderungen: Haustechnik, Telefonanlage, Firewall, WLAN, USV, ...

● komplette Neugestaltung der Netzwerkinfrastruktur (Cisco)

● Website, Mail/Groupware usw. jetzt im eigenen Haus dank S-DSL/statischer IP

● 2014

● DRBD zu unverlässig und vor allem unflexibel → Migration auf CEPH/RBD

6 Storage – Einführung

● CEPH:

● Verteiltes, redundantes und hochskalierbares Storage-System ohne SPOF

● Open-Source (LGPL)

● Selbstheilung

● Einsatz von kostengünstiger Standardhardware

● Zugriffskontrolle mittels Keyrings (analog zu Keytabs bei Kerberos)

● Definition beliebiger Redundanzszenarien und -hierarchien

● CEPH-Frontends:

● RADOSGW – S3/Swift-kompatibles REST-Gateway

● RBD – Zugriff auf Block-Device-Storage ähnlich wie iSCSI

● CEPH FS – POSIX-kompatibles Netzwerkdateisystem

7 CEPH – Grundlagen

● CEPH-Cluster besteht aus Storage-Pools

● Storage-Pools bestehen aus sog. Placement-Groups (PGs)

● Placement-Groups werden über alle verfügbaren OSDs (Object Storage Device – in der Regel eine physikalische Platte) verteilt und repliziert

● Placement-Groups enthalten die eigentlichen Datenobjekte

8 CEPH – Dienste

● 1 OSD-Daemon pro physikalischer Platte (OSD=Object Storage Device):

● Datenspeicherung

● Datenreplikation

● Wiederherstellung/Migration/Rebalancing

● Journal (auf separater Partition oder Platte)

● n Monitor-Daemons zur Verwaltung der Cluster-Map:

● Ungerade Anzahl → Quorum

● Monitor-Map, OSD-Map, PG-Map, CRUSH-Map

● Clients holen sich immer aktuelle Cluster-Map von beliebigem Monitor

● Ermittlung des Speicherorts (OSD) der PG eines Objekts

● Direkte Kommunikation mit OSD-Daemon

● Ggf. Ausweichen auf Kopien

9 Storage – eingesetzte Hardware

● 2x 1 HE Server:

● CPU: Xeon E3-1230 (4x 3,2 GHz), RAM: 16 GB

● I/O-Controller: LSI SAS 2008

● 2x Dual GBit-NICs

● HDD: 4x SATA 4 TB (CEPH-OSD), SSD: 2x 60 GB (OS+CEPH-Journal)

● 1x 2 HE Server:

● CPU: Xeon E3-1241 v3 (4x 3,5 GHz), RAM: 32 GB

● 2x Dual GBit-NICs

● I/O-Controller: LSI SAS2308

● HDD: 8x SAS 2 TB (CEPH-OSD), SSD: 2x 80 GB (OS+CEPH-Journal)

➔ 16 TB Nutzdaten 3-fach-redundant gespeichert

10 Aufbau des CEPH-Clusters

Public Server 1 Private Network Network MON 0 bond0 bond1 CEPH-Client- OSD 0 OSD 1 OSD 2 OSD 3 Replizierung Zugriff auf und Monitor- Datenwieder- und Disk- Server 2 herstellung Daemons MON 1 bond0 bond1 OSD 4 OSD 5 OSD 6 OSD 7

Server 3

MON 2

bond0 OSD 8 OSD 9 OSD 10 OSD 11 bond1

OSD 12 OSD 13 OSD 14 OSD 15

11 CEPH – Integration

● CEPH Block Storage (RBD)

● Größenänderung, Snapshotting, Image-Export/Import

● Unter Linux als Block-Device einbindbar

● RBD-Backend in KVM/QEMU

● VM-Platten können direkt im CEPH-Cluster liegen

● Ausfalltoleranz

● Discard-/Trim-Unterstützung bei Verwendung von virtio-scsi

● CEPH-Unterstützung in Proxmox seit Version 3.2

● Web-UI für CEPH-Cluster-Administration

● Hilfsscripte zur vereinfachten Installation eines CEPH-Clusters

● Management von VM-Platten

12 Virtualisierung mit Proxmox

● Proxmox als Debian-basierte Open-Source-Virtualisierungslösung (AGPL)

● Technologische Grundlage: KVM

● Intuitive Weboberfläche

● Datacenter- und VM-Host-Management

● Storage-Management

● VM-Management

● Backup-Management

● Rechte-, Rollen- und Nutzerverwaltung

● AD-Integration möglich

● HA-Unterstützung (Cluster-Filesystem für Konfigurationsdateien, Fencing etc.)

● Firewalls für VMs seit Version 3.3

13 Infrastruktur mit Zentyal

● Zentyal: -basierter Small-Business-Server

● Als Community-Edition frei verfügbar

● Integration einer Vielzahl von Diensten/Technologien

● mit Samba 4 (inkl. LDAP/Kerberos)

● DHCP/DNS/NTP

● RADIUS

● CUPS

● Firewall

● OpenVPN

● Certification Authority

● ...

● Intuitive Web-UI für alle Module

14 AD/CIFS mit Samba

● Zentyal-Server als Primary Domain Controller

● Nutzer-, Gruppen- und Computerverwaltung

● Administration auch mit Windows-Remoteserver-Verwaltungstools möglich

● Debian-VM mit Sernet-Samba-Paketen als CIFS-Server

● Virtuelle HD (4 TB, ext4) als CIFS-Wurzelverzeichnis freigegeben

● Scriptgesteuerte Verwaltung der CIFS-ACLs auf Basis von Volume-Metadateien

● Volumenschattenkopien („Vorgängerversionen“)

● Testbetrieb 2014: btrfs-Volumes und vfs_shadow_copy2-Modul

● Erneute Umsetzung mit vfs_snapper geplant

● Gute Unterstützung auf Windows- und Linux-Clients

15 AD/CIFS-Integration unter Linux

● Linux-Hosts dank Samba/winbind vollwertige Domainmitglieder

kinit Administrator net ads join -k

● Nutzer- und Gruppenauflösung via Winbind (libnss-winbind)

● Zugriffskontrolle auf Grundlage von Kerberostickets (sec=krb5)

➔ Voraussetzungen:

● Funktionierende Kerberos-Client-Einrichtung (krb5.conf)

● Userspace: key-utils (1.5.5+) und cifs-utils (6.0+)

16 CIFS-Dateizugriff unter Linux

● CIFS-Wurzelverzeichnis zentral gemountet (via HOST$@REALM)

➔ ACLs im Wurzelverzeichnis so gesetzt, dass alle Mitgliedern von „Domain Computers“ Leserechte besitzen

● Individuelle CIFS-Sitzungen für jeden Nutzer dank Multiuser-Feature:

➔ Voraussetzungen:

● Kerberos-Security

● aktueller Kernel (3.10+) → Mountoption multiuser

➔ UID/GID und Dateimodi werden clientseitig emuliert, beim Zugriff aber ignoriert

➔ Server prüft ACLs

● Weiterführende Details z.B. unter

https://www.redhat.com/promo/summit/2010/presentations/summit/in-the-weeds/wed/jlayton-310-interoperability/jlayton_summit_2010-Final.pdf

17 Probleme mit CIFS unter Linux

● DFS im Zusammenspiel mit aktivierten POSIX-Extensions (FIFOs, Symlinks, …) noch nicht zuverlässig (Stand 2014)

➔ DFS-Referrals werden dem Client als spezielle Symlinks übermittelt, die mit aktivierten POSIX-Extensions nicht richtig aufgelöst werden

● FS-Cache-Unterstützung experimentell

➔ Innerhalb von VMs im Zusammenspiel mit virtio-balloon Abstürze beobachtet (Stand 2014)

● Op-Locks (Level II) erlauben inzwischen auch Byte-Range-Locks, aber auch hier noch Stabilitätsprobleme

18 E-Mail & Groupware – Einführung

● bis 2013: Einsatz von eGroupware bei Webhoster

● Anforderungen:

● Kontrolle über Daten

● Gute Outlook-Kompatibilität

● Features: E-Mail, Kalender, Adressbücher

● Einfache Anbindung von Mobilgeräten

● Rechteverwaltung

● Integration mit weiteren webbasierten Diensten

● Linux-Server als Grundlage

19 E-Mail-Server mit Zentyal

● E-Mail-Server-Komponenten in Zentyal integriert und vorkonfiguriert (, , spamassasin, amavis, pyzor)

● Einrichtung und Konfiguration des Mailservers komplett über Web-UI

● Maildomains

● Greylisting

● Mailfilter (Antivirus, Antispam)

● Mailverteiler

● Dienste (POP3, IMAP, SMTP)

● Relaying-Regeln

● Zentrale Nutzer- und Gruppenverwaltung

20 Zarafa-Groupware

● umfassende E-Mail- und Groupware-Lösung

● Gute Kompatibilität mit MS Outlook mittels Zarafa-Plugin

➔ Outlook-Support voraussichtlich nur noch bis Q1/2016

● Active-Sync mit Hilfe von z-push

● Weboberfläche mit allen Features, die auch MS Outlook bietet

● Umfassende Rechteverwaltung

● Jährliche Lizenzkosten für 40 Outlook-Nutzer im 3-stelligen Bereich

● Python-API sowie Konsolen-Managementtools

21 Zarafa & Zentyal

● Zarafa ebenfalls in Zentyal integriert (LDAP)

● Zarafa-Account-Optionen über Zentyal-Nutzerverwaltung zugänglich

● Einstellungen für Zarafa-Gateways: POP3, IMAP, iCal und ActiveSync

● Problem: seit Zentyal 4.0 keine Zarafa-Unterstützung mehr

● stattdessen: OpenChange, eine freie und Exchange-kompatible Lösung mit Active- Directory-Anbindung

● OpenChange (noch) kein vollwertiger Ersatz (Stand 2014)

● Bis auf weiteres: Betrieb mit Zentyal 3.x

22 OwnCloud

● Datenaustausch mit der Außenwelt

● Anbindung an Zentyal über LDAP-Backend

● Storage derzeit über virtuelle Platte im CEPH-Cluster mit ext4

● Direkte Anbindung über OwnCloud-S3-Backend an CEPH-RADOSGW möglich

➔ Vorteil: virtuelle Platte bzw. deren Größe muss nicht von Hand verwaltet werden

● Desktop-Clients für alle Plattformen verfügbar

● WebDAV-Schnittstelle

● PostgreSQL als Datenbanksystem

23 GitLab

● Zentrale Git-Repositories inkl. feingranularer Rechteverwaltung

● LDAP-Integration

➔ Single-Sign-On mit Kerberos noch nicht offiziell verfügbar, aber geplant

● Zugriffskontrolle auf Repositories mittels SSH-Schlüsseln

● Issue-Tracker

➔ Auch als Ticketsystem für IT verwendet

● Integration mit GitLab-CI

➔ Software wird in pbuilder-Umgebungen automatisch gebaut und getestet

24 Ausblick

● Identity-Management-System

● Verwaltung von Volumezugriffsrechten über Web-UI durch Volumeverantwortlichen

● WLAN-Accounting

● Sichere Lösungen für Road Warrior / Zweifaktorauthentifizierung

● Ggf. Groupware-Migration und/oder Einsatz von Univention Corporate Server

● Implementierung von snapper (www.snapper.io)

● Implementierung von check_MK oder vergleichbarer Monitoringlösung

25 Vielen Dank für die Aufmerksamkeit!