Конфигурация RAID 6 на 24 ТБ

Честно говоря, я думаю, что 5 тысяч долларов за диски - это немного круто... но это совсем другая тема. Настройка звучит достаточно звучно, но в случае сбоя диска... имея одну громкость, которая составляет 24 ТБ, потребуется НАВСЕГДА для восстановления. (когда-нибудь пытался прочитать 3 ТБ данных, разбитых на 9 других дисках?) Было бы лучше иметь меньшие наборы рейдов и объединить их вместе, чтобы сформировать больший объем. Если диск выходит из строя, он не снижает производительность всего тома, в то время как все восстанавливается... а только производительность одного набора рейдов.

Кроме того, в зависимости от того, на каком веб-сайте вы работаете... (Linux/Windows/OSX/Solaris/???), также можно определять, какие инструменты вы используете, и какую конфигурацию вы используете.

Что вы подразумеваете под "одноразовым резервным копированием"? Если вы имели в виду "односторонний архив"... (т.е. новые файлы записываются на сервер резервного копирования..., но с него ничего не читается), я настоятельно рекомендую использовать rsync в средах со *nix (linux/unix/ и т. д.) или, если он основан на IIS (windows), используйте что-то вроде synctoy или xxcopy. Если вам нужна LIVE-копия (задержка 0 между тем, когда файл записывается, когда он появляется на другом сервере), вам нужно предоставить больше информации о вашей среде. Linux и Windows работают совершенно по-разному, а инструменты - на 100%. Для подобных вещей вы, вероятно, захотите взглянуть на кластерные файловые системы и, вероятно, должны больше ориентироваться на SAN, а не на хост-хранилище.

Как правило, мы используем RAID5 или 6 для резервных дисков, так как это дает лучший результат, если вы проигнорируете RAID 0:-), поэтому я бы пошел на это, а не на JBOD

Одна вещь, которую вы могли бы рассмотреть, это покупать ваши диски в отдельных партиях, а не во всех 20 сразу, так как если в партии есть производственный дефект, они могут выйти из строя в аналогичное время.

Вы также можете рассмотреть возможность использования зеркалирования, а не обычных резервных копий, если данные записываются только один раз - существует довольно много программных и аппаратных систем хранения, которые позволяют это настроить, и вы также можете воспользоваться преимуществами отработки отказа в случае вашего основного хранилища не работает.

HSM (Hierarchical Storage Manager) - это один из вариантов, который хорошо подходит для вашего варианта использования, особенно если ваши требования продолжают расти. Я установил несколько модулей HSM размером до 150 ТБ диска и 4 ПБ ленты.

Идея заключается в том, что HSM управляет жизненным циклом данных, чтобы снизить общую стоимость хранения. Данные изначально хранятся на диске, но почти сразу архивируются на ленту (что значительно дешевле на байт). Политики архивирования могут быть сконфигурированы для хранения нескольких копий на ленте для дополнительной безопасности, и большинство людей берут вторую копию вне офиса. Миграция на ленту и с ленты прозрачна для конечного пользователя - файлы по-прежнему отображаются в файловой системе.

Когда конечный пользователь запрашивает файл в будущем, данные автоматически переносятся с ленты и передаются пользователю. С ленточной библиотекой процесс подготовки добавляет только около минуты к времени поиска.

Одним из огромных преимуществ HSM является время восстановления в случае сбоя дисков или повреждения файловой системы. Если у вас когда-либо произойдет катастрофический сбой диска или файловой системы, вы можете просто найти еще диск и восстановить недавнюю резервную копию метаданных файловой системы (небольшая часть общего объема данных). В этот момент все данные доступны по запросу, как обычно.

При определении конфигурации рейда для san вам нужно беспокоиться о производительности, степени надежности и времени восстановления, которое вам требуется. Поскольку вы удваиваете количество записей четности (в зависимости от вашего особого вкуса в raid six), обычно лучше всего использовать san с пользовательскими ASIC для выполнения вычислений. Поскольку ваши данные статичны, вы по-настоящему беспокоитесь о том, как долго вы можете позволить себе находиться в ухудшенном состоянии в случае отказа одного из дисков. Также следует отметить, что накопители, как правило, выходят из строя, поэтому лучше устанавливать накопители с некоторым интервалом между наборами.

Что касается резервного копирования, я не вижу необходимости в избыточности в наборе резервных копий, поэтому JBOD хорош

В настоящее время у меня есть файловые системы в этом диапазоне масштабов, в настоящее время занимающие 58 ТБ, плюс отдельная копия вне сайта.

У меня было несколько сбоев дисков и да, чем больше дисков, тем дольше перестройка. Чтобы облегчить его, я разделил хранилище на несколько RAID-массивов, каждый из которых состоит из 5-7 дисков. В настоящее время это RAID5, но когда я получу диски емкостью 3 ТБ, я планирую начать использовать RAID6.

Все это объединено и разделено с LVM, поэтому мне не нужно думать о том, что и где, просто добавьте дополнительные коробки, когда это необходимо, и удалите старые диски, когда они слишком малы, чтобы оправдать занимаемые ими слоты.

Аппаратное обеспечение - это в основном блоки Coraid AoE (но некоторые цели iSCSI скоро присоединятся), управляемые с помощью LVM, файловые системы Ext3/4, если их размер меньше 4-6 ТБ, или XFS, если они превышают их (в настоящее время до 34 ТБ). Все резервные копии обрабатываются с rsync и DVD для автономного архива.

Помимо некоторого программного обеспечения для мониторинга (в основном Zabbix), оно практически не требует обслуживания.

Еще один момент, чтобы добавить к тому, что все говорят здесь. В Windows и огромных файловых системах, если вы решите разбить файловую систему, но хотите сохранить ту же файловую структуру, что и у вас, посмотрите на монтирование этих дисков в пути к папкам.

http://technet.microsoft.com/en-us/library/cc753321.aspx

Я удивлен, что никто не предложил использовать MogileFS ( github).

MogileFS автоматически зеркально отображает данные на разных серверах, и каждый диск - просто тупой диск "JBOD". Существует много производственных установок со многими ТБ (более 100) данных.

Для серверного оборудования существует множество вариантов "много дисков в корпусе". Например, Backblaze Pod (немного самостоятельной работы / не поддерживается) или сервер Super Micro (мы используем Silicon Mechanics. Я думаю, на wordpress.com они используют обычные серверы Dell 2U с корпусами MD1000 для дисков.