Мне было поручено выяснить, как выполнить крупномасштабное развертывание для высокодоступного, динамического, динамического веб-приложения на основе флэш-памяти с высоким трафиком. Есть большая вероятность, что это приложение вырастет до 2 миллионов пользователей или даже больше.
Конечно, когда придет время заняться этим, я, скорее всего, найду эксперта, чтобы он мне помог. На данный момент это все теоретически, и я просто хотел получить хорошее представление о том, как это сделать.
Вот мое текущее мышление:
Моя работа в основном состоит в том, чтобы выяснить оборудование, а также способы его развертывания и обслуживания.
Что касается поддержки этого зверя, я ищу Slack, Rightscale, Landscape, VMware.
Я также собираюсь просто развернуть его на Amazon EC2, но я бы предпочел установить его самостоятельно, поскольку в долгосрочной перспективе это будет намного дешевле. Я могу начать с этой стойки и добавить инстансы EC2, если потребуется.
Как вы думаете, это перебор? Недостаточно? Я понял это, и что мне не хватает?
Спасибо всем, кто читает и отвечает!
Разработайте его на EC2. Если / когда вы хотите переместить его в дом, настройте свой собственный Эвкалипт cluster и переместите его туда, что будет легко, поскольку Eucalyptus - это клон инфраструктуры EC2 с открытым исходным кодом.
Думаю, вы серьезно переоценили свои требования. В качестве ориентира, 2 первичных / первичных IPv-адреса перед парой двухъядерных процессоров xeon, работающих под управлением nginx + tornado, обрабатывают 286 миллионов ~ 2400 байт рекламных блоков iframe + полное ведение журнала рекламного потока для 7 элементов внутри iframe. Использование каждого из них составляет <40% (что позволяет одному узлу выйти из строя без «перегрузки»)
Вторая проблема, о которой вы говорите, - это динамическая «на основе флэш-памяти», что означает, что большая часть вашей полосы пропускания будет обслуживать начальное флэш-приложение - кандидат на CDN или кеш.
В вашем динамическом флеш-приложении, вероятно, будут отправляться небольшие сообщения с использованием gevent или другой подобной технологии. Эти сообщения, вероятно, будут небольшими. Вашему интеллектуальному приложению, вероятно, придется анализировать, регистрировать и отвечать на них, но 2 миллиона пользователей в день, 80 взаимодействий каждое - это 160 миллионов взаимодействий. В часы пик вам, вероятно, придется обрабатывать 3600 транзакций в секунду. Если для этого вам нужно 300 серверов, вам нужно переписать код.
Виртуализация ваших веб-серверов, как упоминалось выше, вероятно, является пустой тратой производительности. Даже самая легкая виртуализация не будет работать так же быстро, как железо.
Однако без знания вашей архитектуры или системного дизайна любые высказанные мнения являются предположениями с учетом слабо определенных требований.
Судя по тому, что я читал о высокой масштабируемости, ваша лучшая стратегия - просто работать над текущими узкими местами и начать планировать следующие узкие места. Если вы не используете точно такое же программное и аппаратное обеспечение, которое кто-то уже использовал, и если модели использования не идентичны при масштабировании, вы не сможете спланировать весь свой рост сейчас. Вам нужно планировать текущую фазу и следующую, а не отметку в 2 миллиона пользователей.
Зачем вам помещать свои веб-серверы в среду виртуальных машин? Это просто вызывает накладные расходы, которые вам не нужны, все они должны обслуживать данные из одного хранилища и иметь одинаковую конфигурацию.
Я могу ответить по поводу размера серверов haproxy. Используйте новейшее ядро Linux (> = 2.6.27), чтобы воспользоваться функцией объединения TCP, которая сэкономит вам много ресурсов процессора при высокой пропускной способности. Используйте самую высокую частоту, которую вы можете найти для ЦП. Не нужно много ядер, лучше найдите двухъядерный процессор с частотой 3,6 ГГц, чем 8-ядерный с частотой 2 ГГц. Для ОЗУ рассчитайте 1 ГБ на 20 тыс. Одновременных подключений. Используйте два виртуальных IP-адреса для LB (активный / активный), управляемые демоном keepalived, и объявите их оба в своем DNS. Таким образом, ваши два LB будут работать одновременно, и если один из них выйдет из строя, другой получит свой IP-адрес. На одном очень большом сайте, который я знаю, работает более 300 тыс. Одновременных подключений только на двух правильно настроенных LB с некоторым запасом.
Не стоит недооценивать сетевые карты. Более низкая задержка некоторых сетевых адаптеров, таких как Myri10GE NIC от Myricom, по сравнению с другими решениями (1 или 10 GbE) может значительно сэкономить на стоимости обработки пакетов и количестве одновременных подключений на серверах.
Что касается серверов apache, haproxy может концентрировать входящие соединения в меньшее количество исходящих, тем самым уменьшая количество серверов и защищая их от скачков трафика. Однако это можно использовать для коротких соединений. Не полагайтесь на это при длительных опросах, в чате или при загрузке / скачивании больших файлов.
Взгляните на systemimager
Что касается чтения по этой теме, я очень рекомендую Масштабируемые Интернет-архитектуры пользователя Theo Schlossnagle. В нем довольно подробно рассматриваются развертывания высокой доступности и горизонтальная масштабируемость.
http://www.amazon.com/Scalable-Internet-Architectures-Theo-Schlossnagle/dp/067232699X
Также, Высокопроизводительные веб-сайты и Архитектуры облачных приложений Возможно, стоит взглянуть на него, однако последний может быть немного устаревшим.