Если очень грубо, для обработки ip-пакетов (через raw socket), в том числе броадкасты, сетевому стеку нужен настроенный ip-адрес. Собственно, именно так и работает dhcp-сервер. и чтобы получать броадкаст-поток с интерфейса и выдавать адреса он требует наличия адреса из раздаваемой сети, иначе не запустится.
raw socket - это raw ip socket, для него нужен сконфигурированный на интерфейсе IP стек. иначе работать нужно уже на уровне ethernet. Например, через bpf
Да, возможно, я тут был как обычно слегка яндекс-центричен ;) На небольших масштабах, думаю, это вполне оправдано, тем более как единый источник информации. Хотя раньше это было не очень удобно.
Дело не напрямую в переходе на микросервисы, а в том, что мы перешли к парадигме IaaS - освободили себя от необходимости обслуживать железо, реализовывать его мониторинги итд. А микросервисы позволяют полагаться не на бэкапы, а на то, что в случае чего мы выкатываем последнюю стабильную версию контейнера
Так ведь об этом и история - на тот момент все скромные силы и помыслы нашей команды в 4 человека были направлены на сеть - Датацентры, магистраль, внешняя связность, Cloud InterConnect, всё остальное было по почти остаточному принципу - чтобы нашу рутину сгладить и оптимизировать. Не было ни мониторингов, ни снапшотов этих машин, ни плейбуков. Притом, что, я повторюсь, мы понимали, что это яма, что мы сами себе копаем.
Виртуалка в публичном облаке появилась ближе к концу повествования. А сначала у нас была виртуалка на выделенной железной машине, которую обслуживали полностью мы сами.
Всё ещё далеко не прямая связь между причинами и следствием. Тут должны потрудиться тараканы в голове.
Так можно довести и до того, что производство унитазов - критическая отрасль, от которой зависит жизнь людей. Что если в нём плохо смывается содержимое - и год за годом точит психологическое здоровье владельца?
Ну, согласитесь, это несколько натянутые примеры? Я говорю про смерть или вред здоровью как прямое следствие ошибок или проблем. Нельзя сравнить это с обрушением моста или врачебной ошибкой.
Пограничными на сегодняшний день являются медицина и автомобили, напичканные электроникой.
Да вопросов нет, что это можно разными способами сделать.
Просто тут случился интересный, хотя и практически бесполезный разрыв привычных представлений)
Процитирую Бориса Лыточкина :)
Если очень грубо, для обработки ip-пакетов (через raw socket), в том числе броадкасты, сетевому стеку нужен настроенный ip-адрес. Собственно, именно так и работает dhcp-сервер. и чтобы получать броадкаст-поток с интерфейса и выдавать адреса он требует наличия адреса из раздаваемой сети, иначе не запустится.
raw socket - это raw ip socket, для него нужен сконфигурированный на интерфейсе IP стек. иначе работать нужно уже на уровне ethernet. Например, через bpf
Ну как автор я к этому давно привык. Поэтому обиды нет никакой)
Спасибо за ваш комментарий. Ковыряли мы это втроём и с большим интересом!
Да, возможно, я тут был как обычно слегка яндекс-центричен ;) На небольших масштабах, думаю, это вполне оправдано, тем более как единый источник информации. Хотя раньше это было не очень удобно.
Кажется, мы разный смысл вкладываем в слова "сборка" и "полноценный" :)
Дело не напрямую в переходе на микросервисы, а в том, что мы перешли к парадигме IaaS - освободили себя от необходимости обслуживать железо, реализовывать его мониторинги итд.
А микросервисы позволяют полагаться не на бэкапы, а на то, что в случае чего мы выкатываем последнюю стабильную версию контейнера
Так ведь об этом и история - на тот момент все скромные силы и помыслы нашей команды в 4 человека были направлены на сеть - Датацентры, магистраль, внешняя связность, Cloud InterConnect, всё остальное было по почти остаточному принципу - чтобы нашу рутину сгладить и оптимизировать.
Не было ни мониторингов, ни снапшотов этих машин, ни плейбуков. Притом, что, я повторюсь, мы понимали, что это яма, что мы сами себе копаем.
Благо лаба в публичном облаке поднимается очень легко)
В отличие от лабы сетевой.
Вы ведь читали текст? Правда же?
Виртуалка в публичном облаке появилась ближе к концу повествования. А сначала у нас была виртуалка на выделенной железной машине, которую обслуживали полностью мы сами.
Да рейд-то восстановили. Но получили доказательства, что жить так дальше ну никак нельзя.
Ну это же не единственный механизм. 1588 поддерживается не всем оборудованием. Поэтому у кого-то sync e как дешёвый эрзац.
Но даже 1588 - это попытка натянуть сову на глобус)
Всё ещё далеко не прямая связь между причинами и следствием. Тут должны потрудиться тараканы в голове.
Так можно довести и до того, что производство унитазов - критическая отрасль, от которой зависит жизнь людей. Что если в нём плохо смывается содержимое - и год за годом точит психологическое здоровье владельца?
Хабы живы!
Вообще вы, получается, обладатель музейной редкости!
Я не понял, это хорошая ирония или вы всерьёз? :)
Где реализована коммутация/маршрутизация/ACL - в железе или на CPU
Вероятность битовых ошибок и их исправление
Отказоустойчивость компонентов
Качество питания и устойчивость к скачкам в сети
Глубина и качество тестирования ПО, отвечающего за Control Plane
То же, но про взаимодействие с SDK чипа, реализующего программирование правил в железо.
Возможность обновления ПО (неактуально, правда, для старых коробок)
А кольца имело смысл собирать на L3 :)
Один из примеров в публикации - это ядро, собранное на кольцах под управлением RRPP - там одно неловкое движение и критический инцидент.
Подпишусь под каждым словом!
Да, бывало такое. И даже в масштабах ядра оператора сети, где не особо ожидаешь дублирования MAC'ов в отличие от сегмента клиентского оборудования.
И порой изменение MAC'а при вводе в эксплуатацию даже в инструкции по настройке прописывали)
Ну, согласитесь, это несколько натянутые примеры? Я говорю про смерть или вред здоровью как прямое следствие ошибок или проблем. Нельзя сравнить это с обрушением моста или врачебной ошибкой.
Пограничными на сегодняшний день являются медицина и автомобили, напичканные электроникой.