Мне нужен совет о том, как лучше всего (в основном с точки зрения оборудования) настроить кластер серверов с высокоскоростной балансировкой нагрузки с ограниченным бюджетом (скажем, 2000–3000 фунтов стерлингов) для размещения веб-сервисов за одним IP-адресом при поддержке db-серверов и общей файловой системы. Все на linux.
Что касается веб-серверов, я знаю, что хотел бы настроить IPVS с apache, но я не знаю, как лучше всего потратиться на оборудование. Я бы хотел иметь одну машину (в идеале с резервной копией), принимающую запросы из Интернета и балансирующую их нагрузку среди массива серверов Apache. Каждый из серверов в массиве имеет общий доступ к общей файловой системе. Со временем я бы добавил в массив больше серверов, чтобы увеличить емкость.
Система всегда оказывается узким местом в балансировщике нагрузки. какая машина мне понадобится, чтобы поддерживать очень большие / не очень большие объемы трафика? что важнее - процессор / оперативная память
Для машин в массиве apache, что мне делать - больше процессоров, более быстрые процессоры, больше оперативной памяти и т. Д. - что является наиболее важным, и имеет ли это даже большое значение, если я намеревался добавить больше машин
Как лучше всего реализовать общую файловую систему, чтобы обеспечить масштабируемость (легко добавить дополнительное дисковое пространство) и производительность (поскольку это также является узким местом). Здесь мне нужен совет по программному и аппаратному обеспечению.
Оценка стоимости / производительности машин для каждой из различных задач.
Любые идеи относительно объемов трафика, которые вы могли бы обслуживать для заданного количества машин с этой настройкой.
Недавно мне пришлось сконструировать нечто подобное. Вот мой концептуальный обратная сторона конверта дизайн
Распределение нагрузки
Я предполагаю, что операторы сети настроили избыточную и высокодоступную маршрутизацию, межсетевой экран и коммутационную матрицу, которая доставляет запросы балансировщикам нагрузки.
(В противном случае я бы выбрал HA с отслеживанием состояния либо PF, либо IPtables с автоматическим переключением при отказе с использованием carp или keepalived.) Спецификации балансировщиков нагрузки будут зависеть от того, используется ли методология распределения нагрузки веб-приложения и стоимость среди других показателей.
В зависимости от бюджета, балансировка нагрузки может быть реализована с использованием - аппаратных балансировщиков нагрузки, которые, как правило, являются дорогими - программных прокси, таких как HAProxy.
Балансировщики нагрузки должны быть высокодоступными, поэтому я бы выбрал пару активных загрузок с резервными копиями в режиме ожидания (скажем, 2 экземпляра HAProxy с 2 в режиме ожидания).
Я бы просил уровень маршрутизации отправлять запросы балансировщикам нагрузки. В случае отказа одного из балансировщиков нагрузки будет использоваться решение, основанное на поддержке активности, для беспрепятственной замены неисправного блока.
Как только балансировщики нагрузки принимают запросы, они передают их на уровень кэширования. Слой кеширования будет обрабатывать:
Уровень кеширования может быть реализован с использованием такого решения, как SQUID или NGINX в обратном прокси. Таким образом мы снизим нагрузку на сервер приложений, посылая только динамические запросы на серверы Apache / PHP.
Чтобы минимизировать затраты, я бы разместил HAProxy и NGINX на одном устройстве.
Простой и масштабируемый способ сделать это - использовать CSS, JS и статические изображения, обслуживаемые поддоменом веб-сайта (скажем, http://cdn.myservice.com/static). Используя такую настройку, мы могли бы в будущем установить экземпляры кеширования глобально и заставить DNS отправлять статические запросы ближайшему экземпляру CDN. Однако сначала эти экземпляры NGINX могут выполнять работу CDN, чтобы снизить затраты.
Слой обработки
Уровень обработки состоит из пула серверов, оптимизированных для Apache / PHP. Они загружали свои файлы конфигурации из общего ресурса NFS или распределенной файловой системы и обслуживали свои запросы, обрабатывая сценарии PHP из другого удаленного общего ресурса (NFS или DFS). Использование этих удаленных общих ресурсов снижает накладные расходы на настройку, связанные с обслуживанием и синхронизацией конфигурации сервера.
Apache и PHP можно оптимизировать, например:
Пул серверов memcache также можно настроить для хранения результатов обычных и дорогостоящих запросов к базе данных. Запросы чтения обычно отправляются подчиненным, если они не находятся в слое кэша памяти, и их результаты затем кэшируются. Записи будут отправлены мастеру и могут привести к аннулированию данных в слое кэша памяти. Данные сеанса PHP также могут быть разделены через memcached, так что в случае отказа одного из серверов Apache / PHP оставшиеся серверы могут забрать данные сеанса из memcache.
Масштабирование нагрузки в пуле обработки будет связано с добавлением дополнительных серверов и обновлением обратных прокси. Пул серверов может быть разделен на несколько логических групп. Затем логическая группа будет использовать общую конфигурацию, совместно используемую через NFS, и ее можно будет обновить как блочную.
Затем можно отслеживать обновление, и при обнаружении проблем могут быть выполнены исправления или откат. Логическая группа может быть распределена по стойкам, которые ничего не разделяют (питание, сетевые коммутаторы и т. Д.) И состоят из разрозненных элементов (скажем, моделей серверов A, B и C от Dell), так что тесты блочной миграции будут всеобъемлющими.
База данных
Для базы данных у меня будет сервер MySQL, работающий в режиме «главный / несколько подчиненных». Мастер будет оптимизирован для записи с включенным двоичным журналированием для репликации. Обычно это означает, что мы будем использовать обычную оптимизацию для MySQL, такую как:
Подчиненные устройства должны быть настроены на чтение, и их необходимо будет постоянно контролировать на предмет задержки репликации с помощью такой утилиты, как mk-heartbeat maatkit. Отставающий сервер может быть удален из набора чтения PHP, пока он не догонит его.
В случае отказа мастера:
Альтернативой DNS может быть сохранение списка исправных ведомых устройств в кэше, таком как memcache, и его соответствующее обновление.
В довершение всего у меня была бы одна или две рабочие станции для сетевого мониторинга и агрегирования отчетов. Я бы использовал Munin / Zenoss для анализа тенденций, сервер системного журнала для агрегирования журналов серверов, пользовательские сценарии для анализа журналов и предупреждений. Nagios также может использоваться для обеспечения глобального обзора инфраструктуры и предупреждений.
Масштабирование
Обновление инфраструктуры для увеличения нагрузки будет осуществляться за счет: