Русский
Русский
English
Статистика
Реклама

Масштабирование базы данных. Microsoft AlwaysOn

Привет. Меня зовут Тигран Петросян, я ведущий инженер по технической поддержке Docsvision, и сегодня расскажу о применении технологии MS SQL AlwaysOn. Это вторая статья из мини-серии Масштабируемость системы ECM на предприятии, в которой первая статья моего коллеги была посвящена технологии масштабирования поиска Elasticsearch.

Оба материала могут быть интересны не только тем, кто работает с Docsvision, но и всем, интересующимся технологиями масштабирования.

Пара слов о том, почему мы об этом говорим


Последняя версия СЭД/ECM платформы Docsvision, разработкой которой мы занимаемся, отличается принципиально от предыдущих версий своей модульной архитектурой. Было важно обеспечить возможность масштабировать систему (причём практически неограниченно) с сохранением скорости работы. Одна из технологий, положенных в основу новых возможностей платформы, MS SQL AlwaysOn.

Мои коллеги уже рассказывали о технологиях масштабирования, положенных в основу новых возможностей платформы: есть серия из 4-х мини-вебинаров на YouTube, серия из 3-х статей на Medium (статья 1, статья 2, а статья 3 как раз посвящена теме масштабирования БД). В этих материалах более чётко обозначено, какие проблемы мы решали и чего достигли в их решении.
Я же рассмотрю одну конкретную функцию MS SQL AlwaysOn, повышающую надёжность и производительность сервера БД.

image
Рис. 1. Сегодня архитектура платформы Docsvision выглядит так.

Масштабирование сервиса баз данных. MS SQL AlwaysOn


В инструменты повышения производительности и масштабирования сервиса базы данных нашей платформы Docsvision вошла возможность создания кластеров серверов БД. Эту возможность обеспечивает технология MS SQL AlwaysOn.

Группы доступности AlwaysOn в рамках БД Docsvision может выполнять сразу две задачи:
  • Высокий уровень доступности обеспечивает бесперебойную работу системы;
  • Нагрузка по чтению из БД частично выполняется на репликах.

Принцип работы режима Always On заключается в создании кластера серверов, среди которых выбирается:
  • Master-сервер основной сервер, который фиксирует все изменения в системе (чтение, запись);
  • Slave-сервер репликационный сервер, который дублирует все изменения в системе, но доступен только для чтения. На каждом репликационном сервере хранится БД (Metadata) для хранения промежуточных данных для работы поисковых запросов и представлений.


Рис. 2. Распределение нагрузки между серверами.

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

В ходе тестирования изначально master-сервер у нас был мощнее, чем slave-сервер. Однако, при преодолении цифры примерно в 40 тысяч пользователей, мы увидели, что slave-сервера не справляются, а master, наоборот, недогружен. Это было практическим подтверждением того, что запросов на чтение больше, нагрузки они генерят больше, поэтому в первую очередь мы распределяем её между узлами.

При работе режима Always On различают несколько видов запросов пользователей:
  • Запрос отчета. В случае, если у отчета, хранящегося в БД, выставлен признак Read Only, сервер приложений берет информацию по запросу, хранящуюся на одном из slave-серверов, не нагружая master-сервер работой. Если же у отчета не указан признак Read Only, то сервер приложений отправляет запрос на master-сервер, т.к. в данном случае будут вноситься изменения в БД.
  • Получение данных карточки. В данном случае используется временная метка Timestamp, которая присваивается каждой карточке при внесении в нее изменений. При каждом новом изменении в карточке счетчик Timestamp повышается. При запросе карточки выбирается место чтения, в котором метка Timestamp у карточки имеет наивысшее значение: из распределенного кэша (если там тот же Timestamp), какой-то из реплик (если Timestamp реплики больше Timestamp карточки это означает, что на реплику уже переданы актуальные данные карточки), иначе с мастера. Если карточка изменялась в текущей сессии, и информация о ней хранится в кэше, система смотрит значение метки Timestamp в кэше, а затем ищет на slave-серверах и master-сервере нужную карточку, у которой Timestamp соответствует значению в кэше.
  • Выполнение поисковых запросов, работа с представлениями. При выполнении данных запросов сервер приложений получает информацию с одного из slave-серверов из области БД Metadata (хранилище временной информации о работе поисковых запросов и представлений). Выбор slave-сервера для работы с представлением фиксируется в кэше и при загрузке новых страниц представления и использования остальных методов, которые работают с поисками и представлениями, используется выбранный сервер.

Особенности работы slave-серверов:
  • Сервер приложений хранит счетчик вызова каждого slave-сервера, значение которого увеличивается при каждом новом запросе к реплике. Для оптимальной нагрузки и скорости работы серверов используется алгоритм Round Robin, т.е. при каждом новом запросе отчета, представления, поиска выбирается slave-сервер с минимальным счетчиком вызова.
  • При репликации существует задержка, связанная со скоростью работы сети. При настройке режима Always On можно задать приемлемое время этой задержки и период проверки соответствия реальной задержки работы slave-сервера заданному значению. Если реальное значение превышает заданное, то slave-сервер становится временно недоступным для запросов. При следующей проверке, если реальное значение задержки будет соответствовать заданному значению, slave-сервер вновь станет доступным для запросов.
  • Выполнение запросов к БД может быть перенаправлено с master-а на slave при использовании следующих методов:

GetCardXmlData серверный метод, возвращает XML запрошенной карточки;
SectionReadRowsData серверный метод, возвращает содержимое строки секции карточки;
SearchCreateProcessor все методы поисков;
ViewCreateProcessor все методы представлений;
CardGetState возвращает состояние карточки;
ReportGetData получает результат выполнения отчета;
RowGetData возвращает содержимое строки секции карточки;
RowGetHierarchy возвращает идентификаторы всех родительских строк в секции для подчиненной строки;
CardGetType серверный метод, возвращает тип карточки;
SessionGetIdList;
UserGetInfo.

Использование технологии MS SQL Always позволяет плавно увеличивать серверные мощности и распределять повышенную нагрузку. На тестах мы добились нагрузки 100 000+ одновременно работающих пользователей, во многом именно благодаря масштабированию на уровне БД.

Буду рад ответить на вопросы.
Источник: habr.com
К списку статей
Опубликовано: 06.08.2020 14:19:11
0

Сейчас читают

Комментариев (0)
Имя
Электронная почта

Администрирование баз данных

Ms sql alwayson

Docsvision

Более 1000

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru