EFSOL перенесла 1С компании «Рыбные корма» на PostgreSQL и собрала отказоустойчивый облачный кластер. Для закупочной комиссии этот кейс подтверждает, что схема работает. Готовой конфигурации для другой компании он не даёт.
Рассчитать свои ресурсы можно только по своей нагрузке: числу пользователей, размерам баз, пиковым операциям, загрузке процессора и памяти, дисковым IOPS. Параметры виртуальных машин и результаты чужих замеров без этого контекста переносить в расчёт нельзя.
Вердикт для закупочной комиссии такой: кейс подтверждает работоспособность подхода, но не заменяет расчёт. Чтобы сравнить облако с локальным сервером, запроси архитектуру, исходную нагрузку и состав услуг у каждого поставщика.
Облако нужно сравнивать не с одним сервером, а со всей локальной системой
EFSOL сообщает о трёх результатах проекта: высокой доступности кластера 1С на PostgreSQL, экономии на лицензиях и росте без простоев. Чтобы перенести эти результаты в финансовую модель своей компании, нужны сумма экономии, состав лицензий и технические параметры кластера.
Документация архитектурного центра Cloud.ru показывает, что облачная 1С состоит не только из базы данных. В типовую схему входят:
- серверы приложений 1С;
- сервер лицензий;
- сервер базы данных;
- сервер публикации;
- сервер идентификации на базе OpenID;
- сетевое соединение с площадкой заказчика;
- балансировщик нагрузки;
- резервное копирование.
Поэтому сравнение «облако против одного физического сервера» занижает стоимость локального варианта. С обеих сторон должны стоять одинаковые функции: доступ пользователей, работа приложений, хранение базы, лицензирование, публикация, идентификация, резервное копирование и восстановление после отказа.
Для локальной площадки ресурсы можно получить через расчёт сервера для нескольких баз 1С. Его цифры нельзя переносить в проект EFSOL: нагрузка другой компании неизвестна. Полезен сам принцип — сначала измерить базы и операции, затем перевести их в ядра, память и дисковую нагрузку.
Отказоустойчивость здесь собрана из отдельных механизмов
В архитектуре Cloud.ru серверы приложений размещают в разных зонах доступности. Нагрузку между серверами приложений и публикации распределяет ELB. Базу данных разворачивают как RDS в конфигурации Multi-AZ Master/Standby: основной экземпляр обрабатывает запросы, резервный находится в другой зоне.
Резервные копии инфраструктуры создаёт сервис CBR. Это отдельный механизм: резервный экземпляр базы сокращает простой при отказе, а копии возвращают данные и компоненты после повреждения или удаления. Наличие Master/Standby не отменяет бэкап.
Провайдер должен показать эти элементы в своей схеме и закрепить их в предложении. Формулировки «отказоустойчивое облако» недостаточно: из неё не видно, дублируются ли серверы приложений, где находится резервная база и что попадает в копию.
Согласуй и обязательства по восстановлению: после каких отказов система переключается автоматически, когда потребуется ручная работа и за какой срок поставщик вернёт сервис. Эти параметры нужны для договора независимо от того, как был устроен проект EFSOL.
После миграции офис зависит от канала связи
Пользователи Cloud.ru Advanced подключаются к 1С через Site-to-Site VPN или Direct Connect. Документация допускает доступ через интернет либо выделенное сетевое соединение, но подходящую пропускную способность и задержку придётся считать под свою компанию.
Числовой порог без замеров здесь был бы выдумкой. Его рассчитывают по числу одновременных сеансов, способу публикации 1С, объёму передаваемых данных и допустимому времени отклика.
До договора проверь два независимых маршрута от офиса к облаку. Если оба проходят через одного оператора и один кабельный ввод, отказ в этом месте остановит доступ к 1С, даже когда облачный кластер продолжит работать.
Зафиксируй порядок переключения: кто обнаруживает обрыв, как сотрудники переходят на резервный маршрут и какие подразделения должны сохранить доступ первыми. Эта часть не относится к вычислительным ресурсам облака, но определяет доступность 1С для офиса.
Аппаратные ключи 1С придётся заменить
Cloud.ru указывает, что платформа Advanced не поддерживает аппаратные USB-носители лицензий 1С. До миграции проверь, какие лицензии использует компания, можно ли перевести их в программную схему и как изменится стоимость.
EFSOL сообщает об экономии на лицензиях в своём проекте. Чтобы применить этот вывод к другой компании, нужны исходное количество лицензий, их типы и схема размещения.
В коммерческом предложении лицензии должны идти отдельной строкой. Иначе скидка на облачные ресурсы может скрыть расходы на замену USB-ключей и изменение лицензионной схемы.
Если компания выбирает между облаком и новой локальной платформой, отдельно сравни варианты замены сервера под 1С и виртуальные машины. Там локальная конфигурация разобрана вместе с совместимостью и сроком ремонта — расходами, которые облачный договор переносит на провайдера только в пределах прописанных обязательств.
Спецификация под задачу
Задача — получить от провайдера предложение на отказоустойчивое размещение 1С, которое можно сопоставить с локальной системой. Спецификацию стоит разделить на две части: фиксированную архитектуру и ресурсы, рассчитанные по измеренной нагрузке.
Минимальный состав предложения:
| Компонент | Что зафиксировать | Зачем |
|---|---|---|
| Серверы приложений 1С | Экземпляры в разных зонах доступности, vCPU и память каждого | Чтобы отказ одной зоны не остановил прикладной слой |
| Балансировка | ELB перед серверами приложений и публикации | Чтобы распределять подключения между доступными экземплярами |
| База данных | RDS Multi-AZ Master/Standby, ресурсы основного и резервного экземпляров | Чтобы база имела резерв в другой зоне |
| Хранилище базы | Объём, тип дисков, гарантированные или расчётные IOPS, запас на рост | Чтобы связать цену и производительность с нагрузкой |
| Резервные копии | CBR, состав копии, частота, срок хранения, порядок восстановления | Чтобы резервирование базы не подменяло восстановление данных |
| Сервер лицензий | Тип лицензий и ресурсы сервера | Чтобы учесть отказ от USB-ключей |
| Публикация и идентификация | Сервер публикации и OpenID-компонент, схема резервирования | Чтобы не потерять в расчёте веб-доступ и вход пользователей |
| Связь | Site-to-Site VPN или Direct Connect плюс резервный маршрут | Чтобы отказ одного канала не отрезал офис от 1С |
| Обязательства поставщика | Условия переключения и срок восстановления | Чтобы сравнивать предложения по одному результату |
Это спецификация архитектуры, но ещё не размер облачных машин. Для расчёта ресурсов поставщику нужны число одновременных пользователей, перечень и размеры баз, пиковые операции, загрузка процессора и памяти, дисковые IOPS, суточный прирост данных и срок хранения копий.
Переход к ресурсам должен быть виден в расчёте. Например, поставщик показывает измеренную нагрузку на сервер приложений, добавляет заявленный запас и получает число vCPU. Затем переводит рабочий объём баз, суточный прирост и срок хранения копий в объём хранилища. Без исходного замера и коэффициентов строку «16 vCPU и 128 ГБ» нельзя проверить.
У отказоустойчивости есть цена. Размещение компонентов в двух зонах, резервная база и второй канал увеличивают ежемесячный платёж. Если убрать их ради экономии, получится облачное размещение без той схемы высокой доступности, которую описывает Cloud.ru.
Что вынести на закупочную комиссию
Кейс EFSOL подтверждает возможность переноса 1С на PostgreSQL в отказоустойчивое облако. Ресурсы, лицензии и стоимость для своей компании считай по собственной нагрузке и предложению провайдера.
Перед решением запроси у поставщика пять вещей:
- схему всех компонентов 1С, а не только параметры базы;
- размещение прикладных серверов по зонам и базу Master/Standby;
- основной и резервный способы подключения офиса;
- схему замены аппаратных USB-лицензий;
- исходные замеры и расчёт vCPU, памяти, IOPS, хранилища и копий.
Сравнивай предложения при одинаковом составе архитектуры и одинаковых обязательствах по восстановлению. Иначе разница в цене может объясняться отсутствием второго канала, резервной базы или проверяемого бэкапа.
