Перемещение серверов внутри одного здания

Вот мой сценарий: я разработчик, который унаследовал (без моего ведома) три сервера, расположенных в моем офисе. Я также унаследовал работу администратора серверов с явным отсутствием знаний об администрировании серверов и Google / ServerFault в качестве ориентира. К счастью, мне никогда не приходилось вступать в физический контакт с машинами или решать любые проблемы, поскольку они всегда «просто работали».

Все три машины расположены в одной комнате данных и служат для следующих целей:

Machine1- IIS 8.0 с несколькими внутренними приложениями
Machine2- хранилище данных SQL Server 2008 R2 для внутренних приложений
Machine3- зеркальное хранилище SQL Server 2008 R2Machine2

У всех трех подключены внешние жесткие диски, которые часто выполняют резервное копирование.

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

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

^{Я знаю, что далеко не идеально все три расположены в одной комнате / помещении, но это выходит за рамки этого вопроса.}

Искренне интересный вопрос, хорошо заданный :)

Есть несколько вещей, которые вы должны проверить перед этим, некоторые легкие, некоторые сложные.

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

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

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

«Другие соединения» - знаете ли вы, есть ли на ваших серверах какие-либо другие соединения, кроме питания и работы в сети? возможно, у них есть Fibre-Channel ссылки на общее хранилище, KVM-ссылки на экран общего управления - опять же, если они вам нужно, чтобы повторить их одинаково.

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

Другие ответы охватывают технические аспекты переезда. Возможно, вам также придется рассмотреть некоторые другие вещи.

Убедитесь, что пользователи знают, что их приложения будут недоступны во время переезда. Вы захотите запланировать переезд, возможно, в нерабочее время, чтобы свести к минимуму количество пострадавших.

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

После тестирования сообщите своим пользователям, что переезд завершен, и пусть они сообщат, есть ли у них проблемы.

Это довольно сложно сказать, и границы "слишком широки" для нашего формата. Самая важная вещь, которую вам нужно проверить, это то, нужно ли вам каким-либо образом переконфигурировать вашу сеть, если они могут продолжать работать с теми же адресами. Даже если они могут сохранять одинаковые адреса, убедитесь, что они не настроены через DHCP, и / или убедитесь, что сервер DHCP будет доступен в новом месте.

Примечание: как вы уже сказали, наличие сервера SQL и его зеркала далеко от идеала. Однако иметь резервные диски в одном месте действительно опасно. Вы должны иметь резервную копию в другом физическом месте.

Другие ответы имеют хорошие соображения перед переездом. Тем не менее, вы также должны планировать, как вы организуете фактическое движение. Из того факта, что Machine3 является зеркалом Machine2 , похоже, что время безотказной работы является важным фактором для баз данных SQL Server 2008 R2. Тот факт, что это зеркало, дает вам возможность. Причина существования зеркала должна быть доступна, когда основной сервер не доступен. Это включает в себя недоступность из-за обслуживания, которое включает в себя перемещение.

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

Основы движения:

1. Переместите Machine3 (зеркало SQL Server): получите его полностью работоспособным. Проверьте повторную синхронизацию.
2. Переместить Machine2 : получить его полностью в рабочем состоянии.
3. Переместить Machine1 : получить его полностью в рабочем состоянии.

Более подробное описание переезда:

Далее приведены два метода (пути A и B) использования Machine3 для проверки соединений для Machine1 и / или Machine2 . Вы должны использовать только один метод. Какой способ сделать это, или даже если использовать любой из них, зависит от информации, не содержащейся в вопросе (например, физическое разделение конечных местоположений машин, физический размер машин, длина сетевых / сетевых шнуров, наличие расширений для них, сходство конфигураций сетевых портов, потребностей во времени работы и т. д.). Использование Machine3 для проверки этих соединений потенциально позволяет увеличить время безотказной работы для Machine2 , но особенно для Machine1 , у которой нет зеркала. Вы можете выбрать либо метод, либо ни один.

1. Сначала переместите Machine3 .

   • Оставьте Machine1 и Machine2 на месте.
   • Резервное копирование Machine3 , а затем закрыть его
   • Получить Machine3 полностью переехал на новое место.
   • [Путь B:. Не используется , если вы собираетесь использовать дополнительный шаг # 2] Если сетевые и силовые конфигурации для всех машин идентичны: Помещенный Machine3 где Machine1 планируется закончить с использованием соединения , предназначенные для MACHINE1 .
   • Получить Machine3 обратно и работает. В новом месте убедитесь, что оно нормально функционирует как зеркало Machine2 . Это обеспечит физическую проверку работоспособности конфигурации всех проблем (электропитание, сеть и т. Д.) В новом месте.
   • Решите любые возникающие проблемы.
   • Перед продолжением убедитесь, что Machine3 полностью синхронизирован с Machine2 .

2. Путь A: (необязательно):

   • Используйте Machine3 для проверки всех объектов, предназначенных для Machine2 и Machine1 .
   • Выключите Machine3 и переведите / переключитесь на использование положения / соединений для Machine2 (проверьте повторную синхронизацию), а затем Machine1 (проверьте повторную синхронизацию). Если вы планировали сделать это, то Machine3 должен был изначально быть настроен с соединениями, предназначенными для конечного использования на Machine1 или Machine2 , поэтому вам не нужно устанавливать его сначала в конечном местоположении для Machine3, а затем изменить его 3 раза, но только 2, начав с этого, используя возможности одной из других машин.
   • Перед продолжением убедитесь, что Machine3 полностью синхронизирован с Machine2 .

3. Переместить Машину2 .

   • Ваша практика с Machine3 должна сделать это намного более плавным.
   • Сделайте резервную копию Machine2 , затем выключите ее
   • Переместите Machine2 на новое место; сделать все соединения
   • Решите любые возникающие проблемы.
   • Перед продолжением убедитесь, что Machine2 полностью синхронизирован с Machine3 .

4. [Путь B: не требуется, если вы проверили все соединения с Machine3 на необязательном шаге # 2] Если теперь есть Machine3, где должен завершиться Machine1 :

   • Выключите Machine3 .
   • Переместите его туда, где планируется его завершение (из того места, где вы собираетесь разместить Machine1 ).
   • Решите любые возникающие проблемы.
   • Перед продолжением убедитесь, что Machine3 полностью синхронизирован с Machine2 .

5. Переместить Машину1 .

   • Переехав Оба machine2 и Machine3 (и , надеюсь , протестировали фактические соединения Machine1 будет использовать при наличии Machine3 использовать их временно), это должно быть гладким из ходов.
   • Резервное копирование Machine1 , а затем закрыть его
   • Переместить Machine1 на новое место; сделать все соединения
   • Решите любые возникающие проблемы.
   • Если что-то пойдет не так с объектами в положении, которое должен занимать Machine1 , у вас есть возможность использовать объекты, где сейчас находится Machine3 . Надеюсь, вы уже смогли протестировать все объекты в позиции Machine1 , если они уже использовались Machine3 какое-то время (путь A или путь B).

Если какой-либо из IP-адресов серверов изменится, и будут установлены подключения к блоку SQL с помощью разрешения DNS, вам нужно будет запланировать изменение записей DNS одновременно с перемещением.

Вещи, которые вы должны знать о программном обеспечении и базах данных интрасети:

• Подключается ли программное обеспечение интрасети к SQL Server через IP, NetBIOS или DNS?
• У учетных записей пользователей SQL Server, используемых программным обеспечением интрасети, аутентификация ограничена трафиком, приходящим с IP?
• Получают ли сотрудники вашей компании доступ к SQL Server напрямую из каких-либо электронных таблиц или инструментов отчетности, если да, то как они определяют DSN?

Если вы не получаете точно такие же IP-адреса или попали в другую подсеть, вам понадобится доступ для изменения исходного кода или файлов конфигурации для любых приложений, которые подключаются к серверу SQL. Люди могут полагаться на недокументированный и прямой доступ к SQL для специальных отчетов.

Используйте ваши серверы «Аварийное восстановление». Переключитесь на них, чтобы справиться с нагрузкой во время перемещения ваших производственных серверов. С правильно сконфигурированным оборудованием DR вы можете выполнять движение в середине дня, не видя большого простоя (до 15 минут). Поскольку серверы аварийного восстановления должны быть настроены так же, как и производственные серверы. Если у вас нет DR-оборудования, я настоятельно рекомендую его приобрести.

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

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

Некоторые соображения в дополнение к другим ответам:

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

• Является ли время простоя приемлемым для ваших пользователей, компании или даже клиентов? Как долго это может быть?

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

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

• Серверы должны умещаться в стойку, если она у вас есть.