Die Skriptsprache JavaScript hat man entwickelt, um dynamische HTML-Dokumente im Webbrowser anzeigen zu können. Die Verarbeitung von JS-Code erfolgt meist direkt im Webbrowser des Nutzers. Mit der Programmiersprache Java hat JavaScript jedoch nicht viel gemeinsam.

Entwicklungsgeschichte von JavaScript

Die Skriptsprache wurde von Netscape ursprünglich unter der Bezeichnung LiveScript entwickelt. Das Ziel der Netscape-Entwickler war es, dynamische HTML-Inhalte direkt im Webbrowser des Nutzers darstellbar zu machen. Der Einsatz von JavaScript sollte Entwicklern die Möglichkeit geben, statische HTML-Dokumente mit dynamischen Elementen anzureichern, Nutzer-Aktionen zu interpretieren und darauf entsprechend zu reagieren, Webseiteninhalte dynamisch zu ändern und Inhalte auf Abruf zu generieren und darzustellen.
Die Programmiersprache Java erlebte in der zweiten Hälfte der 1990er-Jahre einen beispiellosen Höhenflug und wurde von vielen Entwicklern genutzt, um interaktive Desktop- und Webanwendungen zu programmieren. Aufgrund einer Zusammenarbeit mit dem IT-Giganten Sun Microsystems, der die Programmiersprache Java im Jahr 1995 der breiten Öffentlichkeit vorgestellt hatte, entschied sich Netscape dazu, ihre neue Sprache in Anlehnung an die Programmiersprache von Sun Microsystems JavaScript zu nennen. Allerdings teilen sich diese beiden Sprachen fast keine Gemeinsamkeiten.

Netscape veröffentlichte JS im Jahr 1995. Es war fester Bestandteil des zu dieser Zeit sehr beliebten Webbrowsers Netscape Navigator. Begünstigt durch die schnelle Verbreitung des Internets Ende der 1990er-Jahre verbreitet sich JS sehr schnell. Im Laufe der Jahre wurde die Skriptsprache kontinuierlich weiterentwickelt und durch neue Funktionen und Features ergänzt, sodass JS heutzutage neben PHP (LINK) und Python (LINK) zu den grundlegenden Sprachen des World Wide Web gehört.

Skriptsprache ist sehr dynamisch und äußerst flexibel

Einen wesentlichen Anteil am Erfolg von JavaScript hat die Unabhängigkeit von spezifischen Webbrowsern beigetragen. Die Skriptsprache selbst ist sehr dynamisch und äußerst flexibel. Sie verfügt über objektorientierte Eigenschaften und bietet Unterstützung für verschiedene Programmierparadigmen, wie beispielsweise prozedurale, objektorientierte oder funktionale Paradigmen. Dank Node.js lässt sich JavaScript heutzutage nicht nur clientseitig im Rahmen eines Webbrowsers nutzen, sondern auch direkt auf einem Webserver (Apache oder nginx).

Welche Projekte kann man mit JavaScript realisieren?

Durch den Einsatz von JS lassen sich viele unterschiedliche Projekte und Funktionen realisieren.

Im Folgenden gehen wir auf gängige Einsatzgebiete von JavaScript ein:
– dynamische Veränderung von Webseiteninhalten
– Erstellung interaktiver Menüs
– Aktualisierung von HTML-Elementen und Daten, ohne einen Reload der gesamten Webseite
– Veränderung von Texten oder Grafiken durch Aktionen des Nutzers

Abgrenzung zu Skriptsprache Java

Obwohl JavaScript und Java einen ähnlichen Namen haben, teilen sich die beiden Programmiersprachen jedoch nur wenige Gemeinsamkeiten. Bei Java handelt es sich um eine objektorientierte, vollwertige Programmiersprache, die einen wesentlich größeren Funktionsumfang und Befehlssatz bietet als JavaScript. Experten sehen Java als Derivat von C++ an.
Bei JavaScript hingegen handelt es sich um eine Skriptsprache, die grundsätzlich nicht alleine lauffähig ist. JS-Skripte benötigen eine Laufzeitumgebung wie den Webbrowser oder Node.js, um ausgeführt zu werden. JavaScript war ursprünglich dazu vorgesehen,  um es lediglich im Browser einzusetzen. Inzwischen lassen sich JS-Skripte jedoch auch unabhängig vom Browser direkt auf dem Webserver ausführen.

Sicherheitsaspekte

Mit den Möglichkeiten, die JavaScript mit sich bringt, gibt es auch ebenso viele sicherheitskritische Aspekte bei der Ausführung von JS-Skripten. Viele dieser Problemstellungen werden durch das sogenannte „Sandbox-Prinzip“ effektiv gelöst. Alle Befehlszeilen werden von dem Browser in einem isolierten Bereich ausgeführt und haben ausschließlich Zugriff auf die Ressourcen des Webbrowsers und nicht des gesamten Computers.
So wird  der Zugriff auf das Dateisystem durch die Sandbox unterbunden. Darüber hinaus führen moderne Webbrowser wie Chrome oder Firefox jede aufgerufene Webseite, Webanwendung oder Domain  isoliert voneinander aus. Dies erschwert den Datenaustausch zwischen den einzelnen Instanzen, wodurch das Risiko vor sogenannten „Cross-Site-Scripting-Angriffen“ minimiert wird.

JavaScript im Kontext der Suchmaschinenoptimierung

Suchmaschinen analysieren den JS-Code in der Regel nicht. Suchmaschinen-Crawler können die dynamische Interaktion  nicht nutzen. Ein Crawler besucht die Webseite so, wie ein Besucher, bei dem JavaScript explizit im Webbrowser deaktiviert ist. Demzufolge kann ein Web-Crawler Websites nicht erreichen, die man in JavaScript geschrieben hat. Dies hat negative Folgen für das Suchmaschinenranking der betroffenen Webpräsenz.

Weitere Problemstellungen bei JS

Es kommt immer wieder vor, dass Webseitenbetreiber versuchen, JS-Code für die eigenen Interessen zu missbrauchen. So können zum Beispiel mehrere Pop-Up-Fenster ohne Zustimmung des Nutzers automatisch geöffnet werden. Weitere Funktionen, mit denen man den JS-Code missbrauchen kann, sind:
– ungewollte Änderungen am Browserfenster
– das Tarnen zwielichtiger Links und Internetadressen
– die absichtliche Deaktivierung von Kontextmenüs zum Speichern und Kopieren von Webinhalten

Das Betriebssystem vermittelt zwischen Hardware und Programm

Ein Betriebssystem, auch OS (von englisch operating system) ist eine Software zwischen Hardware und Anwendungsprogrammen. Das Betriebssystem vermittelt den Zugriff auf die Hardware-Ressourcen des Computers, wie Arbeitsspeicher, Festplatten, Drucker und USB-Ports. Nicht nur der PC braucht ein Betriebssystem, sondern auch Tablets, Smartphones und andere Computer. Bekannte Betriebssysteme sind Windows, Mac OS , Unix, Linux, iOS und Android.

 

Das Betriebssystem verwaltet und kontrolliert die Hardware, also die Komponenten des jeweiligen Computers. Dazu gehören auch Ausgabegeräte, wie Drucker, DVD-Laufwerk, Tastatur, die Maus und andere Schnittstellen der Hardware, wie etwa USB-Ports. Im Grunde könnte eine Anwendungssoftware, wie z. B. MS Word, diese Aufgaben auch selbst übernehmen. Dann müsste das Anwendungsprogramm jedoch für die verschiedenen Hardwareausführungen der Computer spezielle MS-Word-Versionen anbieten. Mit dem Betriebssystem wird hingegen der Verwaltungsaufwand für die Anwendungsprogramme reduziert und zusätzlich eine einheitliche Oberfläche geschaffen, auf die eine Software von Drittanbietern aufsetzen kann.

Betriebssystem als Softwareschicht zwischen Hardware und Programm

Betriebssysteme verbinden die Anwendersoftware mit den Hardware-Ressourcen. Auf fast allen Arten von intelligenten, computergestützten Geräten wird zunächst ein Betriebssystem installiert: Desktoprechner, Laptops, Server, Minicomputer, Großrechner in Rechenzentrum sowie kleinere Systeme wie Smartphones, PDAs (Blackberry u.a.) haben ein Betriebssystem, um anderen Programmen einen standardisierten Zugriff und Kontrolle auf die Hardware-Ressourcen zu ermöglichen. Neben Windows, Mac OS und Linux nutzen einige Universitäten und Forschungseinrichtungen selbst entwickelte Betriebssysteme. Dazu gehören beispielsweise das Betriebssystem Amoeba der Vrije Universiteit Amsterdam. Amoeba ist inzwischen eines der bekanntesten Betriebssysteme für verteilte Systeme. Weitere Uni-Betriebssysteme sind Barrelfish der ETH Zürich und Microsoft Research sowie Rainbow, ein verteiltes Betriebssystem der Universität Ulm.

Bestandteile von Betriebssystemen

Zum Betriebssystem gehören drei grundlegende Bestandteile:

Kernel: Der Systemkern verwaltet den Speicher, den Prozessor und die Prozesse des Systems. Er ist für die Hardware zuständig und triggert beim Start andere Programme für weitere Aufgaben, wie etwa die Gerätetreiber für Drucker und Peripherie.

– Über den Befehlsübersetzer man mit dem Betriebssystem kommunizieren.

– Dateisystem: Das Betriebssystem definiert auch das Dateisystem, das für die Struktur und Ablage von Dateien zuständig ist.

Abläufe im Betriebssystem:

– Benutzerkommunikation

– Ausführen und Beenden von Programmen

– Zuteilung der Prozessorzeit

– Verwaltung von Speicherplatz und angeschlossenen Geräten Zugriffsbeschränkungen.

Anforderungen an ein Betriebssystem

  1. a) Schaffung von Schnittstellen zu Anwendungsprogrammen

Jede Anwendung (z. B. eine Textverarbeitung) erhält mit dem Betriebssystem einen klar definierten und sauberen Zugriff auf die verfügbare Hardware. Der Programmierer wendet sich nicht an die jeweiligen RAM-Module des Arbeitsspeichers, sondern an die zuständige Softwarekomponente des Betriebssystems. Damit muss der Programmierer die spezifischen Hardwareeigenschaften der verbauten RAM-Module nicht kennen. Das Betriebssystem erzeugt demzufolge abstrakte Objekte, um die Komplexität der unterliegenden und oftmals recht herstellerabhängigen Hardware beherrschbar zu machen.

  1. b) Die Verwaltung der Hardware-Ressourcen

Das Betriebssystem teilt den Benutzern bzw. der Anwendungssoftware die Prozessorleistung zu. Auch Speichereinheiten und Peripheriegeräte werden vom Betriebssystem verwaltet und verteilt. Übernimmt ein Anwendungsprogramm eine Ressource, wie z. B. einen Drucker, so übernimmt das Betriebssystem gleichzeitig die Überwachung des Vorgangs. Bei mehreren Druckanfragen von unterschiedlichen Programmen, entscheidet das Betriebssystem nach definierten Algorithmen, wie eine Verteilung der Ressource erfolgt. Wird ein Computer oder ein Netzwerk von mehreren Benutzern verwendet, müssen vom Betriebssystem zusätzlich Maßnahmen für den Speicherschutz getroffen und konkurrierende Zugriffe auf andere Betriebsmittel geregelt werden.

Systemsoftware vs. Betriebssystem

Das Betriebssystem ist Teil der Systemsoftware, die sämtliche Abläufe auf dem Rechner steuert. Zur Systemsoftware gehören Editoren, Compiler und Interpreter. Browser und andere Anwendungssoftware, wie z. B. ein Buchhaltungsprogramm, nutzen die Systemsoftware für einen ordnungsgemäßen Ablauf. Geregelt ist der Begriff des Betriebssystems sowie sein Umfang in der DIN 44300. Der Umfang des Betriebssystems ist jedoch nicht unumstritten und führende Informatiker grenzen die Komponenten des Betriebssystems weiter ein oder weiten seinen Umfang aus. Im Informatik-Duden gehören auch Übersetzungsprogramme und Dienstprogramme zu den wesentlichen Betriebssystem-Komponenten. Ein Beispiel für die Kontroversen um die Abgrenzung des Betriebssystems ist der GNU/Linux-Namensstreit.

Treiber für Hardwarekomponenten

Die Computer-Hardware eines Desktop-Computers ist zwar selbst zwischen den Herstellern sehr ähnlich, jedoch können die jeweiligen Hardwarekomponenten oder Bauteile unterschiedliche Anforderungen stellen. Wird beispielsweise eine Komponente eines Computers ersetzt, sind meist zusätzlich spezielle Treiberprogramme des Herstellers erforderlich. Einige dieser Treiber werden mit dem Betriebssystem, wie z. B. MS Windows ausgeliefert, jedoch sind nicht alle Versionen und Geräte im Lieferumfang enthalten. In einem solchen Fall müssen die Treiber von der Herstellerseite heruntergeladen werden.

Geschichte der Betriebssysteme

Anfänglich wurden Software und Daten noch über Lochkarten in den Computer gebracht. Der Begriff der „Batchverarbeitung“ (deutsch: Stapelverarbeitung) stammt aus dieser Zeit. Die Lochkarten mussten als Stapel in das Lesegerät des Großrechners eingelegt werden. Meist war die Reihenfolge der Lochkarten wichtig und durfte nicht durcheinandergebracht werden. War eine Lochkarte beschädigt, musste der Stapel beendet, die Karte erneuert und die Einleseprozedur nochmals gestartet werden. In den Anfängen der Großrechner gab es zunächst keine Hardwarespeicher und externe elektronische Speichermedien. Festplatten wurden später entwickelt und waren lange Zeit sehr teuer. An die permanente Ablage von Daten auf einer Festplatte war nicht zu denken. Nach den Lochkarten übernahmen Magnetbänder die Rolle der erschwinglichen Datenträger. Der Begriff der Batch- oder Job-Verarbeitung beschreibt heute die sequentielle Planung von Programmläufen, die meist automatisch getriggert wird.

Aktuelle Hardware und ihre Betriebssysteme

Die Vorläufer der Desktopsysteme waren Heimcomputer mit Betriebssystemen wie AmigaOS, DOS, LUnix, MiNT oder GEOS für den Commodore C64. Auf Großrechnersystemen, die häufig IBM-Maschinen waren, wurde häufig das Betriebssystem AIX installiert. Die Betriebssysteme BS1000 bis BS3000 liefen auf Siemens Großrechnern. Java-basierte Betriebssystem sind typische Middleware-Produkte, wie etwa das JavaOS von Sun Microsystems, MIDP (Mobile Information Device Profile) und JNode (Java New Operating System Design Effort). Auf Desktoprechnern laufen heute Microsoft Windows, BSD inkl. Mac OS von Apple sowie GNU/Linux.

Server-Betriebssysteme

Die bekanntesten Systeme sind Microsoft Windows, Unix und Linux. Für Windows sprechen seine einfache Bedienbarkeit sowie die Vielzahl der windows-basierten Anwendungssoftware, die zudem oft nur eingeschränkt auf anderen Betriebssystemen lauffähig ist.

Linux-basierte Serversysteme haben ihre Vorteile, wie etwa die das offen gelegte Coding (Open-Source-Software). Damit kann jeder das Betriebssystem einsehen, ändern und erweitern. Ein weiterer Vorteil der Open-Source-Systeme ist eine sich bildende Community, die ständig Neuerungen und Sicherheits-Updates bereitstellt.

In großen Rechenzentren spielen Unix-Betriebssysteme noch immer eine Rolle. Sie sind besonders stabil und zuverlässig. Herausgebildet haben sich auf dem Markt die Unix-Derivate AIX (IBM) und HP-UX (Hewlett-Packard). Unix-Betriebssysteme gelten als weniger angreifbar.

Eine Datenbank ist eine organisierte Sammlung von elektronischen Daten. Der physischen Datenbank übergeordnet ist ein Datenbank Management System (DBMS). Das DBMS ist die Software, die mit Endbenutzern, Anwendungen und der Datenbank selbst interagiert, um die Daten zu erfassen, zu analysieren, verwalten oder zu löschen. Zusammen bilden diese beiden Komponenten ein Datenbanksystem (DBS).

Warenwirtschaftssysteme, Enterprise Ressource Planning (ERP) Software und CRM Systeme nutzen Datenbanksysteme im Hintergrund. Datenbanksysteme wie MariaDB und MySql installieren Internet Service Provider standardmäßig für das Hosting von Onlineshops und Content Management Systemen (CMS) wie WordPress oder Joomla.

Der Begriff Datenbank bezieht sich formal auf eine Reihe verwandter Daten und deren Organisation. Der Zugriff auf diese Daten wird normalerweise durch ein Datenbank Management System, abgekürzt DBMS bereitgestellt. Das DBMS ermöglicht Benutzern die Interaktion mit einer oder mehreren Datenbanken und den Zugriff auf die gespeicherten Daten. Aufgrund der engen Beziehung zwischen DBMS und Datenbank wird der Begriff „Datenbank“ häufig verwendet, um sich sowohl auf eine Datenbank als auch auf das DBMS zu beziehen, mit dem sie bearbeitet wird.

Funktionen des Datenbank Management Systems (DBMS)

Die vier Hauptfunktionen eines Datenbank Management Systems sind:

Datendefinition: Erstellen, Ändern und Entfernen von Definitionen, mit der die Organisation der Daten festgelegt wird

Update: Einfügen, Ändern und Löschen der Daten

Abruf: Bereitstellung von Informationen in einer direkt verwendbaren Form oder zur Weiterverarbeitung durch andere Anwendungen. Die abgerufenen Daten können in einer Form zur Verfügung gestellt werden, die im Wesentlichen dieselbe ist, wie sie in der Datenbank gespeichert ist, oder in einer neuen Form, die durch Ändern oder Kombinieren vorhandener Daten aus der Datenbank erzeugt wird.

Administration: Hierzu gehören die Registrierung und Überwachung von Benutzern, Durchsetzung der Datensicherheit, Überwachung der Leistung, Aufrechterhaltung der Datenintegrität, Handhabung der Parallelitätskontrolle und Wiederherstellung von Informationen, die durch ein Ereignis wie einen unerwarteten Systemfehler beschädigt wurden.

Arten von Datenbanksystemen

Ethernet

Die Benutzer eines Datenbanksystems müssen in der Lage sein, die darin enthaltenen Informationen jederzeit schnell zu manipulieren. Für große Unternehmen, die viele unabhängige Dateien mit verwandten und sich überschneidenden Daten aufbauen, ist häufig das Verknüpfen von Daten aus mehreren Dateien erforderlich. Zur Unterstützung unterschiedlicher Anforderungen wurden verschiedene Arten von DBMS entwickelt: flach, hierarchisch, verteilt, relational und objektorientiert.

Flache Datenbanken

In frühen Datenbanksystemen wurden die Daten sequenziell, das heißt alphabetisch, numerisch oder chronologisch gespeichert. Die Entwicklung von Speichermedien mit direktem Zugriff ermöglichte den wahlfreien Zugriff auf Daten über Indizes.

In flachen Datenbanken werden Datensätze nach einer einfachen Liste von Entitäten organisiert. Die Tabellen in diesen Datenbanken enthalten nur Daten und keine Verknüpfungen zu anderen Tabellen. Viele einfache Datenbanken für PCs sind flach aufgebaut.

Hierarchische Datenbanken

Die Datensätze in hierarchischen Datenbanken sind in einer baumartigen Struktur organisiert, wobei jede Datensatzebene in eine Reihe weiterer Kategorien verzweigt. Bei diesem Datenbanksystem wird die „Eltern-Kind-Beziehung“ zum Speichern von Daten verwendet.

Diese Art von Datenbanksystem wird heute nur selten verwendet. Die Struktur ähnelt einem Baum mit Knoten, die Datensätze darstellen, und Zweige, die Felder darstellen. Die Windows-Registrierung in Windows XP ist ein Beispiel für eine hierarchische Datenbank.

Verteilte Datenbanken

Hierbei handelt es sich um ein Datenbanksystem, in dem nicht alle Speichergeräte an einen gemeinsamen Prozessor angeschlossen sind. Eine verteilte Datenbank kann auf mehreren Computern gespeichert werden, die sich am selben physischen Ort befinden, oder über ein Netzwerk miteinander verbundener Computer verteilt sein. Im Gegensatz zu eng miteinander verbundenen Parallelsystemen, die ein einziges Datenbanksystem bilden, besteht ein verteiltes Datenbanksystem aus lose verbundenen Standorten, die keine physischen Komponenten gemeinsam nutzen.

Systemadministratoren können Datensammlungen an mehreren physischen Standorten verteilen. Eine verteilte Datenbank kann sich auf organisierten Netzwerkservern oder auf dezentralen unabhängigen Computern im Internet, in Intranets oder Extranets von Unternehmen oder in anderen Organisationsnetzwerken befinden. Da verteilte Datenbanksysteme Daten auf mehreren Computern speichern, können verteilte Datenbanken die Leistung an den Arbeitsplätzen der Endbenutzer verbessern.

Relationale Datenbanken

Eine relationale Datenbank basiert auf dem 1970 von E. F. Codd entwickelten relationalen Datenmodell. Im relationalen Datenmodell werden Daten in einer oder mehreren Tabellen, oder „Relationen“ aus Spalten und Zeilen organisiert. Jeder Zeile ist ein eindeutiger Schlüssel zugeordnet. Die Zeilen werden auch als Datensätze oder Tupel bezeichnet.

Die Spalten in einer relationalen Datenbank werden als Attribute bezeichnet. Im Allgemeinen stellt jede Tabelle / Relation einen „Entitätstyp“ dar, zum Beispiel einen Kunden oder ein Produkt. Die Zeilen repräsentieren Instanzen dieses Entitätstyps wie „Josef“ oder „Zündkerze“. Die Spalten repräsentieren Werte, die dieser Instanz zugeordnet sind – zum Beispiel die Adresse oder den Preis.

Ein Softwaresystem zum Verwalten relationaler Datenbanken ist ein relationales Datenbank Managenent System (RDBMS). Praktisch jede relationale Datenbank verwendet SQL (Structured Query Language) zur Abfrage und Pflege der Datenbank. Die bekanntesten relationalen Datenbanksysteme sind:

Oracle Database

Die Oracle Database Software, oft einfach als Oracle bezeichnet, ist ein Datenbankmanagementsystem mit mehreren Datenmodellen, das von der Oracle Corporation hergestellt und vermarktet wird.

MySQL

Dieses kostenlose Open Source-RDBMS, basiert auf Structured Query LanguageMySQL läuft auf praktisch allen Plattformen, einschließlich Linux, UNIX und Windows.

MariaDB

MariaDB ist ebenfalls ein Open Source RDBMS, das aus MySQL hervorgegangen ist.

Microsoft SQL Server

Microsoft SQL Server, kurz MS-SQL, ist ein kostenpflichtiges RDBMS, das eine Vielzahl von Transaktionsverarbeitungs-, Business Intelligence– und Analyseanwendungen in Unternehmens-IT-Umgebungen unterstützt. MS-SQL ist unter Windows und Linux Systemen verfügbar.

PostgreSQL

PostgreSQL, oft einfach Postgres, ist ein objektrelationales Datenbankverwaltungssystem (ORDBMS), das den Schwerpunkt auf Erweiterbarkeit und Einhaltung von Standards legt.

DB2

DB2 von IBM ist ein Datenbanksystem, das große Datenmengen effizient speichern, analysieren und abrufen kann.

Objektorientierte Datenbanken

DatenbankEine Objektdatenbank ist ein Datenbankverwaltungssystem, in dem Informationen in Form von Objekten gespeichert werden, wie sie in der objektorientierten Programmierung verwendet werden. Objektdatenbanken unterscheiden sich von relationalen Datenbanken, die tabellenorientiert sind. Objektrelationale Datenbanken sind eine Mischung aus beiden Ansätzen.

Objektorientierte Datenbankverwaltungssysteme (OODBMS), auch ODBMS (Object Database Management System) genannt, kombinieren Datenbankfunktionen mit objektorientierten Programmiersprachenfunktionen. OODBMS ermöglichen objektorientierten Programmierern, ein Produkt zu entwickeln, als Objekte zu speichern und vorhandene Objekte zu replizieren oder zu modifizieren, um neue Objekte in der OODBMS zu erstellen.

Da die Datenbank in die Programmiersprache integriert ist, kann der Programmierer die Konsistenz innerhalb einer Umgebung aufrechterhalten, indem sowohl das OODBMS als auch die Programmiersprache dasselbe Repräsentationsmodell verwenden. Im Gegensatz dazu sorgen relationale DBMS für eine klarere Trennung zwischen Datenbankmodell und Anwendung. Beispiele für objektorientierte Datenbanken sind IRIS von Hewlett Packard und ORION von Microelectronics.

NoSQL Datenbanken

Als NoSQL Datenbanken im Sinne von „No“ oder kein SQL wurden ursprünglich Datenbanksysteme bezeichnet, die keinen SQL Zugriff auf die Daten ermöglichten. Seit etwa 2009 wird NoSQL im Sinne von „Not Only “ SQL (Nicht nur SQL) verwendet.

NoSQLDatenbank Management Systeme verfügen im Allgemeinen über kein starr definiertes Schema, wie die in die Datenbankeingefügten Daten typisiert und zusammengesetzt werden müssen. NoSQL-Datenbanken können schema-agnostisch sein, wodurch unstrukturierte und halb strukturierte Daten gespeichert und bearbeitet werden können.

NoSQL-Datenbanken werden zunehmend in Big-Data– und Echtzeit-Webanwendungen verwendet. Beispiele von NoSQL-Datenbanken sind Oracle NoSQL DatabaseRedisRiak und MongoDBMongoBD ist eine relativ junge Datenbankentwicklung, die die besten Eigenschaften relationaler Datenbanken beibehält und gleichzeitig die Vorteile von NoSQL nutztMongoDB ist eine dokumentenorientierte NoSQL-Datenbank, mit der User Sammlungen von JSON-ähnlichen Dokumenten verwalten können.

Terminalserver

Ein Virtueller Server ist definiert als eine virtuelle Maschine (VM), die von einer speziellen Software auf einem physischen Server erstellt wird. Ein Virtueller Server nutzt die Ressourcen eines physischen Servers gemeinsam mit weiteren Virtuellen Servern. Die auch als VPS (Virtual Private Server) bezeichnete virtuelle Maschine stellt den Benutzern die gleichen Serverfunktionen wie ein dedizierter Server zur Verfügung.

Die Funktionsweise virtueller Server

Ein Virtueller Server ist eine Computerdatei, die meist als Image bezeichnet wird und sich wie ein realer Computer verhält. Die VM läuft wie jedes andere Programm in einem Fenster und bietet dem Endbenutzer auf einer virtuellen Maschine das gleiche Erlebnis wie auf einem physischen Server.

Die virtuelle Maschine ist vom Rest des Systems getrennt, was bedeutet, dass die Software in einer virtuellen Maschine den Computer selbst nicht manipulieren kann. Dies bietet eine ideale Umgebung zum Testen anderer Betriebssysteme oder den Zugriff auf vireninfizierte Daten. Virtuelle Server ermöglichen das Erstellen von Betriebssystemsicherungen und das Ausführen von Software oder Anwendungen auf Betriebssystemen, für die sie ursprünglich nicht vorgesehen waren.

Mehrere Virtuelle Server können gleichzeitig auf demselben physischen Computer ausgeführt werden. Bei Servern laufen die verschiedenen Betriebssysteme nebeneinander mit einer als Hypervisor bezeichneten Software. Desktop-Computer verwenden normalerweise ein Betriebssystem, um die anderen Betriebssysteme in ihren Programmfenstern auszuführen.

Jede virtuelle Maschine stellt ihre eigene virtuelle Hardware bereit, einschließlich CPUs, Arbeitsspeicher, Festplatten, Netzwerkschnittstellen und anderen Geräten. Die virtuelle Hardware wird dann der realen Hardware auf der physischen Maschine zugeordnet. Dies spart Kosten, da der Bedarf an physischen Hardwaresystemen zusammen mit den damit verbundenen Wartungskosten sowie der Strom- und Kühlungsbedarf reduziert wird.

Die Arten der Server-Virtualisierung

virtueller ServerEs gibt drei Möglichkeiten, virtuelle Server zu erstellen: vollständige VirtualisierungParavirtualisierung und Virtualisierung auf Betriebssystemebene. Sie alle haben einige gemeinsame Merkmale. Der physische Server wird als Host bezeichnet. Die virtuellen Server werden als Gäste bezeichnet. Die virtuellen Server verhalten sich wie physische Maschinen. Jedes System verwendet einen anderen Ansatz, um physische Serverressourcen den Anforderungen virtueller Server zuzuweisen.

Die vollständige Virtualisierung

Bei der vollständigen Virtualisierung wird eine spezielle Art von Software verwendet, die als Hypervisor bezeichnet wird. Der Hypervisor interagiert direkt mit der CPU und dem Festplattenspeicher des physischen Servers. Es dient als Plattform für die Betriebssysteme der virtuellen Server. Der Hypervisor hält jeden virtuellen Server vollständig unabhängig von den anderen virtuellen Servern, die auf dem physischen Computer ausgeführt werden. Jeder Gastserver läuft auf einem eigenen Betriebssystem – User können sogar einen Gast unter Linux und einen anderen unter Windows ausführen.

Der Hypervisor überwacht die Ressourcen des physischen Servers. Wenn virtuelle Server Anwendungen ausführen, leitet der Hypervisor Ressourcen von der physischen Maschine an den entsprechenden virtuellen Server weiter. Hypervisoren haben ihre eigenen Verarbeitungsanforderungen, was bedeutet, dass der physische Server Verarbeitungsleistung und Ressourcen für die Ausführung der Hypervisoranwendung reservieren muss. Dies kann die allgemeine Serverleistung beeinträchtigen und Anwendungen verlangsamen.

Die Paravirtualisierung

Im Gegensatz zur vollständigen Virtualisierungstechnik kennen sich die Gastserver in einem Paravirtualisierungssystem gegenseitig. Ein Para-Virtualisierungs-Hypervisor benötigt für die Verwaltung der Gastbetriebssysteme weniger Rechenleistung, da jedes Betriebssystem bereits die Anforderungen kennt, die die anderen Betriebssysteme an den physischen Server stellen. Das gesamte System arbeitet als zusammenhängende Einheit.

Die Virtualisierung auf Betriebssystemebene

Bei einem Virtualisierungsansatz auf Betriebssystemebene wird kein Hypervisor verwendet. Stattdessen ist die Virtualisierungsfunktion Teil des Host-Betriebssystems, das alle Funktionen eines vollständig virtualisierten Hypervisors ausführt.

Die größte Einschränkung dieses Ansatzes besteht darin, dass auf allen Gastservern dasselbe Betriebssystem ausgeführt werden muss. Jeder virtuelle Server bleibt zwar unabhängig von allen anderen, Nutzer können jedoch keine Betriebssysteme miteinander kombinieren. Da alle Gastbetriebssysteme gleich sein müssen, spricht man von einer homogenen Umgebung.

Weitere Artikel im Blog der Biteno GmbH zum Thema Server und Virtualisierung

Anwendung virtueller Server

TerminalserverVirtuelle Server werden zum Betrieb einer Website oder eines Onlineshops genutzt, sind aber nicht auf diese Anwendungen beschränkt. Datenbank- und E-Mail-ServicesWebapplikationen und Groupware-Services sind ebenfalls Einsatzgebiete der VPS. Im Cloud-Computing ermöglichen sie eine schnelle Skalierung bei einem erhöhten Ressourcenbedarf und die nutzungsabhängige Abrechnung der in Anspruch genommenen Hardware-Ressource.

Vor- und Nachteile virtueller Server

Durch die Verwendung virtueller Server ergeben sich verschiedene Vorteile. Die Hardware-Ressourcen werden vollständig genutzt. Durch die Verwendung der Virtualisierung werden Server in mehrere virtuelle Server aufgeteilt, von denen jeder unabhängig ist und unterschiedliche Betriebssysteme für verschiedene Anwendungen installiert.

Untersuchungen haben gezeigt, dass es kostengünstiger ist, wenige, gut ausgelastete Server zu betreiben und zu managen als viele Server, die im Durchschnitt zu weniger als 15 % ausgelastet sind. Die Servervirtualisierung ermöglicht es, Server zu konsolidieren und so die vorhandene Hardware besser zu nutzen.

Die Betriebskosten werden reduziert. Nach der Integration der Virtualisierungsplattform führt diese Technologie zu erheblichen Einsparungen, einschließlich des Server-Energieverbrauchs, des Platzbedarfs und des Energieverbrauchs der Klimaanlagen. Gleichzeitig sinkt die Anzahl der physischen Server, was die Wartung und den Betrieb des gesamten Hardwaresystems einfacher macht.

Verbesserte Sicherheit

Virtuelle Server führen zu einer Verbesserung der Sicherheit des Gesamtsystems. Ohne zusätzliche Investitionen in Hardware kann die virtuelle Plattform einige Anwendungsmodi wie Lastausgleich und Hot-Standby-System bereitstellen. Dadurch steigt die Sicherheit und Kontinuität aller Anwendungssysteme in erheblichem Maße.

Virtuelle Server verbessern die Systemflexibilität. Je nach den unterschiedlichen Anforderungen von Anwendungssystemen können Administratoren mithilfe der Virtualisierungsserverplattform den Ressourcenzustand des virtuellen Servers anpassen.

Ein virtueller Server kann die Migration zwischen physischen Servern innerhalb weniger Sekunden durchführen, und die Anwendung wird nicht unterbrochen. Der Vorteil der Virtualisierungsplattform ist unabhängig von physischer Hardware.

Kontinuität der Anwendung

Unabhängig davon, ob der Server beschädigt ist oder zur Wartung ausfällt, kann der virtuelle Server dynamisch verschoben werden, um die Kontinuität der Anwendung zu gewährleisten. Cloud-Anbieter wie Google Cloud oder Amazon Web Services nutzen diesen Vorteil und migrieren den VPS bei Hardwareproblemen auf einen anderen physikalischen Server. Das bedeutet, dass die VM in der Regel nur für kurze Zeit nicht erreichbar ist. Im Gegensatz dazu kann ein dedizierter Server bei Hardwaredefekten gegebenenfalls für mehrere Stunden ausfallen.

Durch den gleichzeitigen Betrieb mehrerer Virtueller Server auf einem physischen Server kann es bei einer hohen Auslastung jeder virtuellen Maschine zu einer instabilen Leistung der einzeln Server kommen. Generell sind Virtuelle Server beim Zugriff auf die Hardware nicht so effizient wie ein physischer Server.

Daher kann es zu kleinen Leistungseinbußen kommen, wenn mehrere Virtuelle Server versuchen, gleichzeitig auf die Ressourcen des physischen Servers zuzugreifen. Wird der Basisserver neu gestartet, müssen alle auf diesem Server laufende VM ebenfalls neu gestartet werden. Dies ist jedoch nur selten erforderlich, das die VPS vorher auf andere Server verschoben werden können.

Active Directory an Office 365 anbinden

Immer mehr Firmen nutzen auf Basis von Microsoft Azure den Cloud Service Microsoft Office 365. Dabei wird neben dem klassischen Office Produkt (bspw. Office 2016) jedem lizenzierten Benutzer ein Postfach auf Basis von Microsoft Exchange zur Verfügung gestellt. Das ist insofern praktisch, da es auch kleinen Unternehmen mit wenigen Postfächern ermöglicht Microsoft Exchange in Anspruch zu nehmen.

Neben Office 365 haben die meisten Firmen aber nach wie vor lokale Windows-Installationen in Betrieb, für die sie ein Active Directory zur Verwaltung der Benutzer und deren Rechte einsetzen. Der IT-Administrator steht anschließend vor der Aufgabe, daß an zwei Stellen Benutzer verwaltet werden müssen: Einmal im lokalen Active Directory und ein zweites Mal innerhalb des Office 365 Mandanten (engl. Tenant). Das ist insofern unschön, da jeder Benutzer dann einmal im Active Directory als auch in Office 365 gepflegt und verwaltet werden muss.

Microsoft Azure Directory Connect (bzw. Azure Directory Sync) löst dieses Problem, in dem das lokale Active Directory des Unternehmens mit dem Mandanten von Office 365 so verbunden wird, daß die angelegten Benutzer weiterhin nur an einer Stelle verwaltet werden müssen.

Voraussetzungen für den Directory Sync mit Azure

Damit die Synchronisation zwischen Active Directory und Office365 einwandfrei funktioniert, müssen einige Voraussetzungen erfüllt sein:

  • Eigentlich selbstverständlich: Ein Office 365 Mandant muss für die Firma angelegt und vorhanden sein.
  • Die Installation der Synchronisations-Software selbst muss auf einem Member Server innerhalb des Active Directory erfolgen. Die Installation auf einem Domain Controller ist zwar prinzipiell möglich wird aber nicht empfohlen.
  • Der Server auf dem Azure Directory Sync installiert wird, muss ein 64-bit Betriebssystem haben(Windows 2008 R2, Windows Server 2012 oder 2016)
  • Auf dem Server sollten min 70 GB Platz vorhanden sein. Als Mindestanforderung für den Hauptspeicher gibt Microsoft 4 GB RAM an.
  • Ein administrativer (d.h. privilegierter) Account im lokalen Active Directory
  • Ein administrativer Account im Office 365 Tenant (Mandant) bei Microsoft Azure

Eine gern übersehene Voraussetzung für die  erfolgreiche Verbindung zur Office 365 ist, daß die interne Domain des Active Directory (im Internet) routing-fähig ist.

In anderen Worten: keine domain.local oder .intra sondern „domain.com“ oder „domain.de“. Sofern Sie eine (bereits seit Jahre) bestehende interne Domain in ihrem AD haben, die auf eine nicht routing-fähige Endung hört (bspw. *.local), so kann mit einem so genannten Benutzerprinzipalname-Suffix dieser „Fehler“ behoben werden. Mehr dazu am Ende.

Hinweis: Was mit Azure AD Sync nicht geht

Der Wunsch manches Firmenchefs oder IT-Verantwortlichen zum Trotz: Das kostenfreie Verzeichnis von Benutzern bei Office 365 ersetzt nicht ein echtes Active-Directory im eigenen Rechenzentrum bzw. in den Räumen des eigenen Unternehmens. Mit dem reinen Office 365 kann man also keine lokalen Benutzer am heimischen PC authentifizieren.

Wer also den Wunsch nach einer vereinfachten Verwaltung von Computern und Ressourcen im Unternehmens-eigenen Windows Netz hat, der kommt auch weiterhin nicht um ein funktionierendes Active Directory herum.

Übrigens: Der Active Directory Sync muss schon aus Firewall-Gründen ein Push Mechanismus sein, der also vom bestehenden AD aus eine Synchronisation zu Office 365 hin anstößt. Wollte man aus Office 365 heraus einen Sync betreiben (was aber eben nicht geht), so müsste die Firewall des Unternehmens „aufgebohrt“ werden. Das ist aber in 99% aller Fälle weder gewollt noch sinnvoll.

Klappt der Sync denn auch?

Um bei der ersten – hoffentlich erfolgreichen Synchronisation direkt in Office 365 prüfen zu können, ob der Abgleich der Konto einwandfrei funktioniert, haben wir in unserem Active Directory einen Test-Benutzer angelegt, für den es in unserem Office 365 Mandanten noch kein Konto gibt.

In unserem Beispiel habe ich den Anwender „Peter Testmann“ angelegt und ihm ein Passwort vergeben.

Wichtig dabei. Das Feld E-Mail sollte ausgefüllt sein. Es wird später für die Synchronisation und eindeutige Zuordnung benötigt.

Installation von Azure Directory Sync

Nach dem wir nun alle Voraussetzungen geprüft haben und die Kontodaten der beiden notwendigen Accounts (einmal Office365 und einmal Admin aus dem lokalen Active Directory) beisammen haben, können wir auch loslegen.

Das Azure Directory Sync Tool kennt bei zwei Installationsarten:

  • Express und
  • Benutzerdefiniert mit angepassten Einstellungen

Die Express-Installation des Sync-Tools erfragt im wesentlichen „nur“ die Zugangsdaten der beiden Accounts für Office 365 und das lokale AD. Wer mehr Kontrolle über die Einrichtung und die Definition der Synchronisation haben möchte, sollte unbedingt die angepasste Einrichtung wählen. Im nachfolgenden beschreibe ich die benutzer-definierte Installation des Tools.

Starten der Installatoin von Azure Directory Sync

Starten der Azure AD Installation

Starten der Azure AD Installation

Zunächst laden wir das Programmpaket für den Directory Sync herunter:

https://www.microsoft.com/en-us/download/details.aspx?id=47594

Die Installation starten Sie als Administrator mit einem Doppelklick, akzeptieren die Lizenzbedingungen und klicken anschließend unten rechts auf „Weiter“.

 

 

Erforderliche Komponenten für Azure Directory Sync

Die erforderlichen Bestandteile des AC Sync

Die erforderlichen Bestandteile des AC Sync

In der nächsten Maske, können Sie folgende Dinge ändern:

– anderer Installationsort (Default: „C:\Program Files\Microsoft Azure AD Sync“)

– ein bestehender SQL Server (sonst wir ein SQL Express installiert)

– bestehender Account in der AD

– benutzerdefinierte Synchronisierungsgruppen Gruppen (statt Administratoren, Benutzer etc.)

 

Sofern Sie eine der Optionen anpassen möchten, setzen Sie den entsprechenden Haken.

Anschließend klicken Sie unten rechts auf „Installieren“.

 

Azure Sync: Benutzeranmeldung

Die Optionen für „Benutzeranmeldung“ steuert, wie im zukünftigen Sync die Passwörter synchronisiert werden.

Standardmäßig ist die „Kennworthashsynchronisierung“ ausgewählt. Dabei werden die verschlüsselten Hash-Werte der Passwörter vom lokalen AD nach Office 365 übertragen – umgekehrt allerdings nicht.

Für die meisten Anwendungsfälle wird dies allerdings vollkommen ausreichen.

Wer seinen Anwendern die Möglichkeit eines Single-Sign-On (SSO) zur Verfügung stellen möchte, der setzt ganz unten den Haken bei „Einmaliges Anmelden aktivieren“.

Anschließend klicken Sie wieder unten rechts auf „Weiter“.

Sync: Mit Azure AD verbinden

In der nächsten Maske geben Sie die Zugangsdaten eines administrativen Benutzers ihres Office 365 Mandanten an.

Bspw.: admin@<ihr-mandant>.onmicrosoft.com

Bei „Kennwort“ tragen Sie das Passwort ein.

 

Azure Sync: Verzeichnisse verbinden

Azure mit dem lokalen active Directory verbinden

Sofern Ihr Kennwort richtig war, erscheint nun die folgende Übersicht:

Als Verzeichnistyp sollte „Active Directory“ ausgewählt sein.

Darunter können Sie im Dropdown „Gesamtstruktur“ das Verzeichnis auswählen, das Sie synchronisieren möchten.

Klicken Sie dazu auf den günen Button „Verzeichnis hinzufügen“.

 

 

 

Danach sollte die Maske so aussehen:

Klicken Sie nun wieder unten rechts auf „Weiter“.

 

 

 

AD-Gesamtstrutkturkonto in der lokalen Domain

In der Übersicht „AD-Gesamtstrukturkonto“ werden Sie nun nach dem weiter oben erwähnten administrativen Account aus ihrem Active-Directory gefragt.

Dabei können Sie wählen ob für die Synchronisation ein neues Konto in ihrem AD angelegt wird oder ob Sie einen bestehenden Account (AD-Konto) nutzen möchten.

Ich empfehle hier das Programm ein neues AD-Konto anlegen zu lassen. Das dann angelegte Konto sollte wirklich nur zum Zweck der Synchronisierung verwendet werden.

Achtung: Um ein Konto durch das Sync-Tool anlegen zu lassen, müssen Sie um Feld „Benutzername des Unternehmensadministrators“ den Namen des Admin-Kontos in der Form „DOMAIN\Benutzer“ angeben. Das darunter liegende Feld für das Passwort war in unserem Fall mit der Maus nicht zu erreichen. Nur mittels TAB und „blindem“ Eingeben klappte es dann doch. – Klicken Sie anschließend auf „OK“.

Azure AD-Anmeldekonfiguration

In der nun folgenden Maske „Azure AD-Anmeldungskonfiguration“ legen Sie fest, welches Feld aus ihrem Active-Directory genutzt wird, um sicher zu stellen, dass Benutzer eindeutig sind.

Gemeint ist hier der so genannte „User Principal Name“ (kurz UPN). Sie sollten diesen den Wert auf „userPrincipalName“ belassen.

Damit ist die Langform der Anmeldung in der Form benutzer@domain.tld (also etwa: mark.testmann@beispiel.de“ gemeint

Wichtig: Setzen Sie hier bitte den Haken unten bei „Ohne Abgleich aller UPN-Suffixe …“ und klicken anschließend auf „Weiter“.

 

 

Azure Sync: Filtern von Domänen und Organisationseinheiten

In der Maske „Filtern von Domänen und Organisationseinheiten“ können Sie detailliert festlegen, was Sie genau synchronisiert haben wollen.

Es empfiehlt sich in jedem Fall die Benutzer (Users) zu synchronisieren. Ob Sie weitere Elemente synchronisieren möchten, muss jeweils in Ihrem Anwendungsfall entschieden werden.

Klicken Sie nach dem Anhaken der für Sie passenden Kreuze unten rechts auf „Weiter“.

 

 

Active Directory Sync: Ihre Benutzer werden eindeutig identifiziert

In der nun folgenden Maske „Ihre Benutzer werden eindeutig identifiziert“ können Sie vom Standard abweichende Einstellungen angeben, wo und wie das Sync-Tool sicherstellt, dass die Zuordnung von AD-Benutzern zu Office 365 Accounts korrekt erfolgt.

Sofern Sie ihre AD-Benutzer nur einmal angelegt haben, sollten Sie die Einstellungen im Standard so belassen:

Oben: „Benutzer werden nur ein Mail in allen Verzeichnissen dargestellt“.

Unten: „..Quellanker durch Azure verwalten lassen“.

Sofern Sie davon abweichen sollten Sie sowohl oben (im AD) und unten (in Office 365) einen Feld mit möglichst identischem Inhalt wählen – etwa die E-Mail Adresse (da diese immer eindeutig sein muss).Klicken Sie anschließend wieder unten rechts auf „Weiter“.

 

Directory Sync: Benutzer und Geräte filtern

In der Maske „Benutzer und Geräte filtern“ können Sie entscheiden ob Sie ein Alle Benutzer ihres Active Directory synchronisieren lassen möchten, oder ob Sie eine bestimmte Organisationseinheit (engl. OU) innerhalb ihres Directory auswählen.

Wenn Sie etwa mit Subdomains arbeiten, so können Sie hier die für ihren Anwendungsfall passende OU auswählen.

Klicken Sie anschließend wieder auf Weiter.

 

Azure Sync: Optionale Features

In der vorletzten Eingabemöglichkeit „Optionale Features“ können Sie folgende Einstellungen vornehmen:

Anpassungen zur Synchronisierung von Microsoft-Exchange und öffentlichen Ordnern von MS-Exchange.

Hinweis: Diese Option erscheint nur, wenn Sie vorher bereits einen Exchange Server in ihrem Active Directory in Betrieb haben.

Sofern Sie weiter oben die Standard-Option „Kennworthashsynchronisierung“ aktiviert haben, ist diese bereits angekreuzt und ausgegraut.

Klicken Sie nun noch einmal unten rechts auf Weiter.

 

Azure Active Directory Sync: Bereit zur Konfiguration

Herzlichen Glückwunsch: Sie sind nach diesem Options-Marathon auf der finalen Maske angelangt.

Sofern Sie den Haken bei „Starten Sie den Sychronisierungsvorgang, nach dem die Konfiguration abgeschlossen wurde“ gesetzt lassen, wird direkt nach der Installation des Tools der erste Abgleich zwischen dem Active Directory und ihrem Office 365 Mandanten erfolgen.

 

Klicken Sie (diesmal wirklich zum letzten Mal) unten rechts auf den grünen Button „Installieren“.

 

Sie erhalten die allerletzte Maske als Bestätigung, was nun synchronisiert wird.

Klicken Sie unten rechts auf „Beenden“.

 

 

 

 

 

Klappt die Synchronisation mit Azure Active Directory Sync?

Wenn nun alles richtig funktioniert hat, dann sollten wir den eingangs angelegten Testbenutzer „Peter Testmann“ in Office 365 wieder finden.

Um das zu prüfen loggen Sie sich mit einem administrativen Benutzer unter https://portal.office.com ein und klicken dort anschließend auf => Admin => Users => Active Users

Im Screenshot können Sie erkennen, dass „Peter Testmann“ erfolgreich angelegt wurde.

Melden Sie sich nun wieder von Office 365 ab. Anschließend melden Sie sich direkt wieder unter https://portal.office.com an. Diesmal nutzen Sie allerdings die Zugangsdaten ihres Testbenutzers aus dem lokalen Directory ihres Unternehmens.

Sie sollten sich nun mit dem Benutzernamen und dessen Passwort aus dem lokalen Active-Directory bei Office 365 anmelden können.

Troubleshooting und FAQ

Frage: Meine interne Active Directory Domain  hat eine Endung die im Internet nicht routing-fähig ist (z.B. domain.local) . Wie kann ich trotzdem meine bestehende Domain mit Office 365 verwenden?

Antwort: Sie müssen vor der Installation des Directory Sync ein zusätzliches Benutzerprinzipalnamen-Suffix (zu Deutsch: Domain-Endung) für ihre Domain anlegen.

Das geht so:

Auf einem Domain Controller ihrer internen AD öffnen Sie die Management-Konsole für Active Directory Domänen und Vertrauensstellungen. Im obersten Ast (oberhalb ihrer Domain) klicken Sie mit der rechten Maustaste auf „Active Directory-Domänen und –Vertrauensstellungen“ und dann auf Eigenschaften. Fügen Sie nun im Feld „Alternative Benutzerprinzipalnamen-Suffixe“ eine Routing-fähige Endung hinzu.

Bsp.: Wenn ihre bisherige AD-Domain „domain.local“ heißt, dann gehen Sie hier „domain.com“ oder „domain.de“ ein –also alles nach dem @ . Speichern Sie die Veränderungen mit „OK“ ab.

Bei der Anlage bzw. Bearbeitung eines Benutzerkontos können Sie anschließend statt der Endung @domain.local auch die gerade eingegebene Domain-Endung auswählen, die dann später bei Office 365 zur Anmeldung verwendet werden kann.

Wählen Sie dazu rechts neben dem Feld „Benutzeranmeldename“ die gewünschte Domain-Endung aus. Im Beispiel rechts wurden zwei zusätzliche Domain-Endungen vergeben.

Fazit:

Trotz des etwas länglichen Installations-Dialog bei der ersten Einrichtung von Azure Active Directory Sync kann man ein bestehendes Active Directory relativ einfach an Office 365 anbinden. Auf diese Weise erspart man sich die doppelte Administration der Benutzer (und ihrer Passwörter)  und kann so das vorhandene Directory komfortable zur Benutzer-Administration in beiden Welten verwenden.

Quellen:

Links

https://docs.microsoft.com/de-de/azure/active-directory/connect/active-directory-aadconnect-get-started-custom

Bücher:

Das über 1000 Seiten dicke Buch „Microsoft Office 365 – das umfassende Handbuch“ ist Nachschlagewerk und Einführung in einem.

https://www.amazon.de/Microsoft-Office-365-Administratoren-Deutschland/dp/383624473X/ref=pd_lpo_sbs_14_t_0?_encoding=UTF8&psc=1&refRID=AXJX91RQWZAXF5MWKBNJ

 

 

Einleitung: Hochverfügbarer Samba-Server

Je größer eine Firma bzw. deren Infrastruktur wird, desto unwahrscheinlicher ist es, daß man einen einzelnen Host im laufenden Betrieb updaten oder gar herunter fahren kann. Für den sicheren Systembetrieb ist es aber wesentlich, daß aktive Komponenten regelmässig gewartet bzw. aktualisiert werden können. Im Zuge von Updates und Wartung ist sehr häufig ein Reboot des betroffnene Servers notwendig. Leider geht mit Reboots einher, dass Anwender nicht auf die IT-Dienste des Servers zugreifen können.

In diesem Tutorial werden wir einen Ausfallsicherer Samba-Server mit LVM, Gluster-FS sowie Pacemaker/Corosync einrichten und konfigurieren.

Konzeptioneller Ansatz

Um selbstverständliche Dienste wie Windows-Freigaben (etwa für Team-Laufwerke oder andere Shares) ausfallsicher und mit hoher Verfügbarkeit zu gestalten, braucht es an sich nur 3-4 wesentliche Komponenten:

  • 2 identische Hosts
  • Ein oder mehrere gespiegelte Dateisysteme sowie einen Mechanismus zur Synchronisierung der Daten
  • LVM zur nahtlosen Erweiterung des Storage-Bereichs
  • 100%-ige Erreichbarkeit eines der beiden Hosts über eine Cluster-IP-Adresse
  • Samba für die Freigabe(n)

Wirklich wichtig für die nahezu 100-prozentige Verfügbarkeit ist, daß die beiden Hosts sich praktisch nichts teilen, was immer online sein muss.

Beispiel: Wenn wir das File-System mit den Freigaben auf eine zentrale Storage (Storage-SAN oder NAS) legen würden, so hätten wir einen Teil des Systems nur einmal vorrätig, so daß beim Fehlen dieses Bestandteils das Gesamt-System nicht mehr funktionieren würde. Das zentrale Storage wäre ein großer (und meist teurer) „Single Point of Failure“ (SPoF)

Daher: Die beiden Hosts werden also als exakte Klone voneinander betrachtet. Sie teilen sich nichts – zumindest nichts physisches. Dieses Prinzip des „shared nothing“ erreichen wir durch den Einsatz der Opensource-Software Gluster-FS, das das Dateisystem spiegelt.

Die einzige Ressource die entweder auf dem einen oder dem anderen Host vorhanden ist, ist die Cluster-IP (oder Service-IP) die mit Pacemaker/Corosync immer auf einem aktiven Host vorhanden ist und sich im Ernstfall binnen Sekunden auf den jeweils anderen Host übertragen läßt

Um das Dateisystem der beiden Hosts später auch im laufenden Betrieb erweitern zu können, legen wir die Partition mit den Dateien mittels LVM (logical volume manager) unter Linux an.

Voraussetzungen

Für alles Folgende setzen wir zwei identische (virtuelle) Server mit CentOS7 voraus. Diese sollten in etwa die gleichen Ressourcen in Bezug auf RAM und CPU haben. In Sachen Festplatten bzw. Partitionen sollten die beiden Hosts identisch sein. Dabei spielt es keine wirkliche Rolle ob die Linux-Hosts physische Server oder wie in unserem Fall virtuelle Server sind.

Für unser Beispiel nehmen wir an, daß die Linux-Server folgendermaßen heißen:

1
2
3
4
5
10.51.137.245   gstest01.itsc.local     gstest01

10.51.137.246 gstest02.itsc.local     gstest02

10.51.137.247 fileserver.itsc.local    fileserver

Diese drei  Zeilen kommen in die /etc/hosts Datei.

Vorbereiten der Partitionen

Wir bereiten also 2 identische Hosts mit Minimal-Installation unter Centos 7 jeweils auf /dev/sda vor. Außerdem brauchen die Hosts ein zweites File-system /dev/sdb das in etwa identisch groß sein sollte

Im ersten Schritt legen wir mit „parted“ und „fdisk“

Schritt 1: Mit Parted und fdisk Partition anlegen:

1
2
parted /dev/sdb
mklabel -> gpt

Anschließend legen wir eine Partition /dev/sdb1 unter /dev/sdb an und wählen als Partitionstyp “LVM”.

1
2
fdisk /dev/sdb
fdisk -&gt; partition anlegen und Typ 31 auswählen

Schritt 2: Volume Group und LVM anlegen

Wir legen nun zuerst ein „physical volume“ und anschließend eine Volume Group unter LVM an.

Mit dem folgenden Schritt erstellen wir auf der Partition /dev/sdb1 eine Volume Group mit Namen „storagevg“

1
vgcreate storagevg /dev/sdb1

Schritt 3: Das eigentliche Logical Volume anlegen

1
lvcreate --name storage01 --size 198G storagevg

Der obige Befehl legt auf der Volume Group “storagevg“ das logische Volume „storage01“ mit 198 GB Speicher an.

Schritt 4: Formatieren und Einbinden des LVM

Unser frisch erstelltest LV heißt nun also „/dev/storagevg/storage01“. Auf diesem erstellen wir nun ein XFS_Dateisystem:

1
mkfs.xfs /dev/storagevg/storage01

Damit wir das Filesystem später auch nutzen können, legen wir den Mountpoint bzw. das Verzeichnis „/data“ an und mounten das LVM anschließend.

1
2
3
mkdir /data

mount /dev/storagevg/storage01 /data

 

Damit das Filesystem auch nach dem nächsten Reboot wieder unter /data eingeängt wird, tragen wir folgenden Zeile in der /etc/fstab ein.

1
/dev/storagevg/storage01 /data xfs defaults 0 0

Installation von glusterfs unter CentOS 7

Damit wir später unsere identischen Partitionen auch synchron halten können, benötigen wir ein Gluster-Filesystem. Dafür installieren wir die folgenden Pakete unter Centos:

1
2
3
yum -y install epel-release yum-priorities centos-release-gluster

yum -y install glusterfs-server

 

Anschließend aktvieren wir den Dienst und starten ihn

1
2
3
systemctl enable glusterd.service

systemctl start glusterd.service

Zur Sicherheit schauen wir uns den Status an

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
[root@gstest01 ~]# glusterfsd --version

glusterfs 3.12.9

#

# status prüfen

[root@gstest01 ~]# gluster peer probe gstest02

peer probe: success.

# Status teil 2

[root@gstest01 ~]# gluster peer status

Number of Peers: 1

Hostname: gstest02

Uuid: b8fb70b5-fa46-4b11-aaf7-c5697ca3d6da

State: Peer in Cluster (Connected)

Gluster-FS Volume erstellen

MIt dem folgenden Befehl erstellen wir nun ein Dateisystem “storage01” innerhalb von Gluster-FS, dass auf den Hosts gstest01 und gestest02 jeweils physisch unter /data liegt. Der Parameter „replica 2“ bedeutet, dass wir faktisch eine Spiegelung erstellen.

1
2
3
[root@gstest01 ~]# gluster volume create storage01 replica 2 transport tcp gstest01.itsc.local:/data gstest02.itsc.local:/data force

volume create: storage01: success: please start the volume to access data

Das eigentliche Volume unter Gluster-FS muss nun noch auf einem (!) der beiden Hosts gestartet werden. Das erledigt der Befehl:

1
2
3
4
5
6
7
#gluster volume start <volume-name>

&nbsp;

[root@gstest01 ~]# gluster volume start storage01

volume start: testvol: success

[root@gstest01 ~]#

Glusterfs client installieren und mounten

Damit das gerade erstellte Gluster-Filesystem auch nutzbar wird, muss es auf beiden Hosts auch gemountet werden.

Hinweis: Bei der Installation des Gluster-FS- Servers ist der Gluster-FS client bereits mit enthalten.

1
yum -y install glusterfs-client

Anschließend legen wir ebenfalls auf beiden Hosts das Verzeichnis “/datastore” als Mountpoint an:

1
mkdir /datastore

Nun können wir das angelegte synchronisierte Verzeichnis /datastore auf jedem der Hosts mounten:

1
mount.glusterfs gstest01:/storage01 /datastore

 

Damit der Mount auch wieder nach einem Reboot da ist, nehmen wir den Befehl in die /etc/rc.d/rc.local auf.

1
2
3
4
5
6
7
vi /etc/rc.d/rc.local

#einfügen: /usr/sbin/mount.glusterfs gstest01:/storage01 /datastore

chmod +x /etc/rc.d/rc.local

systemctl enable rc-local

Achtung wichtig: Bitte achten Sie unbedingt darauf, daß jeder Host das „eigene“ FileSystem mounted.

Also auf host „gstest01“:

1
/usr/sbin/mount.glusterfs gstest01:/storage01 /datastore

… und auf dem Host „gstest02“

1
/usr/sbin/mount.glusterfs gstest02:/storage01 /datastore

Zur Sicherheit rebooten wir nacheinander jeden Host einmal. Wenn danach das File-System und der gluster service wieder online sind, dann haben wir erfolgreich ein synchrones Filesystem mit Gluster-FS erstellt

Beim Wechsel  bzw. Reboot kommt nun noch ein etwas nerviger Timeout . Während dieser Zeit kommt der verbliebene Host nicht wirklich schnell in die Puschen. Dies kann allerdings mit einem einfachen Einstellen des Timeouts von Gluster-FS erledigt werden.

1
2
3
gluster volume info storage01

gluster volume set storage01 network.ping-timeout 10

Gluster-FileSystem testen

Wenn Sie nun das Gluster-Filesystem testen möchten, so legen Sie auf dem Host gstest01 im Verzeichnis /datastore eine Datei an. Diese sollte nach wenigen Augenblicken auf gstest02:/datastore auftauchen. Änderungen die Sie nun auf gstest02:/datastore an der Datei vornehmen, werden wiederum sofort nach gstest01:/datastore übertragen.

 

Ausfallsicherheit mit Corosync und pacemaker:

Damit wir von Clients nun noch permanent auf Samba zugreifen können, benötigen wir eine dritte, virtuelle IP-Adresse. Über diese IP bzw. den dazu passenden DNS-Namen greifen später die Benutzer auf das hoch verfügbare Samba-Verzeichnis zu. Dafür erstellen wir mit Corosync und Pacemaker folgende Konfiguration.

Wie auch für Gluster-FS sollten die beiden Hostnamen und IP-Adressen in der jeweiligen /etc/hosts auf beiden Nodes enthalten sein. Das können wir an dieser Stelle überspringen, da wir das schon weiter oben erledigt haben.

Schritt 1: Installation von Corosync und Pacemaker / pcs

Auf beiden Hosts installieren wir nun noch Pacemaker und Corosync:

1
2
3
yum  -y install pacemaker pcs
systemctl enable pcsd.service
systemctl start pcsd.service

Während der Installation  wird ein neuer User namens „hacluster“ angelegt: Diesem geben wir ein Passwort und merken es uns gut. Am besten gleich in die IT-Dokumentation schreiben….

1
passwd hacluster

(auf beiden Hosts – jeweils identisches Passwort…)

Schritt 2: Einrichtung von  Pacemaker

Hinweis: Der nachfolgende Linux-Befehl ist nur auf einem der beiden Knoten notwendig. Dazu geben Sie das Passwort des Benutzers „hacluster“ von weiter oben ein

[root@gstest01 ~]# pcs cluster auth gstest01 gstest02

1
2
3
4
5
pcs cluster auth gstest01 gstest02
Username: hacluster
Password:
gstest02: Authorized
gstest01: Authorized

 

1
2
3
4
[root@gstest01]# pcs cluster setup --name cluster01 gstest01 gstest02
Destroying cluster on nodes: gstest01, gstest02...
gstest01: Success
gstest02: Success

Schritt 3: Pacemaker Cluster starten

Als letzten Schritt starten wir nun das Pacemaker Cluster. Auch dies wird nur auf einem der beiden Server erledigt:

1
2
3
[root@gstest01 ~]# pcs cluster start --all
gstest02: Starting Cluster...
gstest01: Starting Cluster...

Schritt 4: Corosync und Pacemaker aktivieren

Damit die Dienste auch nach einem Reboot wieder starten, aktivieren wir sie mit systemctl:

1
2
systemctl enable corosync.service
systemctl enable pacemaker.service

Schritt 5: Stonith und Quorum deaktivieren

Ein Cluster-Quorum und Stonith machen in der Regel erst ab 3 Hosts Sinn. Für unser 2-Server Setup sind sie nicht hilfreich. Daher deaktivieren wir sie:

1
2
pcs property set stonith-enabled=false
pcs property set no-quorum-policy=ignore

 

Schritt 6: Virtuelle Service IP einrichten

Mit dem folgenden Befehl wird die Service-IP-Adresse für das Cluster angelegt. Die Ressource heißt hier “samba-ip” und hat die Adresse 10.51.137.247 (mit der Netzmaske 255.255.254.0)

1
pcs resource create samba-ip ocf:heartbeat:IPaddr2 ip=10.51.137.247 cidr_netmask=23 op monitor interval=5s

Schritt 7: Testen und Reboot

Mit “pcs status” können Sie jederzeit auf beiden Hosts ermitteln, wo die Service-IP-Adresse gerade läuft:

pcs status

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
[root@gestest01 ~]# pcs status
Cluster name: cluster
Stack: corosync
Current DC: gstest02 (version 1.1.18-11.el7_5.3-2b07d5c5a9) - partition with quorum
Last updated: Tue Jul 10 16:49:05 2018
Last change: Tue Jul 10 12:56:42 2018 by root via crm_resource on gstest01
2 nodes configured
1 resource configured
Online: [gstest01 gstest02]

Full list of resources:
samba-ip    (ocf::heartbeat:IPaddr2):       Started - gstest02

Daemon Status:
corosync: active/enabled
pacemaker: active/enabled
pcsd: active/enabled

Um die Funktion der Cluster-IP-Adresse zu testen, rebooten wir nun den Server, auf dem die aktuelle Cluster-IP sich gerade befindet. Wenn alles richtig konfiguriert wurde, so wird beim Shutdown des aktiven Servers die Service/Cluster-IP automatisch von Pacemaker und Corosync auf den zweiten Host übertragen. Testen können Sie das mit einem „ping“ von einem Windows-Host auf die Cluster-IP:

1
ping –t 10.51.137.247

Installation von Samba

Zu guter Letzt installieren wir noch auf beiden Servern Samba als Dienst.

1
yum  -y install samba samba-client samba-common

Die  Datei /etc/samba/smb.conf passen Sie nun noch an Ihre Bedürfnisse an.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
[global]
workgroup = WORKGROUP
security = user
guest account = nobody
map to guest = bad user
passdb backend = tdbsam
#load printers = yes
cups options = raw

[datastore]
path = /datastore
guest ok = yes
guest only = yes
guest account = nobody
browseable = yes

Wie man für Samba die Datei /etc/samba/smb.conf so anpasst, daß sie mit personalisierten Benutzern zugreifen können, beschreiben wir in einem weiteren Tutorial hier im Blog.

 

Samba Dienste aktivieren und starten

Die beiden nachfolgenden Befehle aktivieren die für Samba notwendigen Dienste smb und nmb:

1
2
systemctl enable smb.service
systemctl enable nmb.service

Abschließend starten Sie die beiden Linux-Dienste:

1
2
systemctl restart smb.service
systemctl restart nmb.service

 

Firewalld für Samba anpassen

Sofern Sie unter Centos7 den firewalld-Dienst aktiviert haben, so sollten Sie die Zugriffe per SMB-Protkoll erlauben. Das erledigt der folgende Befehl:

1
2
firewall-cmd --permanent --zone=public --add-service=samba
firewall-cmd --reload

 

Nun sollte von erlaubten Clients aus bzw. mit dem passenden Passwort der der Zugriff auf \\<hostname>\datastore möglich sein. Wer einen anderen Share-Namen möchte, ändert das entsprechend in der smb.conf.

Damit wir nun noch einen „schönen“ Namen für unsere Service-IP im Share-Namen nutzen können, erstellen wir einen entsprechenden Host-Eintrag im DNS – bspw. „fileserver“ für die Cluster-IP 10.51.137.247 aus unserem Beispiel von oben.

Damit können nun Anwender über den Freigabe-Namen \\fileserver\datastore auf ihre Dateien von nun an mit 99,99% Verfügbarkeit zugreifen.

 

 

 

Weiterführende Links zum Thema

 

Fazit zum hochverfügbaren, ausfallsicheren Samba-Server

Wer die Kosten für die doppelten Ressourcen nicht scheut, kann mit den kostenfreien OpenSource-Produkten Pacemaker, Gluster-FS, LVM und Samba und einer Stunde Arbeit die Verfügbarkeit seiner IT-Services erheblich steigern.

Auch wenn das hier gezeigte Beispiel im echten Leben von Anwendern und IT-Verantwortlichen nicht so kritisch gesehen wird, so bleibt doch immerhin in der obigen Konstellation die Möglichkeit etwa Updates und Wartungsarbeiten während der normalen Arbeits- und Nutzungszeit durch den IT-Administrator durchführen zu lassen – anstatt dafür immer wieder Nachtschichten einlegen zu müssen.