Начиналось всё с системника в общаге МГУ и обычного хостинга, на котором размещалось наше расписание электричек, которое многие из вас видели. И перекладывания файлов по ночам, чтобы уложиться в лимиты нагрузки. Потом появились первые сервера. Они получали тройной трафик на майские, отчего сразу ложились. Точнее, мы не знаем, какой трафик они получали, потому что ложились именно на тройном от обычного.
Оглядываясь назад, могу сказать, что все действия по размещению с тех пор — это вынужденные ходы. И вот только сейчас на пятнадцатый год мы можем настраивать инфраструктуру так, как нужно нам.
Сейчас мы стоим в 4 физически разных ЦОДах, соединённых кольцом тёмной оптики, размещая там 5 независимых пулов ресурсов. И так получилось, что если в одну из кроссовых попадёт метеорит, то у нас тут же отвалится 3 этих пула, а оставшиеся два не потянут нагрузку. Поэтому мы занялись полной ребалансировкой, чтобы навести порядок.
Сначала ЦОДа вообще не было. Был старый системник в общаге МГУ. Потом, почти сразу — виртуальный хостинг у Мастерхоста (они ещё живы, чертяки). Посещаемость сайта с расписанием электричек удваивалась каждые 4 недели, поэтому очень скоро мы перешли на KVM-VPS, это случилось примерно в 2005 году. В какой-то момент мы упёрлись в ограничения по трафику, поскольку тогда надо было соблюдать баланс между входящим и исходящим. У нас было две инсталляции, и мы перекладывали с одной на другую пару увесистых файлов каждую ночь, чтобы соблюсти требуемые пропорции.
В марте 2009 были только VPS. Это дело хорошее, решили переходить на colocation. Купили пару физических железных серверов (один из них — тот самый со стены, тело которого мы храним как память). Поставили в ЦОД Фиорд (и они ещё живы, чертяки). Почему? Потому что было недалеко от тогдашнего офиса, порекомендовал знакомый, и вставать надо было быстро. Плюс было сравнительно недорого.
Разделение нагрузки между серверами было простым: на каждом был бэк, MySQL с master-slave репликацией, фронт был там же, где и реплика. Ну т.е. почти без разделения по типу нагрузки. Довольно скоро их тоже начало не хватать, купили третий.
Примерно 1 октября 2009 мы поняли, что серверов уже больше, но на новый год ляжем. Прогнозы по трафику показывали, что возможная мощность будет перекрыта с запасом. Причём упирались мы в производительность БД. Был месяц-полтора на подготовку перед ростом трафика. Это было время первых оптимизаций. Купили пару серверов чисто под БД. Там делали акцент на быстрые диски со скоростью вращения 15krpm (не помню точную причину, почему мы не использовали SSD, но скорее всего они имели невысокий лимит по количеству операций записи, и при этом стоили, как самолет). Разделили фронт, бэк, базы, подкрутили настройки nginx, MySQL, провели ресеч по оптимизации SQL запросов. Пережили.
Сейчас-то мы стоим в паре Tier-III ЦОДов и в Tier-II по UI (с замахом на T3, но без сертификатов). А вот Фиорд был ни разу даже не T-II. У них были проблемы по живучести, бывали ситуации из разряда «все провода питания в одном коллекторе, а там пожар, а генератор ехал три часа». В общем, решили переезжать.
Выбрали ещё один ЦОД, Караван. Задача: как переехать серверами без даунтайма? Решили пожить на два ЦОДа какое-то время. Благо трафика внутри системы на тот момент было не столько, как сейчас, можно было гонять трафик по VPN между локациями какое-то время (особенно вне сезона). Сделали балансировку трафика. Постепенно увеличивали долю Каравана, через некоторое время полностью переехали туда. И вот у нас остался один ЦОД. А нужно два, мы это уже понимали, спасибо сбоям у Фиорда. Оглядываясь на те времена, могу сказать, что TIER III тоже не панацея, живучесть-то будет 99,95, но вот доступность — это другое. Так что одного ЦОДа для доступности 99,95 и выше точно не хватит.
Вторым выбрали Стордату, и там уже была возможность оптического линка с площадкой Каравана. Успели протянуть первую жилу. Только начали загружать новый ЦОД, как Караван объявил, что у них наступила задница. Им надо было покинуть площадку, потому что здание сносят. Уже. Сюрприз! Новая площадка есть, предлагают потушить все, кранами поднять стойки с оборудованием (тогда у нас уже было 2,5 стойки железа), перевести, включить, и все заработает… 4 часа на все… сказки… я уж молчу, что нам даже час простоя не подходил, а тут история на сутки минимум затянулась бы. Причём подавалось всё это в духе «Всё пропало, гипс снимают, клиент уезжает!». 29 сентября первый звонок, а числа 10 октября они хотели забрать всё и везти. За 3-5 дней нам пришлось разработать план переезда, и в 3 этапа, выключая по 1/3 оборудования за раз с полным сохранением сервиса и аптайма перевезти машины в Стордату. В итоге простой был 15 минут в одном не самом критичном сервисе.
Так мы опять остались с одним ЦОДом.
В этот момент нам надоело таскаться с серверами под мышкой и играть в грузчиков. Плюс надоело заниматься самим железом в ЦОДе. Стали смотреть в сторону публичных облаков.
Начали искать варианты с облаками. Вышли на Крок, попробовали, протестировали, договорились по условиям. Мы встали в облако, которое в ЦОДе «Компрессор». Сделали кольцо тёмной оптики между Стордатой, Компрессором и офисом. Везде свой аплинк и два плеча оптики. Перерубание любого из лучей не рушит сеть. Потеря аплинка не рушит сеть. Получили статус LIR, есть своя подсеть, BGP анонсы, сеть резервируем, красота. Как именно заходили в облако с точки зрения сети здесь описывать не буду, но были нюансы.
Так у нас стало 2 ЦОДа.
У Крока есть еще ЦОД на Волочаевской, они расширили свое облако и туда, предлагали перенести часть ресурсов наших туда. Но помня историю с Караваном, который, по сути, так и не оправился после сноса ЦОДа, захотелось облачные ресурсы брать у разных провайдеров, чтобы уменьшить риск, что компания перестанет существовать (страна такая, что игнорировать такой риск нельзя). Поэтому с Волочаевской не стали связываться на тот момент. Ну и ещё второй вендор делает магию с ценами. Потому что, когда вы можете взять и эластично уехать, это даёт сильную переговорную позицию по ценам.
Смотрели разные варианты, но выбор пал на МТС.Cloud. Тому было несколько причин: облако на тестах показало себя хорошо, с сетью ребята тоже умеют работать (телеком оператор все-таки), и очень агрессивная маркетинговая политика захвата рынка, как следствие, интересные цены.
Итого 3 ЦОДа.
Дальше все-таки мы подключили и «Волочаевскую» — нужны были дополнительные ресурсы, а в «Компрессоре» уже было тесновато. В общем, перераспределили нагрузку между тремя облаками и своим оборудованием в Стордате.
4 ЦОДа. Причём уже по живучести везде T3. Сертификаты, кажется, не у всех есть, но не буду утверждать точно.
У МТС был нюанс. Ничего кроме МГТС последней милей туда зайти не могло. При этом тянуть темную оптику МГТС целиком от ЦОДа до ЦОДа не было возможности (долго, дорого, и, если я не путаю, они такую услугу и не предоставляют). Пришлось делать со стыком, выводить два луча из ЦОДа до ближайших колодцев, где есть наш провайдер темной оптики Мастертел. У них разветвлённая сеть оптики по всему городу, и, если что, они просто сваривают нужный маршрут и дают вам жилу. А в это время Чемпионат мира по футболу пришел в город, неожиданно, как снег зимой, и доступы в колодцы в Москве закрыли. Мы ждали, пока это чудо закончится, и мы сможем прокинуть свой линк. Казалось бы, нужно было выйти из ЦОДа МТС с оптикой в руках, посвистывая дойти до нужного люка и опустить её туда. Условно. Делали три с половиной месяца. Точнее первый луч сделали довольно быстро, к началу августа (напомню, что ЧМ закончился 15 июля). А вот со вторым плечом пришлось повозиться — первый вариант подразумевал, что надо перекопать Каширское шоссе, для чего перекрыть его на недельку (там при реконструкции завалило какой-то туннель, где лежат коммуникации, надо откапывать). К счастью, нашли альтернативу: другой маршрут, такой же геонезависимый. Получилось две жилы от этого дата-центра до разных точек нашего присутствия. Кольцо оптики превратилось в кольцо с ручкой.
Чуть забегая вперёд, скажу, что всё равно нам его положили. К счастью, в самом начале эксплуатации, когда еще мало всего перенесли. В одном колодце случился пожар, и пока монтажники матерились в пене, во втором колодце кто-то вытащил посмотреть коннектор (какой-то он был новой конструкции, интересно же). Математически вероятность одновременного сбоя была ничтожна. Практически мы его поймали. Собственно, нам и во Фиорде везло — там рубанулось основное питание, и вместо включения его обратно, кто-то перепутал рубильник и выключил резервную линию.
Были не только технические требования по распределению нагрузки между локациями: чудес не бывает, и агрессивная маркетинговая политика с хорошими ценами подразумевает определенные темпы роста потребления ресурсов. Так что мы все время держали в голове, какой процент ресурсов надо отправить в МТС обязательно. Всё остальное мы перераспределяли между другими ЦОДами более-менее равномерно.
Опыт использования публичных облаков показал нам, что их удобно использовать, когда надо быстро добавить ресурсов, под эксперименты, под пилот и т.п. При использовании под постоянной нагрузкой, получается дороже, чем крутить свое железо. Но мы уже не могли отказаться от идеи контейнеров, бесшовных миграций виртуалок внутри кластера и т.п. Написали автоматизацию, чтобы гасить часть машин ночью, но всё равно экономика не складывалась. У нас не было достаточно компетенции для поддержки частного облака, пришлось отрастить.
Искали решение, которое бы позволило получить облако на своем железе относительно легко. На тот момент мы никогда не работали с серверами Cisco, только с сетевым стеком, в этом был риск. На Деллах же простое хорошо знакомое железо, надёжное как автомат Калашникова. У нас такое стояло годами, и до сих пор где-то есть. Но идея Hyperflex в том, что он из коробки поддерживает гиперконвергентность итогового решения. А у Делла всё живёт на обычных маршрутизаторах, и там есть нюансы. В частности, производительность по факту не такая прикольная как в презентациях из-за оверхеда. В смысле, их можно правильно настроить и будет супер, но мы решили, что это не наш бизнес, и пусть Делл готовят те, кто находит в этом призвание. В итоге выбрали Циско Hyperflex. Этот вариант победил по совокупности как самый интересный: меньше геморроя в настройке и эксплуатации, и во время тестов все было хорошо. Летом 2019 запустили кластер в бой. У нас была полупустая стойка в Компрессоре, занятая по большей части только сетевым оборудованием, там и разместили. Таким образом получили пятый «ЦОД» — физически-то четыре, но по пулам ресурсов получилось пять.
Взяли, посчитали объём постоянной нагрузки и объём переменной. Постоянную превратили в нагрузку на своё железо. Но так, чтобы на уровне оборудования давало облачные преимущества по отказоустойчивости и резервированию.
Окупаемость проекта железного проекта — по средним ценам наших облаков за год.
В этот момент у нас закончились вынужденные ходы. Как видите, у нас не было особо вариантов экономически, и постоянно мы нагружали то, куда должны были встать по каким-то причинам. Это привело к странной ситуации, что нагрузка неравномерная. Отказ любого сегмента (а сегмент с ЦОДами Крока держится на двух Нексусах в узком месте) — это потеря пользовательского опыта. То есть сайт сохранится, но будут явные сложности с доступностью.
Был сбой в МТС со всем ЦОДом. Было ещё два в других. Периодически отваливались облака, либо контроллеры облаков, либо возникала какая-то сложная сетевая проблема. Короче, мы время от времени теряем ЦОДы. Да, кратковременно, но все равно неприятно. В какой-то момент приняли за данность, что ЦОДы отваливаются.
Решили идти на отказоустойчивость уровня дата-центров.
Сейчас мы не ляжем, если откажет один из 5 ЦОДов. Но вот если потеряем плечо Крока — будут очень серьёзные просадки. Так и родился проект отказоустойчивости дата-центров. Цель такая — если ДЦ умрёт, сеть до него умрёт или оборудование умрёт, сайт должен работать без вмешательства руками. Плюс после аварии мы должны штатно восстановиться.
Сейчас:
Нужно:
Сейчас:
Нужно:
Эластик устойчив к потере одной ноды:
MySQL базы (много небольших) управляются достаточно сложно:
Про это лучше детальнее напишет мой коллега, который делал балансировку. Важно то, что до того, как мы навесили это, если мы теряли мастера, то надо было руками зайти на резерв и там поставить флажок r/o=0, перестроить на этот новый мастер ансиблом все реплики, а их в основной гирлянде более двух десятков, поменять конфиги приложения, потом раскатать конфиги и дождаться обновления. Сейчас приложение ходит по одному anycast-ip, который смотрит на LVS балансировщике. Постоянный конфиг не меняется. Вся топология баз на оркестраторе.
Сейчас между нашими ЦОДами протянута тёмная оптика, которая позволяет обращаться к любому ресурсу в пределах нашего кольца как к локальному. Время ответа между ЦОДами и время внутри плюс-минус одинаковое. Это важное отличие от других компаний, которые строят геокластеры. Мы очень сильно завязаны на своё железо и свою сеть, и мы не пытаемся локализовать запросы внутри ЦОДа. Это с одной стороны круто, а с другой — если захотим в Европу или в Китай, то свою тёмную оптику не вытащим.
Это означает ребалансировку почти всего, в первую очередь баз данных. Много схем, когда активный мастер и на чтение, и на запись держит всю нагрузку, а рядом реплика синхронная для быстрого переключения (мы не пишем в два сразу, а именно реплицируем, иначе работает не очень хорошо). Основная база при этом в одном ЦОДе, а реплика — в другом. Ещё частичные копии могут быть в третьем для отдельных приложений. Таких инстансов от 10 до 15 в зависимости от времени года. Оркестратор —— растянутый кластер между цодами 3 ЦОДами. Тут мы детальнее расскажем ещё, когда найдутся силы описать, как вся эта музыка играет.
Нужно будет покопаться в приложениях. Это и сейчас нужно: у нас иногда бывает, что если порвалось соединение, то корректно погасить старое, открыть новое. Но иногда повторяются запросы в уже потерянное соединение в цикле, пока процесс не сдохнет. Последнее, что ловили — задача по крону, напоминание про поезд не выписалось.
В общем, есть ещё чем заняться, но план понятный.
Оглядываясь назад, могу сказать, что все действия по размещению с тех пор — это вынужденные ходы. И вот только сейчас на пятнадцатый год мы можем настраивать инфраструктуру так, как нужно нам.
Сейчас мы стоим в 4 физически разных ЦОДах, соединённых кольцом тёмной оптики, размещая там 5 независимых пулов ресурсов. И так получилось, что если в одну из кроссовых попадёт метеорит, то у нас тут же отвалится 3 этих пула, а оставшиеся два не потянут нагрузку. Поэтому мы занялись полной ребалансировкой, чтобы навести порядок.
Первый ЦОД
Сначала ЦОДа вообще не было. Был старый системник в общаге МГУ. Потом, почти сразу — виртуальный хостинг у Мастерхоста (они ещё живы, чертяки). Посещаемость сайта с расписанием электричек удваивалась каждые 4 недели, поэтому очень скоро мы перешли на KVM-VPS, это случилось примерно в 2005 году. В какой-то момент мы упёрлись в ограничения по трафику, поскольку тогда надо было соблюдать баланс между входящим и исходящим. У нас было две инсталляции, и мы перекладывали с одной на другую пару увесистых файлов каждую ночь, чтобы соблюсти требуемые пропорции.
В марте 2009 были только VPS. Это дело хорошее, решили переходить на colocation. Купили пару физических железных серверов (один из них — тот самый со стены, тело которого мы храним как память). Поставили в ЦОД Фиорд (и они ещё живы, чертяки). Почему? Потому что было недалеко от тогдашнего офиса, порекомендовал знакомый, и вставать надо было быстро. Плюс было сравнительно недорого.
Разделение нагрузки между серверами было простым: на каждом был бэк, MySQL с master-slave репликацией, фронт был там же, где и реплика. Ну т.е. почти без разделения по типу нагрузки. Довольно скоро их тоже начало не хватать, купили третий.
Примерно 1 октября 2009 мы поняли, что серверов уже больше, но на новый год ляжем. Прогнозы по трафику показывали, что возможная мощность будет перекрыта с запасом. Причём упирались мы в производительность БД. Был месяц-полтора на подготовку перед ростом трафика. Это было время первых оптимизаций. Купили пару серверов чисто под БД. Там делали акцент на быстрые диски со скоростью вращения 15krpm (не помню точную причину, почему мы не использовали SSD, но скорее всего они имели невысокий лимит по количеству операций записи, и при этом стоили, как самолет). Разделили фронт, бэк, базы, подкрутили настройки nginx, MySQL, провели ресеч по оптимизации SQL запросов. Пережили.
Сейчас-то мы стоим в паре Tier-III ЦОДов и в Tier-II по UI (с замахом на T3, но без сертификатов). А вот Фиорд был ни разу даже не T-II. У них были проблемы по живучести, бывали ситуации из разряда «все провода питания в одном коллекторе, а там пожар, а генератор ехал три часа». В общем, решили переезжать.
Выбрали ещё один ЦОД, Караван. Задача: как переехать серверами без даунтайма? Решили пожить на два ЦОДа какое-то время. Благо трафика внутри системы на тот момент было не столько, как сейчас, можно было гонять трафик по VPN между локациями какое-то время (особенно вне сезона). Сделали балансировку трафика. Постепенно увеличивали долю Каравана, через некоторое время полностью переехали туда. И вот у нас остался один ЦОД. А нужно два, мы это уже понимали, спасибо сбоям у Фиорда. Оглядываясь на те времена, могу сказать, что TIER III тоже не панацея, живучесть-то будет 99,95, но вот доступность — это другое. Так что одного ЦОДа для доступности 99,95 и выше точно не хватит.
Вторым выбрали Стордату, и там уже была возможность оптического линка с площадкой Каравана. Успели протянуть первую жилу. Только начали загружать новый ЦОД, как Караван объявил, что у них наступила задница. Им надо было покинуть площадку, потому что здание сносят. Уже. Сюрприз! Новая площадка есть, предлагают потушить все, кранами поднять стойки с оборудованием (тогда у нас уже было 2,5 стойки железа), перевести, включить, и все заработает… 4 часа на все… сказки… я уж молчу, что нам даже час простоя не подходил, а тут история на сутки минимум затянулась бы. Причём подавалось всё это в духе «Всё пропало, гипс снимают, клиент уезжает!». 29 сентября первый звонок, а числа 10 октября они хотели забрать всё и везти. За 3-5 дней нам пришлось разработать план переезда, и в 3 этапа, выключая по 1/3 оборудования за раз с полным сохранением сервиса и аптайма перевезти машины в Стордату. В итоге простой был 15 минут в одном не самом критичном сервисе.
Так мы опять остались с одним ЦОДом.
В этот момент нам надоело таскаться с серверами под мышкой и играть в грузчиков. Плюс надоело заниматься самим железом в ЦОДе. Стали смотреть в сторону публичных облаков.
От 2 до 5 (почти) ЦОДов
Начали искать варианты с облаками. Вышли на Крок, попробовали, протестировали, договорились по условиям. Мы встали в облако, которое в ЦОДе «Компрессор». Сделали кольцо тёмной оптики между Стордатой, Компрессором и офисом. Везде свой аплинк и два плеча оптики. Перерубание любого из лучей не рушит сеть. Потеря аплинка не рушит сеть. Получили статус LIR, есть своя подсеть, BGP анонсы, сеть резервируем, красота. Как именно заходили в облако с точки зрения сети здесь описывать не буду, но были нюансы.
Так у нас стало 2 ЦОДа.
У Крока есть еще ЦОД на Волочаевской, они расширили свое облако и туда, предлагали перенести часть ресурсов наших туда. Но помня историю с Караваном, который, по сути, так и не оправился после сноса ЦОДа, захотелось облачные ресурсы брать у разных провайдеров, чтобы уменьшить риск, что компания перестанет существовать (страна такая, что игнорировать такой риск нельзя). Поэтому с Волочаевской не стали связываться на тот момент. Ну и ещё второй вендор делает магию с ценами. Потому что, когда вы можете взять и эластично уехать, это даёт сильную переговорную позицию по ценам.
Смотрели разные варианты, но выбор пал на МТС.Cloud. Тому было несколько причин: облако на тестах показало себя хорошо, с сетью ребята тоже умеют работать (телеком оператор все-таки), и очень агрессивная маркетинговая политика захвата рынка, как следствие, интересные цены.
Итого 3 ЦОДа.
Дальше все-таки мы подключили и «Волочаевскую» — нужны были дополнительные ресурсы, а в «Компрессоре» уже было тесновато. В общем, перераспределили нагрузку между тремя облаками и своим оборудованием в Стордате.
4 ЦОДа. Причём уже по живучести везде T3. Сертификаты, кажется, не у всех есть, но не буду утверждать точно.
У МТС был нюанс. Ничего кроме МГТС последней милей туда зайти не могло. При этом тянуть темную оптику МГТС целиком от ЦОДа до ЦОДа не было возможности (долго, дорого, и, если я не путаю, они такую услугу и не предоставляют). Пришлось делать со стыком, выводить два луча из ЦОДа до ближайших колодцев, где есть наш провайдер темной оптики Мастертел. У них разветвлённая сеть оптики по всему городу, и, если что, они просто сваривают нужный маршрут и дают вам жилу. А в это время Чемпионат мира по футболу пришел в город, неожиданно, как снег зимой, и доступы в колодцы в Москве закрыли. Мы ждали, пока это чудо закончится, и мы сможем прокинуть свой линк. Казалось бы, нужно было выйти из ЦОДа МТС с оптикой в руках, посвистывая дойти до нужного люка и опустить её туда. Условно. Делали три с половиной месяца. Точнее первый луч сделали довольно быстро, к началу августа (напомню, что ЧМ закончился 15 июля). А вот со вторым плечом пришлось повозиться — первый вариант подразумевал, что надо перекопать Каширское шоссе, для чего перекрыть его на недельку (там при реконструкции завалило какой-то туннель, где лежат коммуникации, надо откапывать). К счастью, нашли альтернативу: другой маршрут, такой же геонезависимый. Получилось две жилы от этого дата-центра до разных точек нашего присутствия. Кольцо оптики превратилось в кольцо с ручкой.
Чуть забегая вперёд, скажу, что всё равно нам его положили. К счастью, в самом начале эксплуатации, когда еще мало всего перенесли. В одном колодце случился пожар, и пока монтажники матерились в пене, во втором колодце кто-то вытащил посмотреть коннектор (какой-то он был новой конструкции, интересно же). Математически вероятность одновременного сбоя была ничтожна. Практически мы его поймали. Собственно, нам и во Фиорде везло — там рубанулось основное питание, и вместо включения его обратно, кто-то перепутал рубильник и выключил резервную линию.
Были не только технические требования по распределению нагрузки между локациями: чудес не бывает, и агрессивная маркетинговая политика с хорошими ценами подразумевает определенные темпы роста потребления ресурсов. Так что мы все время держали в голове, какой процент ресурсов надо отправить в МТС обязательно. Всё остальное мы перераспределяли между другими ЦОДами более-менее равномерно.
Снова своё железо
Опыт использования публичных облаков показал нам, что их удобно использовать, когда надо быстро добавить ресурсов, под эксперименты, под пилот и т.п. При использовании под постоянной нагрузкой, получается дороже, чем крутить свое железо. Но мы уже не могли отказаться от идеи контейнеров, бесшовных миграций виртуалок внутри кластера и т.п. Написали автоматизацию, чтобы гасить часть машин ночью, но всё равно экономика не складывалась. У нас не было достаточно компетенции для поддержки частного облака, пришлось отрастить.
Искали решение, которое бы позволило получить облако на своем железе относительно легко. На тот момент мы никогда не работали с серверами Cisco, только с сетевым стеком, в этом был риск. На Деллах же простое хорошо знакомое железо, надёжное как автомат Калашникова. У нас такое стояло годами, и до сих пор где-то есть. Но идея Hyperflex в том, что он из коробки поддерживает гиперконвергентность итогового решения. А у Делла всё живёт на обычных маршрутизаторах, и там есть нюансы. В частности, производительность по факту не такая прикольная как в презентациях из-за оверхеда. В смысле, их можно правильно настроить и будет супер, но мы решили, что это не наш бизнес, и пусть Делл готовят те, кто находит в этом призвание. В итоге выбрали Циско Hyperflex. Этот вариант победил по совокупности как самый интересный: меньше геморроя в настройке и эксплуатации, и во время тестов все было хорошо. Летом 2019 запустили кластер в бой. У нас была полупустая стойка в Компрессоре, занятая по большей части только сетевым оборудованием, там и разместили. Таким образом получили пятый «ЦОД» — физически-то четыре, но по пулам ресурсов получилось пять.
Взяли, посчитали объём постоянной нагрузки и объём переменной. Постоянную превратили в нагрузку на своё железо. Но так, чтобы на уровне оборудования давало облачные преимущества по отказоустойчивости и резервированию.
Окупаемость проекта железного проекта — по средним ценам наших облаков за год.
Вы находитесь здесь
В этот момент у нас закончились вынужденные ходы. Как видите, у нас не было особо вариантов экономически, и постоянно мы нагружали то, куда должны были встать по каким-то причинам. Это привело к странной ситуации, что нагрузка неравномерная. Отказ любого сегмента (а сегмент с ЦОДами Крока держится на двух Нексусах в узком месте) — это потеря пользовательского опыта. То есть сайт сохранится, но будут явные сложности с доступностью.
Был сбой в МТС со всем ЦОДом. Было ещё два в других. Периодически отваливались облака, либо контроллеры облаков, либо возникала какая-то сложная сетевая проблема. Короче, мы время от времени теряем ЦОДы. Да, кратковременно, но все равно неприятно. В какой-то момент приняли за данность, что ЦОДы отваливаются.
Решили идти на отказоустойчивость уровня дата-центров.
Сейчас мы не ляжем, если откажет один из 5 ЦОДов. Но вот если потеряем плечо Крока — будут очень серьёзные просадки. Так и родился проект отказоустойчивости дата-центров. Цель такая — если ДЦ умрёт, сеть до него умрёт или оборудование умрёт, сайт должен работать без вмешательства руками. Плюс после аварии мы должны штатно восстановиться.
В чём подводные камни
Сейчас:
Нужно:
Сейчас:
Нужно:
Эластик устойчив к потере одной ноды:
MySQL базы (много небольших) управляются достаточно сложно:
Про это лучше детальнее напишет мой коллега, который делал балансировку. Важно то, что до того, как мы навесили это, если мы теряли мастера, то надо было руками зайти на резерв и там поставить флажок r/o=0, перестроить на этот новый мастер ансиблом все реплики, а их в основной гирлянде более двух десятков, поменять конфиги приложения, потом раскатать конфиги и дождаться обновления. Сейчас приложение ходит по одному anycast-ip, который смотрит на LVS балансировщике. Постоянный конфиг не меняется. Вся топология баз на оркестраторе.
Сейчас между нашими ЦОДами протянута тёмная оптика, которая позволяет обращаться к любому ресурсу в пределах нашего кольца как к локальному. Время ответа между ЦОДами и время внутри плюс-минус одинаковое. Это важное отличие от других компаний, которые строят геокластеры. Мы очень сильно завязаны на своё железо и свою сеть, и мы не пытаемся локализовать запросы внутри ЦОДа. Это с одной стороны круто, а с другой — если захотим в Европу или в Китай, то свою тёмную оптику не вытащим.
Это означает ребалансировку почти всего, в первую очередь баз данных. Много схем, когда активный мастер и на чтение, и на запись держит всю нагрузку, а рядом реплика синхронная для быстрого переключения (мы не пишем в два сразу, а именно реплицируем, иначе работает не очень хорошо). Основная база при этом в одном ЦОДе, а реплика — в другом. Ещё частичные копии могут быть в третьем для отдельных приложений. Таких инстансов от 10 до 15 в зависимости от времени года. Оркестратор —— растянутый кластер между цодами 3 ЦОДами. Тут мы детальнее расскажем ещё, когда найдутся силы описать, как вся эта музыка играет.
Нужно будет покопаться в приложениях. Это и сейчас нужно: у нас иногда бывает, что если порвалось соединение, то корректно погасить старое, открыть новое. Но иногда повторяются запросы в уже потерянное соединение в цикле, пока процесс не сдохнет. Последнее, что ловили — задача по крону, напоминание про поезд не выписалось.
В общем, есть ещё чем заняться, но план понятный.
smart
Не совсем понял, как устроен failover для mysql. Интересно про это будет почитать подробнее.
Ну и можно неприличный вопрос? А почему mysql, а не postgres?
Molodoi Автор
Первое:
Детали, как это работает, потянет на целую статью. Думаю, напишем и про это.
Если коротко. Есть много (под сотню) различных БД с четко ограниченной предметной областью, там используется с master — standby репликация. Еще есть одна большая БД, которую еще не растащили по небольшим базам. Эта БД собрана в «гирлянду», т.е. ветвистое дерево master-slave-slave… В случае падения мастера github orchestrator промоутит (снимает флаг read-only), на его место или единственный standby инстанс, или одну из реплик гирлянды (по хитрым правилам) и перестраивает остальные, чтобы те тянули данные с нового мастера. Proxysql ориентируются на флаг read-only на mysql и меняют состав своих хостгрупп. Сами proxySQL подняты с одним и тем же IP в разных локациях, поэтому при отказе одного, запросы начинают уходить к соседям.
Второе:
Наверное, правильный ответ “так исторически сложилось”. Когда-то давно выбрали MariaDb, с тех пор парк разросся, внутренняя экспертиза прокачалась, а с postgress практического опыта почти нет. Поэтому пока только аккуратно присматриваемся, но не переезжаем.