Назад | Перейти на главную страницу

Проблема эвкалипта

У меня есть проблемы с построением частного облака на основе эвкалипта. И здесь две версии этой проблемы, простая и длинная.

Просто:

Кто-нибудь, знакомый с частным облаком, может нарисовать мне картинку, чтобы проиллюстрировать «IP-СХЕМУ» облака? Мне сложно решить, где должен быть каждый компонент. Если я хочу установить CLC, Walrus, CC, SC, NC на разные физические машины, какой должна быть топология сети?

Дополнительная информация: у меня сейчас 12 физических машин, работающих в облаке, но я не могу прикреплять тома к экземплярам. Интересно, куда мне поставить контроллер хранилища, в публичную сеть? под CLC? под CC? на одном уровне с CC? Ни фото, ни объяснения не найдено. И я перепробовал все, что мог, инстансы работают, нормально к ним получить доступ, просто чертовски объемная штука беспокоила меня целую неделю.

Длинная версия:

  1. Я успешно настроил эвкалипт на 4 физических серверах, и он отлично работает.
  2. Четыре сервера: CLC, SC, CC, NC.
  3. Проблема в том, что я не очень уверен, куда поставить SC, так как топология моего облака такая:

  1. Теперь к CC подключены два переключателя: ENTSWitch и PrivateSwitch. И имеет два IP-адреса: общедоступный IP-> 10.11.25.115, частный IP-> 10.11.20.1. Контроллер узла подключен только к приватному коммутатору и имеет частный IP 10.11.20.2
  2. К настоящему времени это работает нормально, используя режим управляемого новлана, контроллер узла может развертывать экземпляры и получать для них общедоступные IP-адреса. Все сладко.
  3. Вот проблема, я могу создать том на контроллере хранилища. Но к экземплярам том не прикрепить.
  4. Интересно, не потому ли, что контроллер узла находится в другой сети с контроллером хранилища.

Пытался решить проблему, выполнив следующие действия:

    [root@HeroNodeServer1 images]# cat /var/log/eucalyptus/nc.log | grep Volume
    [Fri Aug 20 16:36:12 2010][015662][EUCAINFO ] doAttachVolume() invoked (id=i-33BD0649 vol=vol-59C90629 remote=/dev/etherd/e0.1 local=/dev/sdb)
    [Fri Aug 20 16:37:53 2010][015662][EUCAERROR ] AttachVolume() failed (err=-1) XML=
    [Fri Aug 20 16:37:53 2010][015662][EUCAERROR ] ERROR: doAttachVolume() failed error=1
    [Fri Aug 20 16:37:53 2010][015662][EUCAINFO ] doAttachVolume() invoked (id=i-33BD0649 vol=vol-59C90629 remote=/dev/etherd/e0.1 local=/dev/sdb)
    [Fri Aug 20 16:37:53 2010][015662][EUCAERROR ] AttachVolume() failed (err=-1) XML=
    [Fri Aug 20 16:37:53 2010][015662][EUCAERROR ] ERROR: doAttachVolume() failed error=1
    [Fri Aug 20 16:37:53 2010][015662][EUCAINFO ] doAttachVolume() invoked (id=i-33BD0649 vol=vol-59C90629 remote=/dev/etherd/e0.1 local=/dev/sda5)
    [Fri Aug 20 16:37:53 2010][015662][EUCAERROR ] AttachVolume() failed (err=-1) XML=
    [Fri Aug 20 16:37:53 2010][015662][EUCAERROR ] ERROR: doAttachVolume() failed error=1
    [Fri Aug 20 16:37:58 2010][015662][EUCAINFO ] doAttachVolume() invoked (id=i-33BD0649 vol=vol-59C90629 remote=/dev/etherd/e0.1 local=/dev/sda4)
    [Fri Aug 20 16:39:38 2010][015662][EUCAERROR ] AttachVolume() failed (err=-1) XML=
    [Fri Aug 20 16:39:38 2010][015662][EUCAERROR ] ERROR: doAttachVolume() failed error=1
    [Fri Aug 20 16:39:38 2010][015662][EUCAINFO ] doAttachVolume() invoked (id=i-33BD0649 vol=vol-59C90629 remote=/dev/etherd/e0.1 local=/ev/sdp)
    [Fri Aug 20 16:39:38 2010][015662][EUCAERROR ] ERROR: doAttachVolume() failed error=1
    [Fri Aug 20 16:39:38 2010][015662][EUCAINFO ] doAttachVolume() invoked (id=i-33BD0649 vol=vol-59C90629 remote=/dev/etherd/e0.1 local=/dev/sdp)
    [Fri Aug 20 16:39:38 2010][015662][EUCAERROR ] AttachVolume() failed (err=-1) XML=
    [Fri Aug 20 16:39:38 2010][015662][EUCAERROR ] ERROR: doAttachVolume() failed error=1
    [Fri Aug 20 16:41:15 2010][015662][EUCAINFO ] doAttachVolume() invoked (id=i-33BD0649 vol=vol-5A030630 remote=/dev/etherd/e0.2 local=/dev/sdp)
    [Fri Aug 20 16:42:55 2010][015662][EUCAERROR ] AttachVolume() failed (err=-1) XML=
    [Fri Aug 20 16:42:55 2010][015662][EUCAERROR ] ERROR: doAttachVolume() failed error=1
    [Fri Aug 20 16:43:12 2010][015662][EUCAINFO ] doAttachVolume() invoked (id=i-33BD0649 vol=vol-5A030630 remote=/dev/etherd/e0.2 local=/dev/sdc)
    [Fri Aug 20 16:44:52 2010][015662][EUCAERROR ] AttachVolume() failed (err=-1) XML=
    [Fri Aug 20 16:44:52 2010][015662][EUCAERROR ] ERROR: doAttachVolume() failed error=1
    [Fri Aug 20 16:50:02 2010][015662][EUCAINFO ] doAttachVolume() invoked (id=i-33BD0649 vol=vol-59C90629 remote=/dev/etherd/e0.1 local=/dev/sdd)
    [Fri Aug 20 16:51:42 2010][015662][EUCAERROR ] AttachVolume() failed (err=-1) XML=
    [Fri Aug 20 16:51:42 2010][015662][EUCAERROR ] ERROR: doAttachVolume() failed error=1

Вопросы:

  1. Куда я должен прикрепить SC? публичная сеть или частная сеть?
  2. Если он должен быть подключен к частной сети, как зарегистрировать SC, если CLC не может подключиться к частной сети
  3. Почему два решения не смогли подключить том к экземпляру?

================================================== ==============

А вот и второй:

  1. В настоящее время я пытаюсь провести еще несколько тестов.
  2. Я хочу расширить 4-физическую архитектуру до 16-физической архитектуры.
  3. Независимо от того, сколько машин я хочу использовать, у меня долгое время есть вопрос, который не решается с помощью множества прочитанных документов.
  4. Новая архитектура, которую я разработал, похожа на следующую картинку
  5. В новой топологии я предполагал, что контроллер хранилища должен быть подключен к частной сети.
  6. В этой модели экземпляры, работающие на контроллере узла, должны иметь два назначенных IP-адреса, один частный, один «общедоступный».
  7. Публичный IP-адрес должен быть в сети такой же, как CC, верно?
  8. Это означает, что к экземплярам может получить доступ сеть, в которой находится CC.
  9. И у CLC должна быть запущена служба шлюза, чтобы экземпляры могли получать доступ к внешним сетям.

Вопросы:

  1. Есть ли проблемы с дизайном?
  2. Если экземпляры могут получить только «общедоступный IP-адрес», который находится в одной сети с контроллером кластера, как клиенты могут получить к ним доступ из внешних сетей?
  3. Значит, как клиенты вне облака получают доступ к инстансам через CLC?
  4. Имеет ли CLC такой же механизм, как CC, для назначения «общедоступного IP-адреса» для экземпляров, чтобы к нему можно было получить доступ?

================================

Это все, что мне нужно спросить.

Большое спасибо за то, что прочитали этот грязный пост, и мы очень ценим любой ответ!

Все следующие ответы предполагают, что сетевой режим - УПРАВЛЯЕМЫЙ-НОВЛАН (вероятно, все это применимо и к УПРАВЛЯЕМОМУ режиму).

Секция 1:

-1) Если у вас нет особых потребностей предотвратить это, я бы рекомендовал связать SC с CC.

-2) В управляемом режиме CC находится между общедоступной сетью и частной сетью (одного из) облачного кластера (ов). Если SC находится на машине CC, он может связываться с обеими сетями. Если вы решите разместить SC на отдельном сервере в частной сети, вам необходимо создать правило NAT (с iptables) на CC, чтобы обеспечить связь между SC и CLC через брандмауэр CC. CLC потребуется это правило для связи с SC.

-3) В растворе 1; ваш SC не был подключен к частному коммутатору (это обязательно). В растворах 2; Вы, вероятно, не создавали это правило iptables для CC, и тогда SC был изолирован за CC.

Раздел 2:

-1) Одно исправление: объедините коммутаторы CTI и switch1, это должен быть тот же коммутатор, который используется для подключения к публичной сети. Я также предлагаю (если это абсолютно не нужно) объединить CLC и WC в одну машину и объединить SC на их соответствующих CC. Эта диаграмма (http://cssoss.files.wordpress.com/2010/05/eucalyptus_cloud.png?w=600&h=467) облака UEC может вам помочь.

-2) Когда вы создаете новый экземпляр (euca-run-instance), Eucalyptus создаст новое правило iptable на сервере CC, управляющем узлом, на котором запущен экземпляр. Это правило разрешает связь через CC. Этот обход NAT направляет связь между общедоступными IP-адресами и соответствующими им частными IP-адресами.

-3) Клиенты получают доступ к экземплярам через соответствующий CC. CLC предназначен только для управления облаком, но после запуска экземпляра CC обрабатывает связь.

-4) Короче: Нет.

Хорошо, давайте попробуем начать отвечать на это

  • SC вопрос

SC должен быть всегда доступен из экземпляров, поэтому он должен находиться в той же сети, что и контроллер узла, экземпляры не могут видеть хранилище, потому что оно находится в другой сети.

  • Топология сети

Хорошо иметь отдельные сети, но я думаю, что было бы лучше основывать свою безопасность на брандмауэре и контроле трафика, а не усложнять вещи, Eucalyptus любит, когда сеть простая, начните с одной сети и не делите ее через два, пока у вас не появится хорошее чувство безопасности. Сконцентрируйте свои усилия на создании безопасных CLC и CC, поскольку безопасность других компонентов будет обеспечиваться частной сетью и протоколами, предоставляемыми эвкалиптом. Также NC ни в коем случае не нужны внешние IP.

  • Сетевой дизайн

Этот дизайн мне кажется надежным, все общедоступные адреса будут предоставлены CC, поэтому CC будет фактически вашим шлюзом, думайте об этом как о «зонах доступности» в Amazon EC2, имея более одной CC, которую вы создание ваших зон.

В резюме внимательно следите за CLC, CC и Walrus, убедитесь, что вы знаете все аспекты безопасности и связи в них, остальные компоненты должны быть в порядке и жить счастливо во внутренних сетях.