У меня есть сервер с двумя четырехъядерными процессорами с тактовой частотой 2,6 ГГц и 32 ГБ оперативной памяти (вместе с множеством хранилищ). У меня есть приложение Django, которое я собираюсь запустить на этом сервере, и я хотел бы настроить (используя VMWare) 2 сервера БД (Postgres на Ubuntu), 2-3 сервера приложений (Django + Nginx + еще несколько вещей на Ubuntu ), сервер задач (Celery и RabbitMQ в Ubuntu) и несколько других второстепенных виртуальных машин для небольших задач.
Мне интересно, будут ли запросы балансировки нагрузки между 2-3 серверами приложений (которые будут выполнять базовые функции Django, такие как доступ к БД, несколько изменений размеров изображений и рендеринг шаблонов), будут разумными, или я буду лучше иметь 1 большую (много оперативной памяти) виртуальную машину для сервера приложений? Я не знаю, какие накладные расходы (или, возможно, выигрыш) возникают при таком разделении одного физического сервера, если таковые имеются. Я думаю, вероятно, 4 ГБ или около того для каждой из виртуальных машин, что оставит 8 ГБ свободными для других второстепенных задач.
Прежде чем начать, я должен упомянуть, что все, что вы собираетесь прочитать, на самом деле просто отправная точка в лучшем случае. Это так много болтовни, что у вас действительно есть что-то, на что стоит посмотреть и измерить, чтобы найти настоящий характеристики производительности вашей системы при заданной нагрузке. Как говорится, дважды отмерь, один раз отрежь (потрати / построй).
Я заметил четыре вещи. Первая - это цитата:
и несколько других второстепенных виртуальных машин для небольших задач
Я бы объединил их в одну «служебную» виртуальную машину. Это сэкономит накладные расходы ОС для вашей системы. Совместное использование ОЗУ в VMware для такого рода вещей - это хорошо, но не идеально. По крайней мере, вы сэкономите некоторые накладные расходы на управление.
Во-вторых, балансировка нагрузки на одном физическом хосте немного странная ... я думаю, что с одним хостом более подходящей будет одна виртуальная машина с теми же ресурсами, которые вы использовали бы для трех меньших. Однако это мое мнение, и я подозреваю, что другие могут не согласиться.
Мне бы очень хотелось, чтобы вы здесь стреляли как минимум по двум, а лучше с тремя-пятью физическими хозяевами. Машины должны быть подготовлены таким образом, чтобы у вас было достаточно мощности для работы виртуальных машин, необходимых для поддержания вашей системы в рабочем состоянии в случае полного отказа одного физического устройства. Вот когда балансировка нагрузки действительно хороша, потому что теперь вы настроили объединить балансировку нагрузки производительности с ядром инфраструктуры высокой доступности. К сожалению, похоже, что вы уже совершили здесь покупку, которой может быть больше, чем вам нужно в какой-либо одной системе для этой настройки. Но в качестве примера того, для чего я хочу, чтобы вы снимались:
HOST1 HOST2 HOST3 ----- ------ ------- DjangoApp1 DjangoApp2 DjangoApp3 DB1 DB2 Celery/RabitMQ1 Celery/RabbitMQ2 (warm-idle) UtilityServer2 (warm-idle) UtilityServer1
Вышеупомянутая система позволяет продолжить работу с минимальными затратами при выходе из строя какого-либо физического хоста. Однако эта настройка все еще довольно проста. По мере того, как вы становитесь больше, ваши серверы БД в конечном итоге будут нуждаться в собственных физических хостах, вам понадобится HAProxy в смеси где-то для обработки балансировки, SAN (или два) где-то сзади для хранения и, возможно, кэширующий сервер (или пара или больше ) где-то тоже. Но это то, к чему вы можете стремиться после того, как начальный продукт будет запущен.
Далее, 4 ГБ - это на самом деле довольно много оперативной памяти для служебного сервера и экземпляров Celery / RabbitMQ. Скорее всего, вы можете обойтись менее чем в два раза меньше, чем для этих ящиков, а 4 ГБ даже могут быть немного перебором для django, в зависимости от того, какой окажется ваша фактическая нагрузка. Это освобождает оперативную память для серверов баз данных, которым часто требуется любая оперативная память, которую вы можете для них сэкономить.
Наконец, я хотел бы услышать ваше определение «большого объема памяти». Если вы просто уронили туда жесткий диск емкостью 2 ТБ или даже набор из 4 в RAID 10, вы можете обнаружить, что это не тот размер Здесь важно не меньше, чем скорость. Ваша база данных, в частности, будет съедать производительность ввода-вывода. Убедитесь, что вы справляетесь с этим хорошо, иначе легко ошибиться. Если вы используете SAN, это нормально ... но если нет, в приведенном выше примере минимум каждый из физических хостов должен представлять собой коробку 2U с минимум 7 традиционных дисков для RAID 10, включая горячий резерв для немедленного начала восстановления в случае отказа диска, или коробку 1U с 4 высокопроизводительными твердотельными накопителями (снова RAID 10) . Возможно, вам даже понадобится больше информации о системах, поддерживающих ваши серверы баз данных.
На это действительно нет хорошего ответа.
Производительность будет зависеть от вашего оборудования и потребностей ваших приложений.
Обычно используются виртуальные машины, потому что они значительно упрощают обслуживание и администрирование машин, когда у вас не все работает в одной ОС. Гипервизоры без дополнительных компонентов (например, Vmware ESXi) на современном оборудовании делают немало, чтобы минимизировать любые накладные расходы, связанные с виртуализацией.