Вот мой сценарий: я разработчик, унаследовавший (без моего ведома) три сервера, расположенные в моем офисе. Я также унаследовал работу администратора серверов с явным отсутствием знаний об администрировании серверов и google / ServerFault в качестве ориентира. К счастью, мне никогда не приходилось физически контактировать с машинами или решать какие-либо проблемы, поскольку они всегда «просто работали».
Все три машины расположены в одной информационной комнате и служат следующей цели:
Machine1 - IIS 8.0, на котором размещается ряд внутренних приложений
Machine2 - Хранилище данных SQL Server 2008 R2 для внутренних приложений
Machine3 - Зеркальное хранилище SQL Server 2008 R2 Machine2
Ко всем трем подключены внешние жесткие диски, которые часто выполняют резервное копирование.
Мне сообщили, что всем трем нужно переехать из одной комнаты данных в другую в одном помещении. Я не буду завершать физическое перемещение оборудования, этим займется компетентный перевозчик.
Помимо создания полной резервной копии каждого из них, какие соображения мне нужно учесть, прежде чем гипотетически щелкнуть выключателем питания и наблюдать за движением моего мира?
Я понимаю, что это далеко не идеально, если все три находятся в одной комнате / помещении, но это выходит за рамки этого вопроса.
Действительно интересный вопрос, хорошо заданный :)
Перед этим ходом вам нужно проверить несколько вещей: некоторые простые, некоторые сложные.
Мощность - убедитесь, что в новой комнате не только нужное количество розеток, но и что они подходящего типа - как в случае с физическим разъемом, и если текущее местоположение позволяет использовать разные фазы питания на сервер для защиты от однофазного отказа, тогда я Я настоятельно рекомендую вам повторить это также в новом месте.
Охлаждение - вам необходимо убедиться, что не произойдет немедленного или постепенного накопления тепла, которое приведет к перегреву и возможному отключению сервера. Обычно вы можете посмотреть максимальную мощность (в ваттах) или тепло (в БТЕ), которую может потреблять каждый сервер, на веб-сайте производителя - сообщите об этом своему руководителю здания и получите от них письменное подтверждение, в котором говорится, что охлаждение в этом месте выдержит .
Сети - это сложный вопрос - необходимо реплицировать не только одинаковое количество портов между старым и новым местоположением, но и их тип, скорость и, самое главное, конфигурация. Этот последний момент является ключевым - было время, когда почти все порты в сети были в значительной степени равны - я достаточно взрослый, чтобы помнить те времена! но в наши дни количество конфигураций портов и место в сети, в котором может находиться любой порт, астрономическое, вам нужно убедиться, что люди в вашей сети реплицировали ВСЕ, чтобы оно было идентичным от старого к новому - снова получите это в письменной форме, как это непросто. Если что-то пойдет не так с этим ходом, я бы положил деньги, это будет связано с тем, что сетевые порты не идентичны, это происходит постоянно.
'Другие соединения' - знаете ли вы, есть ли у ваших серверов какие-либо другие соединения, кроме питания и сети? возможно, у них есть ссылки Fibre-Channel на общее хранилище, KVM-ссылки на общий экран управления - опять же, если вам нужно воспроизвести их идентично.
Помимо этого, не стесняйтесь возвращаться сюда с более конкретными вопросами, и я надеюсь, что этот шаг пройдет хорошо.
Другие ответы касаются технических аспектов переезда. Возможно, вам также придется подумать о некоторых других вещах.
Убедитесь, что пользователи знают, что их приложения будут отключены во время перемещения. Вы захотите запланировать переезд, возможно, в нерабочее время, чтобы свести к минимуму количество пострадавших.
Попросите знающего человека (или людей) протестировать приложения после того, как вы запустите серверы. Попросите их выполнить некоторые проверки работоспособности, чтобы убедиться, что приложения работают должным образом.
После тестирования сообщите своим пользователям, что перенос завершен, и попросите их сообщить вам, если у них возникнут проблемы.
Сложно сказать и граничить с «слишком широким» для нашего формата. Самое важное, что вам нужно проверить, это то, нужно ли вам каким-либо образом перенастроить вашу сеть или могут ли они продолжать работать с теми же адресами. Даже если они могут сохранить те же адреса, убедитесь, что они не настроены через DHCP, и / или убедитесь, что DHCP-сервер будет доступен в новом месте.
Боковое примечание: как вы уже сказали, наличие SQL-сервера и его зеркала далеко от идеала. Однако наличие резервных дисков в одном месте действительно опасно. Вам необходимо иметь резервную копию в другом физическом месте.
В других ответах есть хорошие соображения перед ходом. Однако вы также должны спланировать, как вы организуете фактический переезд. Из того, что Machine3 это зеркало Machine2, похоже, что время безотказной работы является важным фактором для баз данных SQL Server 2008 R2. Тот факт, что это зеркало, дает вам возможность. Причина существования зеркала в том, чтобы быть доступным, когда нет основного сервера. Это включает в себя недоступность из-за технического обслуживания, в том числе переезда.
Составить план:
Вы должны составить письменный план того, как будет осуществляться переезд. Возможно, вам потребуется предоставить этот план или его части людям, выполняющим часть работы (например, грузчикам). Этот план должен включать все действия перед перемещением, фактическое перемещение и действия после перемещения (например, проверку функциональности).
Основы движения:
Более подробное описание переезда:
Ниже приведены два метода (Путь A и B) использования Machine3 проверить соединения для Machine1 и / или Machine2. Вы должны использовать только один метод. Какой способ сделать это или даже использовать ли тот или иной, зависит от информации, не содержащейся в вопросе (например, физическое разделение конечных местоположений машин, физический размер машин, длина сетевых / силовых шнуров, наличие удлинителей для них, сходство конфигураций сетевых портов, время безотказной работы и т. д.). С помощью Machine3 для тестирования этих соединений потенциально позволяет увеличить время безотказной работы для Machine2, но особенно для Machine1, у которого нет зеркала. Вы можете использовать любой метод или ни один из них.
Шаг Machine3 первый.
Путь A: (необязательно):
Шаг Machine2.
[Путь B: не требуется, если вы проверили все соединения с Machine3 в необязательном шаге № 2] Если теперь есть Machine3 где Machine1 должно закончиться:
Шаг Machine1.
Если какой-либо из IP-адресов серверов изменится, и будут выполнены подключения к блоку SQL через разрешение DNS, вам необходимо запланировать изменение записей DNS одновременно с перемещением.
Что вам следует знать о программном обеспечении и базах данных для интрасети:
Если вы не получаете точно такие же IP-адреса или попадаете в другую подсеть, вам потребуется доступ для изменения исходного кода или файлов конфигурации для любых приложений, которые подключаются к серверу SQL. Люди могут полагаться на недокументированный и прямой доступ к SQL для создания специальных отчетов.
Используйте серверы «аварийного восстановления». Переключитесь на них, чтобы справиться с нагрузкой при перемещении производственных серверов. При правильно настроенном оборудовании аварийного восстановления вы можете перемещаться в середине дня, не заметив большого простоя (до 15 минут). Поскольку серверы аварийного восстановления должны быть настроены так же, как и рабочие серверы. Если у вас нет оборудования для аварийного восстановления, я настоятельно рекомендую его приобрести.
Подумайте об этом так: пока ваш корвет настраивается, используйте свой минивэн, чтобы прожить день.
Одна вещь, о которой я думаю, не упоминалось, - это физическая безопасность нового дома серверов. Для чего использовалась эта комната раньше и у кого есть ключи? Есть ли адекватная охрана (сигнализация, камеры и т. Д.).
Некоторые соображения в дополнение к другим ответам:
Связаны ли приложения с другими через e. грамм. еженощный обмен данными по файлам или с помощью веб-сервисов? Какие последствия, когда приложения недоступны? Могут ли связанные приложения справиться с этим, или они не работают или даже дают неверные результаты из-за отсутствия информации из ваших приложений?
Приемлем ли простой для ваших пользователей, компании или даже клиентов? Как долго это может быть?
Думаю, неплохо иметь план отката. Вы можете использовать его в случае проблемы, которую нельзя быстро решить, например. грамм. проблема с сетью. Вероятно, вам нужно будет оставить движок доступным на случай возврата оборудования.
Приводят ли ваши приложения к высокому сетевому трафику и должна ли сеть быть к этому подготовлена (вероятно, проблема гораздо менее вероятна, чем проблемы с адресами и межсетевыми экранами)? Если у вас есть приложения реального времени (например, программное обеспечение для видеоконференций), задержки будут важны.
Серверы должны поместиться в серверную стойку, если она у вас есть.