\nThe Kunpeng processor represents a system on a chip (SoC), where alongside the computational block, there are hardware modules that accelerate various processes such as checksum calculations or performing erasure coding. It also features hardware support for SAS, Ethernet, DDR4 (ranging from six to eight channels), and more. This allows Huawei to create storage controllers that match the performance of classic Intel solutions. <\/p>\n
Additionally, its own solutions based on ARM architecture give Huawei the ability to create complete server solutions and offer them to clients as an alternative to x86.<\/p>\n
\nThe internal architecture of the Dorado V6 storage system's upper series is represented by four main subdomains (factories). <\/p>\n
The first factory serves as a common frontend (network interfaces responsible for communication with the SAN factory or hosts). <\/p>\n
The second factory consists of a set of controllers, each of which can connect via the RDMA protocol to any network card of the frontend and to the adjacent 'engine', which is a box containing four controllers, along with shared power supply and cooling units. Currently, high-end Dorado V6 models can be equipped with two such 'engines' (thus, eight controllers).<\/p>\n
Den tredje fabrik st\u00e5r for backend og best\u00e5r af RDMA 100G netv\u00e6rkskort.<\/p>\n
Endelig er den fjerde fabrik \"i hardwaren\" repr\u00e6senteret ved tilsluttede intelligente hylder med lagringsenheder.<\/p>\n
En s\u00e5dan symmetrisk struktur afsl\u00f8rer det fulde potentiale af NVMe-teknologien og sikrer h\u00f8j ydeevne og p\u00e5lidelighed. Ind- og uddata-processer maksimeres parallelt p\u00e5 processorer og kerner, hvilket g\u00f8r det muligt at l\u00e6se og skrive p\u00e5 mange str\u00f8mme samtidig.<\/p>\n
\nDen maksimale ydeevne for Dorado V6-l\u00f8sningerne overg\u00e5r cirka tre gange resultaterne fra forg\u00e6ngernes systemer (i samme klasse) og kan n\u00e5 op p\u00e5 20 millioner IOPS. <\/p>\n
Dette skyldes, at i det tidligere generations udstyr var NVMe-underst\u00f8ttelse begr\u00e6nset til tilsluttede hylder med lagringsenheder. Nu er der underst\u00f8ttelse p\u00e5 alle niveauer, fra v\u00e6rt til SSD. Backend-netv\u00e6rket har ogs\u00e5 gennemg\u00e5et \u00e6ndringer: SAS\/PCIe er blevet erstattet af RoCEv2 med en b\u00e5ndbredde p\u00e5 100 Gbit\/s. <\/p>\n
SSD-formfaktoren har ogs\u00e5 \u00e6ndret sig. Hvis der tidligere var 25 lagringsdrev i en 2U-hylde, er den nu blevet opgraderet til 36 enheder af palm-sized fysisk format. Desuden er hylderne blevet \"smartere\". Hver hylde har nu et fejltolerant system med to controllere baseret p\u00e5 ARM-chips, som ligner dem, der er installeret i centrale controllere. <\/p>\n
Kompression og deduplicering i det forrige generations SAN blev udf\u00f8rt med faste blokke. Nu er der ogs\u00e5 tilf\u00f8jet en tilstand for variabel l\u00e6ngde blokke, som i \u00f8jeblikket skal aktiveres manuelt. Efterf\u00f8lgende firmwares vil muligvis \u00e6ndre dette.<\/p>\n
Ogs\u00e5 kort om fejltolerance. Dorado V3 bevarede funktionalitet, hvis \u00e9n controller ud af to svigtede. Dorado V6 vil sikre data tilg\u00e6ngelighed, selvom op til syv controllere ud af otte fejler sekventielt eller fire fejler samtidigt i \u00e9t \"motor\".<\/p>\n
\nFor nylig blev der blandt kunderne hos Huawei foretaget en unders\u00f8gelse om, hvilken nedetid for enkelte elementer i IT-infrastrukturen virksomheden finder acceptabel. Generelt havde respondenterne en rimelig tolerance over for den hypotetiske situation, hvor en applikation ikke reagerer i flere hundrede sekunder. For operativsystemer eller bus-adaptere var kritisk nedetid i sekunder (faktisk genstartstid). Endnu h\u00f8jere krav stiller kunderne til netv\u00e6rket: dets b\u00e5ndbredde m\u00e5 ikke falde i mere end 10\u201320 sekunder. Som man kunne forvente, betragter respondenterne svigt i lagringssystemer som de mest kritiske. Fra forretningsrepr\u00e6sentanters synspunkt b\u00f8r nedetid for SAN ikke overstige... et par sekunder om \u00e5ret!<\/p>\n
Med andre ord, hvis en klients banksystem ikke reagerer i 100 sekunder, vil det sandsynligvis ikke have katastrofale konsekvenser. Men hvis et SAN ikke fungerer i samme tidsrum, kan det resultere i forretningsstop og betydelige \u00f8konomiske tab.<\/p>\n
Diagrammet ovenfor viser omkostningerne for en times nedetid for de ti st\u00f8rste banker (data fra Forbes 2017). Hvis din virksomhed n\u00e6rmer sig st\u00f8rrelsen p\u00e5 de kinesiske banker, vil det ikke v\u00e6re sv\u00e6rt at retf\u00e6rdigg\u00f8re behovet for at investere flere millioner dollar i et SAN. Omvendt g\u00e6lder det, at hvis enhver nedetid for virksomheden ikke medf\u00f8rer v\u00e6sentlige tab, vil de n\u00e6ppe investere i et hi-end SAN. Under alle omst\u00e6ndigheder er det vigtigt at have en id\u00e9 om, hvor stort et hul der kan opst\u00e5 i din pengepung, mens systemadministratoren ordner det svigtende lagringssystem.<\/p><\/blockquote>\n
Sekund til n\u00f8dskift<\/h2>\n \nI Solution A p\u00e5 illustrationen ovenfor kan du se vores tidligere generations system Dorado V3. Dets fire controllere arbejder parvis, og cachekopierne opbevares kun i to controllere. Controllerene inden for et par kan omfordele belastningen. Samtidig, som du kan se, er der ingen \"fabrikker\" for frontend og backend, s\u00e5 hver hylde med lagringsenheder er tilsluttet et specifikt controllerpar.<\/p>\n
Diagrammet for Solution B viser en l\u00f8sning, der i \u00f8jeblikket er tilg\u00e6ngelig p\u00e5 markedet fra en anden leverand\u00f8r (kendte du det?). Her er der allerede front-end og back-end fabrikker, og lagermedierne forbindes direkte til fire controllere. Faktisk er der dog nogle mindre \u00e5benlyse nuancer i, hvordan systemets interne algoritmer fungerer.<\/p>\n
Til h\u00f8jre pr\u00e6senteres vores nuv\u00e6rende arkitektur for Dorado V6 storage systemet med et komplet s\u00e6t af interne elementer. Lad os se, hvordan disse systemer h\u00e5ndterer en typisk situation \u2014 fejlen p\u00e5 en controller.<\/p>\n
I klassiske systemer, som Dorado V3 tilh\u00f8rer, kan den tid, der kr\u00e6ves for at omfordele belastningen ved fejl, n\u00e5 op p\u00e5 fire sekunder. I l\u00f8bet af denne tid stopper input-output helt. I Solution B fra vores kolleger, p\u00e5 trods af en mere moderne arkitektur, er nedetid ved fejl endnu l\u00e6ngere \u2014 seks sekunder.<\/p>\n
Dorado V6 gendanner sin funktion efter blot \u00e9n sekund ved en fejl. Dette resultat opn\u00e5s takket v\u00e6re en homogen intern RDMA-milj\u00f8, der g\u00f8r det muligt for controllere at f\u00e5 adgang til 'fremmed' hukommelse. En anden vigtig faktor er tilstedev\u00e6relsen af en front-end fabrik, som sikrer, at stien for v\u00e6rten forbliver u\u00e6ndret. Porten forbliver den samme, og belastningen sendes blot til de fungerende controllere via multipassing drivere.<\/p>\n
Fejlen p\u00e5 den anden controller i Dorado V6 h\u00e5ndteres p\u00e5 samme m\u00e5de indenfor \u00e9n sekund. For Dorado V3 tager dette cirka seks sekunder, mens det for en anden leverand\u00f8rs l\u00f8sning tager ni. For mange databasesystemer kan s\u00e5danne intervaller ikke l\u00e6ngere betragtes som acceptable, da systemet i denne tid overg\u00e5r til standby-tilstand og stopper med at fungere. Dette g\u00e6lder is\u00e6r for databasesystemer, der best\u00e5r af mange partitioner.<\/p>\n
Fejlen p\u00e5 den tredje controller i Solution A kan ikke overholdes. Dette skyldes ganske enkelt, at adgangen til en del af datadiskene forsvinder. P\u00e5 den anden side gendanner Solution B funktionaliteten i en s\u00e5dan situation, hvilket tager som i det foreg\u00e5ende tilf\u00e6lde ni sekunder.<\/p>\n
Hvad med Dorado V6? \u00c9n sekund.<\/p>\n
Hvad kan man opn\u00e5 p\u00e5 en sekund?<\/h2>\n \nN\u00e6sten ingenting, men vi har heller ikke brug for det. Lad os gentage, at i Dorado V6 i hi-end klassen er frontend-fabrikken adskilt fra controllerfabrikken. Det betyder, at der ikke er h\u00e5rdt tildelte porte, der tilh\u00f8rer en specifik controller. Oml\u00e6gning ved fejl indeb\u00e6rer ikke s\u00f8gning efter alternative ruter eller geninitialisering af multipass. Systemet forts\u00e6tter med at fungere som f\u00f8r.<\/p>\n
Modstandsdygtighed over for mange fejl<\/h2>\n \nDe \u00e6ldre modeller af Dorado V6 kan uden problemer overleve et samtidigt nedbrud af to vilk\u00e5rlige (!) controllere inden for enhver \"motor\". Dette er blevet muligt, fordi l\u00f8sningen nu gemmer tre kopier af cachen. Derfor findes der altid en intakt kopi, selv ved dobbeltfejl.<\/p>\n
Synkronisering af nedbrud af alle fire controllere i en af \"motorerne\" vil heller ikke medf\u00f8re fatale konsekvenser, da alle tre kopier af cachen p\u00e5 ethvert tidspunkt er fordelt mellem \"motorerne\". Systemet overv\u00e5ger overholdelsen af denne logik.<\/p>\n
Endelig er et scenarie, hvor syv controllere ud af otte g\u00e5r ned i r\u00e6kkef\u00f8lge, n\u00e6sten usandsynligt. Den minimale tilladte tidsintervaller mellem individuelle nedbrud er 15 minutter. I l\u00f8bet af denne tid f\u00e5r lagersystemet udf\u00f8rt de n\u00f8dvendige operationer til at migrere cachen.<\/p>\n
Den sidste fungerende controller vil sikre drift af datalageret og opretholde cachen i fem dage (standardv\u00e6rdi, som nemt kan \u00e6ndres i indstillingerne). Efter dette vil cachen blive deaktiveret, men lagersystemets drift vil forts\u00e6tte.<\/p>\n
Ubesv\u00e6ret opdateringer<\/h2>\n \nDet nye OS Dorado V6 tillader opdatering af fastwaren i lagersystemet uden genstart af controllerne.<\/p>\n
Operativsystemet, ligesom i tilf\u00e6lde med tidligere l\u00f8sninger, er baseret p\u00e5 Linux, men mange af de operationelle processer er flyttet fra kernen til brugermodulet. De fleste funktioner, s\u00e5som dem der er ansvarlige for deduplikering og kompression, er nu almindelige d\u00e6moner, der k\u00f8rer i baggrunden. Takket v\u00e6re dette er det ikke n\u00f8dvendigt at \u00e6ndre hele operativsystemet for at opdatere individuelle moduler. For eksempel vil der kun v\u00e6re behov for at slukke for det relevante softwaremodul og starte det nye for at tilf\u00f8je support til en ny protokol.<\/p>\n
Det er tydeligt, at sp\u00f8rgsm\u00e5l om opdatering af systemet stadig eksisterer, da der ogs\u00e5 kan v\u00e6re elementer i kernen, der kr\u00e6ver opdatering. Men if\u00f8lge vores observationer er der mindre end 6 % af det samlede antal. Dette g\u00f8r det muligt at genstarte controllere mange gange sj\u00e6ldnere end f\u00f8r.<\/p>\n
Katastrofe-resistente l\u00f8sninger og h\u00f8j tilg\u00e6ngelighedsl\u00f8sninger (HA\/DR)<\/h2>\n \nDorado V6 er 'out of the box' klar til integration i geo-spredte l\u00f8sninger, metro-klynger og 'triple' datacentre.<\/p>\n
Til venstre p\u00e5 illustrationerne ovenfor er den allerede velkendte metro-klynge. To SAN'er arbejder i aktiv\/aktiv tilstand p\u00e5 afstande op til 100 km fra hinanden. En s\u00e5dan infrastruktur med en eller flere kvorumservere kan underst\u00f8ttes af l\u00f8sninger fra forskellige virksomheder, inklusive vores cloud-operativsystem FusionSphere. Kanalernes egenskaber mellem placeringerne f\u00e5r s\u00e6rlig betydning i s\u00e5danne projekter. I vores tilf\u00e6lde varetager HyperMetro-funktionen, som igen er 'out of the box'. Integration er mulig via Fibre Channel samt iSCSI i IP-netv\u00e6rk, hvis behovet opst\u00e5r. Det er ikke l\u00e6ngere n\u00f8dvendigt med dedikeret 'dark' fiber, da systemet kan oprette forbindelse via eksisterende kanaler.<\/p>\n
N\u00e5r s\u00e5danne systemer opbygges, er det eneste hardwarekrav til SAN'en at frigive porte til replikation. Det er tilstr\u00e6kkeligt at k\u00f8be en licens, starte kvorumservere \u2014 fysiske eller virtuelle \u2014 og sikre IP-forbindelse til controllere (10 Mbit\/s, 50 ms).<\/p>\n
Denne arkitektur kan let overf\u00f8res til et system med tre datacentre (se h\u00f8jre side af illustrationen). For eksempel, n\u00e5r to datacentre arbejder i metro-klynge-tilstand, mens den tredje placering, der ligger mere end 100 km v\u00e6k, bruger asynkron replikation.<\/p>\n
Systemet underst\u00f8tter teknologisk forskellige forretningsscenarier, der vil blive implementeret i tilf\u00e6lde af en omfattende h\u00e6ndelse.<\/p>\n
Overlevelse af metro-klyngen ved flere fejlfunktioner<\/h2>\n \nOvenfor og nedenfor er der ogs\u00e5 vist en klassisk metro-klynge, best\u00e5ende af to SAN'er og en kvorumserver. Som du kan se, vil vores infrastruktur bevare sin funktionalitet i seks ud af ni mulige scenarier med flere fejlfunktioner.<\/p>\n
For example, in the second scenario, when the quorum server fails and synchronization between sites occurs, the system remains functional, as the second site stops working. This behavior is already embedded in the built-in algorithms.<\/p>\n
Even after three failures, access to information can be retained if the interval between them was at least 15 seconds.<\/p>\n
A familiar trump card up the sleeve<\/h2>\n \nRecall that Huawei manufactures not only storage systems but also a complete range of network equipment. Whatever storage provider you choose, if a WDM network is used between the sites, in 90% of cases it will be based on solutions from our company. A reasonable question arises: why assemble a zoo of systems when all guaranteed compatible hardware can be obtained from one vendor?<\/p>\n
On the topic of performance<\/h2>\n \nProbably, no one needs convincing that switching to All-Flash storage systems significantly reduces the costs of maintaining infrastructure, as all routine operations are performed much faster. All suppliers of such equipment testify to this. Meanwhile, many vendors begin to gloss over things when it comes to performance drops when different operating modes of storage systems are enabled.<\/p>\n
In our industry, it is common practice to issue storage systems for test operation for one or two days. The supplier runs a 20-minute test on an empty system, obtaining astronomical performance figures. However, in real operation, hidden pitfalls quickly surface. After just one day, the beautiful IOPS values drop to half or a third, and if the storage system is filled to 80%, they become even lower. Enabling RAID 5 instead of RAID 10 incurs an additional 10-15% loss, and in metro-cluster mode, performance is halved again.<\/p>\n
Everything mentioned above does not apply to Dorado V6. Our customers have the opportunity to run a performance test over the weekend or at least overnight. This reveals garbage collection behavior, as well as how the activation of various options \u2014 like snapshots and replication \u2014 affects the achieved IOPS.<\/p>\n
I Dorado V6 p\u00e5virker snapshots og RAID med paritet n\u00e6sten ikke ydeevnen (3\u20135 % i stedet for 10-15 %). Affaldssamling (udfyldning af lagerskaber med nuller), komprimering, deduplication p\u00e5 et SAN, der er fyldt op til 80 %, vil altid p\u00e5virke den samlede foresp\u00f8rgselsbehandlingstid. Men det, der g\u00f8r Dorado V6 interessant, er, at uanset hvilken kombination af funktioner og beskyttelsesmekanismer du aktiverer, vil den endelige ydeevne af SAN ikke falde under 80 % af det niveau, der opn\u00e5s uden belastning.<\/p>\n
Load Balancing<\/h2>\n \nDen h\u00f8je ydeevne af Dorado V6 opn\u00e5s gennem belastningsbalancering p\u00e5 hvert trin, nemlig:<\/p>\n
\nmulti-passing;<\/li>\n brug af flere forbindelser fra \u00e9n v\u00e6rt;<\/li>\n tilstedev\u00e6relse af en frontend-fabrik;<\/li>\n parallelisering af controllerenes arbejde i SAN;<\/li>\n fordeling af belastningen p\u00e5 alle lagringsenheder p\u00e5 RAID-niveau 2.0+.<\/li>\n<\/ul>\n\nI princippet er dette en almindelig praksis. I dag er der f\u00e5, der opbevarer alle data p\u00e5 \u00e9n LUN: alle str\u00e6ber efter at have otte, fyrre, eller endda flere. Dette er en \u00e5benlys og korrekt tilgang, som vi deler. Men hvis dit behov kun kr\u00e6ver \u00e9n LUN, der er lettere at vedligeholde, tillader vores arkitektoniske l\u00f8sninger at opn\u00e5 en ydeevne p\u00e5 80 % af det, der er tilg\u00e6ngeligt ved brug af flere LUN.<\/p>\n
Dynamisk planl\u00e6gning af belastningen af processorerne<\/h2>\n \nBelastningsfordelingen p\u00e5 processorerne ved brug af \u00e9n LUN implementeres p\u00e5 f\u00f8lgende m\u00e5de: opgaver opdeles allerede p\u00e5 LUN-niveau i separate sm\u00e5 'sharder', hvor hver af dem er strengt knyttet til en specifik controller i 'motoren'. Dette g\u00f8res for at sikre, at systemet ikke mister ydeevne, mens det 'hopper' med denne databit gennem forskellige controllere. <\/p>\n
Endnu en mekanisme til at bevare h\u00f8j ydeevne er dynamisk scheduling, hvor forskellige processorkerner kan tildeles forskellige opgavepuljer. For eksempel, hvis systemet lige nu er inaktivt p\u00e5 niveauet for deduplication og komprimering, kan nogle kerner g\u00e5 ind i processen for dataind- og -udgang. Eller omvendt. Alt dette sker automatisk og er gennemsigtigt for brugeren. <\/p>\n
Oplysninger om den nuv\u00e6rende belastning p\u00e5 hver af kernerne i Dorado V6 vises ikke i det grafiske interface, men man kan tilg\u00e5 controllerens OS via kommandolinjen og bruge den almindelige Linux-kommando top<\/i>.<\/p>\n
Underst\u00f8ttelse af NVMe og RoCE<\/h2>\n \nSom n\u00e6vnt underst\u00f8tter Dorado V6 i \u00f8jeblikket NVMe over Fibre Channel \"out of the box\" og kr\u00e6ver ingen licenser. I midten af \u00e5ret vil der komme underst\u00f8ttelse af NVMe over Ethernet. For at kunne bruge dette fuldt ud er der brug for Ethernet med direkte hukommelsestilgang (DMA) version v2.0, b\u00e5de fra selve SAN'en og fra switche og netv\u00e6rksadaptere. For eksempel s\u00e5danne som Mellanox ConnectX-4 eller ConnectX-5. Man kan ogs\u00e5 bruge netv\u00e6rkskort baseret p\u00e5 vores chips. Derudover skal underst\u00f8ttelsen af RoCE implementeres p\u00e5 operativsystemniveau.<\/p>\n
Generelt betragter vi Dorado V6 som et NVMe-orienteret system. P\u00e5 trods af den eksisterende st\u00f8tte til Fibre Channel og iSCSI planl\u00e6gges der i fremtiden at overg\u00e5 til h\u00f8jhastigheds Ethernet med RDMA.<\/p><\/blockquote>\n
En smule marketing<\/h2>\n \nTakket v\u00e6re den h\u00f8je fejltolerance i Dorado V6-systemet, dets gode horisontale skalering og underst\u00f8ttelse af forskellige migrationsmetoder, realiserer den \u00f8konomiske gevinst ved at anskaffe systemet sig tydeligt, s\u00e5 snart intensiv brug af SAN'en begynder. Vi vil forts\u00e6tte med at g\u00f8re ejerskabet af systemet s\u00e5 \u00f8konomisk fordelagtigt som muligt, selvom dette ikke er \u00e5benlyst i starten.<\/p>\n
Specifikt har vi skabt programmet FLASH EVER, relateret til forl\u00e6ngelse af livscyklussen for SAN'en, som er designet til at lette byrden for kunden, n\u00e5r der udf\u00f8res opgraderinger.<\/p>\n
\nmulighed for gradvis udskiftning af controllere og diskhylder med nye versioner uden at skulle udskifte hele udstyret (for Dorado V6-systemer i hi-end klassen);<\/li>\n mulighed for federativ lagring (sammenl\u00e6gning af forskellige versioner af Dorado i et hybrid SAN-kluster);<\/li>\n intelligent virtualisering (mulighed for at bruge tredjepartsudstyr som en del af Dorado-l\u00f8sningen).<\/li>\n<\/ul>\n\n
Derudover, i forbindelse med pandemien, uanset hvor lang tid den m\u00e5tte vare, bliver sp\u00f8rgsm\u00e5let om at forsyne remote medarbejdere med virtuelle arbejdspladser s\u00e6rligt presserende. I denne proces kunne Dorado V6 ogs\u00e5 afhj\u00e6lpe mange problemstillinger. Vi g\u00f8r alle n\u00f8dvendige bestr\u00e6belser for dette, herunder n\u00e6sten at have aftalt at inkludere det nye system i VMware's kompatibilitetsliste.<\/p>\n
***<\/h2>\n \nOg glem ikke vores mange webinarer, der ikke kun afholdes i det russisktalende segment, men ogs\u00e5 p\u00e5 globalt niveau. Listen over webinarer for april er tilg\u00e6ngelig p\u00e5 linket<\/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
![\"Hvorfor](\"\/wp-content\/uploads\/2020\/04\/36c949c0c7099441a62597353bd084a6.png\")