Программно-определяемое хранение: чего ожидать в 2020 году?
Программно-определяемое хранение (Software-Defined Storage, SDS) обещало избавить нас от забот об используемом оборудовании, сделав все «независимым от аппаратного обеспечения», не допуская привязки к конкретному производителю и позволяя заказчикам снижать расходы. Это был отличный выбор для удаленных офисов и филиалов. Однако SDS не удалось воплотить свои намерения по ряду причин.
Тесная связь между вычислениями и хранением вынуждает заказчиков использовать количество узлов SDS, определяемое по наивысшему общему знаменателю. Например, если для вычислений необходимо только пять узлов, но для удовлетворения требований к емкости требуется десять узлов, то в итоге приобретается десять узлов. Результат? Приходится платить не только за оборудование, но и за лицензию гипервизора, электропитание, охлаждение, место в стойке и т
Необходимость повышения производительности подтолкнула решения SDS к использованию узлов All-Flash. В то же время ограниченная надежность одного узла приводит к необходимости хранения как минимум двух копий данных. Это означает, что клиенты должны приобретать большие объемы достаточно дорогих (Flash) носителей.
И вероятно, самое важное. SDS не выполнило обещание сделать нас «независимыми от аппаратного обеспечения», поскольку любое новое оборудование все еще требует серьезной работы по интеграции. Когда это происходит в большом масштабе, некачественная интеграция приводит к увеличению отказов и количества сбоев в работе бизнеса, повышению нагрузки на ИТ-команду. При этом многим поставщикам SDS не хватает надежности, широкого опыта внедрения, поддержки различных экосистем и возможностей для тестирования, необходимых для перемещения данных из массивов с критически важными приложениями в центрах обработки данных. По сути, заказчики должны сами стать системными интеграторами. После того как они наконец-то добились бесперебойной работы аппаратного обеспечения, его замена становится сложной и дорогой. Покупка же оборудования и программного обеспечения SDS у разных поставщиков, если для этого есть веские финансовые или стратегические причины, зачастую ведет к ситуациям, когда при возникновении проблем вина с одного производителя перекладывается на другого. В итоге заказчики по-прежнему зависят от аппаратного обеспечения.
Где же решения SDS работают хорошо? Там, где не требуется масштаб. Многие компании используют SDS в своих магазинах с двумя-тремя серверами, предназначенными для работы всего торгового пространства. Некоторые пользователи «Интернета вещей» (Internet of Things, IoT) используют решения SDS на периферии для запуска локальных вычислений, чтобы обеспечить своим IoT-устройствам и мобильным пользователям минимальную задержку. Во всех этих случаях вычисления и хранение распределены по множеству локаций, что почти диаметрально противоположно логике работы центра обработки данных. Попытка построить трехуровневую (вычисления, сеть, хранение) архитектуру в каждом розничном магазине будет ОЧЕНЬ неэффективной. Это место, где решения SDS отвечают требованиям необходимого масштаба.
В этом плане SDS напоминает маленький мотоцикл, точно подобранного размера и оптимизированный для доставки небольших пакетов по городу, – заметная экономия топлива, управление одним человеком, маневренность, позволяющая не стоять в пробках. Однако, когда вы беретесь за работу в другом масштабе, например, перевозите контейнер, то не арендуете 50 мотоциклов. Вы разрабатываете новый инструмент для нового масштаба – с дизельным двигателем вместо бензинового, чтобы получить больше мощности, с одним водителем, а не с пятьюдесятью, с правильной экономией топлива. Использование неправильного инструмента – это дорого. Представьте вместо мотоцикла огромный грузовик, доставляющий небольшой пакет.
Чего ожидать в 2020 году?
Мы по-прежнему будем наблюдать, как небольшие заказчики уходят из центров обработки данных в облако, так как планируют получить определенный уровень эффективности, стабильности и простоты использования, которые недоступны в локальной инфраструктуре без эффекта масштаба. Мы также увидим, как крупные компании, которые уже перенесли часть приложений в облако, вкладывают больше средств в собственное частное облако, поскольку осознают, что при увеличении масштаба стоимость размещения всех ресурсов в публичном облаке заметно повышается. Такой подход не приемлем для оплаты всей инфраструктуры в долгосрочной перспективе.
Компаниям необходимо провести стратегическую грань между тем, как и когда они используют публичное и частное облако для хранения данных. Это решение потребует тщательной оценки гибкости, удобства управления и переноса данных, скорости выхода на рынок и стоимости, предлагаемой каждым подходом. Это будет зависеть не только от количества устаревших данных, которые по-прежнему должны храниться, но и от того, какие данные компании захотят хранить локально. Не вся информация пригодна для размещения в публичных облаках как по сути бизнес-задач, так и из-за политик безопасности и необходимости соблюдения законов Российской Федерации в области хранения персональных данных.
Мы увидим изменение и в том, как заказчики будут приобретать компоненты частного облака. Компаниям необходима гораздо большая гибкость и вариативность облачных моделей потребления, но в то же время у многих команд управления есть потребность продолжать использовать модель CapEx и избегать OpEx, а публичные облака предлагают только модели потребления OpEx. Это заставит клиентов искать способы повышения гибкости локально благодаря партнерству с поставщиками, которые предлагают им модели pay-as-you-grow, но в то же время не ставят жестких условий по выкупу дополнительных ресурсов.
Что движет бизнес-потребностями производителей?
Поскольку рост данных не прекращается, крупные организации будут испытывать на себе повышенное давление, они должны четко понимать затраты и выгоды для различных моделей хранения, ведь объем создаваемых, совместно используемых и хранимых данных увеличивается в геометрической прогрессии. Компании должны будут пересмотреть решения для частного облака, если они хотят предложить альтернативу публичному облачному хранилищу, которое не является слишком дорогостоящим. Оно, безусловно, оказалось и не таким дешевым, как, возможно, ожидали предприятия, но в чем его плюс?
Гибкость. Рынок теперь сместился в сторону повышения ценности гибкости и времени вывода на рынок, в этом контексте они взаимозаменяемы. Недавно мы встретились с телеканалом, который решил в середине сезона реалити-шоу предоставить зрителям возможность загружать свои видеофайлы, подражая участникам шоу. Этот проект должен был быть реализован в течение двух недель, иначе канал потерял бы аудиторию. Если вы не сможете осуществить подобные проекты локально, в своем частном облаке, это будет означать, что потребуется потратить больше денег (и в OpEx) лишь потому, что вы не подумали о гибкости в своем частном облаке.
Каковы реалии рынка?
Заказчики ищут способы эффективного масштабирования, не дожидаясь на протяжении нескольких недель или месяцев поставок оборудования, и, что более важно, не дожидаясь долгих и неэффективных циклов закупок. При этом чаще всего заказчики по-прежнему приобретают инфраструктуру в нынешнем гибком мире так же, как это делали компании в 1970-х годах, но удивляются, когда узнают, что они недостаточно гибки.
Однако любой подход, который не предусматривает изначальную поставку клиенту оборудования с запасом и его потреблением по мере необходимости, не решает проблему, потому что производство, доставка, установка и настройка нового оборудования занимает слишком много времени исходя из требований современного бизнес-мира.
Перспектива конечного пользователя
Конечным пользователем здесь является бизнес-единица. Все хотят, чтобы все было сделано вчера или в худшем случае сегодня, и не допускают длительных сроков закупок и внедрения, а также желают мгновенных результатов. ИТ-отдел может потратить время, объясняя, почему это сложно, и увидеть, как бизнес-подразделения переносят свои приложения в облако. Обходя ИТ, они не только тратят деньги, но и обходят процессы управления данными, которые, по мнению аналитиков, существуют локально и отсутствуют в облаке. То есть повышение уровня взаимодействия между ИТ-отделом и бизнес-единицами по-прежнему должно быть главным в повестке дня Лидеры должны принимать обоснованные бизнес-решения относительно хранения данных. Выбор между частными и публичными облаками должен быть обусловлен не ажиотажем, а тем, что подходит компаниям с точки зрения затрат, приемлемых для долгосрочной жизнеспособности бизнеса, и форм финансирования (CapEx или OpEx, схема сотрудничества «оплата по мере использования» и т. д.).
Итак, SDS решает проблемы гибкости и простоты в небольших масштабах. Различные инструменты, такие как репликация VMware vSphere, позволяют заказчикам легко использовать SDS в удаленных офисах и филиалах и более масштабируемые среды в главном центре обработки данных. Основную конкуренцию решениям SDS в небольших масштабах составляют публичные облака, которые предлагают сравнимый уровень эффективности, стабильности и простоты эксплуатации.
При построении же больших сред решения SDS зачастую теряют свою привлекательность, вынуждая заказчиков наращивать внутреннюю компетенцию и становясь собственными системными интеграторами. Неравномерность рабочей нагрузки, высокие требования к надежности и необходимость интеграции с существующими платформами значительно повышают сложность и стоимость внедрения SDS.
В то же время при увеличении масштаба сред экономическая эффективность использования публичных облаков для всех сервисов снижается. Как правило, оптимальным выбором является стратегия гибридного облака, вопрос лишь в определении границы между публичным и частным облаками. Использование таких схем финансирования, как «оплата по мере использования», позволяет повысить гибкость частного облака до сравнимого с публичным уровня и снизить затраты.
Из всего вышесказанного следует главный совет для пользователей — используйте правильный инструмент для правильного масштаба.
Опубликовано 03.03.2020