OpenStack Summit Vancouver 2018 - Zusammenfassung

OpenStack Summit Vancouver 2018 - Zusammenfassung

Beim OpenStack Summit 2018 in Vancouver lag der Fokus neben den technischen Neuerungen diesmal noch stärker auf der Integration von Lösungen aus Anwenderseite. Sehr stark priorisiert wurde hierbei das Thema Entwicklung neuer Applikationen, welches unter dem Titel OpenDev CI/CD (Continuous Integration/ Continuous Delivery) zusätzliche, eigene Veranstaltungen für Software Entwickler erhielt. Im Bereich OpenDev CI/CD lag der Fokus wiederum ganz klar beim Thema Container und deren OpenStack Integration.

Natürlich wurden auf der OpenStack Summit auch weitere Ausblicke in die Zukunft von OpenStack gewährt. Diese werden vor allem durch die aktuellen Schwerpunkt- Themen von aktiven OpenStack-Nutzern vorangetrieben. Neben Künstlicher Intelligenz (Artificial Intelligence, AI) und Machine Learning (ML) standen auch Themen wie Serverless- und Edge-Computing ganz weit oben auf der Interessenliste der Anwender.

Ich stelle Schwerpunkt-Themen noch einmal kurz vor:

AI/ML

Machine Learning (ML) kann als ein Themenbereich des großen Entwicklungsfeldes „Artificial Intlligence“ (AI), auf deutsch „Künstliche Intelligenz“ (KI), angesehen werden, bei dem Computer selbst Muster erkennen sollen, um Allgorithmen hinsichtlich eines bestimmten Zieles zu optimieren. Es geht also um die Verbesserung von Genauigkeit, die Optimierung von Ergebnissen bzw. Verbesserung der Vorhersagen aufgrund von Lernprozessen. Die Maschine wird dafür mit empirischen Daten bzw. Trainings-Daten „gefüttert“.
AI/ML kann beispielsweise bei der Entwicklung neuer Software-Komponenten helfen, um Fehler in der Software oder Sicherheitslücken im Vorfeld zu erkennen und zu dezimieren.

Serverless ComputingServerless ist entgegen der Bezeichnung keine serverlose Architektur. Sie dient dazu, Entwicklern eine Umgebung zur Verfügung zu stellen, welche automatisch skaliert und den Entwickler weitestgehend aus der Orchestrierung von Infrastrukturkomponenten heraushält. Im Hintergrund arbeiten aber weiter die Cloud-Komponenten, die mithilfe von zuvor definierten Regeln und intelligenter Software automatisiert skalieren können.

Edge ComputingDas Datenaufkommen steigt zunehmend. Typische Beispiele hier sind Sensoren im IoT („Internet of things“), Smartphones mit Gesicht- und Spracherkennungsfunktion, Mess- und Analysedaten im Gesundheitswesen) Nicht immer ist es wirtschaftlich sinnvoll oder technisch möglich (Internet noch nicht ausgebaut, mobile Geräte), all die anfallenden Daten in eine weitentfernte Cloud zu senden (geringere Latenzen, weniger Bandbreite erforderlich).Edge Computing meint, gemäß der OpenStack Definition, Applikations-Entwicklern und IT-Dienstleistern Cloud Computing Ressourcen und eine Umgebung am Rande eines Netzwerks zur Verfügung zu stellen, mit dem Ziel, Compute, Speicher und Bandbreite an der Stelle der Dateneingabe/beim Enduser bereitzustellen. Diese Definition von Edge Computing wurde auf der OpenStack Summit im Rahmen eines Whitepapers veröffentlicht. Es gibt jedoch noch weitere, weniger stark eingegrenzte Definitionen.

Technische Neuerungen und Erweiterungen

Es wurden auf dem Vancouver Summit wieder viele interessante technische Erweiterungen vorgestellt. So wurden Zuul, eine Platform zur Continuous Integration and Delivery (CI/CD) und Kata Container, welches sichere Container in einer Mini-Variante einer VM zur Verfügung stellt, als offizielle OpenStack Software-Pakete aufgenommen. Weiterhin wurde die GPU-Unterstützung (GPU = graphic processor unit) wesentlich ausgebaut und ermöglicht es demnächst, virtuelle GPUs den einzelnen Instanzen zuzuordnen. Im gleichen Atemzug wurde hier auch die Unterstützung von FPGA (Field Programmable Gate Array) innerhalb virtueller Instanzen erwähnt. Dies ist eine sehr spezielle Erweiterung, um den Zugriff auf Chips zu gewähren, dessen Funktionsweise durch die Benutzer festgelegt werden kann. Die Integration von Kubernetes und Containern wurde durch das Netzwerk Projekt kuryr sehr stark vorangetrieben. Netzwerke werden hierbei nicht mehr über die virtuellen Netzwerke von OpenStack geleitet, sondern direkt über das Management der OpenStack Netzwerk-Switche miteinander verbunden. Eine Verschachtelung mehrerer Netzwerke entfällt somit, und man erreicht eine wesentlich bessere Performance, da das Problem an der Wurzel angepackt wurde.

Ein wesentliches Ziel der OpenStack Foundation war es, die Komplexität bei der Durchführung von Updates stark einzudämmen. So wurde mit dem Fast Forward Upgrade eine Möglichkeit eingeführt, von älteren Installation auf die aktuelle OpenStack Version zu aktualisieren, indem alle einzelne Updates in einem Prozess zusammengefasst wurden. Speziell, aber nicht nur für dieses Fast Forward Upgrade, wurde die Extended Maintenance eingeführt. Die Extended Maintenance soll einen längeren Support (mehr als die zur Zeit üblichen 18 Monate) für Community Mittglieder bieten. Betreiber erhalten dadurch mehr Freiraum bei der Durchführung von Updates. Zudem wird die Kommunikation zwischen Betreibern und Release-Entwicklern über ein gemeinsames Prozess- und Code-Repository verbessert, wenn Betreiber ein Upgrade durchführen und dabei Probleme finden.

Bis zur nächsten OpenStack Summit, das im November 2018 in Berlin stattfinden wird, haben sich die Entwickler-Teams zudem vorgenommen, alle API-Schnittstellen stark zu vereinheitlichen und zu vereinfachen. Es wird in allen Bereichen versucht, Komplexität bei der Verwendung der Cloud-Infrastrukturmanagement-Plattform zur reduzieren.

Die sinkende Teilnehmeranzahl beim OpenStack Summit und geringere Wachstumsraten bei der Anwenderzahl von OpenStack zeigt, dass das Thema mittlerweile differenzierter betrachtet wird. Der typische Anwender-Fall ist eine Private-Cloud-Lösung zur Bereitstellung einer Infrastruktur, die für die Gegebenheiten der Anwender entsprechend angepasst wird. Eine OpenStack-Umgebung bietet IT DevOps und Containerisierung eine ideale Möglichkeit zur Bereitstellung eben dieser Infrastruktur. Dies wird auch von der Cloud Native Computing Foundation bestätigt, in der OpenStack als Private Cloud Lösung für das Deployment verschiedener Services erfolgreich getestet wurde (Kubernetes, Prometheus, CoreDNS, etc.).

Diese Veränderungen innerhalb der OpenStack Community ließen sich bereits bei den ersten Ansprachen der Sponsoren erkennen. In Erinnerung bleiben wird wohl vor allem die Eröffnungskeynote von Mark Shuttleworth, dem CEO von Canonical und Gründer von Ubuntu, der die kontroverseste Präsentation hielt. Während der Keynote vor etwa 2600 technisch fokussierten Teilnehmern, stellte er fertige Produkt-Lösungen inkl. Preisangaben vor. ging er sehr intensiv auf das günstige Geschäftsmodell von Ubuntu ein und griff hiermit auch direkte Mitbewerber Red Hat und VMware an. Die Keynote wurde von der OpenStack Foundation kurzzeitig auf Youtube veröffentlicht, dann aber wieder entfernt. Die versprochene Live Demo zum Thema KubernetesDeployment kam während dieses Vortrags leider viel zu kurz, obwohl sie auch auf technischer Ebene sehr Interessant gewesen wäre.
Beim Thema Live-Demo konnte Red Hat wiederum sehr stark Punkten. Sie stellten eine komplette Live Demo aus verschiedenen Hardware Komponenten von IBM, Dell HP und Supermicro vor, um unter OpenStack ein Deployment von OpenShift auf physikalischer Hardware zu demonstrieren. Hierfür wurde der Installer vom Red Hat Director insoweit erweitert, dass dieser über die internen OpenStack Deployment Methoden direkt OpenShift Server installieren und bereitstellen kann. Weiterhin wurden die neuen Features der Red Hat OpenStack Platform 13 vorgestellt. Diese umfassen die bereits genannten Fast Forward Updates, ein in Zukunft primär über das Konfigurationsmanagement Ansible gesteuertes Deployment, Verschlüsselung von Storage und die Möglichkeit, Schlüssel über Barbican zu verwalten.

Weitere Informationen und alle aufgezeichneten Präsentationen findet ihr hier:

https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21895/join-the-edge-computing-initiative
https://www.openstack.org/summit/vancouver-2018/summit-schedule/#day=2018-05-21

https://www.youtube.com/user/OpenStackFoundation

OpenStack Summit Austin - Zusammenfassung

OpenStack Summit Austin

Im folgenden befindet sich eine Zusammenfassung des ersten Tages meines Besuchs auf der OpenStack Summit in Austin. Zwecks der Übersicht habe ich mich nur auf einige Keynotes und besuchte Sessions fokussiert, welche aus meiner Sicht die wichtigen und aktuellen Themen aus der OpenStack Welt sehr gut wiederspiegeln.

Keynotes

Gartner

Die erste Präsentation der OpenStack Summit in Austin wurde von Gartner vorgetragen. Bestandteil dieser Präsentation war die Vorstellung des zwei Mode Modells, in welchem davon die Rede ist, dass in Zukunft alle Unternehmen sowohl den traditionellen Weg (ITIL, CMMI, COBIT) als auch den neuen Weg der IT (Devops, Automation) nutzen werden. Begründet wurde dies u.a. damit, dass Entwicklungsprozesse schlecht oder nur sehr langsam mit ITIL Vorgaben zu vereinbaren sind und es für jeden Modus unausweichliche Vorteile gibt. Der parallele Betrieb beider Moden ergibt sich dadurch, dass die Entwicklungs und Testumgebungen anders betrachtet werden als der Produktivbetrieb und somit parallel und unter Berücksichtung der jeweiligen Vorteile betrieben werden können. Dabei zeichnet sich ab, dass die Traditionellen Applikationen in Zukunft immer mehr in Richtung Cloud optimiert werden (z.B. angepasste Skalierung) und Neuentwicklungen sich langsam zu Produktivanwendungen (z.B. Hohe Verfügbarkeit) entwickeln.

Mirantis

Von Mirantis kam eine Zusammenfassung aus dem Bereich der Umsetzung von OpenStack Lösungen. Hierbei wurde auf eine Gartner Studie bzgl. Problemen bei Cloud Projekten verwiesen. Fehler beim Umsetzen der Prozesse sowie fehlende Motivation bei der Umsetzung waren hierbei die größten Rückschläge (~50%). Im diesem Rahmen wurde auch erklärt, wie es zu diesen Problemen kommt. Eine sehr schöner Vergleich wurde hierbei mit dem Prozess erläutert, wie die Enduser eine interne Cloud bestellen und sich selbst mit dem Einsatz OpenStack für eine Public Cloud entscheiden würden, da die internen Prozesse im Weg sind. Der Erfolg von OpenStack hängt zu 10% an OpenStack selbst, zu 90% allerdings an den Mitarbeitern und Prozessen im Unternehmen.

VW

Mario Müller von der VW hat den Einsatz und die elementare Notwendigkeit von OpenStack bei der VW Vorgestellt. Durch den Wachstum der nächsten Jahre in allen Bereichen wie z.B. Car-Configurator und den Elektroautos und den hierfür zur Verfügung gestellten Services ist es notwendig eine dynamische und günstige Lösung zu finden, welche die IT Infrastruktur neu erfindet. Durch das VW Commitment "Cloud first" wurden auch noch weitere Projekte der VW wie z.B. der Cloud Foundry Einsatz als Platform as a Service vorgestellt.

Übersicht ausgewählter Sessions

Key Requirements for OpenStack Backup and Recovery

Von Trilio Data wurde ein Backup-Restore Konzept für komplette OpenStack Umgebungen vorgestellt. Es handelt sich hierbei um eine Lösung welche auf dem Data Protection Service Raksha basiert und das Backup-Restore Konzept für den Enterprise Betrieb erweitert. Die Anbindung an Raksha ermöglicht es neben dem Backup von ganzen OpenStack-Umgebungen auch komplette persistente virtuelle Instanzen zu sichern und wieder herstzustellen. Ein weiterer Vorteil dieser Lösung ist, dass der Restore auch auf einer weiteren OpenStack Umgebung durchgeführt werden kann. Dies ermöglicht u.a. eine komplette und einfach zu realisierende Migration zwischen zwei OpenStack Installationen.

Performance Mesuring Tools for the Cloud

Im Bereich Perfomance wurde aus einem Mix von OpenStack Nutzern (RedHat, AWCloud, Intel und Dell) die gängisten Lösungen für Performance Analysen vorgestellt. Neben der Vorstellung von Rally, Cloud Bench SPECcloud und Perfkit wurden auch weitere Methoden und Möglichkeiten zur Auswertung von Performanceproblemen vorgestellt. Hierzu zählte eine Performance Analyse von Cinder über Ceph, als auch die Auswertung der HAProxy Log-Dateien, welche über Logmanagement Lösungen wie z.B. Splunk auch permanent ausgewertet werden können.

OpenStack Storage Across Datacenters

Für den Betrieb von einem Storage über mehrere Rechenzentren gibt es bei den OpenStack Komponenten gewisse Schwächen. Open vStorage bietet in Kombination mit einem Cinder Plugin eine Möglichkeit an, Object Storage in Blockstorage umzuwandeln und Cinder um eine entsprechende Skalierung zu erweitern. Ein Vorteil hierbei ist, dass bei einem Ausfall von Komponenten im gleichen Rechenzentrum über den Object-Storage die Daten weiterhin zur Verfügung gestellt werden.

Rackspace - "IS IT SAFE?" Taking Torture Out of OpenStack and Neutron

Bei dem Vortrag von Rackspace wurde auf die Vorstellung der Rackspace-Umgebung und den Rackspace Methoden zum deployen OpenStack von OpenStack eingegangen. Weiterhin wurde auch kurz die Zusammenarbeit mit und von Open-Xchange vorgestellt. Nach dieser Vorstellung wurden Methoden vorgestellt "Neutron ohne Schmerzen" mit dem Aufbau von OpenStack zu realisieren. Bei mittlerweile einer Anzahl von 60 Treibern und somit etwa 30000 Kombinationen ebendieser sollte man im Vorfeld genau betrachten, welche Möglichkeiten man in seiner OpenStack Umgebung tatsächlich nutzen möchte. Eine Lösungssuche in diesem Bereich wird bei dieser riesen Anzahl an Kombinationen von Netzwerkintegrationen sehr stark erschwert. Ein weiterer Punkt einer OpenStack Neutron Lösung gibt der Satz "Don't use new school tools with old school mind" wieder. Hierbei sollte darauf geachtet werden, dass die Methoden von OpenStack so genutzt werden wie sie vorgesehen sind. Ein Beispiel wurde hier mit der Vergabe von Floating-IPs vorgestellt. Die Vergabe nur einer Floating-IP Adresse für ein gesamtes Projekt ermöglicht so einen schnellen Neuaufbau oder Anpassung eines so definierten Projektes.

The OpenStack Innovation Center (OSIC) - Rackspace

Am Ende der Präsentation "Rackspace - "IS IT SAFE?" Taking Torture Out of OpenStack and Neutron" und fast nebenher wurde noch das Projekt OSIC vorgestellt. The OpenStack Innovation Center (OSIC) ermöglicht es Entwicklern bei Neuentwicklungen und Erweiterungen ihre Projekte auf Skalierung zu testen zu lassen, indem es den Entwicklern große OpenStack-Umgebungen zur Verfügung stellt.

Rule Breaker! - Upgrading an OpenStack Cloud While Skipping a Release

SUSE hat eine selbstentwickelte Methode vorgestellt, mit welcher Sie ein Upgrade von OpenStack auf die aktuellste Version durchführen können indem Sie ein offizielles Release überspringen. Dieses Upgrade wird über einen Wizard durchgeführt, indem der Administrator durch minimale Aktivitäten der alten und neuen Umgebungen das Upgrade durchführen kann. Auch bestimmte individuelle Anpassungen werden hierbei berücksichtigt. Der Wizard erstellt u.a. auch ein Backup der aktuellen Umgebung. In Zukunft plant SUSE ein auch nahtloses Upgrade der Umgebungen, welches über den entwickelten Mechanismus durchaus realistisch erscheint.

Neuigkeiten zur OpenStack Summit Tokyo

OpenStack Neuigkeiten von der OpenStack Summit

Um meinen Blog wieder etwas mit Leben zu befüllen habe ich mich entschlossen eine Zusammenfassung aller Neuigkeiten rum um das Thema OpenStack Summit Tokyo zu erstellen, in der Hoffnung sie hilft dem einen oder anderen weiter :-)

Trennung in Kern- und Optionale Dienste

OpenStack ist aufgrund seiner großen Anzahl an integrierten Projekten in den letzten Jahren sehr stark angewachsen. Die Anzahl der Komponenten führten im letzten Release Kilo zu einer gewissen Unübersichtlichkeit. Um dem entgegenzuwirken wurde im Rahmen der Veröffentlichung des Project Navigators eine offizielle Trennung zwischen den Core Komponenten und den zusätzlich zur Verfügung stehenden Addons eingeführt. Ein sinnvoller und längst überfälliger Schritt, da OpenStack schon seit mehreren Releases nur aus sechs Kernkomponenten besteht. Hiermit fällt es wesentlich leichter Neueinsteigern die Thematik näherzubringen. Zusätzlich dazu bietet der Projekt Navigator auch eine sehr gute Übersicht über den Aktuellen Stand der einzelnen Projekte.

Weitere Infos: 

http://www.openstack.org/software/project-navigator

Zertifizierungsprogramm von OpenStack

Um eine Konsolidierung beim Thema Zertifizierung im OpenStack Bereich zu erreichen führt die OpenStack Foundation mit Unterstützung einer großen Anzahl von Trainingspartnern (SUSE, HP, Mirantis) ein eigenes Zertifizierungsprogramm ein. Dieses Programm ist für Admins und Betreiber von OpenStack Umgebungen gedacht. Zielsetzung von OpenStack ist eine hohe Qualitätssicherung der Schulungen und Trainings sowie herstellerunabhängige Trainings zur Verfügung zu stellen. Die Einführung des Certified OpenStack Administrator ist aktuell im Q2/2016 geplant.

Weitere Infos:

http://www.openstack.org/coa

http://bit.ly/1LN3rSj

3 Mythen über OpenStack

Mirantis stellt aktuell eine gute Übersichts-Serie über die Top 3 Mythen im OpenStack Bereich zusammen. Die erste veröffentlichung vom 29. Oktober behandelt das Thema "Alle Distributionen sind gleich". Hier wird unter anderem auf die Themen Lifecycle Management, die beinhalteten Projekte, die Paketierung der Middlware und die Referenz Architekturen eingegangen.

Weitere Infos:

http://bit.ly/1MdqWVZ

Veröffentlichung Liberty (Version 12)

Mitte Oktober wurde wie traditionell kurz vor der OpenStack Summit in Tokyo eine OpenStack Version veröffentlicht. Mit Liberty nimmt die Anzahl der neu hinzugefügten Projekte langsam ab, dafür steht aktuell die Weiterentwicklung und die Optimierung aller vorhandenen Dienste im Fokus der Entwicklung. Für eine bessere Übersicht eine kurze Zusammenfassung der wichtigsten Änderungen in der Liberty Version 12:

• Hochverfügbarkeit APIs für Nova wurden erweitert
• Einführung von QoS der Netzwerke
• Load Balancing as a Service wurde erweitert
• Unter anderem für NFV (Network Functions Vritualization)
•  Module können für F5-Load-Balancer konfigurieren
•  Ein eigener Software Load-Balancer wurde vorgestellt (Octavia)
• Orchestrierung (Heat) Performance und Robustheit wurde optimiert
• DNS as a Service (Designate) wird eingeführt
• Zentraler Speicher für Passwörter und Zertifikate (Barbican)
• Telemetrie und Billing Service Ceilometer erhält eine eigene Datenbank (Gnocchi)
• Versionsnummerierung aller Komponenten wurde angepasst

Weitere Infos: 

https://www.openstack.org/software/liberty/

Aktuelle Übersicht der OpenStack Distributionen

Die Zeiträume zur Veröffentlichung neuer OpenStack Enterprise Distributionen werden in den letzten Monaten immer länger, da nicht mehr so viele neue Features in die halbjährlichen Veröffentlichungen von OpenStack direkt hinzugefügt werden. Dies hat den Vorteil, dass die Lösungen langsam auch im produktiven Bereich eingesetzt werden können. Im Anhang eine kurze Übersicht über die aktuelle Benennung und Versionierung der in Deutschland vertretenden OpenStack Distributionen:

SUSE OpenStack Cloud 6 (Beta)- Liberty (http://bit.ly/1KDIIfK)

RHEL OpenStack 7 - Kilo (http://red.ht/1l4ZZK4)

Mirantis OpenStack 7.0 - Kilo (http://bit.ly/1Q6Reed)

HP Helion OpenStack 2.0 - Kilo (http://bit.ly/1XKBlfF)

Performance Probleme beim Booten mit resume

Performance Probleme beim Booten mit resume

Nach einem Umzug auf eine neue SSD ist mir aufgefallen, dass meine Boot-Zeit von Ubuntu 12.04 um etwa 5 Sekunden länger gedauert hat als sonst. Daraufhin begab ich mich auf die Suche nach dem Problem. Die Syslog Datei brachte nur einen kleinen Hinweis zu Tage, dem ich vorerst durch googlen versucht habe nachzugehen. Das Ergebnis war aber nicht zufriedenstellend, da mir nur Informationen mitgeteilt wurden, dass das Root-System unsauber gemountet wurde. Auch nach einem sauberen umount trat das Problem allerdings auf.

In der Zeitausgabe vom Kernel als Log in der Syslog Datei erschien ein Timeout von etwa 5 Sekunden.

Jan 28 22:53:41 desktop kernel: [    4.530862] usb 1-3.4.3: New USB device found, idVendor=0a12, idProduct=0001
Jan 28 22:53:41 desktop kernel: [    4.530868] usb 1-3.4.3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
Jan 28 22:53:41 desktop kernel: [    8.783308] EXT4-fs (sda2): INFO: recovery required on readonly filesystem
Jan 28 22:53:41 desktop kernel: [    8.783310] EXT4-fs (sda2): write access will be enabled during recovery
Jan 28 22:53:41 desktop kernel: [    8.943384] EXT4-fs (sda2): recovery complete
Jan 28 22:53:41 desktop kernel: [    8.952596] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)
Jan 28 22:53:41 desktop kernel: [    9.414274] EXT4-fs (sda2): re-mounted. Opts: errors=remount-ro,user_xattr,discard
Jan 28 22:53:41 desktop kernel: [   10.845742] EXT4-fs (sda6): mounted filesystem with ordered data mode. Opts: errors=remount-ro,discard

Jan 28 22:53:41 desktop kernel: [   10.855497] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: errors=remount-ro

In den Logs tauchten folgende Infos nicht auf, welche ich aber auf dem Boot-Screen gesehen habe, nachdem ich die quiet und splash Parameter aus der /etc/default/grub Konfigurationsdatei entfernt habe.

Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... done.
Begin: Running /scripts/local-bottom ... done.
done.
Begin: Running /scripts/init-bottom ... done.

Danach habe ich die initrd auf dem System entpackt und bin den Boot-Prozess Step-by-Step durchgegangen.

[Desktop /]# mkdir /tmp/initrd↵
[Desktop /]# cd /tmp/initrd↵
[Desktop /tmp/initrd]# cp /boot/initrd.img-3.8.0-35-generic /tmp/initrd/initrd.gz↵
[Desktop /tmp/initrd]# gunzip initrd.gz↵
[Desktop /tmp/initrd]# cat initrd | cpio -id↵
[Desktop /tmp/initrd]# less init↵


Dabei ist bin ich auf das Script scripts/local-premount/resume gestossen, welches versucht hat das System von einer Swap-Partition herzustellen die nicht mehr existiert hat.

Den entsprechenden Parameter habe ich auf dem Desktop-System in der Datei /etc/initramfs-tools/conf.d/resume gefunden und komplett entfernt. Die Initrd habe ich danach mit dem Befehl:
[Desktop /root]# update-initramfs -u↵
neu erstellt. Danach bootete das System die vorhin genannten 5 Sec schneller.

Legende

Benutzer Root

[<Servername> <Pfad>]# <Befehl> <Dateiname>↵

Ausgabe

Benutzer

[<user>@<Servername>]$ <Befehl> <Dateiname>↵

Ausgabe

Tastenkombinationen:

Strg+a

Einzelne Tasten:

a

SLES 11 SP2 SMT Server - Howto

SLES 11 SP2 SMT Server - Howto

Einleitung

Der SMT Server ist eine freie Software zur einfachen Systemverwaltung von SUSE Linux Enterprise Servern (SLES10, SLES11). Er dient primär zur lokalen Verwaltung von den von SUSE zur Verfügung gestellten Reposiories um Netzwerktraffic zu sparen und einen besseren Überblick über seine Systemlandschaft zu gelangen. Neben den von SUSE zur Verfügung gestellten Repositorys können aber auch noch eigene hinzugefügt werden. 

Ein weiterer Vorteil des SMT ist die Möglichkeit ein Stageing von z.B. Test und Produktivumgebungen in der eigenen Serverlandschaft darzustellen. 

Neben diesen Funktionen bietet er auch die Möglichkeit Scripte zentral vom SMT aus auf den Clients auszuführen.

In diesem Howto beschreibe ich, wie ich den SMT nutze und wie am Ende die Ausgaben auszusehen haben. Bei der Installation verweise ich dabei auf die recht gute und ausgearbeitet SUSE Dokumentation.

Voraussetzung

NCC Zugang (Novell Customer Center)

Mindestens 3 Aktive Subscriptions für SLES 11 SP2

Einen Server

Name: server-smt
Betriebssystem: SLES 11
Netzwerkadapter:
eth0: 192.168.1.200
LVM Volume:
/dev/VolGroup00/smt 80 GB -> /var/lib/smt

Pakete:
SLES: smt

Anzahl Clients

Name: client1

Betriebssystem: SLES 11

Netzwerkadapter: eth0: 192.168.1.201

Name: client2

Betriebssystem: SLES 11

Netzwerkadapter: eth0: 192.168.1.202

Installation/Konfiguration

Das Subscription Management Tool steht frei zur Verfügung und kann bei SUSE https://download.suse.com/index.jsp in der Suche unter dem gleichnamigen Begriff runtergeladen werden. Die Installation läuft unter einer normal installierten SLES Instanz.

Unter der SLES Installation kann das runtergeladene Addon in YaST2 unter dem Punkt "Software" - "Add-On Product" hinzugefügt werden. Hierbei wird als Installationquelle die CD ausgewählt und die Installation nach Bestätigung der Lizenzvereinbarungen gestartet.

Eine ausführliche Installationsanleitung gibt es von SUSE unter dem folgenden Link:

https://www.suse.com/documentation/smt11/book_yep/data/smt_installation.html

SMT Konfiguration

Bei der Konfiguration ist drauf zu achten, dass der Domainname incl. Domain (FQND)  im ganzen Netzwerk erreichbar ist, da es sonst zu Problemen mit den vom SMT erstellten SSL Zertifikaten kommt.

Sobald die Server Konfiguration durchgeführt wurde geht es daran die Clients an das System anzubinden. Mit der folgenden Befehlsreihenfolge bin ich bisher immer gut gefahren:

Kopieren des Scripts clientSetup4SMT.sh auf die Clients:

[root@<server-smt> ~]# scp -rp /usr/lib/suseRegister/bin/clientSetup4SMT.sh root@client01: ↵

[root@<server-smt> ~]# scp -rp /usr/lib/suseRegister/bin/clientSetup4SMT.sh root@client02: ↵

Löschen der vorhandenen Repositories, dies verhindert, dass der Server noch auf die lokal Konfigurierten CD/DVSs zugreift, die häufig nicht mehr eingebunden sind:

[root@<client1> ~]# rm -rf /etc/zypp/repos.d/* ↵

Konfiguration des Clients:
[root@<client1> ~]# ./clientSetup4SMT.sh https://server-smt.bludau.home/center/regsvc ↵

Sollten eigene nicht zertifizierte Repositories mit eingebunden werden helfen noch folgende Befehle weiter, welche noch einmal nachfragen, ob nicht zertifizierte Pakete zugelassen werden.
[root@<client1> ~]# suse_register --restore-repos
[root@<client1> ~]# zypper ref

Anwendung

Im folgenden Absatz werden die wichtigen Befehle gelistet um den SMT Server zu benutzen.

Eine Liste aller angebundenen Clients und deren aktuellen Status gibt der Befehl smt-client aus. Der Status sollte möglichst auf Up-to-date sein, dies ist aber nicht immer realsierbar.

[root@server-smt ~]# smt-client ↵
.-----------------------------------------------------------------------------------------------.
| GUID                             | Hostname              | Patch Status | Patch Status Date   |
+----------------------------------+-----------------------+--------------+---------------------+
| 12345678901234567890123456789012 | client1               | Up-to-date      | 2013-06-17 12:17:31 |

| 12345678901234567890123456789013 | client2               | Critical     | 2013-06-17 12:15:07 |

'----------------------------------+-----------------------+--------------+---------------------'

[root@server-smt ~]#

Der SMT Server bietet die Möglichkeit einen Report zu generieren, in dem dargestellt wird, wie viele Subscription man aktuell hat und wie lange diese noch gültig sind.

[root@server-smt ~]# smt-report

Um den SMT Mirror auf den aktuellen Stand zu bringen reicht es aus den folgenden Befehl auszuführen. Sollen die Updates ständig eingespielt werden, kann dieser Befehl auch als Cronjob gestartet werden.
[root@server-smt ~]# smt-mirror

iscsi Basis - Howto

iscsi Basis - Howto

Einleitung

In diesem Howto beschreibe ich den Grundaufbau einer minimalen iscsi Umgebung. Hierbei handelt es sich um den Aufbau eines iscsi Servers und die Anbindung von einem Client an den zur Verfügung gestellten Pfad.

Vorraussetzungen

Einen Server

Name: server

Zwei Netzwerkadapter
eth0: 192.168.1.200
eth1: 192.168.201.200

LVM Volume:
/dev/VolGroup00/iscsi 1 GB

Pakete:
RedHat: scsi-target-utils

Zwei Clients

Name: client1

Zwei Netzwerkadapter
eth0: 192.168.1.201
eth1: 192.168.201.201

Pakete:
RedHat: iscsi-initiator-utils.x86, sg3_utils-1.28-4.el6.x86_64, lsscsi-0.23-2.el6.x86_64

Howto

Konfiguration Server

Auf dem Server wird nach der Installation der benötigen Pakete die Konfigurationsdatei target.conf angepasst. In Ihr werden als target Name ein eindeutiger iqn (iSCSI Qualified Name) benötigt. dieser befindet sich in dem <target> Tag. 

Der zur Verfügung stehenden Speicherplatz wird mit dem Parameter backing-store festgelegt. Hier bietet es sich an ein freies Blockdevice zu nehmen. Im Fall des Howtos ein frisch angelegtes LVM Device.

Mit dem Parameter initiator-address werden die definierten IP Adressen freigegeben und der Parameter scsi_sn legt die SCSI Seriennummer fest, welche später über udev ausgelesen werden kann.

[server ~]# cat /etc/tgt/targets.conf ↵
default-driver iscsi
# Target ist ein eindeutiger Name
<target iqn.2013-06-01.home.bludau:iscsi>

  backing-store /dev/VolGroup00/iscsi # LUN1

  initiator-address 192.168.1.200     # server
  initiator-address 192.168.201.201     # client1
  scsi_sn iscsi-seriennummer # SCSI Seriennummer

</target>
[server ~]#

Nach dieser Konfiguration muss der Dienst tgtd gestartet und als Service eingetragen werden.

[server ~]# service tgtd start ↵
[server ~]# chkconfig tgtd on ↵

Nach dieser Konfiguration kann mit dem folgenden Befehl überprüft werden, ob auch alle Konfigurationen wie gewünscht übernommen wurden.


[server ~]# tgt-admin -s ↵
Target 1: iqn.2013-06-01.home.bludau:iscsi
 ...
        LUN: 1
            Type: disk
            SCSI ID: IET     00010001
            SCSI SN: iscsi-seriennummer
            Size: 1074 MB, Block size: 512
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            Backing store type: rdwr
            Backing store path: /dev/VolGroup00/iscsi
            Backing store flags: 
    Account information:
    ACL information:
        192.168.1.200
        192.168.201.201
[server ~]# 

Hinter dem Target-Namen ist die iqn gelistet unter welcher das iscsi Device zur Verfügung steht. Backing Store gibt den auf dem Server genutzten Pfad aus und die ACL Informationen geben die IP Adressen zurück, für welche die iSCSI Targets freigegeben sind.

Konfiguration Clients

Um einen Client anzubinden ist die Konfiguration vom iscsi Daemon notwendig. Dieser kann mit folgenden Befehlen automatisch gestartet werden:

[client1 ~]# chkconfig iscsid on ↵

[client1 ~]# service iscsid start ↵

Danach ist die Anbindung vom Client an das iscsi Target vom Server notwendig. Um sich alle Freigaben anzeigen zu lassen hilft das Programm iscsiadm weiter, welches mit den Parametern "-m discovery -t sendtargets -p 192.168.201.200" vom Server her alle Targets gelistet bekommt.

Diese Freigabe wird dann genutzt um das Target an das System zu binden.

Anbinden des iscsi Targets bei dem Client client1:

[client1 ~]# lsscsi ↵
...
[client1 ~]# iscsiadm -m discovery -t sendtargets -p 192.168.201.200 ↵
192.168.201.200:3260,1 iqn.2013-06-01.home.bludau:iscsi
[client1 ~]# iscsiadm -m node -T iqn.2013-06.home.bludau:iscsi -p 192.168.201.200 --login ↵
[client1 ~]# lsscsi ↵
...
[6:0:0:0]    storage IET      Controller       0001  -       
[6:0:0:1]    disk    IET      VIRTUAL-DISK     0001  /dev/sda 
...
[client1 ~]#

Ausgabe aller Informationen die unter UDEV ausgelesen werden können, dazu gehören unter anderem auch die Seriennummer:
[client1 ~]# udevadm info -q all -n /dev/sda ↵
...

Das ganze funktioniert auch um das Device wieder zu entfernen. Hierbei ist bei dem zweiten Commando aber darauf zu achten, dass anstelle des login Parameters logout angegeben wird. Zusäztlich sollte man vorher unbedingt darauf achten, dass die darauf erstellen Filesysteme ausgehängt wurden.

Entfernen von des iscsi Device von dem Client client1:

[client1 ~]# lsscsi ↵
...
[6:0:0:0]    storage IET      Controller       0001  -       
[6:0:0:1]    disk    IET      VIRTUAL-DISK     0001  /dev/sda 
...
[client1 ~]# iscsiadm -m discovery -t sendtargets -p 192.168.201.200 ↵
192.168.201.200:3260,1 iqn.2013-06-01.home.bludau:iscsi
[client1 ~]# iscsiadm -m node -T iqn.2013-06.home.bludau:iscsi -p 192.168.201.200 --logout ↵
[client1 ~]# lsscsi ↵

Legende

Benutzer Root

[<Servername> <Pfad>]# <Befehl> <Dateiname> ↵

Ausgabe

Benutzer

[<user>@<Servername>]$ <Befehl> <Dateiname> ↵

Ausgabe

Tastenkombinationen:

Strg+a

Einzelne Tasten:

a

Datenrettung von CD/DVDs mithilfe von PhotoRec/TestDisk

In meinem Blogeintrag "Datenrettung bei I/O Fehlern mit ddrescue" habe ich bereits geschrieben wie man Daten von einer Festplatte sichern kann.

Heute habe ich eine CD bekommen, welche mit I/O Fehlermeldungen Meldungen unter Linux und Windows ausgestiegen ist. Leider konnte ich sie nicht mal öffnen, da mir mitgeteilt wurde, dass das Filesystem beschädigt war.

Da ich wusste, das die Daten (Bilder) auf der CD vorhanden sind, habe ich nach einer Lösung gesucht um diese wieder herzustellen.

Über ein ddrescure habe ich den Großteil der CD auf meiner Platte gespeichert. (dd if=/dev/sr0 of=/home/thomas/sr0.img) und dann versucht darüber zu mounten. 


mount: wrong fs type, bad option, bad superblock on /dev/sr0,
       missing codepage or helper program, or other error
       Manchmal liefert das Syslog wertvolle Informationen – versuchen
       Sie  dmesg | tail  oder so

Leider hat dieser Versuch auch mit der gleichen Fehlermeldung geendet wie bei dem Versuch die CD direkt einzubinden.

Über einige Suche nach UDF Restore bin ich dann über den Befehl photorec gestossen, welcher ein Teil des Ubuntu-Packges testdisk ist.

Über eine menügesteuerte Übersicht konnte ich einen Großteil der Daten von meinem zuvor erstellten dd Image sichern.

Die Optionszeile lautet wie folgt:

photorec [/log] [/debug] [/d recup_dir] [device|image.dd|image.e01]

Durch die Eingabe des folgenden Befehls konnte ich meine Daten über das Menü wieder herstellen. Die Bilder befanden sich danach in dem Verzeichnis daten.1 :

# photorec /d daten sr0.img

In den folgenden Bildern werden die von mir durchgeführten Schritte noch im Programm grafisch dargestellt:

Als Auswahl des Filesystem hat es hier völlig ausgereicht Others auszuwählen.