Как кластер volrix.pm растет с каждым узлом, переживает обновление и отказы под нагрузкой и что дает чтение с реплик. Стенд, методика и цифры.
Обновлено 15.10.2026
Отказоустойчивый кластер volrix.pm должен делать три вещи: становиться быстрее с каждым новым сервером, не останавливаться при обновлении и отказе узла и не терять подтвержденные данные. Мы проверили это нагрузкой на стенде и публикуем цифры как есть - вместе с тем, что нагрузка нашла и что пришлось исправить.
Все машины стенда работают на одном физическом сервере и делят его с другими задачами. Абсолютные цифры относятся к этому стенду: на серверах заказчика они будут выше. Важны относительный рост с каждым узлом и поведение при отказах.
С трех до шести узлов потолок вырос на 53%, а время ответа при 400 пользователях сократилось вчетверо. Новый узел добавляется командой присоединения, кластер при этом не останавливается.
Важнее потолка - поведение при перегрузке. Прежняя версия на трех узлах при 800 пользователях отвечала за 8,3 с (p95). Теперь лишние запросы ждут в очереди балансировщика, а не роняют узлы друг за другом: до 1000 пользователей ошибок нет ни на одной конфигурации.
Нагрузочный стенд для того и нужен, чтобы находить узкие места до заказчика. Что было найдено и исправлено по ходу испытаний:
Все события ниже - на работающем кластере под постоянной нагрузкой 300 пользователей, около 130 запросов в секунду:
При внезапном отказе основного сервера запись прерывается на время выборов нового - примерно на 15-20 с. Приложение отвечает «повторите», чтение в это время продолжается с реплик. Подтвержденные записи не теряются: запись считается выполненной, только когда ее получила еще одна реплика, и новым основным становится реплика, у которой есть все подтвержденные данные (RPO 0).
Отказ основного Valkey (служебное состояние) - 5 с, данные на месте. Отказ узла хранилища файлов вместе с лидером - все файлы читаются и пишутся.
Внешний трафик принимают балансировщики на всех узлах, у каждого - свой адрес входа, в DNS имя системы указывает на все адреса. Кворум и право стать основным сервером БД - тоже у всех узлов. Проверка на пяти узлах с тремя адресами входа, по 4 потока чтения и записи на каждый адрес:
В кластере каждый узел приложения пишет в основной сервер, а читает со всех реплик сразу. Мы проверили, что это дает, двумя прогонами одной и той же нагрузки: как в поставке и с чтением только с основного сервера.
Реплики действительно забирают чтение: на 200 пользователях с основного ушло около 130 транзакций в секунду. Но быстрее система на этом стенде не стала - разница в пределах разброса замера. Причина в том, что узкое место здесь не база данных: процессор узлов занимает приложение, а чтение для PostgreSQL дешево, и основной сервер до своего предела не доходит. Выигрыш от реплик проявится там, где основной упирается в базу: больше пользователей на узел, тяжелые отчеты и выборки.
Зато чтение с реплик не мешает: потолок и время ответа не хуже, а пользователь сразу видит свою запись. Мы проверили 95 пар «создать заметку - сразу прочитать»: ни одного случая, когда реплика отдала бы старые данные, самое долгое чтение после записи при 200 пользователях - 63 мс.
В прогоне с чтением только с основного на ступени 600 пользователей локальный прокси на 20 с счел перегруженный основной сервер недоступным - 3,5% ответов ступени с ошибкой. Причина найдена: проверка доступности ждет подключения 1 с вместо задуманных 3 с. Исправляем.
Один физический сервер под всеми машинами стенда, по одному прогону на режим: различия меньше 10-15% не считаем значимыми.
Один сервер и отказоустойчивый кластер
Deckhouse и другие платформы, без терминала
Бесплатно на 5 пользователей
