Заманауи интернетті медиа-контентсіз елестету мүмкін емес: дерлік әрбір әжеде смартфон бар, барлығы әлеуметтік желілерде, ал техникалық қызмет көрсетуде тоқтап қалу компаниялар үшін қымбатқа түседі. Мұнда компания оқиғасының стенограммасы берілген ол аппараттық шешімді пайдалана отырып фотосуреттерді жеткізуді қалай ұйымдастырғаны, бұл процесте қандай өнімділік мәселелеріне тап болғаны, олардың пайда болуына не себеп болғаны және бұл мәселелер барлық деңгейлерде ақауларға төзімділікті қамтамасыз ете отырып, Nginx негізіндегі бағдарламалық құрал шешімі арқылы қалай шешілгені туралы (). Олегтің әңгімесінің авторларына алғыс айтамыз Конференцияда өз тәжірибесімен бөліскен Ефимова мен Александра Дымова .
— Фотосуреттерді қалай сақтау және кэштеу туралы шағын кіріспеден бастайық. Бізде оларды сақтайтын қабат және фотосуреттерді кэштеу қабаты бар. Сонымен қатар, егер біз жоғары жылдамдыққа қол жеткізгіміз келсе және жадтағы жүктемені азайтқымыз келсе, біз үшін жеке пайдаланушының әрбір фотосы бір кэштеу серверінде болуы маңызды. Әйтпесе, бізде серверлер қанша болса, сонша есе көп дискілерді орнатуға тура келеді. Біздің трюк жылдамдығымыз шамамен 99% құрайды, яғни біз қоймадағы жүктемені 100 есеге азайтамыз және бұл үшін 10 жыл бұрын, осының бәрі салынып жатқанда, бізде 50 сервер болды. Сәйкесінше, осы фотосуреттерге қызмет көрсету үшін бізге осы серверлер қызмет ететін 50 сыртқы домен қажет болды.
Әрине, бірден сұрақ туындады: егер серверлеріміздің бірі істен шығып, қолжетімсіз болса, біз трафиктің қай бөлігін жоғалтамыз? Біз нарықта не бар екенін қарап шықтық және ол біздің барлық мәселелерімізді шеше алатындай жабдықты сатып алуды шештік. Таңдау F5-желілік компаниясының шешіміне түсті (айтпақшы, ол жақында NGINX, Inc сатып алған): BIG-IP Local Traffic Manager.
Бұл аппараттық құрал (LTM) не істейді: бұл темір маршрутизатор, ол өзінің сыртқы порттарын темір артық етеді және желі топологиясына, кейбір параметрлерге негізделген трафикті бағыттауға мүмкіндік береді және денсаулықты тексереді. Біз үшін бұл жабдықтың бағдарламалануы маңызды болды. Тиісінше, біз белгілі бір кэштен белгілі бір пайдаланушының фотосуреттеріне қалай қызмет көрсетілетінінің логикасын сипаттай аламыз. Ол неге ұқсайды? Бір доменде, бір IP-де Интернетті қарайтын, ssl жүктейтін, http сұрауларын талдайтын, IRule-ден кэш нөмірін таңдайтын, қайда бару керектігін және трафикті сол жерге жіберуге мүмкіндік беретін аппараттық құрал бар. Сонымен бірге ол денсаулықты тексереді және кейбір құрылғы қолжетімсіз болған жағдайда, біз оны трафик бір резервтік серверге өтетін етіп жасадық. Конфигурация тұрғысынан алғанда, әрине, кейбір нюанстар бар, бірақ жалпы алғанда бәрі қарапайым: біз картаны, желідегі IP-ге белгілі бір санның сәйкестігін тіркейміз, біз 80 порттарында тыңдаймыз деп айтамыз. және 443, егер сервер қолжетімсіз болса, трафикті сақтық көшірмеге жіберу керек деп айтамыз, бұл жағдайда 35-ші және біз бұл архитектураны қалай бөлшектеуге болатыны туралы көптеген логиканы сипаттаймыз. Жалғыз мәселе аппараттық құрал бағдарламаланған тіл Tcl болды. Егер біреу мұны есіне алса... бұл тіл бағдарламалауға ыңғайлы тілден гөрі тек жазуға арналған:
Біз не алдық? Біз инфрақұрылымымыздың жоғары қолжетімділігін қамтамасыз ететін, барлық трафикті бағыттайтын, денсаулыққа пайдалы және жай жұмыс істейтін жабдықты алдық. Оның үстіне, ол өте ұзақ уақыт жұмыс істейді: соңғы 10 жылда бұл туралы шағымдар болған жоқ. 2018 жылдың басында біз секундына 80 мыңға жуық фотосурет жібердік. Бұл біздің екі деректер орталықтарынан шамамен 80 гигабит трафик.
Бірақ ...
2018 жылдың басында біз диаграммаларда жағымсыз суретті көрдік: фотосуреттерді жіберуге кететін уақыт анық артты. Және ол бізге жараспай қалды. Мәселе мынада, бұл мінез-құлық трафиктің шыңында ғана көрінді - біздің компания үшін бұл жексенбіден дүйсенбіге қараған түн. Бірақ қалған уақытта жүйе әдеттегідей әрекет етті, сәтсіздік белгілері байқалмады.
Соған қарамастан, мәселені шешуге тура келді. Біз мүмкін болатын кедергілерді анықтап, оларды жоюға кірістік. Ең алдымен, біз сыртқы байланыстарды кеңейттік, ішкі байланыстардың толық аудитін жүргіздік және барлық ықтимал кедергілерді таптық. Бірақ мұның бәрі айқын нәтиже бермеді, мәселе жойылмады.
Тағы бір ықтимал кедергі фото кэштердің өнімділігі болды. Біз мәселе соларда болуы мүмкін деп шештік. Біз өнімділікті кеңейттік - негізінен фото кэштердегі желілік порттар. Бірақ тағы да айқын жақсарту байқалмады. Ақыр соңында, біз LTM-дің өнімділігіне мұқият назар аудардық және мұнда біз графиктерде қайғылы суретті көрдік: барлық процессорлардағы жүктеме біркелкі кете бастайды, бірақ кенеттен платоға келеді. Сонымен қатар, LTM денсаулық тексерулері мен қосылымдарға адекватты жауап беруді тоқтатады және оларды кездейсоқ өшіре бастайды, бұл өнімділіктің елеулі төмендеуіне әкеледі.
Яғни, мәселенің көзін анықтадық, тар жолды анықтадық. Не істейтінімізді шешу қалды.
Біз жасай алатын бірінші, ең айқын нәрсе - LTM-нің өзін қандай да бір түрде модернизациялау. Бірақ бұл жерде кейбір нюанстар бар, өйткені бұл жабдық өте ерекше, сіз ең жақын супермаркетке барып, оны сатып алмайсыз. Бұл бөлек келісім-шарт, жеке лицензиялық келісім-шарт және ол көп уақытты алады. Екінші нұсқа - өз бетінше ойлауды бастау, өзіңіздің құрамдас бөліктеріңізді пайдалана отырып, өзіңіздің шешіміңізді табу, жақсырақ ашық қолжетімділік бағдарламасын пайдалану. Бұл үшін нақты нені таңдайтынымызды және бұл мәселені шешуге қанша уақыт жұмсайтынымызды шешу ғана қалады, өйткені пайдаланушылар жеткілікті фотосуреттерді алмады. Сондықтан біз мұның бәрін өте, өте жылдам жасауымыз керек, кеше деуге болады.
Тапсырма «бірдеңені мүмкіндігінше тезірек орындау және бізде бар аппараттық құралдарды пайдалану» сияқты естілгендіктен, біз ойлаған бірінші нәрсе - алдыңғы жақтан өте қуатты емес машиналарды алып тастау, Nginx-ті сол жерге қою, біз онымен қалай істеу керектігін білеміз. жұмыс істеп, аппараттық құрал жасайтын барлық логиканы жүзеге асыруға тырысыңыз. Яғни, шын мәнінде, біз аппараттық құралымызды қалдырдық, конфигурациялауымыз керек болатын тағы 4 серверді орнаттық, олар үшін 10 жыл бұрынғыдай сыртқы домендер жасадық... Егер бұл машиналар құлап кетсе, біз аздап қолжетімділіктен айырылдық, бірақ бұдан да аз, олар жергілікті пайдаланушыларымыздың мәселесін шешті.
Тиісінше, логика өзгеріссіз қалады: біз Nginx орнатамыз, ол SSL-жүктемесін жасай алады, біз қандай да бір жолмен маршруттау логикасын, конфигурациялардағы денсаулықты тексеруді бағдарламалай аламыз және бізде бұрын болған логиканы қайталай аламыз.
Конфигурацияларды жазуға отырайық. Басында бәрі өте қарапайым болып көрінді, бірақ, өкінішке орай, әрбір тапсырма үшін нұсқаулықтарды табу өте қиын. Сондықтан біз «фотосуреттер үшін Nginx-ті қалай конфигурациялау керек» деп жай ғана Google іздеуді ұсынбаймыз: қай параметрлерге қол тигізу керектігін көрсететін ресми құжаттамаға жүгінген дұрыс. Бірақ нақты параметрді өзіңіз таңдаған дұрыс. Ал, сонда бәрі қарапайым: бізде бар серверлерді сипаттаймыз, біз сертификаттарды сипаттаймыз... Бірақ ең қызықтысы, шын мәнінде, маршруттау логикасының өзі.
Алғашында біз жай ғана орналасқан жерімізді сипаттап, ондағы фото кэштің санын сәйкестендіріп, қолдарымызды немесе генераторды пайдаланып, бізге қанша жоғары ағын қажет екенін сипаттап жатқандай көріндік, әр жоғары ағында біз трафик қай серверді көрсетеміз. өтіңіз және сақтық көшірме сервері - негізгі сервер қол жетімді болмаса:
Бірақ, бәлкім, бәрі қарапайым болса, біз ештеңе айтпай, үйге барар едік. Өкінішке орай, әдепкі Nginx параметрлері көп жылдар бойы әзірленген және бұл жағдайға мүлдем сәйкес келмейтін ... конфигурация келесідей көрінеді: егер кейбір жоғары ағын серверінде сұрау қатесі немесе күту уақыты болса, Nginx әрқашан трафикті келесіге ауыстырады. Сонымен қатар, бірінші сәтсіздіктен кейін, 10 секунд ішінде сервер қателікпен де, күту уақытымен де өшеді - оны кез келген жолмен конфигурациялау мүмкін емес. Яғни, егер біз жоғары ағын директивасында күту уақыты опциясын жойсақ немесе қалпына келтірсек, онда Nginx бұл сұрауды өңдемейді және өте жақсы емес қатемен жауап берсе де, сервер өшеді.
Бұған жол бермеу үшін біз екі нәрсені жасадық:
a) олар Nginx-ке мұны қолмен жасауға тыйым салды - және өкінішке орай, мұны істеудің жалғыз жолы - максимум сәтсіздіктер параметрлерін орнату.
б) біз басқа жобаларда денсаулықты фондық тексеруге мүмкіндік беретін модульді қолданатынымызды еске түсірдік - сәйкесінше, апат болған жағдайда тоқтау уақыты аз болуы үшін денсаулықты жиі тексеріп тұрдық.
Өкінішке орай, мұның бәрі де емес, өйткені бұл схема жұмысының алғашқы екі аптасы TCP денсаулығын тексеру де сенімсіз нәрсе екенін көрсетті: жоғары ағындық серверде ол Nginx немесе D күйіндегі Nginx болмауы мүмкін. бұл жағдайда ядро қосылымды қабылдайды, денсаулықты тексеруден өтеді, бірақ жұмыс істемейді. Сондықтан, біз оны дереу http денсаулықты тексерумен ауыстырдық, нақтысын жасадық, егер ол 200 қайтарса, бәрі осы сценарийде жұмыс істейді. Сіз қосымша логика жасай аласыз - мысалы, серверлерді кэштеу жағдайында файлдық жүйенің дұрыс орнатылғанын тексеріңіз:
Және бұл бізге қолайлы болар еді, тек қазіргі уақытта схема аппараттық құралдардың әрекетін толығымен қайталады. Бірақ біз жақсырақ әрекет еткіміз келді. Бұрын бізде бір резервтік сервер болған және бұл өте жақсы емес шығар, өйткені сізде жүз сервер болса, бірнешеу бірден істен шыққанда, бір резервтік сервер жүктемені жеңе алмайды. Сондықтан, біз резервтеуді барлық серверлер бойынша таратуды шештік: біз жай ғана басқа бөлек жоғары ағын жасадық, барлық серверлерді олар қызмет ете алатын жүктемеге сәйкес белгілі бір параметрлермен жаздырдық, бізде бұрын болған денсаулық тексерулерін қостық:
Бір жоғары ағынның ішінде басқа жоғары ағынға өту мүмкін болмағандықтан, біз дұрыс, қажетті фото кэшті жай ғана жазып алған негізгі жоғары ағын қолжетімсіз болса, біз жай ғана error_page арқылы қалпына келтіруге өткенімізге көз жеткізу керек еді. біз резервтік көшірмеге бардық:
Төрт серверді сөзбе-сөз қосу арқылы біз мынаны алдық: біз жүктеменің бір бөлігін ауыстырдық - біз оны LTM-ден осы серверлерге алып тастадық, стандартты аппараттық және бағдарламалық жасақтаманы пайдалана отырып, сол логиканы енгіздік және бұл серверлер алатын бонусты бірден алдық. масштабталады, өйткені оларды қажетінше жеткізуге болады. Жалғыз теріс нәрсе - біз сыртқы пайдаланушылар үшін жоғары қолжетімділікті жоғалттық. Бірақ сол сәтте біз мұны құрбан етуге тура келді, өйткені мәселені дереу шешу керек болды. Сонымен, біз жүктеменің бір бөлігін алып тастадық, ол сол кезде шамамен 40% болды, LTM өзін жақсы сезінді және мәселе басталғаннан кейін екі аптадан кейін біз секундына 45 мың емес, 55 мың сұраныс жібере бастадық. Шын мәнінде, біз 20% өстік - бұл пайдаланушыға бермеген трафик екені анық. Осыдан кейін олар қалған мәселені қалай шешуге болатыны туралы ойлана бастады - жоғары сыртқы қолжетімділікті қамтамасыз ету.
Бізде біраз үзіліс болды, оның барысында біз бұл үшін қандай шешім қолданатынымызды талқыладық. Кейбір үйде жазылған сценарийлерді, динамикалық маршруттау протоколдарын пайдалану арқылы DNS сенімділігін қамтамасыз ету бойынша ұсыныстар болды... көптеген нұсқалар болды, бірақ фотосуреттерді шынымен сенімді жеткізу үшін оны бақылайтын басқа қабатты енгізу керек екені белгілі болды. . Біз бұл машиналарды фоторежиссер деп атадық. Біз сүйенетін бағдарламалық құрал Keepalived болды:
Алдымен, Keepalived неден тұрады? Біріншісі – желілік пайдаланушыларға кеңінен танымал, желілік жабдықта орналасқан VRRP хаттамасы, ол клиенттер қосылатын сыртқы IP мекенжайының ақауларға төзімділігін қамтамасыз етеді. Екінші бөлік IPVS, IP виртуалды сервері, фото маршрутизаторлар арасындағы теңгерімге және осы деңгейде ақауларға төзімділікті қамтамасыз етуге арналған. Үшіншіден, денсаулықты тексеру.
Бірінші бөлімнен бастайық: VRRP - ол қалай көрінеді? Клиенттер қосылатын dns badoocdn.com сайтында жазбасы бар белгілі бір виртуалды IP бар. Белгілі бір уақытта бізде бір серверде IP мекенжайы бар. Keepaled пакеттер серверлер арасында VRRP протоколы арқылы іске қосылады және егер мастер радардан жоғалып кетсе - сервер қайта жүктелсе немесе басқа нәрсе болса, сақтық көшірме сервері осы IP мекенжайын автоматты түрде алады - ешқандай қолмен әрекеттер қажет емес. Негізгі және резервтік көшірме арасындағы айырмашылық негізінен басымдылық болып табылады: ол неғұрлым жоғары болса, машинаның шебер болу мүмкіндігі соғұрлым жоғары болады. Өте үлкен артықшылығы - сервердің өзінде IP мекенжайларын конфигурациялаудың қажеті жоқ, оларды конфигурацияда сипаттау жеткілікті және IP мекенжайларына кейбір реттелетін маршруттау ережелері қажет болса, бұл конфигурацияда тікелей сипатталған. VRRP бумасында сипатталғандай синтаксис. Сіз бейтаныс нәрселерді кездестірмейсіз.
Бұл іс жүзінде қалай көрінеді? Серверлердің бірі істен шыққан жағдайда не болады? Мастер жоғалып кеткенде, біздің резервтік көшірме жарнамаларды қабылдауды тоқтатады және автоматты түрде шеберге айналады. Біраз уақыттан кейін біз шеберді жөндедік, қайта жүктедік, Keepalived-ті көтердік - жарнамалар сақтық көшірмеге қарағанда жоғары басымдыққа ие болады және сақтық көшірме автоматты түрде кері қайтарылады, IP мекенжайларын жояды, қолмен әрекет жасаудың қажеті жоқ.
Осылайша, біз сыртқы IP мекенжайының ақауларға төзімділігін қамтамасыз еттік. Келесі бөлім сыртқы IP мекенжайынан оны тоқтатып тұрған фото маршрутизаторларға дейінгі трафикті қандай да бір түрде теңестіру болып табылады. Теңдестіру хаттамаларымен бәрі анық. Бұл қарапайым айналым, немесе сәл күрделірек нәрселер, wrr, тізім қосылымы және т.б. Бұл негізінен құжаттамада сипатталған, ерекше ештеңе жоқ. Бірақ жеткізу әдісі ... Мұнда біз олардың біреуін неліктен таңдағанымызды егжей-тегжейлі қарастырамыз. Бұл NAT, Direct Routing және TUN. Біз бірден сайттардан 100 гигабит трафикті жеткізуді жоспарладық. Егер сіз есептесеңіз, сізге 10 гигабиттік карта қажет, солай ма? Бір сервердегі 10 гигабиттік карта, кем дегенде, біздің «стандартты жабдық» тұжырымдамасының ауқымынан тыс. Содан кейін біз трафикті ғана емес, фотосуреттерді тарататынымызды еске түсірдік.
Не ерекше? — Кіріс және шығыс трафик арасындағы үлкен айырмашылық. Кіріс трафик өте аз, шығыс трафик өте үлкен:
Осы графиктерге қарасаңыз, қазіргі уақытта режиссер секундына шамамен 200 МБ қабылдап жатқанын көруге болады, бұл өте қарапайым күн. Біз секундына 4,500 МБ қайтарамыз, біздің қатынасымыз шамамен 1/22. 22 жұмысшы серверіне шығыс трафикті толығымен қамтамасыз ету үшін бізге осы қосылымды қабылдайтын біреуі ғана қажет екені қазірдің өзінде анық. Бұл жерде бізге тікелей маршруттау алгоритмі көмекке келеді.
Ол неге ұқсайды? Біздің фоторежиссер, оның кестесіне сәйкес, фото маршрутизаторларға қосылымдарды жібереді. Бірақ фотомаршрутизаторлар кері трафикті тікелей Интернетке жібереді, оны клиентке жібереді, ол фотодиректор арқылы кері өтпейді, осылайша, машиналардың ең аз санымен біз ақауларға толық төзімділік пен барлық трафикті айдауды қамтамасыз етеміз. Конфигурацияларда ол келесідей көрінеді: біз алгоритмді көрсетеміз, біздің жағдайда бұл қарапайым rr, тікелей маршруттау әдісін қамтамасыз етеміз, содан кейін бізде қаншасы бар барлық нақты серверлерді тізімдей бастаймыз. Бұл трафикті анықтайды. Егер бізде тағы бір немесе екі сервер немесе бірнеше сервер болса, мұндай қажеттілік туындайды - біз бұл бөлімді конфигурацияға қосамыз және көп уайымдамаңыз. Нақты серверлер жағынан, фото маршрутизатор жағынан бұл әдіс ең аз конфигурацияны қажет етеді, ол құжаттамада жақсы сипатталған және онда ешқандай тұзақтар жоқ.
Бір қызығы, мұндай шешім жергілікті желіні түбегейлі қайта құруды білдірмейді; бұл біз үшін маңызды болды; біз оны ең аз шығындармен шешуге тура келді. Қарасаңыз , содан кейін оның қалай көрінетінін көреміз. Бұл жерде бізде белгілі бір виртуалды сервер бар, 443 портында, тыңдайды, қосылымды қабылдайды, барлық жұмыс істейтін серверлер тізімде көрсетілген және сіз қосылымның бірдей екенін көре аласыз, беріңіз немесе алыңыз. Бір виртуалды сервердегі статистикаға қарасақ, бізде кіріс пакеттері, кіріс қосылымдары бар, бірақ шығыстары мүлдем жоқ. Шығыс қосылымдар тікелей клиентке өтеді. Жарайды, біз оны теңестіре алдық. Енді фото маршрутизаторларымыздың бірі істен шыққан жағдайда не болады? Өйткені темір – темір. Ол ядролық дүрбелеңге түсуі мүмкін, ол үзілуі мүмкін, қуат көзі жанып кетуі мүмкін. Не болса да. Сондықтан денсаулықты тексеру қажет. Олар порттың қалай ашылғанын тексеру сияқты қарапайым немесе одан да күрделірек болуы мүмкін, тіпті бизнес логикасын тексеретін кейбір үйде жазылған сценарийлерге дейін.
Біз ортасында бір жерде тоқтадық: бізде белгілі бір орынға https сұрауы бар, сценарий шақырылады, егер ол 200-ші жауаппен жауап берсе, біз бұл серверде бәрі жақсы, ол тірі және оны толығымен қосуға болады деп сенеміз. оңай.
Бұл тағы да іс жүзінде қалай көрінеді? Серверді техникалық қызмет көрсету үшін өшірейік - мысалы, BIOS жыпылықтауы. Журналдарда бізде бірден күту уақыты бар, біз бірінші жолды көреміз, содан кейін үш әрекеттен кейін ол «сәтсіз» деп белгіленеді және ол жай ғана тізімнен жойылады.
VS жай ғана нөлге орнатылған кезде екінші әрекет опциясы да мүмкін, бірақ фотосурет қайтарылса, бұл жақсы жұмыс істемейді. Сервер пайда болады, Nginx сол жерден басталады, денсаулықты тексеру қосылымның жұмыс істеп тұрғанын, бәрі жақсы екенін бірден түсінеді және сервер біздің тізімде пайда болады және оған жүктеме бірден қолданыла бастайды. Кезекші әкімшіден қолмен орындалатын әрекеттер талап етілмейді. Түнде сервер қайта жүктелді - мониторинг бөлімі түнде бұл туралы бізге қоңырау шалмайды. Олар сізге бұл болғанын хабарлайды, бәрі жақсы.
Осылайша, өте қарапайым түрде, серверлердің аз санының көмегімен біз сыртқы ақауларға төзімділік мәселесін шештік.
Мұның бәрі, әрине, бақылауды қажет ететіні ғана қалды. Айта кету керек, Keepalivede бағдарламалық жасақтамасы бұрыннан жазылғандай, DBus, SMTP, SNMP және стандартты Zabbix арқылы тексерулерді қолдана отырып, оны бақылаудың көптеген жолдары бар. Оның үстіне, оның өзі әр түшкіру үшін хат жазуды біледі, шынын айтсам, бір кездері біз оны өшіруді де ойладық, өйткені ол кез келген трафикті ауыстыру, қосу, әрбір IP қосылымы үшін көп хат жазады, және тағы басқа . Әрине, егер серверлер көп болса, онда сіз өзіңізді осы әріптермен толтыра аласыз. Біз стандартты әдістерді қолдана отырып, фото маршрутизаторлардағы nginx-ті бақылаймыз және аппараттық бақылау жойылған жоқ. Біз, әрине, тағы екі нәрсеге кеңес берер едік: біріншіден, сыртқы денсаулық тексерулері және қолжетімділік, өйткені бәрі жұмыс істеп тұрса да, шын мәнінде, пайдаланушылар сыртқы провайдерлердегі ақауларға немесе күрделі нәрсеге байланысты фотосуреттерді қабылдамауы мүмкін. Әрқашан басқа желіде, Amazon-да немесе басқа жерде серверлеріңізге сырттан пинг жібере алатын бөлек машинаны сақтау керек, сонымен қатар күрделі машиналық оқытуды немесе қарапайым бақылауды білетіндер үшін аномалияны анықтауды қолданған жөн. , кем дегенде, сұраулардың күрт төмендегенін немесе, керісінше, көбейгенін бақылау үшін. Бұл да пайдалы болуы мүмкін.
Қорытындылайық: біз, шын мәнінде, белгілі бір уақытта бізге сәйкес келмей қалған темірмен қапталған шешімді барлығын бірдей жасайтын өте қарапайым жүйемен ауыстырдық, яғни ол HTTPS трафигін тоқтатуды және одан әрі смарт маршруттауды қамтамасыз етеді. қажетті денсаулық тексерулері. Біз бұл жүйенің тұрақтылығын арттырдық, яғни бізде әлі де әрбір қабат үшін жоғары қолжетімділік бар, сонымен қатар бізде оның барлығын әр қабатта масштабтау өте оңай болатын бонус бар, өйткені бұл стандартты бағдарламалық құралмен стандартты жабдық, яғни. , біз ықтимал ақауларды диагностикалауды жеңілдеттік.
Біз немен аяқталдық? 2018 жылдың қаңтар айындағы мерекелерінде мәселеге тап болдық. Алғашқы алты айда біз бұл схеманы іске қосқан кезде, LTM-тен барлық трафикті алып тастау үшін оны барлық трафикке кеңейттік, біз тек бір деректер орталығындағы трафикті 40 гигабиттен 60 гигабитке дейін өсірдік және сонымен бірге бүкіл 2018 жыл секундына үш есе көп фотосуреттерді жібере алды.
Ақпарат көзі: www.habr.com