28 мая, 14:00 МСК: вебинар об архитектуре отказоустойчивой RDS-фермы

RDS-ферму несложно собрать из RD Gateway, Connection Broker, Session Hosts, SQL Always On и FSLogix.

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

Отказоустойчивость держится на связях между ролями.

На вебинаре разберём:

1️⃣ Какие связи удерживают пользовательские сессии при отказе отдельного узла - на уровне конкретных компонентов, а не общей схемы.

2️⃣ Где чаще всего прячутся единые точки отказа и какие узлы дублировать в первую очередь.

3️⃣ Как развести клиентский трафик, репликацию и HA-связи между двумя ЦОД.

📢 Спикер: Алексей Ежков, системный администратор Cloud4Y.

📅🕑 Дата и время: 28 мая, 14:00 МСК.

Регистрация тут

Поставьте + в комментариях и мы пришлём, автономную интерактивную схему фермы, где показаны все ключевые компоненты и связи между ними: клиентский трафик, внутренние соединения, репликация, HA-связи, DNS и кросс-ЦОД маршруты.

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

Счёт за мониторинг растёт быстрее, чем сама инфраструктура.

Datadog тарифицируется по числу хостов - $15–34 за хост в месяц (≈ 1 070–2 425 ₽) для инфраструктурного мониторинга, плюс $0,10 за ГБ логов (≈ 7 ₽) и до $2,50 за миллион проиндексированных событий (≈ 180 ₽) - по курсу ЦБ на 20.05.2026.

На сотнях хостов с высокой кардинальностью метрик счёт за наблюдаемость превышает стоимость самой инфраструктуры.

Для российских команд добавляется ограниченный доступ к зарубежным SaaS.

Open-source стек снимает оплату за хосты и события, перенося затраты в инженерные часы и собственную инфраструктуру.

▪️ Метрики собирает VictoriaMetrics (Apache 2.0): совместима с Prometheus по протоколу и PromQL, на больших объёмах потребляет в 5–10 раз меньше памяти (DevOpsBoys, 2026).

▪️ Логи берёт на себя Loki (AGPLv3): индексирует метки, а не полный текст, поэтому хранение в объектном хранилище дешевле.

▪️ Визуализацию и оповещения закрывает Grafana (Apache 2.0) с Unified Alerting, распределённую трассировку - Tempo.

Стек оправдан при нагрузке с упором на метрики и наличии команды, которая возьмёт эксплуатацию на себя: «бесплатный» открытый стек требует 1–2 инженеров на поддержку.

Рассчитать инфраструктуру под стек мониторинга.

Облачный счёт за стабильную нагрузку часто оказывается выше, чем кажется на старте.

Публичное облако тарифицирует вычисления, хранение, запросы и исходящий трафик по отдельности.

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

Для такой стабильной нагрузки фиксированная аренда стоек или частное облако обходятся дешевле.

В России аренда 5-кВт стойки в ЦОД уровня Tier III начинается от 85 000 ₽ в месяц, и при сопоставимой мощности это становится альтернативой облаку в трёх сценариях. Colocation выигрывает там, где нагрузка предсказуема, а оборудование своё.

1️⃣ Устойчивая высокая утилизация.
При загрузке выше 70% круглосуточно собственное железо в аренде стоек достигает паритета с облаком примерно за год, дальше обходится дешевле.

2️⃣ Специфическое оборудование:
GPU-плотность, кастомные конфигурации, контроль над firmware и топологией хранения, которые публичное облако даёт с наценкой.

3️⃣ Длинный горизонт:
на 3–5 лет амортизация оборудования и фиксированная аренда защищают от роста облачных тарифов.

Облако остаётся выгоднее для переменных и непредсказуемых нагрузок.

Аренда стоек оправдана при стабильном профиле и своём оборудовании.

Рассчитать TCO под вашу нагрузку.

За май охватили инфраструктуру сверху донизу - от регуляторики до оборудования.

Что разобрали:

Суверенный стек разработки

▪️Показали, как собрать CI/CD-конвейер в изолированном контуре, не обращаясь к зарубежным облачным сервисам

▪️Сравнили открытые аналоги GitHub, Jira и Confluence и разобрали, как из них собрать рабочий стек для команды до 50 человек

▪️Показали, как заменить Datadog связкой VictoriaMetrics, Grafana и Loki и во сколько это обходится на практике

Экономика физической инфраструктуры

▪️ Разобрали, какая видеокарта подходит под обучение, инференс и графику - от RTX 4090 до Blackwell

▪️ Объяснили, когда модульный ЦОД оправдан, а когда выгоднее стационарный

▪️ Посчитали, при каком профиле нагрузки аренда стоек обходит облако по TCO

Регуляторика и надёжность

▪️ Разобрали, что приказ ФСТЭК №117 изменил для субъектов КИИ и операторов ГИС

▪️ Сравнили архитектурные варианты хранения персональных данных по 152-ФЗ и их экономику

▪️ Показали, когда георезервирование реально снижает риски, и какие настройки Kubernetes-манифестов обычно забывают

Обсудить инфраструктуру под вашу задачу.

Смена лицензии Terraform на BSL в 2023 году сделала OpenTofu разумным выбором для команд, которым важна стабильность инструмента.

HashiCorp перевела Terraform с открытой MPL 2.0 на закрытую Business Source License, ограничивающую коммерческое использование, и сообщество создало форк последней открытой версии - OpenTofu, который теперь развивается под эгидой Linux Foundation на лицензии MPL 2.0.

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

OpenTofu - прямая замена Terraform: тот же HCL, те же провайдеры, тот же формат state.

Миграция обычно механическая: заменить исполняемый файл, выполнить tofu init -upgrade и tofu plan. Если plan не показывает изменений - готово.

При этом OpenTofu добавил то, чего нет в открытой версии Terraform: шифрование state на стороне клиента, ранний разбор переменных, флаг -exclude.

Описанная в коде инфраструктура на российском облаке разворачивается одинаково в каждой среде, а ревью изменений идёт через обычный pull request.

Рассчитать конфигурацию под IaC.

Приказ ФСТЭК №117 действует с 1 марта 2026 года и меняет саму логику защиты государственных систем: вместо разовой аттестации внедряется непрерывное управление информационной безопасностью.

Он заменил приказ №17 и распространяется теперь не только на ГИС, но и на любые информационные системы госорганов, ГУП и госучреждений.

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

Практический путь начинается с инвентаризации, а дальше выстраивается процесс:

1️⃣ Cоставить полный перечень информационных систем под защитой: все ГИС, иные ИС для госфункций, компоненты инфраструктуры

2️⃣ Построить модель угроз и подобрать меры под конкретную систему по риск-ориентированному принципу, а не типовым списком

3️⃣ Выстроить процесс оценки эффективности и отчётности - ядро новых требований.

Аттестаты, выданные до 1 марта 2026, остаются действительными, поэтому переаттестация с нуля не нужна: задача в переходе к постоянному сопровождению.

Разместить систему в аттестованном сегменте облака.

Резервная копия есть почти у всех, а вот восстановление из неё проверяют единицы - и узнают о проблеме в момент аварии.

Правило 3-2-1 остаётся базовым: три копии данных, на двух разных типах носителей, одна вне основной площадки.

В 2026 году к нему добавляется четвёртая копия - неизменяемая, которую не сотрёт ни администратор, ни вирус-шифровальщик.

Так отвечают на то, что шифровальщики поражают весь домен меньше чем за четыре часа.

Копия в той же стойке или здании не считается размещённой вне площадки: один инцидент уничтожит обе.

Дальше всё определяют две метрики:

▪️ RTO задаёт, сколько времени бизнес терпит простой;

▪️ RPO задаёт, какой объём данных допустимо потерять (RPO в один час означает копию минимум раз в час).

Чем ниже обе цифры, тем дороже инфраструктура под них.

И главное: копия, восстановление из которой ни разу не тестировали, надёжной не считается.

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

Рассчитать схему резервного копирования под вашу нагрузку.

Service mesh решает реальные задачи - mTLS между сервисами, управление трафиком, наблюдаемость, - но нужен не каждому кластеру.

Несколько лет классический sidecar-подход (Envoy в каждый pod) добавлял столько накладных расходов и операционной сложности, что многие команды от него отказывались: по данным CNCF, доля sidecar-меша в 2024 году снизилась. Каждый pod требовал прокси, а обновление меша означало перезапуск приложений.

Ситуацию изменил ambient mode: с конца 2024 года Istio умеет работать без sidecar.

Трафик разделён на два уровня:

L4 (mTLS, телеметрия) закрывает общий ztunnel на узле, а L7-прокси разворачивается только там, где нужна маршрутизация HTTP.

Это убрало главный барьер - overhead на каждый pod.

Service mesh оправдан, когда у вас десятки и сотни сервисов, нужен mTLS по умолчанию, канареечные выкатки и единая наблюдаемость.

Для пары сервисов это избыточно: проще обойтись API gateway и сетевыми правилами.

Развернуть кластер Kubernetes под такую архитектуру.