Прежде всего, спасибо, что прочитали, и извините за вопрос, связанный с моей работой. Я понимаю, что это то, что я должен решить сам, но, как вы увидите, это что-то немного сложное.
Небольшое описание:
Сейчас
Хранилище => 1 ПБ с использованием хранилища DDN S2A9900 для OST, 4 OSS, сеть 10 GigE. (глянец 1.6)
100 вычислительных узлов с 2x Infiniband
1 коммутатор Infiniband на 36 портов
После
Хранилище => Предыдущее хранилище + еще 1 ПБ с использованием 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 месяц, чтобы перенести данные с одной стороны на новую. В течение этого времени исследователям придется отступить, и я лично не доволен этим.
Я говорю вам, что у нас есть соединения Infiniband, потому что я думаю, что может быть возможность использовать его для передачи данных с использованием 18 вычислительных узлов (18 * 2 IB = 36 портов) для передачи данных из одного хранилища в другое . Я пытаюсь понять, будет ли коммутатор IB обрабатывать весь трафик, но если он просто сгорит, будет быстрее, чем при использовании 10GigE.
Кроме того, наличие агентов lustre 1.6 и 2.0 на одном сервере работает достаточно хорошо, при этом нет необходимости переходить на 1.8 для обновления серверов метаданных в два этапа.
Любые идеи?
Большое спасибо
Примечание 1: Zoredache, мы можем разделить его на два блока (A) 600Tb и (B) 400Tb. Идея состоит в том, чтобы переместить (A) в новое хранилище, которое отформатировано lustre2.0, затем отформатировать, где (A) было с lustre2.0, и переместить (B) в этот блок lustre2.0 и расширить пространство, где (B) было .
Таким образом, мы закончим (A) и (B) на отдельных файловых системах, по 1 ПБ каждая.
Цель состоит в том, чтобы каждый слой между старым и новым хранилищем работал быстрее, чем максимальная скорость чтения, которую вы можете получить со своей старой машины. Их спецификации требуют 6 ГБ / с последовательной передачи (что должно быть). Это означает, что минимальное возможное время для перемещения данных будет в пределах 46 часов, если вы сможете получить заявленную скорость.
Когда вы использовали tar для перемещения 120 ТБ за 3 дня, у вас должно быть в среднем чуть меньше половины ГБ в секунду, а это значительно меньше 6 ГБ / с, заявленных в спецификации. Истинное число, скорее всего, будет где-то посередине.
Во-первых, вашей проблемой может быть tar. Я специалист по хранению данных, а не по Unix, но, насколько мне известно, он может ограничивать вашу пропускную способность в зависимости от скорости процессора. Если вы будете придерживаться этой методологии, вы можете уменьшить окно миграции, увеличив количество узлов, на которых выполняется миграция, и заставив их работать с разными частями набора данных. Продолжайте добавлять узлы, пока старая машина не перестанет обрабатывать файлы быстрее.
Во-вторых, убедитесь, что вы можете записывать данные со своего узла миграции в новое хранилище так же быстро, как вы можете считывать данные со старого хранилища. Это может означать настройку некоторых настроек в новом хранилище (особенно если оно имеет устаревший зеркальный кеш записи), а также обеспечение отсутствия узких мест в сети.
Наконец, и это может быть немного надуманным, если вы можете взять время простоя и этот ящик обслуживает LUN через FC, вы можете вставить устройство виртуализации хранилища в путь к данным, что позволит вам продолжать использовать хранилище, хотя и медленнее, пока вы делаете миграцию. Контроллер тома SAN от IBM, устройство виртуализации Falconstore или массив хранения HDS - все они способны автоматизировать миграцию данных в фоновом режиме без прерывания доступа к хосту. Ни один из них не будет таким быстрым, как то, к чему вы привыкли, но он позволит вам выполнять работу во время миграции после краткого перерыва, необходимого для работы узлов с новыми головками хранилища.
Вероятно, не стоит покупать его, так как вы не будете использовать его после завершения миграции, но вы можете взять его взаймы или арендовать.