Inhaltsverzeichnis
Oracle Linux 9 - Ein "gluster Filesystem" über zwei Rechenzentren Zonen aufbauen und für Oracle GoldenGate als Filestorage betreiben
Aufgabe:
In der Oracle Cloud wird eine eigene Golden Gate Umgebung betrieben.
Das Dateisystem von Golden Gate muss von zwei Rechenzentrums-Zonen erreichbar sein; bei einer Störung der ersten Zone (oder auch nur an einem Patch Day) soll die gesamte Umgebung reibungslos auch in der zweiten Rechenzentrums-Zone ohne Datei Verlust funktionieren.
Dazu wurde ein Object-Storage als Datei System gewählt, im laufenden Golden Gate Betrieb hat sich das aber als zu langsam herausgestellt. Die hohe Schreib- und Lese Last auf den Trail Logs von Golden Gate führte zu „merkwürdigen“ Effekten bis hin zum Datenverlusten.
Ein performantes Storage mit ZFS über die beiden Zonen kommt aus kaufmännischen Gründen nicht in Frage, unsere Umgebung hat dazu zu wenige OCPU's.
Alternativ:
Eine DBFS Lösung mit der Oracle Datenbank (Standby System für das Failover) wäre zwar eine Optionen, erscheint aber als reine Cluster Filesystem Lösung doch etwas umständlich und aufwendig.
Lösung:
In jeder Zone steht ein Golden Gate Server, jeder Golden Gate Server hat das Storage in seiner Rechenzentrums Zone gemountet, aktiv ist aber nur einer der beiden Server, der anderen steht als als passives System bei Bedarf zur Verfügung.
Vorteil:
Eine reine Linux Lösung mit einem Cluster File System sorgt hier für die Redundantz der Dateien (Virtuelles, logisches RAID1 ).
Dazu wird **GlusterFS ** auf zwei virtuellen Maschinen in einer kleinen VMWare Umgebung getestet, ob sich die gewünschte Funktionalität erreichen lässt und was dazu getan werden muss.
Später wird das System in dieser Art in der Oracle Cloud implementiert.
Ablauf
- DNS Auflösung der Server sicherstellen
- Bereitstellen von zwei Oracle Linux 9 VM's
- Installations-DVD von https://yum.oracle.com/oracle-linux-isos.html herunterladen
- Basis System Oracle Linux 9 bereitstellen, ähnlich wie Ein Oracle Linux 8 Basis System als Grundlagen für eine Oracle Datenbank Installation vorbereiten
- CentOS Repo für Gluster 11 definieren
- Installation der GlusterFS Software
- Cluster FS Dienste aktivieren
- Volume einrichten
- Anbinden der Clients an das verteilte Filesystem
- Testen
- Konzept in der Oracle Cloud ausrollen
- In der Cloud testen
- Mit dem Oracle Enterprise Manager überwachen
- Produktiv-Umgebung härten
- Firewall aktiveren und Regeln einstellen
- Verschlüsselung zwischen den Knoten aktiveren (SSL)
- Schreibrechte konfigurieren
Mit zwei Knoten von GlusterFS kann es zu einen Splitbrain Verhalten kommen, allerdings ist das mehr ein Thema wenn die Daten über mehrere Server verteilt werden; im Produktiven Fall wäre dann ein 3 Knoten System sinnvoll? Muss für diesen Anwendungsfall getestet werden.
DNS Konfiguration
DNS Auflösung für beide Maschinen einrichten und prüfen!
Die Namen und IP Adressen müssen sich problemlos in alle Richtungen auflösen lassen!
In unsere Umgebung ist das dann:
- goldgatefs-a 10.10.10.111
- goldgatefs-b 10.10.10.112
Im ersten Schritt nicht genützt, müsste über eine Cluster IP Mechanismus wie pacemaker verteilt werden
- goldgatefsCluster 10.10.10.113
Mein DNS ist auf Oracle DB Basis; siehe ⇒ PowerDNS 4.x - Die Alternative für BIND - Mit einer Oracle Datenbank im Backend einsetzen
GlusterFS Cluster Software und Umgebung vorbereiten
Wie immer müssen die grundlegenden Voraussetzung für den Betrieb eines Clusters zu mehr als 100% geben sein!
Oracle Linux 9 Basis Installation bereitstellen
Eine neue Maschine aufsetzen und diese als erste Maschine konfigurieren.
Dazu die Installations-DVD von https://yum.oracle.com/oracle-linux-isos.html herunterladen und ein Basis System Oracle Linux 9 bereitstellen, ähnlich wie Ein Oracle Linux 8 Basis System als Grundlagen für eine Oracle Datenbank Installation vorbereiten.
Netzwerk Konfigurieren siehe ⇒ https://docs.oracle.com/en/operating-systems/oracle-linux/9/network/OL9-NETWORK.pdf
Parameter der VM's:
- Primäre Platte (min 10GB, nach der Installation aktuell 3.3GB in Verwendung)
- Daten Platte 20GB (in Produktion dann deutlich größer)
- 4GB Memory
- 2 CPUs
Wir legen erst einen Knoten 1 an, dieser wird geclont und dann angepasst für zwei gleiche Systeme.
System konfigurieren
IP Adresse setzen
#Status nmcli #setzen nmtui
Name der Maschine setzen
Name der Maschine auf eine eindeutigen Namen für den Knoten 1 setzen
vi /etc/hostname goldgatefs-a.pipperr.local hostname goldgatefs-a.pipperr.local
Was für eine Maschine haben wir:
hostnamectl
Static hostname: goldgatefs-a.pipperr.local
Transient hostname: goldgatefs-a.pipperr.local
Icon name: computer-vm
Chassis: vm
Machine ID: b164d7c8458943129cd8d467e2307f8a
Boot ID: 7ffd0599f643448c811d19e8e1985855
Virtualization: vmware
Operating System: Oracle Linux Server 9.5
CPE OS Name: cpe:/o:oracle:linux:9:5:server
Kernel: Linux 5.15.0-306.177.4.1.el9uek.x86_64
Architecture: x86-64
Hardware Vendor: VMware, Inc.
Hardware Model: VMware Virtual Platform
Firmware Version: 6.00
Repos hinzufügen
Passendes ol9 Repository hinzufügen:
dnf config-manager --enable ol9_appstream
CentOS Repo zusätzlich hinzufügen, da Gluster nur in Linux 8 enthalten ist:
vi /etc/yum.repos.d/CentOS-Gluster11.repo [gluster11] name=Gluster 11 baseurl=https://mirror.stream.centos.org/SIGs/9-stream/storage/x86_64/gluster-11 gpgcheck=1 gpgkey=https://centos.org/keys/RPM-GPG-KEY-CentOS-SIG-Storage enabled=1
System aktualisieren
dnf update reboot
glusterfs Software installieren
#Server dnf install glusterfs-server #Client dnf install glusterfs glusterfs-fuse
Zeit Konfiguration
Sicherstellen das auf beiden Server die gleiche Uhrzeit auf die Sekunde genau eingerichtet ist!
Dazu Crony aktiveren ⇒ https://docs.oracle.com/en/learn/ol-chrony/#introduction und https://docs.oracle.com/en/operating-systems/oracle-linux/8/network/network-ConfiguringNetworkTime.html#ol-nettime-chrony-config
#prüfen timedatectl #Hardware Zeit übernehmen hwclock -w # Crony instalieren dnf list chrony dnf install chrony -y systemctl enable chronyd systemctl start chronyd systemctl status chronyd #prüfen chronyc -n tracking chronyc -n sources -v
in der „/etc/chrony.conf“ eine pool wie https://www.ntppool.org/en/zone/de „pool 0.de.pool.ntp.org“ für die entsprechende Gegend eintragen und chrony Service neu starten.
FW einrichten / ausschalten
Prüfen ob die FW aktiv ist:
firewall-cmd --state
not running
Falls Aktiv, die FW entsprechend konfigurieren oder deaktivieren falls das möglich ist.
Platte zur Verfügung stellen
In unseren Fall haben wir eine eigene Platte konfiguriert, „nvme0n2“ mit 20G zum testen.
Es wird das XFS Dateisystem für den „backend brick“ verwendet, Gluster kann aber mit jedem Filesystem mit „extended attributes“ umgehen.
lsblk .. nvme0n2 259:3 0 20G 0 disk -- #Partition anlegen fdisk /dev/nvme0n2 lsblk nvme0n2 259:3 0 20G 0 disk └─nvme0n2p1 259:5 0 20G 0 part #Dateisystem anlegen mkfs.xfs -i size=512 /dev/nvme0n2p1 #Mounten nach /data/glusterfs mkdir -p /data/brick1 echo '/dev/nvme0n2p1 /data/glusterfs xfs defaults 1 2' >> /etc/fstab mount -a && mount cd /data/glusterfs/ df . -h Filesystem Size Used Avail Use% Mounted on /dev/nvme0n2p1 20G 175M 20G 1% /data/brick1
Produktiv ist es dann besser die Platte über einen Volumen Manager anzulegen und zu verwalten um es später leichter vergrößern zu können, siehe dazu ⇒ LVM Filesystem xfs für die Datenbank anlegen und erweitern.
Clone erzeugen
Maschine herunterfahren und Clonen
init 0
Nur den Clone starten, IP Adresse und Server Name ändern, bestehende Maschine wieder starten, nun stehen uns zwei Maschinen mit je einer eigenen Daten Platte zur Verfügung für die nächsten Schritte.
Beide Maschinen starten und prüfen
Wir haben nun zwei gleiche Maschinen, bis auf die IP Adresse und den Hostnamen stimmen diese komplett überein.
Prüfen ob sich die beiden Maschinen untereinander auch über den Hostnamen erreichen lassen!
Auf jeder Maschine prüfen:
ping goldgatefs-b ping goldgatefs-a
Basis Konfiguration des Clusters
Start des "GlusterFS management daemon" auf beiden Servern
Auf beiden Servern!:
systemctl enable glusterd
systemctl start glusterd
systemctl status glusterd
Trusted Storage Pool anlegen
Auf dem Knote 1 - goldgatefs-a
gluster peer probe goldgatefs-b peer probe: success
Der Knoten auf dem der Befehlt gestartet wird, wird automatisch mit aufgenommen.
Prüfen:
gluster peer status Number of Peers: 1 Hostname: goldgatefs-b Uuid: 417179f6-af50-46a2-b888-8c45b64d5f52 State: Peer in Cluster (Connected)
Wer ist im Pool über Knoten B prüfen:
gluster pool list UUID Hostname State 18550c85-c387-49f0-baa6-9b0a1665de33 goldgatefs-a.pipperr.local Connected 417179f6-af50-46a2-b888-8c45b64d5f52 localhost Connected
Das Volumen anlegen
Für unseren Anwendungsfall wollen wir ein „Replicated Volume“ anlegen, je eine Kopie der Datei auf einen der Server, also ein Virtual Raid 1.
Aus der Oracle Doku: The generally accepted naming convention for creating bricks and volumes is: /data/glusterfs/volume_name/brick_name/brick In this example, volume_name is the file system that can be mounted from a client.
auf beiden Knoten:
mkdir -p /data/glusterfs/goldengateFS/GGFSbrick/brick
Anlegen mit:
gluster volume create goldengateFS replica 2 goldgatefs-{a,b}:/data/glusterfs/goldengateFS/GGFSbrick/brick Do you still want to continue? (y/n) y volume create: goldengateFS: success: please start the volume to access data
Mount Name ist damit goldengateFS
Starten:
gluster volume start goldengateFS volume start: goldengateFS : success
Status:
gluster volume info Volume Name: goldengateFS Type: Replicate Volume ID: 9f7bbe29-da8a-41b1-891c-c72500f0afe0 Status: Started Snapshot Count: 0 Number of Bricks: 1 x 2 = 2 Transport-type: tcp Bricks: Brick1: goldgatefs-a:/data/glusterfs/goldengateFS/GGFSbrick/brick Brick2: goldgatefs-b:/data/glusterfs/goldengateFS/GGFSbrick/brick Options Reconfigured: cluster.granular-entry-heal: on storage.fips-mode-rchecksum: on transport.address-family: inet nfs.disable: on performance.client-io-threads: off
Auf das Datei System vom Client zugreifen
Das unser Client eine Oracle Linux Maschine ist, verwenden wir direkt den Nativ Client.
Gluster Native Client (FUSE)
Software auf dem Client installieren:
dnf install glusterfs glusterfs-fuse
Mount Point anlegen:
# mkdir /gluster-storage-GGFS # Rechte für alle vergeben chmod 777 /gluster-storage-GGFS
Mounten:
mount -t glusterfs goldgatefs-a:goldengateFS /gluster-storage-GGFS
In der fstab hinterlegen:
goldgatefs-a:/goldengateFS /gluster-storage-GGFS glusterfs defaults,_netdev 0 0
siehe auch ⇒ https://docs.gluster.org/en/v3/Administrator%20Guide/Setting%20Up%20Clients/
Test des Filesystems
Ein einfaches Schreiben auf das Volumen zeigt die gewünschte Funktionalität.
Auf den Client :
cd /gluster-storage-GGFS touch testFile_{0..9}.test
Auslesen auf beiden Servern:
cd /data/glusterfs/goldengateFS/GGFSbrick/brick ls -la
Was ist nun alles zu testen:
- Performance
- Verhalten beim Ausfall Netzwerk zwischen den Zonen
- Synchronisieren sich die Bricks des Volumens nach einem Shutdown einer Maschine wieder automatisch?
Test Performance
Siehe dazu https://docs.gluster.org/en/main/Administrator-Guide/Performance-Testing/ und https://docs.gluster.org/en/v3/Administrator%20Guide/Performance%20Testing/ .
Tools:
dnf install nmon
Ablauf:
- Schreiben von 512kB an Daten auf dem Client mit flag oflag=dsync um lokale Cache Effekte zu vermeiden
- Schreiben von 512kB auf einer lokalen Disk auf dem Server
Client:
[root@podman23ai gluster-storage-GGFS]# dd if=/dev/zero of=/gluster-storage-GGFS/test2.img bs=512 count=1000 oflag=dsync 1000+0 records in 1000+0 records out 512000 bytes (512 kB, 500 KiB) copied, 2.19791 s, 233 kB/s #Dauer test mit: watch dd if=/dev/zero of=/gluster-storage-GGFS/test2.img bs=512 count=1000 oflag=dsync
Was kann die Maschine nativ? Auf Knoten A auf dem Host Filesystem, also ohne Cluster
dd if=/dev/zero of=/tmp/test2.img bs=512 count=1000 oflag=dsync 1000+0 records in 1000+0 records out 512000 bytes (512 kB, 500 KiB) copied, 0.245678 s, 2.1 MB/s
Nativ kann ich in meiner Umgebung auf der VM zwischen 1.8 MB/s und 2.3 MB/s schreiben, über das Gluster Filesystem liegen das System bei ~230 KB/s, d.h fast um den Faktor 10 langsamer!
Was lässt sich hier optimieren? siehe https://docs.gluster.org/en/main/Administrator-Guide/Performance-Tuning/
Einfluss Cache Size :
gluster volume get goldengateFS cache-size Option Value ------ ----- performance.cache-size 32MB (DEFAULT) gluster volume set goldengateFS cache-size 128MB volume set: success
Mit obigen Test Wenig Veränderung.
Profiling
gluster volume profile goldengateFS start
gluster volume profile goldengateFS info
#Auswerten
gluster volume profile goldengateFS stop
siehe ⇒ https://docs.gluster.org/en/main/Administrator-Guide/Monitoring-Workload/#start-profiling
Verhalten beim Ausfall eines Knoten
Ablauf:
- Knoten B Herunterfahren
init 0 - Über Client daten Schreiben
touch Sync_testFile_{0..9}.test
- Auf Knoten A prüfen ob die Daten da sind
ls Sync_testFile_* | wc -l 10
- Knoten B starten
- Auf Knoten B prüfen ob die Daten auftauchen
cd /data/glusterfs/goldengateFS/GGFSbrick/brick ls Sync_testFile_* | wc -l 10
Die Daten werden, nach dem der Knoten wieder da ist, synchronisiert.
Überwachen des gluster Filesystems
Was sollte überwacht werden:
- Daemons läuft
- Anzahl der online bricks
- Disk Space
- Healing Status
Status überwachen mit gluster volume heal:
gluster volume heal goldengateFS info Brick goldgatefs-a:/data/glusterfs/goldengateFS/GGFSbrick/brick Status: Connected Number of entries: 0 Brick goldgatefs-b:/data/glusterfs/goldengateFS/GGFSbrick/brick Status: Connected Number of entries: 0 # Auf Probleme abfragen: gluster volume heal goldengateFS info | grep entries | sort | uniq -c 2 Number of entries: 0
# Was haben wir hier auf der Maschine gluster volume status all Status of volume: goldengateFS Gluster process TCP Port RDMA Port Online Pid ------------------------------------------------------------------------------ Brick goldgatefs-a:/data/glusterfs/goldenga teFS/GGFSbrick/brick 50551 0 Y 5517 Brick goldgatefs-b:/data/glusterfs/goldenga teFS/GGFSbrick/brick 52185 0 Y 911 Self-heal Daemon on localhost N/A N/A Y 5533 Self-heal Daemon on goldgatefs-b N/A N/A Y 980 Task Status of Volume goldengateFS ------------------------------------------------------------------------------ There are no active volume tasks #Dateils gluster volume status goldengateFS detail Status of volume: goldengateFS ------------------------------------------------------------------------------ Brick : Brick goldgatefs-a:/data/glusterfs/goldengateFS/GGFSbrick/brick TCP Port : 50551 RDMA Port : 0 Online : Y Pid : 5517 File System : xfs Device : /dev/nvme0n2p1 Mount Options : rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota Inode Size : 512 Disk Space Free : 19.8GB Total Disk Space : 19.9GB Inode Count : 10485248 Free Inodes : 10484912 ------------------------------------------------------------------------------ Brick : Brick goldgatefs-b:/data/glusterfs/goldengateFS/GGFSbrick/brick TCP Port : 52185 RDMA Port : 0 Online : Y Pid : 911 File System : xfs Device : /dev/nvme0n2p1 Mount Options : rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota Inode Size : 512 Disk Space Free : 19.8GB Total Disk Space : 19.9GB Inode Count : 10485248 Free Inodes : 10484915 # Wer nützt das Cluster gluster volume status goldengateFS clients Client connections for volume goldengateFS ---------------------------------------------- Brick : goldgatefs-a:/data/glusterfs/goldengateFS/GGFSbrick/brick Clients connected : 4 Hostname BytesRead BytesWritten OpVersion -------- --------- ------------ --------- 10.10.10.111:49149 139380 671656 110000 10.10.10.111:49139 3056 3132 110000 10.10.10.118:1014 98099528 84912480 70100 10.10.10.112:49149 1756 1828 110000 ---------------------------------------------- Brick : goldgatefs-b:/data/glusterfs/goldengateFS/GGFSbrick/brick Clients connected : 4 Hostname BytesRead BytesWritten OpVersion -------- --------- ------------ --------- 10.10.10.111:49143 2860 2748 110000 10.10.10.111:49142 514112 4808 110000 10.10.10.118:1021 1020 468 70100 10.10.10.112:49146 11984 13612 110000 ----------------------------------------------
siehe auch dazu ⇒ https://docs.redhat.com/en/documentation/red_hat_gluster_storage/3/html/administration_guide/displaying_volume_status
Mit etwas Skripting kann das ein Check für den OEM aus den Infos erstellt werden.
Tools dazu:
Fazit
Auf den ersten Blick ist die für den Anwendungsfall notwendige Funktionalität gegeben.
Nun muss in der Oracle Cloud Umgebung das gleiche aufgesetzt und getestet werden ob die Performance am Ende ausreicht.
Ein einfacher dd Test hat zwar in der Notebook Umgebung nicht so recht performed ist aber am Ende auch nicht aussagekräftig genug für das Golden Gate Schreib/Lese Verhalten.
