​​Критерии выбора оборудования для сервера 1С:Предприятие. Процессор. Часть 2

Во вчерашней заметке мы разобрали общие вопросы производительности сервера 1С в разрезе процессора, сегодня продолжим углубляться в специфику.

Рабочие процессы (rphost) – основная рабочая лошадка, которая выполняет серверный код и обслуживает пользовательские соединения. В целом рабочий процесс умеет эффективно использовать ядра процессора, но есть некоторые тонкости.

Официальная документация гласит:

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

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

Проще говоря – количество рабочих процессов рекомендовано выставлять по количеству ядер.

Но тут беда пришла откуда не ждали, после разделения платформы на ПРОФ и КОРП. Теперь у пользователей ПРОФ нет возможности настраивать рабочие процессы, единственное доступное значение 8 ИБ на процесс и 256 соединений. Также платформа ПРОФ не может использовать более 12 процессорных ядер.

Это говорит о том, что в большинстве случаев вы будете работать в рамках единого рабочего процесса и иметь все прелести неравномерной загрузки, в этом случае также крайне важно иметь CPU с максимально высокой частотой процессора.

Отсюда проистекает также и схема масштабирования. Если ваши масштабы не предполагают переход на КОРП, а на одном сервере всем становится тесно, то лучший вариант – это увеличение количества серверов 1С.

Где-то ряд нагрузки можно вынести на Сервер-МИНИ, а где-то имеет смысл приобрести еще одну лицензию. При этом аппаратно можно продолжать использовать уже имеющееся оборудование.

Скажем тот же AMD Ryzen 9 5900X имеет 12 ядер / 24 потока, что позволит полноценно развернуть на нем две виртуальных машины или контейнера с серверами 1С по 12 ядер в каждом.

Следующий тонкий момент – веб-сервера, которые сейчас очень популярны как средство доступа к 1С.

Здесь мы начнем с вопроса: где исполняется код 1С? А исполняется он в двух местах: на клиенте и на сервере. На клиенте обрабатываются данные форм приложения и данные введенные в них пользователем.

Данные ИБ можно получить только на сервере и обычно там же происходит их обработка. Количество кода, исполняемого клиентом и сервером, различается от характера нагрузки.

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

Если же доступ ведется через веб-клиент (браузер), то код, исполняемый на клиентской стороне, выполняет модуль расширения веб-сервера и вся нагрузка ложится на веб-сервер. Этот момент также нужно учитывать при планировании нагрузки.

Следующий момент – это сеансы и соединения. Сеанс определяет активного пользователя информационной базы и поток управления этого пользователя. Среди доступных видов сеансов есть тонкий клиент и веб-клиент.

Соединение является средством доступа сеансов серверу 1С:Предприятия» и не отождествляется с активным пользователем. Среди видов соединений есть также тонкий клиент и модуль расширения веб-сервера.

О чем это говорит? О том что в режиме работы через веб-сервер количество сеансов не равно количеству соединений. И чаще всего множество входящих сеансов к веб-серверу обслуживаются единственным соединением к серверу 1С:Предприятия.

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

​​И снова про самосбор серверов

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

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

Увы, это не так, а раз в год даже палка стреляет. В чем мы недавно в очередной раз убедились.

На февраль с одним из заказчиков у нас планировался некий проект, но все неожиданно стало на паузу по причине отсутствия свободных вычислительных мощностей.

Но начнем по порядку. Еще осенью администратор этого заказчика купил новый сервер, купил под самосбор на популярной платформе Supermicro. Докупил процессор, память, диски, поднял Proxmox и стал потихоньку переносить нагрузку.

Некоторое время все было хорошо, но, когда используемый объем памяти начал превышать 2/3 установленного – сервер начал падать в kernel panic и все данные показывали на память.

Так и есть, планка в 4-м слоту не проходит тестирование, отнесли в гарантию – тестирование прошла, все ОК. Перекинул планку в другой сервер – проходит. Вернул на место – тоже проходит.

Ну что тут можно сказать? Списали все на плохие контакты. Недели две все работало, потом снова сервер стал падать. Теперь перестала проходить тестирование планка в третьем слоте.

Протестировал в другом сервере – все проходит. Решил поменять память с другим сервером. «Косячная» память там завелась и стала работать без проблем, а та, что нормально работала в другом – снова стала чудить подобным образом.

Опытным путем было установлено, что чудеса начинаются только когда заняты все 4 слота, любые три работали нормально.

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

Сначала поехал по гарантии к своему дистрибьютору процессор, там не стали заморачиваться и сразу его поменяли.

Вроде бы успех, все работает. Сервер вернулся, но ровно на неделю. Потом снова поехал в гарантию, теперь уже к дистрибьюторам Supermicro. Откуда вернулся с заключением, что с платформой все ОК, но так как память использована не из листа совместимости, то никакой ответственности за такое поведение они не несут.

В общем купили память из листа совместимости, хотя сделать это было не просто, потому как 80% перечисленного там в продаже отсутствует полностью.

И снова получили нестабильную работу. Платформа снова уехала к дистрибьюторам Supermicro и заменили ее только почти спустя месяц. Пока, вроде бы полет нормальный. Хотя времени прошло не так и много.

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

Собственно, об этом мы и писали в цикле по гарантии: все сложные ситуации и дорогие комплектующие будут долго ездить по сервисам, так как никто на себя ответственность за них не возьмет. И свободных, заведомо исправных компонентов серверного класса в сервисах тоже нет.

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

Ну и самому покупателю проще – не работает и все! А там можно и ненадлежащее качество подтянуть через ст. 475 ГК РФ. В общем как бы и все тоже самое, но позиция покупателя, даже юридического лица, становится юридически гораздо более выгодной.

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

​​Критерии выбора оборудования для сервера 1С:Предприятие. Память

Вопрос выбора оперативной памяти, а точнее ее необходимого количества является с одной стороны простым, а с другой – весьма и весьма сложным и ниже мы поговорим почему.

Мы не будем касаться аппаратной части выбора, здесь все ясно – чем быстрее память, тем лучше, но такого критического значения как у процессора ее частота не имеет.

Основными критериями выбора будет являться ее необходимый объем.

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

Идем в сеансы и смотрим следующие показатели, естественно – в разгар работы: Память (5 мин) и Память (всего). Первый показатель покажет максимальное значение потребления памяти за пять минут, второй – за сеанс.

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

А в реальной обстановке у нас могут иметь место утечки памяти, чаще всего по вине неоптимальных доработок или внешних отчетов, но могут «течь» и вполне типовые конфигурации.

Второе зло – зависшие сеансы. Стандартный срок жизни такого сеанса – 86400 секунд или 24 часа, что достаточно много. Возникать такие сеансы могут по многим причинам, чаще всего от мобильных пользователей, которые несколько раз переподключаются к серверу перемещаясь от одного провайдера к другому.

В результате реальное количество сеансов может оказаться существенно выше запланированного и привести к неприятным последствиям.

Дело в том, что у платформы уровня ПРОФ отобрали все инструменты управления памятью и заставили довольствоваться параметрами по умолчанию.

Первый из них: Временно допустимый объем памяти процессов, по умолчанию он равен 70% памяти сервера. Второй связанный с ним параметр: Интервал превышения допустимого объема памяти процессов, равный 300 секундам (5 минут).

Таким образом, если рабочие процессы на протяжении более 5 минут будут потреблять более 70% памяти сервера, то начнется их мягкий перезапуск. Для этого создается новый рабочий процесс и ему передаются текущие сеансы, после того как все сеансы будут переданы – процесс будет завершен.

При этом начнет сервер с самого «жирного» рабочего процесса. А теперь снова вспомним об ограничениях платформы ПРОФ и придем к пониманию, что самым «жирным» будет один единственный доступный нам рабочий процесс со всеми сеансами.

При этом далеко не факт, что нам хватит свободной памяти перенести все сеансы. Потому как 70% - это довольно высокий лимит, да и сама ОС тоже нуждается в памяти.

После чего на сцену выходит еще один параметр: Критический объем памяти процессов – по умолчанию 95% объема памяти сервера.

По его достижении рабочие процессы начинают завершаться аварийно, начиная с самого «жирного», а в нашем случае – единственного.

Но это мы рассмотрели сферический сервер в вакууме, в реальности администраторы очень любят совмещать все на одном узле. И сервер 1С, и сервер СУБД, и веб-сервер. Во многом это обусловлено многочисленными материалами типа «Сервер 1С с нуля за пять минут», где просто дается последовательность действий и не поясняется архитектура системы.

А как мы могли видеть все показатели завязаны именно на объем памяти сервера и не поддаются изменению.

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

Выводы здесь довольно очевидны: обязательно выносим сервер 1С:Предприятие в отдельную виртуалку или контейнер и не совмещаем его с никакими другими ролями.

Рассчитываем потребности в памяти и накидываем сверху запас на зависшие сеансы и утечки памяти. А также принимаем меры по контролю сеансов и не забываем мониторить потребление памяти внутри системы с сервером 1С.

🟢 Протоколы OSPF и IS-IS: сходства и различия

 Получите ценные практические знания на бесплатном уроке от OTUS, где вы вместе с опытным экспертом:

1. Разберетесь в сходствах протоколов OSPF и IS-IS
2. Рассмотрите их различия
3. Настроите протоколы OSPF и IS-IS в сети на практике 

👉 Вебинар проведет Николай Колесов, профессионал с 18 летним опытом, эксперт ТАС вендора по решениям routing&switching и data center

Занятие пройдёт 7 марта в 20:00 мск и будет приурочено к старту курса «Network Engineer». Доступна рассрочка на обучение!

🔥 Пройдите короткий тест прямо сейчас, чтобы занять место на открытом уроке и получить запись: https://otus.pw/Rsll/

​​Там, где светлее

Буквально недавно мы поднимали вопрос диагностики и говорили о том, что это задача достаточно сложная, в которой нужен системный подход. Почитать об этом можно здесь: https://t.iss.one/interface31/2129

Но поведение многих наших коллег напоминает мужика из анекдота, который ищет часы не там, где потерял, а под фонарем, потому что там светлее.

Буквально сегодня столкнулся с тем, что в одном из каналов человек задает вопрос в стиле «Никто не сталкивался с такой ошибкой?» и прикладывает скриншот.

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

Когда у него поинтересовались, а что непонятного в ошибке, он снова начал о том, что «Никто не сталкивался?».

И только когда ему уже несколько раз сказали, что смотреть нужно на другой стороне, робко спросил: «А, так это на сайте?»

Квалификация и опыт у всех разные, это понятно. Но любой, подчеркну, любой специалист должен обладать начальными навыками диагностики. Самый первый и базовый принцип которой – смотри в логи!

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

Но шаг вправо, шаг влево и такой «специалист» становится беспомощным, так как даже не представляет, где и что ему посмотреть.

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

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

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

Очень часто, во время составления подобной темы на форуме проблема решалась, не сама собой, а именно благодаря тому, что пришлось-таки углубиться в логи, почитать, подумать.

В свое время чтение логов считалось занятием будничным, практически повседневным. Часто можно было услышать: «Сижу утром, пью кофе, читаю логи»

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

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

Ведь лог – это не только сообщение об ошибке, это целое жизнеописание системы, по которому можно проследить что происходило до, во время, и после. И очень часто ключ к решению проблемы лежит именно там, во вроде бы обычных строках уровня «Информация».

Если провести аналогию, то инспектор ГИБДД приехав на место ДТП не зацикливается на факте происшествия и не спрашивает коллег, посылая фото: «Никто с таким не сталкивался?». А начинает методично восстанавливать события, предшествовавшие аварийной ситуации.

Ровно также должен действовать администратор, выясняя какие именно события предшествовали ошибке и каким образом они могли на ее возникновение повлиять. Это – нормальный инженерный подход.

А зацикливаться на самом факте ошибки и сразу пытаться искать ответ в поисковиках, форумах и телеграм-каналах – это как раз искать не там, где потерял, а там, где светлее.

​​Ошибка резидента (загадка на ночь)

Один мой коллега попал на днях в не очень приятную историю. А началось все с того, что он поменял провайдера на точке в другом населенном пункте.

Ехать туда не очень хотелось и он решил сделать все удаленно. У старого провайдера настройки получались по DHCP, новый выдавал по PPPoE.

Коллега заранее создал новый PPPoE-интерфейс, прописал для него маскарадинг и просто попросил сотрудника в удаленном офисе вынуть старый провод и вставить новый.

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

Примерный набор старых правил для понимания ситуации:

add action=accept chain=input connection-state=established,related in-interface=ether5
add action=drop chain=input connection-state=invalid in-interface=ether5
add action=accept chain=input in-interface=ether5 protocol=icmp
add action=accept chain=input dst-port=8291 in-interface=ether5 protocol=tcp
add action=drop chain=input in-interface=ether5

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

И неожиданно потерял доступ. Подождал пока роутер откатит изменения назад (Safe Mode был включен), снова зашел и снова потерял доступ…

Планируемый набор новых правил:

add action=accept chain=input connection-state=established,related in-interface-list=WAN
add action=drop chain=input connection-state=invalid in-interface-list=WAN
add action=accept chain=input in-interface-list=WAN protocol=icmp
add action=accept chain=input dst-port=8291 in-interface-list=WAN protocol=tcp
add action=drop chain=input in-interface-list=WAN

Что мой коллега раз за разом делал не так?

Как углубить свои знания об архитектуре ПО всего за пару часов?

Прийти на бесплатный практический урок «Тактики работы с обнаруживаемостью в архитектуре программного обеспечения» от OTUS. На вебинаре разберём:
- что такое observability и почему это важно для бизнеса;
- как использовать инструменты мониторинга и алертинга для повышения обнаруживаемости;
- принципы и практические примеры использования USE и RED;
- четыре золотых сигнала, которые помогут оптимизировать работу с обнаруживаемостью.

Встречаемся 6 марта в 20:00 мск в рамках курса «Software Architect». Доступна рассрочка на обучение!

Пройдите короткий тест прямо сейчас, чтобы посетить бесплатный урок и получить запись: https://otus.pw/wcX1/?erid=LjN8KSvcn

Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

​​Ошибка резидента (ответ на загадку)

Начнем с того, что результаты нас удивили и даже расстроили. Если отбросить 48% тех, кто зашел посмотреть ответы, то правильно ответили всего 19%.

При этом одними из самых популярных стали вообще абсурдные варианты (23% и 15%), которые были придуманы абсолютно из головы. Ну и предположения в комментариях совсем не порадовали.

Хотя ответ там лежит на поверхности, если, конечно, знать, как работает iptables, который находится у Mikrotik под капотом.

Такого критерия как список у iptables нет, и он воспринимает любой список как набор критериев, на основании которых он строит свои правила. Списки же используются для упрощения администрирования.

Фактически, если у нас в список WAN включены интерфейсы ether5 и pppoe-out1, то запись:

add action=drop chain=input in-interface-list=WAN

Будет эквивалентна:

add action=drop chain=input in-interface=ether5
add action=drop chain=input in-interface=pppoe-out1

Потому что список – это набор критериев, а несколько критериев всего объединяются через логическое И (или И-НЕ).

Как видим никакой магии в списках нет, и мы можем свободно сочетать списки с интерфейсами хоть в одном правиле, хоть в разных.

Если мы используем в одном правиле несколько списков, то результатом будут все возможные комбинации между ними.

Так если у нас есть еще один список LOCAL в который входят bridge1 и bridge2, то правило:

add action=drop chain=forward in-interface-list=WAN out-interface-list=LOCAL

Следует рассматривать как набор:

add action=drop chain=forward in-interface=bridge1 out-interface=ether5
add action=drop chain=forward in-interface=bridge1 out-interface=pppoe-out1
add action=drop chain=forward in-interface=bridge2 out-interface=ether5
add action=drop chain=forward in-interface=bridge2 out-interface=pppoe-out1

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

Но вернемся к нашим баранам, что произошло после того, как мы поменяли внешний интерфейс с ether5 на pppoe-out1? Мы получили полностью открытый брандмауэр, так как действие по умолчанию – ACCEPT и для интерфейса pppoe-out1 не было ни одного действующего правила.

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

Если же начать менять правила в обратном порядке, то поменяв в

add action=drop chain=input in-interface=ether5

Интерфейс на лист вместо одного правила мы получим два:

add action=drop chain=input in-interface=ether5
add action=drop chain=input in-interface=pppoe-out1

А теперь вспоминаем, что никаких других правил для интерфейса pppoe-out1 у нас нет и мы только что благополучно отключили роутер от внешнего мира.

Поэтому правильный ответ может быть только один: неправильная очередность изменения правил.

​​Продолжаем игру в вопросы-ответы

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

Поэтому сегодня вариант попроще. Подобным образом нас любил спрашивать преподаватель по радиопередающим устройствам.

Он рисовал на доске схему и спрашивал будет ли она работать. Потом мог стереть соединение и спросить, а что случится теперь. Такие занятия давали практическое понимание того, как работают те или иные компоненты и их влияние на систему целиком.

Итак, у нас имеется следующая конфигурация iptables:

*nat
:PREROUTING ACCEPT [55:2444]
:INPUT ACCEPT [55:2444]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.20.1.0/24 -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [2330:3679979]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -p udp -m udp --sport 123 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 21 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 34567 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 60200:60299 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp-host-prohibited

Вопрос №1: будет ли работать выход в интернет через WireGuard сервер, работающий на порту 34567?

Вопрос №2: что будет, если мы уберем первое правило в цепочке INPUT?

​​Ответы на вчерашние вопросы

В комментариях к предыдущей заметке нам посетовали, что мол мы не предоставили полной информации по вопросу, поэтому…

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

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

И навык анализа в условиях недостатка информации является для администратора одним из важнейших. Тем более что были приведены варианты ответов (читай – гипотезы), которые следовало только проверить.

Ладно, вчера мы решили дать задачу попроще, с полной информацией, практически исчерпывающей, так как ответы фактически уже написаны.

Тем не менее на первый вопрос правильно ответила только половина читателей (из тех, кто отвечал), при этом треть из них ответила, скажем так, на «троечку». Почему?

Потому что ответ «Не будет» формально верный, но ниже есть более развернутый ответ, который наиболее точно характеризует поведение системы.

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

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

Поэтому правильный ответ на первый вопрос: «Подключение будет, выход в интернет нет».

Со вторым вопросом все еще хуже, на него правильно ответили только 27% читателей, т.е. меньше трети.

Хотя он, в принципе, даже проще предыдущего. После того, как мы уберем первое правило, которое разрешает RELATED,ESTABLISHED – т.е. уже установленные соединения, у нас в цепочке INPUT останутся только правила для новых пакетов (NEW), все остальное будет запрещено последним REJECT.

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

А самое интересное в том, что правильный ответ со всеми необходимыми обоснованиями был дан еще вчера вечером в одном из первых комментариев.

В общем – выводы каждый должен сделать самостоятельно.

​​Забавная маршрутизация

Маршрутизация – пожалуй одна из самых сложных тем для начинающих, да и не только для них.

Вроде бы с одной стороны все просто, а с другой – не очень. Особенно если у нас есть пересекающиеся маршруты.

Когда-то давно мои заказчики попросили придумать задачку для собеседования на тему маршрутизации и базового понимания сетей.

Задачка простая, но не совсем очевидная.

Итак, имеется следующая таблица маршрутизации:

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/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.

Таким образом правильным является третий вариант ответа в вопросе. Количество ответивших правильно и сделать выводы каждый может самостоятельно.

Пятничное, вечернее. О жизни

Идем из гостей домой, решили зайти в магазин.

Навстречу семья, мама и папа впереди с пакетами, сзади топают девочка и мальчик, лет 9 и 12.

Не знаю о чем они там говорили, но при нашем приближении девочка отчитывала мальчика:

- Ты неправильно говоришь! Люди - это афганцы, а афганка - это конопля...

Жена призналась мне, что до этого она не знала, что афганка - это конопля.

Вот такие детки в клетке...

Угадай систему по скриншоту

Сегодня выходной, в том числе и от вчерашнего праздника.

И попался под руку один интересный скриншот.

Кто угадает, что за система на нем изображена и насколько она актуальна в настоящее время?

​​Понедельник – день тяжелый

А после длинных выходных – тем более. Мы уже давно отметили интересную статистику, перед выходными количество обращений всегда снижается. А перед длинными выходными и праздниками оно снижается существенно.

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

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

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

Но проблема в том, что таким образом «под ковер» могут заметаться и достаточно серьезные проблемы, опять-таки сугубо из того, что никому не хочется работать в праздники. Ну и памятуя о том, что инициатива делает с инициатором.

Мониторинг, скажете вы, и снова будете не правы. Уведомления от мониторинга приходят таким же людям, как и все остальные и эти люди также не горят желанием работать на выходные или в праздники.

Можно, конечно, поставить многоуровневые уведомления и спускать задачи принудительно сверху вниз, но надо понимать, что тут возникнут дополнительные негативные факторы, такие как небрежное выполнение работы (лишь бы триггер перестал срабатывать), выполнение работ в состоянии алкогольного опьянения и т.д. и т.п.

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

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

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

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

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

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

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

Лично мы считаем такую практику сугубо порочной и исходим из принципа, что если задачу можно отложить на понедельник – то ее следует отложить на понедельник.

Очевидный плюс такого подхода – что задачи не будут «заметаться под ковер», а вовремя вносится в систему учета заявок и будут показывать реальную загрузку на первый рабочий день новой недели.

Это, в свою очередь, позволит избежать ситуации, когда в понедельник задачи «внезапно» сваливаются как снег на голову.

А какой подход практикуете вы? Бывает ли у вас завал по понедельникам?