Ай-Теко
Компания
41,19
рейтинг
30 мая 2013 в 10:41

Разное → Как собрать из конструктора облачную инфраструктуру

Мы сейчас участвуем в проекте по созданию сервиса, который собирает виртуальную инфраструктуру в облаке. Подобные решения на рынке есть, но я вижу, что нам удалось продвинуться в этом вопросе, пожалуй, чуть дальше других облачных провайдеров. Почему – попытаюсь объяснить на конкретных примерах.

Что из себя представляет типовое облачное решение сегодня? Компания малого или среднего бизнеса арендует у провайдера ресурсы: облачные сервера или VDS/VPS. Потом в ручном режиме создает редко встречающиеся в готовом виде элементы инфраструктуры — VPN, балансировщик, подсеть, роутер, изолированную сеть (VLAN)–и прописывает настройки. Для компаний крупного бизнеса, требующих реализации сложной инфраструктуры, все, как правило, ещё тяжелее: для выполнения определённого комплекса работ требуется обращение в службу поддержки провайдера с заявкой на разработку практически индивидуального проекта инфраструктуры. Понятно, что построение уникальной сложной инфраструктуры без готовых элементов – это долго и дорого.

В итоге – куча сил и времени айтишной команды уходит на организацию облачной инфраструктуры. Хотя использование виртуального сервиса быстрее и дешевле, чем организация физической инфраструктуры.





Что решили сделать мы?
Сервис, позволяющий «собрать виртуальную инфраструктуру мышкой», в режиме онлайн (MakeCloud).

Для реализации идеи мы использовали «концепцию конструктора», набора готовых элементов, из которых пользователь самостоятельно собирает требуемую инфраструктуру. Любой элемент инфраструктуры – виртуальная изолированная сеть, виртуальный сервер, группы безопасности (файерволы), виртуальный роутер, Cloudpipe (VPN-шлюз), подсеть, дополнительный диск – добавляется нажатием кнопки в панели управления. В выпадающем меню остаётся выбрать настройки для создаваемого элемента. Еще совсем скоро добавим балансировщик – его тоже можно будет добавить одной кнопкой на сайте.

Результат: решение инфраструктурных проблем компаний малого, среднего и крупного бизнеса в облаке с минимальными затратами времени и ресурсов заказчика.

И это реально экономит массу времени айти-специалиста. По сути, свою инфраструктуру в облаке на таком сервисе могут собрать любые компании, от студенческих стартапов до крупного бизнеса.

Приведу несколько типовых примеров – самых частых конфигураций, которые сейчас собирают на MakeCloud пользователи. С одной стороны, в силу того, что эти кейсы реально типичны для массового бизнеса, их несложно реализовать, но даже тут есть возможность сделать это быстрее и проще.

Кейс первый

Что нужно: Разместить информационный сайт (витрину, блог и т.п.).

Решение: Создание виртуального сервера, одновременно выполняющего роли web-сервера и сервера баз данных. В панели управления доступен образ LAMP, содержащий весь необходимый софт для запуска сайта, останется только разместить контент. Нежелательный доступ к серверу ограничивается при помощи групп безопасности (файервола).



Что делаем:

• Создаем один виртуальный сервер
• Настраиваем группы безопасности (файерволы)
• Развертываем свой сайт на сервере

Кейс второй

Что нужно: Разместить интернет-магазин.

Решение: Создание безопасной инфраструктуры с двухуровневой архитектурой приложения – уровень Front-end и уровень Back-end. Front-end (например, web-сайт) расположен в DMZ, доступ к нему ограничен группами безопасности (файервол). Back-end (например, сервер MS SQL Server (БД) и сервер 1С) расположен в приватной сети. DMZ и приватная сеть соединены роутером.



Что делаем:

• Создаем приватную сеть (VLAN 1)
• Создаем подсеть 1
• Создаем роутер с интерфейсами в публичной сети и подсети 1
• Создаем три виртуальных сервера
• Настриваем группы безопасности (файерволы)
• Развертываем ПО на серверах

Кейс третий

Что нужно: Разместить крупную электронную торговую площадку.

Решение: Создание масштабируемой безопасной инфраструктуры с двухуровневой архитектурой приложения – уровень Front-end и уровень Back-end. Front-end, в отличие от второго примера, может содержать несколько web-серверов (терминальную ферму), и нагрузка между ними будет распределяться при помощи балансировщика сетевой нагрузки (балансировщик, как я писал выше, пока недоступен на MakeCloud, но скоро добавим). Back-end, например 1C и кластер БД, расположен в приватной сети, и так же, как, во втором кейсе, соединяет DMZ и приватную сеть роутер.



Что делаем:

• Создаем приватную сеть (VLAN 1)
• Создаем подсеть 1
• Создаем роутер с интерфейсами в публичной сети и подсети 1
• Создаем и настроаиваем балансировщик сетевой нагрузки
• Создаем шесть виртуальных серверов в соответствующих сетях (по схеме)
• Настраиваем группы безопасности (файерволы)
• Развертываем ПО на серверах

Кейс четвертый

Что нужно: Разместить основную инфраструктуру в облаке и организовать доступ к двум офисам.

Решение: Создание безопасной инфраструктуры с многоуровневой архитектурой приложения, с возможностью создать VPN-подключение «точка-точка» между облачной инфраструктурой и инфраструктурой заказчика. Доступ к Cloudpipe (VPN-шлюзу), который расположен в DMZ, ограничивается при помощи групп безопасности (файерволы). Внутри разных приватных сетей можно размещать различные бизнес-приложения, гибко и безопасно соединяя сети через роутеры.



Что делаем:

• Создаем приватную сеть (VLAN 1)
• Создаем подсеть 1
• Создаем подсеть 2
• Создаем роутер с интерфейсами в публичной сети, подсети 1 и подсети 2
• Создаем Cloudpipe (VPN)
• Настраиваем группы безопасности (файерволы)
• Организуем VPN туннели между офисом А и Cloudpipe; между офисом Б и Cloudpipe
• Создаем четыре виртуальных сервера в соответствующих подсетях
• Размещаем ПО на сервера

Кроме балансировщика (в разработке) и готового образа LAMP, мы планируем подготовить другие образы для быстрого создания сервера под конкретные задачи. Сейчас работаем над запуском API, совместимым с AWS EC2.

Все эти типовые случаи, повторюсь, достаточно несложные. Было бы, конечно, интереснее поработать над примерами более сложных ИТ-задач. Если накидаете таких в комментариях, постараемся показать примеры их решения при помощи готовых элементов MakeCloud.
Автор: @AlexeyChI
Ай-Теко
рейтинг 41,19
Компания прекратила активность на сайте

Похожие публикации

Комментарии (24)

  • +6
    Даю простую задачу: решить проблему зависания SAS шины при зависании диска, решить проблему с замедлением работы софтового свичта при увеличении числа flow, обеспечивать хотя бы 500-700 мегабит до виртуалок любого размера пакетами.

    Хехе, городить стек все горазды, а вы базис сделайте-то…
    • –1
      День добрый,
      Перелопатил все обращения клиентов, к счастью таких проблем никто не озвучивал.
      • +2
        Вероятнее всего, либо нет нормальной нагрузки, либо не могут сформулировать претензию за «внезапно затормозило»/«упало».
    • 0
      Как обычно решают проблему зависания SAS шины? Если диск вышел из строя и стал флудить в SAS шине, диск надо извлечь, произойдет терминирование, и проблема исчезнет. Как мы решаем эту проблему — архитектурно, устраняя проблему как единую точку отказа. А как решили в своем облаке эту проблему вы?
      Проблема зависания софтверного свитча нами исследуется и сейчас мы ее не испытываем. Так же как и с зависанием SAS шины, возможен архитектурный обход этой проблемы.
      Считаю утверждение про стек субъективным. Используя KVM виртуализацию, OpenVSwitch и прочие opensource пакеты мы не изобрели велосипед, а Openstack – оркестратор процессов, который достаточно легко «дописывается».
      Предлагаю продолжить общение в кулуарах, если это имеет смысл.
      • 0
        Дайте добро на небольшую dos атаку (15-20 мегабит) на IP'шник, запущенный на OVS'е. будет смешно.
        • 0
          Наши тесты пока не выявили таких проблем. Если Вы можете подсказать структуру DoS-атаки для дополнительной проверки, можем продолжить обсуждение по почте или в личке.
          • 0
            IP, 20 мегабит входящего трафика == недоступный на время атаки хост, где находится атакующая виртуалка.

            Если бы вы серьёзно относились к используемому ПО, то вы бы читали рассылки разработчкиков. Я писал там про проблему и даже засылал патч для её решения.
            • 0
              И что разработчики? Уже пофиксили?
              • 0
                Нет, потому что мой патч делает OVS устройчивым в всякой мерзкости, но нехорошо забивает на высокие идеалы SDN. В результате они решили, что лучше строить замки на песке, чем заниматься котлованами под фундамент.

                • 0
                  Тут проявляется позиция, характерная для опенстека. Не будем лечить и латать узкие места, прсото скажем — используется горизонтальное масштабирование. Поставьте еще 10 серверов =)).
      • 0
        Используя KVM виртуализацию, OpenVSwitch и прочие opensource пакеты мы не изобрели велосипед, а Openstack – оркестратор процессов, который достаточно легко «дописывается»

        А вот тут можно чуточку поподробнее? Что вы использовали из OpenStack, а что «дописывали» сами?
        • 0
          Используем релиз Grizzly и все основные компоненты OpenStack, за исключением Swift. Из изменений – в принципе адаптировали под себя каждый проект, в некоторых проектах доработали логику и функционал, например, Floating IP и маршрутизации в сетевой части (Quantum), адаптировали пребиллинг (Ceilometer) под свои задачи.
  • 0
    Так инфраструктура сама разворачивается или заказчик «рисует» что он хочет, а потом специальные люди это разворачивают?
    • 0
      Структура строится и автоматически разворачивается по мере того, как вы «рисуете».
  • +2
    Прочитал и получил неожиданное впечатление статьи «ни о чем»
  • 0
    Картинки и текст производят впечатление чего-то умного, мощного и хорошего. А если подумать — есть openstack и openvswitch. Вы их взяли. А дальше что? Где ноухау? Где что-то новое?

    Да тысячам юзеров не нужен vlan и они понятия не имеют зачем он им. И да у openvswitch есть проблемы с производительностью на большом числе мелких пакетов. Было бы интереснее, если бы Вы брали железный свич умеющий openflow и про него написали.
    • 0
      А что собственно вы имеете ввиду под ноухау?
      • 0
        Кто мешает любому взять опенстек и тоже самое ПО и сделать тоже самое или даже лучшее? Чем Вы лучше? Что особенного Вы предлагаете?
        Ноухау — openshift, juju (https://juju.ubuntu.com/), heroku местами…
        • 0
          Вы абсолютно правы. Никто никому не мешает взять и сделать лучше. :) Если серьезно, то не хочется «покусочничать». Мы готовим ряд статей, из которых, надеюсь, вы составите себе цельную картину о том, что мы сделали.
          • 0
            Хорошо. Почитаем. А еще вопрос — как делали имаджи для операционок?
    • 0
      В ближайшее время мы продолжим серию статей, в которых расскажем про нашу архитектуру и о том, какие изменения мы в несли в OpenStack. В первой статье 23.01.2013 мы рассказали о проектировании сетевой части habrahabr.ru/company/iteco/blog/166729/
  • +1
    А сейчас как-то можно это всё протестировать? Обычно предлагают триальный период или что-то такое.
    • 0
      Да, забыл. К каждому тестовому серверу прилагается «белый» IP
  • +2
    Конечно. Мы предоставляем двухнедельный тестовый период на ряд конфигураций.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разное