Search
Write a publication
Pull to refresh
3
0
Никита Хохлачев @nioliz

devops

Send message

Главный вопрос: куда подключать пылесос?

Так-то по уму кажется, что пылесос надо подключать в юзерскую сеть, туда же, куда условно подключены мобилы детей. А свой мобильник надо подключать в серверную сеть потому, что я с телефона сервера администрю.

И тут возникает проблема в том, что если мобильник и пылесос находятся в разных Л2 доменах, то приложуха на телефоне отказывается работать с пылесосом!

Да и условный принтер добавлять удобно только тогда, когда он в одной сети с устройствами.

Сложно в этом смысле дома, короче.

Зашел перечитать собственную статью, увидел Ваш комментарий. С Вашей стороны довольно смело заявлять что я понимаю, а что нет. :) Особенно, когда сами пишите явную глупость. Если хочется точности, то "VLAN-порт" на нормальном языке называется "VLAN Interface", это конфигурационная сущность, появляющаяся в микротике если зайти в меню Interface и создать VLAN. Да, фактическая функция этой сущности в том, чтобы терминировать VLAN. И вот "VLAN Interface" относится к микротику тем, что конкретно в микротике терминация VLAN осуществляется именно через этот несчастный "VLAN Interface".

Далее, сам интерфейс всегда L2. IP-адрес, привязанный к интерфейсу, эту ситуацию не меняет. Потому что на самом деле сам интерфейс никакой обработки выше L2 уровня не производит, а сопоставление с интерфейсом используется уже на следующем уровне, на схеме интерфейс отвечает за этапы "декапсуляция" и "инкапсуляция":

Сама схема если что взята отсюда:

https://habr.com/en/articles/345270/

Всё неверно. =)

Во-первых, чем более премиумный сегмент занимает вещь, тем больше можно заложить наценку на единицу. Бриллиантовое колье может продаваться и в 100 раз дороже самих бриллиантов, а шариковую ручку за 15 рублей производить рентабельно могут только производства, где до идеала вылезаны все бизнес-процессы.

Потому если хочется начать производить что-то новое, надо либо сразу запускать миллионные тиражи, либо начинать с премиум сегмента. Иначе просто по деньгам уйдёшь в минус и разоришься. Потому и нужен и брокер и магазин приложений и всё остальное.

Второе, у меня приятель ездит на Тесле, его всё вполне устраивает по количеству зарядок в Питере. Говорит, что более чем достаточно, многие при этом просто бесплатные. То есть, он часто вообще не платит за те километры, которые проехал. Да, они субсидируются государством, но всё равно удобно же?

Третье, автор статьи видимо дома не пользуется двухтарифным счетчиком. Электричество ночью стоит дешевле, но несмотря на это его всё равно уходит меньше. Киловатты, выделенные на день, совершенно неверно считать постоянно потребленными. Пришли все домой после работы, включили чайник и микроволновку, холодильник постоянно открывают-закрывают, он нагревается и включает мотор, жена смотрит телевизор на кухне -- вот потребление 6 кВт на дом без учёта отопления. Потом все угомонились, легли спать, перед сном поставив на зарядку телефоны, сигареты, книжки и машину. Машина при этом ест пускай даже 3,5 кВт, зато без всего остального в 5 уложимся. И это 5 более дешевых, ночных киловатт. За ночь автомобиль зарядится вполне. Да, мой коллега заряжает Теслу на платной стоянке у работы, за пол дня заряжает процентов 40, что считает самым экономичным с точки зрения срока жизни аккумуляторов.

Четвертое, а зачем скажем мне электромобиль без магазина приложений, брокера и всякого такого? Ну, у меня так-то есть машина, да, бензиновая, но с чего бы я стал её менять на электрическую, если набор функций тот же? А вот на машину с широким спектром новых интересных опций с удовольствием посмотрю в магазине, а там посмотрим.

Пятое, на тему параноиков и управления из облака, лично мне вот это кажется просто нереально крутым! А если кому нет -- они просто не целевая аудитория. Пускай хоть на карбюраторном УАЗике ездят, их право, а у нас свободная страна. Он вот кстати точно ничего никуда не отсылает и переживёт даже ядерный взрыв. А я вообще могу забыть где именно машину оставил. И было бы круто иметь к ней постоянное облачное подключение. Да и возможность её через облако выключить одной кнопкой это тоже огромный плюс! Потому что эта возможность сразу снижает ценность автомобиля у угонщиков.

Короче, удивительно не по делу написано на мой взгляд.

Очень-очень круто! Но еще поддержку WiFi-устройств в оффлайн сделайте пожалуйста? А то вот есть у меня ZigBee лампочка и ZigBee датчик влажности, а также WiFi-умная розетка, через которую включается вытяжка. Я очень рад, что могу лампочку включить без Интернета, это на самом деле прямо здорово, но грустно, что вытяжка без того же Интернета не включится если в ванной влажность выросла.

Так именно это я и сделал, если почитаете текст:

dnf module enable php:remi-7.4 -y

Ошибка звучала "Неподдерживаемая версия php", минимальная допустимая была кажется 7.3.

Аналогично было с версией постгреса. Просто минимально совместимая была новее, чем устанавливаемая по умолчанию.

У нас в Питере на спуск по эскалатеру уходит примерно 2-3 минуты. В час пик поезда приходят примерно каждые 1-1,5 минуты. За время моего спуска пара поездов уйдет. Если я бегу в K=2, то я в среднем попадаю на предыдущий поезд почти всегда. А могу даже на позапрошлый!

Я считаю, что заббикс во многих случаях должен дополняться графаной. В графане метрики собирают программисты для отладки своего ПО, в заббиксе метрики собираются для админов, чтобы искать проблемы инфраструктуры. И если метрики программистов нужны им сразу, то метрики админов обычно могут подождать не то, что пару часов, но и пол дня. Поэтому именно ускорять процесс специально я для себя смысла не вижу. Но если бы захотел, я бы снизил таймауты обновления скажем до 10 минут и получал бы добавленный сервер за 20.

А так, для меня автообнаружение сервера является критерием правильной настройки всей цепочки. Если оно не работает, возможно сервер не получает каких-то данных, необходимых для добавления хоста в конфигурацию?

Но если всё же хочется подойти к ситуации с той стороны и жестко использовать ансибл, советую посмотреть вот сюда:

https://github.com/ansible-collections/community.zabbix

Мы в своё время его изучали, продукт интересный, но под наши бизнес-процессы не подошёл, а Вам может и зайдёт :).

Честно говоря, мой комментарий был намёком на то, что вот подробное сравнение ансибла с терраформом является действительно интересной темой для статьи, а сравнивать терраформ с его отсутствием... На мой взгляд абсолютно очевидно, что любая система управления конфигурацией лучше её отсутствия и доказывать этот тезис просто незачем.

Я вот чего-то не понял... Зачем нужен Terraform... когда есть ansible?

Да, согласен, звучит очень здорово :). Особенности выбора оборудования по производительности мне на глаза ни разу не попадались, а все знакомые обычно мыслят категориями "микротик тормозит, значит надо просто купить более дорогой".

Вам прямо с цитатами из этой самой википедии показать чем именно она мне не нравится? :) -- Но если коротко, по ней очень сложно понять, как жить когда микротик ни хрена не основная часть сети, а очень даже вторичная.

Добавил подписку, буду ждать. :)

Вот я не готов мыслить пространствами и полями. Я как раз привык мыслить на уровне тэгов, поэтому и не заходит мне родная документация. Ну и собственно я думаю, что такой не один, поэтому и попытался перевести на привычную мне терминологию обычные описания.

Ну, тэг как виртуальное свойство пакета работает ровно как я написал, а тэг как набор бит в заголовке я честно говоря не представляю как проверить когда по факту пропадает потому, что из самой таблицы маршрутизации пакет для анализа не выдернуть. А с точки зрения поведения оборудования нет никакой разницы между "тэг 3 прописан в пакете, идущем в коммунаторе с другими пакетами" или "тэг 3 прописан в виртуальном коммутаторе, в котором идут только пакеты для этого тэга".

Ну вот есть у нас бридж, в нём два VLAN, номера 1 и 2. В свойствах бриджа прописан тэг 1, тэг 2 создан через создание влана в бридже.

В бридж добавляем один интерфейс VLAN с тэгом 2, ставим туда айпишник и еще на сам интерфейс бриджа ставим айпишник. И в довершение добавляем туда же физический порт, например 1, при этом в свойствах моста ставим тэг 1 опять же.

Снаружи с 1 порта в такой конфигурации можно снимать нетегированный 1 влан и тегированный второй и пинговать соответствующие адреса.

И в принципе можно считать, что это по факту два разных виртуальных коммутатора, один для 1 влана, второй для 2. И что пакеты, входящие без тэга отправляются в одну таблицу коммутации, а с тэгом 2 -- в другую.

Но если мы считаем, что мост всё-таки один, то логика нисколько не меняется: пакет приходит без тэга на внешний порт, попадает в мост без тэга (потому что тэг порта и моста совпадают) и идёт на интерфейс с адресом.

Или второй пакет приходит с тэгом 2, идёт в тот же мост, тэг с него не снимается потому, что в свойствах порта указан другой тэг, в единой таблице коммутации тэг присутствует, по нему пакет идёт к интерфейсу VLAN, где с него снимается тэг постольку, поскольку в свойствах этого порта тэг 2 указан. И дальше идёт на обработку кому он там пологается без тэга.

Или если говорить ближе к программированию, с точки зрения поведения, нет разницы между цифрой в столбце таблицы и цифрой-номером таблицы. А это же гайд для пользователей, а не для разработчиков микротов.

Ах да, еще не ответил на это:

Кроме того на wlan интерфейсах вне капсмана есть фича VLAN mode + VLAN ID позволяющая интерфейсу "забирать" в бридже нужный VLAN с тегом и передавать дальше снимая тег.

Так это на всех интерфейсах, не только wlan: стоит где-то в свойствах интерфейса вписать номер тэга, этот тэг снимается после интерфейса. И я об этом написал в пункте 2.

Про капсман лично мне конкретно эта ссылка и не помогла (как и вагон еще всяких) потому что она как раз и даёт типовое решение вместо понимания вопроса. Мне нужно было заворачивать трафик из капсмана вместо микротика на другой узел через тегированный порт и прочитав статью я тогда не понял, как именно это реализовать. Вроде готовая конфигурация работает, а как ей "доработать напильником" не понятно.

Остальные ссылки добавил в статью, хотя на мой взгляд в материале, помеченном как tutorial обсуждать такие тонкости как "на этом чипе оно будет работать, но возможно будет тормозить из-за программной реализации" не совсем верно и я действительно считаю, что это должно быть в другой статье, которую всё ещё прошу написать Вас :).

Оба-на, вот про меню switch спасибо, реально не сталкивался. Покурю маны на эту тему с интересом.

Но не будет с ним работать по L3 и соответственно влан интерфейсы на этом бридже с вланом которого нет этого бриджа как tagged в меню bridge VLANs работать не будут

А что тогда останется? -- Я не вижу практической разницы между своим высказыванием и Вашим.

Если Вы считаете, что надо было указать дополнительную ссылку -- кидайте её сюда, если она стоящая, я поправлю статью.

Information

Rating
Does not participate
Works in
Date of birth
Registered
Activity