\nIl processore Kunpeng rappresenta un sistema su chip (SoC), dove oltre all'unit\u00e0 di calcolo sono presenti moduli hardware che accelerano vari processi, ad esempio il calcolo delle checksum o l'esecuzione del \"codice di cancellazione\" (erasure coding). Esso stesso implementa il supporto hardware per SAS, Ethernet, DDR4 (da sei a otto canali) e cos\u00ec via. Tutto questo consente a Huawei di creare controller di storage che non sono inferiori alle soluzioni classiche Intel in termini di prestazioni. <\/p>\n
Inoltre, le soluzioni proprietarie basate sull'architettura ARM consentono a Huawei di creare soluzioni server complete e offrirle ai propri clienti come alternativa all'x86.<\/p>\n
\nL'architettura interna dello storage Dorado V6 della serie superiore \u00e8 rappresentata da quattro sottodomini principali (fabbriche). <\/p>\n
La prima fabbrica \u00e8 un front-end comune (interfacce di rete, responsabili della comunicazione con la fabbrica SAN o con gli host). <\/p>\n
La seconda \u00e8 un insieme di controller, ciascuno dei quali pu\u00f2 tramite il protocollo RDMA \"raggiungere\" sia una qualsiasi scheda di rete del front-end che il \"motore\" (engine) adiacente, rappresentato da una scatola contenente quattro controller, insieme a blocchi di alimentazione e raffreddamento comuni. Attualmente, i modelli Dorado V6 di classe hi-end possono essere dotati di due di questi \"motori\" (otto controller in totale).<\/p>\n
La terza fabbrica si occupa del backend ed \u00e8 composta da schede di rete RDMA da 100G.<\/p>\n
Infine, la quarta fabbrica \"in hardware\" \u00e8 rappresentata da scaffali intelligenti modulari con unit\u00e0 di archiviazione.<\/p>\n
Questa struttura simmetrica svela tutto il potenziale della tecnologia NVMe e garantisce elevate prestazioni e affidabilit\u00e0. Il processo di input-output \u00e8 massimamente parallelizzato attraverso processori e core, consentendo lettura e scrittura simultanee su pi\u00f9 flussi.<\/p>\n
\nLe prestazioni massime delle soluzioni Dorado V6 superano di circa tre volte i risultati dei sistemi di generazione precedente (nella stessa categoria) e possono raggiungere 20 milioni di IOPS. <\/p>\n
Questo \u00e8 dovuto al fatto che nel precedente generatore di dispositivi il supporto NVMe era limitato solo a scaffali decorativi con unit\u00e0 di archiviazione. Ora, invece, \u00e8 presente in tutte le fasi, dall'host agli SSD. Anche la rete backend ha subito modifiche: SAS\/PCIe hanno fatto posto a RoCEv2 con una larghezza di banda di 100 Gbps. <\/p>\n
\u00c8 cambiata anche la forma fisica degli SSD. Se prima un'unit\u00e0 2U ospitava 25 unit\u00e0, ora \u00e8 stata aumentata a 36 dischi di formato palm-sized. Inoltre, gli scaffali sono diventati \"intelligenti\". Ognuno di essi ora dispone di un sistema di tolleranza ai guasti composto da due controller basati su chip ARM, simili a quelli installati nei controller centrali. <\/p>\n
La compressione e la deduplicazione nella soluzione di storage precedente venivano eseguite con blocchi di lunghezza fissa. Ora \u00e8 stata aggiunta una modalit\u00e0 di funzionamento con blocchi di lunghezza variabile, che deve essere attivata forzatamente. I firmware successivi potrebbero modificare questa situazione.<\/p>\n
Brevemente sulla tolleranza ai guasti. Dorado V3 manteneva la funzionalit\u00e0 se uno dei due controller falliva. Dorado V6 garantir\u00e0 l'affidabilit\u00e0 dei dati anche nel caso in cui sette controller su otto smettano di funzionare consecutivamente o quattro dello stesso \"motore\" simultaneamente.<\/p>\n
\nRecentemente, tra i clienti di Huawei \u00e8 stata condotta un'indagine su quali elementi semplici dell'infrastruttura IT l'azienda consideri accettabile. La maggior parte dei rispondenti ha reagito in modo tollerante a una situazione ipotetica in cui un'applicazione non risponde per centinaia di secondi. Per il sistema operativo o l'adattatore host del bus, il tempo critico di inattivit\u00e0 \u00e8 risultato essere di decine di secondi (praticamente, il tempo di riavvio). I clienti pongono requisiti ancora pi\u00f9 elevati alla rete: la sua larghezza di banda non deve bloccarsi per pi\u00f9 di 10\u201320 secondi. Come \u00e8 facile immaginare, i guasti dei sistemi di storage sono stati ritenuti dai partecipanti pi\u00f9 critici. Dal punto di vista dei rappresentanti del business, il funzionamento inattivo di uno storage array non deve eccedere\u2026 pochi secondi all'anno!<\/p>\n
In altre parole, se l'applicazione client della banca non risponde per 100 secondi, probabilmente non causer\u00e0 conseguenze disastrose. Ma se lo stesso accade a uno storage array, \u00e8 probabile che si verifichino fermi operativi e significative perdite finanziarie.<\/p>\n
Nel grafico sopra sono riportati i costi orari di funzionamento per dieci delle maggiori banche (dati Forbes del 2017). Concordate, se la vostra azienda si avvicina in dimensioni alle banche cinesi, giustificare la necessit\u00e0 di acquisire uno storage array per diversi milioni di dollari non sar\u00e0 poi cos\u00ec difficile. Vale anche l'affermazione opposta: se l'azienda non subisce perdite significative durante il fermo, \u00e8 improbabile che acquisti uno storage array di fascia alta. In ogni caso, \u00e8 importante avere un'idea della dimensione del buco che potrebbe formarsi nel vostro portafoglio mentre l'amministratore di sistema si occupa del sistema di storage guasto.<\/p><\/blockquote>\n
Secondo per il failover<\/h2>\n \nNella Soluzione A nell'illustrazione sopra, \u00e8 possibile vedere il nostro sistema di precedente generazione Dorado V3. Quattro dei suoi controller lavorano a coppie, e le copie della cache sono contenute solo in due controller. I controller all'interno della coppia possono ridistribuire il carico. Nel frattempo, come potete vedere, qui non ci sono \"fabriche\" frontend e backend, quindi ciascuno scaffale di dischi \u00e8 collegato a una specifica coppia di controller.<\/p>\n
Nello schema Solution B \u00e8 mostrata la soluzione attualmente disponibile sul mercato di un altro fornitore (l'avete riconosciuta?). Qui ci sono gi\u00e0 sia fabbriche front-end che back-end, e i raccoglitori si connettono direttamente a quattro controller. Tuttavia, ci sono delle sfumature nei funzionamenti interni degli algoritmi del sistema che non sono evidenti a prima vista.<\/p>\n
A destra \u00e8 presentata la nostra architettura attuale dello storage Dorado V6 con l'intero insieme di elementi interni. Esaminiamo come questi sistemi affrontano una situazione tipica: il guasto di un controller.<\/p>\n
Nei sistemi classici, tra cui il Dorado V3, il tempo necessario per ridistribuire il carico in caso di guasto arriva fino a quattro secondi. Durante questo periodo, le operazioni di input-output si fermano completamente. Nella soluzione Solution B dei nostri colleghi, nonostante un'architettura pi\u00f9 moderna, il tempo di inattivit\u00e0 in caso di guasto \u00e8 addirittura superiore: sei secondi.<\/p>\n
Lo storage Dorado V6 ripristina il suo funzionamento in appena un secondo dopo un guasto. Questo risultato si ottiene grazie a un ambiente interno RDMA uniforme, che consente al controller di accedere alla memoria 'estranea'. Un secondo aspetto importante \u00e8 la presenza della fabbrica front-end, che mantiene invariato il percorso per l'host. La porta rimane la stessa e il carico viene semplicemente inviato ai controller funzionanti tramite driver di multipassing.<\/p>\n
Il guasto del secondo controller nel Dorado V6 viene gestito in un secondo secondo lo stesso schema. Per il Dorado V3 questo richiede circa sei secondi, mentre per la soluzione di un altro fornitore \u2014 nove. Per molti DBMS tali intervalli non possono pi\u00f9 essere considerati accettabili, poich\u00e9 in quel tempo il sistema passa in modalit\u00e0 standby e smette di funzionare. Questo \u00e8 particolarmente rilevante per i DBMS composti da molte partizioni.<\/p>\n
Il guasto del terzo controller Solution A non pu\u00f2 essere gestito. Proprio per il fatto che si perde l'accesso a parte dei dischi contenenti dati. Al contrario, la soluzione B in questa situazione ripristina la funzionalit\u00e0, richiedendo, come nel caso precedente, nove secondi.<\/p>\n
E per il Dorado V6? Un secondo.<\/p>\n
Cosa si riesce a fare in un secondo<\/h2>\n \nQuasi nulla, ma non ne abbiamo bisogno. Ribadiamo che in Dorado V6 di classe hi-end, la fabbrica del frontend \u00e8 disaccoppiata dalla fabbrica dei controller. Ci\u00f2 significa che non ci sono porte rigidamente assegnate a un controller specifico. La ricostruzione in caso di guasto non implica la ricerca di percorsi alternativi o la re-inizializzazione del multipassaggio. Il sistema continua a funzionare come prima.<\/p>\n
Resistenza a molteplici guasti<\/h2>\n \nI modelli superiori di Dorado V6 sopportano senza problemi il guasto simultaneo di due qualsiasi (!) controller all'interno di qualsiasi \"motore\". Questo \u00e8 stato reso possibile dal fatto che ora la soluzione conserva tre copie della cache. Pertanto, anche in caso di guasto doppio, ci sar\u00e0 sempre una copia integra.<\/p>\n
Il guasto sincronizzato di tutti e quattro i controller in uno dei \"motori\" non avr\u00e0 conseguenze fatali, poich\u00e9 tutte e tre le copie della cache sono distribuite tra i \"motori\" in ogni momento. La stessa sistema sorveglia il rispetto di tale logica operativa.<\/p>\n
Infine, uno scenario altamente improbabile \u00e8 il guasto sequenziale di sette controller su otto. Inoltre, l'intervallo minimo consentito per mantenere la funzionalit\u00e0 tra i singoli guasti \u00e8 di 15 minuti. In questo tempo, l'archiviazione riesce a completare le operazioni necessarie per la migrazione della cache.<\/p>\n
L'ultimo controller rimasto garantir\u00e0 il funzionamento dello storage e manterr\u00e0 la cache per cinque giorni (valore predefinito, facilmente modificabile nelle impostazioni). Dopo di che, la cache sar\u00e0 disattivata, ma il funzionamento della storage continuer\u00e0.<\/p>\n
Aggiornamenti non disturbanti<\/h2>\n \nIl nuovo sistema operativo Dorado V6 consente di aggiornare il firmware della storage senza riavviare i controller.<\/p>\n
Il sistema operativo, come nel caso delle soluzioni precedenti, \u00e8 basato su Linux, tuttavia molti processi operativi sono stati trasferiti dal nucleo alla modalit\u00e0 utente. La maggior parte delle funzioni, come quelle responsabili della deduplica e della compressione, ora sono normali demoni che operano in background. Grazie a ci\u00f2, non \u00e8 necessario cambiare l'intero sistema operativo per aggiornare singoli moduli. Ad esempio, per aggiungere il supporto per un nuovo protocollo sar\u00e0 sufficiente disattivare il modulo software corrispondente e attivare il nuovo.<\/p>\n
\u00c8 chiaro che le questioni relative all'aggiornamento del sistema rimangono, poich\u00e9 ci possono essere elementi nel kernel che necessitano di essere aggiornati. Tuttavia, secondo le nostre osservazioni, tali elementi rappresentano meno del 6% del numero totale. Ci\u00f2 consente di riavviare i controller molte meno volte rispetto al passato.<\/p>\n
Soluzioni resistenti ai disastri e soluzioni ad alta disponibilit\u00e0 (HA\/DR)<\/h2>\n \nDorado V6 \u00e8 pronta per l'integrazione in soluzioni geodistribuite, cluster di livello urbano (metro) e data center \"tripli\".<\/p>\n
A sinistra nell'illustrazione sopra si vede un metro-cluster gi\u00e0 noto a molti. Due sistemi di archiviazione dati operano in modalit\u00e0 attiva\/attiva a una distanza fino a 100 km l'uno dall'altro. Tale infrastruttura, con uno o pi\u00f9 server di quorum, pu\u00f2 essere supportata da soluzioni di diverse aziende, compresa la nostra piattaforma cloud FusionSphere. In progetti del genere, la qualit\u00e0 della connessione tra i siti diventa particolarmente importante; tutte le altre funzioni sono gestite dalla funzione HyperMetro, disponibile, ancora una volta, \"out of the box\". L'integrazione pu\u00f2 avvenire tramite Fibre Channel, cos\u00ec come tramite iSCSI nelle reti IP, se necessario. Non \u00e8 pi\u00f9 necessario avere la fibra ottica \"scura\" dedicata, poich\u00e9 il sistema \u00e8 in grado di collegarsi attraverso i canali esistenti.<\/p>\n
Nella costruzione di tali sistemi, l'unico requisito hardware per i sistemi di archiviazione dati \u00e8 la dedicazione di porte per la replica. \u00c8 sufficiente acquistare una licenza, lanciare server di quorum - fisici o virtuali - e garantire la connettivit\u00e0 IP ai controller (10 Mbit\/s, 50 ms).<\/p>\n
Questa architettura pu\u00f2 essere facilmente trasferita a un sistema con tre data center (vedi la parte destra dell'illustrazione). Ad esempio, quando due data center operano in modalit\u00e0 metro-cluster e un terzo sito, situato a oltre 100 km, utilizza replica asincrona.<\/p>\n
Il sistema supporta tecnologicamente diversi scenari aziendali che saranno attuati in caso di un'elevata emergenza.<\/p>\n
Sopravvivenza del metro-cluster in caso di pi\u00f9 guasti<\/h2>\n \nSopra e sotto \u00e8 mostrato anche un metro-cluster classico, composto da due sistemi di archiviazione dati e un server di quorum. Come puoi vedere, in sei dei nove possibili scenari di guasti multipli, la nostra infrastruttura manterr\u00e0 la funzionalit\u00e0.<\/p>\n
Ad esempio, nello scenario due, in caso di guasto del server quorum e sincronizzazione tra i siti, il sistema rimane produttivo, poich\u00e9 il secondo sito smette di funzionare. Comportamenti simili sono gi\u00e0 incorporati negli algoritmi integrati.<\/p>\n
Anche dopo tre guasti, l'accesso alle informazioni pu\u00f2 essere mantenuto, se l'intervallo tra essi \u00e8 stato di almeno 15 secondi.<\/p>\n
Il classico asso nella manica<\/h2>\n \nRicordiamo che Huawei produce non solo sistemi di archiviazione, ma anche un'ampia gamma di attrezzature di rete. Qualunque fornitore di sistemi di archiviazione tu scelga, se tra i siti viene utilizzata una rete WDM, nel 90% dei casi sar\u00e0 costruita su soluzioni della nostra azienda. Si pone quindi una domanda legittima: perch\u00e9 raccogliere un parco di sistemi, quando tutta l'attrezzatura compatibile garantita pu\u00f2 essere ottenuta da un unico fornitore?<\/p>\n
A proposito di prestazioni<\/h2>\n \nProbabilmente, non c'\u00e8 pi\u00f9 bisogno di convincere nessuno che il passaggio ai sistemi di archiviazione All-Flash consente di ridurre significativamente i costi di mantenimento dell'infrastruttura, poich\u00e9 tutte le operazioni di routine vengono eseguite molte volte pi\u00f9 velocemente. Tutti i fornitori di tale attrezzatura ne danno testimonianza. Tuttavia, molti fornitori iniziano a mentire quando si tratta dell'abbassamento delle prestazioni durante l'attivazione di varie modalit\u00e0 operative dei sistemi di archiviazione.<\/p>\n
Nel nostro settore \u00e8 comune fornire sistemi di archiviazione in prova per uno o due giorni. Il fornitore esegue un test di 20 minuti su un sistema vuoto, ottenendo risultati di prestazioni straordinari. Ma nell'uso reale emergono rapidamente le \"insidie nascoste\". Gi\u00e0 dopo un giorno, i valori di IOPS belli scendono di due o tre volte, e se il sistema di archiviazione viene riempito all'80%, risultano anche inferiori. Attivando RAID 5 invece di RAID 10 si perdono ulteriori 10-15%, e in modalit\u00e0 metro-cluster le prestazioni si dimezzano ulteriormente.<\/p>\n
Tutto ci\u00f2 che \u00e8 stato elencato sopra non riguarda Dorado V6. I nostri clienti hanno la possibilit\u00e0 di avviare un test di prestazioni nei fine settimana o almeno di notte. Allora si manifesta la raccolta dei rifiuti, e diventa chiaro come l'attivazione di varie opzioni \u2014 come snapshot e replica \u2014 influisca sui valori di IOPS raggiungibili.<\/p>\n
In Dorado V6, gli snapshot e RAID con parit\u00e0 influenzano praticamente poco le prestazioni (3\u20135% invece di 10-15%). La raccolta dei rifiuti (riempimento delle celle del dispositivo con zeri), compressione, deduplicazione su storage SCS, riempito all'80%, avranno sempre un impatto sulla velocit\u00e0 complessiva di elaborazione delle richieste. Ma ci\u00f2 che rende Dorado V6 interessante \u00e8 che, qualunque combinazione di funzioni e meccanismi di protezione attivi, la prestazione finale dello storage SCS non scender\u00e0 mai sotto l'80% del valore ottenuto senza carico.<\/p>\n
Il bilanciamento del carico<\/h2>\n \nL'alta prestazione di Dorado V6 \u00e8 raggiunta grazie al bilanciamento in ogni fase, e precisamente a:<\/p>\n
\nmulti-passaggio;<\/li>\n utilizzo di pi\u00f9 connessioni da un singolo host;<\/li>\n presenza di un front-end factory;<\/li>\n parallelizzazione del lavoro dei controller SCS;<\/li>\n distribuzione del carico su tutti i dispositivi a livello RAID 2.0+.<\/li>\n<\/ul>\n\nIn linea di principio, questa \u00e8 una pratica comune. Al giorno d'oggi, pochi mantengono tutti i dati su un unico LUN: tutti cercano di averne almeno otto, quaranta o anche di pi\u00f9. \u00c8 un approccio ovvio e corretto, che condividiamo. Ma se il tuo compito richiede solo un LUN, pi\u00f9 facile da gestire, le nostre soluzioni architetturali consentono di raggiungere su di esso prestazioni dell'80% di quelle disponibili utilizzando pi\u00f9 LUN.<\/p>\n
Pianificazione dinamica del carico sui processori<\/h2>\n \nLa distribuzione del carico sui processori utilizzando un singolo LUN \u00e8 realizzata nel seguente modo: i compiti sono suddivisi gi\u00e0 a livello LUN in piccoli 'shard', ognuno dei quali \u00e8 rigidamente assegnato a un controller specifico nel 'motore'. Questo \u00e8 fatto per garantire che il sistema non perda prestazioni mentre 'salta' con questo pezzo di dati su diversi controller. <\/p>\n
Un altro meccanismo per mantenere alte prestazioni \u00e8 il dynamic scheduling, dove alcuni core del processore possono essere assegnati a diversi pool di compiti. Ad esempio, se il sistema \u00e8 attualmente inattivo nella deduplicazione e compressione, alcuni core possono attivarsi nel processo di gestione dell'input-output. O viceversa. Tutto questo avviene automaticamente e in modo trasparente per l'utente. <\/p>\n
I dati sul carico attuale di ciascun core del Dorado V6 non vengono visualizzati nell'interfaccia grafica, ma tramite la linea di comando \u00e8 possibile accedere al sistema operativo del controller e utilizzare un comando Linux normale. top<\/i>.<\/p>\n
Supporto NVMe e RoCE<\/h2>\n \nCome gi\u00e0 accennato, al momento attuale Dorado V6 supporta completamente NVMe over Fibre Channel \"out of the box\" e non richiede alcuna licenza. Entro la met\u00e0 dell'anno verr\u00e0 aggiunto il supporto per la modalit\u00e0 NVMe over Ethernet. Per un utilizzo completo sar\u00e0 necessaria una rete Ethernet con accesso diretto alla memoria (DMA) versione v2.0 sia da parte dell'array di storage che da parte di switch e adattatori di rete. Ad esempio, come Mellanox ConnectX-4 o ConnectX-5. \u00c8 possibile utilizzare anche schede di rete basate sui nostri chip. Inoltre, il supporto RoCE deve essere implementato a livello di sistema operativo.<\/p>\n
In generale, riteniamo che Dorado V6 sia un sistema orientato a NVMe. Nonostante il supporto per Fibre Channel e iSCSI, in futuro \u00e8 previsto un passaggio a Ethernet ad alta velocit\u00e0 con RDMA.<\/p><\/blockquote>\n
Un pizzico di marketing<\/h2>\n \nGrazie al fatto che il sistema Dorado V6 possiede un'elevata resilienza ai guasti, si scala bene orizzontalmente e supporta varie tecnologie di migrazione, l'effetto economico del suo acquisto si manifesta con l'inizio di un'intensa operativit\u00e0 dell'array di storage. Continueremo a fare del nostro meglio per rendere il possesso del sistema il pi\u00f9 vantaggioso possibile, anche se nella fase iniziale questo non \u00e8 immediatamente evidente.<\/p>\n
In particolare, abbiamo sviluppato il programma FLASH EVER, che si occupa di estendere il ciclo di vita dell'array di storage e mira a quanto pi\u00f9 possibile ridurre il carico per il cliente durante gli aggiornamenti.<\/p>\n
\nla possibilit\u00e0 di sostituire gradualmente i controller e i rack con dischi con nuove versioni senza dover sostituire completamente l'attrezzatura (per i sistemi Dorado V6 di classe hi-end);<\/li>\n la possibilit\u00e0 di storage federativo (unione di diverse versioni di Dorado all'interno di un singolo cluster ibrido di array di storage);<\/li>\n virtualizzazione intelligente (possibilit\u00e0 di utilizzare attrezzature di terze parti come parte della soluzione Dorado).<\/li>\n<\/ul>\n\n
Oltre a tutto, a causa della pandemia, per quanto possa durare, la questione dell'approvvigionamento di postazioni di lavoro virtuali per i dipendenti remoti diventa particolarmente urgente. In questo processo, Dorado V6 potrebbe anche risolvere molte questioni. Per questo motivo, stiamo facendo tutti gli sforzi necessari, incluso aver praticamente concordato l'inclusione del nuovo sistema nella lista di compatibilit\u00e0 VMware.<\/p>\n
***<\/h2>\n \nA proposito, non dimenticate i nostri numerosi webinar, che si tengono non solo nel segmento di lingua russa, ma anche a livello globale. L'elenco dei webinar di aprile \u00e8 disponibile su link<\/a><\/noindex>. habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u041f\u043e\u0436\u0430\u043b\u0443\u0439\u0441\u0442\u0430, \u043d\u0435 \u0441\u043f\u0435\u0448\u0438\u0442\u0435 \u0441 \u0432\u044b\u0432\u043e\u0434\u0430\u043c\u0438 \u0438\u0437-\u0437\u0430 \u0437\u0430\u0433\u043e\u043b\u043e\u0432\u043a\u0430! \u0423 \u043d\u0430\u0441 \u0435\u0441\u0442\u044c \u0443\u0432\u0435\u0441\u0438\u0441\u0442\u044b\u0435 \u0430\u0440\u0433\u0443\u043c\u0435\u043d\u0442\u044b \u0432 \u0435\u0433\u043e \u043f\u043e\u0434\u0442\u0432\u0435\u0440\u0436\u0434\u0435\u043d\u0438\u0435, \u0438 \u043c\u044b \u0443\u043f\u0430\u043a\u043e\u0432\u0430\u043b\u0438 \u0438\u0445, \u043d\u0430\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043c\u043e\u0433\u043b\u0438 \u043a\u043e\u043c\u043f\u0430\u043a\u0442\u043d\u043e. \u041f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u0435\u043c \u0432\u0430\u0448\u0435\u043c\u0443 \u0432\u043d\u0438\u043c\u0430\u043d\u0438\u044e \u043f\u043e\u0441\u0442 \u043e \u043a\u043e\u043d\u0446\u0435\u043f\u0446\u0438\u0438 \u0438 \u043f\u0440\u0438\u043d\u0446\u0438\u043f\u0430\u0445 \u0440\u0430\u0431\u043e\u0442\u044b \u043d\u0430\u0448\u0435\u0439 \u043d\u043e\u0432\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f \u0434\u0430\u043d\u043d\u044b\u0445, \u0440\u0435\u043b\u0438\u0437 \u043a\u043e\u0442\u043e\u0440\u043e\u0439 \u0441\u043e\u0441\u0442\u043e\u044f\u043b\u0441\u044f \u0432 \u044f\u043d\u0432\u0430\u0440\u0435 2020 \u0433\u043e\u0434\u0430. \u041f\u043e \u043d\u0430\u0448\u0435\u043c\u0443 \u0443\u0431\u0435\u0436\u0434\u0435\u043d\u0438\u044e, \u0433\u043b\u0430\u0432\u043d\u043e\u0435 \u043a\u043e\u043d\u043a\u0443\u0440\u0435\u043d\u0442\u043d\u043e\u0435 \u043f\u0440\u0435\u0438\u043c\u0443\u0449\u0435\u0441\u0442\u0432\u043e \u0441\u0435\u043c\u0435\u0439\u0441\u0442\u0432\u0443 \u0421\u0425\u0414 Dorado V6 \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0438\u0432\u0430\u044e\u0442 \u0438\u043c\u0435\u043d\u043d\u043e […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":79692,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-79691","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Perch\u00e9](\"\/wp-content\/uploads\/2020\/04\/36c949c0c7099441a62597353bd084a6.png\")