В моей текущей работе у меня такая ситуация: каждый раз, когда мы устанавливаем какое-то новое программное обеспечение (в 9 из 10 случаев приложение написано на PHP), оно устанавливается на свой собственный сервер, состоящий из ОС Debian, сервера Apache и PostgreSQL. база данных. Благодаря этой стратегии в настоящее время у нас есть около 10 серверов (примечание: когда я говорю «сервер», я говорю «обычный ПК без экрана», а не «мы потратили на этом сервере достаточно, чтобы накормить небольшую страну»), большинство из них совместно используют те же программные требования.
Эта ситуация заставляет меня задуматься: не следует ли нам создавать кластер вместо добавления отдельных серверов для каждого приложения? Я могу засвидетельствовать, что, хотя некоторым серверам требуется лучшее оборудование (в основном ОЗУ), некоторые другие простаивали не менее трех недель, поэтому с кластером мы могли бы лучше использовать эти ресурсы. В то же время я не уверен, что результаты оправдывают затраты времени и усилий, необходимых для создания и поддержания вышеупомянутого кластера (я всегда хотел использовать слово «вышеупомянутый»).
После всего этого вступления главный вопрос: вы бы предложили в этой ситуации создать кластер? Или вы бы сохранили серверы такими, какие они есть сейчас?
Кластер добавит избыточности и улучшит масштабируемость. Однако это вносит сложность. Вам понадобится какая-то форма балансировки нагрузки (а циклический DNS не подходит). Вам также нужно будет иметь дело с разделением сеанса между серверами. Ваши приложения могут записать это в базу данных, которая будет работать, если немного медленно, но многие из них не предназначены для работы в кластерной среде. Вы можете использовать липкую балансировку нагрузки сеанса или самостоятельно изменить приложение для работы с сеансами в масштабе кластера.
Вы можете взглянуть на виртуализацию - замените свои многочисленные коробки одним или двумя высокопроизводительными серверами и используйте VMWare, Virtual Server и т. Д., Чтобы выделить соответствующие ресурсы для каждой виртуальной машины.
У всех остальных есть свои достоинства. Я бы сказал, что если все (или большинство) ваших приложений представляют собой стек LAMP, я бы сказал, что кластер часть базы данных (MySQL / PostGreSQL / и т. Д.) Либо активный-активный / аварийное переключение, как вы хотите.
Что касается производительности приложений, вам действительно нужно больше метрик, чтобы доказать справедливость любого вида кластеризации. Чтобы добавить сложности без оглядки на актуальный измерения не говоря уже о возможном кошмаре управляемости, убедитесь, что у вас есть доказательства.
С логической точки зрения, если вы просто запускаете новые сайты / приложения, а базы данных всегда являются частью каждого приложения, я бы сказал, что объединение баз данных в кластер будет выгодно с точки зрения управления и, в конечном итоге, позволит вам виртуализировать веб-серверы. (снижение будущих затрат). Сохранение независимости обоих слоев поможет вам следующим образом:
Данные превыше всего - самое главное в IT. Потерять информацию; терять клиентов, что приводит к потере денег. Кластер может улучшить производительность / доступность / избыточность / управляемость, если все будет сделано правильно (и тщательно протестировано).
Виртуализация ваших веб-серверов обеспечивает доступность и управляемость. Если виртуальный сервер выходит из строя, веб-сервер может перейти на другой жизнеспособный виртуальный хост, и кластер базы данных может продолжать работать. Кроме того, меньше нужно покупать для каждого нового веб-приложения, которое необходимо установить. Разве не было бы намного дешевле добавить больше оперативной памяти к виртуальному хосту, чем покупать совершенно новый сервер?
Так что отвечу прямо на ваши вопросы ..
Эта ситуация заставляет меня задуматься: не следует ли нам создавать кластер вместо добавления отдельных серверов для каждого приложения?
Да, в некоторой степени. Если вы не размещаете одно большое веб-приложение и производительность не является серьезной проблемой (например, facebook?), Кластеризация веб-серверов и, возможно, включение некоторых кэширующих серверов (memcached) для повышения производительности определенно поможет. Но в вашем случае похоже, что у вас много небольших или более простых сайтов / веб-приложений с базами данных для каждого приложения. Если загрузка / производительность здесь не проблема, виртуализация поможет с временем безотказной работы / доступностью.
С точки зрения времени безотказной работы / избыточности / управления, я бы определенно сгруппировал серверы баз данных в сплошную группу серверов. Храните данные в безопасности и снижайте вероятность простоя / поломки. Это гораздо важнее, чем веб-сайт, поскольку сайт - это просто набор файлов, обслуживаемых apache, nginx (выберите свой веб-сервер). Резервная копия сайта не так уж и велика с точки зрения хранилища (обычно), и восстановление сайта должно быть довольно простым и понятным. Или вы можете проявить творческий подход, и когда все ваши сайты работают на виртуальных машинах, сделайте резервную копию виртуальных машин для любых изменений на веб-сервере, сделайте резервную копию, и если рабочий / производственный образ станет сломанным или трудно исправить, просто скопируйте хорошую копию из архива. . Кластер базы данных должен по-прежнему работать, и как только новая виртуальная машина будет запущена, она должна указывать на кластер db. Просто идея. Бьюсь об заклад, у других людей есть лучшие идеи / методы, но неважно. Это просто мысль.
Я могу засвидетельствовать, что, хотя некоторым серверам требуется лучшее оборудование (в основном ОЗУ), некоторые другие простаивали не менее трех недель, поэтому с кластером мы могли бы лучше использовать эти ресурсы.
Если вы пришли к выводу, что вы нужно лучше оборудования, вам лучше сначала понять это, прежде чем строить кластер из плохих частей. Если у вас постоянно возникают многочисленные похожие проблемы, кластер ничего не исправит. Да, кластер приспосабливается к проблемам, для которых он был разработан, но сначала займется коренной проблемой. Зачем строить на плохом фундаменте? Но если ваша точка зрения не имеет достаточно оборудование, это другая проблема, которая может быть вне ваших рук. Я бы посмотрел на треп, кто бы ни финансировал сильно.
В то же время я не уверен, что результаты оправдывают затраты времени и усилий, необходимых для создания и поддержания вышеупомянутого кластера (я всегда хотел использовать слово «вышеупомянутый»).
Помимо вашего бурлящего словаря, приятно видеть, что вы, по крайней мере, осознаете вес квеста, который лежит перед вами, если вы решите пойти по кластерному маршруту. Я собираюсь предпринять безумный удар и сказать, что, я думаю, вы ищете причину, по которой «продолжать» кластер, и хотя многие здесь могут согласиться с вами, только вы знаете свои технические сильные и слабые стороны. 10 веб-серверов - это не так уж и плохо, но вскоре, когда у вас появится все больше и больше веб-серверов для размещения, между управлением серверами, резервным копированием, работой с безотказной работой / доступностью и избыточностью вам придется что-то делать. Если вы не сделаете что-то сейчас, это может быть хорошо, но я бы начал изучать все ваши варианты свидания в будущем. Кто знает? Через шесть месяцев вы добавите еще 10 приложений, и ваша точка зрения резко изменится.
По моему опыту, прежде чем отправиться в такое приключение, проведите исследование, исследуйте свои текущие активы, создайте стратегию / план и заполните все пробелы в этом плане. Фактически, вот отличный документ, если вы начнете исследовать кластеризацию и тому подобное: http://www.scribd.com/doc/4069180/Caching-Performance-Lessons-from-Facebook. Допустим, что в плане всегда что-то идет не так, чем больше времени у вас будет на пересмотр и пересмотр плана, вы поймете возможные ловушки.
Если вы не видите высокой нагрузки ни на одном из отдельных серверов и у вас уже есть процедуры для управления каждым из этих серверов, я думаю, вам лучше всего взглянуть на виртуализацию (я задавал много вопросов о это и эксперименты с ESXi ... пока приятно!)
Таким образом, вы можете сохранить свои процедуры обслуживания, упростить стоимость оборудования, упростить некоторые операции по резервному копированию (хотя вам понадобится много места для хранения ... на сервере и для резервного копирования) и упростить развертывание новых или экспериментальных установок. в долгосрочной перспективе.
Похоже, вы, вероятно, могли бы потратить деньги, которые вкладываете в серверы и электроэнергию, чтобы использовать эти серверы, для покупки пары серверов для VMWare и поддержки их инструментов избыточности и управления, таких как VMotion.
Связывание всех сайтов в один означает добавление сложности вашей конфигурации и, возможно, некоторых взаимозависимостей на вашем веб-сервере. Это можно сделать, но это может упростить поломку во время обновлений или изменений; виртуализация добавляет уровень, который немного замедлит работу и даст вам единую точку отказа (если вы не инвестируете в два + сервера и решения для резервирования VMWare), но вы многое выиграете, по-прежнему имея отдельные машины для управления и настройки .
Тестирование конфигурации не должно быть слишком сложным, поскольку вы можете получить ESXi бесплатно, если у вас есть сервер в списке совместимости, на котором его можно установить, а затем запустите конвертер (теперь доступен для Linux и Windows, бесплатно), чтобы создать затем виртуальные машины отключают физический сервер и перенастраивают сетевые параметры виртуальной машины, чтобы взять на себя роль физического сервера. Установите какое-нибудь программное обеспечение для мониторинга (например, от Veeam, у них есть некоторые бесплатные инструменты для нужд малого бизнеса, регистрация - это своего рода боль) и начните видеть, какую нагрузку вы накладываете на хост виртуального сервера. Вы можете быть удивлены.
и если то, что у вас работает, в основном одно и то же на всех серверах, вы можете предоставить одну и ту же услугу на одном сервере с виртуальными хостами apache и несколькими базами данных.
Другим решением может быть установка сервера с OpenVZ и настройка VPS для каждого приложения.