Ausfallsicherer und hochverfügbarer Samba-Server

,

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 -> 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.

Hochverfügbarkeit mit Pacemaker und Corosync

, ,

Einleitung: Hochverfügbarkeit mit Pacemaker und Corosync

Mit Pacemaker und Corosync können mehrere Linux-Hosts eine einfache Form der Hochverfügbarkeit (engl. High availability, kurz HA) erreichen. So können mit Pacemaker IP-Adresse, ganze Webserver oder auch File-Systeme hoch-verfügbar gemacht werden.

Anhand einer so genannten Service-IP-Adresse beschreiben wir nachfolgend das Prinzip von Pacemaker und Corosync. Pacemaker übernimmt dabei die Verwaltung der Cluster-Resourcen. Corosync kümmert sich um die Kommunikation zwischen den Hosts.

Auf diese Weise lassen sich zum Beispiel mit einer Master-Master-Replikation von mariadb/mysql hochverfügbare Datenbank-Lösungen erstellen. Mit der OpenSource-Software glusterfs lassen sich zusammen mit Pacemaker und Corosync ganze Dateisysteme als HA-Lösung konfigurieren.

Alle nachfolgend genutzten Software-Pakete (Centos, Pacemaker und Corosnyc) sind genauso wie maysql und mariadb OpenSource Produkte.

Versuchsaufbau für Corosync und HA

Für unser nachfolgendes Tutorial erstellen wir zwei identische Linux-Hosts mit CentOS die jeweils einen Netzwerkanschluss sowie eine eigene statische IPv4-Adresse im selben IP-Subnetz haben. Die Linux-Rechner sollen anschließend eine dritte IP-Adresse (nachfolgend Service-IP genannt) erhalten, die entweder auf dem einen oder dem anderen Linux-Server „gehostet“ wird.

Ziel ist es, diese Service-IP-Adresse immer erreichbar zu haben und dennoch einen der beiden Hosts für Wartungszwecke herunter fahren zu können. Auf diese Weise kann mit einfachen Mitteln eine einfache Form der Hochverfügbarkeit erreicht werden.

Hinweis: Auch wenn wir Pacemaker und Corosync hier exemplarisch unter Centos 7 einrichten, so geht das natürlich auch auf anderen Linux-Distributionen wie debian, Ubuntu oder Redhat . Hier unterscheiden sich lediglich die Kommandos für die Installation der Pakete (apt-get bei debian).

Unser Setup für das Pacemaker Tutorial:

  • 2 CentOS 7.5 Hosts mit je einer statischen IP-Adresse
  • Host 1: testdb01, 168.0.113
  • Host 2: testdb02, 168.0.114
  • Service-IP-Adresse: 168.0.115

Für alles weitere installieren wir CentOS 7.x (z.B. auf einer Vitualisierungsplattform wie VMWare oder Proxmox). Die Linux-Hosts benötigen im produktiven Betrieb 1-2 CPU-Kerne, 2 GB RAM und 20 -30 GB an Festplatte. Wer einfach nur testen will, kommt auch mit einem CPU-Kern, 1 GB RAM und 3-4 GB HDD aus.

Wir richten pro Host die statische IP-Adresse ein und lassen mit „yum-y update“ alle Updates durchlaufen. Für alles weitere deaktivieren wir den CentOS Firewalld (systemctl disable firewalld) und deaktivieren „selinux“ ( In der Datei /etc/sysconfig/selinux ersetzen Sie das die Zeile, die mit „SELINUX“ beginnt durch SELINUX=disabled )

Installation von Corosync bzw. Pacemaker

Die Softwarepakete pacemaker, pcs und corosync müssen unter Centos auf allen Hosts installiert werden die später Mitglieder des Clusters werden. Die Installation erledigen wir mit:

1
yum -y install pacemaker pcs

In der Standard-Version werden hier gleich ca 25-30 weitere anhängige Pakete mit installiert, die für den Betrieb notwendig sind. Im Anschluss daran aktivieren wir den pcsd Dienst und starten ihn:

1
2
systemctl enable pcsd.service
systemctl start pcsd.service

Damit die unterschiedlichen Hosts bzw. die Dienste auf den Hosts mit einander sprechen können, benötigen Sie einen Benutzer mit Kennwort. Während der Installation wird automatisch ein neuer User namens „hacluster“ angelegt: Diesem geben wir nun noch ein Passwort:

1
passwd hacluster

Achten Sie darauf, daß auf beiden Hosts das Passwort für den benutzer „hacluster“ nach Möglichkeit identisch ist

Cluster Dienst einrichten

Damit die Knoten miteinander kommunizieren können, tauschen wir nun erst einmal die Authentifizierungen aus:

1
2
3
4
5
[root@testdb01 mysql<strong>]# pcs cluster auth testdb01 testdb02</strong>
Username: hacluster
Password:
testdb01: Authorized
testdb02: Authorized

Die Meldung von beiden Knoten muss “Authorized” lauten – dann kommunizieren die Hosts erfolgreich miteinander.

Cluster – alte Pacemaker Konfiguration löschen

Zur Sicherheit „zerstören“ bzw. löschen wir alle bisherigen Konfigurationen auf den beiden Hosts.

Hinweis: Bei einer brandneuen Installation ist dieser Schritt nicht nötig.

1
2
3
4
5
6
[root@testdb01 mysql]# pcs cluster destroy --all
Warning: Unable to load CIB to get guest and remote nodes from it, those nodes will not be deconfigured.
testdb01: Stopping Cluster (pacemaker)...
testdb02: Stopping Cluster (pacemaker)...
testdb02: Successfully destroyed cluster
testdb01: Successfully destroyed cluster

Neues Pacemaker Cluster erstellen.

Nun erstellen wir in neues “Cluster” aus zwei Knoten bzw. Hosts. Die Hosts heißen bei uns „testdb01“ und „testdb02“. Das Cluster selbst nennen wir „testdb. Direkt nach dem Abschicken des Befehls „pcs cluster setup“ werden zuerst die Zertifikate ausgetauscht.

Voraussetzung ist, daß die beiden Hosts sich im vorherigen Schritt (pcs cluster auth) erfolgreich gegenseitig authentifiziert haben.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
[root@testdb01 ~]# pcs cluster setup --name testdb testdb01 testdb02
Destroying cluster on nodes: testdb01, testdb02...
testdb02: Stopping Cluster (pacemaker)...
testdb01: Stopping Cluster (pacemaker)...
testdb01: Successfully destroyed cluster
testdb02: Successfully destroyed cluster
Sending 'pacemaker_remote authkey' to 'testdb01', 'testdb02'
testdb01: successful distribution of the file 'pacemaker_remote authkey'
testdb02: successful distribution of the file 'pacemaker_remote authkey'
Sending cluster config files to the nodes...
testdb01: Succeeded
testdb02: Succeeded
Synchronizing pcsd certificates on nodes testdb01, testdb02...
testdb01: Success
testdb02: Success
Restarting pcsd on the nodes in order to reload the certificates...
testdb01: Success
testdb02: Success

Konfiguration von Corosync prüfen:

Zur Sicherheit werfen wir einen Blick in die nun auf beiden Hosts vorhandene Konfig-Datei unter /etc/corosync/. Sie heißt dort „corosync.conf“

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
[root@testdb01 ~]# more /etc/corosync/corosync.conf
totem {
version: 2
cluster_name: filecluster
secauth: off
transport: udpu
}
nodelist {
node {
ring0_addr: testdb01
nodeid: 1
}
node {
ring0_addr: testdb02
nodeid: 2
}
}
quorum {
provider: corosync_votequorum
two_node: 1
}
logging {
to_logfile: yes
logfile: /var/log/cluster/corosync.log
to_syslog: yes
}

Corosync Cluster starten

Mit dem Befehlt “pcs cluster start –all” starten wir auf einem Knoten corosync auf allen zum Cluster gehörenden Hosts.

Wichtig: Das muss nur an auf einem Host/Knoten erfolgen.

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

Corosync und Pacemaker aktivieren und starten

Damit wir nun etwas Praktisches tun können, müssen sowohl der corosync-Dienst als auch Pacemaker aktiviert und gestartet werden.

Auf testdb01 und testdb02 führen wir also aus

1
2
3
4
systemctl enable corosync.service
systemctl start corosync.service
systemctl enable pacemaker.service
service pacemaker start

Anschließend prüfen wir den Status mit “pcs status“. Nun sollte ‚pcs status‘ etwas sinnvolles ausgeben , auch wenn noch keine Resource vorhanden ist

1
2
3
4
5
6
7
8
9
10
11
12
13
14
[root@testdb01 ~]# pcs status
Cluster name: testdb
Stack: corosync
Current DC: testdb01 (version 1.1.18-11.el7_5.2-2b07d5c5a9) - partition with quorum
Last updated: Wed Jun 13 12:50:58 2018
Last change: Wed Jun 13 12:50:55 2018 by root via cibadmin on testdb01
2 nodes configured
0 resources configured
Online: [ testdb01 testdb02 ]
No resources
Daemon Status:
corosync: active/enabled
pacemaker: active/enabled
pcsd: active/enabled

Wir sehen: Auf dem Knoten testdb01 sind alle drei Dienste (corosync, pacemaker und pcsd) aktiv und gestartet. Der Hinweis „no resources“ bedeutet, daß wir noch keine Resource (etwa eine IP) definiert haben.

Corosync anpassen (2 Host Szenario)

In unserem Fall von 2 Hosts mach weder ein Quorum (die Mehrheit unter den Servern) noch Stonith (Mechanismus zum „Abschiessen“ von schwächelnden Hosts) inhaltlich Sinn. Für ein Quorum bräuchten wir mindestens 3 Hosts. Mit den beiden folgenden Befehlen stellen wir sowohl das Quorum als auch stonith dauerhaft ab.

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

Virtuelle Resource / Virtuelle IP anlegen

Wir möchten nun eine einfache IPv4-Adresse als einzige Resource anlegen und auf einem der beiden Hosts verfügbar machen. Mit dem folgenden Befehl wird die Service-IP für das Cluster angelegt:

1
pcs resource create &lt;Resource-Name&gt; ocf:heartbeat:IPaddr2 ip=&lt;IP-Addr&gt; cidr_netmask=&lt;Netmask&gt; op monitor interval=5s

Die Variable <Resource-Name>, <IP-Addresse> und <Netmask> ersetzen wir natürlich durch die tatsächlichen Werte.

Wichtig hierbei: Die IP-Adresse muss zum Netzwerk bzw. IP-Subnetz passen, in dem der Hosts seinen Netzwerkanschluss hat.

Wir legen nun also eine zusätzliche IP-Adresse mit dem Namen „testdb-ip“, der Nummer 192.168.0.115 sowie der Netzmaske 24 (entspricht 255.255.255.0) an, die entweder auf testdb01 oder auf testdb02 gehostet wird. Sie soll außerdem vom Cluster alle 5 Sekunden geprüft werden.

1
[root@testdb01 ~]# pcs resource create testdb-ip ocf:heartbeat:IPaddr2 ip=192.168.0.115 cidr_netmask=24 op monitor interval=5s

Anschließend prüfen wir ob die IP-Adresse auch erfolgreich vom Cluster verwaltet wird:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
[root@testdb01 ~]# pcs status
Cluster name: testdb
Stack: corosync
Current DC: testdb01 (version 1.1.18-11.el7_5.2-2b07d5c5a9) - partition with quorum
Last updated: Wed Jun 13 12:52:35 2018
Last change: Wed Jun 13 12:52:32 2018 by root via cibadmin on testdb01
2 nodes configured
<strong>1 resource configured</strong>
Online: [ testdb01 testdb02 ]
Full list of resources:
 testdb-ip (ocf::heartbeat:IPaddr2): Starting testdb01

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

Ergebnis: Die Resource “testdb-ip” startet direkt auf dem Host testdb01

 

Nun prüfen wir noch am Adapter nach, ob dort ebenfalls die Service-IP vorhanden ist:

1
2
3
4
5
6
7
8
9
10
[root@testdb01 ~]# ip addr
(..)
2: eth0: &lt;BROADCAST,MULTICAST,UP,LOWER_UP&gt; mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 76:f3:cc:53:fa:6b brd ff:ff:ff:ff:ff:ff
inet 192.168.0.113/24 brd 192.168.0.255 scope global noprefixroute eth0
valid_lft forever preferred_lft forever
inet <strong>192.168.0.115/24</strong> brd 192.168.0.255 scope global secondary eth0
valid_lft forever preferred_lft forever
inet6 fe80::3522:f3f3:80cd:7aae/64 scope link noprefixroute
valid_lft forever preferred_lft forever

Ergebnis: Der Netzwerkadapter eth0 hat zusätzlich zu seiner festen IP (192.168.0.113) noch die IP-Adresse 192.168.0.115 die wir vorher als Cluster-Reosurce erstellt haben.

 

Empfehlung: Um im Fehlerfall die Konfiguration von Pacemaker bzw. Corosync schnell wieder anlegen zu können, empfiehlt es sich auf einem der beiden Linux-Hosts die Befehle vom Anlegen des Clusters bis hin zu Einrichtung der Cluster-Resource(n) in einer Bash-Datei abzuspeichern.
Damit kann im Fehlerfall durch einfaches Löschen und neu Anlegen der Konfiguration sowie der Resourcen in 20 bis 30 Sekunden eine Cluster-Einrichtung erfolgen.

 

 

Verwaltung von Corosync / Pacemaker

Cluster-Resourcen manuell verschieben.

In der Praxis wechselt die IP-Adresse nur dann von einem Host, wenn der aktive Host herunter fährt oder der Corosync-Dienst angehalten wird. Möchte man die Cluster-Resource von Hand von einem Host auf den anderen verschieben, so geht das mit:

pcs resource move <resource-name> <nodename>

Beispiel:

1
pcs resource move testdb-ip testdb02

Cluster-Resource entfernen

So wie eine Cluster-Resource angelegt wird, so kann sie natürlich auch gelöscht bzw. entfernt werden:

Syntax: pcs resource delete <Resource-Name>

Bsp.:

1
pcs resource delete testdb-ip

 

Fehler / Troubleshooting von Corosync / Pacemaker /pcsd

Sofern immer ein Host online ist, sind Fehler bei Corosync/Pacemaker eher selten. Wenn doch einmal etwas nicht geht, dann empfiehlt sich folgende Vorgehensweise:

Dienste (Pacemaker/Corosync/pcsd) stoppen und neu starten

Alle relevanten Dienste stoppen:

1
service corosync stop; service pacemaker stop; service pcsd stop;

Alle relevanten Dienste starten:

1
service pcsd start; service pacemaker start; service corosync start;

Danach ermitteln Sie auf beiden Hosts einzeln mit “pcs status” ob die Hosts sich gegenseitig als “online” sehen und ob die Cluster-Resource(n) vorhanden sind.

Die harte Tour: Konfig neu anlegen.

Für den unwahrscheinlichen Fall, dass ein Fehler hartnäckiger ist, kann aus Zeitgründen die Konfiguration auch kurzerhandgelöscht und neu gestartet werden.

Dazu stoppen Sie auf beiden Hosts alle Dienste und löschen anschließend die Konfigurationsdateien auf beiden Hosts. Danach legen Sie die Konfiguration (wie oben beschrieben) neu an.

Das ist in vielen Fällen einfacher und vor allem schneller als eine langwierige Fehlersuche.

Vorgehen:

1
2
3
4
5
6
# Dienste stoppen
service corosync stop; service pacemaker stop; service pcsd stop;
# Konfig Dateien löschen
/etc/corosync/corosync.conf löschen
/etc/pacemaker -&gt; Dateien löschen.
#Ggf. Dienste deaktivieren

Danach noch mal neu aufsetzen wie oben beschrieben. (geht in der Regel schneller als eine lange Fehlersuche)

Weiterführende Infos

 

Die richtige Ceph Netzwerkstruktur

, ,

Warum das richtige Netzwerk bei Ceph so wichtig ist

Vor der Integration eines Ceph storage-clusters steht jeder Linux-Administrator irgendwann vor der Frage, welches Netzwerk (Ethernet, Infiniband, Omnipath) er verwenden möchte. Das hängt zunächst selbstverständlich vom zu erwartenden Workload und der Anzahl der Clients ab. Allerdings gibt es noch einen wichtigen weiteren Faktor den es zu beachten gibt. Ceph nutzt viele unabhängige Festplatten. RAID Arrays bieten sich nicht an, da die Performance mit  jeder zusätzlichen Festplatte wunderbar linear skaliert. Die vielen einzelnen Festplatten sowie der Aufbau des Ceph Clusters bringen es mit sich, dass alle Datenblöcke auf mehrere Knoten verteilt werden müssen. Je nach implementiertem Regelwerk sogar über Racks oder Rechenzentren hinweg. Das schafft Ausfallsicherheit. Jedoch bedeutet das, dass bei jedem Lese- oder Schreibzugriff eine Kommunikation mit allen Ceph-Nodes über das Netzwerk stattfinden muss, um alle notwendigen Datenblöcke zu erreichen.

Festplattenzugriff = Netzwerkzugriff bei Ceph

Da also jeder Zugriff auf eine der vorhandenen Festplatten auch ein Netzwerkzugriff ist, sollte man unbedingt auf ein 10 GE Netzwerk zurückgreifen um alle Ceph Knoten untereinander zu verbinden. 10 GE stellt hierbei das absolute Minimum dar. Möchten Sie Ceph richtig im produktiven Betrieb mit mehreren clients einsetzen, kommt ein 1 GE Netzwerk wirklich extrem schnell an seine Grenzen. Hier ist nicht nur der Datenverkehr zu den Clients und zwischen den Ceph Knoten bei der konkreten Datenabfrage zu betrachten. Ceph muss schließlich auch alle Replikationen auf den vorhandenen Servern und Festplatten des Clusters verteilen. Im besonderen wenn eine der Festplatten oder ein ganzer Server ausfällt, repliziert Ceph automatisch die Daten bis wieder die gewünschte Anzahl an Repliken vorliegt.

Netzwerkoptimierung

Dieses Verhalten kann durch getrennte Netzwerke optimiert werden. Ein Netzwerk übernimmt dann die Kommunikation zu den clients. Das zweite Netzwerk ist ausschließlich für die OSD Replikationen zuständig.

Die Konfiguration

Um zwei separate Netzwerke zu nutzen, müssen die Netzwerke innerhalb der ceph.conf eingetragen werden. Hierzu genügt es bereits die Netz ID mit entsprechendem Prefix anzugeben.

[global]

public network = 172.10.10.0/24

cluster network = 172.10.11.0/24

Sobald die Ceph Konfiguration auf allen Knoten verteilt wurde und die Services neu gestartet sind, werden die Netzwerke entsprechend verwendet. Damit wurde ein möglicher Flaschenhals in der Architektur  des Clusters optimiert bzw. verhindert.

Was ist eigentlich… ein Managed Server?

, ,

Ein Managed Server ist das, was man ein Rundum-Sorglos Paket nennt. Neben dem eigentlichen Server als Speicherplatz und Host beinhalten Managed Server eine Vielfalt praktischer und sicherer Serviceleistungen. Backup Systeme und die Wartung des Internetauftrittes sind zwei der zahlreichen und häufig genutzten Beispiele.

Managed Server sind ausschließlich für den Kunden da während ein Shared Server nur gemietet wird und einen Teil des vorhandenen Speicherplatzes anhand der Mietkosten zur Verfügung stellt, bieten Managed Server ihren Kunden unendlich viel Speicherplatz. Ebenso wird das Maximum an Serviceleistungen per Fernwartung geboten, wodurch der Kunde auf der sicheren Seite und bestens betreut ist. Das Konzept Managed Server wird immer beliebter, was nicht zuletzt an der Kundenorientierung und den zahlreichen integrierten Zusatzleistungen liegt. Der Kunde steht im Mittelpunkt und erhält die besten Leistungen vom Anbieter.

Leistungsumfang beim Managed Server

Techniker wartet einen ServerDie Fernwartung, das Patch Management, ein Remote Data Backup und viele Aspekte zur Sicherheit sowie die Überwachung des Desktop sind integrierte Leistungen. Kunden sparen mit einem Managed Server eine Menge Zeit und Geld, da sie keinen eigenen IT Support beschäftigen oder sich selbst mit der IT Wartung beschäftigen müssen. Für private und klein gehaltene Websites ist ein Managed Server nur bedingt geeignet. Für Unternehmer, die keine eigene Energie und Zeit in das Hosting und die darum auflaufenden Aufgaben investieren möchten, bietet sich diese Option aber an.

Wie wird ein Managed Server bezahlt?

Der Kunde schließt einen All-Inklusive Vertrag ab und zahlt seine monatliche Rate. Bei allen gewünschten Änderungen und im Rahmen der vertraglich vereinbarten Dienstleistung genügt eine Anfrage des Kunden und die Aufgabe wird erledigt. Die sichere und seriöse Wartung der Seite ist ein deutlicher Vorteil, den sich Unternehmer durch das Outsourcing an einen Hoster sichern, der ihnen einen Managed Server anbietet. Ein einfacher Host ist günstiger, aber: Benötigt ein Unternehmen einen vollständigen IT Support, ist der Managed Server auf lange Sicht die günstigere und praktischere Variante. Vor allem Großkonzerne und mittelständische Unternehmen erhalten so einige Vorteile.

Sicherheitskonzept Managed Server

Die Haftung für die Sicherheit der Kundendaten und der gesamten Website obliegt dem Betreiber des Servers. Bei einem Managed Server können Unternehmer sicher sein, dass der Betreiber seine Haftung ernst nimmt und seine Server mit der entsprechenden Sicherheitssoftware und Betriebssoftware ausstattet. Die Daten werden gesichert und der Kunde profitiert von einem Support, der keinen Wunsch offen und keine Frage unbeantwortet lässt. Datenschutz und Datensicherheit sind zwei Grundpfeiler von Managed Servern und liegen den Betreibern am Herzen.

Managed Server vs, klassischer Host

Beim klassischen Hosting bucht man Speicherplatz, der streng begrenzt und in der Aufstockung teuer ist. Beim Managed Server bucht man ein Full-Service Paket, das so viel Speicherplatz wie gewünscht beinhaltet. Expandiert das Unternehmen, wächst die Website ohne Probleme mit. Denn auf dem Managed Server können prinzipiell unendlich viele Daten gespeichert werden, wodurch Unternehmen nicht in ihrer Performance begrenzt werden. Wer nur eine kleine Firma oder einen kleinen Onlineshop betreibt, ist mit einem klassischen Host besser beraten. Großunternehmer und mittelständische Firmen sparen sich die IT Abteilung, da der Managed Server diese Dienstleistung beinhaltet und per Fernwartung vornimmt.

Software Defined Storage mit CEPH

, , ,

Datenwachstum als Herausforderung der IT

Das stetige Wachstum der Datenmengen ist ein Problem, dem sich jede IT-Abteilung früher oder später stellen muss. Nutzen Sie ausschließlich klassische Speicherlösungen wie SAN oder NAS müssen die zur Verfügung stehenden Kapazitäten irgendwann mühsam erweitert werden. Eine solche Maßnahme hat des öfteren auch eine kurze downtime zur Folge, da nicht jede Erweiterung im laufenden Betrieb möglich ist.

Damit stellt sich bereits ein weiteres großes Problem ein. Kunden erwarten heutzutage, dass IT-Services zu 100 % an jedem Tag und zu jeder Stunde verfügbar sind. Downtimes werden immer weniger toleriert, besonders im Bereich von Rechenzentren sowie des Hostings. Eine mögliche Lösung um diese Zeiten zu minimieren oder gar völlig auszuschließen bietet beispielsweise Software Defined Storage oder kurz SDS.

Ceph geht neue Wege

Ceph Architektur

Abbildung 1
Ceph Architektur

Schwierigkeiten bei Software Defined Storage

CEPH ist aber keineswegs perfekt und bringt selbstverständlich auch Nachteile mit sich. Ein Merkmal mit dem man sich vor der Inbetriebnahme auseinandersetzen muss, sind die Latenzen die SDS im Vergleich zu Direct Attached Storage (DAS) mit sich bringt. Die erhöhte Komplexität des Software Stacks in Kombination mit den verwendeten Netzwerkverbindungen erhöhen die Latenz pro IO signifikant.

Es erweist sich als äußerst schwierig die Latenz unter den Wert von einigen Millisekunden für Schreibvorgänge zu senken. Woher diese Latenz kommt lässt sich verdeutlichen, wenn man sich die Arbeitsweise von CEPH bei Schreibvorgängen etwas genauer betrachtet (Abbildung 2).

Ein synchroner IO muss vom Client zur primären OSD gesendet werden. Die primäre OSD schickt anschließend die Anzahl konfigurierter Replikationen zu weiteren OSD’s und deren Journalen. Sobald die Repliken auf den Journalen aller OSD’s vorliegen, wird der Vorgang an die primäre OSD bestätigt. Hat die primäre OSD nun alle Bestätigungen erhalten, wird eine Bestätigung an den Client gesendet und dieser kann den nächsten IO senden. Das verdeutlicht schon weshalb es bereits zu Latenzen innerhalb des Software Stacks kommt.

SDS mit Ceph - Arhcitektur

Abbildung 2

Zusätzlich spielt auch das eingesetzte Netzwerk bei Ceph eine entscheidende Rolle. Es gilt hier zunächst unnötige Hops zu vermeiden, da jeder Hop etwa 200us Latenz mit sich bringt. Ein 10GE Netzwerk gilt hierbei als das absolute Minimum, welches Sie beim Einsatz von Ceph oder einem anderen verteilten Speichersystem verwenden sollten. Das verringert Latenzen und erhöht die Bandbreite. Eine zusätzliche Verbesserung bringt Ihnen selbstverständlich der Einsatz von RDMA, jedoch müssen hier die Kosten beachtet werden. All diese Faktoren spielen eine wichtige Rolle und müssen optimiert werden um Latenzen unter dem 2ms Level zu erhalten und dabei eine Balance zwischen Kosten und Nutzen zu finden, was natürlich nicht immer einfach ist.

 

Anforderungen an eine gute SDS Lösung

Damit Sie nach der Einführung einer SDS Lösung wie Ceph nicht enttäuscht sind, gibt es einige Punkte zu beachten. SSDs oder (Enterprise SSD oder NVME SSD) für die Journale, in denen die Schreibvorgänge gecached werden, sowie ein 10GE Netzwerk sind nach herrschender Meinung innerhalb der Ceph Community und unseren eigenen Erfahrungen ein Muss. Für die OSD’s sollten nach Möglichkeiten SAS3 HDD’s verwendet werden. Es ist auch denkbar bei Bedarf einen Teil der OSD’s rein aus SSDs zu erstellen und gesondert zur Verfügung zu stellen. Wichtig ist zudem keine RAID Arrays zu verwenden. Ceph profitiert stark von vielen unabhängigen Festplatten. Einem schwerwiegenden Datenverlust entgehen Sie zudem indem Sie mehrere Server mit möglichst vielen Festplatten (OSD’s) bereitstellen

Die CPU sollte möglichst viele Prozessor-Kerne haben, und der Arbeitsspeicher mit etwa 1-2 GB pro OSD berechnet werden um hier keinen Flaschenhals zu generieren. Der Einsatz von RDMA muss wohl überlegt sein und kommt auf den speziellen Workload an. Werden extrem niedrige Latenzen und hohe Bandbreite über 10 GE benötigt bietet es sich eventuell eher an auf ein spezielles Storage System wie GPFS, BeeGFS oder Lustre  in Kombination mit Infiniband/Omnipath zu setzen.

Fazit zu Ceph

Zusammenfassend lässt sich sagen, dass Software Defined Storage definitiv eine gute Möglichkeit darstellt, um stetig wachsende Datenbestände einfacher zu verwalten. Jedoch hat Software Defined Storage genau wie jede andere Lösung gewisse Einschränkungen denen man sich bewusst sein muss. Im modernen IT-Betrieb wird man aber nicht auf SDS verzichten können. Die mitgebrachten Vorteile wie Skalierbarkeit, einfache Erweiterung und eine sehr hohe Verfügbarkeit werden zunehmend wichtiger.

Weiterführende Links zum Thema:

Sicherung von Windows Servern mit Online Backup von ahsay

, ,
Die Fortschritts-Anzeige der Online-Backup-Software

In diesem Tutorial beschreibe ich wie Sie auf einem Windows-Server die Online-Backup Software ahsay installieren und konfigurieren. Damit sind Sie in wenigen Minuten in der Lage ihre wichtigen Daten sicher in die Cloud übertragen und jederzeit wieder herzustellen.

Wenn Sie alle Schritte der Reihe nach durchführen, haben Sie hinterher eine regelmäßige Datensicherung, die ihre wichtigen Daten sicher und verschlüsselt regelmäßig (in der Regel täglich) in eines unserer Rechenzentren sichert.

Was Sie brauchen:

  • 10- 15 Minuten Zeit
  • Die Zugangsdaten zur Online-Backup-Software
  • Einen Windows Server
  • Zugang zum Internet

Hinweis: Die Zugangsdaten für den Online-Backup erhalten Sie von einem Mitarbeiter der Biteno GmbH. Sofern Sie den Online Backup zunächst nur testen möchten, so können Sie sich auch hier eine Test-Version frei schalten lassen.

Herunterladen und Konfigurieren der Online-Backup Software

Schalten Sie sich auf Ihren Windows-Host auf. Laden Sie im Browser (Internet- Explorer) die Software von ahsay herunter:  OBM: https://ob01.veryhost.com/obs/download/obm-win.exe. Speichern Sie die Datei unter z.B. unter c:\install  ab. Nach dem Sie die Datei herunter geladen haben, öffnen Sie bitte den Ordner und starten die Installation mit einem Doppelklick. Es öffnet sich der Assistent zur Installation der Software von Ahsay.

Nach der Installation der Online-Backup Software startet der Assistent

Nach der Installation der Online-Backup Software startet der Assistent

Doppelklicken Sie auf die Datei um die Installation zu starten. Akzeptieren Sie den vorgeschlagenen Pfad sowie die Lizenzbedingungen und klicken Sie auf „Fertigstellen“. Am Ende der Installation startet die Online-Backup-Software.

Bitte prüfen Sie, ob der korrekte Backup-Server eingetragen ist. Voreingestellt ist (bei Biteno) ob01.veryhost.com. Geben Sie im Folgenden ihren  Account-Namen und ihr Passwort ein.

Bitte geben Sie ihren Anmeldenamen sowie Ihr Passwort ein

Bitte geben Sie ihren Anmeldenamen sowie Ihr Passwort ein

 

Überblick über die Programm-Oberfläche

Nach dem Start sieht der Start-Bildschirm von ahsay wie folgt aus:

Übersicht der Oberfläche des Online-Backup

Übersicht der Oberfläche des Online-Backup

Unter (1) finden Sie die Aktionen zum sofortigen Sichern und Wiederherstellen von Daten. Im Punkt Optionen (2) können Sie neue Backup-Sets erstellen und bestehende ändern. In der Übersicht von (3) sehen Sie wieviel Gigabyte Sie bereits verwendet haben. Unter (4) können Sie die Protokolle der letzten Sicherungen bzw. Rücksicherungen einsehen.

Einrichten von Datei-Sicherungen

Um nun das erste so genannte Backup-Set einzurichten, gehen Sie wie volgt vor:

Klicken Sie auf das Getriebe-Symbol unten links. Anschließend klicken Sie auf das grüne ‚+‘ Symbol. Es öffnet sich der Assistent zum Einrichten eines neuen Backups:

Einrichten der Online-Backup Software

Einrichten der Online-Backup Software

Geben Sie dem Backup einen sprechenden Namen:

Da unter Ihrem Account mehrere Server mit mehreren Backups eingerichtet werden können, geben Sie dem jeweiligen Backup-Set bitte immer einen eindeutigen Namen (1). Wir empfehlen Ihnen dazu die folgende Konvention:

  • : Server01-DateiBackup.

Darunter wählen Sie die Backup-Art (Datei-Backup, Exchange, etc.) aus. Für Ihre erste Sicherung wählen Sie „Datei Backup“ aus. Damit können Sie alle lokalen Laufwerke sowie verbundene Netzwerklaufwerke sichern.

Eingeben der Windows-Konto Informationen in der Online-Backup Software

Eingeben der Windows-Konto Informationen in der Online-Backup Software

Geben Sie im Kasten darunter (2) den Benutzernamen, die Domäne und das Kennwort des Windows-Accounts ein. Bitte beachten Sie, daß dieser Account bzw online casino download. dieses Windows-Konto die notwendigen Rechte benötigt, um die zu sichernden Dateien zu lesen.

Backup-Quelle auswählen

Danach wählen Sie links „Backup-Quelle“ (1) und klicken rechts (2) auf „Fortgeschritten“. In der folgenden Maske wählen Sie links alle lokalen Laufwerke aus, die gesichert werden sollen und klicken anschließend auf „Okay“.

Auswahl der zu sichernden Ordner beim Online-Backup

Auswahl der zu sichernden Ordner beim Online-Backup

Backup-Zeitplan einrichten

Klicken Sie im linken Menüteil auf „“Backup-Zeitplan“ (1) und anschließend auf „Backup-Schedule“ – anschließend auf Eigenschaften (3).

Einstellen des passenden Zeitplans für die Datensicherung

Einstellen des passenden Zeitplans für die Datensicherung

Geben Sie dem Backup-Zeitplan einen eindeutigen Namen

  • Bsp: server01-daily

Stellen Sie anschließend unter 4 den richtigen Zyklus ein. Tag für täglich, Wochen für wöchentlich usw. Stellen Sie außerdem den frühesten Startzeitpunkt ein. Klicken Sie anschließend auf „Okay“ (5). Legen Sie die Uhrzeit, zu der die tägliche Datensicherung unterhalb der Woche startet, nach Möglichkeit soweit in den Abend, daß keine Anwender mehr gestört oder behindert wird.

Backup-Optionen

Unter dem Punkt Optionen im linken Menü unten finden Sie außerdem das Verzeichnis der temporären Auslagerung von Dateien. In dieses Verzeichnis werden während des Backups Dateien geschrieben.

Vielfältige Optionen zur Einstellung der Backup-Software

Vielfältige Optionen zur Einstellung der Backup-Software

Bitte stellen Sie unbedingt sicher, daß auf diesem Laufwerk ausreichend Platz vorhanden ist.Schließen Sie die Maske mit „Okay“ rechts unten.

 

Erste Online-Sicherung starten

Zum Starten der ersten Sicherung können Sie entweder die erste Ausführung des Backup-Schedule abwarten oder die Sicherung sofort manuell starten. Klicken Sie dazu in der Haupt-Maske auf „Sicherung“ (links) und wählen anschließend den passenden Backup-Satz (Backup-Set) aus. Nach wenigen Sekunden startet der Backup. Dabei erhalten Sie eine Anzeige, in der Sie den aktuellen Backup-Fortschritt sowie die noch verbleibende Dauer angezeigt bekommen.

Die Fortschritts-Anzeige der Online-Backup-Software

Die Fortschritts-Anzeige der Online-Backup-Software

Internet-Bandbreite für die Erst-Sicherung

Bitte beachten Sie beim ersten Start Ihres Online-Backup folgendes: Eine Online-Sicherung belegt – vor allem nach dem ersten Start – ihre  Internet-Bandbreite. Sofern möglich sollten Sie die erste Sicherung eines Servers in die frühen Abendstunden legen. So können Sie während der Nachtstunden die volle Bandbreite nutzen.

Wichtig: Sehr große Erst-Sicherungen (> 100 GB) sollten Sie bevorzugt auf einen Freitag legen. So können Sie die Zeit des Wochenendes mit nutzen, in der in Ihrem Netzwerk meistens niemand arbeitet und damit die Bandbreite frei ist.

In Ihrem eigenen Interesse empfehlen wir Ihnen, die Sicherung am darauffolgenden Tag zu prüfen. Dies können Sie am einfachsten mit der Logging-Funktion der Online-Backup Software erreichen, in der alle gesicherten Dateien protokolliert werden.

Wichtige Hinweis zur Nutzung der Online-Backup Software

Sie erhalten bei der Einrichtung Ihres Accounts/Kontos in der Online-Backup Software einen Benutzernamen und ihr Kennwort.

Wichtig: Das erste vergebene Passwort wird von der Backup Software verwendet und gespeichert, um damit die nachfolgenden Datensicherungen zu verschlüsseln.

Sie können ihr Passwort jederzeit ändern – allerdings benötigen Sie zur Entschlüsselung Ihrer Dateien bei einem Restore bzw. einer Wiederherstellung ihr erstes Passwort.

Daher: Bitte bewahren Sie ihr erstes Passwort an einem sicheren Ort auf – sie werden es bei einer Wiederherstellung Ihrer Daten brauchen

 

Weiterführende Links

 

Haben Sie Fragen zu Online-Backups oder Managed Backup? Unsere freundlichen Vertriebs-Mitarbeiter erklären Ihnen gerne die Vorteile einer ausgelagerten Datensicherung.

Übrigens: Die Online-Backup Lösung der Biteno GmbH können Sie 30 Tage lang unverbindlich testen. Sprechen Sie uns gerne dazu an – wir freuen uns auf Ihren Kontakt.