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

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

Синхронная репликация (или зеркалирование) может выполняться только на небольших расстояниях из-за проблем со скоростью света / задержкой. Он наиболее популярен в Европе, где все «поближе». Асинхронная репликация более привлекательна для рынка, поскольку потенциально может охватывать весь земной шар и не страдает от тех же требований к задержке.

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

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

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

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

Что-то должно управлять этим

«Все преимущества гибкости и эффективности, которые дает Kubernetes, великолепны, но платформа Kubernetes не похожа на гипервизор и виртуальные машины», – говорит Питер Брей, директор по маркетингу служб данных в Red Hat, чей дистрибутив OpenShift Kubernetes является самым лучшим. популярная коммерчески поддерживаемая реализация стека Kubernetes.

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

Постоянное хранилище, присущее Kubernetes, имеет трехкомпонентную модель, называемую ReadWriteOnce, ReadOnlyMany и ReadWriteMany, которые сокращенно обозначаются как RWO, ROX и RWX соответственно. (X означает переменную на современном маркетинговом языке, как это было в алгебре средней школы.) Эти API-интерфейсы RWO, ROX и RWX накладываются на фактическое хранилище – будь то объектное хранилище NFS или Ceph в случае Red Hat OpenShift – и создают постоянные тома для контейнеров, в которые можно выгружать данные и пережевывать их.

На заре коммерческих установок Kubernetes драйверы хранилища были встроены в код Kubernetes; это вызвало множество неприятностей, связанных с приведением драйверов в соответствие с графиком выпуска Kubernetes, который сам по себе был немного беспокойным. Но несколько лет назад Google и Mesosphere (ныне несуществующие) и другие ключевые игроки Kubernetes создали интерфейс хранилища контейнеров, который вытащил драйверы хранилища и превратил их в плагины, что позволило всевозможным поставщикам блочных и файловых хранилищ поддерживать постоянные объемы для платформ Kubernetes.

Головоломка Kubernetes отличается от головоломки VMware – очень отличается

Плагины CSI аналогичны плагинам, которые были доступны для гипервизоров виртуализации серверов, таких как VMware ESXi, Red Hat KVM, Microsoft Hyper-V и Citrix Systems XenServer. Но не существует аналогичной технологии для пространства имен, которое является своего рода – и мы не решаемся использовать это слово – виртуаl кластер вычислений и хранения в физическом кластере, управляемом Kubernetes.

«Я часто использую такую ​​аналогию, – говорит Брей. «Головоломка Kubernetes отличается от головоломки VMware – очень отличается. И некоторые будут утверждать, что головоломка Kubernetes сложнее, потому что у вас есть все эти крошечные микросервисы, выполняющие свои независимые действия. Как вы это организуете? Что ж, Kubernetes это делает. Это буквально его удел в жизни. Он наблюдает за вашими микросервисами и, когда микросервис дает сбой, находит новое место для его запуска и предоставляет ему доступ к своим данным. Это автоматизировано, и вам не нужно вмешиваться ».

Другими словами, устойчивость приложений и управление зависимостями данных встроены в Kubernetes, и прелесть в том, что вам не нужно ничего делать, чтобы это получить. Это было целью Borg и Omega, когда Google создавал его для своего внутреннего управления кластерами и контейнерами, и это было целью Kubernetes, когда Google открыл его исходный код и передал миру.

У вас должна быть автоматизация

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

«И это сильно отличается от традиционного корпоративного центра обработки данных, где разработчик приложения должен отправить заявку на ИТ-поддержку, которая должна быть отправлена ​​администратору хранилища, который должен настроить это хранилище, а затем вернуться к разработчику приложения. Могло пройти две недели. Теперь с OpenShift и постоянным хранилищем все, что нужно сделать разработчику приложения, – это написать строку кода в своем приложении и бум, он автоматически отправляется и запрашивает хранилище на лету, что было предварительно настроено этим администратором хранилища. И все это происходит на лету, без какого-либо ручного вмешательства ».

Предприятиям также нужны данные, чтобы быть устойчивыми за пределами Kubernetes.

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

Kubernetes, реализованный в OpenShift Data Foundation, созданном с помощью Red Hat Ceph, сам по себе устойчив в отношении данных, но предприятиям также нужны данные, которые должны быть устойчивыми, то есть реплицируемыми, резервными или заархивированными – за пределами Kubernetes. Вы не можете доверять какой-либо системе хранения, которая хранит все вечно, и во многих отраслях – на ум приходят здравоохранение, финансовые услуги и правительство – согласно закону, данные должны храниться в извлекаемой форме в течение многих или десятилетий.

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

«У вас должно быть дополнительное программное обеспечение вне CSI, чтобы обеспечить координацию пространства имен», – отмечает Брей, который советует пользователям проверить это, разработали ли их поставщики резервного копирования этот код. Примером Red Hat является OADP -OpenShift API для защиты данных, который предоставляет интерфейс API для координации резервного копирования и восстановления пространства имен Kubernetes.

«Нам все равно, что это за хранилище, если в нем есть подключаемый модуль CSI», – смеется Брей. «Некоторые из наших конкурентов говорят своим клиентам, что с помощью OpenShift Red Hat заставляет их переходить на новое хранилище, но это чушь. Мы можем хранить снимки, резервные копии, реплики – нам все равно, что это за хранилище, и вы даже можете поместить его в общедоступное облако. Мы заботимся о сервисах передачи данных, которые находятся на вершине. Итак, вы можете использовать Veeam, TrilioVault, IBM Spectrum Protect, MicroFocus Data Protector – нам все равно, потому что это не та область, в которой мы хотим добавить ценность. Резервное копирование и восстановление, как я уже сказал, – священная война, и мы здесь не для того, чтобы сражаться в этой битве. У нас есть дела поважнее, например, сделать все это прозрачным для Kubernetes, что мы делаем с помощью OpenShift API для защиты данных ».

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

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

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

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

При поддержке Red Hat.