Какой самый быстрый способ переместить 1 петабайт из одного хранилища в новое?
Прежде всего, спасибо за чтение, и извините за вопрос, связанный с моей работой. Я понимаю, что это то, что я должен решить сам, но, как вы увидите, это немного сложно.
Небольшое описание:
Сейчас
Storage => 1PB с использованием хранилища DDN S2A9900 для OST, 4 OSS, 10 GigE сети. (глянец 1.6)
100 вычислительных узлов с 2x Infiniband
1 бесконтактный коммутатор с 36 портами
После
Память => Предыдущее хранилище + еще 1PB с использованием DDN S2A 990 или LSI E5400 (еще предстоит решить) (блеск 2.0)
8 OSS, сеть 10GigE
100 вычислительных узлов с 2x Infiniband
Предыдущий опыт: перенес 120 ТБ менее чем за 3 дня, используя следующую команду:
tar -C /old --record-size 2048 -b 2048 -cf - dir | tar -C /new
--record-size 2048 -b 2048 -xvf - 2>&1 | tee /tmp/dir.log
Итак, большая проблема здесь, используя большие математические уравнения, я заключаю, что нам потребуется 1 месяц, чтобы перенести данные с одной стороны на новую. В течение этого времени исследователи должны будут отступить, и я лично не доволен этим.
Я говорю вам, что у нас есть бесконечные соединения, потому что я думаю, что, возможно, есть шанс использовать его для передачи данных с использованием 18 вычислительных узлов (18 * 2 IB = 36 портов) для передачи данных из одного хранилища в другое, Я пытаюсь выяснить, будет ли коммутатор IB обрабатывать весь трафик, но в случае, если он просто сгорит, будет быстрее, чем при использовании 10GigE.
Кроме того, наличие агентов luster 1.6 и 2.0 на одном и том же сервере работает достаточно хорошо, поэтому нет необходимости переходить на 1.8 для обновления серверов метаданных в два этапа.
Есть идеи?
Большое спасибо
Примечание 1: Zoredache, мы можем разделить его на два блока (A)600Tb и (B)400Tb. Идея состоит в том, чтобы переместить (A) в новое хранилище, которое отформатировано в lustre 2.0, затем отформатировать, где (A) было с lustre 2.0, и переместить (B) в этот блок lustre 2.0 и расширить пространство, где было (B),
Таким образом, мы закончим с (A) и (B) в отдельных файловых системах, по 1PB каждая.
1 ответ
Цель состоит в том, чтобы каждый слой между старым и новым хранилищами работал быстрее максимальной скорости чтения, которую вы можете получить со своей старой машины. Их спецификации требуют 6 Гбайт / с (что должно быть). Это означает, что минимальное время, необходимое для перемещения данных, составило бы 46 часов, если вы сможете получить заявленную скорость.
Когда вы использовали tar для перемещения 120 ТБ в течение 3 дней, вы должны были в среднем всего лишь половину ГБ в секунду, а это значительно меньше, чем заявленные спецификации в 6 ГБ / с. Истинное число, скорее всего, будет где-то посередине.
Во-первых, смола может быть вашей проблемой. Я работаю с хранилищем, а не с Unix, но, насколько я знаю, это может ограничить вашу пропускную способность в зависимости от скорости процессора. Если вы придерживаетесь этой методологии, вы можете закрыть окно миграции, увеличив число узлов, на которых выполняется миграция, и заставив их работать в разных частях набора данных. Добавляйте узлы, пока старая машина не сможет быстрее обслуживать файлы.
Во-вторых, убедитесь, что вы можете записывать данные с узла миграции в новое хранилище так же быстро, как вы можете считывать данные со старого хранилища. Это может означать настройку некоторых параметров нового хранилища (особенно если оно имеет устаревший зеркальный кэш записи), а также отсутствие узких мест в сети.
И наконец, и это может быть немного надуманным, если вы можете сократить время простоя, и этот блок обслуживает LUN через FC, вы можете вставить устройство виртуализации хранилища в путь данных, что позволит вам продолжать использовать хранилище, хотя и медленнее, пока вы делаете миграцию. IBM SAN Volume Controller, устройство виртуализации Falconstore или массив хранения HDS способны автоматизировать миграцию данных в фоновом режиме, не прерывая доступ к хосту. Ни один из них не будет настолько быстрым, как вы привыкли, но он позволит вам выполнять работу во время миграции после краткого перерыва, необходимого для работы узлов из новых головок хранения.
Вероятно, не стоит покупать его, так как вы не будете использовать его после завершения миграции, но вы можете взять его напрокат или взять напрокат.