2010-жылы компания 50 сервер жана жөнөкөй тармак модели болгон: бэкэнд, фронт жана брандмауэр. Серверлердин саны өстү, модель татаалдашып кетти: сахналаштыруу, ACL менен обочолонгон VLAN, андан кийин VRF менен VPN, L2де ACL менен VLAN, L3 боюнча ACL менен VRF. Башы айланып жатабы? Кийинчерээк кызыктуураак болот.
16 000 сервер болгондо, мынчалык көп гетерогендүү сегменттер менен көз жашсыз иштөө мүмкүн болбой калды. Ошентип, биз башка чечимге келдик. Биз Netfilter стекин алдык, ага маалымат булагы катары консулду коштук жана тез бөлүштүрүлгөн брандмауэр алдык. Алар роутерлерде ACLди алмаштырып, аларды тышкы жана ички брандмауэр катары колдонушкан. Куралды динамикалык башкаруу үчүн биз BEFW тутумун иштеп чыктык, ал бардык жерде колдонулган: колдонуучунун продукт тармагына кирүү мүмкүнчүлүгүн башкаруудан тартып тармак сегменттерин бири-биринен обочолонтууга чейин.
Ал сизге мунун баары кантип иштээрин жана эмне үчүн бул системаны жакшыраак карап чыгуу керектигин айтып берет. Иван Агарков () компаниянын Минск өнүктүрүү борборундагы Тейлөө бөлүмүнүн инфраструктуралык коопсуздук тобунун жетекчиси. Иван SELinux күйөрманы, Perlди жакшы көрөт жана код жазат. Маалыматтык коопсуздук боюнча топтун жетекчиси катары ал Wargamingти хакерлерден коргоо жана компаниядагы бардык оюн серверлеринин иштешин камсыздоо үчүн журналдар, резервдик көчүрмөлөр жана R&D менен үзгүлтүксүз иштейт.
тарыхый маалымат
Муну кантип жасаганыбызды айтуудан мурун, мен биринчи кезекте бул нерсеге кантип жеткенибизди жана ал эмне үчүн керек болгонун айтып берем. Бул үчүн, 9 жыл артка кайрылалы: 2010, World of Tanks жаңы эле пайда болгон. Wargamingде 50гө жакын сервер бар болчу.
Компаниянын серверинин өсүү диаграммасы.
Бизде тармактык модель бар болчу. Ошол убакта ал оптималдуу болчу.
Тармактык модель 2010-ж.
Алдыңкы жагында бизди сындыргысы келген жаман балдар бар, бирок анын брандмауэри бар. Backendде брандмауэр жок, бирок ал жерде 50 сервер бар, биз алардын баарын билебиз. Баары жакшы иштейт.
4 жылдын ичинде сервердик парк 100 эсеге өсүп, 5000ге жетти. Биринчи обочолонгон тармактар пайда болду - сахналаштыруу: алар өндүрүшкө бара албай калышты жана ал жерде көп учурда кооптуу нерселер иштеп жатты.
Тармактык модель 2014-ж.
Инерция боюнча биз бир эле аппараттык бөлүктөрдү колдондук жана бардык иш обочолонгон VLANларда аткарылды: ACLдер VLANга жазылат, алар кандайдыр бир туташууга мүмкүндүк берет же четке кагат.
2016-жылы серверлердин саны 8000ге жетти.Wargaming башка студияларды өзүнө сиңирип, кошумча филиалдык тармактар пайда болду. Алар биздики окшойт, бирок анчалык деле эмес: VLAN көбүнчө өнөктөштөр үчүн иштебейт, VRF менен VPN колдонушуңуз керек, изоляция татаалдашат. ACL жылуулоо аралашмасы өстү.
Тармактык модель 2016-ж.
2018-жылдын башына карата машиналардын паркы 16 миңге чейин өстү. 000 сегмент бар, калганын эсептеген жокпуз, анын ичинде каржылык маалыматтар сакталган жабык. Контейнердик тармактар (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 үчүн backend катары колдондук.
Дайындарды жоготпойт. Колдонуу учурунда Консул бир жолку кырсык учурунда маалыматтарды жоготкон эмес. Бул Firewall башкаруу системасы үчүн чоң плюс.
P2P байланыштары өзгөрүүнүн жайылышын тездетет. P2P менен, бардык өзгөрүүлөр тез келет, бир нече саат күтүүнүн кереги жок.
Ыңгайлуу REST API. Биз Apache ZooKeeperди да карап чыктык, бирок анда REST API жок, ошондуктан балдактарды орнотууга туура келет.
Key Vault (KV) жана Directory (Кызматтын ачылышы) катары иштейт. Сиз дароо кызматтарды, каталогдорду жана маалымат борборлорун сактай аласыз. Бул биз үчүн гана эмес, коңшу командалар үчүн да ыңгайлуу, анткени глобалдык сервисти курууда биз чоң ойлонобуз.
Wargaming стекинин бир бөлүгү болгон Go программасында жазылган. Биз бул тилди жакшы көрөбүз, бизде көптөгөн Go иштеп чыгуучулары бар.
Күчтүү ACL системасы. Консулда сиз ким эмне жазганын көзөмөлдөө үчүн ACL колдоно аласыз. Биз брандмауэр эрежелери башка эч нерсе менен дал келбей тургандыгына кепилдик беребиз жана бул жагынан бизде көйгөйлөр болбойт.
Бирок консулдун да кемчиликтери бар.
- Эгер сизде бизнес версиясы болбосо, маалымат борборунун ичинде масштабдуу болбойт. Ал федерация тарабынан гана масштабдалат.
- Тармактын сапатына жана сервердин жүгүнө абдан көз каранды. Тармакта кандайдыр бир артта калуулар, мисалы, ылдамдыгы бирдей эмес болсо, консул бош эмес серверде сервер катары туура иштебейт. Бул P2P байланыштары жана жаңыртуу бөлүштүрүү моделдерине байланыштуу.
- Жеткиликтүүлүккө мониторинг жүргүзүү кыйынчылыгы. Консул статусунда баары жакшы деп айта алат, бирок көп убакыт мурун каза болгон.
Биз бул маселелердин көбүн Консулду пайдаланып жүрүп чечтик, ошондуктан аны тандап алдык. Компаниянын альтернативалуу пландары бар, бирок биз көйгөйлөр менен күрөшүүгө үйрөндүк жана учурда Консул менен жашап жатабыз.
Консул кантип иштейт
Шарттуу маалымат борборуна үч-беш серверди орнотобуз. Бир же эки сервер иштебейт: алар кворумду уюштуруп, маалыматтар дал келбей калганда ким туура, ким туура эмес экенин чече албайт. Бештен ашык мааниси жок, өндүрүмдүүлүк төмөндөйт.
Кардарлар серверлерге каалаган тартипте туташат: ошол эле агенттер, желек менен гана server = false.
Андан кийин, кардарлар P2P байланыштарынын тизмесин алышат жана өз ара байланыштарды түзүшөт.
Дүйнөлүк деңгээлде биз бир нече маалымат борборлорун бириктиребиз. Алар ошондой эле P2P менен байланышып, баарлашышат.
Биз башка маалымат борборунан маалыматтарды алгыбыз келгенде, сурам серверден серверге өтөт. Бул схема деп аталат Серф протоколу. Serf протоколу, Консул сыяктуу, HashiCorp тарабынан иштелип чыккан.
Консул жөнүндө кээ бир маанилүү фактылар
Консулда анын кантип иштээрин сүрөттөгөн документтер бар. Мен тандалган фактыларды гана берем.
Консул серверлери шайлоочулардын арасынан кожоюнду шайлашат. Консул ар бир дата борбору үчүн серверлердин тизмесинен мастерди тандайт жана бардык суроо-талаптар серверлердин санына карабастан ага гана барат. Мастер тоңдуруу кайра шайлоого алып келбейт. Кожоюн тандалбаса, сурамдарды эч ким тейлебейт.
Сиз горизонталдуу масштабды каалайсызбы? Кечиресиз, жок.
Башка маалымат борборуна суроо-талап кайсы серверге келгенине карабастан, мастерден мастерге өтөт. Тандалган мастер жүктүн 100% алат, алдыга суроо-талаптар боюнча жүктү кошпогондо. Маалымат борборундагы бардык серверлерде маалыматтардын жаңыланган көчүрмөсү бар, бирок бирөө гана жооп берет.
Масштабтын бирден бир жолу - кардардагы эскирген режимди иштетүү.
Эски режимде сиз кворумсуз жооп бере аласыз. Бул биз берилиштердин ырааттуулугунан баш тарткан режим, бирок демейдегиден бир аз ылдамыраак окуп, каалаган сервер жооп берет. Албетте, мастер аркылуу гана жаздыруу.
Консул маалымат борборлорунун ортосунда маалыматтарды көчүрбөйт. Федерация чогултулганда, ар бир сервер өзүнүн гана маалыматтарына ээ болот. Башкалар үчүн, ал дайыма башка бирөөгө кайрылат.
Операциялардын атомдуулугу транзакциядан тышкары кепилденбейт. Бир нерсени өзгөртө ала турган жалгыз сиз эмес экениңизди унутпаңыз. Эгер сиз башкача кааласаңыз, кулпу менен бүтүм жүргүзүңүз.
Бөгөттөө операциялары кулпуга кепилдик бербейт. Сурам түздөн-түз эмес, мастерден мастерге өтөт, андыктан, мисалы, башка маалымат борборунда бөгөттөлгөндө бөгөттөө иштей тургандыгына кепилдик жок.
ACL да кирүүгө кепилдик бербейт (көп учурларда). ACL иштебей калышы мүмкүн, анткени ал бир федерация маалымат борборунда - ACL маалымат борборунда (Негизги DC) сакталган. DC сизге жооп бербесе, ACL иштебейт.
Бир тоңдурулган мастер бүт федерацияны тоңдурат. Мисалы, федерацияда 10 дата борбору бар, биринин тармагы начар, бир мастер иштебей калат. Аны менен баарлашкандардын баары тегеректе тыгылып калат: өтүнүч бар, ага жооп жок, жип катып калат. Бул качан болорун билүүгө мүмкүнчүлүк жок, болгону бир-эки сааттан кийин бүт федерация кулайт. Бул тууралуу эч нерсе кыла албайсың.
Статус, кворум жана шайлоо өзүнчө жип менен каралат. Кайра шайлоо болбойт, статус эч нерсе көрсөтпөйт. Тирүү Консул бар деп ойлойсуң, сурайсың, эч нерсе болбойт – жооп жок. Ошол эле учурда статус баары жайында экенин көрсөтүп турат.
Биз бул көйгөйгө туш болдук жана аны болтурбоо үчүн маалымат борборлорунун айрым бөлүктөрүн кайра курууга туура келди.
Consul Enterprise бизнес версиясында жогоруда айтылган кээ бир кемчиликтер жок. Анын көптөгөн пайдалуу функциялары бар: шайлоочуларды тандоо, бөлүштүрүү, масштабдоо. Бир гана "бирок" бар - бөлүштүрүлгөн система үчүн лицензиялоо системасы абдан кымбат.
Камерон жашоо: rm -rf /var/lib/consul - агенттин бардык ооруларына даба. Эгер бир нерсе сиз үчүн иштебесе, жөн гана дайындарыңызды жок кылып, көчүрмөдөн дайындарды жүктөп алыңыз. Көбүнчө Консул иштейт.
BEFW
Эми Консулга эмнелерди кошконубуз жөнүндө сүйлөшөлү.
дегендин аббревиатурасы болуп саналат BACKEndFиреWбаары. Мен репозиторийди түзүп жатканда, ага биринчи сыноолорду киргизүү үчүн продуктуну кандайдыр бир жол менен аташ керек болчу. Бул аты калды.
Эреже калыптары
Эрежелер iptables синтаксисинде жазылган.
- -N BEFW
- -P INPUT DOP
- -A INPUT -m абалы-мамлекет БАЙЛАНЫШТУУ,ТҮЗГӨН -j КАБЫЛ АЛУУ
- -A INPUT -i lo -j КАБЫЛ АЛУУ
- -A INPUT -j BEFW
Мындан тышкары, баары BEFW чынжырына кирет ESTABLISHED, RELATED жана localhost. Шаблон каалаган нерсе болушу мүмкүн, бул жөн гана мисал.
BEFW кандайча пайдалуу?
кызмат
Бизде кызмат бар, анын дайыма порту, түйүнү бар. Түйүнүбүздөн биз жергиликтүү агенттен сурап, бизде кандайдыр бир кызмат бар экенин биле алабыз. Сиз ошондой эле тегдерди коюуга болот.
Консулда иштеп жаткан жана катталган ар кандай кызмат iptables эрежесине айланат. Бизде SSH бар - ачык порт 22. Баш сценарийи жөнөкөй: curl жана iptables, башка эч нерсе керек эмес.
кардарлар
Кантип баарына эмес, тандап алуу мүмкүнчүлүгүн ачуу керек? Кызматтын аталышы боюнча КВ сактагычка IP тизмелерин кошуңуз.
Мисалы, биз онунчу тармактагылардын баары SSH_TCP_22 кызматына кире алышын каалайбыз. Бир кичинекей TTL талаасы кошулсунбу? эми бизде убактылуу уруксаттар бар, мисалы бир суткага.
Кирүү мүмкүнчүлүгү
Биз кызматтарды жана кардарларды бириктиребиз: бизде кызмат бар, КВ сактагычы ар бири үчүн даяр. Азыр биз бардыгына эмес, тандап алуу мүмкүнчүлүгүн беребиз.
топтор
Ар бир жолу кирүү үчүн миңдеген IP жазсак, чарчап калабыз. Келгиле, топторду ойлоп көрөлү - КВда өзүнчө бир бөлүм. Келгиле, аны Alias (же топтор) деп атайлы жана ошол эле принцип боюнча топторду ошол жерде сактайлы.
Туташып кетели: эми биз SSHди атайын P2P үчүн эмес, бүтүндөй топ же бир нече топтор үчүн ача алабыз. Ошол сыяктуу эле, TTL бар - сиз топко кошуп, убактылуу топтон чыгарып салсаңыз болот.
жуурулушуу
Биздин көйгөй адам фактору жана автоматташтыруу. Азырынча биз муну ушундай жол менен чечтик.
Биз куурчак менен иштейбиз жана системага тиешелүү нерселердин баарын (колдонмо коду) аларга өткөрүп беребиз. Puppetdb (кадимки PostgreSQL) ал жерде иштеп жаткан кызматтардын тизмесин сактайт, аларды ресурстун түрү боюнча тапса болот. Ал жерден ким кайда тапшырып жатканын биле аласыз. Бул үчүн бизде суроо-талапты тартуу жана бириктирүү сурам системасы да бар.
Биз befw-синхрондоштурууну жаздык, бул маалыматтарды өткөрүүгө жардам берген жөнөкөй чечим. Биринчиден, синхрондоштуруу кукилерине puppetdb аркылуу кирүүгө болот. Ал жерде HTTP API конфигурацияланган: бизде кандай кызматтар бар, эмне кылуу керек экенин сурайбыз. Анан консулга арыз менен кайрылышат.
Интеграция барбы? Ооба: алар эрежелерди жазып, тартуу өтүнүчтөрүн кабыл алууга уруксат беришти. Сизге белгилүү бир порт керекпи же кандайдыр бир топко хост кошуу керекпи? Сурамды тартуу, карап чыгуу - мындан ары "200 башка ACL таап, бул боюнча бир нерсе кылууга аракет кылыңыз."
оптималдаштыруу
Бош эреже чынжыр менен localhost пинг жүргүзүү 0,075 мс талап кылынат.
Бул чынжырга 10 000 iptables дарегин кошолу. Натыйжада, пинг 5 эсе көбөйөт: iptables толугу менен сызыктуу, ар бир даректи иштетүү бир аз убакытты талап кылат.
Миңдеген ACLлерди көчүргөн брандмауэр үчүн бизде көп эрежелер бар жана бул күтүү убактысын киргизет. Бул оюн протоколдору үчүн жаман.
Ал эми койсок ipsetте 10 000 дарек Пинг да азаят.
Эң негизгиси ipset үчүн “O” (алгоритмдин татаалдыгы) канча эрежелер бар болбосун, ар дайым 1ге барабар. Ырас, чектөө бар - 65535 эрежеден ашык болушу мүмкүн эмес.Азыр биз муну менен жашайбыз: аларды бириктирип, кеңейтип, биринде эки ипсет жасай аласыз.
сактоочу жай
Итерация процессинин логикалык уландысы болуп ipset кызматына кардарлар тууралуу маалыматты сактоо саналат.
Эми бизде бир эле SSH бар жана биз бир убакта 100 IP жазбайбыз, бирок биз баарлашышыбыз керек болгон ipsetтин атын жана төмөнкү эрежени койдук. DROP. Аны бир эрежеге айландырса болот "Бул жерде ким жок, DROP", бирок бул түшүнүктүү.
Азыр бизде эрежелер жана топтомдор бар. Негизги милдет - эрежени жазуудан мурун топтом түзүү, анткени антпесе iptables эрежени жазбайт.
жалпы схемалык
Диаграмма түрүндө мен айткандардын баары ушундай көрүнөт.
Биз куурчакка милдеттенебиз, бардыгы хостко жөнөтүлөт, бул жерде кызматтар, ошол жерде 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дардын санын азайтабыз.
Бүтүндүктү көзөмөлдөө
Мурда кимдир бирөө брандмауэр эрежесин кол менен өзгөрткөндө кабарлаган атайын триггерге ээ болчубуз. Мен Firewall эрежелерин текшерүү үчүн чоң линтер жазып жаттым, бул кыйын болду. Бүтүндүк азыр BEFW тарабынан көзөмөлдөнөт. Ал ынталуу түрдө өзү чыгарган эрежелердин өзгөрбөшүн камсыздайт. Эгер кимдир бирөө брандмауэр эрежелерин өзгөртсө, ал баарын кайра өзгөртөт. "Мен үйдөн иштөө үчүн проксиди тез орноттум" — мындан ары мындай варианттар жок.
BEFW кызматтардан ipsetти жана befw.conf тизмегинен, BEFW чынжырындагы кызматтардын эрежелерин көзөмөлдөйт. Бирок ал башка чынжырларды жана эрежелерди жана башка ипсеттерди көзөмөлдөбөйт.
Crash коргоо
BEFW ар дайым акыркы белгилүү жакшы абалды түздөн-түз state.bin бинардык структурасында сактайт. Бир нерсе туура эмес болуп кетсе, ал ар дайым ушул абалга кайтып келет.bin.
Бул Консулдун туруксуз операциясынан камсыздандыруу, ал маалыматтарды жөнөтпөгөндө же кимдир бирөө ката кетирип, колдонууга болбой турган эрежелерди колдонгондо. Биз брандмауэрсиз калбашыбыз үчүн, кандайдыр бир этапта ката пайда болсо, BEFW акыркы абалга кайтып келет.
Критикалык кырдаалдарда бул бизде иштеген брандмауэр менен калаарыбыздын кепилдиги. Админ келип оңдоп кетет деген үмүт менен бардык боз тармактарды ачабыз. Бир күнү мен муну конфигурацияга киргизем, бирок азыр бизде үч боз тармак бар: 10/8, 172/12 жана 192.168/16. Консулубуздун ичинде бул биздин андан ары өнүгүүбүзгө жардам берген маанилүү өзгөчөлүк.
Демо: отчеттун жүрүшүндө Иван BEFW демо режимин көрсөтөт. Демонстрацияны көрүү оңой . Демо булак коду жеткиликтүү .
тузактар
Мен сизге биз жолуккан мүчүлүштүктөр жөнүндө айтып берем.
ipset add set 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 жана ушул учурда кандайдыр бир пакет келип, ал жок кылынат жана бир нерсе туура эмес болуп калат. Демек, ал жерде бир аз кара сыйкыр бар.
консул kv get -datacenter=башка. Мен айткандай, биз кандайдыр бир маалыматтарды сурап жатабыз деп ойлойбуз, бирок биз маалымат же ката алабыз. Биз муну жергиликтүү консул аркылуу жасай алабыз, бирок бул учурда экөө тең катып калат.
Жергиликтүү консул кардары HTTP API үстүнөн каптоочу болуп саналат. Бирок ал жөн эле илинип турат жана Ctrl+C же Ctrl+Z же башка нерсеге жооп бербейт, бир гана kill -9 кийинки консолдо. Муну биз чоң кластер куруп жатканда жолуктурдук. Бирок бизде азырынча чечим жок; Консулда бул катаны оңдоого даярданып жатабыз.
Консулдун жетекчиси жооп бербей жатат. Дата борборундагы мастерибиз жооп бербей жатат, биз ойлойбуз: "Балким, кайра тандоо алгоритми азыр иштейби?"
Жок, бул иштебейт, мониторинг эч нерсе көрсөтпөйт: Консул милдеттенменин индекси бар, лидер табылды, баары жакшы деп айтат.
Муну кантип чечебиз? service consul restart саат сайын крондо. Эгер сизде 50 сервер болсо, чоң маселе жок. Алардын саны 16 000 болгондо, анын кандай иштээрин түшүнөсүз.
жыйынтыктоо
Натыйжада, биз төмөнкү артыкчылыктарды алдык:
- Бардык Linux машиналарын 100% камтуу.
- Тез.
- Автоматташтыруу.
- Биз аппараттык жана тармактык инженерлерди кулчулуктан бошоттук.
- Интеграциянын дээрлик чексиз мүмкүнчүлүктөрү пайда болду: жада калса Kubernetes менен, жада калса Ansible менен, ал тургай Python менен.
Минусы: Консул, биз азыр жашашыбыз керек болгон жана катачылыктын өтө кымбат баасы. Мисал катары, бир жолу саат 6:XNUMXдө (Россияда прайм-тайм) мен тармактардын тизмесинде бир нерсени түзөтүп жаттым. Биз ал кезде BEFWде жылуулоону жаңы эле куруп жатканбыз. Мен бир жерден ката кетирдим, туура эмес масканы көрсөттүм окшойт, бирок баары эки секунданын ичинде түшүп калды. Мониторинг күйөт, нөөмөтчү чуркап келип: "Бизде баары бар!" Эмне үчүн мындай болгонун бизнеске түшүндүргөндө бөлүм башчы боз болуп кетти.
Катанын баасы ушунчалык жогору болгондуктан, биз өзүбүздүн комплекстүү алдын алуу процедурасын ойлоп таптык. Эгер сиз муну чоң өндүрүш сайтында ишке ашырсаңыз, бардыгына консулдун үстүнөн мастер белгисин берүүнүн кажети жок. Мунун аягы жаман болот.
Наркы. Мен жалгыз 400 саат код жаздым. Менин 4 адамдан турган командам ар бир адамды колдоо үчүн айына 10 саат жумшайт. Бардык жаңы муундагы брандмауэрдин баасы менен салыштырганда, ал бекер.
Пландар. Узак мөөнөттүү план консулду алмаштыруу же толуктоо үчүн альтернативалуу транспортту табуу болуп саналат. Балким, бул Кафка же ушуга окшош нерсе болот. Бирок жакынкы жылдары биз консулдукта жашайбыз.
Ыкчам пландар: Fail2ban менен интеграция, мониторинг, nftables менен, балким, башка бөлүштүрүү, метрика, өркүндөтүлгөн мониторинг, оптималдаштыруу. Kubernetes колдоосу дагы пландардын бир жеринде, анткени азыр бизде бир нече кластерлер жана каалоо бар.
Пландардан көбүрөөк:
- жол кыймылындагы аномалияларды издөө;
- тармак картасын башкаруу;
- Kubernetes колдоосу;
- бардык системалар үчүн пакеттерди чогултуу;
- Web-UI.
Биз дайыма конфигурацияны кеңейтүү, метрикаларды көбөйтүү жана оптималдаштыруу боюнча иштеп жатабыз.
Долбоорго кошулуңуз. Долбоор сонун болуп чыкты, бирок, тилекке каршы, бул дагы эле бир адамдын долбоору. Келүү жана бир нерсе кылууга аракет кылыңыз: милдеттендириңиз, сынаңыз, бир нерсе сунуштаңыз, өзүңүздүн бааңызды бериңиз.
Ошол эле учурда биз даярданып жатабыз , Санкт-Петербург шаарында 6 жана 7-апрелде өтөт жана биз жогорку жүктөө системаларын иштеп чыгуучуларды чакырабыз . Тажрыйбалуу баяндамачылар эмне кылуу керектигин билишет, бирок жаңы сүйлөп жаткандар үчүн биз жок дегенде сунуштайбыз . Конференцияга баяндамачы катары катышуунун бир катар артыкчылыктары бар. Кайсынысын, мисалы, аягында окуй аласыз .
Source: www.habr.com
