🥇One-cloud - Одноклассникидеги маалымат борборунун деңгээлиндеги ОС

Аллох, адамдар! Менин атым Олег Анастасьев, мен Одноклассникиде Платформа командасында иштейм. Ал эми менден башка Одноклассникиде көптөгөн аппараттык каражаттар иштейт. Бизде 500 миңден ашык серверлери бар 8гө жакын стеллаждар менен төрт маалымат борбору бар. Белгилүү бир учурда биз жаңы башкаруу системасын киргизүү жабдууларды натыйжалуу жүктөөгө, жеткиликтүүлүктү башкарууну жеңилдетүүгө, эсептөө ресурстарын (кайра) бөлүштүрүүнү автоматташтырууга, жаңы кызматтарды ишке киргизүүнү тездетүүгө жана жоопторду тездетүүгө мүмкүндүк берерин түшүндүк. ири көлөмдөгү кырсыктарга.

Андан эмне келди?

Менден жана бир топ жабдыктардан тышкары, бул жабдыктар менен иштеген адамдар дагы бар: түздөн-түз маалымат борборлорунда жайгашкан инженерлер; тармактык программалык камсыздоону орноткон тармактык адистер; инфраструктуранын туруктуулугун камсыз кылган администраторлор же SREs; жана өнүктүрүү топтору, алардын ар бири порталдын функцияларынын бир бөлүгү үчүн жооптуу. Алар түзгөн программалык камсыздоо төмөнкүдөй иштейт:

Колдонуучулардын суроо-талаптары негизги порталдын эки жагында тең кабыл алынат www.ok.ru, жана башкалар боюнча, мисалы, музыка API фронтторунда. Бизнес логикасын иштетүү үчүн алар өтүнмөнүн серверин чакырышат, ал суроо-талапты иштеп чыгууда керектүү адистештирилген микросервистерди - бир графикти (социалдык байланыштардын графигин), колдонуучу-кэшти (колдонуучу профилдердин кэш) ж.б.

Бул кызматтардын ар бири көптөгөн машиналарда жайгаштырылган жана алардын ар биринде модулдардын иштеши, алардын иштеши жана технологиялык өнүгүүсү үчүн жооптуу иштеп чыгуучулар бар. Бул кызматтардын баары аппараттык серверлерде иштейт жана жакында эле биз ар бир серверге бир тапшырманы ишке киргиздик, б.а. ал белгилүү бир тапшырма үчүн адистешкен.

Эмнеге андай? Бул ыкма бир нече артыкчылыктарга ээ болгон:

Жеңилди массалык башкаруу. Тапшырма кээ бир китепканаларды, кээ бир орнотууларды талап кылат дейли. Андан кийин сервер так бир белгилүү топко дайындалат, бул топ үчүн cfengine саясаты сүрөттөлөт (же ал буга чейин сүрөттөлгөн) жана бул конфигурация борборлоштурулган жана автоматтык түрдө ушул топтун бардык серверлерине жайылтылат.
Жөнөкөйлөштүрүлгөн диагноз. Келгиле, сиз борбордук процессорго жүктөмдүн жогорулашын карап, бул жүктү ушул аппараттык процессордо иштеген тапшырма гана түзө аларын түшүндүңүз дейли. Күнөөлүү адамды издөө абдан бат бүтөт.
Жөнөкөйлөштүрүлгөн боюнча. Серверде бир нерсе туура эмес болсо, монитор бул тууралуу кабарлайт жана сиз ким күнөөлүү экенин так билесиз.

Бир нече репликалардан турган кызматка бир нече серверлер бөлүнгөн - ар бири үчүн бирден. Андан кийин кызмат үчүн эсептөө ресурсу абдан жөнөкөй бөлүштүрүлөт: кызмат бар серверлердин саны, ал керектей турган ресурстардын максималдуу көлөмү. Бул жерде "оңой" колдонуу оңой дегенди билдирбейт, бирок ресурстарды бөлүштүрүү кол менен жасалат деген мааниде.

Бул ыкма бизге да мумкундук берди атайын темир конфигурациялары бул серверде иштеген тапшырма үчүн. Эгерде тапшырма чоң көлөмдөгү маалыматтарды сактаса, анда биз 4 диски бар шасси менен 38U серверин колдонобуз. Эгерде тапшырма таза эсептөөчү болсо, анда биз арзаныраак 1U серверди сатып алсак болот. Бул эсептөө натыйжалуу. Башка нерселер менен катар, бул ыкма бизге бир достук коомдук тармакка салыштырылат жүк менен төрт эсе аз машиналарды колдонууга мүмкүндүк берет.

Эсептөө ресурстарын пайдалануунун мындай эффективдүүлүгү, эгерде биз эң кымбат нерсе – серверлер деген негизден чыга турган болсок, экономикалык эффективдүүлүктү да камсыз кылууга тийиш. Узак убакыт бою аппараттык камсыздоо эң кымбат болгон жана биз аппараттык камсыздоонун ишенимдүүлүгүнө талаптарды төмөндөтүү үчүн каталарга чыдамдуулук алгоритмдерин ойлоп таап, аппараттык жабдыктын баасын төмөндөтүү үчүн көп күч жумшадык. Ал эми бүгүн биз сервердин баасы чечүүчү болбой калган этапка жеттик. Эгерде сиз акыркы экзотикаларды эске албасаңыз, анда стойкадагы серверлердин конкреттүү конфигурациясы маанилүү эмес. Эми бизде дагы бир көйгөй бар – сервер дата-борбордо ээлеген мейкиндиктин баасы, башкача айтканда, стойкадагы орун.

Ушундай экенин тушунуп, биз стеллаждарды канчалык натыйжалуу пайдаланып жатканыбызды эсептеп чыгууну чечтик.
Биз эң күчтүү сервердин баасын экономикалык жактан негиздүү болгондордон алдык, канча серверди стеллаждарга жайгаштыра аларыбызды, эски үлгүдөгү "бир сервер = бир тапшырма" боюнча аларда канча тапшырманы аткарарыбызды эсептеп чыктык. милдеттери жабдууларды колдоно алат. Эсептеп, көз жашын төгүштү. Стеллаждарды колдонуудагы эффективдүүлүгүбүз болжол менен 11% экени белгилүү болду. Жыйынтык ачык эле көрүнүп турат: биз маалымат борборлорун пайдалануунун натыйжалуулугун жогорулатуу керек. Чечим айкын көрүнүп турат: бир эле серверде бир нече тапшырманы аткаруу керек. Бирок мына ушул жерден кыйынчылыктар башталат.

Массалык конфигурация кескин түрдө татаалдашып баратат - азыр серверге бир топту дайындоо мүмкүн эмес. Анткени, азыр бир серверде ар кандай буйруктардын бир нече тапшырмаларын ишке киргизүүгө болот. Мындан тышкары, конфигурация ар кандай колдонмолор үчүн карама-каршы болушу мүмкүн. Диагноз дагы татаалдашат: эгер сиз серверде CPU же дисктин керектелиши көбөйүп жатканын көрсөңүз, кайсы тапшырма көйгөй жаратып жатканын билбейсиз.

Бирок, негизгиси, бир эле машинада иштеген милдеттердин ортосунда эч кандай изоляция жок. Бул жерде, мисалы, бир эле серверде башка эсептөө тиркемесин ишке киргизгенге чейин жана андан кийин сервердик тапшырманын орточо жооп берүү убактысынын графиги, биринчисине эч кандай тиешеси жок - негизги тапшырманын жооп берүү убактысы кыйла көбөйдү.

Албетте, сиз тапшырмаларды контейнерлерде же виртуалдык машиналарда аткарышыңыз керек. Биздин дээрлик бардык тапшырмаларыбыз бир OS (Linux) астында иштегендиктен же ага ылайыкташкандыктан, көптөгөн ар кандай операциялык системаларды колдоонун кереги жок. Демек, виртуалдаштыруунун кереги жок, кошумча чыгымдардан улам, контейнерлештирүү караганда натыйжалуураак болот.

Тапшырмаларды түздөн-түз серверлерде аткаруу үчүн контейнерлерди ишке ашыруу катары, Docker жакшы талапкер: файл тутумунун сүрөттөрү карама-каршы келген конфигурациялар менен көйгөйлөрдү жакшы чечет. Сүрөттөр бир нече катмардан турушу мүмкүн экендиги бизге жалпы бөлүктөрдү өзүнчө базалык катмарларга бөлүп, аларды инфраструктурага жайгаштыруу үчүн талап кылынган маалыматтардын көлөмүн олуттуу кыскартууга мүмкүндүк берет. Андан кийин негизги (жана эң көлөмдүү) катмарлар бүт инфраструктурада тез кэштелет жана ар кандай тиркемелерди жана версияларды жеткирүү үчүн кичинекей катмарларды гана өткөрүп берүү керек болот.

Мындан тышкары, даяр реестр жана Dockerдеги сүрөттөрдү белгилөө бизге версияларды түзүү жана кодду өндүрүшкө жеткирүү үчүн даяр примитивдерди берет.

Docker, башка ушул сыяктуу технологиялар сыяктуу эле, бизге кутудан тышкары контейнер изоляциясынын кандайдыр бир деңгээлин камсыз кылат. Мисалы, эстутум изоляциясы - ар бир контейнерге машинанын эс тутумун колдонууга чектөө берилет, андан тышкары ал керектебейт. Ошондой эле CPU колдонуунун негизинде контейнерлерди бөлүп алсаңыз болот. Бирок биз үчүн стандарттуу жылуулоо жетишсиз болчу. Бирок төмөндө бул тууралуу көбүрөөк.

Серверлерде контейнерлерди түздөн-түз иштетүү - бул көйгөйдүн бир бөлүгү. Башка бөлүгү серверлерде контейнерлерди жайгаштыруу менен байланышкан. Кайсы контейнерди кайсы серверге жайгаштырса болорун түшүнүшүңүз керек. Бул анчалык оңой иш эмес, анткени контейнерлерди серверлерге алардын ылдамдыгын азайтпастан, мүмкүн болушунча тыгыз жайгаштыруу керек. Мындай жайгаштыруу да катага чыдамкайлык жагынан кыйын болушу мүмкүн. Көбүнчө биз бир эле кызматтын репликаларын ар кандай стеллаждарга, жада калса дата-борбордун ар башка бөлмөлөрүнө жайгаштыргыбыз келет, андыктан стойка же бөлмө иштен чыгып калса, биз дароо бардык сервис репликаларын жоготуп албашыбыз үчүн.

8 миң сервер жана 8-16 миң контейнер болгондо контейнерлерди кол менен таратуу мүмкүн эмес.

Мындан тышкары, биз иштеп чыгуучуларга ресурстарды бөлүштүрүүдө көбүрөөк көз карандысыздык бергибиз келди, алар администратордун жардамысыз өз кызматтарын өндүрүштө өздөрү жайгаштыра алышат. Ошол эле учурда биз кээ бир майда кызматтар биздин маалымат борборлорубуздун бардык ресурстарын жеп албашы үчүн көзөмөлдү сактап калгыбыз келди.

Албетте, бизге муну автоматтык түрдө жасай турган башкаруу катмары керек.

Ошентип, биз бардык архитекторлор сүйгөн жөнөкөй жана түшүнүктүү сүрөткө келдик: үч чарчы.

бир булут мастерлери булуттун оркестри үчүн жооптуу иштебей калган кластер. Иштеп чыгуучу мастерге манифест жөнөтөт, анда кызматты өткөрүү үчүн зарыл болгон бардык маалыматтар камтылган. Анын негизинде мастер тандалган миниондорго (контейнерлерди иштетүү үчүн арналган машиналар) буйрук берет. Миниондордо биздин агент бар, ал команданы кабыл алат, анын буйруктарын 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

Колдонуучунун кэш кызматынын ресурстары өндүрүш инфраструктурасындагы бардык жеткиликтүү ресурстардын бир бөлүгүн гана керектейт. Ошондуктан, мен күтүлбөгөн жерден, оператордун катасынан улам же жокпу, колдонуучунун кэши ага бөлүнгөн ресурстардан көбүрөөк ресурстарды керектебей тургандыгын текшергим келет. Башкача айтканда, биз ресурстарды чектешибиз керек. Бирок биз квотаны эмнеге байлай алмакпыз?

Келгиле, компоненттердин өз ара аракеттешүүсүнүн абдан жөнөкөйлөштүрүлгөн диаграммасына кайрылып, аны көбүрөөк деталдар менен кайра сызып көрөлү - бул сыяктуу:

Сиздин көзүңүзгө эмне тийет:

Веб фронт менен музыка бир эле колдонмо серверинин обочолонгон кластерлерин колдонот.
Бул кластерлер таандык болгон логикалык катмарларды айырмалай алабыз: фронттор, кэштер, маалыматтарды сактоо жана башкаруу катмары.
Frontend гетерогендүү болуп саналат, ал ар кандай функционалдык подсистемалардан турат.
Кэштер маалыматын кэштеген подсистемага да чачырап кетиши мүмкүн.

Сүрөттү кайра тарталы:

Bah! Ооба, биз иерархияны көрүп жатабыз! Бул ресурстарды чоңураак бөлүктөргө бөлүштүрө аласыз дегенди билдирет: функционалдык подсистемага туура келген бул иерархиянын түйүнүнө жооптуу иштеп чыгуучуну дайындаңыз (сүрөттөгү "музыка" сыяктуу) жана иерархиянын ошол эле деңгээлине квота тиркеңиз. Бул иерархия ошондой эле башкаруунун жеңилдиги үчүн кызматтарды ийкемдүү уюштурууга мүмкүндүк берет. Мисалы, биз бардык вебди бөлөбүз, анткени бул серверлердин абдан чоң тобу, сүрөттө 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 керектөө үлгүсү болот:

Колдонуучудан суроо-талап иштетүү үчүн кабыл алынат, тапшырма бардык колдо болгон 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

Келгиле, тактык үчүн бардык изоляция деңгээлибизди бир таблицага жалпылайлы:

Жылуулоо классы
Alloc мисалы
Docker иштетүү параметрлери
sched_setscheduler chrt*

Prod
cpu = 4
--cpuquota=400000 --cpuperiod=100000
SCHED_OTHER

партия
CPU = [1, *)
--cpushares=1024
SCHED_BATCH

жалкоо
CPU= [2, *)
--cpushares=2048
SCHED_IDLE

*Эгер сиз контейнердин ичинен chrt кылып жатсаңыз, сизге sys_nice мүмкүнчүлүгү керек болушу мүмкүн, анткени демейки боюнча Docker контейнерди ишке киргизгенде бул мүмкүнчүлүктү алып салат.

Бирок тапшырмалар процессорду гана эмес, трафикти да керектейт, бул тармактык тапшырманын кечигүүсүнө процессордун ресурстарын туура эмес бөлүштүрүүдөн да көбүрөөк таасир этет. Ошондуктан, биз табигый жол кыймылы үчүн дал ушундай сүрөттү алууну каалайбыз. Башкача айтканда, өндүрүш тапшырмасы тармакка бир нече пакеттерди жөнөткөндө, биз максималдуу ылдамдыкты чектейбиз (formula бөлүштүрүү: lan=[*,500mbps) ), кайсы продукт муну жасай алат. Ал эми партия үчүн биз минималдуу өткөрүү жөндөмдүүлүгүнө гана кепилдик беребиз, бирок максимумга чек койбойбуз (формула бөлүштүрүү: lan=[10Mbps,*) ) Бул учурда прод трафиги пакеттик тапшырмаларга караганда артыкчылыкка ээ болушу керек.
Бул жерде Докерде биз колдоно турган примитивдер жок. Бирок ал бизге жардамга келет Linux Traffic Control. Тартиптин жардамы менен каалаган натыйжага жетише алдык Иерархиялык адилеттүү тейлөө ийри сызыгы. Анын жардамы менен биз трафиктин эки классын бөлөбүз: жогорку артыкчылыктуу продукт жана төмөнкү артыкчылыктуу партия/бос жүрүү. Натыйжада, чыгуучу трафиктин конфигурациясы төмөнкүдөй:

бул жерде 1:0 - hsfc дисциплинанын "тамыры qdisc"; 1:1 - hsfc бала классы, жалпы өткөрүү жөндөмдүүлүгү 8 Гбит/с чеги менен, анын астында бардык контейнерлердин бала класстары жайгаштырылат; 1:2 - hsfc бала классы төмөндө талкууланган "динамикалык" чеги бар бардык партия жана бош турган тапшырмалар үчүн жалпы болуп саналат. Калган hsfc бала класстары алардын манифесттерине - 450 жана 400 Мбит/с чегинде иштеп жаткан өндүрүш контейнерлери үчүн арналган класстар. Ар бир hsfc классына Linux ядросунун версиясына жараша qdisc кезеги fq же fq_codel ыйгарылган, трафиктин жарылуусу учурунда пакеттин жоголушуна жол бербөө үчүн.

Адатта, tc дисциплиналары бир гана чыгуучу трафикке артыкчылык берет. Бирок биз кирүүчү трафикке да артыкчылык бергибиз келет - баары бир, кээ бир партия тапшырмасы, мисалы, карта жана кыскартуу үчүн киргизилген маалыматтардын чоң партиясын кабыл алып, бүт кирген каналды оңой эле тандап алат. Бул үчүн биз модулду колдонобуз ifb, ал ар бир тармак интерфейси үчүн ifbX виртуалдык интерфейсин түзөт жана кирүүчү трафикти интерфейстен ifbXдеги чыгуучу трафикке багыттайт. Андан тышкары, ifbX үчүн, бардык эле дисциплиналар чыгуучу трафикти көзөмөлдөө үчүн иштейт, алар үчүн hsfc конфигурациясы абдан окшош болот:

Эксперименттердин жүрүшүндө биз hsfc 1:2 класстагы приоритеттүү эмес партия/бос трафик минион машиналарында белгилүү бир бош тилкеден ашпаганга чектелгенде эң жакшы натыйжаларды көрсөтөөрүн билдик. Болбосо, приоритеттүү эмес трафик өндүрүш тапшырмаларынын кечигүүсүнө өтө көп таасир этет. miniond берилген миниондун бардык прод-милдеттеринин орточо трафикти керектөөсүн өлчөө менен секунд сайын бош өткөрүү жөндөмдүүлүгүнүн учурдагы көлөмүн аныктайт. жана аны тармак интерфейсинин өткөрүү жөндөмдүүлүгүнөн алып салуу кичинекей маржа менен, б.а.

Жолдор кирүүчү жана чыгуучу трафик үчүн өз алдынча аныкталат. Жана жаңы баалуулуктарга ылайык, miniond 1:2 артыкчылыктуу эмес класс чегин кайра конфигурациялайт.

Ошентип, биз изоляциянын үч классын тең ишке ашырдык: өндүрүш, партия жана бош. Бул класстар тапшырмалардын аткаруу мүнөздөмөлөрүнө чоң таасир этет. Ошондуктан, биз бул атрибутту иерархиянын эң жогору жагына коюуну чечтик, ошондуктан иерархиялык кезектин атын карап жатканда биз эмне менен алектенип жатканыбыз дароо айкын болот:

Биздин бардык досторубуз желе и музыка фронттор прод астындагы иерархияга жайгаштырылат. Мисалы, пакеттин астында кызматты жайгаштыралы музыка каталогу, ал мезгил-мезгили менен Одноклассникиге жүктөлгөн mp3 файлдардын топтомунан тректердин каталогун түзөт. Бош турган кызматтын мисалы болот музыкалык трансформатормузыканын көлөмүн нормалдаштырат.

Кошумча сызыктар кайра алынып салынса, кызматтын аталышын толук кызматтын атын аягына чейин изоляциялоо классын кошуп, кызмат көрсөтүүлөрүбүздүн аттары жалпак жаза алабыз: web.front.prod, catalog.music.batch, transformator.music.idle.

Ал эми азыр, кызматтын атын карап, биз ал кандай функцияны аткарарын гана эмес, ошондой эле анын обочолонуу классын түшүнөбүз, бул анын критикалык маанисин ж.б.

Баары сонун, бирок бир ачуу чындык бар. Бир машинада иштеген тапшырмаларды толугу менен обочолонтуу мүмкүн эмес.

Биз эмнеге жетише алдык: эгерде партия интенсивдүү керектесе гана CPU ресурстары, анда орнотулган Linux CPU пландаштыргычы өз ишин абдан жакшы аткарат жана өндүрүш тапшырмасына дээрлик эч кандай таасири жок. Бирок бул партия тапшырмасы эс менен жигердүү иштей баштаса, анда өз ара таасир эбак эле пайда болот. Бул өндүрүш тапшырмасы процессордун эс тутум кэштеринен “жуулуп” кеткендиктен болот – натыйжада кэш өткөрүп жиберүүлөрү көбөйүп, процессор өндүрүш тапшырмасын жайыраак иштетет. Мындай партия тапшырмасы биздин типтүү продукт контейнерибиздин күтүү убактысын 10% га жогорулата алат.

Заманбап тармактык карталарда пакеттердин ички кезеги бар болгондуктан, трафикти изоляциялоо дагы кыйыныраак. Эгерде пакеттик тапшырманын пакети алгач ошол жерге жетсе, анда ал биринчи болуп кабель аркылуу берилет жана бул тууралуу эч нерсе кыла албайт.

Мындан тышкары, биз азырынча TCP трафигине артыкчылык берүү маселесин чече алдык: hsfc ыкмасы UDP үчүн иштебейт. Жана TCP трафигинде да, эгерде партия тапшырмасы көп трафикти жаратса, бул өндүрүш тапшырмасынын кечигүүсүнүн болжол менен 10% га көбөйүшүн берет.

катага сабырдуулук

Бир булутту иштеп чыгуудагы максаттардын бири Одноклассникинин каталарга чыдамдуулугун жогорулатуу болгон. Ошондуктан, мен дагы майда-чүйдөсүнө чейин мүмкүн болгон каталар жана кырсыктардын сценарийлерин карап көргүм келет. Келгиле, жөнөкөй сценарийден баштайлы - контейнердин бузулушу.

Контейнердин өзү бир нече жол менен иштебей калышы мүмкүн. Бул манифесттеги кандайдыр бир эксперимент, мүчүлүштүк же ката болушу мүмкүн, анын натыйжасында өндүрүш тапшырмасы манифестте көрсөтүлгөндөн көбүрөөк ресурстарды керектей баштайт. Бизде мындай окуя болгон: иштеп чыгуучу бир татаал алгоритмди ишке ашырып, аны көп жолу кайра иштеп чыгып, өзүн ашыкча ойлонуп, ушунчалык чаташып калгандыктан, акырында маселе өтө маанилүү эмес циклге өтүп кеткен. Жана продюсердик тапшырма ошол эле миниондордогу бардык башкаларга караганда артыкчылыктуу болгондуктан, ал бардык колдо болгон процессор ресурстарын жей баштады. Бул кырдаалда изоляция, тагыраак айтканда, CPU убактысынын квотасы күндү сактап калды. Эгерде тапшырмага квота бөлүнсө, тапшырма ашыкча керектелбейт. Ошондуктан, бир эле машинада иштеген партия жана башка продикалык тапшырмалар эч нерсени байкаган жок.

Экинчи мүмкүн болгон көйгөй - контейнердин кулап калышы. Жана бул жерде кайра баштоо саясаттары бизди сактап калат, аларды баары билет, Докердин өзү сонун иш кылат. Дээрлик бардык өндүрүш тапшырмаларында ар дайым кайра баштоо саясаты бар. Кээде биз on_failure функциясын пакеттик тапшырмалар үчүн же өндүрүш контейнерлерин оңдоо үчүн колдонобуз.

Бүтүндөй минион жеткиликсиз болсо, эмне кыла аласыз?

Албетте, контейнерди башка машинада иштетиңиз. Бул жерде кызыктуу бөлүгү контейнерге дайындалган IP даректери менен эмне болот.

Биз контейнерлерге ушул контейнерлер иштеген минион машиналары сыяктуу эле IP даректерди дайындай алабыз. Андан кийин, контейнер башка машинада ишке киргизилгенде, анын IP дареги өзгөрөт жана бардык кардарлар контейнер көчүп кеткенин түшүнүшү керек, эми алар башка дарекке барышы керек, ал үчүн өзүнчө Service Discovery кызматы талап кылынат.

Кызматтын ачылышы ыңгайлуу. Кызмат реестрин уюштуруу үчүн рыногунда катачылыкка чыдамдуулуктун ар кандай деңгээлдеги көптөгөн чечимдери бар. Көбүнчө мындай чечимдер жүк балансынын логикасын ишке ашырат, КВ сактагыч түрүндө кошумча конфигурацияны сактайт ж.б.
Бирок, биз өзүнчө реестрди ишке ашыруунун зарылдыгынан алыс болгубуз келет, анткени бул өндүрүштө бардык кызматтар тарабынан колдонулуучу критикалык системаны киргизүүнү билдирет. Демек, бул мүмкүн болуучу ийгиликсиз чекит жана сиз катага чыдамдуу чечимди тандап же иштеп чыгышыңыз керек, бул албетте абдан кыйын, көп убакытты жана кымбат.

Жана дагы бир чоң кемчилик: эски инфраструктурабыз жаңысы менен иштеши үчүн, кандайдыр бир Service Discovery тутумун колдонуу үчүн бардык тапшырмаларды кайра жазууга туура келет. КӨП иш бар, кээ бир жерлерде OS ядро деңгээлинде же түз аппараттык камсыздоо менен иштеген төмөнкү деңгээлдеги түзмөктөргө келгенде дээрлик мүмкүн эмес. Белгиленген чечим үлгүлөрүн колдонуу менен бул функцияны ишке ашыруу, мисалы капталдагы унаа кээ бир жерлерде кошумча жүктөмдү, башкаларында - операциянын татаалданышын жана кошумча бузулуу сценарийлерин билдирет. Биз нерселерди татаалдаштыргыбыз келген жок, ошондуктан Кызматтын ачылышын ыктыярдуу колдонууну чечтик.

Бир булутта 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 же Кызматтын ачылышын камтыбайт, бул маалыматтын актуалдуулугун жана бул системалардын каталарына чыдамдуулугун камсыз кылууда эч кандай кыйын көйгөйлөр жок дегенди билдирет. Андан тышкары, бүткүл порталдын иштеши көз каранды болгон маанилүү кызматтарда биз 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 буга чейин 1.1.1.1 дарегин MED менен жарнамалоо буйругун алат = 999 999. М1де иштеген инстанция ошол бойдон кала берет, бул учурда эч кандай байланыш жок жана анын мындан аркы тагдыры бизди кожоюн менен байланыш калыбына келтирилмейинче, ал эски тартып калгандай токтоп калганга чейин кызыктырбайт.

кырсыктар

Бардык маалымат борбору башкаруу системалары ар дайым алгылыктуу түрдө майда каталарды чечет. Контейнердин толуп кетиши дээрлик бардык жерде норма болуп саналат.

Келгиле, маалымат борборунун бир же бир нече бөлмөсүндө электр жарыгы үзгүлтүккө учурашы сыяктуу өзгөчө кырдаалды кантип чечкенибизди карап көрөлү.

Кырсык маалымат борборун башкаруу системасы үчүн эмнени билдирет? Биринчиден, бул көптөгөн машиналардын массалык бир жолку бузулушу жана башкаруу системасы бир эле учурда көп контейнерлерди көчүрүү керек. Бирок кырсык өтө масштабдуу болсо, анда бардык тапшырмаларды башка миниондорго кайра бөлүштүрүү мүмкүн эмес, анткени маалымат борборунун ресурстук кубаттуулугу жүктүн 100% дан төмөн түшүп калат.

Көбүнчө авариялар башкаруу катмарынын иштен чыгышы менен коштолот. Бул анын жабдыктарынын иштебей калышынан улам болушу мүмкүн, бирок көбүнчө авариялар текшерилбегендиктен жана башкаруу катмарынын өзү жүктүн жогорулашынан улам түшүп калат.

Мунун баарын эмне кыла аласың?

Массалык миграция инфраструктурада көп сандагы иш-аракеттердин, миграциянын жана жайылтуулардын бар экендигин билдирет. Миграциялардын ар бири контейнердин сүрөттөрүн миниондорго жеткирүү жана таңгактан чыгаруу, контейнерлерди ишке киргизүү жана инициализациялоо ж.б. үчүн бир аз убакыт талап кылынышы мүмкүн. Ошондуктан, маанилүүрөөк иштердин анча маанилүү эместеринен мурун башталышы керек.

Келгиле, бизге тааныш кызматтардын иерархиясын кайрадан карап көрөлү жана кайсы тапшырмаларды биринчи аткаргыбыз келгенин чечүүгө аракет кылалы.

Албетте, бул колдонуучулардын суроо-талаптарын иштетүүгө түздөн-түз катышкан процесстер, б.а. менен муну билдиребиз жайгаштыруу артыкчылык — кезекке бериле турган номер. Эгерде кезек жогорураак артыкчылыкка ээ болсо, анын кызматтары биринчи орунга коюлат.

Продукция боюнча биз жогорураак артыкчылыктарды беребиз, 0; партияда - бир аз төмөн, 100; бош турганда - андан да төмөн, 200. Приоритеттер иерархиялык түрдө колдонулат. Иерархияда төмөн турган бардык тапшырмалар тиешелүү артыкчылыкка ээ болот. Эгерде биз проддун ичиндеги кэштердин фронтондордон мурун ишке киришин кааласак, анда биз приоритеттерди кэш = 0 жана алдыңкы субкезектерге = 1 дайындайбыз. Эгер, мисалы, биз негизги порталдын алгач фронттордон, ал эми музыкалык фронттон гана ишке киришин кааласак. анда биз экинчисине төмөнкү артыкчылыкты бере алабыз - 10.

Кийинки көйгөй - ресурстардын жетишсиздиги. Ошентип, көп сандагы жабдуулар, маалымат борборунун бүтүндөй залдары иштебей калды жана биз ушунчалык көп кызматтарды кайра ишке киргиздик, азыр бардыгы үчүн ресурстар жетишсиз. Негизги маанилүү кызматтардын иштеши үчүн кайсы тапшырмаларды курмандыкка чалууну чечишиңиз керек.

Орнотуунун приоритетинен айырмаланып, биз бардык партия тапшырмаларын ылгабай курмандыкка бере албайбыз; алардын айрымдары порталдын иштеши үчүн маанилүү. Ошондуктан, биз өзүнчө баса белгиледик алдын ала артыкчылык милдеттер. Орнотулганда, артыкчылыгы жогору болгон тапшырманы алдын ала алат, башкача айтканда, эгерде бош миниондор жок болсо, төмөнкү артыкчылыктуу тапшырманы токтото алат. Бул учурда, аз артыкчылыктуу тапшырма, балким, орунсуз кала берет, башкача айтканда, мындан ары ага жетиштүү бош ресурстары бар ылайыктуу минион болбойт.

Биздин иерархиябызда 200гө барабар бош жүрүү үчүн артыкчылыкты көрсөтүү менен өндүрүш жана партия тапшырмалары бири-бирин эмес, бош турган тапшырмаларды алдын ала же токтото тургандай артыкчылыктуу артыкчылыкты көрсөтүү абдан жөнөкөй. татаал эрежелерди сүрөттөө үчүн биздин иерархияны колдоно алат. Мисалы, негизги веб-портал үчүн жетиштүү ресурстарыбыз жок болсо, музыкалык функцияны курмандыкка чалабыз деп көрсөтөлү, тиешелүү түйүндөр үчүн артыкчылыкты төмөнкүгө коюп: 10.

Бүтүндөй DC кырсыктары

Эмне үчүн бүт маалымат борбору иштебей калышы мүмкүн? Элемент. Жакшы пост болуптур бороон маалымат борборунун ишине таасирин тийгизген. Элементтер бир жолу коллектордо оптика күйүп кеткен селсаяктар деп эсептесе болот, ал эми маалымат борбору башка сайттар менен байланышты толугу менен жоготкон. Иштен чыгуунун себеби адам фактору да болушу мүмкүн: оператор бүт маалымат борбору кулап кала тургандай буйрук берет. Бул чоң катадан улам болушу мүмкүн. Жалпысынан алганда, маалымат борборлорунун кыйрашы сейрек эмес. Бул бизде бир нече айда бир жолу болот.

Жана бул биз кимдир бирөө #alive твиттер калтырбоо үчүн эмне кылабыз.

Биринчи стратегия - изоляция. Ар бир булуттук инстанция обочолонгон жана машиналарды бир гана маалымат борборунда башкара алат. Башкача айтканда, мүчүлүштүктөрдөн же оператордун туура эмес буйруктарынан улам булуттун жоголушу бир гана маалымат борборунун жоголушу болуп саналат. Биз буга даярбыз: бизде резервдик саясат бар, анда тиркеменин көчүрмөлөрү жана маалыматтар бардык маалымат борборлорунда жайгашкан. Биз каталарга чыдамдуу маалымат базаларын колдонобуз жана каталарды мезгил-мезгили менен текшеребиз.
Бүгүнкү күндө бизде төрт маалымат борбору бар, бул бир булуттун төрт өзүнчө, толугу менен обочолонгон учурларын билдирет.

Бул ыкма физикалык катадан гана коргобостон, оператордун катасынан да коргой алат.

Адам фактору менен дагы эмне кылса болот? Оператор булутка кандайдыр бир кызыктай же потенциалдуу кооптуу буйрук бергенде, күтүлбөгөн жерден анын канчалык жакшы ойлогондугун көрүү үчүн кичинекей маселени чечүү суралышы мүмкүн. Мисалы, эгерде бул көптөгөн репликаларды массалык түрдө токтотуу же жөн эле кызыктай буйрук болсо - жаңы манифесттеги версия номерин эле эмес, репликалардын санын азайтуу же сүрөттүн атын өзгөртүү.

натыйжалары

Бир булуттун айырмалоочу белгилери:

Кызматтар жана контейнерлер үчүн иерархиялык жана визуалдык аталыш схемасы, бул тапшырма эмне экенин, анын эмнеге тиешелүү экенин жана ал кандайча иштээрин жана ага ким жооп берерин тезирээк билүүгө мүмкүндүк берет.
Биз өзүбүздүн продукцияны жана партияны айкалыштыруу ыкмасымашиналарды пай-далануунун эффективдуулугун жогорулатуу боюнча миниондорго милдеттер. Процессордун ордуна биз CPU квотасын, үлүштөрүн, CPU пландоочу саясаттарын жана Linux QoS колдонобуз.
Бир эле машинада иштеген контейнерлерди толугу менен изоляциялоо мүмкүн болгон жок, бирок алардын өз ара таасири 20% чегинде калууда.
Кызматтарды иерархияга уюштуруу кырсыктан автоматтык түрдө калыбына келтирүүгө жардам берет жайгаштыруу жана артыкчылыктар.

FAQ

Эмне үчүн биз даяр чечим кабыл алган жокпуз?

Тапшырма изоляциясынын ар кандай класстары миниондорго коюлганда ар кандай логиканы талап кылат. Эгерде өндүрүштүк тапшырмаларды жөн гана ресурстарды резервдөө жолу менен коюуга мүмкүн болсо, анда минион машиналарында ресурстардын иш жүзүндө колдонулушуна көз салып, партиялык жана бош турган тапшырмалар коюлушу керек.
Төмөнкү сыяктуу милдеттерди талап кылган ресурстарды эске алуу зарылчылыгы:
- тармак өткөрүү жөндөмдүүлүгү;
- дисктердин түрлөрү жана "шпинделдери".
Өзгөчө кырдаалдардын кесепеттерин жоюу учурунда кызматтардын артыкчылыктарын, бир булуттагы иерархиялык кезектерди колдонуу менен чечилүүчү ресурстар үчүн командалардын укуктарын жана квоталарын көрсөтүү зарылдыгы.
Кырсыктарга жана инциденттерге жооп берүү убактысын кыскартуу үчүн контейнерлерге адамдын аталышы керек
Кызматтын ачылышын бир жолку кеңири жайылтуунун мүмкүн эместиги; аппараттык хосттордо жайгаштырылган тапшырмалар менен узак убакыт бою бирге жашоо зарылчылыгы - контейнерлерден кийинки "статикалык" IP даректер менен чечилүүчү нерсе, жана натыйжада чоң тармактык инфраструктура менен уникалдуу интеграциянын зарылдыгы.

Бул функциялардын бардыгы бизге ылайыктуу болгон чечимдерди олуттуу өзгөртүүнү талап кылат жана иштин көлөмүнө баа берип, биз болжол менен бирдей эмгек чыгымдары менен өзүбүздүн чечимибизди иштеп чыга аларыбызды түшүндүк. Бирок сиздин чечимиңизди иштетүү жана иштеп чыгуу бир топ жеңил болот - анда бизге кереги жок функцияларды колдогон керексиз абстракциялар жок.

Акыркы саптарды окугандарга сабырдуулугуңуз жана көңүл бурганыңыз үчүн рахмат!

Source: www.habr.com

Бир булут - Одноклассникидеги маалымат борборунун деңгээлиндеги ОС