Опыт переноса веб-сервисов компании СОЮЗ в масштабируемый виртуальный комплекс

    В начале марта мы достигли принципиального соглашения с представителями компании «СОЮЗ» по проведению мероприятий по виртуализации корпоративной ИТ-инфраструктуры. Если проще – то СОЮЗ с нашей помощью производит аутсорсинг ИТ-инфраструктуры, размещает собственные мощности в дата-центре «Оверсан-Меркурий» и проводит еще ряд мероприятий, в результате чего получает экономию средств и массу новых возможностей по развитию.

    Тому, как мы переносили веб-сервисы компании в МВК, и технологическим особенностям реализации проекта и посвящен этот пост.

    image



    Запланировано большое количество действий, вплоть до прокладки оптической «последней мили» от дата-центра к офису компании. Но это планы только грядущие, а пока мы расскажем о вполне удачном переносе нескольких веб-сайтов компании, на деле объединенных единой витриной, и начале второго этапа по переносу обширнейшей базы данных на новые мощности.

    Частью иллюстраций для поста послужат слайды презентации, сделанной нами на открытом столе «ИТ-аутсорсинг в России», организованном Cnews и прошедшем в середине марта.

    image

    image

    Изначально сайты «СОЮЗа», несущие разную нагрузку, от информирования посетителей до продаж, были объединены в своеобразное кольцо и размещались на собственном оборудовании компании, расположенном прямо в офисе. В принципе, для того, чтобы все работало стабильно под любой нагрузкой, было сделано немало. Организован относительно широкий канал в интернет, серверы объединены в кластерную распределенную систему. Но во время рекламных кампаний и, соответственно, большого наплыва посетителей на сайт, все равно случались сбои. В части случаев было даже сложно определить, что именно сбоит, где находится то самое «бутылочное горлышко». В компании созрела необходимость переноса сервисов на сторонние мощности. А мы как раз запустили Масштабируемый Виртуальный Комплекс (МВК) в тестовую эксплуатацию и в «СОЮЗе» согласились организовать с нами совместный проект.

    Для того чтобы сайты работали под любой нагрузкой, потребовалось продумать отдельную систему балансировки, расставившую в итоге все по местам. Ну и, конечно же, перенести их в МВК, о котором мы уже рассказывали здесь

    .

    МВК реализован на блейд-шасси BladeSystem 7000 и системе хранения данных Lefthand P4000 от HP.

    Схема работы веб-сервера



    image

    HTTP-запросы пользователей обрабатывает сетевой балансировщик, состоящий из узлов, перенаправляющих запросы на backend-серверы. Все изменения, сделанные на тестовой площадке, становятся доступны на основном сайте.

    Домен разрешается в два ip-адреса, и каждый ip-адрес сконфигурирован на собственном балансировщике. Балансировщики распределяют трафик между frontend-серверами. Балансировка осуществляется методом Weighted Least-Connection, то есть каждое новое соединение направляется на узел с наименьшим количество соединений с учетом весов.

    Желтые и зеленые стрелки показывают возможные варианты переброса HTTP-запроса клиента к основным серверам с использованием балансировки.

    Синяя стрелка показывает работу самого балансировщика и распределение запросов между узлами.

    Немного подробностей. В список использованного ПО вошли keepalived, vsftpd, nginx, apache и php-5.2.6. Nginx используется для кэширования данных и отдачи статических объектов. Для backend-сервера задействован Apache, в основном по причине наличия модуля для работы sybase. Защиту от отказов нодов предоставляет keepalived.

    В непосредственной работе с сайтом используется технология «сетевого RAID» DRBD (Disctributed Replicated Block Devcie). При «заливке» на сайт картинки и другой контент синхронизируются на два сервера, так как бизнес-процесс заказчика не допускает различий в контенте на узлах.

    image

    Для повышения отказоустойчивости и максимального разнесения узлов всей системы, мы использовали технологию балансировки VMware DRS. В случае прекращения работы одного из узлов кластера высокой доступности (HA-cluster), балансировщик и backend-сервер, находящиеся на другом узле кластера, продолжают обслуживать сайт заказчика.

    В процессе реализации проекта мы получили немалый опыт системной интеграции и обеспечили клиенту кастомизацию предоставляемых услуг в соответствии с требованиями. Необходимо отметить, что процесс переноса веб-сервисов на новые мощности был произведен абсолютно прозрачно для инженеров и незаметно для пользователей, с нулевым временем простоя. Положительная реакция не заставила себя ждать.

    Комментарий Романа Штембульского, руководителя интернет-проектов концерна «СОЮЗ».



    «До работы с дата-центром «Оверсан-Меркурий» у нас уже был достаточно большой собственный опыт технологического обеспечения информационных систем. В какой-то момент мы, что называется, просто ради интереса решили разузнать, какие решения по нашим задачам могут предложить другие. Почему-то чаще всего мы получали не очень убедительные пересказы стандартных предложений, размещённых на сайтах компаний. Мы ожидали, что наши замыслы не будут покалечены острым лезвием стандартизированной рамки, но в то же время не превратятся в облако абстрактной и модной гибкости. В компании «Оверсан-Меркурий» нам задали точные вопросы, точно нас поняли, предложили точное решение и осуществили точную реализацию. В конечном итоге мы получили даже больше, чем понимали и планировали сами — качественно и профессионально. И это не то, что так любят коммерческие отделы при работе с заказчиками, которые, в конце концов, получают много, но не понимают, как всё это работает и зачем им всё это. «Оверсан-Меркурий» работает по-другому.

    При переводе собственной системы на МВК лучше будет сразу же избавиться от старых представлений вроде того, что ваш сайт, к примеру, где-то «лежит», расположен на каком-то сервере, ограниченном физическим размером корпуса, где аккуратно установлены процессоры, память, жёсткие диски и т.д. Также отпадет необходимость умножать и делить всё на 8, 16, 128, 2048 и т.д. Например, в МВК можно легко получить 19 гигагерц процессорной мощности или 17 гигабайт памяти. В сущности, всё это можно представлять себе как электронный бульон, в котором варится и кипит система. Его можно попробовать на вкус, остудить или прибавить огня, если надо, добавить различные электронные специи по вкусу: к нескольким гигагерцам процессорного времени щепотку гигабайт оперативной памяти, нарезать ломтиками терабайты жёстких дисков и всё тщательно перемешать с PHP, SQL, XML и HTML».
    Реклама
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее

    Комментарии 31

      0
      Хорошая success story.l Поздравляю и Союз и Оверсан.
      Радует, что применяете open-source вместо модных балансировщиков/ADC от больших вендоров типа циски и F5, за это отдельный респект.
        0
        спасибо! и за респект тоже )).
        –1
        Компания Оверсан-Меркурий любит и хорошие open-source решения и надежное оборудование от известных вендоров.
          0
          Хм, то-то удивительно быстро интернет-магазин «СОЮЗа» работать стал, а то раньше что ни клик — то лаг.
            0
            прямо в цель! ))
            0
            конфиги в студию бы с пояснениями.
            а то таких success story можно много написать-прочитать.
              0
              какой именно конфиг интересует? конфигурация МВК описана здесь: habrahabr.ru/company/oversun-mercury/blog/92908/
                +2
                интереснее читать не как оно работает, а как оно настроено и почему)
              –1
              Люблю читать ваши статьи, жутко интересно! Спасибо)
                0
                спасибо, стараемся сделать посты интереснее. в ближайшее время опробуем видео.
                +1
                схема почему-то без пояснений. fe1test, fe, slb
                  +1
                  Slb — узлы балансировщиков, fe — узлы backend-ов, fe1test тестовая платформа.
                  0
                  Файлики можно разбарсывать по WebDav, nginx его для этого и поддерживает. DRBD избыточен если нужно просто синхронизировать фаилы, кроме этого можно получить ололо, когда у нас DRBD кластер рассинхронизируется.
                    +1
                    мм если потребуется добавить еще один узел аналогичный по функционалу Fe1 и Fe2 что будете делать с DRBD?
                    мы столкнулись с тем что расширить на 3 узла очень проблематично DRBD и затратно по времени и затем перешли на более простую синхронизацию дерганьем скрипта…
                      +1
                      Для тех целей, которые ставил перед нами заказчик мы решили что backend серверов будет 2, не вижу смысла делать еще один backend. Если же вдруг случится ситуация, что ресурсов на backend серверах будет не хватать, мы на «горячую» добавим памяти и процессора.
                      –3
                      Вы там уже разобрались со своими финансовыми заморочками? Сервера больше не отключают навсегда? Вам уже можно доверить сайт с нулевой посещаемостью (я забочусь о своих клиентах)?
                        0
                        Что? Почему до сих пор никто McHost не припомнил? :)
                          +2
                          Потроха в студию!

                          Поясню: )) не знаю как остальным, а мне очень любопытно, как все устроенно (это с детства :-) ). Читать о ваших успехах на удивление интересно (10000 плюсов пиаршику в ежеквартальную карму), но в итоге чувствуешь себя немножко обманутым. Мне лично интересней на конфиги смотреть, а не на блок схемы… так сказать мое ИМХО.
                            0
                            Спрашивайте конкретно, что Вас интересует и мы Вам ответим. Выкладывать конфиги всего софта, который мы использовали не считаю интересным для Хабросообщества.
                              0
                              спасибо за 10000 плюсов )).
                              +3
                              Оверсан, насколько мне известно вы самостоятельно разрабатываете облачный продукт схожий с Amazon Cloud. Когда планируется использовать собственный продукт?

                              Кста iSCSI массив на котором хранятся образы виртуальных машин как-нибудь резервируете? (active-active репликация например) Чревато для кастомеров если нет.
                                +2
                                iSCSI массив реализован на продукте HP p4300 SAN, кластер состоит из 4 узлов (дисковых полок), которые объединены в массив RAID5, внутри самого узла так же сделан RAID5 из дисков.
                                То есть нашему заказчику не стоит бояться выхода из строя ни диска массива внутри узла, ни даже целой полки.
                                  0
                                  облаком занимается наша «сестринская» компания, Оверсан-Скалакси. их сервис уже запущен и активно используется.
                                    0
                                    success story уже есть?
                                      +1
                                      насколько мне известно, есть, но как-то они не спешат публиковать это все. мы работаем довольно автономно. думаю, скоро обязательно что-нибудь напишут.
                                  +3
                                  если у Вас 4-е дисковые полки, то максимальное network I/O капасити на полку 4gb/s или 16 gb/s на весь кластер, чего явно мало для масштабирования в случае использования этого же массива другими клиентами, что подразумевается в случае МВК. Плюс редандаси на сетевом уровне, судя по топологии которую Вы публиковали в посте про МВК, дисковый массив вотнут в один свитч, что опять же уменьшает реданданси в разы
                                    +1
                                    Топология подключения на данный момент оптимизируется для лучшей работы iSCSI. Про обновленную топологию будет пост. Да, скорость кластера составляется 16 Gb/s. Как только мы упремся в потолок пропускной способности, то добавим в кластер еще узлы для расширения массива и повышения скорости работы массива.В дальнейшем мы будем предлагать клиентам более быстрое хранилище. Но тем не менее я не считаю скорость в 16 Gb/s недостаточной для нормального функционирования МВК.
                                    +2
                                    ага) jumbo frames не забудьте включить, вцелом все ок :)
                                      +1
                                      Спасибо, мы знаем :)
                                      0
                                      А что поверх DRBD?

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

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