Умножение пропускной способности и синхронные кластеры
Я видел много людей, настраивающих кластеры с 3-6 + узлами в сетях 1 Гбит / с. 1 Гбит / с кажется много, не так ли? На самом деле, может быть, не так много, как вы думаете, Хотя теоретический предел 1 Гбит / с на самом деле составляет 120 Мбит / с, я начинаю нервничать около 100 Мбит / с. По умолчанию Galera использует одноадресный TCP для репликации. Поскольку синхронная репликация должна реплицироваться на все узлы одновременно, это означает, что 1 копия вашего сообщения репликации отправляется на другой узел в кластере. Чем больше узлов в кластере, тем больше увеличивается пропускная способность, необходимая для репликации. Теперь это не сильно отличается от стандартной репликации MySQL. 1 мастер с 5 асинхронными подчиненными будет отправлять отдельный поток репликации каждому, поэтому ваши требования к пропускной способности будут аналогичными. Тем не менее, с асинхронной репликацией вы можете позволить себе не блокировать ведение записи мастером, если пропускная способность ограничена, а подчиненные устройства немного отстают, что не так в Galera., Итак, давайте посмотрим на этот эффект в действии. У меня есть простой скрипт, который выводит пропускную способность сети на интерфейс каждую секунду. Я запускаю тест sysbench на одном узле и измеряю исходящую (UP) пропускную способность на этом же узле:
# 2 nodes in the cluster eth1 DOWN:24 KB/s UP:174 KB/s eth1 DOWN:25 KB/s UP:172 KB/s eth1 DOWN:27 KB/s UP:196 KB/s eth1 DOWN:27 KB/s UP:195 KB/s eth1 DOWN:27 KB/s UP:197 KB/s eth1 DOWN:27 KB/s UP:200 KB/s # 3 nodes in the cluster eth1 DOWN:74 KB/s UP:346 KB/s eth1 DOWN:79 KB/s UP:357 KB/s eth1 DOWN:77 KB/s UP:342 KB/s eth1 DOWN:79 KB/s UP:368 KB/s eth1 DOWN:81 KB/s UP:368 KB/s eth1 DOWN:78 KB/s UP:363 KB/s
Это не так много трафика на моих маленьких локальных виртуальных машинах, но вы поняли. Мы можем ясно видеть некоторый фактор в игре, добавляя дополнительные узлы.
Multicast на помощь!
Одним из способов устранения этого ограничения пропускной способности является переключение на многоадресную UDP-репликацию в Galera. Это на самом деле очень легко сделать. Во-первых, нам нужно убедиться, что наша среда будет поддерживать многоадресную передачу . Это вопрос для ваших сетевых ребят и выходит за рамки этого поста, но в моей тривиальной среде виртуальной машины мне просто нужно убедиться, что адресное пространство многоадресной рассылки направляется к моему интерфейсу репликации Galera, eth1:
[all nodes]# ip ro add dev eth1 224.0.0.0/4 [all nodes]# ip ro show | grep 224 224.0.0.0/4 dev eth1 scope link
В этом месте мы выбираем неиспользуемый адрес mcast (опять же, поговорите с ребятами из вашей сети). Я использую 239.192.0.11, поэтому мы добавим это в наш my.cnf:
wsrep_provider_options = "gmcast.mcast_addr=239.192.0.11"
Если у вас уже установлен wsrep_provider_options, добавьте его в список, разделенный точкой с запятой, вместо отдельной строки в вашей конфигурации. Если у нас уже есть работающий кластер, нам нужно выключить его, настроить адрес mcast и заново запустить его:
[root@node3 mysql]# service mysql stop [root@node2 mysql]# service mysql stop [root@node1 mysql]# service mysql stop
[root@node1 mysql]# service mysql start --wsrep_cluster_address=gcomm:// [root@node2 mysql]# service mysql start [root@node3 mysql]# service mysql start
Мы можем видеть, что многоадресный узел все еще должен связываться с портом репликации Galera, и, конечно, это должно быть связано с интерфейсом, на который будет получен многоадресный прием.
[root@node3 mysql]# lsof -P +p 17493 | grep LISTEN mysqld 17493 mysql 11u IPv4 39669 0t0 TCP *:4567 (LISTEN) mysqld 17493 mysql 20u IPv4 39685 0t0 TCP *:3306 (LISTEN)
Теперь давайте сделаем наш тест выше:
# 2 nodes in the cluster eth1 DOWN:15 KB/s UP:199 KB/s eth1 DOWN:14 KB/s UP:195 KB/s eth1 DOWN:15 KB/s UP:212 KB/s eth1 DOWN:14 KB/s UP:204 KB/s eth1 DOWN:13 KB/s UP:173 KB/s # 3 nodes in the cluster eth1 DOWN:62 KB/s UP:185 KB/s eth1 DOWN:61 KB/s UP:187 KB/s eth1 DOWN:52 KB/s UP:164 KB/s eth1 DOWN:62 KB/s UP:187 KB/s eth1 DOWN:64 KB/s UP:186 KB/s eth1 DOWN:62 KB/s UP:193 KB/s
Таким образом, мы видим, что наша исходящая пропускная способность на нашем главном узле не меняется, так как мы добавляем больше узлов, когда используем многоадресную рассылку.
Другие многоадресные советы
Мы также можем загружать узлы, используя адрес mcast:
#wsrep_cluster_address = gcomm://192.168.70.2,192.168.70.3,192.168.70.4 wsrep_cluster_address = gcomm://239.192.0.11
И это прекрасно работает. Довольно гладко! Обратите внимание, что IST и SST по-прежнему будут использовать одноадресную передачу TCP, поэтому мы все же хотим убедиться, что они настроены на использование обычного IP-адреса узла. Обычно я просто устанавливаю параметр wsrep_node_address на каждом узле, если этот IP не является IP-адресом по умолчанию сервера. Я не смог найти способ перенести существующий одноадресный кластер в многоадресную рассылку с непрерывным обновлением. Я считаю (но это может оказаться ошибочным), что вы должны перезапустить весь кластер, чтобы включить многоадресную рассылку.