Алло, адамдар! Менің атым Олег Анастасьев, мен Одноклассники сайтында Платформа командасында жұмыс істеймін. Менен басқа Одноклассникиде көптеген аппараттық құралдар жұмыс істейді. Бізде 500 мыңнан астам сервері бар 8-ге жуық тіректері бар төрт деректер орталығы бар. Белгілі бір сәтте біз жаңа басқару жүйесін енгізу жабдықты тиімдірек жүктеуге, қол жеткізуді басқаруды жеңілдетуге, есептеу ресурстарын (қайта) бөлуді автоматтандыруға, жаңа қызметтерді іске қосуды тездетуге және жауаптарды жылдамдатуға мүмкіндік беретінін түсіндік. ауқымды апаттарға.
Одан не шықты?
Менен және бірқатар аппараттық құралдардан басқа, осы жабдықпен жұмыс істейтін адамдар да бар: тікелей деректер орталықтарында орналасқан инженерлер; желілік бағдарламалық қамтамасыз етуді орнатқан желішілер; инфрақұрылымның тұрақтылығын қамтамасыз ететін әкімшілер немесе SRE; және әзірлеу топтары, олардың әрқайсысы портал функцияларының бір бөлігіне жауап береді. Олар жасаған бағдарламалық құрал келесідей жұмыс істейді:
Пайдаланушы сұраулары негізгі порталдың екі жағында да қабылданады , және басқаларында, мысалы, музыкалық API фронттарында. Іскерлік логиканы өңдеу үшін олар қолданбалы серверді шақырады, ол сұранысты өңдеу кезінде қажетті мамандандырылған микросервистерді шақырады - бір графикті (әлеуметтік байланыстар графигі), пайдаланушы-кэшті (пайдаланушы профильдерінің кэші) және т.б.
Бұл қызметтердің әрқайсысы көптеген машиналарда орналастырылған және олардың әрқайсысында модульдердің жұмыс істеуіне, олардың жұмысына және технологиялық дамуына жауап беретін жауапты әзірлеушілер бар. Бұл қызметтердің барлығы аппараттық серверлерде жұмыс істейді және соңғы уақытқа дейін біз әр серверге бір тапсырманы іске қостық, яғни ол белгілі бір тапсырмаға мамандандырылған.
Неге бұлай? Бұл әдіс бірнеше артықшылықтарға ие болды:
- Жеңілді бұқаралық басқару. Тапсырма кейбір кітапханаларды, кейбір параметрлерді қажет етеді делік. Содан кейін сервер нақты бір топқа тағайындалады, осы топтың cfengine саясаты сипатталады (немесе ол бұрыннан сипатталған) және бұл конфигурация орталықтандырылған және осы топтағы барлық серверлерге автоматты түрде таратылады.
- Жеңілдетілген диагностика. Орталық процессорға жүктеменің жоғарылауына қарап, бұл жүктеме тек осы аппараттық процессорда жұмыс істейтін тапсырма арқылы жасалуы мүмкін екенін түсіндіңіз делік. Кінәлі біреуді іздеу өте тез аяқталады.
- Жеңілдетілген мониторинг. Серверде бірдеңе дұрыс болмаса, монитор бұл туралы хабарлайды және сіз кім кінәлі екенін білесіз.
Бірнеше репликалардан тұратын қызметке бірнеше серверлер бөлінген - әрқайсысы үшін бір. Содан кейін қызметке арналған есептеу ресурсы өте қарапайым бөлінеді: қызметте бар серверлер саны, ол тұтына алатын ресурстардың максималды мөлшері. Мұндағы «оңай» оны пайдалану оңай дегенді білдірмейді, бірақ ресурстарды бөлу қолмен орындалады деген мағынада.
Бұл тәсіл бізге де мүмкіндік берді арнайы темір конфигурациялары осы серверде орындалатын тапсырма үшін. Егер тапсырма деректердің үлкен көлемін сақтаса, онда біз 4 дискі бар шассиі бар 38U серверін қолданамыз. Егер тапсырма таза есептеу болса, біз арзанырақ 1U серверін сатып аламыз. Бұл есептеу жағынан тиімді. Басқа нәрселермен қатар, бұл тәсіл бір ыңғайлы әлеуметтік желімен салыстырылатын жүктемесі бар төрт есе аз машиналарды пайдалануға мүмкіндік береді.
Есептеу ресурстарын пайдаланудағы мұндай тиімділік, егер біз ең қымбат нәрсе - серверлер деген алғышарттан шығатын болсақ, экономикалық тиімділікті қамтамасыз етуі керек. Ұзақ уақыт бойы аппараттық құрал ең қымбат болды және біз аппараттық құралдардың сенімділігіне қойылатын талаптарды азайту үшін ақауларға төзімділік алгоритмдерін ойлап, жабдықтың бағасын төмендетуге көп күш жұмсадық. Ал бүгін біз сервер бағасы шешуші болудан қалған кезеңге жеттік. Егер сіз соңғы экзотиканы қарастырмасаңыз, онда тіректегі серверлердің нақты конфигурациясы маңызды емес. Енді бізде тағы бір мәселе бар – деректер орталығындағы сервер алатын орынның бағасы, яғни сөредегі орын.
Бұл жағдайдың бар екенін түсініп, біз сөрелерді қаншалықты тиімді пайдаланғанымызды есептеуді шештік.
Біз экономикалық тұрғыдан негізделген серверлерден ең қуатты сервердің бағасын алдық, сөрелерге қанша серверді орналастыра алатынымызды, «бір сервер = бір тапсырма» ескі моделі негізінде оларда қанша тапсырма орындайтынымызды және олардың қанша екенін есептедік. тапсырмалар жабдықты пайдалана алады. Олар санап, көз жасын төкті. Тіректерді пайдаланудағы тиімділігіміз шамамен 11% құрайды. Бұдан шығатын қорытынды анық: бізге деректер орталықтарын пайдаланудың тиімділігін арттыру керек. Шешім анық сияқты: бір серверде бірден бірнеше тапсырманы орындау керек. Бірақ қиындықтар осы жерден басталады.
Жаппай конфигурация күрт күрделене түседі - енді серверге бір топты тағайындау мүмкін емес. Өйткені, енді бір серверде әртүрлі командалардың бірнеше тапсырмасын іске қосуға болады. Сонымен қатар, конфигурация әртүрлі қолданбалар үшін қайшы болуы мүмкін. Диагностика да күрделене түседі: серверде процессордың немесе дискіні тұтынудың жоғарылауын көрсеңіз, қандай тапсырма қиындық тудырып жатқанын білмейсіз.
Бірақ ең бастысы, бір машинада орындалатын тапсырмалар арасында оқшаулану жоқ. Мұнда, мысалы, бір серверде басқа есептеу қосымшасы іске қосылғанға дейінгі және одан кейінгі сервер тапсырмасының орташа жауап беру уақытының графигі берілген, біріншісіне еш қатысы жоқ – негізгі тапсырманың жауап беру уақыты айтарлықтай өсті.
Тапсырмаларды контейнерлерде немесе виртуалды машиналарда орындау керек екені анық. Біздің тапсырмаларымыздың барлығы дерлік бір ОЖ (Linux) астында орындалатындықтан немесе оған бейімделгендіктен, бізге көптеген әртүрлі операциялық жүйелерді қолдау қажет емес. Тиісінше, виртуалдандыру қажет емес, қосымша шығындардың арқасында ол контейнерлеуге қарағанда тиімдірек болады.
Тапсырмаларды серверлерде орындауға арналған контейнерлерді іске асыру ретінде Docker жақсы үміткер: файлдық жүйе кескіндері қайшы конфигурациялары бар мәселелерді жақсы шешеді. Кескіндердің бірнеше қабаттан тұруы мүмкін екендігі жалпы бөліктерді жеке негізгі қабаттарға бөліп, оларды инфрақұрылымға орналастыру үшін қажетті деректер көлемін айтарлықтай азайтуға мүмкіндік береді. Содан кейін негізгі (және ең көлемді) қабаттар бүкіл инфрақұрылым бойынша жеткілікті жылдам кэштеледі және қолданбалар мен нұсқалардың көптеген түрлерін жеткізу үшін тек шағын қабаттарды тасымалдау қажет болады.
Сонымен қатар, Docker-тегі дайын тізілім және кескінді тегтеу бізге кодты нұсқалау және өндіріске жеткізу үшін дайын примитивтерді береді.
Docker, кез келген басқа ұқсас технология сияқты, бізге қораптан тыс контейнерді оқшаулаудың кейбір деңгейін қамтамасыз етеді. Мысалы, жадты оқшаулау – әрбір контейнерге машина жадын пайдалану шегі беріледі, одан тыс ол тұтынбайды. Сондай-ақ, процессорды пайдалану негізінде контейнерлерді оқшаулауға болады. Біз үшін стандартты оқшаулау жеткіліксіз болды. Бірақ бұл туралы толығырақ төменде.
Серверлерде контейнерлерді тікелей іске қосу - мәселенің бір бөлігі ғана. Екінші бөлігі серверлерде контейнерлерді орналастыруға қатысты. Сіз қай серверге қай контейнерді орналастыруға болатынын түсінуіңіз керек. Бұл соншалықты оңай міндет емес, өйткені контейнерлерді олардың жылдамдығын төмендетпей серверлерге мүмкіндігінше тығыз орналастыру керек. Мұндай орналастыру ақауларға төзімділік тұрғысынан да қиын болуы мүмкін. Көбінесе біз бір қызметтің көшірмелерін әртүрлі сөрелерге немесе тіпті деректер орталығының әртүрлі бөлмелеріне орналастырғымыз келеді, осылайша тірек немесе бөлме істен шыққан жағдайда, біз барлық қызмет көшірмелерін бірден жоғалтпаймыз.
8 мың сервер мен 8-16 мың контейнер болған кезде контейнерлерді қолмен тарату опция емес.
Бұған қоса, әзірлеушілерге әкімшінің көмегінсіз өз қызметтерін өндірісте орналастыра алатындай етіп ресурстарды бөлуде көбірек тәуелсіздік бергіміз келді. Сонымен қатар, кейбір кішігірім қызмет деректер орталықтарымыздың барлық ресурстарын тұтынбауы үшін бақылауды сақтағымыз келді.
Әлбетте, бізге мұны автоматты түрде орындайтын басқару қабаты қажет.
Осылайша, біз барлық сәулетшілер сүйетін қарапайым және түсінікті суретке келдік: үш шаршы.
бір бұлтты шеберлер - бұлтты оркестрлеуге жауапты ауыстырып қосу кластері. Әзірлеуші шеберге манифест жібереді, онда қызметті орналастыруға қажетті барлық ақпарат бар. Оның негізінде шебер таңдалған миниондарға (контейнерлерді іске қосуға арналған машиналар) командалар береді. Миниондарда пәрменді алатын, Docker-ге өз пәрмендерін беретін агентіміз бар және Docker сәйкес контейнерді іске қосу үшін Linux ядросын конфигурациялайды. Командаларды орындаудан басқа, агент шеберге минион машинасының да, онда жұмыс істейтін контейнерлердің де күйіндегі өзгерістер туралы үздіксіз есеп береді.
Ресурстарды бөлу
Енді көптеген миниондар үшін күрделі ресурстарды бөлу мәселесін қарастырайық.
Бір бұлттағы есептеу ресурсы:
- Белгілі бір тапсырма үшін тұтынылатын процессор қуатының мөлшері.
- Тапсырма үшін қолжетімді жад көлемі.
- Желі трафигі. Миниондардың әрқайсысында шектеулі өткізу қабілеті бар белгілі бір желі интерфейсі бар, сондықтан олар желі арқылы жіберетін деректер көлемін есепке алмай тапсырмаларды тарату мүмкін емес.
- Дискілер. Сонымен қатар, бұл тапсырмалар үшін кеңістікке біз диск түрін де бөлеміз: HDD немесе SSD. Дискілер секундына шекті сұрауларға қызмет ете алады - IOPS. Сондықтан, бір диск орындай алатыннан көбірек IOPS жасайтын тапсырмалар үшін біз «шпиндельдерді» де бөлеміз, яғни тек тапсырма үшін резервтелуі керек диск құрылғылары.
Содан кейін кейбір қызмет үшін, мысалы, пайдаланушы кэші үшін, біз тұтынылған ресурстарды осылай жаза аламыз: 400 процессор өзегі, 2,5 ТБ жад, екі бағыттағы 50 Гбит/с трафик, 6 шпиндельде орналасқан 100 ТБ HDD кеңістігі . Немесе келесідей таныс формада:
alloc:
cpu: 400
mem: 2500
lan_in: 50g
lan_out: 50g
hdd:100x6TПайдаланушы кэш қызметінің ресурстары өндірістік инфрақұрылымдағы барлық қолжетімді ресурстардың бір бөлігін ғана тұтынады. Сондықтан, мен кенеттен, оператордың қателігіне байланысты, пайдаланушы кэші оған бөлінгеннен көп ресурстарды тұтынбайтынына көз жеткізгім келеді. Яғни, біз ресурстарды шектеуіміз керек. Бірақ біз квотаны немен байланыстыра аламыз?
Компоненттердің өзара әрекеттесуінің айтарлықтай жеңілдетілген диаграммасына оралайық және оны толығырақ мәліметтермен қайта сызайық - келесідей:
Сіздің көзіңізге не түседі:
- Веб-фронсон және музыка бір қолданба серверінің оқшауланған кластерлерін пайдаланады.
- Бұл кластерлер жататын логикалық қабаттарды ажырата аламыз: фронттар, кэштер, деректерді сақтау және басқару деңгейі.
- Фронт гетерогенді, ол әртүрлі функционалды ішкі жүйелерден тұрады.
- Сондай-ақ кэштер деректері кэштелген ішкі жүйе бойынша шашыраңқы болуы мүмкін.
Суретті қайта салайық:
Бах! Иә, біз иерархияны көреміз! Бұл ресурстарды үлкенірек бөліктерге бөлуге болатындығын білдіреді: функционалдық ішкі жүйеге сәйкес келетін осы иерархияның түйініне жауапты әзірлеушіні тағайындаңыз (суреттегі «музыка» сияқты) және иерархияның бірдей деңгейіне квотаны тіркеңіз. Бұл иерархия сонымен қатар басқаруды жеңілдету үшін қызметтерді икемді түрде ұйымдастыруға мүмкіндік береді. Мысалы, біз барлық вебті бөлеміз, өйткені бұл серверлердің өте үлкен тобы, суретте group1, group2 ретінде көрсетілген бірнеше кішірек топтарға.
Қосымша жолдарды алып тастау арқылы біз суретіміздің әрбір түйінін жалпақ пішінде жаза аламыз: group1.web.front, api.music.front, user-cache.cache.
Осылайша біз «иерархиялық кезек» ұғымына келеміз. Оның "group1.web.front" сияқты атауы бар. Оған ресурстар мен пайдаланушы құқықтарына арналған квота тағайындалады. Біз DevOps-тен келген адамға кезекке қызмет жіберу құқығын береміз және мұндай қызметкер кезекте бірдеңені іске қоса алады, ал OpsDev адамы әкімші құқықтарына ие болады, енді ол кезекті басқара алады, сол жерде адамдарды тағайындай алады, осы адамдарға құқықтар беріңіз және т.б. Бұл кезекте жұмыс істейтін қызметтер кезек квотасы шегінде іске қосылады. Егер кезектің есептеу квотасы барлық қызметтерді бірден орындау үшін жеткіліксіз болса, онда олар кезекпен орындалады, осылайша кезектің өзі қалыптасады.
Қызметтерді толығырақ қарастырайық. Қызметтің әрқашан кезек атауын қамтитын толық жарамды атауы бар. Содан кейін алдыңғы веб-қызмет атауы болады ok-web.group1.web.front. Және ол қатынасатын қолданба серверінің қызметі шақырылады ok-app.group1.web.front. Әрбір қызметтің манифесті бар, ол нақты машиналарда орналастыру үшін барлық қажетті ақпаратты көрсетеді: бұл тапсырма қанша ресурстарды тұтынатыны, ол үшін қандай конфигурация қажет, қанша көшірме болуы керек, осы қызметтің сәтсіздіктерін өңдеуге арналған сипаттар. Ал қызмет тікелей машиналарға орналастырылғаннан кейін оның даналары пайда болады. Олар сондай-ақ бір мәнді түрде аталады - дананың нөмірі және қызмет атауы ретінде: 1.ok-web.group1.web.front, 2.ok-web.group1.web.front, …
Бұл өте ыңғайлы: жұмыс істеп тұрған контейнердің атауына ғана қарап, біз көп нәрсені бірден біле аламыз.
Енді осы даналардың нені орындайтынын егжей-тегжейлі қарастырайық: тапсырмалар.
Тапсырмаларды оқшаулау кластары
OK ішіндегі барлық тапсырмаларды (және, мүмкін, барлық жерде) топтарға бөлуге болады:
- Қысқа кідіріс тапсырмалары - өнім. Мұндай тапсырмалар мен қызметтер үшін жауаптың кешігуі (кідіріс) өте маңызды, сұраулардың әрқайсысы жүйемен қаншалықты жылдам өңделеді. Тапсырмалардың мысалдары: веб-фронттар, кэштер, қолданбалы серверлер, OLTP қоймасы және т.б.
- Есептеу есептері – топтама. Мұнда әрбір нақты сұрауды өңдеу жылдамдығы маңызды емес. Олар үшін бұл тапсырманың белгілі (ұзақ) уақыт кезеңінде (өткізу қабілеті) қанша есептеулер жасайтыны маңызды. Бұл MapReduce, Hadoop, машиналық оқыту, статистиканың кез келген тапсырмалары болады.
- Фондық тапсырмалар - бос. Мұндай тапсырмалар үшін кідіріс те, өткізу қабілеті де маңызды емес. Бұған әртүрлі сынақтар, тасымалдаулар, қайта есептеулер және деректерді бір пішімнен екіншісіне түрлендіру кіреді. Бір жағынан, олар есептелгенге ұқсайды, екінші жағынан, олардың қаншалықты тез аяқталатыны біз үшін маңызды емес.
Мұндай тапсырмалар ресурстарды, мысалы, орталық процессорды қалай тұтынатынын көрейік.
Қысқа кідіріс тапсырмалары. Мұндай тапсырмада мынаған ұқсас CPU тұтыну үлгісі болады:
Өңдеу үшін пайдаланушыдан сұраныс алынады, тапсырма барлық қол жетімді процессор өзектерін пайдалана бастайды, оны өңдейді, жауапты қайтарады, келесі сұрауды күтеді және тоқтайды. Келесі сұраныс келді - біз тағы да бар нәрсені таңдадық, оны есептедік және келесісін күтеміз.
Мұндай тапсырманың ең аз кідірісіне кепілдік беру үшін біз ол тұтынатын максималды ресурстарды алып, миниондағы (тапсырманы орындайтын машина) қажетті ядролардың санын сақтауымыз керек. Сонда біздің мәселеміздің брондау формуласы келесідей болады:
alloc: cpu = 4 (max)ал егер бізде 16 ядросы бар миниондық машина болса, онда дәл осындай төрт тапсырманы қоюға болады. Біз мұндай тапсырмаларды процессордың орташа тұтынуы жиі өте төмен екенін атап өтеміз - бұл анық, өйткені тапсырма уақыттың едәуір бөлігі сұрауды күтеді және ештеңе жасамайды.
Есептеу тапсырмалары. Олардың үлгісі сәл өзгеше болады:
Мұндай тапсырмалар үшін CPU ресурстарының орташа тұтынуы айтарлықтай жоғары. Көбінесе біз есептеу тапсырмасының белгілі бір уақыт ішінде орындалуын қалаймыз, сондықтан бүкіл есептеу қолайлы уақытта аяқталуы үшін оған қажет процессорлардың ең аз санын сақтауымыз керек. Оның брондау формуласы келесідей болады:
alloc: cpu = [1,*)«Оны кем дегенде бір бос ядросы бар минионға қойыңыз, сонда қанша болса, ол бәрін жеп қояды».
Мұнда пайдалану тиімділігі қысқа кідіріспен орындалатын тапсырмаларға қарағанда әлдеқайда жақсы. Бірақ егер сіз екі тапсырма түрін бір миниондық машинада біріктіріп, оның ресурстарын жолда таратсаңыз, табыс әлдеқайда көп болады. Қысқа кідірісі бар тапсырма процессорды қажет еткенде, ол оны дереу қабылдайды, ал ресурстар қажет болмаған кезде олар есептеу тапсырмасына ауыстырылады, яғни келесідей:
Бірақ мұны қалай жасауға болады?
Алдымен өнім мен оның бөлінуін қарастырайық: cpu = 4. Бізге төрт ядроны сақтау керек. Docker іске қосуында мұны екі жолмен жасауға болады:
- Опцияны пайдалану
--cpuset=1-4, яғни тапсырмаға машинада төрт нақты ядроны бөліңіз. - Пайдаланыңыз
--cpuquota=400_000 --cpuperiod=100_000, процессор уақытына квота тағайындаңыз, яғни нақты уақыттың әрбір 100 мс тапсырманың процессор уақытының 400 мс аспайтынын көрсетіңіз. Бірдей төрт өзек алынады.
Бірақ осы әдістердің қайсысы қолайлы?
cpuset өте тартымды көрінеді. Тапсырмада төрт арнайы ядро бар, яғни процессор кэштері мүмкіндігінше тиімді жұмыс істейді. Мұның да кемшілігі бар: біз есептеулерді операциялық жүйенің орнына машинаның жүктелмеген ядролары бойынша тарату міндетін өз мойнымызға алуымыз керек және бұл өте маңызды емес тапсырма, әсіресе егер біз пакеттік тапсырмаларды осындай жүйеге орналастыруға тырыссақ. машина. Тесттер квотасы бар опцияның бұл жерде қолайлы екенін көрсетті: осылайша операциялық жүйе ағымдағы сәтте тапсырманы орындау үшін ядроны таңдауда көбірек еркіндікке ие болады және процессор уақыты тиімдірек бөлінеді.
Ең аз ядролар санына негізделген Docker-те резервтерді қалай жасау керектігін анықтайық. Пакеттік тапсырмаларға арналған квота енді қолданылмайды, өйткені максимумды шектеудің қажеті жоқ, тек минимумға кепілдік беру жеткілікті. Және мұнда опция жақсы сәйкес келеді docker run --cpushares.
Егер партияға кем дегенде бір ядроға кепілдік қажет болса, онда біз көрсетеміз деп келістік --cpushares=1024, және кем дегенде екі ядро болса, онда біз көрсетеміз --cpushares=2048. CPU акциялары процессордың уақытын бөлуге ешқандай кедергі жасамайды, егер ол жеткілікті болса. Осылайша, егер өнім қазіргі уақытта барлық төрт ядросын пайдаланбаса, пакеттік тапсырмаларды шектейтін ештеңе жоқ және олар қосымша процессор уақытын пайдалана алады. Бірақ процессорлар тапшылығы жағдайында, егер өнім төрт ядросын түгел тұтынса және өз квотасына жетсе, процессордың қалған уақыты cpushares-ке пропорционалды бөлінеді, яғни үш бос ядро жағдайында біреуі болады. 1024 cpushare бар тапсырмаға беріледі, ал қалған екеуі 2048 cpushare бар тапсырмаға беріледі.
Бірақ квота мен акцияларды пайдалану жеткіліксіз. Процессор уақытын бөлу кезінде қысқа кідірісі бар тапсырма пакеттік тапсырмадан басымдылыққа ие екеніне көз жеткізуіміз керек. Мұндай басымдықсыз пакеттік тапсырма өнімге қажет болған сәтте процессордың барлық уақытын алады. Docker іске қосуында контейнер басымдылығы опциялары жоқ, бірақ Linux CPU жоспарлаушы саясаттары ыңғайлы. Сіз олар туралы егжей-тегжейлі оқи аласыз , және осы мақаланың аясында біз оларды қысқаша қарастырамыз:
- SCHED_OTHER
Әдепкі бойынша, Linux құрылғысындағы барлық қалыпты пайдаланушы процестері қабылданады. - SCHED_BATCH
Ресурсты көп қажет ететін процестерге арналған. Тапсырманы процессорға орналастырған кезде белсендіру жазасы деп аталатын шара енгізіледі: мұндай тапсырма SCHED_OTHER тапсырмамен қазір қолданылып жатқан болса, процессор ресурстарын алу ықтималдығы төмен. - SCHED_IDLE
Өте төмен басымдылығы бар фондық процесс, тіпті жақсы -19-дан төмен. Біз ашық бастапқы кітапханамызды пайдаланамыз , қоңырау шалу арқылы контейнерді іске қосу кезінде қажетті саясатты орнату үшін
one.nio.os.Proc.sched_setscheduler( pid, Proc.SCHED_IDLE )Бірақ Java-да бағдарламаламасаңыз да, chrt пәрмені арқылы бірдей нәрсені жасауға болады:
chrt -i 0 $pidТүсінікті болу үшін барлық оқшаулау деңгейлерімізді бір кестеге жинақтайық:
Оқшаулау класы
Бөлу мысалы
Docker іске қосу опциялары
sched_setscheduler chrt*
Prod
cpu = 4
--cpuquota=400000 --cpuperiod=100000
SCHED_OTHER
Batch
CPU = [1, *)
--cpushares=1024
SCHED_BATCH
Жұмыс істемейтін
CPU= [2, *)
--cpushares=2048
SCHED_IDLE
*Егер контейнер ішінен chrt жасап жатсаңыз, сізге sys_nice мүмкіндігі қажет болуы мүмкін, себебі әдепкі бойынша Docker контейнерді іске қосқан кезде бұл мүмкіндікті жояды.
Бірақ тапсырмалар процессорды ғана емес, сонымен қатар трафикті де тұтынады, бұл желілік тапсырманың кешігуіне процессор ресурстарының дұрыс бөлінбеуінен де көп әсер етеді. Сондықтан, біз, әрине, трафик үшін дәл осындай суретті алғымыз келеді. Яғни, өнім тапсырмасы желіге кейбір пакеттерді жібергенде, біз максималды жылдамдықты шектейміз (формула бөлу: lan=[*,500mbps) ), қай өнім мұны істей алады. Ал партия үшін біз тек минималды өткізу қабілетіне кепілдік береміз, бірақ максималды шектемейміз (формула бөлу: lan=[10Мбит/с,*) ) Бұл жағдайда өнім трафигі топтамалық тапсырмалардан басымдылыққа ие болуы керек.
Мұнда Docker-те біз пайдалана алатын примитивтер жоқ. Бірақ бұл біздің көмегімізге келеді . Тәртіптің арқасында қалаған нәтижеге қол жеткізе алдық . Оның көмегімен біз трафиктің екі класын ажыратамыз: жоғары басымдықты өнім және төмен басымдықты топтама/бос жүріс. Нәтижесінде шығыс трафиктің конфигурациясы келесідей:
мұнда 1:0 – hsfc пәнінің «түбір qdisc»; 1:1 - hsfc еншілес класы жалпы өткізу қабілеттілігі шегі 8 Гбит/с, оның астында барлық контейнерлердің еншілес сыныптары орналастырылған; 1:2 - hsfc еншілес сыныбы төменде талқыланатын «динамикалық» шегі бар барлық пакеттік және бос тапсырмаларға ортақ. Қалған hsfc еншілес сыныптары - 450 және 400 Мбит/с - манифесттеріне сәйкес шектеулері бар қазіргі уақытта іске қосылған өнім контейнерлеріне арналған арнайы сыныптар. Әрбір hsfc сыныбына Linux ядросының нұсқасына байланысты qdisc кезегі fq немесе fq_codel тағайындалады, трафиктің жарылыстары кезінде пакеттердің жоғалуын болдырмас үшін.
Әдетте, tc пәндері тек шығыс трафикке басымдық беруге қызмет етеді. Бірақ біз кіріс трафикке де басымдық беруді қалаймыз - ақыр соңында, кейбір пакеттік тапсырма, мысалы, карта және азайту үшін кіріс деректерінің үлкен партиясын ала отырып, бүкіл кіріс арнасын оңай таңдай алады. Ол үшін біз модульді қолданамыз , ол әрбір желі интерфейсі үшін ifbX виртуалды интерфейсін жасайды және кіріс трафикті интерфейстен ifbX жүйесіндегі шығыс трафикке қайта бағыттайды. Сонымен қатар, ifbX үшін барлық бірдей пәндер шығыс трафикті басқару үшін жұмыс істейді, олар үшін hsfc конфигурациясы өте ұқсас болады:
Тәжірибелер барысында біз минион машиналарында басым емес топтама/бос трафиктің 1:2 класы белгілі бір бос жолақпен шектелген кезде hsfc ең жақсы нәтиже көрсететінін білдік. Әйтпесе, басым емес трафик өнім тапсырмаларының кешігуіне тым көп әсер етеді. miniond әрбір секунд сайын бос өткізу қабілеттілігінің ағымдағы мөлшерін анықтайды, берілген минионның барлық өнім тапсырмаларының орташа трафикті тұтынуын өлшейді. және оны желі интерфейсінің өткізу қабілетінен шегеру шағын маржамен, яғни.
Жолақтар кіріс және шығыс трафик үшін тәуелсіз анықталады. Және жаңа мәндерге сәйкес, miniond 1:2 басымдықсыз класс шегін қайта конфигурациялайды.
Осылайша, біз барлық үш оқшаулау класын іске асырдық: өнім, пакеттік және бос. Бұл сыныптар тапсырмалардың орындау сипаттамаларына үлкен әсер етеді. Сондықтан, біз бұл атрибутты иерархияның жоғарғы жағына орналастыруды шештік, осылайша иерархиялық кезектің атауына қараған кезде немен айналысып жатқанымыз бірден анық болады:
Біздің барлық достарымыз веб и музыка содан кейін фронттар өнім астындағы иерархияға орналастырылады. Мысалы, топтаманың астында қызметті орналастырайық музыкалық каталог, ол Одноклассники сайтына жүктелген mp3 файлдар жинағынан мезгіл-мезгіл тректер каталогын құрастырады. Жұмыс істемейтін қызметтің мысалы болуы мүмкін музыкалық трансформатор, ол музыканың дыбыс деңгейін қалыпқа келтіреді.
Қосымша жолдарды қайтадан алып тастағанда, толық қызмет атауының соңына тапсырманы оқшаулау сыныбын қосу арқылы қызмет атауларын тегіс жаза аламыз: web.front.prod, catalog.music.топтама, трансформатор.музыка.бос.
Ал енді, қызметтің атауына қарап, біз оның қандай функцияны орындайтынын ғана емес, сонымен қатар оның оқшаулау класын түсінеміз, бұл оның сынилығын және т.б.
Бәрі тамаша, бірақ бір ащы шындық бар. Бір машинада орындалатын тапсырмаларды толығымен оқшаулау мүмкін емес.
Біз қол жеткізе алдық: егер партия қарқынды түрде тұтынса тек CPU ресурстары, содан кейін кірістірілген Linux CPU жоспарлаушысы өз жұмысын өте жақсы орындайды және өнім тапсырмасына іс жүзінде ешқандай әсер етпейді. Бірақ егер бұл пакеттік тапсырма жадпен белсенді жұмыс істей бастаса, онда өзара әсер қазірдің өзінде пайда болады. Бұл өнім тапсырмасы процессордың жады кэштерінен «жуу» болғандықтан орын алады - нәтижесінде кэш өткізіп алулар көбейеді және процессор өнім тапсырмасын баяу өңдейді. Мұндай топтамалық тапсырма әдеттегі өнім контейнерінің кешігуін 10%-ға арттыруы мүмкін.
Заманауи желілік карталарда пакеттердің ішкі кезегі болғандықтан трафикті оқшаулау одан да қиын. Егер пакеттік тапсырманың пакеті бірінші болып келсе, ол кабель арқылы бірінші болып жіберіледі және бұл туралы ештеңе істеу мүмкін емес.
Сонымен қатар, біз осы уақытқа дейін TCP трафигіне басымдық беру мәселесін шеше алдық: hsfc тәсілі UDP үшін жұмыс істемейді. Тіпті TCP трафигі жағдайында, егер топтамалық тапсырма көп трафикті тудырса, бұл өнім тапсырмасының кешігуінің шамамен 10% ұлғаюын қамтамасыз етеді.
ақауларға төзімділік
Бір бұлтты әзірлеу кезіндегі мақсаттардың бірі Одноклассники қателеріне төзімділігін арттыру болды. Сондықтан, мен келесі сәтсіздіктер мен апаттардың ықтимал сценарийлерін толығырақ қарастырғым келеді. Қарапайым сценарийден бастайық - контейнердің істен шығуы.
Контейнердің өзі бірнеше жолмен істен шығуы мүмкін. Бұл манифесттегі эксперимент, қате немесе қате болуы мүмкін, соның салдарынан өнім тапсырмасы манифестте көрсетілгеннен көбірек ресурстарды тұтына бастайды. Бізде бір жағдай болды: әзірлеуші бір күрделі алгоритмді енгізді, оны бірнеше рет қайта өңдеді, өзін ойдан шығарды және шатасып кетті, ақыр соңында мәселе өте маңызды емес жолмен шешілді. Сондай-ақ, өнім тапсырмасы бірдей миниондардағы барлық басқаларға қарағанда жоғары басымдыққа ие болғандықтан, ол барлық қол жетімді процессор ресурстарын тұтына бастады. Бұл жағдайда оқшаулау, дәлірек айтқанда, CPU уақытының квотасы күнді сақтап қалды. Тапсырмаға квота бөлінсе, тапсырма көп тұтынбайды. Сондықтан, бір құрылғыда орындалатын пакеттік және басқа да өндірістік тапсырмалар ештеңені байқамады.
Екінші ықтимал мәселе - контейнердің құлауы. Міне, қайта іске қосу саясаты бізді құтқарады, оларды бәрі біледі, Docker өзі тамаша жұмыс істейді. Барлық дерлік өнім тапсырмаларында әрқашан қайта іске қосу саясаты болады. Кейде біз пакеттік тапсырмалар үшін немесе өнім контейнерлерін жөндеу үшін on_failure пайдаланамыз.
Бүкіл минион қолжетімсіз болса, не істей аласыз?
Әлбетте, контейнерді басқа машинада іске қосыңыз. Мұндағы қызықты бөлік - контейнерге тағайындалған IP мекенжайларымен не болатыны.
Біз контейнерлерге осы контейнерлер жұмыс істейтін минион машиналарымен бірдей IP мекенжайларын тағайындай аламыз. Содан кейін контейнер басқа машинада іске қосылғанда, оның IP мекенжайы өзгереді және барлық клиенттер контейнердің қозғалғанын түсінуі керек, енді олар басқа мекенжайға өтуі керек, бұл үшін бөлек Service Discovery қызметі қажет.
Service Discovery ыңғайлы. Нарықта қызмет тізілімін ұйымдастыруға арналған ақауларға төзімділіктің әртүрлі дәрежедегі көптеген шешімдері бар. Көбінесе мұндай шешімдер жүктемені теңестіру логикасын жүзеге асырады, қосымша конфигурацияны КВ сақтау түрінде сақтайды және т.б.
Дегенмен, біз жеке тізілімді енгізу қажеттілігінен аулақ болғымыз келеді, өйткені бұл өндірісте барлық қызметтер қолданатын маңызды жүйені енгізуді білдіреді. Бұл дегеніміз, бұл сәтсіздіктің ықтимал нүктесі және сіз өте қиын, уақытты және қымбат тұратын қатеге өте төзімді шешімді таңдау немесе әзірлеу керек.
Тағы бір үлкен кемшілік: ескі инфрақұрылымымыз жаңасымен жұмыс істеуі үшін Service Discovery жүйесінің қандай да бір түрін пайдалану үшін барлық тапсырмаларды қайта жазуға тура келеді. Жұмыс көп, ал кейбір жерлерде ОЖ ядросы деңгейінде немесе тікелей аппараттық құралмен жұмыс істейтін төмен деңгейлі құрылғыларға қатысты бұл мүмкін емес. сияқты белгіленген шешім үлгілерін пайдаланып, осы функционалдылықты жүзеге асыру кейбір жерлерде қосымша жүктемені білдіреді, басқаларында - жұмыстың қиындауы және қосымша сәтсіздік сценарийлері. Біз жағдайды қиындатқымыз келмеді, сондықтан біз Service Discovery қызметін қосымша пайдалануды шештік.
Бір бұлтта IP контейнерден кейін жүреді, яғни әрбір тапсырма данасы өзінің IP мекенжайына ие. Бұл мекенжай «статикалық» болып табылады: ол қызмет бұлтқа алғаш жіберілген кезде әрбір данаға тағайындалады. Егер қызметтің қызмет ету мерзімі ішінде даналардың әртүрлі саны болса, соңында оған ең көп даналар болғандай көп IP мекенжайлары тағайындалады.
Кейіннен бұл мекенжайлар өзгермейді: олар бір рет тағайындалады және өндірісте қызмет көрсетудің барлық мерзімінде бар. IP мекенжайлары желідегі контейнерлерден кейін жүреді. Егер контейнер басқа минионға берілсе, онда мекенжай одан кейін болады.
Осылайша, қызмет атауын оның IP мекенжайларының тізіміне салыстыру өте сирек өзгереді. Егер сіз мақаланың басында біз айтқан қызмет даналарының аттарын қайта қарасаңыз (1.ok-web.group1.web.front.prod, 2.ok-web.group1.web.front.prod, …), олардың DNS жүйесінде қолданылатын FQDN-ге ұқсайтынын байқаймыз. Дұрыс, қызмет даналарының атауларын олардың IP мекенжайларымен салыстыру үшін біз DNS протоколын қолданамыз. Сонымен қатар, бұл DNS барлық контейнерлердің барлық сақталған IP мекенжайларын қайтарады - жұмыс істеп тұрған және тоқтатылған (үш реплика пайдаланылды делік, және бізде бес мекенжай сақталған - бесеуі де қайтарылады). Осы ақпаратты алған клиенттер барлық бес репликамен байланыс орнатуға тырысады және осылайша жұмыс істеп тұрғандарын анықтайды. Қолжетімділікті анықтауға арналған бұл опция әлдеқайда сенімдірек, ол DNS немесе Service Discovery-ді қамтымайды, яғни ақпараттың өзектілігін және осы жүйелердің ақауларға төзімділігін қамтамасыз етуде шешуге қиын мәселелер жоқ. Сонымен қатар, бүкіл порталдың жұмысы тәуелді болатын маңызды қызметтерде біз DNS-ті мүлде пайдалана алмаймыз, тек конфигурацияға IP мекенжайларын енгіземіз.
Контейнерлердің артында мұндай IP тасымалдауды жүзеге асыру тривиальды емес болуы мүмкін - және біз оның қалай жұмыс істейтінін келесі мысалмен қарастырамыз:
Бір бұлтты шебері M1 минионына жүгіру пәрменін берді делік 1.ok-web.group1.web.front.prod 1.1.1.1 мекенжайымен. Минонда жұмыс істейді , бұл мекенжайды арнайы серверлерге жарнамалайды . Соңғыларында желілік аппаратурамен BGP сеансы бар, оған M1.1.1.1 бойынша 1 мекенжайының маршруты аударылады. M1 пакеттерді Linux көмегімен контейнерге бағыттайды. Үш маршруттық рефлекторлық сервер бар, өйткені бұл бір бұлтты инфрақұрылымның өте маңызды бөлігі - оларсыз бір бұлттық желі жұмыс істемейді. Біз оларды үшеуі бір уақытта істен шығу ықтималдығын азайту үшін мүмкін болса, деректер орталығының әртүрлі бөлмелерінде орналасқан әртүрлі сөрелерге орналастырамыз.
Енді бір бұлтты шебері мен M1 минионы арасындағы байланыс жойылды деп есептейік. Бір бұлт шебері енді M1 толығымен сәтсіздікке ұшырады деген болжам бойынша әрекет етеді. Яғни, ол M2 минионына ұшыру пәрменін береді web.group1.web.front.prod бірдей мекенжаймен 1.1.1.1. Енді бізде 1.1.1.1 үшін желіде екі қарама-қайшы маршрут бар: M1 және M2 бойынша. Осындай қайшылықтарды шешу үшін біз BGP хабарландыруында көрсетілген Multi Exit Discriminator пайдаланамыз. Бұл жарнамаланған бағыттың салмағын көрсететін сан. Қарама-қайшы бағыттар арасында MED мәні төмен маршрут таңдалады. Бір бұлтты шебер MED-ді контейнерлік IP мекенжайларының ажырамас бөлігі ретінде қолдайды. Алғаш рет мекенжай жеткілікті үлкен MED = 1 000 000 жазылады.Мұндай авариялық контейнерді тасымалдау жағдайында мастер MED-ді азайтады, ал M2 қазірдің өзінде MED = бар 1.1.1.1 мекенжайын жарнамалау командасын алады. 999 999. M1-де жұмыс істейтін данасы осы жағдайда қалады, бұл жағдайда ешқандай байланыс жоқ және оның кейінгі тағдыры шебермен байланыс қалпына келтірілмейінше, ескі түсіру сияқты тоқтатылғанға дейін бізді қызықтырмайды.
Оқиға
Барлық деректер орталығын басқару жүйелері әрқашан болмашы ақауларды қолайлы түрде өңдейді. Контейнердің толып кетуі барлық жерде дерлік қалыпты жағдай.
Деректер орталығының бір немесе бірнеше бөлмесіндегі электр қуатының үзілуі сияқты төтенше жағдайды қалай өңдейтінімізді қарастырайық.
Деректер орталығын басқару жүйесі үшін апат нені білдіреді? Ең алдымен, бұл көптеген машиналардың жаппай бір реттік істен шығуы және басқару жүйесі бір уақытта көптеген контейнерлерді көшіру керек. Бірақ егер апат өте ауқымды болса, онда барлық тапсырмаларды басқа миниондарға қайта бөлу мүмкін емес болуы мүмкін, себебі деректер орталығының ресурстық сыйымдылығы жүктеменің 100% төмен түседі.
Көбіне апаттар басқару қабатының істен шығуымен бірге жүреді. Бұл оның жабдығының істен шығуына байланысты болуы мүмкін, бірақ көбінесе апаттар сынақтан өтпегендіктен және жүктеменің жоғарылауына байланысты басқару қабатының өзі құлап кетеді.
Мұның бәріне не істей аласыз?
Жаппай көші-қон инфрақұрылымда орын алатын әрекеттердің, көшірулердің және орналастырулардың үлкен санын білдіреді. Көшірулердің әрқайсысы контейнер кескіндерін миниондарға жеткізу және орау, контейнерлерді іске қосу және инициализациялау, т.б. үшін біраз уақыт қажет болуы мүмкін. Сондықтан маңыздырақ тапсырмалардың маңыздылығы азырақ тапсырмалардан бұрын іске қосылғаны жөн.
Бізге таныс қызметтер иерархиясын қайта қарастырайық және қай тапсырмаларды бірінші орындағымыз келетінін шешуге тырысайық.
Әрине, бұл пайдаланушы сұраныстарын өңдеуге тікелей қатысатын процестер, яғни прод. Мұны біз арқылы көрсетеміз орналастыру басымдығы — кезекке тағайындауға болатын нөмір. Кезектің басымдығы жоғары болса, оның қызметтері бірінші орынға қойылады.
Өнімде біз жоғарырақ басымдықтарды белгілейміз, 0; партияда - сәл төмен, 100; бос күйде - одан да төмен, 200. Басымдылықтар иерархиялық түрде қолданылады. Иерархияда төмен тұрған барлық тапсырмалар сәйкес басымдыққа ие болады. Егер біз prod ішіндегі кэштердің фронтендтерден бұрын іске қосылуын қаласақ, онда біз кэш = 0 және алдыңғы ішкі кезектер = 1 басымдықтарын тағайындаймыз. Мысалы, біз негізгі порталды алдымен фронттардан, ал тек музыкалық фронттан іске қосуды қаласақ. содан кейін біз соңғысына төменгі басымдықты тағайындай аламыз - 10.
Келесі мәселе - ресурстардың жетіспеушілігі. Осылайша, жабдықтың үлкен көлемі, дата орталығының бүкіл залдары істен шықты және біз көптеген қызметтерді қайта іске қосқанымыз сонша, қазір ресурстар барлығына жеткіліксіз. Негізгі маңызды қызметтерді жалғастыру үшін қандай тапсырмаларды құрбан ету керектігін шешу керек.
Орналастыру басымдығынан айырмашылығы, біз барлық пакеттік тапсырмаларды таңдаусыз құрбан ете алмаймыз; олардың кейбіреулері портал жұмысы үшін маңызды. Сондықтан біз бөлек атап өттік басымдылық тапсырмалар. Орналастырылған кезде, басымдылығы жоғары тапсырманы алдын ала алады, яғни бос миниондар болмаса, төменгі басымдықты тапсырманы тоқтатады. Бұл жағдайда басымдығы төмен тапсырма орындалмай қалуы мүмкін, яғни оған жеткілікті бос ресурстары бар лайықты минион болмайды.
Біздің иерархиямызда 200-ге тең бос жұмыс үшін басымдықты көрсету арқылы өнім және топтама тапсырмалары бос тапсырмаларды алдын алатын немесе тоқтататын, бірақ бір-бірін емес, алдын ала басымдылықты көрсету өте оңай. Орналастыру басымдылығы жағдайындағы сияқты, біз күрделірек ережелерді сипаттау үшін иерархиямызды пайдалана алады. Мысалы, егер бізде негізгі веб-портал үшін ресурстар жеткіліксіз болса, сәйкес түйіндер үшін басымдықты төменірек орнату арқылы музыкалық функцияны құрбан ететінімізді көрсетейік: 10.
Толық тұрақты ток апаттары
Неліктен бүкіл деректер орталығы істен шығуы мүмкін? Элемент. Жақсы пост болды . Элементтер бір кездері коллектордағы оптиканы өртеп жіберген үйсіз адамдар деп санауға болады, ал деректер орталығы басқа сайттармен байланысын толығымен жоғалтты. Ақаулықтың себебі адам факторы болуы мүмкін: оператор бүкіл деректер орталығы құлайтындай пәрмен береді. Бұл үлкен қатеге байланысты болуы мүмкін. Жалпы, деректер орталықтарының құлауы сирек емес. Бұл бізде бірнеше айда бір рет болады.
Міне, біз ешкімнің #тірі твиттер жазбасын болдырмау үшін жасаймыз.
Бірінші стратегия - оқшаулану. Әрбір бір бұлтты данасы оқшауланған және машиналарды тек бір деректер орталығында басқара алады. Яғни қателер немесе қате оператор командалары салдарынан бұлттың жоғалуы тек бір деректер орталығының жоғалуы болып табылады. Біз бұған дайынбыз: бізде қосымшаның көшірмелері мен деректер барлық деректер орталықтарында орналасқан резервтік саясат бар. Біз ақауларға төзімді дерекқорларды қолданамыз және сәтсіздіктерді кезеңді түрде тексереміз.
Бүгіннен бастап бізде төрт деректер орталығы бар, бұл бір бұлттың төрт бөлек, толығымен оқшауланған данасын білдіреді.
Бұл тәсіл физикалық ақаудан ғана емес, сонымен қатар оператордың қателігінен де қорғай алады.
Адам факторымен тағы не істеуге болады? Оператор бұлтқа қандай да бір оғаш немесе ықтимал қауіпті пәрмен бергенде, оның қаншалықты жақсы ойлағанын көру үшін кенеттен оған шағын мәселені шешу сұралуы мүмкін. Мысалы, егер бұл көптеген көшірмелерді жаппай тоқтатудың қандай да бір түрі немесе жай ғана оғаш пәрмен болса - жаңа манифесттегі нұсқа нөмірін ғана емес, репликалардың санын азайту немесе кескіннің атын өзгерту.
Нәтижелері
Бір бұлттың ерекше белгілері:
- Қызметтер мен контейнерлердің иерархиялық және визуалды атау схемасы, бұл тапсырманың не екенін, оның немен байланысты екенін және қалай жұмыс істейтінін және оған кім жауапты екенін тез анықтауға мүмкіндік береді.
- Біз өзімізді қолданамыз өнімді және топтаманы біріктіру техникасымашиналарды бөлісу тиімділігін арттыру үшін миниондарға тапсырмалар. Процессордың орнына біз CPU квотасын, акцияларды, CPU жоспарлаушы саясаттарын және Linux QoS пайдаланамыз.
- Бір машинада жұмыс істейтін контейнерлерді толығымен оқшаулау мүмкін болмады, бірақ олардың өзара әсері 20% шегінде қалады.
- Қызметтерді иерархияға ұйымдастыру автоматты түрде апатты қалпына келтіруге көмектеседі орналастыру және басымдықтарды алу.
Жиі қойылатын сұрақтар
Біз неге дайын шешім қабылдамадық?
- Тапсырмаларды оқшаулаудың әртүрлі сыныптары миниондарға орналастырылған кезде әртүрлі логиканы қажет етеді. Егер өнім тапсырмаларын жай ғана ресурстарды резервтеу арқылы орналастыруға болатын болса, онда минион машиналарында ресурстардың нақты пайдаланылуын бақылай отырып, пакеттік және бос тапсырмаларды орналастыру керек.
- Тапсырмалар арқылы тұтынылатын ресурстарды есепке алу қажеттілігі, мысалы:
- желінің өткізу қабілеттілігі;
- дискілердің түрлері мен «шпиндельдері».
- Төтенше жағдайларды жою кезінде қызметтердің басымдықтарын, ресурстарға командалардың құқықтары мен квотасын көрсету қажеттілігі, ол бір бұлтта иерархиялық кезектерді пайдалану арқылы шешіледі.
- Жазатайым оқиғалар мен оқыс оқиғаларға жауап беру уақытын қысқарту үшін контейнерлерге адам атауын беру қажеттілігі
- Service Discovery бір реттік кеңінен енгізудің мүмкін еместігі; аппараттық хосттарда орналастырылған тапсырмалармен ұзақ уақыт бірге өмір сүру қажеттілігі - контейнерлерден кейінгі «статикалық» IP мекенжайлары арқылы шешілетін нәрсе және соның салдарынан үлкен желілік инфрақұрылыммен бірегей интеграция қажеттілігі.
Осы функциялардың барлығы бізге сәйкес келетін қолданыстағы шешімдерді айтарлықтай өзгертуді талап етеді және жұмыс көлемін бағалай отырып, біз шамамен бірдей еңбек шығындарымен өз шешімімізді жасай алатынымызды түсіндік. Бірақ сіздің шешіміңіз жұмыс істеу және дамыту әлдеқайда оңай болады - ол бізге қажет емес функционалдылықты қолдайтын қажетсіз абстракцияларды қамтымайды.
Соңғы жолдарды оқығандарға, шыдамдылығыңыз бен назарыңызға рахмет!
Ақпарат көзі: www.habr.com