Привет.
Меня зовут Тигран Петросян, я ведущий инженер технической поддержки компании Docsvision, и сегодня я расскажу об использовании технологии MS SQL AlwaysOn.
Это вторая статья из мини-серии «Масштабируемость ECM на предприятии», в которой первая статья моего коллеги была посвящена Технологии масштабирования поиска Elasticsearch .
Оба материала могут быть интересны не только тем, кто работает с Docsvision, но и всем, кто интересуется технологиями масштабирования.
Несколько слов о том, почему мы об этом говорим
Последняя версия разрабатываемой нами платформы Docsvision SD/ECM принципиально отличается от предыдущих версий модульной архитектурой.Важно было обеспечить возможность масштабирования системы (причем практически неограниченно) с сохранением скорости работы.
Одной из технологий, лежащих в основе возможностей новой платформы, является MS SQL AlwaysOn.
Мои коллеги уже рассказали о технологиях масштабирования, которые лежат в основе возможностей новой платформы: есть
Microsoft всегда включен"> серия из 4 мини-вебинаров на YouTube
,
Microsoft всегда включен"> серия из 3 статей на Medium
(
Microsoft всегда включен"> статья №1
,
Microsoft всегда включен"> статья 2
, А
Microsoft всегда включен"> статья №3
специально посвящен теме масштабирования баз данных).
В этих материалах более наглядно показано, какие задачи мы решали и чего добились при их решении.
Я рассмотрю одну специфическую особенность MS SQL AlwaysOn, повышающую надежность и производительность сервера базы данных.
Microsoft всегда включен" alt="Масштабирование базы данных.
Microsoft всегда включен">
Рис.
1. Сегодня архитектура платформы Docsvision выглядит так.
Масштабирование службы базы данных.
MS SQL всегда включен Инструменты повышения производительности и масштабирования сервиса баз данных нашей платформы Docsvision включают возможность создания кластеров серверов баз данных.
Такую возможность предоставляет технология MS SQL AlwaysOn. Группы доступности AlwaysOn в базе данных Docsvision могут выполнять сразу две задачи:
- Высокий уровень доступности обеспечивает бесперебойную работу системы;
- Нагрузка чтения из базы частично выполняется на репликах.
- Мастер-сервер – основной сервер, записывающий все изменения в системе (чтение, запись);
- Подчиненный сервер — это сервер репликации, который дублирует все изменения в системе, но доступен только для чтения.
Каждый сервер репликации хранит базу данных (метаданные) для хранения промежуточных данных для выполнения поисковых запросов и представлений.
Microsoft всегда включен" alt="Масштабирование базы данных.
Microsoft всегда включен">
Рис.
2. Распределение нагрузки между серверами.
Как видно на схеме, мы распределяем нагрузку по чтению, так как подавляющее большинство пользовательских операций в системе — это операции чтения (поиск, отчеты, открытие документов).
Во время тестирования изначально наш главный сервер был мощнее подчиненного.
Однако когда мы превысили цифру примерно в 40 тысяч пользователей, мы увидели, что слейв-серверы не справляются, а мастер, наоборот, недогружен.
Это было практическое подтверждение того, что запросов на чтение больше, они генерируют большую нагрузку, поэтому в первую очередь распределяем ее между узлами.
При работе режима Always On существует несколько типов запросов пользователя:
- Запросить отчет. Если у отчета, хранящегося в базе данных, установлен флаг «Только чтение», сервер приложений по запросу берет информацию, хранящуюся на одном из подчиненных серверов, не нагружая работой главный сервер.
Если в отчете не указан атрибут «Только чтение», то сервер приложений отправляет запрос на главный сервер, поскольку в этом случае в базу данных будут внесены изменения.
- Получение данных карты.
В этом случае используется временная метка, которая присваивается каждой карте при внесении в нее изменений.
С каждым новым изменением в карточке счетчик Timestamp увеличивается.
При запросе карты выбирается место чтения, в котором метка «Timestamp» карты имеет наибольшее значение: из распределенного кэша (если Timestamp один и тот же), одна из реплик (если Timestamp реплики больше Timestamp карты, это означает, что в реплику уже были переданы текущие данные карты), в противном случае – с мастера.
Если карта изменилась в текущем сеансе, и информация о ней хранится в кеше, система смотрит значение метки Timestamp в кеше, а затем ищет на подчиненных серверах и главном сервере нужную карту, чья Timestamp соответствует значению в кэше.
- Выполнение поисковых запросов, работа с представлениями.
При выполнении этих запросов сервер приложений получает информацию от одного из подчиненных серверов из области базы данных «Метаданные» (хранилище временной информации о работе поисковых запросов и представлений).
Выбор подчиненного сервера для работы с представлением записывается в кэш, и при загрузке новых страниц представления и использовании других методов, работающих с поиском и представлениями, используется выбранный сервер.
- Сервер приложений хранит счетчик вызовов для каждого подчиненного сервера, значение которого увеличивается с каждым новым запросом к реплике.
Для оптимальной загрузки и скорости серверов используется алгоритм Round Robin, т.е.
при каждом новом запросе отчета, презентации или поиска выбирается подчиненный сервер с минимальным счетчиком обращений.
- Во время репликации происходит задержка из-за скорости сети.
При настройке режима Always On вы можете установить допустимое время этой задержки и период проверки соответствия фактической задержки подчиненного сервера заданному значению.
Если реальное значение превышает заданное, то подчиненный сервер становится временно недоступен для запросов.
При следующей проверке, если фактическое значение задержки соответствует заданному, подчиненный сервер снова станет доступен для запросов.
- Выполнение запросов к базе данных можно перенаправить с ведущего устройства на ведомое следующими методами:
- GetCardXmlData – серверный метод, возвращает XML запрошенной карты;
- sectionReadRowsData – серверный метод, возвращает содержимое строки раздела карточки;
- SearchCreateProcessor – все методы поиска;
- ViewCreateProcessor – все методы просмотра;
- CardGetState – возвращает состояние карты;
- ReportGetData – получает результат выполнения отчета;
- RowGetData – возвращает содержимое строки раздела карточки;
- RowGetHierarchy – возвращает идентификаторы всех родительских строк в разделе для дочерней строки;
- CardGetType – серверный метод, возвращает тип карты;
- СеансЖетИдЛист;
- ПользовательGetInfo.
В тестах мы добились нагрузки в 100 000+ одновременных пользователей, во многом благодаря масштабированию на уровне базы данных.
Буду рад ответить на ваши вопросы.
Теги: #Администрирование баз данных #docsvision #MS SQL AlwaysOn #более 1000
-
Подробности О Взломе Алгоритма А5/1
19 Dec, 24 -
Алгоритм Nsco (Алгоритм Хо-Кашьяпа)
19 Dec, 24 -
Веб 3.0 Сейчас
19 Dec, 24 -
Если Бы У Вас Был Компьютер...
19 Dec, 24