[Эта статья написана Бараком Меримовичем .]
В предыдущих статьях мы подробно обсуждали сетевые возможности OpenStack . В этой статье я хотел бы погрузиться в более продвинутый сетевой сценарий OpenStack.
Многие облачные образы не настроены на автоматическое отображение всех доступных сетевых карт. Обычно на них настроена только одна сетевая карта. Чтобы правильно настроить хост в облаке с несколькими сетевыми картами, войдите на компьютер и откройте дополнительные интерфейсы.
echo $'auto eth1\niface eth1 inet dhcp' | sudo tee /etc/network/interfaces.d/eth1.cfg > /dev/null sudo ifup eth1
Сети в облаке
Сложная сетевая архитектура является основой современных облаков IaaS. Понимание того, как настроить облачные сети и хосты, крайне важно для работы вашего приложения в облаке. Это особенно верно для Cloudify, платформы с открытым исходным кодом для облачной оркестровки, над которой я работаю.
Облако, как и мир, раньше было плоским
Не так давно большинство поставщиков IaaS поддерживали только плоские сети — все ваши хосты были в одной большой сети. Разделение между службами, работающими в облаке, осуществлялось программно или с помощью брандмауэров / групп безопасности. Но технически все хосты были подключены к одной сети и видны друг другу.
Модель плоской сети проста, и поэтому легко рассуждать и понимать. Это был хороший выбор для первых дней существования облака IaaS, и он, несомненно, помог в первую очередь получить приложения в облаке. Это было одной из вещей, которые сделали EC2 настолько простым в использовании для любого, кто только начинает «облако». Эта модель на самом деле все еще доступна в Amazon Web Services под названием «EC2-Classic». И для многих приложений плоская сеть достаточно хороша.
Но с ростом облачного распространения все более сложные приложения перемещаются в облака, а такие проблемы, как разделение сетей, безопасность, SLA и широковещательные домены, делают модели более сложных сетей необходимыми. Программно-определяемые сети (SDN) восполняют этот пробел. Сейчас они являются основным продуктом большинства основных облаков IaaS. AWS имеет AWS-VPC , OpenStack имеет проект Neutron и существует множество других реализаций.
Для работы с SDN необходимо знать немного больше о том, как информация перемещается между вашими облачными ресурсами. В этом посте я собираюсь обсудить, как настроить хост в облаке, чтобы он хорошо работал со сложными сетями. Я буду использовать OpenStack, но концепции аналогичны для других облачных инфраструктур.
Конфигурация Openstack
Я собираюсь начать с пустого арендатора, доступна только общедоступная сеть.
Во-первых, давайте настроим сети и маршрутизатор:
neutron router-create demo-router neutron net-create demo-network-1 neutron net-create demo-network-2 neutron subnet-create --name demo-subnet-1 demo-network-1 10.0.0.0/24 neutron subnet-create --name demo-subnet-2 demo-network-2 10.0.1.0/24 neutron router-interface-add demo-router demo-subnet-1 neutron router-interface-add demo-router demo-subnet-2 neutron router-gateway-set demo-router public
Обратите внимание на сетевые идентификаторы:
neutron net-list | id | name | subnets | | 2c33efe2-6204-4125-9716-3bc525630016 | demo-network-1 | 928dafa0-83ef-459c-b20d-71d8ea596fa2 10.0.0.0/24 | | aa30627e-c181-4a4b-89bf-5dd7c26c244e | demo-network-2 | 26d573f7-7953-4a54-825b-ed7bbc0661c7 10.0.1.0/24 | | e502de8d-929a-4ee0-bd18-efa297875cf6 | public | d40dab51-a729-452c-9ee6-b9ad08d10808 |
Начнем со стандартного облачного образа Ubuntu:
glance image-create --name "Ubuntu 12.04 Standard" --location "http://uec-images.ubuntu.com/precise/current/precise-server-cloudimg-amd64-disk1.img" --disk-format qcow2 --container-format bare
Создайте пару ключей и группу безопасности:
nova keypair-add demo-keypair > demo-keypair.pem chmod 400 demo-keypair.pem nova secgroup-create demo-security-group "Security group for demo" nova secgroup-add-rule demo-security-group tcp 22 22 0.0.0.0/0
Давайте раскрутим экземпляр, подключенный к обеим нашим сетям:
nova boot -flavor m1.small --image "Ubuntu 12.04 Standard" --nic net-id=2c33efe2-6204-4125-9716-3bc525630016 --nic net-id=aa30627e-c181-4a4b-89bf-5dd7c26c244e --security-groups demo-security-group --key-name demo-keypair demo-vm
И установите плавающие IP-адреса для первой сети:
nova list
| ID | Name | Status | Task State | Power State | Networks | 2b17588b-8980-4489-9a04-6539a159dc3c | demo-vm | ACTIVE | None | Running | demo-network-1=10.0.0.2; demo-network-2=10.0.1.2 |
neutron floatingip-create public
neutron floatingip-list
| id | fixed_ip_address | floating_ip_address | port_id |
| 49c8b05e-bb8f-4b07-80ed-3155ab6ffc09 | | 192.168.15.42 | |
neutron port-list
| id | name | mac_address | fixed_ips |
| 1ccfd334-7328-4b22-b93e-24a0888276ab | | fa:16:3e:14:39:39 | {"subnet_id": "94598487-c1fc-4f55-ac1f-ef2545d5cfeb", "ip_address": "10.0.1.3"} |
| a482c4f6-fa74-476e-b1ce-cd8dd0c70815 | | fa:16:3e:18:92:79 | {"subnet_id": "94598487-c1fc-4f55-ac1f-ef2545d5cfeb", "ip_address": "10.0.1.2"} |
| b23d7836-30c5-4bff-b873-15c87ba051f6 | | fa:16:3e:3a:28:40 | {"subnet_id": "dec6ec74-cfa9-4a08-8792-54900631b98e", "ip_address": "10.0.0.3"} |
| d421b447-2adf-406f-876b-142238683344 | | fa:16:3e:9d:fc:7f | {"subnet_id": "dec6ec74-cfa9-4a08-8792-54900631b98e", "ip_address": "10.0.0.2"} |
| dcf8696b-cc80-4b48-b09c-61c0f8ab02ac | | fa:16:3e:5b:39:fb | {"subnet_id": "94598487-c1fc-4f55-ac1f-ef2545d5cfeb", "ip_address": "10.0.1.1"} |
| f6a1666e-495a-4d3f-afa3-754b3cb3cfc0 | | fa:16:3e:8a:1b:fb | {"subnet_id": "dec6ec74-cfa9-4a08-8792-54900631b98e", "ip_address": "10.0.0.1"} |
neutron floatingip-associate 49c8b05e-bb8f-4b07-80ed-3155ab6ffc09 d421b447-2adf-406f-876b-142238683344
Обратите внимание, как мы сопоставили IP виртуальной машины с ее портом и связали плавающий IP с портом. Я бы хотел, чтобы был более простой способ сделать это из CLI …
Если все работает правильно, вы должны иметь следующую настройку:
Давайте удостоверимся, что ssh работает правильно:
ssh -i demo-keypair.pem [email protected] hostname demo-vm
Круто, ssh работает. Теперь у нас должно быть две сетевые карты, верно?
ssh -i demo-keypair.pem [email protected] hostname demo-vm Cool, ssh works. Now, we should have two network cards, right? ssh -i demo-keypair.pem [email protected] ifconfig eth0 Link encap:Ethernet HWaddr fa:16:3e:5f:a2:5f inet addr:10.0.0.4 Bcast:10.0.0.255 Mask:255.255.255.0 inet6 addr: fe80::f816:3eff:fe5f:a25f/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:230 errors:0 dropped:0 overruns:0 frame:0 TX packets:224 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:46297 (46.2 KB) TX bytes:31130 (31.1 KB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Да ?! ВМ имеет только один рабочий сетевой интерфейс! Где мой второй NIC? Была ли проблема с настройкой сети OpenStack? Ответ здесь:
ssh -i demo-keypair.pem [email protected] ifconfig -a eth0 Link encap:Ethernet HWaddr fa:16:3e:5f:a2:5f inet addr:10.0.0.4 Bcast:10.0.0.255 Mask:255.255.255.0 inet6 addr: fe80::f816:3eff:fe5f:a25f/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:324 errors:0 dropped:0 overruns:0 frame:0 TX packets:332 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:69973 (69.9 KB) TX bytes:47218 (47.2 KB) eth1 Link encap:Ethernet HWaddr fa:16:3e:29:6d:22 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Второй NIC существует, но не работает.
Проблема не в конфигурации сети OpenStack, а в образе. Сам образ должен быть настроен для правильной работы с несколькими сетевыми картами. Все, что нам нужно сделать, это вызвать NIC. Итак, мы ssh в экземпляр:
ssh -i demo-keypair.pem [email protected]
И выполните следующие команды:
echo $'auto eth1\niface eth1 inet dhcp' | sudo tee /etc/network/interfaces.d/eth1.cfg > /dev/null sudo ifup eth1
Теперь должен быть запущен второй сетевой адаптер:
ifconfig eth1 eth1 Link encap:Ethernet HWaddr fa:16:3e:18:92:79 inet addr:10.0.1.2 Bcast:10.0.1.255 Mask:255.255.255.0 inet6 addr: fe80::f816:3eff:fe18:9279/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:81 errors:0 dropped:0 overruns:0 frame:0 TX packets:45 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:15376 (15.3 KB) TX bytes:3960 (3.9 KB)
И все — ваша виртуальная машина может получить доступ к обеим сетям.
Эта проблема может усложнить жизнь при настройке сложного или даже не очень сложного приложения. Когда этот вопрос повредит вам? Хорошо, представьте себе сценарий, в котором у вас есть веб-сервер и сервер базы данных. Веб-сервер подключен к сети1 и сети2, а сервер базы данных подключен только к сети2. Сеть 1 подключена к внешнему миру через маршрутизатор, а Сеть 2 полностью внутренняя, добавляя еще один уровень безопасности для сервера критически важной базы данных. Так что же произойдет, если веб-сервер имеет только одну сетевую карту? Если подключен только сетевой адаптер для Network1, веб-сервер не сможет получить доступ к базе данных. Если подключен только сетевой адаптер для Network2, веб-сервер не может быть доступен из внешнего мира. Еще хуже, если этот веб-сервер доступен через плавающий IP-адрес, этот IP-адрес также не будет работать,так что вы не сможете получить доступ к веб-серверу и решить проблему. Tricky.
In conclusion
The above commands will bring up your additional network card. You will of-course need to repeat this process for each additional network card, and for each VM. You can use a start-up script (a.k.a. user-data script) or system service to run these commands, but there are better ways. I’ll discuss how to automate the network setup in a follow-up post.