Рекомендации по использованию
In this article:
Рекомендации по использованию#
В этом разделе приводятся рекомендации по использованию сервиса баз данных в К2 Облаке.
MySQL#
Варианты запуска сервиса#
Одиночный экземпляр СУБД, развёрнутый на виртуальной машине в одной зоне доступности.
Отказоустойчивая СУБД, развёрнутая в кластере из трёх виртуальных машинах в одной или трёх зонах доступности. Кластер может содержать:
Три полнофункциональных узла. Данные распределяются по трём самостоятельным копиям, с каждой из которой можно работать независимо.
Два полнофункциональных узла + кластерный арбитр. Этот вариант более экономичен с точки зрения количества задействованных ресурсов. Только два узла СУБД являются рабочими, а третий узел используется для поддержания кластерного кворума. Экземпляр с кластерным арбитром запускается с минимальным набором ресурсов: 1 vCPU, 2 ГиБ RAM, 16 ГиБ дискового пространства.
Архитектура отказоустойчивого решения#
Для кластеризации MySQL мы используем Galera. Все узлы такого кластера активны одновременно и позволяют выполнять любые операции на чтение и запись. Однако используемое приложение должно уметь работать с конфигурацией СУБД с несколькими мастерами. Несогласованные (нетранзакционные) действия со стороны множества экземпляров приложения по отношения к конфигурации СУБД с несколькими мастерами могут приводить, например, к увеличению числа блокировок (deadlock).
Если вы не уверены, что ваше приложение будет корректно работать на чтение и запись со всеми узлами одновременно, лучше использовать следующие сценарии:
Работать единовременно только с одним узлом кластера СУБД, а на остальных узлах хранить копию данных, чтобы они могли принять на себя нагрузку в случае отказа первого узла.
Производить запись только на один узел кластера СУБД, тогда как остальные узлы использовать только на чтение данных.
Для реализации описанных сценариев удобно использовать ProxySQL. Этот инструмент принимает запросы от приложения и перенаправляет к узлам СУБД. При этом он может по заданным правилам распределять операции по конкретным узлам, а также кешировать ответы СУБД, модифицировать запросы и т.д. ProxySQL автоматически детектирует выход из строя узлов кластера СУБД и мгновенно переключается на использование работающих узлов.
Подробнее о возможностях ProxySQL и его настройке читайте в официальной документации ProxySQL и в wiki проекта. Для добавления сервера СУБД в ваш ProxySQL в качестве бэкенда воспользуйтесь инструкцией.
Распределение запросов с помощью HAProxy#
Для простоты и удобства использования отказоустойчивого сервиса MySQL мы встроили в него инсталляцию HAProxy, которая отслеживает статус и роли узлов и автоматически распределяет запросы. Запросы направляются либо на первый узел кластера, либо на следующий работоспособный узел, если первый узел стал недоступен.
Сервис HAProxy работает на каждом из узлов кластера на порту tcp/5000.
Таким образом, вы можете просто отправить запрос на этот порт на любом из узлов — механизм HAProxy направит его на верный узел.
Чтобы максимально использовать преимущества отказоустойчивого сервиса, необходимо при подключении к MySQL задействовать порты HAProxy всех узлов. Удобнее всего для этого настроить ещё один сервис балансировки на стороне вашего приложения. Вы можете использовать облачный балансировщик нагрузки или развернуть свой собственный.
Подключиться к СУБД#
После успешного запуска адреса и порты, которые прослушивает СУБД, можно найти на странице базы данных MySQL.
Экземпляры MySQL прослушивают порт tcp/3306.
Используйте этот порт для подключения и дальнейшей работы с СУБД.
Важно
Кластер позволяет сохранить доступность базы данных при отказе одного из узлов, но только если вы используете не одну, а все точки приёма запросов кластера (endpoints).
СУБД можно управлять как через стандартный консольный клиент mysql в Linux, так и с помощью графических инструментов, таких как dbForge Studio, MySQL Workbench, phpMyAdmin и т.д.
Если вы хотите подключаться к сервису MySQL удалённо, не забудьте назначить Elastic IP экземпляру с развёрнутым сервисом и разрешить подключения к порту tcp/3306 в соответствующей группе безопасности.
Важно
Будьте осторожны, открывая доступ к MySQL из интернета. Рекомендуем ограничить доступ конкретными IP-адресами, а также использовать сложные пароли.
PostgreSQL#
Варианты запуска сервиса#
Одиночный экземпляр СУБД, развёрнутый на виртуальной машине в одной зоне доступности.
Отказоустойчивая СУБД, развёрнутая в кластере из трёх виртуальных машин в одной или трёх зонах доступности. Кластер может содержать:
Три полнофункциональных узла. Данные распределяются по трём самостоятельным копиям, с каждой из которой можно работать независимо.
Два полнофункциональных узла + кластерный арбитр. Этот вариант более экономичен с точки зрения количества задействованных ресурсов. Только два узла СУБД являются рабочими, а третий узел используется для поддержания кластерного кворума. Экземпляр с кластерным арбитром запускается с минимальным набором ресурсов: 1 vCPU, 2 ГиБ RAM, 16 ГиБ дискового пространства.
Архитектура отказоустойчивого решения#
Существует много способов настроить и управлять репликацией в PostgreSQL. Для организации отказоустойчивого кластера PostgreSQL в К2 Облаке используется Patroni. Этот инструмент автоматически отслеживает состояние узлов, управляет репликацией и переключает её в случае отказа одного из узлов кластера.
В каждый момент времени только один узел кластера может быть мастером, остальные являются репликами. На мастере можно производить операции чтения и записи, на репликах — только чтение.
Узнать роль конкретного узла можно с помощью запроса к Patroni RestAPI, который доступен на каждом узле на сервисном порту tcp/8008.
С подробной инструкцией можно ознакомиться здесь.
Для простоты и удобства использования отказоустойчивого сервиса PostgreSQL мы встроили в него инсталляцию HAProxy, которая отслеживает роли узлов и автоматически направляет запросы на мастер.
HAProxy работает на всех узлах кластера (кроме арбитра) на порту tcp/5000.
Таким образом, к этому порту можно обратиться с любого узла и механизм HAProxy направит запрос на мастер.
Чтобы максимально использовать преимущества отказоустойчивого сервиса, необходимо при подключении к PostgreSQL задействовать порты HAProxy всех узлов. Удобнее всего для этого настроить ещё один сервис балансировки на стороне вашего приложения. Вы можете использовать облачный балансировщик нагрузки или развернуть свой собственный.
Схематично архитектура решения изображена ниже.
Подключиться к СУБД#
После успешного запуска адреса и порты, которые прослушивает СУБД, можно найти на странице базы данных PostgreSQL.
Экземпляры PostgreSQL прослушивают порт tcp/5432.
Patroni Rest API доступен на этих же узлах на порту tcp/8008.
Используйте эти порты для подключения и дальнейшей работы с СУБД.
Важно
Кластер позволяет сохранить доступность базы данных при отказе одного из узлов, но только если вы используете не одну, а все точки приёма запросов кластера.
СУБД можно управлять как через стандартный консольный клиент psql в Linux, так и с помощью графических инструментов, например, pgAdmin.
Если вы хотите подключаться к сервису PostgreSQL удалённо, не забудьте назначить Elastic IP экземпляру с развёрнутым сервисом и разрешить подключение к порту tcp/5432 в соответствующей группе безопасности.
Важно
Будьте осторожны, открывая доступ к PostgreSQL из интернета. Рекомендуем ограничить доступ конкретными IP-адресами, а также использовать сложные пароли.
Redis#
Варианты запуска сервиса#
Одиночный экземпляр СУБД, развёрнутый на одной виртуальной машине в одной зоне доступности.
Отказоустойчивая СУБД, развёрнутая в кластере из трёх или шести виртуальных машинах в одной или трёх зонах доступности.
Архитектура отказоустойчивого решения#
Для Redis доступны два варианта отказоустойчивой архитектуры — с использованием мониторингового сервиса Sentinel и, начиная с версии Redis 3.0, cо встроенной кластеризацией (native clustering в терминологии Redis). Первый позволяет реализовать высокую доступность для небольших инсталляций. Второй обеспечивает лучшую масштабируемость и производительность для крупных инсталляций.
Redis Sentinel#
В К2 Облаке реализована конфигурация с Sentinel из трёх узлов, на одном их которых работает мастер, а на двух других — реплики (для кластера с шестью узлами данный вариант кластеризации не поддерживается). На каждом узле помимо сервера Redis запущен также процесс Redis Sentinel. При сбоях и других неполадках сервис Sentinel запускает процедуру автоматического переключения (failover). Подробнее о функциональности Sentinel можно прочитать в официальной документации.
Процессы Sentinel взаимодействуют друг с другом и следят за работоспособностью узлов Redis. При сбое узла, сервера Redis или сервиса Sentinel доступные процессы Sentinel устраивают перевыборы, чтобы определить, какому из узлов будет назначена роль мастера. Далее запускается процедура автоматического переключения: выбранная реплика становится новым мастером, оставшаяся реплика переконфигурируется для работы с этим мастером, а приложения, использующие сервер Redis, информируются о новом адресе для подключения.
Примечание
Redis использует асинхронную репликацию, поэтому такая распределённая система из узлов Redis и процессов Sentinel не гарантирует, что подтверждённые операции записи будут действительно сохранены при сбое.
Отказоустойчивый сервис Redis#
Отказоустойчивый сервис Redis развёртывается в кластере из трёх (или шести) экземпляров виртуальных машин, и на каждом узле работают по одному мастеру и реплике, причём реплика взаимодействует с мастером на другом узле (кросс-репликация).
Высокая производительность и линейная масштабируемость кластера обеспечивается благодаря нескольким мастер-узлам, а высокая доступность — наличием как минимум одной реплики для каждого мастера. С подробной информацией можно ознакомиться в официальной документации Redis.
Все мастер-узлы делят между собой единое пространство для данных, которое разделено на слоты. Таким образом, каждый мастер содержит часть слотов (sharding).
При работе с отказоустойчивым сервисом Redis обращения обрабатываются мастерами. Для операций чтения и записи можно обращаться к любому мастеру. Если при чтении искомые данные находятся в слоте на другом мастере, то Redis сам перенаправит клиента к нужному экземпляру.
В случае сбоя мастер-экземпляра или всего узла, на котором работает экземпляр, происходит автоматическое переключение (failover) на соответствующую реплику, которая берёт на себя роль мастера.
Распределение запросов с помощью HAProxy#
Для простоты и удобства использования отказоустойчивого сервиса Redis мы встроили в него инсталляцию HAProxy, которая отслеживает статус и роли узлов и автоматически распределяет запросы только на экземпляры виртуальных машин в роли мастера.
HAProxy работает на всех узлах кластера на порту tcp/5000.
Таким образом, к этому порту можно обратиться с любого узла и механизм HAProxy направит запрос на один из мастеров.
Чтобы максимально использовать преимущества отказоустойчивого сервиса, необходимо при подключении к Redis задействовать порты HAProxy всех узлов. Удобнее всего для этого настроить ещё один сервис балансировки на стороне вашего приложения. Вы можете использовать облачный балансировщик нагрузки или развернуть свой собственный.
Архитектура решения с HAProxy для отказоустойчивого сервиса Redis#
Подключиться к СУБД#
После успешного запуска адреса и порты, которые прослушивает СУБД, можно найти на странице базы данных Redis. В случае одиночного сервиса для подключения доступна всего одна точка приёма запросов (endpoint), в случае же отказоустойчивого сервиса их несколько (точное количество зависит от выбранной архитектуры).
Мастер-экземпляры Redis прослушивают порт tcp/6379, реплики — tcp/6380.
При сбое мастер-экземпляра или всего узла, на котором работает экземпляр, происходит автоматическое переключение: реплика становится мастером, но продолжает работать на порту tcp/6380.
Поэтому одного номера порта недостаточно, чтобы понять, является ли экземпляр мастером или репликой в работающем продолжительное время кластере.
Важно
Кластер позволяет сохранить доступность базы данных при отказе одного из узлов, но только если вы используете не одну, а все точки приёма запросов кластера (endpoints).
Аутентификация в Redis#
При работе в закрытых контурах нет необходимости включать аутентификацию в Redis, но в недоверенной среде может потребоваться защитить вашу инсталляцию паролем.
Пароль можно задать при создании сервиса БД.
После того как сервис был запущен с заданным паролем, обратиться к нему можно после аутентификации (команда AUTH).
Вы можете управлять развёрнутым сервисом Redis как через стандартный консольный клиент redis-cli в Linux, так и использовать для этого графические инструменты. Хороший обзор графических инструментов можно найти в блоге.
Если вы хотите подключаться к сервису Redis удалённо, не забудьте назначить Elastic IP экземпляру с развёрнутым сервисом и разрешить подключение к портам tcp/6379-6380 в соответствующей группе безопасности.
Важно
Будьте осторожны, открывая доступ к Redis из интернета. Рекомендуем ограничить доступ конкретными IP-адресами, а также использовать сложные пароли.
MongoDB#
Варианты запуска сервиса#
Одиночный экземпляр СУБД, развёрнутый на одной виртуальной машине в одной зоне доступности.
Отказоустойчивая СУБД, развёрнутая в кластере из трёх виртуальных машинах в одной или трёх зонах доступности. Кластер может содержать:
Три полнофункциональных узла. Данные распределяются по трём самостоятельным копиям, с каждой из которой можно работать независимо.
Два полнофункциональных узла + кластерный арбитр. Этот вариант более экономичен с точки зрения количества задействованных ресурсов. Только два узла СУБД (primary и secondary) являются рабочими, а третий узел (arbiter) используется для поддержания кластерного кворума. Экземпляр с кластерным арбитром запускается с минимальным набором ресурсов: 1 vCPU, 2 ГиБ RAM, 16 ГиБ дискового пространства.
Архитектура отказоустойчивого решения#
Отказоустойчивый сервис MongoDB в облаке представляет собой набор реплик (Replica Set) — группу экземпляров MongoDB, которые поддерживают один и тот же набор данных путём репликации.
В наборе реплик существуют несколько ролей:
первичный узел (primary) — производит операции чтения и записи;
вторичный узел (secondary) — выполняет только чтение;
арбитр — не реплицирует данные и не участвует в пользовательских операциях.
Репликация данных является асинхронной: первичный узел выполняет все операции записи, после чего вторичный — считывает описание этих операций и асинхронно применяет их у себя.
Если первичный узел становится недоступным, например, в случае аварии, то оставшиеся узлы кластера используют правило кворума и определяют, кто примет на себя его роль. После возвращения недоступного узла в работу он становится вторичным и копирует себе актуальный набор данных с нового первичного узла. Таким образом, роль primary может перемещаться между узлами в процессе жизни кластера.
Подробнее про организацию работы набора реплик можно почитать в официальной документации MongoDB.
Подключиться к СУБД#
После успешного запуска адреса и порты, которые прослушивает СУБД, можно найти на странице базы данных MongoDB.
Экземпляры MongoDB прослушивают порт tcp/27017.
Важно
Кластер позволяет сохранить доступность базы данных при отказе одного из узлов, но только если вы используете не одну, а все точки приёма запросов кластера (endpoints).
Клиенты и драйверы MongoDB поддерживают строку подключения (connection string), где можно указать точки приёма запросов для набора реплик, чтобы определение текущего первичного узла и переключение на новый узел выполнялись автоматически.
В общем виде подключение может выглядеть так:
mongodb://mongo1,mongo2,mongo3/?replicaSet="rsmain"
Для подключения достаточно указать несколько узлов, остальные будут определены автоматически.
replicaSet в таких автоматически развёрнутых кластерах всегда называется rsmain.
Вы можете управлять развёрнутым сервисом MongoDB как через стандартный консольный клиент mongo shell в Linux, так и использовать для этого графические инструменты, такие как TablePlus или Robo 3T.
Если вы хотите подключиться к сервису MongoDB удалённо, выполните следующие действия:
Откройте страницу экземпляра c развёрнутым сервисом MongoDB, перейдите на вкладку Сеть и безопасность и нажмите на идентификатор той группы безопасности, которую вы планируете использовать для регулирования доступа извне.
На странице группы безопасности перейдите на вкладку Входящие правила.
Добавьте разрешающее правило для протокола tcp и порта
27017.Назначьте Elastic IP сетевому интерфейсу этого экземпляра.
Важно
Будьте осторожны, открывая доступ к MongoDB из интернета. Рекомендуем ограничить доступ конкретными IP-адресами, а также использовать сложные пароли.