{"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\/nl\/blog\/administrirovanie\/failover-nas-gubit-perfektsionizm-i-len","title":{"rendered":"Failover: perfectie en\u2026 luiheid brengen ons ten val","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

In de zomer neemt zowel de koopactiviteit als de intensiteit van veranderingen aan de infrastructuur van webprojecten traditioneel af, vertelt ons Kapitein Obvious. Gewoon omdat zelfs IT'ers soms op vakantie gaan. En CTO's ook. Het is dus moeilijker voor degenen die op hun post blijven, maar daar gaat het nu niet om: misschien is de zomer daarom de beste tijd om rustig na te denken over het bestaande back-upplan en een plan voor verbetering op te stellen. De ervaring van Egor Andreev uit AdminDivision<\/a><\/noindex>, waar hij over sprak op de conferentie Uptime-dag<\/a><\/noindex>.<\/i><\/p>\n

Bij het opzetten van back-up locaties en het maken van back-ups zijn er verschillende valkuilen waarin je kunt vallen. En daarin mag je absoluut niet vallen. Perfectionisme en... luiheid zijn wat ons hierin, zoals in veel andere zaken, verwoest. We proberen alles perfect te doen, maar perfectie is niet nodig! We moeten alleen bepaalde dingen goed doen en deze tot een goed einde brengen, zodat ze normaal functioneren. <\/p>\n

Failover is niet iets leuks of een gimmick 'om het maar te hebben'; het is iets dat precies \u00e9\u00e9n doel moet dienen \u2014 de downtime verminderen, zodat de service, het bedrijf minder geld verliest. En in alle methoden voor het maken van back-ups stel ik voor om het volgende in overweging te nemen: waar zit het geld?<\/p>\n

\"Failover:
\n<\/a><\/noindex>
\nDe eerste valkuil<\/b>: wanneer we grote betrouwbare systemen bouwen en bezig zijn met back-ups \u2014 verminderen we het aantal storingen. Dit is een gevaarlijke misvatting. Wanneer we met back-ups bezig zijn, verhogen we waarschijnlijk het aantal storingen. En als we alles goed doen, verminderen we samen de downtime. Er zullen meer storingen zijn, maar ze zullen plaatsvinden met lagere kosten. Want wat zijn back-ups? \u2014 dat is het compliceren van het systeem. Elke complicatie is slecht: we krijgen meer schroefjes, meer tandwielen, met andere woorden, meer elementen \u2014 en dus een grotere kans op defecten. En ze zullen echt kapotgaan. En vaker kapotgaan. Een simpel voorbeeld: stel dat we een website hebben met PHP, MySQL. En het moet dringend worden geback-upt. <\/p>\n

Laten we een tweede platform nemen en een identiek systeem bouwen\u2026 De complexiteit verdubbelt \u2014 we hebben twee entiteiten. Bovendien moeten we enkele logica voor gegevensoverdracht van de ene naar de andere plaats aanbrengen \u2014 dat wil zeggen, gegevens replicatie, het kopi\u00ebren van statische inhoud, enzovoort. De logica van replicatie is meestal erg ingewikkeld, waardoor de totale complexiteit van het systeem niet 2, maar 3, 5 of zelfs 10 keer groter kan zijn. <\/p>\n

De tweede valkuil<\/b>: wanneer we echt grote complexe systemen bouwen, fantaseren we over wat we uiteindelijk willen bereiken. Voil\u00e0: we willen een superbetrouwbaar systeem dat volledig zonder downtime werkt, dat binnen een halve seconde overschakelt (of beter nog, onmiddellijk), en we beginnen onze dromen werkelijkheid te maken. Maar hier is ook een nuance: hoe korter de gewenste overschakeltijd, des te complexer de logica van het systeem wordt. Hoe moeilijker we deze logica moeten maken, hoe vaker het systeem zal falen. En je kunt in een zeer ongewenste situatie terechtkomen: we proberen koste wat het kost de downtime te verminderen, maar in werkelijkheid maken we alles ingewikkelder, en wanneer er iets misgaat, zal de downtime uiteindelijk groter zijn. Vaak merk je dan dat het beter zou zijn geweest om niet te reserveren. Het zou beter zijn als het \u00e9\u00e9n enkel goed functionerend systeem was met een duidelijke tijd voor downtime. <\/p>\n

Hoe kunnen we dit bestrijden? We moeten stoppen met onszelf te bedriegen, te stoppen met onszelf te vleien dat we hier een ruimteschip gaan bouwen, en in plaats daarvan realistisch begrijpen hoe lang een project kan liggen. En op basis van deze maximale tijd kiezen we welke methoden we zullen gebruiken om de betrouwbaarheid van ons systeem te verhogen. <\/p>\n

\"Failover:
\n
\nHet is tijd voor \"verhalen uit het leven\"... <\/p>\n

Voorbeeld nummer \u00e9\u00e9n<\/h4>\n

\nStel je een visitekaartjeswebsite voor van de nummer 1 buizenfabriek in stad N. Er staat met grote letters \u2013 BUZENFABRIEK \u21161. Iets lager staat de slogan: \"Onze buizen zijn de rondste buizen in N\". Onderaan staat het telefoonnummer van de directeur en zijn naam. We begrijpen dat we moeten reserveren \u2013 het is immers een zeer belangrijke zaak! We beginnen te onderzoeken waar het uit bestaat. Html-statisch \u2013 dat wil zeggen een paar plaatjes waar de directeur met zijn partner aan tafel in de sauna een deal bespreekt. We beginnen na te denken over de downtime. Het valt ons in: het moet daar vijf minuten liggen, niet langer. En dan is de vraag: hoeveel verkopen zijn er eigenlijk gedaan via onze website? Hoeveel? Wat betekent \"nul\"? Dat betekent: omdat de directeur alle vier deals van vorig jaar aan diezelfde tafel heeft gemaakt, met diezelfde mensen, met wie zij ook in de sauna zitten en aan tafel zitten. We begrijpen dat, zelfs als de website een dag stil ligt, er niets ergs aan de hand zal zijn. <\/p>\n

Afgaand op de input, hebben we \u00e9\u00e9n dag om dit verhaal op te zetten. We beginnen na te denken over het reserveringsschema. En we kiezen het meest ideale schema voor reservering voor dit voorbeeld: we gebruiken geen reservering. Deze hele opzet kan door elke admin binnen een halfuur worden opgezet met een paar pauzes. Een webserver instellen, de bestanden plaatsen \u2013 dat is alles. Het zal werken. Er is niets waar je op moet letten, en er is niets dat bijzondere aandacht behoeft. Dus de conclusie uit voorbeeld \u00e9\u00e9n is zeer duidelijk: diensten die niet gereserveerd hoeven te worden, hoeven niet te worden gereserveerd.<\/p>\n

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

Voorbeeld nummer twee<\/h4>\n

\nBedrijf bloggen: speciaal opgeleiden schrijven daar nieuws, bijvoorbeeld dat we hebben deelgenomen aan een bepaalde tentoonstelling, of dat we een nieuw product hebben uitgebracht, enzovoort. Laten we zeggen dat dit standaard PHP met WordPress is, een kleine database en een beetje statische inhoud. Natuurlijk komt weer de gedachte op dat je absoluut niet passief kunt zijn \u2014 'niet meer dan vijf minuten!', al dat soort dingen. Maar laten we verder denken. Wat doet deze blog? Mensen komen er via Yandex, Google met bepaalde zoekopdrachten, via organisch verkeer. Geweldig. Maar zijn de verkopen op de een of andere manier aan deze blog gerelateerd? Een onthulling: niet echt. Advertentietraffic gaat naar de hoofdwebsite, die op een andere server staat. We gaan nadenken over een backupplan voor de blog. Eigenlijk moet je het in een paar uur kunnen opstarten, en het zou fijn zijn om je daarop voor te bereiden. Het is verstandig om een server in een ander datacentrum te nemen, daar de omgeving op te zetten, dus webserver, PHP, WordPress, MySQL, en dit in een standby-modus te houden. Op het moment dat we beseffen dat alles kapot is, moeten we twee dingen doen \u2014 een MySQL-dump van 50 MB maken, die is binnen een minuut overgezet, en een aantal afbeeldingen uit de backup herstellen. Dit is ook niet al te veel. Op die manier wordt alles binnen een half uur weer opgestart. Geen replicatie, of verhoed de Heer, automatische failover. Conclusie: wat we snel uit de backup kunnen herstellen, hoeft niet te worden gereserveerd. <\/p>\n

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

Voorbeeld nummer drie, iets ingewikkelder<\/h4>\n

\nWebwinkel. PHP met open heart, een beetje aangepast, MySQL met een solide database. Vrij veel statische content (want in een webwinkel zijn er mooie HD-afbeeldingen en zo), Redis voor sessies en Elasticsearch voor zoekfuncties. We beginnen na te denken over downtime. En hier is het natuurlijk duidelijk dat een webwinkel niet een dag zonder problemen kan stilvallen. Hoe langer het stil ligt, hoe meer geld we verliezen. We moeten spoed maken. Maar hoe snel? Ik denk dat als we een uur stil liggen, niemand gek zelfs wordt. Ja, we verliezen iets, maar als we ons gaan inspannen - wordt het alleen maar erger. We bepalen het toegestane downtime-schema per uur.<\/p>\n

Hoe kan dit allemaal gereserveerd worden? De machine is hoe dan ook nodig: een uur is vrij kort. Mysql: hier is replicatie nodig, echte replicatie, want binnen een uur zal 100 GB aan dump waarschijnlijk niet binnenkomen. Statica, plaatjes: ook hier kan 500 GB in een uur mogelijk niet binnenkomen. Dus het is beter om de plaatjes meteen te kopi\u00ebren. Redis: hier wordt het interessanter. De sessies liggen in Redis \u2014 we kunnen het gewoon niet opbergen. Omdat dat niet goed zou zijn: alle gebruikers zullen uitloggen, hun winkelwagentjes zullen leeg zijn, enzovoort. Mensen zouden opnieuw hun login en wachtwoord moeten invoeren, en veel mensen kunnen dan afhaken en hun aankoop niet voltooien. Ook zal de conversie dalen. Aan de andere kant, Redis met de laatst ingelogde gebruikers hoeft waarschijnlijk ook niet per se actueel te zijn. Een goede compromis zou zijn om Redis te nemen en het vanuit een backup te herstellen, van gisteren, of als je het elk uur maakt \u2014 van een uur geleden. Gelukkig is het herstel daarvan uit de backup slechts het kopi\u00ebren van \u00e9\u00e9n bestand. En het meest interessante verhaal is Elasticsearch. Wie heeft ooit MySQL-replicatie opgezet? Wie heeft ooit Elasticsearch-replicatie opgezet? En wie heeft het succesvol laten werken? Ik doel erop: we zien in ons systeem een bepaalde entiteit. Het lijkt nuttig \u2014 maar het is complex.
\nComplex in the sense that our engineer colleagues lack experience with it. Either they have negative experiences or we recognize that this is a relatively new technology with nuances or immaturity. We think... Damn, elastic is also hefty; it takes a long time to restore it from a backup, what to do? We understand that elastic is used for search in our case. And how does our online store sell? We go to the marketers and ask where the customers come from. They reply: \"90% come directly from Yandex.Market to the product page.\" And they either buy or they don't. Consequently, search is needed for 10% of users. And maintaining elastic replication, especially between different data centers in different zones, indeed involves many nuances. What\u2019s the solution? We take elastic on a reserved site and do nothing with it. If the matter drags on, we might raise it up later, but that's not certain. Essentially, the conclusion is more or less the same: services that do not impact revenue are, again, not reserved. To keep the scheme simpler.<\/p>\n

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

Example number four, even more complex.<\/h4>\n

\nIntegrator: flower sales, taxi calls, product sales, basically, anything. A serious entity that operates 24\/7 for a large number of users. With a fully featured interesting stack, where there are intriguing databases, solutions, high load, and most importantly, it cannot be down for more than 5 minutes. Not only because people won\u2019t buy, but because they will see that this thing isn\u2019t working, get upset, and might not come back a second time. <\/p>\n

Okay. Five minutes. What are we going to do about it? In this case, we professionally build a true backup platform with full replication of everything, and possibly even automate switching to this platform as much as possible. In addition to this, we must not forget to do one important thing: write the switching regulation. The regulation, even if you have everything automated, can be very simple. Along the lines of \"run this specific Ansible script\", \"check this option in Route 53\", and so forth \u2014 but it should be a precise list of actions. <\/p>\n

Het lijkt allemaal duidelijk. Het overschakelen van replicatie is een triviale taak, of het schakelt automatisch over. Het herschrijven van de domeinnaam in DNS valt onder dezelfde categorie. Het probleem is dat wanneer zo'n project faalt, de paniek toeslaat, en zelfs de meest ervaren systeembeheerders kunnen hieraan onderhevig zijn. Zonder duidelijke instructies zoals 'open de terminal, ga hierheen, het adres van onze server is nog steeds zo' is het moeilijk om binnen een tijdslimiet van 5 minuten voor herstelstand te zorgen. En bovendien, wanneer we deze procedure gebruiken, is het gemakkelijk om wijzigingen in de infrastructuur te documenteren en de reglementen overeenkomstig aan te passen.
\nMaar als het reserveringssysteem erg complex is en we op een bepaald moment een fout maken, kunnen we zowel onze back-upomgeving uithalen, en bovendien de data op beide locaties in rook laten opgaan \u2014 dat zou behoorlijk treurig zijn. <\/p>\n

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

Voorbeeld nummer vijf, complete hardcore.<\/h4>\n

\nEen internationale service met honderden miljoenen gebruikers over de hele wereld. Alle tijdzones die er maar zijn, highload op de maximale capaciteit, uitvallen kan echt niet. E\u00e9n minuut \u2014 en het wordt droevig. Wat te doen? Wederom, een volledige reservering. We hebben alles gedaan wat ik in het vorige voorbeeld zei, en nog een beetje meer. Een ideale wereld, en onze infrastructuur \u2014 die is qua devops-standaarden IaaC. Dat wil zeggen, alles staat in git, je hoeft alleen de knop in te drukken. <\/p>\n

Wat ontbreekt er? E\u00e9n ding \u2014 oefeningen. Zonder die kunnen we niet. Het lijkt erop dat alles perfect is, alles is onder controle. We drukken op de knop, alles gebeurt. Zelfs als dat zo is \u2014 en we weten dat dat niet het geval is \u2014 werkt ons systeem samen met andere systemen. Bijvoorbeeld, DNS van Route 53, S3-opslag, integratie met verschillende API's. We kunnen niet alles voorzien in dit theoretische experiment. En totdat we de schakelaar daadwerkelijk overhalen \u2014 zullen we niet weten of het werkt of niet. <\/p>\n

\"Failover:
\n
\nDat is waarschijnlijk alles. Wees niet lui en overdrijf niet. En moge de uptime met jullie zijn!
\n
Bron: 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: perfectionisme en\u2026 luiheid zijn onze ondergang | ProHoster","description":"In de zomer dalen zowel de koopactiviteit als de intensiteit van infrastructuurveranderingen in webprojecten, zegt Kapitein Overduidelijk. Gewoon omdat zelfs IT'ers soms op vakantie gaan.","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/failover-nas-gubit-perfektsionizm-i-len","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","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\/nl\/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\/nl\/wp-json\/wp\/v2\/posts\/36393","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=36393"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/36393\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/27235"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=36393"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=36393"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=36393"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}