Масштабирование с помощью кластера - лучшая стратегия - PullRequest
2 голосов
/ 08 мая 2009

Я думаю о лучшей стратегии для масштабирования с кластером серверов. Я знаю, что нет жестких и быстрых правил, но мне любопытно, что люди думают об этих сценариях:

  1. кластер комбинированных серверов app / db с круговым циклом (с переключением при сбое), сбалансированных с помощью dnsmadeeasy. БД синхронизируются с использованием репликации. Преимущество заключается в том, что емкость можно легко увеличить, добавив в кластер еще один сервер, и это, естественно, отказоустойчиво.

  2. кластер серверов приложений, опять-таки с циклической балансировкой нагрузки (с отказоустойчивостью) с использованием dnsmadeeasy, все отчеты на большой сервер БД в задней части. легко добавлять серверы приложений, но один сервер БД создает единую точку отказа. Можно ли добавить горячий резерв с репликацией.

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

Кроме того, если у вас есть дополнительные идеи, пожалуйста, внесите предложения. Данные в основном денормализованы и нереляционные, а базы данных имеют 50/50 чтение-запись.

Ответы [ 3 ]

3 голосов
/ 08 мая 2009

Бери 2 физические машины и делай их Xen серверы

  • A. Xen Base alpha
  • B. Xen Base бета

В каждой из них работают три виртуальные машины:

  1. «веб» сервер для статики (css, jpg, js ...) + прокси с балансировкой нагрузки для динамического запроса (apache + mod-proxy-balancer, nginx + fair)
  2. сервер приложений (mongrel, тонкий, пассажирский) для динамических запросов
  3. сервер "db" (mySQL, PostgreSQL ...)

Тогда ваше распределение функций может быть таким:

  • А1 владеет вашим публичным ip и обрабатывает запросы к А2 и В2
  • B1 пингует А1 и вступает во владение, если пинг не удается
  • A2 и B2 принимают динамический запрос к A3 для данных
  • A3 - ваш выделенный сервер данных
  • B3 резервное копирование A3 со второй по секунду и предлагает доступ только для чтения для создания копий, резервного копирования и т. Д. B3 пингует A3 и становится мастером, если A3 становится недоступным

Надеюсь, это поможет вам или, по крайней мере, даст вам некоторые идеи.

2 голосов
/ 08 мая 2009

Это действительно зависит от вашего приложения.

Я потратил немного времени на различные методы для своей компании, и мы остановились (на данный момент) на том, чтобы запустить обратный прокси / loadbalancer перед кластером веб-серверов, которые все указывают на один мастер БД. В идеале нам нужно решение, в котором БД настраивается в конфигурации master / slave, и мы можем продвигать slave в master, если есть какие-либо проблемы. Так что вариант 2, но с ведомой БД. Также для высокой доступности было бы неплохо использовать два обратных прокси, которые являются циклическим перебором DNS. Я рекомендую использовать балансировщик нагрузки, который имеет «честный» алгоритм вместо простого циклического перебора; Вы получите лучшую пропускную способность. Существуют даже решения для балансировки нагрузки вашей БД, но они могут быть несколько сложными, и я бы их избегал, пока вам это не понадобится.

В Rightscale есть хорошая документация о таких вещах, доступных здесь: http://wiki.rightscale.com/ Они предоставляют эти виды услуг для решений облачного хостинга.

Особенно полезными, я думаю, являются эти две записи с картинками, чтобы дать вам хорошее визуальное представление.

«Простая» настройка:
http://wiki.rightscale.com/1._Tutorials/02-AWS/02-Website_Edition/2._Deployment_Setup

«Расширенные» настройки:
http://wiki.rightscale.com/1._Tutorials/02-AWS/02-Website_Edition/How_do_I_set_up_Autoscaling%3f

1 голос
/ 08 мая 2009

Я буду комментировать только на стороне базы данных:

При нормальной СУБД нагрузка чтения / записи для БД 50/50 сделает репликацию «дорогой» с точки зрения накладных расходов. Почти во всех случаях простое решение отработки отказа обходится дешевле, чем реализация репликации активной / активной настройки БД. Как с точки зрения администрирования / обслуживания, так и стоимости лицензирования (если применимо).

Поскольку ваши данные «в основном денормализованы и нереляционные», вы можете взглянуть на HBase , который является реализацией OSS Google Bigtable , системы баз данных на основе столбцов ключ / значение , HBase снова построен поверх Hadoop , который является реализацией OSS Google GFS .

Какое решение выбрать, зависит от ожидаемого увеличения емкости, когда Hadoop предназначен для масштабирования до потенциально тысяч узлов, но также должно работать и на гораздо меньшем.

Я управлял активными / активными реплицированными БД, БД с одной записью / множеством чтений и простыми отказоустойчивыми кластерами. Выход за пределы простого отказоустойчивого кластера открывает новое измерение потенциальных проблем, которые вы никогда не увидите при настройке отказоустойчивости.

Если вы собираетесь использовать традиционную СУБД SQL, я бы предложил относительно «железный» сервер с большим объемом памяти и сделал бы его отказоустойчивым кластером. Если ваш коэффициент записи уменьшается, вы можете использовать отказоустойчивый кластер записи и ферму серверов только для чтения.

Ответ кроется в деталях. Ваш процессор приложения или I / O связаны? Вам потребуется терабайт памяти или всего несколько ГБ?

...