Архитектура для кластера MarkLogi c - PullRequest
1 голос
/ 23 марта 2020

Мой текущий размер БД составляет приблизительно 1,7 ТБ

Я работаю над перестройкой кластера MarkLogi c.

Я могу нарисовать эту конфигурацию кластера.

enter image description here

В столбцах изображения серым цветом указаны основные леса, а синим - реплики (*-R-*).

Примечание. База данных MODULES to BATCH не будет содержать много данных.

Требуется ли какая-либо модификация для кластера? или это хорошо до go с?

1 Ответ

2 голосов
/ 30 марта 2020

В вашей архитектуре более двух реплик, вероятно, не будут очень полезными. У вас есть 5 хостов, поэтому вы можете потерять 2. Как только вы потеряете третий хост, в вашем кластере не будет хостов, достаточных для кворума , и он будет недоступен. Также важно отметить, что каждая реплика также будет увеличивать нагрузку на хост и объем трафика координации внутри кластера c.

У вас есть реплики леса содержимого, распределенные по узлам кластера, что является рекомендуемым методом. Рекомендуется чередование, чтобы гарантировать, что любой сбой 1 хоста не будет перегружать другой хост, но в этом случае вся нагрузка с одного хоста будет перенесена на другой хост. С 5 основными лесами, распределенными по 5 хостам, каждый хост управляет 20% нагрузки. В случае сбоя одного из хостов нагрузка на хост с репликой составит go до 40%, а остальное останется на уровне 20%. Этот эффект можно смягчить, увеличив число первичных лесов на каждом хосте.

Например, при 10 основных лесах, распределенных по 5 хостам, и репликах, распределенных по этим хостам, при сбое хоста 2 хоста будут управлять 30% нагрузки, а два других хоста останутся на 20% каждый , В вашем случае недостатком этой настройки является то, что для обеспечения высокой доступности каждому узлу потребуются 4 леса контента (2 первичных и 2 реплики), где в настоящее время требуется только 3 леса контента на хост (1 первичная и 2 реплики).

Кроме того, с 1,7 ТБ в ваших основных лесах контента, что составляет около 348 ГБ на лес. Время отклика на запросы также может быть уменьшено за счет увеличения числа первичных лесов. С 10 лесами вы получите около 174 Гб на основной лес. Предполагая, что у вас имеются потоки и память процессора для поддержки дополнительных лесов, это может улучшить время отклика.

Итак, подведем итог: сократите количество лесов реплик не более чем до 2. Проверьте, могут ли хосты поддерживать удвоенную рабочую нагрузку в случае сбоя, и, если они не могут, минимизировать риск, увеличив число первичных лесов контента.

Что касается других баз данных, я бы взял две самые маленькие (или наименее используемые) базы данных и размещают свои леса на 1 хосте. Остальное я бы полосал по кластеру. Например, если схема и модули наименьшие, здесь возможна схема.

Host 1  -  Host 2  -  Host 3  -  Host 4  -  Host 5
========   ========   ========   ========   ========
Mod-1      Mod-R-1    Mod-R-2
Trgr-1     Trgr-R-1   Trgr-R-2
           Sch-1      Sch-R-1    Sch-R-2
                      Enttl-1    Enttl-R-1   Enttl-R-2
Audit-R-2                        Audit-1     Audit-R-1
Batch-R-1  Batch-R-2                         Batch-1
...