.png)
У нас есть сервер NFS (Linux), который хранит файлы в дисковом массиве iSCSI. Этот сервер находится в производстве. Сервер и массив очень старые и должны быть вскоре заменены (массив уже в серьезных проблемах).
У меня уже готовы новый сервер и массив в другой сети.
Я думал о том, чтобы rsyncing акций, а затем сделать это снова, чтобы синхронизировать данные. Я не знаю, может ли это вызвать несогласованность данных... Поскольку акции смонтированы через lvm, может быть, я мог бы сначала сделать снимок?
ВОПРОС:
Какой лучший подход к миграции всех данных? Есть ли у вас какие-либо советы?
решение1
Ваш подход хорош, если вы планируете отключить запись в массив перед вторым rsync. Это приведет (должно) к чистой копии.
В зависимости от обстоятельств, чтобы минимизировать время простоя, выполните тройную rsync:
- rsync файловых систем, пока исходный сервер работает как есть. Это займет некоторое время и даст вам черновую копию, возможно, с большим количеством несоответствий.
- (необязательно) Если #1 занимает много времени и у вас много записей в это время, rsync его снова с исходным сервером, работающим как есть. Этот шаг займет меньше времени, и вы получите гораздо лучшую копию (меньше записей произошло во время его работы).
- Остановите запись в исходный узел. Лучший способ — смонтировать его только для чтения, как предлагает stoned. Но отключение служб или использование однопользовательского режима тоже может помочь.
- rsync это в последний раз. На этот раз это должно быть довольно быстро. Не должно быть много несоответствий (шаг №2 намного короче, чем №1), так что синхронизировать особо нечего.
- Выполните проверки и запустите новый сервер вместо старого.
Однако следует отметить несколько моментов:
- Если у вас много маленьких файлов (миллионы), каждая rsync-синхронизация в любом случае будет занимать некоторое время. (то же самое касается медленных линий, медленных/деградировавших хранилищ и т. д.)
- Если у вашего исходного хранилища уже есть проблемы (вышедшие из строя диски или что-то еще, что может привести к тому, что том станет нечитаемым), просто начните с пункта 3. Вы получите длительный простой, но вы сведете к минимуму риск сбоя во время передачи.
- Мне просто пришла в голову безумная идея rsync всего устройства, на котором находится файловая система. Это может сработать, если target больше source. Но я не рекомендую этого делать, так как сам не пробовал.
решение2
Rsync+rsync или снимок+rsync не будут иметь большого значения — rsync, возможно, будет более удобным, так как вы сможете в конечном итоге сжать/зашифровать данные во время передачи без необходимости использования дополнительных команд. В обоих случаях вы будете вечно пытаться наверстать упущенное вашими пользователями, возможно, скопировали на общий ресурс с момента последнего rsync, включая частичные файлы, все еще находящиеся в пути. Честно говоря, я бы рекомендовал вам сделать первую копию с помощью rsync в период низкого использования. Затем предупредите своих пользователей, что будет небольшой сбой из-за необходимого обслуживания. Остановите запись служб на диск. Перемонтируйте старый общий ресурс в режим только для чтения, выполните последний rsync, а затем полностью замените старый общий ресурс nfs на новый. Если вы хотите/можете, вы можете предоставить клиентам доступ только для чтения в течение этого периода. 100% доступность — это чистая мечта, и лучше остановить своих клиентов на 1 час, чем гоняться за возможными бесконечными жалобами на потерю/повреждение данных и сбои приложений.