Какова была бы стабильная, отказоустойчивая, масштабируемая galera кластерная реализация
Контекст: Мы используем кластер MariaDB Gallera с (только) 2 главными узлами для веб-приложения. Вчера вечером у нас был сбой питания, и теперь мы, может казаться, не восстанавливаем данные и узнали, что база данных была повреждена на обоих узлах. Наше начальное впечатление на эту установку было то, если бы один узел понижается, другой быстро действовал бы как основной узел.
Мои вопросы,
Существует ли способ настроить кластер, таким образом, всегда существует резервный узел, который будет автоматически копироваться, если один из узлов понизится? Особенно, если существует сбой питания.
Какова была бы корректная реализация кластера галереи?
Мы используем кластер Galera с 5 узлами, перед которыми находится балансировщик нагрузки, который постоянно проверяет все узлы. Наша конфигурация такова, что у нас есть только один из узлов, обслуживающих цель записи и чтения для соединений от балансировщика нагрузки, а другие узлы находятся в горячем резерве. Но, конечно, Galera также поддерживает чтение и запись с несколькими мастерами, так что вы можете настроить это по своему вкусу.
Минимальный размер кластера должен быть равен трем, поскольку он должен быть нечетным, чтобы избежать ситуации разделения мозга, когда соединение между узлами обрывается по какой-либо причине. (Вы также можете использовать арбитр, но более простая настройка - просто использовать как минимум 3 правильных узла кластера.) Мы используем 5 узлов, чтобы упростить обновление кластера и повысить устойчивость.
Galera также поддерживает кластер через глобальную сеть, но это требует дополнительной настройки в настройках сервера, чтобы не снижать производительность сервера. Обычно для приложений подойдет кластер с 3+ узлами, имеющими резервную сеть и питание.
Кое-что вы не сказали в своем вопросе, так это тип движка базы данных, который вы используете в своем кластере Galera. Видя, что у вас коррупция, я бы подумал, что это, вероятно, MyISAM? Если это так, вам необходимо перейти на использование InnoDB, поскольку MyISAM фактически не поддерживается Galera. У него также есть и другие преимущества, такие как более гибкая запись, позволяющая избежать повреждения данных даже в том маловероятном случае, когда кластер действительно развалится, и вам потребуется восстановить базу данных.
Ответ на первый вопрос, как и на большинство проблем в вычислительной технике: да, если у вас достаточно ресурсов и времени. Если кластер находится в какой-то среде центра обработки данных, можно надеяться, что у него будет какой-то интерфейс внеполосного управления, такой как выделенные сетевые адаптеры управления и / или система KVM.
Современные решения для управления центрами обработки данных, такие как Intel Datacenter Manager или Системы управления Raritan Datacenter , предлагают пользователям возможность настраивать политики для автоматической перезагрузки систем после сбоя питания, отправки уведомлений и, возможно, даже начала развертывание удаленных или облачных узлов аварийного переключения. Однако для установки и настройки всех аспектов такого рода сети безопасности потенциально требуются большие затраты и высокий уровень знаний, для этого требуется много оборудования, а тщательное тестирование и подготовка затруднены без некоторого простоя.
Другой распространенный инструмент управления узлами - Nagios , который позволяет осуществлять удаленное управление и контроль питания.
В дополнение к параметрам внутриполосного и внеполосного управления установка сервера управления конфигурацией с помощью инструмента CM, такого как Salt или Chef , поможет гарантировать, что узлы настроены правильно и значительно упрощают задачу инициализации новых узлов даже в странных или удаленных средах. Требования к хранилищу и базе данных, а также сетевая среда помогут определить подходящую архитектуру кластера, особенно в отношении хранилища, питания и резервного копирования. В некоторых случаях может быть полезно сгенерировать клоны кикстарта или какое-либо подобное средство установки, такое как AutoYaST, в системах SUSE. Это позволит вам быстро создавать чистые узлы и импортировать необходимые данные из моментальных снимков или резервных копий в случае отказа оборудования.
Еще одним вариантом является сохранение пользовательских образов системы, созданных с помощью системы сборки KIWI , которые импортируют, монтируют или копируют необходимые данные.Использование KIWI позволит вам создавать образы, которые можно развертывать в различных сценариях, в том числе в виде виртуальных машин, через PXE, загрузочный DVD / USB и т. Д. Создание идеального пользовательского образа для ваших нужд с помощью KIWI или другого инструмента сборки операционной системы может быть весьма полезным по ряду причин.
Трудно дать более конкретный ответ на второй вопрос, не зная, какие длины вы сочтете приемлемыми. Настройка и ресурсы, необходимые для многосайтового кластера высокой доступности с дополнительными удаленными резервными копиями, автоматическим переключением при отказе и восстановлением, кардинально отличаются от тех, которые потребуются для кластера, где "высокая доступность" означает, что здание, в котором находится кластер, имеет питание и интернет нужны для работы. Надеюсь, часть информации там окажется полезной.