Spanner Omni после GA: переносимость распределённой SQL-системы или перенос операционной сложности

Компания хочет сохранить семантику Spanner, но не может разместить данные только в Google Cloud. Причиной могут быть требования к резидентности данных, инфраструктура заказчика или стратегия выхода из конкретного облака. Spanner Omni выглядит прямым ответом: тот же класс распределённой SQL-системы можно запускать локально, в AWS или Google Cloud.

Но вместе с движком компания не получает операционную модель Cloud Spanner. Сеть между зонами, кворум, диски, синхронизация времени, TLS, резервные копии, мониторинг, обновления и реакция на инциденты становятся ответственностью владельца системы.

Поэтому вопрос выбора звучит не как «можно ли запустить Spanner вне Google Cloud?». Можно. Вопрос в другом: способна ли ваша платформенная команда самостоятельно обеспечить свойства, которые в управляемом Spanner скрыты за сервисным SLA и работой Google?

GA состоялся, но важно понимать, что именно выпущено

Согласно примечаниям к выпускам, Google объявил Spanner Omni общедоступным 30 сентября 2026 года и выпустил LTS-версию 2026.r4-lts. Для этой линии заявлены исправления безопасности в течение одного года.

Это не только формальный статус. Для практической проверки доступны:

• загружаемый образ контейнера;

• отдельный пакет для виртуальных машин;

• чарт Helm версии 1.0.0;

• конфигурации от одного сервера до нескольких кластеров.

Артефакты перечислены на официальной странице загрузки Spanner Omni. Следовательно, продукт можно проверять не по презентациям, а через развёртывание, испытание отказов и восстановление.

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

• точный SKU и редакцию продукта;

• право на промышленную эксплуатацию;

• срок и объём поддержки конкретной LTS-линии;

• поддерживаемые платформы и конфигурации;

• порядок получения исправлений;

• условия расширенной поддержки.

Источником истины для технического статуса можно считать примечания к выпускам для версии GA и опубликованные LTS-артефакты. Источником истины для коммерческих обязательств должен оставаться договор.

Переносимый движок — не переносимый управляемый сервис

Главное различие между Cloud Spanner и Spanner Omni проходит не по SQL API, а по границе ответственности.

Это различие прямо отражено в сопоставлении Spanner и Spanner Omni.

Таким образом, у переносимости есть как минимум четыре уровня:

1. Переносимость исполняемого движка. Omni действительно можно разместить вне Google Cloud.

2. Операционная переносимость. Команда должна уметь воспроизвести сеть, хранилище, безопасность, мониторинг и процедуры эксплуатации на новой площадке.

3. Переносимость приложения. Совместимый SQL-диалект не гарантирует отсутствие изменений в приложении и инструментах.

4. Коммерческая переносимость. Omni остаётся проприетарным продуктом Google с контрактной лицензией на vCPU.

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

От локального теста до промышленной топологии

Редакция для разработчиков — средство проверки, а не бесплатный промышленный кластер

Бесплатная редакция для разработчиков предназначена только для непромышленного и некоммерческого использования. Обычная лицензия для разработчиков прекращает операции записи через 90 дней. Бессрочный режим, расширенные функции безопасности и резервного копирования без истечения срока доступны только для односерверного развёртывания размером до 4 vCPU.

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

Односерверная редакция для разработчиков полезна для короткой проверки:

• поддерживаемого SQL;

• подключения через PGAdapter;

• поведения клиентских библиотек;

• базового резервного копирования во внешнее S3-совместимое хранилище;

• метрик консоли;

• перезапуска контейнера с постоянным томом.

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

Минимальная топология должна отражать реальные домены отказа

Spanner Omni поддерживает односерверные, однозонные, многозонные и многокластерные конфигурации. Для многозонной конфигурации документация рекомендует как минимум три зоны и по три сервера в каждой. Для многокластерной — минимум три зоны в двух или более кластерах и не менее трёх серверов в зоне. Подробности приведены в обзоре Spanner Omni.

Само наличие меток zone-a, zone-b и zone-c не создаёт независимых доменов отказа. Если все узлы зависят от одного массива хранения, сетевого коммутатора, электропитания, плоскости управления Kubernetes или сервиса времени, логически многозонная конфигурация может остаться физически однозонной.

Перед проектированием кворума нужно зафиксировать реальные границы отказа:

• питание и стойки;

• коммутаторы и маршруты;

• кластеры Kubernetes;

• постоянные диски и контроллеры хранения;

• балансировщики нагрузки;

• сервисы времени;

• центры сертификации и хранилища секретов;

• административные контуры.

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

Требования к платформе ограничивают абстрактное «запускается везде»

Для промышленного локального развёртывания документация требует x86-64 Linux, 4 ГБ оперативной памяти на каждый vCPU, выделенные постоянные SSD с ext4 и 500 ГБ дискового пространства на vCPU. Требования к производительности хранения составляют минимум 500 IOPS и 30 МБ/с на vCPU. Локальные диски не поддерживаются. Полный список приведён в системных требованиях.

Для AWS дополнительно требуется доступ к /dev/vmclock0, совместимый тип виртуальной машины и Amazon Linux 2023.

Kubernetes-развёртывания подробно документированы для GKE и EKS. Для других дистрибутивов Kubernetes конфигурацию может потребоваться адаптировать. Это особенно важно для локальных платформ, где поведение CSI-драйверов, сети и постоянных томов может отличаться. Статус поддержки конкретного дистрибутива, bare-metal сети и системы хранения следует подтвердить в коммерческом соглашении, а не выводить из общего обещания работы за пределами Google Cloud.

Внешняя согласованность зависит от вашей инфраструктуры времени

Одна из ключевых характеристик Spanner — external consistency. В Cloud Spanner она опирается на TrueTime Google с GPS и атомными часами. В Omni используется программно определяемый TrueTime: оператор задаёт SLA для часов, включая допустимые джиттер и скорость дрейфа, а развёртывание использует основной сервер времени и клиенты на узлах.

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

Состояние часов влияет и на задержки. Чем больше неопределённость времени, тем шире временное окно, с которым должна работать система. Реальный результат зависит от размещения узлов, сетевых задержек, дисков, параметров часов и поведения кворума. Обещать задержку на основании названия Spanner здесь нельзя.

Риск не теоретический. В истории выпусков зафиксировано исправление дефекта, при котором повторные переключения серверов времени увеличивали окно неопределённости. Это показывает, что подсистема времени имеет собственные сценарии отказа и нуждается в наблюдаемости.

Для промышленной эксплуатации необходимо контролировать как минимум:

• доступность основного сервера времени;

• дрейф и джиттер на каждом узле;

• размер окна неопределённости;

• переключения источников времени;

• расхождение между доменами отказа;

• влияние проблем времени на задержку фиксации транзакций и клиентские ошибки.

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

Репликация не заменяет план восстановления

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

• потерю процесса или контейнера;

• потерю рабочего узла Kubernetes;

• отказ диска;

• потерю зоны;

• сетевое разделение;

• потерю целой площадки или кластера;

• ошибочное изменение или удаление данных;

• повреждение конфигурации;

• потерю всего развёртывания.

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

Что дают резервные копии Omni

Резервная копия Omni представляет собой транзакционно и внешне согласованный снимок на момент versionTime. Файлы хранятся за пределами развёртывания — в Amazon S3, Google Cloud Storage или S3-совместимом хранилище. При потере исходного развёртывания копию можно импортировать в новое из того же внешнего хранилища. Процесс описан в документации по резервным копиям.

В копию не входят политики IAM и данные change streams. Это означает, что восстановление базы ещё не равно восстановлению сервиса. Отдельно должны быть воспроизводимы:

• роли и права доступа;

• сертификаты и секреты;

• сетевые политики;

• конфигурация балансировщиков;

• настройки мониторинга;

• параметры времени;

• клиентские маршруты;

• инфраструктурный код.

У Omni также нет инкрементальных резервных копий, доступных в Cloud Spanner. Поэтому модель хранения, длительность операций и стоимость объектного хранилища нужно измерять на собственном объёме данных.

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

Наблюдаемость, безопасность и обновления формируют скрытую стоимость

Встроенные метрики не создают готовый контур эксплуатации

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

Промышленный контур должен связывать метрики базы с инфраструктурой:

• задержками и ошибками клиентских запросов;

• состоянием реплик и перемещением лидеров;

• дисковой задержкой, IOPS и заполнением томов;

• сетевыми потерями и RTT между зонами;

• здоровьем сервиса времени;

• сроком действия сертификатов;

• результатами резервного копирования и восстановления.

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

Шифрование и сертификаты принадлежат оператору

Для промышленной конфигурации требуется TLS 1.3 между клиентом и сервером и mTLS между серверами. Шифрование данных в состоянии покоя нужно обеспечить на уровне диска или файловой системы.

Из этого следуют отдельные операционные процессы:

• выпуск и ротация сертификатов;

• доставка секретов на узлы;

• отзыв скомпрометированных удостоверений;

• управление ключами шифрования дисков;

• проверка сроков действия сертификатов;

• восстановление доступа после аварии хранилища секретов.

Cloud Spanner скрывает значительную часть этих процессов внутри управляемого сервиса. В Omni они входят в реальную стоимость владения, даже если не отражаются в счёте за лицензию.

Обновление — многофазная операция с границей отката

Обновление Omni состоит из миграции схемы, последовательного обновления исполняемых файлов, включения функций и финализации. До финализации исполняемую версию можно откатить, но этап изменения схемы не откатывается. Для виртуальных машин Google рекомендует выполнять обновление по доменам отказа и не перезапускать одновременно более 5% серверов. Процедура описана в руководстве по обновлению.

Это требует:

• отдельной среды предварительной проверки;

• актуальной резервной копии;

• проверки совместимости клиентов;

• эксплуатационной инструкции по фазам;

• критериев продолжения и остановки;

• наблюдения за кворумом, задержками и ошибками;

• заранее определённой точки, после которой откат невозможен.

Не следует переносить на процесс обновления версии GA опыт ранних бета-версий. Например, для beta 2026.r2.1 обновление на месте из ранних выпусков не поддерживалось: требовалась миграция в новое развёртывание через восстановление копии или импорт и экспорт. Это часть истории зрелости продукта, но не описание заявленного процесса обновления GA-версии.

Совместимость со Spanner и PostgreSQL имеет границы

Omni не обладает полной функциональной эквивалентностью Cloud Spanner. Среди отсутствующих возможностей документация называет Data Boost, географическое секционирование, инкрементальные резервные копии, многоуровневое хранение, интеграцию Cloud Spanner CMEK, интеграции с BigQuery и часть функций AI и векторного поиска. Клиентская поддержка ограничена библиотеками Java, Go и Python, а также gRPC; консоль работает только на чтение.

Это особенно важно, если Omni рассматривается как перенос существующей системы Cloud Spanner. Совпадение базового движка не означает, что все связанные сервисы и процессы можно перенести без переработки.

Аналогично, PostgreSQL dialect и PGAdapter обеспечивают совместимость с сетевым протоколом PostgreSQL, но не полную эквивалентность PostgreSQL. До миграции нужно отдельно проверить:

• используемые конструкции SQL;

• расширения PostgreSQL;

• поведение ORM;

• системные каталоги;

• инструменты миграции схемы;

• повтор транзакций и тайм-ауты;

• эксплуатационные сценарии;

• характеристики производительности.

Проверка «драйвер подключился и выполнил SELECT» доказывает только сетевую и базовую синтаксическую совместимость.

Как Omni соотносится с альтернативами

Сравнивать продукты только по ярлыкам «distributed SQL» или «PostgreSQL-compatible» недостаточно. У них разные модели согласованности, отказоустойчивости, лицензирования и эксплуатации.

Cloud Spanner

Cloud Spanner остаётся более сильным вариантом, если основная ценность — управляемая эксплуатация. Google автоматически применяет обновления, управляет резервным копированием и обслуживанием, отвечает за физическую безопасность, шифрование данных в состоянии покоя и доступность сервиса.

Цена этого удобства — привязка размещения к Google Cloud и меньший контроль над инфраструктурой. Omni имеет смысл не как «более дешёвый Cloud Spanner», а прежде всего при жёстком требовании размещать данные вне управляемого сервиса Google.

CockroachDB

CockroachDB в самостоятельном развёртывании предоставляет сериализуемую изоляцию по умолчанию, но приложение должно корректно повторять транзакции при конкуренции. Топология с переживанием отказа региона увеличивает задержку записи как минимум на RTT до ближайшего региона. Система также зависит от синхронизации часов и может самостоятельно завершить работу узла при чрезмерном смещении времени. Эти особенности описаны в руководстве разработчика и технической публикации CockroachDB.

CockroachDB нельзя автоматически считать вариантом без лицензионной зависимости. Актуальная самостоятельная модель использует CockroachDB Software License; Enterprise требует ежегодного продления, а Enterprise Free зависит от лимита выручки и условий телеметрии и ограничения производительности. Условия следует проверять по лицензионному FAQ.

YugabyteDB

YugabyteDB поддерживает синхронную межрегиональную репликацию и географическое размещение данных. xCluster и реплики чтения предоставляют асинхронные варианты. Это даёт несколько разных архитектурных режимов, которые нельзя сводить к одному показателю высокой доступности. Возможности описаны в документации по многорегиональным развёртываниям.

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

PostgreSQL с Patroni

Patroni не превращает PostgreSQL в distributed SQL. PostgreSQL предоставляет потоковую репликацию, а Patroni координирует выбор лидера через распределённое хранилище конфигурации. При автоматическом переключении кандидат может быть исключён из обычного выбора из-за отставания репликации. Синхронный режим и кворумная репликация меняют компромисс между задержкой и доступностью.

Такой стек может быть предпочтительнее, если:

• нагрузка укладывается в модель основного узла и резервной реплики;

• нужны расширения PostgreSQL;

• приложение уже совместимо с его семантикой;

• команда умеет эксплуатировать PostgreSQL и Patroni;

• горизонтальная запись между площадками не является обязательным требованием.

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

Решение должно опираться на испытание, а не на список функций

На момент исследования не найден независимый опубликованный набор тестов, который сравнивал бы GA-версию 2026.r4-lts с Cloud Spanner, CockroachDB, YugabyteDB и PostgreSQL с Patroni по единой методике. Поэтому нельзя честно назвать заранее ожидаемые задержки, RTO, RPO, скорость восстановления, пропускную способность или TCO.

Минимальная проверка Omni должна проходить в трёх реальных доменах отказа на GKE, EKS или подтверждённой поставщиком локальной платформе. Для всех сравниваемых систем следует использовать одинаковые данные и профиль нагрузки:

• локальные и межрегиональные операции записи;

• конкуренцию вокруг горячих ключей;

• чтение после записи;

• длительные и короткие транзакции;

• массовое восстановление;

• потерю процесса, узла, зоны и сетевого маршрута;

• отказ или деградацию сервера времени.

Результаты удобно фиксировать в единой оценочной карте:

Spanner Omni обоснован, когда размещение вне Google Cloud является обязательным, семантика Spanner имеет самостоятельную ценность, а команда готова владеть распределённой системой целиком. Он заметно слабее как попытка получить Cloud Spanner дешевле, сохранив прежний уровень операционной абстракции.

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