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

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

Итак, немного предыстории. Я работаю в компании, у которой есть ряд чрезвычайно важных закрытых веб-сайтов. От этого зависит безопасность людей и их средства к существованию. У нас очень мало простоев, но всегда возникают катастрофические ситуации, которые требуют восстановления с нуля.

Наша текущая установка неадекватна, но я хотел бы узнать мнение о том, что я вижу в качестве возможных вариантов. Мы размещаем все внутри на невероятно красивой установке vSphere. Прямо сейчас у нас есть один чудовищный экземпляр Ubuntu, на котором размещено все - все сайты, базы данных, ресурсы и так далее.

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

Я вижу две дороги, по которым могу спуститься.

  1. Простое резервирование. Миграция с этой единственной машины на веб-сервер, SAN и сервер базы данных, а затем либо наличие резервных машин, готовых на полную ставку, либо возможность быстро их развернуть. Это то, чего я традиционно ожидал, но не знаю, насколько это помогает нам. Восстановление за пределами площадки означает потратить часы, чтобы получить все резервные копии сайтов, и мне кажется, что их трудно восстановить, чтобы я мог отдать предпочтение наиболее важным вещам. Внутри vSphere это не кажется большим преимуществом. Но это довольно легко поддерживать.

  2. Разделите все на части с помощью vSphere. Каждый сайт может быть собственным экземпляром vSphere (или небольшим набором экземпляров vSphere для разделения базы данных / активов). Это означает больше работы по обслуживанию нескольких небольших серверов вместо одного монолитного, но это также означает, что я могу легко выбрать восстановление сайта A и сайта B в катастрофической ситуации, а не важные вещи оставить на потом. Это также позволяет вещам расходиться по программному обеспечению там, где это необходимо, что является как положительным, так и отрицательным моментом.

Мнения? Я игнорирую очевидный вариант?

  • Используйте VMware SRM или хотя бы VMware Replication. Это значительно сократит время, необходимое для подключения к сети в дополнительном центре обработки данных. (Реплика Hyper-V и HVRM эквивалентны в стеке Microsoft.

  • Отделите интерфейс от серверной части. Похоже, вам нужен уровень сети и уровень базы данных.

  • Инвестируйте в правильную балансировку нагрузки для своего внешнего интерфейса. Это может означать установку и настройку многосайтового кластера Netscalar или настройку чего-то вроде HAProxy.

  • Обеспечьте избыточность на уровне вашей базы данных. Вы не упоминаете, какой продукт БД вы используете, но для многих из них доступны высокая доступность, репликация, кластеризация и т. Д. Использовать это.

  • Сделайте свой DR-сайт «теплым сайтом», на котором у вас есть несколько серверов, работающих постоянно, например зеркала базы данных. Тогда вам не нужно восстанавливать их в случае аварии, вы просто сделаете их активным узлом.

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

Нет причин иметь один экземпляр vSphere для каждого веб-сайта. Это ничего вам не даст.

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