Несколько серверов против 1 большой производительности сервера

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

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

Однако я бы рекомендовал иметь несколько физических машин из-за избыточности. Если у вас есть один физический сервер с миллионом виртуальных машин, то когда этот физический сервер умрет (и так будет), он потеряет миллион виртуальных машин.

Никогда не кладите все яйца в одну корзину!

3 машины с 2 ГГц процессором / 2 ГБ ОЗУ, и вы даете мне 1 машину с 3 процессорами 2 ГГц и 6 ГБ ОЗУ, это то же самое? Они сказали мне, что это так.

Нет, это не то же самое. в зависимости от платформы виртуализации будут накладные расходы (от 5 до 30%) от уровня гипервизора.

Каковы преимущества или недостатки обоих решений?

Это сложно без каких-либо подробностей, но вот несколько общих черт

Преимущества:

1. Лицензирование ОС может быть дешевле - многие поставщики либо не взимают, либо не взимают плату за лицензии на ОС VM
2. Переносимость - поскольку это виртуальная машина, если возникает проблема с масштабированием или требуется замена оборудования, ее тривиально заменить или добавить оборудование
3. Эффективность - если не все виртуальные машины используют все ресурсы, доступные на физических компьютерах, этот ЦП и ОЗУ тратятся впустую, если другой машине требуется больше ресурсов, пришло время купить новую систему. В виртуальных машинах системе, которой требуется больше ресурсов, может быть выделено больше ресурсов из пула доступных ресурсов (опять же, в зависимости от гипервизора это может произойти автоматически)
4. Среды Test/Dev могут быть точно такими же, как на производстве - большинство платформ позволяют вам клонировать компьютер в новую сеть, позволяя проводить исправления и т. Д., Проверенные в "реальной" среде, перед развертыванием в производственной среде.

Недостатки:

1. Устранение неполадок с производительностью более проблематично. Проще говоря, есть больше движущихся частей, которые влияют друг на друга. Есть ли проблема в гипервизоре, есть ли другие машины, вызывающие проблемы на хосте. Если повезет, IOPS - это узкое место, а это означает, что нужно покупать больше дисков или больше кеша.
2. Системные требования становятся немного выше - как правило, вы виртуализируете, потому что у вас недостаточно загруженные системы и вы хотите сэкономить немного (в долгосрочной перспективе) мощности и т. Д., Однако, из-за накладных расходов гипервизора, если вам нужны МГц, прежде чем вам может понадобиться МГц, - это зависит от гипервизор
3. Дополнительное управление - после виртуализации вы получаете ту же нагрузку на управление, что и раньше, плюс гипервизор. В зависимости от выбора гипервизора и количества звонков, это может быть проблемой
4. Стоимость - в краткосрочной перспективе, вероятно, будет дороже. Я бы не взял 3 системы и не поместил их в 1 физическую коробку, просто потому что, если эта единственная коробка не работает, мой сервис полностью мертв. Как правило, вам нужно 3 системы (в целях экономии - обычно дешевле выделить бюджет на дополнительные 1/3 накладных расходов, чем удваивать ресурсы).

В вашем конкретном случае 1 система может быть в порядке, если ваша служба будет недоступна, если какая-либо из этих систем не работает. Вы не добавили никакого риска в этом случае. Также звучит так, что этим системам не понадобится 6 ГГц вычислительной мощности, и в этом случае консолидация, безусловно, сэкономит деньги, поскольку вы не купили бы 6 ГГц только для этих 3 машин. Другая вещь, на которую нужно обратить внимание (и, конечно, не в последнюю очередь), это требования к вводу / выводу и потенциальная конкуренция за ввод / вывод.

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

Для URL взгляните на

Руководство по виртуализации Windows Server

Краткое руководство по внедрению виртуализации в малой среде

Они говорят о предоставлении вам одного шасси? Потому что, если это так, это все еще много отдельных серверов, просто содержащихся в жилой единице. Если они в буквальном смысле говорят об одном мощном сервере для управления партией, они (вероятно) не будут говорить о блейдах.

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

Однако есть крайности. Распространено разделять архитектуру по крайней мере на 2 уровня (интерфейс и база данных) или 3 уровня (интерфейс, приложение, база данных), но если вы не создаете абсолютного монстра системы, вы не часто нужно пойти дальше.

Можете ли вы предоставить больше информации о системе, которую вы разрабатываете? Какую платформу вы используете, ОС, язык, пользовательскую базу, жизненный цикл разработки?

РЕДАКТИРОВАТЬ: На основе ваших правок возникает еще один вопрос - каков ограничивающий фактор вашей текущей конфигурации? У вас заканчивается ОЗУ, или диски не читаются достаточно быстро, или у вас возникают проблемы с извлечением записей из БД достаточно быстро? максимальный процессор? Ограничивающий фактор того, что у вас есть сейчас, должен быть основным направлением для того, куда вам нужно идти с этим.

Они могут ошибаться в зависимости от:

• Вы используете 64-битные приложения / ОС / базы данных? Если этого не сделать и использовать 32-разрядную версию, вы не сможете использовать больше 4 ГБ, и все приложения будут использовать общий физический ОЗУ объемом 2 ГБ по умолчанию.
• Как насчет хранения? Этот сервер должен получить более сильный контроллер хранилища и столько же дисков, сколько у вас (x3). Возможно, нет, если вы не используете много памяти в своем решении
• Риск: когда вы потеряете / перезагрузите этот уникальный сервер, все исчезнет. Возможно также верно, если один из 3 не работает

Архитектура не так проста, как математика. Но мы не можем посоветовать вам больше без более подробной информации

Требования к мощности лучше всего определить с помощью нагрузочного тестирования и эмпирических данных. Не полагайтесь на прогнозы или догадки.

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

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

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

Блейд-серверы не делают хороших виртуальных серверов. Вы строго ограничены в пропускной способности и в памяти - два самых больших требования в виртуальной среде. Мы, как правило, запускаем около 4 виталов на ядро. Даже с лучшим блейд-шасси вы ограничены до 40 Гб сетевого подключения на блейд. Если вы используете 32 высокопроизводительных веб-виртуала, даже при наличии избыточной подписки вы все равно будете увеличивать количество подключений к каждой виртуальной сети. Если вы получаете 40 ГБ подключения к блейду, вам нужно пожертвовать сетью хранения данных и использовать конвергентную структуру, которая отбирает необходимую веб-полосу пропускания. Dell 910 или HP 585 делают хорошую платформу виртуализации. 1 сервер с 24 ядрами, 140 ГБ сети, работающей 96 виртуальных машин.

Далее вы хотите настроить виртуалы по размеру. Никогда не давайте виртуальному больше 1 ядра, всегда уменьшайте масштаб. Если вы добавите дополнительные ядра, причины опроса процессора и искусственная нагрузка и блокировки. Для хорошей виртуальной Apache мы используем 1 ядро, 1.8 Гб памяти и ~4 Гб сети. Под нагрузкой виртуальная скорость составляет около 2 ГГц, а сервер сообщает о загрузке 1,28. Наши виртуальные базы данных работают на 1 ядре, 6 ГБ памяти и ~4 ГБ сети.

Всегда отдельные приложения; вы не можете правильно настроить виртуальный, если вы продолжаете добавлять переменные. Один виртуальный должен иметь одну роль. Он должен выполнять одну вещь очень хорошо. DMZ. DMZ должна быть на отдельных физических виртуальных платформах. Для нормативных требований и защиты.