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

В наши дни практически невозможно прочитать статью о разработке приложений, в которой не упоминалась бы концепция контейнеров — переносимых, автономных программных пакетов, содержащих все необходимое для приложения. Это особенно актуально для нативных облачных сред, которые быстро стали лидерами в плане разработки приложений. По данным Gartner, в 2022 г. более 95% новых цифровых рабочих нагрузок будут развернуты на нативных облачных платформах — по сравнению с 30% в 2021 г.

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

Что такое хранилище на основе контейнеров?

Хранилище на основе контейнеров предназначено для распределенных баз данных и приложений. Оно включает в себя все необходимые части среды хранения внутри контейнера, без зависимостей. Это означает, что хранилище не зависит от инфраструктуры и может быть легко перемещено между средами.

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

«Традиционно тома хранения должны создаваться администратором хранилища заранее, но в нативной облачной среде главное — самообслуживание по требованию», — объясняет Гутам Рао, главный технолог Portworx компании Pure Storage.

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

Именно поэтому многие организации, применяющие контейнеры, внедряют хранилища, управляемые непосредственно контейнерами — в большинстве случаев Kubernetes. Чтобы это работало, в отрасли был разработан интерфейс контейнерного хранилища (CSI), который управляет распределением и предоставлением хранилища. CSI, по сути, создает коммуникационный путь между контейнером и подсистемой хранения нативно-облачного уровня. CSI также определяет класс хранилища, который несет в себе все необходимые свойства, такие как общие тома, объектное хранение или NVMe. Таким образом, создается постоянный том, который привязывает конкретные тома хранения к конкретным контейнерам, независимо от того, где контейнер работает в кластере.

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

«Kubernetes автоматически создает требования к постоянным томам на основе желаемого профиля, политики или желаемой статистики, — говорит Майкл Кейд, старший глобальный технолог компании Veeam. — Затем он может использовать эту методологию для выбора наилучшего хранилища для вашего приложения или данных».

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

Советы по выбору хранилища на основе контейнеров

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

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

Также важно придерживаться принципа «безопасность в первую очередь». Хотя контейнеры могут обладать преимуществами в плане безопасности, они не являются безопасными по своей сути.

«В хранилищах, управляемых Kubernetes, часто имеются постоянные тома, которые могут быть связаны [с] или прикреплены к поду — вычислительному ресурсу, или единице Kubernetes, — отмечает Гэри Огасавара, технический директор Cloudian. — Даже если вы удалите под, постоянный том под ним не будет удален, поэтому, хотя пользователь может подумать, что его базовое хранилище удалено, это не так. Это очевидная проблема безопасности, с которой рано или поздно сталкиваются почти все пользователи Kubernetes».

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

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

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

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

Полный вперед

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

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

«Хранилище часто является наименьшим общим знаменателем в дата-центре, но вы ведь не хотите низводить Kubernetes до этого статуса, — говорит Рао. — Если, например, вы все еще создаете хранилище вручную, все остальное будет тормозиться из-за этой медленной части».

Хотя переход на контейнерное хранение данных является практическим шагом, он также означает изменение вашего мышления.

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