Я запускаю Openstack Grizzly на CentOS, установленном Mirantis Fuel.
[root@controller-20 ~]# cat /etc/redhat-release
CentOS release 6.4 (Final)
[root@controller-20 ~]# rpm -qa | grep -i openstack-nova
openstack-nova-console-2013.1.1.fuel3.0-mira.2.noarch
openstack-nova-common-2013.1.1.fuel3.0-mira.2.noarch
openstack-nova-scheduler-2013.1.1.fuel3.0-mira.2.noarch
openstack-nova-conductor-2013.1.1.fuel3.0-mira.2.noarch
openstack-nova-objectstore-2013.1.1.fuel3.0-mira.2.noarch
openstack-nova-novncproxy-0.4-8.el6.noarch
openstack-nova-cert-2013.1.1.fuel3.0-mira.2.noarch
openstack-nova-api-2013.1.1.fuel3.0-mira.2.noarch
В настоящее время топология состоит из одного узла контроллера и трех вычислительных узлов, работающих на современном стоечном оборудовании Dell. Сегодня я подготовил около 25 виртуальных машин до того, как возникли проблемы.
По какой-то причине при создании / удалении виртуальных машин фиксированный IP застрял в неопределенном состоянии. Теперь у меня проблемы с созданием новых виртуальных машин. Openstack пытается использовать IP-адреса, которые, по его мнению, все еще являются частью старой виртуальной машины, и не может создать виртуальную машину.
Моя фиксированная сеть - 10.129.0.0/24.
Вот список проблемных IP-адресов из командной строки nova-manage:
# nova-manage fixed list | grep -E 'network|WARNING' -A 1
network IP address hostname host
10.129.0.0/24 10.129.0.0 None None
--
WARNING: fixed ip 10.129.0.20 allocated to missing instance
10.129.0.0/24 10.129.0.20 None None
--
WARNING: fixed ip 10.129.0.23 allocated to missing instance
10.129.0.0/24 10.129.0.23 None None
--
WARNING: fixed ip 10.129.0.25 allocated to missing instance
10.129.0.0/24 10.129.0.25 None None
WARNING: fixed ip 10.129.0.26 allocated to missing instance
10.129.0.0/24 10.129.0.26 None None
WARNING: fixed ip 10.129.0.27 allocated to missing instance
10.129.0.0/24 10.129.0.27 None None
--
WARNING: fixed ip 10.129.0.30 allocated to missing instance
10.129.0.0/24 10.129.0.30 None None
WARNING: fixed ip 10.129.0.31 allocated to missing instance
10.129.0.0/24 10.129.0.31 None None
WARNING: fixed ip 10.129.0.32 allocated to missing instance
10.129.0.0/24 10.129.0.32 None None
WARNING: fixed ip 10.129.0.33 allocated to missing instance
10.129.0.0/24 10.129.0.33 None None
WARNING: fixed ip 10.129.0.34 allocated to missing instance
10.129.0.0/24 10.129.0.34 None None
WARNING: fixed ip 10.129.0.35 allocated to missing instance
10.129.0.0/24 10.129.0.35 None None
WARNING: fixed ip 10.129.0.36 allocated to missing instance
10.129.0.0/24 10.129.0.36 None None
WARNING: fixed ip 10.129.0.37 allocated to missing instance
10.129.0.0/24 10.129.0.37 None None
WARNING: fixed ip 10.129.0.38 allocated to missing instance
10.129.0.0/24 10.129.0.38 None None
WARNING: fixed ip 10.129.0.39 allocated to missing instance
10.129.0.0/24 10.129.0.39 None None
WARNING: fixed ip 10.129.0.40 allocated to missing instance
10.129.0.0/24 10.129.0.40 None None
WARNING: fixed ip 10.129.0.41 allocated to missing instance
10.129.0.0/24 10.129.0.41 None None
WARNING: fixed ip 10.129.0.42 allocated to missing instance
10.129.0.0/24 10.129.0.42 None None
WARNING: fixed ip 10.129.0.43 allocated to missing instance
10.129.0.0/24 10.129.0.43 None None
WARNING: fixed ip 10.129.0.44 allocated to missing instance
10.129.0.0/24 10.129.0.44 None None
WARNING: fixed ip 10.129.0.45 allocated to missing instance
10.129.0.0/24 10.129.0.45 None None
WARNING: fixed ip 10.129.0.46 allocated to missing instance
10.129.0.0/24 10.129.0.46 None None
--
WARNING: fixed ip 10.129.0.48 allocated to missing instance
10.129.0.0/24 10.129.0.48 None None
WARNING: fixed ip 10.129.0.49 allocated to missing instance
10.129.0.0/24 10.129.0.49 None None
WARNING: fixed ip 10.129.0.50 allocated to missing instance
10.129.0.0/24 10.129.0.50 None None
--
WARNING: fixed ip 10.129.0.52 allocated to missing instance
10.129.0.0/24 10.129.0.52 None None
WARNING: fixed ip 10.129.0.53 allocated to missing instance
10.129.0.0/24 10.129.0.53 None None
--
WARNING: fixed ip 10.129.0.55 allocated to missing instance
10.129.0.0/24 10.129.0.55 None None
WARNING: fixed ip 10.129.0.56 allocated to missing instance
10.129.0.0/24 10.129.0.56 None None
WARNING: fixed ip 10.129.0.57 allocated to missing instance
10.129.0.0/24 10.129.0.57 None None
--
WARNING: fixed ip 10.129.0.59 allocated to missing instance
10.129.0.0/24 10.129.0.59 None None
WARNING: fixed ip 10.129.0.60 allocated to missing instance
10.129.0.0/24 10.129.0.60 None None
WARNING: fixed ip 10.129.0.61 allocated to missing instance
10.129.0.0/24 10.129.0.61 None None
Я знаю, что IP-адрес 10.129.0.20 отмечает создание виртуальной машины, из-за которой возникли проблемы. Проблема проявляется в невозможности подготовить новые виртуальные машины.
[root@controller-20 ~]# nova --os-username demetri --os-tenant-name admin --os-auth-url http://localhost:5000/v2.0/ fixed-ip-get 10.129.0.20
OS Password:
+-------------+---------------+----------+-----------------------+
| address | cidr | hostname | host |
+-------------+---------------+----------+-----------------------+
| 10.129.0.20 | 10.129.0.0/24 | devdbl9 | compute-21.domain.tld |
+-------------+---------------+----------+-----------------------+
Команды nova-manage, похоже, не предлагают никаких инструментов для восстановления этих IP-адресов. Я пробовал зарезервировать / снять резерв, но это не помогло. Кроме того, эти IP-адреса представлены в таблице nova mysql с именем fixed_ips. Пример:
+---------------------+---------------------+------------+-----+--------------+------------+-----------+--------+----------+----------------------+-----------------------+--------------------------------------+---------+
| created_at | updated_at | deleted_at | id | address | network_id | allocated | leased | reserved | virtual_interface_id | host | instance_uuid | deleted |
+---------------------+---------------------+------------+-----+--------------+------------+-----------+--------+----------+----------------------+-----------------------+--------------------------------------+---------+
| 2013-08-05 11:10:19 | 2013-10-16 11:32:20 | NULL | 21 | 10.129.0.20 | 1 | 0 | 0 | 0 | NULL | NULL | df2e9214-78cf-49d3-b256-e35d48818f29 | 0 |
Чтобы еще раз подтвердить, что проблема связана с сетью с фиксированным IP-адресом, пользовательский интерфейс отображает увеличивающийся IP-адрес для виртуальной машины, скажем, начиная с .21, переходя к .22, переходя к .23, прежде чем в конечном итоге произойдет сбой с состоянием «ERROR».
Все это как бы то ни было, поскольку это начало происходить, большинство, но не все попытки вызвать новую виртуальную машину терпят неудачу. Как я могу устранить эту неполадку и, в конечном итоге, вернуться к плавной подготовке новых виртуальных машин?
Спасибо.
Я смог отследить это до глючной / ошибочной установки rabbitmq. Журналы rabbitmq начали показывать такие ошибки, как:
= ОТЧЕТ ОБ ОШИБКЕ ==== 30 октября 2013 г. :: 16:28:11 === соединение <0.3821.221>, канал 1 - ошибка: {amqp_error, not_found, "нет обмена '75232ec16a7846f1979a93e9371040d0' в vhost '/' ", 'basic.publish'}
Я обновил установленный пакет rabbitmq-server-2.8.7-2.el6.noarch.rpm до пакета rabbitmq-server-3.2.0-1.noarch.rpm, размещенного на сайте rabbitmq. Теперь я могу успешно подготовить узлы!