#openstack
#openstack
Вопрос:
У меня возникла проблема с относительно небольшим кластером openstack, развернутым с помощью kolla-ansible. Проблема в том, что через несколько дней контроллеры перестают работать. Когда я захожу в журналы контейнера docker, я вижу во всех из них, что слишком много открытых файлов. Я попытался изменить файлы limits.conf sysctl max для процессов и пользователя. После всего этого проблема все еще появляется.
Интересно то, что этого не происходило, пока мне не пришлось перезагрузить все контроллеры. Я перезагрузил их, потому что мне нужно было увеличить объем оперативной памяти, который у них есть после того, как они перестали обмениваться. Моей первой мыслью было, что kolla-ansible устанавливает конфигурацию после запуска deploy, но, похоже, я не могу найти какой-либо точки в репозитории, когда kolla-ansible меняет ограничения или другие.
Любые теории, что может вызвать это? Будет ли это связано с увеличением оперативной памяти? Должен ли я запускать перенастройку / развертывание на каждом контроллере? Я попытался заглянуть в документы и форумы kolla-ansible и не смог увидеть, где у кого-либо еще была эта проблема.
Обновление это еще не исправлено: я отправил сообщение об ошибке, https://bugs .launchpad.net/kolla-ansible/ bug/1901898
Комментарии:
1. Какие контейнеры показывают это сообщение?. Я вообще не знаком с kolla, но у клиента также было «слишком много открытых файлов» в простой облачной настройке (один управляющий узел, дюжина вычислительных узлов, без контейнеров). В этом случае apache был ограничен 1024, но запрашивал больше (многие пользователи обращались к keystone, dashboard и т. Д.). Я создал выпадающий файл для apache и увеличил значение примерно до 16 кб или около того (
systemctl edit apache).2. Тот, который я проверяю после их разрыва, — это Memcached, но, по сути, все они имеют некоторую итерацию ошибки слишком много файлов. Я забыл упомянуть, что я также проверил, чтобы убедиться, что ограничения docker были установлены достаточно высоко, и они, казалось, были установлены на БЕСКОНЕЧНОСТЬ.
3. Возможно, кто-то еще, обладающий большими знаниями о docker и kolla, может помочь, я имел дело только с отдельными системными модулями, для которых требовался более высокий лимит.
Ответ №1:
Я не знаю ваших используемых версий Kolla-Ansible и вашего Linux, но ваша проблема, похоже, действительно связана с этим:
On Ubuntu 16.04, please uninstall lxd and lxc packages. (An issue exists with cgroup mounts, mounts exponentially increasing when restarting container) (источник: docs.openstack.org/kolla-ansible/4.0.0/quickstart.html )
У меня была эта проблема с экспоненциально растущим числом указателей монтирования после перезапуска моих докер-контейнеров. Из-за этой проблемы мое тестовое развертывание с одним узлом стало очень медленным, но на данный момент я не могу вспомнить, чтобы у меня была такая же ошибка со слишком большим количеством открытых файлов.
Вы можете удалить пакеты с apt-get remove lxc-common lxcfs lxd lxd-client помощью . Я выполнил это исправление вместе с полной переустановкой установки kolla-ansible, поэтому я не знаю, поможет ли это также с уже существующей установкой. Вы также должны использовать docker-ce вместо docker из apt-репозиториев.
Комментарии:
1. Это имеет смысл. Я использую CentOS 8 и версию kolla-ansible версии 10.1. Он устанавливает версию docker 19.03.12 с помощью bootstrap. Позвольте мне разобраться с концепцией lxd / lxc, чтобы узнать, существует ли она.
2. Похоже, что ни один из этих пакетов не установлен. Я повторно запускаю развертывание на одном из контроллеров, поэтому я подожду, чтобы увидеть, сделает ли он это снова на этом. Для этого требуется несколько дней. Моя теория заключается в том, что во время начальной загрузки / развертывания что-то изменяется или что-то еще, что при увеличении объема оперативной памяти для виртуальной машины / контроллера vmware openstack после первого развертывания что-то ломается. Если повторное развертывание не сработает, я сотру этот контроллер и повторно разверну с нуля, хотя это не исправить: D.
Ответ №2:
Это было исправлено с помощью обходного пути в bug https://bugs .launchpad.net/keystonemiddleware/ bug/1883659 проблема заключалась в том, что сервер neutron поддерживал открытые соединения memcached и не закрывал их до тех пор, пока контейнер memcached не откроет слишком много файлов. Существует обходной путь, упомянутый в ссылке на ошибку.