Как обрабатывать серверы разных типов в сегментированном кластере MongoDB - PullRequest
1 голос
/ 03 ноября 2019

Есть ли способ работать с разными типами серверов в изолированном кластере? Согласно документации MongoDB, балансировщик пытается добиться равномерного распределения кусков по всем сегментам в кластере. Таким образом, похоже, что он основан только на объеме данных.

Однако, когда вы добавляете новые серверы в существующий защищенный кластер, то обычно на новом сервере больше места на диске, диск быстрее и процессор имеет больше энергии,Особенно, когда вы запускаете приложение в течение нескольких лет, это условие может стать реальностью.

Учитывает ли балансировщик такие темы или вам нужно обеспечить одинаковую производительность и ресурсы на всех серверах в изолированном кластере?

1 Ответ

2 голосов
/ 04 ноября 2019

Вы правы, что балансировщик предположит, что все части кластера имеют одинаковое оборудование. Однако вы можете использовать зонное разбиение , чтобы индивидуально настроить поведение балансировщика.

Чтобы процитировать со страницы документации по разделению зоны:

В кластерах с разделителями выможет создавать зоны данных, основанных на ключе. Вы можете связать каждую зону с одним или несколькими осколками в кластере. Осколок может ассоциироваться с любым количеством зон. В сбалансированном кластере MongoDB переносит фрагменты, охватываемые зоной, только в те сегменты, которые связаны с этой зоной.

Используя зоны, вы можете указать распределение данных как по расположению , по спецификации оборудования , по заявке / клиенту и др.

Чтобы напрямую ответить на ваш вопрос, интересующий вас вариант использования будет Многоуровневое оборудование для различных SLA или SLO . См. Ссылку на учебное пособие о том, как этого добиться.

Обратите внимание, что определение зон является конструктивным решением с вашей стороны, и в настоящее время у сервера нет автоматического способа сделать это за вас.

Небольшое примечание : балансировщик балансирует кластер исключительно с помощью ключа шарда. Он вообще не учитывает объем данных. Таким образом, в неправильно сконструированном ключе шарда возможно, что некоторые шарды переполняются данными, в то время как другие полностью пусты. В случае патологического неправильного проектирования некоторые порции не делятся, что приводит к ситуации, когда кластер будет всегда несбалансированным до тех пор, пока не будет проведена обширная переработка.

...