Добрый день! Сегодня поговорим о том, как из-за роста объемов данных меняются требования к СХД и почему традиционные системы, которым мы привылки доверять, больше не могут справляться с расширением емкости и обеспечивать надежность хранения. Это мой первый пост после долгого перерыва, поэтому на всякий случай представлюсь — я Олег Михальский, директор по продуктам компании Acronis.
Если вы следите за трендами в индустрии, наверняка уже сталкивались с таким понятием как software defined anything. Эта концепция подразумевает перенос на уровень программного обеспечение ключевых функций ИТ-инфраструктуры, обеспечивающих ее масштабируемость, управляемость, надежность и взаимодействие с другими частями. Gartner называет Software Defined Anything в числе 10 ключевых трендов 2014 года, а IDC уже опубликовала специальный обзор сегмента Software Defined Storage и предсказывает, что в к 2015 году только коммерческих решений данного типа будет куплено на 1,8 миллиарда долларов. Именно про СХД этого нового типа пойдет речь дальше.
Для начала давайте обратимся к статистике роста объемов данных и сделаем некоторые выводы. Несколько лет назад объем создаваемых во всем мире данных превысил 1 зеттабайт – это примерно миллиард целиком заполненных жестких дисков емкостью 1 Тбайт, и уже превышает все доступное на сегодняшний день пространство хранения. Согласно прогнозу компании EMC – мирового лидера на рынке СХД, за текущее десятилетие объемы данных увеличатся еще в 50 раз, создав дефицит пространства для хранения
более 60%.
Рис.: Дефицит пространства для хранения создаваемой информации увеличивается
Источник: IDC The Digital Universe Decade – Are You Ready? (2010)
Сколько и почему?
В чем причины лавинооразного роста объемов информации:
- создавать новую информацию сейчас намного дешевле чем раньше: стоимость хранения и обработки снизилась в 6 раз с 2005 года
- бюджеты на ИТ за то же время увеличились в полтора раза
- к 2020 году в 8 раз возрастет количество устройств, которые создают информацию: начиная от смартфоном и камер с более высоким разрешением и заканчивая всевозможными датчиками и умными персональными устройствами
- дополнительная информация создается в виде производной от уже созданной — в первую очередь это бэкапы, а также логи, архивы цифрового аудио, видео
В свою очередь недостаток пространства для хранения объясняется тем, что аппаратные СХД долгое время эволюционировали по принципу быстрее, выше, сильнее — то есть от ленты к дискам большей емкости, более быстрым дискам, накопителям на флеш-памяти, системам из нескольких полок с накопителями разного типа и скорости. А оптимизация СХД затачивалась под нужды компаний с большими бюджетами — быстрый сторадж для виртуализации, супер-быстрый сторадж для обработки данных в реальном времени, умный сторадж с оптимизацией под конкретные бизнес-приложения. В то же время про бэкапы, архивы и логи которые не создают напрямую стоимость для бизнеса и просто занимают место, заказчики как бы забыли, а производители СХД не подумали (назовите вендора аппаратной СХД, которая продается специально как «самая дешевая и надежная СХД для бэкапа ваших данных»).
You're doing it WRONG
Из практики мне, например, известны случаи когда бэкапы и логи хранятся сотнями терабайтов на полках брендовых вендоров, предназначенных для оперативного хранения данных бизнес-приложений, или же наоборот — на самодельном JBOD размером несколько петабайт, половина из которых — это полная вторая копия «для надежности». В результате парадокс: стоимость хранения данных (на уровне 10-15 центов за гигабайт в месяц) превышает в несколько раз стоимость хранения в облаке типа Амазон, возможности железа по обработке этих данных не используются, а надежность необходимая для резервного копирования и длительного хранения — наоборот, не обеспечивается. (про надежность разберем чуть ниже). В случае же с JBOD возрастают и издержки на его поддержку и расширение. Но как уже отмечено выше, у компаний эта проблема долгое время была не на первом плане.
Развитие в правильном направлении
Не удивительно, что первыми заметили проблему разработчики и инженеры, которые непосредственно связаны с большими массивами данных — такими какие есть в Google, Facebook, а также в научных экспериментах типа известного адронного коллайдера. И стали решать ее доступными им программными средствами, а потом делиться своими наработками в публикациях и на конференциях. Возможно, отчасти поэтому сегмент Storage в Software Defined Anything быстро оказался заполнен большим количеством open-source проектов, а также стартапов, которые стали предлагать узкоспециализированные решения под конкретный тип проблемы, но снова обходя бэкапы и долговоременные архивы стороной.
Надежность хранения вынесена в заголовок статьи, и мы сейчас дополнительно разберем почему хранение большого количества данных на обычных СХД становится не только затруднительно по мере роста данных, но и опасным — что особенно важно для бэкапов или логов (куда, кстати, относятся и архивы видеонаблюдения), которые могут пригодиться редко, но зато по крайне важному поводу — например для проведения расследования. Дело в том, что в традиционных СХД, чем больше данных становится, тем выше издержки на хранение и риски потери данных в результате аппаратного сбоя.
Расчёты и занимательная статистика
Установлено, что в среднем жесткие диски выходят из строя с вероятностью 5-8% в год (данные Google). Для СХД емкостью в петабайт это означает выход из строя нескольких дисков в месяц, а при размере хранилища в 10 петабайт, диски могут выходить из строя каждый день.
Рис. Как выходят из строя жесткие диски. (Данные Goolge)
Пример: Использование RAID 5 с учетом вероятности ошибки чтения 10-15 на бит означает возможную потерю реальных данных при каждом 26-ом восстановлении или раз в несколько месяцев. Например, если в системе есть 10 тыс. дисков и среднее время между ошибками составляет 600 тыс. часов для одного диска, то восстановление дисков потребуется проводить каждые несколько дней. (на основе данных из статьи Oracle)
Нужно заметить, что системах на основе RAID восстановление сбойных дисков происходит с ограничениями. И время восстановления зависит в том числе от размера диска. Чем больше диск, тем дольше он восстанавливается, увеличивая вероятность повторного сбоя, ведущего к потере данных. Таким образом, с ростом рамера дисков и объема пространства СХД, надежность падает. Кроме того, встречаются ошибки, которые не детектируются на уровне RAID. Для тех, кто хочет больше подробностей — отличный обзор проблем RAID опубликован на Хабре тут.
Добавим к этому, что согласно исследованию компании NetApp, в среднем один из 90 дисков имеет скрытое повреждение, связанное с контрольными суммами, ошибками записи в блоки или неправильными битами четности, которые в традиционных СХД не обнаруживаются. Как показывает другое исследование, такие ошибки не способны обнаруживать и традиционные файловые системы. Вероятность даже самых распростарненных из этих типов ошибок мала. Но по мере роста массива данных вероятность потери также возрастает. СХД перестает обеспечивать надежность хранения.
Аппаратных средств обеспечения надежности, справлявшихся с ограниченными объемами данных, для надежного хранения сотен терабайт и петабайт оказывается недостаточно.
Software Defined Storage
Исходя из этих предпосылок и накопленного опыта работы с растущими объемами данных стала развиваться концепция Software Defined Storage. Первые наработки, которые появились в этоф сфере, не ставили во главу угла какую либо одну проблему, как например надежность. Руководствуясь потребностями своих собственных проектов разработчики Google, например, одновременно решали пытались решить несколько задач: обеспечение масштабируемости, доступности, производительности и, в том числе, надежности при хранении большого количества данных, используя недорогие типовые (commodity) комплектующие, такие, как, например десктопные жесткие диски и небрендовые шасси, которые чаще дорогих марок выходят из строя.
Поэтому файловую систему Googler (GFS) можно считать в некотором роде прародительницей класса решений, о котором пойдет речь ниже. Другие команды разработки, такие как в open source проектах Gluster (позднее вошла в состав RedHat) и CEPH (ныне поддерживается компанией Inktank) ориентировались преимущественно на достижение высокой производительности при доступе к данным. Этот список будет неполным без HDFS (Hadoop filesystem), которая появилась на основе разработок Google и ориентирована на высокопроизводительную обработку данных. Список можно продолжать, но полробный обзор существующих технологий выходит за ракми этой статьи. Замечу только, что проблема оптимизации долговоременного хранения в чистом виде не ставилась в приоритет, а решалась как бы по ходу дела в процессе оптимизации стоимости решения в целом.
Понятно, что создание коммерческого решения на базе open source — эксперимент сложный и рискованный и пойти на него сможет только крупная компания или системный интегратор, которые имеют достаточно экспертизы и ресурсов, чтобы работать со сложным в установке, интеграции и поддержке кодом opensource и имеют достаточную коммерческую мотивацию для этого. Но как уже было сказано выше, у коммерческих вендоров основная мотивация направлена на такие высокобюджетные сферы как СХД с высоким быстродействием для виртуализации или параллельной обработки данных.
Готовые решения
Ближе всех к решению проблемы с недорогим и надежным хранением подошли стартапы, которые сфокусировались на предоставлении облачного бэкапа, но многие из них уже сошли с дистанции, а другие были поглощены крупными компаниями и перестали вкладываться в развитие технологии. Лучше всего продвинулись такие вендоры как BackBlaze и Carbonite, сделавшие ставку на разворачиваниии облачного хранилища в своих собственных датацентрах на основе типовых комплектующих и сумевшие закрепиться на рынке по своими облачными сервисами. Но и они, в виду крайне высокой конкуренции на своем основном рынке, не продвигают активно технологию хранения как самостоятельное решение класса Software Defined Storage. Во-первых, чтобы не создавать конкурентов, во-вторых чтобы не распылять свои ресурсы на совершенно разные направления бизнеса.
В результате перед администраторами СХД, которые отвечают в том числе за хранение бэкапов, логов, архивов систем видеонаблюдения, телепередач, записей голосовых звонков, стоит проблема выбора: с одной стороны, есть удобные но дорогие решения, которыми при наличии достаточного бюджета легко закрыть текущие потребности в хранении 100-150ТБ данных. И это будет надежно и безопасно — как говорят в индустрии, за покупку железа от крутого вендора еще никого не уволили. Но как только емкость СХД превышает порог в 150-200ТБ данных, проявляются проблемы с дальнейшей расширяемостью — для того, чтобы объединять все железо в единую файловую систему, свободно перераспределять пространство, обновлять жесткие диски на диски большей емкости, возникают дополнительные расходы на миграцию, дорогие комплектующие и специализированный софт для «виртуализации СХД». В результате по стоимости владения такая система с течением времени становится далека от оптимальной для «холодных данных». Другая альтернатива — собрать СХД самому на основе Linux и JBOD возможно, подойдет специализированной компании типа хостера или телеком-провайдера, где есть опытные и квалифицированные специалисты, которые возьмут на себя ответственность за работоспособность и надежность собственного решения. У обычной же компании среднего или небольшого размера, основной бизнес которой не связан с хранением данных, скорее всего нет бюджета на дорогое железо и квалифицированных специалистов. Для таких компаний интересной альтернативой может стать собственная разработка Acronis — Acronis Storage — программное решение, которое позволяет быстро развернуть высоконадежную и легко расширяемую СХД на недорогих типовых шасси и дисках, которые можно произвольно сочетать друг с другом, менять по одному на «горячей системе», увеличивая пространство произвольными блоками от нескольких терабайт до нескольких десятков или сотен терабайт, пользуясь по сути только навыками сборки ПК и интуитивно понятным неспециалисту веб-интерфейсом для конфигурации и мониторинга всей СХД и отдельных ее узлов и дисков. Эта разработка стала результатом внутреннего стартапа Acronis по облачному хранилищу для резервных копий, которое сейчас уже расширилось до нескольких петабайт в трех датацентрах.
Обзор подходов к хранению большого количества данных не будет полным без упоминания решений, которые построены на базе ПО, но поставляются на рынок в виде аппаратно-программных комплексов (appliances). В некоторых случаях, это дает возможность быстро развернуть решение и может подойти не очень большой компании с ограниченными ресурсами. Но использование предопределенной аппаратной конфигурации ограничивает возможности по тонкой настройке системыи и, естественное, задает более высокий чем для чистого ПО порог цены решения, в которую уже включена аппаратная часть. И, конечно же, такой подход наследует многие определенные аппаратных СХД в части апгрейда одного сервера (scale-up путем замены дисков на более емкие и быстрые, замены сети на более быструю).
В заключении еще раз обратимся к данным аналитиков по индустрии СХД и зафиксируем несколько выводов. Согласно исследованию Forrester Forrsights Hardware Survey, проведенному в конце 2012 года, у 20% компаний объемы бэкапов уже тогда расли на 100ТБ в год, а сложность расширения СХД под нужды бэкапов стала проблемой для 42% опрошенных. Компания компании рознь, но эти данные дают повод специалистам задуматься над долгосрочным планированием емкости СХД которая может понадобиться в их организации в перспективе нескольких лет. В предположении, что по хранению бэкапов все компании примерно похожи друг на друга, то почти у половины из них в ближайшие годы встанет проблема оптимизации СХД для бэкапов, а возможно такие и других холодных данных. Приведенные данные о традиционных СХД на базе RAID говорят о том, что для повышения надежности и оптимизации стоимости хранения «холодных данных» в процедуру выбора СХД стоит включить альтернативные новые решения класса Software Defined Storage, которые которые лучше справляются с задачей масштабируемости и дают администраторам больше гибкости и свободы выбора при обслуживании и расширении хранилища.
Автор: olegmikh
