【Ctrip.com Ву Сяоган】
В настоящее время ElasticSearch в основном используется в двух сценариях приложений в интернет-компаниях. Один из них заключается в создании модулей функций поиска для предприятий, и большинство из них представляет собой поиск в вертикальных полях. Объем данных обычно находится на уровне от десятков до миллиардов; время OLAP для крупномасштабных данных, таких как ELKStack, масштаб данных может достигать 100 миллиардов и более. Шаблоны индексации данных и доступа к приложениям в этих двух сценариях сильно различаются, и внимание к выбору оборудования и оптимизации кластера также будет разным. Вообще говоря, последний сценарий относится к категории больших данных, объем данных и масштаб кластера больше, а управление сложнее.
По приглашению Medcl я начну Advent этого года для китайского сообщества ES и поделюсь своим опытом управления кластером ES моей собственной компании для анализа логов.
Дом здесь Ctrip.com. С тех пор, как мы начали обращаться к ES в 2013 году, наша команда практиковала промежуточные версии 0.9.x -> 5.0.0, изначально использовалась только для анализа внутренних логов IIS на предмет эксплуатации и обслуживания, а теперь поддерживает ИТ, звоните центр, безопасность, тестирование, бизнес Извлечение и анализ в режиме реального времени более 200 лог-данных в R&D и других отделах. Попутно я всем радуюсь, а себе тоже умираю.
В настоящее время наш крупнейший кластер с одним журналом включает 120 узлов данных, работающих на 70 физических серверах. Шкала данных следующая:
Каковы важные моменты для эксплуатации и обслуживания такого крупномасштабного кластера ES?
1. Основные инструменты
Если вы хотите преуспеть, вы должны сначала отточить свои инструменты.С самого начала, даже если есть всего несколько узлов, вы должны использовать инструменты управления распределенной конфигурацией для развертывания кластера. По мере развития приложения и постепенного увеличения масштаба кластера повышение эффективности будет заметным. Модуль ES Puppet и Chef Cookbook официально предоставлены студентам, которые знакомы с этими двумя инструментами, могут использовать их напрямую. Мы сами использовали Ansible и написали набор Playbook для достижения аналогичного эффекта. Если вы знакомы с такими инструментами, начальное развертывание кластера, пакетное изменение конфигурации, обновление версии кластера и перезапуск неисправных узлов будут намного быстрее и безопаснее.
Второй обязательный инструмент — это плагин sense. Используя этот плагин для прямого вызова restful API кластера, очень удобно просматривать состояние кластера и индекса и изменять конфигурацию индекса. Грамматические подсказки и автозаполнение более практичны, уменьшая частоту пролистывания документов. В Kibana5 сенс стал встроенной консолью, дополнительной установки не требуется.
2. Конфигурация оборудования
Мы используем сервер с 32vcoreCPU + 128GB RAM.Большинство серверов представляют собой RAID0, состоящий из 12 механических дисков SATA по 4 ТБ, а несколько машин представляют собой только что установленные 6 частей SSD RAID0 по 800 ГБ.Основная цель - делать горячие и холодные Разделение, когда мы поговорим об архитектуре кластера позже, мы объясним, как использовать аппаратные ресурсы.
3. Управление кластером
4. Выбор версии
У нас давно стабильно работает на версии 2.4, более консервативные студенты могут перейти на 2.4, а агрессивные и энергичные могут рассмотреть последнюю 5.0. Наш кластер был обновлен с версии 2.4.0 до версии 5.0.0 две недели назад.Помимо нестабильной проблемы в первую неделю обновления, я считаю, что следующие функции новой версии заслуживают обновления:
В течение первой недели обновления наши холодные узлы данных периодически не отвечали, поэтому мы выявили 3 проблемы и отправили их официальному лицу:
Issue#21595 Issue#21612 Issue#21611
Подтверждено, что первая проблема является ошибкой и будет исправлена в версии 5.0.2.Два других до сих пор неясны в отношении основной причины и, похоже, встречаются только в сценарии нашего приложения. К счастью, мы нашли обходные пути решения проблемы, и после реализации этих мер наш кластер на прошлой неделе вернулся в стабильное состояние предыдущей версии 2.4.
V. Мониторинг
Предложение состоит в том, чтобы купить официальный xpack для душевного спокойствия.Если у вас есть энергия, чтобы бросить, вы можете использовать различные API статистики ES, собирать данные с помощью ваших знакомых инструментов мониторинга и визуализировать их. При таком количестве индикаторов мониторинга наиболее важными являются следующие категории:
Последнее, что нужно сделать, это начать и больше практиковаться. Если у вас возникнут проблемы, проверьте больше официальных документов и Google, чтобы узнать, не сталкивались ли другие люди с подобными проблемами. Студенты с достаточным уровнем энергии и опытом программирования также могут копать больше исходного кода.
В настоящее время ElasticSearch в основном используется в двух сценариях приложений в интернет-компаниях. Один из них заключается в создании модулей функций поиска для предприятий, и большинство из них представляет собой поиск в вертикальных полях. Объем данных обычно находится на уровне от десятков до миллиардов; время OLAP для крупномасштабных данных, таких как ELKStack, масштаб данных может достигать 100 миллиардов и более. Шаблоны индексации данных и доступа к приложениям в этих двух сценариях сильно различаются, и внимание к выбору оборудования и оптимизации кластера также будет разным. Вообще говоря, последний сценарий относится к категории больших данных, объем данных и масштаб кластера больше, а управление сложнее.
По приглашению Medcl я начну Advent этого года для китайского сообщества ES и поделюсь своим опытом управления кластером ES моей собственной компании для анализа логов.
Дом здесь Ctrip.com. С тех пор, как мы начали обращаться к ES в 2013 году, наша команда практиковала промежуточные версии 0.9.x -> 5.0.0, изначально использовалась только для анализа внутренних логов IIS на предмет эксплуатации и обслуживания, а теперь поддерживает ИТ, звоните центр, безопасность, тестирование, бизнес Извлечение и анализ в режиме реального времени более 200 лог-данных в R&D и других отделах. Попутно я всем радуюсь, а себе тоже умираю.
В настоящее время наш крупнейший кластер с одним журналом включает 120 узлов данных, работающих на 70 физических серверах. Шкала данных следующая:
- Количество данных индекса за один день — 60 миллиардов, а размер нового файла индекса — 25 ТБ (50 ТБ с одной репликой).
- Пиковая скорость индексирования поддерживается на уровне одного миллиона элементов в секунду в часы пик.
- Срок хранения исторических данных определяется в соответствии с потребностями бизнеса и составляет от 10 до 90 дней.
- Всего в кластере 3441 индекс, 17000 шардов, общий объем данных около 930 миллиардов, а общее потребление диска 1ПБ.
- Пользователей Kibana более 600, и каждый день происходит 630 000 вызовов API от Kibana и третьих лиц.
- Процентиль времени ответа на запрос 75 %: 0,160 с 90 %: 1,640 с 95 %: 6,691 с 99 %: 14,0039 с
Каковы важные моменты для эксплуатации и обслуживания такого крупномасштабного кластера ES?
1. Основные инструменты
Если вы хотите преуспеть, вы должны сначала отточить свои инструменты.С самого начала, даже если есть всего несколько узлов, вы должны использовать инструменты управления распределенной конфигурацией для развертывания кластера. По мере развития приложения и постепенного увеличения масштаба кластера повышение эффективности будет заметным. Модуль ES Puppet и Chef Cookbook официально предоставлены студентам, которые знакомы с этими двумя инструментами, могут использовать их напрямую. Мы сами использовали Ansible и написали набор Playbook для достижения аналогичного эффекта. Если вы знакомы с такими инструментами, начальное развертывание кластера, пакетное изменение конфигурации, обновление версии кластера и перезапуск неисправных узлов будут намного быстрее и безопаснее.
Второй обязательный инструмент — это плагин sense. Используя этот плагин для прямого вызова restful API кластера, очень удобно просматривать состояние кластера и индекса и изменять конфигурацию индекса. Грамматические подсказки и автозаполнение более практичны, уменьшая частоту пролистывания документов. В Kibana5 сенс стал встроенной консолью, дополнительной установки не требуется.
2. Конфигурация оборудования
Мы используем сервер с 32vcoreCPU + 128GB RAM.Большинство серверов представляют собой RAID0, состоящий из 12 механических дисков SATA по 4 ТБ, а несколько машин представляют собой только что установленные 6 частей SSD RAID0 по 800 ГБ.Основная цель - делать горячие и холодные Разделение, когда мы поговорим об архитектуре кластера позже, мы объясним, как использовать аппаратные ресурсы.
3. Управление кластером
- В первую очередь необходимо разделить и обособить роли узлов ЭС. Мы все знаем, что узел данных ES может также играть роли хозяина и клиента в дополнение к данным.Большинство студентов будут смешивать эти роли в узле данных. Однако для крупномасштабного кластера с большим количеством пользователей мастер и клиент могут иметь узкие места в производительности или даже переполнение памяти в некоторых экстремальных случаях использования, что может привести к сбою сосуществующих узлов данных. Восстановление после сбоя узлов данных связано с миграцией данных, которая в определенной степени потребляет ресурсы кластера, что может привести к задержке записи данных или замедлению выполнения запросов. Если мастер и клиент независимы, при возникновении проблемы она будет восстановлена почти мгновенно после перезапуска и почти не повлияет на пользователей. Кроме того, после того, как эти роли станут независимыми, соответствующее потребление вычислительных ресурсов также будет изменено с данных Легче понять взаимосвязь между потреблением ресурсов узла данных и объемом записи и объемом запросов, разделив узел, что удобно для управления емкостью и планирования.
- Избегайте чрезмерного параллелизма, в том числе контролируйте количество сегментов и пулов потоков. Исходя из того, что объем записи и производительность запросов могут быть удовлетворены, выделите для индекса как можно меньше сегментов. Слишком большое количество осколков приведет к множеству негативных последствий, таких как необходимость агрегирования и сортировки большего количества данных после каждого запроса; слишком высокая загрузка ЦП, вызванная переключением потоков из-за слишком большого параллелизма; более медленное удаление индекса и обновление конфигурации.Issue#18776; Слишком большое количество сегментов также приводит к увеличению количества мелких сегментов, а слишком большое количество мелких сегментов может привести к значительному потреблению памяти кучи, особенно если настроено много потоков запросов. Настройка слишком большого пула потоков вызовет множество странных проблем с производительностью.Issue#18161Описанные здесь проблемы - это то, с чем мы столкнулись. Размер Theadpool по умолчанию обычно работает хорошо.
- Лучше всего разделить горячие и холодные данные. Для лог-приложений новый индекс обычно создается каждый день, а у горячего индекса дня будет больше запросов во время записи. Если все еще есть «холодные» данные давнего прошлого, когда пользователи запрашивают исторические данные с большим диапазоном, чрезмерная нагрузка на дисковый ввод-вывод и ЦП может легко замедлить запись и вызвать задержку данных. Поэтому мы используем некоторые машины для хранения холодных данных.С помощью ES мы можем настраивать пользовательские атрибуты для узлов, добавлять «boxtype»: «weak» для холодных узлов и каждую ночь обновлять холодные данные с помощью сценариев обслуживания.index.routing.allocation.{require|include|exclude}, позвольте данным автоматически переноситься на холодный узел. Характеристика холодных данных заключается в том, что они больше не записываются, и частота проверки пользователем низкая, но величина может быть большой. Например, у нас есть индекс 2 ТБ в день, и пользователь запрашивает, чтобы данные за последние 90 дней были доступны в любое время. Сохранение такого большого количества открытых индексов требует не только места на диске. Для быстрого доступа к индексному файлу на диске ES необходимо хранить некоторые данные (индекс индексного файла) в памяти, которая является так называемой сегментной памятью. Студенты, немного знакомые с ES, знают, что выделение кучи JVM не может превышать 32 ГБ.Для нашей машины с 128 ГБ ОЗУ и 48 ТБ дискового пространства, если мы запускаем только один экземпляр ES, мы можем использовать только кучу менее 32 ГБ. индексный файл, сохраненный на диске, был меньше 10 ТБ, что было явно неэкономично. Поэтому мы решили запустить 3 экземпляра ES на холодном узле, каждый с 31 ГБ пространства кучи, чтобы более 30 ТБ индексных данных можно было хранить на физическом сервере и открывать для пользователей для поиска в любое время. При фактическом использовании, из-за низкой частоты холодного поиска данных и отсутствия записи, даже если для ОС остается только 35 ГБ памяти в качестве кеша файловой системы, производительность запросов все равно может удовлетворить спрос.
- Шарды с разными уровнями данных лучше всего изолировать по разным группам узлов. Всем известно, что ES сама будет балансировать распределение шардов в кластере, логика этой автоматической балансировки в основном учитывает три фактора. Во-первых, шарды под одним индексом должны быть максимально распределены по разным узлам, во-вторых, количество шардов на каждом узле должно быть как можно ближе, на дисках третьих узлов достаточно свободного места. Эта стратегия может гарантировать только равномерное распределение количества сегментов, но не гарантирует равномерного распределения размера данных. В практических приложениях у нас есть более 200 видов индексов, и величины данных сильно различаются, от нескольких терабайт в день до нескольких гигабайт в месяц, и время хранения каждого типа данных сильно различается. Возникает вопрос, как сбалансировать и полностью использовать ресурсы всех узлов. В ответ на эту проблему мы по-прежнему выполняем группировку, добавляя метки атрибутов к узлам, и применяем некоторые детализированные элементы управления в сочетании с управлением маршрутизацией индексов. Попробуйте использовать разные группы узлов для данных разной величины, чтобы количество данных на узлах в каждой группе было легче автоматически сбалансировать.
- Периодически выполняйте принудительное слияние индексов, и лучше всего объединять каждый шард в сегмент. Как упоминалось ранее, потребление кучи также связано с количеством сегментов, и принудительное слияние может значительно сократить это потребление. Еще одним преимуществом объединения в сегмент является то, что для агрегации терминов нет необходимости строить глобальные порядковые номера при поиске, что может повысить скорость агрегации.
4. Выбор версии
У нас давно стабильно работает на версии 2.4, более консервативные студенты могут перейти на 2.4, а агрессивные и энергичные могут рассмотреть последнюю 5.0. Наш кластер был обновлен с версии 2.4.0 до версии 5.0.0 две недели назад.Помимо нестабильной проблемы в первую неделю обновления, я считаю, что следующие функции новой версии заслуживают обновления:
- В процесс запуска узла Bootstrap добавлена проверка многих ключевых параметров системных параметров, таких как максимальное количество файловых дескрипторов, блокировка памяти, параметры виртуальной памяти и т. д. Если параметры неверны, он откажется запускаться и выдаст исключение. Вместо того, чтобы запускать систему с неправильными параметрами и впоследствии вызывать проблемы с производительностью, лучше информировать пользователя о проблеме в случае сбоя запуска, что является хорошим решением!
- Повышение производительности индексации. После обновления при той же скорости индекса мы видим, что потребление ЦП значительно снизилось.Помимо увеличения скорости индекса, это также в определенной степени увеличит скорость поиска.
- Новая числовая структура данных, меньше места для хранения, более быстрые расчеты диапазона и географического местоположения
- Instant Aggregation может выполнять кэширование для агрегирования запросов диапазона, таких как now-7d to now. При реальном использовании эффект очевиден. Пользователь запускает агрегацию данных за прошедшую неделю на Kibana. Первые 2 обновления медленные, а затем почти кэш.Сразу вычесать!
- Дополнительные меры защиты обеспечивают стабильность кластера, например, ограничение количества осколков, в которых можно искать совпадения за раз, улучшение характеристик прерывателя цепи и лучшее предотвращение исчерпания ресурсов кластера неправильными запросами.
В течение первой недели обновления наши холодные узлы данных периодически не отвечали, поэтому мы выявили 3 проблемы и отправили их официальному лицу:
Issue#21595 Issue#21612 Issue#21611
Подтверждено, что первая проблема является ошибкой и будет исправлена в версии 5.0.2.Два других до сих пор неясны в отношении основной причины и, похоже, встречаются только в сценарии нашего приложения. К счастью, мы нашли обходные пути решения проблемы, и после реализации этих мер наш кластер на прошлой неделе вернулся в стабильное состояние предыдущей версии 2.4.
V. Мониторинг
Предложение состоит в том, чтобы купить официальный xpack для душевного спокойствия.Если у вас есть энергия, чтобы бросить, вы можете использовать различные API статистики ES, собирать данные с помощью ваших знакомых инструментов мониторинга и визуализировать их. При таком количестве индикаторов мониторинга наиболее важными являются следующие категории:
- Использование различных пулов потоков отображается в файле active/queue/reject. Чтобы определить, есть ли у кластера узкое место в производительности, проверьте, очень ли высоки различные очереди в период пиковой нагрузки и часто ли происходит отклонение.
- Используемый % кучи JVM и частота старого GC, если частота старого GC очень высока, а используемый % кучи вряд ли может снизиться после нескольких GC, это означает, что давление кучи слишком велико, и расширение должно считать. (Это также может быть вызвано проблемным запросом или агрегацией, о которой необходимо судить на основе записей о доступе пользователей).
- Размер сегментной памяти и количество сегментов. Когда на узле хранится много индексов, эти два индикатора заслуживают внимания.Необходимо знать, что память сегмента находится в куче и не будет восстановлена сборщиком мусора.Поэтому, когда давление кучи слишком велико , вы можете комбинировать этот индикатор, чтобы определить, связано ли это со слишком большим объемом данных, хранящихся на узле, и их необходимо расширить. Критично и количество сегментов, если мелких сегментов много, например несколько тысяч, то даже если памяти самого сегмента немного, все равно будет съеден немалый объем кучи при большом количестве поисковых потоков. в теме Информация о состоянии записывается локально, а накладные расходы памяти кучи этого блока связаны с (номер сегмента * номер потока).
- Необходимо записывать записи доступа пользователя. Мы открываем только http API для пользователей, добавляем nginx в качестве http-прокси и записываем все записи доступа сторонних API пользователей через журнал доступа. Анализируя записи доступа, когда в кластере возникает проблема с производительностью, вы можете быстро найти основную причину проблемы, что очень полезно для устранения неполадок и оптимизации производительности.
Последнее, что нужно сделать, это начать и больше практиковаться. Если у вас возникнут проблемы, проверьте больше официальных документов и Google, чтобы узнать, не сталкивались ли другие люди с подобными проблемами. Студенты с достаточным уровнем энергии и опытом программирования также могут копать больше исходного кода.