Я начал изучать создание виртуального сервера с балансировкой нагрузки, для запуска в основном веб-сервисов, сервисов управления проектами (контроль версий и т. д.) и приложений такого рода. И мне нужно решение с открытым исходным кодом (Linux).
Википедия имеетэта запись, есть, казалось бы, очень многообещающие стабильные проекты, но большинство из них давно мертвы.ЛВСиКерригедвыглядят возможными, но я не уверен. Стоят ли они инвестиций (по времени)?
Какое решение было бы хорошим? (хотя я не могу позволить себе коммерческое решение (Linux или что-то другое), я хотел бы узнать об этих альтернативах и буду признателен за комментарии по этому поводу).
спасибо
решение1
Похоже, вы пытаетесь решить проблему не на том уровне. Я не знаю ни одного здравомыслящего системного администратора, который попытается использовать Single System Image для запуска веб-сервера, когда есть другие методы, такие какобратные проксикоторые намного проще и, как следствие, надежнее.
Такой как:
решение2
Если я правильно понял вопрос, то я бы сказал, что в вопросе хостинга веб-приложений вы подходите к этому вопросу неправильно.
Я бы предложил иметь несколько узлов (виртуальных или физических) и управлять их конфигурацией с помощьюкукольный.
Ваши узлы могут представлять собой целую стойку серверов 1U или группу мощных многопроцессорных серверов 3U, работающихКВМа затем ОС по вашему выбору в качестве гостевых систем виртуализации.
Имея 4 сервера, вы можете настроить их следующим образом:
- Сервер 1: Балансировщик нагрузки + HTTP-узел (работающий под управлением Varnish и Apache)
- Сервер 2: Балансировщик нагрузки + HTTP-узел (работающий под управлением Varnish и Apache)
- Сервер 3: HTTP-узел + главный сервер баз данных (работающий с Apache и MySQL)
- Сервер 4: HTTP-узел + подчиненный сервер БД (работающий под управлением Apache и MySQL)
Было бы полезно иметь пятый сервер, на котором будут работать такие службы, как nagios, munin, tftpd для среды загрузки PXE, небольшой HTTP-сервер для файлов kickstart/preseed, DHCPd, возможно, последовательные консоли через Rocketport или что-то подобное.
Огромное преимущество использования Puppet для развертывания собственных систем вместо одного образа заключается в том, что ресурсы фактически самодокументируются. Это намного понятнее и менее похоже на черный ящик, чем просто образ, который вы сбрасываете на серверы. Плюс это значительно упрощает обновления и изменения образа.
решение3
Я не уверен, что отвечаю на ваш вопрос, но если вы ищете способ взять виртуальную машину и создать ее зеркало, вы можете использовать любой из известных мне бесплатных инструментов виртуализации (VMware Server, ESXi, kvm и т. д.)
- создайте свою виртуальную машину со всем необходимым
- скопировать виртуальную машину
- внести изменения в копию (IP-адрес и имя хоста)
- запустить обе виртуальные машины
- вставьте балансировщик нагрузки (аппаратный или программный, неважно)
- .. шестого шага я не могу придумать :)
решение4
Как бы многообещающе ни звучали идеи SSI, маловероятно, что они будут работать оптимально.
Поскольку ваша основная цель — веб-приложения, вы можете (должны!) использовать текущие лучшие практики. Обычно они начинаются с:
- балансировщик нагрузки кэширования в качестве интерфейса (squid, Varnish, nginx)
- несколько HTTP-серверов для веб-приложений (обычно Apache, может быть nginx+FastCGI, что угодно)
- база данных
Если все сделано правильно, то первым узким местом станет база данных. На этом этапе вам следует:
- добавьте кэш в свои веб-приложения, чтобы свести к минимуму обращения к БД. (современные фреймворки (RoR, Django) включают в себя отличную поддержку memcached)
- перенести некоторые виды работ из БД в более специализированные приложения. Первыми кандидатами являются очереди задач (в rabbitMQ или подобные) и хранилища ключей/значений (в Tokyo Cabinet, Resis, MongoDB и многие из них)
- распределите БД. если много чтений/мало записей, попробуйте репликацию master/slave (легко на MySQL), но если это ваш случай, memcached должен был уже поглотить большую часть нагрузки. Также попробуйте шардинг.
если вы когда-нибудь перерастете это (вы Facebook?), вам придется переосмыслить всю свою структуру, а-ля Google (где они делают почти все «автономно» с помощью MapReduce).