Перейти к основному содержимому
Перейти к основному содержимому

Миграция на новые планы

Выбор новых планов​

Могут ли новые организации запускать сервисы на старом (наследуемом) плане?​

Нет, вновь созданные организации не будут иметь доступ к старому плану после объявления.

Могут ли пользователи самостоятельно перейти на новый тарифный план?​

Да, ниже приведены рекомендации по самостоятельной миграции:

Текущий планНовый планСамостоятельная миграция
РазработкаБазовыйПоддерживается, если все сервисы в организации поддерживают Разработку
РазработкаМасштаб (2 реплики+)✅
РазработкаКорпоративный (2 реплики+)✅
ПродакшнМасштаб (3 реплики+)✅
ПродакшнКорпоративный (3 реплики+)✅
ВыделенныйСвязаться с поддержкой

Каков будет опыт пользователей, находящихся в тестовом режиме работы с сервисами Разработки и Продакшна?​

Пользователи могут улучшить свои планы во время теста и продолжать использовать кредитные баллы для оценки новых уровней сервиса и поддерживаемых функций. Тем не менее, если они решат продолжить использование одних и тех же сервисов Разработки и Продакшна, они могут сделать это и перейти на PAYG. Тем не менее, им все равно придется мигрировать до 23 июля 2025 года.

Могут ли пользователи повысить свои уровни, т.е. Базовый → Масштаб, Масштаб → Корпоративный и т.д.?​

Да, пользователи могут повысить уровень самостоятельно, и цена отразит выбор уровня после улучшения.

Могут ли пользователи перейти с более высокого на более низкий уровень, т.е. Корпоративный → Масштаб, Масштаб → Базовый, Корпоративный → Базовый самостоятельно?​

Нет, мы не разрешаем понижение уровней.

Могут ли пользователи с только услугами Разработки в организации перейти на Базовый уровень?​

Да, это будет разрешено. Пользователям будет предложена рекомендация на основании их прошлого использования, и они смогут выбрать Базовый 1x8GiB или 1x12GiB.

Могут ли пользователи с услугами Разработки и Продакшна в одной и той же организации перейти на Базовый уровень?​

Нет, если у пользователя есть как услуги Разработки, так и Продакшна в одной организации, он может самостоятельно мигрировать только на уровни Масштаб или Корпоративный. Если они хотят перейти на Базовый, им следует удалить все существующие услуги Продакшна.

Мы вводим новый механизм вертикального масштабирования для вычислительных реплик, который мы называем "Соглашение перед Разрывом" (MBB). Этот подход добавляет одну или несколько реплик нового размера перед удалением старых реплик, предотвращая любые потери емкости во время операций масштабирования. Устранение разрыва между удалением существующих реплик и добавлением новых создает более бесшовный и менее разрушительный процесс масштабирования. Это особенно полезно в сценариях увеличения, когда высокая загрузка ресурсов вызывает необходимость в дополнительной емкости, поскольку преждевременное удаление реплик только усугубит ограниченность ресурсов.

Обратите внимание, что в рамках этого изменения данные исторических системных таблиц будут храниться не более чем 30 дней в рамках событий масштабирования. Кроме того, любые данные системной таблицы старше 19 декабря 2024 года для услуг на AWS или GCP и старше 14 января 2025 года для услуг на Azure не будут сохраняться в рамках миграции на новые уровни организаций.

Оценка затрат​

Как пользователи будут получать рекомендации во время миграции, понимая, какой уровень лучше всего подходит их потребностям?​

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

Как пользователи определяют и оценивают стоимость "складов" в новом ценообразовании?​

Пожалуйста, обратитесь к калькулятору цен на странице Цены, который поможет оценить стоимость на основе размера нагрузки и выбора уровня.

Проведение миграции​

Каковы предварительные условия версии сервиса для проведения миграции?​

Ваш сервис должен быть версии 24.8 или выше и уже мигрирован на SharedMergeTree.

Каков опыт миграции для пользователей текущих услуг Разработки и Продакшна? Должны ли пользователи планировать время обслуживания, когда сервис недоступен?​

Миграция услуг Разработки и Продакшна на новые тарифные планы может вызвать перезапуск сервера. Для миграции выделенного сервиса, пожалуйста, свяжитесь с поддержкой.

Какие действия должен предпринять пользователь после миграции?​

Шаблоны доступа к API будут другими.

Пользователи, которые используют наш OpenAPI для создания новых сервисов, должны будут удалить поле tier в запросе POST на создание сервиса.

Поле tier было удалено из объекта сервиса, так как у нас больше нет уровней обслуживания.
Это повлияет на объекты, возвращаемые запросами POST, GET и PATCH. Поэтому любой код, использующий эти API, может потребовать корректировки для обработки этих изменений.

Число реплик, с которым будет создан каждый сервис, по умолчанию составляет 3 для уровней Масштаб и Корпоративный, в то время как по умолчанию составляет 1 для Базового уровня.
Для уровней Масштаб и Корпоративный возможно регулировать это, передавая поле numReplicas в запросе на создание сервиса.
Значение поля numReplicas должно быть между 2 и 20 для первого сервиса в складе. Сервисы, создаваемые в существующем складе, могут иметь число реплик не менее 1.

Какие изменения должны внести пользователи, если они используют существующий Terraform-провайдер для автоматизации?​

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

Новый Terraform-провайдер необходим для обработки изменений в атрибуте tier сервиса.

После миграции поле tier больше не принимается, и ссылки на него должны быть удалены.

Пользователи также смогут указывать поле num_replicas как свойство ресурса сервиса.

Число реплик, с которым будет создан каждый сервис, по умолчанию составляет 3 для уровней Масштаб и Корпоративный, в то время как по умолчанию составляет 1 для Базового уровня.
Для уровней Масштаб и Корпоративный возможно регулировать это, передавая поле numReplicas в запросе на создание сервиса.
Значение поля num_replicas должно быть между 2 и 20 для первого сервиса в складе. Сервисы, создаваемые в существующем складе, могут иметь число реплик не менее 1.

Должны ли пользователи вносить какие-либо изменения в доступ к базе данных?​

Нет, имя пользователя/пароль базы данных будут работать так же, как и прежде.

Должны ли пользователи перенастраивать функции частной сети?​

Нет, пользователи могут использовать существующую конфигурацию частной сети (Private Link, PSC и т.д.) после перемещения своего сервиса Продакшн на Масштаб или Корпоративный уровень.