Комментарии 29
Спасибо, пригодится в хозяйстве.
Структура чем-то напоминает RAID0, при выходе из строя одного(не MGS/MDT) из устройств система продолжает функционировать и возвращается в полностью рабочее состояние при возвращении потерявшегося бойца.
Может таки RAID1? А то как-то в случае потери одного из дисков в RAID0 все ломается :)
Нет нет, я не ошибся. Именно RAID0 — скорость чтения/записи повышена. Если в Lustre потеряем бойца, глюки будут. Возврат бойца в строй производится в штатном режиме.
Скорость чтения повышена и на RAID0 и на RAID1.
да ну?
Ну да.
en.wikipedia.org/wiki/RAID#RAID_1
«RAID 1 Mirrored set without parity or striping. Provides fault tolerance from disk errors and failure of all but one of the drives. Increased read performance occurs when using a multi-threaded operating system that supports split seeks, as well as a very small performance reduction when writing»
en.wikipedia.org/wiki/RAID#RAID_1
«RAID 1 Mirrored set without parity or striping. Provides fault tolerance from disk errors and failure of all but one of the drives. Increased read performance occurs when using a multi-threaded operating system that supports split seeks, as well as a very small performance reduction when writing»
Ощутимый прирост скорости чтения/записи даёт RAID0, fakedream прав. 1 наверно тоже даёт, но не так явно.
Вопрос был в том, дает ли RAID1 вообще какой-либо прирост, а не в степени этого прироста. Однако www.google.ru/search?q=RAID1+read+performance+increase&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:ru:official&client=firefox
у люстры нет raid1
Не устаю напоминать, что монтировать папки с данными в корень — дурной тон. Нужно или в /var, или в /srv, ну или хотя бы в /usr/local
А за проделанную работу спасибо.
А за проделанную работу спасибо.
Чем плохо монтировать папки с данными в корень?
Это не плохо, это просто некрасиво, что ли. Желательно стараться придерживаться стандарта на иерархию ФС, вместо того, чтобы создавать свою уникальную иерархию.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Люстра на каких условиях распространяется?
Пока довелось поработать только с gpfs у нас на кластере, она вроде как платная, но нам в свое время на шару дали как университету.
Надо будет попробовать ее потестить на небольшом экспериментальном кластере…
Еще вопрос — Люстра позволяет MGS/MDT зеркалить? Т.е. чтобы при падении одного из серверов, на которых лежат метаданные, файловая система не рассыпалась? Под gpfs у нас два сервера используются, и при падении одного, файловая система продолжает работать, пусть медленнее, но работать.
Пока довелось поработать только с gpfs у нас на кластере, она вроде как платная, но нам в свое время на шару дали как университету.
Надо будет попробовать ее потестить на небольшом экспериментальном кластере…
Еще вопрос — Люстра позволяет MGS/MDT зеркалить? Т.е. чтобы при падении одного из серверов, на которых лежат метаданные, файловая система не рассыпалась? Под gpfs у нас два сервера используются, и при падении одного, файловая система продолжает работать, пусть медленнее, но работать.
я вот так и не понял — это распределенная сетевая система? где общий раздел состоит из кусочков, разбросанных по узлам. или же есть некий общий раздел, доступный одновременно для всех нод на чтение-запись?
сейчас как раз занимаюсь люстрой.
Во-первых Вы не указали важный факт — у люстры НЕТ фейловера и репликации. Т.е. если Вы хотите у себя отказоустойчивость, то потребуется либо шаред сторадж + heartbeat, либо drbd + heartbeat. Это раз.
Два — Ваша статья претендует на хауту, но в ней нет важных моментов. Например в продакшене требуется отключить дебаг на серверах и клиенах: echo 0 > /proc/sys/lnet/debug. С дебагом работает значительно медленнее.
Так же не сказано, что по дефолту файлы страйпятся из принципа — один файл->одна нода. Это можно и нужно изменять. Но на массивах с большими (> 1M) файлами. Почитать об этом можно вот тут: blogs.sun.com/atulvid/entry/improving_performance_of_small_files
Три, это вопрос уже тем, кто использует люстру в продакшене. Как быть с мелкими файлами? У меня просто чудовищно низкая скорость записи/чтения мелких файлов.
Во-первых Вы не указали важный факт — у люстры НЕТ фейловера и репликации. Т.е. если Вы хотите у себя отказоустойчивость, то потребуется либо шаред сторадж + heartbeat, либо drbd + heartbeat. Это раз.
Два — Ваша статья претендует на хауту, но в ней нет важных моментов. Например в продакшене требуется отключить дебаг на серверах и клиенах: echo 0 > /proc/sys/lnet/debug. С дебагом работает значительно медленнее.
Так же не сказано, что по дефолту файлы страйпятся из принципа — один файл->одна нода. Это можно и нужно изменять. Но на массивах с большими (> 1M) файлами. Почитать об этом можно вот тут: blogs.sun.com/atulvid/entry/improving_performance_of_small_files
Три, это вопрос уже тем, кто использует люстру в продакшене. Как быть с мелкими файлами? У меня просто чудовищно низкая скорость записи/чтения мелких файлов.
Отказоустойчивость — отдельная большая тема, поэтому в текущем варианте Lustre сравнима с RAID0, если напишете Ваш опыт будет очень полезен.
Ctrl+f пофайлово =)
Ctrl+f пофайлово =)
Насчет этого я даже и не знаю, что писать. Настройка Heartbeat стандартная, drbd тоже стандартное. По ним есть куча хаутушек в интернете. Так же можете поискать в сети выпуск журнала системный администратор за февраль 2007. Там в общих чертах описана настройка heartbeat и drbd как раз для люстры. Есть некоторые недочеты, но при чтении документации они нивелируются.
Единственное вспомнил. По установке дрбд на центос. DRBD в центосе, как оказалось сейчас сломано. Т.е. у меня не получилось запустить его с последним ядром, которое идет в составе центоса. Модуль из src.rpm тоже собрать не получилось. Качал вот отсюда oss.linbit.com/drbd/ тарбол с 8.3.7. Там внутри есть .spec файл, из которого замечательным образом собираются в rpm-ки все пакеты и модули.
> Наибольшее распространение получила NFS, но для боевых задач с её скоростью и неочевидностью настройки прав доступа практически непригодна.
С появлением pNFS (parallel NFS) в NFS v4.1, которая прошла стандатизацию в яваре того года, это уже не так.
С появлением pNFS (parallel NFS) в NFS v4.1, которая прошла стандатизацию в яваре того года, это уже не так.
>>дисковых массивов RAID0 — запись/чтение побитово производится на оба диска
oO
может поблочно. иначе зачем когда создаеш raid 0 указываеш размер блока
oO
может поблочно. иначе зачем когда создаеш raid 0 указываеш размер блока
У вас в коде mdkir вместо mkdir :)
Статья категорически неполна без демонстрации результатов. Раз говорите о скорости — приведите замеры. Говорите о распределенности — покажите что происходит при отключении и возврате в строй узла.
В идеале — в сравнении с другими ФС в одинаковых условиях.
В идеале — в сравнении с другими ФС в одинаковых условиях.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кластерная LustreFS или с Миру по нитке