Прочитал документацию по репликации между двумя узлами, не входящими в кластер, с использованием pve-zsync. Это работает у меня в лабораторной среде, но я хочу убедиться, что я все делаю правильно и что это лучший способ добиться необходимого. У меня есть двухузловая среда ESXi, которую я планирую перевести на что-то другое, рассматриваю xcp-ng и Proxmox. Это поддерживает малый бизнес и не находится в каком-либо дата-центре, но есть 2 сервера, расположенных в разных серверных шкафах на месте. Для малого бизнеса с архитектурной точки зрения не всегда возможно запустить кластер. Я думаю, многие упрощают это и запускают кластеры с q устройствами, но реальность такова, что для малого бизнеса с узлами, разделенными из соображений избыточности, так много единичных точек отказа, что практически невозможно всегда иметь 2 узла, доступные. В настоящее время у меня есть 2 узла ESXi и я использую Veeam для репликации с одного узла на другой и резервного копирования всех ВМ. Это хорошо служит и работает для нужд этого малого бизнеса. Если бы я потерял шкаф, серьезные проблемы с электропитанием, сетевой коммутатор и т.д., большинство служб дублируются на узлах, за исключением одной файловой шары, которую можно запустить через реплицированную ВМ Veeam. Именно это я пытаюсь реализовать с альтернативными решениями, которые я рассматриваю и работаю с Proxmox. Сейчас я запускаю pve-zsync на одном узле и реплицирую на другой, и кажется, что это работает хорошо.
```
pve-zsync list SOURCE NAME STATE LAST SYNC TYPE CON 100 testzsync1 ok 2025-07-06_09:15:01 qemu ssh
```
Данные копируются, а затем каждые 15 минут синхронизируется с другим узлом, но копируется только часть диска. Судя по документации, вам также необходимо скопировать конфигурацию ВМ на другой узел, что я сделал с помощью scp:
```
scp /etc/pve/qemu-server/100.conf root@x.x.x.x :/etc/pve/qemu-server/100.conf
```
Одна из проблем, которую я вижу с командой SCP, заключается в том, что, если я не добавлю ее в ночной cron job, это будет однократное действие. Если я внесу какие-либо изменения в параметры конфигурации ВМ, хотя это и редко, эти изменения не будут скопированы, если я каким-то образом не добавлю их в ночной/ежедневный cron job. Другая вещь, которую я прочитал, заключается в том, что если мне нужно запустить ВМ на другом хосте, мне нужно убедиться, что задание репликации остановлено. В зависимости от типа сбоя, вызвавшего отказ, это может быть простой задачей или чем-то, в чем мне нужно убедиться, прежде чем я перезапущу другой узел. Я просто хотел убедиться, что вышеперечисленное звучит правильно, и у меня есть дополнительные вопросы. Как только я смогу перезагрузить исходный узел, я предполагаю, что смогу выполнить однократную синхронизацию НАЗАД на исходный узел. Я еще не пробовал этого, но предполагаю, что это возможно, поскольку я хотел бы вернуть приложение на исходный узел.
Некоторые комментарии, которые, как я знаю, поднимались ранее, но хочу повторить заявления, касающиеся VMID. Я частично понимаю, почему они приняли такой подход, но было бы неплохо, если бы хранилище имело vmid+имя и т.д. При репликации на другой узел без конфигурационной части у вас есть только хранилище с меткой vmid, и, если я что-то упускаю, нет способа узнать на этом узле, с чем связано имя. Я знаю, что это, вероятно, не проблема с кластерами и т.д., но для некластерных сред (меньшие бизнесы) это просто усложняет отслеживание того, что к чему, при репликации. Просто мой комментарий, это то, что есть, но это действительно облегчило бы нам малым предприятиям управление. Все еще нужно получить UPS и работоспособное выключение, но поскольку Proxmox теперь официально поддерживает Veeam, это удовлетворяет требование резервного копирования. Любые мысли о том, что я делаю с репликацией, были бы отличными, спасибо!
```
pve-zsync list SOURCE NAME STATE LAST SYNC TYPE CON 100 testzsync1 ok 2025-07-06_09:15:01 qemu ssh
```
Данные копируются, а затем каждые 15 минут синхронизируется с другим узлом, но копируется только часть диска. Судя по документации, вам также необходимо скопировать конфигурацию ВМ на другой узел, что я сделал с помощью scp:
```
scp /etc/pve/qemu-server/100.conf root@x.x.x.x :/etc/pve/qemu-server/100.conf
```
Одна из проблем, которую я вижу с командой SCP, заключается в том, что, если я не добавлю ее в ночной cron job, это будет однократное действие. Если я внесу какие-либо изменения в параметры конфигурации ВМ, хотя это и редко, эти изменения не будут скопированы, если я каким-то образом не добавлю их в ночной/ежедневный cron job. Другая вещь, которую я прочитал, заключается в том, что если мне нужно запустить ВМ на другом хосте, мне нужно убедиться, что задание репликации остановлено. В зависимости от типа сбоя, вызвавшего отказ, это может быть простой задачей или чем-то, в чем мне нужно убедиться, прежде чем я перезапущу другой узел. Я просто хотел убедиться, что вышеперечисленное звучит правильно, и у меня есть дополнительные вопросы. Как только я смогу перезагрузить исходный узел, я предполагаю, что смогу выполнить однократную синхронизацию НАЗАД на исходный узел. Я еще не пробовал этого, но предполагаю, что это возможно, поскольку я хотел бы вернуть приложение на исходный узел.
Некоторые комментарии, которые, как я знаю, поднимались ранее, но хочу повторить заявления, касающиеся VMID. Я частично понимаю, почему они приняли такой подход, но было бы неплохо, если бы хранилище имело vmid+имя и т.д. При репликации на другой узел без конфигурационной части у вас есть только хранилище с меткой vmid, и, если я что-то упускаю, нет способа узнать на этом узле, с чем связано имя. Я знаю, что это, вероятно, не проблема с кластерами и т.д., но для некластерных сред (меньшие бизнесы) это просто усложняет отслеживание того, что к чему, при репликации. Просто мой комментарий, это то, что есть, но это действительно облегчило бы нам малым предприятиям управление. Все еще нужно получить UPS и работоспособное выключение, но поскольку Proxmox теперь официально поддерживает Veeam, это удовлетворяет требование резервного копирования. Любые мысли о том, что я делаю с репликацией, были бы отличными, спасибо!
