Пользователь заводет на заявку "запилите мне базу и кролика", а описывает требуемую инфру в виде, допустм yaml и сабмитит. Либо в заявку, либо PR в git.
Первым делом yml проверяется а-ля линтером - все что нужно в yml-е есть, какого-нужно формата, в нужных диапазонах.
Потом yml преобразуется на основе шаблонов в конфиги для систем управления - конфиг для терраформа, плейбуки для ансибла. И вот в них-то уже и заложены те саме требуемые паттерны - сколько и каких машин для PGsql, сколько и где для rabbit, выделяются адреса, сети, vni в ipam (через api, автоматически), формируются из шаблонов плейбуки. И потом оно все исполняется, валидируется пост-деплой скриптом и просят пользователя нажать кнопочку "я доволен".
ты просто еще до гиперболической геометрии не дорос, поэтому за теорему Пифагора держишься. так и в остальном - goto плохо, но до определенного момента.
судя по всему ты даже не понял о чем речь. "система хранения" это не всегда "хранилка" (sds, nas или старые добрые san), просто кому-то не нужно опускаться настолько далеко. san-техники уже давно стали "черной командой".
OSMP (он же KSC) - Open Single Management Platform (Kaspersky Security Center) - это не система управления фаерволлами. Это - центр управления продуктами ЛК. Сейчас с его помощью управляются агенты KES* (endpopoint security) и XDR (eXtended Detect & Response). Насколько я понимаю, чистого KSC в природе нет и в пилоте должен был быть XDR и NGFW не только управляется из KSC но и интегрируется с сами уже развернутым внутри XDR сливая туда логи для анализа. То есть получается комплекс сетевой безопасности из NGFW + XDR и оба они управляются из зонтика KSC(OSMP).
боже, сколько можно воды налить в старую всем известную hub & spoke topology. Это называется "набивание собственной значимости", целенаправленное переусложнение с целью показать, что мы незаменимы и doing serious business(c).
Только бедный ВТБ кашляет и плюётся кровью от платформы Сфера. Например, некоторые подразделения еще три года назад задавали вопрос "А будет ли у Сферы внешний API как у jira/confluence? А ты мы все свои процессы уже автоматизировали и нам будет больно" и были буквально посланы менеджерами Т1 по внедрению Сферы в банке. Насколько я знаю - проблема существует до сих пор. И это только один из многочисленных примеров проблем "платформы" и их решения.
правильно, не надо сюда. Проходите мимо. Курьеры полчают больше, строители и продавцы в 5ку более нужны, опять же: есть благородная профессия - Родину защищать. не нужно в ИТ. Мы справимся.
добро пожаловать в open-source и вообще в *nix-way. Вам никто ничего не должен. Сделали что-то хорошее - радуйтесь, а не возмущайтесь. Возьмите, да напишите сами патч и отправьте пулл-реквест.
в ARPANET не было аналогов LAN. host-to-host всегда общались через IMP и не было никаких таких разделений на то что два хоста могут пообщаться друг с другом минуя IMP, просто узнав адрес друг-друга.
но с другой стороны IMP - это не просто роутер, как в текущем понимании. Т.к. логика слоя tcp работала именно на IMP. Ну вот фаргментация пакетов, подтверждения доставки, сборка пакетов обратно и гарантия очередности доставки.
Я бы сказал, что IMP больше похож на самом деле на брокер очередей, чем на роутер. Host-IMP - это скорее API к IMP. А host-host - это прям очередь.
ну не совсем ) что роутеры, что свитчи в итоге создают какую-то таблицу форвардинга (FIB) в которой хранят записи, что делать в зависимости от destination. И в принципе этот самый FIB одинаково сложный, что у роутеров, что у современных multilayer-свитчей - dest может быть как просто dst-mac, так и dst-ip или что-от еще суровее, так и "что делать" может быть просто "выплюнь в порт" или сложно "поменяй метку, перепиши dst"/"уложи в vni, отправь к другому vtep".
Вот только у свитчей бывает всего один тип интерфейсов - ethernet. Или ATM. Или infiniband. Или... Но не бывает свитча eth + FR. А роутер - бывает. Вот и основная разница.
Есть еще нюансики, конечно: посмотрите мой ответ ниже - https://habr.com/ru/articles/840116/comments/#comment_27237592
в современном мире функции роутеров и свитчей пересекаются. Большинство свитчей умеют маршрутизировать - если например на свитче создано несколько vlan-ов и каждому из них сконфигурирована своя подсеть с ip-адресом на виртуальном свитча, то свитч прекрасно будет маршрутизировать пакеты из одной подсети в другую и соответственно на выходе тегировать нужным vlan. Также многие свитчи L3+ умеют использовать протоколы маршрутизации как igp (ospf, eigp, isis), так и egp (bgp).
В свою очередь, современные роутеры могут коммутировать на основе данных из L2 - можно собрать из портов коммутируемую группу (у разных вендоров называется по-разному - bridge-group, brdige-domain и т.п.) и они будут работать как свитч.
Факторов разницы несколько:
порты на свитче одной и той-же технологии (ethernet, infiniband, ...), а на роутере могут одновременно быть совершенно разные порты - eth, atm, древний frame-relay, набор модемов 3g/4g/5g, какой-нить жуткий ds3/e3 и прочая экзотика; это ключевой момент из-за которого в принципе и появились роутеры;
портовая емкость - у свитчей как правило больше, впрочем бывают и роутеры с большим количеством портов;
стоимость портов на свитчах как правило в разы меньше; отсюда и портовая емкость;
функционал роутеров как правило гораздо шире. Протоколы маршрутизации умеют и свитчи запускать, mpls и evpn - тоже, а вот, допустим, быть vpn-клиентом и сервером или иметь развесистый иерархический QoS с парой сотен тысяч классов на одном интерфейсе - свитч так не умеет;
исходя из прошлого пункта - у роутеров гораздо сложнее и software и firmware (я имею в виду, то что исполняется на CPU и микропрограммы/архитектура ASICов);
а появились роутеры достаточно просто. Вот были несколько разных видов локальных сетей (lan - это сеть с одним видом технологии передачи данных и соответственно, как-то локализованная с точки зрения физики в которой хосты могут достигать друг-друга обращась по адресу привязанному непосредственно к интерфейсу (mac как-правило)) - token-ring такой, token-ring-сякой, eth, модемные пулы всякие. И если в lan-е или двух одинаковых lan-ах как-то можно общение наладить, то если есть сетка thin-TR, а в соседнем здании thick-TR и еще модемный пул рядом стоит - это беда. И нужно устройство, которое имеет набор интерфейсов с разной технологией, а более того идея как передавать данные между сетями с разной технологей. Нужна абстракция, с адресами непривязанными к железу и методы связывания абстрактных адресов с физическими. Вот отсюда и появился IP - это та самая абстракция и ARP или NDP и методы инкапсуляции данных как связь абстракции с реальностью. Ну и устройство с разными интерфейсами и работающее на основе именно адресов внутри этой абстракции (см. пункт первый в описании про роутеры) - роутер. Всё предельно просто и вытекает логично из необходимостей. Там еще много было всего связанного с отказоустойчивостью, потерями, надежностью и т.д и всё разрабатывалось одновременно, поэтому не просто ip, а сразу tcp/ip, но именно роутеры появились из-за IP.
Infra as a code - решение всех проблем.
Пользователь заводет на заявку "запилите мне базу и кролика", а описывает требуемую инфру в виде, допустм yaml и сабмитит. Либо в заявку, либо PR в git.
Первым делом yml проверяется а-ля линтером - все что нужно в yml-е есть, какого-нужно формата, в нужных диапазонах.
Потом yml преобразуется на основе шаблонов в конфиги для систем управления - конфиг для терраформа, плейбуки для ансибла. И вот в них-то уже и заложены те саме требуемые паттерны - сколько и каких машин для PGsql, сколько и где для rabbit, выделяются адреса, сети, vni в ipam (через api, автоматически), формируются из шаблонов плейбуки. И потом оно все исполняется, валидируется пост-деплой скриптом и просят пользователя нажать кнопочку "я доволен".
Никаких специалистов и очередей.
Это та самая книга, что доступна с сайта RedHat для скачивания бесплатно теперь за 700р?
дистриб 12мб? чо-то слабо верю. одна только скопмиленная либа на гошечке будет как раз 12мб размером, т.к. туда весь go-runtime прилинкуется.
ты просто еще до гиперболической геометрии не дорос, поэтому за теорему Пифагора держишься. так и в остальном - goto плохо, но до определенного момента.
Видимо, статья не совсем о железе
судя по всему ты даже не понял о чем речь. "система хранения" это не всегда "хранилка" (sds, nas или старые добрые san), просто кому-то не нужно опускаться настолько далеко. san-техники уже давно стали "черной командой".
OSMP (он же KSC) - Open Single Management Platform (Kaspersky Security Center) - это не система управления фаерволлами. Это - центр управления продуктами ЛК. Сейчас с его помощью управляются агенты KES* (endpopoint security) и XDR (eXtended Detect & Response). Насколько я понимаю, чистого KSC в природе нет и в пилоте должен был быть XDR и NGFW не только управляется из KSC но и интегрируется с сами уже развернутым внутри XDR сливая туда логи для анализа. То есть получается комплекс сетевой безопасности из NGFW + XDR и оба они управляются из зонтика KSC(OSMP).
телекомы назывались телекомами еще когда Ростелекома не было в природе. и второй вопрос - кто такие "мы"? король?
если б вы еще и зарплату нормальную предлагали...
ну вот нахуя столько мата в статье?
боже, сколько можно воды налить в старую всем известную hub & spoke topology. Это называется "набивание собственной значимости", целенаправленное переусложнение с целью показать, что мы незаменимы и doing serious business(c).
а сколько денег вы заплатили, чтоб решали ваши проблемы?
Только бедный ВТБ кашляет и плюётся кровью от платформы Сфера. Например, некоторые подразделения еще три года назад задавали вопрос "А будет ли у Сферы внешний API как у jira/confluence? А ты мы все свои процессы уже автоматизировали и нам будет больно" и были буквально посланы менеджерами Т1 по внедрению Сферы в банке. Насколько я знаю - проблема существует до сих пор. И это только один из многочисленных примеров проблем "платформы" и их решения.
правильно, не надо сюда. Проходите мимо. Курьеры полчают больше, строители и продавцы в 5ку более нужны, опять же: есть благородная профессия - Родину защищать. не нужно в ИТ. Мы справимся.
эммм... мне казалось, что поезд должен ездить. Иначе это урок жесточайшего хардкодинга и детям с первых уроков надо говорить, что так делать нельзя.
добро пожаловать в open-source и вообще в *nix-way. Вам никто ничего не должен. Сделали что-то хорошее - радуйтесь, а не возмущайтесь. Возьмите, да напишите сами патч и отправьте пулл-реквест.
Привет! начните с этого:
https://linkmeup.ru/sdsm/
там целый цикл статей, найдите начало - 0ю часть - и прямо вот с неё.
в ARPANET не было аналогов LAN. host-to-host всегда общались через IMP и не было никаких таких разделений на то что два хоста могут пообщаться друг с другом минуя IMP, просто узнав адрес друг-друга.
но с другой стороны IMP - это не просто роутер, как в текущем понимании. Т.к. логика слоя tcp работала именно на IMP. Ну вот фаргментация пакетов, подтверждения доставки, сборка пакетов обратно и гарантия очередности доставки.
Я бы сказал, что IMP больше похож на самом деле на брокер очередей, чем на роутер. Host-IMP - это скорее API к IMP. А host-host - это прям очередь.
вот описание IMP:
https://walden-family.com/impcode/BBN1822_Jan1976.pdf
ну не совсем ) что роутеры, что свитчи в итоге создают какую-то таблицу форвардинга (FIB) в которой хранят записи, что делать в зависимости от destination. И в принципе этот самый FIB одинаково сложный, что у роутеров, что у современных multilayer-свитчей - dest может быть как просто dst-mac, так и dst-ip или что-от еще суровее, так и "что делать" может быть просто "выплюнь в порт" или сложно "поменяй метку, перепиши dst"/"уложи в vni, отправь к другому vtep".
Вот только у свитчей бывает всего один тип интерфейсов - ethernet. Или ATM. Или infiniband. Или... Но не бывает свитча eth + FR. А роутер - бывает. Вот и основная разница.
Есть еще нюансики, конечно: посмотрите мой ответ ниже - https://habr.com/ru/articles/840116/comments/#comment_27237592
в современном мире функции роутеров и свитчей пересекаются. Большинство свитчей умеют маршрутизировать - если например на свитче создано несколько vlan-ов и каждому из них сконфигурирована своя подсеть с ip-адресом на виртуальном свитча, то свитч прекрасно будет маршрутизировать пакеты из одной подсети в другую и соответственно на выходе тегировать нужным vlan. Также многие свитчи L3+ умеют использовать протоколы маршрутизации как igp (ospf, eigp, isis), так и egp (bgp).
В свою очередь, современные роутеры могут коммутировать на основе данных из L2 - можно собрать из портов коммутируемую группу (у разных вендоров называется по-разному - bridge-group, brdige-domain и т.п.) и они будут работать как свитч.
Факторов разницы несколько:
порты на свитче одной и той-же технологии (ethernet, infiniband, ...), а на роутере могут одновременно быть совершенно разные порты - eth, atm, древний frame-relay, набор модемов 3g/4g/5g, какой-нить жуткий ds3/e3 и прочая экзотика; это ключевой момент из-за которого в принципе и появились роутеры;
портовая емкость - у свитчей как правило больше, впрочем бывают и роутеры с большим количеством портов;
стоимость портов на свитчах как правило в разы меньше; отсюда и портовая емкость;
функционал роутеров как правило гораздо шире. Протоколы маршрутизации умеют и свитчи запускать, mpls и evpn - тоже, а вот, допустим, быть vpn-клиентом и сервером или иметь развесистый иерархический QoS с парой сотен тысяч классов на одном интерфейсе - свитч так не умеет;
исходя из прошлого пункта - у роутеров гораздо сложнее и software и firmware (я имею в виду, то что исполняется на CPU и микропрограммы/архитектура ASICов);
а появились роутеры достаточно просто. Вот были несколько разных видов локальных сетей (lan - это сеть с одним видом технологии передачи данных и соответственно, как-то локализованная с точки зрения физики в которой хосты могут достигать друг-друга обращась по адресу привязанному непосредственно к интерфейсу (mac как-правило)) - token-ring такой, token-ring-сякой, eth, модемные пулы всякие. И если в lan-е или двух одинаковых lan-ах как-то можно общение наладить, то если есть сетка thin-TR, а в соседнем здании thick-TR и еще модемный пул рядом стоит - это беда. И нужно устройство, которое имеет набор интерфейсов с разной технологией, а более того идея как передавать данные между сетями с разной технологей. Нужна абстракция, с адресами непривязанными к железу и методы связывания абстрактных адресов с физическими. Вот отсюда и появился IP - это та самая абстракция и ARP или NDP и методы инкапсуляции данных как связь абстракции с реальностью. Ну и устройство с разными интерфейсами и работающее на основе именно адресов внутри этой абстракции (см. пункт первый в описании про роутеры) - роутер. Всё предельно просто и вытекает логично из необходимостей. Там еще много было всего связанного с отказоустойчивостью, потерями, надежностью и т.д и всё разрабатывалось одновременно, поэтому не просто ip, а сразу tcp/ip, но именно роутеры появились из-за IP.