В настоящее время у нас есть простая установка из трех серверов:
Мы находимся в точке, где нам нужно масштабировать наш веб-сервер. Мы стремимся достичь следующего:
Я хотел бы добавить дополнительный веб-узел с такой же емкостью, что и исходный, вместо того, чтобы удваивать емкость существующего веб-узла, так как это даст нам резервный / зеркальный узел (при балансировке нагрузки) для повышения емкости и обеспечения избыточности. .
Я подробно изучил варианты, на данный момент кажется, что о HAProxy не может быть и речи, поскольку я хочу обрабатывать SSL (и не хочу завершать работу на балансировщике нагрузки, весь трафик SSL должен быть зашифрован сквозным шифрованием. конец).
Мои варианты кажутся такими:
О: Добавьте программный балансировщик нагрузки (например, Nginx) на его собственный узел перед двумя веб-узлами. Проблема здесь в том, что когда пользовательский контент загружается пользователем, он не будет доступен на другом узле. С прикрепленными сеансами это не проблема, но в конечном итоге нам нужно синхронизировать загруженный контент, иначе узлы будут рассинхронизированы. Можно использовать Rsync, но поскольку мы смотрим на конфигурацию сети master-master, нужна двунаправленная ... сложно!
B: То же, что и выше, но используйте балансировщик нагрузки для обслуживания статического контента. Затем это выгружает часть обработки с веб-узлов. Мы могли бы выполнить синхронизацию всех загрузок с веб-узлов на узел балансировки нагрузки, таким образом, это будет только односторонняя синхронизация из сети-> балансировщик нагрузки. Любые нестатические запросы балансируются по нагрузке на веб-узлы. Это сохраняет весь статический контент в одном месте, но я стремился создать небольшой узел балансировки нагрузки, и он может в конечном итоге стать довольно большим?
c: Как A, но используйте NGinx для направления любого трафика посетителей, где возможна загрузка (это легко сегментировать), на один «главный» сервер для их загрузки и справедливого распределения нагрузки между другими узлами для трафика «только для чтения». Это упрощает синхронизацию, так как она будет однонаправленной (главный веб-узел-> подчиненный веб-узел), позволяет нам лучше использовать дисковое пространство на веб-узлах и не допускать статического контента в балансировщике нагрузки. Однако это означает, что если главный узел выйдет из строя, нам нужно будет вручную переключить трафик для наших областей загрузки на оставшийся сервер (nginx может сделать этот переключатель, у нас просто другая конфигурация баланса нагрузки для нашей загрузки области)
B кажется хорошей конфигурацией, и я, вероятно, мог бы объединить узел балансировки нагрузки с нашим существующим сервером электронной почты / мониторинга, поскольку он простаивает. Существует единственная точка отказа с узлом балансировки нагрузки, но в экстренной ситуации мы могли бы создать новый облачный экземпляр, чтобы заменить его. Однако мне не нравится идея, что статические изображения находятся только на одном узле, поскольку у нас не будет внутренней резервной копии. Мне также нравится идея C, поскольку она означает, что она очень проста. Если балансировщик нагрузки выйдет из строя, мы могли бы направить трафик прямо на один из веб-узлов без каких-либо проблем (поскольку у них обоих был бы полный набор статических файлов).
Любой вклад в приведенные выше решения будет очень признателен.
Я бы выбрал B, потому что преимущества, которые вы называете, верны и убедительны.
Когда у вас есть два веб-сервера, вам уже нужно решить проблему синхронизации контента на нескольких машинах; добавление третьего тривиально, поэтому синхронизация статического контента из любого источника с балансировщиком нагрузки несложна.
Дисковое пространство, вообще говоря, безумно дешево - и если вы значительно разрастетесь, вы, вероятно, все равно захотите отправить этот статический контент в CDN (например, S3, Akami), поэтому балансировка нагрузки знает, где это находится, и направляет клиента соответствующим образом. разумно средний шаг.
Учитывая, что проблема синхронизации контента между двумя главными узлами является жесткийв большинстве случаев я бы начал с направления всего загружаемого трафика на одну машину и выполнения репликации только для чтения на другие серверы. Это уменьшает изменения, и вы можете работать с главной / главной моделью после того, как балансировщик нагрузки будет установлен, заработает и протестирован.