Виртуальные машины
В целях упрощения управления и резервного копирования, все сервера поставляются в виде образов виртуальных машин.
Безопасность
Все пользователи и библиотекари находятся во внешнем периметре. Для них доступны только 80, 443 порты балансировщика нагрузки. Доступ в защитный периметр имеет только администратор. Все сервера управляются по SSH.
Сервера приложений
Все запросы с балансировщика нагрузки попадают в кластер однотипных серверов приложений. Сервера приложений выполняют большую часть задач для работы ELiS, включая конвертацию страниц, авторизацию и проверку прав доступа, отдачу страниц в браузер и на мобильные устройства. На серверах приложений установлен Drupal7, php-fpm, nginx.
Сервера приложений генерируют большую нагрузку на центральный процессор, особенно при генерации страницы под устройство пользователя. Для увеличения числа обслуживаемых клиентов можно включить большее число серверов в кластер.
Все сервера приложений идентичны друг другу и их увеличение можно производить клонированием базового образа виртуальной машины.
Основная база данных
Drupal хранит большую часть информации о сайте и реализованном в ELiS функционале в базе данных MariaDB. Эта центральная база данных, обращение к которой происходит при каждом скачивании страницы или открытии сайта. Для работы с сотнями одновременных обращений необходимо позаботиться об высокой производительности сервера, оснастив его большим объемом ОЗУ и промышленными SSD-дисками.
При необходимости, можно создать реплику (копию) основной базы данных.
Кеш
Для получения полной информации по книге с 1000 страниц в основную базу данных будет сделано около 5000 запросов. Время выполнения запросов на ненагруженном сервере составит около 1-2 секунд. Для снижения нагрузки на основную базу данных и уменьшения времени генерации страницы единожды загруженная книга сохраняется в кеше и, при следующем обращении, структура книги достается сразу из кеша. В качестве кеша с возможностью обращения по сети используется высокопроизводительная NoSQL база данных Redis. Redis сохраняет закешированные данные в ОЗУ и, с некоторым интервалом, сохраняет снимок памяти на диск.
Логи обращения к страницам
Для тщательного учета и возможности построения подробных статистических отчетов, все обращения к страницам сохраняются в базу данных. По логам также рассчитывается число занятых экземпляров электронной книги, что приводит к большому числу операций как вставки (события обращения к странице), так и чтения по индексам (расчет числа занятых экземпляров) в базу с логами. В высоконагруженных проектах работа с базой логов занимает большую часть времени генерации страницы, поэтому она была вынесена в высокопроизводительную NoSQL базу данных MongoDB.
Достоинством MongoDB является возможность отложенной записи, когда отдача рисунка осуществляется без ожидания фактической записи логов в базу данных и высокая производительность при большом числе обращений. Благодаря технологии mmap, MongoDB пытается разместить и сохранить записи базы данных в ОЗУ после первого обращения, за счет чего существенно снижается нагрузка на файловую систему при чтении и ускоряются выборки. Для хранения данных также рекомендуется использовать SSD и большой размер оперативной памяти.
Поиск
Поисковые возможности реляционных баз данных плохо масштабируются на большие объемы текстов. В больших библиотеках для реализации поиска используются специализированные поисковые движки. В ELiS используется отечественный поисковый движок Sphinx, обеспечивающий корректный учет морфологии русского языка и позволяющий осуществлять горизонтальное масштабирование по мере необходимости. Первоночально из загруженных книг на сервере приложений вынимается текст и сохраняется в основной базе данных. Раз в сутки Sphinx обходит основную базу данных и заново иднексирует все полные тексты.
Поисковый запрос пользователя с сайта или мобильного приложения приходит через балансировщик нагрузки на сервер приложений. Сервер приложений обращается в Sphinx для получения результатов поиска, подсвечивает найденные слова и возвращает результат пользователю.
При большой нагрузке на поиск можно установить несколько серверов Sphinx и распределять поисковую нагрузку между серверами.
Система хранения
В ELiS можно выделить три типа файлов и применять к ним различные политики хранения.
1) Файлы для постоянного хранения. Это сами книги и обложки к ним. Эти файлы удалять нельзя.
2) Регенерируемые файлы, рекомендуемые к постоянному хранению. Эти файлы можно удалить, но рекомендуется их хранить для уменьшения времени выдачи страницы книги пользователям. К регенерируемым файлам относятся страницы книг с расширениями png, svg, jpg в директории с PDF-файлом книги.
3) Кеш отданных страниц. При показе страницы может потребоваться наложение защитных меток, водяных знаков и приведение страницы к запрошенному разрешению. Результаты этих преобразований сохраняются в отдельной директории и могут быть безопасно удалены в любой момент. В виду того, что при активном обращении таких файлов будет очень много, они должны периодически удаляться, для чего предусмотрен соответствующий скрипт.
Файлы из политик 1 и 2 обязаны храниться на общей для всех серверов приложений файловой системе. Для файлов из политики 3 допустимо использование локальных дисков серверов приложений (желательно использование SSD).
В больших библиотеках размер файловой системы будет составлять десятки терабайт и получить его на одном сервере нельзя. При этом можно использовать два подхода:
1) Покупка промышленной системы хранения большой емкости и монтирование этой емкости по NFS к серверам приложений.
2) Использование кластерной файловой системы, такой как GlusterFS. Сетевые кластерный файловые системы позволяют хранить файлы с книгами распределенно по нескольким серверам, объединяя емкость дисков всех серверов. При этом подходе возможно постепенное наращивание дисковых ресурсов по мере необходимости без существенных трат. GlusterFS позволяет включить режим зеркалирования записи, когда один файл пишется сразу на два разных сервера и выход из строя сервера или его диска не приводит к потери информации и простою библиотеки.