Failoveri t\u00e4iendav j\u00e4lgimine on vajalik, meil on 12 PostgreSQL shard'i, seega peame j\u00e4lgima 12 klastrit. Shardide arvu suurenedes tuleb failover'i samuti v\u00e4rskendada.<\/li>\n<\/ul>\nKohandatud failover n\u00e4ib v\u00e4ga keeruline ja vajab mittetavalist tuge. \u00dche PostgreSQL klastri puhul oleks see lihtsaim lahendus, kuid see ei ole skaleeritav, seega ei sobi see meile.<\/p>\n
Repmgr<\/h3>\n PostgreSQL klastrite replikatsiooni haldur, mis suudab hallata PostgreSQL klastrite t\u00f6\u00f6d. Samas ei ole seal automaatset failover'i 'karbist', seega on vajalik kirjutada oma '\u00fcmbrik' valmis lahenduse peale. Seet\u00f5ttu v\u00f5ib k\u00f5ik osutuda isegi keerulisemaks kui kohandatud skriptidega, mist\u00f5ttu me ei proovinudki Repmgr'i.<\/p>\n
AWS RDS<\/h3>\n Toetab k\u00f5ike vajalikku, suudab teha varukoopiaid ja toetab \u00fchenduste kogumit. Omab automaatselt \u00fcleminekut: kui p\u00f5hiserver sureb, muutub replikatsioon uuesti peamiseks serveriks ja AWS muudab DNS-kirje uut p\u00f5hiserverit, samas kui replikatsioonid v\u00f5ivad asuda erinevates AZ-des.<\/p>\n
Miinusteks on v\u00f5imalikud peened seadistused. N\u00e4iteks peente seadistuste osas: meie instantsidel on piirangud TCP \u00fchenduste jaoks, 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 tavalise instantsi hind, mis oli peamine p\u00f5hjus selle lahenduse tagasi l\u00fckkamiseks.<\/p>\n
Patroni<\/h3>\n See on Python'i mall PostgreSQL-i haldamiseks, millel on hea dokumentatsioon, automaatne rike ja l\u00e4htekood GitHubis.<\/p>\n
Patroni plusse:<\/p>\n
\nIga konfiguratsiooniparameeter on selgelt kirjas, kuidas miski t\u00f6\u00f6tab;<\/li>\n Automaatne rikete \u00fcleminek t\u00f6\u00f6tab v\u00e4lja karbist;<\/li>\n Kirjutatud Python'is, ja kuna me ise kirjutame palju Python'is, on meil lihtsam probleemidega tegeleda ja v\u00f5ib-olla isegi aidata projekti arengus;<\/li>\n Haldab t\u00e4ielikult PostgreSQL-i, v\u00f5imaldades konfigureerida k\u00f5iki klastrite s\u00f5lmi. Kui uue konfiguratsiooni rakendamiseks on vajalik klastrite taask\u00e4ivitamine, saab seda teha taas Patroni abil.<\/li>\n<\/ul>\nMiinused:<\/p>\n
\nDokumendist ei ole selge, kuidas PgBounceriga \u00f5igesti t\u00f6\u00f6tada. Kuigi seda on keeruline nimetada miinuseks, kuna Patroni \u00fclesanne on hallata PostgreSQL-i ja kuidas \u00fchendused Patroniga toimuvad, on juba meie probleem.<\/li>\n Patroni juurutamiseks suuremates mahus on v\u00e4he n\u00e4iteid, samas on palju n\u00e4iteid juurutamisest nullist.<\/li>\n<\/ul>\nL\u00f5puks valisime usaldusv\u00e4\u00e4rse klastrite loomise jaoks just Patroni.<\/p>\n
Patroni juurutamisprotsess<\/h2>\n Enne Patronit oli meil 12 PostgreSQL-i shard'i, mis olid konfigureeritud \u00fche meistri ja \u00fche replikaga, mille replikatsioon oli as\u00fcnkroonset t\u00fc\u00fcpi. Rakenduste serverid p\u00f6\u00f6rdusid andmebaaside poole l\u00e4bi Network Load Balanceri, mille taga olid kaks PgBounceri instantsi, ning nende taga k\u00f5ik PostgreSQL serverid.
Patroni rakendamiseks pidime valima klastrite konfiguratsiooni jaotatud salvestusruumi. Patroni t\u00f6\u00f6tab koos jaotatud konfiguratsioonihalduss\u00fcsteemidega, nagu etcd, Zookeeper, Consul. Meil on tootmises t\u00e4ielik Consul klaster, mis t\u00f6\u00f6tab koos Vaultiga ja me ei kasuta seda muul viisil. Suurep\u00e4rane v\u00f5imalus hakata Consulit \u00f5igesti kasutama.<\/p>\n
Kuidas Patroni t\u00f6\u00f6tab Consuliga<\/h3>\n Meil on Consul klaster, mis koosneb kolmest node'ist, ja Patroni klaster, mis koosneb liidristruktuurist ja replikast (Patronis nimetatakse master'it klastriliidriks ja slavenid - replikateks). Iga Patroni klastrite instants saadab pidevalt Consulile teavet klastriseisundi kohta. Seet\u00f5ttu saab Consulist alati teada Patroni klastrite praegust konfiguratsiooni ja kes on hetkel liider.<\/p>\n
Patroni \u00fchendamiseks Consuliga on piisav tutvuda ametliku dokumentatsiooniga, kus on kirjas, et tuleb n\u00e4idata hosti formaadis http v\u00f5i https, s\u00f5ltuvalt sellest, kuidas me Consuliga t\u00f6\u00f6tame, ning \u00fchenduse skeem, mis on valikuline:<\/p>\n
host: host:port Consul l\u00f5pp-punkti jaoks, vormingus: http(s):\/\/host:port\nscheme: (valikuline) http v\u00f5i https, vaikimisi http<\/code><\/pre>\nTundub lihtne, kuid siin algavad komistuskivid. Konsuliga t\u00f6\u00f6tame me kaitstud \u00fchenduse kaudu https 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>\nAga see ei toimi. Patroni k\u00e4ivitamisel ei saa see Konsuliga \u00fchendust luua, kuna see \u00fcritab ikkagi minna http kaudu.<\/p>\n
Probleemi lahendamisel aitas Patrioni allikas. Hea, et see on kirjutatud pythonis. Selgub, et host-parameetrit ei anal\u00fc\u00fcsita, vaid protokoll tuleb m\u00e4\u00e4rata skeemi all. Nii n\u00e4eb v\u00e4lja t\u00f6\u00f6tav konfigureerimissegment Konsuliga 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 oleme valinud konfiguratsiooniks hoiuruumi. N\u00fc\u00fcd peame aru saama, kuidas PgBouncer vahetab oma konfiguratsiooni, kui Patroni klastris liider vahetub. Sellele k\u00fcsimusele ei leia dokumentatsioonist vastust, kuna seal ei ole p\u00f5him\u00f5tteliselt kirjeldatud koost\u00f6\u00f6d PgBounceriga.<\/p>\n
Lahenduse otsingutel leidsime artikli (pealkiri, kahjuks, ei meenu), kus oli kirjutatud, et Consul-template aitas v\u00e4ga h\u00e4sti PgBounceri ja Patroni vahel. See suunas meid uurima Consul-template'i toimimist.<\/p>\n
Selgus, et \u0421onsul-template j\u00e4lgib pidevalt PostgreSQL klastri konfiguratsiooni \u0421onsuli kaudu. Juhtide vahetamisel uuendab ta PgBounceri konfiguratsiooni ja saadab k\u00e4su selle taask\u00e4ivitamiseks.<\/p>\n
Suur pluss template'is on see, et see salvestatakse koodina, seega piisab uue shard'i lisamisest lihtsalt uue commit'i tegemisel ja template'i automaatsest uuendamisest, toetades Infrastructure as code p\u00f5him\u00f5tet.<\/p>\n
Uus arhitektuur koos Patroniga<\/h3>\n Tulemuseks saime sellise t\u00f6\u00f6 \u0441\u0445\u0435\u043c:
K\u00f5ik rakenduste serverid p\u00f6\u00f6rduvad tasakaalustaja poole \u2192 selle taga on kaks PgBounceri instantsi \u2192 igal instantsil on k\u00e4imas \u0421onsul-template, mis j\u00e4lgib iga Patroni klastri olekut ja hoolitseb PgBounceri konfi ajakohasuse eest, mis suunab p\u00e4ringud iga klastri praegusele juhile.<\/p>\n
K\u00e4sitsi testimine<\/h3>\n Selle skeemi enne tootmisse viimist k\u00e4ivitasime v\u00e4ikese testkeskkonna ja kontrollisime automaatse \u00fclemineku toimimist. Avatud tahvlil liikusime kleebist ja sel hetkel 'tapsime' klastri juhi. AWS-is piisab selleks instantsi konsoolist v\u00e4ljal\u00fclitamisest.<\/p>\n
Siltik tuli tagasi 10-20 sekundi jooksul, seej\u00e4rel hakkas j\u00e4lle normaalselt liikuma. See t\u00e4hendab, et Patroni klaster t\u00f6\u00f6tas \u00f5igesti: vahetas liidri, edastas teabe Consulile ja Consul-template haaras selle teabe kohe, asendas PgBounceri konfiguratsiooni ja edastas k\u00e4su reload.<\/p>\n
Kuidas ellu j\u00e4\u00e4da k\u00f5rge koormuse all ja s\u00e4ilitada minimaalne seisak?<\/h2>\n K\u00f5ik t\u00f6\u00f6tab suurep\u00e4raselt! Kuid uusi k\u00fcsimusi tekib: Kuidas see t\u00f6\u00f6tab k\u00f5rge koormuse all? Kuidas kiiresti ja ohutult k\u00f5ike tootmisse rakendada?<\/p>\n
Esimesele k\u00fcsimusele aitab vastata testkeskkond, kus teeme koormustestimist. See on t\u00e4ielikult identne tootmisele arhitektuurilt ja sisaldab genereeritud testandmeid, mille maht on umbes sama suur nagu tootmises. Otsustame lihtsalt \u201ctappa\u201d \u00fche PostgreSQL peamise serveri testi ajal ja vaadata, mis juhtub. Kuid enne seda on oluline kontrollida automaatset rakendamist, sest sellel keskkonnas on meil mitu PostgreSQL shard'i, nii et saame suurep\u00e4rase konfiguratsiooniskeemide testimise enne tootmist.<\/p>\n
M\u00f5lemad \u00fclesanded tunduvad ambitsioonikad, kuid meil on PostgreSQL 9.6. Kas t\u00f5stame kohe versioonile 11.2?<\/p>\n
Kavandame seda teha kahes etapis: esmalt uuendame versiooni 11.2-le ja seej\u00e4rel k\u00e4ivitame Patroni.<\/p>\n
PostgreSQL uuendamine<\/h3>\n PostgreSQL versiooni kiireks uuendamiseks tuleb kasutada valikut -k<\/b>, milles luuakse k\u00f5vakettale hard link ja teie andmete kopeerimist pole vaja. 300-400 GB suuruste andmebaaside puhul v\u00f5tab uuendamine aega 1 sekund.<\/p>\n
Meil on palju sharde, seega peab uuendamine toimuma automaatre\u017eiimis. Selleks kirjutasime Ansible playbook'i, mis viib kogu uuendamisprotsessi l\u00e4bi 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 —check<\/b>, et veenduda uuendamise v\u00f5imalikkuses. Samuti teeb meie skript uuendamise ajaks konfiguratsioonifailide vahetuse. Meie skript k\u00e4ivitati 30 sekundi jooksul, see on suurep\u00e4rane tulemus.<\/p>\nPatroni k\u00e4ivitamine<\/h3>\n
Teise probleemi lahendamiseks piisab, kui vaadata Patroni konfiguratsiooni. Ametlikus hoidlas on olemas initdb konfiguratsiooni n\u00e4idis, mis vastutab uue andmebaasi initsialiseerimise eest Patroni esmakordsel k\u00e4ivitamisel. Kuna meil on juba valmis andmebaas, eemaldasime lihtsalt selle osa konfiguratsioonist.<\/p>\n
Kui alustasime Patroni seadistamist juba valmis PostgreSQL klastrile ja selle k\u00e4ivitamist, siis kohtasime uut probleem: m\u00f5lemad serverid k\u00e4ivituvad kui liidrid. Patroni ei tea klastrite varasest seisundist ja \u00fcritab k\u00e4ivitada m\u00f5lemat serverit nagu kahte eraldi klastrit sama nimega. Selle probleemi lahendamiseks tuleb kustutada slaavi andmed direktori:<\/p>\n
rm -rf \/var\/lib\/postgresql\/<\/code><\/pre>\nSeda tuleb teha ainult slaavil!<\/b><\/p>\n
Puhas replikatsioon \u00fchendamisel teeb Patroni liidri baasi varukoopia ja taastab selle replikatsioonile, seej\u00e4rel j\u00f5uab aktuaalsesse seisundisse l\u00e4bi wal-logide.<\/p>\n
Veel \u00fcks keerukus, millega me kokku puutusime, on see, et k\u00f5ik PostgreSQL klastrid kannavad vaikimisi nime main. Kui iga klaster ei tea teistest midagi, on see normaalne. Kuid kui soovite kasutada Patronit, peavad k\u00f5ik klastrid omama unikaalset nime. Lahendus on muuta PostgreSQL konfiguratsioonis klastrinime.<\/p>\n
Koormustest<\/h3>\n Me k\u00e4ivitasime testi, mis j\u00e4ljendab kasutajate tegevust tahvlitel. Kui koormus j\u00f5udis meie keskmisele p\u00e4evatasemele, viisime l\u00e4bi t\u00e4pselt sama testi, l\u00fclitades v\u00e4lja \u00fche PostgreSQL juhi esinduse. Automatiseeritud failover toimis meie ootuste kohaselt: Patroni vahetas juhti, Consul-template uuendas PgBounceri konfiguratsiooni ja k\u00e4skis ta uuesti laadida. Meie Grafanas n\u00e4htavatest graafikutest oli n\u00e4ha, et oli 20-30 sekundi pikkused viivitused ja v\u00e4ike hulk vigu serveritest, mis olid seotud andmebaasi \u00fchendustega. See on normaalne olukord, sellised n\u00e4itajad on meie failover'i jaoks vastuv\u00f5etavad ja kindlasti paremad kui teenuse seiskumine.<\/p>\n
Patroni v\u00e4ljund tootmises<\/h2>\n Kokkuv\u00f5ttes saime j\u00e4rgmise plaani:<\/p>\n
\nConsul-template'i juurutamine PgBounceri serveritesse ja k\u00e4ivitamine;<\/li>\n PostgreSQL versiooni 11.2 uuendamine;<\/li>\n Klastri nime muutmine;<\/li>\n Patroni klastri k\u00e4ivitamine.<\/li>\n<\/ul>\nSamal ajal v\u00f5imaldab meie skeem esimese punkti teostada praktiliselt igal ajal, saame j\u00e4rk-j\u00e4rgult iga PgBounceri v\u00e4lja l\u00fclitada ning teostada sellele juurutamise ja Consul-template'i k\u00e4ivitamise. Just seda me tegime.<\/p>\n
Kiirete juurutuste jaoks kasutasime Ansible'i, kuna k\u00f5ik playbook'id olime juba testkeskkonnas \u00fcle kontrollinud ning t\u00e4issaneerimise kestus iga shard\u2019i kohta oli 1,5 kuni 2 minutit. Me oleksime saanud k\u00f5ik j\u00e4rk-j\u00e4rgult iga shard'i peale k\u00e4ivitada ilma meie teenuse peatamiseta, kuid oleksime pidanud iga PostgreSQL m\u00f5neks minutiks v\u00e4lja l\u00fclitama. Sellisel juhul ei saaks need kasutajad, kelle andmed on sellel shard'il, sel ajal t\u00e4ielikult t\u00f6\u00f6tada, mis on meie jaoks vastuv\u00f5etamatu.<\/p>\n
Selle olukorra lahenduseks sai planeeritud hooldus, mis toimub meil iga kolm kuu tagant. See on aken planeeritud t\u00f6\u00f6deks, mille k\u00e4igus l\u00fclitame meie teenuse t\u00e4ielikult v\u00e4lja ja uuendame andmebaasi instantsid. J\u00e4rgmise aknani oli j\u00e4\u00e4nud n\u00e4dal ja otsustasime lihtsalt oodata ja t\u00e4iendavalt valmistuda. Ootamise ajal kindlustasime end t\u00e4iendavalt: iga shard'i jaoks t\u00f5stsime \u00fcles varureplika, et \u00e4ra hoida eba\u00f5nnestumist ja s\u00e4ilitada k\u00f5ige v\u00e4rskemad andmed, ning lisasime iga shard'i jaoks uue instantsi, mis peab olema uus replikator Patroni klastris, et mitte k\u00e4ivitada andmete kustutamise k\u00e4sku. K\u00f5ik see aitas maksimaalselt v\u00e4hendada vea riski.
Oleme meie teenuse taask\u00e4ivitanud, k\u00f5ik t\u00f6\u00f6tab nagu peab, kasutajad said j\u00e4tkata t\u00f6\u00f6d, kuid graafikud n\u00e4itasid ebanormaalset k\u00f5rget koormust Consul-serveritele.
Miks me seda testkeskkonnas ei n\u00e4inud? See probleem illustreerib v\u00e4ga selgelt, et on h\u00e4davajalik j\u00e4rgida printsiipi \u201eInfrastruktuur kui kood\u201d ja t\u00e4iustada kogu infrastruktuuri alates testkeskkondadest kuni tootmiseni. Vastasel juhul on v\u00e4ga lihtne saada selline probleem, nagu meil oli. Mis juhtus? Consul ilmus esmalt tootmisse ja alles hiljem testkeskkondadesse, tulemuseks oli see, et testkeskkondades oli Consuli versioon k\u00f5rgem kui tootmises. Just \u00fches versiooniv\u00e4ljaandes lahendati CPU lekkimine consul-template'i kasutamisel. Seet\u00f5ttu v\u00e4rskendasime lihtsalt Consuli, lahendades niiviisi probleemi.<\/p>\n
Taask\u00e4ivita Patroni klaster<\/h3>\n Kuid saime uue probleemi, millest isegi ei kahtlustanud. Consuli uuendamisel eemaldame lihtsalt Consuli s\u00f5lme klastrist k\u00e4suga consul leave \u2192 Patroni \u00fchendub teise Consuli serveriga \u2192 k\u00f5ik t\u00f6\u00f6tab. Kuid kui j\u00f5udsime klastris viimasele Consuli instantsile ja saatsime talle k\u00e4su consul leave, taask\u00e4ivitusid k\u00f5ik Patroni klastrid, ja logides n\u00e4gime j\u00e4rgmist viga:<\/p>\n
VIGA: get_cluster\nViga jälgimine (viimase kõne sisu):\n...\nRetryFailedError: 'Ületatud uuesti proovimise tähtaeg'\nVIGA: Viga suhtlemisel DCS-iga\n<b>LOGI: andmebaasi süsteem on välja lülitatud<\/b><\/code><\/pre>\nPatroni klaster ei saanud teavet oma klastrist ja taask\u00e4ivitati.<\/p>\n
Otsides lahendust, p\u00f6\u00f6rdusime Patroni autorite poole GitHubi teema kaudu. Nad pakkusid meie konfiguratsioonifailide t\u00e4iustusi:<\/p>\n
consul:\n consul.checks: []\nbootstrap:\n dcs:\n retry_timeout: 8<\/code><\/pre>\nMe suutsime probleemi testkeskkonnas korrata ja testisime seal neid parameetreid, kuid kahjuks need ei t\u00f6\u00f6tanud.<\/p>\n
Probleem on endiselt lahendamata. Plaanime proovida j\u00e4rgmisi lahendusi:<\/p>\n
\nKasutada Consul-agent\u2019i igas Patroni klastris asuvas instantsis;<\/li>\n Parandada probleem koodis.<\/li>\n<\/ul>\nMeile on selge vea tekkimise koht: probleem on t\u00f5en\u00e4oliselt default timeout\u2019i kasutamises, mida ei \u00fcmberdefineerita konfiguratsioonifaili kaudu. Kui viimane Consul server eemaldatakse klastrist, hangub kogu Consul klaster, mis kestab kauem kui sekund, mist\u00f5ttu Patroni ei saa klastriseisundit ja taask\u00e4ivitab kogu klastrit.<\/p>\n
\u00d5nneks ei ole me kohanud mingeid muid vigu.<\/p>\n
Patroni kasutamise tulemused<\/h2>\n P\u00e4rast Patroni edukat k\u00e4ivitamist lisasime igasse klastrisse \u00fche t\u00e4iendava repliigi. N\u00fc\u00fcd on igas klastris mingi liik, kus on \u00fcks liider ja kaks repliiki \u2014 et kaitsta jagatud aju olukorra korral vahetamisel.
Patroni on tootmises olnud \u00fcle kolme kuu. Selle aja jooksul on see meid juba p\u00e4\u00e4stnud. Hiljuti suri AWS-is \u00fche klastri liider, automaatne failover t\u00f6\u00f6tas ja kasutajad said j\u00e4tkata t\u00f6\u00f6d. Patroni t\u00e4itis oma peamise eesm\u00e4rgi.<\/p>\n
Patroni kasutamise v\u00e4ike kokkuv\u00f5te:<\/b><\/p>\n\nAsetuste muutmise mugavus. Piisab muudatusest \u00fches instantsis ja see t\u00f5mmatakse kogu klastrisse. Kui uue seadistuse rakendamiseks on vajalik taask\u00e4ivitamine, siis Patroni teavitab sellest. 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-i uuendamine ilma rakenduse seiskamiseta. Esiteks tuleb uuendada repliigid uuele versioonile, seej\u00e4rel vahetada klastri Patroni liider ja uuendada vana liider. Sellega toimub 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\u00f5rgeteta](\"\/wp-content\/uploads\/2019\/06\/443f85815b0560fade7db5b639942935.png\")
![\"T\u00f5rgeteta](\"\/wp-content\/uploads\/2019\/06\/674dd77de4c8b48a946c9f64c0b2fdd1.png\")
<\/p>\n![\"T\u00f5rgeteta](\"\/wp-content\/uploads\/2019\/06\/dabcb7f6006520c4fec85fb925e8975e.png\")
<\/p>\n![\"T\u00f5rgeteta](\"\/wp-content\/uploads\/2019\/06\/2c1f1e7d9f7be4fdeb43858520d55e36.png\")
<\/p>\n![\"T\u00f5rgeteta](\"\/wp-content\/uploads\/2019\/06\/8e5350d2466311593e11add30d5b1bdc.png\")
<\/p>\n![\"T\u00f5rgeteta](\"\/wp-content\/uploads\/2019\/06\/3234594b363904424fdce64c9d77fca5.png\")
<\/p>\n![\"T\u00f5rgeteta](\"\/wp-content\/uploads\/2019\/06\/6cf92996a127bb6637ab81dc45fdd60a.png\")
<\/p>\n![\"T\u00f5rgeteta](\"\/wp-content\/uploads\/2019\/06\/bf9a9eff675a26039e3f76b16c6cd713.png\")
<\/p>\n![\"T\u00f5rgeteta](\"\/wp-content\/uploads\/2019\/06\/d670fe373b774f1b52bfd8a8c3b53a21.png\")
<\/p>\n![\"T\u00f5rgeteta](\"\/wp-content\/uploads\/2019\/06\/29e5c5f50dbfebfe5665fa0aeb009728.png\")
<\/p>\n![\"T\u00f5rgeteta](\"\/wp-content\/uploads\/2019\/06\/af0eef9ac235706c0aac62d2e1ee179d.png\")
<\/p>\n![\"T\u00f5rgeteta](\"\/wp-content\/uploads\/2019\/06\/3bb4c0495fea274b04edd2e99b59eacb.png\")
<\/p>\n