Какова оптимальная аппаратная конфигурация для приложений LAMP с высокой нагрузкой?

Question

Мне нужно запустить приложение Linux-Apache-PHP-MySQL (платформа электронного обучения Moodle) для большого числа одновременно работающих пользователей - я нацеливаюсь на 5000 пользователей. Под параллельным я имею в виду, что 5000 человек должны иметь возможность работать с приложением одновременно. «Работа» означает не только чтение базы данных, но и запись.

Приложение не очень типичное, так как оно выполняет много вставок / обновлений в базе данных, поэтому методы кэширования не очень помогают. Мы используем хранилище InnoDB. Кроме того, приложение не написано с учетом производительности. Например, один поток Apache обычно занимает около 30-50 МБ ОЗУ.

Буду признателен за информацию о том, какое оборудование необходимо для построения масштабируемой конфигурации, способной справиться с такой нагрузкой.

Сейчас мы используем два HP DLG 380 с двумя 4-ядерными процессорами, которые способны справляться с гораздо меньшей нагрузкой (обычно 300-500 одновременно работающих пользователей). Разумно ли инвестировать в подобные блоки и создавать кластер, используя их, или лучше использовать более качественное оборудование?

Мне особенно любопытно

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

Другое дело, как собрать все, что является наиболее оптимальной архитектурой. Кластеризация с MySQL довольно сложна (люди жалуются на MySQL Cluster, даже здесь, на Stackoverflow).

Answer 1

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

EC2 , пожалуй, является наиболее гибким на данный момент решением для стека LAMP. Вы можете настроить их виртуальные машины, как если бы они были физическими машинами, кластеризовать их, раскрутить их, когда вам нужно больше времени для вычислений, отключить их в непиковое время, создать образы машин, чтобы их можно было легко тестировать ...

Существуют различные решения для балансировки нагрузки и автоматического раскрутки.

Если вы сможете настроить свое приложение, вы также сможете использовать его механизм нереляционной базы данных. При очень высоких нагрузках реляционные базы данных (и MySQL в частности) не масштабируются эффективно. Пиковая загрузка SimpleDB, BigTable и аналогичных нереляционных баз данных может масштабироваться почти линейно при добавлении оборудования.

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

Answer 2

Петр, ты уже пытался задать этот вопрос на moodle.org ? В настоящее время есть несколько аналогичных установок, сотрудники которых отвечают на этот вопрос.

Кроме того, в зависимости от того, какие у вас временные рамки для развертывания, вы, возможно, захотите проверить строку moodle 2.0, а не строку moodle 1.9. Похоже, есть несколько хороших исправлений для некоторых проблем с архитектурой moodle эта версия.

также: memcached камни для этого. php ускорение качается для этого. serverfault, вероятно, лучший * обменный сайт по этому вопросу, хотя

Answer 3

Я не совсем уверен насчет аппаратного обеспечения, но с точки зрения программного обеспечения:

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

Кэшируйте данные в виде объектов, возвращаемых из вашего data-mapper / ORM, а не HTML, и используйте Memcached в качестве слоя кэширования. Если вы обновляете объект, затем записываете в базу данных и обновляете в memcached, для этого лучше всего использовать шаблон IdentityMap. Вероятно, вам понадобится немало экземпляров Memcached, хотя вы можете запустить их на своих веб-серверах.

Мы никогда не могли заставить кластеризацию MySQL работать должным образом.

Будьте осторожны с написанными вами SQL-запросами, и все будет в порядке.