hVosttPu4koffРазносим это на две разные железки: вот уже у нас могут сломаться две железки, у нас две ОС могут коряво обновиться, т.е. вероятность того, что клиент не сможет работать сильно увеличивается.

абсолютное не понимание реалий. единственное, что представляет ценность, это база данных. остальное всё может навернуться медным тазом. если сломается, чиним без каких-то проблем. если потерялись данные, увольняемся по собственному за тупизну. если из-за того, что всё тормозит, так как СУБД выжирает всю оперативку, как ей и положено, получаем в тык, перестаём фантазировать, и делаем по-человечески.
Как наличие сервера приложений на том же сервере влияет на сохранность базы данных? Какой-то такой корявый сервер, что портит память направо и налево и специально убивает СУБД?
Допустим у нас одинаковые сервера. два блока питания, raid на все данные, бэкапы,... всё с этим хорошо. Про оперативку не фантазируем, т.к. у нас в сервере её террабайт и заведомо хватит всем.
В одном варианте мы на этом сервере располагаем и сервер приложений и субд. В другом варианте разносим по двум разным серверам. С чего вдруг у нас первый вариант потеряет какие-то данные, а второй вариант окажется надёжнее?

hVosttPu4koffВиртуализируем: железка всё так же одна, но разные экземпляры ОС. Опять увеличивается вероятность появления проблем.

не выдумывайте. при разнесении ПО на разные железяки, особенно это касается СУБД, система становится в целом только надёжнее, при чём ощутимо.
Что значит надежнее? Я утверждаю, что при разнесении по двум разным железкам вероятность того, что клиент не сможет работать с системой вырастет, потому что в целом система зависит от двух железок. Пусть у нас вероятность выхода из строя сервера равна 0,1. Значит вероятность выхода из строя любого из двух серверов равно 0,1 + 0,1 = 0,2, т.е. в два раза выше. Сюда добавляем еще вероятность проблемы с ОС. Если совсем уж криворукий разработчик, то он может заминусовать отсюда вероятность того, что сервер приложений прибьёт СУБД и уничтожит базу данных.
hVosttэто всё равно, что сказать, что машину надо делать ровно из одной детали, так как большое количество деталей увеличивает вероятность поломки. фигню-то не говорите.

Нет. Допустим нам нужно перевезти сервер из пункта А в пункт Б. Либо мы везём его на одной машине, но если она попадает в аварию, то мы теряем весь сервер. Либо мы вытаскиваем из сервера жесткие диски, и везём его на двух разных машинах. Теперь уже вероятность потерять весь сервер становится меньше, вероятность довезти сервер целиком так же уменьшается, а вероятность потерять данные примерно такая же.
hVosttтакже разнесение увеличивает безопасность системы. ну уже очевидные вещи-то чо говорить..
Само по себе ничего не происходит. В кривых руках она еще и уменьшиться может.

Так выглядит, как-будто я агитирую за то, что надо всё положить на один десктопный комп, без raid, бэкапов и прочего и это будет надёжнее, чем разнесение по взрослым серверам с резервированием БП, raid'ами, бэкапами,... Ну и естественно никто снимки системы не делает, чтобы потом быстренько развернуть образ. Накрылся сервер приложений - лениво полез скачивать образ ОС, записывать на болванку,... Нет такого, что заранее подготовил образ рабочей системы, потом быстренько его накатил, а там уже есть и сервер приложений и СУБД и нужно только БД подсунуть актуальную.

hVosttPu4koffКак наличие сервера приложений на том же сервере влияет на сохранность базы данных? Какой-то такой корявый сервер, что портит память направо и налево и специально убивает СУБД?
Допустим у нас одинаковые сервера. два блока питания, raid на все данные, бэкапы,... всё с этим хорошо. Про оперативку не фантазируем, т.к. у нас в сервере её террабайт и заведомо хватит всем.
В одном варианте мы на этом сервере располагаем и сервер приложений и субд. В другом варианте разносим по двум разным серверам. С чего вдруг у нас первый вариант потеряет какие-то данные, а второй вариант окажется надёжнее?

Я так понимаю, с логикой вы конкретно не в ладах, да? Вам уже аналогию про яйца и корзину сообщили. Это имеет абсолютно прямое отношение к надёжности.
Приложение работает только тогда, когда все яйца целые. Раскладывание яиц по разным корзинам нужно для сохранения хотя бы части яиц. Совершенно разные вещи.
hVosttНу и фантазии на тему террабайта озу, это уже фиаско.

Мы не знаем что там у человека за программа и сколько она памяти потребляет. Поэтому и террабайт, чтобы не фантазировать, что там вдруг СУБД всю память сожрёт. Может там 8 гигабайт на всё хватит за глаза. Вопрос изначально не стоял, что какие-то проблемы с производительностью.
hVosttPu4koffПусть у нас вероятность выхода из строя сервера равна 0,1. Значит вероятность выхода из строя любого из двух серверов равно 0,1 + 0,1 = 0,2, т.е. в два раза выше. Сюда добавляем еще вероятность проблемы с ОС. Если совсем уж криворукий разработчик, то он может заминусовать отсюда вероятность того, что сервер приложений прибьёт СУБД и уничтожит базу данных.

Надо, чтобы кто-нибудь познакомил вас с логикой. Вероятность того, что одна из нескольких машин выйдет из строя никак не нивелирует способность выйти из строя одной единственной машины. Ну никак. Мозги включайте уже.

Так я и не говорил, что нивелирует. Так что со своей логикой что-то делайте.
hVosttЗато стоимость восстановления отдельной небольшой части СУЩЕСТВЕННО меньше, чем всей системы в целом. Её можно даже заменить чем-то временным, пока чинится, перекинуть ресурсы.

Откуда появились какие-то ресурсы? Может люди весь бюджет потратили на два сервера и нечем резервироваться?
hVosttС одной системой, вашим яйцам приходит пздц одновременно.

Да
hVosttСервер приложений обычно dataless, т.е. достаточно иметь образ, который можно сразу запускать. За счёт этого можно тиражировать деплой на сколько угодно машин одной кнопкой. С базой данных подобное не прокатит.
Откуда такая уверенность, что выйдет из строя именно сервер приложений, а не СУБД? Ну, и скопировать базу на новый экземпляр сервера - это безусловно долгая и дорогая операция.
Не слишком ли много догадок, домыслов и выворачиваний в свою пользу получается? Как ломается, так обязательно сервер приложений и обязательно резервные ресурсы находятся. Чудеса прямо какие-то. Меня прямо удивляет, что ограничились всего двумя серверами. Кластеры же нужно для надёжности, еще и территориально разнести.
Все эти best practics никогда не учитывают реальности в виде бюджетирования, криворукости админов и разработчиков и т.д. и т.п.
Да, в сферических условиях в вакууме, лучше разносить по разным железкам, лучше серверное железо использовать, лучше то, лучше это. А в реальности человеку принесут пару железок от предыдущего проекта и делай с ними что хочешь. Хочешь одну про запас держи, пока вторая работает, хочешь типа грамотно разнеси по разным сервакам, но тогда останешься без резерва, хочешь еще как изгаляйся.
Дальше будем фантазировать об условиях у ТС и определять у кого с логикой беда или сойдёмся на том, что всё нужно делать с умом отдавая себе отчёт в том, что может произойти, прорабатывая все возможные сценарии, а не тупо по каким-то рекомендациям кого-то там, потому что так правильнее?

Valery_B, какие-то аргументы для спора "клиент-сервер vs трёхзвенка". Тут уже определились в пользу трёхзвенки, но не решаются два звена разнести по разным железкам.

skyANAPu4koffПриложение работает только тогда, когда все яйца целые.
Именно ваше приложение?

Лично у нас другие требования. Если вдруг отвалился Couchbase, то приложение должно продолжать работать.
Должен сработать предохранитель (Circuit Breaker pattern), а не проводка к чертям погореть и все лампочки лопнуть
А у нас в квартире газ, а у вас? А если сервер приложений умрёт, то кто отправит сигнал сос? Или их несколько, но в одной комнате. А если комнату затопит или она сгорит? Продолжаем фантазировать на тему апокалипсиса? Может вообще нужно было между сервером и проводкой поставить какой-нибудь контроллер, который бы от сервера ежесекундно получал сообщение, что всё хорошо, а когда сообщения нет - отключал питание? :-)
Если приложение может работать без БД, значит БД и не нужна и нечего голову морочить. Где-то нужны эти "предохранители", где-то не нужны. Всё равно это всё не есть штатная работа программы. Дальше у всех свои требования. Кого-то устроит и день простоя, кому-то 5 минут - смертный приговор. Где-то можно на кэше прожить какое-то время, где-то только актуальные данные.
Я в этом топике лишь агитирую за то, что нужно думать что делаешь, к чему это может привести. Меня почему-то убеждают, что вот прямо обязательно нужно всё делить и это чудесным образом автоматически даст +80 к надёжности.