Записки IT специалиста

Установка платформы 1C:Предприятие для разработчиков на платформе Windows

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

Это стало огромным шагом вперед, так как позволило многим разработчикам, энтузиастам и просто интересующимся легально попробовать платформу 1C:Предприятие в клиент-серверном варианте.

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

https://interface31.ru/tech_it/2024/08/ustanovka-platformy-1cpredpriyatie-dlya-razrabotchikov-na-platforme-windows.html

​​Нужен ли сторонний софт для распознавания текста в Windows 11?

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

Но при этом сама система получила множество новых функций и улучшений. Одно из самых значимых из них как-то незаметно прошло мимо – это оптическое распознавание символов.

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

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

Чтобы распознать текст не нужно даже снимать скриншот картинки, достаточно ее просто открыть в приложении и нажать отмеченную на скриншоте кнопку.

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

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

​​Спрашивают – отвечаем. Какой утилитой можно посмотреть какой процесс сколько занимает памяти.

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

Для этих целей следует использовать утилиту smem, которая доступна в стандартных репозиториях.

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

Если запустить утилиту без параметров, то вы получите список процессов в указанием занимаемой ими памяти в килобайтах отсортированный по возрастанию значений колонки PSS.

Всего колонок четыре, коротко разберем что они обозначают:

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

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

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

🔸 Swap – объем сброшенных в подкачку страниц памяти процесса.

Сразу запоминаем полезные ключи программы:

▫️ -t - выводит снизу результирующую строку по всем колонкам
▫️ -p – представляет значение в процентах от общего объема памяти, а не в килобайтах
▫️ -а – подстраивает ширину колонок под текущий размер окна терминала

Как мы уже говорили, сортировка ведется по возрастанию колонки PSS, т.е. самые «жирные» процессы будут внизу.

Это поведение можно изменить ключами -s и -r, после которых следует указать имя колонки для сортировки. Ключ -r сортирует значения в обратном порядке – по убыванию значений.

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

smem -tap -r swap

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

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

smem -tpa -P postgres -r pss

Или все процессы пользователя 1С:Предприятия:

smem -tpa -U usr1cv8  -r pss

Что еще можно посмотреть с ее помощью? Использование памяти в разрезе пользователей с ключом -u или по всей системе с ключом -w.

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

1С:Предприятие и многопоточность. Часть 1. Общие вопросы

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

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

Современная 1С – это сложное клиент-серверное приложение, хранящее данные в СУБД, что представляет собой классическую трехзвенную схему: фронтенд, бэкенд, база данных.

СУБД, применительно к 1С, хранит не только пользовательские данные, но и исходный код конфигурации (прикладного решения), однако это в рассматриваемом нами контексте не имеет никакого значения.

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

Фронтенд, в терминах 1С – Клиент – выполняет взаимодействие с пользователем, выводит ему полученные от Сервера данные и передает Серверу данные, введенные пользователем для обработки. Также выполняет несложные вычисления, не требующие обращения к хранимым в СУБД данным.

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

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

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

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

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

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

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

Да, с точки зрения айтишника в вакууме это может быть смешно и непонятно, ведь можно…

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

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

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

Сообщение Роскомнадзора о том, что в России принимают меры по частичному ограничению звонков в Telegram и WhatsApp:

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

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

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

Доступ к звонкам в иностранных мессенджерах будет восстановлен после выполнения ими требований российского законодательства, пояснили в Минцифры РФ.

​​Postgres + 1C = сильно тормозит?

Самое частое нарекание на работу свежеустановленной связки PostgreSQL + 1С:Предприятие – это тормоза. Причем именно тормоза, а не замедление, и часто видимые невооруженным глазом.

Означает ли это, что Postgres плох? Вовсе нет, просто привычный подход Далее – Далее – Готово здесь не работает.

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

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

Как это сделать – написано в нашей статье: Оптимизация производительности PostgreSQL для работы с 1С:Предприятие

​​Что такое SRV-записи DNS и для чего они нужны

В комментариях к нашим заметкам по DNS уже не раз спрашивали: что такое SRV-записи и для чего они нужны.

Начнем немного издалека. Все знают, что основная задача DNS сервера – это разрешение имен, т.е. преобразование понятных человеку доменных имен в IP-адреса. Для этого используется запись типа А, которая прямо сопоставляет имя и IP-адрес. Например:

pc-petya   IN A 192.168.121.156

Она говорит, что узел сети с именем pc-petya имеет адрес 192.168.121.156.

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

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

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

Что мы будем делать в реальном мире? Правильно, спросим: а где тут почта?

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

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

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

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

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

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

Давайте посмотрим на реальные SRV-записи, например, служб Яндекса. Начнем с такой:

_xmpp-server._tcp 21600 IN SRV 20 0 5269 domain-xmpp.yandex.net.

Имя записи: _xmpp-server._tcp – т.е. межсерверное общение XMPP-серверов по протоколу TCP.

Далее идет TTL – 21 600 сек (6 часов) и тип записи IN SRV, после чего указан ее приоритет – 20 (здесь как в MX – чем ниже, тем предпочтительнее) и вес 0 (используется для выбора нескольких записей с одинаковым приоритетом), затем порт – 5269 и узел, на котором располагается данная служба - domain-xmpp.yandex.net.

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

А вот еще запись:

_xmpp-client._tcp 21600 IN SRV 20 0 5222 domain-xmpp.yandex.net.

Она отличается только именем _xmpp-client._tcp и сообщает куда должны подключаться XMPP-клиенты через TCP. Также можем увидеть здесь другой порт.

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

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

Также SRV-записи широко используются в Active Directory, с их помощью клиенты находят контроллеры домена, глобальные каталоги, узлы Kerberos и т.д.

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

​​А зачем нам DNS если у нас нет домена?

Довольно часто встречаемся с этим вопросом, особенно когда поднимаем службу DNS в сравнительно небольших сетях. Почему-то у многих коллег DNS прочно ассоциируется с Active Directory. Может быть что и там, и там домен?

Но тем не менее DNS-это одна из важнейших сетевых служб, даже для небольших сетей и хороший задел на будущее.

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

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

А дальше? А дальше коллеги пытаются жить среди плоских имен и IP-адресов, но ни то, ни другое не доставляет хорошего настроения.

Плоские имена, это имена, не являющиеся полностью определенным доменным именем (FQDN), например, PC-02. Разрешение данных имен осуществляется через широковещательные протоколы и действует только внутри широковещательного домена (сегмента сети).

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

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

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

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

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

И вот тут возникает занимательный квест: найди все места, где были забиты IP-адреса и поменяй их. Как показывает опыт – с первого раза его еще никто не проходил.

Отдельная песня – мобильные пользователи, мы ни раз и ни два видели наборы ярлыков «Общая папка офис», «Общая папка из дома» и т.д. и т.п. Связанные с тем, что в разных расположениях один и тот же сервис имел разную IP-адресацию.

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

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

Теперь вам не нужно вспоминать какой адрес имеет тот или иной узел, достаточно знать его имя, плоское. Система сама дополнит его до FQDN при помощи доменного суффикса и разрешит имя в адрес при помощи DNS-сервера.

Но это потребует определенного порядка и системы в наименовании узлов, потому как если компьютеры у вас называются как-то вроде DESKTOP-7GRSBHN, то толку от перехода на обращение по именам будет немного.

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

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

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

Мы — СЕРВЕР МОЛЛ, и наш профиль — серверное и сетевое оборудование от Dell, HPE, Lenovo, Supermicro и других вендоров.
📦 Отгрузка со склада (обычно в день заказа) — и бесплатная доставка по всей России.

Что предлагаем:

✔️ Серверы — новые и восстановленные. Причем восстановленные — это  полная диагностика, замена накопителей на новые, стресс-тесты и точная сборка;
✔️ Сетевое оборудование
✔️ Системы хранения данных (СХД)
✔️ Гарантия  — до 5 лет.

Подберём решение под ваши задачи и бюджет.
Постпродажная поддержка и консультации в любых объёмах.

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

SERVERMALL.RU
Телефон: 8(800)755-25-51
Почта: info@servermall.ru
Telegram: @Servermall_sale_bot

#реклама
О рекламодателе

Локальный домен – как сделать и забыть про IP-адреса как страшный сон

До сих пор сталкиваюсь с ситуацией, когда коллеги по непонятным причинам игнорируют возможность создания локального пространства доменных имен и продолжают «развлекаться» с IP-адресами и плоскими именами в файлах hosts.

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

Что для этого понадобится? Во-первых, локальный домен. Это может быть как поддомен существующего и принадлежащего вам доменного имени, так и домен в одной из специальных зон: .test, .example, .invalid и .localhost. Две последние, а особенно .localhost использовать не рекомендуется.

Также не следует использовать домен .local, который в протоколах мультикаст DNS (mDNS) технологии zeroconf.

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

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

Сделать это не сложно, мы рассказывали об этом в статье:

🔹 Настраиваем отказоустойчивый DNS-сервер на базе BIND 9

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

Также следует добавить для передачи клиентам опции 15 domain-name и 119 domain-search, которые должны содержать имя вашего домена.

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

Про настройку DHCP мы также писали, можете выбирать между проверенным ISC DHCP или более современным Kea.

🔹 Настраиваем отказоустойчивый DHCP-сервер на базе ISC DHCP

🔹 Установка и базовая настройка DHCP-сервера Kea

Ну и если ваши клиенты активно общаются между собой и при этом получают адреса по DHCP, то имеет смысл настроить автоматическое обновление записей DNS-сервера на основе данных аренды DHCP:

🔹 Настраиваем динамическое обновление DNS-сервера BIND 9 при помощи ISC DHCP

🔹 Настраиваем динамическое обновление DNS-сервера BIND 9 при помощи Kea DHCP

Указанных выше материалов вполне достаточно, чтобы настроить собственное локальное пространство имен и полноценно использовать его забыв как об обращении по IP-адресам как страшном сне.

Витая пара

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

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

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

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

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

Например, мы подали на первый проводник сигнал в +2 В, а на второй -2 В. Разница потенциалов у нас составит 4 В. Теперь представим внешнюю помеху с уровнем в 1,5 В. Таким образом в первом проводнике мы получим уровень сигнала +3,5 В, во втором – 0,5 В, но разность потенциалов останется прежней, все те же 4 В.

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

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

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

Стандарт TIA/EIA-568A и пришедший ему на смену TIA/EIA-568B задают в числе прочего порядок разводки разъема 8P8C, более известного как RJ45.

Для 10 и 100 Мбит/с используется две пары из четырех. Которые разводятся на 1-2 и 3-6 контакт разъема, при этом используются зеленая и оранжевая пара. Такая странная разводка сделана для совместимости с телефонным разъемом 6P4C (RJ11), который как раз попадает на 4-5 контакт.

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

Итак, что будет если мы не будем следовать стандарту и вложим провода в разъем в том порядке, который нам нравится?

Если мы будем соблюдать раскладку контактов по парам: 1-2, 3-6, 4-5, 7-8 – то ничего страшного не случится, кабель полностью сохранит свои частотные характеристики.

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

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

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

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

​​Что не так с Cat 7?

Один мой хороший знакомый, третьего дня решил проапгрейдить домашнюю сеть до 2,5 Гбит/с. Зачем? Не спрашивайте. Ну и каждый волен сходить с ума по-своему.

В общем выбрали мы с ним коммутатор, сетевые карты и дело дошло до патч-кордов. И вот он присылает мне пару артикулов и спрашивает, что я об этом думаю.

А артикулы были примерно такие: Патч-корд NAME [круглый, SF/FTP, RJ-45, Cat. 7, длина - N м]

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

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

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

Наиболее распространены и привычны кабели категории Cat 5e, они предусматривают физический размер (диаметр) 24AWG (0,51 мм) и разъем 8P8C RJ-45. Максимальная передаваемая частота – 100 МГц, это обеспечивает связь на скоростях до 1 Гбит/с на расстоянии до 100 м.

Но гигабита скоро стало мало и был разработан новый стандарт – Cat 6, который предполагал несколько более крупный кабель - 23AWG (0,585 мм) и все тот же разъем 8P8C RJ-45. Кабель поддерживал частоту передачи до 250 МГц и поддерживал скорость до 10 Гбит/с на расстоянии до 35-50 м.

Одновременно с ним, а это было в 2002 году, был представлен стандарт Cat 7, который при тех же физических размерах кабеля обеспечивал рабочие частоты до 600 МГц и передачу на скорости 10 Гбит/с на расстояние до 100 метров.

Вот он долгожданный прорыв… или нет? Скорее всего второе. Стандарт Cat 7 предусматривал применение проприетарных разъемов GG45 или TERA. При этом первый из них обратно совместим с RJ-45.

Но все кроется в мелочах. Разъем GG45 предусматривает 4 дополнительных контакта для заземления, а сам кабель седьмой категории обязательно должен быть типа STP (S/UTP), т.е. иметь экран на каждой паре и общий экран для всего кабеля.

Все это серьезно отражается на стоимости и кабель Cat 7 стоит ощутимо дороже своих аналогов.

Так может есть за что переплатить? Увы. Все преимущества данного кабеля раскрываются только с проприетарными разъемами. В режиме совместимости с RJ-45 рабочая частота кабеля падает до 200-250 МГц, т.е. на уровень куда более дешевого Cat 6.

А немного позже вышел Cat 6a, который на обычной витухе позволял достичь рабочих частот до 500 МГц и передавать 10 Гбит/с на расстояние до 100 метров, правда при строгом соблюдении всех правил монтажа.

А что касается бытовых сетей и скоростей 2,5 Гбит/с, то кабели Cat 6a полностью соответствуют всем требованиям и при этом доступны и недороги.

Хотя Cat 7 красивее и дороже (хотя по реальным параметрам хуже), но это уже что-то из области аудиофилии и прочих антинаучных забав.

​​Раз уж мы подняли тему DNS, то разберем основные ресурсные записи:

SOA - Start of authority - начальная запись зоны
NS - Authoritative name server - сервера имен отвечающих за зону
A - Address - Адресная запись, соответствие между именем и IP-адресом
AAAA - Address v6 - Адресная запись в формате IPv6
CNAME - Canonical name - Каноническое имя для псевдонима (одноуровневая переадресация)
MX - Mail Exchanger - Адрес почтового шлюза для домена. Состоит из двух частей — приоритета (чем число больше, тем ниже приоритет), и адреса узла
SRV - Server selection - Указание на местоположение серверов для сервисов
TXT - Text string - Запись произвольных данных, до 255 байт в размере
PTR - Pointer - Соответствие адреса имени — обратное соответствие для A и AAAА

Теперь об особенностях их применения и характерных ошибках.

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

Второе. Во всех ресурсных записях, кроме A и AAAA следует указывать доменные имена, если есть A запись и CNAME для одного узла, то указываем имя из CNAME.

🛑 Неправильно:

@ IN MX 10 192.168.100.25

🛑 Неправильно:

@ IN MX 10 mail
mail IN CNAME srv-mx-01
srv-mx-01 IN A 192.168.100.25

✅ Правильно:

@ IN MX 10 srv-mx-01
mail IN CNAME srv-mx-01
srv-mx-01 IN A 192.168.100.25

Символ @ обозначает текущий домен, допустим example.com

Все записи могут быть абсолютными и относительными.

Абсолютные записи заканчиваются точкой ☝️ (корневой домен), например, example.com.

Относительные записи (без точки на конце) дополняются текущим доменом. Например srv-mx-01 - srv-mx-01.example.com.

👉 Распространенная ошибка - написать в файле зоны абсолютную запись без точки, тогда получим следующий сюрприз: example.com - example.com.example.com. Эта ситуация очень часто вызывает много затруднений у начинающих.

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

​​Почта России – бессмысленная и беспощадная

Про Почту России в принципе все всё знают и удивить очередным пробитым дном со стороны этой конторы трудно. Тем более что снизу каждый раз начинают достаточно громко и настойчиво стучать.

Но некоторые моменты кроме недоумения, граничащего с крайней стадией изумления (скажем так) не вызывают.

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

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

Когда я не нашел там никакого Озона, но обнаружил его наклейку на двери почтового отделения – меня начали одолевать сомнения. Я еще робко надеялся, что может как-нибудь обойдется… Не обошлось…

Как оказалось пункт выдачи Озон открыла сама Почта России, равно как и пункт выдачи Wildberries, добавив вывесок и наклеек к пустующим ранее окошкам.

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

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

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

Подходит моя очередь – поясняю, что надо вернуть Озон. ОК, пройдите вон на то окно. Открываю в телефоне штрих-код, но тут с меня требуют паспорт!
Паспорт??? На Озоне??? Зачем???

А пофиг, у них так положено. Ну, на крайний случай, можно показать QR-код из приложения Почта России. Хорошо, код показал.

А теперь с вас 70 рублей за пакет. Какой такой пакет? Ну в чем-то же его назад отправлять надо. Что за ерунда? Ну вот так или никак. Ладно, не обеднею.

Снова протягиваю телефон, но тетенька его игнорирует и пикает штрих-код на упаковке товара, которую я принес и заявляет, что это не их товар и возврату он не подлежит.

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

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

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

Ну как чего, написано Озон – значит Озон, мне как клиенту должны быть пофиг. На что мне рекомендуют по этому вопросу обращаться в центральное отделение, а не к ним. Зову начальника отделения. Его, как всегда, в таких ситуациях, нет. Зову того, кто вместо него. Тоже никого нет. Все сироты казанские… Бейджики с одежды сотрудников также быстро и незаметно исчезают…

В общем – классика. Мне только непонятно одно – зачем??? Зачем нужен весь этот дешевый балаган? Если работать это с таким подходом заведомо не будет. Ну ни один нормальный человек больше одного раза туда не придет.

Чего хочет добиться руководство открывая подобные «пункты выдачи»? Красиво отчитаться на очередные мудрые инициативы? Но оно бы и пес с ним, если бы не одно но. Такие инициативы сильно поганят нормальному бизнесу, который, может быть, и хотел бы открыть тут нормальный пункт – но не сможет, потому что территория уже занята Почтой.

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

☝️ 512 МБ хватит всем!

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

Перед вами "малинка" образца 2013 года. Тогда нам этих плат по рублю за мешок отдали из одного банка. Им было дешевле продать недорого, чем списывать и утилизировать. На них были тонкие клиенты на основе Windows XP Embedded и да, 512 МБ хватало.

Мы же ставили на них Linux и использовали под то, под что сегодня обычно ставят "малинки". В те годы вполне актуальные системы получались.

Сейчас же если только поностальгировать. Ну или RouterOS x86 попробовать поставить. 😉

Что такое Magic SysRq и чем он может быть полезен

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

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

Чтобы перейти в этот режим отправьте:

echo 1 > /proc/sys/kernel/sysrq

А затем обычно следует команда жесткой перезагрузки системы:

echo b > /proc/sysrq-trigger

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

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

Прежде всего, если у вас система с графической оболочкой, то следует отключить от нее консоль ввода-вывода чтобы быть уверенным, что никто его не перехватит:

echo r > /proc/sysrq-trigger

Затем пробуем отправить SIGTERM всем процессам (попросим завершиться их по-хорошему). Некоторое время ждем, так как не все могут это сделать мгновенно.

echo e > /proc/sysrq-trigger

А дальше: кто не спрятался – я не виноват, приступаем к принудительному завершению всех активных процессов (посылаем SIGKILL):

echo i > /proc/sysrq-trigger

Чтобы не потерять данные в буферах и кешах принудительно пишем их на диск (посылаем fsync):

echo s > /proc/sysrq-trigger

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

echo u > /proc/sysrq-trigger

А теперь можно и Reset нажать:

echo b > /proc/sysrq-trigger

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

​​А что именно мы мониторим?

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

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

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

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

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

А вот остальные значения нуждаются в серьезном тюнинге. Например, у Zabbix из коробки есть два триггера на дисковое пространство: низкое – 80% и критически низкое – 90%.

Если взять диск объемом в 4 ТБ, то эти значения получатся на уровне 3,2 и 3,6 ТБ, в первом случае у нас еще остается почти целый терабайт и можно спокойно работать несмотря на предупреждение. А при «критическом» срабатывании останется 400 ГБ, что при большинстве сценариев будет еще вполне достаточно на долгое время.

А теперь возьмем SSD 120 ГБ, 80% — это 96 ГБ, а 90 – уже 108 ГБ. Т.е. всего 12 ГБ между уровнями срабатывания и столько же еще в резерве. При интенсивной записи мы можем исчерпать такой размер за считанные минуты.

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

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

Можно, конечно, найти стандартный шаблон для приложения и радоваться, только вот чему?

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

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

Многие показатели могут иметь разлет значений на порядок, а то и несколько, скажем критическую нагрузку по IO для HDD средний SSD спокойно переварит, а для NVMе это будут вообще какие-то незначительные цифры.

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

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

Или на вопросы пользователей: «Почему тормозит продукт NAME?», будете отвечать: «Ну это же продукт NAME». Но, согласитесь, такой подход не красит специалиста.

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

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

​​Что означают метрики Pressure Stall Information (PSI) в Linux

В последнем релизе Proxmox VE разработчики добавили на панель новые метрики класса Pressure Stall Information, что, ожидаемо, вызвало волну интереса.

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

 /proc/pressure/<metric>

Где вместо <metric> следует подставить интересующий вас параметр: cpu, memory или io.

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

👉 У данных метрик есть две основные категории:

🔹 some — показывает время, когда хотя бы один процесс ожидает освобождения ресурсов

🔹 full — показывает время, когда все активные процессы ожидают освобождения ресурсов

Для каждой категории доступны следующие показатели:

🔹 avg10 — среднее значение за последние 10 секунд

🔹 avg60 — среднее значение за последнюю минуту

🔹 avg300 — среднее значение за последние 5 минут

❓ Как интерпретировать полученные значения? Существуют следующие рекомендации:

🔹 CPU pressure:

🔸 avg10:

▫️0-10% — нормальное состояние
▫️10-25% — умеренная нагрузка
▫️25% — критическое состояние

🔸 avg60:

▫️0-5% — нормальное состояние
▫️5-15% — умеренная нагрузка
▫️15% — критическое состояние

🔸 avg300:

▫️0-3% — нормальное состояние
▫️3-10% — умеренная нагрузка
▫️10% — критическое состояние

🔹Memory pressure:

🔸avg10:

▫️0-5% — нормальное состояние
▫️5-20% — умеренная нагрузка
▫️20% — критическое состояние

🔸 avg60:

▫️0-3% — нормальное состояние
▫️3-15% — умеренная нагрузка
▫️15% — критическое состояние

🔸 avg300:

▫️0-2% — нормальное состояние
▫️2-10% — умеренная нагрузка
▫️10% — критическое состояние

🔹 IO pressure:

🔸 avg10:

▫️0-15% — нормальное состояние
▫️15-40% — умеренная нагрузка
▫️40% — критическое состояние

🔸 avg60:

▫️0-10% — нормальное состояние
▫️10-30% — умеренная нагрузка
▫️30% — критическое состояние

🔸 avg300:

▫️0-5% — нормальное состояние
▫️5-20% — умеренная нагрузка
▫️20% — критическое состояние

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

​​Эскалации в Zabbix

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

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

Кто-то не заметил, не отработал, не хватило собственной квалификации, либо вообще принял ошибочные решения. Как все это отследить, как проконтролировать?

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

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

Самое простое – это кого-нибудь уведомить. Но как быть, если ответственный не увидел уведомления, не отреагировал или не справляется?

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

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

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

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

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

Для примера мы возьмем триггер «High CPU usage», т.е. когда процессор начинает стабильно выдавать высокую загрузку. Ситуация серьезная, но не катастрофическая. Дадим на решение вопроса 15 минут. Такое же время выделим на каждый шаг.

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

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

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

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

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

Количество шагов ограничено только вашей фантазией и позволяет реализовывать достаточно сложные сценарии.

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

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

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