Кластер Percona XtraDB с GlusterFS
Мы развертываем кластер GlusterFS с 4 узлами, и мы хотим развернуть кластер Percona XtraDB поверх него с 4 узлами, каждый узел будет иметь подключенную папку из GlusterFS, каждое монтирование будет отдельным, а не общим .
Общий размер GlusterFS составит около 6–8 ТБ, и мы планируем расширить его до 20 ТБ в следующие два месяца развертывания. На томе будет 4 экспорта NFS, по одному для каждого узла Percona XtraDB Cluster.
Таковы планы, которые у нас есть до сих пор. Мне нужен совет, рекомендуется ли эта установка, или, лучше, что вы порекомендуете для такой установки? Кластер GlusterFS уйдет, потому что у нас есть другие серверы, которые будут совместно использовать некоторые файлы (это не будет его основной целью, к этим файлам будет редко обращаться, но эти файлы должны находиться в этом кластере). Что нам нужно, так это кластер базы данных для высокой доступности и балансировки нагрузки, и мы думали об использовании основных glusterfs для хранения базы данных. Мы знаем, что использовать один и тот же файл db на всех узлах - плохая идея, поэтому у нас будет 4 монтирования NFS, по одному для каждого узла db.
Я надеюсь, что вы понимаете мою точку зрения и что вы можете дать хороший совет относительно некоторых вариантов решения этой проблемы. Кстати, на всех серверах будет последняя версия Ubuntu Server.
Заранее спасибо.
Я сделал это, именно это
Но ...
... поскольку результаты с XtraDB ON TOP gluster были неоднозначными,
в итоге штуку переместили в тройной перконный кластер с ProxySQL, ваш скорость базы данных будет намного выше без уровня glusterFS с высокой задержкой. (по крайней мере, в сценарии производственной базы данных с «живыми ответами», если вы можете дождаться, пока ваши результаты будут отправлены по почте на следующей неделе или в следующем месяце .. тогда все должно быть в порядке)
→ Используйте нечетное число в обоих сценариях (распространяющиеся тома, кластер XtraDB), например, 3 5 7 и так далее (или используйте арбитражные тома в gluster), чтобы предотвратить проблемы Quorum / SplitBrain
→ в Gluster развернуть функцию bitrot
* → по возможности используйте память ECC, рекомендуемая формула минимального размера:
{ 1GB(daemon/cache) + ( 1GB RAM * TBytes storage ) }
→ Также помните, что для повышения производительности в определенных сценариях и при использовании чрезмерной блокировки (использование базы данных), Монтирование NFS может превзойти родное крепление gluster
общие советы:
- прочтите man-страницы по всем параметрам монтирования nfs, таким как fsc, rsize, wsize, чтобы иметь аварийное переключение, развернуть CTDB
- при использовании предохранитель клиент (большие файлы), используйте резервный volfile-сервер
- сделать некоторую настройку производительности это было уже спрашивали здесь
в другой поток , сказано
По моему опыту, разница в производительности огромна. После переключения моего веб-приложения с FUSE на NFS время загрузки уменьшилось с 1,5 -> 4 секунд до менее 1 секунды. Также я пробовал сегодня распаковать некоторые архивы, и, похоже, это займет в 4-5 раз больше времени на FUSE.
эталон пример здесь
Каждый узел кластера должен использовать свое собственное пространство без совместного использования файлов. GlusterFS следует использовать в качестве эластичного хранилища, чтобы снять ограничение на размер общего диска. Percona XtraDB Cluster может масштабировать производительность, но не размер БД, поэтому, если вы планируете иметь огромные базы данных (по размеру), вы можете использовать GlusterFS, иначе я бы просто использовал локальное хранилище, локальное хранилище SSD еще лучше.