SQL Server Consolidation Guidance - Center

Техническая статья по 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 виртуальных
процессоров в виртуальной машине.
Поддержка SysPrep
SQL 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
Да
Да
Да
Частичная —
изоляция между
приложениями
отсутствует
Да, если
экземпляры
имеют
отдельные
учетные записи
служб
Да
Защита данных посредством
разрешений Windows
Да
Да
Частичная — все
корневые
сертификаты
хранятся в базе
данных master
Частичная —
учетная запись и
файлы службы
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-85697e6a19fb0fdf&displaylang=ru). Для работы функции Live Migration также требуется чтобы на узлах
использовались процессоры одного производителя. Подробные сведения см. в техническом
документе по функции Live Migration.
Все три подхода могут использовать различные функции высокого уровня доступности,
встроенные в SQL Server, например отказоустойчивый кластер, зеркальное отображение базы
данных и репликацию. Модуль перехода на другой ресурс может различаться в зависимости от
используемой функции. В таблице 2 сравниваются эти функции в различных режимах
консолидации.
Возможность
Приложение остается активным во время
запланированного простоя компьютера
без перезапуска приложения
Приложение остается активным во время
запланированного простоя компьютера
без повторного подключения клиента
Возможна миграция приложения между
компьютерами без простоя (перезапуска
или повторного подключения)
Отказоустойчивый кластер SQL Server
14
Виртуализация
Да,
посредством
использования
функции Live
Migration
(также можно
использовать
зеркальное
отображение
базы данных)
Да,
посредством
использования
функции Live
Migration
Да,
посредством
использования
функции Live
Migration
Да
Экземпляр
Да,
посредство
м
использова
ния
зеркальног
о
отображен
ия базы
данных
Нет
База данных
Да, посредством
использования
зеркального
отображения базы
данных
Нет
Нет
Да
Частичная —
переход на другой
ресурс на уровне
экземпляра
Нет
Доставка журналов 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 mask» (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
24
24
+0,8 %
+0,6 %
+0,9 %
80 %
58 %
53 %
24 %
20 %
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, см. в разделе P2V: преобразование физических компьютеров в
виртуальные машины в ДВМ (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
Снижает число физических
серверов, которое необходимо
поддерживать
20
Нет — можно
использовать P2V
или клонирование
Да
Экземпляр База данных
Нет
Нет
Нет
Частичная —
возможно
клонирование
приложений уровня
данных
Нет
Частичная — зависит
от того, насколько
хорошо приложение
размещено в базе
данных
Нет
Нет
Да
Да
Да — если
зарегистрировано как
приложение уровня
данных
Нет
Да
Да
Снижает число экземпляров
Нет
Да
Да
Windows, которое необходимо
поддерживать
Снижает число экземпляров SQL
Нет
Нет
Да
Server, которое необходимо
поддерживать
Таблица 5. Сравнение функций управляемости для различных режимов консолидации
Примечание относительно производительности
В теории производительность может быть одним из определяющих факторов при выборе
стратегии консолидации, учитывая то, что различные подходы имеют различные затраты на
функционирование. Однако на практике проблемы производительности можно снизить, если был
проведен правильный анализ и выбрано подходящее аппаратное обеспечение. Соображения о
производительности были включены вместе с другими показателями, такими как плотность и
управление ресурсами, потому что все приложения должны функционировать не хуже, чем они
функционировали до консолидации. Если после миграции на целевой сервер консолидации
приложение функционирует плохо, то можно использовать множество средств обеспечения
производительности для его анализа и настройки. В самом худшем случае можно будет перенести
приложение на менее перегруженный сервер или выделить для него дополнительные ресурсы, в
которых есть потребность (ввод-вывод, ЦП, память и т. д.). Если приложение имеет строгое
соглашение об уровне обслуживания (SLA) и требует определенного порога производительности,
то оно может быть не лучшим кандидатом на консолидацию, хотя при наличии нового
аппаратного обеспечения схожий уровень производительности можно будет поддерживать и при
использовании консолидации.
Дерево принятия решений
Один из способов рассмотреть приведенные выше факторы — постройка дерева принятия
решений. На рис. 2 показано дерево принятия решений, основанное на относительных функциях и
параметрах, доступных для каждого подхода. В нем рассматриваются все важные точки принятия
решений, описанные ранее.
21
Start
Instance
Security is a concern
Security?
No
Willing to
virtualize?
Next
Yes
High
Availability
Virtualization
High Availablity is a concern
Next
Yes
Manageability is a concern
Manageability?
Next
Willing to
virtualize?
No
Resource
Management?
Resource Management is a concern
Database
Next
Density
No other concerns; maximize density
Рис. 2. Общие сведения о дереве принятия решений
Это дерево описывает размещение режимов консолидации относительно точек принятия
решений, основанных на отличительных чертах функций. Каждый узел может быть развернут в
22
более детализованное поддерево (показано на рис. 3–6). Раздел безопасности показан на рис. 3,
раздел высокого уровня доступности — на рис. 4, раздел управляемости — на рис. 5 и раздел
управления ресурсами — на рис. 6. Если организация выполняет оптимизацию только для
достижения высокой плотности, то лучшим решением будет консолидация на уровне баз данных;
в нашем примере использования данные показали, что при консолидации уровня баз данных был
достигнут наиболее высокий уровень плотности.
На рис. 7 приведено дерево принятия решений, предназначенное для определения возможности
виртуализации приложения. Эта точка принятия решения часто достигается в ходе использования
других деревьев. Следует заметить, что здесь рассматривается не вопрос «Следует ли выполнить
виртуализацию?»; задача дерева на рис. 7 — определение технических границ для
виртуализации. Ответ на вопрос «Следует ли выполнить виртуализацию?» необходимо получить,
руководствуясь определенными значениями, выявленными в поддеревьях, а также
определенными административными политиками организации.
Start
App has
privacy/security
concerns?
No
Yes
App depends
on OS based
mechanism to
protect data?
Data stored in
plaintext?
No
No
App requires
SA or other
server roles/
objects?
Yes
App can be
virtualized?
Yes
Yes
Virtualization
Yes
No
Instance
Рис. 3. Раздел дерева принятия решений, затрагивающий безопасность
23
No
Next
Start
App has high
availability
requirements?
No
Yes
Virtualization
Yes
Yes
App can be
virtualized?
App wants to
leverage Live
Migration for
reduced
downtime?
Next
No
Yes
App requires
SQL Server
Failover
Clustering?
No
No
Instance
Рис. 4. Раздел дерева принятия решений, затрагивающий высокий уровень доступности
24
Start
No
Connection
string/schema/
namespace
collisions?
Yes
Wiling to
maintain
multiple OS
installations?
Instance
No
Yes
No
Yes
Low cost
migration?
Yes
Virtualization
Yes
No
Ease of
deployment?
Yes
No
Willing to
maintain
multiple
instances?
App can be
virtualized?
Wiling to
maintain
multiple OS
installations?
Yes
App can be
virtualized?
No
No
Database
No
Yes
Next
Рис. 5. Раздел дерева принятия решений, затрагивающий управляемость
25
Database
Yes
TempDB
isolation?
Start
Yes
Instance
No
No
Prefer to avoid
setting CPU/
memory limits?
Yes
No
Hot add CPU/
memory?
CPU/memory
isolation at the
SQL Server
process level?
Yes
No
App can be
virtualized?
No
Yes
CPU/Memory
isolation at the
OS level?
No
Yes
Virtualization
Рис. 6. Раздел дерева принятия решений, затрагивающий управление ресурсами
26
Next
Start
Host OS:
Windows
Server 2008
R2?
No
Yes
Host OS:
Windows
Server 2008?
Yes
Workload
serviced within
Hyper-V limits?
Yes
Host server
meets Hyper-V
hardware
requirements?
Yes
Guest OS
supported by
Hyper-V?
Yes
Yes
No
No
No
No
No
Рис. 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