Салам, Хабр! Мен Артем Карамышев, системалык администрациянын командасынын жетекчисимин . Акыркы бир жылда биз көптөгөн жаңы продукцияларды чыгардык. Биз API кызматтары оңой масштабда, каталарга чыдамдуу жана колдонуучунун жүктөмүнүн тез өсүшүнө даяр болгубуз келди. Биздин платформа OpenStack'те ишке ашырылган жана мен сизге катага чыдамдуу системаны алуу үчүн кандай компоненттердин катачылыкка чыдамдуу көйгөйлөрүн чечүү керектигин айткым келет. Бул OpenStackте өнүмдөрдү иштеп чыккандар үчүн кызыктуу болот деп ойлойм.
Платформанын жалпы катачылыкка чыдамкайлыгы анын компоненттеринин туруктуулугунан турат. Ошентип, биз тобокелдиктерди аныктап, аларды жапкан бардык деңгээлдерден акырындык менен өтөбүз.
Бул окуянын видео версиясы, анын негизги булагы Uptime day 4 конференциясындагы отчет болгон, тарабынан уюштурулган , Карасам болобу .
Физикалык архитектуранын туруктуулугу
MCS булутунун коомдук бөлүгү азыр эки Tier III маалымат борборлорунда негизделген, алардын ортосунда физикалык деңгээлде ар кандай маршруттар боюнча сакталган, 200 Гбит/с өткөрүү жөндөмдүүлүгү бар өзүнүн кара буласы бар. III деңгээл физикалык инфраструктура үчүн кемчиликтерге чыдамдуулуктун зарыл деңгээлин камсыз кылат.
Кара жипче физикалык жана логикалык деңгээлде сакталат. Каналдарды ээлөө процесси кайталанма болду, көйгөйлөр пайда болду жана биз маалымат борборлорунун ортосундагы байланышты дайыма жакшыртып жатабыз.
Маселен, жакында эле маалымат борборлорунун биринин жанындагы скважинада иштеп жүрүп экскаватор түтүктү үзүп, бул түтүктүн ичинде магистралдык да, резервдик да оптикалык кабель болгон. Дата борбору менен катачылыкка чыдамдуу байланыш каналыбыз бир учурда, скважинада аялуу болуп чыкты. Ошого жараша инфраструктуранын бир бөлүгүнөн ажырап калдык. Биз жыйынтык чыгарып, бир катар иш-аракеттерди жасадык, анын ичинде жанаша жайгашкан скважинага кошумча оптика орноттук.
Дата борборлорунда биздин префикстерди BGP аркылуу тараткан байланыш провайдерлери бар пункттар бар. Тармактын ар бир багыты үчүн эң мыкты метрика тандалып алынат, бул ар кандай кардарларга эң жакшы байланыш сапаты менен камсыз кылууга мүмкүндүк берет. Эгерде бир провайдер аркылуу байланыш үзүлсө, биз маршрутубузду жеткиликтүү провайдерлер аркылуу калыбына келтиребиз.
Эгерде провайдер иштебей калса, биз автоматтык түрдө кийинкиге которулабыз. Дата борборлорунун бири иштен чыкса, бизде экинчи дата борборунда биздин кызматтардын күзгү көчүрмөсү бар, алар бүт жүктү өзүнө алат.
Физикалык инфраструктуранын туруктуулугу
Колдонмо деңгээлиндеги каталарга чыдамдуулук үчүн эмнени колдонобуз
Биздин кызмат бир катар ачык булак компоненттеринин негизинде курулган.
ExaBGP BGP негизиндеги динамикалык маршруттоо протоколун колдонуу менен бир катар функцияларды ишке ашырган кызмат. Биз аны колдонуучулар API'ге кире турган ак тизмедеги IP даректерибизди жарнамалоо үчүн активдүү колдонобуз.
HAProxy - бул OSI моделинин ар кандай деңгээлдеринде өтө ийкемдүү трафиктин тең салмактуу эрежелерин конфигурациялоого мүмкүндүк берүүчү жогорку жүктөмдүү баланстоочу. Биз аны бардык кызматтардын алдында тең салмактуулук үчүн колдонобуз: маалымат базалары, билдирүү брокерлери, API кызматтары, веб кызматтары, биздин ички долбоорлорубуз - баары HAProxy артында турат.
API колдонмосу — колдонуучу өзүнүн инфраструктурасын жана кызматын башкарган python тилинде жазылган веб-тиркеме.
Жумушчу колдонмосу (мындан ары жөнөкөй жумушчу) - OpenStack кызматтарында бул инфраструктурага API буйруктарын таратууга мүмкүндүк берген инфраструктуралык демон. Мисалы, дискти түзүү жумушчуда, ал эми түзүү өтүнүчү API колдонмосунда пайда болот.
Стандарттык OpenStack колдонмо архитектурасы
OpenStack үчүн иштелип чыккан кызматтардын көбү бир парадигманы карманууга аракет кылышат. Кызмат адатта 2 бөлүктөн турат: API жана жумушчулар (backend аткаруучулар). Эреже катары, API – бул көз карандысыз процесс (демон) катары же даяр Nginx же Apache веб-серверин колдонуу менен ишке киргизилген python тилиндеги WSGI тиркемеси. API колдонуучунун өтүнүчүн иштеп чыгат жана андан аркы нускамаларды аткаруу үчүн жумушчу колдонмосуна өткөрүп берет. Которуу билдирүү брокери аркылуу ишке ашат, адатта, RabbitMQ, башкалары начар колдоого алынат. Билдирүүлөр брокерге жеткенде, алар жумушчулар тарабынан иштелип чыгат жана зарыл болсо, жооп кайтарат.
Бул парадигма обочолонгон жалпы кемчиликтерди камтыйт: RabbitMQ жана маалымат базасы. Бирок RabbitMQ бир кызматтын ичинде обочолонгон жана теориялык жактан алганда, ар бир кызмат үчүн жеке болушу мүмкүн. Ошентип, MCSте биз бул кызматтарды мүмкүн болушунча бөлүп, ар бир жеке долбоор үчүн өзүнчө маалымат базасын, өзүнчө RabbitMQ түзөбүз; Мындай мамиле жакшы, анткени кээ бир аялуу пункттарда авария болгондо бүтүндөй кызмат эмес, анын бир бөлүгү гана бузулат.
Жумушчу тиркемелеринин саны чексиз, андыктан API натыйжалуулугун жана катага чыдамдуулугун жогорулатуу үчүн балансчылардын артына горизонталдуу масштабда оңой эле масштабдана алат.
Кээ бир кызматтар API менен жумушчулардын ортосунда татаал ырааттуу операциялар болгондо кызматтын ичинде координациялоону талап кылат. Бул учурда, бирдиктүү координациялык борбор колдонулат, Redis, Memcache ж.б.у.с. сыяктуу кластердик система, бул бир жумушчуга экинчисине бул милдет ага жүктөлгөндүгүн айтууга мүмкүндүк берет («сураныч, аны кабыл албаңыз»). Биз ж.б. колдонобуз. Эреже катары, жумушчулар маалымат базасы менен активдүү байланышып, ал жерден маалыматты жазып, окушат. Биз multimaster кластеринде жайгашкан маалымат базасы катары mariadb колдонобуз.
Бул классикалык бирдиктүү кызмат OpenStack үчүн жалпы кабыл алынган тартипте уюштурулган. Бул жабык система катары каралышы мүмкүн, ал үчүн масштабдуу жана катачылыкка чыдамкайлык ыкмалары абдан ачык. Мисалы, API катачылыкка чыдамдуулук үчүн, алардын алдына тең салмактуулукту коюу жетиштүү. Жумушчулардын санын көбөйтүү менен жетишилет.
Бардык схеманын алсыз жери - RabbitMQ жана MariaDB. Алардын архитектурасы өзүнчө макалага татыктуу.
Openstack колдонмо архитектурасы. Булут платформасынын тең салмактуулугу жана катага чыдамдуулугу
ExaBGP аркылуу HAProxy баланстарын катага чыдамдуу кылуу
API'лерибизди масштабдуу, тез жана каталарга чыдамдуу кылуу үчүн, биз алардын алдына жүк балансын койдук. Биз HAProxy тандадык. Менин оюмча, ал биздин милдетибиз үчүн бардык зарыл мүнөздөмөлөргө ээ: бир нече OSI деңгээлдеринде тең салмактуулук, башкаруу интерфейси, ийкемдүүлүк жана масштабдуулук, көп сандагы тең салмактуулук ыкмалары, сессия таблицаларын колдоо.
Чечилиши керек болгон биринчи маселе - бул балансизатордун катачылыкка чыдамкайлыгы. Жөн эле баланстоочуну орнотуу да иштебей калуу учурун жаратат: балансизатор бузулуп, кызмат бузулат. Мунун алдын алуу үчүн биз HAProxyди ExaBGP менен бирге колдондук.
ExaBGP сизге кызматтын абалын текшерүү механизмин ишке ашырууга мүмкүндүк берет. Биз бул механизмди HAProxy функциясын текшерүү үчүн колдондук жана көйгөйлөр жаралса, BGPден HAProxy кызматын өчүрүп салдык.
ExaBGP+HAProxy схемасы
- Биз керектүү программалык камсыздоону, ExaBGP жана HAProxyди үч серверге орнотобуз.
- Биз серверлердин ар биринде цикл интерфейсин түзөбүз.
- Бардык үч серверде биз бул интерфейске бирдей ак IP даректи дайындайбыз.
- Ак IP дареги ExaBGP аркылуу Интернетке жарыяланат.
Мүчүлүштүккө толеранттуулук үч серверден бирдей IP даректи жарнамалоо аркылуу ишке ашат. Тармактын көз карашынан алганда, бир эле дарекке үч башка кийинки хоп аркылуу жетүүгө болот. Маршрутизатор үч окшош маршрутту көрөт, өзүнүн метрикасынын негизинде алардын эң жогорку приоритеттерин тандайт (бул көбүнчө бир эле вариант) жана трафик серверлердин бирине гана өтөт.
HAProxy же сервердин иштебей калышына байланыштуу көйгөйлөр пайда болгон учурда, ExaBGP маршрутту жарыялоону токтотот жана трафик башка серверге жайбаракат өтөт.
Ошентип, биз балансизатордун катачылыкка чыдамдуулугуна жетиштик.
HAProxy баланстоочуларынын каталарына чыдамдуулук
Схема жеткилеңсиз болуп чыкты: биз HAProxy кантип резервдештирүү керектигин үйрөндүк, бирок кызматтардын ичинде жүктү бөлүштүрүүнү үйрөнгөн жокпуз. Ошондуктан, биз бул схеманы бир аз кеңейттик: биз бир нече ак IP даректердин ортосунда балансташтырууга өттүк.
DNS плюс BGP негизинде баланстоо
Биздин HAProxy үчүн жүктү теңдөө маселеси чечиле элек. Бирок, биз бул жерде кылгандай, абдан жөнөкөй эле чечсе болот.
Үч серверди тең салмактоо үчүн сизге 3 ак IP даректер жана жакшы эски DNS керек болот. Бул даректердин ар бири ар бир HAProxy'дин кайра цикл интерфейсинде аныкталат жана Интернетке жарыяланды.
OpenStack'те ресурстарды башкаруу үчүн, белгилүү бир кызматтын акыркы чекитинин API'син көрсөткөн кызмат каталогу колдонулат. Бул каталогдо биз домендик аталышты каттайбыз - public.infra.mail.ru, ал DNS аркылуу үч түрдүү IP даректер аркылуу чечилет. Натыйжада, биз DNS аркылуу үч дарек ортосунда жүк бөлүштүрүүнү алабыз.
Бирок ак IP даректерди жарыялоодо биз серверди тандоо приоритеттерин көзөмөлдөбөйбүз, бул азырынча теңдеше элек. Адатта, бир гана сервер IP дарегинин стажынын негизинде тандалат, ал эми калган экөө бош болот, анткени BGPде эч кандай көрсөткүчтөр көрсөтүлбөйт.
Биз ExaBGP аркылуу ар кандай көрсөткүчтөр менен маршруттарды жөнөтө баштадык. Ар бир баланстоочу бардык үч ак IP даректерди жарнамалайт, бирок алардын бири, бул баланстоочу үчүн эң негизгиси, минималдуу метрика менен жарнамаланат. Ошентип, үч баланстоочу тең иштеп турганда, биринчи IP дарекке чалуулар биринчи баланстоочуга, экинчисине экинчисине, үчүнчүсүнө үчүнчүгө чалуулар болот.
Балансчылардын бири кулаганда эмне болот? Кандайдыр бир баланстоочу иштебей калса, анын негизги дареги дагы эле башка экөөнөн жарыяланып, трафик алардын ортосунда бөлүштүрүлөт. Ошентип, биз DNS аркылуу колдонуучуга бир эле учурда бир нече IP даректерди беребиз. DNS жана ар кандай көрсөткүчтөр боюнча тең салмактуулукту сактоо менен, биз үч тең салмактагычка тең жүктү бирдей бөлүштүрөбүз. Ошол эле учурда биз катачылыкка сабырдуулукту жоготпойбуз.
DNS + BGP негизинде HAProxy балансын түзүү
ExaBGP жана HAProxy ортосундагы өз ара аракеттенүү
Ошентип, биз каттамдарды жарыялоону токтотуунун негизинде сервер чыгып кеткен учурда каталарга чыдамдуулукту ишке ашырдык. Бирок HAProxy сервердин катасынан башка себептерден улам өчүрүлүшү мүмкүн: административдик каталар, кызматтын ичиндеги каталар. Биз бул учурларда да бузулган балансизаторду жүктүн астынан алып салгыбыз келет жана башка механизм керек.
Ошондуктан, мурунку схеманы кеңейтүү менен, биз ExaBGP жана HAProxy ортосунда жүрөктүн согушун ишке ашырдык. Бул ExaBGP менен HAProxy ортосундагы өз ара аракеттенүүнүн программалык камсыздоону ишке ашыруу, ExaBGP колдонмолордун абалын текшерүү үчүн ыңгайлаштырылган скрипттерди колдонгондо.
Бул үчүн ExaBGP конфигурациясында ден соолукту текшергичти конфигурациялашыңыз керек, ал HAProxy статусун текшере алат. Биздин учурда, биз HAProxy'де ден-соолукту чыңдоону конфигурацияладык жана ExaBGP тараптан биз жөнөкөй GET сурамы менен текшеребиз. Эгер жарыя токтоп калса, анда HAProxy иштебей калышы мүмкүн жана аны жарнамалоонун кереги жок.
HAProxy Ден соолукту текшерүү
HAProxy Peers: сессияны синхрондоштуруу
Кийинки нерсе сессияларды синхрондоштуруу болду. Бөлүштүрүлгөн баланстоочулар аркылуу иштөөдө кардар сессиялары жөнүндө маалыматты сактоону уюштуруу кыйынга турат. Бирок HAProxy Peers функциясынын аркасында муну жасай алган бир нече баланстоочулардын бири - сессия таблицаларын ар кандай HAProxy процесстеринин ортосунда өткөрүп берүү мүмкүнчүлүгү.
Ар кандай тең салмактуулук ыкмалары бар: жөнөкөй, мисалы , жана кеңейтилген, качан кардардын сессиясы эсте калганда жана ал мурункудай эле серверде аяктаган сайын. Экинчи вариантты ишке ашыралы дедик.
HAProxy бул механизмдин кардар сеанстарын сактоо үчүн таякчаларды колдонот. Алар кардардын баштапкы IP дарегин, тандалган максаттуу дарегин (backend) жана кээ бир кызмат маалыматын сактайт. Адатта, таякча таблицалар булак-IP + көздөгөн жер-IP жупту сактоо үчүн колдонулат, бул өзгөчө башка баланстоочуга, мисалы, RoundRobin балансташтыруу режиминде, колдонуучу сессиясынын контекстин өткөрүп бере албаган тиркемелер үчүн пайдалуу.
Эгерде таякча үстөлдү ар кандай HAProxy процесстеринин ортосунда жылдырууга үйрөтүлсө (анын ортосунда тең салмактуулук пайда болот), биздин баланстоочулар таякча үстөлдөрдүн бир бассейни менен иштей алышат. Бул, эгерде баланстоочулардын бири иштебей калса, кардардын тармагын үзгүлтүксүз которууга мүмкүнчүлүк берет;
Туура иштеши үчүн, сессия түзүлгөн баланстоочунун IP дарегинин көйгөйү чечилиши керек. Биздин учурда, бул кайра интерфейстеги динамикалык дарек.
Теңтуштардын туура иштеши белгилүү бир шарттарда гана ишке ашат. Башкача айтканда, TCP сеансын токтотууга убакыт болбошу үчүн TCP таймауттары жетиштүү чоң болушу керек же которулуу жетиштүү ылдам болушу керек. Бирок, ал үзгүлтүксүз которууга мүмкүндүк берет.
IaaSда бизде ошол эле технологияны колдонуу менен курулган кызмат бар. Бул , ал Octavia деп аталат. Ал эки HAProxy процессине негизделген жана алгач теңтуштарды колдоону камтыйт. Алар бул кызматта өздөрүн мыкты көрсөтүштү.
Сүрөт схемалык түрдө үч HAProxy инстанциясынын ортосундагы теңдүү таблицалардын кыймылын көрсөтөт, муну кантип конфигурациялоо керектиги боюнча конфигурация сунушталат:
HAProxy Peers (сеанс синхрондоштуруу)
Эгерде сиз ошол эле схеманы ишке ашырсаңыз, анын иштеши кылдат текшерилиши керек. Бул убакыттын 100% ушундай жол менен иштей тургандыгы чындык эмес. Бирок, жок дегенде, сиз кардардын IP булагы эстеп калуу керек болгондо, таякча таблицаларын жоготпойсуз.
Бир эле кардардан келген бир эле учурда суроо-талаптардын санын чектөө
Жалпыга жеткиликтүү болгон бардык кызматтар, анын ичинде API'лерибиз, сурамдардын көчкүсүнө дуушар болушу мүмкүн. Алардын себептери колдонуучунун каталарынан максаттуу чабуулдарга чейин такыр башка болушу мүмкүн. Биз мезгил-мезгили менен IP даректер боюнча DDoSed болуп саналат. Кардарлар көбүнчө сценарийлеринде ката кетирип, бизге мини-DDoSтарды беришет.
Тигил же бул жол менен кошумча коргоону камсыз кылуу керек. Ачык чечим - API сурамдарынын санын чектөө жана зыяндуу суроо-талаптарды иштетүү үчүн CPU убактысын текке кетирбөө.
Мындай чектөөлөрдү ишке ашыруу үчүн биз HAProxy негизинде уюштурулган тарифтик чектөөлөрдү, ошол эле таякча таблицаларын колдонуу менен колдонобуз. Чектерди орнотуу абдан жөнөкөй жана колдонуучуну API'ге болгон суроо-талаптардын саны менен чектөөгө мүмкүндүк берет. Алгоритм суроо-талаптар жасалган IP булагын эстейт жана бир колдонуучудан бир убактагы суроо-талаптардын санын чектейт. Албетте, биз ар бир кызмат үчүн орточо API жүктөө профилин эсептеп чыктык жана бул мааниден ≈ 10 эсе көп чек койдук. Биз кырдаалды кылдаттык менен көзөмөлдөп, сөөмөйүбүздү тамырдын кагышын кармайбыз.
Бул иш жүзүндө кандай көрүнөт? Биздин автоматтык масштабдоо API'лерибизди ар дайым колдонгон кардарларыбыз бар. Алар болжол менен эки-үч жүз виртуалдык машинаны эртең менен түзүп, кечинде жок кылышат. OpenStack үчүн виртуалдык машинаны түзүү, ошондой эле PaaS кызматтары менен кеминде 1000 API сурамдарын талап кылат, анткени кызматтардын өз ара аракеттенүүсү API аркылуу да ишке ашат.
Мындай тапшырмаларды өткөрүп берүү бир кыйла чоң жүктү алып келет. Биз бул жүктү бааладык, күнүмдүк чокуларды чогулттук, аларды он эсеге көбөйттүк жана бул биздин тарифтин чеги болуп калды. Биз сөөмөйүбүздү тамырдын кагышын кармайбыз. Биз ботторду жана сканерлерди көп көрөбүз, алар бизде иштете турган CGA скрипттери бар-жоктугун билүү үчүн, биз аларды жигердүү кесип жатабыз.
Колдонуучулар байкабай туруп код базасын кантип жаңыртса болот
Биз ошондой эле кодду жайылтуу процесстеринин деңгээлинде каталарга сабырдуулукту ишке ашырабыз. Ишке чыгаруу учурунда мүчүлүштүктөр болушу мүмкүн, бирок алардын кызматтын жеткиликтүүлүгүнө тийгизген таасирин азайтууга болот.
Биз кызматтарыбызды дайыма жаңыртабыз жана код базасы колдонуучуларга таасир этпестен жаңыртылганын камсыз кылышыбыз керек. Биз бул көйгөйдү HAProxy башкаруу мүмкүнчүлүктөрүн жана кызматтарыбызда Graceful Shutdown киргизүүнү колдонуу менен чече алдык.
Бул көйгөйдү чечүү үчүн, баланстоочу көзөмөлдү жана кызматтардын "туура" өчүрүлүшүн камсыз кылуу зарыл болгон:
- HAProxy учурда, башкаруу статс файлы аркылуу жүзөгө ашырылат, ал негизинен розетка болуп саналат жана HAProxy конфигурациясында аныкталган. Сиз ага stdio аркылуу буйруктарды жөнөтө аласыз. Бирок биздин негизги конфигурацияны башкаруу куралыбыз жеткиликтүү, ошондуктан анын HAProxy башкаруу үчүн орнотулган модулу бар. Биз активдүү колдонобуз.
- Биздин API жана Engine кызматтарыбыздын көбү көрктүү өчүрүү технологияларын колдойт: өчүрүп жатканда, алар http сурамы же кандайдыр бир кызмат тапшырмасы болобу, учурдагы тапшырманын аягына чыгышын күтүшөт. Ошол эле нерсе жумушчу менен болот. Ал аткарып жаткан иштердин баарын билет жана баарын ийгиликтүү аяктагандан кийин бүтөт.
Ушул эки пункттун аркасында биздин жайгаштыруунун коопсуз алгоритми ушундай көрүнөт.
- Иштеп чыгуучу коддун жаңы пакетин чогултат (биз үчүн бул RPM), аны иштеп чыгуучу чөйрөдө сынайт, этапта сынайт жана аны сахна репозиторийинде калтырат.
- Иштеп чыгуучу “артефакттардын” эң деталдуу сүрөттөлүшү менен жайылтуу тапшырмасын коёт: жаңы пакеттин версиясы, жаңы функциянын сыпаттамасы жана керек болсо жайылтуу жөнүндө башка деталдар.
- Системанын администратору жаңыртууну баштайт. Ansible оюн китебин ишке киргизет, ал өз кезегинде төмөнкүлөрдү аткарат:
- Сахнадагы репозиторийден пакетти алып, аны продукт репозиторийиндеги пакеттин версиясын жаңыртуу үчүн колдонот.
- Жаңыртылган кызматтын бэкендтеринин тизмесин түзөт.
- HAProxy'де жаңыртыла турган биринчи кызматты өчүрөт жана анын процесстери иштеп бүткүчө күтөт. Ыкчам өчүрүүнүн аркасында биз кардарлардын бардык учурдагы суроо-талаптары ийгиликтүү аяктайт деп ишенебиз.
- API жана жумушчулар толугу менен токтоп, HAProxy өчүрүлгөндөн кийин, код жаңыртылат.
- Ansible кызматтарын иштетет.
- Ар бир кызмат үчүн белгилүү бир "туткалар" тартылат, алар алдын ала аныкталган бир катар ачкыч тесттеринде бирдикти сынайт. Жаңы коддун негизги текшерүүсү жүргүзүлөт.
- Мурунку кадамда эч кандай ката табылбаса, арткы программа иштетилет.
- Келгиле, кийинки артка жылалы.
- Бардык серверлер жаңыртылгандан кийин, функционалдык тесттер ишке киргизилет. Эгерде алар жок болсо, анда иштеп чыгуучу өзү жараткан бардык жаңы функцияларды карайт.
Бул жайгаштырууну аяктайт.
Кызматты жаңыртуу цикли
Эгерде бизде бир эреже болбосо, бул схема иштемек эмес. Биз согушта эски жана жаңы версияларды колдойбуз. Алдын ала, программалык камсыздоону иштеп чыгуу стадиясында, кызмат базасында өзгөрүүлөр болсо да, алар мурунку кодду бузбай тургандыгы белгиленген. Натыйжада, код базасы акырындык менен жаңыланат.
жыйынтыктоо
Каталарга чыдамдуу WEB архитектурасы жөнүндө өз оюм менен бөлүшүп, мен дагы бир жолу анын негизги пункттарын белгилегим келет:
- физикалык каталарга сабырдуулук;
- тармак катачылыкка чыдамдуулук (балансерлер, BGP);
- колдонулган жана иштелип чыккан программалык камсыздоонун катачылыкка чыдамкайлыгы.
Баарына туруктуу иштөө убактысы!
Source: www.habr.com
