Перед добавлением сборщиков необходимо следующее:

• Хост развертывания под управлением ОС, поддерживаемой желаемой версией Opsview 9.0008
• Корневой доступ к хосту развертывания
• SSH-доступ с хоста развертывания ко всем хостам Opsview (включая новые серверы, которые будут добавлены в качестве хостов-сборщиков)
  • Аутентификация должна использовать открытые ключи SSH
  • Удаленный пользователь должен быть «root» или иметь доступ «sudo» без пароля и без TTY

🚧

В кластере коллекторов всегда должно быть нечетное количество узлов; 1, 3, 5 и т. д. Это поможет повысить отказоустойчивость и избежать проблем с разделением ресурсов, когда что-то случится с узлом в кластере.

Чтобы добавить новые серверы-сборщики в существующую систему Opsview Monitor с одним сервером, откройте файл /opt/opsview/deploy/etc/opsview_deploy.yml и добавьте следующие строки.
Примечание: Не изменять существующие строки в opsview_deploy.yml:

 collect_clusters:
  коллекционеры-де:
    коллектор_хост:
      opsview-de-1: {ip: 10.12.0.9}
 

Вам необходимо заменить «opsview-de-1» и «10.12.0.9» на имя хоста и IP-адрес вашего нового коллектора. Кроме того, вы можете дать имя своему кластеру коллекторов, заменив «collectors-de» на желаемое имя кластера.

Точно так же вы можете добавить несколько кластеров-коллекторов и несколько кластеров-коллекторов в каждый кластер, например:

 collection_clusters:
  коллекционеры-де:
    коллектор_хост:
      opsview-de-1: {ip: 10.12.0.9}
      opsview-de-2: {ip: 10.12.0.19}
      opsview-de-3: {ip: 10.12.0.29}
 
 коллекторы-fr:
    коллектор_хост:
      opsview-fr-1: {ip: 10.7.0.9}
      opsview-fr-2: {ip: 10.7.0.19}
      opsview-fr-3: {ip: 10.7.0.29}
      opsview-fr-4: {ip: 10.7.0.39}
      opsview-fr-5: {ip: 10.7.0.49}
 

Приведенная выше конфигурация, например, добавит 2 новых кластера коллекторов с именами «collectors-de» и «collectors-fr», где «collectors-de» имеет 3 коллектора, а «collectors-fr» имеет 5 коллекторов с именами хостов и IP-адресами. указаны адреса.

После изменения opsview_deploy.yml запустите opsview deploy следующим образом:

 cd /opt/opsview/deploy
./bin/opsview-deploy lib/playbooks/check-deploy.yml
./bin/opsview-deploy lib/playbooks/setup-hosts.yml
./bin/opsview-deploy lib/playbooks/setup-infrastructure.yml
./bin/opsview-deploy lib/playbooks/collector-install.yml
 

После запуска opsview-deploy проверьте раздел «Регистрация новых серверов Collector в Opsview Web».

Если у вас уже есть несколько сборщиков и вы хотите добавить новые сборщики, откройте /opt/opsview/deploy/etc/opsview_deploy.yml на сервере развертывания (обычно это хост opsview с оркестратором и opsview-web) и добавьте новые кластеры коллекторов или хосты коллекторов после существующих, например:

 collect_clusters:
  существующий-коллектор1:
    коллектор_хост:
      существующий-хост1: {ip: 10.12.0.9}
      новый хост1: {ip: 10. 12.0.19}
      новый хост2: {ip: 10.12.0.29}
 
 новый коллектор-кластер1:
    коллектор_хост:
      новый хост3: {ip: 10.7.0.9}
      новый хост4: {ip: 10.7.0.19}
      новый хост5: {ip: 10.7.0.42}
 

В приведенном выше примере было добавлено 5 новых хостов-сборщиков (новый-хост1, новый-хост2, новый-хост3, новый-хост4 и новый-хост5) и 1 новый кластер сборщиков (новый-сборщик-кластер1). new-host1 и new-host2 были добавлены в существующий кластер сборщиков (existing-collector1), а new-host3, new-host4 и new-host5 были добавлены в новый кластер сборщиков (new-collector-cluster1).

После изменения opsview_deploy.yml запустите opsview deploy следующим образом:

 cd /opt/opsview/deploy
./bin/opsview-deploy lib/playbooks/check-deploy.yml
./bin/opsview-deploy lib/playbooks/setup-hosts.yml
./bin/opsview-deploy lib/playbooks/setup-infrastructure.yml
./bin/opsview-deploy lib/playbooks/collector-install.yml
 

Если вы добавляете новые коллекторы и у вас уже определено их количество, вы можете ускорить процесс, указав имена новых коллекторов для работы с

 компакт-диск /opt/opsview/развернуть
. /bin/opsview-deploy lib/playbooks/check-deploy.yml
./bin/opsview-deploy -l "новый-хост1 новый-хост2" lib/playbooks/setup-hosts.yml
./bin/opsview-deploy -l "новый-хост1 новый-хост2" lib/playbooks/setup-infrastructure.yml
./bin/opsview-deploy -l "новый-хост1 новый-хост2" lib/playbooks/collector-install.yml
 

Войдите в пользовательский интерфейс Opsview Monitor и перейдите на страницу Конфигурация > Мониторинг коллекторов.
Вы должны увидеть желтое сообщение «Ожидание регистрации» справа, как показано ниже:

Щелкните значок меню справа от имени хоста вашего коллектора и нажмите Зарегистрировать, как показано ниже:

Появится другое окно для регистрации коллектора:

Нажмите «Отправить изменения и далее». Появится новое окно для создания «Нового кластера мониторинга»:

Дайте новому кластеру мониторинга то же имя, которое вы указали в opsview_deploy.yml, например «collectors-de», и выберите коллекторы, которые должны быть в этом кластере мониторинга, из список или коллекторы. Затем нажмите «Отправить изменения».

После добавления первого кластера мониторинга вы также можете зарегистрировать коллектор в существующем кластере мониторинга, выбрав «Существующий кластер». увидеть свои кластеры и количество коллекторов в каждом кластере на вкладке «Кластеры»:

Вы даже можете щелкнуть числа в столбце «СБОРНИКИ», чтобы увидеть имена хостов коллекторов:

После регистрации новых коллекторов перейдите в раздел «Конфигурация» > Примените изменения, чтобы запустить их в производство.

Убедитесь, что коллекторы работают правильно, проверив вкладку «Обзор системы» в разделе «Конфигурация» > «Моя система»:

Чтобы удалить коллектор из кластера, нажмите «КОНФИГУРАЦИЯ > МОНИТОРИНГ КОЛЛЕКТОРОВ» в верхнем меню, а затем щелкните вкладку «Кластеры». Затем щелкните значок меню и «Изменить»:

Затем отмените выбор коллектора, который вы хотите удалить, и нажмите кнопку «Отправить изменения». Теперь вы можете перейти в «Конфигурация» > «Применить изменения», чтобы подтвердить изменение и завершить работу коллектора.

Чтобы добавить коллектор в кластер, отредактируйте кластер, а затем выберите коллектор (используйте Cntrl в Windows или Cmd в Mac OS, чтобы выбрать в дополнение к существующим выборам). Перейдите в «Конфигурация» > «Применить изменения», чтобы подтвердить изменение.

Кластер можно удалить в любое время. Все коллекторы, связанные с кластером, останутся зарегистрированными, но не будут связаны ни с одним кластером.

Узлы, отслеживаемые удаленным кластером, будут изменены для наблюдения за главным кластером (обычно на основном сервере). Вам нужно будет перейти в «Конфигурация»> «Применить изменения», чтобы это вступило в силу.

Если вам нужно вывести Коллектор из эксплуатации, вы должны сделать следующее:

• Удалите Коллектор из всех Кластеров, прежде чем пытаться его удалить. Вы можете удалить Коллекторы из Кластеров на вкладке Кластеры.
• Удалить запись коллектора. Удаление коллектора удалит его из списка известных коллекторов. Вы можете удалить коллекторы на вкладке Коллекторы на странице Конфигурация > Мониторинг коллекторов.
• Удалите связанную запись хоста в настройках хоста, чтобы полностью удалить ее из Opsview.

Примечание: Если вы удалили коллектор, но затем хотите зарегистрировать его снова, вы не увидите, что он станет доступным в сетке незарегистрированных коллекторов, пока вы не остановите планировщик на этом коллекторе хотя бы на целую минуту, а затем перезапустите Это.

Обновить Collector так же просто, как обновить все пакеты Opsview на сервере Collector. Чтобы избежать простоев, отключите соединение от Collector к главному серверу MessageQueue, обновите все пакеты и перезагрузите систему. Как только соединение будет восстановлено, коллектор автоматически присоединится к кластеру, и теперь вы сможете выполнить обновление других коллекторов.

В распределенной системе Opsview Monitor сценарии мониторинга в Collectors могут не синхронизироваться со сценариями в Orchestrator, если:

• новые пакеты Opspack, сценарии мониторинга или подключаемые модули были импортированы в Orchestrator.
Сценарии мониторинга
• были обновлены непосредственно в Orchestrator.

В таких случаях папку сценариев мониторинга ( /opt/opsview/monitoringscripts ) в Оркестраторе необходимо синхронизировать со всеми коллекторами с помощью доступного плейбука под названием 9.0027 sync_monitoringscripts.yml .

Playbook sync_monitoringscripts.yml использует rsync для отправки соответствующих обновлений каждому сборщику (при необходимости он будет установлен автоматически), исключая определенные наборы файлов.

Следующие каталоги и файлы (относительно /opt/opsview/monitoringscripts ) не синхронизируются:

 .../lib/*
.../tmp/*
.../Поделиться/*
.../перл/*
.../плагины/utils.pm
.../вар/*
.../opspacks/*
.../etc/notificationmethodvariables.cfg
.../etc/plugins/check_snmp_interfaces_cascade
 

Например, при использовании приведенного выше списка исключений файлы в каталоге /opt/opsview/monitoringscripts/lib/ и определенные файлы, такие как /opt/opsview/monitoringscripts/etc/notificationmethodvariables. cfg , не будут синхронизированы. .

Кроме того, если у Collector не та же версия ОС, что и у Orchestrator, будут синхронизированы только статически связанные исполняемые файлы и текстовые файлы. Это делается для того, чтобы двоичные файлы, используемые в Orchestrator, не синхронизировались с несовместимым Collector. Например, двоичный файл AMD64 не будет отправлен в коллектор на базе ARM32.

• Интерпретируемые файлы сценариев, такие как сценарии Python, Perl и Bash и файлы конфигурации, являются текстовыми файлами, и будут синхронизированы.
• Динамически связанные исполняемые файлы не будут синхронизированы, поскольку они могут работать неправильно из-за зависимостей во время выполнения. Такие динамически связанные исполняемые файлы необходимо устанавливать на сборщики вручную, если у сборщиков другая версия ОС, чем у Orchestrator.

Ключи SSH настроены между Orchestrator и коллекторами (это уже должно быть на месте, если Opsview Deploy ранее использовался для установки или обновления системы).

Выполните следующие команды от имени пользователя root в Orchestrator:

 cd /opt/opsview/deploy/
bin/opsview-deploy lib/playbooks/sync_monitoringscripts.yml
 

Если ваш сервер развертывания не является Orchestrator, вы можете выполнять те же команды на своем сервере развертывания, но ключи SSH должны быть настроены между Orchestrator и сборщиками для пользователей SSH, определенных для ваших сборщиков в вашем файле opsview_deploy.yml.

Обновлено около 3 лет назад

Использование допусков для управления размещением модуля ведения журнала кластера — Настройка развертывания ведения журнала кластера | Ведение журнала

• Использование допусков для управления размещением модуля хранилища журналов
• Использование допусков для управления размещением модуля визуализатора журнала
• Использование допусков для управления размещением модуля сбора журналов
• Дополнительные ресурсы

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

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

Ключ — это любая строка длиной до 253 символов, а значение — любая строка длиной до 63 символов. Строка должна начинаться с буквы или цифры и может содержать буквы, цифры, дефисы, точки и символы подчеркивания.

Пример регистрации кластера CR с допусками

 apiVersion: "logging.openshift.io/v1"
вид: "ClusterLogging"
метаданные:
  имя: "экземпляр"
  пространство имен: openshift-логирование
спецификация:
  managementState: "Управляемый"
  логсторе:
    тип: "эластичный поиск"
    эластичный поиск:
      количество узлов: 1
      допуски:   (1) 
      - ключ: "регистрация"
        оператор: "Существует"
        эффект: "Не выполнять"
        допустимые секунды: 6000
      Ресурсы:
        пределы:
          память: 8Gi
        Запросы:
          процессор: 100 м
          память: 1Gi
      хранилище: {}
      redundancyPolicy: «Нулевая избыточность»
  визуализация:
    тип: "кибана"
    кибана:
      допуски:   (2) 
      - ключ: "регистрация"
        оператор: "Существует"
        эффект: "Не выполнять"
        допустимые секунды: 6000
      Ресурсы:
        пределы:
          память: 2Gi
        Запросы:
          процессор: 100 м
          память: 1Gi
      реплики: 1
  коллекция:
    журналы:
      тип: "свободный"
      свободно говорил:
        допуски:   (3) 
        - ключ: "регистрация"
          оператор: "Существует"
          эффект: "Не выполнять"
          допустимые секунды: 6000
        Ресурсы:
          пределы:
            память: 2Gi
          Запросы:
            процессор: 100 м
            память: 1Gi 

1	Этот допуск добавлен в модули Elasticsearch.
2	Этот допуск добавлен в модуль Kibana.
3	Этот допуск добавлен к модулям сбора журналов.

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

Вы применяете допуски к модулям хранилища журналов через ClusterLogging пользовательский ресурс (CR) и применить пометки к узлу через спецификацию узла. Заражение на узле — это пара ключ:значение 9.0028 что указывает узлу отклонять все модули, которые не терпят заражения. Использование определенной пары ключ: значение которого нет на других модулях, гарантирует, что на этом узле могут работать только модули хранилища журналов.

По умолчанию модули хранилища журналов имеют следующие допуски:

 допуски:
- эффект: "Не выполнять"
  ключ: «node. kubernetes.io/диск-давление»
  оператор: "Существует" 

Предпосылки

Процедура

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

    $ oc adm taint nodes <имя-узла> <ключ>=<значение>:<эффект> 

   Например:

    $ oc adm taint nodes node1 elasticsearch=node:NoExecute 

   В этом примере заражение размещается на node1 с ключом elasticsearch , значением node и эффектом заражения NoExecute . Узлы с эффектом NoExecute планируют только те модули, которые соответствуют заражению, и удаляют существующие модули. что не совпадают.

2. Отредактируйте раздел logstore в ClusterLogging CR, чтобы настроить допуск для модулей Elasticsearch:

    logStore:
       тип: "эластичный поиск"
       эластичный поиск:
         количество узлов: 1
         допуски:
         - ключ: "elasticsearch"   (1) 
           оператор: "Есть"   (2) 
           эффект: "NoExecute"   (3) 
           допустимые секунды: 6000   (4)  

   1	Укажите ключ, который вы добавили к узлу.
   2	Укажите оператор Exists , чтобы требовать присутствия на узле taint с ключом elasticsearch .
   3	Укажите эффект NoExecute .
   4	При необходимости укажите tolerationSeconds , чтобы указать, как долго модуль может оставаться привязанным к узлу, прежде чем будет вытеснен.

Этот допуск соответствует taint, созданному командой oc adm taint . Модуль с таким допуском может быть запланирован на node1 .

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

Вы применяете допуски к блоку визуализатора журнала через ClusterLogging пользовательский ресурс (CR) и применить пометки к узлу через спецификацию узла. Заражение на узле — это пара ключ:значение , которая указывает узлу отклонять все модули, которые не терпят заражения. Использование определенной пары ключ: значение которого нет на других модулях, гарантирует, что только модуль Kibana может работать на этом узле.

Предпосылки

Процедура

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

    $ oc adm taint nodes <имя-узла> <ключ>=<значение>:<эффект> 

   Например:

    $ oc административные узлы node1 kibana=node:NoExecute 

   В этом примере заражение помещается на node1 с ключом kibana , значением node и эффектом заражения NoExecute . Вы должны использовать эффект заражения NoExecute . NoExecute планирует только те модули, которые соответствуют заражению, и удаляет существующие модули. что не совпадают.

2. Отредактируйте раздел визуализации в ClusterLogging CR, чтобы настроить допуск для модуля Kibana:

    визуализация:
       тип: "кибана"
       кибана:
         допуски:
         - ключ: "кибана"   (1) 
           оператор: "Есть"   (2) 
           эффект: "NoExecute"   (3) 
           допустимые секунды: 6000   (4)  

   1	Укажите ключ, который вы добавили к узлу.
   2	Укажите оператор Exists , чтобы ключ / значение / эффект параметры совпадали.
   3	Укажите эффект NoExecute .
   4	При необходимости укажите параметр tolerationSeconds , чтобы указать, как долго модуль может оставаться привязанным к узлу, прежде чем будет вытеснен.

Этот допуск соответствует taint, созданному командой oc adm taint . Pod с таким допуском сможет запланировать node1 .

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

Вы применяете допуски к модулям сборщика журналов через ClusterLogging пользовательский ресурс (CR) и применить пометки к узлу через спецификацию узла. Вы можете использовать taints и tolerations чтобы гарантировать, что модуль не будет выселен из-за таких вещей, как проблемы с памятью и процессором.

По умолчанию модули сборщика журналов имеют следующие допуски:

 допуски:
- ключ: "node-role.kubernetes.io/master"
  оператор: "Существует"
  эффект: "NoExecute" 

Предпосылки

Процедура

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

    $ oc adm taint nodes <имя-узла> <ключ>=<значение>:<эффект> 

   Например:

    $ oc административные узлы node1 collection=node:NoExecute 

   В этом примере заражение помещается на node1 с ключом коллектор , значением node и эффектом заражения NoExecute . Вы должны использовать эффект заражения NoExecute . NoExecute планирует только те модули, которые соответствуют заражению, и удаляет существующие модули. что не совпадают.

2. Редактирование коллекции раздела ClusterLogging пользовательский ресурс (CR) для настройки допуска для модулей сборщика журналов:

   Коллекция

   :
       журналы:
         тип: "свободный"
         свободно говорил:
           допуски:
           - ключ: "коллектор"   (1) 
             оператор: "Есть"   (2) 
             эффект: "NoExecute"   (3) 
             допустимые секунды: 6000   (4)  

   1	Укажите ключ, который вы добавили к узлу.
   2	Укажите оператор Exists , чтобы ключ / значение / эффект параметры совпадали.
   3	Укажите эффект NoExecute .
   4	При необходимости укажите параметр tolerationSeconds , чтобы указать, как долго модуль может оставаться привязанным к узлу, прежде чем будет вытеснен.

Этот допуск соответствует taint, созданному командой oc adm taint . Pod с таким допуском сможет запланировать node1 .

Sharding-Руководство MongoDB

на этой странице

• Sharded Cluster
• Шард Клавиши
• Куски
• Балансировщик и равномерное распределение Chunk
• .0008
• Подключение к разделенному кластеру
• Стратегия разделения
• Зоны в разделенных кластерах
• Сопоставления в разделении
• Потоки изменений
• машины. MongoDB использует сегментирование для поддержки развертываний с очень большими данными. наборы и высокопроизводительные операции.

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

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

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

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

  MongoDB поддерживает горизонтальное масштабирование посредством сегментирования.

  Sharded Cluster

  Sharded кластер MongoDB состоит из следующих компонентов:

  • сегмент: Каждый сегмент содержит подмножество сегментированных данных. Каждый сегмент можно развернуть как набор реплик.

  • монго: монго действует как Маршрутизатор запросов, обеспечивающий интерфейс между клиентскими приложениями и сегментированный кластер. Начиная с MongoDB 4.4, монгос может поддерживать хеджированные чтения для минимизации задержек.

  • серверы конфигурации: Конфигурация серверы хранят метаданные и параметры конфигурации для кластера.

  На следующем рисунке показано взаимодействие компонентов внутри сегментированный кластер:

  MongoDB осколки данных на уровне коллекции, распределяя сбор данных по осколкам в кластере.

  Осколочные ключи

  MongoDB использует осколочный ключ для распределять документы коллекции по осколкам. Осколочный ключ состоит из поля или нескольких полей в документах.

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

  • В версии 4.2 и более ранних поля ключа сегмента должны существовать в каждом документ для сегментированной коллекции.

  Вы выбираете ключ сегмента при сегментировании коллекции.

  • Начиная с MongoDB 5.0, вы можете повторно разделить коллекцию, изменив ключ сегмента коллекции.

  • Начиная с MongoDB 4.4, вы можете уточнить ключ сегмента, добавив поле или поля суффикса к существующему осколочный ключ.

  • В MongoDB 4.2 и более ранних версиях выбор ключа сегмента невозможен. быть изменены после шардинга.

  Значение ключа сегмента документа определяет его распределение по осколки.

  • Начиная с MongoDB 4.2, вы можете обновить значение ключа сегмента документа если ваше поле ключа осколка не является неизменным _id поле. Видеть Измените значение ключа сегмента документа для получения дополнительной информации.

  • В MongoDB 4.0 и более ранних версиях значение поля ключа сегмента документа равно неизменный.

  Индекс ключа сегмента

  Чтобы сегментировать заполненную коллекцию, она должна иметь индекс, который начинается с ключа сегмента. При разбивании пустого коллекция, MongoDB создает вспомогательный индекс, если коллекция еще не имеют соответствующего индекса для указанного ключа сегмента. Видеть Индексы Shard Key.

  Стратегия ключа сегмента

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

  См. также:

  Выберите ключ сегмента

  Фрагменты

  MongoDB разделяет сегментированные данные на фрагменты. Каждый чанк имеет инклюзивный нижний и исключительный верхний диапазон на основе осколочный ключ.

  Балансировщик и равномерное распределение чанков

  В попытке добиться равномерного распределения чанков по всем шардов в кластере, балансировщик работает в фоновом режиме, чтобы переносить куски по осколкам.

  См. также:

  Разделение данных на фрагменты

  Преимущества сегментирования

  Чтение/запись

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

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

  Начиная с MongoDB 4.4, mongos могут поддерживать хеджирование читает, чтобы минимизировать задержки.

  Емкость хранилища

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

  Высокая доступность

  Развертывание серверов конфигурации и сегментов, предоставляемых наборами реплик повышенная доступность.

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

  Соображения перед шардингом

  Требования к инфраструктуре шардированного кластера и сложность требуют тщательное планирование, выполнение и обслуживание.

  После разделения коллекции MongoDB не предоставляет методов для разблокировать раздробленную коллекцию.

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

  См. также:

  Выберите ключ сегмента

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

  Если запросы делают , а не включают ключ сегмента или префикс составной осколочный ключ, mongos выполняет широковещательная операция, запрос все сегментов в сегментированном кластере. Эти запросы на разброс/сбор могут быть длительными операциями.

  Запуск в MongoDB 5.1, при запуске, перезапуске или добавлении шард-сервер с sh.addShard() Проблема записи в масштабе кластера (CWWC) должен быть установлен.

  Если CWWC не установлен и шард настроен так что проблема записи по умолчанию { w : 1 } сервер сегмента не запустится или не будет добавлен и возвращает ошибку.

  См. расчеты записи по умолчанию для подробности о том, как рассчитывается проблема записи по умолчанию.

  Если у вас есть действующий контракт на поддержку с MongoDB, рассмотрите возможность обращения вашему представителю по работе с клиентами для помощи с шардированным кластером планирование и развертывание.

  Разделенные и неразделенные коллекции

  База данных может содержать как разделенные, так и неразделенные коллекции. Разделенный коллекции разделены и распределены по осколки в кластере. Нераспределенные коллекции хранятся на первичный осколок. Каждая база данных имеет свой основной шард.

  Подключение к разделенному кластеру

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

  Вы можете подключиться к mongos так же, как вы подключаетесь к mongod с использованием mongosh или Драйвер MongoDB.

  Стратегия разделения

  MongoDB поддерживает две стратегии сегментирования для распространения данных через сегментированные кластеры.

  Разделение по хэшу

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

  MongoDB автоматически вычисляет хэши при разрешении запросов с использованием хешированные индексы. Приложения , а не должны вычислять хэши.

  Хотя диапазон ключей осколков может быть «близким», их хешированные значения маловероятны. быть на одном куске. Распределение данных на основе хешированных значений способствует более равномерному распределению данных, особенно в наборах данных, где ключ шарда изменяется монотонно.

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

  Дополнительную информацию см. в разделе Разделение хеширования.

  Разделение по диапазонам

  Разделение по диапазонам включает разделение данных на диапазоны на основе значения ключа шарда. Затем каждому фрагменту назначается диапазон на основе значения ключа шарда.

  Диапазон ключей осколков со значениями «близко» с большей вероятностью будет находиться на тот самый кусок. Это позволяет целенаправленно операции как mongos может маршрутизировать операции только с теми осколками, которые содержат необходимые данные.

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

  Дополнительные сведения см. в разделе Разделение на расстоянии.

  Зоны в сегментированных кластерах

  Зоны могут помочь улучшить локальность данных для сегментированных кластеров, которые охватывать несколько центров обработки данных.

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

  Каждая зона охватывает один или несколько диапазонов значений ключа сегмента. Каждый диапазон Покрытия зоны всегда включают ее нижнюю границу и исключают ее верхняя граница.

  Вы должны использовать поля, содержащиеся в ключе сегмента, при определении нового диапазон охвата зоны. При использовании составного осколка key, диапазон должен включать префикс ключа сегмента. См. ключи осколков в зонах для получения дополнительной информации.

  Следует принять во внимание возможное использование зон в будущем внимание при выборе шардового ключа.

  Начиная с MongoDB 4.0.3, настройка зон и диапазонов зон до вы разбиваете пустую или несуществующую коллекцию, что позволяет быстрее настройка зонального шардинга.

  Дополнительную информацию см. в зонах.

  Сопоставления в сегментировании

  Используйте команду shardCollection с сопоставлением : { locale : "simple" } параметр для разделения коллекции, которая имеет сопоставление по умолчанию. Успешный шардинг требует, чтобы:

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

  Запросы к сегментированной коллекции продолжают использовать значение по умолчанию параметры сортировки, настроенные для коллекции. Чтобы использовать осколочный ключ индекс простая сортировка , укажите {локаль: "простая"} в документе сопоставления запроса.

  См. shardCollection для получения дополнительной информации о сегментировании и сопоставление.

  Потоки изменений

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

  Транзакции

  Начиная с MongoDB 4.2, с введением распределенной операции, многодокументные операции доступны в сегментированных кластерах.

  Пока транзакция не будет зафиксирована, изменения данных, сделанные в транзакции не видны вне транзакции.

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