Я пытаюсь собрать все части вместе для настройки кластера с балансировкой нагрузки из трех серверов (2 для веб-узлов и один для MySQL) в качестве стека LAMP на EC2. Это только для запуска тестов производительности на приложении, и мне нужно собрать соответствующую информацию, чтобы оценить время, которое это займет. Мне было интересно, может ли кто-нибудь заполнить для меня пробелы по следующим вопросам:
Что именно представляет собой вычислительный блок? Я рассматриваю необходимость трех зеркальных экземпляров RightScale AWS CentOS, два в качестве веб-узлов и один с базой данных. Тогда мне нужны три небольших экземпляра?
Если я использую Apache в качестве своего веб-сервера, mod_proxy — лучший способ балансировки нагрузки на EC2 Amazon? Я вижу, что у Amazon есть балансировщик нагрузки, который можно настроить для работы с Amazon CloudWatch для предоставления метрик. Это лучший способ?
Для кэширования приложений я хочу использовать memcache. Есть ли проблемы с этим на Amazon's EC2? Думаю использовать Siege (http://www.joedog.org/index/siege-faq) для проведения стресс-тестирования. Предоставляет ли Amazon что-то уже для проведения стресс-тестирования или это будет подходящим инструментом?
Для кого-то вроде меня, у кого нет опыта использования этого сервиса, кроме установки нашего приложения на обоих веб-узлах, какое время мы здесь рассматриваем? Я знаком в основном с развертыванием приложений на экземплярах сервера и имею некоторый опыт в конфигурации сервера и настройке производительности, но я программист по профессии. Я думаю, 30 часов на настройку, а затем, вероятно, еще 15-20 на тестирование. Звучит ли это примерно?
решение1
Как уже упоминалось, вычислительный блок представляет собой примерно старый процессор серверного класса с тактовой частотой 1,0–1,2 ГГц, и вам следует рассмотреть возможность использования Elastic Load Balancing от Amazon.
Для простого стека LAMP с балансировкой нагрузки следует начать с небольшого типа экземпляра и двигаться дальше на основе результатов тестирования и сравнительного анализа.
memcached отлично работает на EC2, но вам нужно учитывать нестабильную природу EC2 (иногда экземпляры могут выходить из строя без предупреждения).
Начиная с нуля без управления конфигурацией (вы ничего не упомянули, так что я предположу, что ничего нет, но мне нравится Chef), вы, вероятно, смотрите на 2 рабочих недели. Всегда переоцениваем, так как EC2 может быть... привередливым в работе.
Я также предлагаю использовать инструменты API EC2 (а еще лучше — библиотеку для вашего любимого языка программирования), чтобы вы могли программно управлять своими экземплярами.
решение2
Не могу ничего сказать по поводу остального, но могу сказать следующее:
решение3
Если вы планируете запускать машины только на короткое время, вы, вероятно, можете упростить многие вещи и не использовать эластичное блочное хранилище Amazon. Это означает, что ваши файлы не будут сохраняться при выключении или сбое. Если вы не выключите свои экземпляры, маловероятно, что они выйдут из строя, или вы потеряете свои данные. Вы не захотите делать это в рабочей среде, но для тестирования это должно быть нормально.
Для балансировки нагрузки просто используйте AmazonЭластичная балансировка нагрузки. Используйте Amazon, если вы планируете работать с аппаратным балансировщиком нагрузки в вашей производственной установке. Если в производственной установке вы планируете использовать программный балансировщик нагрузки - тогда да, используйте тот же на EC2.
Для тестирования я люблю проводить низкоуровневые http-тесты с помощьюhttperf. Для тестирования на уровне приложений я предпочитаю использовать JMeter. Обычно я провожу тестирование наоборот. Я запускаю JMeter на EC2 и размещаю эту тестовую нагрузку в своем центре обработки данных, отличном от EC2. Таким образом, я провожу полный сквозной тест. Однако я предполагаю, что вы проводите свой тест, потому что у вас нет дополнительного оборудования локально для запуска макета производственной установки.