Я отвечаю за новый веб-сайт в нишевой отрасли, на котором хранится много данных (более 10 ТБ на клиента, скоро количество клиентов увеличится до 2 или 3). Мы рассматриваем возможность заказа дисков емкостью 3 ТБ на сумму около 5000 долларов (10 в конфигурации RAID 6 и 10 для резервного копирования), что даст нам примерно 24 ТБ хранилища для производственных данных. Данные будут записаны один раз и останутся неизменными в течение всего срока службы веб-сайта, поэтому нам нужно сделать резервную копию только один раз.
Я понимаю основы теории RAID, но у меня нет опыта в этом. Мой вопрос: звучит ли это как хорошая конфигурация? Какие потенциальные проблемы может вызвать эта установка?
Кроме того, как лучше всего сделать разовое резервное копирование? У вас есть два массива RAID 6, один для резервного копирования вне офиса, а другой для производства? Или мне следует сделать резервную копию производственного массива RAID 6 на JBOD?
РЕДАКТИРОВАТЬ: сервер данных работает под управлением Windows 2008 Server x64.
РЕДАКТИРОВАТЬ 2: Чтобы сократить время восстановления, что бы вы подумали об использовании двух RAID 5 вместо одного RAID 6?
В настоящее время я поддерживаю 220 серверов до 96 ТБ (всего 2 ПБ или около того), некоторые в кластерах до 240 ТБ, которые построила моя команда. Вот мои советы:
Честно говоря, я думаю, что 5 тысяч долларов за диски - это немного круто ... но это совсем другая тема. Настройка звучит неплохо, но в случае сбоя диска ... для восстановления одного тома размером 24 ТБ потребуется ВСЕГДА. (пробовали когда-нибудь прочитать 3 ТБ данных, разделенных на 9 других дисков?) Было бы лучше иметь меньшие raid-наборы и объединять их вместе, чтобы сформировать больший том. Если диск выходит из строя, это не снижает производительность всего тома, пока все восстанавливается ... а, скорее, только производительность одного набора рейдов.
Кроме того, в зависимости от того, на чем работает ваш веб-сайт ... (Linux / Windows / OSX / Solaris / ???) также может определять, какие инструменты вы используете и какую конфигурацию используете.
Что вы подразумеваете под «одноразовым резервным копированием»? Если вы имели в виду «односторонний архив» ... (т.е. новые файлы записываются на резервный сервер ... но с него ничего не читается), я настоятельно рекомендую использовать rsync в средах с добавлением * nix (linux / unix / и т.д ...), или если это IIS (Windows), используйте что-то вроде synctoy или xxcopy. Если вам нужна ЖИВАЯ копия (0 задержек между записью файла и его появлением на другом сервере), вам необходимо предоставить дополнительную информацию о вашей среде. Linux и Windows работают совершенно по-разному, и инструменты на 100% разные. Для подобных вещей вы, вероятно, захотите изучить кластерные файловые системы и, вероятно, должны больше ориентироваться на SAN, а не на хранилище на основе хоста.
Обычно мы используем RAID5 или 6 для резервных дисков, так как он дает лучшую отдачу, когда вы игнорируете RAID 0 :-), поэтому я бы пошел на это, а не на JBOD
Вы можете подумать о том, чтобы покупать диски отдельными партиями, а не все 20 сразу, как если бы в партии был производственный дефект, они могут выйти из строя в одно и то же время.
Вы также можете рассмотреть возможность использования зеркалирования, а не обычных резервных копий, если данные записываются только один раз - существует довольно много программных и аппаратных систем хранения, которые позволяют это настроить, и вы также можете получить преимущество аварийного переключения в случае вашего основного хранилища выходит из строя.
Один из вариантов, который будет хорошо соответствовать вашему варианту использования, особенно если ваши требования продолжают расти, - это HSM (Hierarchical Storage Manager). Я установил несколько HSM емкостью до 150 ТБ на диске и 4 ПБ на магнитной ленте.
Идея состоит в том, что HSM управляет жизненным циклом данных, чтобы снизить общую стоимость хранения. Данные изначально хранятся на диске, но почти сразу же архивируются на ленту (что намного дешевле за байт). Политики архивации могут быть настроены для хранения нескольких копий на ленте для дополнительной безопасности, и большинство людей берут вторую копию за пределами офиса. Переход на ленту и с нее прозрачен для конечного пользователя - файлы по-прежнему появляются в файловой системе.
Когда конечный пользователь запрашивает файл в будущем, данные автоматически возвращаются с ленты и передаются пользователю. В случае ленточной библиотеки промежуточный процесс увеличивает время извлечения только на минуту.
Одним из огромных преимуществ HSM является время восстановления в случае выхода из строя дисков или повреждения файловой системы. Если у вас когда-либо случился катастрофический сбой диска или файловой системы, вы можете просто найти еще один диск и восстановить последнюю резервную копию метаданных файловой системы (крошечная часть от общего объема данных). В этот момент все данные доступны по запросу, как обычно.
при определении конфигурации рейда для сана вы должны беспокоиться о производительности, степени надежности и времени восстановления, которое вам нужно. Поскольку вы удваиваете количество операций записи с контролем четности (в зависимости от вашего предпочтения в рейде шесть), обычно лучше всего выполнять вычисления в 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 и огромных файловых системах, если вы все же решите сломать файловую систему, но хотите сохранить ту же файловую структуру, что и у вас, посмотрите, как монтировать эти диски в пути к папкам.
Я удивлен, что никто не предложил использовать МогилеFS (github).
MogileFS автоматически зеркалирует данные на разных серверах, и каждый диск представляет собой простой диск "JBOD". Существует множество производственных установок с большим количеством ТБ (100+) данных.
Для серверного оборудования существует множество вариантов «много дисков в корпусе». Например, Стручок Backblaze (немного самостоятельной работы / не поддерживается, относительно) или сервер Super Micro (мы используем Кремниевая механика. Я считаю, что на wordpress.com используются обычные серверы Dell 2U с корпусами MD1000 для дисков.