Tidligere skrev vi om opsætning af en geo-distribueret databaseklynge ved hjælp af MySQL-replikering. Denne gang handler det om PostgreSQL. Opsætning af en geo-distribueret klynge til PostgreSQL er ikke et nyt koncept, og topologien er ret almindelig.
For at opnå høj tilgængelighed spreder organisationer og virksomheder deres databasenoder, så når en katastrofal hændelse sker i en bestemt region (som påvirker dit datacenter), har du dine standby-knudepunkter til rådighed for failover.
Dette er en meget almindelig praksis (ved at bruge denne type topologi) som en del af din organisations Business Continuity og Disaster Recovery-planer. Denne type topologi fjerner at have et enkelt fejlpunkt (SPOF). Et almindeligt krav, især hvis du har en lav RPO og en højere oppetid (hvis muligt på 99,999999999%).
I denne blog vil jeg tage en simpel implementering af, hvordan man gør dette ved hjælp af ClusterControl. ClusterControl er en agentfri administrations- og automatiseringssoftware til databaseklynger. Det hjælper med at implementere, overvåge, administrere og skalere din databaseserver/-klynge direkte fra ClusterControl-brugergrænsefladen.
Den ønskede arkitektoniske opsætning
Målresultatet her er at implementere effektivt i et sikkert miljø. For at gøre dette er det vigtigt, at du skal placere din etablerede forbindelse mellem brug af VPN og ville være mere sikker, hvis du også opsætter dine databasenoder over TLS/SSL-forbindelse. Til denne opsætning i vores blog installerer vi simpelthen en node over en VPN og viser dig, hvordan du nemt kan gøre denne tilgang. Se nedenfor for diagrammet over målopsætningen:
For at uddybe opsætningen skal det lokale netværk kommunikere over det offentlige sky ved hjælp af en VPN-tunnel, og begge disse netværk skal have en VPN-gateway, så begge kan kommunikere eller etablere en forbindelse. ClusterControl kræver, at du overvåger alle de noder, der skal registreres, da det vil indsamle oplysninger om dine noder til datamålinger. Bortset fra det kræver det, at din aktive skribent-knude på stedet også kan nå standby-knuden til det andet domæne, som er til denne blog, hostet i Google Cloud Platform (GCP).
Opsætning af din OpenVPN
Opsætning af OpenVPN er meget vanskelig for begge netværksdomæner. Kernen i dette er, at det skal tage følgende hensyn:
- Knudepunkter fra din lokale skal være i stand til at etablere en forbindelse til de offentlige skydomæneknudepunkter
- Knudepunkter fra din lokale kan have internetadgang for at downloade pakker, der skal konfigureres. Medmindre du har alle de arkiver gemt lokalt, som er nødvendige, kan dette ikke være tilfældet
- Noder fra dit offentlige cloud-domæne skal være i stand til at etablere en forbindelse til de lokale noder
- Noder fra dit offentlige cloud-domæne kan have internetadgang for at downloade pakker, som er nødvendige for at konfigurere. Medmindre du har alle de arkiver gemt lokalt, som er nødvendige, kan dette ikke være tilfældet
OpenVPN-installation og -konfiguration
Trin 1
Installer openvpn-pakken (og easy-rsa-pakker til Ubuntu/Debian distros)
$ sudo apt-get install openvpn easy-rsa For CentOS/RHEL-baseret OS,
$ sudo yum install openvpn wget
$ wget -O /tmp/easyrsa https://github.com/OpenVPN/easy-rsa-old/archive/2.3.3.tar.gz Trin to
Generer dine certifikater såsom certificeringsmyndighed (CA), server- og klientcertifikater.
For Ubuntu/Debian kan du udføre følgende handlinger:
$ /usr/bin/make-cadir CA Skift til CA-bibliotek
$ cd CA På dette tidspunkt vil du sandsynligvis redigere vars-filen i overensstemmelse med dine behov, f.eks.
export KEY_COUNTRY="SE"
export KEY_PROVINCE="SMD"
export KEY_CITY="Kalmar"
export KEY_ORG="Severalnines"
export KEY_EMAIL="[email protected]"
export KEY_CN="S9s"
export KEY_NAME="server"
export KEY_OU="Support Unit" Udfør derefter vars-scriptet for at definere de nødvendige env-variabler
[ ~/CA ]$ source ./vars
NOTE: If you run ./clean-all, I will be doing a rm -rf on /CA/keys Kør en oprydning
[ ~/CA ]$ ./clean-all Byg derefter certifikaterne til din CA, server og klient.
[ ~/CA ]$ ./build-ca
[ ~/CA ]$ ./build-key-server server
$ ./build-dh 2048
[ ~/CA ]$ ./build-key client Generer endelig en Perfect Forward Secrecy-nøgle.
$ openvpn --genkey --secret pfs.key Hvis du bruger CentOS/RHEL-type distros, kan du gøre følgende:
$ tar xfz /tmp/easyrsa
$ sudo mkdir /etc/openvpn/easy-rsa
$ sudo cp -rf easy-rsa-old-2.3.3/easy-rsa/2.0/* /etc/openvpn/easy-rsa # Sørg for, at dine RSA-nøgler er på den rigtige tilladelse af sikkerhedsmæssige årsager
$ sudo chown vagrant /etc/openvpn/easy-rsa/
$ sudo cp /usr/share/doc/openvpn-2.4.4/sample/sample-config-files/server.conf /etc/openvpn
$ sudo mkdir /etc/openvpn/easy-rsa/keys
$ sudo nano /etc/openvpn/easy-rsa/vars
$ cd /etc/openvpn/easy-rsa På dette tidspunkt vil du sandsynligvis redigere vars-filen i overensstemmelse med dine behov, f.eks.
export KEY_COUNTRY="SE"
export KEY_PROVINCE="SMD"
export KEY_CITY="Kalmar"
export KEY_ORG="Severalnines"
export KEY_EMAIL="[email protected]"
export KEY_CN="S9s"
export KEY_NAME="server"
export KEY_OU="Support Unit" Udfør derefter vars-scriptet for at definere de nødvendige env-variabler
$ source ./vars
NOTE: If you run ./clean-all, I will be doing a rm -rf on /CA/keys Kør en oprydning
$ ./clean-all Byg derefter certifikaterne til din CA, server og klient.
$ ./build-ca
$ ./build-key-server server
$ ./build-dh 2048
$ cd /etc/openvpn/easy-rsa
$ ./build-key client
$ cp /etc/openvpn/easy-rsa/openssl-1.0.0.cnf /etc/openvpn/easy-rsa/openssl.cnf Når du har alle opsætninger, skal du tage højde for, hvor dine nøgler og certifikater er på plads. Hvis du bruger systemd eller service i Linux til at køre dette, kan du placere dine certifikater og nøgler til /etc/openvpn. Sandsynligvis skal du muligvis køre følgende kommando:
sudo cp dh2048.pem ca.crt server.crt server.key /etc/openvpn Trin tre
På dette tidspunkt ender jeg med følgende server- og klientkonfiguration. Se mine konfigurationsfiler i overensstemmelse hermed,
OpenVPN Server Config
$ cat /etc/openvpn/server-ovpn.conf
port 1194
proto udp
dev tun
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key # This file should be kept secret
dh /etc/openvpn/keys/dh2048.pem
cipher AES-256-CBC
auth SHA512
server 10.8.0.0 255.255.255.0
client-to-client
topology subnet
push "route 192.168.30.0 255.255.255.0"
#push "redirect-gateway def1 bypass-dhcp"
#push "redirect-gateway"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
ifconfig-pool-persist ipp.txt
keepalive 10 120
comp-lzo
persist-key
persist-tun
#status openvpn-status.log
#log-append openvpn.log
verb 3
tls-server
tls-auth /etc/openvpn/keys/pfs.key Det vigtigste, du skal tage højde for, er disse følgende muligheder som angivet som følger.
klient-til-klient - Meget vigtigt, så noder i VPN kan pinge de andre noder i forskellige netværksdomæner. Lad os sige, ClusterControl er placeret i on-prem, den kan pinge noderne i GCP.
skub "rute 192.168.30.0 255.255.255.0" - Jeg skubber routingtabellerne, så GCP-noder, der er tilsluttet VPN, kan pinge mine noder i det lokale domæne. I min GCP VPN-gateway har jeg følgende routingtabeller som push "rute 10.142.0.0 255.255.255.0"
#push "redirect-gateway def1 bypass-dhcp" , #push "redirect-gateway" - Begge disse sektioner er ikke nødvendige, da jeg har brug for internetforbindelse for både at konfigurere min repo og afhængige pakker ved installation.
push "dhcp-option DNS 8.8.8.8", push "dhcp-option DNS 8.8.4.4" - Begge disse sektioner kan ændres til din ønskede DNS, hvis det er nødvendigt. Dette er til din ønskede DNS, især når du har brug for internetforbindelse.
OpenVPN Client Config
$ cat openvpn/client-vpn.ovpn
client
dev tun
proto udp
remote 34.73.238.239 1194
ca ca.crt
cert client.crt
key client.key
tls-version-min 1.2
tls-cipher TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256:TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256:TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
cipher AES-256-CBC
auth SHA512
resolv-retry infinite
auth-retry none
nobind
persist-key
persist-tun
ns-cert-type server
comp-lzo
verb 3
tls-client
tls-auth pfs.key
Det vigtigste her er, at du skal være sikker på dine nøglestier og også erstatte parametrene i dette afsnit,
remote 34.73.238.239 1194 som kan være værtsnavnet/IP-adressen på din VPN-servergateway, du skal oprette forbindelse til.
Trin fire
Sæt til sidst proxy VPN-serveren for at få netværkspakkerne dirigeret til netværksgrænsefladen på serveren og tillade kernen at videresende IPV4-trafik
sudo iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
sudo echo 1 > /proc/sys/net/ipv4/ip_forward For mere dybdegående installation foreslår jeg, at du ser på disse indlæg til CentOS og på Ubuntu.
Udvidelse over skyen effektivt
Antag, at du har følgende topologi i dit lokale domæne,
og du vil nu udvide din tilgængelighed over et andet datacenter, som er GCP til denne blog. Implementering ved hjælp af ClusterControl er meget ligetil. Du kan udføre følgende procedure angivet nedenfor,
Trin 1
Opret en slaveklynge
Trin to
Vælg din master til replikering,
Trin tre
Konfigurer adgangen til dit offentlige skymiljø
Trin fire
Angiv værtsnavnet/IP-adressen for din node, der skal udvides til din PG-replikeringsklynge,
Trin fem
Overvåg endelig jobaktiviteten, hvordan reagerer ClusterControl på denne type handling
Resultatet vil vise dig forbindelsen mellem dit on-prem og dit udvidede datacenter, som er i denne blog, vores GCP PostgreSQL standby node. Se nedenfor for resultatet
Konklusion
Det er ikke svært at konfigurere en standby-knude til geografisk placering, men hovedproblemet er, hvor sikkert dette vil være i dit arkitektoniske design. Brug af en VPN kan afhjælpe problemets største bekymring. Brug af OpenVPN er blot en simpel måde at implementere dette på, men for tunge transaktionsapplikationer vil organisationer sandsynligvis investere i opskalere tjenester eller hardware til at håndtere denne opsætning. Også ved at tilføje en TLS/SSL kan det være nemmere end gjort. Vi vil diskutere dette om, hvordan du kan bruge TLS/SSL med PostgreSQL i vores næste blogs.