Vi har allerede dækket nogle teorier om konfiguration af Always ON Availability Groups til Linux-baserede SQL-servere. Den aktuelle artikel vil fokusere på praksis.
Vi vil præsentere trin-for-trin processen med at konfigurere SQL Server Always ON Availability Groups mellem to synkrone replikaer. Vi vil også fremhæve brugen af replikaen, der kun er til konfiguration, til at udføre automatisk failover.
Før vi starter, vil jeg anbefale dig at henvise til den tidligere artikel og genopfriske din viden.
Nedenstående designdiagram viser den synkrone replika med to knudepunkter og en replika, der kun er til konfiguration, og som hjælper os med at sikre automatisk failover og databeskyttelse.
Vi udforskede dette design i den tidligere nævnte artikel, så se venligst til det for information, før vi går videre til praktiske opgaver.
Installer SQL Server på Ubuntu-systemer
Ovenstående designdiagram nævner 3 Ubuntu-systemer – aoagvm1 , aoagvm2 , og aoagvm3 med SQL Server-instanserne installeret. Se vejledningen om installation af SQL Server på Ubuntu – eksemplet vedrører SQL Server 2019 på Ubuntu 18.04-systemet. Du kan gå videre og installere SQL Server 2019 på alle 3 noder (sørg for at installere den samme build-version).
For at spare licensomkostninger kan du installere SQL Server Express-udgaven til den tredje node replika. Denne vil fungere som en replika, der kun er til konfiguration uden at være vært for nogen tilgængelighedsdatabaser.
Når SQL Server er installeret på alle 3 noder, kan vi konfigurere tilgængelighedsgruppen mellem dem.
Konfigurer tilgængelighedsgrupper mellem tre noder
Før du går videre, valider dit miljø:
- Sørg for, at der er kommunikation mellem alle 3 noder.
- Tjek og opdater computernavnet for hver vært ved at køre kommandoen sudo vi /etc/hostname
- Opdater værtsfilen med IP-adresse og nodenavne for hver node. Du kan bruge kommandoen sudo vi /etc/hosts for at få dette gjort
- Sørg for, at du har alle forekomster, der kører ud over SQL Server 2017 CU1, hvis du ikke bruger SQL Server 2019
Lad os nu begynde at konfigurere SQL Server Always ON Availability Group mellem 3-noder. Vi skal aktivere funktionen Tilgængelighedsgruppe på alle 3 noder.
Kør nedenstående kommando (bemærk, at du skal genstarte SQL Server-tjenesten efter denne handling):
--Aktiver tilgængelighedsgruppefunktionerudo /opt/mssql/bin/mssql-conf set hadr.hadrenabled 1--Genstart SQL Server servicesudo systemctl genstart mssql-server Jeg har udført ovenstående kommando på den primære node. Det skal gentages for de resterende to noder.
Outputtet er nedenfor – indtast brugernavn og adgangskode, når du bliver bedt om det.
[email protected]:~$ sudo /opt/mssql/bin/mssql-conf set hadr.hadrenabled 1SQL Server skal genstartes for at anvende denne indstilling. Kør venligst'systemctl genstart mssql-server.service'[email protected]:~$ systemctl genstart mssql-server====GODKENDELSE FOR org.freedesktop.systemd1.manage-units ===Autentificering er påkrævet for at genstarte 'mssql -server.service'.Godkender som:Ubuntu (aoagvm1)Adgangskode: Det næste trin er at aktivere Always ON udvidede begivenheder for hver SQL Server-instans. Selvom dette er et valgfrit trin, skal du aktivere det for at fejlfinde eventuelle problemer, der måtte komme senere. Opret forbindelse til SQL Server-instansen ved hjælp af SQLCMD og kør kommandoen nedenfor:
--Opret forbindelse til den lokale SQL Server-instans ved hjælp af sqlcmdsqlcmd -S localhost -U SA -P 'C0de!n$!ght$'GoALTER EVENT SESSION AlwaysOn_health PÅ SERVER MED (STARTUP_STATE=ON);Go Outputtet er nedenfor:
[email protected]:~$ sqlcmd -S localhost -U SA -P 'C0de!n$!ght$'1>ALTER EVENT SESSION AlwaysOn_health PÅ SERVER MED (STARTUP_STATE=ON);2>GO1> Når du har aktiveret denne indstilling på den primære replikaknude, skal du gøre det samme for de resterende aoagvm2- og aoagvm3-noder.
SQL Server-instanserne, der kører på Linux, bruger certifikater til at godkende kommunikation mellem spejlingsendepunkterne. Så den næste mulighed er at oprette certifikatet på den primære replika aoagvm1 .
Først opretter vi en hovednøgle og et certifikat. Derefter sikkerhedskopierer vi dette certifikat i en fil og sikrer filen med en privat nøgle. Kør nedenstående T-SQL-script på den primære replikaknude:
--Opret forbindelse til den lokale SQL Server-instans ved hjælp af sqlcmdsqlcmd -S localhost -U SA -P 'C0de!n$!ght$'--Konfigurer certifikaterCREATE MASTER KEY KRYPTERING VED PASSWORD ='[email protected] $terKEY';CREATE CERTIFICATE dbm_certificate WITH SUBJECT ='dbm';BACKUP CERTIFICATE dbm_certificate TO FILE ='/var/opt/mssql/data/dbm_certificate.cer'WITH PRIVATE NØGLE (FILE ='/varql/data/ms dbm_certificate.pvk',KRYPTERING AF PASSWORD ='[email protected]'); Udgangen:
[email protected]:~$ sqlcmd -S localhost -U SA -P 'C0de!n$!ght$'1>OPRET MASTER NØGLEKRYPTERING VED ADGANGSKODE ='[email protected]$terKEY';2>OPRET CERTIFIKAT dbm_certifikat MED SUBJECT ='dbm';3>GO1>BACKUP CERTIFIKAT dbm_certifikat TIL FIL ='/var/opt/mssql/data/dbm_certificate.cer'2>Med PRIVAT NØGLE (FIL ='/var /mssql/data/dbm_certificate.pvk',KRYPTERING MED PASSWORD ='[email protected]');3>GO1> Den primære replikaknude har nu to nye filer. Den ene er certifikatfilen dbm_certificate.cer og den private nøglefil dbm_certificate.pvk på /var/opt/mssql/data/ placering.
Kopier ovenstående to filer til den samme placering på de resterende to noder (AOAGVM2 og AOAGVM3), som vil deltage i Availability Group-konfigurationen. Du kan bruge SCP-kommandoen eller et hvilket som helst tredjepartsværktøj til at kopiere disse to filer til målserveren.
Når filerne er kopieret til de resterende to noder, tildeler vi tilladelser til mssql bruger til at få adgang til disse filer på alle 3 noder. For det, kør nedenstående kommando og kør den derefter for den 3. node aoagvm3 også:
--Kopiér filer til aoagvm2 nodecd /var/opt/mssql/datascp dbm_certificate.* [email protected]:var/opt/mssql/data/--Giv tilladelse til brugeren mssql til at få adgang til begge nyoprettede filescd /var/opt/mssql/datachown mssql:mssql dbm_certificate.* Vi vil oprette hovednøglen og certifikatfilerne ved hjælp af ovenstående to kopierede filer på de resterende to noder aoagvm2 og aoagvm3 . Kør nedenstående kommando på disse to noder for at oprette hovednøglen :
--Opret hovednøgle og certifikat på resterende to noder OPRET MASTER NØGLEKRYPTERING VED PASSWORD ='[email protected]$terKEY';OPRET CERTIFIKAT dbm_certificate FRA FIL ='/var/opt/mssql/data/dbm_certificate .cer' MED PRIVAT NØGLE (FIL ='/var/opt/mssql/data/dbm_certificate.pvk', DECRYPTION BY PASSWORD ='[email protected]'); Jeg har udført ovenstående kommando på den anden node aoagvm2 for at oprette hovednøglen og certifikat . Tag et kig på udførelsesoutputtet. Sørg for at bruge de samme adgangskoder, som når du opretter og sikkerhedskopierer certifikatet og hovednøglen.
[email protected]:~$ sqlcmd -S localhost -U SA -P 'C0de!n$!ght$'1>OPRET MASTER NØGLEKRYPTERING VED ADGANGSKODE ='[email protected]$terKEY';2>OPRET CERTIFIKAT dbm_certificate3>FRA FIL ='/var/opt/mssql/data/dbm_certificate.cer'4> MED PRIVAT NØGLE (FIL ='/var/opt/mssql/data/dbm_certificate.pvk', PASSWORD ='[email protected]');5>GO1> Kør kommandoen ovenfor på AOAGVM3 node også.
Nu konfigurerer vi databasespejlingsendepunkter - tidligere har vi oprettet certifikater til dem. Spejlingsendepunktet med navnet hadr_endpoint skal være på alle 3 noder i henhold til deres respektive rolletype.
Som tilgængelighed hostes databaser kun på 2 noder aoagvm1 og aoagvm2, vi kører kun sætningen nedenfor på disse noder. Den tredje node vil fungere som et vidne – så vi vil bare ændre ROLE at vidne i nedenstående script, og kør derefter T-SQL til den tredje node aoagvm3 . Scriptet er:
--Konfigurer databasespejlingslutpunkt Hadr_endpoint på noderne aoagvm1 og aoagvm2CREATE ENDPOINT [Hadr_endpoint] AS TCP (LISTENER_PORT =5022) FOR DATABASE_MIRRORING (ROLE =ALL, AUTHENTICATION =AUTENTICATION =EN_EN_EQRIFICATE-AUTENTICATION =EN_EQRIFICATE-ENKEL; Start det nyoprettede slutpunktALTER ENDPOINT [Hadr_endpoint] STATE =STARTED; Her er outputtet af ovenstående kommando på den primære replikaknude. Jeg har oprettet forbindelse til sqlcmd og udførte det. Sørg for at gøre det samme på den 2. replikaknude aoagvm2 også.
[email protected]:~$ sqlcmd -S localhost -U SA -P 'C0de!n$!ght$'1>OPRET ENDPOINT [Hadr_endpoint]2>AS TCP (LISTENER_PORT =5022)3> FOR DATABASE_MIRRORING (ROLE =ALLE, GODKENDELSE =CERTIFIKAT dbm_certificate, ENCRYPTION =PÅKRÆVET ALGORITHME AES);4>Go1>ALTER ENDPOINT [Hadr_endpoint] STATE =STARTET;2>Go1> Når du har udført ovenstående T-SQL-script på de første 2 noder, skal vi ændre det for den tredje node – skift ROLLEN til WITNESS.
Kør nedenstående script for at oprette databasespejlingsendepunktet på vidne-noden AOAGVM3 . Hvis du vil være vært for tilgængelighedsdatabaser der, skal du også køre ovenstående kommando på 3 replika-noden. Men sørg for at du har installeret den rigtige udgave af SQL Server for at opnå denne funktion.
Hvis du installerede SQL Server Express-udgaven på noden 3 for at implementere kun konfiguration replika , kan du kun konfigurere ROLE som vidne for denne node:
--Opret forbindelse til den lokale SQL Server-instans ved hjælp af sqlcmdsqlcmd -S localhost -U SA -P 'C0de!n$!ght$'----Konfigurer databasespejlingslutpunkt Hadr_endpoint på 3. node aoagvm3CREATE ENDPOINT [Hadr_endpoint ] AS TCP (LISTENER_PORT =5022) FOR DATABASE_MIRRORING (ROLE =VIDNE, AUTHENTICATION =CERTIFICATE dbm_certificate, ENCRYPTION =PÅKRÆVET ALGORITHME AES);--Start det nyoprettede slutpunkt på aoagvm3ALTER STARTPUNKT]
Nu skal vi oprette tilgængelighedsgruppen med navnet ag1 .
Opret forbindelse til SQL Server-instansen ved hjælp af sqlcmd og kør nedenstående kommando på den primære replikaknude aoagvm1 :
--Opret forbindelse til den lokale SQL Server-instans ved hjælp af sqlcmd hostet på den primære replikaknude aoagvm1sqlcmd -S localhost -U SA -P 'C0de!n$!ght$'--Opret tilgængelighedsgruppe ag1CREATE AVAILABILITY GROUP [ag1 ] WITH (CLUSTER_TYPE =EXTERNAL) FOR REPLIKA PÅ N'aoagvm1' WITH (ENDPOINT_URL =N'tcp://aoagvm1:5022', AVAILABILITY_MODE =SYNCHRONOUS_COMMIT, FAILOVER_MODE =SEEDMATING_MODE,' WITH EXTERNAL) N'tcp://aoagvm2:5022', AVAILABILITY_MODE =SYNCHRONOUS_COMMIT, FAILOVER_MODE =EKSTERN, SEEDING_MODE =AUTOMATISK), N'aoagvm3' MED (ENDPOINT_URL =N'tcp://aoagvm2'. Tildel påkrævet tilladelseALTER TILGÆNGELIGHEDSGRUPPE [ag1] GIV OPRET ENHVER DATABASE;
Ovenstående script konfigurerer Availability Group-replikaer med nedenstående konfigurationsparametre (vi har lige brugt dem i T-SQL-scriptet):
- CLUSTER_TYPE =EKSTERN fordi vi konfigurerer tilgængelighedsgruppe på Linux-baserede SQL Server-installationer
- SEEDING_MODE =AUTOMATISK får SQL Server til automatisk at oprette en database på hver sekundær replika. Tilgængelighedsdatabaser vil ikke blive oprettet på replikaer, der kun er til konfiguration
- FAILOVER_MODE =EKSTERN for både primære og sekundære replikaer. det betyder, at replikaen interagerer med en ekstern cluster ressource manager, såsom Pacemaker
- AVAILABILITY_MODE =SYNCHRONOUS_COMMIT for primære og sekundære replikaer til automatisk failover
- AVAILABILITY_MODE =CONFIGURATION_ONLY for 3. replika, der fungerer som en konfigurationsreplika
Vi skal også oprette et Pacemaker-login på alle SQL Server-instanser. Denne bruger skal tildeles ALTER , KONTROL og VIS DEFINITION tilladelser på tilgængelighedsgruppen på alle replikaer. For at give tilladelser skal du køre nedenstående T-SQL-script på alle 3 replika-noder med det samme. Først vil vi oprette et Pacemaker-login. Derefter tildeler vi ovenstående tilladelser til det pågældende login.
--Opret pacemaker-login på hver SQL Server-instans. Kør nedenstående kommandoer på alle 3 SQL Server-forekomster CREATE LOGIN pacemaker WITH PASSWORD ='[email protected]@12'--Giv tilladelse til pacemaker-login på nyoprettet tilgængelighedsgruppe. Kør det på alle 3 SQL Server-forekomster. GRANT ÆNDRING, KONTROL, VIS DEFINITION PÅ TILGÆNGELIGHED GRUPPE::ag1 TIL pacemaker. GIV VIS SERVER STATE TIL pacemaker Efter at have tildelt passende tilladelser til Pacemaker-login på alle 3 replikaer, udfører vi nedenstående T-SQL-scripts for at slutte sig til de sekundære replikaer aoagvm2 og aoagvm3 til den nyoprettede tilgængelighedsgruppe ag1 . Kør nedenstående kommandoer på de sekundære replikaer aoagvm2 og aoagvm3 .
--Udfør nedenstående kommandoer på aoagvm2 og aoagvm3 for at deltage i tilgængelighedsgruppen ag1ALTER TILGÆNGELIGHEDSGRUPPE [ag1] JOIN WITH (CLUSTER_TYPE =EXTERNAL); ÆNDRING AF TILGÆNGELIGHED GRUPPE [ag1] TILDELING OPRET ENHVER DATABASE; Nedenfor er outputtet af ovenstående eksekveringer på node aoagvm2 . Sørg for at køre det på aoagvm3 node også.
[email protected]:~$ sqlcmd -S localhost -U SA -P 'C0de!n$!ght$'1>ÆNDRE TILGÆNGELIGHEDSGRUPPE [ag1] JOIN MED (CLUSTER_TYPE =EKSTERN);2> Gå 1>ÆNDRING AF TILGÆNGELIGHEDSGRUPPE [ag1] GIV OPRET ENHVER DATABASE;2>Go1> Derfor har vi konfigureret tilgængelighedsgruppen. Nu skal vi tilføje en bruger eller en testdatabase til denne tilgængelighedsgruppe. Hvis du allerede har oprettet en brugerdatabase på den primære node-replika, skal du bare køre en fuld sikkerhedskopi og derefter lade den automatiske seeding gendanne den på den sekundære node.
Kør derfor nedenstående kommando:
--Kør en komplet sikkerhedskopi af testdatabasen eller brugerdatabasen hostet på den primære replika aoagvm1BACKUP DATABASE [Test] TIL DISK =N'/var/opt/mssql/data/Test_15June.bak'; Lad os tilføje denne database Test til tilgængelighedsgruppen ag1 . Kør nedenstående T-SQL-sætning på den primære node aoagvm1 . Du kan bruge sqlcmd værktøj til at køre T-SQL-sætninger.
--Tilføj brugerdatabase eller testdatabase til tilgængelighedsgruppen ag1ALTER AVAILABILITY GROUP [ag1] TILFØJ DATABASE [Test]; Du kan verificere brugerdatabasen eller en testdatabase, som du har føjet til Availability Group, ved at se på den sekundære SQL Server-instans, uanset om den er oprettet på sekundære replikaer eller ej. Du kan enten bruge SQL Server Management Studio eller køre en simpel T-SQL-sætning for at hente detaljerne om denne database.
--Bekræft, at testdatabasen er oprettet på en sekundær replika eller ej. Kør det på sekundær replika aoagvm2.SELECT * FROM sys.databases WHERE name ='Test';GO Du får testen database oprettet på den sekundære replika.
Med ovenstående trin er AlwaysOn Availability Group blevet konfigureret mellem alle tre noder. Disse noder er dog endnu ikke klynget. Vores næste trin er at installere Pacemakeren klynge på dem. Så tilføjer vi tilgængelighedsgruppen ag1 som en ressource til den klynge.
PACEMAKER-klyngekonfiguration mellem tre noder
Så vi vil bruge en ekstern cluster ressource manager PACEMAKER mellem alle 3 noder til klyngeunderstøttelse. Lad os starte med at aktivere firewall-portene mellem alle 3 noder.
Åbn firewall-porte ved at bruge nedenstående kommando:
--Kør nedenstående kommandoer på alle 3 noder for at åbne Firewall Portssudo ufw tillad 2224/tcpsudo ufw tillad 3121/tcpsudo ufw tillad 21064/tcpsudo ufw tillad 5405/udpsudo ufw tillad 1433/uftc tillad 1433/uftw tillad 1433/uftw ufw reload--Hvis du ikke ønsker at åbne specifikke firewall-porte, kan du alternativt deaktivere firewallen på alle 3 noder ved at køre kommandoen nedenfor (DETTE ER ALTERNATIV OG VALGFRI TILGANG) sudo ufw disable Se outputtet – denne er fra den primære replika AOAGVM1 . Du skal udføre ovenstående kommandoer på alle tre noder, én efter én. Outputtet skal være ens.
[email protected]:~$ sudo ufw tillade 2224/tcpRegler opdateretRegler opdateret (v6)[email protected]:~$ sudo ufw tillade 3121/tcpRegler opdateredeRegler opdateret (v6)[email protected]:~$ sudo ufw tillade 21064/tcpRegler opdateretRegler opdateret (v6)[email protected]:~$ sudo ufw tillade 5405/udpRegler opdateretRegler opdateret (v6)[email protected]:~$ sudo ufw opdatering tillader 143 ufw opdatering tcpR3s )[email protected]:~$ sudo ufw tillade 5022/tcpRules updatedRegler opdateret (v6)[email protected]:~$ sudo ufw reloadFirewall ikke aktiveret (springer genindlæsning over) Installer Pacemaker og corosync pakker på alle 3 noder. Kør nedenstående kommando på hver node – den vil konfigurere Pacemaker , corosync og hegnmiddel .
--Installer Pacemaker-pakker på alle 3 noder aoagvm1, aoagvm2 og aoagvm3 ved at køre nedenstående kommandosudo apt-get install pacemaker pcs fence-agents resource-agents Outputtet er enormt – næsten 20 sider. Jeg har kopieret de første og sidste par linjer for at illustrere det (du kan se alle pakker installeret):
[email protected]:~$ sudo apt-get install pacemaker pcs fence-agents resource-agentsLæser pakkelister... FærdigBygningsafhængighedstræ Læser tilstandsoplysninger... FærdigFølgende ekstra pakker vil blive installeret:cluster- glue corosync fonts-dejavu-core fonts-lato fonts-liberation ibverbs-providers javascript-common libcfg6 libcib4 libcmap4 libcorosync-common4 libcpg4 libcrmcluster4 libcrmcommon3 libcrmservice3 libdbus-glib-1-2 libesmtp6 libibverbs1 libjs-jquery liblrm2 liblrmd1 libnet-telnet-perl libnet1 libnl -3-200 libnl-route-3-200 libnspr4 libnss3 libopenhpi3 libopenipmi0 libpe-rules2 libpe-status10 libpengine10 libpils2 libplumb2 libplumbgpl2 libqb0 libquorum5 librdmacm1 libruby2.5 libsensors4 libsgutils2-2 libsnmp-base libsnmp30 libstatgrab10 libstonith1 libstonithd2 libtimedate-perl libtotem-pg5 libtransitioner2 libvotequorum8 libxml2-utils openhpid pacemaker-cli-utils pacemaker-common pacemaker-resource-agents python-pexpect python-ptyprocess python-py curl python3-bs4 python3-html5lib python3-lxml python3-pycurl python3-webencodings rake ruby ruby-activesupport ruby-atomic ruby-backports ruby-menede-du ruby-ethon ruby-ffi ruby-highline rubin-ruby -mime-typer ruby-mime-typer-data ruby-minitest ruby-multi-json ruby-net-telnet ruby-oj ruby-open4 ruby-power-assert ruby-rack ruby-rack-beskyttelse ruby-rack-test ruby- rpam-ruby19 ruby-sinatra ruby-sinatra-bidrag rubin-test-enhed rubin-tråd-sikker rubin-tilt rubin-tzinfo ruby2.5 rubygems-integration sg3-utils snmp unzip xsltproc zip Foreslåede pakker:ipmitrequestspy-apthons-ap | lighttpd | httpd lm-sensorer snmp-mibs-downloader python-pexpect-doc libcurl4-gnutls-dev python-pycurl-dbg python-pycurl-doc python3-genshi python3-lxml-dbg python-lxml-doc python-b-doc pythonyd3 dev bundlerFølgende NYE pakker vil blive installeret:cluster-lim corosync fence-agents fonts-dejavu-core fonts-lato fonts-liberation ibverbs-providers javascript-common libcfg6 libcib4 libcmap4 libcorosync-common4 libcpg-common4 libcpg-common4 libcpg-common4 libcpg-common4 libcpg-common4 libcpg2 libesmtp6 libibverbs1 libjs-jquery liblrm2 liblrmd1 libnet-telnet-perl libnet1 libnl-3-200 libnl-route-3-200 libnspr4 libnss3 libopenhpi3 libopenipmi0 libpe-rules2 libpe-status10 libpengine10 libpils2 libplumb2 libplumbgpl2 libqb0 libquorum5 librdmacm1 libruby2.5 libsensors4 libsgutils2-2 libsnmp -base libsnmp30 libstatgrab10 libstonith1 libstonithd2 libtimedate-perl libtotem-pg5 libtransitioner2 libvotequorum8 libxml2-utils openhpid pacemaker pacemaker-cli-utils pacemaker-common pacemaker-ressource-agents pc on-pexpect python-ptyprocess python-pycurl python3-bs4 python3-html5lib python3-lxml python3-pycurl python3-webencodings rake resource-agents ruby ruby-activesupport ruby-atomic ruby-backports ruby-medi-ruby-medi-ruby-medi ffi ruby-highline ruby-i18n ruby-json ruby-mime-typer ruby-mime-typer-data ruby-minitest ruby-multi-json ruby-net-telnet ruby-oj ruby-open4 ruby-power-assert ruby-rack ruby -rack-beskyttelse ruby-rack-test ruby-rpam-ruby19 ruby-sinatra ruby-sinatra-bidrag rubin-test-enhed rubin-tråd-sikker rubin-tilt ruby-tzinfo ruby2.5 rubygems-integration sg3-utils snmp unzip xsltproc zip0 opgraderet, 103 nyinstalleret, 0 til at fjerne og 2 ikke opgraderet. Skal du have 19,6 MB arkiver. Efter denne handling vil der blive brugt 86,0 MB ekstra diskplads. Vil du fortsætte? [Y/n] YGet:1 http://azure.archive.ubuntu.com/ubuntu bionic/main amd64 fonts-lato all 2.0-2 [2698 kB]Get:2 http://azure.archive.ubuntu.com /ubuntu bionic/main amd64 libdbus-glib-1-2 amd64 0.110-2 [58.3 kB]…………-------- Engang Pacemakeren klyngeinstallationen er afsluttet, hacluster brugeren udfyldes automatisk, mens du kører nedenstående kommando:
[email protected]:~$ kat /etc/passwd|grep haclusterhacluster:x:111:115::/var/lib/pacemaker:/usr/sbin/nologin Nu kan vi indstille adgangskoden til standardbrugeren, der blev oprettet under installationen af Pacemaker og Corosync pakker. Sørg for at bruge den samme adgangskode på alle 3 noder. Brug nedenstående kommando:
--Indstil standard brugeradgangskode på alle 3 nodessudo passwd hacluster Indtast adgangskoden, når du bliver bedt om det:
[email protected]:~$ sudo passwd hacluster Indtast ny UNIX-adgangskode:Indtast ny UNIX-adgangskode:passwd:adgangskoden blev opdateret Det næste trin er at aktivere og starte pcsd service og Pacemaker på alle 3 noder. Det tillader alle 3 noder at tilslutte sig klyngen efter genstart. Kør nedenstående kommando på alle 3 noder for at få dette trin gjort:
--Aktiver og start pcsd service og pacemakersudo systemctl aktiver pcsdsudo systemctl start pcsdsudo systemctl aktiver pacemaker Se udførelsen på den primære replika aoagvm1 . Sørg for også at køre det på de resterende to noder.
--Aktiver pcsd [email protected]:~$ sudo systemctl aktiver pcsdSynkroniseringstilstand for pcsd.service med SysV servicescript med /lib/systemd/systemd-sysv-install.Executing:/lib/systemd/ systemd-sysv-install enable pcsd--Start pcsd [email protected]:~$ sudo systemctl start pcsd--Enable [email protected]:~$ sudo systemctl enable pacemaker. /systemd/systemd-sysv-install. Udfører:/lib/systemd/systemd-sysv-install enable pacemaker Vi har konfigureret Pacemakeren pakker. Nu opretter vi en klynge.
Først skal du sikre dig, at du ikke har nogen tidligere konfigurerede klynger på disse systemer. Du kan ødelægge alle eksisterende klyngekonfigurationer fra alle noder ved at køre nedenstående kommandoer. Bemærk, at fjernelse af enhver klyngekonfiguration vil stoppe alle klyngetjenester og deaktivere Pacemakeren service – den skal genaktiveres.
--Ødelæg tidligere konfigurerede klynger for at rense systemsudo pcs cluster destroy--Genaktiver Pacemakersudo systemctl aktiver pacemaker Nedenfor er output fra den primære replikaknude aoagvm1 .
--Ødelæg tidligere konfigurerede klynger for at rense [email protected]:~$ sudo pcs cluster destroy Nedlukning af pacemaker/corosync-tjenester...Dræber alle resterende tjenester...Fjerner alle klyngekonfigurationsfiler... --Genaktiver [email protected]:~$ sudo systemctl aktiver pacemakerSynkroniseringstilstand for pacemaker.service med SysV-servicescript med /lib/systemd/systemd-sysv-install. Udfører:/lib/systemd/systemd-sysv-install enable pacemaker Dernæst opretter vi 3-node-klyngen mellem alle 3 noder fra den primære replika aoagvm1 . Vigtigt :Udfør nedenstående kommandoer kun fra din primære node !
--Opret klynge. Rediger nedenstående kommando med dine nodenavne, hacluster-adgangskode og klyngenavnsudo pcs cluster auth -u hacluster -p sudo pcs klyngeopsætning --navn sudo pcs cluster start --allsudo pcs cluster enable --all Se outputtet på den primære replikaknude:
[email protected]:~$ sudo pcs cluster auth aoagvm1 aoagvm2 aoagvm3 -u hacluster -p haclusteraoagvm1:Authorizedaoagvm2:Authorizedaoagvm3:[email protected] --cluster suago pc av2 aoagvm3Destroying cluster on nodes:aoagvm1, aoagvm2, aoagvm3...aoagvm1:Stopping Cluster (pacemaker)...aoagvm2:Stopping Cluster (pacemaker)...aoagvm3:Stopping Cluster (pacemaker)...aoagvm destroyed clusteraoagvm3:Succesfuld destrueret cluster Sender 'pacemaker_remote authkey' til 'aoagvm1', 'aoagvm2', 'aoagvm3'aoagvm1:vellykket distribution af filen 'pacemaker_remote authkey'aoagvm2:a succesfuld distribution af_filen af_agvm2:vellykket distribution af_filen fil 'pacemaker_remote authkey'Sender klyngekonfigurationsfiler til noderne...aoagvm1:Succeededaoagvm2:Succeededaoagvm3:SucceededSynkronisering af pcsd-certifikater på noderne aoagvm1, aoagvm2, aoagvm3...ao :Successaoagvm2:Successaoagvm3:SuccessGenstart af pcsd på noderne for at genindlæse certifikaterne...aoagvm1:Successaoagvm2:Successaoagvm3:[email protected]:~$ sudo pcs cluster start --alloag cluster start --alloagcluster...Start Cvm. .aoagvm3:Starting [email protected]:~$ sudo pcs cluster enable --allaoagvm1:Cluster Enabledaoagvm2:Cluster Enabledaoagvm3:Cluster Enabled Fægtning er en af de væsentlige konfigurationer, mens du bruger PACEMAKER-klyngen i produktionen. Du bør konfigurere hegn for din klynge for at sikre, at der ikke vil være nogen datakorruption i tilfælde af udfald .
Der er to typer hegnsimplementering:
- Ressourceniveau – sikrer, at en node ikke kan bruge en eller flere ressourcer.
- Knudeniveau – sikrer, at en node ikke kører nogen ressourcer overhovedet.
Vi bruger generelt STONITH som hegnskonfiguration – hegn på nodeniveau til PACEMAKER .
Når PACEMAKER ikke kan bestemme tilstanden af en node eller en ressource på en node, bringer hegn klyngen til en kendt tilstand igen. For at opnå dette kræver PACEMAKER, at vi aktiverer STONITH , som står for Skyd den anden knude i hovedet .
Vi vil ikke fokusere på hegnskonfigurationen i denne artikel, fordi hegnskonfigurationen på knudeniveau afhænger meget af det enkelte miljø. For vores scenarie deaktiverer vi det ved at køre nedenstående kommando:
--Deaktiver hegn (STONITH)sudo pcs-egenskabssæt stonith-enabled=false Men hvis du planlægger at bruge Pacemaker i et produktionsmiljø bør du planlægge STONITH-implementeringen afhængigt af dit miljø og holde den aktiveret.
Dernæst vil vi angive nogle væsentlige klyngeegenskaber:cluster-recheck-interval, start-failure-is-fatal, og fejl-timeout .
I henhold til MSDN, hvis fejl-timeout er indstillet til 60 sekunder og cluster-recheck-interval er indstillet til 120 sekunder, forsøges genstart med et interval, der er større end 60 sekunder, men mindre end 120 sekunder. Microsoft anbefaler at indstille en værdi for cluster-recheck-interval større end værdien af fejl-timeout . En anden indstilling start-fejl-er-fatal skal indstilles som sand . Ellers vil klyngen ikke starte failover af primær replika til deres respektive sekundære replika, hvis der skulle opstå permanente udfald.
Kør nedenstående kommandoer for at konfigurere alle 3 vigtige klyngeegenskaber:
--Sæt cluster property cluster-recheck-interval til 2 minuttersudo pcs property set cluster-recheck-interval=2min--Set start-failure-is-fatal til Truesudo pcs property set start-failure-is- fatal=true--Indstil fejl-timeout til 60 sekunder. Ag1 er navnet på tilgængelighedsgruppen. Skift dette navn med din tilgængelighedsgruppenavn.pcs ressourceopdatering ag1 meta failure-timeout=60s Integrer tilgængelighedsgruppe til pacemakerklyngegruppe
Her er vores mål at beskrive processen med at integrere den nyoprettede tilgængelighedsgruppe ag1 til den nyoprettede Pacemaker klyngegruppe.
Først vil vi installere SQL Server-ressourceagenten til integration med Pacemaker på alle 3 noder:
--Installer SQL Server Resource Agent på alle 3 nodessudo apt-get install mssql-server-ha Jeg har udført ovenstående kommando på alle 3 noder. Se outputtet nedenfor (taget fra aoagvm1 ):
--Installer SQL Server-ressourceagent til integration med [email protected]:~$ sudo apt-get install mssql-server-haLæser pakkelister... FærdigBygning af afhængighedstræ Læser tilstandsoplysninger... FærdigFølgende NYT pakker vil blive installeret:mssql-server-ha0 opgraderet, 1 nyinstalleret, 0 til at fjerne og 2 ikke opgraderet. Skal have 1486 kB arkiver. Efter denne handling vil 9151 kB ekstra diskplads blive brugt.Hent:1 https://packages.microsoft.com/ubuntu/16.04/mssql-server-preview xenial/main amd64 mssql-server-ha amd64 15.0.1600.8-1 [1486 kB]Hentet 1486 kB i 0s (4187 kB)Selecting tidligere fravalgt pakke mssql-server-ha.(Læser database ... 90430 filer og mapper installeret i øjeblikket.) Forbereder til udpakning .../mssql-server-ha_15.0.1600.8-1_amd64.deb ...Udpakning af mssql-server -ha (15.0.1600.8-1) ...Opsætning af mssql-server-ha (15.0.1600.8-1) ... Gentag ovenstående trin på de resterende 2 noder.
Vi har allerede oprettet Pacemakeren login på alle SQL Server-instanser hostet på 3 noder, når vi har konfigureret tilgængelighedsgruppen ag1 . Nu tildeler vi sysadmin-rollen på alle 3 SQL Server-instanser. Du kan oprette forbindelse ved hjælp af sqlcmd for running this T-SQL command. If you have not created the Pacemaker login, you can run the below command to do it.
--Create a pacemaker login if you missed creating it in the above section.USE masterGoCREATE LOGIN pacemaker WITH PASSWORD ='[email protected]@12'Go--Assign sysadmin role to pacemaker login on all 3 nodes. Run this T-SQL on all 3 SQL Server instances.ALTER SERVER ROLE [sysadmin] ADD MEMBER [pacemaker] We must save the above SQL Server Pacemaker login and its credentials on all 3 nodes. Run the below command there:
--Save pacemaker login credentials on all 3 nodes by executing below commands on each nodeecho 'pacemaker'>> ~/pacemaker-passwdecho '[email protected]@12'>> ~/pacemaker-passwdsudo mv ~/pacemaker-passwd /var/opt/mssql/secrets/passwdsudo chown root:root /var/opt/mssql/secrets/passwdsudo chmod 400 /var/opt/mssql/secrets/passwd We will create the Availability Group Resource as master/subordinate .
We are using the pcs resource create command to create the Availability Group resource and set its properties. The following command will create the ocf:mssql:ag resource for the Availability Group ag1 .
The Pacemaker resource agent automatically sets the value of REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT on the Availability Group based on the Availability Group’s configuration during the creation of the Availability Group resource.
Execute the below command:
--Create availability group resource ocf:mssql:agsudo pcs resource create ag_cluster ocf:mssql:ag ag_name=ag1 meta failure-timeout=30s --master meta notify=true Next, we create a virtual IP resource in Pacemaker . Ensure you have the unused private IP address from your network . Replace the IP value with your virtual IP address. This IP will point to the primary replica and you can use it to make databases connections with active nodes.
The command is below:
--Configure virtual IP resourcesudo pcs resource create virtualip ocf:heartbeat:IPaddr2 ip=10.50.0.7 We are adding the colocation constraint and ordering constraint to the Pacemaker cluster configuration . These constraints help the virtual IP resource to make decisions on resources, e.g., where they should run.
Constraints have some scores, and Pacemaker uses these scores to make decisions. Scores are calculated per resource. The cluster resource manager chooses the node with the highest score for a particular resource.
The colocation constraint has an implicit ordering constraint . We need to add an ordering constraint to prevent the IP address from temporarily pointing to the node with the pre-failover secondary . Ordering constraint ensures the cluster comes online in a particular sequential manner.
Run the below commands to add colocation constraint and ordering constraint to the cluster.
--Add colocation constraintsudo pcs constraint colocation add virtualip ag_cluster-master INFINITY with-rsc-role=Master--Add ordering constraintsudo pcs constraint order promote ag_cluster-master then start virtualip Hence, Two-Node Synchronous Replicas (aoagvm1 &aoagvm2) and a Configuration-Only Replica (aoagvm3) on PACEMAKER Cluster between 3-Node Ubuntu Systems has been completed.
We can test the configuration to validate the automatic failover. Run the below command to check the status of the Pacemaker cluster. The command also initiates the Availability Group failover.
Remember, once you couple your Availability Group with the PACEMAKER cluster, you cannot use T-SQL statements to initiate the Availability Group failovers. You can also shut down the primary replica to initiate the automatic failover.
The command is the following:
--Validate the PACEMAKER cluster configurationsudo pcs status--Initiate availability group failover to verify AOAG configurationsudo pcs resource move ag_cluster-master aoagvm2 –master Konklusion
This article was meant to help you understand the configuration of the Two-Node Synchronous Replicas and a Configuration-Only Replica on PACEMAKER Cluster. We hope that you got useful information that will help you in your workflow.
Always plan all steps carefully and do proper testing in a lower life cycle before deploying to your production environment.
We’ll be glad to hear your thoughts about this topic. Feel free to leave your feedback in a comment section.