Пабудова хмарнага сховішчы для захоўвання і дастаўкі статычнага кантэнту на аснове інтэграцыі Nginx і Openstack Swift

Станіслаў Багатыроў: Здравствуйте! Мяне клічуць Станіслаў Багатыроў. Я ўяўляю "хмарны" хостынг Clodo. Распавядаць буду таксама пра "воблачным" сховішча для розных дадзеных, у тым ліку бінарных. Мы нядаўна яго запусцілі. Хочацца падзяліцца некаторымі аспектамі рэалізацыі і праблемамі, з якімі мы сустрэліся.

Такім чынам, любое рашэнне павінна стварацца для нейкай праблемы. Праблема "аблокі" у Расіі і ва ўсім свеце - гэта маркетынг, які сфармаваў ў людзей няслушныя чакання, часам зусім фантастычныя.

Так, карыстальнік прыходзіць у "воблака" са сваім сайтам, зробленым у звычайнай CMS з ужываннем long stack, і спадзяецца, што ў яго як па чараўніцтве адразу з'явіцца магчымасць вытрымліваць любыя нагрузкі, абслугоўваць любую колькасць карыстальнікаў і не марнаваць пры гэтым грошай. На жаль, гэта не так.

Тэхнічна "воблака" ўяўляе сабой нейкія віды рэсурсаў, камбінуючы якія распрацоўшчык можа ствараць сваё рашэнне. З такімі тыпамі "хмарных" рэсурсаў, як працэсар, памяць ці цвёрды дыск ўсё больш-менш зразумела (яны знаёмыя шараговым карыстальнікам па працы на стацыянарных кампутарах). З астатнімі тыпамі рэсурсаў справа ідзе некалькі складаней. Спрабуючы камбінаваць ўжо знаёмыя тыпы, карыстальнікі ствараюць свае рашэнні. Яны атрымліваюцца не самымі эфектыўнымі. Людзі хвалююцца і расчароўваюцца ў "аблоках". Гэта не зусім тое, чаго нам бы хацелася.

Да тыпах "хмарных" рэсурсаў таксама можна аднесці, напрыклад, рэсурсы балансавання нагрузкі і рэсурсы дастаўкі кантэнту (думаю, гэтая тэма блізкая ўсім). Гэта тое, з чым сутыкаецца любы чалавек: перадача малюнкаў з сервера карыстальнікам і гэтак далей.

Часта даводзіцца назіраць наступную карціну: карыстальнік выкарыстоўвае віртуальны сервер, ведаючы, што яго лёгка маштабаваць вертыкальна. Чалавек бярэ велізарны вінчэстар, складвае шмат дробных файлаў у адну дырэкторыю, раздае іх - і ў яго нічога не атрымліваецца.

На гэтым слайдзе мы прапануем больш "заменчаную" пад выкарыстанне "аблокі" архітэктуру. На расійскіх "аблоках" яе нельга было цалкам рэалізаваць, бо расійскія "аблокі" прадстаўляюць сабой тры даступных для ўсіх рэсурсу. Але навошта быць "як усе"? Мы вырашылі стаць трохі лепш і стварылі сэрвіс для прадастаўлення кантэнту (Cloud Storage), для раздачы і захоўвання дадзеных, і хутка ўвядзем балансаванне. Такім чынам, мы дазволім карыстачу абкласці сваё рашэнне ў такую ​​схему.

Тут патрэбныя мінімальныя дапрацоўкі звыклай архітэктуры. У нас тут ёсць базы дадзеных, знаёмыя ўсім. Як мы ведаем, у класічным варыянце LVM стэка яны не вельмі добра маштабуецца гарызантальна. Для іх зручна браць невялікая колькасць вертыкальна маштабуюцца сервераў. Генератары дынамічнага кантэнту могуць быць абсалютна аднолькавымі пры той умове, што мы выносім ўсю статыку, усе файлы ў "хмарнае" сховішча і раздаем іх праз нейкія вонкавыя сэрвісы. Яны незатратнай па рэсурсах, іх па меры неабходнасці можна лёгка маштабаваць гарызантальна. Нагрузка паміж імі дзеліцца нашым вонкавым сэрвісам Load Balancing.

Такім чынам, запыты ад кліента на статыку сыходзяць на Cloud Storage, на раздачу. Раздача адбываецца хутка - за кошт таго, што гэта ўсё кэшуецца. Абсталяванне "заменчаны" менавіта пад гэта: там хуткі канал, і гэтак далей. На аплачванае час працэсара, дыска і памяці (традыцыйных сэрвісаў) прыпадае толькі частка генерацыі дынамікі карыстальніка. Гэта істотная эканомія. Некалькі нашых кліентаў перайшлі на такую ​​архітэктуру. Павялічылася якасць і хуткасць раздачы, а затраты зменшыліся, як ні дзіўна.

Якімі характарыстыкамі павінна валодаць добры "хмарнае" сховішча?

Калі мы стваралі наша сховішча, мы думалі пра тое, якім яно павінна быць.

• Па-першае, яно павінна надзейна захоўваць дадзеныя карыстальнікаў. Гэта відавочна.

• Мы хацелі, каб у нашага сховішчы быў просты, зручны, зразумелы API для кіравання дадзенымі. Бо цяпер большасцю сервераў карыстаюцца не толькі людзі, але і розныя робаты, API павінен быць адаптаваны яшчэ і да праграм.

• Асноўная функцыя, акрамя захоўвання, - гэта хуткая раздача кантэнту ў вялікіх колькасцях па пратаколе HTTP.

• Таксама раптам паўстала наступная праблема: людзі не гатовыя адразу ўзяць і перапісаць свой сэрвіс або сайт і перайсці на іншы від доступу да дадзеных. Таму на перыяд міграцыі трэба было зрабіць варыянт зручнага прамежкавага доступу ў файлавую сістэму - магчыма, з ужываннем пратаколу FTP.

Мы спынілі свой выбар на OpenStack Swift. Па-першае, гэта рашэнне Open Source. Па-другое, яно адказвала ўсім нашым патрабаванням, архітэктурна адпавядала нашым задумак. Замест таго каб вынаходзіць свой ровар, мы вырашылі дапрацаваць існуючы.

У чым асаблівасць Swift? На малюнку паказана, як ён арганізаваны архітэктурна. "Auth node" - гэта нейкі сервер аўтарызацыі, на які карыстальнік прыходзіць пры доступе праз API (мы цяпер не гаворым пра HTTP-раздачу, мы гаворым пра работу па API). Ён паказвае лагін, пароль і атрымлівае токен, па якім будуць аўтарызавацца ўсе яго запыты. Таксама ён атрымлівае URL-кластар, з якім яму неабходна працаваць. Далей ён ідзе на ноду проксі (Proxy node), праз якую праходзяць усе запыты. Нода проксі па Хэш-кольцы знаходзіць сервер back-end, да якога ёй трэба звярнуцца. Пасылае запыт, атрымлівае дадзеныя, вяртае карыстальніку. Усё проста.

Swift аперуе з трыма сутнасцямі. Каб было зразумела, чым гэта адрозніваецца ад файлаў: гэта аб'ектнае сховішча. Ёсць 3 тыпу сутнасцяў.

1. Першая, найбольш высокага ўзроўню - гэта рахунак. Гэта нейкі агрэгатар кантэйнераў.

2. Кантэйнер - гэта дырэкторыя першага ўзроўню ў выглядзе для карыстальніка, якая можа мець нейкія метаатрибуты. Правы доступу, да прыкладу.

3. Самая апошняя і самая запатрабаваная карыстальнікамі сутнасць - гэта аб'екты, якія прывязаныя да кантэйнераў. Аб'екты захоўваюцца плоска. Няма ніякай структуры каталогаў. Дырэкторыя - гэта ўсяго толькі ілюзія з імёнамі.

У кантэйнеры можа знаходзіцца неабмежаваная колькасць аб'ектаў. Мы ў нас быў мільён аб'ектаў, распрацоўшчыкі Swift спрабавалі выкарыстоўваць 10 мільёнаў аб'ектаў. Кожны з тыпаў аб'ектаў "завязаны" на ўласнае Хэш-кальцо. Працуе ўсё гэта досыць хутка. Пры напаўненні кластара гранічным колькасцю аб'ектаў хуткасць практычна не змяняецца. У плане доступу ўсё функцыянуе амаль гэтак жа, як на пустым.

Што мы зрабілі спачатку? Спачатку мы ўзялі і разгарнулі OpenStat і Swift так, як рэкамендуе супольнасць распрацоўнікаў. Мы ўзялі серверы front-end, некаторыя серверы back-end, і паставілі іх пад кіраванне рашэння Pacemaker. Мы любім усё аўтаматызаваць і эканоміць сілы супрацоўнікаў.

На серверах back-end ў нас былі жорсткія дыскі SATA з наладжанай файлавай сістэмай XFS (мы злёгку аптымізавалі налады). На серверах back-end мы разгарнулі ўсе сэрвісы сховішчы Swift (аб'ектныя, аккаунтные, кантэйнерныя). Плюс мы там паставілі лагаванне і білінг, таму што з карыстальнікаў нам трэба было браць грошы. Гэта таксама лічылася серверах back-end.

На серверах front-end мы паставілі Swift Proxy. Так як у нас кожны кластар павінен быць надзейным ўнутры сябе, ёсць нейкі набор плаваюць IP-адрасоў, якія з дапамогай Pacemaker перакідаюцца на "жывыя" серверы.

Мы "паднялі" гэтае рашэнне, але, на жаль, па тэстах на front-end атрымалі прадукцыйнасць ўсяго толькі ў 400 запытаў у секунду, што вельмі сумна. Таму мы вырашылі думаць, што ж нам рабіць далей.

Першае, найбольш відавочнае рашэнне - гэта паставіць NGINX наперад, перад Swift Proxy. Гэта спрацавала. Аналіз запытаў паказаў, што нідзе ніякае кэшаванне не ўжывалася. Жыццёвы цыкл запыту ад моманту адпраўкі запыту кліентам да атрымання адказу ўсё роўна праходзіў да сервераў back-end і назад. Таму ўжыванне кэшавання ў нейкім выглядзе было відавочным рашэннем.

На серверах front-end мы для кэша паставілі дыскі SAS пад ReiserFS. Нам не хацелася марнаваць ёмістасць дыскаў на RAID, таму там проста дададзеныя дыскі. На кожны дыск вылучана асобная кэш-зона. Для гэтага давялося крыху прапатчыць NGINX, дадаўшы для яго падтрымку некалькіх кэшаў. Дзякуй Кірылу карынфскімі, ён у гэтым дапамог.

У такім варыянце па тэстах мы атрымалі ўжо 12 тысяч запытаў на front-end. Гэта ўжо больш прымальнае рашэнне. Кластараў ў дата-цэнтры можа быць шмат. На кожны кластар ідзе канал з агрэгацыяй дзесьці па 4 гігабіту на кожны front-end. У цэлым досыць нядрэнная утылізацыя як па канале, так і па працэсару.

Пры гэтым у першым выпадку мы "ўпіраліся" у рэсурсы сістэмы, паколькі Swift напісаны на Python і спажывае значную колькасць рэсурсаў. У другім выпадку ў нас пры максімальнай нагрузцы амаль палова рэсурсаў адносна вольная, і мы ўжо ведаем, для чаго іх выкарыстоўваць.

Калі мы ўвялі сэрвіс у эксплуатацыю, у карыстальнікаў пачаліся праблемы. Па-першае, ім вельмі не спадабаўся фармат спасылак, якія прадстаўляюцца ім пасля таго, як яны змяшчаюць дадзеныя ў сховішчы.

Што ёсць што на верхняй спасылцы? cs1.clodo.ru - гэта кластар, да якога трэба звярнуцца, каб атрымаць дадзеныя. v1 - версія пратаколу, усё гэта парс серверам front-end. Потым у нас ідзе рахунак карыстальніка. Далей прэфіксам "public" пазначаны кантэйнер. images / image01.gif - гэта імя аб'екта. Гэта не дырэкторыя "images" з файлам выявы.

Для вырашэння праблемы мы зноў задзейнічалі NGINX. Мы пачалі выдзяляць кожнаму карыстачу па віртуальнай HTTP-серверу (не па працэсе, а менавіта па канфігурацыі) з яго даменам "public". Гэта зарабіла. Дадаткова мы атрымалі магчымасць кантраляваць параметры кэшавання для дадзеных кожнага карыстальніка, а таксама задаваць валіднасць, і гэтак далей.

Карыстальнікі заявілі, што ім не падабаецца прэфікс "public". Напрыклад, калі ў іх малюнак размешчана ў кантэйнеры "public", яны хочуць бачыць у спасылцы проста "images". Гэта мы таксама вырашылі з дапамогай NGINX. Проста статыстычна паглядзелі, куды часцей "тыка" карыстальнікі. У 98% выпадкаў нашы чаканні апраўдваліся, таму страты прадукцыйнасці на перабор мы не адчуваем.

Карыстальнікі распавялі нам яшчэ пра адну праблему: «Я выдаліў, а ўсё гэта бачна». Вельмі шмат карыстальнікаў на гэта паскардзілася.

У чым, уласна кажучы, праблема? Так як мы кэшируем адказы сервера на некаторы час, ёсць дзве сітуацыі.

Першая. Карыстальнік паглядзеў спіс файлаў. Дадаў файл, паглядзеў спіс файлаў і здзівіўся: «Дзе мой файл?» Натуральна, ён там ёсць. Калі ён запытае сам файл, ён яго атрымае, але ў спісе ён яго не ўбачыць. Карыстальнік хвалюецца.

Другая праблема больш істотная. Карыстальнік выпадкова выклаў сваю няўдалую фатаграфію ў лазні, а потым яе выдаліў. Фатаграфія ўжо асела ў кэшы. Гэта, сапраўды, непрыемна.

Аналагічныя сэрвісы, напрыклад, у RackSpace, звязаныя з знешняй сеткай CDN, адказваюць: «Гэта ваша праблема. Праз 24 гадзіны фотаздымак выдаліцца з кэша ». Але будзе ўжо позна. Бо сярод нашых кліентаў, якім патрабуецца гэты сэрвіс, ёсць перыядычныя выданні і банкі фотаздымкаў, якія маюць дачыненне да журналістыкі, ім такая сітуацыя зусім не падыходзіла.

Таму нам давялося вырашыць і гэтае пытанне. У нас побач з NginX з'явіўся дэман, які кіруе кэшам. Спачатку мы спрабавалі заняцца праграмаваннем на файлах канфігурацыі NginX і напісаць логіку ачысткі кэша ўнутры NginX.

Спачатку мы выкарыстоўвалі мноства if. Гэта было не самае ўдалае рашэнне, і мы ад яго адразу адмовіліся. Мы ім карысталіся не больш за 5 хвілін.

Потым мы паспрабавалі убудаванае рашэнне Lua. Час, якое мы павінны былі марнаваць на апрацоўку запыту, усё роўна трацілася на нейкія нецікавыя рэчы. Нам гэта не спадабалася.

Цяпер пры апрацоўцы запыту ў post action мы пасылаем на FastCGI толькі сам запыт (англ. Request) карыстальніка без "body". Дэман кэша захоўвае ў сябе гэтыя запыты і аптымізаваць выхайвае патрэбны кэш. Так, напрыклад, калі карыстальнік выдаліў файл images / party / banya / jpg, трэба абнавіць кэш для дырэкторыі "party", скінуць кэш па лістынгу. Калі карыстальнік выдаліў файл, трэба ачысціць кэш для гэтага файла. Прытым не толькі на адным серверы front-end; натуральна, дэман чысціць гэта на ўсіх серверах front-end ў які чакае кластары. Гэта вельмі міла з яго боку.

Праект у прадакшн ўжо каля трох тыдняў пасля выхаду і тэставання. Ён жывы і развіваецца. У нас ёсць нейкія планы на будучыню.

Па-першае, мы збіраемся зрабіць праект пад назвай «Усе логі людзям!». Ён нейкім чынам звязаны з білінгу, так як Swift прадастаўляе магчымасць білінгу з дапамогай аналізу логаваў, але з невялікім дапушчэннем. Першую гадзіну мы не робім нічога, да пачатку другой гадзіны чакаем, калі назапасіць дадзеныя за мінулы гадзіну. У канцы трэцяй гадзіны мы іх апрацоўваем, биллингуем. Бо білінг у нас усюды пасекундная альбо штохвіліннай, нам такое рашэнне не падыходзіла. Мы перапісалі білінг, аналіз логаў і сістэму статыстыкі для Swift. У якасці прыемнага бонуса мы атрымалі магчымасць складаць логі раздачы карыстальнікаў на іх жа "хмарныя" сховішчы для наступнага аналізу. Гэта, пагадзіцеся, вельмі карысная штука.

Далей мы хочам усё гэта аптымізаваць для раздачы медыйнага кантэнту, у прыватнасці, відэа. Таксама мы хочам зрабіць рэплікацыю паміж рознымі кластарамі, пажадана ў розных дата-цэнтрах. Новы рэліз Swift дазваляе гэта зрабіць (ён выйшаў нядаўна, 22-га чысла). Пры наступным абнаўленні мы зробім такую ​​рэплікацыю. Плюс, папярэдне паглядзеўшы, як адбываецца гэтая рэплікацыя, мы зразумелі, што можна зрабіць і рэзервовае капіраванне часткі сховішчы непасрэдна для карыстальніка. Гэта будзе больш эфектыўна па параўнанні з варыянтам, у якім карыстальнік сам будзе выпампоўваць сабе ўсе сваё змесціва. Па-першае, гэта не будзе лішні раз нагружаць нашы серверы front-end. Па-другое, гэта проста зручней.

Далей мы хочам зрабіць аўтарызацыю па pubcookies і падпісаным запытам. Цяпер у нас кантэйнер можа быць альбо прыватным (англ. Private), і ў гэтым выпадку ён недаступны па HTTP без аўтарызацыі (будзе вяртацца 403-я памылка серверам front-end), альбо ён агульнадаступны, і з яго ідзе раздача за ўсё, што ёсць ў кантэйнеры. Прамежкавага рашэнне па сцэнары накшталт «я ўвайшоў і хачу аддаваць частку фотабанкам, напрыклад, фатаграфіі ў вялікай дазволе, толькі гэтаму карыстальніку» пакуль не рэалізавана. Але з увядзеннем pubcookies мы гэтае пытанне таксама вырашым.

Зараз мы хочам уцягнуць Swift Proxy ў модуль NginX, так як бягучы Swift Proxy на Python выконвае толькі пошук патрэбнага сервера back-end, разбіраючы Хэш-кальцо, проста глядзіць, куды звярнуцца.

Далей мы хочам дарабіць падтрымку HTTP 1.1 праз Keep Alive ў Upstream, новай карыснай магчымасцю NginX. Трэба крыху змяніць загрузку дадзеных у сховішча і дадаць інтэлекту дэману кэша. Можа быць, перапісаць яго на чым-небудзь, акрамя Perl, на якім ён напісаны, проста для хуткасці.

Што ў нас атрымалася ў выніку?

Сумарная ёмістасць на адзін кластар - гэта 840 тэрабайт SATA на сэрвэры back-end. Хуткі кэш на серверах front-end, 7 тэрабайт SAS. 512 гігабайт памяці на кэшаванне самых гарачых дадзеных. Ўсё гэта размяшчаецца ў 30 адзінак (англ. Unit) у стэку.

Выкарыстоўваем Debian. Дыскаў няма, усюды вобразы Debian Live. Праверкай кластара займаецца Pacemaker, ён канфігуруецца з дапамогай Chef. Дадзеныя па канфігурацыі - гэта інтэграцыя з нашай Clodo Panel. Праз яе ж ідзе і аўтарызацыя. Падобнае рашэнне можна выкарыстоўваць не толькі ў нас, але і ў прыватных "аблоках". Сабраць гэта ўсё ў хатніх умовах рэальна, да таго ж пры гэтым рэальна не паўтараць нашых памылак.

Уласна кажучы, усё. Я гатовы выслухаць любыя вашы пытанні.

Пытанні і адказы

Пытанне з залы: Здравствуйте! Дзякуй за даклад. Пытанне: чаму трэба было наогул инвалидировать кэшы і ня падыходзіць Ці пад дадзены профіль выкарыстання спіс тыпу "relocation list" ці "delaytion list"?

Станіслаў Багатыроў: Па-першае, инвалидировать кэшы неабходна па паводніцкіх прычынах, якія я ўжо прызначыў. Таксама хацелася абысціся мінімальнымі мадыфікацыямі ўжо існуючага рашэння. У нас ужо быў NginX, у нас ужо быў Swift. Усё гэта працавала. Ўносіць нейкія істотныя змены ў гэтую логіку проста не хацелася, таму мы завялі асобны дэман.

Рэпліка з залы: Усё роўна вы на кожны запыт робіце дадатковы подзапросов на инвалидацию кэшаў.

Станіслаў Багатыроў: Не, не зусім так. Дэман робіць гэта па-разумнаму. Ён спачатку збірае, доўга думае і робіць неабходны мінімум запытаў на ачыстку.

Пытанне з залы: Гэта значыць усё роўна ёсць нейкі прамежак паміж выдаленнем і рэальным знікненнем кантэнту?

Станіслаў Багатыроў: Так, ёсць. Больш за тое, калі мы пачалі выдаляць шмат-шмат, доўга-доўга, то гэты зазор павялічваецца. Канкрэтныя алгарытмы инвалидации мы будзем удасканальваць пад патрэбы карыстальнікаў. Але мы імкнемся не пераходзіць нейкую мяжу разумнасці. Не ўсім патрэбна ачыстка кэша ў рэальным часе.

Пытанне з залы: А лічбу можна агучыць? Праз колькі знікае фотаздымак пасля выдалення?

Станіслаў Багатыроў: Калі пашанцуе, то амаль імгненна.

Рэпліка з залы: Дзякуй.

Пытанне з залы: Вы самі казалі пра чараўніцтва "хмары" і каханую CMS карыстальніка. У вас гэта, атрымліваецца, немагчыма, таму што трэба CMS дапрацоўваць?

Станіслаў Багатыроў: Тут ёсць прадстаўнікі «Битрикс», яны ўжо ўсё дапрацавалі.

Пытанне з залы: Гэта значыць вы чакаеце, пакуль распрацоўшчыкі большасці CMS падбудаваць пад ваша воблака?

Станіслаў Багатыроў: Не зусім так. У нас на GitHub выкладзены рэпазітар Clodo corp., Мы туды паволі выкладваем розныя цікавыя рэчы. Там ёсць напісаны на Python FTP-сервер, які робіць трансляцыю з звычайнага FTP ў наш "воблака". Мы практычна цалкам сумяшчальныя з RackSpace API. Таму можна выкарыстоўваць усе напрацоўкі сусветнай супольнасці ў гэтым вобласці. Гэта кліент Fuse, гэта вельмі шырокі набор "абгортак" практычна для ўсіх моў. Варыянтаў маса. Можна нічога не змяняць, проста па Fuse падмантаваць, і гэта будзе працаваць.

Пытанне з залы: Скажыце, калі ласка, ці магу я неяк пачаць раздаваць кантэнт ня па HTTP, а па іншым пратаколе? Па FMS, напрыклад. У мяне ёсць відэафайлы, і я хачу арганізаваць іх струменевую перадачу карыстальнікам.

Станіслаў Багатыроў: На дадзены момант такой магчымасці няма. Калі вам вельмі хочацца, мы пагаворым пра гэта асобна, напішыце мне.

Пытанне з залы: Добра. Дзякуй. Ёсць іншае пытанне. Вы сказалі, што білінг уладкаваны на баку Swift. Якія запыты білінгу? Менавіта запыты да сховішча або запыты на аддачу? Запыты да NginX білінгу?

Станіслаў Багатыроў: Я, мабыць, незразумела выказаўся. Сама апрацоўка ідзе на боку сервера back-end. Білінг тое, што звяртаецца ў NginX. Ўваходны трафік ня білінгу. Білінг тое, што адпраўляецца з нашага сховішчы карыстачу з ўдалымі адказамі.

Пытанне з залы: Скажыце, калі ласка. Вы карыстаецеся OpenStack як "хмарную" платформу. Правільна?

Станіслаў Багатыроў: Не.

Пытанне з залы: Якім чынам вы яе выкарыстоўваеце?

Станіслаў Багатыроў: Мы выкарыстоўваем толькі OpenStack Swift як аснову для кластара нашага "хмарнага" захоўвання. У нас не OpenStack. У нас Zen, са сваімі дапрацоўкамі. Ня OpenStack зусім.

Пытанне з залы: Здравствуйте. Ці існуе ў вас падтрымка часовых URL? Дапусцім, ці магчымыя выпадкі, калі нейкі прыватны кантэнт можа быць аддадзены па спасылцы, якая будзе несапраўдная праз 10-15 секунд?

Станіслаў Багатыроў: Гэта ёсць у нас у планах разам з pubcookies, карысць для NginX ўжо ёсць выдатны модуль.