Es ist zus\u00e4tzliches Monitoring f\u00fcr das Failover erforderlich und wir haben 12 PostgreSQL-Shards, was bedeutet, dass wir 12 Cluster \u00fcberwachen m\u00fcssen. Bei einer Erh\u00f6hung der Anzahl der Shards darf man nicht vergessen, das Failover ebenfalls zu aktualisieren.<\/li>\n<\/ul>\nEin selbstgeschriebener Failover sieht sehr kompliziert aus und erfordert nicht triviale Unterst\u00fctzung. Bei einem PostgreSQL-Cluster ist dies die einfachste Variante, aber sie ist nicht skalierbar, daher kommt sie f\u00fcr uns nicht in Frage.<\/p>\n
Repmgr<\/h3>\n Replication Manager f\u00fcr PostgreSQL-Cluster, der die Arbeit eines PostgreSQL-Clusters verwalten kann. Dabei gibt es keinen automatischen Failover 'out of the box', weshalb man eine eigene 'Wrapper'-L\u00f6sung \u00fcber die vorhandene L\u00f6sung schreiben muss. Das kann also sogar komplizierter sein als mit selbstgeschriebenen Skripten, weshalb wir Repmgr gar nicht ausprobiert haben.<\/p>\n
AWS RDS<\/h3>\n Unterst\u00fctzt alles Notwendige f\u00fcr uns, kann Backups erstellen und unterst\u00fctzt Connection Pools. Es gibt ein automatisches Umschalten: Wenn der Master ausf\u00e4llt, wird die Replik zur neuen Master, und AWS \u00e4ndert den DNS-Eintrag auf den neuen Master, wobei die Replikate in verschiedenen AZs sein k\u00f6nnen.<\/p>\n
Zu den Nachteilen z\u00e4hlt das Fehlen feiner Einstellungen. Ein Beispiel f\u00fcr feine Einstellungen: Auf unseren Instanzen gibt es Einschr\u00e4nkungen f\u00fcr TCP-Verbindungen, die leider nicht in RDS umgesetzt werden k\u00f6nnen:<\/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>\nAu\u00dferdem ist der Preis f\u00fcr AWS RDS fast doppelt so hoch wie der normale Preis f\u00fcr Instanzen, was der Hauptgrund f\u00fcr die Ablehnung dieser L\u00f6sung war.<\/p>\n
Patroni<\/h3>\n Das ist ein Python-Template zur Verwaltung von PostgreSQL mit guter Dokumentation, automatischem Failover und Quellcode auf GitHub.<\/p>\n
Vorteile von Patroni:<\/p>\n
\nJeder Konfigurationsparameter ist detailliert beschrieben, es ist klar, wie alles funktioniert;<\/li>\n Der automatische Failover funktioniert sofort;<\/li>\n Ist in Python geschrieben, und da wir selbst viel in Python programmieren, wird es uns leichter fallen, Probleme zu l\u00f6sen und m\u00f6glicherweise sogar zur Weiterentwicklung des Projekts beizutragen;<\/li>\n Verwaltet PostgreSQL vollst\u00e4ndig, erm\u00f6glicht das gleichzeitige \u00c4ndern der Konfiguration auf allen Knoten des Clusters. Wenn ein Neustart des Clusters zur Anwendung der neuen Konfiguration erforderlich ist, kann dies ebenfalls mit Patroni erfolgen.<\/li>\n<\/ul>\nNachteile:<\/p>\n
\nAus der Dokumentation ist nicht klar, wie man richtig mit PgBouncer arbeitet. Das ist zwar schwer als Nachteil zu bezeichnen, weil es die Aufgabe von Patroni ist, PostgreSQL zu verwalten, und wie die Verbindungen zu Patroni laufen \u2013 das ist unser Problem;<\/li>\n Es gibt nur wenige Beispiele f\u00fcr die Implementierung von Patroni bei gro\u00dfen Volumen, aber viele Beispiele f\u00fcr Implementierungen von Grund auf.<\/li>\n<\/ul>\nLetztlich haben wir uns f\u00fcr die Erstellung eines hochverf\u00fcgbaren Clusters f\u00fcr Patroni entschieden.<\/p>\n
Der Implementierungsprozess von Patroni<\/h2>\n Vor Patroni hatten wir 12 PostgreSQL-Shards in einer Konfiguration mit einem Master und einem Replica mit asynchroner Replikation. Die Anwendungsserver kommunizierten \u00fcber einen Network Load Balancer mit den Datenbanken, hinter dem zwei Instanzen mit PgBouncer standen, und dahinter befanden sich alle PostgreSQL-Server.
F\u00fcr die Einf\u00fchrung von Patroni mussten wir ein verteiltes Konfigurationsspeicher f\u00fcr den Cluster ausw\u00e4hlen. Patroni funktioniert mit verteilten Konfigurationsspeichersystemen wie etcd, Zookeeper und Consul. Bei uns gibt es in der Produktion einen vollwertigen Consul-Cluster, der in Verbindung mit Vault betrieben wird, und wir nutzen ihn sonst nicht. Das ist eine gute Gelegenheit, Consul wie vorgesehen zu verwenden.<\/p>\n
Wie Patroni mit Consul funktioniert<\/h3>\n Wir haben einen Consul-Cluster, der aus drei Knoten besteht, und einen Patroni-Cluster, der aus einem Leader und einem Replica besteht (im Patroni hei\u00dft der Master Leader des Clusters und die Slaves \u2013 Replikate). Jede Instanz des Patroni-Clusters sendet st\u00e4ndig Informationen \u00fcber den Zustand des Clusters an Consul. Daher kann man immer \u00fcber Consul die aktuelle Konfiguration des Patroni-Clusters und den aktuellen Leader erfahren.<\/p>\n
Um Patroni mit Consul zu verbinden, reicht es aus, die offizielle Dokumentation zu studieren, die besagt, dass man den Host im Format http oder https angeben muss, je nachdem, wie wir mit Consul arbeiten, sowie das Schema f\u00fcr die Verbindung, optional:<\/p>\n
host: der Host:Port f\u00fcr den Consul-Endpunkt, im Format: http(s):\/\/host:port\nschema: (optional) http oder https, standardm\u00e4\u00dfig http<\/code><\/pre>\nDas sieht einfach aus, aber hier beginnen die Fallstricke. Mit Consul arbeiten wir \u00fcber eine sichere Verbindung \u00fcber https, und unsere Verbindungskonfiguration sieht folgenderma\u00dfen aus:<\/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>\nAber so funktioniert es nicht. Beim Start kann sich Patroni nicht mit Consul verbinden, weil es trotzdem versucht, \u00fcber http zu gehen.<\/p>\n
Bei der L\u00f6sung des Problems half der Quellcode von Patroni. Gut, dass er in Python geschrieben ist. Es stellt sich heraus, dass der Host-Parameter nicht geparst wird, und das Protokoll muss im Schema angegeben werden. So sieht der funktionierende Konfigurationsblock f\u00fcr die Arbeit mit Consul bei uns aus:<\/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 Wir haben also das Speicher-Repository f\u00fcr die Konfiguration ausgew\u00e4hlt. Jetzt m\u00fcssen wir verstehen, wie PgBouncer seine Konfiguration beim Wechsel des Leaders im Patroni-Cluster umschaltet. In der Dokumentation gibt es keine Antwort auf diese Frage, da die Zusammenarbeit mit PgBouncer dort grunds\u00e4tzlich nicht beschrieben ist.<\/p>\n
Auf der Suche nach einer L\u00f6sung fanden wir einen Artikel (leider erinnere ich mich nicht an den Titel), in dem geschrieben stand, dass Consul-template sehr hilfreich bei der Verbindung von PgBouncer und Patroni war. Das motivierte uns, die Funktionsweise von Consul-template zu untersuchen.<\/p>\n
Es stellte sich heraus, dass Consul-template st\u00e4ndig die Konfiguration des PostgreSQL-Clusters in Consul \u00fcberwacht. Beim Wechsel des Leaders aktualisiert es die PgBouncer-Konfiguration und sendet einen Befehl zum Neuladen.<\/p>\n
Ein gro\u00dfer Vorteil des Templates ist, dass es in Form von Code gespeichert wird. Daher reicht es aus, einen neuen Commit vorzunehmen und das Template automatisch zu aktualisieren, um das Prinzip Infrastructure as Code zu unterst\u00fctzen.<\/p>\n
Die neue Architektur mit Patroni<\/h3>\n In der Folge erhielten wir ein solches Arbeitschema:
Alle Anwendungsserver wenden sich an den Lastenausgleich \u2192 Hinter ihm stehen zwei PgBouncer-Instanzen \u2192 Auf jeder Instanz l\u00e4uft Consul-template, das den Status jedes Patroni-Clusters \u00fcberwacht und die Aktualit\u00e4t der PgBouncer-Konfiguration sicherstellt, die Anfragen an den aktuellen Leader jedes Clusters weiterleitet.<\/p>\n
Manuelle Tests<\/h3>\n Dieses Schema haben wir vor der Produktion in einer kleinen Testumgebung gestartet und das automatische Umschalten \u00fcberpr\u00fcft. Wir \u00f6ffneten das Board, bewegten einen Sticker und in diesem Moment \"t\u00f6teten\" wir den Cluster-Leader. In AWS reicht es aus, die Instanz \u00fcber die Konsole auszuschalten.<\/p>\n
Der Sticker kehrte innerhalb von 10-20 Sekunden zur\u00fcck und begann dann wieder normal zu wandern. Das bedeutet, dass der Patroni-Cluster korrekt gearbeitet hat: Der Leader wurde gewechselt, die Informationen wurden an Consul gesendet und Consul-template erfasste diese Informationen sofort, ersetzte die PgBouncer-Konfiguration und sendete den Neuladungsbefehl.<\/p>\n
Wie \u00fcberlebt man unter hoher Belastung und h\u00e4lt die Ausfallzeiten minimal?<\/h2>\n Alles funktioniert hervorragend! Aber neue Fragen tauchen auf: Wie funktioniert das unter hoher Last? Wie kann man alles schnell und sicher in der Produktion ausrollen?<\/p>\n
Die Antwort auf die erste Frage erhalten wir mit Hilfe einer Testumgebung, auf der wir Lasttests durchf\u00fchren. Sie ist in der Architektur identisch mit der Produktionsumgebung und hat generierte Testdaten, die in etwa dem Umfang der Produktion entsprechen. Wir versuchen einfach, einen der PostgreSQL-Master w\u00e4hrend des Tests \"auszuschalten\" und zu sehen, was passiert. Aber vorher ist es wichtig, das automatische Rollout zu \u00fcberpr\u00fcfen, denn in dieser Umgebung haben wir mehrere PostgreSQL-Shards, sodass wir ein hervorragendes Testen der Konfigurationsskripte vor der Produktion erhalten.<\/p>\n
Beide Aufgaben erscheinen ehrgeizig, aber wir haben PostgreSQL 9.6. Vielleicht sollten wir gleich auf 11.2 upgraden?<\/p>\n
Wir haben uns entschieden, dies in zwei Schritten zu tun: Zuerst die Version auf 11.2 zu aktualisieren, dann Patroni zu starten.<\/p>\n
PostgreSQL-Update<\/h3>\n Um das Version-Upgrade von PostgreSQL schnell durchzuf\u00fchren, ist es notwendig, die Option zu verwenden -k<\/b>, bei der Hardlinks auf der Festplatte erstellt werden und keine Notwendigkeit besteht, Ihre Daten zu kopieren. Bei Datenbanken mit 300-400 GB dauert das Upgrade 1 Sekunde.<\/p>\n
Wir haben viele Shards, daher muss das Upgrade automatisch erfolgen. Zu diesem Zweck haben wir ein Ansible-Playbook geschrieben, das den gesamten Upgrade-Prozess f\u00fcr uns durchf\u00fchrt:<\/p>\n
\/usr\/lib\/postgresql\/11\/bin\/pg_upgrade \n<b>--Link <\/b>\n--altes-datadir='' --neues-datadir='' \n --altes-bindir='' --neues-bindir='' \n --alte-optionen=' -c konfigurationsdatei=' \n --neue-optionen=' -c konfigurationsdatei='<\/code><\/pre>\nDabei ist es wichtig zu beachten, dass vor dem Start des Upgrades das Upgrade mit dem Parameter \u2013check<\/b>durchgef\u00fchrt werden muss, um sicherzustellen, dass das Upgrade m\u00f6glich ist. Auch unser Skript ersetzt w\u00e4hrend des Upgrades die Konfigurationen. Unser Skript wurde in 30 Sekunden ausgef\u00fchrt, das ist ein hervorragendes Ergebnis.<\/p>\nStart von Patroni<\/h3>\n
Um das zweite Problem zu l\u00f6sen, reicht es aus, einen Blick auf die Patroni-Konfiguration zu werfen. Im offiziellen Repository gibt es ein Beispiel f\u00fcr eine Konfiguration mit initdb, die f\u00fcr die Initialisierung einer neuen Datenbank beim ersten Start von Patroni verantwortlich ist. Da wir jedoch bereits eine vorhandene Datenbank haben, haben wir diesen Abschnitt einfach aus der Konfiguration entfernt.<\/p>\n
Als wir begannen, Patroni auf einem bereits vorhandenen PostgreSQL-Cluster zu installieren und zu starten, stie\u00dfen wir auf ein neues Problem: Beide Server starteten als Leader. Patroni wei\u00df nichts \u00fcber den fr\u00fcheren Zustand des Clusters und versucht, beide Server als zwei separate Cluster mit demselben Namen zu starten. Um dieses Problem zu l\u00f6sen, muss das Datenverzeichnis auf dem Slave gel\u00f6scht werden:<\/p>\n
rm -rf \/var\/lib\/postgresql\/<\/code><\/pre>\nDas muss nur auf dem Slave gemacht werden!<\/b><\/p>\n
Beim Anschlie\u00dfen einer sauberen Replikat macht Patroni ein Basis-Backup des Leaders und stellt es auf der Replikation wieder her, und gleicht dann den aktuellen Zustand \u00fcber die WAL-Logs an.<\/p>\n
Eine weitere Herausforderung, mit der wir konfrontiert waren, ist, dass alle PostgreSQL-Cluster standardm\u00e4\u00dfig main genannt werden. Wenn jeder Cluster nichts \u00fcber den anderen wei\u00df, ist das in Ordnung. Aber wenn Sie Patroni verwenden m\u00f6chten, m\u00fcssen alle Cluster einen eindeutigen Namen haben. Die L\u00f6sung besteht darin, den Namen des Clusters in der PostgreSQL-Konfiguration zu \u00e4ndern.<\/p>\n
Lasttest<\/h3>\n Wir haben einen Test gestartet, der die Aktivit\u00e4ten der Benutzer auf den Boards simuliert. Als die Last unseren Durchschnittswert f\u00fcr den Tag erreichte, haben wir denselben Test wiederholt und einen Instance mit dem Leader PostgreSQL abgeschaltet. Der automatische Failover funktionierte wie erwartet: Patroni wechselte den Leader, der Consul-Template aktualisierte die PgBouncer-Konfiguration und sendete den Reload-Befehl. In unseren Grafana-Diagrammen war zu sehen, dass es Verz\u00f6gerungen von 20-30 Sekunden gab und eine geringe Anzahl von Fehlern von den Servern, die mit der Verbindung zur Datenbank zusammenhingen. Das ist eine normale Situation, solche Werte sind f\u00fcr unseren Failover akzeptabel und auf jeden Fall besser als ein Ausfall des Dienstes.<\/p>\n
Patroni in der Produktion<\/h2>\n Am Ende hatten wir folgenden Plan:<\/p>\n
\nDeployment des Consul-Templates auf die PgBouncer-Server und dessen Start;<\/li>\n Aktualisierung von PostgreSQL auf Version 11.2;<\/li>\n \u00c4nderung des Cluster-Namens;<\/li>\n Start des Patroni-Clusters.<\/li>\n<\/ul>\nDabei erlaubt unser Schema, den ersten Punkt praktisch jederzeit umzusetzen; wir k\u00f6nnen jeden PgBouncer nacheinander au\u00dfer Betrieb nehmen und das Deployment sowie den Start des Consul-Templates durchf\u00fchren. So haben wir es auch gemacht.<\/p>\n
F\u00fcr ein schnelles Rollout haben wir Ansible verwendet, da wir alle Playbooks bereits in der Testumgebung gepr\u00fcft hatten, und die Ausf\u00fchrungszeit des vollst\u00e4ndigen Szenarios lag zwischen 1,5 und 2 Minuten pro Shard. Wir konnten alles nacheinander auf jeden Shard ausrollen, ohne unseren Dienst anzuhalten, aber wir m\u00fcssten jeweils f\u00fcr einige Minuten jeden PostgreSQL abschalten. In diesem Fall k\u00f6nnten die Benutzer, deren Daten sich auf diesem Shard befinden, w\u00e4hrenddessen nicht vollumf\u00e4nglich arbeiten, was f\u00fcr uns inakzeptabel ist.<\/p>\n
Die L\u00f6sung f\u00fcr diese Situation war eine geplante Wartung, die alle 3 Monate bei uns durchgef\u00fchrt wird. Dieses Zeitfenster ist f\u00fcr geplante Arbeiten, in dem wir unseren Dienst vollst\u00e4ndig ausschalten und die Datenbankinstanzen aktualisieren. Eine Woche vor dem n\u00e4chsten Wartungszeitraum entschieden wir uns, einfach abzuwarten und uns zus\u00e4tzlich vorzubereiten. W\u00e4hrend der Wartezeit haben wir uns zus\u00e4tzlich absichert: F\u00fcr jedes PostgreSQL-Shard haben wir eine Backup-Replikation hochgezogen, um die neuesten Daten im Falle eines Fehlers zu sichern, und haben f\u00fcr jedes Shard eine neue Instanz hinzugef\u00fcgt, die als neue Replik im Patroni-Cluster fungieren sollte, um den Befehl zum L\u00f6schen der Daten zu vermeiden. All dies half, das Risiko von Fehlern zu minimieren.
Wir haben unseren Dienst neu gestartet, alles funktionierte wie vorgesehen, die Benutzer konnten weiterarbeiten, aber auf den Grafiken bemerkten wir eine anomal hohe Last auf den Consul-Servern.
Warum haben wir das in der Testumgebung nicht gesehen? Dieses Problem verdeutlicht sehr gut, dass man dem Prinzip Infrastructure as Code folgen und die gesamte Infrastruktur von der Testumgebung bis zur Produktion weiterentwickeln sollte. Andernfalls ist es sehr einfach, auf ein solches Problem zu sto\u00dfen, wie wir es erlebt haben. Was ist passiert? Consul erschien zun\u00e4chst in der Produktion und dann in den Testumgebungen, und letztendlich war in den Testumgebungen die Version von Consul h\u00f6her als in der Produktion. In einem der Releases wurde ein CPU-Leck beim Arbeiten mit consul-template behoben. Daher haben wir einfach Consul aktualisiert und dieses Problem somit gel\u00f6st.<\/p>\n
Patroni-Cluster neu starten<\/h3>\n Doch wir haben ein neues Problem festgestellt, von dem wir nicht einmal ahnten. Bei der Aktualisierung von Consul entfernen wir einfach den Consul-Knoten aus dem Cluster mit dem Befehl consul leave \u2192 Patroni verbindet sich mit einem anderen Consul-Server \u2192 alles funktioniert. Aber als wir zum letzten Knoten im Consul-Cluster gelangten und ihm den Befehl consul leave gaben, starteten alle Patroni-Cluster neu, und in den Logs sahen wir den folgenden Fehler:<\/p>\n
FEHLER: get_cluster\nRückverfolgung (letzter Aufruf letzte):\n...\nRetryFailedError: 'Frist für den erneuten Versuch überschritten'\nFEHLER: Fehler bei der Kommunikation mit DCS\n<b>PROTOKOLL: Datenbanksystem wurde heruntergefahren<\/b><\/code><\/pre>\nDer Patroni-Cluster konnte keine Informationen \u00fcber seinen Cluster erhalten und startete neu.<\/p>\n
Um eine L\u00f6sung zu finden, wandten wir uns \u00fcber ein Issue auf GitHub an die Autoren von Patroni. Sie schlugen Verbesserungen f\u00fcr unsere Konfigurationsdateien vor:<\/p>\n
consul:\n consul.checks: []\nbootstrap:\n dcs:\n retry_timeout: 8<\/code><\/pre>\nWir konnten das Problem in der Testumgebung reproduzieren und testeten diese Parameter dort, aber leider funktionierten sie nicht.<\/p>\n
Das Problem ist nach wie vor ungel\u00f6st. Wir planen, die folgenden L\u00f6sungsans\u00e4tze auszuprobieren:<\/p>\n
\nVerwendung des Consul-Agents auf jeder Instanz des Patroni-Clusters;<\/li>\n Fehler im Code beheben.<\/li>\n<\/ul>\nUns ist der Ort des Fehlers bekannt: Wahrscheinlich liegt das Problem in der Verwendung des Standard-Timeouts, das nicht \u00fcber die Konfigurationsdatei \u00fcberschrieben wird. Wenn der letzte Consul-Server aus dem Cluster entfernt wird, h\u00e4ngt der gesamte Consul-Cluster f\u00fcr mehr als eine Sekunde, wodurch Patroni den Status des Clusters nicht abrufen kann und das gesamte Cluster neu startet.<\/p>\n
Gl\u00fccklicherweise haben wir keine weiteren Fehler festgestellt.<\/p>\n
Ergebnisse der Verwendung von Patroni<\/h2>\n Nach dem erfolgreichen Start von Patroni haben wir in jedem Cluster eine zus\u00e4tzliche Replik hinzugef\u00fcgt. Jetzt gibt es in jedem Cluster eine Art Quorum: einen Leader und zwei Replikate, um f\u00fcr den Fall eines Split-Brains bei einem Failover abzusichern.
In der Produktion l\u00e4uft Patroni seit \u00fcber drei Monaten. In dieser Zeit hat er uns bereits gerettet. K\u00fcrzlich ist in AWS der Leader eines der Cluster ausgefallen, der automatische Failover hat funktioniert und die Benutzer konnten weiterarbeiten. Patroni hat seine Hauptaufgabe erf\u00fcllt.<\/p>\n
Ein kurzes Fazit zur Verwendung von Patroni:<\/b><\/p>\n\nDie Bequemlichkeit der Konfigurations\u00e4nderung. Es reicht aus, die Konfiguration auf einer Instanz zu \u00e4ndern, und sie wird in den gesamten Cluster \u00fcbertragen. Falls ein Neustart zur Anwendung der neuen Konfiguration erforderlich ist, wird Patroni dies mitteilen. Patroni kann das gesamte Cluster mit einem einzigen Befehl neu starten, was ebenfalls sehr praktisch ist.<\/li>\n Der automatische Failover funktioniert und hat uns bereits gerettet.<\/li>\n Aktualisierung von PostgreSQL ohne Ausfallzeiten der Anwendung. Zuerst m\u00fcssen die Replikate auf die neue Version aktualisiert werden, dann den Leader im Patroni-Cluster wechseln und den alten Leader aktualisieren. Dabei findet das notwendige Testen des automatischen Failover statt.<\/li>\n<\/ul>\nQuelle: 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
![\"Hochverf\u00fcgbarer](\"\/wp-content\/uploads\/2019\/06\/443f85815b0560fade7db5b639942935.png\")
![\"Hochverf\u00fcgbarer](\"\/wp-content\/uploads\/2019\/06\/674dd77de4c8b48a946c9f64c0b2fdd1.png\")
<\/p>\n![\"Hochverf\u00fcgbarer](\"\/wp-content\/uploads\/2019\/06\/dabcb7f6006520c4fec85fb925e8975e.png\")
<\/p>\n![\"Hochverf\u00fcgbarer](\"\/wp-content\/uploads\/2019\/06\/2c1f1e7d9f7be4fdeb43858520d55e36.png\")
<\/p>\n![\"Hochverf\u00fcgbarer](\"\/wp-content\/uploads\/2019\/06\/8e5350d2466311593e11add30d5b1bdc.png\")
<\/p>\n![\"Hochverf\u00fcgbarer](\"\/wp-content\/uploads\/2019\/06\/3234594b363904424fdce64c9d77fca5.png\")
<\/p>\n![\"Hochverf\u00fcgbarer](\"\/wp-content\/uploads\/2019\/06\/6cf92996a127bb6637ab81dc45fdd60a.png\")
<\/p>\n![\"Hochverf\u00fcgbarer](\"\/wp-content\/uploads\/2019\/06\/bf9a9eff675a26039e3f76b16c6cd713.png\")
<\/p>\n![\"Hochverf\u00fcgbarer](\"\/wp-content\/uploads\/2019\/06\/d670fe373b774f1b52bfd8a8c3b53a21.png\")
<\/p>\n![\"Hochverf\u00fcgbarer](\"\/wp-content\/uploads\/2019\/06\/29e5c5f50dbfebfe5665fa0aeb009728.png\")
<\/p>\n![\"Hochverf\u00fcgbarer](\"\/wp-content\/uploads\/2019\/06\/af0eef9ac235706c0aac62d2e1ee179d.png\")
<\/p>\n![\"Hochverf\u00fcgbarer](\"\/wp-content\/uploads\/2019\/06\/3bb4c0495fea274b04edd2e99b59eacb.png\")
<\/p>\n