Это повторный хеш вопрос Я спросил некоторое время назад - после того, как консультант пришел и поделился идеями с другими командами в отделе, весь вопрос был снова поднят, поэтому я ищу более подробные ответы.
Мы намереваемся настроить SQL-кластер с несколькими экземплярами на нескольких физических блейд-серверах, который будет запускать множество различных систем в каждом экземпляре SQL. Обычно на каждом хосте виртуальной машины будет работать один виртуальный экземпляр SQL. Опять же, в общем случае каждый хост виртуальной машины будет работать на выделенном базовом блейд-сервере. Настройка должна предоставить нам большую гибкость для обслуживания любой отдельной виртуальной машины или базового блейд-сервера, при этом все экземпляры SQL могут переключаться при отказе по мере необходимости.
Мой первоначальный план состоял в следующем:
Консультант предложил вместо этого сделать следующее:
Большая разница заключается в добавлении шага 4, на котором мы также группируем все гостевые виртуальные машины. Аргумент состоит в том, что это еще больше улучшает обслуживание, поскольку у нас нет никакой связи между кластером SQL и физическим оборудованием. Теоретически мы можем в реальном времени мигрировать гостевые виртуальные машины между хостами, не затрагивая кластер SQL вообще, поэтому для планового обслуживания физических блейдов мы перемещаем кластер SQL без прерывания и без необходимости переключения при отказе.
Это звучит как хорошая идея, но я не встречал в Интернете ничего, где люди говорили бы, что сделали это, и это работает нормально. Могу ли я на самом деле выполнить живую миграцию гостей, чтобы SQL-кластер, размещенный внутри них, не расстраивался?
Есть ли у кого-нибудь опыт такой настройки, хороший или плохой? Есть ли какие-то плюсы и минусы, которые я не учел?
Я ценю, что зеркалирование также является ценным вариантом для рассмотрения - в данном случае мы отдаем предпочтение кластеризации, поскольку она будет выполнять всю работу с каждым экземпляром, и у нас есть достаточное количество баз данных. Некоторые БД предназначены для громоздких сторонних систем, которые могут даже не работать с зеркалированием (и, как я понимаю, кластеризация такова, что отработка отказа полностью прозрачна для клиентов).
Спасибо.
Если эти блейды будут полностью предназначены только для работы с SQL Server, зачем вы вообще возитесь с виртуализацией?
Почему бы вам просто не установить Windows Server и SQL Server на каждом из них и соответствующим образом настроить кластер без дополнительных накладных расходов на виртуализацию?
Звучит сложно.
Мне пришлось бы взвесить «сложность» вашего решения с надежностью и относительной простотой стандартной физической реализации кластерного SQL-сервера.
ВСЕ ли базы данных критичны? По моему опыту, обычно нет, поэтому я обычно размещаю наиболее важные базы данных на серверах, которые настроены с полной отказоустойчивостью, а остальные (обычно большая часть) на простых серверах SQL.
Это позволяет вам сосредоточиться на поддержании в рабочем состоянии наиболее важных систем и не пытаться удерживать «все шары в воздухе одновременно».
Все серверы нуждаются в регулярном плановом обслуживании. Учитывая регулярность, серьезность и важность установки исправлений безопасности, мы отошли от попыток поддерживать теоретическое время безотказной работы 5 девяток (которое понравилось пользователям, но на самом деле не НУЖНО) к более реалистичному «мы будем обеспечивать безопасность серверов. и безопасным, но БУДУТ короткие ОБЯЗАТЕЛЬНЫЕ периоды обслуживания, чтобы мы могли поддерживать серверы в исправном состоянии ».
Из перечисленных вариантов я бы выбрал №2, но я бы не стал кластеризовать SQL (шаг 5), потому что он добавляет уровень сложности, от которого вы мало что выиграете. Кластеризация Hyper-V уже позволит вам запускать эту виртуальную машину на любом хосте, поэтому вы будете защищены от сбоев оборудования.
Я предполагаю, что вы планируете использовать виртуальные жесткие диски фиксированного размера для журналов SQL и томов базы данных.
Я полностью понимаю комментарии других об отказе от Hyper-V в целом и использовании двух блейд-серверов в качестве обычного SQL-кластера - это, безусловно, традиционный подход. Однако преимущества гибкости виртуализации рабочих нагрузок огромны для обслуживания, обновлений и сбоев оборудования. Переносимость виртуальных машин очень привлекательна.
Обратите внимание, что ценность этого решения также зависит от вашей среды. Если у вас нет других серверов Hyper-V, а ваш персонал не слишком опытен с Hyper-V, виртуализация одной из ваших наиболее важных рабочих нагрузок может оказаться не очень хорошей идеей. Однако если вы, как и многие ИТ-магазины, начали виртуализацию менее важных серверов, создали несколько хостов и имеете навыки и процедуры для надежной работы Hyper-V, расширение этого внимания на более важные рабочие нагрузки вполне разумно. Лично я бы предпочел управлять кластеризацией на уровне хоста, а не на уровне SQL, и я думаю, что мы увидим, как это делается все чаще и чаще, хотя это еще не так распространено.
Наконец, ваши вопросы о запуске SQL на Hyper-V: да, живая миграция будет работать с SQL, и она не заметит - И - зеркалирование базы данных SQL - это здорово, но да, оно не поддерживается повсеместно, поэтому не подходит для всех ситуация.
Преимущество настройки вашего консультанта заключается в том, что если вы отказываетесь только от оборудования, это не защитит вас от неисправного сервиса или чего-то еще. Всегда хорошо иметь избыточность как в аппаратном, так и в программном обеспечении, поэтому, если вы спросите меня, я бы выбрал вариант 2 (учитывая, что у вас есть бюджет и знания, конечно)
Я думаю, ваш консультант прав. У меня, как и у него, есть точная идея, которую я хочу реализовать в моей нынешней среде. 2 физических устройства, на каждом из которых работает Hyper-V с 2 установками W2k8.
Это дает вам Полный уровень отказоустойчивой кластеризации и Полный H / A в вашей среде SQL.
А может моя идея тупая?
Что касается проблемы с ником, вы сможете решить эту проблему с помощью объединенных сетевых адаптеров, я не знаю, какое у вас оборудование, но было много подобных проблем с Dell Power Edge 1950-х, 2950-х, R710 и т. д., где nic становится приемником только nic и неправильно отправляет трафик в HyperV. Новейшие диски и правильная конфигурация совместной работы не только обеспечат дополнительную избыточность, но также повысят производительность.
На самом деле Вариант 1 и Вариант 2 очень близки к одному и тому же. Самый большой вопрос - как вы хотите получать доступ к своим данным и для чего предназначена ваша SAN. SQL 2008 фактически увеличивает производительность при запуске в виртуализации через кластеризованные общие тома и снова кластеризации SQL, потому что SQL достаточно умен, чтобы разгрузить свои процессы на несколько узлов SQL. Это не только дает вам большой прирост производительности (представьте себе, когда Intel впервые представила настоящую гиперпоточность), но также увеличивает производительность вашей инфраструктуры для сетей с высокими накладными расходами за счет возможности разделения трафика и использования перенаправления пакетов.