Unser Gast (00:00:00)

• Essy podcastet sonst bei der Nerdkunde: http://nerdkun.de
• Hat mal "Bindestrichinformatik" studiert und macht nun ihren berufsbegleitenden Master an der FH-Köln
  • Master Studium WebScience an der FH Köln: http://webscience.fh-koeln.de/live/
  • Basti und Dirk haben an der FH Köln auch ihren Master gemacht: http://www.medieninformatik.fh-koeln.de/website/general/startseite/startseite527/de/destartseitearticl1.php
  • Es gibt eine gewisse Deckungsgleichheit bei den Dozenten ^^
  • Vorlesungen finden abends via Webcam statt
  • Fokus (noch) auf Theorie, weniger Implementierung
  • Alle Klausuren (~8) sind an einem Wochenende
• Weiterempfehlungsgrad von WebScience: Kommt drauf an was man möchte ;-)

Deployment über Netzwerkfreigabe (00:10:44)

• In GST029 (http://geekstammtisch.de/#GST029) haben wir über Java-Entwicklung und Betrieb gesprochen, dabei viel der Begriff JBoss
• Und Essy setzt sich beruflich mit dem Betrieb von Anwendungen auf dem JBoss auseinander
• Essy arbeitet bei einem großen Rechenzentrum in Köln
• Betrieben werden dort die unterschiedlichsten Anwendungen (vor allem auch große Anwendungen mit vielen Abhängigkeiten)
• Herausforderungen: Leben mit komplexeren Prozessen als bei einem Fancy-Web-Startup™
• Deployment für den JBoss läuft zum Beispiel so ab:
  • Kunde legt Auszug aus seinem JBoss inkl. aller Konfigurationen auf einer Netzwerkfreigabe ab
  • Essy sucht Änderungen zwischen altem und neuem Stand heraus
  • Änderungen werden auf allen Systemen eingespielt
• Klingt umständlich und ist es auch, daher der Plan: Verwendung von Puppet: http://puppetlabs.com/
• Trotz der Strukturen und Prozesse ist es Essy und ihren Kollegen überlassen welche Tools intern verwendet werden, solange das Ergebnis am Ende passt
• Warum mit Puppet? Die nächste Version des Red Hat Enterprise Satellite Server (http://de.redhat.com/products/enterprise-linux/satellite/) setzt auf Puppet auf, daher war hier der Wunsch Puppet auch für weitere Bereiche einzusetzen

Server, Monitoring & Bereitschaft (00:26:00)

• Essy verantwortet den vollständigen Server
• Die Maschine wird lediglich von einem anderen Team bereitgestellt und übergeben
• Neben Maschinen für Kunden gibt es auch Maschinen für Forschung & Entwicklung
• Basis-Monitoring (Erreichbarkeit, Plattenfüllstand, etc) kommt mit dem Server mit
• Weiteres Monitoring lässt sich dann hinzufügen
• Monitoring läuft über Icinga (https://www.icinga.org/), einem Nagios (http://www.nagios.org/) Ableger
• Es gibt natürlich auch eine 24x7 Bereitschaft (in der nicht alle Server enthalten sind)
• Folge ist: Systeme werden so redundant und solide aufgesetzt, dass man Nachts nicht angerufen wird
• Das bedeutet auch, dass man Bereitschaft für Systeme machen muss, die man in der Regel nicht selbst betreut
• Dafür existiert dann entsprechende Dokumentation, die regelmäßig kontrolliert und auditiert wird

Softwarelandschaft (00:35:48)

• Unterschiedlichste Versionsstände von (beispielsweise) Java (von alt bis ganz neu)
• JBoss wird nicht in der Community-Variante verwendet, sondern in der kommerziell unterstützten
• Die Open-Source Variante wird auch nicht mehr JBoss heißen, sondern WildFly (https://github.com/wildfly/wildfly)
• Kostet nicht unerheblich, aber weniger im Vergleich zu anderen Produkten
• Support lohnt sich und wurde von Essy auch immer mal wieder in Anspruch genommen
• Als Dienstleister hat mal im Grunde keine andere Wahl als den kommerziellen Support sowohl von Red Hat Linux als auch JBoss zu nehmen
• Aus diesem Grund wird Ruby 1.8.7 auch immer noch von Red Hat gepflegt
• Was dann natürlich zu anderen Problemen führt ^^

Virtualisierung (00:40:40)

• Ein Großteil der Server laufen auf VMWare ESX Virtualisierung:
  • Der ESX-Hypervisor läuft direkt auf dem Server ohne weiteres Betriebssytem (https://en.wikipedia.org/wiki/VMware_ESX)
  • VMware (http://www.vmware.com/de)
  • VMware vSphere (http://www.vmware.com/de/products/vsphere)
  • VMware vCenter zum Verwalten/Clustern von mehreren VMware ESX Servern mit DRS (Dynamic Resource Scheduling) und HA (High Availability)(http://www.vmware.com/de/products/vcenter-server)
• Einige Dinge machen virtualisiert einfach keinen Sinn (manchmal auch aus Lizenzgründen…)
• Virtualisierung ist auf diesem Niveau schon sehr spaßig: Einfach mal laufende Server per Mausklick auf andere Hardware ziehen
• Für ein Rechenzentrum extrem sinnvoll

Prozesszertifizierung, Support und Monitoring der Kaffeemaschinen (00:44:35)

• Zertifizierung ist für einen Betreiber eines Rechenzentrums sehr wichtig
• Die ISO in diesem Fall ist die 27001 (http://de.wikipedia.org/wiki/ISO/IEC_27001)
• In diesem Zuge werden vor allem organisatorische Aspekte geprüft
• Neben der Dokumentation der Prozesse werden aber auch Gespräche mit Mitarbeitern geführt und exemplarisch Server betrachtet
• Das Audit findet jährlich statt
• Pentesting (http://de.wikipedia.org/wiki/Penetrationstest_(Informatik)) ist nicht Teil der Zertifizierung
• Glücklicherweise keine PCI Zertifizierung (http://de.wikipedia.org/wiki/PaymentCardIndustryDataSecurity_Standard)
• Bei der Vielzahl von Kunden und Projekten lassen sich umfangreiche Prozesse am Ende aber nicht vermeiden
• Das Maximum an Projekten, die man so übernimmt varriert und hängt von der Komplexität der jeweiligen Projekte ab
• Essy macht glücklicherweise kaum bis keinen Support (:
• Der Rest des Teams macht aber durchaus auch mehr 2nd-Level Support
• 2nd-Level Support hat keinen unmittelbaren Kontakt mit dem Kunden
• Inhouse Servicecenter für den First Level Support, wenn das nicht reicht, landen die Tickets im Team im Second Level Support
• Ärzte schrauben ganz gerne mal selbst an PCs rum und mailen an alle über den Mailverteiler
• Basti hat mal in einer Firma die Druckerlandschaft mitkonfiguriert, globales Auslesen von über SNMP von Tonerfüllständen mit Abgleich auf den Lagerbestand und ggf. direkte automatisierte Bestellung beim Händler
• Drucker sind natürlich auch im Icinga ;-) Telefone allerdings nicht mehr
• Icinga hört immer dort auf, wo es spezialisierte Tools der jeweilgen Produkte gibt
  • JBoss Operation Network (http://de.redhat.com/products/jbossenterprisemiddleware/operations-network/)
• Ungelöstes Problem: Monitoring und Alerting der Kaffeemaschinen

K-Fälle (01:02:35)

• K-Fälle wie Katastrophenfälle
• Redundanz bedeutet in diesem Fall auch, dass ein Rechenzentrum wegbrechen kann
• Für diesen Fall werden unterschiedliche Szenarien durchgespielt, um Lücken im System zu entdecken
• ESX-Cluster werden inkl. Storage zwischen den Rechenzentren gespiegelt und im Hot-Standby gehalten
• Dafür braucht man dann allerdings auch entsprechend Bandbreite
• Wir vermuten, dass Darkfibers in Köln zu bekommen kein Problem sein sollten
• Diese hohe Ausfallsicherheit lohnt sich erst für Projekte/System ab einem gewissen Grad, vorher macht es finanziell einfach keinen Sinn
• Finanziell bedeutet in diesem Fall weniger Hardware, sondern vor allem Personal, Organisation und Prozess
• Resultat ist in jedem Fall die Einbüßung von Flexibilität
• Hohe Anhängigkeiten zwischen verschiedenen Teams

Deployment, Koordination (01:10:30)

• Produktmanager koordinieren zwischen Kunde, externer Entwicklung und Infrastruktur
• Es gibt komplexe Abhängigkeiten zwischen verschiedenen System (sowohl in Hard- als auch Software)
• Zero-Downtime Deployments werden angestrebt, aber sind nicht immer möglich
• Vor Deployments: Wöchentliche Meetings von Teams zur Koordination

Tooling (01:16:00)

• Excel ist ein wichtiges Werkzeug hust, soll aber langsam abgelöst werden
• Confluence ist seit neustem im Einsatz (https://www.atlassian.com/de/software/confluence)
• OwnCloud (http://owncloud.org/) ist auch hinzugekommen

git, Gitlab, Stash, Github Enterprise (01:18:35)

• bisher SVN: https://subversion.apache.org/
• aber Essy hat Gitlab aufgesetzt: https://www.gitlab.com/
• Wir erzählen Essy von Stash: https://www.atlassian.com/software/stash
  • Integration in Confluence & Co
  • Betrieb macht man selber (wie bei GHE), für hosted nimmt man dann Bitbucket https://bitbucket.org/
• Ja, Github kann auch SVN sprechen!
• Github Enterprise: https://enterprise.github.com/

Administration und Automatisierung (01:25:00)

• Turnschuh-Administration: Monkey see, Monkey do!
• Automatisierung ist nicht for-free und ein anhaltender Prozess
• "Läuft's noch oder automatisierst du schon?" (@bascht)

Backups (01:28:20)

• Regelmäßig machen, lang genug aufbewahren UND
• Restore testen!
• Bei Essys Arbeitgeber gibt es dazu ein dediziertes Backup Team
• von VMs werden Snapshots erstellt und gesichert
• Restore ist ein Informationssicherheitsvorfall

Chaos Monkey (01:32:20)

• Wir fragen Essy, was mit dem Testen von Infrastruktur ist
• Chaos Monkey bei Netflix (http://techblog.netflix.com/2012/07/chaos-monkey-released-into-wild.html)
  • Chaos Gorilla macht ganze AWS Availability Zones aus
  • Mehr Monkeys… Latency Monkey, Conformity Monkey, Doctor Monkey, Janitor Monkey, Security Monkey, 10-18 Monkey: http://techblog.netflix.com/2011/07/netflix-simian-army.html
• Essy sagt, das sei im VMware Land (auch) möglich

IPv6 (01:38:05)

• Bei Essy noch kein IPv6
• IPv6 CRE: http://cre.fm/cre197-ipv6

Verschiedenes (01:38:30)

• es gibt einen regelmäßigen Austausch zwischen den Teams
• ActiveDirectory: https://en.wikipedia.org/wiki/Active_Directory

Telearbeit (01:45:00)

• Essy hat einen (Windows) Arbeitsrechner und darf mit ihrem Mac Book nicht ins Firmennetz
• WPA2: https://en.wikipedia.org/wiki/Wi-FiProtectedAccess
• Remote Zugang via Citrix, dann via Remote Desktop (RDP) zum Arbeitsrechner und von da aus zu den Servern
• Problem dabei: Keyboard Shortcuts funktionieren wegen dem hin- und hermapping nicht so richtig
• Essy kann Heimarbeit machen, sofern es keine Notwendigkeit gibt, Vorort zu arbeiten

Homesetup (01:53:55)

• Essy hat drei Displays (sowohl zuhause als auch auf der Arbeit) und sich kürzlich neue Hardware für einen Desktop Rechner gekauft
• Dirk und Basti haben schon EWIG keinen Rechner mehr komplett aus Einzelteilen gebaut

Abschluß (01:59:15)

• Es gibt wohl Führungen durch ein Vorzeigerechenzentrum!
• Girls'Day: http://www.girls-day.de/