Моя команда разработчиков предложила структуру сервера для будущего проекта, который мы разрабатываем. Наша структура является «логической», что означает, что различные логические компоненты приложения (оно является распределенным) полагаются на разные серверы. Некоторые компоненты более важны, чем другие, и будут подвергаться большей нагрузке.
Наше предложение состояло в том, чтобы иметь по одному серверу на каждый компонент, но специалисты по аппаратному обеспечению предложили заменить различные машины на одну, более крупную, с виртуальными серверами. Они собираются использовать блейд-серверы.
Я совсем не эксперт, но мой вопрос к ребятам был такой: если нам нужны, например, 3 машины с процессором 2 ГГц / 2 ГБ оперативной памяти, и вы дадите мне 1 машину с 3 процессорами 2 ГГц и 6 ГБ ОЗУ, это та же? Мне сказали, что это так.
Это точно? Каковы преимущества или недостатки обоих решений? Каковы общепринятые передовые практики? Не могли бы вы указать на какой-нибудь URL-адрес, связанный с проблемой?
РЕДАКТИРОВАТЬ:
Еще немного информации. Приложение (Интернет / интранет) уже многоуровнево. У нас есть несколько серверов в демилитаризованной зоне, которые будут открывать страницы в Интернете, а базы данных находятся на их собственных машинах. Мы хотим разделить (а они хотят присоединиться) некоторые веб-серверы, которые в основном предоставляют веб-сервисы. Один из них - это DAL, который взаимодействует с уровнем базы данных, один - это наше приложение единого входа / профиля пользователя, которое вызывается один раз на страницу, а третий - клон того, что видно в Интернете, для использования в нашей локальной сети.
Учитывая, что их требования звучат немного "шерстяно" и на самом деле довольно низкие, я бы очень хотел виртуализировать это. Я бы начал всего с двух блейд-серверов и некоторого общего хранилища, затем вы могли создавать, изменять и удалять их виртуальные машины по мере необходимости, вы теряете большую производительность и получаете огромную степень гибкости, плюс вы можете масштабировать линейно и без влияние на пользователя.
Я думаю, что разумным способом было бы определить, где есть или могут возникнуть серьезные узкие места. Виртуальные машины отлично подходят для изоляции и, в зависимости от типа используемого гипервизора, могут иметь небольшое влияние на фактическую производительность. Виртуальные сети, вероятно, будут работать лучше, чем физические.
Однако я бы рекомендовал иметь несколько физических машин из-за избыточности. Если у вас есть один физический сервер с миллионом виртуальных машин, когда этот физический сервер выйдет из строя (а он умрет), миллион виртуальных машин выйдет из строя.
Никогда не кладите все яйца в одну корзину!
3 машины с процессором 2 ГГц / 2 ГБ оперативной памяти, и вы даете мне 1 машину с 3 процессорами 2 ГГц и 6 ГБ ОЗУ, это то же самое? Мне сказали, что это так.
Нет, это не то же самое. в зависимости от платформы виртуализации на уровень гипервизора будут накладные расходы (от 5 до 30%).
Каковы преимущества или недостатки обоих решений?
Сложно без подробностей, но вот несколько общих слов
Преимущества:
Недостатки:
В вашем конкретном случае 1 система мощь быть в порядке, если ваша служба не работает, если одна из этих систем не работает. В этом случае вы не добавили никакого риска. Также похоже, что этим системам не потребуется вычислительная мощность 6 ГГц, и в этом случае консолидация, безусловно, сэкономит деньги, поскольку вы не будете покупать 6 ГГц только для этих 3 машин. Еще одна вещь, на которую вам нужно обратить внимание (и, конечно, не в последнюю очередь) - это требования к вводу-выводу и потенциальные конфликты ввода-вывода.
В качестве альтернативы, если эти веб-службы могут сосуществовать на одном компьютере, вы также можете рассмотреть возможность создания двух виртуальных машин с одними и теми же службами и либо использовать кластеризацию, либо просто оставить одну в режиме ожидания, если возникнет проблема.
Для URL-адресов посмотрите
Руководство по виртуализации Windows Server
Краткое руководство по реализации виртуализации в небольшой среде
Они говорят о предоставлении вам единого лезвие шасси? Потому что, если это так, это все равно множество отдельных серверов, просто содержащихся в единице жилья. Если они буквально говорят об одном мощном сервере для запуска всей партии, они (вероятно) не будут говорить о лезвиях.
В любом случае, игнорируя лезвие, вот моя точка зрения: если ваше приложение успешно масштабируется на нескольких небольших серверах, сделайте это. Меньшие серверы дешевле покупать, вы можете легко масштабировать их, добавляя больше серверов, и отдельные приложения будут работать более надежно, если у них есть сервер в значительной степени сам по себе.
Однако есть крайности. Довольно часто архитектуру разделяют как минимум на 2 уровня (интерфейс и база данных) или 3 уровня (интерфейс, приложение, база данных), но если вы не создаете абсолютного монстра системы, вы не часто нужно выйти за рамки этого.
Можете ли вы предоставить дополнительную информацию о разрабатываемой вами системе? Какую платформу вы используете, ОС, язык, пользовательскую базу, жизненный цикл разработки?
РЕДАКТИРОВАТЬ: На основании вашего редактирования возникает еще один вопрос - что является ограничивающим фактором вашей текущей конфигурации? У вас заканчивается ОЗУ, или диски читаются недостаточно быстро, или у вас возникают проблемы с достаточно быстрым извлечением записей из БД? максимум CPU? Фактором, ограничивающим то, что у вас есть прямо сейчас, должен быть главный ориентир, куда вам нужно идти с этим.
Настройка одного сервера может быть как выгодной, так и очень плохой. Вы можете поддерживать один сервер проще, чем три, и когда он выходит из строя, все вместе с ним.
При настройке нескольких серверов вы можете разделить их, но это может быть бесполезно, если один из ваших 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 должна находиться на отдельных физических виртуальных платформах. Для нормативных требований и защиты.