Я управляю несколькими веб-сайтами, большинство из которых основаны на WordPress и все основаны на стеке LAMP. Я перемещаю все свои сайты в облако Amazon. Я новичок в AWS, и мой план заключается в перемещении одного веб-сайта за другим, начиная с моего самого маленького веб-сайта.
У меня вопрос: нужно ли размещать весь свой сайт на одном экземпляре EC2 и / или 1 веб-сайт на одном отдельном экземпляре?
Это, вероятно, звучит глупо, так как в обычном контексте веб-хостинга кто-нибудь определенно выберет последнее. Причина, по которой я подумал о первом:
Масштабируемость
Я уверен, что через несколько месяцев мне потребуется примерно в 3 раза больше вычислительной мощности, чем сейчас (запущены новые сайты, сейчас у меня их 6, к тому времени у меня будет 10; трафик на существующие сайты быстро растет). Для чего угодно, скажем, я решил пойти на горизонтальное масштабирование, например. используя 3 экземпляра одного и того же типа, которые я использую сейчас.
Итак, мой следующий вопрос: как этот сценарий повлияет на мое решение о том, следует ли мне разделить свои сайты или собрать все вместе в 1/1 группу экземпляров EC2?
Я знаю, что это, вероятно, связано с разницей между вертикальным и горизонтальным масштабированием в облаке Amazon, которую я все еще читаю. Это также, вероятно, связано со знаниями о виртуальных машинах / серверах, в отношении которых я полный идиот, но при необходимости не возражаю узнать больше. Однако я подумал, что мне следует просто спросить, поскольку это может повлиять на то, в каком направлении мне следует двигаться в отношении облака Amazon. Не стесняйтесь дать мне пощечину, если вы думаете, что я такой ленивый и должен сначала сделать уроки :)
Любая помощь очень ценится!
Отказ от ответственности: пожалуйста, сообщите, следует ли размещать это на superuser.com или на любом сайте stackexchange. Спасибо
Во-первых, необработанные данные, взятые из С. Остерманн и др., 2010 г.:
Основные характеристики экземпляра:
+-----------+---------+------+-------+-------+------+-------+---------------+---------------+
| Name | ECUs | RAM | Archi | I/O | Disk | Cost | Reserve | Reserved Cost |
| | (Cores) | [GB] | [bit] | Perf. | [GB] | [$/h] | [$/y], [$/3y] | [$/h] |
+-----------+---------+------+-------+-------+------+-------+---------------+---------------+
| m1.small | 1 (1) | 1.7 | 32 | Med | 160 | 0.1 | 325, 500 | 0.03 |
| m1.large | 4 (2) | 7.5 | 64 | High | 850 | 0.4 | 1300, 200 | 0.12 |
| m1.xlarge | 8 (4) | 15 | 64 | High | 1690 | 0.8 | 2600, 4000 | 0.24 |
| c1.medium | 5 (2) | 1.7 | 32 | Med | 350 | 0.2 | 650, 1000 | 0.06 |
| c1.xlarge | 20 (8) | 7 | 64 | High | 1690 | 0.8 | 2600, 4000 | 0.24 |
+-----------+---------+------+-------+-------+------+-------+---------------+---------------+
Базовый анализ производительности / затрат:
+---------------+------------+----------+--------+-----------+---------+--------+-----------+----------+
| System | Peak Perf. | HPL | STREAM | RandomAc. | Latency | Bandw. | GFLOP/ECU | GFLOPS/$ |
| | [GFLOPS] | [GFLOPS] | [GBps] | [MUPs] | [µs] | [GBps] | | |
+---------------+------------+----------+--------+-----------+---------+--------+-----------+----------+
| m1.small | 4.4 | 1.96 | 3.49 | 11.6 | - | - | 1.96 | 19.6 |
| m1.large | 17.6 | 7.15 | 2.38 | 54.35 | 20.48 | 0.7 | 1.79 | 17.9 |
| m1.xlarge | 35.2 | 11.38 | 3.47 | 168.64 | 17.87 | 0.92 | 1.42 | 14.2 |
| c1.medium | 22 | 3.91 | 3.84 | 46.73 | 13.92 | 2.07 | 0.78 | 19.6 |
| c1.xlarge | 88 | 51.58 | 15.65 | 249.66 | 14.19 | 1.49 | 2.58 | 64.5 |
| 16x m1.small | 70.4 | 27.8 | 11.95 | 77.83 | 68.24 | 0.1 | 1.74 | 17.4 |
| 16x c1.xlarge | 1408 | 425.82 | 16.38 | 207.06 | 45.2 | 0.75 | 1.33 | 33.3 |
+---------------+------------+----------+--------+-----------+---------+--------+-----------+----------+
Фактическая производительность обычно составляет менее 50% от теоретической. Единственный набор значений, который может вызвать подозрение, - это значения для c1.medium, которые не совсем согласуются с ожидаемыми результатами (например, пропускной способностью).
Основные затраты EC2 для типичной рабочей нагрузки - это стоимость инстансов; другие затраты (пропускная способность, выделенное хранилище и т. Д.) Обычно составляют менее 25% от общей стоимости. Нельзя ожидать идеального масштабирования производительности - и это видно из приведенных выше данных. Что касается горизонтального масштабирования, кажется, что по мере увеличения вычислительной мощности эффективность значительно падает.
Учитывая вышеизложенное и имея в виду, что существуют и другие факторы, помимо производительности исходных вычислений (например, производительность ввода-вывода, память и т. Д.), Понятно, что вертикальное масштабирование является наиболее экономичным подходом.
К сожалению, есть и другие соображения, помимо экономической теории сценария. Надежность - ключ к успеху. В случае единственного экземпляра сбой этого экземпляра приведет к сбою всей вашей установки. Одним из возможных решений может быть автоматическое масштабирование (то есть поддержание количества экземпляров равным 1), однако один экземпляр по-прежнему подвержен проблемам, которые могут возникнуть в данной зоне доступности и т. Д.
В какой-то момент необходимо масштабировать по горизонтали - вопрос просто сводится к тому, когда наступит идеальное время. Я бы, вероятно, предложил: - Вертикальное масштабирование хотя бы нескольких размеров экземпляров (тем более, если вы начнете с t1.micro) - Разделите свои базы данных на отдельные экземпляры (потому что они не масштабируются так же, как ваши веб-серверы) - Масштабируйте по горизонтали до тех пор, пока у вас не появится немного избыточности - Масштабируйте по вертикали, пока не достигнете максимального размера экземпляра - После этого масштабируйте по горизонтали (возможно, сначала используя меньшие экземпляры)
Возвращаясь к текущим вопросам - запуск одного веб-сайта для каждого экземпляра (или для набора экземпляров) всегда будет дороже. Помимо более высоких фиксированных затрат (например, один балансировщик нагрузки на веб-сайт, а не только один балансировщик нагрузки), вы не сможете использовать свои экземпляры так эффективно (т.е. один веб-сайт может иметь высокую нагрузку в то время, когда другие веб-сайты в основном простаивает - это означает, что у вас одни экземпляры перегружены, а другие простаивают). С точки зрения логистики проблема может быть не такой серьезной, как можно было бы представить - основная проблема сводится к независимому управлению всем (чего можно избежать с помощью некоторых инструментов управления конфигурацией (например, Puppet / Chef), но обычно это не шаг до тех пор, пока ваша установка не станет немного больше).
С другой стороны, одним из ограничений экземпляров EC2 является то, что вы можете назначить только один общедоступный IP-адрес данному экземпляру (что имеет некоторые последствия для определенных настроек SSL).
Конечно, вы можете создавать свои собственные AMI - на самом деле это довольно стандартная практика. Я обычно начинаю с AMI Linux от Amazon поскольку я считаю, что это один с наименьшими накладными расходами (довольно простой в использовании ресурсов и быстрый) и который лучше всего поддерживается AWS (он регулярно обновляется и т. д.) - это, и я предпочитаю дистрибутивы RHEL / CentOS (на которых Linux от Amazon на основе) к Debian / Ubuntu, которые являются другим популярным выбором. После настройки экземпляра вы можете сделать снимки своего тома (ов) EBS и зарегистрировать AMI, передав идентификатор снимка в качестве образа, на котором будет основан корневой том. Теоретически вы можете гораздо больше настраивать свою операционную систему, даже в части создания собственного дистрибутива (но все еще используя ядра Amazon), однако, если у вас нет очень конкретного варианта использования, это вряд ли будет особенно полезно. Лично я предпочитаю работать с Wordpress: Varnish + Nginx + PHP-FPM (и W3TC для Wordpress) - я считаю, что это намного проще в использовании ресурсов, чем типичный стек LAMP.
Наконец, еще раз обратимся к масштабированию. Помимо базовой экономики проблемы, обсужденной выше, трудность сводится к тому, чтобы несколько экземпляров «выглядели» как один. Это включает обеспечение того, что каждый экземпляр будет обслуживать одни и те же данные, балансировку нагрузки между вашими экземплярами и, возможно, обработку таких деталей, как сеансы PHP. Это будет сложнее сделать, если каждый сайт будет работать на своем собственном наборе экземпляров, но, вероятно, не значительно (поскольку, надеюсь, вы настроите функциональность в своем AMI). Однако наличие нескольких экземпляров означает более сложную систему и больше вещей, за которыми нужно следить. (Есть несколько вопросов по ServerFault по этой теме, например этот, этот, или этот - если вам нужны подробности о том, как масштабировать конкретную настройку, задайте это как другой вопрос).
В качестве заключительного комментария - если ваша установка не имеет особых потребностей в том, чтобы отдельный сайт работал в собственном экземпляре / кластере (например, с совершенно другой конфигурацией / требованиями), я бы предпочел запускать несколько сайтов на одном экземпляре / кластере, поскольку это проще масштабируются, более экономичны и эффективны и больше соответствуют духу «облачных вычислений» (т. е. общих ресурсов).
Ссылки: