Veeam-Daten als PRTG-Sensor

Markus Kraus, wie ich vExpert, VCP und darüber hinaus ausgewiesener Cloud-Experte, z. B. für vRealize Automation hat vor rund einem Jahr zwei coole PowerCLI-Skripte gebastelt und in seinem privaten Blog My Cloud-(R)Evolution veröffentlicht, die man als Sensor in PRTG Network Monitor einbinden kann, um die umfassenden Alarmierungsmöglichkeiten von PRTG mit dem Monitoring von Veeam-Backups und Replikcation zu verbinden.

Paessler Knowledge Base

Ich benutze die Skripte regelmäßig und möchte daher noch einmal auf Markus hervorragende Arbeit hinweisen.
Inzwischen hat auch Paessler den Tipp offiziell in seine Knowledge Base aufgenommen. So bin ich letztendlich drauf gestoßen.

Download

Der von Markus Kraus geschrieben Sensor ist in zwei Versionen erhältlich. Die eine lässt sich nur mit Veeam Enterprise Server auf Basis der dort freigeschalteten RESTful-API nutzen. Markus hat aber im März letzten Jahres noch eine Version nachgeschoben, die ohne den Veeam Enterprise Server funktioniert.

Allerdings benötigt das Veeam-PowerShell-Plug-In, auf das die Version ohne Veeam Enterprise Server setzt, zwingend eine 64-Bit-Umgebung. PRTG führt jedoch sämtliche Skripte auf der Probe nur in 32 Bit aus. Abhilfe schafft das kleine Tool PSx64 aus der PRTG Tools Family. Die Handhabung und Funktionsweise beider Skripte ist in seinem Blog ausführlich beschrieben.

Ferner lassen sich beide Versionen auch mit der kostenlosen Variante  von PRTG Network Monitor einsetzen. Diese lässt sich bekanntlich ohne Einschränkungen für 100 Sensoren nutzen.

IoT für den Menschen

Use Case & Erwartungen

In der Landschaft verteilte, autark arbeitende und nicht über ein Netzwerk verbundene Mess- und Regelstationen werden durch das Wartungspersonal in regelmäßigen Abständen angefahren, kontrolliert und gegebenenfalls Steuerungsparameter neu justiert. Eine IoT-Lösung ist für diesen Anwendungsfall perfekt geeignet – aber nur, wenn der Mensch, also der Wartungstechniker, ein Wörtchen mitreden darf.

Jede Mess- und Regelstation wird mit einem IoT-Device als Brücke zwischen Internet und Steuerung ausgestattet. Sind die Daten erstmal in der Cloud, können sie von jedem Ort der Welt abgerufen und ausgewertet bzw. Kommandos zum IoT-Device abgesetzt werden. Das Wie ist hier aber entscheidend: Wie muss die Anwendung für die Wartungstechniker gestaltet sein, um fünf goldenen Regeln des App-Designs zu genügen:

 

  1. Mehrwert bieten – “Wir brauchen eine App, weil die anderen auch solche Dinger haben” ist kein Argument dafür, die Anstrengungen und Kosten für die App-Entwicklung auf sich zu nehmen. Es muss ein Mehrwert geboten werden. Im obigen Beispiel besteht der Mehrwert natürlich darin, dass sich die Wartungstechniker lange Anfahrtswege sparen – und damit Zeit und Geld. Mitunter müssen sie sogar erst nach einer Benachrichtigung von der Messstelle Maßnahmen einleiten.
  2. Sicherheit – Die App darf nicht zur Gefahr für Mensch, Umwelt und Maschinen werden. Hierfür ist mindestens ein Zugangsschutz mit entsprechendem Rechtekonzept zu realisieren. Obiges Beispiel definiert zwei Nutzergruppen, den Wartungstechniker und den Statistiker. Beide erhalten eine unterschiedliche Sicht auf die Daten: für die Wartung sind Betriebsdaten von Interesse, zur Auswertung die Messdaten selbst.
  3. Aufgabenangemessenheit – die App muss für den jeweiligen Anwendungsfall speziell konzipiert und realisiert werden, um den Mehrwert für den Anwender bzw. das Unternehmen zu erzielen. Für den Wartungstechniker kann in o.g. Beispiel der Wartungsprozess und die Reihenfolge der Schritte durch ein entsprechendes Storyboard, also der Weg durch die Screens der App, abgebildet werden. Fatal und fehleranfällig wäre, wenn er sich jedes Mal durch eine lange Liste von Parametern wühlen muss.
  4. Kosteneffiziente und flexible Entwicklung – jede App-Entwicklung ist zeit- und kostenintensiv. Wichtig ist, unter Einbeziehung der Endanwender in kleinen nutzbaren Schritten zu der App zu kommen, die ohne Schnickschnack und Extras ihren Nutzen erfüllt. In regelmäßigen Interviews und Tests tauschten sich Wartungstechniker, Statistiker und Entwickler über Ziele und Anforderungen aus und gaben einander Feedback. Somit wurde durch ein iteratives Vorgehen die App entwickelt, die beide mit Freude einsetzen.
  5. Verteilung – die App muss zum Anwender kommen. Punkt. Für die Verteilung von Individual-Apps eignen sich öffentliche App Stores jedoch ganz und gar nicht. Die App aus o.g. Beispiel ist nur für einen eingeschränkten Nutzerkreis von Interesse (dagegen fordert Apple, dass Apps barrierefrei einem möglichst großen Kundenkreis zur Verfügung stehen).

Daneben müssen für die Realisierung einer App die spezifischen Charakteristiken der Smartdevices wie verschiedene mobile Betriebssysteme (iOS, Android, HTML 5 etc.), Bildschirmabmessungen (Smartphone, Phablet, Tablet) und Interaktionsparadigmen (Touch, Multi-Touch, 3D-Touch) berücksichtigt werden. Damit sind in der Regel Mehrfachentwicklungen gleicher Entwürfe notwendig: Eine für ein iPad realisierte App muss für die Verwendung auf einem iPhone mitunter aufwändig angepasst und für die Nutzung auf einem Android-Gerät sogar vollständig neu implementiert werden — dies ist teure und unnütze Monkey Work.

Herausforderungen bei der Entwicklung von Apps

Das einführende Beispiel zeigt, dass Apps im industriellen bzw. IoT-Umfeld komplexe Entwicklungsprozesse verlangen. Apps eröffnen der Industrie bisher ungeahnte Möglichkeiten, bergen aber auch technische und organisatorische Herausforderungen und Einschränkungen.

Technische Herausforderungen

Entwickler, die industrietaugliche Apps konzipieren und realisieren, werden durch eine stets wiederkehrende Implementierung gleicher Inhalte – sog. Monkey Work – herausgefordert. Im genannten Beispiel können verschiedene Geräte wie Tablets, Phablets oder Smartphones eingesetzt werden. Einige Mitarbeiter nutzen vielleicht iOS und andere vielleicht Android. Entwickler der Apps müssen demnach Universaltalente sein: Lösungen für verschiedene Plattformen müssen mit verschiedenen Werkzeugen und verschiedenen Programmiersprachen realisiert werden. Weil dieser Aufwand kaum geleistet werden kann, gibt es zwei Möglichkeiten:

  1. Spezialisierung: Anbieter von Industrie-Apps beschränken sich gemäß den Vorlieben ihrer Zielgruppen auf möglichst wenig Plattformen. Auf diese Weise werden Entwicklungsaufwände reduziert, aber Kunden mit spezifischen Anforderungen können nicht bedient werden. Die Konkurrenzfähigkeit sinkt.
  2. Universalisierung: Anbieter von Industrie-Apps verwenden plattformübergreifende Ansätze auf Basis von HTML5. HTML5-basierte Anwendungen werden im Webbrowser des Smartdevices ausgeführt. Sie haben mit Browser-Inkompatibilitäten zu kämpfen und können die leistungsfähigen APIs plattformspezifischer SDKs nicht nutzen. Das heißt, dem Entwickler steht nur ein eingeschränkter Funktionsumfang zur Verfügung. Darüber hinaus ist immer ein Webserver notwendig.

Tablets und Smartphones sind Geräte, die durch ungleiche Displaygrößen charakterisiert sind. Je größer das Display, desto mehr Inhalt bzw. Details können dargestellt werden. Auf dem Tablet-Display ist ausreichend Platz für einen Überblick über den gesamten Prozess sowie für weitreichende Datenanalyse-Funktionen. Auf einem Smartphone ist demgegenüber zumeist nur Raum für Teilbilder und Datenlisten. Hier hilft das vielfach heraufbeschworene Responsive Design von HTML5 leider auch nicht weiter. Vielmehr sind eigenständige Entwürfe für verschiedene Gerätetypen anzufertigen.

Organisatorische Herausforderungen

Darüber hinaus bestimmen oftmals auch organisatorische Rahmenbedingungen mobiler Ökosysteme, welche Anforderungen realisiert werden können und welche nicht. So können iPhones und iPads ausschließlich über den Apple-eigenen App Store mit Apps bestückt werden. Für die Verteilung von Industrie-Apps sieht Apple das B2B-Programm vor. In jedem Fall nimmt Apple eine Begutachtung der Anwendungen vor, was mitunter ein bis vier Wochen dauert. Android-basierte Geräte können neben dedizierten App Stores (u.a. von Google oder Amazon)  direkt mit einer App bestückt werden. Inhouse-Lösungen ermöglichen das Verteilen von Apps innerhalb des Unternehmens und zwischen Partnern.

Fazit

Insgesamt sind Entwickler für das oben dargestellte Beispiel mit einer Vielzahl von Technologieanalysen und Entscheidungen konfrontiert, für die einerseits entsprechende Kompetenzen vorhanden sein müssen. Andererseits müssen Technologieentscheidungen aufgrund aktueller Anforderungen der Kunden getroffen werden, sollten aber gleichzeitig zukünftige Anforderungen berücksichtigen. Denn der Markt für Mobilgeräte ist verglichen mit den Lebenszyklen von Anlagen und Maschinen sehr kurzlebig und geprägt von einer hohen Innovationsrate. Während bspw. noch vor fünf Jahren die Blackberry-Plattform die Unternehmensanwendungen dominierte, sind es inzwischen die Plattformen Android und iOS. Noch vor zwei Jahren war Microsoft mit seiner Plattform Windows Phone ein heiß gehandelter Kandidat, dümpelt aber in diesem Segment aktuell bei unter 2% Marktanteil herum.

All diesen Erwartungen und Herausforderungen im Umfeld des Internets der Dinge gerecht zu werden und die Komplexität des Themas zu beherrschen, schreckt ein Drittel der in der Studie “Internet of Things in Deutschland 2016” befragten Unternehmen ab. Die Studie wurde von der IDG Business Media mit Unterstützung von Dimension Data in Deutschland durchgeführt.

Dabei lassen sich die Herausforderungen mit modernen Werkzeugen leicht meistern. Voraussetzung ist, dass das Werkzeug von konkreten Implementierungstechnologien abstrahiert. Zur Entwicklungszeit darf noch nicht von iOS, Android oder OPC UA gesprochen werden. Die Entwicklung der Industrie-App muss so einfach sein wie das Gestalten einer Powerpoint-Folie. Das geballte Wissen um die App-Entwicklung muss in leistungsfähige und austauschbare Softwarekomponenten mit direktem Draht zum hauseigenen App Store gekapselt werden. Damit wird die Entwicklung von Industrie-Apps zum Kinderspiel.

www.monkey-works.de

Integration von Dingen und Prozessen

Ohne Zweifel, das Internet der Dinge (IoT) hat die Phantasie beflügelt, zuerst die der Techniker und der IT, mittlerweile auch die der Business-Abteilungen und der Geschäftsleitungen. Kein Wunder, denn bis 2020 sollen rund 20 Milliarden Geräte vernetzt sein, andere Prognosen sprechen schon von 40 oder 50 Milliarden Objekten, die autonom, also ohne direkte „menschliche“ Interaktion miteinander kommunizieren sollen. Auch wenn es schon zahlreiche fertige Anwendungen gibt, stehen derzeit noch die Ideen im Vordergrund. Viele Unternehmen sind noch dabei auszuloten, was mit dem IoT in ihrem jeweiligen Anwendungsfeld alles möglich ist. Dabei zeichnen sich nicht nur neue Prozesse, sondern auch neue Geschäftsmodelle ab.

Zu den neuen Anwendungsfällen zählen beispielsweise Gewährleistung und Wartung beziehungsweise Maintenance, Themen, die für Unternehmen schon vor der IoT-Ära immer wichtiger wurden. Kürzere Produktlebenszyklen und schnellere Technologiesprünge haben gerade in der Fertigung die Anforderungen an einen effizienten Umgang mit den Produktionsmitteln stark erhöht. Ausfälle, Minderleistungen und Qualitätseinbußen stellen für die Industrie ein wachsendes Risiko dar, nicht zuletzt vor dem Hintergrund von Produkthaftung oder drohender Vertragsstrafen bei Ausfällen. Im Rahmen des Konzepts Industrie 4.0, das moderne Informationstechniken und klassische Fertigungsprozesse verbindet, erhalten Wartung und Instandhaltung mehr Bedeutung. Gerade die digitale Vernetzung von Maschinen, Herstellungsverfahren, Vertriebs- und Lagersystemen setzt eine hohe Verfügbarkeit der Produktionsanlagen und eine Minimierung von Ausfällen voraus, wenn der Gesamtprozess reibungslos ablaufen soll. Das Internet der Dinge spielt bei Industrie 4.0 eine tragende Rolle, viele Maschinen sind über Sensoren in die Netze eingebunden, so dass es nur konsequent ist, die vernetzten Objekte auch in entsprechenden Maintenance-Konzepte einzubinden.

Das grundlegende Verfahren dabei ist keineswegs neu. Längst überwachen Sensoren überall die Betriebsdaten von Geräten oder Anlagen und melden Abweichungen an eine Software, beispielsweise wenn in einer Schmelze eine bestimmte Temperatur gehalten werden muss oder wenn Füllstände zu überwachen sind. Weichen die Ist- von den Sollwerten über einen Toleranzwert hinaus ab, so kann automatisch ein Service-Fall eröffnet und eine außerplanmäßige Wartung des jeweiligen Gerätes veranlasst werden. Solche Verfahren sind in der Industrie seit langem Usus, dazu braucht jedoch niemand ein Internet der Dinge.

Dennoch bringt das IoT in diese Abläufe zwei neue Aspekte ein: Zum einen erfolgt die Kommunikation zwischen den Sensoren vor Ort und dem Wartungssystem – mithin auch die zwischen Hersteller und Anwender –im IoT über das Internet. Die Betreiber der jeweiligen Anlagen müssen daher keine Infrastruktur aufbauen, sondern können überall – und das ist tatsächlich wörtlich zu nehmen – auf vorhandene Strukturen zurückgreifen. Zum zweiten hat die zunehmende Verbreitung des IoT dazu geführt, dass Komponenten wie Sensoren, Aktoren oder Kommunikatoren immer kleiner und auch immer billiger werden. Beides hat wiederum zur Folge, dass Unternehmen nicht nur hochwertige Objekte wie Industrieanlagen oder Maschinen vernetzen können, sondern nahezu alles; also auch Endprodukte wie Aufzüge, Lampen, Fotoapparate oder Heizkörper.

Integration in die Prozesse

Ein entscheidender Punkt in solchen Szenarien ist die Integration in die Prozesse. Sensoren in Geräte einzubauen und die dort in großem Umfang generierten Daten zu sammeln, ist ja nur ein Teil einer Lösung, nicht weniger wichtig ist es, diese Daten so aufzubereiten und auszuwerten, dass die damit unterstützten Prozesse besser funktionieren als zuvor. So benötigt ein intelligentes „Incident Management System“ (IMS), das die Verkehrsströme in Echtzeit optimiert, natürlich Sensoren in Fahrbahnen, Ampeln oder Fahrzeugen, aber es braucht darüberhinaus eine Kommunikationsinfrastruktur, die die Daten an die Leitstellen übermittelt und dort müssen Systeme vorhanden sein, die die Sensordaten analysieren und daraus automatisch zum Beispiel eine Störungsmeldung genieren können. Damit nicht genug: eine IMS-Lösung muss auch in der Lage sein, ohne weitere Interaktion Prozesse anzustoßen, mit denen die Verkehrsbelastung reduziert wird. Sie müsste dann also die Teilsperrung bestimmter Strecken oder die Zuweisung von Umleitungen vornehmen. Mit einem dynamischen Case Management (DCM) lässt sich hier die Transparenz und Flexibilität der Prozesse sicherstellen. Gerade in Verbindung mit IoT kann DCM sehr gut eingesetzt werden, weil es nicht an ein starres Prozessmodell gebunden ist. Bei einer Vielzahl unterschiedlicher Ereignisse, die nicht in vorher festgelegter Reihenfolge auftreten, sind damit flexible Reaktionen möglich, und auch Rückkopplungseffekte lassen sich berücksichtigen. Mit einem derartigen System sind natürlich auch ganz andere Szenarien denkbar, etwa für die Wartung von Anlagen, für Großveranstaltungen oder in der Logistik.

Wichtig ist in derartigen Prozessen, dass die Daten zeitnah in Entscheidungen einfließen. Bei einer steigenden Anzahl von vernetzten Systemen tun sich herkömmliche IMS allerdings schwer, die überproportional wachsende Anzahl von Ereignissen, Störungsmeldungen und Alarmen zu bewältigen. Verursacht zum Beispiel ein Fahrzeug einen Unfall mit anschließendem Stau, so muss das Systeme innerhalb kürzester Zeit eine Unmenge von Ereignissen verarbeiten und Informationen weiterleiten; das reicht von der Alarmierung der Rettungskräfte bis zur Ampelschaltung auf Ausweichrouten. Zudem sollte das System kanalübergreifend arbeiten können, um wiederum alle Beteiligten vom Notarzt bis zur Straßenreinigung einzubinden. Im Bereich Maintenance sieht es kaum anders aus: Störfälle lösen Bestellungen von Ersatzteilen aus, es müssen Mitarbeiter alarmiert werden, zugleich Servicetechniker in Bewegung gesetzt und Prozessausfälle abgedeckt werden – es müssen Kunden, Lieferanten und Spediteure informiert werden – alles Prozesse, die sich in einem IMS automatisieren lassen, und die möglicherweise auf einer einzigen Sensormeldung aufbauen.

Ein IMS basiert also nicht nur auf den IoT-Komponenten, sondern muss auch analytische Funktionen abdecken und Complex Event Processing (CEP) beherrschen – das Gesamtsystem ist ein komplexes Gebilde aus Disziplinen wie IoT, DCM, CEP und anderen. Es wäre wenig sinnvoll, bloß einzelne Störungsfälle zu erfassen, zu melden und darauf punktuell zu reagieren. Tatsächlich lassen sich aus den im IMS anfallenden Daten durch Predictive Analysen ja auch Prognosen erstellen, beispielsweise für die Wahrscheinlichkeit von Unfällen an bestimmten Stellen zu bestimmten Zeiten. Des weiteren können für die jeweilige Situation mit den Verfahren des Decision Management aus den Vorhersagen konkrete Lösungen vorgeschlagen werden. Ein Decision-Mana­gement-System kann sich auf Basis der Ergebnisse dann selbstlernend optimieren.

Solche Beispiele und Szenarien zeigen, dass das Internet der Dinge oft nur der Ausgangspunkt für ein wesentlich komplexeres Gebilde aus Disziplinen wie IoT, DCM, CEP, Decision Management oder Event Processing ist. Das Zusammenwirken solcher oft sehr unterschiedlicher Ansätze ist natürlich keine einfache Angelegenheit, erst recht, weil Erfahrungswerte fehlen und ein spartenübergreifendes Know-how erst noch erarbeitet werden muss. Dennoch, in der prozessübergreifenden Integration liegt eine der wichtigsten Entwicklungslinien des Internet der Dinge.

Teil 6 – vCenter Appliance 6.5 aufsetzen

In VMware-Produkten steckt mehr Linux- und Open-Source-Technologie als so Mancher denkt. So basieren die weitaus meisten virtuellen Appliances, mit deren Hilfe VMware Zusatz-Produkte für vSphere, vRealize & Co bereit stellt, auf Suse Linux Enterprise.

Auch beim vCenter, der wichtigsten Infrastruktur-Komponente, war dies bisher so. Für Version 6.5 wechselt VMware allerdings beim Unterbau zum eigenen Photon-Linux. Bevor wir uns in den folgenden Teilen den neuen vCenter-spezifischen Funktionen wie vCenter High Availability oder der GUI-Integration von Image Builder, Auto Deploy und Update Manager zuwenden, soll hier kurz die Installation erläutert werden.

Vereinfachte Installation

Die hat sich gegenüber der Version 6.0 noch einmal vereinfacht. Während bereits Version 6.0 die prinzipielle Notwendigkeit des Ausrollens einer OVA-Datei hinter einem, direkt aus dem gemounteten ISO startbaren HTML5-basierten-Installers verbarg, muss der Nutzer in Version 6.5 nur noch die Datei <Laufwerk>:\vcsa-ui-installer\win32\installer.exe aus dem gemounteten ISO aufrufen, möchte der Installation von einem Windows-PC aus anstubsen.

Alternativ gibt es einen GUI-Installer für Mac und Lin64 im übergeordneten Verzeichnis <Laufwerk>:\vcsa-ui-installer und zudem einen CLI-Installer <Laufwerk>:\vcsa-cli-installer.

Plugins

Etwaige Plugins, wie das lästige Client-Integrations-Plugin (CIP) werden nicht mehr benötigt. Dieses war noch in Version 6.0 essentiell für das Importieren/Exportieren von VMs und vApps via OVF/OVA, für das Ausrollen von OVA/OVFs von einer URL oder aus dem lokalen Dateisystem, für das Importieren und Exportieren von Content-Library-Objekten, das Browsen im Datastore und das Verbinden von optischen Host-Laufwerken in der VM erforderlich.

Version 6.5 braucht nur noch in Ausnahmefällen-Plugins, etwa wenn der Admin Windows Authentication (SSPI) oder Smart Card Authentication aktivieren möchte. Hierzu braucht er das Enhanced Authentication Plugin (EAP).

Wizard of „OS“

Der Installer bietet im ersten Schritt die Möglichkeit, sich zwischen Installation, Upgrade, Migration und Restore zu entscheiden. Die beiden letztgenannten Punkte gab es in Version 6.0 nicht. Der Unterschied zwischen Migration und Upgrade ist, dass erstere bestehen Daten aus einem Windows vCenter holt, während Upgrade schlicht eine vCSA 6.0 auf die neue Version hebt.

Hat man sich für „Install“ entschieden, begrüßt der altbekannte Wizard den Admin, der in 9 Schritten, hübsch verpackt in einem etwas gefälligeren Design durch die bekannte Installation führt.

  • Nach dem bestätigen der Lizenz muss ich der Admin im Schritt 2 entscheiden, ob der Platform-Serives-Controller (PSC) eingebettet oder extern betrieben werden soll. Für den zweiten Fall muss man den Installer dann zwei mal durchlaufen, wobei zuerst der PSC auszurollen ist, damit dass SSO steht, bevor das vCenter installiert wird.
  • Schritt 4 erwartete die Angabe des Ziel-ESXi-Hosts oder vCenter-Servers – auch eine Nested-VCSA ist prinzipiell möglich – nebst Account-Daten für das root-Konto.
  • In Schritt 5 gibt man der auszurollenden virtullen Appliance einen Namen (das ist der, der nachher im Inventory auftaucht (noch nicht der Systemename „in“ der VM) und vergibt das Administrator-Passwort für die vSphere-eigene SSO-Domäne.
  •  Schritt 6 widmet sich der zu erwartenden Deployment-Größe, wovon die Größe der eingebetteten vPostgres-Datenbank und der bereitgestellten virtuellen Disks, sowie die Anzahl der vCPUs und des virtuellen Memorys abhängen.
  • Hat man in Schritt 7 den Ziel-Datastore gewählt …
  • … geht es in Schritt 8 um das virtuelle Netzwerk, in dem die VM platziert werden soll. Die IP-Konfiguration kann wahlweise statisch oder via DHCP erfolgen. Bei „Systemname“ schließlich erwartet das System den FQDN der VM oder deren IP-Adresse. Es ist aber anzuraten, vorher für eine funktionierende DNS-Auflösung zu sorgen, denn „nachher“ ist dieser Punkt nicht mehr änderbar und die Maschine taucht mit der IP-Adresse im Inventory auf, auch wenn man nachher die Runtime-Settigs änder.
  • Nach dem Anzeigen der Zusammenfassung in Schritt 9 kann man das Ausrollen des jetzt auf Photon basierenden vCenters mit „Finish“ einleiten und verfügt nach wenigen Minuten über ein einsatzbereites vCenter.

Office 365 Import Service nutzen

Mit dem Importdienst (https://portal.office.com/EAdmin/Compliance/Ingestion.aspx) lassen sich neue Aufträge erstellen, über die Daten zu Office 365 hochgeladen werden können. Microsoft beschreibt die Vorgehensweise in der TechNet genauer (http://bit.ly/2k7AOad). Für das Hochladen von Daten ist das Tool Azure-AzCopy notwendig. Der Link zum Download erscheint beim Einrichten des Migrationsauftrages. Microsoft hilft zusätzlich mit dem SharePoint Online-Bereitstellungsratgeber bei der Bereitstellung von SharePoint Online, auch für die Migration (https://portal.office.com/onboarding/sharepointonline#/).

Für die Migration stellt Microsoft auch CMDlets in der SharePoint Online-PowerShell zur Verfügung (https://technet.microsoft.com/library/mt203955.aspx). Mit diesen können Sie die Migration lokaler SharePoint-Umgebungen zu SharePoint Online ebenfalls durchführen.

Für die Migration wird die SharePoint-Verwaltungsshell benötigt und eine Anmeldung. Danach lassen sich neue SharePoint Online-Migrationspakete erstellen, zum Beispiel mit:

New-SPOMigrationPackage -SourceFilesPath <Dateifreigabe> -OutputPackagePath <Speicherort des Paktes> -TargetWebUrl <Ziel-URL in SharePoint Online> -IgnoreHidden -ReplaceInvalidCharacters

VMs mit Powershell zu Microsoft Azure hochladen

Die Azure-PowerShell installieren Sie über den Link http://aka.ms/webpi-azps. Nach der Installation sollten Sie überprüfen, ob im Systempfad des Rechners die notwendigen Erweiterungen für die Azure-PowerShell eingetragen sind. Dazu verwenden Sie den Befehl $env:PSModulePath. Mit dem CMdlet Add-AzureAccount erscheint ein Anmeldefenster an Microsoft Azure.

VMs werden auf Basis der VHD(X)-Dateien zu Microsoft Azure hochgeladen. Dazu wird die VHD(x)-Datei mit Sysprep vorbereitet, wenn Sie einen Windows-Server zu Microsoft Azure hochladen wollen. Um in Azure eine VM hochzuladen, besteht der erste Schritt darin, ein Azure-Abonnement zur PowerShell hinzuzufügen. Dazu verwenden Sie den Befehl  Add-AzureAccount. Das entsprechende Azure-Abonnement wird anschließend mit Select-AzureSubscription -SubscriptionName <SubscriptionName> ausgewählt.

Für das Speichern von VHD-Dateien wird ein Speicherkonto in Microsoft Azure benötigt. Ein solches erstellen Sie mit:

New-AzureStorageAccount –StorageAccountName <StorageAccountName> -Location <Location>

Das erstellte Speicherkonto lässt sich als Standard definieren, um leichter VHD-Dateien hochladen zu können:

Set-AzureSubscription -CurrentStorageAccountName <StorageAccountName> -SubscriptionName <SubscriptionName>

Die VHD-Dateien werden in einen Container innerhalb eines Speicherkontos hochgeladen. Der Befehl, um einen neuen Container zu erstellen lautet:

New-AzureStorageContainer -Name <ContainerName> -Permission Off

Sobald der Container zur Verfügung steht, können Sie VHD-Dateien hochladen:

Add-AzureVhd -Destination „https://<StorageAccountName>.blob.core.windows.net/<ContainerName>/<vhdName>.vhd“ -LocalFilePath <LocalPathtoVHDFile>.

Your connection is (not longer) not private

Die Bestrebungen der meisten Webbrowser, unverschlüsseltes HTTP als überholt zu betrachten, in jedem Fall aber vor dem Herstellen einer unverschlüsselten Verbindung zu warnen ist zweifelsohne begrüßenswert.

Wer sich allerdings keine eigenen SSL-Zertifikate von Verisign & Co leisten kann und will oder nicht in der Lage ist, eine eigene CA zu betreiben, muss damit leben, z. B. beim Zugriff auf NAS-Geräte, Virtualisierungshosts, Datenbanken, Webmaildienste etc. eine Warnung zu erhalten, die dann ggf. ignorieren muss.

Manche Unternehmen erstellen auch mit OpenSSL eigene Zertifikate, was mit etwas Kommandozeilen-Know How auch kein Problem ist. Allerdings untersten nicht alle Software-Produkte für Unternehmen selbst signierte Zertifikate, etwa VMware vSphere.

Let´s Encrypt

Als Ausweg bietet sich Let’s Encrypt an. Das Projekt ist jetzt ein knappes Jahr am Start, wird von der gemeinnützigen Internet Security Research Group (ISRG) betrieben und von namhaften Sponsoren wie der Mozilla Foundation, die Mozilla Foundation, Chrome, die Electronic Frontier Foundation (EFF) oder Cisco Systems finanziert.

Ebenfalls involviert sind die Zertifizierungsstelle IdenTrust, die University of Michigan (U-M), die Stanford Law School und einige mehr.  Weitere Sponsoren finden sich auf der Projektseite.

Synology

Nach und nach steigen auch immer mehr Hard- und Software-Hersteller auf den Zug auf.

Exemplarisch genannt sei hier der taiwanesische Storage-Hersteller Synology. Viele kleine Unternehmen, aber auch größeren Firmen setzen z. B. in Außenstellen häufig preiswerte NAS- und SAN-Geräte von Synology ein.

Die Tainwanesen bietet seit Version 6 Ihrer Firmware „Disk Station Manager“ (DSM) direkt in der grafischen Oberfläche die Möglichkeit, kostenlose Zertifikate von Let’s Encrypt einzurichten. DSM 6.0 ist erstmals im Märtz 2016 erschienen, also kurz nach dem Projektstart von Let`s Encrypt. Aktuell ist die Version 6.0.2-8451 Update 9. Der Prozess des Einrichtens ist in der vorbildlichen Knowledge Base von Synology umfassend beschrieben.

Daten in der Wolke – vom Winde verweht?

Tatsächlich erkennen immer mehr Entscheider in kleinen und mittelständischen Unternehmen, dass der Einsatz von Cloud-Computing eine Reihe von großen Einsparungen ermöglichen kann. Und, viele Ansprüche von Kunden als auch Mitarbeitern (Stichwort Arbeit 4.0) sind ohne Services aus der Cloud nicht denkbar.

Daten in der Wolke – vom Winde verweht?

Auf Deutsch bedeutet der Begriff in etwa „Datenverarbeitung in der Wolke“. Gemeint ist damit eine nicht-lokale Verarbeitung von Daten – Hardware und Software sind nicht notwendigerweise lokal im Unternehmen vorhanden (On Premise oder Private Cloud genannt), sondern werden von Dienstleistern über das Internet zur Verfügung gestellt, aus Datenzentren heraus, die praktisch überall sein können. Vielleicht ist es der Begriff, der vielen Verantwortlichen Unbehagen bereitet. Sind die Unternehmensdaten in der Cloud sicher oder „vom Winde verweht“?

Cloud Computing oder On Premise?

Die Leistungen von Cloud-Computing Anbietern sind im Hinblick auf Speicherkapazitäten, Performance und Sicherheit in der Regel kostengünstiger als die Vorhaltung eigener entsprechender Hardware nebst dazugehörigem Fachpersonal. Und genau hier liegt auch ein großer Vorteil für KMUs, sich keine extra Serverräume und IT-Spezialisten leisten zu müssen. Insbesondere die Fähigkeit zur Analyse großer Datenmengen (Big Data) in hoher Geschwindigkeit ist von lokaler IT-Kompetenz oftmals nicht zu vertretbaren Betriebskosten zu bewerkstelligen. Zudem wird Software zunehmend als Dienstleitung aus der Cloud heraus (Software-as-a-Service, abgekürzt „SaaS“) genutzt. Mitunter teure Programme müssen also nicht zwingend erworben und installiert werden. Sollen mehrere Standorte miteinander vernetzt und mit identischer Software versorgt werden, ist Cloud Computing gegenüber On-Premise ebenfalls im Vorteil. Gleiches gilt für die Bereitstellung von Betriebsinformationen auf mobilen Geräten. 

Big Data in der Industrie: Die Nadel im Heuhaufen finden

Ein typisches Cloud Computing Szenario in produzierenden Unternehmen ist die kontextbasierte Informationsdarstellung: Mitarbeiter aus der Produktion oder dem Service erhalten gezielt jene Informationen, die aktuell benötigt werden – automatisiert und idealerweise auf mobilen Endgeräten (Tablet, Smartphone, Smartwatch). Hierfür müssen die erforderlichen Informationen gleichermaßen aus Echtzeit- und historischen Daten zusammengestellt und analysiert werden. Echtzeitdaten werden unter anderem mithilfe vorhandener oder neu installierter Sensoren ermittelt. Beispielsweise erfassen Temperatursensoren die Umgebungsbedingungen von Maschinen. Unter Einbezug der historischen Daten führen Cloud-Dienste anschließend eigenständig Analysen durch und ziehen dadurch Rückschlüsse auf mögliche, zukünftige Ereignisse wie Störungen oder Risiken – hier anhand der Umweltbedingungen. Dadurch kann Maschinenverschleiß bereits frühzeitig anhand erkannt werden. Für diese Form der Zustandsüberwachung (Condition Monitoring) können unterschiedlichste Sensorwerte herangezogen werden, wie Stromverbrauch, Feuchtigkeit etc. Diese zusätzlichen Informationen werden über Benachrichtigungen oder Dashboards eindeutig und frühzeitig kommuniziert um Reparaturen oder Austausch einzuplanen. Dadurch werden Produktionsausfälle sowie Verzögerungen vermieden, sodass diese erheblichen Kosten- und Risikostellen nicht länger unerwartet auftreten können.

IoT Gateways: Daten vom Sensor in die Cloud

Geräte in der Automatisierungs-Pyramide, angefangen bei autarken Sensoren und Steuerungen, sind in der Regel nicht dafür ausgelegt, Daten in die Cloud zur übertragen. Dafür werden so genannte IoT Gateways eingesetzt. Sehr gut geeignet für diese Aufgabe sind kleine Industrie-PCs wie die MICA von HARTING, die im Hinblick auf Leistung, Konnektivität und Return-on-Investment (ROI) für diese spezielle Aufgabe ausgelegt sind. MICA als IoT Gateway sammelt Sensordaten oder greift die Daten zum Beispiel aus der SPS ab, wandelt diese ggf. in ein interpretierbares Datenformat wie OPC-UA um und übermittelt mittels eines installierten Cloud Connectors die Daten in die „Wolke“. Durch die Container-Architektur der MICA können dabei Connectoren verschiedenster Cloud-Anbieter wie Apps problemlos installiert werden. Bereits realisiert oder zertifiziert sind Anwendungen mit bekannten Cloud-Anbietern Dimension Data, IBM Bluemix, Microsoft Azure und SAP Hana.

Datensicherheit bei Cloud Computing

Vielen Firmen liegt verständlicherweise das Thema Datensicherheit sehr am Herzen. Gemeint ist sowohl der Schutz vor fremden Zugriffen (Hacker) als auch die unbefugte Verwendung der Daten durch den Infrastrukturbetreiber. Dafür bieten sich VPN (Virtuelles Privates Netzwerk) Verbindungen zwischen den IoT Gateways und der Cloud oder sogar der Endanwendung an.  Diese müssen jedoch einfach bedienbar und mit standardisierter Hardware und üblichen Kommunikationswegen betreibbar sein.

Ein weiterer Aspekt ist die garantierte Datensicherheit beim Cloud-Service. Die Befürchtung ist, ob ein internationaler Anbieter, der sich in einem Land befindet, das weniger strenge Anforderungen an den Datenschutz richtet, dieses große Bedürfnis deutscher Unternehmen bedienen kann. Unternehmer müssen jedoch trotz umfassendem Datenschutz keinen Nachteil gegenüber Konkurrenten befürchten. Die Lösungen und Beispiele für effektives Cloud-Computing aus Deutschland können sich im internationalen Vergleich problemlos gegen Konkurrenzprodukte behaupten. Internationale Anbieter wie Microsoft haben ebenfalls darauf reagiert und bieten mittlerweile Cloud Server auf deutschem oder europäischem Boden und berücksichtigen entsprechende Datenschutzbestimmungen.

Eine gutes Basiswissen zum Thema Cloud Security bietet das Bundesamt für Sicherheit in der Informationstechnik (www.bsi.bund.de). In dem Dossier „Anwender Professionals“ finden sich viele Hinweise zu Themen wie Sicherheitsprofile, Notfallmanagement, Zertifizierungen und Service-Level-Agreement.

Dieser Beitrag erschien zuerst auf www.mica.network.

Linux-Kernel 4.9 LTS und 4.10

Ich berichte nur noch selten über neue Linux-Kernel-Versionen. Wer Enterprise-Distributionen wie RHEL nutzt verlässt sich in der Regel darauf, einem vom Hersteller optimal gepflegten Kernel zu bekommen, wobei Red Hat zugegebenermaßen innerhalb eines Releases mit Backports arbeitet. Zwei aktuelle Kernel-Meldungen scheinen mir aber doch berichtenswert.

Grafikbeschleunigung in virtuellen Maschinen

So soll das für Februar angekündigte Linux 4.10 eine neue Technik erhalten, mit der VMs künftig die Grafikbeschleunigung der im Host verbauten Grafikkarte nutzen können sollen. Die neue Technik soll ähnlich funktionieren wie VGA Passthrough, d. h. die wesentliche Kontrolle über den Grafikchip bleibt beim Host.

Die Technik ist allerdings auf Treiber-Support und damit auf die Unterstützung der Hersteller angewiesen und steckt noch in den Anfängen, d. h. sie ist nur rudimentär mit GPUs in Intels modernen Prozessoren nutzbar.  Angeblich arbeiten die Kernel-Entwickler aber mit Hochdruck an Verbesserungen. Auch für AMD- und Nvidia-Treiber soll eine ähnliche Technik in naher Zukunft zur Verfügung stehen. 

Als weitere für Linux 4.10 geplante Neuerungen werden im Kernel-Log vor allem Verbesserungen der Treiber für die GPUs von AMD, Intel, Nvidia und Raspberry Pi genannt.

Linux LTS

Ferner hat der Kernel-Maintainer Greg Kroah-Hartman auf der Kernel-Malingliste mitgeteilt, dass der im Dezember 2016 veröffentlichte Kernel das Potenzial als Kandidat für den nächsten LTS-Kernel mit verlängerten Support von zwei Jahren habe.

Offenbar rückte Hartman mit der Bekanntgabe auf mehrfache Nachfrage nur zögerlich raus, weil das Resultat dann meistens darin bestehe, dass Entwickler ihre Patches in einem nicht optimalen Zustand einreichen, um noch in die LTS-Version kommen.

Peer-to-Peer oder Upstream-Server nutzen

Die Einstellungen dazu sind auch in Windows 10 ohne Gruppenrichtlinien über Einstellungen\Update und Sicherheit\Windows Update\Erweiterte Optionen\Übermittlung von Updates auswählen zu finden.

Setzen Sie mehrere WSUS-Server im Unternehmen ein, ist es nicht notwendig, dass sich alle Server direkt bei Microsoft synchronisieren. Sie können auch einen Upstream-Server festlegen, von dem andere WSUS-Server ihre Updates beziehen. Auf Wunsch haben Sie auch die Möglichkeit nicht nur die Updates zu synchronisieren, sondern auch die Einstellungen.

Sobald Sie den Quell-WSUS-Server eingerichtet haben, rufen Sie auf den untergeordneten WSUS-Servern Optionen\Updatequelle und Proxyserver auf. Aktivieren Sie die Option „Von einem anderen Windows Server Update Services-Server synchronisieren“. Im Fenster geben Sie den Servernamen ein sowie den Port 8530, wenn Sie kein SSL konfiguriert haben. Nutzen Sie bereits SSL, verwenden Sie den entsprechenden Port.