Der er behov for yderligere overv\u00e5gning af failover-arbejdet, da vi har 12 PostgreSQL-shards, hvilket betyder, at vi skal overv\u00e5ge 12 klustre. Ved en stigning i antallet af shards skal vi huske at opdatere failover ogs\u00e5.<\/li>\n<\/ul>\nAt skabe en failover-l\u00f8sning fra bunden virker meget komplekst og kr\u00e6ver ikke-triviel support. Med \u00e9n PostgreSQL-klynge vil dette v\u00e6re den simpleste l\u00f8sning, men den kan ikke skaleres, s\u00e5 den passer ikke til os.<\/p>\n
Repmgr<\/h3>\n Replication Manager til PostgreSQL-klynger, som kan styre driften af en PostgreSQL-klynge. Der er dog ikke en automatisk failover \u201cout of the box\u201d, s\u00e5 der kr\u00e6ves en egen \u201cwrapper\u201d oven p\u00e5 den eksisterende l\u00f8sning. Det kan alts\u00e5 vise sig at v\u00e6re endnu mere kompliceret end med skr\u00e6ddersyede scripts, derfor valgte vi endda ikke at afpr\u00f8ve Repmgr.<\/p>\n
AWS RDS<\/h3>\n Den underst\u00f8tter alt det n\u00f8dvendige for os, kan lave backups og underst\u00f8tter en connection pool. Den har automatisk switch: n\u00e5r masteren d\u00f8r, bliver replikaen den nye master, og AWS opdaterer DNS-posten til den nye master, mens replikaerne kan v\u00e6re placeret i forskellige AZ.<\/p>\n
En ulempe er manglen p\u00e5 fine indstillinger. Et eksempel p\u00e5 fine indstillinger: p\u00e5 vores instanser er der begr\u00e6nsninger for TCP-forbindelser, noget der desv\u00e6rre ikke kan g\u00f8res i 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>\nDesuden er prisen p\u00e5 AWS RDS n\u00e6sten dobbelt s\u00e5 h\u00f8j som den normale pris for instanser, hvilket var hoved\u00e5rsagen til at vi valgte ikke at tage denne l\u00f8sning.<\/p>\n
Patroni<\/h3>\n Dette er en skabelon i Python til at administrere PostgreSQL med god dokumentation, automatisk failover og kildekoden tilg\u00e6ngelig p\u00e5 GitHub.<\/p>\n
Fordele ved Patroni:<\/p>\n
\nHver konfigurationsparameter er beskrevet, s\u00e5 det er klart, hvordan tingene fungerer;<\/li>\n Automatisk failover fungerer fra starten;<\/li>\n Skriver i Python, og da vi selv skriver meget i Python, vil det v\u00e6re lettere for os at finde os til rette med problemerne og m\u00e5ske endda hj\u00e6lpe med projektets udvikling;<\/li>\n Styrer fuldst\u00e6ndigt PostgreSQL, tillader \u00e6ndring af konfigurationen p\u00e5 alle noder i klyngen, og hvis en genstart af klyngen kr\u00e6ves for at anvende den nye konfiguration, kan dette ogs\u00e5 g\u00f8res ved hj\u00e6lp af Patroni.<\/li>\n<\/ul>\nUlemper:<\/p>\n
\nFra dokumentationen er det uklart, hvordan man korrekt arbejder med PgBouncer. Selvom det er sv\u00e6rt at betegne som en ulempe, for det er Patronis opgave at styre PostgreSQL, hvordan forbindelser til Patroni h\u00e5ndteres, er vores problem;<\/li>\n Der er f\u00e5 eksempler p\u00e5 implementering af Patroni i stor skala, men mange eksempler p\u00e5 implementering fra bunden.<\/li>\n<\/ul>\nI sidste ende valgte vi netop Patroni til at skabe en failover-klynge.<\/p>\n
Implementeringsprocessen for Patroni<\/h2>\n Inden vi brugte Patroni, havde vi 12 PostgreSQL sharder i en konfiguration med \u00e9n master og \u00e9n replika med asynkron replikation. Applikationsserverne kommunikerede med databaserne via en Network Load Balancer, som havde to instanser med PgBouncer, og bag dem var alle PostgreSQL-serverne.
For at implementere Patroni skulle vi v\u00e6lge et distribueret konfigurationslager for klyngen. Patroni arbejder med distribuerede konfigurationslagre som etcd, Zookeeper og Consul. Vi har allerede et fuldt fungerende Consul-klynge i produktion, som arbejder sammen med Vault, og ellers bruger vi det ikke. Dette er en glimrende mulighed for at begynde at anvende Consul til det, det er beregnet til.<\/p>\n
Hvordan Patroni arbejder med Consul<\/h3>\n Vi har en Consul-klynge, der best\u00e5r af tre noder, og en Patroni-klynge, som best\u00e5r af en leder og en replika (i Patroni kaldes masteren lederen af klyngen, mens slaverne er replikaer). Hver instans af Patroni-klyngen sender konstant oplysninger om klyngets tilstand til Consul. Derfor kan man altid f\u00e5 den aktuelle konfiguration af Patroni-klyngen fra Consul og se, hvem der er lederen lige nu.<\/p>\n
For at forbinde Patroni til Consul er det tilstr\u00e6kkeligt at konsultere den officielle dokumentation, hvor det er angivet, at der skal angives en v\u00e6rt i formatet http eller https afh\u00e6ngigt af, hvordan vi arbejder med Consul, samt en tilslutningsskema, som er valgfri:<\/p>\n
host: v\u00e6rten:port for Consul-endepunktet, i formatet: http(s):\/\/host:port\nscheme: (valgfrit) http eller https, standard er http<\/code><\/pre>\nDet ser simpelt ud, men her begynder udfordringerne. Vi arbejder med Consul via en sikker forbindelse over https, og vores forbindelseskonfiguration vil se s\u00e5ledes ud:<\/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>\nMen det fungerer ikke. Ved opstart kan Patroni ikke forbinde til Consul, fordi det stadig fors\u00f8ger at forbinde via http.<\/p>\n
L\u00f8sningen p\u00e5 problemet fandt vi i koden til Patroni. Heldigvis er den skrevet i Python. Det viser sig, at parameteren host ikke parses korrekt, og protokollen skal angives i scheme. Her er et fungerende konfigurationsblok for at arbejde med Consul hos os:<\/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 S\u00e5, vi har valgt opbevaringen til konfigurationen. Nu skal vi forst\u00e5, hvordan PgBouncer vil skifte sin konfiguration, n\u00e5r lederen i Patroni-klusteret skifter. Der er ikke noget svar p\u00e5 dette i dokumentationen, da arbejdet med PgBouncer overhovedet ikke beskrives.<\/p>\n
I s\u00f8gen efter en l\u00f8sning fandt vi en artikel (titlen kan jeg desv\u00e6rre ikke huske), hvor det blev n\u00e6vnt, at Consul-template var meget nyttig i forbindelsen mellem PgBouncer og Patroni. Dette motiverede os til at unders\u00f8ge, hvordan Consul-template fungerer.<\/p>\n
Det viste sig, at Consul-template konstant overv\u00e5ger PostgreSQL-klusterets konfiguration i Consul. Ved skift af leder opdaterer den PgBouncer-konfigurationen og sender en kommando til at genindl\u00e6se den.<\/p>\n
En stor fordel ved template er, at den opbevares som kode, s\u00e5 n\u00e5r der tilf\u00f8jes en ny shard, er det nok at lave et nyt commit og opdatere template automatisk, hvilket underst\u00f8tter princippet om Infrastructure as code.<\/p>\n
Ny arkitektur med Patroni<\/h3>\n Som resultat fik vi f\u00f8lgende arbejdsscheme:
Alle applikationsservere henvender sig til load balancer \u2192 Bag den st\u00e5r to PgBouncer-instanser \u2192 P\u00e5 hver instans k\u00f8rer Consul-template, som overv\u00e5ger status for hver Patroni-kluster og sikrer, at PgBouncer-konfigurationen, der sender anmodninger til den nuv\u00e6rende leder af hvert kluster, er opdateret.<\/p>\n
Manuel testning<\/h3>\n Vi k\u00f8rte dette scheme i et lille testmilj\u00f8 f\u00f8r udrulning til produktion og kontrollerede, hvordan automatisk skiftede fungerer. Vi \u00e5bnede tavlen, flyttede en klisterm\u00e6rke, og i det \u00f8jeblik 'dr\u00e6bte' vi lederen af klusteret. I AWS er det nok at slukke instansen via konsollen.<\/p>\n
Klisterm\u00e6rket vendte tilbage inden for 10-20 sekunder og begyndte derefter at flytte normalt igen. Det betyder, at Patroni-klusteret fungerede korrekt: det skiftede lederen, sendte information til Consul, og Consul-template greb straks denne information, erstattede PgBouncer-konfigurationen og sendte en kommando til reload.<\/p>\n
Hvordan overlever man under h\u00f8j belastning og bevarer minimal nedetid?<\/h2>\n Det fungerer glimrende! Men der opst\u00e5r nye sp\u00f8rgsm\u00e5l: Hvordan vil det fungere under h\u00f8j belastning? Hvordan udruller man det hurtigt og sikkert i produktion?<\/p>\n
Vi besvarer det f\u00f8rste sp\u00f8rgsm\u00e5l ved hj\u00e6lp af et testmilj\u00f8, hvor vi udf\u00f8rer belastningstest. Det er helt identisk med produktionen i sin arkitektur og har genererede testdata, der omtrent svarer til produktionen i volumen. Vi beslutter os for at \"dr\u00e6be\" en af PostgreSQL-masterne under testen og se, hvad der sker. Men f\u00f8r dette er det vigtigt at kontrollere den automatiske udrulning, da vi har flere PostgreSQL-shards i dette milj\u00f8, s\u00e5 vi f\u00e5r en fremragende test af konfigurationsskripterne inden produktionen.<\/p>\n
Begge opgaver ser ambiti\u00f8se ud, men vi har PostgreSQL 9.6. Skal vi m\u00e5ske straks opgradere til 11.2?<\/p>\n
Vi har besluttet at g\u00f8re dette i 2 faser: f\u00f8rst opgradere versionen til 11.2, derefter starte Patroni.<\/p>\n
Opgradering af PostgreSQL<\/h3>\n For hurtigt at opgradere versionen af PostgreSQL skal der anvendes indstillingen -k<\/b>, som opretter hard links p\u00e5 disken, og der er ikke behov for at kopiere dine data. P\u00e5 databaser med 300-400 GB tager opgraderingen 1 sekund.<\/p>\n
Vi har mange shards, s\u00e5 opgraderingen skal udf\u00f8res automatisk. Til dette har vi skrevet en Ansible playbook, som udf\u00f8rer hele opgraderingsprocessen for os:<\/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>\nHer er det vigtigt at bem\u00e6rke, at f\u00f8r opgraderingen skal den udf\u00f8res med parameteren \u2014check<\/b>, for at v\u00e6re sikker p\u00e5 muligheden for opgraderingen. Vores script h\u00e5ndterer ogs\u00e5 udskiftning af konfigurationsfilerne under opgraderingen. Scriptet blev udf\u00f8rt p\u00e5 30 sekunder, hvilket er et fremragende resultat.<\/p>\nStart af Patroni<\/h3>\n
For at l\u00f8se det andet problem er det tilstr\u00e6kkeligt at se p\u00e5 konfigurationen af Patroni. I det officielle repository findes der et eksempel p\u00e5 en konfiguration med initdb, som er ansvarlig for at initialisere en ny database ved f\u00f8rste opstart af Patroni. Men da vi allerede har en f\u00e6rdig database, har vi blot fjernet dette afsnit fra konfigurationen.<\/p>\n
Da vi begyndte at installere Patroni p\u00e5 den eksisterende PostgreSQL-klynge og starte den, st\u00f8dte vi p\u00e5 et nyt problem: begge servere blev startet som leader. Patroni ved ikke noget om den tidligere tilstand af klyngen og fors\u00f8ger at starte begge servere som to separate klynger med samme navn. For at l\u00f8se dette problem er det n\u00f8dvendigt at slette data mappen p\u00e5 slaven:<\/p>\n
rm -rf \/var\/lib\/postgresql\/<\/code><\/pre>\nDette skal kun g\u00f8res p\u00e5 slaven!<\/b><\/p>\n
N\u00e5r en ren replika forbinder, laver Patroni en basebackup af lederen og genopretter den p\u00e5 replikken, inden den indhenter den aktuelle tilstand via wal-logs.<\/p>\n
Endnu en udfordring, vi stod overfor, var, at alle PostgreSQL-klynger som standard hedder main. N\u00e5r hver klynge ikke kender til de andre, er det fint. Men n\u00e5r du vil bruge Patroni, skal alle klynger have et unikt navn. L\u00f8sningen er at \u00e6ndre klynge-navnet i PostgreSQL-konfigurationen.<\/p>\n
Belastningstest<\/h3>\n Vi k\u00f8rte en test, der simulerer brugeraktivitet p\u00e5 tavlerne. Da belastningen n\u00e5ede vores gennemsnitlige daglige niveau, gentog vi pr\u00e6cist den samme test og slukkede en instans med leader PostgreSQL. Den automatiske failover fungerede som forventet: Patroni skiftede leder, Consul-template opdaterede konfigurationen af PgBouncer og sendte en kommando til opdatering. P\u00e5 vores grafikker i Grafana kunne vi se, at der var forsinkelser p\u00e5 20-30 sekunder og et lille antal fejl fra serverne relateret til databaseforbindelsen. Det er en normal situation, s\u00e5danne v\u00e6rdier er acceptable for vores failover og bestemt bedre end nedetid for tjenesten.<\/p>\n
Patroni-output p\u00e5 produktion<\/h2>\n Resultatet blev, at vi fik f\u00f8lgende plan:<\/p>\n
\nDeployment af Consul-template p\u00e5 PgBouncer-serverne og opstart;<\/li>\n Opdatering af PostgreSQL til version 11.2;<\/li>\n \u00c6ndring af klyngens navn;<\/li>\n Opstart af Patroni-klyngen.<\/li>\n<\/ul>\nVores plan tillader, at vi kan udf\u00f8re det f\u00f8rste punkt p\u00e5 n\u00e6sten ethvert tidspunkt; vi kan tage hver PgBouncer ud af drift en ad gangen og udf\u00f8re deployment og opstart af consul-template p\u00e5 dem. Det gjorde vi.<\/p>\n
Til hurtig udrulning brugte vi Ansible, da vi allerede havde testet alle playbooks i testmilj\u00f8et, og udf\u00f8relsestiden for hele scenariet var fra 1,5 til 2 minutter for hver shard. Vi kunne rulle det ud \u00e9n ad gangen p\u00e5 hver shard uden at stoppe vores service, men det ville kr\u00e6ve, at vi slukkede hver PostgreSQL i et par minutter. I dette tilf\u00e6lde ville brugerne, hvis data findes p\u00e5 denne shard, ikke kunne arbejde ordentligt i mellemtiden, og det er uacceptabelt for os.<\/p>\n
Udvejen ud af denne situation var en planlagt vedligeholdelse, som finder sted hver tredje m\u00e5ned. Dette er et vindue til planlagt arbejde, hvor vi fuldst\u00e6ndig slukker for vores service og opdaterer databaseinstanserne. Der var kun en uge tilbage til det n\u00e6ste vindue, og vi besluttede at vente og forberede os yderligere. I ventetiden tog vi ogs\u00e5 ekstra forholdsregler: For hver PostgreSQL shard oprettede vi en sekund\u00e6r replika som backup i tilf\u00e6lde af fejl for at bevare de nyeste data, og vi tilf\u00f8jede en ny instans for hver shard, som skulle blive en ny replika i Patroni-klyngen for ikke at skulle udf\u00f8re kommandoen til at slette data. Alt dette hjalp med at minimere risikoen for fejl.
Vi genstartede vores service, og alt fungerede som det skulle, brugerne fortsatte med at arbejde, men p\u00e5 graferne bem\u00e6rkede vi en unormalt h\u00f8j belastning p\u00e5 Consul-serverne.
Hvorfor s\u00e5 vi ikke dette i testmilj\u00f8et? Dette problem illustrerer meget godt, at det er n\u00f8dvendigt at f\u00f8lge princippet om Infrastructure as Code og forbedre hele infrastrukturen, fra testmilj\u00f8er til produktion. Ellers kan man nemt f\u00e5 et problem som det, vi fik. Hvad skete der? Consul blev f\u00f8rst introduceret i produktion og derefter i testmilj\u00f8erne, hvilket bet\u00f8d, at versionen af Consul i testmilj\u00f8erne var h\u00f8jere end i produktionen. Netop i en af udgivelserne blev der l\u00f8st et CPU-l\u00e6kageproblem ved brug af consul-template. Derfor opdaterede vi simpelthen Consul for at l\u00f8se problemet.<\/p>\n
Genstart Patroni klynge<\/h3>\n Men vi st\u00f8dte p\u00e5 et nyt problem, som vi ikke engang havde mistanke om. Ved opdateringen af Consul fjerner vi blot en Consul-node fra klyngen med kommandoen consul leave \u2192 Patroni forbinder sig til en anden Consul-server \u2192 alt fungerer. Men da vi n\u00e5ede den sidste instans i Consul-klyngen og sendte den kommandoen consul leave, genstartede alle Patroni-klynger simpelthen, og i loggene s\u00e5 vi f\u00f8lgende fejl:<\/p>\n
FEJL: get_cluster\nTraceback (seneste kald senest):\n...\nRetryFailedError: 'Overskredet forsøgsfrist'\nFEJL: Fejl i kommunikationen med DCS\n<b>LOG: databasesystemet er lukket<\/b><\/code><\/pre>\nPatroni-klyngen kunne ikke f\u00e5 oplysninger om sin klynge og genstartede.<\/p>\n
For at finde en l\u00f8sning kontaktede vi forfatterne af Patroni via en issue p\u00e5 GitHub. De foreslog forbedringer til vores konfigurationsfiler:<\/p>\n
consul:\n consul.checks: []\nbootstrap:\n dcs:\n retry_timeout: 8<\/code><\/pre>\nVi var i stand til at gentage problemet i testmilj\u00f8et og teste disse parametre der, men desv\u00e6rre fungerede de ikke.<\/p>\n
Problemet er stadig uafklaret. Vi planl\u00e6gger at pr\u00f8ve f\u00f8lgende l\u00f8sningsmuligheder:<\/p>\n
\nBruge Consul-agent p\u00e5 hver instans i Patroni-klyngen;<\/li>\n Korrigere problemet i koden.<\/li>\n<\/ul>\nVi forst\u00e5r, hvor fejlen opst\u00e5r: sandsynligvis er problemet med brugen af standard tidsgr\u00e6nsen, som ikke bliver overskrevet i konfigurationsfilen. N\u00e5r den sidste Consul-server fjernes fra klyngen, fryser hele Consul-klyngen i mere end et sekund, hvilket g\u00f8r, at Patroni ikke kan f\u00e5 klyngens status og genstarter hele klyngen.<\/p>\n
Heldigvis har vi ikke st\u00f8dt p\u00e5 flere fejltagelser.<\/p>\n
Resultater af brugen af Patroni<\/h2>\n Efter den vellykkede opstart af Patroni tilf\u00f8jede vi en ekstra replik i hver klynge. Nu har hver klynge en form for flertalsafstemning: en leder og to replikaer, for at v\u00e6re sikker i tilf\u00e6lde af split-brain under skift.
Patroni har fungeret i mere end tre m\u00e5neder i produktionen. I l\u00f8bet af denne tid har det allerede hjulpet os. For nylig d\u00f8de lederen af en af klyngerne i AWS, automatisk failover blev aktiveret, og brugerne fortsatte med at arbejde. Patroni udf\u00f8rte sin hovedopgave.<\/p>\n
En lille opsummering af brugen af Patroni:<\/b><\/p>\n\nNem \u00e6ndring af konfigurationen. Det er tilstr\u00e6kkeligt at \u00e6ndre konfigurationen p\u00e5 en instans, og den vil blive anvendt p\u00e5 hele klyngen. Hvis en genstart er n\u00f8dvendig for at anvende den nye konfiguration, vil Patroni informere om det. Patroni kan genstarte hele klyngen med \u00e9n enkelt kommando, hvilket ogs\u00e5 er meget praktisk.<\/li>\n Den automatiske failover fungerer og har allerede hjulpet os.<\/li>\n Opdatering af PostgreSQL uden nedetid for applikationen. Det er n\u00f8dvendigt f\u00f8rst at opdatere replikaerne til den nye version, derefter skifte lederen i Patroni-klyngen og opdatere den gamle leder. I denne proces foretages den n\u00f8dvendige test af den automatiske failover.<\/li>\n<\/ul>\nKilde: 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
![\"Failoverklynge](\"\/wp-content\/uploads\/2019\/06\/443f85815b0560fade7db5b639942935.png\")
![\"Failoverklynge](\"\/wp-content\/uploads\/2019\/06\/674dd77de4c8b48a946c9f64c0b2fdd1.png\")
<\/p>\n![\"Failoverklynge](\"\/wp-content\/uploads\/2019\/06\/dabcb7f6006520c4fec85fb925e8975e.png\")
<\/p>\n![\"Failoverklynge](\"\/wp-content\/uploads\/2019\/06\/2c1f1e7d9f7be4fdeb43858520d55e36.png\")
<\/p>\n![\"Failoverklynge](\"\/wp-content\/uploads\/2019\/06\/8e5350d2466311593e11add30d5b1bdc.png\")
<\/p>\n![\"Failoverklynge](\"\/wp-content\/uploads\/2019\/06\/3234594b363904424fdce64c9d77fca5.png\")
<\/p>\n![\"Failoverklynge](\"\/wp-content\/uploads\/2019\/06\/6cf92996a127bb6637ab81dc45fdd60a.png\")
<\/p>\n![\"Failoverklynge](\"\/wp-content\/uploads\/2019\/06\/bf9a9eff675a26039e3f76b16c6cd713.png\")
<\/p>\n![\"Failoverklynge](\"\/wp-content\/uploads\/2019\/06\/d670fe373b774f1b52bfd8a8c3b53a21.png\")
<\/p>\n![\"Failoverklynge](\"\/wp-content\/uploads\/2019\/06\/29e5c5f50dbfebfe5665fa0aeb009728.png\")
<\/p>\n![\"Failoverklynge](\"\/wp-content\/uploads\/2019\/06\/af0eef9ac235706c0aac62d2e1ee179d.png\")
<\/p>\n![\"Failoverklynge](\"\/wp-content\/uploads\/2019\/06\/3bb4c0495fea274b04edd2e99b59eacb.png\")
<\/p>\n