предисловие
Как мы узнали ранее, в обязанности главного узла входит:
- Он отвечает за принятие решения о том, какому узлу назначить текущий сегмент.
- Перемещайте сегменты между узлами, чтобы обеспечить баланс кластера. и т.п.
Распределение сегментов — на основе конфигурации кластера
Распределение сегментов относится к процессу выделения сегментов хост-узлу. Триггерные сценарии:
- Инициализировать восстановление
- Распределение копий сегментов
- Кластерный баланс
- Добавить или удалить узлы кластера
Распределение осколков оказывает важное влияние на весь кластер ES, так как быть знакомым и контролем, это очень важное значение знаний. ES-Cluster предоставляет настройки, для которых могут выделить кластер кластера, включая все осколки (по умолчанию), первичные осколки, первичные осколки для новых индексов и отключение всех индексов для выделения осколков. Эти варианты.
Вам может показаться странным, что распределение осколков запрещено, так как же еще вы можете играть?
Существование разумно. Это свойство очень полезно при эксплуатации и обслуживании кластеров (последовательные перезапуски, обслуживание кластера и отсрочка выделения сегментов). Например, после закрытия узла вручную кластер будет работать после фиксированного временного окна. Найдите потерю узлов и запустить балансировку данных, эта операция достаточно трудоемка для балансировки нескольких шардов с большим объемом данных, поэтому в этом случае можно сначала запретить шарды выделения индекса на уровне кластера, После обслуживания установите его снова.
Сводка: Используйте это, чтобы отложить перемещение сегмента реплики, когда вы знаете, что узел быстро восстановится после сбоя.
index.unassigned.node_left.delayed_timeout
Дает вашему кластеру время, чтобы определить, присоединится ли узел, прежде чем запускать перераспределение.
-
Отложенное выделение не препятствует повышению уровня реплик до основных сегментов. Кластер немедленно выполнит необходимые действия, чтобы вернуть кластер в желтое состояние. Реконструкция отсутствующих реплик — единственный объект этой конфигурации, управляющий задержкой. То есть этот delayed_timeout работает только при пересборках реплик.
-
Что не упоминается на рисунке, так это то, что если узел, который не работает, является узлом Master, кластер выполнит еще один шаг действия [select the master], потому что для нормальной работы кластера его необходимо выбрать из главный узел-кандидат (настройте node.master: true ), чтобы выбрать главный узел.
Предотвращение запуска нескольких экземпляров на хосте
Когда ресурсов ЦП и памяти много, один хост может использоваться для запуска нескольких экземпляров, что может в определенной степени полностью использовать ресурсы, но это также сопряжено с рисками. В качестве примера возьмем хост, запускающий два экземпляра.
Как видно из рисунка, два экземпляра es, node-1 и node-2, развернуты на хосте 192.161.11.12.
Если у этого индекса есть 1 реплика, осколок 1 и его реплика на графе сегментируются на узел-1 и узел-2 соответственно.
В этом случае доступность относительно низкая, если хост выйдет из строя, Тогда все данные осколка 1 этого индекса будут потеряны.
Как избежать этой ситуации? Конечно, чтобы не запускать несколько экземпляров на хосте, Или установив: cluster.routing.allocation.same_shard.host: true. чтобы этого не произошло.
Распределение Shard - на основе осведомленности диска
В дополнение к рассмотрению выделения сегментов на общем уровне кластера, elasticsearch также учитывает факторы среды, такие как доступное дисковое пространство.
- Когда elasticsearch выделяет сегменты узлам узла, он учитывает доступное дисковое пространство. disk.watermark.low представляет нижний водяной знак использования диска, который по умолчанию составляет 85%. Эта конфигурация означает, что es не будет выделять сегменты узлам, превышающим это значение. Этот параметр не влияет на основной сегмент вновь созданного индекса. , Влияет, но не дает выделять их копии.
Точно так же существует конфигурация высокого водяного знака disk.watermark.high. Значение по умолчанию — 90%, что означает, что Elasticsearch попытается отделить осколки от узлов с использованием диска более 90%. Эта конфигурация также влияет на баланс кластера.
Конфигурация последнего средства для предотвращения нехватки дискового пространства на узлах, disk.watermark.flood_stage, по умолчанию равна 95%, обеспечивает доступ только для чтения для защиты кластеров и хостов.
Осведомленность о стойке
Информация о стойке позволяет elasticsearch учитывать конфигурацию физического оборудования при выделении сегментов. Преимущество восприятия конфигурации физического оборудования заключается в том, что при возникновении проблем с оборудованием, таким как физическая машина или та же стойка, когда в определенной комнате с оборудованием возникает проблема, полагаясь на физическое восприятие, ищите оптимальную конфигурацию развертывания, чтобы обеспечить доступность кластера в наибольшей степени.
Однако простое развертывание не может сообщить о соответствующем физическом развертывании, поэтому нам нужно указать значение соответствующей конфигурации, чтобы сообщить es. Существует два конкретных метода настройки:
-
/bin/elasticsearch -Enode.attr.rack_id=rack_one` указывается при запуске.
-
cluster.routing.allocation.awareness.attributes: идентификатор стойки, указанный в файле конфигурации.
-
es может рассмотреть возможность настройки разных узлов для разных физических машин.
-
Разные узлы назначаются разным физическим стойкам.
-
Разные узлы назначаются разным областям сети.
теория CAP
Sensing Sensing необходимо учитывать (надежность взвешивания, доступность, потребление пропускной способности и т. Д.). Elasticsearch действует как распределенный компонент, P (неисправность разбиения) в характеристиках CAP необходимо учитывать. Расскажите взгляд на популярном языке: мы знаем, каждый узел кластера ES должен быть подключен друг к другу. Тем не менее, будь то среда все еще человеческим фактором, можно нефункциональность, а сеть может быть разделена на несколько зон. Если данные сохраняются только на одном узле, то невозможно подключить эти данные, то мы говорим, что недопустимо разделить.
Фильтрация распределения сегментов
Позволяет исключить определенные узлы или определенные группы узлов из назначения, чтобы деактивировать их. Сценарий приложения здесь таков: когда мы планируем закрыть узел, мы можем избежать попадания вновь созданных осколков индекса на этот узел.
Суммировать
- Наименьшая единица работы elasticsearch — сегментирование, поэтому очень важно освоить, как сегменты распределяются на узлах.Благодаря сортировке мы можем понять влияние отказа узла на кластер.
- Распределение осколков с учетом диска.
- Распределение осколков с учетом стойки.
- Краткое понимание p (отказоустойчивости раздела) в теории CAP.
- Исключайте узлы, не выделяйте осколки и гибко отключайте узлы.
Добро пожаловать в официальный аккаунт [заметки Сямэна о разработке], чтобы общаться и развиваться вместе