Техническая статья по SQL Server

Авторы: Санг Хсуэх (Sung Hsueh), Энтони Жонг (Antony Zhong), Мадхан Арумугам (Madhan Arumugam)

Технические редакторы: Клод Лоренсон (Claude Lorenson), Клиффорд Диббл (Clifford Dibble), Линдсей Эллен (Lindsey Allen), Самбит Самал (Sambit Samal), Сетху Калавакур (Sethu Kalavakur), Прем Мехра (Prem Mehra), Самир Теджани (Sameer Tejani), Иль-Сун Ли (Il-Sung Lee), Джек Ричинс (Jack Richins), Брайан Дьюи (Brian Dewey), Мэтью Джон (Mathew John), Джейми Рединг (Jamie Reding), Джонатан Моррисон (Jonathan Morrison), Омри Бахат (Omri Bahat), С. Муралидхар (S Muralidhar), Гайдн Ричардсон (Haydn Richardson)

Редактор: Бет Ингрэм (Beth Inghram)

Публикация: ноябрь 2009 г.

Применимо только к SQL Server 2008 и более поздним версиям

Сводка. Цель данного технического документа — обеспечить возможность выбора стратегий консолидации (виртуализация, использование нескольких баз данных или нескольких экземпляров) для приложений OLTP компонента SQL Server Database Engine, предоставив сведения о некоторых важных точках принятия решения, выявленных методом технического анализа. Некоторые основные определения и термины будут включены в документ для облегчения обсуждения, поскольку могут иметь различную трактовку в разных документах.

Версия 1.0

ВведениеВ общих чертах, консолидация — это объединение различных элементов в более крупные, эффективные и стабильные элементы. Применительно к отделу информационных технологий консолидация приводит к большей рентабельности, вызванной большим использованием ресурсов, стандартизацией и улучшенной управляемостью среды ИТ, а также (в последнее время) к большему акценту на «экологическую чистоту» среды ИТ за счет сниженного потребления энергии. Одним из наиболее важных компонентов в среде ИТ является база данных. Базы данных

широко используются на любом предприятии, поскольку они могут эффективно применяться для хранения данных в реляционном формате, а также могут служить основой для множества различных приложений. Поскольку базы данных являются основой множества бизнес-систем, ИТ-отделы могут легко потерять счет базам данных, подлежащим обслуживанию — любая из групп может создать базу данных для разрешения конкретной проблемы. Это ведет к быстрому росту количества баз данных и компьютеров, на которых хранятся их экземпляры; это явление известно как разрастание баз данных. Вследствие этого базы данных являются одним из основных кандидатов на консолидацию. При консолидации приложений баз данных следует рассмотреть следующие потенциальные стратегии: использование одного физического компьютера для размещения нескольких виртуальных машин, на которых выполняется ПО для управления данными Microsoft® SQL Server®; использование одного компьютера для размещения нескольких экземпляров SQL Server; использование одного экземпляра SQL Server для размещения нескольких баз данных. Каждая из этих стратегий имеет различные преимущества и недостатки, связанные с требованиями к безопасности и соответствию нормативам, требованиями к высокому уровню доступности и восстановлению при аварии, преимуществами при управлении ресурсами, уровнем плотности консолидации и уступками для достижения большей управляемости.

Этот документ предназначен для ответа на следующие вопросы.

Что следует учитывать при создании плана консолидации для среды? Каковы основные отличительные черты у этих трех режимов консолидации? Как можно использовать эти отличительные черты для выбора режима консолидации,

подходящего для среды?

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

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

2

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

Отсутствие места в центре обработки данных. Снижение затрат и увеличение эффективности. Стандартизация и централизация. Мобильность информационных технологий. Экологичность информационных технологий.

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

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

Снижение затрат и увеличение эффективностиПосле консолидации приложений аппаратное обеспечение будет использоваться более эффективно, что позволит уменьшить количество используемых компьютеров. Снижение капитальных и эксплуатационных расходов — это один из важнейших факторов, побуждающих компании прибегнуть к консолидации. Заменив старые компьютеры меньшим количеством новых с более совершенным аппаратным обеспечением, можно снизить объем занимаемого пространства, а также потребности в питании и охлаждении. Также минимизируется степень разрастания баз данных, поскольку компьютерами будет легче централизованно управлять. Централизованное управление обеспечивает больший контроль, снижая административные накладные расходы, расходы на техобслуживание, а также на лицензирование.

3

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

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

Экологичность информационных технологийПомимо снижения затрат энергии и затрат на охлаждение в последнее время все более важной становится необходимость в создании более «экологичной» рабочей среды. Эта мотивация схожа с необходимостью снижения затрат и увеличения эффективности, но конечной целью является снижение негативного влияния на окружающую среду, а не экономия средств. Консолидация играет важную роль в снижении уровня негативного воздействия центра обработки данных на экологию. При использовании меньшего количества компьютеров с меньшим временем простоя снижается потребление энергии и потребность в охлаждении. Новое аппаратное обеспечение также может обеспечить более рациональное использование энергии, поскольку в нем могут использоваться более эффективные энергосберегающие технологии. Возможности регулирования пропускной способности ЦП, доступные в операционной системе Windows Server®, а также новые функции в Windows Server 2008 R2, например возможность простоя ядер (core parking), помогают еще больше увеличить эффективность и снизить потребление энергии. Исследование, проведенное отделом информационных технологий корпорации Майкрософт, показало, что при консолидации на новых серверах требуемая мощность снижалась на 3 млн вольт-ампер (что

4

также позволило снизить оперативные расходы на 11 млн долларов в год). Дополнительные сведения см. в статье Практика использования экологически чистых информационных технологий (http://msdn.microsoft.com/ru-ru/architecture/dd393309.aspx).

— Приложения кандидатына консолидациюТермин приложение может обозначать широкий спектр служб. В этой статье будут приведены стратегии консолидации для приложений оперативной обработки транзакций (OLTP), сохраняющих данные в компоненте SQL Server Database Engine. В приложениях OLTP обычно наибольшую значимость имеет быстрое время ответа на небольшие, но наиболее частые запросы и обновления, затрагивающие относительно небольшие объемы данных. Примером такого приложения может служить система ввода заказов. Далее в этом документе термин приложение будет использоваться в основном для обозначения приложения OLTP, сохраняющего данные в базе данных SQL Server. Стратегия консолидации при этом применяется в основном для консолидации экземпляра SQL Server, поддерживающего это приложение.

На ранних шагах выполнения проекта консолидации будет создан профиль, который поможет определить приложения, являющиеся подходящими кандидатами для консолидации. Затем можно будет определить приложения, которые подходят под этот профиль. Приложения, являющиеся подходящими кандидатами на консолидацию, имеют следующие черты: малое использование ресурсов компьютера, умеренные требования к производительности, малая активность по разработке, а также низкие затраты на обслуживание. Еще один фактор, который следует учитывать, — это влияние приложения на сеть и задержки ввода и вывода. Этот фактор важен, поскольку после консолидации сеть и ресурсы хранения станут использоваться совместно.

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

Новые возможности SQL Server 2008 R2В SQL Server 2008 R2 доступны несколько функций, которые могут быть полезны при проведении консолидации.

Точка управления SQL ServerЧтобы облегчить управление разрастанием баз данных, в SQL Server 2008 R2 была добавлена функция точки управления SQL Server. Точка управления SQL Server — это единое место для управления и развертывания приложений SQL Server уровня данных, а также для регистрации экземпляров SQL Server с целью создания централизованных представлений использования

5

ресурсов. Можно выполнить регистрацию и просмотр как экземпляров SQL Server, выполняющихся на физическом компьютере, так и экземпляров в виртуальной машине. Точка управления также позволяет администратору применять политики для определения кандидатов на консолидацию. Дополнительные сведения о точке управления SQL Server см. в этой статье (http://msdn.microsoft.com/ru-ru/library/ee210548(SQL.105).aspx) в электронной документации SQL Server 2008 R2.

Приложение уровня данныхПриложение уровня данных — это новая единица разработки, развертывания и управления базами данных. База данных, зарегистрированная как приложение уровня данных, может управляться точкой управления SQL Server. Дополнительные сведения, включая общие сведения о приложениях уровня данных, см. в статье Основные сведения о приложениях уровня данных (http://msdn.microsoft.com/ru-ru/library/ee240739(SQL.105).aspx) в электронной документации по SQL Server 2008 R2.

64 Масштабируемость свыше логических процессоровВ SQL Server 2008 R2 была добавлена возможность поддержки более 64 логических процессоров. Эта возможность позволяет консолидировать большее количество приложений на одном компьютере. Следует заметить, что технология виртуализации Hyper-V™ имеет ограничение поддержки процессоров, не зависящее от Windows Server и SQL Server: в данный момент она поддерживает только 64 логических процессора в операционной системе узла и до 4 виртуальных процессоров в виртуальной машине.

Поддержка SysPrepSQL Server 2008 R2 предоставляет пользователю возможность установки ненастроенного снимка SQL Server 2008 R2 в процессе подготовки к запуску приложения SysPrep на снимке операционной системы Windows®. Это дает возможность создания стандартизированных снимков развертывания Windows с предустановленным SQL Server. Администраторы из отделов ИТ могут использовать SysPrep и SQL Server 2008 R2 для создания согласованной среды консолидации.

Вариантыконсолидации SQL ServerКаждый вариант консолидации предоставляет определенную степень изоляции, что может повлиять на число приложений, которые могут быть консолидированы на одном компьютере (в дальнейшем это именуется плотностью). Обычно более высокий уровень изоляции обеспечивает большую гибкость в применении функций, но также увеличивает затраты на управление и снижает порог плотности. При достижении большей плотности уровень изоляции снижается для оптимизации ресурсов и снижения затрат на управление. Это может увеличить

6

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

База данныхПри консолидации на уровне баз данных несколько приложений могут использовать (и хранить) данные в одном экземпляре SQL Server; каждое приложение содержится в собственной базе данных или в наборе баз данных. Поскольку все приложения находятся на одном экземпляре SQL Server, они также совместно используют уровень обновления SQL Server (то есть основную и дополнительную версию SQL Server), а также все объекты уровня сервера, например tempdb. В связи с этим все приложения также используют одну и ту же учетную запись службы и, как следствие, имеют один и тот же уровень доступа к системе размещения. Этот режим хорош в плане снижения затрат на управление и лицензирование, поскольку необходимо поддерживать меньшее количество экземпляров SQL Server. В SQL Server 2008 R2 базы данных могут быть зарегистрированы в качестве приложений уровня данных, которые будут управляться из точки управления SQL Server после того, как экземпляр SQL Server будет зарегистрирован в качестве управляемого экземпляра для централизованного управления.

ЭкземплярПри консолидации на уровне экземпляров несколько приложений переносятся на единый физический сервер с несколькими экземплярами SQL Server. Каждое приложение содержится в собственном экземпляре SQL Server. Этот вариант обеспечивает изоляцию двоичных файлов экземпляров SQL Server, позволяя приложениям иметь разный уровень обновления (уровень основной и дополнительной версии). Однако существует вероятность возникновения конфликтов приложений, поскольку системные ресурсы (в основном ЦП, память и ввод-вывод) используются совместно, хотя использование таких параметров, как affinity mask и max server memory, может обеспечить изоляцию ресурсов. Системное администрирование баз данных изолировано, однако системное администрирование Windows совместно используется для сервера размещения. Каждый экземпляр SQL Server на компьютере может быть зарегистрирован в точке управления SQL Server для администрирования.

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

7

уровня доступности с такими функциями, как Microsoft Hyper-V Live Migration. Хотя при использовании этого подхода снижается количество физических серверов, подлежащих управлению, количество снимков операционной системы и SQL Server остается таким же, как и в исходной среде. Экземпляры SQL Server в ВМ могут быть зарегистрированы в контрольной точке SQL Server для администрирования.

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

Требования к программному и аппаратномуобеспечениюМожет быть полезно создать стандартизированный тип сервера или конфигурацию для компьютера консолидации. Стандартизация может помочь упорядочить процесс приобретения дополнительных компьютеров; также она может предоставить общий набор требований к конфигурации и обслуживанию.

Потенциальные узкиеместаКонсолидация может создать узкие места в производительности приложений. Приложение, не прошедшее консолидацию, скорее всего имеет собственный выделенный физический компьютер с собственным ЦП, ОЗУ, хранилищем и сетевыми устройствами, а также крайне небольшим количеством других приложений, выполняющихся на нем. Консолидированное приложение размещается на компьютере, где все ресурсы используются совместно с другими приложениями. В связи с этим важно заранее оценить кандидатов на консолидацию и выбрать компьютер консолидации, имеющий многоядерный ЦП, большой объем памяти, а также достаточный объем хранилища и сетевые адаптеры, способные справиться с нагрузкой. В данном случае точка управления SQL Server может быть использована для просмотра данных журнала по использованию ЦП и хранилища. Детальное обсуждение методов настройки хранилища и слоев сети для сервера выходит за рамки данного документа, однако предполагается, что приложение не имеет ограничений ввода-вывода и имеется достаточная пропускная способность сети. Дополнительную информацию можно получить у поставщика оборудования.

8

Следует выбирать компьютеры с возможностью модернизации в будущем. В них должна быть возможность для добавления, например, дополнительных ядер ЦП, памяти и хранилищ; кроме того, они должны иметь свободные разъемы PCI для дополнительных контроллеров сети и хранилищ. Для выполнения виртуализации обычно рекомендуется использовать виртуальный жесткий диск фиксированного размера либо диск прямого доступа, поскольку использование динамических виртуальных жестких дисков может вызвать дополнительную нагрузку на подсистему ввода-вывода. Дополнительные сведения см. в разделе «Пример использования» ниже.

Новые технологии виртуализацииВ этом документе предполагается, что в качестве технологии виртуализации используется версия Hyper-V, прилагающаяся к Windows Server 2008 R2. Описываемые здесь функции относятся именно к этой версии. Те же принципы могут быть применимы к другим решениям виртуализации, однако они подробно обсуждаться не будут. Дополнительные сведения о Hyper-V см. в разделе Виртуализация с использованием Hyper - V (http://www.microsoft.com/windowsserver2008/ru/ru/hyperv-main.aspx).

Важно отметить, что Hyper-V имеет некоторые ограничения. Hyper-V поддерживается только в операционных системах узла с процессорной архитектурой x64; кроме того, для него необходимо присутствие аппаратной поддержки виртуализации (Intel VT или AMD-V) и аппаратное предотвращение выполнения данных (DEP, также называемое Intel XD bit и AMD NX bit). Также гостевая операционная система в данный момент может осуществлять доступ только к четырем виртуальным процессорам. Скорее всего это не вызовет проблем для большинства кандидатов на консолидацию, однако это стоит учитывать в случае, когда ожидается, что объем приложения по мере использования значительно возрастет.

Однако технология виртуализации постоянно совершенствуется. Одной из новых функций масштабирования и производительности, доступной в новых процессорах, является second-level address translation (SLAT, преобразование адресов второго уровня), также известная как nested paging (вложенное страничное преобразование). В своих процессорах компания AMD называет эту технологию NPT, Intel называет ее EPT. При выполнении консолидации методом виртуализации присутствие технологии SLAT необязательно, однако она может увеличить производительность приложения.

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

9

Рис. 1. Преимущества производительности при использовании процессоров SLAT

Эти показатели были получены с использованием компьютера с 16 ядрами; каждая ВМ была настроена на работу с 4 виртуальными процессорами и 7 ГБ ОЗУ и виртуальным жестким диском фиксированного размера в качестве хранилища. В качестве операционной системы узла использовалась Windows Server 2008 R2.

Для сравнения та же рабочая нагрузка была выполнена на реализации Hyper-V в Windows Server 2008 (показано красной пунктирной линией), в которой не использовалась технология SLAT. На графике видно, что пропускная способность упала после добавления трех виртуальных машин.

Оценка оборудованияПри выполнении консолидации рекомендуется иметь на целевом сервере консолидации как минимум столько же памяти, сколько использовалось приложением на исходном сервере. Следует заметить, что реальный минимальный объем памяти, необходимый приложению, может быть меньше общего объема памяти, доступного на сервере, если приложение работало без ограничений. Для выявления минимального объема памяти, необходимого для работы приложения без снижения производительности, может потребоваться выполнить анализ. Поэтому, если четыре приложения, консолидированные на одиночный сервер, ранее использовали 2 ГБ ОЗУ каждое, новый сервер должен иметь как минимум 8 ГБ ОЗУ. То же самое касается и процессоров.

10

При использовании более новых процессоров приложениям может потребоваться меньшее их количество; кроме того, многие приложения недостаточно используют вычислительную мощность ЦП. Это недостаточное использование также следует учитывать при планировании потребностей аппаратного обеспечения для проекта консолидации. Для начала рассмотрите все приложения, которые недостаточно используют ЦП, выберите то, которое задействует большее количество процессоров, и возьмите это количество процессоров за основу. Добавьте к нему процессоры, используемые приложениями, более полно использующими ЦП. На сервере консолидации должно присутствовать как минимум столько же процессоров. Для получения более точной оценки можно выполнить дальнейший анализ. Как было сказано ранее, всегда следует оставлять достаточно места для достижения максимальной производительности и для потенциального роста приложения. Хорошей начальной точкой будет объем использования примерно в 50 процентов. Точка управления SQL Server может быть использована для сбора и просмотра этих данных. Поставщик оборудования также может иметь инструменты оценки, которые помогут выбрать подходящий сервер консолидации.

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

Безопасность Высокий уровень доступности и аварийное восстановление Управление ресурсами Плотность Управляемость

Насколько важен каждый из этих факторов, зависит от приоритетов консолидации, заданных организацией.

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

11

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

Требование Виртуализация Экземпляр База данныхЭквивалентно размещению на выделенном физическом компьютере.

Да Нет Нет

Изоляция локальных учетных записей Windows

Да Нет Нет

Изоляция имен входа SQL Server Да Да НетИзоляция двоичных файлов SQL Server Да Да НетЗащита данных посредством шифрования дисков Windows BitLocker®

Да Частичная — изоляция между приложениями отсутствует

Частичная — изоляция между приложениями отсутствует

Защита данных посредством шифрованной файловой системы Windows

Да Да, если экземпляры имеют отдельные учетные записи служб

Частичная — изоляция между приложениями отсутствует

Защита данных посредством прозрачного шифрования данных Microsoft SQL Server

Да Да Частичная — все корневые сертификаты хранятся в базе данных master

Защита данных посредством разрешений Windows

Да Да Частичная — учетная запись и файлы службы SQL Server совместно используются экземпляром размещения

Защита данных посредством гранулярного шифрования SQL Server

Да Да Да

Защита данных посредством гранулярных разрешений SQL Server

Да Да Да

Аудит действий с использованием подсистемы аудита SQL Server

Да Да Да

Таблица 1. Сравнение соображений безопасности для различных режимов консолидации

12

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

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

Перед выбором подхода важно определить, где в приложении существуют определенные уязвимости. Определенные типы уязвимостей могут помочь исключить определенные подходы консолидации. Например, важно точно опознать жестко зафиксированные зависимости от учетной записи системного администратора SQL Server, других ролей сервера, учетных данных или других объектов сервера (например, tempdb или msdb), поскольку данные приложения имеют больший риск случайного разглашения информации. Эти приложения следует либо изменить, либо выполнить их консолидацию, не используя подход на уровне баз данных. Даже при отсутствии конфиденциальных данных эти зависимости увеличивают риск повреждения данных при взаимодействии приложений или риск перезаписи данных.

При хранении конфиденциальных данных важно опознать средства, используемые для их защиты. Это могут быть механизмы операционной системы, например Windows BitLocker и шифрованная файловая система Windows (EFS), или механизмы базы данных, например прозрачное шифрование данных SQL Server (TDE). Если приложение полагается на механизмы операционной системы, то консолидация на уровне баз данных или даже экземпляров может быть неприемлемой, поскольку они существуют в одной и той же среде операционной системы.

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

13

виртуализации с использованием технологии Hyper-V можно минимизировать запланированное время простоя посредством использования функции Live Migration, что позволит приложению оставаться активным во время запланированного перехода на другой ресурс. Другие решения высокого уровня доступности могут потребовать перезапуска приложений или повторного подключения клиентов после перехода на другой ресурс. Дополнительные сведения о функции Live Migration см. в техническом документе Общие сведения о функции Hyper - V Live Migration и ее архитектуре (http://www.microsoft.com/downloads/details.aspx?FamilyID=fdd083c6-3fc7-470b-8569-7e6a19fb0fdf&displaylang=ru). Для работы функции Live Migration также требуется чтобы на узлах использовались процессоры одного производителя. Подробные сведения см. в техническом документе по функции Live Migration.

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

Возможность Виртуализация Экземпляр База данныхПриложение остается активным во время запланированного простоя компьютера без перезапуска приложения

Да, посредством использования функции Live Migration (также можно использовать зеркальное отображение базы данных)

Да, посредством использования зеркального отображения базы данных

Да, посредством использования зеркального отображения базы данных

Приложение остается активным во время запланированного простоя компьютера без повторного подключения клиента

Да, посредством использования функции Live Migration

Нет Нет

Возможна миграция приложения между компьютерами без простоя (перезапуска или повторного подключения)

Да, посредством использования функции Live Migration

Нет Нет

Отказоустойчивый кластер SQL Server Да Да Частичная — переход на другой ресурс на уровне экземпляра

14

Доставка журналов SQL Server Да Да ДаЗеркальное отображение базы данных SQL Server

Да Да Да

Репликация SQL Server Да Да ДаТаблица 2. Сравнение функций высокого уровня доступности для различных режимов консолидации

Приложения, требующие схожие уровни доступности, можно разместить на одном компьютере. Такое группирование позволит более эффективно использовать аппаратное обеспечение, а также позволит сосредоточить ресурсы управления на поддержке этих приложений. Однако следует помнить, что технология высокого уровня доступности определяет уровень, на котором осуществляется переход на другой ресурс, и выбирать стратегию консолидации исходя из этого. В данном случае лучше всего использовать виртуализацию или выделенное аппаратное обеспечение. Например, если в качестве решения высокого уровня доступности используется отказоустойчивый кластер SQL Server, то использование кластеризации уровня базы данных будет не лучшим вариантом, поскольку переход на другой ресурс произойдет на уровне экземпляра. Если существуют приложения, консолидирующиеся на уровне базы данных, то им придется полагаться на мониторинг работоспособности, основанный на переходе всего экземпляра на другой ресурс. Стратегии консолидации уровня экземпляра или виртуализации позволяют приложениям использовать функции высокого уровня доступности, предоставляемые на уровне баз данных, такие как, например зеркальное отображение базы данных. Виртуализация позволяет приложению одновременно использовать функцию Live Migration, отказоустойчивый кластер SQL Server, зеркальное отображение базы данных и другие функции высокого уровня доступности для управления различными степенями и этапами перехода на другой ресурс и доступности. Наконец, поскольку все приложения совместно используют один компьютер, сбой в одном приложении может вызвать проблему на компьютере, что приведет к простою других приложений. В связи с этим для достижения большей степени изоляции во избежание ситуаций, когда сбои других приложений влияют на доступность, рекомендуется полагаться на виртуализацию или выделенное аппаратное обеспечение.

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

15

Виртуализация обеспечивает наиболее четкие границы, поскольку распределение ЦП и памяти должно быть задано для всего контейнера ВМ. Обе эти настройки могут быть изменены впоследствии, однако для внесения изменений может потребоваться перевести ВМ в автономный режим. Преимуществом этого подхода является то, что ресурсы содержатся в ВМ в изолированном состоянии (за исключением ЦП, ресурсы которого могут быть выделены избыточно), что снижает влияние чрезмерной загрузки одного приложения на другие приложения на сервере. Недостаток заключается в том, что ресурсы будут выделены ВМ вне зависимости от того, будут ли они использованы в полной мере. Кроме того, гостевая операционная система самой ВМ будет требовать затрат выделенных ресурсов. Операционная система узла также потребует дополнительного выделения ресурсов, однако этот объем будет достаточно мал (см. минимальные требования). Рекомендуется сопоставлять один виртуальный процессор с одним физическим. Чрезмерное выделение ресурсов процессора (например, привязка нескольких виртуальных процессоров к одному физическому) относительно безопасно, но в этом случае следует наблюдать за уровнем производительности. Чрезмерно выделять ресурсы памяти не следует, поскольку это может создать узкие места, которые могут повлиять на производительность. При использовании Hyper-V избыточное выделение памяти невозможно.

Режимы консолидации на уровне экземпляра или базы данных предоставляют прямой доступ к физическому аппаратному обеспечению консолидированного сервера, что может положительно повлиять на масштабируемость, например путем предоставления поддержки «горячей» замены ЦП или памяти (добавление логического процессора или системной памяти на сервер, работающий в оперативном режиме). Однако прямой доступ также создает возможность конфликтов за получение ресурсов. Для разрешения этих проблем в SQL Server присутствуют настройки: max server memory и CPU affinity mask, которые ограничивают объем памяти и количество логических процессоров, которые может использовать экземпляр SQL Server. Дополнительные сведения о настройке max server memory см. в разделе Параметры памяти сервера (http://msdn.microsoft.com/ru-ru/library/ms178067.aspx) в электронной документации по SQL Server 2008. Дополнительные сведения о настройке CPU affinity mask см. в разделе Параметр « affinity ma sk » (http://msdn.microsoft.com/ru-ru/library/ms187104.aspx) в электронной документации по SQL Server 2008.

Примечание. Параметр CPU affinity mask допускается использовать в виртуальной среде.

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

16

см. в разделе База данных tempdb (http://msdn.microsoft.com/ru-ru/library/ms190768.aspx) в электронной документации по SQL Server 2008.

Если между приложениями не существует конфликтов за использование объектов уровня сервера, то консолидацией уровня баз данных может быть проще управлять с точки зрения ресурсов, поскольку администратору понадобится настроить только один экземпляр SQL Server на каждом компьютере. Этот экземпляр сможет использовать все ресурсы компьютера без необходимости совместного использования ЦП или памяти с другими экземплярами SQL Server. Приложения в экземпляре могут вступать в конфликты за использование ресурсов, однако функция регулятора ресурсов, добавленная в SQL Server 2008, может быть использована для управления рабочей нагрузкой (группами запросов) посредством использования ограничений на потребление ресурсов ЦП и памяти и установки приоритетов для задач. Дополнительные сведения о регуляторе ресурсов см. в разделе Управление рабочими нагрузками SQL Server с использованием регулятора ресурсов (http://msdn.microsoft.com/ru-ru/library/bb933866.aspx) в электронной документации по SQL Server 2008. Регулятор ресурсов также может быть использован совместно с другими режимами консолидации для более точной настройки производительности экземпляра SQL Server, его невозможно использовать для управления ресурсами между несколькими экземплярами SQL Server или ВМ.

Замечание Виртуализация Экземпляр База данныхИзоляция tempdb Да Да НетИзоляция объектов уровня сервера (учетные данные, связанные серверы, msdb, задания агента SQL Server)

Да Да Нет

Четкие ограничения на использование ЦП и памяти для каждого приложения.

Да Да Нет

Использование регулятора ресурсов позволяет задавать приоритет запросов в одном экземпляре SQL Server

Да Да Да

ЦП с поддержкой «горячей» замены Нет Да ДаПамять с «горячей» заменой Нет Да Да Хранилище с «горячей» заменой Да Да ДаТаблица 3. Сравнение типов изоляции ресурсов для различных режимов консолидации

ПлотностьВ контексте консолидации плотность — это число приложений, которое может быть консолидировано на одном компьютере. ВМ, экземпляры SQL Server и базы данных SQL Server имеют различные объемы издержек на функционирование, что влияет на плотность консолидации. ВМ имеют самые высокие издержки, поскольку для каждого приложения присутствует полная операционная система. На уровне экземпляров ресурсы операционной

17

системы используются совместно, но каждое приложение имеет собственный независимый экземпляр, который является независимой службой. При консолидации на уровне базы данных издержки сводятся к минимуму, поскольку все остальные ресурсы используются совместно с другими базами данных в одном экземпляре. Также следует заметить, что в данный момент SQL Server имеет ограничение в 50 экземпляров на среду операционной системы (физическую или виртуальную). Hyper-V имеет ограничение в 64 ВМ на узел; экземпляр SQL Server имеет ограничение в 32 767 баз данных на экземпляр.

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

Убедитесь, что целевой сервер консолидации имеет дополнительный объем ресурсов. Не следует думать, что сервер будет работать на 100 процентов от средней производительности ЦП после консолидации; ему также необходимо иметь возможность обработки пиковых нагрузок, увеличения количества пользователей и увеличения производственных нагрузок. Целевой сервер должен иметь возможность поддержки одновременной рабочей нагрузки нескольких приложений в режиме пиковой нагрузки, а также возможность поддержки роста приложений. Обычно достаточно поддерживать загрузку ЦП на 50 процентов; этого хватит и на обработку пиковых нагрузок, и на поддержку постепенного роста.

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

Базовая линия вычисляется при загрузке в 100 %. Для пропускной способности превышение показателя в 100 % показывает, что приложению удалось достичь более высокого уровня пропускной способности (возможность обработки большего количества запросов); чем больше число, тем лучше результат. Для времени ответа значение менее 100 % показывает, что клиент может получить ответ от сервера быстрее, чем клиент получил ответ от сервера базового уровня.

18

Это число — процент общего времени, затраченного сервером базового уровня; более низкое число показывает, что приложение имеет более быстрое время ответа и меньшую задержку.

Метод консолидации Количество приложений

Пропускная способность

Время ответа Загрузка ЦП в системе размещения

Базовая линия (старое аппаратное обеспечение)

1 100 % 100 % 6 %

Виртуализация 24 +0,8 % 80 % 24 %Экземпляр 24 +0,6 % 58 % 20 %База данных 24 +0,9 % 53 % 16 %

Виртуализация 40 +0,6 % 95 % 45 %Экземпляр 40 +1,1 % 73 % 37 %База данных 40 +1,3 % 55 % 34 %Таблица 4. Результаты плотности, основанные на пропускной способности (чем выше, тем лучше) и времени ответа (чем ниже, тем лучше) для различных режимов

УправляемостьВиртуальные машины обладают значительной гибкостью управления, поскольку они имеют все возможности выделенного физического компьютера, а также могут легко управляться с использованием диспетчера виртуальных машин (ДВМ) Microsoft System Center и точки управления Microsoft SQL Server. ДВМ также имеет программу «физическое в виртуальное», называемую P2V. Эта программа принимает физический компьютер, преобразует его в ВМ, а затем развертывает ВМ на сервере Hyper-V. Это значительно снижает затраты на миграцию, поскольку весь процесс производится автоматически. Дополнительные сведения о том, как использовать программу P2V, см. в разделе P 2 V : преобразование физических компьютеров в виртуальные машины в ДВМ (http://technet.microsoft.com/ru-ru/library/cc764232.aspx) в документации по Microsoft System Center. Общие сведения о виртуализации с использованием Hyper-V и подробные сведения о конкретных преимуществах управляемости виртуализации см. в разделе Виртуализация с использованием Hyper - V (http://www.microsoft.com/windowsserver2008/ru/ru/hyperv-overview.aspx) на веб-узле Windows Server 2008 R2. Примерами функций, которые могут использоваться с виртуализацией, являются возможность легкого клонирования и развертывания приложений, а также использование функции Live Migration для быстрого развертывания приложений на нескольких компьютерах с целью динамического управления нагрузкой с нулевым временем простоя.

В SQL Server 2008 R2 доступны новые технологии, которые могут быть полезны при проведении консолидации. Как упоминалось ранее, все три подхода могут использовать точку управления SQL

19

Server в SQL Server 2008 R2 для получения централизованных представлений использования ресурсов и реализации политик в управляемых экземплярах. Другой новой функцией является возможность преобразования существующего приложения в определение приложения уровня данных; она обеспечивает удобный способ переноса схемы и имен входа приложения, поскольку определение приложения уровня данных является более портативным, чем полный экземпляр SQL Server, и включает в себя объекты области сервера, например имена входа. Следует заметить, что этот процесс не переносит данные конкретного приложения между серверами. Перенос данных необходимо выполнить отдельно, используя резервное копирование и восстановление или другой метод. Дополнительные сведения о методах преобразования существующей базы данных в определение приложения уровня данных см. в разделе Как извлечь DAC (http://msdn.microsoft.com/ru-ru/library/ee210526(SQL.105).aspx) в электронной документации по SQL Server 2008 R2. Затем приложение уровня данных может быть зарегистрировано в точке управления SQL Server для централизованного управления. В таблице 5 производится сравнение некоторых функций управляемости при различных режимах консолидации.

Возможность Виртуализация Экземпляр База данныхСоздание стандартных снимков Да Нет НетКлонирование среды на стадиях разработки, испытания и использования «одним щелчком»

Да — с использованием SCVMM

Нет Частичная — возможно клонирование приложений уровня данных

Миграция с малыми затратами Да — программа P2V Нет Частичная — зависит от того, насколько хорошо приложение размещено в базе данных

Динамическое повторное развертывание приложения без простоя

Да — с использованием функции Live Migration

Нет Нет

Может управляться точкой управления SQL Server

Да Да Да — если зарегистрировано как приложение уровня данных

Требует многократной установки SQL Server

Нет — можно использовать P2V или клонирование

Да Нет

Снижает число физических серверов, которое необходимо поддерживать

Да Да Да

20

Снижает число экземпляров Windows, которое необходимо поддерживать

Нет Да Да

Снижает число экземпляров SQL Server, которое необходимо поддерживать

Нет Нет Да

Таблица 5. Сравнение функций управляемости для различных режимов консолидации

Примечание относительно производительностиВ теории производительность может быть одним из определяющих факторов при выборе стратегии консолидации, учитывая то, что различные подходы имеют различные затраты на функционирование. Однако на практике проблемы производительности можно снизить, если был проведен правильный анализ и выбрано подходящее аппаратное обеспечение. Соображения о производительности были включены вместе с другими показателями, такими как плотность и управление ресурсами, потому что все приложения должны функционировать не хуже, чем они функционировали до консолидации. Если после миграции на целевой сервер консолидации приложение функционирует плохо, то можно использовать множество средств обеспечения производительности для его анализа и настройки. В самом худшем случае можно будет перенести приложение на менее перегруженный сервер или выделить для него дополнительные ресурсы, в которых есть потребность (ввод-вывод, ЦП, память и т. д.). Если приложение имеет строгое соглашение об уровне обслуживания (SLA) и требует определенного порога производительности, то оно может быть не лучшим кандидатом на консолидацию, хотя при наличии нового аппаратного обеспечения схожий уровень производительности можно будет поддерживать и при использовании консолидации.

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

21

Рис. 2. Общие сведения о дереве принятия решений

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

22

более детализованное поддерево (показано на рис. 3–6). Раздел безопасности показан на рис. 3, раздел высокого уровня доступности — на рис. 4, раздел управляемости — на рис. 5 и раздел управления ресурсами — на рис. 6. Если организация выполняет оптимизацию только для достижения высокой плотности, то лучшим решением будет консолидация на уровне баз данных; в нашем примере использования данные показали, что при консолидации уровня баз данных был достигнут наиболее высокий уровень плотности.

На рис. 7 приведено дерево принятия решений, предназначенное для определения возможности виртуализации приложения. Эта точка принятия решения часто достигается в ходе использования других деревьев. Следует заметить, что здесь рассматривается не вопрос «Следует ли выполнить виртуализацию?»; задача дерева на рис. 7 — определение технических границ для виртуализации. Ответ на вопрос «Следует ли выполнить виртуализацию?» необходимо получить, руководствуясь определенными значениями, выявленными в поддеревьях, а также определенными административными политиками организации.

Рис. 3. Раздел дерева принятия решений, затрагивающий безопасность

23

Рис. 4. Раздел дерева принятия решений, затрагивающий высокий уровень доступности

24

Рис. 5. Раздел дерева принятия решений, затрагивающий управляемость

25

Рис. 6. Раздел дерева принятия решений, затрагивающий управление ресурсами

26

Рис. 7. Раздел дерева принятия решений, предназначенный для определения возможности виртуализации приложения

Пример использованияНашей задачей было проведение эксперимента для выявления поведения каждого подхода при высокой плотности консолидации. Был выбран старый компьютер с четырьмя логическими процессорами и 8 ГБ доступной системной памяти. Для этого компьютера средняя целевая загрузка была 5–10 процентов. Консолидация приложения производилась на более новый 32-разрядный сервер с поддержкой технологии SLAT, 128 ГБ ОЗУ, 50 жесткими дисками на 135 ГБ и двумя сетевыми картами со скоростью 1 Гбит/с. Затем была выполнена попытка запуска как можно большего количества приложений на новом сервере, чтобы выяснить, сколько приложений сможет выполняться одновременно с тем же уровнем производительности, который достигался на старом компьютере базового уровня. Старый компьютер не испытывал перегрузок, поэтому ограничением производительности служил сам уровень рабочей нагрузки, а не нехватка ресурсов. Как было замечено ранее, считается, что на уровне баз данных будет самый высокий уровень плотности в связи с самыми низкими издержками, а при виртуализации уровень плотности будет самым низким в связи с самыми высокими издержками.

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

27

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

Для консолидации на уровнях баз данных и экземпляров приложения настраивались так, чтобы файлы данных и файлы журналов были разделены. Поскольку количество отдельных жестких дисков было недостаточным, они назначались по кольцевому списку. Все системные двоичные файлы размещались в одной секции. Соответствие процессоров не использовалось, но параметр max server memory использовался исходя из числа приложений. Каждому приложению было выделено 2,2 ГБ исходя из профиля использования памяти приложения на исходном компьютере. Для консолидации на уровне экземпляров это означает, что буферный пул каждого экземпляра был ограничен значением в 2,2 ГБ. Для консолидации на уровне баз данных для параметра max server memory задавалось значение, кратное 2,2 ГБ. Например, для 10 приложений параметру max server memory задавалось значение в 22 ГБ.

При виртуализационном подходе к консолидации каждой виртуальной машине присваивались отдельные виртуальные жесткие диски с фиксированным размером, размещенные на разных жестких дисках, выделенных отдельно для данных и отдельно для журналов. Системные двоичные файлы также хранились на отдельных виртуальных жестких дисках, размещенных на разных жестких дисках, отдельно от данных и журналов. Каждой ВМ был назначен один виртуальный процессор с 3 ГБ памяти. При самом высоком уровне плотности производилось чрезмерное выделение мощности процессоров, поскольку у физического компьютера имелось только 32, а мы использовали 40.

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

28

Все измерения производились с использованием стандартной рабочей нагрузки OLTP. Граница плотности считалась достигнутой, когда пропускная способность и время ответа стандартного приложения становились хуже исходного базового уровня. Было обнаружено, что все три режима консолидации масштабировались достаточно хорошо. Как это показывалось выше в разделе «Плотность», нам удалось достичь плотности приложений в 40 копий. После этого у нас закончились клиентские машины, и, как следствие, у нас нет результатов для объема более чем в 40 приложений. Как и ожидалось, консолидация на уровне баз данных имела наименьшие затраты и наибольшее пространство для дополнительных приложений, поскольку загрузка ЦП и время ответа были самыми низкими, а пропускная способность самой высокой при функционировании 40 приложений. Виртуализация имела несколько более высокое время ответа и загрузку ЦП, чем другие режимы, однако разница между ними была не слишком заметной. Все три режима показали немного более высокую пропускную способность, чем на базовом уровне; во всех случаях загрузка ЦП не превышала 50 процентов.

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

ЗаключениеВ определенной степени консолидация является бесконечным процессом. Постоянно появляются более новые компьютеры и аппаратное обеспечение, позволяющие достичь более высокой плотности консолидации, большего времени доступности приложений и лучшей производительности. Использование приложений будет возрастать; будут создаваться новые приложения на смену или в дополнение к старым. Также будут возникать новые факторы, побуждающие к консолидации, например политики «экологически чистых информационных технологий». В связи с этим очень важно создавать планы по консолидации не только исходя из текущих потребностей, но и делать прогнозы на будущее. Следует определить конкретные цели, которых организация пытается достичь, прибегая к консолидации, и выявить ключевые факторы, лежащие в основе этих целей. Различные режимы консолидации имеют различные преимущества, учитывая которые консолидация может быть использована не только для достижения конкретных краткосрочных целей (например, снижения издержек и освобождения места в центре обработки данных), но и для создания динамической и масштабируемой инфраструктуры ИТ, которая облегчит консолидацию в будущем и поможет поддержать рост компании.

29

Дополнительные сведения см. в разделах:

http://www.microsoft.com/sqlserver/: веб-узел SQL Server

http :// www . microsoft . com / sqlserver /2008/ ru / ru / server - consolidation . aspx : веб-узел по консолидации SQL Server

http :// www . microsoft . com / sqlserver /2008/ ru / ru / virtualization . aspx : веб-узел по виртуализации SQL Server

http :// technet . microsoft . com / ru - ru / sqlserver / : технический центр SQL Server

http :// msdn . microsoft . com / ru - ru / sqlserver / : центр разработки SQL Server

Помог ли вам этот документ? Оставьте свой отзыв. Оцените этот документ по шкале от 1 (плохо) до 5 (отлично). Почему он заслужил такую оценку? Пример.

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

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

Ваш отзыв поможет нам повысить качество нашей документации.

Отправить отзыв.

30