Windows Azure предлагает как хранилище NoSQL, так и реляционное хранилище SQL. Хранилищем NoSQL являются, например, таблицы Windows Azure (ключ\значение) или BLOB-объекты (двоичные данные, такие как фотографии, видео, документы и т. д.).
Реляционное хранилище включает в себя База данных SQL (ранее SQL Azure ).
Пост подготовлен на основе статьи Внутри базы данных SQL Windows Azure , который я решил разделить на две части.
В первой части я предоставлю информацию об архитектуре базы данных SQL и о том, как обеспечивается высокая доступность (обнаружение сбоев, реконфигурация).
Во второй части я расскажу о масштабируемости (контроле производительности, балансировке нагрузки), а также дам рекомендации для разработчиков.
Обзор архитектуры базы данных SQL
База данных SQL общий облачную базу данных, можно сказать, что это База данных как услуга (DaaS).В Центры обработки данных Майкрософт SQL-серверы установлены О тыс.
танков построены на базе штатного оборудования.
Каждый SQL-сервер в дата-центре содержит несколько разных клиентских баз данных (логических баз данных), т.е.
получается общий режим.
Для доступа к данным используется автоматическая балансировка нагрузки и маршрутизация сетевых подключений.
Стоит отметить, что физически или фактически данные не хранятся в одной базе данных, а тиражируются .
Данные реплицируются в трех базах данных SQL Server, распределенных по трем физическим серверам в одном дата-центре: одной основной и двум дополнительным репликам.
Все операции чтения и записи выполняются в первичной реплике, а любые изменения асинхронно реплицируются во вторичные реплики.
Эти реплики обеспечивают высокую доступность баз данных SQL.
Большинство центров обработки данных Microsoft содержат сотни компьютеров с сотнями экземпляров SQL Server, на которых размещены реплики базы данных SQL.
Крайне маловероятно, что первичная и вторичная реплики базы данных SQL будут храниться на одних и тех же компьютерах.
Логический сервер — это сервер базы данных SQL, который вы видите на веб-портале управления Windows Azure. Служба шлюза Шлюз базы данных SQL действует как прокси-сервер, перенаправляя запросы потока табличных данных (TDS) на логический сервер.
Шлюз базы данных SQL — это граница безопасности, которая обеспечивает проверку учетных данных, соблюдение правил брандмауэра и защиту от атак типа «отказ в обслуживании» на экземпляры SQL Server за шлюзом.
Шлюз состоит из нескольких компьютеров, каждый из которых принимает запросы на сетевое подключение от клиентов, проверяет информацию о соединении и передает запрос потока табличных данных на соответствующий физический сервер, в зависимости от имени базы данных, указанного в соединении.
Физическое распределение баз данных, являющихся частью одного и того же логического экземпляра SQL Server, означает, что каждое сетевое соединение привязано к одной базе данных, а не к одному экземпляру SQL Server.
Если бы для подключения использовалась команда USE, поток данных таблицы пришлось бы перенаправить на совершенно другой физический компьютер в центре обработки данных.
По этой причине команда USE не поддерживается для подключений к базе данных SQL. 
Топология сети
Приложение использует клиентский уровень для прямого взаимодействия с базой данных SQL. Клиентский уровень может располагаться в локальном центре обработки данных или размещаться в Windows Azure. Поддерживаются все протоколы, создающие потоки табличных данных для передачи по сети.Вы можете использовать знакомые инструменты и библиотеки для создания клиентских приложений, использующих данные в облаке.
Уровень обслуживания
Уровень служб состоит из компьютеров, на которых размещаются службы шлюза, обеспечивающие маршрутизацию, подготовку, измерение и выставление счетов.Эти сервисы поддерживаются четырьмя группами компьютеров.
Интерфейсный кластер содержит компьютеры физического шлюза.
Компьютеры прикладного уровня авторизуют запросы к серверу и базе данных и управляют выставлением счетов.
Компьютеры сервисной платформы контролируют и управляют работоспособностью экземпляров SQL Server в центре обработки данных.
Компьютеры в основном кластере отслеживают, какие реплики каких баз данных физически существуют в каждом экземпляре SQL Server в центре обработки данных.
Пронумерованные строки рабочего процесса на рисунке отражают процедуру проверки и создания клиентского подключения:
- Шлюз во внешнем кластере, который получает запрос на новое соединение входящего потока табличных данных (TDS), может установить соединение с клиентом.
Парсер с минимальным набором поддерживаемых функций проверяет валидность полученной команды для передачи в базу данных.
Такие команды, как CREATE DATABASE, не разрешены, поскольку они должны обрабатываться на уровне приложения.
- Шлюз выполняет SSL-подтверждение для клиента.
Если клиент отказывается использовать SSL, шлюз разрывает соединение.
Необходимо обеспечить полное шифрование трафика.
Анализатор протокола также включает защиту от отказа в обслуживании, которая отслеживает запросы с IP-адресов.
Если с IP-адреса или диапазона адресов получено чрезмерное количество запросов, последующие попытки подключения с этих адресов будут отклонены.
- Имя сервера и учетные данные для входа, предоставленные пользователем, должны быть проверены.
Проверка уровня брандмауэра гарантирует, что соединения выполняются только с IP-адресами в указанных диапазонах.
- После проверки сервера основной кластер сопоставляет имя базы данных, используемое клиентом, с именем внутренней базы данных.
Первичный кластер — это совокупность компьютеров, обрабатывающих картографическую информацию.
При работе в базе данных SQL понятие раздела имеет совершенно иной смысл, чем при работе с локальными экземплярами SQL Server.
В среде базы данных SQL раздел является частью базы данных SQL Server в центре обработки данных, которая сопоставляется с одной базой данных SQL.
Например, на рисунке каждая база данных содержит три раздела, поскольку каждый раздел содержит три базы данных SQL. - Как только база данных обнаружена, имя пользователя аутентифицируется; если проверка не удалась, соединение разрывается.
Шлюз проверяет наличие базы данных, к которой хочет подключиться пользователь.
- Новое подключение можно выполнить после проверки всех параметров подключения.
- Новое соединение устанавливается непосредственно между компьютером пользователя и внутренним серверным узлом.
- После установления соединения шлюз действует как прокси-сервер для пакетов, передаваемых между клиентом и платформой обработки данных.
Уровень платформы
Уровень платформы состоит из компьютеров, на которых в центре обработки данных размещаются физические базы данных SQL Server. Эти компьютеры называются узлами данных.На рисунке показана внутренняя организация узлов данных.
Каждый узел данных состоит из одного экземпляра SQL Server. Каждый из этих экземпляров имеет одну пользовательскую базу данных, разделенную на разделы.
Каждый раздел содержит одну клиентскую базу данных SQL, представленную в виде первичной или вторичной реплики.
Типичная база данных SQL Server может содержать до 650 разделов.
Эти базы данных, размещенные в центре обработки данных, управляются так же, как и локальные базы данных SQL Server. Разница лишь в том, что регулярное обслуживание и резервное копирование выполняются специалистами дата-центра.
Все базы данных, размещенные на узле данных, используют один и тот же журнальный файл .
Это повышает производительность журналирования за счет использования последовательных операций массового ввода-вывода.
В отличие от локальных баз данных, журналы базы данных SQL хранятся в заранее выделенном и обнуленном дисковом пространстве.
Это позволяет избежать пауз в записи, когда размер файла журнала автоматически увеличивается.
Еще одно отличие управления журналами в базе данных SQL состоит в том, что для этого требуется фиксация кворума .
Это означает, что первичная реплика и по крайней мере одна из вторичных реплик должны подтвердить, что файлы журнала были записаны, прежде чем транзакция будет считаться зафиксированной.
На рисунке показано, что каждый из компьютеров узлов данных содержит набор процессов, также называемых фабрикой.
Структурные процессы служат для решения следующих задач:
- Обнаружение сбоев: мониторинг доступности первичных или вторичных реплик; если они станут недоступны, можно запустить агент реконфигурации.
- Агент реконфигурации: управляет повторным созданием первичных или вторичных реплик после сбоя узла.
- Местоположение диспетчера разделов: обеспечивает отправку сообщений в диспетчер разделов.
- Регулирование нагрузки ядра: предотвращает монополизацию ресурсов хоста логическим сервером или превышение его физических ограничений.
- Кольцевая топология: управляет кластером компьютеров, объединенных в логическое кольцо; У каждого компьютера есть два соседа, которые могут обнаружить его сбой.
Обеспечение высокой доступности базы данных SQL
Платформа базы данных Microsoft SQL обеспечивает доступность базы данных подписчиков на уровне 99,9%.Это достигается за счет использования потребительского оборудования, позволяющего легко и быстро заменить компьютер или диск в случае сбоя, а также за счет управления репликами каждой из баз данных SQL (поддерживаются одна первичная и две вторичные реплики).
Обнаружение сбоев
Необходимо выявлять не только случаи полного выхода из строя компьютеров, но и тенденции медленного снижения производительности компьютеров и нарушения обмена данными с ними.Описанная выше концепция фиксации кворума решает эти проблемы.
Во-первых, транзакция не считается зафиксированной, если первичная реплика и хотя бы одна вторичная реплика не подтвердят, что транзакция зарегистрирована.
Во-вторых, если первичная и вторичная реплики подтверждают успешную запись, могут быть обнаружены небольшие сбои, которые не препятствуют фиксации транзакции, но могут привести к серьезным проблемам.
Реконфигурация
Процедура замены поврежденных реплик называется реконфигурация .
Реконфигурация может потребоваться в случае сбоя оборудования или сбоя операционной системы, а также в случае возникновения проблемы с экземпляром SQL Server. Реконфигурация также используется при обновлении операционной системы, SQL Server или платформы базы данных SQL.
За исправностью каждого узла следят шесть аналогичных узлов, расположенных в разных стойках.
Эти узлы называются соседями.
Сбой обнаруживается одним из соседей вышедшего из строя узла.
Для каждой базы данных, хранившей реплику на вышедшем из строя узле, выполняется процедура реконфигурации.
Каждый компьютер содержит реплики сотен баз данных SQL, некоторые из которых являются первичными, а некоторые — вторичными.
Поэтому при выходе узла из строя выполняются сотни операций по реконфигурации.
При обработке сотен ошибок, вызванных сбоем узла, приоритезация не используется.
Менеджер разделов случайным образом выбирает реплику для обработки, после завершения операций над ней выбирает следующую и так до тех пор, пока не будут обработаны все реплики с вышедшего из строя узла.
Если узел отключается из-за перезагрузки, это считается чистым сбоем, поскольку соседи узла получают сообщение об исключении.
Другой возможный вариант — прекратить связь с компьютером по неизвестной причине при обнаружении неустановленной ошибки.
В данном случае применяется арбитражная процедура , позволяющий достоверно определить факт отказа узла.
Помимо определения отказа отдельной реплики, система выявляет и устраняет последствия отказов целых узлов.
Узел состоит из целого экземпляра SQL Server с несколькими разделами, содержащими реплики до 650 различных баз данных.
Некоторые реплики являются основными, другие – дополнительными.
В случае сбоя узла каждая из затронутых баз данных подвергается процедуре, описанной ранее.
Для некоторых баз данных с неудачными первичными репликами в процессе арбитража выбирается новая первичная реплика из существующих вторичных реплик, а для других баз данных с неудачными вторичными репликами создается новая вторичная реплика.
Большинство реплик базы данных SQL должны подтвердить фиксацию.
В настоящее время пользовательские базы данных поддерживают три реплики.
Таким образом, для фиксации кворума реплики требуется подтверждение транзакции двумя другими репликами.
Хранилище метаданных, включенное в компоненты Data Center Gateway, поддерживает пять реплик.
Для завершения фиксации кворума требуется три подтверждения.
Первичному кластеру, который поддерживает семь реплик, требуется подтверждение от четырех из них для совершения транзакции.
Информацию основного кластера можно восстановить, даже если все семь реплик выйдут из строя.
Существуют механизмы автоматического восстановления основного кластера в случае таких масштабных сбоев.
Первичная реплика не работает Все операции чтения и записи сначала выполняются на первичной реплике.
Таким образом, сбой первичной реплики обнаруживается немедленно и препятствует продолжению дальнейшей работы.
При перенастройке в случае сбоя первичной реплики менеджер разделов выбирает одну из вторичных реплик и назначает ее первичной.
Обычно в качестве новой первичной реплики выбирается вторичная реплика на узле с наименьшей рабочей нагрузкой.
Процесс присвоения статуса первичной реплике дополнительной реплике не приводит к простою базы данных и незаметен для большинства пользователей.
Шлюз отправит сообщение об отключении клиентскому приложению, после чего приложение должно немедленно попытаться повторно подключиться.
Распространение информации о новой первичной реплике на все серверы шлюза может занять до 30 секунд. Поэтому рекомендуется повторить попытку подключения несколько раз, делая небольшие перерывы после каждой неудачной попытки.
Дополнительный сбой реплики Если дополнительная реплика выйдет из строя, в базе данных останется только две реплики для фиксации кворума.
Процедура реконфигурации аналогична процедуре, которая выполняется после выхода из строя первичной реплики, когда статус одной из дополнительных реплик повышается до статуса первичной.
В обоих случаях остается только одна дополнительная реплика.
После небольшого ожидания диспетчер разделов пытается определить, является ли сбой постоянным, чтобы создать новую дополнительную реплику.
В некоторых случаях, например при сбое или обновлении операционной системы, может быть очевиден сбой дополнительной реплики.
Отказ вторичной реплики на вышедшем из строя узле может быть только временным.
Поэтому мгновенного создания новой реплики не происходит. Если вторичная реплика снова подключается к сети, выполняются команды проверки данных (проверка диска и т. д.), чтобы подтвердить работоспособность реплики.
Если реплика не работает более двух часов, менеджер разделов приступает к созданию новой реплики для ее замены.
В некоторых случаях такое фиксированное время ожидания не является оптимальным решением, например, когда компьютер выходит из строя из-за неустранимого аппаратного сбоя.
Новые выпуски платформы базы данных SQL могут включать в себя функции обнаружения различных типов сбоев реплик, а также возможность более быстрого восстановления после неисправимых сбоев.
В случае возникновения невосстановимого сбоя узла для создания новой дополнительной реплики выбирается один из компьютеров кластера, имеющий достаточное дисковое пространство и запас производительности процессора.
Этот компьютер используется для размещения новой дополнительной реплики.
База данных копируется из первичной реплики, затем эта копия подключается к существующей конфигурации.
Время, необходимое для копирования всего содержимого базы данных, является ограничивающим фактором для максимального размера управляемых баз данных SQL.
Все компьютеры в дата-центре представляют собой потребительские вычислительные системы со средним уровнем производительности и качества комплектующих.
На момент написания — 32 ГБ ОЗУ, восьмиядерный процессор и 12 дисков.
Стоимость такой системы составила около $3500. Экономичная и доступная конфигурация позволяет легко и быстро заменить компьютеры в случае фатальных сбоев.
Среда Windows Azure использует то же потребительское оборудование.
Это делает все компьютеры в центре обработки данных взаимозаменяемыми, независимо от того, используются ли они для поддержки базы данных SQL или Windows Azure.
В общей сложности распределение реплик базы данных по различным серверам и эффективные алгоритмы присвоения дополнительным репликам статуса первичных гарантируют доступность даже в случае одновременного выхода из строя 15% всех компьютеров в дата-центре.
То есть, если до 15% всех компьютеров выйдут из строя, уровень поддерживаемой рабочей нагрузки не снизится.
На этом история про SQL Database не заканчивается, будет продолжение (есть продолжение ).
ПС.
Если кому-то понравилась заглавная картинка, вот ссылка на большую.
плакат .
Теги: #sql #Microsoft SQL Server #windows azure #sql azure
-
Обзор Sony Vaio Vpcf11M1E/H
19 Dec, 24 -
Разработка Круговых Интерфейсов
19 Dec, 24 -
Навигатор Для Бесплатных Иконок
19 Dec, 24 -
С Днём Рождения, Рунет
19 Dec, 24 -
Pci Экспресс 2.0
19 Dec, 24
