Corpus collapsum: устойчивость Galera к партиционированию в высоконагруженной среде с помехами Базы данных, системы хранения
Тезисы
Все реально существующие сети время от времени могут выходить из строя, тем более при высокой нагрузке. Выход из строя - явление достаточно распространенное, но устойчивость к партиционированию в распределенной системе обеспечивается не так часто. Несмотря на то, что устойчивость к партиционированию является неотъемлемой частью теоремы Брюера (или теоремы САР), распределенные системы, даже спроектированные с учётом реализации 'P' (Partition tolerance – устойчивость к партиционированию) в CAP, не обеспечивают её в достаточной степени и недостаточно детерминированы. К сожалению, это не исключительные случаи, а обычная практика, согласно последним исследованиям [1].
Galera [2] дополняет MySQL/PXC (подсистему хранения данных Percona XtraDB Cluster)[3] синхронной репликацией благодаря API wsrep репликации. Синхронная репликация требует не только кворума, но и получения согласованного результата. В среде с помехами задержка получения согласованного результата может привести к замедлению фиксации транзакций, следовательно, и к значительной задержке или даже к разделению сети на многочисленные вторичные компоненты и единичный первичный компонент (при условии, что это возможно). Таким образом, обеспечение устойчивости к партиционированию является не просто желательным, а основным требованием.
Данный доклад касается тестирования устойчивости системы Galera к партиционированию. Docker и Netem/tc (управление трафиком) играет значительную роль в данном случае. Модуль Netem важен для эмуляции случаев выхода из строя – потеря пакетов данных, задержка, повреждение, дублирование пакетов, изменение порядка и др., а также для моделирования таблиц распределения, отражающих задержки канала связи, таких как распределение Парето, paretonormal, uniform (равномерное распределение) и т.д. Docker и контейнеры в целом необходимы для моделирования многочисленных нод, которые могут создаваться в реальном времени (во время работы приложения), легко запускаться и отключаться, иметь сети и потоки, которые просты в настройке при необходимости, обеспечивать горизонтальное масштабирование; если производительность также учитывается в ситуации выбора между контейнерами и полной виртуализацией и др. Утилита Sysbench OLTP используется для эмулирования нагрузки, хотя в данном случае возможно использование RQG (генератора случайных запросов) для расширенного fuzz testing (фаззинга).
Будут рассмотрены основные результаты исследований.
* Применение коэффициентов потерь с распознаванием сегментов WAN для виртуальных сетевых интерфейсов.
* Разные периоды синхронизации после устранения помех в сети.
* Потеря многих нод с кратковременным всплеском помех против потери одной ноды и более длительных помех.
* Полнодуплексная связь контейнеров с dnsmasq.
* Влияние внесетевых факторов – таких, как скорость работы дисков, – на fsync.
* Распределение запросов по нодам по алгоритму round-robin при наличии/без нод с отказами сети в цепи.
* Горизонтальное масштабирование тестовых нод и проблемы с Docker/namespace.
В заключительной части доклада будут обсуждаться все детали тестирования Galera на устойчивость к партиционированию с помощью Docker и Netem. Также будут охвачены схожие инструменты/фреймворки, такие как jespen [4]. Более того, будет приведено сравнение Galera/EVS (расширенная виртуальная синхронизация) с другими протоколами обеспечения согласованного результата – например, Paxos, Raft и др. В конце будут освещены результаты тестирования – дополнение auto_evict к Galera.
[1] https://queue.acm.org/detail.cfm?id=2655736
[2] http://galeracluster.com/products/
[3] http://www.percona.com/software/percona-xtradb-cluster
[4] https://github.com/aphyr/jepsen