AERODISK ENGINE N2 պահեստավորման համակարգի վթարի թեստեր, ամրության թեստ

Բարեւ բոլորին! Այս հոդվածով AERODISK-ը բլոգ է բացում Habré-ում: Ուռա՛, ընկերնե՛ր։

Habré-ի նախորդ հոդվածները քննարկել են պահեստավորման համակարգերի ճարտարապետության և հիմնական կազմաձևման վերաբերյալ հարցեր: Այս հոդվածում մենք կքննարկենք մի հարց, որը նախկինում չի լուսաբանվել, բայց հաճախ տրվել է՝ AERODISK ENGINE պահեստավորման համակարգերի անսարքության հանդուրժողականության մասին: Մեր թիմը կանի ամեն ինչ, որպեսզի AERODISK պահեստավորման համակարգը դադարի աշխատել, այսինքն. կոտրել այն:

Այնպես եղավ, որ Habré-ում արդեն կախված են մեր ընկերության պատմության, մեր արտադրանքի մասին հոդվածներ, ինչպես նաև հաջող իրականացման օրինակ, որի համար Շատ շնորհակալություն մեր գործընկերներին՝ TS Solution և Softline ընկերություններին:

Հետևաբար, ես այստեղ չեմ պատրաստի copy-paste կառավարման հմտություններ, այլ պարզապես հղումներ կտամ այս հոդվածների բնօրինակներին.

• Հոդված թիվ 1. Ընկերության պատմության և AERODISK ENGINE պահեստավորման համակարգի ճարտարապետության մասին
• Հոդված թիվ 2. Ինչպես արագ կարգավորել AERODISK ENGINE պահեստավորման համակարգը
• Հոդված թիվ 3. Հետաքրքիր նախագիծ 2018 թվականի ՖԻՖԱ-ի Աշխարհի գավաթի համար լայնածավալ տեսահսկման իրականացման մասին՝ որպես «Ապահով քաղաք» նախագծի մաս

Ուզում եմ նաև կիսվել լավ նորություններով. Բայց ես կսկսեմ, իհարկե, խնդրից. Մենք՝ որպես երիտասարդ վաճառող, ի թիվս այլ ծախսերի, մշտապես բախվում ենք այն փաստի հետ, որ շատ ինժեներներ և ադմինիստրատորներ պարզապես չգիտեն, թե ինչպես ճիշտ գործարկել մեր պահեստավորման համակարգը:
Պարզ է, որ պահեստավորման համակարգերի մեծ մասի կառավարումը ադմինիստրատորի տեսանկյունից մոտավորապես նույնն է թվում, բայց յուրաքանչյուր արտադրող ունի իր առանձնահատկությունները: Եվ մենք այստեղ բացառություն չենք:

Ուստի ՏՏ ոլորտի մասնագետների պատրաստման խնդիրը պարզեցնելու նպատակով որոշեցինք այս տարին նվիրել անվճար կրթությանը։ Դա անելու համար Ռուսաստանի շատ խոշոր քաղաքներում մենք բացում ենք AERODISK կոմպետենցիայի կենտրոնների ցանց, որտեղ ցանկացած հետաքրքրված տեխնիկական մասնագետ կարող է բացարձակապես անվճար դասընթաց անցնել և ստանալ AERODISK ENGINE պահեստավորման համակարգերի կառավարման վկայական:

Յուրաքանչյուր իրավասության կենտրոնում մենք կտեղադրենք AERODISK պահեստավորման համակարգից լիարժեք ցուցադրական ստենդ և ֆիզիկական սերվեր, որի վրա մեր ուսուցիչը կանցկացնի դեմ առ դեմ ուսուցում: Իրավասությունների կենտրոնների աշխատանքի ժամանակացույցը կհրապարակենք նրանց հայտնվելուն պես, սակայն Նիժնի Նովգորոդում արդեն կենտրոն ենք բացել, և հաջորդը Կրասնոդարն է։ Դուք կարող եք գրանցվել վերապատրաստման համար՝ օգտագործելով ստորև նշված հղումները: Ահա քաղաքների և ամսաթվերի մասին ներկայումս հայտնի տեղեկությունները.

• Նիժնի Նովգորոդ (ԱՐԴԵՆ ԲԱՑ Է. կարող եք գրանցվել այստեղ https://aerodisk.promo/nn/);
  Մինչև 16 թվականի ապրիլի 2019-ը կենտրոն կարող եք այցելել ցանկացած աշխատանքային ժամի, իսկ 16 թվականի ապրիլի 2019-ին կկազմակերպվի վերապատրաստման մեծ դասընթաց։
• Krasnodar (ԲԱՑՈՒՄԸ ՇՈՒՏՈՎ - կարող եք գրանցվել այստեղ https://aerodisk.promo/krsnd/ );
  9 թվականի ապրիլի 25-ից 2019-ը կենտրոն կարող եք այցելել ցանկացած աշխատանքային ժամի, իսկ 25 թվականի ապրիլի 2019-ին կկազմակերպվի վերապատրաստման մեծ դասընթաց։
• Ekaterinburg (ԲԱՑՈՒՄԸ ՇՈՒՏՈՎ, հետևեք մեր կայքի կամ Habré-ի տեղեկատվությանը);
  մայիս-հունիս 2019թ.
• Новосибирск (հետևեք մեր կայքի կամ Habré-ի տեղեկատվությանը);
  Հոկտեմբեր 2019.
• Krasnoyarsk (հետևեք մեր կայքի կամ Habré-ի տեղեկատվությանը);
  2019 թվականի նոյեմբեր

Եվ, իհարկե, եթե Մոսկվան ձեզնից հեռու չէ, ապա ցանկացած պահի կարող եք այցելել մեր գրասենյակ Մոսկվայում և անցնել նմանատիպ դասընթացներ:

Բոլորը. Մենք ավարտեցինք մարքեթինգը, եկեք անցնենք տեխնոլոգիային:

Habré-ում մենք պարբերաբար կհրապարակենք տեխնիկական հոդվածներ մեր արտադրանքի, բեռնվածության թեստերի, համեմատությունների, օգտագործման առանձնահատկությունների և հետաքրքիր իրականացումների մասին:

AERODISK ENGINE N2 պահեստավորման համակարգի վթարի թեստեր, ամրության թեստ

ԶԳՈՒՇԱՑՈՒՄ! Հոդվածը կարդալուց հետո կարող եք ասել. Դե, իհարկե, վաճառողն ինքն իրեն կստուգի, որպեսզի ամեն ինչ աշխատի «թափով», ջերմոցային պայմաններ և այլն: Ես կպատասխանեմ՝ ոչ մի նման բան։ Ի տարբերություն մեր արտասահմանյան մրցակիցների, մենք գտնվում ենք այստեղ՝ ձեզ մոտ, և դուք միշտ կարող եք գալ մեզ մոտ (Մոսկվայում կամ ցանկացած Կենտրոնական կոմիտե) և ցանկացած ձևով փորձարկել մեր պահեստավորման համակարգը։ Այսպիսով, մեզ համար այնքան էլ իմաստ չունի արդյունքները հարմարեցնել աշխարհի իդեալական պատկերին, քանի որ Մենք շատ հեշտ է ստուգել. Նրանց համար, ովքեր շատ ծույլ են գնալ և ժամանակ չունեն, մենք կարող ենք կազմակերպել հեռահար փորձարկում: Մենք դրա համար հատուկ լաբորատորիա ունենք: Կապվեք մեզ հետ:

ԱՉՏՈՒՆԳ-2! Այս թեստը ծանրաբեռնվածության թեստ չէ, քանի որ այստեղ մենք միայն մտածում ենք սխալների հանդուրժողականության մասին: Մի քանի շաբաթից մենք կպատրաստենք ավելի հզոր ստենդ և կանցկացնենք պահեստավորման համակարգի բեռնվածության փորձարկում՝ արդյունքները հրապարակելով այստեղ (ի դեպ, թեստերի հարցումներն ընդունվում են)։

Այսպիսով, եկեք կոտրենք այն:

Փորձարկման տակդիր

Մեր ստենդը բաղկացած է հետևյալ սարքավորումներից.

• 1 x Aerodisk Engine N2 պահեստավորման համակարգ (2 կարգավորիչ, 64 ԳԲ քեշ, 8xFC պորտ 8 Գբ/վ, 4xEthernet պորտ 10Գբ/վ SFP+, 4xEthernet պորտ 1Գբ/վ); Պահպանման համակարգում տեղադրված են հետևյալ սկավառակները.
• 4 x SAS SSD սկավառակ 900 ԳԲ;
• 12 x SAS 10k սկավառակ 1,2 TB;
• 1 x Ֆիզիկական սերվեր Windows Server 2016-ով (2xXeon E5 2667 v3, 96 ԳԲ RAM, 2xFC պորտ 8 Գբ/վ, 2xEthernet պորտ 10 Գբ/վ SFP+);
• 2 x SAN 8G անջատիչ;
• 2 x LAN 10G անջատիչ;

Մենք սերվերը միացրել ենք պահեստավորման համակարգին անջատիչների միջոցով և՛ FC, և՛ 10G Ethernet-ի միջոցով: Ստենդի դիագրամը ստորև է:

Մեզ անհրաժեշտ բաղադրիչները, ինչպիսիք են MPIO-ն և iSCSI նախաձեռնիչը, տեղադրված են Windows Server-ում:
Գոտիները կազմաձևված են FC անջատիչների վրա, համապատասխան VLAN-ները կազմաձևված են LAN անջատիչների վրա, իսկ MTU 9000-ը տեղադրված է պահեստավորման պորտերի, անջատիչների և հոսթի վրա (ինչպես անել այս ամենը նկարագրված է մեր փաստաթղթերում, այնպես որ մենք չենք նկարագրելու այս գործընթացը այստեղ):

Փորձարկման մեթոդիկա

Վթարի փորձարկման պլանը հետևյալն է.

• FC և Ethernet պորտերի ձախողման ստուգում:
• Էլեկտրաէներգիայի ձախողման ստուգում.
• Վերահսկիչի ձախողման ստուգում:
• Խմբում/ավազանում սկավառակի ձախողման ստուգում:

Բոլոր փորձարկումները կկատարվեն սինթետիկ բեռնվածության պայմաններում, որոնք մենք կստեղծենք IOMETER ծրագրի միջոցով: Զուգահեռաբար մենք կկատարենք նույն թեստերը, բայց մեծ ֆայլերը պահեստավորման համակարգում պատճենելու պայմաններում։

IOmeter-ի կազմաձևը հետևյալն է.

• Կարդալ/գրել – 70/30
• Բլոկ – 128k (մենք որոշեցինք լվանալ պահեստավորման համակարգերը մեծ բլոկներով)
• Թելերի քանակը – 128 (որը շատ նման է արտադրողական բեռին)
• Ամբողջական պատահական
• Աշխատողների թիվը – 4 (2 FC-ի համար, 2-ը iSCSI-ի համար)

Թեստն ունի հետևյալ նպատակները.

1. Համոզվեք, որ սինթետիկ բեռնման և պատճենման գործընթացը չի ընդհատի կամ սխալներ չի առաջացնի ձախողման տարբեր սցենարների դեպքում:
2. Համոզվեք, որ պորտերի, կարգավորիչների և այլնի փոխարկման գործընթացը բավականաչափ ավտոմատացված է և չի պահանջում ադմինիստրատորի գործողություններ խափանումների դեպքում (այսինքն՝ failover-ների ժամանակ, իհարկե, failback-ների մասին չէ խոսքը)։
3. Համոզվեք, որ տեղեկամատյաններում տեղեկատվությունը ճիշտ է ցուցադրվում:

Հոսթի և պահեստավորման համակարգի պատրաստում

Մենք կարգավորեցինք պահեստային համակարգի արգելափակման հասանելիությունը՝ օգտագործելով FC և Ethernet պորտերը (համապատասխանաբար, FC և iSCSI): TS Solution-ի տղաները մանրամասն նկարագրել են, թե ինչպես դա անել նախորդ հոդվածում (https://habr.com/ru/company/tssolution/blog/432876/) Եվ, իհարկե, ոչ ոք չեղարկեց ձեռնարկներն ու դասընթացները։

Մենք ստեղծել ենք հիբրիդային խումբ՝ օգտագործելով մեր ունեցած բոլոր սկավառակները: 2 SSD սկավառակ ավելացվել է քեշին, 2 SSD սկավառակ՝ որպես լրացուցիչ պահեստային մակարդակ (Online-tier): Մենք խմբավորեցինք 12 SAS10k սկավառակ RAID-60P-ի մեջ (եռակի հավասարություն), որպեսզի ստուգենք խմբում միանգամից երեք կրիչի ձախողումը: Մեկ սկավառակ է մնացել ինքնափոխարինման համար։

Մենք միացրինք երկու LUN (մեկը FC-ի միջոցով, մեկը՝ iSCSI-ի միջոցով):

Երկու LUN-երի սեփականատերը Engine-0 կարգավորիչն է

Սկսենք թեստը

Մենք միացնում ենք IOMETER-ը վերը նշված կոնֆիգուրով:

Մենք գրանցում ենք թողունակությունը 1.8 Գբ/վ և ուշացում՝ 3 միլիվայրկյան: Սխալներ չկան (Total Error Count):

Միևնույն ժամանակ, մեր հոսթի տեղական «C» սկավառակից մենք զուգահեռաբար սկսում ենք պատճենել երկու մեծ 100 ԳԲ ֆայլ FC և iSCSI պահեստավորման LUN-ներում (Windows-ում E և G կրիչներ)՝ օգտագործելով այլ ինտերֆեյսներ:

Վերևում պատկերված է պատճենման գործընթացը LUN FC-ում, ներքևում՝ iSCSI:

Թեստ թիվ 1. անջատել I/O պորտերը

Մենք մոտենում ենք պահեստավորման համակարգին հետևից))) և ձեռքի մի փոքր շարժումով Engine-10 կարգավորիչից հանում ենք բոլոր FC և Ethernet 0G մալուխները։ Կարծես շվաբրով հավաքարարուհին անցավ և որոշեց լվանալ հատակը հենց այնտեղ, որտեղ ընկած էր ծակ ու մալուխները (այսինքն՝ կարգավորիչը դեռ աշխատում է, բայց I/O պորտերը մեռած են):

Եկեք նայենք IOMETER-ին և ֆայլերի պատճենմանը: Թողունակությունը իջավ մինչև 0,5 ԳԲ/վ, բայց արագ վերադարձավ իր նախկին մակարդակին (մոտ 4-5 վայրկյանում): Սխալներ չկան։

Ֆայլերի պատճենումը չի դադարել, արագության անկում կա, բայց դա բոլորովին կրիտիկական չէ (840 ՄԲ/վ-ից իջել է մինչև 720 ՄԲ/վ): Կրկնօրինակումը չի դադարել։

Մենք նայում ենք պահեստավորման համակարգի տեղեկամատյաններին և տեսնում հաղորդագրություն նավահանգիստների անհասանելիության և խմբի ավտոմատ տեղափոխման մասին:

Տեղեկատվական վահանակը նաև մեզ ասում է, որ FC նավահանգիստների հետ ամեն ինչ այնքան էլ լավ չէ:

Պահպանման համակարգը փրկվել է I/O պորտերի ձախողումից հաջողությամբ։

Թեստ թիվ 2. Պահպանման կարգավորիչի անջատում

Գրեթե անմիջապես (մալուխները պահեստավորման համակարգին նորից միացնելուց հետո) մենք որոշեցինք ավարտել պահեստավորման համակարգը՝ կարգավորիչը շասսիից դուրս քաշելով:

Կրկին մոտենում ենք պահեստավորման համակարգին հետևից (մեզ դուր եկավ))) և այս անգամ դուրս ենք քաշում Engine-1 կարգավորիչը, որն այս պահին RDG-ի սեփականատերն է (որին տեղափոխվեց խումբը):

IOmeter-ում իրավիճակը հետևյալն է. I/O-ն դադարեց մոտ 5 վայրկյան: Սխալները չեն կուտակվում։

5 վայրկյանից հետո I/O-ն վերսկսվեց մոտավորապես նույն թողունակությամբ, բայց 35 միլիվայրկյան լատենտներով (շեղումները շտկվեցին մոտ մի քանի րոպե հետո): Ինչպես երևում է սքրինշոթերից, ընդհանուր սխալների քանակի արժեքը 0 է, այսինքն՝ գրելու կամ կարդալու սխալներ չեն եղել:

Եկեք նայենք մեր ֆայլերի պատճենմանը: Ինչպես տեսնում եք, այն չի ընդհատվել, կատարողականի մի փոքր անկում է եղել, բայց ընդհանուր առմամբ ամեն ինչ վերադարձել է նույն ~ 800 ՄԲ/վ:

Մենք գնում ենք պահեստավորման համակարգ և տեղեկատվական վահանակում տեսնում ենք անեծք, որ Engine-1 կարգավորիչը անհասանելի է (իհարկե, մենք սպանեցինք այն):

Նմանատիպ գրառում մենք տեսնում ենք նաև տեղեկամատյաններում:

Պահպանման կարգավորիչը նույնպես փրկվել է ձախողումից հաջողությամբ։

Թիվ 3 թեստ. Էլեկտրամատակարարման անջատում:

Ամեն դեպքում, մենք նորից սկսեցինք պատճենել ֆայլերը, բայց չդադարեցրինք IOMETER-ը:
Մենք քաշում ենք էլեկտրամատակարարման միավորը:

Տեղեկատվական վահանակի պահեստավորման համակարգին ավելացվել է ևս մեկ ահազանգ:

Նաև սենսորների մենյուում մենք տեսնում ենք, որ անջատված սնուցման հետ կապված սենսորները կարմիր են դարձել:

Պահպանման համակարգը շարունակում է աշխատել։ Էներգամատակարարման միավորի խափանումը որևէ կերպ չի ազդում պահեստավորման համակարգի աշխատանքի վրա, հյուրընկալողի տեսանկյունից պատճենման արագությունը և IOMETER ցուցիչները մնացել են անփոփոխ:

Էլեկտրաէներգիայի խափանման թեստն անցել է հաջողությամբ։

Վերջնական փորձարկումից առաջ մենք որոշեցինք մի փոքր կյանքի կոչել պահեստավորման համակարգը, հետ դնել կարգավորիչը և սնուցման միավորը, ինչպես նաև կարգի բերել մալուխները, ինչի մասին պահեստային համակարգը ուրախությամբ տեղեկացրեց մեզ իր առողջության վահանակի կանաչ պատկերակներով: .

Թեստ թիվ 4. Խմբում երեք սկավառակի ձախողում

Մինչ այս թեստը մենք կատարեցինք լրացուցիչ նախապատրաստական ​​քայլ։ Փաստն այն է, որ ENGINE պահեստավորման համակարգը ապահովում է շատ օգտակար բան՝ վերակառուցման տարբեր քաղաքականություններ: TS Solution-ն ավելի վաղ գրել էր այս հատկության մասին, բայց եկեք հիշենք դրա էությունը։ Պահպանման ադմինիստրատորը կարող է նշել ռեսուրսների բաշխման առաջնահերթությունը վերակառուցման ընթացքում: Կամ I/O կատարման ուղղությամբ, այսինքն՝ վերակառուցումն ավելի երկար է տևում, բայց կատարողականի նվազեցում չկա: Կամ վերակառուցման արագության ուղղությամբ, բայց արտադրողականությունը կնվազի։ Կամ հավասարակշռված տարբերակ: Քանի որ սկավառակի խմբի վերակառուցման ժամանակ պահեստավորման կատարումը միշտ ադմինիստրատորի գլխացավանք է, մենք կփորձարկենք քաղաքականությունը I/O կատարողականի նկատմամբ կողմնակալությամբ և վերակառուցման արագության հաշվին:

Հիմա եկեք ստուգենք սկավառակի ձախողումը: Մենք նաև հնարավորություն ենք տալիս ձայնագրել LUN-ներում (ֆայլեր և IOMETER): Քանի որ մենք ունենք եռակի պարիտետով խումբ (RAID-60P), դա նշանակում է, որ համակարգը պետք է դիմանա երեք սկավառակի խափանումներին, իսկ ձախողումից հետո պետք է աշխատի ավտոմատ փոխարինումը, մեկ սկավառակը պետք է զբաղեցնի ձախողվածներից մեկի տեղը: RDG-ում, և դրա վրա պետք է սկսել վերակառուցումը:

Սկսել. Նախ, պահեստավորման ինտերֆեյսի միջոցով, եկեք ընդգծենք սկավառակները, որոնք ցանկանում ենք դուրս հանել (որպեսզի բաց չթողնենք և չքաշեք ինքնափոխման սկավառակը):

Մենք ստուգում ենք ցուցիչը սարքավորման վրա: Ամեն ինչ կարգին է, մենք տեսնում ենք երեք ընդգծված սկավառակ:

Եվ մենք հանում ենք այս երեք սկավառակը:

Եկեք նայենք, թե ինչ է հաղորդավարի վրա: Եվ այնտեղ... ոչ մի առանձնահատուկ բան տեղի չի ունեցել։

Պատճենման ցուցիչները (սկզբից ավելի բարձր են, քանի որ քեշը տաքացել է) և IOMETER-ը շատ չեն փոխվում սկավառակները հեռացնելիս և վերակառուցումը սկսելիս (5-10%-ի սահմաններում)։

Եկեք տեսնենք, թե ինչ կա պահեստավորման համակարգում:

Խմբի կարգավիճակում տեսնում ենք, որ վերակազմավորման գործընթացը սկսվել է, և այն մոտ է ավարտին։

RDG կմախքի մեջ դուք կարող եք տեսնել, որ 2 սկավառակ կարմիր կարգավիճակում է, և մեկն արդեն փոխարինված է: Autoreplacement սկավառակն այլևս չկա, այն փոխարինեց 3-րդ ձախողված սկավառակին: Վերակառուցումը տևեց մի քանի րոպե, 3 սկավառակի ձախողման դեպքում ֆայլեր գրելը չէր ընդհատվում, և մուտքի/ելքի կատարումը շատ բան չէր փոխվում:

Սկավառակի ձախողման թեստը միանշանակ անցավ հաջողությամբ։

Ամփոփում

Այս պահին մենք որոշեցինք դադարեցնել բռնությունը պահեստավորման համակարգերի նկատմամբ: Ամփոփենք.

• FC պորտի ձախողման ստուգում - հաջողված
• Ethernet պորտի ձախողման ստուգում - հաջող
• Վերահսկիչի ձախողման ստուգում - հաջողված
• Էլեկտրաէներգիայի ձախողման թեստ - հաջողված
• Սկավառակի ձախողման ստուգում grouppool-ում - հաջող

Խափանումներից և ոչ մեկը չի դադարեցրել ձայնագրումը կամ սխալներ չի առաջացրել սինթետիկ բեռի մեջ, իհարկե, կատարման հարված է եղել (և մենք գիտենք, թե ինչպես հաղթահարել այն, ինչը շուտով կանենք), բայց հաշվի առնելով, որ դրանք վայրկյաններ են, միանգամայն ընդունելի է: Եզրակացություն. AERODISK պահեստավորման համակարգի բոլոր բաղադրիչների սխալ հանդուրժողականությունն աշխատել է մակարդակով, խափանման կետեր չկան:

Ակնհայտ է, որ մեկ հոդվածում մենք չենք կարող փորձարկել ձախողման բոլոր սցենարները, բայց մենք փորձել ենք լուսաբանել ամենահայտնիները: Ուստի խնդրում եմ ուղարկել ձեր դիտողությունները, առաջարկությունները հետագա հրապարակումների համար և, իհարկե, համարժեք քննադատություն։ Մենք ուրախ կլինենք քննարկել (կամ ավելի լավ է, եկեք մարզմանը, ես կրկնօրինակում եմ գրաֆիկը ամեն դեպքում): Մինչև նոր թեստեր!

• Նիժնի Նովգորոդ (ԱՐԴԵՆ ԲԱՑ Է. կարող եք գրանցվել այստեղ https://aerodisk.promo/nn/);
  Մինչև 16 թվականի ապրիլի 2019-ը կենտրոն կարող եք այցելել ցանկացած աշխատանքային ժամի, իսկ 16 թվականի ապրիլի 2019-ին կկազմակերպվի վերապատրաստման մեծ դասընթաց։
• Krasnodar (ԲԱՑՈՒՄԸ ՇՈՒՏՈՎ - կարող եք գրանցվել այստեղ https://aerodisk.promo/krsnd/ );
  9 թվականի ապրիլի 25-ից 2019-ը կենտրոն կարող եք այցելել ցանկացած աշխատանքային ժամի, իսկ 25 թվականի ապրիլի 2019-ին կկազմակերպվի վերապատրաստման մեծ դասընթաց։
• Ekaterinburg (ԲԱՑՈՒՄԸ ՇՈՒՏՈՎ, հետևեք մեր կայքի կամ Habré-ի տեղեկատվությանը);
  մայիս-հունիս 2019թ.
• Новосибирск (հետևեք մեր կայքի կամ Habré-ի տեղեկատվությանը);
  Հոկտեմբեր 2019.
• Krasnoyarsk (հետևեք մեր կայքի կամ Habré-ի տեղեկատվությանը);
  2019 թվականի նոյեմբեր

Source: www.habr.com