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

Предложения по замене рабочего сервера

Задний план

Моя команда изучает проблему в нашей производственной среде (см. сообщение о переполнении стека). Мы тщательно изучили уровень приложения (например, код, журналы и т. Д.), А также провели анализ пакетов низкого уровня, но безрезультатно. Странно то, что эта проблема возникает только в производственной среде. Еще более странно то, что код неисправности не менялся более года.

Вопрос

Сейчас мы подошли к тому моменту, когда нам нужно начать изучать другие варианты, одним из которых является замена производственной среды на новую. Здесь я надеюсь, что вы все можете мне чем-то помочь.

Я ищу предложения / рекомендации о том, как как можно проще заменить старую производственную среду на новую. Однако в течение некоторого времени мне нужно, чтобы старая и новая среда работали в тандеме, чтобы убедиться, что новая среда решает проблему. Новая среда будет использоваться группой администраторов, в то время как старая среда будет использоваться не администраторами. После того, как мы выполним нашу проверку, старая среда будет полностью отключена.

Я думал поставить какой-то прокси перед сервером, чтобы я мог перенаправлять запросы по мере необходимости, и смотрел на Приложение Load Balancer Apache Tomcat. Я не уверен, что это будет лучший подход, поэтому надеюсь, что кто-то здесь может предложить несколько предложений.

Предположения

Серверные технологии приложений

Глядя на ТАК вопрос Я не знаю, что это проблема системного уровня - описание там похоже на ошибку приложения. В любом случае, всегда стоит подумать об обновлении вашей среды, поэтому я попробую :-)


Общий план действий для серьезного изменения программного обеспечения или миграции обычно выглядит следующим образом (из вашего вопроса SO, везде, где я говорю DB / Database, вы должны думать о своем сервере App2):

  1. Как можно лучше продублируйте свою среду на новом оборудовании (и при необходимости обновленном программном обеспечении - последней версии ОС, веб-сервера, БД и т. Д.)
    Это может включать клонирование всех ваших производственных баз данных (что отлично, если у вас нет удобных тестовых данных).
  2. Протестируйте bejeebus, чтобы убедиться, что ваша проблема решена.
    (Эта часть проблематична в вашем случае, поскольку вы сказали, что не смогли достоверно воспроизвести проблему)
  3. Удалите мусор из вашего тестирования
  4. Выберите удобное время для переключения
    («удобно» для ваших пользователей: к сожалению, это обычно означает 3 часа ночи в субботу или что-то столь же отвратительное для команды администраторов)
  5. Сделайте переключение - это включает (примерно в этом порядке)
    • Отключение старой среды от сети / отключение доступа пользователей
    • Перевод старой среды в спокойное состояние, чтобы она больше не менялась
    • Синхронизация любых баз данных / изменчивых данных с новой средой
    • Выполнение любых тестов, которые вы можете сделать, прежде чем запускать новую среду.
    • Включение доступа к новой среде при прохождении тестов
      (или готов вернуть старую)

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

У вас также есть несколько разных проблем, потому что вы хотите запускать свои среды параллельно: если обе среды будут писать в базу данных, вам нужно будет принять меры предосторожности, чтобы убедиться, что обе среды записывают одинаковую информацию в свою копию базы данных (мультиплексирование соединения на вашем балансировщике нагрузки), или что обе среды могут безопасно взаимодействовать с единой базой данных.
Параллельная работа в значительной степени устраняет первый и третий пункты из пункта 5 выше (вы не дублируете серверные части, а «старая» среда продолжает работать - вы просто поддерживаете новую рядом с ней).

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


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