Управление базами данных в облачных сервисах

Наиболее сложным аспектом управления облачной инфраструктурой является обработка постоянных данных (persistent data). Постоянными данными считается вся информация, которая в обязательном порядке должна сохраниться при разрушении вашей облачной среды. Поскольку вы с легкостью можете восстановить операционную систему, приложения и простые конфигурационные файлы, вся эта информация постоянными данными не считается. Таким образом, к постоянным данным относятся те данные, которые не могут быть восстановлены так просто. Если вы следуете моим рекомендациям, то эти данные должны "жить" в движке вашей базы данных.

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

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

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

ПРИМЕЧАНИЕ

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

Объединение в кластеры или репликация?

Наиболее эффективным механизмом, позволяющим избежать повреждения баз данных, является применение возможностей движка базы данных, поддерживаю-

щего возможности истинной кластеризации (true clustering). В кластерной среде управления базами данных множество серверов баз данных действуют совместно как единый сервер базы данных. Механизмы реализации этого процесса зависят от движка базы данных и для разных движков разнятся, но результат заключается в том, что транзакция, подтвержденная в кластере, "переживет" отказ любого из одиночных узлов, и целостность данных будет сохранена в полном объеме. На практике клиенты базы данных никогда даже не узнают о том, что какой-то из узлов в какой-то момент времени отказал, и смогут продолжать работу, как ни в чем не бывало.

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

± Если только в вашей команде нет опытных специалистов-экспертов в области баз данных, вам не следует даже рассматривать развертывание кластерной базы данных.

± Поставщики кластеризованных баз данных часто требуют от клиентов оплаты более дорогих лицензий, чем при покупке обычных систем управления базами данных (DBMS), не поддерживающих кластерную обработку. Даже если вы используете возможности по кластеризации MySQL, вам уже потребуется платить за то, чтобы пять экземпляров эффективно работали в качестве кластера.

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

ВНИМАНИЕ!

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

Альтернативой кластерной обработке является репликация. Инфраструктура системы управления базами данных, основанная на репликации, обычно подразумевает наличие главного сервера баз данных (database master). Клиентские приложения выполняют транзакции записи на сервере главной базы данных. Затем успешные транзакции реплицируются на подчиненные серверы баз данных (database slaves).

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

± Обычно репликация намного проще в реализации.

± Репликация не требует очень большого количества серверов и дорогих лицензий.

ВНИМАНИЕ!

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

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

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

Источник: Риз Дж., Облачные вычисления: Пер. с англ. — СПб.: БХВ-Петербург, 2011. — 288 с.: ил.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете промотать до конца и оставить ответ. Pinging в настоящее время не допускается.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100