Горячее
Лучшее
Свежее
Подписки
Сообщества
Блоги
Эксперты
Войти
Забыли пароль?
или продолжите с
Создать аккаунт
Я хочу получать рассылки с лучшими постами за неделю
или
Восстановление пароля
Восстановление пароля
Получить код в Telegram
Войти с Яндекс ID Войти через VK ID
Создавая аккаунт, я соглашаюсь с правилами Пикабу и даю согласие на обработку персональных данных.
ПромокодыРаботаКурсыРекламаИгрыПополнение Steam
Пикабу Игры +1000 бесплатных онлайн игр
Добро пожаловать в Кран-ресторан — казуальный симулятор, который превратит вас в настоящего мастера кулинарии! Управляйте краном, ловите нужные ингредиенты и готовьте блюда по рецептам, избегая ошибок, чтобы сохранить рейтинг и получить ценные награды.

Кран-Ресторан

Казуальные, Аркады, Шарики

Играть

Топ прошлой недели

  • AlexKud AlexKud 38 постов
  • SergeyKorsun SergeyKorsun 12 постов
  • SupportHuaport SupportHuaport 5 постов
Посмотреть весь топ

Лучшие посты недели

Рассылка Пикабу: отправляем самые рейтинговые материалы за 7 дней 🔥

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

Спасибо, что подписались!
Пожалуйста, проверьте почту 😊

Помощь Кодекс Пикабу Команда Пикабу Моб. приложение
Правила соцсети О рекомендациях О компании
Промокоды Биг Гик Промокоды Lamoda Промокоды МВидео Промокоды Яндекс Директ Промокоды Отелло Промокоды Aroma Butik Промокоды Яндекс Путешествия Постила Футбол сегодня

Linux + Сервер

С этим тегом используют

Windows IT Программирование Ubuntu IT юмор Компьютер Программист Minecraft Игры Сисадмин Помощь Все
83 поста сначала свежее
23
Diprivan
Diprivan
1 месяц назад
Офисные будни

Продолжение поста «Как я случайно "спас" сервер, ничего не делая»⁠⁠5

Итак, пришло время повторить механизм описаной байки или мифа про перезагрузку сервера с помощью CD-ROM'a. Собиралось из того, что было на коленках.

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

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

Офисный набор "сделай сам":

  1. Потенциальная жертва с непростой судьбой, которая должна периодически крашиться да так, что по сети не будет пинговаться. Комп с Windows 11, расшарен доступ по RDP, ip-адрес: 192.168.1.57. Далее по тексту - просто Жертва

  2. Страж для бесперебойной работы первого компа, тыкающий его в кнопку ресета с помощью DVD-ROM'a. Сорян, но настоящий CD-ROM не отыскался - их время прошло... Здесь стоит Ubuntu, выполняется скрипт, который управляет системой надзора и тыкания в ресет. Ip - 192.168.1.56, компы находятся в локалке.

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

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

Продолжение поста «Как я случайно "спас" сервер, ничего не делая» Текст, Сервер, Смекалка, Ответ на пост, Windows, Reset, Эксперимент, IT, Офисные будни, Linux, Видео, Вертикальное видео, Длиннопост, Волна постов

Базовое положение компов - DVD не достает до кнопки ресета сантиметров на десять

Продолжение поста «Как я случайно "спас" сервер, ничего не делая» Текст, Сервер, Смекалка, Ответ на пост, Windows, Reset, Эксперимент, IT, Офисные будни, Linux, Видео, Вертикальное видео, Длиннопост, Волна постов

Фундамент для линукса

Продолжение поста «Как я случайно "спас" сервер, ничего не делая» Текст, Сервер, Смекалка, Ответ на пост, Windows, Reset, Эксперимент, IT, Офисные будни, Linux, Видео, Вертикальное видео, Длиннопост, Волна постов

Шулыга для ресета (из соплей и палок)

Продолжение поста «Как я случайно "спас" сервер, ничего не делая» Текст, Сервер, Смекалка, Ответ на пост, Windows, Reset, Эксперимент, IT, Офисные будни, Linux, Видео, Вертикальное видео, Длиннопост, Волна постов

Стенд в сборе и готов к работе

Сценарий следующий: на линуксе запущен скрипт, который каждые 5 секунд пингует Жертву. Если три попытки пинга подряд уходят без ответа, выдвигается DVD-ROM, который нажимает на ресет Жертвы. Далее идет ожидание в течении минуты (даем время на перезагрузку) и все повторяется заново.

Для симуляции "выпадения из сети" Жертвы на ней через RDP выполняется батничек, содержащий такую строчку:

netsh interface set interface "Ethernet 3" admin=disable

При загрузке винды в планировщике задач выполняется соответственно

netsh interface set interface "Ethernet 3" admin=enable

На Убунте лежит скрипт

#!/bin/bash

IP_TO_PING="192.168.1.57" # IP-адрес для проверки

PING_COUNT=3 # Максимальное количество неудачных попыток

DEVICE="/dev/sr0" # DVD-ROM

CHECK_INTERVAL=5 # Пауза между попытками в секундах

# Проверки связи с Жертвой

is_reachable() {

ping -c 1 "$IP_TO_PING" &>/dev/null

return $?

}

echo "Начинаю мониторинг доступности $IP_TO_PING..."

while true; do

failure_count=0

while ! is_reachable; do

((failure_count++))

echo "$(date): Нет ответа от $IP_TO_PING. Неудач: $failure_count"

if [ "$failure_count" -ge "$PING_COUNT" ]; then

echo "$(date): Ахтунг! Делаем Hard Reset с помощью DVD-ROM'a!!!"

# Выдвигаем DVD-привод

eject "$DEVICE"

# Ждём 1 секунду

sleep 1

# Задвигаем DVD-привод обратно

eject -t "$DEVICE"

# Пауза 1 минута чтобы подождать загрузки Жертвы

echo "$(date): Ожидание 1 минуты перед новой проверкой..."

sleep 60

echo "$(date): Продолжаем наблюдение"

# Сброс счётчика попыток

failure_count=0

break

fi

sleep "$CHECK_INTERVAL"

done

if is_reachable; then

echo "$(date): узел $IP_TO_PING доступен."

fi

sleep "$CHECK_INTERVAL"

done

А вот и результат работы стендовой модели ))

Показать полностью 4 1
[моё] Текст Сервер Смекалка Ответ на пост Windows Reset Эксперимент IT Офисные будни Linux Видео Вертикальное видео Длиннопост Волна постов
2
12
0sennijLis
0sennijLis
2 месяца назад
Лига Сисадминов

Повышение производительности с использованием LVM Striping⁠⁠

В области управления хранилищами приоритетом является достижение оптимальной производительности дисков. Стремление к более быстрому доступу к данным, уменьшению задержек и повышению количества операций ввода-вывода (I/O) и пропускной способности привело к использованию передовых техник. Одной из таких является LVM Striping (полосование), мощная функция менеджера логических томов (LVM), которая существенно повышает производительность дисковых томов.

Линейный (Linear) LVM против LVM Striping:

1.1 — Линейный LVM:

Линейная конфигурация, являющаяся стандартным подходом для LVM, подразумевает последовательное добавление нескольких физических томов (дисков) в группу томов (Volume Group). Данные последовательно записываются на эти диски: сначала заполняется один диск, затем следующий, и так далее.

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

Хотя линейный LVM прост и удобен для расширения хранилищ, он не полностью раскрывает потенциал параллельной обработки и увеличения общей пропускной способности.

1.2 — LVM Striping (Полосование):

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

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

Процесс создания полос:

  1. Создание полос:

  • Данные разделяются на сегменты («полосы»).

  • Каждая полоса записывается на отдельный диск в составе логического тома.

2. Параллельная запись полос:

  • Полосы записываются параллельно на несколько физических томов (дисков).

3. Равномерное распределение:

  • Полосы равномерно распределены по дискам, предотвращая появление узкого места (bottleneck).

4. Увеличение IOPS и пропускной способности:

  • Благодаря параллельной записи полос LVM Striping существенно увеличивает общую производительность и пропускную способность логического тома.

1.3 — Пример использования:

Рассмотрим пример с тремя дисками, каждый из которых обеспечивает пропускную способность 125 МБ/с:

  • При использовании LVM Striping суммарная производительность составит 375 МБ/с.

  • В случае же с линейным LVM, производительность останется равной 125 МБ/с, вне зависимости от количества добавленных дисков.

Настройка Linear LVM и Striping LVM:

В этом разделе мы создадим две группы томов (Volume Groups, VG): одну линейную, вторую — с полосованием, каждая с использованием трёх дисков. Затем создадим логические тома (Logical Volumes, LV), отформатируем и смонтируем их.

2.1 — Исходные данные:

  • Сервер: AWS EC2 instance типа m4.10xlarge

  • EBS-диски: 6 штук по 20ГБ (тип GP3, 3000 IOPS, 125MiB/s пропускная способность каждый)

  • ОС: Amazon Linux 2

Просмотр подключенных дисков:

# lsblk

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

2.2 — Создание групп томов (VG):

Создадим две группы томов:

# vgcreate vg_linear /dev/sdb /dev/sdc /dev/sdd
# vgcreate vg_striping /dev/sde /dev/sdf /dev/sdg

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

# vgs

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

2.3 — Создание линейного логического тома (Linear LVM):

# lvcreate -l 100%FREE -n lv_linear vg_linear

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

Параметры:

  • -l 100%FREE — задействовать весь доступный объем VG.

  • -n lv_linear — имя логического тома.

  • vg_linear — целевая группа томов.

2.4 — Создание логического тома с полосованием (Striping LVM):

# lvcreate -l 100%FREE -i 3 -I 64k -n lv_striping vg_striping

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

Параметры:

  • -l 100%FREE — задействовать весь объем VG.

  • -i 3 — количество полос (равно числу дисков).

  • -I 64k — размер полосы.

  • -n lv_striping — имя логического тома.

  • vg_striping — целевая группа томов.

2.5 — Проверка созданных LV:

Проверка линейного LV:

# lvdisplay -m /dev/vg_linear/lv_linear

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

Проверка LV с полосованием:

# lvdisplay -m /dev/vg_striping/lv_striping

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

Здесь мы можем увидеть различные детали наших настроек.

2.6 — Форматирование и монтирование LV:

# mkfs.xfs /dev/vg_linear/lv_linear

# mkfs.xfs /dev/vg_striping/lv_striping

# mkdir /mnt/linear

# mkdir /mnt/striping

# mount /dev/vg_linear/lv_linear /mnt/linear/

# mount /dev/vg_striping/lv_striping /mnt/striping/

# df -h

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

LV успешно смонтированы.

3 — Тестирование производительности LV (benchmark):

Для тестирования используем инструмент fio:

# yum install fio -y

3.1 — Тестирование линейного LV:

Чтобы сравнить LV, мы будем использовать файл конфигурации FIO, который поможет нам генерировать трафик на 400м:

# cat fio_config-1.fio

[global]

ioengine=libaio

runtime=60

time_based

direct=1

rw=write

size=10G

bs=512K

rate=400M

numjobs=16

[job1]

filename=/mnt/linear/testfile

Запуск тестирования с созданным конфигом:

# fio fio_config-1.fio

Одновременно с этим в отдельном терминале запустим iostat, чтобы контролировать использование дисков:

# iostat -xdmt 2

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

Видим, что используется только один диск xvdb со скоростью 125 МБ/с.

Ту же картину нам демонстрирует и fio:

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

Операции записи были выполнены исключительно на одном диске.

3.2 — Тестирование LV с полосованием:

Теперь снова запустим fio, но изменим параметр filename в файле конфигурации:

filename=/mnt/striping/testfile

Запускаем iostat:

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

Все три диска работают параллельно, суммарная скорость равна 375 МБ/с (125 x 3).

Аналогичную картинку нам демонстрирует и fio:

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

Вывод:

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

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

Показать полностью 14
Системное администрирование Linux Shell IT Исследования Сервер Длиннопост
7
19
0sennijLis
0sennijLis
2 месяца назад
Лига Сисадминов

Влияние максимального размера I/O-запросов на производительность систем Linux⁠⁠

В области оптимизации производительности Linux важнейшим фактором является производительность дискового ввода-вывода (I/O), которая существенно влияет на общую эффективность системы. Одним из ключевых параметров, влияющих на производительность дискового ввода-вывода, является максимальный размер I/O-запроса, определяемый параметром max_sectors_kb. Понимание и настройка этого параметра могут привести к значительному улучшению производительности системы. В этой статье мы рассмотрим понятие максимального размера I/O, его важность в системах Linux, а также его влияние на производительность в целом.

Понимание максимального размера I/O (max_sectors_kb)

Параметр max_sectors_kb определяет максимальный размер отдельного I/O-запроса в килобайтах. Он устанавливает объём данных, который может быть передан в рамках одного I/O-запроса. Значение параметра max_sectors_kb ограничено логическим размером блока файловой системы и аппаратными возможностями устройства хранения данных. Оно не может быть меньше логического размера блока, делённого на 1024, и не должно превышать значение параметра max_hw_sectors_kb, который является параметром только для чтения и показывает максимально поддерживаемый аппаратурой размер запроса.

Минимальное значение = max(1, logical_block_size/1024) 

Максимальное значение = max_hw_sectors_kb

Примечание: Максимальный размер I/O в Linux преимущественно применим к ядрам версии 4.x и выше. Рекомендуется проверить это в конкретном ядре вашей системы. Хотя впрочем очевидно - если у вас не какой-нибудь embedded, то ядро скорее всего будет выше 5.x

Важность в системах Linux

В Linux параметр максимального размера I/O существенно влияет на эффективность чтения и записи данных с устройств хранения. Он оказывает влияние на следующие аспекты производительности:

1. Баланс между пропускной способностью и задержками:

  • Пропускная способность (Throughput): Крупные размеры I/O-запросов увеличивают общую пропускную способность ввода-вывода за счёт обработки больших блоков данных за одну операцию. Это снижает накладные расходы на обработку множества мелких запросов, особенно эффективно при работе с последовательными потоками данных (видеостриминг, резервные копии баз данных).

  • Задержки (Latency): В то время как большие размеры I/O-запросов могут повысить пропускную способность для больших наборов наборов, они также могут увеличить задержку отдельных операций. Это происходит потому, что более крупные запросы требуют больше времени для завершения. Поэтому необходим баланс между улучшением производительности и допустимым уровнем задержек, особенно в чувствительных к задержкам интерактивных или real-time приложениях. В таких случаях предпочтительнее меньшие размеры запросов.

2. Использование CPU:

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

3. Использование памяти:

  • Максимальный размер I/O влияет на объём выделяемой памяти под буферы ввода-вывода, что также отражается на общем использовании памяти системой.

Факторы, влияющие на максимальный размер I/O

Есть несколько факторов, которые влияют на максимальный размер запросов в Linux:

  • Аппаратные ограничения: Значение max_sectors_kb не должно превышать аппаратные возможности накопителя (значение параметра max_hw_sectors_kb). Превышение аппаратного лимита может привести к ошибкам или снижению производительности.

  • Драйверы устройств: Драйверы контроллеров хранения и накопителей могут задавать свои лимиты на размер запросов.

  • Ограничения файловых систем: У разных файловых систем разные лимиты на размер запроса ввода-вывода.

  • Параметры ядра Linux: Настройки блочных устройств ядра влияют на размер запроса.

Бенчмаркинг и мониторинг

Для определения оптимального размера I/O-запросов необходимо проводить тестирование (бенчмарки) и мониторить показатели производительности (например, с помощью утилиты iostat).

Рекомендуется учитывать:

  • Red Hat советует, чтобы значение max_sectors_kb было кратно оптимальному размеру I/O и внутреннему размеру блока стирания устройства. Если таких данных нет, рекомендуется выставить значение, совпадающее с логическим размером блока устройства.

  • Характеристики рабочей нагрузки: разные приложения выигрывают от разных размеров I/O.

  • Особенности накопителя: HDD и SSD имеют разные оптимальные диапазоны размеров I/O.

  • Ресурсы системы: доступная память и мощность CPU влияют на выбор оптимального размера I/O.

Практические аспекты настройки

Для настройки max_sectors_kb используется команда:

/sys/block/{device}/queue/max_sectors_kb

Например:

echo 256 | sudo tee /sys/block/sda/queue/max_sectors_kb

Данная команда устанавливает максимальный размер запроса в 256 КБ для диска /dev/sda. Перед изменениями желательно протестировать настройки на тестовой системе во избежание негативного влияния на производительность или стабильность системы.

Изменения параметра действуют только до перезагрузки системы. Чтобы изменения сохранялись, добавьте команду в rc.local или настройте сервис для применения параметров при загрузке.

Практическое исследование

Рассмотрим практический сценарий. Создадим лабораторную среду на Linux-сервере и проверим производительность диска. Нагрузку (IOPS) будем генерировать с помощью инструмента fio, а мониторинг производительности проводить с помощью утилиты iostat. Наша задача — оценить влияние параметра max_sectors_kb на производительность системы.

Среда для тестирования:

  • Тип EC2-инстанса: c5.12xlarge

  • EBS-том:

  • тип: GP3

  • размер: 20 GiB

  • IOPS: 3000

  • пропускная способность: 750 MB/s

  • Операционная система: Amazon Linux 2

Проверка дисков и установка fio

Для начала проверим доступные диски:

Влияние максимального размера I/O-запросов на производительность систем Linux Системное администрирование, Компьютерное железо, Linux, Исследования, Производительность, Сервер, Длиннопост

Мы будем создавать нагрузку на диск nvme1n1 при помощи утилиты fio и параллельно мониторить производительность диска, в частности показатель IOPS. Если fio не установлен, используйте команды ниже:

Для Amazon Linux:

sudo yum install -y fio

Для Ubuntu:

sudo apt-get install -y fio

Запуск теста

Откройте два терминала одновременно:

Терминал 1: Генерируем нагрузку:

sudo fio --filename=/dev/nvme1n1 --rw=read --bs=256K --ioengine=libaio --direct=1 --name=volume-initialize

Терминал 2: Мониторим диск:

iostat 1 -d /dev/nvme1n1

Обратите внимание, что в команде fio мы задали размер запроса 256 KiB.

Влияние максимального размера I/O-запросов на производительность систем Linux Системное администрирование, Компьютерное железо, Linux, Исследования, Производительность, Сервер, Длиннопост
Влияние максимального размера I/O-запросов на производительность систем Linux Системное администрирование, Компьютерное железо, Linux, Исследования, Производительность, Сервер, Длиннопост

Наблюдения

На первом скриншоте видно, что утилита fio генерирует 1082 IOPS, однако утилита iostat показывает примерно 2164 IOPS (то есть в два раза больше).

Причина различий

Чтобы выяснить причину этого несоответствия, проверим значение параметра max_sectors_kb:

cat /sys/block/nvme1n1/queue/max_sectors_kb

Влияние максимального размера I/O-запросов на производительность систем Linux Системное администрирование, Компьютерное железо, Linux, Исследования, Производительность, Сервер, Длиннопост

Объяснение:

Инструмент fio создавал IOPS с размером 256 KiB, а max_sectors_kb был установлен на значение 128 KiB. В результате ядро Linux разбивало каждый запрос на два меньших запроса по 128 KiB каждый (256 KiB = 128 KiB × 2). Именно поэтому количество операций, регистрируемых iostat, было в два раза больше, чем указывал fio (1082 × 2 = 2164).

Важно: Увеличение числа запросов из-за неправильно настроенного max_sectors_kb может негативно повлиять на производительность сервера и привести к троттлингу производительности диска (например, EBS-тома), если число операций превышает базовый уровень IOPS.

Проверка максимального аппаратного лимита max_hw_sectors_kb

Проверим максимальное значение I/O, которое поддерживает наш сервер:

cat /sys/block/nvme1n1/queue/max_hw_sectors_kb

Влияние максимального размера I/O-запросов на производительность систем Linux Системное администрирование, Компьютерное железо, Linux, Исследования, Производительность, Сервер, Длиннопост

Результат: наш сервер поддерживает максимальный размер I/O-запроса в 256 KiB.

Попытка увеличения max_sectors_kb

Попробуем увеличить значение до 512 KiB:

echo 512 | sudo tee /sys/block/nvme1n1/queue/max_sectors_kb

Влияние максимального размера I/O-запросов на производительность систем Linux Системное администрирование, Компьютерное железо, Linux, Исследования, Производительность, Сервер, Длиннопост

Результат: Мы получили ошибку «Invalid argument» («Недопустимый аргумент»), так как указали значение, превышающее аппаратный лимит max_hw_sectors_kb.

Теперь установим допустимое значение 256 KiB:

echo 256 | sudo tee /sys/block/nvme1n1/queue/max_sectors_kb

Влияние максимального размера I/O-запросов на производительность систем Linux Системное администрирование, Компьютерное железо, Linux, Исследования, Производительность, Сервер, Длиннопост

Результат: Значение успешно изменено на 256 KiB.

Повторный запуск теста fio

Повторим тест командой:

sudo fio --filename=/dev/nvme1n1 --rw=read --bs=256K --ioengine=libaio --direct=1 --name=volume-initialize

Влияние максимального размера I/O-запросов на производительность систем Linux Системное администрирование, Компьютерное железо, Linux, Исследования, Производительность, Сервер, Длиннопост
Влияние максимального размера I/O-запросов на производительность систем Linux Системное администрирование, Компьютерное железо, Linux, Исследования, Производительность, Сервер, Длиннопост

Результат: После изменения параметра max_sectors_kb количество операций IOPS, отображаемое fio и iostat, совпало.

Заключение:

Максимальный размер I/O-запроса (max_sectors_kb) является мощным инструментом для тонкой настройки производительности дисковой подсистемы в Linux. Правильно подобранное значение позволяет оптимизировать производительность ввода-вывода и снизить нагрузку на CPU, однако следует учитывать возможное увеличение задержек и аппаратные ограничения. Любые изменения параметров производительности следует предварительно тестировать и внимательно анализировать перед внедрением в продуктивную среду. Это гарантирует стабильность работы системы и её оптимальную производительность в различных сценариях.

Показать полностью 9
Системное администрирование Компьютерное железо Linux Исследования Производительность Сервер Длиннопост
1
11
user9843214
user9843214
7 месяцев назад

Установка Proxmox VE 8 на сервер⁠⁠

Proxmox VE (Виртуальная Среда) - это популярная открытая платформа виртуализации.

Установка Proxmox VE 8 на сервер Установка, Сервер, Программа, Linux, Информационная безопасность, Тестирование, Яндекс Дзен (ссылка), Длиннопост

Proxmox VE (Виртуальная Среда) - это популярная открытая платформа виртуализации, которая предоставляет мощное и гибкое решение для создания и управления виртуальными машинами. В этой статье мы установим Proxmox VE 8 на сервер.

Требования к оборудованию

Перед тем как начать установку, убедитесь, что ваш сервер соответствует минимальным требованиям к оборудованию для Proxmox VE 8:

64-разрядный процессор (Intel или AMD)

Не менее 2 ГБ ОЗУ (4 ГБ или более рекомендуется)

1 ГБ свободного пространства на диске для установки

Поддерживаемая сетевая карта

Шаг 1: Скачайте ISO образ

Скачайте файл ISO Proxmox VE 8 с официального сайта: https://www.proxmox.com/downloads

Шаг 2: Создайте загрузочный USB-накопитель

Создайте загрузочный USB-накопитель с помощью инструмента, такого как Rufus (для Windows) или Etcher (для Windows, macOS или Linux). Вставьте USB-накопитель в ваш сервер.

Шаг 3: Загрузитесь с USB-накопителя

Перезапустите ваш сервер и войдите в настройки BIOS (обычно нажав F2, F12 или Del). Установите USB-накопитель как первое загрузочное устройство. Сохраните изменения и выйдите из настроек BIOS. Ваш сервер должен теперь загружаться с USB-накопителя.

Установка Proxmox VE 8 на сервер Установка, Сервер, Программа, Linux, Информационная безопасность, Тестирование, Яндекс Дзен (ссылка), Длиннопост

Шаг 4: Начало установки

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

Шаг 5: Разбиение диска

Proxmox VE 8 использует файловую систему на основе ZFS. Вы можете выбрать использовать весь диск или создать пользовательскую разметку разделов. В этом примере мы будем использовать весь диск.

Шаг 6: Настройка сети

Настройте сеть, включая IP-адрес, маску подсети, шлюз и серверы DNS.

Установка Proxmox VE 8 на сервер Установка, Сервер, Программа, Linux, Информационная безопасность, Тестирование, Яндекс Дзен (ссылка), Длиннопост

Шаг 7: Установите пароль root

Установите сложный пароль для пользователя root.

Шаг 8: Завершите установку

Процесс установки займет несколько минут. После завершения удалите USB-накопитель и перезапустите ваш сервер.

Шаг 9: Начальная настройка

После загрузки сервера откройте веб-браузер и перейдите по адресу https://your-server-ip:8006 (замените your-server-ip на IP-адрес вашего сервера). Войдите с помощью пользователя root и пароля, которые вы установили ранее.

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

Установка Proxmox VE 8 на сервер Установка, Сервер, Программа, Linux, Информационная безопасность, Тестирование, Яндекс Дзен (ссылка), Длиннопост

Шаг 10: Оптимизация Proxmox VE после установки

Этот скрипт предоставляет опции для управления репозиториями Proxmox VE, включая отключение корпоративного репозитория, добавление или исправление источников PVE, включение репозитория без подписки, добавление тестового репозитория, отключение проверки подписки, обновление Proxmox VE и перезагрузку системы.

Выполните приведенную ниже команду в оболочке Proxmox VE.

bash -c "$(wget -qLO - https://github.com/tteck/Proxmox/raw/main/misc/post-pve-inst...)"

Установка Proxmox VE 8 на сервер Установка, Сервер, Программа, Linux, Информационная безопасность, Тестирование, Яндекс Дзен (ссылка), Длиннопост
Установка Proxmox VE 8 на сервер Установка, Сервер, Программа, Linux, Информационная безопасность, Тестирование, Яндекс Дзен (ссылка), Длиннопост

Рекомендуется отвечать “да” (y) на все варианты, представленные в процессе.

Теперь ваш Proxmox не будет показывать форточку об отсутствии подписки. Обновления будет получать с бесплатных серверов. Удачи!

Мой каналDzen https://dzen.ru/100melochey

Показать полностью 6
[моё] Установка Сервер Программа Linux Информационная безопасность Тестирование Яндекс Дзен (ссылка) Длиннопост
16
17
Kravenrus
Kravenrus
8 месяцев назад

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

UPD:

Диапазоны серверов, пойманных для войсов, от сторонних провайдеров

Страна: США
IP диапазон: 34.0.0.0 - 34.3.2.255
CIDR: 34.0.0.0/15, 34.3.2.0/24, 34.2.0.0/16, 34.3.0.0/23
Название провайдера: Google LLC
ASN: 15169

Страна: США
IP диапазон: 35.192.0.0 - 35.207.255.255
CIDR: 35.192.0.0/12
Название провайдера: Google LLC
ASN: 15169

Страна: США
IP диапазон: 35.208.0.0 - 35.247.255.255
CIDR: 35.240.0.0/13, 35.224.0.0/12, 35.208.0.0/12
Название провайдера: Google LLC
ASN: 15169

Страна: Нидерланды
IP диапазон: 5.200.14.128 - 5.200.14.255
CIDR: 5.200.14.128/25
Название провайдера: i3Dnet
ASN: 49544

Страна: Сингапур
IP диапазон: 34.64.0.0 - 34.64.255.255
CIDR: 34.64.0.0/16
Название провайдера: Google Asia Pacific Pte. Ltd.
ASN: 139070

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

Домены:

dis.gd
discord.co
discord.com
discord.design
discord.dev
discord.gg
discord.gift
discord.gifts
discord.media
discord.new
discord.store
discord.tools
discordapp.com
discordapp.net
discordmerch.com
discordpartygames.com
discord-activities.com
discordactivities.com
discordsays.com
discordstatus.com
discordcdn.com

Порты голосовых каналов (вероятно диапазон не точный):

50000 - 65535

Пока только для одного ASN (49544), @killerofsoul говорил, что Discord также использует еще один номер автономной системы.. поймаю — дополню

Страна: Нидерланды

IP диапазон: 66.22.196.0 - 66.22.199.255

CIDR: 66.22.196.0/22

Название провайдера: discord-nlrtm1-1

Страна: Бразилия

IP диапазон: 66.22.200.0 - 66.22.203.255

CIDR: 66.22.200.0/22

Название провайдера: discord-brcoa1-1

Страна: США

IP диапазон: 66.22.204.0 - 66.22.207.255

CIDR: 66.22.204.0/22

Название провайдера: discord-uschi1-1

Страна: Япония

IP диапазон: 66.22.208.0 - 66.22.211.255

CIDR: 66.22.208.0/22

Название провайдера: discord-jptyo1-1

Страна: США

IP диапазон: 66.22.212.0 - 66.22.215.255

CIDR: 66.22.212.0/22

Название провайдера: discord-usewr1-1

Страна: Россия

IP диапазон: 66.22.216.0 - 66.22.217.255

CIDR: 66.22.216.0/23

Название провайдера: discord-rumow2-1

Страна: Гонконг (Китай)

IP диапазон: 66.22.218.0 - 66.22.219.255

CIDR: 66.22.218.0/23

Название провайдера: discord-hkhkg1-1

Страна: Сингапур

IP диапазон: 66.22.220.0 - 66.22.221.255

CIDR: 66.22.220.0/23

Название провайдера: discord-sgsin1-1

Страна: США

IP диапазон: 66.22.222.0 - 66.22.223.255

CIDR: 66.22.222.0/23

Название провайдера: discord-usatl1-1

Страна: США

IP диапазон: 66.22.224.0 - 66.22.225.255

CIDR: 66.22.224.0/23

Название провайдера: discord-usdal1-1

Страна: США

IP диапазон: 66.22.226.0 - 66.22.227.255

CIDR: 66.22.226.0/23

Название провайдера: discord-uslax1-1

Страна: Корея

IP диапазон: 66.22.228.0 - 66.22.229.255

CIDR: 66.22.228.0/23

Название провайдера: discord-asia-northeast3-1

Страна: США

IP диапазон: 66.22.230.0 - 66.22.230.255

CIDR: 66.22.230.0/24

Название провайдера: discord-ussea1-1

Страна: США

IP диапазон: 66.22.231.0 - 66.22.231.255

CIDR: 66.22.231.0/24

Название провайдера: discord-usqas1-1

Страна: Австралия

IP диапазон: 66.22.232.0 - 66.22.232.255

CIDR: 66.22.232.0/24

Название провайдера: discord-ausyd1-1

Страна: Чили

IP диапазон: 66.22.233.0 - 66.22.233.255

CIDR: 66.22.233.0/24

Название провайдера: discord-clscl1-1

Страна: США

IP диапазон: 66.22.234.0 - 66.22.234.255

CIDR: 66.22.234.0/24

Название провайдера: discord-usscz1-1

Страна: Франция

IP диапазон: 66.22.235.0 - 66.22.235.255

CIDR: 66.22.235.0/24

Название провайдера: discord-frpar1-1

Страна: Аргентина

IP диапазон: 66.22.236.0 - 66.22.236.255

CIDR: 66.22.236.0/24

Название провайдера: discord-arbue1-1

Страна: Швеция

IP диапазон: 66.22.237.0 - 66.22.237.255

CIDR: 66.22.237.0/24

Название провайдера: discord-sesto2-1

Страна: Италия

IP диапазон: 66.22.238.0 - 66.22.238.255

CIDR: 66.22.238.0/24

Название провайдера: discord-itmil1-1

Страна: Индия

IP диапазон: 66.22.239.0 - 66.22.239.255

CIDR: 66.22.239.0/24

Название провайдера: discord-inbom1-1

Страна: ЮАР

IP диапазон: 66.22.240.0 - 66.22.240.255

CIDR: 66.22.240.0/24

Название провайдера: discord-zajnb1-1

Страна: Испания

IP диапазон: 66.22.241.0 - 66.22.241.255

CIDR: 66.22.241.0/24

Название провайдера: discord-esmad1-1

Страна: Арабские Эмираты

IP диапазон: 66.22.242.0 - 66.22.242.255

CIDR: 66.22.242.0/24

Название провайдера: discord-aedxb1-1

Страна: Германия

IP диапазон: 66.22.243.0 - 66.22.243.255

CIDR: 66.22.243.0/24

Название провайдера: discord-defra1-1

Страна: Румыния

IP диапазон: 66.22.244.0 - 66.22.244.255

CIDR: 66.22.244.0/24

Название провайдера: discord-robuh1-1

Страна: США

IP диапазон: 66.22.245.0 - 66.22.245.255

CIDR: 66.22.245.0/24

Название провайдера: discord-usdal1-2

Страна: Бразилия

IP диапазон: 66.22.246.0 - 66.22.246.255

CIDR: 66.22.246.0/24

Название провайдера: discord-brcoa1-2

Страна: Австралия

IP диапазон: 66.22.247.0 - 66.22.247.255

CIDR: 66.22.247.0/24

Название провайдера: discord-ausyd1-2

Страна: Япония

IP диапазон: 66.22.248.0 - 66.22.248.255

CIDR: 66.22.248.0/24

Название провайдера: discord-jptyo1-2

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

Страна: США

IP диапазон: 66.22.192.0 - 66.22.255.255

CIDR: 66.22.192.0/18

Название провайдера: US-DISCORD1-20000919

Стоит отметить, что для голосовых каналов также фигурируют и сервера во владении Google Inc, а также Cloudflare, Inc., об этом ниже..

Зачем приложения используют чужие IP-адреса для голосовых каналов?

Вопрос о том, почему некоторые приложения могут использовать сторонние IP-адреса для голосовых или других каналов, можно объяснить несколькими причинами:

  1. Использование сторонних сервисов для голосовой связи: Многие приложения (особенно игры или платформы для коммуникаций) не создают свои собственные голосовые решения, а используют сторонние сервисы или технологии (например, Twilio, Agora, Discord). Эти сервисы предоставляют API для создания и управления голосовыми каналами. В этом случае голосовые данные могут передаваться через их серверы, а пользователи взаимодействуют с внешними IP-адресами, принадлежащими этим сервисам.

  2. CDN для передачи данных: Для ускорения передачи голосовых данных и минимизации задержек могут использоваться распределенные серверы или сторонние сети (CDN). Это позволяет обеспечивать низкую латентность для голосовых сообщений, так как данные направляются через ближайшие к пользователю сервера.

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

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

Много интересного доступно здесь.

Диапазоны адресов, арендованные Discord'ом, что используются серверами для поддержки работы голосовых каналов Windows, Linux, Сети, Discord, Ip-телефония, Чат, Сервер, IP, Текст, Длиннопост

Информация с BGPView

Диапазоны адресов, арендованные Discord'ом, что используются серверами для поддержки работы голосовых каналов Windows, Linux, Сети, Discord, Ip-телефония, Чат, Сервер, IP, Текст, Длиннопост
Диапазоны адресов, арендованные Discord'ом, что используются серверами для поддержки работы голосовых каналов Windows, Linux, Сети, Discord, Ip-телефония, Чат, Сервер, IP, Текст, Длиннопост
Показать полностью 3
[моё] Windows Linux Сети Discord Ip-телефония Чат Сервер IP Текст Длиннопост
7
134
aikrr
aikrr
9 месяцев назад
Лига Сисадминов

Мой сервер бэкапов⁠⁠

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

В качестве железа выбрал старенький HP Microserver Gen7. Продавать большого смысла не видел, куда-то в продакшн ставить тоже — он почти на любой чих под 100% загружается, если какие-то сервисы вешать или просто в несколько потоков файлы по гигабитной сети копировать. А вот с простым хранением файлов он ещё справится.

Мой сервер бэкапов Nas, Резервное копирование, Linux, Сервер, Длиннопост

Коробочка сверху по производительности - как два десятка gen7

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

Если же закрыть глаза на процессор, то в остальном из микросервера получается вполне достойный NAS — четыре-пять слотов под 3.5″ диски, плюс можно внутри корпуса кинуть SSD, благо имеется пять SATA-портов и внешний e-SATA, который я завёл внутрь.

Мой сервер бэкапов Nas, Резервное копирование, Linux, Сервер, Длиннопост

SSD просто валяется сзади, но это не страшно, ничего ему от этого не будет

Первый раз я более-менее серьёзно пытался подойти к задаче в начале года, поставил было на него TrueNAS Scale. Но по дискам у меня тогда была сборная солянка от 3 до 6 терабайт, да ещё самые большие диски были SMR. А TrueNAS — это zfs. А zfs — это враг черепичных дисков (ну или черепичные диски — враг SMR). Плюс, даже если считать, что диски все CMR, собирать массивы на zfs из разных дисков нерационально. Либо большие потери, либо придётся кроить и попадать на потерю ёмкости или головную боль при возможной замене дисков.

Потому TrueNAS снёс, сервер отложил. В начале лета снова вернулся, решив поставить на него Open Media Vault 7.

Мой сервер бэкапов Nas, Резервное копирование, Linux, Сервер, Длиннопост

Объединил диски при помощи mergerfs, а избыточность захотел получить при помощи snapraid. Некоторое время поигрался со всем этим и понял, что сегодняшний OMV мне нравится ещё меньше, чем TrueNAS. От системы плагинов уже почти ушли, а к нормальной поддержке докера всё ещё не пришли. Да и веб-интерфейс его мне никогда особо не нравился. Хотя чего у OMV не отнять — это того, что он на любой табуретке запускается, к ресурсам совершенно не требователен. Но, в остальном, у меня создаётся ощущение, что разработчики сами пока не знают, что хотят получить в итоге. Потому для меня OMV — это дистрибутив для простейшей файлопомойки на слабом железе для тех случаев, когда хочется иметь хоть какой-то веб-интерфейс и не хочется использовать zfs. Если же железо позволяет — лучше смотреть на другие варианты.

Но тут у меня наконец-то образовалась пачка одинаковых по объёму дисков, да ещё и не черепичных. Потому решил дать TrueNAS второй шанс. Тем более, что в свежей бете (Electric Eel) они наконец-то прикрутили более-менее нормальную поддержку докера, переходя на него c kubrnetes.
Что совпало со смертью каталога приложений TrueCharts, который до этого был основным источником контейнеров для TrueNAS Scale.

Для меня, как человека, который и с докером-то пару-тройку лет назад только общаться начал, а про kubernetes слышал только что «это какие-то контейнеры для энтерпрайза», такое стечение обстоятельство только на пользу.

Железо у меня в итоге получилось такое:

HP Microserver Gen7, с процессором AMD Turion(tm) II Neo N40L — 1,5GHz, 2 ядра (по производительности это примерно Rasperry Pi4).
16 GB оперативной памяти (обычной, не ECC)
4 диска по 6TB, один диск на 4TB и SSD на 500GB.
Дополнительно поставил USB-контроллер и вторую сетевую карту (пока гигабит, потом на 2.5 заменю).

ОС — TrueNAS SCALE 24.10

Мой сервер бэкапов Nas, Резервное копирование, Linux, Сервер, Длиннопост

Обязательно должен быть dashboard, можно даже два

Про установку писать не буду, там всё несложно — загрузился с CD, поставил ОС, зашел через веб-интерфейс — пользуешься. Разве что по мелочи:

  1. Загрузочным диском я выбрал USB-флэшку Sandisk Extreme на 32 гигабайта. Вообще, это не особо приветствуется, как я понял. Но Sandisk Extreme — очень выносливые флэшки, в отличие от всяких там Ultra. А флэшку на 32 гигабайта мне использовать особо некуда было, объём маловат. Так что пригодилась. Благо у сервера есть внутренний USB-разъём и снаружи ничего не торчит.

  2. Когда установщик спрашивал про EFI, я решил было, что у меня система старая и пусть лучше Legacy-загрузчик сделает. Как выяснилось, это было ошибкой — установка прерывалась с сообщением «не могу найти sda3». Некоторое время повозился с конфигами (ошибка не особо редкая, рекомендовали вставить в скрипт установки sleep 20), но в итоге всё решилось просто ответом «Да» на вопрос про EFI.

  3. Изначально я ставил стабильную версию, 24.04. После установки как раз и узнал про то, что каталог приложений TrueCharts помер, а сам TrueNAS Scale движется в сторону докера. Потому просто обновил систему через встроенный апдейтер до 24.10, даже переустанавливать не пришлось.

Диски

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

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

SSD используется для установки приложений.

А оставшийся диск на 4ТБ — под что-то типа архива и бэкапов бэкапов. Да, он будет работать без резервирования, но даже если помрёт, то на нём будут только копии копий находиться и вообще не особо важные данные вида «не хочется потерять, но не настолько важные, чтобы пихать их на основной массив».

Задачи сервера

Основная задача — оффсайтовый бэкап для домашнего сервера. Не всего подряд, само собой — дома у меня занято 30 терабайт, но того, что действительно жалко потерять, там порядка 3–4 терабайт. Пока эти бэкапы делаются в вандрайв (с шифрованием), но там подписка через год заканчивается и особого желания её продлять у меня нет — терабайтных облачных хранилищ у меня и так достаточно, офис 2010 или 2013, на которые у меня есть лицензии, для моих нужд ничем не хуже, чем офис365.

Вторичная — резервный сервер для некоторых сервисов, которые крутятся на домашнем сервере. К примеру, бывает полезно иметь второй инстанс сервиса, если к основному нет доступа. Пусть даже и БД этого инстанса не очень актуальна. Примеры — RSS-читалка (freshrss), vaultwarden (менеджер паролей), мониторинг аптайма (uptime kuma) и прочие мелочи, которые не требуют много процессорной мощности.

Установка приложений

Поскольку версия truenas пока ещё в бете, библиотека приложений тут достаточно ограничена, хотя и пополняется потихоньку — несколько дней назад было 96 приложений в каталоге, сейчас уже 102. А свои приложения так сразу непонятно, как добавлять. Раньше была кнопка «добавить контейнер», сегодня же её не видно. Конечно, можно зайти в консоль и оттуда вводить команды докера, но не затем я уходил с OMV, чтобы с консолью возиться.

Мой сервер бэкапов Nas, Резервное копирование, Linux, Сервер, Длиннопост

В репозитории имеются portainer и dockge. Portainer лично мне кажется слишком уж замороченным для простой задачи «поставить контейнер». Он слишком много умеет и глаза от этого разбегаются. Потому я его максимум ставил для того, чтобы мониторить работу контейнеров. А конфиги писал и ставил всё из консоли.

А вот dockge прост и лаконичен, если речь идёт просто об запуске контейнера. Вставляешь в поле текст yml-файла, запускаешь. Либо скармливаешь ему команду вида docker run — он её преобразует в конфиг, читаешь — редактируешь по потребности — запускаешь.

Мой сервер бэкапов Nas, Резервное копирование, Linux, Сервер, Длиннопост

Запуск librespeed

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

При этом dockge видит «чужие» контейнеры (которые truenas ставил), но рулит только своими. Это мне кажется удобным компромиссом — что можно ставишь из админки truenas, что нельзя — через dockge. Когда это что-то добавится в truenas — ну или когда там вернут полноценную работу с контейнерами — можно будет аккуратно мигрировать.

Доступ к серверу «из мира»

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

С другой стороны — к некоторым сервисам хочется иметь доступ извне, если уж делать тут резервный инстанс. Можно было бы сделать проброс портов с моего vps, допустим, но в данном случае мне проще было воспользоваться туннелями Cloudflare (cloudflared). Да, это опять привязка к третьей стороне, от которой я как бы ухожу, но, в данном случае, она не критичная. Если вдруг cloudflare отвалится, никто не мешает вернуться к вариантам с VPN, пробросом портов или просто купить реальный IP.

Технически это всё выглядит следующим способом:

В админке Cloudflare в разделе Zero Tier создаёте туннель, он вам говорит ID туннеля.

На своём сервере (или вообще на любом компьютере) ставите демон cloudflared и в настройках ему указываете ID туннеля. И дальше со стороны Cloudflare указываете поддомен, через который хотите обращаться к сервису и локальный IP:порт этого сервиса.
Единственное ограничение — доменом должен рулить cloudflare. Не обязательно его там покупать (хотя я купил специально под это дело отдельный домен), но DNS должен быть прописан тамошний.

Тут два туннеля — на админку и на контейнер с librespeed.

Мой сервер бэкапов Nas, Резервное копирование, Linux, Сервер, Длиннопост

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

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

Мой сервер бэкапов Nas, Резервное копирование, Linux, Сервер, Длиннопост

А вот через туннель 40 мегабит — это максимум, который удалось получить. Чаще же в районе 25-30 болтается. Впрочем, это для меня вполне терпимо, если не качать большие объёмы данных. А их я пока что качаю через локальную сеть провайдера.

Мой сервер бэкапов Nas, Резервное копирование, Linux, Сервер, Длиннопост

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

Бэкап как таковой

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

Самое большое и важное, что мне надо сохранять — это фотографии за много лет, которых уже порядка двух с половиной терабайт. Раньше они у меня через syncthing копировались на домашний сервер, а оттуда при помощи duplicati заливались в onedrive. Так что просто добавить ещё один инстанс syncthing’a смотрелось вполне логично. Ну и дальнейшую работу, наверное, большей частью буду в рамках syncthing’a организовывать. Хотя можно и любые другие протоколы использовать при необходимости.

Syncthing есть в каталоге приложений, ставится без вопросов. Само собой, надо в контейнер папку подмонтировать, куда бэкапы складывать. Сперва я посмотрел, как оно работает через глобальное обнаружение и посредников — вышло не очень. Максимум видел порядка 50 мегабит скорость, а так вообще колебалась в районе 10-20 мегабит. Два-три терабайта так качать совсем не хотелось.

Мой сервер бэкапов Nas, Резервное копирование, Linux, Сервер, Длиннопост

Потому настроил прямое соединение с домашним компьютером, выставив наружу порт syncthing’a на домашнем роутере. Так добился полной скорости — 100 мегабит, больше провайдер не предоставляет. Загрузка процессора при синхронизации колеблется в районе 50–70%, но особых лагов в админке не ощущается.

Второй способ — копирование данных с линуксовых серверов через rsync. Тут всё просто, был бы доступ к серверу по ssh. В настройках TrueNAS есть rsync tasks, просто добавляешь туда что, откуда и куда копировать, настраиваешь расписание — и вперёд.

Мой сервер бэкапов Nas, Резервное копирование, Linux, Сервер, Длиннопост

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

Планы на будущее

Из аппаратного:
Постараюсь заменить память на ECC. Раньше я к этом относился "хорошо, но не обязательно, а вот после приколов с домашним сервером стал относиться более серьёзно. Но новую память по 7000 за модуль брать жаба не даёт, а али завалено регистровой памятью, которую микросервер не понимает. Так что придётся искать ECC UDIMM на барахолках, что дело не быстрое.

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

Может быть, сниму контроллер usb-3 и поставлю вместо него переходник на nvme-диск — под кэш для массива.

По самому микросерверу — я не могу его рекомендовать, если вы собираете сервер совсем с нуля. В gen7 из полезного — только корпус на 4-5 дисков. Но нормально он себя ведёт только в связке с родной материнкой, если же её захочется обновить — то усилий по допиливанию корпуса под mini-ITX будет затрачено довольно много. По мне так проще потратиться на какой-нибудь китайский корпус и там уже собрать систему на нормальном железе. Или взять готовый NAS на x86 и поставить на него интересную вас ОС. Я микросервером воспользовался только по той причине, что он у меня имелся и по производительности более-менее устраивал. Иначе бы взял Jonsbo N2, очень симпатичный корпус, хоть и не очень бюджетный. Или N1.

Из программного:

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

В остальном я не вижу каких-то серьёзных путей для развития. Основное всё сделано, а дальше уже только использование по назначению остаётся. Все эксперименты и тяжелые задачи пойдут на второй сервер (который с proxmox’ом). Но это отдельная история, отдельной статьи не заслуживающая. Материалов на тему «как я поставил proxmox» в сети навалом в любых видах.

Показать полностью 11
[моё] Nas Резервное копирование Linux Сервер Длиннопост
60
91
Вопрос из ленты «Эксперты»
cbagpipe
cbagpipe
10 месяцев назад
Лига Сисадминов

Notion с нами больше не дружит( Альтернативы?⁠⁠

Помните когда-то была такая программа "Evernote", куда удобно было закидывать всё интересное из интернета, чтобы не потерять.

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

А потом нашел Notion - офигенный сервис, в котором всё было идеально:

  • Визуальный редактор

  • Таблички

  • Простейшие вычисления, как в эксельке

  • Ссылки из одних материалов на другие

  • Конструирование страниц из готовых блоков

  • Календари

  • Шаблоны

  • Можно было расшаривать странички для публичного доступа!

  • И всего хватало в бесплатном плане.

Короче для меня это было именно то что нужно.

Но пару дней назад...

Notion с нами больше не дружит( Альтернативы? Notion, Санкции, Продуктивность, Создание сайта, Сервер, Linux, Вопрос, Спроси Пикабу

Вы не можете получить доступ к Notion из запрещенной юрисдикции

Печалька... что тут ещё скажешь.

Теперь придётся искать и поднимать какой-то self-hosted аналог у себя на сервере...

Подскажите, какие есть альтернативы?

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

Показать полностью 1
Notion Санкции Продуктивность Создание сайта Сервер Linux Вопрос Спроси Пикабу
130
11
parx93
11 месяцев назад

Ответ на пост «Домашнее облако»⁠⁠1

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

IT Облачное хранилище Synology Xpenology Текст Linux Сервер Длиннопост Ответ на пост
20
Посты не найдены
О нас
О Пикабу Контакты Реклама Сообщить об ошибке Сообщить о нарушении законодательства Отзывы и предложения Новости Пикабу Мобильное приложение RSS
Информация
Помощь Кодекс Пикабу Команда Пикабу Конфиденциальность Правила соцсети О рекомендациях О компании
Наши проекты
Блоги Работа Промокоды Игры Курсы
Партнёры
Промокоды Биг Гик Промокоды Lamoda Промокоды Мвидео Промокоды Яндекс Директ Промокоды Отелло Промокоды Aroma Butik Промокоды Яндекс Путешествия Постила Футбол сегодня
На информационном ресурсе Pikabu.ru применяются рекомендательные технологии