Как в 2009 году мы начали строить облако, и где ошиблись



    В октябре 2009-го мы всё перепроверили. Надо было строить дата-центр на 800 стоек. На основании нашей интуиции, прогнозов по рынку и американской ситуации. Вроде как звучало логично, но было страшновато.

    Тогда «облачных» вычислений в России не было, как и облачных хостингов. Собственно, и само слово-то почти не использовалось на рынке. Но мы уже видели по Америке, что там подобные инсталляции пользуются спросом. У нас были за плечами большие проекты создания HPC-кластеров для авиаконструкторов на 500 узлов, и мы верили, что облако — это такой же большой вычислительный кластер.

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

    Знаете, чем принципиально такой кластер отличается от современных облачных инфраструктур? Тем, что у него очень мало обращений к дискам и всё чтение более-менее последовательное. Задача ставится одна, разбивается на куски, и каждая машина делает свой кусок. На тот момент никто не брал серьезно в расчет, что профиль нагрузки на дисковую подсистему для HPC-кластеров и облака принципиально разный: в первом случае это последовательные операции чтения\записи, во втором — полный рандом. И это была не единственная проблема, с которой нам пришлось столкнуться.

    Сетевая архитектура


    Первый важный выбор был такой: InfiniBand или Ethernet для сети внутри основной площадки облака. Мы долго сравнивали и выбрали InfiniBand. Почему? Потому что, повторюсь, рассматривали облако как HPC-кластер, во-первых, и потому что тогда все собиралось из 10Gb-подключений. InfiniBand обещал чудесные скорости, упрощение поддержки и уменьшение стоимости эксплуатации сети.

    Первое плечо в 2010 году было на 10G Ethernet. В то время мы первые начали использовать у себя на платформе опять же первое в мире SDN-решение от компании Nicira, позже купленное VMware за много денег, которое сейчас называется VMware NSX. Как мы тогда учились строить облака, точно так же команда Nicira училась делать SDN. Само собой, без проблем не обходилось, даже как-то пару раз всё знатно падало. Тогдашние сетевые карты «отваливались» при долгой эксплуатации, что только добавляло нам драйва в работу — в общем, жесть. Некоторое продолжительное время после очередного мажорного обновления от Nicira эксплуатация жила на валерьянке. Однако к моменту запуска 56G InfiniBand мы совместно с коллегами из Nicira успешно полечили часть проблем, буря поутихла и все вздохнули с облегчением.

    Если бы мы сегодня проектировали облако, то поставили бы на Ethernet, наверное. Потому что правильная история архитектуры шла все же в этом направлении. Но именно InfiniBand дал нам огромные плюсы, которые мы смогли использовать позже.

    Первый рост


    В 2011–2012 годах начался первый этап роста. «Хотим, как в Амазоне, но дешевле и в России» — это первая категория заказчиков. «Хотим особой магии» — вторая. Из-за того, что все тогда рекламировали облака как чудо-средство для бесперебойной работы инфраструктуры, у нас возникали некоторые непонимания с заказчиками. Весь рынок быстро от больших заказчиков получил по голове из-за того, что большие заказчики привыкли к близкому к нулю даунтайму физической инфраструктуры. Сервак упал — выговор начальнику отдела. А облако за счет дополнительной прослойки виртуализации и некоего пула оркестрирования работает чуть менее стабильно физических серверов. Работать с отказами ВМ никто не хотел, т. к. в облаке настраивали все вручную и никто не использовал автоматизацию и кластерные решения, способные улучшить ситуацию. Амазон говорит: «Всё в облаке может упасть», но рынок-то ведь это не устраивает. Заказчики верили, что облако — это же магия, все должно работать без перерывов и виртуальные машины должны сами между дата-центрами мигрировать… Все заходили с одним экземпляром сервера на одну виртуалку. А ещё уровень развития ИТ тогда был такой, что автоматизации было мало: все делали руками один раз по идеологии «работает — не трогай». Поэтому при перезапуске физического хоста надо было вручную поднимать все виртуальные машины. Наша поддержка занималась в том числе и этим для ряда заказчиков. Это одна из первых вещей, которая была решена внутренним сервисом.

    Кто приходил в облако? Самые разные люди. Одни из первых стали приходить распределённые интернет-магазины. Потом люди начали заносить бизнес-критичные сервисы в нормальной архитектуре. Многие рассматривали облако как фейловер-площадку, что-то типа дата-центра резерва. Потом уже переезжали как на основную, но оставляли вторую площадку как резерв. Те заказчики, кто уже тогда заложился на такую архитектуру, в большинстве до сих пор очень довольны. Правильно настроенная схема миграции в случае сбоев была нашей гордостью — было очень круто наблюдать, как происходит какая-то крупная авария в Москве, а сервисы заказчика автоматически мигрируют и развёртываются на резерве.

    Диски и флеш


    Первый рост был очень быстрым. Быстрее, чем мы могли предсказать при проектировании архитектуры. Мы довольно оперативно закупали железо, но в какой-то момент упёрлись в потолок по дискам. Как раз тогда мы закладывали уже третий дата-центр, он был второй под облако — будущий Компрессор, сертифицированный T-III по аптайму.

    В 2014 году появились очень крупные заказчики и мы столкнулись со следующей проблемой — просадкой систем хранения. Когда у вас 7 банков, 5 торговых сетей, туристическая компания и какой-нибудь НИИ с геологоразведкой, это всё может внезапно совпасть по пикам нагрузки.

    Тогдашняя типовая архитектура хранения данных не предполагала, что у пользователей есть квоты на скорость записи. На запись или чтение ставилось всё в порядке живой очереди, и дальше СХД всё это обрабатывала. А потом была «чёрная пятница» распродаж и мы увидели, что у пользователей СХД скорость упала почти в 30 раз — розница забивала своими запросами почти всю мощность по записи. Упал сайт медклиники, страницы открывались по 15 минут. Нужно было что-то срочно делать.

    Даже на самых высокопроизводительных дисковых массивах, как правило дорогущих, не было возможности разграничения приоритетов по производительности. То есть заказчики всё равно могли друг на друга влиять. Нужно было либо переписывать драйвер в гипервизоре, либо придумывать что-то ещё — и срочно.

    Проблему мы решили покупкой all-flash массивов с пропускной способностью под миллион IOPS. Получилось 100 000 IOPS на виртуальный диск. Производительности хватило за глаза, но надо было всё равно придумывать лимитирование по R/W. На уровне дискового массива на тот момент (конец 2014 года) проблема была нерешаема. Наша облачная платформа построена на непроприетарном KVM, и мы могли свободно лазить в его код. Примерно за 9 месяцев мы аккуратно переписали и протестировали функциональность.

    В этот момент сочетание InfiniBand и All-flash дало нам совершенно дикую вещь — мы первыми на нашем рынке ввели услугу по дискам с гарантированной производительностью с жесточайшими штрафами, прописанными SLA. И на рынке на нас конкуренты смотрели с круглыми глазами. Мы говорили: «Даем на диск 100 000 IOPS». Они такие: «Это невозможно…» Мы: «И мы ещё делаем это гарантированно». Они: «Вы вообще чего, чумные, вы сумасшедшие». Для рынка это был шок. Из 10 крупных конкурсов 8 мы выиграли из-за дисков. Тогда вешали медали себе на грудь.

    16 массивов, каждый по миллиону IOPS даёт, по 40 терабайт каждый! Они ещё напрямую подключены к серверам по InfiniBand. Взорвалось там, где вообще никто не думал. Полгода гоняли на тестах, даже ни намёка не было.

    Дело в том, что при падении контроллера массива на InfiniBand маршруты перестраиваются около 30 секунд. Можно сократить это время до 15 секунд, но не дальше — потому что есть ограничения самого протокола. Оказалось, что при достижении определённого количества виртуальных дисков (которые заказчики создавали себе сами) появляется редкий гейзенбаг с контроллером all-flash-хранилища. При запросе на создание нового диска контроллер может сойти с ума, получить 100% нагрузки, уйти в thermal shutdown и сгенерировать то самое 30-секундное переключение. Диски отваливаются от виртуалок. Приплыли. Несколько месяцев мы вместе с вендором СХД искали баг. В итоге нашли, и они под нас правили микрокод контроллеров на массивах. Мы же за это время вокруг этих массивов написали реально целую прослойку, которая позволяла решить проблему. И ещё пришлось переписать почти весь стек управления.

    Демотиваторы про массивы висят у поддержки до сих пор.

    Наши дни


    Потом возникли проблемы с ПО для удалённых рабочих мест. Там решение было проприетарное, и диалог с вендором происходил так:
    — Вы не могли бы нам помочь?
    — Нет.
    — Вы вообще черти полные, мы на вас будем жаловаться.
    — Пожалуйста.
    В этот момент мы решили, что надо отказываться от проприетарных компонент. Тогда потребность закрыли своей разработкой. Сейчас инвестируем в опенсорс-проекты — как в истории с тем, что мы в своё время обеспечили почти полугодовой бюджет ALT Linux, иногда наш запрос резко ускорял развитие нужной разработки. Параллельно свою разработку на этой волне мы довели до состояния, как сказали наши европейские коллеги, «чертовски удивительной».

    Сегодня мы смотрим на облако уже опытным взглядом и понимаем, как его развивать дальше на несколько лет вперёд. И, опять же, понимаем, что можем делать с KVM вообще что угодно, потому что есть ресурсы разработки.

    Ссылки


    КРОК Облачные сервисы

    147,00

    Облачная IaaS-платформа собственной разработки

    Поделиться публикацией
    Комментарии 22
      +2
      И сайт не открывается img
        +7
        Это удочка на следующую статью «Как в 2018-м мы писали статью на Хабр и где ошиблись».
          0
          Всего 700 просмотров и уже Хабраэффект? :)))
          +2
          Отдельному облачному бложику — привет.
          Приятный рассказ, надеюсь продолжите в том же духе, делая акцент на технические моменты, а не бизнес, было бы крайне интересно.
            +6
            Раз уж затронули opensource и вклад компании в него, можете привести примеры?
              +2
              Публичный репозиторий нашей команды тут: github.com/C2Devel. В него выкладываем модифицированные нами opensource решения. Также мы являемся контрибьюторами (пусть и не очень активными) в проектах, результаты которых мы используем в облаке (Ceph, Open vSwitch, различные модули Puppet). Есть и отдельные небольшие проекты, написанные нашими ребятами и выложенные в публичные репозитории.
              Интегратор КРОК также ведёт деятельность в opensource-сообществе, но это уже не облачное подразделение.
                0
                Спасибо, посмотрю. (просто интересно)
              0
              Таки теперь много становится более понятным.
                0
                Интересная статья.
                Добавьте пожалуйста еще картинки для большей наглядности) Там схемы, сравнения, диаграммы и т. д.
                  0
                  В этот момент сочетание InfiniBand и All-flash дало нам совершенно дикую вещь — мы первыми на нашем рынке ввели услугу по дискам с гарантированной производительностью с жесточайшими штрафами, прописанными SLA. И на рынке на нас конкуренты смотрели с круглыми глазами.
                  речь идет о локальном рынке? Ибо у того же AWS лимитирование по IOPS есть с очень давних пор.
                    0
                    Да, про Россию.
                      0

                      Так все таки лимитирование или гарантия? Две большие разницы…

                        0
                        Именно гарантия.

                        Технически гарантия достигается благодаря:
                        — использованию высокопроизводительных массивов, которые имеют большой ресурс по IOPS;
                        — нашему планировщику, который распределяет виртуальные диски по разным массивам в зависимости от того, на сколько те утилизированы, и того, сколько производительности должен предоставить данный виртуальный диск;
                        — лимитированием нагрузки на каждый отдельный виртуальный диск, чтобы расчеты планировщика не были напрасными.
                    0

                    А СХД я так подозреваю "массивы-скрипки"? До сих пор эксплуатируете или на что-то другое перешли?

                      0
                      Давние проблемы с Violin мы полечили и сейчас успешно эксплуатируем.
                      Также параллельно смотрим, выбираем решение, которое со временем придёт им на замену. Недавно мы внедрили ещё один тип стороджа на магнитных дисках, который работает под управлением EMC ScaleIO. Мы позиционируем его как новый «универсальный тип дисков». Он имеет схожие с амазоновским st1 volume type характеристики: ограничен 500 IOPS, производительность в MB/s зависит от размера волюма, однако не имеет бёрстинга и может быть использован в качестве загрузочного диска.
                      Сейчас он ограниченно доступен в облаке, так как проходит обкатку.
                        0

                        По ScaleIO интересно. Слышал, что есть инсталляции в России, но без конкретики. Можете рассказать что используете для межнодового взаимодействия в кластере? Ethernet 10G? Сами ноды самосбор или брендовые сервера? Сам кластер ScaleIO используете только под хранение или совмещаете роли и на серверах гипервизары тоже крутятся? Что используете из OS на нодах ScaleIO? Что можете сказать про надежность из опыта эксплуатации? Проблемы с недоступностью или потерей данных случались? Если не секрет, то насколько большой кластер сейчас у вас по количеству нод и по полезной емкости? Просто что бы представлять масштабы действа и на сколько все серьёзно :).

                          0
                          Компоненты кластера работают на нодах совместно с другими сервисными ролями Облака, SDS/SDC и вовсе работают на серверах-гипервизорах. ОС — CentOS 7.2. Надежность сейчас нещадно тестируется, результаты пока очень радуют. Больше технических и архитектурных подробностей вместе с ответами на все вопросы будет в готовящемся посте на эту тему.
                            0

                            Спасибо за ответ. Интересно будет почитать пост, когда подготовите. Буду ждать :).

                      +1
                      Доброго времени суток. А про костыли (ну или прослойки для решения проблем) с кусками кода будете писать? Было бы интересно посмотреть, что именно из разработок на скорую руку у вас есть и из серии «быстро, быстро сделали, чтобы работало… и третий год не трогаем» :)
                        0
                        Когда-нибудь будем.
                        0
                        Извините, а где цена на услуги на вашем сайте? Ваш конкурент — Амазон — не скрывает этого.
                          +1
                          Конкурентами Амазон я бы назвал Microsoft и Google. Догоняют-догоняют, да никак не догонят.
                          Мы же скорее взяли Amazon API, как де-факто отраслевой стандарт и лучшую практику.

                          Что касается публичных цен, то мы в основном работаем со средним и крупным бизнесом.
                          А точнее с задачами по размещению в облаке business critical сервисов таких организаций.
                          В подобных проектах обычно используются не только вычислительные ресурсы из облака, но еще и услуги по расширенной технической поддержке, проектирование, бэкап, мониторинг и т.д.

                          Публичные цены хороши там, где сервис высоко стандартизирован, например, на рынке SMB и физических лиц.
                          Когда же проекты в облаке становятся хоть сколь-либо комплексными, то в публичных ценах теряется весь смысл.

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

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