Domänencontroller kann nicht gefunden werden

Haben Sie diese Grundlagentests durchgeführt, aber die Auflösung funktioniert noch immer nicht, fehlen unter Umständen DNS-Einträge der Domänencontroller in den DNS-Zonen. Diese Einstellungen finden Sie unter _msdcs auf den DNS-Servern. Auf den Domänencontrollern finden Sie solche Fehler am schnellsten wenn Sie dcdiag in der Eingabeaufforderung eingeben. Überprüfen Sie auch mit nltest /dsgetsite, ob der Domänencontroller dem richtigen Active Directory-Standort zugewiesen ist. Mit nltest /dclist:<NetBIOS-Name der Domäne> lassen Sie sich eine Liste aller Domänencontroller einer entsprechenden Domäne anzeigen.

Die Einträge sollten als FQDN aufgelistet sein. Ebenfalls ein wichtiger Befehl ist nltest /dsgetdc:<NetBIOS-Name der Domäne>. Dieser Befehl listet Name, IP-Adresse, GUID, FQDN von Active Directory und weitere Informationen auf. Alle Informationen sollten ohne Fehler angezeigt werden.

Starten Sie mit net stop netlogon und dann net start netlogon den Anmeldedienst auf dem Domänencontroller neu. Beim Starten versucht der Dienst die Daten der Datei netlogon.dns erneut in DNS zu registrieren. Gibt es hierbei Probleme, finden Sie im Ereignisprotokoll unter System einen Eintrag des Diensts, der bei der Problemlösung weiterhilft.

Auch der Befehl nltest /dsregdns hilft oft bei Problemen in der DNS-Registrierung. Funktioniert die erneute Registrierung durch Neustart des Anmeldediensts nicht, löschen Sie die DNS-Zone _msdcs und die erstellte Delegierung ebenfalls. Starten Sie dann den Anmeldedienst neu, liest dieser die Daten von netlogon.dns ein, erstellt die Zone _msdcs neu und schreibt die Einträge wieder in die Zone. Testen Sie anschließend wieder mit Dcdiag, ob die Probleme behoben sind. Einen ausführlichen Test führen Sie mit dcdiag /v durch

DNS-Einträge in Active Directory reparieren

Der CNAME ist die GUID dieses DSA-Objektes. Domänencontroller versuchen Ihren Replikationspartner nicht mit dem herkömmlichen Host-A-Eintrag aufzulösen, sondern mit dem hinterlegten CNAME. Ein Domänencontroller versucht nach der erfolglosen Namensauflösung des CNAME eines Domänencontrollers, einen Host-A-Eintrag zu finden. Schlägt auch das fehl, versucht der Domänencontroller den Namen mit NetBIOS aufzulösen, entweder über Broadcast oder einen WINS-Server. Jeder Domänencontroller braucht einen eindeutigen CNAME, der wiederum auf seinen Host-A-Eintrag verweist. Überprüfen Sie bei Replikationsproblemen, ob diese Einträge vorhanden sind

Alle SRV-Records von Active Directory befinden sich parallel in der Datei \%WinDir%\System32\config\netlogon.dns. Die Datei lässt sich mit einem Editor auch anzeigen. Fehlen Einträge in den DNS-Zonen, die Active Directory benötigt, ist es meist hilfreich, wenn Sie den Befehl dcdiag /fix ausführen. Dabei versucht das Tool, auch fehlende Einträge aus der Datei netlogon.dns einzubauen. Danach sollte die Namensauflösung wieder funktionieren.

Der Platz in der zweiten Reihe

Die Amerikaner nennen dieses Thema Industrial Internet und denken es horizontal, also vom Kunden her. Sie vernetzen intelligente Produkte, Supply Chains und Fabriken. Das ist aus unserer Sicht auch der richtige Ansatz. Der deutsche Ansatz hingegen ist vertikal – man denkt in technischen Schnittstellen, zum Beispiel von Maschinen zu übergeordneten Steuerungssystemen. Wir sehen hierzulande größtenteils fabrikinterne technische Lösungen. So werden die Produktioner außerhalb der Produktion aber nicht wahrgenommen.

Der eigentliche Sinn der digitalen Vernetzung und ihr enormes Potential liegt vielmehr in datenbasierten Geschäftsmodellen und damit außerhalb der Fabriken. Das hat man in Deutschland noch nicht verstanden, weshalb davon in Deutschland auch nichts Entsprechendes zu sehen ist. Industrie 4.0 kommt hierzulande gedanklich einfach nicht aus dem kleinen Karo der Fabrik heraus.

Wohl aber in den USA. Sie schaffen Plattformen und vernetzen dabei intelligente Produkte, Supply Chains und Fabriken. Das ist der richtige Ansatz. Mit anderen Worten: Die Deutschen tüfteln an Schnittstellen, die Amerikaner erzeugen Märkte. Was für ein fundamentaler Unterschied. Die Deutschen fragen: wie bringen wir die Vernetzung technisch ans Laufen? Die Amerikaner fragen: welches Geschäft können wir damit machen?

Die Rollenverteilung ist klar: Die Amerikaner stecken die digitalen Claims ab und schürfen Gold, während die Deutschen sich darüber freuen, Spitzhacken und Spaten liefern zu dürfen. Die Deutsche Industrie hat sich widerstandslos in die zweite Reihe drängen lassen – zum austauschbaren Hardwarelieferanten von Internet-Unternehmen. Und die Fabrikausrüster, die Industrie 4.0 ja als Konjunkturprogramm sehen und deshalb vorantreiben, haben noch nicht verstanden, dass eben diese Revolution das Zeug hat, sie selber hinwegzufegen.

Die eigentliche Revolution findet außerhalb der Fabriken statt. Das erkennt man aber nicht, wenn der eigene Denkhorizont am Werkstor endet.
Durch die zunehmende Vernetzung wird vieles transparent für Außenstehende, so auch Produktionsabläufe, Produktinformationen und Produktionstechnologien. Dieses Wissen ist die Basis für den Wettbewerbsvorsprung der deutschen Industrie. Dieser geht mit zunehmender Vernetzung aber verloren. Problematisch dabei ist nicht der Verlust als solcher, sondern die Tatsache, dass hierzulande nichts existiert, was diesen Verlust kompensieren könnte. Während in den USA die Appisierung der Hardware vorangetrieben wird, beharrt der deutsche Maschinenbau darauf, dass seine Maschinen und Produktionseinrichtungen das eigentliche Geschäft sind. Dabei sind Maschinen letztendlich nur Mittel zum Zweck und die Plattformen das eigentliche Geschäft; doch genau das überlassen die Deutschen den Amerikanern. Es besteht hierzulande kein Mangel an Datenstandards und Kooperationsvereinbarungen, sondern ein Mangel an Mut und Phantasie.

Schwachstellenscans für Embedded Systems

Schwachstellenscanner werden eingesetzt, um über das Netzwerk Systeme von außen auf Schwachstellen oder Konfigurationsprobleme zu überprüfen. Das ist notwendig, trotz der regelmäßigen Updates und Patches, mit denen erfahrene Administratoren die IT-Infrastruktur grundsätzlich gut im Griff haben. Denn moderne IT-Umgebungen werden zunehmend komplexer, nicht nur aufgrund des Einsatzes von Cloud Computing oder Bring-Your-Own-Device-Modellen, auch wegen der Komponenten, die an die IT-Infrastruktur andocken – von Smartphones und Tablets über Drucker und Telefone bis hin zu beliebig komplexen Industriesteuerungen. Das Internet of Things entsteht. Doch wie findet man seine Schwachstellen? 

Problemfall beim Schwachstellenscan: „die Unantastbaren“

Bei Industriesteuerungssystemen oder auch allgemein Embedded Devices beziehungsweise IoT-Devices können Schwachstellenscanner zusätzlichen Netzwerk-Traffic verursachen und dem Gerät die Kapazitäten für seine eigentliche Aufgabe rauben. Manchmal stürzen die Geräte auch gänzlich ab. Erfahrungsgemäß werden häufig Industriesteuerungslösungen eingesetzt, die von den Herstellern nur ungenügend aktualisiert oder supportet werden. Einige Anbieter drohen damit, den Support einzustellen, wenn der Nutzer selbst Updates und Patches einspielt oder Sicherheitsmaßnahmen wie Schwachstellenscans oder Penetrationstests laufen lässt.

Eine weitere Schwierigkeit kommt hinzu, wenn – wie in vielen Firmen üblich – die Hoheit für Produktionsumgebungen und Produktionsnetzwerke nicht bei der zentralen IT, sondern bei den entsprechenden Fachabteilungen liegt. Die Angst davor, kritische Prozesse mit Schwachstellenscans zu beeinträchtigen, führt häufig dazu, dass solche Umgebungen gänzlich von Schwachstellenscans und Schwachstellen-Management-Prozessen ausgeschlossen werden.

Die Gefahren für solche Umgebungen sind trotzdem real: Schadsoftware und Angreifer, die es erst einmal ins interne Firmennetzwerk geschafft haben, sind von internen Entscheidungsbefugnissen wenig beeindruckt. Der Effekt: Ausgerechnet die kritischen Systeme weisen die meisten Lücken auf und werden als erstes angegriffen.

Eine Lösung: passives Scannen nach Lücken

Eine Lösung oder zumindest eine Linderung der Problematik können sogenannte Passive Schwachstellenscanner darstellen. Eines dieser Produkte ist beispielsweise PVS (Passive Vulnerability Scanner) von Tenable. Beliebig viele PVS Appliances können gezielt an extra eingerichteten Mirror-Ports an den Netzwerk-Knotenpunkten – zum Beispiel am Übergang eines Produktions-VLANs zum restlichen Firmennetzwerk – platziert werden. Dort identifizieren sie gänzlich passiv die eingesetzten Softwareversionen und darin enthaltenen Schwachstellen, in dem sie den Datenstrom analysieren.

Zwar lässt sich mit einem passiven Schwachstellenscan nicht die gleiche Abdeckung oder ein ähnlicher Tiefgang an Informationen wie bei einem aktiven Scan erreichen, trotzdem wird bereits eine Vielzahl an Schwachstellen auf diesem Weg aufgedeckt. Nun kommt der richtigen Interpretation der Ergebnisse und der Koordination der notwendigen Maßnahmen eine besondere Bedeutung zu. Selbst für versierte IT-Experten kann externe Beratung eine wertvolle Unterstützung sein.

Passive Schwachstellenscans sind zudem hilfreich dabei, ein grundsätzliches Verständnis bei den Fachabteilungen für diese IT-Security-Maßnahmen zu entwickeln. Bestenfalls gelingt es, ein unternehmensweites Schwachstellen-Management über klassische IT-Systeme und Embedded Systems hinweg zu etablieren.

Canonical plant Kubernetes-Distribution

Canonical hat eine spezielle Enterprise-Distribution vorgestellt, die sich gezielt an Unternehmen richtet, die im großen Umfang auf Container setzen.

Die Distribution besteht im Wesentlichen aus einer modifizierten Kubernetes-Version und einer Reihe unterstützter Programme. Die von Canonical angepasste Kubernetes-Version soll aber steht so nahe wie möglich am jeweils aktuellen offiziellen Kubernetes-Release gehalten werden. Das von Canonical entwickelte Cloud-Management-Tool Juju sorgt zudem für eine enge Integration von Canonical Kubernetes mit anderen Canonical-Produkten.

Über Kubernetes hinaus bringt die Distribution weitere spezialisierte Komponenten mit, wie z. B. das Netzwerk-Monitoring-Tool Prometheus, den verteilten Objektspeicher Ceph sowie einem vollständig integrierten Elastic-Stack mit Kibana, der für Datenanalysen und Visualisierungen zum Einsatz kommt.

Noch Beta

Derzeit befindet sich Canonicals neue Distribution noch im Beta-Status. Erst zusammen mit dem geplanten Release von Juju 2.0 soll in einigen Wochen die offizielle Version folgen.
Die Entwicklung der Distribution geht offenbar auf spezielle Kundenanfragen einiger Unternehmen zurück. Canonical leistet dann Support im Rahmen seines Ubuntu Advantage-Programms.

Wer die Distribution nicht selbst installieren möchte, kann alternativ auch auf von Canonical gewartete Instanzen zurückgreifen. Testen kann man die Distribution aber im Prinzip auch jetzt schon, indem man unter Ubuntu-Server mit installiertem Juju das Paket „canonical-kubernetes“ via Juju einbindet. Wie üblich sind sämtliche Komponenten freie Software

Über Kubernetes

Kubernetes ist ein Managament-Framework für das Orchestrieren von Containern. Das initial von Google entwickelte Kubernetes ist z. B. in der Lage, Container auf Hostsysteme zu verteilen, zu migrieren und zu verwalten. Außerdem kann Kubernetes für eine Lastverteilung sorgen. So lassen sich mit Kubernetes skalierbare Container-Cluster anlegen und dynamisch an die Leistungsanforderung anpassen. Ferner überwacht Kubernetes Container und kann deren Zustand und den ihrer Daten persistent machen.

Zertifikate in vSphere verwalten

Schlussendlich spielt es keine Rolle, wo die Zertifikate ausgestellt werden, die Sie in vSphere einbinden. Sie können daher auch problemlos interne Active Directory-Zertifikatsdienste verwenden. Mit dem Certificate Manager können Sie in vCenter Zertifikate aus dem Active Directory-Zertifikatsdiensten einbinden. Zuvor müssen diese Dienste natürlich in Active Directory installiert und konfiguriert werden. Um Zertifikate in vSphere zu nutzen, macht es Sinn, dass Sie eigene Vorlagen für vSphere-Hosts in den Active Directory-Zertifikatsdiensten konfigurieren.

Setzen Sie die vCenter-Appliance ein, melden Sie sich per SSH, zum Beispiel mit Putty an der Appliance an. Nach der Anmeldung starten Sie mit „shell.set –enabled True“ und dann mit „Shell“ das Befehlszeilenfenster.

Erhalten Sie eine Fehlermeldung, Sie zuerst über die Konsole oder die Weboberfläche die Shell aktivieren. Diese ist aus Sicherheitsgründen meistens deaktiviert. Anschließend erstellen Sie ein neues Verzeichnis, welches Sie für die Speicherung der Zertifikate unter notwendigen Dateien benötigen. Dieses können Sie zum Beispiel mit dem folgenden Befehl erstellen:  „mkdir /root/SSLCerts“. Danach starten Sie den Certificate Manager:

/usr/lib/vmware-vmca/bin/certificate-manager

Dieser lässt sich auch auf vCenter-Servern auf Basis von Windows starten. Dazu rufen Sie die entsprechende Batch-Datei im Verzeichnis „C:\Program Files\VMware\vCenter Server\vmcad“ auf.

vSphere Replication

Damit Sie vSphere Replication nutzen können, müssen Sie vCenter im Unternehmen einsetzen. Dabei spielt es keine Rolle, ob Sie die vCenter-Appliance verwenden, oder eine herkömmliche Installation von vCenter. vSphere Replication wird als virtuelle 64-Bit-Appliance zur Verfügung gestellt, und liegt in komprimierter Form im .ovf-Format vor. Die Appliance wird mit einer Dual-Core-CPU, einer 16-GB- und einer 2-GB-Festplatte sowie 4 GB RAM konfiguriert. Zusätzliche vSphere Replication-Server benötigen 716 MB RAM. Sie sollten also die Hardware in ihrer Umgebung entsprechend planen, wenn Sie auf vSphere Replication setzen wollen.

Setzen Sie auf vSphere Replication, sind Sie bei der Verwendung Ihrer vSphere-Umgebung nicht eingeschränkt. Sie haben die Möglichkeit weiterhin vSphere vMotion einzusetzen, genauso wie Storage vMotion. Sobald Sie eine VM mit vMotion verschieben, wird die Replikation angehalten, und nach der erfolgreichen Übertragung wieder gestartet. Sie können vMotion auch zum Migrieren von replizierten virtuellen Maschinen verwenden. Nach dem erfolgreichen Verschieben wird auch hier die Replizierung ab dem definierten RPO (Recovery Point Objective) fortgesetzt.

Auch die Verwendung von vSphere High Availability (HA) ist möglich, das gilt auch für vSphere DRS. Diese beiden Technologien, können Sie auch für die Absicherung der vSphere  Replication-Appliance nutzen. Sie können allerdings kein Fault Tolerance (FT) parallel zur vSphere Replication einsetzen. Die Funktionen vSAN, Distributed Power Management und Flash Read Cache lassen sich ebenfalls nutzen. Sie können beim Konfigurieren von Replizierungen problemlos VMware Virtual SAN-Datenspeicher als Quell- und Zieldatenspeicher verwenden.

Grundsätzlich ist es sinnvoll, wenn Sie für den Datenverkehr der vSphere-Replikation eine eigene VMkernel-Portgruppe erstellen. Sie können in den Einstellungen der neuen Port Gruppe explizit den Datenverkehr von vSphere Replication auswählen. Dadurch haben Sie die Möglichkeit eigene virtuelle Netzwerke, eigene virtuelle Switches und dedizierte physische Netzwerkadapter für die Replikation auszuwählen.

Adblocker für das „echte“ Leben mit Virtual Reality Brille

AdBlocker im Netz, auf werbefinanzierten Seiten, sind ja gegenwärtig schon ein großes Thema. Das Prinzip, Werbung aus dem Sichtfeld zu verbannen, hat nun ein gewisser Jonathan Dubin auf das reale, echte Leben übertragen. Na ja, jedenfalls zum Teil, denn es bedarf dafür eines „Virtual Reality“-Endgerätes, wie einer Oculus Rift. Mit der VR-Brille auf den Augen, ausgestattet mit Dubins „Brand Killer Real Life AdBlocker“ können unliebsame Darstellungen, etwa Markenbilder, „verpixelt“ und damit unkenntlich angezeigt werden. So ist es möglich, die Werbemittel- und Markenreaktanz aus der Online- in die reale Welt zu übertragen (s. Video) Wir finden: eine Anwendung mit ungeheurem Potenzial, wie gemacht für Eskapisten: Anstatt ungewollter Werbung und Markenabbildungen lässt sich das Konzept sicherlich auch auf Gesichter ungeliebter Verwandter und Kollegen oder überhaupt auf alles, was wir in unserem Leben unsichtbar machen möchten, übertragen – die hausgemachte Filterbubble für das analoge Leben.

Der Artikel erschien ursprünglich auf nerdwärts.de

Mehrkern-Prozessoren sind ein Problem für Multithread-Code

Im einem unserer Blog-Beiträge werden einige der Stolperfallen von Multithreading beschrieben, in die Entwickler tappen können. An dieser Stelle widme ich mich der damit verknüpften Frage der Portierung eines bereits multithreading-fähigen Projekts von Einzelprozessorplattformen auf Mehrprozessorplattformen (einschließlich Mehrkern-Plattformen).

Dass es Probleme gibt, die speziell bei der Portierung von Multithread-Code in eine Mehrkern-Umgebung auftreten, mag der Intuition widersprechen. Müsste es nicht so sein, dass man die Anwendung einfach nur portiert und dann vom Leistungsplus profitiert, weil die Threads ja auf mehreren Prozessoren parallel ausgeführt werden? Ganz so einfach ist die Sache nicht. Man ist sich heute weitgehend einig, dass sich Multithreading-Bugs mit größerer Wahrscheinlichkeit auf Mehrprozessorplattformen manifestieren. Dieser Beitrag untersucht eine Reihe von Gründen für diesen Umstand.

Zunächst sei angemerkt, dass Multithreading eine Technologie ist, die zwei Zwecken dient:  Threads werden genutzt, um parallele Software für Mehrprozessorsysteme zu entwickeln. Darüber hinaus dienen sie aber auch der asynchronen Verarbeitung von Interaktionen mit anderer Software und der realen Welt. Dieser zweite Nutzungsfall ist auch dann relevant, wenn die Software auf nur einem Prozessor läuft. Deshalb gab es schon vor der Ausbreitung der Mehrprozessorsysteme jede Menge Multithread-Code.

Selbstgestrickte Synchronisierung funktioniert auf einem einzelnen Prozessor mitunter

Im ersten Beispiel (Sh. Bild 1)  schauen wir uns das „träge“ Initialisierungsmuster an:

multithreaded-1-300dpi

Dieser Code alloziert eine globale Instanz eines speziellen Objekts zu und initialisiert sie. Das erfolgt jedoch erst, wenn das Objekt tatsächlich gebraucht wird (deshalb die Bezeichnung „träge“). Dieser Code funktioniert in einem Ein-Thread-Kontext perfekt, kann in einem Multithread-Kontext jedoch jämmerlich versagen.

Überlegen Sie, was passiert, wenn ein Thread in den konditionalen Block eintritt, weil „obj“ NULL ist, und dann vom Scheduler unterbrochen wird. Ein zweiter Thread ruft „get_special_object“ auf und nimmt die Zuweisung und Initialisierung selbst vor, weil „obj“ immer noch NULL ist. Wenn der erste Thread wieder weiterläuft, initialisiert er sich selbst. Jetzt schwirren zwei unterschiedliche Kopien des speziellen Objekts durch die Gegend. Im besten Fall ist das ein Speicherleck; wahrscheinlicher ist jedoch, dass es Programmlogik gibt, die von der unveränderlichen Größe abhängt, dass es höchstens eine Instanz des speziellen Objekts gibt.

Der einzige einfache und gangbare Weg, dieses Muster Multithreading-fähig zu machen, ist die Zusammenfassung der gesamten Prozedur in einem kritischen Abschnitt (z. B. mit einer Mutex). Mitunter scheuen Programmierer den Mehraufwand einer Synchronisierung bei jedem Aufruf von „get_special_object“ und versuchen dies mit dem Muster der „doppelt überprüften Sperrung“ zu umgehen. Wenn Ihnen dieses Muster mit seinen Fallstricken nichts sagt, empfehlen ich Ihnen eine kurze Google-Suche.

Wenn Sie mit den Fallstricken vertraut sind, erstaunt es Sie möglicherweise, dass es eine Version gibt, die tatsächlich funktioniert – sofern es Ihnen irgendwie gelingt, Ihren Compiler davon zu überzeugen, keine interessanten Optimierungen vorzunehmen (oder das Ganze direkt in Maschinencode schreiben) und der Code nur auf einem Einzelprozessorsystem ausgeführt wird: [Verwenden Sie Code wie diesen nie in einem Produktionssystem!] (sh. Bild 2)

multithreaded-2-300dpi

Dass dieser Code sich in Ein- und Mehrprozessorsystemen unterschiedlich verhalten kann, hat mit Caches zu tun. Alle gängigen Mehrprozessor-Architekturen haben komplexe Speichermodelle, die nicht garantieren, dass die von einem Prozessor abgewickelten Speichervorgänge aus Sicht eines anderen Prozessors in derselben Reihenfolge erscheinen. Grund für die Komplexität dieser Speichermodelle ist der, dass einzelne Prozessoren im Hinblick auf die Verwaltung ihrer Caches Flexibilität brauchen.

In diesem Beispiel ist es möglich, dass ein Thread, der auf einem anderen Prozessor ausgeführt wird, den aktualisierten „obj“-Pointer „sieht“, bevor er den initialisierten Speicher „sieht“, auf den er verweist. Das hat zur Folge, dass der Thread dem Pointer folgen und irgendwelchen nicht initialisierten Schrott lesen könnte. Diese Fehlermöglichkeit ist auf einem Einzelprozessorsystem nicht gegeben, weil auch bei Unterbrechung des initialisierenden Threads zu einem unpassenden Zeitpunkt alle Threads dieselbe Cache-Hierarchie nutzen und daher nicht diese inkonsistenten Speicherinhalte sehen können, wie sie auf Mehrprozessorsystemen möglich sind.

Um es ganz klar zu sagen: Ich rate davon ab, sich auf hochgradig plattformabhängiges und komplexes Verhalten zu verlassen. Der einzig gangbare Weg, Probleme dieser Art zu vermeiden, besteht darin, dafür zu sorgen, dass Ihr Code richtig synchronisiert ist (das heißt, dass er sich nach dem Multithread-Speichermodell ihrer Quellsprache richtet). Viele Multithread-APIs bieten ein „Einmal“-Primitive, das Sie für alle Erfordernisse Ihrer „trägen“ Initialisierung nutzen sollten.

Als wichtige Schlussfolgerung lässt sich an dieser Stelle sagen, dass die umfassende, gar erschöpfende Validierung auf einem Einzelprozessorsystem keine Garantie dafür bietet, dass Ihr Multithread-Code frei von Bugs ist, die sich auf einem Mehrprozessorsystem manifestieren.

Mehrere Kerne treiben Programme in merkwürdige Ecken des Scheduling-Universums

Das Vermeiden exotischer Synchronisierungsmuster wie die doppelt überprüfte Sperrung verringert zwar den Unterschied zwischen Einzel- und Mehrprozessorsystemen, lässt ihn aber nicht verschwinden. Schauen Sie sich diese Prozedur an, die als Thread-Einstiegspunkt dient (sh. Bild 3):

multithreaded-3-300dpi

Nehmen Sie an, dass innerhalb von do_some_initialization verschiedene Bits mit globalem Status aktualisiert werden, um die Existenz des neuen Threads zu registrieren. Nehmen Sie weiter an, dass diese Statusaktualisierungen individuell synchronisiert werden (so dass zu keinem Datenrennen kommt). Nehmen Sie zum Schluss an, dass es für einen anderen Thread schlecht ist, einen teilweise aktualisierten Status zu beobachten. Das ist der klassische Nebenläufigkeitsfehler, der als Atomicity-Verstoß bezeichnet wird. Der Programmierer geht stillschweigend davon aus, dass eine Sammlung von Statusaktualisierungen (die Initialisierung) atomisch (als Ganzes) erfolgt, auch wenn es technisch möglich ist, dass ein anderer Thread einen teilweise aktualisierten Status beobachtet.

Dieses Beispiel ist aus folgendem Grund besonders interessant: Wenn ein neuer Thread auf einem Einzelprozessorsystem erzeugt wird, hat er in der Regel relativ viel Zeit (in Software-Maßstäben) für seine Ausführung, bevor er für die Ausführung eines anderen Prozesses unterbrochen wird. Es ist also durchaus möglich, dass sich ein Atomicity-Verstoß ganz am Anfang der Existenz des Threads auf einem Einzelprozessorsystem nie zu einem Problem auswächst. Wird dieser Code jedoch auf einem Mehrprozessor-System ausgeführt, kann der übergeordnete Thread weiter ausgeführt werden, während der untergeordnete sich selbst initialisiert. In dieser Situation ist die Wahrscheinlichkeit groß, dass der übergeordnete Thread den schlechten, teilweise aktualisierten Status beobachtet. Durch den Umstieg von einem Einzelprozessor- auf ein Mehrprozessorsystem haben wir die Wahrscheinlichkeit des tatsächlichen Auftretens dieses Atomicity-Verstoßes von nahezu Null auf einen Wert gebracht, der jeden verantwortungsbewussten Programmierer beunruhigen sollte.

Im Allgemeinen haben viele Nebenläufigkeitsfehler relativ geringe Wahrscheinlichkeitsfenster. Auf einem Einzelprozessorsystem hängt das Auftreten dieses Fehlers davon ab, ob ein Thread vom Scheduler in der Mitte eines solchen Fensters unterbrochen wird. Im Normalbetrieb neigen Thread-Scheduler zu einem relativ vorhersagbaren und schlüssigen Verhalten (z. B. lassen sie einen Thread für einen bestimmte Zeit laufen oder entscheiden, nach einem ziemlich einheitlichen Muster welcher Thread als nächster ausgeführt werden soll). Folglich bleiben beim Testen von Multithread-Code auf einem Einzelprozessorsystem in der Regel große Teile des Universums der möglichen Interaktionen zwischen Threads unerforscht. Auf Mehrprozessorsystemen können selbst kleine Störungen wie Cache-Fehlzugriffe große Auswirkungen darauf haben, wie sich Events (wie Speicherlese-/-schreibvorgänge) aus verschiedenen Threads relativ zueinander ausrichten. Diese Änderungen können ihrerseits Nebenläufigkeitsfehler auslösen, die auf einem Einzelprozessorsystem praktisch nie auftreten würden.

Wie lässt sich das Problem lösen?

Die Kernbotschaft lautet hier wie folgt: Bei der Portierung eines Multithread-Programms, das auf Einzelprozessorsystemen gründlich getestet wurde, auf Mehrprozessorsysteme besteht ein erstaunlich hohes Risiko, dass bislang verborgene Nebenläufigkeitsfehler zutage treten.

Die Beseitigung dieser Nebenläufigkeitsfehler in bestehenden Codebasen kann ein sehr teures Unterfangen sein. Eine kleine, aber unüberhörbare Gruppe von Nebenläufigkeitsexperten glaubt, dass die meisten Anwendungsentwickler überhaupt keine Threads verwenden sollten. Bei der reaktiven/interaktiven Programmierung sind Event-Handling-Schleifen in der Regel deutlich weniger fehlerträchtig als Threads. Und bei der parallelen Verarbeitung sind isolierte Prozesse im Allgemeinen sicherer (wenn auch unpraktischer) als Threads.

Bei vielen Projekten sind Threads jedoch immer noch das Mittel der Wahl für die interaktive und/oder parallele Programmierung. Wie lassen sich solche Programme sicherer und stabiler machen? Eine wichtige Erkenntnis ist die, dass herkömmliche Testverfahren – vor allem auf Einzelprozessorsystemen – für das Aufspüren subtiler Nebenläufigkeitsfehler nutzlos sind.

Ein Ansatz, der das Problem zumindest teilweise löst, besteht im Rückgriff auf ein Tool wie Chess von Microsoft Research. Chess untersucht systematisch eine sorgfältig zusammengestellte Teilmenge der möglichen Schedules von Multithread-Programmen. Der Ansatz von Chess besteht darin, dass der Thread Scheduler beim Testen fortwährend schlechte Entscheidungen treffen und so die Wahrscheinlichkeit der Entdeckung von Nebenläufigkeitsfehler drastisch erhöhen kann – verglichen mit einem zufälligen Scheduling.

Neben Testtools können statische Analysetools dazu beitragen, potentiell unsichere Nebenläufigkeitsmuster zu entdecken. Statische Analysetools nutzen symbolische Ausführungs-Engines, um mögliche Probleme zu ermitteln, ohne dazu konkrete Eingabedaten oder Thread-Schedules identifizieren zu müssen, bei denen die Probleme zutage treten würden. Daher stellen die durch statische Analyse ermittelten Probleme in der Regel eine Ergänzung der mit Hilfe von Tests ermittelten Probleme dar.

Zu den statischen Analysetools, die Nebenläufigkeitsfehler finden, zählen ThreadSafe von Contemplate und CodeSonar von GrammaTech. Die aktuellste Version von CodeSonar beinhaltet die Prüfung auf unsicheren Code und kann helfen, schwere Nebenläufigkeitsfehler zu finden.

 

Alles vernetzt, alles smart und Daten ohne Ende: das „Internet of Everything“

HIER GEHTS ZUM PODCAST

 

Im „Internet of Everything“ (IoE), zu dem sich das Internet der Dinge gerade weiterentwickelt, können die vernetzten Objekte noch viel mehr. Informationen werden nicht mehr nur erfasst und weitergeleitet, sondern direkt als Basis für Entscheidungen genutzt. Die Dinge werden „smart“ und sind in der Lage, selbständig zu handeln. Der Sensor dreht die Heizung auf, wenn es kühl wird, das Smartphone weiß, dass ich auf dem Weg nach Hause bin und macht schon mal das Licht an, das Auto meldet sich zur Inspektion an, der Kühlschrank bestellt neue Milch – technisch alles längst machbar, wenn auch vielleicht nicht immer erwünscht.

Gartner schätzt, dass die Zahl der vernetzten Objekte von rund 5 Milliarden im Jahr 2015 auf 25 Milliarden im Jahr 2020 steigen wird.  Anders gesagt: Heute sind weltweit bereits etwa doppelt so viele „Dinge“ an das Internet angeschlossen wie Menschen – und ihre Zahl wächst rasant.

Das ist eine erfreuliche Entwicklung, weil smarte Geräte das Potenzial haben, unser Leben einfacher, sicherer und komfortabler zu machen. Natürlich sind noch einige Fragen zu klären, die gerade in Deutschland sehr sensibel sind: Was ist mit dem Datenschutz? Und wer haftet eigentlich für Entscheidungen, die ein Objekt trifft? Aber auch der deutsche Verbraucher wird sich langfristig nicht den Vorteilen des „Internet of Everything“ verschließen können und wollen.

Im Business-Umfeld treibt die Akteure vorrangig ein anderes Problem um: Was tun mit all den Daten, die diese vielen vernetzten Objekt tagaus tagein generieren? Denn je mehr Geräte und Maschinen „sprechen lernen“, je mehr Sensoren im Einsatz sind, desto mehr Daten werden produziert – strukturierte und unstrukturierte, einfache und komplexe, wichtige und nebensächliche.

Die Unternehmen wissen, dass sie hier über einen gewaltigen – und ständig anwachsenden – Schatz verfügen, den sie unbedingt heben müssen, wenn sie größtmöglichen Nutzen aus dem Internet of Everything ziehen wollen. Nur so werden sie auch morgen noch mit anderen Firmen mithalten können, die diese Daten konsequent erfassen, analysieren und zur Grundlage von strategischen und operativen Entscheidungen machen. Denn solche Entscheidungen werden in absehbarer Zukunft immer noch von Menschen getroffen, und nicht von Objekten, seien sie auch noch so „smart“.

Unternehmen brauchen deshalb eine durchdachte Strategie für die Erfassung, Speicherung, Konsolidierung und gezielte Analyse und Auswertung aller Daten, die ihnen bei der Erreichung ihrer Unternehmensziele irgendwie nützlich sein können. Daten von vernetzten Objekten gehören heute schon dazu, und ihr Anteil wird definitiv zunehmen, in einigen Bereichen wahrscheinlich sogar explosionsartig.

Höchste Zeit also, sich mit dem Thema auseinanderzusetzen, Strategien zu entwickeln, Prozesse anzupassen, die richtige Infrastruktur und  geeignete Werkzeuge zu implementieren. 

Die gute Nachricht ist, dass kein Unternehmen bei Null anfangen muss. Es gibt Hersteller, die langjährige Erfahrung auf diesem Gebiet haben und die Unternehmen höchst kompetent bei der Einführung von Systemen und ihrer kontinuierlichen Anpassung an neue Entwicklungen unterstützen können.

Und es gibt Beispiele von Unternehmen, die diesen Weg bereits gegangen sind und heute erfolgreich ein System der „Analytics of Everything“ einsetzen, mit dem sie gezielt den Datenschatz der vernetzten Objekte nutzen, um zukunftsfähig zu bleiben.