{"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\/it\/blog\/administrirovanie\/setevaya-fabrika-dlya-tsoda-cisco-aci-v-pomoshh-adminu","title":{"rendered":"Network Fabric per il Data Center Cisco ACI \u2014 a supporto dell'amministratore","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Network
\nCon questo pezzo magico di script Cisco ACI, \u00e8 possibile configurare rapidamente la rete.<\/i><\/p>\n

La rete fabricha per i data center Cisco ACI esiste da cinque anni, ma su Habr non si \u00e8 parlato molto di essa, quindi ho deciso di rimediare un po'. Racconter\u00f2 dalla mia esperienza cos'\u00e8, quali sono i vantaggi e quali sono le insidie. <\/p>\n

Cos'\u00e8 e da dove proviene?<\/h3>\n

\nAl momento dell'annuncio di ACI (Application Centric Infrastructure) nel 2013, i concorrenti avanzavano da tre fronti contro gli approcci tradizionali alle reti dei data center. <\/p>\n

Da un lato, le soluzioni SDN di \"prima generazione\" basate su OpenFlow promettevano di rendere le reti pi\u00f9 flessibili e economiche allo stesso tempo. L'idea era di spostare le decisioni, tradizionalmente effettuate dal software proprietario degli switch, a un controller centrale. <\/p>\n

Questo controller avrebbe avuto una visione unica di tutto ci\u00f2 che accadeva e, a partire da essa, avrebbe programmato l'hardware di tutti gli switch a livello di regole per il trattamento di flussi specifici. <\/a><\/noindex>
\nDall'altro lato, le soluzioni di rete overlay permettevano di realizzare la connettivit\u00e0 desiderata e le politiche di sicurezza senza apportare modifiche alla rete fisica, costruendo tunnel software tra host virtualizzati. Un esempio molto noto di questo approccio era la soluzione di Nicira, che a quel punto era gi\u00e0 stata acquisita da VMWare per 1,26 miliardi di dollari e ha dato origine all'attuale VMWare NSX. Aggiungeva un po' di pepe alla situazione il fatto che i cofondatori di Nicira fossero le stesse persone che in precedenza erano state all'origine di OpenFlow, ora affermavano che per costruire la fabbrica di un data center OpenFlow non \u00e8 adatto<\/a><\/noindex>.<\/p>\n

Infine, i chip di commutazione disponibili sul mercato aperto (quelli che vengono definiti merchant silicon) hanno raggiunto un livello di maturit\u00e0 tale da rappresentare una reale minaccia per i produttori tradizionali di switch. Se un tempo ogni fornitore sviluppava i propri chip per i suoi switch, nel tempo i chip dei produttori esterni, principalmente da Broadcom, hanno iniziato ad avvicinarsi ai chip dei fornitori in termini di funzionalit\u00e0 e, rispetto al rapporto prezzo\/prestazioni, li superavano. Per questo motivo, molti ritenevano che i giorni degli switch basati su chip progettati internamente fossero contati.<\/p>\n

ACI \u00e8 stata una \u00abrisposta asimmetrica\u00bb di Cisco (piuttosto, della societ\u00e0 Insieme entrata a far parte di essa, fondata da ex dipendenti) a tutto ci\u00f2 che \u00e8 stato elencato. <\/p>\n

Qual \u00e8 la differenza con OpenFlow?<\/h3>\n

\nDal punto di vista della distribuzione delle funzioni, ACI \u00e8 di fatto l'opposto di OpenFlow.
\nNell'architettura OpenFlow, il controller \u00e8 responsabile della scrittura di regole dettagliate (flussi)
\nnell'hardware di tutti gli switch, il che significa che in una rete su larga scala pu\u00f2 essere responsabile della gestione e, soprattutto, della modifica di decine di milioni di record in centinaia di punti nella rete; pertanto, le sue prestazioni e affidabilit\u00e0 in una grande implementazione diventano un collo di bottiglia.<\/p>\n

In ACI si utilizza un approccio inverso: c'\u00e8 sicuramente anche un controller, ma gli switch ricevono da esso politiche dichiarative ad alto livello, e la loro traduzione in dettagli specifici delle configurazioni hardware viene eseguita dallo switch stesso. Il controller pu\u00f2 essere riavviato o spento del tutto, e non succede nulla di male alla rete, tranne, ovviamente, l'assenza in quel momento della possibilit\u00e0 di gestione. \u00c8 interessante notare che in ACI ci sono situazioni in cui OpenFlow viene comunque utilizzato, ma in modo locale all'interno dell'host per programmare Open vSwitch.<\/p>\n

ACI \u00e8 interamente costruita su un trasporto overlay basato su VXLAN, ma include anche il trasporto IP sottostante all'interno di una soluzione unica. Cisco ha definito questo termine \"overlay integrato\". Come punto di terminazione degli overlay, in ACI, si utilizzano per la maggior parte degli switch di fabbrica (lo fanno alla velocit\u00e0 del canale). Gli host non devono sapere nulla sulla fabbrica, sull'incapsulazione, ecc.; tuttavia, in alcuni casi (ad esempio, per la connessione di host OpenStack), il traffico VXLAN pu\u00f2 raggiungerli.<\/p>\n

Gli overlay in ACI non vengono utilizzati solo per garantire una connettivit\u00e0 flessibile attraverso la rete di trasporto, ma anche per la trasmissione di metainformazioni (utilizzate, ad esempio, per l'applicazione delle politiche di sicurezza). <\/p>\n

I chip Broadcom erano gi\u00e0 utilizzati da Cisco negli switch della serie Nexus 3000. Nella famiglia Nexus 9000, appositamente rilasciata per supportare ACI, \u00e8 stata inizialmente implementata una modello ibrido chiamato Merchant+. Nello switch sono stati utilizzati contemporaneamente il nuovo chip Broadcom Trident 2 e un chip complementare sviluppato da Cisco, che implementava tutta la magia di ACI. A quanto pare, questo ha consentito di accelerare il lancio del prodotto e di ridurre il prezzo dello switch a un livello vicino ai modelli basati solo su Trident 2. Questo approccio \u00e8 stato sufficiente per i primi due-tre anni di fornitura di ACI. Durante questo periodo, Cisco ha sviluppato e lanciato sul mercato la generazione successiva di Nexus 9000 gi\u00e0 basata su chip proprietari con prestazioni e funzionalit\u00e0 superiori, ma al medesimo livello di prezzo. Le specifiche esterne in termini di interazione all'interno della fabbrica sono rimaste del tutto invariate. Nel contempo, l'hardware interno \u00e8 stato completamente rivoluzionato: qualcosa di simile a un refactoring, ma per il ferro.<\/p>\n

Come \u00e8 strutturata l'architettura Cisco ACI <\/h3>\n

\nNel caso pi\u00f9 semplice, ACI \u00e8 costruito secondo la topologia di rete Clos, o, come viene spesso chiamata, Spine-Leaf. Ci possono essere da due (o uno, se non ci interessa la resilienza) a sei switch di livello Spine. Di conseguenza, maggiore \u00e8 il numero, maggiore \u00e8 la resilienza (minore riduzione della banda e dell'affidabilit\u00e0 in caso di guasto o manutenzione di uno Spine) e la performance complessiva. Tutte le connessioni esterne vanno agli switch di livello Leaf: ci sono server, interfacce con reti esterne via L2 o L3 e connessioni ai controller APIC. In generale, con ACI non solo la configurazione, ma anche la raccolta di statistiche, il monitoraggio dei guasti e altro \u2014 tutto avviene tramite l'interfaccia dei controller, che in implementazioni di dimensioni normali sono tre. <\/p>\n

Non \u00e8 mai necessario collegarsi agli switch tramite console, neppure per avviare la rete: il controller rileva automaticamente gli switch e li aggrega in una fabbrica, incluso la configurazione di tutti i protocolli di servizio, quindi, a tal proposito, \u00e8 molto importante registrare i numeri di serie dell'attrezzatura installata durante il montaggio, per non dover indovinare quale switch si trova in quale rack. Per il troubleshooting, se necessario, ci si pu\u00f2 collegare agli switch tramite SSH: su di essi sono state accuratamente riprodotte le comuni show-commands di Cisco. <\/p>\n

All'interno, il fabric utilizza trasporto IP, quindi non ci sono Spanning Tree o altre orribili reliquie del passato: tutti i collegamenti sono attivi e la convergenza in caso di guasti \u00e8 molto rapida. Il traffico nel fabric viene trasmesso attraverso tunnel basati su VXLAN. In effetti, Cisco stessa chiama l'incapsulazione iVXLAN, e si differenzia dal normale VXLAN perch\u00e9 i campi riservati nell'intestazione di rete vengono utilizzati per la trasmissione di informazioni di servizio, soprattutto riguardo al rapporto del traffico con il gruppo EPG. Questo consente di implementare regole di interazione tra i gruppi direttamente nell'hardware, utilizzando i loro numeri proprio come si utilizzano gli indirizzi nelle normali access list. <\/p>\n

I tunnel consentono di estendere attraverso il trasporto IP interno sia segmenti L2 che L3 (cio\u00e8 VRF). In questo caso, il gateway predefinito \u00e8 distribuito. Ci\u00f2 significa che ogni switch si occupa dell'instradamento del traffico in entrata nel fabric. Dal punto di vista della logica di trasmissione del traffico, ACI \u00e8 simile a un fabric basato su VXLAN\/EVPN. <\/p>\n

Se \u00e8 cos\u00ec, quali sono le differenze? In tutto il resto! <\/h3>\n

\nLa prima differenza che si incontra in ACI \u00e8 il modo in cui i server vengono connessi alla rete. Nelle reti tradizionali, la connessione sia dei server fisici che delle macchine virtuali avviene in VLAN, e tutto il resto dipende da ci\u00f2: connettivit\u00e0, sicurezza, ecc. In ACI, invece, si utilizza una struttura che Cisco chiama EPG (End-point Group), dalla quale non si pu\u00f2 prescindere. Si pu\u00f2 equiparare a VLAN? S\u00ec, ma in questo caso si rischia di perdere gran parte di ci\u00f2 che offre ACI. <\/p>\n

Tutte le regole di accesso vengono formulate rispetto a EPG, e in ACI per impostazione predefinita viene utilizzato il principio della \"lista bianca\", ovvero \u00e8 consentito solo il traffico il cui passaggio \u00e8 esplicitamente autorizzato. Ci\u00f2 significa che possiamo creare gruppi EPG \"Web\" e \"MySQL\" e definire una regola che consente l'interazione tra di essi solo sulla porta 3306. Questo funzioner\u00e0 senza legami agli indirizzi di rete e persino all'interno della stessa sottorete! <\/p>\n

Abbiamo clienti che hanno scelto ACI proprio per questa caratteristica, poich\u00e9 consente di limitare gli accessi tra i server (virtuali o fisici \u2014 non importa), senza spostarli tra le sottoreti, il che significa non modificare l'indirizzamento. S\u00ec, s\u00ec, sappiamo che nessuno scrive a mano Indirizzi IP<\/a> nelle configurazioni delle applicazioni, vero?<\/p>\n

Le regole per il passaggio del traffico in ACI sono chiamate contratti. In tale contratto, uno o pi\u00f9 gruppi o livelli in un'applicazione multi-tier diventano fornitori di servizi (ad esempio, un servizio di database), mentre altri sono i consumatori. Un contratto pu\u00f2 semplicemente consentire il traffico, oppure pu\u00f2 fare qualcosa di pi\u00f9 complesso, come reindirizzarlo a un firewall o a un bilanciatore di carico, oltre a modificare il valore QoS.<\/p>\n

Come vengono inseriti i server in questi gruppi? Se si tratta di server fisici o di qualcosa integrato in una rete esistente in cui abbiamo creato un trunk VLAN, \u00e8 necessario specificare la porta dello switch e la VLAN utilizzata su di essa per inserirli in EPG. Come possiamo vedere, le VLAN appaiono dove non possono mancare.<\/p>\n

Se invece i server sono delle macchine virtuali, \u00e8 sufficiente riferirsi all'ambiente di virtualizzazione connesso, e poi tutto avverr\u00e0 da solo: verr\u00e0 creata un port-group (se parliamo in termini di VMWare) per collegare le VM, verranno assegnate le VLAN o le VXLAN necessarie, e cos\u00ec via. Quindi, anche se ACI \u00e8 costruito attorno alla rete fisica, per i server virtuali i collegamenti sembrano molto pi\u00f9 semplici rispetto a quelli fisici. ACI ha gi\u00e0 integrato il collegamento con VMWare e MS Hyper-V, oltre al supporto per OpenStack e RedHat Virtualization. A un certo punto \u00e8 apparso anche il supporto integrato per le piattaforme container: Kubernetes, OpenShift, Cloud Foundry, e riguarda sia l'applicazione delle politiche che il monitoraggio. Ci\u00f2 significa che l'amministratore di rete pu\u00f2 vedere immediatamente su quali host operano quali pod e in quali gruppi sono stati inseriti.<\/p>\n

Oltre all'inclusione in un certo port-group, i server virtuali hanno propriet\u00e0 aggiuntive: nome, attributi, ecc., che possono essere utilizzate come criteri per il loro trasferimento in un altro gruppo, ad esempio in caso di rinomina di una VM o dell'aggiunta di un'etichetta. Cisco chiama queste microsegmentazioni, anche se, a dire il vero, la stessa struttura che consente di creare molti segmenti di sicurezza sotto forma di EPG nella stessa sottorete \u00e8 anch'essa una sorta di microsegmentazione. Beh, la casa produttrice sa meglio. <\/p>\n

Gli EPG sono puramente costrutti logici, non vincolati a specifici switch, server ecc., quindi con essi e le costruzioni basate su di essi (applicazioni e tenant) si possono fare cose difficili da realizzare nelle reti tradizionali, per esempio, clonare. Di conseguenza, per esempio, \u00e8 molto facile creare un clone di un ambiente produttivo per ottenere un ambiente di test garantito identico al produttivo. Si pu\u00f2 fare manualmente, ma \u00e8 meglio (e pi\u00f9 semplice) farlo tramite API. <\/p>\n

In generale, la logica di gestione in ACI \u00e8 completamente diversa da quella con cui ci si imbatte di solito
\nnelle reti tradizionali della stessa Cisco: l'interfaccia programmabile \u00e8 primaria, mentre GUI o CLI sono secondarie, poich\u00e9 funzionano tramite la stessa API. Pertanto, quasi chiunque lavori con ACI, dopo un certo tempo, inizia a orientarsi nel modello a oggetti utilizzato per la gestione e a automatizzare qualcosa per le proprie esigenze. \u00c8 pi\u00f9 semplice farlo con Python: ci sono strumenti pratici gi\u00e0 pronti per lui. <\/p>\n

Le trappole promesse<\/h3>\n

\nIl problema principale \u00e8 che molte cose in ACI sono progettate diversamente. Per iniziare a lavorare correttamente con essa, \u00e8 necessario riprendere l'apprendimento. Questo vale soprattutto per i team di gestione della rete nei grandi clienti, dove gli ingegneri si sono occupati per anni di \"stabilire VLAN\" su richiesta. Il fatto che ora una VLAN non sia pi\u00f9 una VLAN, e che per la creazione di nuove reti su host virtualizzati non sia affatto necessario creare VLAN manualmente, sorprende completamente gli addetti alle reti tradizionali e li costringe a mantenersi aggrappati agli approcci abituali. Va notato che Cisco ha cercato di rendere le cose un po' pi\u00f9 facili e ha aggiunto un CLI \"simile a NXOS\" nel controller, che consente di effettuare configurazioni tramite un'interfaccia simile a quella degli switch tradizionali. Tuttavia, per iniziare a utilizzare ACI in modo corretto, sar\u00e0 necessario comprendere come funziona. <\/p>\n

Dal punto di vista dei costi, le reti ACI su larga e media scala non si differenziano effettivamente dalle reti tradizionali con hardware Cisco, poich\u00e9 si utilizzano gli stessi switch (i Nexus 9000 possono operare sia in modalit\u00e0 ACI sia in modalit\u00e0 tradizionale e sono attualmente il \"cavallo di battaglia\" principale per i nuovi progetti nei data center). Tuttavia, per i data center che utilizzano due switch, la presenza di controller e dell'architettura Spine-Leaf si fa sentire. Recentemente \u00e8 stata introdotta una Mini ACI-factory, in cui due dei tre controller sono stati sostituiti da macchine virtuali. Questo consente di ridurre la differenza di costo, ma essa rimane comunque. Pertanto, per il cliente, la scelta \u00e8 dettata dall'interesse verso le funzionalit\u00e0 di sicurezza, integrazione con la virtualizzazione, punto di gestione unico e altro ancora.
\n
Fonte: 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\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\udd47Fabrica di rete per il data center Cisco ACI - per aiutare gli amministratori | ProHoster","description":"Con questo fantastico pezzo di script.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/setevaya-fabrika-dlya-tsoda-cisco-aci-v-pomoshh-adminu","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","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\/it\/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\/it\/wp-json\/wp\/v2\/posts\/35291","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=35291"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/35291\/revisions"}],"predecessor-version":[{"id":157819,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/35291\/revisions\/157819"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=35291"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=35291"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=35291"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}