Обиделся на честность
Источник: «Жиза ИТ руководителя»
Источник: «Жиза ИТ руководителя»
Соскучились по DIY на коленке? Уверен, что многим хотелось бы иметь дома рядом с 3D-принтером станок, который без грязи, дыма и дикого шума будет резать металл. Давайте попробуем собрать настольный электроэрозионный станок (EDM) своими руками из доступных материалов. Данная статья положит начало циклу статей по разработке, отладке и тестированию будущего инструмента. Конечная цель проекта — получить станок, который сможет вырезать детали из металла для создания своих копий.
Статья рассчитана на то, что вы обладаете базовыми знаниями в электротехнике, программировании микроконтроллеров (знаний Arduino хватит) и что облизывать провода под напряжением 80+ В не стоит :)
А начнём мы с самого главного — с разработки электроники EDM-станка и понимания процесса его работы.
Электроэрозия — это процесс разрушения проводящего материала (металла) под воздействием импульсного электрического разряда, возникающего между обрабатываемой деталью и режущим электродом. В промышленности эта технология позиционируется как высокоточный метод обработки. Серьезное оборудование обеспечивает точность до 0,01 мм и выше. Это невероятные цифры, но гнаться за ними мы пока не будем. Начнем с реализации бюджетного варианта проволочного отрезного станка. А теперь — в теорию.
Я не являюсь экспертом по физике и электронике, поэтому возможны неточности. Я попытаюсь рассказать об этом процессе так, как я его понял. Буду рад замечаниям и корректировкам.
Погружаемся в наносекундную временную шкалу. Во время обработки, деталь и электрод находятся в среде с диэлектриком, например, в ванне с дистиллированной водой (рассмотрим диэлектрик без примесей). В качестве материала электрода мы будем использовать латунь из-за содержания в ней цинка и небольшой стоимости. На электрод подаются короткие импульсы высокого напряжения (80+ вольт) с частотой 1 кГц и выше, в промышленных установках частота уходит за 100 кГц.
В момент, когда электрод подходит очень близко к детали (микроны), напряженность электрического поля в этом месте достигает критического значения и начинает локально вырывать электроны из электрода и разгонять их в сторону детали -- токи утечки.
На своём пути они сталкиваются с молекулами диэлектрика, возникает ударная ионизация и электрический пробой с образованием тонкого проводящего канала. Ток резко возрастает, канал мгновенно нагревается, происходит взрывное испарение диэлектрика с образованием крошечного газового пузыря (фазовый взрыв).
Дальше по планам у нас ионизация газа, формируется устойчивый плазменный канал, который существует в течение импульса тока. В плазменном канале загорается дуга, которая плавит электрод и деталь (в некоторых случаях материал сразу испаряется). Это не дуга в классическом понимании, как при сварке, наверное, лучше назвать это искрой.
Помним, что в нашем электроде есть цинк, он тоже начинает активно испаряться, забирая тепловой удар на себя и не давая электроду сгореть.
Когда напряжение снимается, разряд прекращается, температура резко падает, пузырь начинает коллапсировать, вышибая ударной волной расплавленный металл из зоны реза.
И так сотни тысяч раз в секунду. Электрический пробой, как правило, происходит в зоне максимальной напряжённости поля (минимальный зазор + усиление на микроскопических выступах), а значит, прежде всего разрушаются наиболее близко расположенные участки. Таким образом, нам не нужно думать о том, в каком месте ударить искрой, физика всё сделает за нас.
Вот здесь можно посмотреть все эти стадии на одной картинке.
Есть один нюанс. Дело в том, что искра выбивает часть металла не только из детали, но и из электрода. Поэтому просто взять тонкую проволоку и начать резать не получится, её придётся постоянно перематывать. И мы не можем бесконечно увеличивать частоту разрядов — нужно дать время на вымывание продуктов эрозии и восстановление свойств диэлектрика. Цинк в латуни помогает восстановить диэлектрическую прочность чуть быстрее.
Мы поняли базовый принцип работы и всего-то надо собрать контролируемый генератор электрических разрядов. Я немного погуглил и нашел простую схему генератора на базе RC-цепочки. Простой и надёжный — самое то для MVP.
Делать простую RC-цепочку мы, конечно, не будем, она не поддаётся динамическому контролю. Поэтому будем использовать MOSFET и несколько датчиков для контроля этого процесса. В качестве «мозга» схемы возьмём Arduino Due на первый этап запуска (потом уйдем на STM32F407).
Получилась следующая схема генератора. Разумеется, она родилась уже после сборки и тестирования макета — всё по канонам DIY, сначала делаем, потом думаем почему это заработало ;)
Давайте разберём, что тут и зачем. Я опустил подключение к микроконтроллеру, чтобы не загромождать схему, но расскажу, что куда:
DVCC_5V — цифровое питание 5 В, берём с платы Due;
DGND — цифровая земля, берём с платы Due;
VCC_80V — высоковольтный источник питания, цепляем к выходу DC-DC;
GND — высоковольтная земля, цепляем к выходу DC-DC;
VCC_12V — дополнительное питание периферии, можно взять с АКБ;
GATE_CTRL — управление MOSFET. Цепляем на аппаратный таймер (это важно!);
VOLTAGE_FB, CURRENT_FB — цепляем на аналоговые входы.
Входное напряжение схемы возьмём в диапазоне 70–90 В от DC-DC преобразователя и Li-Po АКБ на 12 В. В качестве DC-DC возьмём популярный SZ-BT07CCCV-A, этого парня должно хватить с большим запасом. Зарекомендовал он себя хорошо.
Даже есть небольшое видео его теста. Да, да, дуга рядом с ковром — безопасность и все дела. В свою защиту скажу, что в этот момент я был в очках и в гараже. DIY же, всё как мы любим.
Дальше по схеме у нас идёт микросхема ACS712ELCTR-30A-T — это датчик тока. Он нам необходим для контроля тока в цели и для отключения схемы в случае возникновения короткого замыкания.
За микросхемой следует мощный токоограничивающий резистор 10 Ом 50 Вт и батарея из плёночных конденсаторов К73-17. Ёмкость батареи я решил взять 10 мкФ, убрать лишнее можно в любой момент. Резистор в данном случае нужен в качестве дешёвой защиты схемы от токов короткого замыкания (спасал не раз — окупился в первый же момент). К сожалению, он нам ограничит не только ток, но и частоту работы схемы.
Я был свидетелем взрывов транзисторов, и с того момента схемы запускаю только с ограничениями тока.
Конденсаторы берём плёночные из-за их способности спокойно переносить частые импульсные разряды + у них низкий ESR.
Дальше по схеме мы видим нашего героя — MOSFET IRFP250NPBF. Этот парень поможет нам разрядить нашу батарею конденсаторов в плазменный канал и даже сделает это несколько раз. При параметрах Pulsed Drain Current = 120 А и Drain-to-Source Breakdown Voltage = 200 В, нам этого транзистора должно хватить с запасом. Да и бонусом он нам даёт довольно неплохой Rds канала.
Не забываем про защиту от обратных выбросов при дуговом разряде из-за индуктивности проводов, электрода и прочих паразитных параметров. Ставим в схему диод Шоттки MBR20200CT, который замкнет на себя обратный импульс после закрытия транзистора. На всякий случай добавим еще и TVS-диод 1.5KE150A, который защитит наш транзистор от остаточных выбросов из-за 3D-монтажа (упс, спойлеры).
Чуть ниже мы видим схему затвора. Реализована она на драйвере FOD3180 с гальванической развязкой. Мы же не хотим убить наш микроконтроллер в случае возникновения внештатных ситуаций. Ну, тут всё просто — собираем схему в соответствии с даташитом. Раскачивать MOFSET будем от линии 12 V.
Чуть правее диода мы видим ещё один резистор на 1 Ом, да ещё и на 100 Вт. А вот тут интересный момент. При открытии транзистора через него радостно начинают разряжаться конденсаторы с огромным током. Этот ток непредсказуем и зависит, по сути, от паразитных параметров проводов, электрода и плазменного канала. Так не пойдёт, поставим резистор, чтобы гарантировать верхний предел тока.
Ух, чуть не забыли. В самом низу схемы спрятался вот этот кусочек — схема контроля напряжения на межэлектродном зазоре на базе оптопары PC817.
В ней есть переменный резистор R7, которым можно задавать порог срабатывания схемы. Делается это экспериментально. Напряжение на зазоре во время пробоя обычно находится в пределах 20–25 В, можно отталкиваться от этого. При таком напряжении оптопара должна быть открыта. Если напряжение падает до значения около 0, то это похоже на короткое замыкание, оптопара закрывается, на ножке МК мы видим LOW и выключаем схему. Диод VD2 тут для защиты от обратных выбросов.
Вжух-вжух, провод сюда, провод туда... Простите, но это DIY на коленке, как и обещал. И это работает!
Это самый первый MVP генератора. Разумеется, я это переделал в более безопасный вид.
Статью я пишу уже после завершения первого этапа разработки, поэтому общая схема немного отличается от описанной выше наличием драйвера шагового двигателя, добавились всякие индикаторы и дисплей. Генератор тут как на схеме.
Берём контейнер, наливаем туда водичку из-под крана, кладём в него деталь и цепляем к ней плюсовой провод, минус при этом цепляем к латунной проволоке. Это очень важный момент, полярность определяет, кто будет разрушаться быстрее — электрод или деталь.
Набрасываем код генерации импульсов на частоте 2 кГц, ширина 50 мкс с использованием аппаратного таймера.
#include <Arduino.h>
#define MOSFET_GATE_CTRL (6) // PWM timer
#define MOSFET_GATE_CTRL_PWM_CH (7)
#define MOSFET_GATE_GND (5)
int32_t spark_t1_us = 50;
int32_t spark_t0_us = 450;
void setup() {
// Enable PWM periph
pmc_enable_periph_clk(ID_PWM);
PWMC_ConfigureClocks(1000000UL, 0, VARIANT_MCK);
Serial.begin(115200);
//
// Setup MOSFET gate PWM
int32_t period_ticks = spark_t1_us + spark_t0_us;
int32_t duty_ticks = spark_t1_us;
PWMC_ConfigureChannel(PWM, MOSFET_GATE_CTRL_PWM_CH, PWM_CMR_CPRE_CLKA, 0, 0);
PWMC_SetPeriod(PWM, MOSFET_GATE_CTRL_PWM_CH, period_ticks);
PWMC_SetDutyCycle(PWM, MOSFET_GATE_CTRL_PWM_CH, duty_ticks);
PIO_Configure(g_APinDescription[MOSFET_GATE_CTRL].pPort,
g_APinDescription[MOSFET_GATE_CTRL].ulPinType,
g_APinDescription[MOSFET_GATE_CTRL].ulPin,
g_APinDescription[MOSFET_GATE_CTRL].ulPinConfiguration);
PWMC_EnableChannel(PWM, MOSFET_GATE_CTRL_PWM_CH);
pinMode(MOSFET_GATE_CTRL, OUTPUT);
digitalWrite(MOSFET_GATE_CTRL, LOW);
pinMode(MOSFET_GATE_GND, OUTPUT);
digitalWrite(MOSFET_GATE_GND, LOW);
}
void loop() {
}
Так как у нас DIY, то схему защиты от КЗ, разумеется, оставляем на потом. Ну погреется резистор, ничего страшного. Руки-то чешутся попробовать.
Запускаем! Начнём со схемы с резистором 1 Ом после батареи конденсаторов. Признаюсь — первый раз было страшно.
На видео видно, как активно образуется шлам — это как раз те самые частицы металла, которые выбиваются искрой. Это одна из проблем EDM-станков, и нам с вами придётся её решить. А вот результат:
Отличная лунка получилась, учитывая, сколько времени я держал проволоку там. Давайте рискнём и попробуем работу генератора без резистора.
Я не знаю, каким чудом тут не выбило MOSFET, возможно, длительность импульса не дала току перевалить за его предел. Я не смог это объяснить.
Тут видно, что искра стала более грубой. Обратите внимание, как колбасит проволоку. В колебаниях виноват не только разряд и микровзрыв, но и электромагнитные силы, которые притягивают электрод и деталь друг к другу. Именно поэтому в EDM-станках проволоку натягивают с большим усилием, чтобы минимизировать любое паразитное воздействие. Это целая проблема, о которой мы поговорим в следующей части цикла. Давайте пока насладимся результатами:
Лунка тоже отличная, но, конечно, проделал я её гораздо быстрее за счёт высокого тока. Это не всё — медью тоже можно резать и вот вам пример:
Тут очень хорошо видно, как проволока ходит туда-сюда, и одновременно с этим из зоны реза вылетают всполохи шлама. А вот как выглядит сама деталь после этого.
Ну, это работает — можно дальше с этим работать. К сожалению, после этого я узнал о проекте OpenEDM и немного расстроился. Там уже сделали всё, что я хотел и объяснили максимально доступно. Но я не остановлюсь! Периодически этот стенд подзаряжает меня настроением, разряжая 80 В в мою руку. Ощутимо, повторять не надо.
Схема генератора там интересная, для ограничения тока используют индуктивность. Отличная замена резистору, который греет комнату. Надо будет рассмотреть этот вариант и разобраться, как он работает.
Самое главное достижение проекта в том, что он был собран вот прям на коленке, и он работает! Репозиторий проекта на GitHub. Там пока небольшой бардак, но это временно.
Разумеется, данная статья написана после сборки и тестирования MVP. Простите, я не смог удержаться от спойлеров — ниже на видео первое отрезание куска металла.
На данный момент (23.09.2026) я пишу парсер gcode и модуль управления осями. Плюс надо еще закрыть всю электронику, работа в этом направлении почти закончена
Следующая статья будет о разработке головки и системы натяжения проволоки, это одна из главных проблем этого проекта. Очень много нюансов.
Финансовая помощь на развитие проекта https://pay.cloudtips.ru/p/13d08d43
Полученные средства пойдут на производство печатных плат для проекта
Разберём, как подключиться к Windows VPS и подготовить его к работе. Порядок одинаковый, откуда бы вы ни подключались: из Windows, macOS или Linux. До установки приложений нужно проверить сертификат, заменить временный пароль и ограничить RDP. При ошибке в настройках потребуется другой способ входа: консоль в панели провайдера.
Инструкция рассчитана на Windows Server 2025 Desktop Experience вне домена и клиент Windows 11. Команды выполняются на сервере в Windows PowerShell 5.1 x64 от администратора. В домене часть настроек задаётся групповыми политиками.
Для первого подключения нужны IP-адрес или DNS-имя сервера, порт RDP, имя пользователя и пароль, а также доступ к консоли в панели провайдера. С ними можно открыть сеанс и восстановить доступ при ошибке настройки. Если подключение идёт через шлюз, потребуются и его параметры.
В панели провайдера сверьте выданный IP, регион, число vCPU, объём памяти и диска с заказом. Там же проверьте выбранный образ Windows: для этой инструкции нужна установка с графическим интерфейсом Desktop Experience. Если параметры расходятся, выясните причину до переноса данных.
В инструкции провайдера о том, как подключиться к VPS Windows, найдите имя пользователя и порт. Обычно RDP использует 3389, но образ или сетевые настройки могут предусматривать другой вариант. Временный пароль перенесите в менеджер паролей. В заметке о сервере достаточно ссылки на нужную запись.
Следующий шаг сделайте через аварийную консоль в панели: войдите в Windows и убедитесь, что можете открыть настройки системы. Если срок действия временного пароля истёк и RDP не пускает, смените пароль здесь. Консоль должна давать доступ к управлению Windows, иначе исправить ошибочное правило RDP через неё не получится.
Если в панели есть сетевой экран, ограничьте RDP своим внешним IP уже сейчас. Саму панель защитите многофакторной аутентификацией (MFA): через неё доступны консоль и управление VPS. На скриншотах скрывайте пароли, токены и личные данные. Пример IP ниже взят из диапазона для документации. При настройке правил указывайте свой адрес.
В Windows клиент RDP открывается командой mstsc через Win+R. В нём укажите адрес сервера. Для нестандартного порта используйте запись «адрес:порт». Если нужно разобраться, как подключиться к Windows VPS-серверу с macOS, подойдёт Windows App. В Linux можно использовать Remmina с поддержкой RDP.
Клиент может предупредить о самоподписанном сертификате или несовпадении имени. Прежде чем разрешать подключение, сравните сертификат с тем, который использует сервер. Его отпечаток можно получить через консоль провайдера:
$rdp = Get-CimInstance -Namespace root/cimv2/TerminalServices `
-ClassName Win32_TSGeneralSetting `
-Filter "TerminalName='RDP-tcp'"
$rdp | Select-Object SSLCertificateSHA1Hash,
UserAuthenticationRequired
Значение SSLCertificateSHA1Hash должно совпасть с полем «Отпечаток» в свойствах сертификата на клиенте, пробелы и регистр не важны. Также проверьте срок действия и имя. При необъяснимом расхождении остановитесь и выясните причину через поддержку. Для постоянного доступа по DNS-имени назначьте службе RDP сертификат, которому доверяет клиент и в котором указано это имя.
Если вход недоступен, через консоль проверьте, разрешён ли RDP в sysdm.cpl. После подключения сохраните версию ОС из winver и снимок окна сертификата без секретов, они пригодятся при проверке настроек.
Теперь создайте свою запись с уникальным паролем. New-LocalUser добавит пользователя, а Add-LocalGroupMember включит его в группу администраторов. Обращение по SID находит группу при любом языке Windows:
$pw = Read-Host 'Пароль opsadmin' -AsSecureString
New-LocalUser -Name 'opsadmin' -Password $pw
$admins = Get-LocalGroup -SID 'S-1-5-32-544'
Add-LocalGroupMember -Group $admins.Name `
-Member "$env:COMPUTERNAME\opsadmin"
Проверьте подключение к Windows VPS по RDP с именем ИМЯ_СЕРВЕРА\opsadmin и вход через консоль. После этого смените временный пароль. Исходную запись отключайте, если она не нужна для восстановления. Для задач без повышенных прав создайте обычного пользователя в lusrmgr.msc. Если ему нужен RDP, добавьте его в группу «Пользователи удалённого рабочего стола».
В secpol.msc откройте политику блокировки. Пример: 10 ошибок, блокировка на 15 минут, сброс счётчика через 15 минут. При низком пороге посторонний сможет постоянно блокировать ваш вход.
Создайте отдельного администратора, включите NLA и разрешите RDP только с доверенных адресов, сохранив открытой аварийную консоль. Затем проверьте новый сеанс: действующее подключение может продолжать работать после изменения правил и само по себе не подтверждает доступность входа. Если внешний IP меняется, правило придётся обновлять, поэтому держите под рукой доступ к панели.
Первичная настройка Windows VPS продолжается в sysdm.cpl: на вкладке удалённого доступа включите требование NLA. Этот механизм проверяет учётные данные до создания полного сеанса. Повторите команду проверки сертификата: у свойства UserAuthenticationRequired должно быть значение 1.
Сетевой доступ настраивается в wf.msc. Для активного профиля брандмауэр должен быть включён, а входящие подключения по умолчанию заблокированы. Создайте входящее разрешение для TCP на порт RDP, обычно 3389. В области действия укажите свой внешний IP, например 203.0.113.25. Для UDP задайте такое же ограничение либо отключите его разрешающее правило, если этот транспорт не нужен. Правила должны действовать в активном профиле сети.
Остальные правила тоже нужно просмотреть: старое разрешение «с любых адресов» оставит RDP открытым. Учитывайте IPv6 и правила с диапазоном портов. Общий запрет на порт RDP заблокирует и нужный вход, поскольку явный запрет имеет приоритет. Список действующих правил доступен в разделе «Наблюдение».
Оставив консоль открытой, проверьте новый вход с разрешённого адреса и отказ с другого. Если порт открыт всему интернету, любой может пробовать войти. Смена его номера этого риска не устраняет.
Когда доступ настроен, установите обновления через Windows Update. Перезагрузку удобнее выполнить сейчас, так как после установки приложений она уже может прервать рабочие задания. Перед ней сохраните файлы и убедитесь, что сможете войти через консоль, если RDP не заработает.
После перезапуска откройте новый RDP-сеанс и проверьте, сохранились ли NLA, профиль сети и ограничения доступа. Полный номер сборки из winver и номера установленных обновлений (KB) из журнала Windows Update запишите в заметку о сервере. По ним позже можно будет установить, какие исправления уже были применены и после какого обновления появилась проблема.
Безопасность RDP на VPS зависит и от обновлений самой Windows, поскольку ограничения по IP не исправляют уязвимости службы. При ошибке установки сохраните её код и выясните причину. Затем снова запустите проверку обновлений, чтобы убедиться, что система не ждёт ещё одной установки или перезагрузки.
Для проверки времени используйте w32tm /query /status и Get-TimeZone. Первая команда показывает состояние синхронизации, вторая выводит часовой пояс. Неверное системное время мешает проверке сертификатов и сопоставлению событий. Для журналов разных машин удобно выбрать UTC. Региональный формат дат и чисел настройте с учётом приложений, он может влиять на чтение дат и чисел из CSV.
Первый вход в Windows Server удобен для настройки аудита. В secpol.msc откройте расширенную политику аудита: включите аудит входа в систему и управления учётными записями пользователей, выбрав «Успех» и «Отказ». Затем войдите повторно и найдите событие в журнале Security через eventvwr.msc.
Событие 4624 с типом 10 означает успешный удалённый интерактивный вход. 4625 фиксирует отказ: при NLA встречается тип 3. Он бывает и у других сетевых входов, поэтому нужны также имя пользователя, время, источник и код ошибки. 4740 сообщает о блокировке учётной записи.
Для уведомления в системе мониторинга можно взять начальный порог: 10 отказов за 5 минут для одной пары «IP и пользователь». Успешный вход после такой серии стоит проверить отдельно. Затем порог уточняют по обычной активности сервера, чтобы не получать лишние уведомления.
Брандмауэр и NLA не добавляют второй фактор. MFA можно подключить через RD Gateway, но для этого потребуется отдельно настроить шлюз и службу аутентификации. Клиенты должны входить только через шлюз. Прямое подключение к RDP обходит такую проверку.
1. Заменить временный пароль и разделить рабочую и административную учётные записи.
2. Включить NLA и ограничить доступ к RDP доверенными адресами.
3. Установить обновления, проверить время и включить аудит входов.
Если удалённый рабочий стол VPS реагирует с задержкой, причина может быть как в нагрузке на Windows, так и в соединении. На перерисовку окон влияют задержка сети, потери пакетов и обработка изображения на клиенте. Чтобы оценить сам сервер, нужно посмотреть, что происходит внутри системы.
В resmon видны загрузка CPU, доступная память и процессы с дисковой активностью. Для сравнения запусков в perfmon запишите показатели с шагом в секунду за 2–5 минут одной и той же нагрузки. Подойдут % Processor Time, Available MBytes и Avg. Disk sec/Read либо Avg. Disk sec/Write. Названия счётчиков зависят от языка ОС. Дисковые задержки указаны в секундах, для миллисекунд умножьте их на 1000.
Чтобы оценить скорость обработки данных, запускайте тест скриптом без графического интерфейса. Дождитесь завершения обновлений, отметьте объём данных и фоновые задачи. Сохранённый ряд измерений покажет, была ли задержка постоянной или возникла коротким всплеском.
Сеть проверяйте передачей известного объёма данных до выбранного узла, отдельно фиксируя время и ошибки. Результат зависит от всего маршрута. Если приложение работает быстро, а сеанс тормозит, уменьшите разрешение и визуальные эффекты RDP. Отключите ненужное перенаправление дисков и принтеров, а буфер обмена оставьте только там, где он нужен для работы.
Перед установкой приложений снова проверьте Windows Update. В английском интерфейсе нужная кнопка называется Check for updates. Когда обновления завершены, можно сохранить исходное состояние. Снапшот (снимок) VPS удобен для отката неудачной установки, но его состав и согласованность данных зависят от платформы провайдера. Не считайте любой снимок работающей машины корректной копией базы данных.
Резервная копия должна пережить потерю самого VPS и иметь историю версий. Храните её отдельно от сервера и проверьте восстановление нужных файлов. Снимок на том же хранилище не покрывает его отказ. Убедитесь, что восстановленные файлы открываются и содержат нужные данные.
Проверку аварийного доступа проведите до размещения рабочих данных. Сначала войдите через консоль и найдите своё правило RDP. Других разрешений для этого подключения быть не должно. Затем временно отключите правило и убедитесь, что новый RDP-сеанс не открывается. Через консоль включите его обратно и повторите вход.
На случай потери пароля нужен отдельный порядок действий. Запишите, где хранятся данные резервного администратора, а при его отсутствии уточните процедуру сброса у провайдера. Консоль обходит сетевые ограничения RDP, но для входа в Windows по-прежнему нужен пароль. Ответственный за сервер должен иметь доступ и к панели, и к резервным учётным данным.
Когда понятно, как подключиться к Windows VPS, остаётся проверить вход после перезагрузки и восстановление через консоль. Вы должны входить под своей учётной записью, а с постороннего адреса подключение должно отклоняться. Через консоль вы сможете исправить правило RDP, даже если оно закрыло вход по сети. Если одна из проверок не пройдена, сначала устраните причину, а затем переносите данные.
Результат подготовки сохраните вместе с датой, именем администратора, параметрами VPS и версией образа. Добавьте снимки сертификата и NLA, правила с адресами и профилями, номера обновлений, события проверочного входа и результат восстановления доступа. Если проблема появится после следующего изменения, по этим записям будет проще найти отличия и понять, какую настройку нужно вернуть.
Тюнинг сетевого стека Linux через sysctl помогает, когда передача упирается в регулируемый им лимит. Ниже – ориентиры для TCP на VPS: что проверять в бенчмарке сетевых sysctl Linux и какие параметры дают эффект.
Эффект дают параметры, которые снимают подтверждённое ограничение: например, предел TCP-буфера или очереди новых соединений. Прирост нужно проверить на той же нагрузке вместе с задержками и ошибками. Если скорость ограничивает процессор, приложение или канал провайдера, увеличение сетевых лимитов само по себе эту проблему не решит.
Бенчмарк сетевых sysctl Linux должен воспроизводить проблему: медленную передачу файла или отказы при наплыве клиентов. Исходный прогон показывает скорость, число ошибок и повторных передач TCP, загрузку ядер. Для запросов приложения нужны медиана и p99 – граница времени ответа для 99% запросов.
В VPS с virtio-net пакет проходит через сокет, стек гостя, виртуальный адаптер и сеть хоста. Команда ss -tim показывает состояние TCP и память сокета, nstat – сетевые счётчики, tc -s qdisc – статистику очередей отправки. Sysctl для пропускной способности действует лишь на своём участке: sysctl гостя не меняет настройки хоста.
Настройка TCP-буферов Linux имеет смысл, если их лимит мешает передаче. Ориентир bandwidth-delay product – скорость канала, умноженная на RTT, время пути туда и обратно. При 1 Гбит/с и 50 мс это 6,25 МБ данных в пути, а не готовый размер буфера.
Максимумы tcp_rmem и tcp_wmem нужно сопоставить с ss -tim и настройками приложения. Если автоматическая настройка буферов не достигает предела, его увеличение не поможет.
Огромные буферы и очереди без проверки их заполнения – самый частый случай копирования чужой конфигурации. Больший лимит не ускорит обработку данных приложением. При перегрузке длинная очередь может лишь увеличить ожидание, поэтому полезность изменения определяют по скорости, ошибкам и задержкам при одинаковой нагрузке, а не по самому значению.
Для тюнинга somaxconn и backlog важны оба ограничения: net.core.somaxconn и значение listen() приложения. Они ограничивают очередь установленных соединений, ожидающих accept(). Рост ListenOverflows и ListenDrops в nstat – повод проверить её. Число полуоткрытых соединений ограничивает tcp_max_syn_backlog.
Бенчмарк BBR в Linux требует одинаковых RTT, потерь и скорости канала. Алгоритм соединения виден в ss -ti. Настройки очереди отправки (qdisc) при сравнении должны совпадать. Кроме скорости, важны задержки и доля канала, оставшаяся другим потокам. Смена алгоритма не гарантирует выигрыша.
Netem задаёт задержку и потери на отдельном стенде. Для TCP его размещают на входе принимающего узла. Повторный исходный прогон помогает отличить эффект настройки от колебаний сети. Без устойчивой разницы результат нейтральный, а ухудшение задержек или ошибок – причина отката.
1. Сохранить версию ядра, значения sysctl, нагрузку и исходные метрики.
2. Изменить один параметр и повторить прогоны при тех же условиях.
3. Вернуть прежнее значение, сравнить скорость, ошибки, p99 latency и нужный счётчик.
iperf3 проверяет передачу данных, но не заменяет тест приложения. Провайдер может проверить потери на адаптерах, очереди и загрузку обработки пакетов на хосте. Из гостя эти данные видны не полностью.
Значения нужно читать и менять в network namespace – сетевом окружении нужного процесса. Пробное применение на одном сервере должно дать повторяемое улучшение до записи в /etc/sysctl.d/. Для отката нужно вернуть прежнее значение через sysctl -w и убрать постоянную настройку из файла.
Тюнинг сетевого стека Linux через sysctl стоит ограничить изменениями с подтверждённым эффектом и проверенным откатом.
Измерение лага репликации PostgreSQL под нагрузкой помогает найти этап, где копится WAL. Разберём физическую репликацию PostgreSQL 18.
На асинхронной реплике replay_lag приближённо показывает задержку появления последних изменений. Отсчёт идёт от сохранения WAL на основном сервере до получения подтверждения его применения на реплике. Для проверки конкретной транзакции отслеживают появление её контрольной записи на реплике в новом снимке данных.
Для бенчмарка лага репликации PostgreSQL нужны четыре позиции WAL: sent – отправлено, write – записано в ОС, flush – сохранено на диск, replay – применено. Основной сервер показывает их в pg_stat_replication, получая последние три от реплики. pg_wal_lsn_diff считает разрывы в байтах: текущий LSN–sent, sent–write, write–flush, flush–replay.
На лаг в pg_stat_replication влияют режим репликации и частота отчётов. Поэтому до теста фиксируют версии, число реплик, synchronous_standby_names, synchronous_commit и слоты. Удержание WAL слотами ограничивает max_slot_wal_keep_size. Лимит проверяется при checkpoint.
Опрос обоих серверов пишет LSN и разрывы в CSV с шагом 1 с и метками UTC. Часы узлов синхронизируют. pg_last_xact_replay_timestamp() даёт время commit/abort последней применённой транзакции с основного сервера. При простое её возраст растёт даже у догнавшей реплики, lag может стать NULL.
На тестовом стенде постепенно увеличивают нагрузку записи через pgbench и регулярно снимают позиции WAL с обоих серверов. Разрывы между этапами показывают, где растёт очередь, а метрики сети, CPU и дисков помогают найти причину. Если мощности хватает, нагрузка может вообще не вызвать заметного отставания.
В CSV отмечают фазы pgbench. Для расчёта скорости WAL прирост текущего LSN делят на интервал между замерами. Лаг LSN PostgreSQL выражают в байтах. Чтобы измерить время catch-up, после остановки записи фиксируют конечный LSN и ждут, пока реплика его применит.
За этим разрывом могут стоять сеть, запись WAL или задержка отчёта реплики. Причину ищут по пропускной способности, потерям и работе walreceiver. p99 лага streaming replication считают отдельно по фазам, указав единицы и шаг опроса.
Оба разрыва живут на реплике, но упираются в разное: первый в диск, второй в применение WAL.
1. sent–write проверяют вместе с сетью и приёмником WAL: сам разрыв не доказывает сетевую проблему.
2. write–flush сопоставляют с задержками fsync и очередью диска реплики.
3. Для flush–replay проверяют CPU, I/O и конфликты запросов, учитывая отставание flush.
При synchronous replication synchronous_commit задаёт условие завершения COMMIT: remote_apply требует применения WAL на выбранных синхронных репликах.
Задержка replay WAL под нагрузкой возможна и при стабильном WAL generation rate: конфликт с запросом задерживает применение WAL. Увеличение max_standby_streaming_delay продлевает ожидание. Отмены запросов видны в pg_stat_database_conflicts. hot_standby_feedback уменьшает конфликты очистки ценой накопления старых версий строк на основном сервере.
Порог потери данных задают по RPO, а отставание данных и время catch-up ограничивают отдельно. Сохранённый на диск реплики WAL применяется и после отказа основного сервера. Причину уточняют по network RTT, CPU и I/O обоих узлов.
Измерение лага репликации PostgreSQL под нагрузкой даёт основу для оповещений по этапам: важны размер очереди и скорость её роста. Оповещение по одному порогу lag в секундах такой картины не даёт.