Почему тогда не спросите у него? Или это он предложил такую "замечательную" схему?
Статья на которую вы ссылаетесь давно устарела, хотя некоторые идеи конечно можно почерпнуть. А вообще хорошо спроектировать HA можно, только учтя особенности задачи. Например, если программа использует сессии в файлах, как стандартный пых, то придется выносить это в общее rw хранилище, желательно с нормальными локами. А если использует БД, то нужда в подобном отпадает и ряд проблем исчезает.
В общем случае предложил бы так
1. Независимые БД разнести по разным мускульным серверам, причем каждый из них в отдельный openvz/vserver контейнер ибо мускул не умеет себя толком ограничивать. Физически все это может жить как на одном сервере, так и на нескольких. Для каждого независимого мускула желательно несколько слейвов с репликацией. Приложения должны уметь распределять запросы чтения/записи дабы не записать с дуру в слейв вместо мастера.
2. Основную обработку почты вынести в отдельный контейнер, на остальных MTA только перенаправляют на него. Также отдельный сервер под DNS.
3. Веб приложения делать на основе fast-cgi, в крайнем случае apache+mod_чего_вы_там_юзаете. Исключение наверное для пыха, как самого тупорылого с точки зрения fcgi языка, для него eaccelerator+все_в_один_файл+mod_php.
4. В качестве балансировщика веб нагрузки использовать nginx(или lighttpd), заодно им же осуществлять кеширование и отдачу статики. Это будет основная точка входа. При большом количестве машин можно поставить несколько nginx серверов, а перед ними железный LB или DNS round robin.
5. Как можно больше общих файловых ресурсов монтировать в ro. Разделяемый rw рано или поздно приведет к проблемам. Если правильно спланировать приложения, то нужды в нем не будет. Подобная схема позволит свободно наращивать физические мощности и гибко менять нагрузку на каждый из компонентов, а не только на сайты целиком. Какая-то веб-задача(сайт может делится на отдельные задачи, хотя для конечного пользователя выглядит как одно целое) стала требовать больше ресурсов - увеличиваем количество соответствующих ей fcgi процессов и/или мускульных серверов. Нагрузка упала - сокращаем, дабы передать ресурсы более нагруженным задачам.
|
