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