Введение

Лидеры технологий утопают в  потоках новых облачных архитектур, стратегий и продуктов - все это обеспечено поставщиками и различными отраслевыми экспертами для решения всех проблем с базой данных. Этот, казалось бы, бесконечный массив предложений СУБД на базе облачных вычислений может быстро стать сбивающим с толку. Один из главных вопросов, задаваемый нашими клиентами, заключается в том, следует ли выбирать DBaaS или IaaS в качестве предпочтительной архитектуры облаков данных. Этот пост предназначен для снятия завесы двух базовых СУБД на основе облачных вычислений, предоставляя читателям наш опыт использования архитектур IaaS и DBaaS.

Одним из преимуществ работы для удаленного поставщика услуг DBA является то, что коллективные знания нашей компании не ограничены технологической реализацией одной организации. У нас есть клиенты, чьи технологические стратегии варьируются от самых передовых до устаревших.

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

Давайте продолжим наше обсуждение, узнав больше о двух основных облачных архитектурах: инфраструктура как услуга (IaaS) и платформа как услуга (PaaS). Поскольку мы говорим о системах управления базами данных, давайте использовать термин Database-as-a-Service или DBaaS для определения этой архитектуры.

У всех нас есть опыт работы с локальными системами. Мы должны строить помещения для серверов, обеспечивать отопление, охлаждение, резервную связь и мощность. Мы обязаны покупать, устанавливать и администрировать все компоненты, чтобы обеспечить самую безопасную среду для наших систем.

Затем нам необходимо купить серверное оборудование, установить его и поддерживать. Когда происходят поломки или необходимо увеличить мощность, нам нужно открыть шасси и работать с серверными компонентами. Мы добавляем процессор, память, диск - все, что нам нужно. Чтобы выполнить эти действия, нам нужно либо отключиться, либо планировать перенос системы и рабочих нагрузок на другой сервер для обеспечения доступности. Мы также покупаем и администрируем программное обеспечение OS и DB, которое нам нужно для запуска наших приложений, управляемых базой данных.

Давайте перейдем к облачным технологиям. Большинство сред IaaS и DBaaS являются многопользовательскими, что означает, что мы совместно используем архитектуру вычислений и хранения поставщика с другими клиентами. Кроме того, в зависимости от выбранной архитектуры и поставщика система будет варьироваться в зависимости от степени масштабируемости, эластичности, автоматизированных административных услуг и самообслуживания.

Архитектура, которая наиболее близка к локальным, представляет собой инфраструктуру как услугу, архитектуру, определенную в нижнем центре нашей графики. С IaaS поставщик предоставляет инфраструктуру вычислений и хранения и может предлагать некоторые уровни обслуживания системы. Клиенты имеют прямой доступ к облачной системе, которая включает как вычислительные, так и запоминающие компоненты. Подумайте об этом как о сервере, как правило, виртуальном, в облаке.

Вам не нужно создавать среду поддержки сервера, которая обеспечивает кондиционирование воздуха, свет, многочисленные источники питания, системы ИБП, генераторы и избыточные подключения к Интернету. Все эти функции предоставляются поставщиком, но клиенты IaaS будут продолжать поддерживать полное владение своим администрированием стека программного обеспечения, включая операционную систему и базу данных. Клиенты устанавливают и администрируют свое программное обеспечение по выбору на платформе Infrastructure-as-a-Service.

Важно отметить, что в зависимости от поставщика IaaS и выбранного предложения клиенты могут воспользоваться преимуществами функций поставщика, чтобы сократить время на поддержку среды. Например, Microsoft Azure предоставляет сборку, которую вы можете использовать, чтобы получить возможность запуска новой среды БД. Тем не менее, вам нужно будет адаптировать эту общую сборку для удовлетворения ваших потребностей.

Теперь, когда мы знаем, что IaaS в значительной степени является сервером в облаке, давайте перейдем к PaaS или в нашем случае DBaaS - Database-as-a-Service. Поставщики DBaaS предоставляют все преимущества среды сервера, которые предоставляют их партнеры IaaS.

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

Поставщики DBaaS также вносят изменения в свое программное обеспечение баз данных по двум причинам:

# 1 - чтобы обеспечить, работу их продукта в общей облачной среде

# 2 - чтобы использовать преимущества, обеспечиваемые облаком и архитектурой

Географическая избыточность данных может послужить примером , поскольку это позволяет клиентам использовать облако для более легкого создания систем DR и HA. Важно отметить, что, поскольку мы обсуждаем архитектуры IaaS и DBaaS, в предложениях поставщиков может быть много изменений.

Сравнение локальных архитектур, IaaS и DBaaS

Каждая среда: локальная, IaaS и DBaaS, - имеет свои сильные и слабые стороны, присущие их архитектурам.  Мы предоставили эту информацию для сравнения  сред с тремя базами данных на выбор: -  локальная, база данных, работающая на IaaS и предложение DBaaS. В каждой среде есть плюсы и минусы, преимущества и недостатки.

IaaS позволяет клиентам поддерживать более жесткий административный контроль над своей средой. Они также могут более легко использовать свои любимые внутренние сторонние продукты в системах IaaS, чем они могут с помощью DBaaS. IaaS - это просто сервер, который предоставляется вам через облако.

Многие из сторонних инструментов, включая мониторинг, безопасность, разработку приложений, аудит, могут быть сложными для интеграции в архитектуру DBaaS из-за изменений, которые производители вносят в свои системы. Все поставщики DBaaS предоставляют средства мониторинга. Некоторые поставщики, такие как Amazon, взимают дополнительную плату, если клиент хочет получить более надежное решение для мониторинга, чем то, что предлагается в их базовом пакете. В целом, средства мониторинга DBaaS не столь надежны, как и их локальные партнеры, но они очень быстро к ним подбираются.

Если поставщик DBaaS определяет, что его собственное внутреннее базовое программное обеспечение, ОС или база данных требует критической доступности, безопасности или патча производительности, у магазинов может не быть выбора по ее реализации. Если этот патч требует отключения, клиенту необходимо будет запланировать это переключение и часто до определенной даты. Предложения DBaaS позволяют клиентам более легко настраивать сложные архитектуры, такие как высокая доступность и аварийное восстановление. Все основные поставщики DBaaS предлагают избыточность геоданных.

Использование среды DBaaS для снижения затрат на оплату труда DBA

Миграция в среду DBaaS уменьшает время, которое DBA тратит на администрирование среды базы данных, но это не сводит административное время к нулю. Клиенты будут испытывать наиболее значительную экономию времени при администрировании ОС и аппаратной поддержке.

Администраторы баз данных тратят время на установку, исправление и обновление программного обеспечения СУБД, а также настройку среды и настройку и мониторинг средств технического обслуживания и резервного копирования. Многие из этих административных задач могут быть предоставлены поставщиком DBaaS в зависимости от поставщика и выбранного предложения.

Большинство времени DBA расходуется на работу в самих системах баз данных. Администраторы баз данных строят схемы, предоставляют безопасность, помогают разработчикам с SQL и процедурной настройкой программ, предоставляют советы, внедряют бизнес-логику с использованием функций базы данных, настраивают рабочие нагрузки приложений и проблемы отладки. Поставщики DBaaS не предоставляют эти услуги как часть своего базового пакета. Существует десятки административных действий, которые администраторы баз данных должны выполнять в среде DBaaS.

Важно помнить, что, хотя поставщик может предоставить механизмы и процессы для автоматизации административных действий, это также не сводит обязанности их поддержки администратором к нулю . Персоналу, возможно, потребуется настроить способны и время их выполнения. Все основные поставщики DBaaS предоставляют исправления, утилиты технического обслуживания и автоматизированные процессы резервного копирования, но именно администратор баз данных проверяет планирование, настраивает пользовательские расписания и контролирует выполнение для всех автоматизированных задач.

Все более возрастающая конкуренция на рынке DBaaS заставляет всех поставщиков максимизировать свой собственный набор функций. Постоянная инновация и интеграция новых функций, которые отличают свой продукт от других поставщиков, являются абсолютным требованием для их постоянного конкурентного выживания.

Вот какое уравнение можно вывести для конкурентоспособности DBaaS:

Новые возможности

+ Новая функциональность

+ Новые технологии

+ Новые архитектуры

 + Новые бизнес-требования

 = Повышенная сложность ИТ-поддержки

По мере того, как поставщики облачных технологий добавляют функции к их предложениям DBaaS, продукты становятся сложнее. Эти функции могут автоматизировать некоторые действия по поддержке администраторов, но на глобальном уровне администраторы баз данных с высоким уровнем технических знаний будут по-прежнему нуждаться в поддержке среды DBaaS.

Вот краткий пример. Большинство поставщиков облаков предоставляют функции, которые позволяют администраторам более легко настраивать среды HA и DR, но для этого требуется обширное знание этих технологий и бизнес-требований для настройки, внедрения, администрирования и мониторинга. Действия могут выполняться намного быстрее в средах DBaaS, чем в локальных системах, но эта основная база знаний по-прежнему необходима.

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

Влияние на существующие процедуры управления изменениями и документацию

Поскольку облачные среды отличаются от локальных систем, организациям, использующим эти новые архитектуры, может потребоваться обновить документацию и существующие процессы управления изменениями. Время и число сотрудников, , необходимые для проекта, зависит опять же от выбранной облачной архитектуры и от степени строгости процессов управления изменениями организации и требований к документации. Поскольку DBaaS администрируется гораздо больше,чем локальная архитектура, она будет иметь большее влияние, чем IaaS, которая является просто сервером в облаке.

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

Объем необходимых изменений документации будет зависеть от объема и глубины документации, необходимой вашей конкретной организации в качестве наилучшей практики. Еще раз, это больше влияет на DBaaS.

Влияние на существующие инструменты

Магазины, перемещающиеся в среду DBaaS, должны будут идентифицировать все инструменты сборки, администрирования, мониторинга и доступа, которые они используют для взаимодействия с их локальными базами данных. Во всех магазинах обычно есть несколько «обязательных» инструментов, которые часто используются. Администраторам необходимо будет определить, какие из существующих инструментов их организации будут продолжать работать в облаке, а какие - нет. Популярность облака побуждает большинство поставщиков программных продуктов убедиться, что их предложения работают с облачными системами, но это не то, что нужно воспринимать как нечто само собой разумеющееся.

Наша рекомендация заключается в создании списка и проверке того, что предпочтительные инструменты будут продолжать работать с облачными версиями базы данных. Большинство инструментов будут работать с IaaS (помните, что это просто сервер в облаке), но для DBaaS магазины должны выполнить оценку, чтобы определить, могут ли они интегрироваться, и уровень усилий, необходимых для их интеграции.

Сравнение локальных баз данных с IaaS и DBaaS

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

Давайте сравним локальный SQL Server с двумя ведущими поставщиками облачных решений, Amazon и Microsoft, оба из которых предлагают DBaaS SQL Server. Предложение Amazon SQL Server DBaaS не поддерживает PolyBase, расширяет базу данных, производит резервное копирование в хранилище blob и импорт данных в базу данных msdb. Кроме того, администраторы не могут переименовывать базу данных, если она используется в развертывании Mirroring Amazon, и она не позволяет клиентам увеличивать объем хранилища в базе данных SQL Server. Если заказчику необходимо увеличить хранилище экземпляра SQL Server DB, он должен осуществить резервное копирование базы данных, создать новый экземпляр DB с увеличенным хранилищем и затем восстановить базы данных в новый экземпляр DB.

Он не поддерживает SSIS, SSAS или SSRS и не имеет ролей безопасности на сервере уровня SQL Server для sysadmin, serveradmin, securityadmin, dbcreator и bulkadmin. Он также не поддерживает почту базы данных, планы обслуживания, распределенные запросы, доставку журналов, изменение данных, проверку SQL Server или массовую вставку.

Как насчет Azure SQL DB и локального SQL Server? Это два продукта DB, предлагаемые одним и тем же поставщиком. Предложение Azure DBaaS от Microsoft не поддерживает привязку к базам данных, операции резервного копирования и восстановления, изменения сбора данных, почту базы данных, зеркалирование базы данных, моментальные снимки базы данных, расширенные хранимые процедуры, файловые потоки, связанные серверы, доставку журналов, регулятор ресурсов, профилировщик, SSAS или SSRS.

Теперь вместо зеркалирования базы данных и доставки журналов он обеспечивает Active Geodata-Replication, что может быть лучшей альтернативой для многих клиентов, но это другое! Мы не утверждаем, что эти среды не так эффективны, как локальные, но у них разные функции, о которых мы все должны знать.

В заключении

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

В дополнение к выбору наиболее подходящей облачной архитектуры для конкретного приложения, управляемого базой данных, существует множество других нюансов, которые необходимо оценить при переносе в облако. Вам нужно будет передавать данные в среду облачной базы данных и из нее? Сколько данных? Переносится ли база данных в зависимости от данных из других локальных систем? Как вы обеспечите безопасность базы данных и передачи данных? Какими уровнями изменений вы довольны? Ограничены ли вы временем простоя для миграции или требуется ли «перевернуть процесс переключения»? Это общий перечень вопросов. Целая статья может быть написана по всем вопросам, которые необходимо учитывать и оценивать при переносе на облачные архитектуры.

No Comments