Zus\u00e4tzliche \u00dcberwachung des Failovers ist erforderlich, da wir 12 Shards von PostgreSQL haben, was bedeutet, dass wir 12 Cluster \u00fcberwachen m\u00fcssen. Bei einer Erh\u00f6hung der Anzahl der Shards d\u00fcrfen wir nicht vergessen, das Failover zu aktualisieren.<\/li>\n<\/ul>\nSelbstprogrammierter Failover sieht sehr kompliziert aus und erfordert nicht triviale Unterst\u00fctzung. Bei einem einzelnen PostgreSQL-Cluster wird dies die einfachste L\u00f6sung sein, ist aber nicht skalierbar, weshalb es f\u00fcr uns nicht geeignet ist.<\/p>\n
Repmgr<\/h3>\n Replication Manager f\u00fcr PostgreSQL-Cluster, der die Verwaltung eines PostgreSQL-Clusters \u00fcbernimmt. Dabei bietet er jedoch keinen automatischen Failover \"out of the box\", weshalb eine eigene \"Wrapper\"-L\u00f6sung entwickelt werden muss. Das kann sogar komplizierter sein als mit selbstgeschriebenen Skripten, weshalb wir Repmgr nicht einmal ausprobiert haben.<\/p>\n
AWS RDS<\/h3>\n Bietet alles, was wir ben\u00f6tigen, kann Backups erstellen und unterst\u00fctzt einen Connection-Pool. Verf\u00fcgt \u00fcber automatisches Switching: wenn der Master ausf\u00e4llt, wird die Replikation zum neuen Master und AWS aktualisiert den DNS-Eintrag auf den neuen Master, w\u00e4hrend sich die Replikate in verschiedenen AZs befinden k\u00f6nnen.<\/p>\n
Ein Nachteil ist das Fehlen feiner Einstellungen. Ein Beispiel f\u00fcr feine Einstellungen: In unseren Instanzen gibt es Einschr\u00e4nkungen f\u00fcr TCP-Verbindungen, die leider in RDS nicht 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>\nZudem ist der Preis f\u00fcr AWS RDS fast doppelt so hoch wie der regul\u00e4re Preis f\u00fcr Instanzen, was der Hauptgrund f\u00fcr den Verzicht auf diese L\u00f6sung war.<\/p>\n
Patroni<\/h3>\n Dies ist ein Python-Template zur Verwaltung von PostgreSQL mit guter Dokumentation, automatischem Failover und dem Quellcode auf GitHub.<\/p>\n
Vorteile von Patroni:<\/p>\n
\nJeder Konfigurationsparameter ist klar beschrieben, sodass nachvollziehbar ist, wie alles funktioniert.<\/li>\n Der automatische Failover funktioniert out of the box.<\/li>\n In Python geschrieben, und da wir selbst viel in Python programmieren, wird es uns leichter fallen, Probleme zu beheben und m\u00f6glicherweise sogar das Projekt weiterzuentwickeln.<\/li>\n Verwalten Sie PostgreSQL vollst\u00e4ndig, \u00e4ndern Sie die Konfiguration sofort auf allen Knoten im Cluster, und wenn ein Neustart des Clusters f\u00fcr die Anwendung der neuen Konfiguration erforderlich ist, kann dies ebenfalls \u00fcber Patroni erfolgen.<\/li>\n<\/ul>\nNachteile:<\/p>\n
\nAus der Dokumentation geht nicht klar hervor, wie man richtig mit PgBouncer arbeitet. Das als Nachteil zu werten, ist allerdings schwierig, da es Patrons Aufgabe ist, PostgreSQL zu verwalten, w\u00e4hrend wir uns um die Anbindung an Patroni k\u00fcmmern m\u00fcssen.<\/li>\n Es gibt nur wenige Implementierungsbeispiele von Patroni in gro\u00dfen Umgebungen, jedoch viele Beispiele f\u00fcr Neubauten.<\/li>\n<\/ul>\nLetztendlich haben wir uns zur Erstellung eines ausfallsicheren Clusters genau f\u00fcr Patroni entschieden.<\/p>\n
Prozess der Implementierung von Patroni<\/h2>\n Vor Patroni hatten wir 12 PostgreSQL-Shards in einer Konfiguration mit einem Master und einem Replikat mit asynchroner Replikation. Die Anwendungsserver kommunizierten \u00fcber einen Network Load Balancer mit den Datenbanken, hinter dem sich zwei Instanzen mit PgBouncer befanden, und dahinter lagen alle PostgreSQL-Server.
F\u00fcr die Implementierung von Patroni mussten wir ein verteiltes Konfigurationsspeicher f\u00fcr den Cluster w\u00e4hlen. Patroni funktioniert mit verteilten Konfigurationsspeichersystemen wie etcd, Zookeeper und Consul. Wir haben bereits einen voll funktionsf\u00e4higen Consul-Cluster in der Produktion, der zusammen mit Vault betrieben wird und derzeit nicht anderweitig genutzt wird. Das ist eine ausgezeichnete Gelegenheit, Consul wie vorgesehen zu verwenden.<\/p>\n
Wie funktioniert Patroni mit Consul<\/h3>\n Wir haben einen Consul-Cluster, der aus drei Knoten besteht, und einen Patroni-Cluster, der aus einem F\u00fchrer und Replikaten besteht (im Patroni wird der Master als Clusterf\u00fchrer bezeichnet und die Slaves als Replikate). Jede Instanz des Patroni-Clusters sendet st\u00e4ndig Informationen \u00fcber den Zustand des Clusters an Consul. Daher kann man jederzeit die aktuelle Konfiguration des Patroni-Clusters und den aktuellen F\u00fchrer in Consul einsehen.<\/p>\n
Um Patroni mit Consul zu verbinden, gen\u00fcgt es, die offizielle Dokumentation zu studieren, aus der hervorgeht, dass der Host im Format http oder https angegeben werden muss, je nachdem, wie wir mit Consul arbeiten, sowie das Verbindungsprotokoll optional:<\/p>\n
host: der host:port f\u00fcr den Consul-Endpunkt im Format: http(s):\/\/host:port\nscheme: (optional) http oder https, standardm\u00e4\u00dfig http<\/code><\/pre>\nEs sieht einfach aus, aber hier beginnen die Fallstricke. Mit Consul arbeiten wir \u00fcber eine gesicherte Verbindung via https, und unsere Verbindungs-Konfiguration wird folgenderma\u00dfen aussehen:<\/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>\nDoch so funktioniert es nicht. Beim Start kann Patroni sich nicht mit Consul verbinden, da es trotzdem versucht, \u00fcber http zu gehen.<\/p>\n
Das Verst\u00e4ndnis des Problems wurde durch den Quellcode von Patroni unterst\u00fctzt. Zum Gl\u00fcck ist er in Python geschrieben. Es stellt sich heraus, dass der Parameter host nicht geparsed wird, und das Protokoll muss in der scheme angegeben werden. So sieht der funktionierende Konfigurationsblock f\u00fcr die Arbeit mit Consul 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 Also, wir haben ein Speicherort 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 darauf keine Antwort, da die Arbeit mit PgBouncer dort grunds\u00e4tzlich nicht beschrieben wird.<\/p>\n
Auf der Suche nach einer L\u00f6sung fanden wir einen Artikel (den Titel erinnere ich leider nicht), in dem stand, dass Consul-Template sehr hilfreich in der Verbindung zwischen PgBouncer und Patroni war. Das hat uns dazu angeregt, die Funktionsweise von Consul-Template zu erforschen.<\/p>\n
Es stellte sich heraus, dass der Consul-Template kontinuierlich die Konfiguration des PostgreSQL-Clusters in Consul \u00fcberwacht. Bei einem Leader-Wechsel aktualisiert er die PgBouncer-Konfiguration und sendet den Befehl zur Neuladung.<\/p>\n
Ein gro\u00dfer Vorteil des Templates besteht darin, dass es in Codeform gespeichert wird. Daher gen\u00fcgt es bei der Hinzuf\u00fcgung eines neuen Shards, einen neuen Commit zu machen und das Template automatisch zu aktualisieren, wodurch das Prinzip \"Infrastructure as Code\" unterst\u00fctzt wird.<\/p>\n
Neue Architektur mit Patroni<\/h3>\n Das Resultat ist folgendes Arbeitsdiagramm:
Alle Anwendungsserver wenden sich an den Lastenausgleich \u2192 dahinter stehen zwei PgBouncer-Instanzen \u2192 auf jeder Instanz l\u00e4uft der Consul-Template, der den Zustand jedes Patroni-Clusters \u00fcberwacht und sicherstellt, dass die PgBouncer-Konfiguration aktuell ist, die die Anfragen an den aktuellen Leader jedes Clusters weiterleitet.<\/p>\n
Manuelles Testing<\/h3>\n Diese Struktur haben wir vor dem Rollout in Produktion in einer kleinen Testumgebung getestet und die Funktionalit\u00e4t des automatischen Failovers \u00fcberpr\u00fcft. Wir haben das Board ge\u00f6ffnet, einen Sticker verschoben und in diesem Moment den Leader des Clusters \"get\u00f6tet\". Bei AWS gen\u00fcgt es, die Instanz \u00fcber die Konsole auszuschalten.<\/p>\n
Der Sticker kam innerhalb von 10-20 Sekunden zur\u00fcck, bevor er wieder normal zu bewegen begann. Das bedeutet, der Patroni-Cluster hat korrekt funktioniert: der Leader wurde gewechselt, die Informationen wurden an Consul gesendet, und das Consul-Template hat diese Informationen sofort aufgegriffen, die PgBouncer-Konfiguration ersetzt und den Reload-Befehl gesendet.<\/p>\n
Wie \u00fcberlebt man unter hoher Last und minimiert Ausfallzeiten?<\/h2>\n Alles funktioniert hervorragend! Aber neue Fragen tauchen auf: Wie wird es sich unter hoher Last verhalten? Wie rollt man alles schnell und sicher in die Produktion aus?<\/p>\n
Auf die erste Frage hilft uns eine Testumgebung, in der wir Lasttests durchf\u00fchren. Sie ist in Architektur und Testdaten vollst\u00e4ndig identisch mit der Produktion und hat generierte Testdaten, die in etwa der Produktionsgr\u00f6\u00dfe entsprechen. Wir entscheiden uns, w\u00e4hrend des Tests einen der PostgreSQL-Master absichtlich \u201eabzuw\u00fcrgen\u201c und zu beobachten, was passiert. Aber vorher ist es wichtig, das automatische Rollout zu \u00fcberpr\u00fcfen, denn in dieser Umgebung haben wir mehrere PostgreSQL-Shards, sodass wir gro\u00dfartige Tests der Konfigurationsskripte vor der Produktion erhalten.<\/p>\n
Beide Aufgaben erscheinen ehrgeizig, aber wir haben PostgreSQL 9.6. Vielleicht aktualisieren wir gleich auf 11.2?<\/p>\n
Wir haben beschlossen, dies in zwei Schritten durchzuf\u00fchren: zuerst die Version auf 11.2 zu aktualisieren, dann Patroni zu starten.<\/p>\n
PostgreSQL-Upgrade<\/h3>\n F\u00fcr ein schnelles Upgrade der PostgreSQL-Version sollte die Option -k<\/b>, verwendet werden, bei der Hardlinks auf der Festplatte erstellt werden und kein Kopieren Ihrer Daten erforderlich ist. Bei Datenbanken mit 300-400 GB dauert das Upgrade nur 1 Sekunde.<\/p>\n
Wir haben viele Shards, sodass das Upgrade automatisiert erfolgen muss. Daf\u00fcr 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--old-datadir='' --new-datadir='' \n --old-bindir='' --new-bindir='' \n --old-options=' -c config_file=' \n --new-options=' -c config_file='<\/code><\/pre>\nHier ist es wichtig zu erw\u00e4hnen, dass vor dem Start der Aktualisierung der Parameter \u2014pr\u00fcfen<\/b>verwendet werden muss, um sicherzustellen, dass das Upgrade m\u00f6glich ist. Au\u00dferdem ersetzt unser Skript w\u00e4hrend des Upgrades die Konfigurationsdateien. Unser Skript hat in 30 Sekunden ausgef\u00fchrt, was ein hervorragendes Ergebnis ist.<\/p>\nStart von Patroni<\/h3>\n
Um das zweite Problem zu l\u00f6sen, reicht es, sich die Konfiguration von Patroni anzusehen. Im offiziellen Repository gibt es ein Beispiel f\u00fcr eine Konfiguration mit initdb, das 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 begonnen haben, Patroni auf einen bestehenden PostgreSQL-Cluster zu installieren und zu starten, sind wir auf ein neues Problem gesto\u00dfen: Beide Server starteten als Leader. Patroni hat keine Ahnung vom vorherigen 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>\nDies muss nur auf dem Slave durchgef\u00fchrt werden!<\/b><\/p>\n
Beim Verbinden eines neuen Replikats macht Patroni ein Basebackup des Leaders und stellt es auf der Replik wieder her, und holt anschlie\u00dfend den aktuellen Zustand \u00fcber die WAL-Logs ein.<\/p>\n
Eine weitere Schwierigkeit, die wir festgestellt haben, 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 einzigartigen Namen haben. Die L\u00f6sung besteht darin, den Clusternamen in der PostgreSQL-Konfiguration zu \u00e4ndern.<\/p>\n
Lasttest<\/h3>\n Wir haben einen Test gestartet, der das Nutzerverhalten auf Boards simuliert. Als die Last unser durchschnittliches Tagesniveau erreichte, wiederholten wir denselben Test und schalteten eine Instanz mit dem f\u00fchrenden PostgreSQL aus. Der automatische Failover funktionierte wie erwartet: Patroni wechselte den Leader, Consul-Template aktualisierte die PgBouncer-Konfiguration und gab den Reload-Befehl. Unsere Grafiken in Grafana zeigten Verz\u00f6gerungen von 20-30 Sekunden und eine geringe Anzahl von Fehlern bei der Verbindung mit der Datenbank. Das ist eine normale Situation, solche Werte sind f\u00fcr unseren Failover zul\u00e4ssig und eindeutig besser als Ausfallzeiten des Dienstes.<\/p>\n
Patroni in der Produktion<\/h2>\n Somit haben wir den folgenden Plan erstellt:<\/p>\n
\nDeployment von Consul-Template auf die PgBouncer-Server und 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>\nUnser Schema erm\u00f6glicht es uns, den ersten Punkt praktisch jederzeit durchzuf\u00fchren. Wir k\u00f6nnen nacheinander jeden PgBouncer au\u00dfer Betrieb nehmen und das Deployment sowie den Start von Consul-Template darauf ausf\u00fchren. Genau das haben wir getan.<\/p>\n
F\u00fcr eine schnelle Bereitstellung haben wir Ansible verwendet, da wir alle Playbooks bereits in der Testumgebung gepr\u00fcft hatten, und die Ausf\u00fchrungszeit des gesamten Szenarios betrug zwischen 1,5 und 2 Minuten f\u00fcr jeden Shard. Wir konnten alles nacheinander auf jeden Shard ausrollen, ohne unseren Dienst zu unterbrechen, m\u00fcssten jedoch jeden PostgreSQL f\u00fcr mehrere Minuten abschalten. In diesem Fall k\u00f6nnten die Benutzer, deren Daten auf diesem Shard gespeichert sind, w\u00e4hrenddessen nicht richtig arbeiten, was f\u00fcr uns inakzeptabel w\u00e4re.<\/p>\n
Die L\u00f6sung f\u00fcr diese Situation war eine planm\u00e4\u00dfige Wartung, die alle 3 Monate bei uns stattfindet. Dies ist ein Fenster f\u00fcr geplante Arbeiten, in dem wir unseren Dienst vollst\u00e4ndig abschalten und die Datenbankinstanzen aktualisieren. Eine Woche vor dem n\u00e4chsten Wartungsfenster haben wir uns entschieden, einfach zu warten und uns zus\u00e4tzlich vorzubereiten. W\u00e4hrend der Wartezeit haben wir zus\u00e4tzliche Vorkehrungen getroffen: F\u00fcr jeden PostgreSQL-Shard haben wir eine Backup-Replikation erstellt, um die aktuellsten Daten im Falle eines Fehlers zu sichern, und f\u00fcr jeden Shard eine neue Instanz hinzugef\u00fcgt, die zur neuen Replik im Patroni-Cluster werden sollte, um den Befehl zur Datenl\u00f6schung zu vermeiden. All dies half, das Risiko eines Fehlers zu minimieren.
Wir haben unseren Service neu gestartet, alles funktioniert wie gew\u00fcnscht, die Benutzer konnten weiterarbeiten, jedoch haben wir an den Grafiken eine anomal hohe Last auf den Consul-Servern bemerkt.
Warum haben wir das in der Testumgebung nicht bemerkt? Dieses Problem verdeutlicht sehr gut, wie wichtig es ist, dem Prinzip \"Infrastructure as Code\" zu folgen und die gesamte Infrastruktur von den Testumgebungen bis hin zur Produktionsumgebung weiterzuentwickeln. Andernfalls kann man leicht auf das Problem sto\u00dfen, das uns passiert ist. Was geschah? Consul wurde zun\u00e4chst in der Produktionsumgebung eingef\u00fchrt, bevor es auf den Testumgebungen auftauchte. Schlie\u00dflich war in den Testumgebungen die Version von Consul h\u00f6her als in der Produktionsumgebung. In einer der Versionen wurde ein CPU-Leck bei der Arbeit mit consul-template behoben. Daher haben wir Consul einfach aktualisiert, um das Problem zu l\u00f6sen.<\/p>\n
Patroni-Cluster neu starten<\/h3>\n Aber wir stie\u00dfen auf ein neues Problem, von dem wir nicht einmal wussten. Beim Aktualisieren 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 Instanz des Consul-Clusters kamen und ihm den Befehl consul leave gaben, starteten alle Patroni-Cluster einfach neu, und in den Logs sahen wir folgenden Fehler:<\/p>\n
FEHLER: get_cluster\nVerlauf (letzter Aufruf zuletzt):\n...\nRetryFailedError: 'Zeitüberschreitung der Wiederholungsfrist ü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 abrufen und wurde neu gestartet.<\/p>\n
Um eine L\u00f6sung zu finden, haben wir die Autoren von Patroni \u00fcber ein Issue auf GitHub kontaktiert. Sie haben uns Verbesserungen f\u00fcr unsere Konfigurationsdateien vorgeschlagen:<\/p>\n
consul:\n consul.checks: []\nbootstrap:\n dcs:\n retry_timeout: 8<\/code><\/pre>\nWir konnten das Problem in einer Testumgebung reproduzieren und diese Parameter dort testen, aber leider haben sie nicht funktioniert.<\/p>\n
Das Problem bleibt weiterhin ungel\u00f6st. Wir planen, die folgenden L\u00f6sungsans\u00e4tze auszuprobieren:<\/p>\n
\nDen Consul-Agenten auf jeder Instanz des Patroni-Clusters zu verwenden;<\/li>\n Das Problem im Code zu beheben.<\/li>\n<\/ul>\nWir verstehen, wo der Fehler auftritt: Wahrscheinlich liegt das Problem in der Verwendung des Standard-Timeouts, das nicht durch 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, weshalb Patroni den Clusterzustand nicht abrufen kann und den gesamten Cluster neu startet.<\/p>\n
Gl\u00fccklicherweise haben wir keine weiteren Fehler festgestellt.<\/p>\n
Fazit zur 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 F\u00fchrer und zwei Replikate, um im Falle eines Split-Brain bei einem Failover abzusichern.
In der Produktion l\u00e4uft Patroni bereits seit \u00fcber drei Monaten. In dieser Zeit hat er uns schon mehrfach geholfen. K\u00fcrzlich ist in AWS der F\u00fchrer eines unserer Cluster ausgefallen, der automatische Failover hat funktioniert und die Benutzer konnten weiterarbeiten. Patroni hat seine Hauptaufgabe erf\u00fcllt.<\/p>\n
Ein kleines Res\u00fcmee zur Nutzung von Patroni:<\/b><\/p>\n\nDie Konfigurations\u00e4nderung ist einfach. Es gen\u00fcgt, die Konfiguration auf einer Instanz zu \u00e4ndern, und sie wird im gesamten Cluster \u00fcbernommen. Wenn ein Neustart zur Anwendung der neuen Konfiguration erforderlich ist, informiert Patroni dar\u00fcber. Patroni kann den gesamten Cluster mit einem Befehl neu starten, was ebenfalls sehr praktisch ist.<\/li>\n Der automatische Failover funktioniert und hat uns bereits geholfen.<\/li>\n PostgreSQL-Updates ohne Ausfallzeiten der Anwendung. Zuerst m\u00fcssen die Replikate auf die neue Version aktualisiert werden, dann wird der F\u00fchrer im Patroni-Cluster gewechselt und der alte F\u00fchrer aktualisiert. Dabei erfolgt das notwendige Testen des automatischen Failovers.<\/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