Alle Beiträge von Thomas Joos

Fedora CoreOS verfügbar

Fedora CoreOS ist ein automatisch aktualisierendes, minimales, monolithisches, Betriebssystem für Container-Umgebungen, das für den Betrieb im Cluster konzipiert ist. Der Betrieb kann auch auf alleinstehenden Servern realisiert werden. Auch der Betrieb zusammen mit Kubernetes ist möglich. Technologien wie Ignition, rpm-ostree und SELinux sind ebenfalls integriert. Im Fokus steht der Betrieb als Container-Host.

Fedora CoreOS baut auf Fedora 31 und Kernel 5.4 auf. Die neue Version unterstützt Docker und Open Container Initiative (OCI). CoreOS steht über AWS zur Verfügung, genauso wie in Microsoft Azure und Google Cloud Platform. Die Einrichtung der Distribution wird auf der Seite „Fedora CoreOS – Getting Started“ beschrieben. Folgende Plattformen werden von FedoreCoreOS unterstützt:

  • AWS
  • Azure
  • DigitalOcean
  • GCP
  • OpenStack
  • Packet
  • QEMU
  • VirtualBox
  • VMware

Die Migration zu Fedora CoreOS  wird durch eine Neu-Provisionierung der Maschine mit Fedora CoreOS durchgeführt. Die Entwickler wollen eine Dokumentation und Tools zur Verfügung stellen, um die Migration zu unterstützen.

 

CentOS stellt freie Version von Red Hat Enterprise Linux 8.1 bereit

CentOS stellt die Funktionen von RHEL kostenlos zur Verfügung. Eingesetzt wird die Version entweder auf Servern oder auf Arbeitsstationen. Neben der umfassenden Version mit allen Paketen, bieten die CentOS-Entwickler auch eine reduzierte Version an, in der notwendige Pakete erst installiert werden müssen. Das Pendant von RHEL 8.1 ist CentOS 8 (1911). CentOS 8 1911 setzt auf den Kernel 4.18, der allerdings mit Treibern und Erweiterungen versorgt wurde.

Download CentOS 8 (1911)

In der kostenlosen Distribution fehlen einige Funktionen, die Red Hat vor allem für Kunden vorgesehen hat. Ein Beispiel dafür ist die Analyse und Optimierungsfunktion Insights. Integriert sind aber dafür Sicherheitsfunktionen mit denen sich Anwendungen für Benutzer sperren lassen. Auch ein Tool zur Steuerung von Richtlinien für SELinux sind in CentOS und RHEL 8.1 verfügbar. 

Allerdings müssen Unternehmen, die CentOS einsetzen darauf achten, dass die Entwickler nicht immer sehr aktuell bei Updates sind. Von der Version 8 gab es mehrere Monate keine Updates. 

Im Gegensatz zu RHEL kann der Kernel in CentOS 8.1 allerdings nicht live gepatcht werden. Diese Funktion ermöglicht die Installation von Patches im laufenden Betrieb.

OpenNebula vOneCloud und miniOne

Mit OpenNebula können Administratoren Regeln definieren, auf deren Basis Ressourcen in privaten Cloudumgebungen automatisiert bereitgestellt werden. Im Fokus der Lösung stehen vor allem hybride Clouds. Derzeit werden vor allem Hypervisoren unterstützt und hier Xwn, KVM Und VMware. Die Software wird unter der Apache License 2-Lizenz bereitgestellt. 

Neben der kostenlosen Open Source-Version, stellen die Entwickler auch eine kommerzielle Version mit professionellem Support zur Verfügung.  Neben der großen Variante OpenNebula können sich Tester auch die Appliance vOneCloud ansehen. Mit dieser lassen sich in einer VMware-Umgebung mit vCenter eine Self-Service-Cloud aufbauen. miniOne ist wiederum eine Test-Version von OpenNebula für KVM oder für Container.  Auf Linux-Rechnern, zum Beispiel auf Basis von Ubuntu, kann die Installation und Einrichtung mit den beiden folgenden Befehlen erfolgen:

wget „https://github.com/OpenNebu-
la/minione/releases/latest/
download/minione“

sudo bash minione

Das System ermöglicht den Test von OpenNebula in einer vCenter-gesteuerten VMware-Umgebung

Sicherer Datenaustausch in der Private Cloud mit ownCloud

ownCloud gehört sicherlich zu den bekanntesten Lösungen, wenn es darum geht im Data Center eine eigene Cloud-Lösung bereitzustellen.  Mit „Secure View“ können Anwender oder Administratoren konfigurieren, dass bestimmte Dokumente in ownCloud nicht heruntergeladen werden dürfen, sondern nur online zur Verfügung stehen. Auch Nur-Lesen-Einstellungen sind möglich. Die gängigen Office-Formate werden dabei unterstützt.

In den Einschränkungen kann auch verhindert werden, dass Anwender Dokumente ausdrucken oder Inhalte aus dem Dokument kopieren können. Secure View zeigt die Dateien auf dem Empfängercomputer dazu als Bild dar. Das originale Dokument bleibt dabei immer auf dem Server.

Secure View hilft also dabei Office-Dokumente über ownCloud sicherer freigeben zu können. Auch verschiedene Berechtigungen für unterschiedliche Anwender sind möglich. Administratoren können Regeln hinterlegen, bei denen bestimmte Dokumente auf Basis der Inhalte automatisch geschützt werden. Das ermöglicht das Erstellen von sicheren Datenräumen in ownCloud, in denen gespeicherte Dokumente besonders geschützt werden. 

Container-Management mit OpenShift

Einfach ausgedrückt handelt es sich bei OpenShift um eine spezielle Kubernetes-Distribution, die sich im Rechenzentrum genauso betreiben lässt, wie in der Cloud oder auf einzelnen Computern. 

Der größte Unterschied zwischen OpenShift (das auf Kubernetes aufbaut) und Kubernetes selbst ist die eher einfachere Bedienung von OpenShift. Allerdings ist das sicherlich Geschmacksache und Kubernetes  bietet durch sein Dashboard ebenfalls eine einfachere Verwaltungsmöglichkeit. 

OpenShift Origin wird auch als Origin Community Distribution (OCD) bezeichnet Die kostenpflichtigen Varianten von Red Hat OpenShift  lassen sich bis zu 60 Tage bei einer lokalen Installation testen.

OpenShift Online ist die Variante der Plattform in der Cloud. Wer auf ein vollständig verwaltetes System setzen will, kann mit OpenShift Dedicated (https://www.openshift.com/products/dedicated/) auf OpenShift in AWS oder Google Cloud Platform.

Wer OpenShift in Microsoft Azure nutzen will, kann auf Microsoft Azure Red Hat OpenShift (https://www.openshift.com/products/azure-openshift) setzen.  Auch hierbei ist die Umgebung vollständig verwaltet. 

Entwickler können auch auf Red Hat CodeReady Containers setzen. Hierbei handelt es sich um eine Entwicklungs-Umgebung für einzelne Rechner/Notebooks. 

Am 14. Januar 2020 endet Support für Windows Server 2008/2008 R2

Ab dem 14.01.2010 gibt es für Windows Server 2008/2008 R2 keinen technischen Support und keine Updates mehr. Beim Betrieb in Azure kann dieses Problem temporär behoben werden. 

Unternehmen, die aktuell noch auf Windows Server 2008 oder Windows Server 2008 R2 setzen, können als Sofortmaßnahme auch jetzt noch die Server als virtuelle Server in Microsoft Azure umziehen.  Im Rahmen des Umzugs erhalten die Server weitere drei Jahre kostenlos Sicherheitsupdates. Der Umzug kann entweder temporär sein, bis eine endgültige Migration erfolgt, oder auch dauerhaft, mit entsprechender Aktualisierung des Betriebssystems. 

Der temporäre Umzug zu Microsoft Azure hat den Vorteil, dass aktuelle Software generell weiter betrieben werden kann, und Unternehmen mehr Zeit haben eine vollständige Migration der Server durchzuführen, zum Beispiel zu Windows Server 2019. 

TCP-Port, Komprimierung und Verschlüsselung für die Replikation steuern und kontrollieren

Mit dem folgenden Befehl sehen Sie den aktuell verwendeten Port für DAGs:

Get-DatabaseAvailabilityGroup <DAG-Name> -Status | fl ReplicationPort

Um den Port anzupassen, verwenden Sie den Befehl:

Set-DatabaseAvailabilityGroup <DAG-Name> -ReplicationPort <Portnummer>

Aktualisieren Sie eine Postfachdatenbankkopie, sehen Sie mit „Netstat -an |more“, dass Exchange den neuen Port nutzt.

Standardmäßig komprimiert Exchange die Daten vor einer Replikation. Sie können sich den Status mit dem folgenden Befehl anzeigen lassen:

Get-DatabaseAvailabilityGroup <Name der Gruppe> -Status | fl NetworkCompression

Sie können folgende Werte verwenden:

Disabled — Keine Komprimierung

Enabled — Komprimierung bei allen Netzwerken

InterSubnetOnly — Komprimierung nur zwischen Subnetzen

SeedOnly — Komprimierung nur beim manuellen Seeding

Wollen Sie die Komprimierung für alle Netzwerke einschalten, verwenden Sie in der Exchange Management Shell den Befehl:

Set-DatabaseAvailabilityGroup <Name der DAG> -NetworkCompression Enabled

Standardmäßig verschlüsselt Exchange die Daten vor einer Replikation zu den Kopieservern, wenn diese in verschiedenen Subnetzen positioniert sind. Sie können sich den Status mit der folgenden Anweisung ansehen:

Get-DatabaseAvailabilityGroup <Name der Gruppe> -Status | fl NetworkEncryption

Wollen Sie die Verschlüsselung für alle Netzwerke einschalten, verwenden Sie in der Exchange Management Shell den Befehl:

Set-DatabaseAvailabilityGroup <Name der DAG> -NetworkEncryption Enabled

Serverswitchover und Rechenzentrumswitchover mit Exchange 2019

Bei einem Serverswitchover können Sie alle aktiven Postfachdatenbanken vom aktuellen Postfachserver auf einen oder mehrere Postfachserver mit entsprechenden Postfachdatenbankkopien umschalten. Die Server, auf denen Sie die Postfachdatenbankkopien aktivieren, also zu den produktiven Datenbanken machen, müssen Mitglied in derselben Datenbankverfügbarkeitsgruppe sein.

Serverswitchover durchführen

Um einen Serverswitchover durchzuführen, können Sie die Exchange Admin Center einsetzen. Navigieren Sie zu „Server“. Wählen Sie den gewünschten Postfachserver aus, auf dem aktuell die produktiven Datenbanken gespeichert sind, und klicken auf den Server. Wählen Sie „Serverswitchover“ aus.

Anschließend können Sie Exchange die Wahl überlassen, welche Postfachdatenbankkopien auf den verschiedenen Servern mit den Kopien aktiv geschaltet werden. Alternativ können Sie manuell einen Zielserver auswählen, auf dem Exchange die Postfachdatenbankkopien als produktive Datenbanken einsetzt.

Sie können den Vorgang auch in der Exchange Management Shell durchführen, indem Sie das folgende Cmdlet verwenden:

Move-ActiveMailboxDatabase -Server <Quellserver> -ActivateOnServer <Zielserver>

Switchover von ganzen Rechenzentren

Sie können für Datenbankverfügbarkeitsgruppen (DAG) einen Modus für Rechenzentren aktivieren. Die Option ist sinnvoll, wenn Sie größere DAGs betreiben und diese über verschiedene Active Directory-Standorte verteilt sind. Der Modus ist standardmäßig deaktiviert.

Sie sollten den Modus nur für Datenbankgruppen mit mehr als drei Mitgliedern aktivieren, die über mehrere Rechenzentren verteilt sind. 

In einer Konfiguration mit mehreren Datencentern kann dieses Verhalten zu Problemen führen, wenn Mitglieder der Datenbankverfügbarkeitsgruppen untereinander nicht mehr kommunizieren können, wenn zum Beispiel das Netzwerk zwischen den Rechenzentren ausfällt.

 

MariaDB/MySQL hochverfügbar betreiben

MariaDB ist nicht automatisch hochverfügbar, wie Clouddienste oder Anwendungen, die als „Cloud Ready“ sozusagen automatisch hochverfügbar sind. Auf dem MariaDB-Server läuft der Dienst, der die angebundenen Datenbanken verwaltet, und über einen TCP-Port wird in den meisten Fällen der Zugriff über das Netzwerk hergestellt. 

Für die Hochverfügbarkeit von MariaDB wird häufig auf Galera gesetzt. Allerdings ist die Konfiguration von Galera nicht sehr einfach und erlaubt nur Cluster ab drei Knoten.

Wird auf DRBD gesetzt, lassen sich die Linux-Server auf denen MariaDB oder MySQL laufen zu einem RAID1-System zusammenfassen, in dem die entsprechenden Laufwerke repliziert werden. 

Zusammen mit Pacemaker kann dafür gesorgt werden, dass Systemdienst und IP-Konfiguration auf den anderen Knoten übernommen und aktiviert werden, wenn der Hauptknoten ausfällt.  Die Einrichtung ist zum Beispiel in CentOS oder RHEL möglich. Auch auf Ubuntu-Servern kann DRBD installiert werden, und zum Beispiel mit Heartbeat für Hochverfügbarkeit sorgen. Die Einrichtung ist zum Beispiel auf HowToForge zu lesen

Bei der Einrichtung werden die beiden beteiligten Server mit MariaDB oder MySQL mit DRBD repliziert und mit Pacemaker überwacht. 

Hyper-V-Replikation mit SSL konfigurieren

In der lokalen Verwaltung von Zertifikaten können Sie in Active Directory Zertifikate auf einem Server installieren. Diese Zertifikate verwenden Sie dann für Hyper-V-Replica. Dazu gehen Sie folgendermaßen vor:

1. Starten Sie durch Eingabe von „certlm.msc“ die Verwaltung der lokalen Zertifikate.
2. Klicken Sie mit der rechten Maustaste auf „Eigene Zertifikate“ und wählen Sie „Alle Aufgaben\Neues Zertifikat anfordern“.
3. Bestätigen Sie die Option „Active Directory-Registrierungsrichtlinie“.
4. Aktivieren Sie auf der nächsten Seite die Option „Computer“ und klicken Sie auf „Registrieren“ Das Zertifikat erscheint anschließend in der Konsole und lässt sich nutzen.
5. Sobald Sie diese Vorgänge abgeschlossen haben, ist das Zertifikat in Hyper-V verfügbar.

Rufen Sie im lokalen Zertifikatespeicher des Servers (certlm.msc) die eigenen Zertifikate auf und lassen Sie sich die Eigenschaften anzeigen.

Sie sehen bei der erweiterten Verwendung des Schlüssels die Möglichkeiten zur Client- und Serverauthentifizierung.

Mit selbstsignierten Zertifikaten arbeiten

Alternativ haben Sie auch die Möglichkeit mit selbstsignierten Zertifikaten auf den beiden Hyper-V-Hosts zu arbeiten. Dazu verwenden Sie zum Beispiel die PowerShell und den folgenden Befehl:

New-SelfSignedCertificate -certstorelocation cert:\localmachine\my -dnsname <FQDN des Servers>

In produktiven Umgebungen ist das aber nicht empfohlen. Achten Sie darauf, dass die erstellten Zertifizierungsstellen auf den beiden Servern mit denen Sie die selbst signierten Zertifikate erstellt haben, auf beiden Server als vertrauenswürdig angezeigt werden. Sie sehen die Zertifikate im Zertifikatespeicher des Servers. Diesen rufen Sie über certlm.msc auf.

Wollen Sie Hyper-V-Replica im Cluster nutzen, müssen Sie einen Hyper-V Replica Broker im Clustermanager von Windows Server 2019 erstellen. Dabei gehen Sie vor, wie bei jeder anderen Clusterressource.

Zuvor sollten Sie aber ein neues Computerkonto im Snap-In Active Directory-Benutzer und -Computer erstellen. Rufen Sie die Registerkarte „Sicherheit“ des neuen Objekts auf und geben Sie dem Computerkonto des Clusters Vollzugriff auf das neue Konto.

Hyper-V-Replica mit SSL konfigurieren

Um SSL zu nutzen, rufen Sie auf den Hyper-V-Servern die Hyper-V-Einstellungen auf und klicken auf „Replikationskonfiguration“. Aktivieren Sie die Option „Zertifikatbasierte Authentifizierung verwenden (HTTPS)“ und wählen Sie das Zertifikat aus, welches Sie für die Übertragung verwenden wollen.

Diese Einstellungen müssen Sie auf allen beteiligten Servern vornehmen. Richten Sie danach die Replikation ein.