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

Миграция на новые тарифы

Выбор новых тарифов​

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

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

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

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

Текущий ПланНовый ПланСамостоятельная Миграция
DevelopmentBasicПоддерживается, если все услуги в организации поддерживают Development
DevelopmentScale (2 реплики+)✅
DevelopmentEnterprise (2 реплики+)✅
ProductionScale (3 реплики+)✅
ProductionEnterprise (3 реплики+)✅
DedicatedСвяжитесь со службой поддержки

Каков будет опыт пользователей с пробными запусками услуг Development и Production?​

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

Могут ли пользователи обновлять свои тарифы, т.е. Basic → Scale, Scale → Enterprise и т.д.?​

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

Могут ли пользователи перейти с более дорогого тарифа на более дешевый, например, Enterprise → Scale, Scale → Basic, Enterprise → Basic самостоятельно?​

Нет, переход на более дешевые тарифы не разрешается.

Могут ли пользователи с только услугами Development в организации мигрировать на тариф Basic?​

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

Могут ли пользователи с услугами Development и Production в одной организации перейти на тариф Basic?​

Нет, если у пользователя есть как услуги Development, так и Production в одной организации, они могут самостоятельно мигрировать только на тариф Scale или Enterprise. Если они хотят перейти на Basic, им необходимо удалить все существующие услуги Production.

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

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

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

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

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

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

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

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

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

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

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

Миграции услуг Development и Production на новые тарифные планы могут потребовать перезапуска сервера. Чтобы мигрировать выделенную услугу, пожалуйста, свяжитесь со службой поддержки.

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

Шаблоны доступа к API будут отличаться.

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

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

Количество реплик, с которыми будет создаваться каждая услуга, по умолчанию равно 3 для тарифов Scale и Enterprise, тогда как для тарифа Basic по умолчанию равно 1.
Для тарифов Scale и Enterprise возможно изменить это, указав поле numReplicas в запросе на создание услуги.
Значение поля numReplicas должно быть в диапазоне от 2 до 20 для первой услуги в складе. Услуги, которые создаются в существующем складе, могут иметь количество реплик не менее 1.

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

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

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

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

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

Количество реплик, с которым будет создаваться каждая услуга, по умолчанию равно 3 для тарифов Scale и Enterprise, тогда как для тарифа Basic по умолчанию равно 1.
Для тарифов Scale и Enterprise возможно изменить это, указав поле numReplicas в запросе на создание услуги.
Значение поля num_replicas должно быть в диапазоне от 2 до 20 для первой услуги в складе. Услуги, которые создаются в существующем складе, могут иметь количество реплик не менее 1.

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

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

Придется ли пользователям перенастраивать функции частной сети?​

Нет, пользователи могут использовать свои существующие настройки частной сети (Private Link, PSC и т.д.) после переноса своей услуги Production на Scale или Enterprise.