Назад | Перейти на главную страницу

стабильное, свежее, бесплатное решение для единого образа системы для Linux

Я начал изучать создание виртуального сервера с балансировкой нагрузки для запуска в основном веб-служб, служб управления проектами (контроль версий и т. Д.) И подобных приложений. И мне нужно решение с открытым исходным кодом (Linux).

В Википедии есть эта запись, есть, казалось бы, очень многообещающие стабильные проекты, но большинство из них давно мертвы.LVS и Kerrighed посмотреть можно, но я не уверен. Стоит ли в них инвестировать (по времени)?

Какое было бы хорошее решение? (хотя я не могу позволить себе коммерческое решение (Linux или другое), я хотел бы узнать об этих альтернативах и признателен за комментарии по этому поводу).

Спасибо

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

Я бы предложил иметь несколько узлов (виртуальных или физических) и управлять их конфигурацией с помощью кукольный.

Ваши узлы могут представлять собой целую стойку серверов высотой 1U или группу мощных многопроцессорных серверов высотой 3U. KVM а затем ОС по вашему выбору в качестве гостей виртуализации.

Учитывая 4 сервера, вы можете настроить их следующим образом:

  • Сервер 1: балансировщик нагрузки + HTTP-узел (под управлением Varnish и Apache)
  • Сервер 2: балансировщик нагрузки + HTTP-узел (под управлением Varnish и Apache)
  • Сервер 3: HTTP Node + DB Master (под управлением Apache и MySQL)
  • Сервер 4: HTTP Node + DB Slave (под управлением Apache и MySQL)

Было бы выгодно иметь пятый сервер, который запускает такие службы, как nagios, munin, tftpd для среды загрузки PXE, небольшой HTTP-сервер для файлов кикстарта / предварительной загрузки, DHCPd, возможно, последовательные консоли через Rocketport или аналогичные.

Огромным преимуществом использования Puppet для развертывания ваших собственных систем вместо использования единого образа является то, что ресурсы фактически самодокументируются. Это намного яснее и меньше черного ящика, чем просто изображение, которое вы загружаете на серверы. Кроме того, это значительно упрощает обновление и изменение изображения.

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

Такие как:

Я не уверен, что отвечаю на то, что вы на самом деле спрашиваете, но если вы ищете способ взять виртуальную машину и отразить ее, вы можете использовать любой из бесплатных инструментов виртуализации, о которых я знаю (VMware Server , ESXi, kvm и т. Д.)

  • сделайте свою виртуальную машину со всем необходимым
  • скопировать виртуальную машину
  • внести изменения в копию (IP-адрес и имя хоста)
  • запустить обе ВМ
  • вставить балансировщик нагрузки (аппаратный или программный, не имеет значения)
  • .. не могу придумать шестой шаг :)

Как бы увлекательно ни звучало SSI, вряд ли они будут работать оптимально.

Поскольку ваша основная цель - веб-приложения, вы можете (должны!) Использовать текущие передовые практики. Обычно они начинаются с:

  • кеширующий балансировщик нагрузки в виде внешнего интерфейса (squid, varnish, nginx)
  • несколько HTTP-серверов для веб-приложений (обычно apache, может быть nginx + FastCGI, что угодно)
  • база данных

Если все сделано правильно, вашим первым узким местом будет база данных, на этом этапе вам следует:

  • добавьте кеш в свои веб-приложения, чтобы свести к минимуму количество обращений к БД. (современные фреймворки (RoR, Django), включают отличную поддержку memcached)
  • взять какую-то работу из БД в более специализированные приложения. первые кандидаты - это очереди задач (в rabbitMQ или аналогичные) и хранилища ключей / значений (в tokyo cabin, resis, mongoDB, многие из них)
  • раздать БД. если много чтений / мало записей, попробуйте репликацию master / slave (легко для MySQL), но если это ваш случай, memcached уже должен был поглотить большую часть нагрузки. Также попробуйте шардинг.

если вы когда-нибудь перерастете это (вы FaceBook?), вам придется переосмыслить всю свою структуру, а-ля Google (где они делают почти все "вне очереди" с MapReduce).