Почему в преддверии эры зеттабайтов компании должны переходить на открытую среду?

Рост объема данных идет вверх по крутой траектории, и, по прогнозами International Data Corporation (IDC), в 2023 году во всем мире будет сгенерировано 103 зеттабайта информации. По мере дальнейшего распространения 5G IoT-устройств и существенного роста видео компании будут адаптировать свои технологии хранения данных и извлечения из них ценной информации, и пока мы едва только соприкоснулись с этим процессом. Хотя об одном уже можно говорить с уверенностью: совершенно очевидно, что, находясь на пороге эры зеттабайтов, компании должны пересмотреть свои подходы к архитектуре ЦОД, чтобы в будущем идти в ногу с такими трендами.

Прежде всего, что такое зеттабайт? Зеттабайт – это триллион гигабайтов. Это очень много данных, но – в отличие от гигабайта или даже терабайта – слово «зеттабайт» на слуху далеко не у всех, и причина может крыться в том, что необходимость хранить такой объем информации в коммерческих целях возникает редко. Но так будет не всегда.

Инновации, продукты и требования в период этого нового архитектурного сдвига будут зависеть от нескольких ключевых факторов.

Первый: необходимость дезагрегировать вычислительные системы, СДХ и сетевые ресурсы, чтобы максимально эффективно и оптимально использовать каждый их этих компонентов. Дезагрегация – это единственный способ справиться с объемом, скоростью и разнообразием данных, которые, вне всякого сомнения, принесет с собой наступление эры зеттабайтов.

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

Третий: все различные элементы процесса должны сопрягаться друг с другом и интеллектуально обрабатывать данные. Следует настроить взаимодействие между аппаратным оборудованием и программным обеспечением, но чтобы правильно разработать и оборудование, и ПО, необходимо хорошо разбираться в полном комплекте технологий, только тогда получится максимизировать производительность и функционал всего комплекса.

При проработке возможных решений, которые могли бы удовлетворить потребности следующего десятилетия, связанные с работой с данными, представляется важным получить обратную связь от профессиональных сообществ разработчиков открытого ПО и ПО под Linux® о ключевых технологиях, лежащих в основе черепичной магнитной записи (SMR). При SMR дорожки данных размещаются на диск друг над другом, за счет этого производители оборудования могут увеличить емкость примерно на 20%. Это возможно только при последовательной записи верхней дорожки данных, тогда нижняя дорожка не изменяется.

Для многих гипермасштабируемых решений последовательная запись станет подходящим вариантом, поскольку крупномасшабные рабочие задачи, например, потоковая передача видео, реализуются по принципу однократная запись/многократное считывание. Но повышение производительности для внедрения SMR требует переделки архитектуры на стороне оконечного хоста: нужно изменить операционную систему для последовательного размещения записей или даже разрешить приложению видеть, что данные пишутся последовательно.

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

Сравнение HDD-накопителей с поддержкой технологии SMR и SSD-накопителей может показаться странным, потому что во многих отношениях эти технологии концептуально очень далеки друг от друга. Однако если взглянуть на SSD-накопители и NAND в контексте их места в дезагрегированном будущем, можно обнаружить технологию, сопутствующую SMR/HDD, она называется зональные пространства имен (Zoned Namespaces, ZNS).

Накопители с NAND-памятью рассчитаны только на определенное количество удалений и записей и, следовательно, ими нужно управлять. Слой Flash Translation Layer (FTL) рационально управляется со всем – от кэша до производительности и позволяет выровнять износ. Однако в масштабах зеттабайтов такое управление на уровне устройства вводит промежуточный уровень между хостом и конкретным накопителем, который негативно сказывается на пропускной способности, задержке и стоимости.

Но в новую эру компании захотят держать эти показатели под контролем и максимально повышать эффективность работы, поэтому эта функция управления должна быть передана с уровня устройства на уровень хоста, и суть подхода SMR заключается именно в этом.

ZNS делит флеш-накопитель на зоны, и каждая зона становится изолированным пространством имен. Поставщики облачных решений могут, например, распределять разные типы рабочих нагрузок или данных в разные зоны, получая тем самым возможность выявлять предсказуемые схемы использования у определенного числа пользователей. Но еще важнее то, что данные пишутся в зоне последовательно, как и в черепичной магнитной записи. И вдруг потребность во всем этом управлении накопителями просто отпадает. Итого:

• дополнительная экономия, поскольку нет необходимости раздувать «парк» NAND-флеш-накопителей;

• продление срока службы диска за счет уменьшения избыточной записи;

• значительное уменьшение задержки;

• серьезное увеличение пропускной способности.

Пока компании готовятся к увеличению информационных потребностей, важная роль отводится таким инициативам, как Zoned Storage, работающим с профессиональным сообществом для утверждения ZNS в качестве открытого стандарта, который может использовать те же сопряжения и интерфейс программирования приложений (API), что и SMR. Этот этап позволит пользователям использовать единый интерфейс для обращения к уровню хранения целиком. В результате архитекторам ЦОД будет проще перейти на архитектуры, исчисляемые зеттабайтами, поскольку им не придется менять приложения, чье бы решение для СХД они ни выбрали. Использование дезагрегированных специализированных и умных архитектур позволит компаниям найти новый баланс между производительностью, задержкой и затратами.