У меня есть довольно простая установка Openstack для PoC. 2 узла, оба под управлением Nova и все остальное на узле 1. Он работает под управлением CentOS 6 и был настроен с использованием RDO. Важно отметить, что я использую Neutron для работы в сети с сетями клиентов GRE, настроенными из Документы RDO для существующей сети.
Периодически (кажется, каждые несколько дней) я теряю связь с Openvswitch (и, следовательно, с моими экземплярами). Я знаю это OVS, потому что я могу подключиться к узлу 2 по SSH, а затем подключиться к узлу 1 через их частную сеть. Наиболее показательная вещь, которую я вижу в журналах, это следующее:
unix:/var/run/openvswitch/db.sock: database connection failed (Protocol error)
Вдобавок OVS использует ОГРОМНОЕ количество ЦП (800% на моих 16-ядерных компьютерах), и когда я пытаюсь полностью завершить работу, этого никогда не происходит, потому что он не может убить ovsdb-server.
Я немного погуглил и нашел несколько старых предложений, основанных на более старых выпусках Openstack, где у людей были несоответствия версии OVS / ядра. Поскольку я использую версии от RDO, я считаю, что могу сбрасывать со счетов это (если Red Hat не сделала серьезную ошибку).
Кто-нибудь еще видел это? есть предложения?
PS: Не говорите мне перекомпилировать Openvswitch по разным причинам, этого не произойдет в ближайшем будущем.
Какую версию OpenStack, какую версию репозитория RDO вы используете? Я просто предполагаю с такой маленькой детализацией, но, похоже, вы указываете на какую-то проблему с OpenvSwitch и вашим ядром, неконтролируемый процесс OVS. Возможно, это связано с базой данных или агентом обмена сообщениями.
Проверьте свои журналы qpid: / var / log / messages на предмет того, что указывает на причину отключения во время потери связи с вашим экземпляром. Это может показать, почему могут быть разъединения при обмене сообщениями и вызвано ли оно отказом соединения для обмена сообщениями (внешняя / третичная причина); или наоборот, вызванное отключением OVS (вероятно, проблема сборки OVS / ядра).
Поскольку RDO «... протестирован на RHEL 6.4», я бы использовал минимум CentOS 6.4, а не 6, как вы заявляете. Еще лучше использовать 6.5, так как в ядро входит ряд компонентов, а не исправлений, необходимых для RDO.
Дополнительное устранение неполадок от вашего имени затруднено без журналов и подробностей вашей конфигурации, но после того, как вы это оцените, достаточно сказать, что существуют известные проблемы конфигурации Neutron, которые необходимо преодолеть с помощью настроек GRE и MTU.
В любом случае для успешной сборки OpenStack (какой бы простой она ни была) вам необходимо начать с поддерживаемой и современной сборки ОС, ядра и OVS. Как вы можете быть уверены, что можете не учитывать «несоответствие версий OVS / ядра», какие версии вы используете?
Я бы посоветовал вам настроить последнюю версию CentOS 6.5 и RDO, а затем повторно опубликовать, если проблема не исчезнет (с обновленными деталями, файлами журналов и т.д.), дополнительно на форуме RDO: http://openstack.redhat.com/forum/ так как тогда вы получите подробную информацию о дистрибутиве, которая может вам понадобиться.
РЕДАКТИРОВАТЬ: проверьте конфигурацию dhcp.ini и dnsmask в этих статьях на предмет настроек MTU, по-видимому, 1454 должно быть подходящим для гостевых экземпляров при запуске GRE: http://bderzhavets.blogspot.com.au/2014/01/setting-up-two-physical-node-openstack.html https://ask.openstack.org/en/question/12499/forcing-mtu-to-1400-via-etcneutrondnsmasq-neutronconf-per-daniels/
Не забывайте, что могут быть проблемы с MTU и GRE в зависимости от вашего ядра и версий OVS, поэтому, пожалуйста, сообщите, какие версии у вас есть, и обновите свой пост, чтобы вы могли помочь другим, имеющим аналогичные проблемы, На обоих узлах отображаются результаты для:
uname -a
rpm -qpi | grep openvswitch
Также взгляните на свои потоки OVS GRE и запустите несколько tcpdump в соответствующем пространстве имен qrouter, когда вы делаете большую передачу 20G, это руководство от RDO поможет, взгляните на отличную отладку GRE Джо Талерико на двух узлах, объяснение за 60 минут и далее: http://www.youtube.com/watch?v=wEa_8ESxPAY&feature=share&t=1h20s
И, наконец, вам также необходимо убедиться, что на вас не влияет конфигурация Generic Receive Offload согласно сообщению № 24: https://bugs.launchpad.net/neutron/+bug/1252900