Можешь помочь мне с планированием мощностей?

Это канонический вопрос о планировании мощности

Связанные:

• Как вы проводите нагрузочное тестирование и планирование мощности для веб-сайтов?
• Как вы проводите нагрузочное тестирование и планирование мощности для баз данных?

У меня есть вопрос о планировании мощности. Может ли сообщество Server Fault помочь с следующим:

• Какой сервер мне нужен для обработки некоторого количества пользователей?
• Сколько пользователей может обработать сервер с некоторыми характеристиками?
• Будет ли некоторая конфигурация сервера достаточно быстрой для моего сценария использования?
• Я строю сайт социальной сети: какое оборудование мне нужно?
• Сколько пропускной способности мне нужно для некоторого проекта?
• Сколько пропускной способности будет использовать некоторое количество пользователей в некотором приложении?

Сообщество Server Fault, как правило, не может помочь вам с планированием мощности – лучший ответ, который мы можем предложить это “Проверьте свой код на оборудовании, аналогичном тому, которое вы будете использовать в производственной среде, определите любые узкие места, затем определите, сколько нагрузки может выдержать ваше текущее оборудование и/или сколько вычислительной мощности вам нужно для обработки вашей целевой нагрузки”.

Существует ряд факторов, которые необходимо учитывать при планировании мощности, и которые мы не можем адекватно оценить на сайте вопросов и ответов:

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

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

Некоторые аксиомы планирования мощности

1. Оперативная память дешева
   Если вы ожидаете, что ваше приложение будет использовать много оперативной памяти, вы должны установить столько оперативной памяти, сколько можете себе позволить / уместить.
2. Жесткий диск дешев
   Если вы ожидаете, что будете использовать много дискового пространства, вам следует покупать большие диски – много из них.
   SAN/NAS хранилища менее дешевы, и их также обычно следует специфицировать большими, а не маленькими, чтобы избежать дорогостоящих обновлений позже.
3. Нагрузки со временем растут
   Предположите, что ваши потребности в ресурсах будут расти.
   Имейте в виду, что увеличение может быть несимметричным (ЦП и ОЗУ могут расти быстрее, чем диск), и оно может быть не линейным.
4. Электричество дорого
   Хотя цены на ОЗУ и жесткие диски значительно снизились, стоимость электроэнергии неуклонно растет. Все эти дополнительные диски и ОЗУ, не говоря уже о вычислительной мощности, увеличат ваш счет за электроэнергию (или счет, который вы платите своему провайдеру). Планируйте соответственно.

Планирование количества виртуальных машин

Когда дело доходит до определения того, сколько ВМ вы должны запланировать на одном хосте, на самом деле нет действительно хороших правил. На самом деле, есть только одно, и оно только отчасти хорошее:

Количество виртуальных машин обычно ограничивается ОЗУ, если это не так.

Что не очень помогает. Если эти ВМ будут выполнять приложения с низким потреблением ЦП, то вашим ограничителем будет ОЗУ. Каждая платформа ВМ имеет свои собственные возможности по переоснащению ОЗУ, поэтому просто деление TOTAL_RAM / Per-VM-RAM = MachineCount здесь не сработает, но это число – хороший элемент планирования.

Но что, если ваши ВМ делают что-то другое, кроме низкоуглеродного пакета?

Количество виртуальных машин ограничивается семью дискретными ресурсами, доступными хост-машине:

• Гипервизор VMware, Xen, HyperV, KVM и т.д. У каждого из них есть свои характеристики, влияющие на подсчет. Некоторые очень хорошо справляются с дедупликацией страниц памяти, другие менее успешно. Некоторые не допускают переоснащения вычислительных мощностей, некоторые допускают.
• Скорость ядра ЦП Это ограничивает максимальную однопоточную производительность, которую может запустить ВМ. 36 ядер процессора с частотой 1,8 ГГц могут выдавать 64,8 ГГц на хосте, но ни один отдельный поток не будет работать быстрее, чем 1,8 ГГц.
• Количество ядер ЦП Это, вместе с частотой, описывает потолок максимальной производительности ЦП, которую вы можете достичь.
• Системная ОЗУ Как описано выше, это ограничивает количество ВМ, которые вы можете запустить. Определенные гипервизоры лучше справляются с дедупликацией страниц памяти, так что если вы запускаете 100 одинаковых ВМ, вы можете разместить гораздо больше из них на таких системах с дедупликацией, чем если бы вы запускали 100 совершенно разных ВМ.
• Размер диска Каждое изображение ОС занимает определенное количество места. Вам нужно достаточно места, чтобы все это сохранить. Таким образом, размер диска ставит верхний предел на количество ВМ, которые вы можете разместить.
• Пропускная способность ввода-вывода Диск, лежащий в основе ВМ, имеет максимальное число операций ввода-вывода в секунду, которые он может обрабатывать. Если вы перегрузите его, системы будут застревать в ожидании завершения ввода-вывода. Это ставит верхний предел на количество потребляющих ввод-вывод ВМ, которые вы можете запустить.
• Сетевая пропускная способность Для ВМ, использующих сеть, доступная сетевая пропускная способность поставит потолок на то, сколько таких ВМ вы можете запустить на данном хосте.

Все эти факторы могут стать препятствием, все зависит от того, что вы делаете со своими ВМ. Некоторые вещи, которые стоит помнить:

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

Чтобы определить, сколько ВМ вы можете разместить в системе-хосте, вам нужно знать, как работают ваши системы и что им требуется для эффективной работы. Как только вы это узнаете, вы можете заняться планированием подсчета. А еще лучше – определить, насколько мощными должны быть ваши хост-системы!

Убедитесь, что вы задаете правильный вопрос.

• Компьютеры дешевы
• Будущие потребности очень трудно предсказать
• Планируйте, как масштабироваться, а не что покупать заранее

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

Убедитесь, что у вас есть хотя бы какое-то представление о том, как вы собираетесь масштабироваться, когда объекты станут больше. Можете ли вы добавить больше серверов за балансировщиком нагрузки? Можете ли вы разделить сервер Redis?

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

Начните с оценки “запросов в секунду”. 100 – это легко управляемое количество. 1000 может стать проблемой. 1 миллион практически невозможно обрабатывать на одной машине.

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

“Пропускная способность” – сколько байтов необходимо переместить в/из сервера? Сколько данных у вас будет на диске?

“Социальные сети” – постройте прототип, получите тысячу пользователей и соберите метрики. Затем давайте обсудим, как вы должны переписать схему и перепроектировать топологию сервера.

“Шардинг”, “Кэширование” и т.д. Когда вы достигаете миллиона “пользователей”, вам может понадобиться разбить данные и активность по сотне серверов. Без дополнительных деталей мы не можем обсудить, как сделать разделение. Кроме того, слишком рано проектировать масштабирование, пока вы не узнаете, с какими трудностями столкнетесь.