У нас есть довольно большая база данных Mongo, работающая в AWS. В настоящее время мы работаем с набором реплик с 3 экземплярами. Каждый экземпляр имеет 5 ТБ подключенного хранилища EBS. Это составляет более 1000 долларов в месяц за экземпляр. Вдобавок к этому у нас есть как производственная, так и промежуточная среда (скоро появится третья среда разработки). Кроме того, эти затраты могут резко возрасти в будущем, когда / если мы перейдем к сегментированной среде.
Вопрос в том, насколько необходимы 3 реплики в среде AWS?
Хорошо, хорошо, хорошо, я уже знаю, что ответ - это зависит от обстоятельств. Я ищу несколько советов о том, как лучше всего взвесить компромиссы. Например...
Учитывая, что каждый том EBS уже имеет встроенную тройную избыточность и что довольно просто восстановить из резервной копии, как мне измерить добавленную отказоустойчивость 2 или 3 реплик.
Есть ли дополнительные соображения помимо избыточности при рассмотрении компромиссов?
У кого-нибудь есть опыт (хороший или плохой) запуска всего 2 реплики + Арбитр?
- Учитывая, что каждый том EBS уже имеет встроенную тройную избыточность и что довольно просто восстановить из резервной копии, как мне измерить добавленную отказоустойчивость 2 или 3 реплик.
Что касается MongoDB, то ключевые соображения только с двумя участниками, несущими данные в наборе реплик из трех узлов, заключаются в том, что если один из этих элементов, несущих данные, недоступен по какой-либо причине (плановое обслуживание или незапланированный отказ):
w:1 (например: w:majority или w:2)Эта конфигурация имеет высокую доступность с точки зрения поддержки / выбора основного в случае отказа одного элемента, но арбитр ставит под угрозу избыточность данных, если один из элементов, несущих данные, недоступен. Если предположить, что у вас есть разумное время для восстановления из резервных копий EBS (и вы доверяете избыточности EBS), это может быть приемлемым компромиссом для вашего варианта использования.
- Есть ли дополнительные соображения помимо избыточности при рассмотрении компромиссов?
Если ваш код использует MongoDB писать проблемы выше значения по умолчанию (w:1) вы захотите добавить wtimeout стоимость. Если вы не укажете wtimeout и уровень беспокойства по поводу записи недостижим, операции записи будут блокироваться на неопределенный срок.
Гарантии AWS для избыточной инфраструктуры обычно распространяются только на отказы в нескольких зонах доступности, поэтому для максимальной доступности также следует развернуть элементы набора реплик в разных зонах доступности.
- Есть ли у кого-нибудь опыт (хороший или плохой) запуска всего 2 реплики + Арбитр
Я определенно видел плохие результаты, когда пользователи не учли вышеуказанные моменты (особенно с учетом проблем с записью и тайм-аутов). Если вы планируете (и тестируете) с учетом этих предостережений, вы сможете получить хороший опыт.
Вдобавок к этому у нас есть как производственная, так и промежуточная среда (скоро появится третья среда разработки)
Определенно есть аргумент в пользу наличия промежуточных сред и сред разработки, подобных продуктам, но типичная экономия затрат будет заключаться в развертывании сред с более низкими спецификациями для разработчиков с меньшим отказом, чем в производственной среде. Для постановки вы можете развернуть среды с более низкими характеристиками, но с аналогичной конфигурацией, чтобы вы могли протестировать реалистичные сценарии переключения при отказе. Если вы проводите тестирование производительности или нагрузочного тестирования в промежуточных средах, они должны иметь те же спецификации, что и производственные.