{"id":36393,"date":"2019-10-31T22:11:24","date_gmt":"2019-10-31T19:11:24","guid":{"rendered":"https:\/\/prohoster.info\/blog\/failover-nas-gubit-perfektsionizm-i-len\/"},"modified":"2019-10-31T22:11:24","modified_gmt":"2019-10-31T19:11:24","slug":"failover-nas-gubit-perfektsionizm-i-len","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/failover-nas-gubit-perfektsionizm-i-len","title":{"rendered":"Failover: perfectionism and\u2026 laziness can ruin us","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

In the summer, both consumer activity and the intensity of changes in web project infrastructure traditionally decrease, as Captain Obvious tells us. Simply because even IT professionals sometimes take vacations. And so do CTOs. It's tougher for those who remain on duty, but that's not the main topic: perhaps this is why summer is the best time to calmly reconsider the existing backup scheme and develop a plan for its improvement. E\u0433\u043e\u0440 \u0410\u043d\u0434\u0440\u0435\u0435\u0432's experience will be useful in this regard from AdminDivision<\/a><\/noindex>, which he shared at the conference Uptime day<\/a><\/noindex>.<\/i><\/p>\n

When building backup sites and dealing with backups, there are several pitfalls that one can fall into. And we definitely shouldn't fall into them. What ruins us in all this, as in many other things, is perfectionism and\u2026 laziness. We try to do everything perfectly, but perfection is not necessary! We should only focus on certain things, but do them right, finish them, so that they work properly. <\/p>\n

Failover is not just some fun thing to have; it\u2019s something that should do one clear thing\u2014reduce downtime so that the service and company lose less money. In all backup methods, I suggest thinking in the following context: where is the money?<\/p>\n

\"Failover:
\n<\/a><\/noindex>
\nThe first pitfall<\/b>: when we build large reliable systems and work on backups, we reduce the number of failures. This is a terrible misconception. When we manage backups, we are likely increasing the number of failures instead. And if we do everything correctly, we can reduce the overall downtime. There will be more failures, but they will occur with lower costs. After all, what is backup?\u2014it\u2019s system complexity. Any complexity is bad: we have more screws, more gears, in short, more elements\u2014thus, the chance of breakage increases. And they really will break. And they will break more often. A simple example: let\u2019s say we have some website with PHP, MySQL, and it urgently needs to be backed up. <\/p>\n

No, (c) We are taking the second site, building an identical system... The complexity doubles \u2014 we have two entities. Additionally, we are layering specific data transfer logic from one site to another \u2014 that is, data replication, static content copying, and so on. So, the replication logic is usually very complex, and therefore the cumulative complexity of the system can be not 2, but 3, 5, or even 10 times greater. <\/p>\n

The second trap<\/b>: when we build truly large complex systems, we fantasize about what we ultimately want to achieve. Voila: we want a super-reliable system that works with no downtime at all, switches in half a second (or better yet, instantly), and we start to turn our dreams into reality. But there is also a nuance here: the smaller the desired switching time, the more complex the system logic becomes. The more complicated we have to make this logic, the more often the system will fail. And one can find themselves in a very unpleasant situation: we are trying by all means to reduce downtime, but in reality, we are complicating everything, and when something goes wrong, the downtime ends up being greater. Often you catch yourself thinking: better not to reserve. It would be better if it worked alone with a clear downtime. <\/p>\n

How can we counter this? We need to stop lying to ourselves, stop flattering ourselves that we are going to build a spaceship, but realistically understand how long the project might take. And based on this maximum time, we will choose the methods we will use to increase the reliability of our system. <\/p>\n

\"Failover:
\n
\nIt's time for 'stories from life'... from life, of course. <\/p>\n

Example number one<\/h4>\n

\nPredstavljajte si spletno vizitko cevi\u0161ke tovarne \u0161tevilka 1 v mestu N. Na njej je v velikih \u010drkah napisano \u2013 CEVI\u0160KA TOVARNA \u0160TEVILKA 1. Malo ni\u017eje je slogan: \u201eNa\u0161e cevi so najbolj okrogle cevi v N\u201c. In spodaj je telefonska \u0161tevilka generalnega direktorja ter njegovo ime. Zavedamo se, da je treba rezervirati \u2013 to je zelo pomembna stvar! Za\u010dnemo raziskovati, iz \u010desa vse to sestavlja. Html-stati\u010dnost \u2013 torej nekaj slik, kjer generalni direktor sedi za mizo v savni s svojim partnerjem in razpravljata o kak\u0161ni trenutni pogodbi. Za\u010dnemo razmi\u0161ljati o \u010dasu nedelovanja. Na misel mi pride: tam le\u017eati je treba pet minut, ne ve\u010d. In tukaj se postavi vpra\u0161anje: koliko prodaj je bilo sploh s te na\u0161e spletne strani? Koliko, koliko? Kaj pomeni \u201eni\u010d\u201c? To pomeni, da so vse \u0161tiri pogodbe iz preteklega leta generalni direktor sklenil za isto mizo, s tistimi istimi ljudmi, s katerimi hodijo v savno in sedijo za mizo. In ugotavljamo, da tudi \u010de bi spletna stran en dan le\u017eala \u2013 ne bi bilo ni\u010d stra\u0161nega. <\/p>\n

Glede na izhodi\u0161\u010da imamo dan za dvig te zgodbe. Za\u010dnemo razmi\u0161ljati o shemi rezervacije. In izberemo najbolj idealno shemo za rezervacijo v tem primeru: rezervacije ne potrebujemo. Vse to lahko dvigne kateri koli administrator v pol ure z odmori. Namestiti spletni stre\u017enik, nalo\u017eiti datoteke \u2013 vse. Delovalo bo. Ni\u010desar ni treba spremljati, ni\u010desar ni treba posebej pozorni. Torej, zaklju\u010dek iz primera \u0161tevilka ena je kar o\u010diten: storitve, ki jih ni treba rezervirati \u2013 ni treba rezervirati.<\/p>\n

\"Failover:
\n<\/p>\n

Primer \u0161tevilka dva<\/h4>\n

\nBlog podjetja: usposobljeni pisci objavljajo novice, na primer udele\u017eili smo se te in te razstave, tu pa je nov izdelek in tako naprej. Recimo, da gre za standardni PHP z WordPressom, majhna baza podatkov in malo statike. Seveda se spet pojavi misel, da ne smemo le\u017eati \u2014 \u201ene ve\u010d kot pet minut!\u201c, tak\u0161ne stvari. Ampak pomisli naprej. Kaj ta blog po\u010dne? Obiskujejo ga ljudi iz Yandexa, Googla po nekaterih poizvedbah, organi\u010dno. Super. Kaj pa prodaja, ima to kak\u0161no povezavo? Razsvetljenje: ne ravno. Oglasi gredo na glavno spletno stran, ki je na drugem stre\u017eniku. Za\u010dnemo razmi\u0161ljati o rezervni re\u0161itvi za blog. Po\u0161teno, v dveh urah bi ga bilo treba postaviti, in bilo bi dobro, da se na to pripravimo. Smiselno bi bilo vzeti stroj v drugem podatkovnem sredi\u0161\u010du, na njega namestiti okolje, torej spletni stre\u017enik, PHP, WordPress, MySQL, in pustiti to, da miruje. Ko spoznamo, da je vse pokvarjeno, moramo narediti dve stvari \u2014 obnoviti mysql varnostno kopijo, dol\u017eine 50 metrov, to bo trajalo minuto, in obnoviti nekaj slik iz varnostne kopije. Tudi to ni posebej zapleteno. Tako da se v pol ure postavi celotna zadeva. Brez replikacij ali, ne daj bog, samodejnega preklapljanja. Zaklju\u010dek: kar lahko hitro obnovimo iz varnostne kopije, ni potrebno rezervirati. <\/p>\n

\"Failover:
\n<\/p>\n

Primer \u0161tevilka tri, nekoliko bolj zapleten<\/h4>\n

\nSpletna trgovina. PhP z malce predelanim open heart, MySQL z obse\u017eno bazo. Dokaj veliko statike (kon\u010dno v spletni trgovini so lepa HD slika in vse to), Redis za seje in Elasticsearch za iskanje. Za\u010dnemo razmi\u0161ljati o \u010dasu izpada. In tu je seveda o\u010ditno, da spletna trgovina ne more brez bole\u010din le\u017eati en dan. Kajti dlje ko le\u017ei, ve\u010d denarja izgubljamo. Treba je pospe\u0161iti. In kako mo\u010dno? Menim, da \u010de le\u017eimo eno uro, nih\u010de ne bo padel v obup. Da, nekaj bomo izgubili, ampak \u010de za\u010dnemo preve\u010d delati \u2014 bo le \u0161e huje. Dolo\u010dimo shemo izpada, ki je dovoljena v eni uri.<\/p>\n

Kako to vse rezervirati? Avto je nujno potreben: ena ura je precej malo. Mysql: tu \u017ee potrebujemo replikacijo, \u017eivo replikacijo, saj za eno uro 100 GB v dump verjetno ne bo vstopilo. Statika, slikice: spet, v eni uri morda 500 GB ne bo uspelo priti. Zato je bolje, da takoj kopiramo slike. Redis: tu pa je stvar bolj zanimiva. V Redis so shranjene seje \u2014 enostavno ga vzeti in ukiniti ne moremo. Ker to ne bi bilo najbolje: vsi uporabniki bi bili odjavljeni, nakupovalne ko\u0161arice bi bile prazne in tako naprej. Ljudje bi morali znova vnesti svoj prijavni in geslo, in veliko ljudi bi se lahko odklopilo in nakupa ne bi dokon\u010dalo. Tako bo konverzija padla. Po drugi strani pa Redis ni potrebna 100-odstotno aktualen, s potrebnimi zadnjimi prijavljenimi uporabniki. In dober kompromis je vzeti Redis in ga obnoviti iz varnostne kopije, iz v\u010deraj\u0161nje, ali, \u010de jo imate vsakih 60 minut, \u2014 iz ure stare. Na sre\u010do je obnova iz varnostne kopije preprosto kopiranje enega datoteke. Najbolj zanimiva zgodba pa je Elasticsearch. Kdo je kdaj vzpostavil replikacijo MySQL? Kdo je kdaj vzpostavil replikacijo Elasticsearch? In komu je ta delovala normalno? Mislim, da v na\u0161em sistemu vidimo neko entiteto. Zdi se koristna \u2014 a je zapletena.
\nZapleteno v smislu, da na\u0161i kolegi in\u017eenirji nimajo izku\u0161enj z njo. Bodisi imajo slabe izku\u0161nje. Bodisi razumemo, da je to \u0161e vedno precej nova tehnologija z nekaterimi posebnostmi ali nepopolnostmi. Razmi\u0161ljamo... Pa saj, elastic je tudi zahteven, njegovo obnavljanje iz varnostne kopije traja dolgo, kaj storiti? Zavedamo se, da se elastic v na\u0161em primeru uporablja za iskanje. Kako pa prodaja na\u0161 spletni trgovec? Pojdimo do tr\u017enikov in jih vpra\u0161ajmo, od kod dejansko prihajajo ljudje. Odgovorijo: \"90 % jih pride neposredno iz Yandex-Marketa na stran izdelka\". Bodisi kupijo, bodisi ne. To pomeni, da iskanje potrebujeta le 10 % uporabnikov. In ohranjanje replikacije elastic-a, \u0161e posebej med razli\u010dnimi podatkovnimi centri v razli\u010dnih conah, \u2014 seveda, to vklju\u010duje \u0161tevilne posebnosti. Kak\u0161na je re\u0161itev? Elastic vzamemo na rezervirani platformi in z njim ne po\u010dnemo ni\u010d. \u010ce se bo postopek zavlekel, ga morda kdaj pozneje za\u017eenemo, a to ni gotovo. Pravzaprav je zaklju\u010dek bolj ali manj enak: storitve, ki ne vplivajo na finance, spet ne rezerviramo. Da shema ostane \u010dim bolj preprosta.<\/p>\n

\"Failover:
\n<\/p>\n

Primer \u0161tevilka \u0161tiri, \u0161e zahtevnej\u0161i.<\/h4>\n

\nIntegracija: prodaja cvetja, klic taksija, prodaja blaga, v bistvu karkoli. Resna zadeva, ki deluje 24\/7 za veliko \u0161tevilo uporabnikov. S polnopravno zanimivo tehnologijo, kjer so zanimive baze, re\u0161itve, visoka obremenitev, in kar je najpomembnej\u0161e, le\u017eanje ve\u010d kot 5 minut je bole\u010de. Ne samo, in ne toliko, zato, ker ljudje ne bodo kupili, ampak zato, ker bodo ljudje videli, da ta stvar ne deluje, se razo\u010darali in morda sploh ne pridejo drugi\u010d. <\/p>\n

V redu. Pet minut. Kaj bomo s tem naredili? V tem primeru odraslo in za vse denarje postavimo pravo rezervno platformo, z replikacijo vsega in \u0161e \u010desa, in morda celo maksimiziramo avtomatizacijo preklopa na to platformo. In poleg tega ne smemo pozabiti narediti \u0161e eno pomembno stvar: napisati postopek preklopa. Postopek, tudi \u010de imate vse avtomatizirano, je lahko zelo preprost. Nekaj v smislu: 'za\u017eeni ta in ta ansible skript', 'v route 53 ozna\u010di to in to' in tako naprej - toda to mora biti nek to\u010den seznam dejanj. <\/p>\n

Zdi se, da je vse jasno. Preklop replikacije je trivialna naloga, ali pa se bo preklopila sama. Prepisovanje domene v dns je iz iste serije. Te\u017eava nastane, ko tak\u0161en projekt propade, za\u010dne se panika, in celo najbolj izku\u0161eni admini so lahko podvr\u017eeni temu. Brez jasnih navodil 'odpri terminal, pojdi sem, naslov na\u0161ega stre\u017enika je \u0161e vedno tak\u0161en' je te\u017eko o\u010duvati petminutni rok za reanimacijo. Poleg tega, ko uporabljamo ta postopek, je lahko enostavno popraviti kak\u0161ne spremembe v infrastrukturi in ustrezno spremeniti postopek.
\n\u010ce je sistem rezerviranja zelo zapleten in v nekem trenutku naredimo napako, lahko uni\u010dimo tudi na\u0161 rezervoar, podatki pa se lahko spremenijo v bu\u010do na obeh lokacijah \u2014 to bi bilo zelo \u017ealostno. <\/p>\n

\"Failover:
\n<\/p>\n

Primer \u0161tevilka pet, popoln hardcore<\/h4>\n

\nMednarodna storitev s stotimi milijoni uporabnikov po vsem svetu. Vse \u010dasovne pasove, ki jih le obstajajo, highload na maksimumu, ne sme pasti. Ena minuta \u2014 in \u017ealost bo pri\u0161la. Kaj storiti? Rezervirati, znova, po polni program. Storili smo vse, kar sem omenil v prej\u0161njem primeru, in \u0161e nekoliko ve\u010d. Idealen svet in na\u0161a infrastruktura je po vseh kriterijih devops IaaC. Torej je vse v git-u, le pritisnite gumb. <\/p>\n

Kaj manjka? Enega \u2014 usposabljanj. Brez njih ne gre. Zdi se, da imamo vse popolno, vse imamo pod nadzorom. Pritisnemo gumb, vse se zgodi. Tudi \u010de je tako \u2014 in razumemo, da ni tako \u2014 na\u0161 sistem deluje z nekaterimi drugimi sistemi. Na primer, to je dns od route 53, s3 shrambi, integracija z nekaterimi api. Vse predvideti v tem umskem eksperimentu ne moremo. In dokler dejansko ne potegnemo stikala \u2014 ne bomo izvedeli, ali bo delovalo ali ne. <\/p>\n

\"Failover:
\n
\nNa tem, verjetno, vse. Ne lenarite in se ne trudite preve\u010d. In naj bo uptime z vami!
\n
Izvor: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041b\u0435\u0442\u043e\u043c \u0442\u0440\u0430\u0434\u0438\u0446\u0438\u043e\u043d\u043d\u043e \u0441\u043d\u0438\u0436\u0430\u0435\u0442\u0441\u044f \u0438 \u043f\u043e\u043a\u0443\u043f\u0430\u0442\u0435\u043b\u044c\u0441\u043a\u0430\u044f \u0430\u043a\u0442\u0438\u0432\u043d\u043e\u0441\u0442\u044c, \u0438 \u0438\u043d\u0442\u0435\u043d\u0441\u0438\u0432\u043d\u043e\u0441\u0442\u044c \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u044f \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u044b \u0432\u0435\u0431-\u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432, \u0433\u043e\u0432\u043e\u0440\u0438\u0442 \u043d\u0430\u043c \u041a\u0430\u043f\u0438\u0442\u0430\u043d \u041e\u0447\u0435\u0432\u0438\u0434\u043d\u043e\u0441\u0442\u044c. \u041f\u0440\u043e\u0441\u0442\u043e \u043f\u043e\u0442\u043e\u043c\u0443 \u0447\u0442\u043e \u0434\u0430\u0436\u0435 \u0430\u0439\u0442\u0438\u0448\u043d\u0438\u043a\u0438, \u0441\u043b\u0443\u0447\u0430\u0435\u0442\u0441\u044f, \u0445\u043e\u0434\u044f\u0442 \u0432 \u043e\u0442\u043f\u0443\u0441\u043a. \u0418 C\u0422\u041e \u0442\u043e\u0436\u0435. \u0422\u0435\u043c \u0442\u044f\u0436\u0435\u043b\u0435\u0435 \u0442\u0435\u043c, \u043a\u0442\u043e \u043e\u0441\u0442\u0430\u0451\u0442\u0441\u044f \u043d\u0430 \u043f\u043e\u0441\u0442\u0443, \u043d\u043e \u0441\u0435\u0439\u0447\u0430\u0441 \u043d\u0435 \u043e\u0431 \u044d\u0442\u043e\u043c: \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e, \u0438\u043c\u0435\u043d\u043d\u043e \u043f\u043e\u044d\u0442\u043e\u043c\u0443 \u043b\u0435\u0442\u043e \u2014 \u043b\u0443\u0447\u0448\u0438\u0439 \u043f\u0435\u0440\u0438\u043e\u0434 \u0434\u043b\u044f \u0442\u043e\u0433\u043e, \u0447\u0442\u043e\u0431\u044b \u043d\u0435 \u0442\u043e\u0440\u043e\u043f\u044f\u0441\u044c \u043e\u0431\u0434\u0443\u043c\u0430\u0442\u044c \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u044e\u0449\u0443\u044e \u0441\u0445\u0435\u043c\u0443 \u0440\u0435\u0437\u0435\u0440\u0432\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":27235,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-36393","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Failover: izgublja nas perfekcionizem in\u2026 lenoba | ProHoster","description":"Poleti se tradicionalno zmanj\u0161a tako nakupna aktivnost kot intenzivnost sprememb infrastrukture spletnih projektov, nam pove Kapitan O\u010ditnost. Preprosto zato, ker tudi IT-jevci, se zgodi, gredo na dopust.","canonical_url":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/failover-nas-gubit-perfektsionizm-i-len","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sl_SI","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Failover: \u043d\u0430\u0441 \u0433\u0443\u0431\u0438\u0442 \u043f\u0435\u0440\u0444\u0435\u043a\u0446\u0438\u043e\u043d\u0438\u0437\u043c \u0438\u2026 \u043b\u0435\u043d\u044c | ProHoster","og:description":"\u041b\u0435\u0442\u043e\u043c \u0442\u0440\u0430\u0434\u0438\u0446\u0438\u043e\u043d\u043d\u043e \u0441\u043d\u0438\u0436\u0430\u0435\u0442\u0441\u044f \u0438 \u043f\u043e\u043a\u0443\u043f\u0430\u0442\u0435\u043b\u044c\u0441\u043a\u0430\u044f \u0430\u043a\u0442\u0438\u0432\u043d\u043e\u0441\u0442\u044c, \u0438 \u0438\u043d\u0442\u0435\u043d\u0441\u0438\u0432\u043d\u043e\u0441\u0442\u044c \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u044f \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u044b \u0432\u0435\u0431-\u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432, \u0433\u043e\u0432\u043e\u0440\u0438\u0442 \u043d\u0430\u043c \u041a\u0430\u043f\u0438\u0442\u0430\u043d \u041e\u0447\u0435\u0432\u0438\u0434\u043d\u043e\u0441\u0442\u044c. \u041f\u0440\u043e\u0441\u0442\u043e \u043f\u043e\u0442\u043e\u043c\u0443 \u0447\u0442\u043e \u0434\u0430\u0436\u0435 \u0430\u0439\u0442\u0438\u0448\u043d\u0438\u043a\u0438, \u0441\u043b\u0443\u0447\u0430\u0435\u0442\u0441\u044f, \u0445\u043e\u0434\u044f\u0442 \u0432 \u043e\u0442\u043f\u0443\u0441\u043a.","og:url":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/failover-nas-gubit-perfektsionizm-i-len","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:11:24+00:00","article:modified_time":"2019-10-31T19:11:24+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"36393","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-22 03:07:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:45:36","updated":"2026-01-22 03:07:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts\/36393","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/comments?post=36393"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts\/36393\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media\/27235"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media?parent=36393"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/categories?post=36393"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/tags?post=36393"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}