Как выполнить изменения индекса RavenDB в сценарии развертывания Blue-Green с высокой доступностью?
контекст
- Я пытаюсь разработать стабильный, последовательный подход к обновлению индексов RavenDB в производстве.
- Я сосредотачиваюсь конкретно на истории обновления индекса (т.е. я знаю, что мои настройки не в полной мере учитывают высокую доступность)
- Это гипотетический сценарий (то есть в настоящее время ничего не происходит в производстве)
- Предположим, что аппаратные / программные / сетевые конфигурации являются гибкими (т.е. добавление другого экземпляра RavenDB, дополнительных серверов, постоянного кэша и т. Д.)
Текущий сценарий хостинга
- Балансировка нагрузки двух веб-серверов в активно-пассивной конфигурации, на каждом запущено 1 веб-приложение
- 1x сервер под управлением экземпляра RavenDB (последняя стабильная версия)
Ограничения
- Высокая доступность должна поддерживаться на протяжении всего процесса
- Процесс развертывания будет полностью автоматизирован
- Процесс развертывания может инициировать откат в любой точке всего развертывания.
- Перестройка индекса может занять до 1 минуты; и недопустимо не иметь данных, доступных для отображения так долго
Потенциальное решение
Добавьте второй экземпляр RavenDB и реплицируйте RavenDB в активно-активной конфигурации.
- Активный веб-сервер общается с активным экземпляром RavenDB
- Пассивный веб-сервер общается с пассивным экземпляром RavenDB
Развертывание будет выглядеть так:
- Остановить репликацию
- Развертывание нового кода веб-приложения на пассивном веб-сервере
- Запустите веб-приложение и дайте ему автоматически обновлять определения индекса в его экземпляре RavenDB
- Тестовое задание
- Переключите балансировщик нагрузки на пассивный веб-сервер, сделав его активным
- Монитор (на х количество времени) и откат при необходимости
- Запустите репликацию, и пусть определения индекса и данные обновляются в другом экземпляре RavenDB
Откат будет выглядеть так:
- Переключите балансировщик нагрузки на пассивный веб-сервер, сделав его активным
Есть ли более оптимальный способ реализовать это?
1 ответ
Мы добиваемся чего-то подобного, сохраняя имена индексов в переменной конфигурации. Затем мы создаем новый индекс с обновленным определением под новым именем. Как только он закончится, мы переключаем переменную конфигурации, чтобы она указала на новое имя индекса.
В зависимости от вашего процесса, вы можете жестко закодировать имена индексов в ваших отдельных сборках, выполнить эту настройку и переключить часть своего кода запуска или любое количество альтернатив для того, что подходит вам лучше всего.
Этот процесс должен работать нормально, пока выходные данные определения индекса не радикально отличаются. Если это так, вам может потребоваться больше элементов управления, с помощью которых веб-сервер использует какое определение.