Извините, если я не могу быть здесь полностью ясен. Это не намеренно, я старший разработчик в очень маленькой компании, и в данный момент мне приходится действовать как менеджеру.
В любом случае, история такова, что у нас есть 2 старых сервера Dell с SQL Server 2008 Standard в "кластере". Я поставил это в кавычки, потому что я все еще не на 100% понимаю, что это значит. У нас есть 2 совершенно новых блейд-сервера, и мы хотим перенести существующие базы данных на новое оборудование.
Итак, вот в чем дело. Нам нужно сделать это с минимальным или нулевым временем простоя. Мне говорят, что мы можем вытеснить пассивный узел, а затем подключить один из новых серверов. Но мне также говорят, что это опасный шаг, потому что что-то может пойти не так, что приведет к сбою кластера, и тогда мы останемся ни с чем, потому что активный сервер не сможет вернуться в рабочее состояние.
Есть ли у кого-нибудь мысли, как с этим справиться? Мне сказали, что единственный способ гарантировать успех — это хотя бы день простоя, когда мы поднимем новый кластер на новом оборудовании, а затем перенесем базы данных по одной.
[Изменить] Поскольку это все еще связано с этим вопросом, я хотел бы добавить еще один вопрос. Возможно ли нам удалить машину из кластера. Затем создать новый кластер с удаленным узлом в качестве активной машины, а затем добавить в него новый сервер? Эффективно сохраняя старый кластер, пока новые машины будут заменяться на новые на случай, если что-то пойдет не так?
решение1
малое или отсутствующее время простоя
Хотя это мало поможет вам сейчас, если вы должны использовать предприятие, если вам нужна высокая доступность, самая очевидная функция, которую вы бы использовали в этой ситуации, — это возможность иметь до 16 узлов в кластере, так что в вашем случае вы бы просто добавили еще 2 узла, а затем удалили те, которые вам больше не нужны. Я бы рассмотрел обновление версии, пока вы обновляете оборудование
... Но мне также сказали, что это опасный шаг, потому что что-то может пойти не так, что приведет к сбою кластера, и тогда мы останемся ни с чем, поскольку активный сервер не сможет восстановить работу.
Все возможно. Хотя я никогда не видел, чтобы кластер отказоустойчивости сервера 208 sql 2008 просто падал, теоретически это возможно. Обратите внимание, что активный узел не "падает" во время обновления узла, поэтому нечего отключать. Кластер просто работает на 1 узле без возможности отказоустойчивости. Разумный наихудший сценарий заключается в том, что старый узел каким-то образом мертв, а замена не добавит, в этом случае вы будете работать без возможности отказоустойчивости, пока не будет решена проблема, из-за которой сервер не добавляется.
Мне сказали, что единственный способ гарантировать успех — это как минимум день простоя, в течение которого мы поднимем новый кластер на новом оборудовании, а затем перенесем базы данных одну за другой.
Это, вероятно, единственный способ гарантировать успех парня, выполняющего работу. Я бы задал невинный вопрос: «Если для перемещения кластера требуется день простоя, зачем мне кластер? Я мог бы купить 2 машины, а одну оставить готовой к работе для такой доступности». Короче говоря, вам нужно найти кого-то, кто действительно работал с кластерами раньше и понимает задействованную технологию. Предполагая, что нет никаких уникальных проблем (например, ваша компания написала несколькопочти(программное обеспечение, работающее на кластере, которое работает на кластере) Я думаю, что большинству профессиональных администраторов Microsoft было бы неловко сказать, что замена/добавление оборудования в существующий работающий кластер займет день простоя.
решение2
Во-первых, рекомендуемая стратегия в конце вашего вопроса — это то, как я бы рекомендовал это сделать, но поскольку это не вариант, вот как бы я с этим справился. Вы, кажется, запутались в кластере, по сути, на обоих серверах установлен SQL и службы кластера, с помощью команды через службы кластера вы можете «перекатить» SQL с одного сервера на другой. Если бы я был на вашем месте, я бы сделал так, как вы предложили, перекатил бы все службы на один узел, удалил второй узел из кластера, добавил бы один из ваших новых серверов в качестве узла кластера, перекатил бы все службы на новый узел кластера, добавил второй новый узел, удалил бы второй старый узел из кластера.
**Обратите внимание, если вы не знакомы с кластерными службами и/или кластеризованными установками SQL и попытаетесь сделать это на своей рабочей системе, это может закончиться для вас очень, очень плохо. Гораздо хуже, чем один день запланированного простоя. Я бы либо нанял консультанта с опытом работы с кластерами, либо, если это не вариант, настроил бы тестовую среду, которая могла бы протестировать процесс изнутри и снаружи.
Здесьэто ссылка на шаги по добавлению узла в ваш кластер.
решение3
Вам вообще не нужно ломать старый кластер, если вы не хотите снова использовать оборудование. Я бы рекомендовал следующее:
- Создайте новый кластер с новыми лезвиями
- Не все SQL на новом кластере, оставьте те же буквы дисков, пути, порт и имя экземпляра (если применимо)
- После установки восстановите/замените базы данных master и msdb со старого сервера SQL на новый, чтобы получить логины и задания, или же создайте скрипт заданий на старом сервере и используйте sp_help_revlogins.
- Выполните доставку или зеркальное копирование базы данных со старого сервера на новый, чтобы обновить данные.
Это вернет ваш новый экземпляр в то же состояние, что и старый, вместе с новой установкой ОС и SQL. Чтобы перейти на новый кластер, вы можете сделать следующее, предположив, что имя вашего старого экземпляра — INSTA, а нового — INSTB:
- Переведите старый экземпляр SQL в автономный режим.
- Восстановите базы данных на новом сервере
- Удалить запись DNS INSTA из DNS Active Directory
- Создайте новую запись DNS CNAME (псевдоним) в DNS Active Directory, которая указывает на INSTB
После этого приложения должны будут подключаться к старому имени экземпляра SQL, но это перенесет их на новый сервер. Вам может потребоваться запустить "ipconfig /flushdns" на всех серверах приложений, чтобы ускорить изменение DNS, обязательно пингуйте старое имя, чтобы увидеть, когда оно указывает назад. Мы используем этот метод для переключения, потому что он позволяет нам сохранить старый кластер на случай, если нам понадобится откат. Вы не сможете поднять старый экземпляр SQL, пока не измените параметр сетевого имени SQL Server на что-то другое, но как только это будет сделано, вы просто укажете псевдоним DNS на старый, если захотите откатиться.
решение4
Не зная особенностей оборудования, чтобы узнать, сработает ли это, я бы предложил перенести образ старого пассивного узла на новый сервер. Использование чего-то вроде Acronis, которое позволит поместить образ на новое оборудование, должно позволить вам в основном переместить пассивный узел на новое оборудование. Оказавшись там, вы можете включить его и убедиться, что он функционирует правильно (насколько это возможно), а затем попытаться переключить его на новое оборудование. Хотя есть много вещей, которые могут пойти не так, как сказал Джим Би, есть большая вероятность, что он либо правильно переключится на новое оборудование, либо не будет работать и вам просто придется вернуться к старому оборудованию. Если это сработает, то вы можете повторить процесс на другом узле. Если нет, вы можете просто снова включить старый пассивный узел (который вам не придется уничтожать) и попробовать что-то еще.