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

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

    Что из себя представляет типовое облачное решение сегодня? Компания малого или среднего бизнеса арендует у провайдера ресурсы: облачные сервера или 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.
    Ай-Теко 38,77
    Компания
    Поделиться публикацией
    Комментарии 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
                      Конечно. Мы предоставляем двухнедельный тестовый период на ряд конфигураций.

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

                      Самое читаемое