Ĉiam pli, klientoj ricevas la jenajn petojn: "Ni volas ĝin kiel Amazon RDS, sed pli malmultekosta"; "Ni volas ĝin kiel RDS, sed ĉie, en iu ajn infrastrukturo." Por efektivigi tian administritan solvon en Kubernetes, ni rigardis la nunan staton de la plej popularaj operatoroj por PostgreSQL (Stolon, operatoroj de Crunchy Data kaj Zalando) kaj faris nian elekton.
Ĉi tiu artikolo estas la sperto, kiun ni akiris kaj el teoria vidpunkto (recenzo de solvoj) kaj el praktika flanko (kio estis elektita kaj kio rezultis el ĝi). Sed unue, ni determinu kiaj estas la ĝeneralaj postuloj por ebla anstataŭaĵo por RDS...
Kio estas RDS
Kiam homoj parolas pri RDS, laŭ nia sperto, ili signifas administritan DBMS-servon, kiu:
- facile agordi;
- havas la kapablon labori kun momentfotoj kaj renormaliĝi post ili (prefere kun subteno );
- permesas krei mastro-sklava topologioj;
- havas riĉan liston de etendaĵoj;
- provizas revizion kaj uzantan/aliran administradon.
Ĝenerale parolante, aliroj al efektivigo de la ĉemana tasko povas esti tre malsamaj, sed la vojo kun kondiĉa Ansible ne estas proksima al ni. (Kolegoj de 2GIS venis al simila konkludo kiel rezulto kreu "ilo por rapide deploji Postgres-bazitan malsukcesan areton."
Operaciantoj estas ofta aliro por solvi similajn problemojn en la Kubernetes-ekosistemo. La teknika direktoro de "Flanta" jam pli detale parolis pri ili rilate al datumbazoj lanĉitaj ene de Kubernetes. en .
NB: Por rapide krei simplajn funkciigistojn, ni rekomendas atenti nian Malfermfontan ilon . Uzante ĝin, vi povas fari tion sen scio pri Go, sed en manieroj pli konataj al sistemaj administrantoj: en Bash, Python, ktp.
Estas pluraj popularaj K8s-funkciigistoj por PostgreSQL:
- Stolon;
- Crunchy Data PostgreSQL Operatoro;
- Zalando Postgres Operatoro.
Ni rigardu ilin pli detale.
Elekto de Operaciisto
Krom la gravaj funkcioj jam menciitaj supre, ni - kiel inĝenieroj pri infrastrukturaj operacioj de Kubernetes - ankaŭ atendis la jenon de funkciigistoj:
- deplojo de Git kaj kun ;
- pod kontraŭ-afineca subteno;
- instali nodan afinecon aŭ nodan elektilon;
- instalado de toleroj;
- havebleco de agordaj kapabloj;
- kompreneblaj teknologioj kaj eĉ komandoj.
Sen eniri detalojn pri ĉiu el la punktoj (demandu en la komentoj, ĉu vi ankoraŭ havas demandojn pri ili post legi la tutan artikolon), mi ĝenerale rimarkos, ke ĉi tiuj parametroj estas bezonataj por pli precize priskribi la specialiĝon de clusternodoj por mendu ilin por specifaj aplikoj. Tiel ni povas atingi la optimuman ekvilibron laŭ rendimento kaj kosto.
Nun ni transiru al la operatoroj de PostgreSQL mem.
1. Stolon
de la itala firmao Sorint.lab in estis konsiderita speco de normo inter funkciigistoj por DBMS. Ĉi tio estas sufiĉe malnova projekto: ĝia unua publika eldono okazis reen en novembro 2015(!), kaj la GitHub-deponejo havas preskaŭ 3000 stelojn kaj 40+ kontribuantojn.
Efektive, Stolon estas bonega ekzemplo de pripensema arkitekturo:
La aparato de ĉi tiu operatoro troveblas detale en la raporto aŭ . Ĝenerale, sufiĉas diri, ke ĝi povas fari ĉion priskribitan: malsukcesi, prokuriloj por travidebla kliento-aliro, sekurkopioj... Cetere, prokuriloj disponigas aliron per unu finpunkto-servo - male al la aliaj du solvoj pridiskutataj sube (ĉiu havas du servojn por aliranta bazon).
Tamen, Stolon , tial ĝi ne povas esti deplojita tiel, ke estas facile kaj rapide - "kiel varmaj kukoj" - krei DBMS-instancojn en Kubernetes. Administrado estas farita per la utileco stolonctl, deplojo estas farita per la Helm-diagramo, kaj kutimaj estas difinitaj kaj specifitaj en ConfigMap.
Unuflanke, rezultas, ke la funkciigisto ne vere estas funkciigisto (post ĉio, ĝi ne uzas CRD). Sed aliflanke, ĝi estas fleksebla sistemo, kiu ebligas al vi agordi rimedojn en K8s laŭ via opinio.
Resume, por ni persone ne ŝajnis optimuma krei apartan diagramon por ĉiu datumbazo. Tial ni komencis serĉi alternativojn.
2. Crunchy Data PostgreSQL Operatoro
, juna usona ekentrepreno, ŝajnis kiel logika alternativo. Ĝia publika historio komenciĝas per la unua eldono en marto 2017, ekde tiam la GitHub-deponejo ricevis iom malpli ol 1300 stelojn kaj 50+ kontribuantojn. La plej nova eldono de septembro estis provita por funkcii kun Kubernetes 1.15-1.18, OpenShift 3.11+ kaj 4.4+, GKE kaj VMware Enterprise PKS 1.3+.
La arkitekturo de Crunchy Data PostgreSQL Operator ankaŭ plenumas la deklaritajn postulojn:
Administrado okazas per la utileco pgo, tamen ĝi siavice generas Proprajn Rimedojn por Kubernetes. Tial la funkciigisto plaĉis al ni kiel eblaj uzantoj:
- estas kontrolo per CRD;
- konvena uzantadministrado (ankaŭ per CRD);
- integriĝo kun aliaj komponantoj — specialeca kolekto de ujbildoj por PostgreSQL kaj iloj por labori kun ĝi (inkluzive de pgBackRest, pgAudit, etendaĵoj de contrib, ktp.).
Tamen, provoj komenci uzi la funkciigiston de Crunchy Data malkaŝis plurajn problemojn:
- Ne estis ebleco de toleroj - nur nodeSelector estas provizita.
- La kreitaj podoj estis parto de Deployment, malgraŭ la fakto, ke ni deplojis ŝtatan aplikaĵon. Male al StatefulSets, Deplojoj ne povas krei diskojn.
La lasta malavantaĝo kondukas al amuzaj momentoj: en la testa medio ni sukcesis ruli 3 kopiojn per unu disko. loka stokado, igante la funkciigiston raporti ke 3 kopioj funkciis (kvankam ili ne estis).
Alia trajto de ĉi tiu funkciigisto estas ĝia preta integriĝo kun diversaj subtenaj sistemoj. Ekzemple, estas facile instali pgAdmin kaj pgBounce, kaj en antaŭkonfiguritaj Grafana kaj Prometeo estas konsiderataj. En lastatempaj Plibonigita integriĝo kun la projekto estas aparte notita , danke al kiu la funkciigisto ofertas klaran bildigon de PgSQL-metrikoj el la skatolo.
Tamen, la stranga elekto de Kubernetes-generitaj rimedoj kondukis nin al la bezono trovi malsaman solvon.
3. Zalando Postgres Operatoro
Ni konas Zalando-produktojn delonge: ni havas sperton uzante Zalenium kaj, kompreneble, ni provis estas ilia populara HA-solvo por PostgreSQL. Pri la aliro de la firmao al kreado unu el ĝiaj aŭtoroj, Alexey Klyukin, diris en la aero , kaj ni ŝatis ĝin.
Jen la plej juna solvo priparolata en la artikolo: la unua eldono okazis en aŭgusto 2018. Tamen, eĉ malgraŭ la malgranda nombro da formalaj eldonoj, la projekto faris longan vojon, jam superante en populareco la solvon de Crunchy Data kun 1300+ steloj en GitHub kaj la maksimuma nombro da kontribuantoj (70+).
"Sub la kapuĉo" ĉi tiu funkciigisto uzas tempelprovitajn solvojn:
- Patroni kaj Por veturado,
- - por sekurkopioj,
- - kiel konekta naĝejo.
Jen kiel la operatora arkitekturo de Zalando estas prezentita:
La funkciigisto estas plene administrita per Propraj Rimedoj, aŭtomate kreas StatefulSet el ujoj, kiuj tiam povas esti personecigitaj aldonante diversajn kromĉarojn al la balgo. Ĉio ĉi estas grava avantaĝo kompare kun la operatoro de Crunchy Data.
Ĉar ni elektis la solvon de Zalando inter la 3 ebloj konsiderataj, plia priskribo de ĝiaj kapabloj estos prezentita sube, tuj kune kun la praktiko de aplikado.
Praktiku kun Postgres Operator de Zalando
Operaciisto-deplojo estas tre simpla: nur elŝutu la nunan eldonon de GitHub kaj apliku la YAML-dosierojn el la dosierujo. . Alternative, vi ankaŭ povas uzi .
Post instalado, vi devus zorgi pri agordo . Ĉi tio estas farita per ConfigMap postgres-operator en la nomspaco kie vi instalis la funkciigiston. Post kiam la deponejoj estas agorditaj, vi povas disfaldi vian unuan PostgreSQL-areton.
Ekzemple, nia norma deplojo aspektas jene:
apiVersion: acid.zalan.do/v1
kind: postgresql
metadata:
name: staging-db
spec:
numberOfInstances: 3
patroni:
synchronous_mode: true
postgresql:
version: "12"
resources:
limits:
cpu: 100m
memory: 1Gi
requests:
cpu: 100m
memory: 1Gi
sidecars:
- env:
- name: DATA_SOURCE_URI
value: 127.0.0.1:5432
- name: DATA_SOURCE_PASS
valueFrom:
secretKeyRef:
key: password
name: postgres.staging-db.credentials
- name: DATA_SOURCE_USER
value: postgres
image: wrouesnel/postgres_exporter
name: prometheus-exporter
resources:
limits:
cpu: 500m
memory: 100Mi
requests:
cpu: 100m
memory: 100Mi
teamId: staging
volume:
size: 2Gi
Ĉi tiu manifesto deplojas aron de 3 okazoj kun kromĉaro en la formo , de kiu ni prenas aplikajn metrikojn. Kiel vi povas vidi, ĉio estas tre simpla, kaj se vi deziras, vi povas krei laŭvorte senliman nombron da aretoj.
Indas atenti TTT-administra panelo - . Ĝi venas kun la funkciigisto kaj permesas vin krei kaj forigi aretojn, same kiel labori kun sekurkopioj faritaj de la funkciigisto.
Listo de PostgreSQL-aretoj
Rezerva administrado
Alia interesa trajto estas la subteno . Ĉi tiu mekanismo aŭtomate kreas roloj en PostgreSQL, surbaze de la rezulta listo de uzantnomoj. La API tiam permesas vin resendi liston de uzantoj por kiuj roloj estas aŭtomate kreitaj.
Problemoj kaj solvoj
Tamen, la uzo de la funkciigisto baldaŭ malkaŝis plurajn signifajn mankojn:
- manko de subteno de nodeSelector;
- nekapablo malebligi sekurkopiojn;
- kiam oni uzas la kreadfunkcion de datumbazo, defaŭltaj privilegioj ne aperas;
- Foje dokumentaro mankas aŭ estas malaktuala.
Feliĉe, multaj el ili povas esti solvitaj. Ni komencu de la fino - problemoj kun dokumentado.
Plej verŝajne, vi renkontos la fakton, ke ne ĉiam estas klare kiel registri sekurkopion kaj kiel konekti la rezerva sitelo al la Operaciisto UI. La dokumentaro parolas pri tio preterpase, sed la vera priskribo estas en :
- bezonas fari sekreton;
- transdonu ĝin al la operatoro kiel parametron
pod_environment_secret_nameen la CRD kun operatoraj agordoj aŭ en ConfigMap (depende de kiel vi decidas instali la funkciigiston).
Tamen, kiel ĝi rezultas, ĉi tio estas nuntempe neebla. Tial ni kolektis kun kelkaj aldonaj triapartaj evoluoj. Por pliaj informoj pri ĝi, vidu sube.
Se vi transdonas la parametrojn por sekurkopio al la operatoro, nome - wal_s3_bucket kaj alirŝlosiloj en AWS S3, tiam ĝi sekurkopios ĉion: ne nur bazoj en produktado, sed ankaŭ surscenigo. Ĉi tio ne konvenis al ni.
En la priskribo de la parametroj por Spilo, kiu estas la baza Docker-envolvilo por PgSQL kiam vi uzas la funkciigiston, rezultis: vi povas pasi parametron. WAL_S3_BUCKET malplena, tiel malŝaltante sekurkopiojn. Cetere, al granda ĝojo, mi trovis , kiun ni tuj akceptis en nian forkon. Nun vi nur bezonas aldoni enableWALArchiving: false al PostgreSQL-cluster-rimedo.
Jes, estis ŝanco fari ĝin alimaniere funkciigante 2 funkciigistojn: unu por surscenigo (sen sekurkopioj), kaj la dua por produktado. Sed ni povis kontentigi kun unu.
Bone, ni lernis kiel transdoni aliron al la datumbazoj por S3 kaj sekurkopioj komencis eniri en stokadon. Kiel fari rezervajn paĝojn funkcii en Operator UI?
Vi devos aldoni 3 variablojn al la Operaciisto UI:
-
SPILO_S3_BACKUP_BUCKET -
AWS_ACCESS_KEY_ID -
AWS_SECRET_ACCESS_KEY
Post ĉi tio, administrado de sekurkopioj fariĝos disponebla, kio en nia kazo simpligos la laboron kun surscenigo, permesante al ni liveri tranĉaĵojn de produktado tie sen pliaj skriptoj.
Alia avantaĝo estis la laboro kun la Teamoj API kaj ampleksaj ŝancoj por krei datumbazojn kaj rolojn uzante funkciigistajn ilojn. Tamen, la kreita roloj ne havis rajtojn defaŭlte. Sekve, uzanto kun legrajtoj ne povis legi novajn tabelojn.
Kial estas tio? Malgraŭ tio, ke en la kodo necesa GRANT, ili ne ĉiam estas uzataj. Estas 2 metodoj: syncPreparedDatabases и syncDatabases. la syncPreparedDatabases — malgraŭ tio, ke en la sekcio preparedDatabases estas kondiĉo defaultRoles и defaultUsers por krei rolojn, defaŭltaj rajtoj ne estas aplikataj. Ni estas en la procezo de preparado de flikaĵo por ke ĉi tiuj rajtoj estas aŭtomate aplikataj.
Kaj la lasta punkto en la plibonigoj, kiuj rilatas al ni - , kiu aldonas Node Afinecon al la kreita StatefulSet. Niaj klientoj ofte preferas redukti kostojn per uzado de punktoj, kaj ili klare ne valoras gastigi datumbazajn servojn. Ĉi tiu problemo povus esti solvita per toleroj, sed la ĉeesto de Node Affinity donas pli grandan fidon.
Kio okazis?
Surbaze de la rezultoj de solvado de la supraj problemoj, ni forkigis Postgres Operator de Zalando en , kie ĝi estas kolektita per tiaj utilaj flikoj. Kaj por pli granda komforto, ni ankaŭ kolektis .
Listo de PR-oj akceptitaj en la forkon:
- ;
- ;
- ;
- .
Estos bonege se la komunumo subtenas ĉi tiujn PR-ojn por ke ili akiru kontraŭflue kun la sekva versio de la funkciigisto (1.6).
Gratifiko! Produktada migrada sukceshistorio
Se vi uzas Patroni, viva produktado povas esti migrita al la funkciigisto kun minimuma malfunkcio.
Spilo permesas krei standby aretojn per S3-stokado kun , kiam la binara protokolo de PgSQL unue estas konservita en S3 kaj tiam elpumpita per la kopio. Sed kion fari se vi havas ne uzata de Wal-E sur malnova infrastrukturo? La solvo al ĉi tiu problemo jam estas sur la nabo.
PostgreSQL-logika reproduktado venas al la savo. Tamen ni ne detalos pri kiel krei eldonaĵojn kaj abonojn, ĉar... nia plano estis fiasko.
La fakto estas, ke la datumbazo havis plurajn ŝarĝitajn tabelojn kun milionoj da vicoj, kiuj, krome, estis konstante replenigitaj kaj forigitaj. с copy_data, kiam la nova kopio kopias la tutan enhavon de la majstro, ĝi simple ne povas daŭrigi kun la majstro. Kopiado de enhavo funkciis dum semajno, sed neniam atingis la majstron. Fine, ĝi helpis min solvi la problemon kolegoj de Avito: vi povas transdoni datumojn uzante pg_dump. Mi priskribos nian (iom modifitan) version de ĉi tiu algoritmo.
La ideo estas, ke vi povas fari malfunkciigitan abonon ligitan al specifa replika fendo, kaj poste korekti la transakcian numeron. Ekzistis kopioj haveblaj por produktadlaboro. Ĉi tio estas grava ĉar la kopio helpos krei konsekvencan rubejon kaj daŭre ricevi ŝanĝojn de la majstro.
Postaj komandoj priskribantaj la migradprocezon uzos la sekvajn gastigajn notaciojn:
- majstro — fontservilo;
- kopio1 — streaming kopio sur la malnova produktado;
- kopio2 - nova logika kopio.
Plano de migrado
1. Kreu abonon sur la majstro por ĉiuj tabeloj en la skemo public bazo dbname:
psql -h master -d dbname -c "CREATE PUBLICATION dbname FOR ALL TABLES;"
2. Kreu reproduktan fendon sur la majstro:
psql -h master -c "select pg_create_logical_replication_slot('repl', 'pgoutput');"
3. Ĉesu reproduktadon sur la malnova kopio:
psql -h replica1 -c "select pg_wal_replay_pause();"
4. Ricevu la transakcian numeron de la majstro:
psql -h master -c "select replay_lsn from pg_stat_replication where client_addr = 'replica1';"
5. Forigu la rubejon de la malnova kopio. Ni faros tion en pluraj fadenoj, kiuj helpos akceli la procezon:
pg_dump -h replica1 --no-publications --no-subscriptions -O -C -F d -j 8 -f dump/ dbname
6. Alŝutu la rubejon al la nova servilo:
pg_restore -h replica2 -F d -j 8 -d dbname dump/
7. Post elŝuto de la rubejo, vi povas komenci reproduktadon sur la fluanta kopio:
psql -h replica1 -c "select pg_wal_replay_resume();"
7. Ni kreu abonon sur nova logika kopio:
psql -h replica2 -c "create subscription oldprod connection 'host=replica1 port=5432 user=postgres password=secret dbname=dbname' publication dbname with (enabled = false, create_slot = false, copy_data = false, slot_name='repl');"
8. Ni akiru oid abonoj:
psql -h replica2 -d dbname -c "select oid, * from pg_subscription;"
9. Ni diru, ke ĝi estis ricevita oid=1000. Ni apliku la transakcinumeron al la abono:
psql -h replica2 -d dbname -c "select pg_replication_origin_advance('pg_1000', 'AA/AAAAAAAA');"
10. Ni komencu reproduktadon:
psql -h replica2 -d dbname -c "alter subscription oldprod enable;"
11. Kontrolu la abonan staton, reproduktado devus funkcii:
psql -h replica2 -d dbname -c "select * from pg_replication_origin_status;"
psql -h master -d dbname -c "select slot_name, restart_lsn, confirmed_flush_lsn from pg_replication_slots;"
12. Post kiam reproduktado estas komencita kaj la datumbazoj estas sinkronigitaj, vi povas ŝanĝi.
13. Post malŝalto de reproduktado, vi devas korekti la sekvencojn. Ĉi tio estas bone priskribita .
Danke al ĉi tiu plano, la transiro okazis kun minimumaj prokrastoj.
konkludo
Kubernetes-funkciigistoj permesas vin simpligi diversajn agojn reduktante ilin al la kreado de K8s-resursoj. Tamen, atinginte rimarkindan aŭtomatigon per ilia helpo, indas memori, ke ĝi ankaŭ povas alporti kelkajn neatenditajn nuancojn, do elektu viajn telefonistojn saĝe.
Konsiderinte la tri plej popularajn Kubernetes-funkciigistojn por PostgreSQL, ni elektis la projekton de Zalando. Kaj ni devis venki certajn malfacilaĵojn per ĝi, sed la rezulto estis vere plaĉa, do ni planas vastigi ĉi tiun sperton al iuj aliaj instalaĵoj de PgSQL. Se vi havas sperton uzante similajn solvojn, ni ĝojos vidi la detalojn en la komentoj!
PS
Legu ankaŭ en nia blogo:
- «»;
- «»;
- «".
fonto: www.habr.com