Стремясь к более быстрому, более масштабируемому развертыванию баз данных и к снижению затрат, организации все чаще обращаются к платформам «СУБД как сервис» (database-as-a-service, DBaaS). Наличие множества продуктов и инструментов делает перенос СУБД в облака еще более привлекательным.
Однако имеется распространенный набор ложных концепций и упущений, создающих трудности в процессе миграции на платформы DBaaS. В основном это касается организаций, впервые приступающих к миграции в облака. Но не застрахованы от них и те, кто уже перенес туда несколько СУБД из своих ЦОДов.
Если идентифицировать и преодолевать проблемы на ранних этапах жизненного цикла миграции, можно минимизировать их последствия и уменьшить количество сюрпризов после запуска новой системы DBaaS. Вот десять основных ошибок, которые допускают ИТ-подразделения в процессе переноса СУБД в облака.
1. Недооценка затрат на миграцию и техническую поддержку
Платформы DBaaS не являются новыми продуктами. Они представляют собой новые архитектуры. И как все новые архитектуры они изменяют то, как ваша организация создает свои системы, получает к ним доступ, администрирует их, ведет их мониторинг и обеспечивает защиту. Необходимо предусмотреть затраты на обучение, документацию и организационные изменения. Ниже мы еще вернемся к последствиям для бюджета.
2. Недооценка организационных и процедурных изменений
У сотрудников появятся новые обязанности. Для поддержки платформ DBaaS, возможно, потребуется создать новые должности. Поскольку DBaaS сильно отличается от тех СУБД, которые развертываются в ЦОДах, придется обновить процессы управления изменениями и документацию по технической поддержке. Сколько времени это займет, зависит от того, насколько строги существующие процессы управления изменениями, документация и требования к аудиту.
3. Отсутствие необходимого тренинга для персонала
Администраторам необходимо будет изучить, как предоставлять доступ к платформе DBaaS, администрировать ее, осуществлять тонкую настройку, обеспечивать безопасность, вести мониторинг и восстанавливать после сбоев. Это базовые положения хорошего администрирования, применимые ко всем СУБД. Но ваши администраторы будут применять другие инструменты, утилиты и команды.
4. Непонимание модели затрат производителя
Вы не покупаете DBaaS, вы арендуете. Арендная плата будет зависеть от арендодателя, продукта, конфигурации и решаемых задач. Каждый арендодатель рассчитывает стоимость аренды по-своему. Некоторые модели ценообразования очень сложны. Чтобы точно определить размеры платежей, необходимо понимать, как арендодатель калькулирует свои затраты.
5. Некорректное определение размеров DBaaS
До начала миграции в облако администраторам следует измерить, сколько ресурсов потребляет СУБД в ЦОДе, чтобы сконфигурировать уровни производительности DBaaS и оценить ежемесячные платежи. Обычно основными ресурсами считаются процессоры, ОЗУ, дисковые системы, системы ввода-вывода, входящие и исходящие потоки данных.
6. Игнорирование несоответствия функций СУБД в ЦОДе и в облаке
Между СУБД в ЦОДе и в облаке могут быть значительные различия. Провайдеры DBaaS часто предоставляют сравнение их функций, обходные пути решения проблем и описания «аналогичных» функций облачных СУБД. Некоторые несоответствия функций очень трудно преодолеть.
7. Необходимо убедиться, что используемый набор инструментов будет работать с DBaaS
Вероятно, ваши любимые инструменты, которые были разработаны в вашей компании или приобретены у другой, потребуют модификации для получения доступа к платформе DBaaS. В некоторых случаях более привлекательной с точки зрения финансов будет покупка новых инструментов, которые изначально предназначены для работы с облаками.
8. Превращение СУБД в остров
Распространенная ошибка — не проверить, как СУБД взаимодействует с другими системами. Какой объем данных необходимо передавать в облако и в обратном направлении при повседневных операциях? Содержит ли СУБД ссылки на базы данных в ЦОДе? Передача большого объема данных в облако и из облака может быть сопряжена с трудностями, особенно при наличии жестких ограничений по времени.
9. Составление неадекватных планов тестирования и миграции
Во многих случаях требуется анализ на протяжении всего жизненного цикла миграции СУБД. Как и при любом переходе на новую архитектуру, необходимо составить хорошо продуманный детальный список преобразований. Это не та архитектура, на которую можно перейти без всестороннего анализа и планирования.
10. Неудачные аудиты после миграции производственной системы
Платформы DBaaS не предоставляют пользователям доступ к своей базовой архитектуре. В результате организации, соблюдающие требования регуляторов, часто обнаруживают, что их платформы DBaaS не предоставляют данные, необходимые аудиторам для проверки соответствия систем целям аудиторского контроля. При планировании проекта следует узнать у аудиторов, какие доказательства соблюдения требований регуляторов им необходимы.
Источник: ITWeek
