{"id":35291,"date":"2019-10-31T22:03:28","date_gmt":"2019-10-31T19:03:28","guid":{"rendered":"https:\/\/prohoster.info\/blog\/setevaya-fabrika-dlya-tsoda-cisco-aci-v-pomoshh-adminu\/"},"modified":"2019-10-31T22:03:28","modified_gmt":"2019-10-31T19:03:28","slug":"setevaya-fabrika-dlya-tsoda-cisco-aci-v-pomoshh-adminu","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/setevaya-fabrika-dlya-tsoda-cisco-aci-v-pomoshh-adminu","title":{"rendered":"Netv\u00e6rksfabrikken for datacentre Cisco ACI - til hj\u00e6lp for administratoren","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Netv\u00e6rksfabrikken
\nMed denne magiske stykke Cisco ACI script kan du hurtigt konfigurere netv\u00e6rket.<\/i><\/p>\n

Netv\u00e6rksfabrikken til datacenteret Cisco ACI har eksisteret i fem \u00e5r, men der er ikke rigtig blevet talt om den p\u00e5 Habr, s\u00e5 jeg besluttede mig for at rette lidt op p\u00e5 det. Jeg vil fort\u00e6lle fra min erfaring, hvad det er, hvilken fordel den har, og hvor dens f\u00e6lder ligger. <\/p>\n

Hvad er det, og hvor kommer det fra?<\/h3>\n

\nVed annonceringen af ACI (Application Centric Infrastructure) i 2013 blev de traditionelle tilgange til datacenter-netv\u00e6rk udfordret fra tre sider. <\/p>\n

P\u00e5 den ene side lovede SDN-l\u00f8sninger \"f\u00f8rste generation\" baseret p\u00e5 OpenFlow at g\u00f8re netv\u00e6rk b\u00e5de mere fleksible og billigere p\u00e5 samme tid. Ideen var at flytte beslutningstagningen, der traditionelt blev udf\u00f8rt af den propriet\u00e6re software i switchene, til en central controller. <\/p>\n

Denne controller ville have et samlet overblik over alt, hvad der foreg\u00e5r, og ud fra dette ville den programere udstyret i alle switchene p\u00e5 niveauet for regler til behandling af specifikke str\u00f8mme. <\/a><\/noindex>
\nP\u00e5 den anden side gav overlay-netv\u00e6rksl\u00f8sninger mulighed for at implementere den n\u00f8dvendige forbindelse og sikkerhedspolitikker uden at \u00e6ndre den fysiske netv\u00e6rk, ved at opbygge software tunneler mellem virtualiserede v\u00e6rter. Det mest kendte eksempel p\u00e5 en s\u00e5dan tilgang var l\u00f8sningen fra Nicira, som p\u00e5 det tidspunkt allerede var blevet erhvervet af VMWare for 1,26 milliarder dollars og gav start til det nuv\u00e6rende VMWare NSX. En smule picant tilf\u00f8jede situationen det faktum, at medstifterne af Nicira var de samme personer, der tidligere havde v\u00e6ret med til at udvikle OpenFlow, og nu sagde, at for at bygge en datacenterfabrik var OpenFlow ikke det rette valg. OpenFlow passer ikke<\/a><\/noindex>.<\/p>\n

Og endelig havde switch-chips tilg\u00e6ngelige p\u00e5 det \u00e5bne marked (det, der kaldes merchant silicon), n\u00e5et et modenhedsniveau, hvor de udgjorde en reel trussel mod de traditionelle switch-producenter. Tidligere udviklede hver leverand\u00f8r chips til deres switch, men over tid begyndte chips fra tredjepartsproducenter, is\u00e6r fra Broadcom, at indhente leverand\u00f8rernes chips med hensyn til funktioner og at overg\u00e5 dem i pris\/pr\u00e6station forhold. Derfor mente mange, at dagene for switchene med egenudviklede chips var t\u00e6llende.<\/p>\n

ACI blev Cisco's \"asymmetrisk svar\" (mere pr\u00e6cist, et svar fra det opk\u00f8bte firma Insieme, grundlagt af tidligere ansatte) p\u00e5 alt det n\u00e6vnte. <\/p>\n

Hvad er forskellen til OpenFlow?<\/h3>\n

\nSet fra et funktionsfordelingsperspektiv er ACI faktisk det modsatte af OpenFlow.
\nI OpenFlow-arkitekturen er controlleren ansvarlig for at specificere detaljerede regler (flows)
\ni hardwareen af alle switchene, hvilket betyder, at i et stort netv\u00e6rk kan den have ansvaret for at vedligeholde og, vigtigst af alt, \u00e6ndre titusinder af millioner poster p\u00e5 hundreder af steder i netv\u00e6rket, derfor bliver dens ydeevne og p\u00e5lidelighed i store implementeringer et flaskehals.<\/p>\n

I ACI anvendes der en omvendt tilgang: der findes selvf\u00f8lgelig ogs\u00e5 en controller, men switchene modtager fra den h\u00f8j-niveau deklarative politikker, og deres rendering til detaljerede specifikationer i hardware udf\u00f8res af selve switchen. Controlleren kan genstartes eller helt slukkes, og med netv\u00e6rket vil der ikke ske noget d\u00e5rligt, bortset fra selvf\u00f8lgelig, at der ikke er mulighed for at administrere i det \u00f8jeblik. Interessant nok er der i ACI situationer, hvor OpenFlow alligevel bruges, men lokalt inden for v\u00e6rten til programmering af Open vSwitch.<\/p>\n

ACI er helt bygget p\u00e5 overlay-transport baseret p\u00e5 VXLAN, men inkluderer samtidig i rammerne af en samlet l\u00f8sning det underliggende IP-transport. Cisco har kaldt dette for 'integreret overlay'. Som terminering af overlayne bruges switchene i fabrikken (g\u00f8r det ved kanalens hastighed) i de fleste tilf\u00e6lde. V\u00e6rter beh\u00f8ver ikke at vide noget om fabrikken, indkapslinger osv., men i nogle tilf\u00e6lde (for eksempel for at forbinde OpenStack-v\u00e6rter) kan VXLAN-trafik ogs\u00e5 sendes til dem.<\/p>\n

Overlayne anvendes i ACI ikke kun til at sikre fleksibel forbindelse gennem transportsnetv\u00e6rket, men ogs\u00e5 til at overf\u00f8re metaoplysninger (som for eksempel anvendes til at anvende sikkerhedspolitikker). <\/p>\n

Broadcoms chips have previously been used by Cisco in the Nexus 3000 series switches. In the Nexus 9000 family, specifically released to support ACI, a hybrid model called Merchant+ was initially implemented. The switch simultaneously used a new Broadcom Trident 2 chip alongside a complementary chip developed by Cisco, which executed all the ACI magic. Apparently, this allowed for a quicker product release and reduced the switch price to a level close to models relying solely on Trident 2. This approach was sufficient for the first two to three years of ACI deliveries. During this time, Cisco developed and released the next generation of Nexus 9000, now utilizing its own chips with greater performance and feature sets, but at the same price point. The external specifications regarding interaction in the fabric remained completely unchanged. However, the internal components changed entirely: something akin to refactoring, but for hardware.<\/p>\n

Hvordan er arkitekturen i Cisco ACI <\/h3>\n

\nI sin simpleste form bygges ACI ud fra Clos-netv\u00e6rkstopologien, eller, som det ogs\u00e5 ofte omtales, Spine-Leaf. Der kan v\u00e6re fra to (eller \u00e9n, hvis vi ikke er bekymrede for fejltolerance) til seks Spine-niveau switches. Jo flere der er, desto h\u00f8jere er fejltolerancen (mindre nedgang i b\u00e5ndbredde og p\u00e5lidelighed ved en fejl eller vedligeholdelse af en enkelt Spine) og den samlede ydeevne. Alle eksterne forbindelser g\u00e5r til Leaf-niveau switches: dette inkluderer servere, forbindelser til eksterne netv\u00e6rk via L2 eller L3, samt tilslutning af APIC controllere. Generelt med ACI er ikke kun konfigurationen, men ogs\u00e5 indsamling af statistik, overv\u00e5gning af fejl og andre ting \u2013 alt dette g\u00f8res gennem controllerens interface, hvor der i installationer af almindelig st\u00f8rrelse \u2013 er tre enheder. <\/p>\n

Du skal aldrig tilslutte konsollen til switches, heller ikke for at starte netv\u00e6rket: controllere opdager selv switches og samler dem til en fabrik, inklusive indstillinger for alle serviceprotokoller, s\u00e5 det er meget vigtigt at notere serienumrene p\u00e5 det installerede udstyr under montage, s\u00e5 man ikke skal g\u00e6tte, hvilken switch der er i hvilken rack. Til fejls\u00f8gning kan man ved behov tilslutte sig switches via SSH: de har grundigt gengivet de almindelige show-kommandoer fra Cisco. <\/p>\n

Inden for fabrikken benytter man IP-transport, s\u00e5 der er ingen Spanning Tree og andre r\u00e6dsler fra fortiden: alle forbindelser er aktive, og konvergens ved fejl er meget hurtig. Trafikken i fabrikken overf\u00f8res via tunneler baseret p\u00e5 VXLAN. Mere pr\u00e6cist kalder Cisco selve inkapslingen iVXLAN, og den adskiller sig fra almindelig VXLAN ved, at de reserverede felter i netv\u00e6rkshovedet bruges til at overf\u00f8re kontrolinformation, prim\u00e6rt om forholdet mellem trafikken og EPG-gruppen. Dette muligg\u00f8r at implementere interaktionsregler mellem grupperne i hardwaren, ved at bruge deres numre ligesom adresser i almindelige adgangslister. <\/p>\n

Tunnelene g\u00f8r det muligt at str\u00e6kke b\u00e5de L2-segmenter og L3 (det vil sige VRF) gennem intern IP-transport. Her er standardgatewayen distribueret. Det betyder, at hver switch h\u00e5ndterer routing af den indg\u00e5ende trafik til fabrikken. Med hensyn til trafikoverf\u00f8rselslogik ligner ACI en fabrik baseret p\u00e5 VXLAN\/EVPN. <\/p>\n

Hvis det er tilf\u00e6ldet, hvad er forskellene s\u00e5? I alt andet! <\/h3>\n

\nDen f\u00f8rste forskel, man st\u00f8der p\u00e5 i ACI, er, hvordan servere tilsluttes netv\u00e6rket. I traditionelle netv\u00e6rk tilsluttes b\u00e5de fysiske servere og virtuelle maskiner VLAN'er, og alt andet f\u00f8lger derfra: sammenkobling, sikkerhed osv. I ACI anvendes en struktur, som Cisco kalder EPG (End-point Group), som man ikke kan komme udenom. Kan man ligestille det med VLAN? Ja, men i s\u00e5 fald er der en risiko for at miste meget af det, som ACI tilbyder. <\/p>\n

Alle adgangsregler formuleres i forhold til EPG, og i ACI anvendes som standard princippet om \"hvid liste\", hvilket betyder, at kun trafik, der er tilladt eksplicit, er tilladt. Det vil sige, at vi kan oprette EPG-grupperne \"Web\" og \"MySQL\" og definere en regel, der tillader interaktion mellem dem kun p\u00e5 port 3306. Dette vil fungere uden at v\u00e6re knyttet til netv\u00e6rksadresser, og endda inden for samme subnet! <\/p>\n

Vi har kunder, der har valgt ACI netop p\u00e5 grund af denne funktion, da den muligg\u00f8r restriktioner for adgangen mellem servere (virtuelle eller fysiske \u2014 underordnet), uden at skulle flytte dem mellem subnets, og dermed ikke r\u00f8re ved adresseringen. Ja, vi ved det, ingen skriver det manuelt IP-adresser<\/a> i applikationernes konfigurationer, vel?<\/p>\n

Reglerne for trafikgennemgang i ACI kaldes kontrakter. I en s\u00e5dan kontrakt bliver en eller flere grupper eller niveauer i en multi-tier-applikation leverand\u00f8r af en tjeneste (lad os sige, en database-tjeneste), mens andre bliver forbrugere. Kontrakten kan blot tillade trafik at passere, eller den kan g\u00f8re noget mere avanceret, som at lede trafikken til en firewall eller belastningsbalancer og ogs\u00e5 \u00e6ndre QoS-v\u00e6rdien.<\/p>\n

Hvordan kommer serverne ind i disse grupper? Hvis det er fysiske servere eller noget, der er forbundet til et eksisterende netv\u00e6rk, hvor vi har oprettet en VLAN-trunk, s\u00e5 kr\u00e6ver det at angive porten p\u00e5 switchen og den VLAN, der anvendes p\u00e5 den. Som vi kan se, optr\u00e6der VLAN'er der, hvor de er n\u00f8dvendige.<\/p>\n

Hvis serverne derimod er virtuelle, er det tilstr\u00e6kkeligt at henvise til den tilknyttede virtualiseringsmilj\u00f8, og s\u00e5 sker alt automatisk: der oprettes en portgruppe (hvis vi taler i termer - VMWare) til tilslutning af VM'er, n\u00f8dvendige VLAN'er eller VXLAN'er tildeles, og de skrivs ind p\u00e5 de relevante switch-porte osv. S\u00e5 selvom ACI er bygget op omkring det fysiske netv\u00e6rk, ser forbindelserne til virtuelle servere meget enklere ud end til fysiske. ACI har allerede indbygget integration med VMWare og MS Hyper-V samt support for OpenStack og RedHat Virtualization. Fra et tidspunkt er der ogs\u00e5 indbygget support for containerplatforme: Kubernetes, OpenShift, Cloud Foundry, hvilket g\u00e6lder b\u00e5de anvendelse af politikker og overv\u00e5gning, s\u00e5 netv\u00e6rksadministratoren straks kan se, hvilke pods der k\u00f8rer p\u00e5 hvilke v\u00e6rter, og i hvilke grupper de er blevet placeret.<\/p>\n

Udover at blive inkluderet i en eller anden portgruppe har virtuelle servere yderligere egenskaber: navn, attributter osv., som kan bruges som kriterier for deres flytning til en anden gruppe, for eksempel ved omd\u00f8bning af VM eller ved tilf\u00f8jelse af et ekstra tag. Cisco kalder dette mikrosementeringsgrupper, selvom selve konstruktionen med muligheden for at oprette mange sikkerhedssegmenter i form af EPG i det samme subnet ogs\u00e5 er en form for mikrosementering. N\u00e5, det ved leverand\u00f8ren bedre. <\/p>\n

EPG'er er i bund og grund rent logiske konstruktioner, der ikke er knyttet til specifikke switcher, servere osv., s\u00e5 man kan udf\u00f8re operationer med dem og konstruktioner baseret p\u00e5 dem (applikationer og lejere), som er vanskelige i almindelige netv\u00e6rk, eksempelvis kloning. Det er derfor meget let at oprette en klon af produktionsmilj\u00f8et for at f\u00e5 et testmilj\u00f8, der er identisk med produktionen. Det kan g\u00f8res manuelt, men det er bedre (og lettere) at g\u00f8re det via API. <\/p>\n

Generelt er logikken for styring i ACI slet ikke som det, man normalt m\u00f8der
\ni traditionelle netv\u00e6rk fra den samme Cisco: det programmerbare interface er prim\u00e6rt, mens GUI eller CLI er sekund\u00e6re, da de arbejder via det samme API. Derfor begynder n\u00e6sten alle, der arbejder med ACI, at navigere i den objektmodel, der bruges til administration, og at automatisere noget til deres behov. Det er nemmest at g\u00f8re det fra Python: der er gode, f\u00e6rdige v\u00e6rkt\u00f8jer til det. <\/p>\n

De lovede frustrationer<\/h3>\n

\nHovedproblemet er, at mange ting i ACI er gjort anderledes. For at arbejde ordentligt med det, skal man genl\u00e6res. Dette g\u00e6lder is\u00e6r for netv\u00e6rksdrifts teams hos store kunder, hvor ingeni\u00f8rer i \u00e5revis har besk\u00e6ftiget sig med at 'skriv VLANs' efter ans\u00f8gninger. Det, at VLAN nu ikke l\u00e6ngere er VLAN, og at man overhovedet ikke beh\u00f8ver at oprette VLAN'er manuelt for at anbringe nye netv\u00e6rk i virtualiserede v\u00e6rter, fuldst\u00e6ndig 'nedbryder' de traditionelle netv\u00e6rksfolk og tvinger dem til at h\u00e6nge fast i de vante metoder. Det skal bem\u00e6rkes, at Cisco har fors\u00f8gt at g\u00f8re pillen lidt s\u00f8dere ved at tilf\u00f8je en 'NXOS-lignende' CLI til kontrolleren, som muligg\u00f8r ops\u00e6tning fra et interface, der ligner traditionelle switcher. Men alligevel, for at kunne bruge ACI ordentligt, skal man forst\u00e5, hvordan det fungerer. <\/p>\n

Set med hensyn til prisniveauet for store og mellemstore ACI-netv\u00e6rk adskiller det sig ikke v\u00e6sentligt fra traditionelle netv\u00e6rk p\u00e5 Cisco-udstyr, da de samme switche anvendes til deres opbygning (Nexus 9000 kan fungere b\u00e5de i ACI og i traditionel tilstand og er nu blevet en vigtig \"arbejdshest\" for nye datacenterprojekter). For datacentre med to switche giver tilstedev\u00e6relsen af controllere og Spine-Leaf-arkitektur naturligvis en betydelig forskel. For nylig er der blevet lanceret en Mini ACI-fabrik, hvor to af de tre controllere er blevet erstattet af virtuelle maskiner. Dette hj\u00e6lper med at reducere prisforskellen, men den er stadig til stede. S\u00e5 for kunden dikteres valget af, hvor meget han er interesseret i sikkerhedsfunktioner, integrationsmuligheder med virtualisering, centraliseret styring og lignende.
\n
Kilde: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u0421 \u043f\u043e\u043c\u043e\u0449\u044c\u044e \u0432\u043e\u0442 \u044d\u0442\u043e\u0433\u043e \u0432\u043e\u043b\u0448\u0435\u0431\u043d\u043e\u0433\u043e \u043a\u0443\u0441\u043a\u0430 \u0441\u043a\u0440\u0438\u043f\u0442\u0430 Cisco ACI \u043c\u043e\u0436\u043d\u043e \u0431\u044b\u0441\u0442\u0440\u043e \u043d\u0430\u0441\u0442\u0440\u043e\u0438\u0442\u044c \u0441\u0435\u0442\u044c. \u0421\u0435\u0442\u0435\u0432\u0430\u044f \u0444\u0430\u0431\u0440\u0438\u043a\u0430 \u0434\u043b\u044f \u0426\u041e\u0414\u0430 Cisco ACI c\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u0435\u0442 \u0443\u0436\u0435 \u043f\u044f\u0442\u044c \u043b\u0435\u0442, \u043d\u043e \u043d\u0430 \u0425\u0430\u0431\u0440\u0435 \u043f\u0440\u043e \u043d\u0435\u0451 \u0442\u043e\u043b\u043a\u043e\u043c \u043d\u0438\u0447\u0435\u0433\u043e \u043d\u0435 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u043d\u043e, \u0432\u043e\u0442 \u0438 \u0440\u0435\u0448\u0438\u043b \u044d\u0442\u043e \u043d\u0435\u043c\u043d\u043e\u0433\u043e \u0438\u0441\u043f\u0440\u0430\u0432\u0438\u0442\u044c. \u0420\u0430\u0441\u0441\u043a\u0430\u0436\u0443 \u043d\u0430 \u0441\u0432\u043e\u0451\u043c \u043e\u043f\u044b\u0442\u0435, \u0447\u0442\u043e \u044d\u0442\u043e \u0442\u0430\u043a\u043e\u0435, \u043a\u0430\u043a\u0430\u044f \u043e\u0442 \u043d\u0435\u0451 \u043f\u043e\u043b\u044c\u0437\u0430 \u0438 \u0433\u0434\u0435 \u0443 \u043d\u0435\u0451 \u0433\u0440\u0430\u0431\u043b\u0438. \u0427\u0442\u043e […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-35291","post","type-post","status-publish","format-standard","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\udd47Netv\u00e6rksfabrik til datacenteret Cisco ACI - til hj\u00e6lp for administratoren | ProHoster","description":"Ved hj\u00e6lp af denne magiske bid kode.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/setevaya-fabrika-dlya-tsoda-cisco-aci-v-pomoshh-adminu","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\udd47\u0421\u0435\u0442\u0435\u0432\u0430\u044f \u0444\u0430\u0431\u0440\u0438\u043a\u0430 \u0434\u043b\u044f \u0426\u041e\u0414\u0430 Cisco ACI \u2014 \u0432 \u043f\u043e\u043c\u043e\u0449\u044c \u0430\u0434\u043c\u0438\u043d\u0443 | ProHoster","og:description":"\u0421 \u043f\u043e\u043c\u043e\u0449\u044c\u044e \u0432\u043e\u0442 \u044d\u0442\u043e\u0433\u043e \u0432\u043e\u043b\u0448\u0435\u0431\u043d\u043e\u0433\u043e \u043a\u0443\u0441\u043a\u0430 \u0441\u043a\u0440\u0438\u043f\u0442\u0430.","og:url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/setevaya-fabrika-dlya-tsoda-cisco-aci-v-pomoshh-adminu","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:03:28+00:00","article:modified_time":"2019-10-31T19:03:28+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"35291","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-02-08 20:27:18","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:06:24","updated":"2026-02-08 20:27:18","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/35291","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=35291"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/35291\/revisions"}],"predecessor-version":[{"id":157819,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/35291\/revisions\/157819"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=35291"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=35291"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=35291"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}