Когда количество пользовательского статического контента на проекте начало превышать возможности используемых нами серверов, мы задумались о будущем и решили масштабироваться не вертикально, а горизонтально. Обычный в современном мире способ горизонтального масштабирования подобного рода хранилища - использование так называемого Object Storage, распределенной системы хранения, строящейся на базе относительно дешевых узлов, имеющей S3 или REST-интерфейс.
Все современные объектные хранилища устроены почти одинаково - они состоят из сервера метаинформации (выделенного сервера может и не быть, поскольку он является единой точкой отказа, и его нужно обязательно резервировать), маршрутизатора запросов к серверам хранения и серверов хранения с локальными хранилищами. Далее начинаются отличия, по сумме результатов анализа которых нами и была выбрана LeoFS (кстати, сейчас она уже работает у нас в продакшне и хранит несколько терабайт пользовательских данных).
Кратко осветив причины выбора этого решения, я сконцентрируюсь на описании внутреннего устройства LeoFS, после чего мы заглянем "под капот" и посмотрим, какие динамические процессы происходят в компонентах системы при различных изменениях внешних факторов. Мы увидим на графиках, какими сообщениями и когда обмениваются компоненты системы и как они взаимодействуют, каким образом осуществляется балансировка и перебалансировка контента по серверам хранения, что происходит в случае отказа одного из узлов, как работают локальные узлы кэширования и трансляции запросов (LeoFS gateways).
Конечно, мы не обойдем своим вниманием и "темную сторону силы" - упомянем про недостатки и недочеты используемого нами решения (а недостатки и недочеты существуют всегда, надо только вовремя их обнаружить).
English version