Se necesita una supervisi\u00f3n adicional del funcionamiento del failover, y tenemos 12 shards de PostgreSQL, lo que significa que debemos monitorear 12 cl\u00fasteres. Al aumentar el n\u00famero de shards, tambi\u00e9n debemos recordar actualizar el failover.<\/li>\n<\/ul>\nEl failover personalizado parece muy complicado y requiere soporte no trivial. Con un solo cl\u00faster de PostgreSQL, esta ser\u00eda la opci\u00f3n m\u00e1s sencilla, pero no es escalable, por lo que no es adecuada para nosotros.<\/p>\n
Repmgr<\/h3>\n Gestor de Replicaci\u00f3n para cl\u00fasteres de PostgreSQL que puede administrar el funcionamiento del cl\u00faster de PostgreSQL. Sin embargo, no cuenta con failover autom\u00e1tico \u201cde f\u00e1brica\u201d, por lo que ser\u00e1 necesario escribir nuestro propio \u201cwrapper\u201d sobre la soluci\u00f3n existente. Por lo tanto, puede terminar siendo incluso m\u00e1s complicado que con los scripts personalizados, as\u00ed que ni siquiera probamos Repmgr.<\/p>\n
AWS RDS<\/h3>\n Soporta todo lo necesario para nosotros, permite hacer copias de seguridad y soporta un pool de conexiones. Tiene conmutaci\u00f3n autom\u00e1tica: cuando el maestro falla, la r\u00e9plica se convierte en el nuevo maestro, y AWS cambia el registro DNS al nuevo maestro, manteniendo las r\u00e9plicas en diferentes AZ.<\/p>\n
Entre las desventajas se puede mencionar la falta de configuraciones finas. Un ejemplo de configuraciones finas: en nuestras instancias hay restricciones para las conexiones TCP, lo cual, desafortunadamente, no se puede hacer en RDS:<\/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>\nAdem\u00e1s, el precio de AWS RDS es casi el doble del precio habitual de la instancia, que fue la principal raz\u00f3n para rechazar esta soluci\u00f3n.<\/p>\n
Patroni<\/h3>\n Este es un template en Python para gestionar PostgreSQL con buena documentaci\u00f3n, failover autom\u00e1tico y c\u00f3digo fuente en github.<\/p>\n
Ventajas de Patroni:<\/p>\n
\nCada par\u00e1metro de configuraci\u00f3n est\u00e1 detallado, es claro c\u00f3mo funciona cada cosa;<\/li>\n El failover autom\u00e1tico funciona de f\u00e1brica;<\/li>\n Est\u00e1 escrito en Python, y como nosotros tambi\u00e9n escribimos mucho en Python, nos ser\u00e1 m\u00e1s f\u00e1cil lidiar con problemas y, posiblemente, incluso ayudar en el desarrollo del proyecto;<\/li>\n Administra completamente PostgreSQL, permite cambiar la configuraci\u00f3n de inmediato en todos los nodos del cl\u00faster y, si para aplicar una nueva configuraci\u00f3n se requiere reiniciar el cl\u00faster, esto tambi\u00e9n se puede hacer con Patroni.<\/li>\n<\/ul>\nDesventajas:<\/p>\n
\nLa documentaci\u00f3n no es clara sobre c\u00f3mo trabajar correctamente con PgBouncer. Aunque esto no se puede considerar un inconveniente, ya que la tarea de Patroni es gestionar PostgreSQL, y c\u00f3mo se gestionen las conexiones a Patroni ya es nuestro problema;<\/li>\n Hay pocos ejemplos de implementaci\u00f3n de Patroni en grandes vol\u00famenes, pero hay muchos ejemplos de implementaci\u00f3n desde cero.<\/li>\n<\/ul>\nAl final, para crear un cl\u00faster resistente a fallos, elegimos precisamente Patroni.<\/p>\n
El proceso de implementaci\u00f3n de Patroni<\/h2>\n Antes de Patroni, ten\u00edamos 12 shards de PostgreSQL con una configuraci\u00f3n de un maestro y una r\u00e9plica con replicaci\u00f3n as\u00edncrona. Los servidores de aplicaciones se conectaban a las bases de datos a trav\u00e9s de un Network Load Balancer, detr\u00e1s del cual hab\u00eda dos instancias de PgBouncer, y detr\u00e1s de ellas estaban todos los servidores PostgreSQL.
Para implementar Patroni, necesit\u00e1bamos seleccionar un almac\u00e9n de configuraci\u00f3n distribuido para el cl\u00faster. Patroni trabaja con sistemas de almacenamiento de configuraciones distribuidos, como etcd, Zookeeper y Consul. En producci\u00f3n, tenemos un cl\u00faster completo de Consul que funciona en conjunto con Vault y no lo utilizamos de ninguna otra manera. Es una excelente oportunidad para comenzar a utilizar Consul para su prop\u00f3sito.<\/p>\n
C\u00f3mo funciona Patroni con Consul<\/h3>\n Tenemos un cl\u00faster de Consul que consta de tres nodos y un cl\u00faster de Patroni que est\u00e1 compuesto por un l\u00edder y una r\u00e9plica (en Patroni, el maestro se llama l\u00edder del cl\u00faster y los esclavos son r\u00e9plicas). Cada instancia del cl\u00faster Patroni env\u00eda constantemente informaci\u00f3n sobre el estado del cl\u00faster a Consul. Por lo tanto, siempre se puede conocer la configuraci\u00f3n actual del cl\u00faster de Patroni y qui\u00e9n es el l\u00edder en ese momento desde Consul.<\/p>\n
Para conectar Patroni a Consul, basta con consultar la documentaci\u00f3n oficial, donde se indica que es necesario especificar el host en formato http o https, dependiendo de c\u00f3mo trabajamos con Consul, y opcionalmente el esquema de conexi\u00f3n:<\/p>\n
host: el host:puerto para el punto final de Consul, en formato: http(s):\/\/host:puerto\nscheme: (opcional) http o https, por defecto es http<\/code><\/pre>\nParece simple, pero aqu\u00ed comienzan los problemas ocultos. Trabajamos con Consul a trav\u00e9s de una conexi\u00f3n segura a trav\u00e9s de https, y nuestra configuraci\u00f3n de conexi\u00f3n se ver\u00e1 de la siguiente manera:<\/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>\nPero as\u00ed no funciona. Al iniciar Patroni, no puede conectarse a Consul porque intenta hacer la conexi\u00f3n por http de todos modos.<\/p>\n
Resolver el problema ayud\u00f3 el c\u00f3digo fuente de Patroni. Afortunadamente, est\u00e1 escrito en Python. Resulta que el par\u00e1metro host no se analiza de ninguna manera, y es necesario especificar el protocolo en el esquema. As\u00ed es como se ve el bloque de configuraci\u00f3n funcional para trabajar con Consul en nuestra implementaci\u00f3n:<\/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 As\u00ed que hemos elegido el almacenamiento para la configuraci\u00f3n. Ahora necesitamos entender c\u00f3mo PgBouncer cambiar\u00e1 su configuraci\u00f3n al cambiar de l\u00edder en el cl\u00faster de Patroni. La documentaci\u00f3n no ofrece respuesta a esta pregunta, ya que no describe en principio el funcionamiento con PgBouncer.<\/p>\n
En busca de una soluci\u00f3n, encontramos un art\u00edculo (lamentablemente no recuerdo el nombre), donde se dec\u00eda que Consul-template ayud\u00f3 mucho en la integraci\u00f3n de PgBouncer y Patroni. Esto nos impuls\u00f3 a investigar el funcionamiento de Consul-template.<\/p>\n
Result\u00f3 que Consul-template monitorea constantemente la configuraci\u00f3n del cl\u00faster PostgreSQL en Consul. Al cambiar de l\u00edder, actualiza la configuraci\u00f3n de PgBouncer y env\u00eda un comando para su reinicio.<\/p>\n
Una gran ventaja del template es que se almacena en forma de c\u00f3digo, por lo que al a\u00f1adir un nuevo shard, basta con hacer un nuevo commit y actualizar el template autom\u00e1ticamente, manteniendo el principio de Infraestructura como c\u00f3digo.<\/p>\n
Nueva arquitectura con Patroni<\/h3>\n Como resultado, obtuvimos el siguiente esquema de trabajo:
Todos los servidores de aplicaciones se dirigen al balanceador \u2192 detr\u00e1s de \u00e9l hay dos instancias de PgBouncer \u2192 en cada instancia se ejecuta Consul-template, que monitoriza el estado de cada cl\u00faster de Patroni y mantiene actualizada la configuraci\u00f3n de PgBouncer, que dirige las solicitudes al actual l\u00edder de cada cl\u00faster.<\/p>\n
Pruebas manuales<\/h3>\n Antes de poner este esquema en producci\u00f3n, lo probamos en un peque\u00f1o entorno de pruebas y verificamos el funcionamiento del cambio autom\u00e1tico. Abrimos un tablero, movimos un sticker y en ese momento 'eliminamos' al l\u00edder del cl\u00faster. En AWS, esto es suficiente con apagar la instancia a trav\u00e9s de la consola.<\/p>\n
El sticker regres\u00f3 en 10-20 segundos, y luego comenz\u00f3 a moverse normalmente nuevamente. Esto significa que el cl\u00faster de Patroni funcion\u00f3 correctamente: cambi\u00f3 de l\u00edder, envi\u00f3 la informaci\u00f3n a Consul, y Consul-template capt\u00f3 de inmediato esta informaci\u00f3n, reemplaz\u00f3 la configuraci\u00f3n de PgBouncer y envi\u00f3 el comando para recargar.<\/p>\n
\u00bfC\u00f3mo sobrevivir a una alta carga y mantener un tiempo de inactividad m\u00ednimo?<\/h2>\n \u00a1Todo funciona perfectamente! Pero surgen nuevas preguntas: \u00bfC\u00f3mo funcionar\u00e1 esto bajo alta carga? \u00bfC\u00f3mo desplegar todo en producci\u00f3n de manera r\u00e1pida y segura?<\/p>\n
Responder la primera pregunta nos ayuda un entorno de prueba, en el que realizamos pruebas de carga. Es completamente id\u00e9ntico a production en arquitectura y tiene datos de prueba generados, que en volumen son aproximadamente equivalentes a production. Simplemente decidimos \"matar\" uno de los maestros de PostgreSQL durante la prueba y ver qu\u00e9 sucede. Pero antes de esto es importante verificar el despliegue autom\u00e1tico, ya que en este entorno tenemos varios shards de PostgreSQL, as\u00ed que obtendremos un excelente test de los scripts de configuraci\u00f3n antes de la producci\u00f3n.<\/p>\n
Ambas tareas parecen ambiciosas, pero tenemos PostgreSQL 9.6. \u00bfQuiz\u00e1s deber\u00edamos actualizar directamente a 11.2?<\/p>\n
Decidimos hacer esto en 2 etapas: primero actualizar la versi\u00f3n a 11.2, luego iniciar Patroni.<\/p>\n
Actualizaci\u00f3n de PostgreSQL<\/h3>\n Para una actualizaci\u00f3n r\u00e1pida de la versi\u00f3n de PostgreSQL es necesario utilizar la opci\u00f3n -k<\/b>, que crea enlaces duros en el disco y no requiere la copia de sus datos. En bases de datos de 300-400 GB, la actualizaci\u00f3n toma 1 segundo.<\/p>\n
Tenemos muchos shards, por lo que la actualizaci\u00f3n debe hacerse de forma autom\u00e1tica. Para ello, hemos escrito un playbook de Ansible que lleva a cabo todo el proceso de actualizaci\u00f3n por nosotros:<\/p>\n
\/usr\/lib\/postgresql\/11\/bin\/pg_upgrade \n<b>--enlace <\/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>\nAqu\u00ed es importante se\u00f1alar que antes de iniciar la actualizaci\u00f3n es necesario realizarla con el par\u00e1metro \u2014verificar<\/b>, para asegurarse de que la actualizaci\u00f3n sea posible. Adem\u00e1s, nuestro script realiza el intercambio de configuraciones durante la actualizaci\u00f3n. Nuestro script tard\u00f3 30 segundos en ejecutarse, lo cual es un gran resultado.<\/p>\nIniciar Patroni<\/h3>\n
Para resolver el segundo problema, es suficiente mirar la configuraci\u00f3n de Patroni. En el repositorio oficial hay un ejemplo de configuraci\u00f3n con initdb, que se encarga de inicializar una nueva base de datos en el primer lanzamiento de Patroni. Pero dado que ya tenemos una base de datos lista, simplemente eliminamos esta secci\u00f3n de la configuraci\u00f3n.<\/p>\n
Cuando comenzamos a instalar Patroni en un cl\u00faster de PostgreSQL ya preparado y a ejecutarlo, nos encontramos con un nuevo problema: ambos servidores se iniciaban como l\u00edderes. Patroni no tiene conocimiento del estado previo del cl\u00faster y intenta iniciar ambos servidores como dos cl\u00fasteres separados con el mismo nombre. Para resolver este problema, es necesario eliminar el directorio de datos en el esclavo:<\/p>\n
rm -rf \/var\/lib\/postgresql\/<\/code><\/pre>\n\u00a1Esto solo se debe hacer en el esclavo!<\/b><\/p>\n
Al conectar una r\u00e9plica limpia, Patroni hace un basebackup del l\u00edder y lo restaura en la r\u00e9plica, y luego alcanza el estado actual a trav\u00e9s de los registros wal.<\/p>\n
Otra dificultad que encontramos es que todos los cl\u00fasteres de PostgreSQL se llaman main por defecto. Esto es normal cuando cada cl\u00faster no sabe nada sobre los dem\u00e1s. Pero cuando deseas utilizar Patroni, todos los cl\u00fasteres deben tener un nombre \u00fanico. La soluci\u00f3n es cambiar el nombre del cl\u00faster en la configuraci\u00f3n de PostgreSQL.<\/p>\n
Prueba de carga<\/h3>\n Realizamos una prueba que simula la actividad de los usuarios en los tableros. Cuando la carga alcanz\u00f3 nuestro promedio diario, repetimos exactamente la misma prueba, apagamos una instancia con el l\u00edder de PostgreSQL. El failover autom\u00e1tico funcion\u00f3 como esper\u00e1bamos: Patroni cambi\u00f3 al l\u00edder, Consul-template actualiz\u00f3 la configuraci\u00f3n de PgBouncer y envi\u00f3 el comando para recargar. En nuestros gr\u00e1ficos de Grafana, se pod\u00edan ver retrasos de 20 a 30 segundos y un peque\u00f1o n\u00famero de errores de servidores relacionados con la conexi\u00f3n a la base. Esta es una situaci\u00f3n normal, estos valores son aceptables para nuestro failover y definitivamente son mejores que el tiempo de inactividad del servicio.<\/p>\n
Salida de Patroni en producci\u00f3n<\/h2>\n Al final, obtuvimos el siguiente plan:<\/p>\n
\nDespliegue de Consul-template en los servidores PgBouncer y puesta en marcha;<\/li>\n Actualizaci\u00f3n de PostgreSQL a la versi\u00f3n 11.2;<\/li>\n Cambio del nombre del cl\u00faster;<\/li>\n Inicio del cl\u00faster de Patroni.<\/li>\n<\/ul>\nNuestra esquema permite realizar el primer punto pr\u00e1cticamente en cualquier momento; podemos quitar cada PgBouncer uno por uno de la operaci\u00f3n y realizar el despliegue y el inicio de consul-template. As\u00ed lo hicimos.<\/p>\n
Para una r\u00e1pida implementaci\u00f3n, utilizamos Ansible, ya que hab\u00edamos verificado todos los playbooks en un entorno de prueba, y el tiempo de ejecuci\u00f3n completo del escenario fue de 1,5 a 2 minutos para cada shard. Pod\u00edamos implementar todo de manera secuencial en cada shard sin detener nuestro servicio, pero tendr\u00edamos que apagar cada PostgreSQL durante unos minutos. En este caso, los usuarios cuyos datos est\u00e1n en ese shard no podr\u00edan trabajar plenamente durante ese tiempo, lo cual es inaceptable para nosotros.<\/p>\n
La soluci\u00f3n a esta situaci\u00f3n fue un mantenimiento programado, que realizamos cada 3 meses. Esta es una ventana para trabajos planificados, cuando apagamos completamente nuestro servicio y actualizamos las instancias de base de datos. Quedaba una semana para la pr\u00f3xima ventana, y decidimos simplemente esperar y prepararnos mejor. Durante el tiempo de espera, tomamos precauciones adicionales: para cada shard de PostgreSQL levantamos una r\u00e9plica de respaldo en caso de fallos, para conservar los datos m\u00e1s recientes, y a\u00f1adimos una nueva instancia para cada shard, que deber\u00eda convertirse en una nueva r\u00e9plica en el cl\u00faster Patroni, para no tener que ejecutar el comando de eliminaci\u00f3n de datos. Todo esto ayud\u00f3 a minimizar el riesgo de error.
Reiniciamos nuestro servicio, todo funcion\u00f3 como deb\u00eda, los usuarios continuaron trabajando, pero en los gr\u00e1ficos notamos una carga anormalmente alta en los servidores de Consul.
\u00bfPor qu\u00e9 no vimos esto en el entorno de prueba? Este problema ilustra muy bien que debemos seguir el principio de Infraestructura como c\u00f3digo y desarrollar toda la infraestructura, comenzando desde los entornos de prueba y terminando en producci\u00f3n. De lo contrario, es muy f\u00e1cil enfrentarse a un problema como el que tuvimos. \u00bfQu\u00e9 ocurri\u00f3? Consul apareci\u00f3 primero en producci\u00f3n y luego en los entornos de prueba; como resultado, en los entornos de prueba la versi\u00f3n de Consul era m\u00e1s alta que en producci\u00f3n. Precisamente en una de las versiones se solucion\u00f3 una fuga de CPU al trabajar con consul-template. Por lo tanto, simplemente actualizamos Consul, resolviendo as\u00ed el problema.<\/p>\n
Reiniciar el cl\u00faster Patroni<\/h3>\n Sin embargo, nos encontramos con un nuevo problema, del que ni siquiera sospech\u00e1bamos. Al actualizar Consul, simplemente eliminamos el nodo de Consul del cl\u00faster usando el comando consul leave \u2192 Patroni se conecta a otro servidor de Consul \u2192 todo funciona. Pero cuando llegamos a la \u00faltima instancia del cl\u00faster de Consul y le enviamos el comando consul leave, todos los cl\u00fasteres de Patroni simplemente se reiniciaron, y en los registros vimos el siguiente error:<\/p>\n
ERROR: get_cluster\nTraceback (última llamada más reciente):\n...\nRetryFailedError: 'Se superó el plazo de reintento'\nERROR: Error al comunicarse con DCS\n<b>LOG: el sistema de base de datos está apagado<\/b><\/code><\/pre>\nEl cl\u00faster de Patroni no pudo obtener informaci\u00f3n sobre su cl\u00faster y se reinici\u00f3.<\/p>\n
Para buscar una soluci\u00f3n, nos dirigimos a los creadores de Patroni a trav\u00e9s de un issue en GitHub. Ellos propusieron mejoras a nuestros archivos de configuraci\u00f3n:<\/p>\n
consul:\n consul.checks: []\nbootstrap:\n dcs:\n retry_timeout: 8<\/code><\/pre>\nPudimos reproducir el problema en el entorno de prueba y probamos esos par\u00e1metros all\u00ed, pero, desafortunadamente, no funcionaron.<\/p>\n
El problema sigue sin resolverse. Planeamos probar las siguientes opciones de soluci\u00f3n:<\/p>\n
\nUsar el agente Consul en cada instancia del cl\u00faster Patroni;<\/li>\n Corregir el problema en el c\u00f3digo.<\/li>\n<\/ul>\nEntendemos el origen del error: probablemente la problem\u00e1tica se encuentra en el uso del timeout por defecto, que no se reconfigura a trav\u00e9s del archivo de configuraci\u00f3n. Al eliminar el \u00faltimo servidor Consul del cl\u00faster, todo el cl\u00faster de Consul se congela por m\u00e1s de un segundo, lo que impide que Patroni obtenga el estado del cl\u00faster y reinicia completamente todo el cl\u00faster.<\/p>\n
Afortunadamente, no hemos encontrado m\u00e1s errores.<\/p>\n
Conclusiones sobre el uso de Patroni<\/h2>\n Despu\u00e9s de iniciar con \u00e9xito Patroni, agregamos una r\u00e9plica adicional en cada cl\u00faster. Ahora en cada cl\u00faster hay una especie de qu\u00f3rum: un l\u00edder y dos r\u00e9plicas, para asegurar en caso de un split-brain durante el cambio.
Patroni ha estado funcionando en producci\u00f3n durante m\u00e1s de tres meses. En este tiempo, ya nos ha salvado. Recientemente, el l\u00edder de uno de los cl\u00fasteres en AWS fall\u00f3, se activ\u00f3 el failover autom\u00e1tico y los usuarios continuaron trabajando. Patroni cumpli\u00f3 su tarea principal.<\/p>\n
Un peque\u00f1o resumen sobre el uso de Patroni:<\/b><\/p>\n\nFacilidad para cambiar la configuraci\u00f3n. Basta con modificar la configuraci\u00f3n en una instancia y se aplicar\u00e1 a todo el cl\u00faster. Si se requiere un reinicio para aplicar la nueva configuraci\u00f3n, Patroni lo notificar\u00e1. Patroni puede reiniciar todo el cl\u00faster con un solo comando, lo que tambi\u00e9n es muy conveniente.<\/li>\n El failover autom\u00e1tico funciona y ya nos ha salvado.<\/li>\n Actualizaci\u00f3n de PostgreSQL sin tiempo de inactividad para la aplicaci\u00f3n. Primero hay que actualizar las r\u00e9plicas a la nueva versi\u00f3n, luego cambiar el l\u00edder en el cl\u00faster de Patroni y actualizar al antiguo l\u00edder. En este proceso se realiza la prueba necesaria de failover autom\u00e1tico.<\/li>\n<\/ul>\nFuente: 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
![\"Cl\u00faster](\"\/wp-content\/uploads\/2019\/06\/443f85815b0560fade7db5b639942935.png\")
![\"Cl\u00faster](\"\/wp-content\/uploads\/2019\/06\/674dd77de4c8b48a946c9f64c0b2fdd1.png\")
<\/p>\n![\"Cl\u00faster](\"\/wp-content\/uploads\/2019\/06\/dabcb7f6006520c4fec85fb925e8975e.png\")
<\/p>\n![\"Cl\u00faster](\"\/wp-content\/uploads\/2019\/06\/2c1f1e7d9f7be4fdeb43858520d55e36.png\")
<\/p>\n![\"Cl\u00faster](\"\/wp-content\/uploads\/2019\/06\/8e5350d2466311593e11add30d5b1bdc.png\")
<\/p>\n![\"Cl\u00faster](\"\/wp-content\/uploads\/2019\/06\/3234594b363904424fdce64c9d77fca5.png\")
<\/p>\n![\"Cl\u00faster](\"\/wp-content\/uploads\/2019\/06\/6cf92996a127bb6637ab81dc45fdd60a.png\")
<\/p>\n![\"Cl\u00faster](\"\/wp-content\/uploads\/2019\/06\/bf9a9eff675a26039e3f76b16c6cd713.png\")
<\/p>\n![\"Cl\u00faster](\"\/wp-content\/uploads\/2019\/06\/d670fe373b774f1b52bfd8a8c3b53a21.png\")
<\/p>\n![\"Cl\u00faster](\"\/wp-content\/uploads\/2019\/06\/29e5c5f50dbfebfe5665fa0aeb009728.png\")
<\/p>\n![\"Cl\u00faster](\"\/wp-content\/uploads\/2019\/06\/af0eef9ac235706c0aac62d2e1ee179d.png\")
<\/p>\n![\"Cl\u00faster](\"\/wp-content\/uploads\/2019\/06\/3bb4c0495fea274b04edd2e99b59eacb.png\")
<\/p>\n