Часть первая. Развертывание кластера Apache Cassandra с несколькими центрами обработки данных в Kubernetes

Автор: Джефф Карпентер

Это первая статья из серии, в которой подробно рассказывается, как создавать кластеры Cassandra с различными топологиями развертывания с помощью K8ssandra.

Если вы хотите развернуть один центр обработки данных Apache Cassandra® в одном кластере Kubernetes (K8s), вы найдете множество примеров на K8ssandra. Однако есть много ситуаций, когда вам будет полезно развернуть многоцентровый кластер Cassandra на K8s. Например, если у вас есть рабочая нагрузка аналитики с большим количеством операций чтения, поддерживающая ваше основное приложение, вы можете изолировать ее, создав дополнительный центр обработки данных Cassandra.

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

Гибкие топологии с Cassandra

С самого начала Cassandra включала возможность назначать узлы центрам обработки данных и стойкам.

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

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

Концепции центров обработки данных и стоек в Cassandra гибкие, что позволяет использовать различные шаблоны развертывания. В развертываниях общедоступного облака стойки часто сопоставляются с зонами облачных провайдеров, а центры обработки данных — с регионами. Например, при развертывании на Google Cloud Platform (GCP) у вас может быть Cassandra dc1развернутая в регионе us-west4 со стойками в зонах us-west4-a, us-west4-b и us-west4-c. Еще один центр обработки данных dc2может быть развернут в us-east1.

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

Как развернуть отдельную установку K8ssandra для каждого центра обработки данных Cassandra

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

1. Создайте кластер Kubernetes для тестирования

Чтобы попробовать это, вам понадобится кластер Kubernetes для тестирования. Для примера в этом посте я следовал инструкциям в документации по установке K8ssandra Google Kubernetes Engine (GKE), чтобы создать кластер GKE в регионе us-west4. Обратите внимание, что я следовал инструкциям на этой странице вплоть до раздела Установка K8ssandra и остановился, поскольку моя установка немного отличается.

Инструкции по установке GKE ссылаются на сценарии, которые предоставляются как часть Примера K8ssandra GCP Terraform.

2. Создайте учетные данные администратора

Согласно параметрам K8ssandra по умолчанию, узлы Cassandra создаются с включенной аутентификацией. Если секрет, содержащий учетные данные для аутентификации, не указан, K8ssandra создает секрет, содержащий имя пользователя и пароль администратора, которые будут применяться ко всем узлам.

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

Вы можете создать пространства имен и секреты следующим образом:

Для целей этого блога давайте не будем усложнять и позволим kubectl кодировать учетные данные. Вы можете использовать более сложный пароль для производственных развертываний. См. Страница документации по безопасности и раздел cassandra.auth Документации K8ssandra helm chart для получения дополнительной информации о настройке учетных данных администратора.

3. Создайте первый центр обработки данных

Теперь вы готовы приступить к созданию развертывания с несколькими центрами обработки данных. Сначала создайте конфигурацию для первого центра обработки данных в файле с именем dc1.yaml:

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

Теперь создайте релиз для центра обработки данных с помощью этой команды:

Это устанавливает выпуск K8ssandra в пространстве имен txndc, которое является просто именем, выбранным для обозначения того, что это центр обработки данных Cassandra, предназначенный для транзакционной работы.

Можно проверить распределение узлов Cassandra между воркерами в разных зонах, используя выходные данные команды kubectl описать узлы, которые включают информацию о зоне узла, а также о его исполняемых модулях (я немного сократил вывод для удобства чтения). ):

Как вы видете:

rack1 сопоставляется с зоной us-west4-a
rack2 в зону us-west4-b
rack3 в зону us-west4-c

Как и в случае любого развертывания кластера Cassandra, вам нужно дождаться полной загрузки первого центра обработки данных, прежде чем добавлять второй центр обработки данных. Простой способ сделать это — посмотреть, пока модуль Звездные врата не отобразится как инициализированный, поскольку это зависит от готовности Кассандры:

4. Создайте второй центр обработки данных

Теперь давайте создадим конфигурацию для развертывания второго ЦОД. Чтобы узлы в dc2 присоединились к кластеру, требуется несколько вещей.

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

В традиционной установке Cassandra вы можете получить IP-адреса пары узлов dc1, чтобы предоставить их dc2 в качестве исходных узлов. В K8s мы ожидаем, что модули будут заменяться довольно регулярно, поэтому нет гарантии, что узел Cassandra будет доступен по определенному IP-адресу, если он будет воссоздан в новом модуле. К счастью, K8ssandra позаботится об этом, предоставив услугу семян.

Начальная служба предоставляет стабильный DNS-адрес, который разрешает IP-адреса во время процесса начальной загрузки для других узлов Cassandra, желающих присоединиться к кластеру. K8ssandra управляет деталями сопоставления IP-адресов модуля пары базовых узлов Cassandra в качестве фактических семян. Вы можете найти начальный сервис с помощью такой команды:

Что производит такой вывод:

Как видите, имя службы — mixed-workload-seed-service. Чтобы ссылаться на него как на начального поставщика в другом пространстве имен, вам необходимо включить пространство имен как часть имени DNS: mixed-workload-seed-service.txndc. Теперь создайте конфигурацию с этими значениями в файле с именем dc2.yaml:

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

Это устанавливает выпуск K8ssandra в пространстве имен analyticsdc. Если вы посмотрите на ресурсы в этом пространстве имен с помощью такой команды, как kubectl get services,pods -n analyticsdc, вы заметите, что существует аналогичный набор модулей и сервисов, что и для txndc, включая Stargate, Prometheus, Grafana и Reaper. В зависимости от того, как вы хотите управлять своим приложением, вы можете настроить конфигурацию, чтобы отключить любые компоненты, которые вам не нужны.

5. Настройте пространства ключей

Как только второй центр обработки данных подключится к сети, вы захотите настроить пространства ключей Cassandra для репликации в обоих кластерах. Для этого подключитесь к узлу в исходном центре обработки данных и выполните cqlsh:

Используйте команду DESCRIBE KEYSPACES, чтобы вывести список пространств ключей, и DESCRIBE KEYSPACE <name>, чтобы идентифицировать тех, кто использует NetworkTopologyStrategy. Например:

Как правило, вы обнаружите, что пространства ключей system_auth, system_traces и system_distributed используют NetworkTopologyStrategy. Затем вы можете обновить стратегию репликации, чтобы обеспечить репликацию данных в новый центр обработки данных. Вы выполните что-то вроде следующего для каждого из этих пространств ключей:

Важно! Не забудьте создать или изменить стратегию репликации для любых пространств ключей, необходимых для вашего приложения. Это необходимо для того, чтобы убедиться, что у вас есть необходимое количество реплик в каждом центре обработки данных. Если вы включили Звездные врата, обязательно измените пространство клавиш data_endpoint_auth, чтобы оно также использовало NetworkTopologyStrategy.

После выхода из cqlsh убедитесь, что существующие данные правильно реплицированы в новый центр обработки данных с помощью команды nodetool rebuild. Его нужно запустить на каждой ноде в новом дата-центре, например:

Повторите для других узлов mixed-workload-dc2-rack2-sts-0 и mixed-workload-dc2-rack3-sts-0.

Тестирование конфигурации

Как понять, что конфигурация сработала? Пришло время проверить это. Самый простой способ — использовать команду nodetool status. Итак, вам нужно выбрать узел Cassandra для выполнения команды nodetool.

Поскольку K8ssandra настраивает узлы Cassandra на запрос входа в систему по умолчанию, вам потребуются учетные данные. Выполните команду nodetool the для узла, обязательно заменив любые альтернативные учетные данные, которые вы могли использовать:

Это приведет к выводу, подобному следующему:

Если все настроено правильно, вы увидите оба центра обработки данных в выходных данных кластера. Вот диаграмма того, что вы только что развернули, с акцентом на узлы Cassandra:

Как насчет нескольких центров обработки данных Cassandra в одной установке K8ssandra?

Вы можете задаться вопросом: почему бы не сделать одну установку K8ssandra с несколькими центрами обработки данных? Например, вы можете попробовать такую конфигурацию:

Однако, если вы попробуете выполнить такую установку и проверите результаты с помощью kubectl get cassdc, вы увидите только один центр обработки данных в результирующем развертывании:

В чем проблема? Получается, что версии K8ssandra 1.x поддерживают развертывание только одного центра обработки данных. В то время как cass-operator поддерживает несколько центров обработки данных, выпуски K8ssandra до 2.0 в значительной степени зависят от функции шаблонов Helm для обеспечения дополнительной инфраструктуры вокруг Cassandra.

Настройка этой дополнительной инфраструктуры для добавления или удаления центров обработки данных потребует значительных усилий для реализации в шаблонах Helm, как обсуждалось в выпуске #566. К счастью, версия 2.0 предоставит оператора K8ssandra, который значительно упростит развертывание в нескольких центрах обработки данных. Подробнее об этих захватывающих планах вы можете прочитать в выпуске #485.

Что дальше?

Во втором посте этой серии мы проведем вас через ваши первые шаги в топологиях с несколькими центрами обработки данных, которые охватывают кластеры Kubernetes. Если вы хотите рассказать нам об альтернативных конфигурациях, которые вы создаете, или задать нам какие-либо вопросы по этой теме, перейдите на Форум K8ssandra или Канал сообщества K8ssandra в Discord.

Подпишитесь на DataStax на Medium, чтобы получать эксклюзивные публикации обо всем, что связано с Cassandra, потоковой передачей, Kubernetes и многим другим. Чтобы присоединиться к общению с разработчиками со всего мира, подпишитесь на DataStaxDevs в Твиттере.

Это сообщение было первоначально опубликовано на K8ssandra.