☰

Кластеризация SQL на Hyper V — это кластер внутри кластера, преимущество

tag-icon • tag-icon sql-server-2008 windows-server-2008-r2 cluster
Кластеризация SQL на Hyper V — это кластер внутри кластера, преимущество

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

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

Мой первоначальный план состоял в следующем:

  1. Установите 2008 R2 на каждую лопасть
  2. Добавьте Hyper V к каждому лезвию
  3. Установите виртуальную машину 2008 R2 на каждый блейд-сервер
  4. Внутри виртуальных машин создайте отказоустойчивый кластер, а затем установите кластеризацию SQL Server.

Консультант предложил нам вместо этого сделать следующее:

  1. Установите 2008 R2 на каждую лопасть
  2. Добавьте Hyper V к каждому лезвию
  3. Установите виртуальную машину 2008 R2 на каждый блейд-сервер
  4. Создайте кластер на машинах HOST, на котором будут размещены все виртуальные машины.
  5. Внутри виртуальных машин создайте отказоустойчивый кластер, а затем установите кластеризацию SQL Server.

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

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

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

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

Спасибо.

решение1

Если эти блейды будут полностью предназначены только для работы SQL Server, зачем вы вообще возитесь с виртуализацией?

Почему бы вам просто не установить Windows Server и SQL Server на каждом из них и не настроить свой кластер соответствующим образом, без дополнительных затрат на виртуализацию?

решение2

Звучит сложно.

Мне пришлось бы сопоставить «сложность» вашего решения с надежностью и относительной простотой стандартной физической кластерной реализации SQL-сервера.

ВСЕ ли базы данных критически важны для миссии? По моему опыту, обычно нет, поэтому я предпочитаю размещать самые важные базы данных на серверах, настроенных на полную отказоустойчивость, а остальные (обычно большую часть) — на простых SQL-серверах.

Это позволяет вам сосредоточиться на поддержании работоспособности наиболее важных систем, а не пытаться «держать все мячи в воздухе одновременно».

Все серверы будут нуждаться в регулярном плановом обслуживании. Учитывая регулярность, серьезность и важность исправлений безопасности, мы отошли от попыток поддерживать теоретический показатель времени работы в пять девяток (который нравился пользователям, но на самом деле не НУЖЕН был) к более реалистичному «мы будем поддерживать серверы в безопасности и сохранности — но будут короткие ОБЯЗАТЕЛЬНЫЕ окна обслуживания, чтобы мы могли поддерживать серверы в надлежащем состоянии».

решение3

Из перечисленных вариантов я бы выбрал #2, но не кластеризовал бы SQL (шаг 5), потому что это добавляет уровень сложности, от которого вы не много выигрываете. Кластеризация Hyper-V уже позволит вам запустить эту виртуальную машину на любом хосте, так что вы застрахованы от сбоев оборудования.

Я предполагаю, что вы планируете использовать VHD фиксированного размера для томов журнала SQL и базы данных.

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

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

Наконец, ваши вопросы о запуске SQL на Hyper-V: да, живая миграция будет отлично работать с SQL, и он этого не заметит. И - зеркалирование баз данных SQL - это здорово, но да, оно не поддерживается повсеместно, поэтому не подходит для каждой ситуации.

решение4

Я думаю, ваш консультант прав. У меня есть точное представление, как и у него, что я хочу реализовать в своей текущей среде. 2 физических устройства, каждое из которых работает под управлением Hyper-V с 2 установками W2k8.

  1. Установите 2 виртуальные машины на 1-й физический хост.
  2. Установите SQL на VM1 и выполните зеркалирование или кластеризацию с VM2 с настройкой отказоустойчивости на уровне ОС для переключения на реплицированную среду.
  3. Установите W2k8 на второй физический сервер и отказоустойчивый кластер Hyper-V.

Это обеспечивает вам полный уровень отказоустойчивой кластеризации и полную безопасность H/A в вашей среде SQL.

Или, может быть, моя идея глупа?

Связанный контент