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

Использовать или не использовать виртуализацию для веб-сервера Linux?

Я обслуживаю серверы для большого веб-проекта (java + postgres + некоторые инструменты), который в настоящее время размещен на трех машинах:

  1. Машина: Почтовый сервер (postfix), Ad-Server (lighttpd + php + openx)
  2. Машина: Tomcat + Servlet
  3. Машина: PostgreSQL-Server, статический контент (через lighttpd)

Все машины работают под управлением Debian Stable и подключены через VPN (openvpn). Поскольку оборудование очень старое (AMD Athlon 3000+ и 2 ГБ RAM на каждом), пришло время для изменений.

Эти серверы теперь должны быть заменены одной большой машиной (16 ГБ ОЗУ, большой процессор Intel с поддержкой VT, 5 IP-адресов).

Теперь возникает вопрос: следует ли мне по-прежнему разделять различные задачи с помощью виртуальных машин или я должен просто поместить все на машину как обычно. Где плюсы и минусы?

Я подумал о следующем:

Профессиональная виртуализация:

Con Virtualization:

Спасибо за любые подсказки.

Как отмечали многие, виртуализация хороша тем, что вы можете легко создать / восстановить снимок.

Я хотел бы остановиться на некоторых вещах. Кто-то упомянул о необходимости поддерживать несколько машин вместо одной. Можно значительно сократить это обслуживание, загрузив виртуальные машины по сети и монтируя разделы всего программного обеспечения из центральной точки. Таким образом, обновления / установки программного обеспечения автоматически переносятся на другие машины, устраняя большую часть дополнительного времени на обслуживание.

Есть также третий вариант: тюрьмы FreeBSD. - Это позволяет создавать отдельные среды без дополнительных затрат на виртуализацию. - Разделение намного выше, чем у обычного chroot GNU / Linux (все, даже сетевой уровень, разделено на уровне ядра) - каждая тюрьма может иметь свой собственный IP, и они на самом деле НЕ виртуализированы, а просто изолированные среды в ядре + файловая система. http://en.wikipedia.org/wiki/FreeBSD_jail

Я бы не стал отказываться от повышения безопасности как профессионал. Верно, что при определенных условиях можно выйти из виртуальных машин (ошибки в программном обеспечении vm - хотя они и исправляются; следите за обновлениями, как и с чем-либо еще). Безопасность - это уровни, а не один уровень отказоустойчив. Хотя простота имеет тенденцию к повышению безопасности, есть некоторые вещи, которые дают вам слишком много преимуществ, и, как я уже упоминал, все можно упростить, установив базовую систему из центрального места (может даже быть монтированием только для чтения):

Вот реальный пример:

Скажем, в приложении php есть уязвимость внедрения mysql, злоумышленник может использовать это для записи файлов на ваш сервер. (например: через синтаксис INTO OUTFILE sql) - Обычный подход - написать файл php, содержащий больше кода эксплойта, что еще больше нарушит работу сервера; в конце концов, скрипт php почти эквивалентен учетной записи оболочки, запущенной как пользователь, выполняющий его (пользователь, выполняющий процесс apache) - оттуда злоумышленник является только локальным эксплойтом, не имеющим полного корневого доступа. Если mysql находится в изолированной среде, скажем, на виртуальной машине, bsd jail или chroot-окружении, злоумышленник сможет записать свой php-код в файл, но он никогда не сможет выполнить файл, посетив url, так как служба mysql не будет иметь доступа ни к каким файлам, размещенным в apache.

Я бы предпочел виртуализацию, потому что

а.) Вы можете делать резервные копии сервера очень простым способом

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

c.) Вы можете идеально управлять ресурсами, чтобы дать одному серверу больший приоритет, чем другим.

ура

сорвал

виртуализация - это путь.

Таким образом, вы можете легко сделать резервную копию / восстановить или даже перенести виртуальную машину с одного сервера на другой с минимальным временем простоя.

при хорошем оборудовании, программном обеспечении и хорошей настройке потеря производительности минимальна. просто используйте ssh для всех коммуникаций и используйте отдельные локальные IP-адреса, недоступные из Интернета. просто и безопасно.

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

и это масштаб! гораздо проще добавить больше виртуальных машин, чем оборудование.

Кроме того, любой сбой / отключение одной виртуальной машины не повлияет на другие виртуальные машины.

Потеря производительности - Да, технически она есть. Вы или ваши пользователи это заметите? Я серьезно сомневаюсь в этом, если только это не какая-то сумасшедшая высокопроизводительная рабочая нагрузка, или вы ужасно чрезмерно выделяете виртуальные машины * (или пытаетесь втиснуть 5 виртуальных машин с «нормальным» выделением ОЗУ на старый существующий сервер. Не забудьте проверить свою оперативную память) использование - если вы все разделяете, вам не нужно, скажем, 512 мегабайт для сервера NTP, который по умолчанию имеет уровень выполнения 3. (Выделение ТОЛЬКО сервера NTP является чрезмерным, это был просто пример.)

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

* Пределы памяти - Зависит от вирт. решение, которое вы используете. Некоторые среды, такие как ESX / vSphere, позволяют выделять виртуальным машинам больше оперативной памяти, чем доступно физически. Если вы платите за эту функцию, ESX позволяет вам настраивать пулы ресурсов и автоматически настраивать ресурсы по мере необходимости с возможностью устанавливать приоритеты. Как и все, вы должны знать, как это работает, и какие компромиссы можно найти в конкретной среде.

Эта часть безопасности довольно относительна, так как вам придется защищать три среды вместо одной, и одно лишь разделение не может обеспечить большую безопасность.

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