Надежность по принципу Zero Trust: как мы делаем облачную платформу VK Cloud отказоустойчивой и стабильной

Современная кибербезопасность строится вокруг концепции Zero Trust («не доверяй никому»). Мы пошли дальше и внедрили этот принцип не только в отдельные практики информационной безопасности, но и в саму структуру нашей облачной платформы, чтобы сделать VK Cloud еще надежнее, безопаснее и отказоустойчивее.

Рассказываем, как обеспечивается стабильность VK Cloud на каждом из уровней.

Об облаках и возможных рисках

Российский облачный рынок планомерно и стабильно развивается. Этому способствует повышение спроса на облачные услуги, постепенный переход компаний на сервисы российских поставщиков и важность для бизнеса получения надежной рабочей среды «из коробки». Вместе с тем далеко не все вендоры могут гарантировать стабильно высокую доступность облака. Например:

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

Чтобы подобные риски были неактуальны для VK Cloud, мы непрерывно работаем над совершенствованием мер отказоустойчивости и стабильности облачной платформы на всех уровнях. Например, сейчас в рамках этой стратегии мы проводим глобальную модернизацию VK Cloud на инфраструктурном и программном уровнях.

Меры повышения отказоустойчивости и стабильности на уровне инфраструктуры

Сейчас инфраструктура облачной платформы VK Cloud соответствует высоким требованиям в части надежности, безопасности и защищенности. Это подтверждено многочисленными сертификатами. Но мы не останавливаемся на достигнутом и уже определили, какой должна быть целевая отказоустойчивая инфраструктура, к которой мы стремимся. Выделим некоторые параметры и условия, которые для этого следует выполнить.

• Использование дата-центров уровня Tier IV. Нам, как крупному провайдеру, важно обеспечить максимальную надежность и отказоустойчивость базовой инфраструктуры. Поэтому VK строит ЦОДы, соответствующие строгим стандартам проектирования Tier IV.
• Построение 3-AZ-региона с ЦОДами Tier IV в России. Для корректной работы кворумных приложений в облаке важно иметь три зоны доступности в рамках одного региона. В РФ мы стремимся именно к этой реализации.
• Полный контроль и единые стандарты качества. После отказа от арендованных ЦОДов у нас появилась возможность самостоятельно управлять всей инфраструктурой, применяя единообразные подходы к обслуживанию и сертификации площадок.
• Выработка алгоритма миграции на новые ЦОДы. Одномоментно отказаться от использования старых дата-центров и начать использовать новые невозможно. Поэтому важно предусмотреть порядок одновременной поддержки разных ЦОДов и алгоритм последовательного переключения на новые дата-центры.

При этом упомянутый пул задач — не разовая акция, ведь план работ по совершенствованию отказоустойчивости VK Cloud согласован на несколько лет вперед. Например, в ближайшей перспективе мы планируем запуск четвертой зоны доступности с дата-центром уровня Tier IV.

Меры повышения отказоустойчивости и стабильности на программном уровне

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

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

Control Plane

Одни из ключевых изменений были реализованы на управляющем слое.

• Реализовали переход к конфигурации 3-AZ. Изначально облачная платформа базировалась на двух зонах доступности. Но для кворумных приложений этого недостаточно. Поэтому мы перешли на конфигурацию с тремя зонами доступности.
• Адаптировали сервисы под кластерный режим работы. Исторически часть наших баз данных, сервисов очередей и других инструментов не поддерживали кластерный режим конфигурации, что потенциально сказывалось на их отказоустойчивости. Чтобы устранить эти недостатки, мы переделали часть сервисов.
• Доработали управляющие сервисы. При создании новых сервисов разработчики редко стремятся сразу адаптировать продукты к highload-нагрузкам — на начальных этапах важнее создать решение, которое будет полезно «здесь и сейчас». Отчасти это было актуально и для некоторых наших управляющих сервисов, которые в рамках стратегии повышения отказоустойчивости платформы нам пришлось переписать.
• Развернули Stage-окружение с идентичным control plane. Благодаря этому мы получили возможность проводить любые испытания без влияния на прод.
• Внедрили правило Anti-Affinity на уровне серверных стоек. Развертывание отказоустойчивого сервиса на трех узлах теряет смысл, если все узлы находятся в одной стойке: в случае сбоя стойки сервис станет недоступен и заявленная доступность SLA не будет соблюдаться. Поэтому мы оптимизировали алгоритм размещения экземпляров таким образом, чтобы гарантировать, что они не попадут в одну стойку.
• Повысили отказоустойчивость инфраструктурных сервисов VK. В отдельных сценариях (например, для СМС-рассылки и биллинга) мы используем сервисы внешних поставщиков. Соответственно, стабильность и корректность работы нашей платформы отчасти зависит от надежности этих решений. Поэтому, чтобы повысить отказоустойчивость облачной платформы, мы прорабатывали способы улучшения надежности и всех сервисов внешних поставщиков.

Дисковая подсистема

Значительный объем работ, направленных на повышение отказоустойчивости облака, выполнен и на уровне дисковой подсистемы.

• Добавили поддержку нового типа дисков. Надежное облако для хранения данных и любых других сценариев использования невозможно без высокоскоростных и отказоустойчивых дисков. При этом классические решения часто требуют выбора между производительностью и надежностью. Нам удалось создать новый тип дисков HA High-IOPS, обеспечивающих производительность уровня NVMe с дополнительным преимуществом — встроенной репликацией, снижающей вероятность потери данных.
• Предусмотрели возможность отказа от размещения ВМ и дисков в разных зонах доступности. Ранее наши клиенты могли размещать виртуальные машины и соответствующие им диски в разных зонах доступности. Но в отдельных случаях это могло создавать потенциальные угрозы отказоустойчивости: в случае сбоя в одном дата-центре возникала ситуация, когда сама машина работала исправно, но доступ к ее данным отсутствовал. Теперь такая конфигурация исключена: виртуальные машины и их диски всегда размещаются в одной зоне доступности.
• Уменьшили влияние тайм-аутов. Ранее долгие ожидания отклика от дисковой подсистемы могли негативно сказываться на управлении виртуальными машинами: выполнение стандартных действий становилось невозможным. Благодаря проведенным исследованиям и тестированию мы скорректировали временные интервалы, устранив негативное воздействие длительных задержек.

Сетевая подсистема

Теперь о работах, проведенных на уровне сетевой подсистемы.

Изначально платформа VK Cloud использовала SDN Neutron — решение отлично справлялось при работе с небольшими сетями. Но с большими сетями на тысячи портов SDN Neutron справлялся не так хорошо, что влияло на надежность сервисов. Для нас это было недопустимо, потому что SDN является фундаментом всех виртуальных сетей и сущностей. В связи с этим мы разработали новую SDN Sprut, которая способна поддерживать стабильную работу сетей любого масштаба.

Для повышения отказоустойчивости облачной платформы Sprut непрерывно развивается и пополняется функциональностью. В частности, недавно появились важные функции: общие сети (Shared Network), сервер метаданных на портах (Metadata Server), автоматическое перемещение маршрутизаторов и механизм Dynamic NAT.

Сейчас SDN Sprut находится в проде и является дефолтным решением для всех новых задач. Несмотря на это, полное исключение SDN Neutron запланировано только на 2027 год, поэтому в ходе внедрения мер по повышению отказоустойчивости необходимо было учитывать существование сразу двух систем.

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

• Cross-AZ DHCP-scheduling для Neutron. Теперь агенты Neutron по умолчанию разворачиваются в разных дата-центрах. Это гарантирует непрерывную работу службы DHCP даже при выходе из строя одного из ЦОДов, поскольку виртуальные машины продолжают получать назначаемые им IP-адреса.
• Ограничение автоматической перезагрузки агентов при отказе AZ (Neutron и Octavia). Хотя многие сервисы обладают функцией self-healing, одновременный перезапуск сотен агентов при крупномасштабном сбое может вызвать чрезмерную нагрузку на очереди сообщений и базу данных. Чтобы упростить управление такими ситуациями, мы добавили механизм остановки автоматической перезагрузки агентов для некоторых сервисов, что помогает контролировать восстановление и приоритизировать процессы.
• Балансировка DNS-запросов и настройка балансировки нагрузки. Разработаны дополнительные средства для балансировки DNS-запросов, а также предоставлена возможность указывать предпочтительную зону доступности при создании балансировщика нагрузки. Это улучшает отказоустойчивость и позволяет проектировать эффективные сценарии резервирования.
• Общий IPAM для нескольких SDN. Чтобы избежать возможных осложнений при миграции с одного SDN на другой, мы подготовили универсальное средство управления IP-пространством (IPAM), работающее с несколькими SDN одновременно. Этот инструмент сохраняет старую IP-адресацию, предотвращает кольцевание трафика и упрощает миграционные процессы без необходимости массовой правки конфигурации.
• Утилита для бесшовной миграции с Neutron на Sprut. В октябре 2025 года с помощью специальной утилиты мы завершили перенос порядка 60% сетевых портов с SDN Neutron на SDN Sprut, полностью избежав простоя и влияния на пользователей.

Результаты эффективности реализованных мер

Мы в VK Cloud не просто внедряем и предусматриваем механизмы повышения стабильности и отказоустойчивости платформы, но и регулярно тестируем эффективность реализованных мер. Так, в течение 2025 года мы:

• Провели цикл испытаний (примерно раз в две недели) на Stage, в результате которого убедились, что даже отключение одного дата-центра не приводит к сбою на уровне всей платформы.
• Протестировали отключение зоны доступности на проде — физически отключили control plane зоны GZ. Испытания подтвердили, что наша архитектура отказоустойчивости реализована верно и сбой одной зоны не оказывает влияния на пользователей.

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

Но здесь стоит оговориться.

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