VMFS-Datastore entfernen

Möchte man in einer vSphere-Umgebung nicht mehr benötigte VMFS-Datastores unmounten und/oder ganz entfernen oder möchte man die Backend-seitigen LUNs hinter einem Datastore reorganisieren oder löschen, was ebenfalls mit dem Löschen des Datastores einher geht, sind zuvor in der vSphere-Umgebungen folgende Punkte zu überprüfen. Aber Achtung: beim Entfernern von LUNs müssen unbedingt folgende Bedingung geprüft werden:

• es dürfen keine VMs oder Templates dem Datastore liegen,
• der Datastore darf nicht mehr Mitglied eines Datastore Clusters sein
• der Datastore darf nicht von Storage DRS verwaltet werden,
• Der Datastore darf nicht Datastore Heartbeats für HA verwendet werden
• Storage I/O Control muss für diese Datastore deaktiviert sein.

Trotzdem ist es manchmal nicht möglich, einen VMFS-Datastore erfolgreich zu entfernen. Man bekommt dann einer Fehlermeldung der Art

„The resource ‚Datastore Name: datastore7-SAS-hv3-A VMFS uuid: 585a846d-3c03ab29-cb32-002564bb1d55‘ is in use. Cannot remove volume ‚Datastore Name: datastore7-SAS-hv3-A VMFS uuid: 585a846d-3c03ab29-cb32-002564bb1d55‘ because „file system is busy“. Correct the problem and retry the operation.“

Das wiederum kann daran liegen, dass der Datastore als “diagnostic coredump partition“ konfiguriert ist. Hierbei handelt es sich um ein mit ESXi 5.5 eingeführtes Feature, um Coredumps in einer Datei in einem File auf einem Datastore speichern zu können. In manchen Fällen wird eine solche Datei automatisch erzeugt, was verhindert, dass der Datastore entfernt werden kann.
Ob solche Dump-Files existieren, findet man schnell auf der Kommandozeile durch Eingabe von

esxcli system coredump file list

heraus. In der Ausgabe erkennt man die UUID des ESXi-Hosts, der die Datei gelockt hat. Der hintere Teil der UUID ist die MAC-Adresse von vmnic0, was eine eindeutige Identifikation des Hosts zulässt.

Zum Entfernern der coredump-Datei verbindet man sich per SSH mit diesem Host und löscht dann die Datei mit

esxcli system coredump file remove –force

Code Reviews profitieren von statischer Analyse

Dieser Beitrag erläutert, wie statische Analysetools eine ideale (und zudem automatisierte) Ergänzung zu Code Reviews darstellen, indem sie den Ablauf unterstützen und die Defektentfernungsrate erhöhen. 

Integration in einen bestehenden Prozess

Immer schon propagiert GrammaTech, dass CodeSonar für die Einbindung in einen existierenden Entwicklungsprozess vorgesehen ist und die bereits vorhandenen Tools aufwertet. Inspektionen sind nicht nur bei Code ein wertvolles Hilfsmittel, um Defekte einzudämmen. Wie woanders auch, gilt bei der Codeentwicklung, dass sich die Folgekosten umso wirksamer reduzieren lassen, je früher die Inspektion während des Entwicklungsprozesses vorgenommen wird. Bild 1 verdeutlicht die Einordnung der Inspektionen (die eine Übermenge der Code Reviews sind) über den gesamten Softwareentwicklungs-Lebenszyklus hinweg. Es ist wichtig darauf hinzuweisen, dass die Nutzung von Tools und Inspektionen nicht mit dem Deployment aufhört, denn die Tools sind auch ein Bestandteil der sich möglicherweise anschließenden Wartungs- und Upgradeprozesse.

Abbildung: Grammatech

Wie sich statische Analysetools schnell in einen bestehenden Code-Review-Prozess integrieren lassen, wird nachfolgend beschrieben. Bild 2 zeigt dazu einen modifizierten Code-Review-Prozess, der die statische Analyse vor den manuellen Review-Meetings vorsieht. Es ist davon auszugehen, dass die von den Tools gelieferten Reports in der Inspektion und der erneuten Prüfung Verwendung finden.

Abbildung: Grammatech

Vorteile der statischen Analyse für Codeinspektionen

Dass Code Reviews äußerst vorteilhaft sind, ist unstrittig, jedoch verschlingt der damit einhergehende Aufwand immens viel Arbeitszeit. Jede Möglichkeit, den Zeitaufwand zu reduzieren und gleichzeitig die Ergebnisqualität zu steigern, ist somit eine sichere Win-Win-Situation. Genau hier kommen statische Analysetools ins Spiel, die einen großen Umfang an Input liefern und einen Teil des Prüfungsprozesses automatisieren. Damit sind die Vorteile, die eine automatisierte statische Analyse bietet, jedoch nur zu einem Bruchteil beschrieben. Es gibt noch weitere Pluspunkte, eine Auswahl folgt hier:

  • Arbeit an großen Codemengen: Da es oft nicht praktikabel ist, den gesamten Quellcode zu untersuchen, hat meist nur der neu hinzukommende Code die Priorität bei der Inspektion. CodeSonar aber kann Millionen von Codezeilen, darunter auch binären Objektcode und Bibliotheken, auf Defekte und Sicherheitslücken untersuchen.
  • Aufdeckung schwer sichtbarer, verschleierter Fehler: Statische Analysetools können Fehler detektieren, die bei visuellen Inspektionen und sogar bei Funktionstests unentdeckt bleiben würden.
  • Prozess- und dateiübergreifende Fehler: Die fortschrittliche statische Analyse nimmt eine komplexe Code- und Datenpfad-Prüfung vor. Diese kann sich über mehrere Funktionen und Dateien erstrecken und damit einen Bereich abdecken, der über den Rahmen eines geprüften Moduls hinausgeht. Mit speziellen Concurrency Checkern detektiert CodeSonar auch Multithreaded/Multitasking-Probleme, die per Inspektion nur sehr schwierig zu ermitteln sind.
  • Detektierung von Sicherheitslücken: Das Prüfen auf Sicherheitslücken ist schwierig und erfordert eine andere Herangehensweise als das Prüfen auf korrekte Funktionalität. Statische Analysetools aber können sowohl Schwachstellen als auch unsichere Programmierpraktiken aufzeigen. Darüber hinaus verfolgt die Tainted-Data-Analyse die Eingangsdaten bis zu ihrer Verwendung im System und stellt sie den aufgedeckten Defekten gegenüber.
  • Toolintegration: CodeSonar lässt sich mit verschiedenen integrierten Entwicklungsumgebungen (IDEs) wie Eclipse, mit Build-Systemen wie Jenkins, mit Versioning-Systemen wie GitHub sowie mit Defektreport-Tools wie JIRA integrieren. Damit wird die Leistungsfähigkeit der statischen Analyse den Entwicklern direkt zur Verfügung gestellt und in die üblichen Programmier-, Build- und Testaktivitäten eingebunden.
  • Geringerer Code-Review-Aufwand: Statische Analysetools arbeiten automatisch, schnell und effektiv. Wird die statische Analyse an Code vor der Prüfung angewandt, reduziert sie die Zahl der Defekte im Code, die noch auf manuellem Weg gefunden werden müssen. Außerdem können statische Analysetools bei der Durchsetzung von Programmierstandards wie etwa MISRA helfen, sodass dieser Aspekt aus den Code Reviews herausfällt. Die für jede Analyse verfügbaren Reports können als unterstützende Dokumentation für den Prüfprozess herangezogen werden.

Weshalb es trotzdem nicht ohne manuelle Prüfungen geht

Code Reviews und andere Inspektionen werden von GrammaTech nach wie vor empfohlen, denn unsere Tools sollen bestehende Prozesse aufwerten und deren Ergebnisse verbessern. Es ist deshalb wichtig zu betonen, weshalb Code Reviews immer noch notwendig sind, wenn ein hohes Maß an Qualität und Sicherheit erzielt werden soll.

  • Auffinden von Defekten, die den Tools entgehen: Da die Erfolgsquote guter Inspektionsprozesse hoch ist, sind Code Reviews effektiv. Menschliche Prüfer verstehen, was mit dem Code bezweckt wird, und sind deshalb wesentlich besser in der Lage, Fehler zu detektieren. Es ist ein glücklicher Umstand, dass sich statische Analyse und manuelle Prüfung wie oben beschrieben so hervorragend ergänzen.
  • Die Inspektion beschränkt sich nicht allein auf den Code: Reviews sollten sämtliche Aspekte der Software einschließen – von den Anforderungen über das Design und die Prüfpläne bis zum Quellcode. In komplexen Projekten zahlt sich das Auffinden und Korrigieren der Anforderungen bei weitem am meisten aus. Es ist wichtig sich zu vergegenwärtigen, dass Code Reviews Bestandteil eines übergreifenden Inspektionsprozesses sind.
  • Bereitstellung wichtiger Kontextinformationen zu Tool-Reports: Entwickler verstehen die an das System gestellten Anforderungen und die zu erwartenden Resultate (oder sollten sie zumindest verstehen). Die statische Analyse und andere Tools können nur Schlussfolgerungen zum Zweck des Codes anstellen, sodass von Menschen gelenkte Prüfungen die nötigen Kontextinformationen zu den Reviews und den entsprechenden Reports beisteuern müssen.
  • Validierung der Tool-Ergebnisse: Statische Analysetools erfordern eine Interpretation der gemeldeten Fehler. Die Code-Review-Meetings dienen als Forum zur Klärung etwaiger strittiger Reports.
  • Immaterielle Vorteile: Code Reviews sind ein sehr menschlicher Prozess, und der Ablauf selbst sowie die damit einhergehenden Meetings, Prüfungen und Interaktionen bringen wichtige Vorteile mit sich, zu denen die Einarbeitung neuer Entwickler, die Stimmigkeit von Design und Implementierung sowie der Zusammenhalt des Teams gehören. Überdies erhält das Management auf diese Weise grobe Indizien für den Fortschritt und die Qualität des Projekts.

Code Reviews werden weiter bestehen und durch statische Analysetools aufgewertet. Die von Menschen geleitete Inspektion ergänzt die Tool-Automation hervorragend. Statische Analysetools senken den Zeit- und Kostenaufwand von Code Reviews und verbessern gleichzeitig die Ergebnisse des Prozesses.

Wie viele VMs pro Datastore/LUN ?

Egal ob man nun traditionellen SAN-Storage der führenden Storage-Hersteller oder softwaredefinierten hyperkonvergenten Storage (Datacore, Nutanix, Simplivity, Starwind & Co oder eine Open-Source-SDN-Lösung) anbindet, komm beim Storage-Design immer wieder die Frage auf, viele virtuelle Maschinen (also VMDK-Dateien) man auf einer LUN unterbringen kann und soll.

Eine pauschale Empfehlung vom VMware gibt es dazu nämlich nicht, weil sich die Frage pauschal nicht eindeutig beantworten lässt. Im Übrigen lassen sich unsere folgenden Empfehlungen und Überlegungen prinzipiell bzw. zum Teil auch auf andere Virtualisierungslösungen wie Linux/KVM oder VMware übertagen. Nicht alle hierbei zu berücksichtigen Aspekte sind VMware-spezifisch.

Fünf-Punkte-Plan

Sieht man mal ganz von der Frage ab, dass die Anzahl an VMs, die die eigene Storage-Landschaft hinsichtlich der „Packungsdichte“ (VMware empfiehlt Virtualisierungsraten von 4 bis 8) auf den Hosts überhaupt maximal aufnehmen kann, ist sind beim Sizing der Datastores, bzw. der LUN-Größen am Backend stets folgende Punkte zu berücksichtigen:

  1. Die LUN ist bei traditionellem Storage immer der begrenzende Faktor für die „Eigenschaften“ des Datastores, also VMs mit unterschiedlichen Workload-Charakteristiken gehören zunächst nicht auf die gleiche LUN.
  2. Andererseits profitieren möglicherweise VMs von VMDKs auf der gleichen LUN, wenn deren Workloads miteinander im Zusammenhang stehen.
  3. Ferner ist die Anzahl verfügbarer LUNs (Pfade) pro Host begrenzt. Bis ESXi 6 sind 256, ab ESXi 6,5 512 LUNs erlaubt, wobei jeder Pfad extra zählt. Ist also jede LUN z. B. über 4 Pfade erreichbar, reduziert sich die Zahl nutzbarer LUNs auf 64. Gibt es dann noch Datastores mit mehreren Extents, reduziert sich die Anzahl nutzbarer LUNs weiter. Ist aber die Anzahl der hinsichtlich der Konsolidierungsrate nutzbarer VMs deutlich größer, führt schon kein Weg daran vorbei, mehrere VMs auf einer LUN unterzubringen.
  4. Bei der Auswahl der LUN-Charakteristik ist außerdem zu berücksichtigen, ob das das Storage-Aarray VMwares „vSphere Storage APIs Array Integration“ (VAAI) unterstützt und z. B. Storage-Operationen wie „Clone Blocks/Full Copy /XCOPY“, „ATS“ (Atomic Test & Set) zur Vermeidung von SCSI Reservations, „Zero Blocks/Same Writer“ oder Thin-Provisioning auf das Storage-System offloaden kann. Seit ESX 5.1 kann der ESXi-Host übrigens Informationen zum Storage-Back-end senden, welche Blöcke im Datastore nicht mehr mit VMs-Daten belegt sind, etwa weil eine VM beispielsweise gelöscht oder migriert wurde. Seit vSphere 6,5 kann das so genannte Reclaiming im Zusammenhang mit VMFS 6 sogar automatisch erfolgen. Es ist also z. B. nicht sinnvoll, VMs mit VMware-Thin-Provisiong auf vom Storage thin provisionierte LUNs zu platzieren, um nur ein Beispiel zu nennen.

Damit aber nicht genug. Die Anzahl pro LUN sinnvoller VMs wird noch durch weitere diffizilere Eigenschaften begrenzt. So beschränkt z. B. auch die IO-Queue innerhalb von VMware die Anzahl der VMs pro Datastore. So besitzt jeder ESXi-Host eine Queue-Tiefe von 32 Kommandos pro VMFS-Datastore.

Hat der Storage z. B. eine durchschnittliche Latenz von 5ms für alle IOs, so lassen sich die theoretisch maximal möglichen IOPS berechnen, bevor der Server zusätzliche Latenzen durch ein Überlaufen der Queue erfährt: 1 (host) * 32 (Kommandos pro Queue) * 1000 ms/5ms = durchschnittliche Latenz = 6400 IOPS. Mit 6400 IOPS könnte man dann z. B. 10 sehr aktive VMs mit je 640 IOPS pro VM auf den Datastore packen. Der Wert berechnet sich stets pro ESX Host. Verteilt man also seine VMs gleichmäßig auf die ESX Server, kann man aus Performance-Sicht natürlich deutlich mehr als 10 VMs auf einen Datastore legen.

Vernetzt – aber sicher

1. IoT braucht Offenheit und Sicherheit

Das IoT erfordert offene Standards über Branchengrenzen hinweg. Das Fundament dafür bilden transparente und interdisziplinäre Forschungsarbeit sowie offene Plattformen. Partnerschaften zwischen Unternehmen und Forschungseinrichtungen oder Gremien wie das Open Interconnect Consortium, das sich für Interoperabilität und die Entwicklung übergreifender Standards für das IoT einsetzt, leisten wichtige Pionierarbeit, um das Potenzial des IoT für ein breites Spektrum an Individuen und Organisationen zugänglich zu machen. Gleichzeitig wissen wir: IoT-Ökosysteme, die auf Interoperabilität und Offenheit basieren, benötigen Sicherheit. Je mehr Geräte in einem Netzwerk angeschlossen sind, desto mehr Angriffspunkte bieten sich für Hacker. Durch die neue EU Datenschutz-Grundverordnung verschärfen sich zudem die Konsequenzen bei Datenschutzverstößen und es drohen – abhängig vom jeweiligen Verstoß – künftig höhere Bußgelder. Daher gehört zu jeder professionellen IoT-Lösung zwingend ein fundiertes Sicherheitskonzept, das proaktive Sicherheitssysteme und robuste Sicherheitsplattformen umfasst

2. Die „Open Economy“ kommt

Der Siegeszug der mobilen Endgeräte und die smarte Vernetzung im Internet der Dinge sind Treiber des Wandels hin zur sogenannten „Open Economy“. Bis 2020 werden 40 Prozent der Arbeitskräfte auf selbstständiger Basis arbeiten – das zeigt ein aktueller Bericht des britische Zukunftsforschungsinstituts The Futures Laboratory, den Samsung in Auftrag gegeben hat. Diese Freelancer und zunehmend autonome Mitarbeiter sicher und effektiv in Geschäftsprozesse einzubinden, ist eine der größten Herausforderungen, denen sich Unternehmen stellen müssen. Starre Bürostrukturen sind ein aussterbendes Modell: In der „Open Economy“ werden flexible zeitliche und räumliche Modelle dominieren. Zudem werden sich neue Formen der Kollaboration entwickeln, die nicht nur die Zusammenarbeit mit Start-Ups, sondern auch mit ehemaligen Wettbewerbern einschließen können. Die Basis für diese neuen Formen der Zusammenarbeit ist die standardmäßige Verankerung einer robusten Sicherheitsarchitektur in alle mobilen Business-Geräte. Das ermöglicht einen schnellen Austausch von Wissen und Informationen, während sensible Unternehmensdaten geschützt sind.

3. IoT ist mehr als Effizienz

Eine aktuelle Bitkom-Studie zur Digitalisierung der Wirtschaft kommt zu dem Ergebnis, dass sich deutsche Unternehmen zwar digital transformieren, jedoch nur 39 Prozent die Digitalisierung bislang nutzen, um neue Produkte und Dienstleistungen anzubieten. Das ist erstaunlich, bietet die zunehmende Vernetzung im Zuge des IoT Unternehmen doch weitreichende Möglichkeiten, Produktneuheiten, innovative Services und datenbasierte Geschäftsmodelle zu entwickeln.  Damit können sie sich nicht nur völlig neue Märkte, sondern auch neue Zielgruppen erschließen – und diese Chancen gilt es jetzt zu nutzen. Organisationen, die sich in den kommenden Jahren ausschließlich auf Prozessverbesserungen und Effizienzsteigerung fokussieren, laufen Gefahr, das vielfältige Potenzial des IoT zu verkennen. Analysten und Beratungsunternehmen schreiben dem IoT immerhin Geschäftspotenziale in Milliardenhöhe zu. McKinsey beispielsweise taxiert den wirtschaftlichen Mehrwert für 2025 global auf 3,9 bis 11,1 Billionen Dollar jährlich.

4. Kognitives Machine Learning bringt mehr Komfort

Das IoT-Zeitalter kann neuen Komfort und Service für Anwender bringen, wodurch sich die Konsumentenbedürfnisse zukünftig verändern werden. Die smarte Vernetzung von Gebrauchsgegenständen – vom Kühlschrank bis zum Auto – wird zukünftig verstärkt im Alltag Einzug halten, diesen vereinfachen und neue Dienstleistungen hervorbringen, die nicht nur bequem sind, sondern auch Zeit und Kosten sparen und den individuellen Bedürfnissen entsprechen. Bei der Entwicklung von IoT-basierten Produkten und Services wird damit die Interoperabilität der Geräte und Lernfähigkeit der Systeme immer relevanter. Nehmen wir das Beispiel autonomes Fahren: hier eröffnen leistungsstarke Lerntechnologien in Kombination mit den Daten verschiedener vernetzter Alltagsgeräte eine neue Stufe des Komforts, wenn die Cloud des Autos mit der des Anwenders verknüpft wird. So ist es Automobilherstellern möglich, die individuellen Präferenzen des einzelnen Anwenders genauer zu erkennen, sensibel auf sie zu reagieren und so Mehrwert für ihre Kunden zu schaffen.

5. IoT ist permanente Innovation

Sehr viele Organisationen leisten derzeit wichtige Vorarbeit, um das IoT für Unternehmen aller Größen und Branchen zugänglich zu machen. Doch auch, wenn die Vernetzung schon längst zur Normalität geworden ist: Geräte, Komponenten und Software werden weiter ausgebaut und für das IoT optimiert werden. Deshalb ist es so wichtig für Unternehmen, bereits jetzt die notwendigen Maßnahmen für die „IoT-Readiness“ ihrer Geräte auf den Weg zu bringen. In Zukunft wird es für Unternehmen sehr viel wichtiger sein, IoT-Lösungen schnell und agil in-house entwickeln sowie Prototypen kostengünstig selbst bauen zu können und diese schnell in den Markt zu bringen. Vor diesem Hintergrund werden einerseits leistungsfähige IoT-Plattformen, andererseits aber auch Partnerschaften zu zentralen Erfolgskriterien, um IoT-Lösungen Ende-zu-Ende nahtlos bereitstellen zu können. Offene Schnitt stellen wiederum sicher, dass Unternehmen auch von zukünftigen Innovationen profitieren können und kein „Lock-in“ entsteht, der heutige Investitionen in einigen Jahren bereits obsolet macht.

 

Erfolgreiche IoT-Geschäftsmodelle

Das Internet of Things (IoT) ist längst keine Zukunftsvision mehr, sondern in den meisten Branchen bereits Unternehmensrealität: Von 1096 Managern aus 17 Ländern haben 89 Prozent in den letzten zwölf Monaten ihr IoT-Budget erhöht und 41 Prozent gaben an, neue smarte und vernetzte Produkte oder Services entwickeln zu wollen.

Vor diesem Hintergrund stellen insbesondere die sinnvolle Weiterentwicklung bestehender Geschäftsmodelle und die Etablierung erfolgreicher neuer Geschäftsmodelle enorme Herausforderungen für viele Unternehmen dar – eine komplexe Aufgabe, denn durch das IoT stellen sich völlig neue Anforderungen an die Angebots- und Marktpositionierung, die Konfiguration der Wertschöpfungskette sowie die Ausrichtung des Erlösmodells.

IoT als Wachstumsstrategie

Das IoT eröffnet zahlreiche Wachstumsmöglichkeiten durch den Ausbau bestehender Monetarisierungsansätze und die Erschließung neuer Erlösquellen über eine Neugestaltung der Angebots- und Marktpositionierung. Insbesondere ergänzende digitale Services rund um das Kernprodukt gewinnen stark an Bedeutung, da sich die „Hardware“ vieler Hersteller zunehmend angleicht und somit herkömmliche Differenzierungmöglichkeiten abnehmen. Die typischen Stoßrichtungen solcher digitalen Zusatzangebote sind im B2B-Bereich beispielsweise eine größere Transparenz (z. B. Condition Monitoring), eine höhere Effizienz (z. B. Predictive Maintenance) oder eine einfachere Integration des Geräts bzw. der Anlage oder Maschine in die Produktionsumgebung des Kunden.

 Während gegenwärtig der Schwerpunkt der Aktivitäten noch stark auf dem Angebot kostenloser digitaler Zusatzleistungen sowie der Entwicklung neuer Angebote für bestehende Zielgruppen liegt, sind zukünftig deutlich stärker auch Marktentwicklungs- und Diversifikationstendenzen, das heißt die Erschließung neuer Zielgruppen durch IoT-Innovationen bzw. die Adressierung bislang nicht erschlossener Märkte mit neuen Services und Produkten, zu erwarten. Während solche Strategien bislang vorwiegend von Softwareunternehmen verfolgt werden, sollten auch Industrieunternehmen diese interessanten Wachstumsansätze nicht vernachlässigen.

Jedes größere Unternehmen wird mittelfristig zum Software-driven Business

Das IoT wird auch auf fast alle Aktivitäten der Wertschöpfungskette mittelfristig enormen Einfluss haben. Neben den bereits einschlägig bekannten Transformationen der Bereiche Produktion und Logistik (Industrie 4.0) ist insbesondere die Servicefunktion betroffen – neue Differenzierungsmöglichkeiten durch softwarebasierte Dienstleistungen (z. B. datengetriebene Wartungs- und Instandhaltungsservices oder Apps zur Steuerung des Smart Home) führen verstärkt zu “hybriden Produkten”, in denen das physische Produkt und entsprechende Dienstleistungen untrennbar miteinander verbunden sind.

Ein gutes Beispiel für eine datengetriebene Verschiebung der Wertschöpfung liefert KÄRCHER: Mittlerweile verkauft der Hersteller von Reinigungsgeräten und -systemen nicht mehr nur seine Produkte als solche, sondern vernetzt diese gleichzeitig mit einer Service-Cloud. Käufer der Reinigungsgeräte und Fahrzeugflotten können damit ihre Produkte in einem übersichtlichen Dashboard verorten, Unterauslastung vermeiden und über den Batteriestatus die Laderythmen besser steuern. Nur Basisfunktionen sind dabei kostenlos, Premiumfunktionen hingegen in der Serviceplattform zubuchbar.

Vor dem Hintergrund dieser Entwicklungen muss jedes größere Unternehmen mittelfristig auch zu einem Softwareunternehmen werden, um zukünftig im Wettbewerb bestehen zu können.

SMB 3.1.1 in Windows Server 2016 nutzen

Die neue SMB-Version soll zunächst deutlich sicherer sein, und Man-in-the-Middle-Angriffe verhindern können. Dazu wird SMB-Encryption erweitert. Die Technik verhindert seit SMB 3.0 (Windows 7 und Windows Server 2012), dass Angreifer auf übertragene Daten zugreifen können.  In SMB 3.1.1 wird der Chiffre bereits beim Verbindungsaufbau ausgetauscht. Das soll die Sicherheit von SMB-Verbindungen bereits gewährleisten, bevor sich Client und Server gegenseitig authentifiziert haben. Microsoft bezeichnet diese Neuerung in SMB 3.1.1 auch als „Pre-Authentication Integrity“. Die Daten zur Authentifizierung werden mit SHA-512 verschlüsselt. Außerdem wird die Authentifizierung sicherer gestaltet.

SMB 3.1.1 nutzt für SMB Encryption AES-128-GCM. Der direkte Vorgänger SMB 3.0.2 in Windows Server 2012 R2 und Windows 8.1 hat hier auf AES-128-CCM gesetzt werden. Laut Microsoft kommt AES-128-GCM in Windows Server 2016 und Windows 10 besser mit aktuellen Prozessoren von Intel und AMD zurecht. 

Neben SMB Encryption gibt es noch SMB Signing. Beide Funktionen können parallel genutzt werden, da nur so sichergestellt ist, dass Client und Server nicht übernommen und auch keine Daten ausgelesen werden können.

vSphere 6/6.5 in Test- und Entwicklungsumgebungen einsetzen

Wenn Sie noch eine Test- oder Entwicklungsumgebung installieren wollen, und die Installation zum Beispiel auf einem älteren Server, oder einem PC durchführen, kann es durchaus passieren, dass die Netzwerkadapter auf der entsprechenden Hardware nicht erkannt werden. Im folgenden Abschnitt gehen wir darauf ein, wie Sie solche Probleme beheben können.

Wenn Sie ESXi auf einem Server installieren, und der Netzwerkadapter nicht erkannt wird, erhalten Sie durch den Installationsassistent eine entsprechende Fehlermeldung. Unter Netzwerkadapter zu identifizieren, verwenden Sie zunächst die Tastenkombination Alt + F1. Dadurch öffnet sich die Konsole des Installation-Assistenten. Geben Sie hier als Benutzernamen den Benutzernamen „root“ ein und klicken Sie auf Enter. Ein Kennwort ist zur Anmeldung während der Installation nicht notwendig. Geben Sie danach den folgenden Befehl ein:

lspci -v

Anschließend zeigt der Installationsassistent alle Hardware-Geräte des Servers an. Hier sollten auch die Netzwerkadapter angezeigt werden. Merken Sie sich den Hersteller des Adapters.

Auf der Seite http://esxi-customizer-ps.v-front.de können Sie sich ein PowerShell-Skript herunterladen, welches die notwendigen Treiber automatisch aus dem Internet herunterladen kann und automatisch eine aktuelle ISO-Datei für die Installation von ESXi 6.5 erstellen kann. Laden Sie sich das PowerShell-Skript auf den Rechner herunter, öffnen Sie die PowerShell und wechseln Sie in das Verzeichnis, in das sie das Skript kopiert haben. Geben Sie anschließend den folgenden Befehl ein:

.\ESXi-Customizer-PS-v2.5.ps1 -v65 -vft -load net55-r8168,net51-r8169,net51-sky2

Der Computer, auf dem sie den Befehl ausführen, muss mit dem Internet verbunden sein, da das PowerShell-Skript den Treiber aus dem Internet herunterlädt, automatisch eine ISO-Datei zur Installation von ESXi 6.5 erstellt.

Handelt es sich bei dem Netzwerkadapter um einen anderen Hersteller, der durch diese Lösung nicht in die ESXi-Installation eingebunden werden kann, dann suchen Sie auf der Seite https://vibsdepot.v-front.de/wiki/index.php/Welcome die ID für Ihre Netzwerkadapter. Anschließend können Sie den oben gezeigten Befehl mit einem anderen Treiber ausführen. Der vordere Teil des Befehls bis zur Option „-load“ ist identisch, Sie müssen noch festlegen, welcher Treiber das Skript herunterladen soll.

 

Scale-Out-File-Server erstellen

Der Dateiserver kann auf den gemeinsamen Datenspeicher des Clusters zugreifen, und damit auch auf die S2D-Speicher. Im Rahmen der Erstellung des Dateiservers können Sie auswählen, ob Sie einen herkömmlichen Dateiserver erstellen wollen (Dateiserver zur allgemeinen Verwendung) oder einen Scale-Out-File-Server (Dateiserver mit horizontaler Skalierung für Anwendungsdaten). Die Freigaben des SOFS werden im Failovercluster-Manager verwaltet und zur Verfügung gestellt.

Der Dateiserver kann auf den gemeinsamen Datenspeicher des Clusters zugreifen, und damit auch auf die S2D-Speicher. Im Rahmen der Erstellung des Dateiservers können Sie auswählen, ob Sie einen herkömmlichen Dateiserver erstellen wollen (Dateiserver zur allgemeinen Verwendung) oder einen Scale-Out-File-Server (Dateiserver mit horizontaler Skalierung für Anwendungsdaten). Die Freigaben des SOFS werden im Failovercluster-Manager verwaltet und zur Verfügung gestellt.

 

Windows Server 2016 mit Azure verbinden

Sie können die Zeugenserver für Windows-Cluster in Microsoft Azure positionieren, genauso wie den Connection Broker für die Remotedesktopdienste. Das bietet den Vorteil mehrere Rechenzentren miteinander zu verknüpfen, um dadurch hochverfügbare und leistungsstarke Server und Cluster zu erhalten.

Der Netzwerk-Stack, die Funktionen rund um Software Definied Storage, wie Storage Spaces Direct oder Storage Replica in Windows Server 2016, sind Funktionen, die aus Microsoft Azure bekannt sind. Dazu kommen Technologien wie Azure Site Recovery, zur Replikation von VMs in Microsoft Azure oder auch Azure Backup, um komplette Server in die Cloud zu sichern.

Die Anbindung an Microsoft Azure ist vor allem dann sinnvoll, wenn ein Cluster sich über mehrere Rechenzentren ausstreckt. In diesem Fall kann Cloud Witness die Verwaltung des Quorums entscheidend und stabiler beeinflussen. Solche Cluster werden in Windows Server 2016 zum Beispiel mit den neuen Storage Spaces Direct und Storage Replica eingesetzt.

Natürlich sind auch Scale-Out-File-Server (SOFS) in Windows Server 2016 optimal als Cluster integrierbar. Auch hier ist Cloud Witness ideal. Aber nicht nur bei großen Unternehmen oder in großen Netzwerken macht der Einsatz von Cloud Witness Sinn. Nutzen Sie nur einen kleinen Cluster mit zwei Knoten, kann es sinnvoll sein den Zeugenserver in der Cloud zu positionieren.

Cloud Witness ist eine neue Art der Cluster-Quorum-Berechnung, die mit Windows Server 2016 eingeführt wird. Für Cloud Witness können Sie zum Beispiel den Microsoft Azure Blob Storage nutzen. Das vermeidet den Overhead den eine VM in Microsoft Azure bedeuten würden. Sie können ein Speicherkonto in Microsoft Azure auch als Cloud Witness für mehrere Cluster einsetzen.

Der Connection Broker steuern in Umgebungen der Remotedesktopdienste die Anbindung der Anwender. Seit Windows Server 2012 R2 ist die Erstellung eines Connection Brokers nicht mehr optional, sondern vorgeschrieben. Mit Windows Server 2016 lassen sich die Daten dazu in Azure SQL speichern.

Bei der Einrichtung hilft ein Assistent. Wählen Sie als Option „Freigegebener Datenbankserver aus“. Anschließend geben Sie den DNS-Namen zu Ihrer Datenbank in Microsoft Azure ein und die kopierte Verbindungszeichenfolge, inklusive der angepassten Daten zur Anmeldung.

Wie Maschinen per Mobilfunk global kommunizieren

Folgende Fragen sollte man sich vor der Auswahl der Technologie stellen: Sind die IoT Produkte später an einem festen Ort verbaut? Steht eine Internetnetzwerk-Infrastruktur zur Verfügung und darf diese Infrastruktur verwendet werden? Ist der Einsatz weit entfernt vom Nutzer und in welchem Land? Das wichtigste sind das Anwenderszenario und die Infrastruktur am Einsatzort.

Automatisches Maschinen-Monitoring ist angesagt

In vielen Anlagen der Prozesstechnik oder der Wasser- bzw. Energiewirtschaft bilden große Maschinen wie Pumpen, Generatoren, Turbinen oder Kompressoren wertvolle Assets, deren ständige Verfügbarkeit von hoher funktioneller und wirtschaftlicher Bedeutung ist. Konsequenterweise sind bzw. werden derartige Maschinen von den Herstellern zunehmend mit Sensorik ausgerüstet, welche einen normalen Abnützungsgrad ebenso erfassen und anzeigen kann wie ein unregelmäßiges Betriebsverhalten oder unzulässige Betriebsbedingungen. Die auf diese Weise generierten und für die Maschine oft „lebenswichtigen“ Diagnosedaten stehen dann primär an einer Schnittstelle direkt vor Ort zur Verfügung; vor Ort bedeutet jedoch in vielen Fällen in entlegenen, schwer zugänglichen Regionen mit keiner oder nur gering ausgebauter Infrastruktur, meist ohne Fachpersonal zur Maschinenwartung und vielleicht sogar ohne Internetzugang. Dieser fehlt ggf. generell oder ist aus Sicherheitsgründen seitens der IT-Abteilung des Betreibers für Nutzung zur Übertragung von Maschinendaten gesperrt. Es besteht also das Problem, die von der Sensorik bereitgestellten Diagnosedaten (oft sind das ja dringende „Hilferufe“ der Maschine) den Wartungsspezialisten oder direkt dem Maschinenhersteller zugänglich zu machen, wo auch immer in der Welt sich diese befinden.

Bluetooth ist gut geeignet im Nahbereich

Zur Lösung des aufgezeigten Problems vertrauen viele Anwender im ersten Projektgespräch auf den Einsatz von Bluetooth mit dem Hinweis, dass diese Technologie heute in mobilen Geräten zum Standard gehört und dass die Daten der Maschinen-Sensorik daher leicht auf diese Geräte ausgelesen werden können. Diese Anwender betrachten Bluetooth mit Recht als leistungsfähige und in ständiger Weiterentwicklung befindliche Funktechnologie, welche durch Eigenschaften wie das Frequenz-Hopping eine besonders sichere Übertragung bietet. Was dabei jedoch häufig übersehen wird: die Reichweite dieser Funktechnologie ist auf einen Nahbereich begrenzt: Etwa 10 m bei der Strom- und kostensparenden Bluetooth Low Energy-Variante und wahrscheinlich etwa 40 m bei der neuesten Bluetooth 5-Generation! Das reicht für eine Übertragung der Daten auf mobile Geräte in der Hand von Personen direkt vor Ort; aber wie gelangen die Daten dann unverzüglich zu den weit entfernten Wartungsspezialisten und – noch wichtiger – was passiert, wenn Personen nicht oder nur zeitweise vor Ort sind? Dafür wird dann häufig ein Ethernet-VPN-Tunnel ins Gespräch gebracht, der – wenn überhaupt realisierbar und zulässig – wegen der Notwendigkeit eines ständigen Verbindungs-Neuaufbaus  für ein Maschinen-Monitoring mit hoher Daten-Frequenz kaum geeignet ist; und eine VPN-Standleitung scheidet aus Kosten- und Sicherheitsgründen fast immer aus.

Die Lösung: Maschinen-eigenes „Mobiltelefon-Gateway“ mit globaler Konnektivität

Die Lösung des Problems liegt in der Nutzung des weltweit dichtesten Kommunikationsnetzes mit mehreren Milliarden Teilnehmern! Das ist das Mobilfunk-Netz mit seinen vielen Hundert Providern in aller Welt, welche auch sehr abgelegene und vom Internet nicht erschlossene Regionen abdecken. Diese global verfügbare Konnektivität bietet die Lösung für das hier behandelte Maschinen-Monitoring! Und die entsprechende technische Umsetzung erfolgt durch ein IoT Edge Gateway mit optionaler Bluetooth-Schnittstelle, um auch Sensoren einbinden zu können. Dieses verfügt über eine bei weltweit 400 Providern gültige Universal-eSIM-Karte, welche automatisch die Nutzung des jeweils stärksten Funknetzes veranlasst (Unsteered Roaming). Das IoT Edge Gateway wird damit zu einem global funktionsfähigen Mobiltelefon, dessen Verbindung mit der Sensorik der Maschine diese in die Lage versetzt, ihre jeweils aktuellen Diagnosedaten nach einer Datenvorverarbeitung „mobil-telefonisch“ an ein zugeordnetes Cloudportal zu übertragen. Dort stehen die Daten dann zum Abgriff durch geeignetes Fachpersonal zur Verfügung.B32A5956

Bildquelle: Schildknecht AG

Die Zahl der auf dem Pfad vom Gateway zur Cloud ggf. beteiligten Netze und die Häufigkeit der Übertragungsvorgänge bedeutet keine Beeinträchtigung, da die Abrechnung der Nutzungskosten im Portal zentral und rollenbasiert nach einem Einheitstarif erfolgt. Die monatlichen Kosten für eine Messstelle liegen im Bereich von 10 bis 20 € in Abhängigkeit vom aktuellen Betriebsmodus: dieser reicht wahlweise vom online-Modus (dauerhafte Verbindung) über den Intervall-Modus (Übertragung nur bei bestimmten Werten oder in bestimmten Zeitintervallen) bis hin zum kostenlosen „Schlafbetrieb“, bei welchem das Gerät nur in Bedarfsfällen „aufgeweckt“ wird

B32A5956

Bildquelle: Schildknecht AG

Maschinen-Monitoring per Mobilfunk als beispielhaftes IoT-Geschäftsmodell Die hier aufgezeigte Applikation des IoT Edge Gateways steht exemplarisch für die überall im Gespräch befindlichen neuen IoT-Geschäftsmodelle. Weltweite Kommunikation von Geräten und Maschinen mit Portalen, Zugriff auf Maschinen auch in entlegenen Gegenden, aus Sicherheitsgründen bewusster Verzicht auf lokale Internet-Anbindungen, globale Verfügbarkeit, geringe Übertragungskosten – das alles sind Gründe für die Nutzung von Mobilfunk zum Aufbau von IoT-Geschäftsmodellen. Das globale Mobilfunknetz bietet zusammen mit IoT Edge Gateways wie z.B. dem DATAEAGLE 7050 dafür die Basis. Spezifische IoT-Geschäftsmodelle entstehen durch enge Zusammenarbeit zwischen interessierten Anwendern und erfahrenen Funktechnik-Anbietern nach dem bewährten Ablauf vom Konzept und dessen Test bis zur Marktreife. Für ein schnelles Proof of Concept (PoC) stehen sogenannte IoT Starterkits zur Verfügung, die es ermöglichen Sensoren anzubinden, um so die technischen Möglichkeiten praktisch zu erforschen. Jedes Projekt beginnt mit der Stückzahl 1 und stellt damit die Weichen zu attraktiven und innovativen IoT-Lösungen, wie es der hier gezeigte „Telefonkontakt“ zwischen Maschine und Cloud-Portal zeigt: „Hallo Cloud-Portal“ steht als Paradigma für leistungsfähige IoT-Lösungen.