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

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

Связанные темы:

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

У меня есть вопрос относительно планирования емкости. Может ли сообщество 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 совершенно разных ВМ.
• Размер диска Каждый образ ОС занимает определенное количество места. Вам нужно достаточно места для хранения всех данных. Таким образом, размер диска ставит верхний предел на количество ВМ, которые вы можете разместить.
• Пропускная способность I/O Диск, лежащий в основе ВМ, имеет максимум, сколько операций ввода-вывода в секунду он может обработать. Если вы перегрузите его, системы замедлятся, ожидая завершения ввода-вывода. Это ставит верхний предел на количество ВМ, потребляющих I/O, которые вы можете запустить.
• Пропускная способность сети Для ВМ, использующих сеть, доступная пропускная способность сети поставит потолок на количество таких ВМ, которые вы можете запустить на данном хосте.

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

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

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

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

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

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

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

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

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

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

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

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

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