Теперь вот длинный ответ

travaux.ovh.net/?do=details&id=28247

Сегодня утром в 7:23 утра у нас был большой перерыв на нашем сайте в Страсбурге (SBG): перерыв в электроснабжении, который оставил три датацентра без электроэнергии в течение 3,5 часов. SBG1, SBG2 и SBG4. Вероятно, это самый худший сценарий, который мог произойти с нами.

Участок SBG питается от линии электропередачи 20 кВА, состоящей из 2 кабелей, каждая из которых обеспечивает 10MVA. 2 кабеля работают вместе и подключены к одному и тому же источнику и к тому же автоматическому выключателю в ELD (Strasbourg Electricity Networks). Сегодня утром один из двух кабелей был поврежден, и автоматический выключатель отключил питание от центра обработки данных.

Сайт SBG предназначен для работы без ограничений по времени на генераторах. Для SBG1 и SBG4 мы создали первую резервную систему из 2 генераторов по 2MVA каждый, сконфигурированных в N + 1 и 20kv. Для SBG2 мы создали 3 группы в конфигурации N + 1 1,4 МВА каждый. В случае сбоя внешнего источника питания высоковольтные ячейки автоматически перенастраиваются с помощью моторной отказоустойчивой системы. Менее чем за 30 секунд дата-центры SBG1, SBG2 и SBG4 могут восстановить мощность с 20 кВА. Чтобы сделать это переключение без отключения питания серверов, у нас есть источники бесперебойного питания (ИБП), которые могут поддерживать питание до 8 минут.

Сегодня утром моторная отказоустойчивая система работала не так, как ожидалось. Команда запуска генераторов резервного копирования не была предоставлена ​​NSM. Это NSM (двигатель с нормальной аварийной ситуацией), предоставляемый поставщиком высоковольтных ячеек 20 кВ. Мы контактируем с производителем / супером, чтобы понять происхождение этой проблемы. Тем не менее, это дефект, который должен был быть обнаружен во время периодических испытаний на неисправность внешнего источника. Последний тест SBG для восстановления резервных копий был в конце мая 2017 года. Во время этого последнего теста мы приводили SBG только из генераторов в течение 8 часов без каких-либо проблем, и каждый месяц мы тестируем генераторы резервных копий бесплатно. И, несмотря на все это, этой системы было недостаточно, чтобы избежать сегодняшнего юрта.

Примерно в 10 часов нам удалось переключить ячейки вручную и снова начать работу центра обработки данных с генераторами. Мы попросили ELD отсоединить неисправный кабель от высоковольтных ячеек и снова включить автоматический выключатель только с одним из двух кабелей и, следовательно, были ограничены 10MVA. Это действие было выполнено ELD, и мощность была восстановлена ​​примерно в 10:30. Маршрутизаторы SBG были подключены к сети с 10:58 утра.

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

В 7:50 мы создали кризисную единицу в RBX, где мы централизовали информацию и действия всех вовлеченных команд. Грузовик из RBX был загружен запасными частями для SBG. Он прибыл в пункт назначения около 17:30. Чтобы помочь нашим местным командам, мы отправили команды из центра данных LIM, расположенного в Германии, и персонала из центра обработки данных RBX, все из которых были мобилизованы на месте с 16:00. В настоящее время более 50 техников работают в SBG, чтобы вернуть все услуги в Интернете. Мы готовим работу ночью и, если необходимо, завтра утром.

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

Так почему же этот провал? Почему SBG не выдержала простой сбой питания? Почему весь интеллект, который мы развили в OVH, не смог предотвратить эту катастрофу?

Быстрый ответ: энергосистема SBG унаследовала все недостатки дизайна, которые были результатом небольших амбиций, которые первоначально ожидались для этого местоположения.

Теперь вот длинный ответ:
Еще в 2011 году мы планировали развертывание новых центров обработки данных в Европе. Чтобы проверить аппетит для каждого рынка, с новыми городами и новыми странами, мы изобрели новую технологию развертывания центров обработки данных. С помощью этой внутренней технологии мы надеялись получить гибкость при развертывании центра обработки данных без ограничений времени, связанных с разрешениями на строительство. Первоначально мы хотели получить возможность подтвердить наши гипотезы, прежде чем делать значительные инвестиции в определенном месте.

Таким образом, в начале 2012 года мы запустили дата-центр SBG1 из морских контейнеров. Мы развернули 8 грузовых контейнеров, и SBG1 работает менее чем за 2 месяца. Благодаря этому сверхбыстрому развертыванию, которое заняло менее 6 месяцев, мы смогли подтвердить, что SBG действительно является стратегическим местом для OVH. К концу 2012 года мы решили построить SBG2, а в 2016 году мы начали строительство SBG3. Эти 2 датацентра не были построены из контейнеров, но были основаны на нашей технологии «Башня». Строительство SBG2 заняло 9 месяцев, и SBG3 будет запущен в производство в течение месяца. Чтобы решить проблему пространства, в начале 2013 года мы быстро построили SBG4, основываясь на разговорах о транспортировочных контейнерах.

Проблема заключалась в том, что, развертывая SBG1 с технологией, основанной на транспортных контейнерах, мы не смогли подготовить сайт для крупномасштабного проекта.

Мы допустили две ошибки:
  1. Мы не сделали сайт SBG совместимым с внутренними стандартами, для которых требуется 2 отдельных электропитания 20 кВ, как и все наши места постоянного тока, которые оснащены двумя электрическими каналами. Это крупные инвестиции в размере от 2 до 3 миллионов евро за электрическую подачу, но мы считаем, что это часть нашего внутреннего стандарта.
  2. Мы построили энергосистему SBG2, поместив ее в энергосистему SBG1 вместо того, чтобы сделать их независимыми друг от друга, как и во всех наших центрах обработки данных. В OVH каждый номер центра данных указывает, что силовая сеть не зависит от других датацентров. Где угодно, кроме сайта SBG.

Технология, основанная на транспортных контейнерах, использовалась только для сборки SBG1 и SBG4. На самом деле мы поняли, что контейнерный центр обработки данных не соответствует требованиям нашей торговли. На основе темпов роста SBG минимальный размер сайта должен быть равен нескольким центрам обработки данных и, следовательно, иметь общую емкость 200 000 серверов. Вот почему сегодня для развертывания нового датацентра мы используем только два типа конструкций, которые были широко протестированы и спланированы для крупномасштабных проектов и надежности:
  1. строительство 5-6-этажных башен (RBX4, SBG2-3, BHS1-2) для 40 000 серверов.
  2. приобретение зданий (RBX1-3,5-7, P19, GRA1-2, LIM1, ERI1, WAW1, BHS3-7, VIH1, HIL1) для 40 000 или 80 000 серверов.

Даже если этот утренний инцидент был вызван сторонним автоматом, мы не можем отрицать свою ответственность за провал. У нас есть кое-что, что нужно сделать для SBG, чтобы достичь того же уровня стандартов, что и другие OVH-сайты.

В течение дня мы приняли следующий план действий:
  • установка второго, полностью отдельного электрического питания 20MVA;
  • разделение силовой сети SBG2 от SBG1 / SBG4, а также отделение будущего SBG3 от SBG2 и SBG1 / SBG4;
  • миграция клиентов SBG1 / SBG4 в SBG3;
  • закрытие SBG1 / SBG4 и удаление транспортных контейнеров.

Это инвестиционный план в размере 4-5 миллионов евро, который мы запускаем завтра, и надеемся, что мы сможем восстановить доверие наших клиентов к SBG и OVH.

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

Мы очень сожалеем об этом инциденте, и мы благодарим доверие, которое вы оказываете нам.

Держите свои данные в безопасности вместе с MskHost!

Держите свои данные в безопасности вместе с MskHost: автоматические бекапы уже доступны!

Уважаемые клиенты, рады сообщить, что для всех тарифов VPS в Москве теперь добавлена возможность подключить автоматические бекапы. Подключение услуги полностью автоматизировано, далее от Вас не требуется никаких действий. Резервная копия Ваших данных будет выполняться автоматически в выбранное время. При необходимости, Вы сможете восстановиться из резервной копии в один клик!

Обезопасьте свои данные уже сейчас: my.msk.host


Перенесем баланс от другого хостинг-провайдера



Перенесем баланс с другого хостинга к нам!

Если у Вас есть баланс на личном кабинете у другого хостинг-провайдера и Вы давно хотели его сменить, это стало значительно проще. Теперь MskHost перенесет Ваш баланс в полной мере в наш личный кабинет, который Вы сможете потратить на любые выбранные Вами услуги, без подводных камней и ограничений.

Для переноса баланса достаточно обратиться к нам по любым контактам: в сообщения ВКонтакте, к менеджеру Телеграм или же в службу поддержки в личном кабинете, прикрепив подтверждение наличия баланса у другого хостера, после чего мы начислим аналогичную сумму на Ваш аккаунт в нашем ЛК.

Наш сайт: msk.host/
Личный кабинет: my.msk.host

Зарабатывай вместе с нами


Хочешь зарабатывать с опытной командой SpaceCore? Ты по адресу, ведь у нас есть отличное предложение для тебя. Просто продавай наши услуги и зарабатывай на этом, это проще чем ты думаешь. Мы готовы помочь в установке всего нужного ПО и подробно рассказать вам как все работает!

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

Пиши нам по любым контактам и мы бесплатно проконсультируем каждого!
Email: support@spacecore.pro
Telegram: @spacecore_pro
VK: vk.com/spacecore_pro
Биллинг: billing.spacecore.pro

CLO: удвоим ваш платёж и предоставим сервер на тест



Наш проект облачных серверов CLO продолжает развиваться и расширять функционал. В 2021 году реализованы:
  • разные типы дисков: быстрые локальные и сетевые с использованием Ceph;
  • API для удобной работы и автоматизации задач;
  • управление DNS-записями.

Чтобы вы могли оценить новые возможности, приготовили для вас два предложения.
  • Предоставим сервер на тест. Вы можете выбрать любую конфигурацию и оставить заявку на бесплатный тестовый период на срок до трёх дней, мы свяжемся с вами для согласования.
  • Удвоим сумму платежа. Пополните баланс удобным способом и активируйте промокод DOUBLE — мы зачислим на ваш счет сумму, равную внесённому ранее платежу (но не более 50 000 рублей).


clo.ru/free-test

Как получить х2 к платежу?
  • Войдите в личный кабинет — акция доступна как новым, так и текущим клиентам CLO, без привязки к тестовому периоду.
  • Пополните баланс удобным для вас способом.
  • Активируйте сертификат DOUBLE в разделе «Баланс и расходы», чтобы удвоить внесённый платёж.
  • Готово! Ваш платёж удвоится: на баланс будет зачислена сумма, равная вашему платежу, но не более 50 000 ₽.

Вечные промо-тарифы от 1790р в Нидерландах






Рады сообщить, что начиная с сегодняшнего дня, вы можете приобрести NL-PROMO-1 и NL-PROMO-2 навсегда. Платите один раз — пользуетесь до скончания веков.

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

NL-PROMO-1
1 ядро
1 ГБ ОЗУ
10 ГБ SSD
200 МБит/с
KVM
AntiDDoS
1790р/разово

NL-PROMO-2
2 ядра
2 ГБ ОЗУ
20 ГБ SSD
200 МБит/с
KVM
AntiDDoS
3490р/разово

Заказ можно оформить в личном кабинете: https://my.msk.host

ВМ на базе Ryzen 3800X в Москве от HiP!

Московский датацентр пополняет свой арсенал!
Линейка тарифов «GX» уже доступна для создания ВМ!



Игровые серверы, базы данных, масштабные сайты? Легко!

Производительный процессор AMD Ryzen 3800X с частотой до 4.5GHz, надёжные NVMe накопители Samsung PRO с повышенным ресурсом записи, оперативная память HyperX с частотой 3200MHz обеспечат высокую скорость работы в Ваших задачах!

Все виртуальные серверы, создаваемые в датацентре «Москва», находятся под постоянной защитой от атак, благодаря компании DDoS-Guard.

✅ На тарифы GX7 распространяется постоянная скидка до вечера субботы (12 сентября).

Успей заказать сервер со скидкой, установка занимает считанные секунды!

Заказать ВМ на базе процессора Ryzen 3800X: my.hip-hosting.com/vm/new?range=6

Появился вопрос? Мы всегда готовы ответить! vk.me/hiphosting

Чисто русский переезд в другой дата-центр




У нас на неделе был эпический переезд из Ростелекома в IXcellerate. Кажется, мы обязаны про это рассказать.

Потому что случился просто весь сок того, как работает отечественный рынок:
  • Те, кто ждал подъёма своего облака всё это время — вы ждали СДЭКа, который вёз два патч-корда «день в день».
  • У нас глючили сетевые железки, и мы не знали, в чём дело. Две недели поиска бага закончились тем, что мы перевезли их в другой дата-центр, и там глюк прошёл полностью.
  • Нельзя зайти в ЦОД Ростелекома 21 человеку, потому что 1 человек оформляется охраной 5 минут с записями в бумажный журнал, а через час они просят пересоздать заявку.
  • Если у вас в команде есть белорусы и казах, то их будут проверять 3 дня, прежде чем пустить на стратегический объект, потому что таков SLA безопасников по обмену данными. Но если у вас есть сириец, его пустят сразу (вероятно, потому что обмен данными не налажен).
  • И да, после переезда мы наконец-то обновили бесплатные лимиты, теперь даже не надо пополнять счёт, чтобы их получить.


Бета облака
Мы строим последнее коммерческое облако в России. Есть масштабная бета, в бете много халявных ресурсов, но надо помнить, что, несмотря на 5 автономных зон, геораспределённое хранилище, другие плюшки, в любой момент всё может пойти по звезде. Потому что мы решили поправить какой-то баг на проде (на самом деле нет).

Нашу бету уже ломали коллеги (спасибо большое), ломали тестеры (спасибо большое), нам показывали на проблемы с UI, была куча пожеланий — в общем, постоянно идут работы.

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

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

Массово посыпались проблемы на бете
То на ровном месте начинали флапать внутренние BGP-сессии с хостов до ToR-коммутаторов. То внезапно отваливалась наша гиперконвергентная дисковая подсистема — поды начинали мигрировать, отваливаться, а хосты «затенялись» (становились tainted) и переставали принимать новые нагрузки. Всё упиралось в один маршрутизатор ядра. Производительность у него была неплохой, оверхед маленький, но стабильность исчезла.

Мы привезли новые железки, и они стали показывать примерно 40–50% от номинальной производительности по пропускаемому трафику. Представьте: у вас 25-гигабитный линк, а он выкачивает от силы треть.

Почему? Расследование в моменте, когда всё вокруг горит, не дало результатов, но копались мы пару недель. В итоге подъехали 100-гигабитные карточки и мы решили не тратить время и просто пересобрать всё на них.

Дальше можно было долго и упорно ловить баги, чинить разваливающуюся сеть и пытаться понять, почему железо не работает. А можно было признать очевидное — архитектура, созданная для демо, исчерпала себя.

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

Как потом оказалось, на новом месте железки заработали, и от шутки про то, что «я же тебе говорил, место проклятое!», мы удержаться не смогли.

Как переезжать? Был вариант с плавным переносом серверов, частичными переездами, попыткой обеспечить совместимость двух несовместимых кластеров. Это долго, мучительно и чревато новыми, ещё более изощрёнными проблемами.

Если вы любите приключения, рекомендую такой путь.

Но поскольку это бета, а в бете, как известно betta than nothing, мы выбрали путь Безумного Макса и Дороги ярости. Полностью всё вырубить, физически перевезти и собрать с нуля в новом стеке и новом ЦОДе. Да, это означало простой около 2 дней для пользователей беты (как нам казалось вначале). Но так было быстрее и, как оказалось, веселее.

Мы объявили, что берём тайм-аут, и дальше затеяли масштабный тимбилдинг: почти весь офис, включая фаундеров, отправился в Ростелеком паковать серверы.


Место проклятое!
Шаг 1: подаём заявку на проход 21 человека за сутки. Мы такие заявки (правда, на меньшее количество людей) подавали полтора года по одной и той же форме. Перезванивают их сотрудники и говорят:
— Надо заявку переделать!
— А почему?
— Вам надо по-другому название ЦОДа написать, не Nord, а «РТК-Медведково-1», потому что Nord — это слишком прозападно.

Ладно, поменяли. Последний раз же.

Потом за пару часов до времени заезда коллеги внезапно выясняют, что у нас в штате работают белорусы и пара человек из Казахстана. Им вход блокируют.

— Я сотрудник физической безопасности, мне надо на то, чтобы проверить человека из Беларуси, три дня. У вас их тут двое. Ещё из Казахстана двое. Короче, идите на хер, пересоздайте заявку без них.

Интересно, что у нас есть сириец, который такие проверки не триггерил ни в одной заявке.

Ладно, пересоздались без них. Последний раз же.

Наученные прошлым опытом, печатаем серийники для заявки на выезд.

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

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

— Заявка закрылась, мы не можем запускать новых людей. Пересоздайте, пожалуйста, заявку на вход!

Ладно, пересоздали. Последний раз же.

Около 14 звонит газель, которая должна была всё это вывозить. Она, как это принято, внезапно ломается. Мы срочно ищем другую. Пересоздаём заявку. Последний раз же.

Дальше выезд из Ростелекома. Это ещё хуже, чем вход новых, ни разу не посещавших людей. На каждый сервак сверяется серийник. И благо, они ушли от той идеи, что мы в заявке должны указывать ещё внутренний учётный номер. Раньше было так: при ввозе они клеили наклейку с номером и в заявку надо было вбивать и его, и серийник железки. Мы с первого же раза сказали, что этой хернёй заниматься не будем, и ни разу её не вбивали. Поэтому все наши заявки проходили прекрасно по серийникам серверов.





Патч-корды — оказывается, это проблема
Заезд в IXcellerate как небо и земля. Мы приехали чуть раньше, чем грузовик, успели выпить кофе и посидеть. Заявка делается просто по списку людей, документы проверяют на входе, без всяких журнальчиков (всё электронное). Проход занял по 20 секунд на человека.

Примерно за 3 часа всё смонтировали — быстрее, чем разбирали в РТК, потому что белорусов пустили.


Но! Для того чтобы в IXcellerate связать наш meet-me-room с новой инсталляцией (она у нас идёт как отдельный контур), понадобилась парочка отдельных патч-кордов. Трассы проложены, кроссы разварены, трансиверы есть. И вот нам, значит, нужен обычный патч-корд, FC — LC-дуплекс.

Заказываем его 30-го, в среду.

На «Всех инструментах» патч-корды были, на них было написано «доставка 1 день», но при добавлении в корзину дата доставки превращалась в 5 августа.

Нашли на Nag.ru. Они такие — «сейчас привезём!» Оплачиваем супернаценку за доставку СДЭКом. Это, кстати, в два раза дороже, чем сами патч-корды, чтобы доставить день в день.

И СДЭК их морозит на хрен.


Прикол в том, что у нас собрано уже всё. Контур заведён, уже всё крутится. Связать его с ядром сети — два, два маленьких патч-корда, и их не хватает!

То есть все, кто ждали нашего облака, имейте в виду, вы ждали два патч-корда, которые мы заказали в трёх разных местах. Мы с коллегами из ЮЛ-Ком уже шутили на предмет купить аппарат для сварки этих патч-кордов и варить их самим. Оказалось, это стандарт рынка. Это боль. Оказалось, что у многих это блокер включения нового клиента. Потому что две недели ждать патч-корды! Что происходит, почему в Москве их дефицит, я не знаю.

СДЭК привёз заказ день в день через 6 дней.


Изменения в архитектуре демоинсталляции
Была архитектура, растянутая на VLAN’ах. Пять физически изолированных сетей (для управления, хранения, публичного трафика и т.д.), которые всё равно терминировались как разные VLAN на одном маршрутизаторе. Мы жили даже в продакшене с MTU 1500 (!), что создавало проблемы для оверлейных сетей и производительности. И не спрашивайте, почему мы не пробовали его увеличить — мы пробовали, но пришлось откатиться. Это мешало построить полноценную оверлейную сеть Kube-OVN и изолировать теннаты друг от друга.

Сейчас полностью перешли на микросервисную архитектуру, выпилив все рудименты. Сеть теперь построена на EVPN VXLAN с физической топологией Dragonfly+. На уровне отдельной группы стоек — Clos (Node, Leaf, Spine), между Спайнами — full-mesh. Там тоже не без сюрпризов, про то, какие грабли поймали, напишем отдельно.

Выкатили API напрямую. Здесь мы вдохновлялись подходом AWS, которые через свой IAM прокачивают до миллиарда запросов. Наш API станет точкой входа для веб-интерфейса, CLI и внешних инструментов типа Terraform’а. То, что вы просили с беты, тоже запустим. Теперь эти доработки делаются ещё быстрее. Будут VPC для объединения машин в разных зонах доступности, Managed Kubernetes, управление DNS-зонами, очереди сообщений (Kafka, RabbitMQ, NATS).



Про бесплатный доступ
Для юрлиц сделали ролевую модель доступа (RBAC) для создания и управления пользователями с разными правами. Корпораты, добро пожаловать! При регистрации юрлица сразу даём 50 тысяч бонусов на 3 месяца.

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

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

h3llo.cloud/ru