Не упустите шанс посетить бесплатный вебинар по настройке кластера Elasticsearch 8 от OTUS!

🌟 Спикер Андрей Буранов, опытный системный администратор, расскажет о том, как настроить кластер из 3-х нод, определить статус кластера и индексов, а также многое другое.

На вебинаре вы узнаете:

- 📊 Что такое шарды и реплики
- ⚙️ Как настроить кластер Elasticsearch 8
- 🔍 Как определить статус кластера и индексов
- 🗺 Как выяснить местоположение шарда и количество его реплик
- ➕ Как добавить новую ноду в существующий кластер

Присоединяйтесь к нам 26 ноября в 20:00 и получите 10% скидку на курс "Administrator Linux. Professional" при регистрации! 🎉

📚 Программа курса:

- Архитектура Linux
- Управление, безопасность и мониторинг
- Linux и сеть
- Сервисы Linux
- Проектная работа

Вебинар будет полезен системным администраторам и девопсам. Не упустите возможность повысить свою квалификацию! 🚀

👉 Зарегистрироваться на вебинар https://otus.pw/yLRs/?erid=LjN8KPqoU

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

​​До свиданья наш ласковый миша

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

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

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

В чем проблема? А проблема в таком явлении, как bitrot, битовое гниение (https://yangx.top/interface31/2600) – деградация данных, не связанная с физическим выходом из строя накопителя и часто даже не препятствующая чтению данных, так как встроенные во многие форматы методы коррекции позволяют такие ошибки исправлять.

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

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

Но они правы и буквально вчера мы столкнулись с неприятной ситуацией с битовым гниением на mdadm.

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

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

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

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

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

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

А причем тут mdadm? А при том, что все это хранилище как раз было организовано средствами mdadm: LVM поверх двух зеркал по 4 ТБ.

Да, mdadm защищает нас от физического выхода диска из строя, но от битового гниения спасти не может.

Кто может? Современные файловые системы с контролем целостности данных: ZFS или btrfs, но для этого избыточность также должна создаваться средствами этих ФС, в этом случае они смогут эффективно выявлять повреждения и восстанавливать их за счет избыточных данных.

Если же вы просто натянете btrfs поверх mdadm – то ничего работать не будет, избыточность брать неоткуда.

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

NVMe-over-TCP - практическое знакомство с технологией

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

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

Сохранить высокие показатели при работе с новыми накопителями по сети нам поможет протокол NVMe-over-TCP, с которым мы сегодня познакомился не только в теории, но и на практике.

https://interface31.ru/tech_it/2024/10/nvme-over-tcp---prakticheskoe-znakomstvo-s-tehnologiey.html

​​Выйти из АйТи

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

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

Но все ли так хорошо в АйТи? Нет и наряду с желающими войти находятся и желающие выйти.

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

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

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

Я как раз зашел заправить картридж, а он просто ехал мимо, решил заскочить.

И как сейчас выяснилось – он радикально сменил вид деятельности и теперь на том же предприятии заведующий столовой.

Готовка его, кстати, давно привлекала, дело это он любил и даже закончил после 9 классов кулинарный колледж, но потом, как и многие, пошел за длинным рублем в IT.

И где-то в середине десятых работа начала его сильно тяготить. Потому что IT на предприятии – это сплошной негатив. Ну кто-то идет довольный в IT-отдел? Нет, туда идут, когда что-то не работает. Ругаются, скандалят, требуют.

Постоянное «мы ничего не трогали, оно само» или попытки оправдать свои просчеты «плохими компьютерами и программами».

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

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

Примерно в 2017 его предприятие купило завод в области, к нему в наследство досталась столовая, которая была там объектом поистине социальным. Кроме сотрудников предприятия там питалась практически вся промзона.

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

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

Ну он и взял, успешно автоматизировал и оптимизировал данный контур, заодно вскрыв многочисленные «недочеты» прошлых лет. А вскрыть их можно было только обладая профессиональными знаниями, типа норм потерь на ГО и ХО, и всяких норм закладки и выхода.

После чего предложил шефу на этой должности его и оставить. Шеф подумал и согласился, при условии, что он найдет себе замену. Замену он нашел.

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

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

Работой своей полностью доволен. Сплошной позитив, люди приходят, кушают, говорят спасибо. И разборки уровня «менеджеров среднего звена» также обходят его стороной, столовая она как-бы государство в государстве. С кем там интриговать?

Развиваться? Тоже есть куда, кулинария – дело такое, творческое. В IT обратно не стремится и очень рад что сумел вовремя «выйти».

Запуск нескольких экземпляров сервера на одном компьютере является штатной возможностью сервера 1С:Предприятие и позволяет использовать несколько платформ одновременно или разделить сервера на рабочие и тестовые.

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

Процесс установки дополнительных экземпляров сервера 1С:Предприятие в целом несложен, описан в официальной документации, но имеет некоторые свои тонкости.

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

🔹 Установка и запуск нескольких экземпляров сервера 1С:Предприятие на одном компьютере. Платформа Windows

🔹 Установка и запуск нескольких экземпляров сервера 1С:Предприятие на одном компьютере. Платформа Linux

Вопрос по субботам

Имеется Mikrotik в конфигурации по умолчанию, в самое начало цепочки input мы добавили правило:

ip firewall filter add chain=input protocol=udp dst-port=67 action=drop

Правило рабочее, счетчики увеличиваются.

❓❓❓Будет ли работать DHCP-сервер на роутере?

​​Почему будет работать DHCP-сервер

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

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

А как работать с сетью, если сети еще нет? Понятно, что стандартные инструменты здесь подходят мало и было принято решение использовать Berkeley Packet Filter (BPF).

Berkeley Packet Filter (BPF) – это механизм в UNIX и Linux системой который позволяет работать с сырым трафиком (raw sockets) выполняя захват и фильтрацию.

Поэтому в системе на уровне ядра настроен отдельный BPF на захват DHCP-трафика и этот захват происходит раньше, чем трафик попадает в Netfilter – еще один компонент ядра, который осуществляет фильтрацию пакетов, т.е. является настоящим брандмауэом.

Это важно помнить, фильтрацией трафика в Linux занимается именно Netfilter, а iptables, nftables, ufw и т.д. и т.п. – это всего лишь высокоуровневые интерфейсы для управления им.

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

Постойте, скажет кто-нибудь, это же касается DHCP-клиента, а у нас сервер. Но на самом деле это касается любой системы, вне зависимости от ее роли. На уровне BPF система понятия не имеет о ролях и софте, она просто делает свою работу – захватывает DHCP-трафик.

Поэтому вне зависимости от того, клиент перед нами или сервер, DHCP-трафик в брандмауэр не попадает. А Router OS, являясь по происхождению Linux системой унаследовала это поведение.

🙂 Выиграйте беспроводную колонку!

Fplus растет активно растет и предлагает все больше гаджетов для вашего быта, работы и отдыха. Не хотите пропустить свежие новости? Подписывайтесь на Fplus и участвуйте в конкурсе!

Как принять участие:
1. Подпишитесь на канал @fplus_ru
2. Нажмите кнопку “Принять участие” под конкурсным постом

Оставайтесь на связи и следите за розыгрышем!

Приз - беспроводная колонка, а результаты конкурса будут объявлены 3 декабря ! 😉

С полными правилами розыгрыша можно ознакомиться по ссылке!

erid: LjN8K7Re6

​​Когда DNS использует UDP, а когда TCP?

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

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

А вот что такое ограничение на 512 байт и откуда оно взялось? Это связано с техническими ограничениями протокола UDP и обеспечением обратной совместимости. Проще говоря, если мы хотим быть уверенными, что любой узел сможет получить DNS-ответ по UDP, его размер не должен превышать 512 байт.

В противном случае сервер должен перейти на использование протокола TCP, либо клиент получит усеченный ответ (то, что поместится в 512 байт).

А теперь о том, какие именно записи могут превышать 512 байт:

🔸 Многочисленные записи: если запрашивается доменное имя, которое имеет много A-записей или AAAA-записей размер ответа может превышать 512 байт.

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

🔸 Записи типа CNAME: могут указывать на доменные имена, которые имеют многочисленные А-записи

🔸 DNSSEC: в этом случае дополнительные криптографические записи (RRSIG, DNSKEY) могут значительно увеличить размер ответа.

🔸 Дополнительные записи: например, NS, TXT или SRV записи, которые могут быть многочисленными и иметь достаточно большой размер.

Однако использование TCP в данном случае не является обязательным, существуют расширения протокола DNS - EDNS0, в рамках которого резолвер может в запросе указать какой размер ответа он может принять через UDP и сервер отправит ему такой ответ даже если его размер превышает 512 байт.

❓Кто должен поддерживать TCP? Согласно стандарту, все реализации должны поддерживать оба протокола, но есть и более строгие требования.

Стандарт требует обязательной поддержки от:

🔸 Авторитативного сервера, хранящего зону для ее возможной передачи тому, кто имеет право ее запросить

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

🔸 Конечных DNS-клиентов (реализаций в ОС и т.д.) – для возможности принимать не усечённые запросы.

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

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

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

Также стандарт устанавливает порядок использования протоколов. Резолвер прежде всего должен попытаться выполнить UDP-запрос, должен, но не обязан.

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

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

Установка и настройка сервера лицензирования 1С:Предприятие

Управление лицензиями 1С:Предприятия - задача не простая, особенно если у вас в эксплуатации несколько серверов или используется виртуализация.

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

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

https://interface31.ru/tech_it/2024/11/ustanovka-i-nastroyka-servera-licenzirovaniya-1spredpriyatie.html