Очень-очень круто! Но еще поддержку WiFi-устройств в оффлайн сделайте пожалуйста? А то вот есть у меня ZigBee лампочка и ZigBee датчик влажности, а также WiFi-умная розетка, через которую включается вытяжка. Я очень рад, что могу лампочку включить без Интернета, это на самом деле прямо здорово, но грустно, что вытяжка без того же Интернета не включится если в ванной влажность выросла.
У нас в Питере на спуск по эскалатеру уходит примерно 2-3 минуты. В час пик поезда приходят примерно каждые 1-1,5 минуты. За время моего спуска пара поездов уйдет. Если я бегу в K=2, то я в среднем попадаю на предыдущий поезд почти всегда. А могу даже на позапрошлый!
Я считаю, что заббикс во многих случаях должен дополняться графаной. В графане метрики собирают программисты для отладки своего ПО, в заббиксе метрики собираются для админов, чтобы искать проблемы инфраструктуры. И если метрики программистов нужны им сразу, то метрики админов обычно могут подождать не то, что пару часов, но и пол дня. Поэтому именно ускорять процесс специально я для себя смысла не вижу. Но если бы захотел, я бы снизил таймауты обновления скажем до 10 минут и получал бы добавленный сервер за 20.
А так, для меня автообнаружение сервера является критерием правильной настройки всей цепочки. Если оно не работает, возможно сервер не получает каких-то данных, необходимых для добавления хоста в конфигурацию?
Но если всё же хочется подойти к ситуации с той стороны и жестко использовать ансибл, советую посмотреть вот сюда:
Честно говоря, мой комментарий был намёком на то, что вот подробное сравнение ансибла с терраформом является действительно интересной темой для статьи, а сравнивать терраформ с его отсутствием... На мой взгляд абсолютно очевидно, что любая система управления конфигурацией лучше её отсутствия и доказывать этот тезис просто незачем.
Да, согласен, звучит очень здорово :). Особенности выбора оборудования по производительности мне на глаза ни разу не попадались, а все знакомые обычно мыслят категориями "микротик тормозит, значит надо просто купить более дорогой".
Вам прямо с цитатами из этой самой википедии показать чем именно она мне не нравится? :) -- Но если коротко, по ней очень сложно понять, как жить когда микротик ни хрена не основная часть сети, а очень даже вторичная.
Вот я не готов мыслить пространствами и полями. Я как раз привык мыслить на уровне тэгов, поэтому и не заходит мне родная документация. Ну и собственно я думаю, что такой не один, поэтому и попытался перевести на привычную мне терминологию обычные описания.
Ну, тэг как виртуальное свойство пакета работает ровно как я написал, а тэг как набор бит в заголовке я честно говоря не представляю как проверить когда по факту пропадает потому, что из самой таблицы маршрутизации пакет для анализа не выдернуть. А с точки зрения поведения оборудования нет никакой разницы между "тэг 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 работать не будут
А что тогда останется? -- Я не вижу практической разницы между своим высказыванием и Вашим.
VLAN-порт как раз и занимается тем, что снимает тэг, указанный в его свойствах. То есть, судя по тому, что я вижу, у Вас есть тегированный трафик, который приходит в таки VLAN-порт, где тэг снимается и дальше в логику сервера идёт уже нетегированным. Вот именно эта -- одна из тех особенностей, которые я и пытался показать. Пунктом 2, если быть более точным.
Вот честно, я очень рад, что в комментариях так много людей, знающих вопрос лучше меня. И я буду еще больше рад, если скажем Вы (или кто угодно другой) напишите статью, где распишите подробнее те моменты, которые я упустил, включая разницу настройки тех же VLAN на разном оборудовании, сам с удовольствием её почитаю и скажу искреннее спасибо. Я сам всегда придерживаюсь позиции "критикуя -- предлагай" и другим советую действовать также. Лично мне вот того объёма информации, который я здесь привёл, не хватало на протяжении нескольких месяцев. И привёл тут я его с единственной целью -- помочь тем людям, которые попали в такую же ситуацию, как я раньше. И да, по нему лично я несколько железок от CRS до cAP ac. Перешитый свитч мы в этой конфигурации тоже смотрели, но на демо-стенде, где производительность конечно же было объективно не оценить.
И я буду еще больше рад, если из-за моей статьи начнётся холивар, по результатам которого подобных статей появится несколько, от разных авторов, дополняющих друг друга. :)
Ну, хорошо, добавил описание более стандартного механизма. На мой взгляд он не такой удобный, но это дело вкуса. И заодно ссылку на совсем официальную документацию.
Спасибо :)
Очень-очень круто! Но еще поддержку 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: стоит где-то в свойствах интерфейса вписать номер тэга, этот тэг снимается после интерфейса. И я об этом написал в пункте 2.
Про капсман лично мне конкретно эта ссылка и не помогла (как и вагон еще всяких) потому что она как раз и даёт типовое решение вместо понимания вопроса. Мне нужно было заворачивать трафик из капсмана вместо микротика на другой узел через тегированный порт и прочитав статью я тогда не понял, как именно это реализовать. Вроде готовая конфигурация работает, а как ей "доработать напильником" не понятно.
Остальные ссылки добавил в статью, хотя на мой взгляд в материале, помеченном как tutorial обсуждать такие тонкости как "на этом чипе оно будет работать, но возможно будет тормозить из-за программной реализации" не совсем верно и я действительно считаю, что это должно быть в другой статье, которую всё ещё прошу написать Вас :).
Оба-на, вот про меню switch спасибо, реально не сталкивался. Покурю маны на эту тему с интересом.
А что тогда останется? -- Я не вижу практической разницы между своим высказыванием и Вашим.
Если Вы считаете, что надо было указать дополнительную ссылку -- кидайте её сюда, если она стоящая, я поправлю статью.
VLAN-порт как раз и занимается тем, что снимает тэг, указанный в его свойствах. То есть, судя по тому, что я вижу, у Вас есть тегированный трафик, который приходит в таки VLAN-порт, где тэг снимается и дальше в логику сервера идёт уже нетегированным. Вот именно эта -- одна из тех особенностей, которые я и пытался показать. Пунктом 2, если быть более точным.
Вот честно, я очень рад, что в комментариях так много людей, знающих вопрос лучше меня. И я буду еще больше рад, если скажем Вы (или кто угодно другой) напишите статью, где распишите подробнее те моменты, которые я упустил, включая разницу настройки тех же VLAN на разном оборудовании, сам с удовольствием её почитаю и скажу искреннее спасибо. Я сам всегда придерживаюсь позиции "критикуя -- предлагай" и другим советую действовать также. Лично мне вот того объёма информации, который я здесь привёл, не хватало на протяжении нескольких месяцев. И привёл тут я его с единственной целью -- помочь тем людям, которые попали в такую же ситуацию, как я раньше. И да, по нему лично я несколько железок от CRS до cAP ac. Перешитый свитч мы в этой конфигурации тоже смотрели, но на демо-стенде, где производительность конечно же было объективно не оценить.
И я буду еще больше рад, если из-за моей статьи начнётся холивар, по результатам которого подобных статей появится несколько, от разных авторов, дополняющих друг друга. :)
Ну, хорошо, добавил описание более стандартного механизма. На мой взгляд он не такой удобный, но это дело вкуса. И заодно ссылку на совсем официальную документацию.