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




У нас на неделе был эпический переезд из Ростелекома в 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

Прокачали тарифы «Форсаж» и «Атлант»



Наши тарифы «Форсаж» (в Москве и Амстердаме, c NVMe) и «Атлант» (в Москве) стали еще производительнее. Теперь серверы будут открываться не только на AMD EPYC 9654, но и на новом серверном процессоре AMD EPYC 9655.

AMD EPYC 9655 – мощный серверный процессор с 96 ядрами на архитектуре Zen 5, обеспечивает до 25% прироста производительности по сравнению с предыдущим поколением и отлично подходит для ресурсоемких задач. Подробные характеристики процессора здесь.

firstvds.ru/products/vds_vps_cloud

В течение месяца все новые заказы будут запускаться на EPYC 9655. В дальнейшем процессоры будут распределяться в произвольном порядке, так что не упустите момент!

Австралия — новое место для ваших проектов



THE.Hosting расширяет свою глобальную инфраструктуру — Австралия становится нашей новой точкой присутствия. Открыт предзаказ на виртуальные серверы со скоростью портов до 10 Гбит/с, размещаемые в дата-центре на континенте.

Австралия — это не только стратегически важный регион с высокими стандартами интернет-услуг, но и возможность масштабировать ваши проекты с минимальной задержкой для пользователей в Океании и Юго-Восточной Азии.



Специальное предложение
До 15 августа 2025 года, 23:59 (UTC+3), вы можете получить скидку 50% при оформлении предзаказа. Просто введите промокод AUSTRALIA50 в корзине под суммой заказа.

Все предварительно заказанные серверы будут активированы сразу после окончания 96-часового отсчета.
Скидка действительна только до указанной даты — после этого промокод аннулируется.
Начните расширять свою ИТ-инфраструктуру с надежным партнером — THE.Hosting.

https://the.hosting

Продуктовый дайджест ISPsystem


Поддержка технологии vGPU
Мы добавили возможность подключать из интерфейса платформы графические ускорители в режиме vGPU. Данная технология позволяет разделять физический графический процессор (GPU) на несколько виртуальных, каждый из которых может быть выделен отдельной виртуальной машине. Так, один физический GPU может обслуживать несколько пользователей или задач. Технология vGPU применяется в таких сценариях, как VDI, машинное обучение, искусственный интеллект, рендеринг, гейминг и стриминг.
www.ispsystem.com/docs/vmmanager-admin/clusters/using-vgpu



Отображение статистики в ЛК клиента
Мы переработали интерфейс работы со статистикой в ЛК клиента. Теперь пользователям доступно 2 режима работы:
  • Потребление по дням – режим сохранил все предыдущие возможности; в него не вносились доработки.
  • Перерасход по месяцам – новый режим позволяет просматривать данные ретроспективно за выбранный отчетный период для каждого аддона по статистике в услуге. При этом на графике добавлено пороговое значение, а также блоки слева, отображающие информацию по аддону (лимит, потребление, превышение). Справа добавлена сводная информация, отображающая стоимость перерасхода в периоде.

Кроме этого, мы добавили в ЛК клиента и ЛК администратора новый раздел “Ресурсы по статистике”. В ЛК клиента раздел отображает список услуг с дополнениями по статистике и их состоянию (нормальное состояние, приближение к перерасходу, перерасход), а также дополнения в текущем периоде. В ЛК администратора в данный раздел попадают услуги при приближении к перерасходу и при перерасходе – для аналитики со стороны администратора.

Улучшение поведения зависимостей в тарифах
Мы улучшили возможности настройки поведения списков значений на странице заказа услуги. Теперь при выборе опции в Глобальных настройках «не отображать недоступные для заказа значения» недоступные значения не будут видны. В случае выбора опции «отображать недоступные для заказа значения» (выбрана по умолчанию) недоступные значения подсвечиваются красным.

Изменения могут вас коснуться — проверьте контакты вашего домена

Благодарим вас за вашу постоянную поддержку name.com. Мы хотим сообщить вам о важном изменении правил регистрации доменов ICANN, которое может повлиять на данные о владельце вашего домена.

В феврале 2024 года ICANN представила новую Политику регистрационных данных, которая изменяет порядок обработки контактных данных и прав собственности на домены, особенно для доменов без кода страны (не ccTLD).

Что такое ccTLD?
Что меняется?

Начиная с 21 августа 2025 года новая Политика ICANN в отношении регистрационных данных меняет порядок определения права собственности на домен.

В настоящее время: имя и фамилия регистранта определяют право собственности на домен.
  • С 21 августа 2025 года: если поле «Организация» в контактной информации регистранта заполнено, эта организация будет считаться законным владельцем домена. Имя и фамилия будут считаться контактной информацией, а не владельцем.
  • Дальнейшие действия: Если вы не хотите, чтобы организация считалась владельцем домена, войдите в свою учетную запись name.com или обратитесь к своему провайдеру домена, чтобы обновить контактную информацию о домене.
  • Дальнейшие действия: Если вы не хотите, чтобы организация считалась владельцем домена, войдите в свою учетную запись name.com или обратитесь к своему провайдеру домена, чтобы обновить контактную информацию о домене.
  • Если вы не знаете, как обновить свою учетную запись или доменное имя в учетной записи name.com, ознакомьтесь со следующими статьями поддержки: Обновление учетной записи или Обновление домена.

Изменения в типах контактов домена
В этой политике также обновляется порядок обработки типов контактов доменов и требования реестров:
В настоящее время для доменов отображаются 4 типа контактов: регистрант, администратор, технический специалист и ответственный за выставление счетов.
Будут собираться и храниться только необходимые контактные данные, определенные реестром домена верхнего уровня (обычно это только регистрант).
Любая неиспользованная контактная информация будет удалена из нашей системы.
Конфиденциальность домена
Как всегда, если вы предпочитаете, чтобы ваши контактные данные не были публично видны в службах каталогов регистрационных данных (WHOIS/RDAP), мы рекомендуем включить расширенную безопасность для вашего домена.

Давайте убедимся, что все в порядке
  • Мы рекомендуем вам проверить контактную информацию вашего домена уже сейчас, чтобы убедиться в ее точности, прежде чем политика вступит в силу 21 августа 2025 года.
  • Проверьте и обновите контактную информацию вашего регистранта.
  • Проверьте поле «Организация» — если оно неверно или не нужно, удалите его.
Это обновление распространяется на всех регистраторов, аккредитованных ICANN, и является частью более широкого изменения политики в масштабах всей отрасли.

Специальные предложения августа - мощные выделенные серверы в Нидерландах!



Август — месяц низких цен на по-настоящему мощное железо. Мы собрали список лучших предложений выделенных серверов в Нидерландах, которые отлично подходят под задачи, требующие высокой скорости и производительности. Все они по самым выгодным ценам!

Ловите момент — акция действует только до конца августа! Выберите подходящую конфигурацию под амбиции вашего проекта:

2x Xeon E5-2620v4 Promo
16 ядер, 32 потока (до 3.00 GHz)
64 GB RAM и 2 x 960 GB Enterprise SSD
Канал 1 Gbit/s (100 TB трафика)
Начальная конфигурация в нашей подборке, но достаточно мощная для того, чтобы закрыть потребности многих web-приложений и не только.
Заказать за 74 EUR в месяц!

AMD EPYC 7402P Promo
24 ядра, 48 потоков (до 3,35 GHz)
64 GB RAM и Hardware RAID 1 (480 GB Enterprise SSD x 2)
Канал 1 Gbit/s (100 TB трафика)
Конфигурация полюбившаяся многим клиентам. Мощный процессор, производительные Enterprise SSD в зеркальном Hardware RAID массиве. Надёжный и быстрый сервер подходящий для любого проекта.
Заказать за 108 EUR в месяц прямо сейчас!

AMD EPYC 7402P Promo 128 GB
24 ядра, 48 потоков (до 3,35 GHz)
128 GB RAM и Hardware RAID 1 (960 GB Enterprise SSD x 2)
Канал 1 Gbit/s (100 TB трафика)
Аналогичная конфигурация, но с ещё большим количеством ресурсов, для ещё более требовательных задач.
Заказать за 146 EUR в месяц!

2x Xeon Gold 6230R Promo
52 ядра, 104 потока (до 4.00 GHz)
128 GB RAM и 2 x 960 GB Enterprise NVMe SSD
Канал 1 Gbit/s (100 TB трафика)
Более 100 вычислительных потоков вкупе с высокопроизводительными NVMe дисками — настоящая мощность, подходящая для high-load проектов, виртуализации, сложного машинного обучения.
Супер-цена: 297 EUR в месяц!

В погоне за высокой производительностью не забываем и о базовых вещах. Конфигурация, позволяющая организовать собственный сервер резервного копирования, файлообменник, не требовательный проект и не только:
Xeon E3-1230v6 Promo
4 ядра, 8 потоков (до 3.90 GHz)
16 GB RAM и 1 TB HDD
Канал 1 Gbit/s (50 TB трафика)
Всего 34 EUR в месяц!

Преимущества выделенных серверов в Нидерландах от EuroHoster:
  • Дата-центр с низкой латентностью по Европе;
  • Базовая защита от DDoS-атак до 40 Gbit/s;
  • Полный root-доступ, DNS, возможность заказа мониторинга;
  • Скидки до -15% при оплате на 3-12 месяцев вперёд.

Акция действует до конца августа! Напиши нам прямо сейчас и уже завтра ты можешь получить свой новый мощный выделенный сервер!
Большинство выделенных серверов выдаются в течении 24 часов с момента заказа в будние дни.

Важные изменения в коммуникации – подключайте Telegram!



Мы заметили, что SMS-сообщения часто не доходят из-за технических особенностей операторов связи. Чтобы вы всегда оставались на связи и получали важные уведомления вовремя, рекомендуем подключить Telegram.

Почему Telegram?
  • Надежная доставка сообщений;
  • Мгновенные уведомления;
  • Никакой рекламы и спама!

Как подключиться?
Также рекомендуем выключить 2ФА по SMS и настроить TOTP аутентификацию.

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

Citytelecom и Datahouse подверглись хакерской атаке



11 августа оператор связи Citytelecom и сеть дата-центров Datahouse (входят в периметр ГК ФИЛАНКО) подверглись скоординированной хакерской атаке, направленной на ядро сетевой инфраструктуры компаний.

Атака началась в ночь на 11 августа, ориентировочно в 01:00 по московскому времени. Дежурные службы Citytelecom автоматически зафиксировали сбой в работе сети, инженеры оперативно приступили к диагностике. В результате кибератаки была повреждена конфигурация главного магистрального маршрутизатора сети передачи данных. Для выяснения причин команда действовала поэтапно, проверяя каждый сегмент сети. По мере восстановления контроля была выявлена сохранность ключевых данных и критически важных серверов. Первичный анализ характера атаки исключил использование DDoS-технологий.

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

«Инженерные ИТ-подразделения любой компании постоянно готовятся к возможным атакам, совершенствуя свои системы защиты. К сожалению, злоумышленникам иногда удается добиться сбоев в системах. Что касается произошедшего инцидента, тщательная предварительная подготовка, наличие резервных копий, а также сегментированная система защиты позволила нашей команде оперативно локализовать проблему и восстановить большую часть инфраструктуры. Особую благодарность хотим выразить коллегам из отраслевого сообщества, которые предложили свою помощь и экспертизу для ликвидации последствий хакерского воздействия», — Алексей Солдатов, генеральный директор ГК Филанко.

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

Кибератака не затронула инфраструктуру ЦОД. Компания подтверждает, что данные клиентов, хранящиеся в ЦОД, находятся в безопасности и не попали к третьим лицам.

Разработка многопользовательской платформы GKE для миграции Yahoo Mail



Yahoo находится в самом разгаре многолетнего процесса миграции своего знаменитого приложения Yahoo Mail в Google Cloud. В приложении задействовано более 100 сервисов и компонентов промежуточного ПО, поэтому Yahoo Mail в первую очередь использует подход «переноса и переноса» для своей локальной инфраструктуры, стратегически трансформируя и перенастраивая ключевые компоненты и промежуточное ПО для использования возможностей облачной инфраструктуры.

Чтобы обеспечить успешную миграцию, команды Google и Yahoo Mail активно сотрудничали, собирая информацию о текущей архитектуре и принимая решения относительно границ проекта, сетевой архитектуры и настройки кластеров Google Kubernetes Engine (GKE). Эти решения были критически важны ввиду глобального характера приложения, которое должно быть высокодоступным и избыточным для обеспечения бесперебойной работы пользователей по всему миру.

По мере того, как Yahoo Mail продвигается к миграции первой волны рабочих нагрузок в производственную среду, мы выделяем ключевые элементы архитектуры, в частности, многопользовательскую платформу GKE, которая сыграла ключевую роль в создании прочной основы для миграции. Благодаря многопользовательской поддержке приложение Yahoo Mail может эффективно работать в Google Cloud, помогая удовлетворять разнообразные требования различных арендаторов приложений.

Процесс проектирования
Организация Google по предоставлению профессиональных услуг (PSO) начала процесс проектирования с детального анализа текущего использования системы и требований к емкости. Это включало проведение бенчмарков, сбор исходных данных о существующих рабочих нагрузках и оценку необходимого количества узлов на основе типов машин, которые наилучшим образом соответствовали бы требованиям к производительности и ресурсам для этих рабочих нагрузок. Одновременно мы обсуждали оптимальное количество кластеров GKE и их типы, а также наилучшее размещение и организацию рабочих нагрузок в кластерах. Другим аспектом процесса проектирования было определение количества сред (помимо производственной среды). Мы стремились найти баланс между сложностью эксплуатации, ростом зависимости от локальных сервисов при развёртывании и снижением потенциальных рисков, связанных с дефектами и ошибками приложений.

Но прежде чем принимать решения о кластерах GKE, нам необходимо было определить количество проектов и VPC. На эти решения влияли различные факторы, включая требования заказчика к рабочей нагрузке и масштабируемости, а также ограничения сервисов и квот Google Cloud. В то же время мы хотели минимизировать эксплуатационные расходы. Анализ количества кластеров GKE, VPC и т.д. был довольно простым: достаточно было задокументировать плюсы и минусы каждого подхода. Тем не менее, мы тщательно следовали обширному процессу, учитывая значительное и далеко идущее влияние этих решений на общую архитектуру.

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

Архитектурная схема
Ниже представлено упрощенное представление текущей архитектуры. Основная архитектура состоит из четырёх кластеров GKE на каждую группу регионов (например, в регионах «Восток США» — один VPC) и на каждую среду. Архитектура охватывает несколько регионов, обеспечивая отказоустойчивость и высокую доступность на уровне сервисов. Существует четыре группы регионов, и, следовательно, четыре VPC. Внешний пользовательский трафик направляется в ближайший регион с помощью политики геолокации, настроенной в публичных зонах Cloud DNS. Внутри трафик маршрутизируется между группами регионов через прокси-приложение, а трафик между кластерами GKE — через внутренний балансировщик нагрузки (ILB), где каждый ILB имеет собственную запись DNS.


Характеристики многопользовательской платформы GKE
Как указано в общедоступной документации Google, при запуске и эксплуатации кластера GKE необходимо учитывать ряд факторов. Команда платформы усердно работала над решением следующих вопросов и удовлетворением требований различных команд арендаторов:
  • Размещение рабочей нагрузки: команда платформы назначает метки пулам узлов для поддержки соответствия рабочей нагрузки, а арендаторы используют комбинацию маркеров и допусков, чтобы гарантировать распределение рабочих нагрузок по правильным пулам узлов. Это необходимо, поскольку каждый пул узлов предъявляет особые требования к межсетевому экрану в зависимости от типа обрабатываемого трафика (HTTPS, POPS и т.д.). Кроме того, теги диспетчера ресурсов используются для управления правилами межсетевого экрана и связывания пула узлов с соответствующим правилом межсетевого экрана.
  • Управление доступом: управление доступом на основе ролей (RBAC) в Kubernetes — основной способ управления и ограничения доступа пользователей к ресурсам кластера. У каждого арендатора есть одно или несколько пространств имён в кластере, и кластер загружается со стандартными политиками в процессе подключения арендатора.
  • Сетевые политики: все кластеры организованы на основе dataplane v2, а Yahoo Mail использует стандартную сетевую политику Kubernetes для управления потоками трафика. В основе лежит Cilium — решение с открытым исходным кодом для обеспечения, защиты и мониторинга сетевого соединения между рабочими нагрузками.
  • Квоты ресурсов: для оптимизации использования ресурсов и предотвращения чрезмерного потребления команда платформы применяет квоты ресурсов для ЦП/памяти в пределах пространства имен.
  • Масштабирование: определяется командой платформы на основе запросов квот, поданных арендатором при подключении. Из-за определённых ограничений функций, связанных с автоматической подготовкой узлов, связанных с использованием безопасных тегов для правил брандмауэра и определением определённого типа и формы машины, это не удалось реализовать, но мы совместно с командой инженеров разработали запросы функций для устранения этого пробела.

Проблемы
В ходе этой миграции как Yahoo Mail, так и Google столкнулись с техническими ограничениями и проблемами. Ниже мы описываем некоторые из основных проблем и подходы, принятые для их решения:
  • Подключение к плоскости управления: Как и большинство корпоративных клиентов, Yahoo Mail предоставила частные кластеры GKE и нуждалась в подключении между плоскостью управления и инструментом CI/CD (отвёрткой) извне сети VPC. Команда платформы развернула хосты-бастионы, которые использовались для проксирования подключения к плоскости управления, но столкнулась с проблемами масштабируемости. Google совместно с клиентом протестировала два решения, использующие шлюз Connect и конечную точку на основе DNS, чтобы исключить необходимость в хосте-бастионе.
  • Сквозной mTLS: одним из ключевых принципов безопасности Yahoo Mail было обеспечение сквозного mTLS, который должен быть реализован как в архитектуре в целом, так и в базовых сервисах Google Cloud. Это привело к серьёзным проблемам, поскольку один из ключевых продуктов балансировки нагрузки ( Application Load Balancer ) на тот момент не поддерживал сквозной mTLS. Мы исследовали альтернативные решения, такие как внедрение специализированного прокси-приложения и использование балансировщиков нагрузки уровня 4 во всём стеке. Профессиональные сервисы также сотрудничали с инженерами Google Cloud для определения требований к поддержке mTLS в рамках Application Load Balancer.
  • Интеграция с Athenz: Yahoo Mail использовала внутренний инструмент управления идентификацией и доступом Athenz, с которым должны были интегрироваться все сервисы Google Cloud для реализации федерации идентификационных данных рабочей нагрузки. В контексте Kubernetes это означало, что пользователям по-прежнему требовалась аутентификация через Athenz, но федерация идентификационных данных рабочей нагрузки использовалась в качестве посредника. Поскольку федерация идентификационных данных рабочей нагрузки также была относительно новой функцией, для успешного внедрения в среду Yahoo Mail нам потребовалось тесное сотрудничество с инженерами Google Cloud.
  • Kubernetes externalTrafficPolicy: Одной из отличительных функций, о которой Yahoo Mail горячо и с нетерпением рассуждала, была взвешенная маршрутизация для балансировщиков нагрузки. Эта функция позволяла оптимально направлять входящий трафик к бэкендам. Хотя эта функция поддерживалась для управляемых групп экземпляров, на тот момент встроенной интеграции с GKE не было. В связи с её отсутствием команде платформы пришлось исследовать и экспериментировать с режимами externalTrafficPolicy, такими как локальный и кластерный режимы, чтобы определить влияние на производительность и ограничения.
  • Планирование ресурсов: Наконец, что не менее важно, специалисты Google Professional Services выполнили планирование ресурсов – краеугольный камень успешной миграции в облако. В данном случае это включало в себя совместную работу нескольких команд разработчиков приложений для определения базового уровня потребностей в ресурсах, формирования ключевых предположений и оценки ресурсов, необходимых для удовлетворения текущих и будущих потребностей. Планирование ресурсов – это высоко итеративный процесс, который должен меняться по мере изменения рабочих нагрузок и требований. Поэтому регулярные проверки и поддержание четкой коммуникации с Google имели первостепенное значение для обеспечения адаптации поставщика облачных услуг к потребностям клиента.

Следующая веха Yahoo Mail
Миграция такого большого приложения, как Yahoo Mail, — это сложнейшая задача. Благодаря двуединому подходу — «поднятию и переносу» для большинства сервисов и стратегической перестройке архитектуры для некоторых — Yahoo уверенно движется к настройке своей почтовой системы для следующего поколения клиентов. Хотя небольшая часть системы Yahoo Mail уже находится в эксплуатации, ожидается, что большинство её сервисов будут запущены в течение следующего года. Подробнее о том, как Google PSO может помочь с другими аналогичными сервисами, см. на этой странице.
cloud.google.com/consulting/portfolio

Приглашаем на митапы about:cloud — infrastructure



Разработчики Yandex Cloud и Yandex Infrastructure приглашают вас посетить митапы about:cloud — infrastructure. В этом году мы впервые проводим их офлайн в нескольких городах.

Даты и города
Выберите город для участия и пройдите регистрацию.
21 августа — Казань
28 августа — Санкт‑Петербург
4 сентября — Новосибирск
11 сентября — Екатеринбург
16 октября — Москва (офлайн + онлайн)
events.yandex.ru/events/aboutcloud/index
В формате неформальной встречи обсудим нюансы разработки и устройство инфраструктуры «под капотом», расскажем о сложностях в разработке и как их избежать, подсветим самые нетривиальные подходы к развертыванию и эксплуатации облачных сервисов.

О чём расскажем
  • Как мы разделили плейны для обеспечения отказоустойчивости сети, а также про опыт развертывания и эксплуатации сетевого control-plane.
  • Как мы строим инфраструктуру поверх инфраструктуры.
  • Про разработку «железного» сервиса и нестандартную методику его тестирования.
  • Как обеспечиваем оптимальную работу сетевых дисков с сохранением производительности.
  • Про наш подход к автоматизации управления метаданными и оптимизацию их хранения в S3
  • Про проблему «серых» отказов в сети и как нам удалось её разрешить.