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

Какова цель физического автономного сервера

Какова цель отдельного физического сервера по сравнению с сервером, на котором размещено несколько логических серверов?

Я имею опыт разработки и постоянно строю несколько клиент-серверных систем. Однако я никогда не вникаю в физические аспекты ....

Часто я указываю веб-сервис на приложение базы данных через IP-адрес, то есть адрес, на котором находится приложение базы данных ...

Теперь это понятие физического против виртуального меня беспокоит - я указываю на виртуальный сервер или на физический? Имеют ли физические серверы конкретное назначение - например, просто для хранения и т. Д., Или они также используются на практике для размещения приложений?

Что ж, виртуальные машины должны на чем-то работать, верно?

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

Что касается второй части вашего вопроса, я бы позаимствовал и отослал вас к Собственная архитектура SE

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

От пользователя / dev (и в данном случае от разработчика является с точки зрения пользователя), разница между правильной работой виртуальной машины и физической машины очень расплывчата. Это просто машина, и вы используете ее так же, как и физическую систему. Преимущество виртуальных машин, конечно же, заключается в консолидации (вы можете запускать много виртуальных машин на одной машине) и в способности адаптироваться к нагрузкам, если вам внезапно понадобится приспособиться к более высокому трафику. Физические машины лучше, если у вас есть потребность в настройке довольно большой инфраструктуры и вы можете выделить одну или несколько машин для роли.

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

Забавно, что вы спросите. Я просто мучился, виртуализировать ли мой цветной ящик, но в конце концов отказался от этого. Плюсы были очевидны: это дешевле, гибче, оборудование обслуживает кто-то другой, я получаю виртуализированный «консольный» доступ вместо того, чтобы платить за KVM на основе IP (или привод в колокол) и так далее.

В конце концов, я решил остаться физическим.

Первой серьезной причиной было то, что я хотел использовать USB-устройство под названием Ключ энтропии чтобы раздуть пул энтропии моего сервера. Я знаю, что большинство технологий виртуализации позволяют маршрутизировать физические (USB) устройства на конкретный VPS, но это не стандартная функция большинства пакетов виртуализации.

Вторая серьезная причина заключалась в том, что мне нужна была степень контроля над тем, кто использует мое оборудование, чего я не могу получить с помощью виртуализации. Физический доступ - это всегда проблема, но мой коло физически довольно безопасен, камеры установлены по всему этажу DC и так далее: даже сотруднику будет сложно получить к нему доступ и не оставить следов. Если он просто сидит на оборудовании dom0, он может наблюдать за всем, что делает мой сервер, и, вполне возможно, не оставляет следов. Что сказать, я параноик.

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

Я полагаю, что в конечном итоге все сводится к контролю или удобству. Если вы предпочитаете первое, оставайтесь физическими; если вы предпочитаете последнее, виртуализируйте.

Что ж, в дополнение к тому, что уже было сказано, я хочу добавить, что физические серверы по-прежнему лучше виртуальных в размещении приложений с большой нагрузкой с высокой степенью использования жесткого диска - баз данных и кластерных вычислительных систем (включая получение популярных распределительных баз данных NoSQL). В основном потому, что виртуальные серверы обычно имеют проблемы с использованием RAID (особенно в системах Hyper-V). Однако с виртуальными машинами вы обычно получаете немного более легкое развертывание и высокую доступность, поскольку машины можно переносить из одного физического блока в другой без каких-либо изменений конфигурации или с небольшими изменениями конфигурации. Виртуальные машины также довольно хорошо работают с размещением ящиков брандмауэра и терминальных серверов / удаленных приложений, поскольку вы обычно хотите, чтобы они хранились на отдельном компьютере по соображениям безопасности или производительности.

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