Что будет, если мы уберем первое правило в цепочке INPUT?
Final Results
17%
Ничего не будет
10%
Увеличится нагрузка на CPU
4%
Перестанет работать FTP-сервер
11%
Пропадет доступ к серверу снаружи
14%
Пропадет доступ к серверу с любого интерфейса
3%
Возможны проблемы при добавлении иных правил
41%
Посмотреть ответы
👍7
Ответы на вчерашние вопросы
В комментариях к предыдущей заметке нам посетовали, что мол мы не предоставили полной информации по вопросу, поэтому…
А нет никакого поэтому и быть не может. Любая диагностика и поиск неисправностей – это задача с неполной информацией. Обычно мы имеем некую систему и некое поведение системы, которое не является ожидаемым.
При этом у нас нет полной информации о том, что происходит, нам нужно опираясь на доступные данные максимально восстановить картину происходящего либо выдвинуть рабочую гипотезу, которую потом можно проверить.
И навык анализа в условиях недостатка информации является для администратора одним из важнейших. Тем более что были приведены варианты ответов (читай – гипотезы), которые следовало только проверить.
Ладно, вчера мы решили дать задачу попроще, с полной информацией, практически исчерпывающей, так как ответы фактически уже написаны.
Тем не менее на первый вопрос правильно ответила только половина читателей (из тех, кто отвечал), при этом треть из них ответила, скажем так, на «троечку». Почему?
Потому что ответ «Не будет» формально верный, но ниже есть более развернутый ответ, который наиболее точно характеризует поведение системы.
Давайте разберемся, порт 34567 в брандмауэре открыт и проблемы подключится к WireGuard не возникнет, подключение будет работать и узлы смогут обмениваться данными друг с другом.
Но вот выйти в интернет не получится, потому что цепочка FORWARD не содержит ни одного правила, разрешающего транзитный трафик.
Поэтому правильный ответ на первый вопрос: «Подключение будет, выход в интернет нет».
Со вторым вопросом все еще хуже, на него правильно ответили только 27% читателей, т.е. меньше трети.
Хотя он, в принципе, даже проще предыдущего. После того, как мы уберем первое правило, которое разрешает RELATED,ESTABLISHED – т.е. уже установленные соединения, у нас в цепочке INPUT останутся только правила для новых пакетов (NEW), все остальное будет запрещено последним REJECT.
Таким образом при попытке установить соединение у нас пройдет только первый пакет, а все остальные будут отброшены брандмауэром. Что сделает сервер недоступным с любого интерфейса, так как правила не содержат такого критерия.
А самое интересное в том, что правильный ответ со всеми необходимыми обоснованиями был дан еще вчера вечером в одном из первых комментариев.
В общем – выводы каждый должен сделать самостоятельно.
В комментариях к предыдущей заметке нам посетовали, что мол мы не предоставили полной информации по вопросу, поэтому…
А нет никакого поэтому и быть не может. Любая диагностика и поиск неисправностей – это задача с неполной информацией. Обычно мы имеем некую систему и некое поведение системы, которое не является ожидаемым.
При этом у нас нет полной информации о том, что происходит, нам нужно опираясь на доступные данные максимально восстановить картину происходящего либо выдвинуть рабочую гипотезу, которую потом можно проверить.
И навык анализа в условиях недостатка информации является для администратора одним из важнейших. Тем более что были приведены варианты ответов (читай – гипотезы), которые следовало только проверить.
Ладно, вчера мы решили дать задачу попроще, с полной информацией, практически исчерпывающей, так как ответы фактически уже написаны.
Тем не менее на первый вопрос правильно ответила только половина читателей (из тех, кто отвечал), при этом треть из них ответила, скажем так, на «троечку». Почему?
Потому что ответ «Не будет» формально верный, но ниже есть более развернутый ответ, который наиболее точно характеризует поведение системы.
Давайте разберемся, порт 34567 в брандмауэре открыт и проблемы подключится к WireGuard не возникнет, подключение будет работать и узлы смогут обмениваться данными друг с другом.
Но вот выйти в интернет не получится, потому что цепочка FORWARD не содержит ни одного правила, разрешающего транзитный трафик.
Поэтому правильный ответ на первый вопрос: «Подключение будет, выход в интернет нет».
Со вторым вопросом все еще хуже, на него правильно ответили только 27% читателей, т.е. меньше трети.
Хотя он, в принципе, даже проще предыдущего. После того, как мы уберем первое правило, которое разрешает RELATED,ESTABLISHED – т.е. уже установленные соединения, у нас в цепочке INPUT останутся только правила для новых пакетов (NEW), все остальное будет запрещено последним REJECT.
Таким образом при попытке установить соединение у нас пройдет только первый пакет, а все остальные будут отброшены брандмауэром. Что сделает сервер недоступным с любого интерфейса, так как правила не содержат такого критерия.
А самое интересное в том, что правильный ответ со всеми необходимыми обоснованиями был дан еще вчера вечером в одном из первых комментариев.
В общем – выводы каждый должен сделать самостоятельно.
👍20👌4👎3🤔2❤1
Забавная маршрутизация
Маршрутизация – пожалуй одна из самых сложных тем для начинающих, да и не только для них.
Вроде бы с одной стороны все просто, а с другой – не очень. Особенно если у нас есть пересекающиеся маршруты.
Когда-то давно мои заказчики попросили придумать задачку для собеседования на тему маршрутизации и базового понимания сетей.
Задачка простая, но не совсем очевидная.
Итак, имеется следующая таблица маршрутизации:
Будет ли такая таблица работать и какие сети находятся за каждым интерфейсом?
Маршрутизация – пожалуй одна из самых сложных тем для начинающих, да и не только для них.
Вроде бы с одной стороны все просто, а с другой – не очень. Особенно если у нас есть пересекающиеся маршруты.
Когда-то давно мои заказчики попросили придумать задачку для собеседования на тему маршрутизации и базового понимания сетей.
Задачка простая, но не совсем очевидная.
Итак, имеется следующая таблица маршрутизации:
192.168.0.0/24 – eth0
192.168.0.0/25 – eth1
192.168.0.0/26 – eth2
192.168.0.0/27 – eth3
192.168.0.0/28 – eth4
Будет ли такая таблица работать и какие сети находятся за каждым интерфейсом?
❤1👍1
Какие сети находятся за каждым интерфейсом (eth0 - eth4), приведены только последний октет и маска
Final Results
25%
0/24 0/25 0/26 0/27 0/28
3%
0/25 128/26 192/27 224/28 240/28
6%
128/25 64/26 32/27 16/28 0/28
6%
везде 0/24
5%
везде 0/28
5%
зависит от маски в пакете
11%
такая таблица работать не будет
38%
посмотреть ответы
Забавная маршрутизация (ответы)
Есть такой принцип - Бритва Оккама, краткая суть которого в том, что не следует множить сущности без необходимости.
Можно сколько угодно умничать про то, что за интерфейсом может быть сколько угодно любых сетей, но если вопрос прямо спрашивает про сети, то исходим из того, что они там есть.
Итак, у нас есть таблица маршрутизации
И несколько работающих сетей за каждым интерфейсом. Будет ли работать такая таблица? Да, почему нет. Вся тонкость именно в том, как она работает.
Начнем с того, что пакет не содержит такого поля как маска. Только адреса, в нашем случае имеет значение адрес назначения.
Далее вступает в дело таблица маршрутизации, в котором мы ищем наиболее подходящий маршрут для нашего пакета. Если к месту назначения ведут несколько маршрутов, то выбирается маршрут с маской, содержащий наименьшее количество узлов.
В нашем случае это будет 192.168.0.0/28, сеть /28 содержит 16 адресов, поэтому за eth4 у нас может находиться только 192.168.0.0/28.
Сеть /27 содержит уже 32 адреса, но в eth3 будут направлены только адреса не входящие в 192.168.0.0/28, т.е. следующие 16 адресов. Таким образом за eth3 у нас может быть только сеть 192.168.0.16/28.
Сеть 26 содержит уже 64 адреса, но 32 из них входят в уже указанные нами сети, поэтом за eth2 у нас находится сеть 192.168.0.32/27.
Аналогичным образом вычисляем и сети за eth1 – 192.168.0.64/26 и eth0 – 192.168.0.128/25.
Таким образом правильным является третий вариант ответа в вопросе. Количество ответивших правильно и сделать выводы каждый может самостоятельно.
Есть такой принцип - Бритва Оккама, краткая суть которого в том, что не следует множить сущности без необходимости.
Можно сколько угодно умничать про то, что за интерфейсом может быть сколько угодно любых сетей, но если вопрос прямо спрашивает про сети, то исходим из того, что они там есть.
Итак, у нас есть таблица маршрутизации
192.168.0.0/24 – eth0
192.168.0.0/25 – eth1
192.168.0.0/26 – eth2
192.168.0.0/27 – eth3
192.168.0.0/28 – eth4
И несколько работающих сетей за каждым интерфейсом. Будет ли работать такая таблица? Да, почему нет. Вся тонкость именно в том, как она работает.
Начнем с того, что пакет не содержит такого поля как маска. Только адреса, в нашем случае имеет значение адрес назначения.
Далее вступает в дело таблица маршрутизации, в котором мы ищем наиболее подходящий маршрут для нашего пакета. Если к месту назначения ведут несколько маршрутов, то выбирается маршрут с маской, содержащий наименьшее количество узлов.
В нашем случае это будет 192.168.0.0/28, сеть /28 содержит 16 адресов, поэтому за eth4 у нас может находиться только 192.168.0.0/28.
Сеть /27 содержит уже 32 адреса, но в eth3 будут направлены только адреса не входящие в 192.168.0.0/28, т.е. следующие 16 адресов. Таким образом за eth3 у нас может быть только сеть 192.168.0.16/28.
Сеть 26 содержит уже 64 адреса, но 32 из них входят в уже указанные нами сети, поэтом за eth2 у нас находится сеть 192.168.0.32/27.
Аналогичным образом вычисляем и сети за eth1 – 192.168.0.64/26 и eth0 – 192.168.0.128/25.
Таким образом правильным является третий вариант ответа в вопросе. Количество ответивших правильно и сделать выводы каждый может самостоятельно.
🔥23👍12
Пятничное, вечернее. О жизни
Идем из гостей домой, решили зайти в магазин.
Навстречу семья, мама и папа впереди с пакетами, сзади топают девочка и мальчик, лет 9 и 12.
Не знаю о чем они там говорили, но при нашем приближении девочка отчитывала мальчика:
- Ты неправильно говоришь! Люди - это афганцы, а афганка - это конопля...
Жена призналась мне, что до этого она не знала, что афганка - это конопля.
Вот такие детки в клетке...
Идем из гостей домой, решили зайти в магазин.
Навстречу семья, мама и папа впереди с пакетами, сзади топают девочка и мальчик, лет 9 и 12.
Не знаю о чем они там говорили, но при нашем приближении девочка отчитывала мальчика:
- Ты неправильно говоришь! Люди - это афганцы, а афганка - это конопля...
Жена призналась мне, что до этого она не знала, что афганка - это конопля.
Вот такие детки в клетке...
😁30
Понедельник – день тяжелый
А после длинных выходных – тем более. Мы уже давно отметили интересную статистику, перед выходными количество обращений всегда снижается. А перед длинными выходными и праздниками оно снижается существенно.
Особенно заметна эта тенденция если предпраздничный сокращенный день связан с поздравлениями в коллективе, тогда количество обращений в такой день может упасть более чем наполовину по сравнению с обычным рабочим днем.
Причина тут проста – никто не хочет заморачиваться в преддверии длинных выходных или праздников. Ведь куда лучше слушать поздравления и потягивать шампанское, нежели заниматься какими-то проблемами.
Это касается как обычных сотрудников, так и технического персонала. В целом такой подход имеет под собой здравое зерно, если проблема не носит критический характер, то ее спокойно можно решить в первый рабочий день.
Но проблема в том, что таким образом «под ковер» могут заметаться и достаточно серьезные проблемы, опять-таки сугубо из того, что никому не хочется работать в праздники. Ну и памятуя о том, что инициатива делает с инициатором.
Мониторинг, скажете вы, и снова будете не правы. Уведомления от мониторинга приходят таким же людям, как и все остальные и эти люди также не горят желанием работать на выходные или в праздники.
Можно, конечно, поставить многоуровневые уведомления и спускать задачи принудительно сверху вниз, но надо понимать, что тут возникнут дополнительные негативные факторы, такие как небрежное выполнение работы (лишь бы триггер перестал срабатывать), выполнение работ в состоянии алкогольного опьянения и т.д. и т.п.
И сотрудников тоже можно понять, выходить в праздничный день на работы, которые можно сделать в рабочее время тоже никто не хочет. Тем более что формально такие выходы никак не оформляются, так как и выхода как такового нет, большинство работ производится удаленно.
Поэтому самым разумным будет перед праздниками сделать максимальный аудит инфраструктуры на выявление слабых мест и заблаговременная их профилактика. А на сами праздники оставить только действительно критически важные работы, которые не терпят отлагательств.
Все остальное вполне потерпит до понедельника. Но при этом надо быть готовым, что количество заявок в понедельник, особенно в первой половине дня резко вырастет и к этому надо быть готовым и не планировать на этот период никаких важных дел.
Также не советуем планировать на праздники какие-то внедрения и прочие работы, которые требуют отсутствия пользователей, лучше запланируйте это на обычные выходные, потому что мало кто будет рад в праздник сидеть на работе, даже за дополнительные деньги вместо того, чтобы провести его с семьей.
Конечно, нельзя исключать аварий или иных сбоев, но как мы уже писали, большинство слабых мест всегда можно заранее выявить при помощи аудита и правильно настроенного мониторинга.
Скажем даже больше, определенный процент инцидентов как раз бывает связан со стремлением сотрудников закрыть задачу до выходных или праздников, что заставляло пренебрегать регламентом и грубо нарушать правила безопасности.
И тогда обычная рабочая ситуация внезапно становилась авральной. Просто так, на ровном месте, потому что начальство потребовало закрыть все задачи до (дату можете вписать сами), чтобы самим красиво отчитаться наверх.
Лично мы считаем такую практику сугубо порочной и исходим из принципа, что если задачу можно отложить на понедельник – то ее следует отложить на понедельник.
Очевидный плюс такого подхода – что задачи не будут «заметаться под ковер», а вовремя вносится в систему учета заявок и будут показывать реальную загрузку на первый рабочий день новой недели.
Это, в свою очередь, позволит избежать ситуации, когда в понедельник задачи «внезапно» сваливаются как снег на голову.
А какой подход практикуете вы? Бывает ли у вас завал по понедельникам?
А после длинных выходных – тем более. Мы уже давно отметили интересную статистику, перед выходными количество обращений всегда снижается. А перед длинными выходными и праздниками оно снижается существенно.
Особенно заметна эта тенденция если предпраздничный сокращенный день связан с поздравлениями в коллективе, тогда количество обращений в такой день может упасть более чем наполовину по сравнению с обычным рабочим днем.
Причина тут проста – никто не хочет заморачиваться в преддверии длинных выходных или праздников. Ведь куда лучше слушать поздравления и потягивать шампанское, нежели заниматься какими-то проблемами.
Это касается как обычных сотрудников, так и технического персонала. В целом такой подход имеет под собой здравое зерно, если проблема не носит критический характер, то ее спокойно можно решить в первый рабочий день.
Но проблема в том, что таким образом «под ковер» могут заметаться и достаточно серьезные проблемы, опять-таки сугубо из того, что никому не хочется работать в праздники. Ну и памятуя о том, что инициатива делает с инициатором.
Мониторинг, скажете вы, и снова будете не правы. Уведомления от мониторинга приходят таким же людям, как и все остальные и эти люди также не горят желанием работать на выходные или в праздники.
Можно, конечно, поставить многоуровневые уведомления и спускать задачи принудительно сверху вниз, но надо понимать, что тут возникнут дополнительные негативные факторы, такие как небрежное выполнение работы (лишь бы триггер перестал срабатывать), выполнение работ в состоянии алкогольного опьянения и т.д. и т.п.
И сотрудников тоже можно понять, выходить в праздничный день на работы, которые можно сделать в рабочее время тоже никто не хочет. Тем более что формально такие выходы никак не оформляются, так как и выхода как такового нет, большинство работ производится удаленно.
Поэтому самым разумным будет перед праздниками сделать максимальный аудит инфраструктуры на выявление слабых мест и заблаговременная их профилактика. А на сами праздники оставить только действительно критически важные работы, которые не терпят отлагательств.
Все остальное вполне потерпит до понедельника. Но при этом надо быть готовым, что количество заявок в понедельник, особенно в первой половине дня резко вырастет и к этому надо быть готовым и не планировать на этот период никаких важных дел.
Также не советуем планировать на праздники какие-то внедрения и прочие работы, которые требуют отсутствия пользователей, лучше запланируйте это на обычные выходные, потому что мало кто будет рад в праздник сидеть на работе, даже за дополнительные деньги вместо того, чтобы провести его с семьей.
Конечно, нельзя исключать аварий или иных сбоев, но как мы уже писали, большинство слабых мест всегда можно заранее выявить при помощи аудита и правильно настроенного мониторинга.
Скажем даже больше, определенный процент инцидентов как раз бывает связан со стремлением сотрудников закрыть задачу до выходных или праздников, что заставляло пренебрегать регламентом и грубо нарушать правила безопасности.
И тогда обычная рабочая ситуация внезапно становилась авральной. Просто так, на ровном месте, потому что начальство потребовало закрыть все задачи до (дату можете вписать сами), чтобы самим красиво отчитаться наверх.
Лично мы считаем такую практику сугубо порочной и исходим из принципа, что если задачу можно отложить на понедельник – то ее следует отложить на понедельник.
Очевидный плюс такого подхода – что задачи не будут «заметаться под ковер», а вовремя вносится в систему учета заявок и будут показывать реальную загрузку на первый рабочий день новой недели.
Это, в свою очередь, позволит избежать ситуации, когда в понедельник задачи «внезапно» сваливаются как снег на голову.
А какой подход практикуете вы? Бывает ли у вас завал по понедельникам?
💯12👍5
Какой подход практикуется у вас?
Anonymous Poll
16%
Стараемся выполнить все задачи до окончания периода
42%
Можно перенести некритичные задачи
10%
Выходные - отличное время доделать все хвосты
12%
Никогда не делай сегодня, то что можно отложить на завтра
2%
Выполнить задачи к сроку любой ценой
5%
Заметаем "под ковер", а там жизнь покажет
12%
Ничего не понятно, но очень интересно
Эксплуатация и эксплуатанты
Мы очень много говорим о автоматизации, внедрении современных технологий и т.д. и т.п., но совсем не задумываемся о тех, кто будет эти системы эксплуатировать.
Хорошо если внедренец и эксплуатант – одно и тоже лицо или связанные договорами на обслуживание и сопровождение. Но куда чаще бывает, что вы нам внедрите, а дальше мы как-нибудь сами.
И очень хорошо, если результатом этого «как-нибудь» сами будет то, что просто не будут использоваться 70-80% возможностей, но бывают случаи и похуже.
Эту показательную историю мне рассказал один хороший знакомый, руководитель IT в одном крупном госе за Уральским хребтом, подробностей по понятным причинам не будет.
В этом предприятии достаточно много филиалов, причем эти самые филиалы довольно самодостаточны, особенно в плане IT и головная контора для них скорее централизованный поставщик оборудования и запчастей и внутренний подрядчик.
Многие филиалы расположены в небольших городах с населением до 100 тыс. чел., оклады невысокие, как и квалификация кадров.
Все это как-то худо-бедно работало, кто во что горазд. По мере необходимости современные технологии, конечно, внедрялись, но без фанатизма. Да и какой тут фанатизм, если персонал учить надо, а на это нет ни денег, ни времени, ни этого самого персонала желания.
Поэтому поступали как проще, вот вам гипервизор (сначала Hyper-V, потом Proxmox), вот на нем виртуалки. А вот сюда делаются резервные копии. А вот вам Dude, тут все красиво и разными цветами мигает.
Вот так и жили. Потому как ни сил, ни средств, ни полномочий как-то переломить ситуацию на местах у головного IT-отдела не было.
Да и не было особой потребности. В случае чего филиал мог на полдня прилечь и погонять чаю, пока админы там все поднимут и наладят, никакого аврала от этого не случалось. А люди? А что люди, завтра придут, не графья, чай.
И вот пришла пора импортозамещения. Потянулись вереницей мальчики в дорогих костюмах и стали наперебой предлагать решения, одно другого краше (и дороже). Долго окучивали и наконец руководство сделало выбор.
Коллега, посмотрев в спецификации немного офигел и потом осторожно спросил шефа – а может, это, как-то попроще попробуем, поскромнее. Но был тут же спущен с небес на землю – начальству виднее, а твое дело – претворять решения начальства в жизнь.
А офигеть там было от чего, например, от системы виртуализации, требующей минимум три ноды и взрослых систем мониторинга, а-ля Zabbix.
Нет, решения в целом неплохие, но не для конторы, где админят два дядечки предпенсионного возраста с окладами в 25-35 тыс. руб.
В общем, началась у них в конторе совсем другая жизнь: ни сна, ни покоя. А потом как-то резко сошло на нет. Ну, притерлись, наверное.
И вот недавно приходится ехать ему в командировку в один такой филиал. И что он там увидел? Что ничего из ранее установленного нет и в помине. На новом железе тихо шуршит Proxmox и все худо-бедно работает.
Он, конечно, сильно изумился (мягко сказать), но местные живо пояснили ему, мол не ругайся, насяльника, мы диски старые сняли и вон в ту коробочку сложили. Если надо – сейчас все обратно поставим.
На что он просто устало махнул рукой, мол работайте как работается, все равно никто пока не проверяет. А на официальной поддержке, как это водится, сэкономили, или не сэкономили, но это уже совсем другая история.
А становиться бесплатной поддержкой и возможным крайним (а для госов крайне важно не остаться крайним) ему в лице центрального отдела меньше всего хотелось.
Потом он провел небольшое исследование и выяснил, что такая ситуация практически везде, особенно в небольших филиалах с низкими окладами.
Зато на бумаге все хорошо, внедрили, отчитались, эксплуатируют. Проблем нет.
Мы очень много говорим о автоматизации, внедрении современных технологий и т.д. и т.п., но совсем не задумываемся о тех, кто будет эти системы эксплуатировать.
Хорошо если внедренец и эксплуатант – одно и тоже лицо или связанные договорами на обслуживание и сопровождение. Но куда чаще бывает, что вы нам внедрите, а дальше мы как-нибудь сами.
И очень хорошо, если результатом этого «как-нибудь» сами будет то, что просто не будут использоваться 70-80% возможностей, но бывают случаи и похуже.
Эту показательную историю мне рассказал один хороший знакомый, руководитель IT в одном крупном госе за Уральским хребтом, подробностей по понятным причинам не будет.
В этом предприятии достаточно много филиалов, причем эти самые филиалы довольно самодостаточны, особенно в плане IT и головная контора для них скорее централизованный поставщик оборудования и запчастей и внутренний подрядчик.
Многие филиалы расположены в небольших городах с населением до 100 тыс. чел., оклады невысокие, как и квалификация кадров.
Все это как-то худо-бедно работало, кто во что горазд. По мере необходимости современные технологии, конечно, внедрялись, но без фанатизма. Да и какой тут фанатизм, если персонал учить надо, а на это нет ни денег, ни времени, ни этого самого персонала желания.
Поэтому поступали как проще, вот вам гипервизор (сначала Hyper-V, потом Proxmox), вот на нем виртуалки. А вот сюда делаются резервные копии. А вот вам Dude, тут все красиво и разными цветами мигает.
Вот так и жили. Потому как ни сил, ни средств, ни полномочий как-то переломить ситуацию на местах у головного IT-отдела не было.
Да и не было особой потребности. В случае чего филиал мог на полдня прилечь и погонять чаю, пока админы там все поднимут и наладят, никакого аврала от этого не случалось. А люди? А что люди, завтра придут, не графья, чай.
И вот пришла пора импортозамещения. Потянулись вереницей мальчики в дорогих костюмах и стали наперебой предлагать решения, одно другого краше (и дороже). Долго окучивали и наконец руководство сделало выбор.
Коллега, посмотрев в спецификации немного офигел и потом осторожно спросил шефа – а может, это, как-то попроще попробуем, поскромнее. Но был тут же спущен с небес на землю – начальству виднее, а твое дело – претворять решения начальства в жизнь.
А офигеть там было от чего, например, от системы виртуализации, требующей минимум три ноды и взрослых систем мониторинга, а-ля Zabbix.
Нет, решения в целом неплохие, но не для конторы, где админят два дядечки предпенсионного возраста с окладами в 25-35 тыс. руб.
В общем, началась у них в конторе совсем другая жизнь: ни сна, ни покоя. А потом как-то резко сошло на нет. Ну, притерлись, наверное.
И вот недавно приходится ехать ему в командировку в один такой филиал. И что он там увидел? Что ничего из ранее установленного нет и в помине. На новом железе тихо шуршит Proxmox и все худо-бедно работает.
Он, конечно, сильно изумился (мягко сказать), но местные живо пояснили ему, мол не ругайся, насяльника, мы диски старые сняли и вон в ту коробочку сложили. Если надо – сейчас все обратно поставим.
На что он просто устало махнул рукой, мол работайте как работается, все равно никто пока не проверяет. А на официальной поддержке, как это водится, сэкономили, или не сэкономили, но это уже совсем другая история.
А становиться бесплатной поддержкой и возможным крайним (а для госов крайне важно не остаться крайним) ему в лице центрального отдела меньше всего хотелось.
Потом он провел небольшое исследование и выяснил, что такая ситуация практически везде, особенно в небольших филиалах с низкими окладами.
Зато на бумаге все хорошо, внедрили, отчитались, эксплуатируют. Проблем нет.
👍44😁15💯7👀2❤1
Погрузитесь в мир Python с нашим бесплатным курсом!
🎓 Включено 45 уроков, 56 упражнений в тренажере и 163 проверочных теста. Узнаете, как создавать программы, работать с условиями и функциями.
Что вы освоите:
— Составление программ из нескольких модулей.
— Анализ ошибок в коде с использованием отладочной печати.
📚 Курс охватывает основы Python: синтаксис, условия, циклы, типы данных и библиотеки. Практика на каждом шаге поможет вам уверенно использовать язык.
Начните свое обучение с бесплатного базового курса Python и вы сможете создавать несложные программы, а так же анализировать ошибки в коде!
🎓 Включено 45 уроков, 56 упражнений в тренажере и 163 проверочных теста. Узнаете, как создавать программы, работать с условиями и функциями.
Что вы освоите:
— Составление программ из нескольких модулей.
— Анализ ошибок в коде с использованием отладочной печати.
📚 Курс охватывает основы Python: синтаксис, условия, циклы, типы данных и библиотеки. Практика на каждом шаге поможет вам уверенно использовать язык.
Начните свое обучение с бесплатного базового курса Python и вы сможете создавать несложные программы, а так же анализировать ошибки в коде!
Кеширующий прокси или зеркало репозитория?
Уже не первый раз сталкиваемся с тем, что начинающие администраторы путают эти два понятия. Поэтому попробуем внести ясность.
По мере роста количества машин под управлением Linux возникает проблема доступа к репозиториям. Например, при обновлении весь парк машин будет многократно выкачивать один и тот же объем трафика.
Дополнительными негативными факторами могут быть скорость канала или скорость доступа к репозиториям. Все это заставляет задуматься о том, как решить проблему.
Первое что приходит на ум – это локальное зеркало репозитория. Создать его несложно, для этого есть штатная утилита apt-mirror. С ее помощью можно поддерживать на собственных ресурсах полную копию репозиториев системы.
Но тут возникают иные сложности, так, например, размер репозиториев текущей версии Debian для архитектуры amd64 составляет 778 ГБ, сюда как минимум следует добавить all и еще 258 ГБ. Получаем примерно 1 ТБ требуемого дискового пространства.
Если у нас в эксплуатации несколько систем, то зеркала репозиториев нужно будет организовать для каждой из них. При переходе на новую версию – добавить новые репозитории.
В итоге получаем весьма значительное расходование места, причем достаточно бесполезное, поскольку по факту вы будете использовать лишь малую его часть.
Уменьшить размер локальных репозиториев в целом можно, например, скачав только самые нужные или оставив только последние версии пакетов, но все это не устраняет общей проблемы – значительный перерасход места.
Альтернатива локальному репозиторию – кеширующий прокси-сервер. Он работает по схожему, но несколько иному принципу.
Как и любой прокси-сервер он становится посредником между системой и репозиторием и один раз скачав любой пакет помещает его в локальный кеш. При последующих запросах пакет будет уже отдаваться из кеша, без повторного скачивания.
Локальная структура также организуется по принципу репозиториев, с учетом версии системы, архитектуры, источника пакетов и т.д.
Поэтому один кеширующий прокси может без проблем обслуживать любое количество систем и их версий. Никаких настроек при этом делать не надо. Новая система первый раз скачает необходимые файлы из интернета, а остальные получат их уже из локального хранилища.
Потребовался новый пакет или обновление? Аналогично, один раз качаем, остальное получаем локально.
При этом размер кеша будет равен размеру реально используемых пакетов и их версий. И разница с локальным репозиторием получается где-то на порядок.
Поэтому для большинства сценариев оптимальным будет использование именно кеширующего прокси.
Локальные репозитории в свою очередь следует использовать для закрытого контура или крупных систем с узким внешним каналом.
Настроить кеширующий прокси Apt-Cacher NG можно по нашей статье: Установка и настройка Apt-Cacher NG - кеширующего прокси-сервера обновлений для Debian и Ubuntu
Уже не первый раз сталкиваемся с тем, что начинающие администраторы путают эти два понятия. Поэтому попробуем внести ясность.
По мере роста количества машин под управлением Linux возникает проблема доступа к репозиториям. Например, при обновлении весь парк машин будет многократно выкачивать один и тот же объем трафика.
Дополнительными негативными факторами могут быть скорость канала или скорость доступа к репозиториям. Все это заставляет задуматься о том, как решить проблему.
Первое что приходит на ум – это локальное зеркало репозитория. Создать его несложно, для этого есть штатная утилита apt-mirror. С ее помощью можно поддерживать на собственных ресурсах полную копию репозиториев системы.
Но тут возникают иные сложности, так, например, размер репозиториев текущей версии Debian для архитектуры amd64 составляет 778 ГБ, сюда как минимум следует добавить all и еще 258 ГБ. Получаем примерно 1 ТБ требуемого дискового пространства.
Если у нас в эксплуатации несколько систем, то зеркала репозиториев нужно будет организовать для каждой из них. При переходе на новую версию – добавить новые репозитории.
В итоге получаем весьма значительное расходование места, причем достаточно бесполезное, поскольку по факту вы будете использовать лишь малую его часть.
Уменьшить размер локальных репозиториев в целом можно, например, скачав только самые нужные или оставив только последние версии пакетов, но все это не устраняет общей проблемы – значительный перерасход места.
Альтернатива локальному репозиторию – кеширующий прокси-сервер. Он работает по схожему, но несколько иному принципу.
Как и любой прокси-сервер он становится посредником между системой и репозиторием и один раз скачав любой пакет помещает его в локальный кеш. При последующих запросах пакет будет уже отдаваться из кеша, без повторного скачивания.
Локальная структура также организуется по принципу репозиториев, с учетом версии системы, архитектуры, источника пакетов и т.д.
Поэтому один кеширующий прокси может без проблем обслуживать любое количество систем и их версий. Никаких настроек при этом делать не надо. Новая система первый раз скачает необходимые файлы из интернета, а остальные получат их уже из локального хранилища.
Потребовался новый пакет или обновление? Аналогично, один раз качаем, остальное получаем локально.
При этом размер кеша будет равен размеру реально используемых пакетов и их версий. И разница с локальным репозиторием получается где-то на порядок.
Поэтому для большинства сценариев оптимальным будет использование именно кеширующего прокси.
Локальные репозитории в свою очередь следует использовать для закрытого контура или крупных систем с узким внешним каналом.
Настроить кеширующий прокси Apt-Cacher NG можно по нашей статье: Установка и настройка Apt-Cacher NG - кеширующего прокси-сервера обновлений для Debian и Ubuntu
👍55❤2👀1
Принципы работы Apt-Cacher NG
В обсуждениях к предыдущей заметки выяснилось, что не все коллеги понимают принцип действия данного продукта, поэтому мы посчитали нужным остановиться на нем подробнее.
Apt-Cacher NG по своей сути – это обычный кеширущий прокси сервер, только с некоторыми особенностями кеширования. Работа с прокси не является чем-то необычным для Linux и поэтому никаких дополнительных сущностей там не возникает.
После того, как в настройках APT или репозитория мы тем или иным способом указали прокси-сервер, то все общение с внешним миром у нас будет через него и только через него. Если Apt-Cacher NG окажется недоступным, то никакого доступа к репозиториям у нас не будет.
В этом плане является предпочтительным подключение его через Zeroconf, в этом случае если прокси доступен – то трафик идет через него, если же нет, то напрямую.
В самом начале кеш прокси у нас пуст. А клиент, скажем Debian 12, хочет скачать пакет top. Он формирует стандартный HTTP-запрос к файлу пакета в стандартном репозитории и передает его прокси-серверу.
Прокси смотрит конечный URL и проверяет свой кеш, если данного пакета там нет, то запрос уходит в удаленный репозиторий и клиент производит скачивание напрямую из него, при этом трафик проходит через прокси-сервер.
Это важный момент, и мы специально заостряем на него внимание, никакого двойного скачивания не происходит, т.е. Apt-Cacher NG не качает пакет сначала в кеш, а потом из кеша отдает его клиенту. Клиент качает пакет через прокси напрямую, но при этом прокси кеширует пакет и размещает в специальной структуре однозначно связанной с URL.
Когда у нас этот же самый пакет захочет скачать второй клиент, то он также сформирует HTTP запрос к стандартному репозиторию и передаст его прокси-серверу. Прокси-сервер снова проверит кеш и найдет закешированный для этого URL пакет, после чего отдаст его из локального кеша, без повторного скачивания из сети.
А теперь у нас в сети появляется другая система и хочет скачать тот же самый пакет. Возможно даже с тем же самым именем. Но прокси не так просто провести. Для другой системы иди другой архитектуры или даже другого репозитория или PPA у нас будет совсем другой URL, для которого не будет закешированного пакета.
Поэтому сначала снова будет прямое скачивание из удаленного репозитория, а потом пакет будет отдаваться из кеша. При этом Apt-Cacher NG абсолютно не нужно знать какие у вас в эксплуатации системы и из каких репозиториев вы качаете.
Оно просто выделяет все проходящие через него пакеты, не обязательно DEB, Apt-Cacher NG также умеет работать и с RPM и сохраняет их в кеш с привязкой к URL. При повторном запросе он смотрит в собственную базу и если находит кешированный пакет, то отдает его из локального хранилища.
Таким образом важно понимать, что если вам нужно обновить несколько однотипных систем, то не нужно запускать обновления сразу. Обновите одну систему, чтобы все нужные пакеты попали в кеш и только потом запускайте обновления на остальных.
В обсуждениях к предыдущей заметки выяснилось, что не все коллеги понимают принцип действия данного продукта, поэтому мы посчитали нужным остановиться на нем подробнее.
Apt-Cacher NG по своей сути – это обычный кеширущий прокси сервер, только с некоторыми особенностями кеширования. Работа с прокси не является чем-то необычным для Linux и поэтому никаких дополнительных сущностей там не возникает.
После того, как в настройках APT или репозитория мы тем или иным способом указали прокси-сервер, то все общение с внешним миром у нас будет через него и только через него. Если Apt-Cacher NG окажется недоступным, то никакого доступа к репозиториям у нас не будет.
В этом плане является предпочтительным подключение его через Zeroconf, в этом случае если прокси доступен – то трафик идет через него, если же нет, то напрямую.
В самом начале кеш прокси у нас пуст. А клиент, скажем Debian 12, хочет скачать пакет top. Он формирует стандартный HTTP-запрос к файлу пакета в стандартном репозитории и передает его прокси-серверу.
Прокси смотрит конечный URL и проверяет свой кеш, если данного пакета там нет, то запрос уходит в удаленный репозиторий и клиент производит скачивание напрямую из него, при этом трафик проходит через прокси-сервер.
Это важный момент, и мы специально заостряем на него внимание, никакого двойного скачивания не происходит, т.е. Apt-Cacher NG не качает пакет сначала в кеш, а потом из кеша отдает его клиенту. Клиент качает пакет через прокси напрямую, но при этом прокси кеширует пакет и размещает в специальной структуре однозначно связанной с URL.
Когда у нас этот же самый пакет захочет скачать второй клиент, то он также сформирует HTTP запрос к стандартному репозиторию и передаст его прокси-серверу. Прокси-сервер снова проверит кеш и найдет закешированный для этого URL пакет, после чего отдаст его из локального кеша, без повторного скачивания из сети.
А теперь у нас в сети появляется другая система и хочет скачать тот же самый пакет. Возможно даже с тем же самым именем. Но прокси не так просто провести. Для другой системы иди другой архитектуры или даже другого репозитория или PPA у нас будет совсем другой URL, для которого не будет закешированного пакета.
Поэтому сначала снова будет прямое скачивание из удаленного репозитория, а потом пакет будет отдаваться из кеша. При этом Apt-Cacher NG абсолютно не нужно знать какие у вас в эксплуатации системы и из каких репозиториев вы качаете.
Оно просто выделяет все проходящие через него пакеты, не обязательно DEB, Apt-Cacher NG также умеет работать и с RPM и сохраняет их в кеш с привязкой к URL. При повторном запросе он смотрит в собственную базу и если находит кешированный пакет, то отдает его из локального хранилища.
Таким образом важно понимать, что если вам нужно обновить несколько однотипных систем, то не нужно запускать обновления сразу. Обновите одну систему, чтобы все нужные пакеты попали в кеш и только потом запускайте обновления на остальных.
👍44🔥2👀2
+1 полезный калан, где вы найдете самые актуальные новости связанные с автоматизацией складской и транспортной логистики.
Вот самые классные темы:
- Что будет с программными решениями по модели as a service и почему облачные сервисы потеряли доверие бизнеса.
- Почему food-market отстает по уровню цифровой зрелости от других отраслей.
- Зачем для эффективной работы с системой маркировки «Честный знак» нужна WMS.
- Подкаст «Логистика на ночь», очень понравился недавний выпуск о последней мили.
Всё о цифровых технологиях и не только - коротко, ёмко и по делу на канале @GTLogistics_tech, подписывайтесь!
Реклама. ООО "ДЖИТИ ЛОДЖИСТИКС". ИНН 6670420812. erid: LjN8K7T4s
Вот самые классные темы:
- Что будет с программными решениями по модели as a service и почему облачные сервисы потеряли доверие бизнеса.
- Почему food-market отстает по уровню цифровой зрелости от других отраслей.
- Зачем для эффективной работы с системой маркировки «Честный знак» нужна WMS.
- Подкаст «Логистика на ночь», очень понравился недавний выпуск о последней мили.
Всё о цифровых технологиях и не только - коротко, ёмко и по делу на канале @GTLogistics_tech, подписывайтесь!
Реклама. ООО "ДЖИТИ ЛОДЖИСТИКС". ИНН 6670420812. erid: LjN8K7T4s
🤮3👀2
Легкий мониторинг
Коллеги часто спрашивают что-нибудь простое для мониторинга небольшой инфраструктуры.
Действительно, не везде нужны такие монстры как Zabbix, поэтому расскажем о нескольких простых инструментах.
Начнем с nmon, он не является мониторингом в прямом смысле этого слова, а ближе к таким утилитам как htop, iotop, ifstat и т.д. Это удобная утилита начальной диагностики и мониторинга показателей в режиме реального времени.
Главное преимущество этой утилиты – ее необычайная гибкость, мы можем в режиме реального времени собирать на экране нужные наборы модулей чтобы отслеживать взаимовлияющие показатели и параметры.
Т.е. вместо нескольких утилит использовать одну. Это удобно и быстро позволяет выявить проблемные места и аномалии.
🔹 Простой и удобный инструмент мониторинга производительности – nmon
Для небольших инсталляций и отдельных узлов можно посоветовать Monitorix – очень легкую систему мониторинга, который может использоваться даже на слабых VPS и встраиваемых компьютерах.
Но в тоже время он умеет практически все, что должен уметь мониторинг: собирать и отображать данные, отслеживать триггеры и посылать уведомления.
Для контроля нескольких узлов придется установить Monitorix на каждый из них, однако есть возможность просматривать данные в единственном месте.
🔹 Monitorix - простой и легкий мониторинг для Linux
Для более сложных систем есть простое централизованное решение – Munin. Он также нетребователен к ресурсам, но работает по клиент-серверной схеме.
За сбор информации отвечают клиенты с необходимым набором плагинов, а вся информация собирается и хранится на сервере. Благодаря наличию плагинов вы можете реализовать практически любую функциональность в тоже время не перегружая систему.
🔹 Устанавливаем и настраиваем систему мониторинга Munin
Что выбрать? Смотрите сами, но имейте ввиду, что мониторинг – это не только большие монстры, но и гораздо более простые и легкие решения, которые можно развернуть прямо сейчас.
Коллеги часто спрашивают что-нибудь простое для мониторинга небольшой инфраструктуры.
Действительно, не везде нужны такие монстры как Zabbix, поэтому расскажем о нескольких простых инструментах.
Начнем с nmon, он не является мониторингом в прямом смысле этого слова, а ближе к таким утилитам как htop, iotop, ifstat и т.д. Это удобная утилита начальной диагностики и мониторинга показателей в режиме реального времени.
Главное преимущество этой утилиты – ее необычайная гибкость, мы можем в режиме реального времени собирать на экране нужные наборы модулей чтобы отслеживать взаимовлияющие показатели и параметры.
Т.е. вместо нескольких утилит использовать одну. Это удобно и быстро позволяет выявить проблемные места и аномалии.
🔹 Простой и удобный инструмент мониторинга производительности – nmon
Для небольших инсталляций и отдельных узлов можно посоветовать Monitorix – очень легкую систему мониторинга, который может использоваться даже на слабых VPS и встраиваемых компьютерах.
Но в тоже время он умеет практически все, что должен уметь мониторинг: собирать и отображать данные, отслеживать триггеры и посылать уведомления.
Для контроля нескольких узлов придется установить Monitorix на каждый из них, однако есть возможность просматривать данные в единственном месте.
🔹 Monitorix - простой и легкий мониторинг для Linux
Для более сложных систем есть простое централизованное решение – Munin. Он также нетребователен к ресурсам, но работает по клиент-серверной схеме.
За сбор информации отвечают клиенты с необходимым набором плагинов, а вся информация собирается и хранится на сервере. Благодаря наличию плагинов вы можете реализовать практически любую функциональность в тоже время не перегружая систему.
🔹 Устанавливаем и настраиваем систему мониторинга Munin
Что выбрать? Смотрите сами, но имейте ввиду, что мониторинг – это не только большие монстры, но и гораздо более простые и легкие решения, которые можно развернуть прямо сейчас.
👍25👀2
А что именно мы мониторим?
Очень часто внедрения системы мониторинга заканчивается тем, что она начинает тихо пылиться где-то на забытой всеми виртуалке, пока не будет отключена совсем.
На вопрос почему такие пользователи обычно отвечают, что все равно от нее нет особого толка.
И это действительно так, если вы не уделили системе мониторинга особого внимания и не настроили какие именно параметры вы хотите контролировать, а также не задали подходящие именно вам пороговые значения – толку от нее действительно не будет.
Любая система мониторинга имеет некоторые настроенные из коробки метрики и триггеры, где-то больше, где-то меньше, но все они рассчитаны на некий сферический сервер в вакууме и использовать без адаптации можно разве что триггеры, срабатывающие на предельных значениях.
Но сообщение о выходе параметров за эти значения равносильны звонку в экстренные службы, если раньше вам об этом не сообщат пользователи или руководство в три часа ночи.
А вот остальные значения нуждаются в серьезном тюнинге. Например, у Zabbix из коробки есть два триггера на дисковое пространство: низкое – 80% и критически низкое – 90%.
Если взять диск объемом в 4 ТБ, то эти значения получатся на уровне 3,2 и 3,6 ТБ, в первом случае у нас еще остается почти целый терабайт и можно спокойно работать несмотря на предупреждение. А при «критическом» срабатывании останется 400 ГБ, что при большинстве сценариев будет еще вполне достаточно на долгое время.
А теперь возьмем SSD 120 ГБ, 80% — это 96 ГБ, а 90 – уже 108 ГБ. Т.е. всего 12 ГБ между уровнями срабатывания и столько же еще в резерве. При интенсивной записи мы можем исчерпать такой размер за считанные минуты.
Поэтому что в том, что в другом случае параметры срабатывания триггеров надо откорректировать согласно фактическому положению дел. Иначе такие предупреждения скоро замылят глаз и перестанут восприниматься как серьезные, что может сыграть злую шутку при реальном недостатке места в системе.
Но сам по себе сервер не представляет такой ценности, как запущенные на нем приложения и часто можно столкнуться с ситуацией, когда сервер сам по себе не выходит за рамки контрольных показателей, а приложение работает из рук вон плохо.
Можно, конечно, найти стандартный шаблон для приложения и радоваться, только вот чему?
Стандартный шаблон он тоже для сферического приложения в вакууме и без адаптации будет практически негоден.
Скажем, если у вас веб-сервер на дешевом-дешевом VPS, то вы можете никогда не дождаться срабатывания триггера на большое число запросов, так как сервер ляжет гораздо раньше.
Многие показатели могут иметь разлет значений на порядок, а то и несколько, скажем критическую нагрузку по IO для HDD средний SSD спокойно переварит, а для NVMе это будут вообще какие-то незначительные цифры.
И это касается очень и очень многого. При том, что никаких общих рекомендаций, мол поставь сюда такую цифру, а сюда такую дать нельзя, все достаточно индивидуально. Поэтому для корректной работы любого шаблона вам придется изучить что отражают все собираемые им метрики и как рассчитать их нормальные и предельные значения для каждого конкретного случая.
Сложно? Ну как сказать, если вы понимаете принцип работы приложения – то не очень, а иначе – придется углубиться в теорию. Но без этого никак, даже не касаясь систем мониторинга без данных знаний вы не сможете нормально эксплуатировать систему.
Или на вопросы пользователей: «Почему тормозит продукт NAME?», будете отвечать: «Ну это же продукт NAME». Но, согласитесь, такой подход не красит специалиста.
При этом нам известны и иные случаи, когда внедрив мониторинг и углубившись в изучение метрик и их влияния на общий результат коллеги серьезно подтягивали производительность которая начинала быть видимой буквально невооруженным глазом.
Поэтому, собираясь внедрять систему мониторинга приготовьтесь углубиться в подробности эксплуатации используемых программных продуктов и показателей, влияющих на их производительность.
Очень часто внедрения системы мониторинга заканчивается тем, что она начинает тихо пылиться где-то на забытой всеми виртуалке, пока не будет отключена совсем.
На вопрос почему такие пользователи обычно отвечают, что все равно от нее нет особого толка.
И это действительно так, если вы не уделили системе мониторинга особого внимания и не настроили какие именно параметры вы хотите контролировать, а также не задали подходящие именно вам пороговые значения – толку от нее действительно не будет.
Любая система мониторинга имеет некоторые настроенные из коробки метрики и триггеры, где-то больше, где-то меньше, но все они рассчитаны на некий сферический сервер в вакууме и использовать без адаптации можно разве что триггеры, срабатывающие на предельных значениях.
Но сообщение о выходе параметров за эти значения равносильны звонку в экстренные службы, если раньше вам об этом не сообщат пользователи или руководство в три часа ночи.
А вот остальные значения нуждаются в серьезном тюнинге. Например, у Zabbix из коробки есть два триггера на дисковое пространство: низкое – 80% и критически низкое – 90%.
Если взять диск объемом в 4 ТБ, то эти значения получатся на уровне 3,2 и 3,6 ТБ, в первом случае у нас еще остается почти целый терабайт и можно спокойно работать несмотря на предупреждение. А при «критическом» срабатывании останется 400 ГБ, что при большинстве сценариев будет еще вполне достаточно на долгое время.
А теперь возьмем SSD 120 ГБ, 80% — это 96 ГБ, а 90 – уже 108 ГБ. Т.е. всего 12 ГБ между уровнями срабатывания и столько же еще в резерве. При интенсивной записи мы можем исчерпать такой размер за считанные минуты.
Поэтому что в том, что в другом случае параметры срабатывания триггеров надо откорректировать согласно фактическому положению дел. Иначе такие предупреждения скоро замылят глаз и перестанут восприниматься как серьезные, что может сыграть злую шутку при реальном недостатке места в системе.
Но сам по себе сервер не представляет такой ценности, как запущенные на нем приложения и часто можно столкнуться с ситуацией, когда сервер сам по себе не выходит за рамки контрольных показателей, а приложение работает из рук вон плохо.
Можно, конечно, найти стандартный шаблон для приложения и радоваться, только вот чему?
Стандартный шаблон он тоже для сферического приложения в вакууме и без адаптации будет практически негоден.
Скажем, если у вас веб-сервер на дешевом-дешевом VPS, то вы можете никогда не дождаться срабатывания триггера на большое число запросов, так как сервер ляжет гораздо раньше.
Многие показатели могут иметь разлет значений на порядок, а то и несколько, скажем критическую нагрузку по IO для HDD средний SSD спокойно переварит, а для NVMе это будут вообще какие-то незначительные цифры.
И это касается очень и очень многого. При том, что никаких общих рекомендаций, мол поставь сюда такую цифру, а сюда такую дать нельзя, все достаточно индивидуально. Поэтому для корректной работы любого шаблона вам придется изучить что отражают все собираемые им метрики и как рассчитать их нормальные и предельные значения для каждого конкретного случая.
Сложно? Ну как сказать, если вы понимаете принцип работы приложения – то не очень, а иначе – придется углубиться в теорию. Но без этого никак, даже не касаясь систем мониторинга без данных знаний вы не сможете нормально эксплуатировать систему.
Или на вопросы пользователей: «Почему тормозит продукт NAME?», будете отвечать: «Ну это же продукт NAME». Но, согласитесь, такой подход не красит специалиста.
При этом нам известны и иные случаи, когда внедрив мониторинг и углубившись в изучение метрик и их влияния на общий результат коллеги серьезно подтягивали производительность которая начинала быть видимой буквально невооруженным глазом.
Поэтому, собираясь внедрять систему мониторинга приготовьтесь углубиться в подробности эксплуатации используемых программных продуктов и показателей, влияющих на их производительность.
👍31❤1🌭1
👍9
Онлайн-марафон по программированию от экспертов Хекслета, VK, Альфа-Банка, OneTwoTrip, Dualboot Partners.
IT-Start: с 0 до выбора профессии за 3 дня.
⏰ Когда: 20-22 марта в 19:00 мск.
✔️Расскажем о преимуществах и подводных камнях профессии “разработчик”.
✔️Рассмотрим востребованне направления в программировании: Python и Java, PHP и Frontend, поговорим с Кириллом Мокевниным (co-founder Хекслет).
✔️Обсудим, какие факты о программировании правда, а какие выдумка. Покажем реальную картину в сфере ИТ сегодня.
Участники смогут задать все интересующие вопросы программистам с многолетним стажем.
IT-Start: с 0 до выбора профессии за 3 дня.
⏰ Когда: 20-22 марта в 19:00 мск.
✔️Расскажем о преимуществах и подводных камнях профессии “разработчик”.
✔️Рассмотрим востребованне направления в программировании: Python и Java, PHP и Frontend, поговорим с Кириллом Мокевниным (co-founder Хекслет).
✔️Обсудим, какие факты о программировании правда, а какие выдумка. Покажем реальную картину в сфере ИТ сегодня.
Участники смогут задать все интересующие вопросы программистам с многолетним стажем.
👌1
The Dude
Во вчерашней заметке о простых системах мониторинга мы не упомянули Dude и сделали это вполне сознательно.
Это отдельный продукт от компании Mikrotik, рассчитанный в первую очередь на работу с оборудованием этого производителя. И если ваша сеть построена на основе продуктов Mikrotik, то Dude придется вам ко двору.
Продукт имеет свою специфику – прежде всего это мониторинг именно сети, кроме того, он умеет собирать данные хостов по SNMP и при желании вы сможете настроить любые метрики, которые можно получить данным способом.
Поэтому Dude не заменяет другие системы мониторинга, но оказывается очень полезным, когда надо беглым взглядом окинуть инфраструктуру и посмотреть все ли везде в порядке. А если нужны подробности, то можно будет обратиться уже к более серьезным системам мониторинга.
Как установить и настроить Dude рассказано в нашей статье:
🔹 The Dude. Установка и быстрое начало работы
Также с его помощью можно организовать централизованный сбор логов, пусть простой, даже скажем – примитивный. Но во многих случаях это будет лучше чем ничего:
🔹 Централизованный сбор логов Mikrotik на сервер The Dude
А пользователи Mikrotik могут воспользоваться специальными функциями для этого оборудования, самой полезной из которых будет централизованное обновление:
🔹 Централизованное управление обновлением RouterOS при помощи The Dude
Во вчерашней заметке о простых системах мониторинга мы не упомянули Dude и сделали это вполне сознательно.
Это отдельный продукт от компании Mikrotik, рассчитанный в первую очередь на работу с оборудованием этого производителя. И если ваша сеть построена на основе продуктов Mikrotik, то Dude придется вам ко двору.
Продукт имеет свою специфику – прежде всего это мониторинг именно сети, кроме того, он умеет собирать данные хостов по SNMP и при желании вы сможете настроить любые метрики, которые можно получить данным способом.
Поэтому Dude не заменяет другие системы мониторинга, но оказывается очень полезным, когда надо беглым взглядом окинуть инфраструктуру и посмотреть все ли везде в порядке. А если нужны подробности, то можно будет обратиться уже к более серьезным системам мониторинга.
Как установить и настроить Dude рассказано в нашей статье:
🔹 The Dude. Установка и быстрое начало работы
Также с его помощью можно организовать централизованный сбор логов, пусть простой, даже скажем – примитивный. Но во многих случаях это будет лучше чем ничего:
🔹 Централизованный сбор логов Mikrotik на сервер The Dude
А пользователи Mikrotik могут воспользоваться специальными функциями для этого оборудования, самой полезной из которых будет централизованное обновление:
🔹 Централизованное управление обновлением RouterOS при помощи The Dude
👍26❤1👌1
Развертывание The Dude
Основным вопросом, после того как вы решили внедрить у себя Dude будет как и куда его установить.
Здесь есть разные варианты, The Dude поддерживает следующие архитектуры:
🔹 TILE devices
🔹 ARM devices
🔹 MMIPS devices
🔹 RouterOS x86
🔹 RouterOS CHR
Обратите внимание, что вам подойдут только те устройства, в которых можно расширить память одним из следующих образов: M.2/MiniPCI-e/Memory card/USB
Таким образом из MMIPS вам подойдут только hEX и hEX S, среди ARM устройств список больше, начиная с RB3011UIAS-RM и hAP ac2, главное – возможность расширить память.
Официальные рекомендации вендора следующие:
🔶 Небольшие инсталляции: < 200 устройств
🔸 hEX (RB750Gr3) с microSD card 16/32GB
🔸 Виртуальная машина 1 vCPU, 512MB RAM, 10GB VHD
🔶 Средние инсталляции: 200 - 500 устройств
🔸 RB1100AHx4 Dude Edition с установленным 60GB SSD
🔸 Виртуальная машина 2 vCPU, 2GB RAM, 20GB VHD
🔶 Крупные инсталляции: > 500 devices
🔸 RB1100AHx4 Dude Edition с установленным 60GB SSD
🔸 TILE based device со слотом M.2 для SSD
🔸 Виртуальная машина 4 vCPU, 4GB RAM, 40GB VHD
Но в целом мы не рекомендуем устанавливать The Dude на устройства, сделав выбор в пользу виртуальной машины. Такой вариант обладает большей гибкостью и переносимостью, а также позволяет легко масштабироваться.
В виртуальной среде можно запустить как RouterOS x86, так и RouterOS CHR, разницы между ними нет – это одна и та же система, все различия в лицензировании.
Для новых установок мы однозначно рекомендуем RouterOS CHR, что это такое и с чем его едят мы рассказывали в нашей статье:
🔹 Mikrotik CHR - виртуальный облачный роутер
Несмотря на прошедшие со времени написания статьи изменения лицензии на CHR все еще доступны для покупки и их цена остается все еще приемлемой.
Установить RouterOS CHR на виртуальную машину в целом несложно. Все что вам потребуется – это создать виртуалку с нужными параметрами и подключить к ней скачанный образ диска CHR, возможно перед этим его придется конвертировать в нужный формат.
Чтобы облегчить этот процесс мы написали скрипт для популярной системы виртуализации Proxmox:
🔹 Установка Mikrotik CHR на виртуальную машину Proxmox
Затем на установленную виртуальную машину вам потребуется установить пакет The Dude, который доступен в наборе Extra packages.
Основным вопросом, после того как вы решили внедрить у себя Dude будет как и куда его установить.
Здесь есть разные варианты, The Dude поддерживает следующие архитектуры:
🔹 TILE devices
🔹 ARM devices
🔹 MMIPS devices
🔹 RouterOS x86
🔹 RouterOS CHR
Обратите внимание, что вам подойдут только те устройства, в которых можно расширить память одним из следующих образов: M.2/MiniPCI-e/Memory card/USB
Таким образом из MMIPS вам подойдут только hEX и hEX S, среди ARM устройств список больше, начиная с RB3011UIAS-RM и hAP ac2, главное – возможность расширить память.
Официальные рекомендации вендора следующие:
🔶 Небольшие инсталляции: < 200 устройств
🔸 hEX (RB750Gr3) с microSD card 16/32GB
🔸 Виртуальная машина 1 vCPU, 512MB RAM, 10GB VHD
🔶 Средние инсталляции: 200 - 500 устройств
🔸 RB1100AHx4 Dude Edition с установленным 60GB SSD
🔸 Виртуальная машина 2 vCPU, 2GB RAM, 20GB VHD
🔶 Крупные инсталляции: > 500 devices
🔸 RB1100AHx4 Dude Edition с установленным 60GB SSD
🔸 TILE based device со слотом M.2 для SSD
🔸 Виртуальная машина 4 vCPU, 4GB RAM, 40GB VHD
Но в целом мы не рекомендуем устанавливать The Dude на устройства, сделав выбор в пользу виртуальной машины. Такой вариант обладает большей гибкостью и переносимостью, а также позволяет легко масштабироваться.
В виртуальной среде можно запустить как RouterOS x86, так и RouterOS CHR, разницы между ними нет – это одна и та же система, все различия в лицензировании.
Для новых установок мы однозначно рекомендуем RouterOS CHR, что это такое и с чем его едят мы рассказывали в нашей статье:
🔹 Mikrotik CHR - виртуальный облачный роутер
Несмотря на прошедшие со времени написания статьи изменения лицензии на CHR все еще доступны для покупки и их цена остается все еще приемлемой.
Установить RouterOS CHR на виртуальную машину в целом несложно. Все что вам потребуется – это создать виртуалку с нужными параметрами и подключить к ней скачанный образ диска CHR, возможно перед этим его придется конвертировать в нужный формат.
Чтобы облегчить этот процесс мы написали скрипт для популярной системы виртуализации Proxmox:
🔹 Установка Mikrotik CHR на виртуальную машину Proxmox
Затем на установленную виртуальную машину вам потребуется установить пакет The Dude, который доступен в наборе Extra packages.
👍24