<\/a><\/noindex><\/p>\nAinsi, voici ce que l'exp\u00e9rience nous a offert<\/h2>\n <\/p>\n
Oui, une n\u0153ud tomb\u00e9e n'est pas une trag\u00e9die. C'est justement le principe de tol\u00e9rance aux pannes de Cassandra. Mais une n\u0153ud peut \u00eatre op\u00e9rationnelle tout en commen\u00e7ant \u00e0 ralentir en performance.<\/b>. Il s'est av\u00e9r\u00e9 que cela se r\u00e9percute imm\u00e9diatement sur la performance de l'ensemble du cluster.<\/p>\n
<\/p>\n
Cassandra ne vous prot\u00e8gera pas l\u00e0 o\u00f9 Oracle a sauv\u00e9 gr\u00e2ce \u00e0 ses contraintes.<\/b>. Et si l'auteur de l'application n'a pas compris cela \u00e0 l'avance, un doublon pour Cassandra n'est pas moins bon que l'original. Une fois qu'il est arriv\u00e9, mettons-le tout de m\u00eame.<\/p>\n
<\/p>\n
La version gratuite de Cassandra \u00ab pr\u00eate \u00e0 l'emploi \u00bb a tr\u00e8s vite d\u00e9plu \u00e0 la s\u00e9curit\u00e9 informatique : Il n'y a pas de journalisation des actions des utilisateurs ni de s\u00e9paration des droits.<\/b>L'information sur les appels est consid\u00e9r\u00e9e comme des donn\u00e9es personnelles, ce qui signifie que toute tentative d'y acc\u00e9der ou de les modifier doit \u00eatre journalis\u00e9e avec la possibilit\u00e9 d'un audit ult\u00e9rieur. Il faut \u00e9galement comprendre la n\u00e9cessit\u00e9 de s\u00e9parer les droits \u00e0 diff\u00e9rents niveaux pour diff\u00e9rents utilisateurs. Un simple ing\u00e9nieur d'exploitation et un super administrateur, qui peut librement supprimer tout le keyspace - ce sont des r\u00f4les diff\u00e9rents, avec des responsabilit\u00e9s et des comp\u00e9tences diff\u00e9rentes. Sans cette s\u00e9paration des droits d'acc\u00e8s, la valeur et l'int\u00e9grit\u00e9 des donn\u00e9es seront mises en question plus rapidement qu'avec un niveau de coh\u00e9rence ANY. <\/p>\n
<\/p>\n
Nous n'avons pas pris en compte que les appels n\u00e9cessitent \u00e0 la fois une analyse s\u00e9rieuse et des \u00e9chantillons p\u00e9riodiques selon divers crit\u00e8res. \u00c9tant donn\u00e9 que les enregistrements s\u00e9lectionn\u00e9s sont suppos\u00e9s \u00eatre supprim\u00e9s et r\u00e9\u00e9crits (dans le cadre de la t\u00e2che, nous devons maintenir le processus d'actualisation des donn\u00e9es lorsque les donn\u00e9es initialement re\u00e7ues dans notre syst\u00e8me sont incorrectes), Cassandra ici ne nous est d'aucune aide. Cassandra, comme une tirelire \u2013 il est pratique d'y stocker, mais vous ne pourrez pas effectuer de calculs.<\/b><\/p>\n
<\/p>\n
Nous avons rencontr\u00e9 un probl\u00e8me de transfert de donn\u00e9es vers les zones de test.<\/b> (5 n\u0153uds en test contre 20 en production). Dans ce cas, il ne sera pas possible d'utiliser un dump.<\/p>\n
<\/p>\n
Probl\u00e8me de mise \u00e0 jour du sch\u00e9ma de donn\u00e9es de l'application qui \u00e9crit dans Cassandra. Un rollback va g\u00e9n\u00e9rer un grand nombre de tombstones, ce qui peut de mani\u00e8re impr\u00e9visible affecter nos performances.<\/b>Cassandra est optimis\u00e9e pour l'\u00e9criture, et avant d'\u00e9crire, elle ne r\u00e9fl\u00e9chit pas beaucoup. Toute op\u00e9ration sur des donn\u00e9es existantes est \u00e9galement une \u00e9criture. C'est-\u00e0-dire qu'en supprimant des donn\u00e9es superflues, nous allons simplement multiplier les enregistrements, et seule une partie d'entre eux sera marqu\u00e9e comme tombstones.<\/p>\n
<\/p>\n
Timeouts lors des insertions. Cassandra est excellente pour l'\u00e9criture, mais parfois le flux entrant peut la rendre consid\u00e9rablement perplexe.<\/b>Cela se produit lorsque l'application commence \u00e0 faire circuler plusieurs enregistrements qu'il est impossible d'ins\u00e9rer pour une raison quelconque. Et nous aurons besoin d'un v\u00e9ritable DBA qui surveillera gc.log, les journaux syst\u00e8me et de d\u00e9bogage \u00e0 la recherche de requ\u00eates lentes, ainsi que des m\u00e9triques sur le compactage en attente.\n<\/p>\n
<\/p>\n
Plusieurs centres de donn\u00e9es dans le cluster. D'o\u00f9 lire et o\u00f9 \u00e9crire ?<\/b>
<\/p>\n
Comment nous avons r\u00e9solu<\/h2>\n <\/p>\n
Pour \u00e9viter que le n\u0153ud ne ralentisse, nous avons d\u00e9sactiv\u00e9 le SWAP.<\/b>. Et maintenant, en cas de manque de m\u00e9moire, le n\u0153ud doit tomber au lieu de cr\u00e9er de longues pauses de GC.<\/p>\n
<\/p>\n
Ainsi, nous ne comptons plus sur la logique dans la base de donn\u00e9es. Les d\u00e9veloppeurs de l'application se r\u00e9\u00e9duquent et commencent \u00e0 se prot\u00e9ger activement dans leur propre code.<\/b> Une s\u00e9paration parfaite entre le stockage et le traitement des donn\u00e9es.<\/p>\n
<\/p>\n
Nous avons achet\u00e9 du support de DataStax.<\/b> La version bo\u00eete de Cassandra n'est plus d\u00e9velopp\u00e9e (dernier commit en f\u00e9vrier 2018). En m\u00eame temps, Datastax propose un excellent service et un grand nombre de solutions adapt\u00e9es aux syst\u00e8mes d'information existants.<\/p>\n
<\/p>\n
Je tiens \u00e9galement \u00e0 souligner que Cassandra n'est pas tr\u00e8s pratique pour les requ\u00eates de s\u00e9lection. Bien s\u00fbr, CQL est un grand pas vers les utilisateurs (compar\u00e9 \u00e0 Thrift). Mais si vous avez des d\u00e9partements entiers habitu\u00e9s \u00e0 des jointures pratiques, \u00e0 une filtration libre par n'importe quel champ et \u00e0 des possibilit\u00e9s d'optimisation des requ\u00eates, et que ces d\u00e9partements travaillent pour r\u00e9soudre des probl\u00e8mes et des urgences, alors une solution bas\u00e9e sur Cassandra leur para\u00eet hostile et insens\u00e9e. Et nous avons commenc\u00e9 \u00e0 chercher comment aider nos coll\u00e8gues \u00e0 r\u00e9aliser des s\u00e9lection. <\/p>\n
<\/p>\n
Nous avons envisag\u00e9 deux options. Dans la premi\u00e8re option, nous \u00e9crivons des appels non seulement dans C*, mais aussi dans la base de donn\u00e9es Oracle archiviste. Cependant, contrairement \u00e0 C*, cette base de donn\u00e9es ne stocke que les appels du mois en cours (une profondeur de stockage ad\u00e9quate pour les cas de re-tarification). Ici, un probl\u00e8me se posait imm\u00e9diatement : si nous \u00e9crivons de mani\u00e8re synchrone, nous perdons tous les avantages de C* li\u00e9s \u00e0 une insertion rapide ; si nous \u00e9crivons de mani\u00e8re asynchrone, il n'y a aucune garantie que tous les appels n\u00e9cessaires aient \u00e9t\u00e9 enregistr\u00e9s dans Oracle. Mais il y avait un seul, mais grand, avantage : pour l'exploitation, nous avons toujours le PL\/SQL Developer familier, c'est-\u00e0-dire que nous pourrions pratiquement r\u00e9aliser le pattern \u00ab Fa\u00e7ade \u00bb. Option alternative. Nous mettons en \u0153uvre un m\u00e9canisme qui extrait les appels de C*, tire certaines donn\u00e9es pour enrichir \u00e0 partir des tableaux correspondants dans Oracle, joint les r\u00e9sultats obtenus et nous donne le r\u00e9sultat final, que nous utiliserons ensuite d'une mani\u00e8re ou d'une autre (rollback, r\u00e9ex\u00e9cution, analyse, admiration). Inconv\u00e9nients : le processus s'av\u00e8re assez complexe et, de plus, il n'y a pas d'interface pour les employ\u00e9s de l'exploitation.<\/p>\n
<\/p>\n
Au final, nous avons tout de m\u00eame opt\u00e9 pour la deuxi\u00e8me option. Pour les s\u00e9lections de diff\u00e9rentes bases, nous avons utilis\u00e9 Apache Spark.<\/b> L'essence du m\u00e9canisme se r\u00e9sume \u00e0 un code Java qui, en fonction des cl\u00e9s sp\u00e9cifi\u00e9es (abonn\u00e9, heure de l'appel \u2013 cl\u00e9s de la section), extrait des donn\u00e9es de C* et \u00e9galement les donn\u00e9es n\u00e9cessaires pour enrichir \u00e0 partir de toute autre base de donn\u00e9es. Ensuite, il les joint dans sa m\u00e9moire et affiche le r\u00e9sultat dans la table de r\u00e9sultats. Nous avons dessin\u00e9 une interface web sur Spark et cela s'est av\u00e9r\u00e9 tout \u00e0 fait exploitable.<\/p>\n
\n
Lors de la r\u00e9solution du probl\u00e8me de mise \u00e0 jour des donn\u00e9es, nous avons de nouveau examin\u00e9 plusieurs fa\u00e7ons de proc\u00e9der. Tant le transfert via Sstloader que la solution consistant \u00e0 diviser le cluster en zone de test en deux parties, chacune se connectant alternativement \u00e0 un cluster de production, aliment\u00e9 de cette mani\u00e8re. Lors de la mise \u00e0 jour du test, il \u00e9tait pr\u00e9vu de les \u00e9changer : la partie qui a fonctionn\u00e9 dans le test serait nettoy\u00e9e et introduite en production, tandis que l'autre commencerait \u00e0 travailler avec les donn\u00e9es s\u00e9par\u00e9ment. Cependant, apr\u00e8s y avoir r\u00e9fl\u00e9chi \u00e0 nouveau, nous avons mieux \u00e9valu\u00e9 les donn\u00e9es \u00e0 transf\u00e9rer et compris que les appels eux-m\u00eames sont une entit\u00e9 non coh\u00e9rente pour les tests, g\u00e9n\u00e9r\u00e9e rapidement en cas de besoin, et que l'ensemble de donn\u00e9es de production n'a pas de valeur \u00e0 transf\u00e9rer dans le test. Il y a plusieurs objets accumulants qui m\u00e9ritent d'\u00eatre transf\u00e9r\u00e9s, mais ce ne sont litt\u00e9ralement que quelques tables, et pas tr\u00e8s lourdes. Donc, nous comme solution, Spark a de nouveau \u00e9t\u00e9 utile, gr\u00e2ce auquel nous avons \u00e9crit et commenc\u00e9 \u00e0 utiliser activement un script de transfert des donn\u00e9es entre les tables de production et de test.<\/b><\/p>\n
<\/p>\n
Notre politique actuelle de d\u00e9ploiement nous permet de travailler sans rollback.<\/b> Avant la production, un d\u00e9ploiement obligatoire a lieu sur le test, o\u00f9 l'erreur n'est pas si co\u00fbteuse. En cas d'\u00e9chec, il est toujours possible de supprimer le keyspace et de red\u00e9ployer toute la sch\u00e9ma depuis le d\u00e9but.<\/p>\n
<\/p>\n
Pour assurer une disponibilit\u00e9 continue de Cassandra, il faut un DBA et bien plus encore. Tous ceux qui travaillent avec l'application doivent comprendre o\u00f9 et comment suivre l'\u00e9tat actuel et comment diagnostiquer les probl\u00e8mes \u00e0 temps.<\/b> Pour cela, nous utilisons activement DataStax OpsCenter (Administration et surveillance des charges de travail), les m\u00e9triques syst\u00e8me du Cassandra Driver (nombre de timeouts d'\u00e9criture dans C*, nombre de timeouts de lecture dans C*, latence maximale, etc.), nous surveillons le fonctionnement de l'application elle-m\u00eame, qui fonctionne avec Cassandra.\n<\/p>\n
<\/p>\n
Lorsque nous avons r\u00e9fl\u00e9chi \u00e0 la question pr\u00e9c\u00e9dente, nous avons compris o\u00f9 se cachait notre principal risque. Ce sont les formes d'affichage des donn\u00e9es, qui tirent des informations de plusieurs requ\u00eates ind\u00e9pendantes les unes des autres vers le stockage. Nous pouvons ainsi obtenir des informations plut\u00f4t incoh\u00e9rentes. Mais ce probl\u00e8me serait tout aussi pertinent m\u00eame si nous ne travaillions qu'avec un seul centre de donn\u00e9es. Donc, la meilleure chose \u00e0 faire ici est, bien s\u00fbr, de cr\u00e9er une fonction batch de lecture des donn\u00e9es dans une application externe, qui garantira l\u2019obtention des donn\u00e9es dans une p\u00e9riode de temps unifi\u00e9e. En ce qui concerne la s\u00e9paration entre lecture et \u00e9criture en termes de performance, le risque qui nous a arr\u00eat\u00e9 est que lors d'une perte de connexion entre les centres de donn\u00e9es, nous pourrions obtenir deux clusters totalement incoh\u00e9rents entre eux.<\/p>\n
<\/p>\n
Au final, \u00e0 ce jour nous avons opt\u00e9 pour le niveau de coh\u00e9rence d'\u00e9criture EACH_QUORUM et de lecture LOCAL_QUORUM<\/b><\/p>\n
<\/p>\n
Impressions et conclusions en bref<\/h2>\n <\/p>\n
Pour \u00e9valuer la solution obtenue du point de vue du support op\u00e9rationnel et des perspectives de d\u00e9veloppement futur, nous avons d\u00e9cid\u00e9 de r\u00e9fl\u00e9chir \u00e0 d'autres domaines o\u00f9 ce d\u00e9veloppement pourrait \u00eatre appliqu\u00e9.<\/p>\n
<\/p>\n
\u00c0 br\u00fble-pourpoint, le scoring des donn\u00e9es pour des programmes comme \u00ab Payez quand cela vous arrange \u00bb (nous chargeons l'information dans S* et calculons avec des scripts Spark), la gestion des r\u00e9clamations avec agr\u00e9gation par d\u00e9partements, le stockage des r\u00f4les et le calcul selon la matrice des droits d'acc\u00e8s des utilisateurs. <\/p>\n
<\/p>\n
Comme nous le voyons, le r\u00e9pertoire est large et vari\u00e9. Et si nous devions choisir un camp entre les partisans et les opposants de NoSQL, nous rejoindrions les partisans, car nous avons obtenu des avantages, exactement l\u00e0 o\u00f9 nous le souhaitions.<\/p>\n
<\/p>\n
M\u00eame la version standard de Cassandra permet un scaling horizontal en temps r\u00e9el, r\u00e9solvant de mani\u00e8re totalement indolore la question de l'augmentation des donn\u00e9es dans le syst\u00e8me. Nous avons r\u00e9ussi \u00e0 isoler dans un contour distinct un m\u00e9canisme hautement charg\u00e9 pour le calcul des agr\u00e9gats d'appels, ainsi qu'\u00e0 s\u00e9parer le sch\u00e9ma et la logique de l'application, en nous d\u00e9barrassant de la pratique n\u00e9faste d'\u00e9crire des jobs et objets personnalis\u00e9s directement dans la base de donn\u00e9es. Nous avons obtenu la possibilit\u00e9 de choisir et de configurer, pour am\u00e9liorer la vitesse, dans quels centres de donn\u00e9es nous effectuerons le calcul et dans lesquels nous enregistrerons les donn\u00e9es, nous prot\u00e9geant ainsi contre les pannes tant de n\u0153uds individuels que des centres de donn\u00e9es dans leur ensemble.<\/p>\n
<\/p>\n
En appliquant notre architecture \u00e0 de nouveaux projets, et d\u00e9j\u00e0 avec un certain niveau d'exp\u00e9rience, il serait souhaitable de prendre imm\u00e9diatement en compte les nuances d\u00e9crites ci-dessus et d'\u00e9viter certaines erreurs, ainsi que d'adoucir quelques angles qui n'ont pas pu \u00eatre \u00e9vit\u00e9s au d\u00e9part.<\/p>\n
<\/p>\n
Par exemple, surveiller en temps r\u00e9el les mises \u00e0 jour de Cassandra<\/b>, car de nombreux probl\u00e8mes que nous avons rencontr\u00e9s \u00e9taient d\u00e9j\u00e0 connus et avaient \u00e9t\u00e9 corrig\u00e9s.<\/p>\n
<\/p>\n
Ne pas installer la base de donn\u00e9es et Spark sur les m\u00eames n\u0153uds<\/b> ou les s\u00e9parer strictement en fonction de l'utilisation autoris\u00e9e des ressources, car Spark peut consommer plus de m\u00e9moire vive que pr\u00e9vu, ce qui pourrait rapidement entra\u00eener le probl\u00e8me num\u00e9ro 1 de notre liste.<\/p>\n
<\/p>\n
Am\u00e9liorer le monitoring et la comp\u00e9tence op\u00e9rationnelle d\u00e8s la phase de test du projet. <\/b>Prendre en compte au maximum tous les consommateurs potentiels de notre solution<\/b>, car cela d\u00e9pendra finalement de la structure de la base de donn\u00e9es.<\/p>\n
<\/p>\n
Passer plusieurs fois en revue le sch\u00e9ma obtenu pour identifier les possibilit\u00e9s d'optimisation. D\u00e9terminer quels champs peuvent \u00eatre s\u00e9rialis\u00e9s. Comprendre quelles tables suppl\u00e9mentaires nous devons cr\u00e9er pour tenir compte de mani\u00e8re pr\u00e9cise et optimale des donn\u00e9es, et les restituer efficacement sur demande (par exemple, en consid\u00e9rant que les m\u00eames donn\u00e9es peuvent \u00eatre stock\u00e9es dans diff\u00e9rentes tables, selon divers crit\u00e8res de r\u00e9partition, ce qui peut consid\u00e9rablement \u00e9conomiser le temps processeur lors des requ\u00eates de lecture).<\/p>\n
<\/p>\n
Pas mal pr\u00e9voir imm\u00e9diatement l'ajout de TTL et le nettoyage des donn\u00e9es obsol\u00e8tes.<\/b><\/p>\n
<\/p>\n
Lors de l'extraction des donn\u00e9es de Cassandra la logique de l'application doit fonctionner selon le principe de FETCH, pour que toutes les lignes ne soient pas charg\u00e9es en m\u00e9moire d'un coup, mais soient s\u00e9lectionn\u00e9es par lots.<\/b><\/p>\n
<\/p>\n
Il est pr\u00e9f\u00e9rable de v\u00e9rifier la r\u00e9silience du syst\u00e8me avant de transf\u00e9rer le projet vers la solution d\u00e9crite. en r\u00e9alisant une s\u00e9rie de tests de r\u00e9sistance<\/b>, tels que la perte de donn\u00e9es dans un centre de donn\u00e9es, la restauration des donn\u00e9es alt\u00e9r\u00e9es sur une certaine p\u00e9riode, et les baisses de r\u00e9seau entre les centres de donn\u00e9es. De tels tests permettront non seulement d'\u00e9valuer les avantages et les inconv\u00e9nients de l'architecture propos\u00e9e, mais fourniront \u00e9galement une bonne pratique aux ing\u00e9nieurs qui les r\u00e9alisent, et cette comp\u00e9tence ne sera pas de trop en cas de pannes syst\u00e8me en production.<\/p>\n
<\/p>\n
Lorsqu'il s'agit de traiter des informations critiques (telles que les donn\u00e9es de facturation ou le calcul des dettes des abonn\u00e9s), il convient \u00e9galement de pr\u00eater attention aux outils qui permettent de r\u00e9duire les risques li\u00e9s aux particularit\u00e9s des SGBD. Par exemple, utiliser l'outil nodesync (Datastax) en \u00e9laborant une strat\u00e9gie optimale pour son utilisation afin de ne pas cr\u00e9er une surcharge excessive sur Cassandra pour des raisons de coh\u00e9rence<\/b> et de l'utiliser uniquement pour certaines tables pendant des p\u00e9riodes sp\u00e9cifiques.<\/p>\n
<\/p>\n
Alors, apr\u00e8s six mois de vie avec Cassandra ? Globalement, il n'y a pas de probl\u00e8mes non r\u00e9solus. Nous n'avons pas non plus subi de graves pannes ou de pertes de donn\u00e9es. Oui, il a fallu r\u00e9fl\u00e9chir \u00e0 la compensation de certains probl\u00e8mes qui n'\u00e9taient pas apparus auparavant, mais au final, cela n'a pas terni notre solution architecturale. Si vous \u00eates pr\u00eat \u00e0 essayer quelque chose de nouveau et que vous ne craignez pas d'\u00eatre d\u00e9\u00e7u, pr\u00e9parez-vous \u00e0 ce que rien ne soit gratuit. Vous devrez vous plonger dans la documentation et rencontrer plus souvent vos propres obstacles que dans une solution legacy ancienne, et aucune th\u00e9orie ne pourra vous indiquer \u00e0 l'avance quels obstacles vous attendent.<\/p>\n
Source : habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0413\u043e\u0432\u043e\u0440\u044f\u0442, \u0432 \u0436\u0438\u0437\u043d\u0438 \u0432\u0441\u0435 \u0441\u0442\u043e\u0438\u0442 \u043f\u043e\u043f\u0440\u043e\u0431\u043e\u0432\u0430\u0442\u044c \u0445\u043e\u0442\u044f \u0431\u044b \u0440\u0430\u0437. \u0418 \u0435\u0441\u043b\u0438 \u0432\u044b \u043f\u0440\u0438\u0432\u044b\u043a\u043b\u0438 \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c \u0441 \u0440\u0435\u043b\u044f\u0446\u0438\u043e\u043d\u043d\u044b\u043c\u0438 \u0421\u0423\u0411\u0414, \u0442\u043e \u043f\u043e\u0437\u043d\u0430\u043a\u043e\u043c\u0438\u0442\u044c\u0441\u044f \u043d\u0430 \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0435 \u0441 NoSQL \u0441\u0442\u043e\u0438\u0442 \u0432 \u043f\u0435\u0440\u0432\u0443\u044e \u043e\u0447\u0435\u0440\u0435\u0434\u044c \u0445\u043e\u0442\u044f \u0431\u044b \u0434\u043b\u044f \u043e\u0431\u0449\u0435\u0433\u043e \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u044f. \u0421\u0435\u0439\u0447\u0430\u0441 \u0432 \u0441\u0438\u043b\u0443 \u0431\u0443\u0440\u043d\u043e\u0433\u043e \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u044f \u044d\u0442\u043e\u0439 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0438 \u043e\u0447\u0435\u043d\u044c \u043c\u043d\u043e\u0433\u043e \u043f\u0440\u043e\u0442\u0438\u0432\u043e\u0440\u0435\u0447\u0438\u0432\u044b\u0445 \u043c\u043d\u0435\u043d\u0438\u0439 \u0438 \u0433\u043e\u0440\u044f\u0447\u0438\u0445 \u0441\u043f\u043e\u0440\u043e\u0432 \u043d\u0430 \u044d\u0442\u0443 \u0442\u0435\u043c\u0443, \u0447\u0442\u043e \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e \u043f\u043e\u0434\u043e\u0433\u0440\u0435\u0432\u0430\u0435\u0442 \u0438\u043d\u0442\u0435\u0440\u0435\u0441. \u0415\u0441\u043b\u0438 \u0432\u043d\u0438\u043a\u043d\u0443\u0442\u044c […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":28210,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-37585","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Comment](\"\/wp-content\/uploads\/2019\/08\/4845d37a9928f888639c4ebeb7807787.jpg\")
![\"Comment](\"\/wp-content\/uploads\/2019\/08\/c7b095dc8879011adb751c96427af512.jpg\")
<\/p>\n