Назад | Перейти на главную страницу

Серверная среда Windows для установки, тестирования и запуска сторонних серверных приложений в производство

Наша компания использует несколько сторонних серверных приложений (установленных как службы и рабочие столы с клиентскими приложениями), установленных на серверах Windows (виртуальных) вместе с SQL Server. Все это находится в одном домене (может, в этом проблема?). Каждое приложение имеет свой собственный способ (файлы конфигурации и записи базы данных) управления типичными настройками: имена серверов, имена баз данных, службы учетных записей и т. Д.

Вот типичный сценарий обновления:

  1. Текущая система с предыдущей версией сохраняется. Имя: Текущее
  2. Создается тестовый сервер (часто обновляют операционную систему с 2003 до 2008) и новая версия приложения устанавливается с нуля, настраивается и тестируется. Имя: Тест
  3. Создан новый производственный сервер, установлена ​​и настроена новая система (надеюсь, такая же, как и для теста). Название: Новый ** все эти системы работают одновременно и продолжают использоваться. Текущая в конечном итоге будет удалена, но только после того, как мы узнаем, что работает Новая система, и нам не нужно будет видеть, как «работала старая система».

Проблемы:

  1. Мы должны оставить текущую систему в действии, потому что мы никогда не знаем, когда нам нужно обратиться к ней для различных настроек или оставить ее в рабочем состоянии, когда новая система взорвется. Даже если мы установим предыдущую версию и выполним обновления, конфигурации будут потеряны. Я имею в виду не только имена серверов, но и другие настройки.
  2. Файлы конфигурации нельзя просто скопировать с одного сервера на другой, потому что имена серверов разные.
  3. Многие из этих приложений имеют несколько компонентов, которые работают как разные службы, и все имеют свои собственные конфигурации. т.е. существует более одной конфигурации.
  4. В нашей компании нет никого, кто бы присутствовал при установке и настройке исходных приложений и не оставил никакой документации.
  5. Многие компании, с которыми мы имеем дело, не могут дать нам полных ответов о том, как обновления повлияют на параметры конфигурации, и полагаются на подход «просто посмотрите, что ломается, и попытайтесь исправить это».

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

Извините, сетевое администрирование - не моя область знаний. Я надеюсь пролить свет на тех в нашей компании, кто принимает эти решения.

Что я делал в аналогичной ситуации (академическая среда, пять кампусов, пять серверов с одним и тем же продуктом, все они были основаны на SQL Server):

Первый шаг, который примерно аналогичен вашей тестовой среде: получите виртуальную машину (на данном этапе это может быть рабочая станция VMware), попрактикуйтесь в обновлении на ней и все задокументируйте. Это должно помочь вам выяснить, какие элементы конфигурации вам нужно сохранить и скопировать, а также научит вас, как изменить имя сервера. ;) Тогда получите новую ВМ и сделайте это снова. Если вы получаете новые ужасные ошибки, приобретите новую виртуальную машину и потренируйтесь в третий раз. Продолжайте делать это до тех пор, пока это не станет ужасным, или, по крайней мере, пока вы не почувствуете себя относительно уверенно при обновлении продукта. (Примечание: часто имя БД и имя сервера БД хранятся в реестре. Если вы копируете ключ реестра, поищите его, чтобы не обновить БД продукта преждевременно. Точно так же вам может потребоваться изменить это значение после изменения имени сервера.)

Затем, во время запланированного простоя, фактическое обновление [oldname], во время которого я бы:

  • Сохраните все элементы конфигурации, о которых я знал заранее (например, в одном случае ключи реестра со значениями регулярного выражения и текстовый файл конфигурации).
  • Получите мою блестящую новую виртуальную машину. Назовите его [старое имя] -новое.
  • Установите SQL.
  • Присоедините старую базу данных (скопируйте файлы [productdbname] .mdf и [productdbname] .ldf на новый сервер и используйте команду «присоединить базу данных» - для этого необходимо остановить SQL на старом сервере, что означает, что вам необходимо остановите и службу [productname]).
  • Скопируйте любые другие необходимые файлы (эти ключи реестра / текстовые файлы)
  • Запустите установщик, который, как правило, обнаружит базу данных и предложит обновить ее за вас (Ура!)
  • Переименуйте старый сервер в [oldname] -old и присвойте ему новый IP-адрес.
  • Переименуйте новый сервер [старое имя] и присвойте ему IP-номер [старое имя].

Первое обновление иногда бывает грубым, даже если практиковаться. К пятому вы уже старый профи, и это легко. Записывайте любые проблемы и способы их устранения.

Что касается этих элементов конфигурации, они обычно находятся в реестре в разделе HKLM / Software / [название продукта или поставщика] или в каталоге программных файлов, но не всегда. Был один поставщик, у которого были вещи по странному пути (хотя он упоминался в реестре) и текстовый файл, который нужно было скопировать в c: \ windows \ system32, чтобы программа могла его найти (настройки шифрования). Увы, вы не найдете их, пока не попробуете (и, может быть, позвоните продавцу, чтобы получить последний, вздох).

Удачи!