Я должен признать, что мы немного отстаем в игре с виртуализацией. В настоящее время у нас нет ничего виртуализированного, но я пытаюсь это изменить.
Мы хотим немного попрактиковаться в виртуализации и прочувствовать ее, поэтому я собираюсь предложить в следующем году получить сервер и виртуализировать 3 недостаточно используемых (и невероятно старых) некритичных сервера.
Я знаю, что виртуализация - это все о SAN, но, к сожалению, у нас ее нет (все наши серверы DAS). У меня возникает вопрос: если я получу сервер (вероятно, HP DL380 с некоторым описанием) с DAS, будут ли в результате сильно пострадать гостевые виртуальные машины (недостаточно используемые, не забывайте)? В настоящее время я думаю, что в качестве хоста я выберу Hyper-V Server 2008 R2, если это имеет значение.
Я кратко опишу, что делают 3 сервера ниже. Я знаю, что это не точная наука, но, грубо говоря, как вы думаете, DAS будет в порядке?
Сервер 1
Использует устаревшую систему управления персоналом, доступ к которой может быть один или два раза в неделю. У него есть серверная часть SQL Server 2000, которая также работает на этом сервере. Это архаично (я не знаю, когда HP прекратила брендировать ProLiants Compaq, но на передней панели с гордостью отображается логотип Compaq).
Сервер 2
Запускает несколько эмулированных принтеров для нашей системы AS / 400 и распечатывает результат на некоторых реальных принтерах. Это успешно работает на старом ПК с W2K3 и 2 ГБ ОЗУ.
Сервер 3
Запускает сервер для продукта бизнес-аналитики, однако на самом деле все, что он делает, это в 4:00 утра импортирует тонны данных из нашей AS / 400 и компилирует их в файл (это занимает около получаса). Затем около 15 пользователей периодически (возможно, раз в несколько дней) загружают этот скомпилированный файл (~ 100 МБ) на свой локальный компьютер. Загрузка инициируется пользователем, поэтому реально определенного шаблона доступа нет.
Это также на ПК с 2K3, но с 3 ГБ оперативной памяти.
Обновить
Мы уже несколько раз рассматривали виртуализацию, но из-за отсутствия SAN и множества преимуществ, которые она приносит, мы каждый раз отклоняли виртуализацию как вариант.
Я знаю некоторые подводные камни установки этих виртуальных машин на DAS (отсутствие высокой доступности и т. Д.) - и это нормально для этих машин. Если хост откажет, это будет скорее неудобство, чем полномасштабная катастрофа.
Я смотрю на этот скорее как на проект консолидации, чем на что-либо другое. В любом случае 3 сервера планируется заменить в следующем году, и, как я уже сказал, они довольно стареют, в основном простаивают и представляют собой большие башенные машины, использующие много места и электроэнергии. На мой взгляд, 3 новых сервера (пусть даже базовых) - это слишком много для машин, которые весь день делают очень мало.
На ваш вопрос можно частично ответить, посмотрев на счетчики производительности для операций ввода-вывода на машинах, которые вы пытаетесь перейти на виртуальные. Посмотрите, сколько операций ввода-вывода в секунду (IOPS) требуется каждой. Помните, что каждый физический диск рассчитан на несколько десятков операций ввода-вывода в секунду. Теперь выберите размер вашей системы виртуализации, чтобы поддерживать этот уровень ввода-вывода. Вы будете знать, сколько «шпинделей» вам нужно. Используйте RAID-контроллер для распределения нагрузки по дискам.
Обратите внимание, что ничего из этого не говорит о SAN. Сети SAN хороши, но в основном они предоставляют то, о чем вы не упомянули: высокую доступность, резервное копирование, многоуровневое хранение, отказоустойчивость, межсайтовое аварийное восстановление, быстрое развертывание и т. Д.
Самая примечательная часть всего этого заключается в том, что если вы используете DAS, отказ физического сервера, к которому подключен DAS, представляет собой отказ всех виртуальных машин, которые были размещены на нем. С SAN, используя кластер вычислительных хостов, все подключенные к SAN, вы можете пережить отказ физического хоста, переместив виртуальную машину на новый хост.
Еще одна стратегия, позволяющая выжить при сбое этого физического хоста, - это частое или хотя бы достаточно частое резервное копирование приложений и операционных систем на виртуальных машинах, чтобы вы не возражали потерять то, что произошло после последнего резервного копирования.
Твой выбор. DAS может дать вам необходимую производительность (с учетом того, что вы описали).
1. Производительность По моему опыту, хранилище SAN и хранилище DAS имеют разные характеристики, из-за которых производительность трудно измерить объективно, поскольку рабочие нагрузки, как правило, зависят не только от одной метрики (например, времени доступа), а скорее от переменного сочетания времени доступа, пропускной способности, чтения и записи. и т. д. Это очень сложная картина. Основные преимущества SAN, IMO, заключаются в том, что ваши данные доступны для нескольких хостов одновременно (с учетом кластеризации / высокой доступности) и унификации хранения ваших данных, что упрощает управление и обслуживание. Короче говоря, я бы не стал так сильно беспокоиться о производительности DAS.
2. Доступность и стоимость SAN
Вам не обязательно использовать готовые дискретные решения SAN. Многие люди создают свои собственные, поскольку набор обычных серверных частей может дать вам полностью функциональную систему SAN. Вот один из путей к этому:
Поддержка поставщика может быть приобретена для OpenFiler и вашего оборудования, если ваша компания настаивает на этом. Вы также можете настроить несколько хостов OpenFiler с DRDB, чтобы предоставить вам возможности высокой доступности и избыточности.
Один из них мы запускаем в производство уже больше года, и он очень надежный.
DAS обычно должен быть быстрее, чем некоторые FC SAN, и определенно быстрее, чем iSCSI SAN. Вы получаете скорость соединения SAS (3 Гбит / с, а в более новых коробках - 6 Гбит / с)
Обратной стороной DAS является не скорость или стабильность, а масштабируемость, потому что количество портов на DAS ограничено, поэтому вы не можете подключить к нему слишком много хостов.
Когда мы начинали с виртуализации в 2007 году, мы имели в виду drbd. Итак, мы начали с пары серверов, в которой было 5 внутренних 3,5-дюймовых SAS-дисков (настроенных как RAID 5, обеспечивающих хранение 500 ГБ нетто). Поскольку наши серверы баз данных работают в другом кластере (подключенном к SAN), наши виртуальные системы не работают. Не делайте много disk io - что делает это возможным - даже с 100 Мбит Ethernet для репликации drbd.
С такой настройкой мы смогли предоставить более 20 HA-VM (паравиртуализированный XEN). Дисковый ввод-вывод или производительность диска никогда не были проблемой. В настоящее время DAS даже быстрее, чем локальное хранилище. Так что для вашей установки всего с тремя низкопроизводительными серверами с низким дисковым io я бы сказал, что даже DAS слишком велик.
Поскольку вы используете в основном W2K, вы можете играть с Linux KVM или Windows Hyper-V. Или администраторам Windows нравится последнее (и они сами используют DAS, подключенный к двум серверам). С Linux KVM я бы использовал DRBD как внутреннюю часть хранилища (DAS или внутренние диски).
Просто примечание о SAN / DAS: мы подключили некоторые из наших серверов виртуализации к SAN - для тех гостей, которые теперь используют базы данных с интенсивным вводом-выводом. Но: SAN не быстрее внутренних дисков - он просто распределяет io на большее количество дисков - то же самое можно сказать и о DAS.
Я вижу реальное преимущество SAN в другой области: он использует свою собственную коммутационную матрицу, которая (в моей работе) не имеет ничего общего с IP-маршрутизаторами и коммутаторами - и намного более стабильна. С точки зрения кластера / га вы получаете другое - действительно независимое - соединение.