Нужен совет по созданию масштабируемой архитектуры для Moodle

Роберт, ты явно умный парень, но с уважением найди консультанта с предшествующим знанием предметной области или начни строить что-то маленькое сейчас и посмотри, куда это тебя приведет. Нет возможности ответить на ваш пост; в нем слишком много абстрактных понятий и нет твердых чисел.

Несколько мыслей:

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

Докажите, что вам нужен этот уровень масштаба в первую очередь. Не создавайте масштабную архитектуру в ожидании пользователей, которые никогда не появятся. Извините, если я звучу резко, но 99% всех веб-сайтов не достигают масштабов. См. Переполнение стека / Ошибка сервера; они ежемесячно обслуживают миллион пользователей с нескольких обычных серверов.

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

Зависит от ваших навыков и вашей ситуации относительно времени против денег. После создания, open source и коммерческие предложения работают практически одинаково. Коммерческие решения имеют тенденцию иметь лучшую статистику и более приятные интерфейсы управления из коробки.

Для оборудования веб-сервера мне следует использовать сервер с одним сокетом или одноразовое решение?

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

Для хранилища будет достаточно использовать SAN или сервер хранилища, например Sun Unified Storage 7000.

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

Поскольку этот веб-сайт, вероятно, будет более загружен операциями чтения, какое внимание следует уделить кластеру mysql и настройке хранилища?

Создайте действительно хорошее решение для кэширования. Кэширование полной страницы, например, Squid (Varnish), кеширование данных приложения, например Memcached, или их комбинация. Рассмотрите возможность аннулирования кэша. Может быть, вам нужно быстро удалить содержимое из кэша, чтобы избежать его повторного предоставления?

Каков наилучший способ для резервного копирования кластера MySQL?

Мнения могут быть разными, но один из распространенных подходов - иметь выделенный подчиненный MySQL только для резервного копирования и использовать что-то вроде InnoBackup или Maatkit для решения резервного копирования с собственным сценарием.

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

• Живые снимки томов Amazon EBS упрощают резервное копирование базы данных.
• У Amazon есть балансировка нагрузки в виде сервиса "забыл и забыл" (конечно, больше возможностей ограничено, чем у хорошего самостоятельно размещенного балансировщика нагрузки, но с ним легко начать).
• Rightscale имеет обширный мониторинг серверов, встроенный в их изображения, что облегчает планирование емкости / самоанализ приложений.

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

Блейды и SAN часто продаются продавцами неправильно. Я подозреваю, что кластер из обычных 1U серверов, вероятно, будет лучшим для ваших нужд. Существует целый ряд центров обработки данных, которые не будут использовать блейд-системы, поскольку потребляемая мощность очень высока, а требования к охлаждению также весьма необходимы!

Я большой поклонник Gluster для распределенного / реплицированного хранилища, вам может быть интересно исследовать его как альтернативу SAN-решению от крупного поставщика.

Целый стек HP DL360s тоже подойдет (или более дешевые серверы (я настоятельно рекомендую DNUK)). Я серьезно сомневаюсь, что вам понадобятся соединения Infiniband между вашими серверами (инфраструктура дорогая и в основном не нужна для целей веб-обслуживания; если вы выполняете HPC-моделирование экспрессии генома, мой ответ может быть другим!)

Что касается сетевой инфраструктуры (если вы должны учитывать это тоже...), я рекомендую маршрутизаторы Cisco с коммутаторами Cisco Catalyst или HP Procurves (довольно равномерно, IMO и дешевле)

Что касается распределения нагрузки, выделенный linux-сервер с LVS будет легко обрабатывать трафик на несколько узлов кластера. Если у вас есть деньги ($30 тыс. +), То Citrix Netscaler может быть правильной платформой для кэширования / ускорения / балансировки нагрузки, но имейте в виду, что вам понадобится 2 (в идеале 3) из них для избыточности.

Вероятно, вы должны попытаться включить memcache с самого начала, легко добавить масштабируемость и значительно улучшить производительность кэширования, особенно при чтении из кластера базы данных MySQL. Есть и другие вещи, которые вы можете сделать для настройки производительности MySQL, например, использование InnoDB поверх MyISAM.

Я подозреваю, что вам лучше использовать обратный прокси-кеш, такой как Varnish, в отличие от Squid, который лучше работает как кэш на стороне клиента.
Вы можете легко получить пару выделенных узлов кэша Varnish или запустить Varnish на том же сервере, что и серверы Apache / lighttpd.

Старайтесь не попадать в состояние, когда вы получаете привязку к поставщику, поскольку это может оказаться очень дорогостоящим, когда речь заходит о проблемах с лицензированием. Весьма возможно создать масштабируемый сайт с использованием бесплатного программного обеспечения с открытым исходным кодом. Конечно, программные балансировщики нагрузки не будут такими же быстрыми, как аппаратные с выделенными ASIC, но с хорошей сетевой инфраструктурой это может быть довольно близко.

Для управления я планирую использовать dsh, ganglia, nagios, splunk, kickstart.

Просто нужно добавить куклу в этот список, и вы станете победителем. Не упустите дорогое лицензирование Splunk (если вы обрабатываете 10 ГБ журналов в день, это может вас укусить).

Munin - отличный бесплатный инструмент мониторинга, имеющий преимущества перед приложениями, такими как Zabbix, потому что он может автоматически настраивать графики из скрипта плагина (поэтому вам не нужно заранее отслеживать, что вы отслеживаете).

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

Установка Moodle с миллионами пользователей будет на порядок больше, чем у других, о которых я слышал. Даже Открытый университет со студентами, разбросанными по всей Великобритании и всему миру, ожидает только 200000 пользователей. Крупные университеты США, как правило, имеют только десятки тысяч пользователей. Чтобы получить представление о размере, взгляните на http://docs.moodle.org/en/Large_installations Сможете ли вы привлечь миллионы людей, использующих систему? Собираются ли они все сразу или постепенно поступают в течение нескольких лет? Вам не нужна система, способная обрабатывать миллионы, если вы только получите 10000 в первый год. Кроме того, во многих учебных заведениях имеется теоретическое число студентов, которые будут использовать Moodle, но лишь небольшой процент из них фактически используют систему. Короче говоря, начните с малого и увеличивайте масштаб.

Дистрибутив Linux облегчит жизнь при администрировании Moodle. Доступная справка интернет-сообщества вообще не ориентирована на Windows!

Подумайте о наборе местного партнера Moodle (извините, я новичок и поэтому не могу опубликовать эту вторую ссылку), если вы серьезно относитесь к этому. Они могут дать совет, основанный на личном опыте настройки и администрирования систем Moodle.

Moodle, как правило, очень легко использует системные ресурсы. Просто посмотрите базы данных, так как скорость транзакций может быть очень большой. Вы не упомянули об этом, но рассмотрите возможность отделения серверов БД от веб-сервера и сосредоточьте ресурсы на кластеризации БД. При кэшировании (eaccelerator или memcached) веб-доступ незначителен. Файловое хранилище также обычно не интенсивно, и все, что нужно, - это ссылка на приличный рейд-массив, локальный или на отдельном компьютере. Если у вас есть SAN, используйте его. Если нет, просто придерживайтесь простых вещей.

Как всегда, бэкап, бэкап, бэкап!

Удачи!