В октябре 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 вообще что угодно, потому что есть ресурсы разработки.

Ссылки

• Миграция инфраструктуры в «облако» по шагам: какие возникают сложности и где
• Моя почта — MBerezin@croc.ru