Поиск на сайте: Расширенный поиск


Новые программы oszone.net Читать ленту новостей RSS
CheckBootSpeed - это диагностический пакет на основе скриптов PowerShell, создающий отчет о скорости загрузки Windows 7 ...
Вы когда-нибудь хотели создать установочный диск Windows, который бы автоматически установил систему, не задавая вопросо...
Если после установки Windows XP у вас перестала загружаться Windows Vista или Windows 7, вам необходимо восстановить заг...
Программа подготовки документов и ведения учетных и отчетных данных по командировкам. Используются формы, утвержденные п...
Red Button – это мощная утилита для оптимизации и очистки всех актуальных клиентских версий операционной системы Windows...
OSzone.net Microsoft ИТ-инфраструктура Виртуализация Виртуализация: Консолидация аппаратного обеспечения RSS

Виртуализация: Консолидация аппаратного обеспечения

Текущий рейтинг: 4 (проголосовало 1)
 Посетителей: 1103 | Просмотров: 1403 (сегодня 0)  Шрифт: - +

Традиционно считается, что консолидация всегда просто нужна для сокращения числа серверов в центре обработки данных. С тех пор мы поняли, что консолидация это не просто сокращение объема оборудования.

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

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

Поддержка или замена

В качестве примера возьмем используемую только для разработки ферму виртуальных серверов. Исходные данные: разработчикам нужно создать ферму виртуальных серверов, на которой они могли бы тестировать новые приложения. Эта ферма не будет обслуживать пользователей из производственной среды. От нее не требуется доступность 24 часа семь дней в неделю. Вместе с тем, вы недавно по плану вывели из эксплуатации целую стойку блейд-серверов.

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

При правильной консолидации рабочих нагрузок и оптимизации оборудования практически наверняка возникнет избыток оборудования, которое нужно выводить из эксплуатации.  Именно оно попадает в список того, что нужно выбросить.

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

Вариант №1. Кластеризация

В этом варианте серверная среда кластеризуется на нескольких аппаратных платформах. Создайте четыре серверных операционных системы на 12 блейд-серверах. Каждая ОС будет охватывать три блейд-сервера, причем два будут оставаться в автономном режиме и использоваться как «резерв».

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

С выходом Windows Server 2003 технологии кластеризации Microsoft значительно усовершенствовались. Есть также много сторонних поставщиков кластерных решений. Кластеризация предоставляет необходимые мощности, снижая при этом риск сбоя оборудования путем распределения операционной системы среди нескольких аппаратных платформ.

Вариант №2. Кластеризация с виртуализацией

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

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

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

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

Автор: Томас Олзак  •  Иcточник: TechNet Magazine  •  Опубликована: 11.10.2011
Нашли ошибку в тексте? Сообщите о ней автору: выделите мышкой и нажмите CTRL + ENTER


Оценить статью:
Вверх
Комментарии посетителей
Комментарии отключены. С вопросами по статьям обращайтесь в форум.