Учитывая, что доступность не имеет решающего значения для вашего варианта использования, я бы сказал, что должно быть хорошо, чтобы разместить серверы конфигурации на тех же серверах приложений и mongos.
Если один из узлов процесса опущен, вы потеряете: 1 x mongos, 1 сервер приложений и 1 конфигурационный сервер. Во время этого простоя другие два сервера конфигурации будут только для чтения, что означает, что не будет балансировки осколков, модификации конфигурации кластера и т. Д. Хотя ваши другие два mongos все равно должны быть работоспособны (CRUD мудрый). Если ваш веб-узел не работает, тогда у вас больше проблемы.
Если два узла опущены (2 узла процесса или 1 веб-сервер и узел процесса), опять же, у вас возникнет большая проблема. т. е. ваши приложения, вероятно, не будут работать в любом случае.
Сказав это, рассмотрите возможности этих узлов, чтобы они могли обрабатывать сервер приложений и сервер конфигурации mongos. то есть ЦП, ОЗУ, сетевые соединения и т. д.
Я бы рекомендовал протестировать архитектуру развертывания в кластере разработки/промежуточного развертывания сначала в соответствии с типичной рабочей нагрузкой и используемым случаем.
Также см. Sharded Cluster High Availability для получения дополнительной информации.
Наконец, я бы порекомендовал проверить MongoDB v3.2, который является текущим стабильным выпуском. Конфигурационные серверы в v3.2 моделируются как набор реплик, см. Sharded Cluster config servers для получения дополнительной информации.