Миграция на новые тарифы
Выбор новых тарифов
Могут ли новые организации запускать сервисы на старом (наследственном) тарифе?
Нет, вновь созданные организации не будут иметь доступ к старому тарифу после объявления.
Могут ли пользователи самостоятельно перейти на новый тарифный план?
Да, см. ниже руководство по самостоятельной миграции:
| Текущий тариф | Новый тариф | Самостоятельная миграция |
|---|---|---|
| Development | Basic | Поддерживается, если все сервисы в организации поддерживают Development |
| Development | Scale (2 реплики+) | ✅ |
| Development | Enterprise (2 реплики+) | ✅ |
| Production | Scale (3 реплики+) | ✅ |
| Production | Enterprise (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.