Консолидация повышения эффективности.

Статья
17.01.2024

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

Писатели: спела Арумугам Hsueh, Энтони Чжун, Мадане

Технические рецензенты: Клод Lorenson, Клиффорд Диббл, Линдси Аллен, Самал Sambit, Sethu Kalavakur, Прем Мехра, Самир Tejani, Ир Сена ли, Джек Richins, Брайан Дьюи, Джон Мэтью, Джейми Рединг, Джонатан Моррисон, Омри Бахат, S Муралидхар, Гайдн Ричардсон

Редактор: Inghram Бет

Опубликовано: Ноябрь 2009

Применимо к: SQL Server 2008 и SQL Server 2008 R2

Предложенная статья является машинным переводом оригинала.

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

Введение

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

Этот документ будет пытаться ответить на следующие вопросы:

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

Исходя из нашего опыта и обратной связи, мы имели от клиентов и партнеров, мы будем стараться ответить на эти вопросы путем:

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

Обоснования для консолидации

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

Отсутствие пространство в центре обработки данных
Снижение издержек и повышение эффективности
Стандартизации и централизации
Подвижность ИТ
Позеленейте его

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

Нехватка пространства

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

Сокращение расходов и повышение эффективности

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

Стандартизации и централизации

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

Подвижность ИТ

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

Позеленейте его

Одной из растущих мотивов в снижения мощности и тепловой расходов является также сосредоточены на оказании «зеленой» операционной системы. Это похоже на мотивы для снижения расходов и повышения эффективности, однако конечная цель — экологические преимущества, а не экономия. Консолидация играет важную роль здесь в сокращении след центра данных. Меньшее количество компьютеров и меньше простоя машин приводят к снижению энергопотребления и сокращение потребности для охлаждения. Новое оборудование может также обеспечить улучшение энергоэффективности, а потому, что он может воспользоваться более эффективной технологии энергии. Операционная система Windows Server ® также предоставляет возможности для регулировки и новых функций процессора в Windows Server 2008 R2 таких как ядро, парковка дальнейшее повышение эффективности и Нижняя общего потребления энергии. Исследование корпорацией Майкрософт ИТ-отдел найти что консолидации на новых серверах повлекло за собой снижения требования к питанию, 3 миллионов вольт ампер (с добавленными бонус также предоставляет экономия $11 млн в год в эксплуатационных расходов). Для получения дополнительных сведений см. статью Зелёных ИТ на практике (http://msdn.microsoft.com/en-us/architecture/dd393309.aspx).

Кандидат приложения для консолидации

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

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

Примечание: В большинстве случаев, Tier 1 приложений с более строгие производ��тельности (особенно вокруг ввода/вывода) и требованиям высокого уровня доступности, не идеальные кандидаты для консолидации.

Новое в SQL Server 2008 R2

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

SQL Server Контрольная точка

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

Приложение уровня данных

Данных уровневое приложение является новое подразделение для разработки, развертывания и управления базами данных. Регистрация базы данных как приложение уровня данных позволяет базе данных под управлением SQL Server контрольную точку. Для получения дополнительных сведений, включая обзор уровня данных приложений, см. понимания данных уровневые приложения (http://msdn.microsoft.com/en-us/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 ®. Это позволяет создавать стандартизированные предустановленной изображения развертывания с SQL Server Windows. ИТ-администраторы могут использовать SysPrep и SQL Server 2008 R2 для создания среды последовательной консолидации.

Опции для консолидации SQL Server

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

Базы данных

В базе данных -уровень консолидации, несколько приложений доля (хранилище данных) в один 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, что позволяет для каждого приложения на различные патч уровень (уровеньосновных и вспомогательных версия). Однако, существует потенциал для применения конфликтов потому что системных ресурсов (главным образом процессора, памяти и ввода/вывода) являются общими, хотя инструменты, такие как маски схожести ЦП и max server memory настройки может помочь обеспечивают изоляцию ресурса. Системное администрирование базы данных является изолированным, но администрирования системы Windows используется совместно на хост-сервер. Каждыйэкземпляр SQL Serverна машине могут быть зачислены в контрольную точку SQL Server для управления.

Виртуализация

В рамках этого подхода приложений переносятся из их физического сервера в виртуальную машину (VM).Одной машине хостов несколькими виртуальными машинами, и каждой виртуальной Машине находится один SQL Server экземпляр. Потому что VM может выступать в качестве специальной физической машине, этот подход обеспечивает проще миграции источник окружающей среды для консолидации окружающей среды. VMs полностью изолированы от других VMs и взаимодействия с другими серверами в сети, как если бы они были физических машин. Гипервизор автоматически управляет управления оптимальный ресурс между несколькими виртуальными машинами. Дополнительные высокой доступности варианты также доступны функции, такие как Microsoft Hyper-V Live миграции. Хотя этот подход приводит к меньше физических серверов для управления, он поддержив��ть столько операционной системы и SQL Server изображения как источник окружающей среды. Экземпляры SQL Server в рамках виртуальной машины может быть зачислены в контрольную точку SQL Server для управления.

Другие варианты консолидации

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

Аппаратное и программное обеспечение соображения

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

Потенциальные узкие места

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

Эти машины должны выбираться с комнатой расти. Например они должны включать способность добавить дополнительных ядер процессора, памяти и хранения, и они должны иметь PCI слотов для дополнительной сети и контроллеры системы хранения данных. Для виртуализации обычно рекомендуется использовать фиксированный размер виртуального жесткого диска (VHD) или к серверу диск потому что динамические виртуальные диски может вызвать дополнительные накладные расходы ввода-вывода. Дополнительные сведения содержатся в разделе «Пример» далее в этом документе.

Новые технологии виртуализации

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

Важно отметить, что Hyper-V имеет некоторые ограничения. Hyper-V на базовой операционной системы поддерживается только на x 64 архитектур процессоров и требует поддержки виртуализации (Intel VT или AMD-V) и аппаратного предотвращения выполнения данных (DEP, также называется бит Intel XD и AMD NX bit). Кроме того гостевая операционная система в настоящее время ограничивается доступ к четырех виртуальных процессоров. Это вряд ли будет проблемой для большинства кандидатов консолидации, но стоит рассмотреть, если приложение, как ожидается, будет существенно расти в использовании.

Технология виртуализации однако, постоянно улучшается. Масштабируемость и производительность особенностью новых процессоров является второй-уровень трансляции адресов (штора), также известный как вложенные подкачки. AMD относится к этой технологии, как ДНЯО, и Intel называет этот EPT в их соответствующих процессоров. Выбор виртуализация как путь консолидации не требует штора, но приложение безусловно будет работать лучше.

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

Рисунок 1: преимущество в производительности с помощью штора процессоры

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

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

Аппаратные параметры

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

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

Как выбрать стратегию консолидации

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

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

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

Безопасность

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

Требование	Виртуализация	Экземпляр	Базы данных
Эквивалент имея выделенный физический компьютер	Да	No	No
Изоляция локальные учетные записи Windows	Да	No	No
Изоляция SQL Server Логинов	Да	Да	No
Изоляция исполняемые файлы SQL Server	Да	Да	No
Защита данных через диска Windows BitLocker ® шифрование	Да	Частичное – не изоляции приложений	Частичное – не изоляции приложений
Защита данных через Windows шифрованной файловой системы	Да	Да – если экземпляры имеют отдельные служба учетных записей	Частичное – не изоляции приложений
Защита данных через Microsoft SQL Server прозрачное шифрование данных	Да	Да	Частичное – все корневые сертификаты хранятся в базе данных master
Защита данных путем разрешения Windows	Да	Да	Частичное – файлы, общие для размещения экземпляри учетной записислужба SQL Server
Защита данных через SQL Server гранулированных шифрование	Да	Да	Да
Защита данных через детализированных разрешений SQL Server	Да	Да	Да
Аудит действий с аудита SQL Server	Да	Да	Да

Таблица 1: сравнение соображения безопасности через параметров консолидации

В общем это лучше отделить приложений с требованиями к безопасности. Например приложение с клиентских данных, требующий ограниченным доступом не должны консолидироваться на компьютер, на котором находится приложение, которое регулярно доступны пользователям, которые обычно не имеют доступ к данным клиента. Такая консолидация увеличивает риск, что неправильная настройка входа или разрешение будет предоставлять доступ к конфиденциальным данным. Это даже более важно, с базы данных -уровень подхода; Поскольку учетные записи 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), или может быть база данных механизмов таких как прозрачный шифрования данных (TDE) SQL Server . Если приложение полагается на механизмы на базе операционной системы, базы данныхуровень или даже экземпляр-уровень консолидации параметры могут быть жизнеспособным, потому, что они разделяют ту же среду операционной системы.

Высокой доступности и аварийного восстановления

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

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

Функция	Виртуализация	Экземпляр	Базы данных
Приложение остается доступным во время простоя машины планируемого пребывания без перезапуска приложения	Да – через Live Migration (зеркальное отображение базы данных может также использоваться)	Да – через зеркального отображения базы данных	Да – через зеркального отображения базы данных
Подключите приложения по-прежнему доступны во время простоя машины планируемого пребывания без клиент	Да – через перенос	No	No
Приложения могут быть перенесены между машинами без прерывания работы (перезагрузка или повторное подключение)	Да – через перенос	No	No
SQL Server отказоустойчивой кластеризация	Да	Да	Частичное –failover — науровень экземпляр
SQL Server доставки журналов	Да	Да	Да
Зеркальное отображение базы данныхSQL Server	Да	Да	Да
репликация SQL Server	Да	Да	Да

Таблица 2: сравнение функций высокой доступности различных параметров консолидации

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

Управление ресурсами

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

Виртуализация обеспечивает возможно наиболее конкретных границ, потому что выделения ресурсов ЦП и памяти должен быть указан для всего контейнера VM. Оба из этих параметров можно изменить позднее, но может потребоваться выполнить эти изменения VM в автономном режиме. Преимуществом этого подхода является что ресурсов содержатся и изоляции в VM (за исключением процессор, который может быть over-committed), таким образом, что существенно сокращает негативное влияние одного приложения, которые испытывают nonaverage нагрузки, воздействие других приложений на сервере. От падения эти ресурсы будут выделяться VM независимо от ли они используются полностью. Кроме того, гостевой операционной системы VM сам будет потреблять некоторые служебные выделенных ресурсов и базовая операционная система также потребует дополнительного выделения ресурсов хотя они как правило относительно небольшой (см. минимальных оперативных потребностей). Один виртуальный процессор рекомендуется сопоставить один физический процессор. Это довольно безопасно over-commit процессоры (то есть, чтобы иметь несколько виртуальных процессоров сопоставляется один физический процессор) но наблюдение за работой. Не следует бортом памяти, потому что это так может создать трудности какие воздействия деятельности. В самом деле нельзя бортом памяти в Hyper-V.

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

Примечание: маски схожести ЦП игнорируется в ВМ.

Рассмотрение для состязание ресурсов представляют собой взаимодействие между приложением и базы данных tempdb. Если несколько приложений объединены как базы данных, и они имеют зависимости от базы данных tempdb, ввода/вывода узкие места на базы данных tempdb может привести к проблемам с производительностью. Если это вариант, рекомендуется с помощью либо экземпляр или виртуализация консолидации или изменение приложения. Для получения дополнительных сведений о базы данных tempdb, см. базы данных tempdb (http://msdn.microsoft.com/en-us/library/ms190768.aspx) в электронной документации SQL Server 2008.

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

Замечание	Виртуализация	Экземпляр	Базы данных
Изоляция базы данных tempdb	Да	Да	No
Изоляции объектов на уровень сервера (полномочия, связанные серверы, msdb, SQL Server заданий агента и так далее)	Да	Да	No
Жесткие ограничения на ЦП и памяти использования набор для конкретного приложения	Да	Да	No
Использование регулятора ресурсов для предоставления запрос приоритетов в рамках SQL Server экземпляр	Да	Да	Да
-Добавить ЦП	No	Да	Да
Память с «горячей» заменой	No	Да	Да
Горячей хранения	Да	Да	Да

Таблица 3: сравнение нехватки ресурсов изоляции различных параметров консолидации

Плотность

В контексте консолидации плотность — это количество приложений, которые могут быть объединены в одной машине. VMs, экземпляры SQL Server и SQL\ базы данных SQL Server все имеют различные степени накладных расходов, которая влияет на плотность консолидации. VMs имеют высокие накладные расходы, потому что являющуюся полноценной операционной системой поддерживается для каждого приложения. Науровень экземплярраспределяются ресурсы операционной системы, но каждое приложение имеет независимый экземпляр запущен, который является своей собственной независимой служба. База данных -уровень консолидации обеспечивает низкие накладные расходы, потому что все другие ресурсы используются совместно с другими базами данных на один экземпляр. Обратите внимание, что SQL Server в настоящее время ограничивается максимум 50 экземпляров Zend_Session_Namespace среды операционной системы (физические или виртуальные). Hyper-V имеет предел 64 VMs на узел и SQL Server экземпляр имеет предел в 32 767 баз данных каждого экземпляр.

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

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

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

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

методконсолидации	Количество заявлений	Пропускная способность	Время отклика	Хост-системы ЦП
Базовые (старое оборудование)	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 системы Center Virtual Machine Manager (VMM) и Microsoft SQL Server контрольную точку. VMM также имеет «физические на виртуальную» Утилита, именуемые как P2V. Эта программа занимает физической машине, преобразует его в виртуальный компьютер и затем развертывает его на сервер Hyper-V. Это обеспечивает очень низкая стоимость миграции, потому что весь процесс обрабатывает��я автоматически. Для получения дополнительных сведений о том, как пользоваться P2V, см. P2V: Преобразование физических машин в виртуальные машины в VMM (http://technet.microsoft.com/en-us/library/cc764232.aspx) в документации по Microsoft System Center. Обзор виртуализации Hyper-V и подробные сведения о конкретных преимуществах виртуализации управляемость, см. виртуализации с Hyper-V (http://www.microsoft.com/windowsserver2008/en/us/hyperv-overview.aspx) на Windows Server 2008 R2 веб-сайт. Некоторые из особенностей, которые могут быть использованы с виртуализацией являются возможность клонировать и очень легко развернуть приложение и использование Live миграции для быстрого развертывания приложений между машинами для динамической балансировки нагрузки с нулевым временем простоя.

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

Функция	Виртуализация	Экземпляр	Базы данных
Создание стандартных образов	Да	No	No
«Один клик» клон среды между разработки, испытания и производства	Да-с SCVMM	No	Частичное – можно клонировать данных уровневых приложений
Низкая стоимость миграции	Да – P2V Утилита	No	Частичное – зависит как хорошо приложения содержится в базе данных
Динамическое перераспределение приложений без прерывания работы	Да – с живая миграция	No	No
Могут управляться SQL Server точки управления	Да	Да	Да – если зарегистрированы как приложение уровня данных
Требуется установка SQL Server несколько раз	Нет – можно использовать P2V или клонирования	Да	No
Уменьшает количество физических серверов для поддержания	Да	Да	Да
Уменьшает количество копий Windows для поддержания	No	Да	Да
Уменьшает количество экземпляров SQL Server для поддержания	No	No	Да

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

Записка о производительности

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

Дерево принятия решений

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

Рисунок 2: высоко -уровень обзор дерева принятия решений

Это дерево захватывает, высоко -уровень позиционирования консолидации вариантов точек принятия решений, основанных на Дифференциаторы функция. Каждый узел более подробно рассматривается в более подробную поддерево в рисунки 3-6. Часть безопасности показано на рисунке 3, высокой доступности на рисунке 4, управляемость на рисунке 5 и управления ресурсами на рисунке 6. Если ваша организация оптимизация исключительно на плотность, рассмотреть базы данных -уровень консолидации; в нашем вариант исследовании raw цифры показывают, чтоуровень консолидации базы данных - обеспечивает наивысшую плотность.

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

Рисунок 3: часть дерева решений, посвященных безопасности

Рисунок 4: часть дерева решений, посвященных высокой доступности

Рисунок 5: часть дерева решений, посвященных управляемость

Рисунок 6: часть дерева решений, упором на управление ресурсами

Рисунок 7: часть дерева решений для решения ли приложение можно сделать виртуальным

Тематическое исследование

Нашей целью было провести эксперимент по различным поведением каждого подхода с высоким консолидации плотностью. Мы выбрали старше машина с четырьмя логических процессоров и 8 ГБ общего объема системной памяти. Мы ориентированы 5-10% средний показатель использования для этого компьютера. Мы выбрали для укрепления этого приложения на новых 32-процессорных сервера с поддержки штора, 128 GB RAM, 50 135-ГБ жестких дисков и две 1-Гбит/с сетевой карты. Затем мы пытались запускать столько копий приложения как можно на новом сервере в попытке выяснить, сколько приложений будет иметь возможность запускать одновременно и поддерживать такую же производительность как на базовых старую машину. Старая машина никогда не была подчеркнута, поэтому Рабочая нагрузка, сам был ограничивающим фактором, вместо того, чтобы любой нехватки ресурсов. Как отмечалось ранее предполагалось, что база данных будет иметь самая высокая плотность, потому что он имеет низкие накладные расходы, и что виртуализация будет иметь самый низкий, потому, что она имеет высокие накладные расходы.

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

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

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

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

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

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

Заключение

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

Для получения дополнительной информации:

http://www.Microsoft.com/SQLServer/: SQL Server веб-сайт

http://www.Microsoft.com/SQLServer/2008/en/US/Server-Consolidation.aspx: сайт SQL Server консолидации

http://www.Microsoft.com/SQLServer/2008/en/US/Virtualization.aspx: сайт виртуализации SQL Server

http://TechNet.Microsoft.com/en-US/SQLServer/: SQL Server TechCenter

http://MSDN.Microsoft.com/en-US/SQLServer/: SQL Server DevCenter

Поделиться через