2010 жылы компания 50 сервер және қарапайым желі моделі болды: сервер, фронт және брандмауэр. Серверлер саны өсті, модель күрделене түсті: сахналау, ACL бар оқшауланған VLAN, содан кейін VRF бар VPN, L2 бойынша ACL бар VLAN, L3 бойынша ACL бар VRF. Басы айналып жатыр ма? Кейінірек қызық болады.
16 000 сервер болған кезде, көптеген гетерогенді сегменттермен көз жасынсыз жұмыс істеу мүмкін болмады. Сондықтан біз басқа шешімге келдік. Біз Netfilter стекін алдық, оған деректер көзі ретінде консулды қостық және жылдам таратылатын брандмауэр алдық. Олар маршрутизаторлардағы ACL ауыстырып, оларды сыртқы және ішкі брандмауэр ретінде пайдаланды. Құралды динамикалық басқару үшін біз BEFW жүйесін әзірледік, ол барлық жерде қолданылды: пайдаланушының өнім желісіне қол жеткізуін басқарудан бастап желі сегменттерін бір-бірінен оқшаулауға дейін.
Ол сізге бәрі қалай жұмыс істейтінін және неге бұл жүйені мұқият қарастыру керектігін айтып береді. Иван Агарков () компанияның Минск даму орталығындағы Техникалық қызмет көрсету бөлімінің инфрақұрылымдық қауіпсіздік тобының жетекшісі. Иван - SELinux жанкүйері, Perl-ді жақсы көреді және код жазады. Ақпараттық қауіпсіздік тобының жетекшісі ретінде ол Wargaming-ті хакерлерден қорғау және компаниядағы барлық ойын серверлерінің жұмысын қамтамасыз ету үшін журналдармен, резервтік көшірмелермен және ғылыми-зерттеу жұмыстарымен жүйелі түрде жұмыс істейді.
Тарихи негіз
Мұны қалай жасағанымызды айтпас бұрын, мен сізге бірінші кезекте бұған қалай келгенімізді және оның не үшін қажет екенін айтайын. Ол үшін 9 жыл артқа шегінейік: 2010 жылы World of Tanks жаңа ғана пайда болды. Wargaming-де шамамен 50 сервер болды.
Компания серверінің өсу диаграммасы.
Бізде желілік модель болды. Ол үшін бұл оңтайлы болды.
2010 жылы желілік модель.
Алдыңғы жағында бізді сындырғысы келетін жаман адамдар бар, бірақ оның брандмауэрі бар. Брандмауэр серверде жоқ, бірақ 50 сервер бар, біз олардың барлығын білеміз. Барлығы жақсы жұмыс істейді.
4 жыл ішінде серверлік парк 100 есе, яғни 5000-ға дейін өсті. Алғашқы оқшауланған желілер пайда болды - сахналау: олар өндіріске бара алмады және жиі қауіпті болуы мүмкін нәрселер жұмыс істеп тұрды.
2014 жылы желілік модель.
Инерция бойынша біз бірдей аппараттық құралдарды қолдандық және барлық жұмыс оқшауланған VLAN желілерінде жүргізілді: ACL қосылымның қандай да бір түріне рұқсат беретін немесе жоққа шығаратын VLAN-ға жазылған.
2016 жылы серверлер саны 8000-ға жетті.Wargaming басқа студияларды сіңіріп, қосымша серіктестік желілері пайда болды. Олар біздікі сияқты, бірақ мүлдем емес: VLAN серіктестер үшін жиі жұмыс істемейді, VRF көмегімен VPN пайдалану керек, оқшаулау қиындай түседі. ACL оқшаулау қоспасы өсті.
2016 жылы желілік модель.
2018 жылдың басына қарай машина паркі 16 000-ға дейін өсті.6 сегмент болды, ал қалғандарын есептемедік, оның ішінде қаржылық деректер сақталатын жабық сегменттер де бар. Контейнерлік желілер (Kubernetes), DevOps, VPN арқылы қосылған бұлттық желілер, мысалы, IVS арқылы пайда болды. Ережелер көп болды - бұл азапты болды.
2018 жылы желі моделі және оқшаулау әдістері.
Оқшаулау үшін біз қолдандық: L2 бойынша ACL бар VLAN, L3 бойынша ACL бар VRF, VPN және т.б. Тым көп.
проблемалар
Барлығы ACL және VLAN арқылы өмір сүреді. Не болды? Бұл сұраққа ауырсынуды жасырып, Гарольд жауап береді.
Көптеген мәселелер болды, бірақ бес ауқымды мәселе болды.
- Жаңа ережелер үшін бағаның геометриялық өсуі. Әрбір жаңа ережені қосу алдыңғыға қарағанда ұзағырақ болды, өйткені алдымен мұндай ереженің бар-жоғын білу керек болды.
- Сегменттердің ішінде брандмауэр жоқ. Сегменттер бір-бірінен қандай да бір түрде бөлінген және ішінде ресурстар жеткіліксіз болды.
- Ережелер ұзақ уақыт бойы қолданылды. Операторлар бір сағат ішінде бір жергілікті ережені қолмен жаза алады. Жаһандық бірнеше күнге созылды.
- Аудит ережелерінің қиындықтары. Дәлірек айтқанда, бұл мүмкін емес еді. Алғашқы ережелер 2010 жылы жазылған болатын және олардың авторларының көпшілігі енді компанияда жұмыс істемейді.
- Инфрақұрылымды бақылаудың төмен деңгейі. Бұл басты мәселе – біз елімізде не болып жатқанын жақсы білмедік.
2018 жылы желі инженері: «Тағы да ACL керек» дегенді естігенде, осылай көрінді.
Шешімдер
2018 жылдың басында бұл туралы бір нәрсе жасау туралы шешім қабылданды.
Интеграциялардың бағасы үнемі өсіп келеді. Бастапқы нүкте үлкен деректер орталықтары оқшауланған VLAN және ACL қолдауын тоқтатты, себебі құрылғылардың жады таусылды.
Шешім: біз адам факторын алып тастадық және максималды қолжетімділікті қамтамасыз етуді автоматтандырдық.
Жаңа ережелерді қолдану үшін көп уақыт қажет. Шешуі: ережелерді қолдануды тездету, оны үлестірілген және параллель ету. Бұл ережелер мың жүйеге rsync немесе SFTPсіз жеткізілуі үшін бөлінген жүйені қажет етеді.
Сегменттердің ішінде брандмауэр жоқ. Бір желіде әртүрлі қызметтер пайда болған кезде сегменттердегі брандмауэр бізге келе бастады. Шешім: хост деңгейінде желіаралық қалқанды пайдаланыңыз – хост негізіндегі желіаралық қалқандар. Барлық жерде дерлік бізде Linux бар және барлық жерде iptables бар, бұл проблема емес.
Аудит ережелерінің қиындықтары. Шешім: Қарап шығу және басқару үшін барлық ережелерді бір жерде сақтаңыз, осылайша біз бәрін тексере аламыз.
Инфрақұрылымды бақылаудың төмен деңгейі. Шешім: барлық қызметтерді және олардың арасындағы қатынасты түгендеу.
Бұл техникалық емес, әкімшілік процесс. Кейде бізде аптасына 200-300 жаңа шығарылым болады, әсіресе жарнамалық акциялар мен мерекелер кезінде. Сонымен қатар, бұл біздің DevOps-тің бір командасына ғана арналған. Көптеген шығарылымдармен қандай порттар, IP мекенжайлары және интеграциялар қажет екенін көру мүмкін емес. Сондықтан бізге командаларға: «Бұл жерде не бар және оны не үшін көтердіңіз?» деп сұрайтын арнайы дайындалған қызмет менеджерлері қажет болды.
Біз іске қосқаннан кейін 2019 жылы желі инженері осылай көріне бастады.
Консул
Біз қызмет менеджерлерінің көмегімен тапқанның бәрін Консулға салып, сол жерден iptables ережелерін жазамыз деп шештік.
Біз мұны қалай шештік?
- Біз барлық қызметтерді, желілерді және пайдаланушыларды жинаймыз.
- Солардың негізінде iptables ережелерін құрайық.
- Біз басқаруды автоматтандырамыз.
- ....
- ПАЙДА.
Консул қашықтағы API емес, ол әрбір түйінде жұмыс істей алады және iptables файлына жаза алады. Қажетсіз нәрселерді тазартатын автоматты басқару элементтерін ойлап табу ғана қалады және мәселелердің көпшілігі шешіледі! Қалғанын жүріп келеміз.
Неліктен консул?
Өзін жақсы дәлелдеді. 2014-15 жылдары біз оны құпия сөздерді сақтайтын Vault сервері ретінде пайдаландық.
Деректерді жоғалтпайды. Пайдалану уақытында Консул бір апат кезінде деректерді жоғалтпады. Бұл желіаралық қалқанды басқару жүйесі үшін үлкен плюс.
P2P қосылымдары өзгерістердің таралуын тездетеді. P2P көмегімен барлық өзгерістер тез келеді, сағаттап күтудің қажеті жоқ.
Ыңғайлы REST API. Біз сондай-ақ Apache ZooKeeper-ді қарастырдық, бірақ оның REST API интерфейсі жоқ, сондықтан балдақтарды орнатуға тура келеді.
Кілттер қоймасы (KV) және каталог (қызметтерді табу) ретінде жұмыс істейді.. Қызметтерді, каталогтарды және деректер орталықтарын бірден сақтауға болады. Бұл біз үшін ғана емес, көршілес командалар үшін де ыңғайлы, өйткені жаһандық сервисті құру кезінде біз үлкен ойланамыз.
Wargaming стекінің бөлігі болып табылатын Go бағдарламасында жазылған. Біз бұл тілді жақсы көреміз, бізде көптеген Go әзірлеушілері бар.
Қуатты ACL жүйесі. Консулда сіз кім не жазатынын басқару үшін ACL пайдалана аласыз. Біз брандмауэр ережелерінің басқа ештеңемен сәйкес келмейтініне және бізде бұл мәселеде қиындықтар болмайтынына кепілдік береміз.
Бірақ консулдың да кемшіліктері бар.
- Бизнес нұсқасы болмаса, деректер орталығында масштабталмайды. Оны тек федерация кеңейтеді.
- Желінің сапасына және сервер жүктемесіне өте тәуелді. Егер желіде қандай да бір кешігулер болса, мысалы, біркелкі емес жылдамдық болса, консул бос емес серверде сервер ретінде дұрыс жұмыс істемейді. Бұл P2P қосылымдарына және тарату үлгілерін жаңартуға байланысты.
- Қолжетімділікті бақылаудың қиындығы. Консул мәртебесінде ол бәрі жақсы деп айта алады, бірақ ол баяғыда қайтыс болды.
Біз бұл мәселелердің көпшілігін Консулды пайдалану кезінде шештік, сондықтан оны таңдадық. Компанияда балама бэкенд жоспарлары бар, бірақ біз проблемалармен күресуді үйрендік және қазір консулмен бірге тұрамыз.
Консул қалай жұмыс істейді
Шартты деректер орталығында үш-бес серверді орнатамыз. Бір немесе екі сервер жұмыс істемейді: олар кворум ұйымдастыра алмайды және деректер сәйкес келмеген кезде кім дұрыс, кім бұрыс екенін шеше алмайды. Бестен артық мағынасы жоқ, өнімділік төмендейді.
Клиенттер серверлерге кез келген ретпен қосылады: бірдей агенттер, тек жалаушамен server = false.
Осыдан кейін клиенттер P2P қосылымдарының тізімін алады және өзара байланыстар жасайды.
Жаһандық деңгейде біз бірнеше деректер орталықтарын қосамыз. Олар сонымен қатар P2P-ті қосып, байланысады.
Біз басқа деректер орталығынан деректерді алғымыз келгенде, сұрау серверден серверге өтеді. Бұл схема деп аталады Серф протоколы. Серф хаттамасы, Консул сияқты, HashiCorp әзірлеген.
Консул туралы бірнеше маңызды фактілер
Консулда оның қалай жұмыс істейтінін сипаттайтын құжат бар. Мен тек таңдауға тұрарлық фактілерді беремін.
Консул серверлері сайлаушылар арасынан шеберді таңдайды. Консул әрбір деректер орталығы үшін серверлер тізімінен шеберді таңдайды және барлық сұраулар серверлер санына қарамастан тек оған түседі. Шебердің қатып қалуы қайта сайлауға әкелмейді. Шебер таңдалмаса, сұрауларға ешкім қызмет көрсетпейді.
Көлденең масштабтауды қаладыңыз ба? Кешіріңіз жоқ.
Басқа деректер орталығына сұрау қай серверге келгеніне қарамастан шеберден бастыға өтеді. Таңдалған мастер жүктің 100% алады, форвардтық сұраулардағы жүктемені қоспағанда. Деректер орталығындағы барлық серверлерде деректердің жаңартылған көшірмесі бар, бірақ тек біреуі ғана жауап береді.
Масштабтаудың жалғыз жолы - клиентте ескірген режимді қосу.
Ескірген режимде сіз кворумсыз жауап бере аласыз. Бұл біз деректердің тұрақтылығынан бас тартатын, бірақ әдеттегіден сәл жылдамырақ оқитын және кез келген сервер жауап беретін режим. Әрине, тек шебер арқылы жазу.
Консул деректер орталықтары арасында деректерді көшірмейді. Федерация жиналған кезде әрбір серверде тек өзінің деректері болады. Басқалар үшін ол әрқашан басқа біреуге бұрылады.
Операциялардың атомдылығына транзакциядан тыс кепілдік берілмейді. Есіңізде болсын, сіз бір нәрсені өзгерте алатын жалғыз адам емессіз. Егер сіз мұны басқаша қаласаңыз, құлыппен транзакция жасаңыз.
Блоктау операциялары құлыптауға кепілдік бермейді. Сұрау тікелей емес, шеберден шеберге өтеді, сондықтан блоктау, мысалы, басқа деректер орталығында блоктау кезінде жұмыс істейтініне кепілдік жоқ.
ACL қол жеткізуге кепілдік бермейді (көп жағдайда). ACL жұмыс істемеуі мүмкін, себебі ол бір федерация деректер орталығында - ACL деректер орталығында (бастапқы DC) сақталады. Егер DC сізге жауап бермесе, ACL жұмыс істемейді.
Бір қатып қалған шебер бүкіл федерацияның қатып қалуына әкеледі. Мысалы, федерацияда 10 дата орталығы бар және біреуінің желісі нашар, ал бір шебері істен шығады. Онымен сөйлескендердің бәрі шеңберде тұрып қалады: өтініш бар, оған жауап жоқ, жіп қатып қалады. Мұның қашан болатынын білу мүмкін емес, бір-екі сағаттан кейін бүкіл федерация құлап кетеді. Бұл туралы ештеңе істей алмайсыз.
Статус, кворум және сайлау жеке ағынмен өңделеді. Қайта сайлау болмайды, статус ештеңе көрсетпейді. Сіз тірі Консул бар деп ойлайсыз, сұрайсыз, ештеңе болмайды - жауап жоқ. Бұл ретте статус бәрі жақсы екенін көрсетеді.
Біз бұл мәселеге тап болдық және оны болдырмау үшін деректер орталықтарының белгілі бір бөліктерін қайта құруға тура келді.
Consul Enterprise іскерлік нұсқасында жоғарыда келтірілген кейбір кемшіліктер жоқ. Оның көптеген пайдалы функциялары бар: сайлаушыларды таңдау, бөлу, масштабтау. Бір ғана «бірақ» бар - бөлінген жүйе үшін лицензиялау жүйесі өте қымбат.
Өмірді бұзу: rm -rf /var/lib/consul - агенттің барлық ауруларына ем. Егер бірдеңе жұмыс істемесе, деректеріңізді жойып, деректерді көшірмеден жүктеп алыңыз. Консул жұмыс істейтін шығар.
BEFW
Енді Консулға не қосқанымыз туралы сөйлесейік.
дегеннің аббревиатурасы болып табылады BаккEndFIREWбарлық. Мен репозиторийді жасаған кезде оған бірінші сынақ тапсырмаларын қою үшін өнімді қалай атауға тура келді. Бұл атау қалды.
Ереже үлгілері
Ережелер iptables синтаксисінде жазылған.
- -N BEFW
- -P INPUT DROP
- -A INPUT -m күй-күй БАЙЛАНЫСТЫ, ҚҰРЫЛҒАН -j ҚАБЫЛДАУ
- -A INPUT -i lo -j ҚАБЫЛДАУ
- -A INPUT -j АЛДЫДА
Барлығы BEFW тізбегіне кіреді, қоспағанда ESTABLISHED, RELATED және жергілікті хост. Үлгі кез келген болуы мүмкін, бұл тек мысал.
BEFW қалай пайдалы?
Қызметтер
Бізде қызмет бар, оның әрқашан порты, ол жұмыс істейтін түйіні бар. Біздің түйіннен біз агенттен жергілікті түрде сұрай аламыз және бізде қандай да бір қызмет түрі бар екенін біле аламыз. Сондай-ақ тегтерді қоюға болады.
Консулда жұмыс істеп тұрған және тіркелген кез келген қызмет iptables ережесіне айналады. Бізде SSH бар - ашық порт 22. Bash сценарийі қарапайым: curl және iptables, басқа ештеңе қажет емес.
клиенттер
Барлығына емес, таңдаулы түрде қол жеткізуді қалай ашуға болады? IP тізімдерін қызмет атауы бойынша КВ қоймасына қосыңыз.
Мысалы, оныншы желідегі барлық адамдар SSH_TCP_22 қызметіне қол жеткізе алатынын қалаймыз. Бір кішкентай TTL өрісін қосу керек пе? ал қазір бізде уақытша рұқсаттар бар, мысалы, бір күнге.
Қатынастар
Біз қызметтер мен клиенттерді байланыстырамыз: бізде қызмет бар, КВ қоймасы әрқайсысына дайын. Енді біз барлығына емес, таңдаулы түрде рұқсат береміз.
топтар
Әр жолы кіру үшін мыңдаған IP жазатын болсақ, біз шаршаймыз. Топтастыруды ойлап көрейік - КВ-дағы жеке жиын. Оны бүркеншік ат (немесе топтар) деп атаймыз және сол принцип бойынша топтарды сол жерде сақтаймыз.
Қосылайық: енді біз SSH-ді арнайы P2P үшін емес, бүкіл топ немесе бірнеше топ үшін аша аламыз. Дәл осылай TTL бар - топқа қосуға және топтан уақытша шығаруға болады.
Интеграция
Біздің мәселе – адам факторы мен автоматтандыру. Әзірге біз оны осылай шештік.
Біз Puppet-пен жұмыс істейміз және жүйеге қатысты барлық нәрсені (қолданба коды) оларға тасымалдаймыз. Puppetdb (тұрақты PostgreSQL) сол жерде жұмыс істейтін қызметтер тізімін сақтайды, оларды ресурс түрі бойынша табуға болады. Онда сіз кімнің қайда өтініш бергенін біле аласыз. Бұл үшін бізде сұрауды тарту және біріктіру сұрау жүйесі бар.
Біз деректерді тасымалдауға көмектесетін қарапайым шешім befw-sync жаздык. Біріншіден, синхрондау cookie файлдарына puppetdb арқылы қатынасады. Онда HTTP API конфигурацияланған: бізде қандай қызметтер бар, не істеу керек екенін сұраймыз. Содан кейін олар консулға өтініш жасайды.
Интеграция бар ма? Иә: олар ережелерді жазды және тарту сұрауларын қабылдауға рұқсат берді. Сізге белгілі бір порт қажет пе немесе кейбір топқа хост қосу керек пе? Өтінімді тарту, қарап шығу – енді «200 басқа ACL табыңыз және бұл туралы бірдеңе жасауға тырысыңыз».
Оңтайландыру
Бос ережелер тізбегі бар жергілікті хостты пингтеу 0,075 мс алады.
Осы тізбекке 10 000 iptables мекенжайын қосамыз. Нәтижесінде пинг 5 есе артады: iptables толығымен сызықты, әрбір мекенжайды өңдеу біраз уақытты алады.
Мыңдаған ACL көшіретін брандмауэр үшін бізде көптеген ережелер бар және бұл кідіріс береді. Бұл ойын протоколдары үшін нашар.
Бірақ қойсақ ipset ішіндегі 10 000 мекенжай Пинг тіпті төмендейді.
Мәселе мынада, ipset үшін «O» (алгоритм күрделілігі) қанша ереже болса да, әрқашан 1-ге тең. Рас, шектеу бар - 65535 ережеден артық болуы мүмкін емес. Әзірге біз мұнымен өмір сүреміз: сіз оларды біріктіре аласыз, кеңейте аласыз, бірінде екі ipset жасай аласыз.
Сақтау
Итерация процесінің логикалық жалғасы ipset-те қызметке арналған клиенттер туралы ақпаратты сақтау болып табылады.
Енді бізде бірдей SSH бар және біз бірден 100 IP жазбаймыз, бірақ біз байланысу керек ipset атын және келесі ережені орнатамыз. DROP. Оны бір ережеге айналдыруға болады «Кім мұнда жоқ, DROP», бірақ бұл түсінікті.
Енді бізде ережелер мен жиындар бар. Негізгі міндет - ережені жазбас бұрын жиынды жасау, өйткені әйтпесе iptables ережені жазбайды.
Бас сызба
Диаграмма түрінде менің айтқанымның бәрі осылай көрінеді.
Біз Қуыршаққа міндеттеме береміз, бәрі хостқа жіберіледі, мұнда қызметтер, ipset сонда және ол жерде тіркелмегендерге рұқсат етілмейді.
Рұқсат ету және бас тарту
Әлемді жылдам құтқару немесе біреуді тез өшіру үшін барлық тізбектердің басында біз екі ipset жасадық: rules_allow и rules_deny. Бұл қалай жұмыс істейді?
Мысалы, біреу біздің веб-сайтта боттармен жүктеме жасауда. Бұрын сіз оның IP-ін журналдардан тауып, оны желі инженерлеріне апаруыңыз керек еді, сонда олар трафиктің көзін тауып, оған тыйым салу керек еді. Қазір басқаша көрінеді.
Біз оны консулға жібереміз, 2,5 секунд күтеміз және ол аяқталды. Консул P2P арқылы жылдам таралатындықтан, ол әлемнің кез келген бөлігінде барлық жерде жұмыс істейді.
Бірде брандмауэрдің қателігіне байланысты WOT-ты толығымен тоқтаттым. rules_allow - бұл біздің осындай жағдайлардан сақтандыруымыз. Егер брандмауэрмен бір жерде қателік жасасақ, бір жерде бір нәрсе бұғатталған болса, біз әрқашан шартты жібере аламыз 0.0/0бәрін тез жинау үшін. Кейін барлығын қолмен жөндейміз.
Басқа жиынтықтар
Кеңістікте кез келген басқа жиындарды қосуға болады $IPSETS$.
Не үшін? Кейде біреуге ipset қажет, мысалы, кластердің кейбір бөлігінің өшірілуін эмуляциялау үшін. Кез келген адам кез келген жиынтықты әкеле алады, олардың атын атайды және олар консулдан алынады. Сонымен қатар, жиынтықтар iptables ережелеріне қатыса алады немесе команда ретінде әрекет ете алады NOOP: Сәйкестікті демон сақтайды.
пайдаланушылар
Бұрын ол былай болды: пайдаланушы желіге қосылып, домен арқылы параметрлерді алды. Жаңа буын брандмауэрлері пайда болғанға дейін Cisco пайдаланушының қайда және IP қайда екенін қалай түсінуге болатынын білмеді. Сондықтан қол жеткізу тек құрылғының хост атауы арқылы берілді.
Біз не істедік? Біз мекенжайды алған сәтте тығырыққа тірелдік. Әдетте бұл dot1x, Wi-Fi немесе VPN - барлығы RADIUS арқылы өтеді. Әрбір пайдаланушы үшін пайдаланушы аты бойынша топ жасаймыз және оған dhcp.lease тең TTL бар IP орналастырамыз - оның мерзімі біткен бойда ереже жойылады.
Енді біз басқа топтар сияқты қызметтерге кіруді пайдаланушы аты бойынша аша аламыз. Хост атаулары өзгерген кезде ауыртпалықтан арылдық және желі инженерлерінен ауыртпалықты алып тастадық, өйткені оларға Cisco енді қажет емес. Енді инженерлердің өздері серверлеріне кіруді тіркейді.
Оқшаулау
Сонымен бірге біз оқшаулауды бөлшектеуге кірістік. Қызмет менеджерлері түгендеу жүргізді, біз барлық желілерімізді талдадық. Оларды бірдей топтарға бөлейік, ал қажетті серверлерде топтар, мысалы, бас тарту үшін қосылды. Енді сол кезеңдік оқшаулау өндірістің өзінде емес, ережелерді_дейлеуде аяқталады.
Схема тез және қарапайым жұмыс істейді: біз серверлерден барлық ACL-ді алып тастаймыз, аппараттық құралдарды босатамыз және оқшауланған VLAN санын азайтамыз.
Тұтастығын бақылау
Бұрын бізде біреу брандмауэр ережесін қолмен өзгерткен кезде хабарлайтын арнайы триггер болған. Мен желіаралық қалқан ережелерін тексеру үшін үлкен линтер жаздым, бұл қиын болды. Тұтастықты енді BEFW басқарады. Ол өзі шығарған ережелердің өзгермеуін құлшыныспен қамтамасыз етеді. Егер біреу брандмауэр ережелерін өзгертсе, ол бәрін кері өзгертеді. «Үйден жұмыс істеу үшін мен проксиді тез орнаттым» — бұдан былай мұндай опциялар жоқ.
BEFW BEFW тізбегіндегі қызметтер ережелерін, befw.conf ішіндегі қызметтер мен тізімнен ipset-ті басқарады. Бірақ ол басқа тізбектер мен ережелерді және басқа ипсеттерді қадағаламайды.
Апатқа қарсы қорғаныс
BEFW әрқашан соңғы белгілі жақсы күйді тікелей state.bin екілік құрылымында сақтайды. Бірдеңе дұрыс болмаса, ол әрқашан осы күйге оралады.bin.
Бұл Консулдың тұрақсыз жұмысынан сақтандыру, ол деректерді жібермегенде немесе біреу қателесіп, қолдануға болмайтын ережелерді қолданғанда. Брандмауэрсіз қалмауымыз үшін, кез келген кезеңде қате орын алса, BEFW соңғы күйге оралады.
Қиын жағдайларда бұл бізде жұмыс істейтін брандмауэр болатынына кепілдік. Админ келіп жөндейді деген үмітпен барлық сұр желіні ашамыз. Бір күні мен оны конфигурацияларға қоямын, бірақ қазір бізде үш сұр желі бар: 10/8, 172/12 және 192.168/16. Біздің консулдың ішінде бұл әрі қарай дамуымызға көмектесетін маңызды функция.
Демо: баяндама кезінде Иван BEFW демо режимін көрсетеді. Демонстрацияны көру оңайырақ . Демо бастапқы коды қолжетімді .
Төзімділік
Мен сізге біз кездескен қателер туралы айтып беремін.
ipset қосу жиыны 0.0.0.0/0. ipset-ке 0.0.0.0/0 қоссаңыз не болады? Барлық IP қосыла ма? Интернетке қол жетімділік болады ма?
Жоқ, бізде екі сағат бос тұруға кететін қате пайда болады. Сонымен қатар, қате 2016 жылдан бері жұмыс істемейді, ол RedHat Bugzilla-да №1297092 нөмірімен орналасқан және біз оны кездейсоқ таптық - әзірлеушінің есебі бойынша.
Бұл қазір BEFW-де қатаң ереже 0.0.0.0/0 екі адреске айналады: 0.0.0.0/1 и 128.0.0.0/1.
ipset қалпына келтіру жиыны < файлы. Сіз айтқан кезде ipset не істейді restore? Бұл iptables сияқты жұмыс істейді деп ойлайсыз ба? Ол деректерді қалпына келтіре ме?
Мұндай ештеңе жоқ - ол біріктіреді және ескі мекенжайлар ешқайда кетпейді, кіруге тыйым салмайсыз.
Оқшаулауды сынау кезінде қатені таптық. Енді оның орнына өте күрделі жүйе бар restore жүргізілген create temp, содан кейін restore flush temp и restore temp. Своптың соңында: атомдық үшін, өйткені сіз мұны бірінші орындасаңыз flush және осы сәтте кейбір пакет келеді, ол жойылады және бірдеңе дұрыс болмайды. Демек, мұнда біраз қара магия бар.
consul kv get -datacenter=басқа. Жоғарыда айтқанымдай, біз кейбір деректерді сұрап жатырмыз деп ойлаймыз, бірақ біз деректерді немесе қатені аламыз. Біз мұны жергілікті консул арқылы жасай аламыз, бірақ бұл жағдайда екеуі де қатып қалады.
Жергілікті Консул клиенті HTTP API арқылы қаптама болып табылады. Бірақ ол жай ғана ілулі тұр және Ctrl+C немесе Ctrl+Z немесе ештеңеге жауап бермейді, тек kill -9 келесі консольде. Біз мұны үлкен кластер құрып жатқанда кездестірдік. Бірақ бізде әлі шешім жоқ; біз бұл қатені консулда түзетуге дайындалып жатырмыз.
Консул басшысы жауап бермей отыр. Дата орталығындағы шеберіміз жауап бермейді, біз: «Мүмкін, қайта таңдау алгоритмі қазір жұмыс істейтін шығар?» деп ойлаймыз.
Жоқ, ол жұмыс істемейді және мониторинг ештеңе көрсетпейді: консул міндеттеме индексі бар, көшбасшы табылды, бәрі жақсы деп айтады.
Мұнымен қалай күресеміз? service consul restart сағат сайын cron. Егер сізде 50 сервер болса, маңызды мәселе емес. Олардың саны 16 000 болғанда, оның қалай жұмыс істейтінін түсінесіз.
қорытынды
Нәтижесінде біз келесі артықшылықтарға ие болдық:
- Барлық Linux машиналарын 100% қамту.
- Жылдамдық.
- Автоматтандыру.
- Біз аппараттық және желілік инженерлерді құлдықтан босаттық.
- Интеграциялық мүмкіндіктер пайда болды, олар дерлік шексіз: тіпті Kubernetes-те, тіпті Ansible-де, тіпті Python-да.
Минусы: Консул, біз қазір өмір сүруіміз керек және қателіктің өте жоғары құны. Мысал ретінде, бір рет кешкі сағат 6-де (Ресейдегі прайм-тайм) мен желілер тізімдерінде бірдеңені өңдедім. Ол кезде біз тек BEFW-де оқшаулауды салып жатырмыз. Мен бір жерде қате жібердім, мен қате масканы көрсеткен сияқтымын, бірақ бәрі екі секундта құлап кетті. Бақылау жанады, көмекші кезекші жүгіріп келеді: «Бізде бәрі бар!» Неліктен бұлай болғанын бизнеске түсіндіргенде бөлім басшысы сұр түсті.
Қатенің құны соншалықты жоғары, біз өзіміздің кешенді алдын алу процедурасын ойлап таптық. Егер сіз мұны үлкен өндіріс орнында жүзеге асырсаңыз, барлығына Консулдың басты белгісін берудің қажеті жоқ. Мұның соңы жаман болады.
Құны. Мен тек 400 сағат код жаздым. Менің 4 адамнан тұратын командам айына 10 сағатын барлығына қолдау көрсетуге жұмсайды. Кез келген жаңа буын брандмауэрінің бағасымен салыстырғанда, ол тегін.
Жоспарлары. Ұзақ мерзімді жоспар консулды алмастыратын немесе толықтыратын балама көлікті табу болып табылады. Мүмкін бұл Кафка немесе ұқсас нәрсе болуы мүмкін. Бірақ алдағы жылдары біз консулда тұрамыз.
Жедел жоспарлар: Fail2ban, мониторинг, nftables, мүмкін басқа таратулармен, метрикамен, кеңейтілген бақылаумен, оңтайландырумен интеграция. Kubernetes қолдауы да жоспарлардың бір жерінде, өйткені қазір бізде бірнеше кластерлер мен тілектер бар.
Жоспарлардан көбірек:
- қозғалыстағы ауытқуларды іздеу;
- желі картасын басқару;
- Kubernetes қолдауы;
- барлық жүйелер үшін пакеттерді құрастыру;
- Web-UI.
Біз конфигурацияны кеңейту, көрсеткіштерді арттыру және оңтайландыру бойынша үнемі жұмыс жасаймыз.
Жобаға қосылыңыз. Жоба керемет болып шықты, бірақ, өкінішке орай, бұл әлі де бір адамға арналған жоба. Келу және бірдеңе жасауға тырысыңыз: міндеттеніңіз, сынаңыз, бірдеңе ұсыныңыз, өз бағаңызды беріңіз.
Әзірге дайындалып жатырмыз , ол 6 және 7 сәуірде Санкт-Петербургте өтеді және біз жоғары жүктемелі жүйелерді әзірлеушілерді шақырамыз. . Тәжірибелі спикерлер не істеу керектігін біледі, бірақ жаңадан сөйлейтіндерге кем дегенде кеңес береміз . Конференцияға спикер ретінде қатысудың бірқатар артықшылықтары бар. Сіз қайсысын оқи аласыз, мысалы, соңында .
Ақпарат көзі: www.habr.com