Я новичок в этой теме, так что извиняюсь за глупые вопросы.
У меня есть школьный проект, и я хочу знать, как хранить 250 ТБ данных с жизненным циклом в течение 18 месяцев. Это означает, что каждая запись хранится 18 месяцев и по истечении этого периода может быть удалена.
Есть 2 проблемы:
Из-за большого количества данных мне, вероятно, придется объединить ленты с данными и жесткие диски. Я хотел бы иметь «быстрый» доступ к данным трехмесячной давности, поэтому на диске ~ 42 ТБ. Я действительно не знаю, какой RAID мне следует использовать, или есть ли лучшее решение, чем объединение диска и лент данных?
Спасибо за любой совет, статью, что угодно. Я заблудился.
250ТБ - это много данных. Я приведу вам пример того, как я бы выполнил эту задачу на предприятии, которое было бы в значительной степени связано с бюджетом (поскольку я предполагаю, что вы хотите это по дешевке), но не слишком озабоченным поиском лучших бесплатных продуктов для выполнения этой работы. .
Просто к вашему сведению - я пишу это как 8-летний профессионал как в мире хранения, так и в мире резервного копирования / аварийного восстановления.
Я чувствую, что этот школьный проект больше о том, чтобы писать о том, как это сделать, а не о том, как это делать на самом деле?
Прежде всего, хранилище.
Поскольку вы не упомянули какие-либо конкретные требования к доступности или избыточности, я бы предложил создать базовый JBOD массив "NearLine«Диски SATA емкостью 3 ТБ. По вашей оценке в 42 ТБ онлайн вам потребуется как минимум 14 из них, не считая накладных расходов RAID. Например, если вы выбрали RAID-6 при размере группы в 16 дисков вам потребуется не менее 16 дисков, чтобы получить полезную емкость 42 ТБ, и у вас все равно не будет горячего резерва. Пока я не получил лучшего представления о ваших требованиях к надежности, производительности, избыточности и доступности, я не мог рекомендовать другие типы дисков, типы рейдов или контроллеры.
В очень простой форме вы можете построить такой массив, используя довольно дешевое обычное оборудование и Linux вместе с некоторыми инструментами с открытым исходным кодом, такими как LVM, FreeNas, OpenFilerи т. д. - помимо этого, вы начинаете переходить на дорогие корпоративные хранилища.
Также имейте в виду, что использование для этого дешевого стандартного оборудования не влияет на другие проблемы с избыточностью, помимо дисков (блоки питания, контроллеры, операционная система и т. Д.).
Я предполагаю, что в корпоративной сфере вам потребуется существенная производительность чтения / записи и высокая доступность. В качестве примера - вы можете использовать массив хранения NetApp Enterprise с высокодоступными кластерными избыточными контроллерами. К ним будут прикреплены ящики с 24 дисками SAS 600 ГБ 15 тыс. Об / мин. Чтобы получить 42 ТБ из такой установки, которая будет работать очень хорошо и быть высокодоступной / избыточной, вам понадобится (при условии, что агрегаты NA с 64-битным размером с ограничением размера выше 16 ТБ) агрегат, содержащий примерно 5 16 дисковых групп рейда, если вы настроен на уровне рейда RAID6-DP по умолчанию.
Это не менее 80 дисков SAS 15 тыс. Об / мин 600 ГБ на 4 полках хранения, подключенных к избыточным массивам.
На данный момент вам нужны стойки, серьезное питание и охлаждение, а ваш бюджет превышает 200 тысяч долларов.
Теперь о архивировании.
Здесь у вас есть множество вариантов, существует буквально бесчисленное множество продуктов и методов, которые вы можете использовать для выполнения этой части вашей задачи. Таким образом, я собираюсь написать его с точки зрения использования конкретного приложения, которое, как я знаю, может хорошо выполнять эту работу, IBM Tivoli Storage Manager (TSM). Я также предполагаю, что у вас нет требований к удаленному аварийному восстановлению, и вам просто нужно хранить много данных, а диск стал слишком дорогим на данный момент.
Поэтому для настройки TSM вам понадобится другой сервер, а также некоторое количество ленточных накопителей и / или автоматизированная ленточная библиотека (ATL).
Сервер, на котором монтируются данные, будет иметь клиент TSM, и вы можете запланировать стандартные задания резервного копирования или архивирования в зависимости от ваших потребностей. Это запланированное задание может быть написано сценарием или иным образом настроено для архивирования данных на ленту с последующим удалением их с диска, что делает их доступными на ленте в автономном режиме. Например, вы можете сделать так, чтобы сценарий заархивировал на ленту любые данные старше 90 дней, а затем удалил их. Это еще одна область, где существует бесчисленное множество способов выполнить эту задачу.
Что касается аппаратной части - лента LTO может быть лучшим вариантом, а LTO-5 может хранить около 1,5 ТБ несжатых данных на картридж. Итак, поскольку вам нужно более 200 ТБ данных для хранения на ленте с остальными ~ 50 ТБ на диске, вам потребуется как минимум 140 лент для этого проекта.
Собираем все вместе
Итак, у нас есть некий массив хранения и «инфраструктура резервного копирования». Предположим, что весь этот жизненный цикл происходит на одном сервере. Вам нужен способ связать все это вместе. Будет ли диск быть подключен к серверу через SAN? По сети? Какой протокол вы будете использовать? Все эти решения влияют на то, какое оборудование вам понадобится. Просто глядя на требования к ленте, вам, вероятно, понадобится хотя бы небольшой ATL, который в значительной степени гарантирует, что вам понадобится волоконный канал. SANвместе с коммутаторами SAN, адаптерами и т. д. Вам понадобится сетевая инфраструктура поверх этого для любых требований к сетевой связи.
Чем больше я писал, тем больше я понимал, что этот проект не может быть реальным, и я становился все менее и менее конкретным. Имейте в виду, что это было написано с рядом диких предположений и очень консервативных оценок - версия TL; DR - вам понадобится тонна оборудования, множество знаний и много денег, чтобы сделать это, даже если это будет сделано в самый ненадежный, дешевый способ. Если вам нужна дополнительная помощь или информация, не стесняйтесь связаться со мной.
Поскольку это школьный проект, я предполагаю, что вам не нужно его создавать, просто укажите его. В любом случае вам следует прочитать эти две статьи:
Петабайты в рамках бюджета, версия 2.0: раскрывая больше секретов