{"id":36263,"date":"2019-10-31T22:10:35","date_gmt":"2019-10-31T19:10:35","guid":{"rendered":"https:\/\/prohoster.info\/blog\/aerodisk-engine-katastrofoustojchivost-chast-2-metroklaster\/"},"modified":"2019-10-31T22:10:35","modified_gmt":"2019-10-31T19:10:35","slug":"aerodisk-engine-katastrofoustojchivost-chast-2-metroklaster","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/aerodisk-engine-katastrofoustojchivost-chast-2-metroklaster","title":{"rendered":"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster\" src=\"\/wp-content\/uploads\/2019\/07\/7671ec455e464b7fe98b0b8ffcd38e24.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ciao, lettori di Habr! Nell'articolo precedente, abbiamo parlato di una semplice misura di resilienza alle catastrofi nei sistemi di archiviazione AERODISK ENGINE: la replica. In questo articolo ci immergeremo in un tema pi\u00f9 complesso e interessante: il metrocluster, ovvero uno strumento automatizzato per la protezione contro le catastrofi per due datacenter, che consente ai datacenter di operare in modalit\u00e0 attiva-attiva. Racconteremo, mostreremo, romperemo e ripareremo.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2 id=\"kak-obychno-v-nachale-teoriya\">Come al solito, iniziamo con la teoria<\/h2>\n<p><\/p>\n<p>Il metrocluster \u00e8 un cluster distribuito su pi\u00f9 sedi all'interno di una citt\u00e0 o di un'area. La parola \"cluster\" ci suggerisce chiaramente che il complesso \u00e8 automatizzato, il che significa che il passaggio dei nodi del cluster in caso di guasti (failover) avviene automaticamente. <\/p>\n<p><\/p>\n<p>Qui si trova la principale differenza tra metrocluster e la normale replica. Automazione delle operazioni. In caso di determinati eventi (guasto del datacenter, interruzione dei collegamenti, ecc.), il sistema di archiviazione eseguir\u00e0 autonomamente le azioni necessarie per garantire la disponibilit\u00e0 dei dati. Con le normali repliche, tali azioni vengono eseguite interamente o parzialmente manualmente dall'amministratore.<\/p>\n<p><\/p>\n<h3 id=\"dlya-chego-eto-nuzhno\">A cosa serve?<\/h3>\n<p><\/p>\n<p>L'obiettivo principale dei clienti che utilizzano diverse implementazioni del metrocluster \u00e8 ridurre al minimo il RTO (Recovery Time Objective). Questo significa ridurre al minimo il tempo di ripristino dei servizi IT dopo un guasto. Se si utilizza la normale replica, il tempo di ripristino sar\u00e0 sempre maggiore rispetto a quello di un metrocluster. Perch\u00e9? Molto semplice. L'amministratore deve essere presente in loco e commutare manualmente la replica, mentre il metrocluster lo fa automaticamente.<\/p>\n<p><\/p>\n<p>Se non hai un amministratore a guardia dedicato, che non dorme, non mangia, non fuma e non si ammala, e che guarda lo stato del sistema di archiviazione 24 ore su 24, non puoi garantire che l'amministratore sar\u00e0 disponibile per commutare manualmente durante un guasto. <\/p>\n<p><\/p>\n<p>Di conseguenza, il RTO in assenza di metrocluster o di un amministratore immortale di livello 99 del servizio di addetti sar\u00e0 pari alla somma del tempo di commutazione di tutti i sistemi e dell'intervallo di tempo massimo entro il quale l'amministratore inizier\u00e0 sicuramente a lavorare con il sistema di archiviazione e i sistemi correlati. <\/p>\n<p><\/p>\n<p>Dunque arriviamo a una conclusione ovvia: il metrocluster deve essere utilizzato nel caso in cui il requisito per l'RTO sia di minuti, non di ore o giorni. Vale a dire, quando, in caso del peggior fallimento del data center, il dipartimento IT deve garantire all'azienda il tempo per il ripristino dell'accesso ai servizi IT in pochi minuti, se non secondi.<\/p>\n<p><\/p>\n<h3 id=\"kak-eto-rabotaet\">Come funziona?<\/h3>\n<p><\/p>\n<p>A livello inferiore, il metrocluster utilizza un meccanismo di replica sincrona dei dati, che abbiamo descritto nel precedente articolo (vedi. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/aerodisk\/blog\/456348\/\">link<\/a><\/noindex>). Poich\u00e9 la replica \u00e8 sincrona, anche i requisiti ad essa associati sono di conseguenza, e pi\u00f9 precisamente:<\/p>\n<p><\/p>\n<ul>\n<li>fibra ottica come fisica, Ethernet a 10 gigabit (o superiore);<\/li>\n<li>distanza massima tra i data center non superiore a 40 chilometri;<\/li>\n<li>latenza del canale ottico tra i data center (tra le unit\u00e0 di storage) fino a 5 millisecondi (ottimale 2).<\/li>\n<\/ul>\n<p><\/p>\n<p>Tutti questi requisiti sono di natura raccomandativa, cio\u00e8 il metrocluster funzioner\u00e0 anche se questi requisiti non vengono rispettati, ma \u00e8 importante capire che le conseguenze della mancata osservanza di questi requisiti equivalgono a un rallentamento delle prestazioni di entrambe le unit\u00e0 di storage nel metrocluster.<\/p>\n<p><\/p>\n<p>Quindi, per la trasmissione dei dati tra le unit\u00e0 di storage si utilizza una replica sincrona; in che modo le repliche vengono automaticamente commutate e, soprattutto, come evitare il \"split-brain\"? A questo scopo, a livello superiore viene utilizzata un'entit\u00e0 aggiuntiva: l'arbitro. <\/p>\n<p><\/p>\n<h3 id=\"kak-rabotaet-arbitr-i-v-chem-ego-zadacha\">Come funziona l'arbitro e qual \u00e8 il suo compito?<\/h3>\n<p><\/p>\n<p>L'arbitro \u00e8 una piccola macchina virtuale o un cluster hardware che deve essere avviato in una terza sede (ad esempio, in un ufficio) e deve garantire l'accesso alle unit\u00e0 di storage tramite ICMP e SSH. Dopo l'avvio, l'arbitro deve impostare un IP e poi, dal lato delle unit\u00e0 di storage, specificare il suo indirizzo e gli indirizzi dei controller remoti che partecipano al metrocluster. Dopo di che, l'arbitro \u00e8 pronto per lavorare.<\/p>\n<p><\/p>\n<p>L'arbitro esegue un monitoraggio costante di tutte le unit\u00e0 di storage nel metrocluster e, in caso di inattivit\u00e0 di un determinato sistema di storage, dopo aver confermato l'inattivit\u00e0 da un altro membro del cluster (una delle unit\u00e0 di storage \"attive\"), prende una decisione sull'avvio della procedura di commutazione delle regole di replica e sulla mappatura.<\/p>\n<p><\/p>\n<p>Un aspetto molto importante. L'arbitro deve sempre trovarsi in una sede diversa da quella in cui si trovano le unit\u00e0 di storage, cio\u00e8 n\u00e9 nel data center 1, dove si trova l'unit\u00e0 di storage 1, n\u00e9 nel data center 2, dove \u00e8 installata l'unit\u00e0 di storage 2. <\/p>\n<p><\/p>\n<p>Perch\u00e9? Perch\u00e9 solo in questo modo l'arbitro, con l'aiuto di uno dei controller SCD rimasti, pu\u00f2 determinare in modo chiaro e senza errori il verificarsi di guasti in uno dei due siti dove sono installati i controller SCD. Qualsiasi altra modalit\u00e0 di posizionamento dell'arbitro potrebbe portare a uno split-brain. <\/p>\n<p><\/p>\n<h3 id=\"teper-pogruzimsya-v-detali-raboty-arbitra\">Ora approfondiamo i dettagli del funzionamento dell'arbitro.<\/h3>\n<p><\/p>\n<p>Sull'arbitro sono attive diverse applicazioni che interrogano continuamente tutti i controller SCD. Se il risultato dell'interrogazione \u00e8 diverso dal precedente (disponibile\/non disponibile), viene registrato in un piccolo database che opera anche sull'arbitro.<\/p>\n<p><\/p>\n<p><strong>Esaminiamo la logica di funzionamento dell'arbitro in modo pi\u00f9 dettagliato.<\/strong><\/p>\n<p><\/p>\n<p><u>Passo 1. Determinazione della non disponibilit\u00e0.<\/u> L'evento che segnala un guasto del SCD \u00e8 l'assenza di ping da entrambi i controller di uno stesso SCD per 5 secondi. <\/p>\n<p><\/p>\n<p><u>Passo 2. Avvio della procedura di commutazione. <\/u>Dopo che l'arbitro ha compreso che uno degli SCD non \u00e8 disponibile, invia una richiesta all'SCD 'vivo' per accertarsi che l'SCD 'morto' sia realmente inutilizzabile. <\/p>\n<p><\/p>\n<p>Dopo aver ricevuto tale comando dall'arbitro, il secondo SCD (quello 'vivo') verifica ulteriormente la disponibilit\u00e0 del primo SCD, se non \u00e8 disponibile, invia all'arbitro la conferma della sua supposizione. L'SCD \u00e8 realmente non disponibile. <\/p>\n<p><\/p>\n<p>Dopo aver ricevuto tale conferma, l'arbitro avvia la procedura remota di commutazione della replica e attivazione del mapping su quelle repliche che erano attive (primarie) sul SCD guastato e invia il comando al secondo SCD di trasformare queste repliche da secondarie a primarie e attivare il mapping. Il secondo SCD, di conseguenza, esegue queste procedure, dopo di che garantisce l'accesso agli LUN persi.<\/p>\n<p><\/p>\n<p>Perch\u00e9 \u00e8 necessaria una verifica aggiuntiva? Per il quorum. Cio\u00e8 la maggioranza del numero dispari (3) di membri del cluster deve confermare il guasto di uno dei nodi del cluster. Solo allora questa decisione sar\u00e0 davvero corretta. Questo \u00e8 necessario per evitare commutazioni errate e, di conseguenza, lo split-brain. <\/p>\n<p><\/p>\n<p>Il passo 2 richiede circa 5-10 secondi, quindi, considerando il tempo necessario per determinare la non disponibilit\u00e0 (5 secondi), entro 10-15 secondi dopo un guasto, gli LUN del SCD guastato saranno automaticamente disponibili per lavorare con il SCD vivo. <\/p>\n<p><\/p>\n<p>Evidentemente, per evitare la disconnessione con gli host, \u00e8 necessario anche prendersi cura dell'impostazione corretta dei timeout sugli host. Il timeout raccomandato \u00e8 di almeno 30 secondi. Questo impedir\u00e0 all'host di interrompere la connessione con lo storage durante il passaggio del carico in caso di emergenza e garantir\u00e0 la continuit\u00e0 delle operazioni di input\/output.<\/p>\n<p><\/p>\n<blockquote><p>Aspetta un attimo, quindi se il metrocluster funziona cos\u00ec bene, a cosa serve la replica normale? <\/p><\/blockquote>\n<p>In realt\u00e0 le cose non sono cos\u00ec semplici. <\/p>\n<p><\/p>\n<h3 id=\"rassmotrim-plyusy-i-minusy-metroklastera\">Analizziamo i pro e i contro del metrocluster.<\/h3>\n<p><\/p>\n<p>Dunque, abbiamo capito che i vantaggi evidenti del metrocluster rispetto alla replica normale sono:<\/p>\n<p><\/p>\n<ul>\n<li>Automazione totale, che garantisce un minimo tempo di recupero in caso di disastro;<\/li>\n<li>E tutto :-).<\/li>\n<\/ul>\n<p><\/p>\n<p>Ora, attenzione, i contro:<\/p>\n<p><\/p>\n<ul>\n<li>Costo della soluzione. Anche se il metrocluster nei sistemi Aerodisk non richiede licenze aggiuntive (si utilizza la stessa licenza della replica), il costo della soluzione sar\u00e0 comunque superiore rispetto all'uso della replica sincrona. Sar\u00e0 necessario soddisfare tutti i requisiti per la replica sincrona, pi\u00f9 i requisiti per il metrocluster relativi a ulteriori commutazioni e location aggiuntive (vedi pianificazione del metrocluster);<\/li>\n<li>Complessit\u00e0 della soluzione. Il metrocluster \u00e8 strutturato in modo significativamente pi\u00f9 complesso rispetto a una replica normale e richiede molta pi\u00f9 attenzione e risorse per la pianificazione, la configurazione e la documentazione.<\/li>\n<\/ul>\n<p><\/p>\n<p>In sintesi. <strong>Il metrocluster \u00e8 sicuramente una soluzione molto tecnologica e valida quando \u00e8 davvero necessario garantire un RTO in secondi o minuti.<\/strong> Ma se tale esigenza non esiste e un RTO in ore va bene per il business, non ha senso utilizzare strumenti cos\u00ec complessi. \u00c8 sufficiente una replica normale, poich\u00e9 il metrocluster comporter\u00e0 costi aggiuntivi e una complicazione dell'infrastruttura IT.<\/p>\n<p><\/p>\n<h2 id=\"planirovanie-metroklastera\">Pianificazione del metrocluster<\/h2>\n<p><\/p>\n<p>Questa sezione non pretende di essere una guida esaustiva alla progettazione del metrocluster, ma mostra solo le principali direzioni da considerare se hai deciso di costruire un sistema simile. Pertanto, durante l'effettiva implementazione del metrocluster, assicurati di coinvolgere per consulenze il produttore dello storage (cio\u00e8 noi) e altri sistemi correlati.<\/p>\n<p><\/p>\n<h3 id=\"ploschadki\">Location<\/h3>\n<p><\/p>\n<p>Come indicato sopra, per il metroklauster sono necessarie almeno tre sedi. Due data center, in cui opereranno i sistemi di archiviazione e i sistemi correlati, e una terza sede, dove operer\u00e0 l'arbitro.<\/p>\n<p><\/p>\n<p>La distanza raccomandata tra i data center \u00e8 di non oltre 40 chilometri. Distanze maggiori comportano un'alta probabilit\u00e0 di ritardi aggiuntivi, che nel caso del metroklauster sono estremamente indesiderabili. Ricordiamo che i ritardi devono essere fino a 5 millisecondi, anche se sarebbe preferibile rimanere entro 2.<\/p>\n<p><\/p>\n<p>Si consiglia di controllare anche i ritardi durante la fase di pianificazione. Qualsiasi provider di una certa esperienza che offre fibra ottica tra i data center pu\u00f2 organizzare un test di qualit\u00e0 piuttosto rapidamente. <\/p>\n<p><\/p>\n<p>Per quanto riguarda i ritardi fino all'arbitro (cio\u00e8 tra la terza sede e le due prime), il limite raccomandato \u00e8 fino a 200 millisecondi, quindi un normale collegamento VPN aziendale sopra la rete Internet sar\u00e0 sufficiente.<\/p>\n<p><\/p>\n<h3 id=\"kommutaciya-i-set\">Commutazione e rete<\/h3>\n<p><\/p>\n<p>A differenza dello schema con replica, dove \u00e8 sufficiente collegare tra loro i sistemi di archiviazione da sedi diverse, lo schema con il metroklauster richiede il collegamento degli host a entrambi i sistemi di archiviazione in sedi diverse. Per chiarire le differenze, entrambe le configurazioni sono indicate di seguito.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster\" src=\"\/wp-content\/uploads\/2019\/07\/12334c29a498f686e8eb946daab587c1.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster\" src=\"\/wp-content\/uploads\/2019\/07\/46db8c81d15be3f89e1f9dbee4489e3b.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Come si pu\u00f2 vedere nello schema, gli host della sede 1 si collegano sia al sistema di archiviazione 1 sia al sistema di archiviazione 2. Allo stesso modo, gli host della sede 2 si collegano sia al sistema di archiviazione 2 sia al sistema di archiviazione 1. Ci\u00f2 significa che ogni host vede entrambi i sistemi di archiviazione. Questa \u00e8 una condizione essenziale per il funzionamento del metroklauster.<\/p>\n<p><\/p>\n<p>Naturalmente, non c'\u00e8 bisogno di estendere ogni host con un cavo ottico all'altro data center, non ci sarebbero abbastanza porte e cavi. Tutte queste connessioni devono essere eseguite tramite switch Ethernet 10G+ o FibreChannel 8G+ (FC solo per il collegamento tra host e sistemi di archiviazione per IO; il canale di replica \u00e8 al momento disponibile solo tramite IP (Ethernet 10G+). <\/p>\n<p><\/p>\n<p>Ora alcune parole sulla topologia della rete. Un elemento importante \u00e8 la corretta configurazione delle sottoreti. \u00c8 necessario definire subito diverse sottoreti per i seguenti tipi di traffico:<\/p>\n<p><\/p>\n<ul>\n<li>Sottorete per la replica, attraverso la quale i dati verranno sincronizzati tra i sistemi di archiviazione. Possono essercene diverse; in questo caso non ha importanza, tutto dipende dalla topologia di rete attuale (gi\u00e0 implementata). Se ce ne sono due, ovviamente, deve essere configurato il routing tra di esse.<\/li>\n<li>Sottoreti di archiviazione dati, attraverso le quali gli host accederanno alle risorse dello storage (se \u00e8 iSCSI). \u00c8 necessario avere una di queste sottoreti in ogni data center;<\/li>\n<li>Sottoreti di gestione, cio\u00e8 tre sottoreti instradabili in tre posizioni, da cui avviene la gestione dello storage, dove si trova anche l'arbitro.<\/li>\n<\/ul>\n<p><\/p>\n<p>Non consideriamo qui le sottoreti per l'accesso alle risorse degli host, poich\u00e9 esse dipendono fortemente dai compiti specifici. <\/p>\n<p><\/p>\n<p>\u00c8 estremamente importante separare il traffico diverso in sottoreti diverse (\u00e8 particolarmente importante separare la replica dall'input-output), poich\u00e9 mescolare tutto il traffico in un'unica \"sottorete grossa\" render\u00e0 impossibile la gestione di quel traffico, e in presenza di due data center questo potrebbe causare varie forme di collisioni di rete. Non approfondiremo molto questo aspetto in questo articolo, poich\u00e9 della pianificazione di una rete estesa tra i data center si pu\u00f2 leggere in risorse di produttori di apparecchiature di rete, dove viene descritto in dettaglio.<\/p>\n<p><\/p>\n<h3 id=\"konfiguraciya-arbitra\">Configurazione dell'arbitro<\/h3>\n<p><\/p>\n<p>L'arbitro deve garantire l'accesso a tutte le interfacce di gestione dello storage tramite i protocolli ICMP e SSH. \u00c8 importante anche considerare la resilienza dell'arbitro. C'\u00e8 un aspetto da considerare.<\/p>\n<p><\/p>\n<p>La resilienza dell'arbitro \u00e8 auspicabile ma non obbligatoria. Cosa succede se l'arbitro si guasta in un momento non opportuno?<\/p>\n<p><\/p>\n<ul>\n<li>Il funzionamento del metrocluster in condizioni normali non cambier\u00e0, poich\u00e9 l'arbitro non influisce in alcun modo sul funzionamento normale del metrocluster (il suo compito \u00e8 quello di commutare tempestivamente il carico tra i data center).<\/li>\n<li>Se l'arbitro si guasta e \"passa\" oltre un'emergenza in un data center, non ci sar\u00e0 alcuna commutazione, perch\u00e9 non ci sar\u00e0 nessuno a dare i comandi necessari per la commutazione e a organizzare il quorum. In questo caso, il metrocluster si trasformer\u00e0 in uno schema normale con replica, che dovr\u00e0 essere commutato manualmente durante la catastrofe, il che influenzer\u00e0 il RTO.<\/li>\n<\/ul>\n<p><\/p>\n<p>Cosa ne consegue? Se \u00e8 davvero necessario garantire un valore minimo di RTO, \u00e8 necessario garantire la resilienza dell'arbitro. Ci sono due opzioni per farlo:<\/p>\n<p><\/p>\n<ul>\n<li>Eseguire una macchina virtuale con l'arbitro su un hypervisor resiliente, fortunatamente tutti gli hypervisor avanzati supportano la resilienza.<\/li>\n<li>Se sulla terza piattaforma (nell'ufficio convenzionale) \u00e8 difficile montare un cluster adeguato e non esiste un cluster di iperconvergenza, abbiamo previsto una soluzione hardware per l'arbitro, realizzata in un contenitore 2U, in cui operano due normali server x-86 e che pu\u00f2 superare un guasto locale.<\/li>\n<\/ul>\n<p><\/p>\n<p>Raccomandiamo vivamente di garantire la ridondanza dell'arbitro anche se, in condizioni normali, non \u00e8 necessaria per il metrocluster. Ma come dimostrano sia la teoria che la pratica, se si desidera costruire un'infrastruttura realmente resiliente ai disastri, \u00e8 meglio essere previdenti. \u00c8 consigliabile proteggere se stessi e il proprio business dalla \"legge di Murphy\", ovvero dall'improvviso guasto sia dell'arbitro che di uno dei siti dove \u00e8 posizionato lo storage.<\/p>\n<p><\/p>\n<h3 id=\"arhitektura-resheniya\">Architettura della soluzione<\/h3>\n<p><\/p>\n<p>Considerando i requisiti sopra indicati, otteniamo la seguente architettura generale della soluzione.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster\" src=\"\/wp-content\/uploads\/2019\/07\/e60f67d6705d940f1c06b06328bf99a5.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>I LUN devono essere distribuiti uniformemente su due piattaforme per evitare sovraccarichi eccessivi. Inoltre, nella fase di sizing, in entrambi i data center deve essere prevista non solo una capacit\u00e0 doppia (necessaria per memorizzare i dati contemporaneamente su due storage), ma anche una doppia performance in IOPS e MB\/s, per evitare degrado delle applicazioni in caso di guasto di uno dei data center.<\/p>\n<p><\/p>\n<p>Vale la pena notare che con un approccio adeguato al sizing (ossia, a condizione che abbiamo previsto adeguati limiti superiori per IOPS e MB\/s, cos\u00ec come le risorse necessarie di CPU e RAM) in caso di guasto di uno degli storage nel metrocluster non ci sar\u00e0 un significativo calo delle performance durante la temporanea operativit\u00e0 su uno storage.<\/p>\n<p><\/p>\n<p>Questo \u00e8 dovuto al fatto che nelle condizioni di funzionamento simultaneo di due piattaforme, la replica sincrona 'consuma' met\u00e0 delle performance in scrittura, poich\u00e9 ogni transazione deve essere registrata su entrambi gli storage (analogamente a RAID-1\/10). Pertanto, in caso di guasto di uno degli storage, l'influenza della replica scompare temporaneamente (fino al ripristino dello storage guasto), e otteniamo un raddoppio delle performance in scrittura. Dopo che i LUN dello storage guasto sono stati riavviati su quello funzionante, questo raddoppio delle performance svanisce a causa del carico proveniente dai LUN dell'altro storage, e torniamo allo stesso livello di performance che avevamo prima del 'guasto', ma solo all'interno di una singola piattaforma. <\/p>\n<p><\/p>\n<p>Grazie a un sizing accurato, \u00e8 possibile creare condizioni in cui gli utenti non percepiranno affatto il fallimento di un'intera SAN. Ma ripetiamo, ci\u00f2 richiede un sizing molto attento, al quale, per inciso, potete rivolgervi gratuitamente a noi :-).<\/p>\n<p><\/p>\n<h2 id=\"nastroyka-metroklastera\">Configurazione del metrocluster<\/h2>\n<p><\/p>\n<p>La configurazione di un metrocluster \u00e8 molto simile alla configurazione di una replica normale, che abbiamo descritto in <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/aerodisk\/blog\/456348\/\">articolo precedente<\/a><\/noindex>. Pertanto, ci concentreremo solo sulle differenze. Abbiamo impostato un ambiente di laboratorio basato sull'architettura sopra, ma in un formato minimo: due SAN collegate tra loro tramite Ethernet 10G, due switch 10G e un host che accede a entrambe le SAN tramite porte 10G. L'arbitro funziona su una macchina virtuale.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster\" src=\"\/wp-content\/uploads\/2019\/07\/04e318609929553ed651fd702f0c7327.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Quando si impostano gli IP virtuali (VIP) per la replica, \u00e8 necessario scegliere il tipo di VIP \u2013 per il metrocluster.<\/p>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/ym\/aw\/89\/ymaw89gofhplngagm5nvveg4oe0.png\"><img decoding=\"async\" alt=\"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster\" src=\"\/wp-content\/uploads\/2019\/07\/974acf7aad3244c48049d09ff9b99a52.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p><\/p>\n<p>Abbiamo creato due connessioni di replica per due LUN e le abbiamo distribuite su due SAN: LUN TEST Primary su SAN1 (connessione METRO), LUN TEST2 Primary per SAN2 (connessione METRO2).<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster\" src=\"\/wp-content\/uploads\/2019\/07\/7ff6c2bcf23bfa48974ba3ae5538e424.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Per questi abbiamo configurato due target identici (nel nostro caso iSCSI, ma \u00e8 supportato anche FC, la logica di configurazione \u00e8 la stessa).<\/p>\n<p><\/p>\n<p>SAN1:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster\" src=\"\/wp-content\/uploads\/2019\/07\/e8378f8a65ea7886d9bf0b97b76394c4.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>SAN2:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster\" src=\"\/wp-content\/uploads\/2019\/07\/dee6c339ff0b15ec24f8d2d19d874921.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Per le connessioni di replica sono stati creati mapping su ciascuna SAN.<\/p>\n<p><\/p>\n<p>SAN1:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster\" src=\"\/wp-content\/uploads\/2019\/07\/c71dcc46058731acb7fdf44a2ae52f56.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>SAN2:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster\" src=\"\/wp-content\/uploads\/2019\/07\/f473a0862ccb11d55ff1b1f13d5db87e.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Abbiamo configurato il multipath e lo abbiamo presentato all'host.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster\" src=\"\/wp-content\/uploads\/2019\/07\/e3eea3967f75388cf5bd5aeb8ec4f5df.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster\" src=\"\/wp-content\/uploads\/2019\/07\/20ce2c6f94a1ec507704b2adabe7f7fa.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<h3 id=\"nastraivaem-arbitra\">Configurare l'arbitro<\/h3>\n<p><\/p>\n<p>Non \u00e8 necessario fare molto con l'arbitro stesso, basta accenderlo nel terzo sito, assegnargli un IP e configurare l'accesso tramite ICMP e SSH. La configurazione stessa viene effettuata dalle SAN. Inoltre, la configurazione dell'arbitro deve essere eseguita una sola volta su uno qualsiasi dei controller della SAN nel metrocluster; queste impostazioni verranno propagate automaticamente a tutti i controller.<\/p>\n<p><\/p>\n<p>Nella sezione Replica remota&gt;&gt; Metrocluster (su qualsiasi controller)&gt;&gt; pulsante 'Configura'.<\/p>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/sy\/h0\/x-\/syh0x-gywrz2yu8w9mk0us5mwcg.jpeg\"><img decoding=\"async\" alt=\"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster\" src=\"\/wp-content\/uploads\/2019\/07\/c83c1dd267dcbe0203af23e2f10772c4.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p><\/p>\n<p>Inseriamo l'IP dell'arbitro e le interfacce di gestione dei due controller della SAN remota.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster\" src=\"\/wp-content\/uploads\/2019\/07\/760f6f703f5f0eef1072c4c6ca393089.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Dopo di ci\u00f2, \u00e8 necessario avviare tutti i servizi (pulsante 'Riavvia tutto'). In caso di riconfigurazione in futuro, \u00e8 fondamentale riavviare i servizi affinch\u00e9 le impostazioni abbiano effetto.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster\" src=\"\/wp-content\/uploads\/2019\/07\/ad25df4a17879bcddb45480368c51095.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Controlliamo che tutti i servizi siano attivi.<\/p>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/oh\/mw\/xl\/ohmwxl5jry0dufgfamey0ddxris.jpeg\"><img decoding=\"async\" alt=\"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster\" src=\"\/wp-content\/uploads\/2019\/07\/15b658834b7682c6cc3b76882ad9e4ab.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p><\/p>\n<p><strong>A questo punto, la configurazione del metrocluster \u00e8 completata.<\/strong><\/p>\n<p><\/p>\n<h2 id=\"krash-test\">Crash test<\/h2>\n<p><\/p>\n<p>Il crash test nel nostro caso sar\u00e0 abbastanza semplice e veloce, poich\u00e9 la funzionalit\u00e0 di replica (failover, consistenza, ecc.) \u00e8 stata trattata in <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/aerodisk\/blog\/456348\/\">un articolo precedente<\/a><\/noindex>. Pertanto, per testare l'affidabilit\u00e0 del metrocluster, \u00e8 sufficiente verificare l'automazione del rilevamento dei guasti, il passaggio e l'assenza di perdite durante la scrittura (interruzioni dell'input\/output). <\/p>\n<p><\/p>\n<p>Per questo emuliamo un guasto completo di uno dei sistemi di archiviazione, spegnendo fisicamente entrambi i suoi controller, avviando in precedenza il trasferimento di un grande file su un LUN, che deve attivarsi su un altro sistema di archiviazione.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster\" src=\"\/wp-content\/uploads\/2019\/07\/b1b108313472a03983bc1b8690c70369.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Disconnettiamo un sistema di archiviazione. Sul secondo sistema vediamo avvisi e messaggi nei log riguardo la perdita di connessione con il sistema adiacente. Se le notifiche sono impostate tramite SMTP o monitoraggio SNMP, l'amministratore ricever\u00e0 le comunicazioni pertinenti.<\/p>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/ae\/jo\/xv\/aejoxv6piwk4fvl-nc1leklbxce.jpeg\"><img decoding=\"async\" alt=\"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster\" src=\"\/wp-content\/uploads\/2019\/07\/9af3728eec93cc2e17048ec596748cb1.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p><\/p>\n<p>Esattamente dopo 10 secondi (visibile in entrambi gli screenshot) la connessione di replica METRO (quella che era primaria sul sistema di archiviazione guasto) \u00e8 diventata automaticamente primaria sul sistema di archiviazione attivo. Utilizzando il mapping esistente, il LUN TEST \u00e8 rimasto accessibile all'host, la scrittura ha subito una leggera diminuzione (nel limite del 10% promesso), ma non si \u00e8 interrotta. <\/p>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/v_\/gj\/d9\/v_gjd9sgoi5hwrgjdkwxwtdomeu.jpeg\"><img decoding=\"async\" alt=\"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster\" src=\"\/wp-content\/uploads\/2019\/07\/e0131eb534ed10f1ac64a19d42d0b53f.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Motore AERODISK: Resilienza ai disastri. Parte 2. Metrocluster\" src=\"\/wp-content\/uploads\/2019\/07\/644da1a8b2de75637b58094f549d4de0.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p><strong>Il test \u00e8 stato completato con successo.<\/strong><\/p>\n<p><\/p>\n<h2 id=\"podvodim-itog\">Riassumiamo<\/h2>\n<p><\/p>\n<p>L'attuale implementazione del metrocluster nei sistemi di archiviazione della serie N di AERODISK Engine consente di affrontare pienamente compiti in cui \u00e8 necessario ridurre o minimizzare i tempi di inattivit\u00e0 dei servizi IT e garantire il loro funzionamento in modalit\u00e0 24\/7\/365 con il minimo sforzo. <\/p>\n<p><\/p>\n<p>Si pu\u00f2 certamente dire che tutto questo \u00e8 teoria, condizioni di laboratorio ideali e cos\u00ec via... MA abbiamo una serie di progetti realizzati in cui abbiamo implementato funzionalit\u00e0 di resilienza ai disastri, e i sistemi funzionano egregiamente. Uno dei nostri clienti abbastanza noti, in cui sono utilizzati proprio due sistemi di archiviazione in configurazione resiliente ai disastri, ha gi\u00e0 dato il consenso per la pubblicazione delle informazioni sul progetto, quindi nella prossima parte parleremo dell'implementazione in campo.<\/p>\n<p><\/p>\n<p>Grazie, attendiamo una discussione produttiva.<\/p>\n<p>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/aerodisk\/blog\/460305\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u0432\u0435\u0442, \u0447\u0438\u0442\u0430\u0442\u0435\u043b\u0438 \u0425\u0430\u0431\u0440\u0430! \u0412 \u043f\u0440\u043e\u0448\u043b\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043c\u044b \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u043b\u0438 \u043e \u043f\u0440\u043e\u0441\u0442\u043e\u043c \u0441\u0440\u0435\u0434\u0441\u0442\u0432\u0435 \u043a\u0430\u0442\u0430\u0441\u0442\u0440\u043e\u0444\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u0438 \u0432 \u0441\u0438\u0441\u0442\u0435\u043c\u0430\u0445 \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f AERODISK ENGINE \u2013 \u043e \u0440\u0435\u043f\u043b\u0438\u043a\u0430\u0446\u0438\u0438. \u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043c\u044b \u043f\u043e\u0433\u0440\u0443\u0437\u0438\u043c\u0441\u044f \u0432 \u0431\u043e\u043b\u0435\u0435 \u0441\u043b\u043e\u0436\u043d\u0443\u044e \u0438 \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u0443\u044e \u0442\u0435\u043c\u0443 \u2013 \u043c\u0435\u0442\u0440\u043e\u043a\u043b\u0430\u0441\u0442\u0435\u0440, \u0442\u043e \u0435\u0441\u0442\u044c \u0441\u0440\u0435\u0434\u0441\u0442\u0432\u043e \u0430\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0437\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u043e\u0439 \u0437\u0430\u0449\u0438\u0442\u044b \u043e\u0442 \u043a\u0430\u0442\u0430\u0441\u0442\u0440\u043e\u0444 \u0434\u043b\u044f \u0434\u0432\u0443\u0445 \u0426\u041e\u0414-\u043e\u0432, \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u044e\u0449\u0435\u0435 \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c \u0426\u041e\u0414-\u0430\u043c \u0432 \u0440\u0435\u0436\u0438\u043c\u0435 active-active. \u0420\u0430\u0441\u0441\u043a\u0430\u0436\u0435\u043c, \u043f\u043e\u043a\u0430\u0436\u0435\u043c, \u0441\u043b\u043e\u043c\u0430\u0435\u043c \u0438 \u043f\u043e\u0447\u0438\u043d\u0438\u043c. \u041a\u0430\u043a [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":27126,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-36263","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/aerodisk-engine-katastrofoustojchivost-chast-2-metroklaster\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"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\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47AERODISK Engine: \u041a\u0430\u0442\u0430\u0441\u0442\u0440\u043e\u0444\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u044c. \u0427\u0430\u0441\u0442\u044c 2. \u041c\u0435\u0442\u0440\u043e\u043a\u043b\u0430\u0441\u0442\u0435\u0440 | ProHoster\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/aerodisk-engine-katastrofoustojchivost-chast-2-metroklaster\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:10:35+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:10:35+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47AERODISK Engine: Resilienza ai disastri. Parte 2. Metrocluster | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/aerodisk-engine-katastrofoustojchivost-chast-2-metroklaster","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\udd47AERODISK Engine: \u041a\u0430\u0442\u0430\u0441\u0442\u0440\u043e\u0444\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u044c. \u0427\u0430\u0441\u0442\u044c 2. \u041c\u0435\u0442\u0440\u043e\u043a\u043b\u0430\u0441\u0442\u0435\u0440 | ProHoster","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/aerodisk-engine-katastrofoustojchivost-chast-2-metroklaster","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:10:35+00:00","article:modified_time":"2019-10-31T19:10:35+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"36263","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 02:36:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:47:35","updated":"2026-01-22 02:36:19","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\/36263","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=36263"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/36263\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/27126"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=36263"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=36263"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=36263"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}