Репликацию можно использовать для повышения уровня масштабируемости и надежности системы. Один из протоколов обеспечения надежности на основе репликации был разработан Oracle в составе продукта Oracle RAC [18].
Серверы баз данных могут работать на дешевом компьютерном оборудовании. В частности, серверы-сателлиты могут работать на дешевых стандартных машинах. Кроме того, архитектура с рис. 3 может хорошо масштабироваться при возрастании и сокращении рабочей нагрузки, если рабочая нагрузка в основном состоит из запросов на чтение данных. При сокращении рабочей нагрузки в любой момент времени любой сервер-сателлит может быть выведен из конфигурации системы. Если рабочая нагрузка возрастает, то при добавлении сервера-сателлита требуется скопировать в него базу данных с мастер-сервера (или какого-либо сервера-сателлита). Как показано в разд. 6, при наличии рабочих нагрузок с большим числом операций обновления мастер-сервер может стать узким местом системы.
На рис. 3 показано, каким образом в архитектуре систем баз данных может быть использована репликация. Опять же, эта идея проста и активно изучалась в прошлом. Как и в случае разделения, имеется несколько серверов баз данных. Каждый сервер баз данных управляет некоторой копией всей базы данных (или раздела базы данных, если репликация объединяется с разделением). При этом допустимо множество вариантов. На рис. 3 демонстрируется вариант, в котором репликация является прозрачной, и устройства хранения данных присоединены к серверам баз данных. Наиболее важным аспектом схемы репликации является механизм поддержания реплик в согласованном состоянии. Наиболее известен протокол ROWA (read-once, write all – чтение из любой реплики, запись во все реплики), основанный на поддержке эталонной копии (Master copy) [20]. Если репликация не является прозрачной, приложения направляют все запросы на обновление данных серверу баз данных, который управляет эталонной копией, а этот сервер (мастер-сервер, Master server) передает все обновления серверам-сателлитам после того, как эти обновления удается успешно зафиксировать. Приложения могут направлять запросы на чтение данных любому серверу баз данных (мастеру или сателлиту). Если репликация является прозрачной, то запросы автоматически направляются мастеру или сателлиту. На рис. 3 показана прозрачная репликация. Мастер сервер окрашен красным цветом (в левом нижнем углу рисунка).
Рис. 3. Репликация
Разделение данных и архитектура, представленная на рис. 2, обеспечивают эффективный путь к раскрытию потенциала cloud computing. Серверы баз данных могут функционировать на дешевых машинах, что приводит к использованию большого числа машин, каждая из которых работает с данными довольно небольшого объема, чтобы иметь возможность выдержать нагрузку. Однако у разделения имеются ограничения масштабируемости при наличии колеблющейся рабочей нагрузки: при увеличении или уменьшении числа машин в качестве реакции на возрастание (или снижение) интенсивности рабочей нагрузки запросов/операций обновления требуется перераспределение данных, т.е. пересылка данных между машинами. Чтобы добиться улучшенной масштабируемости и отказоустойчивости, требуется объеденить разделение с репликацией.
По отношению к cloud computing архитектура с рис. 2 была впервые применена в Force.com – платформе, на которой выполнялось приложение Salesforce, и которая была открыта для выполнения заказных приложений. В Force.com ключом разделения является арендатор (tenant). Другими словами, данные распределяются в зависимости от приложения, которое генерирует эти данные и владеет ими. Разделение охватывает весь серверный стек приложений, включая Web-сервер и сервер приложений. Все запросы, направляемые к одному арендатору, обрабатываются одними и теми же Web-сервером, сервером приложений и сервером баз данных. В результате Force.com настраивается при увеличении числа приложений. Однако архитектура Force.com не поддерживает масштабируемость одного приложения сверх возможностей одного сервера баз данных. Поэтому мы не включили в свое исследование эксперименты с этой платформой. Мы полагаем, что Force.com продемонстрировала бы в наших экспериментах поведение, схожее с поведением вариантов, основанных на классической архитектуре.
Варианты архитектуры, представленной на рис. 2, могут различаться не только схемами разделения. Во-первых, разделение может быть прозрачным или видимым для программиста приложений (очевидно, что предпочтительным является прозрачное разделение). Во-вторых, устройства хранения данных могут подключаться к машине, на которой работает сервер баз данных, или быть от нее отделены, например, в сеть устройств хранения данных (как показано на рис. 1). На рис. 2 представлен вариант, в котором доступ к распределенной базе данных является прозрачным, и устройства хранения данных подключаются к каждому серверу баз данных. На практике можно обнаружить использование и других вариантов (разд. 4).
На рис. 2 показано, как можно приспособить классическую архитектуру систем баз данных к использованию разделения данных. Идея проста: вместо того чтобы нагрузить один сервер баз данных управлением всей базой данных целиком, мы логически разделяем эту базу данных и обязываем управлять каждым разделом отдельный сервер баз данных. В литературе баз данных исследовалось много схем разделения; например, вертикальное и горизонтальное разделение, циклическое разделение (round-robin partitioning), разделение с хэшированием (hashing partitioning), разделение по диапазону значений (range partitioning) [8]. Все эти подходы работоспособны и могут быть применены к управлению данными "в облаках".
Рис. 2. Разделение
Потенциальным узким местом классической архитектуры является сервер баз данных. Если сервер баз данных становится перегруженным, единственным выходом из положения является покупка более мощной машины. Машины, используемые для поддержки серверов баз данных, обычно стоят недешево, поскольку они должны уметь справляться с пиковой рабочей нагрузкой. Поэтому классической архитектуре с рис. 1 свойственны ограничения по отношению и к масштабируемости, и к стоимости – двум важным целям "облачных" вычислений. В следующих подразделах этого раздела рассматриваются архитектуры, выбираемыми разработчиками "облачных" служб для преодоления этих ограничений на уровне сервера баз данных.
Классическая архитектура обеспечивает ряд важных преимуществ. Во-первых, она позволяет использовать на всех уровнях компоненты, являющиеся "лучшими в своем классе" "best-of-breed"). В результате в расчете на каждый из этих уровней образовался жизнеспособный рынок конкурирующих продуктов. Во-вторых, классическая архитектура позволяет добиться масштабируемости и эластичности на уровнях хранения данных и серверов Web и приложений. Например, если требуется скорректировать пропускную способность приложения в соответствии с увеличившейся активностью пользователей, то можно легко увеличить число машин на уровне серверов Web и приложений, чтобы справиться с повысившейся рабочей нагрузкой. Аналогичным образом, при снижении рабочей нагрузки некоторые машины на этом уровне можно отключить или использовать для других целей. На уровне хранения данных можно увеличивать или уменьшать число машин (или дисков) для повышения пропускной способности системы хранения при возрастании рабочей нагрузки и/или для решения проблем, связанных с изменением размеров базы данных.
На рис. 1 показана классическая архитектура, используемая в большинстве сегодняшних приложений баз данных (например, в SAP R/3 [5]). Запросы от клиентов направляются балансировщиком нагрузки (изображенным на рис. 1 в виде карусели) в одну из доступных машин, на которой выполняются Web-сервер и сервер приложений. Web-сервер обрабатывает (HTTP-) запросы, поступающие от клиентов, а сервер приложений выполняет указанную логику приложения с использованием, например, языков Java или C# со встроенным SQL (или LINQ, или какого-либо другого языка программирования баз данных). Операторы встроенного SQL доставляются на сервер баз данных, который интерпретирует запрос, возвращает результат и, возможно, изменяет базу данных. Для обеспечения персистентности сервер баз данных сохраняет все данные и журналы на устройствах хранения данных. Интерфейс между сервером баз данных и системой хранения данных предполагает пересылку физических блоков данных (например, блоков размером в 64 килобайта) с использованием запросов get и put. В традиционных системах хранения данных используются диски, подключаемые локально к машине, на которой работает сервер баз данных, или объединяемые в сеть устройства хранения данных (storage area network, SAN). На рис. 1 демонстрируется вариант архитектуры, в котором система хранения данных отделена от сервера баз данных (т.е. SAN). Вместо традиционных вращающихся дисков в системах хранения данных следующего поколения, возможно, будут использоваться твердотельные диски (solid-state disk), основная память или комбинация разных носителей.
Рис. 1. Классическая архитектура системы баз данных
В этом разделе заново пересматриваются архитектуры распределенных систем баз данных, используемые в сегодняшних "облачных" вычислениях. В качестве отправной точки описывается классическая многозвенная архитектура приложений баз данных. Затем обсуждаются четыре разновидности этой арихитектуры. Эти разновидности основаны на простых принципах распределенных баз данных – приниципах репликации, разделения и кэширования. Интересным аспектом является то, как эти понятия оформляются и применяются в коммерческих "облачных" службах (разд. 4).
3. Архитектуры распределенных систем баз данных
Перевод: Сергей Кузнецов
Дональд Коссман, Тим Краска и Саймон Лоузинг
Анализ альтернативных архитектур управления транзакциями в "облачной" среде
Море(!) аналитической информации!
Анализ альтернативных архитектур управления транзакциями в "облачной" среде
Комментариев нет:
Отправить комментарий