+7 (495) 320-70-49
- Назад
- Телефоны
- +7 (495) 320-70-49
- Заказать звонок
info@proxmox.su
Москва, Бакунинская улица, 69с1
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Идеи для самодельной, кустарной сборки, Proxmox Backup Server

IsThisThingOn

Guest

30.09.2024 13:42:00

Хочу запустить несколько тестов производительности для бюджетной сборки и нужно ваше мнение. Хочу использовать старое железо, которое у меня валяется. Сборка будет установлена в удалённом месте с сетью 10GBit. Моя цель — достичь хотя бы 1GBit. К сожалению, в форуме я особо не нашёл результатов подобных бенчмарков https://pbs.proxmox.com/docs/backup-client.html#benchmarking. Вот варианты, которые думаю протестировать:

1. Старый Intel NUC NUC7i3BNK с 8 ГБ ОЗУ. В него влезает только один быстрый NVME. Конечно, это не защитит от выхода одного диска из строя, но SSD обычно довольно надёжны. Планирую установить ext4.

2. То же самое, но с ZFS. Не уверен, даст ли ZFS преимущество здесь, ведь PBS уже использует чексы и прочие штуки. Возможно, есть плюсы из-за ARC? Но скорость записи может упасть из-за ZIL?

3. Старый AMD Ryzen 1700 с 16 ГБ ОЗУ. Два очень старых HDD по 8 ТБ в зеркальном пуле ZFS.

4. Та же сборка, но с особым vdev из старого Samsung Evo 870 на 500 ГБ и Intel 535.

Какие мысли? Идеи?

IsThisThingOn Guest	#2 0 28.10.2024 20:42:00 Спасибо, ребята, за ваши советы. Так как я выключаю свои машины перед бэкапом и мне не нужно больше 100 Мбит/с от моего гигабитного WAN, думаю, я избавлюсь от локального PBS.

IsThisThingOn

Guest

25.10.2024 15:37:00

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

Ghetto PC — это старенький AMD Ryzen 1700 с 8 ядрами, 16 ГБ оперативки. SSD — Samsung 960 EVO на 500 ГБ. Теоретически пишет со скоростью 1900 Мбит и 360 тысяч IOPS. Жесткий диск — Toshiba MG10 на 20 ТБ.

IsThisThingOn

Guest

25.10.2024 18:05:00

Ну что ж, открыть что-нибудь с помощью nano приводит к сбою системы. Придется искать другое железо. В общем, я только что понял, что инструмент Proxmox Benchmark на самом деле не тестирует диск, а проверяет другие параметры. Поскольку мой NUC не поддерживает SATA или 3,5-дюймовые диски, думаю, придется использовать один nvme-диск.

tcabernoch

Guest

27.10.2024 02:07:00

Эээ... Честно говоря, я не совсем понял, к чему ты клонишь. Я делал тестирование дисков для PBS, используя скрипт из этого поста: https://forum.proxmox.com/threads/datastore-performance-tester-for-pbs.148694/ Он выдает кучу сырых данных, с помощью которых можно сравнивать влияние разных конфигураций дисков. Я пользовался им, чтобы настроить ZFS. Удачи тебе в этом деле!

IsThisThingOn

Guest

27.10.2024 09:51:00

Спасибо, было интересно почитать, хотя я не уверен, что всё до конца понял. Давайте попробую лучше описать, что именно ищу. Мне нужен offsite PBS. Сейчас я делаю довольно быстрые бэкапы (200 МБ/с) на один ext4 HDD. Моя главная проблема в том, что в случае пожара или кражи у меня нет резервной копии вне офиса. И, конечно, нужна защита от 321 и ransomware. Поэтому идея в том, чтобы установить PBS во втором офисе и делать туда бэкапы по TLS. В обоих офисах 1 Гбит оптика.

Итак, мои основные мысли и вопросы следующие: я не совсем понимаю, какой производительности ждать от одного HDD в сравнении с HDD + специализированным хранилищем или SSD. Насколько я понял, тест производительности TLS в proxmox на PVE покажет только одно узкое место — производительность TLS на PVE, зато не даст реальных данных о скорости хранилища. Ваш проект на github пытается смоделировать реальную нагрузку, записывая случайные блоки. Могу я запустить ваш тест "Run a simple test on your local disk / the disk you already mounted" на машине PBS (которая будет моей удалённой машиной), чтобы понять, как работают эти комбинации из первого вопроса? Реальная производительность наверняка будет хуже из-за дополнительной задержки.

Как думаете, она будет примерно на уровне ваших результатов по SMB/NFS? Скорее всего, я возьму ZFS вместо ext4, чтобы быть на 100% защищённым, как описывал Dunuin здесь.

news

Guest

27.10.2024 10:43:00

Плохо использовать только один HDD, настрой ZFS Mirror-0 с 2 HDD и Mirror-1 с 2 HDD, а также ZFS Special Device с 2 SSD примерно на 10% от общего объёма raw HDD. Не забудь установить квоту для ZFS примерно в 80% от итогового пространства пула с учётом трёх VDEV-ов:
zfs set quota=<pool-space> <pool-name>
Если учесть, что HDD имеют около 120 IOPS, а SSD — более 10 тысяч IOPS, вся метаинформация ZFS будет храниться на этом ZFS Special Device с 2 SSD или больше. При этом у тебя будет ZFS Mirror-0 с 2 HDD и Mirror-1 с 2 HDD для необработанных данных.

Итог по ZFS Pool:
- Чтение — примерно в 4 раза больше IOPS от HDD
- Запись — примерно в 2 раза больше IOPS от HDD
- Скорость SSD в этом варианте особо не важна

Можно также настроить ZFS Special Device с более чем двумя SSD — это ускорит, например, команду вывода списка файлов ls -lA. Прокмокс и ZFS Backupserver используют миллионы случайных операций чтения/записи 4k для доступа к пулу и датасетам.

Используй только корпоративные SSD (SATA III) с PLP, например Kingston DC600M.
# https://www.kingston.com/en/ssd/dc600m-data-center-solid-state-drive

В Германии я заказываю и забираю комплектующие на Alternate.de.

tcabernoch

Guest

27.10.2024 20:40:00

Хотите организовать удалённый PBS? Настройте 2 сервера PBS: один локальный и один удалённый. Запускайте задания на резервное копирование на локальном сервере. Запускайте задания синхронизации, чтобы копировать бэкапы с локального PBS на удалённый PBS. Начните с этой статьи: https://pbs.proxmox.com/docs/managing-remotes.html

IsThisThingOn Guest	#9 0 27.10.2024 21:01:00 Хмм... Я бы предпочёл чуть худшую производительность, но чтобы нужен был только один PBS вместо двух, как мне кажется.

tcabernoch

Guest

#10

27.10.2024 22:52:00

Признаюсь, я не до конца понимаю твой план. Но если нужны резервные копии вне основного сервера, в мире PBS это делается через Remotes и Sync Jobs. Просто подумай об этом немного. На самом деле, не так уж и сложно. Удачи!

IsThisThingOn Guest	#11 0 28.10.2024 07:55:00 У меня PVE на локации А. У меня PBS на локации В. Хочу сделать резервное копирование с А на В по TLS. Это же возможно, да?

tcabernoch Guest	#12 0 28.10.2024 20:03:00 Абсолютно верно. Есть и другие способы сделать это. Но вот так — правильно. Запустите ещё один PBS на вашем PVE в локации А. Сделайте локальный бэкап с помощью PBS А. Синхронизируйте с PBS А на PBS B.

_gabriel

Guest

#13

28.10.2024 20:21:00

Не рекомендуется делать бэкап на PBS через WAN, если гостевая машина запущена. Во время живого бэкапа гость тормозит, вплоть до краха, если соединение прерывается или слишком медленное. Есть новая опция для смягчения этой проблемы, но сбои всё равно возможны. Более надёжный и рекомендуемый способ — использовать PBS локально на PVE. (PBS даже можно установить как пакет поверх PVE на том же хосте). Потом PBS оффсайт забирает/синхронизирует данные с первого сайта. Вот так делаю я.

IsThisThingOn

Guest

#14

12.11.2024 18:02:00

Наконец-то нашёл время провести несколько тестов производительности.

На PVE
SHA256 скорость: 614.09 МБ/с
Скорость сжатия: 592.06 МБ/с
Скорость распаковки: 846.54 МБ/с
AES256/GCM скорость: 4700.58 МБ/с
Скорость проверки: 354.22 МБ/с

С PVE на PBS через proxmox-backup-client benchmark --repository 10.0.51.50:test
TLS скорость: 117.54 МБ/с
SHA256 скорость: 615.98 МБ/с
Скорость сжатия: 590.80 МБ/с
Скорость распаковки: 839.22 МБ/с
AES256/GCM скорость: 4712.22 МБ/с
Скорость проверки: 352.30 МБ/с

Похоже, TLS скорость ограничена пропускной способностью линии. У некоторых моих сайтов 10 Гбит, у других — всего 60 Мбит загрузка. Так что показатели будут сильно разниться.

На PBS
SHA256 скорость: 324.15 МБ/с
Скорость сжатия: 332.37 МБ/с
Скорость распаковки: 409.43 МБ/с
AES256/GCM скорость: 1945.79 МБ/с
Скорость проверки: 179.43 МБ/с

С PVE на PBS ext4 внешний USB 3.0 2,5" HDD
Первый запуск:
INFO: backup is sparse: 18.66 ГиБ (58%) нулевых данных
INFO: backup done incrementally, reused 18.66 ГиБ (58%)
INFO: transferred 32.00 ГиБ за 190 секунд (172.5 МиБ/с)

Второй запуск без изменений:
INFO: backup is sparse: 18.66 ГиБ (58%) нулевых данных
INFO: backup done incrementally, reused 32.00 ГиБ (100%)
INFO: transferred 32.00 ГиБ за 33 секунды (993.0 МиБ/с)

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

С PVE на PBS ext4 INTEL SSDPEKKW128G7
Первый запуск:
INFO: backup is sparse: 18.66 ГиБ (58%) нулевых данных
INFO: backup сделан инкрементально, reused 18.66 ГиБ (58%)
INFO: transferred 32.00 ГиБ за 54 секунды (606.8 МиБ/с)

Второй запуск без изменений:
INFO: backup is sparse: 18.66 ГиБ (58%) нулевых данных
INFO: backup done incrementally, reused 32.00 ГиБ (100%)
INFO: transferred 32.00 ГиБ за 32 секунды (1.0 ГиБ/с)

Запуск на Intel прошёл быстрее благодаря тому, что это NVME SSD. Но вот второй запуск не оказался быстрее, чем на HDD. У вас есть какие идеи, почему? Может, другой узкий потолок?

NFS шар RAIDZ2, специальный vdev
transferred 32.00 ГиБ за 40 секунд (819.2 МиБ/с)
Довольно быстро, но это не инкрементальный прогон.

IsThisThingOn Guest	#15 0 16.11.2024 11:04:00 Есть идеи, что стало узким местом во втором прогоне? Может, сам хост слишком медленный, и поэтому результаты для HDD и SSD почти не отличаются?

tcabernoch Guest	#16 0 01.12.2024 22:43:00 Ты задаёшь интересные вопросы, которые действительно заслуживают внимания. Это довольно длинная тема. Может быть, ты переформулируешь свой вопрос? Чтобы нам было проще понять, кратко опиши конфигурацию для запуска и как она должна соотноситься с другими конфигурациями. А потом спроси, почему она отличается от твоих ожиданий.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры