Как мы разгребаем зоопарк из 5 размещений в дата-центрах

    Начиналось всё с системника в общаге МГУ и обычного хостинга, на котором размещалось наше расписание электричек, которое многие из вас видели. И перекладывания файлов по ночам, чтобы уложиться в лимиты нагрузки. Потом появились первые сервера. Они получали тройной трафик на майские, отчего сразу ложились. Точнее, мы не знаем, какой трафик они получали, потому что ложились именно на тройном от обычного.



    Оглядываясь назад, могу сказать, что все действия по размещению с тех пор — это вынужденные ходы. И вот только сейчас на пятнадцатый год мы можем настраивать инфраструктуру так, как нужно нам.

    Сейчас мы стоим в 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 ЦОДа.

    У Крока есть еще ЦОД на Волочаевской, они расширили свое облако и туда, предлагали перенести часть ресурсов наших туда. Но помня историю с Караваном, который, по сути, так и не оправился после сноса ЦОДа, захотелось облачные ресурсы брать у разных провайдеров, чтобы уменьшить риск, что компания перестанет существовать (страна такая, что игнорировать такой риск нельзя). Поэтому с Волочаевской не стали связываться на тот момент. Ну и ещё второй вендор делает магию с ценами. Потому что, когда вы можете взять и эластично уехать, это даёт сильную переговорную позицию по ценам.

    Смотрели разные варианты, но выбор пал на #CloudMTS. Тому было несколько причин: облако на тестах показало себя хорошо, с сетью ребята тоже умеют работать (телеком оператор все-таки), и очень агрессивная маркетинговая политика захвата рынка, как следствие, интересные цены.

    Итого 3 ЦОДа.

    Дальше все-таки мы подключили и «Волочаевскую» — нужны были дополнительные ресурсы, а в «Компрессоре» уже было тесновато. В общем, перераспределили нагрузку между тремя облаками и своим оборудованием в Стордате.

    4 ЦОДа. Причём уже по живучести везде T3. Сертификаты, кажется, не у всех есть, но не буду утверждать точно.

    У МТС был нюанс. Ничего кроме МГТС последней милей туда зайти не могло. При этом тянуть темную оптику МГТС целиком от ЦОДа до ЦОДа не было возможности (долго, дорого, и, если я не путаю, они такую услугу и не предоставляют). Пришлось делать со стыком, выводить два луча из ЦОДа до ближайших колодцев, где есть наш провайдер темной оптики Мастертел. У них разветвлённая сеть оптики по всему городу, и, если что, они просто сваривают нужный маршрут и дают вам жилу. А в это время Чемпионат мира по футболу пришел в город, неожиданно, как снег зимой, и доступы в колодцы в Москве закрыли. Мы ждали, пока это чудо закончится, и мы сможем прокинуть свой линк. Казалось бы, нужно было выйти из ЦОДа МТС с оптикой в руках, посвистывая дойти до нужного люка и опустить её туда. Условно. Делали три с половиной месяца. Точнее первый луч сделали довольно быстро, к началу августа (напомню, что ЧМ закончился 15 июля). А вот со вторым плечом пришлось повозиться — первый вариант подразумевал, что надо перекопать Каширское шоссе, для чего перекрыть его на недельку (там при реконструкции завалило какой-то туннель, где лежат коммуникации, надо откапывать). К счастью, нашли альтернативу: другой маршрут, такой же геонезависимый. Получилось две жилы от этого дата-центра до разных точек нашего присутствия. Кольцо оптики превратилось в кольцо с ручкой.

    Чуть забегая вперёд, скажу, что всё равно нам его положили. К счастью, в самом начале эксплуатации, когда еще мало всего перенесли. В одном колодце случился пожар, и пока монтажники матерились в пене, во втором колодце кто-то вытащил посмотреть коннектор (какой-то он был новой конструкции, интересно же). Математически вероятность одновременного сбоя была ничтожна. Практически мы его поймали. Собственно, нам и во Фиорде везло — там рубанулось основное питание, и вместо включения его обратно, кто-то перепутал рубильник и выключил резервную линию.

    Были не только технические требования по распределению нагрузки между локациями: чудес не бывает, и агрессивная маркетинговая политика с хорошими ценами подразумевает определенные темпы роста потребления ресурсов. Так что мы все время держали в голове, какой процент ресурсов надо отправить в МТС обязательно. Всё остальное мы перераспределяли между другими ЦОДами более-менее равномерно.

    Снова своё железо


    Опыт использования публичных облаков показал нам, что их удобно использовать, когда надо быстро добавить ресурсов, под эксперименты, под пилот и т.п. При использовании под постоянной нагрузкой, получается дороже, чем крутить свое железо. Но мы уже не могли отказаться от идеи контейнеров, бесшовных миграций виртуалок внутри кластера и т.п. Написали автоматизацию, чтобы гасить часть машин ночью, но всё равно экономика не складывалась. У нас не было достаточно компетенции для поддержки частного облака, пришлось отрастить.

    Искали решение, которое бы позволило получить облако на своем железе относительно легко. На тот момент мы никогда не работали с серверами Cisco, только с сетевым стеком, в этом был риск. На Деллах же простое хорошо знакомое железо, надёжное как автомат Калашникова. У нас такое стояло годами, и до сих пор где-то есть. Но идея Hyperflex в том, что он из коробки поддерживает гиперконвергентность итогового решения. А у Делла всё живёт на обычных маршрутизаторах, и там есть нюансы. В частности, производительность по факту не такая прикольная как в презентациях из-за оверхеда. В смысле, их можно правильно настроить и будет супер, но мы решили, что это не наш бизнес, и пусть Делл готовят те, кто находит в этом призвание. В итоге выбрали Циско Hyperflex. Этот вариант победил по совокупности как самый интересный: меньше геморроя в настройке и эксплуатации, и во время тестов все было хорошо. Летом 2019 запустили кластер в бой. У нас была полупустая стойка в Компрессоре, занятая по большей части только сетевым оборудованием, там и разместили. Таким образом получили пятый «ЦОД» — физически-то четыре, но по пулам ресурсов получилось пять.

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

    Окупаемость проекта железного проекта — по средним ценам наших облаков за год.

    Вы находитесь здесь


    В этот момент у нас закончились вынужденные ходы. Как видите, у нас не было особо вариантов экономически, и постоянно мы нагружали то, куда должны были встать по каким-то причинам. Это привело к странной ситуации, что нагрузка неравномерная. Отказ любого сегмента (а сегмент с ЦОДами Крока держится на двух Нексусах в узком месте) — это потеря пользовательского опыта. То есть сайт сохранится, но будут явные сложности с доступностью.

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

    Решили идти на отказоустойчивость уровня дата-центров.

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

    В чём подводные камни


    Сейчас:


    Нужно:


    Сейчас:


    Нужно:


    Эластик устойчив к потере одной ноды:


    MySQL базы (много небольших) управляются достаточно сложно:



    Про это лучше детальнее напишет мой коллега, который делал балансировку. Важно то, что до того, как мы навесили это, если мы теряли мастера, то надо было руками зайти на резерв и там поставить флажок r/o=0, перестроить на этот новый мастер ансиблом все реплики, а их в основной гирлянде более двух десятков, поменять конфиги приложения, потом раскатать конфиги и дождаться обновления. Сейчас приложение ходит по одному anycast-ip, который смотрит на LVS балансировщике. Постоянный конфиг не меняется. Вся топология баз на оркестраторе.

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

    Это означает ребалансировку почти всего, в первую очередь баз данных. Много схем, когда активный мастер и на чтение, и на запись держит всю нагрузку, а рядом реплика синхронная для быстрого переключения (мы не пишем в два сразу, а именно реплицируем, иначе работает не очень хорошо). Основная база при этом в одном ЦОДе, а реплика — в другом. Ещё частичные копии могут быть в третьем для отдельных приложений. Таких инстансов от 10 до 15 в зависимости от времени года. Оркестратор —— растянутый кластер между цодами 3 ЦОДами. Тут мы детальнее расскажем ещё, когда найдутся силы описать, как вся эта музыка играет.

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

    В общем, есть ещё чем заняться, но план понятный.
    Туту.ру
    Tutu.ru — сервис путешествий №1 в России.

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

      0
      Не совсем понял, как устроен failover для mysql. Интересно про это будет почитать подробнее.

      Ну и можно неприличный вопрос? А почему mysql, а не postgres?
        +4
        Первое:
        Детали, как это работает, потянет на целую статью. Думаю, напишем и про это.
        Если коротко. Есть много (под сотню) различных БД с четко ограниченной предметной областью, там используется с master — standby репликация. Еще есть одна большая БД, которую еще не растащили по небольшим базам. Эта БД собрана в «гирлянду», т.е. ветвистое дерево master-slave-slave… В случае падения мастера github orchestrator промоутит (снимает флаг read-only), на его место или единственный standby инстанс, или одну из реплик гирлянды (по хитрым правилам) и перестраивает остальные, чтобы те тянули данные с нового мастера. Proxysql ориентируются на флаг read-only на mysql и меняют состав своих хостгрупп. Сами proxySQL подняты с одним и тем же IP в разных локациях, поэтому при отказе одного, запросы начинают уходить к соседям.

        Второе:
        Наверное, правильный ответ “так исторически сложилось”. Когда-то давно выбрали MariaDb, с тех пор парк разросся, внутренняя экспертиза прокачалась, а с postgress практического опыта почти нет. Поэтому пока только аккуратно присматриваемся, но не переезжаем.
        0
        Что такое «Dell на маршрутизаторах», c которым сравнивали гиперконвергентный Hyperflex?
          0
          Dell VxRail E560F + Dell S5248F-ON
            0
            Понятно. Спасибо. Может тогда поправить в тексте? А то «мозг спотыкается» на этом месте.
          0
          А какое сейчас количество серверов? завязываетесь ли на одного вендора или остановились на чём-то одном (Dell / Cisco)?
            +2

            Именно свое железо это 4 стойки в ЦОДах и в офисе еще есть, но чуть поменьше. В основном пара вендоров, но бывали эксперименты с другими производителями, не зашло нам. В целом, строгих ограничений нет, но плодить зоопарк тоже нет желания — хочется без сюрпризов:)

              0
              Про зоопарк прекрасно понимаю :)
              А почему остановились именно на вендорском клауде? Почему не тот же opennebula/cloudstack/openstack/vmware поверх commodity железа?
                0

                Основное: уровень требуемой экспертизы для нормальной и надежной работы этих решений. Мы несколько лет назад игрались с кластеризацией поверх обычных серверов, все время что-то шло не так и не туда. Мы же все таки для себя решение строили, а не для зарабатывания на нем. Поставил, запустил и полетели (не так, конечно, получилось, но близко к этому). От начала проекта до выхода в прод 4-5 месяцев получилось, что очень неплохо.
                Но как писал в комменте уже, сейчас в проработке проект OpenShift on Bare Metal. Хотим свое облако с микросервисами на обычном железе попробовать разместить.

                  0
                  А не боитесь вендор-лока и/или необходимости платить существенные деньги за саппорт, который, к тому же, не всегда помогает?
                    0

                    Риск приемлемый :) кстати, саппорт нам понравился у циски, а вот у делла — нет. На это смотрели, да. В том числе по этой же причине почти сразу отмели Нутаникс.

                      0
                      У Делла да, саппорт «специфический», к сожалению.
                      С Нутаниксом история немного другая — оно живёт, даже в Community edition вполне годно для небольшого продакшена, но всё равно нужны люди «на месте», которые умеют его готовить. Даже если это коммерческая версия.
                      Но комьюнити весьма хорошее
                    0

                    Опеншифт ради чего? Безопасность, поддержка редхата — или какая причина смотреть на него?
                    Или думаете брать бесплатный шифт?

                      0
                      Начинали мы с кубера в чистом виде. Но постоянно натыкались на сырость: как установить, как настроить, как заставить работать… в шифте же все эти проблемы решены, там все, что нам надо есть из коробки. Т.е. сэкономили время на старте. Пока используем бесплатную версию.
                        +2

                        К сожалению, не могу согласиться. Мы с коллегами из того же Фланта обсуждали перспективы Шифта… И они топят все-таки за ваниль. Шифт очень opinionated. Хотя в нем и многие проблемы решены, но шифт не гибок.
                        Касательно того, с чем столкнетесь с шифтом:


                        1. в него прекрасно заезжают ваши самописные сервисы (в общем-то он для этого и предназначен)
                        2. засунуть в шифт что-то, что для него не предназначено — это отдельный секс. Любой гитлаб, постгрес, редис и пр. из официальных хельмов и докерхабов нужно умудриться поставить
                        3. опеншифт очень платен, как вы будете его масштабировать — я вообще не представляю. А бесплатный… Ну, такое себе.
                        4. ограниченный набор плагинов — из кубернетеса Вы действительно можете слепить что угодно (это же и проблема на самом деле). Опеншифт — это коробка. Т.е. Вы получаете ровно тот функционал, который там есть. Отклонения в сторону… ну, либо снимут с поддержки, либо будет отдельная боль с интеграцией доп модулей.
                        5. отсутствие понимание как опеншифт будет развиваться. Уже были примеры, когда функционал появлялся в шифте, потом в кубернетесе, но другой. Например, в шифте были Route, в куб затащили Ingress. В результате, в шифте все равно придется переезжать на Ингресс. С сетевыми политиками та же история.

                        Если уж Вы строите из себя энтерпрайз, то лучше посмотрите в сторону Vmware и Vmware Tanzu (у них свой менеджед кубер есть по сути в Вашем контуре) :-)


                        И прочее-прочее-прочее.

                          +1
                          Мы на протяжении 2 лет успешно эксплуатируем бесплатный openshift командой из 4 человек, которые занимаются и разворачиванием кластеров, и разработкой нового функционала на основе шифта под нужды наших продуктовых команд. Последний год все наши новые продукты и сервисы запускаются в шифте. По опыту наши потребности он не ограничивает, а пользу приносит. Разработку своих операторов и CRD шифт никак не ограничивает, а нам нужна гибкость в первую очередь с точки зрения автоматизаций процессов. Про существование VMware Tanzu мы конечно знаем, мы как раз строим из себя ентерпрайз, умеющий считать деньги. Решения vmware бюджетными традиционно не бывают — это комбайны с кучей функционала, часто нами не востребованным. Нам эффективнее использовать бесплатные версии продуктов и небольшую команду экспертов, которая адаптирует их под наши потребности.
                  0
                  И кстати, почему именно тёмная оптика, а не провайдерские VPN? задержка при размещении в пределах Мск не сильно вырастет, а надёжность и гибкость сильно выше
                    0

                    Во-первых, нужны гарантии по задержкам сети, что с публичными сетями бывает проблемой. А во-вторых, и это важнее, оптика дешевле выходит. У нас в одной из локаций был резерв по VPN (делали временно, пока второе плечо оптики вводили). Так вот в момент той самой аварии из статьи, когда в одном колодце пожар, а во втором «какой интересный коннектор», этот гигабитный канал не вытянул. По факту у нас 3-4 Гбит/с между локациями ходит. А такие аплинки дороже оптики получаются.

                      0
                      Странно, конечно — обычно overlay каналы получаются дешевле (и уж точно гибче в эксплуатации). С другой стороны — если расстояния небольшие, и брать не волокно, а лямбду в нём, то получается не так дорого, согласен.
                0

                В сторону облачных контор а-ля AWS не смотрели из-за ФЗ, или какая-то своя причина была?


                Яндекс.Облако также не рассматривали из-за финансовой невыгодности? И, на самом деле, была бы интересна арифметика — "на колокейшене со своим железом тратим столько-то, в облаке бы тратили вот столько-то", например.


                Ещё любопытно почему на одном кластере есть мастер, на другом слейв, а на третьем нету ничего, но на всех есть приложение. Групповая репликация с хранением копии под каждой репликой приложения также не могла быть применена по каким-то причинам?

                  +2
                  1. У нас было несколько экспериментов с AWS и Google Cloud — мы там брали PaaS решения для быстрых тестов. Но в массовое решение не пошло. В качестве IaaS не рассматриваем из-за наших требований к связности локаций. ФЗ-152 тут играет малую роль, поскольку он только про персональные данные. А кроме них есть еще очень много элементов системы.

                  2. К моменту появления Я.Облака у нас уже было два провайдера облаков, третий не нужен. Тратить ресурсы на «давайте еще попробуем вот это», когда с действующими поставщиками все нормально, нецелесообразно. Наш проект на своем HCI окупается примерно за год. Я считал NPV на 4 года, сравнивая одинаковые объемы ресурсов в облаке и у себя. Кстати, сейчас мы работаем над проектом OpenShift on Bare Metal: идея в том, чтобы развернуть OpenShift на самом обычном железе, а не на HCI или облаках. Просчитываем варианты, если получится, поделюсь.

                  3. Тут скорее вопрос целесообразности и экономики. Можно поднять и три, и четыре копии (на некоторых особо критически важных базах так и делаем). Все-таки вероятность одновременного отказа двух сильно ниже, а деньги на инфраструктуру надо выделять. Изначально так и хотели делать (по копии в каждой локации), однако известные события весны этого года скорректировали аппетиты :)
                  0
                  В частности, производительность по факту не такая прикольная как в презентациях из-за оверхеда.

                  Можете прояснить, что не так с производительностью Делла? Это какая-то доступная информация или ваши наблюдения?
                    0
                    Мы проводили тесты, сравнивали. Конкретно здесь у нас такой опыт был (цитата из отчета наших инженеров): «Сетевая инфраструктура не утилизирует пропускную способность сети серверов, используя режимы active-backup, в связи с чем страдает как скорость подключения серверов, так и надежность.»
                    Наверняка есть способы это побороть, но мы искали решение, которое требует меньше танцев с бубном. Кроме того, мы остались не очень довольны уровнем технической поддержки Dell, а это тоже очень важно, когда покупаешь очень дорогое оборудование.
                    0
                    Не совсем понял, в том, что планируете в итоге, пришли к полностью своей инфраструктуре в трех ЦОДах, или всё-таки часть переменной пиковой нагрузки планируется обеспечивать облаками?
                      0
                      Гибридное решение в итоге. Не отказываемся от облаков

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

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