On vajalik t\u00e4iendav failover'i t\u00f6\u00f6tamise j\u00e4lgimine, samas on meil 12 PostgreSQL'i shard'i, seega peame j\u00e4lgima 12 klastrit. Kui shard'ide arv suureneb, ei tohi unustada failover'it uuendada.<\/li>\n<\/ul>\nKohandatud failover tundub v\u00e4ga keeruline ja n\u00f5uab mitte triviaalset tuge. \u00dche PostgreSQL-klastriga on see k\u00f5ige lihtsam variant, kuid see ei ole skaleeritav, seega meie jaoks ei sobi.<\/p>\n
Repmgr<\/h3>\n PostgreSQL klastrite replikatsiooni haldaja, mis oskab hallata PostgreSQL klastri t\u00f6\u00f6d. Samas puudub selles automaatne failover \u201ekarbist v\u00e4lja\u201d, seega on vajalik kirjutada selle valmis lahenduse peale oma \u201e\u00fcmberpakend\u201d. Nii et k\u00f5ik v\u00f5ib osutuda isegi keerulisemaks kui kohandatud skriptide puhul, seega ei proovinud me isegi Repmgr.<\/p>\n
AWS RDS<\/h3>\n Toetab k\u00f5ike vajalikku meie jaoks, oskab teha varukoopiaid ja toetab \u00fchenduste basseini. Omab automaatset vahetust: kui master sureb, muutub replikast uus master ja AWS muudab dns-kirje uuele masterile, samal ajal kui replikad v\u00f5ivad olla erinevates AZ-des.<\/p>\n
Puudustena v\u00f5ib v\u00e4lja tuua peente seadete puudumise. N\u00e4iteks peene seadistusena on meie instantsidel TCP-\u00fchenduste jaoks piirangud, mida kahjuks RDS-is teha ei saa:<\/p>\n
net.ipv4.tcp_keepalive_time=10\nnet.ipv4.tcp_keepalive_intvl=1\nnet.ipv4.tcp_keepalive_probes=5\nnet.ipv4.tcp_retries2=3\n<\/code><\/pre>\nLisaks on AWS RDS hind peaaegu kaks korda kallim kui tava hind instantside puhul, mis oli ka peamine p\u00f5hjus selle lahenduse k\u00e4est \u00e4ra \u00fctlemiseks.<\/p>\n
Patronit<\/h3>\n See on Pythonis kirjutatud mall PostgreSQL haldamiseks, millel on hea dokumentatsioon, automaatne failover ja source code GitHubis.<\/p>\n
Patroni plussid:<\/p>\n
\nIga seadistuse parameeter on kirjas, on selge, kuidas mis t\u00f6\u00f6tab;<\/li>\n Automaatne failover t\u00f6\u00f6tab karbist v\u00e4lja;<\/li>\n Kirjutatud Pythonis ja kuna me ise kirjutame palju Pythonis, siis on meil lihtsam lahendada probleeme ja v\u00f5ib-olla isegi aidata projekti arengus;<\/li>\n Haldab t\u00e4ielikult PostgreSQL-i, v\u00f5imaldab muuta konfiguratsiooni kohe k\u00f5igil klastrinoodidel, ja kui uue konfiguratsiooni kasutamiseks on vajalik klastrit taask\u00e4ivitada, saab seda taas teha Patroni abil.<\/li>\n<\/ul>\nMiinused:<\/p>\n
\nDokumentatsioonist ei ole selge, kuidas \u00f5igesti PgBounceriga t\u00f6\u00f6tada. Kuigi seda on keeruline miinuseks pidada, sest Patroni \u00fclesanne on hallata PostgreSQL-i, ja kuidas \u00fchendused Patronisse j\u00f5uavad, on juba meie probleem;<\/li>\n Patroni rakendamise n\u00e4idiseid on v\u00e4he suurte koguste puhul, samas on palju n\u00e4iteid rakendamise algusest.<\/li>\n<\/ul>\nKokkuv\u00f5ttes valisime k\u00f5rgema usaldusv\u00e4\u00e4rsuse klastri loomiseks just Patroni.<\/p>\n
Patroni rakendamise protsess<\/h2>\n Enne Patronit oli meil 12 PostgreSQL shard'i konfiguratsioonis, kus oli \u00fcks meister ja \u00fcks replikatsioon as\u00fcnkroonse replikatsiooniga. Rakenduste serverid kasutasid andmebaase Network Load Balancer'i kaudu, mille taga olid kaks PgBouncer'i instantsi, ja nende taga k\u00f5ik PostgreSQL serverid.
Patroni rakendamiseks pidime valima klastrite konfiguratsiooni jaotatud salvestuse. Patroni t\u00f6\u00f6tab jaotatud konfiguratsioonide salvestuss\u00fcsteemidega nagu etcd, Zookeeper ja Consul. Meil on tootmises t\u00e4ielik Consul klaster, mis t\u00f6\u00f6tab koos Vault'iga ja me ei kasuta seda muul viisil. Suurep\u00e4rane v\u00f5imalus hakata Consulit sihip\u00e4raselt kasutama.<\/p>\n
Kuidas Patroni t\u00f6\u00f6tab koos Consuliga<\/h3>\n Meil on Consul klaster, mis koosneb kolmest s\u00f5lmest ja Patroni klaster, mis koosneb \u00fclemast ja replikast (Patronis nimetatakse meistrit klastrite \u00fclemaks ja koopiaid replikateks). Iga Patroni klastrite instants saadab pidevalt Consulile teavet klastrite oleku kohta. Seet\u00f5ttu on Consul'is alati v\u00f5imalik teada saada hetke Patroni klastrite konfiguratsiooni ja kes on antud hetkel \u00fclem.<\/p>\n
Patroni \u00fchendamiseks Consuliga piisab ametliku dokumentatsiooni uurimisest, kus on kirjas, et tuleb n\u00e4idata hosti http v\u00f5i https formaadis, olenevalt meie t\u00f6\u00f6viisist Consuliga, ja \u00fchenduse skeemi, valikuline:<\/p>\n
host: Consul'i l\u00f5pp-punkti host:port, formaadis: http(s):\/\/host:port\nscheme: (valikuline) http v\u00f5i https, vaikev\u00e4\u00e4rtuseks on http<\/code><\/pre>\nSee tundub lihtne, kuid siin algavad probleemid. Consul'iga t\u00f6\u00f6tame kaitstud \u00fchenduse kaudu https kaudu ja meie \u00fchenduse konfigureerimine n\u00e4eb v\u00e4lja j\u00e4rgmine:<\/p>\n
consul:\n host: https:\/\/server.production.consul:8080 \n verify: true\n cacert: {{ consul_cacert }}\n cert: {{ consul_cert }}\n key: {{ consul_key }}<\/code><\/pre>\nKuid see ei t\u00f6\u00f6ta. Patroni k\u00e4ivitamisel ei saa see Consul'iga \u00fchendust, sest ta proovib ikkagi minna http kaudu.<\/p>\n
Probleemi lahendamine osutus annetatud Patroni l\u00e4htekoodiks. Hea, et see on kirjutatud python'is. Selgub, et parameetrit host ei parsita, vaid protokoll tuleb n\u00e4idata skeemis. Nii n\u00e4eb v\u00e4lja t\u00f6\u00f6tav konfiguratsiooniblokk Consul'iga t\u00f6\u00f6tamiseks meie jaoks:<\/p>\n
consul:\n host: server.production.consul:8080\n scheme: https\n verify: true\n cacert: {{ consul_cacert }}\n cert: {{ consul_cert }}\n key: {{ consul_key }}<\/code><\/pre>\nConsul-template<\/h3>\n Nii, me oleme valinud konfiguratsioonide mahuti. N\u00fc\u00fcd tuleb m\u00f5ista, kuidas PgBouncer muudab oma konfiguratsiooni, kui Patroni klastris liider vahetub. Selle kohta dokumentatsioonis vastust ei leidu, kuna PgBouncer'i kasutamine ei ole seal p\u00f5hjalikult kirjeldatud.<\/p>\n
Lahendust otsides leidsime artikli (pealkirja, kahjuks, ei m\u00e4leta), kus kirjutati, et Consul-template aitas v\u00e4ga h\u00e4sti PgBouncer'i ja Patroni vahel. See suunaski meid uurima Consul-template'i t\u00f6\u00f6d.<\/p>\n
Selgus, et Consul-template j\u00e4lgib pidevalt PostgreSQL klastri konfiguratsiooni Consulis. Liidri vahetamisel uuendab ta PgBouncer'i konfiguratsiooni ja saadab k\u00e4su selle taask\u00e4ivitamiseks.<\/p>\n
Suur pluss template'i juures on see, et see on salvestatud koodina, seega on uue shardi lisamisel piisav teha uus commit ja automaatse protsessiga template uuendada, toetades Infrastructure as Code p\u00f5him\u00f5tet.<\/p>\n
Uus arhitektuur Patroniga<\/h3>\n Tulemuseks saime j\u00e4rgmise t\u00f6\u00f6skeemi:
K\u00f5ik rakenduse serverid p\u00f6\u00f6rduvad tasakaalustaja poole \u2192 selle taga on kaks PgBouncer'i instantsi \u2192 igal instantsil t\u00f6\u00f6tab Consul-template, mis j\u00e4lgib iga Patroni klastri olekut ja hoolitseb PgBouncer'i konfi ajakohasuse eest, suunates p\u00e4ringud iga klastri aktiivsele liidrile.<\/p>\n
K\u00e4sitsi testimine<\/h3>\n Enne tootmist l\u00f5puleviimist k\u00e4ivitasime selle skeemi v\u00e4ikeses testkeskkonnas ja kontrollisime automaatse vahetamise toimimist. Avastasime tahvli, liikusime kleebise \u00fcmber ja samal ajal 'tapsime' klastri liidri. AWS-is piisab selleks instantsi konsoliga v\u00e4lja l\u00fclitamisest.<\/p>\n
Kleebis naases 10-20 sekundi jooksul tagasi, ja seej\u00e4rel hakkas uuesti normaalselt liikuma. See t\u00e4hendab, et Patroni klaster tegutses \u00f5igesti: vahetas liidri, edastas teabe Consulisse ja Consul-template haaras kohe selle teabe, asendas PgBouncer'i konfiguratsiooni ja saatis reload k\u00e4su.<\/p>\n
Kuidas ellu j\u00e4\u00e4da k\u00f5rge koormuse all ja hoida minimaalset seisuaja?<\/h2>\n K\u00f5ik t\u00f6\u00f6tab suurep\u00e4raselt! Ent tekivad uued k\u00fcsimused: Kuidas see t\u00f6\u00f6tab k\u00f5rge koormuse all? Kuidas kiiresti ja ohutult k\u00f5ik tootmisse viia?<\/p>\n
Esimesele k\u00fcsimusele vastamiseks aitab meid testkeskkond, kus viime l\u00e4bi koormustestimise. See on t\u00e4ielikult identne tootmisuuendusele arhitektuurilt ja sisaldab genereeritud testandmeid, mille maht on ligikaudu sama kui tootmises. Me otsustame lihtsalt 'tappa' \u00fche PostgreSQL meistritest testimise ajal ja vaadata, mis juhtub. Kuid enne seda on oluline kontrollida automaatset \u00fcmberpaigutamist, kuna sellel keskkonnas on meil mitu PostgreSQL shard'i, seega saame suurep\u00e4rase konfigureerimisskriptide testimise enne tootmist.<\/p>\n
M\u00f5lemad \u00fclesanded n\u00e4evad ambitsioonikad v\u00e4lja, kuid meil on PostgreSQL 9.6. Kas me v\u00f5iks kohe 11.2 versioonile \u00fcle minna?<\/p>\n
Otsustame teha seda kahes etapis: esmalt uuendame versiooni 11.2 peale, seej\u00e4rel k\u00e4ivitame Patroni.<\/p>\n
PostgreSQL uuendamine<\/h3>\n PostgreSQL versiooni kiireks uuendamiseks tuleb kasutada valikut -k<\/b>, mille puhul luuakse k\u00f5vakettale hard link ja teie andmete kopeerimine ei ole vajalik. 300\u2013400 GB suuruste andmebaaside puhul kestab uuendamine 1 sekund.<\/p>\n
Meil on palju shard'e, seega peab uuendamine toimuma automaatselt. Selleks oleme kirjutanud Ansible playbook'i, mis teostab kogu uuendamise protsessi meie eest:<\/p>\n
\/usr\/lib\/postgresql\/11\/bin\/pg_upgrade \n<b>--link <\/b>\n--old-datadir='' --new-datadir='' \n --old-bindir='' --new-bindir='' \n --old-options=' -c config_file=' \n --new-options=' -c config_file='<\/code><\/pre>\nSiinkohal on oluline m\u00e4rkida, et enne uuenduse k\u00e4ivitamist tuleb see teha parameetriga \u2013check<\/b>, et olla kindel uuenduse v\u00f5imalikuses. Samuti meie skript asendab konfiguratsioone uuenduse ajaks. Meie skript t\u00e4itis \u00fclesande 30 sekundiga, see on suurep\u00e4rane tulemus.<\/p>\nPatroni k\u00e4ivitamine<\/h3>\n
Teise probleemi lahendamiseks piisab Patroni konfiguratsiooni vaatamisest. Ametlikus hoidlas on olemas n\u00e4idiskonfiguratsioon koos initdb'ga, mis vastutab uue andmebaasi initsialiseerimise eest Patroni esmakordsel k\u00e4ivitamisel. Kuid kuna meil on juba valmis andmebaas, siis lihtsalt kustutasime selle osa konfiguratsioonist.<\/p>\n
Kui me hakkasime Patroni installima juba olemasolevale PostgreSQL klastrile ja seda k\u00e4ivitama, siis kokku puutusime uue probleemiga: m\u00f5lemad serverid k\u00e4ivitusid juhtidena. Patroni ei tea klastrite varasemast olekust ja proovib k\u00e4ivitada m\u00f5lemat serverit kui kahte eraldi klastri samu nimesid. Selle probleemi lahendamiseks on vajalik kustutada slave'i andmed direktorium:<\/p>\n
rm -rf \/var\/lib\/postgresql\/<\/code><\/pre>\nSeda tuleb teha ainult slave'il!<\/b><\/p>\n
Puhta replika \u00fchendamisel teeb Patroni basebackup'i juhist ja taastab selle replikale, seej\u00e4rel hoiab see ajakohast seisundit wal-logide kaudu.<\/p>\n
Veel raskusi, millega silmitsi seisime, oli see, et k\u00f5ik PostgreSQL klastrid on vaikimisi nimega main. Kui iga klaster ei tea teistest, siis on k\u00f5ik korras. Kuid kui soovite kasutada Patronit, peavad k\u00f5ik klastrid omama ainulaadset nime. Lahendus on muuta PostgreSQL konfiguratsioonis klastri nime.<\/p>\n
Koormustest<\/h3>\n L\u00e4ksime testima, simuleerides kasutajate t\u00f6\u00f6d foorumites. Kui koormus j\u00f5udis meie keskmisele p\u00e4evasele tasemele, kordasime t\u00e4pselt sama testi, kus katkestasime \u00fche instance'i, millel oli PostgreSQL juht. Automaatne failover toimis ootusp\u00e4raselt: Patron vahetas juhti, Consul-template uuendas PgBounceri konfiguratsiooni ja saatis reload-k\u00e4su. Meie Grafanas olevad graafikud n\u00e4itasid, et esines 20-30 sekundi viivitusi ja m\u00f5ningaid vigu serveritest, mis olid seotud andmebaasi \u00fchendamisega. See on normaalne olukord, sellised n\u00e4itajad on meie failoveri jaoks vastuv\u00f5etavad ja kindlasti parem kui teenuse seiskumine.<\/p>\n
Patroni k\u00e4itamine tootmises<\/h2>\n Kokkuv\u00f5ttes saime j\u00e4rgmise plaani:<\/p>\n
\nConsul-template'i paigaldamine PgBounceri serveritesse ja k\u00e4ivitamine;<\/li>\n PostgreSQL v\u00e4rskendamine versioonile 11.2;<\/li>\n Klastri nime muutmine;<\/li>\n Patroni klastri k\u00e4ivitamine.<\/li>\n<\/ul>\nSamas v\u00f5imaldab meie skeem teha esimese punkti praktiliselt igal ajal, saame j\u00e4rjestikku iga PgBounceri t\u00f6\u00f6lt eemaldada ja teha selle jaoks Consul-template'i paigaldamise ja k\u00e4ivitamise. Just seda me tegime.<\/p>\n
Kiireks juurutamiseks kasutasime Ansible'i, kuna k\u00f5ik playbookid olime juba testkeskkonnas kontrollinud, ning kogu stsenaariumi t\u00e4itmise aeg oli iga shard'i jaoks 1,5 kuni 2 minutit. Saime k\u00f5ik j\u00e4rjestikku igale shard'ile juurutada ilma meie teenuse seiskamiseta, kuid pidime iga PostgreSQL m\u00f5neks minutiks v\u00e4lja l\u00fclitama. Sel juhul ei saaks kasutajad, kelle andmed on sellel shard'il, samaaegselt t\u00f6\u00f6tada, mis meie jaoks pole vastuv\u00f5etav.<\/p>\n
Situatsioonist p\u00e4\u00e4semiseks toimus planeeritud hooldus, mis meil toimub iga 3 kuu tagant. See on aeg, mil teeme t\u00e4iesti v\u00e4lja meie teenuse ning uuendame andmebaasi instantsid. J\u00e4\u00e4nud oli n\u00e4dal j\u00e4rgmise aknani ja otsustasime lihtsalt oodata ning valmistuda. Ootamise ajal tegime t\u00e4iendavaid ettevaatusabin\u00f5usid: iga PostgreSQL shard'i jaoks t\u00f5ime \u00fcles varureplika juhuks, kui midagi l\u00e4heks valesti, et s\u00e4ilitada viimaseid andmeid, ja lisasime iga shardi jaoks uue instantsi, millest peaks saama uus replik Patroni klastris, et mitte t\u00e4ita k\u00e4su andmete kustutamiseks. See k\u00f5ik aitas minimeerida vea riski.
Taask\u00e4ivitame oma teenuse, k\u00f5ik t\u00f6\u00f6tas nagu peab, kasutajad j\u00e4tkasid t\u00f6\u00f6d, kuid graafikutel m\u00e4rkasime ebanormaalset k\u00f5rget koormust Consul-serveritele.
Miks me ei n\u00e4inud seda testkeskkonnas? See probleem illustreerib v\u00e4ga h\u00e4sti, et on vajalik j\u00e4rgida infrastruktuuri kui koodi p\u00f5him\u00f5tet ja t\u00e4iendada kogu infrastruktuuri alates testkeskkondadest kuni tootmiseni. Vastasel juhul on v\u00e4ga lihtne sattuda sellisesse probleemisse nagu meil. Mis juhtus? Consul ilmus esmalt tootmisesse ja alles sitten testkeskkondades, mille tulemusena testkeskkondade versioon Consulist oli k\u00f5rgem kui tootmises. \u00dches versioonide v\u00e4ljaandes lahendati CPU leke, kui t\u00f6\u00f6tati consul-template'iga. Seet\u00f5ttu uuendusime lihtsalt Consulit, lahendades nii probleemi.<\/p>\n
Taask\u00e4ivita Patroni klaster<\/h3>\n Kuid me sattusime uude probleemisse, millest me isegi ei kahtlustanud. Consuli uuendamise k\u00e4igus kustutame lihtsalt Consuli s\u00f5lme klastrist k\u00e4suga consul leave \u2192 Patroni \u00fchendub teise Consul-serveriga \u2192 k\u00f5ik t\u00f6\u00f6tab. Kuid kui j\u00f5udsime viimase instantsi Consuli klastrisse ja saatasime talle k\u00e4su consul leave, taask\u00e4ivitusid k\u00f5ik Patroni klastrid ja logides n\u00e4gime j\u00e4rgmist viga:<\/p>\n
VIGA: get_cluster\nJälgimine (viimane kutse viimasena):\n...\nRetryFailedError: 'Ületatud korduse tähtaeg'\nVIGA: Viga suhtlemisel DCS-iga\n<b>LOG: andmebaasisüsteem on välja lülitatud<\/b><\/code><\/pre>\nPatroni klaster ei suutnud saada teavet oma klastri kohta ja taask\u00e4ivitati.<\/p>\n
Lahenduse leidmiseks p\u00f6\u00f6rdusime Patroni autorite poole GitHubi kaudu. Nad soovitasid meie konfiguratsioonifailide t\u00e4iustusi:<\/p>\n
consul:\n consul.checks: []\nbootstrap:\n dcs:\n retry_timeout: 8<\/code><\/pre>\nMe suutsime probleemi testkeskkonnas uuesti esitada ja testisime seal neid parameetreid, kuid kahjuks need ei toiminud.<\/p>\n
Probleem j\u00e4\u00e4b endiselt lahendamata. Planeerime proovida j\u00e4rgmisi lahendusi:<\/p>\n
\nKasutada Consul-agent'i igas Patroni klastris asuvas instantsis;<\/li>\n Parandada probleem koodis.<\/li>\n<\/ul>\nMeile on teada vea tekkimise koht: t\u00f5en\u00e4oliselt on probleem default timeout'i kasutamises, mida ei \u00fcmbers\u00f5ideta konfiguratsioonifailis. Kui viimane Consul server eemaldatakse klastri seest, j\u00e4\u00e4b kogu Consul-klaster hanguma, mis kestab kauem kui sekund, mist\u00f5ttu ei saa Patroni klastri seisundit m\u00e4\u00e4rata ja k\u00e4ivitab kogu klastri t\u00e4ielikult uuesti.<\/p>\n
\u00d5nneks ei ole me kokku puutunud millegi muuga, mis viga tekitaks.<\/p>\n
Patroni kasutamise tulemused<\/h2>\n P\u00e4rast Patroni edukat k\u00e4ivitamist lisasime igasse klastrisse \u00fche t\u00e4iendava replitseerimise. N\u00fc\u00fcd on igas klastris mingi kuorum: \u00fcks juht ja kaks replitseerimist, et tagada ohutus split-braini korral vahetamise ajal.
Tootmises on Patroni t\u00f6\u00f6tanud \u00fcle kolme kuu. Selle aja jooksul on see meid juba aidanud. Hiljuti suri AWS-is \u00fche klastri juht, automaatne failover toimis ja kasutajad j\u00e4tkasid t\u00f6\u00f6d. Patroni t\u00e4itis oma peamist \u00fclesannet.<\/p>\n
V\u00e4ike kokkuv\u00f5te Patroni kasutamisest:<\/b><\/p>\n\nKonfiguratsiooni muutmise mugavus. Piisab konfiguratsiooni muutmisest \u00fchel instantsil ja see t\u00f5mmatakse kogu klastrisse. Kui uue konfiguratsiooni rakendamiseks on vajalik taask\u00e4ivitamine, siis Patroni annab sellest teada. Patroni saab kogu klastrit taask\u00e4ivitada \u00fche k\u00e4suga, mis on samuti v\u00e4ga mugav.<\/li>\n Automaatne failover t\u00f6\u00f6tab ja on meid juba aidanud.<\/li>\n PostgreSQL uuendamine ilma rakenduse seisaku. Esiteks tuleb uuendada replitseerimise uus versioon, seej\u00e4rel vahetada klastri Patronis juht ja uuendada vana juhti. Sellega kaasneb vajalik automaatse failoveri testimine.<\/li>\n<\/ul>\nAllikas: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0412 \u0441\u0442\u0430\u0442\u044c\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443, \u043a\u0430\u043a \u043c\u044b \u043f\u043e\u0434\u043e\u0448\u043b\u0438 \u043a \u0432\u043e\u043f\u0440\u043e\u0441\u0443 \u043e\u0442\u043a\u0430\u0437\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u0438 PostgreSQL, \u043f\u043e\u0447\u0435\u043c\u0443 \u044d\u0442\u043e \u0441\u0442\u0430\u043b\u043e \u0434\u043b\u044f \u043d\u0430\u0441 \u0432\u0430\u0436\u043d\u043e \u0438 \u0447\u0442\u043e \u0432 \u0438\u0442\u043e\u0433\u0435 \u043f\u043e\u043b\u0443\u0447\u0438\u043b\u043e\u0441\u044c. \u0423 \u043d\u0430\u0441 \u0432\u044b\u0441\u043e\u043a\u043e\u043d\u0430\u0433\u0440\u0443\u0436\u0435\u043d\u043d\u044b\u0439 \u0441\u0435\u0440\u0432\u0438\u0441: 2,5 \u043c\u043b\u043d \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u043f\u043e \u0432\u0441\u0435\u043c\u0443 \u043c\u0438\u0440\u0443, 50\u041a+ \u0430\u043a\u0442\u0438\u0432\u043d\u044b\u0445 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u043a\u0430\u0436\u0434\u044b\u0439 \u0434\u0435\u043d\u044c. \u0421\u0435\u0440\u0432\u0435\u0440\u0430 \u043d\u0430\u0445\u043e\u0434\u044f\u0442\u0441\u044f \u0432 Amazone \u0432 \u043e\u0434\u043d\u043e\u043c \u0440\u0435\u0433\u0438\u043e\u043d\u0435 \u0418\u0440\u043b\u0430\u043d\u0434\u0438\u0438: \u0432 \u0440\u0430\u0431\u043e\u0442\u0435 \u043f\u043e\u0441\u0442\u043e\u044f\u043d\u043d\u043e 100+ \u0440\u0430\u0437\u043b\u0438\u0447\u043d\u044b\u0445 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432, \u0438\u0437 \u043d\u0438\u0445 \u043f\u043e\u0447\u0442\u0438 50 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26749,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-35706","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"T\u00f5rketaluv](\"\/wp-content\/uploads\/2019\/06\/443f85815b0560fade7db5b639942935.png\")
![\"T\u00f5rketaluv](\"\/wp-content\/uploads\/2019\/06\/674dd77de4c8b48a946c9f64c0b2fdd1.png\")
<\/p>\n![\"T\u00f5rketaluv](\"\/wp-content\/uploads\/2019\/06\/dabcb7f6006520c4fec85fb925e8975e.png\")
<\/p>\n![\"T\u00f5rketaluv](\"\/wp-content\/uploads\/2019\/06\/2c1f1e7d9f7be4fdeb43858520d55e36.png\")
<\/p>\n![\"T\u00f5rketaluv](\"\/wp-content\/uploads\/2019\/06\/8e5350d2466311593e11add30d5b1bdc.png\")
<\/p>\n![\"T\u00f5rketaluv](\"\/wp-content\/uploads\/2019\/06\/3234594b363904424fdce64c9d77fca5.png\")
<\/p>\n![\"T\u00f5rketaluv](\"\/wp-content\/uploads\/2019\/06\/6cf92996a127bb6637ab81dc45fdd60a.png\")
<\/p>\n![\"T\u00f5rketaluv](\"\/wp-content\/uploads\/2019\/06\/bf9a9eff675a26039e3f76b16c6cd713.png\")
<\/p>\n![\"T\u00f5rketaluv](\"\/wp-content\/uploads\/2019\/06\/d670fe373b774f1b52bfd8a8c3b53a21.png\")
<\/p>\n![\"T\u00f5rketaluv](\"\/wp-content\/uploads\/2019\/06\/29e5c5f50dbfebfe5665fa0aeb009728.png\")
<\/p>\n![\"T\u00f5rketaluv](\"\/wp-content\/uploads\/2019\/06\/af0eef9ac235706c0aac62d2e1ee179d.png\")
<\/p>\n![\"T\u00f5rketaluv](\"\/wp-content\/uploads\/2019\/06\/3bb4c0495fea274b04edd2e99b59eacb.png\")
<\/p>\n